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

On 2020-08-27 17:59, Keith Packard via Newlib wrote:
> C Howland via Newlib <[email protected]> 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.

Last C17 public FDIS N2176 is available via:

https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

see 7.12.8.3 lgamma and 7.12.8.4 tgamma on pp181-182, 7.26 tgmath #5 lgamma,
tgamma pp272-273, 7.31.1 complex clgamma, ctgamma p332, F10.5.3 lgamma and
F.10.5.4 tgamma.

>> 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.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]