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.html
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.
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
