Looking at your macro, it seems to me that you are using an ancient ROOT 5.
That is why the "P" fit option is ineffective.
In any case, you’d better clean up your macro so that you can use: .x test1.C++
BTW. To make your macro also ready for ROOT 6, you will need to replace:
area = function->Integral(a, b, params);
with:
function->SetParameters(params); area = function->Integral(a, b);
Don’t make me cry again. My laptop was broken, so I had to use my ancient DELL. There is ONLY windows 10 installed on it. I was doing everyting with .x test1.C++ style on linux before, but it doesn’t work in that way () on windows right now (I guess) due to the exe I used from ROOT website .
I think I used to installation method stated here down there in the last part.
BTW, I already use area = function->Integral(a, b);
For instance, what is the result in your computer, can you post it to me. I assume you haven’t seen any error or logic mistake in the code, have you?
I only looked at the source code. I wasn’t able to run your macro with ROOT 6 so I gave up.
My root version: root_v5.34.36.win32.vc12
I don’t have any clue why I can run but not compile and run in my version now.
I used to write as I was doing before in linux. Not sure, why your computer cannot run.
It seems there is ROOT6 for windows here. Let me give it a try.
It seems root 6 is installed and giving too many errors after running. Very nice 
A slightly modified version is attached below (just to make it ROOT 6 and C++ compiler ready).
You can now play with different fit options and compare the results (note that the “real” shape of the “background” is usually not a simple straight line and the “real” shape of the “signal” is usually not a simple gaussian).
test1.C (10.9 KB)
Alright, back to the business. I installed root6 in Ubuntu as subsystem in windows 10. It took 7hours to install and compile root6. Insane!
When I compile and run with “.x …cpp++” , everything works now.
Cheers.
“Fit data is empty” suggests that the macro did not find the input data file (so the histogram is empty).
I see. That was my first time to use ubuntu like an application on windows.
I figured out the correct PATH, now it worked. Let me investigate.
I am happy to see that I can compile + run now finally and properly.
BTW, it turns out the correct PATHs are:
file.open("/mnt/c/root-6-24-06-build/macros/Co60.txt", ios::in);
//ON UBUNTU While running WINDOWS
///file.open(“C:\root-6-24-06-build\macros\Co60.txt”, ios::in);
//ON WINDOWS ROOT terminal
For some reason, I had to install Xming X server for visualization. Also, I had to type : export DISPLAY=“localhost:0” before entering the root.
Is there any another way to get the visualization working when I just run the code.Plus, background area style looks different than before.
Alright, I can turn back to my discussion again since root6 issue an compilation issues are done.
Before starting the analysis, I did some assumptions. Actually, I try many methods all together to compare the results. Anyway, I know the peaks might not even be a Gaussian or the backgrounds might be some quadratic polynomials in higher degrees. Putting all aside as options, my purpose is not the test all now.
My main goal at the moment is to compare the basics. For instance, I want to compare the histogram results for gross , background and net areas with the results of ROOT fittings through the functions.
All I see is that they differ if I don’t fix my parameters. When I do, I loose the errors in return.
The conclusion is that SHOULD I accept the ROOT results as OK? or SHOULD I find a new method which I think I did?
BTW, here are some results again:
Form fitting: TFitResultPtr r_total = h1->Fit(total, “EMRS”);
From histogram:
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:
TH1F or TH1D, which one is more suitable to the data?
I got round of error on gross area 1, how can be fixed? I’ll attach the terminal view.
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?
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.
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?
