Re: Float/Double cast to int

From: Feng Tian <ftian(at)vitessedata(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Float/Double cast to int
Date: 2015-05-21 19:33:19
Message-ID: CAFWGqntnhR+0JPAh=ffayywp_nsmvuDEAygVKpKts3DVHdzYMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ah, thanks! I did not realize numeric comes into play. But, this is even
more interesting -- I would expect numeric is more consistent than
float/double when dealing with stuff like rounding.

I missed the not too long ago discussion, :-) Regardless of the
mechanisms underneath, it would be quite hard to explain this behavior to
customer. Maybe it is time to be brave, and be compatible with reality
instead of backward?

Best,
Feng

On Thu, May 21, 2015 at 12:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Feng Tian <ftian(at)vitessedata(dot)com> writes:
> > Here is a query, server was built witch GCC on Linux, AMD64.
>
> > ftian=# select 1.5::int, 1.5::double precision::int, 314.5::int,
> > 314.5::double precision::int;
> > int4 | int4 | int4 | int4
> > ------+------+------+------
> > 2 | 2 | 315 | 314
> > (1 row)
>
> > I believe this is because rint is broken -- can some expert on IEEE754
> > please help confirm that this is a bug?
>
> rint() is doing what the IEEE spec says, ie round to nearest even.
> Your third expression is doing numeric-to-int, and that code doesn't
> obey the IEEE spec. We've had discussions (not too long ago) about
> making these behaviors more consistent, but people seem to be too
> afraid of backwards-compatibility problems if we change it.
>
> regards, tom lane
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-05-21 19:34:00 Re: Fix misaligned access of ItemPointerData on ARM
Previous Message Piotr Stefaniak 2015-05-21 19:24:21 Fix misaligned access of ItemPointerData on ARM