Broadcasting \sqrt (√) (and similar infix ops?)

[tkoolen]

From https://discourse.julialang.org/t/using-with-a-vector/6025.

x = rand(3)
√(x)

results in

WARNING: sqrt{T <: Number}(x::AbstractArray{T}) is deprecated, use sqrt.(x) instead.

sqrt.(x) works fine, but √.(x) results in

ERROR: syntax: invalid identifier name "."

since √ is an infix op (so .√(x) should be used, or (√).(x)).

Could √.(x) be made to work?

[stevengj]

See #20249. The following works:

julia> a = [1,2,3]
3-element Array{Int64,1}:
 1
 2
 3

julia> .√a
3-element Array{Float64,1}:
 1.0    
 1.41421
 1.73205

(Since it is an operator, you add the dot before the operator, just like .+.)

[tkoolen]

I already mentioned that in the issue description, but wouldn't it make sense to also support √.(x)?

[mschauer]

As binary operators o take their arguments at both sides, x .o y is not really different from y o. x. For unary operators o. x is less surprising than .o x and could be allowed as well, especially when it is not clear if a symbol is an operator or just an exotic character.

[fredrikekre]

#20540

[mschauer]

Ah, #19089 landed after #20540 went dormant.

[Keno]

I think √.(x) should parse and work regardless of the fact that it's a unary operator. That's just the standard call syntax. E.g. even though it's an operator you can do

julia> √(a,b) = 1
√ (generic function with 1 method)

julia> √(1,2)
1

which you can't express in operator syntax, but can express in call syntax.
Whether to make the do work on the other side is a separate question.

[Sacha0]

Making √.(x) work requires a breaking change IIRC, so labeling triage. Best!

[StefanKarpinski]

Why? √.(x) is a syntax error currently.

[Sacha0]

Why? √.(x) is a syntax error currently.

A vague memory from #20540. But having briefly reviewed #20540 I believe you are correct, i.e. making op.(x) parse for unary op shouldn't involve breakage. (The breakage in #20540 seems to follow from making op. parse for binary op, as e.g. 1+.2 becomes ambiguous as 1.+2 is now.) Best!

[Sacha0]

Hm, operators that are simultaneously unary and binary might add a twist though...

[stevengj]

No, I don't think simultaneous/unary binary ops should matter. If you make op.(x...) parse as (op).(x...) then it will work in both cases.

+.(3) and 4+.(3) are both currently syntax errors too, so there is no breakage here.