## WeBWorK Problems

### 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_PGMLWhat is [[$ans]]?[___________]{\$ans}
END_PGMLENDDOCUMENT();

### Re: contextInequalities.pl and previous answer comparison

by Alex Jordan -

Amending what I originally said: submitting:
x!=-4, x!=4
is *not* counted as correct. I guess it should not, since that is like listing two unions of intervals, not intersecting them.

If you submit that twice in a row, the second attempt produces error messages while also displaying the green bar that "All of the above answers are correct." And I passed:
bypass_equivalence_test => 1
to the checker and it doesn't change the behavior, so maybe this is not about the equivalence check with the previous answer.

The error messages are:

ERRORS from evaluating PG file:  Missing close parenthesis for '('; see position 1 of formula at line 824 of [PG]/macros/contextInequalities.pl
Died within Inequalities::Inequality::new called at line 37 of [PG]/lib/Parser/List/Interval.pm
from within Parser::List::Interval::_eval called at line 88 of [PG]/lib/Parser/List.pm
from within Parser::List::eval called at line 63 of [PG]/lib/Parser/List.pm
from within Parser::List::new called at line 402 of [PG]/lib/Parser.pm
from within Parser::Close called at line 143 of [PG]/lib/Parser.pm
from within Parser::parse called at line 50 of [PG]/lib/Parser.pm
from within Parser::new called at line 19 of [PG]/lib/Value/Formula.pm
from within Value::Formula::new called at line 64 of [PG]/macros/Parser.pl
from within main::Formula called at line 100 of [PG]/macros/Parser.pl
from within main::Compute called at line 99 of (eval 6075)

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.