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


 

Forums >

comp.lang.ruby

Simple Math Problem

Thom Loring

11/8/2006 5:36:00 PM

Can anyone shed some light on a simple math problem I have encountered?
I am doing a very simple calculation, and the comparison of that result
compared to the number itself is returning false in some cases...for
instance:

$irb
>> v1 = 80.04
=> 80.04

>> v2 = 0.12 * 667
=> 80.04

>> v1 == v2
=> false

>> v1 > v2
=> true

>> v1 < v2
=> false

>> v1.inspect
=> "80.04"

>> v2.inspect
=> "80.04"

Any insight?

Thanks,
Thom

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

Tim Pease

11/8/2006 5:43:00 PM

0

On 11/8/06, Thom Loring <tloring@mac.com> wrote:
> Can anyone shed some light on a simple math problem I have encountered?
> I am doing a very simple calculation, and the comparison of that result
> compared to the number itself is returning false in some cases...for
> instance:
>
> $irb
> >> v1 = 80.04
> => 80.04
>
> >> v2 = 0.12 * 667
> => 80.04
>
> >> v1 == v2
> => false
>
> >> v1 > v2
> => true
>
> >> v1 < v2
> => false
>
> >> v1.inspect
> => "80.04"
>
> >> v2.inspect
> => "80.04"
>
> Any insight?
>

Machine roundoff error. Floating point values are never precise on any computer.

The best way to compare two floating point values is to take there
difference and make sure it lies withing some acceptable error limit.

v1 = 80.04
v2 = 0.12 * 667
diff = v1-v2
diff.abs < Float::EPSILON

That last line returns false, so you need to choose a different epsilon ...

diff.abs < 1.0e-12

That will return true.

Blessings,
TwP

Ara.T.Howard

11/8/2006 5:47:00 PM

0

Hugh Sasse

11/8/2006 5:49:00 PM

0

Thom Loring

11/8/2006 5:52:00 PM

0

Hmm...yeah, I figured that must be it, but I just didn't expect it with
numbers of this scale. Thanks for the insight!

Thom

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

Ara.T.Howard

11/8/2006 5:55:00 PM

0

Tim Pease

11/8/2006 6:00:00 PM

0

On 11/8/06, Hugh Sasse <hgs@dmu.ac.uk> wrote:
> >
> > Machine roundoff error. Floating point values are never precise on any
> > computer.
> >
> brains hgs 226 %> irb
> irb(main):001:0> v1 = 80.04
> => 80.04
> irb(main):002:0> v2 = 0.12 * 667
> => 80.04
> irb(main):003:0> puts "%.20f" % v1
> 80.04000000000000625278
> => nil
> irb(main):004:0> puts "%.20f" % v2
> 80.03999999999999204192
> => nil
> irb(main):005:0> exit
> brains hgs 227 %>
>

With IEEE 754 floating point values you only have 15 digits of
precision (8 byte doubles). Ara's little example above demonstrates
that very nicely. Things go pear shaped in the 17th digit with the
"exact" value 80.04 (v1).

Take a look at the "assert_in_delta" method of the Test::Unit library.
That performs floating point comparison by comparing a diff against
some epsilon (delta).

<shameless plug>
There is an RCR open to implement a =~ operator for floating point
values that would perform a diff comparison against an epsilon value.

http://rcrchive.net/rc...
</shameless plug>

Blessings,
TwP

Tim Pease

11/8/2006 6:01:00 PM

0

On 11/8/06, Tim Pease <tim.pease@gmail.com> wrote:
> On 11/8/06, Hugh Sasse <hgs@dmu.ac.uk> wrote:
>
> With IEEE 754 floating point values you only have 15 digits of
> precision (8 byte doubles). Ara's little example above demonstrates
> that very nicely. Things go pear shaped in the 17th digit with the
> "exact" value 80.04 (v1).
>

<errata>
Sorry, that should be "Hugh's little example above".
</errata>

TwP

Hugh Sasse

11/8/2006 6:19:00 PM

0

Paul Lutus

11/9/2006 7:17:00 AM

0

Thom Loring wrote:

> Hmm...yeah, I figured that must be it, but I just didn't expect it with
> numbers of this scale. Thanks for the insight!

It isn't about the magnitude of the numbers, it is about the unseen bits.

You could produce examples of numbers with very large or very small
exponents and they are equally likely to have the sort of roundoff error
you experienced.

The only thing you can rely on with floating-point numbers is that the same
sequence of operations, on the same platform, will produce numbers that
will agree with each other when compared later.

There are many packages now that use decimal instead of binary internal
storage to avoid this sort of thing, at the expense of execution speed and
storage space. But an interesting fact about binary vs. decimal is that
projects that compute Pi to billions of places, now perform the entire
operation in decimal internally, because the time required to convert the
result from binary to decimal at the end of the computation turned out to
be a substantial percentage of the entire calculation time.

--
Paul Lutus
http://www.ara...

Josef 'Jupp' Schugt

11/9/2006 9:38:00 PM

0

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

* Thom Loring, 11/08/2006 06:35 PM:
> Any insight?

Visit an introduction to Numerical Mathematics at your favorite
university. Numerical imprecision and the stability of algorithms
against it is one of the most prominent questions addressed there.
Also they address the question how precise a result of a computation
can be given a certain imprecision of input that either results from
the computer's approximation to a given value (decimal 0.1 cannot be
represented as a binary fraction with a finite number of digits) or
from imprecisely known values - which includes any measured quantity
occuring in natural science (actually all quantities that are not
defined by law as it is the case with vacuum light speed that by law
is defined to be precisely 299792458 m/s).

Jupp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFU5+6rhv7B2zGV08RAquRAJ9iylLMInU/DyFSLmbgtHYAf1CPTACfZz8I
NvxFp0ctdnvL8LmK43KbvK4=
=jb/q
-----END PGP SIGNATURE-----