From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Minor bug in src/port/rint.c |
Date: | 2008-01-20 21:47:54 |
Message-ID: | 13697.1200865674@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk> writes:
> I believe that there is a small bug in src/port/rint.c when the input
> parameter has a fractional part of 0.5 which is demonstrated by the
> attached program. It appears that the PG version of rint() rounds in the
> wrong direction with respect to glibc.
> The fix is, of course, to add an equals into the if() comparisons on
> lines 21 and 26, so that when the fractional part is 0.5, it rounds in
> the opposite direction instead.
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 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-20 21:54:54 | Re: message string fixes |
Previous Message | Tom Lane | 2008-01-20 21:34:44 | Re: setof record "out" syntax and returning records |