-
Notifications
You must be signed in to change notification settings - Fork 4k
ARROW-14093: [C++] subtract(date, date) -> duration kernel #12124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
|
The title should be |
I think so. I suppose same goes for most most ARROW-11090 jiras. |
|
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? |
|
I don't see a problem with ms. |
|
Sorry, I've been a bit backlogged, I'll try to get through these tomorrow (Friday) |
|
No worries @lidavidm! :) |
bb12021 to
970ac73
Compare
lidavidm
left a comment
There was a problem hiding this 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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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 :).
|
Thanks for the review @lidavidm! I've accidentally amended changes to the last commit, sorry. |
lidavidm
left a comment
There was a problem hiding this 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)
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
| RETURN_NOT_OK( | ||
| Status::Invalid("Subtraction of zoned and non-zoned times is ambiguous. (", | ||
| left_type->timezone(), right_type->timezone(), ").")); |
There was a problem hiding this comment.
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(...);?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
|
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. |
This is to resolve ARROW-14093.