#624: Replace Cactus complex number implementation with C/C++ standard implementation --------------------------+------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: review Priority: major | Milestone: Component: Cactus | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by eschnett):

* status: new => review

Comment:

The enclosed patch changes the definition of CCTK_COMPLEX to use C99 or C++ complex datatypes, respectively. The Cactus complex number functions CCTK_Cmplx* are retained for compatibility, and only wrap the C99 functions.

In most places the changes are trivial.

File cctk_Complex.h contained optimisations allowing inlining; since we are using different implementations in C and C++, this is not easily possible any more, and is now disable. (The inlining, that is.)

In many places, real and imaginary parts were accessed as structure members. This is not possible any more, and has been replaced by calls to CCTK_Cmplx{Real|Imag}. This probably also teaches a lesson about the values of information hiding.

In many places, complex numbers were explicitly treated as two-vector of real numbers. This is now not necessary any more, simplifying the code.

Thorn LocalReduce is not amenable to modifications. I disabled it in this patch. A better solution is probably to remove support from complex numbers from it, since this support has serious errors anyway. In the long term, LocalReduce should be rewritten in C++, probably reducing code size by a factor of 100.

#624: Replace Cactus complex number implementation with C/C++ standard implementation --------------------------+------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: review Priority: major | Milestone: Component: Cactus | Version: Resolution: | Keywords: --------------------------+-------------------------------------------------

Comment (by eschnett):

(a) Disabling LocalReduce won't fly; we will have to e.g. remove complex number support from it instead. (b) This won't be a problem. double;double; always has the same layout as double[2]. float will not be aligned to 64 bits, even on 64 bit systems.