Open szvsw opened 2 days ago
]
:tada: Welcome to PyMC! :tada: We're really excited to have your input into the project! :sparkling_heart:
If you haven't done so already, please make sure you check out our Contributing Guidelines and Code of Conduct.
CC @lucianopaz does this make sense?
I would also have expected that this already throws an error.
We have a check when the variable has the same name as one of the dims, but bot another variable?
I haven't double checked all cases:
But as a user I think they should probably all fail when a new declaration would obscure another.
Describe the issue:
When using
coords
in conjunction withData
some unexpected behavior can happen if one of the data containers is given the same name as one of the existing coords dimensions. The symptom I was diagnosing was pretty difficult to identify: when sampling posterior predictive checks, some variables in the middle of the model that used one of the coord dimensions in theirdims
were getting sampled for seemingly opaque reasons compared to identically constructed models in a separate notebook. Eventually realized that it was because of the conflicting namespacing, which I think led to the model thinking there was a shared dependency and unknown data leading to using the priors in the ppc. All would have been avoided if there was a simple warning when yourData
container conflicts with a coord dim.In the example below, changing the data container name to anything other than “group” is sufficient to return to normal behavior.
Reproduceable code example:
Error message:
No response
PyMC version information:
5.18.2
Context for the issue:
It’s a footgun. It’s natural to want to use the same name for the dimension in coords and for the data that stores the assigned values, especially when you are dynamically constructing your model (eg from data frames which may have an unknown number of columns).
a simple warning (or hard error) which is thrown when this conflict occurs would be much appreciated.