[Axiom-math] APL, J, and Axiom documentation

[d***@axiom-developer.org]

I have been looking at the question of documenting Axiom's algorithms.

Beyond the english description I've been pondering the use of J (an
ascii version of APL). J/APL, for those who don't know, is an
executable mathematical programming language. Ken Iverson created it
as a language for thought. <http://www.jsoftware.com>

A J description of an algorithm has the appeal that it can be very
precise and compact. It can also be executed to compare the results
with the algorithm. Re-notating the algorithm in J will certain
uncover some existing bugs and/or optimizations in the existing work.

On the down side, J is "its own subculture", meaning that even less
people speak J than speak lisp. In J, the BesselJ function is:

BesselJ=: 1 : '(i.0) H. (1+m.)@(_0.25&*)@*: * ^&m.@-: % (!m.)"_'

where
J0=: 0 BesselJ
j1=: 1 BesselJ

Has anyone here used the language, besides myself?

Tim

[root]

This seems like a bizarre idea to me. Why would you document one program
with another program? Who's to say the J program is correct? This would

far be it from me to propose a bizarre idea :-)

1) You have to code everything twice, with the second implementation in a
very obscure language.

Yes, it does involve coding everything twice, in wildly different
languages. Consider it a feature.

2) You need to verify that both implementations are correct. How can we
ever guarantee that?

Since J/APL is executable the verification would involve testing the
results of one program against the results of the other.

3) You need to learn an obscure language which is understood by almost
nobody.

Hopefully, you're not referring to Spad :-). Yes, it does involve
learning a second language. APL is a language focused on thinking
in a very math-like notation rather than programming linearly.

If I wanted to learn something about the implementation of the BesselJ
function, seeing this would mean nothing to me.

Post by d***@axiom-developer.org
where
J0=: 0 BesselJ
j1=: 1 BesselJ

Sorry, I'll try to be a bit more concise next time :-)

Since the documentation for the program contains another program, doesn't
that program need to be documented too? Also, using J baffles me. APL is
known for being very concise, but nearly unreadable. Why would that help
documentation?

Actually the J program would be a small part of the planned
documentation. If you look in src/algebra/special.spad.pamphlet you
can see the recent implementation of the exponential integral and the
associated documentation.

I must admit, I just don't get this idea. Can you enlighten me?

J/APL has advantage of forcing you to think about the solution to
a problem in a completely orthogonal way to the usual programming
paradigms. In my experience the "re-expression" of an idea in a
second, very different form dramatically highlights the design
decisions made in the first form. Since the original authors are
no longer available we need to tease out the design decisions.

Unfortunately I'm unaware of any category or strongly typed work in J
so I don't think the idea carries much weight beyond the numerics. I
added a piecewise Gamma function to Axiom in February and have been
looking at the special functions since then. J seems to be a good fit
in this area, hence the original remark.

Tim

[M. Edward (Ed) Borasky]

Post by root
J/APL has advantage of forcing you to think about the solution to
a problem in a completely orthogonal way to the usual programming
paradigms. In my experience the "re-expression" of an idea in a
second, very different form dramatically highlights the design
decisions made in the first form. Since the original authors are
no longer available we need to tease out the design decisions.
Unfortunately I'm unaware of any category or strongly typed work in J
so I don't think the idea carries much weight beyond the numerics. I
added a piecewise Gamma function to Axiom in February and have been
looking at the special functions since then. J seems to be a good fit
in this area, hence the original remark.

Well ... at one time I claimed there were only three "original"
programming languages -- Lisp, APL and Forth. So if we call Axiom a
"dialect of Lisp", recoding pieces of it in an APL dialect would give us
two thirds of the spectrum. Perhaps someone would pick up the third??

But I really think the YAGNI principle needs to be observed here. You
Ain't Gonna Need It! :)

[root]

Post by M. Edward (Ed) Borasky

Post by root
J/APL has advantage of forcing you to think about the solution to
a problem in a completely orthogonal way to the usual programming
paradigms. In my experience the "re-expression" of an idea in a
second, very different form dramatically highlights the design
decisions made in the first form. Since the original authors are
no longer available we need to tease out the design decisions.
Unfortunately I'm unaware of any category or strongly typed work in J
so I don't think the idea carries much weight beyond the numerics. I
added a piecewise Gamma function to Axiom in February and have been
looking at the special functions since then. J seems to be a good fit
in this area, hence the original remark.

Well ... at one time I claimed there were only three "original"
programming languages -- Lisp, APL and Forth. So if we call Axiom a
"dialect of Lisp", recoding pieces of it in an APL dialect would give us
two thirds of the spectrum. Perhaps someone would pick up the third??
But I really think the YAGNI principle needs to be observed here. You
Ain't Gonna Need It! :)

Essentially I've been spending a fair amount of time thinking about
Axiom's documentation mechanisms, Axiom's crystal work, and other
design issues. I've read a couple books from the design literature
(and now have joined the dangerously undereducated).

I've been spending time looking at the special functions since
January. One of the insights was that while making the equations
into procedures I was essentially "thinking in APL" (way back in
college I used APL on IBM selectric typeball terminals).

The connection of these two streams led me to look at the idea of
using APL for documentation purposes. Further investigation led me
to J, the ascii version of APL.

While I see the intellectual value of re-thinking by re-coding I'm
not sure J is a worthwhile idea, especially since the J language does
not support Axiom types well. Plus, as Scott points out, it is rather
a "write-only" language so its not clear that it helps anyone but the
person writing the original document.




If we were to re-think by re-coding it would make a lot more sense
to rewrite the algebra into Aldor. We might have the chance to
actually replace some of the existing algebra with the "documented in
Aldor" version. However, this idea comes up once a month and it isn't
going to happen anytime soon. The only possible path I see is the
effort by Gaby to define the "axiom virtual machine". This would
give us a clean API under the algebra which could then be implemented
in Aldor, providing a new portable base.

Unfortunately my guess is that the axiom virtual machine, if it was
reimplemented in Aldor, would likely invoke Greenspun's Tenth Rule:
"Any sufficiently complicated C or Fortran program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of
common lisp." However, if were implemented by cleaning up and
documenting the current version it would not involve that much rework.

One possible idea is to define an API domain which encapsulates the
lisp calls into one domain that exports spad/aldor functionality.
This collects all the lisp interface issues into one domain. I'm
not sure if this is technically possible though since I don't know
what the function signatures would look like. They may have to be
very special purpose signatures.





In any case, documentation ideas are front-and-center in my attention.

The new firefox browser front end is giving us access to a lot of new
tools. The latest task is to try to use JIT, the javascript information
visualization toolkit (see
http://blog.thejit.org/javascript-information-visualization-toolkit-jit)
We can put the algebra hierarchy into these kind of graphs.
Each graph node would be linked to the documentation and sources for
the underlying implementation.

A recoding of this kind of visualization can give the underlying
skeletal machinery to the facets of the crystal. Each node in the
hyperbolic tree is shown onscreen as a crystal facet. Some details of
interest to work out include the ability to "in place edit" in the
browser facet window (nearly possible now) and have the result
recompile into place (somewhat more complex since this would require
restarting Axiom under the crystal).

If we wrap a crystal around each of the Axiom books
(http://axiom.axiom-developer.org/axiom-website/documentation.html),
and put the whole pile into a git-based repository, then each
user could have a complete, personal clone of Axiom. Completed
work could be git-pushed or git-pulled thru a browser "drag-and-drop"
interface.

Architecturally this isn't that far from the possible, which just
leaves the minor issue of coding :-)

Tim

[root]

Post by d***@axiom-developer.org
I have been looking at the question of documenting Axiom's algorithms.
Beyond the english description I've been pondering the use of J (an
ascii version of APL).

I have been studying Sun's Fortress mathematics-oriented programming
language recently and it seems to be able to encode mathematics
algorithm pseudocode that looks very close to the pseudocode. Here is
a .pdf file I put together that contains slides from a Fortress talk
http://sage.ssu.portsmouth.oh.us/tmp/fortress_compared_with_algorithm_pseudocode.pdf

Interesting. I particularly liked the unicode version. I'm puzzled by
the last slide though. It seems to show that Fortress will handle
2D equations, which would be a complete surprise. The ability to
directly write 2D equation input in a programming language would be
a huge leap forward. Its the late 90s and we should be able to handle
such things but I'm unaware of any language that can.

I had a 2D parser on my desk at IBM. Our Scratchpad group had an
effort to do handwritten input. Maple had one also but I don't know
what the outcome was. I gave a sample at ECCAD in Phila. If you ignore
the handwritten portion of the problem it seems you could create a
parser to handle 2D linear typewritten input. Thus a single program
assignment statement such as:

b
a = ------
t
p q

Ideally it would be print/read equivalent to Axiom's Charybdis output.
Ron Avitzur had a really nice, but small, subset of this.
Sounds like a fantastic student project to me.

I've had a small amount of correspondence with Guy Steele about
whether Fortress can support Provisos natively but I've not actually
seen the language up until now.

I'm not sure what ability Fortress will have to handle Axiom-style
types. They aren't required for Fortran and Steele seems to have taken
Fortran as the target replacement language. I'm also not sure if it
can handle the category/domain questions.

If Fortress was suitable for what you had in mind, my thought is that
there is a chance that Sun would provide funding for encoding Axiom's
algorithms in it.

As for funding Axiom from anywhere by anyone... sigh. The only hope I
see for funding is if

(a) Axiom is deeply documented,
(b) Computational Mathematics becomes its own department in many schools,
(c) Axiom gets picked up as the canonical teaching platform.

A fully documented Axiom system would teach people how to read, write
and understand computational mathematics as opposed to the current
"trade-school" mentality which teaches how to use Mathematica, Matlab
and Maple. Of course, by the time these conditions occur a fair portion
of the documentation work will have already been done. I doubt that
the NSF or INRIA have any interest in allocating grants for teaching
computational mathematics as a separate discipline. Instead it seems to
be viewed as a stepchild of either the Math or Comp. Sci. departments.
Curiously, this is exactly where Comp. Sci. was when I went to school.
There were no Comp. Sci. departments or majors. You learned it from the
Math (Fortran), Business (COBOL), or Engineering (Fortran) departments.

Maybe in 10 years....

Tim

[root]

Another thing that comes across fairly clearly in the talk is that Sun
is planning to use Fortress as a way to create a large scientific
computing community just like Java was used to create a large "web
commerce" community. The marketing person in me can't help but think
that Axiom's algorithms would be very useful for helping to achieve
this goal.

<rant>

Oh, please, not ANOTHER attempt. I made myself rather unpopular at the
CalculusFormalLibre conference over this point. A meeting was held to
decide whether there should be an effort to create a new computer
algebra system.

I pointed out that Axiom had been around for about 22 years.
In that time it had a large number of contributors, roughly
300 man-years of research, and about 42 million dollars invested.
It was one of the four large commercial systems along with Maple,
Matlab, and Mathematica. (Axiom was not yet free at the
time but I had been in private discussion with NAG about it).

I did not believe (and still do not) that any new effort will get
that level of sustained funding over so many years. It makes more
sense to start from a prepared base. There are a large number of
not-very-interesting technical issues that need to be re-solved
if you start from scratch. It would be much more productive to
spend any additional resource starting from a prepared base. Then
researchers can add new algorithms and work on the mathematics
rather than the language/porting/graphics/library/interpreter
and all the other uninteresting-but-needed details.

I'm watching Sage struggle over what is essentially a solved problem
in Axiom, that is, how to handle coercion and still be efficient.
That would be fine if it was a research attempt to define a theory
detailing the full lattice of coercions based on category theory.
That would be a lasting contribution to the field of computational
mathematics and would create a much stronger foundation for everyone.

Instead I'm watching what appears to be an ad-hoc war over dynamic
lookup vs performance. Axiom achieves both, getting the dynamic
lookup from the interpreter and performance from the compiler.
Unfortunately Sage is python-based and does not have a compiler.
So this is turning into a python vs cython debate which has NO
long term benefits for the field.

There are many, many more of these debates ahead (eg. noncommutative
issues, OpenMath-like communication issues, non-pythonic type
hierarchies, variable scoping rules, invalid object constructions
(e.g. matrix of streams), simplification, etc.). None of the Sage
discussions of ad-hoc solutions are likely to be of any real
research interest or achieve long term advancement of the field.

Work is being done to rewrite things like symbolic integration
in python when Axiom contains correct, fast, and efficient code
written by the people who invented the theory (Davenport, Trager,
Bronstein, etc.). The Axiom code is well tested and sound. A python
rewrite does not represent an advance.

I do hope that Sage is successful, in whatever sense that might be
taken, since it might expand the number of people who get interested
in the computational mathematics field. But I have to say that I
believe the effort would be much better spent concentrated on a
major code base such as Axiom or Maxima.

Clearly I have an interest in Axiom being chosen so my voice is
highly biased and, therefore, quite suspect and worth ignoring.
Despite that, I do believe I raise a valid point.

Watching SUN pour 42 million dollars into climbing the same mountain
that others have already climbed would be heartbreaking.

</rant>

Tim

[Gabriel Dos Reis]

Post by root

Another thing that comes across fairly clearly in the talk is that Sun
is planning to use Fortress as a way to create a large scientific
computing community just like Java was used to create a large "web
commerce" community. The marketing person in me can't help but think
that Axiom's algorithms would be very useful for helping to achieve
this goal.

<rant>
Oh, please, not ANOTHER attempt. I made myself rather unpopular at the
CalculusFormalLibre conference over this point. A meeting was held to
decide whether there should be an effort to create a new computer
algebra system.

I participated in that conference. I think people just disagreed and
did what they
thought they should do. I don't think anyone had any specific feeling
with respect to you because you were of different opinion.

-- Gaby

[Ted Kosan]

Post by root
I'm not sure what ability Fortress will have to handle Axiom-style
types. They aren't required for Fortran and Steele seems to have taken
Fortran as the target replacement language. I'm also not sure if it
can handle the category/domain questions.

My understanding is that Fortress was designed to support any
application that could benefit from mathematical notation. One of
their design goals appears to be extreme flexibility and they achieved
this by having most of the language specified by libraries.

The talk I obtained the slides from was very illuminating and it
contains the best explanation of Fortress I have been able to find:

http://www.infoq.com/presentations/fortress-steele

My thought is that an Axiom developer would be able to determine
whether or not Fortress can handle Axiom-style types by viewing this
talk.

Another thing that comes across fairly clearly in the talk is that Sun
is planning to use Fortress as a way to create a large scientific
computing community just like Java was used to create a large "web
commerce" community. The marketing person in me can't help but think
that Axiom's algorithms would be very useful for helping to achieve
this goal.

Ted

[M. Edward (Ed) Borasky]

Post by root
I had a 2D parser on my desk at IBM. Our Scratchpad group had an
effort to do handwritten input. Maple had one also but I don't know
what the outcome was. I gave a sample at ECCAD in Phila. If you ignore
the handwritten portion of the problem it seems you could create a
parser to handle 2D linear typewritten input. Thus a single program
b
a = ------
t
p q
Ideally it would be print/read equivalent to Axiom's Charybdis output.
Ron Avitzur had a really nice, but small, subset of this.
Sounds like a fantastic student project to me.

I'll have to go grubbing about in my collection of ancient history, but
IIRC there was a language that did this -- 2D parsing -- on a
Flexowriter in 1965. :)

Really -- I'm not making it up!

Post by root
I've had a small amount of correspondence with Guy Steele about
whether Fortress can support Provisos natively but I've not actually
seen the language up until now.
I'm not sure what ability Fortress will have to handle Axiom-style
types. They aren't required for Fortran and Steele seems to have taken
Fortran as the target replacement language. I'm also not sure if it
can handle the category/domain questions.

Everybody is waiting with bated breath for Fortress. About the only
thing it has going for it in my humble opinion is the marketing weight
of Sun. There are real languages that really exist now that will do
everything I want as efficiently as possible. They are called Scheme,
Forth, Ruby, Axiom, Maxima, Common Lisp, Fortran, C, Perl, R, ...

Post by root
As for funding Axiom from anywhere by anyone... sigh. The only hope I
see for funding is if
(a) Axiom is deeply documented,
(b) Computational Mathematics becomes its own department in many schools,
(c) Axiom gets picked up as the canonical teaching platform.

The thing is that Axiom *was* at one time funded -- it was a commercial
product. It couldn't compete in its market place and now resides
(mostly) in open source. Now there's Sage, which promises to give other
commercial math packages a run for their money.

[M. Edward (Ed) Borasky]

Post by d***@axiom-developer.org
I have been looking at the question of documenting Axiom's algorithms.
Beyond the english description I've been pondering the use of J (an
ascii version of APL). J/APL, for those who don't know, is an
executable mathematical programming language. Ken Iverson created it
as a language for thought. <http://www.jsoftware.com>
A J description of an algorithm has the appeal that it can be very
precise and compact. It can also be executed to compare the results
with the algorithm. Re-notating the algorithm in J will certain
uncover some existing bugs and/or optimizations in the existing work.
On the down side, J is "its own subculture", meaning that even less
where
J0=: 0 BesselJ
j1=: 1 BesselJ
Has anyone here used the language, besides myself?
Tim
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer

Actually, I think the "open-source" dialect of APL is called "A-Plus",
not J. I don't think there's an open-source J implementation.

I've never used any APL -- it was always on my list of things to do but
I never had an opportunity to get paid for it, so other things got
learned. :)

[Scott Morrison]

Hi Tim,

This seems like a bizarre idea to me. Why would you document one program
with another program? Who's to say the J program is correct? This would
mean:

1) You have to code everything twice, with the second implementation in a
very obscure language.
2) You need to verify that both implementations are correct. How can we
ever guarantee that?
3) You need to learn an obscure language which is understood by almost
nobody.

If I wanted to learn something about the implementation of the BesselJ
function, seeing this would mean nothing to me.

Post by d***@axiom-developer.org
where
J0=: 0 BesselJ
j1=: 1 BesselJ

Since the documentation for the program contains another program, doesn't
that program need to be documented too? Also, using J baffles me. APL is
known for being very concise, but nearly unreadable. Why would that help
documentation?

I must admit, I just don't get this idea. Can you enlighten me?

-- Scott

[Ted Kosan]

Post by d***@axiom-developer.org
I have been looking at the question of documenting Axiom's algorithms.
Beyond the english description I've been pondering the use of J (an
ascii version of APL).

I have been studying Sun's Fortress mathematics-oriented programming
language recently and it seems to be able to encode mathematics
algorithm pseudocode that looks very close to the pseudocode. Here is
a .pdf file I put together that contains slides from a Fortress talk
which shows this:

http://sage.ssu.portsmouth.oh.us/tmp/fortress_compared_with_algorithm_pseudocode.pdf

If Fortress was suitable for what you had in mind, my thought is that
there is a chance that Sun would provide funding for encoding Axiom's
algorithms in it.

Ted