Closed mcara closed 10 months ago
Attention: 1 lines
in your changes are missing coverage. Please review.
Files | Coverage Δ | |
---|---|---|
spherical_geometry/great_circle_arc.py | 40.45% <66.66%> (+0.92%) |
:arrow_up: |
:loudspeaker: Thoughts on this report? Let us know!.
I also have question of whether the custom C-extension still holds for cross-architecture or even necessary in this age, but that is pondering for another time.
Yes, the custom extension is needed as it performs computations with quad accuracy.
This path is never tested because it is only used when the custom C-extension is missing. How do we know they are equivalent?
Do you have a suggestion?
Do you have a suggestion?
We could force this flag to pretend the C-extension isn't there in one of the jobs. 🤷
Also I did accidentally run that mode back in #243 when the jobs refused to build the C-ext at one point, and I discovered some differences:
computations with quad accuracy
Is that really necessary though?
Is that really necessary though?
If this question about the unit tests, then YES. If it is about the need to use quad accuracy in general, then the answer is again YES.
I do not want to discuss this any further in this PR. In https://github.com/spacetelescope/spherical_geometry/pull/233 I modified a piece of the algorithm to get extra couple of bits of accuracy. Yes, it is needed, in my opinion. But if you would like to have a broader discussion, feel free to open an issue and tag @mdboom @perrygreenfield @WilliamJamieson and others
You can also disable quad accuracy and run the pipelines on many sets from archive. "Many" is the secret here. double accuracy is enough for many sets but for a significant number of data, it is not.
With no formal approval from @pllim this has been merged.
I don't think you need my approval. 😉
But FWIW LGTM. 👏
This PR replaces the deprecated
numpy.core._umath_tests.inner1d()
(which will likely error in numpy>=2) with an alternative implementation.