Scalar binop giveup in fallback #1
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
This function is used to be called `_typenum_fromtypeobj` but since it is used in more places (including one new added now), giving it a long descriptive name seemed reasonable. Ideally, I would like to phase out the `user` option and expose (or use) the new functionality in the array-coercion to handle such cases making this only useful for super-fast paths of our internal scalars.
This simplification and code change does a few things:
1. We remove all binop deferals, by simply only handling the numeric
numpy scalars and python floats+integers specifically.
All other object will cause deferal.
This specifically defers subclassess even of NumPy scalars
(unless it is `class+subclass` where Python will reverse the
lookup.
2. We always defer binops if the type number of the current type
is smaller. This allows `float32 + float64` to retry with
`float64 + float32`, which is much faster.
3. It simplifies the double special cases and expand it to
include longdouble.
The previous casting code was faster, so cases such as:
float64 + float32
were somewhat faster. However, previously `float32 + float64`
would end up using the fallback path and thus be *much* slower.
Identically, `scalar + array0d` had previously a fast-path which
is now removed. While, thus much slower, it means that the
performance is now symmetric wtih `array0d + scalar`.
Generally, it could make sense to make a dumbed down ufunc machinery
for 0D scalars, to strike a middle path between the current super-slow
array fallback and the somewhat quick scalar paths.
However, scalars do have the advantage that they can refuse to handle
anything that is not known much easier, i.e. they do not need to find
the common dtype. If the other scalar is not known, they can just defer
(or rather fall back to the slow paths).
3e1fc91 to
3e3a4dd
Compare
ganesh-k13
pushed a commit
that referenced
this pull request
Feb 10, 2021
…py#18295) * BUG: don't mutate list of fake libraries while iterating over it * BUG: iterate over copy of list * TST: add build test for build_ext fix (#1) * TST: add build test for build_ext fix * TST: clearer test name * STY: use triple quotes instead of lists of strings * FIX: check for f77 compiler before test is run * DOC: add comment explaining that a list copy is necessary
seiko2plus
pushed a commit
that referenced
this pull request
May 19, 2021
update from main - fixing SVD
ganesh-k13
pushed a commit
that referenced
this pull request
Apr 10, 2024
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.
No description provided.