|
From: Bastian M. <bma...@we...> - 2011-05-05 10:33:14
|
> Please fill us in about what these are supposed to mean. Maybe that > will lead to better syntax. Browsing the documentation for "fit" and > reading the bug report is a bit to digest. > (snip) The point of the original report is the following: After the actual fit the calculated errors of free variables are currently scaled by FIT_STDFIT. This is correct if there was no error column given for the dependent variable, or the errors are in fact relative weights, ie. they only give the relative "credibility" of the data points. This would be the behaviour of "set fit relativeerrors". If the error column actually contains (absolute) data errors, e.g. statistical errors, this scaling is undesirable. "set fit absoluteerrors" would allow the user to switch it off and therefore obtain the same errors as e.g. CERN Minuit does. This issue has been discussed at lengths on this mailing list (and elsewhere) several times already, see e.g.: http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/3737/focus=3740 and http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/6205 The proposed solution leaves the decision on how to interpret data errors to the user. (My gnuplot.ini will certainly have "set fit abs" in it.) For the sake of compatibility and since "weigths" are standard in some fields, the default stays like it is. > ** > Dear gnuplotters, > > I may be missing something, but I understood that with least squares > with given standard deviations, the error in the fit parameters is > simply the square root of the according covariance matrix diagonal > element, opposed to the case of unknown standard deviations, where the > standard deviations are assumed to be equal and are estimated a > posteriori by chi^2 / ndf. If this is the case, I think lines 766--768 > in fit.c of gnuplot version 4.4 rc1 are a bug, because in the case of > known data errors, this code should not be exercised. > > Thanks for your comments, > > Paul > ** > > The case of "known data errors", what is that? Does Paul mean known > statistics for the data errors (i.e., the case where an extra column is > supplied to the input)? Yes. Supplied errors, but with an "absolute" meaning. > I see in the documentation something about "set fit errorvariables" and > variables created with "_err" tagged onto the string. Is this what > "relativeerrors" and "absoluteerrors" refers to? Is it something having > to do with the way in which "_err" error variables are derived? If so, > what then if the user wants both for comparison purposes? Maybe it > should become two sets of error variables "_errabs" and "_errrel". Am I > on the right track? Right track, see above. I don't think that having two variables is a good solution, though: the data errors (input) are either relative weights or absolute errors. If the user want's both, he could still multiply/divide by FIT_STDFIT when needed. Bastian > As for the original bug report, unless this is something obvious, > perhaps there is a way to illustrate the error with a test case, to > ensure the fit is solved correctly. In fact, a tutorial demo or two > illustrating settings would be nice. > > Dan |