### How can an answer be a list of linear equations?

by Mary Cameron -### Re: How can an answer be a list of linear equations?

by Davide Cervone -`parserImplicitPlane.pl`

, but you'd have to upgrade your copy of PG to get it. I've attached the updated copy here. You can put this in the `templates/macros`

directory of your course until the PG at your institution is updated (then remove it).### Re: How can an answer be a list of linear equations?

by Mary Cameron -### Re: How can an answer be a list of linear equations?

by Paul Pearson -### Re: How can an answer be a list of linear equations?

by Robin Cruz -### Warning messages

`Use of uninitialized value $ld in numeric eq (==) at line 169 of [TMPL]/macros/parserImplicitPlane.pl`

### Re: How can an answer be a list of linear equations?

by Davide Cervone -### Re: How can an answer be a list of linear equations?

by Robin Cruz -### Warning messages

`Use of uninitialized value $ld in numeric eq (==) at line 169 of [TMPL]/macros/parserImplicitPlane.pl`

### Re: How can an answer be a list of linear equations?

by Davide Cervone -The initial error about undefined

`$ld`

was because that code forces the earlier answer to be treated as a Formula and so it loses the fact that it is an ImplicitPlane object and the data associated with that. I have fixed that in an updated copy of parserImplicitPlane.pl. There is a "raw" button on the linked page that you can use to obtain a copy of the file (use your browser "Save" menu to save it to disk and them move it to your course macros directory).This patch also fixes a problem when the student enters "NONE" when an ImplicitPlane was the correct answer (it used to give an error message about the answer not being an implicit plane; now it is marked incorrect silently).

The second issue, about the message saying the answer is the same as the previous one, is more difficult to fix, and I haven't done that yet. This comes from the fact that you have a list of implicit planes. Because the planes are formulas, the list is converted from a list of formulas to a formula returning a list. That is fine for the student answer checking (since formulas returning lists are broken up again during answer checking). But the check to see if a formula is equivalent to the previous one is done by a simple equality check of the two formulas, and that means the lists are evaluated at the test points for the formula and the results are compared to see if the lists agree at each test point.

The equal signs in the formulas produce the result 1 if the two operands are equal and 0 if not, and for random points, the equation of the plane usually is not equal, so you get lists with just a bunch of zeros as the entries, and that means that the two lists

*do*agree on the test points. That is why the message is produced. The upshot is that the implicit planes are not being checked for equality as they should be in that case, and that leads to the incorrect message.

I'm not sure what the best way is to address the problem, as the code that is handing this is not part of the parserImplicitPlane.pl file. I have to think harder about how to overcome the problem. Probably the real solution is to not convert lists of formulas to a formula returning a list, but that is a fairly fundamental change to MathObjects that would need to be handled very carefully. It is not a quick fix. I'll see if I can come up with something better for the time being.