broadcasting over scalars should produce a scalar

[stevengj]

This changes f.(numbers...) to be equivalent to f(numbers...). Rationale:

• It is a longstanding convention that "dot" operators like .^ are equivalent to the "non-dot" operator when acting on scalars, and we need to preserve this behavior if we want to change dot operators to use broadcast as per Vectorization Roadmap #16285.
• It makes it easier to write generic code that works equally well for vectors and scalars.
• map(f, numbers...) already returned f(numbers...), and it is odd for broadcast to be different.

Also, I made the empty-argument case f.() or map(f) return f(), for much the same reasons. (Previously, this threw an exception for both map and broadcast.) Update: This also will give more consistent behavior for inlining literals in f.(args...) broadcast syntax (see below).

[stevengj]

cc: @nalimilan

[nalimilan]

+1, but see #17053.

[stevengj]

While it would be nice to have a more general mechanism, I'd prefer to merge this so that the f.(number...) semantics are fixed for 0.5.

[nalimilan]

Sure, let's merge and possibly revise this to use the new trait from #17053 later.

Another interesting question: should strings behave like scalars? That's been advocated at #16966 (comment). Again, should not block this PR.

[tkelman]

test type equality too?

[stevengj]

will do

[stevengj]

At least for the purposes of broadcast, my inclination is that strings should be treated as scalars. I'd like to be able to do broadcast(string, "foo", 1:3) and get ["foo1", "foo2", "foo3"]. But that is a separate issue from this PR, of course.

[TotalVerb]

Why should it return f() (in analogy with map(f, 1, 2)), and not [f()] (in analogy with map(f, [1], [2])), or even [f(), f()] in analogy with map(f, [1, 2], [3, 4])? It seems it's impossible for the empty case to be fully generic, because different kinds of collections give different results.

Otherwise, I agree with this PR.

[pabloferz]

I was doing this also as part of #16986. But that tries to be much more general. I agree that at least the simple case for number should work on 0.5.

[andyferris]

Why should it return f() (in analogy with map(f, 1, 2)), and not [f()](in analogy with map%28f, [1], [2]%29), or even [f(), f()] in analogy with map(f, [1, 2], [3, 4])?

I think it would do all of those things. broadcast(f, 1, 2) == map(f, 1, 2) == f(1,2), and broadcast(f, [1], [2]) == map(f, [1], [2]) == [f(1,2)], etc, no? I.e. [1] is not a scalar.

[stevengj]

@TotalVerb, my feeling was that f.() should return the simplest possible sensible result. The result should certainly be zero-dimensional for broadcast over zero arrays, and f() is a much simpler and more useful "zero-dimensional" result than a zero-dimensional Array. And map should be consistent with broadcast.

[stevengj]

Another reason for this f.() behavior: in my loop-fusion code for #17300, pretty soon I will be "inlining" numeric literals, so that atan2.(x,1) goes to broadcast(x -> atan2(x,1), x). However, in that case it will transform atan2.(3,4) to broadcast(() -> atan2(3,4)), and the f.() === f() behavior is required for this to work.

(I could explicitly check for the case where all the arguments are literals, of course, but the inlining behavior is much more consistent if I don't have to special-case this.)

[stevengj]

Okay to merge? cc @JeffBezanson

[stevengj]

These semantics really should be decided by 0.5, because the broadcast usage will expand greatly with the new f.(args...) syntax, so I'm marking this with the milestone.

[tkelman]

I think this is ambiguous with

julia/base/deprecated.jl

Line 370 in 2b98dda

function broadcast(x::Any, i::Union{Integer,Symbol})

(but not detected? cc @timholy) and causes, for example speye(5).(2) to not trigger the deprecation getfield path that it would have meant on 0.4, but instead trigger a MethodError: objects of type SparseMatrixCSC{Float64,Int32} are not callable.

[stevengj]

Should be a simple matter of adding a more specific deprecation method, yes?

[tkelman]

is the deprecation method already more specific? integer vs number? or is the union making dispatch pick Number?

[stevengj]

You're right, the deprecation method seems more specific according to the rules discussed in #16489, but maybe the varargs are confusing things here. @JeffBezanson?

[stevengj]

Oh, right, it's turning foo.(1) into broadcast(() -> foo(1)) because the literal gets inlined into the function by compress-fuse, so the deprecation can't be invoked.

[stevengj]

Will submit a PR shortly to restore the getfield deprecation.

[tkelman]

thanks, I was attempting some things and not able to get it to work - d8f4b60 wasn't where I thought bisect would point me