http://www.perlmonks.org?node_id=881955


in reply to Re^2: Why does perl math suck?
in thread Why does perl math suck?

The order in which the operations are done matter more than the number of operations. Using a/d + b/d + c/d instead of (a + b + c)/d can yield different results, and not because of the number of operations.

Replies are listed 'Best First'.
Re^4: Why does perl math suck? (order)
by tye (Sage) on Jan 13, 2011 at 16:03 UTC

    A more specific and illustrative example is $small+$huge1-$huge2 where ($small+$huge1)-$huge2 is easily much less accurate than $small+($huge1-$huge2) (where parens imply order of evaluation, which isn't always the case).

    For example: 

    #!/usr/bin/perl -lw
use strict;
my $h1= my $h2= 1e20;
my $s= 1.2345;
print $s+$h1-$h2;
print $s+($h1-$h2);
__END__
0
1.2345

    [download]

    (I'd actually be surprised to see an example where the difference you proposed, ($a+$b+$c)/$d vs $a/$d+$b/$d+$c/$d, made more than a couple of least-significant bits of difference in the result -- though that would be enough to thwart the use of ==, of course.)

    - tye        

[reply]
[d/l]
[select]

      where parens imply order of evaluation, which isn't always the case

      This has been bugging me. Which language would that be? Given 

      $small+($huge1-$huge2)

      [download]

      I know that Perl and C doesn't define whether $small or $huge1-$huge2 is evaluated first, but nowhere I've seen has mentioned that they can apply mathematical equivalence rules that don't work with floats to refactor equations. The LHS of the "+" in the code will be used as the LHS of the "+" operator, and similarly for RHS.

[reply]
[d/l]
[select]

      I'd actually be surprised to see an example where the difference you proposed,

      It looked fishy to me too. I must have been thinking about the case you posted. Thanks for the correction.

[reply]

In Section Seekers of Perl Wisdom