On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote: > Noah Misch <n...@leadboat.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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
