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.
