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

On Tue, Aug 15, 2000 at 03:27:55AM +0000, Thomas Lockhart wrote:
>
> Not all computers fully support IEEE754, though many new ones do.

True - the question becomes: how new is new? Are we supporting ones
that aren't? If so, that's fine. If not, it's a lot easier to fix. ;-)

> > And, there's no test case in the regression tests for inserting NaN or
> > Infinity. (Shame on Thomas ;-)
>
> Ah, I'm just trying to leave some rewarding work for other folks ;)

And we appreciate the crumbs. Actually, it _was_ good practice grovelling
out versions from CVS and matching log messages.

>
> istm that the existing protection (or something like it) is required for
> some platforms, while other platforms may be able to handle NaN and
> +/-Inf just fine. Seems like a job for autoconf to determine the FP
> capabilities of a system, unless Posix defines some way to tell. Of
> course, even then we'd need an autoconf test to deal with non-Posix
> platforms.

Yeah, need to get Peter Eisentraut involved, perhaps. Should actually be
pretty simple: the #define is already there: UNSAFE_FLOATS. Define that,
and the CheckFloat[48]Val functions just return true.

>
> How about setting up a separate test (say, ieee754.sql) so that
> non-compliant platforms can still pass the original FP test suite. Then
> other platforms can be added in as they are tested.

Hmm, I wish we had clue what other systems might be non-compliant, and how.
The question becomes one of if it's _possible_ to support NaN, +/-Inf on
some platforms. Then, we end up with a difference in functionality.

>
> > Is there an intrinsic problem with allowing values outside the range
> > FLOAT8_MAX <= x =>FLOAT8_MIN ? 'ORDER BY' seems to still work, with
> > 'Infinity' and '-Infinity' sorting properly. Having a 'NaN' in there
> > breaks sorting however. That's a current, live bug. Could be fixed
> > by treating 'NaN' as a different flavor of NULL. Probably a fairly deep
> > change, however. Hmm, NULL in a float8 sorts to the end, regardless of
> > ASC or DESC, is that right?
>
> NULL and NaN are not quite the same thing imho. If we are allowing NaN
> in columns, then it is *known* to be NaN.

For the purposes of ordering, however, they are very similar. Neither one
can be placed corectly with respect to the other values: NULL, because
we don't know were it really is, NaN because we know it's not even on
this axis. I'm suggesting the we fix sorting on floats to treat NaN as
NULL, and sort it to the end. As it stands, sorting is broken, since it
returns the NaN rows wherever they happen to be. This causes them to
act as barriers, partitioning the returned set into seperately sorted
sub sequences.

>
> > Anyway, here's the patch for just float.c , if anyone wants to look
> > at it. As I said, it passes the existing float8 regression tests, but
> > raises a lot of interesting questions.
>
> Are you interested in pursuing this further? It seems like we might be
> able to move in the direction you suggest on *some* platforms, but we
> will need to scrub the math functions to be able to handle these edge
> cases.

Sure. I'm no great floating point wiz, but I'm sure Tom and Don will
jump on anything I get wrong. Duping the float tests and feeding them
NaN/+/-Inf as a seperate test set is probably a good idea.

The existing patch moves the call to CheckFloat8Val() inside float8in
so it is only called if strtod() consumes all it's input, and does not
set errno. Seems safe to me: if strtod() doesn't consume it's input,
we check to make sure it's not NaN/+/-Inf (gah, need a shorthand word
for those three values), else elog(). If it does, but sets errno,
we catch that. Then, in belt-and-suspenders style, we call
CheckFloat8Val(). For that check to fail, strtod() would have to consume
its entire input, return +/-HUGE_VAL, and _not_ set errno to ERANGE.

BTW, this also brings up something that got discussed before the last
release, but never implemented. The original problem from Tim Allen had
to do with using a work around for not having +/- Inf: storing the values
-1.79769313486232e+308 and 1.79769313486232e+308. He was having trouble,
since a pg_dump/restore cycle broke, do to rounding the values to out
of range for floats. This wasn't caught by the current regression tests,
but would have been caught by the suggested dump/restore/dump/compare
dumps cycle someone suggested for exercizing the *out and *in functions.

Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm(at)rice(dot)edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005