On 30 October 2012 08:12, alexeymuranov (Alexey Muranov)
<redmine / ruby-lang.org> wrote:
>
> Issue #6973 has been updated by alexeymuranov (Alexey Muranov).
>
>>  >>   Floats are precise, just like Integers are.  *Operations* on floats are
>>  >>   not accurate, and that's where the confusion comes from.  That's
>>  >>   inherent to the representation and something you've got to deal with
>>  >>   anyway, so I certainly don't see this test as making that problem worse.
>>  >
>>  > Your points is valid as long as we can distinguish a Float that includes
>>  > error from a Float that includes no error, such as, just created by a
>>  > Float literal, or by only accurate operations (no overflow, no indivisible
>>  > division, ...).
>>  > But in fact, we cannot distinguish them.  We conservatively have to think
>>  > that any Float object includes an error, I think.
>>
>>  So if I knowingly and correctly construct a calculation which cannot
>>  contain such an error, Ruby should tell me that it's wrong?
>>
>
> I guess the question is: what would be a point in calling this method on a Float?  A Float value is rarely exact in the sense that it rarely coincides with the real-world value which it models.

What if it had an (optional?) parameter for precision?  I know in the
past I've wanted to know whether the value stored in a float looked
like an integer to a certain number of places.

I believe that would make it more clear that we're not necessarily
saying that the real-world value we're modeling is exactly an integer;
rather that it is near enough for our current purposes.

If optional, I suppose the default would be "as many places as are
represented by this float," or (self.to_i == self)

-- 
  Matthew Kerwin, B.Sc (CompSci) (Hons)
  http://matthew.kerwin.net.au/
  ABN: 59-013-727-651

  "You'll never find a programming language that frees
  you from the burden of clarifying your ideas." - xkcd