[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Math Types inclusion

From: Bertfried Fauser
Subject: [Axiom-developer] Math Types inclusion
Date: Tue, 6 Apr 2004 00:12:49 +0200 (CEST)

On Mon, 5 Apr 2004, root wrote:

> The correct attack on these kinds of problems in Axiom is to first
> figure out the category hierarchy. Within algebra you can find a
> nice structure of:
>  fields
>    rings
>      groups
>        monoids
> Ideally you'd be able to declare variables of type SU(3).

Dear Camm and Tim,

        both of you write very interesting perspectives on the possible
applications of group theory. However, life is somehow more complicated.

While I think I would be able to come up with some inclusion ship like
above, that is _not_ what a physicist _really_ wants. Having a group, say
SU(2) for simplicity, does not solve actual (and hence not computational)
problems. What physicists want to deal with are group _representations_!

All of quantum entanglement, quantum information processing, quantum
computing etc deals with tensor product representations of SU(2) currently
(and only a few such factors are currently experimental available, quantum
computers have up to say 15 q-bits max, that is one has to deal with a 15
fold tensor product of basic SU(2) spin 1/2 representations)

        There is a special purpose program called Schur (proprietary non
free software alas), which can handle such questions is a virtuose manner.
My attempts go into the direction to implement such possibilities.
Actually Clifford/Bigebra can do this in part, but Schur can do much more.
It was used to perform calculations in nuclear phys, high energy phys,
quantum chemistry, etc. I have tried to come up with a maple package
SchurFkt and implement there cutting edge algorithms (using Hopf
algebra methods) for dealing with Schur functions (group representations)
[Actually to test own calculations and preconceptions in a research

Hence while eg.
         monoid < group,
you need representations of these groups (monoids), which increases the
computational complexity by magnitudes. To have an SU(2) variable would not
be entirely satisfying. An SU(2) variable would not even allow you to say
what spin it has, since the spin value is given to a representation, an
SU(2) element would however _act_ on such representations. [A group
representation could be projective, over complex numbers, over a finite
field etc...]

The point is, that eg. in Schur there is an algorithmical knowledge grown
up in several master and PhD thesis over a period of over 2 decades.
Unfortunately died Brian Wybourne, who initiated the project and was the
main power user of Schur last year, Peter and I were extraordinarily sad
to hear that bad news, since Brian was interested in or Hopf algebra
approach to the topic. (And due to the personal loss of such a friend and
        Unfortunately, Schur's algorithms are not well documented, but
only its usage. Since its written in C, its pretty hard (for me at least)
to extract the time relevant parts of the algorithms. Hence my attempt to
implement them newly using new mathematics.

Most helpful, and I think mathematical modest, would be the development of
a category in AXIOM which could handle polynomial algebra, where the
"variables can be as complex as possible data structures (to be able to
iterate, at least one should have

A polynomial algebra in several variables, where the variables are signed
(commutative, anticommutative (two types) and neutral) every "variable"
should be replaceable by an element from (another instance of) the
polynomial algebra itself.

I think I can do this, but I will take my time (more likely years than
month). To be able to get started, a simple test domain for polynomial
algebra would be a great learning filed. I have to face the fact, that I
am a bad programmer, so my problem really is more like "what is the syntax
of this and that" and questions like "how to program this and that awkward
index set" etc. And -- efficiency is a major topic since all actual
computations are rather pretty longwinded, even beyond present day
compuert power, see the quantum simulator at the FIRST Fraunhofer
institute in Berlin (soory no url, but easily found via goole)

Regarding the discussion about Haskell, I am not sure how "functional" one
can be. My personal experience is, that to abstract mathematics often
fails the computer algebra texst. I found rather a couple of "theorems"
which didn't hold true on being tested via Clifford/Bigebra. AXIOM is the
only tool, which really seems to allow to program nearly functional by
specifying only types and not actual "elements", but...

Look at commutativity, given a multiplication m which is commutative
m(a,b)=m(b,a). A CAS needs _further_ information on term ordering to make
sense from this. Eg assume a>b then a "simplify" would not affect m(a,b),
but would change the arguments of m(b,a) into m(a,b). Such issues come up
in Groebner basis methods, and they really become a point in
noncommutative algebra. Actually such things as the Euclidean algorithm
breaks down in such domains and computability is very weak. There math is
an issue, not only the implementation.

Hence, (see Singular), even if you have a commutative ring, (monoid, with
action of an Abelian group [beware, there are rings having no monoid
structure, ie are not build over a "vector space"]) you need to specify a
term order to be able to compute. There lays the main difference between
categorial mathematics and computer algebra needs.

(AXIOM can already deal rudimentarily with symmetric functions, and hence
with group representations, see that chapter in the book, alas, the
current AXIOM does not allow to load this package as described there, so I
was not able to test what can be done actually)

Since the present discussion very fast could come into an idle discussion,
the main point recently has to be to bring AXIOM into life as complete as
possible, and to provide documentation which allows silly people as I am
to create a category and a domain, and to understand what actual types are
already there (I wont try to hack in bad code for things in AXIOM done
already much neater)


% PD Dr Bertfried Fauser
%       Institution: Max Planck Institut for Mathematics Leipzig 
%       Privat Docent: University of Konstanz, Physics Dept 
% contact |->    URL :
%             E-Mail : address@hidden (address@hidden)
%              Phone : Leipzig +49 341 9959 735  Konstanz +49 7531 693491

reply via email to

[Prev in Thread] Current Thread [Next in Thread]