WeBWorK Problems

Answer precision in PGML -- mend a broken heart!

Answer precision in PGML -- mend a broken heart!

by Philip Loewen -
Number of replies: 2

We want to calculate a number S. I ask the students to find an interval [a,b] that contains S, and enter the numbers a and b in different boxes. Then I ask them to express their answer like a physicist, by entering S as  m plus-or-minus epsilon, where m is the midpoint of [a,b] and epsilon is the radius.

Heartbreak occurs in the following scenario. First, the student finds an interval [a',b'] whose endpoints are within some relative tolerance of the true endpoints, and WW marks their interval correct. Second, the student calculates m', the midpoint of [a',b'] and epsilon', the corresponding radius. Of course m' is close enough to m to get marked right also, but the relative error in epsilon' is enormous and that answer gets marked wrong. I'm not asking about the math here, but rather the psychology. The student thinks they are doing a simple manipulation on a bunch of ingredients that WW has endorsed and inexplicably getting marked wrong. I sympathize with their frustration.

Now for the questions.

1. One obvious solution is to insist on more accuracy in the computation of the original interval, so wrong answers can't be accepted by mistake. What is the approved PGML way to do this? (Can it be done inline, through some modification to the familiar  [`a=`][_____]{$answer_a} ?)

2. Does WW include a context or format for numbers that triggers one of those helpful yellow text-box replies saying something like, "Your answer looks pretty close but I'm not going to accept it until you show some more significant digits"?

Thanks!  (PS: For forum purposes, I would much rather be answered like a beginner than like an expert. Extra thanks if you kindly take on that extra challenge!!)

Tags:
In reply to Philip Loewen

Re: Answer precision in PGML -- mend a broken heart!

by Alex Jordan -

The "correct" answers are a, b, m, and e. And they have some dependencies: a+b=2m, b-a=2e.

The student enters a', b', m', and e'. It's probably more important that the primed numbers have the corresponding relationship than it is for e' to equal e. So I would recommend something that checks the answers as a package deal instead of anything that checks four independent answers.

One option for that would be to use parseMultiAnswer.pl. Here is an example problem file:
https://webwork.maa.org/wiki/AlgebraicFractionAnswer1
In a nutshell, you declare a multianswer object associated to all four answer blanks, and you write a little code to assess how the student submission is assessed. You would probably want a' to equal a and b' to equal b, but then assess m' and e' based on a' and b'.

The important bit will be like the following. Which I did not try, so apologies if it has bugs.

$multians = MultiAnswer($a, $b, ($a+$b)/2, ($b-$a)/2)->with(
    singleReslt => 0,
    allowBlankAnswers => 1,
    checker => sub {
        my ( $correct, $student, $self ) = @_;
        my $scores = [0,0,0,0];
        $scores->[0] = 1 if ($correct->[0] == $student[0]);
        $scores->[1] = 1 if ($correct->[1] == $student[1]);
        $scores->[2] = 1 if ($scores->[0] && $scores->[1] && 2*$student[2] == $student[0] + $student[1]);
        $scores->[3] = 1 if ($scores->[0] && $scores->[1] && 2*$student[3] == $student[1] - $student[0]);
        return $scores;
    }
);

In the PGML, you will declare each of the four answer blanks the same way:

[_]{$multians}{5}

(The 5 is to make it 5 characters wide without typing five underscores.)


To answer your actual posted questions:

1. It is not PGML that controls the precision on the answers. The answers are (I presume) MathObjects in a certain "context". And that context controls what level of decimal tolerance is used when each answer is compared against a student submission. See https://webwork.maa.org/wiki/NumericalTolerance

2. I'm not aware of something like that. If it existed, then let's fix some answer $a. There would be a tolerance window for something being equal to $a, and then a second larger tolerance window for something being in this close-but-not-quite-there range. You could certainly have a custom checker that did this, but I'm not sure how to package it up into a reusable context. I guess you would need more context flags to control how the outer tolerance window worked.



In reply to Alex Jordan

Re: Answer precision in PGML -- mend a broken heart!

by Philip Loewen -
Thanks a lot for responding, Alex. I'll think about these suggestions, and report back if I can add anything more of value from my side.