Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

ENH: Implement divmod and remainder for timedelta and int #16458

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
Loading
from

Conversation

seberg
Copy link
Member

@seberg seberg commented May 31, 2020

Also fixes that we should not be giving warnings when the input is already a NaT.


@jbrockmendel maybe you can have a look as well, whether this seems right? Maybe @tylerjereddy if you have the time, since the initial implementation was from you.

Marking as draft, although its probably pretty far. This probably needs one more iteration, possibly a few more tests.
I may have went down a wrong path when modifying/trying to expand the tests and get the warnings right, it did get somewhat messy. It combines all into one giant test now (including the integers), since we can do at least partial cross checks.

One additional test that may be good, is a test for the integer types other than int64, and I have not yet checked carefully if stealing some pandas tests may be nice.

TODO:

  • Add basic tests for non-native byte order (timedelta/first argument mainly) and non-int64 integer inputs.

Copy link
Contributor

@tylerjereddy tylerjereddy left a comment

Choose a reason for hiding this comment

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

I found running the pandas test suite against the NumPy feature branch helpful for these. Usually the impact was pretty easy to fix though & they seemed pretty keen to get the enhancements last time I believe.

The CI fail is unrelated--I wish we could get Azure to have a 32-bit mingw on the base VMs, that DL is an unfortunate bottleneck for NumPy/SciPy.

return -1;
}
out_dtypes[1] = PyArray_DescrFromType(NPY_LONGLONG);
if (out_dtypes[1] == NULL) {
Copy link
Contributor

Choose a reason for hiding this comment

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

codecov seems to be showing useful patch diffs again at least--not sure if this conditional is too pathological to test, but shows up as uncovered

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, is that for platforms that don't support that integer size or something? I guess NumPy probably only uses one or maybe two platforms for the cov reports in any case.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmmm, I copy pasted this without thinking maybe, or just wrote it without thinking. This condition can never be hit, it would be an allocation error, but that is not even possible...

Copy link
Member Author

@seberg seberg May 31, 2020

Choose a reason for hiding this comment

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

@tylerjereddy does codecov only show them if it thinks there is a serious change? It seemed a bit random whether or not the patch diff shows up in the CI grid.

EDIT: Example for a missing one #16418

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we need another setting or two for it to always show the patch diff--let's ping @thomasrockhu from their team.

I believe if there are some failures in CI, this can affect the reporting status for codecov. When we turned it back on recently though, it did show a patch entry, and just said something like "no tracked files affected" because we only changed the codecov config file itself. Anyway, now I'm side-tracking your PR..

Choose a reason for hiding this comment

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

Hi everyone, taking a look at this now. Just to make sure I'm getting this right, sometimes the patch status check isn't showing up on PRs? If there are failures in CI, Codecov normally doesn't report back, but that setting can be overwritten. This would prevent project from showing up as well, though.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I think project shows up now always (or almost always?), patch seemed to be missing sometimes, not sure if due to failures. Do failures in the azure pipeline count, since we have some there fairly regularly unfortunately.

Choose a reason for hiding this comment

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

So looks like for #16418, patch had still been set to false, and that's why no patch status showed up.

However, for more recent PRs that have a successful CI, I'm seeing a patch status. We, unfortunately, can't distinguish between what is and what isn't a CI status, so failures in Azure Pipelines do count. If you would prefer not to have this behavior, you can edit the yaml with

codecov:
  require_ci_to_pass: false

@@ -1264,6 +1264,13 @@ PyUFunc_RemainderTypeResolver(PyUFuncObject *ufunc,
out_dtypes[2] = out_dtypes[0];
Py_INCREF(out_dtypes[2]);
}
else if (PyTypeNum_ISINTEGER(type_num2)) {
out_dtypes[0] = PyArray_DESCR(operands[0]);
Copy link
Member Author

Choose a reason for hiding this comment

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

Note to self, this needs an ensure_dtype_nbo.

Also fixes that we should not be giving warnings when the input
is already a NaT.
@seberg seberg force-pushed the divmod-timedelta branch from 19996f8 to 000dfda Compare June 1, 2020 00:47
@jbrockmendel
Copy link
Contributor

Nice, thanks for pushing forward on this

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.

4 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.