[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: grassman.spad
From: |
Martin Baker |
Subject: |
[Axiom-developer] Re: grassman.spad |
Date: |
Fri, 20 Nov 2009 17:10:28 +0000 |
User-agent: |
KMail/1.11.0 (Linux/2.6.27.37-0.1-default; KDE/4.2.2; x86_64; ; ) |
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