## Forum archive 2000-2006

### Nandor Sieben - undef as result for function evaluators

by Arnold Pizer -
Number of replies: 0
 undef as result for function evaluators topic started 5/31/2005; 7:56:44 PMlast post 6/2/2005; 6:59:58 PM
 Nandor Sieben - undef as result for function evaluators  5/31/2005; 7:56:44 PM (reads: 1573, responses: 10) Suppose the correct answer in a problem is the function ln(-x). Then the function evaluator cannto use the default [0,1) interval to check if the student answer is correct. It needs to use something like [-10,0). Now if the student tries the answer ln(x) then the evaluator rejects this as an incorrect answer (this is good) but it also gives a warning that ln(x) cannot be evaluated at some negative number (this is bad). Is there any way to avoid this warning? Is there any reason that undef is not a completely legal output for function evaluation that does not cause any errors? In fact if the correct answer is x/|x| then I'd like to compare the student answer at the points -2, -1, 0, 1, 2 and I'd like to make sure that the student function and the correct function both evaluate to undef. Currently I'd get an error since 0 is not in the domain. Having undef as a valid value that can be compared would make the choice of the test points simpler, perhaps even more robust. An interval of [-20,20] with 30 test points would work in almost all cases even if the answer in not definded on the interval [-2,infty). Nandor <| Post or View Comments |>

 Nandor Sieben - Re: undef as result for function evaluators  6/1/2005; 12:16:46 AM (reads: 1805, responses: 0) > If the professor's function were sqrt(x-30), for example, it would > produce undef all the time on your interval; should that match > sqrt(x-40)? I suppose one could require that some portion of the > points produce something other than undef. Well, the [-20,20] interval certainly doesn't work in this situation. The suggested solution should work though. Maybe give a warning if more than half of the tested values are undef. The default input set could be something like {-1000,1000} U [-20,20]. I realize nothing is going to work completely but allowing undef instead of error might give more flexibility even when the default needs to be changed. It might be a good idea not to have any defaults and force the instructor to define a domain. >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. It's arguable but I believe ln(abs(x)) is an incorrect answer in this case and it should be rejected. Nandor <| Post or View Comments |>

 Davide P. Cervone - Re: undef as result for function evaluators  6/1/2005; 7:42:53 AM (reads: 1811, responses: 1) It's arguable but I believe ln(abs(x)) is an incorrect answer in this case and it should be rejected. If the natural range of x's in the problem are all positive (as I stipulated), then ln(abs(x)) = ln(x) for all x, so the functions are equal and I don't see why you think this should be rejected.  I realize nothing is going to work completely but allowing undef instead of error might give more flexibility even when the default needs to be changed. I agree that it is certainly worth looking into, and I've been thinking about how to do it using the new Parser. I only meant to point out that the implications need to be carefully considered. Function comparison is so central to the operation of WeBWorK that changes to it can't be taken lightly. Davide <| Post or View Comments |>

 Gavin LaRose - Re: undef as result for function evaluators  6/1/2005; 8:03:44 AM (reads: 2142, responses: 0) A similar issue came up when I was working on the gateway/quiz testing module that I've been working on in the past year. In this case (I claim, at least that) it's undesirable to have the evaluator tell the student (e.g., when previewing) if the student answer isn't correct because of a domain error. My work-around was to add a flag to the fun_cmp() evaluator that tells it not to report domain errors. That is, we assume that the evaluator is defined for a domain on which the correct answer is well-defined, so if the student's answer isn't defined there, it's wrong. But the actual error message isn't reported. Gavin <| Post or View Comments |>

 Nandor Sieben - Re: undef as result for function evaluators  6/1/2005; 11:24:09 AM (reads: 1788, responses: 1) > If the natural range of x's in the problem are all positive (as I > stipulated), then ln(abs(x)) = ln(x) for all x, so the functions are > equal and I don't see why you think this should be rejected. If we want to be absolutely precise then we define a function together with it's domain like f:[0,inf)-> R, f(x)=ln(x). This function is the same as g:[0,inf), g(x)=ln(|x|). We don't wanna use this type of precision in WebWork and we use the standard practice of defining a function with it's formula with the assumption that the domain is the largest subset of R or of C for which the expression makes sense. With this practice f(x)=ln(x) and g(x)=ln(|x|) are not the same. The natural domain for x should not be an extra condition that hides somewhere in the background. The student's answer has the opportunity to encode the information about the natural domain by producing undef outside the natural domain. So why not live with this opportunity if we can. If we asked the questiion this way: Find a formula for f:[0,inf)->R that satidfies blah blah. Then I agree that both ln(x) and ln(|x|) are perfectly correct. I admit that this is splitting hair a little bit but hey we are mathematicians we like splitting hair :-) Nandor <| Post or View Comments |>

 Davide P. Cervone - Re: undef as result for function evaluators  6/2/2005; 6:59:58 PM (reads: 1790, responses: 0) OK, I've implemented the undefined value checking that we have been discussing as part of the function comparison in the new Parser's answer checker. This is an optional feature that you need to enable explicitly by setting the checkUndefinedPoints flag in the Context() or in the formula itself. When this is done, test points where the function is undefined will be retained and the student's answer will have to be undefined at the same points. If the points are selected at random, the points where the function is undefined are kept in addition to the ones where it is defined, so the required number of test points where the function is defined will still need to be able to be found. The number of undefined points can be up to the number of defined points. This number can be reduced by setting the max_undefined flag. If you want to guarantee that a specific undefined point be tested, you can provide that point using the test_points field of the formula. For example:  Context()->flags->set(checkUndefinedPoints=>1); $f = Formula("(x^2-1)/(x-1)");$f->{test_points} = [[-1],[0],[1],[2]]; ANS($f->cmp); will guarantee that the singularity at x=1 is tested, so the answer x+1 will not be marked as correct. If an answer matches at all the test points where the functions are both defined, but some of the undefined points differ between the two functions, the answer checker will generate an error message indicating that the domains of the functions don't agree, as in John's suggestion. (This is only generated when the functions match except for that.) This can be controlled by setting the showDomainErrors flag in the formula's cmp() call:  ANS($f->cmp(showDomainErrors=>0)); The default is to show these errors. I hope that satisfies the requirements we have discussed. I think it will be a useful addition to the answer-checker repertoire. Davide <| Post or View Comments |>