Repository navigation
fix: compare integral numbers exactly instead of via double - #843
Merged
ebussieres merged 1 commit intoOct 19, 2026
Merged
ebussieres merged 1 commit into
ebussieres merged 1 commit into
Conversation
Number comparisons routed every operand through doubleValue(), so two distinct values above 2^53 compared equal: 325055142682428416 == ...417 evaluated true. Integral pairs (Long, Integer, Short, Byte) now compare with longComparison, BigDecimal/BigInteger via compareTo, and only floating-point operands keep the double path, matching Java's own numeric promotion. Binary operations route BigInteger through bigDecimalOperation too; previously it fell through to integerOperation and wrapped on intValue. The BigDecimal operand conversion now uses toString instead of doubleValue, keeping exact precision for integral inputs. Closes PebbleTemplates#595
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
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.
Closes #595.
What was broken
wideningConversionBinaryComparisonrouted every operand throughdoubleValue(), so325055142682428416 == 325055142682428417evaluated totruein templates (both collapse to the same double above 2^53). Related,wideningConversionBinaryOperationsentBigIntegeroperands throughintegerOperation(intValue()truncation) and convertedBigDecimalpairs viadoubleValue(), losing precision for integral inputs.Fix
Mirroring Java's numeric promotion in
wideningConversionBinaryComparison:BigDecimal/BigIntegeroperand → exactcompareToDouble/Floatoperand → double comparison (unchanged)Long/Integer/Short/Byte) → exactlongcomparisonIn
wideningConversionBinaryOperation:BigIntegernow joins theBigDecimalbranch, and the operand conversion usestoString-basedtoBigDecimal(exact for integral inputs, identical toBigDecimal.valueOffor doubles).Tests
Three new cases in
OperatorUtilsTest: large-long equality/ordering, BigInteger+BigDecimal exactness, andBigInteger + 1no longer wrapping pastLong.MAX_VALUE.mvn -pl pebble test: 1012 tests, 19 failures all inEmbedTagTest, which fails identically on a clean checkout (missing embed resources in this environment).