2012/5/4 Gilles Sadowski <gilles@harfang.homelinux.org>:
> Hello.
>
>> I'm obviously missing something in my litterature review. I did a new
>> MC simulation, with a much smaller number of observation points
>> (namely 3, to fit a straight line!!!). It turns out that the formula
>> you are advocating for is the best estimate of the standard deviation
>> of the parameters. Could you please explain why this fomula differs
>> from formulas (34) and (35) in
>> http://mathworld.wolfram.com/LeastSquaresFitting.html?
>
> Independently of the explanation to be provided by Dimitri, I think that
> there are code design arguments in favour of deprecating (and later,
> deleting) the "guessParametersErrors" method, as follows.
>
> In the context of the "optimization.general" package, one assumes that a
> Jacobian matrix is available. From there, the code in "AbstractLeastSquares"
> computes the covariance matrix, from which one can readily extract the
> "sigma".
> This can be done without computing the chisquare! [While, as you have
> probably noticed, the "guessParametersErrors" will not behave nicely if you
> don't call "updateResidualsAndCost()" beforehand.]
>
> For the class to be selfconsistent, the story can end here: Any additional
> utilities can lead to wrong expectations from different types of users (as
> we've demonstrated here).
> Indeed, confidence intervals refer to additional variables (as Dimitri
> wrote: "By how much can a parameter change before the normalized chi2
> changes by <some number>?"). Being able to answer those questions also
> involves the correlations between the parameters (cf. the plot I've attached
> to MATH784), whereas "guessParametersErrors" does not take them into
> account.
>
>> I hope I'm not bothering you too much. I really would like to
>> understand, so that we could write an accurate javadoc and possibly
>> rename the method appropriately.
>
> For clarity's sake (designwise), I propose to remove the
> "guessParametersErrors" method, and add a "getSigma" (as syntactic sugar).
>
I'm OK with that. As a first step, we deprecate it, and stipulate in
the javadoc that getSigma() should be used instead. We emphasize that
both methods do not provide exactly the same value. Similarly, I
propose that the javadoc of getSigma() states exactly what it returns
(namely, sqrt(cov[i][i])). Finally, do you think its worth calling
this method getSigmaParameters() in order to avoid confusion with sd
on the observations (which are implicitly assumed by the weights in
the chissquare)?
The tests I've recently added (NIST data) must be altered a bit, so
maybe I could take of the whole thing if you want. Then we could
consider that MATH784 is resolved.
>
> If you want to dig further into the confidence interval issues in order to
> provide the related functionality (similar to, but not limited to, the
> current "guessParametersErrors"), I propose that that code be located in the
> "stat" package (where, by the way, some of the utilities might already
> exist!).
>
Maybe in the future I will dig into this problem, I find it very
interesting!!! For the time being, I'd rather concentrate on other
issues such as the current bugs reported in the distribution package
(been working a lot on this recently, even if I have not yet come up
with a patch...).
> What do you think?
>
>
> Best regards,
> Gilles
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
