-
Notifications
You must be signed in to change notification settings - Fork 13
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
Mapping of pyttb ttb functionality #291
Mapping of pyttb ttb functionality #291
Conversation
…nstruction-of-a-tucker-tensor.
…b and pyttb documentation, 2. add algorithms.
This PR fails regression tests, but only documentation was updated (no source code). |
It looks like there was a breaking change in ruff. Could try |
My pre-commit failed to update ruff due to proxy issues and missed this error. I'm not sure how to resolve these extra args calls in |
This is a general configuration issue. Unrelated to your change like you mentioned. It looks like pre-commit requires (or I just set it up this way), a pinned version of ruff here that hasn't conflicted with latest ruff until now. The simplest unblocking solution is probably to update our package ruff requirement here to match exactly. This will require rolling back your latest commit and downgrading ruff locally. That pinned version is why pre-commit passed last time but the pytest failed (I assumed it was just caching but clearing the cache wasn't successful). Then can file a ticket to handle this cleaner. Ideally linking the two configs and not pinning to an EXACT ruff version. |
If that doesn't work I can debug it after business hours today on a separate branch. |
@ntjohnson1 It sounds like I should wait for the pre-commit yaml and/or pyproject to be updated to unblock? |
…om/jeremy-myers/pyttb into mapping-of-pyttb-ttb-functionality
@ntjohnson1 It looks like this fix is now failing with |
Boo. I assume so since it looks like we have it pinned here Line 8 in 5751f02
|
@@ -36,7 +36,7 @@ dev = [ | |||
"nbstripout", | |||
"pytest", | |||
"pytest-cov", | |||
"ruff", | |||
"ruff==0.0.284", |
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.
You updated the pre-commit config but left this pinned. So we still have the issue of incompatible pre-commit and project. My suggestion is to be more explicit in our pyproject so the alignment is guaranteed then figure out an easier way to keep them aligned in the future as a follow up
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.
I think I have it. I pinned ruff but pre-commit autoupdate gave a conflicting version. So, pre-commit autoupdate --repo https://github.com/psf/black
to update black only should do the trick.
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.
The tests pass now but we still have the possibility of this pre-commit/black mismatch occurring again. Can you pin the version of black in this file to match the one in the pre-commit. We can figure out if there is an automated way to align these as follow up. In my opinion it would be nicer to keep the version of black that was originally in in the pre-commit and just pin it here then roll back the changes from the newer version of black. That way the content changes and formatting churned aren't coupled together.
…om/jeremy-myers/pyttb into mapping-of-pyttb-ttb-functionality
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.
Will leave for Danny to give the official approval and merge it in. Thanks for putting this together.
A few notes:
- My preference for all the formatting headache would be to pin black in pyproject to the previous version that is on main, rollback the changes in *.ipynb and *.py.
- As I mentioned in the tenmat doc some of these things may go stale and there isn't currently a way to check if the pyttb side is broken. Could you file a follow up ticket to add some sort of automated checking for this content? Either using Jupyter notebooks and the rendering we already have or sphinx supports doctest, but I don't think we have an example of that in the repo yet. Wouldn't need to verify outputs but just a smoke test basically to make sure the methods/functions actually exist.
@@ -36,7 +36,7 @@ dev = [ | |||
"nbstripout", | |||
"pytest", | |||
"pytest-cov", | |||
"ruff", | |||
"ruff==0.0.284", |
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.
The tests pass now but we still have the possibility of this pre-commit/black mismatch occurring again. Can you pin the version of black in this file to match the one in the pre-commit. We can figure out if there is an automated way to align these as follow up. In my opinion it would be nicer to keep the version of black that was originally in in the pre-commit and just pin it here then roll back the changes from the newer version of black. That way the content changes and formatting churned aren't coupled together.
+=================+======================+========================================================================+ | ||
| ``and`` | ``logical_and`` | ``X.logical_and(Y)`` | | ||
+-----------------+----------------------+------------------------------------------------------------------------+ | ||
| ``disp`` | ``__str__`` | ``X`` | |
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.
Hmm, for all the names pyttb names
that include dunder methods I wonder if it makes sense to use their public equivalents. Technically they are all hidden methods that get exposed via some other hook. For example __str__
and __repr__
both get called under the hood for str(X)
and repr(X)
. For someone totally unaware of python just trying to directly translate from matlab based on this doc I'd really hope they don't end up with a bunch of __str__
, __rmul__
calls in their code
| ``xor`` | ``logical_xor`` | ``X.logical_xor(Y)`` | | ||
+-----------------+----------------------+------------------------------------------------------------------------+ | ||
|
||
Copying |
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.
It might be useful to note this is fairly common for non-builtin types in python and include a link. Hereish? https://docs.python.org/3/library/copy.html
@@ -0,0 +1,8 @@ | |||
``symktensor`` |
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.
IMO I think it might be clearer to just remove the placeholders. I'm not sure what the plan is for actually covering these other classes.
@@ -0,0 +1,22 @@ | |||
``tenmat`` |
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.
I have a PR up now that updates the tenmat constructors. I believe this is correct currently but once Danny merges my PR this will go stale.
====================== | ||
|
||
Already familiar with MATLAB Tensor Toolbox? To assist transitions from the | ||
Tensor Toolbox for MATLAB to pyttb, this guide documents some key differences. |
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.
It might be good to mention that the tutorials are similar to the MATLAB ones if they want a hands on approach. I think that's already implied but might not be a bad idea to be explicit.
Addresses #180
Summary: this PR came from a desire to ease the transition for MATLAB TTB users to pyttb. The main goal of mapping TTB and pyttb functionality is to document where naming conventions, method and data member usages, etc. differ between implementations.
📚 Documentation preview 📚: https://pyttb--291.org.readthedocs.build/en/291/