-
-
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
Reassess MutableData
and coords_mutable
#6972
Comments
+1 to the 2nd idea. It seems like it should be possible to know which coords are mutable/constant based on the model? Consider this model: import pymc as pm
coords = {'a':[0], 'b':[0]}
with pm.Model() as mod:
x = pm.MutableData('x', [3], dims='a')
y = pm.ConstantData('y', [1], dims='b') Just by looking at My point in all this is that the mutable/non-mutable distinction on coords is not one the user should have to engage with. If a container is declared as mutable, the coords should be mutable: either because they all are by default, or because we internally make it so. Declaring a |
I would go one step further and remove the Mutable/Constant data distinction as well |
coords_mutable
to mutable_coords
MutableData
and coords_mutable
My only objection to that is that if someday we allowed users to recycle compiled logp functions in pm.sample, it wouldn't be possible to change the data between runs. This is an oft-requested feature on the Discourse. I also don't think an on-going discussion about removing the Mutable/Constant data distinction should be a blocker to a PR that removes the distinction for coords. |
We can allow advanced users to still compile functions with shared variables, but I don't think that has to map directly to the |
Completely agree with this too -- making coords mutable by default, inferring which ones are not under the hood, and removing the distinction between Mutable and Constant Data. |
We could make all coords mutable by default and replace mutable lengths by constants before doing any operations on a Model object. Same for MutableData. We could have a helper function
freeze_graph
that does that.Note we already do something similar for jax based sampling since shared variables aren't really supported in that backend
The text was updated successfully, but these errors were encountered: