-
Notifications
You must be signed in to change notification settings - Fork 4
make better split between wrappers and torch implementations #52
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
Conversation
8f1b501
to
89a8d54
Compare
963fb8c
to
e304cc6
Compare
707f4a4
to
f2ff966
Compare
This is no longer WIP, this is large enough. Nothing exciting here, this is pure MAINT PR, which sets the ground for a future work on communications between array_like user API and pytorch implementations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that the implementations are much cleaner, I went on and re-reviewed the implementations of the functions.
Now, this starts to look much better! The implementationos in implementations.py
are much cleaner and easier to understand, and then the ugly and repetitive preprocessing lives in _wrapper.py
.
5ec1278
to
fabf01f
Compare
Co-authored-by: Mario Lezcano Casado <[email protected]>
13e5277
to
6970fd3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff! This is certainly a great step in the right direction.
Thanks Mario for the review. |
Working towards moving actual logic to
_detail
, so that top level modules (currently, _wrappers.py, _ndarray.py) unwrap/normalize their inputs and pass heavy lifting to_detail
. Details of organization of the_detail
submodules are TBD, and so are details of unwrapping/normalization or arguments. This PR is to only to make the split as clean as reasonable.