David Widmann

> Despite this probably being a Julia issue, we may want to patch it anyways What's a possible workaround? Can we just change https://github.com/JuliaGaussianProcesses/KernelFunctions.jl/blob/ce7923f8252d183768f247256079a2c8279f7b1b/src/kernels/kernelsum.jl#L46 to ```julia function (κ::KernelSum)(x, y) return...

Maybe one has to add a `let` block to avoid the closure type inference bug?

Hmm, I'm not sure what's the best way to approach this though. I can see that it could be useful to retrieve the domain of the parameters, e.g., if one...

So it seems the main motivation is to introduce a different parametrization of `PeriodicTransform`? Then we could just define ```julia function PeriodicTransform(; period=nothing, frequency=period === nothing ? 1.0 : inv(period))...

> PeriodicTransform only works on 1D inputs, and maps each Real to two values. This is the main reason why I still think that PeriodicTransform should map to complex numbers...

> Then the base kernel would have to handle complex numbers, how would that affect speed e.g. when trying to run it on the GPU? `CuArray`s of `Complex{Float32}` should be...

Unfortunately, functors are not supported currently: https://github.com/JuliaDiff/ChainRulesTestUtils.jl/issues/117

Or we could just not make it a vector at all but a scalar :stuck_out_tongue:

If we stick with vectors (e.g. because of Flux/Zygote), in the example I guess `LinearKernel(c::Real)` could be a simple outer constructor `LinearKernel(c::Real) = LinearKernel([c])`.

One could eg use ParameterHandling and perform in-place updates of the resulting vector 😉 But then you would still have to go back and reconstruct the kernel.