Mathieu Besançon

Yes using the right abstractions could let us avoid depending on anything heavy. Lots of PRs lately have been abound correct parametrization of types to increase interop. Maybe we could...

Agreed, couldn't `AbstracPDMats` be defined in a separate package from the implementation? Or even better, moved to `LinearAlgebra` (not sure how possible this would be). Removing a heavy and not...

to dispatch on `covar_mat=...` vs `factorization = ...`?

@devmotion fixed the conflict here, what's the status?

the argument for NaN outside of the support makes sense yes

yeah there are still a lot of F64 hardcoded sprinkled in the package :/

``` │ %34 = Base.getproperty(∂d_sq::Tangent{FullNormal}, :μ)::Any │ %35 = (0.5 * %34)::Any │ %36 = (%33 - %35)::Any │ %37 = Base.getproperty(∂d_c0, :Σ)::Matrix{Float64} │ %38 = Base.getproperty(∂d_sq::Tangent{FullNormal}, :Σ)::Any ``` One...

Alright I could fix inference but it took some assumptions which might be a bit restrictive

@devmotion I think everything discussed has been adapted/validated

not computing the inverse at all would be a bit of a hassle here since it's reused several times in the whole function. I removed the materialization of the inverse...