Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Sun, Jan 31, 2016 at 9:01 PM, Piotr Stefaniak wrote: > - result = sign * cosd_q1(arg1) / sind_q1(arg1); > + result = sign * ((cosd_q1(arg1) / sind_q1(arg1)) / cot_45); > > and > > - result = sign * sind_q1(arg1) / cosd_q1(arg1); > + result = sign * ((sind_q1(arg1)

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 01/31/2016 01:23 PM, Michael Paquier wrote: Per IEEE 754, division by 0 for a double results in Nan or +/-Inf, so that's actually correct. I didn't know that. I guess that in practice that is OK and the case is closed. Interestingly to me, that assumption appears to rely on the C

Re: [HACKERS] Proposal: Trigonometric functions in degrees

These changes from 65abaab547a5758b0d6d92df4af1663bb47d545f - result = sign * cosd_q1(arg1) / sind_q1(arg1); + result = sign * ((cosd_q1(arg1) / sind_q1(arg1)) / cot_45); and - result = sign * sind_q1(arg1) / cosd_q1(arg1); + result = sign * ((sind_q1(arg1) / cosd_q1(arg1)) / tan_45); both

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Piotr Stefaniak writes: > These changes from 65abaab547a5758b0d6d92df4af1663bb47d545f > - result = sign * cosd_q1(arg1) / sind_q1(arg1); > + result = sign * ((cosd_q1(arg1) / sind_q1(arg1)) / cot_45); > and > - result = sign * sind_q1(arg1) / cosd_q1(arg1); > +

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 23 January 2016 at 23:04, Tom Lane wrote: > Noah Misch writes: >> On Sat, Jan 23, 2016 at 05:04:56PM -0500, Tom Lane wrote: >>> Either I missed something or there's another issue, because tern/sungazer >>> are *still* failing. This is getting annoying

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Jan 25, 2016 at 2:34 AM, Tom Lane wrote: > Perhaps we can fix this by rewriting as > > float8 numerator = 1.0 - cos(x * RADIANS_PER_DEGREE); > return 1.0 - (numerator / one_minus_cos_60) / 2.0; > > cockatiel's compiler does recognize

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Dean Rasheed writes: > If I understand correctly there were 2 separate issues at play here: > 1). On some platforms the compiler evaluates expressions like > sin(constant) and comes up with a slightly different result than a > runtime evaluation of the expression. The

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 1/23/16 4:18 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 1/23/16 3:05 PM, Tom Lane wrote: >>> Peter Eisentraut writes: I'm still getting a failure in float8 on OS X after commit 73193d8: > >>> Weird, because my OS X critters are all happy.

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Noah Misch writes: > On Sat, Jan 23, 2016 at 12:08:40PM -0500, Tom Lane wrote: >> So I pushed that, and tern/sungazer are still failing. Noah, could you >> trace through that and see exactly where it's going off the rails? > The second sin() is a constant, so gcc computes it

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Sat, Jan 23, 2016 at 12:08:40PM -0500, Tom Lane wrote: > I wrote: > > So the early returns from the buildfarm aren't very good: > > * tern/sungazer isn't getting exactly 0.5 from sind(30). > > > The tern/sungazer result implies that this: > > > return (sin(x * (M_PI / 180.0)) / sin(30.0 *

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Peter Eisentraut writes: > On 1/23/16 12:08 PM, Tom Lane wrote: >> So I pushed that, and tern/sungazer are still failing. Noah, could you >> trace through that and see exactly where it's going off the rails? > I'm still getting a failure in float8 on OS X after commit 73193d8:

Re: [HACKERS] Proposal: Trigonometric functions in degrees

I wrote: > So the early returns from the buildfarm aren't very good: > * tern/sungazer isn't getting exactly 0.5 from sind(30). > The tern/sungazer result implies that this: > return (sin(x * (M_PI / 180.0)) / sin(30.0 * (M_PI / 180.0))) / 2.0; > is not producing exactly 0.5, which means

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 1/23/16 12:08 PM, Tom Lane wrote: > So I pushed that, and tern/sungazer are still failing. Noah, could you > trace through that and see exactly where it's going off the rails? I'm still getting a failure in float8 on OS X after commit 73193d8: @@ -490,9 +490,9 @@ x | asind | acosd |

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 1/23/16 3:05 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 1/23/16 12:08 PM, Tom Lane wrote: >>> So I pushed that, and tern/sungazer are still failing. Noah, could you >>> trace through that and see exactly where it's going off the rails? > >> I'm still getting a

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Peter Eisentraut writes: > On 1/23/16 3:05 PM, Tom Lane wrote: >> Peter Eisentraut writes: >>> I'm still getting a failure in float8 on OS X after commit 73193d8: >> Weird, because my OS X critters are all happy. Which OS X and compiler >> version, exactly?

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Sat, Jan 23, 2016 at 05:04:56PM -0500, Tom Lane wrote: > Noah Misch writes: > > To reliably produce exact answers, this code must delay all trigonometric > > calculations to runtime. On sungazer, the float8 test happens to pass if I > > rebuild float.c with

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Noah Misch writes: > To reliably produce exact answers, this code must delay all trigonometric > calculations to runtime. On sungazer, the float8 test happens to pass if I > rebuild float.c with -fno-builtin-sin; that leaves calls like acos(0.5) and > cos(60.0 *

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Noah Misch writes: > On Sat, Jan 23, 2016 at 05:04:56PM -0500, Tom Lane wrote: >> Either I missed something or there's another issue, because tern/sungazer >> are *still* failing. This is getting annoying :-( > sungazer's "make check" passes if I change

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Dean Rasheed writes: > I tried using feclearexcept + fetestexcept as recommended by > POSIX.1-2008, and that does indeed make the above examples compliant > on my linux box. Unfortunately it introduces new errors -- asin starts > generating FE_UNDERFLOW errors for

Re: [HACKERS] Proposal: Trigonometric functions in degrees

I wrote: > Dean Rasheed writes: >> Attached are patches for this and the new functions in degrees, now >> with POSIX compatible Inf/NaN handling. > Pushed with minor, mostly cosmetic fixes. So the early returns from the buildfarm aren't very good: * tern/sungazer

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 19 January 2016 at 06:32, Michael Paquier wrote: > The first patch looks fine to me, a nitpick: > + /* Be sure to throw an error if the input is infinite --- see dcos */ > s/dcos/docs > No, I meant dcos the function there. I would normally write that as dcos()

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Jan 18, 2016 at 5:01 AM, Dean Rasheed wrote: > On 30 November 2015 at 14:11, Tom Lane wrote: >> FWIW, I think that probably the best course of action is to go ahead >> and install POSIX-compliant error checking in the existing functions >>

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 30 November 2015 at 14:11, Tom Lane wrote: > FWIW, I think that probably the best course of action is to go ahead > and install POSIX-compliant error checking in the existing functions > too. POSIX:2008 is quite clear about this: > > : An application wishing to check for

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Wed, Dec 2, 2015 at 3:30 AM, Dean Rasheed wrote: > On 1 December 2015 at 12:59, Michael Paquier > wrote: >> Dean, are you planning to continue working on this patch? If yes, are >> you fine to move it to next CF? It seems that the current

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 1 December 2015 at 12:59, Michael Paquier wrote: > Dean, are you planning to continue working on this patch? If yes, are > you fine to move it to next CF? It seems that the current consensus is > to split this effort into two patches: Yes, I still plan to work on

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Nov 30, 2015 at 11:24 PM, Michael Paquier wrote: > On Mon, Nov 30, 2015 at 11:11 PM, Tom Lane wrote: >> Michael Paquier writes: >>> On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: Instinctively, it

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Nov 30, 2015 at 10:39 PM, Michael Paquier wrote: > On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: >> Instinctively, it seems to me that we had better return Nan for the >> new asind and acosd when being out of range for OSX, Linux will >> complain

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Michael Paquier writes: > On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: >> Instinctively, it seems to me that we had better return Nan for the >> new asind and acosd when being out of range for OSX, Linux will >> complain about an out-of-range error so the

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Fri, Nov 27, 2015 at 6:33 PM, Dean Rasheed wrote: > > On 11 November 2015 at 11:45, Dean Rasheed wrote: > > Thanks for testing. I'll post an updated patch sometime soon. > > > > I finally got round to looking at this again, and here is an

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: > Instinctively, it seems to me that we had better return Nan for the > new asind and acosd when being out of range for OSX, Linux will > complain about an out-of-range error so the code is right in this > case. This is still mentioned

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Nov 30, 2015 at 11:11 PM, Tom Lane wrote: > Michael Paquier writes: >> On Mon, Nov 30, 2015 at 10:36 PM, Michael Paquier wrote: >>> Instinctively, it seems to me that we had better return Nan for the >>> new asind and acosd when being out of

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 11 November 2015 at 11:45, Dean Rasheed wrote: > Thanks for testing. I'll post an updated patch sometime soon. > I finally got round to looking at this again, and here is an updated patch. I've reverted the changes to the CHECKFLOATVAL() checks in the existing

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 11 November 2015 at 06:04, Michael Paquier wrote: >>> 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

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Tue, Nov 10, 2015 at 11:17 PM, Michael Paquier wrote: > On Sun, Nov 1, 2015 at 9:34 PM, Dean Rasheed wrote: >> On 27 October 2015 at 08:24, Dean Rasheed wrote: >>> I think it's still feasible to have sind(30) =

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Sun, Nov 1, 2015 at 9:34 PM, Dean Rasheed wrote: > On 27 October 2015 at 08:24, Dean Rasheed 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

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 27 October 2015 at 08:24, Dean Rasheed 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

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 22:51, Tom Lane wrote: > Dean Rasheed writes: >> Personally I'd rather have sind(30) be exactly 0.5, even if >> sind(29.999...) or sind(30.000...1) ended up the wrong side of it. > > TBH, sir, if you think that you are too

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Dean Rasheed writes: > On 26 October 2015 at 14:18, Tom Lane wrote: >> ... but having said that, your argument here is faulty, because 0.9 >> in itself is not exactly representable in binary. You'd be relying >> on roundoff happening in the right

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 18:58, Tom Lane wrote: > Dean Rasheed writes: >> On 26 October 2015 at 14:18, Tom Lane wrote: >>> ... but having said that, your argument here is faulty, because 0.9 >>> in itself is not exactly

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 19:45, Peter Eisentraut wrote: > On 10/24/15 5:24 AM, Dean Rasheed wrote: >> Additionally, functions that worked natively in degrees would be able >> to return exact answers in special cases like cosd(90) = 0, whereas >> cos(radians(90)) is not exactly 0

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 10/24/15 5:24 AM, Dean Rasheed wrote: > Additionally, functions that worked natively in degrees would be able > to return exact answers in special cases like cosd(90) = 0, whereas > cos(radians(90)) is not exactly 0 because pi/2 cannot be represented > exactly as a floating point number. But

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 10/26/15 1:48 PM, Simon Riggs wrote: Deviation from SI units is no laughing matter. How would we even know how to capitalise "Fortnight"? It's all fun and games until someone pokes Mars' eye out with a spacecraft. https://en.wikipedia.org/wiki/Mars_Climate_Orbiter (Ok, I guess we just

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Dean Rasheed writes: > On 26 October 2015 at 19:45, Peter Eisentraut wrote: >> But how you are going to implement that? I don't see a sind() in the C >> library. > I'm thinking something along the lines of: > 1. Reduce the range of the input (say to

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 20:19, Tom Lane wrote: > Dean Rasheed writes: >> I'm thinking something along the lines of: > >> 1. Reduce the range of the input (say to 0..90 degrees). >> 2. Handle special cases (0, 30 and 90 for sind()). >> 3. Otherwise

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Dean Rasheed writes: > Personally I'd rather have sind(30) be exactly 0.5, even if > sind(29.999...) or sind(30.000...1) ended up the wrong side of it. TBH, sir, if you think that you are too dangerous to be allowed anywhere near any numerical analysis code. Preserving

Re: [HACKERS] Proposal: Trigonometric functions in degrees

> > ​ > Stupid question - is sin(3m) a call-through to the math coprocessor?​ It probably only matters when doing a series of calculations (where the extra guard bits can matter) and not when doing a simple one-time lookup but it might be something to consider in regards to setting a precedent.

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 14:18, Tom Lane wrote: >> Having degree-based functions would make it trivial to implement >> user-defined gradian-based functions, just by multiplying or dividing >> by 0.9, and they would return exact results in the smaller number of >> cases where

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 13:58, Robert Haas wrote: > > Also -1 to furlongs, fortnights, pecks and hundredweight, amongst others. > > Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be > cool. > Deviation from SI units is no laughing matter. How would

Re: [HACKERS] Proposal: Trigonometric functions in degrees

Dean Rasheed writes: > On 25 October 2015 at 09:16, Emre Hasegeli wrote: >> I would prefer gradian over degree. > I think gradians are generally less commonly used than degrees and > radians, so I'm less inclined to include them. I agree. gradians

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 25 October 2015 at 09:16, Emre Hasegeli wrote: >> Currently PostgreSQL only has trigonometric functions that work in >> radians. I think it would be quite useful to have an equivalent set of >> functions that worked in degrees. In other environments these are >> commonly

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 26 October 2015 at 10:18, Tom Lane wrote: > Dean Rasheed writes: > > On 25 October 2015 at 09:16, Emre Hasegeli wrote: > >> I would prefer gradian over degree. > > > I think gradians are generally less commonly used than

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Mon, Oct 26, 2015 at 1:29 PM, Simon Riggs wrote: > On 26 October 2015 at 10:18, Tom Lane wrote: >> Dean Rasheed writes: >> > On 25 October 2015 at 09:16, Emre Hasegeli wrote: >> >> I would prefer gradian

Re: [HACKERS] Proposal: Trigonometric functions in degrees

> Currently PostgreSQL only has trigonometric functions that work in > radians. I think it would be quite useful to have an equivalent set of > functions that worked in degrees. In other environments these are > commonly spelled sind(), cosd(), etc. I would prefer gradian over degree. -- Sent

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Sun, Oct 25, 2015 at 6:16 PM, Emre Hasegeli wrote: >> Currently PostgreSQL only has trigonometric functions that work in >> radians. I think it would be quite useful to have an equivalent set of >> functions that worked in degrees. In other environments these are >> commonly

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On Sun, Oct 25, 2015 at 10:16:41AM +0100, Emre Hasegeli wrote: > > Currently PostgreSQL only has trigonometric functions that work in > > radians. I think it would be quite useful to have an equivalent set of > > functions that worked in degrees. In other environments these are > > commonly

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 24 October 2015 at 05:24, Dean Rasheed wrote: > Currently PostgreSQL only has trigonometric functions that work in > radians. I think it would be quite useful to have an equivalent set of > functions that worked in degrees. In other environments these are > commonly

[HACKERS] Proposal: Trigonometric functions in degrees

Currently PostgreSQL only has trigonometric functions that work in radians. I think it would be quite useful to have an equivalent set of functions that worked in degrees. In other environments these are commonly spelled sind(), cosd(), etc. Partly, this would be a matter of convenience. It's