Hi:
I'm using a lot of functions that are undefined on various intervals, so I have been trying to use
->with(test_at =>
to force evaluation safely inside the domains.
However, I find that I am not allowed to evaluate some functions at points even though they are within the domain and they don't result in overflow.
As a simple example, if I use the following code for testing the function xsqrt(1 + 24x):
*********************************
Context("Numeric");
Context()->variables->are(
x=>"Real",y=>"Real"
);
parser::Assignment->Allow;
$answer = Formula(" x sqrt(1+24x) ")->with(test_at => [[2],[3],[4],[5]]);
********************************
it will say I can't evaluate at any of the points, even though the function is well-behaved there, and numbers aren't large.
In know that I can instead use an interval
>with(limits=>[0,100]);
and it seems to work fine - at least for the few random seeds that I test it on.
I have 2 questions.
1) What is causing it to reject seemingly "good" points? (or is this really happening?)
2) If for some reason WW can't evaluate at certain points, and I use an interval containing these unknown points that seems like a safe interval, how can I prevent random students from getting random test points that can't be evaluated, and that might cause their correct answer to be graded as incorrect?
Any help would be appreciated!
Thanks,
-Bentley
Hi Bentley,
Point 1: If you had only one variable (x) in your context, what you have would probably work just fine. However, you have two variables (x and y) in your context, so you need to specify both an x-value and a y-value for each test point. For instance, try
test_at => [[2,1],[3,1],[4,1],[5,3]]
where (2,1) = (x,y) is the first test point, etc. The variables are always specified in lexicographic order. For more info, see
http://webwork.maa.org/wiki/FormulaTestPoints
Point 2: If you use proper syntax and coding, webwork can evaluate any function at any point in its domain (even though the value of the function may be ridiculously large in magnitude or close to zero). I usually specify the domain of the function so that the function values will be smaller than 1000 in magnitude and not within 10^(-4) of zero. This generally avoids problems due to numbers that are "too large" or "too close to zero" to check reliably using the answer checker default values. If the answers are naturally large and it is unavoidable, consider using absolute tolerance instead of relative tolerance. In general, "think like an analyst" -- use delta and epsilon thinking to choose a reasonable domain and numerical tolerances that will give robust answer checking.
Best regards,
Paul Pearson
Hi Paul:
Thanks for your reply!
That clears it up. I was actually confused because earlier I was getting the same message "can't evaluate at points...," but for another reason: the points appeared to be in the domain, but were not in the domain of the actual called function. The function was (1-3tanx)^(1/3), and I was getting the same message because it was evaluating where the base was negative. It's my understanding that this is because it was really computing e^[(1/3)ln(1-3tanx)].
Are there any other situations like this - where the actual called function has a different domain from the one used in the problem - that could cause such error messages?
Thanks, again,
-Bentley
Thanks for your reply!
That clears it up. I was actually confused because earlier I was getting the same message "can't evaluate at points...," but for another reason: the points appeared to be in the domain, but were not in the domain of the actual called function. The function was (1-3tanx)^(1/3), and I was getting the same message because it was evaluating where the base was negative. It's my understanding that this is because it was really computing e^[(1/3)ln(1-3tanx)].
Are there any other situations like this - where the actual called function has a different domain from the one used in the problem - that could cause such error messages?
Thanks, again,
-Bentley