Brandon T. Willard

> The following returns, but the logprob is likely wrong as it does not include `Y_vv`: > > ```python > import aeppl > import aesara.tensor as at > > srng...

Here's the AePPL IR produced in that example: ```python import aesara import aesara.tensor as at srng = at.random.RandomStream() X_rv = srng.normal(name="X") Y_rv = at.exp(X_rv) Z_rv = srng.normal(X_rv, name="Z") from aeppl.rewriting...

> I can give this a shot. Perhaps I can start with working with `Z_rv` and see how the logic generalizes to `B_rv` and `C_rv`? That would be great, thanks!

There's no need to frame the marginalization functionality in terms of the log-probability function interface (e.g. via a keyword option); it's a coupling that doesn't provide anything constructive at the...

> The more we talk about it the more it makes sense to me. This defines a neat hierarchy and clear separation of concerns: > > * Aesara defines the...

> I don't follow why doesn't it have a place in Aeppl? Because it requires a new operator? Yes, that's part of it, as well as the fact that the...

Is this a request to make all transforms return the same precision outputs as their inputs (excluding the inputs' shapes from consideration, of course)? If so, that would seem to...

If we can avoid unnecessary upcasting (e.g. #80), then we'll do that, but forcibly downcasting results is a very problematic and confounding endeavor. As a rule, I'm inclined to say...

> numpy is not a great guide here though, because they use Python integers for shapes. > > This expression returns a float32 array (until x.shape ~ 2**16) Unfortunately, we...

> I wonder if we might need a dispatch system to resize non-pure RandomVariables like those created via OpFromGraph. Or something that would be able to resize `5.0 + at.random.normal()`...