Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4EYL-00024u-Kt for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Mar 2019 00:48:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h4EYK-00059M-8G for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Mar 2019 00:48:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4EYK-00059F-0m for pgsql-hackers@lists.postgresql.org; Thu, 14 Mar 2019 00:48:56 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4EYH-00078A-BM for pgsql-hackers@lists.postgresql.org; Thu, 14 Mar 2019 00:48:55 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x2E0mnrg027341; Wed, 13 Mar 2019 20:48:49 -0400 From: Tom Lane To: Dean Rasheed cc: Michael Paquier , PostgreSQL Hackers , laetitia.avrot@gmail.com Subject: Re: pgsql: Add support for hyperbolic functions, as well as log10(). In-reply-to: References: <20190313022159.GR13812@paquier.xyz> <24813.1552447002@sss.pgh.pa.us> <20190313050331.GT13812@paquier.xyz> <17820.1552514192@sss.pgh.pa.us> Comments: In-reply-to Dean Rasheed message dated "Thu, 14 Mar 2019 00:35:30 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27339.1552524529.1@sss.pgh.pa.us> Date: Wed, 13 Mar 2019 20:48:49 -0400 Message-ID: <27340.1552524529@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Dean Rasheed writes: > It's not unreasonable to expect these functions to be accurate to within > the last 1 or 2 digits, so testing with extra_float_digits or whatever > seems reasonable, but I think a wider variety of test inputs is required. Meh. As I said before, we're not in the business of improving on what libm does --- if someone has a beef with the results, they need to take it to their platform's libm maintainer, not us. The point of testing this at all is just to ensure that we've wired up the SQL functions to the library functions correctly. > I also wonder if we should be doing what we do for the regular trig > functions and explicitly handle special cases like Inf and NaN to ensure > POSIX compatibility on all platforms. I'm not too excited about this, but perhaps it would be interesting to throw in tests of the inf/nan cases temporarily, just to see how big a problem there is of that sort. If the answer comes out to be "all modern platforms get this right", I don't think it's our job to clean up after the stragglers. But if the answer is not that, maybe I could be talked into spending code on it. regards, tom lane