Repository navigation
Add opt-in BigDecimal support for precise numeric evaluation - #2
Merged
Merged
Conversation
Preserve arbitrary-precision JSON numbers and expression literals with the bigdecimal feature. Use decimal arithmetic in numeric functions and operators, with precise comparisons, sorting, hashing, and serialization. Accept decimal strings in numeric functions and return string results when string operands are supplied, while keeping the default behavior unchanged. Add regression coverage for issue #1, precision boundaries, rounding, mixed inputs, bindings, and invalid arguments. Correct the example's expected total to 300.55. Document precision and power/rounding limits and run both feature configurations in CI. Validation: workspace tests, Clippy with warnings denied, formatting, and documentation builds pass. The compatibility report retains four existing failures; decimal mode adds nine expected semantic differences. Refs #1
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing: 23
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Closed
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.
JSON numbers currently pass through
f64, losing precision, and numeric functions reject the decimal strings in #1. This adds an optionalbigdecimalfeature that enablesserde_json/arbitrary_precisionand preserves decimal values through numeric evaluation. Default behavior remains unchanged.The paid-order example now returns
"300.55":100.30 + 200.25 = 300.55(the issue's expected"300.95"is an arithmetic typo).$numberexplicitly converts strings to numbers.Local validation passed: workspace tests with the feature disabled and enabled, Clippy with warnings denied in both configurations, formatting, documentation builds, and the README example's regression test.
The existing JSONata compatibility runner reports failures without failing its test command. Default mode reports 1,027 passing cases, 4 existing failures, and 549 skipped cases. Decimal mode reports 1,018 passing cases, 13 failures, and 549 skipped cases: the same 4 existing failures plus 9 expected differences from accepting numeric strings, supporting numbers outside the
f64range, and preserving string-conversion precision.Documented limits: inexact operations follow BigDecimal's precision rules (normally 100 significant digits);
$powersupports integer and half-integer exponents and returnsD3061for other fractional exponents;$rounduses half-even rounding with precision from -10,000 to 10,000.$randomretains its existing behavior. Inputs already rounded through Rust floating-point literals cannot regain lost precision.Refs #1.