The problem below produces an error
(division by zero, ultimately going back
to parserFormulaUpToConstant.pl, I think)
if the incorrectly typed answer
arcsin 1/2(x - 2) + C
is entered. (The correct answer gives no
such error, of course.)
Does anyone have an idea why this occurs?
Thanks.
William Boshuck
DOCUMENT();
loadMacros(
'PGstandard.pl',
'MathObjects.pl',
'parserFormulaUpToConstant.pl'
);
TEXT(beginproblem());
Context()->texStrings;
$f = Compute("1/sqrt(4x - x^2)");
$F = FormulaUpToConstant("arcsin(1/2(x - 2))");
BEGIN_TEXT
Evaluate the following integral.
Use \(C\) for the constant of integration.
$BR $BR
\( \displaystyle \int $f \, dx = \)
\{ ans_rule() \}.
END_TEXT
Context()->normalStrings;
ANS($F->cmp);
ENDDOCUMENT();
Can't answer the question itself. But perhaps the following observation will make it easier for someone else who does know more.
I noticed that asin(1)+c also gives the same error as an incorrect response
I think it must be how the adaptive parameters code is implemented, but I don't understand that yet.
- Brian
I noticed that asin(1)+c also gives the same error as an incorrect response
I think it must be how the adaptive parameters code is implemented, but I don't understand that yet.
- Brian
Yes, I was in a bit of a hurry when I
sent the last message. I should have
mentioned that the error seems to occur
when the answer contains a constant f(a)
where f has a vertical tangent (or cusp)
at a (e.g., asin(1), sqrt(1^2 - 1), and
even sqrt(0^3 - 0^2), but not 0^(2/2),
so even this is decided a little unevenly).
cheers,
-wb
William,
The issue actually has nothing to do with adaptive parameters, but differentiation. The the post-processing of the student's response, there is a test to see if the student's answer is linear in the constant. This is performed using differentiation.
The way that differentiation is performed does not look ahead to see if the input to a function is a constant. So, for example,
d/dx[asin(1)]
is treated algorithmically as:
d/dx[asin(u)] = 1/sqrt(1-u^2) * d/dx[u]
and now u is replaced by 1.
This is where the division by zero error is creeping in, because it deals with 1/sqrt(1-1) before noticing that d/dx[1] = 0.
I have posted a bug-report in the webwork bugzilla on this issue. I'm not sure how to avoid it right now, since it depends entirely on the student response (and would appear in ANY problem, regardless of the form of the original function) including evaluation of a function at a constant that happens to be a point where the function is nondifferentiable.
- Brian
D. Brian Walton
James Madison University
The issue actually has nothing to do with adaptive parameters, but differentiation. The the post-processing of the student's response, there is a test to see if the student's answer is linear in the constant. This is performed using differentiation.
The way that differentiation is performed does not look ahead to see if the input to a function is a constant. So, for example,
d/dx[asin(1)]
is treated algorithmically as:
d/dx[asin(u)] = 1/sqrt(1-u^2) * d/dx[u]
and now u is replaced by 1.
This is where the division by zero error is creeping in, because it deals with 1/sqrt(1-1) before noticing that d/dx[1] = 0.
I have posted a bug-report in the webwork bugzilla on this issue. I'm not sure how to avoid it right now, since it depends entirely on the student response (and would appear in ANY problem, regardless of the form of the original function) including evaluation of a function at a constant that happens to be a point where the function is nondifferentiable.
- Brian
D. Brian Walton
James Madison University