[ruby-core:61788] [ruby-trunk - Bug #9689] [Open] (BigDecimal + Float) no longer commutative due to #7176

[ruby-core:61788] [ruby-trunk - Bug #9689] [Open] (BigDecimal + Float) no longer commutative due to #7176

[saurik]

Issue #9689 has been reported by Jay Freeman.

----------------------------------------
Bug #9689: (BigDecimal + Float) no longer commutative due to #7176
https://bugs.ruby-lang.org/issues/9689

* Author: Jay Freeman
* Status: Open
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
* ruby -v: ruby 2.0.0p299 (2013-08-29) [x86_64-linux-gnu]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
So, there was a bug filed a while back (#7176) about Rational + BigDecimal failing, despite BigDecimal + Rational working.

https://bugs.ruby-lang.org/issues/7176

When this bug was fixed (in r37406), the new BigDecimal#+ also (I believe unnecessarily) converts Float to BigDecimal, making BigDecimal + Float return a BigDecimal despite Float + BigDecimal returning a Float. Given that work was put in to make BigDecimal + Rational commutative it seems like the same behavior should be in place for BigDecimal + Float: preferably, either both should be commutative, or neither should be commutative. (Please understand that I filed this as a "Bug", as this seems like a regression from the earlier behavior, but I would not at all quibble if someone decided that this should actually be classified as a "Feature" instead.)

(BTW, while doing due diligence on this issue, I determined that there was a previous bug #2129 that was filed against Rational + BigDecimal years ago that has almost the same description as 7176. At the time, Rational + BigDecimal returned a Rational; I think this is the more correct behavior, because any BigDecimal can be represented as a Rational, but not all Rationals can be represented as a BigDecimal. As a concrete example, 1/9 has no BigDecimal representation. Given that this behavior has already changed before, it seems like a fix for the commutativity of Float+BigDecimal should probably also deal with this other problem.)

https://bugs.ruby-lang.org/issues/2129



-- 
https://bugs.ruby-lang.org/

[ruby-core:63810] [ruby-trunk - Bug #9689] (BigDecimal + Float) no longer commutative due to #7176

[muraken]

Issue #9689 has been updated by Kenta Murata.

Assignee set to Kenta Murata

----------------------------------------
Bug #9689: (BigDecimal + Float) no longer commutative due to #7176
https://bugs.ruby-lang.org/issues/9689#change-47849

* Author: Jay Freeman
* Status: Open
* Priority: Low
* Assignee: Kenta Murata
* Category: 
* Target version: 
* ruby -v: ruby 2.0.0p299 (2013-08-29) [x86_64-linux-gnu]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
So, there was a bug filed a while back (#7176) about Rational + BigDecimal failing, despite BigDecimal + Rational working.

https://bugs.ruby-lang.org/issues/7176

When this bug was fixed (in r37406), the new BigDecimal#+ also (I believe unnecessarily) converts Float to BigDecimal, making BigDecimal + Float return a BigDecimal despite Float + BigDecimal returning a Float. Given that work was put in to make BigDecimal + Rational commutative it seems like the same behavior should be in place for BigDecimal + Float: preferably, either both should be commutative, or neither should be commutative. (Please understand that I filed this as a "Bug", as this seems like a regression from the earlier behavior, but I would not at all quibble if someone decided that this should actually be classified as a "Feature" instead.)

(BTW, while doing due diligence on this issue, I determined that there was a previous bug #2129 that was filed against Rational + BigDecimal years ago that has almost the same description as 7176. At the time, Rational + BigDecimal returned a Rational; I think this is the more correct behavior, because any BigDecimal can be represented as a Rational, but not all Rationals can be represented as a BigDecimal. As a concrete example, 1/9 has no BigDecimal representation. Given that this behavior has already changed before, it seems like a fix for the commutativity of Float+BigDecimal should probably also deal with this other problem.)

https://bugs.ruby-lang.org/issues/2129



-- 
https://bugs.ruby-lang.org/

[ruby-core:64060] [ruby-trunk - Bug #9689] [Assigned] (BigDecimal + Float) no longer commutative due to #7176

[e]

Issue #9689 has been updated by Zachary Scott.

Category set to ext
Status changed from Open to Assigned
Target version set to current: 2.2.0

----------------------------------------
Bug #9689: (BigDecimal + Float) no longer commutative due to #7176
https://bugs.ruby-lang.org/issues/9689#change-48070

* Author: Jay Freeman
* Status: Assigned
* Priority: Low
* Assignee: Kenta Murata
* Category: ext
* Target version: current: 2.2.0
* ruby -v: ruby 2.0.0p299 (2013-08-29) [x86_64-linux-gnu]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
So, there was a bug filed a while back (#7176) about Rational + BigDecimal failing, despite BigDecimal + Rational working.

https://bugs.ruby-lang.org/issues/7176

When this bug was fixed (in r37406), the new BigDecimal#+ also (I believe unnecessarily) converts Float to BigDecimal, making BigDecimal + Float return a BigDecimal despite Float + BigDecimal returning a Float. Given that work was put in to make BigDecimal + Rational commutative it seems like the same behavior should be in place for BigDecimal + Float: preferably, either both should be commutative, or neither should be commutative. (Please understand that I filed this as a "Bug", as this seems like a regression from the earlier behavior, but I would not at all quibble if someone decided that this should actually be classified as a "Feature" instead.)

(BTW, while doing due diligence on this issue, I determined that there was a previous bug #2129 that was filed against Rational + BigDecimal years ago that has almost the same description as 7176. At the time, Rational + BigDecimal returned a Rational; I think this is the more correct behavior, because any BigDecimal can be represented as a Rational, but not all Rationals can be represented as a BigDecimal. As a concrete example, 1/9 has no BigDecimal representation. Given that this behavior has already changed before, it seems like a fix for the commutativity of Float+BigDecimal should probably also deal with this other problem.)

https://bugs.ruby-lang.org/issues/2129



-- 
https://bugs.ruby-lang.org/

[ruby-core:78574] [Ruby trunk Bug#9689][Closed] (BigDecimal + Float) no longer commutative due to #7176

[muraken]

Issue #9689 has been updated by Kenta Murata.

Status changed from Assigned to Closed

This is fixed in the latest master branch of [ruby/bigdecimal](https://github.com/ruby/bigdecimal).

----------------------------------------
Bug #9689: (BigDecimal + Float) no longer commutative due to #7176
https://bugs.ruby-lang.org/issues/9689#change-61959

* Author: Jay Freeman
* Status: Closed
* Priority: Normal
* Assignee: Kenta Murata
* ruby -v: ruby 2.0.0p299 (2013-08-29) [x86_64-linux-gnu]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
So, there was a bug filed a while back (#7176) about Rational + BigDecimal failing, despite BigDecimal + Rational working.

https://bugs.ruby-lang.org/issues/7176

When this bug was fixed (in r37406), the new BigDecimal#+ also (I believe unnecessarily) converts Float to BigDecimal, making BigDecimal + Float return a BigDecimal despite Float + BigDecimal returning a Float. Given that work was put in to make BigDecimal + Rational commutative it seems like the same behavior should be in place for BigDecimal + Float: preferably, either both should be commutative, or neither should be commutative. (Please understand that I filed this as a "Bug", as this seems like a regression from the earlier behavior, but I would not at all quibble if someone decided that this should actually be classified as a "Feature" instead.)

(BTW, while doing due diligence on this issue, I determined that there was a previous bug #2129 that was filed against Rational + BigDecimal years ago that has almost the same description as 7176. At the time, Rational + BigDecimal returned a Rational; I think this is the more correct behavior, because any BigDecimal can be represented as a Rational, but not all Rationals can be represented as a BigDecimal. As a concrete example, 1/9 has no BigDecimal representation. Given that this behavior has already changed before, it seems like a fix for the commutativity of Float+BigDecimal should probably also deal with this other problem.)

https://bugs.ruby-lang.org/issues/2129



-- 
https://bugs.ruby-lang.org/