From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) by sourceware.org (Postfix) with ESMTPS id 7A6933851C2A for ; Fri, 28 Aug 2020 02:03:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7A6933851C2A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id BTjlkv7MM62brBTjmkMFc0; Thu, 27 Aug 2020 20:03:31 -0600 X-Authority-Analysis: v=2.3 cv=LKf9vKe9 c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=CCpqsmhAAAAA:8 a=s58qX92hAAAA:20 a=b4LDLZbEAAAA:8 a=uZvujYp8AAAA:8 a=jChkm-x5hCMFubTIiR0A:9 a=QEXdDO2ut3YA:10 a=ZHFgC012yJgA:10 a=ul9cdbp4aOFLsgKbc677:22 a=20T61YgZp4ItGotXEy2O:22 a=SLzB8X_8jTLwj6mN0q5r:22 Reply-To: newlib@sourceware.org Subject: Re: Fw: [PATCH 0/3] libm: Clean up gamma functions To: newlib@sourceware.org References: <20200826170357.2551683-1-keithp@keithp.com> <87lfhzej39.fsf@keithp.com> From: Brian Inglis Autocrypt: addr=Brian.Inglis@SystematicSw.ab.ca; prefer-encrypt=mutual; keydata= mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5 RSyTY8X+AQ== Organization: Systematic Software Message-ID: Date: Thu, 27 Aug 2020 20:03:29 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <87lfhzej39.fsf@keithp.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCWbdU3BRnc/WFtFrZE5z8nE9rUwNIo222U5e/X8ONPp0ocW1Vz1ZmYnolIvkZeDtPTK6TJdO/1aMoJ0wYuH8Y/pEVnSHrmhbmMmN1x4c/bAwvLeW6q0 5carOYaZSgQKLuL2PHa6DbgxekSVAl1hPnlM1up6l0Nhd+7lcRCiagiKPzf6yc8MElMfQkRP9ERkaA== X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 02:03:35 -0000 On 2020-08-27 17:59, Keith Packard via Newlib wrote: > C Howland via Newlib 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.]