Dean Rasheed <dean.a.rash...@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
