-
-
Notifications
You must be signed in to change notification settings - Fork 123
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
Use bayeux
to access a wide range of samplers
#775
Conversation
Really cool! A few suggestions --
|
What kind of API bayex has? Could we enable support for external samplers if we define specific API we support (need)? (Users could create class for external samplers if needed?) Of course that does not mean we could not have a text based support on certain libraries? |
|
Thanks for the suggestions! That makes sense. I am liking the second option, but I will run some ideas past the others first before asking for the feature. Thanks! |
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
In this example, the error is because bayeux is appending For example: print(bayeux_idata.posterior.dims, pymc_idata.posterior.dims)
|
Update: I have added logic in the cleaning of idata to: (1) identify bayeux idata and to remove the trailing numeric suffix from the _dims, and (2) to rename the posterior dims to be consistent with the PyMC model coords. Although this works for simple models, I haven't tried this logic with more complex models in Bambi such as HSGP or with models that have a large number of dims and or factors. Since the idata contains very "important data", I also think it could be worthwhile to not clean idata when the user calls samplers from bayeux at the moment in order to avoid unknown effects appearing in the inference data. |
Would it be possible to allow access to the optimization methods from
Bayeux as well via Bambi?
…On Sat, Feb 10, 2024 at 4:25 AM Gabriel Stechschulte < ***@***.***> wrote:
In this example, the error is because bayeux is appending _0 to
party_id_dim of the posterior dims. This results in Bambi discarding
<https://github.com/GStechschulte/bambi/blob/9f1d9d179071abbb4cc6255242132829aae80faf/bambi/backend/pymc.py#L261C4-L261C86>
all posterior dims because the dims in the PyMC model are inconsistent with
the dims of the InferenceData returned by bayeux.
For example:
print(bayeux_idata.posterior.dims, pymc_idata.posterior.dims)
(FrozenMappingWarningOnValuesAccess({'chain': 8, 'draw': 500, 'party_id_dim_0': 2, 'party_id:age_dim_0': 3}),
FrozenMappingWarningOnValuesAccess({'chain': 4, 'draw': 1000, 'party_id_dim': 2, 'party_id:age_dim': 3}))
Update: I have added logic in the cleaning of idata to: (1) identify
bayeux idata and to remove the trailing numeric suffix from the _dims, and
(2) to rename the posterior dims to be consistent with the PyMC model
coords.
—
Reply to this email directly, view it on GitHub
<#775 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH3QQV3RMDQKAJ34J6FVNWLYS44HDAVCNFSM6AAAAABCY5BXBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWHE2TCMJUHA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I think you could -- @GStechschulte has a good outline here. If @tomicapretto thinks this is a reasonable idea in principle, I'd be happy to either collaborate on this to (programatically) get the |
I think this is really cool, thanks @GStechschulte and thanks @ColCarroll for Another thing, I see we're replacing |
bayeux will pull those in, but i agree it is better to be explicit and require dependencies (in case bayeux makes weird decisions). I'll double check on the naming conventions! |
Oh right, yes: |
Thanks for the answer, it makes much more sense now! |
@ColCarroll thanks for the information. @tomicapretto I can apply this post processing step on Bambi's side. |
Sounds great, just let me know if you need help or a second opinion :) |
Two updates:
Regarding
@ColCarroll I'd be happy to collaborate and see how you would do this 👍🏼 |
@ColCarroll thanks a lot for the review! I will incorporate these in the coming days. |
Ugh. pylint is making the CI fail. It says it cannot import bayeux. However, when I check the logs of the step "Install Bambi and all its dependencies", I can see that bayeux was installed. |
the package is named |
Oh. Last failures are because
Any preferences? |
I'm in favor of following NumPy's deprecation cycle but at the same time I feel it moves faster than many users. For that reason, even when the pipe operator is a feature I really like, I have not been using it because of this (i.e. not working for Python <= 3.9). According to PyPI stats, users are downloading Bambi using Python 3.7, 3.8, and 3.9. I know PyPI stats may not be a crystalline reflection of reality, but it's still useful. I don't want to break their installations. So, we could drop official support for 3.9 as soon as NumPy does (this includes testing with Python >= 3.10 only), but I would not start using Python >= 3.10 specific features in the default installation of Bambi right now. I guess there will be a point where it'll become unavoidable (for example, when PyMC or PyTensor start to do so) and that's fine. What do others think? Edit I think I didn't answer your questions straightforwardly. I would wait, do a PR removing Python 3.9 support, and then merge this. I don't want to ask you to work on a Python 3.9 compatible version that will be disposed in the short future (unless you think it's worth it). |
Thanks @ColCarroll for the information, and I agree with @tomicapretto thoughts. Looking forward to eventually merge this! |
Just want to add that after some comms in our Slack it looks like we won't be breaking users' installations. They'll just get an older version of Bambi if they use Python < 3.10 |
@tomicapretto so do we want to wait the |
sorry for the slow response, we can do it now if you agree on that edit also, it won't impact most users until we make a release, so now i realize it's even less dangerous |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #775 +/- ##
==========================================
+ Coverage 89.86% 90.14% +0.27%
==========================================
Files 46 46
Lines 3810 3836 +26
==========================================
+ Hits 3424 3458 +34
+ Misses 386 378 -8 ☔ View full report in Codecov by Sentry. |
I was giving this a shot and just found that the development version of PyMC now supports Python 3.12 https://github.com/pymc-devs/pymc/blob/61ce412aa599939eaf299a6328059c184e6c25db/setup.py#L33-L36 This is not the case in the latest release 5.11. I think we can just wait a bit until PyMC releases a new version to upgrade the PyMC version requirement in our Another option would be to pin PyMC to the current development version but that will have to be updated as soon as PyMC releases the version suporting Python 5.12 so I think it's just better to wait a bit. https://github.com/pymc-devs/pymc/blob/a06081e1e9649bd56e3528cb96380efdf6bb2dc0/setup.py#L33-L35 |
There's a new version of PyMC supporting Python 3.12... 🤞 |
@GStechschulte I let you have the honor to click the green button :D |
Woooooo! Gracias! 🎉 |
Thanks for all the persistence @GStechschulte! |
I have been following @ColCarroll bayeux library and thought it would be interesting to see how Bambi could incorporate it to offer the users a wide range of samplers (more than
nuts_blackjax
andnuts_numpyro
).Edit: Now I access the samplers programmatically using the
inference_method
arg. This removes previously needed code fornuts_blackjax
andnuts_numpyro
. If a user passes an MCMC inference method other than the PyMC MCMC samplermcmc
, Bambi will use bayeux to call that sampler.However, when cleaning the InferenceData, I am getting an xarray error
It seems xarray is not liking something that bayeux is doing with the InferenceData.
Another thought is that using bayeux with Bambi is so easy
that maybe we just add documentation explaining how to use bayeux with Bambi to avoid overhead from Bambi's side?
To Do:
test_alternative_samplers.py