On 27/10/12 05:26, mame (Yusuke Endoh) wrote:
>
> Issue #6973 has been updated by mame (Yusuke Endoh).
>
> Status changed from Open to Assigned
> Assignee changed from mame (Yusuke Endoh) to mrkn (Kenta Murata)
> Target version changed from 2.0.0 to next minor
>
> I think mrkn is eligible to handle this ticket.
> The following is my personal comment.
>
> regularfry (Alex Young) wrote:
>>   >  Personally, I'm not entirely convinced this method is a good idea.
>>   >  With Floats, you can't really guarantee that "4.0" is the same as
>>   >  "4". It could actually be "4.00000000000000001" but the precision is
>>   >  lost.
>>
>>   This is actually not true.  If you have a float with a value of 4.0,
>>   then that genuinely *is* the same as 4.  The whole number value "4" has
>>   a precise representation in floating point format, and if you have that
>>   value then it makes no sense to say that what you have might not be
>>   equal to 4.
>>
>>   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?

-- 
Alex