On Mon, Feb 4, 2008 at 11:59 AM, Stuart Brorson <[EMAIL PROTECTED]> 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. -- . __ . |-\ . . [EMAIL PROTECTED]
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
