ROOT.gStyle.SetOptFit(1111)

[L_N]

Hello,

I have a question regarding some fit results.
My problem is that the fit parameter shown in the final canvas, which includes the data, the fit and the fitparameters (for which I used ROOT.gStyle.SetOptFit(1111) and GetPrimitive(“stats”)) is not the same as extracted directly from the fit results via “fitfunction”.Parameter().
I used SetFitFormat(“5.10g”) since the fit parameter has at least 9 important decimal places.
The deviation of the two values is visible only at the last position after the decimal point.
Please let me know in case you have an idea what the problem could be.

Thanks in advance and cheers!

[Wile_E_Coyote]

Try with: "5.17g"
Dump your “extracted” fit results using, e.g.: printf("%5.17g\n", some_parameter);

[L_N]

Thanks for your answer and suggestions.
I’m still getting the same values.
Do you have an other idea what I could try?
Thanks again and cheers!

[couet]

Do you have a small reproducer?

[Wile_E_Coyote]

A possible source could be mixing “double”/“Double_t” and “float”/“Float_t” variables.

[L_N]

Hi again,

here is a short overview on the code:

ROOT.gStyle.SetOptTitle(0);
ROOT.gStyle.SetOptStat(0);
ROOT.gStyle.SetOptFit(1111);
ROOT.gStyle.SetStatBorderSize(0);

Datareadin=float(data[j])
mc = ROOT.TCanvas(“fit”, “fit”, 1024, 200, 700, 500)
graph = ROOT.TGraphErrors(n, ff, sig, ROOT.nullptr, sigErr)
rfitfunc = ROOT.TF1(“rfit”, fitfunc, min, max, npars)
/set fit parameter etc
fitresults = graph.Fit(rfitfunc, “QERMBS”)
/save fit results in file via fitresults.Parameter()
graph.Draw(“APE”)
mc.Update()

ps = mc.GetPrimitive(“stats”)
ps.SetFitFormat(“5.15f”)
ps.SetStatFormat(“6.4f”)
mc.Modified()
mc.Update()

---

Saved fit results are not the same as the one shown in the canvas.

[Wile_E_Coyote]

So, what exactly do you get “in the canvas” versus “saved in a file” (e.g., do you get 15 decimal digits precision in both cases?).

[L_N]

I get i.e. 1.4301894903 (canvas with ps.SetFitFormat(“5.11g”)) and 1.4301894936 in the file.
And I’m using also an optimizer (ROOT.Math.MinimizerOptions.SetDefaultPrecision(1e-18)) in case that’s important.

[Wile_E_Coyote]

@couet It seems there is a bug in TPaveStats … it internally converts the original “double”/“Double_t” values into “float”/“Float_t” (which are then displayed).

Try: ((float)1.4301894936) - 1.4301894903f

[couet]

@Wile_E_Coyote @L_N : do you have a reproducer showing the problem?

[Wile_E_Coyote]

Just “gStyle->SetFitFormat("5.17g");”, fit anything, and then:
printf("%5.17g %5.17g\n", f->GetParameter(0), ((float)f->GetParameter(0)));

[couet]

I made this:

Double_t fitf(Double_t *x, Double_t *par)
{
   return x[0]*x[0]*par[0]+x[0]*par[1];
}

void L_N()
{
   gStyle->SetOptFit(1111) ;

   const Int_t n = 4;
   Double_t x[n]= {0.3156, 1.0012, 1.4146, 8.4996};
   Double_t y[n]= {1.881, 5.899, 8.376, 50.239};

   auto gr = new TGraph(n,x,y);
   gr->Draw("A*");

   TF1 *f = new TF1("f", fitf,0, 9, 2);
   f->SetParameters(-0.01, 5.9);
   gr->Fit(f);
   printf("%5.17g %5.17g\n", f->GetParameter(0), ((float)f->GetParameter(0)));

}

****************************************
Minimizer is Minuit / Migrad
Chi2                      =  0.000799383
NDf                       =            2
Edm                       =  3.07171e-24
NCalls                    =           36
p0                        = -0.000278198   +/-   0.00159679  
p1                        =      5.91312   +/-   0.0132961   
-0.00027819773415341253 -0.00027819772367365658

Does it reproduce what you are complaining about?

[Wile_E_Coyote]

@couet Add: gStyle->SetFitFormat("5.17g");

[L_N]

Thanks a lot for your efforts.
Yes, could you please add SetFitFormat(“5.17g”) to check if you values also deviate?

[couet]

it seems so:

[couet]

If I remove the float casting I get:

[L_N]

Ok, what does that mean now exactly, so I guess f->GetParameter(0) is wrong and the float casting is needed?

[couet]

is the 2nd output right ?

[L_N]

Please let me know what you think and how to proceed. Are the values extracted via f->GetParameter not trustworthy?

[couet]

@L_N

f->GetParameter not trustworthy?

Yes they are