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