Bug with numpy.float32.tolist (Trac #718)

[numpy-gitbot]

Original ticket http://projects.scipy.org/numpy/ticket/718 on 2008-04-04 by trac user Elby, assigned to unknown.

numpy.float32 has a tolist method that standard python's float does not have, but this method does not return a list.

This can leads to bugs as reported in this thread, and IMHO this should be fixed or clearly explained.

[numpy-gitbot]

@teoliphant wrote on 2008-04-06

All of the numpy scalars have (almost) all of the same methods and attributes of numpy arrays. That is intentional. In addition, the behavior is generally equivalent to 0-d arrays in NumPy.

Thus, the behavior of the numpy scalar tolist method is to do the equivalent of convert to 0-d array and then call tolist on the 0-d array.

Currently, the 0-d array intentionally does not convert to a list (because 0-d arrays are not iterable) but returns it's corresponding Python ojbect. There are two options here:

1. Keep current behavior
2. Raise an error
3. Convert to a 1-element list

All but option 1 must be put off until 1.1 because of the change in behavior. My preference is to leave things as they are. I like #3 the least because a 0-d array should not be thought of as a list.

[numpy-gitbot]

Milestone changed to 1.1 by @teoliphant on 2008-04-06

[numpy-gitbot]

@cournape wrote on 2009-03-02

Hi Travis, why would you prefer 1 to 2 ? Is it because of the amount of effort, or do you see complication is that fails ?

[numpy-gitbot]

Milestone changed to Unscheduled by @cournape on 2009-03-02

[numpy-gitbot]

@charris wrote on 2010-07-18

I like 3) myself because it returns a list as implied by the method. 2) would be next on my list. I don't see any reason for 1), a method named tolist should never return anything other than a list.

[numpy-gitbot]

@teoliphant wrote on 2011-03-23

After the discussion it seems that Option 2) Raise an error or Option 3) return a 1-element list are the correct approaches.

I lean towards raising an error because of consistency with the interpretation that 0-d arrays are not containers.

On the other hand, practicality would indicate to do the "obvious" thing and return a 1-element list.

So, I could go either way.

[numpy-gitbot]

@charris wrote on 2011-03-23

I'm tending towards raising an error, not least because the scalar type doesn't have a len method.

[charris]

Still open.

[jamesbondo]

well, this is not so good.. still open and here's an example

a = np.arange(10).reshape(2,5)/3.0001

d = np.float32(a)

print d.tolist()
print "======"
print d
print "======"

print "%.8f", d

[mhvk]

@jamesbondo - your example is for an array, for which the behaviour seems fine. The problem here is that for a single float, one does not get a list:

In [6]: np.float32(1.).tolist()
Out[6]: 1.0

I note that the current behaviour is at least consistent in that array scalars (0-dimensional arrays) also return just the item instead of a list. This has the advantage of round-tripping:

In [9]: np.array(np.array(1.).tolist())
Out[9]: array(1.0)

In [10]: np.array(np.array([1.]).tolist())
Out[10]: array([ 1.])

Since the documentation says tolist returns a possibly nested list, one could argue that the 0-d case should be no list at all...

Anyway, for what it is worth, my vote would be for leaving things as is (but update the docstring).

[njsmith]

tolist is really misnamed -- it should be to_analogous_object_made_out_of_python_builtin_types or something. The actual semantics are to recursively replace n-d arrays with n-nested lists, floating types with instances of float, integer types with instances of int, and so forth.

I think this has to do with a compromise solution to a big debate way back in the mists of time about whether or not numpy indexing should return native python objects (type(np.arange(3)[0]) is int).

[eric-wieser]

I'm with @mhvk and @njsmith on this one - this is a documentation issue, and an unfortunate choice of function name, respectively. Tagging as appropriate