i was curious as to why the ‘.’ versions, abs., log10., etc… have been created ?
doesn’t the fact that the functions are methods and can specialize on their argument make this unnecessary, i.e. what was wrong with the non ‘.’ versions ?
I think you misunderstand. There is no “broadcast version”, there is only broadcast. f.(...) is lowered to broadcast(f, ...). Please read the manual.
2 Likes
The . is now just a shorthand for broadcast / broadcast!. If you create a function foo(x::Int) = 3 * x, then foo.([1, 2, 3]) will automatically work and return
3-element Array{Int64,1}:
3
6
9
Running @which foo.([1, 2, 3]) will print
broadcast(f, A, Bs...) in Base.Broadcast at broadcast.jl:434
showing that the broadcast function is being called. So it’s not that abs., log10., etc. have been explicitly created, it’s just that the dot syntax is a language feature that applies to all functions.
2 Likes
Obligatory read:
Essentially by making it a part of the syntax, many optimizations can occur to get rid of temporary variables and speed it up (without runtime magic).
7 Likes
It also eases the load on the developer. Instead of having to create a special method of their function for collections (and perhaps even special versions for different collections), they can just rely on broadcast to handle it for them, in a uniform and well-defined way.
The user also doesn’t have to wonder whether a collection version exists, (because sometimes it does and sometimes the developer just didn’t think of it). Just use dot broadcast.
Some functions should actually have separate different behaviour for collections. Let’s say you develop a method foo(x, y) that essentially multiplies x and y. If someone inputs two 2-dimensional arrays instead of two numbers, how should your code handle that? Perform elementwise multiplication or matrix multiplication? You need to decide in your code, and let’s say you decide to use matrix multiplication.
But what if the caller actually wants the elementwise operation? Without broadcasting, they’ll have to write a loop. With broadcasting, the developer does not need to think about the elementwise behaviour. The caller just writes foo.(X, Y), and automatically get what they want.
4 Likes
There’s also the eternal question of “should this function be a broadcast function or not?” There’s no good, consistent answer, just a random division of functions that are and functions that aren’t. The f.(x, y) calling scheme allows the caller to choose, which is the correct place for the choice to be made.
6 Likes
No, because you may want to define a method for arrays that isn’t simply the “broadcasted” version of the “scalar” method.
For example, currently expm is the function to compute the matrix exponential, which is a substantially different operation than the “broadcasted” version of the scalar method. There is an ongoing debate whether rename it to exp (and I’m personally in favor of this change), so that
exp(x), withxscalar, gives the exponential of the numberx;exp(A), withAmatrix, gives the matrix exponential ofA;exp.(A)gives the element-wise exponential of the matrixA.
Thus, using a different syntax for broadcast than the simple function call and leaving the freedom to define different methods for arrays that aren’t the broadcasted version of the scalar method is a good thing.
13 Likes
aha! exactly what I was looking for. thanks 
For a different reason, I find myself asking the same question for this situation: suppose that a long precomputation is needed:
function f(x::Number, y::Number, z)
c = long_precomputation_of_parameters(z)
compute_something.(x, y, c)
end
For this situation, short of having to awkwardly call compute_something.(x, y, c), it makes more sense in my opinion to have only the version taking vectors as input.
I’m confused about what the issue is here – is it an objection to the syntax?
I am not sure you are replying to my post, and I realize that the post was hastily written.
No, the syntax is not the problem. I am instead struggling to find the correct signature of a function that requires a long set up.
I apologize in advance because the specific case I am going to describe is slightly different from the one outlined above: I need to evaluate series of fully normalized Legendre polynomials which is usually done by the Clenshaw algorithm: the coefficients \alpha_k and \beta_k in the article contains square roots.
If I use the dot notation, I need to compute the coefficients for each input element; on the other hand, using the vectorized version, the coefficients are computed once for input vector. (If you are going to suggest to cache the coefficients, this is what I do when I use Float64 only.)
What I wanted to say is that there is another class of problems for which the vectorized version may be more efficient than the dot version.
Does all this make sense?
Normally, the Julian solution for this sort of thing is to construct an object that encapsulates your precomputation. For example, you have a constructor Legendre(data) that creates a Legendre object that stores all of the coefficients etcetera that you need to evaluate the interpolant efficiently. An L = Legendre(data) object would be callable, so you could then do L(x) to evaluate the interpolant at x, and L.(x) to evaluate it efficiently for an array. Or, more compactly, Legendre(data).(x) would efficiently construct the coefficients (once) and then apply them to an array, without requiring you to ever define a specialized “vectorized” method.
For real-world examples of this, see the Fun object in ApproxFun.jl or the various InterpolationType objects in Interpolations.jl.
Then, for example y .+= sqrt.(Legendre(data).(x .- 1) .* 2) would fuse into a single in-place assignment loop that constructed L = Legendre(data) once and computed y[i] += sqrt(L(x[i] - 1) * 2) in-place for each element of two arrays x and y.
16 Likes
Sorry for reviving an old thread, but something linked here which made me read this and got me curious
I am confused. Is this something introduced in 0.7? I looked at the result of expand for your example expression and got suspicious by its output, so i tried the following mock imlementation:
julia> struct Legendre
data
Legendre(data) = (println("foo"); new(data))
end
julia> (L::Legendre)(x) = L.data * x
julia> x = rand(5) .+ 10; y = zeros(5);
julia> y .+= sqrt.(Legendre(2).(x .- 1) .* 2)
foo
foo
foo
foo
foo
5-element Array{Float64,1}:
6.3153
6.03635
6.32346
6.2137
6.04248
EDIT: the above is 0.6 but I just tried a couple days old 0.7 branch on my second machine and it gives the same output. Am I doing something subtle that prevents the struct to be created just once? I also tried using a function barrier as well as adding a ::Int to the data field (just in case). both without success.
2 Likes
A little more compact example of the above issue:
struct Bar
data
Bar(data) = (println("foo"); new(data))
end
(B::Bar)(x) = B.data * x
Bar(2).([1,2,3]) ##Bar(2) will be only evaluated once
broadcast(sqrt, Bar(2).([1,2,3])) ##Bar(2) will also be evaluated once
sqrt.(Bar(2).([1,2,3])) ##Bar(2) will be evaluated three times
1 Like
No, my mistake. Legendre(2).(x) corresponds to broadcast(Legendre(2), x), which calls Legendre(2) once, but sqrt.(Legendre(2).(x)) turns into broadcast(x -> sqrt(Legendre(2)(x)), x), which calls Legendre(2) multiple times. You need to do L = Legendre(2) separately, then do sqrt.(L.(x)), to ensure that the constructor is called only once.
It would be possible, in principle, to change this so that sqrt.(expression.(x)) turns into let tmp = expression; broadcast(x -> sqrt(tmp(x)), x); end. I haven’t really thought through what implications this would have, though. In any case, it would be (in principle) a breaking change that is probably too late to get into Julia 1.0. Or maybe this could be viewed as a bugfix?
3 Likes
I always thought of nested broadcasts as calculating non-broadcasted values once (not sure why though, it just seemed like good design so I assumed it), so I would think this is a bug. It would be nice to have this as a property one could rely on.
1 Like
File an issue on GitHub if that’s a problem for you. Since it’s about a very specific case, it could be considered a bugfix and applied even after the feature freeze (but before 1.0).
Opened an issue:
https://github.com/JuliaLang/julia/issues/25340
@Non-Contradiction: I used your nice compact example, but could not give credit on github since I don’t know your username there, just PM me if you want me to add it.
1 Like