When creating a histogram from a TF1 via TF1->GetHistogram(), the function is evaluated at the bin centers as I would expect. However, when saving the TF1 to a file via TF1->Write(), the function is evaluated at the bin edges instead.
So, when creating the histogram or drawing from the saved TF1, one doesn’t get the same result as the unsaved TF1 because the function must be interpolated between the saved evaluations at the bin edges. It’s not a matter of increasing Npx - if the function were evaluated at the bin centers when saving the TF1, there would be no discrepancy.
As an example, run the attached TF1_test.C, quit ROOT, then run the attached TF1_test2.C. The resulting plot illustrates the difference between the histogram obtained from the original (unsaved) TF1 and the saved TF1 itself.
I first noticed this behavior in v5_14, but it’s also present in v5_22 (Unix and Windows). Thanks for any help addressing this problem. TF1_test2.C (145 Bytes) TF1_test.C (871 Bytes)
we are aware of this small problem (visible when setting Npx to small values).
The idea was to draw the function as much as possible in the full range from [xmin,xmax] and not from [xmin+0.5dx, xmax-0.5dx].
Changing this at this point is difficult as we will have to introduce a special case when reading old or new files or reading files produced by new versions of ROOT using old versions.
It may be a small problem, but it caused considerable confusion and effort to understand it. In my case, I had saved the resulting distributions from a fit into TF1s. When comparing the data to those saved TF1s bin-by-bin, it appeared the fit was not describing the data very well. But, the problem was simply the small differences caused by the interpolation between points in the saved TF1. My data sample has large statistics, so even a small discrepancy in the fitted distribution can appear statistically significant, especially in a “residual” distribution. Comparing the data to results in an UNsaved TF1 were “correct” and as expected.
My chosen Npx (and dx) are appropriate given the experimental resolution. In some cases, I’m already using Npx = several hundred and evaluating the TF1s for complicated PDFs takes a lot of time (hours).
Saving TF1s is pointless for me since I can’t get the right answer with them. I may be able to use saved histograms obtained from the unsaved TF1 instead.
I’ve seen at least several other posts describing what I think is this same problem, so I think it would be worthwhile to pursue a fix. At the very least, the TF1 documentation could include a caveat that writing a TF1 to a file doesn’t save the same points that it uses when drawing. Perhaps providing an option to write the TF1 evaluated either at the bin centers or edges is one way to work around compatibility issues between versions. Another idea is just to automatically evaluate the TF1 at both bin edges and centers when writing it. Regardless, having the different behavior before and after saving is, well, aggravating.
Could you send a concrete case showing the problem and where setting a high value for Npx does not solve the problem.
Note that the main purpose of saving the function tabulated at Npx points is only for visualization purposes. If you need the exact values, you should of course start from the original mathimatical function.