There's more than one way to do things PerlMonks

### Re^3: How can I calculate the right combination of postage stamps?

 on Nov 28, 2008 at 14:59 UTC ( #726602=note: print w/replies, xml ) Need Help??

That's not a bug in Perl. It's an artifact of using floating point numbers. There are many numbers that cannot be represented exactly in floating point.

At a glance, it appears that none of those would be exactly represented in the IEEE floating point formats. (I could be wrong.) So there would be some error in the calculation in any language, on any processor.

• Comment on Re^3: How can I calculate the right combination of postage stamps?

Replies are listed 'Best First'.
Re^4: How can I calculate the right combination of postage stamps?
by gone2015 (Deacon) on Nov 28, 2008 at 19:16 UTC

Strictly, it's not because it's floating point, it's because it's binary floating point.

When decimal 1.51 is converted to a binary fraction the result is:

```  1.1000_0010_1000_1111_0101_1100_0010_1000_1111_0101_1100_0010_1000_1111_0101_1100_0010_1000_1111_0101...
```
which you can see is a repeating binary fraction.

As you say, most decimal fractions are like this... so before any errors can be introduced by rounding and what not, most decimal fractions have a built-in "representation" error.

Most of the time you won't see the "representation" error, because conversion back to decimal rounds it off. This can lead to bafflement when two values look the same when printed out, but fail \$x == \$y. Addition and subtraction are the more difficult floating point operations, so you're more likely to see the problems there. Consider:

```  print 1.09 - 1, "\n" ;
print "0.84 - 0.34 == ", 0.84 - 0.34,
( 0.84 - 0.34 == 0.5 ? " ==" : " but !=" ), " 0.5\n" ;
which gives:
```  0.0900000000000001
0.84 - 0.34 == 0.5 but != 0.5
```
it really makes me wonder why we persist in using binary floating point for decimal arithmetic !

This issue is caused by binary floating point. But, it is an artifact of any floating point notation. For example,

```1/3 + 1/3 + 1/3 != 1

for any finite number of digits using decimal representations.

Given any base, there will be some fractions that cannot be properly represented and would therefore cause this problem. (At least until such time as we have infinite precision floating point representations.<grin/>)

This problem can be solved with Continued Fractions. Unfortunately nobody seems to use continued fraction libraries.

I know that MJD wrote one in Perl, but he didn't polish it up and release it on CPAN. I don't think anyone else has released one either.

At least until such time as we have infinite precision floating point representations.

I believe there have been efforts to represent p-adic numbers. perlnumber makes a brief mention of "exotic" number operations with p-adic arithmetic.

Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://726602]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (2)
As of 2023-03-22 23:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
Voting Booth?
Which type of climate do you prefer to live in?

Results (60 votes). Check out past polls.

Notices?