WeBWorK Problems

contextInequalities.pl and previous answer comparison

contextInequalities.pl and previous answer comparison

by Alex Jordan -
Number of replies: 2
In the problem pasted below, a user might enter:
x!=-4, x!=4

It's marked correct and everything is OK. But if the user submits it a second time, the answer is marked correct but there are error messages. So something about using contextInequalities in this way is not working with the comparison of an answer to the previously submitted answer.

I will probably disable that comparison globally. It sporadically causes errors like this. But I thought this was worth reporting.

DOCUMENT();

loadMacros(
  "PGstandard.pl",
  "MathObjects.pl",
  "PGML.pl",
  "contextInequalities.pl",
);
TEXT(beginproblem());
Context("Inequalities");
$ans = Compute("(-inf,-4)U(-4,4)U(4,inf)");
BEGIN_PGML

What is [`[$ans]`]?

[___________]{$ans}
END_PGML

ENDDOCUMENT();
In reply to Alex Jordan

Re: contextInequalities.pl and previous answer comparison

by Alex Jordan -
In reply to Alex Jordan

Re: contextInequalities.pl and previous answer comparison

by Davide Cervone -

OK, this was a tricky one, and it took my quite a while to track it down.

It turns out that it is not the answer checking that is producing the error, but the rather Compute() call itself where the error is being produced. That, together with the fact that it only occurs for the second submit, suggests that there is some bleed through from one processing of the problem to the next. Since the base MathObject library code is loaded into the main memory used by the https child process, not into the safe compartment like macro files are, that could happen if something during the problem processing was changing an object within the shared code. That turns out to be what was happening here, but it took a bit for me to find it.

The base contexts (Numeric, Interval, Vector, etc.) are created in the shared code when the child process starts up, and when a problem asks for a given context, a copy is made in the safe compartment so that changes made by the problem to the context won't affect the original context definition. That was specifically to avoid the kind of problem happening here. Well, there are some other shared objects as well, and one is the %Value::Types hash that contains definitions for common object types, like numbers, intervals, etc. It turns out that when a list of inequalities is created, it needs to mark that fact by setting a field in its type definition to "Inequalities"; but the original type object was actually the shared type object for an Interval object, and so the shared definition of an interval was changed so that it said it was an inequality. That was retained in the child process, so the next time the problem ran, when the Compute() command tried to create an interval (as part of the union of three intervals), the first interval that was created thought it was an inequality rather than an interval, and that lead to the context trying to convert what it thought was an inequality back into an interval, which failed with the message you received.

The solution is to use a new type object rather than modify the old one when converting an interval to an inequality, and I've made a pull request that does that. You could take the contextInequalities.pl file from that for now, if you want.