(in)exactness of complex numbers

[David C. Ullrich]

On Wed, 01 Aug 2001 23:17:52 GMT, bokr at accessone.com (Bengt Richter)
wrote:

>On Wed, 01 Aug 2001 13:32:52 GMT, ullrich at math.okstate.edu (David C. Ullrich) wrote:
>
>>On Wed, 01 Aug 2001 14:45:14 +1200, Greg Ewing
>><greg at cosc.canterbury.ac.nz> wrote:
>>
>>>"David C. Ullrich" wrote:
>>>> 
>>>> But why should the real and imag of a complex be required to be
>>>> floats in the first place? Why  shouldn't they be allowed to be
>>>> floats or rationals or integers?
>>>
>>>A complex number, in the mathematical sense, is 
>>>not a pair of other numbers -- that's just one 
>>>way of *representing* a complex number.
>>
>>Well thanks for clarifying _that_. Duh.
>>
>>(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".)
>>
>Well, he *is* trying to pay attention to representation issues,
>which I think is good ;-) 

Paying attention to representation issues may very well be
a good thing, depending on the context. That's not the
same thing as saying that what the mathematical definition
of a complex number is should have a bearing on how complexes
should work in Python - that seems just silly. (The idea that
the "correct" mathematical definition should be an important
factor seems silly to me regardless of what the definition
actually is. I am curious what definition he has in mind
other than "pair of real numbers". Another mathematical
definition would be "element of the algebraic completion
of R", but _that's_ certainly not a definition we want
to use as a basis for the internal representation or
a basis for how the interface should work. And I can't
think of a third definition this morning...)

>but it sounded like the horse wasn't
>quite hitched right, the way I read it.
>[...]
>
>It looks to me like the problem is that the Python internal representation
>in C of complex actually *is* two doubles, not two python numbers.
>
>Probably because for using external libraries it makes it a lot faster if you
>don't first have to convert Python's numeric objects and make a pair
>of doubles -- especially since you probably always get doubles back.
>
>I don't think there is there's any reason you *couldn't*
>use general numbers (excluding complex ;-) as the real and imag parts.
>I'm guessing it would just be a lot of mostly boring rework programming
>and there's hotter things now for the internals people 

"Well of course" to all of that. I think this is the fourth time
I've said that I'm not actually suggesting that complexes be
changed this way.

But people at present _are_ talking about all sorts of major changes
to the way numberic types work, and most of those changes sound
like they will require revisions to the internal representation,
and revisions that don't sound like they're going to speed things
up.

>(of which I'm not one,
>in case the thought occurred. Not that I wouldn't like to be at some point ;-).
>The trick would be to preserve speed and still get generality. I think it
>could be done, but is that where you want to allocate the people who both
>can and are in a position to do that?

Of course that's not where I would allocate those resources.

_In_ a context where people _are_ talking about making some
types (or possibly values) officially exact and some 
officially inexact the question of how complexes should
work seems like a reasonable question. Someone said they
should go ether way, someone else said that they should
be exact because floats should always be exact. The
fact that floats should always be exact does not imply
that complexes should always be exact _unless_ we've 
already decided that when we change how everything else
works we're not going to change the internal representation
of complexes. Seemed worth pointing this out. Preserving
speed would be nice, but it doesn't sound like that's
being taken as the primary consideration in the other
revisions being proposed. The bit about allocating
programmer resources is exactly why I keep saying that
this is not an actual request _until_ the point at
which they give up and start giving everybody their own
version of Python.

>Anyway, the abstract aspects of things are more interesting.
>At least until I'm hungry ;-)
>
>from complexobject.h:
>
>typedef struct {
>    double real;
>    double imag;
>} Py_complex;
>...
>/*
>PyComplexObject represents a complex number with double-precision
>real and imaginary parts.
>*/
>
>typedef struct {
>    PyObject_HEAD
>    Py_complex cval;
>} PyComplexObject;     

I've never used NumPY much. My impression is that NumPY
arrays are somehow rigged so manipulating an array of floats
is very fast but you can also have an array of any sort
of Python object which can be manipulated through the
same interface, just slower because the array elements
are being handled at a different level. In spite of the
extreme generality I gather that nobody has complaints
with the speed of arrays of floats.

I guess that's just NumPY arrays, couldn't be done
with complexes. Because, um, well I'm not a 
professional programmer so I can't quite see why
doing complexes this way would be harder than
arrays.




David C. Ullrich