Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees. - Mailing list pgsql-hackers

From Noah Misch
Subject Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.
Date
Msg-id 20160419041631.GC1983345@tornado.leadboat.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote:
> >> 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?
> 
> Hm?  The expected answer is exact (30, 45, or whatever) in each case.
> If we get some residual low-order digits then it's a failure, so we don't
> need to worry about whether it's the same failure everywhere.

Does something forbid snprintf implementations from printing '45'::float8 as
45.0000000000000001 under extra_float_digits=3?



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.
Next
From: Etsuro Fujita
Date:
Subject: Re: Optimization for updating foreign tables in Postgres FDW