While converting some old problems to use the LimitedComplex context instead of separate boxes for Real and Imaginary parts, I found the "Correct Answer" column might display an incorrect value even though the actual answer is scored correctly. E.g., 6 + 5.5 i is displayed as the first Correct answer for the following example.
#### Correct Answer column shows first argument of answer computation
#### $w instead of $wz
#### Computation of $zmw shows one method to fix that difficulty.
DOCUMENT();
loadMacros( "PGstandard.pl", "MathObjects.pl", "contextLimitedComplex.pl" );
Context( "LimitedComplex-cartesian" ) ;
# Context( "LimitedComplex" ) ; ## display error appears here too
# Context( "Complex" ) ; ## display error appears here too
$w = Compute( "6 + 5.5 i" ) ;
$z = Compute( -4.5 + 2.5 * i ) ;
$wz = $w + $z ;
$zmw = Compute( $z - $w ) ;
TEXT(beginproblem);
BEGIN_TEXT
Write each answer in the form \( a + b i \)
where \(a\) and \(b\) are real numbers.
$PAR
\( $w + $z = \) \{ ans_rule(20) \} $wz
$PAR
\( $z - $w = \) \{ ans_rule(20) \} $zmw
END_TEXT
$showPartialCorrectAnswers = 1 ;
ANS( $wz -> cmp , $zmw -> cmp );
ENDDOCUMENT();
A similar difficulty was discussed in June 2008:
http://wwrk.maa.org/moodle/mod/forum/discuss.php?d=141
Note: for this type of simple arithmetic, it is not a fix to do the initial computations in Complex context with
$wz = Compute( "$w + $z" ) ;
and then switch to LimitedComplex for student answers (because the Correct Answer column shows the formula instead of numerical result). A discussion of quoted versus unquoted input to Compute in October 2009 is relevant.
http://wwrk.maa.org/moodle/mod/forum/discuss.php?d=452
There are several things going on here, one of which is a bug (I have fixed it in version 1.99 of pg/lib/Value.pm), but the other is a misunderstanding of the Compute() macro.
Compute has several puproses, the principle one being to convert a string (representing a formula like a student would type as an answer) into a MathObject for use in the problem. A second purpose is to make the initial string be the correct answer string (rather than the RESULT of the formula being the correct answer). This allows authors to specify exactly what they want the answer to look like, rather than it always being the computed result. (A third use is to take a non-MathObject like a perl real and convert it to a corresponding MathObject; a fourth use is to make a copy of a given MathObject.)
Many authors are confused about the difference between these four operations, and that seems to be the case in your problem as well. Your first Compute() call is an example of the first use described above: convert "6 + 5.5 i" to a Complex MathObject. It also sets the correct answer string for $w to be exactly "6 + 5.5 i".
Your second Compute(), however, is a example of the fourth use, and is essentially unnecessary. The expression -4.5 + 2.5 * i already produced a Complex MathObject (by virtue of the fact that "i" is already a Complex MathObject, and operations like * and + on a MathObject will produce another MathObject), so there is no need for Compute() in this case; it simply makes a copy of the Complex MathObject, sets its correct answer string to be the string version of the complex number, and returns that. You could just as easily have said
Your assignment for $z could just as easily have been
$z = -4.5 + 2.5 * i;
and that would have been more concise and more readable. Similarly, your original assignment for $w could have been
$w = 6 + 5.5 * i;
Your computation of $wz uses the fact that MathObjects combine to form other MathObjects, which is great. Unfortunately, it is this line that the bug affected. During an operation like addition, the resulting MathObject inherits some of the values of the original objects that were combined, and this process mistakenly passed the correct-answer value from $w on to the result of $w + $z. That is the error that I have corrected in the Value.pm file.
Your Final use of Compute() is also of the fourth type; since $z - $w is already a Complex MathObject, there is no need for Compute() in this case, which just makes a copy of that MathObject, and sets the correct answer string to the stringified version of the object. It is that last action (setting the correct answer to the stringified version of the object) that saved the day for you, however, since otherwise the correct answer would have been inherited from $z (incorrectly).
Ironically, had you used Compute() when you computed $wz, you would have gotten the correct answer to display properly. Alternatively, had you used Complex() rather than Compute() for $w and $z, you would have had the proper correct answer. Or if you had not used Compute() but rather the $w = 6 + 5.5 * i form, all would have been well. It was the combination of Compute() with the inheritance bug that was the problem.
My recommendation to you is to use
$w = 6 + 5.5 * i;
$z = -4.5 + 2.5 * i;
$wz = $w + $z;
$zmw = $z - $w;
and avoid Compute() entirely in this problem. This will work even if you have variables in place of the constants for $w and $z.
Hope that clears things up.
Davide
Thanks, Davide, for clarifying the Compute procedure and the crucial detail that '... "i" is already a Complex MathObject ...'.
Your discussion also seems to imply several items in http://webwork.maa.org/wiki/Introduction_to_MathObjects
(last modified 16 November 2009) should be revised.
3rd example: $z = Complex("1 + 5i");
6th example: $z = Compute("1 + 5i");
3 more examples in How to create a MathObject
$b = Complex(3, 4); or
$b = Complex("3 +4i"); or
$b = Compute("3+4i");
dick
Your discussion also seems to imply several items in http://webwork.maa.org/wiki/Introduction_to_MathObjects
(last modified 16 November 2009) should be revised.
3rd example: $z = Complex("1 + 5i");
6th example: $z = Compute("1 + 5i");
3 more examples in How to create a MathObject
$b = Complex(3, 4); or
$b = Complex("3 +4i"); or
$b = Compute("3+4i");
dick
Yes, a lot of the documentation needs revision. Most of the Wiki documents were written by others, and they do contain some incorrect, inefficient, or non-optimal material. Fortunately, when you see something that needs updating, you can make the change yourself (no need to wait for me), since it is a Wiki!
Davide
Davide