[boost] [New][Multiprecision] Getting errors while writing hypercomplex classes.

Subject: [boost] [New][Multiprecision] Getting errors while writing hypercomplex classes.
From: Daryle Walker (darylew_at_[hidden])
Date: 2013-06-17 12:32:48

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<Number, Rank>
- boost::math::complex_rt<Number, Rank>

"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<Number, Rank - 1> (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<ConvertibleNumber, SameOrLowerRank>, ...
};
  * Complex_type  f{ Complex_type<ConvertibleNumber, GreaterRank> };  //
explicit
  * Complex_type  g{ Other_complex_type<AnyNumber, AnyRank> };  // explicit
  * Complex_type  h{ Complex_type<AnyNumber, AnyRank> };  // 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.