From: Mark Hubbart <discord@...>
Date: 2004-05-13T03:36:52+09:00
Subject: Re: Major Addition Bug?


On May 12, 2004, at 10:27 AM, Sean O'Dell wrote:

>> If you want exact, fractional, math, you should probably use the
>> 'rational' library and investigate 'mathn'.
>
> Funny though, if I set a variable to 1547.91 exactly, it is 
> represented just
> fine.  A value during the arithmetic must be a value which can't be
> represented.
>
> I had to massage my floating point math in C/C++ a lot many years ago, 
> but I
> always assumed it was a flaw in the MS compiler, and once I got in the 
> habit
> of doing it, I forgot about it.

just a point here... floats are just one binary integer times two to 
the power of another binary integer:

   num = 0b11000001011111010001111010111000010100011110101110001 * 0b10 
** -0b101010
     ==>1547.91
   "%.43f"%num
     ==>"1547.9100000000000818545231595635414123535156250"
   "%.43f"%1547.91
     ==>"1547.9100000000000818545231595635414123535156250"

The BigDecimal class uses actual decimal numbers, IIRC. It might be 
more appropriate for a calculator app, or something like that. I 
suppose it is much slower, however.

> Thanks for the info.  I'm far less bitter now about having to round the
> numbers for comparison.  =)

rather than rounding, you might consider:

   (625.91 + 900.00 + 22.00) - 1547.91 > 0.0000000001
     ==>false

or even, for the scope of your app:

   class Float
     def ==(other)
       self - other < 0.000000000001
     end
   end
     ==>nil
   (625.91 + 900.00 + 22.00) == 1547.91
     ==>true

or, if you aren't into redefing #==, you might just make a method, say, 
#approx_eql?(other) for Float.

cheers,
--Mark