I’m not sure whether we should do this. I can see the benefits of making Calcite’s SQL FLOAT type behave more like Java's double type. (Not java float; java float is 32 bit floating point, whereas SQL FLOAT is 64 bit floating point.) But I don’t recall whether the SQL standard deals with NaN, and I am cautious about departing from the standard.
> Calcite uses BigDecimal for handling DOUBLE, FLOAT values Not strictly true. It uses BigDecimal for all numeric literals. But that’s just while we’re preparing the query. At run time we translate to something more efficient. What we translate to depends on which engine you are using. Julian > On Nov 23, 2017, at 4:53 AM, Volodymyr Tkach <[email protected]> wrote: > > Currently we are working in Drill to allow support for Nan an Inf > <https://issues.apache.org/jira/browse/DRILL-5919> values . > When using such values with functions we see the NumberFormatException > exception. > Query example: *select sin(cast('NaN' as float)) from (values(1)) * > > It turns out that Calcite uses BigDecimal for handling DOUBLE, FLOAT > values. > Is it acceptable for Calcite to support nan, infinity values handling? For > example, adding new types NON_NUMERIC_DOUBLE, NON_NUMERIC_FLOAT?
