You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by "Mihai Budiu (Jira)" <ji...@apache.org> on 2023/10/26 01:05:00 UTC
[jira] [Created] (CALCITE-6074) The size of REAL, DOUBLE, and FLOAT is not consistent
Mihai Budiu created CALCITE-6074:
------------------------------------
Summary: The size of REAL, DOUBLE, and FLOAT is not consistent
Key: CALCITE-6074
URL: https://issues.apache.org/jira/browse/CALCITE-6074
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.35.0
Reporter: Mihai Budiu
This stems from the review of CALCITE-6052
Which one is 8 bytes and which one is 4 bytes?
The intent seems to be that DOUBLE and FLOAT are synonyms, both using 8 bytes, (which is very weird for Java users), and REAL is 4 bytes.
But an audit of the code shows that:
In AggregateNode.maxMinClass:
{code:java}
case FLOAT:
return max ? MaxFloat.class : MinFloat.class;
case DOUBLE:
case REAL:
return max ? MaxDouble.class : MinDouble.class;
{code}
In VisitorDataContext:
{code:java}
case DOUBLE:
return Pair.of(index, rexLiteral.getValueAs(Double.class));
case REAL:
return Pair.of(index, rexLiteral.getValueAs(Float.class));
{code}
(no case for FLOAT)
In RelMdSize:
{code:java}
case FLOAT:
case REAL:
....
return 4d;
{code}
in RelDataTypeFactoryImpl:
{code:java}
case REAL:
return createSqlType(SqlTypeName.DECIMAL, 14, 7);
case FLOAT:
return createSqlType(SqlTypeName.DECIMAL, 14, 7);
case DOUBLE:
// the default max precision is 19, so this is actually DECIMAL(19, 15)
// but derived system can override the max precision/scale.
return createSqlType(SqlTypeName.DECIMAL, 30, 15);
{code}
The reference.md itself seems to be wrong:
{code}
| REAL, FLOAT | 4 byte floating point | 6 decimal digits precision.
| DOUBLE | 8 byte floating point | 15 decimal digits precision.
{code}
and there are many more I haven't even checked!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)