Re: OONSTD: Alias-free arrays

E. Robert Tisdale (edwin@maxwell.hrl.hac.com)
Fri, 17 Jul 1998 15:21:00 -0700 (PDT)

> 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.

I think FORTRAN guarantees that a 1D array of complex numbers
is equivalent to a 1D array of real numbers twice as long.
The odd elements (remember FORTRAN arrays are 1-based) are real
and the even elements are imaginary.

I don't think C or C++ guarantee that a 1D array of complex numbers
is equivalent to a 1D array of real numbers twice as long.
The real and imaginary parts could be packed into the first part
of a struct with unused space behind them.
In practice, we don't expect that this will ever be a problem
for types float, double or long double but it might be a problem
on a few platforms for type complex<char> for example.

The only way around this potential problem is to specify
that a complex subscalar, subvector, submatrix or subtensor
is a view of 1D array of real numbers where the even elements
(remember C arrays are 0-based) are real and the odd elements are even.
This is convenient because it is possible to reference
the real and imaginary parts of a subscalar, subvector, submatrix
or subtensor separately. Bob Tisdale