Re: [Axiom-developer] Clifford Algebra Requirements

[Tim Daly]

Martin Baker wrote:
> Bertfried,
>
> 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:
>
> ring
> field
> 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?
>
> Martin
>
>
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
>
>   
Martin,

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
equality.

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:
http://axiom-developer.org/axiom-website/bookvol10.2full.html

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.

Tim