(in)exactness of complex numbers

[David C. Ullrich]

On Thu, 2 Aug 2001 11:55:02 -0400, "Steve Holden"
<sholden at holdenweb.com> wrote:

>"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?

Seems likely.

>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.

Hasn't been explicitly stated except by my, you mean. (Ok, maybe
"explicit" is too strong. But when I say something about exact
real and imag, and then I change that and say oh wait, actually
what would be interesting would be exact arg, it seems kinda
clear that I'm saying the two are not the same...)

>Hence I now believe exactness is not useful for complex values.

I never said it would be "useful", and never asked for it.
One point to my saying "oh wait, actually exact arg would
be more interesting" was precisely to point out that the
notion of exactness is not a priori well-defined for 
complexes; they can be exact in one coordinate system
but not in another. (Yes, _this_ point was only implicit.)

> 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/
>
>
>
>
>


David C. Ullrich