Re: Proposal: Trigonometric functions in degrees - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Proposal: Trigonometric functions in degrees
Date
Msg-id CAB7nPqS+wg+iWeL7pC1MS3ELmf4==XjJewH9_HPk+jx4NQ1E-g@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Trigonometric functions in degrees  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Proposal: Trigonometric functions in degrees  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Sun, Nov 1, 2015 at 9:34 PM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> On 27 October 2015 at 08:24, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>> I think it's still feasible to have sind(30) = 0.5 exactly and keep
>> monotonicity....
>>
>
> Here's a patch along those lines. It turned out to be fairly
> straightforward. It's still basically a thin wrapper on top of the
> math library trig functions, with a bit of careful scaling to ensure
> that curves join together to form continuous functions that are
> monotonic in the expected regions and return exact values in all the
> special cases 0,30,45,60,90,...
>
> I also modified some of the CHECKFLOATVAL() checks which didn't look
> right to me, unless there's some odd platform-specific behaviour that
> I'm not aware of, functions like sin and asin should never return
> infinity.

The alternative expected outputs for test float8 need to be updated,
this is causing regression failures particularly on win32 where 3
digits are used for exponentials and where tan('NaN') actually results
in an ERROR. See for example the attached regressions.diffs.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Uh-oh: documentation PDF output no longer builds in HEAD
Next
From: Adam Brightwell
Date:
Subject: Re: bootstrap pg_shseclabel in relcache initialization