[ https://issues.apache.org/jira/browse/CALCITE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112139#comment-16112139 ]
sunjincheng edited comment on CALCITE-1908 at 8/3/17 4:17 AM: -------------------------------------------------------------- Hi, [~julianhyde] Thanks for tell me more detail. I think we can not consider decimal at the first. For the example above, we can look {{11.6}} as `DOUBLE`(if user defined in table), {{2}} as {{INTGRE}}, then we can implicitly convert {{2}} as {{DOUBLE}}. i.e., we can consider the following implicitly conversions: * tinyint --> smallint-> int --> bigint --> float --> double - string Is this implicitly conversion logic make sense for you? *Note:* * Of course if we look {{11.6}} as a {{DOUBLE}} we get result{{1.5999999999999996}}. But I think we can resolve the accuracy problems between 1.6 and 1.5999 after CALCITE-1468 fixed.* Thanks, Jincheng was (Author: sunjincheng121): Hi, [~julianhyde] Thanks for tell me more detail. I think we can not consider decimal at the first. For the example above, we can look {{11.6}} as `DOUBLE`(if user defined in table), {{2}} as {{INTGRE}}, then we can implicitly convert {{2}} as {{DOUBLE}}. i.e., we can consider the following implicitly conversions: * tinyint --> smallint-> int --> bigint --> float --> double - string Is this implicitly conversion logic make sense for you? *Note: * *of course if we look {{11.6}} as a {{DOUBLE}} we get result{{1.5999999999999996}}. But I think we can resolve the accuracy problems between 1.6 and 1.5999 after CALCITE-1468 fixed.* Thanks, Jincheng > Mod function got exception in MOD(34.5,3), MOD(19,6.7) situation. > ----------------------------------------------------------------- > > Key: CALCITE-1908 > URL: https://issues.apache.org/jira/browse/CALCITE-1908 > Project: Calcite > Issue Type: Bug > Reporter: sunjincheng > > Calcite MOD definition: > // Return type is same as divisor (2nd operand) > // SQL2003 Part2 Section 6.27, Syntax Rules 9 > new SqlFunction( > "MOD", > SqlKind.OTHER_FUNCTION, > ReturnTypes.ARG1_NULLABLE, > null, > OperandTypes.EXACT_NUMERIC_EXACT_NUMERIC, > SqlFunctionCategory.NUMERIC); > Calcite Document description: > MOD(numeric, numeric) Returns the remainder (modulus) of numeric1 divided by > numeric2. The result is negative only if numeric1 is negative > > MOD(34.5,3), mod(19,6.7) 异常: > org.apache.calcite.sql.validate.SqlValidatorException: Cannot apply 'MOD' to > arguments of type 'MOD(<DOUBLE>, <INTEGER>)'. Supported form(s): > 'MOD(<EXACT_NUMERIC>, <EXACT_NUMERIC>)' at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > In MySQL: > https://dev.mysql.com/doc/refman/5.7/en/mathematical-functions.html#function_mod > Modulo operation. Returns the remainder of N divided by M. We can get the > correct value in MOD(34.5,3), MOD(19,6.7) situation. > MOD(34.5,3), mod(19,6.7) -> 1.5 , 5.6. > So, In this JIRA. we should do two thing: > 1. Decide whether we are consistent with Mysql. > 2. Improve the document, clearly inform the user for the MOD behavior. > Reference: > https://docs.microsoft.com/en-us/sql/t-sql/data-types/data-type-conversion-database-engine > https://issues.apache.org/jira/browse/CALCITE-1296 > https://issues.apache.org/jira/browse/CALCITE-613 > Hi, [~julianhyde] What do you think? Maybe this is related to implicit > conversions. I am not sure. I appreciated if you can tell me your thoughts. > :) -- This message was sent by Atlassian JIRA (v6.4.14#64029)