Re: Proposal: Trigonometric functions in degrees

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: Proposal: Trigonometric functions in degrees
Дата
Msg-id CAEZATCV+rkuA23ceYS_VA2UXLX7X4L-fkOOh8zhFX67r6YmhkQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: Trigonometric functions in degrees  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proposal: Trigonometric functions in degrees  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: UTF-32 support in PostgreSQL ?
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Proposal: Trigonometric functions in degrees