Le dimanche 11 mai 2014 à 21:27 -0500, Tim Holy a écrit :
> Yes, when reading data from files, where information about the object is
> encoded in the file, "type stability" kinda goes out the window. (We have the
> same issue with HDF5, of course.)
But this would mean that functions loading CSV files cannot rely on the
assumption that the result is a two-dimensional array. This makes
writing generic code harder.
I'd say the situation is different for HDF5 since it allows for a much
more precise description of the data, i.e. when saving/loading I guess
you can distinguish between a row vector and a column vector.
My two cents
> So it's not an unreasonable request (although neither is the current
> behavior). You might consider giving it a stab yourself and see how people
> react to a pull request.
>
> --Tim
>
>
>
> On Sunday, May 11, 2014 03:00:10 PM Ethan Anderes wrote:
> > Thanks for the response. Still not sure I understand what you mean. readcsv
> > returns Array{T, 2} where T is determined form the file ... so the type of
> > the output does change based on the file. Since column vectors are thought
> > of as 1-d arrays in Julia I would have assumed the Julian way to load a
> > column is to return Array{T,1}. I was just suggesting that readcsv would
> > just return Array{T,d} where T and d are appropriately determined form the
> > file.
> >
> > Anyhoo, I guess there must be a reason it works the way it does but the
> > whole readcsv(...)[:] thing seemed an unnecessary overhead so I thought I
> > would check to see if I'm using the wrong command.
