Request: Vector and Matrix constructors.

[KristofferC]

For previous discussion, see: https://groups.google.com/forum/#!topic/julia-users/FBmU-mxQ0k4

My request is to have functionality to be able to initialize a vector of size N and type T using the Vector(T, N) command. This would be equivalent to the current Array(T, N). The reason for this is that it if I have a function taking a Vector argument it feels nice to create the vector I send in to the function using a Vector constructor. Same for matrices.

I tried to implement it myself like this (and in some other ways) but it is not working:

Base.call{T}(::Vector{T}, size::Int) = Array(T, size)

[nalimilan]

I think what you need is this:

Base.call(::Type{Vector}, T::Type, m::Integer) = Array(T, convert(Int, m))

This is consistent with the definition used for Array (cf. @edit Array(Int, 1)). It ensures that e.g. Vector(Int, BigInt(1)) works.

Note ::Type{Vector}, which means that the argument is the Vector type, not a Vector object.

Could you prepare a PR for this (together with the equivalent code for Matrix, and some tests)? Thanks!

[stevengj]

You could also have Base.call{T}(::Type{Vector{T}}, m::Integer) = Array(T, m) to support e.g. Vector{Int}(5). But for that matter shouldn't we also support Array{Int}(5)?

(I don't think the convert(Int, m) is required since that is done in the Array constructor already.)

[StefanKarpinski]

While we're at it, I think it would be nice if things like Array{Int}(3,4) worked. Arguably that's a better, more consistent way to construct arrays than the current Array(Int,3,4).

[nalimilan]

@stevengj You're right about convert of course.

Regarding Array{Int}(5), I've often wanted to do that too, but having too many ways of doing the same thing is not great. We should decide which one is the recommended way, and deprecate the other.

[ivarne]

Array{Int}(3,4) or Array{Int, 2}(3,4)

[StefanKarpinski]

I would say that both could be allowed, but Array{Int,2}(3,4) is redundant and the fact that it's a matrix is implied by the dimensions. As for too many ways, I'd favor deprecating Array(Int,3,4).

[milktrader]

Yeah, +1 for deprecating Array(Int,3,4)

This suggests the type is just another parameter, but putting it into curly braces reinforces the notion that types are super-parameters.

[bicycle1885]

It looks nice and is what I expected to work when I started to play with Julia 👍.
If you are reluctant to do the job, can I take on it?

[KristofferC]

How about things like floor(Int, x)? Should they be written floor{Int}(x) as well?

[bicycle1885]

That would be a separated question. Array{T,N} is a constructor but floors are not.
If we take the idea, too many functions that take a type as its first argument will be affected (rand(Bool) => rand{Bool}(), convert(Int, 1.0) => convert{Int}(1.0) etc...).

[JeffBezanson]

duplicate of #3214

[JeffBezanson]

I added these. We can decide whether to do formal deprecations --- prepare yourself for lots of warnings!!

I didn't add Vector(T, n), pending the deprecation decision.

[jakebolewski]

Is it correct that Array{Int}(1,2) constructs a new array and Array{Int}((1,2)) calls convert(::Type{Array{Int}}, (1,2))?

[jakebolewski]

I see the old behavior is still retained. So Array{Int}([1,2]) is a conversion and Array{Int}((1,2)) is a construction?

[JeffBezanson]

Yes.

[jakebolewski]

If this is going to be the new default behavior, could we deprecate the NTuple constructor?

[JeffBezanson]

I would be fine with that, but the trouble is that an NTuple carries type information about the number of dimensions, while varargs do not. So we will need to hack around that with an internal definition that still accepts a tuple. There is also something to be said for minimizing splatting, and writing Array{T}(size(x)).

[stevengj]

See Jeff's commit: 23a6995