[SciPy-user] numpy repr issue
Fri Feb 27 13:19:22 CST 2009
On Fri, Feb 27, 2009 at 04:45, Jeremy Sanders <firstname.lastname@example.org> wrote:
> Hi - I wonder whether you consider this a bug (numpy 1.2.0 x86_64):
> In : repr(numpy.arange(10000))
> Out: 'array([ 0, 1, 2, ..., 9997, 9998, 9999])'
> I've found out that you can use numpy.set_printoptions to control this
> truncation behaviour, but the python documentation says:
> Return a string containing a printable representation of an object. This is
> the same value yielded by conversions (reverse quotes). It is sometimes
> useful to be able to access this operation as an ordinary function. For many
> types, this function makes an attempt to return a string that would yield an
> object with the same value when passed to eval(), otherwise the
> representation is a string enclosed in angle brackets that contains the name
> of the type of the object together with additional information often
> including the name and address of the object. A class can control what this
> function returns for its instances by defining a __repr__() method.
> Numpy doesn't obey this. It returns a string you can't do repr on to get
> back the original data. It's not a string in angle brackets either.
It is far from a strict commandment. There is absolutely no guarantee.
The reason for the truncation by default is interactive use. Numeric
used to display everything by default. If you typed the name of a very
large array and pressed enter, the interpreter would try to make a
full string repr from it and then display it. Since this is done in C
code, you could not cancel it from the keyboard.
> I've just hit a bug in pymc where truncated data is stored in its text
> database. It uses eval to read back the data.
PyMC should not be relying on that behavior.
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
More information about the SciPy-user