From: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-22 19:34:31 |
Message-ID: | 20000822143431.A27521@rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 22, 2000 at 08:22:21PM +0200, Peter Eisentraut wrote:
>
> Hmm, I'm getting the feeling that perhaps at this point we should
> explicitly *not* support NaN at all. After all, the underlying reason for
> offering them is to provide IEEE 754 compliant floating point arithmetic,
> but if we start making compromises such as NaN == NaN or NaN > +Infinity
> then we might as well not do it. In these cases I opine that if you can't
> do something correctly then you should perhaps be honest and don't do
> it. After all, users that want a "not-a-number" can use NULL in most
> cases, and hard-core floating point users are going to fail miserably
> with the FE/BE protocol anyway.
>
Pretty much were I have come to on this, as well. The point is to get
the existing NaN to not break indicies or sorting. The simplest way is
to disable it.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Ross J. Reedstrom | 2000-08-22 20:16:01 | Re: when does CREATE VIEW not create a view? |
Previous Message | Mark Hollomon | 2000-08-22 19:10:19 | Re: when does CREATE VIEW not create a view? |