Use return annotation to wrap tensors into ndarrays/sequences of ndarrays #83
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
Base is tracked via `self._tensor._base`. Use `a.get()._base is b.get()` instead of numpy's `a.base is b`.
…nd import from _detail
…eturn a value On failure, @ normalizer without arguments (default) raises, while @Normalizer(return_or_failure=value) return a specified `value`. This is useful, e.g. for @-normalizer def is_scalar(a: ArrayLike): .... Consider is_scalar(int): the argument cannot be converted to tensor, so the function returns False. But the actual failure is in the decorator, so cannot do try-except in the body of the function!
Two cases
- just {tuple, list}[NDArrays] (list is e.g. meshgrid)
- a variadic return of a single NDArray or a list/tuple (where, atleast_{1,2,3}d, unique)
Note that in the latter case the choice of the return type depends purely on
the number of input array_likes.
`_helpers.tuple_arrays_from` is now localized to the normalizer only
Optional arguments to the normalizer decorator turn out to be useful for quantile/percentile, which does non-standard things allowing zero-dim out arrays for size-out outputs etc.
ev-br
force-pushed
the
return_annotation
branch
2 times, most recently
from
2fe8a9a to
35e647b
Compare
This was referenced Mar 15, 2023
ev-br
force-pushed
the
return_annotation
branch
from
35e647b to
bc9bd0c
Compare
lezcano
reviewed
Mar 21, 2023
There was a problem hiding this comment.
Numpy returns either a Tensor, or a list / tuple or Arrays. Now, why do we need the annotations if this information is readily available in the type of result after executing the function? I think we should be able to post process everything simply based on that.
|
|
||
| postprocessors = { | ||
| NDArray: postprocess_ndarray, | ||
| OutArray: postprocess_out, |
There was a problem hiding this comment.
As discussed, I think we should be able to implement the out= keyword generically. Let's catch-up on this today.
ev-br
force-pushed
the
move_to_impl_take_2
branch
2 times, most recently
from
78b64c6 to
5fea60f
Compare
This was referenced Mar 23, 2023
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.
Annotate return values of wrapper functions to trigger generic postprocessing. No annotation mean no postprocessing of scalar returns;
-> NDArraytriggersndarray(tensor)etc. There's again a need for a special annotation for functions which return either an array or a sequence of arrays (atleast_1d,where,unique). Other than that, all looks straightforward.on top of gh-82, so it's the top of the stack based off gh-70.
NB: postprocessing currently invokes functions from
_helpers. Those are straighforward to clean up/inline, once the rest of the "stack" is in.