[Numpy-discussion] round, fix, ceil, and floor for complex args
Timothy Hochberg
tim.hochberg@ieee....
Mon Feb 4 13:25:24 CST 2008
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.html
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080204/b499da5e/attachment.html
More information about the Numpy-discussion
mailing list