From: Richard Owlett on
Rune Allnor wrote:
> On 10 Nov, 21:20, Richard Owlett <rowl...(a)pcnetinc.com> wrote:
>
>> What guidelines are there for choosing number and location of
>> breakpoints?
>
> You have stumbled upon the 'art' part of 'the art of data
> analysis'. Data analysis is a bit desceptive, as it relies
> extensively but not entirely on mathemathics, which is a
> quantitative science.
>
> The deception lies in the fact that when it comes to making
> the decisions that are *not* governed by the maths you are
> more or less on your own. There might be an established 'best
> practice' within a field or user community, but if such a
> 'best practice' exists at all, it will be based on one or more
> qualitative factors like empiri, user experience, mutual
> agreements among users and/or clients, and convenience.
>
> Unless you happen to stumble upon a user community that happen
> to use *exactly* the same methods as you to answer *exactly* the
> same question as you - and who are willing let you in on their
> experiences - the best you can do to get an answer is to play
> with your data while keeping some key questions in mind:
>
> 1) What do I attempt to achieve?
> 2) Why do I expect any one particular method to produce
> the results I want?
> 3) What does it take to implement / apply the method?
> 4) How well did the method work?
> 5) How well did the results meet my expectations?
> 6a) Why did the method work as expected? Did I as user /
> analyst use prior knowledge about the test data to
> set up idealized input, or did I stop the method at
> a point where I knew the result was close to the
> known answer?
> 6b) Why did the method not work? Did it rely on data
> or information I could not possibly have? Were there
> noise or other imperfections in the data that undermined
> the workings of the method? Was the desired result
> discernible from mere noise?
> 7) How much prior knowledge about a data set, the generating
> process and the inner workings of the method does it take
> for a user to obtain useful results?
>
> And so on. I know, it's a long list of questions (and quite
> a few of them requires some dicipline to ask oneself, particularly
> when stakes are high or when working alone), but there are no
> other ways to learn.
>
> Rune

I hadn't set out exactly those questions. But brick walls of
reality effectively required me to answer them. My initial goal
may have been too ambitious for my abilities. So I attack smaller
problems that come to light.

Retirement is for learning what you never learned in school ;)

 | 
Pages: 1
Prev: Wav File
Next: Schmitt trigger in software