On Sun, 2008-01-20 at 16:47 -0500, Tom Lane wrote:
> Your proposed fix wouldn't make it act the same as glibc, only move the
> differences around. I believe glibc's default behavior for the
> ambiguous cases is "round to nearest even number". You propose
> replacing "round towards zero", which is what our code currently does,
> with "round away from zero", which really isn't likely to match any
> platform's behavior. (The behaviors specified by IEEE are "to nearest
> even", "towards zero", "towards minus infinity", and "towards plus
> infinity", with the first being the typical default.)
>
> Considering that probably every modern platform has rint(), I doubt
> it's worth spending time on our stopgap version to try to make it
> fully IEEE-compliant ...
Hi Tom,
Right, I think I understand more about this now. My confusion stemmed
from reading the GNU documentation here:
http://www.gnu.org/software/libc/manual/html_node/Rounding-Functions.html where in rint() section it says "The default
roundingmode is to round to the nearest integer". However, Wikipedia proved to be quite a fruitful resource, and agrees
withwhat you stated which was "round to even number".
Interestingly, the article on rounding also points to this page
http://support.microsoft.com/kb/196652 which has some example code to
perform round to even number, or Banker's Rounding. The reason I was
looking into this is because PostGIS will require this for an MSVC Win32
build. I haven't yet tried the implementations given in the above page,
so I'm not sure whether they are any good or not...
The big question is, of course, how much difference does this make? Does
the current implementation exhibit different behaviour for certain date
calculations between Win32 and glibc platforms, and if so does it
matter? I guess at the end of the day, if it doesn't have any real
effect then there is no need to worry about it.
ATB,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk