Open ricardoV94 opened 5 months ago
Hi there @ricardoV94, I'm attending the hackathon at Pydata London.
I'd like to work on Softmax.
Hi there @ricardoV94, I'm attending the hackathon at Pydata London.
I'd like to work on Softmax.
Sure!
Thanks @ricardoV94
I have been doing some reading around the docs, I noticed that #764 has the initial setup. I believe that contains ground work for adding other Ops, so I'd be following the PR and the Softmax Ops will likely use some code from it.
Am I thinking about this the right way?
@HAKSOAT yes, you should be able to start a branch already from #764. All the functionality is done, except some tests are failing because they depend non-optionally on GPU. We should make that optional and get it merged soon enough, but you need not wait :)
Hello @ricardoV94, I would like to work on Reshape
Go ahead. We'll link and lock the Op when you open a PR
Hi @ricardoV94, I have opened a PR for the Softmax Ops. I see it has been grouped with LogSoftmax and Grads, so I can update the PR to include them.
Hi @ricardoV94, I will work on the Dot
Op
now.
If someone wants to look through the codebase and populate the list of Ops above that would also be very helpful :)
If someone wants to look through the codebase and populate the list of Ops above that would also be very helpful :)
@ricardoV94 Does something like this work? There are correponding torch function/method attached each op.
I could help with the remaining Tensor creation ops
to begin with. Let me know.
Thanks @twaclaw, feel free to open a PR
I will have a look at Repeat
, Unique
, etc. during the weekend.
@ricardoV94, regarding Unique
:
return_index=True
or rather throw NotImplementedError
? (torch.unique
doesn't feature that param)axis
param required? Your current JAX
Op implementation doesn't support a non None
axis
@twaclaw in general we want to support exactly the same functionality from the original Op. When that is not possible or too complicated raising NotImplementedError
is fine.
Regarding JAX, we probably cannot compile (JIT) any function that has unique in it because JAX can't handle dynamic shapes. So it's a bit moot whether we say we support axis or not, although the NotImplementedError could be removed and we could just dispatch to jax.numpy.unique
rather straightforward. Feel free to open a PR for that if you want.
I'll be working on the indexing Ops now
@twaclaw in general we want to support exactly the same functionality from the original Op. When that is not possible or too complicated raising
NotImplementedError
is fine.Regarding JAX, we probably cannot compile (JIT) any function that has unique in it because JAX can't handle dynamic shapes. So it's a bit moot whether we say we support axis or not, although the NotImplementedError could be removed and we could just dispatch to
jax.numpy.unique
rather straightforward. Feel free to open a PR for that if you want.
@ricardoV94, regarding the JAX implementation of unique
, one possible option would be to make the param size
in jax.numpy.unique
static. Anyhow, I think the current implementation might be broken (i.e., lax_numpy
is undefined).
I can't imagine many cases where I would know the size of the unique elements but not what/where they were? If I knew what/where they are I would just select them instead of using unique.
More importantly we don't have size in our Unique Op and I don't think it makes sense to add it for this edge case. A more general approach will be to be clever about what can and cannot be jitted. I think there's an issue open for that already.
For now we can probably just remove the implementation and let it raise NotImplementedError if as you say it's broken anyway
You are right, unique
is not compatible with JIT.
You don't need to know the exact size but guess it (maybe overestimate it). I was wondering whether it is possible to insert parameters (like a Constant size
) into the Op Graph 🤔.
But I agree a NotImplementedError
would be appropriate.
I can take a look at the linear algebra ops.
Seems like Reshape is become more and more relevant, if anyone wants to tackle it
Seems like Reshape is become more and more relevant, if anyone wants to tackle it
Is someone working on this?
Seems like Reshape is become more and more relevant, if anyone wants to tackle it
Is someone working on this?
Not yet I think. You can go ahead
Is the checklist at the top up to date on what else is needed?
More or less up to date except linalg and indexing is being worked on
If someone is interested we need to check whether we can bridge nicely between PyTensor and Torch random number generator APIs.
We have added a recent documentation page explaining how random variables work in PyTensor: https://github.com/pymc-devs/pytensor/pull/928
As a reminder we're targetting torch compile functionality in case that matters
@ricardoV94 I'll take a stab after i finish some of the operators in #939. I need to build a bit more familiarity with the pytensor code first
Coming from PyMC, adding a sparse solve would be useful I believe...
Coming from PyMC, adding a sparse solve would be useful I believe...
This issue is not very relevant for that request, since we first need it in PyTensor to begin with, before we add it to the PyTorch backend. We haven't done anything with Sparse stuff in the PyTorch backend to begin with
Description
If you want to help implementing some of these Ops just leave a comment below saying which ones you are interested in. We'll give you some time to work on it (and then put it back up to grabs).
See the documentation for How to implement PyTorch Ops and tests: https://pytensor.readthedocs.io/en/latest/extending/creating_a_numba_jax_op.html
Example PR: #836
See https://github.com/pymc-devs/pytensor/issues/821#issuecomment-2202258929 for suggestions on equivalent torch functions
Tensor creation Ops
Shape Ops
Math Ops
Indexing Ops
Branching Ops
Linalg Ops
SparseOps
RandomVariable Ops
If you need an Op that's not in this list, comment below and we'll add it!