Tom Lane wrote:
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
We already have some codes to avoid -0 float8um (unary minus),
but there are no protection in trunc(), ceil() and round() at least.
I looked into the CVS history to find out when the anti-minus-zero code
got put into
Tom Lane t...@sss.pgh.pa.us writes:
The CVS commit message says
Check for zero in unary minus floating point code (IEEE allows an
explicit negative zero which looks ugly in a query result!).
I'm of the opinion that minus zero was put into the IEEE floating point
standard by
Gregory Stark st...@enterprisedb.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
I'm of the opinion that minus zero was put into the IEEE floating point
standard by people who know a great deal more about the topic than
anyone on this list does, and that we do not have the expertise to be
On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The point I'm trying to make is that we should deliver IEEE-compliant
results if we are on a platform that complies with the spec. Right down
to the minus sign. If that surprises people who are unfamiliar with the
spec,
Brendan Jurd dire...@gmail.com writes:
On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The point I'm trying to make is that we should deliver IEEE-compliant
results if we are on a platform that complies with the spec. Right down
to the minus sign. If that surprises people
I reported the following bug to -bugs, and I'd like to discuss
whether we need to fix the issue or how to fix it.
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp wrote:
Bug reference: 4660
PostgreSQL version: 8.3.3
Operating system: Fedora 8
Description:float functions return
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes:
We already have some codes to avoid -0 float8um (unary minus),
but there are no protection in trunc(), ceil() and round() at least.
I looked into the CVS history to find out when the anti-minus-zero code
got put into float8um. It seems to
