From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees. |
Date: | 2016-04-19 02:49:50 |
Message-ID: | 20160419024950.GB1983345@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > On Mon, Apr 18, 2016 at 09:17:46AM -0400, Tom Lane wrote:
> >> Given that it's apparently showing the results of asind as NULL ...
>
> > I doubt asind is returning NULL. Here's the query, which uses a CASE to
> > report NULL if asind returns any value not on a whitelist:
>
> > SELECT x,
> > CASE WHEN asind(x) IN (-90,-30,0,30,90) THEN asind(x) END AS asind,
> > CASE WHEN acosd(x) IN (0,60,90,120,180) THEN acosd(x) END AS acosd,
> > CASE WHEN atand(x) IN (-45,0,45) THEN atand(x) END AS atand
> > FROM (VALUES (-1), (-0.5), (0), (0.5), (1)) AS t(x);
>
> Oh, duh --- should have checked the query. Yes, the most probable theory
> must be that it's returning something that's slightly off from the exact
> value.
>
> > I can see the benefit for atand(-0.5) and for atand(0.5), since those are
> > inexact. Does the CASE gain us anything for asind or acosd?
>
> None of these are expected to be inexact. The point of the CASE is to
> make it obvious if what's returned isn't *exactly* what we expect.
Ah, got it.
> We could alternatively set extra_float_digits to its max value and hope
> that off-by-one-in-the-last-place values would get printed as something
> visibly different from the exact result. I'm not sure I want to trust
> that that works reliably; but maybe it would be worth printing the
> result both ways, just to provide additional info when there's a failure.
We'd have an independent problem if extra_float_digits=3 prints the same
digits for distinguishable float values, so I wouldn't mind relying on it not
to do that. But can we expect the extra_float_digits=3 representation of
those particular values to be the same for every implementation?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-04-19 03:56:55 | Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees. |
Previous Message | Tom Lane | 2016-04-19 02:22:59 | Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees. |
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2016-04-19 02:56:23 | Re: parallel query vs extensions |
Previous Message | Tom Lane | 2016-04-19 02:22:59 | Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees. |