<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>How are you determining this tagger weight? I would be
interested to know how that works. <br>
</p>
<p><br>
</p>
<p> - Paul<br>
</p>
<br>
<div class="moz-cite-prefix">On 02/25/2017 08:56 AM, Richard Jones
wrote:<br>
</div>
<blockquote
cite="mid:CABfxa3TM7LUZkz5pP_K3ZBhV3wL7MyXx6bt_yWREhtzKYpU0Jw@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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
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="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 moz-do-not-send="true" class="m_-3577612556481807005moz-txt-link-abbreviated" href="mailto:Halld-offline@jlab.org" target="_blank">Halld-offline@jlab.org</a>
<a moz-do-not-send="true" 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>
</div>
</blockquote></div>
</div>
</blockquote>
</body></html>