$a
is actually just the real number 6 (equivalent to Real(6)
), not a Formula object, but with its correct_ans
field set to the string C(4,2)
(and its correct_ans_latex_string
set to the appropriate thing). When you do $a*$b
, you end up with the equivalent of Real(18)
, again just a Real MathObject. The Real inherits properties from the first factor ($a
), but some properties where supposed to be removed, including the correct_ans
, since it no longer applies. The correct_ans
did get removed, but the correct_ans_latex_string
did not (this value was added rather recently, so hasn't had a lot of testing), which is why it shows up a C(4,2)
in the correct answer rather than 18 as it should have. I will need to fix that bug.
One way to handle this is the following:
Context()->flags->set(reduceConstantFunctions=>0,reduceConstants=>0); $a = Formula("C(4,2)"); $b = Formula("C(3,2)"); BEGIN_PGML The answer is [______________]{$a*$b} END_PGMLThis works, but the type of answer will be a Formula, so you will get error messages that say you are looking for a Formula, and it will not give error messages if you include x in your answer.
If you really want to get it right, you need to do something like
Context()->flags->set(reduceConstantFunctions=>0,reduceConstants=>0); $a = Formula("C(4,2)"); $b = Formula("C(3,2)"); $d = $a*$b; $d = $d->eval()->with( correct_ans => $d->string, correct_ans_latex_string=> $d->TeX ); BEGIN_PGML The answer is [______________]{$d} END_PGMLThis will produce the proper error messages (since
$d
is a Real), while showing the proper correct answer (since the correct_ans
is set explicitly). A bit unpleasant, but it works.