pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedmin() and NaN
17+ messages / 7 participants
[nested] [flat]
* min() and NaN
@ 2003-07-15 19:09 Michael S. Tibbetts <mtibbetts@head-cfa.harvard.edu>
0 siblings, 2 replies; 17+ messages in thread
From: Michael S. Tibbetts @ 2003-07-15 19:09 UTC (permalink / raw)
To: pgsql-sql
Hi,
I have a table containing a double precision column. That column
contains at least one judiciously placed NaN.
I'd expect the aggregate function min() to return the minimum, valid
numeric value. Instead, it seems to return the minimum value from the
subset of rows following the 'NaN'.
What's going here? What should I expect the aggregate function min() to
return in this case? And why?
Any help is appreciated,
Mike
testdb=> \d min_with_nan
Table "public.min_with_nan"
Column | Type | Modifiers
--------+------------------+-----------
col1 | double precision |
testdb=> select * from min_with_nan ;
col1
-------
3.141
2.718
NaN
10
(4 rows)
testdb=> select min(col1) from min_with_nan ;
min
-----
10
(1 row)
testdb=> select min(col1) from min_with_nan where col1 != 'NaN';
min
-------
2.718
(1 row)
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-20 04:40 Tom Lane <tgl@sss.pgh.pa.us>
parent: Michael S. Tibbetts <mtibbetts@head-cfa.harvard.edu>
1 sibling, 2 replies; 17+ messages in thread
From: Tom Lane @ 2003-07-20 04:40 UTC (permalink / raw)
To: Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; +Cc: pgsql-sql
"Michael S. Tibbetts" <mtibbetts@head-cfa.cfa.harvard.edu> writes:
> I'd expect the aggregate function min() to return the minimum, valid
> numeric value. Instead, it seems to return the minimum value from the
> subset of rows following the 'NaN'.
Not real surprising given than min() is implemented with float8smaller,
which does this:
result = ((arg1 > arg2) ? arg1 : arg2);
In most C implementations, any comparison involving a NaN will return
"false". So when we hit the NaN, we have arg1 = min so far, arg2 = NaN,
comparison yields false, result is NaN. On the next row, we have
arg1 = NaN, arg2 = next value, comparison yields false, result is next
value; and away it goes.
We could probably make it work the way you want with explicit tests for
NaN in float8smaller, arranged to make sure that the result is not NaN
unless both inputs are NaN. But I'm not entirely convinced that we
should make it work like that. The other float8 comparison operators
are designed to treat NaN as larger than every other float8 value (so
that it has a well-defined position when sorting), and I'm inclined to
think that float8smaller and float8larger probably should behave
likewise. (That actually is the same as what you want for MIN(), but
not for MAX() ...)
Comments anyone?
regards, tom lane
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-20 06:11 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Michael S. Tibbetts <mtibbetts@head-cfa.harvard.edu>
1 sibling, 0 replies; 17+ messages in thread
From: Stephan Szabo @ 2003-07-20 06:11 UTC (permalink / raw)
To: Michael S. Tibbetts <mtibbetts@head-cfa.harvard.edu>; +Cc: pgsql-sql
On Tue, 15 Jul 2003, Michael S. Tibbetts wrote:
> Hi,
>
> I have a table containing a double precision column. That column
> contains at least one judiciously placed NaN.
>
> I'd expect the aggregate function min() to return the minimum, valid
> numeric value. Instead, it seems to return the minimum value from the
> subset of rows following the 'NaN'.
This appears to be a bug in the min (and presumably max) aggregate
function for floats. AFAICT It should use the same logic as the < (or >)
comparison operator for the type (SQL92 6.5 GR2b iii I believe), but it's
just doing a < (or >) in C on the two arguments which isn't the same.
Changing it to follow those rules would give 2.718 for min and it looks
like NaN for max.
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-20 06:26 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 17+ messages in thread
From: Stephan Szabo @ 2003-07-20 06:26 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
On Sun, 20 Jul 2003, Tom Lane wrote:
> "Michael S. Tibbetts" <mtibbetts@head-cfa.cfa.harvard.edu> writes:
> > I'd expect the aggregate function min() to return the minimum, valid
> > numeric value. Instead, it seems to return the minimum value from the
> > subset of rows following the 'NaN'.
>
> Not real surprising given than min() is implemented with float8smaller,
> which does this:
>
> result = ((arg1 > arg2) ? arg1 : arg2);
>
> In most C implementations, any comparison involving a NaN will return
> "false". So when we hit the NaN, we have arg1 = min so far, arg2 = NaN,
> comparison yields false, result is NaN. On the next row, we have
> arg1 = NaN, arg2 = next value, comparison yields false, result is next
> value; and away it goes.
>
> We could probably make it work the way you want with explicit tests for
> NaN in float8smaller, arranged to make sure that the result is not NaN
> unless both inputs are NaN. But I'm not entirely convinced that we
> should make it work like that. The other float8 comparison operators
> are designed to treat NaN as larger than every other float8 value (so
> that it has a well-defined position when sorting), and I'm inclined to
> think that float8smaller and float8larger probably should behave
> likewise. (That actually is the same as what you want for MIN(), but
> not for MAX() ...)
The spec seems to say that min/max should work the same way as the
comparison operators by saying that it returns the maximum or minimum
value as determined by the comparison rules of the comparison predicate
section. That'd seem to be asking for the second version.
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-21 15:41 Jean-Luc Lachance <jllachan@nsd.ca>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 17+ messages in thread
From: Jean-Luc Lachance @ 2003-07-21 15:41 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
If a compare with NaN is always false, how about rewriting it as:
result = ((arg1 < arg2) ? arg2 : arg1).
Or better yet, swap arg1 and arg2 when calling float8smaller.
Use flaost8smaller( current_min, value).
JLL
Tom Lane wrote:
>
> "Michael S. Tibbetts" <mtibbetts@head-cfa.cfa.harvard.edu> writes:
> > I'd expect the aggregate function min() to return the minimum, valid
> > numeric value. Instead, it seems to return the minimum value from the
> > subset of rows following the 'NaN'.
>
> Not real surprising given than min() is implemented with float8smaller,
> which does this:
>
> result = ((arg1 > arg2) ? arg1 : arg2);
>
> In most C implementations, any comparison involving a NaN will return
> "false". So when we hit the NaN, we have arg1 = min so far, arg2 = NaN,
> comparison yields false, result is NaN. On the next row, we have
> arg1 = NaN, arg2 = next value, comparison yields false, result is next
> value; and away it goes.
>
> We could probably make it work the way you want with explicit tests for
> NaN in float8smaller, arranged to make sure that the result is not NaN
> unless both inputs are NaN. But I'm not entirely convinced that we
> should make it work like that. The other float8 comparison operators
> are designed to treat NaN as larger than every other float8 value (so
> that it has a well-defined position when sorting), and I'm inclined to
> think that float8smaller and float8larger probably should behave
> likewise. (That actually is the same as what you want for MIN(), but
> not for MAX() ...)
>
> Comments anyone?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-21 15:43 Tom Lane <tgl@sss.pgh.pa.us>
parent: Jean-Luc Lachance <jllachan@nsd.ca>
0 siblings, 1 reply; 17+ messages in thread
From: Tom Lane @ 2003-07-21 15:43 UTC (permalink / raw)
To: Jean-Luc Lachance <jllachan@nsd.ca>; +Cc: Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Jean-Luc Lachance <jllachan@nsd.ca> writes:
> If a compare with NaN is always false, how about rewriting it as:
> result = ((arg1 < arg2) ? arg2 : arg1).
That just changes the failure mode.
regards, tom lane
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-22 01:34 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 17+ messages in thread
From: Bruce Momjian @ 2003-07-22 01:34 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Is this a TODO?
---------------------------------------------------------------------------
Tom Lane wrote:
> Jean-Luc Lachance <jllachan@nsd.ca> writes:
> > If a compare with NaN is always false, how about rewriting it as:
> > result = ((arg1 < arg2) ? arg2 : arg1).
>
> That just changes the failure mode.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-22 06:09 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 2 replies; 17+ messages in thread
From: Tom Lane @ 2003-07-22 06:09 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Is this a TODO?
It'll only take ten minutes to make it a DONE, once we figure out what
the behavior ought to be. So far I think both Stephan and I argued that
MIN/MAX ought to treat NaN as larger than all ordinary values, for
consistency with the comparison operators. That was not the behavior
Michael wanted, but I don't see that we have much choice given the
wording of the SQL spec. Does anyone want to argue against that
definition?
regards, tom lane
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-22 14:03 Michael Tibbetts <tibbetts@head-cfa.harvard.edu>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 17+ messages in thread
From: Michael Tibbetts @ 2003-07-22 14:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Treating NaN's as larger(or smaller) than all ordinary values seems a fine way
to go.
It avoids the situation where you request MIN and get an ordinary value which
is greater than the minimum ordinary value in the table. If MIN(or MAX given
the ordering you're suggesting) returns NaN, the user would stand better odds
of figuring out that something about the query needs to be changed.
Returning an plausible, though possibly incorrect, ordinary value from MIN or
MAX if there are NaN's in the column can lead users to make some unfortunate
mistakes(voice of experience?).
Thanks for your help,
Mike
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Is this a TODO?
>
> It'll only take ten minutes to make it a DONE, once we figure out what
> the behavior ought to be. So far I think both Stephan and I argued that
> MIN/MAX ought to treat NaN as larger than all ordinary values, for
> consistency with the comparison operators. That was not the behavior
> Michael wanted, but I don't see that we have much choice given the
> wording of the SQL spec. Does anyone want to argue against that
> definition?
>
> regards, tom lane
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-22 16:14 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 17+ messages in thread
From: Bruce Momjian @ 2003-07-22 16:14 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Well, my 2 cents is that though we consider NULL when ordering via ORDER
BY, we ignore it in MAX because it really isn't a value, and NaN seems
to be similar to NULL.
When doing ORDER BY, we have to put the NULL value somewhere, so we put
it at the end, but with aggregates, we aren't required to put the NULL
somewhere, so we ignore it. Should that be the same for NaN? I just
don't see how we can arbitrarly say it is greater/less than other
values.
---------------------------------------------------------------------------
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Is this a TODO?
>
> It'll only take ten minutes to make it a DONE, once we figure out what
> the behavior ought to be. So far I think both Stephan and I argued that
> MIN/MAX ought to treat NaN as larger than all ordinary values, for
> consistency with the comparison operators. That was not the behavior
> Michael wanted, but I don't see that we have much choice given the
> wording of the SQL spec. Does anyone want to argue against that
> definition?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-22 18:32 Stephan Szabo <sszabo@megazone.bigpanda.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 2 replies; 17+ messages in thread
From: Stephan Szabo @ 2003-07-22 18:32 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
On Tue, 22 Jul 2003, Bruce Momjian wrote:
> Well, my 2 cents is that though we consider NULL when ordering via ORDER
> BY, we ignore it in MAX because it really isn't a value, and NaN seems
> to be similar to NULL.
>
> When doing ORDER BY, we have to put the NULL value somewhere, so we put
> it at the end, but with aggregates, we aren't required to put the NULL
> somewhere, so we ignore it. Should that be the same for NaN? I just
> don't see how we can arbitrarly say it is greater/less than other
> values.
But we already do. When doing a less than/greater than comparison, 'NaN'
is considered greater than normal values which is different from NULL
which returns unknown for both.
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-22 18:50 Jean-Luc Lachance <jllachan@nsd.ca>
parent: Stephan Szabo <sszabo@megazone.bigpanda.com>
1 sibling, 0 replies; 17+ messages in thread
From: Jean-Luc Lachance @ 2003-07-22 18:50 UTC (permalink / raw)
To: Stephan Szabo <sszabo@megazone.bigpanda.com>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; Tom Lane <tgl@sss.pgh.pa.us>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Hey! here is a (stupid maybe) idea. Why not disallow 'NaN' for a float?
JLL
Stephan Szabo wrote:
>
> On Tue, 22 Jul 2003, Bruce Momjian wrote:
>
> > Well, my 2 cents is that though we consider NULL when ordering via ORDER
> > BY, we ignore it in MAX because it really isn't a value, and NaN seems
> > to be similar to NULL.
> >
> > When doing ORDER BY, we have to put the NULL value somewhere, so we put
> > it at the end, but with aggregates, we aren't required to put the NULL
> > somewhere, so we ignore it. Should that be the same for NaN? I just
> > don't see how we can arbitrarly say it is greater/less than other
> > values.
>
> But we already do. When doing a less than/greater than comparison, 'NaN'
> is considered greater than normal values which is different from NULL
> which returns unknown for both.
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-22 18:59 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Stephan Szabo <sszabo@megazone.bigpanda.com>
1 sibling, 1 reply; 17+ messages in thread
From: Bruce Momjian @ 2003-07-22 18:59 UTC (permalink / raw)
To: Stephan Szabo <sszabo@megazone.bigpanda.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Stephan Szabo wrote:
>
> On Tue, 22 Jul 2003, Bruce Momjian wrote:
>
> > Well, my 2 cents is that though we consider NULL when ordering via ORDER
> > BY, we ignore it in MAX because it really isn't a value, and NaN seems
> > to be similar to NULL.
> >
> > When doing ORDER BY, we have to put the NULL value somewhere, so we put
> > it at the end, but with aggregates, we aren't required to put the NULL
> > somewhere, so we ignore it. Should that be the same for NaN? I just
> > don't see how we can arbitrarly say it is greater/less than other
> > values.
>
> But we already do. When doing a less than/greater than comparison, 'NaN'
> is considered greater than normal values which is different from NULL
> which returns unknown for both.
But maybe that logic is the same as ORDER BY, where we have to give it
some location in sorting order, while with aggregates we don't.
I am not strong on this, but just point it out.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-22 19:33 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 2 replies; 17+ messages in thread
From: Tom Lane @ 2003-07-22 19:33 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: Stephan Szabo <sszabo@megazone.bigpanda.com>; Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Well, my 2 cents is that though we consider NULL when ordering via ORDER
> BY, we ignore it in MAX because it really isn't a value, and NaN seems
> to be similar to NULL.
Good idea, but I don't think we can get away with it. The spec says
that MAX/MIN have to be consistent with the comparison operators (and
therefore with ORDER BY):
iii) If MAX or MIN is specified, then the result is respec-
tively the maximum or minimum value in TXA. These results
are determined using the comparison rules specified in
Subclause 8.2, "<comparison predicate>".
NULL can be special, because it acts specially in comparisons anyway.
But NaN is just a value of the datatype.
I'd be willing to go against the spec if I thought that having
ignore-NaNs behavior was sufficiently important, but I don't think it's
important enough to disregard the spec...
regards, tom lane
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-22 20:19 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 17+ messages in thread
From: Bruce Momjian @ 2003-07-22 20:19 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Stephan Szabo <sszabo@megazone.bigpanda.com>; Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Well, my 2 cents is that though we consider NULL when ordering via ORDER
> > BY, we ignore it in MAX because it really isn't a value, and NaN seems
> > to be similar to NULL.
>
> Good idea, but I don't think we can get away with it. The spec says
> that MAX/MIN have to be consistent with the comparison operators (and
> therefore with ORDER BY):
>
> iii) If MAX or MIN is specified, then the result is respec-
> tively the maximum or minimum value in TXA. These results
> are determined using the comparison rules specified in
> Subclause 8.2, "<comparison predicate>".
>
> NULL can be special, because it acts specially in comparisons anyway.
> But NaN is just a value of the datatype.
>
> I'd be willing to go against the spec if I thought that having
> ignore-NaNs behavior was sufficiently important, but I don't think it's
> important enough to disregard the spec...
Yep.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-24 18:35 Greg Stark <gsstark@mit.edu>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 17+ messages in thread
From: Greg Stark @ 2003-07-24 18:35 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; Stephan Szabo <sszabo@megazone.bigpanda.com>; Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Tom Lane <tgl@sss.pgh.pa.us> writes:
> NULL can be special, because it acts specially in comparisons anyway.
> But NaN is just a value of the datatype.
Does postgres intend to support all the different types of NaN? Does you
intend to have +Inf and -Inf and underflow detection and all the other goodies
you actually need to make it useful?
If not it seems more useful to just use the handy unknown-value thing SQL
already has and turn NaN into a NULL.
--
greg
^ permalink raw reply [nested|flat] 17+ messages in thread
* Re: min() and NaN
@ 2003-07-24 18:44 Tom Lane <tgl@sss.pgh.pa.us>
parent: Greg Stark <gsstark@mit.edu>
0 siblings, 0 replies; 17+ messages in thread
From: Tom Lane @ 2003-07-24 18:44 UTC (permalink / raw)
To: Greg Stark <gsstark@mit.edu>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; Stephan Szabo <sszabo@megazone.bigpanda.com>; Jean-Luc Lachance <jllachan@nsd.ca>; Michael S. Tibbetts <mtibbetts@head-cfa.cfa.harvard.edu>; pgsql-sql
Greg Stark <gsstark@mit.edu> writes:
> Does postgres intend to support all the different types of NaN? Does you
> intend to have +Inf and -Inf and underflow detection and all the other goodies
> you actually need to make it useful?
We have some of that; it needs work, and it's always going to be
dependent on the platform having proper IEEE support, but that's no
excuse to throw it away.
regards, tom lane
^ permalink raw reply [nested|flat] 17+ messages in thread
end of thread, other threads:[~2003-07-24 18:44 UTC | newest]
Thread overview: 17+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-07-15 19:09 min() and NaN Michael S. Tibbetts <mtibbetts@head-cfa.harvard.edu>
2003-07-20 04:40 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-07-20 06:26 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
2003-07-21 15:41 ` Jean-Luc Lachance <jllachan@nsd.ca>
2003-07-21 15:43 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-07-22 01:34 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-07-22 06:09 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-07-22 14:03 ` Michael Tibbetts <tibbetts@head-cfa.harvard.edu>
2003-07-22 16:14 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-07-22 18:32 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
2003-07-22 18:50 ` Jean-Luc Lachance <jllachan@nsd.ca>
2003-07-22 18:59 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-07-22 19:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-07-22 20:19 ` Bruce Momjian <pgman@candle.pha.pa.us>
2003-07-24 18:35 ` Greg Stark <gsstark@mit.edu>
2003-07-24 18:44 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-07-20 06:11 ` Stephan Szabo <sszabo@megazone.bigpanda.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox