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


 

Forums >

comp.lang.ruby

0.06 == 0.06 returns false in Ruby?

Jason G.

8/31/2007 1:38:00 AM

Hi

I wrote a simple test program, basically the program asks the user to
enter floats. the entered values shall be used as keys for Hash (the
values are irrelavent).

The program tries to find the lowest untaken key/float (floats are used
as keys).

please see attachment.

please run the prog, and enter the following:
0.01 - OK
0.02 - OK
0.03 - OK
0.04 - OK
0.05 - OK
0.06 - Problem

Can anyone explain to me what's going on here?

thanks
jason

Attachments:
http://www.ruby-...attachment/1...

--
Posted via http://www.ruby-....
43 Answers

Dan Zwell

8/31/2007 1:54:00 AM

0

Jason G. wrote:
> Hi
>
> I wrote a simple test program, basically the program asks the user to
> enter floats. the entered values shall be used as keys for Hash (the
> values are irrelavent).
>
> The program tries to find the lowest untaken key/float (floats are used
> as keys).
>
> please see attachment.
>
> please run the prog, and enter the following:
> 0.01 - OK
> 0.02 - OK
> 0.03 - OK
> 0.04 - OK
> 0.05 - OK
> 0.06 - Problem
>
> Can anyone explain to me what's going on here?
>

You should never compare floating point numbers for equality in any
language. This is true at least for C, C++, .NET, and Java, to name a
few. It just won't be accurate. Unlike integers, floats are not stored
as their true Platonic forms ;). If you really wanted to see how the
digits differed, you could print both numbers to a large number of
digits (printf("%.20f", my_number)). You don't even need to do any math
to see the roundoff error.

>> printf("%.50f", 1.1)
1.10000000000000008881784197001252323389053344726562

To compare floats, you must ask whether they are within a certain
threshold of each other.
Epsilon = 0.00000000001
return (num1-num2).abs < Epsilon # num1 == num2

Dan

Jason G.

8/31/2007 2:28:00 AM

0

thanks for the help
--
Posted via http://www.ruby-....

Dan Zwell

8/31/2007 2:42:00 AM

0

Dan Zwell wrote:
> To compare floats, you must ask whether they are within a certain
> threshold of each other.
> Epsilon = 0.00000000001
> return (num1-num2).abs < Epsilon # num1 == num2
>
> Dan
>
>

Oops, I didn't realize that Ruby comes with an Epsilon. This should be a
fine test for equality:

return (num1-num2).abs < Float::EPSILON

Now, whether Float#==(other) should make this check might be worth
thinking about, but I really have no opinion on the matter--I'm used to
not comparing floats like this.

Dan

doug meyer

8/31/2007 2:51:00 AM

0

There is also a class called BigDecimal (or something like that) if
you want to have really accurate numbers and no floating-point errors.

On 8/30/07, Dan Zwell <dzwell@gmail.com> wrote:
> Dan Zwell wrote:
> > To compare floats, you must ask whether they are within a certain
> > threshold of each other.
> > Epsilon = 0.00000000001
> > return (num1-num2).abs < Epsilon # num1 == num2
> >
> > Dan
> >
> >
>
> Oops, I didn't realize that Ruby comes with an Epsilon. This should be a
> fine test for equality:
>
> return (num1-num2).abs < Float::EPSILON
>
> Now, whether Float#==(other) should make this check might be worth
> thinking about, but I really have no opinion on the matter--I'm used to
> not comparing floats like this.
>
> Dan
>
>

Ravil Bayramgalin

8/31/2007 5:04:00 AM

0

2007/8/31, doug meyer <doug.meyer@sigeps.org>:
> There is also a class called BigDecimal (or something like that) if
> you want to have really accurate numbers and no floating-point errors.

+1

Michael Ulm

8/31/2007 6:25:00 AM

0

Peña wrote:
--snip--
> irb(main):010:0> (0.05+0.01) - 0.06
> => 6.93889390390723e-18
>
> as mentioned by Dan, careful on comparing floats. And as to any
> precision subject, there is what we call significant digits..
>
> this floating problem is a faq and is very surprising on such a
> very high language such as ruby. can we address this? maybe create
> flag like $EPSILON=0 or something, or may flag to revert to rational
> or bigdeci like $FLOAT_PROCESSOR=RATIONAL...
>

Unfortunately, there is no easy solution to this problem. Here is a
catalog of often proposed solutions and why they do not work:

1 (proposed by doug meyer in this thread) Always use
(x-y).abs < Float::EPSILON
as a test for equality.

This won't work because the rounding error easily can get bigger than
Float::EPSILON, especially when dealing with numbers that are bigger
than unity. e.g.
y = 100.1 + 0.3
y - 100.4 # => -1.421e-14, while Float::EPSILON = 2.22e-16

2 Always use
(x-y).abs < (x.abs + y.abs) * Float::EPSILON)
as a test for equality.

Better than the first proposal, but won't work if the rounding error
gets too large after a complex computation.
In addition, (1) and (2) suffer from the problem that x==y and y==z do
not imply x==z.

3 Use Bigdezimal

This only shifts the problem a few decimal places down, and tests for
equality will fail as with the normal floats.

4 Use Rationals

Works if you only have to deal with rational operations. But doesn't
solve the following
x = sqrt(2)
y = x + 1
x + 0.2 == y - 0.8 # => false
In addition, rational arithmetic can produce huge numbers pretty fast,
and this will slow down computations enormously.

5 Use a symbolic math package

This could in theory solve the issue with equality, but in practice there
is no way to decide that two symbolic representations of a number are the
same, like
1 / (sqrt(2) - 1) == sqrt(2) + 1
Also, very, very slow.

6 Use interval arithmetic

Gives you strict bounds on your solution, but can't answer x==y.


Summing up, when using floating point arithmetic there is no one true way.
There is no substitute for understanding numbers and analyzing your problem.

HTH,

Michael

M. Edward (Ed) Borasky

8/31/2007 7:12:00 AM

0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Ulm wrote:
> Unfortunately, there is no easy solution to this problem. Here is a
> catalog of often proposed solutions and why they do not work:
>
> 1 (proposed by doug meyer in this thread) Always use
> (x-y).abs < Float::EPSILON
> as a test for equality.
>
> This won't work because the rounding error easily can get bigger than
> Float::EPSILON, especially when dealing with numbers that are bigger
> than unity. e.g.
> y = 100.1 + 0.3
> y - 100.4 # => -1.421e-14, while Float::EPSILON = 2.22e-16
>
> 2 Always use (x-y).abs < (x.abs + y.abs) * Float::EPSILON) as a test
> for equality.
>
> Better than the first proposal, but won't work if the rounding error
> gets too large after a complex computation.
> In addition, (1) and (2) suffer from the problem that x==y and y==z do
> not imply x==z.
>
> 3 Use Bigdezimal
>
> This only shifts the problem a few decimal places down, and tests for
> equality will fail as with the normal floats.
>
> 4 Use Rationals
>
> Works if you only have to deal with rational operations. But doesn't
> solve the following
> x = sqrt(2)
> y = x + 1
> x + 0.2 == y - 0.8 # => false
> In addition, rational arithmetic can produce huge numbers pretty fast,
> and this will slow down computations enormously.
> 5 Use a symbolic math package
>
> This could in theory solve the issue with equality, but in practice there
> is no way to decide that two symbolic representations of a number are the
> same, like
> 1 / (sqrt(2) - 1) == sqrt(2) + 1
> Also, very, very slow.
>
> 6 Use interval arithmetic
>
> Gives you strict bounds on your solution, but can't answer x==y.
>
>
> Summing up, when using floating point arithmetic there is no one true way.
> There is no substitute for understanding numbers and analyzing your
> problem.

Well ... OK ... but ...

This whole floating-point thing comes up here on a weekly basis, and
I'll bet it comes up on all the other language mailing lists too. No
matter how many times you repeat this, no matter how many web sites
explaining floating point arithmetic you point people to, etc., you are
still going to get people who don't know how it works and have
expectations that aren't realistic. An awful lot of calculators have
been built using decimal arithmetic just because there are a few less
"anomalies" that need to be explained.

People like me who do number crunching for a living know all this stuff
inside and out. I actually learned the basics of scientific computing in
scaled fixed-point arithmetic, and it's only been in recent years (since
the Pentium, in fact) that just about every computer you're likely to
touch has had floating point hardware. Before that, you were likely to
be dealing with slow and inaccurate libraries emulating the hardware
unless you were in a scientific research environment. And it's also been
only a few more years since nearly all new architectures supported
(mostly) the IEEE floating point standard.

Before that, it was chaos -- most 32-bit floating point arithmetic was
unusable except for data storage, the reigning supercomputers had
floating point units optimized for speed at the expense of correctness,
you actually had to pay for good math libraries and whole books of
garbage number crunching algorithms were popular best-sellers. In short,
even the folks who knew very well how it *should* be done made both
necessary compromises and serious mistakes. It took some brave souls
like William Kahan several years to get some of the more obvious garbage
out of "common practice".

So give the newbies a break on this issue -- the professionals have only
been doing it mostly right since about 1990. :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail....

iD8DBQFG179D8fKMegVjSM8RAnaZAJ0X16UuHOEvWc5iZDurg7f607xr8QCfed+C
FG+18FnY10HxP+8t6R/62bM=
=jJ+X
-----END PGP SIGNATURE-----

Daniel DeLorme

8/31/2007 8:04:00 AM

0

Michael Ulm wrote:
>> this floating problem is a faq and is very surprising on such a
>> very high language such as ruby. can we address this? maybe create
>> flag like $EPSILON=0 or something, or may flag to revert to rational
>> or bigdeci like $FLOAT_PROCESSOR=RATIONAL...
>
> Unfortunately, there is no easy solution to this problem. Here is a
> catalog of often proposed solutions and why they do not work:
>
> 2 Always use (x-y).abs < (x.abs + y.abs) * Float::EPSILON) as a test
> for equality.
>
> Better than the first proposal, but won't work if the rounding error
> gets too large after a complex computation.
> In addition, (1) and (2) suffer from the problem that x==y and y==z do
> not imply x==z.

But it would fix 99% of problems. It would be worth it just for the sake
of reducing those questions on the list :-P

Seriously though, since floating point calculations are approximative to
start with, what would be wrong with making them more intuitive
approximations? IMHO Float should use the above algorithm for == and
reserve normal floating point arithmetic for eql?

Daniel

Dan Zwell

8/31/2007 8:19:00 AM

0

Daniel DeLorme wrote:
> Michael Ulm wrote:
>>> this floating problem is a faq and is very surprising on such a
>>> very high language such as ruby. can we address this? maybe create
>>> flag like $EPSILON=0 or something, or may flag to revert to rational
>>> or bigdeci like $FLOAT_PROCESSOR=RATIONAL...
>>
>> Unfortunately, there is no easy solution to this problem. Here is a
>> catalog of often proposed solutions and why they do not work:
>>
>> 2 Always use (x-y).abs < (x.abs + y.abs) * Float::EPSILON) as a test
>> for equality.
>>
>> Better than the first proposal, but won't work if the rounding error
>> gets too large after a complex computation.
>> In addition, (1) and (2) suffer from the problem that x==y and y==z do
>> not imply x==z.
>
> But it would fix 99% of problems. It would be worth it just for the sake
> of reducing those questions on the list :-P
>
> Seriously though, since floating point calculations are approximative to
> start with, what would be wrong with making them more intuitive
> approximations? IMHO Float should use the above algorithm for == and
> reserve normal floating point arithmetic for eql?
>
> Daniel
>
>

Michael wrote very convincingly that there is no simple solution that
will work in all cases. I'm convinced, at least. If there is no solution
that works 100% of the time, we can't give the illusion that there is.
To do so would be to teach bad programming practices to newcomers, and
that's not fair.

The current "==" in okay because it works the way a moderately
experienced programmer would expect. A perfect "==" that could deal with
floats would be even better, but we aren't gonna get that. A "==" that
seems like magic and almost always works is really pretty dangerous.

Dan

Bertram Scharpf

8/31/2007 8:20:00 AM

0

Hi,

Am Freitag, 31. Aug 2007, 17:03:38 +0900 schrieb Daniel DeLorme:
>> Unfortunately, there is no easy solution to this problem. Here is a
>> catalog of often proposed solutions and why they do not work:
>
> But it would fix 99% of problems. It would be worth it just for the sake of
> reducing those questions on the list :-P
>
> Seriously though, since floating point calculations are approximative to
> start with, what would be wrong with making them more intuitive
> approximations? IMHO Float should use the above algorithm for == and
> reserve normal floating point arithmetic for eql?

I alway liked it to be forced to decide what are countable
dimensions and what are continuous ones. This made my
programming style much clearer.

Bertram


--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-...