You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For univariate Normal with vector valued parameters, the last dimension is broadcasted to match the rest of the dimensions of the given shape. I couldn’t find anywhere in the documentation that explicitly mentioned this and it took me while of playing around to figure out how the shape parameter behaved in this case.
For MvNormal, it seems like the shape parameter doesn’t do anything at all. The following doesn’t raise any error and seemingly ignores the shape parameter, returning an array of shape (10,). This last one seems more like a bug to me.
Also, to be consistent with the behavior in the example with the univariate Normal with vector valued parameters, it seems to make sense to be able to write:
Thanks for the comment, you are right: currently, the shape of RV is one of our recurrent issues and we see a lot of related corner cases. Hopefully it will get address in #2833
The way the shape parameter behaves can be confusing and doesn't seem to be present in the docs.
For univariate Normal with scalar valued parameters, providing the shape parameter creates an array of the specified shape, which is I find intuitive.
For univariate Normal with vector valued parameters, the last dimension is broadcasted to match the rest of the dimensions of the given shape. I couldn’t find anywhere in the documentation that explicitly mentioned this and it took me while of playing around to figure out how the shape parameter behaved in this case.
For MvNormal, it seems like the shape parameter doesn’t do anything at all. The following doesn’t raise any error and seemingly ignores the shape parameter, returning an array of shape (10,). This last one seems more like a bug to me.
Also, to be consistent with the behavior in the example with the univariate Normal with vector valued parameters, it seems to make sense to be able to write:
However, this raises the following error:
I think it would make this library much more user friendly if we explicitly documented these “gotchas”.
The text was updated successfully, but these errors were encountered: