iskroncompatible

[willtebbutt]

1. iskroncompatible appears to be incorrectly implemented in a couple of places. For example, I don't believe that an ExponentialKernel should not be marked as compatible, or have I misunderstood something?
2. Do we really want to try and do this with a flag method? Would be not be better off introducing a RectilinearGrid input type (that is a subtype of AbstractVector) and then using dispatch to figure out whether it's correct to return a KroneckerMatrix when kernelmatrix is called?

[theogf]

Back to this :

• 1. Yep that's a mistake, I will take care of it
• 2. How would you figure out automatically the factorization of the kernel? Also wouldn't that lead to type instability?

[willtebbutt]

I wouldn't imagine that you would need to introduce a type instability. One would just implement specialised kernelmatrix functions for kernels that are separable when they receive a RectilinearGrid, that spit out Kronecker matrices (e.g. from Kronecker.jl). Everything else in the pipeline would just specialise on that.

Am I missing something?

e.g.

kernelmatrix(k::SqExponentialKernel, x::RectilinearGrid) = Kronecker(...)

and all of the other SqExponentialKernel methods would remain unchanged.

[theogf]

Coming back to this issue:

• I think the RectilinearGrid solution would be too restrictive (I don't think a uniform grid is needed to compute a Kronecker matrix?). I don't see a problem having it, but I think dispatching separately for every kernel able to do it is too much unnecessary work.
• The other solution would be to rely on traits, but that would be doing the exact same thing no?

Additional point we can also define the TensorProduct as "kroncompatible"

[willtebbutt]

I think the RectilinearGrid solution would be too restrictive (I don't think a uniform grid is needed to compute a Kronecker matrix?). I don't see a problem having it, but I think dispatching separately for every kernel able to do it is too much unnecessary work.

It's just unclear to me what other contexts Kronecker product structure arises in. You need to have some kind of cartesian-product-like structure, and a rectilinear grid is the most general manifestation of that in Euclidean space, if I'm not mistaken. Maybe CartesianProductVector would be a better name?

[devmotion]

More structured output, such as Toeplitz or circulant matrices, would be useful also when working with Gaussian random fields.

[theogf]

Yes! It's even in the README! :laughing:

[devmotion]

For Toeplitz matrices, it would be good to fix https://github.com/JuliaMatrices/ToeplitzMatrices.jl/issues/36 :grimacing:

Edit: I opened a PR: https://github.com/JuliaMatrices/ToeplitzMatrices.jl/pull/60