From: Raphael Clancy <raphael.clancy@...>
Date: 2009-02-22T11:21:47+09:00
Subject: Re: floating point rounding error?

Roger Pack wrote:
>> 1. existing code might be broken
> 
> True
> 
>> 2. efficiency (Float is faster than BigDecimal)
> 
> Can't disagree with that.
> 
> 
>> 3. standards (AFAIK the Float implementation is backed by an ISO
>> standard while I am not sure whether this is the case for BigDecimal).
> 
> True.

In this case, I think it's IEEE.

> 
>> 4. limited use: while your particular example will work as you expect,
>> BigDecimal is still not a real number (in math terms) but still a
>> rational number => rounding errors for other numbers will be introduced
>> when switching from Float to BigDecimal by default.
> 
> The only real benefit of it is that it won't bite "as often," for better 
> or worse.
> This is a learning curve that could hit you at the edges [adding 
> extremely small and extremely large numbers, for example] and not during 
> normal day use :)

You don't even have to get into numbers that are that big...

irb(main):001:0> a = (10.11 * 100).to_i
=> 1011
irb(main):002:0> b = (10.12 * 100).to_i
=> 1011
irb(main):003:0> a == b
=> true

> 
> One "almost good" answer would be to have ruby output float to strings 
> by default with enough precision to be able to recreate the original.
> 
> 
> Thoughts?
> -=r

This behavior isn't limited to ruby, any language which uses the IEEE 
spec for floating point exhibits the same behavior. For example the C++ 
code that matches the ruby above gives the same result...

#include <iostream>

using namespace std;

int main(int argc, char* argv[]) {
  float x = 10.12;
  int y = (int) (x * 100.0);
  cout << x << " , " << y << endl;
  return(0);
}

gives: 10.12 , 1011

I guess the take home is to avoid floats whenever you'll be doing any 
rounding or truncating.
-- 
Posted via http://www.ruby-forum.com/.