feat: add decimal argument support to round function

[andrew-coleman]

The round function has a number of variants to support different numeric types. This commit adds support for rounding decimals. This is required for the spark module.

[EpsilonPrime]

Can this happen with decimal representations? I'd argue all of the floating point handling stuff here does not apply.

[andrew-coleman]

Why would these not apply? For example, the input value 2.5 could be represented exactly in a decimal type, but rounding it to the nearest integer would result in 2 if the rounding mode is TIE_TO_EVEN or 3 if the mode is TIE_AWAY_FROM_ZERO.

[EpsilonPrime]

For all other decimal functionality we have placed them in _decimal.yaml files. Not sure if we want to have just this one function in a file by itself though.

[EpsilonPrime]

Does this operation affect the scale? We should probably clarify that here.

[andrew-coleman]

I guess this function could return a different decimal type (i.e. reduce the precision and the scale parameters), but I was working on the assumption that it would just return a different value. I'm not sure if that is what you are asking.

[jacques-n]

Let's not assume. Let's add some expected behaviors here. Once we get tests inside core, we can transplant those into test cases. And if this is the behaviors of spark we're trying to match, we shouldn't probably just put this in a spark function file (or name it spark_round here). Decimal behavior is often quite different between different systems.

[andrew-coleman]

Just revisiting this. I've updated the parameters of the decimal return type to match the logic used by the Spark round functions:
https://github.com/apache/spark/blob/master/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala#L1492

I note the comment here: #671 (comment)
Does this still apply? If so, how would you suggest I work around this since the output decimal scale depends on that second argument?

Thanks!

[EpsilonPrime]

I don't think we can use any constants in the calculation. The s parameter in round could be not a constant although I suspect some backends only will allow constants here. If it is not a constant then we don't know a lot. If the number turns out to be negative the scale could even increase. Because that second value could change the value in any manner we likely have to return maximum scale and precision here.

I will take it as an action to try running these tests against a backend (as the consumer testing does) to see if the tests are functional/correct.

[EpsilonPrime]

there are three digits here so the precision needs to be 3

[EpsilonPrime]

The last two lines should be:

round(123::dec<3,0>, -2::i32) = 100::dec<3,0>
round(8793::dec<4,0>, -2::i32) = 8800::dec<4,0>

[EpsilonPrime]

Since this file is the rounding_decimal directory I'd name this file ceil.test.

[EpsilonPrime]

The last two lines should be:

round(123::dec<3,0>, -2::i32) = 100::dec<3,0>
round(8793::dec<4,0>, -2::i32) = 8800::dec<4,0>

[EpsilonPrime]

FWIW, DuckDB returns decimal<8,0> for the first two and decimal<2,0> for the last one (and decimal<8,0> for the floor tests too). There may be some variation between systems here.

[EpsilonPrime]

DuckDB returns:

2,0
8,1
2,0
3,0
4,0

[andrew-coleman]

Thanks @EpsilonPrime, that's helpful. It looks like the scale of the decimal returned by DuckDB is also a function of the second parameter of round() as is the case with Spark.

Given the following query:

select num, floor(num), ceil(num),
     round(num, -2), round(num, -1), round(num, 0),
     round(num, 1), round(num, 2), round(num, 3)
from (values (0.5), (-0.5), (999.9), (-999.9), (2.75)) as table(num)

Spark produces the following output and type schema:

+-------+----------+---------+--------------+--------------+-------------+-------------+-------------+-------------+
|    num|FLOOR(num)|CEIL(num)|round(num, -2)|round(num, -1)|round(num, 0)|round(num, 1)|round(num, 2)|round(num, 3)|
+-------+----------+---------+--------------+--------------+-------------+-------------+-------------+-------------+
|   0.50|         0|        1|             0|             0|            1|          0.5|         0.50|         0.50|
|  -0.50|        -1|        0|             0|             0|           -1|         -0.5|        -0.50|        -0.50|
| 999.90|       999|     1000|          1000|          1000|         1000|        999.9|       999.90|       999.90|
|-999.90|     -1000|     -999|         -1000|         -1000|        -1000|       -999.9|      -999.90|      -999.90|
|   2.75|         2|        3|             0|             0|            3|          2.8|         2.75|         2.75|
+-------+----------+---------+--------------+--------------+-------------+-------------+-------------+-------------+

root
 |-- num: decimal(5,2) (nullable = false)
 |-- FLOOR(num): decimal(4,0) (nullable = true)
 |-- CEIL(num): decimal(4,0) (nullable = true)
 |-- round(num, -2): decimal(4,0) (nullable = true)
 |-- round(num, -1): decimal(4,0) (nullable = true)
 |-- round(num, 0): decimal(4,0) (nullable = true)
 |-- round(num, 1): decimal(5,1) (nullable = true)
 |-- round(num, 2): decimal(6,2) (nullable = true)
 |-- round(num, 3): decimal(6,2) (nullable = true)

I propose, then, that the given an input of type decimal<P, S>, the return type expression should be:

        return: |-
          precision = min(P + 1, 38)
          decimal?<precision, S>

Which is not necessarily what it actually returns, but is the maximum precision/scale of what it could return (taking into account your earlier comment).

How does that sound?