Fw: [PATCH 0/3] libm: Clean up gamma functions

[Keith Packard]

C Howland via Newlib <newlib@sourceware.org> writes:

>>         Following the C spec, gamma(-0) should be -INFINITY rather than
>>         +INFINITY, so the *signgamp value in lgamma should be -1
>>         rather than +1 for this case.
>>
> What C spec?  Neither C99 nor C11 say so that I see for lgamma().  POSIX
> makes the direct statement "If x is a non-positive integer, a pole error
> shall occur and lgamma(), lgammaf(), and lgammal() shall return +HUGE_VAL,
> +HUGE_VALF, and +HUGE_VALL, respectively."  0, regardless of sign, falls
> under that.

Right, C99/C11 doesn't mention signgam at all, so POSIX is free to
define it as it likes. That spec only says that it's value is undefined
when the parameter is a negative integer.

C99 says that , tgamma should return -INFINITY for -0. As newlib makes
'gamma' an alias for tgamma, gamma should probably return the same
thing. To make that work with our implementation of tgamma, (which uses
lgamma and the 'signgam' value), that signgam value should be -1.

> https://pubs.opengroup.org/onlinepubs/9699919799/functions/lgamma.html
> Additionally, the Linux lgamma man page, using GLIBC, says the same thing
> as quoted from POSIX (not word for word, but the identical result).
> (POSIX does require the +-0 +-INFINITY for tgamma().  Did these get crossed
> up?)
> Craig

I think we're probably just confusing gamma between lgamma and tgamma --
newlib defines gamma 'oddly' (fixed in 2/3).

I think the only problematic patch in the series is in changing the
semantics of gamma/gammaf and removing the gamma_r/gammaf_r -- we need
to decide how to recover from what looks like a mistake introduced 18
years ago.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20200827/464b7903/attachment.sig>