...
>
> There are many places were C9x chooses to diverge from C++.
>
> BTW complex<>, valarray<> and several numerical algorithms
> (e.g. inner_product<>) also have to be improved/corrected. The
> standard only defines complex in catersian cordinates. Polar
> representations are equally useful. I suspect one will need a
> namespace std::math in which to put something like:
>
> template<typename T> class polar { ... };
> template<typename T> class cartesian { ... };
>
> template<typename T, template<class> class R=cartesian>
> class complex { ... }
>
> making it possible both forms.
>
> #include <map>
>
> int main()
> {
> map<double, complex<double> > f;
>
> map<double, complex<double, polar> > polar_curve;
>
> //...
>
> complex<double> z = integrate(f.begin(), f.end());
> plot(curve);
> }
>
The current specification of complex<> doesn't require any particular
internal representation. It could be Cartesian or polar. If I'm
not mistaken, both
re()
im()
and
abs()
arg()
are available in the interface.
In practice, I expect most implementations will choose Cartesian
representations, since the Cartesian plane maps one-to-one to complex
numbers, while the polar plane does not. Also, I've yet to see a
FORTRAN that doesn't implement COMPLEX as Cartesian pairs, and it
would be crazy for a compiler vendor to supply representations of
complex that are not portable across languages.
...
>
>
> -- Gaby
> "One reason that life is complex is that it has a
> real part and imaginary part." -- Andrew Koenig
Heh, heh. One of Andy's better quotes.