SEO

Hi everyone,

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.

mca@mca-desktop:~$ ./test
rint(-1.5): -2.000000
pg_rint(-1.5): -1.000000
rint(1.5): 2.000000
pg_rint(1.5): 1.000000

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.

I'm sure that this will have practically zero effect on the code,
however it may be worth applying for correctness and consistency with
other platform implementations.


ATB,

Mark.

--
ILande - Open Source Consultancy
http://www.ilande.co.uk



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> 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.

Hasn't it got something equivalent? This is IEEE-required behavior
I think.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> 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.
>
> Hasn't it got something equivalent? This is IEEE-required behavior
> I think.

Quite possibly - I haven't looked for it. I just added port/rint.c when
it was missing that one.

Something for the list of things to investigate, I guess...

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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/man...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

Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:
> The big question is, of course, how much difference does this make?

Probably not a lot. If we can find an IEEE-compliant rounding function
on Windows, I'd be happy to see rint() fixed to call it; beyond that
I think it's not worth troubling with.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Added to TODO:

o Fix port/rint.c to be spec-compliant

http://archives.postgresql.org/pgsql...1/msg00808.php


---------------------------------------------------------------------------

Mark Cave-Ayland wrote:
> Hi everyone,
>
> 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.
>
> mca@mca-desktop:~$ ./test
> rint(-1.5): -2.000000
> pg_rint(-1.5): -1.000000
> rint(1.5): 2.000000
> pg_rint(1.5): 1.000000
>
> 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.
>
> I'm sure that this will have practically zero effect on the code,
> however it may be worth applying for correctness and consistency with
> other platform implementations.
>
>
> ATB,
>
> Mark.
>
> --
> ILande - Open Source Consultancy
> http://www.ilande.co.uk
>

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Bruce Momjian <bruce@momjian.us> writes:
> Added to TODO:
> o Fix port/rint.c to be spec-compliant

Actually, the TODO I had in mind was entirely not that. Getting exact
spec compliance in a completely platform-independent fashion is probably
impossible, and is certainly not worth the trouble in view of the fact
that every SUS-compliant platform provides a working rint() already.
The proper wording of this item is

* Find a correct rint() substitute on Windows

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane wrote:

> The proper wording of this item is
>
> * Find a correct rint() substitute on Windows

Fixed.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers