Forum: Ruby Float.to_int not working ??

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Cac38bd52587115deb8be507d4371bea?d=identicon&s=25 unknown (Guest)
on 2007-07-19 16:01
(Received via mailing list)
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.
Cf7cd97cdc8ed7d4ae92965b24f0dfad?d=identicon&s=25 Stefan Rusterholz (apeiros)
on 2007-07-19 16:06
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
9dec3df8319c613f6f4f14a27da0fdb4?d=identicon&s=25 Kyle Schmitt (Guest)
on 2007-07-19 16:32
(Received via mailing list)
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
84dc575c33a123789521d53cad0f62ae?d=identicon&s=25 Lloyd Linklater (lloyd)
on 2007-07-19 16:56
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"
Cf7cd97cdc8ed7d4ae92965b24f0dfad?d=identicon&s=25 Stefan Rusterholz (apeiros)
on 2007-07-19 17:14
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 ;-)

Regards
Stefan
1c0cd550766a3ee3e4a9c495926e4603?d=identicon&s=25 John Joyce (Guest)
on 2007-07-19 21:42
(Received via mailing list)
On Jul 19, 2007, at 10:15 AM, Stefan Rusterholz wrote:

>
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.
Cf7cd97cdc8ed7d4ae92965b24f0dfad?d=identicon&s=25 Stefan Rusterholz (apeiros)
on 2007-07-19 22:26
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
9dec3df8319c613f6f4f14a27da0fdb4?d=identicon&s=25 Kyle Schmitt (Guest)
on 2007-07-19 23:22
(Received via mailing list)
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.
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
Cf7cd97cdc8ed7d4ae92965b24f0dfad?d=identicon&s=25 Stefan Rusterholz (apeiros)
on 2007-07-19 23:35
Kyle Schmitt wrote:
> 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.
> 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
9dec3df8319c613f6f4f14a27da0fdb4?d=identicon&s=25 Kyle Schmitt (Guest)
on 2007-07-19 23:50
(Received via mailing list)
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
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
This topic is locked and can not be replied to.