David Widmann

I noticed this a while ago: https://github.com/JuliaGaussianProcesses/KernelFunctions.jl/pull/240

In the latest release, https://github.com/JuliaGaussianProcesses/KernelFunctions.jl/issues/284#issuecomment-833445916 is addressed (formula is correct and `GaborKernel` is deprecated in favour of `gaborkernel`). It is unclear though if these fixes all test issues. At least...

Taking one step back, what is the main motivation for a `DomainKernel`, regardless of the (dis)advantages of both approaches? I think it is quite nice that currently one does not...

> I'm really not sure that it would -- I think it would lead us to having to specify really complicated domains if the user is using a really complicated...

I still think a natural and simple initial step would be to specify domains separate from kernels as additional arguments if needed (e.g. for RFFs). This would be completely non-breaking...

Maybe we could mark the PR with a (new) label "pending clear need" for now? :slightly_smiling_face:

Yes, this is (or was, it might be a bit outdated now) solved by https://github.com/JuliaGaussianProcesses/KernelFunctions.jl/pull/244. However, IIRC there was no agreement on the more verbose output for nested kernels so...

My alternative suggestion above was ```julia julia> LinearKernel() + (4.0 * SqExponentialKernel() * transform(LinearKernel(; c = 2.0), 3.0)) Sum of 2 kernels: Linear Kernel (c = 0.0) (4.0 * Squared...

Maybe we should revive the PR in its initial (?) state @theogf? It seems now that we retired transform the initial proposal would actually correspond to the preferred way to...

IMO at least we should respect the convention that `print(io, x)` only prints a compact single-line representation and `print(io, ::MIME"text/plain", x)` displays a more detailed multiline representation, as e.g. when...