<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
No, he's right. With floats you only have 23 bits for the
significand (1 for sign, 8 for exponent), meaning you only have 6 or
7 significant digits (2^23). Then you can't increment by one any
more. <br>
<br>
- Paul <br>
<br>
<div class="moz-cite-prefix">On 02/25/2017 09:20 AM, Richard Jones
wrote:<br>
</div>
<blockquote
cite="mid:CABfxa3TFBeeYjaZKFm5=JM_Uv=TvcaWi2fCTS+f9XYFFapWHQQ@mail.gmail.com"
type="cite">
<div dir="ltr"><span style="font-size:12.8px">Dominik,</span>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px">Such limits exist of course, but
this is NOT what I am reporting. The limit of IEEE 32-bit
floats is 3.4e+38. TH1F is not using ordinary float-type
values. It must be converting the floats to something less
than 32 bits (maybe 16 bits?) and trying to save space that
way.</div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px">-Richard J</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Feb 25, 2017 at 9:15 AM,
Dominik Werthmueller <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:werthm@jlab.org"
target="_blank">werthm@jlab.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Dear
Richard<br>
<br>
This issue is not really a bug in ROOT but related to
general floating point arithmetics on computers. Basically
the difference between two representable numbers increases
as their values increase and it will exceed 1 at the limit
you mentioned. Hence adding 1 does not change the number
anymore.<br>
<br>
<a moz-do-not-send="true"
href="https://root-forum.cern.ch/t/maximum-histogram-bin-content/5891/2"
rel="noreferrer" target="_blank">https://root-forum.cern.ch/t/<wbr>maximum-histogram-bin-content/<wbr>5891/2</a><br>
<a moz-do-not-send="true"
href="https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html"
rel="noreferrer" target="_blank">https://docs.oracle.com/cd/<wbr>E19957-01/806-3568/ncg_<wbr>goldberg.html</a><br>
<br>
Cheers,<br>
Dominik<br>
<div class="HOEnZb">
<div class="h5"><br>
> Am 25.02.2017 um 13:14 schrieb Richard Jones <<a
moz-do-not-send="true"
href="mailto:richard.t.jones@uconn.edu">richard.t.jones@uconn.edu</a>>:<br>
><br>
> Dear colleagues,<br>
><br>
> 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.<br>
><br>
> >> TH1F histograms silently truncate their
bin contents at 16,777,216 (2^28) <<<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
> -Richard Jones<br>
</div>
</div>
<div class="HOEnZb">
<div class="h5">> ______________________________<wbr>_________________<br>
> Halld-offline mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a><br>
> <a moz-do-not-send="true"
href="https://mailman.jlab.org/mailman/listinfo/halld-offline"
rel="noreferrer" target="_blank">https://mailman.jlab.org/<wbr>mailman/listinfo/halld-offline</a><br>
<br>
</div>
</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>