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
Axiom-developer@nongnu.org
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
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
