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