Re: Re: [GENERAL] +/- Inf for float8's

From: "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-hackers(at)hub(dot)org
Subject: Re: Re: [GENERAL] +/- Inf for float8's
Date: 2000-08-21 21:34:50
Message-ID: v04210176b5c73dae36fa@[137.78.84.130]
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 1:25 AM -0400 8/21/00, Tom Lane wrote:
>"Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> > ! if (isnan(a))
> > ! PG_RETURN_INT32(1);
>
>Do not like this at all --- doesn't it make the result of btint4cmp(NaN,
>NaN) dependent on which argument chances to be first? Seems to me that
>you must consider two NaNs to be equal, unless you want to subdivide
>the category of NaNs.

I'm pretty sure IEEE 754 says that NaN does not compare equal to
anything, including themselves. I also believe that Infinity isn't
equal to itself either, it's just bigger than anything else except
NaN (which isn't littler either).

Without having seen the start of this thread I think the biggest
problem is that some of the results of compares depend on the mode
that the FP hardware is put in. IEEE specifies some modes, but not
how you set the mode you want on the system you are actually running
on. For example I think comparing zero and -Infinity may return
three possible results: 0 > -Infinity, 0 < -Infinity (because it was
told to ignore the sign of Infinity), or an illegal value exception.
Likewise signalling/non-signalling NaN's act different depending on
mode settings.

We need to first figure out what floating point behavior we want to
support. Then we figure what mode settings provide that behavior
with a minimum of overhead. Then we need to figure out how to set
those modes on all the platforms we support. We will probably
discover that not all required modes actually exist on all hardware
platforms. I know that 68000 and SPARC are pretty good, but PowerPC
punted some stuff to exception handlers which may not be correct on
all OS's. I've heard that Java has some portability issues because
Intel fudged some stuff in the newer hardware.

Does anyone feel like tracing down how to set the modes for all the
different systems that we try to run on? If there is interest then I
might poke at a couple/three NetBSD ports and Solaris/SPARC. But
only if there is interest.

Sun has put some code out under GPL which will let you test for these
special values and handle them, but that seems like a big hit for
what should be a simple compare. I assume that we can't put GPL code
into the main sources any more than the *BSD's do. Perhaps we could
get away with it if it is only included if configure can't figure out
how to set the modes properly?

Signature held pending an ISO 9000 compliant
signature design and approval process.
h(dot)b(dot)hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross J. Reedstrom 2000-08-21 22:30:21 Re: Re: [GENERAL] +/- Inf for float8's
Previous Message Ned Lilly 2000-08-21 21:24:49 Re: Bug tracking