Which notation is best? about multivariateorthogonalpolynomials.jl HOT 3 OPEN

That's mostly just me trying different things to get building operators to be faster. The big issue with @. is it makes nested broadcasting, which at some point breaks type inference. The manual . versions suffer the same problem, but not as bad.

It's likely that the BroadcastVector(...) version was a specific case where the nested broadcasting was too hard for type inference so by doing this we avoid nested broadcasting completely.

But this would have been a one-off experiment so has not been thoroughly investigated.

from multivariateorthogonalpolynomials.jl.

Does type assertion solve issues related to inference?

from multivariateorthogonalpolynomials.jl.

No. Here's a rough idea of the problem. Let's say we have a complicated nested BroadcastVector like

v = ((k .+ (c-1)) .* ( k .- n .- 1 ) ./ (2k .+ (b+c-1)))

When building operators the code basically lowers to

for K in Block.(1:N)
   copyto!(view(dest,K), view(v,K))
end

It's smart enough to recognise view(v,K) is itself equivalent to a BroadcastVector thus this becomes equivalent to:

k_K = view(k,K) # returns Base.OneTo(Int(K))
n_K = view(n,K) # returns Fill(Int(K),Int(K))
copyto!(view(dest,K), ((k_K .+ (c-1)) .* ( k_K .- n_K .- 1 ) ./ (2k_K .+ (b+c-1)))) # actually a nested Broadcasted 

When correctly type-inferred the last step then gets reduced to a tight loop, essentially as fast as if done manually. When type-inferrence fails, it doesn't know how to reduce the nested Broadcasted to a simple loop, and hence has to do dynamic dispatch looping over every entry of view(dest,K), so extremely slow.

from multivariateorthogonalpolynomials.jl.