Gauging Interest: polar_complex
I wanted to gauge whether there might be interest in a class for complex numbers with data stored in polar form. For some applications, polar complex numbers have significant advantages over Cartesian complex (e.g., std::complex) in efficiency and numerical accuracy. (I spent some time Googling and, somewhat to my surprise, didn't find any freely available versions of this.) I have a fairly well developed class that implements this; "boosting" it to be worthy of consideration would probably be straight-forward but non-trivial. My version of this is of course templated on the contained numeric type. It is also uses a policy-based design that determines whether or not the polar angle phi is always maintained in principal form or not and what constitutes principal form (default: no, -pi < phi <= pi). Thanks, Mickey Moore ---------------------------------------- Mitchell G. (Mickey) Moore, Ph.D. mgmoore@austin.rr.com
Mickey Moore wrote:
For some applications, polar complex numbers have significant advantages over Cartesian complex (e.g., std::complex) in efficiency and numerical accuracy.
Just out of curiosity: Can you give me an example of an algorithm where this would be of advantage? Roland
Somewhere in the E.U., le 23/11/2004 Bonjour In article <41A1D3A7.70609@chello.at>, Roland Schwarz <roland.schwarz@chello.at> wrote:
Mickey Moore wrote:
For some applications, polar complex numbers have significant advantages over Cartesian complex (e.g., std::complex) in efficiency and numerical accuracy.
Just out of curiosity: Can you give me an example of an algorithm where this would be of advantage?
Roland
It is interesting if, for instance, you have to track an object along an orbit for a very long time. Using the canonical ("cartesian") representation usually entails transcendental functions (say sine and cosine), for which it is very hard to guaranty the accuracy (of a given, one-size-fits-all, implementation) for big values of the argument. If you integrate numerically, you all the more want to stay in the polar domain (unless we cross the singularity, but we are not modeling missiles, are we ;-) ? ). Merci Hubert Holin
On Tue, 23 Nov 2004 10:55:19 +0100, Hubert Holin <hubert.holin@meteo.fr> wrote:
Just out of curiosity: Can you give me an example of an algorithm where this would be of advantage?
Roland
It is interesting if, for instance, you have to track an object along an orbit for a very long time. Using the canonical ("cartesian") representation usually entails transcendental functions (say sine and cosine), for which it is very hard to guaranty the accuracy (of a given, one-size-fits-all, implementation) for big values of the argument. If you integrate numerically, you all the more want to stay in the polar domain (unless we cross the singularity, but we are not modeling missiles, are we ;-) ? ).
I'm sure you'd want to use polar coordinates for that, yes. There are of problems for which you want to use polar coordinates of some sort or another. But is it likely that you would want to use a package that provides complex numbers in polar form? My experience is that if you're working with complex numbers that you want to think of in the form r exp(i phi), then you'll probably just do the work of separating out the magnitude and phase ahead of time in your equations, and then compute with them separately. After all: if you're doing something where the magnitude-phase form is most convenient, it usually means that putting numbers in that form makes the equations simpler. --Matt
Somewhere in the E.U., le 26/11/2004 In article <98604e9d041123112135c8caae@mail.gmail.com>, Matt Austern <austern@gmail.com> wrote:
On Tue, 23 Nov 2004 10:55:19 +0100, Hubert Holin <hubert.holin@meteo.fr> wrote:
Just out of curiosity: Can you give me an example of an algorithm where this would be of advantage?
Roland
It is interesting if, for instance, you have to track an object along an orbit for a very long time. Using the canonical ("cartesian") representation usually entails transcendental functions (say sine and cosine), for which it is very hard to guaranty the accuracy (of a given, one-size-fits-all, implementation) for big values of the argument. If you integrate numerically, you all the more want to stay in the polar domain (unless we cross the singularity, but we are not modeling missiles, are we ;-) ? ).
I'm sure you'd want to use polar coordinates for that, yes. There are of problems for which you want to use polar coordinates of some sort or another.
But is it likely that you would want to use a package that provides complex numbers in polar form? My experience is that if you're
Basically, as I answered the OP, the answer is no ;-) .
working with complex numbers that you want to think of in the form r exp(i phi), then you'll probably just do the work of separating out the magnitude and phase ahead of time in your equations, and then compute with them separately. After all: if you're doing something
Yes.
where the magnitude-phase form is most convenient, it usually means that putting numbers in that form makes the equations simpler.
Yes (but it usually also means to watch out for the singularity).
--Matt
Still, from the discussion on comp.std.cpp a few years back, I recall that there was a feeling that having multiple representations (say cartesian and polar) at the same time would have been nice. Of course, it would have been a bloated beast (at least in a naive implementation), and a slow one at that (to keep track of the various changes, in a naive implementation still). Furthermore it clashed with the desire to have some layout guaranty which played nice with C (that line of reasoning seems to have flown out in limbo, however). This illustration is merely there as a reminder that the wish for concurrent multiple points of views of a given abstract entity is not a futile one, if one that I fear can't be translated from mathematics to CS. We've had another illustration of that recently with the affine space/vector space discussion in a GUI thread a few days back here (which also happens to be relevant to this discussion as well, at least in two dimensions). Merci Hubert Holin
Hubert Holin wrote:
It is interesting if, for instance, you have to track an object along an orbit for a very long time. Using the canonical ("cartesian") representation usually entails transcendental functions (say sine and cosine), for which it is very hard to guaranty the accuracy (of a given, one-size-fits-all, implementation) for big values of the argument. If you integrate numerically, you all the more want to stay in the polar domain (unless we cross the singularity, but we are not modeling missiles, are we ;-) ? ).
Excuse me, but this does not convince me. First I cannot see easily how complex numbers enter into the picture (but this might be due to my lack of knowledge in that domain), and then you need to use sine and cosine only ever if you are using polar _and_ cartesian coordinates at the _same_ time. Even if so, you could formulate your algorithm in the cartesian domain and need sine and cosine only at the last stage to transform the whole trace back to polar representation (if ever needed). But I admit these arguments are all very vaguely and don't make sense as long as not refering to a concrete algorithm. The situation is similar to the concept of number types in general: You may formulate an algorithm in terms of decimals, but do not yet specify whether you will use short int or long. You will specify the type when refering to a certain algorithm. You usually will want to be able to trade off accuracy for size and speed and choose the apropriate type. I would expect from a complex type then that is should be possible to specify e.g.: polar comlex double myvar; when wanting a magnitude phase representation, or complex double myvar; when needing real imag representation. Of course it should be easy to convert between these two representations similar as beeing able to convert between int and long int. Again I am still thinking that even this will not even justify the need for a dedicated polar representation of complex numbers. Take e.g. the FFT algorithm. Altough you have complex representation at the core, you won't gain anything by polar representation because you need addition and multiplication (as is common in any linear algorithm). Rather than optimize the representation you need to optimze the so called "butterfly operation" which is a combination of multiplication and addition, to speed things up. (This reminds me more to what I've seen in ublas when doing late evaluation of composite terms.) Even complex linear equation systems are usually solved by representing them as a (larger) real system. (Polar representation again does not help much.) I am somewhat knowledgeable in the domain of signal processing, and as far as I can tell one will not really benefit much from a polar representation in this field at all. Having said this I do not think it is of no use to think about having such a type. I'd rather suggest pointing out first some concrete examples or algorithms that really benefit from it. Roland BTW.: Wouldn't tracking of an object in an orbit rather require rotations (i.e. quaternions) instead of complex numbers?
Somewhere in the E.U., le 29/11/2004 Bonjour In article <41A9F3EC.6010305@chello.at>, Roland Schwarz <roland.schwarz@chello.at> wrote:
Hubert Holin wrote:
It is interesting if, for instance, you have to track an object along an orbit for a very long time. Using the canonical ("cartesian") representation usually entails transcendental functions (say sine and cosine), for which it is very hard to guaranty the accuracy (of a given, one-size-fits-all, implementation) for big values of the argument. If you integrate numerically, you all the more want to stay in the polar domain (unless we cross the singularity, but we are not modeling missiles, are we ;-) ? ).
Excuse me, but this does not convince me. First I cannot see easily how complex numbers enter into the picture (but this might be due to my lack of knowledge in that domain), and then you need to use sine and cosine only ever if you are using polar _and_ cartesian coordinates at the _same_ time. Even if so, you could formulate your algorithm in the cartesian domain and need sine and cosine only at the last stage to transform the whole trace back to polar representation (if ever needed). But I admit these arguments are all very vaguely and don't make sense as long as not refering to a concrete algorithm.
Let's look at the following problem: you have an abject in a plane (i.e., this is a two-dimensional problem), for which you know the equation of motion. As we are in a plane, and we have chosen an origin and axes, we can represent a point either by its coordinate vector or by a complex number. That's how complex numbers enter the scene. Say in our frame the equation of motion is (warning: ASCII "art"): [x]' [ 0 -1] [x] [y] = [+1 0] [y] Using complex numbers, in this case the equation is z' = iz. You can clearly find the analytic solution to this one, but were you to try and integrate numerically, you would (depending on QOI, of course, but I have yet to see an I with sufficient Q for this...) rapidly see that the cartesian version rather rapidly spouts nonsense (you can even predict how fast using the usual techniques), while the polar version would be far more accurate. This example, of course, is but a toy (though one which has real-world uses, I even published an article about some ;-) ). But is really is a model for genuine real-world problems. [Digression: we *really* need a living, standard or semi-standard free library dealing with optimization, integration, etc., in addition to (and in some cases to help with) special functions.] [SNIP]
I am somewhat knowledgeable in the domain of signal processing, and as far as I can tell one will not really benefit much from a polar representation in this field at all.
Having said this I do not think it is of no use to think about having such a type. I'd rather suggest pointing out first some concrete examples or algorithms that really benefit from it.
See the OP's other examples.
Roland
BTW.: Wouldn't tracking of an object in an orbit rather require rotations (i.e. quaternions) instead of complex numbers?
In three dimensions quaternions are useful to represent rotations (the unit sphere of the quaternions "unwraps" the rotations of R^3 in roughly the same way the unit circle of the complexes "unwraps" the rotations of R^2). Quite often an object in orbit in three dimensions around some other body is (as a first approximation, when perturbations are not too great) bound to a plane. Hubert Holin
Somewhere in the E.U., le 22/11/2004 Bonjour In article <6.1.0.6.2.20041120224709.026b7c40@pop-server.austin.rr.com>, Mickey Moore <mgmoore@austin.rr.com> wrote:
I wanted to gauge whether there might be interest in a class for complex numbers with data stored in polar form. For some applications, polar
I am unsure of any widespread interest in such a thing.
complex numbers have significant advantages over Cartesian complex (e.g., std::complex) in efficiency and numerical accuracy. (I spent some time
Yes.
Googling and, somewhat to my surprise, didn't find any freely available versions of this.)
I have a fairly well developed class that implements this; "boosting" it to be worthy of consideration would probably be straight-forward but non-trivial. My version of this is of course templated on the contained numeric type. It is also uses a policy-based design that determines whether or not the polar angle phi is always maintained in principal form or not and what constitutes principal form (default: no, -pi < phi <= pi).
Thanks, Mickey Moore
---------------------------------------- Mitchell G. (Mickey) Moore, Ph.D. mgmoore@austin.rr.com
The main problems I foresee are in the commingling of the two different classes. It is interesting to see a complex number (among other ways) either as its two canonical coordinates, or in a polar representation, but sometimes we just want to switch between the two for a given instance. So I fear a substantial amount of typical run time will be spent doing conversions. There is another, perhaps deeper, problem to consider, with the representation of complex numbers (and others), as evidenced by a thread on comp.std.c++ a couple of years back: layout guaranties. People wanted, in essence, to be able to break encapsulation when it suited them (for efficiency in time-critical code). The discussion also encompassed thoughts about the polar representation (which, as you remarked, also has advantages). As far as I know, there has been no tangible result to that thread. In short, I am not sure a library for complex numbers in polar form would be worthwile, but I certainly think that if you could make the above situation progress (as in: write a formal proposal), it would be a great win for us all. Bon courage Hubert Holin
participants (4)
-
Hubert Holin -
Matt Austern -
Mickey Moore -
Roland Schwarz