WeBWorK Problems

Incorrect answer being marked correct

Incorrect answer being marked correct

by Darwyn Cook -
Number of replies: 2
[I've moved this discussion to a new topic, since it is no longer related to the prime notation -- Davide]

Tested this on our production server and on my laptop virtual server, both running the head version of pg. Would someone be willing to see if they have the same problem, that is webwork marks both answers it asks for correct.

DOCUMENT(); # This should be the first executable line in the problem.


$showPartialCorrectAnswers = 1;
Context("Numeric")->variables->{namePattern} = qr/[a-z][a-z0-9_]*'*/i;

$m = Compute(random(1,5)); # the in flow will be a multiple of the outflow
$a = Compute(random(1,3));

$diffeqn = Formula("A'-$a+ A/($m(1000+t))");
Type \($diffeqn\) \{$diffeqn->ans_rule(30)\}
then type \(A'-$a + \frac{A}{$m(1000+2t)}\)

In reply to Darwyn Cook

Re: Incorrect answer being marked correct

by Davide Cervone -
The problem is in the limits used for the various variables. Note that the usual range is -2 to 2 for MathObject Formulas, so A', A and t are all in that range. But since you divide A by m(1000+2t), that means the last term is several orders of magnitude smaller than the first term, so any errors the student introduces there show up in the third or fourth decimal places (at best). But the default tolerance ignored errors that small, so they don't have any effect. (Moreover, since 2t is small in comparison to 1000, the student errors are really in the 6th or 7th decimals, well below the tolerance).

To fix it, you need to set the limits for the various variables so that they make the magnitudes of the terms be approximately equal (so errors in any one of them have the same effect on the total error of the equation). You need the size of A to balance out the size of the denominator, so A should be on the order of 1000m, and you want 2t to be about the size of 1000, so t should be on the order of 500.

One solution, then, is to use

      A => {limits=>[$m*1000,$m*1000+100]},
      t => {limits=>[500,600]},
right after the creation of the $m and $a values. This should bring errors in the second term up to the same size as errors in the first term.


PS, if you add diagnostics=>1 to the cmp() call, as in

you will get a display that includes the points used in the comparison and their relative and absolute differences. That can help you see what is (or isn't) going on, and is how I diagnosed the problem.
In reply to Davide Cervone

Re: Incorrect answer being marked correct

by Darwyn Cook -
Well that's a bit embarrassing. Nice sleuthing as usual, I owe you a beer or two if you drink the stuff.