Project

General

Profile

Actions

Feature #6958

closed

buggy BigDecimal#integer?

Added by adrianomitre (Adriano Mitre) over 11 years ago. Updated over 11 years ago.

Status:
Rejected
Target version:
-
[ruby-core:47386]

Description

=begin
BigDecimal#integer? always return false, which is wrong in many cases, as shown below.

x, y = BigDecimal('1'), BigDecimal('1.0')

x.integer?
#=> false

y.integer?
#=> false

x == x.to_i
#=> true

y == y.to_i
#=> true

Possible workaround

class BigDecimal
def integer?
self == self.to_i
end
end
=end

Actions #1

Updated by nobu (Nobuyoshi Nakada) over 11 years ago

  • Tracker changed from Backport to Feature
  • Project changed from Backport192 to Ruby master
  • Category changed from lib to lib

Currently BigDecimal does not define #integer? method.
It is Numeric#integer? and returns false always.

Possible options occur to me are:
(1) define BigDecimal#integer?
(2) change Numeric#integer?, like as your workaround.

It might be better to implement (1) together, if (2) is chosen.

Updated by nobu (Nobuyoshi Nakada) over 11 years ago

  • Description updated (diff)

Updated by nobu (Nobuyoshi Nakada) over 11 years ago

  • Status changed from Open to Rejected

I was wrong.

Numeric#integer? returns true if the receiver is an instance of integral class, or false.
BigDecimal is not an integral object, so it must return false always, as well as Float.

1.0.integer? #=> false

What you expect is not #integer? method.

Updated by regularfry (Alex Young) over 11 years ago

On 02/09/2012 05:45, nobu (Nobuyoshi Nakada) wrote:

Issue #6958 has been updated by nobu (Nobuyoshi Nakada).

Status changed from Open to Rejected

I was wrong.

Numeric#integer? returns true if the receiver is an instance of integral class, or false.
BigDecimal is not an integral object, so it must return false always, as well as Float.

That's an implementation detail, surely? Mathematically, isn't it true
to say that 1.0 (as understood by BigDecimal) is an integer? If so,
wouldn't a second method, #integral? be better for the case where you
want to know if a numeric is of an integral class?

--
Alex

1.0.integer? #=> false

What you expect is not #integer? method.

Feature #6958: buggy BigDecimal#integer?
https://bugs.ruby-lang.org/issues/6958#change-29134

Author: adrianomitre (Adriano Mitre)
Status: Rejected
Priority: High
Assignee:
Category: lib
Target version:

=begin
BigDecimal#integer? always return false, which is wrong in many cases, as shown below.

x, y = BigDecimal('1'), BigDecimal('1.0')

x.integer?
#=> false

y.integer?
#=> false

x == x.to_i
#=> true

y == y.to_i
#=> true

Possible workaround

class BigDecimal
def integer?
self == self.to_i
end
end
=end

Updated by nobu (Nobuyoshi Nakada) over 11 years ago

  • Category changed from lib to core
  • Status changed from Rejected to Assigned
  • Assignee set to mrkn (Kenta Murata)
  • Priority changed from 5 to Normal

Ok, then you want to request a new feature?

Updated by regularfry (Alex Young) over 11 years ago

Sure. I've created #6973 for this, although I've switched the method names around from my suggestion above. I'm guessing there's rather more code relying on #integer?'s current implementation than I'd want to personally fix right now :-)

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

  • Status changed from Assigned to Rejected

Closing, as it is now covered by feature request #6973

I was also surprised by the fact that .integer? is equivalent to is_a?(Integer). It makes that method completely redundant (and less clear than using is_a?).

Did we ever remove a method in Ruby?

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0