-
Notifications
You must be signed in to change notification settings - Fork 875
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cast: should get the round result for decimal to a decimal with smaller scale #3139
Conversation
949c6fd
to
fbc307d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should consistently use wrapping or checked add, neg, div, rem, etc... This not only is consistent with other kernels, but avoids differences between release and debug builds
arrow-cast/src/cast.rs
Outdated
let d = v / div; | ||
let r = v % div; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let d = v / div; | |
let r = v % div; | |
let d = v.wrapping_div(div); | |
let r = v.wrapping_rem(div); |
arrow-cast/src/cast.rs
Outdated
let d = v / div; | ||
let r = v % div; | ||
if v >= 0 && r >= half { | ||
d + 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
d + 1 | |
d.wrapping_add(1) |
arrow-cast/src/cast.rs
Outdated
if v >= 0 && r >= half { | ||
d + 1 | ||
} else if v < 0 && r <= neg_half { | ||
d - 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
d - 1 | |
d.wrapping_sub(1) |
arrow-cast/src/cast.rs
Outdated
@@ -1955,12 +1956,26 @@ fn cast_decimal_to_decimal_safe<const BYTE_WIDTH1: usize, const BYTE_WIDTH2: usi | |||
// For example, input_scale is 4 and output_scale is 3; | |||
// Original value is 11234_i128, and will be cast to 1123_i128. | |||
let div = 10_i128.pow((input_scale - output_scale) as u32); | |||
let half = div / 2; | |||
let neg_half = half.neg(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let neg_half = half.neg(); | |
let neg_half = half.wrapping_neg(); |
As we've divided by 2 this can't overflow
arrow-cast/src/cast.rs
Outdated
// TODO: it's better to implement the neg | ||
let neg_half = half * i256::from_i128(-1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// TODO: it's better to implement the neg | |
let neg_half = half * i256::from_i128(-1); | |
let neg_half = half.wrapping_neg(); |
The changes i have done will not overflow. |
Do you intend to switch to explicitly using wrapping / checked operations to ensure consistent behaviour across debug and release, and to be consistent with the other kernels? |
fbc307d
to
153781d
Compare
Sorry for the late reply, i forgot to push the changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there is a logical conflict with one of the tests for negative scales
Benchmark runs are scheduled for baseline = 2c86895 and contender = 187bf61. 187bf61 is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
Maybe I got your thought from this commit 2abbf89 But i need time to get the behavior of negative scale when we do cast in other system. |
123 |
I am confused about this, if the data type is decimal(10,-2) and the 128-bit integer is I think the 128-bit integer should be From the doc: https://arrow.apache.org/docs/python/generated/pyarrow.decimal128.html#pyarrow-decimal128
|
Apologies I misread your example, if the integer value was |
Which issue does this PR close?
Closes #3137
Rationale for this change
What changes are included in this PR?
Are there any user-facing changes?