[boost] Requesting number crunchers for trial complex classes

Subject: [boost] Requesting number crunchers for trial complex classes
From: Daryle Walker (darylew_at_[hidden])
Date: 2013-07-22 18:58:05

I just pushed out commit "aaeabbd3fcc04956c4fd3d3825f6202355ab9297" of my trial hypercomplex number classes at https://github.com/CTMacUser/Complex.  The classes now have all the arithmetic operators.  They already have the condition functions (norm and conj), norm functions (taxi (ex L1), abs, sup, and sgn), and equality operators.  There is an output operator, but not input.  There are constructors for: default (both garbage bits and all zeros), copy and move (automatically defined), component (single or list), cross version, smaller hypercomplex (single and list), and (head of) larger hypercomplex.  Look at the unit tests for usage examples.

I haven't done any utility or transcendental functions yet, so let me know if you need them before proceeding.  I just want people who do hard-core number crunching with complex, quaternion, and/or octonion numbers to see if my classes are worth it, performance-wise.  You can also use the array-of-hypercomplex to array-of-many-reals reinterpret_cast trick.  Everything should have Doxygen comments.

I run this code on GCC 4.7.1 off MinGW for 32-bit Windows 8 Pro, so tests on other compilers will be appreciated.  (It probably can't run on Visual C++, but GCC 4.8 and Clang 3.x will probably work.)

Note on octonions: a month ago I found out, while looking for online octonion calculators, that octonion (and above) multiplication isn't standardized.  I'm using the same philosophy from Wikipedia, which is also used by the existing Boost.Octonion.  (Actually, I found a bug in B.O.'s octonion times quaternion code, since that author manually lists all the sub-terms, and my code is more automatic.  I had to do the multiplication by hand to check who had it right.)  So if your octonion products are different, it may not be a bug.

I've tried to make as many constructors/operators/functions constexpr as possible.  (That's why no std::initializer_list.)  That may help move data into ROM, but you have to force non-inline-ness when you need to test runtime performance.

Daryle W.