Float.to_int not working?

ruby-talk
1

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.

2

unknown wrote:

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

···

--
Posted via http://www.ruby-forum.com/\.

3

unknown wrote:

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"

···

--
Posted via http://www.ruby-forum.com/\.

4

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

5

Lloyd Linklater wrote:

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

Round already returns an integer, the .to_i is redundant :wink:

Regards
Stefan

···

--
Posted via http://www.ruby-forum.com/\.

6

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.

···

On Jul 19, 2007, at 10:15 AM, Stefan Rusterholz wrote:

Lloyd Linklater wrote:

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

Round already returns an integer, the .to_i is redundant :wink:

Regards
Stefan

-- Posted via http://www.ruby-forum.com/\.

7

John Joyce wrote:

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

···

--
Posted via http://www.ruby-forum.com/\.

8

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. :frowning:

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

···

On 7/19/07, John Joyce <dangerwillrobinsondanger@gmail.com> wrote:

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

9

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

···

On 7/19/07, Stefan Rusterholz <apeiros@gmx.net> wrote:

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

10

Kyle Schmitt wrote:

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

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

···

On 7/19/07, Stefan Rusterholz <apeiros@gmx.net> wrote:

--
Posted via http://www.ruby-forum.com/\.