Hi Rene,
the question is not about the precision, but in that the value
1.1111e+0 differs from 111111.0 for 5 orders. Be very careful with C
formatting, "%9.5" does not guarantee fixed width of the field, 9 is the
minimum width. In this case sign+dot+"e"+sign+order(3dig.) may give 7
characters which you should add to 5 "precision" digits. This gives up
to 12 chars on output for "%9.5g" format. Evidently this is the case
with the example in my post: 111111.0 gets printed as "1.1111e+05" which
is 10 characters long. And the last (most significant) character gets
truncated in the TTreePlayer::Scan which, "reformats" this string to
"%9.9s".
Cheers, Andy.
Rene Brun wrote:
>
> Hi Andy,
> There is a fixed format %9.5g in TTreeFormula::PrintValue.
> The idea is to get as many columns as possible on one page.
> This should be parametrized. Meanwhile, in br.C, you can evaluate
> your current value-1.111e+05
>
> Rene Brun
>
> Andrei Salnikov wrote:
> >
> > Hi all!
> >
> > Very simple and clear case, I believe. TTree::Scan seems to truncate
> > the printed numbers, giving sometimes a complete nonsense. E.g. I put
> > two numbers in the "D" leaf of some tree, namely 111100.0 and 111111.0
> > and get as the result:
> >
> > root [3] t.Scan("br.c");
> > ************************
> > * Row * br.c *
> > ************************
> > * 0 * 1.111e+05 *
> > * 1 * 1.1111e+0 *
> > ************************
> >
> > Note the missing "5" in the exponent of the second entry.
> >
> > Above was observed with the 2.23/12 on RH6.0.
> >
> > Cheers, Andy.
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:19 MET