Project

General

Profile

Actions

Bug #2129

closed

Rational can't be coerced into BigDecimal (TypeError)

Added by kubo (Takehiro Kubo) almost 13 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
ruby -v:
ruby 1.9.2dev (2009-09-20 trunk 25012) [x86_64-linux]
Backport:
[ruby-core:25697]

Description

=begin
Rational + BigDecimal makes a Rational as follows:

$ ruby -rbigdecimal -e "puts Rational(1) + BigDecimal.new('1')"
2/1

But BigDecimal + Rationl raises a TypeError as follows:

$ ruby -rbigdecimal -e "puts BigDecimal.new('1') + Rational(1)"
-e:1:in +': Rational can't be coerced into BigDecimal (TypeError) from -e:1:in '
=end

Actions #1

Updated by nobu (Nobuyoshi Nakada) almost 13 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

=begin
Applied in changeset r25025.
=end

Actions #2

Updated by kubo (Takehiro Kubo) almost 13 years ago

=begin
Thanks for the fix not to raise a TypeError.

Well, ruby svn trunk 25031 calculate Rational and BigDecimal as follows:
Rational + BigDecimal -> Rational
BigDecimal + Rational -> BigDecimal

I think that it should be
Rational + BigDecimal -> Rational
BigDecimal + Rational -> Rational
or
Rational + BigDecimal -> BigDecimal
BigDecimal + Rational -> BigDecimal

I prefer the former.

=end

Actions #3

Updated by tadf (tadayoshi funaba) almost 13 years ago

=begin
BigDecimal can represent Infinity and NaN.

main@192-20090925> Rational(1,3) * BigDecimal('NaN')
TypeError: BigDecimal can't be coerced into Rational

=end

Actions #4

Updated by marcandre (Marc-Andre Lafortune) over 12 years ago

  • Category set to lib
  • Status changed from Closed to Open
  • Target version set to 1.9.2

=begin

=end

Actions #5

Updated by mame (Yusuke Endoh) about 12 years ago

=begin
Hi,

  • #1454 was registerd
  • r23389 was committed to fix #1454, but it was incomplete
  • #2129 (this ticket) was registered
  • r25025 was committed to fix #2129 correctly

Now, r23389 not only is unnecessary but also causes the
inconsistency of return type.

Thus, I'll fix this issue by reverting r23389.
By this revert, both will return BigDecimal.

diff --git a/ext/bigdecimal/bigdecimal.c b/ext/bigdecimal/bigdecimal.c
index 9930e63..2dd3213 100644
--- a/ext/bigdecimal/bigdecimal.c
+++ b/ext/bigdecimal/bigdecimal.c
@@ -602,14 +602,9 @@ BigDecimal_coerce(VALUE self, VALUE other)
ENTER(2);
VALUE obj;
Real *b;

  • switch (TYPE(other)) {
  •  case T_FLOAT:
    
  • if (TYPE(other) == T_FLOAT) {
    obj = rb_assoc_new(other, BigDecimal_to_f(self));
  •   break;
    
  •  case T_RATIONAL:
    
  •   obj = rb_assoc_new(other, BigDecimal_to_r(self));
    
  •   break;
    
  •  default:
    
  • } else {
    GUARD_OBJ(b,GetVpValue(other,1));
    obj = rb_assoc_new(b->obj, self);
    }

--
Yusuke Endoh
=end

Actions #6

Updated by mame (Yusuke Endoh) about 12 years ago

  • Status changed from Open to Closed

=begin
This issue was solved with changeset r27358.
Takehiro, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end

Actions

Also available in: Atom PDF