fix: preserve operand width in DecimalValue checked arithmetic#7380
Open
abnobdoss wants to merge 5 commits into
Open
fix: preserve operand width in DecimalValue checked arithmetic#7380abnobdoss wants to merge 5 commits into
abnobdoss wants to merge 5 commits into
Conversation
…thmetic (vortex-data#7022) Signed-off-by: Abanoub Doss <abanoub.doss@gmail.com>
Contributor
|
I256 is not the maximum of the inputs. I would accept a PR doing this |
Contributor
|
This PR has been marked as stale because it has been open for 14 days with no activity. Please comment or remove the stale label if you wish to keep it active, otherwise it will be closed in 7 days |
Author
|
Hi @joseph-isaacs, sorry not sure I understood - are you saying this change is fine? If so, what would the process be to get this approved / merged? |
github-actions
Bot
removed
the
stale
Comment on lines
+29
to
+30
| let a: T = $self.cast()?; | ||
| let b: T = $other.cast()?; |
| use crate::match_each_decimal_value_type; | ||
|
|
||
| /// Performs a checked binary operation at the wider of the two operand types. | ||
| macro_rules! checked_binary_op { |
Contributor
There was a problem hiding this comment.
Can we signify the upcast
Suggested change
| macro_rules! checked_binary_op { | |
| macro_rules! checked_widening_binary_op { |
Contributor
joseph-isaacs
left a comment
joseph-isaacs
left a comment
There was a problem hiding this comment.
Thanks for this sorry, for delay just a few small ones and we are good to go
…rt widening cast Address review feedback on vortex-data#7380: - Rename `checked_binary_op!` to `checked_widening_binary_op!` to make the upcast to the wider operand type explicit at call sites. - Replace `cast()?` with `vortex_expect`, since widening a `DecimalValue` to a type at least as wide as itself cannot fail. Signed-off-by: Abanoub Doss <abnobdoss@proton.me> Signed-off-by: Claude <noreply@anthropic.com>
Signed-off-by: Abanoub Doss <abnobdoss@proton.me> Signed-off-by: Claude <noreply@anthropic.com>
Improve error handling in decimal checked operations
Author
|
Thank you @joseph-isaacs! I've updated the PR per the comments. |
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
3 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.
Summary
Closes: #7022
DecimalValue::checked_add/sub/mul/divunconditionally upcast both operands toi256and returnedDecimalValue::I256, producing unnecessarily wide scalars even when both inputs were narrow (e.g.I32 + I32 → I256).Operate at
max(self, other)width instead, matching the pattern inaggregate_fn/fns/sum/decimal.rs. The oldchecked_binary_ophelper was replaced with a local macro so each op dispatches with its own trait.AI disclosure: Analysis, implementation, and tests were done with Claude Code under my direction and review.
API Changes
No public API signature changes (verified via
./scripts/public-api.sh).Overflow is now caught at the target width rather than silently widening (e.g.
I8(i8::MAX) + I8(1)now returnsNoneinstead ofI256(128)). This felt like the most faithful reading of the issue, but I'd appreciate a sanity check that returningNoneon target-width overflow is the desired semantics rather than, say, promoting to the next wider variant. No in-tree caller depends on the old behavior:sum/mod.rspre-widens the accumulator by +10 precision,decimal/scalar.rs::checked_binary_numericrequires both operands to share the same width, andsum/constant.rsusesI128as the multiplier.Testing
test_decimal_value_checked_*to assert the correct variant.i8::MIN / -1).