I wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> Attached are patches for this and the new functions in degrees, now >> with POSIX compatible Inf/NaN handling.
> Pushed with minor, mostly cosmetic fixes. So the early returns from the buildfarm aren't very good: * tern/sungazer isn't getting exactly 0.5 from sind(30). * narwhal isn't getting exactly 1 from tand(45) or cotd(45). It also is producing "0" not "-0" from tand(180) and cotd(270). * gaur likewise is getting "0" not "-0" from tand(180) and cotd(270). The tern/sungazer result implies that this: return (sin(x * (M_PI / 180.0)) / sin(30.0 * (M_PI / 180.0))) / 2.0; is not producing exactly 0.5, which means that the two sin() calls aren't producing identical results, which I suspect is best explained by the theory that the compiler is rearranging 30.0 * (M_PI / 180.0) into (30.0 * M_PI) / 180.0, and getting a slightly different number that way. I think we could fix that by replacing (M_PI / 180.0) by a hard-wired constant (computed to say 20 digits or so). I'd be inclined to do that throughout the file for consistency; however, in principle such a change might affect existing results from the radians() and degrees() functions. The tand(45) problem doesn't seem especially surprising, because we're really not making any effort to ensure that that result is exact. A brute-force way to fix it would be to divide (sind_q1(arg1) / cosd_q1(arg1)) by (sind_q1(45.0) / cosd_q1(45.0)) but that seems rather expensive, and possibly subject to the compiler deciding to reorder the arithmetic operations. I wonder if there's a smarter way. As for the minus-zero issues, I doubt that (a) there is a basis for claiming that minus-zero is more correct than plain zero, or (b) the user community for this feature really wants minus-zero results anyhow. I propose getting rid of minus-zero outputs from tand and cotd by dint of code like if (result == 0.0) result = 0.0; Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers