9

When multiplying a numpy float with a list, the float is automatically cast to int

>>> import numpy as np
>>> a = [1, 2, 3]
>>> np.float64(2.0) * a ### This behaves as 2 * a
[1, 2, 3, 1, 2, 3]

A normal float gives a TypeError

>>> 2.0 * a ### This does not
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't multiply sequence by non-int of type 'float'

However, the numpy float cannot be used for indexing

>>> a[np.float64(2.0)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not numpy.float64

What is the logic behind this behaviour?

wernere
  • 103
  • 5
  • So do you want to know why the float becomes a int or do you want to know the logic behind all of this? – Anthony Pham Dec 25 '14 at 15:24
  • @PythonMaster I want to know why the float64 differs from the float, and why it is cast to int in the first example but not in the third. – wernere Dec 25 '14 at 15:27
  • I can't seem to understand the question(s) you are asking at all. – Anthony Pham Dec 25 '14 at 15:35
  • I would say it is a valid question. Why does numpy.float64 behave like an integer in the first case? – Christian K. Dec 25 '14 at 15:51
  • 3
    The question is why, for example, `np.float64(2.0)*[1,2,3]` does not have the same behavior as `2.0*[1,2,3]`. – Warren Weckesser Dec 25 '14 at 15:51
  • @WarrenWeckesser, considering one example uses a numpy object and the other does not would be the main reason, if you use `2.0* np.array([1,2,3])` that will also return a value – Padraic Cunningham Dec 25 '14 at 16:15
  • 2
    See also [this question](http://stackoverflow.com/q/26690480/2647279), where a bug in a beginner's program was caused by the same weird behavior you observed. I consider this a bug in Numpy. I [reported this](http://mail.scipy.org/pipermail/numpy-discussion/2014-November/071635.html) on the Numpy mailing list, but got no response. – Bas Swinckels Dec 25 '14 at 16:21
  • @PadraicCunningham: I'm not the one asking the question. :) I was just clarifying the question for the other commenters. If you have an answer, why not create a real answer for @wernere? – Warren Weckesser Dec 25 '14 at 16:24
  • @WarrenWeckesser , the question title is *Why is float64 cast to int when multiplying with a list* I cannot see that anywhere in the question so I don't fully get the question – Padraic Cunningham Dec 25 '14 at 16:27
  • @wernere, where are the ints? – Padraic Cunningham Dec 25 '14 at 16:35
  • @WarrenWeckesser Thanks for your clearer statement of the question. I've edited the original question now. – wernere Dec 25 '14 at 17:16
  • @PadraicCunningham In the first example, `np.float64(2.0)` behaves like `2`, whereas `2.0` does not. – wernere Dec 25 '14 at 17:18
  • @BasSwinckels Yes, I agree that returning an error would have been more helpful. Or converting the list to a numpy array (which was my original expectation). I was wondering whether there was some underlying logic which I was missing. – wernere Dec 25 '14 at 17:28
  • @wernere, is there reason you would want to multiply a python list by a numpy float? – Padraic Cunningham Dec 25 '14 at 19:02
  • @PadraicCunningham Just as in [the linked question](http://stackoverflow.com/questions/26690480/matplotlib-valueerror-x-and-y-must-have-same-first-dimension?lq=1), I wanted to generate a numpy array containing all elements of a list, multiplied by a common factor. I expected that this method would either work directly or return an error. Now I want to understand the reason why it instead treated the numpy float as an integer. – wernere Dec 25 '14 at 23:44
  • @wernere, so this is a duplicate of the linked question? – Padraic Cunningham Dec 25 '14 at 23:48
  • @PadraicCunningham The question is different, but the answer is the same. I don't think it is a duplicate, but since I'm new here, I don't really know what counts as a duplicate question. – wernere Dec 25 '14 at 23:51
  • @BasSwinckels If you'd turn your comment into an answer, I'd accept it. – wernere Dec 26 '14 at 20:55

1 Answers1

3

You've hit up against a known bug in NumPy. The GitHub issue was closed last year, but the behavior remains in NumPy version 1.9.1.

Andrew
  • 743
  • 6
  • 17