-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Handle RVs assigned to steps #4701
Handle RVs assigned to steps #4701
Conversation
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.
Could we perform this check more directly in BlockedStep.__new__
instead? For example, could the exception be raised when pm.BinaryMetropolis([model["x"]])
is called?
I'll check. Sounds more reasonable in principle. Do we want to be permissive (ie call the respective |
We need to be very straightforward about the argument types in our step methods, because we're going to convert those step methods to Aesara—or at least Numba/Cython—next, and those kinds of niceties don't translate well. |
We also need to remember that PyMC3 is primarily a library that makes probabilistic modeling accessible to a lot of people who don't know what the difference between |
Should we try to separate a bit more the initialization logic from the actual stepping algorithms then? I imagine that as long as we make sure the inputs to the actual step methods are valid (and are what users would expect) it doesn't matter how we "got them". We are currently very lenient in how we accept starting point dictionaries as well (eg auto transforming the points) |
It think that'd be a good call. Could be a very thin function layer too, and maybe we'll even need it because of sampler stats? But let's take one step at a time. First we need to get
Issue #4689 comes to mind. |
My statement was neither prescriptive nor did it preclude the "accessibility" changes implied here; it was a general guideline for making changes to this area of the code. Right now, we only need to make sure that the early
If we end up keeping the same First, we need to take a look over everything and find out whether or not we can simply take random variables as No matter what, we want the codebase to be as uniform as possible (i.e. always pass one type or the other). There's less room for confusion that way.
This definitely needs to be fixed. |
Thanks for the input. I'll take some time and come back with a worked suggestion. |
This PR looks stale, but is included in the |
I'll come back to it. But we can move it to 4.0.1 if there is an intent to release anytime soon |
588c8c4
to
695cf9e
Compare
Codecov Report
@@ Coverage Diff @@
## main #4701 +/- ##
==========================================
+ Coverage 76.34% 77.24% +0.90%
==========================================
Files 86 85 -1
Lines 13931 14004 +73
==========================================
+ Hits 10636 10818 +182
+ Misses 3295 3186 -109
|
695cf9e
to
1b2afa0
Compare
cc08cf1
to
096a6d3
Compare
096a6d3
to
2f902a5
Compare
Following some work in #4698 I realized some steppers (
BinaryMetropolis
andBinaryGibbsMetropolis
) would silently ignore if a modelrv_var
was assigned manually to them, instead of the correctvalue_var
. I added a check inassign_step_methods
which is called insample
that raises an error when any of the manually assigned variables is not found inmodel.value_vars
.It would probably be better if the steppers themselves raised an informative error (or gracefully converted the
rv_var
tovalue_var
, as some already do more or less incidentally), but the new check still seems reasonable in the long-term.Here is a non-comprehensive list of problematic ways the steppers currently deal with receiving
rv_vars
instead ofvalue_vars
:NUTS
andHamiltonianMC
update the vars argument inplace here: https://github.com/pymc-devs/pymc3/blob/54c39bbfdb5d58a0f97cedf7fd51097fce567141/pymc3/model.py#L690-L692Slice
returns an empty list (and so wouldn't trigger the new check!)Metropolis
raises a cryptic error:BinaryMetropolis
andBinaryGibbsMetropolis
will happily incorporate therv_vars
(which triggers the new check)