Remove size from distribution API

[ricardoV94]

This was brought up in the last meeting, the question is whether there's any benefit in introducing size as a new parameter to our distributions. Size is simply shape[:-ndim_supp] so it's pretty easy for us to convert a user provided shape to size which Aesara RandomVariables use and will keep using internally.

We should decide this before we release V4. For some context on the distinction see this WIP PR #5746

For a more involved example where we are converting from shape/dims/observed to size, take a look at these PRs #5743 and #5690

[twiecki]

Big agreement, users know shape already so why add a subtly new thing.

[canyon289]

Agree hiding size would help make things much more sane, especially because as examples proliferate if we have size and shape some people will use size, others will use shape, and with a split API itll cause recurring confusion. Very similar to how matplotlib as both ax.plot and plt.plot and every beginner gets confused every time

[fonnesbeck]

This is a smart decision. Size can be left available for advanced users as an attribute, but no need to have it in the public API.

[ricardoV94]

Anyone wants to open a PR to this effect?

[canyon289]

This is a smart decision. Size can be left available for advanced users as an attribute, but no need to have it in the public API.

Great idea, share with power users that its possible in a subtle way without confusing everyone else

[danhphan]

Hi, I am happy to work on this task.

[canyon289]

Hi, I am happy to work on this task.

Thanks! Its yours for the taking

[lucianopaz]

I wouldn't like us to hide size. It's new, but it's also better. We should transition away from shape altogether. For univariate distributions, shape and size are equivalent, but for multivariate distributions they aren't, and the shape is far worse.

shape forces users to always insert the implied support shape of multivariate distributions (which was a bad UX in pymc3 and now that we can, we should stir away from it). Besides that, the shape value of the multivariate distribution's support is completely ignored in favor of the implied support shape:

>>> pm.draw(pm.MvNormal.dist(mu=np.zeros(5), cov=np.eye(5), shape=(3,))).shape
(5,)
>>> pm.draw(pm.MvNormal.dist(mu=np.zeros(1), cov=np.eye(1), shape=(3,))).shape
(1,)
>>> pm.draw(pm.Multinomial.dist(n=5, p=[0.1, 0.3, 0.6], shape=(5, 100))).shape
(5, 3)

Furthermore, if you want to mimic the behavior of size using an Ellipsis, you can't if there are implied batch dimensions:

>>> pm.draw(pm.MvNormal.dist(mu=np.zeros((5, 1)), cov=[[1.]], shape=(3, 2, ...))).shape
(3, 2, 5, 1)

size is better because it lets the users be explicit on what they can change of a random variable: they can create batches, but they can't alter the support which are implied.

The only weird scenario is with time series distributions where the support can't be inferred from the distribution parameters, and needs to be specified using shape.

[twiecki]

@lucianopaz You raise good points. If size is indeed better/more consistent than shape, now would be the time to transition users over.

[ricardoV94]

Also worth considering that we can add SpecifyShape to assert the support dimension size:

import aesara.tensor as at
import pymc as pm

x = pm.MvNormal.dist(mu=np.zeros(3), cov=np.eye(3), shape=(5,))
x = at.specify_shape(x, (5,))
pm.draw(x)  # AssertionError: SpecifyShape: dim 0 of input has shape 3, expected 5.

These asserts would most likely be constant folded during graph compilation so they won't pose any burden. The downside of this is that the outputs would no longer be pure RandomVariables, which complicates matters in factory distributions, like Mixture, RandomWalk or LKJCholeskyCov, which currently require pure RandomVariables as inputs.

Hopefully we will one day overcome this limitation (not only related to SpecifyShape, but also other cases like indexing, transposing, or doing transformations, the sort of thing that Aeppl focuses on), but it's an immediate downside if we were to add SpecifyShapes now.

[fonnesbeck]

There are arguments to be made for either continuing with shape for now or converting to size. What I would not want to see is continuing with both. With a major release, we should either continue with shape if it is not causing a plethora of problems, or rip the BandAid off and start using size. It would be nice to avoid muddying the waters with shape/size/dim uncertainty.