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.
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:31 MET