From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: newlib@sourceware.org
Subject: Re: Fw: [PATCH 0/3] libm: Clean up gamma functions
Date: Thu, 27 Aug 2020 20:03:29 -0600 [thread overview]
Message-ID: <a0515976-fd8c-ca20-78c6-594a1f8688b8@SystematicSw.ab.ca> (raw)
In-Reply-To: <87lfhzej39.fsf@keithp.com>
On 2020-08-27 17:59, Keith Packard via Newlib wrote:
> 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.
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.]
next prev parent reply other threads:[~2020-08-28 2:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-26 17:03 Keith Packard
2020-08-26 17:03 ` [PATCH 1/3] libm: Fix sign value returned from __ieee754_lgamma*_r(-0) Keith Packard
2020-08-26 17:03 ` [PATCH 2/3] libm: Remove __ieee754_gamma_r variants Keith Packard
2020-08-26 18:20 ` Corinna Vinschen
2020-08-26 19:10 ` Keith Packard
2020-08-27 7:24 ` Corinna Vinschen
2020-08-27 17:05 ` Keith Packard
2020-08-28 8:19 ` Corinna Vinschen
2020-08-28 8:34 ` Corinna Vinschen
2020-09-01 16:33 ` Fabian Schriever
2020-09-01 17:23 ` Keith Packard
2020-09-02 8:03 ` Corinna Vinschen
2020-09-02 20:37 ` Keith Packard
2020-09-03 8:04 ` Corinna Vinschen
2020-09-03 15:59 ` Brian Inglis
2020-09-03 21:25 ` Keith Packard
2020-09-03 22:09 ` Brian Inglis
2020-09-04 0:01 ` Keith Packard
2020-09-04 0:27 ` Brian Inglis
2020-09-04 1:37 ` Keith Packard
2020-09-04 13:03 ` Corinna Vinschen
2020-09-04 16:19 ` Keith Packard
2020-08-26 17:03 ` [PATCH 3/3] libm: Adjust errno/exception values for gamma/lgamma Keith Packard
[not found] ` <SN5P110MB0383012287522E8285674CAB9A550@SN5P110MB0383.NAMP110.PROD.OUTLOOK.COM>
2020-08-27 17:55 ` Fw: " C Howland
2020-08-27 19:28 ` Brian Inglis
[not found] ` <SN5P110MB0383186ECD9B028A4B0E2ECC9A550@SN5P110MB0383.NAMP110.PROD.OUTLOOK.COM>
2020-08-27 17:43 ` Fw: [PATCH 0/3] libm: Clean up gamma functions C Howland
2020-08-27 23:59 ` Keith Packard
2020-08-28 2:03 ` Brian Inglis [this message]
2020-08-28 3:13 ` Keith Packard
2020-08-28 3:51 ` Brian Inglis
2020-08-28 17:13 ` Keith Packard
2020-08-28 18:29 ` Joseph Myers
2020-08-28 19:32 ` Keith Packard
2020-08-28 19:53 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a0515976-fd8c-ca20-78c6-594a1f8688b8@SystematicSw.ab.ca \
--to=brian.inglis@systematicsw.ab.ca \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).