Float.to_int not working ??

[alexc42]

Hi all,

I must admit that I am new to Ruby, so maybe this is not a real bug?!

Trying the following

print "#{((1.0 + 0.025)/0.0002 + 1.0)} \n"
print "#{((1.0 + 0.025)/0.0002 + 1.0).to_i} \n"

I get (with ruby 1.8.4 & 1.8.5, Linux) as output

5126.0
5125

Any suggestions?

Thanks,
Alex.

 

[Stefan Rusterholz]

Hi all,

I must admit that I am new to Ruby, so maybe this is not a real bug?!

Trying the following

print "#{((1.0 + 0.025)/0.0002 + 1.0)} \n"
print "#{((1.0 + 0.025)/0.0002 + 1.0).to_i} \n"

I get (with ruby 1.8.4 & 1.8.5, Linux) as output

5126.0
5125

Any suggestions?

Yes. Learn about floats. Floats are approximations, that has some
consequences. As for your code above:
printf "%.40f\n",((1.0 + 0.025)/0.0002 + 1.0) # prints:
5125.9999999999990905052982270717620849609375

Now you see why .to_i gives you 5125.

Regards
Stefan

 

[Kyle Schmitt]

Look at the links below for some help understanding it. It's more or
less a 2's compliment problem. Basically, there are a lot of
seemingly simple, finite decimal numbers that can not be accurately
represented by the standard float.

http://docs.sun.com/source/806-3568/ncg_goldberg.html
http://en.wikipedia.org/wiki/IEEE_754

 

[Lloyd Linklater]

Trying the following

print "#{((1.0 + 0.025)/0.0002 + 1.0)} \n"
print "#{((1.0 + 0.025)/0.0002 + 1.0).to_i} \n"

I get (with ruby 1.8.4 & 1.8.5, Linux) as output

5126.0
5125

Any suggestions?

What about

print "#{((1.0 + 0.025)/0.0002 + 1.0).round.to_i} \n"

 

[Stefan Rusterholz]

print "#{((1.0 + 0.025)/0.0002 + 1.0).round.to_i} \n"

Round already returns an integer, the .to_i is redundant ;-)

Regards
Stefan

 

[John Joyce]

Round already returns an integer, the .to_i is redundant ;-)

Regards
Stefan

For more accurate math, use really large integers and simply keep
track of where you want your decimal.
You wouldn't dare write an accounting application using floats, would
you?
If you absolutely must use floats for something, and you need greater
accuracy, you should use something like C and its extra long float
types, coupled with at least a 64 bit system, ideally go get an old
PowerMac G5, its math coprocessor is 128 bits. It'll give you as good
as you can get without buying a much more expensive machine or
cobbling together a cluster of computers.

 

[Stefan Rusterholz]

For more accurate math, use really large integers and simply keep
track of where you want your decimal.

Or with ruby use BigDecimal or Rational (won't work for applications
where you have to use functions that will result in real numbers, like
square-root, sin, etc.).

If you absolutely must use floats for something, and you need greater
accuracy, you should use something like C and its extra long float
types, coupled with at least a 64 bit system, ideally go get an old
PowerMac G5, its math coprocessor is 128 bits. It'll give you as good
as you can get without buying a much more expensive machine or
cobbling together a cluster of computers.

Not sure but it seems that you think 64bitness of a System influences
the float accuracy. It does not.

Regards
Stefan

 

[Kyle Schmitt]

If you absolutely must use floats for something, and you need greater
accuracy, you should use something like C and its extra long float
types, coupled with at least a 64 bit system, ideally go get an old

Just remember, sadly even with C and a 64 bits, all you get is a
better estimation. The numbers that can't exactly be represented by a
32bit IEEE float still can't be exactly represented if you give them
more bits.

As far as accounting applications go, you'd think that the fixed
precision data types would be just the thing. The problem is fixed
precision data types tend have the EXACT same problems brought about
by 2s compliment (some .net projects here at work ran into that).

Some languages apparently provide a decimal type that doesn't have
these problems, but I've never played with them.

--Kyle

 

[Kyle Schmitt]

Not sure but it seems that you think 64bitness of a System influences
the float accuracy. It does not.

It can increase the accuracy of the estimation.
0.3333333333333333333333333333333333333
is a better estimation of 1/3 than
0.33
etc..
In more complex cases it makes more of a difference, but it's still
just an estimation.

--Kyle

 

[Stefan Rusterholz]

It can increase the accuracy of the estimation.
0.3333333333333333333333333333333333333
is a better estimation of 1/3 than
0.33
etc..
In more complex cases it makes more of a difference, but it's still
just an estimation.

--Kyle

Ya, but that's nothing to do with a system being 32 or 64bit, you can
have 64bit floats on both, on some even 80bit.
That 128bit coprocessor he talked about, I guess is Altivec, which only
does single precision float (32bit) operations. Not every X bit means
the same. The context has a big part in that.

Regards
Stefan