10

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

Improve this question
7
  • 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... Commented Jan 18, 2013 at 22:21
  • 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? Commented Jan 18, 2013 at 22:23
  • If you replace x with x[...] it works, but it is a nasty hack... Commented Jan 18, 2013 at 22:25
  • 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). Commented Jan 18, 2013 at 22:30
  • 2
    Already got a response! Issue is corrected in numpy 1.7 (which will be released soon) github.com/numpy/numpy/issues/2930#issuecomment-12445232 Commented Jan 18, 2013 at 23:36

2 Answers 2

Reset to default
7

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?

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

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.
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.
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
1

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
Improve this answer

1 Comment

@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.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.