WeBWorK Problems

Parameter-matching fails with unexpected results

Parameter-matching fails with unexpected results

by Philip Loewen -
Number of replies: 2

Here attached is a short .pg file (in the PGML style) whose operation mystifies me. Expert commentary would be much appreciated.

Students are asked for a particular solution to an ODE like ay"+by'+cy=f. I'd like to accept the sum of the simplest particular solution I can think of with any solution to the homogeneous equation. The WW functionality involving variables of type "Parameter" should be able to do this, but something very strange is happening. If I put in my favourite particular solution, the answer is rejected; if I add to it any nonzero solution of the homogeneous equation, the answer is accepted. What's happening, and what should I do to achieve the expected results?

Technical notes: (1) I completely removed all random elements, so others should be able to reproduce this issue. (2) I found this first on my University's WW 2_15 installation, but the same thing happens on my basement VM installation of WW 2_16.

I just know this is going to be an amazing learning opportunity. Thanks.

In reply to Philip Loewen

Re: Parameter-matching fails with unexpected results

by Danny Glin -
My experience with adaptive parameters in WeBWorK is that they make answers much more sensitive to minor differences. Since WeBWorK is solving for the values of the parameters, small differences between the correct answer and the student answer can be amplified.

There are a couple of things going on here.

By default the Numeric context contains the variable x. When you add the variable t (and the two parameters), you now have a function of both x and t. In general this will be invisible to students, since it should still mark correct answers as correct (subject to the other considerations below), but in the background it is evaluating the correct answer at values of both x and t, and it also will allow students to enter answers in terms of both x and t.

What you want is for the only variables present to be t and the two parameters. Probably the most concise way to do this is to use
Context()->variables->are(t => 'Real', a => 'Parameter', b => 'Parameter');

Having x around isn't the source of the issues, but it can make things more complicated.

When WeBWorK displays a correct answer, it does not show the full precision for real numbers (see https://webwork.maa.org/moodle/mod/forum/discuss.php?d=5735), so despite the fact that it shows (-0.542857*t+0.186122)*e^(4*t) as the correct answer, if you display the values of $A and $B in the question, they are actually -0.542857142857143 and 0.186122448979592 respectively, so typing the answer to six decimal places ends up not being within the default tolerance, which is why it can be marked wrong depending on the values of the parameters a and b.

These sort of small numerical differences can be amplified by exponential functions, since they can easily lead to very small (or very large) function values. This can be somewhat mitigated by setting the domain of evaluation for t, with the goal of having the function values not get too close to 0. This is extra complicated for functions that involve exponential functions of opposite signs (like in this case the answer involves e^(4t) and e^(-3t)), since making one of those large makes the other one small. The default domain for each variable is [-2,2], but for a question like this you may want to keep the t-values closer to 0 by setting something like
$ans->{limits} = [0,1];

One more useful tool is to enable diagnostics for your answer checker:
ANSWER: [`\quad y_{p}(t) =\ `][__________________________________________________]{$ans->cmp(diagnostics=>1)}

This will show you the values at which WeBWorK is evaluating the answer, and give you some detail on numerical tolerances.

With all this being said, I have been using similar questions for years and still occasionally run into a situation where something that should be marked right is marked wrong because of numerical tolerances. In general I do my best to design questions so that the student answers are integers, which eliminates a lot of the rounding error. For your example, if you choose $c to be a multiple of $den (e.g. $c = $den*random(1,5,1);), then the values of $A and $B will be integers, which will reduce the rounding errors entered by students. With that being said, there is always the perspective that answers shouldn't always be nice, which is an individual decision.
In reply to Danny Glin

Re: Parameter-matching fails with unexpected results

by Philip Loewen -

Thanks a lot for this swift and richly informative reply.

Changing the limits on t to the interval [-1,1] did the trick for me. I didn't know about the option to request diagnostics from the answer-checker, and I love it. Looking at the specifics of my little problem and suggesting algebra-friendly improvements takes your kind engagement to the next level. Big gratitude from out west!