[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Clifford Algebra Requirements

From: Tim Daly
Subject: Re: [Axiom-developer] Clifford Algebra Requirements
Date: Sat, 31 Oct 2009 09:51:07 -0500
User-agent: Thunderbird (Windows/20090302)

Martin Baker wrote:

In addition to the limitations of the current Clifford algebra implementation, that you explained, there also seem (to my untrained eye) to be performance issues. Also I wanted to get a feel for the general Axiom design methodology by picking a specific issue.

The current implementation seems to calculate the product of terms every time it is required when a multiplication is called. From a performance point of view it would seem much more efficient to calculate a multiplication table in the constructor which would make individual multiplications much faster. The original author also had this thought as the following comment is in the code:

-- The ei*ej products could instead be precomputed in
-- a (2**n)**2 multiplication table.

The entries in such a table (in the general Grassman case) would be quite complicated. Not just a single type but perhaps a sum of types with algebraic number multipliers.

I think, if I were designing such a system using a conventional object oriented program then, I would create a class for the multiplication table and also a class for individual table entries. I don't know if that's how things are done in Axiom?

I don't know enough about the mathematics but is seems to me that classes (domains) such as mutiplicationTable and multipicationTableEntry might have wider application for implementing other algebras?

Here I am really going to show up the gaps in my mathematical education but, could these things link back to more fundamental structures, for example could there be an inheritance hierarchy like:

field which is a compound type
compound type which can be defined by a multiplication table.
clifford (Grassman) algebra

Is there someone who defines the overall structure of Axiom at this level?

What do you think would be the best approach to this?


Axiom-developer mailing list


Structurally, Axiom rests on the categories which define the behavior
which is expected from domains which belong to the categories. For
instance, everything that belongs to SetCategory has to implement

Domains implement the methods required by the categories as well as
methods particular to themselves. Thus, it would seem that you would
define a category "field defined by multiplication table" which could
defines expected methods by all members (e.g. tableLookup(element,element))

The Grassman algebra domain would be a member of the category and thus
would be expected to implement such a method.

Alternatively you could create a category "field with cached results"
that required a "cacheLookup(element,element)".

The design is flexible. However, there should be a strong mathematical
basis for the choice of category structure. That said, there is the
"computational mathematics" issue that some ideas are implied purely
by performance rather than mathematical.

A graph of the category hierarchy is at:

This is one of the more challenging aspects of Axiom so don't feel
intimidated by the task. Feel free to ask more questions.

I downloaded the Grassman Algebra book and have finished the first
two chapters. I looked at Grassman a couple years ago while I was
busy documenting the Quaternions.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]