Re: [HACKERS] [BUGS] BUG #4660: float functions return -0

2009-02-17 Thread Tom Lane
Brendan Jurd writes: > On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane 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

Re: [HACKERS] [BUGS] BUG #4660: float functions return -0

2009-02-17 Thread Brendan Jurd
On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane 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, well, there are a l

Re: [HACKERS] [BUGS] BUG #4660: float functions return -0

2009-02-17 Thread Tom Lane
Gregory Stark writes: > Tom Lane 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 >> second-guessing how it should work.

Re: [HACKERS] [BUGS] BUG #4660: float functions return -0

2009-02-17 Thread Gregory Stark
Tom Lane 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 people who know a

Re: [HACKERS] [BUGS] BUG #4660: float functions return -0

2009-02-17 Thread Bruce Momjian
Tom Lane wrote: > ITAGAKI Takahiro 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

Re: [HACKERS] [BUGS] BUG #4660: float functions return -0

2009-02-16 Thread Tom Lane
ITAGAKI Takahiro 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 have been done by Tom Lockha

Re: [HACKERS] [BUGS] BUG #4660: float functions return -0

2009-02-16 Thread ITAGAKI Takahiro
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" wrote: > Bug reference: 4660 > PostgreSQL version: 8.3.3 > Operating system: Fedora 8 > Description:float functions return -0 > Details: > Float8 ve