[ET Trac] [Einstein Toolkit] #1534: Bug in complex numbers

[Einstein Toolkit]

#1534: Bug in complex numbers
-----------------------+----------------------------------------------------
  Reporter:  eschnett  |       Owner:                     
      Type:  defect    |      Status:  new                
  Priority:  critical  |   Milestone:                     
 Component:  Cactus    |     Version:  development version
Resolution:            |    Keywords:                     
-----------------------+----------------------------------------------------

Comment (by rhaas):

 Reading the bug report this seems to be only an issue for return values.
 The bug report states that even std::complex<double> is fine *in memory*
 ie std::complex<double> must look the same as _Complex double in memory.
 The only functions we have that returns a CCTK_COMPLEX are the
 CCTK_CmplxAdd etc functions. Since we now require C99 all of our supported
 languages (C, C++, F77, F90) support a complex type natively to do algebra
 with. So it seems feasible that we can make things standards conforming by
 removing the  CCTK_CmplxAdd etc. functions which are no longer required
 since the users can just use the language provided functionality instead.
 For backwards compatibility we can provide macro versions of the routines
 in cctk_Math.h or similar (or inline functions returning CCTK_COMPLEX for
 C/C++). I actually do run the Cactus test suites on a 32bit (virtual)
 machine. The failing tests (current trunk) are (using gcc/gfortran):
 {{{
     waveinterp-2p (from CarpetInterp)
     test_o9 (from CarpetProlongateTest)
     Schwarzschild_EF (from Exact)
     test_tov_carpet_refined_nosync (from GRHydro)
     tov_slowsector (from GRHydro)
     test_axibrill_nostagger (from IDAxiBrillBH)
     test_simpson (from Multipole)
     regression_test (from SphericalHarmonicRecon)
 }}}
 SphericalHarmonicRecon in PITTNull uses complex numbers. PITTNull itself
 is in Fortran so probably fine, MoL does the update and is in C so
 *should* be fine as well. There seems to be no C++ code using complex
 numbers in the tests. Slab uses complex numbers but the test does not use
 Slab. Both SphericalHarmonicReconGen and SphericalSlice do use them and
 are in C++, neither one is in the ET yet.

 There are two reasons I can see for the SphericalHarmonicRecon test
 failing:
 1. complex return values are handled differently in C and Fortran after
 all (different from what is stated in the link above)
 2. 32bit machines by default compile for the i387 coprocessor which always
 uses 80bit long double precision in its registers (well almost always)
 while 64bit machines use sse2 which uses only 64bit double precision it
 its registers. One can test this by recompiling the code (assuming gcc)
 using -mfpmath=sse

 I am testing patch for the flesh that replaces the complex algebra
 routines by inline function calls which should remove the problem of
 possibly differing return value representations and will report back on
 the results using the patch alone and using -mfpmath=sse.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1534#comment:4>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit