Re: Proposal: Trigonometric functions in degrees

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Proposal: Trigonometric functions in degrees
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Re : Re: UTF-32 support in PostgreSQL ?