[Axiom-developer] Mostly about MuPad (was: Philosophy... )

[Bill Page]

On September 22, 2005 10:20 AM Martin Rubey wrote:
> 
> Bill Page wrote: 
>> [...] still I think that types and domains in Axiom are a 
>> big problem... and also the main reason to use Axiom as I
>> said above.
> 
> What exactly do you think is a problem?

There are many problems most of which we have discussed to a
greater or lesser extent here over the last two years:

#1 Understanding how to apply the programming language concept
   of 'types' (as in Pascal) to mathematical 'domains' (as in
   Bourbaki and category theory). Are types and domains the
   same thing? When to define Axiom categories?

#2 Understanding how and when to use representations (Rep) and
   the role of primitive domains like record, union and mapping.
   How is this related to object-oriented programming concepts?

#3 Understanding the structure of Axiom's more than 1,000 existing
   domains and categories. Lack of adequate documentation. Difficulty
   of navigating and browsing such a large structure. Difficulty in
   relating design choices to contemporary mathematical concepts.
   In spite of it's already large size, only a relatively small part
   of mathematics is implemented.

#4 Dealing with unexpected and sometimes complex behaviour of the
   Axiom interpreter -- mainly it's heuristics relating to guessing
   types. Differences between the Axiom "interpreter language" and
   the Axiom "library language".

#5 Differences between the SPAD language and the Aldor language.

#6 ...

> I do admit that improving the quality of the explanations in the
> Axiom Book would be good, however difficult. Same for the Aldor
> User Guide, which is more technical and more detailed. But I
> wouldn't write *more* about it. It's too much quantity!

Actually I mostly agree with you about this. Quantity does not
substitute for quality and quality is more difficult. For example,
over the last few years the participants of axiom-developer list
here have probably exchanged a much greater quantity of text than
contained in the original 1,000+ page Axiom Book (from which we
have plans to create 4 or 5 new volumes). In general, as Axiom
documentation the quality and coverage of the resulting online
archive might be considered rather "low". But on MathAction we
have (gradually) collecting and re-writing some of the material
that might have some lasting relevance and quality. When I say
"write more", I am thinking mostly of improving the "quality"
in this way.

> 
> > It seems to me that one of the reasons that Axiom is not 
> > used as much and is not being developed as quick as
> > Mathematica, Maple and even Maxima is precisely because of
> > the problem to trying to understand and use strong typing
> > in computer algebra systems (the marketing and commercial
> > reasons not withstanding).
> 
> Look at MuPad, which works well. It has (nearly exactly) the
> same type hierarchy as axiom -- still it sells. The difference
> is mainly the language of MuPad, which is not statically typed,
> in contrast to Aldor/Spad.
>

Could you explain what you mean by "statically typed"? I don't
think Aldor and Spad could be said to be statically typed either.
I agree that in contrast to Aldor and Spad, Mupad is not "strongly
typed". And this is exactly my point. 

The "type hierarchy" in MuPad was more or less directly grafted on
to MuPad in version 2. Version 1 of MuPad looked almost identical
to Maple release 4 and had essentially no concept of type at all.
But the structure of these programming languages have diverged
greatly in MuPad versions 2 and 3 and Maple from versions 7, 8, 9
and 10. Maple by deliberate design has no concept of type at all
(the "assume" facility notwithstanding). Both MuPad and Maple
are taking very different paths towards a more complete "object-
orientation", and neither are really similar to Axiom.

Yes, MuPad does "sell" although considerably behind Mathematica
and Maple. Originally MuPad was open source but since version 2
the kernel software has a proprietary license. Like Maple, most
of the algebra source code is "open" and accessible to the end
user but licensing and copyright remains an issue. I think MuPad
would be doing much better now if it had remained entirely open
source. And if that had happened we might be discussing MuPad
instead of Axiom right here and now. :)

MuPad's implementation of Axiom's type hierarchy is described
here:

Axioms, Categories and Domains
Klaus Drescher
January 2002 Automath Technical Report No 1
http://research.mupad.de/doc/31/eng/domainref.pdf

Here are some highlights:

In the section "Categories":

http://research.mupad.de/doc/31/eng/domainref_se12.html#x14-230004

See especially "Figure 4: Graph of the Categories of the Integers".
This graph is nearly identical to part of the graph inside the
front cover of the Axiom Book.

Axiom is referenced explicitly in the section titled
"General Nonsense?":

http://research.mupad.de/doc/31/eng/domainref_se17.html#x20-310007

"Most of the concepts in the constructors are based on ideas in
AXIOM, see [7]. Many new algorithms have been implemented in
AXIOM for the first time because there the user has the algebraic
structures handy that he can use for his problem, independent of
their representation. All objects in AXIOM are strictly typed.
This is not possible in MuPAD because the MuPAD language is not
strictly typed.

A debatable feature of AXIOM is the automatic type conversion:
the system tries to determine the type of the user's input
on entry, i.e., to convert untyped expressions directly into
domain elements. In MuPAD the user currently has to explicitly
convert the type "by hand". It is, of course, in some cases
easier for the user not to have to give the type. On the other
hand, it is often difficult to determine the type of an
expression that the user has in mind. For this AXIOM uses
time-consuming and error-susceptible heuristics."

[7] R.D. Jenks, R.S. Sutor. AXIOM, The Scientific Computation
    System. Springer, 1992.

In "The Constructors of the MuPAD Library":

http://research.mupad.de/doc/31/eng/domainref_se18.html

Notice in particular even specific details of Axiom's category
structure are implemented:

Cat::Ring - the category of rings
http://research.mupad.de/doc/31/eng/Cat_Ring.html#Ring

Cat::Rng - the category of rings without unit
http://research.mupad.de/doc/31/eng/Cat_Rng.html#Rng 

>> In a sense, Axiom is/was an experiment in the application of
>> strongly typed programming languages in computer algebra and
>> to be quite honest and blunt, for the most part the experiment
>> seems to have failed. :(
> 
> No, most of it has been transformed into MuPad.

I disagree. In spite of what MuPad has borrowed from Axiom, it
seems to me that so far MuPad has implemented only a small part
of the original concept of the Axiom designers. I think that
this is probably intentional on the part of the MuPad developers
and is at least in part due to the perception that the "Axiom
Experiment" failed to demonstrate the utility of it's strong
type system.

The situation is similar with statically typed programming
languages in general. For example, hardly anyone writes in
Pascal any more. But there is still a lot of research going
on in strongly typed languages such as Haskell and Ocaml.

> However, I dare say that Aldor is superior to MuPad's
> language.

I agree. In many respects Spad and Aldor anticipated many of
the features implemented in Haskell and Ocaml. And they are
strongly motivated by abstract mathematical concepts. MuPad
(and Maple and Mathematica) on the other hand has not yet
shed it's origins as what Tim Daly referred to as the
"engineering approach to computer algebra".

Regards,
Bill Page.