Re: Fw: [PATCH 3/3] libm: Adjust errno/exception values for gamma/lgamma
Brian Inglis <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Organization | Systematic Software |
| Message-ID | <[email protected]> |
On 2020-08-27 11:55, C Howland via Newlib wrote: > On Wednesday, August 26, 2020 1:03 PM, Keith Packard wrote: >> This makes all of gamma/lgamma functions match POSIX (and glibc) for >> errno and exception values for both gamma and lgamma functions. >> >> The big change is to support the exception/errno value differences for >> tgamma/lgamma for negative integer arguments. tgamma produces >> EDOM/FE_INVALID while lgamma produces ERANGE/FE_DIVBYZERO. >> >> This was done by splitting the lowest level __ieee754_lgamma*_r >> functions apart. The new lower-level ___ieee754_lgamma*_r functions >> can now produce exceptions which are correct for either lgamma or >> tgamma and use the value in the signgamp parameter to select which >> mode to operate in. >> >> All functions now return EDOM/FE_INVALID for -INFINITY, although POSIX >> doesn't specify this behavior for lgamma. It does match glibc at >> least. > I think you're looking at an old GLIBC. From my RHEL7 lgamma() man page: > " If the result overflows, a range error occurs, and the functions > return > HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively, with the correct > math‐ > ematical sign. > ... > BUGS > In glibc 2.9 and earlier, when a pole error occurs, errno is set > to > EDOM; instead of the POSIX-mandated ERANGE. Since version 2.10, > glibc > does the right thing." > POSIX has only pole and range errors listed for lgamma(), both of which > return ERANGE, so it is definitely improper to return EDOM. It should be > range, so ERANGE/FE_OVERFLOW is what it ought to be. RHEL7 uses an *old glibc* 2.17 from 2012, compared to Fedora Rawhide with latest glibc release 2.32. Check out the specs at the tops of the *current glibc* sources of the gamma functions to be found nearby online under: https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/ieee754/dbl-64 -- 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.]