fix: preserve operand width in DecimalValue checked arithmetic#7380
fix: preserve operand width in DecimalValue checked arithmetic#7380abnobdoss wants to merge 7 commits into
Conversation
…thmetic (vortex-data#7022) Signed-off-by: Abanoub Doss <abanoub.doss@gmail.com>
|
I256 is not the maximum of the inputs. I would accept a PR doing this |
|
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 |
|
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
| 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 { |
There was a problem hiding this comment.
Can we signify the upcast
| macro_rules! checked_binary_op { | |
| macro_rules! checked_widening_binary_op { |
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
|
Thank you @joseph-isaacs! I've updated the PR per the comments. |
Signed-off-by: abnobdoss <abanoubdoss@gmail.com>
|
Hi @joseph-isaacs, could you please take a look when you get a chance? |
|
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 |
|
Hi @joseph-isaacs, could you please take a look when you get a chance? |
3 participants
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).