The parser can return lots of different types of values (like vectors
and so on) in addition to numbers. It usually throws an error rather
than produce NaN, but perhaps there are cases that I missed.
The function comparison that is part of the parser already works
something like what you suggested. When the random points are chosen,
if the professor's function doesn't evaluate at the point, a new one is
chosen. If enough points can't be found, an error is generated.
When comparing to the student's answer, if the student's answer doesn't
evaluate at one of the points, the student's answer is considered not
equal to the professor's, with no error message produced. There are
some situtations where this may not be the right thing to do, say when
the student's answer has a removable singularity that has been removed
from the professor's answer. But the chances of one of the random
points falling exactly on that point is pretty slim. The confusion
caused by the "can't evaluate student input at ..." messages seem to be
much more common, and I wanted to avoid that. These tend to come not
because of an isolated singularity, but because of an interval of
places where the student's function can't be defined (like square roots
of negatives), where it is more likely that a random point will fall.
If the professor's function has one of these intervals and the
student's doesn't they are not equal.
In terms of the situation you mention about manually specifying points
where the function is NOT defined, I haven't checked to see what would
happen with that. I think it would probably be better to handle that
with a post-filter in any case.
<| Post or View Comments |>