The search might not converge to the same zero for both equations (student's and instructor's)
That is not a problem, since the comparison doesn't compare the zeros obtained from the two equations to each other, but rather plugs the zeros located for one equation into the other one to see if they are also zeros there. That is, the zeros of one equation must also be the zeros of the other.
the search might not result in a zero because of the shape of F(x,y)
That is certainly possible, and something that needs to be taken into consideration. One of the keys is getting the domain right so that the search for zeros will be more likely to find them.
the zero of F(x,y) might not occur in the default domain of ImplicitEquation,
Right. Again, setting the domain appropriately is important.
It seems from on-line discussions of ImplicitEquation that either implicit equations of circles are most problematic or that this context is used most often when the answer is the equation of a circle.
Circles are no more problematic than other equations, but they are fairly frequently used, so come up often.
setting the limits dynamically based on the parameters of the problem, especially when randomized, and providing solution points for the algorithms to work with resolve some problems.
These are good practices.
The final issue I had was by trying to 'fix' the ImplicitEquation context so that I could use z and i in the question. Somehow by adding those variables to the context I created some problems in the context and was getting "Can't compute the log of zero" errors.
The ImplicitEquation object uses the variables in the context to specify the domain of the formula, so if you add more variables, the dimension of the domain goes up. If the variables in the context are x, y, and z, then the ImplicitEquation will look for points in (x,y,z)-space that are zeros of the formula.
It turns out that the algorithm used in the ImplicitEquation object requires the variables to be real-valued, and that complex-valued variables cause the problem you see. The algorithm takes the distance between two test points, and if some of the coordinates are complex, then the distance is computed incorrectly, and it leads to the log of zero problem.
The take-away is that you can add real variables to the ImplicitEquation context, but not complex ones. Your use of the Complex context separately is the better approach.
Here are some comments on the code:
Context("ImplicitEquation");
Context()->{error}{msg}{"Can't find any solutions to your equation"} = " ";
Context()->{error}{msg}{"Can't generate enough valid points for comparison"} = " ";
I would not disable these messages, as they alert you to problems that are occurring with the answer checking. They indicate that the checking will not be properly performed, and so the correct/incorrect result is not necessarily reliable.
for my $i (0..6) {
$xtest[$i] = random($xmin,$xmax,0.01);
$ytest[$i] = $y1 + random(-1,1,2)*sqrt(($r1)**2 - ($xtest[$i]-$x1)**2);
}
It is customary to use foreach rather than for here, but apparently both work.
$soln1 = ImplicitEquation("(x-$x1)**2 + (y-$y1)**2 -( ($r1)**2)=0",
limits=>[[$xmin-1,$xmax+1],[$ymin-1,$ymax+1]],
...
Since your radius can be as large as 8, the extra 1 on either side might be a little small (since the circle will be relatively close to the edge of the domain). Perhaps using $xmin-$r1/2 and $xmax+$r1/2 might be better, as this gives a better chance of finding zeros.
Anyway, glad you got the problem to run. Good work!