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.) 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