## WeBWorK Main Forum

### Problems having answer be list of ImplicitEquations ### Problems having answer be list of ImplicitEquations

by Christian Seberino -
Number of replies: 6
The following problem runs without error messages
but when I display the answers
it doesn't show the equations x = 1, x= -1, y = 0.
Rather, it shows "x-1, x+1, y"  as if the = symbol and the 0 were being dropped.

Any ideas?

cs

DOCUMENT();
"PGstandard.pl",
"PGML.pl",
"MathObjects.pl",
"PGcourse.pl",
"parserNumberWithUnits.pl",
"contextArbitraryString.pl",
"parserImplicitEquation.pl",
"parserPopUp.pl",
"contextInequalities.pl",
"PGgraphmacros.pl",
);
TEXT(beginproblem());
$showPartialCorrectAnswers = 1; ###################################################################### Context("ImplicitEquation") ; Context()->flags->set(tolerance => 0.01); Context()->variables->set( x=>{limits=>[-10,10]}, y=>{limits=>[-10,10]} );$menu_e = PopUp(["select one", "even", "odd", "neither"], "even");
$menu_o = PopUp(["select one", "even", "odd", "neither"], "odd");$menu_n = PopUp(["select one", "even", "odd", "neither"], "neither");

BEGIN_PGML
Answer the following questions regarding the function
[\frac{1}{1 - x^2}].

Is the function even, odd or neither?

What are all the horizontal and vertical asymptotes of the function, if any?

[________________________]{List(ImplicitEquation("x=1"),
ImplicitEquation("x=-1"),
ImplicitEquation("y=0"))}
END_PGML

######################################################################
ENDDOCUMENT(); ### Re: Problems having answer be list of ImplicitEquations

by Davide Cervone -
Try using
    [________________________]{"x=1,x=-1,y=0"}


I'm not sure why the other way doesn't work as expected. I'll have to look into it.

Davide ### Re: Problems having answer be list of ImplicitEquations

by Christian Seberino -
Replacing the ImplicitEquation wrapper with Compute wrappers also works...

[________________________]{List(Compute("x=1"),
Compute("x=-1"),
Compute("y=0"))}

I'm actually blown away by your answer.  Not only did you omit the List function but you omitted all the Compute functions as well?  Is this a new feature?  Does every string automagically get treated like it is in a Compute function now?  Or maybe it has always been that way but I just didn't get the memo.  Either way that will make things much nicer.

Thanks & Sincerely,

Chris ### Re: Problems having answer be list of ImplicitEquations

by Davide Cervone -
Is this a new feature? Does every string automagically get treated like it is in a Compute function now?

This is not new, it has been there from the beginning. (You can see it in some of the examples in the PGML lab on line.) This is how the answers were intended to be given, with explicit use of MathObject constructors only needed for special cases (like lists with only one entry).

Davide ### Re: Problems having answer be list of ImplicitEquations

by Davide Cervone -
Note that you might be better off using parserAssignment.pl rather than contextImplicitEquation.pl for this. The ImplicitEquation object is not as reliable, and would allow funny answers like y^3 = 0 to be marked correct for y=0, or 1 = 1/x for x = 1. I suspect you would not want those answers to be marked correct.

Davide ### Re: Problems having answer be list of ImplicitEquations

by Christian Seberino -
Davide

Thanks for pointing out that distinction between those macro files.

(I'm sure you know the distinctions I'm making below.  I'm partially just making sure *I* understand it correctly...)

It seems parserAssignment.pl is more strict about HOW the equation is entered.
That can be nice but a teacher needs to decide on a case by case basis if he
wants/needs that level of uniformity.

I'm thinking of, say an algebra problem, where a student needs to find the equation of a line.  Both x - y = 1 and y = x - 1 are equivalent and correct.
The former would require contextImplicitEquation.pl and the latter could
benefit from parserAssignment.pl if desired.  The teacher may want to specify
the need for "standard form" to get the former and "slope intercept form" to get the latter.

In short,  contextImplicitEquation.pl is good for the "big tent" solution where you are open to different formats.

cs Yes, you are right, parserAssignment only allows the expression in the form "x = ..." or "y = ...", so it would not accept x - y = 1 as equivalent to y = x - 1.
On the other hand, x - y = 1 is better handled through parserImplicitPlane.pl than parserImplicitEquation.pl. It is best to avoid ImplicitEquation whenever possible.