unsupported operand type(s) for *: 'numpy.ndarray' and 'numpy.float64'

Question

long time reader, first time writer.

I searched around on google and stack overflow, but wasn't really able to find a general answer to this question.

I am getting an "unsupported operand type(s) for *: 'numpy.ndarray' and 'numpy.float64'" error in python 2.7.3 using numpy 1.6.2.

The error comes from multiplying a numpy array and a numpy float, but it doesn't happen every time.

For example:

x = np.tan(1) # numpy.float64
y = np.array([0,1,2,3]) # numpy.ndarray
np.multiply(x,y) # works no problem

Or

x = np.tan(np.abs(np.multiply(-31,41)))  # numpy.float64
y = np.square(np.add(np.divide(np.zeros(100),42),(-27)**40)) # numpy.ndarray
np.multiply(x,y) # works no problem

Both work

Now for the problem children:

np.multiply(np.square(np.add(np.divide(np.zeros(100),42),-27)**40)),
np.tan(np.abs(np.multiply(-31,41))))

or, with x defined as above:

np.multiply(np.square(np.add(np.divide(np.zeros(100),42),(-27)**40)),x)

both produce the error: NotImplemented

I know the random functions and numbers seem odd, but conceptually this still should work, as it worked when both were set to variables individually.

Why does this happen? How can I fix it in a general sense?

Thanks so much! Jason

Mcspadden

I think you have caught a bug in the code, you may want to report it to the numpy people. For the record, if a is np.ndarray and x is np.float64, then both x * a and a * x[...] work, but none of a * x, a + x, a / x or a - x do. It is hard to understand why, if the __mul__ method of a cannot handle it, __rmul__ of x is not called, as it seems to know how to handle the case... – Gemination

Thanks so much for vetting that for me. I will try to report it as an issue in numpy. Do you think there may be a way to work around this? – Mcspadden

If you replace x with x[...] it works, but it is a nasty hack... – Gemination

Unfortunately, that is not going to be an easy way for me to stop my code from erroring, as these functions are being randomly generated by DEAP (An excellent genetic programming framework I am working with). – Mcspadden

Issue filed at: github.com/numpy/numpy/issues/2930 – Mcspadden

Mixing floating point numbers with long integers is in general a bad idea. (-27.)**47 should fix your problem... You could go for arbitrary precision arithmetic, but there is no support in numpy, see this answer – Rill

Already got a response! Issue is corrected in numpy 1.7 (which will be released soon) github.com/numpy/numpy/issues/2930#issuecomment-12445232 – Mcspadden

Answer 1

I suspect that the problem here is that NumPy cannot store Python long values in its arrays. As soon as you try to do this, it switches the data type of the array to object. Arithmetic operations on the array then become trickier because NumPy can no longer do the arithmetic itself.

>>> np.array(27**40)
array(1797010299914431210413179829509605039731475627537851106401L, dtype=object)
>>> np.array(27**40) * np.tan(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for *: 'numpy.ndarray' and 'numpy.float64'

Oddly enough, swapping the order of the arguments can sometimes work:

>>> np.tan(1) * np.array(27**40)
2.7986777223711575e+57

In this second case, the type of the result is a Python float, not a NumPy array.

The fix is to avoid creating long values in NumPy arrays, and use floats instead:

>>> np.array(27.0**40)
array(1.797010299914431e+57)
>>> np.array(27.0**40) * np.tan(1)
2.7986777223711575e+57
>>> np.multiply(np.square(np.add(np.divide(np.zeros(10),42),(-27.0)**40)),np.tan(1))
array([  5.02925269e+114,   5.02925269e+114,   5.02925269e+114,
         5.02925269e+114,   5.02925269e+114,   5.02925269e+114,
         5.02925269e+114,   5.02925269e+114,   5.02925269e+114,
         5.02925269e+114])

If you do get an error like this is the future, the first thing to do is to check the dtype of the array being multiplied. Does it contain NumPy values or Python objects?

Cynthea

Good call! My array variable (y = np.square(np.add(np.divide(np.zeros(100),42),(-27)**40))as defined above in my question) has type 'object' (y.dtype) Unfortunately I am not sure I can force it to be a float, considering it starts as a float, and somewhere along the way casts itself to a long. – Mcspadden

It's the operation with (-27)**40 that's the problem. NumPy can't handle Python longs directly. However, you can use np.array to convert a NumPy array to another array of a different type. For example, np.array(np.array(27**40), dtype=np.float64) will return an array of type float64. – Cynthea

Yes I was able to find where the ints 27 and 40 were being generated in my code, and cast them as floats. For the record np.arange generates int32. Most numpy functions work in floats including np.ones and np.zeros – Mcspadden

Answer 2

Is this a quiz? I do not understand why the question is so obfuscated... Everything boils down to this simple fact.

Given

>>> x = 10**100
>>> type(x)
<type 'long'>
>>> y = np.float64(1)

we have

>>> y.__mul__(x)
1e+100
>>> y.__rmul__(x)
NotImplemented

This is the bug (or feature, I do not know) since it should be y.__mul__(x) == y.__rmul__(x) (at least for these particular values of x and y).

Python long does not know how to handle multiplication with numpy.float64 (but this is correct.)

>>> x.__mul__(y)
NotImplemented
>>> x.__rmul__(y)
NotImplemented

So y*x evaluates to y.__mul__(x) and gives the expected result. On the contrary x*y is first tried as x.__mul__(y) (not implemented, OK) than as y.__rmul__(x) (not implemented but a bug.).

As already pointed out, we can have nd.arrays of arbitrary objects, and everything becomes clear.

Edit

This bug has been corrected (probably in numpy ver. 1.7):

>>> np.version.version
'1.13.1'
>>> x = 10**100
>>> y = np.float64(1)
>>> x.__mul__(y)
NotImplemented
>>> x.__rmul__(y)
NotImplemented
>>> y.__mul__(x)
1e+100
>>> y.__rmul__(x)
1e+100
>>> x*y
1e+100
>>> y*x
1e+100

Rill

@Worthy7 No idea why my answer was downvoted: IMHO it pinpoints the numpy bug responsible for the unexpected behaviour, as confirmed by github.com/numpy/numpy/issues/2930#issuecomment-12445232 (and no, I didn't wrote my answer after reading that numpy issue.) – Rill