## Forum archive 2000-2006

### Dennis Keeler - Another square root of negative issue

by Arnold Pizer -
Number of replies: 0
 Another square root of negative issue topic started 10/12/2004; 6:58:24 AMlast post 10/13/2004; 1:46:45 PM
 Dennis Keeler - Another square root of negative issue  10/12/2004; 6:58:24 AM (reads: 2286, responses: 11) Hi. My students and I are running into an issue where (f(x))^.5 or sqrt(f(x)) are giving errors like "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 |>

 Doug Drinen - Re: Another square root of negative issue  10/12/2004; 9:07:16 AM (reads: 2556, responses: 1) WeBWorK checks answers by choosing (5 or 10) random numbers and plugging them into both the student's answer and the correct answer. If they match, the answer is deemed correct. 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 |>

 Dennis Keeler - Re: Another square root of negative issue  10/12/2004; 9:20:01 AM (reads: 2795, responses: 0) Thanks for the advice. I'm not yet to the point of writing my own problems, so maybe this is just a bug in the problems above. 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 |>  Carl F. Letsche - Re: Another square root of negative issue 10/12/2004; 12:31:40 PM (reads: 2530, responses: 1) If you really want to do a problem like this, just bury the square root a little deeper in the chain so that you *can* get a grip on a domain. 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 |>  Dennis Keeler - Re: Another square root of negative issue 10/12/2004; 3:23:43 PM (reads: 2749, responses: 0) Yes, this certainly works, Carl. Thanks. 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 |>  John Jones - Re: Another square root of negative issue 10/12/2004; 6:33:47 PM (reads: 2512, responses: 0) Specifying the domain can help, but there are some problems where you currently can't win. While it is essential that the limits range fit into the domain of the right answer, it really should fit all wrong answers. Otherwise, students enter something and get system type error messages. Student's don't always interpret this as "my answer must be really wrong". Instead, some think "the system is buggy because it is throwing error messages and all I did is submit an answer, so my answer might be right". 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 |>  Arnold K. Pizer - Re: Another square root of negative issue 10/12/2004; 6:47:23 PM (reads: 2531, responses: 1) Thanks for the bug reports, analysis, and suggested fixes. 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 |>

 Davide P. Cervone - Re: Another square root of negative issue  10/12/2004; 7:53:40 PM (reads: 2797, responses: 0) Arnie: 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 |>

 Arnold K. Pizer - Re: Another square root of negative issue  10/12/2004; 8:29:24 PM (reads: 2515, responses: 1) Thanks Davide, 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 |>

 Davide P. Cervone - Re: Another square root of negative issue  10/12/2004; 11:52:20 PM (reads: 2783, responses: 0) Thanks Arnie. 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 |>

 Arnold K. Pizer - Re: Another square root of negative issue  10/13/2004; 8:52:49 AM (reads: 2501, responses: 1) This sounds like a good option to be able to select. I'm not sure if the default should be to have it on or off. 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 |>

 Davide P. Cervone - Re: Another square root of negative issue  10/13/2004; 1:46:45 PM (reads: 2734, responses: 0) Note that the domain would expand ONLY if enough points within the given domain could not be found, so if the professor provides a reasonable domain, it would not expand. But I agree, it should not change the professor-specified domain. In terms of the (0,1) domain, remember that if enough points are found in that domain, no change need be made. Only in the case where it was too hard to find points in that domain would the domain be expanded. I don't see how that would hurt, unless you want to force the problem writer to think more carefully about the domain himself. That may be a reasonable desire. Remember, the alternative to expanding the domain is having the problem fail to be able to analyse the PROFESSOR'S answer and so produce the pink screen of death. Most of the parameters that control the answer checking are taken from global.conf (like functRelPercentTolDefault and functZeroLevelDefault). Davide <| Post or View Comments |>