On 12/08/09 02:32, David Warde-Farley wrote:
On 7-Dec-09, at 11:13 PM, Dr. Phillip M. Feldman wrote:
Example #1: IPython 0.10 [on Py 2.5.4] [~]|1> z= zeros(3) [~]|2> z[0]= 1+1J
TypeError: can't convert complex to float; use abs(z)
The problem is that you're using Python's built-in complex type, and it responds to type coercion differently than NumPy types do. Calling float() on a Python complex will raise the exception. Calling float() on (for example) a numpy.complex64 will not. Notice what happens here:
In [14]: z = zeros(3)
In [15]: z[0] = complex64(1+1j)
In [16]: z[0] Out[16]: 1.0
Example #2:
### START OF CODE ### from numpy import * q = ones(2,dtype=complex)*(1 + 1J) r = zeros(2,dtype=float) r[:] = q print 'q = ',q print 'r = ',r ### END OF CODE ###
Here, both operands are NumPy arrays. NumPy is in complete control of the situation, and it's well documented what it will do.
I do agree that the behaviour in example #1 is mildly inconsistent, but such is the way with NumPy vs. Python scalars. They are mostly transparently intermingled, except when they're not.
At a minimum, this inconsistency needs to be cleared up. My preference would be that the programmer should have to explicitly downcast from complex to float, and that if he/she fails to do this, that an exception be triggered.
That would most likely break a *lot* of deployed code that depends on the implicit downcast behaviour. A less harmful solution (if a solution is warranted, which is for the Council of the Elders to decide) would be to treat the Python complex type as a special case, so that the .real attribute is accessed instead of trying to cast to float.
I'm not sure how much code is actually relying on the implicit downcast, but I'd argue that it's bad programming anyways. It is really difficult to spot if you reviewing someone else's code. As others mentioned it's also a bitch to track down a bug that has been accidentally introduced by this behaviour. Jochen