<div dir="ltr">Hello Paul,<div><br></div><div>Thank you, that is a good suggestion. I use weighted spectra for just about all spectra I create, so for that TH1I is not so useful. However in some of the use cases I covered in my message, a TH1I would do just as well.</div><div><br></div><div>For example, simply using a tagger_weight in filling your histograms would immediately give you automatic tagger accidentals subtraction. That is how I do it in my analyses. The non-Poisson errors are automatically accounted for by the TH1D. If you think that would be of general interest, I can offer to add a method to the DBeamPhoton that returns a tagger weight. It would be part of the calibration cycle to establish the correct bounds for the tagger trues and accidentals for each run.</div><div><br></div><div>-Richard Jones</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 25, 2017 at 8:33 AM, Paul Mattione <span dir="ltr"><<a href="mailto:pmatt@jlab.org" target="_blank">pmatt@jlab.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>I recommend using TH1I, since it uses half the memory of TH1D,
unless of course you need to fill a bin more than 2 billion times
(or the content could be that large after merging, or if you
anticipate dividing histograms, etc.). <br>
</p>
<p><br>
</p>
<p> - Paul<br>
</p><div><div class="h5">
<br>
<div class="m_-3577612556481807005moz-cite-prefix">On 02/25/2017 08:23 AM, Richard Jones
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">correction: "<span style="font-size:12.8px">That,
plus the fact that TH1F::Fill() is a couple orders of
magnitude slower than TH1F::Fill()" should be </span>
<div><span style="font-size:12.8px"><br>
</span></div>
<div><span style="font-size:12.8px">That, plus the fact that
TH1F::Fill() is a couple orders of magnitude slower than
TH1D::Fill(). </span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Feb 25, 2017 at 8:14 AM,
Richard Jones <span dir="ltr"><<a href="mailto:richard.t.jones@uconn.edu" target="_blank">richard.t.jones@uconn.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Dear colleagues,
<div><br>
</div>
<div>Maybe this is common knowledge to people more versed
in ROOT than I am, but this was a surprise to me, that
took me quite some effort to discover why my TTree
analysis was producing nonsense.</div>
<div><br>
</div>
<div>>> TH1F histograms silently truncate their bin
contents at 16,777,216 (2^28) <<</div>
<div><br>
</div>
<div>unless you fill with non-unity weights, in which case
they truncate at OTHER SMALL VALUES. To be specific, if
you create a TH1F histogram h1 and then do h1.Fill(0.)
repeatedly then this bin will silently stop incrementing
when the bin content reaches 1.677216e+7. If you fill it
with a non-unity weight then it will gradually lose
precision as the number of Fill calls on that bin
exceeds some threshold like a few M, and then silently
stop incrementing altogether when the bin content
reaches some limit. For w=100 I found this limit to be
2.147e+9. This was unexpected because the letter F in
TH1F implies "float" which has a max value about
3.4e+38. What use is a histogram object that silently
discards entries as soon as the count reaches some small
value that we expect to commonly hit in high-statistics
analysis? They must be doing some kind of
range-truncating-compression in the storage of TH1F bin
contents. Personally, I would rather get the right
answer, even if it means using more memory, but that's
just me.</div>
<div><br>
</div>
<div>A workaround would be never to use TH1F, always TH1D.
I have not been able to discover a similar silent
truncation in TH1D. That, plus the fact that
TH1F::Fill() is a couple orders of magnitude slower than
TH1F::Fill(). Apparently it takes a lot of cpu time to
generate bugs of this kind?</div>
<div><br>
</div>
<div>Meanwhile, beware. This is especially insidious
because the command tree.Draw("px") in your interactive
ROOT session implicitly creates and fills a TH1F, not a
TH1D, even if px is declared double in your tree. In my
present analysis, my tree has 200M rows, but in
principle that will bite you even if you have only 20M
rows in your tree. </div>
<span class="m_-3577612556481807005HOEnZb"><font color="#888888">
<div><br>
</div>
<div>-Richard Jones</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="m_-3577612556481807005mimeAttachmentHeader"></fieldset>
<br>
</div></div><pre>______________________________<wbr>_________________
Halld-offline mailing list
<a class="m_-3577612556481807005moz-txt-link-abbreviated" href="mailto:Halld-offline@jlab.org" target="_blank">Halld-offline@jlab.org</a>
<a class="m_-3577612556481807005moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-offline" target="_blank">https://mailman.jlab.org/<wbr>mailman/listinfo/halld-offline</a></pre>
</blockquote>
<br>
</div>
</blockquote></div><br></div>