# Boost :

From: Jaap Suter (boost_at_[hidden])
Date: 2004-06-16 02:57:12

Hi,

This is a follow-up to my original email from June 9th, see:
http://tinyurl.com/3defq

[again crossposted to oo-numerics and boost-developers]

After this email, several people expressed interest in my geometric algebra
library. Unfortunately I cannot address each email individually, so thanks
to everybody that replied.

First, I want to introduce a new feature I added this week.. It's what I
like to call the "auto_element" feature.

Within the Clifford framework it works like a "typeof" or "auto" feature.
Consider the following:

typedef algebra<float, 4, 1> conformal_space;

element<list_c<int, 0, 2>, conformal_space> a;
element<list_c<int, 1, 2, 4>, conformal_space> b;

some_type c = left_contraction(a, b)
* outer_product(some_vector,
some_bi_vector);

People familiar with Clifford algebra know that sometimes it is hard to
decude what grades appear in the resulting element of a complicated
expression. E.g., in the above example, who can tell me what grades
appear in the left_contraction of a conformal-spinor and an element that has
grade 1, 2 and 4. Let alone if you multiply that with the outer_product of
some vector and some bivector.

In other words, what is the type of c?

Most other libraries solve this by just using a full multivector (consisting
of 32 floats) in this case, which is often redundant. In fact, perhaps the
above expression results in just a single scalar. That's a lot of
calculation and storge for just one number then.

This library allows you to write:

auto_element(conformal_space,
c,
left_contraction(a, b)
* outer_product(some_vector, some_bi_vector)
);

[indention weird, because of the line-ending limit]

which will declare an multi-vector of a type that contains the bare-minimum
of grades necessary to capture all the information available in the
expression. This has big performance improvements, but more interesting, it
makes generic programming with arbitrary elements of an algebra a lot of
fun. You don't have to know what types are involved in an expression
anymore, but still get all the benefits of static type-checking and the
associated performance analysis.

Who said C++ was statically typed? :)

By the way, for those wondering how I did it, obviously auto_element is a
macro that does some (compile-time) stuff. It's not that hard, but a
technique I hadn't seen before (let me know if it does exist somewhere else,
or if there's a better way of doing this). Come to think of it, other
libraries that involve dimensional-types (matrix libraries, etc.) could
possible benefit from this as well.

I have now uploaded a package to http://www.jaapsuter.com containing all the
header files, some of my unit-tests, and the MSVC 7.1 project file. For
reasons outside of my control I cannot upload all of the unit-tests yet.
This will be resolved shortly.

If you consider porting this to GCC, I would still recommend trying to
compile the project in MSVC first and play around with it. It's some really
heavy code internally. Hopefully (this is for you to judge) the client-side
(see the unit-tests) are very friendly though. So please browse the tests
before you dive into the implementation.

Comments are welcome. There is still some bugs with certain
expressions (as a consequence of not being able to deal with unsorted
grade-lists), this will be fixed shortly. I am working on the library
on-going, but I am hoping somebody will join.

Then, somebody mentioned the interoperability with std::complex and Hubert
Holin's Quaternion and Octonion library. I have some tests that test whether
Clifford and these libraries behave the same (and inter-operate).

As for implementing these types in terms of a geometric algebra? It depends.
Sometimes it's worthwhile to specialize and keep things simple (think about
scoped_ptr not being implemented in terms of a policy_ptr). But then again,
if you have a clifford library in your project already anyway, you might as
well use it for complex numbers, quaternions, etcetera. Otherwise, using
clifford to provide these basic components is probably overkill.

Regards,

Jaap Suter