Re^4: Why does perl math suck? (order)

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

Comment on Re^4: Why does perl math suck? (order) Select or Download Code

Replies are listed 'Best First'.
Re^5: Why does perl math suck? (order) by ikegami (Patriarch) on Jan 13, 2011 at 18:09 UTC
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]
Re^5: Why does perl math suck? (order) by ikegami (Patriarch) on Jan 13, 2011 at 17:06 UTC
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]