Andreas C. Doering:
> not only the collection of algorithms is important but also the
> data base of algebraic objects.
> For instance the group theoretic package Magma (formerly Caley) comes
> with as much information on finite groups as the the libraries of algorithms.
> This data base represents condensed information from hundrets of papers
> and an incredible large amount of computation.
Yes.
(<<Cayley>>; see http://www.maths.usyd.edu.au:8000/u/magma/).
See also GAP: http://www-history.mcs.st-and.ac.uk/~gap/ which is FREE.
Magma is advertised as something with a powerful functional subset:
higher
order functions, partial evaluation, closures, etc. I suppose that this
part
would be easily implementable in Haskell. One has in Magma such
mathematical
hierarchies as Rings, Lattices, Modules, and God knows what, and it was
one
of my old dreams to represent them through the Haskell type class
system. It
didn't work properly, but in order to explain why, I would need several
pages.
(Anyway, I would start rather with the categories of Axiom or MuPAD ...)
Magma operates upon sequences and other iterative structures which are
well adapted to lazy algorithms, so, implementable in Haskell with a lot
of fun. Well, you might have a quick look here:
http://www.info.unicaen.fr/~karczma/arpap/laseq.pdf, but I was mainly
interested in numerical processing...
So, I have still some optimism, but I wholeheartily disagree with what
follows:
> One option would be interfacing or translating a FPL into the CA system.
> For instance Axion uses an own language (strongly typed, very powerful)
> which is translated into lisp, than to C, assembler and finally machine language
> (at least these are the steps done on IBM mainframes).
> I could imagine that a second front end, Haskell could translated in compatible
> Lisp code easily. This would allow using the libraries (data base and
> algorithms) of Axiom.
Sorry, but this is a typical Frankensteinisation if you know what I
mean.
Getting rid of the type system, of the lazy formulation of algorithms
and
transforming Haskell into Lisp? I would rather go to a Buddhist
monastery.
No, I believe that CA pkgs could be eventually rewritten, and
*especially* the
algorithms. But it is pointless to start with Maple as such, this *IS*
crazy.
Why not implement *some* symbolic algorithms in Haskell?
There is plenty of things to do.
I managed to implement in a simplistic way (but which killed the
audience at
Stirling anyway...) Differential Forms. Marc McConnell implemented some
homological algebra and topology in Lisp:
http://www.math.okstate.edu/~mmcconn/shh0596.html
Implement just a partial polynomial package for a specific purpose:
Gröbner
bases, Galois Field manipulation (e.g. for CRC), etc. ...
It will (for some time) remain an academic initiative, but we can gather
some experience.
=======================
I don't know anything (yet) about the system of Malaquias, but I assure
you
that I have seen at least 20 small CA experimental systems written very
often
as PH theses. (It seems that Jacal based on Aubrey Jaffer's SCM Scheme
is
such a system, quite known.) There is plenty of material to look up, one
of
my favourites, dead for more than 25 years, was a nice system (made
somewhere
in Germany) embedded in Algol68, which used its type system.
====
A short comment on Sergey hypothesis, who reacted to my statement that
CA
packages are popular because of the mathematical bedlam concerning the
status of symbolic indeterminates:
> Maybe, Maple is popular for other reason? Maybe, due to the rich
> library of efficient algorithms? Integration, numeric methods, and
> so on. I suppose this, i do not know.
Well, I have a strong opinion about that, oscillating between my
previous
world of physicists, and Comp. Sci., especially the educative Comp. Sci.
Nope!
The power, the perennity, the commercial success among professionals is
obviously the result of delivering a complete, universal package, with
all
kind of goodies, bells, whistles, demos, etc. But let me assure you:
1. Numerical methods in Maple are lousy! Inefficient as hell for all
serious
numerists. For prototyping they are OK, but not for long runs.
2. A lot of other algorithms is also inefficient (I suppose that even
the
basic pattern substitution algorithms are somewhat obsolete, but it
changes all the time...). It doesn't really matter, they work well.
3. The *POPULARITY*, the flourishing life of MUG discussion
lists/newsgroups,
the usage of Maple in schools, etc. - this has *nothing* to do with
this
super-power of algebraic hierarchies, or whatever. The system was
conceived
to be used interactively in a most silly way. A typical user wants
that
typing "x+x" gives "2x", and "x-y" where y was assigned x, should
give zero.
No question about typing, no questions about 'what is x' in
fun = function(x) ... x(bonjour) ... end;
followed by "fun(allons*enfants+x);"
Jerzy Karczmarczuk
Caen, France
