Axiom and Bronstein's source code

[F. B.]

According to Wikipedia, the Axiom computer algebra system is licensed as New BSD.

http://en.wikipedia.org/wiki/Axiom_%28computer_algebra_system%29

It also claims that it contains Bronstein's original implementation of Risch algorithm.

Does it mean that the code could possibly be copied and translated into SymPy? I'm telling you, because I see that there is an ongoing effort to implement the Risch algorithm based on Bronstein's book. If it is possible to import parts of Axiom, maybe the work would be easier.

Apparently Axiom's development has split into FriCAS and OpenAxiom two years ago.

[Aaron Meurer]

Well it's written in Lisp, so "copied and translated" is not the easiest thing.

But yes, I think this is a good idea, especially for the parts that
are not in Bronstein's book, like the algebraic part of the algorithm.
The implementation in Axiom may very well be the best place in the
literature for those parts of the algorithm.

Regarding FriCAS and OpenAxiom, I don't know much about that. My
understanding (which could be completely wrong) is that the old code
that has the deep mathematics, like the Risch algorithm, is not really
touched much, because so few people can understand it, so I wouldn't
be surprised if that part is the same in either.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> For more options, visit https://groups.google.com/groups/opt_out.

[someone]

Hi,

> Well it's written in Lisp, so "copied and translated" is not the
> easiest thing.

No, it is not written in lisp but in "spad". This is a
small language only used by the various Axiom projects.
And it is rather difficult to learn :-/

In any case there is nothing like copy and paste.

I think that copying over snippets of code
would give a very detailed understanding of the
mathematics in Bronstein's book.

> But yes, I think this is a good idea, especially for the parts that
> are not in Bronstein's book, like the algebraic part of the algorithm.

There are some holes in the algebraic branch there too.
But never the less its probably the most complete code
available.

> The implementation in Axiom may very well be the best place in the
> literature for those parts of the algorithm.

Yes, probably.

> Regarding FriCAS and OpenAxiom, I don't know much about that. My
> understanding (which could be completely wrong) is that the old code
> that has the deep mathematics, like the Risch algorithm, is not really
> touched much, because so few people can understand it, so I wouldn't
> be surprised if that part is the same in either.

This is not true, in Fricas there are very interesting things
going on. In particular some new Risch extensions are implemented.
Search the mailing list for details.

[Aaron Meurer]

On Wed, Jan 22, 2014 at 12:33 PM, someone <some...@bluewin.ch> wrote:
> Hi,
>
>
>> Well it's written in Lisp, so "copied and translated" is not the
>> easiest thing.
>
> No, it is not written in lisp but in "spad". This is a
> small language only used by the various Axiom projects.
> And it is rather difficult to learn :-/

Oh I must have been thinking of Maxima.

>
> In any case there is nothing like copy and paste.
>
> I think that copying over snippets of code
> would give a very detailed understanding of the
> mathematics in Bronstein's book.
>
>> But yes, I think this is a good idea, especially for the parts that
>> are not in Bronstein's book, like the algebraic part of the algorithm.
>
> There are some holes in the algebraic branch there too.
> But never the less its probably the most complete code
> available.

Oh sure, no one has a full implementation. But these corner cases are
less likely to actually be used by someone.

The real problem is that the algorithms needed here are not really
implemented in the polys module. And "copy and paste" from Axiom to
the polys module would presumably be much harder than copy and paste
to the risch module.

>
>> The implementation in Axiom may very well be the best place in the
>> literature for those parts of the algorithm.
>
> Yes, probably.
>
>> Regarding FriCAS and OpenAxiom, I don't know much about that. My
>> understanding (which could be completely wrong) is that the old code
>> that has the deep mathematics, like the Risch algorithm, is not really
>> touched much, because so few people can understand it, so I wouldn't
>> be surprised if that part is the same in either.
>
> This is not true, in Fricas there are very interesting things
> going on. In particular some new Risch extensions are implemented.
> Search the mailing list for details.

OK so Fricas is the better one then.

Aaron Meurer

[F. B.]

Oh, that's terrible, why would a program need its own programming language? Back in the 1960s, whene Axiom was initially developed, computer programming was in a primitive stage and communication was very difficult, as there was no internet. I think that having its own language, SPAD, is a big hindrance to its development today.

http://www.euclideanspace.com/maths/standards/program/spad/syntax/index.htm

As for Maxima, it is GPL, its code cannot be copied.

In any case I suggest to find someone who is practical with Axiom's SPAD in order to see if parts of it can be copied into SymPy.

[someone]

Hi,

> Oh, that's terrible, why would a program need its own programming
> language?

Well, why not, think of all kinds of DSPs?

I don't think there was any language suitable to express these
very abstract algebraic structures we need for CA. And in some
way, I doubt that there is such a language today, except, maybe,
Haskell. (All the OO things like C++ or Python can be used to
write algebraic code of course, but it will always be less
concise.) But this is my personal conclusion.

The SPAD language is indeed hard to learn but the ideas are very
elegant and perfectly useful for its purpose. Actually, writing
code in it is very difficult also because of the SPAD compiler
which is not helpful at all in finding programming errors.

> http://www.euclideanspace.com/maths/standards/program/spad/syntax/index.htm

Oh, forget about that. The much better source for information
about SPAD is the "Aldor User Guide". Aldor is the SPAD successor
and became free software in the last year.
It is more clean and well defined but still similar enough
in concept and structure.

Anyway, I'd be surprised if there are more than 50 or 100
people worldwide being able to read and program in Aldor.
(And I'd count myself as 0.5 at most.)

> I think that having its own language, SPAD, is a big hindrance
> to its development today.

Maybe a bit, but I'm not too sure about that. Maxima is written
in Lisp and the development there is extremely slow.

> In any case I suggest to find someone who is practical with Axiom's
> SPAD in order to see if parts of it can be copied into SymPy.

Personally, I'd say that this is a waste of time. Reading the
Axiom source may help to gain even better understanding of the
math, but it would be much easier to just write the code anew.

[someone]

Hi,

> > No, it is not written in lisp but in "spad". This is a
> > small language only used by the various Axiom projects.
> > And it is rather difficult to learn :-/
>
> Oh I must have been thinking of Maxima.

Well, below that SPAD layer, there is Lisp.

> > There are some holes in the algebraic branch there too.
> > But never the less its probably the most complete code
> > available.
>
> Oh sure, no one has a full implementation. But these corner cases are
> less likely to actually be used by someone.

I don't understand why nobody considers filling these holes.
AFAIK the math is completely developed although very complicated.

> The real problem is that the algorithms needed here are not really
> implemented in the polys module. And "copy and paste" from Axiom to
> the polys module would presumably be much harder than copy and paste
> to the risch module.

Right. The category & domain approach taken there is
very interesting both not easily portable to other
systems I think.

> > This is not true, in Fricas there are very interesting things
> > going on. In particular some new Risch extensions are implemented.
> > Search the mailing list for details.
>
> OK so Fricas is the better one then.

Well, depends on the meaning of "better". I compile and
use all three systems more or less regularly, but I spent
most time in Fricas.

[F. B.]

On Thursday, January 23, 2014 2:24:36 AM UTC+1, rl wrote:

I doubt that there is such a language today, except, maybe,
Haskell. (All the OO things like C++ or Python can be used to
write algebraic code of course, but it will always be less
concise.) But this is my personal conclusion.

What about Scala? It's both object-oriented and functional. The European Union has selected Scala to be granted millions of euros of development funds, there are people who claim it is a very good language.
 

 

> http://www.euclideanspace.com/maths/standards/program/spad/syntax/index.htm

Oh, forget about that. The much better source for information
about SPAD is the "Aldor User Guide". Aldor is the SPAD successor
and became free software in the last year.
It is more clean and well defined but still similar enough
in concept and structure.

 I googled a bit, and I found that mattpap has written an interface to IPython for Aldor:

https://github.com/mattpap/IAldor

By the way, he also wrote IScala to embed Scala into IPython:

https://github.com/mattpap/IScala

Maybe Scala would make a good language for a CAS. It supports a Lisp-like macro metaprogramming, it also has a native pattern matching interface on its own code.

He is a SymPy contributor, right?

Personally, I'd say that this is a waste of time. Reading the
Axiom source may help to gain even better understanding of the
math, but it would be much easier to just write the code anew.

Well, that way it would be possible to get inspiration also from Maxima, as long as code isn't copied (as it is GPL).

[Richard Fateman]

I came across this discussion when searching for info on FriCAS and sympy together,
and found the comments to be worthy of some response.

1. The Axiom languages do not go back to the 1960s.  Anything you might say about
them blaming defects on historical  ignorance of those ancient times is probably misplaced.
While there were predecessors to Axiom going back to the Scratchpad project at IBM
(which was late 1960s), the view from the IBM group was that to automate all of mathematics
one needed an appropriate programming language substrate, and none of the existing
programming languages was suitable.

There is a traditional approach in building large systems to define a language layer that
allows for ease of expression.  This is almost inevitable in large lisp systems where ideas
like building interpreters, defining macros for compiling, and other features are often
used. Hence SPAD and ALDOR. 

Frankly, the thought that python is suitable for a CAS base is easily shown to be false by looking
at Sage, and the uncomfortable syntax and misfit between Sage types and python types that
have the same underlying concept.

So python/Sage is wrong.

But the idea that the existence of SPAD and ALDOR is a hindrance to development --- eh,
not obvious.  Unless you have tried to write the same algebraic symbolic code with and without them, (in lower level, say Lisp), you are not in a position to judge.

The note below which suggests reading the code and writing it anew in python might make
sense -- I don't know.   But if someone said to you, look at this short Lisp program. Can you
write it in (say) FORTRAN,   you might say -- sure -- it's not so very different.

Except that to implement the equivalent program in FORTRAN you might have to also
implement a storage allocation / garbage collection system.

So first impressions of the ease of conversion from ALDOR etc to python might also be false.

RJF

The thought that all mathematics would be simple to encode given the right programming language
has been unsuccessfully pursued for about 60 years.  I supervised aPhD thesis circa 1984 on this
general topic.