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

IIRC, the fallacy was stated, “have you stopped beating your wife?”

Well....?

One thing that is taught very early on in engineering schools is exactly how many of those digits on your pocket calculator are actually “significant.”   I remember a friend of mine explaining why, on a particularly difficult exam, the challenge of one question was how to arrive at the answer using no more than three consecutive math operations.   (Within four operations, apparently, all of the significance of the answer would have been lost.)   I nodded politely, but blankly ... and thanked my lucky stars that I didn’t go to Georgia Tech.   ;-)

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

      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

      (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        

        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)

        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.

        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.