Revert BigDecimal MathContext handling changes #7516
Conversation
This reverts commit ace11c0. We did the same thing before in 3a1332c to avoid problems such as scala/bug#4981 (back then) and scala/bug#11152 (now).
|
Down voted because it reverts infinite loops on simple |
Ichoran
left a comment
Ichoran
left a comment
There was a problem hiding this comment.
This isn't a viable strategy. The bug fixed in #6884 is a bug. Furthermore, if we don't care about math contexts, we shouldn't go to all the trouble of wrapping them together with BigDecimal and instead just provide extension methods for Java's versions. For example, you would expect that (2*x)/2 gives the same answer as (x + x)/2, but that isn't true with this reversion. (Even IEEE754, which is chock-full of surprises, isn't that surprising.)
That we in the past decided against using MathContexts for some operations in order to fix bugs elsewhere is not necessarily an indication that we should do so again.
I think instead that this is pointing that the idea of MathContext itself does not actually follow the principle of least surprise, and/or that NumericRange should know about BigDecimal and program defensively so that if it could possibly work it will work.
Note that BigDecimal(1) / BigDecimal(3) gives OOM if we don't use MathContext at all, which is pretty bad. So we need to address it somehow; I just don't think this is it--not in this simple of a form, anyway.
I'll discuss more options on scala/bug#11152.
|
I don't think reversion (alone) is enough, because it leaves surprising resource-gobbling behavior bugs in place (in contrast to expectation if you set precision). Feel free to reopen with a fix for that. Or I have an alternate way to fix scala/bug#11152 that solves that problem. |
5 participants
Fixes scala/bug#11152, supersedes #7236,
reverts #6884 ...and repeats 3a1332c