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 54CF9386F401 for ; Fri, 28 Aug 2020 03:51:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 54CF9386F401 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 BVPuk1e4wng7KBVPvk87jC; Thu, 27 Aug 2020 21:51:07 -0600 X-Authority-Analysis: v=2.3 cv=ecemg4MH c=1 sm=1 tr=0 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=13zjGPudsaEWiJwPRgMA:9 a=s58qX92hAAAA:20 a=b4LDLZbEAAAA:8 a=7DBnviNHoRFRbFUWpioA:9 a=QEXdDO2ut3YA:10 a=deaLXQ9wXIOqZgZLmfkA:9 a=FfaGCDsud1wA:10 a=20T61YgZp4ItGotXEy2O: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> <87imd3ea46.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: <64f92545-b6b2-4381-e300-13d1039e7554@SystematicSw.ab.ca> Date: Thu, 27 Aug 2020 21:51:05 -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: <87imd3ea46.fsf@keithp.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I3NcO5tjMotZLH94pW6jsMrW4XdkjTBNH" X-CMAE-Envelope: MS4wfEpVc8VYXmhnsBfUmPi7D4hBmVeCmgomXcSXo+aS4HmcjAHwOS4LQmL3lAkC33ZFWDkgMhc1dBzR6xjqqwocO3wasM+Ii8rcZjbDbTz0XGl8o3wokdpp jRxNfWhDmvdMMLi4xivYnhNp5AMYyjdul4HjQTr2E2NbeZ+1bbRdd3CT2mfDmPvamgOBRKn+ARYsLg== X-Spam-Status: No, score=-7.9 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 03:51:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I3NcO5tjMotZLH94pW6jsMrW4XdkjTBNH Content-Type: multipart/mixed; boundary="eqSjssGHVA4hllhK0poAG9M2N2B2PldHn" --eqSjssGHVA4hllhK0poAG9M2N2B2PldHn Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: quoted-printable On 2020-08-27 21:13, Keith Packard wrote: > Brian Inglis writes: >=20 >> 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 l= gamma, >> tgamma pp272-273, 7.31.1 complex clgamma, ctgamma p332, F10.5.3 lgamma= and >> F.10.5.4 tgamma. >=20 > Thanks for the link -- the difference for lgamma is that in C99: >=20 > A range error occurs if x is too large. A range error may occur= > if x is a negative integer or zero. >=20 > While in C17: >=20 > A range error occurs if positive x is too large. A pole error > may occur if x is a negative integer or zero. >=20 > Frustratingly, tgamma still returns different errors. In C99: >=20 > A domain error or range error may occur if x is a negative > integer or zero. A range error may occur if the magnitude of x > is too large or too small. >=20 > While in C17: >=20 > A domain error or pole error may occur if x is a negative > integer or zero. A range error occurs if the magnitude of x is > too large and may occur if the magnitude of x is too small. >=20 > C17 appears to have added this new 'pole' error, which seems to match > what the IEEE 754 calls a 'divideByZero exception'. Let's see if my > understanding of the various errors is correct: >=20 > IEEE C17 POSIX errno Exception > divideByZero Pole Pole ERANGE FE_DIVBYZERO > invalid Domain Domain EDOM FE_INVALID > overflow Range Range ERANGE FE_OVERFLOW >=20 > POSIX is more specific than C17, but it does appear to have been update= d > to follow that spec, including the term 'Pole Error' which wasn't in > C99. >=20 > As my tests all refer to the POSIX spec (which defines the > errno/exception values), I think they're correct. Here's the set of > values I'm testing for both tgamma and lgamma (I'm not testing gamma > currently; we need to sort out what it should be doing first): >=20 > Value tgamma lgamma > POSIX result errno exception POSIX result errno = exception >=20 > +0 Pole +INFINITY ERANGE FE_DIVBYZERO Pole +INFINITY ERANGE= FE_DIVBYZERO > -0 Pole -INFINITY ERANGE FE_DIVBYZERO Pole +INFINITY ERANGE= FE_DIVBYZERO > -1 Domain NAN EDOM FE_INVALID Pole +INFINITY ERANGE= FE_DIVBYZERO > +3e38f Range +INFINITY ERANGE FE_OVERFLOW Range +INFINITY ERANGE= FE_OVERFLOW > +1.7e308 Range +INFINITY ERANGE FE_OVERFLOW Range +INFINITY ERANGE= FE_OVERFLOW > -3e38f Domain NAN EDOM FE_INVALID Pole +INFINITY ERANGE= FE_DIVBYZERO > -1.7e308 Domain NAN EDOM FE_INVALID Pole +INFINITY ERANGE= FE_DIVBYZERO > +inf None +INFINITY 0 0 None +INFINITY 0 = 0 > -inf Domain NAN EDOM FE_INVALID None +INFINITY 0 = 0 >=20 > I have rationalized the differences in this way: >=20 > Domain error means there is no defined limit for the function > approaching the parameter. Pole error means that there *is* a > defined limit in this case. >=20 > For non-positive inputs, the limit of the value of the tgamma > function depends on whether that limit is approached from above= > or below. >=20 > For zero, we can separate out 'approach from below' and > 'approach from above' with the sign -- -0 might well be the > result of an underflow from below, hence returning the value of= > the function as approached from below makes "sense", in this > case -INFINITY. Similarly, +0 might well be underflow from > above, so the function can return +INFINITY. In both cases, as > the limit is well defined, this represents a Pole error rather > than a Domain error, hence the differences in errno and excepti= ons. > =20 > For negative integers, as the limit depends on whether the valu= e > is approached from below or above and we have no way of > distinguishing these two cases from the input, the limit is not= > well defined, so we have a Domain error and return > NAN/EDOM/FE_INVALID. >=20 > For the lgamma function, the limit for non-positive integers is= > always +INFINITY because it returns ln(|=CE=93(x)|). This makes= it > well defined and hence a Pole error rather than a Domain error >=20 > Huge negative values (-1e308) are negative integers, and hence > treated that way, generating a Domain error for tgamma and Rang= e > error for lgamma >=20 > +INFINITY input and +INFINITY output generate *no* error > presumably because there's an assumption that the computation > which resulted in +INFINITY being provided to these functions > already raised a FE_OVERFLOW exception, and perhaps an ERANGE > errno. >=20 > Please review the table above to see if you agree about what errno and > exception values each of the provided inputs should generate. I'd reall= y > like to know if you can suggest additional test cases to use to validat= e > the correctness of these functions. I don't get so don't do maths above my comfort level: but it is possible = that ORs in the specs could mean that some important implementations (e.g BSD = and glibc) may differ in errors reported depending on which, possibly differe= nt, exceptional input values are passed. You could check the BSD and glibc sp= ecs and tests for these functions to see what the expected outputs are for what i= nputs, what exceptional values generate which errno values, and whether all possibilities are allowed by all the specs. POSIX always defers to C wher= e the latter defines library implementations, but as long as they do not contra= dict normative content, POSIX may add additional conditions or requirements. --=20 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.] --eqSjssGHVA4hllhK0poAG9M2N2B2PldHn-- --I3NcO5tjMotZLH94pW6jsMrW4XdkjTBNH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTDOf5W1Pe9BgUtm2QetpcbvdiPGAUCX0h/KgAKCRAetpcbvdiP GDKLAQDHZI7l4IGDJudrUvUWVBSh+471kiR+i/6OFz63YgTR6AEA3cwvIUgoq8i4 vJXMYFYEQUTBKIU4ma3ki04DqJJTLgo= =cy7O -----END PGP SIGNATURE----- --I3NcO5tjMotZLH94pW6jsMrW4XdkjTBNH--