Apparently WW tried to evaluate the first function (df) at pi/2, fails, and then tried to approximate the limit as x->pi/2, and doesn't quite succeed.
No, that is not what is happening. The evaluation didn't fail, and there is no limiting process involved at all. The issue is the standard one involved with numerical calculations via floating-point numbers: the finite precision of the numbers used.
What this means in this case is that pi (and therefore pi/2) are only approximations. Numbers are stored with a finite number of decimal places (about 16 to 17 digits), so you aren't evaluating at exactly π/2, but rather at a rational approximate of 16 to 17 digits precision. (Note that all numbers stored in floating-point notation on a computer are rational numbers.) So the function is defined for this value.
From a numerical standpoint, for a function that is undefined at an isolated irrational value, you will never be able to even try to evaluate the function at that value, since it can't even be represented in the set of numbers available to WeBWorK. (It is possible that the function can be undefined for other reasons, however, like the formula produces a number too large or too small to represent, but that isn't the case here.)
So since the function is actually defined at the value where we are evaluating it, why isn't the answer closer to 3? The reason here is again the finite precision being used. To understand what is going on, we need to look at the terms of the (unreduced) derivative more closely.
The derivative produced by the automatic differentiation is
sec2(x)sec(x) - (tan(x) - 3)sec(x)tan(x)
-----------------------------------------
sec2(x)
The approximation to π/2 used by WeBWorK is 1.5707963267948966, and for this
x, sec
2(
x)sec(
x) is 4.3556947031103271 × 10
48, while (tan(
x) - 2)sec(
x)tan(
x) is 4.3556947031103264 × 10
48. Note that these are equal except for the last two digits.
When you subtract these two values, the first 15 digits cancel each other, and you are left with just the 71 minus the 64, or just 7, with a lot of leading zeros. That is, of the 17 original digits, you are left with only one digit (and the least significant and most unreliable digit at that), and so there has been a catastrophic loss of precision.
This is known as "subtractive cancelation", and it is the effect at the heart of most of the problems the occur in numerical computations via computer, not round-off error, as commonly thought. Round-off error is how you get bad digits down at the least significant digits, but it is subtractive cancelation that brings those bad digits into positions of significance.
The actual values internally are, of course, in binary, not decimal, and so the decimal versions I've given above are also not exactly the numbers used internally.
The difference between the two terms in the numerator is 6.4903710731685345 × 1032, and you can see that the change of magnitude from 1048 to 1032 represents a loss of 16 digits of precision. So at this point, the computation is essentially worthless, as we have no reliable data left (only the 6 is remotely useful, and even that is not very accurate -- the rest is complete garbage). So when it is divided by the value of sec2(x) from the denominator, we don't get very close to the expected value of 3. (To get that, the numerator would need to be closer to 8 × 1032). This is why you are getting 2.4335 instead of 3.
So this has nothing to do with WeBWorK failing to evaluate at π/2 and trying to take limits, and everything to do with how floating-point numbers are stored on a computer.
In terms of your comment asking for WeBWorK to inform you that the function is not defined for π/2, that is not really possible, since you are not actually using a value where it is undefined (and never can, since that number isn't representable as a floating-point real). WeBWorK, and its MathObjects library, is not a computer algebra system, it is a numeric evaluation system. These issues are inherent in that approach, and are things that problem authors do need to be aware of, particularly places where subtractive cancelation can occur.
My real question is why are you asking for f '(π/2) in the first place, since it doesn't exist for your f ? Since f itself is undefined at π/2 (neither the secant nor the tangent is defined at π/2), it is discontinuous there, and so the derivative is not defined there. The student's answer of 3 is incorrect.
