Should this work? Python 2.4.3 (#1, Dec 27 2006, 21:18:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import numpy as N N.__version__ '1.0.2.dev3531' N.arange(1j, 5j) array([], dtype=complex128) N.arange(1j, 5j, 1j) array([], dtype=complex128)
Currently, the real direction is determined to be of zero length (multiarraymodule.c _calc_length), and the length of the array is the minimal length. I can understand the first one not working (default step is 1, it takes 0 of those to cover this range), but the second seems like a bug.
Russel Howe wrote: (It's good to see so many Rudds seeing sense and using Python and numpy. ;-))
Should this work?
Python 2.4.3 (#1, Dec 27 2006, 21:18:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import numpy as N N.__version__ '1.0.2.dev3531' N.arange(1j, 5j) array([], dtype=complex128) N.arange(1j, 5j, 1j) array([], dtype=complex128)
Currently, the real direction is determined to be of zero length (multiarraymodule.c _calc_length), and the length of the array is the minimal length. I can understand the first one not working (default step is 1, it takes 0 of those to cover this range), but the second seems like a bug.
arange() is pretty much only defined for real numbers. For general z0, z1, and dz, there is no guarantee that (z1 - z0)/dz is a real number as it needs to be. dz may point in a different direction than (z1-z0). For example, what should arange(1j, 5j, 1) do? Numeric raises an exception here, and I thing numpy should, too. Of course, linspace() is generally preferred for floating point types regardless of whether complex or real. It's difficult to predetermine whether the stop value will be included or not. And since you give it a count instead of a step size, we can guarantee that the step does lie along the vector (z1-z0). In [8]: linspace(1j, 5j, 5) Out[8]: array([ 0.+1.j, 0.+2.j, 0.+3.j, 0.+4.j, 0.+5.j]) -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
arange(1j, 5j, 1) do? Numeric raises an exception here, and I thing numpy should, too.
The same as arange(1, 5, 1j) - an empty array since it takes 0 of the step to cross the distance. But something like arange(1j, 5j, 1j) seems fine. As does arange(1j, 3+5j, 2+1j) which should give [ 1j, 2+2j ]. The idea is to walk by step up to the edge of the box. I seem to recall a discussion of why this was a bad idea a while ago on this list, but I can't find it... The exception is a good answer too, but it should probably happen for all complex arguments, since most seem to return an empty array now. Russel they're all fine hovses.
Russel Howe wrote:
arange(1j, 5j, 1) do? Numeric raises an exception here, and I thing numpy should, too.
The same as arange(1, 5, 1j) - an empty array since it takes 0 of the step to cross the distance.
I'm not sure that's really the answer. I think it's simply not defined. No number of steps (which is different than 0 steps) along the imaginary axis will take 1+0j to 5+0j.
But something like arange(1j, 5j, 1j) seems fine. As does arange(1j, 3+5j, 2+1j) which should give [ 1j, 2+2j ]. The idea is to walk by step up to the edge of the box. I seem to recall a discussion of why this was a bad idea a while ago on this list, but I can't find it...
Box? *Aaah*! You're looking at z1 placing distinct upper(lower) bounds on the real and imaginary parts rather than specifying a point target. That's a...unique perspective. ;-) But then, I'm of the opinion that arange() should be reserved for integers, and the other use cases are better served by linspace() instead. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
I think arange for complex numbers should work like meshgrid, with the real and imaginary axis replacing the x and y axis. That would mean something like this: def complex_arange(start,end,stride): def iscomplex(x): if ((type(x)==complex) or (type(x)==complex64) or (type(x)==complex128)): return True else: return False if iscomplex(start) or iscomplex(end) or iscomplex(stride): start = complex(start) end = complex(end) stride = complex(stride) ar = arange(start.real, end.real, stride.real) ai = arange(start.imag ,end.imag, stride.imag) rr,ri = meshgrid(ar,ai) tmp = rr + 1j*ri if tmp.shape[0] == 1 or tmp.shape[1] == 1: tmp = tmp.flatten() return tmp else: return arange(start,end,stride) I think this is a reasonable extension of arange to complex numbers. Here complex_arange(1j, 5j, 1) throws a ZeroDivisionError as the stride for the imaginary part i 0. Observe that complex_arange(1j, 5j, 1j) throws an exception as well, as the extent of the real part is arange(0,0,0). But complex_arange(0+1j,1+5j,1+1j) does exist, and so does complex_arange(0+1j,0+5j,1+1j). But in the case of complex_arange(0+1j,0+5j,1+1j) the return value is an empty array, as the extent along the real axis is 0. Regards, Sturla Molden
participants (4)
-
Robert Kern -
Russel Howe -
Sturla Molden -
Timothy Hochberg