[Tutor] Floor and modulus for complex arguments

[Lie Ryan]

Angus Rodgers wrote:
> I'm a little confused by: (i) the definition of the modulus and
> floor division functions for complex arguments; (ii) the fact 
> that these functions for complex arguments are now "deprecated";
> and (iii) the fact that the math.floor() function is not defined
> at all for a complex argument.

maybe because math module is specifically designed NOT to support
complex number. For which cmath (complex math) is the appropriate
module. But even cmath doesn't have floor().

> 
> If I were thinking about this from scratch (in the context of
> mathematics, rather than any particular programming language),
> I /think/ I would be naturally inclined to define:
> 
>  floor(x + yj) = floor(x) + floor(y)j     for all real x, y
> 
>  z % w = z - floor(z / w) * w    for all complex z, w (!= 0)

I'm not a mathematician, and I understand zilch about complex numbers.
But looking literally at your definition, python 2.5 seems to define
complex mod complex as you have defined:

>>> import math
>>> def floor(comp):
...     return math.floor(comp.real) + math.floor(comp.imag) * 1j
...
>>> def mod(z, w):
...     return z - floor(z / w) * w
...
>>> mod(10.4j+5.1, 5.2j+3.2)
(1.8999999999999995+5.2000000000000002j)
>>> (10.4j+5.1) % (5.2j+3.2)
__main__:1: DeprecationWarning: complex divmod(), // and % are deprecated
(1.8999999999999995+5.2000000000000002j)


> These seem like they would be mathematically useful definitions
> (e.g. in algebraic number theory, where one has to find the
> "nearest" Gaussian integer multiple of one Gaussian integer to
> another - I forget the details, but it has something to do with
> norms and Euclidean domains), and I don't understand why Python
> doesn't do it this way, rather than first defining it a different
> way (whose mathematical usefulness is not immediately apparent
> to me) and then "deprecating" the whole thing!  It seems like
> a wasted opportunity - but am I missing something?
> 
> Has there been heated debate about this (e.g. in the context
> of Python 3, where the change to the division operator has 
> apparently already provoked heated debate)?

There is this:
http://mail.python.org/pipermail/python-dev/2002-April/023251.html
http://mail.python.org/pipermail/python-dev/2002-April/023259.html

and the justification seems to be related to the grand unified numeric
type. Apparently this is the reason given:

"""
Update of /cvsroot/python/python/dist/src/Objects
In directory usw-pr-cvs1:/tmp/cvs-serv7877

Modified Files:
	complexobject.c
Log Message:
SF bug #543387.

Complex numbers implement divmod() and //, neither of which makes one
lick of sense.  Unfortunately this is documented, so I'm adding a
deprecation warning now, so we can delete this silliness, oh, around
2005 or so.

Bugfix candidate (At least for 2.2.2, I think.)
"""

> Also, by the way, is there some obvious reason for Python's use
> of the notation x + yj, rather than the more standard (except
> perhaps among electrical engineers) x + yi?

I'm not a mathematician, and I understand little about complex numbers.
But it seems the reason is because when the decision was made, nobody in
the devteam understand the reasoning behind complex numbers implementing
the divmod, //, and % as such, and caused it to be removed due to being
"makes no sense". Perhaps if you can convince the devteam about the math
behind complex mod complex, this feature can be reintroduced. FWIW it
has been 5+ years and nobody seems to complain before, it seems complex
mod complex must have been very rarely used.