Skip to content

Conversation

@rok
Copy link
Member

@rok rok commented Jan 11, 2022

This is to resolve ARROW-14093.

@github-actions
Copy link

@github-actions
Copy link

⚠️ Ticket has not been started in JIRA, please click 'Start Progress'.

@lidavidm
Copy link
Member

The title should be -> duration, not -> interval, right?

@rok
Copy link
Member Author

rok commented Jan 12, 2022

The title should be -> duration, not -> interval, right?

I think so. I suppose same goes for most most ARROW-11090 jiras.

@rok rok changed the title ARROW-14093: [C++] subtract(date, date) -> interval kernel ARROW-14093: [C++] subtract(date, date) -> duration kernel Jan 12, 2022
@rok
Copy link
Member Author

rok commented Jan 12, 2022

This now always returns in ms. Do we want to be able to output other units or is it ok to defer to casting kernels if other units are desired?

@lidavidm
Copy link
Member

I don't see a problem with ms.

@lidavidm
Copy link
Member

Sorry, I've been a bit backlogged, I'll try to get through these tomorrow (Friday)

@rok
Copy link
Member Author

rok commented Jan 27, 2022

No worries @lidavidm! :)

@rok rok force-pushed the ARROW-14093 branch 3 times, most recently from bb12021 to 970ac73 Compare January 31, 2022 21:09
@lidavidm lidavidm self-requested a review January 31, 2022 22:36
Copy link
Member

@lidavidm lidavidm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, just a couple nits.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, but as used, the units should always match right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's used to resolve duration resolution in subtract(timestamp, timestamp) -> duration and the timestamps could be of any resolution. Am I missing something?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I was thinking, since we only register kernels where the units match, technically this max is redundant, but it doesn't hurt to have it. (Though perhaps it would be safer to DCHECK or return an error if they don't match to avoid accidentally doing arithmetic on incompatible types.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I think return types are computed post-implicit-casts, right? So they should match here.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes of course! Fixed. Thanks :).

@rok
Copy link
Member Author

rok commented Feb 1, 2022

Thanks for the review @lidavidm! I've accidentally amended changes to the last commit, sorry.
I've also refactored some other temporal subtraction tests to avoid duplicating subtract and subtract_checked logic.

Copy link
Member

@lidavidm lidavidm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, just some nits/suggestions (sorry for the back-and-forth)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I was thinking, since we only register kernels where the units match, technically this max is redundant, but it doesn't hurt to have it. (Though perhaps it would be safer to DCHECK or return an error if they don't match to avoid accidentally doing arithmetic on incompatible types.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I think return types are computed post-implicit-casts, right? So they should match here.)

const std::vector<ValueDescr>& args) {
auto left_type = checked_cast<const TimestampType*>(args[0].type.get());
auto right_type = checked_cast<const TimestampType*>(args[1].type.get());
DCHECK_EQ(left_type->id(), right_type->id());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, but the checked_cast should account for this in debug mode since the dynamic_cast will give us nullptr (or else if we're going to assert, we should assert before casting)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Comment on lines 1647 to 1649
RETURN_NOT_OK(
Status::Invalid("Subtraction of zoned and non-zoned times is ambiguous. (",
left_type->timezone(), right_type->timezone(), ")."));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, but just return Status::Invalid(...);?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@lidavidm lidavidm closed this in 56386a4 Feb 2, 2022
@ursabot
Copy link

ursabot commented Feb 2, 2022

Benchmark runs are scheduled for baseline = c715beb and contender = 56386a4. 56386a4 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.36% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.3% ⬆️0.09%] ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python. Runs only benchmarks with cloud = True
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants