Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On 19 April 2016 at 05:16, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote:
>>> 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?

> I'm not sure it's really worth having the test output something like
> 45.0000000000000001 since that extra detail doesn't really seem
> particularly useful beyond the fact that the result wasn't exactly 45.
> Also you'd have to be careful how you modified the test, since it's
> possible that 45.0000000000000001 might be printed as '45' even under
> extra_float_digits=3 and so there'd be a risk of the test passing when
> it ought to fail, unless you also printed something else out to
> indicate exactness.

Yeah, what I was thinking of printing is something like

asind(x),
asind(x) IN (-90,-30,0,30,90) AS asind_exact,
...

with extra_float_digits=3. The point of this is not necessarily to give
any extra information, though it might, but for failures to be more easily
interpretable. If I'd forgotten how the test worked just a few months
after committing it, how likely is it that some random user faced with a
similar failure would understand what they were seeing?

Also, though I agree that it might not help much to know whether the
output is 45.0000000000000001 or 44.9999999999999999, our thoughts would
be trending in quite a different direction if it turns out that the
output is radically wrong, or even a NaN. The existing test cannot
exclude that possibility.

regards, tom lane