[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

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

Yukihiro Matsumoto

5/21/2008 8:14:00 AM

Hi,

In message "Re: Why doesn't Float() work the same as Integer()?"
on Tue, 20 May 2008 11:30:12 +0900, "Eric I." <rubytraining@gmail.com> writes:

|First, Float() and Integer() work like Ruby itself. In Ruby code you
|can hardcode integer literals using 17 (dec), 021 (oct), or 0x11
|(hex). But you can only hardcode floating point literals using base
|ten. Admittedly, that's a bit of a punt since you'll probably ask why
|Ruby works that way.

Because most of us would have hard time to guess how much 0x11.4 is.
Besides that, I don't see any usecase for converting hexadecimal
(integer) representation directly into float values.

matz.
12 Answers

Sebastian Hungerecker

5/21/2008 4:22:00 PM

0

Yukihiro Matsumoto wrote:
> Because most of us would have hard time to guess how much 0x11.4 is.

I'd expect it to be 1 * 16**1 + 1 * 16**0 + 4 * 16**(-1)

--
NP: Depeche Mode - See You
Jabber: sepp2k@jabber.org
ICQ: 205544826

Michael W. Ryder

5/21/2008 7:07:00 PM

0

Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: Why doesn't Float() work the same as Integer()?"
> on Tue, 20 May 2008 11:30:12 +0900, "Eric I." <rubytraining@gmail.com> writes:
>
> |First, Float() and Integer() work like Ruby itself. In Ruby code you
> |can hardcode integer literals using 17 (dec), 021 (oct), or 0x11
> |(hex). But you can only hardcode floating point literals using base
> |ten. Admittedly, that's a bit of a punt since you'll probably ask why
> |Ruby works that way.
>
> Because most of us would have hard time to guess how much 0x11.4 is.
> Besides that, I don't see any usecase for converting hexadecimal
> (integer) representation directly into float values.
>
> matz.
>
Thank you for the reply. I wanted to convert strings to Floats first as
it simplified some of a method's logic. The method allows
Rational.new(3.5) and returns 7/2, it also allows Rational.new(3.5, 2)
and returns 7/4. Converting from strings seemed to be a simple addition
to the method and rather than having separate logic for Integers and
Floats I wanted to just convert all Strings to Floats and then convert
the Floats. Since I had already gone this far I decided to add support
for any number that Ruby allows, this is where I ran into the
"inconsistency" in the methods Float(x) and Integer(x).
As Ruby doesn't appear to support Floats in any base other than 10 I had
no problem if it didn't convert '0x11.4' just like it wouldn't convert
'abcd'. But since it could convert valid Integers I was confused while
it couldn't convert '0x11'.

Pit Capitain

5/26/2008 9:33:00 AM

0

2008/5/21 Michael W. Ryder <_mwryder@worldnet.att.net>:
> 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.

Regards,
Pit

Eric I.

5/26/2008 2:58:00 PM

0

On May 21, 4:14 am, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
> Besides that, I don't see any usecase for converting hexadecimal
> (integer) representation directly into float values.

That's what I'd said in my reply. And then, of course, we get this:

http://xkc...

Not that a webcomic should drive language design. But not that it
shouldn't either.... ;)

Eric

====

LearnRuby.com offers Rails & Ruby HANDS-ON public & ON-SITE
workshops.
Ruby Fundamentals Wkshp June 16-18 Ann Arbor, Mich.
Ready for Rails Ruby Wkshp June 23-24 Ann Arbor, Mich.
Ruby on Rails Wkshp June 25-27 Ann Arbor, Mich.
Ruby Plus Rails Combo Wkshp June 23-27 Ann Arbor, Mich
Please visit http://Lea... for all the details.

Michael W. Ryder

5/26/2008 10:23:00 PM

0

Pit Capitain wrote:
> 2008/5/21 Michael W. Ryder <_mwryder@worldnet.att.net>:
>> 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.


> Regards,
> Pit
>

Tim Hunter

5/26/2008 10:57:00 PM

0

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.

--
RMagick: http://rmagick.ruby...
RMagick 2: http://rmagick.ruby...rmagick2.html

Axel Etzold

5/26/2008 10:59:00 PM

0


-------- 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:
> > 2008/5/21 Michael W. Ryder <_mwryder@worldnet.att.net>:
> >> 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_gol...

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,

http://en.wikipedia.org/wiki/Continue...
http://en.wikipedia.org/wiki/Continue...#Best_rational_approximations

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




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

Michael W. Ryder

5/27/2008 6:24:00 PM

0

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.

Mark Wilden

5/27/2008 7:15:00 PM

0

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

How would you exactly represent 1/3 in BCD?

///ark

Michael W. Ryder

5/27/2008 8:38:00 PM

0

Mark Wilden wrote:
> 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
>
> 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.