On 26 October 2015 at 18:58, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> On 26 October 2015 at 14:18, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> ... 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? > > Possibly, but the bigger picture is you're ignoring other cases, such as > > regression=# select 30 / 0.9; > ?column? > --------------------- > 33.3333333333333333 > (1 row) > > which is problematic since sin(30 degrees) = 0.5 is one of the cases > one would like to be exact. (Actually I guess this example shows that > implementing sind in terms of sing would be imprecise, but I'm sure > the reverse holds for some other special angles.) >
No, actually sing() and the other gradian-based trig functions have fewer exact special cases than their degree-based equivalents. That's one of the criticisms of gradians. For example an equilateral triangle has internal angles of 66.666... gradians. The only exact results for sing() and cosg() are at multiples of 100 gradians. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
