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

On Wed, Aug 16, 2000 at 11:16:24AM +1000, Tim Allen wrote:
> 
> Thanks for pursuing this, Ross. I shall look forward to not having to use
> a workaround in future versions.

See, Tim knows how to get work out of Open Source programmers. Flattery, not
flames ;-)

> 
> Actually, we also have a use for NaN. The main thing we're using this for
<snip>
> read them from the database. So, for what it's worth, here's one vote for
> keeping NaN's. As for sorting, we don't really care how they sort. Any
> consistent behaviour will do for us.
> 

Right. Currently, NaN's break sorting of everything else in the column. 
Not good. But Thomas mentioned a possible clever work around. I've got to
dig into the code a bit more to see if it'll work.

> Yes, there is a difference between an NaN and a NULL, but that difference
> is not important in our application. We never do any serious arithmetic on
> our float8 values, we just store them in the database and allow users to
> view and edit the values.
> 
> >So, anyone have any ideas what NaN would be useful for? Especially given
> >we have NULL available, which most (non DB) numeric applications don't.
> 
> It's this last point that makes NaN's useful; most non DB numeric
> applications don't have a NULL, and NaN can make an adequate substitute.
> One thing we could do, I suppose, is add code to our db interface layer to
> translate NaN's to NULL's and vice versa. But if we don't have to, we'd be
> happier :-).

Well, this is open source: all we need is one customer, if the idea
is sound. (Usually, that's the coder themselves, but not always. And
conversely, if it's a lousy idea, it doesn't matter howmany people
want it!) I had forgotten that the DB often interacts with non-DB
code. (What, you mean psql and hand typed queries isn't good enough for
your clients?) 'Course, I'm the type that's been known to code figures
directly in Postscript because the drawing package wouldn't do what I
wanted to.

I'll definitely look into this some more. If we can solve the sort
problem without to big a kludge, I think we might be able to let people
do serious math in the backend, let the non-finites fly!

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