Proposal: Trigonometric functions in degrees

On 24 October 2015 at 05:24, Dean Rasheed <dean.a.rasheed@gmail.com> 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 spelled sind(), cosd(), etc.

Partly, this would be a matter of convenience. It's quite common to
have a problem domain where angles are specified in degrees, and it's
somewhat cumbersome having to type things like sin(radians(x)) and
degrees(asin(x)).

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.

That is important.

Possibly the earthdistance module would benefit from these functions too.

Thoughts?

+1, yes, please.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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 via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Oct 25, 2015 at 6:16 PM, Emre Hasegeli <emre@hasegeli.com> 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 spelled sind(), cosd(), etc.

I would prefer gradian over degree.

This may be a matter of personal taste, but I am personally used to
degrees since primary school. By the way, +1 for the proposal.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 spelled sind(), cosd(), etc.

I would prefer gradian over degree.

We can have both, but degree is a good bit better known, which means
more users will care about it.

People have gone a long way toward dealing with problems like the
known correspondence (90° = π/2, etc.) and periodicity (f(x) =
f(x+360*n) for integer n, f in (sin, cos, tan, cot, sec, csc), for
example).

I haven't yet found same in a PostgreSQL-compatible library, though.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 25 October 2015 at 09:16, Emre Hasegeli <emre@hasegeli.com> 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 spelled sind(), cosd(), etc.

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.

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 gradian results are exactly representable.

Regards,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Dean Rasheed <dean.a.rasheed@gmail.com> writes:

On 25 October 2015 at 09:16, Emre Hasegeli <emre@hasegeli.com> 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 are not often used at all, AFAICT.

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 gradian results are exactly representable.

... 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 direction to get exact answers
from such calculations, for just the same reasons that sind() can't be
just "sin(x * scalefactor)" if you want exact-where-possible results.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 26 October 2015 at 10:18, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dean Rasheed <dean.a.rasheed@gmail.com> writes:

On 25 October 2015 at 09:16, Emre Hasegeli <emre@hasegeli.com> 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 are not often used at all, AFAICT.

I've never seen anyone use a gradian, even though my calculator had them
when I was 16.

I even misread the request, thinking he meant "radians". Definitely -1 to
gradians in PostgreSQL.

Also -1 to furlongs, fortnights, pecks and hundredweight, amongst others.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Mon, Oct 26, 2015 at 1:29 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

On 26 October 2015 at 10:18, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dean Rasheed <dean.a.rasheed@gmail.com> writes:

On 25 October 2015 at 09:16, Emre Hasegeli <emre@hasegeli.com> 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 are not often used at all, AFAICT.

I've never seen anyone use a gradian, even though my calculator had them
when I was 16.

I even misread the request, thinking he meant "radians". Definitely -1 to
gradians in PostgreSQL.

Also -1 to furlongs, fortnights, pecks and hundredweight, amongst others.

Aw, you're no fun. select '1 fortnight'::interval => '14 days' would be cool.

https://en.wikipedia.org/wiki/FFF_system

I don't think we should be dismissive of gradians, because I'm sure
Emre's request was serious and in good faith, but I don't feel a
crying need for them either.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 26 October 2015 at 14:18, Tom Lane <tgl@sss.pgh.pa.us> 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 gradian results are exactly representable.

... 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 direction to get exact answers
from such calculations, for just the same reasons that sind() can't be
just "sin(x * scalefactor)" if you want exact-where-possible results.

It would be relying on the things like the following being exactly true:

45 / 0.9 = 50
50 * 0.9 = 45
90 / 0.9 = 100
100 * 0.9 = 90

which they are on my machine. I thought that this was guaranteed in
IEEE floating point arithmetic, since one of the inputs and the result
are exactly representable, and the result is guaranteed to be within
0.5ulp. I'm curious now though. Are there any platforms on which the
above aren't exactly true?

Regards,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 26 October 2015 at 13:58, Robert Haas <robertmhaas@gmail.com> 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 we even know how
to capitalise "Fortnight"?

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Dean Rasheed <dean.a.rasheed@gmail.com> writes:

On 26 October 2015 at 14:18, Tom Lane <tgl@sss.pgh.pa.us> 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 direction to get exact answers
from such calculations, for just the same reasons that sind() can't be
just "sin(x * scalefactor)" if you want exact-where-possible results.

It would be relying on the things like the following being exactly true:

45 / 0.9 = 50
50 * 0.9 = 45
90 / 0.9 = 100
100 * 0.9 = 90

which they are on my machine. I thought that this was guaranteed in
IEEE floating point arithmetic, since one of the inputs and the result
are exactly representable, and the result is guaranteed to be within
0.5ulp. I'm curious now though. Are there any platforms on which the
above aren't exactly true?

Possibly, but the bigger picture is you're ignoring other cases, such as

regression=# select 30 / 0.9;
?column?
---------------------
33.3333333333333333
(1 row)

which is problematic since sin(30 degrees) = 0.5 is one of the cases
one would like to be exact. (Actually I guess this example shows that
implementing sind in terms of sing would be imprecise, but I'm sure
the reverse holds for some other special angles.)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 26 October 2015 at 18:58, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dean Rasheed <dean.a.rasheed@gmail.com> writes:

On 26 October 2015 at 14:18, Tom Lane <tgl@sss.pgh.pa.us> 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 direction to get exact answers
from such calculations, for just the same reasons that sind() can't be
just "sin(x * scalefactor)" if you want exact-where-possible results.

It would be relying on the things like the following being exactly true:

45 / 0.9 = 50
50 * 0.9 = 45
90 / 0.9 = 100
100 * 0.9 = 90

which they are on my machine. I thought that this was guaranteed in
IEEE floating point arithmetic, since one of the inputs and the result
are exactly representable, and the result is guaranteed to be within
0.5ulp. I'm curious now though. Are there any platforms on which the
above aren't exactly true?

Possibly, but the bigger picture is you're ignoring other cases, such as

regression=# select 30 / 0.9;
?column?
---------------------
33.3333333333333333
(1 row)

which is problematic since sin(30 degrees) = 0.5 is one of the cases
one would like to be exact. (Actually I guess this example shows that
implementing sind in terms of sing would be imprecise, but I'm sure
the reverse holds for some other special angles.)

No, actually sing() and the other gradian-based trig functions have
fewer exact special cases than their degree-based equivalents. That's
one of the criticisms of gradians. For example an equilateral triangle
has internal angles of 66.666... gradians. The only exact results for
sing() and cosg() are at multiples of 100 gradians.

Regards,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 how you are going to implement that? I don't see a sind() in the C
library.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 26 October 2015 at 19:45, Peter Eisentraut <peter_e@gmx.net> 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 because pi/2 cannot be represented
exactly as a floating point number.

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 0..90 degrees).
2. Handle special cases (0, 30 and 90 for sind()).
3. Otherwise convert to radians for the general case.

Regards,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Dean Rasheed <dean.a.rasheed@gmail.com> writes:

On 26 October 2015 at 19:45, Peter Eisentraut <peter_e@gmx.net> 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 0..90 degrees).
2. Handle special cases (0, 30 and 90 for sind()).
3. Otherwise convert to radians for the general case.

I'd be okay with #1 and #3, but #2 is just a crock; it would risk creating
problems that did not exist before, such as non-monotonicity of the
function result (over ranges where that does not hold).

I looked into my dusty old copy of Cody & Waite's "Software Manual for the
Elementary Functions", which is what I used as a reference the last time
I had to do code like this (which admittedly was quite a long time ago;
the state of the art might've advanced). C&W say that the key accuracy
limit for sin and cos is reduction of the argument modulo pi (or whichever
multiple of pi you choose to work with). Now that problem just goes away
for degrees, of course, so it might be that reduction mod 360 and then
conversion to radians would be Good Enough(TM).

If it's not good enough, a possible idea is reduction mod 45 degrees or
even mod 30 degrees and then using trig identities to reconstruct the
correct output.

Anyway, I think the core idea of trying to build a reasonably thin wrapper
around sin(3m) and friends is probably an appropriate amount of effort,
depending on how many cases you are hoping to make exact. I doubt it's
worth coding sind() from scratch.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 26 October 2015 at 20:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dean Rasheed <dean.a.rasheed@gmail.com> 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 convert to radians for the general case.

I'd be okay with #1 and #3, but #2 is just a crock; it would risk creating
problems that did not exist before, such as non-monotonicity of the
function result (over ranges where that does not hold).

Well special-casing 0 and 90 are certainly no problem, and do not risk
introducing non-monotonicity. sin() changes sign at 0 and for very
small x, sin(x) ~= x, so special-casing sin(0) = 0, doesn't affect the
monotonic nature of the function in that vicinity. Near 90, sin(x) is
not monotonic, but rather that is a maxima, and the slope is 0, so
small perturbations in x do not affect the result and you have to move
quite far away from 90 for the result to become different from 1, so
special-casing sind(90) = 1 does not affect the continuity of the
function.

Special-casing sind(30) = 0.5 could be more problematic, but a quick
test on my machine shows that it does remain monotonic. As I
understand it, most modern processors apply argument reduction to the
range 0..pi/4, using cos(pi/2-x)=sin(x) to extend this to the range
0..pi/2 and hence all inputs. So passing in an input close to pi/6 (30
degrees) will not undergo any further argument reduction and the
result would be expected to be very accurate. Of course, we could just
omit this special case, and accept whatever approximation to 0.5 the
underlying function returned. It's a question of which is worse in
practice -- a small chance that sind(29.999...) or sind(30.000...1)
might be the wrong side of 0.5, making the function non-monotonic, or
having sind(30) not be exactly 0.5.

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.
Floating point arithmetic is inherently imprecise, so tiny errors are
to be expected. But the well-known exact cases ought to work exactly.
BTW, these are the *only* values for which sind() returns exact
answers (see Niven's Theorum -
http://mathworld.wolfram.com/NivensTheorem.html) and they also happen
to be exactly representable using floats, so it seems a shame not to
return the exact values whenever possible.

I looked into my dusty old copy of Cody & Waite's "Software Manual for the
Elementary Functions", which is what I used as a reference the last time
I had to do code like this (which admittedly was quite a long time ago;
the state of the art might've advanced). C&W say that the key accuracy
limit for sin and cos is reduction of the argument modulo pi (or whichever
multiple of pi you choose to work with). Now that problem just goes away
for degrees, of course, so it might be that reduction mod 360 and then
conversion to radians would be Good Enough(TM).

No that would lead to sind(180) being non-zero.

If it's not good enough, a possible idea is reduction mod 45 degrees or
even mod 30 degrees and then using trig identities to reconstruct the
correct output.

Reduction mod 45 would be fairly trivial, and would result in things
like sind(10) being exactly equal to cosd(80), even though neither
answer would be exactly correct. I'm not sure that by itself is worth
the extra effort, but it would probably improve the chances of cosd()
staying monotonic near 60, if we special-cased cosd(60) = 0.5
(although it does anyway on my machine).

Regards,
Dean

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

​

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.

Bear

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 sprayed the planet with debris instead of poking an
eye out...)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Dean Rasheed <dean.a.rasheed@gmail.com> 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 mathematical properties like
monotonicity is *far* more important than whether sin(30 degrees) comes
out exact or not. You can do proofs about the behavior of algorithms
using these functions if you can ensure monotonicity; but exactness of
values is always going to depend on subtle details of the floating point
format.

I think using a range reduction to some fractional part of the circle is a
reasonable way of trying to deal with these concerns, but I really really
do not want to see it special-casing point values in a way that doesn't
guarantee monotonicity.

It may be that guaranteeing the sin(30) case is just not very feasible,
and we should content ourselves with getting the 0/90/180/270/360 cases
exactly, which we could do with a mod 90 initial reduction. Doing mod 30
or mod 45 would require sewing together pieces of the curve that might not
meet exactly, if we were unlucky. (I've not tried it though.)

What have you got in mind for tan() and the rest?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers