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

From Dean Rasheed
Subject Re: Proposal: Trigonometric functions in degrees
Date
Msg-id CAEZATCV+rkuA23ceYS_VA2UXLX7X4L-fkOOh8zhFX67r6YmhkQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Trigonometric functions in degrees  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: Trigonometric functions in degrees  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: UTF-32 support in PostgreSQL ?
Next
From: Simon Riggs
Date:
Subject: Re: Proposal: Trigonometric functions in degrees