-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Fix BigDecimal#to_big_i
regression
#8790
Conversation
Since it's a pretty major regression it would be gr8 having this merged into |
|
||
bd1.to_u.should eq 0 | ||
bd2.to_u.should eq 0 | ||
bd3.to_u.should eq 123 | ||
bd4.to_u.should eq 123 | ||
bd5.to_u.should eq 123 |
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.
@bcardiff btw, why do Big*#to_u
methods for values < 0 are returning them as absolute instead of raising?
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.
That seems unexpected...
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 is the effect of time, when Int#to_u
used to be more like a cast, and BigDecimal#to_big_u
simple uses an .abs
as an approximation. Nobody submit any opinions regarding that in the original PR #4876 .
It should raise OverflowError
for negative inputs.
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.
Was thinking the same, although I'd leave it for another PR.
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.
For further consideration: All these specs don't really test what you would expect. Equality between different number types already works without explicit conversation. So these specs should also validate the return type.
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.
@straight-shoota Could we leave it for another PR? I don't think we should do much more here.
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.
Absolutely
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.
btw, BigInt#to_u
/ BigFloat#to_u
has the same issue:
require "big"
-123.to_big_i.to_u # => 123
-123.123.to_big_f.to_u # => 123
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.
The fix only works when all decimal places are zero.
This is still incorrect:
"-1.1".to_big_d.to_big_i # => -10
f5d0812
to
c96498f
Compare
@straight-shoota Force-pushed amended commit with the fix. |
Is it possible to (also) have a spec for |
Done. |
Is this GTG? |
Merge time? :) |
Yo! Anything else to do here? 🕦 Your PR-review process guys is a real mystery to me. You let tested, approved and tagged PRs lay idly with no explanation about the next steps or anything else that's suppose to come next... Could you be please more transparent in your actions, so it's less of a guessing-game and more of a understandable process - at least to the outsiders, who do not share your private communication channels or whatever you use to discuss things like that - if you do... |
Sadly, there's really no process in place. |
Thanks @Sija and sorry for the delay! |
Fixes #8789