Re: TGraphErrors::Fit

Rene Brun (Rene.Brun@cern.ch)
Thu, 12 Mar 1998 18:28:21 +0100


Hi Jacek,
We agree essentially with your point. Thanks, by the way, to
formulate the problem/algorithm in a simple way.
I will implement the algorithm (TGraphErrors, and also TH1).
The optimisation you propose is in general not possible
because points in a TGraph/TGraphErrors are in general not equidistant.

Rene Brun

Jacek M. Holeczek wrote:
>
> Hi,
> Now, when the TF1::Derivative function is implemented, I would like to
> propose that a new feature is implemented - the TGraphErrors::Fit function.
> The TGraphErrors object contains errors on BOTH X and Y axis. The Fit
> function, however, comes from TGraph::Fit, which internally uses
> TGraph::GraphFitChisquare, and it does NOT take errors on X axis into
> account. Only errors on Y axis are considered. Thus my proposal - in
> case of a TGraphErrors object the TGraphErrors::Fit should use errors on
> BOTH axis, X and Y. For me it seems that the TGraphErrors::Fit could be
> a "direct" copy of TGraph::Fit and the only change should be done for
> TGraphErrors::GraphFitChisquare, which should be a modified
> TGraph::GraphFitChisquare function ( possibly also a log likelihood
> function could be implemented :-) ).
> To calculate the chisquare in such case one should sum over "bins" :
>
> (n - f)**2
> ------------------
> dy**2 + (f' dx)**2
>
> where n is the experimental bin content, f and f' are respectively the
> value of the function being fitted and its derivative, both taken at
> the nominal value of x, and dx and dy are the errors in x and y.
> This clearly assumes that the function being fitted is nearly a
> straight line inside a bin ( or inside a dx ). If that is not true,
> the problem becomes highly non-linear and one shouldn't believe the
> results of any fit anyway.
> If the chisquare is calculated as indicated above and the
> approximations are valid, then all the other features of MINUIT
> ( calculation of parameter errors, error matrix, contours, etc. ) will
> automatically take account correctly of the errors in x and y ( based
> on my talks with Fred James ).
> The function f would be called three times - two times as f(x) and once
> for f(x+dx) ( or f(x+0.5dx) ). In order NOT to call f(x) twice ( once
> in the above sum and once in calculation of f'(x) ) on might "embed" a
> simplified version of TF1::Derivative into this sum. In this case there
> are two calls of the function f per "experimental point".
> One might also consider a better approximation of f' using for example
> a parabola going through f(x-dx), f(x), and f(x+dx). In this case one
> gets :
>
> (n - f)**2
> -----------------------------------
> dy**2 + ((f(x+dx) - f(x-dx))/2)**2
>
> This method requires again three calls to the function f.
> To reduce the number of calls to the function f to ONE per "experimental
> point" one could, during looping over bins, remember the value of f from
> the previous bin and use that to estimate f' ( watch out at both ends ).
> Jacek.
> P.S. Of course, the user may supply his f', which should be used in this
> case ( the MINUIT has it foreseen ). Jacek.