From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Emre Hasegeli <emre(at)hasegeli(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: Trigonometric functions in degrees |
Date: | 2015-10-26 18:47:31 |
Message-ID: | CAEZATCV+rkuA23ceYS_VA2UXLX7X4L-fkOOh8zhFX67r6YmhkQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26 October 2015 at 14:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2015-10-26 18:48:26 | Re: Proposal: Trigonometric functions in degrees |
Previous Message | Tom Lane | 2015-10-26 18:11:56 | Re: [HACKERS] UTF-32 support in PostgreSQL ? |