<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body 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>
<br>
<div class="moz-cite-prefix">On 02/25/2017 08:23 AM, Richard Jones
wrote:<br>
</div>
<blockquote
cite="mid:CABfxa3QazO+uC4A1+GwN6eQsmj_f9mxHcSnd=Jr+mD0km4Si9Q@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>-Richard Jones</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Halld-offline mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-offline">https://mailman.jlab.org/mailman/listinfo/halld-offline</a></pre>
</blockquote>
<br>
</body>
</html>