Stephan Hilb

> I think if I use the in place version it won't have such issue. Not in your output container type, but the executed code might still by type-unstable before...

It is exactly as you say: return-type declarations are a `convert` before returning the value. No validation but they can still help type inference (provided you don't have a buggy...

> So in the case above your way of doing `mW -> (sum(mW) / kernelNumPx)::Float64` won't use any `conver()` but make the inference better hence performance will be better? yes,...

A couple of notes here: - An 11x11 kernel is something I would consider "big" and `StaticKernels` might not be the right choice for this, since we just loop over...

There is one in [this old pull request](https://github.com/JuliaArrays/StaticArrays.jl/pull/973). I would want to avoid changing `map` syntax too much, but you can definitely use a buffer in your window function already...

It says "Review required". I'm saying that you can reference a buffer from within your window function like this: ```julia const buf = zeros(3) k = Kernel{(-1:1,)}(@inline w -> (copyto!(buf,...

It is currently still undocumented, but you have full control over the boundary conditions already. A quick way to do that is defining your own extension type (here mostly copied...