[treeplayer] Evaluate long through long double in Scan and report values that can't be printed exactly#22620
Open
guitargeek wants to merge 2 commits into
Open
[treeplayer] Evaluate long through long double in Scan and report values that can't be printed exactly#22620guitargeek wants to merge 2 commits into
long through long double in Scan and report values that can't be printed exactly#22620guitargeek wants to merge 2 commits into
Conversation
TTree::Scan prints each column with TTreeFormula::PrintValue, which
evaluates it in a floating-point accumulator. The "long" integer format
("ld"/"lu") used a double, whose 53-bit mantissa rounds any 64-bit
integer above 2^53, whereas the "long long" format ("lld"/"llu") already
used a long double. Promote "ld"/"lu" to long double as well, so that on
platforms where long double is wide enough -- e.g. x86-64, with a 64-bit
mantissa -- the full 64-bit value prints exactly, consistently with the
"long long" format.
This deliberately does NOT switch the evaluation to a 64-bit *integer*
accumulator, even though that would represent every value exactly.
TTreeFormula evaluates every column through a single numeric accumulator
whose type defines the arithmetic, and that arithmetic has always been
floating point. Carrying integers instead would silently change
long-standing, effectively frozen semantics:
- "x/2" would become integer division instead of floating division;
- literal constants would be truncated ("x*0.5" -> "x*0");
- division and modulo of unsigned values above 2^63 would differ,
because the evaluation is signed.
No accumulator type is simultaneously exact for every 64-bit integer and
faithful to the existing floating-point arithmetic; the two goals are
mutually exclusive for exactly the values at stake. Widening the float
keeps the arithmetic bit-for-bit identical while extending the range of
integers that are printed exactly.
🤖 Done with the help of [Claude Code](https://claude.com/claude-code) (Claude Opus 4.8)
guitargeek
changed the title
long Scan format through long double and report integer values that still can' be printed exactly
guitargeek
changed the title
long Scan format through long double and report integer values that still can' be printed exactly long Scan format through long double and report values that still can't be printed exactly
guitargeek
changed the title
long Scan format through long double and report values that still can't be printed exactly long values through long double in Scan and report values that can't be printed exactly
guitargeek
changed the title
long values through long double in Scan and report values that can't be printed exactlylong through long double in Scan and report values that can't be printed exactly
Even evaluated through long double, an integer column can still exceed the accumulator's exactly-representable range: above 2^53 where long double is merely a 64-bit double (e.g. macOS ARM), or beyond 2^64 for results that overflow. As explained in the preceding commit, this cannot be fixed without changing TTreeFormula's frozen floating-point arithmetic, so it is a genuine known limitation, not a bug to work around -- but it must not pass silently. TTreeFormula::PrintValue now emits an error whenever the value it is about to print as an integer has reached the point where the long double accumulator can no longer hold every integer exactly, so the printed digits may be rounded. The diagnostic is deliberately a kError, issued for every offending value with no deduplication: silently printing a wrong integer is precisely the trap we want to surface as loudly as possible, even on a many-row Scan. The threshold check is inclusive (>= 2^digits) on purpose: a rounded result can land back exactly on the threshold (e.g. 2^53 + 1 -> 2^53 in a 53-bit type), and an inclusive comparison avoids missing those. Closes root-project#7844. 🤖 Done with the help of [Claude Code](https://claude.com/claude-code) (Claude Opus 4.8)
pcanal
reviewed
Jun 15, 2026
Comment on lines
+5116
to
+5117
| LongDouble_t v = ((TTreeFormula *)this)->EvalInstance<LongDouble_t>(instance); | ||
| CheckIntegerPrintPrecision(v, GetTitle()); |
Member
There was a problem hiding this comment.
Consider
Suggested change
| LongDouble_t v = ((TTreeFormula *)this)->EvalInstance<LongDouble_t>(instance); | |
| CheckIntegerPrintPrecision(v, GetTitle()); | |
| if (this->IsInteger()) { | |
| Long64_t vi = ((TTreeFormula *)this)->EvalInstance<Long64_t>(instance); | |
| snprintf(value, kMAXLENGTH, Form("%%%s", decform), vi); | |
| } else { | |
| LongDouble_t v = ((TTreeFormula *)this)->EvalInstance<LongDouble_t>(instance); | |
| CheckIntegerPrintPrecision(v, GetTitle()); | |
| snprintf(value, kMAXLENGTH, Form("%%%s", decform), (Long64_t)v); | |
| } |
except we probably can not tell the difference between signed and unsigned :(
Test Results 21 files 21 suites 3d 14h 11m 8s ⏱️ For more details on these failures, see this check. Results for commit 27cbd7b. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TTree::Scancould silently round 64-bit integer columns, becauseTTreeFormulaevaluates them through a floating-point accumulator. This PR improves that in two ways, one per commit:"long"(ld/lu) format throughlong double, like the"long long"format already does, so the full 64-bit value prints exactly whereverlong doubleis wide enough (e.g. x86-64), without changing TTreeFormula's floating-point arithmetic.long double, or results overflowing 2⁶⁴), turning a silent rounding into a clear known-limitation diagnostic.See the individual commit messages for the full rationale, in particular why this is not fixed by evaluating over integers (it would change long-standing arithmetic semantics).
Closes #7844.
🤖 Done with the help of Claude Code (Claude Opus 4.8), although the problem and my requirements were so precisely specified that a less capable model could probably have reached the same result. The wording of inline comments and error messages was the only remaining degree of freedom.