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 rounding mode is to round to the nearest integer". However, Wikipedia proved to be quite a fruitful resource, and agrees with what 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
