Why doesn't Float() work the same as Integer()?

ruby-talk
21

-------- Original-Nachricht --------

Datum: Tue, 27 May 2008 07:24:28 +0900
Von: "Michael W. Ryder" <_mwryder@worldnet.att.net>
An: ruby-talk@ruby-lang.org
Betreff: Re: Why doesn\'t Float() work the same as Integer()?

Pit Capitain wrote:
>> The method allows Rational.new(3.5) and returns 7/2
>
> I would be very careful with converting Floats to Rationals. You know
> that Rational.new(0.1) wouldn't return 1/10? If not you should read
> about IEEE 754, which is the basis for Ruby's floating point numbers.
>

I realize that my implementation will not work with all allowable Floats
such as Infinity, NAN, etc. but I am not trying to cover everything,
just some of the most common. I envision being able to use my version
of the rational module to implement a command line calculator that could
take "3.4 + 12 3/4" and return 16 3/20 or 16.15.
I can not see how you can say that 0.1 != 1/10. I tried looking up the
standard but the paper I looked at, about implementing the standard in a
language, made no mention of converting floating point numbers to
rational numbers.

Dear Michael,

maybe what Pit meant was what you find in a paper like this:

http://docs.sun.com/source/806-3568/ncg_goldberg.html

about numerical (mis-)representations of Floats on machines.

If you want to do calculations with both Floats and fractions,
you can first generate a best approximation (with respect to the
size of the denominator, that is) of the Float by a fraction, via
a continued fraction expansion of the Float,

and then go on from there. But in the end, that wont be cleaner than
floating point arithmetic - consider adding or multiplying the numbers
defined by the following continued fraction expansions:

cfpi=[3,1,4,1,5,9,...] ('single digits from pi')
cfe=[2,7,1,8,2,8,1,8,2,8...] ('single digits from e')

Best regards,

Axel

···

> 2008/5/21 Michael W. Ryder <_mwryder@worldnet.att.net>:

--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx

22

Tim Hunter wrote:

Michael W. Ryder wrote:

I can not see how you can say that 0.1 != 1/10. I tried looking up the standard but the paper I looked at, about implementing the standard in a language, made no mention of converting floating point numbers to rational numbers.

Ruby uses binary numbers, not decimal numbers. In binary, 1/10 cannot be represented exactly, just like 1/3 cannot be represented exactly in decimal.

But if I told you that 10 dimes does not equal $1 you would freak. I know that computers do not normally represent fractional numbers correctly, but part of that is the fault of the programmers and chip designers opting for "good enough". If all arithmetic on a computer was done using something like BCD there would not be this problem. Agreed that in the deep dark past using something like BCD was noticeably slower but with the raw power available today, most of which is wasted there is no reason to accept second or third best.
Anyway, there is no way for you, me, or a computer program to know if 0.1 is 1/10 or .999999999999999 or 1.00000000000001 so one can only choose one and hope that it is the right choice. Personally, as someone who works in business, I prefer the 1/10 solution as that is the way they expect it in business. They do not want to see 10 * .1 equaling .99999999 or 1.00000001, they have to see 1.

23

How would you exactly represent 1/3 in BCD?

///ark

···

On May 27, 2008, at 11:24 AM, Michael W. Ryder wrote:

If all arithmetic on a computer was done using something like BCD there would not be this problem

24

Michael W. Ryder wrote:

Tim Hunter wrote:

Michael W. Ryder wrote:

I can not see how you can say that 0.1 != 1/10. I tried looking up the standard but the paper I looked at, about implementing the standard in a language, made no mention of converting floating point numbers to rational numbers.

Ruby uses binary numbers, not decimal numbers. In binary, 1/10 cannot be represented exactly, just like 1/3 cannot be represented exactly in decimal.

But if I told you that 10 dimes does not equal $1 you would freak. I know that computers do not normally represent fractional numbers correctly, but part of that is the fault of the programmers and chip designers opting for "good enough". If all arithmetic on a computer was done using something like BCD there would not be this problem. Agreed that in the deep dark past using something like BCD was noticeably slower but with the raw power available today, most of which is wasted there is no reason to accept second or third best.
Anyway, there is no way for you, me, or a computer program to know if 0.1 is 1/10 or .999999999999999 or 1.00000000000001 so one can only choose one and hope that it is the right choice. Personally, as someone who works in business, I prefer the 1/10 solution as that is the way they expect it in business. They do not want to see 10 * .1 equaling .99999999 or 1.00000001, they have to see 1.

I found this interesting paper "Performance Characterization of Decimal Arithmetic in Commercial Java Workloads" here: [IEEE Xplore Login]

I don't have an account so I can't read the paper, but I see this interesting tidbit in the summary: "In this paper, we present detailed performance characteristics and we conclude that, relative to total application performance, the overhead of using software decimal implementations is low, and at least from the point of view of these workloads, there is insufficient performance justification to pursue hardware solutions."

···

--
RMagick: http://rmagick.rubyforge.org/
RMagick 2: http://rmagick.rubyforge.org/rmagick2.html

25

Mark Wilden wrote:

If all arithmetic on a computer was done using something like BCD there would not be this problem

How would you exactly represent 1/3 in BCD?

///ark

The same way that the current binary system represents the number or numbers like pi, as an approximation. My point was that .1 is a real number that can be accurately represented fairly simply using something like BCD or rational numbers without having to worry about the approximations and the corrections necessary in the current representation.
My module to represent rational numbers will convert decimal numbers to rationals without having to worry that it isn't IEEE format. I am not worried that it isn't "correct" according to Computer Science thinking as the program is for my learning. I think we can agree that 1/3 * 9 = 3 exactly, not some approximation.

···

On May 27, 2008, at 11:24 AM, Michael W. Ryder wrote:

26

we can, but it just pushes the problem back further when you re-introduce irrational numbers like pi and systems that are, by definition, approximations, like calculus. the reality is that any computation system *must* handle approximations and handle them well. IEEE floating point numbers are a useful way to do just that for classes of problems that are larger than representing fractions.

regards.

a @ http://codeforpeople.com/

···

On May 27, 2008, at 2:39 PM, Michael W. Ryder wrote:

I think we can agree that 1/3 * 9 = 3 exactly, not some approximation.

--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama