I've been having troubles with using parserImplicitEquation.pl. (I know that the documentation says to be careful, but I tried a number of different seeds on my own which worked. Then, of course, my students found all sorts of broken ones).

I want students to enter the standard equation of a circle (x-h)^2 + (y-k)^2 = r^2.

Here is the code:

loadMacros(

"PG.pl",

"PGbasicmacros.pl",

"PGunion.pl",

"parserImplicitEquation.pl"

);

BEGIN_PROBLEM();

$r = random(1,5,1);

do {

$h = random(-4,4,1);

$k = random(-4,4,1);

} until (($h != 0 )||($k != 0));

Context("ImplicitEquation");

$std_eq = ImplicitEquation("(x-$h)^2 + (y-$k)^2 = $r^2",solutions=>[[$h,$k],[$h+$r,$k+$r],[$h-$r,$k+$r],[$h+$r,$k-$r],[$h-$r,$k-$r]]);

BEGIN_TEXT

A circle has radius \(r = $r\) and center \((h,k) = ($h,$k)\). $PAR Write an equation of the circle. (Enter the entire equation.) \{ans_rule(20)\}

END_TEXT

ANS($std_eq->cmp);

I initially had it without the solutions specified. A seed of 1654 would not display at all. It will display with the solutions specified, but the correct student answer returns an incorrect answer and "Can't find any solutions to your equation". If I understood the documentation correctly, I need to specify points where f(x,y) = (x-$h)^2 + (y-$k)^2 - $r^2 is both positive and negative. I've certainly done this. I've also tried changing the limits on the problem, to no avail. I've changed the listed solutions as well. So far, all I've been able to do is give the affected students new seeds, but I'd obviously prefer a fix, if possible.

Nathan

In reply to Nathan Wodarz
Thursday, 22 September 2011, 7:09 PM

### Re: parserImplicitEquation

by Alex Jordan -
The solutions that you have specified aren't actually solutions. You want points like [$h,$k+$r], [$h,$k-$r], etc.

This type of question is one on the examples handled here: http://webwork.maa.org/wiki/SubjectAreaTemplates

This is a good resource for lots of common problems. The example for a circle equation here tests the circle at the four cardinal points and a fifth point as well. Including this fifth point rules out a lot of other curves from being marked as correct. For example, |x|+|y|=r.

This type of question is one on the examples handled here: http://webwork.maa.org/wiki/SubjectAreaTemplates

This is a good resource for lots of common problems. The example for a circle equation here tests the circle at the four cardinal points and a fifth point as well. Including this fifth point rules out a lot of other curves from being marked as correct. For example, |x|+|y|=r.

In reply to Alex Jordan
Friday, 23 September 2011, 11:03 AM

### Re: parserImplicitEquation

by Nathan Wodarz -
I neglected to mention that I had already tried the actual solutions, however I still found the same error.

That was actually the first thing I did (although I started with just the cardinal points). When I ran into problemes, I noted that the sample problem at http://webwork.maa.org/wiki/EquationEvaluators sets 5 points for the equation "y=(x-1)^2", none of which actual work as solutions for the equation. That, together with a misunderstanding in the documentation in the actual file is what made me give the points that I did.

I also note that the documentation says that a correct answer can be marked incorrect, depending on what choice of random points is used. I assumed (perhaps wrongly?) that setting the actual solution points should solve this, since I thought that there would be no random choice remaining. However, I took the example you linked to, changed the assignments of a, b, and r to read a=1, b=1, r=1, and entered the correct answer. I submitted the answer 50 times without changing it, and it was marked correct 34 times and incorrect 16 times. I experimented by changing r=0.5 and it marked the correct answer as incorrect approximately 60% of the time. Presumably there's some problem with the small radii.

Nathan

That was actually the first thing I did (although I started with just the cardinal points). When I ran into problemes, I noted that the sample problem at http://webwork.maa.org/wiki/EquationEvaluators sets 5 points for the equation "y=(x-1)^2", none of which actual work as solutions for the equation. That, together with a misunderstanding in the documentation in the actual file is what made me give the points that I did.

I also note that the documentation says that a correct answer can be marked incorrect, depending on what choice of random points is used. I assumed (perhaps wrongly?) that setting the actual solution points should solve this, since I thought that there would be no random choice remaining. However, I took the example you linked to, changed the assignments of a, b, and r to read a=1, b=1, r=1, and entered the correct answer. I submitted the answer 50 times without changing it, and it was marked correct 34 times and incorrect 16 times. I experimented by changing r=0.5 and it marked the correct answer as incorrect approximately 60% of the time. Presumably there's some problem with the small radii.

Nathan

In reply to Nathan Wodarz
Friday, 23 September 2011, 5:17 PM

### Re: parserImplicitEquation

by Alex Jordan -
That is distressing. Have you tried redefining the domain for test points? If you add something like

limits=>[[$h-$r*1.5,$h+$r*1.5],[$k-$r*1.5,$k+$r*1.5]]

to the definition of the object, the test points will have to come from this square. Although, it seems with the values that you were using, reasonable defaults should have worked. There's one reason I can think of why small radii would be a problem. If the test points are chosen from a region a lot larger than the solution curve, then it might not find any negative values for f(x,y). But if you had this redefinition of the test field, then small radii might be less of a cause for problems.

You also might try changing the number of points that the answer checker tries to find. It looks like the default is 7, and perhaps by only listing 5, it looks for two more solutions that it has trouble finding. To do this:

Context()->flags->set(ImplicitPoints=>5);

Or you could just explicitly define 7 solution points.

(By the way, you could define these solution points to still be random, just in case you are really concerned about that. Something like:

for my $i (0..6) {

$xtest[$i] = random($h-$r,$h+$r,0.01);

$ytest[$i] = $k + random(-1,1,2)*sqrt(($r)**2 - ($xtest[$i]-$h)**2);

}

And then add

solutions=>[[$xtest[0],$ytest[0]],...,[$xtest[6],$ytest[6]]]

to the definition of the object.)

I'd love to hear about it if any of this solves the problem (so I can feel confident about writing ImplicitEquation problems in the future). And also if it does not (so I will know when to avoid them).

Alex

limits=>[[$h-$r*1.5,$h+$r*1.5],[$k-$r*1.5,$k+$r*1.5]]

to the definition of the object, the test points will have to come from this square. Although, it seems with the values that you were using, reasonable defaults should have worked. There's one reason I can think of why small radii would be a problem. If the test points are chosen from a region a lot larger than the solution curve, then it might not find any negative values for f(x,y). But if you had this redefinition of the test field, then small radii might be less of a cause for problems.

You also might try changing the number of points that the answer checker tries to find. It looks like the default is 7, and perhaps by only listing 5, it looks for two more solutions that it has trouble finding. To do this:

Context()->flags->set(ImplicitPoints=>5);

Or you could just explicitly define 7 solution points.

(By the way, you could define these solution points to still be random, just in case you are really concerned about that. Something like:

for my $i (0..6) {

$xtest[$i] = random($h-$r,$h+$r,0.01);

$ytest[$i] = $k + random(-1,1,2)*sqrt(($r)**2 - ($xtest[$i]-$h)**2);

}

And then add

solutions=>[[$xtest[0],$ytest[0]],...,[$xtest[6],$ytest[6]]]

to the definition of the object.)

I'd love to hear about it if any of this solves the problem (so I can feel confident about writing ImplicitEquation problems in the future). And also if it does not (so I will know when to avoid them).

Alex

` `

In reply to Alex Jordan
Monday, 26 September 2011, 6:30 PM

### Re: parserImplicitEquation

by Nathan Wodarz -
The change in limits seemed to do the trick.

Incidentally, increasing the number of test points helped, but not enough to justify the increased time to check the problems. Increasing to 25 test points led to my test problem marked correct about 85% of time. This was substantially better than my theoretical computations, which indicated that should the test points be chosen uniformly, the correct answer would be marked correct about 20% of the time. However, 85% is still too low for my taste.

Playing around with specifying the "solutions" attribute has left me puzzled. It seems to have no effect on the problem. I entered "abs(x-1)+abs(y-1)=0.5" for the question which asked for a circle with center (1,1) and radius 0.5. Despite only having the cardinal points as indicated solutions, this answer was correctly rejected 100% of the time (in over 50 trials).

Incidentally, increasing the number of test points helped, but not enough to justify the increased time to check the problems. Increasing to 25 test points led to my test problem marked correct about 85% of time. This was substantially better than my theoretical computations, which indicated that should the test points be chosen uniformly, the correct answer would be marked correct about 20% of the time. However, 85% is still too low for my taste.

Playing around with specifying the "solutions" attribute has left me puzzled. It seems to have no effect on the problem. I entered "abs(x-1)+abs(y-1)=0.5" for the question which asked for a circle with center (1,1) and radius 0.5. Despite only having the cardinal points as indicated solutions, this answer was correctly rejected 100% of the time (in over 50 trials).