[Top][All Lists]

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

[Axiom-developer] Re: [Axiom-mail] Axiom v. Maxima

From: root
Subject: [Axiom-developer] Re: [Axiom-mail] Axiom v. Maxima
Date: Fri, 16 May 2008 16:21:54 -0400


>So, I am extremely new to Axiom, in fact I pretty much don't know how to do
>anything I want with the system, even after reading the introductory
>materials.  But I just want to say that Alasdair has some good points from
>my point of view.

Please look at my reply to Alasdair. There are links to other free

>When I was searching for a free CAS I found Maxima first (around 6 years

>This is really big, but perhaps not for the reasons one might think.  I have
>read some of Prof. Woollett's chapters and they leave something to be
>desired for anyone not brand spanking new to the system.  In fact, for any
>advanced usage information, nothing seems to replace the mailing list which
>is perhaps 10 times as active as axiom-developer and axiom-math put
>together.  What this does show is that Maxima has a user base that cares
>about it.  Archaic languages such as C survive because they have a large
>user base, which creates more development/ease of
>use/portability/efficiency, which draws more people to the language.  The
>fact that more people seem (are?) interested in Maxima makes it seem that
>the project is healthier than Axiom.
>Perhaps some public relations work would help?

<humor>Perhaps we could offer pay-per-post?</humor>

Seriously, though, I have no idea how to increase mailing list posts.

>>   5. The various forks: Axiom, FriCAS, OpenAxiom, also must make it hard
>>   for the new user - which one to choose, and why?  The many many
>>   distributions of Linux make choosing one awfully hard for the beginner -
>>   even I, who've been using Linux exclusively for over 15 years, get
>>   on the rare occasions I have to install a new system.  Axiom has the
>>   problem.
>Once again, this seems to point to an overall relative unhealthiness in
>Axiom as compared to Maxima.  When projects fork, it necessarily applies
>stress to the users (and I assume developers).  But more importantly, it
>makes the choice more complicated for new users.  As a newcomer, it looks
>like rats leaving a sinking ship, but should you trust a rats assessment of
>the ships status?  As sad as it may be, people, in my experience, do not
>like choices.  Tell me, is there any bad blood behind the forks?

There was a disagreement about the vision and long term goals of the
Axiom project. I cannot speak for any other project but Axiom has the
goal of making a sustainable system that can form the basis for the
science of computational mathematics.

To be sustainable means that users must be able to understand,
maintain, and modify the system. Understanding the system implies that
people can know the "why and what", that is, why a piece of code is
written the way it is and what the code actually does.  The "why" is
generally not available in most systems, even though this is
fundamentally important (e.g. writing the code in a special way was
done to optimize cache-load times). The "what" is generally only
available from published algorithms cached in pay-per-view databases
(e.g. ACM) or other expensive sources (I just paid $350 for a copy of
Luke's special function books). Worse yet, the actual algorithm is
both an original algorithm from a paper plus later, possibly never
published, improvements. Even worse yet, even if you understand the
algorithm and read the code you'll find it a challenge.

It is vitally important to understand the details before changing
the system. Axiom has grown beyond the complexity bound where local
fixes can be safely applied without understanding. (Witness the two
incidents in the past related to algebra fixes). Unless these are
caught by comprehensive, system-independent mathematical test cases
(e.g. the Computer Algebra Test Suite (CATS)) they pass quietly into
incorrect results.

Axiom has been recast into literate documents. The point of this
exercise is to draw together the source materials, the "why" 
explanations, the "what" explanations, the test cases, and all
other related pieces of information. This is intended to be written
in a "literate" style so one can just sit down and read the system
like a book, with the important information being introduce when
the discussion motivates it.

In the long term you should be able to read Axiom from cover to 
cover (unlikely given the volume of material) and get an education
in both Axiom and the underlying computational mathematics. When
you decide to improve the system you can enter into a "conversation"
with the prior developers by updating the surrounding discussion as
well as the code, giving your motivations and insights. People should
be able to publish literate documents at a conference which you just
drag-and-drop onto your system (perhaps during their talk) and it
"just works".

Since this is a long term effort, as indicated by the phrase
"The 30 Year Horizon", it will take a while to approach these goals.

Not everyone cares about this. Some would rather continue building
systems "the old fashioned way", or make it different without caring
why it is the way it is. Documenting code is hard and much more time
consuming than just writing code. And few people are willing to
sacrifice their own time now to benefit other people later. So Axiom's
goals are quite controversial. Thus, the forks.

Its not bad blood. It's a difference of goals. Everyone involved
has excellent and admirable motives for what they do. 

>> Future releases will have a primitive Firefox front end to Axiom,
>similar in spirit (but not design) to the MMA, Maple, and Sage  notebooks.
>> I'm working on various tools in javascript but they are not ready for
>> release yet. I'm also in design discussions with a graphics designer
>> to try to maximize the user viewpoint. This will take a few release
>> cycles to fully emerge.
>Tim, please tell me that Firefox will not be the only way to interface with
>Axiom.  It will still be possible to write an Emacs mode for it, something
>like IMaxima?  Also, why only Firefox, why not any browser?

Well, any browser is fine. But all I have available is Firefox.
I'm not a browser-agile developer so I have no idea what is required
to get new fonts into Opera, or canvas tag support in IE, or graphics
in graphics in Lynx :-)

Hyperdoc was the original help system in Axiom and was way ahead of
its time in the functions it presented. It was designed to allow users
to create new pages, for instance. But over the lifetime of the system
only NAG developed a few new pages. Hyperdoc is difficult to port and
requires an X11 system, special socket handling, etc. Hyperdoc is
special purpose C code I need to maintain.

The new browser front end is designed to allow users to develop new
material in html and javascript, while interacting with Axiom. It
should be completely portable without any special requirements. 
There will be no C code to maintain, although there is new, minimal
javascript/css code.

I did write a wxAxiom (using a fork of the wxMaxima code) but decided
it was yet-another-pile of code to maintain. I like wxMaxima. I just
don't see the advantage of special purpose code when I can leverage
the browser functionality better. I did have to figure out how to
create CSS-based drop-down menus but that's my learning curve issue.

The new browser front end is forming the basis for the Crystal
interface (see the mailing list archives), although this won't
be readily apparent for quite a while.

I believe Martin Rubey (copied on this) has an Emacs mode.
You might consider trying that.

You'll still have all the old interfaces to Axiom, although once
the Firefox front end works I plan to remove all the old hyperdoc
and graphics code. This will significantly improve the ability to
port Axiom to other platforms since most of the issues of porting
have to do with the "portable" C code. 


reply via email to

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