dot operator inconsistency; broadcasting

[ViralBShah]

Inconsistency is that +(Matrix, Number) works, but >(Matrix, Number) does not.

julia> rand(5,5) > 0.5
no method isless(Float64,Array{Float64,2})
in method_missing at base.jl:60
in > at operators.jl:14

julia> rand(5,5) .> 0.5
5x5 Bool Array:
false true false true false
true true false true false
true false true false true
false true true false true
false true true true true

julia> rand(5,5) + 0.5
5x5 Float64 Array:
0.79251 1.06707 0.500777 0.953643 0.552748
0.879198 0.975167 0.671291 1.05633 0.99309
1.47143 1.28383 0.819195 1.09337 0.82331
1.44972 1.08734 0.510404 0.796567 0.523913
0.703234 0.701464 0.517295 0.569722 1.29657

julia> rand(5,5) .+ 0.5
syntax error: extra input after end of expression

[JeffBezanson]

Fixed the syntax error in commit 02f5cc3.

[JeffBezanson]

A related issue that hasn't come up yet is scalar broadcasting in assignment, e.g. A[:,1] = 2. This creates a major annoyance since there is an ambiguity in the case A[1:1,1:1] = [2,3]. Should that assign [2,3] as an element of the array, or is it elementwise assignment with a shape mismatch?

[JeffBezanson]

Copying @StefanKarpinski . Another problem this causes is that we have to double every definition for assign to deal with the ambiguity, which is really annoying, and can cause performance problems since there are cases where 2 methods match that do the same thing, so the match should have been unique.

[StefanKarpinski]

Hmm. That is perplexing. Tangentially, would the assign API be nicer if it looked like assign(A,I::Tuple,v) where I is always a tuple of indices? I suspect that would potentially slow things down, although I think it's a much cleaner API, IMO.