zeros function mutates arguments

[jw3126]

I was surprised by zeros sometimes mutating an array, I guess this is not intended:

x = [1.];
zeros(Float64, x);
x
1-element Array{Float64,1}:
 0.0

while

x = [1.];
zeros(x);
x
1-element Array{Float64,1}:
 1.0

Julia Version 0.6.0-dev.1202
Commit 42a22b6 (2016-11-06 22:14 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, haswell)

[nalimilan]

This is an unintended consequence of the fact that Array{T}(dims...) returns x when dims = (x,) and x is an Array{T}. That's kind of annoying. We could limit dims to a tuple of integers (i.e. ::Dims), since passing a type and an array it not really documented, and doesn't make a lot of sense since the type is redundant with the array's element type.

[jw3126]

I see, adding dims::Dims sounds good. Would it make sense to officially add a
zeros(::Type, ::AbstractArray) method? I used this quite frequently and did not realize it is unsupported until now.

[martinholters]

Allowing zeros(Float64, x) as a shorthand for zeros(Float64, size(x)) does not seem important, but it should error instead of having the current surprising behavior. Should we do

zeros(T::Type, dims::Dims) = fill!(Array{T}(dims), 0)
zeros(T::Type, dims::Integer...) = zeros(T, convert(Dims, dims))

and likewise for ones?

[nalimilan]

@martinholters's proposal sounds good.

Would it make sense to officially add a
zeros(::Type, ::AbstractArray) method? I used this quite frequently and did not realize it is unsupported until now.

Why don't use just use zeros(::AbstractArray)? The type must match the array's element type anyway, so it doesn't sound terribly useful.

[jw3126]

Why don't use just use zeros(::AbstractArray)? The type must match the array's element type anyway, so it doesn't sound terribly useful.

Ah usually I want say an array of Float64 zeros with the layout as a given matrix of Int64. Now I don't explicitly write silly code like zeros(Float64, [1.]), but this case occurs when using generic programming.

[jw3126]

@martinholters I can provide a PR with your suggestion if you like.

[yuyichao]

Ah usually I want say an array of Float64 zeros with the layout as a given matrix of Int64.

We support this in similar so I think it makes sense to support it in zeros too.

[jw3126]

The signature of similar is
similar(array, [element_type=eltype(array)], [dims=size(array)])

would you suggest to add
zeros(array, [element_type=eltype(array)], [dims=size(array)])
?

[martinholters]

@jw3126 Go ahead with a PR. But restricting the current signature to ::Dims and ::Integer... might qualify as a backport-worthy bugfix, while supporting a similar-like signature would be a new feature, so best to make these two separate commits.

[yuyichao]

Removing a signature will cause code that used to "work" to error so I'm not sure how backportable is that. Sure, those code shouldn't be using this signature in the first place but there many other cases where we don't backport a change because of this.