thouis / numpy-trac-migration

numpy Trac to github issues migration
2 stars 3 forks source link

Multi-dimensionial array support for savetxt / loadtxt (migrated from Trac #1888) #3436

Open thouis opened 12 years ago

thouis commented 12 years ago

Original ticket http://projects.scipy.org/numpy/ticket/1888 Reported 2011-06-30 by atmention:brickZA, assigned to unknown.

I think it would be feasible to support multi-dimensional saving/loading quite simply by using multiple line-breaks for 'higher-dimensional' linebreaks.

d3D = numpy.array([[[111, 112], [121, 122]], 
                   [[211, 212], [221, 222]]])

could be written to text quite unambigiously as

111 112
121 122
            <--- two line breaks indicate break in the 3rd dimension
211 212
221 222

Similarly, 3 line breaks could indicate a break in the 4th dimension.

Another option would be to have the option to write out text in nested-list format. I.e., simply write

[[[111, 112], [121, 122]], [[211, 212], [221, 222]]]

to the file.

thouis commented 12 years ago

Comment in Trac by atmention:dhomeier, 2011-07-04

To some degree this has already been addressed in #1107. I am in favour of adopting the gnuplot convention of double blank lines between blocks, as there seems to be some demand for reading in files of this style. I don't feel quite comfortable with the way proposed in the patch there to return a regular ndarray(N,M) plus an index list to the blocks though. As a general comment, basic support for such functionality would indeed be relatively easy to implement, but there are a few design decisions involved (like the above, or should we allow to read data blocks of different sizes or only true 3-dimensional arrays, meaning to raise an error if not all of the blocks have equal length...); and it touches a number of features that have just been cleared up in the code - e.g. the ndmin keyword and the behaviour of the unpack option for regular vs. record arrays. Not sure of the latter can be consistently defined for arbitrary dimensions.