Zeros #19635

jw3126 · 2016-12-17T20:20:42Z

Fix #19265 and add methods to zeros / ones with same signature as similar.

tkelman · 2016-12-17T20:43:03Z

test/arrayops.jl

+ zs = zeros(SparseMatrixCSC([1 2; 3 4]), Complex{Float64}, (2,3))
+ test_zeros(zs, SparseMatrixCSC{Complex{Float64}}, (2, 3))
+
+ @test_throws Exception zeros(Float64, [1.]) #19265


which exception type?

This tests that the situation in #19265 throws an error. It is a method error, so one could test for method error explicitly. I thought about this, but I think the precise exception type is an implementation detail and does not need to be part of the spec?

should test specifically, otherwise a typo in the implementation could pass this test

Good point.

tkelman · 2016-12-17T20:43:34Z

add a test for the situation from #19265 to make sure it doesn't alias now?

jw3126 · 2016-12-18T21:12:47Z

I think this PR is ready.

ViralBShah · 2016-12-19T10:30:59Z

I think this could use a slightly better commit message. Would you mind squashing and adding a couple of lines?

* Fix JuliaLang#19265. * Add methods to zeros, ones with analgous signature to similar.

jw3126 · 2016-12-20T19:48:10Z

Done.

stevengj · 2016-12-21T01:06:29Z

Needs a NEWS item.

stevengj · 2016-12-21T14:24:00Z

NEWS.md

@@ -97,6 +97,8 @@ Library improvements
 That is, not every member of the input iterable will be visited if a `true` (in the case of `any`) or
 `false` (in the case of `all`) value is found, and `mapreduce` will visit all members of the iterable.

+ * Additional methods for `ones` and `zeros` functions. These have the same signature as the `similar` function.


* Additional methods for `ones` and `zeros` functions to support the same signature as the `similar` function ([#19635]).

stevengj · 2016-12-21T15:16:41Z

base/array.jl

+ function ($fname)(a::AbstractArray, T::Type=eltype(a), dims::Tuple=size(a))
+ fill!(similar(a,T,dims), $felt(T))
+ end
+ ($fname)(T::Type, dims::Tuple) = ($fname)(Array{T}(dims...), T, dims)


This isn't right: it allocates an Array{T}(dims...) and passes it to $fname(...), but then that function calls similar, which allocates an second array. So you end up allocating one more array than you need.

I think you just want

($fname)(T::Type, dims::Tuple) = fill!(Array{T}(dims...), $felt(T))

Good catch!

stevengj · 2016-12-21T15:18:39Z

base/array.jl

+ ($fname)(T::Type, dims::Tuple) = ($fname)(Array{T}(dims...), T, dims)
+ ($fname)(dims::Tuple) = ($fname)(Float64, dims)
+
+ ($fname)(a::AbstractArray,T::Type,dims::DimOrInd...) = ($fname)(a,T,dims)


DimOrInd (an alias for Union{AbstractUnitRange{T},Integer}) doesn't seem right here. Shouldn't it just be Integer...?

I stole this from similar, which also uses DimOrInd for some methods. I think DimOrInd is for exotic things like OffsetArrays?

stevengj · 2016-12-21T16:42:52Z

base/docs/helpdb/Base.jl

@@ -564,9 +564,10 @@ julia> ones(Complex128, 2, 3)
 ones(t,dims)

 """
- ones(A)
+ ones(A::AbstractArray, T=eltype(A)::Type, dims=size(A)::DimOrInd)


this type signature isn't right for dims

stevengj · 2016-12-21T16:43:29Z

base/array.jl

+ ($fname)(T::Type, dims::Tuple) = fill!(Array{T}(dims...), $felt(T))
+ ($fname)(dims::Tuple) = ($fname)(Float64, dims)
+
+ ($fname)(a::AbstractArray,T::Type,dims::DimOrInd...) = ($fname)(a,T,dims)


dims::Integer...?

I stole this from similar, which also uses DimOrInd for some methods. I think DimOrInd is for exotic things like OffsetArrays?

okay... abstractarray.jl calls to_shape(dims) to get a tuple, though, and similar also supports dims::NeedsShaping

Maybe it would be better to just define:

$fname(a::AbstractArray, T::Type, dims::Tuple) = fill!(similar(a,T,dims), $felt(T)) $fname(a::AbstractArray, T::Type, dims...) = fill!(similar(a,T,dims...), $felt(T)) $fname(a::AbstractArray, T::Type=eltype(a)) = fill!(similar(a,T), $felt(T))

so that it can take any dims argument supported by similar and has the same behavior for exotic array types

Mhh okay, I was not aware of NeedsShaping. I will think about a clean way to support this, if I don't find one, I will switch back to Integer as you suggested in the beginning.

The NeedsShaping cases will be handled by the dims::Tuple method.

jw3126 · 2016-12-21T17:09:33Z

test/arrayops.jl

+ # exotic indexing
+ oarr = zeros(randn(3), UInt16, 1:3, -1:0)
+ @test indices(oarr) == (1:3, -1:0)
+ test_zeros(oarr.parent, Matrix{UInt16}, (3, 2))


@stevengj Here is a test that shows why ::DimOrInd instead of ::Integers was choosen.

stevengj · 2016-12-21T21:45:34Z

base/array.jl

+ $fname(a::AbstractArray, T::Type, dims...) = fill!(similar(a,T,dims...), $felt(T))
+ $fname(a::AbstractArray, T::Type=eltype(a)) = fill!(similar(a,T), $felt(T))
+
+ $fname(T::Type, dims::Tuple) = fill!(Array{T}(Dims(dims)...), $felt(T))


No need for splatting here; you can just do fill!(Array{T}(Dims(dims)), $felt(T)) I think?

stevengj · 2016-12-21T21:47:09Z

base/docs/helpdb/Base.jl

@@ -564,9 +564,10 @@ julia> ones(Complex128, 2, 3)
 ones(t,dims)

 """
- ones(A)
+ ones(A::AbstractArray, T=eltype(A)::Type, dims=size(A)::Tuple)


Need to document the dims... case too. Is ones(T, dims...) documented somewhere else?

There are at least some doctests where dims... is used. I can be more explicit about it.

stevengj · 2016-12-22T01:48:37Z

LGTM.

tkelman · 2016-12-22T07:49:28Z

base/docs/helpdb/Base.jl

-Create an array of all ones of specified type. The type defaults to `Float64` if not specified.
+Create an array of all ones with the same layout as `A`, element type `T` and size `dims`.
+The `A` argument can be skipped, which behaves like `Array{Float64,0}()` was passed.
+For convenience `dims` may also be passed in variadic form.


"variadic form" is not very clear, we don't use that terminology anywhere else

How would you call it instead?

I'd spell out an example

Maybe:

For convenience, `dims` may be passed as individual integer arguments, as in `zeros(3,4,5)`, rather than as a tuple.

There are examples where dims... is used already e.g. zeros(Int8, 2, 3). But I can open a new PR with stevengj's suggestion if you like.

Also I think if we don't have a terminology for dims..., we should introduce one. It occurs quite frequently and feels cumbersome not having a word for it.

I think "variadic form" is fine, but it should be spelled out with an example as well.

without any explanation that's terribly jargony and not very clear

Then please make a PR that improves it.

JuliaLang#19635 merged two docstrings for each of `zeros` and `ones` in a single docstring each. This changes the signatures in the stdlib file to reflect that change.

timholy · 2017-01-05T18:14:59Z

Worth noting, the syntaxes zeros(A, dims...) conflicts with something else we might like, zeros(-2:2, 0:5) to create an all-zeros array with indices (-2:2, 0:5). That first range argument is an AbstractArray so it will get captured by the zeros(A, ...) method.

timholy · 2017-01-05T18:20:03Z

Oh, looks like you test for this, but the true meaning is actually ambiguous unless the user supplies an intervening T. If ndims(A) > 1 you can also figure out what was intended, but the 1d case is awkward. For example, is zeros(1:3, 1:5) supposed to create an all-zeros vector "similar to a UnitRange{Int}", or is it supposed to create a 3x5 Matrix{Float64}?

jw3126 · 2017-01-05T21:05:30Z

Good point! I think at the moment zeros(1:3, 1:5) will be an error. Of course one could use dims instead of dims... to be unambiguous in these cases. But I agree it is awkward.

timholy · 2017-01-05T21:35:09Z

As long as the ambiguous case (not in the julia-method-sense, but in the "what do I mean?" sense) throws an error, we're probably OK.

timholy · 2017-02-24T13:00:08Z

Seems like we need a depwarn.

Julia 0.5:

julia> ones(Float64, 1:5)
5-element Array{Float64,1}:
 1.0
 1.0
 1.0
 1.0
 1.0

master:

julia> ones(Float64, 1:5)
ERROR: MethodError: Cannot `convert` an object of type UnitRange{Int64} to an object of type Int64
This may have arisen from a call to the constructor Int64(...),
since type constructors fall back to convert methods.
Stacktrace:
 [1] ones(::Type{T} where T, ::UnitRange{Int64}) at ./array.jl:252

timholy · 2017-02-24T13:00:36Z

Note that this depwarn should be viewed as a bugfix, and thus allowed even though we're in feature freeze.

timholy · 2017-03-27T09:39:31Z

Bump @jw3126 (see the depwarn above).

jw3126 · 2017-03-27T10:00:47Z

I can take care of the depwarn next weekend.

tkelman reviewed Dec 17, 2016

View reviewed changes

jw3126 force-pushed the zeros branch from cbbd66e to 0681cf4 Compare December 17, 2016 21:02

jw3126 force-pushed the zeros branch from d16b6ea to 17093ff Compare December 19, 2016 11:22

Add methods to zeros, ones.

39a3bde

* Fix JuliaLang#19265. * Add methods to zeros, ones with analgous signature to similar.

jw3126 force-pushed the zeros branch from 17093ff to 39a3bde Compare December 20, 2016 15:27

jw3126 closed this Dec 20, 2016

jw3126 reopened this Dec 20, 2016

news

b3a93f2

stevengj reviewed Dec 21, 2016

View reviewed changes

fix

38d34e7

stevengj reviewed Dec 21, 2016

View reviewed changes

fix

8f824a2

stevengj reviewed Dec 21, 2016

View reviewed changes

fix

259668b

jw3126 commented Dec 21, 2016

View reviewed changes

jw3126 added 2 commits December 21, 2016 21:37

fix

757e7ac

fix

b71e9e0

stevengj reviewed Dec 21, 2016

View reviewed changes

jw3126 added 2 commits December 21, 2016 23:11

fix

e80a695

fix

85c3f0a

ViralBShah merged commit 66ab171 into JuliaLang:master Dec 22, 2016

tkelman reviewed Dec 22, 2016

View reviewed changes

MichaelHatherly mentioned this pull request Dec 23, 2016

Doc fixes #19701

Merged

timholy mentioned this pull request Feb 24, 2017

Support new zeros/ones methods from #19635 JuliaLang/Compat.jl#330

Merged

timholy mentioned this pull request Mar 27, 2017

Some questions on useability JuliaArrays/OffsetArrays.jl#16

Closed

jw3126 mentioned this pull request Mar 27, 2017

deprecate unintended methods of zeros, ones #21183

Merged

saschatimme mentioned this pull request Aug 15, 2017

Eliminate build failure on julia 0.7 JuliaAlgebra/MultivariatePolynomials.jl#43

Merged

StefanKarpinski pushed a commit that referenced this pull request Feb 8, 2018

Support new zeros/ones methods from #19635 (#330)

86bd62b

Zeros #19635

Zeros #19635

Conversation

jw3126 commented Dec 17, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tkelman commented Dec 17, 2016

jw3126 commented Dec 18, 2016

ViralBShah commented Dec 19, 2016

jw3126 commented Dec 20, 2016

stevengj commented Dec 21, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stevengj Dec 21, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stevengj commented Dec 22, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timholy commented Jan 5, 2017

timholy commented Jan 5, 2017

jw3126 commented Jan 5, 2017

timholy commented Jan 5, 2017

timholy commented Feb 24, 2017

timholy commented Feb 24, 2017

timholy commented Mar 27, 2017

jw3126 commented Mar 27, 2017

stevengj Dec 21, 2016 •

edited

Loading