[WIP] Porting kroneckernormal distribution to v4

[kc611]

This PR refactors the KroneckerNormal distribution to be compatible with v4.

[kc611]

I don't know how practical it is to use an eval() in a dist. But this is one way to get the output's of the cholesky matrices from the Op.

[brandonwillard]

Yeah, we almost never want to use eval/aesara.function outside of a place where it's intended to be used (e.g. posterior predictive sampling).

Regardless, why would we want/need to use non-symbolic values here?

[kc611]

The exact place this comment tags right now i.e. dist is eval() free. The .eval() is currently required over in rng_fn since the kronecker() method was returning TensorVariable (I'm working on replacing that with scipy.linalg.kron so we can count on eval() being removed from there too) The other place .eval() is in is logp where it is used to infer shapes (Theoretically that can also be removed with a bit of effort.)

Overall with the current implementation (which is a whole lot of omitted code) I wouldn't worry about eval() as much as the inability of supporting sigma which us the bigger issue with this implementation.

[brandonwillard]

We simply cannot evaluate things like this unless we place very strong and unnatural restrictions on all of the terms involved. More specifically, the graphs in chols must have no symbolic inputs; otherwise, this will fail. If the tests are passing with this in place, then our testing isn't sufficient, because it's only ever testing Constant/SharedVariable inputs.

[kc611]

@ricardoV94 The current failure is the test from #4488 which is something that you worked upon. The difference between the values is nearly negligible, though you might wanna have a look at it again if it's something that needs to be very precise.

[ricardoV94]

@ricardoV94 The current failure is the test from #4488 which is something that you worked upon. The difference between the values is nearly negligible, though you might wanna have a look at it again if it's something that needs to be very precise.

Maybe try to increase the tolerance to 1e-4

[brandonwillard]

Yeah, we almost never want to use eval/aesara.function outside of a place where it's intended to be used (e.g. posterior predictive sampling).

Regardless, why would we want/need to use non-symbolic values here?

[ricardoV94]

Look great, I added just a tiny suggestion

[brandonwillard]

We simply cannot evaluate things like this unless we place very strong and unnatural restrictions on all of the terms involved. More specifically, the graphs in chols must have no symbolic inputs; otherwise, this will fail. If the tests are passing with this in place, then our testing isn't sufficient, because it's only ever testing Constant/SharedVariable inputs.

Meant to comment

[ricardoV94]

Look great, although I am not familiar with the distribution so I will have to trust the tests on this one. I left a couple of minor suggestions.

[ricardoV94]

Checking if the tests pass one last time before merging.

Great work @kc611!