AnswerHints misbehaving under certain circumstances (probably due to a Value::Error being called)

[taniwallach]

In the following problem, when the second answer is set to 1/x the AnswerHints code fails, the following errors are reported:

The evaluated answer is not an answer hash : ||.
Use of uninitialized value $credit{"AnSwEr0002"} in numeric eq (==) at (eval 1863) line 292.
Use of uninitialized value $credit{"AnSwEr0002"} in multiplication (*) at (eval 1863) line 308.

The second and third are from the pg/macros/weightedGrader.pl code.

When this is used with a weighted grader, due to that error, this part of the question is treated as having weight 1 (instead of 50 as intended by the code) so the allocation of partial credit is quite off. Without a weighted grader, the answer gets marked as incorrect but the warning about The evaluated answer is not an answer hash : ||. is still issued.

It seems that the division by zero when $student->eval( x=>0 ); is being run is causing a Value::Error to be called , and apparently that leads to a die which eventually leads to there not being a answer hash as the output of the AnswerHints code.

Ideally, I think that the AnswerHints code should avoid such a total failure. I would say that in the "worst" case, the original answer hash from before the post-filter runs could be the final result. Even better would be to try to collect the "hints" result ignoring those "cases" which fail (but to warn that some trouble was encountered).

I'm not sure how such a fix can be made to pg/macros/answerHints.pl.

A proposed fix is in #680

---

DOCUMENT();

loadMacros(
  "PGstandard.pl",
  "MathObjects.pl",
  "weightedGrader.pl",
  "answerHints.pl",
  "PGcourse.pl",
);

# Print problem number and point value (weight) for the problem
TEXT(beginproblem());

install_weighted_grader();

# Show which answers are correct and which ones are incorrect
$showPartialCorrectAnswers = 1;

# The answer for $ansD has exp(-y/n) so make most of range of y
# negative, but not too large in absolute value.

Context("Numeric");

########################################################################

$k = random( 2,4,1 );

$ans1 = Real(2);
$ans2 = Compute( "1/(x+$k)" );

BEGIN_TEXT

\( 1+1 = {} \) \{ $ans1->ans_rule(10) \}

$BR

Find the function of the form \( f(x) = \frac{1}{x+k} \)
such that \( f(0) = \frac{1}{$k} \).
$BR
\( f(x) = {} \) \{ $ans2->ans_rule(10) \}

END_TEXT

WEIGHTED_ANS( $ans1->cmp, 50 );

WEIGHTED_ANS( $ans2->cmp()->withPostFilter(AnswerHints(

  # Check initial condition f(0)
  sub {
   my ($correct,$student,$ansHash) = @_;
    if ( $ansHash->{score} == 1 ) {
      return 0;
    } elsif ( $student->class ne "Formula" ) {
      return 0;
    } else {
      $tmp = $student->eval( x=>0 );
      if ( Real( 1/$k ) != $tmp ) {
        return 1;
      } else {
        return 0;
      }
    }
  } => [ "The condition \( f(0) = \frac{1}{$k} \) is not satisfied." ],
)), 50);

ENDDOCUMENT();

[taniwallach]

PR #680 will prevent fatal errors inside the AnswerHints condition subroutine from causing the grading chain to fail so severely. As a result, the weighted partial credit of the problem will use the correct weights after the patch.

---

As suggested by @drgrice1 in #680 (review) the problem code can be fixed by changing the AnswerHints block to use:

      $tmp = 0; 
      eval { $tmp = $student->eval( x=>0 ); };

to replace

      $tmp = $student->eval( x=>0 );

so that there will not be a fatal error inside the subroutine to break the AnswerHints behavior.

[pstaabp]

fixed with #680.