Use of C99 extra long double math functions after r236148
Peter Jeremy
peter at rulingia.com
Sun Aug 12 23:00:18 UTC 2012
Hi Bruce or das@ or Steve,
I have a question on the following code from s_ccosh.c:
% /*
% * cosh(NaN + I NaN) = d(NaN) + I d(NaN).
% *
% * cosh(NaN +- I Inf) = d(NaN) + I d(NaN).
% * Optionally raises the invalid floating-point exception.
% * Choice = raise.
% *
% * cosh(NaN + I y) = d(NaN) + I d(NaN).
% * Optionally raises the invalid floating-point exception for finite
% * nonzero y. Choice = don't raise (except for signaling NaNs).
% */
% return (cpack((x * x) * (y - y), (x + x) * (y - y)));
x is always NaN so the real part presumably just needs to be quietened
before returning - ie (x + x) would seem to be sufficient. Why does
the code use ((x * x) * (y - y))?
y has no restriction on its value so an arithmetic operation with x is
a good way to convert it to a NaN. Wouldn't (y + x) be sufficient?
My understanding is that:
- Addition is generally faster than multiplication
- Signs are irrelevant for NaN so merging the sign of x doesn't matter.
- NaN + NaN returns the (quietened?) left-hand NaN
- Inf + NaN returns the (quietened?) right-hand NaN
- finite + NaN returns the (quietened?) right-hand NaN
Also, whilst things like ((x + x) * (y - y)) are reasonably efficient
on x86, few (if any) RISC architectures support exceptional conditions
in hardware. My understanding is that SPARC would trap back into the
userland handler (lib/libc/sparc64/fpu) on each operation unless both
arguments and the result are normalised numbers. Explicitly fiddling
with the FPU state would seem faster than multiple traps.
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-numerics/attachments/20120812/15d69242/attachment.pgp
More information about the freebsd-numerics
mailing list