ARROW-14101: [C++] multiply(duration, integer) -> duration kernel

[rok]

This is to resolve ARROW-14101 and ARROW-14102.

[github-actions]

https://issues.apache.org/jira/browse/ARROW-14101

[jorisvandenbossche]

For the mutiply_checked, should we add a test for a duration that would go out of bounds? Or is this already sufficiently covered by integer multiply_checked tests if that is using the same underlying implementation?

[rok]

For the mutiply_checked, should we add a test for a duration that would go out of bounds? Or is this already sufficiently covered by integer multiply_checked tests if that is using the same underlying implementation?

Another test won't hurt :) I'll add it.

[rok]

Added the test and removed divide checked (seemed redundant since we're only dividing with integers).

[rok]

@pitrou could you please take a look at this one? It covers multiply and divide (ARROW-14102).

I think the CI error is due to s3fs.

[jorisvandenbossche]

Can you have a case in this test where the division is not exact?

[rok]

Added.

[jorisvandenbossche]

Added the test and removed divide checked (seemed redundant since we're only dividing with integers).

I would keep divide_checked. You could give the same argument for divide_checked being redundant for integer types, but we still allow you to use it. It could be annoying that, when using divide_checked, you need to switch to divide, only if your input type is duration.

[rok]

Thanks for reviewing @jorisvandenbossche. Agreed on the divide_checked. Added.

[pitrou]

This looks unexpected to me since int64 is not a temporal at all. @lidavidm What do you think?

[lidavidm]

I think this is fine, but maybe we need a better name for what this function does.

That said, I don't think this change is needed for this function to work, anyways. There's only a single temporal argument so there isn't really a meaningful common resolution to cast to.

[pitrou]

To be honest, the function doesn't seem to have changed :-). It's just the additional test that surprised me (but adding a test for existing behaviour is useful, thank you @rok ).

[rok]

Well duration has a unit and int64 is dimensionless. The goal of the function is to find the best common unit and I'd argue it still does.

[pitrou]

Is it worth also supporting multiply(int64, duration) or would commutativity be handled at an upper level? @lidavidm

[lidavidm]

Hmm, I don't see why not. It could just use the same exec function.

[rok]

Done.

[pitrou]

Can you some negative value(s) into the mix?

[rok]

Done.

[pitrou]

Also check that division by zero raises?

[rok]

Added.

[ursabot]

Benchmark runs are scheduled for baseline = 194ace5 and contender = 2f8f1e8. 2f8f1e8 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.25% ⬆️0.13%] test-mac-arm
[Failed ⬇️0.36% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.38% ⬆️0.21%] ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[rok]

Thanks all!