-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Integration of aeppl
with PyMC
#4887
Conversation
I would guess the "Mixture" distribution in PyMC3 would only have to be concerned with returnig the right random graph, from which the logprob can be derived with the I am not sure how feasible it would be to plug the |
One thing we can do over here is : Registering the |
Codecov Report
@@ Coverage Diff @@
## main #4887 +/- ##
==========================================
+ Coverage 75.31% 76.46% +1.15%
==========================================
Files 87 87
Lines 14106 14027 -79
==========================================
+ Hits 10624 10726 +102
+ Misses 3482 3301 -181
|
bf606eb
to
5024154
Compare
aeppl
with PyMC
1c79a25
to
f9e7d55
Compare
3949c80
to
f452a50
Compare
I think we can push this to a future PR, as |
Note that most of the test failures in Ubuntu's There's already an issue for that: aesara-devs/aesara#616 The only concerning thing that remains is |
@kc611 now that aesara-devs/aesara#616 is fixed, is this done? Maybe we mark that slice test with xfail and move on? |
Yeah sure. |
Looks like one of the subclass's tests of Edit: Got around it by temporarily failing the test for that particular class, the failure can be removed once the entire test is fixed. A bit crude method butsince the logic is actually passing on other systems such as float64 linux and windows systems any logical errors arising from other changes/other PRs will be caught there so I don't see any issues with failing it like this temporarily for a specific subsystem. Any other solutions are also welcome. |
@kc611 Tests are passing 🥳 can we merge? |
@@ -83,6 +84,18 @@ def perform(self, node, inputs, outputs): | |||
raise NotImplementedError() | |||
|
|||
|
|||
@jax_funcify.register(Assert) | |||
def jax_funcify_Assert(op, **kwargs): |
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.
Not a blocker, but shouldn't this go into Aesara?
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.
That is supposed to be just a temporary pass-through for Assert
Op since Jax doesn't allow asserts in it's code. Though you're right we should be adding this functionality (maybe with a good workaround) in Aesara, I'll open an issue for this.
5ec3e0b
to
3b828a7
Compare
Pushed a test that works and rebased from main. Apologies if I messed up anything @kc611! |
…nsforms Co-authored-by: Ricardo Vieira <[email protected]>
@@ -4,6 +4,7 @@ channels: | |||
- conda-forge | |||
- defaults | |||
dependencies: | |||
- aeppl>=0.0.13 |
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.
Disclaimer: I skimmed the discussion and have not reviewed the code
What does this dependency mean for the users? Will using aeppl functions/methods be necessary? Or will it be handled under the hood and advanced users will be able to use it if they want?
This is a minor-medium concern for the beta release, but aeppl seems to be very little documented. I was unable to find the link to it's docs anywhere. I also did check and saw there was a gh-pages
branch so I went to https://aesara-devs.github.io/aeppl/ which has some api docs. We need to work on aeppl docs if we expect pymc users to work with it directly before releasing stable 4.0
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.
Users don't need to know about aeppl, it will be used by us developers to create more complex distributions.
Indeed we need documentation building on aeppl, we have a PR opened for that, but we welcome help. All our methods and functions are quite well documented on the other hand
Can we merge? |
Pulled the trigger, 🤞 Great work @kc611 |
This PR refactors PyMC's
_logp
framework to be able to useaeppl
'sjoint_logprob
framework.The changes this PR aims to make:
_logprob
instead of_logp
so thatjoint_logprob
can use them internally.log-cdf
logic handling fromlogp
logic (currently both are being handled in the samelogpt
function)logp
from Distribution classes (since_logprob
registration present inaeppl, for e.g.
NormalRV`)factorized_joint_logprob
insidelogpt
function. and then return the appropriate RVs (sincejoint_logprob
tends to return all of the RV'slogp
present in the graph)pymc
's transforms toaeppl
's transforms.transforms.py
and remove transforms already present inaeppl
aeppl
's.joint_logprob
correctlytest_transforms.py
test_transforms.py
test failures.test_logprob
failures.