Coerce all rng_fn outputs in distributions using np.asarray

[canyon289]

Description of your problem

All rng_function on ops should return numpy array

See examples here
https://github.com/pymc-devs/pymc/blob/main/pymc/distributions/continuous.py#L909
https://github.com/pymc-devs/pymc/blob/main/pymc/distributions/continuous.py#L909

All rng_fn in the various distributions directory modules should updated
https://github.com/pymc-devs/pymc/tree/main/pymc/distributions

• Bound
• Censored
• Continuous
• Discrete
• Mixture
• Multivariate

These two additionally were missed in continuous distributions
https://github.com/pymc-devs/pymc/blob/update_dist_parameter_types/pymc/distributions/continuous.py#L594
https://github.com/pymc-devs/pymc/blob/main/pymc/distributions/continuous.py#L909

[ricardoV94]

Are we sure the extra call is needed?

[canyon289]

Its a continuation of this PR, is the extra call not needed? If so we can open up an issue to remove them!
#5296

[ricardoV94]

Its a continuation of this PR, is the extra call not needed? If so we can open up an issue to remove them!
#5296

I don't think it is needed. Was any code failing? Most of those methods are working with numpy and scipy random methods which will return valid outputs by default. I don't see any extra asarray calls in Aesara either: https://github.com/aesara-devs/aesara/blob/main/aesara/tensor/random/basic.py

[canyon289]

I dont think we have mypy type checking on yet so nothing failing in CI. Im not tied to keeping them in there, was just following a suggestion :D

@michaelosthege Any objections if np.asarray coercions from this pr are removed? 5296

[michaelosthege]

For scalar RVs most scipy or numpy distributions return scalars instead of arrays.

type(scipy.stats.t.rvs(df=1)) # >>> numpy.float64
type(numpy.random.uniform()) # >>> float

I don't have a preference, but without the np.asarray a np.ndarray type hint is just not correct.

[canyon289]

Oof thats a good point, thank you. Type hints are nice since it makes the code statically readable but of course they have to be correct.

@ricardoV94 what are your thoughts on the type hints, not for code execution, but for readability and understandability?

[ricardoV94]

It sounds like the type hints have to be updated then, not the code?

[michaelosthege]

That's an option, but the type hint that needs to be changed then is in the base class RandomVariable. (IIRC I looked that up a few days ago and it was just ndarray)

[canyon289]

That's an option, but the type hint that needs to be changed then is in the base class RandomVariable. (IIRC I looked that up a few days ago and it was just ndarray)

This ndarray class reference here is the one that needs to be changed? If so to what?

https://github.com/aesara-devs/aesara/blob/main/aesara/tensor/random/op.py#L385

[michaelosthege]

That's an option, but the type hint that needs to be changed then is in the base class RandomVariable. (IIRC I looked that up a few days ago and it was just ndarray)

This ndarray class reference here is the one that needs to be changed? If so to what?

https://github.com/aesara-devs/aesara/blob/main/aesara/tensor/random/op.py#L385

Sorry, looks like I misremembered. It would be https://github.com/aesara-devs/aesara/blob/main/aesara/tensor/random/op.py#L160 but there's no type hint there.
The hints would be something along the lines of Union[int, float, ndarray] in the base class and Union[float, ndarray] or Union[int, ndarray].
It looks like a np.asarray call could be added in the base class, similar to the lines you linked(?).

But I don't have strong opinions or good oversight about the (dis)advantages of the additional call vs. Union hints.