Tom Lane wrote:
> 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 ...
Except win32. (let's not get into the argument about modern platforms,
please, but it certainly is one of our most popular ones)
//Magnus
