Re: [WWdevel] Re: extraAnswerEvaluators.pl

[Davide P.C. <dp...@un...>]

> Also the rounding should not depend on the problem otherwise students 
> will get very confused as to what WeBWorK is doing.

It already does, as this depends on the format parameter and (and the 
default number format set in global.conf, which I think can be 
overridden in the problem).

> I have no problem with presenting double precision or scientific 
> notation but if others want say only 8 significant digits, then I 
> think all answers should be rounded to this accuracy before they are 
> processed to see if they are correct within the tolerance of the 
> individual problem.

That is not what currently gets done, as the values are used at the 
full precision regardless of what format is used to display them.

> WeBWork should use the value .377964473... to decide whether or not 
> the student's answer is correct.

It does, both in the traditional and Parser-based version of num_cmp

> A similar philosophy is (or at least was) used in the string answer 
> comparisons.  In numerical comparisons, things like  1/sqrt(7) are 
> translated to .377964473... which WeBWorK then sends on to the answer 
> checker.

This is correct for the PROFESSOR'S answer, but the STUDENT'S answer is 
handled entirely by the answer checker. itself (or its pre- and 
post-filters).

> In case insensitive string compare, things like AbCdE are translated 
> to ABCDE which are then sent  to the answer checker.
> In case sensitive strict string compare, the original string is just 
> reproduced.
>
> Since students see exactly what they entered in the body of the 
> problem (sticky answers), what should be  displayed under entered is 
> the numerical or string equivalent of their entered answers.

This is NOT the case for the string answer checkers.  If you use 
str_cmp("AbCdE"), for example, then the students response will be shown 
in upper case in both the entered and preview columns.  The professor's 
answer will show as "AbCdE" if you don't enter an answer in the blank 
and ask to show answers, but will be shown as "ABCDE" if you DO enter 
an answer in the blank.  (I didn't check what hardcopy with answers 
produces, but I suspect "AbCdE").  So it looks like the actual 
evaluation of the answer checker will cause a difference in this case.

I agree that they should see "the numerical or string equivalent of 
their entered answers", but we may disagree about what that means.  To 
me, in a problem where the tolerances are at .5, showing an answer as 
.377964473 is misleading, but perhaps that is just me.

Davide