Forum archive 2000-2006

Alberto Candel - problem precision puzzle

Alberto Candel - problem precision puzzle

by Arnold Pizer -
Number of replies: 0
inactiveTopicproblem precision puzzle topic started 12/3/2004; 7:46:55 PM
last post 12/9/2004; 2:15:12 PM
userAlberto Candel - problem precision puzzle  blueArrow
12/3/2004; 7:46:55 PM (reads: 927, responses: 3)
Problem setAlgebra12EqunsOtherTypes/ asks two find the possible solutions of an equation and to check which ones are solutions. With seed #2260 (and others), it says that none of the two possible solutions is a solution, but one of them is.

This puzzled me because the problem is fine with other seed #. After much playing around I figured out that WW (or perl) actually approximates the numbers, and in this case the equality test performed by WW on one of the solutions (line 46) gives a number of the order of 10-16 instead of just 0.

I fixed it by changing lines 46 and 47 (and lines 43 and 44 similarly) in a rather pedestrian way, but I suspect that there is a better way to fix it, isn't it? I was not able to find anything about precision in the PG manuals that I could use here.


<| Post or View Comments |>

userGavin LaRose - Re: problem precision puzzle  blueArrow
12/9/2004; 10:49:42 AM (reads: 1104, responses: 0)
Hi Alberto,

I don't have a solution to this, but I've seen behavior that I think is the same as that which you've described. In my case it's always occurred when I'm doing some calculations on a solution before handing it off to a WeBWorK answer evaluator, and those calculations result in a very small number.

For example, I'll do something like calculate
  $qu = $a/$b;
where $a is something like 1 and $b is something like 30,000, so that $qu evaluates in Perl to be 3.333e-05. Then when I hand this off to an answer evaluator, viz.,
  ANS( num_cmp($qu) );
I run into trouble with num_cmp not correctly intepreting what the e-05 means.

I haven't found a solution to this other than avoiding very small numbers, and/or putting a conditional in the text of the problem to detect this case and deal with it appropriately.


<| Post or View Comments |>

userArnold K. Pizer - Re: problem precision puzzle  blueArrow
12/9/2004; 1:43:42 PM (reads: 1094, responses: 0)
Hi Alberto,

Your analysis is correct and I can not think of a better way to fix the problem than what you did. Using = = to compare quantities that are computed with floating point arithmetic is asking for trouble even though perl uses double precision for calculations.

To be precise I changed the 4 lines

if (sqrt($A*$ans1 +$B)+$C == $D*$ans1) {$check1 = 'yes';}
else {$check1 = 'no';}

if (sqrt($A*$ans2 +$B)+$C == $D*$ans2) {$check2 = 'yes';}
else {$check2 = 'no';}


if (abs(sqrt($A*$ans1 +$B)+$C - $D*$ans1)< 1e-9) {$check1 = 'yes';}
else {$check1 = 'no';}

if (abs(sqrt($A*$ans2 +$B)+$C - $D*$ans2)< 1e-9) {$check2 = 'yes';}
else {$check2 = 'no';}


<| Post or View Comments |>

userAlberto Candel - Re: problem precision puzzle  blueArrow
12/9/2004; 2:15:12 PM (reads: 1069, responses: 0)
Thanks Gavin and Arnie for your comments.

My correction is actually a little different from yours (Arnie). I am not sure that it is any better, but I tell you anyway. I changed those first two lines to

if ($D*$ans1 -$C >=0 && $A*$ans1 + $B >=0) {$check1='yes';}
else {$check1='no';}
and similarly for the two other lines. I think it works, and avoids problems with precision (as far as I know).


<| Post or View Comments |>