Setting Parameter Limits, Fixing Parameters and Their effects on fitting

I know that part. Thus, you suggest me to play with , for instance, pol1 and pol2 to see which one is closer to the histogram results? Is there any right or wrong results at all? Or, is it all model dependent procedures?

Should I infer this from your answer? What do you guys do normally? Do you set one method as your reference or do you give all results together and let the people decide?

I surely assume that you will start your work with some pre-defined accepted assumptions. Right!

BTW, thanks for the enlightning discussion.

I think you should start to play with some “well-defined” histograms. That means running a simple, dedicated simulation (a “toy MC”) at least several times. Each time you run it, it will create a slightly different histogram, so you will get a “feeling” of how the fitting procedure behaves, as the “exact” parameters’ values will always be the same (and known, of course).

Political answers again. I see your “well-defined histograms" point if I am not mistakenly wrong. By creating the functions in advance and then filling the histogram, I think you get rid of the blur fog on the clarity of the histogram with unproved and unambigious peak shapes in advance. I guess it’s the same thing of saying that this is my accepted MODEL in the begining.

When you say “known and exact parameters”, we haven’t fix the parameters but just set the parameters in the beginning in your simulation code. Is it still regarded as fixed in that occasion?

My sincere appreciation to our discussion.

You can compare the “fitted” parameters (e.g., playing with different fit options) with the “true” ones (that were used to simulate the histogram, but note that each time you run the simulation, you will get a slightly different histogram).
Of course, for test purposes, you can also use one kind of background for the simulation but then a different type for fitting and so on.

No worries, I’ll play with all. That’s my job.

I noticed the Random filling method , no worries. For instance, all answers below are slightly different than each other.

Can you tell me what MinFCN, NDF, and edm stand for as words here on the terminal results?

I’ll have couple of follow up questions about the discussion for the update. I start to change the code’s approach a bit.

Problems in my mind:

  1. TH1F or TH1D, which one is more suitable to the data?

  2. I got round of error on gross area 1, how can be fixed? I’ll attach the terminal view.

  3. After all is done properly, I may fill the histogram with the integrals from functions instead of the real data. I think it will be pre-defined MODEL based analysis in that way. What is your thought about that?

image

DigitalIntegrationProcedures.cpp (10.4 KB)
(UPDATED)

Co60.txt (3.5 KB)

Cheers.

Try with: g...->IntegralError(..., 1e-6)

In your case, I don’t think it makes sense to try to “minimize” the RAM usage by using single-precision, instead of the default double-precision, floating-point format for histograms’ contents.

I forgot. Is this epsilon (1e-6) related to the precision of finding the mean? Should I keep playing with that number until the roundoff error is demolished? I found Moneta mentioned about that.

My conclusion: error disappears as I play with my integral limits. If I go from Lower bin 400 to upper bin 530, I see NO ERROR. Thus, it’s a matter of limits and the ability of fitting procedure within those limits. Am I right?

I see the terminal resuls and the fit result DONOT MATCH. First parameters of each gaussian should be the integral of those peaks due to the usage of Gausn, but the results give different outcomes comparison to parameter outcomes.

One more thing is that the broken line is not broken where I set the value. I want it to break at the bin number 462. Why is that?

What about my 3rd question?

If 1e-6 is still too small, try 1e-5.

The position of the “breakpoint” is a fitted parameter.

Yes, I think it is a good idea to start with a “well-known” histogram.

1 Like

What happens when I fix the break point parameter which I needed. Otherwise, it will be wrong.
I fixed it to the bin number 460, and it looks like OK.

However, the roundoff error 18 is so sensitive to the limits I choose. It only worked from 400 to 460 for the 1st peak and from 460 to 430 bin numbers for the 2nd peak.

Do you think that it’s totally OK to play with numbers until getting NO ERROR?

You can “fix” whatever parameter you want.

BTW. Note that the “area” parameter of a “gausn” is always its “full” integral. You integrate the function from some “xmin” to some “xmax”, so such “integral” will always be <= “area”.

When you say full integral, it is the value of this first part below: 1/sigma*squareRoot(2Pi) .
image
The integral, however , is the value below.

image

A bit confusing. When we fit gausn instead of gaus, do we tell somewhere in the code before it prints out the information, show the area as the 1st parameter. Obviously, the area is NOT equal to normalizating constant.

gROOT->GetFunction("gaus")->Print();
gROOT->GetFunction("gausn")->Print();

1 Like

It’s nice that I can see quicker like that instead of going through the ROOT website. I wasn’t aware. Thanks for that.


The word constant here is indeed the parameter p0 as we know. The height term in gaus.

That’s the website version.

image
image

To be normalized to 1, p0 here should be set to squareRoot(2xPi )x sigma in gaus.

Gausn is actually different than PDF of the Gaussian function as said on this website.

Ok. let me try my shot to explain my confusion.
In gaus, we give height as parameter, it draws the shape nicely. In gausn, we need to give area to be drawn. By looking at the histogram, I can easily give the hight but not the area. I need to calculate the area from height x sigma x sqrt(2 x Pi) . Isn’t it tiring?

Yeah, I am aware of that.

image
image

Here below, how p0 parameter turns to an area as a fit parameter after fitting?
image

When we find the integral and error, we use these two methods:

Should we not use these for gausn? Instead, should we just retrieve the parameter and its error, instead?

@Wile_E_Coyote
From terminal results, if I do gross area - background area with a calculator, it doesn’t match the ROOT net area result.

Is that normal!

Try:

{
  TF1 *f = (TF1*)gROOT->GetFunction("gausn");
  Double_t area = 100., mean = 0., sigma = 1.;
  f->SetParameters(area, mean, sigma);
  std::cout << "area = " << area << std::endl;
  for (Int_t i = 1; i < 10; i++)
    std::cout << i << " : " << area - f->Integral(mean - i * sigma, mean + i * sigma) << std::endl;
}

BTW. Make sure that you use:
total = g1 + g2 + bg
bg_g1 = total - g1 = g2 + bg (i.e., it’s always >= bg)
bg_g2 = total - g2 = g1 + bg (i.e., it’s always >= bg)

1 Like