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. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
