round, fix, ceil, and floor for complex args
Hi -- I'm fiddling with NumPy's chopping and truncating operators: round, fix, ceil, and floor. In the case where they are passed real args, they work just fine. However, I find that when they are passed complex args, I get the following: round -> works fine. ceil -> throws exception: 'complex' object has no attribute 'ceil' floor -> throws exception: 'complex' object has no attribute 'floor' fix -> throws exception: 'complex' object has no attribute 'floor' Please see the session log below for more details. My question: Is this a bug or a feature? It seems to me that if you implement round for complex args, then you need to also support ceil, floor, and fix for complex args, so it's a bug. But I thought I'd ask the developers what they thought before filing a ticket. Regards, Stuart Brorson Interactive Supercomputing, inc. 135 Beaver Street | Waltham | MA | 02452 | USA http://www.interactivesupercomputing.com/ -------------------------- <session log> ------------------- In [14]: import numpy In [15]: A = 10*numpy.random.rand(2, 2) + 10j*numpy.random.rand(2, 2) In [16]: numpy.round(A) Out[16]: array([[ 6.+8.j, 6.+5.j], [ 10.+6.j, 9.+9.j]]) In [17]: numpy.floor(A) --------------------------------------------------------------------------- <type 'exceptions.AttributeError'> Traceback (most recent call last) /fs/home/sdb/<ipython console> in <module>() <type 'exceptions.AttributeError'>: 'complex' object has no attribute 'floor' In [18]: numpy.ceil(A) --------------------------------------------------------------------------- <type 'exceptions.AttributeError'> Traceback (most recent call last) /fs/home/sdb/<ipython console> in <module>() <type 'exceptions.AttributeError'>: 'complex' object has no attribute 'ceil' In [19]: numpy.fix(A) --------------------------------------------------------------------------- <type 'exceptions.AttributeError'> Traceback (most recent call last) /fs/home/sdb/<ipython console> in <module>() /home/sdb/trunk/output/ia32_linux/python/lib/python2.5/site-packages/numpy/lib/ufunclike.py in fix(x, y) 14 x = asanyarray(x) 15 if y is None: ---> 16 y = nx.floor(x) 17 else: 18 nx.floor(x, y) <type 'exceptions.AttributeError'>: 'complex' object has no attribute 'floor' In [20]: numpy.__version__ Out[20]: '1.0.4' In [21]: ---------------------------- </session log> -------------------
On Mon, Feb 4, 2008 at 10:34 AM, Stuart Brorson <sdb@cloud9.net> wrote:
Hi --
I'm fiddling with NumPy's chopping and truncating operators: round, fix, ceil, and floor. In the case where they are passed real args, they work just fine. However, I find that when they are passed complex args, I get the following:
round -> works fine. ceil -> throws exception: 'complex' object has no attribute 'ceil' floor -> throws exception: 'complex' object has no attribute 'floor' fix -> throws exception: 'complex' object has no attribute 'floor'
Please see the session log below for more details.
My question: Is this a bug or a feature? It seems to me that if you implement round for complex args, then you need to also support ceil, floor, and fix for complex args, so it's a bug. But I thought I'd ask the developers what they thought before filing a ticket.
IMO, the problem is not that ceil, floor and fix are not defined for complex, but rather that round is. (Re, Im) is not a unique representation for complex numbers, although that is the internal representation that numpy uses, and as a result none of these functions are uniquely defined. Since it's trivial to synthesize the effect that I assume you are looking for (operating on both the Re and Im parts as if the were floats), there's no reason to have this functionality built in. [....examples....] -- . __ . |-\ . . tim.hochberg@ieee.org
round -> works fine. ceil -> throws exception: 'complex' object has no attribute 'ceil' floor -> throws exception: 'complex' object has no attribute 'floor' fix -> throws exception: 'complex' object has no attribute 'floor'
My question: Is this a bug or a feature? It seems to me that if you implement round for complex args, then you need to also support ceil, floor, and fix for complex args, so it's a bug. But I thought I'd ask the developers what they thought before filing a ticket.
IMO, the problem is not that ceil, floor and fix are not defined for complex, but rather that round is. (Re, Im) is not a unique representation for complex numbers, although that is the internal representation that numpy uses, and as a result none of these functions are uniquely defined. Since it's trivial to synthesize the effect that I assume you are looking for (operating on both the Re and Im parts as if the were floats), there's no reason to have this functionality built in.
What you say is reasonable prima face. However, looking deeper, NumPy *already* treats complex numbers using the (Re, Im) representation when implementing ordering operators. That is, if I do "A <= B", then NumPy first checks the real parts, and if it can't fully decide, then it checks the imaginary parts. That is, the (Re, Im) representation already excludes other ways in which you might define ordering operations for complex numbers. BTW: I have whined about this behavior several times, including here [1]: http://projects.scipy.org/pipermail/numpy-discussion/2008-January/031056.htm... Anyway, since NumPy is committed to (Re, Im) as the base representation of complex numbers, then it is not unreasonable to implement round, fix, and so on, by operating independently on the Re and Im parts. Or am I wrong? Cheers, Stuart Brorson Interactive Supercomputing, inc. 135 Beaver Street | Waltham | MA | 02452 | USA http://www.interactivesupercomputing.com/ [1] Sorry for whining, by the way! I'm just poking at the boundaries of NumPy's feature envelope and trying to see how self-consistent it is.
On Mon, Feb 4, 2008 at 11:59 AM, Stuart Brorson <sdb@cloud9.net> wrote:
round -> works fine. ceil -> throws exception: 'complex' object has no attribute 'ceil' floor -> throws exception: 'complex' object has no attribute 'floor' fix -> throws exception: 'complex' object has no attribute 'floor'
My question: Is this a bug or a feature? It seems to me that if you implement round for complex args, then you need to also support ceil, floor, and fix for complex args, so it's a bug. But I thought I'd ask the developers what they thought before filing a ticket.
IMO, the problem is not that ceil, floor and fix are not defined for complex, but rather that round is. (Re, Im) is not a unique representation for complex numbers, although that is the internal representation that numpy uses, and as a result none of these functions are uniquely defined. Since it's trivial to synthesize the effect that I assume you are looking for (operating on both the Re and Im parts as if the were floats), there's no reason to have this functionality built in.
What you say is reasonable prima face.
However, looking deeper, NumPy *already* treats complex numbers using the (Re, Im) representation when implementing ordering operators. That is, if I do "A <= B", then NumPy first checks the real parts, and if it can't fully decide, then it checks the imaginary parts. That is, the (Re, Im) representation already excludes other ways in which you might define ordering operations for complex numbers.
BTW: I have whined about this behavior several times, including here [1]:
http://projects.scipy.org/pipermail/numpy-discussion/2008-January/031056.htm...
I agree with this, FWIW. Ordering comparisons between complex numbers should raise an exception.
Anyway, since NumPy is committed to (Re, Im) as the base representation of complex numbers, then it is not unreasonable to implement round, fix, and so on, by operating independently on the Re and Im parts.
IMO, just because numpy has a certain wart is no reason to push for adding a bunch of vaguely similar warts just to make things more consistent. Better to try to remove the initial wart if the opportunity presents itself. The more the (Re, Im) representation leaks, the harder it will become to ever fix. And, in this case at least, full consistency is not possible short of removing the ordered comparison of complex numbers, since the Python complex type does not support ordered comparisons. -- . __ . |-\ . . tim.hochberg@ieee.org
Stuart Brorson wrote:
Anyway, since NumPy is committed to (Re, Im) as the base representation of complex numbers, then it is not unreasonable to implement round, fix, and so on, by operating independently on the Re and Im parts.
Or am I wrong?
Sounds reasonable to me... -Travis O.
On Feb 4, 2008 10:34 AM, Stuart Brorson <sdb@cloud9.net> wrote:
Hi --
I'm fiddling with NumPy's chopping and truncating operators: round, fix, ceil, and floor. In the case where they are passed real args, they work just fine. However, I find that when they are passed complex args, I get the following:
round -> works fine. ceil -> throws exception: 'complex' object has no attribute 'ceil' floor -> throws exception: 'complex' object has no attribute 'floor' fix -> throws exception: 'complex' object has no attribute 'floor'
Please see the session log below for more details.
My question: Is this a bug or a feature? It seems to me that if you implement round for complex args, then you need to also support ceil, floor, and fix for complex args, so it's a bug. But I thought I'd ask the developers what they thought before filing a ticket.
Regards,
I think it would be reasonable to add these operations for consistency. Useful is perhaps a different question. Chuck
participants (4)
-
Charles R Harris -
Stuart Brorson -
Timothy Hochberg -
Travis E. Oliphant