From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2004-11-28 10:51:08
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
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
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
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.
BTW.: Wouldn't tracking of an object in an orbit rather require
rotations (i.e. quaternions) instead of
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk