Todd Lipcon has posted comments on this change.

Change subject: KUDU-1386 NaN float and double values are not handled correctly
......................................................................


Patch Set 1:

(1 comment)

http://gerrit.cloudera.org:8080/#/c/3142/1/src/kudu/common/types.h
File src/kudu/common/types.h:

Line 53:   NONCOMPARABLE = 12
> I agree more with Dan, though I think the Todd/Postgres position is reasona
> I'm not following, why would you want NaNs to show up in a per-block min/max 
> statistic?

Imagine a column for a time series value which is a float with lots of NaNs. 
The user wants to 'select * where !isNan(val)'. In that case, with min/max 
statistics, you can just convert this to '< NaN', and quickly use the min/max 
to determine whether a given block has any NaNs.

The whole concept of min/max gets a bit messed up if there is no total order.

In terms of compatibility, Oracle also does like Postgres:

"Comparison operators conform, except for comparisons with NaN. Oracle orders 
NaN greatest with respect to all other values, and evaluates NaN equal to NaN. 
See "Floating-Point Conditions"." 
(http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements001.htm)

Best I can tell, MySQL doesn't support NaN at all.

SQL Server before 2000 would apparently corrupt the database if you inserted 
NaN 
(https://www.simple-talk.com/blogs/2010/04/13/from-nan-to-infinity-and-beyond/).
 According to that article, SQL Server 2008 just disallowed them.

SQLite seems to coerce NaN to NULL and prevents insertion into a NOT NULL 
column (which is also a reasonable position IMO).

DB2 apparently lives in another universe (the IBM one) where there is both a 
positive and negative NaN as well as two variants, "signalling" and "quiet" 
(what???). But they do assign a total order:
  The ordering among the different special values is as follows: -NAN < -SNAN < 
-INFINITY < 0 < INFINITY < SNAN <NAN
(https://www.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.sqlref/src/tpc/db2z_numericcomparisions.dita)


So, I think despite there being an IEEE standard around float comparison, I 
can't seem to find any database engines which behave that way.


-- 
To view, visit http://gerrit.cloudera.org:8080/3142
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I194dcddeb8eabcc67699661b9cc9362a99f2f4ae
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Will Berkeley <wdberke...@gmail.com>
Gerrit-Reviewer: Dan Burkert <d...@cloudera.com>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>
Gerrit-Reviewer: Will Berkeley <wdberke...@gmail.com>
Gerrit-HasComments: Yes

Reply via email to