I don't know if anyone brought up a similar issue in evaluating answers that are rational expression entered with MathQuill.
After some of my colleagues contacted me about the issue, I changed the default for assistive tool for helping students to enter their answer to WIRIS.
Both WIRIS and MathView don't present any issue with answers with expressions with exponents and rational expressions.
I use MathQuill for all of my classes. I have never seen that problem.
I suspect there is an issue with that problem that is causing this and not MathQuill, based on the errors that are being displayed, i.e., "the evaluated answer is not an answer hash". Could you post the PG source for that problem?
Just out of curiosity, what happens if you type in "(3/(x-3))", either in text mode in MathQuill, or directly into a text box?
So you have confirmed that this has nothing to do with MathQuill. The problem is the incorrect design of these problems. The pedagogy is completely incorrect. An instructor should absolutely never count an answer incorrect for additional parentheses. In fact, the usage of additional parenthesis should be encouraged.
The reason that this is happening is because MathQuill adds extra parenthesis to maintain correctness in order of operations as the answer is visually displayed when the student types the answer into the MathQuill answer box. Those additional parentheses are mathematically correct, just as additional parentheses are when a student uses them.
When a student types 3/(x-3) as a vertical fraction (without typing any parentheses), then MathQuill passes the answer (3/(x-3)) to webwork. In this case those additional parentheses are not needed, but MathQuill is not a mathematical program. It doesn't know if there are other things typed before or after that might make those parentheses be necessary. The answer is still mathematically correct, and no grader should count off for that.
The same thing is happening in this problem as well. MathQuill is adding parentheses around the exponents to maintain correctness in that case as well. You can see this in the "Entered" column of the results table. WeBWorK removes most of these extra parentheses when it parses answers and this is why it shows up without those parentheses in the "Preview" column. Without those parentheses there would be no difference between the answers x to the power of 23 and x to the power of 2 times 3 (for one example). Both cases would be sent to webwork as x^23. Again the answer is mathematically correct, and should not be counted off for even if this were what the student had entered in a text input (without MathQuill).
The problem comes down to lines 417 - 432 of the file CollegeOfIdaho/CofIdaho_macros.pl from the OPL that this file is using. Those lines should not be in that file. Those lines check for extra parentheses and count off for it. Bad!
First, my apologies for not reading the full thread here. I hope what I am posting is relevant.
If you have problems that want basic algebra expressions in "simplified", "factored", "expanded" form, etc., try using contextFrom.pl (which is in the OPL, in the PCC macros folder). For example, here is a minimal problem file. Then two screenshots with MathQuill in use. One with correct answers accepted, and one showing what happens if the form is not right. The context is flexible in certain senses, like (x+1)(x+2) is counted equivalent to (2+x)(x+1), etc. But it catches the things that math teachers are trying to catch.
If this works for you, it /might/ be as easy as visiting each problem, loading contextForm.pl, and activating Context("Form") immediately prior to the declaration of the answer formula.
DOCUMENT();
loadMacros(
"PGstandard.pl",
"MathObjects.pl",
"PGML.pl",
"contextForm.pl",
"PGcourse.pl",
);
##############################################
Context("Form");
$display = Formula("(3x+9)/(x^2-9)");
$answer = Formula("3/(x-3)");
$display2 = Formula("x^2+3x+2");
$answer2 = Formula("(x+2)(x+1)");##############################################
TEXT(beginproblem());
BEGIN_PGML
a. Simplify [` [$display] `].
[_]{$answer}{20}
a. Factor [` [$display2] `].
[_]{$answer2}{20}
END_PGML
##############################################
ENDDOCUMENT();
Hi Glenn,
This was an old and very long thread and I might have missed something. I don't understand why it is alright to prohibit extra parentheses in scientific notations. For me MathQuill is not doing anything wrong neither in the CofIdaho_macros case nor in the contextScientificNotation case.
I am not sure what you mean by "it is alright to prohibit extra parentheses in scientific notation". Can you clarify?
With the scientific notation context, if you enter 5x10^(-3) it will be counted wrong, even if that is correct. That is assuming that you are not using MathQuill. If you are using MathQuill it adds the parentheses, and so is graded as incorrect.
Why is it counted incorrect to enter 5x10^(-3) in the scientific notation context ?
I suppose this is a very long thread. Read the post by Robin that started the whole thing. The contextScientificNotation.pl macro removes "parens" from the context, making it so that entering such an answer will be counted correct and give the message "'(' is not allowed in scientific notation".
I think you meant that the answer will be counted INCORRECT.
Shouldn't it be counted correct? I want to encourage students to use parentheses, not discourage them.
Yeah, I meant incorrect.
I agree that this should be counted correct. I also want to encourage the correct usage of parenthesis.
Note that you can add:
Context()->parens->add('(' => {close => ')', type => 'Real', removable => 1});
to the problem to allow parenthesis again. Add this line in the problem after the call to Context("ScientificNotation").
See https://webwork.maa.org/moodle/mod/forum/discuss.php?d=4877#p14643 earlier in this thread.
Great! Thanks!