Not sure if this is a bug or a feature but if I use:
f_data = np.genfromtxt('file.dat', dtype=None, unpack=True)
where file.dat
is a standard data file with several columns (ie: http://pastebin.com/ihEW2dxS) the result is not transposed as one would expect having set unpack=True
.
For example, the line f_data = np.loadtxt('file.dat', unpack=True)
works as expected.
Looks like a bug, marking it so until informed otherwise.
I investigated this a little bit.
The result of @Gabriel-p's code is a shape (12,) flex array. The code calls output.T
on it, but since it's one dimensional this is a no-op.
The biggest issue that dtype=None
specifies that it will be flex array. Each column has a separate inferred type. If we were to truly transpose this result, each row would need to have a separate type. AFAIK, the only way to do that is to have a list or tuple of homogeneous arrays.
Since numCols << numRows in the text file, using a list or tuple shouldn't be a big deal. If implemented that way, it would unpack for x, y, z = np.genfromtxt(...)
as specified in the docs, and solve @Gabriel-p's case.
However, genfromtxt
is already over 600 lines. Any thoughts?
Just got bitten by this, too. I made a test case, see
https://github.com/hsgg/numpy.git
I also experience this. loadtxt
is a bit more clever:
if unpack:
if len(dtype_types) > 1:
# For structured arrays, return an array for each field.
return [X[field] for field in dtype.names]
else:
return X.T
Why doesn't genfromtxt
do this?
Any update on this issue? It seems like it hasn't changed since 2014.
The suggestion @moi90 made a couple years ago is correct. genfromtxt
should do the same thing as loadtxt
.
I think it will be easy to fix, so I've tagged the issue as a "good first issue".
Most helpful comment
I also experience this.
loadtxt
is a bit more clever:Why doesn't
genfromtxt
do this?