[C++][Compute] Add rounding kernel

[asfimport]

Kernel to round an array of floating point numbers. Should return an array of the same type as the input. Should have an option to control how many digits after the decimal point (default value 0 meaning round to the nearest integer).

Reporter: Ian Cook / @ianmcook
Assignee: Eduardo Ponce / @edponce

Related issues:

• [C++] Arithmetic kernels for numeric arrays (is a child of)
• [C++][Compute] Add floor, ceiling, and truncate kernels (is related to)
• [C++][Compute] Add decimal support to round functions (is depended upon by)

PRs and other links:

• GitHub Pull Request #10349

_{Note: This issue was originally created as ARROW-12744. Please see the migration documentation for further details.}

[asfimport]

Joris Van den Bossche / @jorisvandenbossche:
For the midpoint values, Python's round() and numpy use the "round half to nearest even value" approach (https://en.wikipedia.org/wiki/Rounding#Round_half_to_even).

[asfimport]

Eduardo Ponce / @edponce:
C++ provides a std::round() function where the rounding mode can be set at runtime. Note that library implementations can provide additional rounding modes or support a subset. It seems there is no round-half-to-even/odd defined in spec.

1. Should the Arrow round kernel make use of std::round and extend the rounding modes to support round-half-to-even/odd and only in these cases implement them explicitly?

2. Also, std::round() provides versions where it outputs integral data instead of floating-point. Are these variants desirable in Arrow?

[asfimport]

Ben Kietzman / @bkietz:

1. IMHO, compute kernels should not rely on (or be affected in any way by) the floating point environment. Users may have a need to adjust this for their own applications and arrow's kernels should produce correct output regardless

2. Output should be of the same floating point type as the input since the extent of rounding is configurable (probably via a function option like RoundOptions::ndigits) whereas integral output is only well formed if we're rounding to the nearest one.

[asfimport]

Eduardo Ponce / @edponce:
I understand this issue requests rounding to the nearest integer, but a more general rounding function is able to round based on any factor. For example:

• Rounding 113 to the nearest multiple of 10 is 110
• Rounding 1.13 to the nearest multiple of 0.1 is 1.1

[asfimport]

Eduardo Ponce / @edponce:
A draft PR is available that implements round function as a unary scalar function. It outputs float64 for integral inputs and matching type for floating-point inputs.

Rounding behavior is controlled via 2 option controls, a rounding mode (specifies displacement behavior) and a multiple (scale and precision).

Feedback is welcomed w.r.t. to implementation, rounding options and names, and documentation.

[asfimport]

Eduardo Ponce / @edponce:
The current implementation follows a rounding with multiple approach which is more general/flexible than ndigits parameter in Python round and decimals parameter in NumPy, pandas round, and MySQL.

The following are comments on round APIs:

• The decimals parameter name in NumPy and pandas seems counter-intuitive in that when it is a negative value it corresponds to the non-decimal part of the value. IMHO ndigits is a more suitable name.

• rounding with multiple bypasses the need to calculate pow(10, decimals). Although, I expect the other software use a LUT table for power(10, x) which is better. For example, MySQL limits |decimals| < 30.

• The decimals parameter only supports rounding to powers of 10.

  We can also include two variants of rounding functions (similar to Excel)

• round(x, ndigits)

• mround(x, multiple)

  I am inclined to support the two variants to both support current APIs as-is and provide a more general rounding function.

  Any comments or suggestions are welcomed.

[asfimport]

Eduardo Ponce / @edponce:
The current PR includes both variants, round(x, ndigits) and round(x, multiple).

[asfimport]

Krisztian Szucs / @kszucs:
Postponing to 6.0.

[asfimport]

Antoine Pitrou / @pitrou:
Issue resolved by pull request 10349
#10349