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.
Strategy
We implement xarray-like dummy Ops that respect / propagate dims semantics, and lower them to regular PyTensor graphs with rewrites.
Note in the example above the dummy TensorFromXtensor and XTensorFromTensor remain in the final graph. If we had created a function with Tensor inputs and outputs that are only then converted (symbolically) to and from xtensor, respectively, the final graph would have no signs of dimension operations, other than how it was constructed.
I suggest registering those rewrites in an
xtensor_lowering
database.Coordinates
For now I'm playing with how far we can get without coordinates. This means the graphs produced by an xarray-like syntax are much more amenable to the numpy-like backend of PyTensor. Otherwise it involves a lot of Pandas-like stuff (e.g., Multiindex) that we don't really have. It may be feasible, specially if nothing is symbolic, but... I fear a rabbit hole of edge cases)
Gradients
These ops are currently not differentiable, but one can lower the graph and then call the gradient. I do want to try the lazy grad approach from #788
Help implementing more Ops so we have MVP to try out with PyMC next. We need some Ops
Open a PR on top of this branch, I'll try to merge quickly! Try to make it clean (one commit per Op, unless it's like a factory of related Ops)
Implementing means:
3.1 The rewrites "box" the lower tensor operations between
TensorFromXTensor
andXTensorFromTensor
calls, so that the replacements are valid in terms of types. There are rewrites to remove chains of useless TensorFromXTensor/XTensorFromTensor that should clean up everything in the middle of the graph.Interplay between XTensorTypes and TensorTypes / weakly typed inputs
__add__
and the like so you can do x + x)Meta Ops
Math stuff
Shape stuff
overloading the name to avoid confusion) (@OriolAbril working on it in first pass at unstack #1412 )
Array creation stuff
Indexing stuff
__getitem__
+ isel with non XTensor indices (in progress, missing tests and lowering)__getitem__
+ isel with XTensor indices (can be multi-dimensional, not sure the rules of xarray).It probably makes sense to convert the non-XTensor indices to XTensor indices if they can be rendered equivalent, to reduce logic needed.
RandomVariables
This is quite important, as we'll need those for PyMC models! They are a mix of blockwise + size argument (which can or not be redundant)
📚 Documentation preview 📚: https://pytensor--1411.org.readthedocs.build/en/1411/