Warning: This email consists mostly of a "rant" on category theory,
computer algebra, and a comparison of implementations that is somewhat
tangential to the main subject.

>> On Tue, Aug 19, 2008 at 8:14 PM, Bill Page wrote:
>> >> The Sage concept of 'parent' is an attempt to capture similar
>> >> generic relationships that are represented by categories in
>> >> Axiom, but I do not like the fact that this concept needs to
>> >> be added on to Sage rather than being supported by some
>> >> more fundamental feature of Python, e.g. Python meta-types.
>
>> William Stein:
>> Unlike you, I personally like that parent is not a fundamental
>> feature of Python, but a "design pattern" that can be implemented
>> on top of Python.  That means one can directly use the same idea
>> in C/C++/etc. code.

On Sun, Nov 9, 2008 at 10:31 AM, Nicolas M. Thiery wrote:
>
> Let me reuse this thread for further discussions about categories.
>
> To start with: a disclaimer. I am a complete practitioner here.
> Language design is not at all my specialty. But I do have a bit
> of experience using and designing categories in MuPAD
> (MuPAD-Combinat adds about 60 categories to the standard
> MuPAD hierarchy) as a design pattern for organizing and factoring
> out generic code.
>

Thank you for "re-using" this thread. :-) I still think this subject
is important so let me start by explaining why I did not continue the
original thread. William's comment quoted above struck me as
representing a view of computer algebra systems so different than mine
that I did not think there was any chance of consensus - so merely
stating opinions seemed like an adequate closure of the subject at
that time. In spite of this I do still strongly support the idea of
Sage, including many of William's other visions of how it should/does
work. And in fact I find myself using Sage more and more these days in
spite of my continuing devotion to most other things more
Axiom-related.

The difference of opinion about parents and categories in Sage versus
Axiom probably runs rather deep. I was amused to realize that this
difference might even be summarized rather well by your choice of
title for this thread: "Categories for the working programmer". The
significance of this title might be lost on some readers who might not
know the classic text on category theory by Saunders Mac Lane:
"Categories for the working Mathematician". Not only does the term
"category" mean something very different in these titles, but also
there is a fundamental different in the point of view. It comes down
to this question: What is one really doing in computer algebra:
*programming* or *mathematics* ???

In perhaps a too terse manner, I think the difference between Axiom
and Sage can be summarized in the following anecdotal manner: The
developers of Axiom were/are largely computer scientists (aka.
programmers) attempting to implement a system for doing mathematics on
a computer. The developers of Sage on the other hand are (mostly)
mathematicians attempting to program a computer system to do
mathematics. The peculiar thing perhaps is that there is somewhat a
reversal of the usual perspective of mathematics versus computer
science: Sage is often pragmatic where Axiom is pedantic.

> My feeling is that we need both concepts of parents *and* of
> categories (more rant about this upon request). And I like the idea
> of having them as design pattern not tighten too much to the language.
> In particular, this means that we can progressively improve the design
> pattern to increase its expressiveness in our context.  We used that
> a lot in MuPAD. Of course, in the long run, further and deeper support
> from the language could help improve the safety.
>

I think there is something deeper at issue here as well. Python is a
dynamically typed language while Axiom is statically typed. What this
means is that in Python it is the *values* that carry the type
information and the associated methods while in Axiom it is the
container, i.e. variable that carries the type. This distinction is
obscured somewhat by Axiom's interpreter which does try to implement a
kind of compromise (and bridge) between these two ideas about types,
but it is very obvious when one compares the Axiom library compiler
language Spad and Python. This difference has a big impact on the role
of parents in Sage and categories in Axiom. To some extent I view the
notion of "parent" in Sage as attempting to "put back" some of the
rigor (and type safely) that is lost in the dynamic approach to typing
implemented in Python. The library compiler in Axiom on the other hand
can (at least in principle) make good use of static typing to produce
type-safe and efficient machine code.

I have never spent much time with MuPAD, but my perception after some
experimentation is that MyPAD sort of "grafts" Axiom's ideas of domain
and category on top of an underlying untyped language not so different
from Maple. I have only a little more sympathy for this approach than
I have for the concept of "parent" in Sage. William Stein has said
that the notion of parent used in Sage is motivated almost entirely by
his experience with Magma. But all of these projects (MuPAD, Magma,
and Sage) seem to fit my preconceived notion of how mathematicians use
and program computers as opposed to how computer scientists might like
computers to implement mathematics.

But perhaps I am making to much of this supposed difference?

> With Florent, Mike, and Robert we spent some time discussing about
> categories for Sage. I am now implementing a prototype (available in
> sage-combinat), whose design differs slightly from that of:
>
>        http://trac.sagemath.org/sage_trac/ticket/4301
>
> The idea is to let a category define generic code for parents and
> elements through standard class inheritance (with some class
> surgery done automatically behind the scene). It's a bit more tricky
> to setup internally, but avoids messing around with getattr (that is
> in practice introducing another technical way for doing multiple
> inheritance; I am not speaking of cython object there, which
> probably will need some getattr tricks since standard multiple
> inheritance does not work).
>

As some others in this thread (Tim Daly and Ralf Hemmecke) have
pointed out, there is not a complete consensus even in the Axiom
project(s) about the "true nature" of categories in Axiom. But the one
that I like the most is the one promoted by one of the early
developers of Axiom who later became the primary developer of Aldor -
the second generation library compiler for Axiom: Stephen Watt.
Stephen defines a category in Axiom (and Aldor) as a "sub-domain of
the Domain of all domains". This combines several ideas. First,
domains implement the notion of type or class in object-oriented
design. All values manipulated in Axiom are members of some domain and
the domain provides the methods by which these values are created and
accessed. One domain can be a sub-domain of another, e.g.
PositiveInteger is a sub-domain of Integer. But domains themselves are
values of a distinguished domain called Domain. Finally, categories
are sub-domains of this Domain - in other words categories are just
collections of domains.

I find this description satisfying because it is couched in terms that
should be very familiar to the mathematician. It does not invent any
new concepts of dubious intuitive value like "parent".

The reason why categories are interesting is as a means of organizing
domains into a conceptual hierarchy that corresponds in some
reasonable manner to formal concepts of interest to mathematics.
Navigating this hierarchy is an important part of learning to use the
Axiom system for any particular purpose. But it turns out that this is
also exactly the abstraction that makes generic programming possible.
When we associate properties like a list of exported operations to a
category, we will require that all domains that are members of this
category export and implement exactly these operations. Algorithms
implemented at the level of a category are available as defaults to
all the members of that category.

In comparison I find the concepts of class, meta-class, element,
parent and category in Sage overly complex and confusing - especially
to someone new to Sage. But I am clearly trumped in any argument along
these lines by the overwhelmingly greater number of people now
actively programming new functionality in Sage compared to Axiom. Of
course this is a source of considerable frustration to me. :-(

> The current design should leave the door open for those who will
> want to do category theory (i.e. calculations on the categories
> themselves), rather than using them to organize generic code which
> is my own main goal.

This strategy also conflicts strongly with my personal vision of how
mathematical category theory (as opposed to "category" as implemented
in Axiom and Sage) ought to fit into computer algebra. Category theory
has rapidly become an essential part of the toolkit of the computer
scientist. It has also gained almost universal acceptance in
mathematics as at least one of the ways in which mathematics can be
accurately and formally presented. Most aspects of category theory are
essentially algebraic in nature. So it seems peculiar in the extreme
to me that almost all computer algebra systems treat category theory
as at best a kind of "add-on" rather than a fundamental design
approach.

It seems to me that of all the existing computer algebra systems,
because of it's strong and often pedantic type system, Axiom seems
most compatible with taking category theory as a foundation.
Unfortunately in most respects Axiom does not do nearly enough to
exploit this. Magma apparently also takes a formal approach that is at
least in part motivated by category theory but I was rather
disappointed to see how little of this remains in the approach now
implemented in Sage.

>
> See the attached files for some details.
> ...

Well, it is hard to argue with working code! So to the extent that
this allows you do do things in Sage that might be awkward in a more
pedantic system like Axiom, I am very happy that you are working on
extending Sage in this manner. I do still wish however this becomes an
integral part of Sage and not just something else added on.

Regards,
Bill Page.

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to