Re: Minor bug in src/port/rint.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Minor bug in src/port/rint.c
Date
Msg-id 13697.1200865674@sss.pgh.pa.us
Whole thread Raw
In response to Minor bug in src/port/rint.c  (Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>)
Responses Re: Minor bug in src/port/rint.c  (Magnus Hagander <magnus@hagander.net>)
Re: Minor bug in src/port/rint.c  (Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>)
List pgsql-hackers
Mark Cave-Ayland <mark.cave-ayland@ilande.co.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


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: message string fixes
Next
From: Tom Lane
Date:
Subject: Re: message string fixes