Re: What's left for a 4.2 release?

[<ha...@on...>]

On Wed, Jul 12, 2006 at 11:12:07PM +0200, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
> > 	FIT_CONVERGED - 1 if the fit has converged, 0 otherwise
> > 	FIT_NDF  - number of degrees of freedom (#obs - #param)
> > 	FIT_RMS  - RMS fit of model to data;
> > 	           a.k.a. "std fit"
> >                    a.k.a. sqrt(sum_of_squares/ndf)
> > 	FIT_CHI2 - variance (reduced chi-squared residual) after fit;
> > 	           a.k.a. (sum_of_squares/ndf)
> > 
> > 	Hans-Bernhard has objected to these names, but no one has
> > 	suggested anything better. Please speak up.
> 
> Oh well, since I don't have the time to put my money where my mouth is 
> --- go ahead and check it in as-is.
> 

I agree with Hans-Bernhard's point in Feature Request 1117724
that it is preferable to be consistent and use the same variable 
names as occur in the printout and documentation rather than
introduce additional notation for the same quantities.

Thus FIT_STDFIT instead of the above FIT_RMS, to indicate that the
denominator is ndf not #obs-1.  While STDFIT may not be familiar, 
it is documented.

However, gnuplot.doc could be clearer wrt rms of the residuals, i.e, 
when estimating the mean value of the residuals, one would use #obs-1, 
and refer to standard deviation of the residuals.  For standard 
deviation of the fit, one uses #obs-#param.  Thus 'variance of residuals' 
and 'rms of residuals' in gnuplot.doc are generic descriptions for the 
lack of an alternative characterization of WSSR/ndf and sqrt(WSSR/ndf).)

By analogy to STDFIT, I would suggest FIT_VARFIT for variance of 
the fit rather than some other notation for WSSR/ndf.

It is not clear in the request why one wants both FIT_STDFIT and 
FIT_VARFIT, each readily computed from the other.

BTW It is difficult to find posts relevant to a particular item when 
all have the same subject so I may have missed some mention of the fit
discussions related to a 4.2 release.  Any suggestions for a subject 
for any fit follow-up? 

I don't recall having seen any mention of incorporating patch 
 1445064  Gnuplot fitting improvements  2006-03-07
submitted by Thomas Mattison after a number of exchanges on the
mail list between he and HBB.

The discussions re that patch brought out the point that currently 
the documentation and the fit output label are consistent, but those 
are inconsistent with the values output by the fit routine, i.e., 
the documentation and fit output explicitly refer to parameter 
errors as "asymptotic standard error", i.e., as calculated from the 
variance-covariance matrix, with the intent that notation might cause
the less experienced fitter to consult the documentation and become 
aware of the limitations in using those values to determine confidence 
levels.

However, fit.c has the comment
 * HBB (br...@ph...) : fit didn't calculate the errors
 * in the 'physically correct' (:-) way, if a third data column
 * containing the errors (or 'uncertainties') of the input data was given.

and the code
	/* scale parameter errors based on chisq */
		chisq = sqrt(chisq / (num_data - num_params));
			for (i = 0; i < num_params; i++)
				    dpar[i] *= chisq;

Somehow, that discrepency was overlooked in earlier releases.

I would present the asymptotic standard error and leave it to the user
to determine any relationship between parameter errors as determined by 
the curvature of the chisquare hypersurface in the region of the minimum 
and confidence limits for those parameters rather than apply an
arbitrary scaling to the asymptotic standard errors.

That may be a point of contention - IIRC, the patch has a control
variable which allows the user to select unscaled errors, as documented,
or scaled errors, if such are desired, or for consistency with earlier
gnuplot versions.

- Lucas Hart