Re: [Numpy-discussion] numpy.complex
On Monday, July 23, 2012, OC wrote: It's unPythonic just in the sense that it is unlike every other type constructor in Python. int(x) returns an int, list(x) returns a list, but np.complex64(x) sometimes returns a np.complex64, and sometimes it returns a np.ndarray, depending on what 'x' is. This object factory design pattern adds useful and natural functionality. I can see an argument for deprecating this behaviour altogether and referring people to the np.asarray(x, dtype=complex) form; that would be cleaner and reduce confusion. Don't know if it's worth it, but that's the only cleanup that I can see even being considered for these constructors. From my experience in teaching, I can tell that even beginners have no problem with the fact that complex128(1) returns a scalar and that complex128(r_[1]) returns an array. It seems to be pretty natural. Also, from the duck-typing point of view, both returned values are complex, i.e. provide 'real' and 'imag' attributes and 'conjugate()' method. On the contrary a real confusion is with numpy.complex acting differently than the other numpy.complex*. People do write from numpy import * Yeah, that's what I do very often in interactive ipython sessions. Other than this, people are warned often enough that this shouldn't be used in real programs. Don't be so sure of that. The pylab mode from matplotlib has been both a blessing and a curse. This mode is very popular and for many, it is all they need/want to know. While it has made the transition from other languages easier for many, the polluted namespace comes at a small cost. And it is only going to get worse when moving over to py3k where just about everything is a generator. __builtin__.any can handle generators, but np.any does not. Same goes for several other functions. Note, I do agree with you that the discrepancy needs to be fixed, I just am not sure which way. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex
On Sat, Jul 21, 2012 at 4:44 PM, OC oc-spa...@laposte.net wrote: Thank you for your answers. Chris Barker wrote: for consistency with the rest of the numpy types Then, why do numpy.complex64(A), numpy.complex128(A), numpy.uint8(A),... all work with arrays? It's very convenient that it works like this! It's awkward that numpy.complex(A) is the only one that does not. Is there a problem to extend numpy.complex so that it acts the same as numpy.complex64? Pauli Virtanen wrote: Remember that numpy.complex, numpy.complex64 (...) are types that represent scalar numbers, not arrays. (...) That you get an array out from numpy.complex64(A) rather than a ValueError is un-Pythonic. Thanks for pointing this out. I don't see why it would be un-pythonic, and on the contrary this behavior is useful. Why shouldn't a type object offer such useful method/constructor? Is there a design mistake here? (from the Python point of view, not from the C++ point of view). It's unPythonic just in the sense that it is unlike every other type constructor in Python. int(x) returns an int, list(x) returns a list, but np.complex64(x) sometimes returns a np.complex64, and sometimes it returns a np.ndarray, depending on what 'x' is. I can see an argument for deprecating this behaviour altogether and referring people to the np.asarray(x, dtype=complex) form; that would be cleaner and reduce confusion. Don't know if it's worth it, but that's the only cleanup that I can see even being considered for these constructors. All the types you mention inherit from numpy.generic, except numpy.complex. Is there a reason for this? I find it awkward and misleading. I understand that numpy.real and numpy.complex are different things from a programmer's point of view, the first being a function and the latter being a type. However, from the syntax point of view, I think that an average user is founded to believe that they behave similarly with arrays. And such an improvement seems to be easy. For example, why isn't numpy.complex simply equal to numpy.complex_ instead of __builtin__.complex? Note: same remark for numpy.bool and numpy.bool_ There's also np.int/np.int_ and np.float/np.float_. It's considered poor form to have variables names that clash with builtins. People do write from numpy import *, and it would be very bad if that overwrote basic builtins like int/float/bool. I'd probably have just had np.int_ be what it is, and np.int be undefined. But hindsight is 20/20 and all that; it's a bit late to do anything about it now. (I suppose there probably aren't many people who depend on np.int, and the ones who do are probably confused, so maybe that is a good argument for deprecating the builtin aliases. But it's very difficult to deprecate exports, so I guess this will probably never happen.) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex
On Fri, Jul 20, 2012 at 1:17 PM, OC oc-spa...@laposte.net wrote: numpy.complex is just a reference to the built in complex, so only works on scalars: What is the use of storing the complex() built-in function in the numpy namespace, when it is already accessible from everywhere? for consitancy with teh rest of the numpy types. When I create a numpy array, I might do: np.zeros( (3,4), dtype=np.float32 ) so for the numpy types that have a direct relationship with the python types, we put the type in the numpy namespace as well. But, since in numpy, you generally really want to control your types closely, Id tend to use: np.zeros( (3,4), dtype=np.complex128 ) (or np.complex64) anyway. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex
20.07.2012 22:17, OC kirjoitti: The syntax numpy.complex(A) seems to be the most natural and obvious thing a user would want for casting an array A to complex values. I think I disagree here -- that something like that works at all is rather surprising. Remember that numpy.complex, complex64, complex128, float64, ... et al. are types that represent scalar numbers, not arrays. That you get an array out from `float64(some_array)` rather than a ValueError is un-Pythonic. Happens to work, but probably for the wrong reasons. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex
On Wed, 2012-07-18 at 15:14 +0200, Molinaro Céline wrote: In [2]: numpy.real(arange(3)) Out[2]: array([0, 1, 2]) In [3]: numpy.complex(arange(3)) TypeError: only length-1 arrays can be converted to Python scalars Are there any reasons why numpy.complex doesn't work on arrays? Should it be bug reported? numpy.complex is just a reference to the built in complex, so only works on scalars: In [5]: numpy.complex is complex Out[5]: True Try numpy.complex128 (or another numpy.complexN, with N being the bit length). Henry ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex
On 18 July 2012 15:14, Molinaro Céline celine.molin...@telecom-bretagne.eu wrote: Hello, In [2]: numpy.real(arange(3)) Out[2]: array([0, 1, 2]) In [3]: numpy.complex(arange(3)) TypeError: only length-1 arrays can be converted to Python scalars I think you're looking for the dtype keyword to the ndarray constructor: import numpy as np np.arange(3, dtype=np.complex) Out[2]: array([ 0.+0.j, 1.+0.j, 2.+0.j]) or if you have an existing array to cast: np.asarray(np.arange(3), dtype=np.complex) Out[3]: array([ 0.+0.j, 1.+0.j, 2.+0.j]) You can get the real and imaginary components of your complex array like so: a = np.arange(3, dtype=np.complex) a Out[9]: array([ 0.+0.j, 1.+0.j, 2.+0.j]) a.real Out[10]: array([ 0., 1., 2.]) a.imag Out[11]: array([ 0., 0., 0.]) Cheers, Scott ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex* functions do not call the __complex__ method
[EMAIL PROTECTED] wrote: In creating an array of type numpy.complex128, I'm having problems passing in Sage types that should be considered complex numbers since they implement the standard __complex__ method. However, numpy doesn't recognize that. Here's a minimal example: I had tried to add my own complex_int class (using c++ code). Although partly successful, I was not able to get x.real to work. The reason is that PyArray_ISCOMPLEX is used in various places, and this is a hard-coded macro. There is no way to extend numpy's complex behavior to support user added types. I wish there was. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex* functions do not call the __complex__ method
Neal Becker wrote: [EMAIL PROTECTED] wrote: In creating an array of type numpy.complex128, I'm having problems passing in Sage types that should be considered complex numbers since they implement the standard __complex__ method. However, numpy doesn't recognize that. Here's a minimal example: I had tried to add my own complex_int class (using c++ code). Although partly successful, I was not able to get x.real to work. The reason is that PyArray_ISCOMPLEX is used in various places, and this is a hard-coded macro. There is no way to extend numpy's complex behavior to support user added types. I wish there was. Is there any possibility of redefining the macro to first call the Python function that converts to a python complex? (I don't know much about the python C API, just throwing an idea out). My example works if I do: numpy.complex128(complex(my_complex_number)), but not if I do numpy.complex128(my_complex_number). Can we make the call to python's complex (or maybe numpy's copy of it) automatic? Thanks, Jason ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
