Re: Minor bug in src/port/rint.c

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Minor bug in src/port/rint.c
Date: 2008-01-20 22:00:33
Message-ID: 4793C481.80408@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> 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 ...

Except win32. (let's not get into the argument about modern platforms,
please, but it certainly is one of our most popular ones)

//Magnus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-01-20 22:05:22 Re: [HACKERS] bgwriter_lru_multiplier blurbs inconsistent
Previous Message Tom Lane 2008-01-20 21:54:54 Re: message string fixes