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