** Using WeBWorK **

"WeBWorK was unable evaluate your function. Please check that your expression doesn't take roots of negative numbers, or divide by zero."

For instance, the naive answer to rochesterLibrary/setDerivatives7Log/mec8.pg seed 1972 is ((4x+6)/(7x-3))^-.5 which gives the above error. If one inputs 1/sqrt((4x+6)/(7x-3)) the message Error: Can't take sqrt of -2.88789. is displayed.

Of course that problem can be dealt with using log differentiation. But this issue can't be avoided in setDerivatives5ChainRule/ur_dr_5_21.pg . In that problem, the correct answer is sometimes accepted, sometimes not, depending on the luck of the draw during the random evaluation comparison.

The only solution I see on my end is to avoid any problem with square roots, though that cuts out a lot of nice ones. Any other suggestions? Thanks. -Dennis

<| Post or View Comments |>

By default, the random numbers are taken to be between 0 and 1. If your answer function's domain does not contain some portion of that interval (frequently with functions involving logs and roots), you can get those error messages.

The solution is to manually tell WeBWorK where to take its random numbers from. In the case of your function above, for instance, you could tell it to choose random numbers from the interval (1,2) by including something like:

limits => [[1,2]]

in your answer evaluator.

Note that these considerations can also cause wrong answers to appear right to WeBWorK (although this happens far less frequently). For instance, if the correct answer is "abs(x)" and the student enters "x", it will be counted correct, because those two function agree on the interval (0,1).

<| Post or View Comments |>

However, I imagine in some problems that it will be difficult to think of every possible way of writing a correct answer that involves a square root and figuring out appropriate bounds for x.

In setDerivatives5ChainRule/ur_dr_5_21.pg, the proble is to take the derivative of

sqrt($trig1($e^(x^$m*$trig2(x))))

where $trig1 can be sin or cos, and $trig2 can be sin or cos independently, and $m=2 to 5. I haven't gotten out a piece of scratch paper, but it looks challenging to find out what bounds to put on x. -Dennis

<| Post or View Comments |>

Finding the derivative of

$trig1(sqrt($e^(x^$m*$trig2(x))))

is every bit as nasty a computation, and any positive stretch of domain is fine.

Carl

<| Post or View Comments |>

Upon further reflection, I realized that for this particular question, as long as x is near 0, the expression inside the square root is positive. Using Maple to look at the various possibilities, it turns out that (0, .5) works as an interval for the original problem, as the input of the trig function will be between 0 and pi/2.

In fact, if cos(x) is in the exponent, (0, 1) works. This would explain why about 50% of my students had no trouble with this problem. -Dennis

<| Post or View Comments |>

I have run into some where there is no single domain which will work - there is no common ground between the right answer and all natural wrong answers one might give.

One solution might be to move to the new parser. In my limited experience with thus far, it doesn't seem to have this problem.

John

<| Post or View Comments |>

I changed setDerivatives5ChainRule/ur_dr_5_21.pg using the first suggestion of switching sqrt with $trig1.

For setDerivatives7Log/mec8.pg I used &ANS(fun_cmp($ans, limits => [10,15])) since things are always defined there.

Both these edited problems are now uploaded to CVS.

If Davide's parser always returns either a value or NaN, then when that becomes standard we could modify fun_cmp so that if, in comparing two functions, if one returned Nan and the other a value the functions would be declared different and if both returned NaN, then another random point would be considered. This at least would take care of some troubles but not a case where the problem author has WeBWorK check points where the function is not (or should not) be defined. This was the case with setDerivatives7Log/mec8.pg (f(x) = ln { sqrt { frac { $a x + $b } { $c x + $d } } } ) where the answer obtained by simplifying then differentiating is defined almost everywhere but the original function and the answer obtained by just differentiating is not.

Arnie

<| Post or View Comments |>

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.

Davide

<| Post or View Comments |>

I hoped you would pick up on this. It sounds like your function comparison works exactly how I think it should behave.

Arnie

<| Post or View Comments |>

One additional thing that I had considered was to have the limits for the test points dynamically determined. If we are unable to locate enough test points, the range could be enlarged until enough are found. That would avoid having to think too hard about the limits. I'm sure there would be some situation where this would be a problem, but I think it would help in most situations.

Davide

<| Post or View Comments |>

Thinking a bit more, this probably should be off by default if a prof selects a specific domain. Also since the current naive default domain of (0,1) works surprising well. So maybe I would vote for this to be off by default. Are such defaults setable in global.conf?

Arnie

<| Post or View Comments |>