Minuit versus Linear fitter in ROOT v5-30-00-patches

While trying to fit a TGraph with a “pol3”, the “Minuit” gives me always worse “chi2” (in both cases below the “Fit Panel” interface was used).
Is there any parameter I can change in order to “improve” it?

[code]Minimizer is Minuit / MigradImproved
Chi2 = 2216.32
NDf = 464
Edm = 7.8433e-11
NCalls = 77
p0 = 23210.3 +/- 1.36739
p1 = -12.0737 +/- 0.000698405
p2 = -0.00598662 +/- 3.52969e-07
p3 = 3.15663e-06 +/- 1.76515e-10


Minimizer is Linear
Chi2 = 2068.52
NDf = 464
p0 = 3.48357e+06 +/- 634455
p1 = -5259.19 +/- 962.054
p2 = 2.64612 +/- 0.486262
p3 = -0.000443663 +/- 8.19242e-05 [/code]

Hi,

This is probably due to the fact that Minuit requires some initial parameter values. If these are too far off from the minimum, it is possible that it is stuck in a local one. In your case it is also possible that numerical errors creates this effect. I would translate either the graph or the function to center the parameters more around 1.
For example I would try to fit a polynomial function defined as:

TF1 * f = new TF1("f","[0]+[1]*(x-2000.)+[2]*(x-2000)**2+[3]*(x-2000)**3") 

Lorenzo

The trick with “X axis scaling” works. Is there any way I can “test” whether the problem is related to “numerical errors” or to “initial parameters”?

There’s another stupid problem.
I use the “Fit Panel”, I select “pol3” then “Fit” (“Linear fit” is “checked” by default in this case).
Then I “uncheck” the “Linear fit” and “Fit” it again (“Minuit” is used then).
The parameters are not changed at all, but see their errors …

[code]Minimizer is Linear
Chi2 = 2068.52
NDf = 464
p0 = 3.48357e+06 +/- 634455
p1 = -5259.19 +/- 962.054
p2 = 2.64612 +/- 0.486262
p3 = -0.000443663 +/- 8.19242e-05


Minimizer is Minuit / Migrad
Chi2 = 2068.52
NDf = 464
Edm = 1.10297e-12
NCalls = 57
p0 = 3.48357e+06 +/- 1.32101
p1 = -5259.19 +/- 0.000674717
p2 = 2.64612 +/- 3.40996e-07
p3 = -0.000443663 +/- 1.70527e-10 [/code]

Hi,

Normally you suspect numerical errors when the Hessian matrix is ill conditioning. In your case due to different scales in the parameters (very large p0) you can suspect this. It is always better un general to transform the parameter such as their scale is close to 1.
The huge difference you get in the error again is again due to the numerical errors.
I have tried now by defining the function as:

TF1 * f1 = new TF1("f1","1++(x-2000.)++ (x-2000)**2++ (x-2000)**3") 
Graph->Fit(f1);  // Linear fit
Graph->Fit(f1,"F");  // Minuit fit 

Using this signature, you can use both Minuit or the Linear fitter (which is the default) since the function is recognized as linear in this case.
Using that formula you get compatible results in parameter values and errors

****************************************
Minimizer is Linear
Chi2                      =      2066.56
NDf                       =          464
p0                        =      366.922   +/-   0.565177    
p1                        =      1.27525   +/-   0.107751    
p2                        =   -0.0195835   +/-   0.00567865  
p3                        = -0.000501481   +/-   8.70244e-05 
(class TFitResultPtr)140493937182128
root [4] Graph->Fit(fl,"F")

****************************************
Minimizer is Minuit / Migrad
Chi2                      =      2066.56
NDf                       =          464
Edm                       =  1.07516e-17
NCalls                    =           49
p0                        =      366.922   +/-   0.565173    
p1                        =      1.27525   +/-   0.10775     
p2                        =   -0.0195835   +/-   0.00567859  
p3                        = -0.000501481   +/-   8.70234e-05 

Lorenzo

Is there any “test” I can perform (after the fit converged) in order to get the “quality” of the returned “estimated errors”?
(Well, I know there’s a paragraph called “Reliability of Minuit Error Estimates” in the “5 Fitting Histograms” chapter of the “User’s Guide”, but it doesn’t give any “automatic” way to get the “quality” - one needs to “manually” check several points, but I’m been thinking about a function which would return a single value that one could check, after doing the fit, in an “automatic” way in the source code.)

HI,

If you are using Minuit or MInuit2 you can check the status code of the covariance matrix,
TFitResult::CovMatrixStatus() and it must be 2 or 3.
But the best test for the errors is to run Minos. If it succeeds normally the errors returned are reliable.

Best Regards

Lorenzo

It seems to me that many methods of the TFitResult class (including the “TFitResult::CovMatrixStatus()”) can be called “without object”, like they were static methods referencing a global static object.
I was thinking that that object keeps the result from the very last “Fit” call, but when I try it, I get segmentation violations, e.g.:
root [0] TFitResult::MinimizerType()
*** Break *** segmentation violation
Do I need to “initialize” that object somehow?
(Well, when one calls a non-static method this way, one should get an “Error: cannot call member function without object (tmpfile):1:”, not a segmentation violation.)

Hi,

That method is not a static function of TFitResult, so you cannot called without the object. You can get the fit result when fitting using the “S” option.

TFitResultPtr result = h1->Fit( myFunction, "S");
int covStatus =  result->CovMatrixStatus();

Lorenzo

Yes, that’s what I do with the “TFitResultPtr”, too.
So, it’s a bug in CINT that it allows to call many TFitResult methods as “static” (I just wanted to make sure).

[quote]So, it’s a bug in CINT that it allows to call many TFitResult methods as “static” (I just wanted to make sure).[/quote]Yes, it is an unfortunate deficiency in CINT :frowning:

Cheers,
Philippe.