## WeBWorK Main Forum

### indefinite integral (strange error)

by William Boshuck -
Number of replies: 3
The problem below produces an error
(division by zero, ultimately going back
to parserFormulaUpToConstant.pl, I think)

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();

'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();

### Re: indefinite integral (strange error)

by D. Brian Walton -
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
In reply to D. Brian Walton

### Re: indefinite integral (strange error)

by William Boshuck -
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

### Re: indefinite integral (strange error)

by D. Brian Walton -
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