Kent> The current specification of complex<> doesn't require any particular
Kent> internal representation. It could be Cartesian or polar. If I'm
Kent> not mistaken, both
Kent> re()
Kent> im()
Kent> and
Kent> abs()
Kent> arg()
Kent> are available in the interface.
At first glance yes. But FDIS/26.2.4 (constructors) tends to suggest
that complex<> are mainly manipulated in cartesian coodrinates. I/O
operates on complex<> in cartesian coordinates. And what is polar()
for if not to indicate that complex<> are manipulated in cartesian
coordinates.
What I'm trying to say is that it would be more accurate and
convenient to provide both forms and let the user choose instead of
favoring one form.
Kent> In practice, I expect most implementations will choose Cartesian
Kent> representations, since the Cartesian plane maps one-to-one to complex
Kent> numbers, while the polar plane does not. Also, I've yet to see a
Kent> FORTRAN that doesn't implement COMPLEX as Cartesian pairs, and it
Kent> would be crazy for a compiler vendor to supply representations of
Kent> complex that are not portable across languages.
I do agree. To increase portability, it is safe to provide both usual
forms: cartesian<> and polar<>. Up to the user to choose
complex<T, cartesian> or complex<T, polar> -- I proposed complex<T> to
default to complex<T, cartesian>. BTW I can't take FORTARN inability
to provide both forms as an excuse not to increase portability and
performance issue.
Best,
-- Gaby