# [Maxima] Complicated objects in Maxima

Rupert Swarbrick rswarbrick at gmail.com
Thu May 17 04:24:27 CDT 2012

```Hi there,

If you don't want to read the entire message, skip down to the bottom -
there are three questions there.

I've been playing around a bit with code to represent algebraic objects
like monoids and finitely presented groups (and elements in them!) in
Maxima. It would be lovely if we could get some of the functionality of
other CAS's for that sort of computation in Maxima. Now, unfortunately
there's a problem.

You see, if I want to do calculations with a finitely presented (FP)
group, I definitely need to store a list of generators and relations for
G. So maybe something like D8:

G: present_group([a,b], [a^^4, b^^2, a.b.a.b]);

or whatever. Fine, but now I notice that actually I want to
short-circuit computations by noticing that a and b have finite
order. Right, so G should be storing a list of element orders, a list of
generators and the remaining relator. Although, that's an implementation
detail, so maybe it should still print something like the above. Of
course, as the code gets more capable, I might want to store lots of
other information about the group in the structure as it gets
calculated.

One option would be to have G be represented by something like the
following lisp form

((%fp_group) ((mlist) \$a \$b)
((mlist) ((mlist) \$a 4) ((mlist) \$a 2))
( something for the abab relator ))

(I'm typing this by hand, so ignore errors and mentally add as many
SIMP's as you like). Then I can define a DIMENSION property on the
%fp_group symbol etc.

Another option would be to represent G by an object

(defclass fp-group (fg-monoid)
((relators :accessor relators :initform nil)
(element-orders :accessor element-orders :initform nil))
(:documentation
"A group defined by a presentation in generators and
relators. Relators of the form x^^n are stored in ELEMENT-ORDERS
rather than in the general RELATORS slot since they allow us to check
for torsion generators easily. (Obviously, general torsion elements
are much harder to spot). ELEMENT-ORDERS is an alist keyed by
generators where the cdr is nil for an infinite order element and the
order (always a positive integer) otherwise.")
(:default-initargs :abelian nil))

(Yep, as you can see, this is pasted.) I really really like this option
because it means that you can use CLOS to pass on calculations to parent
types etc. You then have a constructor function like

(defmfun \$present_group (generators relators) ...)

and everything works...

Except, of course, it doesn't. But in only one way, as far as I can
tell. Since an object of type fp-group is an atom, the displa code just
prints it with (format nil "~A" the-group). To do proper dimensioning,
one has to add an extra hook into the displa code to call a generic
function (dimension-object here) that can be specialised. Oh, there's
also a tiny one-line change I had to make in simp.lisp where something
assumed that an atom was always a symbol or a number.

So

(1) Have I missed an obviously better way of doing things? I'd really
like to be able to use defmethod rather than rewriting a subset of
CLOS to make things work.

(2) Does anyone have a fundamental objection to Maxima objects that
are not CONSes? (Well, other than numbers, that is)

(3) (If not) would you be willing to include the displa patch I
mentioned? It only adds the extra check just before resorting to
(format nil ...), so it shouldn't hurt performance of displa.

I should say that at the moment the algebra code I have can basically
just act by group actions and interpret group elements sensibly. I
intend to add more soon - hopefully to be able to do some Bredon
cohomology calculations that I might be able to use for actual work. But
(since it would probably be easier to do this in, say, Magma at the
moment) I'm carefully not doing this in work time...

When this code doesn't depend on hacking src/ (so it can just live in
share/) and also can actually do useful computations, I intend to post
it for public ridicule...

Looking forward to comments / help / flames,

Rupert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20120517/7af6a471/attachment.pgp>
```