Re: Changes to gnuplot fitting submitted to sourceforge as patch

[<br...@ph...>]

Thomas Mattison wrote:
> On 10-Mar-06, at 8:52 AM, Hans-Bernhard Bröker wrote:

>>> On 8-Mar-06, at 10:34 AM, Hans-Bernhard Bröker wrote:

> I did subscribe, so I don't understand.  But I have several email accounts,
> and some of them have aliases for the mail servers, so gnuplot-beta
> may not have figured out who I am.

Mailman only knows the actual mail address you subscribed as.  If you 
use something else as the FROM: field in your submissions, it'll reject 
them.  This one passed directly.

>>>> 7.  New one-line progress-report, revert by FIT_CLASSIC_PROGRESS = 1

> When it wraps, the columns typically don't line up, so usually the only
> thing that a line-wrap parameter would improve is that a single column
> would not get broken across lines.  

That's fixable.  E.g. if the lines are set to wrap, have them wrap 
always.  I.e. put all the non-parameter info in one line, then as many 
parameters as fit per line, with some indentation to provide some visual 
guidance.

But don't let me detain you --- if you don't implement, I might just
do it myself, once we integrated your patch.

>>>> 9.  Error-rescaling control

> The remaining disagreement is what to do in the old result format,
> and what about the internal variables containing the errors.

> It sounds like providing another variable to control the behavior
> is the appropriate solution.  So I'll provide one in the next version.

OK, then.

>>> If we repeat the same experiment and fit many times, the data will
>>> have statistical fluctuations, the fit parameters will have statistical
>>> fluctuations, and the chisquare will have statistical fluctuations.

>> ... and the parameter errors will also have statistical fluctuations.
>> Which will generally be no smaller than those of chisquare itself.
>> So the dividing them doesn't actually increase the variation of the
>> reported parameter errors considerably.

> I agree that for a normal chisquare behavior we are only talking about
> fluctuations of the errors by of order a factor of 2, not a factor of 10
> or more.  But the fit _errors_ for repeated experiments should actually
> not fluctuate at all, for fixed data errors.  

Now, that's a very strange statement, I think.  How could a process 
based entirely on statistically fluctuating data *avoid* fluctuation in 
some of its results?  There's a direct algebraic connection data --> 
residuals --> parameter errors.  I really don't see how the data can 
fluctuate, but the parameters not.

>>>> 10.  Gnuplot-readable parameters and errors in one line in fit.log file

>> Because its primary purpose is to be human-readable, not
>> machine-readable.  Because for all you know, it already contains a lot
>> of data the moment you start gnuplot.  fit.log is, basically, an
>> electronic lab notebook, not a worksheet to collect data from various
>> steps of a single experiment in.

> The simplest solution sounds like my original proposal of a new file
> with the summary lines always appended, with enough comments between
> them for human editing if required.  

What I don't really like about that version is the "always".  It 
basically means the user has to re-do the entire procedure, or manually 
edit the file in the middle of a gnuplot sessions, to remove fits gone 
bad from this machine-readable log, before he forgets which fits are to 
be kept, and which not.

'update' is the existing command to, so-to-say, 'bless' a fit result as 
accepted for further usage.  That's why I think it's the right place to 
add the machine-readable session log.

 > If we don't need a way to control
> whether or not the present summary goes into fit.log, we don't need a
> way to control whether the one-line summary goes to the new file.

Because the fit.log file is for humans to read, and it provides all the 
context the user can possibly need.  A full-blown copy of it in a 
machine-readable format would not serve much of a purpose that couldn't 
already be had by machine-translating the existing fit.log.   A selected 
subset of it must have the selection done inside gnuplot, not 
afterwards.  That's where update comes in handy.

>>>> 13.  Parameter step size limit, controlled by FIT_MAX_PAR_STEP

> There is still another goal, which is to avoid long jumps
> that might find the wrong minimum or be slow to recover from,
> even if they don't cause an undefined function evaluation.

But such tactics require implied knowledge about which long jumps are 
bad, and which aren't.  I don't see how it can be part of generic 
fitting program's job to second-guess the individual problem.  If the 
user already knows where the minimum is, she shouldn't be running 'fit'
to find it.

>>>> 16. Monte Carlo search for initial fit parameters

> The goal of _this_ Monte Carlo is to find a starting point in a
> defined range, 

I'm fully aware of that, and I'm not arguing we remove it.  FWIW, MINUIT 
also has such a method available.  But I don't think anyone I know ever 
used it on a regular basis.  A well-informed guess at startup parameters 
basically always outperformed it.

Ultimately, the statement I took from the manual for fudgit still holds: 
Non-linear least-squares fitting is an art!  It takes some learning to 
master it.