Yes, it would be good to deprecate `collect` to `Vector` (so it always
returns a vector like it used to), and call `Array` where we want the
result to have the same shape as the iterator. The main wart is that
Array{T}(tuple) already has a meaning where the tuple specifies the
size, but here the tuple would be the iterator giving the data. I
think it would be best to base everything on iterators, e.g.
zeros(n) = Vector(take(repeated(0), n))
zeros(n,m) = Array(reshape(repeated(0), (n,m)) or
zeros(n,m) = Array(repeated(0), (n,m))
# half seriously
Array(T::Type, n) = Array{T}(take(Undefined(), n))
I can just barely imagine a deprecation path here. The main question
is what to do about all the constructor calls that currently make
uninitialized arrays. For numeric types it would be ok to deprecate
them to `zeros(T, n, m)`, since we will probably move to zero filling
anyway, but it's less clear what to do for general T.
On Thu, May 26, 2016 at 4:14 PM, <[email protected]> wrote:
> I've also discovered that collect(1) will now generate a 0-dimensional
> Array, presumably as part of the same update, while collect([1]) still
> generates a Vector. Is this intended too? If so, is there any way of
> generating a Vector from either a Vector or a scalar - I was using collect
> to do this up to now with 0.[34].x, 0.5-dev...?
>
> Cheers,
>
>
> Richard.
>
>
> PS If it's a permanent change, the docs should be updated too:
>
> Return an array of type Array{element_type,1} of all items in a collection.
>
>
> On Wednesday, 25 May 2016 20:41:05 UTC+1, [email protected] wrote:
>>
>> Hi,
>>
>> I am not sure if this is the right place to post questions about version
>> 0.5.0-, but I'll give it a try anyhow.
>>
>> In 0.4.5, collect([1 2]) gives Array{Int64,1}, like a column vector.
>>
>> In 0.5.0_ (as of 25 May, Win64), collect([1 2]) gives Array{Int64,2}, like
>> a row vector.
>>
>> Is this intended? (...just struggling to prepare for the next release)
>>
>> /Paul S