Well, it may not be a problem with Perl, but it's a problem for me.

So can I avoid it somehow? Stringification of the values before doing the operation solves my problem. Why is that? Is it something accumulated that gets re-set?

(I understand that it changes Perl's internal representation of what is stored in the variable, but what I wonder is how and why that changes what it does when performing the addition).

This is something that popped up in an old application where I do basically the same thing all over the place, but this particular thing haven't been a problem in the past.

Right now I have "solved" id by stringifying the value before doing the calculation, but that doesn't feel very solid.

/J

An alternative which is used in C a lot is to make them into integers by multiplying everything by 10**N where N is the number of decimal places (or precision) you want to have in your answer. Then, when you're done, you divide the answer by 10**N and you're good.

*ponders* This sounds like a good candidate for a CPAN module doing overloaded math ... Or, you could just use Math::BigFloat (which may be overkill)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

When you stringify them, you're forcing perl to round them. If it makes you feel any better about it, you could explicitly round them with sprintf.

---

Caution: Contents may have been coded under pressure.

So can I avoid it somehow?

Yes, multiply everything by 100 (i.e. deal with cents instead of dollars), and divide by 100 (i.e. convert to dollars) when you print. You won't have the problem, because it doesn't occur for numbers with no decimals, unless they get really big (> 2 billion on a 32 bit system).

>perl -e "$a=0; $a += 0.10 for (1..60); print($a, $/);"
5.99999999999999
>perl -e "$a=0; $a += 10 for (1..60); print($a/100, $/);"
6
[download]

See Re: Re: Re: Bug? 1+1 != 2 for why this happens, and what to do about it.

You have a few choices about how to deal with this issue. It does depend on how important this is to you, and what you are trying to accomplish. People writing software for financial institutions will do different things from students just playing with lab results.

• Fixed Point Numbers, part of this thread
• My floating point comparison does not work. Why ?
• Strange rounding Error in Perl

Just because a number looks sane in base 10 doesn't mean it's a rational number in binary.

Rationality is independant of base. A rational number in base 10 will still be rational in base 2. You mean not periodic. A number which isn't periodic in base 10 may be periodic in base 2, but periodic numbers are rational.

As others have said, the problem is that floating point binary can't represent most decimal fractions exactly. It's analogous to the way that 1/3 is a repeating decimal (0.3333...). 0.95 and 0.9 are both repeating binary numbers. As can you see, it goes both ways: even 1/3 in trinary notation does not repeat: 0.1.

The solution is to use "fixed point" or "arbitrary precision" decimal arithmetic. This is usally implemented internally as an integer (or byte array) with a scale. I'm not sure how Math::BigFloat does its job, but it is the standard module for arbitrary precision arithmetic in Perl.

I think that what confused me the most with this is that seemingly identical values don't behave the same way. I.e. the result of

perl -e "print 4253.95 + 0.9"
[download]

is 4254.85. But the result of my other values, which are 4253.95 and 0.9, is 4254.84999999999.

/J

Your diagnostics are still not telling you the whole of the story, because Devel::Peek is performing the same sort of rounding on the NV value it shows you that perl normally does.

If you want to look at these values in more detail, best to ask for it explicitly with sprintf:

  my $a = 4253.95;
  my $b = 0.9;
  my $c = $a + $b;
  print "$a + $b = $c\n";
  printf "%.30f + %.30f = %.30f\n", $a, $b, $c;
[download]

If you use this with your real code, it is more likely to show you the actual difference between the numbers you get when you enter them explicitly as above and those derived in your code. My guess would be accumulated rounding errors; another possibility would be something modifying $# (see perlvar), but trying to create a testcase to illustrate that I can't get it to do anything at all.

Hugo