real and imag functions should produce errors for object arrays
Hi, The following example demonstrates a rather unexpected result:
import numpy x = numpy.array( complex( 1.0 , 1.0 ) , numpy.object ) print x.real (1+1j) print x.imag 0
Shouldn't real and imag return an error in such a situation? Thanks, Mike
On Tue, Sep 21, 2010 at 4:31 PM, Michael Gilbert < michael.s.gilbert@gmail.com> wrote:
Hi,
The following example demonstrates a rather unexpected result:
import numpy x = numpy.array( complex( 1.0 , 1.0 ) , numpy.object ) print x.real (1+1j) print x.imag 0
Shouldn't real and imag return an error in such a situation?
Thanks, Mike
Don't use 'numpy.object'. Because complex is a numerical type, numpy can handle it just fine. By setting dtype to numpy.object, numpy then treats it like an object rather than a numerical. x = numpy.array( complex(1.0, 1.0) ) should work just fine. I hope that helps! Ben Root
Hi, On Tue, Sep 21, 2010 at 2:44 PM, Benjamin Root <ben.root@ou.edu> wrote:
On Tue, Sep 21, 2010 at 4:31 PM, Michael Gilbert <michael.s.gilbert@gmail.com> wrote:
Hi,
The following example demonstrates a rather unexpected result:
import numpy x = numpy.array( complex( 1.0 , 1.0 ) , numpy.object ) print x.real (1+1j) print x.imag 0
Shouldn't real and imag return an error in such a situation?
It looks like there was a decision to let 'real' and 'imag' pass quietly for non-numerical types: In [2]: a = np.array('hello', dtype=object) In [3]: a.real Out[3]: array('hello', dtype=object) In [4]: a.imag Out[4]: array(0, dtype=object) and In [6]: a = np.array('hello', dtype='S5') In [7]: a.real Out[7]: array('hello', dtype='|S5') In [8]: a.imag Out[8]: array('', dtype='|S5') I can see that that could be confusing. I suppose the alternative would be to raise an error for real and imag for non-numerical types at least. Best, Matthew
On Tue, Sep 21, 2010 at 4:44 PM, Benjamin Root <ben.root@ou.edu> wrote:
On Tue, Sep 21, 2010 at 4:31 PM, Michael Gilbert < michael.s.gilbert@gmail.com> wrote:
Hi,
The following example demonstrates a rather unexpected result:
import numpy x = numpy.array( complex( 1.0 , 1.0 ) , numpy.object ) print x.real (1+1j) print x.imag 0
Shouldn't real and imag return an error in such a situation?
Thanks, Mike
Don't use 'numpy.object'. Because complex is a numerical type, numpy can handle it just fine. By setting dtype to numpy.object, numpy then treats it like an object rather than a numerical.
x = numpy.array( complex(1.0, 1.0) )
should work just fine.
I hope that helps! Ben Root
I see that I have interpreted this thread as "Doctor, it hurts when I do this... Well, don't do that!" Sorry for the noise. Ben Root
Hi,
I see that I have interpreted this thread as "Doctor, it hurts when I do this... Well, don't do that!" Sorry for the noise.
It's all good - a reply is almost always more friendly and helpful than no reply ;) See you, Matthew
Tue, 21 Sep 2010 17:31:55 -0400, Michael Gilbert wrote:
The following example demonstrates a rather unexpected result:
import numpy x = numpy.array( complex( 1.0 , 1.0 ) , numpy.object ) print x.real (1+1j) print x.imag 0
Shouldn't real and imag return an error in such a situation?
It probably shouldn't do *that* at the least. http://projects.scipy.org/numpy/ticket/1618 -- Pauli Virtanen
Tue, 21 Sep 2010 21:50:08 +0000, Pauli Virtanen wrote:
Tue, 21 Sep 2010 17:31:55 -0400, Michael Gilbert wrote:
The following example demonstrates a rather unexpected result:
import numpy x = numpy.array( complex( 1.0 , 1.0 ) , numpy.object ) print x.real (1+1j) print x.imag 0
Shouldn't real and imag return an error in such a situation?
It probably shouldn't do *that* at the least.
*that* == return a complex number from .real
On Tue, Sep 21, 2010 at 17:17, Pauli Virtanen <pav@iki.fi> wrote:
Tue, 21 Sep 2010 21:50:08 +0000, Pauli Virtanen wrote:
Tue, 21 Sep 2010 17:31:55 -0400, Michael Gilbert wrote:
The following example demonstrates a rather unexpected result:
import numpy x = numpy.array( complex( 1.0 , 1.0 ) , numpy.object ) print x.real (1+1j) print x.imag 0
Shouldn't real and imag return an error in such a situation?
It probably shouldn't do *that* at the least.
*that* == return a complex number from .real
What is the alternative? I'm personally happy with saying that many of the operations we define on numpy arrays can be done because we know the types and that object arrays subvert this. numpy can't, without excessive amounts of magic, always know a sensible thing to do with object arrays, so we implement the fast thing to do. -- 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
Hi, On Tue, Sep 21, 2010 at 3:28 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Tue, Sep 21, 2010 at 17:17, Pauli Virtanen <pav@iki.fi> wrote:
Tue, 21 Sep 2010 21:50:08 +0000, Pauli Virtanen wrote:
Tue, 21 Sep 2010 17:31:55 -0400, Michael Gilbert wrote:
The following example demonstrates a rather unexpected result:
> import numpy > x = numpy.array( complex( 1.0 , 1.0 ) , numpy.object ) print x.real (1+1j) > print x.imag 0
Shouldn't real and imag return an error in such a situation?
It probably shouldn't do *that* at the least.
*that* == return a complex number from .real
What is the alternative? I'm personally happy with saying that many of the operations we define on numpy arrays can be done because we know the types and that object arrays subvert this. numpy can't, without excessive amounts of magic, always know a sensible thing to do with object arrays, so we implement the fast thing to do.
I agree that special-casing object array .real to detect complex contents seems a bit messy, but it does make sense I think to raise an error from .real and .imag for non-numerical types. Best, Matthew
Tue, 21 Sep 2010 17:28:08 -0500, Robert Kern wrote: [clip]
*that* == return a complex number from .real
What is the alternative? I'm personally happy with saying that many of the operations we define on numpy arrays can be done because we know the types and that object arrays subvert this. numpy can't, without excessive amounts of magic, always know a sensible thing to do with object arrays, so we implement the fast thing to do.
As I see it, the alternatives are 1) Not to define .real and .imag for object arrays 2) Define them as elementwise .real and .imag I don't clearly see the reason for
x.real is x True x.imag array([0], dtype=object)
But it is a minor corner case, and there may be backward compatibility issues in changing it. -- Pauli Virtanen
On Tue, Sep 21, 2010 at 17:40, Pauli Virtanen <pav@iki.fi> wrote:
Tue, 21 Sep 2010 17:28:08 -0500, Robert Kern wrote: [clip]
*that* == return a complex number from .real
What is the alternative? I'm personally happy with saying that many of the operations we define on numpy arrays can be done because we know the types and that object arrays subvert this. numpy can't, without excessive amounts of magic, always know a sensible thing to do with object arrays, so we implement the fast thing to do.
As I see it, the alternatives are
1) Not to define .real and .imag for object arrays
2) Define them as elementwise .real and .imag
I don't clearly see the reason for
x.real is x True x.imag array([0], dtype=object)
The reason it is that way is probably because object and str dtypes were an afterthought when we extended .real and .imag to all dtypes. We used to only have those attributes on complex arrays. We added the behavior described above to all of the other dtypes to allow one to use the .real and .imag attributes regardless of whether the array was complex or real. I don't think we gave much thought to what the right thing to do with object arrays or str arrays. Perhaps we did think about it and decided that consistency with the other non-complex dtypes was more important than trying to expensively inspect the individual objects for .real and .imag attributes. -- 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
participants (5)
-
Benjamin Root -
Matthew Brett -
Michael Gilbert -
Pauli Virtanen -
Robert Kern