I think we should follow the public opinion regarding Vector and Array, but
I see a use in the long run for a ``collect``-function (under the old or a
new name) that collects to the most adequate index-able structure, which
can be a BitArray for a boolean iterator, a no-op for a Range or a Dict or
Sparse array for other special iterators.
Regards,
Moritz
On Friday, May 27, 2016 at 11:42:52 AM UTC+2, Milan Bouchet-Valat wrote:
>
> Le jeudi 26 mai 2016 à 18:41 -0400, Jeff Bezanson a écrit :
> >
> > 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.
> How about this ?
>
> @deprecate Array{T}(dims::Dims) Array{T}(dims...)
>
> Then the only ambiguous case is Array{T}(x::Integer), which could
> either mean collect(x) or Array{T}((x,)). Maybe that's another argument
> in favor of deprecating iteration over scalars, which would allow
> choosing the latter meaning.
>
>
> Regards
>
> >
> > On Thu, May 26, 2016 at 4:14 PM, <[email protected] <javascript:>>
> 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
>
