I was looking at the most recent version of .7 and noticed a lot of the dot syntax was not working. Is this feature broken or being deprecated?
Here are some examples:
function f(x)
if rand() < .5
return x + 1
else
return x - 1
end
end
f.(rand(10))
ERROR: MethodError: no method matching getproperty(::typeof(f), ::Tuple{Array{Float64,1}})
Closest candidates are:
getproperty(::Any, ::Symbol) at sysimg.jl:18
x = [rand(2) for i in 1:10]
x .+ [1 2]
β Warning: `a::AbstractArray + b::Number` is deprecated, use `broadcast(+, a, b)` instead.
β caller = macro expansion at broadcast.jl:341 [inlined]
β @ Core broadcast.jl:341
a = rand(3,3)
a .= .1
β Warning: Deprecated syntax `using the value of `.=``.
β @ nothing none:0
The first example looks like a bug (something with global scope?):
julia> x = rand(2);
julia> f(x) = sin.(x);
julia> f(x)
2-element Array{Float64,1}:
0.3560585848659661
0.7432072794002402
julia> sin.(x)
ERROR: MethodError: no method matching getproperty(::typeof(sin), ::Tuple{Array{Float64,1}})
Closest candidates are:
getproperty(::Any, ::Symbol) at sysimg.jl:18
The third example is
https://github.com/JuliaLang/julia/issues/26516
1 Like
Thanks for the info. I canβt say I understand all of the design implications, but Iβm hoping most of the dot syntax is preserved. I think its among Juliaβs best features.
3 Likes
What version of v0.7 are you using?
This is the version Iβm using:
julia> versioninfo()
Julia Version 0.7.0-DEV.4806
Commit 98b1206 (2018-04-06 19:49 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin17.5.0)
CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-3.9.1 (ORCJIT, haswell)
Environment:
I thought that some of that might be fixed already.
It looks like example 1 is a bug and 3 is in flux. Does anyone know the status behind the second example?
That should be the same as
julia> [1 2] + 3
β Warning: `a::AbstractArray + b::Number` is deprecated, use `broadcast(+, a, b)` instead.
β caller = top-level scope
β @ Core :0
1Γ2 Array{Int64,2}:
4 5
which is a valid warning β the +
is applied elementwise in your example, with the elements being vectors and numbers.
Interesting. It works in .6.2 for some reason. It adds 1 to the first element of each sub-array and 2 to the second element of each sub-array. Is there a way to achieve that in .7?
Correction: it creates a 10Γ2 Array{Array{Float64,1},2}. It works in .6.2 nonetheless.
The reason is that they were deprecated for v0.7
. See
JuliaLang:master
β JuliaLang:ajf/deprecatearrayplusscalar
opened 07:34AM - 24 Jul 17 UTC
There has been much discussion around this lately. This PR deprecates `array + s⦠calar` (and related) in favor of `array .+ scalar` for v0.7 (with the possibility of introducing behavior such that `matrix + scalar == matrix + scalar*I` in v1.0 in a separate PR).
The arguments for changing the behavior of `array + scalar` from elementwise are:
* Apart from the binary `Number`/`AbstractArray` methods deprecated in this PR, all the other methods of `+`, `-`, `*`, `/` involving `AbstractArray` are motivated by and consistent with linear algebra. For instance `vector + vector` is defined because `vector` belongs to a vector space (not because `vector .+ vector` is inconvenient) and a such, the entire container adds (not just the elements). However, the current element-wise definition seems to be incorrect for linear algebra. For instance, if I write a polynomial function such as `f(a,b,c,x) = a*x^2 + b*x + c`, I expect it to work for any `x` that belongs to a field/ring/whatever. However, this definition is broken if `x` is a square matrix - you expect behavior like `f(a,b,c,x) = a*x^2 + b*x + c*I` but currently the `c` is added to all parts of the matrix, not just the diagonal part. It is therefore difficult to write generic code that works for a wide range of types of `x` (though I would note `a*x*x + b*x + c*one(x)` currently works for `x::Number` and `x::AbstractMatrix`, though the extra `one` seems unnatural).
* It seems to violate a property of `one` that you might expect, whereby `array + scalar != array + scalar*one(array)`
* AFAIK these are the last auto-vectorized methods that haven't been deprecated as a part of the dot-call changes (e.g. `sin(array)` no longer works; rather `sin.(array)` is necessary). In this situation, I would actually argue that `array .+ scalar` for elementwise addition is less confusing... it's less of a special case.
The primary arguments against (that I am aware of) are:
* The current `array + scalar` behavior is convenient (though `.+` is hardly much harder to type that `+`).
* We tried this once before and it was difficult (before the dot-call convention was introduced and well-known?)