I've banged out (yet another) complex number class at https://github.com/CTMacUser/Complex. The current commit has an SHA of "b866cda91ccdb4aa87c199c6d9e7c776fee61bcc." Right now, I'm writing this code on a 32-bit Windows 8 system using Code::Blocks with a packaged MinGW GCC 4.7 by TDM. In many of the incremental changes, I ran into internal compiler errors. I don't know if my code is too unusual or it's the compiler. I'm asking if you guys can check out the code with other compilers (GCC 4.7 besides MinGW/TDM, GCC 4.8, Clang 3.x, non-Windows, etc.) so we can figure out what bug goes where. There are two class templates: - boost::math::complex_it - boost::math::complex_rt "Number" is a Regular type that supports math operations plus Boolean conversions. "Rank" is the Cayley-Dickson hypercomplex level. Use 0 as a shell for real numbers, 1 for regular complex numbers, 2 for quaternions, 3 for octonions, etc. The "complex_it" class template stores all the components directly in an array with length 1ULL << Rank ("i" is for "iterative"). The "complex_rt" class template stores an array of 2 objects of the previous level ("r" is for "recursive"), except for the partial-specialized base case which stores one component. The two templates support nearly the same interface. - Static interface * using value_type = Number * rank = Rank * static_size = 1ULL << Rank * using barrage_type = complex_?t (or self when Rank == 0) - Construction * Complex_type a; // random garbage bits * Complex_type b{}; // zero-fill * Complex_type c{ r }; // real conversion * Complex_type d{ r, i, ... }; // real list * Complex_type e{ Complex_type, ... }; * Complex_type f{ Complex_type }; // explicit * Complex_type g{ Other_complex_type }; // explicit * Complex_type h{ Complex_type }; // explicit * For [d], the total number components can't exceed static_size. * For [e], the combined number of components from the objects can't exceed static_size. * "ConvertibleNumber" uses implicit conversion, "AnyNumber" static_cast. * Conversions in [g] are both in complex_rt, a constructor and conversion-operator. * For [h], it excludes types in "AnyNumber" that would be covered by [e] and [f]. - Member functions * Boolean conversion operator (explicit) * "real" and "imag," inspector and mutator versions, just like std::complex (Don't use "imag" mutator when Rank == 0!) * "unreal" inspector, like boost::quaternion and octonion; plus a mutator version * Lower- and upper-halves of component list (called barrages) - complex_it uses inspector and mutator, like real/imag/unreal - complex_rt uses by-reference returns, const and mutable * operator [] for direct (by-reference) access to components - External operators * == * != * + (unary) * - (unary) * ~ (new, conjugation) * << (output) - Tuple interface (get, tuple_element, tuple_size) - Object support * begin (non-member, complex_it only) * end (non-member, complex_it only) * swap - Math * conj These spots cause internal-compiler errors: * https://github.com/CTMacUser/Complex/blob/master/include/boost/math/complex_ it.hpp#L753 * https://github.com/CTMacUser/Complex/blob/master/include/boost/math/complex_ rt.hpp#L593 * https://github.com/CTMacUser/Complex/blob/master/include/boost/math/complex_ rt.hpp#L599 use the comments to switch the code back and see if it works on your system. There were also problems using Boost.Multiprecision in the unit tests. I don't know if the problems are in Multiprecison, Test, MPL, or some interaction between them. The spots in "complex_it_test.cpp" and "complex_rt_test.cpp" that use the "test_builtin_types" alias were supposed to use "test_types," but the sample types from Multiprecision had MPL errors. Switch the types and see if they work on your system. Daryle W.