** Using WeBWorK **

When the answers are formulas, WeBWorK compares a student's answer to the author's answer by choosing a bunch of random numbers for input and evaluating both at those values. If the outputs always agree, WeBWorK declares the formulas equal. This is how something like 1/(sqrt(x) - 1) is ruled as equal to (sqrt(x) + 1) / (x - 1). It's not because WeBWorK has any kind of computer algebra system in it. It is also permitted to have outputs be undefined for both answers, as will happen for roughly half of the random inputs when sqrt(x) is the answer.

Occasionally with answers like the one in your example, all of the randomly chosen inputs are negative through bad luck. In this case, if all of the random inputs for the variable "a" were negative, then all of the outputs would be undefined, and there is no way for WeBWorK to evaluate if the student's answer is equivalent to the problem author's answer. And then you get this message about not having enough valid test points for comparison.

The random numbers that are chosen are chosen based on the random seed that has been assigned to the student for that problem. I would bet that if you tried the same seed for the problem on the two different servers, that you would get the same behavior on both servers.

In any case, the solution to the issue is to have set the "domain" for the variable "a" to be appropriate in the first place. Probably for "b" too, since I'm not sure how the perl will handle "b^(2/3)". You can do this following what you see here: http://webwork.maa.org/wiki/FormulaTestPoints#.VDYqi-fI9gs

If you do fix this problem this way, and it is an OPL problem, it would be nice if you would commit that change in your git repository for the OPL, push it up to a GitHub fork, and then submit a pull request to https://github.com/openwebwork/webwork-open-problem-library. Eventually over time we could attack all the bugs like this in this way.

By the way, the code that you have here does not actually check that the student hasn't merely copied the original expression. "ab/(a^(1/2)b^(1/3))" will be counted as correct. I think that if you used bizarroArithmetic.pl, with bizarro power turned on, you might be able to check that the answer has actually been simplified. Instructions on how to use bizarroArithmetic.pl are in the comments at the top of the file. If you end up needing to also make use of bizarro division, then you should make decimals not allowed with Parser::Number::NoDecimals(); Because if you use bizarro division, then 1/2 is not equal to 0.5.

Lastly, have you considered whether you would want "sqrt(a)*b^(2/3)" to count as correct? Or if you use parserRoot.pl, if you would want "sqrt(a)*root(3,b^2)" to count as correct? If so, you would need to think about how to implement those alongside bizarroArithmetic.pl.