Skip to content
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

Adjust to numpy dev scalar format #15065

Draft
wants to merge 29 commits into
base: main
Choose a base branch
from

Conversation

mhvk
Copy link
Contributor

@mhvk mhvk commented Jul 12, 2023

DEV NOTE: Do not merge until numpy 2.0 is actually out! Do not merge until this is merged and available in numpy nightly wheel (when we start to see things fail in devdeps)

  • Revert TST: Use legacy numpy 1.25 print #15096 if it got in first. (EDIT: it should get in first; this one is for when 2.0 is actually out)
  • Decide for scalar quantity.value whether it should not just return an array scalar (see below)
  • Check whether we may want similar adjustments elsewhere (maybe as follow-up; e.g., Structure for structure units output) - but this should not be part of this PR, so punted to Post-numpy-2.0 changes in repr/str #15793.
  • Decide whether we are happy for the docs to pass tests only on numpy >=2.0. If not, we have to update doctest-plus to ignore np.float64, etc., in comparing numerical values. 2023-Dec: seems that we are heading to a docs-on-numpy>=2.0 only state

This is a start to adjusting our tests for the change in how scalars are formatted in NEP 51 - see numpy/numpy#22449

Note that it does not adjust tests of repr and the documentation yet!

Posting this in part to show that outside of repr this is not a big deal.

In the documentation, one often will have things like

>>> q = 5 * u.m
>>> q.value
5.0  -> np.float64(5.0)

This brings up a more general question of whether we should use this opportunity of the repr changing to just return an array scalar (i.e., it would be np.array(5.0) instead).

Fix #15095
Fix #15792

  • By checking this box, the PR author has requested that maintainers do NOT use the "Squash and Merge" button. Maintainers should respect this when possible; however, the final decision is at the discretion of the maintainer that merges the PR.

@github-actions
Copy link

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

  • Do the proposed changes actually accomplish desired goals?
  • Do the proposed changes follow the Astropy coding guidelines?
  • Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
  • Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
  • Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see "When to rebase and squash commits".
  • Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
  • Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
  • Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
  • Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
  • At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

@github-actions
Copy link

👋 Thank you for your draft pull request! Do you know that you can use [ci skip] or [skip ci] in your commit messages to skip running continuous integration tests until you are ready?

@pllim
Copy link
Member

pllim commented Jul 12, 2023

The diff looks much simpler than I anticipated. Thanks! 🤞

@mhvk
Copy link
Contributor Author

mhvk commented Jul 12, 2023

Well, the main diff from the docs is not yet in there...

@pllim
Copy link
Member

pllim commented Jul 26, 2023

If #15096 goes in first, that PR also has to be reverted here. FYI.

@mhvk mhvk force-pushed the adjust-to-numpy-dev-scalar-format branch from 28e80f7 to cf64e6c Compare July 26, 2023 19:16
@mhvk
Copy link
Contributor Author

mhvk commented Jul 26, 2023

I just rebased and force-pushed to get a fresh test run. If -dev passes, we probably should run extra CI as well, just in case.

p.s. Very pressed for time right now, so if this doesn't converge easily, happy with #15096 as a stop-gap measure...

@pllim
Copy link
Member

pllim commented Jul 26, 2023

Alas... still 95 failed (though 3 of them are from modeling and unrelated).

@pllim
Copy link
Member

pllim commented Jul 26, 2023

Looks like we need version check in some places?

ImportError: cannot import name 'get_formatter' from 'numpy.core.arrayprint'

@mhvk
Copy link
Contributor Author

mhvk commented Jul 26, 2023

Ah, right, that changed, we didn't make the new get_formatter in the end! Can be a quick change (hopefully)...

@pllim
Copy link
Member

pllim commented Jul 26, 2023

There are 51 failures now (3 unrelated, the rest doctest output comparison failures). I actually don't like the new look in our own doc test output... especially when you print out the WCS... it looks jarring and adds noise to the actual data I am interested in (say, what is the value of CVAL1, without also have to see it is np.float because I already know that).

@mhvk
Copy link
Contributor Author

mhvk commented Aug 11, 2023

The problem with this PR is that all doctests will fail on older numpy. In principle, we can just not run the tests on older versions, but that makes sense only once 2.0 is actually out. I think the logical route is to go with #15096 first, so that things work again, and then do this one once 2.0 is released.

@pllim
Copy link
Member

pllim commented Aug 11, 2023

In that case might even want to wait for numpy 2.1 for a chance for users to catch up? Or is that too long?

@@ -121,7 +121,7 @@ class StructuredUnit:
Structured units share most methods with regular units::
>>> su.physical_type
((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), PhysicalType('time'))
astropy.units.structured.Structure((astropy.units.structured.Structure((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), dtype=[('f0', 'O'), ('f1', 'O')]), PhysicalType('time')), dtype=[('f0', 'O'), ('f1', 'O')])
Copy link
Member

Choose a reason for hiding this comment

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

How does @namurphy and @nstarman feel about this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that was one case where I felt we might want to override __repr__... I'll put it on top.

Copy link
Member

Choose a reason for hiding this comment

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

Agreed! I think the current ((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), PhysicalType('time')) should be the behaviour of __str__.
For __repr__ we at least don't want to show the module structured.

Suggested change
astropy.units.structured.Structure((astropy.units.structured.Structure((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), dtype=[('f0', 'O'), ('f1', 'O')]), PhysicalType('time')), dtype=[('f0', 'O'), ('f1', 'O')])
astropy.units.Structure((astropy.units.Structure((PhysicalType('length'), PhysicalType({'speed', 'velocity'})), dtype=[('f0', 'O'), ('f1', 'O')]), PhysicalType('time')), dtype=[('f0', 'O'), ('f1', 'O')])

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed, that is the minimal change. But coming back to this fairly substantial PR, it is probably best to do that afterwards - I raised a new issue at #15793.

Copy link
Member

Choose a reason for hiding this comment

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

Totally fine by me. I can review this PR in a few days, if you're ready @mhvk

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks! This PR is basically waiting for numpy 2.0 to be released... I'm just keeping it up to date once in a while until that happens.

@mhvk
Copy link
Contributor Author

mhvk commented May 11, 2024

While testing this with test-devdeps-alldeps, I found some tests with pandas failed.

See fix in #16439. Combined with @larrybradley's fixes in #16431 that I already rebased on, everything should pass, which will mean this can go out of draft. Note that #16439 will bring in a devdeps-alldeps run in extra CI that would be good for a final sanity check.

@@ -266,6 +266,8 @@ def test_iter_coosys(self):
)
def test_select_missing_columns_error_message(columns, expected_missing):
# see https://github.com/astropy/astropy/pull/15956
# Turn into numpy strings (otherwise match fails on numpy >= 2.0).
expected_missing = [np.str_(e) for e in expected_missing]
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm don't think this is the correct fix here. I'll link to my own solution when I open the PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants