-> RP>   ATN(z / SQR(-x * x + 1 + 1E-37))
-> RP> The 1E-37 seems mysterious but all it does is add a tiny number
-> to the RP> result to avoid division by zero errors.
-> This is very clever; thanks for posting it!
Yes. My first reaction, when I saw it, was that a round-off error could
still give x the precise value that would make the denominator of the
fraction zero. But then I realized that this value would be
(+/-)(1 + 5E-38) (very, very nearly). And there's no way that BASIC can
store a number with that many digits. x would be rounded off to exactly
1. So my imagined problem can't happen.
Another interesting thing is that the order in which the additions are
done is important. The 1E-37 must be added in last. If, for example, the
denominator of the fraction were written: sqr(1 + 1E-37 -x*x), which is
mathematically identical to the original, BASIC would have to hold an
intermediate value of (1 + 1E-37), which it can't do. So the 1E-37 would
be lost. I would be almost tempted to use another pair of brackets:
((1 - x*x) + 1E-37), to make absolutely certain that things are done in
the right order.
However, even after all this admiration, I still feel a bit uneasy about
this trick. I just don't like the thought of deliberately introducing an
error into a calculation, however small. I think I still prefer to trap
out the divide-by-zero possibility some other way.
Each to his own taste.
                              dow
--- PCBoard (R) v15.3 (OS/2) 5
---------------