[Numpy-discussion] Numeric bug in array2str() for rank >1 arrays when using MA?

Fernando Perez Fernando.Perez at colorado.edu
Mon Aug 2 11:50:05 CDT 2004


Hi all,

I think I've found a bug in Numeric's MA package.  The numeric docs say:

Finally, the last attribute, array_output, specifies whether to prepend the 
string "array(" and append either the string ")" or ", 'X')" where X is a 
typecode for non-default typecodes (in other words, the typecode will only be 
displayed if it is not that corresponding to Float, Complex or Int, which are 
the standard typecodes associated with floating point numbers, complex numbers 
and integers respectively). The array() is so that an eval of the returned 
string will return an array object (provided a comma separator is also used).

and they provide this example:

 >>> type(eval(array2string(arange(3), array_output=1, separator=',')))

<type 'array'>

This is all fine and dandy, but things seem to break down for any array of 
rank > 1 *** when MA has been imported only ***

In [234]: type(eval(array2string(RA.random((2,3)),separator=',',array_output=1)))
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/fperez/research/code/mwadap/<console>

/home/fperez/research/code/mwadap/<string>

TypeError: list indices must be integers


The problem is easily seen to be caused by MA:

In [1]: a=arange(4)

In [2]: a.shape= 2,2

In [3]: a
Out[3]:
array([[0, 1],
        [2, 3]])

In [4]: import MA

In [5]: a
Out[5]:
[[0,1,]
  [2,3,]]

Note the misplaced commas above, which make this an invalid nested list.

Once MA is imported it's impossible to get array2string() to return a valid 
representation of an array (something which survives an eval() call).  This is 
a problem for saving things to disk.

I'm using Numeric 23.1.

For now I'll work around this by avoiding MA, which is unfortunate because 
it's otherwise great for preventing huge machine-killing printouts of large 
arrays.

Best,

Fernando.




More information about the Numpy-discussion mailing list