(in)exactness of complex numbers

[Steve Holden]

"David C. Ullrich" <ullrich at math.okstate.edu> wrote in message
news:3b695793.2250764 at nntp.sprynet.com...
> On Thu, 02 Aug 2001 09:28:05 +0200 (MET DST), Mikael Olofsson
> <mikael at isy.liu.se> wrote:
>
> >
> >On 01-Aug-2001 David C. Ullrich wrote:
> > >  (Not that it makes any difference here, but
> > >  since you undertstand the math so much better
> > >  than I do: Exactly what definition of
> > >  "complex number" do you have in mind here?
> > >  The _standard_ definition _is_ "pair of
> > >  real numbers".)
> >
> >I'd say it's not the standard definition, but rather the standard
> >representation.
>
> Well, it _is_ the _definition_ in many contexts. Honest.
>
> (_Not_ that I see what it _matters_ what "the" definition
> in mathematics is! The idea that that should be an
> important criterion in determining the way Python
> complexes should work seems silly.)
>
> > The complex field C is an extension of degree 2 of the
> >reals R (by the way, the only possible extension of R). To get a
> >representation of the complex field you need a root of an irreducible
> >polynomial over R. The standard representation uses the polynomial
> >x**2 + 1, and we usually call that root i or j. This means that we have
> >i**2 = -1. This choice is natural, since it gives the easiest rules for
> >arithmetic operations. However, you could use any other irreducible
> >polynomial over R, e.g. x**2 + x + 1. You still would use a pair of
> >reals to represent a complex number, but another pair than you would
> >have in the standard representation. And the arithmetic rules would
> >be different as well.
>
> Something like that could be very interesting, but surely the
> sort of thing that could not possibly belong in Python proper
> instead of some specialized module.
>
> >What I believe Greg is aiming at is that the complex numbers are more
> >than a pair of reals. A pair of reals is not a complex number unless
> >you specify the arithmetic rules of the pair.
>
> It's certainly true that a pair of reals is not exactly the same
> thing as a complex for exactly the reason you give. I don't see
> what bearing that has on how a Python complex should work (and
> hence it doesn't seem to me to be what he was getting at, since
> he was drawing conclusions about what Python complexes should
> be from statements about what the mathematical definition is.)
>
> >Now *I* would not mind to allow complex numbers with integers as
> >coefficients. That way I would get Gaussian integers without specifying
> >my own class for the purpose. _But_, I understand that very few would
> >have a need for that.
>
> Right. For possibly the seventh time: I was not making a request.
> Just pointing out that when someone says that the fact that
> floats should always be inexact _implies_ that complexes
> should always be inexact someone seemed to be misunderstanding
> someone else's point, which point appeared to me to be
> a request for exact or inexact complexes which was perfectly
> consistent with the idea that floats should always be inexact.
>
I seem to remember suggesting that complexes should be considered exact if
both the real and the imaginary coefficients were exact. Perhaps this is the
point to which you refer?

In response somebody else pointed out that this was not really suitable,
because of the multiplicity of representations in mathematical and
engineering work.

What has not so far been explicitly stated (although several posts have
implied it) is that complex numbers are in fact points on a two-dimensional
plane. If we choose to represent those points as distances along two
orthogonal axes then the concept of exactness might be said to have some
meaning for the points at the intersections of two integral values. But if
we choose to represent an "exact" complex number (by the previous
definition) in polar coordinates (angle & magnitude) then the same complex
number would become inexact. Even though there is a strict mathematical
relationship between polar and orthogonal representations (which is many to
one, BTW), the transformations would render exactness a less than useful
concept. A similarly "exact" polar representation would become inexact in
orthogonal representations.

Hence I now believe exactness is not useful for complex values. Not that it
couldn't be implemented if somebody perverse enough chose to. Simply that it
wouldn't be useful.

which-won't-stop-c.l.py-debating-it-ly y'rs  - steve
--
http://www.holdenweb.com/