[Axiom-developer] Re: grassman.spad

[Martin Baker]

Bertfried,

Thank you for your reply.

I will correct the spelling of Grassmann (although without using ß).

I have been thinking about the naming of the domain. I think it would be 
better to use the name 'Multivector', which seems to me to represent what it 
is, then the names Grassmann and Clifford can be reserved for the 
multiplication types. What do you think? If you agree I will change it now.

No need to apologise about feature requests, I will keep adding to the list of 
requirements on the webpage here:
http://www.euclideanspace.com/maths/standards/program/clifford/

I don't know how efficiently sparse multivectors will be stored, when an 
instance of the multivector is created a PrimitiveArray of instances of a 
field is created. The length of this PrimitiveArray is fixed n^2 so that the 
position in the array indicates the type. I must admit that I have not looked 
at PrimitiveArray to see what happens internally when a given index is not 
set, but when a index that was not specifically set is then read then zero is 
returned. I therefore assume that it takes space with instances of the field 
set to zero.

I can think of a number of alternative designs, for instance, we could create 
2 domains:
Multivector - contains multiple MultivectorElements, just the non-zero, 
position not significant.
MultivectorElement - contains one instance of a field and an integer to 
indicate the bases.

Or another design could be:
Multivector - contains just the non-zero MultivectorGrades, position not 
significant.
MultivectorGrade - contains one instance of a grade, for instance a complete 
vector or a complete bivector and so on.

On the requirement for symbolic indexes, I can't see how this can be done in 
the current sort of design, which uses algorithms where the presence of e1, 
e2, etc. are indicated by bits in a word? Would this require an approach more 
like an equation solver? Where it is given a set of rules, rather than a fixed 
algorithm?

I think the whole design may need to be changed in the future but I don't 
think I have the expertise to do that yet. I would be interested to know the 
sort of top level design approach you took to the maple package or your 
current Hopf algebra work?

Martin