Issue #5321 has been updated by wishdev (John Higgins).


I really think this is a very overblown issue that is being handled incorrectly.

First, we have what appears to be a singular issue on our hands

Complex(1, BigDecimal("0.0")).to_r

Whether or not that qualifies as a valid operation. BigDecimal('0.0') is ABSOLUTELY without any question at all an exact number and therefore valid in the original operation.

BigDecimal('0.0') is and ALWAYS is an exact number

An example with a slightly different number (0 does not allow for many calculation examples).

# Request arbitrary precision for future CALCULATIONS
BigDecimal.limit(3)
# => 0
# Store a number
a = BigDecimal('0.00000001')
=> 0.1e-7
# Calculate
a + 0.1
# => 0.1e0 # Note the precision dropped

# Remove the limit
BigDecimal.limit(0)
=> 3
# Recalculate
a + 0.1
# Precision held
=> 0.10000001e0

The number is 100% accurate - the precision only affects calculation results and they are only affected at my request.

(BigDecimal('6e-1092837') + BigDecimal('1')).to_s.length
# 1092842

That is an accurate calculation to whatever required precision exists. You can lock your system up if you increase the length of the number - it will work to accomplish what you ask of it.

One cannot throw out valid concepts because someone offers up convenience methods to developers to limit precision if desired. But the choice is that of the developer and not an issue with the class. The class is fully compliant with exactness and should be afforded that.

Floating point does not offer up a choice - it has intrinsic limits - BigDecimal offers no such limitations.

----------------------------------------
Feature #5321: Introducing Numeric#exact? and Numeric#inexact?
https://bugs.ruby-lang.org/issues/5321#change-83622

* Author: mrkn (Kenta Murata)
* Status: Assigned
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 
----------------------------------------
Ruby has several numeric classes such as Integer.
These classes are classified whether their instances represent numbers exactly.
According to this, Integer and Rational are exact, and Float and BigDecimal are inexact because they're always including error.
The exactness of a Complex depends on its real and imaginary parts.

Now, Ruby's numeric classes doesn't provide predicators to investigate the exactness of their instances.
So, if we want to examine whether a number is exactly zero, we must investigate the class of the number.
I want simple way to examine the number exactness.

I propose to introduce Numeric#exact? and/or Numeric#inexact? for resolving this inconvenience.


---Files--------------------------------
numeric-exact-5321.patch (7.33 KB)


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

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>