Use of C99 extra long double math functions after r236148
Peter Jeremy
peter at rulingia.com
Sun Jul 29 23:53:12 UTC 2012
[Pruning CC list to keep mailman happy]]
On 2012-Jul-29 17:39:27 -0500, Stephen Montgomery-Smith <stephen at missouri.edu> wrote:
>On 07/29/2012 05:27 PM, Peter Jeremy wrote:
>> WG14/N1256 G.6. I hadn't considered extending that to verifying that
>> purely real or imaginary inputs give purely real or imaginary outputs,
>> with the appropriately signed zero. This might be reasonable but it's
>> not completely trivial to implement in general since the domains of
>> the real part can be different.
>
>Maybe this should be a different program, since its logical structure
>would be quite different. In particular, you wouldn't be checking the
>value of the non-zero parts.
Adding code to skip checks on the real or imaginary part of the
result is quite easy.
>Also I forgot that the real part of casinh(0+I*x) isn't always 0. If
>|x|>1, it is something non-zero. And so you need to check that
>creal(casinh(0+I*x)) and creal(casinh(-0+I*x)) have opposite signs in
>this case.
This is related to my "domains can be different" comment. Adding code
to restrict the domain of the argument to be compatible with the real
function isn't too hard (off the top of my head, I think the domains
are all one of [-1,1], [0,Inf] or (0,Inf]). Handling behaviour
outside that domain requires more special-casing because the behaviour
is less consistent.
>> I'm less sure of the next logical
>> step, which is to check things like
>> casinh(x + I*0) = asinh(x) + I*0
>
>Does C99 mandate this?
Nope. They are just mathematical equivalences (at least within the
domains supported by the real function). POLA implies that they
should be true but unless they are special-cased, the complex variant
probably has less accuracy as a result of the additional calculations
to support the imaginary component.
> My programs probably won't satisfy this, because
>I realized that the computation works in these cases anyway. Of course,
>it would be easy to make it happen.
It's probably up to the implementation - special casing pure real or
imaginary arguments should give those cases a shorter and simpler (and
therefore faster and more accurate) calculation but it's a matter of
whether this case in common enough to justify the additional test(s)
in all cases.
It's also just occurred to me that doing so may result in unexpected
output discontinuities between cfoo(x-I*tiny), cfoo(x-I*0), cfoo(x+I*0)
and cfoo(x+I*tiny).
--
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/20120729/cee4ddb9/attachment.pgp
More information about the freebsd-numerics
mailing list