Nador:
I was always bothered by the ln(x) and ln(x) problem that you
mentioned as well, and so the new Parser does not generate an error
message if the student's answer does not evaluate at one of the points
that the professor's answer does (it is quietly marked as incorrect).
There are situations where this is not really the right thing to do
(and that is why the original answer checkers report errors), but I
think the number of instances where that is the case is so much smaller
than the number of times this IS what you want to do, I chose to not
report those errors.
It would be possible to add an object class to the Parser for the
indefined value (similar to the one for infinity), but I'd need to
think more about some of the implications. It could not be used with
adapting parameters, for example.
Some things to consider:
If the professor's function were sqrt(x30), for example, it would
produce undef all the time on your interval; should that match
sqrt(x40)? I suppose one could require that some portion of the points
produce something other than undef.
If the professor's answer were ln(x) and the natural range of x's in
the problem are all positive, but the professor didn't think to
restrict the interval to (0,20], a student who entered ln(abs(x)) would
be marked wrong, since this would not produce undef on the negative
values while ln(x) would. Granted, this is the professor's mistake for
not restricting the x's to the correct range, but most problem writers
don't think about these issues, and it is not always easy to tell what
the right range really IS. Also, but making it work in more cases, you
are making it even less likely that they will think about it, and are
more likely to be caught by these situations.
Another posibility would be to report errors if the professor's answer
is undefined unless the professor specifically indicates a point or
range of points to check for undefined. That way, the problem writer
must actively request that undefined values be accepted, and so will
have to have throught about it before it is allowed.
As for [20,20] working most of the time, I think you will find that
this is not the case. There are lots of chainrule and exponential
growth situations where this large a range can cause problems. As some
of the developers are fond of saying, the function comparison algorithm
has no real right to work, and the fact that it does as well as it does
is remarkable. The issues involved are extremely subtle and
counterintuitive at times, and a change of this type would require
pretty extensive testing to earn the level of trust that the current
method has.
It's certainly worth trying out. I'll put it on my list of things to try in the new Parser.
Davide
< Post or View Comments >
