forked from numpy/numpy
-
Notifications
You must be signed in to change notification settings - Fork 0
DOC: adding docstring to TooHardError class #1
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
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Also remove FutureWarning and update documentation Co-authored-by: Ralf Gommers <ralf.gommers@gmail.com>
This commit optimizes the operations below: - fmod (signed/unsigned integers) - remainder (signed/unsigned integers) - divmod (signed/unsigned integers) - floor_divide (signed integers) using the VSX4/Power10 integer vector division/modulo instructions. See the improvements below (maximum speedup): - numpy.fmod - arr OP arr: signed (1.17x), unsigned (1.13x) - arr OP scalar: signed (1.34x), unsigned (1.29x) - numpy.remainder - arr OP arr: signed (4.19x), unsigned (1.17x) - arr OP scalar: signed (4.87x), unsigned (1.29x) - numpy.divmod - arr OP arr: signed (4.73x), unsigned (1.23x) - arr OP scalar: signed (5.05x), unsigned (1.31x) - numpy.floor_divide - arr OP arr: signed (4.44x) The times above were collected using the benchmark tool available in NumPy.
This commit tries to redo the scalar math logic to take some more care about subclasses, but most of all introduce logic to defer to the `other` if `self` can be cast to it safely (i.e. it is the correct promotion). This makes things much faster and more reliable, since we now use defer much less to `ufuncs` indirectly. This ensures that integer overflows are reported more reliably. Another major point about it, is that this reorganizes the coercion of Python int, float, complex (and bool). This should help a bit with switching to "weak" Python scalars. This may just be a first step on a longer path...
This significantly speeds pure up integer operations since checking floating point errors is somewhat slow. It seems to slow down some clongdouble math a tiny bit, maybe because the functions don't always get inlined fully.
The function was only used for the scalarmath and is not even documented, so schedule it for deprecation.
The assert doesn't make sense for richcompare, since it has no notion of forward. It is also problematic in the other cases, because e.g. complex remainder defers (because complex remainder is undefined). So `complex % bool` will ask bool, which then will try to defer to `complex` (even though it is not a forward op). That is correct, since both should defer to tell Python that the operation is undefined.
For some reason, some of the clang/macos CI is failing in the multiply operation becaues it fails to report floating point overflow errors. Maybe using `NPY_FINLINE` is enough to keep the old behaviour, since this seemed not to have beena problem when the function was a macro.
IIRC, these have to be inlined, because otherwise we pass structs by value, which does not always work correctly.
... also undefine any complex floor division, because it is also not defined. Note that the errors for some of these may be a bit less instructive, but for now I assume that is OK.
However, note that complex comparisons currently do NOT agree, but the problem is that we should possibly consider changing the ufunc rather than the scalar, so not changing it in this PR.
These are complicated, and modifications could probably be allowed here. The complexities arise not just from the assymetric behaviour of Python binary operators, but also because we additionally have our own logic for deferring sometimes (for arrays). That is, we may coerce the other object to an array when it is an "unknown" object. This may assume that subclasses of our scalars are always valid "arrays" already (so they never need to be coerced explicitly). That should be a sound assumption, I think?
Co-authored-by: Matti Picus <matti.picus@gmail.com>
ENH,SIMD: Vectorize modulo/divide using the universal intrinsics (VSX4)
I am not sure why the previous places led to (oddly) unreliable code on some Mac clang versions. Moving it here fixes it, so it is all fine. There was previously some inlining, which we should be able to trust the compiler to do (as an attempt to get back to the same result as the macro version. But it turned out the issue was moving down the FPE clearing till after we know we actually do the operation. This also removes an unused function for true division IIRC.
Probably not a real bug, but this seems cleaner to me. Plus maybe it will actually help with getting the PyPy behavior right.
PyPy does not seem to replace tp_richcompare in the "C wrapper" object for subclasses defining `__le__`, etc. That is understandable, but means that we cannot (easily) figure out that the subclass should be preferred. In general, this is a bit of a best effort try anyway, and this is probably simply OK. Hopefully, subclassing is rare and comparing two _different_ subclasses even more so.
* PERF cache unicode version of __array_ufunc__ Cache PyUniCode object with value __array_ufunc__ for attribute lookup * MAINT Refactor PyArray_LookupSpecial and PyArray_LookupSpecial_OnInstance Refactor code so the unicode names are interned * clear errors of type PyExc_AttributeError * STY: Tiny style fixes for get_attr_string.h Frankly, we should not use a header anymore there, it should be a C file now, but that is better for another PR/day. Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
Reduce the overhead of np.linalg.norm by replacing dot(x,x) with x.dot(x). This is OK, since `x` is converted to a base-class array here.
DOC: Update set of allowed f2cmap types
* DOC: Windows and F2PY * DOC: Intel F2PY * DOC: F2PY Windows Reviewer Comments I Co-authored-by: Melissa Weber Mendonça <melissawm@gmail.com> * DOC: Clean F2PY Win and add to index * DOC: F2PY windows narrative rewrite * DOC: Clean up Windows environment suggestions * DOC: Add Windows Terminal Details * DOC: Update windows index * MAINT: Clean doc * DOC: Add partials for Windows * DOC: Update as per review Co-authored-by: Melissa Weber Mendonça <melissawm@gmail.com> * DOC,BLD: Add to toctree to appease build Co-authored-by: Melissa Weber Mendonça <melissawm@gmail.com>
TEST: on PyPy, skip hanging slow test and require-mem on second [wheel build]
This has been bugging me for a bit. The concurrent.futures Executor requires checking the result for the error to be raised. That makes sense, but just means we need to consume the result explicitly here to ensure we know about compile errors. Otherwise, compile errors just pass silently (which is very confusing if the old object files are still around and the tests run based on the old version).
Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
BUG: Ensure compile errors are raised correctly
Pytest silence these normally anyway (capturing it to print it only on failure), but occasionally I run with `-s` and I don't think this output adds anything unless using printing to debug a specific test. If nobody else cares about it nvm, just close it :). Otherwise this cleans up everything in the fast tests, except the f2py compilation right now.
* PERF Statically allocate unicode strings * Update numpy/core/src/multiarray/multiarraymodule.c Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net> Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
No need to use C++ here, but getting rid of the template engine is already a plus.
TST: Remove most prints from the test suit run
…-cxx-npy_cpu_features [road-to-cxx] npy_cpu_features moved to pure C
* Fixed numpy#21301 * Fixed numpy#21436, better error message, organized test cases as requested * Update numpy/core/src/umath/ufunc_object.c Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
* TST: Add test checking if newaxis indexing works for `array_api` Also removes previous check against newaxis indexing, which is now outdated * TST, BUG: Allow `None` in `array_api` indexing Introduces test for validating flat indexing when `None` is present * MAINT,DOC,TST: Rework of `_validate_index()` in `numpy.array_api` _validate_index() is now called as self._validate_index(shape), and does not return a key. This rework removes the recursive pattern used. Tests are introduced to cover some edge cases. Additionally, its internal docstring reflects new behaviour, and extends the flat indexing note. * MAINT: `advance` -> `advanced` (integer indexing) Co-authored-by: Aaron Meurer <asmeurer@gmail.com> * BUG: array_api arrays use internal arrays from array_api array keys When an array_api array is passed as the key for get/setitem, we access the key's internal np.ndarray array to be used as the key for the internal get/setitem operation. This behaviour was initially removed when `_validate_index()` was reworked. * MAINT: Better flat indexing error message for `array_api` arrays Also better semantics for its prior ellipsis count condition Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net> * MAINT: `array_api` arrays don't special case multi-ellipsis errors This gets handled by NumPy-proper. Co-authored-by: Aaron Meurer <asmeurer@gmail.com> Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
Co-authored-by: Matti Picus <matti.picus@gmail.com>
Adding the setuptools version to the matrix makes sure that asv (run through `runtests`) locally works again. I am not quite sure what changed that I now run into this issue and previously do not (and neither does the CI runner yet). There may be a better solution, but this seems fine for now? Closes numpygh-21428
MAINT: Remove `f2py.f2py_testing` without replacement
DOC: Add missing entries in `numpy.testing` documentation
DEV: Pin setuptools in the asv config
Optimizes the parsing of shape tuples and integers by avoiding multiple conversions and generally refactoring the code. Closes numpygh-19010, that parsing a single integer was very slow (due to trying to convert it to a squence twice). Co-authored-by: Sebastian Berg <sebastian@sipsolutions.net>
MAINT,ENH: Rewrite scalar math logic
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
issue: 10106
Changes were made according to the previous request for a docstring to the class TooHardError.
Thanks for your attention