I was surprised that numpy.split yields a list and not an array. I would have thought it would be better to return an array, since numpy has put a lot of work into making arrays more useful than lists. Can anyone justify numpy returning a list instead of an array? Why would that be a better programming decision for the numpy developers to have made?
Rationale for numpy.split returning a list and not an array
2.7k views Asked by kilojoules At
2
There are 2 answers
0
On
Actually you are right it returns a list
import numpy as np
a=np.random.randint(1,30,(2,2))
b=np.hsplit(a,2)
type(b)
it will return type(b) as list so, there is nothing wrong in the documentation, i also first thought that the documentation is wrong it doesn't return a array, but when i checked
type(b[0])
type(b[1])
it returned type as ndarray.
it means it returns a list of ndarrary's.
A comment pointed out that if the slit is uneven, the result can't be a array, at least not one that has the same
dtype. At best it would be anobjectdtype.But lets consider the case of equal length subarrays:
But we can get the same array without split - just reshape:
Now look at the code for
split. It just passes the task toarray_split. Ignoring the details about alternative axes, it just doesIn other words, it just steps through array and returns successive slices. Those (often) are views of the original.
So
splitis not that sophisticate a function. You could generate such a list of subarrays yourself without a lot of numpy expertise.Another point. Documentation notes that
splitcan be reversed with an appropriatestack.concatenate(and family) takes a list of arrays. If give an array of arrays, or a higher dim array, it effectively iterates on the first dimension, e.g.concatenate(arr) => concatenate(list(arr)).