\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Tue, 1 Nov 2005 01:04:11 -0500
From: Bill Page
To: Tim Daly
Subject: RE: BAD tim

Tim,

Thanks very much for the good humour and detailed reply.

On October 31, 2005 10:00 PM you wrote:
> 
> Ah, language wars ... the only thing that out-emotions a
> license war

Damn! And I just finished saying I didn't want to start such
a war...

> 
> I suppose, having been cast as the bad guy in this morality
> play, that I'm required to have the long monologue about my
> evil ways (so the hero has time to sneak around behind me
> and kill me) :-) So sit back, grab some coffee, and watch
> the opinions fly...

I wouldn't worry about some sneaky but merely human hero. It's
the spirits of this play that haunt do most of the haunting.
Is that a long echoing evil laugh I hear? Ah, it is still
"All Hallow's Eve" here... :)
http://en.wikipedia.org/wiki/All_Hallows_Eve

What are the tools I need here? Hmmm... \cross and \dagger ?
Trick or treat?

> 
> POINT 1: Axiom needs to be future-proofed.
> 
>    Axiom needs to be torn down, re-architected, re-thought
>    and rewritten cleanly so it can be modularized, maintained,
>    and extended. Which implies a major rewrite, likely done
>    by me.
>

I am not convinced that this is necessary or even possible,
although I do not doubt your knowledge or your ability to do
this - given enough time. According to the history of Axiom
that you have described in various previous emails, Axiom has
already undergone several cycles of re-writing. I don't see
any evidence that such re-writing has resulted in making
Axiom any more "future-proof".

On the other hand I don't think it is necessary, because
Axiom is here now as open source. Axiom is certainly complex
but there are already good examples of other large and complex
open source programs that have managed to attract some very
skilful and dedicated developers who are capable of dealing
with this sort of complexity. The example of the Linux kernel
comes to mind.

Unfortunately, I think it is true that although several years
have passed since Axiom's release as open source, there is
still only one active developer with a thorough knowledge of
Axiom - Tim Daly. In order to best "future proof" Axiom, rather
than re-writing Axiom, I think the best strategy might simply
to give up programming and learn something about genetics and
cloning. ;)  Failing that, there remains the task of documentation
and education. I think you have been doing a great job at that
and I urge you to continue.

> 
> POINT 2: The rewriting will change existing code. 
> 
>    If we look at the "start-up sequence" we see:
> 
>               restart (lisp)
>    init-memory-config (lisp)
>              initroot (lisp)
>                reroot (lisp)
>                  spad (boot)
>               runspad (boot)
>            ncTopLevel (boot)
>             ncIntLoop (lisp)
>               intloop (boot)
>   SpadInterpretStream (boot)
>    intloopReadConsole (boot)
> 
>   and, if you follow the side-paths you'll see the constant
>   switching between boot and lisp at every level in nearly
>   every function.
> 
>   This inhibits "collapsing and rewriting" code which will 
>   have to happen during the rewrite. Functions will either
>   have to be collapsed into lisp or boot.
>

As a long term strategy, I agree, however as I have stated
I think boot is the better choice.
 
>   Historically this interleaving occurs because new function
>   was added/deleted/replaced. The "nc" prefix implies "New
>   Code", a newly rewritten parser that partially replaced the
>   previously newly rewritten parser. The "shoe" code, which is
>   the new, improved "boot" language exists in there. The "meta"
>   code used to exist but is gone. Addition of Fortran support
>   (for NAG), Foreign Language calls (for graphics and the
>   browser), Lisp vendor specific code, etc. required lisp.
>

Why was lisp required? Surely it is possible to do these
things in BOOT. In fact, aren't most of the NAG extensions
written in BOOT? E.g. ls src/interp/nag*
 
> 
> POINT 3: Boot is a dead language. 
> 
>    There are approximately 10 people still living who have coded
>    in boot and every one of them is doing something else with
>    their life. You have to be careful in boot. It is case sensitive 
>    so APPEND is not the same as append.

Wow, that comment certainly dates you! :) Almost all programming
languages in the last 20 (30?) years have been case sensitive.
Usually that is considered an advantage.

>    It is often not clear what a construct will translate to and
>    you end up reading the lisp to learn. A single, misplaced
>    space will change the meaning of the code.

That is true of most programming languages. Understanding a
"construct" by seeing how it "translates" is usually just a
matter of lack of fluency in the language. This can be a result
of inadequate documentation and/or experience. In a language
that syntactically depends on indentation, of course misplaced
spaces can change the meaning of the code. But this is not
essentially different than misplaced commas or braces in other
languages.

> 
> POINT 4: Boot SERIOUSLY complicates the Axiom system. For
> instance:
> 
>   1) Bootstrapping boot
> 
>    The boot compiler is written in boot and needs to be compiled
>    using itself. If you have a running Axiom system this is not
>    a problem. However if you start from a clean lisp system it
>    is a big problem. I cheesed up a way to do this but it is
>    fragile and ugly. But given that we build from scratch there
>    is no other way.

But that is exactly how the C programming language works. The
Gnu C compiler is written in C and bootstrapped in a similar
way.

Also, the current Axiom build starts by first building GCL from
the C sources. This is also a kind of bootstrap process. I don't
see that the BOOT level adds much to this already existing
complexity.

> 
>   2) Makefiles come in multiple stages
> 
>    Boot forces Axiom to be built in stages. Thus Axiom cannot 
>    use modern tools like ASDF. A pure common lisp Axiom interpreter
>    can be built and loaded directly into a lisp image, interpreted
>    or compiled.

I thought there was already a version of interpsys called debugsys
which provides an interpreted environment that is more friendly to
debugging in lisp?

Not being a lisp programmer, it is entirely unclear to me what
advantages ASDF might have over more general tools like 'make'
especially considering that the Axiom source files are actually
literate programming documents (pamphlets), not lisp source code.

> 
>    Lisp, BOOTSYS, DEPSYS, INTERPSYS, AXIOMSYS. These can all be
>    collapsed if Boot disappears.
> 

Although I still recall that this looked very complicated to me
when I first started working with Axiom, now each of these stages
in the current Axiom build process makes sense to me. Since Axiom
is a large and complex system, building it a "layer" at a time
seems quite logical. If these were all collapsed into one, then
I worry that this would all start to look impossibly complicated
to me again.

>   3) lsp, lisp, clisp, ${LISP}
> 
>    All of these exist because boot exists. For example, .clisp
>    is a translated boot file whereas a lisp file is hand coded.
>    ${LISP} exists to smooth over this bump. I won't go into the
>    historical reasons why these came about but they exist as a 
>    side-effect of boot.
> 

Just another type of intermediate file, and Axiom already has
many of these.

>   4) The interpreter has a boot compiler built in
> 
>    There are complications to the interpreter to handle boot-
>    related development from the command line which no-one is
>    ever likely to do again. This code could disappear and, having
>    gone away, simplify the interpreter

This still sounds a little vague, but in general if it was
documented then perhaps someone who was working with BOOT would
find this functionality useful and use it again.

> 
> POINT 5: The boot language is undocumented 
> 
>    It is likely to remain so as one of the authors is dead 
>    and the other one might be. There are no primary sources of
>    documentation.

That does present a problem. But since there is still a lot
of boot code in Axiom, figuring out how boot works and
documenting it does not seem to me to be any more difficult
than figuring out how the boot code works and re-writing it
in lisp.

> 
> POINT 6: Boot does not give you the full power of common lisp.
> 
>    Boot cannot handle backquote, defstruct, and other primitives
>    not to mention CLOS, CLIM, etc. So as lisp evolves boot will
>    "further fork" away from the living edge of lisp ideas and 
>    limit the axiom programmer. 
>

This is true, but I think that perhaps by accident or by design 
it can be largely cast as an advantage. After all, the purpose
of boot is to implement SPAD and the Axiom interpreter in a
language that is higher level than common lisp - not to be a
general purpose programming language.
 
>    Witness the data structures used in boot, mostly lists.
>    Frames are lists of lists, history is a circular list of
>    lists, etc. Where are the data structures? Who will redesign,
>    rewrite, and document boot extensions to fully cover common
>    lisp?

This point was also recently raised by Juergen Weiss. I believe
that his view is that it is possible to extend boot to include
these data structures in boot syntax but that it might be
preferable simply to use boot's built-in mechanism to "escape"
to lisp where necessary to define these structures and then to
call the data structure access methods in the usual way in boot.

> 
> POINT 7: Boot loses program-data symmetry.
> 
>    This is a matter of religion but having been at this game for
>    35 years I've seen a hundred languages built on lisp that try
>    to "eliminate the parens" and all will eventually die (including
>    Python).

I don't see that this has to do with parens or not. Using
parenthesis to denote nested lists is just one more syntax.

> 
>    The paren syntax is fundamental. Look at how Axiom really 
>    works under the covers. It doesn't build boot functions, it
>    builds lisp functions. Why? Because you can cons up a lisp
>    function, compile it, and run it directly. Axiom code and
>    data intermingle in the algebra lisp files. The databases
>    have code and data in them. Data <==> Programs. Fundamental.

I don't agree that lisp has anything special to offer here
except perhaps by being the first language to formalism this
relationship. Any higher level language in which functions are
first order objects has this property, although usually not in
the way it is implemented in lisp. This is especially true in
functional languages like Haskell and Ocaml and probably also
in Aldor. "cons'ing up a lisp function" is just a less structured
way of doing the same thing.

> 
> POINT 8: Tools don't support boot
> 
>    Emacs balances lisp parens. It lets me do lisp function 
>    lookups. It understands the lisp syntax including escape
>    chars. SLIME lives in emacs and provides support. Code
>    walkers walk lisp code. Pretty printers understand lisp.
>    Debuggers understand lisp (I want to fix it in the language
>    I broke it in). ASDF can manipulate lisp. Programmers 
>    speak lisp. Blank spaces don't break lisp.
> 
>    Boot is unsupported anywhere by anything.

Kai Kaminiski has written a simple emacs mode for boot.
See http://wiki.axiom-developer.org/AxiomInEmacs Boot is
syntactically similar to Python so if there was a need for
enhanced emacs support, then I expect a lot of this
functionality could simply be "borrowed" from the Python
extensions of emacs (and other syntax aware editors).

I think it remains to be seen how some of these other lisp
tools could be used with Axiom.

I don't know many people who "speak lisp" except perhaps
during severe rapid eye movement while asleep. ;)

> 
> 
> POINT 9: Where are the programmers?
> 
>    Who will write in boot? I'm the only person likely to be
>    hacking the interpreter for the near future, mostly because
>    it is so big, ugly, unstructured, and undocumented. Even if
>    people code in boot to maintain the interpreter how often
>    will they do that? How will they maintain their skill at
>    writing boot? I've written many, many thousands of lines of
>    lisp and use it continuously. Who are the programmers who
>    will do that in boot?

I agree! That is the #1 question. But besides Tim Daly, where
are the other lisp programmers? How will they maintain their
skills at using lisp in Axiom?

Axiom is now open source and is at least potentially exposed
to a much larger range of people than ever before. I believe
that in the future there is a good chance that the people who
may help to maintain and further develop Axiom will be those
people who started by writing Axiom library code in SPAD.
>From SPAD it is a natural step down the ladder to programming
in boot. I expect that many of these people would never have
had any previous exposure to lisp. So forcing them to program
in lisp just to maintain Axiom would probably feel more like
"falling off the ladder" than just stepping down.

Of course this is currently mostly speculation (with the
exception perhaps of myself and Martin Rubey).

> 
> POINT 10: Boot was an experiment in surface syntax
> 
>    Historically Axiom was a platform for experimenting with 
>    many research topics. One of these topics was a favourite
>    of Dick Jenks and Bill Burge, that of language design.
>    Scratchpad, now called Axiom, was changed many times to
>    introduce new ideas. This research is no longer the point
>    of Axiom and is better done elsewhere. We neither have the 
>    expertise nor the research goal of surface language design.
>    Let Python do that. Or Spad/Aldor fans.

I think the Python designers also (for the most part) consider
their work done.

I thought Spad/Aldor was an essential part of Axiom and
necessarily closely related to the Axiom interpreter, so I
am not sure what you mean by your last comment.

> 
> POINT 11: Do language design where it counts.
> 
>    If we are going to devote research effort toward language
>    design lets do it at the Spad/Aldor level where it counts.
>    This is where the real language expertise should be applied.

I agree. I don't see any serious need to re-design the boot
language - simply to document it as it works now.

>    For instance, why do I have to write programs to express
>    functions?

In Axiom you can already expression functions in other ways
than imperative code. The Axiom interpreter, SPAD and Aldor
have a (more or less) complete functional subset.

>    Why can't I write a domain using equations? Why doesn't
>    the Spad language support that?

Could you elaborate on what you mean by "write a domain using
equations"? Are you talking about an alternative to the way
that Axiom implements "axioms" now simply by assertion?

> 
> POINT 12: Future directions assume lisp
> 
>    Notice that one of the near future goals is to connect Axiom
>    and ACL2. ACL2 understands lisp-ish kind of languages, not
>    boot.

Besides the fact that ACL2 is implemented in lisp, I don't see the
connection between ACL2 and "lisp-ish" languages when it comes
to proving program correctness.

There are other tools similar to ACL2 such as Coq which is not
written in lisp at all. Coq has already been used with Axiom
in some research.

> 
> 
> and now, on to the recent changes
> 
> POINT 13: Don't break code until you understand it.
> 
>    I'm working hard to understand the code so the existing code
>    is a straightforward translation (well, mostly, with some
>    rewrites that I know are logically equivalent).
> 
>    Once I've completely figured out the various twists and turns,
>    uses and references, and other points I'll be recoding the
>    whole process. There is no reason (other than historical) why
>    there are a dozen entry points into the interpreter that set
>    weird, undocumented, stateful flags. All that cruft must go
>    away.

I agree with all that, while de-emphasizing the need to remove
all of the cruft right now. But I fail to see why recoding
anything from boot into lisp is involved.

> 
>    So the code is ugly. At the moment. But it will get better,
>    cleaner, clearer, more robust, and easier to change. History
>    and Frames, for example will use structures that don't depend
>    on 
>       (caar (cdddddr (cdddddr x)))
> 
>    It takes time. It takes work, probably 2-3 years worth of
>    work.

I think you worry too much about how "ugly" to current code is.
It works. That is what matters most to people who want to begin
using Axiom now. I doubt that there is much you can do to the
Axiom internal code in the way of re-writing it into lisp that
would make it any more appealing to this putative new generation
of Axiom users. Still I am hopeful that among the thousands of
new people who have recently been exposed to Axiom, there will
be some who will want to take up the challenge of dealing with
what's on the inside. If/when they arrive, I think it is more
important to have good documentation than it is to have pretty
code.

>   
> and now, on to the personal...
> 
> POINT 14: I'm a lisp programmer 
>    
>    (clearly)
> 

I don't seen anything inherently evil in that. :)

\start
Date: Mon, 31 Oct 2005 22:15:37 -0800
From: Bob McElrath
To: Cliff Yapp, Tim Daly
Subject: re: Boot vs. Lisp


C Y [Cliff Yapp] wrote:
> > I agree that using *both* Lisp and BOOT is probably more
> > complicated than it needs to be. But my solution to this
> > would be precisely opposite the solution proposed by Tim.
> > What I would greatly prefer is to replace the Lisp in
> > Axiom with BOOT, where possible. I think the only place
> > where Lisp is required is in the bootstrap for the BOOT
> > compiler itself. And even there, BOOT could be weened from
> > it's mother Lisp and live on it's own like ML, Aldor, and
> > some other languages that started out in Lisp - but I am
> > not really advocating that in the short term.
> 
> In doing so we basically commit to writing our own development
> environments and tools, as well as leaving a language that has an
> established ANSI standard.  That may be worth it, but I'm going to be a
> hard sell. ;-)

Having worked on a couple projects which involved some form of custom
language...

It is far, far more important to have a system which people can jump
into quickly than it is to have a system that is complete, thorough, and
consistent.  If it is easy to get into, it will become complete,
thorough, and consistent eventually.

By writing in a language no one has ever heard of, the project will be
doomed to those that already know it, and those that have a lot of time
on their hands.  Open source development is "itch scratching" and if it
takes a month to figure out how to scratch the itch, most people won't
do it.

Complexity of software scales as exp(size).  Doubling the size
(maintaining a compiler too) means far more than double the work, and
will require far more than double the coders.

I don't really care what language is used.  I've used around 40 in my
life and can learn another.  But Axiom will die if it is necessary to
maintain a compiler also, and it will die if other people can't pick it
up quickly and contribute.  KISS.

I agree wholeheartedly with Tim on much of this:

root [Tim Daly] wrote:
> POINT 3: Boot is a dead language. 
> 
>    There are approximately 10 people still living who have coded in
>    boot and every one of them is doing something else with their
>    life. You have to be careful in boot. It is case sensitive so APPEND
>    is not the same as append. It is often not clear what a construct
>    will translate to and you end up reading the lisp to learn. 
>    A single, misplaced space will change the meaning of the code.
> 
> POINT 4: Boot SERIOUSLY complicates the Axiom system. For instance:
> 
>   1) Bootstrapping boot
> 
>    The boot compiler is written in boot and needs to be compiled
>    using itself. If you have a running Axiom system this is not a
>    problem. However if you start from a clean lisp system it is a
>    big problem. I cheesed up a way to do this but it is fragile and
>    ugly. But given that we build from scratch there is no other way.
> 
>   2) Makefiles come in multiple stages
> 
>    Boot forces Axiom to be built in stages. Thus Axiom cannot use modern
>    tools like ASDF. A pure common lisp Axiom interpreter can be built
>    and loaded directly into a lisp image, interpreted or compiled.
> 
>    Lisp, BOOTSYS, DEPSYS, INTERPSYS, AXIOMSYS. These can all be
>    collapsed if Boot disappears.
> 
>   3) lsp, lisp, clisp, ${LISP}
> 
>    All of these exist because boot exists. For example, .clisp is a
>    translated boot file whereas a lisp file is hand coded. ${LISP}
>    exists to smooth over this bump. I won't go into the historical
>    reasons why these came about but they exist as a side-effect of boot.
> 
>   4) The interpreter has a boot compiler built in
> 
>    There are complications to the interpreter to handle boot-related
>    development from the command line which no-one is ever likely to
>    do again. This code could disappear and, having gone away, simplify
>    the interpreter
> 
> POINT 5: The boot language is undocumented 
> 
>    It is likely to remain so as one of the authors is dead and the other
>    one might be. There are no primary sources of documentation.
> 
> POINT 8: Tools don't support boot
> 
>    Emacs balances lisp parens. It lets me do lisp function lookups. It 
>    understands the lisp syntax including escape chars. SLIME lives in 
>    emacs and provides support. Code walkers walk lisp code. Pretty 
>    printers understand lisp. Debuggers understand lisp (I want to fix
>    it in the language I broke it in). ASDF can manipulate lisp. Programmers 
>    speak lisp. Blank spaces don't break lisp.
> 
>    Boot is unsupported anywhere by anything.
> 
> POINT 9: Where are the programmers?
> 
>    Who will write in boot? I'm the only person likely to be hacking
>    the interpreter for the near future, mostly because it is so big,
>    ugly, unstructured, and undocumented. Even if people code in boot
>    to maintain the interpreter how often will they do that? How will
>    they maintain their skill at writing boot? I've written many, many
>    thousands of lines of lisp and use it continuously. Who are the
>    programmers who will do that in boot?
> 
> POINT 12: Future directions assume lisp
> 
>    Notice that one of the near future goals is to connect Axiom and
>    ACL2. ACL2 understands lisp-ish kind of languages, not boot.

\start
Date: Tue, 1 Nov 2005 08:09:02 +0200
From: Vladimir Bondarenko
To: Tim Daly
Subject: Re: BAD tim
Cc: list

ThD> (so the hero has time to sneak around behind me and kill me) :-)

My heart is set strongly against this ;)

Viva la Tim! ;-)

\start
Date: Tue, 1 Nov 2005 01:56:37 -0500
From: Bill Page
To: Bob McElrath
Subject: re: Boot vs. Lisp

Bob,

After this reply, I promise to "give it a rest" ... :)

On November 1, 2005 1:16 AM you wrote:

> C Y [Cliff Yapp] wrote:
> ... 
> Having worked on a couple projects which involved some form of
> custom language...
> 
> It is far, far more important to have a system which people can
> jump into quickly than it is to have a system that is complete, 
> thorough, and consistent.  If it is easy to get into, it will
> become complete, thorough, and consistent eventually.
>

I agree with this. But from my point of view the BOOT language
embedded in Axiom is much easier to "jump into quickly" compared
to lisp, if your starting point is SPAD or if you had previously
programmed in Python (unless you also happen to be a lisp
programmer).
 
> By writing in a language no one has ever heard of, the project
> will be doomed to those that already know it, and those that
> have a lot of time on their hands.  Open source development
> is "itch scratching" and if it takes a month to figure out how
> to scratch the itch, most people won't do it.

I cannot help but counter this view with another quote from
Norvig:

Teach Yourself Programming in Ten Years

http://www.norvig.com/21-days.html

"Researchers (Hayes, Bloom) have shown it takes about ten
years to develop expertise in any of a wide variety of areas,
including chess playing, music composition, painting, piano
playing, swimming, tennis, and research in neuropsychology
and topology."

He claims this applies to programming as well and I doubt
that he would have any objection to adding computer algebra
systems to the list.

Of course we aren't talking about learning to program just to
make small changes to Axiom. We must assume that the people
who choose to work on Axiom already have quite a lot of other
relevant experience including programming in several languages.
I think this is what limits the potential developers much more
than just learning another new language.

> 
> Complexity of software scales as exp(size).  Doubling the
> size (maintaining a compiler too) means far more than double
> the work, and will require far more than double the coders.

Maintaining both a library compiler (SPAD) and an interpreter
(an integral part of the user interface) is inherent in the
design of Axiom. BOOT is closely related to SPAD (or perhaps
better said, SPAD is closely related to BOOT). So really there
is no additional compiler to maintain.

> 
> I don't really care what language is used.  I've used around
> 40 in my life and can learn another.  But Axiom will die if it
> is necessary to maintain a compiler also,

I don't agree. I think maintaining a compiler as part of Axiom
is essential.

> and it will die if other people can't pick it up quickly and
> contribute.  KISS.

That might be true. But I think we need to be very clear what
you mean by "pick it up". If you mean "learn to use Axiom to
solve some relatively simple algebraic problem", then I don't
think Axiom is much worse off than any other computer algebra
system in that regard. From there to programming Axiom library
routines is not such a big step. And there are other things
that one would need to "pick up" before one could start making
changes to Axiom itself.

\start
Date: Tue, 01 Nov 2005 03:56:16 -0600
From: MathAction (unknown)
To: MathAction
Subject: [MathAction] Heavy frontpage

A small suggestion: The frontpage that is opened upon typing http://axiom-developer.com is  too long and heavy. and sometimes looks scarcy.

Please avoid at least the issue-tracker stuff.

\start
Date: Tue, 1 Nov 2005 12:46:43 +0100 (CET)
From: Bertfried Fauser
To: Tim Daly
Subject: Re: BAD tim

Dear Tim,

	thank you for your long mail and the invitation to a coofee which
I took while reading...

Perhaps I may add, that as a _user_ of AXIOM, I am totally ignorant to its
internal struggles (bild process from scratch, historical accidents, etc),
but that I need to focus my resources. I am not a programmer, but need to
be able to develop own functionality. So I would vote for a system having
1 internal language (lisp, C++, ...) and probably one toplevel language
(Aldor, spad, ...). Any further mixing prevents a _user_ from even making
first steps.

Hence I would at least like to have a winner of the lanuage war, alas such
stories usually will have no ... and they lifed happyly ever after.

\start
Date: Tue, 1 Nov 2005 07:35:46 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: re: Boot vs. Lisp

> Bob,
> 
> After this reply, I promise to "give it a rest" ... :)

Heh - sorry, I can't resist replying.  Ignore me if
if you like - the short version is if I were to vote
I'd cast my vote for Lisp, somewhat because of my own
bias but mostly because Tim is accomplishing a lot
of stuff and I'm eager to see that continue.

Bill, one point is that the the current codebase already
works and uses BOOT, so if at some point in the future
we discover that Lisp was in fact a mistake (I doubt that
but I'll postulate it for discussion) we can just come
back to where we are now, grab the BOOT code, stick it
in in whatever the current literate documents are in place
of the Lisp code, and fill in the holes.  That's the
real beauty of the whole literate document idea - the IDEAS
will work regardless of the language, and while it would
be annoying having to redo the work in BOOT it would just
be a question of implementing the ideas in BOOT, as opposed
to puzzling out Lisp code and THEN writing them in BOOT.  So
I don't think it's irrecoverable in any case, no matter what
happens, since we are in the decidely unusual position of
starting not from scratch but from a fully functional system.
All mathematical work done in SPAD/Aldor doesn't have to care
one way or the other, so that work survives regardless, and
I'm really hopeful that we will reach a point where most
significant work in Axiom takes place at that level, because
that will mean Axiom is functioning as a mathematical and 
scientific research platform.
 
> On November 1, 2005 1:16 AM you wrote:
>
> I agree with this. But from my point of view the BOOT language
> embedded in Axiom is much easier to "jump into quickly" compared
> to lisp, if your starting point is SPAD or if you had previously
> programmed in Python (unless you also happen to be a lisp
> programmer).

Two points I wish to mention - 1) The CAS community is a small subset
of the total programming community, but within that community Lisp is a
much bigger deal than otherwise - I think it is this community we are
likely to attract, rather than the general community 2) SPAD will only
be a starting point for people who have programmed a lot of SPAD code
(not many currently) and also want to work on the internals of Axiom
the program.  I'm hoping this will actually work a bit in reverse -
programmers who are not up on the heavy duty mathematics side so much
(for high level math that's most of them, at a guess) will start out by
working on the Lisp side (with its documentation, tools, etc. to help
them getting started with Lisp) and then graduate to working on the
mathematical side, where learning SPAD/Aldor will be part of learning
to express high level mathematics in a computer.  Actual honest to
goodness mathematical researches and scientists are probably the LAST
people who want to work on the guts of Axiom except out of need for a
working tool - they want to USE it to do other stuff.  They'll be
working at the Aldor/SPAD level, and any need to go lower will probably
get reported as a bug to be fixed by the team.  After all, how many
scientists would request to hack on the Mathematica source code?  They
want it to solve problems without their needing to do that.  Since we
want to become a rising force in the mathematical community our goal
has to be to provied a program where people can focus on the math
rather than the program.  (Of course, this is all speculation so it may
or may not be worth anything.)
  
> > By writing in a language no one has ever heard of, the project
> > will be doomed to those that already know it, and those that
> > have a lot of time on their hands.  Open source development
> > is "itch scratching" and if it takes a month to figure out how
> > to scratch the itch, most people won't do it.
> 
> I cannot help but counter this view with another quote from
> Norvig:
> 
> Teach Yourself Programming in Ten Years
> 
> http://www.norvig.com/21-days.html
> 
> "Researchers (Hayes, Bloom) have shown it takes about ten
> years to develop expertise in any of a wide variety of areas,
> including chess playing, music composition, painting, piano
> playing, swimming, tennis, and research in neuropsychology
> and topology."
> 
> He claims this applies to programming as well and I doubt
> that he would have any objection to adding computer algebra
> systems to the list.

I agree, but isn't this in fact what Axiom is trying to address by
bringing the program closer to the mathematics?  To allow researchers
who have put in the ten years to get good at mathematics to use a
significant part of those abilities as is in Axiom?  The goal is to
allow mathematicians to be mathematicians without being programmers any
more than actually necessary to completely specify their problems,
which is one of the brand new things about Axiom.

> Of course we aren't talking about learning to program just to
> make small changes to Axiom. We must assume that the people
> who choose to work on Axiom already have quite a lot of other
> relevant experience including programming in several languages.

I disagree - I think we want to appeal to mathematicians and
scientists, who quite often are NOT (or don't want to be) computer
programmers.  

> I think this is what limits the potential developers much more
> than just learning another new language.

Maybe I'm alone in making the distinction between Axiom the
programmer's challenge and Axiom the mathematical environment, but I'm
hoping that level of abstraction is possible because it is likely to
appeal to non-programmers.

> > Complexity of software scales as exp(size).  Doubling the
> > size (maintaining a compiler too) means far more than double
> > the work, and will require far more than double the coders.
> 
> Maintaining both a library compiler (SPAD) and an interpreter
> (an integral part of the user interface) is inherent in the
> design of Axiom. BOOT is closely related to SPAD (or perhaps
> better said, SPAD is closely related to BOOT). So really there
> is no additional compiler to maintain.

You mean the same compiler compiles both BOOT and SPAD with no
additional complexity added due to compiling BOOT?

> > I don't really care what language is used.  I've used around
> > 40 in my life and can learn another.  But Axiom will die if it
> > is necessary to maintain a compiler also,
> 
> I don't agree. I think maintaining a compiler as part of Axiom
> is essential.

But mathematicians aren't going to want to work on a compiler (it's
hard to get funding for things like that.)  They want to do math.

> > and it will die if other people can't pick it up quickly and
> > contribute.  KISS.
> 
> That might be true. But I think we need to be very clear what
> you mean by "pick it up". If you mean "learn to use Axiom to
> solve some relatively simple algebraic problem", then I don't
> think Axiom is much worse off than any other computer algebra
> system in that regard. 

There, I agree.

> From there to programming Axiom library
> routines is not such a big step. 

Also agree.

> And there are other things
> that one would need to "pick up" before one could start making
> changes to Axiom itself.

True.  But I think wanting to make changes to Axiom itself will be a
different job from wanting to create new mathematical abilities.  It is
quite possible there are others (like me) who are not likely to make
any spectacular mathematical contributions to Axiom but are interested
in providing features and functionality for those who can.  For folks
like me, the guts of Axiom being similar to the high level language is
pretty much totally irrelevant.  In THAT situation, there is a clear
advantage to not using a custom language, because hypothetically if I
were a good Lisp programmer (Granted I'm not at the moment) I could
hook in FFI bindings to the GNU Scientific Libraries.  Starting from
BOOT I haven't got the faintest idea of how to proceed.  Lots of things
like that will crop up over time, and Lisp already is working on the
problem of being able to interface with a large number of foreign
libraries via FFI.

In the end, Tim is being very producive, and that's a really rare
thing.  I'm cheering him on regardless - literate documents will make
sure Axiom survives any language.  If someone wants someday to do a new
CAS, we want to set things up so that to do anything other than start
associating code with the documentation part of the Axiom literate
pamphlets wouldn't make any sense at all :-).

\start
Date: 01 Nov 2005 11:47:14 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: --patch46

Greetings!

Bill Page writes:

> Camm,
> 
> On October 31, 2005 9:31 AM you wrote:
> > 
> > Greetings!  And please excuse me -- this thread has slipped under
> > the radar here.
> 
> No problem.
> 
> > 
> > Bill, here is the problem -- Redhat 9 is apparently placing the
> > stack within the first 1Gb of memory, but you are requesting this
> > amount for your heap.  GCL won't (or tries not to) allow the head
> > to overrun the stack: 
> > ... 
> > In all of the machines I've looked at, this is about the worst
> > stack placement I've seen.  Is this 'enterprise' or 'normal'?
> 
> Actually, I don't know very much about this server. It is a
> "Unmanaged Virtual Servers (VPS/VDS)" hosted at a commercial
> ISP called RoseHosting. (This is the system which runs MathAction
> and for which Tim Daly is still paying the full operational
> costs.) http://www.rosehosting.com
> 
> Can you deduce anything from the following system information:
> 
>   # uname -a
>     Linux axiom-developer.org 2.6.11.10-RH1956 #9 SMP
>       Fri May 20 20:48:44 CDT 2005 i686 i686 i386 GNU/Linux
> 

This is a recent kernel.  The stack placement is probably a kernel
configuration option (I hope -- we still run 2.4).

> I think that what we have is a legacy RedHat 9 configuration.
> According to the RoseHosting website, we could probably upgrade
> to a Fedora Core 4 configuration.
> 
> Perhaps if I contacted the admins at RoseHosting, I might be
> able to get more details.
> 

OK.

> > I thought the former had a sophisticated mechanism to push
> > the stack and the shared memory area as high up in memory
> > as possible.
> > 
> > I know of no way to change this short of getting a different
> > Linux kernel, where the issue should be addressable.
> > 
> 
> I think the above info suggests we are running 2.6.11.10.
> That's fairly new isn't it?
> 
> > One thing we could do is relax the power of two constraint
> > on maxpages if a lesser amount would suffice.
> >
> 
> Yes, very likely a lesser amount would suffice.
>  

OK, will look into this and consider putting into 2.6.8pre.

> > 
> > You say there is another work around with
> > si::allocate-contiguous-pages, which I suspect to be a
> > feather-edge manipulation issue, but am not sure.  You
> > can check this out by doing (room) after your job has
> > completed and seeing how close you are to OOM.
> 
> Ok. Here is the output of (room) in the case of setting
> si::allocate-contiguous-pages, see:
> 
> http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs
> 
> )lisp (room)
>   1528/1528   59.3%       4 CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
>     94/200    99.9%         FIXNUM SHORT-FLOAT CHARACTER
>                             RANDOM-STATE READTABLE SPICE
>    340/500    75.9%         SYMBOL STREAM
>      1/8      23.1%         PACKAGE
>     65/400    99.0%         ARRAY HASH-TABLE VECTOR BIT-VECTOR
>                             PATHNAME CCLOSURE CLOSURE
>    500/500    53.3%       1 STRING
>    195/331    99.8%       2 CFUN BIGNUM
>     40/115    97.6%         SFUN GFUN VFUN AFUN CFDATA
>   3000/3000               2 contiguous (237 blocks)
>        1476                 hole
>        1000   73.5%       1 relocatable
>       2763 pages for cells
>       8239 total pages
>     116036 pages available
>       6797 pages in heap but not gc'd + pages needed for
>            gc marking
>     131072 maximum pages
> Value = NIL
> 


You have plenty of room here.  Is this before or after running the job
which required the allocate-contiguous-pages?

> -------
> 
> >From this output how can I tell how "close I am to OOM"? Maybe
> the FIXNUM ... memory is a problem? What can I do about that?
> 
> > In addition to the contiguous page function you've found, here
> > are some other ways to explicitly allocate memory to various
> > types:
> > 
> > (si::allocate 'cons 400)
> > (si::allocate-relocatable-pages 10000)
> > <will explain the allocate sgc functions later if desired>
> 
> How can I related these to the output of (room)?
> 

"pages available" tells you about proximity to OOM.  The two functions
mentioned above, in addition to si::allocate-contiguous-pages, alter
the denominator of the corresponding type output by room.  I.e. it
will allow allocation up to this amount without trying to clear space
with a gc.

> > 
> > The typed pages are self-explanatory I'd think.  Contiguous
> > pages are used for untyped memory which cannot be moved,
> > typically compiled-code.  relocatable-pages hold untyped
> > memory to which no pointer refers directly (i.e. outside of
> > a lisp object, where we can control the reference in the
> > garbage collector), string bodies, bignum bodies, certain
> > arrays, etc.
> 
> Where do FIXNUM ... things live?
> 

In 2.6, fixnums, short-floats, and long-floats all reside in unmovable
locations in correspondingly typed pages on the heap.  There is a
small fixnum table outside the heap in the text function of the
executable.  In 2.7, most fixnums are immediate fixnums consuming no
memory but overlaying the memory range reserved by the kernel.

Take care,

> > 
> > Here is a bit of clarification on the room report:
> > 
> >    211/211    42.9%   CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
> >    
> >    ^  pages allocated for this type
> >         ^  maximum pages before triggering GC
> >               ^  Percent of the allocated pages holding live
> >                  objects
> > 
> > =============================================================
> > >(room)(si::allocate 'cons 400)(room)
> > 
> >    211/211    42.9%         CONS RATIO LONG-FLOAT COMPLEX
> >                             STRUCTURE
> >      2/28     40.8%         FIXNUM SHORT-FLOAT CHARACTER 
> >                             RANDOM-STATE READTABLE SPICE
> >     47/49     72.9%         SYMBOL STREAM
> >      1/2      12.8%         PACKAGE
> >      1/38     56.8%         ARRAY HASH-TABLE VECTOR
> >                             BIT-VECTOR PATHNAME CCLOSURE
> >                             CLOSURE
> >     16/32     85.8%         STRING
> >      3/27     98.3%         CFUN BIGNUM
> >      6/115    88.1%         SFUN GFUN VFUN AFUN CFDATA
> > 
> >    347/512                  contiguous (86 blocks)
> >        13107                hole
> >        5242    0.0%         relocatable
> > 
> >        287 pages for cells
> >      18983 total pages
> >     101769 pages available
> >      10320 pages in heap but not gc'd + pages needed for gc marking
> >     131072 maximum pages
> > 

\start
Date: Tue, 1 Nov 2005 12:50:33 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: --patch46

Camm,

On November 1, 2005 11:47 AM you wrote:
> ...
> > 
> >   # uname -a
> >     Linux axiom-developer.org 2.6.11.10-RH1956 #9 SMP
> >       Fri May 20 20:48:44 CDT 2005 i686 i686 i386 GNU/Linux
> > 
> 
> This is a recent kernel.  The stack placement is probably a
> kernel configuration option (I hope -- we still run 2.4).

Do you think stack placement could have something to do with
running as a shared virtual server?

> > 
> > Ok. Here is the output of (room) in the case of setting
> > si::allocate-contiguous-pages, see:
> > 
> > http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs
> > 
> > )lisp (room)
> >   1528/1528   59.3%       4 CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
> >     94/200    99.9%         FIXNUM SHORT-FLOAT CHARACTER
> >                             RANDOM-STATE READTABLE SPICE
> >    340/500    75.9%         SYMBOL STREAM
> >      1/8      23.1%         PACKAGE
> >     65/400    99.0%         ARRAY HASH-TABLE VECTOR BIT-VECTOR
> >                             PATHNAME CCLOSURE CLOSURE
> >    500/500    53.3%       1 STRING
> >    195/331    99.8%       2 CFUN BIGNUM
> >     40/115    97.6%         SFUN GFUN VFUN AFUN CFDATA
> >   3000/3000               2 contiguous (237 blocks)
> >        1476                 hole
> >        1000   73.5%       1 relocatable
> >       2763 pages for cells
> >       8239 total pages
> >     116036 pages available
> >       6797 pages in heap but not gc'd + pages needed for
> >            gc marking
> >     131072 maximum pages
> > Value = NIL
> > 
> 
> You have plenty of room here.  Is this before or after running
> the job which required the allocate-contiguous-pages?

It is after running the job. If I omit the call to
allocate-contiguous-pages, then I get the following error
message:

    >> System error:
    Contiguous blocks exhausted.
  Currently, 1354 pages are allocated.
  Use ALLOCATE-CONTIGUOUS-PAGES to expand the space.

and Axiom aborts.

\start
Date: Tue, 01 Nov 2005 12:01:19 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [MathAction] 

A small suggestion: The frontpage that is opened upon typing
http://axiom-developer.org is too long and heavy. and sometimes
looks scarcy.

\start
Date: Tue, 1 Nov 2005 10:11:10 -0800
From: Bob McElrath
To: Tim Daly
Subject: Re: BAD tim

I've said it before, but...

This whole argument can be broken down into: who is coding, and what
does he want?

The answer is Tim, and he's going to get what he wants by default.

...Unless one of the rest of us is willing/able to pony up the level of
work that Tim is doing, then it makes sense for the two to get together
and discuss strategy.

Correct me if I'm wrong, but who else besides Tim is actively
boot-ifying or lisp-ifying things?

I wish I had the time.  I spent an hour on the phone yesterday with some
Mathematica support rep with a bad french accent because their license
manager decided I wasn't worthy to install the turd.  In the end, it was
a bug in their license manager.  What a waste of my time.  I would far
rather hack on axiom.

\start
Date: Tue, 01 Nov 2005 12:13:52 -0600
From: MathAction (billpage)
To: MathAction
Subject: [MathAction] Subtopics display disabled on FrontPage

I agree that the FrontPage was too large. The bulk of the page
was actually automatically generated by the ZWiki 'show_subtopics'
option. Since the FrontPage (by design) is linked to a large
number (maybe even all) of the pages that follow, the subtopics
list was very large and probably not very useful. So I have
disabled the subtopics display on this FrontPage.

You can get a similiar list on demand by clicking 'contents'.

\start
Date: 01 Nov 2005 13:45:24 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: --patch46

Greetings!

Is there any way you could arrange access for me to this machine?  It
might be a while before a time window opens for me to look into this.

Take care,

Bill Page writes:

> Camm,
> 
> On November 1, 2005 11:47 AM you wrote:
> > ...
> > > 
> > >   # uname -a
> > >     Linux axiom-developer.org 2.6.11.10-RH1956 #9 SMP
> > >       Fri May 20 20:48:44 CDT 2005 i686 i686 i386 GNU/Linux
> > > 
> > 
> > This is a recent kernel.  The stack placement is probably a
> > kernel configuration option (I hope -- we still run 2.4).
> 
> Do you think stack placement could have something to do with
> running as a shared virtual server?
> 
> > > 
> > > Ok. Here is the output of (room) in the case of setting
> > > si::allocate-contiguous-pages, see:
> > > 
> > > http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs
> > > 
> > > )lisp (room)
> > >   1528/1528   59.3%       4 CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
> > >     94/200    99.9%         FIXNUM SHORT-FLOAT CHARACTER
> > >                             RANDOM-STATE READTABLE SPICE
> > >    340/500    75.9%         SYMBOL STREAM
> > >      1/8      23.1%         PACKAGE
> > >     65/400    99.0%         ARRAY HASH-TABLE VECTOR BIT-VECTOR
> > >                             PATHNAME CCLOSURE CLOSURE
> > >    500/500    53.3%       1 STRING
> > >    195/331    99.8%       2 CFUN BIGNUM
> > >     40/115    97.6%         SFUN GFUN VFUN AFUN CFDATA
> > >   3000/3000               2 contiguous (237 blocks)
> > >        1476                 hole
> > >        1000   73.5%       1 relocatable
> > >       2763 pages for cells
> > >       8239 total pages
> > >     116036 pages available
> > >       6797 pages in heap but not gc'd + pages needed for
> > >            gc marking
> > >     131072 maximum pages
> > > Value = NIL
> > > 
> > 
> > You have plenty of room here.  Is this before or after running
> > the job which required the allocate-contiguous-pages?
> 
> It is after running the job. If I omit the call to
> allocate-contiguous-pages, then I get the following error
> message:
> 
>     >> System error:
>     Contiguous blocks exhausted.
>   Currently, 1354 pages are allocated.
>   Use ALLOCATE-CONTIGUOUS-PAGES to expand the space.
> 
> and Axiom aborts.

\start
Date: 01 Nov 2005 16:08:06 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: BAD tim

Greetings!

Bill Page writes:

> Tim,
> 
> > POINT 1: Axiom needs to be future-proofed.
> > 
> >    Axiom needs to be torn down, re-architected, re-thought
> >    and rewritten cleanly so it can be modularized, maintained,
> >    and extended. Which implies a major rewrite, likely done
> >    by me.
> >
> 
> I am not convinced that this is necessary or even possible,
> although I do not doubt your knowledge or your ability to do
> this - given enough time. According to the history of Axiom
> that you have described in various previous emails, Axiom has
> already undergone several cycles of re-writing. I don't see
> any evidence that such re-writing has resulted in making
> Axiom any more "future-proof".
> 

"Future-proofing", IMHO, is a continous process by any living
project.  It requires an active developer base intimately familiar
with the system details which can only be acquired gradually through
time.  Developing this base is the key issue IMHO.

> > POINT 2: The rewriting will change existing code. 
> > 
> >    If we look at the "start-up sequence" we see:
> > 
> >               restart (lisp)
> >    init-memory-config (lisp)
> >              initroot (lisp)
> >                reroot (lisp)
> >                  spad (boot)
> >               runspad (boot)
> >            ncTopLevel (boot)
> >             ncIntLoop (lisp)
> >               intloop (boot)
> >   SpadInterpretStream (boot)
> >    intloopReadConsole (boot)
> > 
> >   and, if you follow the side-paths you'll see the constant
> >   switching between boot and lisp at every level in nearly
> >   every function.
> > 
> >   This inhibits "collapsing and rewriting" code which will 
> >   have to happen during the rewrite. Functions will either
> >   have to be collapsed into lisp or boot.
> >
> 
> As a long term strategy, I agree, however as I have stated
> I think boot is the better choice.
>  
> >   Historically this interleaving occurs because new function
> >   was added/deleted/replaced. The "nc" prefix implies "New
> >   Code", a newly rewritten parser that partially replaced the
> >   previously newly rewritten parser. The "shoe" code, which is
> >   the new, improved "boot" language exists in there. The "meta"
> >   code used to exist but is gone. Addition of Fortran support
> >   (for NAG), Foreign Language calls (for graphics and the
> >   browser), Lisp vendor specific code, etc. required lisp.
> >
> 
> Why was lisp required? Surely it is possible to do these
> things in BOOT. In fact, aren't most of the NAG extensions
> written in BOOT? E.g. ls src/interp/nag*

Existing boot code can obviously be automatically converted into lisp,
but the converse is not true to my knowledge.


>  
> > 
> > POINT 3: Boot is a dead language. 
> > 
> >    There are approximately 10 people still living who have coded
> >    in boot and every one of them is doing something else with
> >    their life. You have to be careful in boot. It is case sensitive 
> >    so APPEND is not the same as append.
> 
> Wow, that comment certainly dates you! :) Almost all programming
> languages in the last 20 (30?) years have been case sensitive.
> Usually that is considered an advantage.
> 
> >    It is often not clear what a construct will translate to and
> >    you end up reading the lisp to learn. A single, misplaced
> >    space will change the meaning of the code.
> 
> That is true of most programming languages. Understanding a
> "construct" by seeing how it "translates" is usually just a
> matter of lack of fluency in the language. This can be a result
> of inadequate documentation and/or experience. In a language
> that syntactically depends on indentation, of course misplaced
> spaces can change the meaning of the code. But this is not
> essentially different than misplaced commas or braces in other
> languages.
> 

I feel that syntax is largely a matter of taste from the language
user's perspective.  There is an immensse difference from the compiler
writer's perspective (more below).  In lisp, the user can easily blend
into the compiler writer by writing macros and compiler macros in
*very* few lines of code.  Personally, I find whitespace with syntax
quite foreign, but I can get used to just about anything if it is
*flexible enough to be widely used, thereby granting extensive
experience through doing*.  I think lisp wins over boot here.  One
might make the argument that the whole thing should be written in
vanilla C for maximal mindshare, power, and available code to learn
from, but most would find this extreme I suspect.  Going in the other
direction is bound to limit our potential contributor base even more.
The lisp user base is decent, though not spectacular, though once
was.  What I mean by contributor here is someone who can work with the
internals of axiom as well as add new mathematical algorithms in the
upper level language.

> > 
> > POINT 4: Boot SERIOUSLY complicates the Axiom system. For
> > instance:
> > 
> >   1) Bootstrapping boot
> > 
> >    The boot compiler is written in boot and needs to be compiled
> >    using itself. If you have a running Axiom system this is not
> >    a problem. However if you start from a clean lisp system it
> >    is a big problem. I cheesed up a way to do this but it is
> >    fragile and ugly. But given that we build from scratch there
> >    is no other way.
> 
> But that is exactly how the C programming language works. The
> Gnu C compiler is written in C and bootstrapped in a similar
> way.
> 
> Also, the current Axiom build starts by first building GCL from
> the C sources. This is also a kind of bootstrap process. I don't
> see that the BOOT level adds much to this already existing
> complexity.
> 

Yes, but do we want to be in the compiler business really?  Or rather
in the math business?  Axiom can be built without building gcl at
present, so boot bootstrapping is the most complex absolutely required
part.  I agree with your other statement though -- what we have works,
so its complexity is not paramount.


> > 
> >   2) Makefiles come in multiple stages
> > 
> >    Boot forces Axiom to be built in stages. Thus Axiom cannot 
> >    use modern tools like ASDF. A pure common lisp Axiom interpreter
> >    can be built and loaded directly into a lisp image, interpreted
> >    or compiled.
> 
> I thought there was already a version of interpsys called debugsys
> which provides an interpreted environment that is more friendly to
> debugging in lisp?
> 
> Not being a lisp programmer, it is entirely unclear to me what
> advantages ASDF might have over more general tools like 'make'
> especially considering that the Axiom source files are actually
> literate programming documents (pamphlets), not lisp source code.
> 

I agree with Bill here, though I don't yet grok asdf.

> > 
> >    Lisp, BOOTSYS, DEPSYS, INTERPSYS, AXIOMSYS. These can all be
> >    collapsed if Boot disappears.
> > 
> 
> Although I still recall that this looked very complicated to me
> when I first started working with Axiom, now each of these stages
> in the current Axiom build process makes sense to me. Since Axiom
> is a large and complex system, building it a "layer" at a time
> seems quite logical. If these were all collapsed into one, then
> I worry that this would all start to look impossibly complicated
> to me again.
> 
> >   3) lsp, lisp, clisp, ${LISP}
> > 
> >    All of these exist because boot exists. For example, .clisp
> >    is a translated boot file whereas a lisp file is hand coded.
> >    ${LISP} exists to smooth over this bump. I won't go into the
> >    historical reasons why these came about but they exist as a 
> >    side-effect of boot.
> > 
> 
> Just another type of intermediate file, and Axiom already has
> many of these.
> 
> >   4) The interpreter has a boot compiler built in
> > 
> >    There are complications to the interpreter to handle boot-
> >    related development from the command line which no-one is
> >    ever likely to do again. This code could disappear and, having
> >    gone away, simplify the interpreter
> 
> This still sounds a little vague, but in general if it was
> documented then perhaps someone who was working with BOOT would
> find this functionality useful and use it again.
> 
> > 
> > POINT 5: The boot language is undocumented 
> > 
> >    It is likely to remain so as one of the authors is dead 
> >    and the other one might be. There are no primary sources of
> >    documentation.
> 
> That does present a problem. But since there is still a lot
> of boot code in Axiom, figuring out how boot works and
> documenting it does not seem to me to be any more difficult
> than figuring out how the boot code works and re-writing it
> in lisp.
> 
> > 
> > POINT 6: Boot does not give you the full power of common lisp.
> > 
> >    Boot cannot handle backquote, defstruct, and other primitives
> >    not to mention CLOS, CLIM, etc. So as lisp evolves boot will
> >    "further fork" away from the living edge of lisp ideas and 
> >    limit the axiom programmer. 
> >
> 
> This is true, but I think that perhaps by accident or by design 
> it can be largely cast as an advantage. After all, the purpose
> of boot is to implement SPAD and the Axiom interpreter in a
> language that is higher level than common lisp - not to be a
> general purpose programming language.
>  

There may be a point here.  How difficult would it be to write spad
directly in lisp?  Are the restrictions of boot useful in implementing
spad, just as the applicative (i.e. functional) restrictions of acl2
assist that project?

> >    Witness the data structures used in boot, mostly lists.
> >    Frames are lists of lists, history is a circular list of
> >    lists, etc. Where are the data structures? Who will redesign,
> >    rewrite, and document boot extensions to fully cover common
> >    lisp?
> 
> This point was also recently raised by Juergen Weiss. I believe
> that his view is that it is possible to extend boot to include
> these data structures in boot syntax but that it might be
> preferable simply to use boot's built-in mechanism to "escape"
> to lisp where necessary to define these structures and then to
> call the data structure access methods in the usual way in boot.
> 
> > 
> > POINT 7: Boot loses program-data symmetry.
> > 
> >    This is a matter of religion but having been at this game for
> >    35 years I've seen a hundred languages built on lisp that try
> >    to "eliminate the parens" and all will eventually die (including
> >    Python).
> 
> I don't see that this has to do with parens or not. Using
> parenthesis to denote nested lists is just one more syntax.
> 

I think Tim means the grammar of the parens, not their lexigraphical
syntax (more below).

> > 
> >    The paren syntax is fundamental. Look at how Axiom really 
> >    works under the covers. It doesn't build boot functions, it
> >    builds lisp functions. Why? Because you can cons up a lisp
> >    function, compile it, and run it directly. Axiom code and
> >    data intermingle in the algebra lisp files. The databases
> >    have code and data in them. Data <==> Programs. Fundamental.
> 
> I don't agree that lisp has anything special to offer here
> except perhaps by being the first language to formalism this
> relationship. Any higher level language in which functions are
> first order objects has this property, although usually not in
> the way it is implemented in lisp. This is especially true in
> functional languages like Haskell and Ocaml and probably also
> in Aldor. "cons'ing up a lisp function" is just a less structured
> way of doing the same thing.
> 

This takes quite a while to appreciate for someone new to lisp, IMHO.
Sure, I can write a C program to generate and run other programs -- all
I have to do is write a printer to parse the logic of the program into
a text file, write (or use an external) parser and compiler to
generate the code, then write (or use an external) loader and
evaluator to give me my executable program withing my currently
running program.  I.e. I would at the simplest level do

f=fopen("foo.c","w");
print_c_program_from_struct_representation(f,funtion_representation_in_memory);
system("gcc  foo.c -o foo");
s=generate_command_line(args);
p=popen(s,"r");
read_result(p);
pclose(p);

Consider this vs.

fun:= a+b;
result=fun(x,y);
fun:= make_function("a","b");
result=fun(x,y);

where the functions are compiled, refer to live objects in the running
program, etc.  In lisp this is

(let* ((fun (compile nil '(lambda (a b) (+ a b))))
       (res (fun x y))
       (fun (compile nil (generate_function_lambda 'a 'b)))
       (res (fun x y))) ...)
 
> > POINT 8: Tools don't support boot
> > 
> >    Emacs balances lisp parens. It lets me do lisp function 
> >    lookups. It understands the lisp syntax including escape
> >    chars. SLIME lives in emacs and provides support. Code
> >    walkers walk lisp code. Pretty printers understand lisp.
> >    Debuggers understand lisp (I want to fix it in the language
> >    I broke it in). ASDF can manipulate lisp. Programmers 
> >    speak lisp. Blank spaces don't break lisp.
> > 
> >    Boot is unsupported anywhere by anything.
> 
> Kai Kaminiski has written a simple emacs mode for boot.
> See http://wiki.axiom-developer.org/AxiomInEmacs Boot is
> syntactically similar to Python so if there was a need for
> enhanced emacs support, then I expect a lot of this
> functionality could simply be "borrowed" from the Python
> extensions of emacs (and other syntax aware editors).
> 
> I think it remains to be seen how some of these other lisp
> tools could be used with Axiom.
> 

While I have done precious little for axiom (my apologies), there was
one bug I found and fixed early on.  I used lisp trace, debug, and
even gdb to find it.

> I don't know many people who "speak lisp" except perhaps
> during severe rapid eye movement while asleep. ;)
> 

Again, many more than boot I believe.  Still too few IMHO, but
relatively speaking lisp is much more widely used and known.

> > 
> > 
> > POINT 9: Where are the programmers?
> > 
> >    Who will write in boot? I'm the only person likely to be
> >    hacking the interpreter for the near future, mostly because
> >    it is so big, ugly, unstructured, and undocumented. Even if
> >    people code in boot to maintain the interpreter how often
> >    will they do that? How will they maintain their skill at
> >    writing boot? I've written many, many thousands of lines of
> >    lisp and use it continuously. Who are the programmers who
> >    will do that in boot?
> 
> I agree! That is the #1 question. But besides Tim Daly, where
> are the other lisp programmers? How will they maintain their
> skills at using lisp in Axiom?
> 

Here!

> Axiom is now open source and is at least potentially exposed
> to a much larger range of people than ever before. I believe
> that in the future there is a good chance that the people who
> may help to maintain and further develop Axiom will be those
> people who started by writing Axiom library code in SPAD.
> >From SPAD it is a natural step down the ladder to programming
> in boot. I expect that many of these people would never have
> had any previous exposure to lisp. So forcing them to program
> in lisp just to maintain Axiom would probably feel more like
> "falling off the ladder" than just stepping down.
> 

Well, witness maxima.  Lots more developer contributions on a project,
which while magnificent in its own right, has far less potential than
axiom IMHO.  And all of these people are writing in lisp.

> Of course this is currently mostly speculation (with the
> exception perhaps of myself and Martin Rubey).
> 
> > 
> > POINT 10: Boot was an experiment in surface syntax
> > 
> >    Historically Axiom was a platform for experimenting with 
> >    many research topics. One of these topics was a favourite
> >    of Dick Jenks and Bill Burge, that of language design.
> >    Scratchpad, now called Axiom, was changed many times to
> >    introduce new ideas. This research is no longer the point
> >    of Axiom and is better done elsewhere. We neither have the 
> >    expertise nor the research goal of surface language design.
> >    Let Python do that. Or Spad/Aldor fans.
> 
> I think the Python designers also (for the most part) consider
> their work done.
> 

???  I guess its a question of time horizon.  Lisp was standardized in
1994.  Changes in perl or python et. al. will always be possible at
the discretion of their inventors, to my limited understanding.  I've
upgraded Debian Linux from the days of 'rex', and believe me you don't
want to know what a perl incompatible upgrade can do to critical
system programs written therein.  C and lisp are no longer moving
targets -- some might consider this a disadvantage, but I find it
indispensable. 

> I thought Spad/Aldor was an essential part of Axiom and
> necessarily closely related to the Axiom interpreter, so I
> am not sure what you mean by your last comment.
> 
> > 
> > POINT 11: Do language design where it counts.
> > 
> >    If we are going to devote research effort toward language
> >    design lets do it at the Spad/Aldor level where it counts.
> >    This is where the real language expertise should be applied.
> 
> I agree. I don't see any serious need to re-design the boot
> language - simply to document it as it works now.
> 
> >    For instance, why do I have to write programs to express
> >    functions?
> 
> In Axiom you can already expression functions in other ways
> than imperative code. The Axiom interpreter, SPAD and Aldor
> have a (more or less) complete functional subset.
> 
> >    Why can't I write a domain using equations? Why doesn't
> >    the Spad language support that?
> 
> Could you elaborate on what you mean by "write a domain using
> equations"? Are you talking about an alternative to the way
> that Axiom implements "axioms" now simply by assertion?
> 
> > 
> > POINT 12: Future directions assume lisp
> > 
> >    Notice that one of the near future goals is to connect Axiom
> >    and ACL2. ACL2 understands lisp-ish kind of languages, not
> >    boot.
> 
> Besides the fact that ACL2 is implemented in lisp, I don't see the
> connection between ACL2 and "lisp-ish" languages when it comes
> to proving program correctness.
> 
> There are other tools similar to ACL2 such as Coq which is not
> written in lisp at all. Coq has already been used with Axiom
> in some research.
> 

Bill has a point IMHO that modern OSes provide a remarkable amount of
generic glue between differing programs via shell pipelines, php/cgi
scripting, etc.  But it will never be the same as integrating programs
in core memory for anyone wanting to push the limits of what their
system can do.  Lisp makes this easy, and having acl2 in the same
image opens up numerous possibilities.  Should we wish to integrate
the theorem prover into the spad compiler, for example, do we really
want to output Coq input through a shell pipe and parse the results?

> > 
> > 
> > and now, on to the recent changes
> > 
> > POINT 13: Don't break code until you understand it.
> > 
> >    I'm working hard to understand the code so the existing code
> >    is a straightforward translation (well, mostly, with some
> >    rewrites that I know are logically equivalent).
> > 
> >    Once I've completely figured out the various twists and turns,
> >    uses and references, and other points I'll be recoding the
> >    whole process. There is no reason (other than historical) why
> >    there are a dozen entry points into the interpreter that set
> >    weird, undocumented, stateful flags. All that cruft must go
> >    away.
> 
> I agree with all that, while de-emphasizing the need to remove
> all of the cruft right now. But I fail to see why recoding
> anything from boot into lisp is involved.
> 
> > 
> >    So the code is ugly. At the moment. But it will get better,
> >    cleaner, clearer, more robust, and easier to change. History
> >    and Frames, for example will use structures that don't depend
> >    on 
> >       (caar (cdddddr (cdddddr x)))
> > 
> >    It takes time. It takes work, probably 2-3 years worth of
> >    work.
> 
> I think you worry too much about how "ugly" to current code is.
> It works. That is what matters most to people who want to begin
> using Axiom now. I doubt that there is much you can do to the
> Axiom internal code in the way of re-writing it into lisp that
> would make it any more appealing to this putative new generation
> of Axiom users. Still I am hopeful that among the thousands of
> new people who have recently been exposed to Axiom, there will
> be some who will want to take up the challenge of dealing with
> what's on the inside. If/when they arrive, I think it is more
> important to have good documentation than it is to have pretty
> code.

I agree with this.  One could easily take the position that we have
more important fish to fry, and what we have works.  But if we are
considering a code simplification, I feel using lisp is clearly the
best choice from where we are now.

> 
> >   
> > and now, on to the personal...
> > 
> > POINT 14: I'm a lisp programmer 
> >    
> >    (clearly)
> > 
> 
> I don't seen anything inherently evil in that. :)
> 

\start
Date: 01 Nov 2005 16:23:11 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: ANSI Lisp?

Greetings!

Tim Daly writes:

> > > it's not far away. there are minor package issues but very little else.
> > > once gcl becomes ansi i'll port it.
> > > 
> > > i could probably make it run in an ansi common lisp within a few days.
> > 
> > If you have the time, I think this would be worthwile. 
> 
> yeah, it's coming eventually. i'm waiting for an ansi version of GCL
> which is "in process". 
> 

Just a note here -- 2.6.x has an ansi build which while not perfect is
likely good enough for this port whenver you might wish to undertake
it.  maxima uses it successfully.  That said, 2.7.0 will be much
better.  I am hoping we can finalize it in the next few months.

\start
Date: Tue, 1 Nov 2005 13:51:45 -0800 (PST)
From: Cliff Yapp
To: Camm Maguire
Subject: Re: BAD tim

> "Future-proofing", IMHO, is a continous process by any living
> project.  It requires an active developer base intimately familiar
> with the system details which can only be acquired gradually through
> time.  Developing this base is the key issue IMHO.

True.  I think, though, that the literate pamphlet structure has a
better chance of robust future-proofing than any system I have heard of
before.  It takes the focus from the code to the design and ideas, and
that's about as future proof as you can get.

[snip] 

> One might make the argument that the whole thing should be written 
> in vanilla C for maximal mindshare, power, and available code to 
> learn from, but most would find this extreme I suspect.  

Heh - what better time to mention 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."

[snip]
> > Not being a lisp programmer, it is entirely unclear to me what
> > advantages ASDF might have over more general tools like 'make'
> > especially considering that the Axiom source files are actually
> > literate programming documents (pamphlets), not lisp source code.
> 
> I agree with Bill here, though I don't yet grok asdf.

Well, as I understand it the lisp source code (or any other code for
that matter) is untangled from the pamphlet files into source code
files before compiling takes place, so pamphlet files don't really pose
a problem.  The advantage of using asdf (IMHO anyway) is it reduces the
dependency of Axiom on external tools and the guarantee that they will
behave the same way.  (Make itself isn't so bad I suppose, but I
shudder thinking of the headaches I have had trying to compile programs
written for different versions of autoconf/automake.)  asdf, being in
lisp, will guarantee that the build logic will function correctly on
any platform the lisp implementation does.  It is unlikely that all
build logic can be contained in asdf, particularly system interactions,
but the build logic for lisp files can be handled by asdf and is a
technique very familiar to most current lisp programmers.
 
[snip]
> > Axiom is now open source and is at least potentially exposed
> > to a much larger range of people than ever before. I believe
> > that in the future there is a good chance that the people who
> > may help to maintain and further develop Axiom will be those
> > people who started by writing Axiom library code in SPAD.
> > From SPAD it is a natural step down the ladder to programming
> > in boot. I expect that many of these people would never have
> > had any previous exposure to lisp. So forcing them to program
> > in lisp just to maintain Axiom would probably feel more like
> > "falling off the ladder" than just stepping down. 
>
> Well, witness maxima.  Lots more developer contributions on a
> project, which while magnificent in its own right, has far less 
> potential than axiom IMHO.  And all of these people are writing in
> lisp.

Heh - hopefully with any luck we will eventually be able to match all
the functionality present in Maxima, although things like the tensor
packages will take some doing.

[snip]

> Bill has a point IMHO that modern OSes provide a remarkable amount 
> of generic glue between differing programs via shell pipelines, 
> php/cgi scripting, etc.  

A problem with that though is many of those methods are not really
usable across different platforms :-(.

> But it will never be the same as integrating programs in core 
> memory for anyone wanting to push the limits of what their
> system can do.  Lisp makes this easy, and having acl2 in the same
> image opens up numerous possibilities.  Should we wish to integrate
> the theorem prover into the spad compiler, for example, do we really
> want to output Coq input through a shell pipe and parse the results?

I would prefer to have that as an option - e.g. an alternative method
for verification at user option - but I agree as a default standard
method it is undesirable since it relies on platform specific methods.

[snip]

> > Still I am hopeful that among the thousands of
> > new people who have recently been exposed to Axiom, there will
> > be some who will want to take up the challenge of dealing with
> > what's on the inside. If/when they arrive, I think it is more
> > important to have good documentation than it is to have pretty
> > code.
> 
> I agree with this.  One could easily take the position that we have
> more important fish to fry, and what we have works.  But if we are
> considering a code simplification, I feel using lisp is clearly the
> best choice from where we are now.

We could take that position, but I think documentation time is also a
good time for this type of simplification, at least when the guy
writing the documentation is also project chief and architect :-). 
Writing the kind of documentation Axiom needs is almost the same thing
as (re)designing it, in some ways - you really have to understand what
you're documenting to be able to succeed.  (Would that more of the
programming world was like this...)  Converting to lisp is relatively
trivial as a first step thanks to BOOT already compiling to lisp, and
since he's documenting as he goes the important work is getting done. 
We may want to clean up and polish the lisp code later, but that can be
done at leasure.  I don't think the current level of lisp conversion is
adding much to the effort, and also if he is able to simplify things in
a functional fashion that reduces the amount of documentation he needs
to write.  Of course, all this is ultimately up to him - my conclusion
is we don't need to worry on that count.  Now if only we could stick
him in a duplicator, or almost as good convince a university to hire
him to work on Axiom...

\start
Date: Tue, 1 Nov 2005 17:14:57 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: --patch46

Camm,

On November 1, 2005 2:32 PM you wrote:
> ...
> Can you give me a step by step of what to do to reproduce
> your issue?
> 

Well, wouldn't you know it ... I just spent the last hour or
so trying to reproduce the error that I have recorded on the
web page on MathAction from circa September 15,

>     >> System error:
>     Contiguous blocks exhausted.
>   Currently, 1354 pages are allocated.
>   Use ALLOCATE-CONTIGUOUS-PAGES to expand the space.

I am frustrated by the fact that I no longer seem to be able to
cause this to happen. It was always intermittant but previously
I could make in happen after two or three tries of re-executing
this page:

http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs

I am not aware of any changes in Axiom or on the axiom-
developer.org server since September 15, that could conceivably
affect this problem. If I can find a way to make this happen
again reliably, I will let you know ASAP.

This was the problem which lead me to want to increase the
maxpage to 256*1024. And during the build of Axiom with this
gcl option is when I got the error that I reported to you:

  Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.

On the axiom-developer.org server you can get this error
message just by building gcl-2.6.7 with the option

  --enable-maxpages=256*1024

\start
Date: Tue, 1 Nov 2005 20:35:51 -0500
From: Bill Page
To: Bertfried Fauser
Subject: RE: Boot vs. Lisp - various replies

On November 1, 2005 6:47 AM Bertfried Fauser wrote to
Tim Daly:

> 
> Perhaps I may add, that as a _user_ of AXIOM, I am totally 
> ignorant to its internal struggles (bild process from
> scratch, historical accidents, etc), but that I need to
> focus my resources.
>

I think we need to distinquish several different kinds of
"users":

Axiom user I (beginner):

  - uses the Axiom interpreter to evaluate expressions
  - writes single-line and multi-line functions
  - Ref. Axiom book chapters 1 - 7.

Axiom user II (advanced):

  - writes .input files containing imperative statements
    such as if, for, and while.
  - Ref. Axiom book chapters 8, 9.

Axiom user III (library developer):

  - writes Axiom packages, domains and categories using
    SPAD and/or Aldor.
  - needs to understand the logical/mathematical structure
    of the Axiom library and how to extend and build apon it.
  - Ref. Axiom book, chapter 11, 12, 13.

Axiom system developer:

  - maintains and enhances the underlying tools such as
    SPAD and the Axiom interpreter.
  - writes in boot and lisp.
  - needs to understand the internal design of Axiom.
  - Ref. Tim's new book volumes 4 and 5

Axiom support programmer:

  - writes in lisp (e.g. gcl), C/C++ and other languages
  - maintains the underlying tools such as lisp (gcl)
  - debugs problems directly related to lisp and/or the
    operating system
  - advises on porting Axiom to different systems, etc.

> I am not a programmer, but need to be able to develop own
> functionality. So I would vote for a system having
> 1 internal language (lisp, C++, ...) and probably one 
> toplevel language (Aldor, spad, ...). Any further mixing
> prevents a _user_ from even making first steps.

>From the categories above I think that most likely you would
be a user of the third kind (Axiom user III). In this case
you are mainly concerned with what you call the toplevel
language (SPAD), it's relationship to the interpreter and to
other existing domains in the Axiom library. Any internal
language such as boot, lisp or C would be invisible to you.

Making the first steps in Axiom usually involves just
evaluating complex expressions using existing operations,
i.e. a user of the first kind (Axiom user I). In this case
no programming is involved, but of course some mathematical
knowledge of Axiom operations is necessary.

Generally I expect people will progress from I to II and
maybe to III. Some highly motivated user of the third kind
with additional programming experience might be also work
as Axiom system developers.

Some Axiom support programmers might become Axiom system
developers.

> 
> Hence I would at least like to have a winner of the
> lanuage war, alas such stories usually will have no ...
> and they lifed happyly ever after.
> 

I think there is a good chance that even if there is no
winner, we will live happily ever after - ever after we
get some serious users of Axiom, that is!

\start
Date: Tue, 1 Nov 2005 23:23:27 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Boot vs. Lisp - various

On November 1, 2005 10:36 AM C Y wrote:
> ...
> I'd cast my vote for Lisp, somewhat because of my own
> bias but mostly because Tim is accomplishing a lot
> of stuff and I'm eager to see that continue.
>

People seldom vote during a war :) but I agree that Tim is
accomplishing a lot of stuff and I am also eager to see that
continue. I believe Tim is very committed to Axiom and I doubt
whether my haranguing him about his intentions to replace boot
with lisp will have much affect on that.
 
> ... That's the real beauty of the whole literate document
> idea - the IDEAS will work regardless of the language,

I think you put entirely too much faith in the concept of
literate programming. The description of an idea is very
different than the implementation of an idea. Very seldom,
if ever, is a description written in a natural (human)
language a sufficient basis of an implementation. There
are always loose ends and forgotten details. And some
people are much better writers than others (programmers
are in general notoriously bad). I don't mean by this that
literate programming is a not a good thing - just that it
has its limitations.

> ...
> All mathematical work done in SPAD/Aldor doesn't have to
> care one way or the other, so that work survives regardless,
> and I'm really hopeful that we will reach a point where
> most significant work in Axiom takes place at that level,
> because that will mean Axiom is functioning as a mathematical
> and scientific research platform.

In my opinion we are already at that point. Or rather, we are
anxiously waiting for more research-oriented users to show up.
The work that Tim is doing now is mostly aimed at the longer
term that will not immediately affect Axiom's suitability as
a research platform. The issue of boot vs. lisp is a similar
issue. It doesn't have any immediate impact on the usability of
Axiom, but it (may) have a large impact on it's maintainability.

>  
> > On November 1, 2005 1:16 AM Bill Page wrote:
> >
> > I agree with this. But from my point of view the BOOT
> > language embedded in Axiom is much easier to "jump into
> > quickly" compared to lisp, if your starting point is
> > SPAD or if you had previously programmed in Python
> > (unless you also happen to be a lisp programmer).
> 
> Two points I wish to mention - 1) The CAS community is a
> small subset of the total programming community, but within
> that community Lisp is a much bigger deal than otherwise -
> I think it is this community we are likely to attract,
> rather than the general community

I don't agree that CAS users are a subset of all programmers.
I think a large number of people use systems like Mathematica
and Maple without programming at all. Most CAS *developers*
i.e. CAS users who write new applications within some given
environment,  of course must program in some language or other
but then usually only at the highest level language available.
I think only a small fraction of them might also know lisp.
So if we target primarily the lisp programmers in this group,
we are limiting ourselves unnecessarily.

> 2) SPAD will only be a starting point for people who have
> programmed a lot of SPAD code (not many currently) and also
> want to work on the internals of Axiom the program.  I'm
> hoping this will actually work a bit in reverse -programmers
> who are not up on the heavy duty mathematics side so much
> (for high level math that's most of them, at a guess) will 
> start out by working on the Lisp side (with its documentation,
> tools, etc. to help them getting started with Lisp) and then
> graduate to working on the mathematical side, where learning
> SPAD/Aldor will be part of learning to express high level
> mathematics in a computer.

I have a very hard time understanding what someone who does not
know SPAD might be able to contribute to internal programming
in Axiom. I don't think having a lot of experience in SPAD is
necessary - only the basic syntax and usage plus a knowledge
of how SPAD fits into the overall Axiom design is really
important. In general it is not necessary to know a lot of
mathematics to program in SPAD. However the Axiom library that
is written in SPAD does represent a considerable amount of
mathematical knowledge and to use it and extend it effectively
does require some of this knowledge.

In general I don't think trying to learn mathematical programming
from the "bottom-up" so to speak is a good idea. I am certain
that this is not what the original designers of Axiom had in mind.
That is why SPAD is such a high level language when it comes to
expressing mathematics.

> Actual honest to goodness mathematical researches and scientists
> are probably the LAST people who want to work on the guts of
> Axiom except out of need for a working tool - they want to USE
> it to do other stuff.

Yes I agree. But in spite of that I do think that these people
are still the mostly likely people who *will* do this kind of
work. The other stuff that they really want to do is what
motivates them to dig in and do whatever seems necessary to
get the computer system to do what they need. Inevitable some
of them adopt new "deeper" goals and spend most of their time
implementing CAS internals and helping other people do what
they really want to do. It seems to me that this is how it
has gone in a very large number of cases since the beginning
of this field.

In fact I think the design of some computer algebra systems
has sometimes suffered because those most motivated to do the
work did not have particularly strong backgrounds in computer
science, being perhaps excellent mathematicians but often
self-taught in compiler design and user interface design. In
this regard I think Axiom was exceptionally fortunate to have
among it's developers people with both of these skills.

> They'll be working at the Aldor/SPAD level, and any need to
> go lower will probably get reported as a bug to be fixed by
> the team.  After all, how many scientists would request to
> hack on the Mathematica source code?

I think you really should take a poll. :) For example, from my
experience I know a lot of researchers who would be very glad
to get a chance to "hack" in the internal code of Maple. Very
few of them would say they are entirely happy simply letting
the developers solve the bugs. That is one of the reasons why
there is a lot of pressure among CAS users for open source.

> They want it to solve problems without their needing to do
> that.

As I said, I agree that that is what they want to do but not
what all of them end up doing.

> Since we want to become a rising force in the mathematical
> community our goal has to be to provide a program where people
> can focus on the math rather than the program.  (Of course,
> this is all speculation so it may or may not be worth anything.)

If we could accomplish that goal, than I think it would be
worth a lot. I think that Axiom comes closer to that goal
than most of the other systems.

> ... 
> > We must assume that the people who choose to work on Axiom
> > already have quite a lot of other relevant experience
> > including programming in several languages.
> 
> I disagree - I think we want to appeal to mathematicians
> and scientists, who quite often are NOT (or don't want to be)
> computer programmers.  

I am sorry. What I meant was for this assumption to apply
to people who want to work on the *internals* of Axiom, i.e.
Axiom developers, not Axiom users. I agree with your statement.

> 
> > I think this is what limits the potential developers much
> > more than just learning another new language.
> 
> Maybe I'm alone in making the distinction between Axiom the
> programmer's challenge and Axiom the mathematical environment,
> but I'm hoping that level of abstraction is possible because
> it is likely to appeal to non-programmers.

I think you are right in making this distinction but things
are not quite as separable as you seem to imply.

> > 
> > Maintaining both a library compiler (SPAD) and an interpreter
> > (an integral part of the user interface) is inherent in the
> > design of Axiom. BOOT is closely related to SPAD (or perhaps
> > better said, SPAD is closely related to BOOT). So really
> > there is no additional compiler to maintain.
> 
> You mean the same compiler compiles both BOOT and SPAD
> with no additional complexity added due to compiling BOOT?

I mean that the problem of compiling BOOT is essentially
a subset of the problem of compiling SPAD. In a sense BOOT
is just SPAD but with a very limited set of types. So yes,
conceptually speaking there is really not additional complexity
added due to compiling BOOT.

But from what I have seen and understood so far, Tim is right
that the current Axiom code contains a lot of "cruft" and is
in some cases quite far from optimal even though it works.
So in the case of BOOT and SPAD I expect that a lot of the
essentially similar code is actually duplicated or implemented
in slightly different ways.

If you look at some of the older SPAD code you can even see
some of the original boot syntax appearing right at the surface,
e.g. the "append"/[...] construct.

> > 
> > I don't agree. I think maintaining a compiler as part of Axiom
> > is essential.
> 
> But mathematicians aren't going to want to work on a compiler
> (it's hard to get funding for things like that.)  They want to
> do math.

Ah, there's the rub.

>...
> I think wanting to make changes to Axiom itself will be a
> different job from wanting to create new mathematical abilities.
> It is quite possible there are others (like me) who are not
> likely to make any spectacular mathematical contributions to
> Axiom but are interested in providing features and functionality
> for those who can.

If you can complete your work on a units system for Axiom then
I think that would potentially be quite spectacular.

> For folks like me, the guts of Axiom being similar to the high
> level language is pretty much totally irrelevant.  In THAT
> situation, there is a clear advantage to not using a custom
> language, because hypothetically if I were a good Lisp programmer
> (Granted I'm not at the moment) I could hook in FFI bindings to
> the GNU Scientific Libraries.  Starting from BOOT I haven't got
> the faintest idea of how to proceed.  Lots of things like that
> will crop up over time, and Lisp already is working on the
> problem of being able to interface with a large number of
> foreign libraries via FFI.

Exactly that issue came up in Kai Kaminski's work on Axiom UI.
In that case Kai choose initially to use an entirely separate
lisp process (in fact written in clisp rather than gcl because
of ansi compatibility) and to communicate with Axiom via a
pipe or socket. But gradually and during the latter stages of
his work he discovered that he had to make changes in some
boot code in Axiom in order to support Scalable Vector Graphics
in the AxiomUI browser. Now as gcl approaches full ansi
compliance and after Axiom is ported to the ansi standard
(see another recent thread on this subject), I wonder if Kai
might have used a different approach and written more in
boot?

> 
> In the end, Tim is being very productive, and that's a really
> rare thing.

I presume that you mean something like "productivity in open
source is a rare thing"? Or did you really mean to imply that
Tim is not usually so productive? :) I don't think so.

> I'm cheering him on regardless - literate documents will
> make sure Axiom survives any language.  If someone wants
> someday to do a new CAS, we want to set things up so that
> to do anything other than start associating code with the
> documentation part of the Axiom literate pamphlets wouldn't
> make any sense at all :-).
> 

I don't think literate programming is really such a "magic
bullet", but I am all for the writing of documentation. Three
cheers for Tim! And I hope that real soon now, some other
axiom developers will come along to help out with this
enormous task.

\start
Date: Wed, 2 Nov 2005 09:57:40 +0100
From: Juergen Weiss
To: list
Subject: re: Boot vs. Lisp

Hi,


I want to make a few comments to the discussion. Some were
in part already made in a recent mail by Bill Page.

1. Lisp versus BOOT versus SPAD

What's the difference between Lisp and BOOT? In a way, it's
similar to Lisp and Rlisp, the language in which Reduce is
written. And there are probably a quite a few other examples as=20
well. It's just a different syntax (less parentheses if you like)
and different control structures (loops, if-then-else, defining
functions etc.). The functions you can call are the=20
functions of the Lisp system, the functions you define get
added to the Lisp system. As datatypes you have the Lisp
datatypes (no syntax for structures yet). So in a way,
it's just a different syntax for Lisp.

2. BOOT versus SPAD

As above, it's similar to Rlisp and the Algebra mode of Reduce.
The syntax and the control structures of BOOT and SPAD and
the Axiom interpreter are the same. But BOOT just does not
have types (categories, domains, etc), just the Lisp types.=20

3. Parsing BOOT code

The parser for SPAD code is able to parse BOOT code as well --
which is not too surprising after point 2 above. You can
build Axiom with it -- after a few cosmetic changes in syntax
in a few more recent files written in BOOT. This parser is
equally capable of parsing the interpreter input (modulo rules
to be fair). The parser has certain deficiencies (for example
the poor error messages in the compiler showing lisp code).=20
This parser is written with the help of a parser generator
(meta). There is another parser for boot code in the src/boot
directory (always wondered, why it exists). Then there is parser
which is used for the Axiom interpreter (src/interp/pf2* files
and others). It is capable of parsing rules.

4. Destructuring setq and destructuring comparisons

One of the highlights in BOOT is the possibility
to use destructuring setqs and destructuring comparisons.
This is extremly handy. Some random examples:

  for [[.,arg], :.] in singles while null tuple repeat
    if arg is ['Tuple,.] then tuple := arg

  a is [=op,b,t1] =>

Without this feature the code will get almost unintelligible.
And this feature is used in almost every line of code.

5. My conclusions

a. I do not see BOOT as an hindrance to new contributors.
   Without a certain knowlegde of the interpreter and
   compiler language and Lisp contributions to the
   interpreter will not be possible. With the knowledge
   of the interpreter and compiler language you know
   the control structures of BOOT. There is nothing
   left to learn. With the usage of BOOT, one could=20
   even argue that Lisp knowledge would be less important.

b. An automatic or semiautomatic translation of BOOT to
   Lisp as done in Volume 5 of the Axiom book is not
   very helpful. Even if you fix most of the prog, progn,
   seq etc. by hand, the loss of the destructuring
   features makes the code an order of magnitude harder
   to understand. Without a complete rewrite of the
   Axiom interpreter from scratch (not a function by
   function or module by module replacement) with a=20
   more modern Lisp like look and feel (defstruct, more
   functional programming style etc), I think we can
   not get rid of BOOT without losing the maintainability
   of the code.

c. If we went for a total rewrite of the code, and at that
   time the licencing problems with A# were resolved, we
   should certainly consider reimplementing the interpreter
   in A#. Then we had only one language for the whole
   system.=20
   But I do not think, that a total rewrite is a viable=20
   option with the current developer base and the current=20
   developer model. At the current development speed it
   would take maybe 5 years or longer. And success would not
   be sure.

\start
Date: 02 Nov 2005 10:31:00 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: compile with Debian fails / works

Dear all,

so, here is some news:

* setting up tla meanwhile is trivial. I just followed my (own) recipe on
  mathaction, since I forgot everything meanwhile. It's a matter of copy and
  paste. Compiling patch-46 worked without a problem after applying Bill's
  suggestions. I repeat it here for the record: binutils-dev should probably go
  into the list of dependencies.

* setting up darcs is even easier: one line instead of three. However, I did
  not find out how to tell darcs not to overwrite my old patches. For
  development, it is necessary for me to keep the old patches, or, at least
  have them available.

  Furthermore, it would be crucial that the two archives were
  *identical*. (Currently, they are not, only some of the patches are in darcs)
  In fact, compiling from darcs doesn't finish (apart from the missing gcl2.7
  and the executable bit problem, which I do not understand):

generic 10 making /home/rubey/axiom--main--1/mnt/linux/input/pollevel.input from /home/rubey/axiom--main--1/int/input/pollevel.input
make[3]: *** No rule to make target `/home/rubey/axiom--main--1/mnt/linux/input/pmint.input', needed by `all'.  Stop.
make[3]: Leaving directory `/home/rubey/axiom--main--1/src/input'
make[2]: *** [inputdir] Error 2
make[2]: Leaving directory `/home/rubey/axiom--main--1/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/rubey/axiom--main--1'
make: *** [all] Error 2

* I suggest that we stay with tla, since this is easiest for me :-)
  Furthermore, it enables me to update axiom on my home machine, where I only
  have a slow modem. I suppose that this would also work with darcs, but
  detailed instructions would be necessary.

  Of course, providing a darcs server would be very good, however, it is
  crucial that the archives are *identical*. (Not necessarily on the hardware
  level, of course...)

Thanks to everybody, and especially to Bill for his Debian instructions!

\start
Date: 02 Nov 2005 10:59:12 +0100
From: Martin Rubey
To: Bertfried Fauser
Subject: Re: BAD tim

Dear Tim, Bertfried, *

Bertfried Fauser writes:

> Dear Tim,
> 
> 	thank you for your long mail and the invitation to a coofee which
> I took while reading...

I'd like to second that, although I did not have coffee available. (should go
on Axiom's wishlist, I suppose)

> Perhaps I may add, that as a _user_ of AXIOM, I am totally ignorant to its
> internal struggles (bild process from scratch, historical accidents, etc),
> but that I need to focus my resources. I am not a programmer, but need to be
> able to develop own functionality. So I would vote for a system having 1
> internal language (lisp, C++, ...) and probably one toplevel language (Aldor,
> spad, ...). Any further mixing prevents a _user_ from even making first
> steps.

Although I can really understand Bill's concerns, especially given the current
style of the lisp code, which really looks like translated Boot, not
Lisp. Well, Tim confirmed this in point 13. My hope is that the *final* Lisp
code will be crystal clear, even to non lispers.

Thus I think that the current version is a good compromise: use boot as the
documentation... I hope that with patch 56 this need will be gone.

\start
Date: 02 Nov 2005 11:58:56 +0100
From: Martin Rubey
To: Juergen Weiss
Subject: re: Boot vs. Lisp

Dear Juergen, Tim, *,

Oops, I didn't know about these points. Since it seems that J=FCrgen
and Tim have some knowledge about Boot, maybe the two of you could
drink some coffee together and decide upon a route that Axiom is to
take?

This implies, that I would like to take back my comment written some
minutes ago.

I'm happy with any possibility that makes it clear what each language
should be used for, and that minimzes the amount of code in the system
we want to have in future.

Some more questions:

Juergen Weiss writes:

> 3. Parsing BOOT code
>
> The parser for SPAD code is able to parse BOOT code as well -- which is not
> too surprising after point 2 above. You can build Axiom with it -- after a
> few cosmetic changes in syntax in a few more recent files written in
> BOOT. This parser is equally capable of parsing the interpreter input (modulo
> rules to be fair). The parser has certain deficiencies (for example the poor
> error messages in the compiler showing lisp code).  This parser is written
> with the help of a parser generator (meta). There is another parser for boot
> code in the src/boot directory (always wondered, why it exists). Then there
> is parser which is used for the Axiom interpreter (src/interp/pf2* files and
> others). It is capable of parsing rules.

So, is it possible to have only one parser for all code written in pile syntax?
I suppose that we will always need to have a second parser (which will maybe be
Christian Aisleitners) for the nopile syntax.

Does this parser exist already and is it working -- the above seems to imply
that it is currently not in use?

Another question:

I believe that you have posted a long time ago that you had succesfully built
Axiom with CMUCL. Is this true and is this reproduceable? I just found the
link, it is

http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz

So, couldn't we add CMUCL as a second compiler?

\start
Date: 02 Nov 2005 12:03:19 +0100
From: Martin Rubey
To: Juergen Weiss
Subject: dependent Types

Dear Juergen,

since you seem to be quite knowledgable of the interpreter, would it be
possible that you look at

http://wiki.axiom-developer.org/219TheInterpreterDoesNotUnderstandDependendTypes

It would be really wonderful if you could resolve this!

\start
Date: Wed, 2 Nov 2005 05:27:38 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: Boot vs. Lisp - various

--- Bill Page wrote:

> On November 1, 2005 10:36 AM C Y wrote:
> > ...
> > I'd cast my vote for Lisp, somewhat because of my own
> > bias but mostly because Tim is accomplishing a lot
> > of stuff and I'm eager to see that continue.
> 
> People seldom vote during a war :) but I agree that Tim is
> accomplishing a lot of stuff and I am also eager to see that
> continue. I believe Tim is very committed to Axiom and I doubt
> whether my haranguing him about his intentions to replace boot
> with lisp will have much affect on that.

Agreed.

> > ... That's the real beauty of the whole literate document
> > idea - the IDEAS will work regardless of the language,
> 
> I think you put entirely too much faith in the concept of
> literate programming. The description of an idea is very
> different than the implementation of an idea. Very seldom,
> if ever, is a description written in a natural (human)
> language a sufficient basis of an implementation. There
> are always loose ends and forgotten details.

True, but those can be fixed up over time.  Often the hard part is
figuring out what on earth a particular block of code is trying to
accomplish in the first place.

> And some people are much better writers than others (programmers
> are in general notoriously bad). I don't mean by this that
> literate programming is a not a good thing - just that it
> has its limitations.

I think we can agree there is no optimal solution.  The only way I know
to COMPLETELY specify something other than using program code itself
would be the B Method or some other formal method.  I'd love to be able
to do this, but it's far beyond our current resources, particularly
given the lack of good free tools for working with the B Method.

If we can establish a standard for thorough, exaustive, exacting
documentation which is still usable early on, I think it will go a long
way towards establishing the right kind of momentum.  Ultimately, human
readable documentation and code is all about conveying ideas.  Details
always have to be handled on a per-implementation basis, but the fewer
implicit and undocumented behaviors the better.  A description of an
algorithm, for example, should be implementable in any language. 
Details if its implementation in that language can't be specified
without actually writing it, but if the algorithm is clearly and
completely described that should be enough.
 
> > ...
> > All mathematical work done in SPAD/Aldor doesn't have to
> > care one way or the other, so that work survives regardless,
> > and I'm really hopeful that we will reach a point where
> > most significant work in Axiom takes place at that level,
> > because that will mean Axiom is functioning as a mathematical
> > and scientific research platform.
> 
> In my opinion we are already at that point. Or rather, we are
> anxiously waiting for more research-oriented users to show up.
> The work that Tim is doing now is mostly aimed at the longer
> term that will not immediately affect Axiom's suitability as
> a research platform. The issue of boot vs. lisp is a similar
> issue. It doesn't have any immediate impact on the usability of
> Axiom, but it (may) have a large impact on it's maintainability.

It is my hope that very little maintainance will need to be done once
this phase of the project is complete.  ANSI Lisp is now a defined
standard, and if we can implement all of the core (non-graphical)
functionality in that language we should be able to function as
designed on any ANSI Lisp implementation.  (Fortunately, this is
currently testible.)  If our designs are sound and don't need a
significant amount of change in the future, worrying about Axiom below
the level of SPAD/Aldor will hopefully become a thing of the past.  

I admit this is likely impractical, but hopefully we will be able to
approach this ideal closely.

That's one of the reasons I actually favor building up McCLIM and
implementing all the core plotting and graphics abilities in it -
McCLIM will need to adapt backend code to changing graphics systems on
various operating systems, but the logic defined for Axiom will
hopefully remain constant and unchanging.  In the same fashion, lisp
implementations will have to adjust to shifting operating system
developments, but the Axiom core won't need changes as long as it
relies only on the features in the ANSI standard.

> > Two points I wish to mention - 1) The CAS community is a
> > small subset of the total programming community, but within
> > that community Lisp is a much bigger deal than otherwise -
> > I think it is this community we are likely to attract,
> > rather than the general community
> 
> I don't agree that CAS users are a subset of all programmers.
> I think a large number of people use systems like Mathematica
> and Maple without programming at all. 

Sorry, I should have said the CAS development community.

> Most CAS *developers* i.e. CAS users who write new applications
> within some given environment,  of course must program in some 
> language or other but then usually only at the highest level 
> language available.

Right.  I guess the best way to the group I mean is CAS "implementers"
who build these higher level systems.

> I think only a small fraction of them might also know lisp.
> So if we target primarily the lisp programmers in this group,
> we are limiting ourselves unnecessarily.

I think it's better to try to approach things from the standpoint of
wanting to ensure that CAS users and "highlevel developers" don't have
to be come CAS implementers.

> > 2) SPAD will only be a starting point for people who have
> > programmed a lot of SPAD code (not many currently) and also
> > want to work on the internals of Axiom the program.  I'm
> > hoping this will actually work a bit in reverse -programmers
> > who are not up on the heavy duty mathematics side so much
> > (for high level math that's most of them, at a guess) will 
> > start out by working on the Lisp side (with its documentation,
> > tools, etc. to help them getting started with Lisp) and then
> > graduate to working on the mathematical side, where learning
> > SPAD/Aldor will be part of learning to express high level
> > mathematics in a computer.
> 
> I have a very hard time understanding what someone who does not
> know SPAD might be able to contribute to internal programming
> in Axiom. 

Given a stable Axiom core and Aldor compiler that do not need major
tweaking, the most that should have to be done is an occasional minor
bugfix or portability change.  This type of task can be accomplished by
someone familiar with the implementation language, and I'm hoping once
we're done with this phase no modifications more significant than that
will be needed.  Endless redesign of the languages of Axiom is not a
project goal - the languages should, as nearly as possible, be fixed in
stone.

> I don't think having a lot of experience in SPAD is
> necessary - only the basic syntax and usage plus a knowledge
> of how SPAD fits into the overall Axiom design is really
> important. In general it is not necessary to know a lot of
> mathematics to program in SPAD. However the Axiom library that
> is written in SPAD does represent a considerable amount of
> mathematical knowledge and to use it and extend it effectively
> does require some of this knowledge.

Right.  But the latter task (extending the libraries) I'm hoping will
be a completely different set of tasks than whatever minor "under the
hood" work will be required, and that the ability to do the latter will
require only adjusting to some minor syntax change or package locking
adjustment in the lisp implementation. 

> In general I don't think trying to learn mathematical programming
> from the "bottom-up" so to speak is a good idea.

oops.

> I am certain
> that this is not what the original designers of Axiom had in mind.
> That is why SPAD is such a high level language when it comes to
> expressing mathematics.

I thought it was high level to avoid the need of mathematicians ever
becoming programmers (the "ten year" requirement), but I suppose maybe
that's overly optimistic.

> > Actual honest to goodness mathematical researches and scientists
> > are probably the LAST people who want to work on the guts of
> > Axiom except out of need for a working tool - they want to USE
> > it to do other stuff.
> 
> Yes I agree. But in spite of that I do think that these people
> are still the mostly likely people who *will* do this kind of
> work. 

That's what grad students are for - "here, fix this" ;-).  I think we
should try design so that there is little to no work of this type to be
done in the first place, but I concede this is likely to be not totally
achieveable in practice.

> The other stuff that they really want to do is what
> motivates them to dig in and do whatever seems necessary to
> get the computer system to do what they need. Inevitable some
> of them adopt new "deeper" goals and spend most of their time
> implementing CAS internals and helping other people do what
> they really want to do. It seems to me that this is how it
> has gone in a very large number of cases since the beginning
> of this field.

Yes, but the number of people who take the latter path are EXTREMELY
few, perhaps in part because so few are qualified and have the luxury
to do so.  The vision I prefer is programmers doing low level work to
keep Axiom running and mathematicans using it to get things done, like
auto mechanics and drivers.  The mechanic isn't concerned about the
route or the destination, just that the car works.  Likewise, most
drivers don't want to know HOW the car works, just that it does and is
reliable - they want to learn how to drive, then go places.  I tend to
view software the same way.
 
> In fact I think the design of some computer algebra systems
> has sometimes suffered because those most motivated to do the
> work did not have particularly strong backgrounds in computer
> science, being perhaps excellent mathematicians but often
> self-taught in compiler design and user interface design. In
> this regard I think Axiom was exceptionally fortunate to have
> among it's developers people with both of these skills.

Agreed!  In many cases with software written by scientists it's clear
that the software is simply a means to an end, and the effort put in is
only that effort which gets them the answer they need.  I think Tim
made a comment about this once the 3x3x3 phenomena involved with
implementing software for different purposes.

> > They'll be working at the Aldor/SPAD level, and any need to
> > go lower will probably get reported as a bug to be fixed by
> > the team.  After all, how many scientists would request to
> > hack on the Mathematica source code?
> 
> I think you really should take a poll. :) 

I should :-).  I'd need to make the distinction though - how many want
to fix an annoying bug that shouldn't be there in the first place, vs.
how many want to explore new methods of CAS implementation.  I'm
betting most of the yeas would be in the former category.

> For example, from my
> experience I know a lot of researchers who would be very glad
> to get a chance to "hack" in the internal code of Maple. Very
> few of them would say they are entirely happy simply letting
> the developers solve the bugs. That is one of the reasons why
> there is a lot of pressure among CAS users for open source.

I'd be curious - how many of these bugs are due to mathematical errors
(e.g. algorithms that are incorrect) vs. "programmer level" bugs (e.g.
"whoops, semicolon there")?  (Not rhetorical - I really am interested.

> > They want it to solve problems without their needing to do
> > that.
> 
> As I said, I agree that that is what they want to do but not
> what all of them end up doing.

That's true (and a very nice thing!) but we want to make sure they make
that choice out of desire rather than necessity, to the extent that is
possible.  I have a feeling most programs written today could be
improved on in that respect.

> > Since we want to become a rising force in the mathematical
> > community our goal has to be to provide a program where people
> > can focus on the math rather than the program.  (Of course,
> > this is all speculation so it may or may not be worth anything.)
> 
> If we could accomplish that goal, than I think it would be
> worth a lot. I think that Axiom comes closer to that goal
> than most of the other systems.

True.  I also think our being able to achieve that goal is the only
possible way for us to gain market share in the mathematical and
scientific communities.  Mathematica has a great deal of inertia and
work already done in it, and so (perhaps to a slightly lesser extent)
does Maple.  We are going to have to be compelling, and the only way I
can think to do that is to be as bug free as humanly possible, both
from a mathematical algorithm standpoint and a programming standpoint. 
Otherwise the cost and inconvenience of the know, established, standard
commercial programs becomes less than the cost of the time required to
build up the new platform.

> > ... 
> > > We must assume that the people who choose to work on Axiom
> > > already have quite a lot of other relevant experience
> > > including programming in several languages.
> > 
> > I disagree - I think we want to appeal to mathematicians
> > and scientists, who quite often are NOT (or don't want to be)
> > computer programmers.  
> 
> I am sorry. What I meant was for this assumption to apply
> to people who want to work on the *internals* of Axiom, i.e.
> Axiom developers, not Axiom users. I agree with your statement.

Oh, oops.  Yes, I read that wrong.  I agree the people currently on the
project (mostly) have a lot of other experience.  But the people on the
project now are also for the most part a rare breed - those willing to
pioneer a new system in the face of stiff competition.  Academic folk
are by nature rather conservative about such things (understandably)
which leads to things like journals being able to charge hundreds of
dollars for a single subscription.  The opportunity cost and risk of
switching systems (or journals) is very very high, and so the lure must
be very strong.  Most of us currently on the project are not active phd
mathematical researchers, am I right?  At this stage of the project I
would not expect us to appeal to that audience - we need to be strong,
stable, friendly from an interface standpoint, and demonstrate
compelling abilities.  We have to make it so NOT using Axiom looks like
a dangerous decision. ;-)

> > > I think this is what limits the potential developers much
> > > more than just learning another new language.
> > 
> > Maybe I'm alone in making the distinction between Axiom the
> > programmer's challenge and Axiom the mathematical environment,
> > but I'm hoping that level of abstraction is possible because
> > it is likely to appeal to non-programmers.
> 
> I think you are right in making this distinction but things
> are not quite as separable as you seem to imply.

Currently, I agree.  But I think it's a worthwhile goal to keep in
mind, because we have an uphill battle ahead of us.

> > > Maintaining both a library compiler (SPAD) and an interpreter
> > > (an integral part of the user interface) is inherent in the
> > > design of Axiom. BOOT is closely related to SPAD (or perhaps
> > > better said, SPAD is closely related to BOOT). So really
> > > there is no additional compiler to maintain.
> > 
> > You mean the same compiler compiles both BOOT and SPAD
> > with no additional complexity added due to compiling BOOT?
> 
> I mean that the problem of compiling BOOT is essentially
> a subset of the problem of compiling SPAD. In a sense BOOT
> is just SPAD but with a very limited set of types. So yes,
> conceptually speaking there is really not additional complexity
> added due to compiling BOOT.

Huh.  Is the same true for Aldor?

> But from what I have seen and understood so far, Tim is right
> that the current Axiom code contains a lot of "cruft" and is
> in some cases quite far from optimal even though it works.
> So in the case of BOOT and SPAD I expect that a lot of the
> essentially similar code is actually duplicated or implemented
> in slightly different ways.

Ugh.

> > But mathematicians aren't going to want to work on a compiler
> > (it's hard to get funding for things like that.)  They want to
> > do math.
>
> Ah, there's the rub.

But also a chance for us, if we can enable this in a way that current
systems cannot.  Axiom's top level language and literate programming
style might be considered "doing math."  That's the goal, at least.  So
if the "program" parts of Axiom can be made robust enough so they don't
get in the way, we might get mathematicans who are funded only for
"mathematics" to give Axiom a look.

>...
> > I think wanting to make changes to Axiom itself will be a
> > different job from wanting to create new mathematical abilities.
> > It is quite possible there are others (like me) who are not
> > likely to make any spectacular mathematical contributions to
> > Axiom but are interested in providing features and functionality
> > for those who can.
> 
> If you can complete your work on a units system for Axiom then
> I think that would potentially be quite spectacular.

Thanks :-).  

> > For folks like me, the guts of Axiom being similar to the high
> > level language is pretty much totally irrelevant.  In THAT
> > situation, there is a clear advantage to not using a custom
> > language, because hypothetically if I were a good Lisp programmer
> > (Granted I'm not at the moment) I could hook in FFI bindings to
> > the GNU Scientific Libraries.  Starting from BOOT I haven't got
> > the faintest idea of how to proceed.  Lots of things like that
> > will crop up over time, and Lisp already is working on the
> > problem of being able to interface with a large number of
> > foreign libraries via FFI.
> 
> Exactly that issue came up in Kai Kaminski's work on Axiom UI.
> In that case Kai choose initially to use an entirely separate
> lisp process (in fact written in clisp rather than gcl because
> of ansi compatibility) and to communicate with Axiom via a
> pipe or socket.

Kai, did you do that because you wanted to avoid having to run the UI
in the same thread as Axiom itself or because of toolkit limitations?

> But gradually and during the latter stages of
> his work he discovered that he had to make changes in some
> boot code in Axiom in order to support Scalable Vector Graphics
> in the AxiomUI browser. 

Really?  Are the plotting routines written in BOOT?

> Now as gcl approaches full ansi compliance and after Axiom is 
> ported to the ansi standard (see another recent thread on this 
> subject), I wonder if Kai might have used a different approach and
> written more in boot?

I guess I would have tried making a cl-svg package in the hopes of
getting help from projects outside of Axiom, but that's just me.

> > In the end, Tim is being very productive, and that's a really
> > rare thing.
> 
> I presume that you mean something like "productivity in open
> source is a rare thing"? Or did you really mean to imply that
> Tim is not usually so productive? :) I don't think so.

Er, yeah :-).  Clearly Tim has been very productive very often.

> > I'm cheering him on regardless - literate documents will
> > make sure Axiom survives any language.  If someone wants
> > someday to do a new CAS, we want to set things up so that
> > to do anything other than start associating code with the
> > documentation part of the Axiom literate pamphlets wouldn't
> > make any sense at all :-).
> 
> 
> I don't think literate programming is really such a "magic
> bullet", but I am all for the writing of documentation.

It's not a silver bullet, true, but a silver bullet is in fact
impossible when it comes to conveying information - there is no one way
that is going to work for all people in all situations.  The best way I
know of to think about it is to try and treat it like a proof - define
one's core concepts, what they are based on, and then build on those
concepts assuming as little prior knowledge as is practical and stating
assumptions when made (and what to do in case they are invalid - e.g.
if a document assumes familiarity with CLOS provide links to allow the
reader to become familiar with CLOS if they aren't, as opposed to just
mentioning that CLOS familiarity is assumed and going on.)  That's why
I love the idea of literate documents as academic papers - the idea of
citing references, building the understanding of the subject up from
the basics, etc.  If I were documenting the algebra, I would try to
start at the set theory that underlies the whole global design itself -
what is set theory, why it's interesting, which versions Axiom makes
use of and why, "casual" vs. "formal" set theory and reasons for each,
etc. (I don't know enough about it to know what all I would need) and
once that foundation was solidly laid, build on it in describing the
next level.  I would like to see Axiom's mathematical structure in
effect represent the dependancy logic tree of all of mathematical
theory, from the foundational assumptions right up through to PDE
solution techniques and numerical algorithms.  That's also why I would
like to formally specify what properties of the underlying language
(BOOT, Lisp, whatever) the top level definitions are relying on to
implement their ideas, since a violation of those assumptions could (in
theory) subtly break Axiom or allow for incorrect results.  I guess
that's another reason for my preferring not to have too many languages,
since if an attempt is made to do this each language would have to lay
out these assumptions.  In the case of Aldor->Lisp it is only necessary
to identify what properties of the lisp functions Aldor is relying on
for performance to be as designed - this is in effect a slightly more
casual approach to formal methods programming and would lay the
foundation for someone with expertise to make it truly formal.

> Three cheers for Tim! And I hope that real soon now, some other
> axiom developers will come along to help out with this
> enormous task.

Well, once I get the units package figured out (if I ever do...
grumble...) I'd be glad to start trying to document the foundational
design principles of set theory used in the Axiom libraries. (I guess
that would be the core of the SPAD/Aldor language design as well?) I
should point out I'm totally unqualified, but in a sense that might be
an advantage since if I can document it so that I understand it, anyone
should be able to - I won't make any hidden assumptions because I don't
know enough TO make the assumptions.  Of course, there's also the
chance I'll royally mess it up, but I'm game to take a shot at it... 
It can only be educational, and worse case scenario my stuff could be
thrown out and someone else better qualified can take a shot at it.

\start
Date: 02 Nov 2005 15:12:52 +0100
From: Martin Rubey
To: Cliff Yapp
Subject: Re: was: Boot vs. Lisp / a smaller project

Cliff Yapp writes:

> I'd be curious - how many of these bugs are due to mathematical errors
> (e.g. algorithms that are incorrect) vs. "programmer level" bugs (e.g.
> "whoops, semicolon there")?  (Not rhetorical - I really am interested.

Well, most bugs (or, maybe: surprising results) I encountered so far are really
design problems. For example: that %pi < %e is really a design problem of the
EXPR domain...

Although I think that there are cures, they involve a lot of work. Currently I
have little time for Axiom, so I try to fix small things.

> Well, once I get the units package figured out (if I ever do...
> grumble...) 

you reallly should.

> I'd be glad to start trying to document the foundational design principles of
> set theory used in the Axiom libraries. (I guess that would be the core of
> the SPAD/Aldor language design as well?) 

I'm not quite sure what you mean. But I'd advise you anyhow to take up a small
project (especially if you find units too big for the moment) and implement
this first.

In fact, here is something for you:

Currently, there is a category StepThrough defined in catdef.spad. It is used
only in very few places, and as I noted in 

http://wiki.axiom-developer.org/220StepThroughIsBraindead

it is braindead.

What it really should do is to implement the notion of a countable set. I was
surprised at first, but this can be effectively implemented.

So, maybe you would like to do this. You will probably learn a *lot* about
axiom rather quickly, since you will have to implement nextItem and prevItem
for many domains, and you will have to document what it is used for in those
few where it is already used, i.e., GENPGCD and in PFBRU.

I have already working code for fraction.spad, so if you are interested, I'll
send you the details.

\start
Date: Wed, 2 Nov 2005 06:59:28 -0800 (PST)
From: Cliff Yapp
To: Martin Rubey
Subject: StepThrough

--- Martin Rubey wrote:

> Cliff Yapp writes:
> 
> > I'd be curious - how many of these bugs are due to mathematical
> > errors (e.g. algorithms that are incorrect) vs. "programmer level"
> > bugs (e.g. "whoops, semicolon there")?  (Not rhetorical - I really
> > am interested.
> 
> Well, most bugs (or, maybe: surprising results) I encountered so far
> are really design problems. For example: that %pi < %e is really a
> design problem of the EXPR domain...

Hmm.

> Although I think that there are cures, they involve a lot of work.
> Currently I have little time for Axiom, so I try to fix small things.

That's open source - do what can be done with available resources.
Unless some generous soul with mucho dinero wants to give us all day
jobs doing this :-).

> > Well, once I get the units package figured out (if I ever do...
> > grumble...) 
> 
> you reallly should.

I intend to.  I'm still reading papers and looking over other systems
out there - I'm going to try my best to do this right.  Hopefully in
another week or so I'll have something I can send Dr. Sit without
feeling like I'd be wasting his time.

> > I'd be glad to start trying to document the foundational design
> > principles of set theory used in the Axiom libraries. (I guess 
> > that would be the core of the SPAD/Aldor language design as well?) 
> 
> I'm not quite sure what you mean.

Well, I might be saying it wrong.  My understanding was that Axiom's
design tries to represent the basic theories and axioms of mathematics
and build subsequent mathematics off of them.  I know this is imperfect
- there are circularities in the design which cause significant
problems for the bootstrap build process - but this part of Axiom has
always appealed to me.  I wanted to relate the most basic concepts in
Axiom to their mathematical roots - Axiom, unlike any other system
except maybe MuPAD, is said to be well founded in modern mathematical
theory.  I would like to document what we are considering the
foundations of modern mathematical theory and how our design reflects
them, and tie that documentation to the code that actually does the
job.  Surely this will have to be done eventually if we are to hold up
the design of Axiom to review and criticism successfully.

> But I'd advise you anyhow to take up a small project (especially if
> you find units too big for the moment) and implement this first.

Not a bad idea.  (In fact, that was my original idea with units ;-)

> In fact, here is something for you:
> 
> Currently, there is a category StepThrough defined in catdef.spad. It
> is used only in very few places, and as I noted in 
> 
> http://wiki.axiom-developer.org/220StepThroughIsBraindead
> 
> it is braindead.

I fear I am too, as I am not quite following what you want this
function to do.  You say it provides the following:

"a function init() which yields an initial element of the domain and a
function nextItem(n) which produces the element after n"

How does one define what the "initial element" is in any particular
domain?  How do you define what element comes "after" another element? 
I suppose Postive Real Integers would be obvious - init()->0, after
that comes 1, etc., but you suggest "Float" should have StepThrough
implemented? I have absolutely no idea what "next" means in this
instance.  I suppose initial element would be 0.0 - is the element
"after" this element 0.1?  0.0001?  Clearly I'm missing something
fundamental but I'm not sure what.

> What it really should do is to implement the notion of a countable
> set. I was surprised at first, but this can be effectively 
> implemented.

I'll have to read up on the idea of a countable set.
 
> So, maybe you would like to do this. You will probably learn a *lot*
> about axiom rather quickly, since you will have to implement 
> nextItem and prevItem for many domains, and you will have to 
> document what it is used for in those few where it is already used, 
> i.e., GENPGCD and in PFBRU.

Sounds interesting, but I'd have to be comfortable first with what
StepThrough is supposed to achieve, and I'm obviously missing some
critical pieces.
 
> I have already working code for fraction.spad, so if you are
> interested, I'll send you the details.

I'd be interested certainly, but I need some background first.  (BTY,
this is why I said earlier I was unlikely to make any spectacular
mathematical contributions. ;-)  Undoubtedly this should be obvious to
me.)

\start
Date: Wed, 2 Nov 2005 10:13:34 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Boot vs. Lisp - various

On November 2, 2005 8:28 AM C Y wrote:

> ...
>>> Starting from BOOT I haven't got the faintest idea of how to
>>> proceed.  Lots of things like that will crop up over time,
>>> and Lisp already is working on the problem of being able to
>>> interface with a large number of foreign libraries via FFI.
>
> Bill Page wrote:
>> 
>> Exactly that issue came up in Kai Kaminski's work on Axiom UI.
>> In that case Kai choose initially to use an entirely separate
>> lisp process (in fact written in clisp rather than gcl because
>> of ansi compatibility) and to communicate with Axiom via a
>> pipe or socket.
> 
> Kai, did you do that because you wanted to avoid having to run
> the UI in the same thread as Axiom itself or because of toolkit
> limitations?
> 

I am sorry, I must retract one thing I wrote earlier. In the
quoted email on November 1, 2005 11:23 I went on to write:

>> But gradually and during the latter stages of his work he
>> discovered that he had to make changes in some boot code in
>> Axiom in order to support Scalable Vector Graphics in the
>> AxiomUI browser.

Sorry. I have reviewed my email and the archive that Kai produced
as part of the AxiomUI project and I see that what I wrote above
is wrong. During the AxiomUI project Kai did not write boot code
for the purpose I indicated but rather SPAD, although at several
times we did discuss the issue of boot vs. lisp.

You can see the pamphlet part of Kai's work online here:

http://wiki.axiom-developer.org/axiom--GUI--1

(The missing parts in the lisplib folder are external lisp
modules.)

>> Now as gcl approaches full ansi compliance and after Axiom
>> is ported to the ansi standard (see another recent thread on
>> this subject), I wonder if Kai might have used a different
>> approach and written more in boot?

I would like to let this question stand and hope Kai has a few
moments available to commment.

It is interesting to notice that Kai does in fact make use of
lisp's asdf tools in the build script for this package.

\start
Date: Wed, 02 Nov 2005 16:40:40 +0100
From: Jens Axel Segaard
To: list
Subject: Re: Boot vs. Lisp - various

Bill Page wrote:

> It is interesting to notice that Kai does in fact make use of
> lisp's asdf tools in the build script for this package.

Btw - one thing that speaks for asdf is that is widespread
in the Common Lisp community. I.e. using it makes it
easier to use premade CL libraries.

\start
Date: Wed, 2 Nov 2005 10:49:59 -0500
From: Bill Page
To: Juergen Weiss
Subject: re: Boot vs. Lisp

On November 2, 2005 3:58 AM Juergen Weiss wrote:

> ... 
> 4. Destructuring setq and destructuring comparisons
> 
> One of the highlights in BOOT is the possibility
> to use destructuring setqs and destructuring comparisons.
> This is extremly handy. Some random examples:
> 
>   for [[.,arg], :.] in singles while null tuple repeat
>     if arg is ['Tuple,.] then tuple := arg
> 
>   a is [=op,b,t1] =>
> 
> Without this feature the code will get almost unintelligible.
> And this feature is used in almost every line of code.
> ...

Of course ANSI lisp includes 'destructuring-bind' and other
operators which support this kind of thing.

http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_443.html#SEC443
http://www.bookshelf.jp/texi/onlisp/onlisp_19.html

"Destructuring is a generalization of assignment. The
operators setq and setf do assignments to individual
variables. Destructuring combines assignment with access:
instead of giving a single variable as the first argument,
we give a pattern of variables, which are each assigned
the value occurring in the corresponding position in some
structure."

--------

So if Axiom adopts ANSI lisp, some of these advantages might
disappear. But in general I think the boot syntax is preferrable
in the context of Axiom.

Does SPAD inherit much of this kind of destructuring?

In Axiom for example I know that I can write a multiple
assignment like this:

(1) -> [a,b] := [1,2]

   (1)  [1,2]
                            Type: List PositiveInteger
(2) -> a

   (2)  1
                                 Type: PositiveInteger
(3) -> b

   (3)  2
                                 Type: PositiveInteger

-------

Are more sophisticated forms of destructuring also possible?

\start
Date: Wed, 2 Nov 2005 13:11:37 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: StepThrough

On November 2, 2005 9:59 AM C Y wrote:
>...
> --- Martin Rubey wrote:
> >
> > Currently, there is a category StepThrough defined in
> > catdef.spad. It is used only in very few places, and as
> > I noted in
> >
> > http://wiki.axiom-developer.org/220StepThroughIsBraindead
> >
> > it is brain-dead.
>
> ...
> How does one define what the "initial element" is in any
> particular domain?

According to the documentation:

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/CatdefSpad

StepThrough denotes:

"A class of objects which can be 'stepped through'.
Repeated applications of \spadfun{nextItem} is guaranteed never to
return duplicate items and only return "failed" after exhausting
all elements of the domain.
This assumes that the sequence starts with \spad{init()}.
For infinite domains, repeated application \spadfun{nextItem}
is not required to reach all possible domain elements
starting from any initial element."

-------

So 'init()$SomeDomain' is not required to be uniquely defined.
It can in principle be any member of the domain. But some
choices might be more convenient then others because of the
requirements of 'nextItem'.

> How do you define what element comes "after" another element?

Since all representable members of a domain must have some
finite representation (i.e. internally represented by some
finite pattern of bits), so every member can be sorted in
at least this way with respect to all other members. In specific
cases, other orderings may be more convenient.

> I suppose Positive Real [sic] Integers would be obvious -
> init()->0, after that comes 1, etc., but you suggest "Float"
> should have StepThrough implemented? I have absolutely no idea
> what "next" means in this instance.  I suppose initial element
> would be 0.0 - is the element "after" this element 0.1?  0.0001?
> Clearly I'm missing something fundamental but I'm not sure what.

You should take a look at how 'nextItem' is defined in the
current Axiom source.

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FrontPage/searchw
iki?expr=nextItem

See for example:

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FmodSpad
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FfcatSpad
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FractionSpad

In Axiom 'Float' is not the same as the 'Real' number system.
For more details recall the discussion with William Sit about
Infinite Floats:

http://wiki.axiom-developer.org/RealNumbers

>
> > What it really should do is to implement the notion of a
> > countable set. I was surprised at first, but this can be
> > effectively implemented.
>
> I'll have to read up on the idea of a countable set.

In Axiom the natural representation of a countable set is
via a 'Stream'. If instead of 'nextItem' (or in addition to
it) every domain provided a stream, say 'memberOf', then
one would be able to write something like:

  (1) -> memberOf()$Integer

   [0,1,-1,2,-2, ... ]

                            Type: Stream Integer

Mathematically and logically speaking such domains are very
important for 'diagonalization' kind of proofs, e.g. that there
are the same number of Integers as there are PositiveIntegers.

> 
> > So, maybe you would like to do this. You will probably learn
> > a *lot* about axiom rather quickly, since you will have to
> > implement nextItem and prevItem for many domains, and you
> > will have to document what it is used for in those few where
> > it is already used, i.e., GENPGCD and in PFBRU.

As far as I know there is no operation of 'prevItem' anywhere
in Axiom and implementing it in addition to 'nextItem' or
'memberOf' might be challenging in some peculiar cases.

>
> Sounds interesting, but I'd have to be comfortable first with
> what StepThrough is supposed to achieve, and I'm obviously
> missing some critical pieces.

Clifford! Just get started. :) You don't have to know everything
in order to proceed. Do something. Try something. And continue
to ask questions. I often find programming is like that: The
more time I spend thinking about it, the less motivation remains
to actually do something concrete. But once I get started, it
(usually) just flows. At some point I can stop programming
and starting thinking again ... :) And the cycle repeats.

> 
> > I have already working code for fraction.spad, so if you
> > are interested, I'll send you the details.

I am not sure what Martin means here about working code for
'fraction.spad' since it seems to me that it already has
some working code for 'StepThrough', but I would encourage
him to put something in the SandBox on the Axiom wiki so that
you can start to play with it.

>
> I'd be interested certainly, but I need some background first.
> (BTY, this is why I said earlier I was unlikely to make any
> spectacular mathematical contributions. ;-)  Undoubtedly this
> should be obvious to me.)
>

Now don't be self-deprecating, Grasshopper. :) I don't see
why you should assume that it "should be obvious to me".
Many obvious things are hardly worth doing.

\start
Date: Wed, 2 Nov 2005 11:11:18 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: StepThrough

--- Bill Page wrote:
> > How does one define what the "initial element" is in any
> > particular domain?
> 
> According to the documentation:
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/CatdefSpad
> 
> StepThrough denotes:
> 
> "A class of objects which can be 'stepped through'.
> Repeated applications of \spadfun{nextItem} is guaranteed never to
> return duplicate items and only return "failed" after exhausting
> all elements of the domain.
> This assumes that the sequence starts with \spad{init()}.
> For infinite domains, repeated application \spadfun{nextItem}
> is not required to reach all possible domain elements
> starting from any initial element."

So the latter part is what Martin doesn't care for? 

> So 'init()$SomeDomain' is not required to be uniquely defined.

But it is presumably supposed to return something - a random starting
point, perhaps?

> It can in principle be any member of the domain. But some
> choices might be more convenient then others because of the
> requirements of 'nextItem'.

So the question becomes should the starting point be specifically
specified for each domain, even if there is no advantage to any
particular choice?

> > How do you define what element comes "after" another element?
> 
> Since all representable members of a domain must have some
> finite representation (i.e. internally represented by some
> finite pattern of bits), so every member can be sorted in
> at least this way with respect to all other members. In specific
> cases, other orderings may be more convenient.

OK.  So all integers in theory have a unique representation and this
can be arrived at, even if in practice there are limits to the size of
the integers the computer can handle?
 
> > I suppose Positive Real [sic] Integers would be obvious -
> > init()->0, after that comes 1, etc., but you suggest "Float"
> > should have StepThrough implemented? I have absolutely no idea
> > what "next" means in this instance.  I suppose initial element
> > would be 0.0 - is the element "after" this element 0.1?  0.0001?
> > Clearly I'm missing something fundamental but I'm not sure what.
> 
> You should take a look at how 'nextItem' is defined in the
> current Axiom source.

[snip]

> In Axiom 'Float' is not the same as the 'Real' number system.
> For more details recall the discussion with William Sit about
> Infinite Floats:
> 
> http://wiki.axiom-developer.org/RealNumbers

Hmm. OK, so Floats are in fact a subset of Reals.  

Hmm.  Could we say that all Floats are representable by an integer
multiplied by ten raised to an integer power?

> > > What it really should do is to implement the notion of a
> > > countable set. I was surprised at first, but this can be
> > > effectively implemented.
> > 
> > I'll have to read up on the idea of a countable set.
> 
> In Axiom the natural representation of a countable set is
> via a 'Stream'. If instead of 'nextItem' (or in addition to
> it) every domain provided a stream, say 'memberOf', then
> one would be able to write something like:
> 
>   (1) -> memberOf()$Integer
> 
>    [0,1,-1,2,-2, ... ]
> 
>                             Type: Stream Integer
> 
> Mathematically and logically speaking such domains are very
> important for 'diagonalization' kind of proofs, e.g. that there
> are the same number of Integers as there are PositiveIntegers.

OK.  Do we actually want to provide this?
 
> > > So, maybe you would like to do this. You will probably learn
> > > a *lot* about axiom rather quickly, since you will have to
> > > implement nextItem and prevItem for many domains, and you
> > > will have to document what it is used for in those few where
> > > it is already used, i.e., GENPGCD and in PFBRU.
> 
> As far as I know there is no operation of 'prevItem' anywhere
> in Axiom and implementing it in addition to 'nextItem' or
> 'memberOf' might be challenging in some peculiar cases.

Hmm. Well, it's a start anyway.

> > Sounds interesting, but I'd have to be comfortable first with
> > what StepThrough is supposed to achieve, and I'm obviously
> > missing some critical pieces.
> 
> Clifford! Just get started. :) You don't have to know everything
> in order to proceed. Do something. Try something. And continue
> to ask questions. 

Oh, don't worry.  But while I might not have to know everything I
certainly need to know something! 

I'm intrigued by an idea which I mentioned above and which had actually
occurred to me once before - are all numbers representible in a
computer actually integers multiplied by powers of ten?  If so, is the
whole notion of floating point computation in a computer reducible to
integer calculations in scientific notation?

> I often find programming is like that: The
> more time I spend thinking about it, the less motivation remains
> to actually do something concrete. But once I get started, it
> (usually) just flows. At some point I can stop programming
> and starting thinking again ... :) And the cycle repeats.

What, no head banging? ;-).  I'll give it a shot and see what happens.

> > > I have already working code for fraction.spad, so if you
> > > are interested, I'll send you the details.
> 
> I am not sure what Martin means here about working code for
> 'fraction.spad' since it seems to me that it already has
> some working code for 'StepThrough', but I would encourage
> him to put something in the SandBox on the Axiom wiki so that
> you can start to play with it.

Agreed.

> > I'd be interested certainly, but I need some background first.
> > (BTY, this is why I said earlier I was unlikely to make any
> > spectacular mathematical contributions. ;-)  Undoubtedly this
> > should be obvious to me.)
> 
> Now don't be self-deprecating, Grasshopper. :) I don't see
> why you should assume that it "should be obvious to me".
> Many obvious things are hardly worth doing.

I was right - it should have been obvious. ;-)  I just wasn't thinking
about the limits of the type Float (which are actually universal to all
digital computers) - any finite digitial representation of real numbers
restricts the available numbers to a subset, and so next can actually
be defined as the next Float representible in the computer's Float
domain, which is a small number but does not approach zero at all
closely.  A step is meaningless in a continuum, but any numerical
domain a computer can work with is going to be discrete.  It's just
workable because the approximation is usually "good enough."  For
physical problems with measurement error bars, it might even be
provably good enough - for example, if we can represent length
descriptions to and just below the Heisenberg uncertainty limit we can
represent any measurement of length to any precision that the laws of
nature allow.  (I wonder if someone has done that...)

\start
Date: 02 Nov 2005 23:13:49 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Boot vs. Lisp
Cc: Mike Thomas

Bill Page writes:

| Hello Mike,
| 
| I trust all is well.
| 
| On October 31, 2005 4:01 PM you wrote:
| 
| > ... 
| > One wonders, however, just how complicated a build system
| > actually has to be particularly as Lisp is used elsewhere
| > in Axiom.
| > 
| 
| I agree that using *both* Lisp and BOOT is probably more
| complicated than it needs to be. But my solution to this
| would be precisely opposite the solution proposed by Tim.

When using homegrown language to develop a non-trivial system, I think
questions related to large availability in terms of community,
supported tools, etc., shall be be a determinin factor.  From my
perspective, I would find it a mistake not to prefer Lisp over a
dialect known to only a small community.

\start
Date: 02 Nov 2005 23:15:34 +0100
From: Gabriel Dos Reis
To: Bob McElrath
Subject: re: Boot vs. Lisp

Bob McElrath writes:

[...]

| It is far, far more important to have a system which people can jump
| into quickly than it is to have a system that is complete, thorough, and
| consistent.  If it is easy to get into, it will become complete,
| thorough, and consistent eventually.

\start
Date: Wed, 2 Nov 2005 15:58:27 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Axiom is now listed in the FSF Free Software Directory

http://directory.fsf.org/math/axiom.html

\start
Date: Thu, 3 Nov 2005 02:04:18 -0500
From: Tim Daly
To: list
Subject: boot vs lisp

Just to get an idea of the struggles that boot causes during the
system bootstrapping mode look at the bottom of
src/interp/setvars.boot.pamphlet

Notice that this is one of several files that contains the compiled
lisp code because the translation of this file is needed before the
boot compiler can run.

Note that this is not a recent change.

\start
Date: 03 Nov 2005 10:42:14 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: StepThrough

Bill Page writes:

> According to the documentation:
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/CatdefSpad
> 
> StepThrough denotes:
> 
> "A class of objects which can be 'stepped through'.  Repeated applications of
> \spadfun{nextItem} is guaranteed never to return duplicate items and only
> return "failed" after exhausting all elements of the domain.  This assumes
> that the sequence starts with \spad{init()}.  For infinite domains, repeated
> application \spadfun{nextItem} is not required to reach all possible domain
> elements starting from any initial element."
> 
> -------
> 
> So 'init()$SomeDomain' is not required to be uniquely defined.  It can in
> principle be any member of the domain. But some choices might be more
> convenient then others because of the requirements of 'nextItem'.

Well, there are hardly any requirments on nextItem. Only duplicates are
forbidden, that's not much.

> > How do you define what element comes "after" another element?
> 
> Since all representable members of a domain must have some
> finite representation (i.e. internally represented by some
> finite pattern of bits), so every member can be sorted in
> at least this way with respect to all other members. In specific
> cases, other orderings may be more convenient.
> 
> > I suppose Positive Real [sic] Integers would be obvious -
> > init()->0, after that comes 1, etc., but you suggest "Float"
> > should have StepThrough implemented? 

NO. Float is -- although obviously different from the reals -- a *model* for
them. So it would *not* have COUNTABLE.

> As far as I know there is no operation of 'prevItem' anywhere in Axiom and
> implementing it in addition to 'nextItem' or 'memberOf' might be challenging
> in some peculiar cases.

No, it is trivial given nextItem. However, it is *necessary* for implementing
nextItem$COUNTABLE for the Fractions, for example. Here comes some code:

This would replace STEP in catdef.spad:

)abbrev category COUNTABLE Countable
++ Description:
++ A class of objects which is countable. Intended as a replacement for
++ StepThrough. Repeated applications of \spadfun{nextItem} is guaranteed never
++ to return duplicate items and only return "failed" after exhausting all
++ elements of the domain.  This assumes that the sequence starts with
++ \spad{init()}.  For infinite domains, repeated application of
++ \spadfun{nextItem} is guaranteed to reach all possible domain elements
++ starting from the initial element.
++ Conditional attributes:
++   infinite\tab{15}repeated \spad{nextItem}'s are never "failed".
Countable(): Category == SetCategory with
    --operations
      init: constant -> %
        ++ init() chooses an initial object for stepping.
      nextItem: % -> Union(%,"failed")
        ++ nextItem(x) returns the next item, or "failed" if domain is exhausted.
      prevItem: % -> Union(%,"failed")
        ++ prevItem(x) returns the previous item, or "failed" if x=init().


Some comments:

This is only the bare minimum of operations. Very often (but not always) it
will be possible to implement an efficient operation nthItem. This might be
interesting for the generation of random elements of the domain according to
some distribution.

For many domains it will be possible to implement nextItem as a GrayCode...


And here is an example for an implementation for the domain FRAC in
fraction.spad:


    if S has StepThrough then
       init() == init()$S / 1$S

       nextItem(n) ==
         r := numer n
         if r = 0 then return 1
         s := denom n
         if (d1 := init()$S) = 0 then 
           d2: Union(S, "failed") := nextItem(d1)
           d2 case "failed" =>
             error "QuotientFieldCategory: a finite IntegralDomain _
                    should be a field"
           d1 := d2
         repeat
           if r = d1 then
             num := nextItem(s)
             den := r::Union(S, "failed")
           else
             num := prevItem(r)
             den := nextItem(s)

           (num case "failed") or (den case "failed") =>
             error "QuotientFieldCategory: a finite IntegralDomain _
                    should be a field"
           if numer(m:=(num::S/den::S)) = num::S then 
             return m
           else
             r := num::S
             s := den::S

It is a straightforward implementation of the diagonal argument I posted in a
previous mail.


> I am not sure what Martin means here about working code for 'fraction.spad'
> since it seems to me that it already has some working code for 'StepThrough',
> but I would encourage him to put something in the SandBox on the Axiom wiki
> so that you can start to play with it.

Now you hopefully see what I meant: The above is code for an implementation of
COUNTABLE for FRAC...

I claim that STEP is braindead, because it achieves much less than what can be
achieved.

> * univariate polynomials with coefficients in a counatble set, since
> the union of countably many countable sets is countable... Can you 
> find an effective enumeration?


Cliff Yapp writes:

> Define effective...  

Given a statement like "this set is countable", "effective" means that we can
implement an algorithm that enumerates all elements of the set -- possibly in
infinite time, though.

"Ineffective" would be, if we knew for some reason that a set is countable, but
we do not know how to give an enumeration.

For example, the wikipedia says -- correctly:

THEOREM: (Assuming the axiom of choice) The union of countably many countable
         sets is countable.

Thus we know now that the set of polynomials with coefficients in a countable
set and variables from a countable set is countable. Let's do univariate
polynomials in the variable x for a start:

Let R=(c1, c2, c3, ...) be the set of coefficients

Let P_d be the set of univariate polynomials of degree d with coefficients in
R.

Lemma: P_d is countable:

Proof: 

indices sum up to d

c1 + c1 x + c1 x^2 + ... + c1 x^d
                   
indices sum up to d+1
     
c2 + c1 x + c1 x^2 + ... + c1 x^d
                        
c1 + c2 x + c1 x^2 + ... + c1 x^d
                        
c1 + c1 x + c2 x^2 + ... + c1 x^d

...

c1 + c1 x + c1 x^2 + ... + c2 x^d

indices sum up to d+2

c2 + c2 x + c1 x^2 + ...             + c1 x^d

c2 + c1 x + c2 x^2 + ...             + c1 x^d

c2 + c1 x + c1 x^2 + ...             + c2 x^d

...

c1 + c1 x + c1 x^2 + .. + c2 x^(d-1) + c2 x^d

c3 + c1 x + c1 x^2 + ... + c1 x^d
                        
c1 + c3 x + c1 x^2 + ... + c1 x^d
                        
c1 + c1 x + c3 x^2 + ... + c1 x^d

...

c1 + c1 x + c1 x^2 + ... + c3 x^d

indices sum up to d+3

c2 + c2 x + c2 x^2 + ...             + c1 x^d

...

See how it goes on?              [end of Proof]

Now let

Let P be the set of univariate polynomials with coefficients in R.

Proposition: P is countable

Proof: P = U_{d>=0} P_d          [end of Proof]

The proof of the Lemma is effective, but the proof of the Proposition is not.
However, it is quite easy to give an effective proof. Try it!

By the way, I was wrong in one point. I said

> Thus, FLOAT, EXPR, AN are examples of domains that should *not* have STEP.

This is incorrect, since the Wikipedia says:

By a similar development, the set of algebraic numbers is countable, 

Thus AN should have COUNTABLE. (FLOAT and EXPR should not, that was correct.)

If you embark on this, I advise you to do the easy domains first:

NNI, PI, INT, FRAC.

SYMBOL might be a little more difficult in terms of implementation.

When you have done this, I suggest that you try to find an effective proof of
the Proposition above, or, if you do not succeed, I'll help. In any case, I
think it would be a good project for you, since the mathematics is easy to
follow, but the implementation might be difficult.

Finally, it would be necessary to document the operations that currently *use*
STEP, i.e., the operations in GENPGCD and in PFBRU.

\start
Date: Thu, 3 Nov 2005 08:34:55 -0800
From: Scott Morrison
To: list
Subject: Re: BAD tim

Hello everybody,

This is my first posting to this list. I worked at IBM Research off and on
for 9 years. I'm the primary author/designer of the interpreter and
HyperDoc, and I wrote the first code generator and optimizer for Aldor (then
called A#).

I found Tim's posting very interesting, and I just had to comment. (Hi Tim!)

>>POINT 3: Boot is a dead language.
>>
>>   There are approximately 10 people still living who have coded in
>>   boot and every one of them is doing something else with their
>>   life.


Being one of those 10 people, I have to agree with Tim and his opinion of
the Boot language. Dick Jenks told me that boot was to be the first step in
implementing the entire system in the Spad language. Once the syntax looked
like Spad, the next step would be to convert it to real Spad. Of course that
never happened, so the main purpose behind Boot is gone.

In my opinion Boot can be a convenient language to code in, but it has two
main problems. The use of indentation for grouping is just a bad idea. It
works well for one-page programs, but with anything with reasonable
complexity, it falls down. Just adding braces to Boot for grouping would go
a long way to making it more usable. The other problem is the lack of a way
to structure data. I fully agree with Tim on the problems with that
language.

>>I'm the only person likely to be hacking
>>   the interpreter for the near future, mostly because it is so big,
>>   ugly, unstructured, and undocumented.

Ouch. The truth hurts. Believe me, when I started writing the interpreter
some 21 years ago, I never imagined it would have such a long life. This was
my first major programming project out of college. After 20 years of
experience, I would do a lot of things differently today. These days I'm too
busy with my current job (graphics programming at Audtodesk) to be able to
devote any time to the Axiom project.

>>There is no reason (other than historical) why there are
>>   a dozen entry points into the interpreter that set wierd, undocumented,
>>   stateful flags. All that cruft must go away.

Good luck Tim. As the author of much of this cruft, I think you have your
work cut out for you. Maintaining functionality while refactoring the code
will be a major challenge. Your two year estimate seems about right if you
are planning on working on this full time. If not, I think two years is
optimistic.

I think the transition from Boot to Lisp could be done in an incremental
way, converting modules gradually, thus maintaining the integrity of the
system during the conversion. However, I agree that converting to Lisp
ultimately is the right thing to do.

I'm on the axiom-developer list now, so I can answer the occasional
question, but I won't have much time for this project, unfortunately.

\start
Date: Thu, 3 Nov 2005 13:02:09 -0500
From: Tim Daly
To: Scott Morrison
Subject: Re: BAD tim

> Hello everybody,

Hey, Scott! 

> 
> This is my first posting to this list. I worked at IBM Research off and on
> for 9 years. I'm the primary author/designer of the interpreter and
> HyperDoc, and I wrote the first code generator and optimizer for Aldor 
> (then called A#).
> 
> I found Tim's posting very interesting, and I just had to comment.
> 
> >>POINT 3: Boot is a dead language.
> >>
> >>   There are approximately 10 people still living who have coded in
> >>   boot and every one of them is doing something else with their
> >>   life.
> 
> 
> Being one of those 10 people, I have to agree with Tim and his opinion of
> the Boot language. Dick Jenks told me that boot was to be the first step in
> implementing the entire system in the Spad language. Once the syntax looked
> like Spad, the next step would be to convert it to real Spad. Of course 
> that never happened, so the main purpose behind Boot is gone.
> 
> In my opinion Boot can be a convenient language to code in, but it has two
> main problems. The use of indentation for grouping is just a bad idea. It
> works well for one-page programs, but with anything with reasonable
> complexity, it falls down. Just adding braces to Boot for grouping would go
> a long way to making it more usable. The other problem is the lack of a way
> to structure data. I fully agree with Tim on the problems with that
> language.

ah, right. i forgot about the "larger than one page" issue. i can count
characters by eye but i can't count whitespace. i used to convert the
whitespace to periods so i could get proper indentation in spad code.

the other "oh by the way" is that while you can seem to read boot code
without knowing lisp (a sort-of pseudocode syntax) you can't WRITE boot
code without knowing lisp. 

> 
> >>I'm the only person likely to be hacking
> >>   the interpreter for the near future, mostly because it is so big,
> >>   ugly, unstructured, and undocumented.
> 
> Ouch. The truth hurts. Believe me, when I started writing the interpreter
> some 21 years ago, I never imagined it would have such a long life. This 
> was my first major programming project out of college. After 20 years of
> experience, I would do a lot of things differently today. These days I'm too
> busy with my current job (graphics programming at Audtodesk) to be able to
> devote any time to the Axiom project.

hey, scott, that was not intended to be a flame directed at you.
you're one of the best programmers i've crossed path with in the
last 35 years. one indication is that you seem to still be programming
rather than retired into manangement.

the axiom system grew by accretion and was intended to be a research
platform rather than a product so we were all doing good-enough patch
jobs. of course in my experience most real products are just as bad
but the code never sees the light of day. i suspect that's what keeps
some products proprietary :-)

i never thought axiom would live this long either or i'd have at least 
included a docstring to give me some clue why i wrote some functions.
or taken my name out of the sources :-)

one big reason behind the literate programming push is my undying 
embarrassment over how bad my coding/nondocumenting style was 20 years ago. 
i don't write anything now unless it's in a literate style.


> 
> >>There is no reason (other than historical) why there are
> >>   a dozen entry points into the interpreter that set wierd, undocumented> ,
> >>   stateful flags. All that cruft must go away.
> 
> Good luck Tim. As the author of much of this cruft, I think you have your
> work cut out for you. Maintaining functionality while refactoring the code
> will be a major challenge. Your two year estimate seems about right if you
> are planning on working on this full time. If not, I think two years is
> optimistic.
> 
> I think the transition from Boot to Lisp could be done in an incremental
> way, converting modules gradually, thus maintaining the integrity of the
> system during the conversion. However, I agree that converting to Lisp
> ultimately is the right thing to do.

i am doing this in an incremental manner, actually. the lastest release
axiom--main--1--patch-46 removes two original files and adds a new
volume in the axiom book (book volume 5) which contains the actual
source code along with new documentation. each section of the book
will move some code from existing files in an incremental manner.
so the system will continue to build while slowly being converted.

the original book has been broken into 4 parts (not yet integrated):

v1 tutorial, v2 programming, v3 reference, v4 developer's guide

and the other volumes will (at least at this point in the plan) be
something like:

v5 interpreter, v6 compiler, v7 browser, v8 graphics, v9 algebra

so the whole system will be just a series of books. the focus in the
books will be toward human understanding of the code. extracting the
code for the machine is secondary but it's important that the ACTUAL
code be in the books and not some handwaving pseudocode.

eventually writing axiom code will be an "authoring" job rather than
a programming job,

> 
> I'm on the axiom-developer list now, so I can answer the occasional
> question, but I won't have much time for this project, unfortunately.

great! at least you'll find it entertaining. i'd encourage you to check
out bill page's work on page.axiom-developer.org. it's a wiki server
he is developing which allows you to type axiom inline in a page and
see the results. he's got quite a few interesting innovations there
and he's (almost) convinced me that the browser is the one-true-path
forward for the user interface.

the big struggle we've had is how to move the graphics so it runs
on linux and windows with the same code. suggestions are welcome.

\start
Date: Thu, 3 Nov 2005 22:16:05 -0500
From: Bill Page
To: Scott Morrison, Tim Daly
Subject: Terms of Surrender (was: BAD tim)

On November 3, 2005 1:02 PM Tim Daly wrote:

> Scott Morrison wrote:
>
> > Hello everybody,
> > 
> > This is my first posting to this list. I worked at IBM 
> > Research off and on for 9 years. I'm the primary
> > author/designer of the interpreter and HyperDoc, and
> > I wrote the first code generator and optimizer for Aldor 
> > (then called A#).

Hello Scott Morrison! I am very glad that you dropped in.

> > 
> > I found Tim's posting very interesting, and I just had to
> > comment.

Please.

> > 
> > >>POINT 3: Boot is a dead language.
> > >>
> > >>   There are approximately 10 people still living who 
> > >>   have coded in boot and every one of them is doing
> > >>   something else with their life.
> > 
> > 
> > Being one of those 10 people, I have to agree with Tim and 
> > his opinion of the Boot language. Dick Jenks told me that
> > boot was to be the first step in implementing the entire
> > system in the Spad language. Once the syntax looked like
> > Spad, the next step would be to convert it to real Spad.

Which came first: Boot or Spad? I thought from the way Tim
told it, that Spad was at least partly written in Boot. So
Boot came first? But what you wrote above suggests that
Dick Jenks was actively re-writing Lisp code into Boot in
preparation for eventually compiling the whole thing in Spad
itself.
 
> > Of course that never happened, so the main purpose behind
> > Boot is gone.

Why "of course"? Lack of resources? Or was there a technical
issue? Perhaps Spad was not quite up to the task?  What is
your opinion about the possibility of carrying out Dick Jenks
program in Aldor?

It seems illogical to conclude that because it never happened
that therefore the purpose of Boot is gone. Perhaps you mean
that you think the idea was ill-conceived from the beginning?
Looking back, would you say that there was some spirit of
rivalry between those responsible for the compiler parts of
Axiom versus the interpreter parts of Axiom? I.e. Did it seem
like "those compiler guys" wanted to take over the whole
project?

> > 
> > In my opinion Boot can be a convenient language to code in, 
> > but it has two main problems. The use of indentation for
> > grouping is just a bad idea. It works well for one-page
> > programs, but with anything with reasonable complexity, it
> > falls down.

Do you see that sort of failure occuring in the Python language?
To me Python programmers seem both dedicated to the language and
very productive.

> > Just adding braces to Boot for grouping would go a long
> > way to making it more usable. The other problem is the
> > lack of a way to structure data. I fully agree with Tim on
> > the problems with that language.

But both of these problems are solved in Aldor, right?

> 
> ah, right. i forgot about the "larger than one page" issue.
> i can count characters by eye but i can't count whitespace.
> i used to convert the whitespace to periods so i could get
> proper indentation in spad code.

These days most people use an emacs mode (or other editor)
with syntax highlighting. Eyeballing whitespace or counting
characters is irrelevant. And the concept of "page" is a
surely a relative one. A lot of code is never actually
printed on paper.

Generally writing a module that is "larger than one page" is
probably not very good programming style - like writing a
very long sentence with too many subphrases and clauses. It
is difficult for a reader to grasp and perhaps even difficult
for a compiler to optimize. A lot of the Spad code in the
Axiom library is less than one page per package domain or
category.

> 
> the other "oh by the way" is that while you can seem to
> read boot code without knowing lisp (a sort-of pseudo
> code syntax) you can't WRITE boot code without knowing
> lisp.

Why is that? Surely it is possible to write Spad code without
knowing Lisp? That was the point of Spad, wasn't it? (Otherwise
the mathematicians could have simply written in Lisp and this
whole issue would be moot, right?) If Boot is a simplified
form of Spad then why is knowing Lisp so relevant? And if by
"knowing lisp" you mean knowing the concepts on which lisp is
based, then I would be surprised to find many undergraduate
computer science students who did not have at least one
programming course which included at least an introduction
to lisp. (Maybe my experience here is too out of date?)

> ...
> > 
> > I'm on the axiom-developer list now, so I can answer the
> > occasional question, but I won't have much time for this
> > project, unfortunately.

I suppose that I have asked more than one "occasional question"
above. :) I hope that doesn't put you off replying to at least
some of the issues.

---------

Now about this language war ...

I think the fact that many people responded to the issue of
lisp vs. boot is a really good thing. In open source projects
it must be quite common to feel like one is "working in a
vacuum" because while many people may subscribe to the
project mailing list, usually only a few people of the more
vocally-inclined people tend to dominate it (I should know,
I do it too often. :). Unfortunately for me, the majority
seem to favour Tim's goal of "lispifying" everything possible.
And I happen to believe that occasionally compromise is a
good thing in a collaborative environment...

So, *if* I was thinking of such a compromise then there are
some "terms of surrender" that might make this easier:

1) Before any more "lispifying" goes on, *first* move Axiom
   over to ANSI lisp. This will make it possible to write lisp
   that conforms to modern practices and as high level as
   possible. It will also make Axiom less dependent on a
   particular implementation of Lisp and more easily portable.

2) No more just cutting and pasting the generated lisp output
   of Boot into the literate document! This seems pointless
   and a net loss in intelligibility even if it is accompanied
   by a verbal explanation of the code. The original Boot code
   is, as Tim admitted above, significantly more readable as
   "pseudo-code" then what the compiler outputs.

3) Where possible and practical, replace Boot code with Spad
   code as in Dick Jenks original vision instead of Lisp. Surely
   you are not going to argue that Spad is a "dead language"
   written by fewer than 10 surviving programmers? And even if
   that happens to be true ;), that is one thing that we are
   trying hard to change, right?

\start
Date: Fri, 4 Nov 2005 00:05:45 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: StepThrough

On November 3, 2005 4:42 AM Martin Rubey wrote:
> ...
> there are hardly any requirements on nextItem. Only 
> duplicates are forbidden, that's not much.

I was referring to:

> > only return "failed" after exhausting all elements of the
> > domain

If you can start with a unique "first" element than this is
easier. Also I am not convinced that "forbidding duplicates"
is always that easy either. Doing this could imply either
impossibly large storage requirements or run times.

> ...
> Float is -- although obviously different from the reals 
> -- a *model* for them. So it would *not* have COUNTABLE.
>

I am not exactly sure what you mean by *model* in this case
but I do not think Float is any more of a model for reals
than is Fraction Integer. It is no more difficult to define
'nextItem' in Float than it is in Fraction Integer. Instead
of 'numer' and 'denom' we have 'mantissa' and 'exponent'.

The Float domain has to do with numerical computation which,
while easier and faster than exact symbolic computation in
some respects, is actually more complicated than the real
numbers algebraically. E.g. Addition and multiplication of
floating point numbers is not associative.

On the other hand there is some very important work on
"Exact Real Numbers" and "Computable Numbers". See:

http://wiki.axiom-developer.org/RealNumbers

which in my opinion might well be said to be models for the
reals. Although these numbers are "computable" it seems to
me that it might be rather hard to construct a useful total
ordering and to compute something like 'nextItem'.

Axiom currently does not have any domain for Real that is
symbolically exact in the same sense in which the domain
Integer is exact.
 
> > As far as I know there is no operation of 'prevItem' 
> > anywhere in Axiom and implementing it in addition to
> > 'nextItem' or 'memberOf' might be challenging in some
> > peculiar cases.
> 
> No, it is trivial given nextItem.

In what sense? Of course you can always write

 prevItem(x) ==
  n=init()
  repeat
    p=n
    n=nextItem(n)
    x=n ==> p

But this could take a long time or a lot of space. Or are
you claiming there is always an effectively computable total
ordering? No partial orders?

> However, it is *necessary* for implementing
> nextItem$COUNTABLE for the Fractions, for example.
> Here comes some code:
>
> This would replace STEP in catdef.spad:
> ...
> ++ For infinite domains, repeated application of
> ++ \spadfun{nextItem} is guaranteed to reach all possible
> +  domain elements starting from the initial element.

So the main difference between Countable and the original
StepThrough category:

> ++ For infinite domains, repeated application
> ++ \spadfun{nextItem} is not required to reach all possible
> ++ domain elements starting from any initial element.

is replacing 'not required to' with 'guaranteed to' 

> 
> And here is an example for an implementation for the domain FRAC
> in fraction.spad:
> ... 
> It is a straightforward implementation of the diagonal 
> argument I posted in a previous mail.
> ... 
> Now you hopefully see what I meant: The above is code for an 
> implementation of COUNTABLE for FRAC...
>

Yes I see. The current code in Fraction is:

if S has StepThrough then
  init() == init()$S / 1$S
  nextItem(n) ==
    m:= nextItem(numer(n))
    m case "failed" =>
      error "We seem to have a Fraction of a finite object"
    m / 1

------

So although it obviously is not guaranteed to reach all
possible domain elements, it does "StepThrough" it.

> I claim that STEP is brain-dead, because it achieves much less 
> than what can be achieved.
> 

I agree. But worse than that, it seems that the current
implementation of 'nextItem' in 'Fraction' does not even meet
the requirements of 'StepThrough' for finite Fraction objects!

> ++ only return "failed" after exhausting all elements of
> ++ the domain

\start
Date: Fri, 04 Nov 2005 08:50:56 +0100
From: Gernot Hueber
To: list
Subject: axiom/aldor build error on FreeBSD5.4

Hello,

I want to build axiom--main--45 with native FreeBSD ports gcl (=2.6.6),
following the instructions on
http://page.axiom-developer.org/zope/mathaction/AldorForAxiom

Axiom builds fine (with some minor "hacks"), as well aldor tests build
and run properly, but building the src/aldor part fails with
[...]
%/axextend.as, /home/hueber/src/axiom--main--1--patch-45/src/aldor/as/axextend.as /home/hueber/src/axiom--main--1--patch-45/int/aldor/ap/.dir
"/home/hueber/src/axiom--main--1--patch-45/src/aldor/as/axextend.as",
line 382:
                macro  Rep == Ptr$Machine;
.................................^
[L382 C34] #1 (Warning) Definition of macro `Rep' hides an outer
definition.

Creating dependencies for ax0 C: 2
gmake[1]:
[/home/hueber/src/axiom--main--1--patch-45/int/aldor/dep_ax0.stamp]
Error 255 (ignored)
cat: /home/hueber/src/axiom--main--1--patch-45/int/aldor/gendeps/axlit.dep: No such file or directory
** Build failed
for /home/hueber/src/axiom--main--1--patch-45/int/aldor/deps/axlit.dep
[...]

when I rerun "gmake" the message changes:

[...]
Creating dependencies for ax0 C: 2
gmake[1]:
[/home/hueber/src/axiom--main--1--patch-45/int/aldor/dep_ax0.stamp]
Error 255 (ignored)
cat: /home/hueber/src/axiom--main--1--patch-45/int/aldor/gendeps/axlit.dep: No such file or directory
** Build failed
for /home/hueber/src/axiom--main--1--patch-45/int/aldor/deps/axlit.dep
cat: /home/hueber/src/axiom--main--1--patch-45/int/aldor/gendeps/axextend.dep: No such file or directory
** Build failed
for /home/hueber/src/axiom--main--1--patch-45/int/aldor/deps/axextend.dep
gmake[1]: ***
[/home/hueber/src/axiom--main--1--patch-45/int/aldor/dep_ax0.stamp]
Error 1
gmake[1]: Leaving directory
`/.amd_mnt/johnson/vol/vol0/home/hueber/src/axiom--main--1--patch-45/src/aldor'
gmake: *** [all] Error 2

Can anybody explain/solve this error?

Thanks

Gernot

--
DI Gernot Hueber
Email Gernot Hueber

\start
Date: Fri, 04 Nov 2005 00:00:26 -0800
From: Karl Hegbloom
To: list
Subject: Re: Terms of Surrender (was: BAD tim)

On Thu, 2005-11-03 at 22:16 -0500, Bill Page wrote:
> And if by "knowing lisp" you mean knowing the concepts on which lisp
> is based, then I would be surprised to find many undergraduate
> computer science students who did not have at least one
> programming course which included at least an introduction
> to lisp. (Maybe my experience here is too out of date?)

I wish that more colleges would introduce Computer Programming using the
Scheme language, rather than C++.  http://www.htdp.org/  is a great
textbook and it would be great to see more schools using it.  "Structure
and Interpretation of Computer Programs" is also one of my number one
favorites.  Lisp is at the heart of all programming languages, if only
in spirit.

> 3) Where possible and practical, replace Boot code with Spad
>    code as in Dick Jenks original vision instead of Lisp. Surely
>    you are not going to argue that Spad is a "dead language"
>    written by fewer than 10 surviving programmers? And even if
>    that happens to be true ;), that is one thing that we are
>    trying hard to change, right?

Don't give up on that.  It might take several years of study before I
can understand it very well.  At this point in time, I plan to study the
Axiom system in the future.  I'd like to learn more about how it works.

I have been using it from inside of GNU TeXmacs, which I'm sure you must
be familiar with.  I think it's a great interface, and could certainly
be developed into something even better.  Have you tried the TeXmacs
style file editing mode?  It's mathematics mode?

I think it would be really cool to port Axiom from 'noweb' to a TeXmacs
based literate programming system of some kind.  There is at least one
person on the TeXmacs users and/or development mailing list who has
mentioned this idea in the past.  Since TeXmacs keeps the document in a
tree form, it makes me ponder... what if an Axiom language, a descendant
of Spad or Aldor, was written especially for the TeXmacs environment,
utilizing a tree-form that encapsulates the semantics, not just the
appearance as type-set, of an expression --- something like the two
forms of MathML --- was created?  It could be semi-graphical, using an
evolved mathematical notation[1] maybe with some lines and arrows...
circles and arrows and an explanation on the back of each one.

-----
[1]: There is a good discussion of some of the ambiguities to be found
in traditional mathematical notation in http://en.wikipedia.org/SICM ;
also, the author of the ASTER system, which can read mathematics to the
blind, has learned some lessons re parsing TeX into a more semantically
relevant form.

\start
Date: 04 Nov 2005 11:10:42 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: StepThrough

Dear Bill, Cliff,

Clifford, are you still there? I'm not quite sure about your status now, are
you interested in pursuing this project?

Bill Page writes:

> > Float is -- although obviously different from the reals 
> > -- a *model* for them. So it would *not* have COUNTABLE.
> 
> I am not exactly sure what you mean by *model* in this case but I do not
> think Float is any more of a model for reals than is Fraction Integer. 
> It is no more difficult to define 'nextItem' in Float than it is in Fraction
> Integer. Instead of 'numer' and 'denom' we have 'mantissa' and 'exponent'.

OK, I surrender.

> On the other hand there is some very important work on "Exact Real Numbers"
> and "Computable Numbers". See:
> 
> http://wiki.axiom-developer.org/RealNumbers
> 
> which in my opinion might well be said to be models for the reals. Although
> these numbers are "computable" it seems to me that it might be rather hard to
> construct a useful total ordering and to compute something like 'nextItem'.

Since the set of computable numbers is countable and we can clearly only define
domains containing computable numbers in Axiom, all domains would have
COUNTABLE. Of course for some domains it will be more difficult to come up with
an enumeration than for others.

I had the feeling that FLOAT and EXPR INT were domains which should not be
countable, but it seems that this feeling should not be trusted.

In any case, it does make sense to sharpen the meaning of StepThrough.

-------------------------------------------------------------------------------
  
> > > As far as I know there is no operation of 'prevItem' anywhere in Axiom
> > > and implementing it in addition to 'nextItem' or 'memberOf' might be
> > > challenging in some peculiar cases.
> > 
> > No, it is trivial given nextItem.
> 
> In what sense? Of course you can always write
> 
>  prevItem(x) ==
>   n=init()
>   repeat
>     p=n
>     n=nextItem(n)
>     x=n ==> p
> 
> But this could take a long time or a lot of space. 

Yes. Of course, I did not claim that it would be efficient. However, in all
cases I considered, it was trivial.

I suspect that it will usually be only a simply modification of the algorithm
for nextItem.

> > Here comes some code:
> >
> > This would replace STEP in catdef.spad:
> > ...
> > ++ For infinite domains, repeated application of
> > ++ \spadfun{nextItem} is guaranteed to reach all possible
> > +  domain elements starting from the initial element.
> 
> So the main difference between Countable and the original
> StepThrough category:
> 
> > ++ For infinite domains, repeated application
> > ++ \spadfun{nextItem} is not required to reach all possible
> > ++ domain elements starting from any initial element.
> 
> is replacing 'not required to' with 'guaranteed to' 

Yes. Well, it's the only difference.

> Yes I see. The current code in Fraction is:
> 
> if S has StepThrough then
>   init() == init()$S / 1$S
>   nextItem(n) ==
>     m:= nextItem(numer(n))
>     m case "failed" =>
>       error "We seem to have a Fraction of a finite object"
>     m / 1
> 
> So although it obviously is not guaranteed to reach all
> possible domain elements, it does "StepThrough" it.
> 
> > I claim that STEP is brain-dead, because it achieves much less 
> > than what can be achieved.
> 
> I agree. But worse than that, it seems that the current
> implementation of 'nextItem' in 'Fraction' does not even meet
> the requirements of 'StepThrough' for finite Fraction objects!

Fraction takes an integral domain as parameter, and a finite integral domain is
a field. In fact, the domain Fraction should really test whether it's parameter
is a field and in this case return an error -- the interpreter does
this. Alternatively, we could say that in this case the denominator is always
equal to one.

It is not difficult to extend my code to "finite fraction objects". In fact, I
coded it that way first, until I discovered that the parameter domain is not
allowed to be finite.

Thus, it might be better to implement nextItem in the domain Localize.

\start
Date: Fri, 04 Nov 2005 04:17:34 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] 

After a grep I found the definition for 'random()$INT' in interp/spad.boot.pamphlet::

  (defun |random| () (random (expt 2 26)))

\start
Date: Fri, 04 Nov 2005 04:11:44 -0600
From: MathAction (anonyme)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] (nouveau) 

Currently there is a function 'random()' for 'IntegerNumberSystem', which is documented to return a random number::

   random   : () -> %
      ++ random() creates a random element.

Of course, this is really a half-lie. There is no uniform distribution over the integers, so one wonders which distribution is used.

After a grep I found the definition for 'random()$INT' in interp/spad.boot.pamphlet:

(defun |random| () (random (expt 2 26)))

So, at least the documentation should change. But in fact, I don't see why such a function should exist at all.

Martin

\start
Date: 04 Nov 2005 13:01:29 +0100
From: Martin Rubey
To: Bill Page
Subject: page.axiom-developer problem / FrontPage

Dear Bill,

it seems that there is a small problem with 

http://page.axiom-developer.org/zope/mathaction/FrontPage

If I click on "Axiom book" I get the link

http://page.axiom-developer.org/Mirrors?go=/public/book2.pdf&it=Axiom+Book

which does not work.

It should eiter be

http://wiki.axiom-developer.org/Mirrors?go=/public/book2.pdf&it=Axiom+Book

or 

http://page.axiom-developer.org/zope/mathaction/Mirrors?go=/public/book2.pdf&it=Axiom+Book

I suppose that usage of page.axiom-developer.org/zope/mathaction is
depreciated, but there are probably still many many links to that address out
there...

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

FrontPage design

I'm a little unhappy about the crowdy look of the FrontPage. I suggest that we
concentrate on the essentials. I think that:

* Buy Axiom Gear to help support Axiom...

should move to the download redirector.

* Check out what's new in the WebLog - page summaries by date

should move to theAxiomCommunity (which should be renamed to AxiomCommunity...)

* Read the list of frequently asked questions FAQ or check problems and
  solutions

should move to AxiomDocumentation

* update Axiom

contains no information yet and I think it won't in the near future. Can we
remove it?

* Axiom supports both SPAD and Aldor as library compilers

should go to ProgrammingAxiom

* Discuss Axiom in the Axiom Colloquium and contribute ideas for Future
  Development

should maybe go to theAxiomCummunity


* Google Summer Of Code supports Axiom User Interface (AxiomUI) project thanks
  to Lisp NYC!

should either be removed or moved to Sponsor (which would then have to be
renamed to Sponsors) 

-------------------------------------------------------------------------------

If there is agreement, I can redo the FrontPage. 

There are some more things that should be redesigned:

The WishList and SummerOfCode pages should be merged and redone. I think that
several projects are already completed. It would be good if every project on
this common page would have a link and a backlink to IssueTracker.

The bits and pieces of wiki-documentation to interpreter, SPAD and Aldor should
be regrouped.

Volunteers?

\start
Date: Fri, 4 Nov 2005 08:16:10 -0500
From: Tim Daly
To: Karl Hegbloom
Subject: Re: Terms of Surrender (was: BAD tim)

> I think it would be really cool to port Axiom from 'noweb' to a TeXmacs
> based literate programming system of some kind.  There is at least one
> person on the TeXmacs users and/or development mailing list who has
> mentioned this idea in the past.  Since TeXmacs keeps the document in a
> tree form, it makes me ponder... what if an Axiom language, a descendant
> of Spad or Aldor, was written especially for the TeXmacs environment,
> utilizing a tree-form that encapsulates the semantics, not just the
> appearance as type-set, of an expression --- something like the two
> forms of MathML --- was created?  It could be semi-graphical, using an
> evolved mathematical notation[1] maybe with some lines and arrows...
> circles and arrows and an explanation on the back of each one.
> 

if you start axiom and type

   )trace (|pf2Sex|)

and then type some expression 

   1

you'll see the input and output of this function. This function
(parsed function to s-expression) is internal to the axiom interpreter.
it takes the parsed input line and converts it to a lisp s-expression.
so the above '1' input yields

 1> (|pf2Sex| ((|Integer| (|posn (0 "1" 1 1 "strings") . 0)) . "1"))
 1< (|pf2Sex| 1)

the "1>" line tells you the function input.
the "1<" line tells you the function output.

notice that even a simple input line generates type information.

this function is not part of the exposed user interface because
there is nothing at the user level that needs this information.

\start
Date: Fri, 4 Nov 2005 08:20:17 -0500
From: Tim Daly
To: Karl Hegbloom
Subject: Re: Terms of Surrender (was: BAD tim)

> I think it would be really cool to port Axiom from 'noweb' to a TeXmacs
> based literate programming system of some kind.  There is at least one
> person on the TeXmacs users and/or development mailing list who has
> mentioned this idea in the past.  Since TeXmacs keeps the document in a
> tree form, it makes me ponder... what if an Axiom language, a descendant
> of Spad or Aldor, was written especially for the TeXmacs environment,
> utilizing a tree-form that encapsulates the semantics, not just the
> appearance as type-set, of an expression --- something like the two
> forms of MathML --- was created?  It could be semi-graphical, using an
> evolved mathematical notation[1] maybe with some lines and arrows...
> circles and arrows and an explanation on the back of each one.
> 

Also, look in the FAQ file for FAQ 19

\start
Date: Fri, 4 Nov 2005 08:33:08 -0500
From: Tim Daly
To: Karl Hegbloom
Subject: Re: Terms of Surrender (was: BAD tim)

> I think it would be really cool to port Axiom from 'noweb' to a TeXmacs
> based literate programming system of some kind.  There is at least one
> person on the TeXmacs users and/or development mailing list who has
> mentioned this idea in the past.  Since TeXmacs keeps the document in a
> tree form, it makes me ponder... what if an Axiom language, a descendant
> of Spad or Aldor, was written especially for the TeXmacs environment,
> utilizing a tree-form that encapsulates the semantics, not just the
> appearance as type-set, of an expression --- something like the two
> forms of MathML --- was created?  It could be semi-graphical, using an
> evolved mathematical notation[1] maybe with some lines and arrows...
> circles and arrows and an explanation on the back of each one.
> 

axiom's literate programming style follows Knuth's work on Tex in spirit.
we use Latex (he used Tex) and noweb (he used Web).

we only use two pieces of functionality in noweb so far, the chunking
mechanism which has two parts (definition and use)

   definiion        <<any string>>=
                       anything
                    @

   use              <<any string>>

and the quoting mechanism 

   quote            [[anything]]

there has been some discussion about rewriting noweb in lisp but
the pushback is that more features will be used in the future.

in addition axiom has a "booklet" function (written by David Mentre)
which lives on top of noweb. the noweb chunking mechanism allows
any string in the chunk name.

the booklet idea is to define a URL-like syntax for chunknames that
we can use for breaking documents into parts. currently we support
the "file" protocol so you can say:


   file include      <<file:path-to-file>>=
                     @

and the file will be included inline. 

in addition, bill page has made it possible to edit pamphlet files
online at the axiom wiki site. this could greatly simplify the whole
system maintenance problem, make it possible to "drag and drop" a
changed file from the website to your running axiom, have it rebuilt,
and added to the system. this could eliminate the CVS/Arch/Darcs
mechanism from the user level and create a whole new way of doing
system patch distribution.

changing axiom's hundreds of files to texmac's non-latex form seems
unlikely for several reasons. latex is a standard that everyone uses.
moving away from it seems counter-intuitive.

\start
Date: Fri, 4 Nov 2005 09:31:57 -0500
From: Bill Page
To: Gernot Hueber
Subject: RE: axiom/aldor build error on FreeBSD5.4

On November 4, 2005 2:51 AM Gernot Hueber writes:
> 
> I want to build axiom--main--45 with native FreeBSD ports gcl 
> (=2.6.6), following the instructions on
> http://wiki.axiom-developer.org/AldorForAxiom
> 
> Axiom builds fine (with some minor "hacks"),

I thought axiom--main--1--patch-45 used gcl-2.6.7 or are you
building using a modified make script? The last time I built
the Aldor extension on Axiom I was using patch-44. I think Tim
actually included some of the Aldor patches directly into
patch-45 (but not the full build of the Aldor extension). So
building with patch-45 and later will require some changes to
the Aldor patch files, I think.

We are now at patch-46. When I get a chance, I will try the build
of the Aldor extension myself with patch-46 and post any changes
to the instructions I find necessary. But I am building on Fedora
Core 3 and RedHat 9 so these still might not be entirely relevant
to you.

When you get a chance it would be great if you could make note
of the "hacks" that you required in order to build Axiom.

Also, I think it would be very useful if someone could produce
a binary tarball (or whatever packaging is standard on FreeBSD)
of Axiom and upload it to the web site.

> as well aldor tests build and run properly, but building the
> src/aldor part fails with
> [...]
> %/axextend.as, 
> /home/hueber/src/axiom--main--1--patch-45/src/aldor/as/axexten
> d.as /home/hueber/src/axiom--main--1--patch-45/int/aldor/ap/.dir
> "/home/hueber/src/axiom--main--1--patch-45/src/aldor/as/axextend.as",
> line 382:
>                 macro  Rep == Ptr$Machine;
> .................................^
> [L382 C34] #1 (Warning) Definition of macro `Rep' hides an outer
> definition.
>

I do not recall ever seeing this warning from Aldor. Which version
of Aldor are you using? On the axiom-developer.org server the Aldor
extension for Axiom was built using:

  $ aldor -version
  Aldor version 1.0.2 for LINUX(glibc2.3)

> Creating dependencies for ax0 C: 2
> gmake[1]:
> [/home/hueber/src/axiom--main--1--patch-45/int/aldor/dep_ax0.stamp]
> Error 255 (ignored)
> cat: 
> /home/hueber/src/axiom--main--1--patch-45/int/aldor/gendeps/ax
> lit.dep: No such file or directory
> ** Build failed
> for /home/hueber/src/axiom--main--1--patch-45/int/aldor/deps/axlit.dep
> [...]

This error looks similar to what I saw when I was using the
wrong version of make. What version are you using? As noted
in the instructions on MathAction, the build assumes

  $ make --version
  GNU Make 3.80

I might as well ask you also: What version of Java you are
using?

> ... 
> Can anybody explain/solve this error?
> 

I don't have access to a FreeBSD system so I can't be too
specific, but I would be glad to try to help.

\start
Date: Fri, 4 Nov 2005 09:25:17 -0800 (PST)
From: Cliff Yapp
To: Martin Rubey
Subject: Re: StepThrough

--- Martin Rubey wrote:

> Dear Bill, Cliff,
> 
> Clifford, are you still there? I'm not quite sure about your status
> now, are you interested in pursuing this project?

I am, but probably not immediately - I'm working again on the units
package concepts so that will take some time.  My current thought is:

1)  Finish the draft of the "paper/documentation" part of the units and
dimensions package, so first Dr. Sit (if he has time) and then the
general audience can judge the summary of the issues and features in
question.  I am making progress on this but some of the papers I need
to review are taking time to digest.  

2)  While demolition of 1) is proceeding, I'll dive into the
StepThrough issue, which will also be the time when I will really have
to come to grips with the design and SPAD programming language of
Axiom.  StepThrough is an excellent start because it should be
informative, useful, but still relatively elementary (famous last
words).  I think it's the usual thing - driving isn't so bad once you
know how to drive, and in Axiom's case I need to learn how to drive.

3)  If by some chance any significant part of the units draft survives
review the process of 1), I'll proceed to implement the actual SPAD (or
maybe Aldor depending on the prospects of being able to use it in
Axiom) required to bring it into being.  2) will hopefully supply me
with the Axiom specific tools and knowledge needed to do this
intelligently.

> Bill Page writes:
> 
> > > Float is -- although obviously different from the reals 
> > > -- a *model* for them. So it would *not* have COUNTABLE.
> > 
> > I am not exactly sure what you mean by *model* in this case but I
> do not
> > think Float is any more of a model for reals than is Fraction
> Integer. 
> > It is no more difficult to define 'nextItem' in Float than it is in
> Fraction
> > Integer. Instead of 'numer' and 'denom' we have 'mantissa' and
> 'exponent'.
> 
> OK, I surrender.

So we're agreeing nextItem makes sense in Float?

> > On the other hand there is some very important work on "Exact Real
> Numbers"
> > and "Computable Numbers". See:
> > 
> > http://wiki.axiom-developer.org/RealNumbers
> > 
> > which in my opinion might well be said to be models for the reals.
> Although
> > these numbers are "computable" it seems to me that it might be
> rather hard to
> > construct a useful total ordering and to compute something like
> 'nextItem'.
> 
> Since the set of computable numbers is countable and we can clearly
> only define domains containing computable numbers in Axiom, all 
> domains would have COUNTABLE. Of course for some domains it will be
> more difficult to come up with an enumeration than for others.

Indeed.
 
> I had the feeling that FLOAT and EXPR INT were domains which should
> not be countable, but it seems that this feeling should not be 
> trusted.

I suppose in once sense any mathematics stored as digital information
is somehow countable, although that counting might in some cases have
little to do with the conceptual uses to which the tools are put.
 
> In any case, it does make sense to sharpen the meaning of
> StepThrough.

Agreed.

[snip]

> It is not difficult to extend my code to "finite fraction objects".
> In fact, I coded it that way first, until I discovered that the 
> parameter domain is not allowed to be finite.
> 
> Thus, it might be better to implement nextItem in the domain
> Localize.

Heh - I'm reminded again of Tim's mantra - "there's no such thing as a
simple problem" :-).

\start
Date: Fri, 4 Nov 2005 12:55:27 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: page.axiom-developer problem / FrontPage

Martin,

On November 4, 2005 7:01 AM you wrote:
>
> it seems that there is a small problem with
>
> http://page.axiom-developer.org/zope/mathaction/FrontPage
>
> If I click on "Axiom book" I get the link
>
> http://page.axiom-developer.org/Mirrors?go=/public/book2.pdf&it=Axiom+Book
>
> which does not work.
> ...

Thanks. It should be ok now. Please let me know if not.

>
> I suppose that usage of page.axiom-developer.org/zope/mathaction
> is depreciated, but there are probably still many many links to
> that address out there...
>

Yes, you are right. At some point, we should start echoing a
"Please change your bookmark" for this url but for now I will
try to keep it working while we make sure that the shorter
aliases:

http://wiki.axiom-developer.org

and

http://portal.axiom-developer.org

are working properly.

There is also some awkwardness about the shortest possible
url:

http://axiom-developer.org

which is mapped automatically by the ISP name server to

http://www.axiom-developer.org

I made www.axiom-developer.org and alias for

http://page.axiom-developer.org/zope/mathaction

But I am not sure whether there is any point in retaining
these longer urls:

  http://www.axiom-developer.org/zope/mathaction

and

  http://www.axiom-developer.org/zope/Plone

anymore.

I know all these names for the same things is rather confusing
and it's hard to maintain so they all work properly.

> -----------------
>
> FrontPage design
>
> I'm a little unhappy about the crowdy look of the FrontPage.
> I suggest that we concentrate on the essentials. I think
> that:
> ...
> -----------------
>
> If there is agreement, I can redo the FrontPage.
>

I agree with all your suggested changes and encourage you to
do the re-design.

> There are some more things that should be redesigned:
>
> The WishList and SummerOfCode pages should be merged and
> redone. I think that several projects are already completed.
> It would be good if every project on this common page would
> have a link and a backlink to IssueTracker.

Do you think the current set of IssueTracker categories, severity
and status properties is adequate for this purpose? If not, then
then also can be extended and/or rationalized.

>
> The bits and pieces of wiki-documentation to interpreter,
> SPAD and Aldor should be regrouped.
>
> Volunteers?
>

I think this is a great idea!

\start
Date: Fri, 4 Nov 2005 19:01:40 +0100 (CET)
From: Bertfried Fauser
To: Cliff Yapp
Subject: Re: StepThrough

On Fri, 4 Nov 2005, C Y wrote:

Hi,

> > > I am not exactly sure what you mean by *model* in this case but I
> > do not
> > > think Float is any more of a model for reals than is Fraction
> > Integer.
> > > It is no more difficult to define 'nextItem' in Float than it is in
> > Fraction
> > > Integer. Instead of 'numer' and 'denom' we have 'mantissa' and
> > 'exponent'.
> >
> > OK, I surrender.
>
> So we're agreeing nextItem makes sense in Float?

NO! IFF float is a model for 'floats' then such a domain/category should
NOT have an attribute COUNTABLE, otherwise it may run into logical
inconsistencies.

I promote this opinion even if I know that an actual digital computer has
only a finite (not even countable!) number of such objects available at a
moment, but one can choose at random from an uncountable resource and a
successor function (NextItem) does not make sense.

I am not even sure if I appreciate that one has a 'standatrd?' nextItem in
the rationals. It is quite not clear, what a unique (canonical) order of
teh rationals is. Stepping through a finite or countable set means to
implement a total order starting with the smales element init() and ending
with the greatest (if finite). (Streams are infinite such things and I do
not really see why one should not even have a sort of 'stream' object if a
category has countable, something like nextItem() is nothing but a stream
(isn't it?) However a set may have many total orderings which can be
different, hence its not canonical.

Eg what are the nextItems of partitons, compositions, etc. This is a
concept which depends on an order. So first we would need to introduce an
(total) order then there is a canonical nextItem.

Partitions can be partially ordered, so that you do not find a unique
sucessor,...

Moreover, stepping through a set might need other (efficiency, logical)
structures, you might have a look at Don Knuth prefascicles of his TAOCP
http://www-cs-faculty.stanford.edu/~knuth/taocp.html where eg codes are
discussed so that you step through binary strings and in each step exactly
one bit changes and other such options. Any such option needs a futher
nextItem()

> > Since the set of computable numbers is countable and we can clearly
> > only define domains containing computable numbers in Axiom, all
> > domains would have COUNTABLE. Of course for some domains it will be
> > more difficult to come up with an enumeration than for others.
>
> Indeed.

You can algebraically define %pi and %e, of course you cannot give a
digital or decimal presentations, but would that be desirable? %pi is fine
for me ;-)

Anyway, this mail shall not prevent you from starting doing something with
nextStep...

\start
Date: Fri, 4 Nov 2005 14:31:50 -0500
From: Bill Page
To: Bertfried Fauser
Subject: RE: StepThrough

On November 4, 2005 1:02 PM Bertfried Fauser wrote:
> 
> Bill Page wrote: 
> > I am not exactly sure what you mean by *model* in this case
> > but I do not think Float is any more of a model for reals than
> > is Fraction Integer. It is no more difficult to define 'nextItem'
> > in Float than it is in Fraction Integer. Instead of 'numer' and
> > 'denom' we have 'mantissa' and 'exponent'.
>
> Martin Rubey wrote:
> > OK, I surrender.

> On Fri, 4 Nov 2005, C Y wrote:
> > So we're agreeing nextItem makes sense in Float?
> 
> NO! IF float is a model for 'floats' then such a domain/category
> should NOT have an attribute COUNTABLE, otherwise it may run into
> logical inconsistencies.

What inconsistencies?

> 
> I promote this opinion even if I know that an actual digital 
> computer has only a finite (not even countable!) number of such
> objects available at a moment, but one can choose at random from
> an uncountable resource and a successor function (NextItem) does
> not make sense.

But Bertfried, we are talking about exact symbolic mathematics
here.  'Float' is not a correct model for the real numbers. That
is a common mistake that is promoted by the "numericists" (people
who like to do numerical calculations). The domain 'Float' is
countable because it is determined completely by exactly two
Integers just in the same way that Fraction Integer is countable.

> 
> I am not even sure if I appreciate that one has a 'standard?'
> nextItem in the rationals. It is quite not clear, what a unique 
> (canonical) order of the rationals is.

It isn't necessary that this ordering be unique.

> Stepping through a finite or countable set means to implement a
> total order starting with the smallest element init() and ending
> with the greatest (if finite).

But this total order need not be their order in a numerical
sense. I believe that is what Martin might have meant by
reference to the "gray code"

http://en.wikipedia.org/wiki/Gray_code

I know this sort of ordering is related to "z-ordering" in the
context of database theory. It also comes under the names of
"linear clustering" and space-filling curves (e.g. Hilbert curve).
See for example:

http://citeseer.ist.psu.edu/lawder01querying.html

> (Streams are infinite such things and I do not really see why one
> should not even have a sort of 'stream' object if a category has
> countable, something like nextItem() is nothing but a stream
> (isn't it?)

Yes.

> However a set may have many total orderings which can be
> different, hence its not canonical.
>

I agree.
 
> Eg what are the nextItems of partitions, compositions, etc. This
> is a concept which depends on an order. So first we would need to 
> introduce an (total) order then there is a canonical nextItem.
> 
> Partitions can be partially ordered, so that you do not find a
> unique successor,...

I think that 'nextItem' can be defined in a partial order but
not a unique 'previousItem' (or vice versa).

> 
> Moreover, stepping through a set might need other (efficiency,
> logical) structures, you might have a look at Don Knuth prefascicles 
> of his TAOCP
> http://www-cs-faculty.stanford.edu/~knuth/taocp.html where eg 
> codes are discussed so that you step through binary strings and in
> each step exactly one bit changes and other such options. Any such
> option needs a further nextItem()

Yes, these are gray codes or something like them.

> 
> > > Since the set of computable numbers is countable and we 
> > > can clearly only define domains containing computable numbers
> > > in Axiom, all domains would have COUNTABLE. Of course for some
> > > domains it will be more difficult to come up with an enumeration
> > > than for others.
> >
> > Indeed.
> 
> You can algebraically define %pi and %e, of course you cannot
> give a digital or decimal presentations, but would that be
> desirable? %pi is fine for me ;-)

This is not a matter of algebraic definition. Yes you can give
a digital representation. The thing is, it is just not finite.
The essence of the idea of exact real numbers is that it is
possible to finitely encode an algorithm which will compute
%pi (or any other "computable" real number) as an infinite stream
of digits. In any given computation though one does need the
entire infinite stream. Still one can treat the algorithm itself
as the representation of such a number.

This has been studied in some detail and there are some proposed
efficient implementations. Please see the "Some History" section
of:

http://wiki.axiom-developer.org/RealNumbers

\start
Date: Fri, 4 Nov 2005 14:44:31 -0500
From: Bill Page
To: Bertfried Fauser
Subject: RE: StepThrough

On November 4, 2005 2:32 PM I wrote:
> > 
> > You can algebraically define %pi and %e, of course you cannot
> > give a digital or decimal presentations, but would that be
> > desirable? %pi is fine for me ;-)
> 
> This is not a matter of algebraic definition. Yes you can give
> a digital representation. The thing is, it is just not finite.
> The essence of the idea of exact real numbers is that it is
> possible to finitely encode an algorithm which will compute
> %pi (or any other "computable" real number) as an infinite stream
> of digits. In any given computation though one does need the
> entire infinite stream. Still one can treat the algorithm itself
> as the representation of such a number.
>

I meant to write: "In any given computation though one does *not*
need the entire infinite stream."

 
> This has been studied in some detail and there are some proposed
> efficient implementations. Please see the "Some History" section
> of:
> 
> http://wiki.axiom-developer.org/RealNumbers
> 

\start
Date: Fri, 4 Nov 2005 18:39:12 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: StepThrough

> 2)  While demolition of 1) is proceeding, I'll dive into the
> StepThrough issue, which will also be the time when I will really have
> to come to grips with the design and SPAD programming language of
> Axiom.  StepThrough is an excellent start because it should be
> informative, useful, but still relatively elementary (famous last
> words).  I think it's the usual thing - driving isn't so bad once you
> know how to drive, and in Axiom's case I need to learn how to drive.
> 

write down what you learn as you go in a tutorial form and we can
add it as a section to volume 2, programming. it is always helpful
to get a first-time user's view.

\start
Date: Sat, 05 Nov 2005 05:08:39 -0500
From: William Sit
To: Cliff Yapp
Subject: Re: Units Package

On Wed, 2 Nov 2005 06:59:28 -0800 (PST) C Y wrote (Re: StepThrough)
> > > Well, once I get the units package figured out (if I ever do...
> > > grumble...)

> --- Martin Rubey wrote: 
> > you reallly should.
> 
> I intend to.  I'm still reading papers and looking over other systems
> out there - I'm going to try my best to do this right.  Hopefully in
> another week or so I'll have something I can send Dr. Sit without
> feeling like I'd be wasting his time.

I learn a lot from the discussion with you (even though most of the ideas are
"reinventing the wheel", there is always a positive side to "reinventing" as
compared to just "reimplementing"). So independent of what you want to do with
the units project, you did not waste anyone's (certainly not my) time. 


On Fri, 4 Nov 2005 09:25:17 -0800 (PST) C Y wrote (Re: StepThrough)
> --- Martin Rubey wrote:
> 
> > Dear Bill, Cliff,
> >
> > Clifford, are you still there? I'm not quite sure about your status
> > now, are you interested in pursuing this project?
> 
> I am, but probably not immediately - I'm working again on the units
> package concepts so that will take some time.  My current thought is:
> 
> 1)  Finish the draft of the "paper/documentation" part of the units and
> dimensions package, so first Dr. Sit (if he has time) and then the
> general audience can judge the summary of the issues and features in
> question.  I am making progress on this but some of the papers I need
> to review are taking time to digest.

I'm glad you are making progress, and I'll find time :-). But perhaps you can
simply post the draft for everyone to comment on.  It would be best when
everything we say is in the open because we'll receive more constructive
comments from others as well.

> 2)  While demolition of 1) is proceeding, I'll dive into the
> StepThrough issue, which will also be the time when I will really have
> to come to grips with the design and SPAD programming language of
> Axiom.  StepThrough is an excellent start because it should be
> informative, useful, but still relatively elementary (famous last
> words).  I think it's the usual thing - driving isn't so bad once you
> know how to drive, and in Axiom's case I need to learn how to drive.

Contrary to what Martin suggests, I think it is a bad idea for you to work on
two projects simultaneously. StepThrough is not a simple issue (I'll comment on
this if I can keep up with all the discussions). The coding for UnitsPackage is
not as difficult as you think, but you should actually take Bill Page's advice
and simply dive in to get a feel for coding in Axiom (Spad). During all the
rewriting (you sure will be doing that), you'll learn to become fluent in Spad
(the compiler version). If you need help, lots of people on this board will lend
you a hand.

On Fri, 4 Nov 2005 18:39:12 -0500, Tim Daly wrote (Re:StepThrough):

> > write down what you learn as you go in a tutorial form and we can
> > add it as a section to volume 2, programming. it is always helpful
> > to get a first-time user's view.

I agree with Tim. So indeed, if this is to become a tutorial for first-time
user, who best qualifies than a first-time user recording all the steps for a
non-trivial project? Keep record of each trial, analyse each compiler error and
note down how it is resolved. You will find that you have lots of ideas of how
the compiler can be improved, and these suggestions will be valuable down the
road when documentation for the compiler gets to a stage the developers can fix
and modify it. If the whole thing becomes really long, we can devote a whole
volume to it. 

> 3)  If by some chance any significant part of the units draft survives
> review the process of 1), I'll proceed to implement the actual SPAD (or
> maybe Aldor depending on the prospects of being able to use it in
> Axiom) required to bring it into being.  2) will hopefully supply me
> with the Axiom specific tools and knowledge needed to do this
> intelligently.

There is no immediate need to "come to grips with the design and SPAD
programming language of Axiom". When I first began coding in Axiom (the project
was to compute first integrals of dynamical systems, which was completed in less
than a year in 1988, but unfortunately the only surviving code is a piece of it
for parametric linear equations PLEQN -- I had the rest of the code, but they
were broken by changes in Spad; throughout the years, I had only time to keep
PLEQN running as I moved onto other Spad projects), I knew nothing about the
design philosophy of Spad, nothing of Boot or Lisp, didn't know how to use Boot
to debug erroneous code. There was no documentation (the book was out only in
1992). I did have help from the original developers and I had to learn Groebner
basis along the way. So all it really took was some guts to go ahead. The less
you know where the difficulties may lie, the better!

As to pamphlet writing, I suggest you keep good notes first, concentrate on the
coding and testing. When the code is kind of at a convenient break (say you have
done a test version based on a small database of the SI system), get back to
document this. Then move on to the next stage. If you start writing
documentation of the code before you code, you may have to revise that a lot
more often. Documentation of the design for a first implementation is another
matter and you are right to do that carefully, before coding.

Just another two cents.

\start
Date: Sat, 05 Nov 2005 05:31:13 -0500
From: William Sit
To: Bill Page
Subject: Re: Live Pamphlet Editing

On  Fri, 4 Nov 2005 08:33:08 -0500 Tim Daly wrote (Re:Terms of Surrender (was:
BAD tim))

> in addition, bill page has made it possible to edit pamphlet files
> online at the axiom wiki site. this could greatly simplify the whole
> system maintenance problem, make it possible to "drag and drop" a
> changed file from the website to your running axiom, have it rebuilt,
> and added to the system. this could eliminate the CVS/Arch/Darcs
> mechanism from the user level and create a whole new way of doing
> system patch distribution.

Bill, sorry if I missed the message(s) where you might have described this. Is
there an easy way to directly add documentation to an existing pamphlet file
(like a patch) and the change be automatically visible to the discussion forum
(such as reflecting the change on wiki). If possible, then when some Axiom
problem involving the algebra code are discussed, whoever examined and
understood the code can add comments directly. Right now, we create and edit a
wiki page (possibly from emails), and then later this has to be searched and put
into the pamphlet file.

I noted the following Wiki page on MathAction:
http://page.axiom-developer.org/zope/mathaction/210PamphletSupportOnMathAction

You mentioned a new pamphlet PageType (pun intended :-) ?), but the links
http://page.axiom-developer.org/zope/mathaction/SandBoxEmbededPDF
(which is apparently a copy of the now defunct page:
http://page.axiom-developer.org/zope/mathaction/SandBoxPamphlet
where the links (pdf, dvi or src) are broken)
only give the pdf, dvi, and src files of dhmatrix.spad.pamphlet. There are no
instructions how to modify the src file (of course right now just the SandBox
copy, not the original archive copy) and have the modified file recompiled into
pdf, dvi, src files.

By the way, I have no trouble, under Windows and Firefox, to open the three
(pdf, dvi, src) files. The rendering seems ok to me.

\start
Date: Sat, 05 Nov 2005 08:53:30 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#228 pamphlets only work on wiki.axiom-developer.org] (new) 

There is a bug in the way that MathAction generates the path
to the output files when LaTeX, DVIPDF and DVIPNG are run during 'Save'. Right now only short urls that begin with

http://wiki.axiom-develop.org

for example

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/AcplotSpad

work properly. In that case the physical path to the files is::

  .../var/LatexWiki/axiom--test--1/src/algebra/

where the initial part of the path is system dependent.

If the url contains '/zope/mathaction/...' then the path is
not correct.

Also, at the present time 'pamphlet' format files will not
on the Axiom portal

http://portal.axiom-developer.org

because of a missing definition for the local file root for
the path.

I am actively working on correcting this problems.

\start
Date: Sat, 05 Nov 2005 09:21:08 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] revised design for pamphlet support

Revised Design: Thumbnail first page

  See http://wiki.axiom-developer.org/SandBoxPamphlet

Because of problems with display of embedded PDF files (see
section below plus attached comments), it was decided to
replace the embedded PDF with an PNG image of the first page
(usually the title page) of the pamphlet file. This image file
is considerably smaller than the full PDF file and can be
displayed in all browsers regardless of whether an PDF viewer
plug-in is available. But since this is only an image of the
first page, we should think of this as a "thumbnail", i.e.
just a reminder of what the actual document looks like.

To access the real document, the user must click on **pdf** or
**dvi**. If a viewer for either pdf or dvi format is available
the browser will normally launch the viewer. If not, then the
browser will offer to save the file to disk.

The **src** link will display the actual source of the pamphlet
file. This can be saved to disk (using 'right-click/Save As' or
other appropriate browser idiom) for local use with an Axiom
source distribution.

The **tex** link displays the output of the literate program
'weave' operation applied to the source file. This is pure
LaTeX code and can be saved and subsequently processed by
LaTeX if desired.

The **log** link displays the log file generated by LaTeX. If
the document thumbnail does not appear after clicking 'Save'
you should check this file for error messages and make
corrections to the pamphlet file as necessary.

The **tangle** button and the associated drop down box are used
to access the program code contained in the literate progam
document. Select a code chunk name from the drop down box and
then click **tangle** to run the literate program 'tangle'
operation on the source file. The resulting code will be
displayed in the browser and can be saved to disk and used
locally if desired.

To edit pamphlet files, just click **edit** (located on the
upper right of the page) as you would for any other page
on MathAction.

Original Design: Embedded PDF

\start
Date: Sat, 5 Nov 2005 10:50:26 -0500
From: Bill Page
To: William Sit
Subject: RE: Live Pamphlet Editing


On November 5, 2005 5:31 AM William Sit wrote:
> On  Fri, 4 Nov 2005 08:33:08 -0500 Tim Daly wrote:
>
> > in addition, bill page has made it possible to edit pamphlet
> > files online at the axiom wiki site. this could greatly
> > simplify the whole system maintenance problem, make it
> > possible to "drag and drop" a changed file from the website
> > to your running axiom, have it rebuilt, and added to the
> > system. this could eliminate the CVS/Arch/Darcs mechanism
> > from the user level and create a whole new way of doing
> > system patch distribution.
>
> Bill, sorry if I missed the message(s) where you might have
> described this.

No problem. I have just updated the IssueTracker page

http://wiki.axiom-developer.org/210PamphletSupportOnMathAction

to better reflect what I have actually implemented so far.
Tim's description above still represents the vision towards
which this work is directed but not yet fully achieved. Still
in it's current state I think it is quite usable. The following
groups of pamphlet files are currently available on MathAction:

http://wiki.axiom-developer.org/axiom--test--1

- a copy of all the pamphlet files from the Axiom source archive
  'axiom--main--1--patch-45'

http://wiki.axiom-developer.org/axiom--book--1

- the pamphlet files for the volumes of the new Axiom book

http://wiki.axiom-developer.org/axiom--GUI--1

- the pamphlet files from Kai Kaminski's AxiomUI project

> Is there an easy way to directly add documentation to an
> existing pamphlet file (like a patch) and the change be
> automatically visible to the discussion forum (such as
> reflecting the change on wiki).

Yes. Pamphlet files can be edited on-line or with an external
editor in exactly the same way as other pages on the wiki.

I have also thought about on-line support for the generation
and application of patch files. I think doing this would not
be difficult but after working with these pamphlet files now
for a while, I (personally) think that this older form of
interaction with source files may not be so relevant in this
new on-line environment. In any case it is still possible to
download the pamphlet source files and use such methods locally
on your own workstation and then upload the result to the wiki.

> If possible, then when some Axiom problem involving the algebra
> code are discussed, whoever examined and understood the code
> can add comments directly.

Yes, that's it exactly. That is possible right now. Please
visit the links I gave above to see how this might work.

> Right now, we create and edit a wiki page (possibly from
> emails), and then later this has to be searched and put
> into the pamphlet file.

Now it can be done directly.

>
> I noted the following Wiki page on MathAction:
>
http://page.axiom-developer.org/zope/mathaction/210PamphletSupportOnMathActi
on
> You mentioned a new pamphlet PageType (pun intended :-) ?), but
> the links
http://page.axiom-developer.org/zope/mathaction/SandBoxEmbededPDF
> (which is apparently a copy of the now defunct page:
http://page.axiom-developer.org/zope/mathaction/SandBoxPamphlet
> where the links (pdf, dvi or src) are broken only give the pdf,
> dvi, and src files of dhmatrix.spad.pamphlet.

For reasons I have posted to IssueTracker as #228, you should
use shorter url:

http://wiki.axiom-developer.org/210PamphletSupportOnMathAction
http://wiki.axiom-developer.org/SandBoxEmbededPDF
http://wiki.axiom-developer.org/SandBoxPamphlet

'SandBoxEmbededPDF' is an example of the original proposed design.
After some consideration (described in the comments attached
to #210) I abandoned the idea of using embedded PDF. The page
'SandBoxPamphlet' is an example of the revised design.

> There are no instructions how to modify the src file (of course
> right now just the SandBox copy, not the original archive copy)
> and have the modified file recompiled into pdf, dvi, src files.

I have just updated the IssueTracker page #210 to better reflect
the current design. Hopefully the new documentation here will be
enough to get you started.

> By the way, I have no trouble, under Windows and FireFox, to
> open the three (pdf, dvi, src) files. The rendering seems ok
> to me.

The problems had to do with the display of PDF files embedded
in an HTML page. For certain combinations of Adobe Acrobat
Reader 7 and FireFox browser version 1.0.x on Windows and some
other browsers on Linux this combination did not work at all
due to a bug in either Acrobat or FireFox or both. In the most
recent versions of FireFox and Acrobat this combination now
works properly on Windows (I haven't tested the newer versions
on Linux yet). But I have opted for the new design that displays
a graphic "thumbnail" first page instead of the embedded PDF
because this should work on virtually all browsers in use on
the web regardless of how they are configured.

If you have any questions, please ask. And if you or anyone
else feel inclined to write some documentation about this from
a "new users' perspective" :) please feel free to add it
somewhere on MathAction.

\start
Date: Sat, 5 Nov 2005 10:59:34 -0500
From: Bill Page
To: William Sit
Subject: RE: Live Pamphlet Editing

On November 5, 2005 10:50 AM I wrote:
>...
> The following groups of pamphlet files are currently available
> on MathAction:
> 
> http://wiki.axiom-developer.org/axiom--test--1
> 
> - a copy of all the pamphlet files from the Axiom source archive
>   'axiom--main--1--patch-45'
> 
> http://wiki.axiom-developer.org/axiom--book--1 [sic]
> 
> - the pamphlet files for the volumes of the new Axiom book

I am sorry the url above was wrong. The correct url for the
new Axiom book is:

http://wiki.axiom-developer.org/book--main--1

> 
> http://wiki.axiom-developer.org/axiom--GUI--1
> 
> - the pamphlet files from Kai Kaminski's AxiomUI project
>

\start
Date: Sat, 5 Nov 2005 11:51:30 -0500
From: Bill Page
To: Cliff Yapp, William Sit
Subject: Re: StepThrough (was: Units package)

On November 5, 2005 5:09 AM William Sit wrote:
> ...
> On Fri, 4 Nov 2005 09:25:17 -0800 (PST) C Y wrote (Re: StepThrough)
> > --- Martin Rubey wrote:
> >
> > > Dear Bill, Cliff,
> > >
> > > Clifford, are you still there? I'm not quite sure about
> > > your status now, are you interested in pursuing this project?
> >
> > I am, but probably not immediately - I'm working again on the
> > units package concepts so that will take some time.  My current
> > thought is:
> >
> > 1)  Finish the draft of the "paper/documentation" part of
> > the units and dimensions package,
> > ...
> > 2)  While demolition of 1) is proceeding, I'll dive into the
> > StepThrough issue, which will also be the time when I will
> > really have to come to grips with the design and SPAD
> > programming language of Axiom.  StepThrough is an excellent
> > start because it should be informative, useful, but still
> > relatively elementary (famous last words).  I think it's the
> > usual thing - driving isn't so bad once you know how to drive,
> > and in Axiom's case I need to learn how to drive.
>
> Contrary to what Martin suggests, I think it is a bad idea
> for you to work on two projects simultaneously. StepThrough
> is not a simple issue (I'll comment on this if I can keep up
> with all the discussions).

I would not want to dissuade anyone from working on the issue
of StepThrough and Countable but I tend to agree with William
about this. In some cases, the concept of Countable is relatively
simple (as in the case of Fraction as Martin has shown) but in
other cases it could lead to some rather deep mathematical and
implementation issues. The implications of the category Countable
do seem to affect the Axiom library at a fairly basic level. Of
course these issues are what make the whole subject interesting
and worth pursuing but they may not be the ideal place to start
working with Axiom.

I look forward to reading your thoughts abut this William.

> The coding for UnitsPackage is not as difficult as you think,
> but you should actually take Bill Page's advice and simply
> dive in to get a feel for coding in Axiom (Spad). During all
> the rewriting (you sure will be doing that), you'll learn to
> become fluent in Spad (the compiler version). If you need
> help, lots of people on this board will lend you a hand.
>

We should remember that Martin has already contributed some
working Spad code for units. See:

http://wiki.axiom-developer.org/UnitsAndDimensions

Clifford, (as if you need any more advice ... :) I think a good
place to start would be to understand this code and modify it
(a little at a time) to implement some of the new ideas on units
that you have been thinking and writing about. If you would just
like to try a few things but not have your experiments broadcast
to the email list, you can work here:

http://wiki.axiom-developer.org/SandBoxUnitsAndDimensions

which contains a copy of Martin's original code.

All you have to do is click 'edit' and start making changes
to this code. Clicking 'Preview' allows you to test your
changes and 'Save' with save them for other people to see.
But here in SandBox pages, none of the changes you make
(even when you click 'Save') will result in emails to the
mailing list. So please feel free to treat it as if you
personally own this page.

\start
Date: Sat, 5 Nov 2005 18:15:39 +0100
From: Hans Peter Wuermli
To: Camm Maguire
Subject: Debian Axiom - Compile problem

Dear Camm

Using hypertext or trying to compile (and I guess other actions that use 
special executables) cause an error, typically of the type:

 >> System error:
   Cannot open the file /usr/lib/axiom-20050901/autoload/postprop.

Do I have to set some parameters someplace? Or compile axiom myself?

With best regards

\start
Date: Sat, 5 Nov 2005 14:07:52 -0500
From: Tim Daly
To: Hans Peter Wuermli
Subject: Re: Debian Axiom - Compile problem
Cc: Camm Maguire

it appears that your shell variable (AXIOM) is not set properly.
the autoload directory is found from this shell variable.

find your autoload subdirectory and you'll know how to set this variable.

suppose you are running in linux and find your autoload subdirectory at

/usr/lib/axiom-20050901/mnt/linux/autoload

then do

export AXIOM=/usr/lib/axiom-20050901/mnt/linux

and try running axiom again.


\start
Date: Sat, 5 Nov 2005 17:18:58 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: StepThrough

> write down what you learn as you go in a tutorial form and we can
> add it as a section to volume 2, programming. it is always helpful
> to get a first-time user's view.

Will do.  

\start
Date: 05 Nov 2005 21:17:39 -0500
From: Camm Maguire
To: Hans Peter Wuermli
Subject: Re: Debian Axiom - Compile problem

Greetings!  I see I have accidentally omitted postprop.lsp from the
axiom package, as I had assumed all the shiped files were compiled.
Am fixing this now in a -4 debian package upload.  It would be most
helpful if you could send me the exact description of what you are
doing to trigger any errors you see so that I can ensure they are gone
before uploading.

Thanks so much for the report!

Hans Peter W=FCrmli Hans Peter Wuermli writes:

> Dear Camm
>
> Using hypertext or trying to compile (and I guess other actions that use
> special executables) cause an error, typically of the type:
>
>  >> System error:
>    Cannot open the file /usr/lib/axiom-20050901/autoload/postprop.
>
> Do I have to set some parameters someplace? Or compile axiom myself?
>
> With best regards

\start
Date: 05 Nov 2005 21:20:00 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: Debian Axiom - Compile problem

Greetings!

Tim Daly writes:

> it appears that your shell variable (AXIOM) is not set properly.
> the autoload directory is found from this shell variable.
> 
> find your autoload subdirectory and you'll know how to set this variable.
> 
> suppose you are running in linux and find your autoload subdirectory at
> 
> /usr/lib/axiom-20050901/mnt/linux/autoload
> 
> then do
> 
> export AXIOM=/usr/lib/axiom-20050901/mnt/linux
> 
> and try running axiom again.
> 

Tim is right -- this setting is critical.  The Debian packages install
under /usr/lib/axiom-20050901 as the base and set the AXIOM variable
in the shell script wrapper /usr/bin/axiom.

\start
Date: Sat, 5 Nov 2005 18:33:36 -0800 (PST)
From: Cliff Yapp
To: William Sit
Subject: Re: Units Package

--- William Sit wrote:

> I learn a lot from the discussion with you (even though most of the
> ideas are "reinventing the wheel", there is always a positive side 
> to "reinventing" as compared to just "reimplementing"). 

I've always thought the best "reimplementers" are the ones who do
reinvent it because they tend to actually understand what they are
implementing, and it shows.

> So independent of what you want to do with
> the units project, you did not waste anyone's (certainly not my)
> time. 

Thanks!  I know it's been very educational for me, in fact in some ways
I wish I had done a lot of this before taking intro physics.

> On Fri, 4 Nov 2005 09:25:17 -0800 (PST) C Y wrote (Re: StepThrough)

> > 1)  Finish the draft of the "paper/documentation" part of the units
> > and dimensions package, so first Dr. Sit (if he has time) and then 
> > the general audience can judge the summary of the issues and 
> > features in question.  I am making progress on this but some of the
> > papers I need to review are taking time to digest.
> 
> I'm glad you are making progress, and I'll find time :-). But perhaps
> you can simply post the draft for everyone to comment on.  It would 
> be best when everything we say is in the open because we'll receive
> more constructive comments from others as well.

Sure, can do.  In fact, with the online pamphlet viewing now in place I
might actually be able to upload it for viewing that way.  (Of course
it's all LaTeX right now, but I don't think that will matter to the
system.)

> Contrary to what Martin suggests, I think it is a bad idea for you to
> work on two projects simultaneously. StepThrough is not a simple 
> issue (I'll comment on this if I can keep up with all the 
> discussions). 

Yes, I agree with you and Bill upon consideration.

> The coding for UnitsPackage is not as difficult as you think, 

<grin>  Glad to hear that :-).

> but you should actually take Bill Page's advice
> and simply dive in to get a feel for coding in Axiom (Spad). 

Sounds good.

> During all the rewriting (you sure will be doing that), you'll learn
> to become fluent in Spad (the compiler version). If you need help, 
> lots of people on this board will lend you a hand.

I really think the people on this list are one of the best assets Axiom
has.  So I'll take this chance to thank them collectively for helping
to make the Axiom experience so educational and exciting.

> On Fri, 4 Nov 2005 18:39:12 -0500, Tim Daly wrote (Re:StepThrough):
> 
> > > write down what you learn as you go in a tutorial form and we can
> > > add it as a section to volume 2, programming. it is always
> > > helpful to get a first-time user's view.
> 
> I agree with Tim. So indeed, if this is to become a tutorial for
> first-time user, who best qualifies than a first-time user recording
> all the steps for a non-trivial project? 

I'll do my best.

> Keep record of each trial, analyse each compiler error and
> note down how it is resolved. 

Time to dust off the old script command. :-)

> You will find that you have lots of ideas of how
> the compiler can be improved, and these suggestions will be valuable
> down the road when documentation for the compiler gets to a stage the
> developers can fix and modify it. If the whole thing becomes really 
> long, we can devote a whole volume to it. 

Hopefully we will be able to switch to Aldor to help with the compiler
situation, but that will probably be a while.

> There is no immediate need to "come to grips with the design and SPAD
> programming language of Axiom". When I first began coding in Axiom
> (the project was to compute first integrals of dynamical systems, 
> which was completed in less than a year in 1988, but unfortunately 
> the only surviving code is a piece of it for parametric linear 
> equations PLEQN -- I had the rest of the code, but they were broken 
> by changes in Spad; throughout the years, I had only time to keep
> PLEQN running as I moved onto other Spad projects),

Perhaps the rest could be retooled?  Or would that amount to a rewrite
in any case?

> I knew nothing
> about the design philosophy of Spad, nothing of Boot or Lisp, didn't
> know how to use Boot to debug erroneous code. There was no 
> documentation (the book was out only in 1992). I did have help from
> the original developers and I had to learn Groebner basis along the 
> way. So all it really took was some guts to go ahead. The less
> you know where the difficulties may lie, the better!

In that case I'm in good shape!  OK, here we go.

> As to pamphlet writing, I suggest you keep good notes first,
> concentrate on the coding and testing. When the code is kind of at a
> convenient break (say you have done a test version based on a small
> database of the SI system), get back to document this.

Heh - that's almost exactly the stage at which I stopped to try and
document the Maxima version.  

> Then move on to the next stage. If you start writing
> documentation of the code before you code, you may have to revise
> that a lot more often. Documentation of the design for a first
> implementation is another matter and you are right to do that 
> carefully, before coding.

Oh, I wasn't going to try to document code while still debugging,
except for recording the steps for the How to Start Writing in
Axiom/SPAD part.  
 
> Just another two cents.

I'd say it's worth a bit more than that!

\start
Date: Sat, 5 Nov 2005 19:08:33 -0800 (PST)
From: Cliff Yapp
To: Bill Page, William Sit
Subject: Re: StepThrough (was: Units package)

--- Bill Page wrote:

> I would not want to dissuade anyone from working on the issue
> of StepThrough and Countable but I tend to agree with William
> about this. In some cases, the concept of Countable is relatively
> simple (as in the case of Fraction as Martin has shown) but in
> other cases it could lead to some rather deep mathematical and
> implementation issues. 

That was the conclusion I was coming too from the discussions.

> The implications of the category Countable
> do seem to affect the Axiom library at a fairly basic level. Of
> course these issues are what make the whole subject interesting
> and worth pursuing but they may not be the ideal place to start
> working with Axiom.

Agreed.

> I look forward to reading your thoughts abut this William.
> 
> > The coding for UnitsPackage is not as difficult as you think,
> > but you should actually take Bill Page's advice and simply
> > dive in to get a feel for coding in Axiom (Spad). During all
> > the rewriting (you sure will be doing that), you'll learn to
> > become fluent in Spad (the compiler version). If you need
> > help, lots of people on this board will lend you a hand.
> >
> 
> We should remember that Martin has already contributed some
> working Spad code for units. See:
> 
> http://wiki.axiom-developer.org/UnitsAndDimensions
> 
> Clifford, (as if you need any more advice ... :) I think a good
> place to start would be to understand this code and modify it
> (a little at a time) to implement some of the new ideas on units
> that you have been thinking and writing about.

Most definitely :-).  Starting from square one was not what I had in
mind - I'm just waiting to look at that code until the desired design
is in hand.

> If you would just
> like to try a few things but not have your experiments broadcast
> to the email list, you can work here:
> 
> http://wiki.axiom-developer.org/SandBoxUnitsAndDimensions
> 
> which contains a copy of Martin's original code.

Excellent.

> All you have to do is click 'edit' and start making changes
> to this code. Clicking 'Preview' allows you to test your
> changes and 'Save' with save them for other people to see.
> But here in SandBox pages, none of the changes you make
> (even when you click 'Save') will result in emails to the
> mailing list. So please feel free to treat it as if you
> personally own this page.

Actually, since my home box is offline and will be for a while yet,
I'll probably have to do most of my initial tests offline.  That
reminds me - I (think I) remember a while back discussions as to
running the MathAction on individual machines - is that conceivable or
is it specific to the current server?  

\start
Date: Sat, 5 Nov 2005 22:38:31 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: StepThrough (was: Units package)

On November 5, 2005 10:09 PM C Y wrote:

> ...
> I (think I) remember a while back discussions as to running
> the MathAction on individual machines - is that conceivable
> or is it specific to the current server?
>

Yes, that is certainly conceivable. I run a version of MathAction
(not the most recent) locally on my Linux workstation. Configuring
MathAction is a little complex but Hans Peter W=FCrmli succeeded in
doing it on a Debian workstation as described here:

http://wiki.axiom-developer.org/InstallingMathAction

Some of these instructions and some of the source code in the
repository will need to be updated if you want to implement
support for the new pamphlet format.

If you are interested, I would be very pleased to help you set up
your machine with MathAction. That would give me the motivation
to update the instructions. :)

\start
Date: Sat, 05 Nov 2005 22:41:33 -0500
From: William Sit
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

Dear Bill:

I have been staying on the sideline (since I don't know much about
Boot or Lisp) on this "war", but I am more convinced by your arguments
than by Tim's or Morrison's, and I felt that I should be a late ally
before you surrender!

First about Boot. My (admittedly poor) understanding of Boot is that
it is an intermedate language between Lisp and Spad (and there are
other intermediate languages Shoe, Meta, etc as well). I agree that to
build a truely high level language like Spad/Axiom/Aldor, intermediate
languages are necessities and not evils. It's much like what a
mathematician does all the time (and most original developers are
mathematicians, in addition to being computer scientists): if the
proof of a theorem is too complicated, such as that for Fermat's Last
Theorem, you build up the proof in steps providing tools along the
way. Even for simpler results, there are usually lemmas, propositions,
new definitions to abbreviate frequently used concepts, new results
based on definitions, etc. before the final proof. A theorem proofer
is also built that way. No one wants to reduce every proof to its most
fundamental logic. Whitehead and Russell did that in 2000 pages of
Principia Mathematica, but how many people read it? Even there, they
"introduce a stratification of Frege's formulas into types, and to use
this to restrict which of Frege's formulas would be permitted in their
logic. The key idea was that a formula could not be substituted for a
variable x in a formula unless the variable x was of the appropriate
type." (Quoted from a brief synopsis in
http://www.math.uwaterloo.ca/~snburris/htdocs/WWW/PDF/principia.pdf)
That sounds much like using Boot to restrict which constructs of Lisp
would be permitted to support the strong typing in Axiom. (OK, I am
stretching the analogy, but the parallel is irresistable.)  The writer
of that quoted article also noted: "they quickly adopted the
convention of leaving out easy steps of proofs".

Second, I think once the bootstrap step is done, it is ok to write a
compiler for the language in the language itself. So writing a
compiler for C in C, a precompiler for C++ in C, one for Boot in Boot,
or for Axiom in Axiom is perfectly reasonable. The purist may want to
boil everything down to hand-crafted assembly (dare I say machine?)
language, but honestly, while there is a role to play when frequently
called routines need to be inlined for efficiency to use a lower level
language, the majority of the code can and should be replaced by as
high a level language as usable. Such a stratification allows easier
understanding of the entire build and is a compromise and probably an
optimized compromise, when we consider all factors about efficiencies
(including those of developers and users, not just code). In any case,
whether eventually the project decides to turn everything to Lisp or
to retain but streamlining the intermediate languages, the most
important step is documenting the code in these intermediate
languages. I believe when this is done, there will be no need to
reduce everything to Lisp; this does not mean there are no
opportunities to improve efficiency of code execution for some
frequently used Boot code by coding them in Lisp or even assembly
languange. Rather, these opportunities will be identified by the
documentation and code analysis phase (much like Knuth's MIX
assembler, which keeps count of the number of times any line of code
has been executed).

Third, as far as Axiom code is concerned, and here I may claim some
familiarity, there is almost no need for a user (mathematician or
scientist or student) of symbolic computation to know (1) the
architecture of the system (2) the various intermediate languages (3)
the algorithms behind the functions (4) the mechanics of user
interfaces, and more. All they need is a consistent syntax, well
documented, and a reliable answer returned each time. When a symbolic
computation system approaches the ease of use as a scientific
calculator, that's when it is most useful.

Fourth, for a developer of algebra code, it will help if (s)he
understands some basic design philosophy behind the language, but that
is not necessary. If the syntax and documentation are clear, and if
the developer knows the subject matter (mathematics, physics, etc) and
the algorithm, (s)he can pick up the Spad language easily.  History
supports this observation: many of the Axiom algebra packages beyond
the basic categories and polynomial algebra were developed by visitors
to IBM (I was a visitor in 1988, after I was introduced to Scratchpad
by another visitor, Fritz Schwarz, who co-developed with Bronstein the
LODOF pacakge). Quoting myself from another post: "When I first began
coding in Axiom (the project was to compute first integrals of
dynamical systems, which was completed in less than a year in 1988
[snipped] ... I knew nothing about the design philosophy of Spad,
nothing of Boot or Lisp, didn't know how to use Boot to debug
erroneous code. There was no documentation (the book was out only in
1992). I did have help from the original developers and I had to learn
Groebner basis along the way. So all it really took was some guts to
go ahead."  Even though the compiler often gave (and still does) poor
or meaningless error messages, it was always possible to find my own
mistakes by the logic of the program and a few print statements
inserted at strategic places. But these are just typical programming
skills.

Scott Morrison wrote:
> Being one of those 10 people, I have to agree with Tim and
> his opinion of the Boot language. Dick Jenks told me that
> boot was to be the first step in implementing the entire
> system in the Spad language. Once the syntax looked like
> Spad, the next step would be to convert it to real Spad.
> Of course that never happened, so the main purpose behind
> Boot is gone.

If Boot is really dispensable, then I think Boot code should be raised
to the level of Spad, not lowered to the level of Lisp. I just cannot
believe that rewriting Boot code in Lisp would be more readable than
Boot code in Spad. The only exceptions are frequently inlined code
should be optimized and there Lisp may be a good choice.

I like to point out that Aldor has at least one intermediate language
FOAM.  Probably the Aldor compiler compiles source to FOAM, which is
then compiled to C (correction requested since this is only a wild
guess). Can Boot be modified to be equivalent to FOAM in its role?
 
> In my opinion Boot can be a convenient language to code in,
> but it has two main problems. The use of indentation for
> grouping is just a bad idea. It works well for one-page
> programs, but with anything with reasonable complexity, it
> falls down.

I like the indentation (no pile) syntax and I agree that it took me a
while to get used to that and avoid the missing space errors. But I
think whether you use pile or no pile, it is only a matter of
habit. As Bill Page pointed out, missing a semicolon in other
languages (Maple, for example) is equally devastating. In fact I like
the indentation so much that when I program in Pascal and other
languages, I put all the "parenthesize annoyances to the end of the
line so as not to interfere with my visual cues of the hierarchy --
for example:

     if not fileopen then                       begin
        writeln(outfilename,'  not found!');
        writeln('hit any key to continue');
        repeat until keypressed                 end;

which also maximizes the number of lines that can fit in one page. If
I were forced to use no pile, I would place the braces similarly to
the begin/end pair.  I also agree with Bill that one should write a
routine that spans more than one page only if it is absolutely
impossible to break up the code into smaller chunks. Bill already
noted that "A lot of the Spad code in the Axiom library is less than
one page per package domain or category."


> the other "oh by the way" is that while you can seem to
> read boot code without knowing lisp (a sort-of pseudo
> code syntax) you can't WRITE boot code without knowing
> lisp.

Bill page responded:

> Why is that? Surely it is possible to write Spad code without
> knowing Lisp? That was the point of Spad, wasn't it? (Otherwise
> the mathematicians could have simply written in Lisp and this
> whole issue would be moot, right?) If Boot is a simplified
> form of Spad then why is knowing Lisp so relevant? And if by
> "knowing lisp" you mean knowing the concepts on which lisp is
> based, then I would be surprised to find many undergraduate
> computer science students who did not have at least one
> programming course which included at least an introduction
> to lisp. (Maybe my experience here is too out of date?)

I do not want to argue against Lisp (some would say Scheme is
better). But I agree with your implications from my own experience
that writing algebra code in Axiom requires absolutely no knowledge
(ok, some reading knowledge, but only because the compiler
occasionally includes Lisp in error messages -- I don't think anyone
would disagree that the compiler needs to improve its diagnostic
messages) of Lisp or Boot. Of course, knowing these helps if the
system (compiler or interpreter) ever is in error; but that is for
system people to know. The algebra developers would simply report the
bugs and meanwhile find a way around them -- that was what I did most
of the time because the system developers in those days were busy with
experimenting with many new ideas (in particular Aldor or A#) and they
said they would not fix those bugs or add some natural features. But
those days are over, I hope, with open source. If system developers
spend too much time on rewriting as a means to fix bugs, I believe the
bugs would not be fixed for a long time, and the new code will break
old code. Developing an algebra package is no trivial matter and it
would be quite a waste of resources to have to upgrade a package
because of backward incompatibility.  One should learn from the
longevities of Fortran and Cobol.

> ---------
> 
> Now about this language war ...
> [snipped] 
> So, *if* I was thinking of such a compromise then there are
> some "terms of surrender" that might make this easier:
> 
> 1) Before any more "lispifying" goes on, *first* move Axiom
>    over to ANSI lisp. This will make it possible to write lisp
>    that conforms to modern practices and as high level as
>    possible. It will also make Axiom less dependent on a
>    particular implementation of Lisp and more easily portable.
> 
> 2) No more just cutting and pasting the generated lisp output
>    of Boot into the literate document! This seems pointless
>    and a net loss in intelligibility even if it is accompanied
>    by a verbal explanation of the code. The original Boot code
>    is, as Tim admitted above, significantly more readable as
>    "pseudo-code" then what the compiler outputs.
> 
> 3) Where possible and practical, replace Boot code with Spad
>    code as in Dick Jenks original vision instead of Lisp. Surely
>    you are not going to argue that Spad is a "dead language"
>    written by fewer than 10 surviving programmers? And even if
>    that happens to be true ;), that is one thing that we are
>    trying hard to change, right?

These terms should not be negotiable! Actually, I would put these as
requests to whoever does the work) I would add at least

4) The error messages outputted by the compiler should NOT refer to
any Lisp.  Nothing like the current $m, $x, $f stuff. All errors
should refer as close to the offending source code as possible. (I
believe such output was due to "laziness" or viewing more intelligible
messages as an insult to the developers.  But that might be why Axiom
failed to capture market shares in the 1990's.)

5) The )trace function should likewise return high level state of the
algebra variables, not lisp code or representation of them.

6) The interpreted language should adhere to the compiler language to
facilitate prototyping (in the interpreter) and production code (using
the compiler) and any deviations (due to the smartness of the
interpreter) should be logged to help the transfer (maybe it is even
possible to translate a working interpreted set of routines
automatically into compilable code?).

\start
Date: Sun, 6 Nov 2005 00:21:07 -0500
From: Tim Daly
To: Bill Page
Subject: re: StepThrough (was: Units package)

perhaps the mathaction site could become a 
./configure ; make ; make install process?

\start
Date: Sun, 6 Nov 2005 01:54:34 -0500
From: Tim Daly
To: William Sit
Subject: Re: Terms of Surrender (was: BAD tim)

> First about Boot. My (admittedly poor) understanding of Boot is that
> it is an intermedate language between Lisp and Spad (and there are
> other intermediate languages Shoe, Meta, etc as well). I agree that
> to build a truely high level language like Spad/Axiom/Aldor,
> intermediate languages are necessities and not evils. It's much like
> what a mathematician does all the time (and most original developers
> are mathematicians, in addition to being computer scientists): if
> the

.....[snip].....

sorry, but you are reasoning by wrong analogy.

boot is not an intermediate step between lisp and spad. boot is a 
syntactic sugar coating on lisp that eliminates parentheses in favor
of "piling" (indenting) code. it adds no new functionality and does
not help you reason about programming any more than, say, python or perl.
in fact it limits the things you can write so you can't use the full
power of lisp.

boot does not function as a lemma-like level of reasoning.

> Second, I think once the bootstrap step is done, it is ok to write a compiler
> for the language in the language itself. So writing a compiler for C in C, a
> precompiler for C++ in C, one for Boot in Boot, or for Axiom in Axiom is
> perfectly reasonable. The purist may want to boil everything down to
> hand-crafted assembly (dare I say machine?) language, 

.....[snip].....

swing and a miss, as they say in baseball. 

the interpreter needs to be:
   simple to build, 
   simple to maintain, 
   simple to extend, 
   simple to port.

writing boot in boot forces the system build to be more complex. 

it forces the maintenance to be harder since you need to understand 
whether the problem is in the boot compiler or the interpreter. 

it forces the user to understand the interaction of lisp vs boot 
when extending the system since certain facilities have to be in 
lisp because boot is not yet available at that point in the build 
process (e.g. setvars)

it makes the system harder to port because we have to rewrite the
bootstrap lisp code from old common lisp to ansi common lisp to port it.
this makes the boot-level code out of date.

writing boot in boot is clever but it makes building, maintaining, 
extending, and porting axiom harder than it has to be.

yes, this can be fixed but fixing it means that you have to
  (1) rewrite the boot compiler changes in boot
  (2) recompile the boot compiler to clisp
  (3) clip out the changes from the clisp file
  (4) insert the changes into the bootstrap sections of the boot compiler
  (5) rebuild the system

writing boot in boot is clever.
we don't need clever code.

boot is NOT a higher level language than lisp. spad is.
boot is NOT spad and is unrelated to spad.
boot is ONLY seen by interpreter/compiler developers.
boot is used by 1 developer (me) until the documentation completes.



> > the other "oh by the way" is that while you can seem to
> > read boot code without knowing lisp (a sort-of pseudo
> > code syntax) you can't WRITE boot code without knowing
> > lisp.
> 
> Bill page responded:
> 
> > Why is that? Surely it is possible to write Spad code without
> > knowing Lisp? 

because boot IS a limited version of lisp. for instance, in the
history mechanism in bookvol5.pamphlet you'll see that boot uses RPLAC
functions to create a circular list. to write this you need to
understand that (a) you're using list structures, (b) how they are
represented (as cons cells) and (c) how rplaca/rplacd modifies
them. all of that requires an understanding of lisp, not boot.

> > 
> > Now about this language war ...
> > [snipped] 
> > So, *if* I was thinking of such a compromise then there are
> > some "terms of surrender" that might make this easier:
> > 
> > 1) Before any more "lispifying" goes on, *first* move Axiom
> >    over to ANSI lisp. This will make it possible to write lisp
> >    that conforms to modern practices and as high level as
> >    possible. It will also make Axiom less dependent on a
> >    particular implementation of Lisp and more easily portable.

so you're suggesting that we modify the boot compiler to generate ansi
lisp code? yet during the "lispifying" rewrite i AM rewriting to ansi
lisp.

> > 
> > 2) No more just cutting and pasting the generated lisp output
> >    of Boot into the literate document! This seems pointless
> >    and a net loss in intelligibility even if it is accompanied
> >    by a verbal explanation of the code. The original Boot code
> >    is, as Tim admitted above, significantly more readable as
> >    "pseudo-code" then what the compiler outputs.

the cut and paste has to happen. it's the only way to make sure the
code does what it originally did. successive passes of the code have
been complete rewrites. you'll see this at the next code release.
there are a LOT of subtle issues that require careful thought and
having working lisp code, even clipped code, is a necessary guide.

believe me, i find the boot compiler output code even more painful
than anyone else. but it is important to move the code from a
correct state to a correct state during the rewrite and i'm not
man enough to do it all in one go.

(btw, as a side-effect of the rewrite i've already found and
corrected two bugs).

if you tried to maintain the system as it is now you'll find that
the boot compiler output is all over the source tree. try this:

  cd axiom/src
  fgrep -r DEFUN *

the boot compiler generates an uppercase DEFUN. look at how
pervasive the compiled lisp code has to be to actually get the
system to bootstrap. in every file where the DEFUN occurs
the BOOT code is just PSUEDO-CODE.

in particular, 

  cd axiom/src/boot
  fgrep DEFUN *

and you'll see how many of the boot compiler files aren't REALLY
written in boot.

believe me, it took a long time with a lot of effort to get the
system to build without a running axiom system.

 and it ain't pretty. but it should be.

> > 
> > 3) Where possible and practical, replace Boot code with Spad
> >    code as in Dick Jenks original vision instead of Lisp. Surely
> >    you are not going to argue that Spad is a "dead language"
> >    written by fewer than 10 surviving programmers? And even if
> >    that happens to be true ;), that is one thing that we are
> >    trying hard to change, right?

wrong level. boot is NOT spad. the languages are NOT related except
by authors. they have different design goals. 

> 
> These terms should not be negotiable! Actually, I would put these as 
> requests to whoever does the work) I would add at least 

ummm, i'm doing the work :-)

and i REALLY don't want to rewrite the boot compiler to make it do
things like ansi common lisp generation. especially if, after having
achieved the 3 *terms* i'd would then have agreement that i could
elide boot from the system. what would be the point?

> 
> 4) The error messages outputted by the compiler should NOT refer to any Lisp.
> Nothing like the current $m, $x, $f stuff. All errors should refer as close to
> the offending source code as possible. (I believe such output was due to
> "laziness" or viewing more intelligible messages as an insult to the developers.
> But that might be why Axiom failed to capture market shares in the 1990's.)

the output uses the variables like $m because that's all the developers
need to know to debug. $m is the target mode information that the
compiler is trying to achieve. 

i agree that the compiler needs to be rewritten to do things like
generate better error messages. 
  to do THAT level of rewrite requires a deep understanding of the compiler. 
    to achieve THAT level of understanding we need to deeply document how 
    the compiler works. 
      to do THAT level of documentation we need to review each function 
      in detail. 
        to do THAT detailed level of documentation is my current goal. 
        as a side-effect of achieving that level of understanding the
        code will be in lisp (which is a language i deeply understand.)

> 
> 5) The )trace function should likewise return high level state of the algebra
> variables, not lisp code or representation of them.

admirable goal. BIG changes to the interpreter and compiler data
structures (since the code is COMPILED into machine language) to
maintain state information that trace can use.

and it needs to be done without impacting efficiency, accumulating
large amounts of possibly unneeded state, etc.

this is like asking C to give you only algorithmicly related error
messages. 


> 6) The interpreted language should adhere to the compiler language to facilitate
> prototyping (in the interpreter) and production code (using the compiler) and
> any deviations (due to the smartness of the interpreter) should be logged to
> help the transfer (maybe it is even possible to translate a working interpreted
> set of routines automatically into compilable code?).

we need to "reify" (name) the interpreter type-translation, guessing
and manipulation mechanisms. we need to separate them from the
interpreter itself so we can understand, add or modify them. 

( to do THAT level of rewrite requires a deep understanding of the interpreter
  ( to achieve THAT level of understanding we need to deeply document how 
    the interpreter works. 
     ( to do THAT level of documentation we need to review each function 
       in detail. 
       ( to do THAT detailed level of documentation is my current goal. 
         as a side-effect of achieving that level of understanding the
         code will be in lisp (which is a language i deeply understand.)))))


read the book when it comes out.
the story turns out ok in the end.

BAD Tim

\start
Date: Sun, 6 Nov 2005 12:01:50 +0100 (CET)
From: Bertfried Fauser
To: Tim Daly
Subject: build from tla failed

Hi Tim,

	I tried to build a new AXIOM from the tla archive. I did an "tla
update ..." on an existing directory and started to compile with "make"
	Everything went fine, untill I got a bunch of "... permission
denied..." statements during the build process of teh brouwser. A second
"make" (I wanted to produce the output of make into a file) however
finished the make process. So I have no file with the original error
messages.
	Result is an working axiom interpreter (it managed to do all the
testing during the make process) but if I start axiom, it issues some
error nonsense in the interpreter and teh browser dies. I checked the file
permissions in the directory which was complained about, but it looks OK
to me. Any hint?

\start
Date: Sun, 6 Nov 2005 09:39:03 -0500
From: Bill Page
To: Tim Daly, William Sit
Subject: RE: Terms of Surrender (was: BAD tim)

Tim,

I feel rallied by William Sit's support, so here comes another
defensive action.

On November 6, 2005 1:55 AM you wrote:

> 
> > First about Boot. My (admittedly poor) understanding of 
> > Boot is that it is an intermedate language between Lisp
> > and Spad (and there are other intermediate languages Shoe,
> > Meta, etc as well). I agree that to build a truely high
> > level language like Spad/Axiom/Aldor, intermediate
> > languages are necessities and not evils. It's much like
> > what a mathematician does all the time (and most original
> > developers are mathematicians, in addition to being 
> > computer scientists): if the
> .....[snip].....
> 
> sorry, but you are reasoning by wrong analogy.
>

William's analogy seems perfectly reasonable to me. That
is exactly the kind of "mindset" and approach that seems
consistent with Axiom's origins. The point is building a
set of concepts, often embedded in a new language (Yes,
mathematicians do invent new language all the time!) which
make expressing the ideas and proofs that you really want
to express, that mush easier. Of course there is an overhead
for learning the new language, but in mathematics that is
often part of the "fun" and when it's done you realize that
you have made some important intellectual gain in power.

The situation of Boot and Lisp is similar because the
abstractions and concepts implicit in Spad would be quite
obscure if one attempted to express them directly in Lisp.
Boot *does* provide an intermediate ground between the
concrete implementation in Lisp and the abstraction of
Spad - just as Dick Jenks apparently intended.

> boot is not an intermediate step between lisp and spad.
> boot is a syntactic sugar coating on lisp that eliminates
> parentheses in favor of "piling" (indenting) code.

Tim, I am amazed that you would make this claim. It is quite
demonstratably incorrect. The use of parenthesis or not in Boot
is *completely* besides the point. Adding braces (as was done
in Aldor) is a trivial syntactic difference and *that* is what
I might agree could be characterized as simple sugar coating.
But the difference between boot and lisp, and the relationship
between boot and Spad is obvious. Even Scot Morrison seems to
hold this view. Just consider the example cited by Clifford Yap
many emails ago:

Boot language:

intloop () ==
    mode := $intRestart
    while mode = $intRestart repeat
      resetStackLimits()
      mode := CATCH($intTopLevel,
            SpadInterpretStream(1, ["TIM", "DALY", "?"], true))

Lisp:

(defun |intloop| ()
 (prog (mode)
  (declare (special |$intTopLevel| |$intRestart|))
   (return
    (progn
     (setq mode |$intRestart|)
     ((lambda ()
       (loop
        (cond
         ((not (equal mode |$intRestart|))
           (return nil))
         (t
          (progn
            (|resetStackLimits|)
            (setq mode
              (catch |$intTopLevel|
               (|SpadInterpretStream| 1
                 (list 'tim 'daly '?) t)))))))))))))

--------

Who could claim that the Boot code has a direct (sugar coating)
relationship to Lisp? Who would miss the similarity between
Boot and Spad?

> it adds no new functionality

Since when does any high level language "add functionality"?
You should not expect it too. Fortran does not add functionality
to Assembler language. If anything it specifically removes
functionality, trading-off extreme flexibility for a more
congenial model of computation. No one could argue that the
development of high level programming languages was some kind
of mistake.

> and does not help you reason about programming any more than,
> say, python or perl.

Here I also completely disagree with you. I *do* think that
Boot, Python and Perl do help you to reason about programming.
I don't mean in the "nuts and bolts" kind of way of say, a
'while'


> in fact it limits the things you can write so you can't use the full
> power of lisp.
> 
> boot does not function as a lemma-like level of reasoning.
> 
> > Second, I think once the bootstrap step is done, it is ok 
> to write a compiler
> > for the language in the language itself. So writing a 
> compiler for C in C, a
> > precompiler for C++ in C, one for Boot in Boot, or for 
> Axiom in Axiom is
> > perfectly reasonable. The purist may want to boil everything down to
> > hand-crafted assembly (dare I say machine?) language, 
> 
> .....[snip].....
> 
> swing and a miss, as they say in baseball. 
> 
> the interpreter needs to be:
>    simple to build, 
>    simple to maintain, 
>    simple to extend, 
>    simple to port.
> 
> writing boot in boot forces the system build to be more complex. 
> 
> it forces the maintenance to be harder since you need to understand 
> whether the problem is in the boot compiler or the interpreter. 
> 
> it forces the user to understand the interaction of lisp vs boot 
> when extending the system since certain facilities have to be in 
> lisp because boot is not yet available at that point in the build 
> process (e.g. setvars)
> 
> it makes the system harder to port because we have to rewrite the
> bootstrap lisp code from old common lisp to ansi common lisp 
> to port it.
> this makes the boot-level code out of date.
> 
> writing boot in boot is clever but it makes building, maintaining, 
> extending, and porting axiom harder than it has to be.
> 
> yes, this can be fixed but fixing it means that you have to
>   (1) rewrite the boot compiler changes in boot
>   (2) recompile the boot compiler to clisp
>   (3) clip out the changes from the clisp file
>   (4) insert the changes into the bootstrap sections of the 
> boot compiler
>   (5) rebuild the system
> 
> writing boot in boot is clever.
> we don't need clever code.
> 
> boot is NOT a higher level language than lisp. spad is.
> boot is NOT spad and is unrelated to spad.
> boot is ONLY seen by interpreter/compiler developers.
> boot is used by 1 developer (me) until the documentation completes.
> 
> 
> 
> > > the other "oh by the way" is that while you can seem to
> > > read boot code without knowing lisp (a sort-of pseudo
> > > code syntax) you can't WRITE boot code without knowing
> > > lisp.
> > 
> > Bill page responded:
> > 
> > > Why is that? Surely it is possible to write Spad code without
> > > knowing Lisp? 
> 
> because boot IS a limited version of lisp. for instance, in the
> history mechanism in bookvol5.pamphlet you'll see that boot uses RPLAC
> functions to create a circular list. to write this you need to
> understand that (a) you're using list structures, (b) how they are
> represented (as cons cells) and (c) how rplaca/rplacd modifies
> them. all of that requires an understanding of lisp, not boot.
> 
> > > 
> > > Now about this language war ...
> > > [snipped] 
> > > So, *if* I was thinking of such a compromise then there are
> > > some "terms of surrender" that might make this easier:
> > > 
> > > 1) Before any more "lispifying" goes on, *first* move Axiom
> > >    over to ANSI lisp. This will make it possible to write lisp
> > >    that conforms to modern practices and as high level as
> > >    possible. It will also make Axiom less dependent on a
> > >    particular implementation of Lisp and more easily portable.
> 
> so you're suggesting that we modify the boot compiler to generate ansi
> lisp code? yet during the "lispifying" rewrite i AM rewriting to ansi
> lisp.
> 
> > > 
> > > 2) No more just cutting and pasting the generated lisp output
> > >    of Boot into the literate document! This seems pointless
> > >    and a net loss in intelligibility even if it is accompanied
> > >    by a verbal explanation of the code. The original Boot code
> > >    is, as Tim admitted above, significantly more readable as
> > >    "pseudo-code" then what the compiler outputs.
> 
> the cut and paste has to happen. it's the only way to make sure the
> code does what it originally did. successive passes of the code have
> been complete rewrites. you'll see this at the next code release.
> there are a LOT of subtle issues that require careful thought and
> having working lisp code, even clipped code, is a necessary guide.
> 
> believe me, i find the boot compiler output code even more painful
> than anyone else. but it is important to move the code from a
> correct state to a correct state during the rewrite and i'm not
> man enough to do it all in one go.
> 
> (btw, as a side-effect of the rewrite i've already found and
> corrected two bugs).
> 
> if you tried to maintain the system as it is now you'll find that
> the boot compiler output is all over the source tree. try this:
> 
>   cd axiom/src
>   fgrep -r DEFUN *
> 
> the boot compiler generates an uppercase DEFUN. look at how
> pervasive the compiled lisp code has to be to actually get the
> system to bootstrap. in every file where the DEFUN occurs
> the BOOT code is just PSUEDO-CODE.
> 
> in particular, 
> 
>   cd axiom/src/boot
>   fgrep DEFUN *
> 
> and you'll see how many of the boot compiler files aren't REALLY
> written in boot.
> 
> believe me, it took a long time with a lot of effort to get the
> system to build without a running axiom system.
> 
>  and it ain't pretty. but it should be.
> 
> > > 
> > > 3) Where possible and practical, replace Boot code with Spad
> > >    code as in Dick Jenks original vision instead of Lisp. Surely
> > >    you are not going to argue that Spad is a "dead language"
> > >    written by fewer than 10 surviving programmers? And even if
> > >    that happens to be true ;), that is one thing that we are
> > >    trying hard to change, right?
> 
> wrong level. boot is NOT spad. the languages are NOT related except
> by authors. they have different design goals. 
> 
> > 
> > These terms should not be negotiable! Actually, I would put 
> these as 
> > requests to whoever does the work) I would add at least 
> 
> ummm, i'm doing the work :-)
> 
> and i REALLY don't want to rewrite the boot compiler to make it do
> things like ansi common lisp generation. especially if, after having
> achieved the 3 *terms* i'd would then have agreement that i could
> elide boot from the system. what would be the point?
> 
> > 
> > 4) The error messages outputted by the compiler should NOT 
> refer to any Lisp.
> > Nothing like the current $m, $x, $f stuff. All errors 
> should refer as close to
> > the offending source code as possible. (I believe such 
> output was due to
> > "laziness" or viewing more intelligible messages as an 
> insult to the developers.
> > But that might be why Axiom failed to capture market shares 
> in the 1990's.)
> 
> the output uses the variables like $m because that's all the 
> developers
> need to know to debug. $m is the target mode information that the
> compiler is trying to achieve. 
> 
> i agree that the compiler needs to be rewritten to do things like
> generate better error messages. 
>   to do THAT level of rewrite requires a deep understanding 
> of the compiler. 
>     to achieve THAT level of understanding we need to deeply 
> document how 
>     the compiler works. 
>       to do THAT level of documentation we need to review 
> each function 
>       in detail. 
>         to do THAT detailed level of documentation is my 
> current goal. 
>         as a side-effect of achieving that level of understanding the
>         code will be in lisp (which is a language i deeply 
> understand.)
> 
> > 
> > 5) The )trace function should likewise return high level 
> state of the algebra
> > variables, not lisp code or representation of them.
> 
> admirable goal. BIG changes to the interpreter and compiler data
> structures (since the code is COMPILED into machine language) to
> maintain state information that trace can use.
> 
> and it needs to be done without impacting efficiency, accumulating
> large amounts of possibly unneeded state, etc.
> 
> this is like asking C to give you only algorithmicly related error
> messages. 
> 
> 
> > 6) The interpreted language should adhere to the compiler 
> language to facilitate
> > prototyping (in the interpreter) and production code (using 
> the compiler) and
> > any deviations (due to the smartness of the interpreter) 
> should be logged to
> > help the transfer (maybe it is even possible to translate a 
> working interpreted
> > set of routines automatically into compilable code?).
> 
> we need to "reify" (name) the interpreter type-translation, guessing
> and manipulation mechanisms. we need to separate them from the
> interpreter itself so we can understand, add or modify them. 
> 
> ( to do THAT level of rewrite requires a deep understanding 
> of the interpreter
>   ( to achieve THAT level of understanding we need to deeply 
> document how 
>     the interpreter works. 
>      ( to do THAT level of documentation we need to review 
> each function 
>        in detail. 
>        ( to do THAT detailed level of documentation is my 
> current goal. 
>          as a side-effect of achieving that level of understanding the
>          code will be in lisp (which is a language i deeply 
> understand.)))))
> 
> 
> read the book when it comes out.
> the story turns out ok in the end.

\start
Date: Sun, 6 Nov 2005 10:49:50 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

intloop () ==
    mode := $intRestart
    while mode = $intRestart repeat
      resetStackLimits()
      mode := CATCH($intTopLevel,
            SpadInterpretStream(1, ["TIM", "DALY", "?"], true))

Lisp:

(defun intloop ()
  (do ((mode $intRestart))
      ((equal mode $intRestart))
   (resetStackInitials)
   (setq mode
    (catch $intTopLevel (SpadInterpretStream 1 '("TIM" "DALY" "?") t)))))

\start
Date: Sun, 6 Nov 2005 10:57:32 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

> Since when does any high level language "add functionality"?
> You should not expect it too. Fortran does not add functionality
> to Assembler language. If anything it specifically removes
> functionality, trading-off extreme flexibility for a more
> congenial model of computation. No one could argue that the
> development of high level programming languages was some kind
> of mistake.

boot and lisp attack the same problem with different syntax.
in the same environment, namely the execution environment of
the interpreter boot loses

   backquote
   macros
   structures
   data-program symmetry
   ....

if we were going to keep a boot-level syntax i'd argue for recoding
the whole interpreter into python. at least python is a recognized
language with documentation and a user base.

but lisp will do what python does
lisp code for the interpreter exists and works
lisp has documentation and a user base
i know lisp.

\start
Date: Sun, 6 Nov 2005 11:10:10 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

> Since when does any high level language "add functionality"?
> You should not expect it too. Fortran does not add functionality
> to Assembler language. If anything it specifically removes
> functionality, trading-off extreme flexibility for a more
> congenial model of computation. No one could argue that the
> development of high level programming languages was some kind
> of mistake.

boot subtracts functionality and forces me to code things that 
i know generate code which is a waste of time. do this:

cd int/interp
fgrep MAKESTRING *

see all those calls to MAKESTRING? lets investigate. each call looks like:

     (MAKESTRING "a string")

so we look up the definition of MAKESTRING in src/interp/vmlisp.lisp:

     (defmacro MAKESTRING (a b) a)

thus

     (MAKESTRING "a string") ==> "a string"

so boot generates MAKESTRING into lisp and lisp expands the macro to 
remove it. pointless.

we need to modify the boot compiler to rewrite these string expressions.
 
( to do THAT level of rewrite requires a deep understanding 
  of the boot compiler
  ( to achieve THAT level of understanding we need to deeply 
     document how the boot compiler works. 
      ( to do THAT level of documentation we need to review 
         each function in detail. 
        ( to do THAT detailed level of documentation is pointless
          since the boot compiler is marked for destruction))))

\start
Date: Sun, 6 Nov 2005 16:21:12 +0100
From: Juergen Weiss
To: Martin Rubey
Subject: re: Boot vs. Lisp

Dear Martin,

> -----Original Message-----
>
> Dear J=FCrgen, Tim, *,
>
> Oops, I didn't know about these points. Since it seems that
> J=FCrgen and Tim have
> some knowledge about Boot, maybe the two of you could drink
> some coffee
> together and decide upon a route that Axiom is to take?

In the last 2 years, I did not have much time to contribute
with the exception of a few mails with my opinion on a few
details. As some else already wrote, people who contribute
code have more influence on the project.

> Juergen Weiss writes:
>
> > 3. Parsing BOOT code
> >
> > The parser for SPAD code is able to parse BOOT code as well
> -- which is not
> > too surprising after point 2 above. You can build Axiom
> with it -- after a
> > few cosmetic changes in syntax in a few more recent files written in
> > BOOT. This parser is equally capable of parsing the
> interpreter input (modulo
> > rules to be fair). The parser has certain deficiencies (for
> example the poor
> > error messages in the compiler showing lisp code).  This
> parser is written
> > with the help of a parser generator (meta). There is
> another parser for boot
> > code in the src/boot directory (always wondered, why it
> exists). Then there
> > is parser which is used for the Axiom interpreter
> (src/interp/pf2* files and
> > others). It is capable of parsing rules.
>
> So, is it possible to have only one parser for all code
> written in pile syntax?
> I suppose that we will always need to have a second parser
> (which will maybe be
> Christian Aisleitners) for the nopile syntax.
>
> Does this parser exist already and is it working -- the above
> seems to imply
> that it is currently not in use?

This parser is the one used by the SPAD algebra compiler. But
as I already noted: it has severe deficiences with respect
to error reporting and maybe some other things.

>
> Another question:
>
> I believe that you have posted a long time ago that you had
> succesfully built
> Axiom with CMUCL. Is this true and is this reproduceable? I
> just found the
> link, it is
>
> http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz
>
> So, couldn't we add CMUCL as a second compiler?

Using the CMU compiler is not a big deal. The tar archive
you mentioned has, I think, a running (but old) version in it.
It would not be difficult to fold the changes into the
current version. As is, it does not support the external
programs (hyperdoc, graphics) as I did not link the
C library into the lisp image. This could probably
by done, or better, as CMU CL does support an almost
complete interface to Unix system calls (and especially
sockets) one could easily recode the glue to the
external programs in Lisp.

The compiler in CMU CL gives a lot of good error messages
and warnings. I found quite a few bugs in the
AXIOM sources with it. And I think the system is a little faster
then GCL on average (did not do too much benchmarking though).

\start
Date: Sun, 6 Nov 2005 10:36:03 -0500
From: Bill Page
To: Tim Daly, William Sit
Subject: RE: Terms of Surrender (was: BAD tim)

[Ooops, got too excited and hit the wrong key and sent this
prematurely ... please excuse the previous partial email.]

Tim,

I feel rallied by William Sit's support, so here comes another
defensive action.

On November 6, 2005 1:55 AM you wrote:

> 
> > First about Boot. My (admittedly poor) understanding of 
> > Boot is that it is an intermediate language between Lisp
> > and Spad (and there are other intermediate languages Shoe,
> > Meta, etc as well). I agree that to build a truly high
> > level language like Spad/Axiom/Aldor, intermediate
> > languages are necessities and not evils. It's much like
> > what a mathematician does all the time (and most original
> > developers are mathematicians, in addition to being 
> > computer scientists): if the
> .....[snip].....
> 
> sorry, but you are reasoning by wrong analogy.
>

William's analogy seems perfectly reasonable to me. That
is exactly the kind of "mindset" and approach that seems
consistent with Axiom's origins. The point is building a
set of concepts, often embedded in a new language (Yes,
mathematicians do invent new language all the time!) which
make expressing the ideas and proofs that you really want
to express, that mush easier. Of course there is an overhead
for learning the new language, but in mathematics that is
often part of the "fun" and when it's done you realize that
you have made some important intellectual gain in power.

The situation of Boot and Lisp is similar because the
abstractions and concepts implicit in Spad would be quite
obscure if one attempted to express them directly in Lisp.
Boot *does* provide an intermediate ground between the
concrete implementation in Lisp and the abstraction of
Spad - just as Dick Jenks apparently intended.

> boot is not an intermediate step between lisp and Spad.
> boot is a syntactic sugar coating on lisp that eliminates
> parentheses in favour of "piling" (indenting) code.

Tim, I am amazed that you would make this claim. It is quite
demonstratably incorrect. The use of parenthesis or not in Boot
is *completely* besides the point. Adding braces (as was done
in Aldor) is a trivial syntactic difference and *that* is what
I might agree could be characterized as simple sugar coating.
But the difference between boot and lisp, and the relationship
between boot and Spad is obvious. Even Scot Morrison seems to
hold this view. Just consider the example cited by Clifford Yap
many emails ago:

Boot language:

intloop () ==
    mode := $intRestart
    while mode = $intRestart repeat
      resetStackLimits()
      mode := CATCH($intTopLevel,
            SpadInterpretStream(1, ["TIM", "DALY", "?"], true))

Lisp:

(defun |intloop| ()
 (prog (mode)
  (declare (special |$intTopLevel| |$intRestart|))
   (return
    (progn
     (setq mode |$intRestart|)
     ((lambda ()
       (loop
        (cond
         ((not (equal mode |$intRestart|))
           (return nil))
         (t
          (progn
            (|resetStackLimits|)
            (setq mode
              (catch |$intTopLevel|
               (|SpadInterpretStream| 1
                 (list 'tim 'daly '?) t)))))))))))))

--------

Who could claim that the Boot code has a direct (sugar coating)
relationship to Lisp? Who would miss the similarity between
Boot and Spad?

> it adds no new functionality

Since when does any high level language "add functionality"?
You should not expect it too. Fortran does not add functionality
to Assembler language. If anything it specifically removes
functionality, trading-off extreme flexibility for a more
congenial model of computation. No one could argue that the
development of high level programming languages was some kind
of mistake.

> and does not help you reason about programming any more than,
> say, python or perl.

Here I also completely disagree with you. I *do* think that
Boot, Python and Perl do help you to reason about programming.
I don't mean in the "nuts and bolts" kind of way of say, a

[message continues here]

'while' statement version a conditional jump instruction,
but rather at the conceptual level. Each of these languages
provides a certain set of tools and data structures and a
characteristic way (maybe several ways) in which to express
common operations on these data structures. This is the
"model of computation" that I referred to above and as
anyone who has programmed in several different languages
knows, this model is sometimes subtly and sometimes quite
grossly different in different programming languages.

> in fact it limits the things you can write so you can't use
> the full power of lisp.

Yes! That is precisely the point of Boot. That is the main
reason for it's existence. It's just like you cannot use
the full power of assembler language in Fortran.

> 
> boot does not function as a lemma-like level of reasoning.
>

I claim you are wrong. The problem must be that you never
really did "grok" the model of computation that the developers
of Boot had in mind. You are still stuck always thinking in
terms of the way things are done in Lisp.
 
> > Second, I think once the bootstrap step is done, it is ok 
> > to write a compiler for the language in the language itself.
> > So writing a compiler for C in C, a precompiler for C++ in C,
> > one for Boot in Boot, or for Axiom in Axiom is perfectly
> > reasonable. The purist may want to boil everything down to
> > hand-crafted assembly (dare I say machine?) language, 
> 
> .....[snip].....
> 
> swing and a miss, as they say in baseball. 
> 
> the interpreter needs to be:
>    simple to build, 
>    simple to maintain, 
>    simple to extend, 
>    simple to port.
> 
> writing boot in boot forces the system build to be more
> complex.

The additional complexity is irrelevant since it works.
And I don't doubt that it works in the open source version
of Axiom in large part due to your efforts. But of course
it has been working since the early days of Axiom development.

> 
> it forces the maintenance to be harder since you need to
> understand whether the problem is in the boot compiler or
> the interpreter.

That is a normal and expected consequence of using a high
level language. Even when using Lisp one must occasionally
consider whether a problem is due to some coding in Lisp or
perhaps due to some incorrect behaviour on the part of the
implementation of Lisp itself.

> ... 
> writing boot in boot is clever but it makes building,
> maintaining, extending, and porting axiom harder than it
> has to be.

The point of writing boot in boot has nothing to do with
being "clever". It is one of the first goals of most projects
which develop a general purpose language. It shows three very
important things: First that the language has attained a
certain fundamental expressive power and completeness. Second
it also serves as a demonstration of the correctness of a
major part of the language. Third, it represents a transition
from the computational model of the source language to the
higher level computational model of the target language.
>From that point on, it is not longer necessary for the compiler
developer to kept both computational models in mind. The
developers specifically want to free themselves from the old
"mindset".

> 
> yes, this can be fixed but fixing it means that you have to
>   (1) rewrite the boot compiler changes in boot
>   (2) recompile the boot compiler to clisp
>   (3) clip out the changes from the clisp file
>   (4) insert the changes into the bootstrap sections of the 
>       boot compiler
>   (5) rebuild the system
>

All of this can be made completely automatic. But of course
it is only relevant in the rare cases when you need to make
changes to the Boot language itself - something that should
be as rare as making changes to Fortran when writing a
numerical calculation package.
 
> writing boot in boot is clever.

No, it is a logical and normal step in the development of a
new programming language.

> we don't need clever code.

Au contraire! If it wasn't for clever code there would be no
Axiom at all. Human beings are notoriously bad a programming.
We need all the help we can get just to do simple things
correctly. That is why while hardware has increased enormously
in power, software has remained (more or less) at the same
technical level that it reached already 30 years ago. That is
the reason why we are running Axiom now - essentially the
same as it was then - on hardware that must be at least a
1,000,000 times faster and more capable then that on which
Axiom was originally developed.

> 
> boot is NOT a higher level language than lisp. Spad is.



> boot is NOT Spad and is unrelated to Spad.

Simply not true. It is clear that Boot has a direct relation
to Spad as Scot Morrison said.

> boot is ONLY seen by interpreter/compiler developers.

That is true. But where do new interpreter/compiler developers
come from? I have argued that it is very likely and even
desirable that they first be Axiom library developers and
therefore would be very familiar with Spad. They would find
working with Boot much easier than working with the full
power of Lisp.

> boot is used by 1 developer (me) until the documentation
> completes.

That is what motivates me to carry out this "war". You want to
make that 0 developers and for the last 3 years I have been
trying hard instead to increase that number. I want documentation
that makes this possible, not documentation that eliminates
the possibility.

> 
> > > the other "oh by the way" is that while you can seem to
> > > read boot code without knowing lisp (a sort-of pseudo
> > > code syntax) you can't WRITE boot code without knowing
> > > lisp.
> > 
> > Bill page responded:
> > 
> > > Why is that? Surely it is possible to write Spad code
> > > without knowing Lisp? 
> 
> because boot IS a limited version of lisp. for instance, in
> the history mechanism in bookvol5.pamphlet you'll see that
> boot uses RPLAC functions to create a circular list. to write
> this you need to understand that (a) you're using list
> structures, (b) how they are represented (as cons cells)
> and (c) how rplaca/rplacd modifies them. all of that requires
> an understanding of lisp, not boot.

No, that is not true. Lisp is irrelevant. The concept of
a linked list and how to manipulate it is all that is needed.
Linked list structures exactly like this are also available
and used effectively in Spad. So of course there is no
problem understanding and using lists if one only writes in
Boot.

> 
> > > 
> > > Now about this language war ...
> > > [snipped] 
> > > So, *if* I was thinking of such a compromise then there are
> > > some "terms of surrender" that might make this easier:
> > > 
> > > 1) Before any more "lispifying" goes on, *first* move Axiom
> > >    over to ANSI lisp. This will make it possible to write
> > >    lisp that conforms to modern practices and as high level
> > >    as possible. It will also make Axiom less dependent on a
> > >    particular implementation of Lisp and more easily portable.
> 
> so you're suggesting that we modify the boot compiler to generate
> ansi lisp code? yet during the "lispifying" rewrite I AM rewriting
> to ansi lisp.

No, I am not concerned about the specific level of the Lisp
output from Boot. Of course, if we move Axiom to Ansi Lisp,
e.g. the Ansi mode of GCL, then what Boot generates must still
be compilable by the GCL compiler. Can you give some examples
where changes would be required to Boot in order to accomplish
this goal?

>From what I have seen in so far in the new BookVol5 I don't
see much use of high level Ansi lisp constructs. At best the
code looks like it is neutral - sort of the lowest common
denominator. When I referred to using Ansi lisp, above it was
in the context of writing lisp at the highest level of
abstraction possible, e.g. using the kind of destructuring
operations that Jergen Weiss pointed out are fundamental to
Boot.

> 
> > > 
> > > 2) No more just cutting and pasting the generated lisp output
> > >    of Boot into the literate document! This seems pointless
> > >    and a net loss in intelligibility even if it is accompanied
> > >    by a verbal explanation of the code. The original Boot code
> > >    is, as Tim admitted above, significantly more readable as
> > >    "pseudo-code" then what the compiler outputs.
> 
> the cut and paste has to happen. it's the only way to make sure
> the code does what it originally did.

This wouldn't be necessary if you did not insist on re-writing
things in Lisp.

> ... 
> (btw, as a side-effect of the rewrite i've already found and
> corrected two bugs).
>

Surely there are easier and better ways to find bugs than
re-writing something.
 
> 
> believe me, it took a long time with a lot of effort to get
> the system to build without a running axiom system.

Of course. It would also take a long time to get a running
C compiler if you did not already have one.

> 
>  and it ain't pretty. but it should be.
> 
> > > 
> > > 3) Where possible and practical, replace Boot code with Spad
> > >    code as in Dick Jenks original vision instead of Lisp. Surely
> > >    you are not going to argue that Spad is a "dead language"
> > >    written by fewer than 10 surviving programmers? And even if
> > >    that happens to be true ;), that is one thing that we are
> > >    trying hard to change, right?
> 
> wrong level. boot is NOT Spad. the languages are NOT related
> except by authors. they have different design goals.

What you say contradicts what Scot Morrison said.

> 
> and I REALLY don't want to rewrite the boot compiler to make
> it do things like ansi common lisp generation. especially
> if, after having achieved the 3 *terms* I'd would then have
> agreement that I could elide boot from the system. what would
> be the point?

What changes are required of boot if we move Axiom to
Ansi lisp?

> 
> I agree that the compiler needs to be rewritten to do things
> like generate better error messages. 
>   to do THAT level of rewrite requires a deep understanding 
>   of the compiler. 
>     to achieve THAT level of understanding we need to deeply 
>     document how 
>     the compiler works. 
>       to do THAT level of documentation we need to review 
>       each function in detail. 
>         to do THAT detailed level of documentation is my 
>         current goal. 
>         as a side-effect of achieving that level of understanding
>         the code will be in lisp (which is a language I deeply 
>         understand.)

The easiest way to avoid this deeply nested list of things
to do is to use Aldor instead of Spad as was originally
planned for Axiom. The main relevance for Boot, in the short
to medium term would be to support the maintenance of the
Axiom Interpreter. In the longer term perhaps it also could
eventually be re-written in Aldor - but at this point with
the current level of interest in Axiom this seems unlikely
to me.

> ... 
> read the book when it comes out.
> the story turns out ok in the end.
> 

I was kind of hoping that we might all be able to
contribute to the actual *writing* of the book. :)

\start
Date: Sun, 6 Nov 2005 16:35:27 +0100
From: Juergen Weiss
To: Martin Rubey
Subject: RE: dependent Types

Dear Martin,

I must admit that my practical knowlegde of AXIOM does not
really include code produced by the A# compiler, as it
predates the availability of A#. And as I wrote in my
last mail, I do not have much spare time which I can
spend on AXIOM. So probably I will not be able to
contribute much to this.

> -----Original Message-----
>
> since you seem to be quite knowledgable of the interpreter,
> would it be
> possible that you look at
>
> http://wiki.axiom-developer.org/219TheInterpreterDoesNotUnders
> tandDependendTypes
>
> It would be really wonderful if you could resolve this!

\start
Date: Sun, 6 Nov 2005 10:44:47 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Terms of Surrender (was: BAD tim)

Am (marginally) happier. :)

On November 6, 2005 10:50 AM Tim Daly wrote:
> 
> intloop () ==
>     mode := $intRestart
>     while mode = $intRestart repeat
>       resetStackLimits()
>       mode := CATCH($intTopLevel,
>             SpadInterpretStream(1, ["TIM", "DALY", "?"], true))
> 
> Lisp:
> 
> (defun intloop ()
>   (do ((mode $intRestart))
>       ((equal mode $intRestart))
>    (resetStackInitials)
>    (setq mode
>     (catch $intTopLevel (SpadInterpretStream 1 '("TIM" "DALY" 
>      "?") t)))))
> 

\start
Date: Sun, 6 Nov 2005 10:49:14 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Terms of Surrender (was: BAD tim)

On November 6, 2005 10:58 AM Tim Daly wrote:

> 
> boot and lisp attack the same problem with different syntax.
> in the same environment, namely the execution environment of
> the interpreter boot loses
> 
>    backquote
>    macros
>    structures
>    data-program symmetry
>    ....
> 
> if we were going to keep a boot-level syntax i'd argue for
> recoding the whole interpreter into python. at least python
> is a recognized language with documentation and a user base.
> 

There is more to the change from lisp to boot than just syntax.
But I agree with your point about the (possible) relevance of
python. In fact we discussed in this email list probably more
than 3 years ago. (Would you like me to lookup on the reference
in the email archive?)

> but lisp will do what python does

Boot also does what python does even more so.

> lisp code for the interpreter exists and works

and currently uses Boot.

> lisp has documentation and a user base
> i know lisp.

No argument there.

\start
Date: Sun, 6 Nov 2005 10:52:15 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Terms of Surrender (was: BAD tim)

On November 6, 2005 11:10 AM Tim Daly wrote:

> 
> boot subtracts functionality and forces me to code things
> that i know generate code which is a waste of time. do this:
> ... 
> we need to modify the boot compiler to rewrite these string 
> expressions.

But the fact that Boot does this is entirely invisible to the
Boot programmer. I don't see any reason other than aesthetics
to want to change this behaviour. As far as I can see it does
not result in any more or less efficient compiled code.

\start
Date: Sun, 6 Nov 2005 11:43:24 -0500
From: Tim Daly
To: Juergen Weiss
Subject: re: Boot vs. Lisp

> > http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz
> > 
> > So, couldn't we add CMUCL as a second compiler?
> 
> Using the CMU compiler is not a big deal. The tar archive
> you mentioned has, I think, a running (but old) version in it.
> It would not be difficult to fold the changes into the
> current version. As is, it does not support the external
> programs (hyperdoc, graphics) as I did not link the 
> C library into the lisp image. This could probably
> by done, or better, as CMU CL does support an almost
> complete interface to Unix system calls (and especially
> sockets) one could easily recode the glue to the
> external programs in Lisp.
> 
> The compiler in CMU CL gives a lot of good error messages
> and warnings. I found quite a few bugs in the
> AXIOM sources with it. And I think the system is a little faster
> then GCL on average (did not do too much benchmarking though).

the first common lisp port of axiom to the ibm/rt was to cmucl
(then called spice lisp under scott fahlman at cmu). it should
still work. i'll fetch the archive and diff it with the current
sources.

the key issue is the browser/graphics integration.

\start
Date: Sun, 6 Nov 2005 11:07:33 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Terms of Surrender (was: BAD tim)

On November 6, 2005 11:10 AM Tim Daly wrote

> ...
> boot is NOT a higher level language than lisp. Spad is.

I think boot is a higher level language than lisp.

In my previous email I intended to quote Jergen Weiss'
example of the use of destructing in Boot:

> 4. Destructuring setq and destructuring comparisons

> One of the highlights in BOOT is the possibility
> to use destructuring setqs and destructuring comparisons.
> This is extremly handy. Some random examples:
>
>   for [[.,arg], :.] in singles while null tuple repeat
>     if arg is ['Tuple,.] then tuple := arg
>
>   a is [=op,b,t1] =>
>
> Without this feature the code will get almost unintelligible.
> And this feature is used in almost every line of code.

Of course Ansi lisp does support such operations at a fairly
high level. That is what motivated me to include the adoption
of Ansi lisp in Axiom as the first of my "terms".

\start
Date: Sun, 6 Nov 2005 17:12:55 +0100
From: Juergen Weiss
To: Bill Page
Subject: re: Boot vs. Lisp

Dear Bill,

> -----Original Message-----
>
> Of course ANSI lisp includes 'destructuring-bind' and other
> operators which support this kind of thing.
>
> http://www.cs.queensu.ca/software_docs/gnudev/gcl-ansi/gcl_443
> .html#SEC443
> http://www.bookshelf.jp/texi/onlisp/onlisp_19.html
>
> "Destructuring is a generalization of assignment. The
> operators setq and setf do assignments to individual
> variables. Destructuring combines assignment with access:
> instead of giving a single variable as the first argument,
> we give a pattern of variables, which are each assigned
> the value occurring in the corresponding position in some
> structure."

In MAC Lisp, I think, there was even a destructuring setq.
One can extend the Common Lisp syntax by macros
to get something like destructuring comparisons. (I did
a google search a few days ago, for destructuring setq --
I found  http://www.bookshelf.jp/texi/onlisp/onlisp_19.html)

But I think the BOOT syntax is much more concise. Much
of the current AXIOM code (interpreter and SPAD library
compiler) operates on lists representing parse trees of
the user input. Here the BOOT syntax is extremely handy.

As I said, a total rewrite with different data structures
may obsolete this advantage. But I think we are far away
from that aim.

And if a reimplementation is indeed going to happen,
we should certainly consider A# as the implementation
language. I cannot follow Tim's opinion, that it's level
is too high (can't find the reference though).

\start
Date: Sun, 6 Nov 2005 17:47:48 +0100
From: Juergen Weiss
To: Tim Daly
Subject: re: Boot vs. Lisp

Dear Tim,

> -----Original Message-----
>
> the first common lisp port of axiom to the ibm/rt was to cmucl
> (then called spice lisp under scott fahlman at cmu). it should
> still work. i'll fetch the archive and diff it with the current
> sources.

I must warn you, that the version is more than 2 years old. Most
changes fix the usage or the better not-usage of #'. There are
2 changes to the algebra files with respect of char and integer
mixture. And directories have no file type in CMU CL - this
change to daase.lisp is not a fix but a hack and does not
work under GCL. The other changes should work with GCL as
well.

> the key issue is the browser/graphics integration.
>
CMU CL has an interface to external C code, but I never
tried it. Rewriting the 2 C files in Lisp should not
be difficult either. Not being too interested in the
graphics and hyperdoc, I did not port these parts
to CMU CL at that time (2 or 3 years ago).

\start
Date: Sun, 6 Nov 2005 13:15:49 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

in open source "advocacy is volunteering"

are you volunteering to write the "boot" compiler docs
and maintain it? can you set it up as a separate language
so we don't need to bootstrap it? you could write bookvol10
(boot language).

to do that you'll have to figure out what parts of axiom
are only there to support boot and you'll have to recode
the portions of the boot compiler that is written in lisp.

will you redo the boot language to support ansi destructuring setq?
structures? mcclim? clos? macros? defvars? 

the bottom line is that without these facilities axiom won't be
able to use the latest lisp developments. we will have essentially
forked the lisp used by axiom. this is something i do not want to do.
we are already off the leading edge of ansi.

yet developing those new boot facilities takes me off into designing 
extensions and enhancements to a language i don't like. and it's
a big project. Jenks and Burge spent a lot of time on it. why the
feature-debating alone could take years!

if we're going to enhance a language i'd much rather the time and
energy went into debating new ideas for the spad language.

since this is open source development you're welcome to document,
support, and enhance boot. for my part, i see no good reason for
it to live so i'm certainly not going to spend my time on this.

i'm advocating literate programming and have likely committed
the rest of my axiom working life to proving (or disproving)
the concept.

t

(btw, axiom lisp has a destructuring setq (which i ported from 
maclisp). we just don't use it. see doDSETQ and *DCQ* in vmlisp.lisp.
the boot compiler SHOULD use it but does not)

\start
Date: Sun, 6 Nov 2005 12:59:50 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Terms of Surrender (was: BAD tim)

Tim

On November 6, 2005 1:16 PM you wrote:
> 
> in open source "advocacy is volunteering"
> 
> are you volunteering to write the "boot" compiler docs
> and maintain it? can you set it up as a separate language
> so we don't need to bootstrap it? you could write bookvol10
> (boot language).

I agree that "advocacy is volunteering" so yes volunteering
to document boot is the least I can do, having spent so much
bandwidth and sweat trying to defend it. :)

> 
> to do that you'll have to figure out what parts of axiom
> are only there to support boot and you'll have to recode
> the portions of the boot compiler that is written in lisp.
>

I know it wont be easy. I wasn't thinking in terms of recoding
anything from lisp to boot or vice versa - just providing a
sound documentation of the design and use of boot as it stands
now.
 
> will you redo the boot language to support ansi destructuring
> setq? structures? mcclim? clos? macros? defvars?

I don't see why this should be necessary. Boot already supports
destructuring setq.

> 
> the bottom line is that without these facilities axiom won't
> be able to use the latest lisp developments. we will have
> essentially forked the lisp used by axiom. this is something
> i do not want to do.

I agree. I think that some ansi constructs can be introduced
without any changes to boot - simply using the escape to lisp
where necessary as explained by Jergen.

> we are already off the leading edge of ansi.

I am not sure what you mean by that.

> 
> yet developing those new boot facilities takes me off into
> designing extensions and enhancements to a language i don't
> like. and it's a big project. Jenks and Burge spent a lot of
> time on it. why the feature-debating alone could take years!

I also do not want that.

> 
> if we're going to enhance a language i'd much rather the time
> and energy went into debating new ideas for the spad language.

I agree completely.

> 
> since this is open source development you're welcome to
> document, support, and enhance boot. for my part, i see no
> good reason for it to live so i'm certainly not going to
> spend my time on this.

No problem. I understand your view, even though I don't agree.
I just didn't like the feeling of my going in this direction
while you seem to be going in exactly the opposite. That is
the reason I am looking for a compromise.

> 
> i'm advocating literate programming and have likely committed
> the rest of my axiom working life to proving (or disproving)
> the concept.
> 

Three cheers! On this we are in complete agreement. I agree
100% with the emphasis on literate programming - so much so
that I have a hard time understanding why you feel that it
might be necessary to prove it.

> t
> 
> (btw, axiom lisp has a destructuring setq (which i ported
> from maclisp). we just don't use it. see doDSETQ and *DCQ*
> in vmlisp.lisp. the boot compiler SHOULD use it but does not)
> 

Thanks, that is interesting. I will look into this a little
more. Do you know if Spad makes any use of these macros?

\start
Date: Sun, 6 Nov 2005 14:22:21 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

> > i'm advocating literate programming and have likely committed
> > the rest of my axiom working life to proving (or disproving)
> > the concept.
> > 
> 
> Three cheers! On this we are in complete agreement. I agree
> 100% with the emphasis on literate programming - so much so
> that I have a hard time understanding why you feel that it
> might be necessary to prove it.

how much of mathaction is developed as a literate program? -- qed

\start
Date: Sun, 6 Nov 2005 14:03:49 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Terms of Surrender (was: BAD tim)

On November 6, 2005 2:22 PM you Tim Daly wrote:
>
> > > i'm advocating literate programming and have likely committed
> > > the rest of my axiom working life to proving (or disproving)
> > > the concept.
> > >
> >
> > Three cheers! On this we are in complete agreement. I agree
> > 100% with the emphasis on literate programming - so much so
> > that I have a hard time understanding why you feel that it
> > might be necessary to prove it.
>
> how much of mathaction is developed as a literate program?
> -- qed
>

Touch=E9!

You are absolutely right. This is something I need to fix.

Much of mathaction itself is directly intended to support
documentation and a lot of the design of mathaction is
already described on the web site. For example:

http://wiki.axiom-developer.org/MathAction

But this is not a literate program. It needs to be merged
with the code itself which is available in the repository:

http://wiki.axiom-developer.org/MathActionRepository

MathAction currently amounts to about 200 lines of Python
code that is added to the LatexWiki code which in turn is a
patch for the ZWiki application in Zope. Excluding Zope, that
probably amounts to at most a few thousand lines of code.

Bob McElrath (the maintainer of LatexWiki) and I have been
discussing off the list the possibility of forking a version
of ZWiki specifically to support LaTeX and the mathaction
extensions for Axiom. One reason for doing this of course is
that LaTeX support is not the kind of main stream feature
that appeals to most wiki users, but to do it properly seems
to imply some fairly deep changes to ZWiki. I have also made
a number of changes on MathAction to ZWiki itself in order to
better support it's use with Axiom, e.g. the preview for
comments. Additionally Bob has expressed some misgivings about
the current copyright policies of the ZWiki developer visa vi
Bob's own view of free software.

We are both a little reluctant to do this because of the time
investments required to maintain an entire separate version,
but perhaps the time has come to seriously consider this. If
we go ahead, then I fully intend to document all of the code
from the MathAction extensions right down to the ZWiki level.

And like in the case of asdf in Lisp, we also need to think
carefully about how best to integrate the way applications
are normally distributed for Zope with the use of pamphlet
files to store Python application code. The match is not
perfect but that can no doubt be solved by the use of some
kind of make script.

\start
Date: Sun, 6 Nov 2005 15:07:43 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

so we can look forward to bookvol11 (mathaction)? :-)

\start
Date: Sun, 6 Nov 2005 14:54:48 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Terms of Surrender (was: BAD tim)

On November 6, 2005 3:08 PM Tim asked:
> 
> so we can look forward to bookvol11 (mathaction)? :-)
> 

Yes. At least chapter 1 - the mathaction specific part,
within the next few days. Recently Clifford Yap asked if
it was possible to install MathAction stand alone on the
desktop. I think some decent documentation will make this
a little easier. Mostly this is just a matter of pulling
together things that are already written elsewhere.

Until recently I did not really think of mathaction as
necessarily very strongly linked to the future of Axiom.
As you know, it started out only as a kind of "quick"
experiment in response to the challenge of making Axiom
output appear on the web. But the idea has grown so that
I now feel like I can reasonably advocate this approach
as the first steps towards the implementation of your
ideas on Doyen and web publishing of Axiom research -
both of a mathematical nature and Axiom development.

\start
Date: Sun, 6 Nov 2005 16:01:26 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

mathaction is on the critical path, or so you've convinced me.  we
need to get it on the desktop, rework axiom to have a browser front
end, make "drag and drop" programs work. and we need it standalone so
we can get the doyen idea (a bootable liveCD science platform)
demonstrated. doyen exists on sourceforge (doyencd project). i can
make bootable cds that interact with axiom thru a browser but i don't
have a mathaction interface. making mathaction work on the desktop is
important for future use. 

i've made the proceedings CDs for the last 2 ISSAC conferences.
i expect to make the third. but this time i'd like to demonstrate
a doyen science platform that runs axiom in a browser and can do
drag-and-drop program installation. the CD push begins in may so
we'd need to demonstrate the ability by then.

if we can get computer algebra working on a doyen cd then we can
construct web pages for various sciences that demonstrate the idea
of a doyen science platform. once we do that we can have a CD at
every science conference. 

and if the "drag-and-drop" works with literate programs we can show
that conference papers can be "executable" and demonstrate real
results by executing on the user's laptop. this will make "showing
the program" as important to computational science as "showing the proof"
is to mathematics.

and, if we get lucky, google will fund it :-)

\start
Date: Sun, 6 Nov 2005 15:12:54 -0500
From: Bill Page
To: list
Subject: FW: [FrontPage] More developers on Axiom

Axiom Developers;

Recently there have appeared some new Axiom users who seem to prefer to
interact via the Axiom Portal rather than by email or through the Wiki.
Changes and additions to the content on the Axiom Portal are not
automatically forwarded to the axiom-developer list, however registered
users of the Portal can subscribe to receive notifactions similar to those
received when the content of the Axiom Wiki is changed.

I have forwarded the following posting here to the axiom-developer list just
as a reminder of the existence of the Axiom Portal side of MathAction and
because I think some people here might find it interesting.

-----Original Message-----

Changes http://portal.axiom-developer.org/wiki/FrontPage/diff
--
I think one of the most important thing that is required for success of
axiom is to induce more developers on axiom. Axiom has been under
development for quite a long time and has grown into a very complex beast so
it is rather hard to for a new developer to "dive-in" to the project right
away; one needs to have good background of what is its philosophy, how
various parts work so forth.

Those who are on this project must be sort of die-hard fans of it :)Hence to
attract more developers, I feel, the strategy should be to expand its
user-base. If a person is happily using axiom he would at some point of time
would add some funtionality to it which could be integrated. In this light,
IMHO, the target audience should not just be those who would be doing
research but all kinds of people who would ever be using a CAS. People
generally tend to remain loyal with their first system: so the idea should
be a kind of "Catch them young" philosophy.

One recent news is that the MuPad is under trouble for various political
reasons. I feel sorry about it but there is something that axiom can from
this situation to its advantage: Axiom is the only system I that is close to
MuPad. Existing MuPad users can be braught to the axiom community.

One more suggestion. There have been a lot of people who have involved in
making axiom. A kind of interview of them would benefitial to any new
developer or user discussing their viewpoint on the system and would
motivate the developers. (I followed the link from the thread above and
found http://people.kde.org doing the same.

\start
Date: Sun, 6 Nov 2005 22:19:33 +0100
From: Hans Peter Wuermli
To: list
Subject: Expression problems

I am struggling with dealing with Expressions. For most sake and purposes I 
can find a fix and solve my small problems, but I never feel very assured. 

Maybe you can give me some pointers. The question that I originally would have 
liked to ask was: is there a "parse tree" object available for elements of 
type, say, Expression(Integer).

As there doesn't seem to exist a parse tree object, I should ask a different 
question: how are you analysing an Expression?

While browsing through the documentation I found many functions that could be 
usable for parsing, but I wasn't very lucky in using them. 

For example, there is a function

isMult(p) 

which is supposed to return [n,x] if p=n*x if n<>0.

For a Symbol x and an Integer n 

isMult(n*x) returns [n,x], 

but for another Symbol y

isMult(y*x) returns "failed".

Not exactly analoguously

isPower(x**y) returns [x**y,1], whereas

isPower(x**10) returns [x,10].

isExpt behaves like isPower, where isTimes differs from isMult and returns all 
factors of a product, i.e.

isTimes(x*y*z)=[x,y,z].

Whereas 

isPlus((x+y+z*y) returns [y z,y,x]

isTimes((x+y)*z) returns "failed" instead of the exp.

Somehow I don't understand the inner logic of these operations.

Any hints for how to proceed are greatly welcome.

\start
Date: Sun, 6 Nov 2005 20:42:52 -0500
From: Bill Page
To: Hans Peter Wuermli
Subject: RE: Expression problems

On November 6, 2005 4:20 PM Hans Peter W=FCrmli wrote:
>
> I am struggling with dealing with Expressions. For most sake
> and purposes I can find a fix and solve my small problems,
> but I never feel very assured.
>
> Maybe you can give me some pointers. The question that I
> originally would have liked to ask was: is there a
> "parse tree" object available for elements of type, say,
> Expression(Integer).

I am not entirely sure what you expect when you say "parse tree",
but maybe InputForm is similar to what you want. Try for example:

(1) -> cos(3*x)::InputForm

   (1)  (cos (* 3 x))
                                        Type: InputForm

The "parse tree" is in the form of a lisp-like S-expression. There
is some information about this at:

http://wiki.axiom-developer.org/ManipulatingExpressions

and

http://wiki.axiom-developer.org/InputForm

>
> As there doesn't seem to exist a parse tree object, I should
> ask a different question: how are you analysing an Expression?

I think the most direct answer to that question is the same as
above: as in InputForm object. But of course the internal details
are a little more complex.

>
> While browsing through the documentation I found many
> functions that could be usable for parsing, but I wasn't
> very lucky in using them.
>
> For example, there is a function
>
> isMult(p)
>
> which is supposed to return [n,x] if p=n*x if n<>0.
>
> For a Symbol x and an Integer n
>
> isMult(n*x) returns [n,x],
>
> but for another Symbol y
>
> isMult(y*x) returns "failed".

That is exactly what it is supposed to do. In the context of
Expression Integer, the parameter n must be an Integer. The
Symbol y is not an Integer.

>
> Not exactly analogously
>
> isPower(x**y) returns [x**y,1], whereas
>
> isPower(x**10) returns [x,10].
>

It is similar:

  isPower(p) returns [x, n] if p = x**n

for some Integer n. In the first case the Integer is 1.

> isExpt behaves like isPower, where isTimes differs from
> isMult and returns all factors of a product, i.e.
>
> isTimes(x*y*z)=[x,y,z].
>

The definition of isTimes is:

  isTimes(p) returns [a_1,...,a_n] if p = a_1*...*a_n and n > 1.

where a_1, ..., a_n are sub-expressions.

> Whereas
>
> isPlus((x+y+z*y) returns [y z,y,x]
>
> isTimes((x+y)*z) returns "failed" instead of the exp.

That is because the expression is internally treated as a
multivariate polynomial like this:

(1) -> ((x+y)*z)::MPOLY([x,y,z],INT)

   (1)  z x + z y
              Type: MultivariatePolynomial([x,y,z],Integer)

If you say:

(2) -> isPlus((x+y)*z)

   (2)  [y z,x z]
                     Type: Union(List Polynomial Integer,...)

perhaps the result makes sense?

>
> Somehow I don't understand the inner logic of these
> operations.
>
> Any hints for how to proceed are greatly welcome.
>

I hope this helps. For some of the details of these operations
I consulted the actual algebra code at:

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FspaceSpad

Click on 'pdf' or 'dvi' to see the documentation.

You can also enter expressions like 'isTimes' in the search box
on the upper right and see all the places in the algebra where
this operation is defined and used.

I haven't checked the Axiom book yet, but if some of the
definitions there are incomplete or misleading, then perhaps
we can update it.

\start
Date: Sun, 06 Nov 2005 20:20:30 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Manipulating Expressions] 

Other Operations

  The domain FunctionSpace includes the following operations::

    isExpt(p,f:Symbol) returns [x, n] if p = x**n and n <> 0 and x = f(a)
    isExpt(p,op:BasicOperator) returns [x, n] if p = x**n and n <> 0 and x = op(a)
    isExpt(p) returns [x, n] if p = x**n and n <> 0
    isMult(p) returns [n, x] if p = n * x and n <> 0
    isPlus(p) returns [m1,...,mn] if p = m1 +...+ mn and n > 1
    isPower(p) returns [x, n] if p = x**n and n <> 0
    isTimes(p) returns [a1,...,an] if p = a1*...*an and n > 1

  If these conditions are not met, then the above operations
  return "failed".

For example,
\begin{axiom}
isMult(3*x)
\end{axiom}
but
\begin{axiom}
isMult(x*y)
\end{axiom}

In the context of 'Expression Integer', or 'Polynomial Integer'
the parameter n must be an Integer. The Symbol 'y' is not an
'Integer'.

Not exactly analogously
\begin{axiom}
isPower(x**y)
\end{axiom}
whereas
\begin{axiom} 
isPower(x**10)
\end{axiom}
In the first case the 'Integer' is assume to be 1.

We have:
\begin{axiom} 
isTimes(x*y*z)
isPlus(x+y+z*y)
\end{axiom}

Whereas 
\begin{axiom}
isTimes((x+y)*z)
\end{axiom}
That is because the expression is internally treated as a
'MultivariatePolynomial' like this:
\begin{axiom}
((x+y)*z)::MPOLY([x,y,z],INT)
\end{axiom}

If you say:
\begin{axiom}
isPlus((x+y)*z)
\end{axiom}
perhaps the result makes sense?

For some of the details of these operations I consulted the
actual algebra code at:

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FspaceSpad

Click on 'pdf' or 'dvi' to see the documentation.

You can also enter expressions like 'isTimes' in the search box
on the upper right and see all the places in the algebra where
this operation is defined and used.

\start
Date: Mon, 07 Nov 2005 11:56:26 +0100
From: Francois Maltey
To: list
Subject: Re: Expression problems

Hello everybody ! Hans, Bill and others...

> I am struggling with dealing with Expressions. For most sake and purposes I
> can find a fix and solve my small problems, but I never feel very assured.

I have the same problem when I try to expand cos(2*x) in cos(x)^2-sin(x)^2.

The expand(cos(x+y)) is right, but expand (cos(2*x)) remains cos(2*x).

Martin and Bill help me, but I can't see the pretty way to write
my own expand which also compute for cos(2*x).

A possible method is here :

http://wiki.axiom-developer.org/SandBoxDistributedExpression

Have a good day !

I'm always waiting for a pretty expand (cos(3*x)) !

\start
Date: Mon, 07 Nov 2005 06:41:07 -0500
From: William Sit
To: Tim Daly
Subject: Re: Terms of Surrender (was: BAD tim)

root wrote:

> sorry, but you are reasoning by wrong analogy.
> 

Let me try another analogy. Ever use MS Word to generate an html page
and look at how inefficient the generated html source is?  Well, I
hate that every time I see such html code, and I myself never used
that: I hand code html pages using only html tags. The result is a
very clean, readable code that I can maintain.  Those pages arn't
fancy, but they are not too plain either (see
http://www.sci.ccny.cuny.edu/~ksda/ for a seminar site I helped
design). Why?  Because I don't like Word, I don't know the fancier
programs like FrontPage, I don't use Frames, etc. So, I am LIMITED in
my ways to construct only utilitarian pages. However, I do not argue
that hand coding html pages is the BEST way. That depends. Hand coding
requires a good knowledge of html (an example: relatively few people
know that html can do superscripts and subscripts, and do most of the
Greek alphabets without loading a language module). But nowadays, one
can use high level tools like MS Word or Mathematica to generate
equations, or FrontPage or a host of other Web tools to create much
more complicated pages and while it is possible to boil them down to a
clean efficient handcoded html page with the same features, it is very
likely the amount of effort is not worth it. An artist now can design
a fancy layout by concentrating on the design rather than the
technicalities of font tags, table tags, picture formats, etc. That is
why almost anyone can design a home page without much training in html
at all. Don't we want the same for Axiom, that anyone who wants to use
symbolic computation can use Axiom without training in lisp?

> the interpreter needs to be:
>    simple to build,
>    simple to maintain,
>    simple to extend,
>    simple to port.
 
> writing boot in boot forces the system build to be more
  complex. [BOOT evils snipped]

Let's say I agree with your assessment for the evils of Boot (I don't
have the qualification to verify your claims, but I am fairly
convinced by Bill Page's rebuttal in his message of Sun, 6 Nov 2005
10:36:03 -0500; but let's put this aside for the moment). Can you
please lay out your vision of how these evils will be eliminated by
giving us an overall picture of what your ultimate architecture is for
Axiom? What will be the remaining components and how do they interact?
What is the booting sequence? What would be required of developers to
maintain the system (besides cloned GOOD TIM)?

You quoted from Bill Page:
> > Now about this language war ...
> > [snipped]
> > So, *if* I was thinking of such a compromise then there are
> > some "terms of surrender" that might make this easier:
> >
> > 1) Before any more "lispifying" goes on, *first* move Axiom
> >    over to ANSI lisp. This will make it possible to write lisp
> >    that conforms to modern practices and as high level as
> >    possible. It will also make Axiom less dependent on a
> >    particular implementation of Lisp and more easily portable.
and said: 
> so you're suggesting that we modify the boot compiler to generate ansi
> lisp code? yet during the "lispifying" rewrite i AM rewriting to ansi
> lisp.

I don't see any conflict in modifying the boot compiler to generate
ansi lisp (or any other type of lisp based on some switch) and
rewriting some parts using ansi lisp, as long as there are good
reasons to do so. I agree with your goal to write for portability, but
at some point, portability has to be of lower priority, especially
before the Axiom system become stable, well documented, and the bugs
corrected. What is the value of new users trying out Axiom on multiple
platforms and finding it to be unreliable computationally or difficult
to understand the outputs (there are many such very simple examples on
IssueTracker). Many will simply abandon Axiom and go back to the M's.

> >
> > 2) No more just cutting and pasting the generated lisp output
> >    of Boot into the literate document! This seems pointless
> >    and a net loss in intelligibility even if it is accompanied
> >    by a verbal explanation of the code. The original Boot code
> >    is, as Tim admitted above, significantly more readable as
> >    "pseudo-code" then what the compiler outputs.
> 
> the cut and paste has to happen. it's the only way to make sure the
> code does what it originally did. successive passes of the code have
> been complete rewrites. you'll see this at the next code release.
> there are a LOT of subtle issues that require careful thought and
> having working lisp code, even clipped code, is a necessary guide.
> 
> believe me, i find the boot compiler output code even more painful
> than anyone else. but it is important to move the code from a
> correct state to a correct state during the rewrite and i'm not
> man enough to do it all in one go.

Your care to maintain the correct state is admirable and for your
purpose, I can understand why you put the boot compiler output code in
the pamphlets. For proper balance, as well as documentation, before
you jettison Boot altogether, I think the boot code generated from
Spad should also be included (if available, since I don't know if Spad
compiles to Boot first or not).

However, I think this miniproject of yours is exactly like someone
wanting to streamline html code generated by say MS Word. I have tried
this myself, and I started with the generated source and then
gradually pairing down the redundant or worse, irrelevant code. But it
is tedious, error prone, and in the end, other than getting a file
that is much smaller, I wasted hours of my time. I don't do that any
more: hard disk space is cheap and CPU's are fast. I don't notice a
difference other than I still hate the generated code mess. But I
understand that whoever designed that html page did not start from a
blank page with html code and will not maintain it by reading the
generated code. If they need to make changes, they will be using the
high level tools because they trust (and don't care about) the
generated code. The problem to streamline generated code can be solved
by optimization (even though often that is not done or tools are not
available). Perhaps you will consider writing an optimizer for the
boot compiler instead?

> (btw, as a side-effect of the rewrite i've already found and
> corrected two bugs).

In a production environment, language compiler bugs should be rare.
Besides, are you sure it is the rewrite that helps you find the bugs
and not the understanding of the Boot code before rewriting? Did you
discover the bugs before or after the rewrite? If before, did you try
fixing it in the boot code?  If not, why not? If it is AFTER, did you
also try if it can be fixed in the boot code? In this case, I also
seriously worry that your rewrite may not be faithfully rendered
(assuming your translation is exactly logically equivalent as far as
Lisp goes, but somehow the Lisp compiler handles them differently and
the object codes differ). This time, you may be fixing two bugs, but
next time, it could be introducing two bugs. Are you willing to dig
into the Lisp compiler to figure out the differences?

> if you tried to maintain the system as it is now you'll find that
> the boot compiler output is all over the source tree. try this:
> 
>   cd axiom/src
>   fgrep -r DEFUN *
> 
> the boot compiler generates an uppercase DEFUN. look at how
> pervasive the compiled lisp code has to be to actually get the
> system to bootstrap. in every file where the DEFUN occurs
> the BOOT code is just PSUEDO-CODE.
> 
> in particular,
> 
>   cd axiom/src/boot
>   fgrep DEFUN *
> 
> and you'll see how many of the boot compiler files aren't REALLY
> written in boot.

I am not following your line of thought. Isn't the role of the boot
compiler to compile Boot into Lisp code? So if the Boot code can use
SOME embedded Lisp as a subset of the language, what is the problem?
Are you suggesting that if one only uses Lisp (and get rid of Boot)
that there will be fewer DEFUN's?

> believe me, it took a long time with a lot of effort to get the
> system to build without a running axiom system.

I don't for any moment forget what you put into the project to make
Axiom alive again. To that we all thank you. But we now have a running
axiom system and why must we continue to build without a running axiom
system? Can't we ship Axiom just like NAG shipped it (minus whatever
is not open-sourced)?

>  and it ain't pretty. but it should be.

Beauty is in the eyes of the beholder.

[snipped]

Quoting from William Sit:

> > These terms should not be negotiable! Actually, I would put these as
> > requests to whoever does the work) I would add at least
> 
> ummm, i'm doing the work :-)

Hope that you are not the only one forever.
 
> and i REALLY don't want to rewrite the boot compiler to make it do
> things like ansi common lisp generation. especially if, after having
> achieved the 3 *terms* i'd would then have agreement that i could
> elide boot from the system. what would be the point?

But so would be documenting the Boot code. It is kind of "on the
path"; like a rocket fuel tank that has to be jettisoned after
launch. That does not mean the fuel tank is pointless.

> > 4) The error messages outputted by the compiler should NOT refer
> > to any Lisp.  Nothing like the current $m, $x, $f stuff. All
> > errors should refer as close to the offending source code as
> > possible. (I believe such output was due to "laziness" or viewing
> > more intelligible messages as an insult to the developers.  But
> > that might be why Axiom failed to capture market shares in the
> > 1990's.)
 
> the output uses the variables like $m because that's all the developers
> need to know to debug. $m is the target mode information that the
> compiler is trying to achieve.

No, unless the developers also know Boot and Lisp. Often the values
for $m, etc have no relation to where the bug is in the source.  While
breaking, I got into Boot, and the data structure (usually raw) is
presented by such a long string that I quickly got lost. It is
necessary to know deeply how the source is translated into Lisp. On
the other hand, understanding the logic at the source and often the
type system in Axiom was what saved the day. For engineers, scientists
or mathematicians who are not also computer scientists, this is a huge
hurdle to overcome.
 
> i agree that the compiler needs to be rewritten to do things like
> generate better error messages.
>   to do THAT level of rewrite requires a deep understanding of the compiler.
>     to achieve THAT level of understanding we need to deeply document how
>     the compiler works.
>       to do THAT level of documentation we need to review each function
>       in detail.
>         to do THAT detailed level of documentation is my current goal.
>         as a side-effect of achieving that level of understanding the
>         code will be in lisp (which is a language i deeply understand.)

How does error messages from the Aldor compiler compare? If it  has already
achieved THAT level, may be that's the way.

> > 5) The )trace function should likewise return high level state of
> > the algebra variables, not lisp code or representation of them.
 
> admirable goal. BIG changes to the interpreter and compiler data
> structures (since the code is COMPILED into machine language) to
> maintain state information that trace can use.
 
> and it needs to be done without impacting efficiency, accumulating
> large amounts of possibly unneeded state, etc.
 
> this is like asking C to give you only algorithmicly related error
> messages.

What we need is a development kit with tools to set breaks and examine
Axiom variables, displayed in mathematical notations, not Lisp data
structures down to the nitty gritty. The translation tools are
definitely there already (in coerce to OutputForm) and it is a matter
of whether those tools can be called from within Lisp or Boot.  Since
Axiom algebra code is highly structured, it should be possible to dig
(zoom) into substructures for debugging purposes, but substructures
need not be automatically revealed. Such tools are routinely available
for other common languages.

> > 6) The interpreted language should adhere to the compiler language
> > to facilitate prototyping (in the interpreter) and production code
> > (using the compiler) and any deviations (due to the smartness of
> > the interpreter) should be logged to help the transfer (maybe it
> > is even possible to translate a working interpreted set of
> > routines automatically into compilable code?).
 
> we need to "reify" (name) the interpreter type-translation, guessing
> and manipulation mechanisms. we need to separate them from the
> interpreter itself so we can understand, add or modify them.
> 
> ( to do THAT level of rewrite requires a deep understanding of the interpreter
>   ( to achieve THAT level of understanding we need to deeply document how
>     the interpreter works.
>      ( to do THAT level of documentation we need to review each function
>        in detail.
>        ( to do THAT detailed level of documentation is my current goal.
>          as a side-effect of achieving that level of understanding the
>          code will be in lisp (which is a language i deeply understand.)))))

I am not convinced that deep understanding of Lisp is sufficient or necessary,
much like a deep understanding of assembler languange alone is neither
sufficient nor necessary to debug Lisp code. At each level of translation, the
logic and design of the program need to be understood and well documented to
assist debugging. What is necessary and sufficient for working in Axiom,
especially with the compiler, is a deep understanding of the algebra Spad code
and the mathematics behind it. A better error message response on the algebra
Spad level rather than the Lisp or Boot level, together with a compatible
interpreter/compiler environment will go a long way to help the writing of
robust algebra code -- the goal of Axiom. It will remove at least 50% of the
frustrations in developing algebra code and correspondingly doubles the
retention rate of new users (empirical projections, of course).

> read the book when it comes out.
> the story turns out ok in the end.
> BAD Tim

Can we change that to GOOD TIM?

\start
Date: Mon, 07 Nov 2005 06:41:51 -0500
From: William Sit
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

Bill Page wrote:
> 
> Am (marginally) happier. :)
> 
> On November 6, 2005 10:50 AM Tim Daly wrote:
> >
> > intloop () ==
> >     mode := $intRestart
> >     while mode = $intRestart repeat
> >       resetStackLimits()
> >       mode := CATCH($intTopLevel,
> >             SpadInterpretStream(1, ["TIM", "DALY", "?"], true))
> >
> > Lisp:
> >
> > (defun intloop ()
> >   (do ((mode $intRestart))
> >       ((equal mode $intRestart))
> >    (resetStackInitials)
> >    (setq mode
> >     (catch $intTopLevel (SpadInterpretStream 1 '("TIM" "DALY"
> >      "?") t)))))

If this is what you view as sugar coating, then why not write all Spad
code in Lisp?

But even if it is sugar coating, don't we all like sweets (especially
dentists)?

I would prefer the Boot version over the Lisp version 100 to 1 (even
though I don't follow either -- something like "blame TIM DALY if
something goes wrong"?). Let the computer perform the translation for
me. Put the Boot version in the pamphlet!

\start
Date: Mon, 07 Nov 2005 06:44:58 -0500
From: William Sit
To: Tim Daly
Subject: Re: Terms of Surrender (was: BAD tim)

root wrote:

> boot subtracts functionality and forces me to code things that
> i know generate code which is a waste of time. do this:
> 
> cd int/interp
> fgrep MAKESTRING *
> 
> see all those calls to MAKESTRING? lets investigate. each call looks like:
> 
>      (MAKESTRING "a string")
> 
> so we look up the definition of MAKESTRING in src/interp/vmlisp.lisp:
> 
>      (defmacro MAKESTRING (a b) a)
> 
> thus
> 
>      (MAKESTRING "a string") ==> "a string"
> 
> so boot generates MAKESTRING into lisp and lisp expands the macro to
> remove it. pointless.
> we need to modify the boot compiler to rewrite these string expressions.
> 

Every compiler (or assembler) generates inefficient codes because they need for
example to "parenthesize" every piece of code: just look at the LaTeX code
generated by any symbolic computation package, including Axiom. In assembler,
that would be pushing and popping stacks. These can be corrected by compiler
optimization, a fairly well understood technology. So what is needed is an
optimizer, not hand-recoding.
 
> ( to do THAT level of rewrite requires a deep understanding
>   of the boot compiler
>   ( to achieve THAT level of understanding we need to deeply
>      document how the boot compiler works.
>       ( to do THAT level of documentation we need to review
>          each function in detail.
>         ( to do THAT detailed level of documentation is pointless
>           since the boot compiler is marked for destruction))))

Are you suggesting that by simply hand-optimizing away these inefficiencies
(like my earlier analogy with cleaning generated html code), you do NOT need 
  (a deep understanding of the boot compiler
    (deeply document how the boot compiler works
     (review each function in detail)))
? and if 
  (the boot compiler is marked for destruction)
are you going to rewrite the interpreter in Lisp?

I get a feeling that you find it difficult, or at least you are unwilling, to
document Boot, its compiler, and each Boot function. Do you imply that 
reimplementing the Interpreter (or a better version of it) from scratch can be
done without such deep understanding and documentation?

\start
Date: Mon, 07 Nov 2005 06:48:56 -0500
From: William Sit
To: Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

Bill Page wrote:
> 
> Tim
> 
> On November 6, 2005 1:16 PM you wrote:
> >
> > in open source "advocacy is volunteering"
[snipped]
> I agree that "advocacy is volunteering"  ...

Well, I don't! To have that as the defacto working principle is to
discourage people from commenting or advocating. All who submit their
comments, experience, or voice their deeply felt convictions ARE
volunteering, but it does NOT mean they should be also the ones to
carry out and implement the code. We should all simply be working
together, each contributing what (s)he can, but with an open mind to
accept or reject suggestions after due considerations.

[snipped]
> > if we're going to enhance a language i'd much rather the time
> > and energy went into debating new ideas for the spad language.
> 
> I agree completely.

This is a perfect example: people who suggest new ideas for the spad language
need not be the ones to implement them. In fact, possibly, they are not even
qualified to implement them. Let each contribute his/her best.

\start
Date: Mon, 7 Nov 2005 08:50:16 -0500
From: Bill Page
To: Hans Peter Wuermli
Subject: RE: Expression problems

Hans Peter,

On November 7, 2005 1:28 AM you wrote:
> 
> Thank you for the quick answer. I had hoped for a different 
> one. S-expressions are what I would call a parse tree, but
> I feel that I have to leave thinking in Axiom and need
> rethinking in Lisp. Anyway, I will try.

I know what you mean, but I don't think that it is necessary
to "rethink in Lisp" as such. Structures like InputForm are
certainly Axiom domains in their own right. For example you can
write:

  A:=sin(2*x)::InputForm
  A.2.1

to get the "*". The InputForm domain includes a large number
of operations:

  )show InputForm

including one called 'interpret' that evaluates the InputForm
as an actual input.

> 
> I understand if you write that inMult does exactly what it 
> should, but somehow I would like to program without always
> having to have the precise documentation at hand (which in
> this case would have to be the source code, as in the
> HyperText documentation no type requirements are given, i.e.
> that "n in R").

Of course HyperDoc and the Axiom book need to be updated to
include information about these functions.

> 
> Just one example to explain, why I felt there was some
> inconsistency:
> 
> if isPower(x**y) returns [x**y,1] then I would expect 
> isMult(x*y) to return [x*y,1] as the power expression
> seems to be viewed as (x**y)**1, so one would 
> expect the second expression to be viewed as (x*y)*1.
> 

I agree with you that it is a little inconsistent. What do
you think would be better: 1) for isPower(x**y) to return
"failed" or 2) for isMult(x*y) to return 1?

If we check carefully how these are used in the Axiom library
code and the Axiom test input files now, then I expect that
it would be quite easy to make these operations consistent.

\start
Date: Mon, 7 Nov 2005 09:22:47 -0500
From: Bill Page
To: list
Subject: RE: [fspace.spad] dvi file display

Willaim,

Thanks for noticing this. I get the a similar error when I try
to open the dvi file using Yap from MikTeX. But this is very
strange because I can open other dvi files and I can even open
this file in pdf format even though the pdf format is created from
the dvi using dvipdfm.

The file does contain some very long lines of machine generated
lisp bootstrap code. Maybe that is a problem for dvi viewers?
I will try adding some new lines in this code and see if that fixes
the problem.

Have any seen this error with any other source files?

Can anyone reproduce this problem using a dvi viewer on linux?

On November 7, 2005 3:50 AM William Sit wrote:

>
> Changes
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FspaceSpad/diff
> --
> I click on the dvi (OS: Windows XP, dvi viewer: DVIWIN). It
> is a 118 page document with the first 84 pages "gabbage"
> consisting mainly of a few symbols a page. On p. 85, the
> title page appears, followed by a table of contents, followed
> by the source code (except that spaces become xxx's).
>
> DVIWIN reports the following error messages ::
>
> \begin{verbatim}
> Opening c:\docume~1\william\locals~1\temp\fspace~1.dvi
> (118 pages)
> [1]
> TeX \special{t4ht@[} ignored
> ...

\start
Date: 07 Nov 2005 16:20:36 +0100
From: Martin Rubey
To: William Sit
Subject: Re: Terms of Surrender (was: BAD tim)

William Sit writes:

> What we need is a development kit with tools to set breaks and
> examine Axiom variables, displayed in mathematical notations, not
> Lisp data structures down to the nitty gritty.

You do know about

)trace COMBF )math

(does not work with EXPR, unfortunately. Bind Stack overflow, there is an
infinite loop somewhere.)

\start
Date: Mon, 7 Nov 2005 10:52:32 -0500
From: Tim Daly
To: Bill Page
Subject: re: [fspace.spad] dvi file display

what source file?

\start
Date: Mon, 7 Nov 2005 07:07:32 -0800 (PST)
From: Cliff Yapp
To: William Sit, Bill Page
Subject: Re: Terms of Surrender (was: BAD tim)

--- William Sit wrote:

> Bill Page wrote:
> > 
> > Tim
> > 
> > On November 6, 2005 1:16 PM you wrote:
> > >
> > > in open source "advocacy is volunteering"
> [snipped]
> > I agree that "advocacy is volunteering"  ...
> 
> Well, I don't! To have that as the defacto working principle is to
> discourage people from commenting or advocating.

I think it is more like "if there are two firmly opposed points of view
in a debate, if only one person is willing to put the coding time
behind their ideas then they win the argument by default."  Or perhaps
"only ideas with both merit and support can survive."

I think Tim is saying (correct me if I'm wrong Tim) he things his
reasons are good ones, he is not convinced by the counter arguments,
and he is willing to support his ideas with the effort it takes to make
them real.  This being the case it is unreasonable to expect him to
undertake coding tasks he neither enjoys nor thinks are necessary
simply due to a group vote.  If the opposing viewpoints are willing to
put in the effort to actually implement their ideas then they gain much
more respect and if they turn out well they can be incorporated into
the project too.  I'm guessing that's what Bill was agreeing with.

> All who submit their comments, experience, or voice their deeply 
> felt convictions ARE volunteering, but it does NOT mean
> they should be also the ones to carry out and implement the code. 

True.  But nor should those who are actually be doing the coding have
to abandon their ideas - the name of the game is to convince the
opposition that your ideas are good ones.  There are two ways to
advance a viewpoint in open source - one is to try and present an idea
on its merits, and convince the active coders it is a good one.  But
there is no guarantee that the developer will agree with you.  Failing
that, you can implement it yourself and demonstrate its potential.  I
for one think this debate is a very healthy one, and I don't think Tim
is trying to argue that people shouldn't be voicing their ideas.  I
think what he's saying (again, Tim please correct me if I'm wrong) is
that he has a design in mind, he is putting forth his time and effort
to bring it to fruition, and he believes in his design decisions enough
to try putting them into practice.  Discussion is fine, but barring
something both objective and compelling (which is virtually impossible
in this kind of debate) he has chosen his implementation path.

A lot of us have been arguing in a way that sort of suggests that if we
argue to concensus we think Tim should/will shift his direction
accordingly, and we have no right to expect that.  I for one wish to
apologize to Tim if I have given him that impression.  I'm fascinated
by the question of the relative merits of the two design philosophies,
and am wondering if there is in fact any objective way to evaluate them
at all.   There have been extremely intelligent arguments put forth on
all sides, and it's been a treat to be able to witness such
discussions.  But when all is said and done Tim is his own master and
the active coder's decision is the one that the project goes with by
default, because it's a very, very bad decision that makes an active
project worse than in inactive one.  If we can't convince Tim that some
path other than the one he has decided on is better, based on the
merits, then that's fine.  There is certainly nothing stopping us from
experimenting ourselves, and if Tim wants to carry through with his
design I for one am thrilled.  I remember a quote from one of the Dune
books that I think went like this - "Most decisions can be made to
work, or if shown not to work can be corrected. But refusing to chose
any course results in certain disaster, because no new information is
gained and no progress is made."  One step backwards and two forwards
may be less efficient than three steps forward, but either is far far
better than no steps at all.  Whether Tim is making a step forward or
backward will be shown by events, but regardless making the step is
preferable to remaining deadlocked.  Remember, a worst case scenario is
simply a) we roll back the archive to the point at which the Boot code
is intact, and b) proceed from there.  The really important
mathematical code is written in SPAD or Aldor, and surivives
regardless.  

Ultimately, perhaps we can all agree that more important than either
Boot or Lisp is for Axiom to remain a living, vital project.  If we
move to Lisp rather than Boot, we'll survive.  If we go to Boot rather
than Lisp, we'll survive.  Either way, we'll learn new things. 
Ideally, most of the time we won't have to work in either Lisp or Boot,
but at the higher level of SPAD/Aldor where the really interesting
mathematical developments will happen.  Without active effort, design,
documentation, and new mathematical work no language choice will ensure
Axiom's survival.

I personally favor Lisp, but I will make no further attempt to join in
the argument.  I will say that for my part, regardless of the final use
of Lisp or Boot, I will stick with the Axiom project because the ideas
behind transcend language and are in fact what make Axiom special to
begin with.  

> We should all simply be working together, each contributing what 
> (s)he can, but with an open mind to accept or reject suggestions
> after due considerations.

Agreed.  Remember though, in this kind of discussion there is
legitimate room for many different points of view - it's not like a
mathematical problem where a correct solution can be demonstrated.  

> > > if we're going to enhance a language i'd much rather the time
> > > and energy went into debating new ideas for the spad language.
> > 
> > I agree completely.
> 
> This is a perfect example: people who suggest new ideas for the spad
> language need not be the ones to implement them. In fact, possibly, 
> they are not even qualified to implement them. Let each contribute 
> his/her best.

Definitely.  I think Tim and Bill mutually concluded though that the
SPAD level, where most significant work will be taking place, is the
most logical forum for language considerations.  Ultimately, both Lisp
and Boot are "under the hood" and either can be made to function.  SPAD
or perhaps Aldor will be the public face for Axiom coding, and has a
specialized focus as well.

Tim, am I right that the eventual goal is to have all significant work
take place in SPAD/Aldor, and the Lisp supporting structure become
stable and need little tweaking?  (Sort of like the TeX source code?) 
I'm hoping that if McCLIM can eventually be used to define a GUI, we
can define a SPAD/Aldor API for interacting with and defining any
needed custom graphical elements, and then forget all about any
language below SPAD/Aldor except for maintainance issues.  But perhaps
I'm seeing it incorrectly.

Anyway, rant mode off :-)  Viewpoints aside I've been very much
impressed with the quality of thought and expression from all sides on
this list, and I think it speaks well of Axiom that it can attract this
caliber of discussion and thought.  Thanks for making this such an
interesting forum for discussion.

Cheers,
CY

P.S. - One idea I'd like to mention both to Tim and his debate
opponents - what about the idea of keeping the Lisp like syntax, but
defining macros or whatnot to add some of the "safety" that Boot
provides in coding?  The result will still be Lisp, make no mistake (I
for one really like that all I have to worry about is getting the right
number of parenthesis, as opposed to other syntax mistakes, but that's
just a personal preference) but perhaps some of what appeals to the
Boot folks could be incorporated as macros or whatnot in the Lisp code
itself, and in fact make the Lisp coding easier?  Tim, were you
planning something like this?  We haven't seen much of your hand coded
lisp yet, so perhaps you were already planning something like that?  I
know that's a popular thing in Lisp, having the computer do work
instead of the programmer, so perhaps something of the sort could be
useful here?

Boot guys, maybe the thing to do is to enumerate what makes Boot a good
tool for writing the SPAD compiler (or whatever) and look for a way to
have Lisp macros or some such assist the programmer.  Boot syntax I
don't think is going to make it, but if we take an ideas approach
perhaps there is some useful mapping to be done which would appeal both
to the original motivations for Boot and to an advanced Lisp
programmer.  Rather than an all or nothing stance, perhaps accepting
Tim's focus on Lisp and looking for ways to intelligently code Lisp to
achieve the best (non-syntax) ideas of Boot would result in something
everyone can be satisfied with.

\start
Date: Mon, 07 Nov 2005 16:10:17 +0100
From: Kai Kaminski
To: list
Subject: Good Tim

Hi everyone,

I don't feel like participating in the language arguments going on at
the moment. Still I would like to voice my support for Tim's position
in this matter.

In particular, I agree with him that BOOT is *not* higher-level than
Lisp. There is not a single feature in Lisp that can't be embedded in
Lisp with macros.

I also agree with him that in open source "advocacy is
volunteering". Hence I'm willing to start working on converting BOOT
code to Lisp as soon as Tim tells me that he'll accept such patches.

\start
Date: 07 Nov 2005 17:13:55 +0100
From: Martin Rubey
To: Bill Page
Subject: re: [fspace.spad] dvi file display

Bill Page writes:

> Have any seen this error with any other source files?
> 
> Can anyone reproduce this problem using a dvi viewer on linux?
> 

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FspaceSpad

Clicking on pdf or dvi returns a page 

-------------------------------------------------------------------------------

I could not find any likely page matching "error" 

Click here to 

create this page

search for it

  or visit the front page. 

-------------------------------------------------------------------------------

Downloading, compiling and viewing TeX works fine. (Debian, tetex, kdvi)

\start
Date: Mon, 7 Nov 2005 07:48:31 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Couple of quick questions while I'm thinking of them

Dunno if these relate to Mathaction, the pamphlet structure, or what
exactly so I'll just throw them out:

a)  I'm building a bibtex file that is specialized to the units and
dimensions effort - how would this file be handled as 1) part of a
MathAction rendering and 2) as part of the Axiom source tree if it
makes it that far?  Should it just be uploaded onto MathAction and the
latex file will find it there, or is it a little more complicated?

b)  I'm using the hyperref package with a few tweaks to things like
color settings to provide things like a clickable table of contents and
active links to references - is this OK or is this something we don't
want to do with pamphlet files?  I'm assuming we want a uniform look
for pamphlet files so perhaps I could submit my proposed look for
consideration?  Also, how will MathAction react to it?  I've been
assuming the TeX distribution on the server is the full tetex, but
perhaps I should check that assumption.

\start
Date: Mon, 07 Nov 2005 09:49:53 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Programming Axiom] 

Debugging in Axiom

  Axiom contains some powerful commands to help with testing and
debugging library modules written in Spad and also the Axiom system
itself. The most important of these commands is ')trace'.

This command is used to trace the execution of functions that make
up the Axiom system, functions defined by users, and functions from
the system library. Almost all options are available for each type
of function but exceptions will be noted below.

To list all functions, constructors, domains and packages that are
traced, simply issue::

  )trace

To untrace everything that is traced, issue::

  )trace )off

When a function is traced, the default system action is to display
the arguments to the function and the return value when the function
is exited. Other information can be displayed or collected when a
function is traced and this is controlled by the various options.
If a domain or package is traced, the default action is to trace all
functions exported. Individual interpreter, lisp or boot functions
can be traced by listing their names after ')trace'. Any options that
are present must follow the functions to be traced. For example::

  )trace f

traces the function f. To untrace f, issue::

  )trace f )off

Note that if a function name contains a special character, it will
be necessary to escape the character with an underscore::

  )trace _/D_,1

To trace all domains or packages that are or will be created from a
particular constructor, give the constructor name or abbreviation
after ')trace'::

  )trace MATRIX
  )trace List Integer

The first command traces all domains currently instantiated with
Matrix. If additional domains are instantiated with this constructor
(for example, if you have used 'Matrix(Integer)' and 'Matrix(Float)'),
they will be automatically traced. The second command traces
'List(Integer)'.

The following are the general options for the ')trace' command.

')break after' -- causes a Common Lisp break loop to be entered after
exiting the traced function.

')break before' -- causes a Common Lisp break loop to be entered before
entering the traced function.

')break' -- is the same as )break before.

')count' -- causes the system to keep a count of the number of times the
traced function is entered.

The total can be displayed with::

   )trace )stats

and cleared with::

   )trace )stats reset

')count n' -- causes information about the traced function to be displayed
for the first n executions. After the n-th execution, the function is
untraced.

')depth n' -- causes trace information to be shown for only n levels of
recursion of the traced function.

The command::

  )trace fib )depth 10

will cause the display of only 10 levels of trace information for the
recursive execution of a user function fib.

')math' causes -- the function arguments and return value to be displayed
in the Axiom monospace two-dimensional math format.

')nonquietly' -- causes the display of additional messages when a function
is traced.

')nt' -- This suppresses all normal trace information. This option is useful
if the ')count' or ')timer' options are used and you are interested in the
statistics but not the function calling information.

')off' -- causes untracing of all or specific functions. Without an argument,
all functions, constructors, domains and packages are untraced. Otherwise,
the given functions and other objects are untraced.

To immediately retrace the untraced functions, issue::

  )trace )restore

')only listOfDataToDisplay' -- causes only specific trace information to be
shown.

')restore' -- causes the last untraced functions to be retraced. If
additional options are present, they are added to those previously in
effect.

')stats' -- causes the display of statistics collected by the use of the
')count' and ')timer' options.

')stats reset' -- resets to 0 the statistics collected by the use of the
')count' and ')timer' options.

')timer' -- causes the system to keep a count of execution times for the
traced function. The total can be displayed with ')trace )stats' and
cleared with ')trace )stats reset'.

')varbreak var1 ... varN' -- causes a Common Lisp break loop to be
entered after the assignment to any of the listed variables in the
traced function.

')vars' -- causes the display of the value of any variable after it is
assigned in the traced function. Note that library code must have been
compiled using the ')vartrace' option in order to support this option.

')vars var1  ... varN' -- causes the display of the value of any of
the specified variables after they are assigned in the traced function.
Note that library code must have been compiled using the ')vartrace'
option in order to support this option.

')within executingFunction' -- causes the display of trace information
only if the traced function is called when the given executingFunction
is running.

The following are the options for tracing constructors, domains and
packages.

')local op1 ... opN' -- causes local functions of the constructor to
be traced. Note that to untrace an individual local function, you must
use the fully qualified internal name, using the escape character before
the semicolon. For example::

  )trace FRAC )local
  )trace FRAC_;cancelGcd )off

')ops op1 ... opN' -- By default, all operations from a domain or package
are traced when the domain or package is traced. This option allows you
to specify that only particular operations should be traced.

The command::

  )trace Integer )ops min max _+ _-

traces four operations from the domain Integer. Since + and - are special
characters, it is necessary to escape them with an underscore.

Also See: ')boot', ')lisp' , and ')ltrace'. Please refer to the
"Axiom Book":AxiomDocumentation, section "Axiom System Commands"
for more detailed information.

\start
Date: Mon, 7 Nov 2005 10:54:03 -0500
From: Bill Page
To: Tim Daly
Subject: re: [fspace.spad] dvi file display

On November 7, 2005 10:53 AM Tim Daly wrote:
> 
> what source file?
> 

fspace.spad.pamphlet

\start
Date: Mon, 7 Nov 2005 11:45:44 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Couple of quick questions while I'm thinking of

you're semi-innovating here, which is a good thing.

re: bibtex

there is some prior art. see src/doc/axim.bib.pamphlet.
consider rewriting/redesigning/redoing it.

re: hyperlinks

hyperlinks are fine in pamphlet files, i think.
they'll cause us some dependency pain but they are worth it.

not sure how they will impact mathaction and pdf. needs to be investigated.

\start
Date: Mon, 7 Nov 2005 08:09:34 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Couple of quick questions while I'm thinking of them

--- Tim Daly wrote:

> you're semi-innovating here, which is a good thing.
> 
> re: bibtex
> 
> there is some prior art. see src/doc/axim.bib.pamphlet.
> consider rewriting/redesigning/redoing it.

I take it you're referring to this?:
http://wiki.axiom-developer.org/axiom--test--1/src/doc/AxiomBib

I think that's a little different from what I mean - that (as far as I
can tell) is a way for pamphlet files to reference other pamphlet
files.  That's good but not what I have in mind - I'm actually
referencing books and papers from external sources, more like a
research paper.  I guess you could say I'm trying to more or less make
this a paper which also happens to be an Axiom pamphlet and
implementation of the ideas under discussion, sort of like your
"literate journal" idea.  (I know that the idea there is mainly for the
research and implementation of new mathematical ideas, but I like the
format and it helps to organize my thinking.)  So this I guess would be
a UnitsandDimensions.bib file to go along with
UnitsandDimensions.pamphlet.  I doubt it would make sense to include it
in a global bib file, and if Axiom begins incorporating lots of papers
trying to maintain one huge bib file could get pretty hairy.

> re: hyperlinks
> 
> hyperlinks are fine in pamphlet files, i think.
> they'll cause us some dependency pain but they are worth it.

I think they hyperref package is pretty standard nowadays, for what
that's worth.  Or did you mean dependency pain in pamphlets referring
to each other?
 
> not sure how they will impact mathaction and pdf. needs to be
> investigated.

pdf at least should be no problem - I'm generating pdf now without too
much issue (a few odd warnings I don't really understand, but the
resulting pdf looks fine and seems to have working hyperlinks.)

\start
Date: Mon, 7 Nov 2005 11:13:53 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Couple of quick questions while I'm thinking of them

On November 7, 2005 10:49 AM C Y wrote:
> 
> Dunno if these relate to Mathaction, the pamphlet structure, or
> what exactly so I'll just throw them out:

Yes, they do relate to how pamphlets are implemented on
MathAction.

> 
> a)  I'm building a bibtex file that is specialized to the units
> and dimensions effort - how would this file be handled as
> 1) part of a MathAction rendering

On MathAction the bibtex file will have to be located in a place
where LaTeX will see it after weave is applied to the pamphlet.
This is similar to the problem of handling external 'ps' and
other graphic format files in the Axiom book pamphlets. To do
this it is necessary for me to setup what is in Zope terminology
is known as a LocalFile and make it part of the pamphlet folder
structure. I can help you to do this when you are ready to put
something on MathAction (soon I hope :).

> and 2) as part of the Axiom source tree if it makes it that far?

I think the answer is similar but simplier. It just needs to go
in a sub-directory of the directory where you decide you want to
keep the pamphlet file.

> Should it just be uploaded onto MathAction and the latex file
> will find it there, or is it a little more complicated?

Yes, and yes. :)

> 
> b)  I'm using the hyperref package with a few tweaks to things
> like color settings to provide things like a clickable table of 
> contents and active links to references - is this OK or is this
> something we don't want to do with pamphlet files?

hyperref works fine with pamphlet files on MathAction.

> I'm assuming we want a uniform look for pamphlet files so perhaps
> I could submit my proposed look for consideration?  Also, how will
> MathAction react to it?

Should be no problem. If there is, we will fix it so it works.

> I've been assuming the TeX distribution on the server is the full
> tetex, but perhaps I should check that assumption.

Yes it is a very recent tetex (actually pdtex) distribution.

\start
Date: Mon, 7 Nov 2005 11:32:19 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Couple of quick questions while I'm thinking of them

On November 7, 2005 11:10 AM C Y wrote:

> ...
> So this I guess would be a UnitsandDimensions.bib file to
> go along with UnitsandDimensions.pamphlet.  I doubt it would
> make sense to include it in a global bib file ...

I think this is an interesting question that I think must have
been addressed by the literate programming people at one time
or another.

Certainly there is no technical problem if we maintain the bib
file outside of the pamphlet file - the same way the external
graphics files are handled now.

It is tempting to suggest that all you need to do is include
the contents of your 'UnitsandDimensions.bib' file as a named
chunk in the pamphlet file. But the 'weave' operation applied
to a pamphlet file produces only a LaTeX file as output which
is then passed to LaTeX. If the bib file is a chunk in the
pamphlet file then there would also need to be an intermediate
'tangle' operation to extract it as a file for reference by
LaTeX. But that approach would mean in general a potentially
much more complex process to construct documents from pamphlet
files.

I think we (you?) should consult the literate programming
community and ask what is the recommended practice in the use
of bib files and noweb documents.

\start
Date: Mon, 7 Nov 2005 12:22:31 -0500
From: Tim Daly
To: Bill Page
Subject: re: [fspace.spad] dvi file display

\documentclass{article}
\usepackage{axiom}
\begin{document}
\title{\$SPAD/src/algebra fspace.spad}
\author{Manuel Bronstein}
\maketitle
\begin{abstract}
\end{abstract}
\eject
\tableofcontents
\eject
\section{category ES ExpressionSpace}
<<category ES ExpressionSpace>>=
)abbrev category ES ExpressionSpace
++ Category for domains on which operators can be applied
++ Author: Manuel Bronstein
++ Date Created: 22 March 1988
++ Date Last Updated: 27 May 1994
++ Description:
++ An expression space is a set which is closed under certain operators;
++ Keywords: operator, kernel, expression, space.
ExpressionSpace(): Category == Defn where
  N   ==> NonNegativeInteger
  K   ==> Kernel %
  OP  ==> BasicOperator
  SY  ==> Symbol
  PAREN  ==> "%paren"::SY
  BOX    ==> "%box"::SY
  DUMMYVAR ==> "%dummyVar"

  Defn ==> Join(OrderedSet, RetractableTo K,
                InnerEvalable(K, %), Evalable %) with
    elt          : (OP, %) -> %
      ++ elt(op,x) or op(x) applies the unary operator op to x.
    elt          : (OP, %, %) -> %
      ++ elt(op,x,y) or op(x, y) applies the binary operator op to x and y.
    elt          : (OP, %, %, %) -> %
      ++ elt(op,x,y,z) or op(x, y, z) applies the ternary operator op to x, y and z.
    elt          : (OP, %, %, %, %) -> %
      ++ elt(op,x,y,z,t) or op(x, y, z, t) applies the 4-ary operator op to x, y, z and t.
    elt          : (OP, List %) -> %
      ++ elt(op,[x1,...,xn]) or op([x1,...,xn]) applies the n-ary operator op to x1,...,xn.
    subst        : (%, Equation %) -> %
      ++ subst(f, k = g) replaces the kernel k by g formally in f.
    subst        : (%, List Equation %) -> %
      ++ subst(f, [k1 = g1,...,kn = gn]) replaces the kernels k1,...,kn
      ++ by g1,...,gn formally in f.
    subst        : (%, List K, List %) -> %
      ++ subst(f, [k1...,kn], [g1,...,gn]) replaces the kernels k1,...,kn
      ++ by g1,...,gn formally in f.
    box          : % -> %
      ++ box(f) returns f with a 'box' around it that prevents f from
      ++ being evaluated when operators are applied to it. For example,
      ++ \spad{log(1)} returns 0, but \spad{log(box 1)}
      ++ returns the formal kernel log(1).
    box          : List % -> %
      ++ box([f1,...,fn]) returns \spad{(f1,...,fn)} with a 'box'
      ++ around them that
      ++ prevents the fi from being evaluated when operators are applied to
      ++ them, and makes them applicable to a unary operator. For example,
      ++ \spad{atan(box [x, 2])} returns the formal kernel \spad{atan(x, 2)}.
    paren        : % -> %
      ++ paren(f) returns (f). This prevents f from
      ++ being evaluated when operators are applied to it. For example,
      ++ \spad{log(1)} returns 0, but \spad{log(paren 1)} returns the
      ++ formal kernel log((1)).
    paren        : List % -> %
      ++ paren([f1,...,fn]) returns \spad{(f1,...,fn)}. This
      ++ prevents the fi from being evaluated when operators are applied to
      ++ them, and makes them applicable to a unary operator. For example,
      ++ \spad{atan(paren [x, 2])} returns the formal
      ++ kernel \spad{atan((x, 2))}.
    distribute   : % -> %
      ++ distribute(f) expands all the kernels in f that are
      ++ formally enclosed by a \spadfunFrom{box}{ExpressionSpace}
      ++ or \spadfunFrom{paren}{ExpressionSpace} expression.
    distribute   : (%, %) -> %
      ++ distribute(f, g) expands all the kernels in f that contain g in their
      ++ arguments and that are formally
      ++ enclosed by a \spadfunFrom{box}{ExpressionSpace}
      ++ or a \spadfunFrom{paren}{ExpressionSpace} expression.
    height       : %  -> N
      ++ height(f) returns the highest nesting level appearing in f.
      ++ Constants have height 0. Symbols have height 1. For any
      ++ operator op and expressions f1,...,fn, \spad{op(f1,...,fn)} has
      ++ height equal to \spad{1 + max(height(f1),...,height(fn))}.
    mainKernel   : %  -> Union(K, "failed")
      ++ mainKernel(f) returns a kernel of f with maximum nesting level, or
      ++ if f has no kernels (i.e. f is a constant).
    kernels      : %  -> List K
      ++ kernels(f) returns the list of all the top-level kernels
      ++ appearing in f, but not the ones appearing in the arguments
      ++ of the top-level kernels.
    tower        : %  -> List K
      ++ tower(f) returns all the kernels appearing in f, no matter
      ++ what their levels are.
    operators    : %  -> List OP
      ++ operators(f) returns all the basic operators appearing in f,
      ++ no matter what their levels are.
    operator     : OP -> OP
      ++ operator(op) returns a copy of op with the domain-dependent
      ++ properties appropriate for %.
    belong?      : OP -> Boolean
      ++ belong?(op) tests if % accepts op as applicable to its
      ++ elements.
    is?          : (%, OP)     -> Boolean
      ++ is?(x, op) tests if x is a kernel and is its operator is op.
    is?          : (%, SY) -> Boolean
      ++ is?(x, s) tests if x is a kernel and is the name of its
      ++ operator is s.
    kernel       : (OP, %) -> %
      ++ kernel(op, x) constructs op(x) without evaluating it.
    kernel       : (OP, List %) -> %
      ++ kernel(op, [f1,...,fn]) constructs \spad{op(f1,...,fn)} without
      ++ evaluating it.
    map          : (% -> %, K) -> %
      ++ map(f, k) returns \spad{op(f(x1),...,f(xn))} where
      ++ \spad{k = op(x1,...,xn)}.
    freeOf?      : (%, %)  -> Boolean
      ++ freeOf?(x, y) tests if x does not contain any occurrence of y,
      ++ where y is a single kernel.
    freeOf?      : (%, SY) -> Boolean
      ++ freeOf?(x, s) tests if x does not contain any operator
      ++ whose name is s.
    eval         : (%, List SY, List(% -> %)) -> %
      ++ eval(x, [s1,...,sm], [f1,...,fm]) replaces
      ++ every \spad{si(a)} in x by \spad{fi(a)} for any \spad{a}.
    eval         : (%, List SY, List(List % -> %)) -> %
      ++ eval(x, [s1,...,sm], [f1,...,fm]) replaces
      ++ every \spad{si(a1,...,an)} in x by
      ++ \spad{fi(a1,...,an)} for any \spad{a1},...,\spad{an}.
    eval         : (%, SY, List % -> %) -> %
      ++ eval(x, s, f) replaces every \spad{s(a1,..,am)} in x
      ++ by \spad{f(a1,..,am)} for any \spad{a1},...,\spad{am}.
    eval         : (%, SY, % -> %) -> %
      ++ eval(x, s, f) replaces every \spad{s(a)} in x by \spad{f(a)}
      ++ for any \spad{a}.
    eval         : (%, List OP, List(% -> %)) -> %
      ++ eval(x, [s1,...,sm], [f1,...,fm]) replaces
      ++ every \spad{si(a)} in x by \spad{fi(a)} for any \spad{a}.
    eval         : (%, List OP, List(List % -> %)) -> %
      ++ eval(x, [s1,...,sm], [f1,...,fm]) replaces
      ++ every \spad{si(a1,...,an)} in x by
      ++ \spad{fi(a1,...,an)} for any \spad{a1},...,\spad{an}.
    eval         : (%, OP, List % -> %) -> %
      ++ eval(x, s, f) replaces every \spad{s(a1,..,am)} in x
      ++ by \spad{f(a1,..,am)} for any \spad{a1},...,\spad{am}.
    eval         : (%, OP, % -> %) -> %
      ++ eval(x, s, f) replaces every \spad{s(a)} in x by \spad{f(a)}
      ++ for any \spad{a}.
    if % has Ring then
      minPoly: K -> SparseUnivariatePolynomial %
        ++ minPoly(k) returns p such that \spad{p(k) = 0}.
      definingPolynomial: % -> %
        ++ definingPolynomial(x) returns an expression p such that
        ++ \spad{p(x) = 0}.
    if % has RetractableTo Integer then
      even?: % -> Boolean
        ++ even? x is true if x is an even integer.
      odd? : % -> Boolean
        ++ odd? x is true if x is an odd integer.

   add

-- the 7 functions not provided are:
--        kernels   minPoly   definingPolynomial
--        coerce:K -> %  eval:(%, List K, List %) -> %
--        subst:(%, List K, List %) -> %
--        eval:(%, List Symbol, List(List % -> %)) -> %

    allKernels: %      -> Set K
    listk     : %      -> List K
    allk      : List % -> Set K
    unwrap    : (List K, %) -> %
    okkernel  : (OP, List %) -> %
    mkKerLists: List Equation % -> Record(lstk: List K, lstv:List %)

    oppren := operator(PAREN)$CommonOperators()
    opbox  := operator(BOX)$CommonOperators()

    box(x:%)     == box [x]
    paren(x:%)   == paren [x]
    belong? op   == op = oppren or op = opbox
    listk f      == parts allKernels f
    tower f      == sort_! listk f
    allk l       == reduce("union", [allKernels f for f in l], {})
    operators f  == [operator k for k in listk f]
    height f     == reduce("max", [height k for k in kernels f], 0)
    freeOf?(x:%, s:SY)       == not member?(s, [name k for k in listk x])
    distribute x == unwrap([k for k in listk x | is?(k, oppren)], x)
    box(l:List %)                  == opbox l
    paren(l:List %)                == oppren l
    freeOf?(x:%, k:%)              == not member?(retract k, listk x)
    kernel(op:OP, arg:%)           == kernel(op, [arg])
    elt(op:OP, x:%)                == op [x]
    elt(op:OP, x:%, y:%)           == op [x, y]
    elt(op:OP, x:%, y:%, z:%)      == op [x, y, z]
    elt(op:OP, x:%, y:%, z:%, t:%) == op [x, y, z, t]
    eval(x:%, s:SY, f:List % -> %) == eval(x, [s], [f])
    eval(x:%, s:OP, f:List % -> %) == eval(x, [name s], [f])
    eval(x:%, s:SY, f:% -> %)      == eval(x, [s], [f first #1])
    eval(x:%, s:OP, f:% -> %)      == eval(x, [s], [f first #1])
    subst(x:%, e:Equation %)       == subst(x, [e])

    eval(x:%, ls:List OP, lf:List(% -> %)) ==
      eval(x, ls, [f first #1 for f in lf]$List(List % -> %))

    eval(x:%, ls:List SY, lf:List(% -> %)) ==
      eval(x, ls, [f first #1 for f in lf]$List(List % -> %))

    eval(x:%, ls:List OP, lf:List(List % -> %)) ==
      eval(x, [name s for s in ls]$List(SY), lf)

    map(fn, k) ==
      (l := [fn x for x in argument k]$List(%)) = argument k => k::%
      (operator k) l

    operator op ==
      is?(op, PAREN) => oppren
      is?(op, BOX) => opbox
      error "Unknown operator"

    mainKernel x ==
      empty?(l := kernels x) => "failed"
      n := height(k := first l)
      for kk in rest l repeat
        if height(kk) > n then
          n := height kk
          k := kk
      k

-- takes all the kernels except for the dummy variables, which are second
-- arguments of rootOf's, integrals, sums and products which appear only in
-- their first arguments
    allKernels f ==
      s := brace(l := kernels f)
      for k in l repeat
          t :=
              (u := property(operator k, DUMMYVAR)) case None =>
                  arg := argument k
                  s0  := remove_!(retract(second arg)@K, allKernels first arg)
                  arg := rest rest arg
                  n   := (u::None) pretend N
                  if n > 1 then arg := rest arg
                  union(s0, allk arg)
              allk argument k
          s := union(s, t)
      s

    kernel(op:OP, args:List %) ==
      not belong? op => error "Unknown operator"
      okkernel(op, args)

    okkernel(op, l) ==
      kernel(op, l, 1 + reduce("max", [height f for f in l], 0))$K :: %

    elt(op:OP, args:List %) ==
      not belong? op => error "Unknown operator"
      ((u := arity op) case N) and (#args ^= u::N)
                                    => error "Wrong number of arguments"
      (v := evaluate(op,args)$BasicOperatorFunctions1(%)) case % => v::%
      okkernel(op, args)

    retract f ==
      (k := mainKernel f) case "failed" => error "not a kernel"
      k::K::% ^= f => error "not a kernel"
      k::K

    retractIfCan f ==
      (k := mainKernel f) case "failed" => "failed"
      k::K::% ^= f => "failed"
      k

    is?(f:%, s:SY) ==
      (k := retractIfCan f) case "failed" => false
      is?(k::K, s)

    is?(f:%, op:OP) ==
      (k := retractIfCan f) case "failed" => false
      is?(k::K, op)

    unwrap(l, x) ==
      for k in reverse_! l repeat
        x := eval(x, k, first argument k)
      x

    distribute(x, y) ==
      ky := retract y
      unwrap([k for k in listk x |
              is?(k, "%paren"::SY) and member?(ky, listk(k::%))], x)

    -- in case of conflicting substitutions e.g. [x = a, x = b],
    -- the first one prevails.
    -- this is not part of the semantics of the function, but just
    -- a feature of this implementation.
    eval(f:%, leq:List Equation %) ==
      rec := mkKerLists leq
      eval(f, rec.lstk, rec.lstv)

    subst(f:%, leq:List Equation %) ==
      rec := mkKerLists leq
      subst(f, rec.lstk, rec.lstv)

    mkKerLists leq ==
      lk := empty()$List(K)
      lv := empty()$List(%)
      for eq in leq repeat
        (k := retractIfCan(lhs eq)@Union(K, "failed")) case "failed" =>
                          error "left hand side must be a single kernel"
        if not member?(k::K, lk) then
          lk := concat(k::K, lk)
          lv := concat(rhs eq, lv)
      [lk, lv]

    if % has RetractableTo Integer then
       intpred?: (%, Integer -> Boolean) -> Boolean

       even? x == intpred?(x, even?)
       odd? x  == intpred?(x, odd?)

       intpred?(x, pred?) ==
           (u := retractIfCan(x)@Union(Integer, "failed")) case Integer
                  and pred?(u::Integer)

@
\section{ES.lsp BOOTSTRAP}
{\bf ES} depends on a chain of files. We need to break this cycle to build
the algebra. So we keep a cached copy of the translated {\bf ES}
category which we can write into the {\bf MID} directory. We compile 
the lisp code and copy the {\bf ES.o} file to the {\bf OUT} directory.
This is eventually forcibly replaced by a recompiled version. 

Note that this code is not included in the generated catdef.spad file.

<<ES.lsp BOOTSTRAP>>=

(|/VERSIONCHECK| 2) 

(SETQ |ExpressionSpace;AL| (QUOTE NIL)) 

(DEFUN |ExpressionSpace| NIL
 (LET (#:G82344)
  (COND
   (|ExpressionSpace;AL|)
   (T
    (SETQ |ExpressionSpace;AL| (|ExpressionSpace;|)))))) 

(DEFUN |ExpressionSpace;| NIL
 (PROG (#1=#:G82342)
  (RETURN
   (PROG1 
    (LETT #1# 
     (|sublisV| 
      (PAIR 
       (QUOTE (#2=#:G82340 #3=#:G82341))
       (LIST (QUOTE (|Kernel| |$|)) (QUOTE (|Kernel| |$|))))
      (|Join|
       (|OrderedSet|)
       (|RetractableTo| (QUOTE #2#))
       (|InnerEvalable| (QUOTE #3#) (QUOTE |$|))
       (|Evalable| (QUOTE |$|))
       (|mkCategory|
        (QUOTE |domain|)
        (QUOTE (
         ((|elt| (|$| (|BasicOperator|) |$|)) T)
         ((|elt| (|$| (|BasicOperator|) |$| |$|)) T)
         ((|elt| (|$| (|BasicOperator|) |$| |$| |$|)) T)
         ((|elt| (|$| (|BasicOperator|) |$| |$| |$| |$|)) T)
         ((|elt| (|$| (|BasicOperator|) (|List| |$|))) T)
         ((|subst| (|$| |$| (|Equation| |$|))) T)
         ((|subst| (|$| |$| (|List| (|Equation| |$|)))) T)
         ((|subst| (|$| |$| (|List| (|Kernel| |$|)) (|List| |$|))) T)
         ((|box| (|$| |$|)) T)
         ((|box| (|$| (|List| |$|))) T)
         ((|paren| (|$| |$|)) T)
         ((|paren| (|$| (|List| |$|))) T)
         ((|distribute| (|$| |$|)) T)
         ((|distribute| (|$| |$| |$|)) T)
         ((|height| ((|NonNegativeInteger|) |$|)) T)
         ((|mainKernel| ((|Union| (|Kernel| |$|) "failed") |$|)) T)
         ((|kernels| ((|List| (|Kernel| |$|)) |$|)) T)
         ((|tower| ((|List| (|Kernel| |$|)) |$|)) T)
         ((|operators| ((|List| (|BasicOperator|)) |$|)) T)
         ((|operator| ((|BasicOperator|) (|BasicOperator|))) T)
         ((|belong?| ((|Boolean|) (|BasicOperator|))) T)
         ((|is?| ((|Boolean|) |$| (|BasicOperator|))) T)
         ((|is?| ((|Boolean|) |$| (|Symbol|))) T)
         ((|kernel| (|$| (|BasicOperator|) |$|)) T)
         ((|kernel| (|$| (|BasicOperator|) (|List| |$|))) T)
         ((|map| (|$| (|Mapping| |$| |$|) (|Kernel| |$|))) T)
         ((|freeOf?| ((|Boolean|) |$| |$|)) T)
         ((|freeOf?| ((|Boolean|) |$| (|Symbol|))) T)
         ((|eval| (|$| |$| (|List| (|Symbol|)) (|List| (|Mapping| |$| |$|))))
           T)
         ((|eval| (|$| |$| (|List| (|Symbol|))
                           (|List| (|Mapping| |$| (|List| |$|)))))
           T)
         ((|eval| (|$| |$| (|Symbol|) (|Mapping| |$| (|List| |$|)))) T)
         ((|eval| (|$| |$| (|Symbol|) (|Mapping| |$| |$|))) T)
         ((|eval| (|$| |$| (|List| (|BasicOperator|))
                                   (|List| (|Mapping| |$| |$|)))) 
           T)
         ((|eval| (|$| |$| (|List| (|BasicOperator|))
                           (|List| (|Mapping| |$| (|List| |$|)))))
           T)
         ((|eval| (|$| |$| (|BasicOperator|) (|Mapping| |$| (|List| |$|)))) T)
         ((|eval| (|$| |$| (|BasicOperator|) (|Mapping| |$| |$|))) T)
         ((|minPoly| ((|SparseUnivariatePolynomial| |$|) (|Kernel| |$|)))
          (|has| |$| (|Ring|)))
         ((|definingPolynomial| (|$| |$|)) (|has| |$| (|Ring|)))
         ((|even?| ((|Boolean|) |$|))
          (|has| |$| (|RetractableTo| (|Integer|))))
         ((|odd?| ((|Boolean|) |$|))
          (|has| |$| (|RetractableTo| (|Integer|))))))
       NIL
       (QUOTE (
        (|Boolean|)
        (|SparseUnivariatePolynomial| |$|)
        (|Kernel| |$|)
        (|BasicOperator|)
        (|List| (|BasicOperator|))
        (|List| (|Mapping| |$| (|List| |$|)))
        (|List| (|Mapping| |$| |$|))
        (|Symbol|)
        (|List| (|Symbol|))
        (|List| |$|)
        (|List| (|Kernel| |$|))
        (|NonNegativeInteger|)
        (|List| (|Equation| |$|))
        (|Equation| |$|)))
       NIL)))
     |ExpressionSpace|)
   (SETELT #1# 0 (QUOTE (|ExpressionSpace|))))))) 

(MAKEPROP (QUOTE |ExpressionSpace|) (QUOTE NILADIC) T) 
@
\section{ES-.lsp BOOTSTRAP}
{\bf ES-} depends on {\bf ES}. We need to break this cycle to build
the algebra. So we keep a cached copy of the translated {\bf ES-}
category which we can write into the {\bf MID} directory. We compile 
the lisp code and copy the {\bf ES-.o} file to the {\bf OUT} directory.
This is eventually forcibly replaced by a recompiled version. 

Note that this code is not included in the generated catdef.spad file.

<<ES-.lsp BOOTSTRAP>>=

(|/VERSIONCHECK| 2) 

(DEFUN |ES-;box;2S;1| (|x| |$|) (SPADCALL (LIST |x|) (QREFELT |$| 16))) 

(DEFUN |ES-;paren;2S;2| (|x| |$|) (SPADCALL (LIST |x|) (QREFELT |$| 18))) 

(DEFUN |ES-;belong?;BoB;3| (|op| |$|)
 (COND
  ((SPADCALL |op| (QREFELT |$| 13) (QREFELT |$| 21)) (QUOTE T))
  ((QUOTE T) (SPADCALL |op| (QREFELT |$| 14) (QREFELT |$| 21))))) 

(DEFUN |ES-;listk| (|f| |$|)
 (SPADCALL (|ES-;allKernels| |f| |$|) (QREFELT |$| 25))) 

(DEFUN |ES-;tower;SL;5| (|f| |$|)
 (SPADCALL (|ES-;listk| |f| |$|) (QREFELT |$| 26))) 

(DEFUN |ES-;allk| (|l| |$|)
 (PROG (#1=#:G82361 |f| #2=#:G82362)
  (RETURN
   (SEQ
    (SPADCALL
     (ELT |$| 30)
     (PROGN
      (LETT #1# NIL |ES-;allk|)
      (SEQ
       (LETT |f| NIL |ES-;allk|)
       (LETT #2# |l| |ES-;allk|)
      G190
       (COND
        ((OR (ATOM #2#) 
             (PROGN (LETT |f| (CAR #2#) |ES-;allk|) NIL))
          (GO G191)))
       (SEQ
        (EXIT
         (LETT #1# (CONS (|ES-;allKernels| |f| |$|) #1#) |ES-;allk|)))
       (LETT #2# (CDR #2#) |ES-;allk|)
       (GO G190)
      G191
       (EXIT (NREVERSE0 #1#))))
     (SPADCALL NIL (QREFELT |$| 29))
     (QREFELT |$| 33)))))) 

(DEFUN |ES-;operators;SL;7| (|f| |$|)
 (PROG (#1=#:G82365 |k| #2=#:G82366)
  (RETURN
   (SEQ
    (PROGN
     (LETT #1# NIL |ES-;operators;SL;7|)
     (SEQ
      (LETT |k| NIL |ES-;operators;SL;7|)
      (LETT #2# (|ES-;listk| |f| |$|) |ES-;operators;SL;7|)
     G190
      (COND
       ((OR (ATOM #2#)
            (PROGN (LETT |k| (CAR #2#) |ES-;operators;SL;7|) NIL))
         (GO G191)))
      (SEQ
       (EXIT
        (LETT #1# 
          (CONS (SPADCALL |k| (QREFELT |$| 35)) #1#)
          |ES-;operators;SL;7|)))
      (LETT #2# (CDR #2#) |ES-;operators;SL;7|)
      (GO G190)
     G191
      (EXIT (NREVERSE0 #1#)))))))) 

(DEFUN |ES-;height;SNni;8| (|f| |$|)
 (PROG (#1=#:G82371 |k| #2=#:G82372)
  (RETURN
   (SEQ
    (SPADCALL (ELT |$| 41)
     (PROGN 
      (LETT #1# NIL |ES-;height;SNni;8|)
      (SEQ
       (LETT |k| NIL |ES-;height;SNni;8|)
       (LETT #2# (SPADCALL |f| (QREFELT |$| 38)) |ES-;height;SNni;8|)
      G190
       (COND
        ((OR (ATOM #2#) 
             (PROGN (LETT |k| (CAR #2#) |ES-;height;SNni;8|) NIL))
          (GO G191)))
       (SEQ
        (EXIT
         (LETT #1# 
          (CONS (SPADCALL |k| (QREFELT |$| 40)) #1#)
          |ES-;height;SNni;8|)))
       (LETT #2# (CDR #2#) |ES-;height;SNni;8|)
       (GO G190)
      G191
       (EXIT (NREVERSE0 #1#))))
     0 
     (QREFELT |$| 44)))))) 

(DEFUN |ES-;freeOf?;SSB;9| (|x| |s| |$|)
 (PROG (#1=#:G82377 |k| #2=#:G82378)
  (RETURN
   (SEQ
    (COND
     ((SPADCALL |s|
       (PROGN
        (LETT #1# NIL |ES-;freeOf?;SSB;9|)
        (SEQ
         (LETT |k| NIL |ES-;freeOf?;SSB;9|)
         (LETT #2# (|ES-;listk| |x| |$|) |ES-;freeOf?;SSB;9|)
        G190
         (COND
          ((OR (ATOM #2#)
               (PROGN (LETT |k| (CAR #2#) |ES-;freeOf?;SSB;9|) NIL))
            (GO G191)))
         (SEQ
          (EXIT
           (LETT #1#
             (CONS (SPADCALL |k| (QREFELT |$| 46)) #1#)
             |ES-;freeOf?;SSB;9|)))
         (LETT #2# (CDR #2#) |ES-;freeOf?;SSB;9|)
         (GO G190)
        G191
         (EXIT (NREVERSE0 #1#))))
       (QREFELT |$| 48))
         (QUOTE NIL))
     ((QUOTE T) (QUOTE T))))))) 

(DEFUN |ES-;distribute;2S;10| (|x| |$|)
 (PROG (#1=#:G82381 |k| #2=#:G82382)
  (RETURN
   (SEQ
    (|ES-;unwrap|
     (PROGN
      (LETT #1# NIL |ES-;distribute;2S;10|)
      (SEQ 
       (LETT |k| NIL |ES-;distribute;2S;10|)
       (LETT #2# (|ES-;listk| |x| |$|) |ES-;distribute;2S;10|)
      G190
       (COND
        ((OR (ATOM #2#)
             (PROGN (LETT |k| (CAR #2#) |ES-;distribute;2S;10|) NIL))
         (GO G191)))
       (SEQ
        (EXIT
         (COND
          ((SPADCALL |k| (QREFELT |$| 13) (QREFELT |$| 50))
           (LETT #1# (CONS |k| #1#) |ES-;distribute;2S;10|)))))
       (LETT #2# (CDR #2#) |ES-;distribute;2S;10|)
       (GO G190)
       G191
       (EXIT (NREVERSE0 #1#))))
     |x|
     |$|))))) 

(DEFUN |ES-;box;LS;11| (|l| |$|)
 (SPADCALL (QREFELT |$| 14) |l| (QREFELT |$| 52))) 

(DEFUN |ES-;paren;LS;12| (|l| |$|)
 (SPADCALL (QREFELT |$| 13) |l| (QREFELT |$| 52))) 

(DEFUN |ES-;freeOf?;2SB;13| (|x| |k| |$|)
 (COND
  ((SPADCALL
     (SPADCALL |k| (QREFELT |$| 56))
     (|ES-;listk| |x| |$|)
     (QREFELT |$| 57))
    (QUOTE NIL))
  ((QUOTE T) (QUOTE T)))) 

(DEFUN |ES-;kernel;Bo2S;14| (|op| |arg| |$|)
 (SPADCALL |op| (LIST |arg|) (QREFELT |$| 59))) 

(DEFUN |ES-;elt;Bo2S;15| (|op| |x| |$|)
 (SPADCALL |op| (LIST |x|) (QREFELT |$| 52))) 

(DEFUN |ES-;elt;Bo3S;16| (|op| |x| |y| |$|)
 (SPADCALL |op| (LIST |x| |y|) (QREFELT |$| 52))) 

(DEFUN |ES-;elt;Bo4S;17| (|op| |x| |y| |z| |$|)
 (SPADCALL |op| (LIST |x| |y| |z|) (QREFELT |$| 52))) 

(DEFUN |ES-;elt;Bo5S;18| (|op| |x| |y| |z| |t| |$|)
 (SPADCALL |op| (LIST |x| |y| |z| |t|) (QREFELT |$| 52))) 

(DEFUN |ES-;eval;SSMS;19| (|x| |s| |f| |$|)
 (SPADCALL |x| (LIST |s|) (LIST |f|) (QREFELT |$| 67))) 

(DEFUN |ES-;eval;SBoMS;20| (|x| |s| |f| |$|)
 (SPADCALL |x| 
  (LIST (SPADCALL |s| (QREFELT |$| 69)))
  (LIST |f|)
  (QREFELT |$| 67))) 

(DEFUN |ES-;eval;SSMS;21| (|x| |s| |f| |$|)
 (SPADCALL |x| 
  (LIST |s|)
  (LIST (CONS (FUNCTION |ES-;eval;SSMS;21!0|) (VECTOR |f| |$|)))
  (QREFELT |$| 67))) 

(DEFUN |ES-;eval;SSMS;21!0| (|#1| |$$|)
  (SPADCALL
   (SPADCALL |#1| (QREFELT (QREFELT |$$| 1) 72))
   (QREFELT |$$| 0))) 

(DEFUN |ES-;eval;SBoMS;22| (|x| |s| |f| |$|)
 (SPADCALL |x| 
  (LIST |s|)
  (LIST (CONS (FUNCTION |ES-;eval;SBoMS;22!0|) (VECTOR |f| |$|)))
  (QREFELT |$| 75))) 

(DEFUN |ES-;eval;SBoMS;22!0| (|#1| |$$|)
 (SPADCALL
  (SPADCALL |#1| (QREFELT (QREFELT |$$| 1) 72))
  (QREFELT |$$| 0))) 

(DEFUN |ES-;subst;SES;23| (|x| |e| |$|)
 (SPADCALL |x| (LIST |e|) (QREFELT |$| 78))) 

(DEFUN |ES-;eval;SLLS;24| (|x| |ls| |lf| |$|)
 (PROG (#1=#:G82403 |f| #2=#:G82404)
  (RETURN
   (SEQ
    (SPADCALL |x| |ls|
     (PROGN
      (LETT #1# NIL |ES-;eval;SLLS;24|)
      (SEQ
       (LETT |f| NIL |ES-;eval;SLLS;24|)
       (LETT #2# |lf| |ES-;eval;SLLS;24|)
      G190
       (COND
        ((OR (ATOM #2#)
             (PROGN (LETT |f| (CAR #2#) |ES-;eval;SLLS;24|) NIL))
          (GO G191)))
       (SEQ
        (EXIT
         (LETT #1#
          (CONS (CONS (FUNCTION |ES-;eval;SLLS;24!0|) (VECTOR |f| |$|)) #1#)
          |ES-;eval;SLLS;24|)))
       (LETT #2# (CDR #2#) |ES-;eval;SLLS;24|)
       (GO G190)
      G191
       (EXIT (NREVERSE0 #1#))))
     (QREFELT |$| 75)))))) 

(DEFUN |ES-;eval;SLLS;24!0| (|#1| |$$|)
 (SPADCALL (SPADCALL |#1| (QREFELT (QREFELT |$$| 1) 72)) (QREFELT |$$| 0))) 

(DEFUN |ES-;eval;SLLS;25| (|x| |ls| |lf| |$|)
 (PROG (#1=#:G82407 |f| #2=#:G82408)
  (RETURN
   (SEQ
    (SPADCALL |x| |ls|
     (PROGN
      (LETT #1# NIL |ES-;eval;SLLS;25|)
      (SEQ
       (LETT |f| NIL |ES-;eval;SLLS;25|)
       (LETT #2# |lf| |ES-;eval;SLLS;25|)
      G190
       (COND
        ((OR (ATOM #2#)
             (PROGN (LETT |f| (CAR #2#) |ES-;eval;SLLS;25|) NIL))
          (GO G191)))
       (SEQ
        (EXIT
         (LETT #1# 
          (CONS (CONS (FUNCTION |ES-;eval;SLLS;25!0|) (VECTOR |f| |$|)) #1#)
          |ES-;eval;SLLS;25|)))
       (LETT #2# (CDR #2#) |ES-;eval;SLLS;25|)
       (GO G190)
      G191
       (EXIT (NREVERSE0 #1#))))
     (QREFELT |$| 67)))))) 

(DEFUN |ES-;eval;SLLS;25!0| (|#1| |$$|)
 (SPADCALL (SPADCALL |#1| (QREFELT (QREFELT |$$| 1) 72)) (QREFELT |$$| 0))) 

(DEFUN |ES-;eval;SLLS;26| (|x| |ls| |lf| |$|)
 (PROG (#1=#:G82412 |s| #2=#:G82413)
  (RETURN
   (SEQ
    (SPADCALL |x|
     (PROGN
      (LETT #1# NIL |ES-;eval;SLLS;26|)
      (SEQ
       (LETT |s| NIL |ES-;eval;SLLS;26|)
       (LETT #2# |ls| |ES-;eval;SLLS;26|)
      G190
       (COND
        ((OR (ATOM #2#)
             (PROGN (LETT |s| (CAR #2#) |ES-;eval;SLLS;26|) NIL)
        ) (GO G191)))
       (SEQ
        (EXIT
         (LETT #1#
          (CONS (SPADCALL |s| (QREFELT |$| 69)) #1#)
          |ES-;eval;SLLS;26|)))
       (LETT #2# (CDR #2#) |ES-;eval;SLLS;26|)
       (GO G190)
      G191
       (EXIT (NREVERSE0 #1#))))
     |lf|
     (QREFELT |$| 67)))))) 

(DEFUN |ES-;map;MKS;27| (|fn| |k| |$|)
 (PROG (#1=#:G82428 |x| #2=#:G82429 |l|)
  (RETURN
   (SEQ
    (COND
     ((SPADCALL
       (LETT |l|
        (PROGN
         (LETT #1# NIL |ES-;map;MKS;27|)
         (SEQ
          (LETT |x| NIL |ES-;map;MKS;27|)
          (LETT #2# (SPADCALL |k| (QREFELT |$| 85)) |ES-;map;MKS;27|)
         G190
          (COND
           ((OR (ATOM #2#)
                (PROGN (LETT |x| (CAR #2#) |ES-;map;MKS;27|) NIL))
             (GO G191)))
          (SEQ
           (EXIT
            (LETT #1# (CONS (SPADCALL |x| |fn|) #1#) |ES-;map;MKS;27|)))
          (LETT #2# (CDR #2#) |ES-;map;MKS;27|)
          (GO G190)
         G191
          (EXIT (NREVERSE0 #1#))))
        |ES-;map;MKS;27|)
       (SPADCALL |k| (QREFELT |$| 85))
       (QREFELT |$| 86))
      (SPADCALL |k| (QREFELT |$| 87)))
      ((QUOTE T)
        (SPADCALL (SPADCALL |k| (QREFELT |$| 35)) |l| (QREFELT |$| 52)))))))) 

(DEFUN |ES-;operator;2Bo;28| (|op| |$|)
 (COND
  ((SPADCALL |op| (SPADCALL "%paren" (QREFELT |$| 9)) (QREFELT |$| 89))
    (QREFELT |$| 13))
  ((SPADCALL |op| (SPADCALL "%box" (QREFELT |$| 9)) (QREFELT |$| 89))
    (QREFELT |$| 14))
  ((QUOTE T) (|error| "Unknown operator")))) 

(DEFUN |ES-;mainKernel;SU;29| (|x| |$|)
 (PROG (|l| |kk| #1=#:G82445 |n| |k|)
  (RETURN
   (SEQ
    (COND
     ((NULL (LETT |l| (SPADCALL |x| (QREFELT |$| 38)) |ES-;mainKernel;SU;29|))
       (CONS 1 "failed"))
     ((QUOTE T)
       (SEQ 
        (LETT |n|
         (SPADCALL
          (LETT |k| (|SPADfirst| |l|) |ES-;mainKernel;SU;29|)
          (QREFELT |$| 40))
         |ES-;mainKernel;SU;29|)
        (SEQ
         (LETT |kk| NIL |ES-;mainKernel;SU;29|)
         (LETT #1# (CDR |l|) |ES-;mainKernel;SU;29|)
         G190
         (COND
          ((OR (ATOM #1#)
               (PROGN (LETT |kk| (CAR #1#) |ES-;mainKernel;SU;29|) NIL))
            (GO G191)))
         (SEQ
          (EXIT
           (COND 
            ((|<| |n| (SPADCALL |kk| (QREFELT |$| 40)))
             (SEQ
              (LETT |n|
               (SPADCALL |kk| (QREFELT |$| 40))
               |ES-;mainKernel;SU;29|)
              (EXIT
               (LETT |k| |kk| |ES-;mainKernel;SU;29|)))))))
         (LETT #1# (CDR #1#) |ES-;mainKernel;SU;29|)
         (GO G190)
        G191
         (EXIT NIL))
        (EXIT (CONS 0 |k|))))))))) 

(DEFUN |ES-;allKernels| (|f| |$|)
 (PROG (|l| |k| #1=#:G82458 |u| |s0| |n| |arg| |t| |s|)
  (RETURN
   (SEQ
    (LETT |s|
     (SPADCALL
      (LETT |l| (SPADCALL |f| (QREFELT |$| 38)) |ES-;allKernels|)
      (QREFELT |$| 29))
     |ES-;allKernels|)
    (SEQ
     (LETT |k| NIL |ES-;allKernels|)
     (LETT #1# |l| |ES-;allKernels|)
     G190
     (COND
      ((OR (ATOM #1#)
           (PROGN (LETT |k| (CAR #1#) |ES-;allKernels|) NIL))
         (GO G191)))
     (SEQ
      (LETT |t|
       (SEQ
        (LETT |u|
         (SPADCALL
          (SPADCALL |k| (QREFELT |$| 35))
          "%dummyVar"
          (QREFELT |$| 94))
         |ES-;allKernels|)
        (EXIT
         (COND
          ((QEQCAR |u| 0)
           (SEQ
            (LETT |arg| (SPADCALL |k| (QREFELT |$| 85)) |ES-;allKernels|)
            (LETT |s0|
             (SPADCALL
              (SPADCALL (SPADCALL |arg| (QREFELT |$| 95)) (QREFELT |$| 56))
              (|ES-;allKernels| (|SPADfirst| |arg|) |$|)
              (QREFELT |$| 96))
             |ES-;allKernels|)
            (LETT |arg| (CDR (CDR |arg|)) |ES-;allKernels|)
            (LETT |n| (QCDR |u|) |ES-;allKernels|)
            (COND ((|<| 1 |n|) (LETT |arg| (CDR |arg|) |ES-;allKernels|)))
            (EXIT (SPADCALL |s0| (|ES-;allk| |arg| |$|) (QREFELT |$| 30)))))
          ((QUOTE T)
            (|ES-;allk| (SPADCALL |k| (QREFELT |$| 85)) |$|)))))
       |ES-;allKernels|)
      (EXIT (LETT |s| (SPADCALL |s| |t| (QREFELT |$| 30)) |ES-;allKernels|)))
     (LETT #1# (CDR #1#) |ES-;allKernels|)
     (GO G190)
    G191
     (EXIT NIL))
    (EXIT |s|))))) 

(DEFUN |ES-;kernel;BoLS;31| (|op| |args| |$|)
 (COND
  ((NULL (SPADCALL |op| (QREFELT |$| 97))) (|error| "Unknown operator"))
  ((QUOTE T) (|ES-;okkernel| |op| |args| |$|)))) 

(DEFUN |ES-;okkernel| (|op| |l| |$|)
 (PROG (#1=#:G82465 |f| #2=#:G82466)
  (RETURN
   (SEQ
    (SPADCALL
     (SPADCALL |op| |l| 
      (|+| 1 
       (SPADCALL
        (ELT |$| 41)
        (PROGN
         (LETT #1# NIL |ES-;okkernel|)
         (SEQ
          (LETT |f| NIL |ES-;okkernel|)
          (LETT #2# |l| |ES-;okkernel|)
         G190
          (COND
           ((OR (ATOM #2#) 
                (PROGN (LETT |f| (CAR #2#) |ES-;okkernel|) NIL))
             (GO G191)))
          (SEQ
           (EXIT
            (LETT #1# 
             (CONS (SPADCALL |f| (QREFELT |$| 99)) #1#) |ES-;okkernel|)))
          (LETT #2# (CDR #2#) |ES-;okkernel|)
          (GO G190)
         G191
          (EXIT (NREVERSE0 #1#))))
        0 
        (QREFELT |$| 44)))
      (QREFELT |$| 100))
     (QREFELT |$| 87)))))) 

(DEFUN |ES-;elt;BoLS;33| (|op| |args| |$|)
 (PROG (|u| #1=#:G82482 |v|)
  (RETURN
   (SEQ
    (EXIT
     (COND
      ((NULL (SPADCALL |op| (QREFELT |$| 97))) (|error| "Unknown operator"))
      ((QUOTE T)
       (SEQ
        (SEQ
         (LETT |u| (SPADCALL |op| (QREFELT |$| 102)) |ES-;elt;BoLS;33|)
         (EXIT
          (COND
           ((QEQCAR |u| 0)
            (COND
             ((NULL (EQL (LENGTH |args|) (QCDR |u|)))
              (PROGN
               (LETT #1#
                (|error| "Wrong number of arguments")
                |ES-;elt;BoLS;33|)
               (GO #1#))))))))
        (LETT |v| (SPADCALL |op| |args| (QREFELT |$| 105)) |ES-;elt;BoLS;33|)
        (EXIT
         (COND
          ((QEQCAR |v| 0) (QCDR |v|))
          ((QUOTE T) (|ES-;okkernel| |op| |args| |$|))))))))
    #1#
    (EXIT #1#))))) 

(DEFUN |ES-;retract;SK;34| (|f| |$|)
 (PROG (|k|)
  (RETURN
   (SEQ
    (LETT |k| (SPADCALL |f| (QREFELT |$| 107)) |ES-;retract;SK;34|)
    (EXIT
     (COND
      ((OR (QEQCAR |k| 1) 
           (NULL 
            (SPADCALL 
             (SPADCALL (QCDR |k|) (QREFELT |$| 87))
             |f| 
             (QREFELT |$| 108))))
        (|error| "not a kernel"))
      ((QUOTE T) (QCDR |k|)))))))) 

(DEFUN |ES-;retractIfCan;SU;35| (|f| |$|)
 (PROG (|k|)
  (RETURN
   (SEQ
    (LETT |k| (SPADCALL |f| (QREFELT |$| 107)) |ES-;retractIfCan;SU;35|)
    (EXIT
     (COND
      ((OR (QEQCAR |k| 1) 
           (NULL
            (SPADCALL
             (SPADCALL (QCDR |k|) (QREFELT |$| 87))
             |f|
             (QREFELT |$| 108))))
        (CONS 1 "failed"))
      ((QUOTE T) |k|))))))) 

(DEFUN |ES-;is?;SSB;36| (|f| |s| |$|)
 (PROG (|k|)
  (RETURN
   (SEQ
    (LETT |k| (SPADCALL |f| (QREFELT |$| 111)) |ES-;is?;SSB;36|)
    (EXIT
     (COND
      ((QEQCAR |k| 1) (QUOTE NIL))
      ((QUOTE T) (SPADCALL (QCDR |k|) |s| (QREFELT |$| 112))))))))) 

(DEFUN |ES-;is?;SBoB;37| (|f| |op| |$|)
 (PROG (|k|)
  (RETURN
   (SEQ
    (LETT |k| (SPADCALL |f| (QREFELT |$| 111)) |ES-;is?;SBoB;37|)
    (EXIT
     (COND
      ((QEQCAR |k| 1) (QUOTE NIL))
      ((QUOTE T) (SPADCALL (QCDR |k|) |op| (QREFELT |$| 50))))))))) 

(DEFUN |ES-;unwrap| (|l| |x| |$|)
 (PROG (|k| #1=#:G82507)
  (RETURN
   (SEQ
    (SEQ
     (LETT |k| NIL |ES-;unwrap|)
     (LETT #1# (NREVERSE |l|) |ES-;unwrap|)
    G190
     (COND
      ((OR (ATOM #1#) 
           (PROGN (LETT |k| (CAR #1#) |ES-;unwrap|) NIL))
       (GO G191)))
     (SEQ
      (EXIT
       (LETT |x|
        (SPADCALL |x| |k|
         (|SPADfirst| (SPADCALL |k| (QREFELT |$| 85)))
         (QREFELT |$| 115))
        |ES-;unwrap|)))
     (LETT #1# (CDR #1#) |ES-;unwrap|)
     (GO G190)
    G191
    (EXIT NIL))
   (EXIT |x|))))) 

(DEFUN |ES-;distribute;3S;39| (|x| |y| |$|)
 (PROG (|ky| #1=#:G82512 |k| #2=#:G82513)
  (RETURN
   (SEQ
    (LETT |ky| (SPADCALL |y| (QREFELT |$| 56)) |ES-;distribute;3S;39|)
    (EXIT
     (|ES-;unwrap|
      (PROGN
       (LETT #1# NIL |ES-;distribute;3S;39|)
       (SEQ
        (LETT |k| NIL |ES-;distribute;3S;39|)
        (LETT #2# (|ES-;listk| |x| |$|) |ES-;distribute;3S;39|)
       G190
        (COND
         ((OR (ATOM #2#) 
              (PROGN (LETT |k| (CAR #2#) |ES-;distribute;3S;39|) NIL))
           (GO G191)))
        (SEQ
         (EXIT
          (COND
           ((COND
            ((SPADCALL |k|
              (SPADCALL "%paren" (QREFELT |$| 9))
              (QREFELT |$| 112))
             (SPADCALL |ky|
              (|ES-;listk| (SPADCALL |k| (QREFELT |$| 87)) |$|)
              (QREFELT |$| 57)))
            ((QUOTE T) (QUOTE NIL)))
            (LETT #1# (CONS |k| #1#) |ES-;distribute;3S;39|)))))
        (LETT #2# (CDR #2#) |ES-;distribute;3S;39|)
        (GO G190)
       G191
        (EXIT (NREVERSE0 #1#))))
      |x| 
      |$|)))))) 

(DEFUN |ES-;eval;SLS;40| (|f| |leq| |$|)
 (PROG (|rec|)
  (RETURN
   (SEQ
    (LETT |rec| (|ES-;mkKerLists| |leq| |$|) |ES-;eval;SLS;40|)
    (EXIT (SPADCALL |f| (QCAR |rec|) (QCDR |rec|) (QREFELT |$| 117))))))) 

(DEFUN |ES-;subst;SLS;41| (|f| |leq| |$|)
 (PROG (|rec|)
  (RETURN
   (SEQ
    (LETT |rec| (|ES-;mkKerLists| |leq| |$|) |ES-;subst;SLS;41|)
    (EXIT (SPADCALL |f| (QCAR |rec|) (QCDR |rec|) (QREFELT |$| 119))))))) 

(DEFUN |ES-;mkKerLists| (|leq| |$|)
 (PROG (|eq| #1=#:G82530 |k| |lk| |lv|)
  (RETURN
   (SEQ
    (LETT |lk| NIL |ES-;mkKerLists|)
    (LETT |lv| NIL |ES-;mkKerLists|)
    (SEQ
     (LETT |eq| NIL |ES-;mkKerLists|)
     (LETT #1# |leq| |ES-;mkKerLists|)
    G190
     (COND
      ((OR (ATOM #1#)
           (PROGN (LETT |eq| (CAR #1#) |ES-;mkKerLists|) NIL))
        (GO G191)))
     (SEQ
      (LETT |k|
       (SPADCALL (SPADCALL |eq| (QREFELT |$| 122)) (QREFELT |$| 111))
       |ES-;mkKerLists|)
      (EXIT
       (COND
        ((QEQCAR |k| 1) (|error| "left hand side must be a single kernel"))
        ((NULL (SPADCALL (QCDR |k|) |lk| (QREFELT |$| 57)))
          (SEQ
           (LETT |lk| (CONS (QCDR |k|) |lk|) |ES-;mkKerLists|)
           (EXIT
            (LETT |lv|
              (CONS (SPADCALL |eq| (QREFELT |$| 123)) |lv|)
              |ES-;mkKerLists|)))))))
     (LETT #1# (CDR #1#) |ES-;mkKerLists|)
     (GO G190)
    G191
     (EXIT NIL))
    (EXIT (CONS |lk| |lv|)))))) 

(DEFUN |ES-;even?;SB;43| (|x| |$|) (|ES-;intpred?| |x| (ELT |$| 125) |$|)) 

(DEFUN |ES-;odd?;SB;44| (|x| |$|) (|ES-;intpred?| |x| (ELT |$| 127) |$|)) 

(DEFUN |ES-;intpred?| (|x| |pred?| |$|)
 (PROG (|u|)
  (RETURN
   (SEQ
    (LETT |u| (SPADCALL |x| (QREFELT |$| 130)) |ES-;intpred?|)
    (EXIT
     (COND
      ((QEQCAR |u| 0) (SPADCALL (QCDR |u|) |pred?|))
      ((QUOTE T) (QUOTE NIL)))))))) 

(DEFUN |ExpressionSpace&| (|#1|)
 (PROG (|DV$1| |dv$| |$| |pv$|)
  (RETURN
   (PROGN
    (LETT |DV$1| (|devaluate| |#1|) . #1=(|ExpressionSpace&|))
    (LETT |dv$| (LIST (QUOTE |ExpressionSpace&|) |DV$1|) . #1#)
    (LETT |$| (GETREFV 131) . #1#)
    (QSETREFV |$| 0 |dv$|)
    (QSETREFV |$| 3
     (LETT |pv$| 
      (|buildPredVector| 0 0 
       (LIST 
        (|HasCategory| |#1| (QUOTE (|RetractableTo| (|Integer|))))
        (|HasCategory| |#1| (QUOTE (|Ring|)))))
      . #1#))
    (|stuffDomainSlots| |$|)
    (QSETREFV |$| 6 |#1|)
    (QSETREFV |$| 13
     (SPADCALL (SPADCALL "%paren" (QREFELT |$| 9)) (QREFELT |$| 12)))
    (QSETREFV |$| 14
     (SPADCALL (SPADCALL "%box" (QREFELT |$| 9)) (QREFELT |$| 12)))
    (COND
     ((|testBitVector| |pv$| 1)
       (PROGN 
        (QSETREFV |$| 126 (CONS (|dispatchFunction| |ES-;even?;SB;43|) |$|))
        (QSETREFV |$| 128 (CONS (|dispatchFunction| |ES-;odd?;SB;44|) |$|)))))
    |$|)))) 

(MAKEPROP
 (QUOTE |ExpressionSpace&|)
 (QUOTE |infovec|)
 (LIST (QUOTE #(
   NIL NIL NIL NIL NIL NIL (|local| |#1|) (|String|) (|Symbol|) (0 . |coerce|)
   (|BasicOperator|) (|CommonOperators|) (5 . |operator|) (QUOTE |oppren|)
   (QUOTE |opbox|) (|List| |$|) (10 . |box|) |ES-;box;2S;1| (15 . |paren|)
   |ES-;paren;2S;2| (|Boolean|) (20 . |=|) |ES-;belong?;BoB;3| (|List| 34)
   (|Set| 34) (26 . |parts|) (31 . |sort!|) (|List| 55) |ES-;tower;SL;5|
   (36 . |brace|) (41 . |union|) (|Mapping| 24 24 24) (|List| 24)
   (47 . |reduce|) (|Kernel| 6) (54 . |operator|) (|List| 10)
   |ES-;operators;SL;7| (59 . |kernels|) (|NonNegativeInteger|)
   (64 . |height|) (69 . |max|) (|Mapping| 39 39 39) (|List| 39)
   (75 . |reduce|) |ES-;height;SNni;8| (82 . |name|) (|List| 8)
   (87 . |member?|) |ES-;freeOf?;SSB;9| (93 . |is?|) |ES-;distribute;2S;10|
   (99 . |elt|) |ES-;box;LS;11| |ES-;paren;LS;12| (|Kernel| |$|)
   (105 . |retract|) (110 . |member?|) |ES-;freeOf?;2SB;13| (116 . |kernel|)
   |ES-;kernel;Bo2S;14| |ES-;elt;Bo2S;15| |ES-;elt;Bo3S;16| |ES-;elt;Bo4S;17|
   |ES-;elt;Bo5S;18| (|Mapping| |$| 15) (|List| 65) (122 . |eval|)
   |ES-;eval;SSMS;19| (129 . |name|) |ES-;eval;SBoMS;20| (|List| 6)
   (134 . |first|) (|Mapping| |$| |$|) |ES-;eval;SSMS;21| (139 . |eval|)
   |ES-;eval;SBoMS;22| (|List| 79) (146 . |subst|) (|Equation| |$|)
   |ES-;subst;SES;23| (|List| 73) |ES-;eval;SLLS;24| |ES-;eval;SLLS;25|
   |ES-;eval;SLLS;26| (152 . |argument|) (157 . |=|) (163 . |coerce|)
   |ES-;map;MKS;27| (168 . |is?|) |ES-;operator;2Bo;28|
   (|Union| 55 (QUOTE "failed")) |ES-;mainKernel;SU;29|
   (|Union| (|None|) (QUOTE "failed")) (174 . |property|) (180 . |second|)
   (185 . |remove!|) (191 . |belong?|) |ES-;kernel;BoLS;31| (196 . |height|)
   (201 . |kernel|) (|Union| 39 (QUOTE "failed")) (208 . |arity|)
   (|Union| 6 (QUOTE "failed")) (|BasicOperatorFunctions1| 6)
   (213 . |evaluate|) |ES-;elt;BoLS;33| (219 . |mainKernel|) (224 . |=|)
   |ES-;retract;SK;34| |ES-;retractIfCan;SU;35| (230 . |retractIfCan|)
   (235 . |is?|) |ES-;is?;SSB;36| |ES-;is?;SBoB;37| (241 . |eval|)
   |ES-;distribute;3S;39| (248 . |eval|) |ES-;eval;SLS;40| (255 . |subst|)
   |ES-;subst;SLS;41| (|Equation| 6) (262 . |lhs|) (267 . |rhs|) (|Integer|)
   (272 . |even?|) (277 . |even?|) (282 . |odd?|) (287 . |odd?|)
   (|Union| 124 (QUOTE "failed")) (292 . |retractIfCan|)))
   (QUOTE #(
    |tower| 297 |subst| 302 |retractIfCan| 314 |retract| 319 |paren| 324 
    |operators| 334 |operator| 339 |odd?| 344 |map| 349 |mainKernel| 355 
    |kernel| 360 |is?| 372 |height| 384 |freeOf?| 389 |even?| 401 |eval| 406 
    |elt| 461 |distribute| 497 |box| 508 |belong?| 518))
   (QUOTE NIL)
   (CONS
    (|makeByteWordVec2| 1 (QUOTE NIL))
    (CONS
     (QUOTE #())
     (CONS (QUOTE #())
      (|makeByteWordVec2| 130 (QUOTE 
       (1 8 0 7 9 1 11 10 8 12 1 6 0 15 16 1 6 0 15 18 2 10 20 0 0 21 1 24
 23 0 25 1 23 0 0 26 1 24 0 23 29 2 24 0 0 0 30 3 32 24 31 0 24 33 1 34 10
 0 35 1 6 27 0 38 1 34 39 0 40 2 39 0 0 0 41 3 43 39 42 0 39 44 1 34 8 0 46
 2 47 20 8 0 48 2 34 20 0 10 50 2 6 0 10 15 52 1 6 55 0 56 2 23 20 34 0 57 2
 6 0 10 15 59 3 6 0 0 47 66 67 1 10 8 0 69 1 71 6 0 72 3 6 0 0 36 66 75 2 6
 0 0 77 78 1 34 71 0 85 2 71 20 0 0 86 1 6 0 55 87 2 10 20 0 8 89 2 10 93 0
 7 94 1 71 6 0 95 2 24 0 34 0 96 1 6 20 10 97 1 6 39 0 99 3 34 0 10 71 39 100
 1 10 101 0 102 2 104 103 10 71 105 1 6 91 0 107 2 6 20 0 0 108 1 6 91 0 111
 2 34 20 0 8 112 3 6 0 0 55 0 115 3 6 0 0 27 15 117 3 6 0 0 27 15 119 1 121
 6 0 122 1 121 6 0 123 1 124 20 0 125 1 0 20 0 126 1 124 20 0 127 1 0 20 0
 128 1 6 129 0 130 1 0 27 0 28 2 0 0 0 77 120 2 0 0 0 79 80 1 0 91 0 110 1
 0 55 0 109 1 0 0 0 19 1 0 0 15 54 1 0 36 0 37 1 0 10 10 90 1 0 20 0 128 2
 0 0 73 55 88 1 0 91 0 92 2 0 0 10 15 98 2 0 0 10 0 60 2 0 20 0 8 113 2 0 20
 0 10 114 1 0 39 0 45 2 0 20 0 8 49 2 0 20 0 0 58 1 0 20 0 126 3 0 0 0 10 73
 76 3 0 0 0 36 66 84 3 0 0 0 10 65 70 3 0 0 0 36 81 82 3 0 0 0 8 65 68 3 0 0
 0 8 73 74 3 0 0 0 47 81 83 2 0 0 0 77 118 2 0 0 10 15 106 5 0 0 10 0 0 0 0
 64 3 0 0 10 0 0 62 4 0 0 10 0 0 0 63 2 0 0 10 0 61 2 0 0 0 0 116 1 0 0 0 51
 1 0 0 15 53 1 0 0 0 17 1 0 20 10 22)))))) (QUOTE |lookupComplete|))) 
@
\section{package ES1 ExpressionSpaceFunctions1}
<<package ES1 ExpressionSpaceFunctions1>>=
)abbrev package ES1 ExpressionSpaceFunctions1
++ Lifting of maps from expression spaces to kernels over them
++ Author: Manuel Bronstein
++ Date Created: 23 March 1988
++ Date Last Updated: 19 April 1991
++ Description:
++   This package allows a map from any expression space into any object
++   to be lifted to a kernel over the expression set, using a given
++   property of the operator of the kernel.
-- should not be exposed
ExpressionSpaceFunctions1(F:ExpressionSpace, S:Type): with
    map: (F -> S, String, Kernel F) -> S
      ++ map(f, p, k) uses the property p of the operator
      ++ of k, in order to lift f and apply it to k.

  == add
    --  prop  contains an evaluation function List S -> S
    map(F2S, prop, k) ==
      args := [F2S x for x in argument k]$List(S)
      (p := property(operator k, prop)) case None =>
                                  ((p::None) pretend (List S -> S)) args
      error "Operator does not have required property"

@
\section{package ES2 ExpressionSpaceFunctions2}
<<package ES2 ExpressionSpaceFunctions2>>=
)abbrev package ES2 ExpressionSpaceFunctions2
++ Lifting of maps from expression spaces to kernels over them
++ Author: Manuel Bronstein
++ Date Created: 23 March 1988
++ Date Last Updated: 19 April 1991
++ Description:
++ This package allows a mapping E -> F to be lifted to a kernel over E;
++ This lifting can fail if the operator of the kernel cannot be applied
++ in F; Do not use this package with E = F, since this may
++ drop some properties of the operators.
ExpressionSpaceFunctions2(E:ExpressionSpace, F:ExpressionSpace): with
    map: (E -> F, Kernel E) -> F
      ++ map(f, k) returns \spad{g = op(f(a1),...,f(an))} where
      ++ \spad{k = op(a1,...,an)}.
  == add
    map(f, k) ==
      (operator(operator k)$F) [f x for x in argument k]$List(F)

@
\section{category FS FunctionSpace}
<<category FS FunctionSpace>>=
)abbrev category FS FunctionSpace
++ Category for formal functions
++ Author: Manuel Bronstein
++ Date Created: 22 March 1988
++ Date Last Updated: 14 February 1994
++ Description:
++   A space of formal functions with arguments in an arbitrary
++   ordered set.
++ Keywords: operator, kernel, function.
FunctionSpace(R:OrderedSet): Category == Definition where
  OP ==> BasicOperator
  O  ==> OutputForm
  SY ==> Symbol
  N  ==> NonNegativeInteger
  Z  ==> Integer
  K  ==> Kernel %
  Q  ==> Fraction R
  PR ==> Polynomial R
  MP ==> SparseMultivariatePolynomial(R, K)
  QF==> PolynomialCategoryQuotientFunctions(IndexedExponents K,K,R,MP,%)

  ODD  ==> "odd"
  EVEN ==> "even"

  SPECIALDIFF  ==> "%specialDiff"
  SPECIALDISP  ==> "%specialDisp"
  SPECIALEQUAL ==> "%specialEqual"
  SPECIALINPUT ==> "%specialInput"

  Definition ==> Join(ExpressionSpace, RetractableTo SY, Patternable R,
                     FullyPatternMatchable R, FullyRetractableTo R) with
       ground?   : % -> Boolean
         ++ ground?(f) tests if f is an element of R.
       ground    : % -> R
         ++ ground(f) returns f as an element of R.
         ++ An error occurs if f is not an element of R.
       variables : %  -> List SY
         ++ variables(f) returns the list of all the variables of f.
       applyQuote: (SY, %) -> %
         ++ applyQuote(foo, x) returns \spad{'foo(x)}.
       applyQuote: (SY, %, %) -> %
         ++ applyQuote(foo, x, y) returns \spad{'foo(x,y)}.
       applyQuote: (SY, %, %, %) -> %
         ++ applyQuote(foo, x, y, z) returns \spad{'foo(x,y,z)}.
       applyQuote: (SY, %, %, %, %) -> %
         ++ applyQuote(foo, x, y, z, t) returns \spad{'foo(x,y,z,t)}.
       applyQuote: (SY, List %) -> %
         ++ applyQuote(foo, [x1,...,xn]) returns \spad{'foo(x1,...,xn)}.
       if R has ConvertibleTo InputForm then
         ConvertibleTo InputForm
         eval     : (%, SY) -> %
           ++ eval(f, foo) unquotes all the foo's in f.
         eval     : (%, List SY) -> %
           ++ eval(f, [foo1,...,foon]) unquotes all the \spad{fooi}'s in f.
         eval     : % -> %
           ++ eval(f) unquotes all the quoted operators in f.
         eval     : (%, OP, %, SY) -> %
           ++ eval(x, s, f, y) replaces every \spad{s(a)} in x by \spad{f(y)}
           ++ with \spad{y} replaced by \spad{a} for any \spad{a}.
         eval     : (%, List OP, List %, SY) -> %
           ++ eval(x, [s1,...,sm], [f1,...,fm], y) replaces every
           ++ \spad{si(a)} in x by \spad{fi(y)}
           ++ with \spad{y} replaced by \spad{a} for any \spad{a}.
       if R has SemiGroup then
         Monoid
         -- the following line is necessary because of a compiler bug
         "**"   : (%, N) -> %
           ++ x**n returns x * x * x * ... * x (n times).
         isTimes: % -> Union(List %, "failed")
           ++ isTimes(p) returns \spad{[a1,...,an]}
           ++ if \spad{p = a1*...*an} and \spad{n > 1}.
         isExpt : % -> Union(Record(var:K,exponent:Z),"failed")
           ++ isExpt(p) returns \spad{[x, n]} if \spad{p = x**n}
           ++ and \spad{n <> 0}.
       if R has Group then Group
       if R has AbelianSemiGroup then
         AbelianMonoid
         isPlus: % -> Union(List %, "failed")
           ++ isPlus(p) returns \spad{[m1,...,mn]}
           ++ if \spad{p = m1 +...+ mn} and \spad{n > 1}.
         isMult: % -> Union(Record(coef:Z, var:K),"failed")
           ++ isMult(p) returns \spad{[n, x]} if \spad{p = n * x}
           ++ and \spad{n <> 0}.
       if R has AbelianGroup then AbelianGroup
       if R has Ring then
         Ring
         RetractableTo PR
         PartialDifferentialRing SY
         FullyLinearlyExplicitRingOver R
         coerce    : MP -> %
           ++ coerce(p) returns p as an element of %.
         numer     : %  -> MP
           ++ numer(f) returns the
           ++ numerator of f viewed as a polynomial in the kernels over R
           ++ if R is an integral domain. If not, then numer(f) = f viewed
           ++ as a polynomial in the kernels over R.
           -- DO NOT change this meaning of numer!  MB 1/90
         numerator : % -> %
           ++ numerator(f) returns the numerator of \spad{f} converted to %.
         isExpt:(%,OP) -> Union(Record(var:K,exponent:Z),"failed")
           ++ isExpt(p,op) returns \spad{[x, n]} if \spad{p = x**n}
           ++ and \spad{n <> 0} and \spad{x = op(a)}.
         isExpt:(%,SY) -> Union(Record(var:K,exponent:Z),"failed")
           ++ isExpt(p,f) returns \spad{[x, n]} if \spad{p = x**n}
           ++ and \spad{n <> 0} and \spad{x = f(a)}.
         isPower   : % -> Union(Record(val:%,exponent:Z),"failed")
           ++ isPower(p) returns \spad{[x, n]} if \spad{p = x**n}
           ++ and \spad{n <> 0}.
         eval: (%, List SY, List N, List(% -> %)) -> %
           ++ eval(x, [s1,...,sm], [n1,...,nm], [f1,...,fm]) replaces
           ++ every \spad{si(a)**ni} in x by \spad{fi(a)} for any \spad{a}.
         eval: (%, List SY, List N, List(List % -> %)) -> %
           ++ eval(x, [s1,...,sm], [n1,...,nm], [f1,...,fm]) replaces
           ++ every \spad{si(a1,...,an)**ni} in x by \spad{fi(a1,...,an)}
           ++ for any a1,...,am.
         eval: (%, SY, N, List % -> %) -> %
           ++ eval(x, s, n, f) replaces every \spad{s(a1,...,am)**n} in x
           ++ by \spad{f(a1,...,am)} for any a1,...,am.
         eval: (%, SY, N, % -> %) -> %
           ++ eval(x, s, n, f) replaces every \spad{s(a)**n} in x
           ++ by \spad{f(a)} for any \spad{a}.
       if R has CharacteristicZero then CharacteristicZero
       if R has CharacteristicNonZero then CharacteristicNonZero
       if R has CommutativeRing then
         Algebra R
       if R has IntegralDomain then
         Field
         RetractableTo Fraction PR
         convert   : Factored % -> %
           ++ convert(f1\^e1 ... fm\^em) returns \spad{(f1)\^e1 ... (fm)\^em}
           ++ as an element of %, using formal kernels
           ++ created using a \spadfunFrom{paren}{ExpressionSpace}.
         denom     : %  -> MP
           ++ denom(f) returns the denominator of f viewed as a
           ++ polynomial in the kernels over R.
         denominator : % -> %
           ++ denominator(f) returns the denominator of \spad{f} converted to %.
         "/"       : (MP, MP) -> %
           ++ p1/p2 returns the quotient of p1 and p2 as an element of %.
         coerce    : Q  -> %
           ++ coerce(q) returns q as an element of %.
         coerce    : Polynomial Q -> %
           ++ coerce(p) returns p as an element of %.
         coerce    : Fraction Polynomial Q -> %
           ++ coerce(f) returns f as an element of %.
         univariate: (%, K) -> Fraction SparseUnivariatePolynomial %
           ++ univariate(f, k) returns f viewed as a univariate fraction in k.
         if R has RetractableTo Z then RetractableTo Fraction Z
   add
    import BasicOperatorFunctions1(%)

    -- these are needed in Ring only, but need to be declared here
    -- because of compiler bug: if they are declared inside the Ring
    -- case, then they are not visible inside the IntegralDomain case.
    smpIsMult : MP -> Union(Record(coef:Z, var:K),"failed")
    smpret    : MP -> Union(PR, "failed")
    smpeval   : (MP, List K, List %) -> %
    smpsubst  : (MP, List K, List %) -> %
    smpderiv  : (MP, SY) -> %
    smpunq    : (MP, List SY, Boolean) -> %
    kerderiv  : (K, SY)  -> %
    kderiv    : K -> List %
    opderiv   : (OP, N) -> List(List % -> %)
    smp2O     : MP -> O
    bestKernel: List K -> K
    worse?    : (K, K) -> Boolean
    diffArg   : (List %, OP, N) -> List %
    substArg  : (OP, List %, Z, %) -> %
    dispdiff  : List % -> Record(name:O, sub:O, arg:List O, level:N)
    ddiff     : List % -> O
    diffEval  : List % -> %
    dfeval    : (List %, K) -> %
    smprep    : (List SY, List N, List(List % -> %), MP) -> %
    diffdiff  : (List %, SY) -> %
    diffdiff0 : (List %, SY, %, K, List %) -> %
    subs      : (% -> %, K) -> %
    symsub    : (SY, Z) -> SY
    kunq      : (K, List SY, Boolean) -> %
    pushunq   : (List SY, List %) -> List %
    notfound  : (K -> %, List K, K) -> %

    equaldiff : (K,K)->Boolean
    debugA: (List % ,List %,Boolean) -> Boolean
    opdiff := operator("%diff"::SY)$CommonOperators()
    opquote := operator("applyQuote"::SY)$CommonOperators

    ground? x                == retractIfCan(x)@Union(R,"failed") case R
    ground  x                == retract x
    coerce(x:SY):%             == kernel(x)@K :: %
    retract(x:%):SY            == symbolIfCan(retract(x)@K)::SY
    applyQuote(s:SY, x:%)      == applyQuote(s, [x])
    applyQuote(s, x, y)        == applyQuote(s, [x, y])
    applyQuote(s, x, y, z)     == applyQuote(s, [x, y, z])
    applyQuote(s, x, y, z, t)  == applyQuote(s, [x, y, z, t])
    applyQuote(s:SY, l:List %) == opquote concat(s::%, l)
    belong? op                 == op = opdiff or op = opquote
    subs(fn, k) == kernel(operator k,[fn x for x in argument k]$List(%))

    operator op ==
      is?(op, "%diff"::SY) => opdiff
      is?(op, "%quote"::SY) => opquote
      error "Unknown operator"

    if R has ConvertibleTo InputForm then
      INP==>InputForm
      import MakeUnaryCompiledFunction(%, %, %)
      indiff: List % -> INP
      pint  : List INP-> INP
      differentiand: List % -> %

      differentiand l    == eval(first l, retract(second l)@K, third l)
      pint l  == convert concat(convert("D"::SY)@INP, l)
      indiff l ==
         r2:= convert([convert("::"::SY)@INP,convert(third l)@INP,convert("Symbol"::SY)@INP]@List INP)@INP
         pint [convert(differentiand l)@INP, r2] 
      eval(f:%, s:SY)            == eval(f, [s])
      eval(f:%, s:OP, g:%, x:SY) == eval(f, [s], [g], x)

      eval(f:%, ls:List OP, lg:List %, x:SY) ==
        eval(f, ls, [compiledFunction(g, x) for g in lg])

      setProperty(opdiff,SPECIALINPUT,indiff@(List % -> InputForm) pretend None)

    variables x ==
      l := empty()$List(SY)
      for k in tower x repeat
        if ((s := symbolIfCan k) case SY) then l := concat(s::SY, l)
      reverse_! l

    retractIfCan(x:%):Union(SY, "failed") ==
      (k := retractIfCan(x)@Union(K,"failed")) case "failed" => "failed"
      symbolIfCan(k::K)

    if R has Ring then
      import UserDefinedPartialOrdering(SY)

-- cannot use new()$Symbol because of possible re-instantiation
      gendiff := "%%0"::SY

      characteristic()    == characteristic()$R
      coerce(k:K):%       == k::MP::%
      symsub(sy, i)       == concat(string sy, convert(i)@String)::SY
      numerator x         == numer(x)::%
      eval(x:%, s:SY, n:N, f:% -> %)     == eval(x,[s],[n],[f first #1])
      eval(x:%, s:SY, n:N, f:List % -> %) == eval(x, [s], [n], [f])
      eval(x:%, l:List SY, f:List(List % -> %)) == eval(x, l, new(#l, 1), f)

      elt(op:OP, args:List %) ==
        unary? op and ((od? := has?(op, ODD)) or has?(op, EVEN)) and
          leadingCoefficient(numer first args) < 0 =>
            x := op(- first args)
            od? => -x
            x
        elt(op, args)$ExpressionSpace_&(%)

      eval(x:%, s:List SY, n:List N, l:List(% -> %)) ==
        eval(x, s, n, [f first #1 for f in l]$List(List % -> %))

      -- op(arg)**m ==> func(arg)**(m quo n) * op(arg)**(m rem n)
      smprep(lop, lexp, lfunc, p) ==
        (v := mainVariable p) case "failed" => p::%
        symbolIfCan(k := v::K) case SY => p::%
        g := (op := operator k)
           (arg := [eval(a,lop,lexp,lfunc) for a in argument k]$List(%))
        q := map(eval(#1::%, lop, lexp, lfunc),
                 univariate(p, k))$SparseUnivariatePolynomialFunctions2(MP, %)
        (n := position(name op, lop)) < minIndex lop => q g
        a:%  := 0
        f    := eval((lfunc.n) arg, lop, lexp, lfunc)
        e    := lexp.n
        while q ^= 0 repeat
          m  := degree q
          qr := divide(m, e)
          t1 := f ** (qr.quotient)::N
          t2 := g ** (qr.remainder)::N
          a  := a + leadingCoefficient(q) * t1 * t2
          q  := reductum q
        a

      dispdiff l ==
        s := second(l)::O
        t := third(l)::O
        a := argument(k := retract(first l)@K)
        is?(k, opdiff) =>
          rec := dispdiff a
          i   := position(s, rec.arg)
          rec.arg.i := t
          [rec.name,
             hconcat(rec.sub, hconcat(","::SY::O, (i+1-minIndex a)::O)),
                        rec.arg, (zero?(rec.level) => 0; rec.level + 1)]
        i   := position(second l, a)
        m   := [x::O for x in a]$List(O)
        m.i := t
        [name(operator k)::O, hconcat(","::SY::O, (i+1-minIndex a)::O),
                                             m, (empty? rest a => 1; 0)]

      ddiff l ==
        rec := dispdiff l
        opname :=
          zero?(rec.level) => sub(rec.name, rec.sub)
          differentiate(rec.name, rec.level)
        prefix(opname, rec.arg)

      substArg(op, l, i, g) ==
        z := copy l
        z.i := g
        kernel(op, z)


      diffdiff(l, x) ==
        f := kernel(opdiff, l)
        diffdiff0(l, x, f, retract(f)@K, empty())

      diffdiff0(l, x, expr, kd, done) ==
        op  := operator(k := retract(first l)@K)
        gg  := second l
        u   := third l
        arg := argument k
        ans:% := 0
        if (not member?(u,done)) and (ans := differentiate(u,x))^=0 then
          ans := ans * kernel(opdiff,
               [subst(expr, [kd], [kernel(opdiff, [first l, gg, gg])]),
                             gg, u])
        done := concat(gg, done)
        is?(k, opdiff) => ans + diffdiff0(arg, x, expr, k, done)
        for i in minIndex arg .. maxIndex arg for b in arg repeat
          if (not member?(b,done)) and (bp:=differentiate(b,x))^=0 then
            g   := symsub(gendiff, i)::%
            ans := ans + bp * kernel(opdiff, [subst(expr, [kd],
             [kernel(opdiff, [substArg(op, arg, i, g), gg, u])]), g, b])
        ans

      dfeval(l, g) ==
        eval(differentiate(first l, symbolIfCan(g)::SY), g, third l)

      diffEval l ==
        k:K
        g := retract(second l)@K
        ((u := retractIfCan(first l)@Union(K, "failed")) case "failed")
          or (u case K and symbolIfCan(k := u::K) case SY) => dfeval(l, g)
        op := operator k
        (ud := derivative op) case "failed" => 
             -- possible trouble 
             -- make sure it is a dummy var  
             dumm:%:=symsub(gendiff,1)::%
             ss:=subst(l.1,l.2=dumm)
             -- output(nl::OutputForm)$OutputPackage
             -- output("fixed"::OutputForm)$OutputPackage
             nl:=[ss,dumm,l.3]
             kernel(opdiff, nl)
        (n := position(second l,argument k)) < minIndex l => 
              dfeval(l,g)
        d := ud::List(List % -> %)
        eval((d.n)(argument k), g, third l)

      diffArg(l, op, i) ==
        n := i - 1 + minIndex l
        z := copy l
        z.n := g := symsub(gendiff, n)::%
        [kernel(op, z), g, l.n]

      opderiv(op, n) ==
--        one? n =>
        (n = 1) =>
          g := symsub(gendiff, n)::%
          [kernel(opdiff,[kernel(op, g), g, first #1])]
        [kernel(opdiff, diffArg(#1, op, i)) for i in 1..n]

      kderiv k ==
        zero?(n := #(args := argument k)) => empty()
        op := operator k
        grad :=
          (u := derivative op) case "failed" => opderiv(op, n)
          u::List(List % -> %)
        if #grad ^= n then grad := opderiv(op, n)
        [g args for g in grad]

    -- SPECIALDIFF contains a map (List %, Symbol) -> %
    -- it is used when the usual chain rule does not apply,
    -- for instance with implicit algebraics.
      kerderiv(k, x) ==
        (v := symbolIfCan(k)) case SY =>
          v::SY = x => 1
          0
        (fn := property(operator k, SPECIALDIFF)) case None =>
           ((fn::None) pretend ((List %, SY) -> %)) (argument k, x)
        +/[g * differentiate(y,x) for g in kderiv k for y in argument k]

      smpderiv(p, x) ==
        map(retract differentiate(#1::PR, x), p)::% +
         +/[differentiate(p,k)::% * kerderiv(k, x) for k in variables p]

      coerce(p:PR):% ==
        map(#1::%, #1::%, p)$PolynomialCategoryLifting(
                                      IndexedExponents SY, SY, R, PR, %)

      worse?(k1, k2) ==
        (u := less?(name operator k1,name operator k2)) case "failed" =>
          k1 < k2
        u::Boolean

      bestKernel l ==
        empty? rest l => first l
        a := bestKernel rest l
        worse?(first l, a) => a
        first l

      smp2O p ==
        (r:=retractIfCan(p)@Union(R,"failed")) case R =>r::R::OutputForm
        a :=
          userOrdered?() => bestKernel variables p
          mainVariable(p)::K
        outputForm(map(#1::%, univariate(p,
         a))$SparseUnivariatePolynomialFunctions2(MP, %), a::OutputForm)

      smpsubst(p, lk, lv) ==
        map(match(lk, lv, #1,
            notfound(subs(subst(#1, lk, lv), #1), lk, #1))$ListToMap(K,%),
             #1::%,p)$PolynomialCategoryLifting(IndexedExponents K,K,R,MP,%)

      smpeval(p, lk, lv) ==
        map(match(lk, lv, #1,
            notfound(map(eval(#1, lk, lv), #1), lk, #1))$ListToMap(K,%),
             #1::%,p)$PolynomialCategoryLifting(IndexedExponents K,K,R,MP,%)

-- this is called on k when k is not a member of lk
      notfound(fn, lk, k) ==
        empty? setIntersection(tower(f := k::%), lk) => f
        fn k

      if R has ConvertibleTo InputForm then
        pushunq(l, arg) ==
           empty? l => [eval a for a in arg]
           [eval(a, l) for a in arg]

        kunq(k, l, givenlist?) ==
          givenlist? and empty? l => k::%
          is?(k, opquote) and
            (member?(s:=retract(first argument k)@SY, l) or empty? l) =>
              interpret(convert(concat(convert(s)@InputForm,
                [convert a for a in pushunq(l, rest argument k)
                   ]@List(InputForm)))@InputForm)$InputFormFunctions1(%)
          (operator k) pushunq(l, argument k)

        smpunq(p, l, givenlist?) ==
          givenlist? and empty? l => p::%
          map(kunq(#1, l, givenlist?), #1::%,
            p)$PolynomialCategoryLifting(IndexedExponents K,K,R,MP,%)

      smpret p ==
        "or"/[symbolIfCan(k) case "failed" for k in variables p] =>
          "failed"
        map(symbolIfCan(#1)::SY::PR, #1::PR,
          p)$PolynomialCategoryLifting(IndexedExponents K, K, R, MP, PR)

      isExpt(x:%, op:OP) ==
        (u := isExpt x) case "failed" => "failed"
        is?((u::Record(var:K, exponent:Z)).var, op) => u
        "failed"

      isExpt(x:%, sy:SY) ==
        (u := isExpt x) case "failed" => "failed"
        is?((u::Record(var:K, exponent:Z)).var, sy) => u
        "failed"

      if R has RetractableTo Z then
          smpIsMult p ==
--            (u := mainVariable p) case K and one? degree(q:=univariate(p,u::K))
            (u := mainVariable p) case K and (degree(q:=univariate(p,u::K))=1)
              and zero?(leadingCoefficient reductum q)
                and ((r:=retractIfCan(leadingCoefficient q)@Union(R,"failed"))
                   case R)
                     and (n := retractIfCan(r::R)@Union(Z, "failed")) case Z =>
                       [n::Z, u::K]
            "failed"

      evaluate(opdiff, diffEval)

      debugA(a1,a2,t) == 
         -- uncomment for debugging
         -- output(hconcat [a1::OutputForm,a2::OutputForm,t::OutputForm])$OutputPackage
         t

      equaldiff(k1,k2) ==
        a1:=argument k1
        a2:=argument k2
        -- check the operator
        res:=operator k1 = operator k2 
        not res => debugA(a1,a2,res) 
        -- check the evaluation point
        res:= (a1.3 = a2.3)
        not res => debugA(a1,a2,res)
        -- check all the arguments
        res:= (a1.1 = a2.1) and (a1.2 = a2.2)
        res => debugA(a1,a2,res)
        -- check the substituted arguments
        (subst(a1.1,[retract(a1.2)@K],[a2.2]) = a2.1) => debugA(a1,a2,true)
        debugA(a1,a2,false)
      setProperty(opdiff,SPECIALEQUAL,
                          equaldiff@((K,K) -> Boolean) pretend None)
      setProperty(opdiff, SPECIALDIFF,
                          diffdiff@((List %, SY) -> %) pretend None)
      setProperty(opdiff, SPECIALDISP,
                              ddiff@(List % -> OutputForm) pretend None)

      if not(R has IntegralDomain) then
        mainKernel x         == mainVariable numer x
        kernels x            == variables numer x
        retract(x:%):R       == retract numer x
        retract(x:%):PR      == smpret(numer x)::PR
        retractIfCan(x:%):Union(R,  "failed") == retract numer x
        retractIfCan(x:%):Union(PR, "failed") == smpret numer x
        eval(x:%, lk:List K, lv:List %)  == smpeval(numer x, lk, lv)
        subst(x:%, lk:List K, lv:List %) == smpsubst(numer x, lk, lv)
        differentiate(x:%, s:SY)         == smpderiv(numer x, s)
        coerce(x:%):OutputForm           == smp2O numer x

        if R has ConvertibleTo InputForm then
          eval(f:%, l:List SY) == smpunq(numer f, l, true)
          eval f               == smpunq(numer f, empty(), false)

        eval(x:%, s:List SY, n:List N, f:List(List % -> %)) ==
          smprep(s, n, f, numer x)

        isPlus x ==
          (u := isPlus numer x) case "failed" => "failed"
          [p::% for p in u::List(MP)]

        isTimes x ==
          (u := isTimes numer x) case "failed" => "failed"
          [p::% for p in u::List(MP)]

        isExpt x ==
          (u := isExpt numer x) case "failed" => "failed"
          r := u::Record(var:K, exponent:NonNegativeInteger)
          [r.var, r.exponent::Z]

        isPower x ==
          (u := isExpt numer x) case "failed" => "failed"
          r := u::Record(var:K, exponent:NonNegativeInteger)
          [r.var::%, r.exponent::Z]

        if R has ConvertibleTo Pattern Z then
          convert(x:%):Pattern(Z) == convert numer x

        if R has ConvertibleTo Pattern Float then
          convert(x:%):Pattern(Float) == convert numer x

        if R has RetractableTo Z then
          isMult x == smpIsMult numer x

    if R has CommutativeRing then
      r:R * x:% == r::MP::% * x

    if R has IntegralDomain then
      par   : % -> %

      mainKernel x                    == mainVariable(x)$QF
      kernels x                       == variables(x)$QF
      univariate(x:%, k:K)            == univariate(x, k)$QF
      isPlus x                        == isPlus(x)$QF
      isTimes x                       == isTimes(x)$QF
      isExpt x                        == isExpt(x)$QF
      isPower x                       == isPower(x)$QF
      denominator x                   == denom(x)::%
      coerce(q:Q):%                   == (numer q)::MP / (denom q)::MP
      coerce(q:Fraction PR):%         == (numer q)::% / (denom q)::%
      coerce(q:Fraction Polynomial Q) == (numer q)::% / (denom q)::%
      retract(x:%):PR                == retract(retract(x)@Fraction(PR))
      retract(x:%):Fraction(PR) == smpret(numer x)::PR / smpret(denom x)::PR
      retract(x:%):R == (retract(numer x)@R exquo retract(denom x)@R)::R

      coerce(x:%):OutputForm ==
--        one?(denom x) => smp2O numer x
        ((denom x) = 1) => smp2O numer x
        smp2O(numer x) / smp2O(denom x)

      retractIfCan(x:%):Union(R, "failed") ==
        (n := retractIfCan(numer x)@Union(R, "failed")) case "failed" or
          (d := retractIfCan(denom x)@Union(R, "failed")) case "failed"
            or (r := n::R exquo d::R) case "failed" => "failed"
        r::R

      eval(f:%, l:List SY) ==
        smpunq(numer f, l, true) / smpunq(denom f, l, true)

      if R has ConvertibleTo InputForm then
        eval f ==
          smpunq(numer f, empty(), false) / smpunq(denom f, empty(), false)

        eval(x:%, s:List SY, n:List N, f:List(List % -> %)) ==
          smprep(s, n, f, numer x) / smprep(s, n, f, denom x)

      differentiate(f:%, x:SY) ==
        (smpderiv(numer f, x) * denom(f)::% -
          numer(f)::% * smpderiv(denom f, x))
            / (denom(f)::% ** 2)

      eval(x:%, lk:List K, lv:List %) ==
        smpeval(numer x, lk, lv) / smpeval(denom x, lk, lv)

      subst(x:%, lk:List K, lv:List %) ==
        smpsubst(numer x, lk, lv) / smpsubst(denom x, lk, lv)

      par x ==
        (r := retractIfCan(x)@Union(R, "failed")) case R => x
        paren x

      convert(x:Factored %):% ==
        par(unit x) * */[par(f.factor) ** f.exponent for f in factors x]

      retractIfCan(x:%):Union(PR, "failed") ==
        (u := retractIfCan(x)@Union(Fraction PR,"failed")) case "failed"
          => "failed"
        retractIfCan(u::Fraction(PR))

      retractIfCan(x:%):Union(Fraction PR, "failed") ==
        (n := smpret numer x) case "failed" => "failed"
        (d := smpret denom x) case "failed" => "failed"
        n::PR / d::PR

      coerce(p:Polynomial Q):% ==
        map(#1::%, #1::%,
           p)$PolynomialCategoryLifting(IndexedExponents SY, SY,
                                                     Q, Polynomial Q, %)

      if R has RetractableTo Z then
        coerce(x:Fraction Z):% == numer(x)::MP / denom(x)::MP

        isMult x ==
           (u := smpIsMult numer x) case "failed"
              or (v := retractIfCan(denom x)@Union(R, "failed")) case "failed"
                 or (w := retractIfCan(v::R)@Union(Z, "failed")) case "failed"
                     => "failed"
           r := u::Record(coef:Z, var:K)
           (q := r.coef exquo w::Z) case "failed" => "failed"
           [q::Z, r.var]

      if R has ConvertibleTo Pattern Z then
        convert(x:%):Pattern(Z) == convert(numer x) / convert(denom x)

      if R has ConvertibleTo Pattern Float then
        convert(x:%):Pattern(Float) ==
          convert(numer x) / convert(denom x)

@
\section{package FS2 FunctionSpaceFunctions2}
<<package FS2 FunctionSpaceFunctions2>>=
)abbrev package FS2 FunctionSpaceFunctions2
++ Lifting of maps to function spaces
++ Author: Manuel Bronstein
++ Date Created: 22 March 1988
++ Date Last Updated: 3 May 1994
++ Description:
++   This package allows a mapping R -> S to be lifted to a mapping
++   from a function space over R to a function space over S;
FunctionSpaceFunctions2(R, A, S, B): Exports == Implementation where
  R, S: Join(Ring, OrderedSet)
  A   : FunctionSpace R
  B   : FunctionSpace S

  K  ==> Kernel A
  P  ==> SparseMultivariatePolynomial(R, K)

  Exports ==> with
    map: (R -> S, A) -> B
      ++ map(f, a) applies f to all the constants in R appearing in \spad{a}.

  Implementation ==> add
    smpmap: (R -> S, P) -> B

    smpmap(fn, p) ==
      map(map(map(fn, #1), #1)$ExpressionSpaceFunctions2(A,B),fn(#1)::B,
        p)$PolynomialCategoryLifting(IndexedExponents K, K, R, P, B)

    if R has IntegralDomain then
      if S has IntegralDomain then
        map(f, x) == smpmap(f, numer x) / smpmap(f, denom x)
      else
        map(f, x) == smpmap(f, numer x) * (recip(smpmap(f, denom x))::B)
    else
      map(f, x) == smpmap(f, numer x)

@
\section{License}
<<license>>=
--Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
--All rights reserved.
--
--Redistribution and use in source and binary forms, with or without
--modification, are permitted provided that the following conditions are
--met:
--
--    - Redistributions of source code must retain the above copyright
--      notice, this list of conditions and the following disclaimer.
--
--    - Redistributions in binary form must reproduce the above copyright
--      notice, this list of conditions and the following disclaimer in
--      the documentation and/or other materials provided with the
--      distribution.
--
--    - Neither the name of The Numerical ALgorithms Group Ltd. nor the
--      names of its contributors may be used to endorse or promote products
--      derived from this software without specific prior written permission.
--
--THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
--IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
--TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
--PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
--OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
--EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
--PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
--PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
--LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
--NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
--SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
@
<<*>>=
<<license>>

-- SPAD files for the functional world should be compiled in the
-- following order:
--
--   op  kl  FSPACE  expr funcpkgs

<<category ES ExpressionSpace>>
<<package ES1 ExpressionSpaceFunctions1>>
<<package ES2 ExpressionSpaceFunctions2>>
<<category FS FunctionSpace>>
<<package FS2 FunctionSpaceFunctions2>>
@
\eject
\begin{thebibliography}{99}
\bibitem{1} nothing
\end{thebibliography}
\end{document}

\start
Date: Mon, 7 Nov 2005 12:23:01 -0500
From: Tim Daly
To: Bill Page
Subject: re: [fspace.spad] dvi file display

replace that text with the one i just sent you.
this update will go out as part of the next patch.
hopefully that fixes the problem.

\start
Date: Mon, 7 Nov 2005 12:29:27 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Couple of quick questions while I'm thinking of them

the bibtex file in src/doc is intended to be the standard place
where bibtex references from axiom reside. this keeps the bibtex
reference files from showing up all over the place.

it only references axiom files now because that's all i had at the time.

the idea of the bibtex file as a pamphlet file is that bibtex references
would be kept with annotations so people could figure out what the
reference was about (an abstract). that way people could expand the
annotations as well as give references. and people who wanted to know
what the reference was about but did not have the reference could read
the annotations.

the size of the file isn't an issue. the ability to manage the
references is an issue. if every pamphlet file has its own bibtex
and index files we'll have a hairball of files.

\start
Date: Mon, 7 Nov 2005 11:46:38 -0500
From: Bill Page
To: Kai Kaminski
Subject: RE: Good Tim

On November 7, 2005 10:10 AM Kai Kaminski wrote:

> 
> I don't feel like participating in the language arguments going
> on at the moment. Still I would like to voice my support for Tim's
> position in this matter.

Thank you for participating anyway. :)

> 
> In particular, I agree with him that BOOT is *not* higher-level
> than Lisp. There is not a single feature in Lisp that can't be
> embedded in Lisp with macros.

I expect you meant to write: 

"There is not a single feature in Boot that can't be embedded
in Lisp with macros."

That is certainly true but it is completely irrelevant. Before
we argue about when something is "higher-level" than something
else, I think we must first define what we mean by "higher-level".
This is difficult.

Perhaps we can agree that Spad is higher-level than Lisp? If
so then I can at least temporarily bypass the exact definition
of the language hierarchy and simply argue that Boot is closer
to Spad than Lisp and so the designation "higher-level" is
appropriate.

If you do not agree that Spad is higher-level than Lisp, then
I think we should talk more about Spad first before talking
about Boot.

> 
> I also agree with him that in open source "advocacy is
> volunteering". Hence I'm willing to start working on converting
> BOOT code to Lisp as soon as Tim tells me that he'll accept
> such patches.
> 

Converting Boot code to Lisp is trivial - just run the compiler.
That is the first step that Tim has already used in his recent
work to which I am objecting. After that, there is the matter of
removing the Boot compiler artefacts. But that is not enough.
If anything is to be converted to Lisp than it seems to me that
it must be converted to a form of Lisp which is at least as
intelligible as the original Boot code.

Of course we can also argue about what is "intelligible". In
this regard my proposed standard again would be Spad. So by
"intelligible" I mean that it must be easily understood by an
Axiom user who is fluent in Spad and may only know Lisp
"in theory", not by extensive practice.

\start
Date: Mon, 7 Nov 2005 08:49:37 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Couple of quick questions while I'm thinking of them

--- Tim Daly wrote:

> the bibtex file in src/doc is intended to be the standard place
> where bibtex references from axiom reside. this keeps the bibtex
> reference files from showing up all over the place.
> 
> it only references axiom files now because that's all i had at the
> time.

OK.  I'll look it over and try merging in my stuff.

> the idea of the bibtex file as a pamphlet file is that bibtex
> references would be kept with annotations so people could figure 
> out what the reference was about (an abstract). that way people 
> could expand the annotations as well as give references. and people
> who wanted to know what the reference was about but did not have the
> reference could read the annotations.

Hmm.  OK.  That's a little more extensive than my original bibliography
was going to be.  I'll go back and start summarizing each paper as I go
(or do you want the actual paper abstracts?)

> the size of the file isn't an issue. the ability to manage the
> references is an issue. if every pamphlet file has its own bibtex
> and index files we'll have a hairball of files.

OK.  Should we have some kind of indexing scheme that identifies which
pamphlet files a paper relates to?  Maybe bibtex itself has some
optional field for that, I'll have to look.

One problem I can forsee is the case where a pamphlet wants to include
in its bibliography papers or books it didn't directly reference in the
text itself.  There is an option for this but IIRC it's an all or
nothing scheme - you can either include JUST the papers you reference
or the entire contents of the bibliography. (Eeek)  I suppose the
simple solution is to just include a "For Further Reading" section that
references everything the rest of the text didn't get.

\start
Date: Mon, 7 Nov 2005 12:06:01 -0500
From: Bill Page
To: Tim Daly
Subject: re: [fspace.spad] dvi file display

Tim,

On November 7, 2005 12:23 PM you wrote:
> 
> replace that text with the one i just sent you.
> this update will go out as part of the next patch.
> hopefully that fixes the problem.
> 

Thanks Tim. That looks much better and does fix the problem for
me using MikTeX Yap on Windows.

Does the 'dvi' link at

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FspaceSpad

work for you now William?

\start
Date: Mon, 07 Nov 2005 12:12:28 -0500
From: William Sit
To: Martin Rubey
Subject: Re: Terms of Surrender (was: BAD tim)

Martin Rubey wrote:
> 
> William Sit writes:
 
> > What we need is a development kit with tools to set breaks and
> > examine Axiom variables, displayed in mathematical notations, not
> > Lisp data structures down to the nitty gritty.
 
> You do know about
> 
> )trace COMBF )math
> 
> (does not work with EXPR, unfortunately. Bind Stack overflow, there is an
> infinite loop somewhere.)
> 
> Martin

Thanks, Martin. I didn't know and will try that.

But then why did Tim think (or at least give the impression) high level
debugging was quite difficult to do?

\start
Date: Mon, 7 Nov 2005 13:07:37 -0500
From: Tim Daly
To: Richard Fateman
Subject: integration server

Richard,

Axiom has a wiki website (page.axiom-developer.org) where we are
hosting not only axiom but other computer algebra systems.

You run the tilu website.

It would be a useful extension to the systems we host to enable
them to use your database lookup for computation. I hesitate
to point our server software at your server however as this
could cause a big increase in traffic. Plus the web interface
is awkward for automation.

Is the database available? Could we set up a local copy on
axiom-developer.org?

\start
Date: Mon, 7 Nov 2005 12:19:00 -0500
From: Bill Page
To: Martin Rubey
Subject: re: [fspace.spad] dvi file display

Martin,

Tim provided an updated pamphlet file that I have put on
MathAction. Does this work now for you?

If not, could you please let me know what

  linux version:

  browser and version:

  dvi viewer and version:

you are using?

Thanks.

Bill Page.

On November 7, 2005 11:14 AM you wrote:
> > 
> > Can anyone reproduce this problem using a dvi viewer on linux?
> > 
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FspaceSpad
> 
> Clicking on pdf or dvi returns a page 
> 
> --------------------------------------------------------------
> 
> I could not find any likely page matching "error" 
> ... 

\start
Date: Mon, 7 Nov 2005 13:30:50 -0500
From: Tim Daly
To: Dan Zwillinger
Subject: Re: integration server
Cc: Richard Fateman

Dan,

You may remember me as we've crossed paths in the past but it 
has been a while.

Richard Fateman has a TILU server which contains a database of
integrals that can be accessed from common lisp.

Bill Page has a website (page.axiom-developer.org) where he's
been building up a mathematics web server, mostly based at the
moment on the open source version of axiom, but including by
permission REDUCE.

It would be useful if we could standardize this database and
put it behind the various algebra systems we plan to host.

As you can see from Richard's email he is willing to share
the data but it appears you hold the copyright.

Can we get your permission to use the database of integrals
on the axiom wiki site?

> Hi Tim,
> 
> There are a few issues.
> 
> 1. You are welcome to use the lookup service. There is a simple
> socket interface used by the Macintosh graphing calculator that
> you should use instead of the html page.
> 
> 2. I wouldn't worry about the traffic; there are about 100 visits
> per day on that socket, about 150 visits on the html page.
> 
> 3. On the other hand, the machine that it is running on is
> not supported, and when/if it crashes, it may not be revived.
> 
> 4. I don't actually own the database of integrals. It is mostly the
> CRC shorter table of integrals, used by permission of the
> publisher. Plus a few dozen Bessel integrals typed in from
> Gradshteyn, I think.
>  I (or you) would have to inquire about moving the CRC info
> elsewhere. I got permission via Dan Zwillinger, who was the editor.
> Maybe you should ask him.
> 
> 5. Tilu runs in Allegro Common Lisp, but I believe that it
> is written in ANSI common lisp, so that it could run on
> some other lisp --- assuming that ASERVE (written
> by Franz, but open sourced)  is available (e.g. GCL, SBCL, CMU-CL).
> So you could make a mirror site if you wished, and if the table
> ownership were solved.
> 
> I will see how the socket info works  (it's been a lonnng time...
> Tilu has been up since 1996... but the mac calculator is only a
> few years old.  Ron Avitzur and I worked together on that; he
> may have better documents.)  But I will send email soon.
> 
> Oh, I think the mathematica people may have a good site -- they used
> to -- and in fact tilu referred unsolved integrals to that web site
> until they fancied it up and ruined the interface.  (Basically they
> started returning pictures of the answer instead of text.)
> 
> You may share this info with axiom-dev list.
> 
> Regards
> Richard
> 
> 
> 
> root wrote:
> 
> >Richard,
> >
> >Axiom has a wiki website (page.axiom-developer.org) where we are
> >hosting not only axiom but other computer algebra systems.
> >
> >You run the tilu website.
> >
> >It would be a useful extension to the systems we host to enable
> >them to use your database lookup for computation. I hesitate
> >to point our server software at your server however as this
> >could cause a big increase in traffic. Plus the web interface
> >is awkward for automation.
> >
> >Is the database available? Could we set up a local copy on
> >axiom-developer.org?
> >
>Tim Daly

\start
Date: Mon, 07 Nov 2005 09:57:50 -0800
From: Richard Fateman
To: Tim Daly
Subject: Re: integration server

I checked the interface.
If you do the same as Ron Avitzur, you open a socket and
send a string in prefix form, like

(integrate (sin x) x)

and you get a response like (-1)*cos(x)

Even easier would be  (* -1 (cos x))
but that is not what Ron wanted.

The socket is at tilu/integrateGC2
I could set up a socket at tilu/axiom  or something like that.


but I don't recall how any of this worked
ftp or something?

Another thing you could do, if you want to use some kind
of socket, is to link to the maxima site at Franz inc.
But then you could just run maxima locally, so that
should be pointless.

RJF

root wrote:

>Richard,
>
>Axiom has a wiki website (page.axiom-developer.org) where we are
>hosting not only axiom but other computer algebra systems.
>
>You run the tilu website.
>
>It would be a useful extension to the systems we host to enable
>them to use your database lookup for computation. I hesitate
>to point our server software at your server however as this
>could cause a big increase in traffic. Plus the web interface
>is awkward for automation.
>
>Is the database available? Could we set up a local copy on
>axiom-developer.org?

\start
Date: Mon, 7 Nov 2005 13:54:32 -0500
From: Tim Daly
To: Dan Zwillinger
Subject: Re: integration server
Cc: Richard Fateman

Dan,

You may remember me as we've crossed paths in the past but it 
has been a while. My last email for you was as world.std.com.

Richard Fateman has a TILU server which contains a database of
integrals that can be accessed from common lisp.

Bill Page has a website (page.axiom-developer.org) where he's
been building up a mathematics web server, mostly based at the
moment on the open source version of axiom, but including by
permission REDUCE.

It would be useful if we could standardize this database and
put it behind the various algebra systems we plan to host.

As you can see from Richard's email he is willing to share
the data but it appears you hold the copyright.

Can we get your permission to use the database of integrals
on the axiom wiki site?

> Hi Tim,
> 
> There are a few issues.
> 
> 1. You are welcome to use the lookup service. There is a simple
> socket interface used by the Macintosh graphing calculator that
> you should use instead of the html page.
> 
> 2. I wouldn't worry about the traffic; there are about 100 visits
> per day on that socket, about 150 visits on the html page.
> 
> 3. On the other hand, the machine that it is running on is
> not supported, and when/if it crashes, it may not be revived.
> 
> 4. I don't actually own the database of integrals. It is mostly the
> CRC shorter table of integrals, used by permission of the
> publisher. Plus a few dozen Bessel integrals typed in from
> Gradshteyn, I think.
>  I (or you) would have to inquire about moving the CRC info
> elsewhere. I got permission via Dan Zwillinger, who was the editor.
> Maybe you should ask him.
> 
> 5. Tilu runs in Allegro Common Lisp, but I believe that it
> is written in ANSI common lisp, so that it could run on
> some other lisp --- assuming that ASERVE (written
> by Franz, but open sourced)  is available (e.g. GCL, SBCL, CMU-CL).
> So you could make a mirror site if you wished, and if the table
> ownership were solved.
> 
> I will see how the socket info works  (it's been a lonnng time...
> Tilu has been up since 1996... but the mac calculator is only a
> few years old.  Ron Avitzur and I worked together on that; he
> may have better documents.)  But I will send email soon.
> 
> Oh, I think the mathematica people may have a good site -- they used
> to -- and in fact tilu referred unsolved integrals to that web site
> until they fancied it up and ruined the interface.  (Basically they
> started returning pictures of the answer instead of text.)
> 
> You may share this info with axiom-dev list.
> 
> Regards
> Richard
> 
> 
> 
> root wrote:
> 
> >Richard,
> >
> >Axiom has a wiki website (page.axiom-developer.org) where we are
> >hosting not only axiom but other computer algebra systems.
> >
> >You run the tilu website.
> >
> >It would be a useful extension to the systems we host to enable
> >them to use your database lookup for computation. I hesitate
> >to point our server software at your server however as this
> >could cause a big increase in traffic. Plus the web interface
> >is awkward for automation.
> >
> >Is the database available? Could we set up a local copy on
> >axiom-developer.org?

\start
Date: Mon, 7 Nov 2005 14:09:24 -0500
From: Tim Daly
To: Richard Fateman
Subject: Re: integration server

i'd like to make the integration by lookup opaque to the user
so the various math systems "just work". 

for axiom this is going to take a bit of work due to the type issue.
i don't know about reduce as i haven't looked at the code.
axiom already does some pattern-match lookup so i expect that is
the proper place to extend the system.

maxima will probably be one of the math systems that gets added to
the mathaction site at some point, running locally. i've also been
pondering the thought of running it "under" axiom (since they are
both in common lisp on gcl) to provide a testing/debugging mechanism
for my automated builds. besides the type issue the only nit left is
solving the zero-equivalence problem :-)

\start
Date: Mon, 7 Nov 2005 14:24:54 -0500
From: Bill Page
To: Tim Daly
Subject: RE: integration server
Cc: Richard Fateman

Tim,

Could you explain a little more about what you have in mind
with the TILU site/database

http://torte.cs.berkeley.edu:8010/tilu

Mirroring this site on MathAction and maybe adding something
like Axiom-style input and LaTeX output or something like that,
e.g. adding the following kind of MathAction pseudo-environment:

\begin{tilu}
sin x
\end{tilu}

in parallel with the way {axiom} and {reduce} are handled, is
one thing (probably not too very difficult). But integrating
this kind of lookup into Axiom itself is quite another. I am
not sure it would be a good idea unless done in the context
of a major re-evaluation of the way Axiom does integration.

And yes, I am also planning someday to provide

\begin{maxima}
 ...
\end{maxima}

on the MathAction web site but so far there has not been much
interest expressed in this and no one who knows Maxima well
has come forward to offer to help, so I have given it a low
priority for now.

Regards,
Bill Page.

On November 7, 2005 2:09 PM you wrote:
> 
> i'd like to make the integration by lookup opaque to the user
> so the various math systems "just work". 
> 
> for axiom this is going to take a bit of work due to the type
> issue. i don't know about reduce as i haven't looked at the
> code. axiom already does some pattern-match lookup so i expect
> that is the proper place to extend the system.
> 
> maxima will probably be one of the math systems that gets added
> to the mathaction site at some point, running locally. i've also
> been pondering the thought of running it "under" axiom (since
> they are both in common lisp on gcl) to provide a testing /
> debugging mechanism for my automated builds. besides the type
> issue the only nit left is solving the zero-equivalence problem
> :-)

\start
Date: Mon, 7 Nov 2005 15:30:19 -0500
From: Tim Daly
To: Bill Page
Subject: Re: integration server
Cc: Richard Fateman, list

re: maxima.

i know Jim Amundson. He's a good guy. We can ask him if he or someone
else would like to help. probably just crossposting a request to the
maxima mailing list would likely get a response also.

re: integration integration

more on this later. i'm lagged at the moment.

\start
Date: Mon, 7 Nov 2005 21:20:44 +0100
From: Hans Peter Wuermli
To: Bill Page
Subject: Re: Expression problems

Thank you, Bill.

> >
> > if isPower(x**y) returns [x**y,1] then I would expect
> > isMult(x*y) to return [x*y,1] as the power expression
> > seems to be viewed as (x**y)**1, so one would
> > expect the second expression to be viewed as (x*y)*1.
>
> I agree with you that it is a little inconsistent. What do
> you think would be better: 1) for isPower(x**y) to return
> "failed" or 2) for isMult(x*y) to return 1?
>
Honestly, I wouldn't know, because I know too little about the design 
principles that are implemented (and I just haven't grasped yet).

\start
Date: 07 Nov 2005 18:05:29 -0500
From: Camm Maguire
To: Hans Peter Wuermli
Subject: Re: Debian Axiom - Compile problem

Greetings!

Hans Peter W=FCrmli Hans Peter Wuermli writes:

> Hi Camm
>
> I can probably not reproduce all the smaller or larger glitches I encountered,
> but they all seemed to be like the one with postprop.
>
> > Am fixing this now in a -4 debian package upload.  It would be most
> > helpful if you could send me the exact description of what you are
> > doing to trigger any errors you see so that I can ensure they are gone
> > before uploading.
> >
>
> postprop missing: )compile some.spad
>

OK, this is being added.

> libdb.text missing: search in hyptertext
>

This does not appear included in the distribution (i.e. under
mnt/linux) after compilation.  In any case, I cannot reproduce this
error and need a more specific example.

> htsearch not functioning correctly: looking for "eval" works, for "eval*"
> doesn't (I use unicode: could that make a difference?)
>

Both eval and eval* work for me, unsure what to do here.

> or sometimes:
> sh: line 1: htsearch: command not found
> syntax error: expected a page
> While parsing (null)
> Unexpected EOF
>

The path variable is not set correctly at present.  Am fixing this in
the next upload.

> I set the SPADEDIT environment variable to /usr/bin/emacs. emacs is called
> alright out of hypertext (or an axiom session), but the source.spad file to
> inspect is not presented (this seems to be a path problem).
>
>

This is a long standing bug in axiom proper (as opposed to the Debian
package).  To fix this will require some modifications to the file
naming conventions to my understanding.

Thank you so much for this feedback!  Please feel free to use the
Debian bug tracking system to describe any anomalies you see -- this
way I can be sure the issues are not lost. (e.g. 'reportbug').

\start
Date: Mon, 7 Nov 2005 15:24:01 -0800
From: Scott Morrison
To: Bill Page
Subject: Re: Good Tim

------=_Part_35487_7146088.1131405841682

Hello all,

It's time for me to weigh in on some issues again.

>>Converting Boot code to Lisp is trivial - just run the compiler.
>>That is the first step that Tim has already used in his recent
>>work to which I am objecting.

I agree that this is not the best way to convert the system to Lisp. In my
earlier post supporting Tim's project I was assuming that he was talking
about a real re-implementation. It was the comment about removing cruft and
structuring the data that made me think that. Compiling Boot to Lisp just
adds cruft; none is removed. The cruft removal implies a real re-write to
me.

Now if the goal was to really re-write the interpreter from scratch, I would
strongly recommend using Aldor. It's a great language and it would be ideal
for implementing the interpreter.

The destructuring assignments have been mentioned frequently as a reason to
stay with Boot. That syntax was a favorite of Dick Jenks, and it does lead
to some nifty small programs. It is in the destructuring assignments that
all the data structure information really lives in Boot. Tim mentioned that
he wanted to introduce real structured data during his conversion. To me
that mean analyzing all the destructuring assignments in Boot and converting
them into real data structure definitions. If that were done, the Lisp would
readable, if not quite as compact as the Boot equivalent. If the Boot is
converted to Lisp by compiling, then you don't get that, and the resulting
code would be harder to maintain than the Boot.

My main reason for supporting Tim's idea to convert to Lisp is that Boot is
dead, and less powerful than Lisp, so why not convert to a language that
many people know? However, if it is done in a largely automatic way by
compiling the Boot, that won't help anybody.

Ideally the whole system will be re-implemented in Aldor, but short of that
a well-designed conversion to Lisp would be great. If it is going to be an
automatic conversion without extracting data structures, then I'd say keep
the Boot.

-- Scott

\start
Date: Mon, 07 Nov 2005 18:45:55 -0500
From: William Sit
To: Cliff Yapp
Subject: Re: Terms of Surrender (was: BAD tim)

C Y wrote:
> 
> --- William Sit wrote:
> 
> > Bill Page wrote:
> > >
> > > Tim
> > >
> > > On November 6, 2005 1:16 PM you wrote:
> > > >
> > > > in open source "advocacy is volunteering"
> > [snipped]
> > > I agree that "advocacy is volunteering"  ...
> >
> > Well, I don't! To have that as the defacto working principle is to
> > discourage people from commenting or advocating.
> 
> I think it is more like "if there are two firmly opposed points of view
> in a debate, if only one person is willing to put the coding time
> behind their ideas then they win the argument by default."  Or perhaps
> "only ideas with both merit and support can survive."

I would agree with the second interpretation. The party who produces
code surely will have a much larger influence on the eventual utility
of the software, but whether it "wins" remains to be seen. The market
is littered with many well supported software that got nowhere. I am
sure while such software was at the developing stages, there was
heated debates on its directions. Just because someone puts an effort
to do the code is not my criteria for good software.  Neither does
that prevent me from appreciating the work that went into the
coding. Of course advocating an opposing viewpoint without producing
code will lead nowhere, but why should there be a defacto connection
between the advocate and the implementation?

> I think Tim is saying (correct me if I'm wrong Tim) he things his
> reasons are good ones, he is not convinced by the counter arguments,
> and he is willing to support his ideas with the effort it takes to make
> them real.  This being the case it is unreasonable to expect him to
> undertake coding tasks he neither enjoys nor thinks are necessary
> simply due to a group vote.  

No quarrel with that. The choice remains his. I said, "We should all simply be
working together, each contributing what (s)he can, but with an open mind to
accept or reject suggestions after due considerations." and you agreed.

> If the opposing viewpoints are willing to
> put in the effort to actually implement their ideas then they gain much
> more respect and if they turn out well they can be incorporated into
> the project too.  I'm guessing that's what Bill was agreeing with.

There are different levels of commitment for everything. I am not as
committed to Axiom as Tim, Bill, Camm, Martin, and many others,
are. If respect is measured in the amount of code produced, then I am
not in favor of that metric.

> > All who submit their comments, experience, or voice their deeply
> > felt convictions ARE volunteering, but it does NOT mean
> > they should be also the ones to carry out and implement the code.
> 
> True.  But nor should those who are actually be doing the coding have
> to abandon their ideas - the name of the game is to convince the
> opposition that your ideas are good ones. [snipped]

Agreed, even if I am doomed to fail :-(.
 
> A lot of us have been arguing in a way that sort of suggests that if we
> argue to concensus we think Tim should/will shift his direction
> accordingly, and we have no right to expect that.  I for one wish to
> apologize to Tim if I have given him that impression.  

No, I don't expect Tim to only follow concensus -- that is not the sign of a
true leader. I respect his decisions even if I do not agree (at this time). I
trust and know Tim well enough that apologies are not needed. 

[snipped]

> The really important mathematical code is written in SPAD or Aldor, and 
> surivives regardless.

The running of Spad depends on the underlying modules. Having to
backup to where we are now in three years' time is not progress, but
of course, I hope this will never happen. In this case, it may be
fortunate that we have a working code as backup, but I bet that if we
were to need to backup, the Boot code would have been broken. In
general, if we start writing code without a careful design, then even
though the resulting code can always be improved, the price may be
very high. Of course, I know the game is "release often, patch often"
or something like that. I guess a mathematician would never accept
that.
 
[snipped]

> I will say that for my part, regardless of the final use
> of Lisp or Boot, I will stick with the Axiom project because the ideas
> behind transcend language and are in fact what make Axiom special to
> begin with.

Viva Axiom!
 
> Remember though, in this kind of discussion there is
> legitimate room for many different points of view - it's not like a
> mathematical problem where a correct solution can be demonstrated.

Even in mathematics, there may be different correct solutions.

Tim wrote: 
> > if we're going to enhance a language i'd much rather the time
> > and energy went into debating new ideas for the spad language.
> >

Bill Page responded:
> >  I agree completely.

William Sit commented:
> > This is a perfect example: people who suggest new ideas for the spad
> > language need not be the ones to implement them. In fact, possibly,
> > they are not even qualified to implement them. Let each contribute
> > his/her best.

CY wrote: 
> Definitely.  I think Tim and Bill mutually concluded though that the
> SPAD level, where most significant work will be taking place, is the
> most logical forum for language considerations.  Ultimately, both Lisp
> and Boot are "under the hood" and either can be made to function.  SPAD
> or perhaps Aldor will be the public face for Axiom coding, and has a
> specialized focus as well.

Precisely, that is perhaps my (and may be Bill's) rational that converting Boot
to Lisp is not a priority, documenting Axiom (and Boot, perhaps, so that
maintenance is possible) is. 

[snipped]
 
> Tim, am I right that the eventual goal is to have all significant work
> take place in SPAD/Aldor, and the Lisp supporting structure become
> stable and need little tweaking? 
 
[snipped]
> 
> P.S. - One idea I'd like to mention both to Tim and his debate
> opponents - what about the idea of keeping the Lisp like syntax, but
> defining macros or whatnot to add some of the "safety" that Boot
> provides in coding?  The result will still be Lisp, make no mistake (I
> for one really like that all I have to worry about is getting the right
> number of parenthesis, as opposed to other syntax mistakes, but that's
> just a personal preference) but perhaps some of what appeals to the
> Boot folks could be incorporated as macros or whatnot in the Lisp code
> itself, and in fact make the Lisp coding easier?  Tim, were you
> planning something like this?  We haven't seen much of your hand coded
> lisp yet, so perhaps you were already planning something like that?  I
> know that's a popular thing in Lisp, having the computer do work
> instead of the programmer, so perhaps something of the sort could be
> useful here?
> 
> Boot guys, maybe the thing to do is to enumerate what makes Boot a good
> tool for writing the SPAD compiler (or whatever) and look for a way to
> have Lisp macros or some such assist the programmer.  Boot syntax I
> don't think is going to make it, but if we take an ideas approach
> perhaps there is some useful mapping to be done which would appeal both
> to the original motivations for Boot and to an advanced Lisp
> programmer.  Rather than an all or nothing stance, perhaps accepting
> Tim's focus on Lisp and looking for ways to intelligently code Lisp to
> achieve the best (non-syntax) ideas of Boot would result in something
> everyone can be satisfied with.

I think your proposal is well worth considering by both sides. So far, we have
heard how bad Boot is and how powerful Lisp is. I am waiting for Tim to tell us
what the eventual architecture the Axiom system will be in his vision and how
Lisp supported that vision. I can still be convinced his way (and I will not
commit myself to coding for either camp -- that's full disclosure).

\start
Date: Mon, 07 Nov 2005 19:06:39 -0500
From: William Sit
To: Bill Page
Subject: re: [fspace.spad] dvi file display

Bill Page wrote:
> 
> Tim,
> 
> On November 7, 2005 12:23 PM you wrote:
> >
> > replace that text with the one i just sent you.
> > this update will go out as part of the next patch.
> > hopefully that fixes the problem.
> >
> 
> Thanks Tim. That looks much better and does fix the problem for
> me using MikTeX Yap on Windows.
> 
> Does the 'dvi' link at
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FspaceSpad
> 
> work for you now William?

Yes, it works, other than on p. 3 and 36 there are some lines spilling over the
right margin.

Thanks. This set up (viewing pamphlet files in all its modes) is great and at
least makes the poor links in hyperdoc to source files irrelevant for the time
being. Great job.

\start
Date: Mon, 7 Nov 2005 17:16:00 -0800 (PST)
From: Cliff Yapp
To: William Sit
Subject: Re: Terms of Surrender (was: BAD tim)

--- William Sit wrote:

> C Y wrote:
> > I think it is more like "if there are two firmly opposed points of
> > view in a debate, if only one person is willing to put the coding 
> > time behind their ideas then they win the argument by default."  
> > Or perhaps "only ideas with both merit and support can survive."
> 
> I would agree with the second interpretation. The party who produces
> code surely will have a much larger influence on the eventual 
> utility of the software, but whether it "wins" remains to be seen. 

OK, point.

> The market is littered with many well supported software that got 
> nowhere. I am sure while such software was at the developing stages,
> there was heated debates on its directions. Just because someone 
> puts an effort to do the code is not my criteria for good
> software.  Neither does that prevent me from appreciating the work
> that went into the coding. Of course advocating an opposing 
> viewpoint without producing code will lead nowhere, but why should 
> there be a defacto connection between the advocate and the 
> implementation? 

There isn't - I'm just saying in a case like this, where neither side
makes an appreciable dent in the other, the way forward is code. :-)

> > I think Tim is saying (correct me if I'm wrong Tim) he things his
> > reasons are good ones, he is not convinced by the counter
> > arguments, and he is willing to support his ideas with the effort
> > it takes to make them real.  This being the case it is 
> > unreasonable to expect him to undertake coding tasks he neither 
> > enjoys nor thinks are necessary simply due to a group vote.  
> 
> No quarrel with that. The choice remains his. I said, "We should all
> simply be working together, each contributing what (s)he can, but 
> with an open mind to accept or reject suggestions after due 
> considerations." and you agreed.

Yep.  I think so far that's going rather well :-).  I'm learning a lot
from these discussions, and several offshoot questions are also of
interest - such as what objective "figures of merit" could be
established for programming languages?

> > If the opposing viewpoints are willing to put in the effort to 
> > actually implement their ideas then they gain much more respect 
> > and if they turn out well they can be incorporated into the 
> > project too.  I'm guessing that's what Bill was agreeing with.
> 
> There are different levels of commitment for everything. I am not as
> committed to Axiom as Tim, Bill, Camm, Martin, and many others, are.
> If respect is measured in the amount of code produced, then I am not
> in favor of that metric. 

I didn't mean to imply that.  Lord knows amount of code by itself is
not a metric for quality or respect - if that were the case Windows
could be considered a really high quality piece of coding art.  I'm
just saying that in an open source project discussion without code
ultimately goes nowhere.  I don't think that's a danger here, but it
has been known to effectively kill projects in the past.

> > > All who submit their comments, experience, or voice their deeply
> > > felt convictions ARE volunteering, but it does NOT mean
> > > they should be also the ones to carry out and implement the code.
> > 
> > True.  But nor should those who are actually be doing the coding
> > have to abandon their ideas - the name of the game is to convince
> > the opposition that your ideas are good ones. [snipped]
> 
> Agreed, even if I am doomed to fail :-(.

I wouldn't consider it a failure.  This kind of discussion is education
in and of itself.  And if we should have to revisit the issue someday,
we can have everybody re-read the archives and save some typing :-).

> > A lot of us have been arguing in a way that sort of suggests that
> > if we argue to concensus we think Tim should/will shift his 
> > direction accordingly, and we have no right to expect that.  I for
> > one wish to apologize to Tim if I have given him that impression.  
> 
> No, I don't expect Tim to only follow concensus -- that is not the
> sign of a true leader. I respect his decisions even if I do not 
> agree (at this time). I trust and know Tim well enough that 
> apologies are not needed. 

Well, since I don't know Tim all that well yet (and he doesn't know me)
I just wanted to be sure I didn't come across incorrectly.

> > The really important mathematical code is written in SPAD or Aldor,
> > and surivives regardless.
> 
> The running of Spad depends on the underlying modules. Having to
> backup to where we are now in three years' time is not progress, but
> of course, I hope this will never happen.

Spad does of course depend on the underlying modules, but shouldn't it
(in theory) not need to care how they are implemented?  Sort of the
same way ANSI lisp code should run in any ANSI lisp implementation,
without worrying about how the enviroment underneath it is coded up?

> In this case, it may be fortunate that we have a working code as 
> backup, but I bet that if we were to need to backup, the Boot code 
> would have been broken. 

Some of the newer mathematical code might depend on language
capabilities that the older Boot code couldn't support, but I would be
surprised if things diverge that badly, particularly if we are able to
use Aldor as the primary language for new work.

> In general, if we start writing code without a careful design, then
> even though the resulting code can always be improved, the price may
> be very high. Of course, I know the game is "release often, patch
> often" or something like that. I guess a mathematician would never 
> accept that.

Probably not.  I am hoping either SPAD or Aldor will present a fairly
stable, fixed platform from which to build, but I suppose that never
works out perfectly.  At any rate, having a working version to fall
back on is definitely a luxury compared to starting from scratch :-).

> > I will say that for my part, regardless of the final use
> > of Lisp or Boot, I will stick with the Axiom project because the
> > ideas behind transcend language and are in fact what make Axiom
> > special to begin with.
> 
> Viva Axiom!

:-)
  
> > Remember though, in this kind of discussion there is
> > legitimate room for many different points of view - it's not like a
> > mathematical problem where a correct solution can be demonstrated.
> 
> Even in mathematics, there may be different correct solutions.

Point.

> CY wrote: 
> > Definitely.  I think Tim and Bill mutually concluded though that
> > the SPAD level, where most significant work will be taking place,
> > is the most logical forum for language considerations.  
> > Ultimately, both Lisp and Boot are "under the hood" and either can
> > be made to function. SPAD or perhaps Aldor will be the public face
> > for Axiom coding, and has a specialized focus as well.
> 
> Precisely, that is perhaps my (and may be Bill's) rational that
> converting Boot to Lisp is not a priority, documenting Axiom (and 
> Boot, perhaps, so that maintenance is possible) is. 

If I'm not mistaken, the approach Tim has taken so far with vol5 is
resulting in documentation that applies equally well to Lisp and Boot
code - at least, the level of documentation he has started writing.  If
it helps, perhaps the current state of included auto-generated lisp
code could represent proof that the current documentation is in fact
applicable to both Boot and Lisp code (where the documentation covers
such things instead of SPAD code) since they are demonstrably identical
at this stage.  If you parse out the lisp includes and build the book
again, viola - documented boot code.

> > P.S. - One idea I'd like to mention both to Tim and his debate
> > opponents - what about the idea of keeping the Lisp like syntax,
> > but defining macros or whatnot to add some of the "safety" that 
> > Boot provides in coding?  The result will still be Lisp, make no 
> > mistake (I for one really like that all I have to worry about is 
> > getting the right number of parenthesis, as opposed to other 
> > syntax mistakes, but that's just a personal preference) but 
> > perhaps some of what appeals to the Boot folks could be 
> > incorporated as macros or whatnot in the Lisp code itself, and in
> > fact make the Lisp coding easier?  Tim, were you planning 
> > something like this?  We haven't seen much of your hand coded
> > lisp yet, so perhaps you were already planning something like that?
> > I know that's a popular thing in Lisp, having the computer do work
> > instead of the programmer, so perhaps something of the sort could 
> > be useful here?
> >
> > Boot guys, maybe the thing to do is to enumerate what makes Boot a 
> > good tool for writing the SPAD compiler (or whatever) and look for
> > a way to have Lisp macros or some such assist the programmer.  
> > Boot syntax I don't think is going to make it, but if we take an 
> > ideas approach perhaps there is some useful mapping to be done 
> > which would appeal both to the original motivations for Boot and 
> > to an advanced Lisp programmer.  Rather than an all or nothing 
> > stance, perhaps accepting Tim's focus on Lisp and looking for ways
> > to intelligently code Lisp to achieve the best (non-syntax) ideas
> > of Boot would result in something everyone can be satisfied with.
>
> I think your proposal is well worth considering by both sides. So
> far, we have heard how bad Boot is and how powerful Lisp is. I am
> waiting for Tim to tell us what the eventual architecture the Axiom
> system will be in his vision and how Lisp supported that vision. I
> can still be convinced his way (and I will not commit myself to 
> coding for either camp -- that's full disclosure).

Thanks!  I have always heard Lisp is real good at redefining itself to
particular tasks, so perhaps this is a good opportunity for it to do so
- that would leave pure lisp abilities for things like FFIs with
libraries and graphics, and still allow targeted coding for SPAD
purposes.  Eventually of course the ideal thing to do is rewrite all
relevant foreign libraries with the relevant research information in
Spad or Aldor, but for things like the CERN libs that could take some
doing :-).

The overall architecture of the Axiom system is definitely interesting,
even without language questions :-).  On Maxima I starting trying to
use Graphviz to map key relationships between systems, with the idea of
eventually creating successive nested graphs that would constitute a
roadmap of the entire system.  I didn't get much further than the
toplevel control loop, but even that was useful (to me anyway): 
http://maxima.sourceforge.net/toplevel.png

My original vision was that each package would have one of these types
of graphs as it's second page (sort of an "inside the cover" addition
if it were a book) that would allow a new programmer to immediately get
a feel for the workflow of this particular part of the system, and what
parts it relates to.  Maybe this could apply to pamphlets.  Also it
might allow programmers unfamiliar with how the system works to quickly
zero in on which functions were possibly relevant to a particular bug.
For real fun perhaps these diagrams could be autogenerated by the
SPAD/Aldor parser as part of the compile :-).  Of course, higher level
ones might have to be done by hand, depending on how smart the output
routines were...

Anyway, enough idle chatter.  Time for supper, and then some more
banging of the head on dimensional analysis.

\start
Date: Mon, 7 Nov 2005 22:19:48 -0500
From: Tim Daly
To: Cliff Yapp
Subject: letting my mud settle

*,

when i first got the code (before it saw the light of day) i spent a
lot of time thinking about my past sins and letting my mud settle. as
a result of that navel gazing i decided that the system needed to be
completely rewritten. the task at that time was to rewrite the system
into pamphlet files. had i proposed such a massive, prevasive rewrite
this mailing list would have been aflame with opinion. and the
concensus would certainly have been to NOT do a pamphlet rewrite
or if so, use doxygen, texmacs, xml, etc.

in the process of building the system and the Makefile tree i spent
a lot of time thinking about my past sins (and suffering from them
which is poetic justice). as a result of that effort i decided that
the system needed to be completely rewritten. the task at this time
is to document it and clean it up. i need to get to the point of
being able to say 

  (compile-file "interpreter.lisp") ; actually bookvol5
  (load "interpreter")
  (compile-file "compiler.lisp")    ; actually bookvol6
  (load "compiler")
  (compile-file "browser.lisp")     ; actually bookvol7
  (load "browser")
  (compile-file "graphics.lisp")    ; actually bookvol8
  (load "graphics")
  (axiom)

at that time we'll have a crisp, clean, documented, partitioned 
system and we will be able to understand the parts. we can rewrite
them in aldor if someone steps up to it. or add new ones. for example

  (compile-file "openmath-server.lisp") ; bookvol9?
  (load "openmath-server")
  (axiom :openmath-port 1234)

we can't do that now. and we can't do it in boot. the system is too
damn complex and badly designed/written/structured. construction is
always dirty, disruptive, and time consuming. i'm sorry that you'll
get to see my ugly hacking along the way. but, hey, that's open
source programming.

i'm going to fix axiom.
i know how to get there from here. 
it takes time. 
it takes work.
it takes patience.

and once this is done there is SO much more to do.
why, the algebra restructuring alone will take years...

\start
Date: Tue, 08 Nov 2005 00:07:32 -0500
From: William Sit
To: Cliff Yapp
Subject: Re: Terms of Surrender (was: BAD tim)

C Y wrote:
> I'm
> just saying that in an open source project discussion without code
> ultimately goes nowhere.  I don't think that's a danger here, but it
> has been known to effectively kill projects in the past.

Is that (projects getting killed) necessarily bad?

> > The running of Spad depends on the underlying modules. Having to
> > backup to where we are now in three years' time is not progress, but
> > of course, I hope this will never happen.
> 
> Spad does of course depend on the underlying modules, but shouldn't it
> (in theory) not need to care how they are implemented?  Sort of the
> same way ANSI lisp code should run in any ANSI lisp implementation,
> without worrying about how the enviroment underneath it is coded up?

True, but we are talking about maintaining the system, not just the algebra
code. There are bound to be modifications, if only because versions of Lisp has
changed.
 
> > In this case, it may be fortunate that we have a working code as
> > backup, but I bet that if we were to need to backup, the Boot code
> > would have been broken.
> 
> Some of the newer mathematical code might depend on language
> capabilities that the older Boot code couldn't support, but I would be
> surprised if things diverge that badly, particularly if we are able to
> use Aldor as the primary language for new work.

Even my limited experience tells me that codes will break if allowed to stay
stagnant.
 
[snipped]

> If I'm not mistaken, the approach Tim has taken so far with vol5 is
> resulting in documentation that applies equally well to Lisp and Boot
> code - at least, the level of documentation he has started writing.  If
> it helps, perhaps the current state of included auto-generated lisp
> code could represent proof that the current documentation is in fact
> applicable to both Boot and Lisp code (where the documentation covers
> such things instead of SPAD code) since they are demonstrably identical
> at this stage.  If you parse out the lisp includes and build the book
> again, viola - documented boot code.

Glad to know that.

[snipped]
 
> > I think your proposal is well worth considering by both sides. So
> > far, we have heard how bad Boot is and how powerful Lisp is. I am
> > waiting for Tim to tell us what the eventual architecture the Axiom
> > system will be in his vision and how Lisp supported that vision. I
> > can still be convinced his way (and I will not commit myself to
> > coding for either camp -- that's full disclosure).
> 
> Thanks!  I have always heard Lisp is real good at redefining itself to
> particular tasks, so perhaps this is a good opportunity for it to do so
> - that would leave pure lisp abilities for things like FFIs with
> libraries and graphics, and still allow targeted coding for SPAD
> purposes.  Eventually of course the ideal thing to do is rewrite all
> relevant foreign libraries with the relevant research information in
> Spad or Aldor, but for things like the CERN libs that could take some
> doing :-).
> 
> The overall architecture of the Axiom system is definitely interesting,
> even without language questions :-).  On Maxima I starting trying to
> use Graphviz to map key relationships between systems, with the idea of
> eventually creating successive nested graphs that would constitute a
> roadmap of the entire system.  I didn't get much further than the
> toplevel control loop, but even that was useful (to me anyway):
> http://maxima.sourceforge.net/toplevel.png

Tim has done that type of analysis on Axiom more than anyone else. But
what I am looking for is even coarser: just the major components and
how Lisp helps.
 
> My original vision was that each package would have one of these types
> of graphs as it's second page (sort of an "inside the cover" addition
> if it were a book) that would allow a new programmer to immediately get
> a feel for the workflow of this particular part of the system, and what
> parts it relates to.  Maybe this could apply to pamphlets.  Also it
> might allow programmers unfamiliar with how the system works to quickly
> zero in on which functions were possibly relevant to a particular bug.
> For real fun perhaps these diagrams could be autogenerated by the
> SPAD/Aldor parser as part of the compile :-).  Of course, higher level
> ones might have to be done by hand, depending on how smart the output
> routines were...

That would be useful for Tim's Crystal vision.

\start
Date: Tue, 08 Nov 2005 00:05:23 -0600
From: Jay Belanger
To: list
Subject: Re: letting my mud settle

> *,

That's wild enough to include me.  I really don't have anything to
contribute, but I thought I should delurk sometime.

> when i first got the code (before it saw the light of day) i spent a
> lot of time thinking about my past sins and letting my mud settle. as
> a result of that navel gazing i decided that the system needed to be
> completely rewritten. the task at that time was to rewrite the system
> into pamphlet files. had i proposed such a massive, prevasive rewrite
> this mailing list would have been aflame with opinion. and the
> concensus would certainly have been to NOT do a pamphlet rewrite
> or if so, use doxygen, texmacs, xml, etc.

It's probably largely due to hindsight and seeing how things turned
out, but rewriting it in the pamphlet files was a fantastic thing.
I can see how it could cause an opinion war, though.

> in the process of building the system and the Makefile tree i spent
> a lot of time thinking about my past sins (and suffering from them
> which is poetic justice).

I'm too clueless to even dream of commenting on past sins, but if they
led, even indirectly, to where things are going now, I don't think sins
is the right word.

> we can't do that now. and we can't do it in boot. the system is too
> damn complex and badly designed/written/structured. construction is
> always dirty, disruptive, and time consuming. i'm sorry that you'll
> get to see my ugly hacking along the way. but, hey, that's open
> source programming.

Seeing your "ugly hacking" may well be a good thing.  As a teacher, I
try to make clear to my students that not everything starts off clean
and polished; that leads to false sense of how things are really done,
and can easily make good students feel inadequate.  ("This works
great, but it seems to have been pulled out of thin air.  I could
certainly never come up with anything like this.")

> i'm going to fix axiom.

How "broken" is it?  I'm working my way through the Axiom book, but
haven't gotten very far yet.  (Whatever happened to the plans to
publish it?  I would love to have a copy.  Right now I'm printing a
few pages at a time to read.)  I would like to encourage people here
to use it in class.

> i know how to get there from here.
> it takes time.
> it takes work.
> it takes patience.
>
> and once this is done there is SO much more to do.
> why, the algebra restructuring alone will take years...

A finished, polished Axiom would be nice.  But I've always enjoyed
playing around with things trying to get them to work. Hopefully, I'll
be able to help sometime in the near future.  (I only have about
10,000 pages left to read in the Axiom book.)

> t

That would make me...

\start
Date: Tue, 08 Nov 2005 04:04:42 -0600
From: MathAction (unknown)
To: MathAction
Subject: [mirrors] 

integrate(1/(a+z^3), z=0..1,"noPole")

\start
Date: Tue, 08 Nov 2005 11:35:27 +0100
From: Kai Kaminski
To: list
Subject: Re: Good Tim

Bill Page writes:

> On November 7, 2005 10:10 AM Kai Kaminski wrote:
>
>> 
>> I don't feel like participating in the language arguments going
>> on at the moment. Still I would like to voice my support for Tim's
>> position in this matter.
>
> Thank you for participating anyway. :)
My pleasure ;-)

>> In particular, I agree with him that BOOT is *not* higher-level
>> than Lisp. There is not a single feature in Lisp that can't be
>> embedded in Lisp with macros.
>
> I expect you meant to write: 
>
> "There is not a single feature in Boot that can't be embedded
> in Lisp with macros."
Yes.

> That is certainly true but it is completely irrelevant. Before
> we argue about when something is "higher-level" than something
> else, I think we must first define what we mean by "higher-level".
> This is difficult.
>
> Perhaps we can agree that Spad is higher-level than Lisp? If
> so then I can at least temporarily bypass the exact definition
> of the language hierarchy and simply argue that Boot is closer
> to Spad than Lisp and so the designation "higher-level" is
> appropriate.
>
> If you do not agree that Spad is higher-level than Lisp, then
> I think we should talk more about Spad first before talking
> about Boot.
In that sense BOOT might be higher level than Lisp, but I can't see
how that is useful. Still I won't argue this point, as I really don't
want to join the discussion. I only wrote the above to make clear what
exactly I agree with.

>> I also agree with him that in open source "advocacy is
>> volunteering". Hence I'm willing to start working on converting
>> BOOT code to Lisp as soon as Tim tells me that he'll accept
>> such patches.
>> 
> Converting Boot code to Lisp is trivial - just run the compiler.
But the compiler's output is mostly useless. It only(?) uses lists and
maybe vectors and the code it generates is pretty ugly. I'm offering
to rewrite BOOT code in Lisp by hand. That requires some redesign,
especially considering that Aldor is the goal, and so I'm waiting for
Tim to tell me where to start or what to do.

> That is the first step that Tim has already used in his recent
> work to which I am objecting. After that, there is the matter of
> removing the Boot compiler artefacts. But that is not enough.
> If anything is to be converted to Lisp than it seems to me that
> it must be converted to a form of Lisp which is at least as
> intelligible as the original Boot code.
I don't think removing the artifacts will be enough.

> Of course we can also argue about what is "intelligible". In
> this regard my proposed standard again would be Spad. So by
> "intelligible" I mean that it must be easily understood by an
> Axiom user who is fluent in Spad and may only know Lisp
> "in theory", not by extensive practice.
I don't agree, but again I won't argue this point. The discussion is
confusing enough as it is.

\start
Date: 08 Nov 2005 12:58:45 +0100
From: Martin Rubey
To: Bill Page
Subject: re: [fspace.spad] dvi file display

> Does the 'dvi' link at
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FspaceSpad

Don't know why, but it works for me now, too. Although I doubt it had anything
to do with the dvi file itself...

\start
Date: 08 Nov 2005 13:06:25 +0100
From: Martin Rubey
To: Bill Page
Subject: re: integration server
Cc: Richard Fateman

Bill Page writes:

> But integrating this kind of lookup into Axiom itself is quite another. I am
> not sure it would be a good idea unless done in the context of a major
> re-evaluation of the way Axiom does integration.

I recently had to understand the pattern matcher in Axiom (it's in
intpm.spad). Unfortunately, in comparison to MuPad for example, it is a rather
poor facility. Furthermore, it doesn't look easy to extend it, contrary, for
example, to the MuPad pattern matcher...

It would really be necessary to interest some integration expert in Axiom,
otherwise we are probably unable to do these things.

In any case, I'm open to help if somebody wants to document intpm.spad and it's
interaction with the rest of the integration system.

\start
Date: 08 Nov 2005 13:09:38 +0100
From: Martin Rubey
To: Bill Page, Tim Daly, Richard Fateman
Subject: re: integration server

I forgot an important paragraph: the implementation of the Risch algorithm
seems to be quite up to date however. Furthermore, it appears that the SumIt
library by Manuel will be released under a free license, and it should be
possible to link it to Axiom. This would probably be state of the art. -- Not
for pattern matching integration, of course.

\start
Date: Tue, 08 Nov 2005 13:05:32 +0100
From: Ralf Hemmecke
To: Kai Kaminski
Subject: Future of Axiom design

Hello,

I don't want to take part in that discussion about whether BOOT should 
remain or not. Good documentation is one thing, but there should be some 
goal of where we want to get Axiom finally.

>> Converting Boot code to Lisp is trivial - just run the compiler.
> But the compiler's output is mostly useless. It only(?) uses lists and
> maybe vectors and the code it generates is pretty ugly. I'm offering
> to rewrite BOOT code in Lisp by hand. That requires some redesign,
> especially considering that Aldor is the goal, and so I'm waiting for
> Tim to tell me where to start or what to do.

 From the mails I read so far, one point seems to be agreed upon.

Aldor should be the language of choice for further development of the 
ALGEBRA.

However, I have not seen a rough plan for the overall design of Axiom.
(Did I miss something?)

Now the discussion goes LISP vs. BOOT, but is there perhaps also some 
plan to finally replace both LISP and BOOT AND SPAD by Aldor? The Aldor 
compiler already exists (and it needs a lot of work to make it more 
stable). For license issues see
http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00276.html.

I have not much experience with (writing) interpreters, but I could 
imagine the following:

Build the ALGEBRA with the Aldor compiler generating .o (or .lisp) files.

Add "reflections" to the runtime-system (similar to reflections in JAVA) 
so that an interpreter (written in Aldor or any other language) can get 
information about the available types in order to do its job.

I have no knowledge about the internals of .o files, but wouldn't it be 
possible to have the interpreter call the functions from the .o files 
dynamically? For new functions the interpreter would call the compiler 
and generate some temporary .o files.

This would be my vision of how Axiom should be heading to.

I hope this motivates others to post their views on the future of Axiom.
Maybe we can converge to some steps that are needed to reach the final goal.

\start
Date: Tue, 8 Nov 2005 08:38:59 -0500
From: Tim Daly
To: Kai Kaminski
Subject: code walker and crystal

Kai,

what i'm doing is pure dogwork. there are interesting parts to be
done which i have "in plan" and you can clearly get there first.
they will get done but not real soon. so i'll give you some thoughts.

besides the summer work that you're doing i think the main thing you
could help with is making the books more useful. we need a standard
who-calls/called-by mechanism for creating index entries. my experience
working with publishers is that they know that a good index is very
valuable. they have professionals on staff who help authors. several
lisps have this kind of mechanism and i've even written one once but
that was long ago and the code is gone. you have to be clever because
macros can hide code calls.

we need to find (or write) a code-walker that can collect this
information and we need to add it to the process so it can be
used to generate automatic index entries in latex. so the input
is a set of lisp files and the output is a latex index file.
assume lisp code so you can manipulate source code as data.

another subproject is to get the code hierarchy (per CY's note)
into some graphing format. i've downloaded CL-DOT from
http://www.cliki.net/cl-dot but have not had time to play with it.
there may be other/better tools. Bill has looked at some of them.
ideally this would use mcclim so we can gain expertise in lisp graphics.
i'd like to get diagrams autogenerated in the book. and i'd like
to be able to click on graph nodes entries and go right to the code
(hyperlinking in graphs).

plus this leads the way to a larger project which Bill and i have
struggled with, namely the algebra hierarchy.

the algebra hierarchy is a directed circular graph with 1100 nodes.
we need to untangle it better as the last pass was done by hand.
Bill and i have both attempted this without success. the problem
is big and hard.

beside the code-walker/algebra/graphic improvements in the books
this will give us some ideas about how to do the graphics in lisp.

the code indexer and the code grapher are both subprojects i have
"in plan" but have not yet had the cycles to devote to it.

if you REALLY want to think about the larger picture (pun intended) of
these two efforts we really need to think of the code, the walker, the
book, and the graph as "facets" in the crystal. the hard problem is
combining these things with machinery so that updating one updates all
of the others automatically. edit the book, save the book, type make
which rewalks the code, rebuilds the index, the book, the bib, and
piles it all together.

riffing off (ripping off?) bill's wiki idea consider a web page design
where there are 8 "facet" links around the page (the 4 edges and the
4 corners, probably 1/8 inch border.) consider each border area to
be a command (actually a hyperlink but with save/regen of the current
modified page) to "rotate" the crystal. so a browser "page" becomes
a "crystal facet" where you can see tiny labeled portions of the other
facets around the edge of the current page. (it takes some imagination
to view a page as a facet. think of getting REAL close to a crystal)

assume the wiki web pages are running locally.
assume all the horsepower in the world so everything gets updated
directly from sources and rebuilt every time on every change.

modifying one facet (say the code facet) in the web page would update
the other N facets (code walker, code graph, book page, index table,
who calls, who called, constant list, variable list, axiom shell,
etc). 


  whocalls                                               calledby
     +-------------------------------------------------------+
     |  /              graph                              \  |
     + +---------------------------------------------------+ +
     |/|                                                   |\|
     | |                                                   | |
     | |                                                   | |
     | |                                                   | |
     | |                                                   | |
     |a|                                                   |b|
     |x|                                                   |o|
     |i|                                                   |o|
     |o|                                                   |k|
     |m|             SOURCE CODE                           | |
     | |                                                   | |
     |s|                                                   | |
     |h|                                                   | |
     |e|                                                   | |
     |l|                                                   | |
     |l|                                                   | |
     | |                                                   | |
     | |                                                   | |
     |\|                                                   |/|
     + +---------------------------------------------------+ +
     |  \               index                             /  |
     +-------------------------------------------------------+
  constant                                                variable 
   usage                                                   usage


similarly, another facet might lead to the algebra sources
or the problem statement, the literature references, the
"semantic graph", the latex, the pdf, etc.


   pdf                                                   semantic net
     +-------------------------------------------------------+
     |  /              latex                              \  |
     + +---------------------------------------------------+ +
     |/|                                                   |\|
     | |                                                   | |
     | |                                                   | |
     | |                                                   | |
     | |                                                   | |
     |r|                                                   |b|
     |e|                                                   |o|
     |f|                                                   |o|
     |e|                                                   |k|
     |r|             AXIOM SHELL                           | |
     |e|                                                   | |
     |n|             ->                                    | |
     |c|                                                   | |
     |e|                                                   | |
     |s|                                                   | |
     | |                                                   | |
     | |                                                   | |
     | |                                                   | |
     |\|                                                   |/|
     + +---------------------------------------------------+ +
     |  \               bibliography                      /  |
     +-------------------------------------------------------+
  spad code                                                literature
                                                            search

rather than shovelling source code in the same ditch it would be
much more productive to begin to think about the longer term. the
hard part is seeing that apparently simple problems (like a code
indexer) fit into the long term. even a code indexer is hard because
you have to figure out how to make it all happen "automagiacally".

\start
Date: Tue, 08 Nov 2005 07:28:39 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [Computing with Vectors] (new) 

How to multiply two vectors??

  Multiplication element by element:

*Vanuxem Gregory replies:*

\begin{axiom}
a:= vector [1,2,3,5,6]
map(*,a,a)
\end{axiom}

otherwise use Matrix:
\begin{axiom}
a:= matrix [[1,2,3,4,5,6]]
a * transpose a
\end{axiom}

Tim Daly replies:

make three vectors
\begin{axiom}
)clear all
u : VECTOR INT := new(5,12)
v : VECTOR INT := vector([1,2,3])
w : VECTOR INT := vector([2,3,4])
\end{axiom}
multiply them
\begin{axiom}
cross(v,w)
\end{axiom}
dot product
\begin{axiom}
dot(v,w)
\end{axiom}
ask for the length
\begin{axiom}
#(v)
\end{axiom}
access an element
\begin{axiom}
v.2
\end{axiom}
set an element
\begin{axiom}
v.3 := 99
\end{axiom}
show the vector
\begin{axiom}
v
\end{axiom}
multiply by a constant
on either side
\begin{axiom}
5 * v
v * 7
\end{axiom}

add them
\begin{axiom}
v + w
\end{axiom}

substract them
\begin{axiom}
v - w
\end{axiom}

display all possible functions
\begin{axiom}
)show Vector(Integer)
\end{axiom}

\start
Date: Tue, 8 Nov 2005 08:31:33 -0500
From: Bill Page
To: list
Subject: FW: [FrontPage] MuPad under trouble

Axiom Developers,

This information was forwarded to the Axiom Portal by an
anonymous Axiom user.

At http://fuchssteiner.info

there is some sad and shocking news about MuPad. Of the three,
Mathematica, Maple and MuPad, MuPad is the closest in spirit
to Axiom both in mathematical approach and in availability to
the research community.

I sincerely hope that MuPad can over come these problems and
prevail against politics, greed, and closed minds. Dare I suggest
that open source development would be their best way forward?

Regards,
Bill Page.

-----Original Message-----

See for example Benno Fuchssteiner's personal page for this:
http://fuchssteiner.info/

Sciface has stopped providing MuPad light (which was a limited functionality
free edition) and the cost have also been raised. You may also check the
http://sciface.com and http://mupad.com

\start
Date: Tue, 08 Nov 2005 07:38:20 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [simplifying Expressions] (new) 

Simplification of Expressions

  Suppose we compute

\begin{axiom}
integrate(exp(-x**2/2)/sqrt(2*%pi),x=%minusInfinity..%plusInfinity)
\end{axiom}

*And now I wonder why common factors are not cancelled and why not the
result "1" is produced.*

In general (unlike some other computer math systems) Axiom automatically
performs only a very small number of basic simplifications. This is not
one of them, so we need to provide some help. In particular we need to
tell Axiom how to expand square roots. (Since $\sqrt{\ }$ is a multi-valued
function this rule is true only in a restricted sense for a particular
choice of branches. Consider $a=-1, b=-1$.)

\begin{axiom}
expandSqrt := rule sqrt(a*b)==sqrt(a)*sqrt(b)
\end{axiom}

Next, notice that the output of the integration operation has a complicated
type structure. This would interfere with the simplification, so we first
simplify the type before we apply the rule.

\begin{axiom}
(%% 1)::Expression Integer
expandSqrt %
\end{axiom}

\start
Date: Tue, 08 Nov 2005 07:40:38 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [Graphics on MathAction] (new) 

Graphics?

  Try this

\begin{axiom}
draw(5*besselJ(0,sqrt(x**2+y**2)), x=-20..20, y=-20..20)
\end{axiom}

*Not clear why latex is not rendered properly ... *

The reason why this did not originally render properly was because I had not
defined \axiomType as a valid LaTeX command in the LatexTemplate page. The
output of the draw command generates this as part of it's LaTeX output.

Anticipating the next question::

  Where is the graphic??

Although graphics is available in the most recent version of Axiom
from the Savannah CVS (see AxiomDownload), the problem is that graphics
has not yet been integrated into MathAction. Doing so will require
solving some problems about using X-windows on the MathAction server.

\start
Date: Tue, 8 Nov 2005 06:05:40 -0800 (PST)
From: Cliff Yapp
To: William Sit
Subject: Re: Terms of Surrender (was: BAD tim)

--- William Sit wrote:

> C Y wrote:
> > I'm just saying that in an open source project discussion without
> > code ultimately goes nowhere.  I don't think that's a danger here,
> > but it has been known to effectively kill projects in the past.
> 
> Is that (projects getting killed) necessarily bad?

Well, I guess I was sort of viewing it as a waste.  I suppose other
views are possible.

> > Spad does of course depend on the underlying modules, but shouldn't
> > it (in theory) not need to care how they are implemented?  Sort of
> > the same way ANSI lisp code should run in any ANSI lisp 
> > implementation, without worrying about how the enviroment 
> > underneath it is coded up?
> 
> True, but we are talking about maintaining the system, not just the
> algebra code. There are bound to be modifications, if only because 
> versions of Lisp has changed.

True enough, but those will hopefully be minor.  (A lot of fixes to
Maxima have been this sort of thing - tracking different versions of
Lisps - so I admit it happens.)  I think it depends in part on how much
non-standardized (e.g. non ANSI) functionality we need or want to use.

> Even my limited experience tells me that codes will break if allowed
> to stay stagnant.

Also true, unfortunately.

> > If I'm not mistaken, the approach Tim has taken so far with vol5 is
> > resulting in documentation that applies equally well to Lisp and
> > Boot code - at least, the level of documentation he has started 
> > writing.  If it helps, perhaps the current state of included auto-
> > generated lisp code could represent proof that the current 
> > documentation is in fact applicable to both Boot and Lisp code 
> > (where the documentation covers such things instead of SPAD code) 
> > since they are demonstrably identical at this stage.  If you parse
> > out the lisp includes and build the book again, viola - documented
> > boot code.
> 
> Glad to know that.

I should admit that's based on a casual inspection of vol5 - I haven't
yet read through it in detail or actually tried generating a Boot only
file.  But the structure of printing both Boot and Lisp code together
suggests it would be possible to omit the autogenerated lisp and still
have a viable document.

> Tim has done that type of analysis on Axiom more than anyone else.
> But what I am looking for is even coarser: just the major components
> and how Lisp helps.

Ah, got it.

> > My original vision was that each package would have one of these
> > types of graphs as it's second page (sort of an "inside the cover"
> > addition if it were a book) that would allow a new programmer to 
> > immediately get a feel for the workflow of this particular part of
> > the system, and what parts it relates to.  Maybe this could apply 
> > to pamphlets.  Also it might allow programmers unfamiliar with how 
> > the system works to quickly zero in on which functions were 
> > possibly relevant to a particular bug.
> > For real fun perhaps these diagrams could be autogenerated by the
> > SPAD/Aldor parser as part of the compile :-).  Of course, higher
> > level ones might have to be done by hand, depending on how smart
> > the output routines were...
> 
> That would be useful for Tim's Crystal vision.

Tim, could a compiler output diagram information files or is that not
really viable?

\start
Date: Tue, 08 Nov 2005 08:21:01 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [HyperDocTracing] (new) 

The Trace Facility

  Axiom contains some powerful commands to help with testing and
debugging library modules written in Spad and also the Axiom system
itself. The most important of these commands is ')trace'.

This command is used to trace the execution of functions that make
up the Axiom system, functions defined by users, and functions from
the system library. Almost all options are available for each type
of function but exceptions will be noted below.

To list all functions, constructors, domains and packages that are
traced, simply issue::

  )trace

To untrace everything that is traced, issue::

  )trace )off

When a function is traced, the default system action is to display
the arguments to the function and the return value when the function
is exited. Other information can be displayed or collected when a
function is traced and this is controlled by the various options.
If a domain or package is traced, the default action is to trace all
functions exported. Individual interpreter, lisp or boot functions
can be traced by listing their names after ')trace'. Any options that
are present must follow the functions to be traced. For example::

  )trace f

traces the function f. To untrace f, issue::

  )trace f )off

Note that if a function name contains a special character, it will
be necessary to escape the character with an underscore::

  )trace _/D_,1

To trace all domains or packages that are or will be created from a
particular constructor, give the constructor name or abbreviation
after ')trace'::

  )trace MATRIX
  )trace List Integer

The first command traces all domains currently instantiated with
Matrix. If additional domains are instantiated with this constructor
(for example, if you have used 'Matrix(Integer)' and 'Matrix(Float)'),
they will be automatically traced. The second command traces
'List(Integer)'.

The following are the general options for the ')trace' command.

')break after' -- causes a Common Lisp break loop to be entered after
exiting the traced function.

')break before' -- causes a Common Lisp break loop to be entered before
entering the traced function.

')break' -- is the same as )break before.

')count' -- causes the system to keep a count of the number of times the
traced function is entered.

The total can be displayed with::

   )trace )stats

and cleared with::

   )trace )stats reset

')count n' -- causes information about the traced function to be displayed
for the first n executions. After the n-th execution, the function is
untraced.

')depth n' -- causes trace information to be shown for only n levels of
recursion of the traced function.

The command::

  )trace fib )depth 10

will cause the display of only 10 levels of trace information for the
recursive execution of a user function fib.

')math' causes -- the function arguments and return value to be displayed
in the Axiom monospace two-dimensional math format.

')nonquietly' -- causes the display of additional messages when a function
is traced.

')nt' -- This suppresses all normal trace information. This option is useful
if the ')count' or ')timer' options are used and you are interested in the
statistics but not the function calling information.

')off' -- causes untracing of all or specific functions. Without an argument,
all functions, constructors, domains and packages are untraced. Otherwise,
the given functions and other objects are untraced.

To immediately retrace the untraced functions, issue::

  )trace )restore

')only listOfDataToDisplay' -- causes only specific trace information to be
shown.

')restore' -- causes the last untraced functions to be retraced. If
additional options are present, they are added to those previously in
effect.

')stats' -- causes the display of statistics collected by the use of the
')count' and ')timer' options.

')stats reset' -- resets to 0 the statistics collected by the use of the
')count' and ')timer' options.

')timer' -- causes the system to keep a count of execution times for the
traced function. The total can be displayed with ')trace )stats' and
cleared with ')trace )stats reset'.

')varbreak var1 ... varN' -- causes a Common Lisp break loop to be
entered after the assignment to any of the listed variables in the
traced function.

')vars' -- causes the display of the value of any variable after it is
assigned in the traced function. Note that library code must have been
compiled using the ')vartrace' option in order to support this option.

')vars var1  ... varN' -- causes the display of the value of any of
the specified variables after they are assigned in the traced function.
Note that library code must have been compiled using the ')vartrace'
option in order to support this option.

')within executingFunction' -- causes the display of trace information
only if the traced function is called when the given executingFunction
is running.

The following are the options for tracing constructors, domains and
packages.

')local op1 ... opN' -- causes local functions of the constructor to
be traced. Note that to untrace an individual local function, you must
use the fully qualified internal name, using the escape character before
the semicolon. For example::

  )trace FRAC )local
  )trace FRAC_;cancelGcd )off

')ops op1 ... opN' -- By default, all operations from a domain or package
are traced when the domain or package is traced. This option allows you
to specify that only particular operations should be traced.

The command::

  )trace Integer )ops min max _+ _-

traces four operations from the domain Integer. Since + and - are special
characters, it is necessary to escape them with an underscore.

Also See: ')boot', ')lisp' , and ')ltrace'. Please refer to the
"Axiom Book":AxiomDocumentation, section "Axiom System Commands"
for more detailed information.

\start
Date: Tue, 08 Nov 2005 08:22:08 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [debugging Axiom] 

Fortunately, Axiom is rather easy to debug. Most of the source is very
transparent, so once you have localized the bug there are mostly
"design issues":DesignIssues to overcome. However, to find out which
function is bugged, there are some helpful tools.  These consist of:

  - inspecting signatures of operations and packages, domains and categories using::
      
       )display operation foo
       )show mydomain

  - seeing which functions are called using ')set message bottom on'

  - using the "trace facility":HyperDocTracing

Let's use the following might-be-bug as a running example:

\start
Date: Tue, 8 Nov 2005 06:31:38 -0800 (PST)
From: Cliff Yapp
To: Jay Belanger
Subject: Re: letting my mud settle

--- Jay Belanger wrote:

> 
> > *,
> 
> That's wild enough to include me.  I really don't have anything to
> contribute, but I thought I should delurk sometime.

Hey Jay! :-).  Glad to see you on the list.  

> It's probably largely due to hindsight and seeing how things turned
> out, but rewriting it in the pamphlet files was a fantastic thing.
> I can see how it could cause an opinion war, though.

Heh - a common thread between academics and open source ;-).
 
> > in the process of building the system and the Makefile tree i spent
> > a lot of time thinking about my past sins (and suffering from them
> > which is poetic justice).
> 
> I'm too clueless to even dream of commenting on past sins, but if
> they led, even indirectly, to where things are going now, I don't 
> think sins is the right word.

Agreed!

> > we can't do that now. and we can't do it in boot. the system is too
> > damn complex and badly designed/written/structured. construction is
> > always dirty, disruptive, and time consuming. i'm sorry that you'll
> > get to see my ugly hacking along the way. but, hey, that's open
> > source programming.
> 
> Seeing your "ugly hacking" may well be a good thing.  As a teacher, I
> try to make clear to my students that not everything starts off clean
> and polished; that leads to false sense of how things are really
> done, and can easily make good students feel inadequate. 
> ("This works great, but it seems to have been pulled out of thin 
> air.  I could certainly never come up with anything like this.")

Been there a few times.

> > i'm going to fix axiom.
> 
> How "broken" is it?  I'm working my way through the Axiom book, but
> haven't gotten very far yet.  (Whatever happened to the plans to
> publish it?  I would love to have a copy.  Right now I'm printing a
> few pages at a time to read.)  I would like to encourage people here
> to use it in class.

There was a wiki page set up here:
http://page.axiom-developer.org/zope/mathaction/AxiomBook

Tim and Bill, is that still in the works?  If we want to get the first
volume out the door soon I'd be glad to pitch in some effort to get it
ready.

> > i know how to get there from here.
> > it takes time.
> > it takes work.
> > it takes patience.
> >
> > and once this is done there is SO much more to do.
> > why, the algebra restructuring alone will take years...
> 
> A finished, polished Axiom would be nice.  But I've always enjoyed
> playing around with things trying to get them to work. Hopefully,
> I'll be able to help sometime in the near future.  (I only have about
> 10,000 pages left to read in the Axiom book.)

Heh.  It gets more tolerable when compared to Maxima, where if we want
to read a book on it we have to write it first ;-)

\start
Date: 08 Nov 2005 16:43:17 +0100
From: Martin Rubey
To: list
Subject: MathAction Contents

Dear all,

I have done some cosmetics to MathAction, primarily to address the complaint
that it's FrontPage was too loaded.

Unfortunately, my time is very limited and even with regard to Axiom, I think
it is better spent in writing packages and fixing bugs.

However, I feel that MathAction is very important. If you google for axiom it
is the 5th hit, and it's usage statistics are quite impressive. So, what's the
problem?

If you look at MathAction, it is easily summarized: there is too much
text. A lot is duplicated, and some things are difficult to find.

So here are some small projects anyone can do:

* Merge SummerOfCode and WishList

* Reorganize the pages about 

    Programming in Axiom

    Using Aldor for Axiom

    Debugging Axiom

    Development

    ...

  in a sensible way.

* Walk through the contents of MathAction and see which things belong together
  and should be regrouped.


If you embark on any of these projects, it may make sense to first create a
(hierarchy of) SandBox page(s) containing the newly organized content
(partially probably copied and pasted...), post a message on axiom-developer,
and wait for: go ahead!

I personally prefer StructuredText Markup. In future, everything should be
coded as pamphlets, but we are not there yet. (If you are interested in *that*
issue, connect yourself with

Ralf Hemmecke    who designed a wonderful Aldor documentation format, which
                 will hopefully replace our pamphlet format in near future

Kai Kaminski     who is in charge of the Axiom User Interface, thereby
                 hopefully writing the successor to HyperDoc, thereby
                 converting the .ht pages to the above mentioned format in near
                 future

jsMath & tex4ht  which will probably enable proper rendering of the pamphlet
                 successor on Mathaction.


Thanks,

Martin

Bill, how large is the text-only content of MathAction currently (i.e.,
withouth axiom--main-test-1, and similar stuff)? If it is not too big, could
you send it to me tarred and zipped?

\start
Date: Tue, 8 Nov 2005 11:34:01 -0500
From: Tim Daly
To: Bill Page
Subject: MuPad under trouble

God I hate to see such research die.

I hope they have a "deadman provision" to open source the work
if MuPAD/SciFace dies. Perhaps we could merge the efforts and
benefit in the long run. If they do open the code someone should
let me know.

I know that in the U.S. there is no NSF funding available for
Computer Algebra research. The argument seems to be that as
long as there are commercial ventures doing CA there is no need
for public funding. (Europe has been much more enlightened in 
this respect.)

It's a short-sighted view. Companies fail. And when they fail
they take their code with them. Witness IBM, during its failing
years, which sold Axiom. Witness Symbolics, which locked up Macsyma.

Even with individuals we lose work. Manual's work is still tied
up somewhere in INRIA.

Suppose it was Wolfram or Maplesoft that folded? What would become
of all of that research work? Will computational mathematics have
a huge black hole if these companies die?

I fear for the future of computational mathematics. 
The past century was the birth of the subject. 
This century will make for a very difficult childhood.

Is this how future science will live and die?

\start
Date: Tue, 8 Nov 2005 08:31:56 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: Re: MuPad under trouble

--- Tim Daly wrote:

> God I hate to see such research die.

Amen.
 
> I hope they have a "deadman provision" to open source the work
> if MuPAD/SciFace dies. Perhaps we could merge the efforts and
> benefit in the long run. If they do open the code someone should
> let me know.

I hope so too - trying to go head to head commercially with Mathematica
and Maple is going to be a difficult thing to do without the momentum
of the academic users behind it.

The relevant thread in sci.math.symbolic seems to be here:
http://groups.google.com/group/sci.math.symbolic/browse_thread/thread/1a8f61438235ceef/

> I know that in the U.S. there is no NSF funding available for
> Computer Algebra research. The argument seems to be that as
> long as there are commercial ventures doing CA there is no need
> for public funding. (Europe has been much more enlightened in 
> this respect.)

I hope this isn't about to change?

> It's a short-sighted view. Companies fail. And when they fail
> they take their code with them. Witness IBM, during its failing
> years, which sold Axiom. Witness Symbolics, which locked up Macsyma.

Amen.

> Even with individuals we lose work. Manual's work is still tied
> up somewhere in INRIA.

Can it be freed up?  I would think that's a resource that should be
preserved if at all possible.

> Suppose it was Wolfram or Maplesoft that folded? What would become
> of all of that research work? Will computational mathematics have
> a huge black hole if these companies die?

I think with those two the worst that will happen is they will
stagnate.  There are too many universities and companies that have
functionality that depends on them - there will probably be enough
licensing revenue to sustain them.  The cost of moving to something
else will be much higher than paying whatever is needed to keep them
running on the current setup and occasionally buying new licenses.

Whether there will be money for INNOVATIVE work on those systems,
however, remains to be seen.  I know at least some departments in my
old university stick with older versions of Mathematica because they
can't afford the upgrades, for example.  It's a lot harder to put forth
a business case for innovative work when the market gets tight - too
much risk of costs without returns.

> I fear for the future of computational mathematics. 
> The past century was the birth of the subject. 
> This century will make for a very difficult childhood.

I fear this might be true.

> Is this how future science will live and die?

In an environment where all funding is based on corporate thinking,
only ideas that can generate short term profits will be developed.  It
deeply worries me how prevelant such thinking is becoming, particularly
in universities and governments, but that's another post in another
forum.

It's too bad Mathsoft decided to look at just DOE-Macsyma for a
symbolic backend - funding some work on Axiom might also have produced
very interesting results.  I suppose they want an engineering system
though, and aren't much interested in the strongly typed environments. 

\start
Date: Tue, 8 Nov 2005 17:42:30 +0100 (CET)
From: Bertfried Fauser
To: Cliff Yapp
Subject: Re: MuPad under trouble

Hi,

	first, is that reliable information? If so it would be a desater
to the fruiltful and active work on the tremendouly good combinat package
of MuPad. However, some of those developers might have MuPad source, I
have to be inquisitive. Anyhow, it would have officially to go open
source.

	The combinat people integrated a tremendous amount of code from
symmetrica, partly SCHUR and forged from these special purpose (few used?)
programs a good tool. The point is that MuPad code is very AXIOMish and I
was thinking of 'stealing' some of teh combinat code for AXIOM, hmm,
perhaps the only way for that package not to perish...

sad news if true,

\start
Date: Tue, 8 Nov 2005 12:09:23 -0500
From: Bill Page
To: Tim Daly
Subject: RE: letting my mud settle

On November 7, 2005 10:20 PM Tim Daly wrote:
>...
> the task at that time was to rewrite the system into pamphlet
> files. had i proposed such a massive, pervasive rewrite this
> mailing list would have been aflame with opinion. and the
> consensus would certainly have been to NOT do a pamphlet
> rewrite or if so, use doxygen, texmacs, xml, etc.

I think Tim is wrong about this. I do not recall any objection
at all to the concept of using literate programming methods in
Axiom. I still do not hear any objections to the use of "pamphlet"
files. For the most part this change was just syntactical, i.e.
wrapping existing source code into a literate programming
container. That change was dealt with by expanding the make
scripts.

The only thing that I think was broken by this was that at the
same time as packaging stuff into pamphlet files, Tim also
decided to group the algebra source code modules (about 1,300
files) into a smaller number of pamphlet files (about 300). This
was not a bad idea in principle but it broke the link to the
source files what was built into the Axiom )show command and
into HyperDoc. See Issue #144

http://wiki.axiom-developer.org/144DomainAbbreviationIsNoLongerAssociatedWit
hFilename

because the relationship between pamphlet files and the Axiom
user interface had not been fully thought out. Of course this
can be fixed but it requires some thinking about how we want
this part of the Axiom user interface to work. Does it still
make sense to access Axiom algebra source files this way given
that pamphlet files mix algebra code and it's documentation in
raw LaTeX format? Perhaps a link to the dvi and/or pdf file
would be more appropriate, with a secondary link to the pamphlet
source file, e.g. like the pamphlet support on MathAction?

>
> in the process of building the system and the Makefile tree
> i spent a lot of time thinking about my past sins (and
> suffering from them which is poetic justice). as a result
> of that effort i decided that the system needed to be
> completely rewritten.

I am not aware of any of Tim's past sins -- only his present
ones. ;) Building Axiom from sources only, which was apparently
a requirement imposed by restrictive licensing conditions which
apparently prevented any of the previously commercial binary
versions of Axiom to be distributed along with the Axiom source
code, was certainly a challenge because of the way that Axiom
had been designed to be "bootstrapped" from an existing running
copy. But this is no different than the situation with most
compilers and in particular GNU C (gcc).

I think that William Sit is right that having accomplished this
bootstrap, it seems unnecessary to continue to distribute Axiom
in this way. It is now quite possible to return to the way Axiom
used to be distributed as binary code plus source code. Building
open source Axiom would then require a running version of open
source Axiom in exactly the same way that building gcc from
source code requires a running gcc.

Since this thread is at least partly devoted to "airing dirty
laundry", I should mention that in retrospect I think the specific
way in which Axiom algebra was bootstrapped from source, i.e. by
including machine generated lisp code from Spad compiler output
directly in the pamphlet files was probably not the best idea.
At the time Tim made this decision I was not really part of the
project and even if I had been I would not have understood then
that there was a better way. But now it is clear to me that the
cyclic dependencies in Axiom's library code are a result of the
fairly extensive use of mutual recursion, i.e. source modules
that naturally recursively depend on each other. This may not
have been especially obvious even to the original Axiom developers
since Axiom had always previously been built from an existing
running version of Axiom and the algebra code as written over a
fairly long period of time.

In theory the better way, instead of patching in the lisp output
of a previous version of Axiom, would have been (and which still
may be) to compile Spad "stub" files consisting only of the initial
code with all dependencies removed, for those Spad files which
had been specially selected to break the dependency cycles - or
for that matter, even compiling all existing Spad files - first
as "stubs' and then a second time in their full source form.

We have previously discussed this extensively as part of the
thread:

http://wiki.axiom-developer.org/17AlgebraBOOTSTRAPFixedPoint
http://wiki.axiom-developer.org/MutualRecursion

I think that recognizing this is important because it is
really a **feature** of the Spad language and the Axiom algebra
library in particular. It is not a *problem* as such, but rather
a challenge for the compiler developers. Aldor at least partially
addresses this through it's "extend" mechanism.

> the task at this time is to document it and clean it up.

I think as Tim will admit, that task is still at it's beginning
stage. Very few (maybe less than 10%) of the Axiom source code
pamphlet files currently contain any useful documentation besides
the comments contained in the original code. And even to get this
far Tim has had to devote a lot of time and effort to just creating
the amount of documentation that does exist and is essential to
building Axiom from the current source distribution - especially
in the make files.

> i need to get to the point of being able to say
>
>   (compile-file "interpreter.lisp") ; actually bookvol5
>   (load "interpreter")
>   (compile-file "compiler.lisp")    ; actually bookvol6
>   (load "compiler")
>   (compile-file "browser.lisp")     ; actually bookvol7
>   (load "browser")
>   (compile-file "graphics.lisp")    ; actually bookvol8
>   (load "graphics")
>   (axiom)
>

To me this vision of how to build Axiom seems terribly myopic.
I don't think it addresses the really important issues about
Axiom's design. And more over, getting a stage where something
like the above build sequence might be possible is likely to
both distract from the all important task of documentation plus
lead us away from some of the things that really need to be
documented most, e.g. the relationship between Spad, Boot and
Lisp.

> at that time we'll have a crisp, clean, documented, partitioned
> system and we will be able to understand the parts. we can
> rewrite them in aldor if someone steps up to it. or add new ones.
> for example
>
>   (compile-file "openmath-server.lisp") ; bookvol9?
>   (load "openmath-server")
>   (axiom :openmath-port 1234)
>

> we can't do that now. and we can't do it in boot. the system is
> too damn complex and badly designed/written/structured. construction
> is always dirty, disruptive, and time consuming.

Even with deficient documentation, I don't see anything that prevents
us from doing this sort of thing right now. I think Kai Kaminski's
work on AxiomUI is a good demonstration that this is indeed possible.

> i'm sorry that you'll get to see my ugly hacking along the way.
> but, hey, that's open source programming.

I don't think anyone here (except perhaps you, Tim) is worried about
seeing "ugly hacking". All of that is an expected part of any large
programming project. What is much more important are the conceptual
issues and the overall approach. Is your approach one that will
encourage other developers to help with the task or is it one that
makes it likely that only for you to carry-out all the work?

>
> i'm going to fix axiom.
> i know how to get there from here.
> it takes time.
> it takes work.
> it takes patience.
>

As you say: "that's open source programming", but I don't think
that it must be this way.

> and once this is done there is SO much more to do.
> why, the algebra restructuring alone will take years...
>

I agree that Axiom's 30 year horizon is not unrealistic except
for the human physical limitations of lifespan (and attention
span :). I think that if Axiom is really going to continue to
live passed the span of it's original developers, then we must
plan very carefully to attract and keep a new generation of
developers. This is the "bottom line" that motivates me to
continue this rather difficult thread of discussion.

\start
Date: Tue, 08 Nov 2005 18:16:10 +0100
From: Michel Lavaud
To: Bill Page
Subject: re: [fspace.spad] dvi file display

On 7 Nov 2005 at 9:22, Bill Page wrote:

> Willaim,
> 
> Thanks for noticing this. I get the a similar error when I try
> to open the dvi file using Yap from MikTeX. But this is very
> strange because I can open other dvi files and I can even open
> this file in pdf format even though the pdf format is created from the
> dvi using dvipdfm.
> 
> The file does contain some very long lines of machine generated
> lisp bootstrap code. Maybe that is a problem for dvi viewers?
> I will try adding some new lines in this code and see if that fixes
> the problem.
> 
> Have any seen this error with any other source files?
> 
> Can anyone reproduce this problem using a dvi viewer on linux?
> 
> Regards,
> Bill Page.
> 
> On November 7, 2005 3:50 AM William Sit wrote:
> 
> > 
> > Changes 
> > http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FspaceSpa
> > d/diff -- I click on the dvi (OS: Windows XP, dvi viewer: DVIWIN).
> > It is a 118 page document with the first 84 pages "gabbage"
> > consisting mainly of a few symbols a page. On p. 85, the title page
> > appears, followed by a table of contents, followed by the source
> > code (except that spaces become xxx's).
> > 
> > DVIWIN reports the following error messages ::
> > 
> > \begin{verbatim}
> > Opening c:\docume~1\william\locals~1\temp\fspace~1.dvi 
> > (118 pages)
> > [1]
> > TeX \special{t4ht@[} ignored
> > ...

I suspect you are viewing with Dviwin, a dvi file produced by TeX4ht ?
TeX4ht produces an intermediate dvi file (because it uses TeX to
resolve user-defined or package-defined TeX commands), but this dvi
file is not to be viewed with a dvi viewer, it is not what one would
get by running TeX directly. The real/usable/viewable output is the
html file(s) produced by TeX4ht.

\start
Date: Tue, 08 Nov 2005 11:12:55 -0600
From: Jay Belanger
To: Bertfried Fauser
Subject: Re: MuPad under trouble

Bertfried Fauser writes:

> Hi,
>
> 	first, is that reliable information?

I think so.  The thread that CY linked to had a link to the MuPAD
founder's website, http://fuchssteiner.info/, which discusses it, and
the thread also contains comments from Christopher Creutzig, a MuPAD
developer (although he says he's not technically a developer).

I don't see MuPAD going away soon; I think there are some big projects
that use it, but its user base will shrink quite a bit (most users use
a free license), and so its long term viability doesn't look good.

> If so it would be a desater to the fruiltful and active work on the
> tremendouly good combinat package of MuPad. However, some of those
> developers might have MuPad source, I have to be
> inquisitive. Anyhow, it would have officially to go open source.

Right now, it seems to be going the other way: more commercial.
The library sources have always been available to read, and there was
talk about putting them under a free license.  I don't know if that's
still the plan or not.

> The point is that MuPad code is very AXIOMish

I know some people working with Scratchpad switched to MuPAD; perhaps
they'll come back.

> and I was thinking of 'stealing' some of teh combinat code for
> AXIOM, hmm, perhaps the only way for that package not to perish...

Is the combinatoric code in the kernel or libraries?  If the
libraries, it can at least be studied, and the authors' names are
listed so perhaps you can get permission to port it.

\start
Date: Tue, 8 Nov 2005 12:27:07 -0500
From: Bill Page
To: Michel Lavaud
Subject: re: [fspace.spad] dvi file display

On November 8, 2005 12:16 PM Michel Lavaud
> ... 
> I suspect you are viewing with Dviwin, a dvi file produced by 
> TeX4ht ? TeX4ht produces an intermediate dvi file (because it
> uses TeX to resolve user-defined or package-defined TeX commands),
> but this dvi file is not to be viewed with a dvi viewer, it is
> not what one would get by running TeX directly. The
> real/usable/viewable output is the html file(s) produced by
> TeX4ht.

Thanks, Michel. I think you are right about this. In my haste
and limited time available to implement pamphlet support on
MathAction, I did do a number of experiments with alternative
ways to render LaTeX as HTML. TeX4ht was one of these. It seems
that due to my error, the file that William Sit tried to view
was simply "left over" from such experiments. When I updated the
pamphlet file for fspace.spad with the new source provided by
Tim, these old experiments were overwritten with the correctly
formatted files and everything appears to work now.

Note: This was not a problem with TeX4ht which I think works
extremely well in most cases. Recall that according to some emails
exchanged here a few weeks ago, the author of this package is also
planning to extend it to support jsmath format LaTeX output and
I think that would make it ideal for many web applications. The
problem was only due to my not cleaning things up properly after
my experiments.

\start
Date: Tue, 8 Nov 2005 13:54:54 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Tim Daly
Subject: RE: letting my mud settle

--- Bill Page wrote:

> I am not aware of any of Tim's past sins -- only his present
> ones. ;) Building Axiom from sources only, which was apparently
> a requirement imposed by restrictive licensing conditions which
> apparently prevented any of the previously commercial binary
> versions of Axiom to be distributed along with the Axiom source
> code, was certainly a challenge because of the way that Axiom
> had been designed to be "bootstrapped" from an existing running
> copy. But this is no different than the situation with most
> compilers and in particular GNU C (gcc).

Personally, I would be happier with a system that can be bootstrapped. 
I know at some point you need a compiler to make a compiler unless you
want to feed binary into the machine by hand (which happened at some
point in the remote mists of computer past) but I have always disliked
the idea of needing a running program in order to build new versions of
that program.  You are implicitly trusting a binary when you do that,
and I like the idea of a system being completely buildable from source
code.  I suppose the realization of that in reality would require a
hardware compiler for some minimalistic language.  Hmm...  I wonder how
hard it would be to design a printed circuit board that compiles
lisp... ;-)

> I think that William Sit is right that having accomplished this
> bootstrap, it seems unnecessary to continue to distribute Axiom
> in this way. It is now quite possible to return to the way Axiom
> used to be distributed as binary code plus source code. Building
> open source Axiom would then require a running version of open
> source Axiom in exactly the same way that building gcc from
> source code requires a running gcc.

What about a platform that has no running Axiom binary?  gcc, IIRC,
solves this by a rather convoluted process called cross compilation? 
It would be nice not to have to worry about such issues for Axiom - why
not keep the design goal of building Axiom using only a working ANSI
Lisp?

> Since this thread is at least partly devoted to "airing dirty
> laundry", I should mention that in retrospect I think the specific
> way in which Axiom algebra was bootstrapped from source, i.e. by
> including machine generated lisp code from Spad compiler output
> directly in the pamphlet files was probably not the best idea.

Well, a cleaner solution would be nice, but hopefully rewriting the
source in Lisp would allow us to unknot this situation.

> At the time Tim made this decision I was not really part of the
> project and even if I had been I would not have understood then
> that there was a better way. But now it is clear to me that the
> cyclic dependencies in Axiom's library code are a result of the
> fairly extensive use of mutual recursion, i.e. source modules
> that naturally recursively depend on each other.

This bothers me in principle.  Why is this necessary?  I for one would
prefer to change this situation, if it can be changed.  Chicken-egg
situations are seldom desirable.

> This may not have been especially obvious even to the original 
> Axiom developers since Axiom had always previously been built from 
> an existing running version of Axiom and the algebra code as written
> over a fairly long period of time.

I worry about a case in the future in which the Axiom code might have
to be built without any working binaries of Axiom - what happens then? 
We've already seen the pain this situation caused once.

> In theory the better way, instead of patching in the lisp output
> of a previous version of Axiom, would have been (and which still
> may be) to compile Spad "stub" files consisting only of the initial
> code with all dependencies removed, for those Spad files which
> had been specially selected to break the dependency cycles - or
> for that matter, even compiling all existing Spad files - first
> as "stubs' and then a second time in their full source form.

If a "stub" file satisfies the dependancy requirement, is there really
a circular dependence in the first place?  Maybe I'm not understanding
how that really works.
 
> We have previously discussed this extensively as part of the
> thread:
> 
> http://wiki.axiom-developer.org/17AlgebraBOOTSTRAPFixedPoint
> http://wiki.axiom-developer.org/MutualRecursion
> 
> I think that recognizing this is important because it is
> really a **feature** of the Spad language and the Axiom algebra
> library in particular. It is not a *problem* as such, but rather
> a challenge for the compiler developers. Aldor at least partially
> addresses this through it's "extend" mechanism.

Circular dependence is a feature?  I'm afraid I'm not following, if I
understand you correctly - how can this be an advantage?

> > the task at this time is to document it and clean it up.
> 
> I think as Tim will admit, that task is still at it's beginning
> stage. Very few (maybe less than 10%) of the Axiom source code
> pamphlet files currently contain any useful documentation besides
> the comments contained in the original code. And even to get this
> far Tim has had to devote a lot of time and effort to just creating
> the amount of documentation that does exist and is essential to
> building Axiom from the current source distribution - especially
> in the make files.

Tim, is the plan to retain the ability to build from source only in the
future? 

> > i need to get to the point of being able to say 
> > 
> >   (compile-file "interpreter.lisp") ; actually bookvol5
> >   (load "interpreter")
> >   (compile-file "compiler.lisp")    ; actually bookvol6
> >   (load "compiler")
> >   (compile-file "browser.lisp")     ; actually bookvol7
> >   (load "browser")
> >   (compile-file "graphics.lisp")    ; actually bookvol8
> >   (load "graphics")
> >   (axiom)
> > 
> 
> To me this vision of how to build Axiom seems terribly myopic.
> I don't think it addresses the really important issues about
> Axiom's design. And more over, getting a stage where something
> like the above build sequence might be possible is likely to
> both distract from the all important task of documentation plus
> lead us away from some of the things that really need to be
> documented most, e.g. the relationship between Spad, Boot and
> Lisp.

Perhaps a lisp rewrite with documentation occurring along the way will
address all of these concerns, depending on how it is done.

\start
Date: Tue, 8 Nov 2005 21:35:49 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: letting my mud settle

On November 8, 2005 4:55 PM C Y wrote:
> 
> Personally, I would be happier with a system that can be 
> bootstrapped. 

I started writing a long explanation about bootstrapping
and all that, but thanks to the magic of Wikipedia I don't
have to bother, I can just point:

http://en.wikipedia.org/wiki/Bootstrap

and you can instantly find out all kinds of things like the
importance of Robert Heinlein to the concept. :)

More specific to this discussion is:

http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29

The design of bootstrapping compilers has a long and
venerable history and Axiom happens to be one of these
types of systems.

> 
> > I think that William Sit is right that having accomplished
> > this bootstrap, it seems unnecessary to continue to distribute
> > Axiom in this way. It is now quite possible to return to the
> > way Axiom used to be distributed as binary code plus source
> > code. Building open source Axiom would then require a running
> > version of open source Axiom in exactly the same way that
> > building gcc from source code requires a running gcc.
> 
> What about a platform that has no running Axiom binary?  gcc,
> IIRC, solves this by a rather convoluted process called cross
> compilation?

No. Cross compilation is a simple and common operation.

This is essentially the situation that Tim was in when he
first received the Axiom source code for the open source
distribution and cross compilation was the method by which
he solved that problem. He used Axiom (actually just parts
of Axiom) running on another system to generate the lisp
code that he then copied to the open source distribution so
that those algebra modules that needed to be present before
the rest of the library could be compiled, could first be
compiled from the lisp code. Of course it wasn't quite that
simple - some hand coded changes to the machine generated
lisp code was necessary because the target lisp environment
was not the same as the lisp on the host machine.
 
> It would be nice not to have to worry about such issues
> for Axiom - why not keep the design goal of building Axiom
> using only a working ANSI Lisp?

Because that means having to maintain two versions - a lisp
version and a spad version of quite a few Axiom library
modules. And if changes are made to any of the spad code in
one of these modules, the lisp code must be re-generated.
All of this is well described in Tim's documentation.

If we could return to the original way of building Axiom,
then this error-prone process is not required.

> 
> > Since this thread is at least partly devoted to "airing
> > dirty laundry", I should mention that in retrospect I think
> > the specific way in which Axiom algebra was bootstrapped
> > from source, i.e. by including machine generated lisp code
> > from Spad compiler output directly in the pamphlet files was
> > probably not the best idea.
> 
> Well, a cleaner solution would be nice, but hopefully rewriting
> the source in Lisp would allow us to unknot this situation.

No. I think you must not understand what I said above. The
Lisp code is part of the bootstrap. It does not in anyway
"unknot" the situation.

> 
> > At the time Tim made this decision I was not really part of
> > the project and even if I had been I would not have understood
> > then that there was a better way. But now it is clear to me
> > that the cyclic dependencies in Axiom's library code are a
> > result of the fairly extensive use of mutual recursion, i.e.
> > source modules that naturally recursively depend on each other.
> 
> This bothers me in principle.  Why is this necessary?  I for
> one would prefer to change this situation, if it can be changed.
> Chicken-egg situations are seldom desirable.

Sigh. I feel like we have already been around this circle
several times... :) Well, I suppose it might be considered a
rather difficult concept, so it doesn't hurt to try to say it
all again another way ... see below. I hope you don't mind that
this email is a rather long as a result.

> 
> > This may not have been especially obvious even to the original 
> > Axiom developers since Axiom had always previously been built
> > from an existing running version of Axiom and the algebra code
> > was written over a fairly long period of time.
> 
> I worry about a case in the future in which the Axiom code
> might have to be built without any working binaries of Axiom -
> what happens then? We've already seen the pain this situation
> caused once.
> 

Axiom is open source, like gcc and gcl. So you might as well be
saying: what happens if we want to build Axiom and we have no C
compiler or lisp system?

Actually, I don't think it could have been that painful - just
a lot of tedious work. But I should let Tim speak to that. I
know that determining which modules to use in the bootstrap
was not easy because that means essentially having to do a
topological sort of the dependencies among the 1,300 modules
and finding the cycles. Tim used a simple but tedious process
to do this that probably did not result in an optimal (smallest)
set of bootstrap modules. But that is a minor detail.

> > In theory the better way, instead of patching in the lisp
> > output of a previous version of Axiom, would have been (and
> > which still may be) to compile Spad "stub" files consisting
> > only of the initial code with all dependencies removed, for
> > those Spad files which had been specially selected to break
> > the dependency cycles - or for that matter, even compiling
> > all existing Spad files - first as "stubs' and then a second
> > time in their full source form.
> 
> If a "stub" file satisfies the dependency requirement, is there
> really a circular dependence in the first place?  Maybe I'm not
> understanding how that really works.

No, the "stub" does not really satisfy any dependencies, it is
really just a like an empty "place holder" the same way the lisp
bootstrap code is now. As the last steps of the build cycle (just
as is done now) these place holder modules are re-compiled directly
from the Spad code. In the current build process all of the
bootstrap modules are compiled twice - first as lisp routines
and finally as Spad routines. That completes one full cycle.
Usually that is all that is done. But as the analysis that I
referred to below shows this is not quite enough since some
to the dependencies do cycle back to affect code that has
already been compiled. However we believe (but have not proven!)
that this affects only some of the optimization that the Spad
compiler would have done and not that actual semantics of the
programs.

The idea of a Spad stub module is not my idea. I think it was
first mentioned by Peter Broadbery in

http://lists.nongnu.org/archive/html/axiom-developer/2005-01/msg00519.html

He wrote:

"Much of the circularity comes mainly from exported signatures -
It _may_ be possible to statically determine all the type signatures
from the .spad files, write out as a bootstrap definition, then
compile against these definitions."

That is what I meant by "stub".

>  
> > We have previously discussed this extensively as part of the
> > thread:
> > 
> > http://wiki.axiom-developer.org/17AlgebraBOOTSTRAPFixedPoint
> > http://wiki.axiom-developer.org/MutualRecursion
> > 
> > I think that recognizing this is important because it is
> > really a **feature** of the Spad language and the Axiom algebra
> > library in particular. It is not a *problem* as such, but rather
> > a challenge for the compiler developers. Aldor at least partially
> > addresses this through it's "extend" mechanism.
> 
> Circular dependence is a feature?  I'm afraid I'm not following,
> if I understand you correctly - how can this be an advantage?

Yes it is an advantage - quite a major one. Of all of the things
that I have studied while learning about Axiom, this is the one
things about which I am still most excited. I have to admit that
I do not fully understand all of the implications yet. But the
idea is really very simple.

Consider for example the problem of solving a system of linear
equations:

  1)  y = a1 x + b1

  2)  x = a2 y + b2

Each of these equations might make perfectly good sense in
it's own context. In the first case we assume x is known and
we just need to compute y. Or in the case of 2) we assume y
is known and we need to compute x. But taken together these
are circular!

Actually the formal relationship between solutions of equations
and mutual recursion is a very general one that is worked out
in some detail in a book called "Vicious Circles" by Barwise and
Moss, to which I have referred before on several occasions.
This kind of circularity can easily be confused with the
idea of "circular logic" which is a kind of logical fallacy.
But really it has more in common with the idea of "positive
feedback" in the context of automatic control systems in
engineering. The right kind of positive feedback can lead to
a stable solution (also called a fixed point).

So this is the lesson: Circularity is often a *good* thing,
because it allows us to specify what we want very simply and
clearly, but it implies the need for a *solution*.

One of the ways of trying to solve this circularity is just
to "break" it by starting with a good (lucky?) guess for x
in step 1). Then when we come to step 2) and actually calculate
x from the y that we calculated in step 1) we will find that
it is the same (or maybe almost the same). If it is not quite
the same, then we can trying feeding the answer from 2) back
into 1) and try again. This is exactly analogous to the situation
that we are in with respect to the Axiom algebra library.

It turns out that unlike the case of the circularity in a
system of linear equations where using a guess and simply
repeating the calculation will not work very well, in most
(maybe all?) cases of circularity in the Axiom library, this
process does seem to lead to the exact and stable solution
after going 3 times around the loop, i.e. re-compiling all
of the Axiom library code three times, each time feeding the
bootstrap that results from the final stage of each cycle,
back into the start of the next cycle.

Is this clear? Can you see what the implications of this
are and why I think it is both a *feature* (answer: because
it allows the Axiom library code to be written in a manner
that is simpler and more self-contained, module by module)
and also something about which we have to be rather careful
(answer: because this circularity implies the need for a
solution strategy)?

If not, then I am certainly willing to try to answer questions,
because I am convinced that understanding this is important
to the overall design of Axiom.

\start
Date: Wed, 09 Nov 2005 09:11:46 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: MuPad under trouble

Helllo,

>> Even with individuals we lose work. Manual's work is still tied
>> up somewhere in INRIA.

> Can it be freed up?  I would think that's a resource that should be
> preserved if at all possible.

Stephane Dalmas is the responsible 
person at INRIA. I've already asked him about Manuel's software. He told 
me that it will be released under an open source license. Is is not yet 
fixed which one and he was very busy with other things, but Manuel's 
work will eventually become accessible.

\start
Date: Wed, 09 Nov 2005 00:40:49 -0800
From: Karl Hegbloom
To: list
Subject: Another literate programming system you might like.

What do yous think of this:

 http://www.cse.ohio-state.edu/~gurari/tug97/vis-lit.html

Would it be useful for Axiom?

 http://www.cse.ohio-state.edu/~gurari/systems.html

\start
Date: 09 Nov 2005 11:03:45 +0100
From: Martin Rubey
To: Bertfried Fauser, Nicolas Thiery
Subject: Re: MuPad under trouble

Dear Nicolas, Bertfried, *

Nicolas: I'm copying this to you, since I'd like you to correct me if I'm
mistaken...

Bertfried Fauser writes:

> The combinat people integrated a tremendous amount of code from symmetrica,
> partly SCHUR and forged from these special purpose (few used?)  programs a
> good tool. The point is that MuPad code is very AXIOMish

But you do know that MuPAD Combinat itself is released under the LGPL? See:

http://sourceforge.net/projects/mupad-combinat/

In fact, summer last year I asked Nicolas Thiery about porting Combinat to
Axiom and he seemed *very* much in favor of it. (In order to have a second
platform. *NOT* as a replacement, of course.) So this can and should certainly
be done. I also put it as an item on the MathAction WishList, in fact...

To do the porting, it would be great if somebody knowledgeable of the bigger
structures in MuPAD (i.e., what does a domain, a category look like) would
write a bunch of regexps that would save us a bit of typing...

Other than that, Nicolas is *very* responsive, and he gave me some suggestions
where to start, but I admit, I forgot.

So, dig in!

\start
Date: Wed, 9 Nov 2005 10:40:09 +0000
From: Mike Dewar
To: Bill Page
Subject: Re: letting my mud settle

On Tue, Nov 08, 2005 at 12:09:23PM -0500, Bill Page wrote:
> I am not aware of any of Tim's past sins -- only his present
> ones. ;) Building Axiom from sources only, which was apparently
> a requirement imposed by restrictive licensing conditions which
> apparently prevented any of the previously commercial binary
> versions of Axiom to be distributed along with the Axiom source
> code, was certainly a challenge because of the way that Axiom
> had been designed to be "bootstrapped" from an existing running
> copy. But this is no different than the situation with most
> compilers and in particular GNU C (gcc).
Just for the record this is not true.  Arthur Norman offered to provide
an open-source version of CCL to the project which would have allowed
you to build and distribute a Unix version of Axiom from the original NAG
sources without any modifications.  I provided copies of the Axiom
product to several people on the list so you would have had no problem
bootstrapping the first open-source versions from the NAG code.

Eliminating the need for a running Axiom was a good thing to do, but if
anything forced you to do it it was probably the decision to develop on
GCL rather than CCL.

\start
Date: Wed, 9 Nov 2005 11:41:17 +0100 (CET)
From: Bertfried Fauser
To: Martin Rubey
Subject: Re: MuPad under trouble
Cc: Nicolas Thiery

On 9 Nov 2005, Martin Rubey wrote:

Hello Martin,

I knew that MuPad Combinat is open source. And I had some discussions with
Tomazet and other Marn le Valle people about a port and *they* told me its
easy. However, for me its rather difficult to see what the combinat code
does, furthermore, some additional code, as that of symmetrica is included
as C source code and would have to undergo a major change though. And last
but not least, its a tremendous amount of code (200.000 lines was told to
me ?)
	For me the stopping line was, that major features of SCHUR, which
I need for my research work are *not (yet?)* included in Combinat, so that
issue would come on top of it. Given my abilities in programming I don't
feel fit for such a task. Hence my Idea to steal what I need and build
around some own functions...

By tha way: Is there a possibility for AXIOM to interact with external
C-functions via a sort of wrapper?

ciao
BF.

> Dear Nicolas, Bertfried, *
>
> Nicolas: I'm copying this to you, since I'd like you to correct me if I'm
> mistaken...
>
> Bertfried Fauser writes:
>
> > The combinat people integrated a tremendous amount of code from symmetrica,
> > partly SCHUR and forged from these special purpose (few used?)  programs a
> > good tool. The point is that MuPad code is very AXIOMish
>
> But you do know that MuPAD Combinat itself is released under the LGPL? See:
>
> http://sourceforge.net/projects/mupad-combinat/
>
> In fact, summer last year I asked Nicolas Thiery about porting Combinat to
> Axiom and he seemed *very* much in favor of it. (In order to have a second
> platform. *NOT* as a replacement, of course.) So this can and should certainly
> be done. I also put it as an item on the MathAction WishList, in fact...
>
> To do the porting, it would be great if somebody knowledgeable of the bigger
> structures in MuPAD (i.e., what does a domain, a category look like) would
> write a bunch of regexps that would save us a bit of typing...
>
> Other than that, Nicolas is *very* responsive, and he gave me some suggestions
> where to start, but I admit, I forgot.
>
> So, dig in!

\start
Date: Wed, 09 Nov 2005 13:33:53 +0100
From: Ralf Hemmecke
To: Bertfried Fauser
Subject: Re: MuPad under trouble
Cc: Nicolas Thiery

Hello,

> By tha way: Is there a possibility for AXIOM to interact with external
> C-functions via a sort of wrapper?

Given that AXIOM is in some way connected to Aldor the following link 
should provide an answer.

http://www.aldor.org/docs/HTML/chap19.html

I am however not really sure whether the connection works if the code is 
compiled to LISP (as it must for AXIOM). Is there someone who knows?

\start
Date: Wed, 9 Nov 2005 06:16:41 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: letting my mud settle

--- Bill Page wrote:

> On November 8, 2005 4:55 PM C Y wrote:
> > 
> > Personally, I would be happier with a system that can be 
> > bootstrapped. 
> 
> I started writing a long explanation about bootstrapping
> and all that, but thanks to the magic of Wikipedia I don't
> have to bother, I can just point:
> 
> http://en.wikipedia.org/wiki/Bootstrap
> 
> and you can instantly find out all kinds of things like the
> importance of Robert Heinlein to the concept. :)

Cool!  I'll take a look.

> More specific to this discussion is:
> 
> http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
> 
> The design of bootstrapping compilers has a long and
> venerable history and Axiom happens to be one of these
> types of systems.

OK.
 
> > > I think that William Sit is right that having accomplished
> > > this bootstrap, it seems unnecessary to continue to distribute
> > > Axiom in this way. It is now quite possible to return to the
> > > way Axiom used to be distributed as binary code plus source
> > > code. Building open source Axiom would then require a running
> > > version of open source Axiom in exactly the same way that
> > > building gcc from source code requires a running gcc.
> > 
> > What about a platform that has no running Axiom binary?  gcc,
> > IIRC, solves this by a rather convoluted process called cross
> > compilation?
> 
> No. Cross compilation is a simple and common operation.

Heh :-).  OK, I'll stop worrying then.

> This is essentially the situation that Tim was in when he
> first received the Axiom source code for the open source
> distribution and cross compilation was the method by which
> he solved that problem. He used Axiom (actually just parts
> of Axiom) running on another system to generate the lisp
> code that he then copied to the open source distribution so
> that those algebra modules that needed to be present before
> the rest of the library could be compiled, could first be
> compiled from the lisp code. Of course it wasn't quite that
> simple - some hand coded changes to the machine generated
> lisp code was necessary because the target lisp environment
> was not the same as the lisp on the host machine.

Ah, OK.  So as long as we preserve a copy of this original version with
which to compile future versions, we are in the clear.

> > It would be nice not to have to worry about such issues
> > for Axiom - why not keep the design goal of building Axiom
> > using only a working ANSI Lisp?
> 
> Because that means having to maintain two versions - a lisp
> version and a spad version of quite a few Axiom library
> modules. And if changes are made to any of the spad code in
> one of these modules, the lisp code must be re-generated.
> All of this is well described in Tim's documentation.

OK.  I'll try to do some reading.

> If we could return to the original way of building Axiom,
> then this error-prone process is not required.
> 
> > 
> > > Since this thread is at least partly devoted to "airing
> > > dirty laundry", I should mention that in retrospect I think
> > > the specific way in which Axiom algebra was bootstrapped
> > > from source, i.e. by including machine generated lisp code
> > > from Spad compiler output directly in the pamphlet files was
> > > probably not the best idea.
> > 
> > Well, a cleaner solution would be nice, but hopefully rewriting
> > the source in Lisp would allow us to unknot this situation.
> 
> No. I think you must not understand what I said above. The
> Lisp code is part of the bootstrap. It does not in anyway
> "unknot" the situation.

I think I just don't properly understand compiler technology, so I'll
hush up until I know enough to talk intelligently.

> > > At the time Tim made this decision I was not really part of
> > > the project and even if I had been I would not have understood
> > > then that there was a better way. But now it is clear to me
> > > that the cyclic dependencies in Axiom's library code are a
> > > result of the fairly extensive use of mutual recursion, i.e.
> > > source modules that naturally recursively depend on each other.
> > 
> > This bothers me in principle.  Why is this necessary?  I for
> > one would prefer to change this situation, if it can be changed.
> > Chicken-egg situations are seldom desirable.
> 
> Sigh. I feel like we have already been around this circle
> several times... :) Well, I suppose it might be considered a
> rather difficult concept, so it doesn't hurt to try to say it
> all again another way ... see below. I hope you don't mind that
> this email is a rather long as a result.

Sorry!  I don't mean to cause a rehash.  I'll go back and look over the
older discussions.
 
> > > This may not have been especially obvious even to the original 
> > > Axiom developers since Axiom had always previously been built
> > > from an existing running version of Axiom and the algebra code
> > > was written over a fairly long period of time.
> > 
> > I worry about a case in the future in which the Axiom code
> > might have to be built without any working binaries of Axiom -
> > what happens then? We've already seen the pain this situation
> > caused once.
> 
> Axiom is open source, like gcc and gcl. So you might as well be
> saying: what happens if we want to build Axiom and we have no C
> compiler or lisp system?

Not a bad question to ask, actually, but I suppose the answer is so
much trouble and the problem so unlikely as to not be worth worrying
about.

> Actually, I don't think it could have been that painful - just
> a lot of tedious work. But I should let Tim speak to that. I
> know that determining which modules to use in the bootstrap
> was not easy because that means essentially having to do a
> topological sort of the dependencies among the 1,300 modules
> and finding the cycles. Tim used a simple but tedious process
> to do this that probably did not result in an optimal (smallest)
> set of bootstrap modules. But that is a minor detail.

Ah.  And even more minor if we aren't going to need to keep
bootstrapping.

> > If a "stub" file satisfies the dependency requirement, is there
> > really a circular dependence in the first place?  Maybe I'm not
> > understanding how that really works.
> 
> No, the "stub" does not really satisfy any dependencies, it is
> really just a like an empty "place holder" the same way the lisp
> bootstrap code is now. As the last steps of the build cycle (just
> as is done now) these place holder modules are re-compiled directly
> from the Spad code. In the current build process all of the
> bootstrap modules are compiled twice - first as lisp routines
> and finally as Spad routines. That completes one full cycle.
> Usually that is all that is done. But as the analysis that I
> referred to below shows this is not quite enough since some
> to the dependencies do cycle back to affect code that has
> already been compiled. However we believe (but have not proven!)
> that this affects only some of the optimization that the Spad
> compiler would have done and not that actual semantics of the
> programs.

Hmm.  I take it at some point we should either demonstrate that or
generate a binary using enough cycles so things iterate to steady
state?

> The idea of a Spad stub module is not my idea. I think it was
> first mentioned by Peter Broadbery in
> 
>
http://lists.nongnu.org/archive/html/axiom-developer/2005-01/msg00519.html
> 
> He wrote:
> 
> "Much of the circularity comes mainly from exported signatures -
> It _may_ be possible to statically determine all the type signatures
> from the .spad files, write out as a bootstrap definition, then
> compile against these definitions."
> 
> That is what I meant by "stub".

Got it.

> > > We have previously discussed this extensively as part of the
> > > thread:
> > > 
> > > http://wiki.axiom-developer.org/17AlgebraBOOTSTRAPFixedPoint
> > > http://wiki.axiom-developer.org/MutualRecursion
> > > 
> > > I think that recognizing this is important because it is
> > > really a **feature** of the Spad language and the Axiom algebra
> > > library in particular. It is not a *problem* as such, but rather
> > > a challenge for the compiler developers. Aldor at least partially
> > > addresses this through it's "extend" mechanism.
> > 
> > Circular dependence is a feature?  I'm afraid I'm not following,
> > if I understand you correctly - how can this be an advantage?
> 
> Yes it is an advantage - quite a major one. Of all of the things
> that I have studied while learning about Axiom, this is the one
> things about which I am still most excited. I have to admit that
> I do not fully understand all of the implications yet. But the
> idea is really very simple.

If you don't understand all the implications I'm most likely sunk, at
least for a while :-).

> Consider for example the problem of solving a system of linear
> equations:
> 
>   1)  y = a1 x + b1
> 
>   2)  x = a2 y + b2
> 
> Each of these equations might make perfectly good sense in
> it's own context. In the first case we assume x is known and
> we just need to compute y. Or in the case of 2) we assume y
> is known and we need to compute x. But taken together these
> are circular!
> 
> Actually the formal relationship between solutions of equations
> and mutual recursion is a very general one that is worked out
> in some detail in a book called "Vicious Circles" by Barwise and
> Moss, to which I have referred before on several occasions.
> This kind of circularity can easily be confused with the
> idea of "circular logic" which is a kind of logical fallacy.

I think that's what I might be doing.

> But really it has more in common with the idea of "positive
> feedback" in the context of automatic control systems in
> engineering. The right kind of positive feedback can lead to
> a stable solution (also called a fixed point).

Ah :-).

> So this is the lesson: Circularity is often a *good* thing,
> because it allows us to specify what we want very simply and
> clearly, but it implies the need for a *solution*.

OK.

> One of the ways of trying to solve this circularity is just
> to "break" it by starting with a good (lucky?) guess for x
> in step 1). Then when we come to step 2) and actually calculate
> x from the y that we calculated in step 1) we will find that
> it is the same (or maybe almost the same). If it is not quite
> the same, then we can trying feeding the answer from 2) back
> into 1) and try again. This is exactly analogous to the situation
> that we are in with respect to the Axiom algebra library.
>
> It turns out that unlike the case of the circularity in a
> system of linear equations where using a guess and simply
> repeating the calculation will not work very well, in most
> (maybe all?) cases of circularity in the Axiom library, this
> process does seem to lead to the exact and stable solution
> after going 3 times around the loop, i.e. re-compiling all
> of the Axiom library code three times, each time feeding the
> bootstrap that results from the final stage of each cycle,
> back into the start of the next cycle.

That's the kind of thing it would be nice to have a formal proof of
:-).  Oh, well.  As long as it works.  It sounds a little like running
LaTeX on a document multiple times to get to the final form.

> Is this clear? Can you see what the implications of this
> are and why I think it is both a *feature* (answer: because
> it allows the Axiom library code to be written in a manner
> that is simpler and more self-contained, module by module)
> and also something about which we have to be rather careful
> (answer: because this circularity implies the need for a
> solution strategy)?

I think so.  I'll need to peruse the bootstrapping info.

> If not, then I am certainly willing to try to answer questions,
> because I am convinced that understanding this is important
> to the overall design of Axiom.

I might have a few, but I'll try and do my homework first.  I would
suggest that both axiom specific bootstrapping information and any
relevant background material be incorporated into the books, as well as
(perhaps) instructions on how to proceed in the (very unlikely!) case
of having to compile Axiom without a working Axiom binary.

Cheers, and thanks for taking the time to answer an essentially
redundant question.

\start
Date: Wed, 9 Nov 2005 09:50:51 -0500
From: Bill Page
To: Mike Dewar
Subject: RE: letting my mud settle

On November 9, 2005 5:40 AM Mike Dewar wrote:
> 
> On Tue, Nov 08, 2005 at 12:09:23PM -0500, Bill Page wrote:
> ...
> > Building Axiom from sources only, which was apparently a
> > requirement imposed by restrictive licensing conditions which
> > apparently prevented any of the previously commercial binary
> > versions of Axiom to be distributed along with the Axiom source
> > code, was certainly a challenge because of the way that Axiom
> > had been designed to be "bootstrapped" from an existing running
> > copy. But this is no different than the situation with most
> > compilers and in particular GNU C (gcc).
>
> Just for the record this is not true.  Arthur Norman offered to
> provide an open-source version of CCL to the project which would
> have allowed you to build and distribute a Unix version of Axiom
> from the original NAG sources without any modifications.

Thank you for the correction, Mike. My quip about "restrictive
licensing conditions" was not intended in any way to be a criticism
of NAG's agreement to make Axiom open source. I think it was the
right thing to do and was done in an open and professional manner.

In fact I was aware through discussions with Arthur that building
Axiom based on CCL was possible. There is indeed an open source
version of CCL available through the web. At one point before we
had an operational version of Axiom on Windows, I was very seriously
considering this path to a Windows executable.

I think it is a pity that Tim did not follow-through with an initial
release of Axiom based on CCL. But that was up to him, I guess. His
priorities were obviously different - wanting to introduce some
kind of documentation/literate programming system first before making
Axiom widely available. I think the CCL code is still contained
in the Axiom source archive but is not in a runable state because
the complete original make scripts are not included and of course
none of it was converted to literate programming form.

> I provided copies of the Axiom product to several people on the
> list so you would have had no problem bootstrapping the first
> open-source versions from the NAG code.

Do you mean that this original "Axiom product" binary - as distinct
from the commercial binary version - could have been distributed
as part of the original open source distribution? If that is true,
it makes me sad that Tim went to all the trouble to embed bootstrap
lisp code into the build process.

> 
> Eliminating the need for a running Axiom was a good thing to 
> do, but if anything forced you to do it it was probably the
> decision to develop on GCL rather than CCL.
> 

Thanks. I really appreciate your input on this.

\start
Date: Wed, 9 Nov 2005 15:31:41 +0100
From: Nicolas Thiery
To: Martin Rubey
Subject: Re: MuPad under trouble
Cc: Bertfried Fauser

	Dear Bertfried, dear Martin, dear Axiom developers,

> Nicolas: I'm copying this to you, since I'd like you to correct me
> if I'm mistaken...

Thanks Martin for keeping me updated. I completely second your
comments. Yes, the MuPAD-Combinat code is LGPL, so please go ahead and
reuse as much of it as you can! The whole point of this library is to
share as much as possible combinatorics code among as many researchers
as possible.

In fact, when we got to choose a platform for our Combinat package
five years ago, we have been pondering for a while whether we should
go for MuPAD or Axiom. We ended up going for MuPAD mainly because
Axiom's future was highly uncertain at that time (and also because
MuPAD had a larger user base and we already had some code under hand).

So, if our code could be ported to Axiom, that would be great!

Now to the technical part:

 - I have no clear idea of how much work that would be. We strongly
   use the Domain/Category/Axiom mechanism of MuPAD. It indeed is
   quite similar to that of Axiom, as it has been inspired by it!
   However, there are a few peculiarities, which might get in the
   way. That especially if the goal it not only to make a one-time
   port, but to keep the development synchronized on the two
   platforms.

   We also use quite intensively functional aspects of the language
   (lexical scoping, closures, ...), but I assume that's similar in
   Axiom.

 - We will be very happy to provide technical support to anyone
   hopping in for doing the Axiom port; however, as long as MuPAD is
   reasonably alive we will concentrate on the MuPAD platform, and we
   won't be able to allocate serious development time ourselves to the
   Axiom port.

> To do the porting, it would be great if somebody knowledgeable of
> the bigger structures in MuPAD (i.e., what does a domain, a category
> look like) would write a bunch of regexps that would save us a bit
> of typing...

Ok. The efficient way to do that would be to have some MuPAD-Combinat
guy meet physically with some Axiom guy and have a one/two day coding
party on the subject. If we want to do more than a one-time port,
maybe the right approach would be to have a MuPAD parser in Axiom
(with possible legal issues to check).

> > The combinat people integrated a tremendous amount of code from
> > symmetrica, partly SCHUR and forged from these special purpose
> > (few used?)  programs a good tool.

Thanks :-) Do you mind if I post your comment on our "user
testimonials" wiki page?

\start
Date: Wed, 9 Nov 2005 12:56:44 -0500
From: Tim Daly
To: Bill Page
Subject: Re: letting my mud settle
Cc: Mike Dewar

> > 
> > On Tue, Nov 08, 2005 at 12:09:23PM -0500, Bill Page wrote:
> > ...
> > > Building Axiom from sources only, which was apparently a
> > > requirement imposed by restrictive licensing conditions which
> > > apparently prevented any of the previously commercial binary
> > > versions of Axiom to be distributed along with the Axiom source
> > > code, was certainly a challenge because of the way that Axiom
> > > had been designed to be "bootstrapped" from an existing running
> > > copy. But this is no different than the situation with most
> > > compilers and in particular GNU C (gcc).
> >
> > Just for the record this is not true.  Arthur Norman offered to
> > provide an open-source version of CCL to the project which would
> > have allowed you to build and distribute a Unix version of Axiom
> > from the original NAG sources without any modifications.
> 
> Thank you for the correction, Mike. My quip about "restrictive
> licensing conditions" was not intended in any way to be a criticism
> of NAG's agreement to make Axiom open source. I think it was the
> right thing to do and was done in an open and professional manner.
> 
> In fact I was aware through discussions with Arthur that building
> Axiom based on CCL was possible. There is indeed an open source
> version of CCL available through the web. At one point before we
> had an operational version of Axiom on Windows, I was very seriously
> considering this path to a Windows executable.

Arthur worked hard to pull together a version of CCL he could
freely distribute and I thank him for that.

> I think it is a pity that Tim did not follow-through with an initial
> release of Axiom based on CCL. But that was up to him, I guess. His
> priorities were obviously different - wanting to introduce some
> kind of documentation/literate programming system first before making
> Axiom widely available. I think the CCL code is still contained
> in the Axiom source archive but is not in a runable state because
> the complete original make scripts are not included and of course
> none of it was converted to literate programming form.

The first 3 months after I got the sources from NAG were spent trying
to get a Axiom on CCL. That effort failed. I built CCL but was unable
to understand how to build Axiom on top of it. It introduces "yet
another layer" of optimization that would have to be performed as
part of the build process. Since CCL is byte-interpreted the optimizations
are necessary for Axiom to perform well. I never figured out how to
automate the whole process which required a large amount of CCL
expertise.

In frustration I moved to AKCL (never released but i was one of the
"contributing authors" to Schelter's work so I understood the code)
and built Axiom. (AKCL became GCL)

All of the original CCL sources are in the source tree. They are
tar/gzipped in the latest distribution (in zips) but were fully
expanding in versions prior to about --patch-40. Look at 
lsp/ccl/src. 

In fact, you'll see that I WAS doing literate programming on the
CCL sources. See lsp/ccl/src/cslbase/*.pamphlet, for instance.
One early pushback from Norman was that this was the wrong thing
to do. He could not immediately port back patches to his sources.
The discussion is logged in the original mailing lists (some of
which predate getting Axiom on savannah). Rewriting CCL (and Axiom)
in literate form caused a huge debate. This was probably before 
your time. I can understand Arthur's position and it was reasonable
from his point of view. Unfortunately I had no documentation for 
the CCL sources and did not understand how they worked and how to
modify them so I started reading the sources and documenting them.

The Makefile.pamphlet files are in the lsp/ccl/src subtree which
contains all of the files provided with CCL.

> 
> > I provided copies of the Axiom product to several people on the
> > list so you would have had no problem bootstrapping the first
> > open-source versions from the NAG code.
> 
> Do you mean that this original "Axiom product" binary - as distinct
> from the commercial binary version - could have been distributed
> as part of the original open source distribution? If that is true,
> it makes me sad that Tim went to all the trouble to embed bootstrap
> lisp code into the build process.

Bill, we had this discussion. I asked Mike for permission to
distribute the commercial version to you and because of contract
issues the answer was no. There is no "Axiom product" binary distinct
from the commercial version that I'm aware of. In fact, we had a
discussion about getting a single commercial copy just for you.

Mike provided me a copy of the commercial version for development
purposes but I was unable to distribute it due to contract issues.
We have him to thank for early progress.

> 
> > 
> > Eliminating the need for a running Axiom was a good thing to 
> > do, but if anything forced you to do it it was probably the
> > decision to develop on GCL rather than CCL.
> > 
> 
> Thanks. I really appreciate your input on this.

And this is a red herring anyway. Open Source is more than just the
source code. It implies a way of working. Open Source people expect
to type:

   ./configure
   make
   make install

from the sources. But if we needed to distribute a binary product
as part of the 'make' step then we'd have to build binaries that
ran on every possible system so people could build axiom. But if
we're going to distribute a binary axiom in order to build the
system then why distribute the sources? Why rebuild?

And if we don't distribute the binaries then nobody can build it.

So the Axiom build needed to be restructured so it could be built
from scratch. The commercial version of Axiom was useful for A/B
testing but would never have become part of the open source platform.

It has nothing to do with CCL/GCL.

\start
Date: Wed, 9 Nov 2005 17:42:31 +0000
From: Mike Dewar
To: Bill Page
Subject: Re: letting my mud settle

On Wed, Nov 09, 2005 at 09:50:51AM -0500, Bill Page wrote:
> Do you mean that this original "Axiom product" binary - as distinct
> from the commercial binary version - could have been distributed as
> part of the original open source distribution? If that is true, it
> makes me sad that Tim went to all the trouble to embed bootstrap lisp
> code into the build process.

No, I mean that you could have bootstrapped the first open source binary
from the commercial system, and then distributed that first open
source-derived binary.

\start
Date: Wed, 9 Nov 2005 13:28:59 -0500
From: Bill Page
To: Tim Daly
Subject: RE: letting my mud settle
Cc: Mike Dewar

On November 9, 2005 12:57 PM Tim Daly wrote:
> 
> > > 
> > > On Tue, Nov 08, 2005 at 12:09:23PM -0500, Bill Page wrote:
> > > ...
> Mike Dewar wrote:
> > 
> > > I provided copies of the Axiom product to several people on the
> > > list so you would have had no problem bootstrapping the first
> > > open-source versions from the NAG code.
> > 
> > Do you mean that this original "Axiom product" binary - as distinct
> > from the commercial binary version - could have been distributed
> > as part of the original open source distribution? If that is true,
> > it makes me sad that Tim went to all the trouble to embed bootstrap
> > lisp code into the build process.
> 
> Bill, we had this discussion. I asked Mike for permission to
> distribute the commercial version to you and because of contract
> issues the answer was no. There is no "Axiom product" binary
> distinct from the commercial version that I'm aware of. In fact,
> we had a discussion about getting a single commercial copy just
> for you.

Actually I was never really interested in getting a copy of the
commercial version of Axiom as such. I already had a copy of the
demo version of Axiom for Windows that was distributed by NAG as
part of a promotional effort. My experience with Axiom prior to
the open source release was limited to playing with the demo version
on Windows. I was unhappy with the way development was going with
Maple, but I hesitated just a little too long before deciding to
actually purchase Axiom. When I went to the NAG website I found
Axiom was no longer available. :( The demo version is time limited
and so when open source Axiom arrived I found I could no longer
play with the Windows demo version.  Since the Windows version had
several unique features - like a completely re-done HyperDoc done
using an early version Techexplorer - I thought it would be very
useful to use this as a model for what we might eventually do with
the open source version of Axiom. What I asked Mike for was an
extended version of the key for the demo version on Windows, but
NAG was unable to provide that because of licensing conditions,
probably most directly related to techexplorer rather than Axiom,
and I respect their decision about that.

> 
> Mike provided me a copy of the commercial version for development
> purposes but I was unable to distribute it due to contract issues.
> We have him to thank for early progress.
>

So as I said originally: From your point of view you had no
alternative but to do the bootstrap from source because no
runnable binary for Axiom could be distributed with the open
source version of Axiom. Right?

> > 
> > > 
> > > Eliminating the need for a running Axiom was a good thing to 
> > > do, but if anything forced you to do it it was probably the
> > > decision to develop on GCL rather than CCL.
> > > 
> > 
> > Thanks. I really appreciate your input on this.
> 
> And this is a red herring anyway. Open Source is more than just
> the source code. It implies a way of working. Open Source people
> expect to type:
> 
>    ./configure
>    make
>    make install
> 
> from the sources.

That is exactly how the gcc is distributed and built. Of course
it assumes a running version of gcc in order to do that.

> But if we needed to distribute a binary product as part of the
> 'make' step then we'd have to build binaries that ran on every
> possible system so people could build axiom. But if we're going
> to distribute a binary axiom in order to build the system then
> why distribute the sources? Why rebuild?

I don't understand your logic. The reason to distribute the sources
is the same as the reason that GNU distributes the gcc sources -
to make the maintenance and improvement of gcc possible for as
many people as possible, who are interested and willing to do this
kind of work. We want the same thing for Axiom, right?

> 
> And if we don't distribute the binaries then nobody can build it.
>

I understand that the need to distribute binaries along with the
sources in order to re-build from the sources is a significant
requirement, but it does not seem much different than any other
fundamental operating system software. And from the point of view
of doing mathematics on a computer, Axiom is just another piece
of fundamental software of this kind.
 
> So the Axiom build needed to be restructured so it could be built
> from scratch. The commercial version of Axiom was useful for A/B
> testing but would never have become part of the open source
> platform.
> 
> It has nothing to do with CCL/GCL.
> 

Now I am confused. I thought Mike said rather explicitly above that
*if* we had chosen to distribute a ccl-based version of Axiom
then bootstrapping would not have been necessary (although still
perhaps a "good thing" to do anyway for other reasons). But anyway,
please ignore that I ever asked this question. All of this is just
history - not where we are now.

My point is that *now* that we do have freely licensed open source
binaries again, so we could return to the original maintenance model
for Axiom that was based on the having a running version of Axiom
available, as William Sit suggested in another email. I still think
that doing this might have some advantages in terms of making Axiom
development simpler, faster, and possible for people who do not want
to go to the effort of building Axiom from the bootstrap sources.

I guess what this amounts to would be providing an alternate
simplified source distribution of Axiom that started by assuming
that a running Axiom was already available (just like with gcc this
could be either a previously built version or a previously
downloaded binary version). Running 'make' with this distribution
would then use the locally modified Axiom sources to build a new
running version of Axiom including these changes. No Boot or Spad
bootstrapping would be necessary.

\start
Date: Wed, 9 Nov 2005 12:14:53 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: Bootstrapping

--- Bill Page wrote:

> More specific to this discussion is:
> 
> http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
> 
> The design of bootstrapping compilers has a long and
> venerable history and Axiom happens to be one of these
> types of systems.

Right, but the chicken-egg problem remains.  The article on
Bootstrapping compilers mentions several solutions for this, all but
one of which depend on other compilers being available.  The only
solution offered that didn't involve another compiler was the one I
expected, which was to hand translate the code into machine code the
first time around.  This produces a non-optimal but working compiler
without requiring a compiler, which is the interesting and important
step.  Iterating from there to improve the compiler is important and a
fascinating field of study but it can't get anywhere without that all
important first compile by hand.

I think Bill I'm actually focused on a somewhat different problem, and
one which I admit is probably not really a valid one in this day and
age and not really an issue for Axiom.  I would like the capability to
exist for someday, a thousand years from now, someone with only the
bare electronics and the source code to be able to re-create a running
system.   To the best of my knowledge this is doable only one of two
ways - implement a compiler in hardware which which translates a human
readable/writeable language into something the machine can understand
(which I think is what assembly code is actually all about), or define
the smallest possible viable compiler in machine language and implement
it by hand (I think the very first systems did this by flipping
switches - I don't know how matters proceeded from there) and proceed
to bootstrap using that.  Symbolics machines were actually very
interesting in this respect, since IIRC they actually DID implement
Lisp at a machine level, but they unfortunately didn't survive
commercially.

I think this resonates in some way with the open source community, or
at least a subset of it.  The ideal is that, starting from nothing but
freely available source code and bare hardware, you can create a fully
functional system.  Obviously this is not something one would want to
do often, but I think the potential ability to do it appeals.  This
might be one of the reasons people prefer to rely only on bootstrapping
from gcc as much as possible - in theory, once you get gcc running,
you're done with bootstrapping because most other software can be
compiled with that one tool.  There are a variety of compilers that
aren't like this of course - cmucl and sbcl among them, IIRC, but I
think there has been some consideration of developing the possibility
of using clisp, which CAN be bootstrapped with gcc, to build cmucl and
sbcl.

Basically, I think there is kind of a mantra that the fewer
bootstrapped software dependencies a system has, the better.  No one
denies gcc is such a dependency, but the introduction of other such
dependencies is not a popular idea, because of the reliance of such
systems on some available system being able to run the original binary.
 That's an unpopular assumption, just on principle.

> > It would be nice not to have to worry about such issues
> > for Axiom - why not keep the design goal of building Axiom
> > using only a working ANSI Lisp?
> 
> Because that means having to maintain two versions - a lisp
> version and a spad version of quite a few Axiom library
> modules. And if changes are made to any of the spad code in
> one of these modules, the lisp code must be re-generated.
> All of this is well described in Tim's documentation.

I'll try and read through that part Tim, but would the re-generation of
this lisp code be automatic in future systems?

> > I worry about a case in the future in which the Axiom code
> > might have to be built without any working binaries of Axiom -
> > what happens then? We've already seen the pain this situation
> > caused once.
> 
> Axiom is open source, like gcc and gcl. So you might as well be
> saying: what happens if we want to build Axiom and we have no C
> compiler or lisp system?

As I mentioned, I do actually consider this a valid question, although
perhaps one that should be addressed below the Axiom level.

\start
Date: Wed, 9 Nov 2005 21:12:21 +0100 (CET)
From: Bertfried Fauser
To: list
Subject: Re: MuPad under trouble

On Wed, 9 Nov 2005, Nicolas M. Thiery wrote:

[Hi Nicolas, I tried this directly to send to you but your return addres
fails, so I post it on this list, sorry to the others]

Hi Nicolas,

> > > The combinat people integrated a tremendous amount of code from
> > > symmetrica, partly SCHUR and forged from these special purpose
> > > (few used?)  programs a good tool.
>
> Thanks :-) Do you mind if I post your comment on our "user
> testimonials" wiki page?

Of course you can! I said it and I meant it. I know Florent Hivert,
Frederic Tomazet and others from the Marn le Valle group and recognize
their work well. However I have to admitt that I never was a user of
Mupad, but only a spektator.

I am activlely developing, together with Rafal Ablamowicz TN, a Clifford
algebra package for Maple. When I decided to search for a second option
for our package I went for AXIOM. However, I want not to do a port but a
rewrie of the Maple code, since it has drawbacks. Till now I haven't found
time to do it anyway, ... hm. Inbetween I became a user of SCHUR and would
like to see its abilities to be kept alife, after Brian Wybourne deceased.

Anyway, if I can help I would be at least an user of an AXIOM based
Combinat packahe and could imagine to spend alos some time to keep it
syncrounous with a Mupad version.

\start
Date: Wed, 9 Nov 2005 15:44:26 -0500
From: Bill Page
To: Cliff Yapp
Subject: bootstrapping (was: letting my mud settle)

On  November 9, 2005 9:17 AM C Y wrote:
> ...
> I'll hush up until I know enough to talk intelligently.
>

My old physics professor used to tell me that after graduation,
the more education you got, the more you realize the less you
actually know and the only point of "higher education" is to
learn how to ask better questions. And generally, I think your
questions are pretty good! ;) But of course there are diminishing
returns in any exchange.

> ...
> > > Chicken-egg situations are seldom desirable.
> > 
> 
> --- Bill Page wrote:
> 
> > Sigh. I feel like we have already been around this circle
> > several times... :) Well, I suppose it might be considered
> > a rather difficult concept, so it doesn't hurt to try to say
> > it all again another way ... see below. I hope you don't mind
> > that this email is a rather long as a result.
> 
> Sorry!  I don't mean to cause a rehash.  I'll go back and 
> look over the older discussions.
>

My comment was actually intended as a kind of pun. :o) But don't
apologize. If I sigh it is not because I think your question is
pointless; it is more likely because I think trying to answer
the question will be a little difficult. But those are the best
questions, not the worst.

> > ...
> > the analysis that I referred to below shows [one iteration
> > of the bootstrap] is not quite enough since some of the
> > dependencies do cycle back to affect code that has already
> > been compiled. However we believe (but have not proven!)
> > that this affects only some of the optimization that the Spad
> > compiler would have done and not that actual semantics of the
> > programs.
> 
> Hmm.  I take it at some point we should either demonstrate that
> or generate a binary using enough cycles so things iterate to
> steady state?
> 

I have already provided a script called 'fixed-point' that does
this. But it is not part of the default build because like I
said it takes three iterations to reach the fixed point (which
is a long time on most current desktop computers) and we are not
sure yet whether the changes from the first iteration to the last
are really significant. Probably it should become an optional
part of the build script.

For comparison purposed again, it might be interesting to note
that the gcc distribution has essentially the same kind of build
option that involves iteration and comparison of one iteration
of the gcc build to the next. In gcc it is assumed (maybe proven?)
that 3 iterations are always enough.

> > > > http://wiki.axiom-developer.org/17AlgebraBOOTSTRAPFixedPoint
> ...
> > > 
> > > Circular dependence is a feature?  I'm afraid I'm not
> > > following, if I understand you correctly - how can this be
> > > an advantage?
> > 
> > Yes it is an advantage - quite a major one. Of all of the
> > things that I have studied while learning about Axiom, this
> > is the one things about which I am still most excited. I
> > have to admit that I do not fully understand all of the
> > implications yet. But the idea is really very simple.
> 
> If you don't understand all the implications I'm most likely
> sunk, at least for a while :-).

Sometimes just trying to explain a problem helps one to
understand it better. So you see, you are already helping. :)

> 
> >
> > It turns out that unlike the case of the circularity in a
> > system of linear equations where using a guess and simply
> > repeating the calculation will not work very well, in most
> > (maybe all?) cases of circularity in the Axiom library, this
> > process does seem to lead to the exact and stable solution
> > after going 3 times around the loop, i.e. re-compiling all
> > of the Axiom library code three times, each time feeding the
> > bootstrap that results from the final stage of each cycle,
> > back into the start of the next cycle.
> 
> That's the kind of thing it would be nice to have a formal proof
> of :-).  Oh, well.  As long as it works.  It sounds a little
> like running LaTeX on a document multiple times to get to the
> final form.
>

I agree that a formal proof of convergence or at least some
idea about which situations lead to convergence and which do
not is very desirable. Yes, it is exactly like the case of
running LaTeX on a document multiple times to get the final
dvi file. In that case we can know from the structure of
the document what the maximum number of iterations will be
in any given situation.
 
> 
> Cheers, and thanks for taking the time to answer an
> essentially redundant question.
> 

I don't think the question is redundant (at least not yet :).
Thank you for asking.

\start
Date: Wed, 9 Nov 2005 16:07:36 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Bootstrapping

On November 9, 2005 3:15 PM C Y wrote:

> ... the chicken-egg problem remains.

Why do you keep on insisting that it is a problem? At most it
is a paradox to which we must consider a solution. To me it
seems like you are arguing that chickens should not come from
eggs but rather from some lower life form - maybe grow on
trees? ;) Sorry for my poor attempt at humour ...

> 
> I would like the capability to exist for someday, a thousand
> years from now, someone with only the bare electronics and the
> source code to be able to re-create a running system.

I think the simplest way to achieve this would be through what
is known as a byte-code interpreter: in the source code you
include the machine code for the compiler but not the machine
code for a real machine, but rather for a simpler abstract
machine for which you also provide the complete documentation.
Then the problem becomes first finding a way to simulate that
abstract machine on whatever hardware you have available. Having
done that, you load the provided abstract machine code and
compile your first iteration of the compiler.

The biological analogy seems to remain quite valid. The
abstraction machine code is the chicken's dna. :)

> Symbolics machines were actually very interesting in this
> respect, since IIRC they actually DID implement Lisp at a
> machine level, but they unfortunately didn't survive
> commercially.

Actually all of these machines used microcode to implement
a lisp interpreter. Someone had to write the microcode and
probably used a compiler.

> ...  There are a variety of [lisp] compilers that [are
> bootstrapped] - cmucl and sbcl among them, IIRC, but I think
> there has been some consideration of developing the possibility
> of using clisp, which CAN be bootstrapped with gcc, to build
> cmucl and sbcl.

As you say, writing a lisp compiler in lisp is a very common
strategy. I am sure the Axiom developers where aware of this.

> 
> Basically, I think there is kind of a mantra that the fewer
> bootstrapped software dependencies a system has, the better.

As far as I am concerned that is only because these people
do not understand the issue. Or perhaps it is because they
are concerned with issues - such as security and recovery
that are quite different than building the best language for
a particular job.

> No one denies gcc is such a dependency, but the introduction
> of other such dependencies is not a popular idea, because of
> the reliance of such systems on some available system being
> able to run the original binary. That's an unpopular assumption,
> just on principle.

Stupid principle.

\start
Date: Wed, 9 Nov 2005 14:00:44 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: Bootstrapping

--- Bill Page wrote:

> On November 9, 2005 3:15 PM C Y wrote:
> 
> > ... the chicken-egg problem remains.
> 
> Why do you keep on insisting that it is a problem? At most it
> is a paradox to which we must consider a solution. To me it
> seems like you are arguing that chickens should not come from
> eggs but rather from some lower life form - maybe grow on
> trees? ;) Sorry for my poor attempt at humour ...

I seldom get asked that question - somehow explaining that the chicken
was bootstrapped from an earlier evolutionary form, which was also
bootstrapped from an earlier form, etc. etc. back to when some protein
got bored and decided to have a party in the form of early DNA seems to
kill the joke :-P.  (Although, come to think of it, the egg probably
did come first, in that sense ;-)

It might not be a problem - I'm just used to thinking binary dependance
= bad.  It's a holdover from not having the correct Windows computer
you need to run a binary around and being Totally Out of Luck ;-). 
Just think where we would be if the original Axiom had only run on
AmigaOS, or one of the early pre-Unix OSs, and those were the only
binaries we had.  I don't think either Linux or BSD folk are totally
confident their systems will survive 100 years - "current" operating
systems may be totally different by then.
 
> > I would like the capability to exist for someday, a thousand
> > years from now, someone with only the bare electronics and the
> > source code to be able to re-create a running system.
> 
> I think the simplest way to achieve this would be through what
> is known as a byte-code interpreter: in the source code you
> include the machine code for the compiler but not the machine
> code for a real machine, but rather for a simpler abstract
> machine for which you also provide the complete documentation.
> Then the problem becomes first finding a way to simulate that
> abstract machine on whatever hardware you have available. Having
> done that, you load the provided abstract machine code and
> compile your first iteration of the compiler.

Cool.  I wonder if there is a project working on that somewhere.  The
ultimate hacker challenge - given only text files and bare hardware,
make Linux and all the software it runs work :-).

Sure would make a great time capsule entry.  (Sorry, this is kind of an
idea I like - how do we document our current technology in such a way
as to provide all necessary information from going from raw materials
only to where we are today.  Bootstrapping a computer fits in there
;-).

> The biological analogy seems to remain quite valid. The
> abstraction machine code is the chicken's dna. :)

Works for me :-).

> > Symbolics machines were actually very interesting in this
> > respect, since IIRC they actually DID implement Lisp at a
> > machine level, but they unfortunately didn't survive
> > commercially.
> 
> Actually all of these machines used microcode to implement
> a lisp interpreter. Someone had to write the microcode and
> probably used a compiler.

I suppose.  I wonder if bare metal could be made to implement circuits
for Lisp functions...  I suppose going down that route wouldn't make it
an ordinary computer at all.  Mapping Lisp directly to semiconductor
physics... OK, I should stop now.

> > ...  There are a variety of [lisp] compilers that [are
> > bootstrapped] - cmucl and sbcl among them, IIRC, but I think
> > there has been some consideration of developing the possibility
> > of using clisp, which CAN be bootstrapped with gcc, to build
> > cmucl and sbcl.
> 
> As you say, writing a lisp compiler in lisp is a very common
> strategy. I am sure the Axiom developers where aware of this.

Right.

> > Basically, I think there is kind of a mantra that the fewer
> > bootstrapped software dependencies a system has, the better.
> 
> As far as I am concerned that is only because these people
> do not understand the issue. Or perhaps it is because they
> are concerned with issues - such as security and recovery
> that are quite different than building the best language for
> a particular job.

Well, I'm not sure you can separate security and recovery from the job,
since if either fails the job goes with it.

Years ago Ken Thompson proposed a diabolical attack on a computer that
could be made by putting a trap door in a compiler, which would
automatically build it into all software and subsequent versions of
itself, undetectibly.  (I think this is the article: 
http://www.acm.org/classics/sep95/) That kind of thing makes people
(especially open source folk, I think) suspect all binaries, and for
good reason.

> > No one denies gcc is such a dependency, but the introduction
> > of other such dependencies is not a popular idea, because of
> > the reliance of such systems on some available system being
> > able to run the original binary. That's an unpopular assumption,
> > just on principle.
> 
> Stupid principle.

Not in light of things like Ken Thompson's proposed attack.  Security
people may be paranoid, but on the internet paranoia is a virtue.  I
have wondered about that in the past, with both Maxima and Axiom - what
kind of security holes might be present?  Of course a trustable OS
would remove the need to worry about anything more than the integrity
of our own calculations, but no such system exists. (Yet.)

Anyway, we're pretty far off topic (sorry, list!) but I think you have
hit on the key point that supports minimizing bootstrapping - it
reduces the number of unverifable programs you must trust.  Security is
probably the single biggest lack of today's computer infastructure, and
I'm keeping my fingers crossed that Coyotos comes through and changes
this.  Ideally there shouldn't be ANYTHING on the system you can't
trust, but of course it always comes down to something (even if it's
only the circuit tester used to check the output of physical circuits.)
 
\start
Date: 09 Nov 2005 21:41:55 -0500
From: Camm Maguire
To: Ralf Hemmecke
Subject: Re: MuPad under trouble
Cc: Nicolas Thiery, Bertfried Fauser

Greetings!  At least with AXIOM built atop GCL, interfacing with any C
code is pretty trivial.  See the gcl docs for clines, defentry, and
compiler::link.  There is also a thread in this group about
interfacing to fast blas via these GCL interfaces.


Ralf Hemmecke writes:

> Hello,
> 
> > By tha way: Is there a possibility for AXIOM to interact with external
> > C-functions via a sort of wrapper?
> 
> Given that AXIOM is in some way connected to Aldor the following link
> should provide an answer.
> 
> http://www.aldor.org/docs/HTML/chap19.html
> 
> I am however not really sure whether the connection works if the code
> is compiled to LISP (as it must for AXIOM). Is there someone who knows?

\start
Date: Wed, 9 Nov 2005 22:38:45 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: MuPad under trouble
Cc: Nicolas Thiery, Bertfried Fauser

re: interfacing

which reminds me. i ought to try to document the clines/defentry
portions of Axiom so we can capture the technique and other people
can expand it.

sigh. yet more work to do :-)

\start
Date: Wed, 9 Nov 2005 19:41:24 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Camm Maguire
Subject: Interfacing with the rest of the world
Cc: Nicolas Thiery, Bertfried Fauser

Just to throw this up on the radar screen:

We might want to keep our eyes on the Verrazano
(http://common-lisp.net/project/fetter/) and CFFI
(http://common-lisp.net/project/cffi/) projects as a potential way to
get portable interfaces to non-lisp libraries.  Both projects are early
stage but are already able to do some interesting things.

Of course the best way to proceed is to document the ideas and
implement them as part of Axiom, but until then it might be nice to be
able to interface with the outside world.  Sucking in things like the
cernlibs is not for the faint of heart ;-).

--- Tim Daly wrote:

> re: interfacing
> 
> which reminds me. i ought to try to document the clines/defentry
> portions of Axiom so we can capture the technique and other people
> can expand it.
> 
> sigh. yet more work to do :-)

\start
Date: Wed, 9 Nov 2005 21:21:53 -0800
From: Bob McElrath
To: Cliff Yapp
Subject: Re: Interfacing with the rest of the world
Cc: Camm Maguire, Nicolas Thiery, Bertfried Fauser

C Y [Cliff Yapp] wrote:
> Of course the best way to proceed is to document the ideas and
> implement them as part of Axiom, but until then it might be nice to be
> able to interface with the outside world.  Sucking in things like the
> cernlibs is not for the faint of heart ;-).

Uh...I know this is probably a joke, but...as a daily user of cernlib...
the functionality of cernlib has no intersection with axiom.

*I* can imagine wanting to interface the two.  But I wouldn't want to
inflict that can of worms on anyone else.

\start
Date: Thu, 10 Nov 2005 14:11:35 +0600 (NOVT)
From: Andrey G. Grozin
To: Cliff Yapp
Subject: re: Bootstrapping

On Wed, 9 Nov 2005, C Y wrote:
> Years ago Ken Thompson proposed a diabolical attack on a computer that
> could be made by putting a trap door in a compiler, which would
> automatically build it into all software and subsequent versions of
> itself, undetectibly.  (I think this is the article:
> http://www.acm.org/classics/sep95/) That kind of thing makes people
> (especially open source folk, I think) suspect all binaries, and for
> good reason.
Yes. I dislike having any binaries in my system I have not compiled 
myself. Therefore, I use Gentoo (installed from stage 1, so I recompiled 
gcc too). Of course, this does not help against the Thompson's attack.

> Not in light of things like Ken Thompson's proposed attack.  Security
> people may be paranoid, but on the internet paranoia is a virtue.
As one of my colleges said,

For a sysadmin, the absense of paranoia is called professional 
incompetence.

Sorry for off-topic.

\start
Date: Thu, 10 Nov 2005 09:45:12 -0500
From: Bill Page
To: Andrey G. Grozin
Subject: re: Bootstrapping

On November 10, 2005 3:12 AM Andrey G. Grozin
>
> On Wed, 9 Nov 2005, C Y wrote:
> > Years ago Ken Thompson proposed a diabolical attack on a
> > computer that could be made by putting a trap door in a
> > compiler, which would automatically build it into all software
> > and subsequent versions of itself, undetectibly.  (I think this
> > is the article: http://www.acm.org/classics/sep95/) That kind
> > of thing makes people (especially open source folk, I think)
> > suspect all binaries, and for good reason.

It must be the approaching Winter season or maybe it is this pain
in my back that wont go away anymore, but I seem to be disagreeing
with almost everyone here lately... :(

I believe that such an attack is technically possible, but I
disagree strongly that therefore there is a good reason to suspect
all binaries. Modern network computing (like life in general) is
a social phenomenon. In social interactions it is extremely
important that one establish relationships based on trust. It is
only by trusting others that is possible to build a co-operative
collaborative environment that is more than the sum of it's parts.
Given the aggressive and competitive nature of people, companies
and governments, no doubt this might seem a little na=EFve to some
people, but trust me, it is not ... :)

The implementation of trusted computing on the Internet is
already quite well advanced. Many binary programs are available
with electronic signatures that guarantee authenticity and
origin. Yes, any system (at least those in common use now) can
be broken, but we trust these people, e.g. the GNU free software
foundation, or for that matter even the Axiom developers, not to
behave in a malicious manner. No matter what we do technically,
in the end security always comes down to trusted relationships,
from computer to computer, computer to human, and human to human.

> Yes. I dislike having any binaries in my system I have not
> compiled myself. Therefore, I use Gentoo (installed from stage
> 1, so I recompiled gcc too). Of course, this does not help
> against the Thompson's attack.

By arguing in favour of bootstrapping, I am certainly *not* arguing
against the idea of compiling as much open source software from
source as possible - from the kernel up. I think that such an
approach does effectively deter Thompson's attack (but not prevent)
because at least in principle the possibility of comparing the
source to the generated binary does exist.

>
> > Not in light of things like Ken Thompson's proposed attack.
> > Security people may be paranoid, but on the internet paranoia
> > is a virtue.

No. Paranoia is a disease, like depression. It is a social/medical
condition that needs to be treated.

Security is another thing all together. It consists of using the
right technology, having a clear understanding of the way the
system works, and establishing trusted relationships. Security
is not a matter of hiding knowledge and hording control.

> As one of my colleges said,
>
> For a sysadmin, the absence of paranoia is called professional
> incompetence.
>

I think your colleague does not have a clear understanding of
security.

> Sorry for off-topic.
>

Andrey, I think that although this might be a side-issue, it
is not really off-topic since as open source developers we do
distribute both binaries and source code for Axiom. And I
think we should take some steps that we are not taking now to
help ensure that what we distribute is trusted by Axiom users.

\start
Date: Thu, 10 Nov 2005 07:01:13 -0800 (PST)
From: Cliff Yapp
To: Bob McElrath
Subject: Axiom + High Energy Physics
Cc: Camm Maguire, Nicolas Thiery, Bertfried Fauser

--- Bob McElrath wrote:

> C Y [Cliff Yapp] wrote:
> > Of course the best way to proceed is to document the ideas and
> > implement them as part of Axiom, but until then it might be nice to
> > be able to interface with the outside world.  Sucking in things 
> > like the cernlibs is not for the faint of heart ;-).
> 
> Uh...I know this is probably a joke, but...as a daily user of
> cernlib... the functionality of cernlib has no intersection with 
> axiom.

Really?  I thought they at least had some numerical routines that could
be of interest?
http://wwwasdoc.web.cern.ch/wwwasdoc/cernlib.html

I don't use it though, so I may be wrong.  I was just thinking CAS+High
Energy Physics tasks might be a good match, but I readily admit I don't
know cernlib all that well.

> *I* can imagine wanting to interface the two.  But I wouldn't want to
> inflict that can of worms on anyone else.

Heh - I guess it's from my own undergraduate physics background, but I
tend to focus on CAS usage as it relates to physics.  Cernlibs
naturally lept to mind when thinking about large, complex packages ;-).

Feyncalc would probably be my first target once the basic abilities for
physical science packages have been implemented (units, dimensions, and
error analysis) since that's a Mathematica package and already part of
a CAS environment (plus I know my own old department used it).  We
discussed the possibility on the list a while back - I think it would
be really neat to try implementing Feyncalc in Axiom, and I have a
feeling it would appeal to a lot of High Energy Physics departments who
want to run Feyncalc but have no $$ for Mathematica.  The problem is I
don't know if anyone would use it even if I did implement it - I'm not
part of the high energy physics community so it's dubious whether
people would trust it enough to want to use it - they might prefer to
stick to Mathematica.

Anyway, the attempt would be both educational and interesting, and
might provide enough momentum for some grad student to pick it up and
make it robust in the eyes of the physics community.  (Assuming the
availability of both funding and an advisor interested in that, of
course.) I'm sort of hoping Axiom might someday become the tool of
choice for theoretical physics - the mathematical backbone seems to be
there and physics departments are often looking to save the $$ required
for things like 20 copies of Mathematica for student labs.

Oh well, that's for the future if at all.  Back to dimensional
analysis...

\start
Date: Thu, 10 Nov 2005 07:42:52 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Andrey G. Grozin
Subject: re: Bootstrapping

--- Bill Page wrote:

> On November 10, 2005 3:12 AM Andrey G. Grozin
> > 
> > On Wed, 9 Nov 2005, C Y wrote:
> > > Years ago Ken Thompson proposed a diabolical attack on a 
> > > computer that could be made by putting a trap door in a
> > > compiler, which would automatically build it into all software
> > > and subsequent versions of itself, undetectibly.  (I think this
> > > is the article: http://www.acm.org/classics/sep95/) That kind
> > > of thing makes people (especially open source folk, I think)
> > > suspect all binaries, and for good reason.
> 
> It must be the approaching Winter season or maybe it is this pain
> in my back that wont go away anymore, but I seem to be disagreeing
> with almost everyone here lately... :(

Didn't somebody respond to that situation once with "How can I be
agreeable when everybody is wrong?" ;-)
 
> I believe that such an attack is technically possible, but I 
> disagree strongly that therefore there is a good reason to suspect
> all binaries. Modern network computing (like life in general) is
> a social phenomenon. In social interactions it is extremely
> important that one establish relationships based on trust.

The problem is you have to trust not only the person you are getting
the binary from, but that their computer is secure and the files
haven't be replaced, that the original computer it was compiled on was
uncompromised, that the binaries used on that computer to make the
binary you are downloading don't contain any earlier backdoors they can
pass on...

>From a point of fact, I don't think any true (e.g. human) bootstrapping
has occurred within recent history, so in a sense all software today
relies on some unknown binaries from the past.  This sounds like a good
project for the government, actually - establish open software and
hardware standards to create a system that, with the minimum necessary
work from a human being, can start the binary chain reaction going.  Of
course even if I somehow propose that to my congressman I'll probably
just get a weird look...

> It is only by trusting others that is possible to build a co-
> operative collaborative environment that is more than the sum of
> it's parts.

True, de facto.  But it would be nice if, at least in theory, it were
possible for some group or organization to bootstrap from the beginning
using open techniques, software, and hardware.  Then we at least know
who we are trusting, and at need that bootstrap could be reproduced
elsewhere and compared.

Actually, that sounds like something the FSF might be good for... 

> Given the aggressive and competitive nature of people, companies
> and governments, no doubt this might seem a little naive to some
> people, but trust me, it is not ... :)

I'm reminded of some incident a while back where Microsoft was quietly
sticking unique identifying numbers in every word document...  they got
caught and issued a patch to stop it:
http://www.microsoft.com/downloads/details.aspx?FamilyID=D7214DBB-2163-456A-B746-57621C8877F0&displaylang=en

If they did it once...

The problem with any binary is it involves a web of trust reaching all
the way back to the beginnings of the first binary that created it.  We
don't even know WHO we are trusting, so there is no way to evaluate
whether we should be trusting them.  I think some academic work has
been done on "web of trust" issues, but I'm not really familiar with
it.

If we were to establish a clear, documented trail of binary history
back to a few original bootstrapping events, with GPG signatures,
identical files produced between different entities every step along
the way, and full documentation of all tools and hardware used then I
agree that's probably workable.

> The implementation of trusted computing on the Internet is
> already quite well advanced. Many binary programs are available
> with electronic signatures that guarantee authenticity and
> origin.

But how far back?  Binaries were used to create the signed binaries,
after all.

> Yes, any system (at least those in common use now) can
> be broken, but we trust these people, e.g. the GNU free software
> foundation, or for that matter even the Axiom developers, not to
> behave in a malicious manner.

Right, but in software you're trusting every binary ever in the chain
of software production.  AFAIK that is NOT well documented, anywhere.

> No matter what we do technically,
> in the end security always comes down to trusted relationships,
> from computer to computer, computer to human, and human to human.

Right.  However, knowing nothing about anybody beyond the immediate
developers and distributors we are dealing with, we can't judge for
ourselves where our web of trust should end.  I agree the Axiom
developers are a good crowd, but that's only the tip of the iceberg.

> > Yes. I dislike having any binaries in my system I have not
> > compiled myself. Therefore, I use Gentoo (installed from stage
> > 1, so I recompiled gcc too). Of course, this does not help
> > against the Thompson's attack.
> 
> By arguing in favour of bootstrapping, I am certainly *not* arguing
> against the idea of compiling as much open source software from
> source as possible - from the kernel up. I think that such an
> approach does effectively deter Thompson's attack (but not prevent)
> because at least in principle the possibility of comparing the
> source to the generated binary does exist.

I agree it does deter it, but someone needs to certify that the binary
being used to bootstrap gcc doesn't have any backdoors in it.  I'll
agree it probably doesn't, as a point of fact, but we cant' KNOW that
unless the original source -> unoptimized binary event by human beings
is documented and recorded, and then the full compiler binary history
from that point to the current bootstrap binary.  That's the full web
of trust, and a full documentation of that is what is needed for
informed decisions.

> > > Not in light of things like Ken Thompson's proposed attack. 
> > > Security people may be paranoid, but on the internet paranoia
> > > is a virtue.
> 
> No. Paranoia is a disease, like depression. It is a social/medical
> condition that needs to be treated.

OK, technically true.

> Security is another thing all together. It consists of using the
> right technology, having a clear understanding of the way the
> system works, and establishing trusted relationships. Security
> is not a matter of hiding knowledge and hording control.

The problem is, how can you make an intelligent decision to trust when
you have no knowledge of the entity you are trusting?

> > As one of my colleges said,
> > 
> > For a sysadmin, the absence of paranoia is called professional 
> > incompetence.
> 
> I think your colleague does not have a clear understanding of
> security.

I think the above statement is essentially shorthand acknowledgement of
the following:

a)  when a computer is connected to the internet, anyone in the world
can launch an attack against it.
b)  given the number of people on the net, there will be bad actors. 
the statistical chances of this being the case approach unity quite
closely.
c)  there is a significant, non-zero chance that my machine will come
under attack
d)  any part of my system not personally verified by myself is an
unknown, and I cannot state with certainty that it contains no
vulnerabilities.
e)  any binary not created on site from source code cannot be
inspected, and therefore is only as trustworthy as the ENTIRE web of
trust behind its creation.
f)  since functionality must be provided, the best available measures
are to reduce the required bootstrapping binaries to a minimum,
reducing the number of potential problems.  Hence, the appeal in the
open source world of only relying on gcc for bootstrapping events - if
a problem is ever found, that makes only ONE piece of software that has
to be redone the "hard way".  Then everything else can be rebuilt
automatically.

So, if Axiom (at least SOME version of Axiom) can be built with just a
working GCL, GCL can be built by gcc.  So Axiom only relies on gcc for
bootstrapping, which is a common reliance in the open source world.

> > Sorry for off-topic.
>  
> Andrey, I think that although this might be a side-issue, it
> is not really off-topic since as open source developers we do
> distribute both binaries and source code for Axiom. And I
> think we should take some steps that we are not taking now to
> help ensure that what we distribute is trusted by Axiom users.

I agree here - signed binaries might be a very good idea.   I'll admit
I don't know too much about that myself (I admit I'm too trusting) but
its definitely the "right" way to do things.  I'll have to look into
what the modern ideas on that issue are.

\start
Date: Thu, 10 Nov 2005 09:57:23 -0600
From: Jay Belanger
To: Bill Page
Subject: re: Bootstrapping

Bill Page writes:
...
> It must be the approaching Winter season or maybe it is this pain
> in my back that wont go away anymore, but I seem to be disagreeing
> with almost everyone here lately... :(

I don't think that's right.
(Sorry.)

> I believe that such an attack is technically possible, but I 
> disagree strongly that therefore there is a good reason to suspect
> all binaries.

Tainted binaries are rare, but they do exist.  Trying to avoid them
seems like common sense.
(Tainted sources also exist, but they get spotted easier.)
There's an old saying (Finlay Peter Dunne)
  Trust everyone, but cut the cards. 
Not relying on binaries is, if nothing else, cutting the cards.

>> > Not in light of things like Ken Thompson's proposed attack. 
>> > Security people may be paranoid, but on the internet paranoia
>> > is a virtue.
>
> No. Paranoia is a disease, like depression. It is a social/medical
> condition that needs to be treated.
...
>> For a sysadmin, the absence of paranoia is called professional 
>> incompetence.
>
> I think your colleague does not have a clear understanding of
> security.

I think you're taking "paranoia" too literally.

But you might disagree.  (See above.)

\start
Date: Thu, 10 Nov 2005 12:10:03 -0500
From: Bill Page
To: Cliff Yapp
Subject: security and trust in Axiom (was: Bootstrapping)

On November 10, 2005 10:43 AM C Y wrote:
> ...
> The problem is you have to trust not only the person you are
> getting the binary from, but that their computer is secure and
> the files haven't be replaced, that the original computer it was
> compiled on was uncompromised, that the binaries used on that
> computer to make the binary you are downloading don't contain
> any earlier backdoors they can pass on...
>
> From a point of fact, I don't think any true (e.g. human)
> bootstrapping has occurred within recent history, so in a sense
> all software today relies on some unknown binaries from the past.
> This sounds like a good project for the government, actually -
> establish open software and hardware standards to create a
> system that, with the minimum necessary work from a human being,
> can start the binary chain reaction going.  Of course even if
> I somehow propose that to my congressman I'll probably just get
> a weird look...

Although some people might be a little paranoid about the
motivations of both government and military organizations,
I suppose it shouldn't hurt my argument here much if I promote
the work of an organization associated with the people for
whom I work.

The Canadian Defense Research Centre Valcartier has an ambitious
project called MaliCots, directly related to this subject:

http://www.drdc-rddc.gc.ca/researchtech/malicots/home_e.asp
http://www.dodccrp.org/events/2003/8th_ICCRTS/Pres/track_7/1_1400Charpentier
.pdf

The orientation is mostly towards the integration of Commercial
Off the Shelf (COTS) software, i.e. mostly closed source software,
within secure or trusted systems, but they also have a strong
interest in open source software for obvious reasons.

I don't consider these people paranoid at all but they do take
their job very seriously.

I expect that there are other organizations with similar
motivations in various countries around the world.

> ...
> > > As one of my colleges said,
> > >
> > > For a sysadmin, the absence of paranoia is called professional
> > > incompetence.
> >
> > I think your colleague does not have a clear understanding of
> > security.
>
> I think the above statement is essentially shorthand acknowledgement
> of the following:
>
> a)  when a computer is connected to the internet, anyone in the world
> can launch an attack against it.
> b)  given the number of people on the net, there will be bad actors.
> the statistical chances of this being the case approach unity quite
> closely.
> c)  there is a significant, non-zero chance that my machine will
> come under attack

The proper question here is not how to make the chance zero,
but rather how to acceptably manage the risk. Life is a risk.
We need to balance that against the need to interaction.

> d)  any part of my system not personally verified by myself is an
> unknown, and I cannot state with certainty that it contains no
> vulnerabilities.
> e)  any binary not created on site from source code cannot be
> inspected, and therefore is only as trustworthy as the ENTIRE web
> of trust behind its creation.

That is not really true, as my reference to the MaliCots project
above shows, although granted lack of certified original source
code does make it more difficult.

> f)  since functionality must be provided, the best available measures
> are to reduce the required bootstrapping binaries to a minimum,
> reducing the number of potential problems.  Hence, the appeal in the
> open source world of only relying on gcc for bootstrapping events -
> if a problem is ever found, that makes only ONE piece of software
> that has to be redone the "hard way".  Then everything else can be
> rebuilt automatically.

I think this strategy is wrong. Biological analogies demonstrate
that robustness is a function of the variety and diverseness in
a population. In other words, it is wrong to keep all of our
(chicken :) eggs in one basket. It is interesting to notice to what
extent the Internet and free software is also adopting this sort
of strategy. Online disk storage is cheap, bandwidth is rising.
Open source code is duplicated in many places all over the world.
Open source allows a great diversity and choice among alternative
software. This is something that we should encourage.

>
> So, if Axiom (at least SOME version of Axiom) can be built with just a
> working GCL, GCL can be built by gcc.  So Axiom only relies on gcc for
> bootstrapping, which is a common reliance in the open source world.

No. If anything we should be prepared to build open source programs
like Axiom many different ways and with some variations. That is,
I think, the best way to ensure that Axiom will survive over a
long period of time.

> ...
> > I think we should take some steps that we are not taking now to
> > help ensure that what we distribute is trusted by Axiom users.
>
> I agree here - signed binaries might be a very good idea.   I'll
> admit I don't know too much about that myself (I admit I'm too
> trusting) but its definitely the "right" way to do things.  I'll
> have to look into what the modern ideas on that issue are.
>

I think it would be great if someone here could take the lead
to make some recommendations about what we should do to make the
distribution of Axiom source code and binaries more trustworthy.
 I know there are some fairly extensive features within tla for
signatures. And Tom Lord (the main tla developer) seems to have
a strong interest in this subject.  We can also create signed
hash codes for the downloadable binaries. The trick it seems,
is how to introduce such procedures without making the whole
process too awkward for developers. We need some help with this.

\start
Date: Thu, 10 Nov 2005 09:11:19 -0800
From: Bob McElrath
To: Cliff Yapp
Subject: Re: Axiom + High Energy Physics
Cc: Camm Maguire, Nicolas Thiery, Bertfried Fauser

C Y [Cliff Yapp] wrote:
> --- Bob McElrath wrote:
> 
> > C Y [Cliff Yapp] wrote:
> > > Of course the best way to proceed is to document the ideas and
> > > implement them as part of Axiom, but until then it might be nice to
> > > be able to interface with the outside world.  Sucking in things 
> > > like the cernlibs is not for the faint of heart ;-).
> > 
> > Uh...I know this is probably a joke, but...as a daily user of
> > cernlib... the functionality of cernlib has no intersection with 
> > axiom.
> 
> Really?  I thought they at least had some numerical routines that could
> be of interest?
> http://wwwasdoc.web.cern.ch/wwwasdoc/cernlib.html

Cernlib certainly contains mathematical routines.

However it contains a very large number of things which are not
mathematical routines, and it is written in fortran.

A much more appropriate library for interfacing is the GNU Scientific
Library, BLAS, and LAPACK.  Taken together these cover almost all of the
cernlib routines.  Anything it does not cover should be added to them,
rather than imported from cernlib.  ;)

> I don't use it though, so I may be wrong.  I was just thinking CAS+High
> Energy Physics tasks might be a good match, but I readily admit I don't
> know cernlib all that well.

Besides, the data analysis package root (root.cern.ch) has superceded
cernlib.

> Feyncalc would probably be my first target once the basic abilities for
> physical science packages have been implemented (units, dimensions, and
> error analysis) since that's a Mathematica package and already part of
> a CAS environment (plus I know my own old department used it).  We
> discussed the possibility on the list a while back - I think it would
> be really neat to try implementing Feyncalc in Axiom, and I have a
> feeling it would appeal to a lot of High Energy Physics departments who
> want to run Feyncalc but have no $$ for Mathematica.  The problem is I
> don't know if anyone would use it even if I did implement it - I'm not
> part of the high energy physics community so it's dubious whether
> people would trust it enough to want to use it - they might prefer to
> stick to Mathematica.

They would.  People tend to (rightfully) distrust such packages, and the
learning curve is high, so people tend to continue using what they know.

But of course I think such an effort is still worthwhile.

> I'm sort of hoping Axiom might someday become the tool of
> choice for theoretical physics - 

Me too!  ;)

\start
Date: Thu, 10 Nov 2005 09:13:44 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Anyone familiar with Xy-pic?

Tim, you had mentioned earlier wanting to be able to click on the names
of elements in generated graphs of the source code and be taken to that
point in the text.  As far as I can tell graphviz is not usable for
this purpose, but I stumbled on something else which might be made to
serve:

http://www.tug.org/applications/Xy-pic/Xy-pic.html

I think this is a pdf of the user's manual:
http://www.esm.psu.edu/mac-tex/Tools/Xy-pic/xy-pic-users-guide.pdf

Perhaps using this and hyperref (assuming they can be mixed and matched
- this is untested) hyperlinked graphs could be generated for use in
documentation.  

There is a semi-relevant comparison of Xy-pic and graphviz here: 
http://osl.iu.edu/~tveldhui/misc/hasse.html

I'm seeing comments that Xy-pic is a bit hard to learn, but perhaps the
end results of teaching both ourselves and Axiom about it could be
worth it?

\start
Date: Thu, 10 Nov 2005 13:10:14 -0500
From: Tim Daly
To: Bill Page
Subject: Re: security and trust in Axiom (was: Bootstrapping)

> Although some people might be a little paranoid about the
> motivations of both government and military organizations,
> I suppose it shouldn't hurt my argument here much if I promote
> the work of an organization associated with the people for
> whom I work.

it is getting hard to tell which emails relate to axiom and which
emails relate to work. 

i work for CERT (the guys who issue the official virus warnings)
in a research capacity.

\start
Date: Thu, 10 Nov 2005 12:26:51 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: security and trust in Axiom (was: Bootstrapping)

On November 10, 2005 12:10 PM I wrote:
> 
> The Canadian Defense Research Centre Valcartier has an ambitious
> project called MaliCots, directly related to this subject:
> 
> http://www.drdc-rddc.gc.ca/researchtech/malicots/home_e.asp
> http://www.dodccrp.org/events/2003/8th_ICCRTS/Pres/track_7/1_1
> 400Charpentier.pdf
> 
> The orientation is mostly towards the integration of Commercial
> Off the Shelf (COTS) software, i.e. mostly closed source software,
> within secure or trusted systems, but they also have a strong
> interest in open source software for obvious reasons.
>

Oh ya one more thing. Here is the paper I wanted to reference about
this group's interest in Open Source;

http://www.dodccrp.org/events/2005/10th/CD/papers/227.pdf

\start
Date: Thu, 10 Nov 2005 09:27:46 -0800 (PST)
From: Cliff Yapp
To: Bob McElrath
Subject: Re: Axiom + High Energy Physics
Cc: Camm Maguire, Nicolas Thiery, Bertfried Fauser

--- Bob McElrath wrote:

> Cernlib certainly contains mathematical routines.
> 
> However it contains a very large number of things which are not
> mathematical routines, and it is written in fortran.

I thought it was being ported to C?  Did that not happen?
 
> A much more appropriate library for interfacing is the GNU Scientific
> Library, BLAS, and LAPACK.  Taken together these cover almost all of
> the cernlib routines.  Anything it does not cover should be added to
> them, rather than imported from cernlib.  ;)

Of course, ideally we'd document and implement all the algorithms in
Axiom as literate code ;-).  Although I understand BLAS and LAPACK in
particular do a lot of low level optimization work I for one would not
care to repeat...

> Besides, the data analysis package root (root.cern.ch) has superceded
> cernlib.

Ah, good to know.
 
> They would.  People tend to (rightfully) distrust such packages, and
> the learning curve is high, so people tend to continue using what 
> they know.

Since the idea would be to re-implement Feyncalc hopefully the learning
curve wouldn't be too terribly high, but I suppose the realistic view
would suggest differently.

Bob, being a member of a physics department and a user of cernlib and
friends, what would you recommend as a way to ensure and demonstrate
the reliability of such packages?  (I suppose me getting a Phd in High
Energy Physics would be the best first step, but that's probably not
really practical...)  The only way I can think of is to make some kind
of feyncalc_examples.pamphlet which reproduces every published result
of Feyncalc on Mathematica, which might be good for a paper but may or
may not convince people.  Would sure make for great bug testing though,
regardless (/me scribbles note to look for published Feyncalc results
on todo list...)

> But of course I think such an effort is still worthwhile.

Heh - perhaps the chance to avoid spending large fractions of the
department budget on CAS software will help convince folks to to debug
and test the new arrival.

> > I'm sort of hoping Axiom might someday become the tool of
> > choice for theoretical physics - 
> 
> Me too!  ;)

In your estimation, are the mathematical abilities of Axiom as it
currently exists enough to support Feyncalc, or are we lacking
something essential?  (Disregard if you don't use Feyncalc, of course
;-)

\start
Date: Thu, 10 Nov 2005 23:28:25 +0600 (NOVT)
From: Andrey G. Grozin
To: Bob McElrath
Subject: re: Axiom + High Energy Physics

On Thu, 10 Nov 2005, Bob McElrath wrote:
> A much more appropriate library for interfacing is the GNU Scientific
> Library, BLAS, and LAPACK.  Taken together these cover almost all of the
> cernlib routines.  Anything it does not cover should be added to them,
> rather than imported from cernlib.  ;)
Right. Taken together, these libraries can be a good substitute for the 
NAG library which could be used from the commercial Axiom. It would be 
great to be able to do efficient numeric calculations inside a larger 
Axiom program, using these 3 excellent libraries.

There is a tricky point, however. GNU Scientific Library (GSL) is licensed 
under GPL (not LGPL). Therefore, Axiom linked with GSL (either statically 
or dynamically) is automatically under GPL. A historical example: the 
author of CLISP was forced (by RMS) to change its license to GPL, because 
it uses readline. This was my argument when I advocated using GPL for 
Axiom in the beginning of the project.

\start
Date: Thu, 10 Nov 2005 23:38:05 +0600 (NOVT)
From: Andrey G. Grozin
To: Jay Belanger
Subject: re: Bootstrapping

On Thu, 10 Nov 2005, Jay Belanger wrote:
> Tainted binaries are rare, but they do exist.  Trying to avoid them
> seems like common sense.
> (Tainted sources also exist, but they get spotted easier.)
> There's an old saying (Finlay Peter Dunne)
>  Trust everyone, but cut the cards.
> Not relying on binaries is, if nothing else, cutting the cards.
A fresh example (see Linux Weekly News). Somebody have inserted a 
(licensed! original!) music CD from SONY into his Windows computer. 
Windows autoruns some binaries from CDs. In this case, the binary had 
inserted some spyware, and had modified some normal parts of Windows in 
such a way that this spyware was (almost) impossible to notice. In other 
words, a regular rootkit.

Moral: don't trust CDs with binaries from (seemingly) respectable large 
companies.

\start
Date: Thu, 10 Nov 2005 09:47:17 -0800 (PST)
From: Cliff Yapp
To: Andrey G. Grozin, Bob McElrath
Subject: re: Axiom + High Energy Physics

--- Andrey G. Grozin wrote:

> Right. Taken together, these libraries can be a good substitute for
> the  NAG library which could be used from the commercial Axiom. It 
> would be great to be able to do efficient numeric calculations 
> inside a larger Axiom program, using these 3 excellent libraries.

Hmm.  Actually, we might even be able to use the documentation for the
NAG libraries to do a feature for feature comparison, and working off
of these libraries add in whatever we need to achieve feature parity
(although probably not, at least right away, performance parity.)

> There is a tricky point, however. GNU Scientific Library (GSL) is
> licensed under GPL (not LGPL). Therefore, Axiom linked with GSL 
> (either statically or dynamically) is automatically under GPL. A 
> historical example: the author of CLISP was forced (by RMS) to 
> change its license to GPL, because it uses readline. This was my 
> argument when I advocated using GPL for Axiom in the beginning of
> the project.

I'll have to look at GSL more carefully.  Depending on how extensive it
really is, perhaps using the documentation
(http://www.gnu.org/software/gsl/manual/gsl-ref_toc.html) and papers
describing the original ideas as a guide for implementing the
functionality in Axiom itself is a viable way to go - we also get a
literate document by default, that way.  I know GSL is fairly extensive
in its coverage but I don't know how difficult the ideas are to
implement - once we have a design outlined and features we want
identified from GSL, NAG, and any other relevant libraries it might be
a fairly smooth process.  I'd really rather not get into the whole GPL
wrangle again, and from the 30 year horizon perspective it might be
better to focus on finding desirable features and implementing them in
Axiom, rather than risk another 100 emails on licensing issues.

\start
Date: Thu, 10 Nov 2005 14:00:44 -0500
From: Tim Daly
To: Cliff Yapp
Subject: re: Axiom + High Energy Physics

i have a subtree of the CATS effort laying around here someplace
where i started converting the BLAS routines to pamphlet files.

\start
Date: Thu, 10 Nov 2005 10:25:41 -0800
From: Bob McElrath
To: Cliff Yapp
Subject: Re: Axiom + High Energy Physics
Cc: Camm Maguire, Nicolas Thiery, Bertfried Fauser

C Y [Cliff Yapp] wrote:
> --- Bob McElrath wrote:
> 
> > Cernlib certainly contains mathematical routines.
> > 
> > However it contains a very large number of things which are not
> > mathematical routines, and it is written in fortran.
> 
> I thought it was being ported to C?  Did that not happen?

no...though the majority of it is in root.

> Of course, ideally we'd document and implement all the algorithms in
> Axiom as literate code ;-).  Although I understand BLAS and LAPACK in
> particular do a lot of low level optimization work I for one would not
> care to repeat...

Yes.  Those are in cernlib, but also exist elsewhere.  I agree they
should be incorporated for numerical linaear algebra.

> Bob, being a member of a physics department and a user of cernlib and
> friends, what would you recommend as a way to ensure and demonstrate
> the reliability of such packages?  (I suppose me getting a Phd in High
> Energy Physics would be the best first step, but that's probably not
> really practical...)  The only way I can think of is to make some kind
> of feyncalc_examples.pamphlet which reproduces every published result
> of Feyncalc on Mathematica, which might be good for a paper but may or
> may not convince people.  Would sure make for great bug testing though,
> regardless (/me scribbles note to look for published Feyncalc results
> on todo list...)

Making examples is a good idea.  Evangelizing within the community is
also a good idea.  Giving talks at conferences, etc.  A database of
known "test-case" results would be an excellent idea.

But perhaps the biggest of all is "ease of use".  All these tools are a
big pain and require a lot of specialized knowledge to even use.  The
holy grail of this field is to enter something like:
    p p -> t B j H
proton-proton (LHC) scattering into a top quark, bottom quark, jet and
higgs particle.  (or any other process) and then have it return a result
at next-to-leading order.  Believe it or not, we can't even do this.
There are a few tools that will do it at leading order that should be
compared to.

There are a lot of very smart people working on this, it's a highly
non-trivial problem.  The above example involves a few thousand
feynman diagrams.  At next-to-leading order it will involve perhaps a
few ten thousand.  Then one must consider renormalization, cuts, and
detector effects.  Which, frankly, is a whole lot of technical claptrap
that most users (even in physics) don't want to think about when they
sit down to figure this out, but is absolutely required to get a finite
answer.  I think such a program should choose a reasonable set of such
things, and include them in the output, with enough information in the
output to let the user know how to change them.  So, at tree level it
has been done.  (They are madgraph, comphep, grace, O'Mega/Whizard,
sherpa) See my Software page for more of this:
    http://mcelrath.org/Notes/Software

At one loop the general consensus is that this is possible, and there
are some people actively working on this (see: feyncalc and xloops).
There are technical problems which have not been solved, however, such
as automatic handling of soft, collinear, and overlapping singularities.
Handling of these things has even led to a new theory called SCET (Soft
Collinear Effective Theory) that only a few people understand right now.
The one-loop structure of this theory is only beginning to be explored.

So, one easily begins to encounter problems that no one knows how to
solve.  A significant amount of physics intuition must be applied to any
problem, and that is very difficult to automate.  The above example
contains a hexagon diagram at one loop.  As far as I know this has not
been solved for massive external particles.

I think this particular idea is probably only implementable within the
physics community, unfortunately.  But if anyone is going to take a stab
at it I would be happy to advise.

Many people actually see this as a crisis.  When the LHC turns on we
will quickly be in a situation where the theory error bars are much
larger than the experimental error bars, because next-to-leading order
results have in general not been calculated for many processes.  (and in
many cases, even that is not sufficent accuracy)

> > But of course I think such an effort is still worthwhile.
> 
> Heh - perhaps the chance to avoid spending large fractions of the
> department budget on CAS software will help convince folks to to debug
> and test the new arrival.

That will not be a hard sell, especially with the financial situation
under the current emperor.

But it will be a hard sell, because no one is likely to get a paper out
of it.

> In your estimation, are the mathematical abilities of Axiom as it
> currently exists enough to support Feyncalc, or are we lacking
> something essential?  (Disregard if you don't use Feyncalc, of course
> ;-)

I don't see anything fundamental that is missing.  However, almost all
of it would be "new" code.  For instance one must program in the
analytic solutions to loop integrals (a la the FF library).  One needs
Gamma matrices, tensors, metrics, etc.  Basic functions such as
polylogarithms and hypergeometric functions would make the whole thing
easier.  And, as the loops gets bigger, one really wants some kind of
monte carlo to evaluate them numerically.

I mean, you can look through the feyncalc documentation to see what is
there...

\start
Date: Thu, 10 Nov 2005 15:51:37 -0800 (PST)
From: Cliff Yapp
To: Bob McElrath
Subject: Re: Axiom + High Energy Physics
Cc: Camm Maguire, Nicolas Thiery, Bertfried Fauser

--- Bob McElrath wrote:

> C Y [Cliff Yapp] wrote:
> > --- Bob McElrath wrote:
> > 
> > > Cernlib certainly contains mathematical routines.
> > > 
> > > However it contains a very large number of things which are not
> > > mathematical routines, and it is written in fortran.
> > 
> > I thought it was being ported to C?  Did that not happen?
> 
> no...though the majority of it is in root.

Hmm.  OK.  So scratch cernlibs, and focus on root.
 
> > Of course, ideally we'd document and implement all the algorithms
> > in Axiom as literate code ;-).  Although I understand BLAS and 
> > LAPACK in particular do a lot of low level optimization work I for
> > one would not care to repeat...
> 
> Yes.  Those are in cernlib, but also exist elsewhere.  I agree they
> should be incorporated for numerical linaear algebra.

Tim, what's the plan for stuff like this?  Is the Lisp level up to
providing the performance for these algorithms that the (presumably)
optimized code already implemented can provide, or at least close
enough so that no one will worry about it?  Typically code for symbolic
algebra systems has been a different animal that that for numerically
optimized systems - is Axiom going to attempt to merge the two worlds?

> > Bob, being a member of a physics department and a user of cernlib
> > and friends, what would you recommend as a way to ensure and
> > demonstrate the reliability of such packages?  (I suppose me 
> > getting a Phd in High Energy Physics would be the best first step,
> > but that's probably not really practical...)  The only way I can 
> > think of is to make some kind of feyncalc_examples.pamphlet which
> > reproduces every published result of Feyncalc on Mathematica, 
> > which might be good for a paper but may or may not convince 
> > people.  Would sure make for great bug testing though,
> > regardless (/me scribbles note to look for published Feyncalc
> > results on todo list...)
> 
> Making examples is a good idea.  Evangelizing within the community is
> also a good idea.  Giving talks at conferences, etc.  A database of
> known "test-case" results would be an excellent idea.

Well, the first and the last might (with sufficient study) be something
I could attempt, anyway :-).  Other than that, I guess maybe the guys
at my undergrad university might give it a look, if I asked nicely...

> But perhaps the biggest of all is "ease of use".  All these tools are
> a big pain and require a lot of specialized knowledge to even use.  
> The holy grail of this field is to enter something like:
>     p p -> t B j H
> proton-proton (LHC) scattering into a top quark, bottom quark, jet
> and higgs particle.  (or any other process) and then have it return a
> result at next-to-leading order.  Believe it or not, we can't even 
> do this. There are a few tools that will do it at leading order that 
> should be compared to.

Ho boy, I've got a long ways to go.  Is leading order the decay
products from t B j H, and next to leading order the products from
those products?

> There are a lot of very smart people working on this, it's a highly
> non-trivial problem.  The above example involves a few thousand
> feynman diagrams.

Um. (setf *question-mode* 'clueless-dweeb)  How does one display a few
thousand diagrams usably?  Or are the feynman diagrams the means rather
than the end?

> At next-to-leading order it will involve perhaps a few ten
> thousand.  Then one must consider renormalization, cuts, and
> detector effects.  Which, frankly, is a whole lot of technical
> claptrap that most users (even in physics) don't want to think 
> about when they sit down to figure this out, but is absolutely
> required to get a finite answer.

How much of that can be either pre-entered as a function of the
experimental conditions or algorithmically decided?

> I think such a program should choose a reasonable set of
> such things, and include them in the output, with enough information
> in the output to let the user know how to change them.  

Makes sense.

> So, at tree level it has been done.  (They are madgraph, comphep, 
> grace, O'Mega/Whizard, sherpa) See my Software page for more of this:
>     http://mcelrath.org/Notes/Software

Cool!

> At one loop the general consensus is that this is possible, and there
> are some people actively working on this (see: feyncalc and xloops).
> There are technical problems which have not been solved, however,
> such as automatic handling of soft, collinear, and overlapping
> singularities. Handling of these things has even led to a new theory
> called SCET (Soft Collinear Effective Theory) that only a few people
> understand right now. The one-loop structure of this theory is only 
> beginning to be explored.
> 
> So, one easily begins to encounter problems that no one knows how to
> solve.  A significant amount of physics intuition must be applied to
> any problem, and that is very difficult to automate.  The above 
> example contains a hexagon diagram at one loop.  As far as I know 
> this has not been solved for massive external particles.

Fun!  So there's some opportunity for real research here, from the
sound of things.

> I think this particular idea is probably only implementable within
> the physics community, unfortunately.  But if anyone is going to 
> take a stab at it I would be happy to advise.

I'll see if I can work my way up there.

> Many people actually see this as a crisis.  When the LHC turns on we
> will quickly be in a situation where the theory error bars are much
> larger than the experimental error bars, because next-to-leading
> order results have in general not been calculated for many 
> processes.  (and in many cases, even that is not sufficent accuracy)

Wow.  That's kind of a fun time, actually.

> > > But of course I think such an effort is still worthwhile.
> > 
> > Heh - perhaps the chance to avoid spending large fractions of the
> > department budget on CAS software will help convince folks to to
> > debug and test the new arrival.
> 
> That will not be a hard sell, especially with the financial situation
> under the current emperor.
> 
> But it will be a hard sell, because no one is likely to get a paper
> out of it.

Maybe if they solve some of the difficult questions you mentioned
earlier and happend to do it in Axiom...

> > In your estimation, are the mathematical abilities of Axiom as it
> > currently exists enough to support Feyncalc, or are we lacking
> > something essential?  (Disregard if you don't use Feyncalc, of
> > course ;-)
> 
> I don't see anything fundamental that is missing.  However, almost
> all of it would be "new" code.  For instance one must program in the
> analytic solutions to loop integrals (a la the FF library).  One
> needs Gamma matrices, tensors, metrics, etc.  Basic functions such as
> polylogarithms and hypergeometric functions would make the whole
> thing easier.  And, as the loops gets bigger, one really wants some 
> kind of monte carlo to evaluate them numerically.

Sounds like a challenge!  Maybe Maxima's tensor package would have some
useful hints for that part of the operation - it has been heavily
worked on of late (I noticed you mentioned it in your software page -
last I heard it had been fixed and was working.)

> I mean, you can look through the feyncalc documentation to see what
> is there...

I think I'll need some more basic material first...

Cheers, and thanks!

\start
Date: Thu, 10 Nov 2005 20:16:05 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Axiom + High Energy Physics
Cc: Nicolas Thiery, Bertfried Fauser, Camm Maguire

> Tim, what's the plan for stuff like this?  Is the Lisp level up to
> providing the performance for these algorithms that the (presumably)
> optimized code already implemented can provide, or at least close
> enough so that no one will worry about it?  Typically code for symbolic
> algebra systems has been a different animal that that for numerically
> optimized systems - is Axiom going to attempt to merge the two worlds?

well, i don't plan to rewrite EVERYTHING in lisp, despite what i told
Bill, although in principle you can generate machine-instruction
equivalent routines from lisp. Before we gave the system to NAG
we worked with them to generate an Axiom-Fortran interface which
still exists in the code. I'd like to keep it compatible with the
NAG library but i don't have access to that anymore.

NAG, IBM, and several hundred other places still use the original (or
equivalent) fortran code although both NAG and IBMs are known to be
much better than the regular BLAS code. I started putting together
replacement routines (as pamphlets) for the numerics. I've attached an
example from the BLAS library (aka BLAS DROTG, NAG F06AAF, IBM ESSL
DROTG) for double-precision rotations in the Givens Plane. For
reference see

Lawson, C.L., Hanson, R.J., Kincaid, D.R., and Krogh, F.T. 
"Basic Linear Algebra Subprograms for Fortran Usage"
ACM Trans. on Math. Soft. (TOMS) Vol 5, pp308-325 (1979)

When I get around to it I'll write and inline the test case code so
the testing can be automated from the makefile.

Note that the default chunk is a makefile which is useful for standalone
testing purposes. you can extract with:

tangle -t8 drotg.pamphlet >Makefile.drotg
 
and then extract the code, latex it, and (eventually) run test cases with

make -f Makefile.drotg

The Makefile.pamphlet in the directory will be used to construct
the proper files to hook into Axiom.

I don't yet have this fully implemented for all of BLAS but it's coming.

I believe Camm is the BLAS maintainer but i'm not certain.

t

=========================================================================

\documentclass{article}
\begin{document}
\title{subroutine drotg(da,db,c,s)}
\author{Jack Dongarra}
\maketitle
\begin{abstract}
\end{abstract}
\eject
\tableofcontents
\eject
\section{Purpose}
This generates a real Givens plane rotation with parameters $c$ and $s$
such that given a real $a$ and $b$:
$$
\left(
\begin{array}{cc}
c & s\\
-s & c
\end{array}
\right)
\left(
\begin{array}{c}
da\\
db
\end{array}
\right)
=
\left(
\begin{array}{c}
f\\
0
\end{array}
\right)
$$
\noindent
The routine computes $c$, $s$, and $f$ as follows:
$$
f = \sigma{}\sqrt{da^2 + db^2}
$$
$$
c=\left\{
\begin{array}{ccc}
da/f & {\rm if\ }& f \ne 0\\
1   & {\rm if\ }& f = 0
\end{array}
\right.
s=\left\{
\begin{array}{ccc}
db/f & {\rm if\ }& f \ne 0\\
0   & {\rm if\ }& f = 0
\end{array}
\right.
$$
$$
{\rm where\ \ \ \ }
\sigma=\left\{
\begin{array}{ccc}
{\rm sign\ }da & {\rm if\ }& \vert{}da\vert{} > \vert{}db\vert{}\\
{\rm sign\ }db & {\rm if\ }& \vert{}da\vert{} \le \vert{}db\vert{}\\
\end{array}
\right.
$$
The routine also computes the value of $z$ defined as
$$
z=\left\{
\begin{array}{ccl}
s   & {\rm if\ }& \vert{}s\vert{} < c {\rm\ or\ }c = 0\\
1/c & {\rm if\ }& 0 < \vert{}c\vert{} \le s
\end{array}
\right.
$$
This enables $c$ and $s$ to be reconstructed from the single value $z$ as
$$
c=\left\{
\begin{array}{ccc}
\sqrt{1-z^2} & {\rm if\ }& \vert{}z\vert{} \le 1\\
1/z          & {\rm if\ }& \vert{}z\vert{} > 1
\end{array}
\right.
s=\left\{
\begin{array}{ccc}
z & {\rm if\ }&  \vert{}z\vert{} \le 1\\
\sqrt{1-c^2}   & {\rm if\ }&  \vert{}z\vert{} > 1
\end{array}
\right.
$$
To apply the plane rotation to a pair of real vectors call DROT.
\section{Specification}
\begin{verbatim}
subroutine drotg(double precision da,
                 double precision db,
                 double precision c,
                 double precision s)
\end{verbatim}
\section{Parameters}
\begin{list}{}
\item {\bf da} (Double Precision)
\begin{list}{}
\item {\sl Entry}: first element of the vector which determines the rotation
\item {\sl Exit}: the value {f}
\end{list}
\item {\bf db} (Double Precision)
\begin{list}{}
\item {\sl Entry}: second element of the vector which determines the rotation
\item {\sl Exit}: the value {z}
\end{list}
\item {\bf c} (Double Precision)
\begin{list}{}
\item {\sl Entry}: no value
\item {\sl Exit}: cosine of the rotation
\end{list}
\item {\bf s} (Double Precision)
\begin{list}{}
\item {\sl Entry}: no value
\item {\sl Exit}: sine of the rotation
\end{list}
\end{list}
\section{Error Indicators and Warnings}
None.
\section{Examples}
\subsection{Example 1: $f = 0$}
\begin{verbatim}
      call drotg( 0.0, 0,0, c, s)
==>
      da = 0.0
      db = 0.0
      c  = 1.0
      s  = 0.0
\end{verbatim}
\subsection{Example 2: $c = 0$}
\begin{verbatim}
      call drotg( 0.0, 2.0, c, s)
==>
      da = 2.0
      db = 1.0
      c  = 0.0
      s  = 1.0
\end{verbatim}
\subsection{Example 3: $\vert{}b\vert{} > \vert{}a\vert{}$}
\begin{verbatim}
      call drotg( 6.0, -8.0, c, s)
==>
      da = -10.0
      db =  -1.666...
      c  =  -0.5
      s  =   0.8
\end{verbatim}
\subsection{Example 4: $\vert{}a\vert{} > \vert{}b\vert{}$}
\begin{verbatim}
      call drotg( 8.0, 6.0, c, s)
==>
      da = 10.0
      db =  0.6
      c  =  0.8
      s  =  0.6
\end{verbatim}
<<fortran>>=
      subroutine drotg(da,db,c,s)
c
c     construct givens plane rotation.
c     jack dongarra, linpack, 3/11/78.
c
      double precision da,db,c,s,roe,scale,r,z
c
      roe = db
      if( dabs(da) .gt. dabs(db) ) roe = da
      scale = dabs(da) + dabs(db)
      if( scale .ne. 0.0d0 ) go to 10
         c = 1.0d0
         s = 0.0d0
         r = 0.0d0
         z = 0.0d0
         go to 20
   10 r = scale*dsqrt((da/scale)**2 + (db/scale)**2)
      r = dsign(1.0d0,roe)*r
      c = da/r
      s = db/r
      z = 1.0d0
      if( dabs(da) .gt. dabs(db) ) z = s
      if( dabs(db) .ge. dabs(da) .and. c .ne. 0.0d0 ) z = 1.0d0/c
   20 da = r
      db = z
      return
      end
@
\section{Makefile}
<<*>>=
TANGLE=/usr/local/bin/NOTANGLE
WEAVE=/usr/local/bin/NOWEAVE
LATEX=/usr/bin/latex

all: code doc run

code: drotg.pamphlet
	${TANGLE} -Rfortran drotg.pamphlet >drotg.f

doc:
	${WEAVE} -t8 -delay drotg.pamphlet >drotg.tex
	${LATEX} drotg.tex 2>/dev/null 1>/dev/null
	${LATEX} drotg.tex 2>/dev/null 1>/dev/null

run:
	@echo done
remake:
	${TANGLE} -t8 drotg.pamphlet >Makefile.drotg

@
\eject
\begin{thebibliography}{99}
\bibitem{1} Lawson, C.L., Hanson, R.J., Kincaid, D.R., and Krogh, F.T. 
``Basic Linear Algebra Subprograms for Fortran Usage''
ACM Trans. on Math. Soft. (TOMS) Vol 5, pp308--325 (1979)
\bibitem{2} Numerical Algorthms Fortran Library routine F06AAF\\
{\sl http://www.nag.co.uk/numeric/fl/manual/pdf/F06/f06aaf.pdf}
\bibitem{3} IBM ESSL Documentation routine DROTG\\
{\sl http://csit1cwe.fsu.edu/extra\_link/essl/essl250.html\#HDRHSROTG}
\end{thebibliography}
\end{document}

\start
Date: Thu, 10 Nov 2005 20:19:09 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Axiom + High Energy Physics
Cc: Nicolas Thiery, Bertfried Fauser, Camm Maguire

(this is a resend) .... i just clipped and tested what i sent out
and i managed to accidently delete the \usepackage line without
which the pamphlet stuff is broken. sorry about the flying fingers. 
this one is correct..... --t


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


> Tim, what's the plan for stuff like this?  Is the Lisp level up to
> providing the performance for these algorithms that the (presumably)
> optimized code already implemented can provide, or at least close
> enough so that no one will worry about it?  Typically code for symbolic
> algebra systems has been a different animal that that for numerically
> optimized systems - is Axiom going to attempt to merge the two worlds?

well, i don't plan to rewrite EVERYTHING in lisp, despite what i told
Bill, although in principle you can generate machine-instruction
equivalent routines from lisp. Before we gave the system to NAG
we worked with them to generate an Axiom-Fortran interface which
still exists in the code. I'd like to keep it compatible with the
NAG library but i don't have access to that anymore.

NAG, IBM, and several hundred other places still use the original (or
equivalent) fortran code although both NAG and IBMs are known to be
much better than the regular BLAS code. I started putting together
replacement routines (as pamphlets) for the numerics. I've attached an
example from the BLAS library (aka BLAS DROTG, NAG F06AAF, IBM ESSL
DROTG) for double-precision rotations in the Givens Plane. For
reference see

Lawson, C.L., Hanson, R.J., Kincaid, D.R., and Krogh, F.T. 
"Basic Linear Algebra Subprograms for Fortran Usage"
ACM Trans. on Math. Soft. (TOMS) Vol 5, pp308-325 (1979)

When I get around to it I'll write and inline the test case code so
the testing can be automated from the makefile.

Note that the default chunk is a makefile which is useful for standalone
testing purposes. you can extract with:

tangle -t8 drotg.pamphlet >Makefile.drotg
 
and then extract the code, latex it, and (eventually) run test cases with

make -f Makefile.drotg

The Makefile.pamphlet in the directory will be used to construct
the proper files to hook into Axiom.

I don't yet have this fully implemented for all of BLAS but it's coming.

I believe Camm is the BLAS maintainer but i'm not certain.

t

=========================================================================

\documentclass{article}
\usepackage{axiom}
\begin{document}
\title{subroutine drotg(da,db,c,s)}
\author{Jack Dongarra}
\maketitle
\begin{abstract}
\end{abstract}
\eject
\tableofcontents
\eject
\section{Purpose}
This generates a real Givens plane rotation with parameters $c$ and $s$
such that given a real $a$ and $b$:
$$
\left(
\begin{array}{cc}
c & s\\
-s & c
\end{array}
\right)
\left(
\begin{array}{c}
da\\
db
\end{array}
\right)
=
\left(
\begin{array}{c}
f\\
0
\end{array}
\right)
$$
\noindent
The routine computes $c$, $s$, and $f$ as follows:
$$
f = \sigma{}\sqrt{da^2 + db^2}
$$
$$
c=\left\{
\begin{array}{ccc}
da/f & {\rm if\ }& f \ne 0\\
1   & {\rm if\ }& f = 0
\end{array}
\right.
s=\left\{
\begin{array}{ccc}
db/f & {\rm if\ }& f \ne 0\\
0   & {\rm if\ }& f = 0
\end{array}
\right.
$$
$$
{\rm where\ \ \ \ }
\sigma=\left\{
\begin{array}{ccc}
{\rm sign\ }da & {\rm if\ }& \vert{}da\vert{} > \vert{}db\vert{}\\
{\rm sign\ }db & {\rm if\ }& \vert{}da\vert{} \le \vert{}db\vert{}\\
\end{array}
\right.
$$
The routine also computes the value of $z$ defined as
$$
z=\left\{
\begin{array}{ccl}
s   & {\rm if\ }& \vert{}s\vert{} < c {\rm\ or\ }c = 0\\
1/c & {\rm if\ }& 0 < \vert{}c\vert{} \le s
\end{array}
\right.
$$
This enables $c$ and $s$ to be reconstructed from the single value $z$ as
$$
c=\left\{
\begin{array}{ccc}
\sqrt{1-z^2} & {\rm if\ }& \vert{}z\vert{} \le 1\\
1/z          & {\rm if\ }& \vert{}z\vert{} > 1
\end{array}
\right.
s=\left\{
\begin{array}{ccc}
z & {\rm if\ }&  \vert{}z\vert{} \le 1\\
\sqrt{1-c^2}   & {\rm if\ }&  \vert{}z\vert{} > 1
\end{array}
\right.
$$
To apply the plane rotation to a pair of real vectors call DROT.
\section{Specification}
\begin{verbatim}
subroutine drotg(double precision da,
                 double precision db,
                 double precision c,
                 double precision s)
\end{verbatim}
\section{Parameters}
\begin{list}{}
\item {\bf da} (Double Precision)
\begin{list}{}
\item {\sl Entry}: first element of the vector which determines the rotation
\item {\sl Exit}: the value {f}
\end{list}
\item {\bf db} (Double Precision)
\begin{list}{}
\item {\sl Entry}: second element of the vector which determines the rotation
\item {\sl Exit}: the value {z}
\end{list}
\item {\bf c} (Double Precision)
\begin{list}{}
\item {\sl Entry}: no value
\item {\sl Exit}: cosine of the rotation
\end{list}
\item {\bf s} (Double Precision)
\begin{list}{}
\item {\sl Entry}: no value
\item {\sl Exit}: sine of the rotation
\end{list}
\end{list}
\section{Error Indicators and Warnings}
None.
\section{Examples}
\subsection{Example 1: $f = 0$}
\begin{verbatim}
      call drotg( 0.0, 0,0, c, s)
==>
      da = 0.0
      db = 0.0
      c  = 1.0
      s  = 0.0
\end{verbatim}
\subsection{Example 2: $c = 0$}
\begin{verbatim}
      call drotg( 0.0, 2.0, c, s)
==>
      da = 2.0
      db = 1.0
      c  = 0.0
      s  = 1.0
\end{verbatim}
\subsection{Example 3: $\vert{}b\vert{} > \vert{}a\vert{}$}
\begin{verbatim}
      call drotg( 6.0, -8.0, c, s)
==>
      da = -10.0
      db =  -1.666...
      c  =  -0.5
      s  =   0.8
\end{verbatim}
\subsection{Example 4: $\vert{}a\vert{} > \vert{}b\vert{}$}
\begin{verbatim}
      call drotg( 8.0, 6.0, c, s)
==>
      da = 10.0
      db =  0.6
      c  =  0.8
      s  =  0.6
\end{verbatim}
<<fortran>>=
      subroutine drotg(da,db,c,s)
c
c     construct givens plane rotation.
c     jack dongarra, linpack, 3/11/78.
c
      double precision da,db,c,s,roe,scale,r,z
c
      roe = db
      if( dabs(da) .gt. dabs(db) ) roe = da
      scale = dabs(da) + dabs(db)
      if( scale .ne. 0.0d0 ) go to 10
         c = 1.0d0
         s = 0.0d0
         r = 0.0d0
         z = 0.0d0
         go to 20
   10 r = scale*dsqrt((da/scale)**2 + (db/scale)**2)
      r = dsign(1.0d0,roe)*r
      c = da/r
      s = db/r
      z = 1.0d0
      if( dabs(da) .gt. dabs(db) ) z = s
      if( dabs(db) .ge. dabs(da) .and. c .ne. 0.0d0 ) z = 1.0d0/c
   20 da = r
      db = z
      return
      end
@
\section{Makefile}
<<*>>=
TANGLE=/usr/local/bin/NOTANGLE
WEAVE=/usr/local/bin/NOWEAVE
LATEX=/usr/bin/latex

all: code doc run

code: drotg.pamphlet
	${TANGLE} -Rfortran drotg.pamphlet >drotg.f

doc:
	${WEAVE} -t8 -delay drotg.pamphlet >drotg.tex
	${LATEX} drotg.tex 2>/dev/null 1>/dev/null
	${LATEX} drotg.tex 2>/dev/null 1>/dev/null

run:
	@echo done
remake:
	${TANGLE} -t8 drotg.pamphlet >Makefile.drotg

@
\eject
\begin{thebibliography}{99}
\bibitem{1} Lawson, C.L., Hanson, R.J., Kincaid, D.R., and Krogh, F.T. 
``Basic Linear Algebra Subprograms for Fortran Usage''
ACM Trans. on Math. Soft. (TOMS) Vol 5, pp308--325 (1979)
\bibitem{2} Numerical Algorthms Fortran Library routine F06AAF\\
{\sl http://www.nag.co.uk/numeric/fl/manual/pdf/F06/f06aaf.pdf}
\bibitem{3} IBM ESSL Documentation routine DROTG\\
{\sl http://csit1cwe.fsu.edu/extra\_link/essl/essl250.html\#HDRHSROTG}
\end{thebibliography}
\end{document}

\start
Date: Thu, 10 Nov 2005 16:48:12 -0800
From: Bob McElrath
To: Cliff Yapp
Subject: Re: Axiom + High Energy Physics
Cc: Camm Maguire, Nicolas Thiery, Bertfried Fauser

C Y [Cliff Yapp] wrote:
> --- Bob McElrath wrote:
> 
> > C Y [Cliff Yapp] wrote:
> > > --- Bob McElrath wrote:
> > > 
> > > > Cernlib certainly contains mathematical routines.
> > > > 
> > > > However it contains a very large number of things which are not
> > > > mathematical routines, and it is written in fortran.
> > > 
> > > I thought it was being ported to C?  Did that not happen?
> > 
> > no...though the majority of it is in root.
> 
> Hmm.  OK.  So scratch cernlibs, and focus on root.

Root is also not something you want to absorb into axiom.

Root is about almost an operating system.  It contains (among other
things): a database, an object browser, a dynamic object system for C++,
a C++ interpreter, opengl graphics toolkit, drawing and canvas routines,
etc.

It has been placed under the LGPL though as of the most recent version.
(there are debian packages!!!)  If it contains useful routines, we
should extract them and incorporate them into axiom, rather than
interfacing with root...

> Ho boy, I've got a long ways to go.  Is leading order the decay
> products from t B j H, and next to leading order the products from
> those products?

Leading order means roughly "the biggest piece".  In this context I mean
a diagram containing no closed loops (I am not worried about the decay
products of t,b,j,h -- those can be handled straightforwardly).  NLO
(next-to-leading order) is diagrams with one loop.

And, for the record, I just finished calculating that cross section, and
it's tiny.  A bad example.  ;)

> > There are a lot of very smart people working on this, it's a highly
> > non-trivial problem.  The above example involves a few thousand
> > feynman diagrams.
> 
> Um. (setf *question-mode* 'clueless-dweeb)  How does one display a few
> thousand diagrams usably?  Or are the feynman diagrams the means rather
> than the end?

The feynman diagrams are a useful representation that helps get an
intuitive feel.  Of course there is a 1:1 conversion from diagrams to
formulas.  But, there are other ways to solve the path integral.

The programs I listed (madgraph, comphep, grace) generate the diagrams
algorithmically (usually in a postscript file).  Feyncalc will generate
loop diagrams algorithmically and display them using kludgy mma
graphics.  Generating the diagrams is non-trivial but not hard.  It's
evaluating them that's a bitch.  ;)

> How much of that can be either pre-entered as a function of the
> experimental conditions or algorithmically decided?

Little.  Some approaches (like Sherpa) attempt to encode lots of
experimental information so the user doesn't have to deal with it.
Experimental collaborations generally have their own "monte carlo"
system, which really means a big pile of ugliness designed to compute
the things they most intend to measure.  If the user asks for a specific
process that has not been calculated at NLO, it usually falls back to
one of the tree-level generators (madgraph, comphep, grace).  But this
has known problems.  Cross sections are usually wrong by as much as a
factor of two, but worse, angular relations among particles can be
significantly wrong.

This, I think, is the really hard part: Identifying what can be
pre-decided and handled without the user's intervention.  Most packages
right now just return garbage results, and the user doesn't know there
was a problem.  For instance, infrared singularities cancel between
leading order and next to leading order, but can instead be handled by
placing realistic detector resolution cuts.  All programs I know will
happily integrate the singularity and return NAN or garbage.  In
principle this can be recognized and handled.

> Fun!  So there's some opportunity for real research here, from the
> sound of things.

Oh definitely.  There's opportunity for many Ph.D. theses.

> > Many people actually see this as a crisis.  When the LHC turns on we
> > will quickly be in a situation where the theory error bars are much
> > larger than the experimental error bars, because next-to-leading
> > order results have in general not been calculated for many 
> > processes.  (and in many cases, even that is not sufficent accuracy)
> 
> Wow.  That's kind of a fun time, actually.

I'm not so sure "fun" is the right word.  But I look forward to the day
that the physics departments around the country kick themselves for
hiring so many useless string theorists.  (Europeans have generally been
more pragmatic on this point)

> Maybe if they solve some of the difficult questions you mentioned
> earlier and happend to do it in Axiom...

That would be nice.  That's a matter of building the low level tools
(dirac matrices, polylogarithms), and advertising.

> Sounds like a challenge!  Maybe Maxima's tensor package would have some
> useful hints for that part of the operation - it has been heavily
> worked on of late (I noticed you mentioned it in your software page -
> last I heard it had been fixed and was working.)

Cool, I'll have to take a look again.

\start
Date: Thu, 10 Nov 2005 18:51:06 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDevelopment] 

Structure of Axiom Source Files

  All of the Axiom source is written in a [Literate Programming] style
and contained in [Pamphlet Files]. These files contain the system
documentation (written in LaTeX) also contains the entire source code
itself. The design and theory of operation of the program makes direct
reference to the source code and both are updated together in a single
source document.

\start
Date: Thu, 10 Nov 2005 19:11:11 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Pamphlet Files] (new) 

**Based on an email from Tim Daly on June 27, 2005 1:24 AM:**

It is important to the long term goals of the project that we document
the new work we are doing. The original developers, including myself,
did not do a good job documenting the system which makes it very
difficult to maintain and modify. Going forward we don't want to
continue making the same mistake.

A simple, stripped down pamphlet file that uses lisp is shown in
[Pamphlet Example]. What you see is a thumbnail image of the first
page of the final result. Click 'pdf' or 'dvi' to see the full
document and click 'edit' to see the actual source code.

This document contains the explanation of the lisp code, it contains
the source code for the lisp, and it contains a Makefile to build itself.

You need to extract the Makefile before you can use it. This is done with
the 'notangle' command from noweb. Once you've extracted the Makefile all
you ever need to type is 'make' and everything is automatically rebuilt.
That way you can write a new paragraph, add new code and type 'make'.

As this was literally ripped out of my local working environment it's
not likely that it will run the first time but it should be close.

To use this file you need to 

0 store this file somewhere (e.g. /tmp/autodoc.lisp.pamphlet)

1 get noweb-2.10a.tgz::

        cd /tmp
        mkdir noweb
        cd noweb
        wget http://daly.axiom-developer.org/noweb-2.10a.tgz

2 untar noweb::

        tar -zxf noweb-2.10a.tgz

3 make noweb::

        ./awkname gawk
        make all install

  this will install a few commands, two of which you need.
  One is called 'notangle' and the other is 'noweave'.
  Be sure they show up on your path.

4 extract the makefile using 'notangle'. (notangle is a command 
  to extract code from a pamphlet. noweave is a command to 
  extract latex from a pamphlet)::

        cd /tmp
	notangle autodoc.lisp.pamphlet >Makefile                

5 get axiom.sty::

        wget http://daly.axiom-developer.org/axiom.sty

6 modify the Makefile to point at your lisp command and
  your notangle and noweave commands.

7 build the document and run the lisp code

        make

If you do::

        xdvi autodoc.dvi &
        emacs autodoc.lisp.pamphlet
           (and start an emacs subshell)
        then you can modify the file 
             type make
             and switch the focus to the xdvi window which will
             automatically refresh with the new changes.

It's a very fast way to develop a pamphlet file.

\start
Date: Thu, 10 Nov 2005 19:12:29 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Pamphlet Example] (new) 

\documentclass{article}
\usepackage{axiom}
\begin{document}
\title{Autodoc}
\author{Tim Daly}
\maketitle
\begin{abstract}
We want to generate the reference information from axiom source
files automatically.
\end{abstract}
\eject
\tableofcontents
\eject
By design the chunk name has 3 fields. 
The first field is one of \{category, domain, package\}.
The second field is the abbreviation.
The third field is the full name.
This routine will return two lists, the first is the list of
abbreviations and the second is the list of full names.

We keep looping until we run out of input, at which point we
throw out of the loop and catch it here.
<<until done>>=
  (catch 'done
@
We open the source file
<<open source file>>=
   (with-open-file (in sourcefile)
@
We read each line, trimming off trailing spaces
<<for each line do>>=
    (loop
     (setq expr (read-line in nil 'done))
     (when (eq expr 'done) (throw 'done nil))
     (setq expr (string-trim '(#\space) expr))
@
We look for lines that begin with a chunk name that
starts with package, domain, or category and end with an
equal sign (which indicates a chunk definition).
<<when package domain or category definition>>=
     (when 
      (and (> (length expr) 4)
           (or
            (string= "@<<pa" (subseq expr 0 4))
            (string= "@<<do" (subseq expr 0 4))
            (string= "@<<ca" (subseq expr 0 4)))
           (char= (elt expr (1- (length expr))) #\=))
@
We remove the 3 characters, two $>$ and an $=$ which make up the chunk name.
<<remove the trailing chunk characters>>=
      (setq expr (subseq expr 0 (- (length expr) 3)))
@
We get the third field from the string which is the long name.
<<capture the long name>>=
      (setq point (position #\space expr :from-end t :test #'char=))
@
We get the second field from the string which is the abbreviation.
<<capture the abbreviation>>=
      (setq mark
       (position #\space 
        (string-right-trim '(#\space)
         (subseq expr 0 (1- point))) :from-end t))
      (push (string-trim '(#\space) (subseq expr mark point)) names)))))
@
<<srcabbrevs>>=
(defun srcabbrevs (sourcefile)
 (let (in expr start end names longnames)
<<until done>>
<<open source file>>
<<for each line do>>
<<when package domain or category definition>>
<<remove the trailing chunk characters>>
<<capture the long name>>
      (format t "~a ~a ~a~%" expr point longnames)
<<capture the abbreviation>>
  (values names longnames))))

@
\section{Doit}
<<doit>>=
(srcabbrevs "/new/patch38/src/algebra/acplot.spad.pamphlet")

@
\section{Autodoc}
<<autodoc>>=
<<srcabbrevs>>
<<doit>>
@
\section{Makefile}
<<*>>=
TANGLE=/usr/local/bin/notangle -t8 
WEAVE=/usr/local/bin/noweave -delay
LISP=/new/patch38/obj/linux/bin/lisp

all: code doc run

code: autodoc.lisp.pamphlet
	@${TANGLE} -Rautodoc autodoc.lisp.pamphlet >autodoc.lisp

doc: autodoc.lisp.pamphlet
	@${WEAVE} autodoc.lisp.pamphlet >autodoc.tex
	@latex autodoc.tex
	@latex autodoc.tex

run: autodoc.lisp
	@cat autodoc.lisp | ${LISP}

remake:
	@${TANGLE} autodoc.lisp.pamphlet >Makefile

@
\eject
\begin{thebibliography}{99}
\bibitem{1} nothing
\end{thebibliography}
\end{document}

\start
Date: Thu, 10 Nov 2005 21:11:19 -0500
From: Bill Page
To: Tim Daly
Subject: re: Axiom + High Energy Physics

On November 10, 2005 8:16 PM Tim Daly wrote:
> 
> well, i don't plan to rewrite EVERYTHING in lisp, despite what I
> told Bill,

:o)

> although in principle you can generate machine-instruction
> equivalent routines from lisp. Before we gave the system to NAG
> we worked with them to generate an Axiom-Fortran interface which
> still exists in the code. I'd like to keep it compatible with the
> NAG library but i don't have access to that anymore.
> 

>From a quick look at the NAG routines that are not compiled in the
current open source release it looked to me like these assumed
that these numeric calculations were performed by a separate server
program that communicates with Axiom through sockets. Am I right
about this, Tim?


If that is the case, then what one would need to do in order to
retain the NAG Axiom coding in it's current form would be to write
a new numeric server program which would call open source math
library routines to perform equivalent functions. Of course such
a program could be written in any convenient language, e.g. C or
even Fortran (post 2000 version please!).

In principle such a design seems to make sense because it allows
some parallelism and also provides the numeric routines with their
own address space. This also allows the conversion to and from
Axiom data structures to native (Fortran?) data structures to be
centralized and done as efficiently as possible.

Of course it is also possible to interface with external programs
from Axiom in more high level ways such as Martin Rubey's interface
to Polymake which is written entirely in Spad and communicates
simply through files.

http://wiki.axiom-developer.org/Polymake

For example one might create such an interface for Octave or even
Cactus http://www.cactuscode.org/aboutCactus if you are into that
kind of thing. The main problem has to do with converting to and
from Axiom's internal data structures and the simplest place to do
that is in Spad (or Aldor).

\start
Date: Fri, 11 Nov 2005 00:26:11 -0500
From: Tim Daly
To: Luanne Burns Goldrich
Subject: reqeust

So far i've been able to set up a live CD that can be booted
and does not touch the hard drive (the KNOPPIX idea). 
(see sourceforge.net/projects/doyencd)

I have set it up so it starts up a webserver at boot time. 

I have set it up with a browser that contains a page with a text box.

The CD contains Axiom and the literate tools.

It starts a web page with an "expression box" Typing an expression in
the box and pressing enter will cause the expression to be evaluated
with the results returned to the page as pretty latex output. This is
essentially where mathaction is today.

Now I need to be able to do two things:

 1) make the web page look and act like an embedded shell

 2) drag and drop a file onto a web page and have it automatically
    "uploaded" (of course, it's all running on the same machine but
    don't assume that).

Can AJAX help with these two problems?



Essentially I want the following scene to work:

  1) I go to a conference with a bootable Doyen CD which contains the
     proceedings, axiom, the browser, literate tools, etc.

  2) everyone at the conference gets a copy of the CD

  3) a speaker gives a talk at the conference and, as part of the
     talk, indicates a URL where a literate copy of the paper lives

  4) the conference attendees boot the proceedings CD and visit the URL

  5) the conference attendees "drag and drop" the paper to their machine

  6) drag and drop causes the following actions:

     a) the paper gets the latex extracted (weave)
     b) latex is run on the paper
     c) the dvi or pdf output shows up in a browser tab

     d) the paper gets the code extracted (tangle)
     e) the code is compiled and loaded
     f) a tab opens which has a command prompt
     h) the user can interact with the code


Consider a simple paper that compares two sort strategies (bubble
and quick). The presentation shows a table of results:

          

          1 10 100 1000 10000 (# of random entries in list)

bubble
              (table of comparitive execution times)

quick

While the talk is ongoing the conference attendee can fetch the paper
(which contains the code) and see the actual computed results on their
local machine by running the code.




This is the "Doyen" concept, in essence. It will allow us to promote
literate programming at all of the computational science conferences.
Real code can be distributed and run and even updated in real time.

It will eventually be the case that presenting computational science
results without presenting the code will be like presenting a theorem
without presenting a proof. I'll believe the results in the table when
my system arrives at the same results.

Somehow it seems just a small step away from where we are but my 
web/browser/javascript/xml skills are lacking.

\start
Date: Fri, 11 Nov 2005 00:51:52 -0500
From: Tim Daly
To: Luanne Burns Goldrich
Subject: reqeust

since we can set up the architecture of such a system any way we want
(it's all on the same CD) we could consider a much tighter coupling
between axiom and the local browser.


currently pages are in html/xml format and are interpreted by the
browser. suppose we change the model and open up the local browser.

we could create a plugin (or flash???) that runs in a tab and
creates 
  (a) a blank window 
  (b) in input socket 
  (c) output socket
  (d) an API

the API could be simple text i/o over the sockets with terminal-like
display

the API could be a drawing ability that allows X/Y pixel addressing

the browser could have many different "specialized" tabs that present
different APIs. This would be a tight coupling to Axiom for certain
tabs and general purpose html in the rest of the tabs.

if we could do this then the various parts of axiom, namely the 
console, the axiom help-browser, and the graphics could all be
running at the same time in separate tabs.

and since the browser can open new windows rather than tabs all
of these could be separate windows.

do you know how to create a window/canvas/blank-thing in a tab?
can we (using javascript? using a modified browser) draw text or
lines in that blank area?

this would go directly to Bill Page's hope of having a browser
be the universal front-end of Axiom.

\start
Date: Thu, 10 Nov 2005 21:02:02 -0800
From: Bob McElrath
To: Tim Daly
Subject: Re: reqeust
Cc: Luanne Burns Goldrich

root [Tim Daly] wrote:
> Now I need to be able to do two things:
> 
>  1) make the web page look and act like an embedded shell
> 
>  2) drag and drop a file onto a web page and have it automatically
>     "uploaded" (of course, it's all running on the same machine but
>     don't assume that).
> 
> Can AJAX help with these two problems?

Maybe.  AJAX quite simply can send and receive XML, so it can send the
file (but so could a POST request).  Browsers, however, do not have a
consistent implementation for any kind of drag & drop.  e.g. what is
the input and where did it come from?  If it's not from the browser, the
browser doesn't necessarily know anything about it, how to read it, etc.

If the whole thing is in the browser itself, it's not really a problem.
You can easily implement a file browser in a browser.  A click on a file
can then do anything it wants with the file.  Doesn't matter if the file
is on the local system or from a website.

>      a) the paper gets the latex extracted (weave)
>      b) latex is run on the paper
>      c) the dvi or pdf output shows up in a browser tab
> 
>      d) the paper gets the code extracted (tangle)
>      e) the code is compiled and loaded
>      f) a tab opens which has a command prompt
>      h) the user can interact with the code

Neat idea.

\start
Date: Fri, 11 Nov 2005 00:08:51 -0500
From: Bill Page
To: Tim Daly
Subject: RE: reqeust
Cc: Luanne Burns Goldrich

Tim,

On November 11, 2005 12:26 AM you wrote:
> ... 
> Now I need to be able to do two things:
> 
>  1) make the web page look and act like an embedded shell
> 

Why not use the AxiomUI work that Kai Kaminski developed? It
implements such a Axiom command input/output shell and uses
AJAX techniques.

>  2) drag and drop a file onto a web page and have it
>     automatically "uploaded" (of course, it's all running
>     on the same machine but don't assume that).
> 
> Can AJAX help with these two problems?
> ...

I don't know of any type of interaction with a browser that
implements "drag and drop" actions - maybe it is possible
with the Mozilla extensions - but you can certainly write
a web page that uploads a file. That is a standard function
of HTML forms.
 
\start
Date: Fri, 11 Nov 2005 01:11:12 -0500
From: Bill Page
To: Tim Daly
Subject: RE: reqeust
Cc: Luanne Burns Goldrich

Tim,

On November 11, 2005 12:52 AM you wrote:
> 
> since we can set up the architecture of such a system any way we want
> (it's all on the same CD) we could consider a much tighter coupling
> between axiom and the local browser.
> 
> currently pages are in html/xml format and are interpreted by the
> browser. suppose we change the model and open up the local browser.
> 
> we could create a plugin (or flash???) that runs in a tab and
> creates 
>   (a) a blank window 
>   (b) in input socket 
>   (c) output socket
>   (d) an API
> 
> the API could be simple text i/o over the sockets with terminal-
> like display
> 
> the API could be a drawing ability that allows X/Y pixel addressing
> 
> the browser could have many different "specialized" tabs that
> present different APIs. This would be a tight coupling to Axiom
> for certain tabs and general purpose html in the rest of the tabs.
> 
> if we could do this then the various parts of axiom, namely the 
> console, the axiom help-browser, and the graphics could all be
> running at the same time in separate tabs.
> 
> and since the browser can open new windows rather than tabs all
> of these could be separate windows.
> 
> do you know how to create a window/canvas/blank-thing in a tab?
> can we (using javascript? using a modified browser) draw text or
> lines in that blank area?
> 
> this would go directly to Bill Page's hope of having a browser
> be the universal front-end of Axiom.
> 

I am confused by your request. Glossing over whatever you might
mean by API, this is exactly what AxiomUI is intended to become.
All of what you say is possible using Javascript, SVG and
possibly MathML. Do you mean that this was not clear from our
discussions that began last June?

\start
Date: Fri, 11 Nov 2005 10:32:27 -0500
From: Tim Daly
To: Bill Page
Subject: Re: reqeust
Cc: Luanne Burns Goldrich

> I am confused by your request. Glossing over whatever you might
> mean by API, this is exactly what AxiomUI is intended to become.
> All of what you say is possible using Javascript, SVG and
> possibly MathML. Do you mean that this was not clear from our
> discussions that began last June?

possibly. i've been keeping the doyen problem in a separate space
in my head so i guess i'm not making all of the connections. i'll
review kai's work more closely.

\start
Date: Fri, 11 Nov 2005 13:13:12 -0500
From: Bill Page
To: Tim Daly
Subject: RE: reqeust
Cc: Luanne Burns Goldrich

On November 11, 2005 10:32 AM Tim Daly wrote:
> 
> Bill Page wrote: 
> > I am confused by your request. Glossing over whatever you might
> > mean by API, this is exactly what AxiomUI is intended to become.
> > All of what you say is possible using Javascript, SVG and
> > possibly MathML. Do you mean that this was not clear from our
> > discussions that began last June?
> 
> possibly. i've been keeping the doyen problem in a separate space
> in my head so i guess i'm not making all of the connections. i'll
> review kai's work more closely.
> 

I know very well about having separate spaces in my head. :)

Tim, please don't let the apparent "bad temper" of my recent emails
prevent you from asking about this work. (The same applies of course
to everyone else on this list.) I think Kai's work on AxiomUI is
very important to the future of Axiom, unfortunately since the close
of the Google Summer of Code project, Kai has apparently not had much
chance to continue work on this new user interface. We have quite a
lot of information and ideas captured in terms of our exchange of
emails - both on and off the axiom-developer list and I would like
to spend some time distilling it and organizing it on the wiki. If
you have questions about Kai's work, what was actually accomplished
and about the discussion and plans that lead up to it, then that
would help motivate me to do this. And also it might help to
encourage Kai to continue work, when he has time, of course.

\start
Date: Fri, 11 Nov 2005 14:31:03 -0500
From: Tim Daly
To: Bill Page
Subject: Re: reqeust
Cc: Luanne Burns Goldrich

> Tim, please don't let the apparent "bad temper" of my recent emails
> prevent you from asking about this work. (The same applies of course
> to everyone else on this list.)                                 

mood? hadn't noticed. i greatly respect your opinion and it carries a
lot of weight. it won't necessarily change my mind but that's partly
my irish showing up and partly because i disagree with you.

your input is always valued and you have managed to change my opinion
in the past.


>                                 I think Kai's work on AxiomUI is
> very important to the future of Axiom, unfortunately since the close
> of the Google Summer of Code project, Kai has apparently not had much
> chance to continue work on this new user interface. We have quite a
> lot of information and ideas captured in terms of our exchange of
> emails - both on and off the axiom-developer list and I would like
> to spend some time distilling it and organizing it on the wiki. If
> you have questions about Kai's work, what was actually accomplished
> and about the discussion and plans that lead up to it, then that
> would help motivate me to do this. And also it might help to
> encourage Kai to continue work, when he has time, of course.

unfortunately Kai's work occurred while i was "mentally offline"
switching jobs and living arrangements. it hasn't gotten the 
attention from me it deserves and i really do need to look at it.

i want to get a "best case" example of doyen running soon. the 
ISSAC conference CD work goes white hot (gotta get done immediately)
in the late april/early may timeframe. this year i'm trying to get
ahead of the curve so i can prototype a conference CD based on 
doyen before the actual proceedings work occurs.

i'd hoped to do this last year but the strain of trying to bring
two students "up to speed" followed by switching jobs just put the
project way behind schedule. i did manage to set up the doyencd
project on sourceforge.

i spoke to RedHat about doyen and actually have permission from 
their legal dept to state that they endorse the project. if we
can put on a convincing demo of a computational science platform
we may be able to convince them to show up at physics, chem, bio,
math, and other science conferences and give away the doyen CDs.
that, combined with some wizzy demos, could convince a few scientists
of the worth of the effort.

a "standard" computational science platform that contained a wide
range of computational science software would give scientists a
target for distributing their algorithms. and literate programming
has the chance to capture the expertise and keep it with the code.

it really could have a big impact. but it needs work to make it happen.

if you collate Kai's stuff it would make it easier for everyone to view
including me. you were much more involved with it than i was. i've
asked Luanne Burns (copied above) to get up to speed on AJAX so we
can push ahead on this. Perhaps she and Kai can make the magic happen.

\start
Date: Fri, 11 Nov 2005 20:49:48 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Re: Anyone familiar with Xy-pic? (resend)

(previous attempt had pdf attached - this one should work.)

--- Cliff Yapp wrote:

> Tim, you had mentioned earlier wanting to be able to click on the
> names of elements in generated graphs of the source code and be 
> taken to that point in the text. 

Or, more precisely:

"i'd like to get diagrams autogenerated in the book. and i'd like
to be able to click on graph nodes entries and go right to the code
(hyperlinking in graphs)."

The autogeneration is going to be quite a trick, and the hyperlinking
in graphs isn't any cakewalk either, but I think I've demonstrated the
possibility of the hyperlinking part.  Basically I made the crudest
test imaginable - I cut and pasted an example from the XY-pic docs and
added it to a subset of the dhmatrix tex file - basically just enough
to let me try \usepackage{axiom}, \usepackage[all]{xy}, and
\usepackage[<fancystuff>]{hyperref} together.  Then I replaced the text
in one of the XY-pic objects with hyperref hyperlinking commands, and
added a target around a section header, and darned if it didn't work,
at at least with pdflatex!

Just for fun (and in case my machine wipes out) I'll attach the tex
document, but it's nothing to write home about.  (Does the list allow
attachments?) XY-pic is not for the faint of heart (it reminds me of
looking at some of the more mangled perl scripts I've seen, actually)
but it also looks very, very powerful, so I'll take a shot at it.  (I
don't even faintly understand the example in the attachment yet, which
is why its not a better example of what we would want.) The main
question looks to be automatic layout, and that could be a problem.  I
haven't been able to figure out what XY-pics abilities are in that
department, but I'm assuming it's not really designed for that.

Cheers,
CY

(Note:  interesting stuff is pretty much in the first part here - only
other point of interest is the code required to make Vectors section a
legal hyperlink target.  This is a first cut and maybe not even the
best way to set up the link but I was excited enough at seeing it work
that I wanted to let other people know it's possible.)

\documentclass{article}
\usepackage{axiom}
\usepackage[all]{xy}
\ifx\pdfoutput\undefined
  \usepackage[backref=false, colorlinks=false,
breaklinks=true]{hyperref}
 \else
  \usepackage[pdftex=true, plainpages=false, colorlinks=true,
linkcolor=blue, breaklinks=true, pdfpagelabels, 
              bookmarksopen=false, pdfnewwindow=true,
              pdfstartview=FitH, pdfpagemode=UseOutlines]{hyperref}
\fi

\begin{document}
\xy *[o]=<40pt>\hbox{\hyperlink{Vectors}{Vectors}}="o"*\frm{oo},
    +<5em,-5em>@+,
    (46,11)*+\hbox{Square}="s" *\frm{-,},
    -<5em,-5em>@+,
 "o";"s" **{} ?*+\hbox{Bend}="b"*\frm{.},
 "o";"s"."b" **\crvs{-},
 "o"."b";"s" **\crvs{-} ?>*\dir{>}
\endxy

\mathchardef\bigp="3250
\mathchardef\bigq="3251
\mathchardef\bigslash="232C
\section{Homogeneous Transformations}
The study of robot manipulation is concerned with the relationship
between
objects, and between objects and manipulators. In this chapter we will
develop the representation necessary to describe these relationships.
Similar
problems of representation have already been solved in the field of
computer
graphics, where the relationship between objects must also be
described.
Homogeneous transformations are used in this field and in computer
vision
[Duda] [Robserts63] [Roberts65]. These transformations were employed by

Denavit to describe linkages [Denavit] and are now used to describe 
manipulators [Pieper] [Paul72] [Paul77b].

We will first establish notation for vectors and planes and then
introduce
transformations on them. These transformations consist primarily of
translation and rotation. We will then show that these transformations
can also be considered as coordinate frames in which to represent
objects, including the manipulator. The inverse transformation will
then be introduced. A later section describes the general rotation
transformation representing a rotation about a vector. An algorithm is
then described to find the equivalent axis and angle of rotations
represented by any given transformation. A brief section on stretching
and scaling transforms is included together with a section on the
perspective transformation. The chapter concludes with a section on
transformation equations.

\section{Notation}

In describing the relationship between objects we will make use of
point vectors, planes, and coordinate frames. Point vectors are
denoted by lower case, bold face characters. Planes are denoted by
script characters, and coordinate frames by upper case, bold face
characters. For example:

\begin{tabular}{ll}
vectors & {\bf v}, {\bf x1}, {\bf x} \\
planes  & $\bigp$, $\bigq$ \\
coordinate frames & {\bf I}, {\bf A}, {\bf CONV}\\
\end{tabular}\\

We will use point vectors, planes, and coordinate frames as variables
which have associated values. For example, a point vector has as value
its three Cartesian coordinate components.

If we wish to describe a point in space, which we will call {\sl p},
with respect to a coordinate frame {\bf E}, we will use a vector which
we will call {\bf v}. We will write this as

$$^E{\bf v}$$

\noindent
The leading superscript describes the defining coordinate frame.

We might also wish to describe this same point, {\sl p}, with respect
to a different coordinate frame, for example {\bf H}, using a vector
{\bf w} as

$$^H{\bf w}$$

\noindent
{\bf v} and {\bf w} are two vectors which probably have different
component values and ${\bf v} \ne {\bf w}$ even though both vectors
describe the same point {\sl p}. The case might also exist of a vector
{\bf a} describing a point 3 inches above any frame

$${^{F^1}}{\bf a}\qquad {^{F^2}}{\bf a}$$

\noindent
In this case the vectors are identical but describe different
points. Frequently, the defining frame will be obvious from the text
and the superscripts will be left off. In many cases the name of the
vector will be the same as the name of the object described, for
example, the tip of a pin might be described by a vector {\bf tip}
with respect to a frame {\bf BASE} as

$${^{BASE}}{\bf tip}$$

\noindent
If it were obvious from the text that we were describing the vector
with respect to {\bf BASE} then we might simply write

$${\bf tip}$$

If we also wish to describe this point with respect to another
coordinate frame say, {\bf HAND}, then we must use another vector to
describe this relationship, for example

$${^{HAND}{\bf tv}}$$

\noindent
${^{HAND}{\bf tv}}$ and {\bf tip} both describe the same feature but
have different values. In order to refer to individual components of
coordinate frames, point vectors, or planes, we add subscripts to
indicate the particular component. For example, the vector
${^{HAND}{\bf tv}}$ has components ${^{HAND}{\bf tv}}_{\bf x}$,
${^{HAND}{\bf tv}}_{\bf y}$, ${^{HAND}{\bf tv}}_{\bf z}$.

\hypertarget{Vectors}{\section{Vectors}}

The homogeneous coordinate representation of objects in $n$-space
is an $(n + 1)$-space entity such that a particular perspective
projection recreates the $n$-space. This can also be viewed as the
addition of an extra coordinate to each vector, a scale factor, such
that the vector has the same meaning if each component, including the
scale factor, is multiplied by a constant.

A point vector

$${\bf v} = a{\bf i} + b{\bf j} + c{\bf k}\eqno(1.1)$$

\noindent
where {\bf i}, {\bf j}, and {\bf k} are unit vectors along the $x$,
$y$, and $z$ coordinate axes, respectively, is represented in
homogeneous coordinates as a column matrix

$${\bf v} = \left[\matrix{{\bf x}\cr
                          {\bf y}\cr
                          {\bf z}\cr
                          {\bf w}\cr}
            \right]\eqno(1.2)$$

\noindent
where

$${{\bf a} = {\bf x}/{\bf w}}$$
$${{\bf b} = {\bf y}/{\bf w}}\eqno(1.3)$$
$${{\bf c} = {\bf z}/{\bf w}}$$

\noindent
Thus the vector $3{\bf i} + 4{\bf j} + 5{\bf k}$ can be represented as
$[3,4,5,1]^{\rm T}$ or as $[6,8,10,2]^{\rm T}$ or again 
as $[-30,-40,-50,-10]^{\rm T}$,
etc. The superscript $T$ indicates the transpose of the row vector
into a column vector. The vector at the origin, the null vector, is
represented as $[0,0,0,n]^{\rm T}$ where $n$ is any non-zero scale
factor. The vector $[0,0,0,0]^{\rm T}$ is undefined. Vectors of the
form
$[a,b,c,0]^{\rm T}$ represent vectors at infinity and are used to
represent
directions; the addition of any other finite vector does not change
their value in any way.

We will also make use of the vector dot and cross products. Given two
vectors

$${\bf a} = a_x{\bf i} + a_y{\bf j} + a_z{\bf k}\eqno(1.4)$$
$${\bf b} = b_x{\bf i} + b_y{\bf j} + b_z{\bf k}$$

\noindent
we define the vector dot product, indicated by ``$\cdot$'' as

$${\bf a} \cdot {\bf b} = {a_x}{b_x} + {a_y}{b_y} +
{a_z}{b_z}\eqno(1.5)$$

\noindent
The dot product of two vectors is a scalar. The cross product,
indicated by an ``$\times$'', is another vector perpendicular to the
plane formed by the vectors of the product and is defined by

$${\bf a} \times {\bf b} = ({a_y}{b_z} - {a_z}{b_y}){\bf i} +
                         ({a_z}{b_x} - {a_x}{b_z}){\bf j} +
                         ({a_x}{b_y} - {a_y}{b_x}){\bf k}\eqno(1.6)$$

\noindent
This definition is easily remembered as the expansion of the
determinant

$${\bf a} \times {\bf b} = 
  \left|\matrix{{\bf i}&{\bf j}&{\bf k}\cr
                 {a_x}&{a_y}&{a_z}\cr
                 {b_x}&{b_y}&{b_z}\cr}\right|\eqno(1.7)$$

\section{Planes}
A plane is represented as a row matrix

$$\bigp=[a,b,c,d]\eqno(1.8)$$

\noindent
such that if a point {\bf v} lies in a plane $\bigp$ the matrix
product

$$\bigp{\bf v} = 0\eqno(1.9)$$

\noindent
or in expanded form

$$xa + yb + zc + wd = 0\eqno(1.10)$$

\noindent
If we define a constant

$$m = +\sqrt{a^2 + b^2 + c^2}\eqno(1.11)$$

\noindent
and divide Equation 1.10 by $wm$ we obtain

$${x\over w}{a\over m} + {y\over w}{b\over m} + {z\over w}{c\over m} 
   = -{d\over m}\eqno(1.12)$$

\noindent
The left hand side of Equation 1.12 is the vector dot product of two
vectors $(x/w){\bf i} + (y/w){\bf j} + (z/w){\bf k}$ and 
$(a/m){\bf i} + (b/m){\bf j} + (c/m){\bf k}$ and represents the
directed distance of the point 
$(x/w){\bf i} + (y/w){\bf j} + (z/w){\bf k}$ along the vector\\
$(a/m){\bf i} + (b/m){\bf j} + (c/m){\bf k}$. The vector
$(a/m){\bf i} + (b/m){\bf j} + (c/m){\bf k}$ can be interpreted as the
outward pointing normal of a plane situated a distance $-d/m$ from the
origin in the direction of the normal. Thus a plane $\bigp$ parallel
to the $x$,$y$ plane, one unit along the $z$ axis, is represented as

$${\rm {\ \ \ \ \ \ \ \ \ }} \bigp = [0,0,1,-1]\eqno(1.13)$$
$${\rm {or\  as\ \ \ }} \bigp = [0,0,2,-2]\eqno(1.14)$$
$${\rm {\ \ \ \ \ or\  as\ \ \ }} \bigp = [0,0,-100,100]\eqno(1.15)$$

\noindent
A point ${\bf v} = [10,20,1,1]$ should lie in this plane

$$[0,0,-100,100]\left[\matrix{10\cr
                              20\cr
                               1\cr
                               1\cr}
                \right]
     = 0\eqno(1.16)$$

\noindent
or

$$[0,0,1,-1]\left[\matrix{ -5\cr
                          -10\cr
                          -.5\cr
                          -.5\cr}
             \right]
     = 0\eqno(1.17)$$

\noindent
The point ${\bf v} = [0,0,2,1]$ lies above the plane

$$[0,0,2,-2]\left[\matrix{0\cr
                          0\cr
                          2\cr
                          1\cr}
             \right]
     = 2\eqno(1.18)$$

and $\bigp{\bf v}$ is indeed positive, indicating that the point is
outside the plane in the direction of the outward pointing normal. A
point ${\bf v} = [0,0,0,1]$ lies below the plane

$$[0,0,1,-1]\left[\matrix{0\cr
                          0\cr
                          0\cr
                          1\cr}
             \right]
     = -1\eqno(1.19)$$

\noindent
The plane $[0,0,0,0]$ is undefined.

\end{document}

\start
Date: Fri, 11 Nov 2005 21:15:12 -0800
From: Karl Hegbloom
To: list
Subject: [Bug?] "error in library; negative log"

Attached is a session log showing an error that I receive while
attempting to produce a sequence from an expression in Axiom.  Maxima
seems to have no trouble with the similar expression, and computing the
value of the expression by hand, as you can see, seems to work fine
also.

Another problem I have is that taking the limit of an expression
containing (-1)^n always returns "failed", where my TI-89 Titanium
calculator will give a finite limit.  For example:

 limit( 2 + (-2/%pi)^n, n=%plusInfinity )  ===> "failed"

... but the TI-89t returns 2.

The TI-89t says that the limit of (-1)^n as n approaches infinity is -1,
implying that it believes that infinity is an odd number.  That kind of
makes sense to me, since if you divide infinity in half, you still have
infinity, and you keep adding 1 to get to infinity, making it odd.  If
infinity is even then the answer should be 1, and if we can't know if
infinity is even or odd, then the answer is uncertain or undefined.

On the other hand, the TI-89t says that lim ( (-1)^n * (n + 1)/n ) is
undefined.  But it already told me that lim (-1)^n = -1, and that lim (n
+ 1)/n = 1.  If the limit of a product is the product of the limits of
the factors, then lim ( (-1)^n * (n + 1)/n ) should be -1, right?

So, who's right?

-- 
Karl Hegbloom

--=-4v9s0O0l3NDtDMAIF9RE

Q:	What do monsters eat?
A:	Things.

Q:	What do monsters drink?
A:	Coke.  (Because Things go better with Coke.)
% axiom
GCL (GNU Common Lisp)  2.6.7 CLtL1    Sep 26 2005 15:30:02
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
                        AXIOM Computer Algebra System 
                     Version: Axiom 3.9 (September 2005)
              Timestamp: Monday September 26, 2005 at 17:32:58 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------
 
   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase
   RationalInterpolationAlgorithms is now explicitly exposed in frame 
      initial 
   RationalInterpolationAlgorithms will be automatically loaded when 
      needed from 
      /home/karlheg/src/Mathematics/Axiom/Lib/RINTERPA.NRLIB/code
   RationalInterpolation is now explicitly exposed in frame initial 
   RationalInterpolation will be automatically loaded when needed from 
      /home/karlheg/src/Mathematics/Axiom/Lib/RINTERP.NRLIB/code
   PolynomialCommonDenominator is now explicitly exposed in frame 
      initial 
   PolynomialCommonDenominator will be automatically loaded when needed
      from /home/karlheg/src/Mathematics/Axiom/Lib/PCDEN.NRLIB/code
   GuessPolynomial is now explicitly exposed in frame initial 
   GuessPolynomial will be automatically loaded when needed from 
      /home/karlheg/src/Mathematics/Axiom/Lib/GUESSP.NRLIB/code
   GuessInteger is now explicitly exposed in frame initial 
   GuessInteger will be automatically loaded when needed from 
      /home/karlheg/src/Mathematics/Axiom/Lib/GUESSINT.NRLIB/code
   Guess is now explicitly exposed in frame initial 
   Guess will be automatically loaded when needed from 
      /home/karlheg/src/Mathematics/Axiom/Lib/GUESS.NRLIB/code
   Loading /usr/lib/axiom-20050901/autoload/bc-matrix.
   Loading /usr/lib/axiom-20050901/autoload/bc-misc.
   Loading /usr/lib/axiom-20050901/autoload/bc-solve.
   Loading /usr/lib/axiom-20050901/autoload/bc-util.
   Loading /usr/lib/axiom-20050901/autoload/ht-util.
   Loading /usr/lib/axiom-20050901/autoload/htsetvar.
   Loading /usr/lib/axiom-20050901/autoload/ht-root.
   Loading /usr/lib/axiom-20050901/autoload/br-con.
   Loading /usr/lib/axiom-20050901/autoload/br-data.
   Loading /usr/lib/axiom-20050901/autoload/showimp.
   Loading /usr/lib/axiom-20050901/autoload/br-op1.
   Loading /usr/lib/axiom-20050901/autoload/br-op2.
   Loading /usr/lib/axiom-20050901/autoload/br-search.
   Loading /usr/lib/axiom-20050901/autoload/br-util.
   Loading /usr/lib/axiom-20050901/autoload/topics.
   Loading /usr/lib/axiom-20050901/autoload/br-prof.
   Loading /usr/lib/axiom-20050901/autoload/br-saturn.
initial (1) -> 
frame0 (1) -> f == 2.0 + (-2.0/(%pi::Float))**n;
                                                                   Type: Void
frame0 (2) -> [[i,(eval(f,n=i))] for i in 1..20]
   Loading /usr/lib/axiom-20050901/algebra/FLOAT.o for domain Float 
   Loading /usr/lib/axiom-20050901/algebra/HACKPI.o for domain Pi 
   Loading /usr/lib/axiom-20050901/algebra/UPMP.o for package 
      UnivariatePolynomialMultiplicationPackage 
   Loading /usr/lib/axiom-20050901/algebra/EXPR.o for domain Expression
      
   Loading /usr/lib/axiom-20050901/algebra/KERNEL.o for domain Kernel 
   Loading /usr/lib/axiom-20050901/algebra/BOP.o for domain 
      BasicOperator 
   Loading /usr/lib/axiom-20050901/algebra/SCACHE.o for package 
      SortedCache 
   Loading /usr/lib/axiom-20050901/algebra/VOID.o for domain Void 
   Loading /usr/lib/axiom-20050901/algebra/AN.o for domain 
      AlgebraicNumber 
   Loading /usr/lib/axiom-20050901/algebra/IAN.o for domain 
      InnerAlgebraicNumber 
   Loading /usr/lib/axiom-20050901/algebra/ACFS-.o for domain 
      AlgebraicallyClosedFunctionSpace& 
   Loading /usr/lib/axiom-20050901/algebra/FS-.o for domain 
      FunctionSpace& 
   Loading /usr/lib/axiom-20050901/algebra/COMMONOP.o for package 
      CommonOperators 
   Loading /usr/lib/axiom-20050901/algebra/KDAGG-.o for domain 
      KeyedDictionary& 
   Loading /usr/lib/axiom-20050901/algebra/DIAGG-.o for domain 
      Dictionary& 
   Loading /usr/lib/axiom-20050901/algebra/BOP1.o for package 
      BasicOperatorFunctions1 
   Loading /usr/lib/axiom-20050901/algebra/ACF-.o for domain 
      AlgebraicallyClosedField& 
   Compiling body of rule f to compute value of type Expression Float 
   Loading /usr/lib/axiom-20050901/algebra/EQ.o for domain Equation 
   Loading /usr/lib/axiom-20050901/algebra/ES-.o for domain 
      ExpressionSpace& 
   Loading /usr/lib/axiom-20050901/algebra/FRETRCT-.o for domain 
      FullyRetractableTo& 
   Loading /usr/lib/axiom-20050901/algebra/EVALAB-.o for domain 
      Evalable& 
   Loading /usr/lib/axiom-20050901/algebra/FPS-.o for domain 
      FloatingPointSystem& 
   Loading /usr/lib/axiom-20050901/algebra/RNS-.o for domain 
      RealNumberSystem& 
   Loading /usr/lib/axiom-20050901/algebra/POLYCATQ.o for package 
      PolynomialCategoryQuotientFunctions 
   Loading /usr/lib/axiom-20050901/algebra/COMBF.o for package 
      CombinatorialFunction 
   Loading /usr/lib/axiom-20050901/algebra/EQ2.o for package 
      EquationFunctions2 
   Loading /usr/lib/axiom-20050901/algebra/POLY2.o for package 
      PolynomialFunctions2 
   Loading /usr/lib/axiom-20050901/algebra/POLYLIFT.o for package 
      PolynomialCategoryLifting 
   Loading /usr/lib/axiom-20050901/algebra/FSAGG-.o for domain 
      FiniteSetAggregate& 
   Loading /usr/lib/axiom-20050901/algebra/FLASORT.o for package 
      FiniteLinearAggregateSort 
   Loading /usr/lib/axiom-20050901/algebra/LIST2MAP.o for package 
      ListToMap 
 
   >> Error detected within library code:
   negative log

frame0 (2) -> f == 2.0 + (-2.0/(%pi::Float))**n;
   Compiled code for f has been cleared.
   1 old definition(s) deleted for function or rule f 
                                                                   Type: Void
frame0 (3) -> [[i,(eval(f,n=i))] for i in 1..20]
   Compiling body of rule f to compute value of type Expression Float 
   Loading /usr/lib/axiom-20050901/algebra/IDPOAMS.o for domain 
      IndexedDirectProductOrderedAbelianMonoidSup 
   Loading /usr/lib/axiom-20050901/algebra/IDPOAM.o for domain 
      IndexedDirectProductOrderedAbelianMonoid 
 
   >> Error detected within library code:
   negative log

frame0 (3) -> f == 2.0 + (-2.0/(%pi::Float))**n;
   Compiled code for f has been cleared.
   1 old definition(s) deleted for function or rule f 
                                                                   Type: Void
frame0 (4) -> [[i,(eval(f,n=i))] for i in 1..20]
   Compiling body of rule f to compute value of type Expression Float 
 
   >> Error detected within library code:
   negative log

frame0 (4) -> f

   Loading /usr/lib/axiom-20050901/algebra/UNISEG.o for domain 
      UniversalSegment 
                                         n
   (4)  (- 0.6366197723 6758134307 55351)  + 2.0
                                                       Type: Expression Float
frame0 (5) -> -2.0/%pi::Float

   (5)  - 0.6366197723 6758134307 55351
                                                                  Type: Float
frame0 (6) -> % ** 2

   (6)  0.4052847345 6935108577 55179
                                                                  Type: Float
frame0 (7) -> 2 + %

   (7)  2.4052847345 6935108577 5518
                                                                  Type: Float
frame0 (8) -> %%(5)**3

   (8)  - 0.2580122754 6559591347 53764
                                                                  Type: Float
frame0 (9) -> 2 + %

   (9)  1.7419877245 3440408652 4624
                                                                  Type: Float
frame0 (10) -> 
--=-4v9s0O0l3NDtDMAIF9RE--

\start
Date: Sat, 12 Nov 2005 01:17:22 -0500
From: Tim Daly
To: Karl Hegbloom
Subject: Re: [Bug?] "error in library; negative log"

TI uses Derive, I believe, which is from David Stoutmeyer of Soft
Warehouse. Believe me, if David thinks infinity is odd he's probably
right :-)

\start
Date: Sat, 12 Nov 2005 01:18:30 -0500
From: Tim Daly
To: Karl Hegbloom
Subject: Re: [Bug?] "error in library; negative log"

it would be useful if you posted this email to 
http://wiki.axiom-developer.org/IssueTracker

\start
Date: Fri, 11 Nov 2005 22:13:51 -0800
From: Bob McElrath
To: Karl Hegbloom
Subject: Re: [Bug?] "error in library; negative log"

(-1)^\infty is an indeterminate expression, like 0/0.

Mathematica returns Indeterminate, and maple returns "-1 .. 1" since the
limit is bounded, but indeterminate on the interval [-1,1].

Infinity is neither even nor odd.

Karl Hegbloom [Karl Hegbloom] wrote:
> Attached is a session log showing an error that I receive while
> attempting to produce a sequence from an expression in Axiom.  Maxima
> seems to have no trouble with the similar expression, and computing the
> value of the expression by hand, as you can see, seems to work fine
> also.
> 
> Another problem I have is that taking the limit of an expression
> containing (-1)^n always returns "failed", where my TI-89 Titanium
> calculator will give a finite limit.  For example:
> 
>  limit( 2 + (-2/%pi)^n, n=%plusInfinity )  ===> "failed"
> 
> ... but the TI-89t returns 2.
> 
> The TI-89t says that the limit of (-1)^n as n approaches infinity is -1,
> implying that it believes that infinity is an odd number.  That kind of
> makes sense to me, since if you divide infinity in half, you still have
> infinity, and you keep adding 1 to get to infinity, making it odd.  If
> infinity is even then the answer should be 1, and if we can't know if
> infinity is even or odd, then the answer is uncertain or undefined.
> 
> On the other hand, the TI-89t says that lim ( (-1)^n * (n + 1)/n ) is
> undefined.  But it already told me that lim (-1)^n = -1, and that lim (n
> + 1)/n = 1.  If the limit of a product is the product of the limits of
> the factors, then lim ( (-1)^n * (n + 1)/n ) should be -1, right?
> 
> So, who's right?

\start
Date: Fri, 11 Nov 2005 20:11:23 -0800 (PST)
From: Cliff Yapp
To: Cliff Yapp, list
Subject: Re: Anyone familiar with Xy-pic?

--- Cliff Yapp wrote:

> Tim, you had mentioned earlier wanting to be able to click on the
> names of elements in generated graphs of the source code and be 
> taken to that point in the text. 

Or, more precisely:

"i'd like to get diagrams autogenerated in the book. and i'd like
to be able to click on graph nodes entries and go right to the code
(hyperlinking in graphs)."

The autogeneration is going to be quite a trick, and the hyperlinking
in graphs isn't any cakewalk either, but I think I've demonstrated the
possibility of the hyperlinking part.  Basically I made the crudest
test imaginable - I cut and pasted an example from the XY-pic docs and
added it to a subset of the dhmatrix tex file - basically just enough
to let me try \usepackage{axiom}, \usepackage[all]{xy}, and
\usepackage[<fancystuff>]{hyperref} together.  Then I replaced the text
in one of the XY-pic objects with hyperref hyperlinking commands, and
added a target around a section header, and darned if it didn't work,
at at least with pdflatex!

Just for fun (and in case my machine wipes out) I'll attach the tex
document, but it's nothing to write home about.  (Does the list allow
attachments?) XY-pic is not for the faint of heart (it reminds me of
looking at some of the more mangled perl scripts I've seen, actually)
but it also looks very, very powerful, so I'll take a shot at it.  (I
don't even faintly understand the example in the attachment yet, which
is why its not a better example of what we would want.) The main
question looks to be automatic layout, and that could be a problem.  I
haven't been able to figure out what XY-pics abilities are in that
department, but I'm assuming it's not really designed for that.

__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com
--0-902339947-1131768683=:93603

XGRvY3VtZW50Y2xhc3N7YXJ0aWNsZX0KXHVzZXBhY2thZ2V7YXhpb219Clx1
c2VwYWNrYWdlW2FsbF17eHl9ClxpZnhccGRmb3V0cHV0XHVuZGVmaW5lZAog
IFx1c2VwYWNrYWdlW2JhY2tyZWY9ZmFsc2UsIGNvbG9ybGlua3M9ZmFsc2Us
IGJyZWFrbGlua3M9dHJ1ZV17aHlwZXJyZWZ9CiBcZWxzZQogIFx1c2VwYWNr
YWdlW3BkZnRleD10cnVlLCBwbGFpbnBhZ2VzPWZhbHNlLCBjb2xvcmxpbmtz
PXRydWUsIGxpbmtjb2xvcj1ibHVlLCBicmVha2xpbmtzPXRydWUsIHBkZnBh
Z2VsYWJlbHMsIAogICAgICAgICAgICAgIGJvb2ttYXJrc29wZW49ZmFsc2Us
IHBkZm5ld3dpbmRvdz10cnVlLAogICAgICAgICAgICAgIHBkZnN0YXJ0dmll
dz1GaXRILCBwZGZwYWdlbW9kZT1Vc2VPdXRsaW5lc117aHlwZXJyZWZ9Clxm
aQoKCgpcYmVnaW57ZG9jdW1lbnR9Clx4eSAqW29dPTw0MHB0PlxoYm94e1xo
eXBlcmxpbmt7VmVjdG9yc317VmVjdG9yc319PSJvIipcZnJte29vfSwKICAg
ICs8NWVtLC01ZW0+QCssCiAgICAoNDYsMTEpKitcaGJveHtTcXVhcmV9PSJz
IiAqXGZybXstLH0sCiAgICAtPDVlbSwtNWVtPkArLAogIm8iOyJzIiAqKnt9
ID8qK1xoYm94e0JlbmR9PSJiIipcZnJtey59LAogIm8iOyJzIi4iYiIgKipc
Y3J2c3stfSwKICJvIi4iYiI7InMiICoqXGNydnN7LX0gPz4qXGRpcns+fQpc
ZW5keHkKCgoKXG1hdGhjaGFyZGVmXGJpZ3A9IjMyNTAKXG1hdGhjaGFyZGVm
XGJpZ3E9IjMyNTEKXG1hdGhjaGFyZGVmXGJpZ3NsYXNoPSIyMzJDClxzZWN0
aW9ue0hvbW9nZW5lb3VzIFRyYW5zZm9ybWF0aW9uc30KVGhlIHN0dWR5IG9m
IHJvYm90IG1hbmlwdWxhdGlvbiBpcyBjb25jZXJuZWQgd2l0aCB0aGUgcmVs
YXRpb25zaGlwIGJldHdlZW4Kb2JqZWN0cywgYW5kIGJldHdlZW4gb2JqZWN0
cyBhbmQgbWFuaXB1bGF0b3JzLiBJbiB0aGlzIGNoYXB0ZXIgd2Ugd2lsbApk
ZXZlbG9wIHRoZSByZXByZXNlbnRhdGlvbiBuZWNlc3NhcnkgdG8gZGVzY3Jp
YmUgdGhlc2UgcmVsYXRpb25zaGlwcy4gU2ltaWxhcgpwcm9ibGVtcyBvZiBy
ZXByZXNlbnRhdGlvbiBoYXZlIGFscmVhZHkgYmVlbiBzb2x2ZWQgaW4gdGhl
IGZpZWxkIG9mIGNvbXB1dGVyCmdyYXBoaWNzLCB3aGVyZSB0aGUgcmVsYXRp
b25zaGlwIGJldHdlZW4gb2JqZWN0cyBtdXN0IGFsc28gYmUgZGVzY3JpYmVk
LgpIb21vZ2VuZW91cyB0cmFuc2Zvcm1hdGlvbnMgYXJlIHVzZWQgaW4gdGhp
cyBmaWVsZCBhbmQgaW4gY29tcHV0ZXIgdmlzaW9uCltEdWRhXSBbUm9ic2Vy
dHM2M10gW1JvYmVydHM2NV0uIFRoZXNlIHRyYW5zZm9ybWF0aW9ucyB3ZXJl
IGVtcGxveWVkIGJ5IApEZW5hdml0IHRvIGRlc2NyaWJlIGxpbmthZ2VzIFtE
ZW5hdml0XSBhbmQgYXJlIG5vdyB1c2VkIHRvIGRlc2NyaWJlIAptYW5pcHVs
YXRvcnMgW1BpZXBlcl0gW1BhdWw3Ml0gW1BhdWw3N2JdLgoKV2Ugd2lsbCBm
aXJzdCBlc3RhYmxpc2ggbm90YXRpb24gZm9yIHZlY3RvcnMgYW5kIHBsYW5l
cyBhbmQgdGhlbiBpbnRyb2R1Y2UKdHJhbnNmb3JtYXRpb25zIG9uIHRoZW0u
IFRoZXNlIHRyYW5zZm9ybWF0aW9ucyBjb25zaXN0IHByaW1hcmlseSBvZgp0
cmFuc2xhdGlvbiBhbmQgcm90YXRpb24uIFdlIHdpbGwgdGhlbiBzaG93IHRo
YXQgdGhlc2UgdHJhbnNmb3JtYXRpb25zCmNhbiBhbHNvIGJlIGNvbnNpZGVy
ZWQgYXMgY29vcmRpbmF0ZSBmcmFtZXMgaW4gd2hpY2ggdG8gcmVwcmVzZW50
Cm9iamVjdHMsIGluY2x1ZGluZyB0aGUgbWFuaXB1bGF0b3IuIFRoZSBpbnZl
cnNlIHRyYW5zZm9ybWF0aW9uIHdpbGwKdGhlbiBiZSBpbnRyb2R1Y2VkLiBB
IGxhdGVyIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBnZW5lcmFsIHJvdGF0aW9u
CnRyYW5zZm9ybWF0aW9uIHJlcHJlc2VudGluZyBhIHJvdGF0aW9uIGFib3V0
IGEgdmVjdG9yLiBBbiBhbGdvcml0aG0gaXMKdGhlbiBkZXNjcmliZWQgdG8g
ZmluZCB0aGUgZXF1aXZhbGVudCBheGlzIGFuZCBhbmdsZSBvZiByb3RhdGlv
bnMKcmVwcmVzZW50ZWQgYnkgYW55IGdpdmVuIHRyYW5zZm9ybWF0aW9uLiBB
IGJyaWVmIHNlY3Rpb24gb24gc3RyZXRjaGluZwphbmQgc2NhbGluZyB0cmFu
c2Zvcm1zIGlzIGluY2x1ZGVkIHRvZ2V0aGVyIHdpdGggYSBzZWN0aW9uIG9u
IHRoZQpwZXJzcGVjdGl2ZSB0cmFuc2Zvcm1hdGlvbi4gVGhlIGNoYXB0ZXIg
Y29uY2x1ZGVzIHdpdGggYSBzZWN0aW9uIG9uCnRyYW5zZm9ybWF0aW9uIGVx
dWF0aW9ucy4KClxzZWN0aW9ue05vdGF0aW9ufQoKSW4gZGVzY3JpYmluZyB0
aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gb2JqZWN0cyB3ZSB3aWxsIG1ha2Ug
dXNlIG9mCnBvaW50IHZlY3RvcnMsIHBsYW5lcywgYW5kIGNvb3JkaW5hdGUg
ZnJhbWVzLiBQb2ludCB2ZWN0b3JzIGFyZQpkZW5vdGVkIGJ5IGxvd2VyIGNh
c2UsIGJvbGQgZmFjZSBjaGFyYWN0ZXJzLiBQbGFuZXMgYXJlIGRlbm90ZWQg
YnkKc2NyaXB0IGNoYXJhY3RlcnMsIGFuZCBjb29yZGluYXRlIGZyYW1lcyBi
eSB1cHBlciBjYXNlLCBib2xkIGZhY2UKY2hhcmFjdGVycy4gRm9yIGV4YW1w
bGU6CgpcYmVnaW57dGFidWxhcn17bGx9CnZlY3RvcnMgJiB7XGJmIHZ9LCB7
XGJmIHgxfSwge1xiZiB4fSBcXApwbGFuZXMgICYgJFxiaWdwJCwgJFxiaWdx
JCBcXApjb29yZGluYXRlIGZyYW1lcyAmIHtcYmYgSX0sIHtcYmYgQX0sIHtc
YmYgQ09OVn1cXApcZW5ke3RhYnVsYXJ9XFwKCldlIHdpbGwgdXNlIHBvaW50
IHZlY3RvcnMsIHBsYW5lcywgYW5kIGNvb3JkaW5hdGUgZnJhbWVzIGFzIHZh
cmlhYmxlcwp3aGljaCBoYXZlIGFzc29jaWF0ZWQgdmFsdWVzLiBGb3IgZXhh
bXBsZSwgYSBwb2ludCB2ZWN0b3IgaGFzIGFzIHZhbHVlCml0cyB0aHJlZSBD
YXJ0ZXNpYW4gY29vcmRpbmF0ZSBjb21wb25lbnRzLgoKSWYgd2Ugd2lzaCB0
byBkZXNjcmliZSBhIHBvaW50IGluIHNwYWNlLCB3aGljaCB3ZSB3aWxsIGNh
bGwge1xzbCBwfSwKd2l0aCByZXNwZWN0IHRvIGEgY29vcmRpbmF0ZSBmcmFt
ZSB7XGJmIEV9LCB3ZSB3aWxsIHVzZSBhIHZlY3RvciB3aGljaAp3ZSB3aWxs
IGNhbGwge1xiZiB2fS4gV2Ugd2lsbCB3cml0ZSB0aGlzIGFzCgokJF5Fe1xi
ZiB2fSQkCgpcbm9pbmRlbnQKVGhlIGxlYWRpbmcgc3VwZXJzY3JpcHQgZGVz
Y3JpYmVzIHRoZSBkZWZpbmluZyBjb29yZGluYXRlIGZyYW1lLgoKV2UgbWln
aHQgYWxzbyB3aXNoIHRvIGRlc2NyaWJlIHRoaXMgc2FtZSBwb2ludCwge1xz
bCBwfSwgd2l0aCByZXNwZWN0CnRvIGEgZGlmZmVyZW50IGNvb3JkaW5hdGUg
ZnJhbWUsIGZvciBleGFtcGxlIHtcYmYgSH0sIHVzaW5nIGEgdmVjdG9yCntc
YmYgd30gYXMKCiQkXkh7XGJmIHd9JCQKClxub2luZGVudAp7XGJmIHZ9IGFu
ZCB7XGJmIHd9IGFyZSB0d28gdmVjdG9ycyB3aGljaCBwcm9iYWJseSBoYXZl
IGRpZmZlcmVudApjb21wb25lbnQgdmFsdWVzIGFuZCAke1xiZiB2fSBcbmUg
e1xiZiB3fSQgZXZlbiB0aG91Z2ggYm90aCB2ZWN0b3JzCmRlc2NyaWJlIHRo
ZSBzYW1lIHBvaW50IHtcc2wgcH0uIFRoZSBjYXNlIG1pZ2h0IGFsc28gZXhp
c3Qgb2YgYSB2ZWN0b3IKe1xiZiBhfSBkZXNjcmliaW5nIGEgcG9pbnQgMyBp
bmNoZXMgYWJvdmUgYW55IGZyYW1lCgokJHtee0ZeMX19e1xiZiBhfVxxcXVh
ZCB7XntGXjJ9fXtcYmYgYX0kJAoKXG5vaW5kZW50CkluIHRoaXMgY2FzZSB0
aGUgdmVjdG9ycyBhcmUgaWRlbnRpY2FsIGJ1dCBkZXNjcmliZSBkaWZmZXJl
bnQKcG9pbnRzLiBGcmVxdWVudGx5LCB0aGUgZGVmaW5pbmcgZnJhbWUgd2ls
bCBiZSBvYnZpb3VzIGZyb20gdGhlIHRleHQKYW5kIHRoZSBzdXBlcnNjcmlw
dHMgd2lsbCBiZSBsZWZ0IG9mZi4gSW4gbWFueSBjYXNlcyB0aGUgbmFtZSBv
ZiB0aGUKdmVjdG9yIHdpbGwgYmUgdGhlIHNhbWUgYXMgdGhlIG5hbWUgb2Yg
dGhlIG9iamVjdCBkZXNjcmliZWQsIGZvcgpleGFtcGxlLCB0aGUgdGlwIG9m
IGEgcGluIG1pZ2h0IGJlIGRlc2NyaWJlZCBieSBhIHZlY3RvciB7XGJmIHRp
cH0Kd2l0aCByZXNwZWN0IHRvIGEgZnJhbWUge1xiZiBCQVNFfSBhcwoKJCR7
XntCQVNFfX17XGJmIHRpcH0kJAoKXG5vaW5kZW50CklmIGl0IHdlcmUgb2J2
aW91cyBmcm9tIHRoZSB0ZXh0IHRoYXQgd2Ugd2VyZSBkZXNjcmliaW5nIHRo
ZSB2ZWN0b3IKd2l0aCByZXNwZWN0IHRvIHtcYmYgQkFTRX0gdGhlbiB3ZSBt
aWdodCBzaW1wbHkgd3JpdGUKCiQke1xiZiB0aXB9JCQKCklmIHdlIGFsc28g
d2lzaCB0byBkZXNjcmliZSB0aGlzIHBvaW50IHdpdGggcmVzcGVjdCB0byBh
bm90aGVyCmNvb3JkaW5hdGUgZnJhbWUgc2F5LCB7XGJmIEhBTkR9LCB0aGVu
IHdlIG11c3QgdXNlIGFub3RoZXIgdmVjdG9yIHRvCmRlc2NyaWJlIHRoaXMg
cmVsYXRpb25zaGlwLCBmb3IgZXhhbXBsZQoKJCR7XntIQU5EfXtcYmYgdHZ9
fSQkCgpcbm9pbmRlbnQKJHtee0hBTkR9e1xiZiB0dn19JCBhbmQge1xiZiB0
aXB9IGJvdGggZGVzY3JpYmUgdGhlIHNhbWUgZmVhdHVyZSBidXQKaGF2ZSBk
aWZmZXJlbnQgdmFsdWVzLiBJbiBvcmRlciB0byByZWZlciB0byBpbmRpdmlk
dWFsIGNvbXBvbmVudHMgb2YKY29vcmRpbmF0ZSBmcmFtZXMsIHBvaW50IHZl
Y3RvcnMsIG9yIHBsYW5lcywgd2UgYWRkIHN1YnNjcmlwdHMgdG8KaW5kaWNh
dGUgdGhlIHBhcnRpY3VsYXIgY29tcG9uZW50LiBGb3IgZXhhbXBsZSwgdGhl
IHZlY3Rvcgoke157SEFORH17XGJmIHR2fX0kIGhhcyBjb21wb25lbnRzICR7
XntIQU5EfXtcYmYgdHZ9fV97XGJmIHh9JCwKJHtee0hBTkR9e1xiZiB0dn19
X3tcYmYgeX0kLCAke157SEFORH17XGJmIHR2fX1fe1xiZiB6fSQuCgpcaHlw
ZXJ0YXJnZXR7VmVjdG9yc317XHNlY3Rpb257VmVjdG9yc319CgpUaGUgaG9t
b2dlbmVvdXMgY29vcmRpbmF0ZSByZXByZXNlbnRhdGlvbiBvZiBvYmplY3Rz
IGluICRuJC1zcGFjZQppcyBhbiAkKG4gKyAxKSQtc3BhY2UgZW50aXR5IHN1
Y2ggdGhhdCBhIHBhcnRpY3VsYXIgcGVyc3BlY3RpdmUKcHJvamVjdGlvbiBy
ZWNyZWF0ZXMgdGhlICRuJC1zcGFjZS4gVGhpcyBjYW4gYWxzbyBiZSB2aWV3
ZWQgYXMgdGhlCmFkZGl0aW9uIG9mIGFuIGV4dHJhIGNvb3JkaW5hdGUgdG8g
ZWFjaCB2ZWN0b3IsIGEgc2NhbGUgZmFjdG9yLCBzdWNoCnRoYXQgdGhlIHZl
Y3RvciBoYXMgdGhlIHNhbWUgbWVhbmluZyBpZiBlYWNoIGNvbXBvbmVudCwg
aW5jbHVkaW5nIHRoZQpzY2FsZSBmYWN0b3IsIGlzIG11bHRpcGxpZWQgYnkg
YSBjb25zdGFudC4KCkEgcG9pbnQgdmVjdG9yCgokJHtcYmYgdn0gPSBhe1xi
ZiBpfSArIGJ7XGJmIGp9ICsgY3tcYmYga31cZXFubygxLjEpJCQKClxub2lu
ZGVudAp3aGVyZSB7XGJmIGl9LCB7XGJmIGp9LCBhbmQge1xiZiBrfSBhcmUg
dW5pdCB2ZWN0b3JzIGFsb25nIHRoZSAkeCQsCiR5JCwgYW5kICR6JCBjb29y
ZGluYXRlIGF4ZXMsIHJlc3BlY3RpdmVseSwgaXMgcmVwcmVzZW50ZWQgaW4K
aG9tb2dlbmVvdXMgY29vcmRpbmF0ZXMgYXMgYSBjb2x1bW4gbWF0cml4Cgok
JHtcYmYgdn0gPSBcbGVmdFtcbWF0cml4e3tcYmYgeH1cY3IKICAgICAgICAg
ICAgICAgICAgICAgICAgICB7XGJmIHl9XGNyCiAgICAgICAgICAgICAgICAg
ICAgICAgICAge1xiZiB6fVxjcgogICAgICAgICAgICAgICAgICAgICAgICAg
IHtcYmYgd31cY3J9CiAgICAgICAgICAgIFxyaWdodF1cZXFubygxLjIpJCQK
Clxub2luZGVudAp3aGVyZQoKJCR7e1xiZiBhfSA9IHtcYmYgeH0ve1xiZiB3
fX0kJAokJHt7XGJmIGJ9ID0ge1xiZiB5fS97XGJmIHd9fVxlcW5vKDEuMykk
JAokJHt7XGJmIGN9ID0ge1xiZiB6fS97XGJmIHd9fSQkCgpcbm9pbmRlbnQK
VGh1cyB0aGUgdmVjdG9yICQze1xiZiBpfSArIDR7XGJmIGp9ICsgNXtcYmYg
a30kIGNhbiBiZSByZXByZXNlbnRlZCBhcwokWzMsNCw1LDFdXntccm0gVH0k
IG9yIGFzICRbNiw4LDEwLDJdXntccm0gVH0kIG9yIGFnYWluIAphcyAkWy0z
MCwtNDAsLTUwLC0xMF1ee1xybSBUfSQsCmV0Yy4gVGhlIHN1cGVyc2NyaXB0
ICRUJCBpbmRpY2F0ZXMgdGhlIHRyYW5zcG9zZSBvZiB0aGUgcm93IHZlY3Rv
cgppbnRvIGEgY29sdW1uIHZlY3Rvci4gVGhlIHZlY3RvciBhdCB0aGUgb3Jp
Z2luLCB0aGUgbnVsbCB2ZWN0b3IsIGlzCnJlcHJlc2VudGVkIGFzICRbMCww
LDAsbl1ee1xybSBUfSQgd2hlcmUgJG4kIGlzIGFueSBub24temVybyBzY2Fs
ZQpmYWN0b3IuIFRoZSB2ZWN0b3IgJFswLDAsMCwwXV57XHJtIFR9JCBpcyB1
bmRlZmluZWQuIFZlY3RvcnMgb2YgdGhlIGZvcm0KJFthLGIsYywwXV57XHJt
IFR9JCByZXByZXNlbnQgdmVjdG9ycyBhdCBpbmZpbml0eSBhbmQgYXJlIHVz
ZWQgdG8gcmVwcmVzZW50CmRpcmVjdGlvbnM7IHRoZSBhZGRpdGlvbiBvZiBh
bnkgb3RoZXIgZmluaXRlIHZlY3RvciBkb2VzIG5vdCBjaGFuZ2UKdGhlaXIg
dmFsdWUgaW4gYW55IHdheS4KCldlIHdpbGwgYWxzbyBtYWtlIHVzZSBvZiB0
aGUgdmVjdG9yIGRvdCBhbmQgY3Jvc3MgcHJvZHVjdHMuIEdpdmVuIHR3bwp2
ZWN0b3JzCgokJHtcYmYgYX0gPSBhX3h7XGJmIGl9ICsgYV95e1xiZiBqfSAr
IGFfentcYmYga31cZXFubygxLjQpJCQKJCR7XGJmIGJ9ID0gYl94e1xiZiBp
fSArIGJfeXtcYmYgan0gKyBiX3p7XGJmIGt9JCQKClxub2luZGVudAp3ZSBk
ZWZpbmUgdGhlIHZlY3RvciBkb3QgcHJvZHVjdCwgaW5kaWNhdGVkIGJ5IGBg
JFxjZG90JCcnIGFzCgokJHtcYmYgYX0gXGNkb3Qge1xiZiBifSA9IHthX3h9
e2JfeH0gKyB7YV95fXtiX3l9ICsge2Ffen17Yl96fVxlcW5vKDEuNSkkJAoK
XG5vaW5kZW50ClRoZSBkb3QgcHJvZHVjdCBvZiB0d28gdmVjdG9ycyBpcyBh
IHNjYWxhci4gVGhlIGNyb3NzIHByb2R1Y3QsCmluZGljYXRlZCBieSBhbiBg
YCRcdGltZXMkJycsIGlzIGFub3RoZXIgdmVjdG9yIHBlcnBlbmRpY3VsYXIg
dG8gdGhlCnBsYW5lIGZvcm1lZCBieSB0aGUgdmVjdG9ycyBvZiB0aGUgcHJv
ZHVjdCBhbmQgaXMgZGVmaW5lZCBieQoKJCR7XGJmIGF9IFx0aW1lcyB7XGJm
IGJ9ID0gKHthX3l9e2Jfen0gLSB7YV96fXtiX3l9KXtcYmYgaX0gKwogICAg
ICAgICAgICAgICAgICAgICAgICAgKHthX3p9e2JfeH0gLSB7YV94fXtiX3p9
KXtcYmYgan0gKwogICAgICAgICAgICAgICAgICAgICAgICAgKHthX3h9e2Jf
eX0gLSB7YV95fXtiX3h9KXtcYmYga31cZXFubygxLjYpJCQKClxub2luZGVu
dApUaGlzIGRlZmluaXRpb24gaXMgZWFzaWx5IHJlbWVtYmVyZWQgYXMgdGhl
IGV4cGFuc2lvbiBvZiB0aGUKZGV0ZXJtaW5hbnQKCiQke1xiZiBhfSBcdGlt
ZXMge1xiZiBifSA9IAogIFxsZWZ0fFxtYXRyaXh7e1xiZiBpfSZ7XGJmIGp9
JntcYmYga31cY3IKICAgICAgICAgICAgICAgICB7YV94fSZ7YV95fSZ7YV96
fVxjcgogICAgICAgICAgICAgICAgIHtiX3h9JntiX3l9JntiX3p9XGNyfVxy
aWdodHxcZXFubygxLjcpJCQKClxzZWN0aW9ue1BsYW5lc30KQSBwbGFuZSBp
cyByZXByZXNlbnRlZCBhcyBhIHJvdyBtYXRyaXgKCiQkXGJpZ3A9W2EsYixj
LGRdXGVxbm8oMS44KSQkCgpcbm9pbmRlbnQKc3VjaCB0aGF0IGlmIGEgcG9p
bnQge1xiZiB2fSBsaWVzIGluIGEgcGxhbmUgJFxiaWdwJCB0aGUgbWF0cml4
CnByb2R1Y3QKCiQkXGJpZ3B7XGJmIHZ9ID0gMFxlcW5vKDEuOSkkJAoKXG5v
aW5kZW50Cm9yIGluIGV4cGFuZGVkIGZvcm0KCiQkeGEgKyB5YiArIHpjICsg
d2QgPSAwXGVxbm8oMS4xMCkkJAoKXG5vaW5kZW50CklmIHdlIGRlZmluZSBh
IGNvbnN0YW50CgokJG0gPSArXHNxcnR7YV4yICsgYl4yICsgY14yfVxlcW5v
KDEuMTEpJCQKClxub2luZGVudAphbmQgZGl2aWRlIEVxdWF0aW9uIDEuMTAg
YnkgJHdtJCB3ZSBvYnRhaW4KCiQke3hcb3ZlciB3fXthXG92ZXIgbX0gKyB7
eVxvdmVyIHd9e2Jcb3ZlciBtfSArIHt6XG92ZXIgd317Y1xvdmVyIG19IAog
ICA9IC17ZFxvdmVyIG19XGVxbm8oMS4xMikkJAoKXG5vaW5kZW50ClRoZSBs
ZWZ0IGhhbmQgc2lkZSBvZiBFcXVhdGlvbiAxLjEyIGlzIHRoZSB2ZWN0b3Ig
ZG90IHByb2R1Y3Qgb2YgdHdvCnZlY3RvcnMgJCh4L3cpe1xiZiBpfSArICh5
L3cpe1xiZiBqfSArICh6L3cpe1xiZiBrfSQgYW5kIAokKGEvbSl7XGJmIGl9
ICsgKGIvbSl7XGJmIGp9ICsgKGMvbSl7XGJmIGt9JCBhbmQgcmVwcmVzZW50
cyB0aGUKZGlyZWN0ZWQgZGlzdGFuY2Ugb2YgdGhlIHBvaW50IAokKHgvdyl7
XGJmIGl9ICsgKHkvdyl7XGJmIGp9ICsgKHovdyl7XGJmIGt9JCBhbG9uZyB0
aGUgdmVjdG9yXFwKJChhL20pe1xiZiBpfSArIChiL20pe1xiZiBqfSArIChj
L20pe1xiZiBrfSQuIFRoZSB2ZWN0b3IKJChhL20pe1xiZiBpfSArIChiL20p
e1xiZiBqfSArIChjL20pe1xiZiBrfSQgY2FuIGJlIGludGVycHJldGVkIGFz
IHRoZQpvdXR3YXJkIHBvaW50aW5nIG5vcm1hbCBvZiBhIHBsYW5lIHNpdHVh
dGVkIGEgZGlzdGFuY2UgJC1kL20kIGZyb20gdGhlCm9yaWdpbiBpbiB0aGUg
ZGlyZWN0aW9uIG9mIHRoZSBub3JtYWwuIFRodXMgYSBwbGFuZSAkXGJpZ3Ak
IHBhcmFsbGVsCnRvIHRoZSAkeCQsJHkkIHBsYW5lLCBvbmUgdW5pdCBhbG9u
ZyB0aGUgJHokIGF4aXMsIGlzIHJlcHJlc2VudGVkIGFzCgokJHtccm0ge1wg
XCBcIFwgXCBcIFwgXCBcIH19IFxiaWdwID0gWzAsMCwxLC0xXVxlcW5vKDEu
MTMpJCQKJCR7XHJtIHtvclwgIGFzXCBcIFwgfX0gXGJpZ3AgPSBbMCwwLDIs
LTJdXGVxbm8oMS4xNCkkJAokJHtccm0ge1wgXCBcIFwgXCBvclwgIGFzXCBc
IFwgfX0gXGJpZ3AgPSBbMCwwLC0xMDAsMTAwXVxlcW5vKDEuMTUpJCQKClxu
b2luZGVudApBIHBvaW50ICR7XGJmIHZ9ID0gWzEwLDIwLDEsMV0kIHNob3Vs
ZCBsaWUgaW4gdGhpcyBwbGFuZQoKJCRbMCwwLC0xMDAsMTAwXVxsZWZ0W1xt
YXRyaXh7MTBcY3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjBc
Y3IKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDFcY3IKICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIDFcY3J9CiAgICAgICAgICAgICAg
ICBccmlnaHRdCiAgICAgPSAwXGVxbm8oMS4xNikkJAoKXG5vaW5kZW50Cm9y
CgokJFswLDAsMSwtMV1cbGVmdFtcbWF0cml4eyAtNVxjcgogICAgICAgICAg
ICAgICAgICAgICAgICAgIC0xMFxjcgogICAgICAgICAgICAgICAgICAgICAg
ICAgIC0uNVxjcgogICAgICAgICAgICAgICAgICAgICAgICAgIC0uNVxjcn0K
ICAgICAgICAgICAgIFxyaWdodF0KICAgICA9IDBcZXFubygxLjE3KSQkCgpc
bm9pbmRlbnQKVGhlIHBvaW50ICR7XGJmIHZ9ID0gWzAsMCwyLDFdJCBsaWVz
IGFib3ZlIHRoZSBwbGFuZQoKJCRbMCwwLDIsLTJdXGxlZnRbXG1hdHJpeHsw
XGNyCiAgICAgICAgICAgICAgICAgICAgICAgICAgMFxjcgogICAgICAgICAg
ICAgICAgICAgICAgICAgIDJcY3IKICAgICAgICAgICAgICAgICAgICAgICAg
ICAxXGNyfQogICAgICAgICAgICAgXHJpZ2h0XQogICAgID0gMlxlcW5vKDEu
MTgpJCQKCmFuZCAkXGJpZ3B7XGJmIHZ9JCBpcyBpbmRlZWQgcG9zaXRpdmUs
IGluZGljYXRpbmcgdGhhdCB0aGUgcG9pbnQgaXMKb3V0c2lkZSB0aGUgcGxh
bmUgaW4gdGhlIGRpcmVjdGlvbiBvZiB0aGUgb3V0d2FyZCBwb2ludGluZyBu
b3JtYWwuIEEKcG9pbnQgJHtcYmYgdn0gPSBbMCwwLDAsMV0kIGxpZXMgYmVs
b3cgdGhlIHBsYW5lCgokJFswLDAsMSwtMV1cbGVmdFtcbWF0cml4ezBcY3IK
ICAgICAgICAgICAgICAgICAgICAgICAgICAwXGNyCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgMFxjcgogICAgICAgICAgICAgICAgICAgICAgICAgIDFc
Y3J9CiAgICAgICAgICAgICBccmlnaHRdCiAgICAgPSAtMVxlcW5vKDEuMTkp
JCQKClxub2luZGVudApUaGUgcGxhbmUgJFswLDAsMCwwXSQgaXMgdW5kZWZp
bmVkLgoKXGVuZHtkb2N1bWVudH0K

--0-902339947-1131768683=:93603

JVBERi0xLjQKNSAwIG9iago8PCAvUyAvR29UbyAvRCAoc2VjdGlvbi4xKSA+
PgplbmRvYmoKOCAwIG9iagooSG9tb2dlbmVvdXMgVHJhbnNmb3JtYXRpb25z
KQplbmRvYmoKOSAwIG9iago8PCAvUyAvR29UbyAvRCAoc2VjdGlvbi4yKSA+
PgplbmRvYmoKMTIgMCBvYmoKKE5vdGF0aW9uKQplbmRvYmoKMTMgMCBvYmoK
PDwgL1MgL0dvVG8gL0QgKHNlY3Rpb24uMykgPj4KZW5kb2JqCjE2IDAgb2Jq
CihWZWN0b3JzKQplbmRvYmoKMTcgMCBvYmoKPDwgL1MgL0dvVG8gL0QgKHNl
Y3Rpb24uNCkgPj4KZW5kb2JqCjIwIDAgb2JqCihQbGFuZXMpCmVuZG9iagoy
MSAwIG9iago8PCAvUyAvR29UbyAvRCBbMjIgMCBSICAvRml0SCBdID4+CmVu
ZG9iagoyNCAwIG9iaiA8PAovTGVuZ3RoIDQ2ODAgICAgICAKL0ZpbHRlciAv
RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja7V1bc+PIdX7Xr+BLqsiqJYK+N/K2
ttfO+sFee1W+ZKwkWAqSGFOklqR2dv59zqUBgiJGu8l8qVI5U1M1ArsPPpw+
tz59QcPMavpnZsa5KsXsZ7Gxlal9nK0er+rZPVX+5soUIueJyBj+OVG7dK6p
csputsy+ck02SsV1+/tC9McRvXGpirWxs2WsU5XqGPiGX1xf/fOv86ypmmjj
7PpuNpANVNe37+Z/WmQ371aLpZkfF2a+2x8WN9e/vfrqesA3salSjmY2Rr9g
eqC6ZMLWZ1z0AjKmcnWThIv7u+524eu6nv9n+91q4SJd/ce/3/zNOL9wln78
5a//9o4Ze9mkUPkm55nNVfDRCda331M7ntt997IhNsbKJKKOvqlCcMzg91fv
burZLbXnt1d1ZZrGzt6zrKu6aeLssS8rvzdX3179YcArdctSeYFGqgsFTQgf
r4hda3L/+xxtqJsG+5+xtiS0YGImvfgqett8nLuCcgKkO4J37pK9bEJSk/0k
JOYtGbaUurKsvH9kNZADW+OYuZxi6h2ZHhINeYihe0OY7bvZ3Sg4VN4OoaHu
aUiWydoXtEtXmyo2pJZlZL9yGm8uXN+SS0ZiI1pXWW+i+MkvOnb6LTnL7YWn
1KQ5S2CMWvvmk13FVi728e6TcUAwbw3nc7P+Hzbr02GW1Pc5ZykEEKDJ6ZPD
KQMZijn/uED+k1WXKdZSJpUrn1LzWeL/9xJf9iIHWfnnUPm5WZ+bNYFTN4Au
KRJSHXhUSINCH39WUl7KJpNyGijELFl0HbNFoFHUFrQAAYsKZhoImhe0kCFo
URsaQoKgJUWzGDRVqW8gBqJKAFlb0IZ6h0FTlfoaYm5BwFyCgPmsaB6iUa8N
dQYiNi9zBLXNEN6cttSGDEFTc7MW4qVOW0q1CDSrPm+SgaBpS413EDT1eWM8
BE3A6gwxN6M+X2MMxKgr1BgDMWogBIdAq2WCi1wBAhYFLEDMo5aUos4Qy2Uo
UyOCR2iSgLkAAfMCFg0EzAhYRhhtyGIYFuKcIYsCrIc0k9I/BosQbWorG4TF
hiSW4SC5X0hBwDxE/kl8yUEkRmkkYzUQ+48iMp7lRoCJM3mP4UycyUM6zhBE
Zh4jsyDOFDBmFkRmAWNmQWQWIiQAeXHNgHFNLzKLkGSUhcVgEJF5ERmPfwBg
TkQWIUlycCIyjP07kVhymFaKyFKA6NKKZ05O3f4vwERkGZKZBSsyyxZiZlY6
gOwhMjMisxwhMjPSA2QMlvSZjYHI30ia0TiI/MVkefEWgKUpe5MgXl6ryBpI
yK7ZZE2N6ZlqWc+nRAMA5ptGwCIEKwkWZGDCKQHVkcwgYE7ArIWAifwNJGf3
MpowmHGOz6IAg1FAFpuFSCxbgcJgCRTG+JMYP2a2y6coYJDo45MKHzLr65NY
v4OMWL2YmIMkLD6KMl2A2GtUziCdr49S5yAJI2+6ozrMzLaX4ZfxGGeS4ZeB
jHF8EPl7yCKKl6GcYTdAgKn8G4iZBYllnGsgwAQLMsfovegyYLoldXPMipgv
zcQo04syMSt/3osyI8YzJWRHjGPKgNVEyNKad6LMGDCcSV2ETDJ6pzLLGM5U
mQ2GM65KBuJMMpQ2yUKUacUyEsbNZVxuEmT45WVcbhJkkstbVUCG5BkyyDcJ
YxmClWtI/JEJA4OZyvAyYWAyZDKbN0AzmMc0UywjQ+byejDI0r43qk3IypDX
ffY4JAORV627+DFJhixkmgbTL9Vah7GxAoZhTIJPkyDdkizXmgYTyeryLgci
YDiZ+7E1JPuhSgGDLCQ4mUmytcWARQGDxEUn01K29hkIFjCcOQGLGM6sgCUM
Z/KnzhgwwYJ05S4LGGb208nkmzUmAMEgiYGTTQbWQOZsnNRZ4y0QDCMyp1gN
BEzs38QEBEuYZsofkzHKFCzIxIhL6kyQBROXhDOL8cwCBkmnnOxlsZBRvpMp
Y8KCWJnsi7EWsizXg2GwvGJhWileboMDgmGMzCoWxMmT/LHJIMESEAwyY+Nk
x5TF7F126peQXTEuasTAxDIFc7VDgn2yyIwjGDJ9+msg8pf1FwRneJmpmWFy
xh7M4Ww2ZyCWfashAxTMHDLMWmD89/iOyac315dDkwxo+oPMy6AJIzSVRSbZ
yOwfOyyBDpigQznoIBM5+oUOy6ETBtCpjIycZEFO/yDnpRrkfBl0Jq/MMWLA
vM5+IqdSMT0mdsa4zGUn4JQ9aJYdOP8PXZkAr5lAV3Nk9bEJDXA1zSPBMMu/
/aIhRpsNcDnTAFdZoYu/DrksDV0why7lZ+QmAwWzDrcvwyD3i8S3t5Ol7LFp
kLt//Nvbl4TcMVW2cr3BPWbQ3W/QfXnQHYPIvYxlk6V5e7s/dV9qg9ww65Bb
eSG9nL5+AdpkLC9/obY/F7Aas/3c645x+/b2skN32QO3/0PfS8C+MQF9lyMi
3zJpgO+/IF/MkYlx2BtDAfkuE/Qtqwx8/0tmQFFvpkHfmAO+yAd9wRD56iP0
pUyZM4O9Lgp9kRX6ii3u3d+gMzY15J1wnbBBvS0dke9xlzfM41t79R37Tj70
tIByjIFBHrCQ39zRD9hDKaDHZSAP8oAeMYI9/AR5KgvyuJj+IBv/5k7YgR79
Uw4lsm/uuCTsQU56xJR9c2df9adyIY8Li8iDzJAnrMW3dvQb9kw65Gl5yGP8
sOcLQk8+RJ7JCD0tEnuOJfSEzQZ39meUlL2GHIoQ9eQl1GGp5RhXzOm3FnnC
LPj0W+jJvNBDg8HnGWPPWoaeA+0s8oxqF6DnZ0PP9saeO+4D9Ez0VM5rxxxM
b8pZ8hg0Bz3mHnoEP/TrANFDP1wQkR9VSMjvPSRXvkWR3953MnL5goeBfl0E
g6YNTZhOIWsYT5AMPDba0gRZZYiNthRzZIiaboakzanWdmbI1rhUazsbyIRy
0qjbuAwB02DUQHr5ZKShpobMdidrFA0yEk2aa2Gy+mQlfhjMtH7SD3gYg2mo
84qGUakmR8ZCuuXkraJB1gKTJkfGQraDJC+R0jjIWC0FbamDzO/wtLKgQeKu
9qTGQ87wSprOGO8xrCVFg2z9ShorTTAQlSY1twAZf6ekjoU5ry9lNbf46css
S/KEiuRP7MmnrsuWPvksMA2lR98FJjpevWKqyOrn7wL/k35n24w/IMy4ozp+
tdZXNAaxXLkkO+T1fLLJ3FS8WZhJzWJpjA3zf93xZ4Yf5f/7bisfHd49HxZL
l8L8etG4+b7dHu52eyFrj2sh2B4uv/bNH5M0VbaUa/ADrh8Iy3s7P8jHy5/5
Q8YfuIRuv9Oa/e67BQljvjvq78d2uyayJ6bd0KN2W6VfH/ivm69225UwuCeC
bXerd71fHx+U7tg/ct/x7Qth9GH9pLX8rDzvjgv6//2CHtuVLyxTS5h5Y6om
UFBh5pmxEOb/dfryurTiCxKLcfN2S4+mKDZX9julUdisP7stUzQDECFI+ep4
0IoBgxv9xJ9E39B/7XG3P1TEr4vzr5U7IaIWqhj41hUzzwXt07Hba1n/ZLle
bzZ62233w8DRZvd03lIjLRVkvjFHEtvTvjsUqdB9x5ZbLmpwOZDEVfoHkUXL
SvigN8qn6fXytm/pYdVraj2ISWgf5BH6vKLlIl5p5BO3nz8w/y0r8JHL1yKa
vXLxxFZDzemk6jCpPbYvZ6Q9AzujZomg1bqI6qHlwl5Q3tl5u9l3rRirM2Md
d+UOYXbHTJ3Ee6tV60LSi5Xh/lYb320KQc+bSGf3KLZ+LEYtFff7ls3hgVsv
RIcvptr4/qHbixhrNXu+mJan1v2EqRLFtKlm1gGRPh+OStZuDrsTpBod/bjt
5JGrfa/tW1JjyJ4CjChqx8GFA8uUDVKI6Xm+Y1PaP47aYcnzW24rXzwfemlb
8nOWNv8d3INJBnFzjbjZmLSXO3uceA/f8kO5nf6XoKGl737FRLftjd757o9i
eELW7Y+H6G6mFCNkg6zZ/o5ySww3dC2+7Tk4Kg77KfHPZBpmxy3nKo1U+0Io
mML8Zsda+TC2P1eztUqpXP9q+IK8Wvj6WJ5WvJUuT1pbmJE+qWbDJdu/L6ea
2N7zbb6JJKJu24PfcFGYt/rJer1mvvliu1Obk5ueBykWsuNO/05zwzViQoK8
7nsHCpRa9+6bdW+yT+eCv+kJ+OGtBNhkb6YssCdh6JRYzTeV0FE/2vBXE8fN
//OCzJoZM32s9SaL2dF9e/YTrukOx/Y7kWLxRaHiJuyOffShArV3vdZool3O
bq93MpQYsTdp/rQRGWhA03tKnUa1h66grjXQ7VXTdHn73IeTTtq1nGrY637o
6yiu4Ws/hDcyRo7WIVOqUALOEG19HT6KeNBq6tAPaxFYzYGd1fvY7tebD/oU
iZX8NE5BNu1yMnYUSZpeElZU38tYPC5SEDspzQ1Ks2Oh2VPMHIyVaKWl7bGQ
a98l5a/LiihWbcHViMlXvU1P+JSI4pYcneNVJNfhaBYjlcs9uz13rGtxZu4u
uOpOooa4RleoxWkV4P3DesXteNCf7GP896KP1+LJ4C8JD2W+9NzVRhI4YeC+
ID50eqHOORkpzvK53b7SADC2FRdMsVa1/v0QF6niMi5Scd0nOEG6vq2SnnKM
AXDa/G8LE18qKfElOVRgo1XX4+dMWBpFJ01pRtFJVF1EwRf3Q8gdglC70ar9
uecXq74TP1cJDslWT15iGicyh9JTc7N6JTBZW6h346SGy0tmLelFTzqhoIuQ
w9KJaf4li9Uz9/dSTDn2o5ZIFurNKAQI6UQG0HdLVMfWxzeVILntiyVz8QXn
e+5u1z8sQqTHdr11Chc/ljjqpEtfFNzSJdxvOq2heDHRxP1uyGPZS5Kdzgub
koax/6VTR8rX7Xb4Yef367O8b6skHwsHLE7r2Nj4Xu5Y9uvuTn8diqeJ0hik
/6sjpoHFo/pxUfuEZQ6RTw203UiouC8x64WZlei0PgUq8e4hby9QR0rYSD17
/VXGWBzM9J4z3rm8/1tcwb3siw8v+me6tQhxQmWvBFcWKKWb12o5ca6ykZR5
SKOdl66lxKzuoJTaBq5r9c9ZG7hA/77mmUzVff88HezGqXc1NRInemep2w1Z
6G0Zgv9OBt9spJyA7oZB6avD66+3akTnOdMQn5MbHJSvPzYyUKN8bWTAFC9G
wwfF7OnkWiIy0z62fx+VS7rOF7ti80/am2k/VbofKj7504oTu8kRz5OMArdd
3zH5YSTepJfdpGiMLaShDGvfPnZFKcvo0lxyvTMWGOEFC3qvJLB8cXsKdhzG
u1st/o7jxge93mjmkEYC3BfmWg3fhWntO3Y0RJlo5V27kgw8lGG+DLNbFXxX
5gbC/JuTLBylZcpmzRn0tjBHPwbm6Lo3kiftD074MrJuV8dzR5WJjrqfpPBl
1FREPCQCkonw89lHWcoTI3KNUMOwxDlJ/5/OooMUj4TEP3shlVhPJUUyzr/K
OQuIXPjXi+wkr+Y7ux/bR7EeIf0XYdDWVWN5NYXYpPGOme4NyzSXHc/K5aYK
gV/GLbdceGrkhexc6r+YQCCCnHuAH80lAvGUEn865nWInuDHSwRqFrNp8rke
Tj6kk4j+o+365hIzVUlenBkzdYZwxtQfppiqXeUaXvo7T31f+G5XFK6O+1Ma
+PryQRxyff654vvyEiBXkZfBfybAL39PjP/uT1MNJjNL/GbQ0sSK93aPx4+c
AZVU1jWjUbH+noiUXHwRKQXmbGD4xSg3utW7pkXcvBxCMBS7oT6I87D9mgax
oyEn17wfepDiiB8dUJ5PrdkU5+rkB2VntW4lWHFFSfueh2dJ5hROjmxT0Bp2
ZpkA7AcoOXGPziAaVXbrU9cSXghM6SR2HApHpWWXTNiUJE3SDi9ph7rvSs0v
JTJr9JkcmR7WPACU0NZHz8QaEI0WDVAs47ko0c321MWUScpTJjE5D/H1HUfp
0dyvZXs6PGippNz09/UJWbqlVbqXsuMynjRzJvfJW98RSYy2djzEvORD7JpK
Vy1dqQONXcMGSmZS3fvY06XzBHKYkRPrEzWHI5bKkOgsoxwaLgZJeQWFgSa9
mLvisV6adggqHzvEVOQJVcPnDClTX03FyMCLpSemwykfcCGzXNh2tUKyIy4t
TL3ofqgsFhknkTH/XPSj3DQMg9NYxmNuTUoVhTH/E11VKvU8YUvjxD+zx108
4r0kmEcRytVX16OzXF2VYvYclF3UbxPUs3uq+81pwWsgWo6oZL1rzIyj3kHe
Iu6JdJ3qxQM9NcqnJkw98L8Bzyk992VuZHN0cmVhbQplbmRvYmoKMjIgMCBv
YmogPDwKL1R5cGUgL1BhZ2UKL0NvbnRlbnRzIDI0IDAgUgovUmVzb3VyY2Vz
IDIzIDAgUgovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50IDUyIDAg
UgovQW5ub3RzIFsgMjcgMCBSIF0KPj4gZW5kb2JqCjI3IDAgb2JqIDw8Ci9U
eXBlIC9Bbm5vdAovQm9yZGVyWzAgMCAwXS9IL0kvQ1sxIDAgMF0KL1JlY3Qg
WzEzNi42MDQ5IDYwNi43MTAyIDE3MC43ODI0IDYxNS41MTA2XQovU3VidHlw
ZSAvTGluawovQSA8PCAvUyAvR29UbyAvRCAoVmVjdG9ycykgPj4KPj4gZW5k
b2JqCjI1IDAgb2JqIDw8Ci9EIFsyMiAwIFIgL1hZWiAxMzMuNzY4NCA2OTIu
MTA0NiBudWxsXQo+PiBlbmRvYmoKMjYgMCBvYmogPDwKL0QgWzIyIDAgUiAv
WFlaIDEzMy43Njg0IDY2Ny4xOTggbnVsbF0KPj4gZW5kb2JqCjYgMCBvYmog
PDwKL0QgWzIyIDAgUiAvWFlaIDEzMy43Njg0IDU3MS4xOTA3IG51bGxdCj4+
IGVuZG9iagoxMCAwIG9iaiA8PAovRCBbMjIgMCBSIC9YWVogMTMzLjc2ODQg
Mjk2LjI0OTYgbnVsbF0KPj4gZW5kb2JqCjIzIDAgb2JqIDw8Ci9Gb250IDw8
IC9GOCAzMCAwIFIgL0YyMCAzMyAwIFIgL0YxNyAzNiAwIFIgL0YxOCAzOSAw
IFIgL0YyNiA0MiAwIFIgL0YyNyA0NSAwIFIgL0YxNCA0OCAwIFIgL0YyOCA1
MSAwIFIgPj4KL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0KPj4gZW5kb2JqCjU2
IDAgb2JqIDw8Ci9MZW5ndGggMjQ2MiAgICAgIAovRmlsdGVyIC9GbGF0ZURl
Y29kZQo+PgpzdHJlYW0KeNrNWUtz47gRvs+v0FGqWFi8QRxy8NbOZJPDXtaV
HLI50BJtcUsWFZEa2/n16UYDICnBHs8eUilXWSDQRDf68XU3KBYc/sRCKMWc
rfTCeskE13axefrEF4+w+JdPIhIpDURC4GNhda2dY9p5s1hPN/nx7tMPX6qF
Z95Ku7h7mLAyjkll1OJu+8/lsFuJZduv1krpZd2v/nX3tx++CL6wzDtVhfes
YapyerEWnjlvq/DeZ6KUbsLBMqe4AoGYEMoEsq9ENpVjLRxIKZzDEfNK0oZ3
u4aE2INAMBTLeouiHR5xWi3783G1lo6WTrDS42Bzao8wHujVbXq1h/n7kTwe
b4DlxCWT/saFhvGhPcD/R1rcdPButeyQzTYs1EN87wHn6id8s2F4uIXQzGvl
4TSCeWNEOM0/VpXG/aWTy6f2cbeC7QZ8hJf3fUej57bf0WiIM9um34TztcDl
PgjRRIpdS2fGHfsoAC2RXjqQE5ncRMNMVS65ZZU0DvwFhTteG8Uwo3QV12+Q
sVo+Iw/kOkQpT1m9RxItyBqOxfMR6niSFhSrsrHCAAT0QI5KW0vpmOJaJ7XJ
wDkrnkwfta5A6/VTcxMtAEtgmTAftn3JFkFX2DcFzxRKMy6Njgf8+VoBFYys
HhWAu5/7qVPUNPl1RUYB3xtAjGtejjPljIhbPV+zggMbD+FHBMWYW1sBgSzc
POZ+LnFjxoDc05h7Jg0LJ5gW1s/DrBCQwCF5Rn3YlrSHFFq+eyLvx01OaDWH
8QaqesZ/HU3MddfT5HPw7M0KfHiHM2p5PHX3aNN7hIJXokKYqpEm7YGTwUvQ
z0I0nJpDDDNc23RP5KXd4cL/oijGQiiemyhF+eRrDbbS4iK4ow6FnqqAM+FU
0pG91hGPS38uKVgAvtv3XEYCwgOuE0Ez6vGwWmtuIEK7M3rqjh4JObqAdzhj
o9ZivGL89DS/bRKMTgEHV0JiiONAAxFIT1Gt+EZUeAFxpGXSOvFBxGGrtbWC
cgCy2NR9BDh8GgGUoMNaBkmpmkMHwSoGavPS9gMFa/dAvx+NXa+YkCpJXZdg
ovI8WXmO1gWsmCMzzSn6aQ8bnNw1KfVGm+FkdnGcD077OoHBAlxgfeCrao4W
X4jQLiA/VUJRghbSLBTj3BJUiIIONGR7RBQHxFM1zDhKw7TXuHeGnY/wk9/B
b14zQGWjpLdzMPsruL+yHpNjCGM+cRx8Sj6M4wL2cICqRECZbhshpN3Ue6JA
IDoPxGYMllxbIMkW3yyiEL/0gFi1gLsbo0BjkGVzdvw3coov71+xfgipHHxt
Bj7pTLKSIBBWL4dUJslKzOoTmslpfL+nibGugAdAWvS4NuBHT9uGPbonehh2
kXLIyXaglRoZb+Niogrnw71iiXCKIYIyHof+IyLtA6OHwGimAHKPDlUNGtS+
IgcwfBnOO4aKwXyCM30u/4wYvcHI5SGgGc4GiLhYnaJlKDWAxUxmfGH0ASNn
b/dxb4m5Pe4dmR3yErHlYal0yHt0keXvucQKjvZGeYvzWLI4v3wI4gJt81I/
HfdNnCYBMCKgXA6+HPhjBEQ/bWMoPaVj5pqVomCdsi4v5oxtooOH19nOV5mn
AAGXLt5SMXedBqFmlFBqxzzZYmGKuPhmYYqLQzfLARMMnedgbhjU1nHvH29/
/XzNn6rIdws3Bc1AbpU87YW+urz9NVi01DdJgECj543TmzoAAHSMK8DKCIWO
oBDtyd2yHej3OcNdgjhepWDHWOzOPRHmYEeC7MY4bl7iXsOuvtgV14scJi6a
w37MjGGvhgYXuZi2J4tCyj+N5nSJqhQnYNyCKaG/dNZ+3JTp2KGeQid5nmTg
SfsW+tAUIGPHEbPz86kdip4lKmYNMFtL8A7B1bcMrD2SiYtcBwaW0qBoQSM4
hpoHN+niShuesFmTmvoxacsWSWpFAkqeuEEq7FKdjKtkElydB9loFdokylAf
qOpsTjT/RieNS7NMRR2LjsEzwYI+FP1jOrxuTaZ93e0vPxVMjfcXYtLaieCG
aGoxujGOn5DXOWXpgUjPfVzFs2VHOdHiVabAvTuif1fzSBDLFhhl3e7rAX2r
O/S7cLGB4kqRet6gJaMZFMUXjTPC/WUHPL/FMZJVxpnLjnLt7PL2F3gVwu+n
EjYB5Crt5tj0tYR8ooIWyEsZ7Ah60N/FwSJ0WmH0jMMM/GFXKdU3O1UItxTW
7+QRa1UiI5t0AXqsK1Z5dgKNMB77IXx6yBdWA/rOKU6PlSM0tvWsrofVN4tG
i05lMLZDPZjrRe2w2gke4MDpFeLJNFDoziT7pqFLJSw1snM9vEEQOrkg0NcW
NznX+0kR9VYf3U8LGXl5dZPvzIyMKRcDAd3Z2Ou+CHhd1OeRMjr9BeofUTf1
gZSDlJ5nXFQVp5vDLZU+uSC9v6xEQ2HU0RukAlyiwjGInguniofAqk/QGJwD
7xMtv6sgtBqUyaHK7+IL8zi9Kaa05GhKFxvWeecHtYBT2GPl2PmOmP5WxEG6
qmQqiXahmoU8Nzk0GPEQXbdUDTkJDKz7I9KV8UD6KaRxiGKBQIi9KBG+lC4a
pPF6MSG6KYhqGa8q9T+U9LUkqaqU+r+T9D/XkmpmhJ3plMXNbMBpbSVVwxza
dqgLYSQhtxsqiBHzBBQLf195nb07xGZfujdbS8Eqyf3kM4FQ4UKwC7HUPTaH
hupZmH/r7h6WTs1xLGJSoFJbDmm3CwVBBDT8nbdgcXu69SKriKmGjWCQAVNv
cihZ1zuf1td9QoF6ky4s4u6RUR3F+Y0bXuBnIPB19Q47x5xLGe5PK8zOSwF7
iTXlEKgqILjDR5gJ9vTHehPqc76c66cdUmcHS/2Z7q5A0d7H7gBHNf0cAScz
kiLy7hEuw8rkC868imxzbuSEtScwI+D/78leGzIQ7pJtuDk19ZA7fHgxfuC5
1ha4IDilUH/UOiwqLdQgofWaZN47KuNsunQ40ENI4Kk+x4lJOSEh0zaUsbaR
uqf5scyQkMZCRoquaTm5ph1ZjDcyp3oiQUfIfAopPX5Ewa2jHE2dL9utuKxg
xbKYlGpKspRCa7yhwceHGtPSDd7SqjHR5t19tEjoHv3kOs6LwrVAIKEkc0E7
fu7CFSol6nzrhXN40AcaTk4HT29+BSieMsBFkGl/DvCB+ovfH4f05bDf0Pnx
U1Q6f7jRjekxNxH7IZTw+zbYGFby7Ui6jcCvFId+qCnM3vmceDveJ89v3t+4
1v70+S5/H87ffSvPlNW++A05E60nVFefkBVXDChV3irf6U4Z5u/RBYb/BfXS
ZPdlbmRzdHJlYW0KZW5kb2JqCjU1IDAgb2JqIDw8Ci9UeXBlIC9QYWdlCi9D
b250ZW50cyA1NiAwIFIKL1Jlc291cmNlcyA1NCAwIFIKL01lZGlhQm94IFsw
IDAgNjEyIDc5Ml0KL1BhcmVudCA1MiAwIFIKPj4gZW5kb2JqCjU3IDAgb2Jq
IDw8Ci9EIFs1NSAwIFIgL1hZWiAxMzMuNzY4NCA2OTIuMTA0NiBudWxsXQo+
PiBlbmRvYmoKNTMgMCBvYmogPDwKL0QgWzU1IDAgUiAvWFlaIDEzMy43Njg0
IDIzNS45NTQxIG51bGxdCj4+IGVuZG9iagoxNCAwIG9iaiA8PAovRCBbNTUg
MCBSIC9YWVogMTMzLjc2ODQgMjIwLjk0MSBudWxsXQo+PiBlbmRvYmoKNTQg
MCBvYmogPDwKL0ZvbnQgPDwgL0Y4IDMwIDAgUiAvRjEwIDYwIDAgUiAvRjI3
IDQ1IDAgUiAvRjI4IDUxIDAgUiAvRjE0IDQ4IDAgUiAvRjYgNjMgMCBSIC9G
MjkgNjYgMCBSIC9GMjYgNDIgMCBSIC9GMTEgNjkgMCBSID4+Ci9Qcm9jU2V0
IFsgL1BERiAvVGV4dCBdCj4+IGVuZG9iago3MiAwIG9iaiA8PAovTGVuZ3Ro
IDI1MjggICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja
zVpZb+NGEn6fXyHkScIOO30fWezLApsAeTZ2Hzx5oCWNrR1bNChpfPz6VPVB
s+mmKduKJxhgTLGL1dV1fHWQbEbhH5sxIYjRVs6044RRqWfLm090dgmLv31i
kUhIIGIMfxZWK2kMkcapWdVn8u+zTz//ys3MEae5np19nXFDiWSMz7RUhFvK
Z2er8/n3xR9nv//8q+0RWuKM4MAc1/8V1mH3JwJGiWKaRYo6UGR7wQa6I9g8
30IR4bSM6/8obBGvAsFFYQdJuFGJ4P+lHQyT+tgdlsUdBGNJxm/Pd2CcE86o
jRRfqKKssI8lVikTiX55zoaDA5i0DQMunsmsEkLik3JWMUOc4NYT3F2t23VB
WG6J5oqPa1wQZrmK65+LJnOSqXGFCqJod9jPi0owO6+3q5IsijDu3LjmHMgi
k6w1nAeYqflhu2DzzT78+L7gdr5eLio23zctLOzwvp7X13DdbC8D1f4Kfq1L
HsrQeiYd577kH9oJl+sjY5Hp46HEgHdnGKojY5Sr47EUb5za5CHLZlHB0Zt2
hdrY1vuonfp+vUNtxK3a8OsWiE3UUxX8hktKqDMa/IYRpxTzbPeboNHrh4WV
nokQ8w0qVUhgdtt6RQKXnf9/u+BuvveXq0i7wLv+8qq5aS4jWXyqOUQTATcv
TOMFg1P45+AUcbFOfwOrQIs2PdxE7jf1vt3cF9yKSUeUYw5CwxKh9OvwqwBf
XBDKwAeQjHvlUR9sSkjpb+p0UxNhdFCkLEjmiHSARQxCnTv55HGzCkxhXGcK
/uRLM5ABUCFbeAzPMKINBFpmvrviKShsBtZ2UmtPJUqHMIVDqAKaCUBMJcFN
iXWR30kgjZcgTWB4AouXII0pDjFqBbi0IA7yWj/b5PYWQpvc3jmnLF/dF06k
CaTNl1hI4myXDO7icSi4oeUJoE0/Vw3gTnBxtHwPRfk4VfZV8g3MC34CeGhO
maxEsuxAlopZRqRkeeZaPudmYDd3vGIeiyhNHZ/SixjXi5fVasFyK55dIVoe
AKy4kpBm1uEiYChi1hKzkr8nCrsa2JZ3eipmY8tcV5xUWhZxhQkitH4hJ0vw
LCMyPmqSz7dSBCljkzzLehtOduEzUTx6MUfY+T7dWwWyOqrsXBTrRsC27tz/
LJ1HcpPcXBY4ZG4+xUCNMRBHMmB/BAID8QcpxQafNRKStYCDqIBIZyV9GgZ2
qXpUyV06BemCdIAomnZVy5R49t3no2N1sTmSA3+XhuRQQ09ZgptBcqwv642v
EGysIdz8PEov+9L57Mk7mKO0BDsgYDqBOFYH+TZ9JbywS+IhP2QX9SG7MFow
OoPMICibsLqGwh/s2bc6lqKSztf7JVlUUlOA3nUw7+4Qq1uEl9gCAPC2m1u4
3pdOaiHFuXSSwvaYToztYBmr19VmmYpTF3DeX+B29XZ3G2rx3TqV1tAEMcrz
2qz5imKa1IzAtfXiNgsQ/i6sDdoZfy9U1IihTbhRhz+DmrjwOJujrrgOunoi
6CUmZLd/LlfT4q6Xm+1nPJnN1rwsWMdfX4/s+rmrL3uB6ZsIp+ZddkDztDFP
hPN1fYSLDQCQnwNVyV2tJMYpdiT+0PfmCDqNoRXTGpRT8iZJTYqKQkz4YklN
hARwYUzlSNiriPNOEhoN6OLjjttSpelYB37JMLU3wkNQ/9a3z9UjWmTdNuFm
CKz6eh0e+FqjE4GLAW6AyLAWvQQXB04ROhYN9angMneM85JuMyT5O1h3gsFY
frPTZoUKL4c6NIjUcdCxWn+hTG7XK9CzBcj578KK4cAD+jqPLvhQilS89xWN
2N6EhfNSoaXRq7oBXfThC/8XAYaVDs4NVJNaT53cvOHkYwOGcIIcvOK5633E
XKWgb8UusI+5Hru9AsPMKDi4FMLPYOCCh7mSFHJ+SKljvQokiLf49wXECgSr
TUey3G+abWIEepRgrc4kOM9Y+WSC5TAS+se96bxIeNgoXwNJpg2XKD/mgM1+
XQLWYc7A4chqEUYrUV+7cHfb7NM4BSL2yueuy3UYtCQhmc83kc33hVJhlHaI
ZKG24j2wALI7ZFeHG1ZC0kEpGQSQHIT6/3DZO6fFjBf2wjQCTTXss4sTIfx1
g9f1t2hyvHPYxSeDq5uQhvHGUAO46DWwD+u1D6Rw31O1zW4XlrxJg6bwicNy
74XAYJNm/huaKXDfBnrvQnf4XxMxLTsmK1kE9V9otjjUto66N40tpsfsjPYC
Mo7ZK2i3nZT96cZgtEuZcrMe1btH8kdK81BsyY0F/OxRvXt8PyoNz6R5LEqj
HNioR1Ua9eM4WdmTjvrl2PSEU3A9A+16Nj45cq70ggNdFJQU36IEJYmPdKBJ
aT7UgY6UZtSB1IQDgVEheYJ3DN7mRBhEBI4FQay0hEzdiHhW3PtEkCC/D3SY
6QI6LcKLAgR2zDD+XYJfgWYnDvQvekD/hQlZ6Aw5OBDkXvbUG7IJp/4p8KtL
wFhBfyYsNQkYRRa6Mi8SreDPdh0f7L0/OF6HrsMR5CA4Rr3JlJjljTbnzvR5
nQr7Hoql8DCQXheVueSU8hNJzkpBN5B8GHSvi2Cbjw0swm2P6iQAr6be5YZJ
h6RdTYOjh9s2vDrrB7NfwOrIzyZipWKwosIbxVelwHUT/9ZxnBLi/7pO8wPN
8+YOSJdQQHV1ZVGWOK7ZREipe+8IHUKKr3P9rtu8pg0V1AjQZMEMAc8nhnY/
eTHY0xF9Wxsqa/wdVRLQEn7HQVLbGyjF4c8B9RH02vSHQP4hqGHrbfwVe67B
cSOC9p4as0Znvqs4TEoTs6yQvm27An/gAKKrdvtvblepuE+9xADdC7hpiGBC
vR6EefHF5/Mc+gII+zETxlYJjqHCwpB+S3l5GlB7LChBE0uhLsqggU5OWX8E
sD2UJhlDTYyUnAIAUMqJr3V6r5k456NmBF7iR+rhvujKkFXtsVbUP7AkeCxZ
cdigHGPF6Yr41FY8qR4eilYEENJ/kRVPiiTFz42GmjjGioVOQnBinwagJylU
9HShsomTpqcmZeMHYr1kJEIiqneb69hVtOuQLm8wF8WXyW1KUOlDoDSfwmtP
fQ+/b+vtrmMfMqfwTc3VepD39uv2xg8D6zi4Kw1kBGEM3ycKAe2MejnjiZNm
vPFvjyiRXKTPbJhMxZICvzIjt83pqQens0QJkA28lDkbs0HFtNWAJxVTnCaP
zJytEkRJZwfva49rS+7LpYAzNov0d0QxcDOKqTdwK+WlSkIkC4GHAAtqat+S
mzLxwCrasbdn/CE3I/k7ip+s9jESNCIQkQT/MJcc9dT8JQOQKIe3pJYn/FrN
JCz89J+z7hPr7itt64jQ0hU/w+6Iqh6V/wo7g28KYARo1rHqvtvrb9h90l3Y
8E+y67JEZW5kc3RyZWFtCmVuZG9iago3MSAwIG9iaiA8PAovVHlwZSAvUGFn
ZQovQ29udGVudHMgNzIgMCBSCi9SZXNvdXJjZXMgNzAgMCBSCi9NZWRpYUJv
eCBbMCAwIDYxMiA3OTJdCi9QYXJlbnQgNTIgMCBSCj4+IGVuZG9iago3MyAw
IG9iaiA8PAovRCBbNzEgMCBSIC9YWVogMTMzLjc2ODQgNjkyLjEwNDYgbnVs
bF0KPj4gZW5kb2JqCjcwIDAgb2JqIDw8Ci9Gb250IDw8IC9GMjcgNDUgMCBS
IC9GOCAzMCAwIFIgL0YxMSA2OSAwIFIgL0YxIDc2IDAgUiAvRjcgNzkgMCBS
IC9GMTQgNDggMCBSIC9GMTAgNjAgMCBSID4+Ci9Qcm9jU2V0IFsgL1BERiAv
VGV4dCBdCj4+IGVuZG9iago4MiAwIG9iaiA8PAovTGVuZ3RoIDIzNTYgICAg
ICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja7VpLcxu5Eb7r
V/BIVZZYNNB4ZcuHTZU3lT1tKrrZOoxEymJCkTJFyfL++nQDmOEMByOObNqb
pFKqEueB6W70108AMJH0BxPQWjjrcWKDEiDRTq7vzuTkA7386xnkQRppEADf
Ft7O0DmBLpjJrE3kLxdnP/6i7ARQaLRqcnHTYmacUNroycX83RTPZwDKTH9b
0cW0OofpesFXD+eXF7/++IufBBEsESICcjJTILySIX758/lMaz29X1Vr+mrB
dzhdPqTfbXoE03u62C4e+HKxPld+ulvM04dVHlql2+2G335Kz+6q3Xb5nEQA
bMkArIyAjkTRIoBMk/itL6wTDr0jmfn9m/OZcn76LhOENkEtlNcmD6x+IkGt
nV7FXze9Junz5bzPQyuhlcqfXtIwpYnLe2kkFDmhCDrk4X/uk1MEj8P83hOZ
SGXCChHeGJzMwBEF5eOAh8frc+Wmt0l7OxL0ttqlm+VN1nBGiGbvp5slYxsR
SKyVa/H2ThhpauZPfeGC0NbZ/H61XGTwlmv+VYkVRrTJHhYF5CwBJ01NoYAY
gJA21AN2t3ujuoumyVNko0hzYgPbxInNH+nymofsCmxZZ8rbor10NABSGLAw
rAEvgtOqa1GS2JJ/vgC68eRr1oxEPRxDfbPNEK/T7+KZVV6t57VX3bBetncl
UUgD5PbYVcVzVUBCC3CNpf6pQCtfpQGfiTO5TBFRpwHH0vn9fIZISJbomGDt
WDqfGJuSv4IRFPb6EAYPOIygoqhKIWIkgiBbEKogvDtA8G/ZOT+xK2YDny/e
S8BWGM2eG616w89jAN1Vbf89kNISZu4A3LuyLgFtVwe1StvjyG4tBnriPKaA
f8+jzt5eNLlHhSCsd2GCwQhnguPM8/Hs3aWczClR/XomhQ7eTD7RjRQQgprc
nRkQFlDVD1Zn/zj7+z6bNSRnbZoxm3Xmu2ftDfklJt1mW3YTy77qeaChaZBX
KwLCQxyk+kqxREtr4r4fddTKrvq8UChHEW4EL/U6XtclXhrItV7mBdII8NZ2
uA0Zuudw48aaORwxcwpJKTPMl0+ceebZst/S9cfHGMyXmxzEgMqWdHXF9v15
wL69N10XL5l3EGibvN/2sc3VrkopsE+dpkAiUJSe0ffehmTvzz17RyfAKjI6
rkIUATHC3qk6k9IMmXtNcdYmWTD3hjNlBcM80vRY/+zRWnExKYzTdu8IHdEN
mY5BfJXonmoop4dErykeE73h3Ba9BB1hYCzbOPmiH3QMGkZlFlWxlFuCzwno
cLZektuTzKcDqqZ4bLYN5wJQSkhFkreBuurHVEllkPQnBKqmeEz0hvPJgKLq
2LWB+v1wtpp0oTlmngyohuKR2e45l4GS1FG1gbruiU6JlvoCOB1QDcVjojec
jwPlQKo2UG9KPVWn8n0vpSyhKUkio9poznsqMVRgaWdPqJKa4jGVNJyPqCRw
+oWO7Z4mH6pCPlSsM26+acDFLeUhVDhdLW526eo2Ve58o6cPy3kesLlJT95+
5Mam2sU0yQ8oTao0hLts/q2bJKQG/inmutwHQWwUeMh8s0tfD3RM8V1iSfRS
C87dYnrwlBMoDd9ttnFNgJcBKOUEY1SjvoL2NKugLpqf33wqWKcX0hnfmJ2B
QlcWydRKXvaJUPFn3L5TidXsgES8FBI8dpqWolxOWDa08XL9s1TlKde41Bi5
TKcJGpALjYZXyPWvUkUolAy1wpL1gRsSTaGQvhGtenNXRDEEPAWK/gu0dTUg
kpSN7X1vAK+HRMJvgtx2cd+stT3E/9QjhumOIwSEOkLEuKQsUA2tTO2/qR2Y
L+MKXQoH9SpCfNj0nDlY1IX0TSrsd7eLetGHi/HNMjenkcCQqrSh5B3gNHFB
v2RROlhswafUsEyUC9wJw4IetipqaffN9yvE+sZRobO4V63iisOHBG57Ha6d
Yii/JKNCz5kXxycF/A7hxCvX9l1rXvBdZZvQ8y3DCaDBV4jkjoYT+ZWgW6Jh
azbifGZ1SFUKBbODxJ+eDchrUdiA4f+o/kegSmlCQhOmrqt1wu4qFn4Z3OV6
lp038KK2NF3n3S22+5ySUgJC2q7BvNPAhFBNN4/7irHa5oH1dkPKQ8v1h/R4
vdneVat0HVMIpl0D+ml2DeLdw3KXCt/Iv+ae3s152aifl/o9jaa4KNHrl5ua
zibRvIQJFfMoXHDdnHkTa+k7zhUu50FrqeRefojr8nRd/zba4h2kdqZNi1/8
1U0eWQdaGkm6opu07bGiK/JOQ/H/4pYV/fiQBlXpu2b/ra8E5SQv/8GLey61
Ld1XzLNarRarPK/UL6Qptjh0Fs6UB2GYRceCnkvea/ebXz+Uas12O/W5tP1i
rKrt+n4Ve6fFD6na2KxzhmLDWS9zDXKQyBISBc/khQpj96m2wFoHVWuxel4+
ZLav2+wsNN7k8BrsuL1Mf7iXCdNinInr9vXgn/rEUKBqQmOJAorgQY8kAEME
sEugM+8Ohb1rDm7fwiXv0UgzvEfD0TXo0c263jfrSjqhITp4YZutCJumGIxG
DXvVH4AXjiSgRgL+VXgpxsuhfQEvTeHAj8YL23hRyvJS1Xi5/wm8vs495EDB
EXCsWRAJwswFUMOYydhTjd3JBtNbEIOuj/08/nSCtsLLhvXIvXlGEIqrGloo
PhMz0mPk0O6c+9oYOTrIXiZVxcTCqXjzyPkvp5bVsj57E1WYjoPcptykO+UB
Gy8g92rac8pLxcy7o5XRqbLIF1m5P7GV93e6qft14NksqHIO+zAZVzqdMBrT
crKtH1r6ICsPi9WCVIp17VXAzLi0cposi9wGgzwoMKE0HvqyBwFUoE5QkhZs
CoW6JLoriG5K6wBpcUb4kKm1DklI5Y4lYDs2ONhScNAgrLdNQE87MVSg+lAb
rPrOBvuHlz0FwAkh9ZKt4jFbPdz7cYECcttaRzijKZ60kkLp0FsJGpG/StSs
sEheOUCsj70faXtDohuwquuEp+TWn3vyWVvyWfxSn7WHPmtfOpqmpNAexh5I
BFfY4eIzarzb3exwHawHh2I6R0shT+Hr0/l/UQF9NJnvz1BWV0lhXP08tU6s
5AX2bg5v77c2J3o9L+BiKJ4PbgbNWqPiDmrnKKvUlEq0bkg1AaPNsDlrXGD4
b8q+Js1lbmRzdHJlYW0KZW5kb2JqCjgxIDAgb2JqIDw8Ci9UeXBlIC9QYWdl
Ci9Db250ZW50cyA4MiAwIFIKL1Jlc291cmNlcyA4MCAwIFIKL01lZGlhQm94
IFswIDAgNjEyIDc5Ml0KL1BhcmVudCA1MiAwIFIKPj4gZW5kb2JqCjgzIDAg
b2JqIDw8Ci9EIFs4MSAwIFIgL1hZWiAxMzMuNzY4NCA2OTIuMTA0NiBudWxs
XQo+PiBlbmRvYmoKMTggMCBvYmogPDwKL0QgWzgxIDAgUiAvWFlaIDEzMy43
Njg0IDY2Ny4xOTggbnVsbF0KPj4gZW5kb2JqCjgwIDAgb2JqIDw8Ci9Gb250
IDw8IC9GMjYgNDIgMCBSIC9GOCAzMCAwIFIgL0YxNCA0OCAwIFIgL0YxMSA2
OSAwIFIgL0YyNyA0NSAwIFIgL0YxIDc2IDAgUiAvRjcgNzkgMCBSID4+Ci9Q
cm9jU2V0IFsgL1BERiAvVGV4dCBdCj4+IGVuZG9iago4NiAwIG9iaiA8PAov
TGVuZ3RoIDcyNiAgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry
ZWFtCnja1VZNb9swDL3nV+hoA7MqStTXhh02YB2w0w65dT1kjdsaSOOhSbu/
P1K2Y3dW2q6HAEOBVCKfniiSfhIIRX8gwBjpXUDhopag0Imru4USN+T8uoAe
ZJBAADzNeCv0XqKPVlRTks/Lxdl5EFFGp51YXgvtQDqtjXBGyWAQxXJ9UVyo
8nL57eyc2Eeolx5DIHZGfOgAUyqUqP3gzxGgjAHMKwn0MQJ8SkDzIww/lFLz
TdIp/LDJZU8yAUSJKmqhjVRg4hgLLanAS2vQJqMbjE4a7yDZcL5fkEZpKmmQ
QUccc5PoQEZrdc4If208QcI8ZicdQhCoZETnE8rkYvaZmO085pQC6iQZYs/2
sawosRRPBUp7T7m1CjIVAu0ovy72+X0/59bU2X6oIQQiSjyiMkDlNYpa16A0
YENCrLbrTJ2BI8Sh0N87hPZThJLWqyGOx9wZrY2u9ze7sjLGF822hGJd13TM
Ys0mV/zikxftjk0NeffNY6lDkSDvpqvYecXW1T4Zbjrn/rZk02RSd2MmDkXL
y7bM2EN4nqIh3wPvt2vWdWb1ZrUdZ7RhyqFF/ub1034Zl7kuyvsU/NW+abds
xaK95v+WkHU3aB/2HNJv/lndrztjn4mmj5bSsb3pPBxJe3+XDr+hsSwrtKr4
lF03r5U2NKZ6PlcspYzt/dyLAYoL2iinMvSl6UhHP5FOqVfq1FECuOzStGnq
XVeknylh9abtapAqq6OSGKx+qg9jaXHsCMYDyVf01N+VIQGyTr8g6/5U6YJT
yDq8SdbxBLL+jNa/JOsuJ+v4Vll3/aeU0VZSTnDwD9kuqxhCPH4ngOYWtK+9
E+LkTtBRBvLwlRDoHZMAy9uh46ndJzKI+f4mTfSUvv9GD1TSA9PfSVjwJUCX
IHRXzg8FyIZ6LZln8WV5ePIdXo0hSuMwZp+FB1A1Qc1ehUYZSUhzoDp01HTD
wxMzs+EfsNNx4GVuZHN0cmVhbQplbmRvYmoKODUgMCBvYmogPDwKL1R5cGUg
L1BhZ2UKL0NvbnRlbnRzIDg2IDAgUgovUmVzb3VyY2VzIDg0IDAgUgovTWVk
aWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50IDUyIDAgUgo+PiBlbmRvYmoK
ODcgMCBvYmogPDwKL0QgWzg1IDAgUiAvWFlaIDEzMy43Njg0IDY5Mi4xMDQ2
IG51bGxdCj4+IGVuZG9iago4NCAwIG9iaiA8PAovRm9udCA8PCAvRjggMzAg
MCBSIC9GMTEgNjkgMCBSIC9GMTQgNDggMCBSIC9GMSA3NiAwIFIgL0YyNyA0
NSAwIFIgPj4KL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0KPj4gZW5kb2JqCjc4
IDAgb2JqIDw8Ci9MZW5ndGgxIDc0OQovTGVuZ3RoMiAxMjQyCi9MZW5ndGgz
IDUzMgovTGVuZ3RoIDE3OTcgICAgICAKL0ZpbHRlciAvRmxhdGVEZWNvZGUK
Pj4Kc3RyZWFtCnja7VJrWBPpGQUrBSOCgN2qqAwqKxcJSQzhplICJI3KRUCB
BRdCMoGByUxIJpAgIJcIKMqy3HTjskikuOFmIVYQN1XUBQURuS3gGrdcll2E
BwW8ACvYAWv7lP3Z/urTmT9z3ve85ztzvtfC3Nff1o2LRoAMFMFsyUSyM+Du
5ecAkIkkgoWFuxBkYxCKeLAx0BkgOzmRATdxJEAhAWSa8x4nZwqZYAG4owKp
EIqMwgBLd6slkgPgxgeFEIeNAF5sLArk4xocNgz4oxwIxKREwA2GAb+lCRHg
B4pAYRzIJRLIZIALcTAgAoyEEILdkh8WwkMBh/dlrljwoRUHCkW4KcASN2kF
4Ba5KAJLAS7II9h5o/hZIO7kv2FqpThDDMPebP6SPJ7Rr7psPgRL/9FH+QIx
BgoBL5QLCpGV1EDwvTUvkAuJ+Su7LIwNQxw3JBIGAdL7EiRiQBKQ6wthnCiA
x4ZF4HIdRLgrTeCxLVuwo3uwGMEHbJZvc7nly4YQLEAq+KfoEncZk/+F8WyE
kAQIIRFJJDJOxN8PX8dWHOWJcFAuhODrYE8D2EIhW0rA9wJH9sBxMgAhXFAC
gBLcrx0RQTF8BMAjSQJ4qJCwdJn2JMAOi0eXisvYkQrYBSyjX/8RnY5KjttS
HABbCj5GJlMogIM9KenfiByxUAgi2PKy4Ll8wDwITxEEJSCHMPAdynGRRZ+7
lqFM9rz0qELHWpseWZ/rrbrVrV6b3v+5NlzeejDW+mld0Hyl3MRgVGfULP6t
qej0N4mH2xnPU2Nzz/cujsaFj8oTrpsGTcu9pD8Ktr9JHze8ca3n5YS9tk/X
0zZlQXDZt8UvmsdLfS09An7SfWKu1RQSd7XpgozmEMSQw0cyT9Z9vMfcb/35
WGUWNVMTv74gb7WmIz05OlOvweb7KfQbsfH8Jb2L+Yuhrxpab5S8he9MjdVQ
pqnj4YtJw6zC2qp3fvQchX5Oz4JoOD90vMfAoFpwKyvBc5vp5nvMmqdunz/4
PptNDXskWCDdnRH3u53VeDKtFIdVr7fWJGalOdLTFr5bb/3z5OJTLjMwen6j
2a6ytI+UrX2koxugEUldxvQOy+ka2fON+0aMvvzDrlgFq6JpPsAeIlh2XsUy
1off01rnOnjT02TvLFNx0EfGLd/7THtCVrF9QetTTJasTY+Jyi3cnNT5ihBG
OTk4FzRl1vLCYAidTOR8kVNKyb4v2xJ4bw2j6/bbVGoEq5w78Yue4qGuL+3h
ZfuS1m25t15n3Lmxa3Les/ePb9S6h0YNIqJ90ptLxpz9d5o4S2h2pJyzD1I0
+qxBh/b7VXqNw3lpQ9EJXmd+d6FwepdaoUi9onw8PmPm655Sp2esMOooGTci
3pa7qtT7U1NKmq2omZc9P1U1SLuuqhkFNrU7HYs+Zm5vC94Au4Lq4OvRWK1N
ndwk4MrvWRRzfWTTYtBB0w23DLDwU221yVGyY8f3XzysMznCHoZOdKSH/pXP
aDmyg5kTF0URb3k9gNxxVFcH9rr4vaIaVpX8zTO6k6ydRqfWRVTpV5a5RIw/
dpKG1MCL5446+1YMThVmZTpNR4ZnKFO3hcoPJK+d8dlvcfQUqXrWcK2myoVz
oKcxOlhoUIbl0ToMpZVlsTDV8PzhE+hvByqT+1+iTRnZYftokh9iK+J3T73R
bN8dM1Wc86Kj/jLa3Eno3tEUZ8LSrXQIAzraeQl/LhhqaTOX3rXcY3V/xP6n
sm2rrR81XgxWzUbsYKeovFwf9u9hWsQ3tjOtD/W2UJOIW9fxSC8ZM4LP2qy+
9jBLX2N4YbfFjKaoubtVv5vxhrs6uw+p9D4Fjv6S85yYqu8gs5BBt98dZZTW
ryqemGHFkeYlXe5BvLyIHmCvY/UUCn/i11A6WLxp36JFvxnQ9/WDUsXYycKe
2rspWqQFuFFrlXWCR4HNKnOazZZup5+f3LitClCptzo12yDs2U/KN52rN+uq
gg0zea4DNOHg29U2C10sx/jWuSGivIFEevYsX3FVFMgsMhxoxnrHMs/M/jDp
9NUZ2wZ6wEB3V+wx8Y8vfOeME+9HxbmcCzpCLKNl6a/TPDcel5+IOd1sOuxm
9GXjzZE5avqTdZb5O6t38kQ1RUr3zZKJ1y06xq3FXXfmUtpSb/azrOpqxaZF
JrXCjyLozFxqhwpSDo4dc869yHefNhRD5T5nE7YqqWFIx1BNpLfkT3xBTFx1
bW5Gufzmb/TkmddOHOKEdJOembYnUYPBv9TruFeNPMx7nHhFd8tovv+RcfXo
sEdY38SaJ/XvVH7+n103/6LPqLNhNjRqn4Z4OrCeskYQdmlD0bfKLtKhTHWI
lsl+BSG3V9UFEPe+uxtLzxZ9NVdjVpOuub6R9B8+hP8L/E8IcGCQLcRQPlsY
Q/g7nPPIkmVuZHN0cmVhbQplbmRvYmoKNzkgMCBvYmogPDwKL1R5cGUgL0Zv
bnQKL1N1YnR5cGUgL1R5cGUxCi9FbmNvZGluZyA4OCAwIFIKL0ZpcnN0Q2hh
ciA1MAovTGFzdENoYXIgODQKL1dpZHRocyA4OSAwIFIKL0Jhc2VGb250IC9C
RElGWUorQ01SNwovRm9udERlc2NyaXB0b3IgNzcgMCBSCj4+IGVuZG9iago3
NyAwIG9iaiA8PAovQXNjZW50IDY5NAovQ2FwSGVpZ2h0IDY4MwovRGVzY2Vu
dCAtMTk0Ci9Gb250TmFtZSAvQkRJRllKK0NNUjcKL0l0YWxpY0FuZ2xlIDAK
L1N0ZW1WIDc5Ci9YSGVpZ2h0IDQzMQovRm9udEJCb3ggWy0yNyAtMjUwIDEx
MjIgNzUwXQovRmxhZ3MgNAovQ2hhclNldCAoL3R3by9UKQovRm9udEZpbGUg
NzggMCBSCj4+IGVuZG9iago4OSAwIG9iagpbNTY5IDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDgxNSBdCmVuZG9iago4OCAwIG9iaiA8PAovVHlwZSAvRW5jb2Rp
bmcKL0RpZmZlcmVuY2VzIFsgMCAvLm5vdGRlZiA1MC90d28gNTEvLm5vdGRl
ZiA4NC9UIDg1Ly5ub3RkZWZdCj4+IGVuZG9iago3NSAwIG9iaiA8PAovTGVu
Z3RoMSA5MzcKL0xlbmd0aDIgMTUzNwovTGVuZ3RoMyA1MzIKL0xlbmd0aCAy
MTYxICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42u2S
azxU+xrHXcPUrmyl07i0hmhiY2aYEWEfRC5jcqmQOjVm1piVMTNmFplGCLkU
oaNitmtCbikk1ehDkkuXTbIphlEunRJKNxWdRbvrfnnOq/M5a71Zz/N9nuf/
W7/nr4dx9zKypXP8QUcOGzbCG+MtAXs3Bx88DsAb43AoPT17HkiFIQ57ExUG
LQG8hQUBcAlhAQRTgIC3JBAszTag9AB7DlfAgwKYMIC1Xz9fZA7YBoE8iEZl
A25UmAkGITNoVBbgxaFBICwwBmxZLMBzvoMPeIJ8kBcK0o1ReDxAh2gw4A8G
QGyUybwkZzaDA5h/StNDuJ9RKMjjI6IA7LzK9QCikc5hswQAHWSgTCgc5DAQ
kfLfUPXjcMcQFotCDZofv+DTXzg1CGIJ/qzgBHFDYJAHuHHoII/9Y6k3+Emc
G0iHQoJ+pM4wlQXRbNkBLBDAfUpBfEcoDKS7QzCNCTCoLD64kAfZ9B9FIM4t
SDBx8Xb1sHMz/HOnC9CdCrHhrQLul7Hz1Qsx/muM+MODwgA/HOIvHilE3s9f
u344zIFN49AhdgBAIJIAKo9HFaCQ24NERECIByA2HQwDwDBEsYkxmwMjLQBi
ygGAweGh5jeKJwDIOsNg5C/40MLfIniBEHGAiT+PSgsEYRbIgGHuV4L/QhYW
/C0ifNfkD38lpt83fYvMvmtCBH8hxO+bvkH4eeU8Kn3+CvlDAQv5v67Bzo4T
JjQimAFGBAsS4osZcpa5OeHAd5W0EB4PZMMLtxzx4XPMgBA3QDAMpKHu/8Gh
bYzde7I2riTCoaCjVNFA1i7gYiqluqGrfnFMb5osq6jdNdhgoMrnXZlIbemo
4uiafR80+IfF4R63HScPBqdmdM+Nhu4ZFe2/pOHzQuQmGOHqvIl5uuxK7b2X
40TZLXcHbpak+55uzp668TTfHbtp65hSP0am0S+0pvG3WJK5j6OItS3+UJW+
KcZzeUZwSYJZvGTf8vRjCpLfYyL2xivXGfY954hDfn5XoJz3z7mdr+rabxRf
vdChEzqi+rHSYGj18gElzlq8VnpHeHmT7vSehEjtfA1J8bHIaYJv3Oy5ssHW
o65/H8tIxHR7jCsHPG3f1LDde6o/zUaIUyicHjIVQvFzYoeZxNb+oIYK74jU
XxU7uu2U885GYlvMnuMaTWtida7ei7M4dZFCVn4xtvyhS+b0ZulLC/IopfyC
szc7UYHi+eSqr18bfWVQdpJh2TJnBuW4VjjaelXi9Uj5FkU0rfvxoMK78s1E
7eh2qcClBPqF7sk8DBcXFVeo1JWEWen+o/EJZru+Rko1PjrYYQDvx26s7q0V
muq+oT55eU33CoZMDlxkpIFd427bwcTnOqsqxoT2Tl72TXAtwCf5tW2PfXFQ
6qvR0Fl12tdALXJaliqzuq7c8SzbSayinXB0Uzwzxv1fFe7whJPTOs3h8qbk
JHGKdTVWTdJdbVspYshi0Zc3uJw8kuFkSftw3afjkXh0NmZphMq5voz9gbSL
jhs+5GIKk5ibc9CHdLZze7IkI+WL970qSW/nLt697PlM5A2bWanuQeKUSzbQ
tDrjvIGUEdrkvwJdWnD89iTKWbpCy9QXfPHeNsP5ZOadW62lu/Q86WHkLpRN
9PGEo++vLUJJei5f3zExcfvj/s1njkK95BxvffXGcqjAdfdPPz2eoAzmugzI
xzNV1vZ2X7SZolREOpwMP1PBvydxGFjNKKjT05SPUycTfaIk+iqtS090lsVp
HvOFj2a8DtairEXr53SvmcaaOdItZ54n3wlQV+0z2WVTHDFmdvfqH7oz/NHY
xckV2r9Y6TMkbp2NTSbRK2mHRnbntTk9CnEVOsVIKjwzc9Axw5CcCqlUprXS
vPnBWgd0z/Dp8e7YvFLbkcpHG02lHcOrVA1LG1yaH7RjhsQnNSdai0YbSIkP
2tN6hq/fShk/J2Z1AVXWbaG1BOqVm6eKBG8LQxV2LBHwMPd1ahXfg9L77Y8C
DKuKkpfPrR9vPnIkUWv9OYrxA/kPoo9T4iUz3hYbrZm5S83kIyqa0VEaK60e
+u/NZEwUED1WydF38k00PKJeaR9eRo6aHZ+84Tn3MxPjZdOyqVqXezhM+res
gjMy54QP7+SwEoAqXmdLTcChRKxcMKeqvnetUNPr7I5MK8OqIWn3pALKKD34
sUEC10Q0PJEziFPsfVreij5rWe2qbr1KkErVze38Lbdvx6PgjlVqZmK5NW+m
+O3FWTZ+v+fY6guHNeVJH6Mk5+sW7amjT20MTVGasT9snbWz59JZ6n2V4bi+
N+PoPDf/yne3kivl4ICk1kGiILlF/SZaOU+iZo89kw28PrDvqd5wnZwtLVIJ
kjbTDQv7YRLZVCcixr6syHyJA8Elf3e+2omuS9ruMgnl5g3SLCtstoiUOuot
kvUgP2wceOY//fqlSwaJo68otmRgcssStq+bi8YYXrwy5LUvTzn/IfmWrP7g
thLLyCMbJusLa4CaKdyppG05fveeiRYxmzeoVU+fuHZCOtslm1Zwk8Apa70i
Ik1wd+y51PaynBMu/zbN+05hS8PdzDW948fbVMATXX2nQps3C88/HhMTX2cx
t3meEXqVoNOiON7bYFKPlQzWq02L3wLa0VJVUU6i7JT6wGhnXH+Za/CW+OTO
fG7F4tUvaudG8mveFrN7++l7fe4FXTVSD1sSE7jONZ1Jld3qq9rWyismMQ8e
qZCN9ejIWSlZnxGlVKAlrKz5VQvz5r2vuClxhcezwOzZPNZ5nyBf3labsg7K
YIJm8EjSFt3nW986vK+6GYsFXC5o8fSe1MorPc6pj7owSCSPnTr/NtwrU0M+
VtVKvefVIGloYmqyPiEnBfcfPqj/D/ifGEBjgVQezAmi8gJR/wbg4Z5uZW5k
c3RyZWFtCmVuZG9iago3NiAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlw
ZSAvVHlwZTEKL0VuY29kaW5nIDkwIDAgUgovRmlyc3RDaGFyIDEyCi9MYXN0
Q2hhciAxMTIKL1dpZHRocyA5MSAwIFIKL0Jhc2VGb250IC9KV0tRQk0rQ01F
WDEwCi9Gb250RGVzY3JpcHRvciA3NCAwIFIKPj4gZW5kb2JqCjc0IDAgb2Jq
IDw8Ci9Bc2NlbnQgNDAKL0NhcEhlaWdodCAwCi9EZXNjZW50IC02MDAKL0Zv
bnROYW1lIC9KV0tRQk0rQ01FWDEwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViA0
NwovWEhlaWdodCA0MzEKL0ZvbnRCQm94IFstMjQgLTI5NjAgMTQ1NCA3NzJd
Ci9GbGFncyA0Ci9DaGFyU2V0ICgvdmV4dGVuZHNpbmdsZS9icmFja2V0bGVm
dHRwL2JyYWNrZXRyaWdodHRwL2JyYWNrZXRsZWZ0YnQvYnJhY2tldHJpZ2h0
YnQvYnJhY2tldGxlZnRleC9icmFja2V0cmlnaHRleC9yYWRpY2FsYmlnKQov
Rm9udEZpbGUgNzUgMCBSCj4+IGVuZG9iago5MSAwIG9iagpbMzMzIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY3IDY2NyA2NjcgNjY3IDY2NyA2
NjcgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDEwMDAgXQplbmRvYmoKOTAgMCBv
YmogPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbIDAgLy5ub3Rk
ZWYgMTIvdmV4dGVuZHNpbmdsZSAxMy8ubm90ZGVmIDUwL2JyYWNrZXRsZWZ0
dHAvYnJhY2tldHJpZ2h0dHAvYnJhY2tldGxlZnRidC9icmFja2V0cmlnaHRi
dC9icmFja2V0bGVmdGV4L2JyYWNrZXRyaWdodGV4IDU2Ly5ub3RkZWYgMTEy
L3JhZGljYWxiaWcgMTEzLy5ub3RkZWZdCj4+IGVuZG9iago2OCAwIG9iaiA8
PAovTGVuZ3RoMSA5NTAKL0xlbmd0aDIgMzY4MAovTGVuZ3RoMyA1MzIKL0xl
bmd0aCA0MzM1ICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVh
bQp42u1SaTyUbduXJUxkzb5ctmxhZmyNNdnLvkcyY2YwzKIxg7GUyhKDtCBU
hIiIJEvIkmxly5JRyB5KIrKEd+p+nvu+3/v5+L6f3t97XV/O/3Ie5/93HIec
lJ2jihGK4I02I+BJKhBViA5gbG1tCQED9DMYDJKTMyaiESQMAW+CIKF1AAgM
pgWcImMBqDoA1tbRVNfR1AbJAcaEQAoR4+tHAhSMFX+ZtAEjHJqIQSLwgDWC
5IfG0WsgEVjAkYDEoEkUVcAIiwUcft0IAhzQQWhiMBqlCoJAABQGSQK80b4Y
PEjtVyZLvA8B0P6DRpED/y0Fo4lB9FCAwu+YigA9JIqAx1IAFNoHpGZDoL+G
pmf534j1z+JmZCzWBoH7Vf53p/5DR+AwWMq/HARcIJmEJgLWBBSaiP+n1RX9
RzhrNApDxv1TtSQhsBikEd4XiwZUIBqqYI0/eEyQGSYUjbLDkJB+gA8CG4T+
zaPxqH8moffvdw41B3NzVwsT5X+N9rdoh8DgSU6UQDQA/sv9G0P+wvQmETGh
gAdYFQyG0I30/98nz388ZopHElAYvC8A1dQCEEQiggKiLxEdaQLhEACDR6FD
AXQoPbGaKp5Aol8B6J2JBHwIRNCvuWoeB9QC6aMhoH7xf1AwQA1JwOEQfzJa
EEAtCIsI8vuTOa4BqDn9iejzVfvLDaOX9P4L/ar2J6IvDaCG+hukq7i/IL1J
avi/Qboa8heE0tXQv0F6KsrfIBRQC/sN/3MaJ08SQsNV1KGAClST3h2wxnFA
WxMc+d+MSDKRiMaTfm88fab/xj4Y+hqg0aFoJIg2TEDqRvunV8UWXTDN6ytm
UQwSyyiMfvMipjJDV3VpXJd3kFjd64SWWOWJ4fHHPOJO+3K6VA3lo/lRuMoo
oj3cUS1mhKedk1/xfqYj61fk0tlzjB3ZbS1cuLvx8zTJmcBq5a+jMusTwS9Y
yqwWINq5wl8SmIveDe+uXQi42P2Rdug2SmY2DeSZXWeVinb5NJHyevuzOSGP
QHvQIXg2c51vjybcMvY24ANnBoyabc00lKH/kx2sGOoz2Q2CZAVI0tzuwU45
6rCJaQ265GQADCL6UhluBrU1p62X2ab7FWHTUhkcby0vR6ZZuFo6b4gW3+dF
Foli9c0fCB9Al7e4N+IM8M1xM+X2l3kDyvug+rcggdWpcg7wrV25Vdkk5u+e
OzvjP/apwo1fkeFSDEKPGV2Vj2cZBisoLym+AQuzDFxtlzqD8Ls5TzIytBg/
dILahusxnIyo3bQG3GBDUfzDD6/K0KCgBZ0tXHrOMWt35Yqa9htnTUMZYGda
8XqTuSuLrY3ULOg5M2OPcXi90zvljpJnTXkmfCVxzJ7tNWZmebI1bISR6ZOC
UgZ8YrpHuI3OzjgBfsm05rehKZ/9GiJ4Nbe3xB/paN19+1N3tjfNub36S6GW
+AWW2SuiAcmqn52Uwo8vM704XQKn9B0vedreKSCfjnKKULFPD3hUdLooFkf5
BmNPLYaVr0CYciIavhvVvPLJJqYAZQqnL64rKbbJeXWVfCNxp9jt5MJViWcM
6xtb8ET8zOOt8GBova2Xpu5Z3723BoUO+Q/Cr138+u2dhni8F0jn0OTINEw4
0DQs7cJ+9MaIOfkQj2nNGw8afr44Y6zzIwY2faUhn4cso+9WetSgUbisaWrz
hL0KlMfHKRyMPaOccGByWw5Vm4sr4ZdD8c90nET4KtCE2q35Xlp+F8K31wZS
Y81IcgW7T/PSXNQuzIycqNSSIllt5urgHY9aVmGVGBjHmDfX0oRm1omX7g5Y
aD/LSUYZfrhv575xf1t/on+bHMXX9SWh+32durWP9b6HYypc0Iccv4xhS/MX
HBs/0bLtkN85GidRzlWg962m60KzUzA2f1QnpcWB6F3opO51UUvAklXzRPGm
ByV1x1MNz+Dd1xflqeJyeahsp8nohrEfXNRvT123JMGtUNCdRXl8RghjUixQ
/kIYhHAuvmBIPh1XfZRaOK5dd691Dbp25DNCyzAh2BEmdt3rOrYDCA8L9z90
3XWJW4SZJvA0Mq12aALxmisD/8V/J5cjtfZU3atTXBdkC0ruCI3q6zw9vWy/
aioUNVa5RbuWlBf7OqT3u8YQm0PLkMdWJlQ7WOLxp04BnoiwvJstScNEcRHL
kIdl/AcfH71c8mIXSG+p+JlYp6q7HhsrvAkPd+x6rXdDKtsT9tPy/l7QwBwQ
UvSOMX1psmErL5J7j8XMM83nmIzsWQUDr7mKqGQccGrSaowDyinlhkzaiO+I
emIxJXLOQmuenGTrV8e0atjwZBXcMcjOxgClfpw97v/EE9suxDu9NmJC1Ca8
duF1FzBviXnJgUwVqkhrgZ4sux/ROSYnYr51N7iHu4s/1u2hfsuQydqtN6YS
RI47gvXc00ObKQB4ljVI/pqsxbcTaolBzPheVcm5erM5y564+R03YPMpofGM
dAkrpXJMAQSy1dqOlWj3Hmy0qT72KDI073plXRavf+3RpQfvi1buMPC/+lBi
Xgidn325MKKSfQYkIb9WAd9IOWv3PjkYpsxkDqeWDva6tIoWeN0c2z+f/fKT
fWplvK8L42QOyUH9ltn57adlopASXKk26+3dR2COKwo/tnSZy3N4cfvV7Ipx
8g7XuaLJRkFR/aXQFd7q09kaT/dPLrCNyRrbboablla9fRUDOSTa9cw9B1cm
JDMQLBOTwdfnCrQ9lEiLCsRH4xNl7cYLmRoTcFDaMmswVmwfFJ5sMWnpO1Ds
ZLF9ew31tsBAkuc6O4fi1hJ8br0qqzIpTmI/g1r2XJdQ490ickjryf7jJN/o
qrjGi5DZdsJl8YOFxKKeTROnaLkm0acsxvbrzvbDWc1s8Wk3aKeXCy6J51Kz
2BXsM7ONzp9lWt27ldbENdQiGtP+I7LT9IQumdH87K1+xTOBTorjphqd1Tiz
o5Q3YiKJVIsDm2m3rXH+WUFL9oUjbqNkXn5TqMyRUxOsuECbU4ap3aaHhQQD
JM1rJVdyNpWLOyrJeT5F1qGeCcFjO5U1XsPUrsNJcGKH1uCzZ+1ClKkVxntS
kn2fA/rTq/H5MiasRcqOVy8Ki2xVxnDEhTCe8yGHYyQtEQkIfaqErs+e9GrR
4pVWuOECpyl/aM0AYoxHcvxOdK0PevPWA6UHbVE/gdkUgiRBJ0fza8SISEW3
S5bo3sTeeiNq1zgmYeTO6s+PVjy2N3PywM/fCvtu+ZnILJ0IU9300QjiDy/9
EefiJeRAZWVMcU66UBF8YDg/t4y8X7FcyXomR7RLOP6twIvGQYbXNkNBr4xV
RF8XNUkR5x1Y/fTraiLZRN73y/TagytX9u40CyjCxjNtcnrTNs6/2tDb0oML
vVpYpIglHBRJ4Up4mp5dH/NuKzasZyLFwmA0BvldNaz0jTqDpXQXddub9TJY
SYo3qrPJzWrMIcmMqkS5eZ7M5PxABylmYfr0R0Ox09QN4COLzPrLyjVzzfuS
N8SFxZ+TOplEOStTT8WEbsu4rjzrUzRX2dSiRKq2e7uoZiTOe7TasZ8bCog9
vN2uf5WPNjIw0ae+e/++dSny/bvtAI2TTtr9n1wMPjwME2vtlDzZSoZ2sT5u
y+cu8Opg96qHWPWeO8MO7xfj8QxzEclPjL+LW2tHbSgoEqkxDXrHhVD6mrWE
Si8awar04CWngdZ9QX/MdlupiIGQxqABi+NwKkP7br3g8jHpJx9EzifljMvp
FUwdHoryMp4W518bywzti9cIAHXNJ4cFACrFvE7Bt0SrejLguxnPpvMOTqkm
wWyuhN+P2Rb3mABZNLR6oEKs9gc4pJPY0x+fjBijGou8Gy3Qhs0PQAyBVzHQ
0S8tBYM9CatPOPcPys1U1ipX25hKfXjwAxMaMc+8Je6ZjrL0xSokC7LUp6zc
CaR0q3YKDnXtKvB2XxpJ0o1Zz9uvQV+GxB5pz6LUa0Ft2L1IVxoh5/D+jten
WXrfLY8UxAUNvCJ7vZS+Jh6TXjPH4psnycf8UIGZr23BfSVIzlRPwwU7Nh2/
gtg25xAYyXGiBgUHZc7CEUHCP7W/P5PM6xkKcgnbEtjmqZ4ZiX2hvWrQI3bL
vVOlZnewmGugiq12SVsNZ4dpTKSUa7ZqsMPPDo/htUDrPFZbrOlxxQW1yMWU
sl6Da6hs/deXJwlkdseeaI96cngd0zVr+YrLk3YfU4YO/MRMivVcbZpo+n7O
2eueTvRByd58aM6UvUzzDiZz45NG2UAzhci8w9KfDsjmZPwgtGXdK/dAMUMV
I0KccDNMraGNz1dtKJpMO6jk9EiDPcPvR24dr29paGltULpjcbTtip3UAbXe
JaibFa3BxKsEN5y/zZc5OPEU5Hn/xuDp68M0BuWBGEFBBurzzQ1ISuUhYJb5
IQ6gIAEll0XeBdt7gsuvXNHgx753T5G1x+AVDTfzbMEV+8/QRNe27MWA6CE9
8eSJJDEAwXcXi3BYSusj3znmYVr9/Ca4i1cztdSIW9U5UA/5Ip/BQ13/TlVF
8paAybHuok/XU9LktWkvnnexBAjx40n+wZZTRSKaPfqXYdcs3H3ygpa/jwok
mYidjEp5n6t1m7rEA3sx6TI1eEFDiYlvzxDNsHaoxHmZLad1BS5dYe/XOyGd
JSv5RtNwUWFYnMI51my71VMtvp8o6T7HHC1TOF85cV6+0RfOr9VCqV4UkoWG
TJE3mSxmcG3XrEmLQhwwuP/j1cM+RdF1k9qZ41mPn0KllMcGe9t2fX/sR3V2
cH7pyVo8sSGNPtpV4sa49vEZ+LlWgjXtrQWT7fdO78q5LkX2otGV3M9qk1U5
2xRnyGreRy3wvcIwpoCv6heZRGaxlTNDvfBIeciZ8AXiR1Fh5wfLpjrWgrE+
Sv3qlZfHDw5A9qwXMA8NuB7ZdDNDDZ8l0+aS7qYcUXxEhn6TEzOL6xZPRKom
Jmo0ubi9UXmQfBWb69CMZ757OOcji2PZLs41goV1WMJUui+Eg1Z4brOBe2rv
Jcrm5iDhwI5IXS21t4NTMeTwRbPcTN1PLW7usn3LQWJ3n5RJ+AYW8Wz76mHF
h/2M2mbnKuXEVBuFnEfrHWaqS85yopDyRsXRHYHfQmgv+3JHnZPfZEbJNc7k
Xf2sXhWsk07u42R1HwKJiLpz7yzuhqdoK7b1VLX3GFeJihs463WHld9KJSqA
L7txoR9++umV/n4yukitpLFB5EmzSqKxUiToHhPDGEucZEcXS1vID1ffjeQY
bafg/vUrIM06Z0nrNr3VJmvbhUr7iE53a4Wu/X7QnsM9wZfGy/kx/iSPLwNf
zSfjD50YxWMbzziKU7vELtRNyY95eW9NzWq5pa4ePowvZJWHByubpucF9LAc
9DkffPtdd0p8ny3350K3C8VL2gbrMZ0WWQfTMh9d4vLiHpvRtxfIfN4bTVMT
KpPPQJnF6K6xfd+Q2G2B4ZsGHPTluy5Jl6fWqn85Zg8S5q0pd6vKeq/1beN5
WD45w2KRU4LdzqPn0+HY+kPnPdJN70CNKaJavEdOJbjR3kwVVmCavflhe1IL
T8qrW0uKGR9yOfiqwNUHXji3zFvZhF46yy9nNsM1t/iI6sUx/mqxpuaa+WnB
zO5hXtn+d0d2ohyUpDEySYi5Y5sCvivOsjcmGec/9dOG7B6FR/PAd6kuU0ed
Hujv/vA2gMaY+hw/eaOt2JD75chJghgFaygWdcsLYD6i4r4jaqMfili71kHz
IwXcbna19w8o+GDrSInSng7ScTp37Lw6WDCd0+bKm6IrVT3g/+EH+v8C/ycK
ILFoBJFEwCGIAaD/AvSnptRlbmRzdHJlYW0KZW5kb2JqCjY5IDAgb2JqIDw8
Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRW5jb2RpbmcgOTIgMCBS
Ci9GaXJzdENoYXIgNTgKL0xhc3RDaGFyIDEyMgovV2lkdGhzIDkzIDAgUgov
QmFzZUZvbnQgL1JHR1dIRCtDTU1JMTAKL0ZvbnREZXNjcmlwdG9yIDY3IDAg
Ugo+PiBlbmRvYmoKNjcgMCBvYmogPDwKL0FzY2VudCA2OTQKL0NhcEhlaWdo
dCA2ODMKL0Rlc2NlbnQgLTE5NAovRm9udE5hbWUgL1JHR1dIRCtDTU1JMTAK
L0l0YWxpY0FuZ2xlIC0xNC4wNAovU3RlbVYgNzIKL1hIZWlnaHQgNDMxCi9G
b250QkJveCBbLTMyIC0yNTAgMTA0OCA3NTBdCi9GbGFncyA0Ci9DaGFyU2V0
ICgvcGVyaW9kL2NvbW1hL3NsYXNoL1QvYS9iL2MvZC9tL24vdy94L3kveikK
L0ZvbnRGaWxlIDY4IDAgUgo+PiBlbmRvYmoKOTMgMCBvYmoKWzI3OCAyNzgg
MCA1MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCA1ODQgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTI5IDQyOSA0MzMg
NTIwIDAgMCAwIDAgMCAwIDAgMCA4NzggNjAwIDAgMCAwIDAgMCAwIDAgMCA3
MTYgNTcyIDQ5MCA0NjUgXQplbmRvYmoKOTIgMCBvYmogPDwKL1R5cGUgL0Vu
Y29kaW5nCi9EaWZmZXJlbmNlcyBbIDAgLy5ub3RkZWYgNTgvcGVyaW9kL2Nv
bW1hIDYwLy5ub3RkZWYgNjEvc2xhc2ggNjIvLm5vdGRlZiA4NC9UIDg1Ly5u
b3RkZWYgOTcvYS9iL2MvZCAxMDEvLm5vdGRlZiAxMDkvbS9uIDExMS8ubm90
ZGVmIDExOS93L3gveS96IDEyMy8ubm90ZGVmXQo+PiBlbmRvYmoKNjUgMCBv
YmogPDwKL0xlbmd0aDEgNzY1Ci9MZW5ndGgyIDE0MjcKL0xlbmd0aDMgNTMy
Ci9MZW5ndGggMTk4NSAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+Pgpz
dHJlYW0KeNrtUms8VPsaJuzak1vZou2oJcktw2rMjOuvMy6Tcmkkt0iWmTVj
GGuNMYORsE3lEjUuyVZ2KJ1yN9lKsUu6bEUSQiI7pe2SCscttBftzqU+nvPp
/M5aX9bzvs//eZ/1/F8dLZqbEYWBBsBUFOEbgXjQArB1tvEiAyDeBKejY8uD
IT4bRewgPmwBgObmIEARsIBtJgBIsiAQLUzNcTqALcoV8tisQD6gZ6u/RCID
lBCYx6ZDCOAM8QPhEEyDDnEAN5TOhvlCPEDhcIA9SyfCgD1wGMwLhxl4HAgC
DDadDwTALDaCM14ytBNhogD5U5kh4H5uhcO8MMwUoIeZ1AcwiwwU4QgBBszE
Gbug2CwYc/LfMPWlOFXA4bhAIUvySyF91YZC2BzhnwQ0hCvgwzzAGWXAPORL
qif8yZsNyvlqyk4+xGHTKQiLAwMmn0rsMCo7EmbQ2Hx6IMCEOGHwch1GGF9a
wFJbNmDs7uXm6E0x/HSbyz0axEb4e4Xcf6gukZcx+E+MZcNjRwI+JngTExAj
Yu/nr/1fzLJH6CiDjWDrQCQBEI8HCXHYXmCICBwEATbCgCMBOBIzbIxHUD52
BMASOQQwUR5u6TJBbIuMI5dqf0IQMBb+C9wGGEctw6//0MYGjTxohM0x2kbE
Rm4zMwfIRPDQvxHpAh4PRvjLu4Pl9Bkz2ViqMBwJ03HdT1C65eGgU9VHL8XY
n3tUJGcgbcO6Ina5fLOtbrWoK02ac+G+Y6hBn8RrrjhHRXFQbnBjxLxGWHJt
tGsz9e0PoeLsjsXBcP/BnKgaDa/xHGfhK+6madGI0vXq9slRovTux30PLmV6
n7+T++7uSD5Nz27v65XPtKTqfcKr6k8fJpG9qDkc94Qjki0ErT3K2aGXEk0T
eiOUM9Nle1tEMUEJq64a9rxHawVr586tystYPCDDaPbwn3YcyxIqDOybEzdN
r62M238xeUCQt9tKXO/ft25GPGSpUhUsmTylKV79M+3V9tEAB5GBqMVOw8HV
zuvIjmzz8iJ9mYLw8FcLtU/cqNE+LM+nGjwtgnRiWP7q3d2dyte7f3FNzT7N
6rUnzHCNGIpXnaxu+Uc4fOi8XRty6Qj53kXL5uYEjQabAfVx/RU/uhSeOMBO
8r/hXt37fU+RZzcS13nr+Dd20X7SYBVN28m8bduTkcHXIR0y1V5HQyZ7WHzv
MLPKHnEJB3dtpODMEIwkrTuUePKE5XiACimplFJYc0lhXJS86S801hUTJmSg
VKoeROJKLuSqgaRoEdF/RWZxAzwhmhVdLN5Arq+Pc8iY7nm/6ekZM9vW0H0P
3qaPJ4/+Tste69r6+IBKRZ8t8BjybKXsCDDQf/16Ko9cbpq3/pBnscHZUH2p
jbF01HJl/3vj9m+74q5GjqakbbDcuLlMP+dOgO6HXKS5987M82b1rkeVjpMN
QXjS1E+8tPy8abM3uh1Hr5WlyPYr+FglgkFtZCdXhtYJ98SxnlmmnK/7UKSm
oLKzpr5gYUv86weJc2cCk1LclevWM67TfItnz6bdW7PS/nmtY7KBqr4bMDwe
derN4buvMvm3RHrehS/cEEKStTg9N0TnyD0L1BoMzno2JauShtdLbcj0s9jq
NqYaNxfYLt9A6i7H9yQ8vbnrwbh2m3Bv/PRbj4t9roL27sQ6luzqg1TTSvup
xpNSZzSzQrViyIJjgo5dW96moh7x2uoSD8ltS90XSXgdxexJMwIlXk3zxxbz
hRPqi03yrhrxsy+rJpUPXBE/IbY7NQ73+FasmZ++rB8W97RYiYrm/YZwXzz/
OyB6FDZ82jPHqFDx8sdd1xWV5gdmrLd8lOwq/eWx7qxhytYCa6jJ2+xlLS1j
2Go974NrcH/bkKlyi8uGghJdG3vk/cXSNd7WP1itiEjJknzvsuqb82NlhCko
KtxxMU6GVLu1zM7k/FyC/FBQrozfDYnz0eI11kkXqI+qDGU9fhqVkv/wdFC+
HJbPOGP6sHHdrc0+vzeemJiqZ1ZQ6srsuPLa83wOSblU8CtEUi0cId9Oe7G6
pdnP/I4UN8JXTu3uxG1VP0iNR/JId+rfqc8wz+/m4e41bp/5DupelWWz8rsg
ZWtg7DhREdpTKqTWVTZSmZWX52Z246VL3Gs6GuRPyhF/Q0QOh5ulJ4bu52r0
xVT6Ns4/k7tr7rwB2S29IaI/+WpghAJARmKLZlcqKPADRupLbquZBv1aoUBY
IA1LaZZIuw+CMWrUVjE11nITPz1iMmJ7vGbBz4X3bh6zkQ+4ofbgLEf6VOq5
TaP93wrCxUjRhyy2z81hyx0erNpab++UAD2bYu3y9x+pY+mbnYIfnu5ciKtJ
/Zvtm8XwOq3q523ZFiq9Ka/UXz63fpd+cPGa0wT6kiaiVRL0QPLQ9v41Hwmy
bWBbU2qnf1OFavBGflfsw2a5/XveCHfI6JqicPpB2fZz1pKMh5Dvu/NO+yeV
n3W9a3MbMHINZo1JqqyrY/bh98k/+6vLtfS1iVamVXI6vQJcdOZIUfdeQkNs
va/FaPEoDueUTy9jHg9sVVc3qw1q6vZwKxy4X5gT1ZG1X4F7WCvaL4FeoXyK
yy4njiKStNNKTjUUKyud7YuGrobcYzEOhUz6vFlLvsl/+OD+L/A/IUDnwBCP
j4ZAvGDcH/UXIcllbmRzdHJlYW0KZW5kb2JqCjY2IDAgb2JqIDw8Ci9UeXBl
IC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRW5jb2RpbmcgOTQgMCBSCi9GaXJz
dENoYXIgMTIwCi9MYXN0Q2hhciAxMjIKL1dpZHRocyA5NSAwIFIKL0Jhc2VG
b250IC9VWFNLWUErQ01CWDcKL0ZvbnREZXNjcmlwdG9yIDY0IDAgUgo+PiBl
bmRvYmoKNjQgMCBvYmogPDwKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2ODYK
L0Rlc2NlbnQgLTE5NAovRm9udE5hbWUgL1VYU0tZQStDTUJYNwovSXRhbGlj
QW5nbGUgMAovU3RlbVYgMTI3Ci9YSGVpZ2h0IDQ0NAovRm9udEJCb3ggWy01
NSAtMjUwIDEyODkgNzUxXQovRmxhZ3MgNAovQ2hhclNldCAoL3gveS96KQov
Rm9udEZpbGUgNjUgMCBSCj4+IGVuZG9iago5NSAwIG9iagpbNjgzIDY4MyA1
NzYgXQplbmRvYmoKOTQgMCBvYmogPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZm
ZXJlbmNlcyBbIDAgLy5ub3RkZWYgMTIwL3gveS96IDEyMy8ubm90ZGVmXQo+
PiBlbmRvYmoKNjIgMCBvYmogPDwKL0xlbmd0aDEgNzU2Ci9MZW5ndGgyIDEy
MTQKL0xlbmd0aDMgNTMyCi9MZW5ndGggMTc3MSAgICAgIAovRmlsdGVyIC9G
bGF0ZURlY29kZQo+PgpzdHJlYW0KeNrtUmlYU1caBpUi0coqskg5gMhSIAkk
IMu0BiFssoVdKhCSmxB7cy9cEiBsFcMiFR1QsILCSGmR5fFRQTZJR5BFB1lH
2QRSpw7gIFPAihRQmAvWmWfoz+mvPnPP/XG+733Pe97znmOo5+NnTmOjkRAd
RQTmZAuyHTjiyaACsgWJ5EgwNDyCQUwBD0WcmALIDpBtbS0BHYrEJ/hvR6Xa
kSwJhuAIGi3CeNwoATA+YrJBsgE0PoTxWEwEeDIFURAf12AxYeCHsniQQGQB
aDAMGBsrYgEDioWwOIhtQSCTAZvHEoBIiMtDCMQNR24IBwU279psYfR7KA7C
YnFTwHjTpgnATbJRBBYBNsQhEL1QfDcI9/Jb2NoqThfCsBeTvyGP5/QrlMnn
waJfcJQfLRRAGPBE2RCGbKUGQe+seUJsnpC/FXUTMGEei4ZwYQiQ3rV4sXRe
AsT24QlYUYDDhGOhzT6EsLeawIPbtEB08Q1m0Hw+3rzRTciHyUME/qLof4tu
cDdr8n9qPBuMlwBCSXi4ZJyIj/ez41u2ckZYKJuHcIEl1RowMYwpIpBwKUsq
FSSRAQ9hQwkASsD9Ei0QVIAvAXgkKYCDYoSN66TYAiKKQBvNzZpKAkRBPLpZ
//pMjo5oQpK5FYUMzC1xJtmKRAG21tSU/2KyhBgGIYLNF4NH877m8PAgISgB
YhFGh1CWffqJr+ozK1Ody/qr5ExlHbkNuV61LY++2yUeyZOFy7s8YkylNcEr
1UWqe6bkpnTj32jHfilJ9u2hz6XF5F4aXJuKi5gqSmzSDn5Z5CmajNZfEr9Q
bK5//GqWKuv9V+nDyvyQbzqK5ztflPoYO/lPy4/rybSGxt1uvZxubRNML4ID
sjJqDlrpMZQuxVSepmRNxCvln98x0SdOPZG1s/HjsQVUIlRZKdt59cLaZ0t7
/6jMkuhaMX4wVWNMfzpb8U2WkuKt9fYHNw5fBlw/DEzJPdnJ6HITl6hm3ihO
1HIOH5jf1+t82jNuzqxJEqz31tD6uLR0+eb60XXDxilPeZey5OtqT8fKnnUV
LCgeaBgc9vdND9dt0NeJz6+IEMKrtdPR7oyvD7i2uaq0jf3zscb5oMTqa4MB
/zDJ0VJMKT8kn8ZdREy4B8Ud+xdatse5n0scHbk+neQmXkR/GDAyqBq5ax1l
ttqgraOiJ+v0qHiEVhmzpNNo2tmTFpLV02dS3dZ9MezF4BDzFaPz6X3vkpH+
jlphgG8p9nSNPLONQot7dpCjVp9ht59kF5aWY+F8DP75TRFnHDHKkx3az7Af
HTvXSJx5Nfz2tY2BuEV01DmqX8TOzC4tfFwfWk7vK2hgp3rMijNgo4q5fUl2
UcgTlv9aQezfDFot2u8EXnt+t3G5wdeleLhIYBv1E5ryocufypXm05BI7mSv
ZVzmt67HGvRlGZ+t2ieX7tF+iTjd81K/+HDnlZtyoUPnH1w2SH7JW0okj6cp
eggfHCZI3vZ2Ojn0P9eI6YmpIrGrpafNjjIszYxWztA6s382WlX88sZJ/T4H
XVrL7UBZzd2qxmKNoIfLt6YHqg4w903yPxcdcj0Z8GrqE9P9Z4NaU/RsTDrF
bmv32ugobd9HMrQ/2H6vy5XszSOS4o+9XVq1UglOBeU5S4mPciMOp5uz2sM0
jTL1J/RzNKontnmOMh3GdynlFowRxu0cdtdVh6S4yWbPpBmU2AIzSeKpkqZa
1YrlyKWsYhv37xmX+wOs5r6KcXztcp0YIryTStmhqRxReKuou9umw9ew0Enj
gkejOpwbZ6s0NqLlqh50qQUb81pVubpdqhH24ImCsF59nK5NNNzh6ZjGJZEH
L/q7TNSh82WRUHu13NHKRoNuVaS55JNu19mZxcxJ50Cu9M2492MP/++qJvtU
7vttX887FaUQwrnzAdKrlS/Za6ZJWynsa5jmW2WrLjWOFyh/e+hsr03VJWhi
JtylG/NyVu6htzffn/hiWn/9z0PqFPkem8k6g1D31LPbA7O7VqZrMialtCuT
0jUpqYIuck6lKDT2hTfduLbGeKmzcNwhz/+ufU1nRmfmsO2FU4MB5l5RCxy9
hr+na15XSqlous9XLr6HZU64ptTqzZnCP5bnXFHIDPcukqm2Cr16hirzQRK4
ou3kRelwORHc3Lt4MXdgTutT+I7x4Z8y5s9IIurqTiQnnJRXee6wxoPtd38U
2Ctg/0VjsXTZkaREzdWLWJr7OlXtCz+dlQWOTM2e+V2DF6RtOTcNm28XUpB+
d1+1F4PnfId1z+i2yL0hnDQhDSh86DWgK98V9lqVajda4X1tm8OPYWcLqC75
wjazZ+js3Wr5/rVWAul//P4v8PsQYMEQExOgfCb2OeFfbyWy6WVuZHN0cmVh
bQplbmRvYmoKNjMgMCBvYmogPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5
cGUxCi9FbmNvZGluZyA5NiAwIFIKL0ZpcnN0Q2hhciA0OQovTGFzdENoYXIg
NTAKL1dpZHRocyA5NyAwIFIKL0Jhc2VGb250IC9HUVhSQVArQ01SNQovRm9u
dERlc2NyaXB0b3IgNjEgMCBSCj4+IGVuZG9iago2MSAwIG9iaiA8PAovQXNj
ZW50IDY5NAovQ2FwSGVpZ2h0IDY4MAovRGVzY2VudCAtMTk0Ci9Gb250TmFt
ZSAvR1FYUkFQK0NNUjUKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDg5Ci9YSGVp
Z2h0IDQzMQovRm9udEJCb3ggWy0zNDEgLTI1MCAxMzA0IDk2NV0KL0ZsYWdz
IDQKL0NoYXJTZXQgKC9vbmUvdHdvKQovRm9udEZpbGUgNjIgMCBSCj4+IGVu
ZG9iago5NyAwIG9iagpbNjgxIDY4MSBdCmVuZG9iago5NiAwIG9iaiA8PAov
VHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMCAvLm5vdGRlZiA0OS9v
bmUvdHdvIDUxLy5ub3RkZWZdCj4+IGVuZG9iago1OSAwIG9iaiA8PAovTGVu
Z3RoMSA4ODYKL0xlbmd0aDIgMzU2NAovTGVuZ3RoMyA1MzIKL0xlbmd0aCA0
MTkyICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42u2S
eTxU/dvHK1tIslPUYezFzGDs2yBMBiOV3IhhDoYxwxiMLCFZC0XKWCZbImtl
i7JmSWVfIyS7UpaiLD91P/fd77l/fz7PX8/rOef88X1fy+d8znUdCVGMpRwS
R3IEDUlEihxcHq4O6JuaolSAvSMMxiYhoU8GsRQ8iWiApYDqAFxNTRk440MA
FBQBmIo6QnHvYZMA9Eme/mS8iysFkNaX+VmkAiA9QDLeCUsETLEUV9BjT8MJ
SwAsSU54kOIvDyAJBODszw5v4CzoDZJ9QZw8GxwO4PBOFMARdMET2aA/LaGI
ziRA5c8wzsfzr5QvSPbeMwVI/7IpA+yZxJGIBH8ABzqzQc1Ie28D97z8b9j6
p7ihD4FghvX4Kf9zUP+RxnrgCf7/VUDy8PShgGTAlIQDycR/llqBf3ozBXF4
H49/ZlEULAHvhCS6EEBADq4kD1P6M473NsRTQRwGT3FyBZyxBG/wVxwk4v7p
ZG98v3xA/zDHoND6J/9c7K8cBosnUs75e4IA7HfxL4b/5r0RkfFUwAYmD4PB
9wr37r9Odv9412miEwmHJ7oACghlAEsmY/3ZYHtSCggEEAAH8EQcSAVA6p5h
qDyRRNlrAfYGEwQ4k8hsP7eqjACgyJ+hP0kZgOr9JlUAavCb1ADo6b9JBQZA
DX+TAgA1/k17fWZ/k6oiALX8m+AKe43Uf0M4APX/N9wTuvwL/3OienokagAM
kFNA7H0gXAUOqCBgQf+tzMmHTAaJlF+/7N5W/mJn/N4iQZAKOrEND5CcNMLd
7lRE5Aefzu4qYJLxFk7JC3/1/NqTFA35xXca3H3kys5z4PEVrmtcbviHR5I/
mhRBcc6ICaEKZGBrgCX02hBXKwevTCbNkmXZadH20oE2eksjp0d69OzwiQ+e
lSeXRyDr477PmUrQ83CVLKGPMYz5gwPbq8HuV15PDLPfxUGmk9ns6DXo2+CF
ufGEju9LRqRs0nBum4AtbZ1nZ1iocazHfZQjRS2Wbsow6Ks2zq2QMwBRTyvB
l1mM9+rUJ8sXErXrqook3DRBs4LN3EMWtaR8dmwF4/5GRMnDgFJqD7tJjMcV
hn2deDP8hd00mTbzV7YZUQkFF8pqHeZcR8KjCg0QM+VvlBai5hn726kWpsFG
7ht3RJCJTtx2xlymUcSx0bEH90u3czuZGRbouX1qGouPiEfLhOUou/d3pr7/
aPlsEyIsrOBbdiRk/YDagXIwcfVr2ar/HYZ45eqph76N88EnUHJSD+bp2kmX
jfg9ODiYtc3cUi3t2r8875Z5wa3i0z8QGZl7PXEfvX/kfNltrmoL1zYlmWdy
kWEsTXc890MEFy5np+xrD0hXtZ7qKjXCVKmxf/lSKzMqVluEWWrJblHsSrxs
PWc9LfjH5roLo+cNe2HMt3j98UL95tnRJB6DNzv6UrRtTf7AJOno7LMruyEE
6MbjRdTBfhZqwcXOLdNjvNaXmfOTPobz1sw9IlL66IR1pG+lTOAIlyzeIgSz
XzHw6Tnq4l30mNgBjuLhl1e5mnRq25B+628iD3vSWw72xKqTDy5/k4lqUOY9
NZtqlhagMx01H3amlsTYjZyOfnzzjHeO9H7YObUIcd6NxP6KJqm8T1Kwd+/c
+O6UpknEM0kea1H6iqaH+722cDK5b7zl+dW6naNer36g4nr3uPIAn/iqY9Uf
Fwf+iPPYvqi9mUfTi4ck3CtXi1ukrpU/SKf15ApMKAugzp95BhqxQO7ujkVo
62KE4STp7fHY85wbA0539bue54hFb9gMGUSLPJFvfcEt06s9O6fBnaCL9k+N
ux51J/J1Y+l76sTKErNex1LaN6uUzJPRJsJ+xYLVmdwIab9dzn35aZSUPC75
ok2sLeSBWknACNyYK8Ojbd5++FwvGD928Ju8pB4jpayEt8T8ls6XRUxhnsTw
sZo3nGMLeS+G7KwvZ85dQBeWqn43u71PJFLMa+00cSEn8Vo4FPFk4jLmiE/o
oFuyRXaob2FkU92pD3P1/DkMApOt97P6l1nbqGg5RXOrSEcxVvukhijboNTZ
TUuZoGWTN+gTbp47TPhnwza07Pjj097iIdLQN1o1T32FbKkPLj37mvkkZdTl
0gbNShhkrBx5ca/jfpPhvTkvsvmN2MSyPFQEekLuQ4mngENdR3eDxvwrtpGg
kDTrP7zX+oCLKw8HGfE+ZYosiqcw9JwUChvtWN97+oLhdb8hpt5APqIWV9Q9
frphmrxSxqlLLKHJCsf2PbposBiXefrlZudhzRouGPUE49tRpwe3dKOWLmsc
jygsf17cmGYUvWavp/RevXDt5tzhItHS0Nj7blnNaq5X7T/P1LTxpnNmB6pt
9zdDzPokRirUFgdtGgDmU19psw2i4ynpL5UDlZzHn59vUamN1FLw6dk0vT3Z
smq+KC0nCyHaQWW9OkbGSNy2EIYSve+WfCIqFjfJijsH3K/Zq4eULB+fsMc/
n4v4as4yaurGJHjeo33SbVMiQD2R496TJhR7chNqYDXjo9gA7BPR7dQ8muL9
XnFCaYdpNYJHK1+veb/v4o+ZtoA+UQLDBnjQJTdYJVr4wI8oHtvUFeiSpXcG
osxbQSCJ8fjR7Q2O28yvrbGZtfaTkLTlRpqI9LMhXPwcxTBemSunsNro251l
CEQcnFnihJ2EG+yWOIxaPqxj5VQaQizb3XglDcewH+WiQz4IcYqd2zd+X8yv
bTlHqPwShjYhdagVZlAZ3cbiI/Pmi5UIXnM4673imJhKk8al4XdiwwOaaAnR
5UCa1Z2VCKn3WvSZYuuvcawmom0Cbehd+OHvj17dfuGCExj9pK+q0m9nWxEW
SxLgPxcVN+ofKPL2hmJuprB6gg7tpcDl5GAHk17Oljy1IoUjwX6Pz+xITW+a
X3d+yDDHr2ZTBS6HWJrm2u5z7tDSnPhYSU2/3RIXsXoz+KK8912OPHh3a29p
fn7P2q3AIyWEUE994bHCVRGeaDebBdP2yB1uh5GkQQ9m940Mc6c5KYSZxIyZ
u6R7+NM6SaXWhFhLeQdcPfqDoqhK8L0wlWCdwUBGh+c9u80tcTNWZzVQNRle
Xp+4jowmiHcouJwFn+VrUBpouvu7ubvXX3kRu841I+pZEwZ1D46iYrcmStae
Qg+5klM4o9N/jMDedTnolBmHXE14pDPOKnLw2KljIKHTLvv0PKdOaTqlMy3B
RK9GZPzo3MGnOB2teKKr5Dq3SlnPIYxSSmSoIyySW+bkVJsPsxVDGd2j56zM
vNs20yMVrmXSD9EwRmLLzYQv7jMKn+37Dohz63HtNHbyNcw4I1+YjViflPKJ
x0FIHeTtq8PKOYJbucMq8JD1gM1nNG9deHi0lhYKEO4P1jwp1XBh8UTChm1F
hcN3pfGxZQQW9WPY5v2yl+ICPzru3eeES+4OrF33Zytk4ZNJK9avH3urc6h0
wQq4V6G4dYwV+vzbrSgjLcjb99XScivUPcHdS/n4wyYv5OuTsk4PRToX6168
QmrXjYLSEFVaqd4uYcxig+0vj1Vr7Asprv7SVY6RlPWJn6Y5igeSsYaxED/z
Sge0vmNzXybzmza9jtd+XIUWRHgNQTGnOl9PNDn5oqBiaOuRDpVuCOojSoG9
Vf9a7ysw5YamVHOdrsMhO9pl06Tq/geTK0yr2kwDDXVGrOGHt9jv64RMaU3l
S0lZfa33Hysn+21qHWhUa7UXG0NCkjNUSsR0kXUZoZIB8nmpFrgsHqEoiXY2
5ba0PPeE73OyH3el8F9HOQKbcNMQcs4s9pChCSD0rLJAJmtWjvrtD98zb9Wl
n+UfYcttTvfwpDIeNP963mC3d/TUAf4NsZzCMWXD9tdduManxROmTFyt2Iny
gjq5rZC0dt2MnqKcHb5T3vOinCSf9Y7i1toSc15HzpAhY+EP/Qv5kud6tE2X
EmRTMw0vsLn3bykSyumj14JohVtFVk5qrsJn+iubfwQpTKjWNEyllF1ZX2Th
k1qMd8GXEo60uXTzD5FcnV0rnfoZix9p5bpe0B6KEl6VZCjddtVFF5vjxL35
Dy/oIuVQnbGsutJXMZ8L3x1ybt051GU61VifGLZmY6BaMZreFnNW0PZWj4JG
ifCnWY34h/aN5RQmDprXBIVKi0OnWd1eYshVEdbDHL3aI8M2G04hsxSzecPc
JYfg7rmZ1388wWGesHibTjZwTvlVnWQav/qYzrrfZrycB+n1RTA2f+xlwiTX
+WdTiqEGHj1C7mhjxPtuHqTnFSzYRCU4Bhc/mtT8jKh3f5Drn3phPvl6yg6W
Lcbu+9ANLd6jBFamMrYKWXZq7foGTQsVgxoIHKk5wbikidJ+daI1xMPOIMgP
lTV+ujY8UaF2s2bS8GrjqmOTC0p958Qdu5dGMRA6CwJTpfilZUzO5NL49OfH
9dzza3Oj4nyqhiLhfRNuRbyXpubXmoS3PlWk5LgbM8HCyCi3sENvmXb7qna6
eexizpj6JIs9pVco2bJqnZX3vSW6bqh20dFlPslRVHkdy6XWAxoRb4dVrSk1
XT0Rvv9VY1lDQL/clI+B+Vhvs9nlqjkFwF67XUDDr++HVjmfDrsy9cqdWdfr
L7KqR2tBz2a0JQTQHFkSoh5um3ltn16QWz87tuuyy8XDUz1rK9RVdD7n3iQT
YxzUtlzOoQWcKW5kUYi0jguNmwsGl4MrgptibhXlKUd5QU86tzI/n/okR+23
0/F6euVBgHOP26Rtarj1+Q5UbOeG6LRJkI0lJaXowy5ZslUk6KZvr+WtTN5C
pPjhuuF4uPYzZfeGW/qzFLUxJqYuhaGmlHfZgpV13yc3BCvFQ2bi9RSWal81
N4vpDYxmM9Wrez5O5pvYxQg7LHX2Wrda5hJkC2CKlp03T6Eyeh549gLEkd6H
ZA6CxvFKsWAD031eqq6PA54v+opISfh34w9GwNSHLlIObknmPOrvnc4XifMI
eDl6MzxiaVXPYjBre8A6mXmB1cet9A6hPn3l0N2YmK57dTEyXjvIhWtzTW/6
c2JgF6TmlJHK19zGI4RPxO2Ydw0NeN/nrCbosZSUqG5Lk0Cel/OpU4eb3tF8
At1e80cULLmc+SwT990adnLBSCPTwbzSCns6QnuHe+bKi1Db+kMtvDbZUucY
ZqlN4tk8KMTZanGhKvrUfE3KuEUBXXDHJHm2fHEWLzDV3lXyoVp0AznzuUj6
9pPcbjdxKbE3vGJmtOiPvLKNn8ZMxepzvXSmyNk1vls+n3hvHc+kVznb0AUS
FeNync52PYLHh78dVR7U+6Q4KlGHeOE+PODGxN5QCNm5SlNVv2+CBmK1tQF2
jc7DL4OOQo7eDBNTgqU22r8z/jw7E/KWZqZIqW/UkGb7oslwVvU6WZVpafYF
UgNexpARPIq5+5E5aMWJvypaf7vhG/DwG+TYgUmF75zZvFLk1ZV1E9ExvvAv
klCKxt1B2dNbZrgLNo90VWmJgRh+TVlj40TEw3NrNU9yj6+oij5Fw/gfDGcu
f5w+0r9Q0j1w7Aoya4U7aLur2udqBzDCIzjbjCSSWIyYbEKvvGzlsywlPucJ
GS5gfaX2Wrg+qdxMJE64K8uh19gsDPY/vNj+X+D/hIATAcSSKSQPLNmd7V/E
gW60ZW5kc3RyZWFtCmVuZG9iago2MCAwIG9iaiA8PAovVHlwZSAvRm9udAov
U3VidHlwZSAvVHlwZTEKL0VuY29kaW5nIDk4IDAgUgovRmlyc3RDaGFyIDY1
Ci9MYXN0Q2hhciAxMjIKL1dpZHRocyA5OSAwIFIKL0Jhc2VGb250IC9aT1BJ
TEMrQ01NSTcKL0ZvbnREZXNjcmlwdG9yIDU4IDAgUgo+PiBlbmRvYmoKNTgg
MCBvYmogPDwKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2ODMKL0Rlc2NlbnQg
LTE5NAovRm9udE5hbWUgL1pPUElMQytDTU1JNwovSXRhbGljQW5nbGUgLTE0
LjA0Ci9TdGVtViA4MQovWEhlaWdodCA0MzEKL0ZvbnRCQm94IFswIC0yNTAg
MTE3MSA3NTBdCi9GbGFncyA0Ci9DaGFyU2V0ICgvQS9CL0QvRS9GL0gvTi9T
L3gveS96KQovRm9udEZpbGUgNTkgMCBSCj4+IGVuZG9iago5OSAwIG9iagpb
ODU5IDg2MyAwIDkzNCA4MzkgNzI1IDAgOTM2IDAgMCAwIDAgMCA5MDUgMCAw
IDAgMCA3MDEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjQ4IDU3OSA1
NDYgXQplbmRvYmoKOTggMCBvYmogPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZm
ZXJlbmNlcyBbIDAgLy5ub3RkZWYgNjUvQS9CIDY3Ly5ub3RkZWYgNjgvRC9F
L0YgNzEvLm5vdGRlZiA3Mi9IIDczLy5ub3RkZWYgNzgvTiA3OS8ubm90ZGVm
IDgzL1MgODQvLm5vdGRlZiAxMjAveC95L3ogMTIzLy5ub3RkZWZdCj4+IGVu
ZG9iago1MCAwIG9iaiA8PAovTGVuZ3RoMSA3NDQKL0xlbmd0aDIgMTA5MAov
TGVuZ3RoMyA1MzIKL0xlbmd0aCAxNjM2ICAgICAgCi9GaWx0ZXIgL0ZsYXRl
RGVjb2RlCj4+CnN0cmVhbQp42u1SfTiVZxzWGs1bimhqF3lSJsz5MIdxYh0H
Z8XBhcWi1nHe5xxv3nPe43XoyPFRWEVWaeGwxrTmow/TQioKC4mQUsdCVFqX
STEVK/bSunZNf25/7drz/vP8fvf93M/93s/PbIWPnzUHJUKgOyGVWzNpTEfA
5ft5MhmASWMgZmZcEgrkGCF1FcihI2A6ODABJ1IMbCjcztGW4WhDkQCXkEWT
mDhUDlZzLaZJ9oAjgSQmFEgBXyAPhRJKQyjAgR8hxKA8mgY4OA58p09EAF8Y
AckoiNIQJhOgmFAOQqAYkyL0aUfrpCIC2L9qo5Gy11AUJCMoU2A1ZdICUBZR
QopHAxSKELoXQd0FKSf/hqnZ4u6ROO4lkEzLz6T0Bi6QYHj0nwxCIouUQxLw
CRSS0tnUAPjKHB+iWKRkNrpOLsAxIUcqxiGwdqDZ2r1qYxHumAKiPphcGApE
AjwCzvShFJ1thApvxgad78/n8bhWf77qDOgjwKRy/2gZBIy/2DM186+ayojE
FCCIQWMwmBSR+l7vNs26zE0qJFBMSo0Fyw4ISFIQjVDzQVUsEMMEmBSFCgAV
lGM6TUrIqSOACiYWiAgSmX5UJtMG0GXTPeTNn3BxIRQx1nY2wNqGxZimfgjs
WYzYvxGFkSQJpfKZKaGieF2LMCo8CBVQiKg7CSE7aWtm+RdFcW5H2oo1LSKM
VAVJzdXJp1Vs2mAPe/F1sqLVHy4f0UvW24od080Y8jhBR0WsO8vKOcqGGD96
8i29Bh0Di2+z/eYNCweDN7/VmFtfu0hyeM8Dtck9WYXVcNfKsd6oas0Sz4dM
+/xlQylvF93sfDkaFxbfckc9PwtdeT8D2ZR7zvMQ3PBL7/4rE7/yiCOE+mij
YXD2mP6kellt97Ww2zoqh9Rc/twbKqcX2gwLhaivBWHmhJmoA7+yqLyuveq2
5kEz9fXmua6j45lF3+AXxWLWYEvoxuMHXN7pmmxIPf3eC7rRCpVu1W/GIdGr
vZ5qlGdGNS05n2Jrq2Qo1viWfL+o2pnlbHnXv3VXWeC2raYNUQ15ZceC+8Y5
w7Xqpjryqwtrt4tNdO/J2c9dDD72jp0c4J5lV6VW3h1Zf741HulNPaoRsmDH
XOeTe71GanqeOF6KfPLjuXJC24mt8F98xko8lberJGCplSljfEQ/PKEpsEB9
qtF06u1qvM2Ye6pJFthQ6fdUXdb5cPmV4uAevc9+uP914s8nMjobG8+W2ns9
9W1fsMj5ga4reTmtI8CyxNqtYP4zLQNe//K7dRdW9jrUtv8Y5NLim1ldHXbZ
W3m4fmB5fZy3mNwwqdby6LhX9l546TXld/eLvzFOSBjoKmPO03v0XLk2ObeI
VXpo1clEYalwIjGzasrVxnyyN/ZUbN2mPb8bbeZuyhNkB+8uaWDvye/dHKUM
8gtreHd7ErLApirgW/5AdqzOjuw6YpS+P8VHNmqReE5Dbn/XZ56qdzPSEY54
amg81k4LephLq6yp/cn15SHfttt5WUUe7CdRY3pX+5wqhieGlLyyE61pPI2x
GMnYwgHDi9qiyvydu3cm8Ct48ev3jtkGxbNCTz+zuhpBszx63sNT1m/iqC6p
O7Nlo0Zn3PiQCV+/uzhdx+30mjvanAuGrZrXKrbVGPOT1p9aoHWwvfvxfHN1
X7F11nd5eH2Hy4l9qDdvVzlecEvw4Kr+i67kmh8uj6/VjvqyMOujwXzF0t/m
T+hkJXUdV9f6OCtjoMQeNLFwr/iWOe9bhscZGF2TKAFn+/uPCgf19Me7mq0m
d9ZYqQ6p0taH53VKng9kHDtwNrD9eOf2Y2992WZt8qubp3nGxWdZH2X33lC0
m4evSiFZFd66mSN9J2mJOwIWiha7XJHq/0wbH0snrKomP62pNz/IkeyBF7vP
ad3sT8W2bQtzWjO1N8fCbAmwR91/+qRmzsGV6UhWmxHbnQwaGlq6rz9RxOgP
M1vm7IGixk8KClXp/YeTckz3NT9yf6zQlbC7R3cf7Zi6+XmKXfqFI0vOcOM+
KD6fwLvVLuy5Az7JWb3f0TBkl5OmWdrCqZ4to7c+m9obs7T5UtOly4Y5cw29
8PyWZOLjmMKCDenDpj7pvjstbyzaeLjwQ03vVqIvfl1y4YGJVq3Key9d5hnk
17O8DdSlu0cZ/3Ah/wv8JwSEOBSQckIiIMOQPwDamoE1ZW5kc3RyZWFtCmVu
ZG9iago1MSAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEK
L0VuY29kaW5nIDEwMCAwIFIKL0ZpcnN0Q2hhciAxMTIKL0xhc3RDaGFyIDEx
MgovV2lkdGhzIDEwMSAwIFIKL0Jhc2VGb250IC9NVE1HR0MrQ01TTDEwCi9G
b250RGVzY3JpcHRvciA0OSAwIFIKPj4gZW5kb2JqCjQ5IDAgb2JqIDw8Ci9B
c2NlbnQgNjk0Ci9DYXBIZWlnaHQgNjgzCi9EZXNjZW50IC0xOTQKL0ZvbnRO
YW1lIC9NVE1HR0MrQ01TTDEwCi9JdGFsaWNBbmdsZSAtOS40NgovU3RlbVYg
NzkKL1hIZWlnaHQgNDMxCi9Gb250QkJveCBbLTYyIC0yNTAgMTEyMyA3NTBd
Ci9GbGFncyA0Ci9DaGFyU2V0ICgvcCkKL0ZvbnRGaWxlIDUwIDAgUgo+PiBl
bmRvYmoKMTAxIDAgb2JqCls1NTYgXQplbmRvYmoKMTAwIDAgb2JqIDw8Ci9U
eXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWyAwIC8ubm90ZGVmIDExMi9w
IDExMy8ubm90ZGVmXQo+PiBlbmRvYmoKNDcgMCBvYmogPDwKL0xlbmd0aDEg
ODQ4Ci9MZW5ndGgyIDEyODcKL0xlbmd0aDMgNTMyCi9MZW5ndGggMTg5OSAg
ICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeNrtUmlYFFcW
xTCBocGIMoRFkaIJytrdBTQtm8giCtjsooiCRVd1U9BdhdXVCCKrggq0ZCKL
kU1ZRAmoQQgkNiCboCEqBFlU2gAuECKMO47bFBjjN+TnzK/5pt6fuvecd+75
zn1GBr4BFs4wHo644xhpATJAO8CVGxAMsgCQwaIZGbkSCESiOOYGkYgdANra
goCzRACAbIDFsbNk2bE5NCPAFY+OI1BBBAkYu5rMkTiAswghUB6EAVyIjEBE
lAYPEgIBOA9FyDgG4CwUAv5zN8SAPyJGiBgEZtBAEIBRHgmEIwIUozHnHHlg
fBzgvG/DkugPUAxCiClTgDFl0gSgLMI4JowDYIRPY3rj1CyEcvLfMLVQ3F0i
FHpDojn5+ZT+hEMiVBj3OwMXRUtIhAC4OIwQ2ELqFuS9OS4CoxLRQtSDhIQo
zxkTCBHAArRmsKzY7wFU7I7GIrAvSvIiAD4kFCPzfQSDF1qh4ps3wvRw9trA
3Wj2+17nQV8IxcjAuGgEYH1kz9fgx5pKiUBjgRAWg8UCKSJ1PvztWDBsPcbD
YRQTAJZsGwAiCCiORr0gqmID8SCAYjASCyCxlGMmA8NJ6gpARZMA8HGCNrdW
FsAUoZhEPNedb4AAM5raFQ7zEIyKEIH/QCwpqkRIotHU6A89tjXAxBDB/EMV
CyFxxB/IGkrZ92NFyfrNV3+OysUFj423sLQFLGxtKOsgaANwOOyEfyPyJARB
+Zl/jVTgH2o+Si0JQWIRHm14AOfZ74/M/y79dOL6sutVnzJVXnbXTA4rX9za
mFiAwgkB7GI/AwFZ/uuJsfrD7VpRvdqePPtcDaJOR+qdFfq0VKO6PuP4ya1f
JrNbGEMBWnH7MvIWvzVb/atH+66go4VpY8vtWojxY4cMzYefGiZ1qxXDEy7b
yppfyAdUl5n6f2VK1+UMn1IeWfS5VtzIg5/1Hzcm5Xc58qZ/urnJw1dL7J6x
upe/VjX8KfT8Lm0HP6a318zvvnNr/8TYbm34tbpPVktI7G96B+kHjB51BJyM
fZaRuDx+8Eq0slbfwSnpiWd7fVRoLXounSPX2/d3jTGzkzc0621a0T1uFfFK
t9vMO+9vApbc6pPa+406P0be3fztWfDAuwll3YrE2ZNQVGFDjp7bb3t2VV5w
fLFZS5rA8PruaPBM+YV21YELmqCGU/+wa/bLEhXvHqUMS66k/nleY8ThKabW
vYfWPQPXN5SPJ4sU1HSK9vrtaKBJfSD3t0rS1nvyzM5oSxV63g3OitWhQa88
FE9+Ji411pbTp2Knf7lfLGeAP9gkTZ59l5VAfrPyC4VcJ9g+/tJfZg3Kezrx
jrufqa5r/DH1+PqZuu+fpzxsWmTa7sefCc9ZxAGLWKm1Z/WfbWVMBsn0lXPK
8kx6zOk1kNkSk1YrhszB6WyXrOpwg9qtYa0X1+gFZNlSVb/EF9rwpa5uYxd/
u8wypVRD55srLovJpnK6UqqJFBzCIM0xzHbp2pBLhej+5uY8c0+PtChtpSJd
peyRFRphmNMZmy+Xv9Wlf7ON8dUEvSOJU/OPJ5v6Qlt3hzRYR6p/z6WFVDT8
0OTZfM1/6M2ouhzKyg4+drHwZc4aFellE1gRebT9UHySFU89pbqw4pNgg9Fn
Z6wqN1b3yR7XnlgfZpq2ym47lmtU8EXkdcFrecCuU6oHCtndE9qLNvR03OxZ
56BpnaSeaVpVV37vykOVEsN9DZMS57eiNecy3RrYreKXXh7pu67Cjrdv9Jco
LytzKTuivTMy31Wmjzax5CaXamdDsbZV/ba5RMi9s9q5VjOySJ/uSj64bE8t
+TBOO7UNXRpQbvdm1M/HbVrj68DF3t5wyvn6tITTg37HAu3JM1UOne1lT4BK
X4vQrPNXMPX6ksBoB0ZiimmyVb6JXu3mHq9bZhKV9qadQTEH7xRYba959HpA
0exMfUapGuDj5XJcqH/36L7F+ckVwJPALvhlfQSGd9256Kl6S79jStFT2tAp
uvz0ZzG89uFp+69fu+aUdiwJt5mSqdaMPvp0Vq1FnfiJoIWt482W3pnW4Les
1EwTj5wL+2f2zgBPd+ZI3fOhwQe5FUcHx6s7q87J91ybeK1wXzHEsc3+tBR6
Z2l74zZR96Aszfxuaq0Tl9TfVlLpGe16rjElokOmEkdPVXvQtfuJdrzGzaNR
kbvTjtiz6Qf1wnfvFcqTdKVt5626N8sab43FBPFt/165pHupaahL2PLedQbK
d4bTYvflvCnXdfPczHWZjLSVm11/dTy7xlhh2jedlT4tV9N5vCLY7erBxp7J
LYyNK6vTM82vuR/7VsaNLM6fWp58z5DRy62sN4jcVbSlb/KNNdmmmCP467uc
YrUZRaXx2qtnBoN2jo6FVCod6c/ao79qy7qNQ/ITwTH7FE7RNYvdepsyzX7Z
73Decenqmy2qyrhOH7va1ef2uF7R9tkC/y6R4V582QSnQKHo80wVQRFfUzza
f0jx8t71+29b70yvb89lXhkbVWb9hx/t/wL/EwI8IQIRJC6CiCjavwBYB/A5
ZW5kc3RyZWFtCmVuZG9iago0OCAwIG9iaiA8PAovVHlwZSAvRm9udAovU3Vi
dHlwZSAvVHlwZTEKL0VuY29kaW5nIDEwMiAwIFIKL0ZpcnN0Q2hhciAwCi9M
YXN0Q2hhciA4MQovV2lkdGhzIDEwMyAwIFIKL0Jhc2VGb250IC9JQUtHTUgr
Q01TWTEwCi9Gb250RGVzY3JpcHRvciA0NiAwIFIKPj4gZW5kb2JqCjQ2IDAg
b2JqIDw8Ci9Bc2NlbnQgNzUwCi9DYXBIZWlnaHQgNjgzCi9EZXNjZW50IC0x
OTQKL0ZvbnROYW1lIC9JQUtHTUgrQ01TWTEwCi9JdGFsaWNBbmdsZSAtMTQu
MDM1Ci9TdGVtViA4NQovWEhlaWdodCA0MzEKL0ZvbnRCQm94IFstMjkgLTk2
MCAxMTE2IDc3NV0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9taW51cy9wZXJpb2Rj
ZW50ZXJlZC9tdWx0aXBseS9uZWdhdGlvbnNsYXNoL1AvUSkKL0ZvbnRGaWxl
IDQ3IDAgUgo+PiBlbmRvYmoKMTAzIDAgb2JqCls3NzggMjc4IDc3OCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgNjk2IDgxNyBdCmVuZG9iagoxMDIgMCBvYmogPDwK
L1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbIDAgL21pbnVzL3Blcmlv
ZGNlbnRlcmVkL211bHRpcGx5IDMvLm5vdGRlZiA1NC9uZWdhdGlvbnNsYXNo
IDU1Ly5ub3RkZWYgODAvUC9RIDgyLy5ub3RkZWZdCj4+IGVuZG9iago0NCAw
IG9iaiA8PAovTGVuZ3RoMSAxMDkwCi9MZW5ndGgyIDU1NjEKL0xlbmd0aDMg
NTMyCi9MZW5ndGggNjI2OSAgICAgIAovRmlsdGVyIC9GbGF0ZURlY29kZQo+
PgpzdHJlYW0KeNrtk2c8XG337/UwQUS0qKOLNkaviR4lBiF6yWAwDBNjtOhd
ohOC6C16EL3XED1C9BYtiF6iO3Pn+T937vM8L895dT5n7/1if69rrd/67XWt
zc6spcMnZ4W0gCkjHdF8YH6wJFBBQ94ALAAE8wsIyAPY2RVQMCgajnRUhKJh
kkCwhIQgUBlmgXnBPJIiwpICogB2oALyhQcKbmOLBnIpPPgrSAwo5wBDwS2h
jkANKNoW5oDRsIQigDpISzgM7cEPlEMggE//ynAGPoU5w1CuMCt+ABgMtIJb
ooEWMBu4IwD0lydVR2skUOxfy1YuL/695QpDOWNMAbl+23wAxJi0QjoiPIBW
MGsACILEVINhvPzfsPWf4souCAQE6vCX/O9O/dc+1AGO8PifCKTDCxc0DAXU
QFrBUI7/GaoP+5c5eSTiv8qooqEIuKWcow0CBhT41xLcWRnuDrPSgqMtbYHW
UIQz7Pc6zNHqPy1gGvfbAOixkZKuoibP/5zp700tKNwRrevx4m/Zv6J/M/gP
Y7qDgrsDjQUw7QVjAjH3v99M/6OYkqMl0gruaAMUFBEFQlEoqAcAMz0YEgF6
goFwRyuYOxDmjnEM4ndEojEpQExLvIHWSBTgrwMVlgCCkI6wvxZ/s6gIECT3
h0SBIPk/JAYEKfwhcSBI8Q9hdJT+JjFBIEjlDwkBQap/CJMH+UOYPM2/SRwT
qfOHMNX1/ibM9ICgfwijYvGHMCqWfxNYAPMR8H8gRsfuH4gRsv+DYIzXF/9A
TDD6H4ip4/oPxBRy+4OCAkCQ+z8QDAR5/AMxyi9/43/Ph7w80t2TTwhzpnyC
IgJ/lRUGSgiLev9vkZYuKBTMEf3778OM2b/ZGo4ZShjMHWYJmPqGtJQKsntb
E1Loo5QzUoTPjS1vUxsD+dj2tfl24GQsNiK/T92Je77S4Lw45R7pGv4ak9sl
nfPrJi/tQeVdf6eYpPHrNdfnaykv6+kMDlI0PFZfsPwK3LrTWDN29FMEW3N0
vr/wjWFud9rep60sLS5F3fVbs8xY7cauVe3vgkTFDJRTEM9Cgys5hJifkiU5
FYYJh865kb2Jw5sbDvSxCyWs45nZRza5kJ/nEGbGX5tjnVkShIc704ZNoG+T
TG/TPQrwrl+oEuOTEOkIWU5fL8moKawe0gCV0bWtGi3yXCoruLvVn5iwLjdU
MZ4vK859LqaT7m+DBsRMyvTonY23XPfT8JUvJ789sBojbL6FhOWR+rz53BsZ
lFK5AcQfzqEqGYy9eapWirKowNXuJm0Yia4afDa6DD/5IdrLa0hFsLTa82j+
UU7fKOqTF6JVoQa5Umfj/WEnKy5MPvLWdcURFl2R7ctSh5kVQSeIR+q56mRW
FtchfzgXPluTn9z+GmRIVqcrA/ATnuJSx4nFn5EQ4PDxREEoOtjvLlaU0OtX
McBEZtdh63x+yV08h9jeiND5cum1gQXNGu3kO6QhX9BE+8xuMrZuC1jBC5Xw
nLaX+dZ495vvkB52y2SDw7NCAB8hXA2ffvDN0CusAiU/L8S5EUXzy7f9asb9
NHXbIm3DTYDNOCrqFW49i1bSrdRnOT4QwzLudNEa4YzstncVx0cKDyG7PWaP
kgS2CM18kC0c1iVGEhF8B1wE3MMZfXp6EgDKQC+15J9ispPOw7v8bOGKffeU
498HGGqMwHk0WpmougZ/5sd1kSpetfzCI7tL06Sjb3zACV7/5eQhXOpk1Cll
KupRG/RZVnltUBowSfrlRI+jAiI0PO1YGWDapXhuQeRAGOMyRjDNMWm2wy/R
XVuHVtDWI4nOySt4oQ+zUyz/tKMOuRbyC3CbejziV9aXp9a9mRuRWzAmSyid
XNPFXvMkXvWeqMDbxk6VB8MHPCwhBwrvEsYiyNQakZTNqbrSOA1ZG3VEBIdJ
60Qr3+S/wHP1/Bc7Y9B59Hfx5QfErlO0OZsliEivbhIA2+A1Q1FFXuCSUtJe
a05NBzZdEGfQXTLghEMapbJKuA9+cZFShMn62xxOWxPeE+9l+5F7maZVdNi6
RJaU6Q8vasnt1lgZpVXYJLM3TPdgyfEL9CSbENVnjztMueKXzdgUzJ9lf0Ns
XO0W5pKK186yT0Rx58/zRdA0n+XE9HNW+OhzR5aP6Jnjf3caJucXe6F6W8Jk
xAkr8L3nbEDp+wpTzf6anb0vP6b0zTeM7RO0vW2NoluybHVCPWLx03PBHsTC
5QuiBQHGbsiiXSpQNqTCK3lv+3zAFSzXSF1oP9xLjqbgU+JlJuGJ5UwL61Lo
OE10Es83VzoXFoyk7PUWH7qS+EKbptMeISyyjZvHrNpEZ9xHmE0AUBzuysWd
ST+lsvKo5Hj1tiUTJ2gIR0rDLJbeRhvtv8OB0kORIFY+/qoofXnVd3y/ajiD
VzzM4SONL/ZLD9H4dYaPY+WjfOc6S8ftVA+wqvd3DR+neeikD8H6Sv2rCBZl
yYO/WT0VOwwNGMqN1wGe3Ypu3F2s26SoQg3O3eoP1P1eAppJcbfEexPWmdKg
DaZvOGAvwraiEVgMp07Qku9TwiaN9rDMBUYzaX+ew4X6ete3PFYkEA72O+uf
2a2txO0S8GDrPiLqfkaWX56dSgf5Iu3Gvj7H2da5FsBz5s/MR/1q02reCWKo
8HrKb7HiZpxxKTFuG1aicj3dKXFJmzaK5TLRh92vt1KAT6N7fYe/seIti8re
SuPr5TevZaOLiGtujeP22kpSVseW9tNAbJNfmUmp9N5euOpK22v0GXSIn+6Y
20ioFmL9rL2miwuqah0TCoh8+G7+wloG19SBQxkndJk4+mZbpUB3gtTl1E9k
OI8504tbhmKU+3Xmexfj/eTwhlsEI2xd5QGw9oHbMvE9X82BZ2uZH1wTtpsC
NTI76Rs9KCgTfX01fo7FvQ9mstOawKbrm6qzv7BB9SX1JdyMUIYSai96sZZ+
GNiqEH8mUOnkZ01rqOjtXW1yg/WrpFuPcKrBTlstlj6CUWZW77tieTJrqLYD
KDdpeF3IICy73f4I2b0E9ZxvdSImDzNixVaDOUeOyLg19yE4VAsgzYpeJqwP
QA7NtN93voJiDmL0MiMnTxK80+DZlFkHLUIhB8WfJmEQfhzf90J7WD0/qAmY
ktKb2+8bmq2FBHxSs+sANdd00NTxN/BANYET4ZbjekIt7n1qa9m6vJU5w0+z
qGq8K79vCXljpWm9L8gU48wkTSy8CX0wCSRkfNYn/chGvJSwNTP4IxWZQ4zc
i4WUJvgRwTeFa/n66pwjYt3S1po5M9YfJAuU4sly5sQXPOG1J2cHqTjmXY4G
Mtrqk8KDPe8kCey38hq0I68R5huxLFjzPn2LednuH1zLdjdvzAIHjihWZ+ev
r1yfl0TlrHsJp6ezyF5L2r90SLQ9nBxz2ZzldkuOQEZ36qwMa1/X41SFNvp/
+VXnZRVMXXt1IqzeGSYmVDNQeLJ21NOHN85UEVumcOLcBTz9MvfdaWvBdcK1
Sje3z/TxJWgHtTErqm8g+/oN+alk3IFilqu/i0C/pLJwgP27kxomrIIgEgDP
p84JmBngqqbOQ/VhceAWxTuzl7rj1YxnDfoPlEU9tEbmfzzWO6SMF42QDd45
Iq9G6oagg5w2SDa7L/p5vmgnBLAvjXutr9/4uPJQv5MrOpEMchDuEjq8QD2N
5PjYydzcTrJ+++P3cfrd3VZh+Fkyo5u9HUuJtxcqzew9wnJjFlfqTFb3XPV4
9RPRa+IfxRO0KmexafLzeGA0Aw7e1cBBIZO2BpX53lUWPI1JXs1WaPzeHbgy
D7mwk3mnUvhDxqQls8/p8jGDj+ppQClSZkC/Y+dwceeMVUkDGMGXy3h8T0JX
HFu3/Iy3rjNdlFUz6Qq997e6N7LcGMlCOs1cSAOxyc7RzzavjfCd791bB/OU
yyEARQ5+rOoTNazBZV+sq/1ezg/4kHwVQQZCuFzL7OdXB9RjdV0XcREtNW4S
tASMftcGPgnX54vADqotanpI3XjRi12hioB+LkPFZ8mBpQl0QfnsvHE8eq1M
lTUuRLreSWFuQSvEuR9pyRNnL+II8ttGgxgcwlSkR10eSUmnx0w8eUIzcmNQ
bs3+xYA2bH+a2uL7mvNriTvNVTrEjpKODs9t3VC5uSJi/rBp5VuAFN3AfZrm
sMg7iTKSgLDdBMNnokmpOrQBZKdkNTIVLiZOMKCMJJ3L12k70tLAqLKnpBH0
lQfXZvhYN98muFdtblS9aXEkTe/akxvQLWBdNaEelW+qNja7P+oNOirVbn7u
My+0iqObPmbfepl3sYXr01xrSVlIuUJ2z3vl2UQvP7q27pM/e50xrgKv9Hvw
VYb6m0zDd57trAqvbUwrakwYA9J/+aUzcrSRfHMWmyzXrKQZ0LM40ULsxPFy
FPeG7fCIcovsazK8T+9KCJinuX6/vJjtW+7zuYDlhA3WKxfiGf28MXCdxvjk
wfGouG9E9xtfxEnDRFJ31Xgtyr14ywd7hZ5FYUIq9W174XRvYVBtf7HTRPBU
ycecxJN2Q5r4MpkJWPqEbSEED3yJG+zs822JdOcX6OzJUOyblucWjZqjdSfg
3ceIlvfJtMv3m0e3lEVZwA1kDu24IZBVTfFt9vtk5WQ2uSI1ytjpfXe11K3L
+SiinK/dCkaVnbv0AW87SC6FbRyjXkW8XUcMdQuoaC/QfyUiNEeETTNIBHvr
WD8rMuEtOiQnJvzJgBDY3txZXEJaa5lWP7wdBs0qslVCV2gufinwqb+4Sx3x
vHoUQTUBp0rrb5WE1zcnkn4ePs9aylLTwjKIzfXm/aoDvpG+ah8+EOapEp+y
maYOoMcXCjecuNs+Zcx8WjG3bXbMeYnA85DPeq2keQYmUhTYGRzSqhIFlrqW
PS04HxhM7GSjSVm3OUxT4RyZykkKXMRnV11nf0r8Tvds4Boadoo7+G14mjvC
kM6mciNpec5bq6TH2kKHPIkfmBcIV8x6+bWjM2ROikHwSDlSSWpToxfrMVTx
uyvXo5+diujKICe+nijOR1uos73lep7b8nzkGwL3e3y4LkTK49g8ChcaSKco
P8BxvNkb9TewZwFu+VasKxzxGrE+ELtqBjFd23CG4+rPUbKmaZzFrfttlNv5
3M6hN1jX6IQ3IhdROPOV06ofY5yR7uLO91JOB/YTlk5IV/PChh6W7WY9QQC9
TExML02wRg5pjTaVwDQ5Sx4PrKUs6K7tSfocb5savTIvYQy22Iu0FfPTPl0a
pdzbz/q+Zr3spO1FChBiPk0X1sVWnTCyIF5l5/AfSfI71OE7abuYc/LEZeDf
fP0EEJx05yRpsodVbdm3OQkB3aWxYgEr8vRrHaiOvblG8tRxOgAA+d1RfXBb
72mf5/T1W8HtUmupbW9nsKlbBEvxb32f9+f6OPM8v8B1vQ/cY+ZE4nzV4sUA
mv2xqXt9eZPOuJ02a+rf95InIsf5o55clYmf27IjJXNYxPFO1mn+jbRZW0ZW
VODQ8Rnw2XjTQ6Eht71Dg2h30lKiLglD+uPAURppIvRRu3GFIevwpqnGiQm+
T0M1POqUJXMCZmu+YTgalbZS7oTdbRFfn6Z31+jpku0w+z1aWVX9k7M4taDA
SxLluqYiQFtw7DagTRLPYVt5dU+ep2n6g1DJTGhVftgdmUe5LB3iKnMxOgX6
Wy4Nnsk5geCf8413T6n47oZ2HbQLJPc2xvhMbu9HGQnwcpuzHkuT5UMimfuq
p1UHTgGqZeR6nBTn/R7e070DnWtLrCVVmnwG3cX5AX2gzZYMksRHXB06vIMU
yRTWCjXb5WlLp6fLwEYQzmXUOTRzMLg9pEwZKuYkWjSDtyow/VEWFbbcfpl5
u+ns1642NrmQfIYWM3RLn4wWV0lX+K65rnDVreHWUyvit2ZNuaEhvJU+Uwff
DFkpCajLbgAh7trEe3FOLyDTpOKQ1NXnDuxbSGmCQsuTo1LvoBGF5/sXqlAp
Jd2sTc0L37qI/vsRWuHvSqmh+oBJvIpewHlGY10Djul34i49tuOQQgLmULtW
eIwstoofCtRkIn+7Ii3pe8+F82Or+Ae4jBmr5y8qPrC+NCoM82ReN/d6E8DZ
IzVEeerYYn67m1sqZ76+W7yyZXhIvJbDEmuvh8J375qAGknethqkfwx8FRvD
snUJYFhaRqB6bj30glcstx01keP+iHHQhvTP7sNeJo6RaPgzpprV6civyywN
lRI/JKrV2b3wzpKIMwLNYjni/dz0lbLD2eSghas/LqyiJUyj5GKIJzPXQMDf
P9XufXs1NAiuOZprVuSYSa9g8ThglzvjncndWmyIPE5VhPD0PG8YFAzCK2FM
0eHD/7GScjrxEBv6YCeIpc01eNqpiiTpczE5tOLJJZY0WnFF32ym0+NBeLwt
rvWZYn9OKLXIRXGJRoTUe5wP548XFx6YPqrUMnTmCVeBD6nlZG17HF8H3d4d
jqNviKXhYNmHJjGwbxPqtn1pBEfTizLoL9oY7ij6VFvGM5PATsy+/lQjjKBL
G1HVsb6uA9sPxE+e8pfvbPHK2X00Wi3jVtfcFnZ2F/kSFktcnP8Cn8rMOflx
e8dDPA3kkjo+E9FJs+AEU5HtKyUBCvQL013/t3KVOVuj+YRl+ymWLlTbQ0km
u80WxwMwy1by0kSP3MaE56Yu19qobRJIiOhFl4vw9KWiVb4Dcy1pwoSvEgcR
mSOLolGGmDrDrC9vK6Drzm0jY+7XsmAejurctYxG5tSQ1PS8vQGTIat8Kl2v
Dd5xhsqA4gtZLORdiG/ioCh1c5FNS+RqEzfC8NotiP5WWRiblLCGL3sa1wYV
gcsp/YtiblGawwj/zR1BWT/1b7IcjVy5iBhKEyOCd7O9nk/Z+o6/kGr1ofwK
v2n75bjOvXrc73uK258awhjmmDa8gCdxyebpRkTg5bLHtHpBE7gCyHSKOOV6
FWoEfoKg9OpJ3ifheAe9SfweJsFX/wnxIWAl4XuNPoXE6gLZ9plgCCrPDSqu
lmmMu1a2c1YpwqvkhmfWmOXuyXaJPwMfTyY2fY2FSC5E+C/OZTxZ3Fn+EB4k
fAdbPS+8jfocUXQk/U72SYr9cMyr3IEnNJJC94ar4jRkK8KobPGVDdX0Tebi
vOSNLzwiL6PFVUkzVu9FObRGYFdrd2RJ8gseX9a83neX4U3jiKAPvIJ8NVC6
PKw25mJMh5asaawmmuJyW9tYZwFSMyXqpYa+cZtm8/buozMFmDQWM8KWX0JZ
XUyiZIQkpr4DlL+NF+zQ8vXMz5uOKFUv0ztTjMu24jUn1xUG7+k1H34/oaj5
ecankyZ4ySwldEABfbQtNGt88MvTcZpcmmPjkPFQQXpg4IZyOJkvFuqlUtn8
Q0Rwi3y2QZ96atdTGPcDjh3x514gkE3RjXEr1iNJ2BELuIUvRtC1yZJchyC8
Zb6vih/Gmy7YJGZA7xk0XIk/do+5ff3A9Eizn5GOhUPfXFVQvdpbXSFSrGEc
OGHBtVbVpay9USDKtVrXp69MnmivHUvzrmzhzs70/kymn2J8/+fP/B0l8seF
dIN4zapYQx5UHmgH41tZF4IBWAvnDqz2ufcYSETDD2JnoSagyow39Da3n3ta
qYlGakkYTstbC/ctjO0F02dLby2zGLRaqz8WN8rdz1O3evjcYIHjEEW00MMl
DwpXZXOMasuS7TGZsvn2dlmyc2Zy7tLBt6+2Yp284upykSlGuF1J12KMaYr5
4TJN+9ZkpgFN2LcI+1/+vdjEMiz1KzeEDpRPJ+KADfp1qxXVuypK7i+b5gZj
n5DB7YxqGHLQMiqe52Jt4PMDpMuu63aVu2zqqySV/FykWaXPmW0EUcRYm8rX
Z8vXwZx4C5NPZm4K02/n7ttZW6ZVD1B558rfrxDmJfFa7D0jFofu3yl9Vvy5
xYtcjgd/VbZkl1Zv4zg+SKsrz49/QZwPCai/I9kkcNOhfbW6PfRG9Zdx/pPG
Wnq+M4CbUEcFL0XIZmuiiJM57RE6Xe4y8/hHGuN9Nnzen7fsLl3HCpKwHO8U
KW8ItjExxdmQoMncWLnNeB7Si0/Yfsge6yDxiJtsYBeDJ5Sm7xfgxma/62Xu
rUQYztxT0G6Q+XHAafBpGMtbIqo5y2SWKq9HYKHlwdaPl07wq2/USYuja6pY
/Eb4KwIr6MeQLuHUmQHt0Jy+6E7mOjir30PfkA/W1TnsWZqClCRKXp+4QAVY
bwXEGMZqsB9lcx/AwQbvPgi8J6JqRczxTW2bwdwXUAoNiUzdDTnpbHeOpbS2
et4S4UFI6uNxqkQk1MgmIQsK0fKOhSDhIDE6iYhJk1T4j2DQYjm1PO6MS6Oc
yYNzDVhsUvwKLu1Twdy556+aqxKnsb4yzvWyC1T86pMjl1jq5glykRX4P7wA
/1/g/wkBSwQMikIjHaAoe8D/Anjylz5lbmRzdHJlYW0KZW5kb2JqCjQ1IDAg
b2JqIDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRW5jb2Rpbmcg
MTA0IDAgUgovRmlyc3RDaGFyIDQ5Ci9MYXN0Q2hhciAxMjIKL1dpZHRocyAx
MDUgMCBSCi9CYXNlRm9udCAvR1pFVERPK0NNQlgxMAovRm9udERlc2NyaXB0
b3IgNDMgMCBSCj4+IGVuZG9iago0MyAwIG9iaiA8PAovQXNjZW50IDY5NAov
Q2FwSGVpZ2h0IDY4NgovRGVzY2VudCAtMTk0Ci9Gb250TmFtZSAvR1pFVERP
K0NNQlgxMAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTE0Ci9YSGVpZ2h0IDQ0
NAovRm9udEJCb3ggWy0zMDEgLTI1MCAxMTY0IDk0Nl0KL0ZsYWdzIDQKL0No
YXJTZXQgKC9vbmUvQS9CL0MvRC9FL0gvSS9OL08vUy9WL2EvYi9jL2kvai9r
L3AvdC92L3cveC95L3opCi9Gb250RmlsZSA0NCAwIFIKPj4gZW5kb2JqCjEw
NSAwIG9iagpbNTc1IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDg2
OSA4MTggODMxIDg4MiA3NTYgMCAwIDkwMCA0MzYgMCAwIDAgMCA5MDAgODY0
IDAgMCAwIDYzOSAwIDAgODY5IDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU5IDYz
OSA1MTEgMCAwIDAgMCAwIDMxOSAzNTEgNjA3IDAgMCAwIDAgNjM5IDAgMCAw
IDQ0NyAwIDYwNyA4MzEgNjA3IDYwNyA1MTEgXQplbmRvYmoKMTA0IDAgb2Jq
IDw8Ci9UeXBlIC9FbmNvZGluZwovRGlmZmVyZW5jZXMgWyAwIC8ubm90ZGVm
IDQ5L29uZSA1MC8ubm90ZGVmIDY1L0EvQi9DL0QvRSA3MC8ubm90ZGVmIDcy
L0gvSSA3NC8ubm90ZGVmIDc4L04vTyA4MC8ubm90ZGVmIDgzL1MgODQvLm5v
dGRlZiA4Ni9WIDg3Ly5ub3RkZWYgOTcvYS9iL2MgMTAwLy5ub3RkZWYgMTA1
L2kvai9rIDEwOC8ubm90ZGVmIDExMi9wIDExMy8ubm90ZGVmIDExNi90IDEx
Ny8ubm90ZGVmIDExOC92L3cveC95L3ogMTIzLy5ub3RkZWZdCj4+IGVuZG9i
ago0MSAwIG9iaiA8PAovTGVuZ3RoMSAxMDY4Ci9MZW5ndGgyIDQyNzEKL0xl
bmd0aDMgNTMyCi9MZW5ndGggNDk2NiAgICAgIAovRmlsdGVyIC9GbGF0ZURl
Y29kZQo+PgpzdHJlYW0KeNrtk3k8lG3bx+3Zd7IbZU2MsS8le8m+jxDTmGEY
MxpjC9kjyh6GQsi+ZIns2YmMrMm+lj0S2fJO3c9z13s/f77vX+/nva5/ru9x
Hufv+J3HdZxCAsZmEuqO6DswHTQKKwGSBCkDNA00wCBpAEhSilpISBMDg2AR
aJQWBAtTBoCUlEAAdU8ngLQUACSvLCOrLCdLLQTQRLv7YhBOzliAqKbYzyQF
gLobDIOAQlAAAwjWGeZG0IBCkAAzNBQBw/pKAtSRSIDpzx0eAFOYBwzjBXOU
pAaBAI4IKBZwB+aEQFEDfzrSRcHRAIW/wo6e7v9e8oJhPAimAKIEk2IAgkVH
NArpC3CEwamBhmhCLRjByf+GqX+K63gikYYQt5/yv7r0H+sQNwTS918ZaDd3
TywMAzBAO8IwqH+mWsH+MqeBRv5HGV0sBImAqqOckDCA1F8hhIcOwgfmaIzA
Qp0BcAjSA/YrDkM5/tMCoW2/DAD1jDV1dXXF//U/fy0aQxAorLmv+9+yP7N/
Meg3E7qDQfgAbKQkpaRAhETC++8vu38U00ZB0Y4IFGEg5OQBEAwG4ktNmAwC
yQH8QAAEyhHmA4D5EBwDJVFoLGELgNCSAAAcjaH++TtllQBANAr2M/iL5aQA
QKw3+jeDCOyMgf2RIQ0AwtGemL8DCoTAjd+kCAAa/k2KBDnj3yQLAJr/JnkA
0PJvIgwHEPKbCLagfxOIcHQg7A/8aeEPlAEAnf5AOQAQ8QcSDCH/QIKy228E
EQyi/kBCIfQfSDCM+QMJyh5/IOEA2D+QcALPX/if46Chgfbxk5CTAUhIEzoK
AskoARTkpAL+WyLUE4OBobC/bhphqP7NcARhBGEwHxiUemIMDVUJc0mpeVB4
XztnsIj8ErGGU22cYdWb4Saa0A/xxMi8t3p3L81Ugo+K01joV8hX+L1PuD2i
Gv1N3ulsB9+NSx39seLlsJJ2r44bvJtm4LvsfuEgdJ2hoWZkb0OO2Ghopq8w
yTq389mXrvXnxqJa5p/OTQkQtdp4Vbemh8krgHXSkBYR4ZXCMgKmjKl3CyNl
I6a9GZMSyKbxofddIihfi0/uoBs9mY9yKLMSf9iTOr6zdDjQ20r2pVu8dRTX
f8BcEWRXELXomWWAs44pPbljM8X/FGSD3H2UPiLy9TLWFlfW7P6xbCQj99ah
ESWnbNH1hzcV6BBR9U25AhZEFXHlwoH42unsRmeHW4b7fP05YzzOetfPXkXe
U9mcqx6mj6lvAaTSXgQJc6zTl4umiwme3ZTRC5+IHQvXPi2tDsTxecRV0H92
0XlRHgl/w3jBWHB0+YGE7syrDxt9TyY0Qjup5a8658bd1bJk/HJl0YFKmynK
9U1VkXYioyHhUnU9unn9O9X4ff1dP/ng/ZqvJbox2vLch3P85RYi3xb7femk
wpz0VIXF0Kqk0ty2FnaCYKuoh58kQPCcznG1quIKEbwGLcjt0Criapb+l0mh
fDls7oykkYSdYQyNJoU5PlCWi3tSVdi7NcnLsBTcGb6XsUOp+YOEIXN2gugx
nG6ZJn08uwCDawRlwMeDGbnrLBcpNJ+nJ/Yk3+daupspRfMDDP8y9vF25+3z
XILDtee2c4RGAq8rOK6m91QwPg623S0pPULqQD9Lhds5XVmNqo21D8kMzBYu
tvripxpg6L9IP1y7Ticl18n6uGDiSPaGLOtpweJUBvJ6hupWGlOWeWAvpX0u
lOv901X5OesYUAogML8BZYEf3caUtUqkJXsK8vgRlYKP9rWZU3DcdsTufCEX
HpOynPjDK6GNviXTh0UdUVdaNOpQimBVXnKc2Tk3Z9bHPTW9pn7K2IGAbZ8o
JjN+LWaaWQYIDVB1wnD93VLJkKJsm0aRJmvddupSM2bSa32amuTR2rPq9kf8
EoKvT1cehAJX75BZXA6h166p/9IuFaFRJupivMCBlH9VTfNlMkhWlvyltn3a
R0gbQ3PrfmvNRfYUo5GKLnQZ6z4Vr/2wSRIqK1OA+F4Ow0YBl4XFN0Bvo4pv
qfTJErjTb0Hemj0tfMilxGVGzoSL2dckTxTY0pa8z/ItglasSMLAOCDBRU0t
5PiyZ6FSsgWvfJM4HzOOHt1d4oWdiha5pl9zQcU7cO/B4/U4XpXbAT6DKwJ3
tyy7RX2Fbl4xupgbOrJCj9PQzkTeZ0/stYzpipoyrUlW6TnNGii2VBcd3oFe
eR6fY3aHWQ3jo/1VQwL4ETsh1qIcKtdv2qLVoIruK+ZrHzhUC/QBNdxfZ8fV
Tcy1zdJD+cnNU9/Ull+1FdQx7RAciZoKsFORtmtYRbqy73CMMAkgtM+I8i8H
CA0Uyq6iVDi+7lfBNbdfMGiebhE1ckRr3TQenfo+qhfb3PQ+WyHTRBlNR6z+
Ia2vdm8SXUVpcMNkV/Qkzca8lKUs5NXs+VYqxtsiBqC618B6BVty9eJdl3vF
nhSPPEPwGuxvbvdfq5I1IRKT1L7BWYbdVH0qCQGfQKBJXO3u/doa1Bdy4W01
0kS3yioaOJTGpD7Mfpf0fVP6Y6FJtkNJDYY3uJ5j9C7yDtoU22hatOd7fjBw
esnIfEScQ9ySfENiUd5H4nEfOF2FfbxOY0nZsRdw6xglX9PiUNZp81aZaeQQ
sJ/I6MxGS8mx9A40bIaOLkiI8UsBh9Tj5/03IlMD5VhwkmpBDi6fE8C8POXM
vdDosVHk85dZed2JwoMCfjViqm9D3B1IDMu6ryZfYcatuN8mwpafmPA5Blfu
nT+fJzVTmSjdb0lMGr4aLtfybNvLXGxYd8k9KDGmpEiwiCdlzoqyDU00tn7a
5ypdY8bcYCKWPOBPFxBsyytvR8MAPJroXTGysh4/ET/OEEDHb3HShcwHRfKc
Q73Zu6cSk/Au9HFDesLbEdLz4YJyGPtt/3JOrpVjMtw+Udyx9ZTGuyto+349
Sw2qh332oIVM9qIOch8pG+6DQj+yCy5wA86cMD2NyqbW2Fj1npdFHy4laiZK
t2GmJkObcTJbwmM+qVg1Sa/6kzze6/BE3p7NBTrL6Sg9KZh3s1GWJvw+60MI
1d2WiDrwXtMnw29WivZ8yu2QO/T60qtmt0pYKbs4mdnzC+AD7jqrGYckWnJR
Mxe/Zzy1eltBocPw1k+1fXcTn6eyrfZap/N9xjCP6yV5xvmA8dS1D66R3kbK
lwqgjnHfvJqh6O9xIUa58TN56633svMPPUi/PCFRXoywmJCsFfdX6kytFiwX
08P01sMXK9Vys6btqZ+yFYbIVigFCD1Ul0uu4Drz1Pu2NsNdZdKpwMfxYGNW
2wCRfaGsq7jnVIsDL+18qTj1wdXVy6tZVwd2fAYpvPK39nRnWvHq1SskbbLp
5iyey9lccZugpM5zGRAmj6rjFPuznNo9AVY7rZEfcV3Wi/5TaOEdqrFviKVH
HavfiMq3ekrpLVhdAOxnTERDtqPXtx2b5Uxd+w58sm4x8gwhjmKUMQiuikiu
F2+vbGrq7w462VIDKfo64xhddY2CvWjgbbKFt7gws95CoT3SpJL5AZC4j017
ZgybV1aB4nLbPb0d4Sck+RFTouUiVV1kY0xW+Rr4R2xHpxWvOcJLbBa+UOHM
874VHV+K9Y12CjVfWEyLKzbSheDes3KvbI+mKHuLSH1iNdkdNhdvuAO3S1Av
g5VRdBpYlJuUtZe6UvpS0F4tXuTNvSGjs6Tr3MhFqZRDs5HwMAloFIhbk7JP
7w1Im2KqJfmwzfjZv427sJMoL51Hz1Jr+LxDjfJu6QVSvRS5g0/8L5UrJgYF
RbY4c/ltBA6Ta03q2kisMuus7jkP01MHSKw5IJvX3tS/iJBwOai1f3pydMnt
2vwPs87vMllXbsoE+mz1d4o+bBCLrA8SW9nndl6xzzPhjQG/0TFi7aug6LRb
iXivyaXamb4C1j9p35Tc1WwneXruPtn8uJ7c8dMIAdHzFBFDLHmW67lv7tAJ
HQsELTBDnNteXvcG2k6NiXmN2fCBC7AC6iWGxmzWyxVCV9FOe05gygNBM9+4
MJFjXh8mdfybqYPJ+Z5nXkPhwkqeMpfJS8cxpmBdueLZ9GRhCMwpJB3FvnmQ
8PmpVrX60inTnmTwvid7MA0UfDpg29RyY897czCnteP9JtuKIeuDEbYHjJQp
LqwB+y2PjW/BE0gxeK30JGJYSzv1BP/MmNMWrva2yNp5VXO8MtAWHj5MT/pV
Z7PZ7/DV16bNg0Jeb++k/ri4XZ6PQs8pqpmSEtgkBG0O/C3PWrBhsvt7Gh+T
9Gs+TmcGyd+85AwZ2Zi+Gjt86abnjwBn2Jqd8Bg9iw9+4abdWv2J/EBY00rB
B8TCVotMHEd0aVe5Ajm0fxva1qlbt/ljPxMgbmfp+QLbMddhmyxrWe31A5+f
p+LZbvIcLvf+gP7l2EhGCwpHKz2utNK0si89jxvrffpcnY/6OROCrXjDkIx9
uontA5NzmNMt9UKRR3FMEuJnXKa2d83i6YVC++5P7z7BOXwStckNDptr1x+1
9lXN0Z8cqbeI/05lPVe8UlSSu69XmZYAnAzoA7NE3xft47k2LKGZKUAeu8DM
2zkqVHnsJXWEjT1bAGitN17T4dsZu8F8CvN96BwDvjsY6BEx9CQ7YbKt57UU
JJ6kkK9GBi/h2lygfyA99/27NHMJWSmuHMoTRefWuqWASPWUp96tjlw6ErUU
6PTuSa1m4D982X/HfrntQZqBq+xyYk9BaMtE4rXvAb0PB042aYLLllQvCmA5
Ab67MgFtA+Xpnze44sjir5FswGmvutwU7Yabma+wkxvSfMo35pjqiA7Lm2CM
qNSV+IZn4j7pXS3l4zgtw5nkTXtkqM5i9LhoFrp429himJ5NJNJmeFed5Nyu
Ya4+yn/QmJR5R88MScNLpaibXmKEIME5kRjk075u61tXEaiubiajDNh3PSDe
0R1wXsPXj9btxrI2VZ6MsYZh5llpyDeeMAzmdFFznrZ6FYThLRNb/UyktY2d
rx0YOgUcpQuFGr+b4ljXljU1L1q/GTgofqSjKPi66lt+wf42N4hXM8q6ZFQQ
b/6lkirCT4g+883yO9xVKjwL9rb0m216kD0LzwmVHTKoL7toLNl5Uuf1IBj9
9px4freOlqbDUIJOYemMZuDS8rLJqVG3mHZDNH+NM4XwTWZmA1Hxe8sjL4PB
5iZSPLzRb8m6TcoUtwpezMWfLmDKukvsdsSZZrQsiFCw61uYKM9sZDDHcXD/
Hqd+a4leGm/yW3OaTCzjCRLjV3hJyjZOJhiuhgB8tcvXYauS4cySCamR3b2Q
u7UkM50c85T1tYVBh8zqupOWzLk20Go+ruPRtZVzjOdXaMgQab6Rq460H5jj
NJjARWh9nC39/Qa2zchhvfiXerRZEbUiivKhgWs/+EYK6WyTpPfaEVfG7LhS
+B/ZN5KIZ8Y7GQtfZLh6fJuTYkD2yUabyHZPx+HJwqu5z9wp6xyQ+jV/oXmz
NIxfmq/kRuD06eqjypoe0WEo7f43QeMjm8MAMUe20xmSA6cSD1tcxhKYIvey
4/VFJBu7WZoIrsst5mT1Cw1beVyyi+Lu/F2ye7pKfoY7p/30HqLhgkf5zDRM
oojw+1sPU4q98Gi228SMnpXvZj1jxrlX2Ka12MIZTCJZ2gdyna72GBh8rbsc
EWZy0ei4SV5rCXqo/j2t7iw3mvHcBukYoCIU1hBumsGo5l2TLta4o6Yw9dr6
xCBURFTSH8RZTzzRXRAY6t/dVmElUqDspWAPxLuNlXDZnHhE+RJva0pYKXJk
ZLT7eXVARNr5i3oNzhjVm4mC3l/zgM3xC2uM86y+J2qcJ17usn2VzCqZ4Iio
Jr8dm4WgpA8XRrhf/+7sP958bgJ2WR/jGs0lTEebtvwEJ2r4qbiyPGpy6O5k
tLFH/9cR0lRdKbEBhOAsuUm12wBTznRe4yqY1GgquS1YPXZxIiGimHGzM7V0
4Uhdjop0W/i8vAmD5kftoVuu2U+d1a9RCEusU7FZiC55uGaMM5Pc1Sb/vgRx
gb8zXPgSP9/Nu1OkwC9J6YoJzHZw9Z7VW6+fT7VwT5yGkS0dOF7Uqx3jD8va
R1ZZv4UEeJYpUjJUP4tgXUcBh4HWnfE9iYO+rIfXBSasZkFpsdUVdUPd8med
H3k/hnBEtMmfprIeJG/4tZ4yJaJF64iHqqtr+ryBeoIl6pPe8PR4J6+5KDq1
j3onsy31XXmlLG7u3DI1B5nwy90l2Bm/vDgV6YtWmkHZeA+3gdgGtdnW2Tma
wtE4SnTRYvOoZAbLiAab3Fzl8ogEeTsrTpTzE4fjy85BCpKFnN1o6nMML24G
snheKpsCP15/on3nWekDP1S1olevDSCfTGTKod/bP5EZiiRmeFfLI5vIMzOw
HmRAblulMMYvwUwf2BY8s3TUj8XFpserzl9Rop94fM47lSX1czVtMnXLyNnJ
7R02QG0+7z4FTwUYw9oys7c7/cJ7h0ckNJgxRWRBuO7JjY4P+m3m8oZnSb3O
tzhTIBeeZCYKDnYcmh8Jp4nciXh58eHnlU9XwuXTZUoy/Oc0s4KmiV8J4xN/
YKNEhCImaRyETiLhyw9NFRt0xyW055iy3aozpaJadT/oM/zo/dqA12x3xNav
ebxiQkv9Dx/q/xf4PyEARcIgGCzaDYJxpf4v+3D+qWVuZHN0cmVhbQplbmRv
YmoKNDIgMCBvYmogPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9F
bmNvZGluZyAxMDYgMCBSCi9GaXJzdENoYXIgNDkKL0xhc3RDaGFyIDExNwov
V2lkdGhzIDEwNyAwIFIKL0Jhc2VGb250IC9LUENJSUkrQ01CWDEyCi9Gb250
RGVzY3JpcHRvciA0MCAwIFIKPj4gZW5kb2JqCjQwIDAgb2JqIDw8Ci9Bc2Nl
bnQgNjk0Ci9DYXBIZWlnaHQgNjg2Ci9EZXNjZW50IC0xOTQKL0ZvbnROYW1l
IC9LUENJSUkrQ01CWDEyCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMDkKL1hI
ZWlnaHQgNDQ0Ci9Gb250QkJveCBbLTUzIC0yNTEgMTEzOSA3NTBdCi9GbGFn
cyA0Ci9DaGFyU2V0ICgvb25lL3R3by90aHJlZS9mb3VyL0gvTi9QL1QvVi9h
L2MvZS9mL2cvaS9sL20vbi9vL3Ivcy90L3UpCi9Gb250RmlsZSA0MSAwIFIK
Pj4gZW5kb2JqCjEwNyAwIG9iagpbNTYyIDU2MiA1NjIgNTYyIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgODgwIDAgMCAwIDAgMCA4
ODAgMCA3NjkgMCAwIDAgNzgyIDAgODUwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
NTQ3IDAgNTAwIDAgNTEzIDM0NCA1NjIgMCAzMTIgMCAwIDMxMiA5MzcgNjI1
IDU2MiAwIDAgNDU5IDQ0NCA0MzcgNjI1IF0KZW5kb2JqCjEwNiAwIG9iaiA8
PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMCAvLm5vdGRlZiA0
OS9vbmUvdHdvL3RocmVlL2ZvdXIgNTMvLm5vdGRlZiA3Mi9IIDczLy5ub3Rk
ZWYgNzgvTiA3OS8ubm90ZGVmIDgwL1AgODEvLm5vdGRlZiA4NC9UIDg1Ly5u
b3RkZWYgODYvViA4Ny8ubm90ZGVmIDk3L2EgOTgvLm5vdGRlZiA5OS9jIDEw
MC8ubm90ZGVmIDEwMS9lL2YvZyAxMDQvLm5vdGRlZiAxMDUvaSAxMDYvLm5v
dGRlZiAxMDgvbC9tL24vbyAxMTIvLm5vdGRlZiAxMTQvci9zL3QvdSAxMTgv
Lm5vdGRlZl0KPj4gZW5kb2JqCjM4IDAgb2JqIDw8Ci9MZW5ndGgxIDE4NTEK
L0xlbmd0aDIgOTc1Ci9MZW5ndGgzIDUzMgovTGVuZ3RoIDIxMzQgICAgICAK
L0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja7VZ5WBNnGtcWqsYe
oq3FVvTTEAG5kghBTg0EJEggTYKAgjLMfCEDk5k4mQDx3Fo8Wy1egKKi64EW
W1fXo+u1VVuPKgpWjNgq4Hquui606mq3um8C2Iq7232e/W+fTZ5MZt7j976/
7z0SyRCtPlBJcbk4gWOFQFmQLAJlZMYa1FqZFEml8CwNEUkkcTwmBJpjVYSA
I5AsPDwMJdkYJJciuSxCFh4hGwlGOlxIW5830mMLkoXAfUToyIiQMJFEJHkG
H4EYrgjziOB5rggJtMWKjByPMuyBFppEhIAgAwtHswIaKmDSxNIkwSCrYGfw
0CAXUCpP59EsCDVYIIyQPqKwlc5jURxnsYPOJCDfOD9nIrJAVzZjedoqcEYj
BE0MQjrOigEIaTmroCd52iIggiIsgovoixgh7RjgZUUajuNdvomQHs3mIYKl
kNKgQSRntoB/Ls3Qgv1FjDCUOSwzAKlZsp2BwUQDaZrBCL4tBC8gzogEE+48
BDNB8hwoyAIizxWvQ/4LYPLfE0RRBSDj4W50Lk+T1iCqIKYj9D+P4szEyGOM
rJxRKCJ4HInsnA2RBIt4TAE8T+faBDATAARoB0PJzBxFG+0gQjaWgthOBgLm
zdZOOmNS0tAYzGIeiqW15TIQNJkmMWvFThCg7pRZTZhCuXaXQ4IzA31HBiiB
A1xXWSIRpkHPo0LMO1sNyQGgI0gHYgCCjHyhfSBtHnEWp5sfZGpHDPTlM8+g
Xz2Fn8lSiGZdIUycBZiZABy4FtEMAxC5GNms2GhjAhDYonS1ITE1zYCUKZko
XanTKVMMmZFgK5g40OJC3I5Emy0MjSnwB4Y8wUK3AA1NvC4uETyUsepktSHT
ySRBbUiJ1+tRQqoOKZFWqTOo49KSlTqkTdNpU/Xxzq7QY/wrx+yaLDM0LYyI
QNCMtZ1+JlTWCokxFDIRhRgqTGK6EPgS0MkW+39WPoaDAXASBFs4tufOMRLR
RsRyQgAq4mnoGoFzAoLXvypw+3AEIEVYKNIQMGrKQqhoHGGG7qXy4FajRFK5
bER4AErTK4NEMhnUiRSgCrAKRMHOJaZmjRwKbxdTNkunqrNjfDu2mh+wJSiO
ZexwJkZRcAonACeY1K5DqwhAXSbfNe7PJrkrUIKNYVIIM0B1broXLAgzzdh/
adPVIh23Z6CBkbOZu2rVAgE1ULJ5sDik7SLamkAXY0pLC6QJGQnGitvlac6B
ZGgWw5ajXYstUB6m6KKDNUQWsBjoyUaMdOkwEOySM5ysK+NgjT4hKVHl/+xX
wqXWErAJDXbLs4Sc9q5n2c/PGgIGqhhNkAZBDcAQ3p132V3CxbMkLBVoLHmo
wvkLQdhFUoCSh4aiqTIYRwoXI1wMXIODoL3ABXaIMN3Z5iJnzUeEoWAKLiAU
vcgjNpYrnhoYGiJHrkvHZ/pzhqSN5zEruLoITqPz2bWsMS7GpKjxPEdGluSX
756zZUb8+rpP3P2sA1dUl5w6OHvnisig25cj+57j95wx4EFtHrM98umaPmV3
x34aTBlDmwfsVk47NlUfPPuCx7HX3vRbt1Lf4x55O2viS8erjh5+w7x6/o3G
wVcte/zvXRTfbyo86L4t+ZYs7LcD7i5w2+I4/9P3Mwpm1jY39q6gxNfKRNlV
+5KX43E3m0pPPr4zhlvPNW48/nbWyvv9njQOOHzpbMF3r60I/7BqdOXS4UJd
8QPDgWNul0P3nIofrznypH54w7qRrYGDFTXL7IHT9tXUpOcs2xe9tcG7yq8q
X3WtwbBU1bu058V6XtNH8jT53ZKp190cMTvLZ/VrmPHnC5vrx8/5OvSSsft7
biF7P35y7lB0qW/Zjso/FGdJZzkUeyvEDTOor8VPqn8YO8T72oNpd8pvXc7Y
/XhCRW/FZ74FPQdWOA5U2Le/M79l2ZXv3sxL8vypbvONt9duZEd9Zc4240lJ
S9TfvsWNWlPaJ8o/Z2vF9JeoxVHhprmVybEix6QhOjLca9PcpxkNN3Xex1dL
Jl6pPx3aOiyjcaphTPnrbpo7J4p6x3i91XODz7wFtg/mu/c/LGuWzI3aXt5/
xPl18vgEr1TPP/Vf7p6dPP7e3Zaj91tPS1J3SX3cLtzNcV9ETXog3REtOX/s
VdWIXuTZVdXuH9V6eoxNeXSihv9UpSpxnKwNuukT+1XGzqLus1r3FC9p6tHm
uVzb9E2am3jMlXl/yfnkRETSxwpNrW0WOW5NyUTdYMU7i0RXa3dWR18pu1nX
uGr/6949/jowITu3u2HJySPSqta+LdQuz+G1754q7N+SPkX8uCczefGWOW6D
+pXN7Dtu+vrxVRn3V/l9tPrD34m3b62yZG2YIFsnP3LA/+HSyds3hMVMzmH6
BbhvLhHmZsXElCly3k895F3uWL9yr2MQ13PtTHEB7zO52GNVqce314uu39c+
CvdO+8Lm+YXP2aisfqrTUtE2lVu1cG7dw8JFi267ZaSfKEU/xnsfumY8vHag
acpC34G+8w5evdgnqVzpiHtFku9uW/yGqtdRfs2usAWtPtcXhpycnOcznBdf
uHmmLkQ+6YfWoScauv24cL0s0utvA8bun2F/wj49OacpTBW76/Pkaq/3u125
lOz9SvmUtnGfRz9UpvcZ3+vspm6HrVHSp4OH9FIMt5jzQz/7/fW2Ue/tfvnv
qns7mjNqun8j6dVyxidbLm77PnKv9RV/r1eb9Xmk2hHcbRNzzH/QI/3+l29/
gHP3XG3K2Rs9On8cU7m6UnFkmjrtzK0hQysfoPq7fxQ23qgTfbmjyeqOs4zz
Uetv1J4ad/GsYY62xPQbLZe+FC5va65/JP0vX6L/A/xPAJAMhj/inJngC0T/
AAc7kl1lbmRzdHJlYW0KZW5kb2JqCjM5IDAgb2JqIDw8Ci9UeXBlIC9Gb250
Ci9TdWJ0eXBlIC9UeXBlMQovRW5jb2RpbmcgMTA4IDAgUgovRmlyc3RDaGFy
IDM3Ci9MYXN0Q2hhciAzNwovV2lkdGhzIDEwOSAwIFIKL0Jhc2VGb250IC9N
U0ZKSEQrWFlCVElQMTAKL0ZvbnREZXNjcmlwdG9yIDM3IDAgUgo+PiBlbmRv
YmoKMzcgMCBvYmogPDwKL0FzY2VudCAwCi9DYXBIZWlnaHQgMAovRGVzY2Vu
dCAwCi9Gb250TmFtZSAvTVNGSkhEK1hZQlRJUDEwCi9JdGFsaWNBbmdsZSAw
Ci9TdGVtViA0MAovWEhlaWdodCAzMTAKL0ZvbnRCQm94IFstNTQyIC01NDIg
NTQyIDU0Ml0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9kMzcpCi9Gb250RmlsZSAz
OCAwIFIKPj4gZW5kb2JqCjEwOSAwIG9iagpbMCBdCmVuZG9iagoxMDggMCBv
YmogPDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbIDAgLy5ub3Rk
ZWYgMzcvZDM3IDM4Ly5ub3RkZWZdCj4+IGVuZG9iagozNSAwIG9iaiA8PAov
TGVuZ3RoMSAxODUxCi9MZW5ndGgyIDk5MgovTGVuZ3RoMyA1MzIKL0xlbmd0
aCAyMTQ2ICAgICAgCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4
2u1We1RT9x3vJq0a5/FZW8TqT5EalEASSRDwFSNIhCAmoYiK4+beX8glN/fG
mxskokjxcVYVx9DKw2NRkaHiY1bUKdN1uorL1IoF8Y21vlCZlfmoroR9E8BW
7Nads/92lpzc3Pt9fL7fz+/7SAKGJ+glKooz4miOFSSyYFkEmpWsMmgSZFIk
lcKzNFQUEKDmMSHQHDuVEHAEkoWHh6HpDgbJpUgui5CFR8jCwEiHM2j7q0Z6
bEOyULiPUIyLCAUjUcBL+AjksNkwjwie5xYggbbZkYnj0SynxEaTiBAQZGDj
aFZAIwRMmlmaJBhkF5wMHhHsBZrB02k0C0ItFggTpI8obKfTWKTmbE7QmQUk
Vgd6EpFJvNnE8rRd4EwmCBoTjHScHQMQSuDsgp7kaZuACIqwCV6ir2OEtmOA
lx1pOY73+sZAejSbhgiWQiqDFpGc1Qb+RpqhBefrGGEo+f3kIKRhyXYGBjMN
pGkGI/i2EbyAOBMSzLjzEKwEyXOgIC1Emjdeh/wHwOS/J4jGW0DGw91kI0+T
9mDKMrEj9I9H8WRi4jFGds4kLCB4HImcnAORBIt4TAE8TxsdApgJAAK0Q6Bk
Vo6iTU4QIQdLQWwPAwHzVnsnnWnxiWgaZjEPxUpwGBkIGkeTmLVjDwhQ98js
Zkwho9PrEO3JQN+RAYrmANdblkiEadDzKAPznlZDcgDoCNKBGIQgIzG0D6TN
I87mcQuETJ2Igb586Rn8k6fwPVkK0aw3hJmzATMzgAPXBTTDAIQRI4cdmxxM
EAJblKQxxMxINCBVfDJKUul0qnhDciTYCmYOtDgDtyPRVhtDYwr8gSFPsNAt
QEMbpVPHgIdqiiZOY0j2MInWGOKj9HoUPUOHVChBpTNo1IlxKh1KSNQlzNBH
ebpCj/FPHLN3sqzQtDAiAkEz9nb6yVBZOyTGUMhMZGCoMInpDOBLQCfbnP9Z
+RgOBsBDEGzh2F45x0hEmxDLCUFoAU9D1wicBxC8/lWB24cjCCnDFEhLwKip
MqCiasIK3Uulwa1WhaRy2djwIJSoVwWLZDKoEylAFWAViEI8S0zDmjgU3i6m
HLZOVWfHiDu2WiCwJSiOZZxwJiZRSDwnACeY1K5DqwxCXSbfO+4vJ7krULSD
YeIJK0B1brrXLAgrzTh/aNPVIgm3Z6CFkXNYu2o1AgE1ULFpsDik7SLaHk1n
YiqBFkgzMhGMHbfLEz0DydAshi1HexebRB6m7KKDNURaWAz0ZGPHeXUYCHbJ
GU7Wm3HI7CRDrF495uWvhFedQMAmNDhtLxPy2HufZd8/awkYqEw0RxoMNQBD
eHfepXQJF8WSsFSgseQKpecXgnCKpAAlVyhQlgzGkcKZCGcC15BgaC9wgR0i
LPa0uchT87FhKISCCwhFr/OYMoXLzJIoQuXIe+n4LH7FkHTwPGYFbxfBaXQ+
e5c1xpmYFF08z5GRy9ILD6zYnh1VdnbHm4H2IcUVy04dXV5VHBl8/1pk/zr+
4BcGPLSl3/J+6XRl3/XNsbtCKJPiuu8B1aKaLH3I8gv9anoPDNxcou/+kLw/
d97PT5aeONbHuvGjOxeH3bQdHPPwkv+Txoyjb+6Ja5KFbfFtXumzveF869+z
LUtOX7/Yq4jyv7VelFJaHfcx/uBuY/5fXzyYxpVxF8tPvjO35MkA90XfY1fP
Wa70Lg5fVTp5w9rRwtnMp4YjNT7XFAdPRc3WHnfXjq7fPO6RZJiycp1Tsqi6
sjIpdV31hJ31I0sDS9On3qo3rJ3aK7/HpVpe2zegLc5vWdZtn4aJVYW5A+qz
713YVjt7hUtx1fSzmT6hh3/trvvThHzx+k83HMqcK81tUB4u8q/Pplz+7orH
scNH3nq66EFh07VZB17MKeql3C229BhS1HCkyLl38EdfrbtxZWDa9Hdbz267
886mcnbS59YUK/7l9ALN5bfZ+fXzTq5UyF3fJv4+ZPlx9y8CysO2hPYdvsMY
O1KsUyddd+ZlD/Ibkj5ULo4t2+tvSdlW5X5PUbuTGhA/5uMR736+1LK75Q1u
4wHHE9/mpps3RLlz1jwmLY1DH1XPzHeZfte8ZhuOOq2U75i56fjqJQX7b+hX
pZ94WNrrQtPJ6lvNB/Z3V36Xt9JfnLe2+ptn+3LmTN27v+fyHtbGweMPXvvt
5SvZrlO1b7WMar73dAITV7aQiZRveZJ7bl+k0lpbU9CY4pp/r+Co+6vB+wR+
88rK7qkT/T6YVUMKYr+W0IaGqKjVrkuHdWb9oPzVhYbN7mNp7rjnAwIiBm3b
maJu6v7tZSEnaKl2hV9A7+M7Tatd5Q8u3Mob/VxTMifX3+fFmPvlWrmebB7+
oXam/PritecmmJ8pqeTaMOMRc5/nj0/3WUosXTLj+Zke0xb4NHZ7dNI5ckl5
Wdvh1nGTFLXdJk7us4mtmvD10YGF4qa8Ez3vbvyzdKrI5dtoStV9kjp+mNqa
MKiAuhr3XnyRcyVlTzVu/UPJkJ3FFbZ5xXWSDwPVcW0FZ7YbxPdlnwmD3/6O
v5pTEJ7rljzdcJc5w210XW9trevfeNOn3DdQ9hffvTsC9MWH/B7N3GNcl/Xl
mkvPN7S1zR9U+b4wKaiIvypNfhbAzgtruSepWXVl35LPSnK2Fh9/qmfk7tsL
0+nQC4GmsqKH2TkVkWW2Pm1TPu3rbEgfN7s1xiisODHYGTyq8pOeB6tadqUu
POu7Oyz/ZnaWumojrj5ULJ32N66wwuo3qnFkN9dW/Y3R3KxF52vZxG/MFeqG
t8rOxtzetafC1+dBSd3Xl/44edXa/l+GV70hKfD9TdQXD+7If7V/yj9WF+dF
4Lqou03S//Il+j/A/wQAyWD4Z85ZCd4i+iepDbcAZW5kc3RyZWFtCmVuZG9i
agozNiAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL0Vu
Y29kaW5nIDExMCAwIFIKL0ZpcnN0Q2hhciAzNwovTGFzdENoYXIgMzcKL1dp
ZHRocyAxMTEgMCBSCi9CYXNlRm9udCAvWldUS1NDK1hZQVRJUDEwCi9Gb250
RGVzY3JpcHRvciAzNCAwIFIKPj4gZW5kb2JqCjM0IDAgb2JqIDw8Ci9Bc2Nl
bnQgMAovQ2FwSGVpZ2h0IDAKL0Rlc2NlbnQgMAovRm9udE5hbWUgL1pXVEtT
QytYWUFUSVAxMAovSXRhbGljQW5nbGUgMAovU3RlbVYgNDAKL1hIZWlnaHQg
MzEwCi9Gb250QkJveCBbLTU0MiAtNTQyIDU0MiA1NDJdCi9GbGFncyA0Ci9D
aGFyU2V0ICgvZDM3KQovRm9udEZpbGUgMzUgMCBSCj4+IGVuZG9iagoxMTEg
MCBvYmoKWzAgXQplbmRvYmoKMTEwIDAgb2JqIDw8Ci9UeXBlIC9FbmNvZGlu
ZwovRGlmZmVyZW5jZXMgWyAwIC8ubm90ZGVmIDM3L2QzNyAzOC8ubm90ZGVm
XQo+PiBlbmRvYmoKMzIgMCBvYmogPDwKL0xlbmd0aDEgMjEyNgovTGVuZ3Ro
MiAyNDg5Ci9MZW5ndGgzIDUzMgovTGVuZ3RoIDM3OTcgICAgICAKL0ZpbHRl
ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCnja7VV5PJTr21ciRloIKelRhCyz
MNaOjH0by8wodFoeM4/xMGaYecgc2dqoJGRtUSTpUCkUnUKLJUu0SdlKtBCn
Qiktv3uonNN5f+/v/Xze/97Py+fzzPO97uu67u/3vq7rfjTU3Ol6FBbPF7Hj
cTE9oj7RDPLytnakWRMJEIEAMMEQp6FhzUdgDOVxbWAMMYOIpqbGkFMoByIR
IBLRzMDAzIAEnGhIGCr4uxMllA2RTCCCkRnZ0Iz0b5zoSDBEBE6mZgSCGdkY
p4HT+MHBDEJQtj/mDzFRPpODQAKEHYRwMQHkx+NDXkK9YJQJwRgEyAbzUC42
GevGR9koF+ZAVASD/YAsiIUIUDYXsuYFC/midJCWtbZob6LeJAFnPirAeH5+
CB9y0IdoPAGiD9K48wQYnclHgzEIZsHB2OQB/DOH4VQOECWAqDwefzLWAXBB
uWwI5rIgCoMKMXlBwSDeF+WgmPCfOYwh75XeupAjl6k/qYDhjwKFKNALfoNh
Pgbx/CDMH/muOAhm8nlggRkIsyf3+2b/S2Lmfy8QWh0IbHzwZunLR5kCfVag
xbet/+tdREz8+AioAM8P2wLzEXNIyAuFmDAX4iMskJ6P+oZiwA3UQCQbD+oT
xGOhfkJggkK5LLC3SAGG8IME3+XYu3pC9ggX4YNiuYf6csCmLigT4QoQURIg
XWQT+CMsyFc4GWAnYkD/xgCy44G8k2UxB20C1vlQGMIXdRcEWu37Jt8y6kKA
kRboFUCbD/GCRWHagKkQ4oBW/BGp/x9PYVosC0K5k1v484KBMn+QHGjdgnI4
IIUvAoUKEL9Qji4EfKF1jgwHN08GRHH1htZRaDSKK8PbHPhi/jywioQhU5nQ
oGAOirBAPFDIh7mgW4AMqi3N2gFEUKwcXRwZ3iIldo4MV1s6HbJzo0EUyJ1C
Yzhae7pQaJC7J83djW4r6go6gvyHY54coyDQtGBEMBjlCKbke4PKCgAxDgvy
h8MQUGEmgoYBvTDo5GDh/6x8HB4YAJFA4AuO7W/naA6hfhCXh+lCW/go6BqM
J0oIov5dgaeGQxcyMiZDVBiMGiUMVNQaDgLdy2KDVyoFIpCIBqa6kCedoo8j
EkGdmBioArgKcHjR5ebI9eNBplNmVmjw96XvHaP17bbTBmphFo/LEYIz8cPh
XXkY0AQm9eehNdKFfpr8yXH/Mck/J7IL5XBc4SCQ6vvl9g8POAjlCP/q87PH
OmSKARWMXGjQz6uOGAxqQOGywcVBmDKhAjs0HGG5oxjTH/KDOQJkyu4pGkgO
ykXALYdOXmx6RBMC4adFcA8xA7kI0Gf6bQ0BCn8iDY52kjLeyd5xrZuLzo/P
x+SyOwyuQoYw+Acjkf8kJk5jKgwmKhxaT9AnEEjAEfx/f9vw03a2XCa4VUBn
kchGkGhEhDgCSEUik6EIIphHFhIOIeFALF4f9BcIAZcIFinqc5yo6CYmEJ4F
HsA4hU1F2PQHNiUADB4/MFGEidOYJMKkaWwgwgbT2FCEDacxWYTJ09hIhI2m
sbEIG09jET/TaX6mIn6m0/yIBBFB0XPaQpy0EP9iIU1aSH+xGExapnj+s35W
VrzwCD0wM3pEI1A4ItHQABK9Rf7NlRnK54Nv7+QAgT74jie/UwgSjjBxD9t4
TPMdARkXdp2Ksj3e+rsEXvpD/emXD2dXe5VHHUJZkXRytocaG8sbyOktS7yu
FHh7kRPTPE2eX6q8zzVh42iufFHZnmP5Xkkx5Cr9drqScPuedNkvOpoDjtdD
1mYe3tm7xKyK//Tg7hW6D0dXRNfPyWa9sPI5Xvm+u01GbhUtZaWtjWE+74KY
qSq/o1FTMqDJTXzriE7Hk7tfOvD2Q/ZyirAVUpD0YZ7gV4f+ebGHS0j7/uTH
CxNvvL06/5OXncIj90ZS8PjTls7xo0H7ncICnlRSQ8Tw3ZJOG8o5IaGG3tIS
+4txm8uElcUT11zXLobFd4zJ5JD8tTfZ7DW+d7C/f3f0561UiaeWN0N9Cp3D
B5RVizedF3caTGhVK3T2aJ7h4HNnTw5VRxpn6ew+lmXcchUOltsizWmmS6d6
fjDbMl/ShEZe9QFv4PKr8i/x+cUvYrobzRQzyAxy0ky50xbW77KZVzo9bBVL
2S+3TtDwadH2eWYrtRiBL/6UXG2le9cerxLFIrTssdj8cI6dpcAjtwgLbz5w
v3XB7YSCShX5z9cUFNKkXYRR7DOkfnqWR4lqXoRQotO+i+3DlSSlWAYZ8OQo
5rEhy2nv6+1u7eQ27TWUWFuiOox1w1EDPekrrSq368df+pLKfn7vMueWg/7b
Bk8u44lRiCbFWf7QoggN9c3F8U26pxpjHatH7lep/KEu83WsPq+hnnzKNDFq
87PPObcenLEQd6jIjqT2GzxtwQ225haZbCsNuJbdLH5OHr6tU4Or3hDt501r
oo41Bt35/NV9T5efykTJYq/ZubZLsu84FvbGh5QePKvzkpm7xD63b3t6u8pz
68CugkSN6l+MZTmVa4gLhnOPW6VFhWf5NIUrPWjNfrhihdudEzOQti/WjS8v
Lqp8bpXyKPncLJkXH8poWVXwmgWPrPzfbGPIhcslK9+5maxhWT54cyTm88A6
A1lhbvJu9j0nrYNlTXe0saP2e2PF9Kqr7QVOw3U1nFrtMStX3EU7TuNFj7HC
j64Le+bvMeorcM9P2FrxSH5w89n3GTMuzvdTXZ1DymI4G5g8qVa76rx8dD/1
yGNHBgFe1kN/o/LJ3eN+PDZT57fhhbUfF1/E3X43L80zc8PEago+JYwoplkg
ZbwmUf+4QmajNqlpbNE888sZx1ccdOyHnsoSnV6fzsL1FKrbvkIL0uYgM5tO
1KgnB1ZmsI8vVUy7dM/m/M6dx59VXVuoMzPyaCBRZcOjlO5OlcjBNs3cHvq7
3g+fMtd7FRlfGpV8380KkP/sq1dpN5fzq8r2ctIzTW7+/aaHb6pTqEUZiTkk
imSs7PbC6EpT2T4JNUuPY9fnXlConu/WPyvT4mu2zMr7ZzjcdvH1sXltrufw
2dsN6AoBOX0QO7JlRKK95cpOSY6iWhyvTrrjPaGKUZ27Ta6NmzXoW4/WakcE
Yy8PbdjbjPd5lpvbZnK34HBm6c0j4Wut606qfpXDEzXjU3OGzy858vxcjljz
5Vkhyt2zqogZPmsiuPikx6E9Zy3buzNSbrwOsT8l5rRjyXDeUF+WnH7t+ZvH
M37vOtBLDCwZvtlUIua9IOLxg+KOjbllxVDe3E0pNQs5V3UH1VPICuwKP1o3
bXeHSsunro7g5C86IzaJrnp6G1Pfr41rD1Bwnndtx4rG07WDry5Qx9p1T/oe
6o6yKCDo2c/yZ84QF5bKKhra8pxmtaUlFFHWK9UNP52h9rq6y7yYTa879faa
9pPSLdxY5qLx7Q34vXjdhMLT0VLD7+dNxFnij98vWNXfS925PHNujWehU29F
5NyqK7O7953/anfyITE5Lq1j/jyv2/Gn75cnuHUaezra4FYWavU6k2VurnJ8
rRrvGTPWMGP/dSOXdKO8TsWATzMiDtAJITNbYaNDsS/q+yrw97A58zrR5iBt
+zeXjLfd7qtW3muw6773/j9S//jtANWkK93i3NkTcw+0iHOb8zkK3SdOe2sv
hhbj9y13Zla4OWfFNKxZWXC6vtOsM7LzPFdicKtG70qJgwOavYKrpQ2+W1aG
JOxt0OCOyxga90bFn/VIWqsiI3UvNfhVv3KSke2+juiX1Zhi4ZpB47r4VC5B
3rRrWUPS1diaajjrsGDk6tO5ehu1el23LU13Wyp25lcNnPrBZa9cKm857by0
fJYGGU4ai5ddHCM8c77eejvC/FS7tFyp+J0yLVrt9wd21gkGuyLCriMut/x8
wu2UShqPmSuGMAyNDud5u49vqhketMlsP29Qzgn/xSxu1c10qdPFG1XOd0gM
LPzUZvHw4tBSnsmMyivrTwzoPMNfJiruWGBtPWuPx2gSw3+Wbqm6rPO7s7BV
8sBvjNS7bfkF6hzZ3guSXe6/HZE66mGV+1alrea1QlHMlq9riLlKb+zFI2tU
61jFNRM+Xe0P2EU7XCwqb5S9MXwla3HnUt0775N7bwyno/NbWxdFWNGEMkdl
Wi1NXfT0N4r1j8QWPGH7kAXF24qEjVt5Wh/5C61uFYzMSaCMxHMHzrGGVPb9
OS4dU+YR46P26lH02o6SK7rt3ZF2RbaRt89icHpcyeJBrLBOden7paUzYvo+
S+ePfKQGUJwrlTSumoY5q9Pyf5+/b2FjAHXoiq6EXX72ssyPcsz9mcrcsEzv
TU6+PZWdhmZY1eiST6vw9hfHopxGFxJbruAmZuaEGpjLr6IXEci6Lu+3bahR
qw1HAgsFWQ4FKZyCuo7+ton58cfcxKTmPL4w6lh+vVA9bWh8R3Sj4LB2bEbc
09iX4nJ9zWtsVks9c3ygVjtzo+J720candKb0T31aj0dyp5iXqfazi1NJz3h
WO24rpVozW1pdSVWVGDsMN+yy6nJGfRyT3Kp2fhO69g0rrgLkeCu6fb28boP
klk2uxZVu6119xkIlXmdXlPcrD57tf67UysqMk5s2nl9xC83bSZZquBK5cLy
qA0+q5TYSGDqjeLk7hQ0vYZRMZDjaTnnwhWqcegcz+dv2MxEU0r+5npSX+oR
B9LlLLVRldP141t7UZvdEs2BSU6xA+myQcrPqwvW+WsVdhok2Tn5HMissvaJ
43vJat0b51LMzhY1t9zFVE4GPX470bjJzO1igBqR0qYirxNNjrVSlu2R9ds8
+MebyNUKI9jO7Ys/DVWlbm5I9ygzHpSyvtNFl2j1MmG8bh/elDtbtUrZNVJK
ky5pdT/ntprqOS2pi3npagZfjjTtHz0/qu0f17gMO0QeHqkIic2Yfa088djW
6Mg+wT3p3YmrsUPynW/3DAXFTAzlRqcJGzMu3LwTXlvZft0mN6UHNrQqefqh
4TUWOqy5sXKXfVl+kZJN3HKjoP54h0D/Wtm8ZWq7O3LMVErS9RjxH59IlUQO
bS3KavqzSEmbO7Er9NIKWcL/8g/3/wn+TyRgchCYj/GCYH4g7l9zZ89fZW5k
c3RyZWFtCmVuZG9iagozMyAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlw
ZSAvVHlwZTEKL0VuY29kaW5nIDExMiAwIFIKL0ZpcnN0Q2hhciA4OAovTGFz
dENoYXIgMTAzCi9XaWR0aHMgMTEzIDAgUgovQmFzZUZvbnQgL0pHSVZPTCtY
WUNJUkMxMAovRm9udERlc2NyaXB0b3IgMzEgMCBSCj4+IGVuZG9iagozMSAw
IG9iaiA8PAovQXNjZW50IDI0MDAKL0NhcEhlaWdodCAxMjAwCi9EZXNjZW50
IC0zMjAwCi9Gb250TmFtZSAvSkdJVk9MK1hZQ0lSQzEwCi9JdGFsaWNBbmds
ZSAwCi9TdGVtViA0MAovWEhlaWdodCAwCi9Gb250QkJveCBbLTExIC0xNjEw
IDExNDMgMTYxMF0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9kODgvZDg5L2Q5MC9k
OTEvZDkyL2Q5My9kOTQvZDk1L2Q5Ni9kOTcvZDk4L2Q5OS9kMTAwL2QxMDEv
ZDEwMi9kMTAzKQovRm9udEZpbGUgMzIgMCBSCj4+IGVuZG9iagoxMTMgMCBv
YmoKWzQ2OSAxMTMxIDExMzEgNDY5IDQ2OSAxMTMxIDExMzEgNDY5IDU4NiAx
NDE0IDE0MTQgNTg2IDU4NiAxNDE0IDE0MTQgNTg2IF0KZW5kb2JqCjExMiAw
IG9iaiA8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsgMCAvLm5v
dGRlZiA4OC9kODgvZDg5L2Q5MC9kOTEvZDkyL2Q5My9kOTQvZDk1L2Q5Ni9k
OTcvZDk4L2Q5OS9kMTAwL2QxMDEvZDEwMi9kMTAzIDEwNC8ubm90ZGVmXQo+
PiBlbmRvYmoKMjkgMCBvYmogPDwKL0xlbmd0aDEgMTgwMAovTGVuZ3RoMiAx
MjQ4MAovTGVuZ3RoMyA1MzIKL0xlbmd0aCAxMzQ5NyAgICAgCi9GaWx0ZXIg
L0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp42u21ZVTc3dK3iWtwC944BHd3d3cI
2ri7u7u7W3AIwS0QXALB3d2DO0zf57zPSc4zH2c+zZruXr36ql276le167+b
gkRJlV7Y1N4YKGFv50LPzMDMAxCVV2FmAjAzMDGJIFBQiDoBjVws7e3EjFyA
PABmbm4WgATQGPQD9OFhZ+NhZ0GgAIjaO3g6WZpbuACoRWn+ceIECNsCnSxN
jOwA8kYuFkBbUAwTIxuAqr2JJdDFkwEgbGMDUPlnhzNABegMdHIDmjIgMDMD
TC1NXADGQHNLOwTGfyRJ25nZAzj/bTZ1dfifJTegkzNIFID6XzJpACCRpvZ2
Np4AU6AZAqOCPSgbEKTl/w1Z/zu4hKuNjYKR7T/h/2nU/23ZyNbSxvP/ONjb
Ori6AJ0A8vamQCe7/+2qCfy3NnmgqaWr7f9elXYxsrE0EbYztwECmP5tsnSW
sPQAmipZuphYAMyMbJyB/7ID7Uz/twhQ5/4lgVFSXEdOSZj232f6rzUlI0s7
FzVPh/9E/cf5X8z8h0HdcbL0AOgygdrLDHIEvf/nl/7/yiVuZ2JvamlnDmBh
5wAYOTkZeSKApgdE7ABvZoClnSnQAwD0AAlmZLCzdwFtAYB64gsws3dC+OdA
QWfOaPYv27+RBYSW/0FWNgCjo6u9C9DU2ObfJ/k/K2xMAEYHIyegnQ3Q7C8r
8/+x/i9nVpDZxtX5jwEU18Te1tboj4UdwGjh6WABtPtj4gDtAo2LvekfExeA
0QvoZP/HwA1gtLcD/ofZQbJc3P+ss4MEuVg4Af/y+KdCe1enPwbWf0p2+8sD
JM4Z1P3/MEiaM9DtL2WgTjMC/6tCdk4Ao53l30K4/qnQxv6vTdz/hLG1/G8r
B0gg0NEV9BD8xwJKJ/yHQKlE/hAojegfAuUQ+0Og+OL/IU5QIyT+ECiL5B8C
tUDqD4Hql/4PcYH2Kf0hkKfKHwJ5qv4hUJvU/hBIp8YfAunU/A9xg7IbOxmZ
WANd/mtaQHfZf6brvxdY/7PhvwcJdIMw/pkZblD9xn8IVL/Jn0FmAhVi+hf+
0+e/8J8p+AtBCc3/QlBpFn8h6EQs/0JQqVZ/IUiT9V8IEmXzF4JU2f5B0C3A
aPcXglTZ/4UgVQ5/IUiV418IUuX0F/4zln8hSJXLXwhS5foXglS5/YUgVe5/
PfQgVR5/IUiV518IUuX1L/y/33IiIvYe3vQsoMcM9MX0T9e5Adwc3L7/5Wni
6gS6Elz+9ScCuiz/h80sQVcrEOgBNEFYmrc34Q2xSm8Oq/ATL/5VCf0JXMS8
JUHhW89MF2LwYiK4TdmorOOn9Qatp6osDOR96H1i9xd856hOH+WfEheBjgkZ
c2/7bob7WV5t+FpXWfKeew6k98EnKB3Nszen7OCK0+tjFSnaJQO5vwdPCpWo
xdQOYFdJwHp13Rp7s0M4OLUksmzUw0MbKFlJVFAzHCsi2MLX3FFTkqDWJoP9
rMLhWmlXLu07XdGfiuEKkt/07rHi0Uw6iVlVtj9hqhwInpaXhKOifH3vH64T
ygaYqzoB9qGX4VRGpYPzMMLqcr3wxA2mfuNMiEfIu13QtXVqkbxScOivl+0a
sNIaWJTILJYy/U4qtq+OpXqE83o7BqQ9cBd1yib7k28GXPigJLsUxmro0ehA
kyC1WZHh6AxkZf/C9GJGvslRxxP2QyB1EEx593YVytIX9i1zRrDcQX2yEqF5
8VM0RkTpH+RTOsrDyWsikpPtV8FxYiSKE7rcEonzZKjb1NNRmolRQZN/mZZX
g/D5ToG+hmYPZbIupPKlRrVZuMgvcDcwxSNkgt0MXxpLsDAP4VPYB28j9TBH
Jv79WphyZAVxZBwYN7f9jsZPWeTVnQL1o95evG/limfc48+2aroNnf15n7HT
TWGrclPUbWZ/w5FfaGZbgDWv8tSFIAoOBlE7ccTxiriswYxy1MWbSPTiiw45
jZMz8pLQyS6AxzoWfpHLSjkDSy59BmrebLqiStYtADJOi8Fbay3QUDI40/YC
L2EwpZU3dF2hWIqYXoubXHW4mg7SP1X1ksEU4GW+PHzMdWxduUlVaj/OuWzz
+T40niYdN54cjYeD2uwA9D0iK9NeCdfE9MZEkIJxpj7Yeezz/RjREJIgCi7+
YbMT6/wYbDfmp0nE9QvvxeJSPxi4LhCFUdUWUoPy6zuC5QLLUGGwrYkeU4/1
mSiVswPNXrsWU9thlBB5H4vV9LWiZJMkd2MERY1Z5v0UzrGczKmY0HfbSrDM
9VcWY/Y0PRNTT5Kg6CvL02EvWoKYGhuP5j2jetj0btqhUZZGVSHXO2n8I+2p
O3YJAUfzPBV/RXF7d9lPD2/Xi4O8jNGZbyjO7WLfJrHKMCSJiocKf3rwCzQS
y0zsAVyzreTEzLYXke+HwqxrYLYLoVDq6LderV4NlvwqmzFTLdK/dHooZADr
kQ8bsxPjIgylL2+SUyCPl1t55GNYGUhJ6uLtZaTVlAiayyijRuwdEskNIGXn
1UU2JDu92+fNifbrEsO3M8a8qkrjBJsahw7NsHvLmUoqOH8Ax6nLBc7i+dIJ
bW9LEYx0HQVVWTYnoYfUXt0S7U93V6hhWeXYtraF49/xxWhKTatC/YnIWH1c
D2hMdU4OHtLcmEqQwR56mdSuuqksLBiUfjUK8O1E+uYdUPi5P0bKzXLrkWjp
Yz/UvkGT+M3exzC/muiATegjvXgjWD+KyRoPc8C5M89PQ5OX6PLFBmTwmHP6
dZzjEG42FmFYPLby3I9R2wZHenxO/oruPqgv75H1mE3oxcSS4qW8UVWwzJuy
OAvQ3RalFKaSlE+/1iQLBY81PpPF486OkzmL9WHJR83tZsL6QrXmcGa7u8Lx
XQqgF7N5iuAujUf5KOiDAGlBZWyAphlWVH0pL7kViRmELW53et1RyyYUCVWq
NVwiwJEF3t/hS9vxvcGxPAnc3cm0L/M6Sb/6VBTe+sXuzFdX1TZDooHWtZsF
h9vIPxyB8zXUkribEIHr6QIXyBerr0cwa4apXXLCk7urtIvFV6OHkZxyXEPy
Nt5a+Yvc0t5i8aqc9pda1Lbr8S7v/ic6PCtu65sVdDeTYlv4eq4Y3PgPG1X4
pfyeIggfXGnqu1191UUTrhwBch9LQoj1P29Tj4y7Cc3yCa55mlEOgCkVfD/Z
1j8WcFihaNvYpMO0dMtkKUwQ4Uze+zrPLa1qO9CLnZKMp52dPGMlI7QkPSB1
vS7jFCSi3TfGDISJY+B4kqjUCOsrCM01ee8rHJ9EbDZbND//HfpJywaj4rOF
lsqLxFk30vBKJBLaIi9ZbMuMNFnhGzVtEhAyLHrKcR5X3SvUzI+fWQK70O2R
wrQVvvhqLinQ+ow8LV8t4mOUGLFQHkzy0qf9YDoqIw2CAwzftC88ry3stiQU
fjtxkarrEII4uXqBp5vesy/gYM9IEQl+EZEFC8CPEJ/Br1bjnN1gEd0HF3LE
4ZAdrqO6uKVuLQr2KS213bFOBaG/z0LJeV5bKV+6H4LB7skhZ0uEuVMWpN17
cY+/MG6rLkEL3OvVbdC6z5d+GrcEwn7PI2rp6JzoWhv/xcOD78hDZ5q4XMVC
TopHVnnkbU27OIvKkGBfVcQtw5S+YsQXIvMmPOiQJ+XAeM3daLjFfNa+N6T7
nC+MhVHqIJCDIH5gNwqhvh7M3aCnTOEb0g2BYHBD8fHKtLcCc6uqjYNoTbJo
uUZun06oqEGsi/QcywI5nX6oPjypLz/3c/6c4YCVjvo3xHkZuhCq8SDqmJwW
obAXJt1bJgjyNBWDvPGYYQDn4TclC+MuhPoOve91Z1gfy6+Dbsd32j4OJ9OO
3Mf8krRN8sCIsnyLnPmdZArN1cXOzWuhaELRK2Wk5Vf/ZcZRDNvVzL05s6cA
ykZ+VUNqB9DFHIXvHq+KgYjyyQr/mbn+EByTy1351x749JDNVQkfGK+qIKJh
YRXJSsAYy3Oonvp80Ty391xp73r8zJrV2smKK78VZ7HPgt9Zq8RyuM7UKvHA
fu+ch14JK0/71I+0CUOmz8Bsx/XU6aWHbAjCe/ORhVmwqqaoIGiexiBZaBRv
ZG5qevEzBVT+EYMkQKHY5Zu59SWLx2NXieUtrWmYw0E/PnSVEOdXmLiM1p/E
nLQa8u2YncImjzVmB/wU4ZZyo0bfDCopuyAJwmsr2tomvvMCWLvofmmMdijh
5YwY5r0s5j4jcqCqdB966IDVKa9tL9hPUaGO2BGuo7YXmnKszXHLDDiYokFl
FG8/SZFORO0/qBQtSAVJxBK/rspRSJ9AyznLo/Uc5xBAxNP+TFN9QC9+bXPS
/KlM2uDMEzfs4HDlNUY6F8BOYLgiuyIp/iMTrlX8lG5SKEnG7aWegAC9GNz9
OSRrNuXBAJvhKBeylpKpgfGjlVyNiFiI/wYiilYmhSpRTBxaXUyMPumIdUoI
kjRuoTOxjom1M2QdB8Ww0OXvEGKYNKGVHWxnr8G434K+OaqNCayC4PhgebCx
HqHjJY3KxDjhWr8X01o5MpS8Hq5oYwgt9BPWdxTu/QPwnF8rgmaObwZxRTGF
fizP3gm2tDyq8AdlNMUnNr/UxvZMtorAV3t2Cn+rgnDS0ym9bYpAiOCpLKP3
xE5drmn+RtwCRQMNFEgkcRztsskn/vCMNRPZTYIZtQXLnQaFAPWTf2sqjfKz
XhRQqOU3Sy7EqFWoOiOl6ZHFtS07O2SRnVQiWuDUCAXFIYTShsXSAtJaOZTD
ToFZ/2ywh+PIpzzFh/WFSZ4BJ7dq32cyuNrI42yFuOso8CFmU+YRrKrB+SfU
VIqr4TNbOOfkUB8ssE5kSF4CnHSTqJFAEYNZ6cVmCjYy/y+QqR1E0yPpR+dp
P6S7ydM6dFz7ZDTQCSyJYtofxpPB6DZc7lcHCASw87vWQwWH5v1kGi0Wu0Xz
hmYGl+hwQ/ZLPbo7TQUC+Em/4X0v+wks5H8/cK5TRtJt79jmM7mWvaTqSDmn
Frlwksq0X2j9sPG9Qs0tIvi4CXIFTi55rvqEa1BzPYMyxwXW/An8Jah27bEH
7Uj/EcET+plJhM+kvnV7NsEtbCLDoI0SoUHUknpJKyvK473BFb84p/4CsrbO
F3zsvspmpUvZRZVyKBj+XRk/pwNugN3kfAhh+jxJQmXddlm2BxN8l+mz0Nn5
POm1owO+Ubs37E7kRLsjX63r22gMbHGn/ORK1OciEb7KOcZ0eEoDa9VVBLJg
Ae09e9YZOzhVte9vV73ofPIbNRSZrRBpaJsMPbQ194ZZAhSIgAv817GJHFJ2
4ZrzMPHkQBGZqhrnB4NP4Nk/vSfffLPsnvo1krxCbpp32NXqf6dhcwmeBN1a
j4CBQz8J9hBovCLr9dEkBotmpjWlBveIkHzmX76uANBeN/WMVf60BiZPzOWo
jkcbE6iAVzh/Qu97cDKKMBo8x6jur7Dp39mfveahN5Bx8qTVyhBDHWK/x7pN
6DWsgJnWU80v2ArqbvWbboqM9Q3YdB7qt4eqYDBUqNjaO5wyRJXyahhAwzTG
OSN2Z9n/OAAud8+PxyLiJ8C5flwq6Gi8lnz/tSdlrM0hOgxepw9JpQRY9I2J
JK3qtFBCOJzJ8Ip/HW3qSVbux/AqTChu9m+VPpo+ntnzG+GqLcXeqOHG4s5m
tHL7toHgSG6RWskHDXcUiw5+S9tl3TDFJ3SZKkadKntZDrwGfriEtjLe74mT
zq7jDE1dzXLxzS53X+WgPGSM8X553Yb2JZwohgFOP+hVxWkRxyYLedvvjoet
hJyNVDmzHVVIXbv4CZPcdTm29jwKJvHtN/H/+Fy/b/TQ4xZL13n4BuNGRZEY
hzuWbuy1O+IVpO01TqwMIRuvR1Ga3ARPudAT2FYoAPEkcNailFqwXd8D6b8y
n7/HF8xC86Np77i9TqbGhwOhToYpGCpqiZh6bZSx/HEweUihoVA9PJeYa8cX
Szc92wayn84H+zceDP+D+5bQ87scKvFmN7/wY7OBebVPT8fj4I1LS9YLl/tI
jZYW+bmY7kLakiGaK7mS9OiCLYudmKiVkyb2siVkE697hGXED+0hM1g6C4+c
9xFuNTfUtQpeFwrB/QDfKEt0Rb6c3nHNa7lNvyEiLn3aXPtdBW0UPkrbdU2c
uArDy/3MyUk/7DCw81KDl4MpkyIfsnvT37wmptrjAnZeWYuoA3iS1wLZu4IM
Mm9gbjlNJmB7LQcSHyyNGpOk+Bx/wVixHXxraUePONzdsi9P5r9o5FNgFed8
BvsZ0Kj3QUP3B8a5AaMzlioUo57mlJXixgwseu7E+/a4pwoFGVNQsHMEdW04
1oLWsWpjhcvPfIeHlnpCkp4ekZxTSzdREUKys5MXwiHGjLpds30jRSsDJBsB
QXguJ2pH+/RKC/Vf+haFB8qJIXZfcYI0/GhZJYAcKKWQVYkU3lFeudZG0EBK
vvlvywsSedPPcG7xDsOGCC9nc95Bv9M+xk+ToQyqCYKZysPVlBZGfd5lCx+S
he31qRDtgh0zP7M1BP5K15FK9yj3vc7c3zJRo1hydXhWG4jbMFZDirxtGsUy
NYPRgxy+RO2EIB15pLSqNa/7xbK28/Vh63ttdj7N6ZR+e3pW14iA+DOJVCsN
kgCZjdEAjGg4wfg5EqwWbLiyTHwV+UMz/5zqBxKmxn7W7OyQ+0mo3JsbposB
yFvZuS8nlwCw1JBFF3hW5u1+BU9wtdJjm4RpoUNxg2wwivF2ki9kh8e7XK59
E6zuDdhOKHK6BuRx6AmUd0diuPRrEpnvalc6xytQSSn5E3uzSSI+8AnWywbi
qb8d0E0s7OU4ihepV+Ngm4XG/TgqB+qX2m2fNk7R4y8nqw7BDnWy1t5EONd6
U3d9CjZYw6cSAq8lg+25vnO7eGtOlY2HF1F2jml/NPkN5XuZuvubPXJ2CZo9
wYMVEl/bch7dkHkOI2uAu3oCs+79MYs8gHc4HC+bq1DBdd+FjfPsKidBmjBN
hqPuIXzqxvXtsI8Vb6Z8Up7IwmoJ1SJKrV6yPXf21D39h+IuQd00jRapgLXG
ul+jCH7djfpWMrnFUNORuTPGp3h1kSdVq7Rc6Q+uh0+OjiyUEjFzrVIfJ+D8
Wub8uxGEy9XVWmAZ7sOjjbdfdyCY2zkxGokzVqMHsU8MwEjB3O4QLvBS39m6
79Zsx1xZCwU/If+USMMGvMsaL5gtHDPz/+gUJoRuU5/Csv9y9izs5sDiIHGR
uew0grXtMGcrs546r981Y1zc4ZtreFYmcwkndXOncb4kOkfYgBmQjimgrHwW
VjE2eWL4bnPGKIKgyh3pHho4Qk4fERHFtUWLtur6M7lGB6fkXYqz+jLepNz/
ccekBnMTl7QXSQK9Un8ufPGVuiJtYjg9pAmBpvdxJuLHM5wjxCGVNR24qnMs
Xqwq1SSJWkwOOr3Vi+qvb1Y8onjYEqgxuSkpPmUFtypJGqfx3OCduphPqnzg
abA3fWU+ysLqIvLP0koc/Be1YfZD++0opxIEPKNhhIk3kV80mznHF8BQuDmb
ClD3O+LBa/wPLLuTSNWw9w3WHz2FfJXgsPiCguYjmOhkC+nSHQe9G1b3nxWK
m4PHoatnnvCr5tcKWcRdWoXmvE1f8bLGNsCCmvN1rd01yg3tYN8IKA4t9pj3
YjUSe44ZUymISxQqS8cmSLzuPwad2BZgXasbojqERi3tCkaEQipctmzEmKVI
HTd1VmeMekE+lKULvCNVh6nZyEghjN3Z4HbI53kmdWQukHVN2JPMHX8Tdb2K
7/n83DRvMLLEqMVXjpIPj62xZNz8mxcqF0VUjyfylOm2sicFAU0uy2LqZf6X
0CB980EtnHM73qqcoQRxluTWHpXWUKhAxOc1inbLTzRsOju9jjkXeSrS1erd
9eKwOEmeY5xn6vD4nx0mr+7f/NXI+lgjAqQbd8y2UnIpQn8hHErdSl1O1ZJd
o1Lg9+DQW4dHj4lUngwP/7giPUL+ZEnQmJiV9Hyi3hpHGNmEM+9OMNs188UC
nJ8BvY0hnsAa6Q31qnM61mgNlfJA1Iou2K+jVlD5ZaBHtGjXzp05YvmFzNXE
K5XSwK3G6kOV75jTymG4GzoRVA0mfFH4Q0b/23IcPqUFhRZP8dh6xtHt6PvX
5zzxroaGtgJt0u042P3FfpryIpKb4ilLz9viTHVBOqOvp+UmTZ1RhZsDR0F0
AR4MEnKWOIAG+baDQIXWNIjqoqb5VWeS2nWT4J2SsGuHXIZkY8Ka18YNQCNv
E65pNak13baI4Zb8B8R8bZdyu9uGrwvbMfSYRCENM7zqwVfOBHijALX+Aj/F
ceFh2v0UE+8Mh1foO5HJxkbW5byS0dyxyUvIbzEMA5VsDwEsmoYWahNGuqtT
STgvAvpQ/fYtolMdH5ZYdr5kpOKEn9zise8ErIeN/mY//ISi0Ean6fDldjOm
qjQDpsAj0rTfdIwwy6QWP7VRhU8EUjYgFvNQJMEnOwddX5yigbAhLD0cLIun
s2crVjbVbyTDr+rDFB1AsK9gdHjkMF3JLOCc2eXJqsTD30VoWssL13s63o8i
20i4LfNlAYpI7/vveui+WEbFw7kNyGGHZQU2HUk+RSJCO0Bz06S3xzq4v4Li
nLJMnOK9dUhcUyAVqaNOgyJersDHV0MbBOEGeF8EUROBsYrBiONE0lLn2gId
uMLoads4Je1D/sxwCaovzxIQTC4Y0y1Py82Sk139ypAlEEnGtbU2v/j75AY3
5fUFKtOJp1t5LpL46qe447qPRuFcv784cCB1OZ5zmZiLIQQrK0jdmunP6Icz
VPj5l/nCuzHjuu/c5fSgLKk1FMwKwymG7amfYEpw3SXw0eljfpcaYt93KaTP
l0ZDZwrwT22qD75Yqm48DTN0Z9y2Yu6qWJ7N3oRg06B3j8IzG7q7FidEz1p0
OXp1jD/AxpTgZocp/T43wKdfOTV5/X00zYuSv8rBeY6rCjLbxCZfTWKrDiuG
Gzdw3B+9UieJJbr1MKzLeHvLiA3djY5kZgqoRIR9/cQRgIACb4+HYkmBIuWi
8Qj7gvFUaEFB57lwe7OrPXGNbRvMSR8Lu8nLOCTB9H54MujJ8HMM76SFkoA3
5hfmtWZ4lSnB9N7yJUFJnGATLOYLNCZ6Q6x8yDOvs+vXr66sWFvIv/g20CQk
Wsy3pt2wo5+/zSUbVZJYizrkqptMNuohlPCubXwlIiZ/HMce5gA88gua81n7
gjeVbvOyAj6LNqqc2c4cbFw9Tin9+pb3gFy/i3Tenyuchw1B1ZPgVrNA8wWy
3OTVrlR4Stw4A0eiNfHNjgLilQCrzSGQcyMZ7FM+AQQFhZHe6PLlaQi0WiIO
+N1NGM37tcrwHaGdcFiwuW5p22/s81b0Xvaf0dy+OhgvmSQB6Hb31KlXU9vW
R8xlZtvzecpESLASEwPee789Je/lGKhvcXSNWIVYKQMMgBifEFJ5A3bOV3VD
P14qFbNBH0Ua06ZJrBA8qvpongDOBwN9irLb0/rgwRnxYrp+YxCKEF7ntZP7
oUdFrRex8z82PTCRB4acYQ/udSKHsBriWOrtu3x6dupLQdI9VZ01aLuNQGmk
K40HR/aU8HW8+OGWKRGJdoWAYBMbTICfQn29x0R06S0xsSoXgVFky3yDvHCL
abnPhPaVkP4ruCcCz/u8A4ajwVwG7zcpZUdNU6640k47kd/8nT8XjukNvppH
5fQGSsqCfxWszrjGTMT9Bogzj/25QiW4Y/QtS5hS5r6pmjzB06jd4q43MdFU
QrRcBRGcDn7j7iyrt1R9qrUAkZH5+ArVakMgxA8Qs55R2oCaqPJuWutptCaw
RL/j5mpbUf4LdaLCBrXHaQKaFEeCkypdTeejUMv1DUBvP01XuDtYz9cpfwej
ohRiuW4uCddV+9bJ7wCOnqGpc9I47c7dRSqhYFd21lL/eYw8pU/RIqYLk5Z/
O0qhovBFC1c+eSMqCkz9PW7kTDiF+qzwKOjyIHDXehEl+DPr1W+rlj0r3C3q
oshZlc8tpAw31xuCS+bB+f0/lRv1kJ3g1AiNE63WRaPFgmHZOux2HNcXVKFq
Vn0U+JKWNCThKC9Uwmcj9SghNX221fu3DffrFo/SnYTp8j9qBYfigNmvMsd+
M3ZeTRci2IkJkMDZJh5H6HR50RvxNJvNPFUGGyKTsukulIPLYiHcoVc3Lzw7
KjvPP5oPPLykS/sBEZsNHnjIT3e7ORvxKDbkc6h4eVBJZ+y2Oqh94lQnjBH0
BW7qEmyrIa9AbnbcDfzji6xqSyBXh4mWZaTC74hsocAj4qndSQUeaBGfznxn
q+KL8NNDcaqTxAPuEVpxBMvPS8sHX7ZlIWquj49e8+o+SNnotJ+RSnE5WWXD
1ccHiBMnMvkYrKGW1KxHJgTaHhaUawTPbxX1o4OltWbjLNoi9qr+JBJxWH2W
TwOXJPIORQKnIv8CkL6tmWw4/I6rr2PBHw0/jFEsjGWPXPNubJaddGBmPL6X
XLL1EFdx2vrxJ2peoSGPXOEwNtLs0mwDuCp+s7TeT2tDpao7q7VM+FyIYLnj
QmSpsCxO3cXUjeYkGld2l/KwOdqulKSH4RmKNWhbyPwuzSqLuSN7WLbbnyrS
UM0yK3qbUKFKU123fIUp7EN74ctm56smSofZYNiQG2fFFYRUsXVLiEKtfJPK
jvqSxHcjnPp8vJM5qAsIUdVXSEwxPCd0tIETZqjidCwKETcy0ccYvFbuVhw+
bEqJGsZsO2nDbBUb1zZv9HozkQKxVZm/Y7pmKsoToMP7NPPzCWwuoXnQgEEb
J7wLSp8xjBbb+42+PkyUi4lGgpE7p+xvHZEsNo1f9KRqHoLVZ/chW0Alr/is
LBgrKKR1j9ptQEc4C4b1si1/v/J+kJITKURZyImWjiK1UorUfO93pJA4K0sf
W8gdFd1MasCneXuukhz4JGJj0mdCbdYbcTIcuajlV/SzFssSGoFJzUY3CmZN
LGDFaiBOGdvD85NqxezVUBp6CPzUwAnPL3GyRar0ivBR9nZ5FAovfyGjQZjV
9wiNavZBrnf4oClo1CVWFpWr2J3Hnj6uKIQFz4pAPJrDpVxtvLKt92abcan0
vciDeTXrF8i6/bNuyQ+frBclMlQiYmsObwgVVxke0eTjiJro4OjgBr6uW/P1
0UbaiYl1czWeS+lyvBU9X2LUzsW7L3zWfM9gS2kQ58CZW+L/Xqs8CINXUXn5
8MVKR2BpQP5lm7u6x+DZgIpdpYmopQW9ZNpH/vrNS7zLhq+hY3YzZx/HRSCt
ftku/eQRsaak8QP80kz7yzE0VRA+nay0webAs+b59jC9H/86QLmy/WXTagXG
0wefK4jbkQtiPPpmJo1Ckpj0MmgUCd1Xaf8zAxjjL3Ocb4Mvg6xS8DzAWo0k
+/dH5ct5ETryBxMuRzWWWi9kXCvx6G55HBYrZrwdYYKUDOmynyp6eram/B6T
4VMv58452K+D5TnDcp8P+IZIsoYLtUWrK3Wi7AU0VphFsD0+6eMio68I4XCC
Bb8z6TcZM7mtY3bXmlB3cn1cfDZG+aKgaLpqae3bX8AzKVbtkrFbozvVzeef
6YRo5HKt6aM14tWhj+hdjw+/9ta6AQ7kkbbO93u+z97B0s4pafJPX+ALdlet
2DFoB2q4kxrVTRjo+E7dNX1gkN/ja2h7Fq0prfqk8HyhxOIZuERioqb8OQUn
tYdJeDQDAx9annXE57BLkNsy+tGdqqXnSCybj59dZapC7APgerqiObE//F50
twRXSod9udFNva4PJSCoYYTcYmrVnzlAbYdT6jgaLAy4BA4B4VOQ59BqVZCn
Ve8nHJe9wwLLG9ghWPdMJVLlgS+jTSW3cLOwnDrwdqnyU/6dimWE4aUAPJJe
rf3Wjd+OpAvtVdepGaGdyjWlDpeIfxAdzIGc3f/O9JLinQDWpdfzhDXTbmdt
Oo6zUeR1fR3awin5OlkMw57tpv8SLLpy3qo95IPhL0RUFwhZxMaA2N/VWQnP
4jtDM9wi66UdqEn2PncCfGvZH38EEJzBvQblzscHKJxtCsbk0+VY7+22CB7F
GoeV53csX1op0sg/qY+kJKD5417yFADC+R5QXq+anPaJJrH0V054ZkwKMuhI
9AI/OQEiRBgGVFpddr6KlbkKtxBDfq1oxoZNPnsLtcu+tftY79McVpEf4sA+
M6n00Gkai0RhsA3mPfe6Y5t0lDY88G51ZRpMoKR++BIklUy0igBJdis5qnaF
56whHtXtgxlUZpft7Ew0Q/MyP87G+w2lHwmbRaTYNLV1e17O+GMSitzHWRHB
XvNBeifeYhnVaMUQZH1yx7blw9NPFD1vAlrnzdc1mrEQB07atGp0WYjLG2pE
k2Yt2F8KRQ7vL9dtD1EHrQK1v+3skiYQx1nqDgYY8jy7rWpNLBJRx/deI6ib
GiAnXZKaZ20DhoZqGJMfhF2GZIJlsESn+85tZuZ+0Gwbui7eBCpRsvhKRDgb
N3z9ySZdsbMnGkpH7DJdUj+yIPzYgxgv+zL7RuW/HFI2X8koqkDhatd8ujHG
t3qTjUjsH9GxMRZc7IY+obOO4w9AknEvrieOhBmY+fEroffbQXKCrxrm90Dy
gxvKlkdilchRrfk7w3PnsezvNe9OUOcWllboyJIwOVruqRuP04DKXzIw0hOv
1eKSc0OmzeS++6EBFkTcne6yO0R+CxAtuRfNX/gzcWOsby+ETwUohpq8LJ9Y
8MCqN38M3PcIgEVYjPJSfKx3FWf6Mkkoa6Xqj+9hm6lcUUcmEdmIZnUXQBcY
ddbFEMleFM21/W0bzFMREm1HmiuHmdE64cuKgnUaPrh2/ZsXZVeVcQhdTBeU
DGGFzTMvteW9ejlFBVJJ4NTjFUudpgzykqrjAUqUhGjCUJ35qUSPKOmBOnc4
z1Mawnw57LKG69VcBcv2MnPI81e13Dn6KRM8O1b8WWGeVDawNx+qpbU3LzdH
CS/YE1fobJ5J6u5Zbdm0V0nxPEFZAj+138T87L0So4N982/PHh4+lF6yWi/q
J0EZmq2Fapm8fOOEK6wJpdg0jLm66ueS67QBtLhL+XzofTR0Xp7nbdJmbWly
9yZEfNGeRvfdX76z65kq9OuOcSlM2jbq3SqSwBeufpbbtDYC0OOWGpLYtcip
vUBKq7m1jyt0J7riZixuyxZyp9d+e4tz2UX6hVtO1jqPm2yn/2XWaa7Apm0Q
2vhjpr8aEVfuG00Ocveb0uZhm2PTHoWClTyvb68k+nyet6+7wDRxfOTgnEK0
WnVTJ2K7lNzRK11+Cb7PQfF3RnPc6g4LVHe+8NxJUYFnmRRXMq+oHCs9WbRL
tepUNjw7Fi753pJf6pXE/AW1da6mE55bkripDy7kZdx724KZ2j0sT0EL2o5U
oSK0Qt8goywls72L7RMH4GJojxo8pKrm09JKsTQ+A5MWG4uIDCLL0jzpPp98
VJmKNsbUxQbbISs1KGXj/LHX33vbFSLlhhJBu/IJRiQcuRnviZdCYWh9dsGC
RmPalF4QTynZ+76izsI19+MVpo2Zmo7TwIBcvVfdN9t+xNOOzFZ24d4rlXmG
xx9mChMtz86xXN+pFZ8FIL+EsTOm7eZ0uBSdGW2xHPiar/fvt5WxfqRGiYOF
DnyFdBEU3O+F/mg23LixG1p2EyS4ZiXnqJkoUeOIcgTu/KyVil206t9MExbT
MT0zgZMco+ONkI0thdRss8A1hYG0EQxOCo+a87nmHk5nj2m+DhrKBmm9RkK7
qF0xduP2nXwzfjtwX4HRvY8ptr8CKsQ9Y26FdJFf/Myic87x0iMRV/sNPywu
6P1crgQZ0s6SqhkpfPjj68Nz11RpQ205bJLvno9+hHOBpElm5ZoJI3W6srRR
hVjjjL+bwfebD3Od1JdRtMwYGAN2X8vYzWmtuV6+mbyQHK8Ir0YsO79mOzZZ
J4fGIrvfmSEYQF5TJQhalRpGtApIDr2qi1xQjvBob0J//KREF/l+Bt6BvODc
LIjvAg6hpWZ/4cGF1h3nYkgrVKUI7JZq7ZGyZEiMKA9od3QeWCaGKW7NdVdT
4HrJv4pn7vFzbCWsnn8IpEb9vlT1LQEerrY9ff3EcLA/eS3zbIXG2V1XmOFO
rZgPF8Ci2nIKkXdSQsMr/Do6u9S7pIKRTBN9pcYo3SFJX0N6Az5s1yhjvNA1
iEox871+OIRgkh8quKzN6A4Bm74uWGFyBmKt0ZLZzCiyt2YN0CEcMoEy2Gtl
D++wdF4efRmlqwwJyya+sgZjKtm4Juo6Kb7ZrCQB5eZxP421TPJmbHYL8WyE
e8IHEyysMiRk7clAf1cqDnlTnBW9e1sa+fWponqNL6BWIJJo8V65CyuMfhnv
g1VSrxPMaKZ/25sO0SvnkChzgV1JXkEEt7sm+vthl90FHweWyNXFaVtftll5
V8ze92rgke6XtFRiFQhuHnYzYISwpRGjwc+LbMdeH+7rKTOvKFnG8BnmBsGH
1lsigqUQ154tUWpoZimHE+crFIgnLiHDz2TmDbQN/m7eVkhOGhaEPk7svR6o
+2osgXXVvdJy01QLnqVikGUyg443acdMKzJP6aU/8owicrI+JLslIk6S+Zkh
KDPBtoW5CW23XprJfZ8LHBLkRP25nHJHWkpGjQWPWOqQnoMGSaU7z5pm5S3u
2SarmEUc2upb7Ot14aXUL5eQsh/T7T8ynutVuZ93+QiYTcH+dtYP9jKBd2xt
Yd/lOVLz4eKxB/WFyMp10BYmcPY4A6av6MG7L694dvMYf/igWQfOERW/YN0O
HjCm4vdF9gTHzDprBXrL8Tgcz8FNCT47YChxsryyja72pRsTttmCD7OjOut2
zrJI1RMh/sH3jd5UZGiPSpdR92mC/+c9JLkhomaX58QoTTDoDvwpHe1H5wqx
q4XhYJBt1k7qI7vEFREXowpfwigp6uV0jr0YG/L7U8sTETiFTIauf2zR6whP
lxqFp0gByncUo2qCd+l5S8E+lkxtHvZTjq+VXL1WakxVu98gYwvhmFnY0gh2
IQrIoYLcMuxS2CqR42jtTaCtJb7R8dmhwMI+aGUh22fLppw8MN5GizOjVj6X
9pm74KpzQBEQX0y9RXUaN2GRRdwp3Pay+UpOefIWuM+NpKv0kA0Ig83VrqLL
vykmNJjUJ9XCh/mjNUJNX1PNO1Zp/OrE8+nyQZJGooQYJvtFg0GW+au9YYNA
vLfvqs4axmGZwFz0e++lT+LMJDrKdEHyD05yA9rhn5ym6nZz2ePuxkLSMgcN
yJ9uGJjGtiwkVsNEzHOcRii63iZxo0Z9HfZcQ6HOVnvweikpWOEt1ZEk2TbS
rTPLOXqkrePye+ng5XULM+Z41ub7pA/0p/rp2Yo8BxxRHroZV3fREQpbhMND
2sFf6fKKe4zvGmn4yR66Pg6V0Rmw3B6Rrsr9KlIkVxqE5z0tpPXA/jJVp0Qm
9LV2JC+KSHN+hMGChSVDM0xmT7/q9UocDWZtsw8RV+Ag6swsPd9lnb9DRIMN
caQOo3ZopJMj+NJdNKNjVAbZA9uVckDIuOciXsAOP4eQlg4zV56gjBTI5WfG
PysdaSdeqzDMuHL6lc2Z4OO7k9XElgROuH31NKI5x7BZWu22mSHXfkwIU2x9
UxIrYhsN1hNkCJk4UzKw8QAW4YlTmeSX+iWmllHVYnhD96QNJ99GvgaEqhFt
gDzN0ZQgQzGGJMUlrQlXYMkCPOUvTqBQG1tnQi5XzZPt/BJPNzAv6IioQoM/
esA+xrvlICC45scHsZnrAM4QKcKOXqjniMDb/I1cH2U4kSU2dN2Z+rQ1baxU
+3gVPdiEZeTIqJ8x+iqZUz7I4JYz9cMq92vx7tCAamGxDf2DMMaqaE/+aEcD
q3tErY8RBuaj/muGr+g3j1ELhmeJUwunoW/t9Ia/CkKHNfig+PxXx08rZTJv
0cqa375MfsUziEPapPidp8c2GbgdFfFCboA2dHH3bdAPwibGI5VZQtc5j47V
VqElQDCouyunjLgp36W+TvrLl9BxiS+wJLn8wyicXz9OB0R6v7yADweQK92p
ntDoLRL2rGtHc4Tr7MMze4I5NEGhIFcoWLk0koY+YcAUpKW6i8gRnd5Pldze
GX5RTp501y88SRkMPxPkXWPvc6ShBioJPu7e61xe6hShEN7AU9UwlUQ+xvWs
9LC1nAZQ9a4BsVD8RmXJ6k3HvyXJ9+OzHoyWVoZ8wNe8koyMLaNso0Are/+R
AYP0qbWydBAqNGR4i/4BawL83OdQWeR2e0UjSnlvARLvVCJ/cAi3zKbB1x5w
8COTtiGPQiCugPWOzRHxtMQOJbdkViU8sKmm3I0/n4cdsJR3YP1k7hY3flUT
9b0wgSLPzd3IniOiHoGztMddb9y3acnjSGpNqrMOh8FJaXVOWyz1LH9/5Ka/
zkqaIJoIn4O2bBLaGtUVzo1qTRlchkeXolNxaLbbauphI5v27MUYLeFl3+dc
RNG/i2ksPWg8zazl4VYaUCE4ZiPbG368fPitKdAbn7sqa9ziBtAAubUWWdMr
iDMW1GidzFW9FEzYSTQ6t4lWyOJzhSPdaxYvWAUeKBAhxSINVw9e0HZWZzbG
TAdEoIu0RcQ3It4bXaaXLQPsAimGyChUINdypa3zOqmW3eB6UK7wmogy4/Om
FijFdVyhCejAFGlu37B5x91+vBYHptabBo1aq2ydWcBQj9b0PZ8Zpi3oZ0uB
HafjSI4HsMFmGWwF7cBc+1kK9IyhsMMJdRPkb7YYyhQhXPcrY4spc6chM/42
9VhB/aK9NpIYokdMaVDhgDv1IcyFmEe5H82WzkZdeloN3hERvacD6sbI0oB3
Ek7ZjFQCU+jSYdM1STUFEOH4PMSROS09rLYlotkYJ2MkZExC/mCR0ltLJ7lm
uOtMZyCFsUrJBC8F2RZ0j2ShOJN3suR/S3gcartXugWW4fulRaiwBJqi7EMF
nD0CsAFqMzBL51Puwxj98HjAWph5xUI2ipdcApP2anX88M8OUS2TOD4meqIy
PCkZuQ/u13a1olIws0PezUxwbpetK5DmdIu3zbzvQPMTL93TzlJZwcvPOlga
2ji791NzX3/HKzzXgs/dqo1t5sLYL5HWFypBFq8MUOH3fTJUDZOZ5u9hdHab
WVGhqAYPOzbMbVaxnPQdRUzk1LQUVv3xwRkRL8/Pma5HTguytGCHQkDBKOwc
nRnFCoH89DcjLwnvKWUJRz1z60OSghxDcui94/xiFJnti6pvmBMzldg6dDw/
q3lfY5jgidUPTqigRm3O635RWBvyJxOpnMvPw8sITLcWOMlrDrNBA7devfrq
j+2wlrp+kbbyRpHFNzMO27yFTJDymA+DuCSyWlp9d4cjrR0oGz++zVSDM7Hj
OAZ0eceSFZeIkdHQVldVbl6HNVmUmm8ZlcS1c3BAeB6EsZ5JpUokpwrKBLg5
jBYfLsgjacq4XOAPWfBsBCU9C542OtO2WLWokCwT3wXW0jqZKyQRN0hbwhxa
9UpdsszqnF/A6+uJqdQpecP5iz9pwTiWoWdnb4BnVuLUcS1ftgKtCz+n5/h+
DmKPnf31gqYlZvEKPPJwa/QQ9hWoCE8Cc0lpNyleqSX0+d3HVqA5+NhG0+L8
SbQkiiYAv/WCf9HxaaSiv6haFSZqOkfFqpaxvmq906KieC8Uwyp2XTGEnLDH
Nq/GDqFGxkf0vNl3dbxP7cRBfoKUnRnzo3qS5OqlMILkSlhvhMwz/wMqZMRq
1LKB+U4v3yvFnXa0XbPwRXTvtdOZNOFv7N/wfB6r7zVeeKe09ech7MTYo9bo
SRu8nyvAPkQFXSxsqzR+Rs8X9kJMHaisNVsskYna8lehC+uYZ3ILRK9MrsEP
LCBnw80joGTVRU5rUnMxFlGq3E4aIQ+wKESEU86JSbKXmH3xICbl9OCONMr0
6HT3FdkPym13bRGJzr/JGOHwkh9DanL09XX1/MD3/ugwAym7AcdNL+ueie1W
y2B5AGArhD7FdhUxZHZ0cajoX0//jMhoJ4WewsVnjxc6fjS1bCQctZ6jjCCv
PXGhU3crcjh0M3AYFbpQkkUapg7HqDCfZPSqHzFVZsvHYqLH9P/whfD/B/j/
RAATG6CRk4u9rZGTNcL/BXyU1M1lbmRzdHJlYW0KZW5kb2JqCjMwIDAgb2Jq
IDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRW5jb2RpbmcgMTE0
IDAgUgovRmlyc3RDaGFyIDExCi9MYXN0Q2hhciAxMjIKL1dpZHRocyAxMTUg
MCBSCi9CYXNlRm9udCAvR0VaTFBBK0NNUjEwCi9Gb250RGVzY3JpcHRvciAy
OCAwIFIKPj4gZW5kb2JqCjI4IDAgb2JqIDw8Ci9Bc2NlbnQgNjk0Ci9DYXBI
ZWlnaHQgNjgzCi9EZXNjZW50IC0xOTQKL0ZvbnROYW1lIC9HRVpMUEErQ01S
MTAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDY5Ci9YSGVpZ2h0IDQzMQovRm9u
dEJCb3ggWy0yNTEgLTI1MCAxMDA5IDk2OV0KL0ZsYWdzIDQKL0NoYXJTZXQg
KC9mZi9maS9xdW90ZWRibHJpZ2h0L3BhcmVubGVmdC9wYXJlbnJpZ2h0L3Bs
dXMvY29tbWEvaHlwaGVuL3BlcmlvZC96ZXJvL29uZS90d28vdGhyZWUvZm91
ci9maXZlL3NpeC9zZXZlbi9laWdodC9uaW5lL2NvbG9uL3NlbWljb2xvbi9l
cXVhbC9BL0IvQy9EL0UvRi9HL0gvSS9QL1IvUy9UL1YvVy9icmFja2V0bGVm
dC9xdW90ZWRibGxlZnQvYnJhY2tldHJpZ2h0L2EvYi9jL2QvZS9mL2cvaC9p
L2ovay9sL20vbi9vL3AvcS9yL3MvdC91L3Yvdy94L3kveikKL0ZvbnRGaWxl
IDI5IDAgUgo+PiBlbmRvYmoKMTE1IDAgb2JqCls1ODMgNTU2IDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCAwIDAgMCAw
IDAgMzg5IDM4OSAwIDc3OCAyNzggMzMzIDI3OCAwIDUwMCA1MDAgNTAwIDUw
MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDAgNzc4IDAgMCAw
IDc1MCA3MDggNzIyIDc2NCA2ODEgNjUzIDc4NSA3NTAgMzYxIDAgMCAwIDAg
MCAwIDY4MSAwIDczNiA1NTYgNzIyIDAgNzUwIDEwMjggMCAwIDAgMjc4IDUw
MCAyNzggMCAwIDAgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMDYgNTAwIDU1NiAy
NzggMzA2IDUyOCAyNzggODMzIDU1NiA1MDAgNTU2IDUyOCAzOTIgMzk0IDM4
OSA1NTYgNTI4IDcyMiA1MjggNTI4IDQ0NCBdCmVuZG9iagoxMTQgMCBvYmog
PDwKL1R5cGUgL0VuY29kaW5nCi9EaWZmZXJlbmNlcyBbIDAgLy5ub3RkZWYg
MTEvZmYvZmkgMTMvLm5vdGRlZiAzNC9xdW90ZWRibHJpZ2h0IDM1Ly5ub3Rk
ZWYgNDAvcGFyZW5sZWZ0L3BhcmVucmlnaHQgNDIvLm5vdGRlZiA0My9wbHVz
L2NvbW1hL2h5cGhlbi9wZXJpb2QgNDcvLm5vdGRlZiA0OC96ZXJvL29uZS90
d28vdGhyZWUvZm91ci9maXZlL3NpeC9zZXZlbi9laWdodC9uaW5lL2NvbG9u
L3NlbWljb2xvbiA2MC8ubm90ZGVmIDYxL2VxdWFsIDYyLy5ub3RkZWYgNjUv
QS9CL0MvRC9FL0YvRy9IL0kgNzQvLm5vdGRlZiA4MC9QIDgxLy5ub3RkZWYg
ODIvUi9TL1QgODUvLm5vdGRlZiA4Ni9WL1cgODgvLm5vdGRlZiA5MS9icmFj
a2V0bGVmdC9xdW90ZWRibGxlZnQvYnJhY2tldHJpZ2h0IDk0Ly5ub3RkZWYg
OTcvYS9iL2MvZC9lL2YvZy9oL2kvai9rL2wvbS9uL28vcC9xL3Ivcy90L3Uv
di93L3gveS96IDEyMy8ubm90ZGVmXQo+PiBlbmRvYmoKNTIgMCBvYmogPDwK
L1R5cGUgL1BhZ2VzCi9Db3VudCA1Ci9LaWRzIFsyMiAwIFIgNTUgMCBSIDcx
IDAgUiA4MSAwIFIgODUgMCBSXQo+PiBlbmRvYmoKMTE2IDAgb2JqIDw8Ci9U
eXBlIC9PdXRsaW5lcwovRmlyc3QgNyAwIFIKL0xhc3QgMTkgMCBSCi9Db3Vu
dCA0Cj4+IGVuZG9iagoxOSAwIG9iaiA8PAovVGl0bGUgMjAgMCBSCi9BIDE3
IDAgUgovUGFyZW50IDExNiAwIFIKL1ByZXYgMTUgMCBSCj4+IGVuZG9iagox
NSAwIG9iaiA8PAovVGl0bGUgMTYgMCBSCi9BIDEzIDAgUgovUGFyZW50IDEx
NiAwIFIKL1ByZXYgMTEgMCBSCi9OZXh0IDE5IDAgUgo+PiBlbmRvYmoKMTEg
MCBvYmogPDwKL1RpdGxlIDEyIDAgUgovQSA5IDAgUgovUGFyZW50IDExNiAw
IFIKL1ByZXYgNyAwIFIKL05leHQgMTUgMCBSCj4+IGVuZG9iago3IDAgb2Jq
IDw8Ci9UaXRsZSA4IDAgUgovQSA1IDAgUgovUGFyZW50IDExNiAwIFIKL05l
eHQgMTEgMCBSCj4+IGVuZG9iagoxMTcgMCBvYmogPDwKL05hbWVzIFsoRG9j
LVN0YXJ0KSAyNiAwIFIgKFZlY3RvcnMpIDUzIDAgUiAocGFnZS4xKSAyNSAw
IFIgKHBhZ2UuMikgNTcgMCBSIChwYWdlLjMpIDczIDAgUiAocGFnZS40KSA4
MyAwIFIgKHBhZ2UuNSkgODcgMCBSIChzZWN0aW9uLjEpIDYgMCBSIChzZWN0
aW9uLjIpIDEwIDAgUiAoc2VjdGlvbi4zKSAxNCAwIFIgKHNlY3Rpb24uNCkg
MTggMCBSXQovTGltaXRzIFsoRG9jLVN0YXJ0KSAoc2VjdGlvbi40KV0KPj4g
ZW5kb2JqCjExOCAwIG9iaiA8PAovS2lkcyBbMTE3IDAgUl0KPj4gZW5kb2Jq
CjExOSAwIG9iaiA8PAovRGVzdHMgMTE4IDAgUgo+PiBlbmRvYmoKMTIwIDAg
b2JqIDw8Ci9UeXBlIC9DYXRhbG9nCi9QYWdlcyA1MiAwIFIKL091dGxpbmVz
IDExNiAwIFIKL05hbWVzIDExOSAwIFIKL1BhZ2VNb2RlIC9Vc2VPdXRsaW5l
cyAKL09wZW5BY3Rpb24gMjEgMCBSCj4+IGVuZG9iagoxMjEgMCBvYmogPDwK
L0F1dGhvcigpL1RpdGxlKCkvU3ViamVjdCgpL0NyZWF0b3IoTGFUZVggd2l0
aCBoeXBlcnJlZiBwYWNrYWdlKS9Qcm9kdWNlcihwZGZlVGVYLTEuMjFhKS9L
ZXl3b3JkcygpCi9DcmVhdGlvbkRhdGUgKEQ6MjAwNTExMTEyMDUwMTQtMDUn
MDAnKQovUFRFWC5GdWxsYmFubmVyIChUaGlzIGlzIHBkZmVUZVgsIFZlcnNp
b24gMy4xNDE1OTItMS4yMWEtMi4yIChXZWIyQyA3LjUuNCkga3BhdGhzZWEg
dmVyc2lvbiAzLjUuNCkKPj4gZW5kb2JqCnhyZWYKMCAxMjIKMDAwMDAwMDAw
MSA2NTUzNSBmIAowMDAwMDAwMDAyIDAwMDAwIGYgCjAwMDAwMDAwMDMgMDAw
MDAgZiAKMDAwMDAwMDAwNCAwMDAwMCBmIAowMDAwMDAwMDAwIDAwMDAwIGYg
CjAwMDAwMDAwMDkgMDAwMDAgbiAKMDAwMDAwNTUyNyAwMDAwMCBuIAowMDAw
MDgwMjczIDAwMDAwIG4gCjAwMDAwMDAwNTQgMDAwMDAgbiAKMDAwMDAwMDA5
OSAwMDAwMCBuIAowMDAwMDA1NTg4IDAwMDAwIG4gCjAwMDAwODAxODcgMDAw
MDAgbiAKMDAwMDAwMDE0NCAwMDAwMCBuIAowMDAwMDAwMTcxIDAwMDAwIG4g
CjAwMDAwMDg1NzYgMDAwMDAgbiAKMDAwMDA4MDA5OSAwMDAwMCBuIAowMDAw
MDAwMjE3IDAwMDAwIG4gCjAwMDAwMDAyNDMgMDAwMDAgbiAKMDAwMDAxNDMy
MiAwMDAwMCBuIAowMDAwMDgwMDI0IDAwMDAwIG4gCjAwMDAwMDAyODkgMDAw
MDAgbiAKMDAwMDAwMDMxNCAwMDAwMCBuIAowMDAwMDA1MTI0IDAwMDAwIG4g
CjAwMDAwMDU2NTAgMDAwMDAgbiAKMDAwMDAwMDM2NSAwMDAwMCBuIAowMDAw
MDA1NDA0IDAwMDAwIG4gCjAwMDAwMDU0NjYgMDAwMDAgbiAKMDAwMDAwNTI1
MSAwMDAwMCBuIAowMDAwMDc4NTQxIDAwMDAwIG4gCjAwMDAwNjQ3NjQgMDAw
MDAgbiAKMDAwMDA3ODM4MiAwMDAwMCBuIAowMDAwMDY0MjU2IDAwMDAwIG4g
CjAwMDAwNjAxNzcgMDAwMDAgbiAKMDAwMDA2NDA5NCAwMDAwMCBuIAowMDAw
MDU5ODc4IDAwMDAwIG4gCjAwMDAwNTc0NTIgMDAwMDAgbiAKMDAwMDA1OTcx
NyAwMDAwMCBuIAowMDAwMDU3MTUzIDAwMDAwIG4gCjAwMDAwNTQ3MzkgMDAw
MDAgbiAKMDAwMDA1Njk5MiAwMDAwMCBuIAowMDAwMDUzOTgzIDAwMDAwIG4g
CjAwMDAwNDg3MzcgMDAwMDAgbiAKMDAwMDA1MzgyMyAwMDAwMCBuIAowMDAw
MDQ3OTkwIDAwMDAwIG4gCjAwMDAwNDE0NDEgMDAwMDAgbiAKMDAwMDA0Nzgz
MCAwMDAwMCBuIAowMDAwMDQwODU1IDAwMDAwIG4gCjAwMDAwMzg2NzkgMDAw
MDAgbiAKMDAwMDA0MDY5NyAwMDAwMCBuIAowMDAwMDM4MzcxIDAwMDAwIG4g
CjAwMDAwMzY0NTUgMDAwMDAgbiAKMDAwMDAzODIxMCAwMDAwMCBuIAowMDAw
MDc5ODYzIDAwMDAwIG4gCjAwMDAwMDg1MTQgMDAwMDAgbiAKMDAwMDAwODYz
NyAwMDAwMCBuIAowMDAwMDA4MzQ0IDAwMDAwIG4gCjAwMDAwMDU4MDMgMDAw
MDAgbiAKMDAwMDAwODQ1MiAwMDAwMCBuIAowMDAwMDM1OTA3IDAwMDAwIG4g
CjAwMDAwMzE0MzkgMDAwMDAgbiAKMDAwMDAzNTc1MCAwMDAwMCBuIAowMDAw
MDMxMTI0IDAwMDAwIG4gCjAwMDAwMjkwNzkgMDAwMDAgbiAKMDAwMDAzMDk2
OSAwMDAwMCBuIAowMDAwMDI4NzYxIDAwMDAwIG4gCjAwMDAwMjY0OTkgMDAw
MDAgbiAKMDAwMDAyODYwMyAwMDAwMCBuIAowMDAwMDI1ODg3IDAwMDAwIG4g
CjAwMDAwMjEyNzUgMDAwMDAgbiAKMDAwMDAyNTcyOSAwMDAwMCBuIAowMDAw
MDExNTc4IDAwMDAwIG4gCjAwMDAwMTE0MDggMDAwMDAgbiAKMDAwMDAwODgw
MSAwMDAwMCBuIAowMDAwMDExNTE2IDAwMDAwIG4gCjAwMDAwMjA1MTIgMDAw
MDAgbiAKMDAwMDAxODA3NCAwMDAwMCBuIAowMDAwMDIwMzU0IDAwMDAwIG4g
CjAwMDAwMTc2ODQgMDAwMDAgbiAKMDAwMDAxNTYxMyAwMDAwMCBuIAowMDAw
MDE3NTI5IDAwMDAwIG4gCjAwMDAwMTQzODMgMDAwMDAgbiAKMDAwMDAxNDE1
MiAwMDAwMCBuIAowMDAwMDExNzE3IDAwMDAwIG4gCjAwMDAwMTQyNjAgMDAw
MDAgbiAKMDAwMDAxNTQ5NyAwMDAwMCBuIAowMDAwMDE1MzI3IDAwMDAwIG4g
CjAwMDAwMTQ1MjIgMDAwMDAgbiAKMDAwMDAxNTQzNSAwMDAwMCBuIAowMDAw
MDE3OTc1IDAwMDAwIG4gCjAwMDAwMTc4ODIgMDAwMDAgbiAKMDAwMDAyMTA1
NCAwMDAwMCBuIAowMDAwMDIwODE2IDAwMDAwIG4gCjAwMDAwMjYzMDQgMDAw
MDAgbiAKMDAwMDAyNjEyNyAwMDAwMCBuIAowMDAwMDI4OTkyIDAwMDAwIG4g
CjAwMDAwMjg5NjEgMDAwMDAgbiAKMDAwMDAzMTM1MiAwMDAwMCBuIAowMDAw
MDMxMzI1IDAwMDAwIG4gCjAwMDAwMzYyODIgMDAwMDAgbiAKMDAwMDAzNjEy
NSAwMDAwMCBuIAowMDAwMDM4NTk1IDAwMDAwIG4gCjAwMDAwMzg1NzEgMDAw
MDAgbiAKMDAwMDA0MTI5NyAwMDAwMCBuIAowMDAwMDQxMTAzIDAwMDAwIG4g
CjAwMDAwNDg0NTYgMDAwMDAgbiAKMDAwMDA0ODIzOCAwMDAwMCBuIAowMDAw
MDU0NDM5IDAwMDAwIG4gCjAwMDAwNTQyMzUgMDAwMDAgbiAKMDAwMDA1NzM2
OCAwMDAwMCBuIAowMDAwMDU3MzQ2IDAwMDAwIG4gCjAwMDAwNjAwOTMgMDAw
MDAgbiAKMDAwMDA2MDA3MSAwMDAwMCBuIAowMDAwMDY0NjE1IDAwMDAwIG4g
CjAwMDAwNjQ1MjMgMDAwMDAgbiAKMDAwMDA3OTM3MCAwMDAwMCBuIAowMDAw
MDc4OTkzIDAwMDAwIG4gCjAwMDAwNzk5NTAgMDAwMDAgbiAKMDAwMDA4MDM0
NSAwMDAwMCBuIAowMDAwMDgwNjAyIDAwMDAwIG4gCjAwMDAwODA2NDEgMDAw
MDAgbiAKMDAwMDA4MDY3OSAwMDAwMCBuIAowMDAwMDgwODA3IDAwMDAwIG4g
CnRyYWlsZXIKPDwKL1NpemUgMTIyCi9Sb290IDEyMCAwIFIKL0luZm8gMTIx
IDAgUgovSUQgWzwwOUU2MjBBQjM4QUREQTA0MzVBMUFEMDRGMjU5MzhCQj4g
PDA5RTYyMEFCMzhBRERBMDQzNUExQUQwNEYyNTkzOEJCPl0KPj4Kc3RhcnR4
cmVmCjgxMDcwCiUlRU9GCg==

--0-902339947-1131768683=:93603--

\start
Date: Sat, 12 Nov 2005 08:25:28 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#229 Axiom Output in Documentation] (new) 

One of the purposes of MathAction is to allow Axiom commands
to be including in web pages and have the Axiom output
automatically generated and displayed on the page. The Axiom
commands are wrapped with syntax that looks like a LaTeX
environment::

  !\begin{axiom}
  integrate(sin x, x)
  \end{axiom}

but although MathAction uses LaTeX for formatting, the Axiom
commands are not actually processed by LaTeX. Instead they
are processed by the pre-processor of the page source that is
part of the LatexWiki package (written in Python).

Preprocessing During Weave

  The ability to automatically include the output of Axiom
commands should be available not only in MathAction web
pages but in all Axiom documentation. Since Axiom uses
[Pamphlet Files] (noweb [Literate Programming]) for everything,
this means that the pre-processing of Axiom pseudo-environments
could be done during the 'weave' operation pre-processing that
generates LaTeX source from pamphlet file source.

Preprocessing in LaTeX

  Alternatively, LaTeX itself could be extended to process
these special environment commands in a manner similar to
the way GraphViz commands are currently handled. In this
case the LaTeX coding for the !\begin{axiom} environment
would first look for a corresponding Axiom output file. If
it exists, then the contents of that file would be simply
included at that point in the LaTeX document. If it does not
exist, then the text content of the environment, i.e. the
Axiom commands, would be written to an Axiom input file.
At the end of the LaTeX pass, if any Axiom input files have
been generated, then Axiom would be run (probably with the
help of an appropriate shell script) to process these input
files and generate corresponding output files. Finally,
LaTeX is run again to generate the complete dvi file in the
usual manner.

Axiom Output in Pamphlet Files on MathAction

  Adding Axiom output to pamphlet files on MathAction will be
quite easy because the program logic to do this already exists
at part of the Pamphlet page type. However at this time this
logic is not applied to the pamphlet part of the page itself
but only to the StructuredText part of the page which follows
the \\end{document} command and usually consists mostly of
comments.

The difference is that the StructuredText part is rendered
as HTML with embedded images, while the pamphlet part is
rendered directly as 'dvi' and 'pdf' files linked from the
pamphlet first page thumbnail image. This extension is straight
forward but should only be done when support of included Axiom
commands is also available outside the MathAction environment.

\start
Date: Sat, 12 Nov 2005 08:27:55 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#230 IssueTracker input form should allow preview] (new) 

Because describing an issue complete with Axiom commands and/or
LaTeX mathematics can be quite complex, the IssueTracker
'Add a new issue' form should permit the user to 'Preview' the
issue report in the same way as comments can be previewed on
other pages on MathAction.

\start
Date: Sat, 12 Nov 2005 15:20:22 -0600
From: MathAction (anonimowy)
To: MathAction
Subject: [#231 simplify working on matrices] (new) 

It would be very nice if function simplify could operate on matrices,
simplifying each element.

\start
Date: Sat, 12 Nov 2005 17:42:33 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#232 Trace causes Bind Stack Overflow from erroneous input] (new) 

                        AXIOM Computer Algebra System
              Version of Tuesday November 30, 2004 at 21:11:14
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

(1) -> f == (-3.0)**n
                                                                   Type: Void
(2) -> )set mess autoload off
(2) -> eval(f, n-3)
   Compiling body of rule f to compute value of type Expression Float
   There are 10 exposed and 4 unexposed library operations named eval
      having 2 argument(s) but none was determined to be applicable.
      Use HyperDoc Browse, or issue
                              )display op eval
      to learn more about the available operations. Perhaps
      package-calling the operation or using coercions on the arguments
      will allow you to apply the operation.

   Cannot find a definition or applicable library operation named eval
      with argument type(s)
                              Expression Float
                             Polynomial Integer

      Perhaps you should use "@" to indicate the required return type,
      or "$" to specify which version of the function you need.
(2) -> )trace EXPR )math

   Packages traced:
      Expression Float, Expression Integer
   Parameterized constructors traced:
      EXPR
(2) -> eval(f, n-3)
1<enter Expression.coerce,83 :
 arg1= - 3.0
1>exit  Expression.coerce,83
   >> System error:
   Bind stack overflow.

protected-symbol-warn called with (NIL)
(2) -> eval(f, n=3)
1<enter Expression.coerce,83 :
 arg1= - 3.0
1>exit  Expression.coerce,83
   >> System error:
   Bind stack overflow.

protected-symbol-warn called with (NIL)

\start
Date: Sat, 12 Nov 2005 17:54:33 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#231 simplify working on matrices] use map

\begin{axiom}
A:=matrix _
 [[tan(x)**6 + 3*tan(x)**4 + 3*tan(x)**2 + 1, _
   tan(x)**5 + 3*tan(x)**3 + 3*tan(x)], _
  [tan(x)**4 + 3*tan(x)**2, _
   tan(x)**3 + 3*tan(x)]]

map(simplify,A)
\end{axiom}

\start
Date: Sat, 12 Nov 2005 19:17:34 -0500
From: William Sit
To: Karl Hegbloom
Subject: Re: [Bug?] "error in library; negative log"

Karl Hegbloom wrote:
> 
> Attached is a session log showing an error that I receive while
> attempting to produce a sequence from an expression in Axiom.  Maxima
> seems to have no trouble with the similar expression, and computing the
> value of the expression by hand, as you can see, seems to work fine
> also.
> 
> Another problem I have is that taking the limit of an expression
> containing (-1)^n always returns "failed", where my TI-89 Titanium
> calculator will give a finite limit.  For example:
> 
>  limit( 2 + (-2/%pi)^n, n=%plusInfinity )  ===> "failed"
> 
> ... but the TI-89t returns 2.

Mathematically, the limit is 2 since (-2/%pi) has absolute value less than 1,
and hence (-2/%pi)^n converges to 0. So TI-89t is correct and Axiom is wrong.

> The TI-89t says that the limit of (-1)^n as n approaches infinity is -1,
> implying that it believes that infinity is an odd number.  That kind of
> makes sense to me, since if you divide infinity in half, you still have
> infinity, and you keep adding 1 to get to infinity, making it odd.  If
> infinity is even then the answer should be 1, and if we can't know if
> infinity is even or odd, then the answer is uncertain or undefined.

No, TI-89t is wrong to say that limit (-1)^n is -1. The limit does not exist
because the sequence (-1)^n oscillates between 1 and -1. There is no number L
(the assumed limit) such that given any epsilon > 0, there is a natural number N
such that |(-1)^n - L| < epsilon for all n > N.

> On the other hand, the TI-89t says that lim ( (-1)^n * (n + 1)/n ) is
> undefined. 

This is correct since (n + 1)/n = 1 + 1/n has a limiting value 1 as n approaches
infinity, but (-1)^n makes that alternating in sign, and hence the limit does
not exist.

> But it already told me that lim (-1)^n = -1, and that lim (n
> + 1)/n = 1.  If the limit of a product is the product of the limits of
> the factors, then lim ( (-1)^n * (n + 1)/n ) should be -1, right?

See above. The limit of a product is the product of the limits of the factors,
provided each  factor has its own limit. Here (-1)^n does not have a limit. 
Note that if you consider (-1)^n * (1/n), then the limit would exist and is 0,
and the converse does not hold (it is not necessary that each factor has a limit
for the product to have a limit).

> Karl Hegbloom
> 
[coke and GCL ads snipped]
[AXIOM loading messages snipped, ditto below] 

To simplify the outputs and explanation, I have replaced your function f by
removing the initial addition of 2.0, which is not relevant to the discussion. I
have also replaced the floating point (-2.0/%pi::Float) by just a floating point
number -3.0. I have replaced the loop by a single eval. The follwwing transcript
is extracted from mine.

> (1) -> f == (-3.0)**n
                                                                   Type: Void
> (2) -> eval(f,n=3)

>    Compiling body of rule f to compute value of type Expression Float
>    >> Error detected within library code:
>    negative log

This is because you did not specify in the definition of f that n is an integer. 
Note that when you do not specify the type of arguments for a function, the
Interpreter may use any type specification as it sees fit at the time the
function is called. In this case, the Interpreter needs to figure out which eval
is to be used and it compiles f with target in Expression Float because n has
not been given a value and is treated as a symbol. The function f is technically
a constant function with value in Expression Float. 

> (3) -> f

               n
   (3)  (- 3.0)
                                                       Type: Expression Float

Note that you DID say f takes NO input argument. It would make a difference if
you had used:

> (2) ->  g n == (-3.0)**n
                                                                   Type: Void

> (3) ->  g 3
>   Compiling function g with type PositiveInteger -> Float
   (3)  - 27.0
                                                                  Type: Float
To see what happened in (2),

> )set mess bot on
> (4) -> f == (-3.0)**n
>   Compiled code for f has been cleared.
>   1 old definition(s) deleted for function or rule f
                                                                   Type: Void
> (5) -> eval(f,n=3)

[snipped]
> Function Selection for **
>     Arguments: (FLOAT,VARIABLE n)
>     Default target type: Expression Float

>[1]  signature:   (EXPR FLOAT,EXPR FLOAT) -> EXPR FLOAT
>     implemented: slot $$$ from EXPR FLOAT

>  Compiling body of rule f to compute value of type Expression Float
[snipped]
> Function Selection for eval
>      Arguments: (EXPR FLOAT,EQ POLY INT)
>      Default target type: Expression Float

> [1]  signature:   (EXPR FLOAT,EQ EXPR FLOAT) -> EXPR FLOAT
>      implemented: slot $$(Equation $) from EXPR FLOAT
[snipped]
>   >> Error detected within library code:
>   negative log

Now note that ** is taken from Expression Float, not Float and note the
signature of **. Axiom implements the exponentiation function in EXPR by
distinguishing whether the exponent is integer or otherwise.  The "otherwise"
cases are 
rather complicated, but suffices to say that a meaningful way to compute x**n
for a SYMBOL n with x:Expression Float in general is to use

   x**n == exp(n*log(x))

Now combine this with the fact you asked Axiom to FIRST compute f, THEN evaluate
by substituting n = 3, it should be clear why the computation produces the error
message above (in the special case x retracts to Float,
log is not defined for negative x). See float.spad:

   log x ==
      negative? x => error "negative log"
      zero? x => error "log 0 generated"

--- skip if you like
If anyone is inclined to get to the bottom of this, here is a summary of the
source:

  The implementation of ** in Expression (see expr.spad) in the case when a
symbol n is coerced to EXPR FLOAT is:

      x:% ** y:%                == x **$CF y

where CF is CombinatorialFunction(Float, Expression Float) package. We find in
combfunc.spad:

    x ** y               == 
      -- Do some basic simplifications
      is?(x,POWER) =>
        args : List F := argument first kernels x
        not(#args = 2) => error "Too many arguments to **"
        number?(first args) and number?(y) =>
          oppow [first(args)**y, second args]
        oppow [first args, (second args)* y]
      -- Generic case
      exp : Union(Record(val:F,exponent:Z),"failed") := isPower x
      exp case Record(val:F,exponent:Z) =>
        expr := exp::Record(val:F,exponent:Z)
        oppow [expr.val, (expr.exponent)*y]
      oppow [x, y]
and
    oppow   := operator(POWER::Symbol)$CommonOperators

>From CommonOperators:

    oppow   := operator(POWER, 2)

It is interesting to note what f is compiled into:

(6) -> f::InputForm

   (6)
   (/

     (+

       (+  (float 0 0 2)

         (*  (float 1 0 2)

           (**  (/ (float - 3 0 2) (float 1 0 2))

             (/  (+ (+ (float 0 0 2) (* (float 1 0 2) n)) (float 0 0 2))
              (float 1 0 2))
             )
           )
         )

      (float 0 0 2))

    (float 1 0 2))
                                                              Type: InputForm

Here (float a b c) means floating numbers using base c, with exponent b and
mantissa a, which is mathematically a*c^b.  So (float 0 0 2) is simply 0, (float
1 0 2) is 1, and (float - 3 0 2) is (-3.0).
Thus, one can see that the compiled Lisp code has a lot of cruft (adding 0 and
multiplying by 1 all over the place; however, this may be Lisp way of coercion
and I don't know how Lisp interacts with Axiom), but the compiled form for the
above f is equivalent to
           (** (float - 3 0 2) n)
(not surprising). Here n is a symbol and the expression belongs to the domain
Expression Float, and the only signature the Interpreter can find is what I
showed above.
---- 

Continuing with your output transcript:

> frame0 (5) -> -2.0/%pi::Float
> 
>    (5)  - 0.6366197723 6758134307 55351
>                                                                   Type: Float
> frame0 (6) -> % ** 2
> 
>    (6)  0.4052847345 6935108577 55179

                                                                    Type: Float
Here you actually supplied an integer 2 as exponent. This is implemented by
repeated multiplication (or something more clever such as Russian
multiplication). In Float, Axiom also implements ** by cases. See float.spad.

To do what you intend:
(7) -> g n == 2.0+(-2/%pi::Float)**n
   Compiled code for g has been cleared.
   1 old definition(s) deleted for function or rule g
                                                                   Type: Void
(8) -> [[i, g i] for i in 1..20]
   Compiling function g with type PositiveInteger -> Float

   (7)
   [[1.0,1.3633802276 3241865692], [2.0,2.4052847345 6935108578],
    [3.0,1.7419877245 3440408652], [4.0,2.1642557160 7494936303],
    [5.0,1.8954315634 2229166488], [6.0,2.0665703342 9093454695],
    [7.0,1.9576200089 3727145417], [8.0,2.0269799402 6329437858],
    [9.0,1.9828240365 7109059006], [10.0,2.0109345579 2830621047],
    [11.0,1.9930388442 2074156846], [12.0,2.0044316094 0760677601],
    [13.0,1.9971787498 2770734225], [14.0,2.0017960636 4247695142],
    [15.0,1.9988565903 7276863419], [16.0,2.0007279171 7661093314],
    [17.0,1.9995365935 3272349524], [18.0,2.0002950137 1971123349],
    [19.0,1.9998121884 3291212109], [20.0,2.0001195645 5708748421]]
                                                        Type: List List Float
   
\start
Date: Sat, 12 Nov 2005 18:52:52 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#233 Trace in Float caused Fatal Error] 

In the (old) Windows binary version 0.1.4, tracing the following function caused a fatal error.

\begin{verbatim}
                        AXIOM Computer Algebra System
              Version of Tuesday November 30, 2004 at 21:11:14
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

(1) -> )set mess autoload off
(1) -> h(n:INT):Float==(-3.0)**n
   Function declaration h : Integer -> Float has been added to
      workspace.
                                                                   Type: Void
(2) -> h(3)
   Compiling function h with type Integer -> Float

   (2)  - 27.0
                                                                  Type: Float
(3) -> )trace Float )math

   Packages traced:
      Float
   Parameterized constructors traced:
      FLOAT
(3) -> h(3)
1<enter Float.float,106 :
\end{verbatim}

\begin{verbatim}
 arg1= 3
 arg2= 0
 arg3= 10
 1<enter Float.increasePrecision,42 :
  arg1= 4
  1<enter Float.bits,53 :   1>exit  Float.bits,53 :
   68
  1<enter Float.bits,64 :
   arg1= 72
   1<enter Float.bits,53 :    1>exit  Float.bits,53 :
    68
  1>exit  Float.bits,64 :
   68
 1>exit  Float.increasePrecision,42 :
  68
 1<enter Float.**,86 :
  arg1= 10.0
  arg2= 0
  1<enter Float.=,38 :
   arg1= 10.0
   arg2= 0.0
   1<enter Float.order,57 :
    arg1= 10.0
   1>exit  Float.order,57 :
    3
   1<enter Float.order,57 :
    arg1= 0.0
   1>exit  Float.order,57 :
    - 1
  1>exit  Float.=,38 :
   false
 1>exit  Float.**,86 :
  1.0
 1<enter Float.*,66 :
  arg1= 3
  arg2= 1.0
  1<enter Float.bits,53 :   1>exit  Float.bits,53 :
   72
  1<enter Float.normalize,47 :
   arg1= 3.0
   1<enter Float.bits,53 :    1>exit  Float.bits,53 :
    72
  1>exit  Float.normalize,47 :
   3.0
 1>exit  Float.*,66 :
  3.0
 1<enter Float.decreasePrecision,46 :
  arg1= 4
  1<enter Float.bits,53 :   1>exit  Float.bits,53 :
   72
  1<enter Float.bits,64 :
   arg1= 68
   1<enter Float.bits,53 :    1>exit  Float.bits,53 :
    72
  1>exit  Float.bits,64 :
   72
 1>exit  Float.decreasePrecision,46 :
  72
 1<enter Float.normalize,47 :
  arg1= 3.0
  1<enter Float.bits,53 :   1>exit  Float.bits,53 :
   68
 1>exit  Float.normalize,47 :
  3.0
1>exit  Float.float,106 :
 3.0
1<enter Float.-,35 :
 arg1= 3.0
 1<enter Float.normalize,47 :
  arg1= - 3.0
  1<enter Float.bits,53 :   1>exit  Float.bits,53 :
   68
 1>exit  Float.normalize,47 :
  - 3.0
1>exit  Float.-,35 :
 - 3.0
1<enter Float.**,86 :
 arg1= - 3.0
 arg2= 3
 1<enter Float.=,38 :
  arg1= - 3.0
  arg2= 0.0
  1<enter Float.order,57 :
   arg1= - 3.0
  1>exit  Float.order,57 :
   1
  1<enter Float.order,57 :
   arg1= 0.0
  1>exit  Float.order,57 :
   - 1
 1>exit  Float.=,38 :
  false
 1<enter Float.=,38 :
  arg1= - 3.0
  arg2= 1.0
  1<enter Float.order,57 :
   arg1= - 3.0
  1>exit  Float.order,57 :
   1
  1<enter Float.order,57 :
   arg1= 1.0
  1>exit  Float.order,57 :
   0
 1>exit  Float.=,38 :
  false
 1<enter Float.bits,53 :  1>exit  Float.bits,53 :
  68
 1<enter Float.bits,64 :
  arg1= 72
  1<enter Float.bits,53 :   1>exit  Float.bits,53 :
   68
 1>exit  Float.bits,64 :
  68
 1<enter Float.bits,53 :  1>exit  Float.bits,53 :
  72
 1<enter Float.bits,53 :  1>exit  Float.bits,53 :
  72
 1<enter Float.bits,53 :  1>exit  Float.bits,53 :
  72
 1<enter Float.bits,64 :
  arg1= 68
  1<enter Float.bits,53 :   1>exit  Float.bits,53 :
   72
 1>exit  Float.bits,64 :
  72
 1<enter Float.normalize,47 :
  arg1= - 27.0
  1<enter Float.bits,53 :   1>exit  Float.bits,53 :
   68
 1>exit  Float.normalize,47 :
  - 27.0
1>exit  Float.**,86 :
 - 27.0

1<enter Float.<,41 :
 arg1= - 27.0
 arg2= 0.0
1>exit  Float.<,41 :
 true
1<enter Float.-,35 :
 arg1= - 27.0
 1<enter Float.normalize,47 :
  arg1= 27.0
  1<enter Float.bits,53 :   1>exit  Float.bits,53 :
   68
 1>exit  Float.normalize,47 :
  27.0
1>exit  Float.-,35 :
 27.0
1<enter Float.<,41 :
 arg1= 27.0
 arg2= 0.0
1>exit  Float.<,41 :
 false
1<enter Float.zero?,32 :
 arg1= 27.0
1>exit  Float.zero?,32 :
 false
1<enter Float.mantissa,17 :
 arg1= 27.0
1>exit  Float.mantissa,17 :
 27
1<enter Float.bits,64 :
 arg1= 5
 1<enter Float.bits,53 :  1>exit  Float.bits,53 :
  68
1>exit  Float.bits,64 :
 68
1<enter Float.outputFloating,158 :
 arg1= general()
1>exit  Float.outputFloating,158 :
 "general"
1<enter Float.outputFloating,158 :
 arg1= general()
1>exit  Float.outputFloating,158 :
 "general"
1<enter Float.outputFloating,158 :
 arg1= general()
1>exit  Float.outputFloating,158 :
 "general"
1<enter Float.zero?,32 :
 arg1= 27.0
1>exit  Float.zero?,32 :
 false
1<enter Float.negative?,34 :
 arg1= 27.0
1>exit  Float.negative?,34 :
 false
1<enter Float.digits,98 :  1<enter Float.bits,53 :  1>exit  Float.bits,53 :
  5
1>exit  Float.digits,98 :
 1
1<enter Float.exponent,19 :
 arg1= 27.0
1>exit  Float.exponent,19 :
 0
1<enter Float.mantissa,17 :
 arg1= 27.0
1>exit  Float.mantissa,17 :
 27
1<enter Float.bits,64 :
 arg1= 68
 1<enter Float.bits,53 :  1>exit  Float.bits,53 :
  5
1>exit  Float.bits,64 :
 5
1<enter Float.coerce,162
   >> System error:
   Caught fatal error [memory may be damaged]

protected-symbol-warn called with (NIL)
(3) ->
\end{verbatim}

[Not the entire transcript is displayed. Use edit to see the rest. ]

[Aside: Bill, the \begin{verbatim} \end{verbatim} does not work well. Can't even break the transcript into pieces to display correctly. The place where it stopped is kind of random too.]

This does not happen on the Wiki version, nor with the function 'h(n:INT):Float==3.0**n' in Windows.

\begin{axiom}
h(n:INT):Float==(-3.0)**n
h(3)
)trace Float )math
h(3)
\end{axiom}

\start
Date: Sat, 12 Nov 2005 20:51:21 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: [Aldor-l] Ann: ALLPROSE

Ralf,

I'm installing the necessary software from your site www.hemmecke.de/aldor
to build the AllProse environment. 

It would be useful to modify your Makefile to use symbolic names
for the notangle program calls. You do this for Make.

I have several versions of tangle/weave on my system (Knuth, Ramsey, Me0
and 'tangle' is an overloaded name here.

Now I see why you didn't want me to rewrite noweb out of Axiom.
Cansidering that the work you're doing looks quite useful I agree
with your suggestion.

Would you please include a link to Axiom on your site? We'd really
like to see the Aldor/Axiom community converge again. It's the same
work in the same language with the same goals but different tools.

\start
Date: Sat, 12 Nov 2005 20:56:45 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: ALLPROSE

Ralf,

Makefile.inc.nw contains \CVSID which appears to be an undefined tex tag.

\start
Date: Sat, 12 Nov 2005 21:13:40 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: ALLPROSE

Ralf,

\xAldor{} in Makefile.inc.nw expands to nothing. Thus the sentence
reads:

... the variable  is installed.

\start
Date: Sat, 12 Nov 2005 20:59:59 -0600
From: MathAction (Doug Stewart)
To: MathAction
Subject: [Axiom-mail] A newby question about eval and Expression

When I have  a polynomial of type

Polynomial Fraction Integer

and I use eval

zz1:=eval(qu1,[a1=62/100,a2=11,a3=6]);

it returns a type Expression Integer.

How do I change it back to   Polynomial Fraction Integer


I think the Expression thingy is bothering me later on in my program.

Any help would be nice.
Doug Stewart

\start
Date: Sat, 12 Nov 2005 21:09:04 -0600
From: MathAction (root)
To: MathAction
Subject: [Axiom-mail] [Axiom-mail] A newby question about eval and Expression

given

f:=a1*x^2 +a2*x+a3
eval(f,[a1=62/100,a2=11,a3=6])

i get:

 16  2
 -- x  + 11x + 6
 25
                         Type: Polynomial Fraction Integer


perhaps zz1 already has a type? try:

zz1::POLY(FRAC(INT)):=eval(f,[a1=62/100,a2=11,a3=6])

\start
Date: Sat, 12 Nov 2005 21:30:27 -0600
From: MathAction (Doug Stewart)
To: MathAction
Subject: [Axiom-mail] [Axiom-mail] [Axiom-mail] A newby question about eval and Expression

root wrote:

>given
>
>f:=a1*x^2 +a2*x+a3
>eval(f,[a1=62/100,a2=11,a3=6])
>
>i get:
>
> 16  2
> -- x  + 11x + 6
> 25
>                         Type: Polynomial Fraction Integer
>
>
>perhaps zz1 already has a type? try:
>
>zz1::POLY(FRAC(INT)):=eval(f,[a1=62/100,a2=11,a3=6])
>
Thanks for your help,
I think I have the latest version of Axiom for windows, just got it this 
week.
 here is the code


)clear all
digits 20
-- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer

Q:=(3*a2-a1^2)/9
R:=(9*a1*a2-27*a3-2*a1^3)/54
S:=(R+(Q^3+R^2)^(1/2))^(1/3)
T:=(R-(Q^3+R^2)^(1/2))^(1/3)
x1:=S+T-a1/3
x2:=-(S+T)/2-a1/3 + %i*sqrt(3)*(S-T)/2
x3:=-(S+T)/2-a1/3 - %i*sqrt(3)*(S-T)/2 

a5:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer;
a6:=('x-x11)  ::Polynomial Fraction Integer;

a7:=monicDivide(a5,a6,x) ;

a77:=a7.quotient  ::Polynomial Fraction Integer;
a78:=a7.remainder ::Polynomial Fraction Integer;


qu1 :=eval(a77,x11,x1)
rem1::POLY(FRAC(INT)):=eval(a78,x11,x1)

this gives an error message:

The form on the left hand side of an assignment must be a single 
variable ... supporting the setelt operation.

Doug Stewart

\start
Date: Sat, 12 Nov 2005 21:33:08 -0600
From: MathAction (root)
To: MathAction
Subject: [Axiom-mail] [Axiom-mail] [Axiom-mail] A newby question about eval and Expression

ummm, minor transcribing typo.... i actually called it with the args:

given

f:=a1*x^2 +a2*x+a3
eval(f,[a1=64/100,a2=11,a3=6])       <==== 64/100, not 62/100. sigh

i get:

 16  2
 -- x  + 11x + 6
 25
                         Type: Polynomial Fraction Integer


perhaps zz1 already has a type? try:

zz1::POLY(FRAC(INT)):=eval(f,[a1=62/100,a2=11,a3=6])

t

\start
Date: Sat, 12 Nov 2005 21:51:46 -0600
From: MathAction (root)
To: MathAction
Subject: A newby question about eval and Expression

hmmm, perhaps eval is broken but
eval(a78,x11,3) works

perhaps variable lookup is broken but
xtpd:=3
eval(x78,x11,xtpd) works

perhaps eval with a third arg of EXPR(INT) is broken but
xtpd2:Expression(Integer):=3
eval(x78,x11,xtpd2) works

perhaps eval fails if the third arg cannot be coerced to POLY(FRAC(INT)) but
xtpd2:Expression(Integer):=3*sqrt(2)
eval(x78,x11,xtpd2) works


next i tried changing the final line:

)clear all
digits 20
-- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer

Q:=(3*a2-a1^2)/9
R:=(9*a1*a2-27*a3-2*a1^3)/54
S:=(R+(Q^3+R^2)^(1/2))^(1/3)
T:=(R-(Q^3+R^2)^(1/2))^(1/3)
x1:=S+T-a1/3
x2:=-(S+T)/2-a1/3 + %i*sqrt(3)*(S-T)/2
x3:=-(S+T)/2-a1/3 - %i*sqrt(3)*(S-T)/2 

a5:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer;
a6:=('x-x11)  ::Polynomial Fraction Integer;

a7:=monicDivide(a5,a6,x) ;

a77:=a7.quotient  ::Polynomial Fraction Integer;
a78:=a7.remainder ::Polynomial Fraction Integer;


qu1 :=eval(a77,x11,x1)
m:=eval(a78,x11,x1)

and THAT works. at least here.

t

\start
Date: Sat, 12 Nov 2005 22:29:28 -0600
From: MathAction (Doug Stewart)
To: MathAction
Subject: A newby question about eval and Expression

root wrote:

>Changes http://page.axiom-developer.org/zope/mathaction/AxiomMail/diff
>--
>hmmm, perhaps eval is broken but
>eval(a78,x11,3) works
>
>  
>
cut

>a77:=a7.quotient  ::Polynomial Fraction Integer;
>a78:=a7.remainder ::Polynomial Fraction Integer;
>
>
>qu1 :=eval(a77,x11,x1)
>m:=eval(a78,x11,x1)
>
>and THAT works. at least here.
>
Yes that works but it gives me an Expression thingy  - I don't know 
anything about "Expression" What does "Expression" Meen?
But later on when I want to see a float output it won't let me becouse 
it can't change an Expression ...  to a Float????
I don't know enough yet to no why.
So can I change an Expression  INT to a FLOAT?

All I am trying to do is factor a qubic into a first and second order poly.
It works if the coeff are nice integers but I want it for floats. So I 
am doing it symbolicly and then trying to put in my numbers at the last. 
I am doing this mainly to learn Axiom. I can get my numbers real easy in 
Octave.

\start
Date: Sat, 12 Nov 2005 22:39:40 -0600
From: MathAction (root)
To: MathAction
Subject: A newby question about	eval and Expression

so if we try:

)clear all
digits 20
-- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer

Q:=(3*a2-a1^2)/9
R:=(9*a1*a2-27*a3-2*a1^3)/54
S:=(R+(Q^3+R^2)^(1/2))^(1/3)
T:=(R-(Q^3+R^2)^(1/2))^(1/3)
x1:=S+T-a1/3
x2:=-(S+T)/2-a1/3 + %i*sqrt(3)*(S-T)/2
x3:=-(S+T)/2-a1/3 - %i*sqrt(3)*(S-T)/2 

a5:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer;
a6:=('x-x11)  ::Polynomial Fraction Integer;

a7:=monicDivide(a5,a6,x) ;

a77:=a7.quotient  ::Polynomial Fraction Integer;
a78:=a7.remainder ::Polynomial Fraction Integer;


qu1 :=eval(a77,x11,x1)
m:=eval(a78,x11,x1)

eval(m,[a3=1.0, a2=1.0, a1=1.0])

does that give you what you want?

\start
Date: Sun, 13 Nov 2005 03:06:07 -0600
From: MathAction (Hans Peter Wuermli)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

Hi

What are my wrong expectations in the following interpreter session when using 
"typeOf" and "has"

(1) -> e:=(1+n)/(n+k)
        n + 1
   (1)  -----
        n + k
                                           Type: Fraction Polynomial Integer
(2) -> typeOf e
   (2)  Fraction Polynomial Integer
                                                                 Type: Domain
(3) -> typeOf (e) has Fraction Polynomial Integer
   (3)  false

In (3) I would expect true.
 
\start
Date: 13 Nov 2005 11:44:41 +0100
From: Martin Rubey
To: Karl Hegbloom
Subject: Re: [Bug?] "error in library; negative log"

If you file a bug report concerning limit((-1/2)^n,n=%plusInfinity), I'll file
a patch :-)

\start
Date: 13 Nov 2005 12:51:47 +0100
From: Martin Rubey
To: Hans Peter Wuermli
Subject: Re: Expression problems

Dear Hans Peter,

Hans Peter W=FCrmli Hans Peter Wuermli writes:

> I am struggling with dealing with Expressions. For most sake and purposes I
> can find a fix and solve my small problems, but I never feel very assured.

Yes. The EXPR domain is *not nice*

> As there doesn't seem to exist a parse tree object, I should ask a different
> question: how are you analysing an Expression?

Could you elaborate a bit on what you mean by analysing an Expression? I.e.,
could you please provide an example.

I reached the conclusion that the EXPR domain badly needs an update. However,
for the time being ...

On the other hand, "parsing" an expression is quite certainly *not* the way you
should do things with axiom.

Still, more often than not, EXPR is wrong and you are right...

\start
Date: 13 Nov 2005 13:01:41 +0100
From: Martin Rubey
To: Francois Maltey
Subject: Re: Expression problems

Francois Maltey writes:

> Hello everybody ! Hans, Bill and others...
> 
> > I am struggling with dealing with Expressions. For most sake and purposes I 
> > can find a fix and solve my small problems, but I never feel very assured.
> 
> I have the same problem when I try to expand cos(2*x) in cos(x)^2-sin(x)^2.
> 
> The expand(cos(x+y)) is right, but expand (cos(2*x)) remains cos(2*x).
> 
> Martin and Bill help me, but I can't see the pretty way to write
> my own expand which also compute for cos(2*x).

I believe that the "correct" way to do this is to patch the existing domains.

You did not respond to 

http://lists.nongnu.org/archive/html/axiom-developer/2005-06/msg00294.html

so I thought that you managed to get the results you wanted. Are you able to
program in SPAD or Aldor already? I can help, if necessary. 

Maybe you could find out where the code for Chebyshev expansion should be
inserted, possibly using the )trace facility - also described on MathAction:
look at DebuggingAxiom.

WE NEED MORE ALGEBRA DEVELOPERS!

\start
Date: Sun, 13 Nov 2005 05:27:51 -0600
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

Hans Peter Wuermli writes:

> Hi
 
> What are my wrong expectations in the following interpreter session
> when using "typeOf" and "has"
 
> (1) -> e:=(1+n)/(n+k)
>         n + 1
>    (1)  -----
>         n + k
>                                            Type: Fraction Polynomial Integer
> (2) -> typeOf e
>    (2)  Fraction Polynomial Integer
>                                                                  Type: Domain
> (3) -> typeOf (e) has Fraction Polynomial Integer
>    (3)  false
> 
> In (3) I would expect true.

Axiom is correct. "A has B" tests whether the Domain or Category A is a member
of *Category* B or satisfies the axiom B. So 

Fraction Polynomial Integer has Ring

or

Field has Ring

would return true, similarly

PF 5 has commutative("*")

returns true.

\start
Date: Sun, 13 Nov 2005 05:49:02 -0600
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] A newby question about eval and Expression

Dear Doug,

there are two issues in your code:


Doug Stewart writes:

> )clear all
> digits 20
> -- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer
> 
> Q:=(3*a2-a1^2)/9
> R:=(9*a1*a2-27*a3-2*a1^3)/54
> S:=(R+(Q^3+R^2)^(1/2))^(1/3)
> T:=(R-(Q^3+R^2)^(1/2))^(1/3)
> x1:=S+T-a1/3

note that x1 is *not* a polynomial. Not even a rational function.

> x2:=-(S+T)/2-a1/3 + %i*sqrt(3)*(S-T)/2
> x3:=-(S+T)/2-a1/3 - %i*sqrt(3)*(S-T)/2 
> 
> a5:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer;
> a6:=('x-x11)  ::Polynomial Fraction Integer;
> 
> a7:=monicDivide(a5,a6,x) ;
> 
> a77:=a7.quotient  ::Polynomial Fraction Integer;
> a78:=a7.remainder ::Polynomial Fraction Integer;
> 
> 
> qu1 :=eval(a77,x11,x1)
> rem1::POLY(FRAC(INT)):=eval(a78,x11,x1)
> 
> this gives an error message:
> 
> The form on the left hand side of an assignment must be a single 
> variable ... supporting the setelt operation.

The notation "::" is a shorthand for "coerce". But then, this is bad
syntax. You can either say

rem1:POLY(FRAC(INT)):=eval(a78,x11,x1)

or

rem1:=eval(a78,x11,x1)::POLY(FRAC(INT))

However, since x1 is not a polynomial, both will fail.

The domain "Expression Integer" is the domain of all expressions you can form
with coefficients being integers. For example:

sin(x)^2+cos(x)^2-1

or

5^(n/2)

or

%pi*sum(1/i, i=1..n)

...

However, if you *can* avoid this domain (often you can't), try to do so, since
it has a major drawback:

A computer cannot test reliably whether some element of Expression Integer is
zero or not. Axiom tries, but often fails. For example, the first example above
is not zero for Axiom...

(MuPAD, Mathematica and Maple try harder, but they often fail, too)

Note that this problem does not arise for many other domains: you can test for
zero in

Integer,
Polynomial Integer,
AlgebraicNumber,
PrimeField 5
Matrix Integer,
Fraction Polynomial PrimeField 1783

and so on.

\start
Date: Sun, 13 Nov 2005 06:22:49 -0600
From: MathAction (Hans Peter Wuermli)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

>
> Axiom is correct. "A has B" tests whether the Domain or Category A is a
> member of *Category* B or satisfies the axiom B. So
>
> Fraction Polynomial Integer has Ring
>
> or
>
> Field has Ring
>
> would return true, similarly
>
> PF 5 has commutative("*")
>
> returns true.

Thank you, I think I understand, but how then would you assert that something 
is in a Domain? I tried

typeOf(3)=Integer

but such a simple solution doesn't work.

\start
Date: Sun, 13 Nov 2005 06:50:25 -0600
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

Hans Peter Wuermli Hans Peter Wuermli writes:

> but how then would you assert that something is in a Domain? I tried
> 
> typeOf(3)=Integer
> 
> but such a simple solution doesn't work.

You got a quite tricky question there, really. If you are doing something else
then trying to understand how axiom is doing things, it's very likely that you
are on the wrong track. What are you trying to accomplish?

As far as I know, typeOf is only defined in the Interpreter. The domain ANY
provides a function domainOf which returns an element of OutputForm.

You can sometimes test whether something is "retractable" to a given domain
using "retractIfCan"...

\start
Date: Sun, 13 Nov 2005 08:06:04 -0600
From: MathAction (Hans Peter Wuermli)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

Dear Martin

> > but how then would you assert that something is in a Domain? I tried
> >
> > typeOf(3)=Integer
> >
> > but such a simple solution doesn't work.
>
> You got a quite tricky question there, really. If you are doing something
> else then trying to understand how axiom is doing things, it's very likely
> that you are on the wrong track. What are you trying to accomplish?

I might very well be on the wrong track. On one hand I am not really trying to 
accomplish anything, but to understand Axiom, or, in fact, Axiom's 
interpreter. On the other hand I usually try to solve some problem for such 
exercises and I had thought that the summation algorithms a la Gosper are 
quite useful for that. But even checking that some summand is a 
hypergeometric term causes the greatest pain. So in fact, the last thing I 
tried was trying to check wether a quotient 

F(n-1,k)/F(n,k) ,

primarily given by an Expression Integer could be "coerced" / "converted" / 
"retracted" (certainly not) to, say, a 

Fraction Polynomial Integer.

Ideally, I would have used parsing operators and analysed such an expression 
from scratch, but I lacked the proper clues to do that. Even though 
Expressions are described someplace as "recursive", I haven't encountered the 
representation and tools to use that fact, but that said I might not have 
studied enough the "FunctionSpace"s.

I will answer your question in the other mail later. I need to travel today, 
i.e. leave for the airport right now, and will only return late on Monday 
night.

Thanks and best regards

\start
Date: Sun, 13 Nov 2005 07:42:48 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Archive of IRC channel?

Does anybody know if the axiom IRC channel is being archived anywhere? 
meme.b9.com archvies the #lisp channel and I have found that a very
useful resource on a number of occasions.  Unfortunately, I don't know
how to reproduce the nice formatting that site gives archives - anybody
know how that's done?  Normally all I get is rather hard to read text
:-(.

\start
Date: Sun, 13 Nov 2005 08:12:55 -0800
From: Bob McElrath
To: Cliff Yapp
Subject: Re: Archive of IRC channel?

C Y [Cliff Yapp] wrote:
> Does anybody know if the axiom IRC channel is being archived anywhere? 
> meme.b9.com archvies the #lisp channel and I have found that a very
> useful resource on a number of occasions.  Unfortunately, I don't know
> how to reproduce the nice formatting that site gives archives - anybody
> know how that's done?  Normally all I get is rather hard to read text
> :-(.

No, it is not currently archived.

You'd need a channel bot to sit there and record everything.

\start
Date: Sun, 13 Nov 2005 11:24:59 -0600
From: MathAction (anonymous)
To: MathAction
Subject: [#234 limit((-1/2)^n,n=%plusInfinity)] (new) 

Another problem I have is that taking the limit of an expression
containing (-1)^n always returns "failed", where my TI-89 Titanium
calculator will give a finite limit.  For example:

 limit( 2 + (-2/%pi)^n, n=%plusInfinity )  ===> "failed"

... but the TI-89t returns 2.

The TI-89t says that the limit of (-1)^n as n approaches infinity is -1,
implying that it believes that infinity is an odd number.  That kind of
makes sense to me, since if you divide infinity in half, you still have
infinity, and you keep adding 1 to get to infinity, making it odd.  If
infinity is even then the answer should be 1, and if we can't know if
infinity is even or odd, then the answer is uncertain or undefined.

On the other hand, the TI-89t says that lim ( (-1)^n * (n + 1)/n ) is
undefined.  But it already told me that lim (-1)^n = -1, and that lim (n
+ 1)/n = 1.  If the limit of a product is the product of the limits of
the factors, then lim ( (-1)^n * (n + 1)/n ) should be -1, right?

So, who's right?

\start
Date: Sun, 13 Nov 2005 11:27:39 -0600
From: MathAction (unknown)
To: MathAction
Subject: [#234 limit((-1/2)^n,n=%plusInfinity)] An answer to my question, from William Sit.

William Sit responded via emai, and wrote, in part:

Mathematically, the limit is 2 since (-2/%pi) has absolute value less than 1,
and hence (-2/%pi)^n converges to 0. So TI-89t is correct and Axiom is wrong.

In the second case, TI-89t is wrong to say that limit (-1)^n is -1. The limit does not exist
because the sequence (-1)^n oscillates between 1 and -1. There is no number L
(the assumed limit) such that given any epsilon > 0, there is a natural number N
such that |(-1)^n - L| < epsilon for all n > N.

\start
Date: 13 Nov 2005 19:16:43 +0100
From: Martin Rubey
To: Martin Rubey
Subject: Re: [Bug?] "error in library; negative log"

Dear all,

Martin Rubey writes:

> If you file a bug report concerning limit((-1/2)^n,n=%plusInfinity), I'll file
> a patch :-)

Today I tried to do so, but alas, the patch is not so easy... Furthermore, it
seems that it would be wasted work, because of

On Computing Limits in a Symbolic Manipulation System [Abstract] [Postscript] 
Dominik Gruntz. ETH Diss 11432, 1996. 

which can be obtained from

http://www.cs.fh-aargau.ch/~gruntz/publications2.html

Somehow sad, since the algorithm in Axiom is quite elaborate, while Gruntz's
algorithm seems to be much shorter. It is in fact implemented in MuPAD.

Still, here is the reason for Axiom's failure:

(1/2)^(1/x) has an essential singularity at x=0, thus no Puiseux expansion can
be computed. Thus, Axiom computes an exponential expansion, which, in this
simple case is

%e^(- log 2 * 1/x)

Next it checks that - log 2 is negative, thus the exponent goes to -infinity
and we are done.

For 

(-1/2)^(1/x) 

or

(-1/2)^(1/x) + (1/3)^(1/x)

this doesn't work, since we would obtain negative numbers in the exponent...

\start
Date: Sun, 13 Nov 2005 11:38:38 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [WishList] 

  David Mentre added:

  I believe there's a better, faster, more complete choice than
  Octave. It is called Scilab, and it was developed by the French
  INRIA (Institute Nationale De Recherche en Informatique et
  Automation, IIRC), and it is in ongoing development, is very
  complete (even has a simulation kit). It is also Open Source. Octave
  pales in comparison as somewhat of a "toy."

  http://scilabsoft.inria.fr/

  For reference: on scilab.org web site, FAQ section:
  Q6. Is Scilab license GPL-compatible?

      According to the Free Software Foundation, Scilab is not a free software.
      See http://www.fsf.org/licenses/license-list.html#NonFreeSoftwareLicense.

  Q1. What does the Scilab license mean?     

  * Scilab license allows you to:
  ** use freely Scilab for non commercial use

  ** use freely Scilab for commercial use if you do not use it as a
  derived software (ie a modified Scilab) or a composite software (ie
  Scilab included in another software).

  * Scilab license forbids you to:

  ** use a composite or derived version of Scilab for commercial uses
  without asking INRIA authorization.


  Update: Meanwhile Renaud provided his
  [CylindricalAlgebraicDecomposition] package, which solves this item
  partially.


  See ProgrammingAxiom. This is nearly done, except of Issue
  219TheInterpreterDoesNotUnderstandDependendTypes

  Update: To get things started, I implemented an operator that
  represents recurrences.  Look at RecurrenceRelationOperator.

  Graphics should be programmable, interactive, suitable for
  publication.  Mathematica gained much of its popularity because it
  was early to get the visualization right (almost, at least).

  Although a naive implementation is available now, it would be great
  if someone could implement a more sophisticated algorithm. I
  provided some pointers at the above page.

  Update: This item can be regarded as done. I implemented two
  different algorithms, the faster one being due to Beckermann and
  Labahn. Unfortunately, I do not have the time to finish this package
  right now, since some tricky issues remain. A preliminary version
  can be obtained by posting to axiom-math.

- Limits

  The LIMITPS package is outdated. We should implement the MRV
  algorithm described in

  "On Computing Limits in a Symbolic Manipulation System, Dominik
  Gruntz. ETH Diss 11432, 1996."

  which can be obtained from

  http://www.cs.fh-aargau.ch/~gruntz/publications2.html

  Somehow sad, since the algorithm in Axiom is quite elaborate, while
  Gruntz's algorithm seems to be much shorter. It is in fact
  implemented in MuPAD.

\start
Date: Sun, 13 Nov 2005 11:41:40 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [WishList] 

  This item relates to Bug #234. The LIMITPS package is outdated. We
  should implement the MRV algorithm described in

\start
Date: Sun, 13 Nov 2005 11:52:42 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#232 Trace causes Bind Stack Overflow from erroneous input] This happens always with ')tr EXPR )ma'!

Unfortunately, it is currently impossible to ')tr EXPR )ma', a bind stack overflow results always. Somehow, an infinite loop is created - probably for the output routines...

\start
Date: Sun, 13 Nov 2005 16:01:55 -0500
From: Tim Daly
To: list
Subject: Numerical Mathematics Consortium

*,

The Numerical Mathematics Consortium is pushing to develop
a portable and compatible numerical algorithms library.
http://www.nmconsortium.org/index.aspx

This effort will be important to Axiom in the long term.
Plus, as you can probably guess, I feel it's important that
they adopt a literate programming style

In any case, I've sent a request to have Axiom join as an
associate member so we can participate in the discussion
and development. I'll let you know if we get approved.

\start
Date: Sun, 13 Nov 2005 21:01:06 -0600
From: MathAction (Doug Stewart)
To: MathAction
Subject: [Axiom-mail] A newby question about eval and Expression

Martin Rubey wrote:

>Dear Doug,
>
>there are two issues in your code:
>
>
>Doug Stewart writes:
>
>  
>
>>)clear all
>>digits 20
>>-- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer
>>
>>Q:=(3*a2-a1^2)/9
>>R:=(9*a1*a2-27*a3-2*a1^3)/54
>>S:=(R+(Q^3+R^2)^(1/2))^(1/3)
>>T:=(R-(Q^3+R^2)^(1/2))^(1/3)
>>x1:=S+T-a1/3
>>    
>>
>
>note that x1 is *not* a polynomial. Not even a rational function.
>  
>
>  
>

But it is a constant ---- How can I tell axiom that it is a constant?
I tried this way but :-(
)clear all
digits 20
-- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer

a1:=1
a2:=1
a3:=1

Q:=(3*'a2-'a1^2)/9
R:=(9*'a1*'a2-27*'a3-2*'a1^3)/54
S:  Complex Float :=(R+(Q^3+R^2)^(1/2))^(1/3)


I thought that if I gave a1 a2 a3 some in integer values, that Maxima 
would then know that it was a constant but no it thinks it is a variable????



>However, if you *can* avoid this domain (often you can't), try to do so, since
>it has a major drawback:

>A computer cannot test reliably whether some element of Expression
>Integer is zero or not. Axiom tries, but often fails. For example,
>the first example above is not zero for Axiom...

>(MuPAD, Mathematica and Maple try harder, but they often fail, too)

>Note that this problem does not arise for many other domains: you can
>test for zero in

>Integer,
>Polynomial Integer,
>AlgebraicNumber,
>PrimeField 5
>Matrix Integer,
>Fraction Polynomial PrimeField 1783
>
>and so on.
>

Thanks for your help, It clarified what I was seeing.  --- a big mess of 
numbers that was realy zero.

\start
Date: Sun, 13 Nov 2005 21:45:31 -0600
From: MathAction (William Sit)
To: MathAction
Subject: A newby question about eval andExpression

Doug Stewart wrote:

> But it is a constant ---- How can I tell axiom that it is a constant?
> I tried this way but :-(
> )clear all
> digits 20
> -- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer
> 
> a1:=1
> a2:=1
> a3:=1
> 
> Q:=(3*'a2-'a1^2)/9
> R:=(9*'a1*'a2-27*'a3-2*'a1^3)/54
> S:  Complex Float :=(R+(Q^3+R^2)^(1/2))^(1/3)
> 
> I thought that if I gave a1 a2 a3 some in integer values, that Maxima
> would then know that it was a constant but no it thinks it is a variable????
> 

Perhaps you try removing the single quotes?

\start
Date: Sun, 13 Nov 2005 22:29:26 -0600
From: MathAction (Doug Stewart)
To: MathAction
Subject: A newby question about eval and Expression

William Sit wrote:

>Doug Stewart wrote:
>
>>But it is a constant ---- How can I tell axiom that it is a constant?
>>I tried this way but :-(
>>)clear all
>>digits 20
>>-- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer
>>
>>a1:=1
>>a2:=1
>>a3:=1
>>
>>Q:=(3*'a2-'a1^2)/9
>>R:=(9*'a1*'a2-27*'a3-2*'a1^3)/54
>>S:  Complex Float :=(R+(Q^3+R^2)^(1/2))^(1/3)
>>
>>I thought that if I gave a1 a2 a3 some in integer values, that Maxima
>>would then know that it was a constant but no it thinks it is a variable????
>>
>>    
>>
>
>Perhaps you try removing the single quotes?
>  
>
If I do that then it puts the ones in and that is not what I want.
I want a symbolic answer not a numeric one.

\start
Date: Mon, 14 Nov 2005 02:46:30 -0600
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] A newby question about eval and Expression

Doug Stewart writes:

> Martin Rubey wrote:
> 
> >Dear Doug,
> >
> >there are two issues in your code:
> >
> >
> >Doug Stewart writes:
> >
> >
> >>)clear all
> >>digits 20
> >>-- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer
> >>
> >>Q:=(3*a2-a1^2)/9
> >>R:=(9*a1*a2-27*a3-2*a1^3)/54
> >>S:=(R+(Q^3+R^2)^(1/2))^(1/3)
> >>T:=(R-(Q^3+R^2)^(1/2))^(1/3)
> >>x1:=S+T-a1/3
> >>
> >
> >note that x1 is *not* a polynomial. Not even a rational function.
> >
> 
> But it is a constant ---- How can I tell axiom that it is a constant?

Maybe in a mathematical or physical sense, but not for Axiom, since it contains
variables.

You have to use the appropriate domain, for example EXPR INT itself. The way I
do these things usually is to ask Axiom for the "smallest" domain x1 is in, by
typing 

x1

and looking at the type information.

You may also consider the domain POLY EXPR INT, which is, however, a dangerous
construction...

\start
Date: Mon, 14 Nov 2005 03:10:09 -0600
From: MathAction (William Sit)
To: MathAction
Subject: A newby question about eval andExpression

Doug Stewart wrote:
> 
> Changes http://page.axiom-developer.org/zope/mathaction/AxiomMail/diff
> --
> William Sit wrote:
> 
> >Changes http://page.axiom-developer.org/zope/mathaction/AxiomMail/diff
> >--
> >
> >
> >Doug Stewart wrote:
> >
> >
> >
> >>But it is a constant ---- How can I tell axiom that it is a constant?
> >>I tried this way but :-(
> >>)clear all
> >>digits 20
> >>-- n:=x^3+a1*x^2+a2*x+a3 ::Polynomial Fraction Integer
> >>
> >>a1:=1
> >>a2:=1
> >>a3:=1
> >>
> >>Q:=(3*'a2-'a1^2)/9
> >>R:=(9*'a1*'a2-27*'a3-2*'a1^3)/54
> >>S:  Complex Float :=(R+(Q^3+R^2)^(1/2))^(1/3)
> >>
> >>I thought that if I gave a1 a2 a3 some in integer values, that Maxima
> >>would then know that it was a constant but no it thinks it is a variable????
> >>
> >>
> >>
> >
> >Perhaps you try removing the single quotes?
> >
> >
> If I do that then it puts the ones in and that is not what I want.
> I want a symbolic answer not a numeric one.
> Doug Stewart

But you already have the symbolic formula in code (at least assuming S
is not 0).  May be what you need is done in SOLVEFOR package in
http://wiki.axiom-developer.org/images/zope/mathaction/axiom--test--1/src/algebra/solvefor.spad.pamphlet
which uses formulae to solve polynomials equations of degree 1 to
4. According to that, the case S = 0 can be handled separately and the
formulae you used above is not valid (that is, S will not be 0 in that
case).

So you can do:

pkg:= SOLVEFOR(UP('x,Complex Float), Complex Float)
root := aCubic(1,1,1,1)$pkg
qfactor := monicDivide(x^3 + x^2 + x + 1,x - root)
qfactor.quotient
qfactor.remainder

see SandboxQubic page
http://page.axiom-developer.org/zope/mathaction/SandBoxQubic#bottom

\start
Date: Mon, 14 Nov 2005 03:19:48 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#235 Where is RadicalExtension and RationalRadical?] (new) 

In Solvefor.spad.pamphlet:
)abbrev package SOLVEFOR PolynomialSolveByFormulas
--  Current fields with "**": (%, RationalNumber) -> % are
--     ComplexFloat, RadicalExtension(K) and RationalRadical
I cannot locate any reference to RadicalExtension or RationalRadical.

Also, hyperdoc crashes when I enter either "**" or ** under Browse and
operations. When restarted with )hd, it is not connected to the Axiom
server. I am using Version Feb 20, 2005 under Fedora 2.

\start
Date: Mon, 14 Nov 2005 10:56:20 +0100
From: Ralf Hemmecke
To: list
Subject: Re: [Aldor-l] ALLPROSE

 > Makefile.inc.nw contains \CVSID which appears to be an undefined tex tag.

\CVSID is defined in Section 21.2.9.

Files in ALLPROSE are not supposed to be translated separately as in 
AXIOM, but rather one 'make dvi' at the toplevel builds the whole 
documentation.

That is an advantage of ALLPROSE that the whole documentation is in just 
ONE document. Simply use the SEARCH of your pdf viewer to look up CVSID.

In case ALLPROSE is properly installed and the "inverse search" (Section 
  21.2.8) works properly, then viewing with kdvi or xdvik, searching for 
CVSID and clicking onto the page in the DVIVIEWER will automatically 
open an editor at the right place in the corresponding source file.


 > \xAldor{} in Makefile.inc.nw expands to nothing. Thus the sentence
 > reads:

 > ... the variable  is installed.

\xAldor is defined in Section 21.7.

\start
Date: Mon, 14 Nov 2005 04:01:08 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] 

Are you serious?  random() is a categorical specification and it is
not possible to be more specific without knowing the domain. It is
certainly useful in creating derived random functions that are more
meaningful such as random(n) or random(m,n). It does not mean that n
is limited to 2^26. A grep for random()$INT shows uses in other
domains (such as Float, Fraction Integer). There are many algorithms
(like factoring integers) that use monte carlo methods.

Of course, one only implements pseudo-random numbers and not truely
random numbers on computers (excluding quantum computers). But that is
generally understood. Once restricted to a finite integer interval,
uniform distribution makes sense even if it may only be programmed
approximately.

It should be the responsibility of each domain to be specific on what
random() exactly does and the algorithm used, but not at the category
level. So for random()$INT, yes, the documentation should say the
random number lies between 1 and 2^26. But that is not crucial since
developers know that, and for users, there is random(n)$INT for any n
(also implemented in Lisp), which one should use instead in
applications.

\start
Date: Mon, 14 Nov 2005 04:06:00 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] 

'random()' is a categorical specification and it is not possible to be
more specific without knowing the domain. It is certainly useful in
creating derived random functions that are more meaningful such as
'random(n)' or 'random(m,n)'. It does not mean that 'n' is limited to
$2^{26}$. A grep for 'random()\$INT' shows uses in other domains (such
as Float, Fraction Integer). There are many algorithms (like factoring
integers) that use monte carlo methods.

It should be the responsibility of each domain to be specific on what
random() exactly does and the algorithm used, but not at the category
level. So for 'random()\$INT', yes, the documentation should say the
random number lies between '1' and $2^{26}$. But that is not crucial
since developers know that, and for users, there is 'random(n)\$INT'
for any 'n' (also implemented in Lisp), which one should use instead
in applications.

\start
Date: Mon, 14 Nov 2005 10:12:12 +0000
From: Mike Dewar
To: Bill Page
Subject: re: Axiom + High Energy Physics

You're correct that we originally did numerics via a separate server.
At the time this made sense but with machines being more powerful I
wouldn't try to reproduce this today, except via support for standard
protocols like SOAP and WSDL.  The Windows version of Axiom called NAG
numerical code directly by loading symbols as needed from a DLL, and had
we continued to develop Axiom we would have done the same on Unix.  This
is the approach taken by Maple and Matlab as well, by the way.

Cheers, Mike.

On Thu, Nov 10, 2005 at 09:11:19PM -0500, Bill Page wrote:
> On November 10, 2005 8:16 PM Tim Daly wrote:
> > 
> > well, i don't plan to rewrite EVERYTHING in lisp, despite what I
> > told Bill,
> 
> :o)
> 
> > although in principle you can generate machine-instruction
> > equivalent routines from lisp. Before we gave the system to NAG
> > we worked with them to generate an Axiom-Fortran interface which
> > still exists in the code. I'd like to keep it compatible with the
> > NAG library but i don't have access to that anymore.
> > 
> 
> >From a quick look at the NAG routines that are not compiled in the
> current open source release it looked to me like these assumed
> that these numeric calculations were performed by a separate server
> program that communicates with Axiom through sockets. Am I right
> about this, Tim?
> 
> 
> If that is the case, then what one would need to do in order to
> retain the NAG Axiom coding in it's current form would be to write
> a new numeric server program which would call open source math
> library routines to perform equivalent functions. Of course such
> a program could be written in any convenient language, e.g. C or
> even Fortran (post 2000 version please!).
> 
> In principle such a design seems to make sense because it allows
> some parallelism and also provides the numeric routines with their
> own address space. This also allows the conversion to and from
> Axiom data structures to native (Fortran?) data structures to be
> centralized and done as efficiently as possible.
> 
> Of course it is also possible to interface with external programs
> from Axiom in more high level ways such as Martin Rubey's interface
> to Polymake which is written entirely in Spad and communicates
> simply through files.
> 
> http://wiki.axiom-developer.org/Polymake
> 
> For example one might create such an interface for Octave or even
> Cactus http://www.cactuscode.org/aboutCactus if you are into that
> kind of thing. The main problem has to do with converting to and
> from Axiom's internal data structures and the simplest place to do
> that is in Spad (or Aldor).

\start
Date: Mon, 14 Nov 2005 08:45:17 -0500
From: Tim Daly
To: list
Subject: doyen

> From: "Tim Daly Jr." <Tim Daly Jr>
> 
> If you want to bolt Lisp onto a webserver, the sweet spot of simple and
> nice is probably tbnl and mod_lisp:  <http://www.weitz.de/tbnl/>.
> Nothing fancy, but it all works well.
> 
> The website for finding Lisp software is <http://www.cliki.net/>.
> 
> I run my Lisp code in SBCL: <http://www.sbcl.org>.  It supports the full
> standard (<http://www.lispworks.com/documentation/HyperSpec/>), does
> native code compilation, has multithreading, two different profilers,
> comes with libraries for system definition (asdf), fetching and
> installing packages and their dependiencies (asdf-install), sockets,
> posix functions, a foreign function interface, yadda yadda yadda...
> 
> So in my world, you would keep the client functionality (the stuff in
> the web browser) relatively straightforward, and do all the magic in
> your Lisp webserver.  Nobody likes programming in a web browser anyway.
> 
> (it's okay to quote this email...)
> --
> -Tim

i got this response to the doyen questions. if i understand the
architecture correctly this solves both the questions of "drag and drop"
and "embedded command window".

"drag and drop" works since the browser, the webserver, and lisp are all
running on the same machine. thus anything the browser asks for (such as
notangle-compile-load, noweave-latex-xdvi can be done by a background
lisp process. 

"embedded command window" is also possible. it appears that franz already
offers this ability with a lisp prompt in a window. they appear to be
using a java applet which opens a tcp connection to the host-based lisp
process and emulates a terminal.

so doyen seems much more feasible at this point. i'm going to prototype
this setup and, if i can make it work, merge it onto the doyencd project
at sourceforge.

\start
Date: Mon, 14 Nov 2005 06:47:16 -0600
From: MathAction (root)
To: MathAction
Subject: [#235 Where is RadicalExtension and RationalRadical?]

William,

> Also, hyperdoc crashes when I enter either "**" or ** under Browse and
> operations. When restarted with )hd, it is not connected to the Axiom
> server. I am using Version Feb 20, 2005 under Fedora 2.

Could you file this as a bug report in IssueTracker?

\start
Date: Mon, 14 Nov 2005 07:31:33 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

Hello,

Martin Rubey wrote:
> Hans Peter Wuermli Hans Peter Wuermli writes:
> 
>> Hi

>> What are my wrong expectations in the following interpreter session
>> when using "typeOf" and "has"

>> (1) -> e:=(1+n)/(n+k)
>>         n + 1
>>    (1)  -----
>>         n + k
>>                                            Type: Fraction Polynomial Integer
>> (2) -> typeOf e
>>    (2)  Fraction Polynomial Integer
>>                                                                  Type: Domain
>> (3) -> typeOf (e) has Fraction Polynomial Integer
>>    (3)  false
>>
>> In (3) I would expect true.

Hmm, I can find "typeOf" in the original Axiom book, but HyperDoc does 
not seem to know it. :-(

> Axiom is correct. "A has B" tests whether the Domain or Category A
> is a member of *Category* B or satisfies the axiom B.

Oh can one do this with A being a category?

Anyway, what is the semantics of "A has B" if both (A and B) are domains 
as above in line (3)?

\start
Date: Mon, 14 Nov 2005 09:41:13 -0600
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

Ralf Hemmecke writes:

> Hmm, I can find "typeOf" in the original Axiom book, but HyperDoc
> does not seem to know it. :-(

it is not a library function -- only defined in the interpreter.

> > Axiom is correct. "A has B" tests whether the Domain or Category A
> > is a member of *Category* B or satisfies the axiom B.

> Oh can one do this with A being a category?

> Anyway, what is the semantics of "A has B" if both (A and B) are
> domains as above in line (3)?

To return false, I believe.

\start
Date: Mon, 14 Nov 2005 09:46:33 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] 

Using browse I found that 'random()' is implemented only for three types:

 - 'QuotientFieldCategory' if has 'IntegerNumberSystem'

 - 'IntegerNumberSystem'

 - 'Finite'

I think the first two should go away, since, mathematically they make
no sense. 'random()' is not implemented for 'Float'. In fact, I could
not find a single affected operation! If you find one, could you
please post it here? Caution: there are some domains, for example
'FSAGG' that use 'random()\$Integer', but only in the finite case. In
fact, it appears to me that their use is mathematically wrong and
should be replaced by 'random(n)\$Integer'.

\start
Date: Mon, 14 Nov 2005 17:15:32 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] 

Sorry, maybe your zope is misconfigured. I got pages in which I was
able to change the content of the site (reparenting and adding pages,
and so on). This as a simple user/navigator.  Moreover, the link to
the Windows 0.14 version installer is broken. It was impossible to
download it.

\start
Date: Mon, 14 Nov 2005 18:57:40 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] this is a wiki web site

What makes you sorry? This is a wiki web site. It is our
intention that **you** can change the content of this site.
We would like it very much if you to make corrections and
other improvements to the content.

The link to 'Windows version 0.1.4' download link works
fine for me. What version of browser are you using? In
what sense is it "broken"? What error do you get?

\start
Date: Mon, 14 Nov 2005 19:54:11 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] Using Grep here are all the lines involving random()

You are right, 'random()' is not implementd or specified in 'Float'
(it should!) and the above three categories are the only ones Hyperdoc
shows. But 'random()' for 'Float' is available in almost any
computation software and the lack of it in Axiom is simply because
Axiom developers were hardly interested in floating point computations
at the time. It surely does not imply that 'random()\$Float' has no
applications (how about probability theory and statistics?) The
neglect of numerical computation tools may be a fatal flaw in the
development of Axiom, especially when it claims to be "the Scientific
Computation System". So much so that even after hooking up with NAG's
Fortran library and adding graphics, it was not able to attract the
real scientific community and only the computer algebra
community. With the convergence of symbolic-numerical computation as a
dominating theme at ISSAC, it is crucial for the survival of Axiom to
strength its numerical applications, and random !  number generation
for floating point numbers is definitely a basic tool.

You seem to insist to interpret 'random()\$INT' to mean a random
 integer chosen out of all integers, and in this sense, then you are
 correct, but only because the implementation of 'random()\$INT' uses
 the Lisp version, not because it is inherently impossible to generate
 such a random integer (see Third point below). I think you cannot
 give a better documentation for this function for a category, and you
 cannot specify a function 'random(n)' without knowing the domain
 where 'n' lives or an explicit bijection between the set and some
 segment of integers. The function 'random()' has meaning for any set,
 finite or not, and in the case the set is finite, it can be used
 without having to worry about the size of the set. Of course, in
 implementing such a function for a finite set, like the first line
 shown below (the result of grep), there is a tacit assumption that
 the size of the finite set is less than $2^{26}$. We may consider
 that $2^{26}$ is a system constant due to hardware!  or efficiency
 consideration (in fact, due to Lisp implementation) and should be
 documented. I would agree that in certain places, using random(n) is
 technically more correct since it would not subject the set to a
 system limit, but I don't follow your reasoning to remove it
 altogether. Of course, it is possible to remove any code, and rewrite
 it in some other form, but that would be both unnecessary and
 counter-productive. Here're my reasons.

Firstly, you cannot really start 'random(n)\$INT' without a seed (here
'n' is NOT the seed but an upper bound for the range). Axiom uses
'random()\$INT' to provide the seed for its algebra codes (see line in
'd01agents.spad'). Of course, 'random()$Lisp' must have its own seed,
possibly taken from some hardware clock. But 'random()\$INT' provides
a higher level of conceptual abstraction for the seed and that is a
valid design for algebra code.

Secondly, to remove 'random()' means removing all the lines grepped
below and hoping it will not break anything. Are you willing to spend
the time to track this? Are you going to replace this with 'random(n)'
by forcing the usage to require knowing the size of a set a priori
(consider the set of compositions of a positive integer 'k', for
example) and knowing some hardware clock address? The version
'random()\$S' hides these technicalities from the user. Which version
would be more user friendly? Unless you want to do away with random
elements altogether, you will also have to set up explicit bijections,
which is not possible for the generality Axiom is designed for.

Thirdly, it is not inconceivable to select random elements out of an
infinite set. For example, take Streams over a finite set (say
'GF(2)'). We can conceptually generate a random stream of binary
digits and implement this as 'random()\$Stream(GF(2))'. We simply need
to generate each digit randomly one at a time. (I will not argue with
you whether such an stream of binary digits is truely random or not,
since this is moot because we never finish doing so; and I know that
if a pseudo-random generator is used to generate the coordinates of an
n-dimension point, then these points lie on certain hyperplanes in
n-dimensional space. These are simply properties of these
pseudo-random generators, and do not invalidate the mathematical
concept of a random element from an infinite set.) Now it is just a
simple leap to consider these streams as integers expressed in binary,
where the k-th bit is the bit for 2<SUP>k</SUP>.  Since Axiom can
compute (or at least simulate computing) with s!  treams, Axiom can
compute with random elements from the ring of integers.

Fourthly, which do you think is more efficient: to generate a random
integer one bit at a time, and having to stop somewhere eventually, or
to generate a random integer within a bound of 2<SUP>26</SUP>?

In conclusion, I agree that one may use 'random(n)\$INT' almost
everywhere 'random()\$INT' is used in the implementation of
'random()\$S' for a finite set 'S'. I say "almost" because in defining
the seed in algebra code, it is convenient to use 'random()\$INT' ; I
say "may" rather than "should" because in many cases where usage is
'random()\$INT' modulo a small integer, the system bound is of no
concerns.  However, I don't think you can or should replace
'random()\$S' by 'random(n)\$S' since the latter need not make sense
for some sets 'S' (for example, where the concept of 'next' or the
bijection with '1..n' is not given).

William

\begin{verbatim}
aggcat~1.spa:     random()     == index((random()$Integer rem (size()$% + 1))::PositiveInteger)
algcat~1.spa:     random() == represents [random()$R for i in 1..rank()]$Vector(R)
algext~1.spa:         random == represents([random()$R for i in 0..d1])
boolea~1.spa:    random()      ==
boolea~1.spa:      even?(random()$Integer) => false
catdef~1.spa:        ++ random() returns a random element from the set.
d01age~1.spa:      seed:INT := random()$INT
d01age~1.spa:      r:LDF := [(((random(seed)$INT) :: DF)*s/dseed + l) for i in 1..n]
ddfact~1.spa:           for j in 1..k1 repeat u:=u+monomial(random()$F,j)
ddfact~1.spa:        for j in 0..k1-1 repeat u:=u+monomial(random()$F,j)
diviso~1.spa:        +/[random()$F * qelt(v, j) for j in minIndex v .. maxIndex v]
diviso~1.spa:        +/[(random()$Integer rem m::Integer) * qelt(v, j)
diviso~1.spa:          j := i + 1 + (random()$Z rem (n - i))
facuti~1.spa:        ran(k:Z):R == random()$R
facuti~1.spa:        ran(k:Z):R == (random(2*k+1)$Z -k)::R
ffcg~1.spa:    random() ==
ffcg~1.spa:      positiveRemainder(random()$Rep,sizeFF pretend Rep)$Rep -$Rep 1$Rep
ffnb~1.spa:        ++ random(n) creates a vector over the ground field with random entries.
ffnb~1.spa:    random(n) ==
ffnb~1.spa:      for i in 1..n repeat v.i:=random()$GF
ffnb~1.spa:    random() == random(extdeg)$INBFF
ffpoly~1.spa:--      ++ random()$FFPOLY(GF) generates a random monic polynomial
ffpoly~1.spa:      ++ random(n)$FFPOLY(GF) generates a random monic polynomial
ffpoly~1.spa:      ++ random(m,n)$FFPOLY(GF) generates a random monic polynomial
ffpoly~1.spa:--    random == qAdicExpansion(random()$I)
ffpoly~1.spa:--        if (c := random()$GF) ^= 0 then
ffpoly~1.spa:        if (c := random()$GF) ^= 0 then
ffpoly~1.spa:    random(m,n) ==
ffpoly~1.spa:      if d > 1 then n := ((random()$I rem (d::PI)) + m) :: PI
ffpoly~1.spa:      random(n)
ffp~1.spa:    random() == random()$Rep
files~1.spa:            ix := random()$Integer rem #ks
fmod~1.spa:    random()             == random(q)$Rep
fmod~1.spa:    random()             == random(p)$Rep
fracti~1.spa:        ++ random() returns a random fraction.
fracti~1.spa:      random():% ==
fracti~1.spa:        while zero?(d:=random()$S) repeat d
fracti~1.spa:        random()$S / d
gpgcd~1.spa:--JHD          lval:=[(random()$I rem (2*range) - range)::R  for i in 1..nvr]
gpgcd~1.spa:--JHD          lval:=[(random()$I rem (2*range) -range)::R  for i in 1..nvr]
groebs~1.spa:             ranvals:L I:=[1+(random()$I rem (count*(# lvar))) for vv in rlvar]
idecom~1.spa:         val:=random()$Z rem 23
idecom~1.spa:       ranvals:List(Z):=[(random()$Z rem 23) for vv in lv1]
intege~1.spa:      ++ random(n) returns a random integer from 0 to \spad{n-1}.
intege~1.spa:      random() == random()$Lisp
intege~1.spa:      random(x) == RANDOM(x)$Lisp
intege~1.spa:              ++ random(n) returns a random integer from 0 to \spad{n-1}.
\end{verbatim}
\begin{verbatim}
intfac~1.spa:       x0 := random()$I
lingro~1.spa:        while c=0 repeat c:=random()$Z rem 11
lingro~1.spa:      ll: List Z :=[random()$Z rem 11 for i in 1..nvar1]
lodof~1.spa:    random()               == index((1 + (random()$Integer rem size()))::PI)
mfinfa~1.spa:      --if R case Integer then random()$R rem (2*k1)-k1
mfinfa~1.spa:      +/[monomial(random()$F,i)$R for i in 0..k1]
modmon~1.spa:         random == UnVectorise([random()$R for i in 0..d1])
mring~1.spa:          random() == index( (1+(random()$Integer rem size()$%) )_
naalgc~1.spa:    -- [random()$Character :: String :: Symbol for i in 1..rank()$%], _
oderf~1.spa:        retract eval(f, t, [random()$Q :: F for k in t])
permgr~1.spa:      ++ random(gp,i) returns a random product of maximal i generators
permgr~1.spa:      ++ random(gp) returns a random product of maximal 20 generators
permgr~1.spa:      ++ Note: {\em random(gp)=random(gp,20)}.
permgr~1.spa:      randomInteger : I     := 1 + (random()$Integer rem numberOfGenerators)
permgr~1.spa:        numberOfLoops : I  := 1 + (random()$Integer rem maxLoops)
permgr~1.spa:        randomInteger : I := 1 + (random()$Integer rem numberOfGenerators)
permgr~1.spa:      randomInteger : I  := 1 + (random()$Integer rem numberOfGenerators)
permgr~1.spa:      numberOfLoops : I  := 1 + (random()$Integer rem maximalNumberOfFactors)
permgr~1.spa:        randomInteger : I  := 1 + (random()$Integer rem numberOfGenerators)
pfbr~1.spa:      randomR() == random()
pfbr~1.spa:   else randomR() == (random()$Integer rem 100)::R
pfbr~1.spa:      randomR() == random()
pfbr~1.spa:   else randomR() == (random()$Integer)::R
pfo~1.spa:                                      setelt(redmap, k, random()$Z)::F
plot~1.spa:--        jitter := (random()$I) :: F
primel~1.spa:    randomInts(n, m)       == [symmetricRemainder(random()$Integer, m) for i in 1..n]
primel~1.spa:        c := symmetricRemainder(random()$Integer, i)
random~1.spa:        -- random()  generates numbers in 0..rnmax
rep2~1.spa:      randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:      randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:             randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:               randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:               randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:        randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:          randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:          randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:             randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:               randomIndex := 1+(random()$Integer rem numberOfGenerators)
rep2~1.spa:               randomIndex := 1+(random()$Integer rem numberOfGenerators)
sia369~1.spa:      ++ random() creates a random element.
sia369~1.spa:      ++ random(a) creates a random element from 0 to \spad{n-1}.
sia369~1.spa:   seed : % := 1$Lisp               -- for random()
sia369~1.spa:   random() ==
sia369~1.spa:   random(n) == RANDOM(n)$Lisp
string~1.spa:        random()               == char(random()$Integer rem size())
twofac~1.spa:          vval := random()$F
\end{enumerate}
\begin{enumerate}
twofac~1.spa:         val:=random()$extField
\end{verbatim}

\start
Date: Tue, 15 Nov 2005 02:39:06 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] 

I disagree:

 - 'random()' has meaning only if I specify a distribution. If no
   distribution is specified, usually the uniform distribution is
   taken. There is no uniform distribution on the integers, nor on the
   reals.  By the way: random without an argument is not a lisp
   function!

 - I am not proposing to remove 'random()' for finite sets. If it is
   known how to select an element from a certain finite set - for
   example the set of partitions of $k$ - then it should be
   implemented. In fact: it is.  By the way: I don't see how knowing
   the size of a set helps with creating a random element. I believe
   one needs some way of enumerating the elements?  Furthermore, I
   think that lines like 'random()\$Z rem 11' are a bad idea, since
   the resulting distribution will be nearly uniform, but not
   quite... Do you know why such code was written?

 - I did not say that it is impossible to create a random element of
   the integers according to some distribution. Only: it cannot be the
   uniform distribution...  To generate random Integers according to a
   specific distribution we have 'RIDIST'.

Apart from the usage in 'D01AGNT' - where 'random()\$Integer' is used
to generate a seed, did you find any other places where
'random()\$Integer' is used?

Finally: Which CAS defines a function random for floats? I checked
Mathematica and MuPAD, the both define functions that return a
(uniformly distributed) float between zero and one. This is
reasonable, since most (all?) other distributions can be generated
from that one.

\start
Date: Tue, 15 Nov 2005 09:07:30 -0800
From: Bob McElrath
To: Cliff Yapp
Subject: Re: Axiom + High Energy Physics
Cc: Camm Maguire, list,	Nicolas Thiery, Bertfried Fauser

If you (or anyone else) is interested, a very nice paper appeared today
http://arxiv.org/abs/hep-ph/0511176 which presents an algorithm for the
evaluation of loop integrals.  I would love to see this implemented in
axiom.

I would also be interested if the experts could read it and estimate
what is missing from axiom for such an implementation (if anything).

\start
Date: Tue, 15 Nov 2005 11:54:58 -0600
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

Hans Peter Wuermli Hans Peter Wuermli writes:

> But even checking that some summand is a hypergeometric term causes the
> greatest pain. So in fact, the last thing I tried was trying to check wether
> a quotient
> 
> F(n-1,k)/F(n,k) ,
> 
> primarily given by an Expression Integer could be "coerced" / "converted" / 
> "retracted" (certainly not) to, say, a 
> 
> Fraction Polynomial Integer.

Indeed, "retractIfCan(argument)@Domain" is your friend. What it does is to
check whether "argument" can be regarded as an element of "Domain".

Well, in this particular case not quite, since you want rationality only in
k, and unfortunately there is no such domain in Axiom...

To see how it is done see the function notRF? in combfunc.spad.pamphlet.

A suggestion: as you probably know, Gospers method is already implemented in
Axiom. Maybe you could implement a simple version of Zeilbergers algorithm?
Very similar problems are involved, and the mathematics are no more difficult.

If you do, you will need to have a method of representing recurrences, with
which I can help.

\start
Date: Tue, 15 Nov 2005 15:57:02 -0600
From: MathAction (Hans Peter Wuermli)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

Hi Martin

I am a bit tired, so my response might be make not make sense.

> > F(n-1,k)/F(n,k) ,
> >
> > primarily given by an Expression Integer could be "coerced" / "converted"
> > / "retracted" (certainly not) to, say, a
> >
> > Fraction Polynomial Integer.
>
> Indeed, "retractIfCan(argument)@Domain" is your friend. What it does is to
> check whether "argument" can be regarded as an element of "Domain".

I don't understand. Wouldn't argument have to be in a Domain' which is a 
target of an injection from Domain, like INT -> FRAC INT. But for that you 
would have to inject rational functions into the Domain of expressions. I 
admit that I don't understand yet enough. 

I tried to apply your advice, but I am still where I was before, meaning that 
only good look brings me to the right answer, e.g.

(1) -> e2:=binomial(n-1,k)/binomial(n,k)

         n - 1
        (     )
           k
   (1)  -------
           n
          ( )
           k
                                                     Type: Expression Integer
(2) -> retractIfCan(e2)@Union(Fraction Polynomial Integer, "failed")

   (2)  "failed"
                                                    Type: Union("failed",...)
(3) -> retractIfCan(normalize(e2))@Union(Fraction Polynomial Integer, 
"failed")

        n - k
   (3)  -----
          n
                                 Type: Union(Fraction Polynomial Integer,...)

> To see how it is done see the function notRF? in combfunc.spad.pamphlet.

Thank you. I will study it.

> A suggestion: as you probably know, Gospers method is already implemented
> in Axiom. 

Yes, I know. I had bought the Zeilberger-Wilf-Petkovsek A=B book, when the sum 
problem was discussed some time ago on this list. My first try then was to 
check whether I could play with polynomials of forward difference operators. 
I manage now, but then my naive approach was to take a polynomial, say, p[n], 
and substitute n for N: subst(p,n=N) or eval(p,n=N), something that fails 
miserably. Nevertheless, the idea of substitution is so general that one 
would expect that Axiom would allow it.

> Maybe you could implement a simple version of Zeilbergers 
> algorithm? 

I still don't master the simplest first steps of programming in Axiom, but 
comes times, comes success ... 

> If you do, you will need to have a method of representing recurrences, with
> which I can help.

Yes, I am interested (as I remember you pointed the list once to it, haven't 
you?), though my primary goal would not be to have some representation, but 
to be able to represent the recurrences as naturally as possibly, natural 
meaning as close to standard math language as possible. I am just as much 
interested in Axiom as a language as in Axiom as a tool to manipulate 
expressions and do some Algebra (and to occasionally solve a problem).

I have followed to some extent the discussion on Lisp, Boot and Axiom. As a 
heretic I would prefer Haskell as the underlying language anyway. Axiom 
itself has a nice foundation, but I wonder whether some of the understanding 
of typed functional languages that devoloped during the last 20 years would 
not help to make Axiom even better.

But as an aside: maybe 3 years ago when I encountered by chance Aldor I became 
quite enthusiastic about it, but stayed off really using it, because the 
project was not free. Nevertheless, as some of my colleagues knew Manuel 
Bronstein from his time in Zurich, I approached him and asked whether the 
Algebra library would remain closed source. He answered very positively that 
he only needed to brush up (to clean some sins, as I understood), before he 
was going to publish the source. It seemed to me at the time that Stephen 
Watt "owned" the compiler and Manuel the Algebra libraries, but with much 
more openness on. Are they really lost with INRIA?

\start
Date: Wed, 16 Nov 2005 01:07:25 +0100 (CET)
From: Bertfried Fauser
To: Bob McElrath
Subject: re: Axiom + High Energy Physics
Cc: Camm Maguire, Nicolas Thiery, Bertfried Fauser

Hi *,

I will read it, but I am on my way to a 1 month visit and need a few days
to settle down. I would also be interested in seeing eg Feyncalc, FORM and
other packages at least analysed to see what could be used in AXIOM.
However, my personal interests turn to more combinatorial issues, as Hopf
algebra of renormalization, and I don not (yet) see how to mergs these two
fields.

\start
Date: Wed, 16 Nov 2005 00:24:21 -0000
From: Bill Page
To: Tim Daly
Subject: (no subject)
Cc: Tim Daly Jr

On Monday, November 14, 2005 8:45 AM Tim Daly wrote:
> 
> > Subject: lisp webserver
> > 
> > If you want to bolt Lisp onto a webserver, the sweet spot 
> > of simple and nice is probably tbnl and mod_lisp:
> > <http://www.weitz.de/tbnl/>. Nothing fancy, but it all works
> > well.

Kai Kaminshi used Araneida for AxiomUI instead of Apache+mod_lisp
because I think he wanted an all lisp solution for desktop use.
Must people don't run Apache on their desktop configurations.
Perhaps for performance reasons on a network mod_lisp might be
preferred although from what I hear Araneida is supposed to be
pretty good. Is any other reason why Tim Daly Jr. recommends an
Apache solution?

As far as I know Kai did not used 'tbnl' in AxiomUI but since it
can act as a webserver without Apache maybe it would also have been
a suitable tool for AxiomUI. It is not clear to me what 'tbnl'
really adds to the mix if you have already gone to the trouble to
use Araneida except perhaps session management - and that is only
really of interest if you on the web, not for desktop use.

> > 
> > The website for finding Lisp software is <http://www.cliki.net/>.
> > 

But cliki itself seems like a fairly neat and tidy wiki implemented
in lisp. If someone was motivated to add LaTeX and Axiom integration
to cliki then that might be quite interesting.

Since http://www.cliki.net lists Maxima as a common lisp application
and GCL as a common lisp implementation and Axiom runs on GCL it
makes sense that cliki.net should also include Axiom, so I have just
added it. If you get a chance, you might want to review what I wrote.

> > I run my Lisp code in SBCL: <http://www.sbcl.org>.  It supports
> > the full standard
> > (<http://www.lispworks.com/documentation/HyperSpec/>),
> > does native code compilation, has multithreading, two different 
> > profilers, comes with libraries for system definition (asdf),
> > fetching and installing packages and their dependencies
> > (asdf-install), sockets, posix functions, a foreign function
> > interface, yadda yadda yadda...
> >

Wouldn't it be nice (hint, hint :) if someone decided to do an
SBCL port of Axiom?

I believe Kai chose clisp for AxiomUI because in principle it is
standards compliant and is supposed to run easily on Windows,
however apparently that does not apply to all lisp applications
written in clisp since we still have not successfully installed
AxiomUI on Windows. The problem seems to have something do with
differences in path names between Linux and Windows.
 
> > So in my world, you would keep the client functionality (the stuff
> > in the web browser) relatively straightforward, and do all the
> > magic in your Lisp webserver.  Nobody likes programming in a web
> > browser anyway.
> > 
> > (it's okay to quote this email...)
> > --
> > -Tim
> 
> i got this response to the doyen questions. if i understand
> the architecture correctly this solves both the questions of 
> "drag and drop" and "embedded command window".

I don't see how it solves either of these questions. If I am
wrong I would be glad if you could explain it to me.

> 
> "drag and drop" works since the browser, the webserver, and 
> lisp are all running on the same machine.

??? Seems to me there is a lot more to it than that! :(

> thus anything the browser asks for (such as notangle-compile-load,
> noweave-latex-xdvi can be done by a background lisp process.

That part is no problem in any case. See how it is done in
AxiomUI for instance. But it can also be done directly from
the browser in javascript - see how Bob McElrath did this for
his TiddlyWiki interface for Axiom. In that case there is
nothing to install except the browser, but it doesn't use AJAX
(yet).

> 
> "embedded command window" is also possible. it appears that 
> franz already offers this ability with a lisp prompt in a
> window. they appear to be using a java applet which opens a
> tcp connection to the host-based lisp process and emulates a
> terminal.

Very "old tech"... I don't see why you think this is relevant.

> 
> so doyen seems much more feasible at this point. i'm going to 
> prototype this setup and, if i can make it work, merge it onto
> the doyencd project at sourceforge.
> 

If you want to configure Apache on axiom-developer.org with
mod_lisp I would be glad to help although I doubt that I will be
much inclined to start developing web applications in lisp any
time soon. Compared to Zope (which some people seem to think is
pretty complicated) all this lisp-based web stuff seems completely
over the top to me... ;)

\start
Date: Tue, 15 Nov 2005 20:54:04 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Recall: doyen
Cc: Tim Daly Jr

funny :-)

\start
Date: 15 Nov 2005 20:17:44 -0500
From: Camm Maguire
To: Bob McElrath
Subject: Re: Axiom + High Energy Physics
Cc: list, Nicolas Thiery, Bertfried Fauser

Greetings!

Bob McElrath writes:

> If you (or anyone else) is interested, a very nice paper appeared today
> http://arxiv.org/abs/hep-ph/0511176 which presents an algorithm for the
> evaluation of loop integrals.  I would love to see this implemented in
> axiom.
> 

Thanks for the reference!  Got the paper and will review -- it does
look very interesting.  This and the symbolic summation algorithm
discussed previously interest me and hopefully will result in a
directed contribution along these lines from me to axiom someday.  For
the next few months I'll be busy with gcl 2.7.0 for sure.

Take care,

> I would also be interested if the experts could read it and estimate
> what is missing from axiom for such an implementation (if anything).

\start
Date: Wed, 16 Nov 2005 02:12:23 +0100
From: Tim Daly Jr.
To: Bill Page
Subject: Re:

On Wed, 2005-11-16 at 00:24 +0000, Bill Page
wrote:

> Must people don't run Apache on their desktop configurations.

What?  I don't know these most people, but most of the people I know run
Apache. 

> Perhaps for performance reasons on a network mod_lisp might be
> preferred although from what I hear Araneida is supposed to be
> pretty good. Is any other reason why Tim Daly Jr. recommends an
> Apache solution?

I don't know exactly what you guys are doing, being CC'd in the middle
of this and all, but I wouldn't think about performance until you have
something working.  

Apache is solid, well-tested, and well-maintained.  For a hostile
environment like the internet, it's an appropriate choice.  The author
of Araneida runs it behind Apache, both for his commercial sites, and
for the cliki.

TBNL provides a more traditional framework than Araneida.  I think it's
also slightly more comprehensive, and certainly better documented. ;)

> But cliki itself seems like a fairly neat and tidy wiki implemented
> in lisp. If someone was motivated to add LaTeX and Axiom integration
> to cliki then that might be quite interesting.

FWIW, anybody who wants to play with cliki would probably have a lot
more fun with cl-typesetting than LaTeX. :)

> Since http://www.cliki.net lists Maxima as a common lisp application
> and GCL as a common lisp implementation and Axiom runs on GCL it
> makes sense that cliki.net should also include Axiom, so I have just
> added it. If you get a chance, you might want to review what I wrote.

Axiom runs in gcl's special "archaic" mode; it's not a Common Lisp
program yet.  But adding it to the cliki might help that process
along. :)  Thanks for adding it.

> 
> Wouldn't it be nice (hint, hint :) if someone decided to do an
> SBCL port of Axiom?

I started on it, got a good chunk of the compiler compiled (which is a
long way from working...), and couldn't maintain interest because (at
least that part of) axiom's code is so awfully horrible.  It seriously
needs a rewrite, and I don't have the time.

> > "drag and drop" works since the browser, the webserver, and 
> > lisp are all running on the same machine.
> 
> ??? Seems to me there is a lot more to it than that! :(

I think what Tim means here is that he doesn't see any reason why it
wouldn't work, with suitable application of effort.  There's always more
to it. :(

> > "embedded command window" is also possible. it appears that 
> > franz already offers this ability with a lisp prompt in a
> > window. they appear to be using a java applet which opens a
> > tcp connection to the host-based lisp process and emulates a
> > terminal.
> 
> Very "old tech"... I don't see why you think this is relevant.

Actually, the web repl is only a year or two old, I think.  What could
you possibly think is "old tech" about it?  What kind of a term is that,
anyway?  Software is not seasonal.  If you don't understand the "old
tech", you're just going to re-invent it, (probably in a bloated,
embedded-in-a-web-browser, xml-compliant, and thoroughly unprincipaled
way).

> If you want to configure Apache on axiom-developer.org with
> mod_lisp I would be glad to help although I doubt that I will be
> much inclined to start developing web applications in lisp any
> time soon. Compared to Zope (which some people seem to think is
> pretty complicated) all this lisp-based web stuff seems completely
> over the top to me... ;)

Working on a web application written in Lisp might be a nice way to
learn enough of it to work on Axiom.  Despite rumors to the contrary,
web applications are often simpler than computer algebra software.

\start
Date: 15 Nov 2005 20:24:31 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: Axiom + High Energy Physics
Cc: Nicolas Thiery, Bertfried Fauser

Greetings!

> The Makefile.pamphlet in the directory will be used to construct
> the proper files to hook into Axiom.
> 
> I don't yet have this fully implemented for all of BLAS but it's coming.
> 
> I believe Camm is the BLAS maintainer but i'm not certain.
> 

For Debian, yes.  blas, lapack and atlas.  I'd love to do an official
gcl binding to these libs someday.  One poster on this list has
already achieved the rudiments at least.  The key to remember, if you
want my opinion, is to interface to generic blas and lapack,
preferably using the fortran interface (as clapack is a bit unusual),
and then rely on Debian's (or similar) ld.so trick to automatically
pull in optimized atlas compatible libraries at runtime depending on
the capabilities of the running cpu.  Quite a large tree of software
in Debian is transparently linking against atlas in this way at
present.   For x86, for example, one can choose from atlas3-base,
atlas3-sse, atlas3-sse2, and atlas3-3dnow -- just install the package
and get the performance benefit on appropriate harddware without
recompiling!.  I'd love gmp3 to do the same someday.

Take care,


> t
> 
> =========================================================================
> 
> \documentclass{article}
> \usepackage{axiom}
> \begin{document}
> \title{subroutine drotg(da,db,c,s)}
> \author{Jack Dongarra}
> \maketitle
> \begin{abstract}
> \end{abstract}
> \eject
> \tableofcontents
> \eject
> \section{Purpose}
> This generates a real Givens plane rotation with parameters $c$ and $s$
> such that given a real $a$ and $b$:
> $$
> \left(
> \begin{array}{cc}
> c & s\\
> -s & c
> \end{array}
> \right)
> \left(
> \begin{array}{c}
> da\\
> db
> \end{array}
> \right)
> =
> \left(
> \begin{array}{c}
> f\\
> 0
> \end{array}
> \right)
> $$
> \noindent
> The routine computes $c$, $s$, and $f$ as follows:
> $$
> f = \sigma{}\sqrt{da^2 + db^2}
> $$
> $$
> c=\left\{
> \begin{array}{ccc}
> da/f & {\rm if\ }& f \ne 0\\
> 1   & {\rm if\ }& f = 0
> \end{array}
> \right.
> s=\left\{
> \begin{array}{ccc}
> db/f & {\rm if\ }& f \ne 0\\
> 0   & {\rm if\ }& f = 0
> \end{array}
> \right.
> $$
> $$
> {\rm where\ \ \ \ }
> \sigma=\left\{
> \begin{array}{ccc}
> {\rm sign\ }da & {\rm if\ }& \vert{}da\vert{} > \vert{}db\vert{}\\
> {\rm sign\ }db & {\rm if\ }& \vert{}da\vert{} \le \vert{}db\vert{}\\
> \end{array}
> \right.
> $$
> The routine also computes the value of $z$ defined as
> $$
> z=\left\{
> \begin{array}{ccl}
> s   & {\rm if\ }& \vert{}s\vert{} < c {\rm\ or\ }c = 0\\
> 1/c & {\rm if\ }& 0 < \vert{}c\vert{} \le s
> \end{array}
> \right.
> $$
> This enables $c$ and $s$ to be reconstructed from the single value $z$ as
> $$
> c=\left\{
> \begin{array}{ccc}
> \sqrt{1-z^2} & {\rm if\ }& \vert{}z\vert{} \le 1\\
> 1/z          & {\rm if\ }& \vert{}z\vert{} > 1
> \end{array}
> \right.
> s=\left\{
> \begin{array}{ccc}
> z & {\rm if\ }&  \vert{}z\vert{} \le 1\\
> \sqrt{1-c^2}   & {\rm if\ }&  \vert{}z\vert{} > 1
> \end{array}
> \right.
> $$
> To apply the plane rotation to a pair of real vectors call DROT.
> \section{Specification}
> \begin{verbatim}
> subroutine drotg(double precision da,
>                  double precision db,
>                  double precision c,
>                  double precision s)
> \end{verbatim}
> \section{Parameters}
> \begin{list}{}
> \item {\bf da} (Double Precision)
> \begin{list}{}
> \item {\sl Entry}: first element of the vector which determines the rotation
> \item {\sl Exit}: the value {f}
> \end{list}
> \item {\bf db} (Double Precision)
> \begin{list}{}
> \item {\sl Entry}: second element of the vector which determines the rotation
> \item {\sl Exit}: the value {z}
> \end{list}
> \item {\bf c} (Double Precision)
> \begin{list}{}
> \item {\sl Entry}: no value
> \item {\sl Exit}: cosine of the rotation
> \end{list}
> \item {\bf s} (Double Precision)
> \begin{list}{}
> \item {\sl Entry}: no value
> \item {\sl Exit}: sine of the rotation
> \end{list}
> \end{list}
> \section{Error Indicators and Warnings}
> None.
> \section{Examples}
> \subsection{Example 1: $f = 0$}
> \begin{verbatim}
>       call drotg( 0.0, 0,0, c, s)
> ==>
>       da = 0.0
>       db = 0.0
>       c  = 1.0
>       s  = 0.0
> \end{verbatim}
> \subsection{Example 2: $c = 0$}
> \begin{verbatim}
>       call drotg( 0.0, 2.0, c, s)
> ==>
>       da = 2.0
>       db = 1.0
>       c  = 0.0
>       s  = 1.0
> \end{verbatim}
> \subsection{Example 3: $\vert{}b\vert{} > \vert{}a\vert{}$}
> \begin{verbatim}
>       call drotg( 6.0, -8.0, c, s)
> ==>
>       da = -10.0
>       db =  -1.666...
>       c  =  -0.5
>       s  =   0.8
> \end{verbatim}
> \subsection{Example 4: $\vert{}a\vert{} > \vert{}b\vert{}$}
> \begin{verbatim}
>       call drotg( 8.0, 6.0, c, s)
> ==>
>       da = 10.0
>       db =  0.6
>       c  =  0.8
>       s  =  0.6
> \end{verbatim}
> <<fortran>>=
>       subroutine drotg(da,db,c,s)
> c
> c     construct givens plane rotation.
> c     jack dongarra, linpack, 3/11/78.
> c
>       double precision da,db,c,s,roe,scale,r,z
> c
>       roe = db
>       if( dabs(da) .gt. dabs(db) ) roe = da
>       scale = dabs(da) + dabs(db)
>       if( scale .ne. 0.0d0 ) go to 10
>          c = 1.0d0
>          s = 0.0d0
>          r = 0.0d0
>          z = 0.0d0
>          go to 20
>    10 r = scale*dsqrt((da/scale)**2 + (db/scale)**2)
>       r = dsign(1.0d0,roe)*r
>       c = da/r
>       s = db/r
>       z = 1.0d0
>       if( dabs(da) .gt. dabs(db) ) z = s
>       if( dabs(db) .ge. dabs(da) .and. c .ne. 0.0d0 ) z = 1.0d0/c
>    20 da = r
>       db = z
>       return
>       end
> @
> \section{Makefile}
> <<*>>=
> TANGLE=/usr/local/bin/NOTANGLE
> WEAVE=/usr/local/bin/NOWEAVE
> LATEX=/usr/bin/latex
> 
> all: code doc run
> 
> code: drotg.pamphlet
> 	${TANGLE} -Rfortran drotg.pamphlet >drotg.f
> 
> doc:
> 	${WEAVE} -t8 -delay drotg.pamphlet >drotg.tex
> 	${LATEX} drotg.tex 2>/dev/null 1>/dev/null
> 	${LATEX} drotg.tex 2>/dev/null 1>/dev/null
> 
> run:
> 	@echo done
> remake:
> 	${TANGLE} -t8 drotg.pamphlet >Makefile.drotg
> 
> @
> \eject
> \begin{thebibliography}{99}
> \bibitem{1} Lawson, C.L., Hanson, R.J., Kincaid, D.R., and Krogh, F.T. 
> ``Basic Linear Algebra Subprograms for Fortran Usage''
> ACM Trans. on Math. Soft. (TOMS) Vol 5, pp308--325 (1979)
> \bibitem{2} Numerical Algorthms Fortran Library routine F06AAF\\
> {\sl http://www.nag.co.uk/numeric/fl/manual/pdf/F06/f06aaf.pdf}
> \bibitem{3} IBM ESSL Documentation routine DROTG\\
> {\sl http://csit1cwe.fsu.edu/extra\_link/essl/essl250.html\#HDRHSROTG}
> \end{thebibliography}
> \end{document}

\start
Date: Wed, 16 Nov 2005 02:11:20 -0000
From: Bill Page
To: Tim Daly Jr.
Subject: Re: Doyen

Tim Daly Jr wrote:

> On Wed, 2005-11-16 at 00:24 +0000, Bill Page
> wrote:
> 
> > Must people don't run Apache on their desktop configurations.
> 
> What?  I don't know these most people, but most of the people
> I know run Apache.

Oh, that's good. I thought that most Linux distributions considered
Apache a "server" application that was not installed by default in
a "desktop" configuration. But if more people are running Apache on
their desktop computers, I think that's fine.

> 
> > Perhaps for performance reasons on a network mod_lisp might be
> > preferred although from what I hear Araneida is supposed to be
> > pretty good. Is any other reason why Tim Daly Jr. recommends an
> > Apache solution?
> 
> I don't know exactly what you guys are doing, being CC'd in the
> middle of this and all,

Sorry, you were just on the Cc list to which I was replying
regarding the "Doyen project" about which I presumed you did have
some previous knowledge. We are really "doing" much more than that.
But anyway, I appreciate your reply.

> but I wouldn't think about performance until you have
> something working.  
> 
> Apache is solid, well-tested, and well-maintained.  For a
> hostile environment like the internet, it's an appropriate
> choice.

Agreed. In the case of Doyen, however this is an application
that is intended to run locally on the desktop - just another
gui application except for the choice of web browser as user
interface. It is usually not difficult to protect such a
application from the internet.

> The author of Araneida runs it behind Apache, both for his
> commercial sites, and for the cliki.

I think that is a good strategy. On the axiom-developer.org
server we also run Apache as the front-end with Zope behind it
for similar reasons.

> 
> TBNL provides a more traditional framework than Araneida.
> I think it's also slightly more comprehensive, and certainly
> better documented. ;)
> 
> > But cliki itself seems like a fairly neat and tidy wiki
> > implemented in lisp. If someone was motivated to add LaTeX
> > and Axiom integration to cliki then that might be quite
> > interesting.
> 
> FWIW, anybody who wants to play with cliki would probably
> have a lot more fun with cl-typesetting than LaTeX. :)

I've looked at cl-typesetting. It's nice but it doesn't get you
very far if your source documents are all in LaTeX and Axiom
generates LaTeX output. In AxiomUI for example it is clear that
jsmath on the browser gets you a lot further.

> 
> > Since http://www.cliki.net lists Maxima as a common lisp
> > application and GCL as a common lisp implementation and
> > Axiom runs on GCL it makes sense that cliki.net should also
> > include Axiom, so I have just added it. If you get a chance,
> > you might want to review what I wrote.
> 
> Axiom runs in gcl's special "archaic" mode; it's not a Common
> Lisp program yet.  But adding it to the cliki might help that
> process along. :)  Thanks for adding it.

Is Maxima compiled on GCL as a Common Lisp application?

I think upgrading the Axiom source to Common Lisp is something
that should be done with high priority. If I had the necessary
skill, I would probably be working on that right now.

> 
> > 
> > Wouldn't it be nice (hint, hint :) if someone decided to do
> > an SBCL port of Axiom?
> 
> I started on it, got a good chunk of the compiler compiled
> (which is a long way from working...), and couldn't maintain
> interest because (at least that part of) axiom's code is so
> awfully horrible. It seriously needs a rewrite, and I don't
> have the time.

I thought Axiom was supposed to be quite portable - having been
previous compiled on a long list of pre-historic lisps. From
what I understood, from Tim, just about the only thing
preventing it from be Common Lisp was some non-standard use
of packages. Ignoring any revulsion you might feel for working
on awfully horrible code, having worked on moving Axiom to SBCL,
is it your experience that the changes required to make Axiom
conform to the Common Lisp standard are much more than that?

> 
> > > "embedded command window" is also possible. it appears that 
> > > franz already offers this ability with a lisp prompt in a
> > > window. they appear to be using a java applet which opens a
> > > tcp connection to the host-based lisp process and emulates
> > > a terminal.
> > 
> > Very "old tech"... I don't see why you think this is relevant.
> 
> Actually, the web repl is only a year or two old, I think.  What
> could you possibly think is "old tech" about it?  What kind of a
> term is that, anyway?  Software is not seasonal.

It's a pejorative term. I know people still use terminal emulators,
but the point of Doyen is a graphical user interface. I don't like
the idea of slapping some console-style terminal emulation inside
a web browser and calling that progress.

But perhaps I completely mis-understood. What is a 'web repl'?

> If you don't understand the "old tech", you're just going to
> re-invent it, (probably in a bloated, embedded-in-a-web-browser,
> xml-compliant, and thoroughly unprincipaled way).

I agree. In fact, that was basically my point.

> 
> > If you want to configure Apache on axiom-developer.org with
> > mod_lisp I would be glad to help although I doubt that I will
> > be much inclined to start developing web applications in lisp
> > any time soon. Compared to Zope (which some people seem to
> > think is pretty complicated) all this lisp-based web stuff
> > seems completely over the top to me... ;)
> 
> Working on a web application written in Lisp might be a nice way
> to learn enough of it to work on Axiom.  Despite rumors to the
> contrary, web applications are often simpler than computer algebra
> software.
> 

With the proper tools, I think a web application (even in lisp)
should probably be somewhere between 100 to 1000 lines of code
so I don't know how much opportunity that would give me to learn
much more about lisp. :)

But really, my point is rather similar to yours at the beginning
of this message regarding Apach+mod_lisp. Zope works. It has
some very high level applications available off-the-shelf and
it required about 100 lines of python code to integrate with
Axiom - so why not use it?

\start
Date: Tue, 15 Nov 2005 22:08:05 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: allprose

typo in Makefile s/programms/programs/
typo in Makefile s/environemnt/environment/
\xALLPROSE{} expands to nothing
\xAldor{} expands to nothing
\xPerl{} expands to nothing
\xNoweb{} expands to nothing

the axiom version of notangle fixes the problem of << in source code
so it no longer fails. this is one of the patches that Norman Ramsey
would not accept because I modified the C sources. It appears that
you have a different solution. Please contact Norman to see if he'll
incorporate your patch. If so, we can remove the patch from axiom.
maybe we can even fix it to use the standard distribution.

i still don't have it running but i continue to work on it.
as you can see, i'm reading the .nw files


\start
Date: Wed, 16 Nov 2005 01:03:05 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: allprose missing file

i moved allprose to a different system and almost successfully
built it. unfortunately it cannot find rhxterm.sty.

\start
Date: Wed, 16 Nov 2005 01:29:32 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: allprose missing file

i downloaded rhxterm.sty, put it in misc and ran texhash.
now it cannot find 'typeoutframed.sty' and neither can google.

\start
Date: Wed, 16 Nov 2005 01:33:10 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: allprose missing file

despite the missing .sty file it works!
this is cool. we have to import this technology into axiom.
of course it appears that you've licensed it under GPL and
we'd need your permission to include it under a second BSD
license. since you're the author you're the only one who
can authorize that.

\start
Date: Wed, 16 Nov 2005 07:05:39 -0000
From: Bill Page
To: list
Subject: Axiom Foundation 1st Annual Report 2004/5
Cc: Camm Maguire

Axiom Developers;

The Axiom Foundation was established approximately 1 year ago to
promote the development and maintenance of the open source version
of Axiom through the dispersement of donations to support Axiom-
related projects and through the Award Of Bounties.


Foundation Membership

The original plan

( see http://wiki.axiom-developer.org/AxiomFoundation )

selected three registered Axiom Developers (Bob McElrath,
Camm Maguire and Martin Rubey) as the initial members of the
committee. The idea is that these 3 people will make decisions
for the Foundation for a 1 year renewable term, therfore now
is probably a good time to ask the current members if they wish
to continue their membership and if necessary ask for new
volunteers for this position. My hope is that at most 1 member
might not wish to renew, in which case someone new can step
forward for their turn and in this way we will establish
some continuity of membership. (Please don't everyone say they
want to resign at once! :) Or perhaps the current memebers
are satisfied to continue for one more year?


Foundation Projects

So far, I think it is fair to say that membership in the Axiom
Foundation has not involved any difficult decisions or an undue
amount of time. There was only a very low level of free donations
to Axiom (see report below) and so no decisions about actual
Award of Bounties have been made yet this year. Of course we can
all hope that the level of interest in Axiom continues to rise
and that sooner or later a large donor or a corporate sponsor
will appear to make the work of the Foundation much more
interesting.

This year at least I think we can be proud that Axiom did
receive some serious support from Google through the Summer of
Code project. I think it would be great if we can repeat this
next year in an even bigger way.


Donations Received

Since November 15, 2004 the Axiom Foundation has received
donations from the following sources:

  Donations via PayPal: 3 donors           total: $260.07 USD
  Donations via E-gold: 1 donor            total:   $9.88 USD *
  Donation via personal check: 1 donor     total: $100.00 USD
  Revenue via Axiom Gear sales at CafePress
              3 orders    Gross: $59.95    Net:    $30.00 USD **

                                          Total    $499.87 USD

Notes: * Includes e-gold transaction.
      ** Revenue is 30% to 50% of sales depending on item.

I can provide a detailed list of transactions to Axiom Foundation
members on request.


Conclusions

Well, I think this has been an exciting year for Axiom developers
and Axiom users based on the monthly statistics on the number of
accesses to the Axiom web site, downloads of Axiom and of the
Axiom Book as well as the continued steady exchange of email
messages via the email lists. But unfortunately this excitement
has not yet resulted in a significant level of donations. In
spite of this, I think it might be a good idea for the Foundation
to consider some dispersement of the current balance towards 1 or
more bounties as originally planned.


Summary of Recommendations

1) Open invitations to (re)new Axiom Foundation memberships.

2) Receive proposals for Award of Bounties.


----------

If anyone has any questions about this report or would like to
comment or make recommendations please ask either via this email
list or in private if you wish.

\start
Date: 16 Nov 2005 09:38:06 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: Axiom Foundation 1st Annual Report 2004/5
Cc: Camm Maguire, list

* I would like to stay

* I would like to post again that bounties for Axiom are available in the
  appropriate newsgroups. I'll do so in december, since I do not know yet
  whether two students who said that they were going to do something are
  actually going to do something. Of course, I'll send you a manuscript before
  posting. 

  I really think that the most important activity for the Axiom foundation in
  the coming term will be to spend the 500$ in a mathematical package. If we
  are able to do so, we will have attracted at least one new developer, who
  really should be a mathematician. We need them badly!

Martin

Bill Page writes:

> Axiom Developers;
> 
> The Axiom Foundation was established approximately 1 year ago to
> promote the development and maintenance of the open source version
> of Axiom through the dispersement of donations to support Axiom-
> related projects and through the Award Of Bounties.
> 
> 
> Foundation Membership
> 
> The original plan
> 
> ( see http://wiki.axiom-developer.org/AxiomFoundation )
> 
> selected three registered Axiom Developers (Bob McElrath,
> Camm Maguire and Martin Rubey) as the initial members of the
> committee. The idea is that these 3 people will make decisions
> for the Foundation for a 1 year renewable term, therfore now
> is probably a good time to ask the current members if they wish
> to continue their membership and if necessary ask for new
> volunteers for this position. My hope is that at most 1 member
> might not wish to renew, in which case someone new can step
> forward for their turn and in this way we will establish
> some continuity of membership. (Please don't everyone say they
> want to resign at once! :) Or perhaps the current memebers
> are satisfied to continue for one more year?
> 
> 
> Foundation Projects
> 
> So far, I think it is fair to say that membership in the Axiom
> Foundation has not involved any difficult decisions or an undue
> amount of time. There was only a very low level of free donations
> to Axiom (see report below) and so no decisions about actual
> Award of Bounties have been made yet this year. Of course we can
> all hope that the level of interest in Axiom continues to rise
> and that sooner or later a large donor or a corporate sponsor
> will appear to make the work of the Foundation much more
> interesting.
> 
> This year at least I think we can be proud that Axiom did
> receive some serious support from Google through the Summer of
> Code project. I think it would be great if we can repeat this
> next year in an even bigger way.
> 
> 
> Donations Received
> 
> Since November 15, 2004 the Axiom Foundation has received
> donations from the following sources:
> 
>   Donations via PayPal: 3 donors           total: $260.07 USD
>   Donations via E-gold: 1 donor            total:   $9.88 USD *
>   Donation via personal check: 1 donor     total: $100.00 USD
>   Revenue via Axiom Gear sales at CafePress
>               3 orders    Gross: $59.95    Net:    $30.00 USD **
> 
>                                           Total    $499.87 USD
> 
> Notes: * Includes e-gold transaction.
>       ** Revenue is 30% to 50% of sales depending on item.
> 
> I can provide a detailed list of transactions to Axiom Foundation
> members on request.
> 
> 
> Conclusions
> 
> Well, I think this has been an exciting year for Axiom developers
> and Axiom users based on the monthly statistics on the number of
> accesses to the Axiom web site, downloads of Axiom and of the
> Axiom Book as well as the continued steady exchange of email
> messages via the email lists. But unfortunately this excitement
> has not yet resulted in a significant level of donations. In
> spite of this, I think it might be a good idea for the Foundation
> to consider some dispersement of the current balance towards 1 or
> more bounties as originally planned.
> 
> 
> Summary of Recommendations
> 
> 1) Open invitations to (re)new Axiom Foundation memberships.
> 
> 2) Receive proposals for Award of Bounties.
> 
> 
> ----------
> 
> If anyone has any questions about this report or would like to
> comment or make recommendations please ask either via this email
> list or in private if you wish.
> 
> Sincerely,
> Bill Page
> (as acting Secretary to the Axiom Foundation)

\start
Date: Wed, 16 Nov 2005 02:03:27 -0600
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] Type of Expression Problem

Hans Peter Wuermli writes:

> (1) -> e2:=binomial(n-1,k)/binomial(n,k)
> 
>          n - 1
>         (     )
>            k
>    (1)  -------
>            n
>           ( )
>            k
>                                                      Type: Expression Integer
> (2) -> retractIfCan(e2)@Union(Fraction Polynomial Integer, "failed")
> 
>    (2)  "failed"
>                                                     Type: Union("failed",...)
> (3) -> retractIfCan(normalize(e2))@Union(Fraction Polynomial Integer, 
> "failed")
> 
>         n - k
>    (3)  -----
>           n
>                                  Type: Union(Fraction Polynomial Integer,...)

this follows the documentation: binomial(n-1,k)/binomial(n,k) is not a rational
function, but normalize(e2) is:

        n - k
   (3)  -----
          n
                                                     Type: Expression Integer

Note the type information: it is still EXPR INT. After retraction it becomes
Fraction Integer!

> I manage now, but then my naive approach was to take a polynomial, say, p[n],
> and substitute n for N: subst(p,n=N) or eval(p,n=N), something that fails
> miserably. Nevertheless, the idea of substitution is so general that one
> would expect that Axiom would allow it.

I hope you use HyperDoc:

browse POLY
select operations
notice that there is no subst, but there is eval
select eval
select descriptions...

So what you want is eval(p,n,N) where N has to be of Type Poly. For example, it
could be N::POLY INT

(In the interpreter you don't have to specify anything, it does all the type
coercions for you)

> my primary goal would not be to have some representation, but to be able to
> represent the recurrences as naturally as possibly, natural meaning as close
> to standard math language as possible.

This is a different matter. I think that you should decide what you want to
implement: Zeilbergers algorithm or coercion of holonomic functions to expressions. The latter might be more tricky, but I don't know. 

> But as an aside: maybe 3 years ago when I encountered by chance Aldor I became 
> quite enthusiastic about it, but stayed off really using it, because the 
> project was not free. Nevertheless, as some of my colleagues knew Manuel 
> Bronstein from his time in Zurich, I approached him and asked whether the 
> Algebra library would remain closed source. He answered very positively that 
> he only needed to brush up (to clean some sins, as I understood), before he 
> was going to publish the source. It seemed to me at the time that Stephen 
> Watt "owned" the compiler and Manuel the Algebra libraries, but with much 
> more openness on. Are they really lost with INRIA?

I don't know about Algebra, but SumIt is said to be open source in the near
future.

\start
Date: Wed, 16 Nov 2005 09:10:12 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: allprose missing file

That file is not in the allprose distribution. You have to get it from
http://www.hemmecke.de/aldor subpage ALLPROSE. There I list a few style 
files that are needed for ALLPROSE.

Maybe I should make my distribution a bit bigger and pack up the other 
style files, into the distro. I have not done this, because then I have 
to look at all the different licenses in order to check what I am 
allowed to do.

You can find framed.sty at
http://www.tug.org/tetex/tetex-texmfdist/tex/latex/framed/framed.sty

Ralf

root wrote:
> i moved allprose to a different system and almost successfully
> built it. unfortunately it cannot find rhxterm.sty.
> 
> t

\start
Date: Wed, 16 Nov 2005 00:15:09 -0800
From: Bob McElrath
To: Bill Page
Subject: Re: Axiom Foundation 1st Annual Report 2004/5
Cc: Camm Maguire, list

Egad has it been a year already?

I would like to stay.

I agree with Martin that we need to redouble our efforts to obtain
contributions in exchange for bounties, as there have been none so far.

Posts in relevant newsgroups is a good idea.

I can post to the feyncalc mailing list.  Would that be too much of a
faux pas?

Bill Page [Bill Page] wrote:
> 
> 
> Axiom Developers;
> 
> The Axiom Foundation was established approximately 1 year ago to
> promote the development and maintenance of the open source version
> of Axiom through the dispersement of donations to support Axiom-
> related projects and through the Award Of Bounties.
> 
> 
> Foundation Membership
> 
> The original plan
> 
> ( see http://wiki.axiom-developer.org/AxiomFoundation )
> 
> selected three registered Axiom Developers (Bob McElrath,
> Camm Maguire and Martin Rubey) as the initial members of the
> committee. The idea is that these 3 people will make decisions
> for the Foundation for a 1 year renewable term, therfore now
> is probably a good time to ask the current members if they wish
> to continue their membership and if necessary ask for new
> volunteers for this position. My hope is that at most 1 member
> might not wish to renew, in which case someone new can step
> forward for their turn and in this way we will establish
> some continuity of membership. (Please don't everyone say they
> want to resign at once! :) Or perhaps the current memebers
> are satisfied to continue for one more year?
> 
> 
> Foundation Projects
> 
> So far, I think it is fair to say that membership in the Axiom
> Foundation has not involved any difficult decisions or an undue
> amount of time. There was only a very low level of free donations
> to Axiom (see report below) and so no decisions about actual
> Award of Bounties have been made yet this year. Of course we can
> all hope that the level of interest in Axiom continues to rise
> and that sooner or later a large donor or a corporate sponsor
> will appear to make the work of the Foundation much more
> interesting.
> 
> This year at least I think we can be proud that Axiom did
> receive some serious support from Google through the Summer of
> Code project. I think it would be great if we can repeat this
> next year in an even bigger way.
> 
> 
> Donations Received
> 
> Since November 15, 2004 the Axiom Foundation has received
> donations from the following sources:
> 
>   Donations via PayPal: 3 donors           total: $260.07 USD
>   Donations via E-gold: 1 donor            total:   $9.88 USD *
>   Donation via personal check: 1 donor     total: $100.00 USD
>   Revenue via Axiom Gear sales at CafePress
>               3 orders    Gross: $59.95    Net:    $30.00 USD **
> 
>                                           Total    $499.87 USD
> 
> Notes: * Includes e-gold transaction.
>       ** Revenue is 30% to 50% of sales depending on item.
> 
> I can provide a detailed list of transactions to Axiom Foundation
> members on request.
> 
> 
> Conclusions
> 
> Well, I think this has been an exciting year for Axiom developers
> and Axiom users based on the monthly statistics on the number of
> accesses to the Axiom web site, downloads of Axiom and of the
> Axiom Book as well as the continued steady exchange of email
> messages via the email lists. But unfortunately this excitement
> has not yet resulted in a significant level of donations. In
> spite of this, I think it might be a good idea for the Foundation
> to consider some dispersement of the current balance towards 1 or
> more bounties as originally planned.
> 
> 
> Summary of Recommendations
> 
> 1) Open invitations to (re)new Axiom Foundation memberships.
> 
> 2) Receive proposals for Award of Bounties.
> 
> 
> ----------
> 
> If anyone has any questions about this report or would like to
> comment or make recommendations please ask either via this email
> list or in private if you wish.
> 
> Sincerely,
> Bill Page
> (as acting Secretary to the Axiom Foundation)

\start
Date: Wed, 16 Nov 2005 12:55:27 +0100
From: Tim Daly Jr.
To: Bill Page
Subject: Re: Doyen

On Wed, 2005-11-16 at 02:11 +0000, Bill Page
wrote:

> Is Maxima compiled on GCL as a Common Lisp application?

I don't know.  It is possible to compile Maxima on a Common Lisp, but I
don't think that GCL is a complete Common Lisp implementation yet.  I
think Raymond Toy was responsible for getting it working on CMUCL, but
ICBW.  

> I think upgrading the Axiom source to Common Lisp is something
> that should be done with high priority. If I had the necessary
> skill, I would probably be working on that right now.

The first part of working on something is acquiring the skills you need.
I recommend studying a good book: http://www.gigamonkeys.com/book/

> I thought Axiom was supposed to be quite portable - having been
> previous compiled on a long list of pre-historic lisps. 

It's important to distinguish between being ported and being portable.
Axiom has been ported many times.  The cumulative damage is pretty
significant.

> From
> what I understood, from Tim, just about the only thing
> preventing it from be Common Lisp was some non-standard use
> of packages. Ignoring any revulsion you might feel for working
> on awfully horrible code, having worked on moving Axiom to SBCL,
> is it your experience that the changes required to make Axiom
> conform to the Common Lisp standard are much more than that?

Axiom has been ported by writing compatibility layers that emulate the
Lisp it was being ported from.  At least for the code I looked at, it's
no more a Common Lisp program than it is a CLTL1 (a previous
semi-standard) program.  It's more like a Maclisp/VMLisp program that
predates any semblance of modern style. It also looks like a number of
unfortunately bright hackers cut their teeth on it.  Take this with a
grain of salt, however, because I only spent a few weeks working with
the code, and haven't read all of it.

> It's a pejorative term. I know people still use terminal emulators,
> but the point of Doyen is a graphical user interface. I don't like
> the idea of slapping some console-style terminal emulation inside
> a web browser and calling that progress.

Anybody sufficiently bright is going to want a commandline eventually.
I agree, it's not a good idea to put a commandline for a program that
will only run locally in a web browser.  In general, I don't think it's
a hot idea to use a web browser as an interface for software meant to
run locally.  It's like telephoning somebody in the next room.

> But perhaps I completely mis-understood. What is a 'web repl'?

REPL is a term that is defined in the first chapter or two of basically
every introductory work written about Lisp.  If you don't know what it
is, it would be a good thing to look up.  A web repl is a repl on a web
page.

> With the proper tools, I think a web application (even in lisp)
> should probably be somewhere between 100 to 1000 lines of code
> so I don't know how much opportunity that would give me to learn
> much more about lisp. :)

This is like saying that every rope is 10 feet long, and that wouldn't
be enough to learn about tying knots.  It's just so wrong.

>  Zope works. It has
> some very high level applications available off-the-shelf and
> it required about 100 lines of python code to integrate with
> Axiom - so why not use it?

Hey, why should anybody care what you use?  Pick your poison.  If you do
the heavy lifting on a project, you have to use something that you want
to play with.  

Usually, the more talk about a project, the less is actually happening
with it. 

\start
Date: 16 Nov 2005 14:33:15 +0100
From: Martin Rubey
To: Bob McElrath
Subject: Re: Axiom Foundation 1st Annual Report 2004/5
Cc: Camm Maguire, list

Bob McElrath writes:

> Egad has it been a year already?
> 
> I would like to stay.
> 
> I agree with Martin that we need to redouble our efforts to obtain
> contributions in exchange for bounties, as there have been none so far.
> 
> Posts in relevant newsgroups is a good idea.
> 
> I can post to the feyncalc mailing list.  Would that be too much of a
> faux pas?

Of course not. Please do. But I suggest that we start posting now, hope that a
million (well, maybe only two) interested mathematicians apply and that we
decide just before christmas which project is going to be funded.

\start
Date: 16 Nov 2005 07:52:49 -0500
From: Camm Maguire
To: Bob McElrath
Subject: Re: Axiom Foundation 1st Annual Report 2004/5

Greetings!

Bob McElrath writes:

> Egad has it been a year already?
> 
> I would like to stay.
> 
> I agree with Martin that we need to redouble our efforts to obtain
> contributions in exchange for bounties, as there have been none so far.
> 
> Posts in relevant newsgroups is a good idea.
> 

Me too on all 3 account!

Take care,

> I can post to the feyncalc mailing list.  Would that be too much of a
> faux pas?
> 
> Bill Page [Bill Page] wrote:
> > 
> > 
> > Axiom Developers;
> > 
> > The Axiom Foundation was established approximately 1 year ago to
> > promote the development and maintenance of the open source version
> > of Axiom through the dispersement of donations to support Axiom-
> > related projects and through the Award Of Bounties.
> > 
> > 
> > Foundation Membership
> > 
> > The original plan
> > 
> > ( see http://wiki.axiom-developer.org/AxiomFoundation )
> > 
> > selected three registered Axiom Developers (Bob McElrath,
> > Camm Maguire and Martin Rubey) as the initial members of the
> > committee. The idea is that these 3 people will make decisions
> > for the Foundation for a 1 year renewable term, therfore now
> > is probably a good time to ask the current members if they wish
> > to continue their membership and if necessary ask for new
> > volunteers for this position. My hope is that at most 1 member
> > might not wish to renew, in which case someone new can step
> > forward for their turn and in this way we will establish
> > some continuity of membership. (Please don't everyone say they
> > want to resign at once! :) Or perhaps the current memebers
> > are satisfied to continue for one more year?
> > 
> > 
> > Foundation Projects
> > 
> > So far, I think it is fair to say that membership in the Axiom
> > Foundation has not involved any difficult decisions or an undue
> > amount of time. There was only a very low level of free donations
> > to Axiom (see report below) and so no decisions about actual
> > Award of Bounties have been made yet this year. Of course we can
> > all hope that the level of interest in Axiom continues to rise
> > and that sooner or later a large donor or a corporate sponsor
> > will appear to make the work of the Foundation much more
> > interesting.
> > 
> > This year at least I think we can be proud that Axiom did
> > receive some serious support from Google through the Summer of
> > Code project. I think it would be great if we can repeat this
> > next year in an even bigger way.
> > 
> > 
> > Donations Received
> > 
> > Since November 15, 2004 the Axiom Foundation has received
> > donations from the following sources:
> > 
> >   Donations via PayPal: 3 donors           total: $260.07 USD
> >   Donations via E-gold: 1 donor            total:   $9.88 USD *
> >   Donation via personal check: 1 donor     total: $100.00 USD
> >   Revenue via Axiom Gear sales at CafePress
> >               3 orders    Gross: $59.95    Net:    $30.00 USD **
> > 
> >                                           Total    $499.87 USD
> > 
> > Notes: * Includes e-gold transaction.
> >       ** Revenue is 30% to 50% of sales depending on item.
> > 
> > I can provide a detailed list of transactions to Axiom Foundation
> > members on request.
> > 
> > 
> > Conclusions
> > 
> > Well, I think this has been an exciting year for Axiom developers
> > and Axiom users based on the monthly statistics on the number of
> > accesses to the Axiom web site, downloads of Axiom and of the
> > Axiom Book as well as the continued steady exchange of email
> > messages via the email lists. But unfortunately this excitement
> > has not yet resulted in a significant level of donations. In
> > spite of this, I think it might be a good idea for the Foundation
> > to consider some dispersement of the current balance towards 1 or
> > more bounties as originally planned.
> > 
> > 
> > Summary of Recommendations
> > 
> > 1) Open invitations to (re)new Axiom Foundation memberships.
> > 
> > 2) Receive proposals for Award of Bounties.
> > 
> > 
> > ----------
> > 
> > If anyone has any questions about this report or would like to
> > comment or make recommendations please ask either via this email
> > list or in private if you wish.

\start
Date: Wed, 16 Nov 2005 19:28:49 +0600 (NOVT)
From: Andrey G. Grozin
To: Tim Daly Jr.
Subject: re: Doyen

On Wed, 16 Nov 2005, Tim Daly Jr. wrote:
> On Wed, 2005-11-16 at 02:11 +0000, Bill Page
> wrote:
>> Is Maxima compiled on GCL as a Common Lisp application?
> I don't know.  It is possible to compile Maxima on a Common Lisp, but I
> don't think that GCL is a complete Common Lisp implementation yet.  I
> think Raymond Toy was responsible for getting it working on CMUCL, but
> ICBW.
If the current gcl is configured with --enable-ansi, it is nearly 100% 
compliant common lisp. Maxima runs on it, as well as on clisp, cmucl, 
sbcl, openmcl (on a mac), scl, Allegro cl (the last two lisps are 
commercial). On my laptop, I have maxima on gcl, clisp, cmucl, and sbcl.

\start
Date: Wed, 16 Nov 2005 08:20:49 -0600
From: MathAction (unknown)
To: MathAction
Subject: [#127 Building axiom from source fails on my Fedora Core 3] 

with September source I have the same problem (still on FC3)
I try to use 'setarch i386 -X make' in vain!

\start
Date: Tue, 15 Nov 2005 18:18:26 -0500
From: Bill Page
To: Tim Daly
Subject: RE: doyen
Cc: Tim Daly Jr.

On Monday, November 14, 2005 8:45 AM Tim Daly wrote:
>
> > Subject: lisp webserver
> > From: "Tim Daly Jr." <Tim Daly Jr>
> > To: Tim Daly
> > Content-Type: text/plain
> > Date: Mon, 14 Nov 2005 11:29:43 +0100
> >
> > If you want to bolt Lisp onto a webserver, the sweet spot
> > of simple and nice is probably tbnl and mod_lisp:
> > <http://www.weitz.de/tbnl/>. Nothing fancy, but it all works
> > well.

Kai Kaminshi used Araneida for AxiomUI instead of Apache+mod_lisp
because I think he wanted an all lisp solution for desktop use.
Must people don't run Apache on their desktop configurations.
Perhaps for performance reasons on a network mod_lisp might be
preferred although from what I hear Araneida is supposed to be
pretty good. Is any other reason why Tim Daly Jr. recommends an
Apache solution?

As far as I know Kai did not used 'tbnl' in AxiomUI but since it
can act as a webserver without Apache maybe it would also have been
a suitable tool for AxiomUI. It is not clear to me what 'tbnl'
really adds to the mix if you have already gone to the trouble to
use Araneida except perhaps session management - and that is only
really of interest if you on the web, not for desktop use.

> >
> > The website for finding Lisp software is <http://www.cliki.net/>.
> >

But cliki itself seems like a fairly neat and tidy wiki implemented
in lisp. If someone was motivated to add LaTeX and Axiom integration
to cliki then that might be quite interesting.

Since http://www.cliki.net lists Maxima as a common lisp application
and GCL as a common lisp implementation and Axiom runs on GCL it
makes sense that cliki.net should also include Axiom, so I have just
added it. If you get a chance, you might want to review what I wrote.

> > I run my Lisp code in SBCL: <http://www.sbcl.org>.  It supports
> > the full standard
(<http://www.lispworks.com/documentation/HyperSpec/>),
> > does native code compilation, has multithreading, two different
> > profilers, comes with libraries for system definition (asdf),
> > fetching and installing packages and their dependencies
> > (asdf-install), sockets, posix functions, a foreign function
> > interface, yadda yadda yadda...
> >

Wouldn't it be nice (hint, hint :) if someone decided to do an
SBCL port of Axiom?

I believe Kai chose clisp for AxiomUI because in principle it is
standards compliant and is supposed to run easily on Windows,
however apparently that does not apply to all lisp applications
written in clisp since we still have not successfully installed
AxiomUI on Windows. The problem seems to have something do with
differences in path names between Linux and Windows.

> > So in my world, you would keep the client functionality (the stuff
> > in the web browser) relatively straightforward, and do all the magic
> > in your Lisp webserver.  Nobody likes programming in a web browser
> > anyway.
> >
> > (it's okay to quote this email...)
> > --
> > -Tim
>
> i got this response to the doyen questions. if i understand
> the architecture correctly this solves both the questions of
> "drag and drop" and "embedded command window".

I don't see how it solves either of these questions. If I am
wrong I would be glad if you could explain it to me.

>
> "drag and drop" works since the browser, the webserver, and
> lisp are all running on the same machine.

??? Seems to me there is a lot more to it than that! :(

> thus anything the browser asks for (such as notangle-compile-load,
> noweave-latex-xdvi can be done by a background lisp process.

That part is no problem in any case. See how it is done in
AxiomUI for instance. But it can also be done directly from
the browser in javascript - see how Bob McElrath did this for
his TiddlyWiki interface for Axiom. In that case there is
nothing to install except the browser, but it doesn't use AJAX
(yet).

>
> "embedded command window" is also possible. it appears that
> franz already offers this ability with a lisp prompt in a
> window. they appear to be using a java applet which opens a
> tcp connection to the host-based lisp process and emulates a
> terminal.

Very "old tech"... I don't see why you think this is relevant.

>
> so doyen seems much more feasible at this point. i'm going to
> prototype this setup and, if i can make it work, merge it onto
> the doyencd project at sourceforge.
>

If you need/want any help configuring Apache on axiom-developer.org
with mod_lisp I would be glad to help although I doubt that I will
be much inclined to start developing web applications in lisp any
time soon. Compared to Zope (which some people seem to think is
pretty complicated) all this lisp-based web stuff seems completely
over the top to me... ;)

\start
Date: Tue, 15 Nov 2005 19:21:48 -0500
From: Bill Page
To: Tim Daly
Subject: Recall: doyen
Cc: Tim Daly Jr.

Page, Bill would like to recall the message, "doyen".

\start
Date: Wed, 16 Nov 2005 10:03:20 -0600
From: MathAction (root)
To: MathAction
Subject: [#127 Building axiom from source fails on my Fedora Core 3]

===================================================================
FAQ 36: Axiom won't build on FC3
===================================================================
You need to turn off dynamic library load point randomization.
As root do:

echo 0 >/proc/sys/kernel/exec-shield


===================================================================
FAQ 37: Axiom won't build on FC4
===================================================================
You need to turn off dynamic library load point randomization.
As root do:

echo 0 >/proc/sys/kernel/randomize_va_space

or do

setarch i386 -R make axiom

\start
Date: Wed, 16 Nov 2005 12:27:40 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [Aldor-l] Ann: ALLPROSE / Suggestions

On Wednesday, November 16, 2005 7:53 AM Ralf Hemmecke wrote:
>
> Martin Rubey wrote:
>
> > * it would be very useful - if not necessary - if you
> >   provided a one page summary on how to use ALLPROSE for
> >   the average A{ldor,xiom} programmer, separate from the
> >   complete 225 pages documentation.
>
> I thought there is enough overview material at the beginning
> of the ALLPROSE documentation, but seemingly one easily gets
> distracted by the vast amount of documentation of all the make
> files so that a short section "How to work with ALLPROSE" is
> certainly a good idea.

I have read quickly through the 225 pages of documentation of
ALLPROSE and I have to agree with Martin. A short concise summary
in 1 or 2 pages that gives the basic ideas, motivation and a few
**very simple** examples is necessary. The examples can be just
partial examples - only enough to get the basic idea across.

Although I am strongly in favor of this literate programming
methodology, if there is one criticism that I would make against
it is it easily leads to excessive verbosity and it does very
little to help with documentation organization. In many cases it
is often more difficult for the author of a complex program
(or any scientific work for that matter) to write 2 really good
pages about the work than it is to write 200 pages. As a result
the documentation can get so verbose that it becomes inaccessible
even though it is complete. I think this is already this is
happening in the Axiom documentation.

Perhaps too much documentation is a much better situation than
none at all, but for the first time user/developer, the result
is often the same.

> However, I am not quite sure what you would like to see in such a
> section. What do you think is missing from Section 6 "How to Start
> a New Project"?

I find it is rather difficult to say precisely what is missing
because I think that really is not the problem. The issue is more
the way the information is presented. The best analogy that I can
think of is something like this: suppose that you have been invited
to create a one page advertisement for the ALLPROSE product that
will be placed in a technical journal such as the mythical "IEEE
Advanced Computer Algebra Systems". What do you want to say to the
experienced readers who are not likely to take more than 10 minutes
at most to review your advertisement?

I think this is the sort of thing that should appear at the
beginning of an literate programming documentation - a sort of
technical executive summary.

>
> > * maybe you can connect yourself with Eitan Gurari to
> >   enable automatic translation to html/mathml via tex4ht?
>
> Thank you, I would really be happy if somebody could assist
> me with that translation.

What problems are you having using tex4ht? Have you tried any of
the other packages for converting LaTeX to HTML?

>
> > * I really want that your documentation format becomes a
> >   replacement for Axioms Hypertex format.
>
> Well, I would be happy if ALLPROSE goes this way.

I presume that what is most appealing to Martin about the ALLPROSE
approach is the automatic "lifting" of the +++ comments from the
source code to the documentation and vice-versa. The availability
of this documentation coupled with the ability to navigate the
algebra hierarchy of parents, ancestors, children, descendants
(including those domains that might be their own grandfathers :)
and packages is very important for both users and developers.

I like the way you have used hyperref to embed a lot of this
information directly into the documentation. I think some of
this could be quite easily grafted onto the pamphlet files that
Tim uses now for the Axiom source code, although right now
none of the sections of these pamphlet files is automatically
generated.

Or can you imagine this going the other way: Can ALLPROSE as it
exists now really play the same role as pamphlet files in Axiom?
I worry that too much is "hard coded" into the way that the
ALLPROSE makefiles are structured to be easily adaptable to Axiom.
Is that right?

>
>  >  However, there is one bit missing: it is necessary that we
> >   have an environment that contains Axiom/Aldor commands
> >   which are then sent to the Axiom/Aldor interpreter and the
> >   result gets then set in verbatim. Would this be a lot of work?
>
> Well, the aldordoc.sty is basically an agreement between
> Christian Aistleitner and me in order to introduce some kind of
> standard for the +++ comments that are possible in Aldor. As you
> see, the +++ environments are translated into +++ comments and
> put into the .as files. So the Aldor compiler actually sees them
> and puts them into the corresponding .ao file. Unfortunately
> there is not yet a program which extracts these comments form the
> .ao file (or the .al library). This would be on my wish list.

This functionality of using the +++ comments is built-in to
Axiom's database (daase) and used by the HyperDoc browser, the
standalone 'asq' utility and accessed by commands such as )show
)what and )display in the interpreter. I haven't checked yet
whether this holds true for the +++ comments embedded in Aldor
extension for Axiom library programming, but if it is not, then
perhaps Peter Broadbery could help to make sure that this bridge
exists.

\start
Date: Wed, 16 Nov 2005 14:18:16 -0500
From: Tim Daly
To: Bill Page
Subject: re: [Aldor-l] Ann: ALLPROSE / Suggestions

i like the executive summary idea in pamphlet files.

while i feel that complete documentation is important the real
goal of pamphlet files is to write programs for the user rather
than the machine. embedding source code leads to a daunting pile
of documentation. stylistically an "executive summary"/introduction
chapter should probably be required.

\start
Date: Wed, 16 Nov 2005 12:48:51 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] 

>random() has meaning only if I specify a distribution.

True (but that's a bit arrogant? :-). So the flaw is not in
'random()', but in the documentation because the distribution is not
given. I never said that the 'random()' for streams in my example is
distributed uniformly. I am just saying that 'random()' makes sense,
indeed, better sense, for infinite sets and should not be removed.

>I am not proposing to remove 'random()' for finite sets.

Good. Are you proposing to remove it from infinite sets? or just
'IntegerNumberSystem' and 'QuotientFieldCategory domains'? If you are
only objecting to the documentation, then I don't agree with removing
a function because of documentation error.


>By the way: I don't see how knowing the size of a set helps with
 creating a random element. I believe one needs some way of
 enumerating the elements?

An enumeration of a finite set means (at least implicitly) a bijection
from '1..n' (where 'n' is the size) to the set, and then a call to
'random(n)' can be used to index into an element of the set. The
enumeration alone is not enough to generate a random element. On the
other hand, I believe the size is necessary: even if one starts with a
seed element of the set, any algorithm to generate the next random
element (not just next element) from the current one most likely will
need to know the size of the set to ensure a uniform distribution. I
guess if someone is really clever, it is possible to have such an
algorithm independent of the size and prove that every element has the
same probability of being chosen. I don't have an example.


>Finally: Which CAS defines a function random for floats? 

That depends on what is meant.  Floats are not the same as reals and a
random float is not the same as a random real.  Yes, random for
floating point is usually done for the interval (0, 1) and then it can
be scaled for any interval. So I don't see what we are disagreeing
about. As you pointed out, Mathematica has Random[]. I am surprised
that Maple does not. But it is easy to scale rand(), which "returns a
random 12 digit non-negative integer" (I believe Maple meant less than
or equal to 12 digit) to float.

>By the way: random without an argument is not a lisp function!

Sure, 'random(n)' is a Lisp function for positive integer 'n', and in
boot, 'random()' is defined in terms of it, precisely to abstract it
for use with sets that are not related to the integers. But I suppose
you don't agree that 'random()' is a better calling convention for
abstract data sets.

>Apart from the usage in D01AGNT - where 'random()\$Integer' is used
 to generate a seed, did you find any other places where
 'random()\$Integer' is used?

Sure, if you just look at the list I attached above last time. 

\begin{verbatim}
pfbr~1.spa:      randomR() == random()
pfbr~1.spa:   else randomR() == (random()$Integer)::R
pfo~1.spa:                                      setelt(redmap, k, random()$Z)::F
plot~1.spa:--        jitter := (random()$I) :: F
primel~1.spa:    randomInts(n, m)       == [symmetricRemainder(random()$Integer,
 m) for i in 1..n]
primel~1.spa:        c := symmetricRemainder(random()$Integer, i)
\end{verbatim}

But this is besides the point. Indeed, all such use can be replaced by
'random(2^26)\$Lisp'. I think you are missing the idea behind the
deliberate creation of 'random()' to enable the concept of random
elements of an abstract data set and free this conceptually from the
underlying intermediate languages (like Lisp) and machine hardware, as
well as any implementation of 'random(n)' for a random integer in the
interval $[0,n]$.

>Furthermore, I think that lines like 'random()\$Z rem 11' are a bad
 idea, since the resulting distribution will be nearly uniform, but
 not quite... Do you know why such code was written?

You are getting really picky here! The error (for nearly uniformity)
when the size is small (like 11, as compared to $2^{26}$) is so small
that I don't think it is significant. All numerical computation with
floating points (and probabilities are certainly done in floating
point in most scientific applications), approximation is used and
here, the error in uniformity is no bigger than floating point error
(this is itself only an approximate statement, I have not done the
mathematical analysis!). Moreover, any statistical applications based
on random samples are subject to sampling errors which are
significantly (no pun intended) larger than rounding errors.

I think the code is a matter of convenience, the same way 'random()'
for floats is done (usually by scaling the integer interval $(0,
2^{26})$ to '(0, 1)'). It can be easily fixed: just use something like
'random(11*(2^26 exquo 11))\$INT rem 11' instead. If you are picky on
modulo 11, you should be just as picky for random floats in the
interval '(0,1)'. Well, I guess you are.

Unless you are thinking of applications in exact simulations for
theoretical probability and statistics, I don't see any reasons to fix
these minor problems. We all know pseudo-random number generators have
their deficiencies but until some equally efficient but more
mathematically precise methods are available, we have to live with
it. Even when that day comes, all we need to do is to replace the Lisp
version. (Along that thought, if the lisp version of 'random()' uses a
larger upper bound than $2^{26}$, will you be satisfied? Perhaps the
number $2^{26}$ should be parametrized as a system constant and the
documentation should mention this.)

\start
Date: Wed, 16 Nov 2005 14:43:55 -0500
From: Bill Page
To: Tim Daly Jr.
Subject: RE: Doyen

On Wednesday, November 16, 2005 6:55 AM Tim Daly Jr. wrote:
> ...
>
> Axiom has been ported by writing compatibility layers that emulate
> the Lisp it was being ported from.  At least for the code I
> looked at, it's no more a Common Lisp program than it is a CLTL1
> (a previous semi-standard) program.  It's more like a Maclisp/VMLisp
> program that predates any semblance of modern style. It also looks
> like a number of unfortunately bright hackers cut their teeth on it.
> Take this with a grain of salt, however, because I only spent a few
> weeks working with the code, and haven't read all of it.
>

But aside from the fact that the resulting "style" might be quite
ugly, is there anything besides the use of packages that prevents
Axiom from being built using a Common Lisp compliant Lisp? I don't
mean is it "good" Common Lisp, just whether it will compile or not.

> ...
> In general, I don't think it's a hot idea to use a web browser
> as an interface for software meant to run locally.  It's like
> telephoning somebody in the next room.

I don't know about that. For example I email people who sit right
next to me in the office all the time and sometimes even leave
voice mails. I think it depends on one's goals. For Doyen I think
some of these goals might be:

Goal number 1: GUI portability between Linux and Windows

Goal number 2: Common look and feel of user interface

Goal number 3: Easily extended to a networked environment

All of these things suggest to me a browser-based interface.

>
> > But perhaps I completely mis-understood. What is a 'web repl'?
>
> REPL is a term that is defined in the first chapter or two of
> basically every introductory work written about Lisp.  If you
> don't know what it is, it would be a good thing to look up.
> A web repl is a repl on a web page.

But why does anyone want a read-eval-print-loop via the web? Is
the idea to do Lisp development through the web? I doubt that
such interactive tools make much sense in this environment - at
least it seems to me that a lot (almost all) web development
takes place without such a facility. For example Zope supports
through-the-web application development including Python scripts
but it does not provide anything like an interactive REPL although
of course Python REPL does exist in console mode.

>
> > With the proper tools, I think a web application (even in
> > lisp) should probably be somewhere between 100 to 1000 lines
> > of code so I don't know how much opportunity that would give
> > me to learn much more about lisp. :)
>
> This is like saying that every rope is 10 feet long, and that
> wouldn't be enough to learn about tying knots.  It's just so
> wrong.
>

I am sure anyone can tie knots in programs of less than 100 lines
of code. ;) But my point is that usually we are not doing much
programming in these systems. We are actually mostly learning how
to use large and complex packages written by other people. It seems
that a lot of people who really like programming do not much like
doing this. Sometimes the difficulty and reluctance to learn how
to use other people's work is so high that programmes spend a lot
of time just re-inventing things their own way rather than investing
the time necessary to learn how to integrate and re-use.

I guess that learning how to program well in lisp is quite a
different thing than learning code re-use in general. In fact
Peter Norvig has argued that Lisp is not particularly well suited
to hetrogenuous projects that involve several different kinds of
tools and programmers with varying levels of experience - in other
words most open source projects. Maybe this is changing gradually.

> > Zope works. It has some very high level applications available
> > off-the-shelf and it required about 100 lines of python code
> > to integrate with Axiom - so why not use it?
>
> Hey, why should anybody care what you use?  Pick your poison.
> If you do the heavy lifting on a project, you have to use
> something that you want to play with.

Really, I don't want to play with any of this. I want to use
computer algebra for theoretical physics. I would prefer if
heavy lifting was done in a collaborative manner, shared among
several people. But instead, the suggestion is that I should
start by studying a textbook on lisp ...

>
> Usually, the more talk about a project, the less is actually
> happening with it.
>

The reason to care what poison we choose and the reason to spend
a lot of time discussing it is the hope that in the longer term
this will eventually lead to co-operative development instead of
a series of one-person shows.

\start
Date: Wed, 16 Nov 2005 21:56:28 +0100
From: Jens Axel Segaard
To: list
Subject: Re: Doyen

Page, Bill wrote:

> I guess that learning how to program well in lisp is quite a
> different thing than learning code re-use in general. In fact
> Peter Norvig has argued that Lisp is not particularly well suited
> to hetrogenuous projects that involve several different kinds of
> tools and programmers with varying levels of experience - in other
> words most open source projects. Maybe this is changing gradually.

Can you remember where Norvig argued that?

\start
Date: Wed, 16 Nov 2005 17:39:57 -0500
From: Bill Page
To: Jens Axel Segaard
Subject: Re: Doyen

On Wednesday, November 16, 2005 3:56 PM Jens Axel S=F8gaard asked:
>
> Page, Bill wrote:
>
> > I guess that learning how to program well in lisp is quite a
> > different thing than learning code re-use in general. In fact
> > Peter Norvig has argued that Lisp is not particularly well
> > suited to heterogeneous projects that involve several different
> > kinds of tools and programmers with varying levels of experience -
> > in other words most open source projects. Maybe this is changing
> > gradually.
>
> Can you remember where Norvig argued that?
>

I will have to accept that perhaps my biases colored somewhat my
memory of what Peter Norvig actually wrote. (Translation: I guess
I sort of put my foot in it again, eh? :) Of course in 1993 there
wasn't such a clear idea of open source as there is now so there
is no direct reference to open source.

Here is my best effort to find the exact quote I had in mind.

See:

Tutorial on Good Lisp Programming Style

Peter Norvig
Sun Microsystems Labs Inc.

Lisp Users and Vendors Conference
August 10, 1993.

http://www.norvig.com/luv-slides.ps
http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf

pages 20, 21

To wit:

-------

1.2 How do I know if it's good?

Choose the Right Language

Choose the appropriate language, and use appropriate
features in the language you choose. Lisp is not the
right language for every problem.

"You got to dance with the one that brung you."
      - Bear Bryant

Lisp is good for:

- Exploratory programming
- Rapid prototyping
- Minimizing time-to-market
- Single-programmer (or single-digit team) projects
- Source-to-source or data-to-data transformation
  Compilers and other translators
  Problem-specific languages
- Dynamic dispatch and creation
  (compiler available at run-time)
- Tight integration of modules in one image
  (as opposed to Unix's character pipe model)
- High degree of interaction (read-eval-print, CLIM)
- User-extensible applications (gnu emacs)

"I believe good software is written by small teams of
two, three, or four people interacting with each other
at a very high, dense level."  - John Warnock

                                   ------- 20 -------

-------

1.2.  How do I know if it's good?

Choose the Right Language

"Once you are an experienced Lisp programmer, it's
hard to return to any other language." - Robert R. Kessler

Current Lisp implementations are not so good for:

- Persistent storage (data base)
- Maximizing resource use on small machines
- Projects with hundreds of programmers
- Close communication with foreign code
- Delivering small-image applications
- Real-time control (but Gensym did it)
- Projects with inexperienced Lisp programmers
- Some kinds of numerical or character computation
  (Works fine with careful declarations, but the Lisp
  efficiency model is hard to learn.)

                               -------- 21 --------

Besides these statements, this set of slides presents
a lot of other opinions about Lisp and programming in
general with which I agree.

\start
Date: Thu, 17 Nov 2005 02:37:45 +0100
From: Tim Daly Jr.
To: Bill Page
Subject: RE: Doyen


> Really, I don't want to play with any of this. 

It shows.

> I want to use
> computer algebra for theoretical physics. I would prefer if
> heavy lifting was done in a collaborative manner, shared among
> several people. But instead, the suggestion is that I should
> start by studying a textbook on lisp ...

Look, if you're not willing to learn, if you're not willing to read a
beautiful book and learn something about one of the most amazing
creations of human intelligence, in fact the very language that the
project you're trying to work with is written in, then you may as well
give up now.

When someone recommends a good book to you, you say "thank you".

> The reason to care what poison we choose and the reason to spend
> a lot of time discussing it is the hope that in the longer term
> this will eventually lead to co-operative development instead of
> a series of one-person shows.

So you're going to generate hot air until somebody else does the work.
Fine.  I hope that works out for you.

The way to start a project is to release your code with an email that
says "hey, I hacked this up and it basically works, please give it a
shot and let me know what you think".  If people like it, they send you
patches.

\start
Date: Wed, 16 Nov 2005 23:24:33 -0500
From: Tim Daly
To: Bill Page
Subject: axiom common lisp
Cc: Tim Daly Jr

Bill,

in "ANSI Common Lisp" by Paul Graham (ISBN0-13-370875-6) on pp304-309
Graham lists the changes from common lisp to ansi common lisp. axiom
has example code that either violates the new standard (eg in-package)
or duplicates the new standard (destructuring binds) with our own twists.
Axiom is stylistically diverse with maclisp, lispvm, spice lisp, and a
variety of other coding styles and naming conventions. for instance,
global variables in the interpreter start with $ rather than the
convention of *var*, it rarely uses setf but uses set (deprecated),
it declares string to be (vector string-char) which is no longer 
supported, it uses (function 'symbol) which is no longer correct, etc.

so there is much work to do during the rewrite. i'm testing all of
the new code in gcl, clisp, cmucl, and sbcl so it will be ansi
compliant when i'm done.

\start
Date: Thu, 17 Nov 2005 10:20:49 +0100
From: Juergen Weiss
To: Tim Daly, Bill Page
Subject: RE: axiom common lisp
Cc: Tim Daly Jr

Actually the changes are minor, if you forget about
changes in style. There is the changed package syntax.
And there is the quoted function stuff and some minor
changes (a few macros and one or two places in the algebra
code) for string-char, both of which I already have taken care
of in my cmucl port 2 years ago.

Should not take more than 1/2 a day.

> -----Original Message-----
> From: axiom-developer-bounces+weiss=uni-mainz.de@nongnu.org
>  On Behalf Of root
> Sent: Thursday, November 17, 2005 5:25 AM
> To: Bill Page
> Cc: list; Tim Daly Jr
> Subject: axiom common lisp
>
> Bill,
>
> in "ANSI Common Lisp" by Paul Graham (ISBN0-13-370875-6) on pp304-309
> Graham lists the changes from common lisp to ansi common lisp. axiom
> has example code that either violates the new standard (eg in-package)
> or duplicates the new standard (destructuring binds) with our
> own twists.
> Axiom is stylistically diverse with maclisp, lispvm, spice lisp, and a
> variety of other coding styles and naming conventions. for instance,
> global variables in the interpreter start with $ rather than the
> convention of *var*, it rarely uses setf but uses set (deprecated),
> it declares string to be (vector string-char) which is no longer
> supported, it uses (function 'symbol) which is no longer correct, etc.
>
> so there is much work to do during the rewrite. i'm testing all of
> the new code in gcl, clisp, cmucl, and sbcl so it will be ansi
> compliant when i'm done.
>
> t

\start
Date: Thu, 17 Nov 2005 11:56:52 +0100
From: Tim Daly Jr.
To: Juergen Weiss
Subject: RE: axiom common lisp
Cc: list

On Thu, 2005-11-17 at 10:20 +0100, Weiss, Juergen wrote:
> Actually the changes are minor, if you forget about
> changes in style. There is the changed package syntax. 
> And there is the quoted function stuff and some minor
> changes (a few macros and one or two places in the algebra
> code) for string-char, both of which I already have taken care
> of in my cmucl port 2 years ago.
> 
> Should not take more than 1/2 a day.
> 

Hahaha! :)  You did a CMUCL port 2 years ago?  In 1/2 a day?  Nice. :)

How did you test it?  

What was your approach to loading the code?  I was making an ASDF
system.  I wish I'd known, if you already had one.

And, if it's been done, howcome people are still talking about getting
it done?

--
-Tim

\start
Date: Thu, 17 Nov 2005 13:29:25 +0100
From: Juergen Weiss
To: Tim Daly Jr.
Subject: RE: axiom common lisp

> -----Original Message-----
>
> On Thu, 2005-11-17 at 10:20 +0100, Weiss, Juergen wrote:
> > Actually the changes are minor, if you forget about
> > changes in style. There is the changed package syntax.
> > And there is the quoted function stuff and some minor
> > changes (a few macros and one or two places in the algebra
> > code) for string-char, both of which I already have taken care
> > of in my cmucl port 2 years ago.
> >
> > Should not take more than 1/2 a day.
> >
>
> Hahaha! :)  You did a CMUCL port 2 years ago?  In 1/2 a day?  Nice. :)

Did not say that. With the changes I made and the link to the
sources I posted 2 years ago, it should not take longer than
1/2 a day to incorportate the changes necessary for more
common lisp compliance into the current sources.

The cmucl port did not include communications to external programs
(which need the foreign function interface for 2 files written in C).
This could easily be rewritten to the cmucl foreign function interface
or recoded in cmucl, which offers access to all unix system calls and
sockets in particular. I was not so interested in Hyperdoc and the
graphics and left that part alone.

> How did you test it? 

I ran all the algebra test files (graphics excluded).

> What was your approach to loading the code?  I was making an ASDF
> system.  I wish I'd known, if you already had one.

I used the standard makefile approach

> And, if it's been done, howcome people are still talking about getting
> it done?

Because most people do not listen ;-). Last time I posted the url
http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz was on Nov 6. 2005

\start
Date: Wed, 16 Nov 2005 22:09:16 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: allprose
Cc: list

> typo in Makefile s/programms/programs/
> typo in Makefile s/environemnt/environment/

Thank you for that.

> \xALLPROSE{} expands to nothing
> \xAldor{} expands to nothing
> \xPerl{} expands to nothing
> \xNoweb{} expands to nothing

I don't understand. These commands are defined properly in
allprose.sty.nw. Just go to the index and click on the page number. That 
brings you directly to their definitions.

May I ask in which situations you realised this empty expansion.

> the axiom version of notangle fixes the problem of << in source code
> so it no longer fails. this is one of the patches that Norman Ramsey
> would not accept because I modified the C sources. It appears that
> you have a different solution. Please contact Norman to see if he'll
> incorporate your patch. If so, we can remove the patch from axiom.
> maybe we can even fix it to use the standard distribution.

Oh, I didn't know that your patch was about unbalanced << appearing in a 
pamphlet file. The problem is actually in the markup program so I have 
to filter the .nw file before it is handed over to markup. I've done 
this via perl.

> i still don't have it running but i continue to work on it.

I am happy about someone trying it out. It seems that I still have to 
work on the installation process. It is much too complicated.
I seriously consider to provide a second archive with all (most of) the 
additional software put into a nice directory structure together with a 
kind of installation script. But don't expect this anytime soon.
I first would need to hear about experiences of some volunteers who tell 
me where the installation process is not too simple.

> as you can see, i'm reading the .nw files

That's what they are made for. Tim, it was actually you who brought me 
into the business of trying out this literate programming style. I 
think, by now I quite like it. Now when I write some piece of code I 
always write some documentation with it explaining the general idea. And 
(very important) I immediately put some references (back and forth) to 
other code that has some relation to the code I am just writing. The 
latter really helps a lot if I look at my code at any later point and 
want/must modify it.

I do not yet consider ALLPROSE to be documented in a truely literate 
programming style. One still cannot read the documentation linearly in 
order to understand ALLPROSE. But I wanted to release it in order to get 
some feedback.

I hope there will be some more people trying it out.

\start
Date: Wed, 16 Nov 2005 22:11:27 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: allprose missing file

root wrote:
> i downloaded rhxterm.sty, put it in misc and ran texhash.
> now it cannot find 'typeoutframed.sty' and neither can google.

I don't use that file. It's just framed.sty.

\start
Date: Thu, 17 Nov 2005 13:46:35 +0100
From: Tim Daly Jr.
To: Juergen Weiss
Subject: RE: axiom common lisp

On Thu, 2005-11-17 at 13:29 +0100, Weiss, Juergen wrote:
...
> > Hahaha! :)  You did a CMUCL port 2 years ago?  In 1/2 a day?  Nice. :)
> 
> Did not say that. With the changes I made and the link to the
> sources I posted 2 years ago, it should not take longer than
> 1/2 a day to incorportate the changes necessary for more 
> common lisp compliance into the current sources.

Right, my mistake.

> I used the standard makefile approach

Rats.

> > And, if it's been done, howcome people are still talking about getting
> > it done?
> 
> Because most people do not listen ;-). Last time I posted the url
> http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz was on Nov 6. 2005
> 

Hehe :)

Thanks for reposting the link, I'll take a look at it.

\start
Date: Thu, 17 Nov 2005 06:16:37 -0800 (PST)
From: Cliff Yapp
To: Tim Daly Jr., Juergen Weiss
Subject: RE: axiom common lisp

I think the point should be made that Tim (the "root" Tim) is taking a
more measured approach - rather than just making the code work on ANSI
lisp implementations, he is going in and addressing/eliminating the
multitude of bizarre layers that have accumulated over the decades.  (I
think - feel free to correct me Tim :-).

This may not "get us to ANSI Lisp" as fast as making the smaller
changes would, but the result will be far more understandable, far
easier to work with, and far less fragile than the current state of
affairs.  From this standpoint, making the changes to get to ANSI lisp
now would just result in duplicate effort in the long run, and would be
of questionable benefit since it makes far more sense to test Axiom on
multiple lisp implementations after it has been rewritten in a cleaner
fashion.  Problems brought to light in the current codebase stand a
fair chance of being eliminated by the lisp cleanup/rewrite.

That said, if the change really is a fairly simple one and there is
sufficient interest to get it in place I would vote for it being put in
place in order to allow us to transition over to GCL's ANSI
environment.  This would be more for GCL's benefit than ours -
certainly an ANSI Axiom, even (or perhaps especially) with ANSI being
simply the support layer for layers of emulation, would be an excellent
stress test of GCL!

Tim, if patches were made available that would allow Axiom to
transition to ANSI GCL would there be any chance they could be merged
in with the latest release branch?  Or do we want to avoid dealing with
the problems that will surely crop up moving between Lisp
implementations until the proper rewrite is done?  

\start
Date: Thu, 17 Nov 2005 09:45:37 -0500
From: Bill Page
To: Tim Daly Jr.
Subject: RE: Doyen

On November 16, 2005 8:38 PM Tim Daly Jr. wrote:
> ... 
> > Really, I don't want to play with any of this. 
> 
> It shows.
>

Thank you.
 
> > I want to use computer algebra for theoretical physics.
> > I would prefer if heavy lifting was done in a collaborative
> > manner, shared among several people. But instead, the
> > suggestion is that I should start by studying a textbook on
> > lisp ...
> 
> Look, if you're not willing to learn, if you're not willing
> to read a beautiful book and learn something about one of the
> most amazing creations of human intelligence, in fact the very
> language that the project you're trying to work with is written
> in, then you may as well give up now.

Well, I have a feeling that I probably first studied lisp a few
years before you were born and it seems that I still learn about
one new programming language per year so your assumption that I
am unwilling to learn is not warranted. Lisp is neat but I think
you would have to have a pretty limited experience to class it
as "one of the most amazing creations of human intelligence"
especially in the context of a project like Axiom whose goal it
is to make all of mathematics available by computer.

I am well aware that Axiom is written in lisp and that's perfectly
fine with me.

> 
> When someone recommends a good book to you, you say "thank you".
>

I am sure it's a good book, but there have been dozens of good
books written about lisp.
 
> > The reason to care what poison we choose and the reason to
> > spend a lot of time discussing it is the hope that in the
> > longer term this will eventually lead to co-operative
> > development instead of a series of one-person shows.
> 
> So you're going to generate hot air until somebody else does
> the work. Fine.  I hope that works out for you.

No, I am generating hot air while I continue to do the things
that I think matter to help make this project a collaborative
effort. I hope that it works for all of us.

> 
> The way to start a project is to release your code with an
> email that says "hey, I hacked this up and it basically works,
> please give it a shot and let me know what you think".  If
> people like it, they send you patches.
> 

As I said, I don't think working on Axiom should be this sort
of one-person show.

\start
Date: Thu, 17 Nov 2005 11:47:43 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: axiom common lisp
Cc: Tim Daly Jr

> Tim, if patches were made available that would allow Axiom to
> transition to ANSI GCL would there be any chance they could be merged
> in with the latest release branch?  Or do we want to avoid dealing with
> the problems that will surely crop up moving between Lisp
> implementations until the proper rewrite is done?  

the process:

  mod the code
  doc the mods in the pamphlets
  supply appropriate test case(s)
  diff -Naur the files with the latest --patch level
  post the patches.

\start
Date: Thu, 17 Nov 2005 17:04:32 +0100
From: Juergen Weiss
To: Tim Daly
Subject: RE: axiom common lisp
Cc: Tim Daly Jr

Have done it 2 years ago. I won't do it again.

> -----Original Message-----
> From: root [mailto:Tim Daly]
> Sent: Thursday, November 17, 2005 5:48 PM
> To: Cliff Yapp
> Cc: Tim Daly Jr; Weiss, Juergen; list
> Subject: Re: axiom common lisp
>
> > Tim, if patches were made available that would allow Axiom to
> > transition to ANSI GCL would there be any chance they could
> be merged
> > in with the latest release branch?  Or do we want to avoid
> dealing with
> > the problems that will surely crop up moving between Lisp
> > implementations until the proper rewrite is done? 
>
> the process:
>
>   mod the code
>   doc the mods in the pamphlets
>   supply appropriate test case(s)
>   diff -Naur the files with the latest --patch level
>   post the patches.

\start
Date: Thu, 17 Nov 2005 12:18:41 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: axiom common lisp
Cc: Tim Daly Jr

> Tim, if patches were made available that would allow Axiom to
> transition to ANSI GCL would there be any chance they could be merged
> in with the latest release branch?  Or do we want to avoid dealing with
> the problems that will surely crop up moving between Lisp
> implementations until the proper rewrite is done?  

there is a public arch archive for the sbcl port (see
http://arch.axiom-developer.org). 

i know i'm back to the "bad tim" role but lets look at the issue of a 
"cheap and quick" port to ansi.

does the port work in sbcl/clisp/other ansi?

does the hyperdoc/graphics interface work?

there are subtle points to check. for instance, the BOOT compiler
spits out (functionp symbol) which i believe needs to become
(fboundp symbol). a (functionp symbol) won't fail but it used
to return T and now returns NIL thus taking a different code
branch.

is sbcl/clisp/other ansi building included in the makefiles?

how do you handle system startup since *restart-hook* doesn't
seem to be ansi?

how do you handle shell variables (e.g. (|getEnv| "AXIOM")?

the best case is to start patching the axiom--sbcl--1 branch
and do A/B testing against the current axiom. that way many
people can download and test the sbcl code without stomping
on their main branch. 

\start
Date: Thu, 17 Nov 2005 12:43:49 -0500
From: Tim Daly
To: Juergen Weiss
Subject: Re: axiom common lisp
Cc: Tim Daly Jr

> Have done it 2 years ago. I won't do it again.
> 
> Juergen Weiss

sigh. ok. it appears you feel slighted because your ansi patches
didn't get added to the system 2 years ago.

three years ago gcl was chosen (over ccl) because (a) i knew it worked
on akcl (gcl's parent code) and (b) i helped write akcl so i knew the
internals. (c) there were not many ansi common lisps and, in fact, i
didn't understand the distinction between cltl2 and ansi.

two years ago the interpreter was not yet fully functional on gcl. in
fact, it was in the process of being converted to pamphlet files with
a makefile hierarchy. supporting 2 different lisps in the makefiles
was more work than i could do and a complete rewrite to ansi lisp (on
an ansi lisp i didn't understand) was too much work for me to do. the
point was to get ALL of axiom running. email discussions on the lisp
pointed out that gcl would eventually be ansi. uffi didn't exist and
i didn't understand the way to hook the C socket code into your work.

axiom became fully functional (interp/algebra/hyperdoc/ graphics) as
of feb 2005. at which point i could begin to focus on other issues.

rewriting the code from the current boot language to ansi common lisp
is in process and i'm testing the rewrite on every available ansi
common lisp platform during the rewrite. so ansi common lisp is 
coming. not quickly but in well-tested increments.

i know i ignored your ansi patches but they happened at a time when
they would have been vastly disruptive to getting the system running
again. 

i apologize that they were ignored.

\start
Date: Thu, 17 Nov 2005 18:07:53 +0100
From: Juergen Weiss
To: Tim Daly
Subject: RE: axiom common lisp
Cc: Tim Daly Jr

Sorry that I was so harsh. Your answer was mainly to C Y,
to me only as a CC, but I kind of took it as directed to
me. Email communication is tricky ;-)

> -----Original Message-----
> From: root [mailto:Tim Daly]
> Sent: Thursday, November 17, 2005 6:44 PM
> To: Weiss, Juergen
> Cc: Tim Daly; Cliff Yapp;
> Tim Daly Jr; list
> Subject: Re: axiom common lisp
>
> > Have done it 2 years ago. I won't do it again.
> >
> > Juergen Weiss
>
> sigh. ok. it appears you feel slighted because your ansi patches
> didn't get added to the system 2 years ago.
>
> three years ago gcl was chosen (over ccl) because (a) i knew it worked
> on akcl (gcl's parent code) and (b) i helped write akcl so i knew the
> internals. (c) there were not many ansi common lisps and, in fact, i
> didn't understand the distinction between cltl2 and ansi.
>
> two years ago the interpreter was not yet fully functional on gcl. in
> fact, it was in the process of being converted to pamphlet files with
> a makefile hierarchy. supporting 2 different lisps in the makefiles
> was more work than i could do and a complete rewrite to ansi lisp (on
> an ansi lisp i didn't understand) was too much work for me to do. the
> point was to get ALL of axiom running. email discussions on the lisp
> pointed out that gcl would eventually be ansi. uffi didn't exist and
> i didn't understand the way to hook the C socket code into your work.
>
> axiom became fully functional (interp/algebra/hyperdoc/ graphics) as
> of feb 2005. at which point i could begin to focus on other issues.
>
> rewriting the code from the current boot language to ansi common lisp
> is in process and i'm testing the rewrite on every available ansi
> common lisp platform during the rewrite. so ansi common lisp is
> coming. not quickly but in well-tested increments.
>
> i know i ignored your ansi patches but they happened at a time when
> they would have been vastly disruptive to getting the system running
> again.
>
> i apologize that they were ignored.

\start
Date: Thu, 17 Nov 2005 10:30:52 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: axiom common lisp
Cc: Tim Daly Jr

--- Tim Daly wrote:

> the process:
> 
>   mod the code
>   doc the mods in the pamphlets
>   supply appropriate test case(s)
>   diff -Naur the files with the latest --patch level
>   post the patches.

OK.  I myself am quite content to wait for the robust rewrite but I
thought maybe Camm would be interested in an ANSI stress test ;-) 

One question I do have that I hadn't thought to mention until I saw you
mention test cases - are you planning to use XLUnit
(http://www.cliki.net/xlunit) or a similar tool to provide an actual
Unit test framework?

\start
Date: Thu, 17 Nov 2005 14:30:12 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: axiom common lisp
Cc: Tim Daly Jr

nope. the test cases are embedded in the pamphlet file and get
run during the build. i have a wrapper function to compare
input and output.

\start
Date: Thu, 17 Nov 2005 13:55:36 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: axiom common lisp

On November 17, 2005 9:17 AM C Y wrote:
> 
> I think the point should be made that Tim (the "root" Tim) is
> taking a more measured approach - rather than just making the
> code work on ANSI lisp implementations, he is going in and
> addressing/eliminating the multitude of bizarre layers that
> have accumulated over the decades.  (I think - feel free to
> correct me Tim :-).

Looking at the Axiom lisp code it is obvious that it contains
multiple layers and multiple styles, but I think it is not
correct to class this as "bizarre". Allowing such a mix of
layers and styles is one of the things that lisp is good at.
It only looks complex because it is not well documented (or
not documented at all).

> 
> This may not "get us to ANSI Lisp" as fast as making the smaller
> changes would, but the result will be far more understandable,
> far easier to work with, and far less fragile than the current
> state of affairs.

I don't think that there is any proof of that. I don't think
that the Axiom code is "fragile". It is just difficult to
maintain because the documentation is so poor (mostly absent).

> From this standpoint, making the changes to get to ANSI lisp
> now would just result in duplicate effort in the long run, 
> and would be of questionable benefit since it makes far more
> sense to test Axiom on multiple lisp implementations after it
> has been rewritten in a cleaner fashion.

"Clearer fashion" is another issue of style and style is
subjective. I have no doubt that the current approach will
make it easy for Tim to maintain - since he is the one actually
do the re-writing - but except of the new documentation I
do not see a net gain.

> Problems brought to light in the current codebase stand a
> fair chance of being eliminated by the lisp cleanup/rewrite.
> 

I also doubt this. Because Axiom currently works and has been
in fact a commercial product for a number of years, I expect
that most (if not all) the problems in the basic Axiom code are
of a systemic nature - design oversights or unresolved issues.
The kind of thing that one sees while converting subroutines
a few at a time are not of this kind. And re-writing is just as
apt to introduce new problems as it is to correct old ones.

Overall I am still very strongly against this approach -
especially when you mix all this up with the misguided idea
of removing major parts of Axiom's current architecture like
boot. Add this to the fact that there is only one person doing
all this and I think the net result is to set Axiom back a few
years when we should be concentrating instead on mathematical
functionality that could potentially attract new users now.

> That said, if the change really is a fairly simple one and
> there is sufficient interest to get it in place I would vote
> for it being put in place in order to allow us to transition
> over to GCL's ANSI environment.  This would be more for GCL's
> benefit than ours - certainly an ANSI Axiom, even (or perhaps
> especially) with ANSI being simply the support layer for
> layers of emulation, would be an excellent stress test of
> GCL!

The use of the word "emulation" is not very accurate. As I
pointed out above, programming in layers is a commonly used
lisp programming style.

> 
> Tim, if patches were made available that would allow Axiom to
> transition to ANSI GCL would there be any chance they could
> be merged in with the latest release branch?  Or do we want
> to avoid dealing with the problems that will surely crop up
> moving between Lisp implementations until the proper rewrite
> is done?  
> 

I don't see why Tim doesn't stop grinding old axes like boot
vs. lisp and just merge in Jergen Weiss' changes now. The
sooner we get to a point where Axiom can be built under a
common lisp compliant system the better. Once we are there,
we can worry about cleaning things up (whatever that might
mean to those doing the work) in a gradual and incremental
manner.

\start
Date: Thu, 17 Nov 2005 12:05:48 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: axiom common lisp

--- Bill Page wrote:

> On November 17, 2005 9:17 AM C Y wrote:
> > 
> > I think the point should be made that Tim (the "root" Tim) is
> > taking a more measured approach - rather than just making the
> > code work on ANSI lisp implementations, he is going in and
> > addressing/eliminating the multitude of bizarre layers that
> > have accumulated over the decades.  (I think - feel free to
> > correct me Tim :-).
> 
> Looking at the Axiom lisp code it is obvious that it contains
> multiple layers and multiple styles, but I think it is not
> correct to class this as "bizarre". Allowing such a mix of
> layers and styles is one of the things that lisp is good at.
> It only looks complex because it is not well documented (or
> not documented at all).

To a point that may be true, but making old code run by implementing
layers that mimic the behavior of older lisps is not something I would
argue is a good thing.  It makes the code much harder to understand,
because to work with any given part of the code you have to first
understand what version of lisp that part of the code was written for
(and consequently what behavioral assumptions were made) and then try
and work with it.  For younger coders especially, that can be a high
hurdle - they have no knowledge of obsolete standards.  I can see
layers being used to more closely match ideas (e.g. SPAD vs. Lisp) but
defining layers to match old code behavior rather than making that code
work with a now long established, agreed upon standard (Common Lisp) is
one of the better ways to guarantee no one will ever want to touch the
old code later on. 
 
> > This may not "get us to ANSI Lisp" as fast as making the 
> > smaller changes would, but the result will be far more 
> > understandable,far easier to work with, and far less fragile
> > than the current state of affairs.
> 
> I don't think that there is any proof of that. I don't think
> that the Axiom code is "fragile". It is just difficult to
> maintain because the documentation is so poor (mostly absent).

Well, maybe it isn't "fragile" - say rather there are too many layers
of complexity that do not directly benefit the goals of Axiom.  Or,
from experience with Maxima, too much complexity in the code makes it
impossible to say with certainty that any particular change will impact
only what it is intended to impact.  Maintaining compatibility with
older styles of coding doesn't help anything in the long run. All it
does is avoid the task of revisiting older code and redoing it to match
modern standards.  It could be argued that such standards are
themselves a moving target but I think at this point the ANSI spec is
pretty well established.

> "Clearer fashion" is another issue of style and style is
> subjective. I have no doubt that the current approach will
> make it easy for Tim to maintain - since he is the one actually
> do the re-writing - but except of the new documentation I
> do not see a net gain.

Well, let's wait for the results before we decide that.  It's early
days yet.  But by "clearer fashion" I ment "without having to cope with
code written to outdated standards and not easily understood (or worse,
easy to misunderstand) by common lisp programmers."

> > Problems brought to light in the current codebase stand a
> > fair chance of being eliminated by the lisp cleanup/rewrite.
> 
> I also doubt this. Because Axiom currently works and has been
> in fact a commercial product for a number of years, I expect
> that most (if not all) the problems in the basic Axiom code are
> of a systemic nature - design oversights or unresolved issues.
> The kind of thing that one sees while converting subroutines
> a few at a time are not of this kind. And re-writing is just as
> apt to introduce new problems as it is to correct old ones.

If we get a result of break even on bugs removed vs. bugs introduced,
and get code which is more readable and understandable in the eyes of
common lisp programmers, I think that's a definite net gain.  But
again, I'll wait for the results to speak for themselves.
 
> Overall I am still very strongly against this approach -
> especially when you mix all this up with the misguided idea
> of removing major parts of Axiom's current architecture like
> boot. Add this to the fact that there is only one person doing
> all this and I think the net result is to set Axiom back a few
> years when we should be concentrating instead on mathematical
> functionality that could potentially attract new users now.

Well, there's nothing to stop the rest of us from working on the
mathematical functionality - that will survive and be useful
regardless.  It would seem to me that the question of the availability
of Aldor would have a more direct bearing on that issue, and I haven't
heard any update on its status for quite a while.

I haven't let the architectural discussions worry me too much, although
granted I'm still slugging it out with Buckingham at the moment so SPAD
code isn't yet an issue ;-).  

> > That said, if the change really is a fairly simple one and
> > there is sufficient interest to get it in place I would vote
> > for it being put in place in order to allow us to transition
> > over to GCL's ANSI environment.  This would be more for GCL's
> > benefit than ours - certainly an ANSI Axiom, even (or perhaps
> > especially) with ANSI being simply the support layer for
> > layers of emulation, would be an excellent stress test of
> > GCL!
> 
> The use of the word "emulation" is not very accurate. As I
> pointed out above, programming in layers is a commonly used
> lisp programming style.

Right, but I only like that idea when the new language/layer is
designed in for some major, non-trivial advantage, not to support older
code - older code should be modernized to reduce the burden on future
coders.  I think the mark of the proper use of a language within a
language is it makes it easier for a programmer with training only in
the "core" language to understand ALL the code - "embedded" language
and known language alike.  

Just MHO, of course - I'm certainly no expert in such matters.

\start
Date: Thu, 17 Nov 2005 15:48:24 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: axiom common lisp

On November 17, 2005 3:06 PM C Y wrote:
> 
> --- Bill Page wrote:
> 
> > 
> > Looking at the Axiom lisp code it is obvious that it contains
> > multiple layers and multiple styles, but I think it is not
> > correct to class this as "bizarre". Allowing such a mix of
> > layers and styles is one of the things that lisp is good at.
> > It only looks complex because it is not well documented (or
> > not documented at all).
> 
> To a point that may be true, but making old code run by
> implementing layers that mimic the behavior of older lisps
> is not something I would argue is a good thing.

But Axiom has had just such a compatibility layer for a long
time and it has served Axiom well, otherwise we wouldn't be
using Axiom today.

> It makes the code much harder to understand, because to work
> with any given part of the code you have to first understand
> what version of lisp that part of the code was written for
> (and consequently what behavioral assumptions were made) and
> then try and work with it.

I think you may be arguing based on a rather unclear idea of
just how flexible a language lisp is - any version of lisp
and especially ANSI common lisp, which for the most part is a
superset of other lisps, rather than a refinement. (Notice
that I said: for the most part.) To understand any lisp code
(pick almost anything off the web) and you will find that to
understand how something works you first have to understand
the author's design.

> For younger coders especially, that can be a high hurdle -
> they have no knowledge of obsolete standards.

I think that is wrong. Do you really think that learning to
program in Fortran is made seriously more difficult because
the year 2000 Fortran standard is radically different than
the year 1964 Fortran standard? Standards are important for
very different reasons, but learning to program is not one
of them.

> I can see layers being used to more closely match ideas
> (e.g. SPAD vs. Lisp) but defining layers to match old code
> behavior rather than making that code work with a now long
> established, agreed upon standard (Common Lisp) is one of
> the better ways to guarantee no one will ever want to touch
> the old code later on.

As I said, Axiom already has a sort of lisp-variant compatibility
layer implemented as a set of macros that is built-in to it's
design. Understand this layer is not particularly difficult.

> 
> Well, maybe it isn't "fragile" - say rather there are too many
> layers of complexity that do not directly benefit the goals of
> Axiom.  Or, from experience with Maxima, too much complexity
> in the code makes it impossible to say with certainty that any
> particular change will impact only what it is intended to impact.

I think you have it backwards. Layers, when done properly, do not
increase the complexity of the code, they decrease it. I haven't
looked much as Maxima, but I suspect that some of the "complexity"
that you talk about in Maxima is due the use of a design that
does not take advantage of this design idea.

It has been claimed here that the Maxima source is now fully
compliant with the Common Lisp standard. Is there any information
available from the Maxima developers about what changes were
necessary to attain this goal?

\start
Date: Thu, 17 Nov 2005 13:06:19 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: axiom common lisp

--- Bill Page wrote:

> On November 17, 2005 3:06 PM C Y wrote:
> >
> > To a point that may be true, but making old code run by
> > implementing layers that mimic the behavior of older lisps
> > is not something I would argue is a good thing.
> 
> But Axiom has had just such a compatibility layer for a long
> time and it has served Axiom well, otherwise we wouldn't be
> using Axiom today.

Right, but Axiom is now open source - the clarity and transparency of
the code now becomes much more important than for a commercial project.
 Being just functional is insufficient for open source (IMHO anyway)
but in a commercial program the source code is never seen, so as long
as it is functional it is no problem.

> > It makes the code much harder to understand, because to work
> > with any given part of the code you have to first understand
> > what version of lisp that part of the code was written for
> > (and consequently what behavioral assumptions were made) and
> > then try and work with it.
> 
> I think you may be arguing based on a rather unclear idea of
> just how flexible a language lisp is - any version of lisp
> and especially ANSI common lisp, which for the most part is a
> superset of other lisps, rather than a refinement. (Notice
> that I said: for the most part.) To understand any lisp code
> (pick almost anything off the web) and you will find that to
> understand how something works you first have to understand
> the author's design.

True.  I make no claim to being an expert lisp programmer, and for this
reason I may be overestimating the issues involved.  However, I know I
would be very wary of behavioral inconsistencies between changes in the
standards and how they would impact the coding requirements.

> > For younger coders especially, that can be a high hurdle -
> > they have no knowledge of obsolete standards.
> 
> I think that is wrong. Do you really think that learning to
> program in Fortran is made seriously more difficult because
> the year 2000 Fortran standard is radically different than
> the year 1964 Fortran standard? Standards are important for
> very different reasons, but learning to program is not one
> of them.

I know if I had learned to program in 2000 Fortran I would be very wary
of assumptions and behaviors learned when editing 1964 Fortran, and
possibly subtle bugs I could introduce by using the wrong assumptions
when working on the code.  But I might be overestimating the problems -
I have no experience to base a judgement on.

> I think you have it backwards. Layers, when done properly, do
> not increase the complexity of the code, they decrease it. I 
> haven't looked much as Maxima, but I suspect that some of 
> the "complexity" that you talk about in Maxima is due the use 
> of a design that does not take advantage of this design idea.

Probably true.  Certainly, it was not modular enough - almost
everything is jammed into one huge lisp package, for example.  I am
unsure of whether introducing language variations would have
contributed anything.

> It has been claimed here that the Maxima source is now fully
> compliant with the Common Lisp standard. Is there any 
> information available from the Maxima developers about what 
> changes were necessary to attain this goal?

I think this was a very gradual process.  The cvs history might offer
some insight, but I myself don't know too much about the issues
involved.

I should pose this question of defining languages within lisp on
comp.lang.lisp and see what the real gurus think.  Or maybe it has been
asked already - I'll see what I can find.

\start
Date: Thu, 17 Nov 2005 17:11:53 -0500
From: Tim Daly
To: Bill Page
Subject: Re: axiom common lisp

what are the semantics of these operations?

evalandfileactq
rdefiostream
rplq
*lam
mdef
comp370
remove-fluids
dcqexp

unless you happen to have the documentation for vmlisp handy
it's unlikely you'll be able to decide or even guess. future
generations won't even have vmlisp available. i spoke to Fred
Blair (the vmlisp author) and he doesn't even have a copy of
the sources.

rdefiostream creates filenames which follow VM/CMS conventions
8char.8char.1char (filename, filetype, filemode (disk name))
do we want to carry this convention into the future?

the other operations are equally obscure. there are more where
they came from. their semantics pervade the sources and unless
you understand their semantics you'll never guess why filenames
have such wierd restrictions.

so i can document and educate the users on the wierd file i/o
semantic differences or simply write it out of the code and
adopt proper ansi common lisp conventions.

only my questionable expertise in vmlisp allows me to maintain
this code. i want it to go away so others can maintain/modify
and expand it.

\start
Date: Thu, 17 Nov 2005 22:00:25 -0500
From: Bill Page
To: Tim Daly
Subject: RE: axiom common lisp

On November 17, 2005 5:12 PM Tim Daly wrote:

> 
> what are the semantics of these operations?
> 
> evalandfileactq
> rdefiostream
> rplq
> *lam
> mdef
> comp370
> remove-fluids
> dcqexp
> 
> unless you happen to have the documentation for vmlisp handy
> it's unlikely you'll be able to decide or even guess. future
> generations won't even have vmlisp available. i spoke to Fred
> Blair (the vmlisp author) and he doesn't even have a copy of
> the sources.

That is irrelevant. We have up to date definitions of the exact
semantics of all of these in Axiom right now. For example, I go
to

http://wiki.axiom-developer.org/axiom--test--1/src/interp

I enter 'evalandfileactq' in the search box and hit Enter. I see
where it is used and that it is defined in 'vmlisp.lisp' I click
on

http://wiki.axiom-developer.org/axiom--test--1/src/interp/VmlispLisp

and choose 'pdf'. In about 15 seconds I know that

(defmacro evalandfileactq (name &optional (form name))
'(eval-when (eval load) ,form))

If someone had bothered to write one or two sentences in English
about the usage, I might be happier, but as long as I know that it
works in GCL and how to read lisp, then this is enough to define
the semantics isn't it? I don't care that much about the history.

> 
> rdefiostream creates filenames which follow VM/CMS conventions
> 8char.8char.1char (filename, filetype, filemode (disk name))
> do we want to carry this convention into the future?
> 

It's not hard to find the defun for redefiostream in nlib.lisp.
Of course without some documentation it is a little hard to
decode the logic of this 30 line function but as far as I can
tell it no longer imposes the 8 character name limit.


> the other operations are equally obscure. there are more where
> they came from. their semantics pervade the sources and unless
> you understand their semantics you'll never guess why filenames
> have such weird restrictions.

Looking at some of the others it seems to me that the only
reason these seem obscure is because of lack of documentation.

> 
> so i can document and educate the users on the weird file i/o
> semantic differences or simply write it out of the code and
> adopt proper ansi common lisp conventions.
>

I would definitely opt for the first option first. We can adopt
proper ansi common lisp conventions later.
 
> only my questionable expertise in vmlisp allows me to maintain
> this code. i want it to go away so others can maintain/modify
> and expand it.
> 

Really, Tim I don't think it is as hard as you make it out to
be. The main thing that seems to be preventing other people
from helping to maintain, modify and expand it is their lack
of time and interest. I really doubt that your rewriting all
of this according to modern conventions will make much
difference to the availability of people willing to work on
the internals of Axiom.

\start
Date: Fri, 18 Nov 2005 07:13:51 -0500
From: Tim Daly
To: Bill Page
Subject: Re: axiom common lisp

ummmkay... i admit i'm wrong.

(bad tim puts down his keyboard weapon,
 abandons his entrenchment,
 and exits the language war)

now, can we move back to discussing math?

\start
Date: Fri, 18 Nov 2005 05:47:01 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: Re: axiom common lisp

--- Tim Daly wrote:

> ummmkay... i admit i'm wrong.
> 
> (bad tim puts down his keyboard weapon,
>  abandons his entrenchment,
>  and exits the language war)
> 
> now, can we move back to discussing math?

Sounds good to me - back to the math.

\start
Date: Fri, 18 Nov 2005 05:46:50 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: Re: axiom common lisp

--- Tim Daly wrote:

> ummmkay... i admit i'm wrong.
> 
> (bad tim puts down his keyboard weapon,
>  abandons his entrenchment,
>  and exits the language war)
> 
> now, can we move back to discussing math?

\start
Date: Fri, 18 Nov 2005 09:19:58 -0500
From: Bill Page
To: Tim Daly
Subject: RE: axiom common lisp

On November 18, 2005 8:47 AM C Y wrote:
> 
> --- Tim Daly wrote:
> > ...
> > now, can we move back to discussing math?
> 
> Sounds good to me - back to the math.
> 

Yes I agree, back to the math! :-)

Is anyone interested in discussing the implementation of exact
computable reals in Axiom? 

http://page.axiom-developer.org/zope/mathaction/RealNumbers

http://www.rbjones.com/rbjpub/cs/cs006.htm

http://keithbriggs.info/xrc.html

There has been quite a lot of work on this but as far as I know
it has not yet made it's way into any commercial computer algebra
systems like Maple, Mathematica, or MuPad. On the other hand
these ideas fit very well with Axiom's approach and would provide
Axiom with an immediate advantage over these other systems.

\start
Date: Fri, 18 Nov 2005 13:42:10 -0600
From: MathAction (anonymous)
To: MathAction
Subject: [#236 Clicking on 'Dependents' in HyperDoc Browse crashes HyperDoc] (new) 

When I click on the 'Dependents' link in the HyperDoc Browse interface, it always crashes, printing:

 >> System error:
   Caught fatal error [memory may be damaged]

... in the terminal.  What is the matter?  Is it difficult to fix that?

 1. Start axiom
 2. Click the 'Browse' link
 3. Type 'Matrix' in the box, and then 'domains'.
 4. Click 'Dependents', and it crashes HyperDoc.

This is Axiom axiom--main--1 fresh as of 2005/11/18, that I just built last night.  I had to 'chmod +x mnt/linux/{bin/{htsearch,presea},lib/presea}', and had to edit the 'presea' scripts to change the path to 'awk' since it resides in /usr/bin on FHS compliant Linux.

\start
Date: Fri, 18 Nov 2005 20:22:07 +0000
From: Peter Broadbery
To: Bill Page
Subject: re: [Aldor-l] Ann: ALLPROSE / Suggestions

On Wed, 2005-11-16 at 12:27 -0500, Page, Bill wrote:
> On Wednesday, November 16, 2005 7:53 AM Ralf Hemmecke wrote:
> > 
> > Martin Rubey wrote:
> > 
> > > * it would be very useful - if not necessary - if you 
> > >   provided a one page summary on how to use ALLPROSE for
> > >   the average A{ldor,xiom} programmer, separate from the
> > >   complete 225 pages documentation.
> >  on my wish list.

[Allprose snipped - not had time to look at it]

> This functionality of using the +++ comments is built-in to
> Axiom's database (daase) and used by the HyperDoc browser, the
> standalone 'asq' utility and accessed by commands such as )show
> )what and )display in the interpreter. I haven't checked yet
> whether this holds true for the +++ comments embedded in Aldor
> extension for Axiom library programming, but if it is not, then
> perhaps Peter Broadbery could help to make sure that this bridge
> exists.
> 


In theory it ought to. The .asy symbol file loaded by the interpreter
contains the +++ documentation strings, and these are read by the )lib
command, and passed into the runtime type database.  However, I'm not
sure quite how they get into the hyperdoc world.

What should work is that if you can get axiom to display the
documentation for a newly compiled .spad domain, then you should be able
to see the docs for an aldor domain.  However, I can't recall how to do
the 1st part, so if someone can show me how to do that, I may take a
look.  (apologies, but I'm a bit streched for time at the moment).

Ideally, +++ comments should be spilled out by something into a lovely
HTMLised piece of documentation, but this would require aldor sources
and some amount of work.

\start
Date: Fri, 18 Nov 2005 15:02:58 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Free Code Graphing Project

Was thinking about visualizing Axiom's source code, and remembered
this:

http://fcgp.sourceforge.net

I'm not quite sure how useful it is, but perhaps it can be adapted to
work with Axiom (at the very least, it would make a really cool image
for a book cover :-)

Just wanted to mention it on the list, so I can find it again later -
this one is a bit hard to remember since it never gained much of a name
as fcgp.

\start
Date: Sat, 19 Nov 2005 01:00:07 -0500
From: Tim Daly
To: list
Subject: infinite loop from Makefile

I'm testing axiom under a variety of common lisps.
The Makefile I use does the following:

  @-echo (load "bookvol5.lisp") | clisp

If I get an error, e.g.

** - Continuable Error
FUNCALL: undefined function foo
If you continue (by typing 'continue): Retry
The following restarts are also available:
STORE-VALUE   :R1
USE-VALUE     :R2

clisp continues in an infinite loop forcing me to kill the shell
and I lose all of the output.

so I tried:

  @-echo (progn (load "bookvol5.lisp") (common-lisp-user::quit)) | clisp

with the same result.

How can I invoke clisp from a Makefile without entering an infinite loop?

\start
Date: Sat, 19 Nov 2005 08:04:42 +0100
From: Hans Peter Wuermli
To: list
Subject: B#

In "How to Make AXIOM Into a Scratchpad" Jenks and Trager describe "... a new 
user interface language ..." for Axiom, which they called B# ("B natural") in 
the article. If it ever had been implemented, it would offer a lot of the 
language elements at least I would have hoped for in the interpreter 
interface for Axiom.

Does anybody know what ever happened to that project?

\start
Date: Sat, 19 Nov 2005 13:11:58 +0100
From: Juergen Weiss
To: Tim Daly
Subject: RE: infinite loop from Makefile

The following Makefile works for me (under FreeBSD)

test:
        @- echo '(progn (print 5) (quit))' | clisp


> -----Original Message-----
> From: axiom-developer-bounces+weiss=uni-mainz.de@nongnu.org
>  On Behalf Of root
> Sent: Saturday, November 19, 2005 7:00 AM
> To: clisp-list@lists.sourceforge.net
> Cc: list
> Subject: infinite loop from Makefile
>
> I'm testing axiom under a variety of common lisps.
> The Makefile I use does the following:
>
>   @-echo (load "bookvol5.lisp") | clisp
>
> If I get an error, e.g.
>
> ** - Continuable Error
> FUNCALL: undefined function foo
> If you continue (by typing 'continue): Retry
> The following restarts are also available:
> STORE-VALUE   :R1
> USE-VALUE     :R2
>
> clisp continues in an infinite loop forcing me to kill the shell
> and I lose all of the output.
>
> so I tried:
>
>   @-echo (progn (load "bookvol5.lisp")
> (common-lisp-user::quit)) | clisp
>
> with the same result.
>
> How can I invoke clisp from a Makefile without entering an
> infinite loop?
>

\start
Date: Sat, 19 Nov 2005 02:10:03 -0600
From: Stephen Compall
To: Tim Daly
Subject: Re: [clisp-list] infinite loop from Makefile

On Sat, 2005-11-19 at 01:00 -0500, root wrote:
> I'm testing axiom under a variety of common lisps.
> The Makefile I use does the following:
>
>   @-echo (load "bookvol5.lisp") | clisp

clisp takes Lisp or fasl files on the command-line.  You can say "clisp
bookvol5.lisp".  For arbitrary forms, you can say "clisp -q -x '(progn
(run) (this) (form))'.

\start
Date: Sat, 19 Nov 2005 10:33:31 -0500
From: Tim Daly
To: list
Subject: axiom conference funding?

One thing we've done in the past, while Axiom was at IBM, would be
to apply to the National Science Foundation (NSF) for conference
funding. We would ask for a grant amount to cover local costs and
some limited travel for students and speakers.

Perhaps we could draft a grant proposal (with the grant money 
managed by the Axiom foundation) and send it off to Chris DiBona
at Google (the sponsor of the Summer of Code).

Thoughts?

\start
Date: Sat, 19 Nov 2005 07:53:18 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: axiom conference funding?

--- Tim Daly wrote:

> One thing we've done in the past, while Axiom was at IBM, 
> would be to apply to the National Science Foundation (NSF) 
> for conference funding. We would ask for a grant amount to 
> cover local costs and some limited travel for students and
> speakers.
> 
> Perhaps we could draft a grant proposal (with the grant money 
> managed by the Axiom foundation) and send it off to Chris 
> DiBona at Google (the sponsor of the Summer of Code).
> 
> Thoughts?

I like it.  I suppose the NSF itself is now out of the question as a
possible additional funding source?

Premature question:  Where would it be held?

\start
Date: Sat, 19 Nov 2005 11:54:06 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: axiom conference funding?

> Premature question:  Where would it be held?

Kansas. So we could decide if the changes to Axiom are the result
of intelligent design or evolution :-)

\start
Date: Sat, 19 Nov 2005 08:27:43 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: axiom conference funding?

--- Tim Daly wrote:

> > Premature question:  Where would it be held?
> 
> Kansas. So we could decide if the changes to Axiom are the result
> of intelligent design or evolution :-)

Hehehe :-).  I wonder if they would punt the lot of us out of the state
for refusing to acknowledge that Pi is exactly 3.

\start
Date: Sat, 19 Nov 2005 11:32:27 -0500
From: Bill Page
To: Tim Daly
Subject: RE: axiom conference funding?

On November 19, 2005 11:54 AM Tim Daly (root) wrote:
> 
> > Premature question:  Where would it be held?
> 
> Kansas. So we could decide if the changes to Axiom are the
> result of intelligent design or evolution :-)
> 

Oh, you're baaadd, Bad Tim! I but like it. :-))

But clearly evolution is part of the design so it remains
unfalsifiable. ;)

\start
Date: Sat, 19 Nov 2005 12:24:40 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: axiom conference funding?

> Premature question:  Where would it be held?

a more reasonable answer is another question:
who would be willing to host it.

frankly i think it'd be a lot of fun to rent a beach house
somewhere and spend 3 days code hacking/designing/lang-wars-ing
on the front porch. morning presentations, afternoon debates,
evening code hacking. the scratchpad group used to do this in
the hamptons, i believe. nobody said a conf HAS to be in a
huge building with cinderblock walls.

\start
Date: Sat, 19 Nov 2005 10:48:06 -0600
From: Jay Belanger
To: list
Subject: Re: axiom conference funding?

Cliff Yapp writes:

> --- Tim Daly wrote:
>
>> > Premature question:  Where would it be held?
>>
>> Kansas. So we could decide if the changes to Axiom are the result
>> of intelligent design or evolution :-)
>
> Hehehe :-).  I wonder if they would punt the lot of us out of the state
> for refusing to acknowledge that Pi is exactly 3.

As an attempt to appeal to as many people as possible, perhaps Axiom
could include a boolean variable, KANSAS, which when true would do all
computations with pi equal to 3.

(Although to be fair, the pi=3 bill was in Indiana, and it died in
Senate.)

\start
Date: Sat, 19 Nov 2005 13:11:36 -0500
From: Bill Page
To: Tim Daly
Subject: RE: axiom conference funding?

On November 19, 2005 12:25 PM Tim Daly (root) wrote:
>
> C. Y wrote: 
> > Premature question:  Where would it be held?
> 
> a more reasonable answer is another question:
> who would be willing to host it.
> 
> frankly i think it'd be a lot of fun to rent a beach house
> somewhere and spend 3 days code hacking/designing/lang-wars-ing
> on the front porch. morning presentations, afternoon debates,
> evening code hacking. the scratchpad group used to do this in
> the hamptons, i believe. nobody said a conf HAS to be in a
> huge building with cinderblock walls.
> 

I don't think it is premature to ask the question of location
and format. We should also ask when? I was thinking in terms
of April or May - roughly one year from the last meeting that
was hosted by City College in New York City last year.

I like Tim's suggestion about the format and location however
I would be even more pleased if we could find a venue like
this in Europe. Open source Axiom is already supported by an
international group of developers and the Axiom web site
regularly records frequent access to the web site from more
than 80 countries around the world. I think we should try to
organize face-to-face meetings in several different parts of
the world. But of course we do need a host organization.

I also think that very soon we should advertise for written
contributions to the Axiom meeting and plan to publish these
papers in some manner - perhaps in co-operation with a
recognized journal. Real publications count for a lot of the
people who are potential contributors to Axiom.

Finally, I think we should establish an organizing committee.
I am certainly willing to be part of such a committee. Who
else would like to volunteer? Or perhaps you might wish it
nominate someone else?

\start
Date: Sat, 19 Nov 2005 22:05:19 -0500
From: Bill Page
To: Hans Peter Wuermli
Subject: RE: B#

On November 19, 2005 2:05 AM Hans Peter W=FCrmli wrote:
>
> In "How to Make AXIOM Into a Scratchpad" Jenks and Trager
> describe "... a new user interface language ..." for Axiom,
> which they called B# ("B natural") in the article. If it ever
> had been implemented, it would offer a lot of the language
> elements at least I would have hoped for in the interpreter
> interface for Axiom.
>
> Does anybody know what ever happened to that project?
>

http://portal.axiom-developer.org/refs/articles/axiom-scratchpad.pdf

The date on this paper, 1994, closely coincides with the time
when IBM decided to close Axiom as a research project and
negotiated with Numerical Algorithms Group to market Axiom as a
commercial product. It is easy to guess that B# might have been
a causality of this transition.

I agree with Peter that B# is probably what a lot of new users
of Axiom are expecting to find. I like most of the design ideas
for the B# language presented by Jenks and Trager in this paper
so I think implementing B# would be a great project to resurrect
for open source Axiom.

Also interesting in this article is mention of the project GAUSS
which was an attempt to provide an Axiom-like type system in Maple
GAUSS is contrasted with B# because Maple is essentially untyped
while B# was an attempt to provide an untyped user environment
within Axiom. As an active Maple developer at that time, I remember
briefly playing with GAUSS and not being particularly impressed.
My point of view has changed a lot since then. I am convinced of
the value of strong type system in Axiom but I find I often miss
the freedom of expression that the untyped environments of Maple,
Mathematical and Maxima provide. B# might very provide the kind
of bridge that Jenks and Trager envisaged in this paper.

Does anyone else have an interest in investigating the possible
implement of B# ?

\start
Date: Sun, 20 Nov 2005 01:05:27 -0500
From: Tim Daly
To: Bill Page
Subject: Re: B#
Cc: list

if you do 
 )lisp (trace pf2sex)
you can see the input translated to s-expressions which
are essentially a GREAT-like data structure. It should
be possible to write USER algebra domain that captures
this, parses it, and allows you to manipulate it as a
tree expression.

\start
Date: Sun, 20 Nov 2005 09:02:31 +0100
From: Hans Peter Wuermli
To: Tim Daly
Subject: Re: B#

On Sunday 20 November 2005 07.05, root wrote:
> if you do
>  )lisp (trace pf2sex)

pf2sex is currently missing in the Debian distribution, so I can't try.

> ... It should
> be possible to write USER algebra domain that captures
> this, parses it, and allows you to manipulate it as a
> tree expression.

Yes, this is probably possible, but probably difficult, too, if one does not 
know enough about Lisp and the way the interpreter works now (for which Lisp 
knowledge is probably necessary, isn't it). Parsing an S-expression looks 
like analysing something untyped (with Lisp or Axiom) that is untyped. As as 
colleague of mine once remarked "strong typing is for the weak of minds" I 
have to admit that I have a very weak mind. That's also how I would excuse my 
preference of Haskell over Lisp: strong versus no typing. I have noticed with 
several of your and Bill's answers that you quickly assume a user's dislike 
of typing, if unease with the interface is expressed (please forgive me if 
I'm wrong, I don't intend to criticise somebody who does such great work). 

At least in my case its different: I have a liking for syntactic sugar and a 
dislike of opacity. The way the current Axiom interface handles user input, 
is relatively opaque (but admittedly, I neither know all the tools, nor have 
I kept notes to build "documentation").

But to get back to your advice: where would you start, if you wanted to build 
such a USER algebra domain?
           	  
Let me give some examples of what I would consider nice syntactic sugar, and 
it must be syntactic sugar as the evaluation of any expression is ultimately 
extremely simple as explained at the end of section 5 of the "Axiom as 
Scratchpad" article.

1) TeX-like conventions: being able to define, say, variables as x_{i,j} looks 
very handy. One should actually go further and allow type annotations, like

x_{i:NNI,j:PI}:POLY INT,

or even further and allow "operators" as syntactic elements, like defining a 
few variables as (or the sum example in "Afterthoughts, ...")

for i in 0..5 repeat x_i:POLY INT

This actually seems to be nothing else than polymorphism of the function 
"for", if - as the manuals claim - types are first class citizens.

2) Afterthoughts: if "==" generally would point to a rewrite rule then 
exending eval to an eval ( expr, List 'Rewrite Rules' ) would semantically be 
the same as the "afterthoughts". It looks to me that this is the regular 
evaluation mechanism of any functional programming language. (Currently an 
expression like x==t has the type Void; I wonder what would happen if this 
construct came under programming control.)

3) Pattern-matching and functional paradigm: it's probably the type of pattern 
matching and currying from Haskell that I miss most. Actually, I don't have 
the feeling that it is entirely missing, not at all, but the ease of use of 
Haskell is certainly missing.

Thank you for the comments and have a nice Sunday

\start
Date: Sun, 20 Nov 2005 10:31:19 -0500
From: Tim Daly
To: Hans Peter Wuermli
Subject: Re: B#

The single hardest part of the Bnatural interpreter would be writing
the semantics of the evaluator. Because it mixes every possible type
of syntax-to-semantics mapping it is important that the syntax is
not ambiguous. 

We'd have to develop the grammer and semantics very, very carefully.

\start
Date: Sun, 20 Nov 2005 11:52:40 -0500
From: Bill Page
To: Hans Peter Wuermli
Subject: RE: B#

On November 20, 2005 3:03 AM Hans Peter W=FCrmli wrote:
>
> On Sunday 20 November 2005 07.05, root wrote:
> > if you do
> >  )lisp (trace pf2sex)
>
> pf2sex is currently missing in the Debian distribution,
> so I can't try.

I also can not find any reference to 'pf2sex' in my copy of
the Axiom sources. Is this really what you meant Tim?

>
> > ... It should be possible to write USER algebra domain
> > that captures this, parses it, and allows you to manipulate
> > it as a tree expression.
>
> Yes, this is probably possible, but probably difficult, too,
> if one does not know enough about Lisp and the way the
> interpreter works now (for which Lisp knowledge is probably
> necessary, isn't it). Parsing an S-expression looks like
> analysing something untyped (with Lisp or Axiom) that is
> untyped.

I do not think that s-expressions is what Jenks and Trager
had in mind when they talked about "GREAT". Although lisp
s-expressions are certainly one way to represent a tree
structure, there are better representations of expression
trees that would probably be more suitable for the purposes
of B#.

> As as colleague of mine once remarked "strong typing is for
> the weak of minds" I have to admit that I have a very weak
> mind. That's also how I would excuse my preference of Haskell
> over Lisp: strong versus no typing.

It is not accurate to suggest that Lisp has no typing - quite
the opposite. But Lisp uses strong *dynamic* typing where all
values have types and this type information is strongly enforced
but in general (recent extensions to Lisp not withstanding) the
Lisp variables do not have types.

Haskell, Spad and Aldor on the other hand have strong static
typing which applies directly to both variables and values; and
which can be determined at "compile-time" rather than "run-time"
as is the case with Lisp.

I wonder if your colleague who said: "strong typing is for the
weak of minds" really knows what "types" in computer programming
really are? But I agree with you. I also have a weak mind in that
sense and strongly prefer a language which is an aid to the way
I think about a problem. I think human programmers (and
mathematicians, too :) need all the help we can get from the
computer.

I do prefer Haskell over Lisp for many purposes but it is not
becase Lisp is not a typed language.

> I have noticed with several of your and Bill's answers that
> you quickly assume a user's dislike of typing, if unease with
> the interface is expressed (please forgive me if I'm wrong,
> I don't intend to criticise somebody who does such great work).

I thought that this was your point because of your reference
to the Jenks and Trager paper which is mostly devoted to the
issue of a typed versus and untyped user interface language for
Axiom.

>
> At least in my case its different: I have a liking for
> syntactic sugar and a dislike of opacity. The way the current
> Axiom interface handles user input, is relatively opaque (but
> admittedly, I neither know all the tools, nor have I kept
> notes to build "documentation").
>
> But to get back to your advice: where would you start, if you
> wanted to build such a USER algebra domain?

I think that a lot of work has already been done in Axiom to
support the concept of a USER algebra domain - specifically in
the Expression constructor. Expression implements many of the
ideas that Jenks and Trager assume for the type USER. The other
domain in the Axiom interpreter that implements some of these
ideas is ANY. I think of the type USER as sort of a cross
between these two.

>            	 
> Let me give some examples of what I would consider nice
> syntactic sugar, and it must be syntactic sugar as the
> evaluation of any expression is ultimately extremely simple
> as explained at the end of section 5 of the "Axiom as
> Scratchpad" article.
>
> 1) TeX-like conventions: being able to define, say, variables
> as x_{i,j} looks very handy. One should actually go further
> and allow type annotations, like
>
> x_{i:NNI,j:PI}:POLY INT,
>
> or even further

I think you are mixing sugar with semantics here. It does not
make sense to me to associate types with superscirpts and
subscripts if these are just symbols. But if they are not
symbols then we need to decide what the use of subscript
means, e.g. if x is a matrix then the subscripts might
denote a reference to an element of a matrix. It is not
clear to me what meaning might be associated with your
example.

> and allow "operators" as syntactic elements, like defining a
> few variables as (or the sum example in "Afterthoughts, ...")
>
> for i in 0..5 repeat x_i:POLY INT
>

As I understand it, this syntax actually denotes 6 names,
x_0 x_1 ... x_5 all of type POLY INT, is that right?


> This actually seems to be nothing else than polymorphism of
> the function "for", if - as the manuals claim - types are
> first class citizens.

Could you explain how you think of "for" as a function in this
example?

>
> 2) Afterthoughts: if "==" generally would point to a rewrite
> rule then exending eval to an eval ( expr, List 'Rewrite Rules' )
> would semantically be the same as the "afterthoughts". It looks
> to me that this is the regular evaluation mechanism of any
> functional programming language.

Could you please explain this a little more. I do not think
of == as involving any type of evaluation.

> (Currently an expression like x==t has the type Void; I wonder
> what would happen if this construct came under programming
> control.)

What type would you suggest?

>
> 3) Pattern-matching and functional paradigm: it's probably
> the type of pattern matching and currying from Haskell that
> I miss most.

Axiom supports currying of functions. You might recall some
discussion between myself and William Sit about this. But I
agree that Axiom does not provide quite the same kind of
syntactic sugar for currying as does Haskell. But Axiom is
not a purely functional language so I think it has more
constraints to satisfy in it's choice of syntax.

> Actually, I don't have the feeling that it is entirely
> missing, not at all, but the ease of use of Haskell is
> certainly missing.

I have to agree with you on both counts.

\start
Date: 20 Nov 2005 20:47:25 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: B#

Bill Page writes:

[...]

| I wonder if your colleague who said: "strong typing is for the
| weak of minds" really knows what "types" in computer programming
| really are?

well, if Pascal has a strong type system, then I can't see how I can
disagree :-/

\start
Date: Sun, 20 Nov 2005 15:32:48 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: B#

On November 20, 2005 2:47 PM Gabriel Dos Reis wrote:
> 
> Bill Page writes:
> [...]
> | I wonder if your colleague who said: "strong typing is for the
> | weak of minds" really knows what "types" in computer programming
> | really are?
> 
> well, if Pascal has a strong type system, then I can't see how I
> can disagree :-/
> 

Perhaps you said this only as humour? But I am curious since it is
not clear to me who you are not disagreeing with ... ?

Pascal was the first strongly typed language that I learned. I wrote
what I thought was a fairly substantial medical application in UCSD
Pascal on an Apple II microcomputer. I believe that the type system
really did contribute to more reliable software development. From a
historical perspective it is interesting to speculate why Pascal did
not survive. I think perhaps it was because in the end it's type
system was not quite flexible enough (compared say to Haskell). As a
result C, with almost not type system dominated (and still dominates)
most application development.

\start
Date: Sun, 20 Nov 2005 16:01:46 -0500
From: Doug Stewart
To: Bill Page
Subject: Re: B#

Bill Page wrote:

>On November 20, 2005 2:47 PM Gabriel Dos Reis wrote:
>  
>
>>Bill Page writes:
>>[...]
>>| I wonder if your colleague who said: "strong typing is for the
>>| weak of minds" really knows what "types" in computer programming
>>| really are?
>>
>>well, if Pascal has a strong type system, then I can't see how I
>>can disagree :-/
>>
>>    
>>
>
>Perhaps you said this only as humour? But I am curious since it is
>not clear to me who you are not disagreeing with ... ?
>
>Pascal was the first strongly typed language that I learned. I wrote
>what I thought was a fairly substantial medical application in UCSD
>Pascal on an Apple II microcomputer. I believe that the type system
>really did contribute to more reliable software development. From a
>historical perspective it is interesting to speculate why Pascal did
>not survive. I think perhaps it was because in the end it's type
>system was not quite flexible enough (compared say to Haskell). As a
>result C, with almost not type system dominated (and still dominates)
>most application development.
>
>Regards,
>Bill Page.
>  
>

I also started with pascal and now c# reminds me of Pascal. My students 
a spared many hrs. of trouble shooting because of strong Typing of C#. :-)

I am new to this list, and was wondering how Haskell can be used to 
write Axiom programs?
Isn't Axiom written in Lisp?
Doug Stewart

\start
Date: Sun, 20 Nov 2005 18:53:33 -0500
From: Tim Daly
To: William Sit
Subject: apple port

William,

I just bought an Apple iBook to port Axiom since it doesn't seem to
be making much progress. Besides the Apple 10.4 opsys what other
software do you think I need?

\start
Date: 21 Nov 2005 00:10:30 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: B#

Bill Page writes:

| On November 20, 2005 2:47 PM Gabriel Dos Reis wrote:
| > 
| > Bill Page writes:
| > [...]
| > | I wonder if your colleague who said: "strong typing is for the
| > | weak of minds" really knows what "types" in computer programming
| > | really are?
| > 
| > well, if Pascal has a strong type system, then I can't see how I
| > can disagree :-/
| > 
| 
| Perhaps you said this only as humour? But I am curious since it is
| not clear to me who you are not disagreeing with ... ?

Partly as humour, and partly seriously.  I don't think strong typing is
a goal in itself; I have had lot of experience with good type systems
helping me catching silly errors early in program development, and
alleged "strong type systems" getting in my way.

| Pascal was the first strongly typed language that I learned. I wrote

I started with BASIC and Pascal was my second programming language,
the more serious I programmed with (and I did not have much choice
given the French educational system at the time).

| what I thought was a fairly substantial medical application in UCSD
| Pascal on an Apple II microcomputer. I believe that the type system
| really did contribute to more reliable software development. From a
| historical perspective it is interesting to speculate why Pascal did
| not survive.

I'm not sure we have much to speculate about, given the facts.  I can
only speak for myself and I would refrain from generalization; but
Pascal's "strong type system" did not help me.  I got far more
positive experience later with (O)Caml and C++ (and even Scheme!).  I
don't believe it is a matter of dynamism vs. non-dynamism.  For me, it
is a matter of what I can express and how I can express it.  

| I think perhaps it was because in the end it's type
| system was not quite flexible enough (compared say to Haskell). As a
| result C, with almost not type system dominated (and still dominates)
| most application development.

C has a type system -- serious C programmers know how to use it.  Yes,
it does not get anal-retentive about it where it should.  And that is
a pity.  Notice that Pascal and C started almost at the same time...

\start
Date: 21 Nov 2005 00:11:55 +0100
From: Gabriel Dos Reis
To: Doug Stewart
Subject: Re: B#

Doug Stewart writes:

[...]

| Isn't Axiom written in Lisp?

sort-of -- and it depends on your definition f Lisp.  See the recent
long threads about BOOT vs. Lisp vs. The-Rest-of-The-World :-)

\start
Date: Mon, 21 Nov 2005 01:01:22 +0100
From: Pierre Doucy
To: Tim Daly
Subject: Re: apple port

Hi Tim,

the list hasn't heard very much from me lately, but it seems I might
be able to work on a mac os port again the next few months. More info
on that later.

For now, here are some very nice pieces of software for mac os x:

1) Mac OS X dev tools, which are normally shipped with the os
2) fink (http://fink.sf.net) ports a lot of Unix OSS to mac os X
3) A good editor : textmate (www.macromates.com) is *very* nice,
although not free ; SubEthaEdit is cool too (www.codingmonkeys.de) ;
and so is the carbonized version of emacs
(http://www.apple.com/downloads/macosx/unix_open_source/carbonemacspackage.html).
You can also use XCode, but I don't think it understands Lisp.
4) I would also recommend voodoopad
(http://flyingmeat.com/voodoopad/). It's very much like a wiki, but on
your desktop. It pretty much replaces my brain.

That would be a good start.

Have fun with your new Mac !

Pierre

On 11/21/05, Tim Daly wrote:
> William,
>
> I just bought an Apple iBook to port Axiom since it doesn't seem to
> be making much progress. Besides the Apple 10.4 opsys what other
> software do you think I need?

\start
Date: Sun, 20 Nov 2005 16:25:04 -0800
From: Ed Borasky
To: Gabriel Dos Reis
Subject: Re: B#

Gabriel Dos Reis wrote:

>C has a type system -- serious C programmers know how to use it.  Yes,
>it does not get anal-retentive about it where it should.  And that is
>a pity.  Notice that Pascal and C started almost at the same time...
>  
>
Both are descendents of Algol 60. Pascal resembles its ancestor much 
more closely than C does. But both are procedure-oriented languages. 
Neither Pascal nor C, nor their common ancestor Algol 60, are 
significantly different in my view from Fortran II. It's pretty much all 
syntactic sugar (or syntactic rat poison, if you prefer.)

If you're interested in a procedure-oriented language that delivers as 
much bullet-proofing and compile time bug prevention as is "humanly 
possible", have a look at Pascal's descendent, Ada. "Serious 
anal-retentive" procedure oriented programmers use Ada. :)

On the other hand, if you're looking to do symbolic math, is there any 
reason not to use Lisp? There must be some reason nearly every 
successful symbolic mathematics package was at least bootstrapped from 
some Lisp variant!

\start
Date: Sun, 20 Nov 2005 19:47:16 -0500
From: William Sit
To: Tim Daly
Subject: Re: apple port

Tim:

I am all thumbs as far as OSes go and I don't use my Mac that much
except for teaching and presentations. But Pierre Doucy's
recommendations are good ones.  Since Mac OS X is BSD based, at least
you can install whatever you want from the linux world (for example
tetex). You'll definitely need fink. You may also want not:
http://www.apple.com/macosx/features/x11/ (older Mac OS X used
XDarwin).

This page may help:
http://darkwing.uoregon.edu/~noeckel/TigerG4G5Setup.html

\start
Date: Mon, 21 Nov 2005 02:01:35 +0100
From: Pierre Doucy
To: list
Subject: Re: apple port

Yep, right, I completely forgot about LaTex, shame on me.

TexShop (http://www.uoregon.edu/~koch/texshop/) is THE editor for *Tex.
Gerben Wierda's i-Installer (obtainable from TexShop's homepage) is
just great to install tetex without too much harassment, although you
can also use fink.

On 11/21/05, William Sit wrote:
> Tim:
>
> I am all thumbs as far as OSes go and I don't use my Mac that much except for
> teaching and presentations. But Pierre Doucy's recommendations are good ones.
> Since Mac OS X is BSD based, at least you can install whatever you want from the
> linux world (for example tetex). You'll definitely need fink. You may also want
> X-11 for Mac OS X, which should be on your Tiger OS installation disc, and if
> not:
> http://www.apple.com/macosx/features/x11/
> (older Mac OS X used XDarwin).
>
> This page may help:
> http://darkwing.uoregon.edu/~noeckel/TigerG4G5Setup.html

\start
Date: Sun, 20 Nov 2005 21:03:16 -0500
From: Tim Daly
To: William Sit
Subject: Re: apple port

yeah, the MAC is a BSD variant so i'll also have a place to look at
the FreeBSD changes that Murray sent.


\start
Date: 21 Nov 2005 02:28:01 +0100
From: Gabriel Dos Reis
To: Ed Borasky
Subject: Re: B#

Ed Borasky writes:

[...]

| If you're interested in a procedure-oriented language that delivers as
| much bullet-proofing and compile time bug prevention as is "humanly
| possible", have a look at Pascal's descendent, Ada. "Serious
| anal-retentive" procedure oriented programmers use Ada. :)

Indeed.

| On the other hand, if you're looking to do symbolic math, is there any
| reason not to use Lisp?

Not a significant reason -- but Lisp's type system is not what I would
consider "strong" :-)

| There must be some reason nearly every
| successful symbolic mathematics package was at least bootstrapped from
| some Lisp variant!

But in 2005, would you want to start with BOOT? 
[Bill, Tim, that was a joke :-)]

\start
Date: Sun, 20 Nov 2005 20:58:30 -0500
From: Bill Page
To: Doug Stewart
Subject: RE: B#

On November 20, 2005 6:12 PM Gabriel Dos Reis wrote:

> 
> Doug Stewart writes:
> 
> | Isn't Axiom written in Lisp?
> 
> sort-of -- and it depends on your definition of Lisp.  See
> the recent long threads about BOOT vs. Lisp vs. The-Rest-
> of-The-World :-)
> 

>From my point of view, yes the main part of Axiom is written
in Lisp. The issue of Boot is about the architecture of Axiom
and how to use Lisp;  it's not about one language versus
another since Boot is written in Lisp (and Boot), uses Lisp
data structures and compiles to Lisp. The only reason it
exists is as an intermediate language to implement parts of
Axiom. There is a difference of opinion as to whether this is
a good design or not.

HyperDoc, Axiom graphics and sman - the glue that manages the
sessions and sockets, are all written in C.

\start
Date: Sun, 20 Nov 2005 22:15:59 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: B#

Two comments. Lisp IS strongly typed. It just associates the type with
the object and not with the box (variable) it comes in. That is, it
distinguishes a TV from the box labeled TV as the type is related to
the object and not the box. Other "strongly-typed" languages don't so
once you say a box (variable) is a TV box you can't put anything else
in it.  You can spot a Box-Typed language because it forces you to
coerce your entertainment center to a TV to put it into a TV
box. Exactly why you would want to consider the TV and the box it came
in to have any fixed relationship is beyond most lispers.  
(Bad Tim slaps his own wrist for joining in another language war)

Bill's interest in B-natural could easily be grounded in BOOT code.
Taking the BOOT language as a starting point and expanding the syntax
and semantics to include the other paradigms would get us a long way
toward a B-natural compiler. Some of the ideas in the Jenks/Trager
paper are already implemented with a compiler and running code.
Expanding the syntax and the compiler are probably easier tasks
than trying to start from scratch.

Presenting a USER type that can be programmed in an extended BOOT
language is reasonable. Indeed, the experiment could eventually
influence the syntax and semantics of the Spad compiler language.
The goal is to make it easier to express mathematics. The current
syntax used by non-computational mathematicians is horribly ambiguous.

\start
Date: Sun, 20 Nov 2005 21:46:05 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: B#

On November 20, 2005 8:28 PM Gaby wrote:

> 
> "Ed Borasky" writes:
> ... 
> | On the other hand, if you're looking to do symbolic math, 
> | is there any reason not to use Lisp?
> 
> Not a significant reason -- but Lisp's type system is not
> what I would consider "strong" :-)

We have mentioned before on this lisp the very good article

http://en.wikipedia.org/wiki/Datatype

about type systems in programming languages. "strong type
checking" has several different definitions but I think most
people would agree that Lisp is a strong dynamically typed
language by most of these definitions.

I can think of several reasons not to use Lisp to do symbolic
math but most of these do not have to do with the technical
details of the language itself, both rather what one might call
"cultural" issues. I think one should not ignore such broader
in the context of a project like this one that aims to maintain
software like Axiom over a 30 year time horizon.

> 
> | There must be some reason nearly every successful symbolic
> | mathematics package was at least bootstrapped from some Lisp
> | variant!

I wonder if that is true. Was Maple bootstrapped from Lisp?
Was Mathematica bootstrapped from Lisp? Was MuPad bootstrapped
from Lisp?

I know for sure that that answer for Maple is "no"? See
http://www.scg.uwaterloo.ca/SCG/history.html

I am quite sure that the answer for MuPad is also "no". But
I cannot find a specific reference.
http://www.gh.wits.ac.za/MuPAD/history.html

I also think the answer is no for Mathematica. See:
http://en.wikipedia.org/wiki/Talk:Mathematica

Of course it is true for Reduce, Maxima and Axiom but these
seem significantly less "successful" to me. :(

> 
> But in 2005, would you want to start with BOOT? 
> [Bill, Tim, that was a joke :-)]
> 

Gaby, you have a strange sense of humour!

\start
Date: Sun, 20 Nov 2005 22:17:21 -0500
From: Bill Page
To: Tim Daly
Subject: RE: B#

On November 20, 2005 10:16 PM Tim Daly (root) wrote:

> 
> Two comments. Lisp IS strongly typed. It just associates the type
> with the object and not with the box (variable) it comes in. That
> is, it distinguishes a TV from the box labelled TV as the type is
> related to the object and not the box. Other "strongly-typed"
> languages don't so once you say a box (variable) is a TV box you
> can't put anything else in it.  You can spot a Box-Typed language
> because it forces you to coerce your entertainment center to a TV
> to put it into a TV box. Exactly why you would want to consider
> the TV and the box it came in to have any fixed relationship is
> beyond most lispers.

I think this is a great analogy! :-) In technical jargon we
would translate "box-typed language" to statically typed.

Of course there is very good reason to want to have this fixed
relationship between a box and it's contents: You don't have to
look inside to know what's in there! Every shop keeper knows the
advantage of that and every consumer knows they should probably
open the box before they leave the story. ;)

> (Bad Tim slaps his own wrist for joining in another language war)

No, don't do that.  This is just another friendly Sunday afternoon
discussion... :)

> 
> Bill's interest in B-natural could easily be grounded in BOOT
> code. Taking the BOOT language as a starting point and expanding
> the syntax and semantics to include the other paradigms would get
> us a long way toward a B-natural compiler. Some of the ideas in
> the Jenks/Trager paper are already implemented with a compiler
> and running code. Expanding the syntax and the compiler are
> probably easier tasks than trying to start from scratch.

Yes, I see the similarity between Boot and B# since Boot is a
lot like Spad without the static type system. But I think the
point of B# is as a entry-level programming language for new
Axiom users. This would be an alternative to the programming
language that is normally accessed through Axiom *.input files
and is part of the Axiom interpreter. Currently the programming
language in the Axiom interpreter is closely related to the
Spad programming language that is accessed via the )compile
command. Although the interpreter makes attempts to relieve the
burden of assigning types to objects by a series of heuristics,
The language is still essentially strongly and statically typed.

The purpose of Boot of course is/was very different being focused
on the internal design of Axiom and never appearing at the user
level. I am not convinced that the best path to B# would be through
Boot.

> 
> Presenting a USER type that can be programmed in an extended
> BOOT language is reasonable. Indeed, the experiment could
> eventually influence the syntax and semantics of the Spad
> compiler language. The goal is to make it easier to express
> mathematics. The current syntax used by non-computational
> mathematicians is horribly ambiguous.
> 

I would not use the word "ambiguous" in reference to Spad,
since it does require complete specifications of types, but
I would agree that the syntax is not ideal for the non-
computational mathematicians. I think that most people do at
least initially view the strong type system as a hindrance.
It is only later as they become experienced computationally
oriented mathematicians that they may really appreciate the
purpose of the type system. However Spad as the Axiom library
compiler is specifically targeted for the experienced Axiom
user so this is as it should be.

As I understand it, the idea of B# was as an intermediate
language for Axiom that would appeal more to these initial
users of Axiom - not to be a replacement for Spad. In my
opinion, the evolution of Spad reached it's most desirable
state of development in Aldor. But I don't think that a similar
solution exists yet for the Axiom user interface.

\start
Date: Sun, 20 Nov 2005 23:40:50 -0500
From: Tim Daly
To: Bill Page
Subject: Re: B#

I suggested the BOOT language because some of the ideas are already
implemented there. Making it a standalone language would give us a
place to play with various syntactic and semantic changes. Starting
to build a compiler from scratch would be a lot of work.

\start
Date: 21 Nov 2005 05:30:58 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: B#

Bill Page writes:

| On November 20, 2005 10:16 PM Tim Daly (root) wrote:
| 
| > 
| > Two comments. Lisp IS strongly typed. It just associates the type
| > with the object and not with the box (variable) it comes in. That
| > is, it distinguishes a TV from the box labelled TV as the type is
| > related to the object and not the box. Other "strongly-typed"
| > languages don't so once you say a box (variable) is a TV box you
| > can't put anything else in it.  You can spot a Box-Typed language
| > because it forces you to coerce your entertainment center to a TV
| > to put it into a TV box. Exactly why you would want to consider
| > the TV and the box it came in to have any fixed relationship is
| > beyond most lispers.
| 
| I think this is a great analogy! :-) In technical jargon we
| would translate "box-typed language" to statically typed.

It it a good analogy; but it is just that: An analogy.
Many statically typed languages do make the distinction between the
box and what-is-in-the-box: They call the former a "Variable" and the
later an "object", so they don't confuse the TV box with the TV.

Furthremore, if one translates "box-typed language" to statically
typed language, then I think one makes a fundamental mistake of
confusing "strong typing" with "static typing".

\start
Date: 21 Nov 2005 05:49:35 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: B#

Bill Page writes:

| On November 20, 2005 8:28 PM Gaby wrote:
| 
| > 
| > "Ed Borasky" writes:
| > ... 
| > | On the other hand, if you're looking to do symbolic math, 
| > | is there any reason not to use Lisp?
| > 
| > Not a significant reason -- but Lisp's type system is not
| > what I would consider "strong" :-)
| 
| We have mentioned before on this lisp the very good article
| 
| http://en.wikipedia.org/wiki/Datatype
| 
| about type systems in programming languages. "strong type
| checking" has several different definitions but I think most
| people would agree that Lisp is a strong dynamically typed
| language by most of these definitions.

That is interesting but the link above is confused to start with.  I
quote: 

   An example of the absence of strong typing is a C cast gone wrong; if
   you cast a value in C, not only is the compiler required to allow the
   code, but the runtime is expected to allow it as well.

That is misleading at best. The core C system is consistent -- the only
trouble is that I would be in difficult position to prove it, in the
mathematical sense because I have not sense any formal definition of C
in the mathematical sense.  However, the fundamental point is that if
you make a cast, the runtime is not required to accept it if it is
semantically ill-formed. And the compiler is not required to accept it
if it can somehow determine that it is invalid.  In fact, we're seeing
more compilers taking advantages of those semantics invariants, in
terms of optimizations.

Fundamentally, the C semantics is defined for *typed* objects and the
specification is done so that it allows for "erasing" translation --
which means that runtime checking is not -required- but definitely
*allowed* to check for every operation.  Indeed, there are checking C
translators around. 

I'm not here to "defend" C -- that would be a difficult task :-) but
at least, if we're going to be picky about "strong typing", let's not
pretend C allows just about anything :-)

[...]

| > | There must be some reason nearly every successful symbolic
| > | mathematics package was at least bootstrapped from some Lisp
| > | variant!
| 
| I wonder if that is true. Was Maple bootstrapped from Lisp?
| Was Mathematica bootstrapped from Lisp? Was MuPad bootstrapped
| from Lisp?

I took his remark as not meaning Lisp literally, but in its
"conceptual" sense -- for example, at one point I could pretend that
the C source part of GCC was written in Lisp :-)
MuPAD, Matematica implement, in their core, functionality found as
"built-in" in Lisp or variants. 

[...]

| > But in 2005, would you want to start with BOOT? 
| > [Bill, Tim, that was a joke :-)]
| > 
| 
| Gaby, you have a strange sense of humour!

Yup, that is what my wife keeps telling me; I'm for diversity ;-)

\start
Date: Mon, 21 Nov 2005 03:15:40 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] 

I am proposing to keep 'random()' only for finite sets. In this case it should
return a random element uniformly chosen from all elements.

For infinite sets, we have - or should have - functions which chose a random
element chosen according to the distribution, indicated by the function
name. Of course, not all distributions make sense on all sets... But I'm
certain that this can be worked out.

However, I meanwhile realize that it can be very difficult to create a random
element according to the uniform distribution of some finite domain. This is
indeed a severe obstacle. I do not know whether this applies to any domain
currently in Axiom.

Since you think that I'm missing the point, here is an example: why don't we
define 'random()\$INT' to be always equal to $1783$? Of course, it wouldn't
make much sense in practice, but it is indeed a random integer, with a rather
peculiar distribution maybe. I believe that such functions should not be used.

> > Furthermore, I think that lines like 'random()\$Z rem 11' are a
    bad idea, since the resulting distribution will be nearly uniform,
    but not quite... Do you know why such code was written?

> You are getting really picky here! 

Yes.

> just use something like 'random(11*(2^26 exquo 11))\$INT rem 11' instead.

But why wouldn't you use simply 'random(11)\$INT'? 

> Unless you are thinking of applications in exact simulations for theoretical
> probability and statistics,

Since I'm currently working in statistics and probability...

Martin

\start
Date: Mon, 21 Nov 2005 10:29:36 -0500
From: Bill Page
To: Tim Daly
Subject: RE: B#

On November 20, 2005 11:41 PM Tim Daly (root) wrote:
> 
> I suggested the BOOT language because some of the ideas are
> already implemented there. Making it a standalone language
> would give us a place to play with various syntactic and
> semantic changes. Starting to build a compiler from scratch
> would be a lot of work.
> 

After re-reading the Jenks and Trager article "How to Make
AXIOM Into a Scratchpad",

http://portal.axiom-developer.org/refs/articles/axiom-scratchpad.pdf/view

I think it is clear that B# should not be conceived of as an
non-statically typed language like Boot, but rather as a language
in which there is only one mathematical type. The authors call
this single type 'USER'. I think this is a rather poor choice
of name for the domain. Really it seems to me to be just a
generalization of the existing Axiom domain constructor
'Expression' that allows all of the kinds of manipulations of
expressions that are common in other systems like Maple and
Mathematica.

Presumably the B# language would also include some additional
data structure types like List, Array etc.

This difference between Boot and B# is important because it is
presumed that all of the objects in the USER domain can be
coerced into objects in the underlying Axiom domains just as
it is possible now to say:

(1) -> A:Expression Integer:=2*x+1

   (1)  2x + 1
                                     Type: Expression Integer
(2) -> A::Polynomial Integer

   (2)  2x + 1
                                     Type: Polynomial Integer

--------

I think of B# as first of all generalizing 'Expression' so that
all of the computations that a user is likely to want to do can
be done entirely within that one domain - just as if they were
calculating using Maple or Mathematica. And then simplifying
the syntax and semantics of the Spad language so that it always
implicitly refers to this generalized domain. And there is some
syntactic sugar to add to make this all a little sweeter.

It seems to me that Boot is too low a level at which to build
such a language. And further it does seem to make a lot of sense
to me to think of this as a "stand alone" language. I think it
must be built on top of the Axiom library, not beneath it or in
parallel with it. This means that B# should be written in Spad.

But rather than Spad, I would argue that Aldor is actually a
better choice for the B# implementation language. We have
discussed elsewhere on this list the fact that Aldor has already
been used to write a parser for the Aldor language. Doing
something similar for the B# language seems completely feasible
to me.

If we use Aldor (or Spad) to implement B#, then a user would
start using B# by invoking the read-eval-print-loop within the
B# package something like this:

(1) -> repl()$Bnatural

Of course this could be hidden for first time users within the
initial axiom.input file.

After invoking the repl, the user's interaction would be
controlled by the B# package as described in the Jenks and
Trager article.

What do you think? Is there enough interest in this to declare
this as an "official" Axiom open source project?

\start
Date: Mon, 21 Nov 2005 10:51:09 -0500
From: Bill Page
To: Tim Daly
Subject: RE: B#

On November 21, 2005 10:30 AM I wrote:

> ... 
> I think of B# as first of all generalizing 'Expression' so that
> all of the computations that a user is likely to want to do can
> be done entirely within that one domain - just as if they were
> calculating using Maple or Mathematica. And then simplifying
> the syntax and semantics of the Spad language so that it always
> implicitly refers to this generalized domain. And there is some
> syntactic sugar to add to make this all a little sweeter.
> 
> It seems to me that Boot is too low a level at which to build
> such a language. And further it does seem to make a lot of sense
> to me to think of this as a "stand alone" language. I think it
> must be built on top of the Axiom library, not beneath it or in
> parallel with it. This means that B# should be written in Spad.
> 

I intended to write:

> And further it does *not* seem to make a lot of sense to me to
> think of this as a "stand alone" language.

Regards,
Bill Page.

\start
Date: Mon, 21 Nov 2005 11:53:42 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: B#

On November 20, 2005 11:50 PM Gaby wrote:
> | 
> | We have mentioned before on this list the very good article
> | 
> | http://en.wikipedia.org/wiki/Datatype
> | 
> | about type systems in programming languages. "strong type
> | checking" has several different definitions but I think most
> | people would agree that Lisp is a strong dynamically typed
> | language by most of these definitions.
> 
> That is interesting but the link above is confused to start with.
> I quote: 
> 
>    An example of the absence of strong typing is a C cast 
>    gone wrong; if you cast a value in C, not only is the
>    compiler required to allow the code, but the runtime is
>    expected to allow it as well.
> 
> That is misleading at best. The core C system is consistent 
> -- the only trouble is that I would be in difficult position
> to prove it, in the mathematical sense because I have not sense
> any formal definition of C in the mathematical sense.  However,
> the fundamental point is that if you make a cast, the runtime is
> not required to accept it if it is semantically ill-formed. And
> the compiler is not required to accept it if it can somehow
> determine that it is invalid.  In fact, we're seeing more
> compilers taking advantages of those semantics invariants, in
> terms of optimizations.
>

I think you are wrong. For example consider this example:

/*
  'caste' example of weak typing in C
   Author: Bill Page
   Date: 21 Nov 2005
*/
#include <stdio.h>
int main(int argn, char *argv[]) {
float j;

  (int)j = 1;
  printf("float: %d\n",j);
  return 0;
}

------

You can compile this with gcc without errors and it runs without
error. What result would you expect it to return?
 
I still think the referenced article is well balanced and
accurate.

\start
Date: Mon, 21 Nov 2005 18:44:37 +0100
From: Hans Peter Wuermli
To: Bill Page
Subject: Re: B#

On Sunday 20 November 2005 17.52, you wrote:
>
> I wonder if your colleague who said: "strong typing is for the
> weak of minds" really knows what "types" in computer programming

To be fair to him, he quoted another colleagues in the US who said that to 
him. The full quote went something like: "Weak typing is for the strong minds 
and ..." and reference in the discussion was made to C and Pascal.

> I think that a lot of work has already been done in Axiom to
> support the concept of a USER algebra domain - specifically in
> the Expression constructor. Expression implements many of the
> ideas that Jenks and Trager assume for the type USER. The other
> domain in the Axiom interpreter that implements some of these
> ideas is ANY. I think of the type USER as sort of a cross
> between these two.

Noted. But even if, it seems to be difficult to continue in the same spirit.

> > Let me give some examples of what I would consider nice
> > syntactic sugar, and it must be syntactic sugar as the
> > evaluation of any expression is ultimately extremely simple
> > as explained at the end of section 5 of the "Axiom as
> > Scratchpad" article.
> >
> > 1) TeX-like conventions: being able to define, say, variables
> > as x_{i,j} looks very handy. One should actually go further
> > and allow type annotations, like
> >
> > x_{i:NNI,j:PI}:POLY INT,
> >
> > or even further
>
> I think you are mixing sugar with semantics here. It does not
> make sense to me to associate types with superscirpts and
> subscripts if these are just symbols. But if they are not
> symbols then we need to decide what the use of subscript
> means, e.g. if x is a matrix then the subscripts might
> denote a reference to an element of a matrix. It is not
> clear to me what meaning might be associated with your
> example.

Let me explain, why I think it's a syntax problem: 

If a mathematician writes a_i, he thinks of a function 

a: Index -> Something, i |-> a(i).

Further, sometimes he writes sloppily f(x) for a function (domain and range to 
be guessed), some other times f_x. So if B# proposes TeX like conventions, it 
proposes an alternative syntax for Expressions (denoting "functions") which 
in the current implementation I think are called "kernel", having the form 
"f(x)", but could also be denoted with f_x, or, if it is a function of two 
variables, f_{x,y}.

So the meaning is: f_x `equal` f(x), or, f_{x,y} `equal` f(x,y).

I guess that the internal representation would coincide, whereas the 
"OutputForm" would differ.

The second form, which does not seem to be proposed, but that would equally 
well make sense are type annotations, which would express the intended type, 
i.e.

f_{x:INT}:NNI `equal` f: (x:INT) -> NNI `equal` f(x: INT):NNI

(where I am unsure whether the middle and last forms exist as a declaration). 
If anything this would probably help disambiguate Expressions.

> > and allow "operators" as syntactic elements, like defining a
> > few variables as (or the sum example in "Afterthoughts, ...")
> >
> > for i in 0..5 repeat x_i:POLY INT
>
> As I understand it, this syntax actually denotes 6 names,
> x_0 x_1 ... x_5 all of type POLY INT, is that right?

Yes, that is what would be meant, and I tried, also with declaring the 
variables global (i.e. free), but it did not seem to work.

> > This actually seems to be nothing else than polymorphism of
> > the function "for", if - as the manuals claim - types are
> > first class citizens.

> Could you explain how you think of "for" as a function in this
> example?

I didn't think much about this one, but assumed that a "for" would correspond 
to a construct with operational semantics, "for" being defined as a 
recursively defined Monad binder.

> > 2) Afterthoughts: if "==" generally would point to a rewrite
> > rule then exending eval to an eval ( expr, List 'Rewrite Rules' )
> > would semantically be the same as the "afterthoughts". It looks
> > to me that this is the regular evaluation mechanism of any
> > functional programming language.
>
> Could you please explain this a little more. I do not think
> of == as involving any type of evaluation.

I used the suggestion in the "Axiom as Scratchpad" paper to read "==" as 
rewrite operator. See the example in "Afterthoughts". It immediately appealed 
to me though, because functions in Axiom as well as in Haskell are defined 
that way, the left side representing the name and argument(s) and the right 
side the body of a (typed) lambda, where the body "evaluated" with further 
rewrite rules producing the value of the right type. Actually, I played a 
little bit with the idea to use the Axiom == in this way, but it didn't 
really work.

My question would be, to what extent the current "="-equation sign in Equation 
expressions serves that purpose and whether "=" could be overloaded?

Does this answer your question or did you mind my use of the term "eval"?

> > (Currently an expression like x==t has the type Void; I wonder
> > what would happen if this construct came under programming
> > control.)
>
> What type would you suggest?

RewriteRule PatternType BodyType

(PatternType and BodyType are inventions for the purpose of this email.)

> Axiom supports currying of functions. You might recall some
> discussion between myself and William Sit about this. 

I had seen it but no time at the time to follow it.

\start
Date: 21 Nov 2005 18:58:50 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: B#

Bill Page writes:

| On November 20, 2005 11:50 PM Gaby wrote:
| > | 
| > | We have mentioned before on this list the very good article
| > | 
| > | http://en.wikipedia.org/wiki/Datatype
| > | 
| > | about type systems in programming languages. "strong type
| > | checking" has several different definitions but I think most
| > | people would agree that Lisp is a strong dynamically typed
| > | language by most of these definitions.
| > 
| > That is interesting but the link above is confused to start with.
| > I quote: 
| > 
| >    An example of the absence of strong typing is a C cast 
| >    gone wrong; if you cast a value in C, not only is the
| >    compiler required to allow the code, but the runtime is
| >    expected to allow it as well.
| > 
| > That is misleading at best. The core C system is consistent 
| > -- the only trouble is that I would be in difficult position
| > to prove it, in the mathematical sense because I have not sense
| > any formal definition of C in the mathematical sense.  However,
| > the fundamental point is that if you make a cast, the runtime is
| > not required to accept it if it is semantically ill-formed. And
| > the compiler is not required to accept it if it can somehow
| > determine that it is invalid.  In fact, we're seeing more
| > compilers taking advantages of those semantics invariants, in
| > terms of optimizations.
| >
| 
| I think you are wrong.

No -- sorry, Bill you can't have it right on this one.

| For example consider this example:
| 
| /*
|   'caste' example of weak typing in C
|    Author: Bill Page
|    Date: 21 Nov 2005
| */
| #include <stdio.h>
| int main(int argn, char *argv[]) {
| float j;
| 
|   (int)j = 1;
|   printf("float: %d\n",j);
|   return 0;
| }
| 
| ------
| 
| You can compile this with gcc without errors and it runs without
| error. What result would you expect it to return?

Your program is ill-formed according to ISO C rules and semantics and
my compiler rightly rejects it:

    merlin[12:54]% cat bill-page.c && gcc bill-page.c
    /*
        'caste' example of weak typing in C
           Author: Bill Page
              Date: 21 Nov 2005
    */
    #include <stdio.h>
    int main(int argn, char *argv[]) {
       float j;

       (int)j = 1;
       printf("float: %d\n",j);
       return 0;
    }
    bill-page.c: In function 'main':
    bill-page.c:10: error: invalid lvalue in assignment


| I still think the referenced article is well balanced and
| accurate.

I don't think so  If is full of confusion and misunderstanding.
Unfortunately, many people take it as a Bible sentence don't go and do
a minimum scrutinity as would be required in a scientific setting :-(

\start
Date: Mon, 21 Nov 2005 10:41:22 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Tim Daly
Subject: RE: B#

--- Bill Page wrote:

> I think of B# as first of all generalizing 'Expression' so that
> all of the computations that a user is likely to want to do can
> be done entirely within that one domain - just as if they were
> calculating using Maple or Mathematica. And then simplifying
> the syntax and semantics of the Spad language so that it always
> implicitly refers to this generalized domain. And there is some
> syntactic sugar to add to make this all a little sweeter.

Sounds like a good way to make Axiom more friendly for new (and casual)
users.
 
> But rather than Spad, I would argue that Aldor is actually a
> better choice for the B# implementation language. We have
> discussed elsewhere on this list the fact that Aldor has 
> already been used to write a parser for the Aldor language. 
> Doing something similar for the B# language seems completely 
> feasible to me.

I agree this is a job for a high level language, but I would suggest
that the Aldor licensing situation be clarified before implementing B#
in it.  (I promise I'll move to axiom-legal if the discussion around
this heats up ;-).

> If we use Aldor (or Spad) to implement B#, then a user would
> start using B# by invoking the read-eval-print-loop within the
> B# package something like this:
> 
> (1) -> repl()$Bnatural
> 
> Of course this could be hidden for first time users within the
> initial axiom.input file.

Right.

> After invoking the repl, the user's interaction would be
> controlled by the B# package as described in the Jenks and
> Trager article.
> 
> What do you think? Is there enough interest in this to declare
> this as an "official" Axiom open source project?

I would say so!  We want users, and Axiom's type system is frequently
cited as a high hurdle for beginners.

I like the idea of starting out in B-natural, and then for advanced
users being able to "drop down" into the current environment when
strong typing becomes a tool rather than a distraction.  The full power
of Axiom is hidden but when the user wants to expand they will find the
system able to do so.

Cheers,
CY

P.S.  Bill, just a quick dumb question on the Real Number stuff - are
Real Numbers on a computer just an expansion of Floats?  E.g. Floats
are designed to map well to the limitations of the low level
processors, and Reals are a superset of Floats but make no attempt to
be easy on the hardware?

\start
Date: Mon, 21 Nov 2005 14:09:49 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: B#

On November 21, 2005 12:59 PM Gaby wrote:
> 
> Bill Page writes:
> | 
> | http://en.wikipedia.org/wiki/Datatype
> | 
> | > 
> | > That is interesting but the link above is confused to start
> | > with. I quote: 
> | > 
> | >    An example of the absence of strong typing is a C cast 
> | >    gone wrong; if you cast a value in C, not only is the
> | >    compiler required to allow the code, but the runtime is
> | >    expected to allow it as well.
> | > 
> | > That is misleading at best. ...
> | 
> | I think you are wrong.
> 
> No -- sorry, Bill you can't have it right on this one.
> 
> 
> Your program is ill-formed according to ISO C rules and semantics
> and my compiler rightly rejects it:
> 
>     bill-page.c: In function 'main':
>     bill-page.c:10: error: invalid lvalue in assignment
> 

I guess we are using different versions of gcc.

Here is what I get:

$ gcc --version;cat cast1.c; gcc -o cast1 cast1.c; cast1
gcc.exe (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

/*
  'caste' example of weak typing in C
   Author: Bill Page
   Date: 21 Nov 2005
*/
#include <stdio.h>
int main(int argn, char *argv[]) {
float j;

  (int)j = 1;
  printf("float: %d\n",j);
  return 0;
}
cast1.c: In function `main':
cast1.c:10: warning: use of cast expressions as lvalues is
            deprecated
float: 0

--------

I note that I do get a warning. So this is a feature in the
language that is changing (deprecated).

> 
> | I still think the referenced article is well balanced and
> | accurate.
> 
> I don't think so  If is full of confusion and misunderstanding.

You have given only one example of something you disagree with
and at most I might be forced to agree that the author should
probably have been specific about which version of C he was
criticizing. The point still stands that many version of C used
to accept such constructions even if that is no longer true in
all versions.

> Unfortunately, many people take it as a Bible sentence don't
> go and do a minimum scrutinity as would be required in a
> scientific setting :-(
> 

Maybe some people do, but I do not intend to accept such an
attitude. I think I have applied much more than "minimum
scrutiny" to this article. Of course it is difficult to be
entirely accurate in an article that is intended to be at
most one or two pages.

Notice that there is a reference therein also to

http://en.wikipedia.org/wiki/Strongly-typed_programming_language

which also criticises the term "strong typing" as being
ambiguous and quotes well known author Benjamin C. Pierce
to this effect.

Could you provide a reference to a short article that you think
is less "full of confusion and misunderstanding"?

\start
Date: Mon, 21 Nov 2005 14:27:43 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: Cast = pretend in Spad/Aldor?  (was: B#)

On November 21, 2005 12:59 PM Gaby wrote:

> 
> "Bill Page" writes:
> 
> | On November 20, 2005 11:50 PM Gaby wrote:
> | > | 
> | > | We have mentioned before on this list the very good article
> | > | 
> | > | http://en.wikipedia.org/wiki/Datatype
> | > | 
> | > 
> | > That is interesting but the link above is confused to start
> | > with. I quote: 
> | > 
> | >    An example of the absence of strong typing is a C cast 
> | >    gone wrong; if you cast a value in C, not only is the
> | >    compiler required to allow the code, but the runtime is
> | >    expected to allow it as well.
> | > 
> ...

Actually, perhaps I should simply concede that the above
article is not particularly good, and I will be glad to do
so if you can recommend a better alternative that defines
these terms more accurately.

But really I don't want to be spending a lot of time arguing
about the merits of the C programming language on this list.
What I would really like to think about is strong static typing
in the context of Axiom, specifically in Spad and in Aldor.

There is one very important type-related construction in
Spad and in Aldor that looks as if it might make them "weak"
in the sense in which the author of the above quote implies
the use of cast in the C language makes it weak. That is the
use of 'pretend'.

It is pretty clear in the following example that the Axiom
interpreter does something odd:

(1) -> I:Integer
                                                Type: Void
(2) -> F:Float:=1.0

   (2)  1.0
                                                Type: Float
(3) -> I := F pretend Integer

   (3)  1()
                                                Type: Integer

------

Yet the ability to use 'pretend' is critical to the concept
of representation in the construction of Axiom domains.

For a perhaps overly abstract discussion of this see:

http://wiki.axiom-developer.org/RepAndPer

So my question is: Does this feature of the Spad and Aldor
languages actually make them "weakly typed"?

\start
Date: 21 Nov 2005 20:56:11 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: B#

Bill Page writes:

[...]

| cast1.c: In function `main':
| cast1.c:10: warning: use of cast expressions as lvalues is
|             deprecated
| float: 0
| 
| --------
| 
| I note that I do get a warning. So this is a feature in the
| language that is changing (deprecated).

No, it is not something in the C language.  As I said in my previous
message, the ISO C rules say it is ill-formed.

The "feature" you're testing and you think is part of C is actually a
(misguided, IMNSHO) GNU extension that we happily removed in recent
versions -- we decided to warn wbout it in preceding releases.

| > | I still think the referenced article is well balanced and
| > | accurate.
| > 
| > I don't think so  If is full of confusion and misunderstanding.
| 
| You have given only one example of something you disagree with

You're very kind in crediting me as author of the example you put
forward :-)

| and at most I might be forced to agree that the author should
| probably have been specific about which version of C he was
| criticizing.

Again, it is not about which version of C being criticed.  That stuff
wasn't part of ISO C90, it isn't part of ISO C99 -- and I'm pretty sure it
wasn't part of K&R C (though my copy of that book is inaccessible at
the moment).

You intended to prove that my previous statement about the core C
semantics was wrong by exhibiting a specifc example.  I'm more 
than willing to accept I'm wrong if before real facts, not examples
based on misunderstanding. 

| The point still stands that many version of C used
| to accept such constructions even if that is no longer true in
| all versions.

I do hope you make a distinction between a *language specification* and
its *implementations* by various incomplete and buggy compilers!

| > Unfortunately, many people take it as a Bible sentence don't
| > go and do a minimum scrutinity as would be required in a
| > scientific setting :-(
| > 
| 
| Maybe some people do, but I do not intend to accept such an
| attitude. I think I have applied much more than "minimum
| scrutiny" to this article. Of course it is difficult to be
| entirely accurate in an article that is intended to be at
| most one or two pages.

Well, don't take it as a personal thing.  My comment was very broad
and was not targetting you specifically.  It upset me you took it
personally. 

As many years of active involvement in the development of the ISO 
standards for C and C++, and their implementations I've come to the
conclusion that many material out there, either in peer reviewed
journals, conferences or on the web display serious defective
understanding of the languages they are playing down or praising.
That widestreap tribal ritual of playing them down does not help either :-/

| Notice that there is a reference therein also to
| 
| http://en.wikipedia.org/wiki/Strongly-typed_programming_language
| 
| which also criticises the term "strong typing" as being
| ambiguous and quotes well known author Benjamin C. Pierce
| to this effect.

Notice I'm not disputing that the term "strong typing" is ambiguous.
I'm disagreeing with the claims that the C programming language was
supposed to illustrate.

(I know of lot of deficiencies in C -- it is hard not to, when you're
involved in its specification and implementation) but none of the
examples I've so far are illustrative of the claim of "weak typing". 

| Could you provide a reference to a short article that you think
| is less "full of confusion and misunderstanding"?

About C?  The shortest is the ISO C specification :-)

\start
Date: 21 Nov 2005 21:13:37 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Cast = pretend in Spad/Aldor?  (was: B#)

Bill Page writes:

| On November 21, 2005 12:59 PM Gaby wrote:
| 
| > 
| > "Bill Page" writes:
| > 
| > | On November 20, 2005 11:50 PM Gaby wrote:
| > | > | 
| > | > | We have mentioned before on this list the very good article
| > | > | 
| > | > | http://en.wikipedia.org/wiki/Datatype
| > | > | 
| > | > 
| > | > That is interesting but the link above is confused to start
| > | > with. I quote: 
| > | > 
| > | >    An example of the absence of strong typing is a C cast 
| > | >    gone wrong; if you cast a value in C, not only is the
| > | >    compiler required to allow the code, but the runtime is
| > | >    expected to allow it as well.
| > | > 
| > ...
| 
| Actually, perhaps I should simply concede that the above
| article is not particularly good, and I will be glad to do
| so if you can recommend a better alternative that defines
| these terms more accurately.

I don't know of a good definition of "strong typing" that does not
promote particular languages one is interested in, and at the same
time downplay languages one does not particular like/prefer/use.

The term is ambiguous, and usually used to convey personal preferences
undr the cover of seemingly "universal terms."

| But really I don't want to be spending a lot of time arguing
| about the merits of the C programming language on this list.
| What I would really like to think about is strong static typing
| in the context of Axiom, specifically in Spad and in Aldor.

Great!  We're on the same page then.

| There is one very important type-related construction in
| Spad and in Aldor that looks as if it might make them "weak"
| in the sense in which the author of the above quote implies
| the use of cast in the C language makes it weak. That is the
| use of 'pretend'.

I claim that any serious programming language for large scale
software, that supports system programming to some extent, and that
allows "multiple representation" would contain something similar to
casts, and that operation would probably be spelled differently.

| It is pretty clear in the following example that the Axiom
| interpreter does something odd:
| 
| (1) -> I:Integer
|                                                 Type: Void
| (2) -> F:Float:=1.0
| 
|    (2)  1.0
|                                                 Type: Float
| (3) -> I := F pretend Integer
| 
|    (3)  1()
|                                                 Type: Integer

I'm not (yet) fluent in Aldor as I would like, and I wish I had more
time to devote to the language specification and implementation.  I
however hope the Aldor compiler source will be "open sourced" soon as
I understood it.

| Yet the ability to use 'pretend' is critical to the concept
| of representation in the construction of Axiom domains.

Indeed.

| For a perhaps overly abstract discussion of this see:
| 
| http://wiki.axiom-developer.org/RepAndPer
| 
| So my question is: Does this feature of the Spad and Aldor
| languages actually make them "weakly typed"?

In my mind "pretend" by itself does not make the language "weak
typed".  It would make it so only if it "actively support" type
unsafe operations to be carried on with minimal effort -- in that
sense I would claim C is weakly typed.  Notice here that my used of 
"type safety" is not in a a universal sense, but relatively to Aldor's
own semantics.
For more elaboration of what I meant, and in better and clearer terms,
have a look at the following (of Bob Harper):

  http://www.seas.upenn.edu/~sweirich/types/archive/1999-2003/msg00298.html

\start
Date: Mon, 21 Nov 2005 15:30:09 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: B#

On November 21, 2005 2:56 PM Gaby wrote:
> ... 
> | > | I still think the referenced article is well balanced
> | > | and accurate.
> | > 
> | > I don't think so  If is full of confusion and misunderstanding.
> | 
> | You have given only one example of something you disagree with
> 
> You're very kind in crediting me as author of the example you put
> forward :-)
>

Well, I suppose I should have been a little more careful with
my example. How about this:

$ gcc --version;cat cast1.c; gcc -o cast1 cast1.c; cast1
gcc.exe (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

/*
  'caste' example of weak typing in C
   Author: Bill Page
   Date: 21 Nov 2005
*/
#include <stdio.h>
int main(int argn, char *argv[]) {
int i;
float j;

  i = 1;
  j = (float)i;
  printf("float: %d\n",j);
  return 0;
}
float: 0

----------

Does this program conform to ISO C99? Does it compile with
your newer version of gcc? Does it produce a result that you
expect?
 
> ... 
> | > Unfortunately, many people take it as a Bible sentence
> | > don't go and do a minimum scrutinity as would be required
> | > in a scientific setting :-(
> | > 
> | 
> | Maybe some people do, but I do not intend to accept such an
> | attitude. I think I have applied much more than "minimum
> | scrutiny" to this article. Of course it is difficult to be
> | entirely accurate in an article that is intended to be at
> | most one or two pages.
> 
> Well, don't take it as a personal thing.  My comment was very
> broad and was not targetting you specifically.  It upset me you
> took it personally.

No problem, I do not mind being "targetted" even if you did
not intend it. Please don't worry that I took it "personally",
but I did take it seriously and I think you meant it seriously,
right?

> ... 
> Notice I'm not disputing that the term "strong typing" is
> ambiguous. I'm disagreeing with the claims that the C
> programming language was supposed to illustrate.

Do you think my improved example illustrates this point?

> 
> (I know of lot of deficiencies in C -- it is hard not to,
> when you're involved in its specification and implementation)
> but none of the examples I've so far are illustrative of the
> claim of "weak typing".

I am very glad that you have been active in the standardization
of C and that you are here discussing Axiom. Perhaps some day
we will be talking about standardization of computer algebra
languages?

> 
> | Could you provide a reference to a short article that you
> | think is less "full of confusion and misunderstanding"?
> 
> About C?  The shortest is the ISO C specification :-)
> 

That is a pity.

Suppose we agree to strike all references of C from the
Wikipedia article:

http://en.wikipedia.org/wiki/Datatype

then would you consider it a reasonable brief discussion of
type systems in programming languages?

\start
Date: Mon, 21 Nov 2005 16:48:27 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Cast = pretend in Spad/Aldor?

On November 21, 2005 3:14 PM Gaby wrote:
> ...
> Bill Page wrote: 
> | There is one very important type-related construction in
> | Spad and in Aldor that looks as if it might make them "weak"
> | in the sense in which the author of the above quote implies
> | the use of cast in the C language makes it weak. That is the
> | use of 'pretend'.
> 
> I claim that any serious programming language for large scale
> software, that supports system programming to some extent, and
> that allows "multiple representation" would contain something
> similar to casts, and that operation would probably be spelled
> differently.

I think representation in domains (rep and per) is an essential
part of Axiom's "object model". Would you say that your claim
above also applies to any object-oriented language?

> 
> | It is pretty clear in the following example that the Axiom
> | interpreter does something odd:
> | 
> | (1) -> I:Integer
> |                                                 Type: Void
> | (2) -> F:Float:=1.0
> | 
> |    (2)  1.0
> |                                                 Type: Float
> | (3) -> I := F pretend Integer
> | 
> |    (3)  1()
> |                                                 Type: Integer
> 
> I'm not (yet) fluent in Aldor as I would like, and I wish
> I had more time to devote to the language specification and
> implementation. I however hope the Aldor compiler source will
> be "open sourced" soon as I understood it.

We are still waiting <expression of growing frustration> for
Steven Watt to officially announce something. I do not understand
the delay but I am still confident that this is going to happen.
And I am still plotting possible ways to force the issue. :)
Of course it would still help if other people on this list would
simply write to Steven and emphasize the importance of making
Aldor open source as soon as possible.

In the mean time we can certainly apply these same ideas to
Spad and to the Spad-like programming language embedded in
Axiom's interpreter.

> 
> | Yet the ability to use 'pretend' is critical to the concept
> | of representation in the construction of Axiom domains.
> 
> Indeed.
> 
> | For a perhaps overly abstract discussion of this see:
> | 
> | http://wiki.axiom-developer.org/RepAndPer
> | 
> | So my question is: Does this feature of the Spad and Aldor
> | languages actually make them "weakly typed"?
> 
> In my mind "pretend" by itself does not make the language "weak
> typed".  It would make it so only if it "actively support" type
> unsafe operations to be carried on with minimal effort -- in that
> sense I would claim C is weakly typed.  Notice here that my used
> of "type safety" is not in a universal sense, but relatively to
> Aldor's own semantics.

Ok, so my example above from the Axiom interpreter (this is not
what happens in Spad and Aldor) would be such an example of
failure of type safety, right?

> For more elaboration of what I meant, and in better and clearer
> terms, have a look at the following (of Bob Harper):
>   
> http://www.seas.upenn.edu/~sweirich/types/archive/1999-2003/msg00298.html

Thank you for this reference. I think it is very useful. I find
the notion of "transitions" between programs to be rather awkward
to apply but perhaps I simply do not understand the approach very
well. Can you suggest a reference that describes the formal approach
used here by Robert Harper?

Generally I have come to prefer a more "category theory" oriented
approach to program semantics e.g. as presented in introductory
form by Benjamin Pierce in "Basic Category Theory of Computer
Scientists" and in his "Advanced Topics ..." collection (which
contains a joint paper by Harper and Pierce on ML modules).

It seems to me that category theory (on the surface at least) is
more suitable to the mathematical aims of Axiom. I would like to
be able to think about type safety in these terms.

\start
Date: 21 Nov 2005 23:01:56 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: B#

Bill Page writes:

| On November 21, 2005 2:56 PM Gaby wrote:
| > ... 
| > | > | I still think the referenced article is well balanced
| > | > | and accurate.
| > | > 
| > | > I don't think so  If is full of confusion and misunderstanding.
| > | 
| > | You have given only one example of something you disagree with
| > 
| > You're very kind in crediting me as author of the example you put
| > forward :-)
| >
| 
| Well, I suppose I should have been a little more careful with
| my example. How about this:
| 
| $ gcc --version;cat cast1.c; gcc -o cast1 cast1.c; cast1
| gcc.exe (GCC) 3.4.2 (mingw-special)
| Copyright (C) 2004 Free Software Foundation, Inc.
| This is free software; see the source for copying conditions.  There is NO
| warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
| 
| /*
|   'caste' example of weak typing in C
|    Author: Bill Page
|    Date: 21 Nov 2005
| */
| #include <stdio.h>
| int main(int argn, char *argv[]) {
| int i;
| float j;
| 
|   i = 1;
|   j = (float)i;
|   printf("float: %d\n",j);
|   return 0;
| }
| float: 0
| 
| ----------
| 
| Does this program conform to ISO C99?

No, it does not.
Because of the obvious reasons -- passing in double (yes, floats get
promoted to doubles when passed in ellipsis) and telling printf() to
access if as int.  That is undefined behaviour according to ISO C
rules.  
Good compilers would catch such cases; and good runtimes would also catch
it. 

| Does it compile with
| your newer version of gcc? Does it produce a result that you
| expect?

GCC has format checkin -- which gets improved every release -- and
mine says

   merlin[16:37]% cat bad-format.c && gcc -Wformat bad-format.c
   /*
       'caste' example of weak typing in C
          Author: Bill Page
             Date: 21 Nov 2005
   */
   #include <stdio.h>
   int main(int argn, char *argv[]) {
      int i;
      float j;

      i = 1;
      j = (float)i;
      printf("float: %d\n",j);
      return 0;
   }
   bad-format.c: In function 'main':
   bad-format.c:13: warning: format '%d' expects type 'int', but argument 2 has type 'double'

| > ... 
| > | > Unfortunately, many people take it as a Bible sentence
| > | > don't go and do a minimum scrutinity as would be required
| > | > in a scientific setting :-(
| > | > 
| > | 
| > | Maybe some people do, but I do not intend to accept such an
| > | attitude. I think I have applied much more than "minimum
| > | scrutiny" to this article. Of course it is difficult to be
| > | entirely accurate in an article that is intended to be at
| > | most one or two pages.
| > 
| > Well, don't take it as a personal thing.  My comment was very
| > broad and was not targetting you specifically.  It upset me you
| > took it personally.
| 
| No problem, I do not mind being "targetted" even if you did
| not intend it. Please don't worry that I took it "personally",

OK, thanks.

| but I did take it seriously and I think you meant it seriously,
| right?

yes.

| > ... 
| > Notice I'm not disputing that the term "strong typing" is
| > ambiguous. I'm disagreeing with the claims that the C
| > programming language was supposed to illustrate.
| 
| Do you think my improved example illustrates this point?

Not really -- not in the sense that the compiler would be _required_
to accept it. A compiler is not required to accept an ill-formed
program.  I believe that is main point of confusion when people
talk about the C type system. 

I would concede it exhibits the C type system as a "weak system" --
not in the sense that the C semantics requires the compiler (or the
runtime) to accept the program.  It illustrates the weakness in the
sense that such an error (from the language semantics point of view)
can be made very easily -- see my previous message. 

| > (I know of lot of deficiencies in C -- it is hard not to,
| > when you're involved in its specification and implementation)
| > but none of the examples I've so far are illustrative of the
| > claim of "weak typing".
| 
| I am very glad that you have been active in the standardization
| of C and that you are here discussing Axiom. Perhaps some day
| we will be talking about standardization of computer algebra
| languages?

probably, but I would first need to make a good contribution,
implementation wise :-)
I'm glad Tim followed up on the Lyon meeting by having the Axiom
happening free.

| > | Could you provide a reference to a short article that you
| > | think is less "full of confusion and misunderstanding"?
| > 
| > About C?  The shortest is the ISO C specification :-)
| > 
| 
| That is a pity.

Indeed.

| Suppose we agree to strike all references of C from the
| Wikipedia article:
| 
| http://en.wikipedia.org/wiki/Datatype
| 
| then would you consider it a reasonable brief discussion of
| type systems in programming languages?

well, it depends at what level.  For a simple introductory material
for freshmen, that would probably do.
But I'm not sure I would take it as a basis for more serious
discussions on type systems in programming languages.

The point is, it starts with equating "datatype" with "types", then
builds on a set-theoretic centric notion of type.  However,
polymorphism, for example, is not set-theoretic (see Reynolds).  I
don't think I agree that is reasonable.  
Type system is not a simple matter -- it took Pierce about 6 hundreds
pages to introduce the basic notions (and another volume to talk about
"advanced" type systems.) 

I'm not claiming I have better answers; I'm just dubitative that the
material you point to is a reasonable summary.  However, it is a
material to be read by all parties :-)

\start
Date: Mon, 21 Nov 2005 14:17:59 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Gabriel Dos Reis
Subject: RE: B#

--- Bill Page wrote:

> I am very glad that you have been active in the standardization
> of C and that you are here discussing Axiom. Perhaps some day
> we will be talking about standardization of computer algebra
> languages?

A very interesting and potentially important thought.  I'm hoping Tim
would agree that the best way to approach either SPAD or more probably
Aldor as a high level language for Axiom would be to create a "literate
specification" of the language, in the tradition of ANSI specs but with
not only text but code incorporated into them.  Say, for example,
implement as much of Aldor as can be handled in Aldor itself, and have
a "bootstrapping" definition in C or Lisp, as the case may be.  I
suppose the opinion that the Axiom project can't create a whole new
compiler is correct when designing from scratch, but hopefully we can
take Aldor and create some kind of "literate specification" with it
:-).

I've been exploring along those lines with the draft ANSI Lisp
specification, seeing as it is already TeX - it's status is a tad murky
but given it has been freely downloadable for a decade and there
already exists the freely viewable hyperspec...  weaving it into a lisp
implementation would be a really interesting exercise :-).

OpenMath seems to be the closest thing out there to a universal
standard and that has problems - hmm.  An interesting problem.

\start
Date: Mon, 21 Nov 2005 18:22:38 -0600
From: MathAction (unknown)
To: MathAction
Subject: [#227 'random()$Integer' is a strange function] 

>Since I'm currently working in statistics and probability...

In that case, I completely agree with you on exactness whenever
possible (depending on the computation and distribution involved). But
those situations are rare (may be limited to only some discrete random
variable with a finite sample space like the Binomial r.v.)  I wonder
how one can create even a normally distrihbuted random variable. In
simulation programs involving a continuous random variable, uniformly
distributed floats and the inverse of the cumulative distribution
function are involved. How can you do any exact computations with
continuous variables if you have to solve for the inverse of the cdf?
You will need exact reals, and then an exact method to solve
'cdf(x)=y', for any uniformly distributed random real number 'y' over
(0,1). Even for discrete variables like the Poission variable, you
will have to use floats, or else you get into exact summations and
their inverses.

>But why wouldn't you use simply 'random(11)\$INT' ?

Because I was not thinking or was stupid or both!

Now that I believe I am thinking, using 'random(11)\$INT' simply
passes the question to Lisp and if you are still picky, you should
investigate how the Lisp function 'random(n)' is coded. Is it some
variation of the usual linear congruence method, but perhaps extended
to arbitrary precision with a large base like $2^{26}$ to cover really
large 'n'. For small 'n', it would be modulo 'n' in the same way: that
is, the algorithm for 'random(11)\$Lisp' may be actually something
like 'random1(seed)$Lisp rem 11' translated to Lisp where 'random1'
(name is arbitrarily made up) is the Lisp random number generator for
single precision (4 byte, for example) integers and 'seed' is the seed
or previously generated random single precision integer.  If so, it
would be only approximately uniform also.

>For infinite sets, we have - or should have - functions which chose a
 random element chosen according to the distribution, indicated by the
 function name. Of course, not all distributions make sense on all
 sets... But I'm certain that this can be worked out.

The way to go would seem to be to create two new categories
'ProbabilityDensityFunctions' (or 'ProbabilityDensityFunctionSpace')
and 'RandomVariable', say 'RandomVariable(S:Set,
d:ProbabilityDensityFunction)' where 'S' is the sample space, and
'x:=random()' would mean 'x' is a r.v. on 'S' with probabillity
density function 'd', and then create domains for these. The actual
design, parameters, and specifications will need be more carefully
thought out, say whether to use the cdf instead of the pdf (it seems
cdf has lots of advantages as it is easy to recover the pdf by
differentiation in many cases and cdf is continuous), and what are
useful functions ( 'seed(x)', 'nextRandom(x)' come to mind, but
operations on r.v. such as finding the pdf of joint distributions, are
possible too). Then, if we were in Aldor, we can retroactively make
'IntegerNumberSystem' a subcategory (In Axiom, we add a package).
This would be a major project, since as you know, probability theory
gets g!  eneralized into measure theory and so on.

I think worrying about the proper syntax of 'random()' for an infinite
sample space is the least of our (your?) problems :-)

\start
Date: Tue, 22 Nov 2005 12:34:04 +1000
From: Mike Thomas
To: Tim Daly
Subject: RE: [Axiom-developer] axiom conference funding?

| frankly i think it'd be a lot of fun to rent a beach house
| somewhere and spend 3 days code
| hacking/designing/lang-wars-ing on the front porch. morning
| presentations, afternoon debates, evening code hacking. the
| scratchpad group used to do this in the hamptons, i believe.
| nobody said a conf HAS to be in a huge building with
| cinderblock walls.

Sounds like you all need to come here to Brisbane (Queensland,
Australia, Sunshine Coast and Gold Coast available). 

\start
Date: Mon, 21 Nov 2005 21:51:32 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Cast = pretend in Spad/Aldor?

On November 21, 2005 4:48 PM I wrote:

> 
> It is pretty clear in the following example that the Axiom
> interpreter does something odd:
> 
> (1) -> I:Integer
>                                                 Type: Void
> (2) -> F:Float:=1.0
> 
>    (2)  1.0
>                                                 Type: Float
> (3) -> I := F pretend Integer
> 
>    (3)  1()
>                                                 Type: Integer
> ... 
> In the mean time we can certainly apply these same ideas to
> Spad and to the Spad-like programming language embedded in
> Axiom's interpreter.
>
> Gaby wrote:
> > Bill Page wrote:
> > | Yet the ability to use 'pretend' is critical to the concept
> > | of representation in the construction of Axiom domains.
> > 
> > Indeed.
> > 
> > | For a perhaps overly abstract discussion of this see:
> > | 
> > | http://wiki.axiom-developer.org/RepAndPer
> > | 
> > | So my question is: Does this feature of the Spad and Aldor
> > | languages actually make them "weakly typed"?
> > 
> 
> > In my mind "pretend" by itself does not make the language "weak
> > typed".  It would make it so only if it "actively support" type
> > unsafe operations to be carried on with minimal effort -- in that
> > sense I would claim C is weakly typed.  Notice here that my used
> > of "type safety" is not in a universal sense, but relatively to
> > Aldor's own semantics.
>
> Ok, so my example above from the Axiom interpreter (this is not
> what happens in Spad and Aldor) would be such an example of
> failure of type safety, right?

Here is the unhappy result of using 'pretend' this same way in
Spad:

(1) -> )sys cat cast.spad

)abbrev package CAST cast
cast(): exports == implementation where

  exports == with

    cast1: Integer -> Float

  implementation == add

    cast1(i:Integer):Float ==
      j:Float := (i pretend Float)

(1) -> )compile cast.spad
   Compiling AXIOM source code from file
      /home/page/cast.spad
      using old system compiler.
   CAST abbreviates package cast
...
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /home/page/axiom/CAST.NRLIB/code.lsp.
------------------------------------------------------------------------
   cast is already explicitly exposed in frame initial
   cast will be automatically loaded when needed from
      /home/page/CAST.NRLIB/code

(1) -> cast1(1)$CAST

   >> System error:
   Caught fatal error [memory may be damaged]

(1) ->

-----------

The same thing happens with Aldor:

(1) -> )sys cat casta.as
#include "axiom"
cast2(i: Integer): Float == {
      j:Float := (i pretend Float)
}

(1) -> )compile casta.as
   Compiling AXIOM source code from file /home/page/casta.as using
      AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y
$AXIOM/algebra
      Use the system command )set compiler args to change these
      options.
#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
   Compiling Lisp source code from file ./casta.lsp
   Issuing )library command for casta
   Reading /home/page/casta.asy

(1) -> cast2(1)

   >> System error:
   Caught fatal error [memory may be damaged]

---------

As you can see we do not get a compile time errors, but we
do get a run-time errors.

By your criteria above then, would you agree that this
example proves that both Spad and Aldor are in fact weakly
typed or type unsafe?

Or do I have to be more careful to define clearly what are
the Spad and Aldor semantics for the example code before I
can make such a claim?

\start
Date: Mon, 21 Nov 2005 21:58:18 -0500
From: Bill Page
To: Mike Thomas
Subject: RE: axiom conference funding?

On November 21, 2005 9:34 PM Mike Thomas wrote:
> 
> | frankly i think it'd be a lot of fun to rent a beach house 
> | somewhere and spend 3 days code hacking/designing/lang-wars-ing
> | on the front porch. morning presentations, afternoon debates,
> | evening code hacking. the scratchpad group used to do this in
> | the hamptons, i believe. nobody said a conf HAS to be in a huge
> | building with cinderblock walls.
> 
> Sounds like you all need to come here to Brisbane (Queensland,
> Australia, Sunshine Coast and Gold Coast available).  
> 

Make it 3 weeks and give me a place to stay and I will book
my flights tomorrow! :) I always feel like this as winter
approaches in the northern hemisphere ... 

Seriously, I have no objections to the suggested location.

Mike, can you think of any possible local funding sources
and/or host organizations?

\start
Date: Tue, 22 Nov 2005 03:59:30 -0500
From: Tim Daly
To: Bill Page
Subject: re: Cast = pretend in Spad/Aldor?

The example

> (1) -> I:Integer
>                                                 Type: Void
> (2) -> F:Float:=1.0
> 
>    (2)  1.0
>                                                 Type: Float
> (3) -> I := F pretend Integer
> 
>    (3)  1()

'pretend' is only for system-internal use.  it basically says: i KNOW
the exact internal representation of this thing so trust me. But here
is the exact internal rep of 1.0 (at some level)

(1) -> )lisp trace |pf2Sex|
(2) -> 1.0
  1> (|pf2Sex| ((|float| (|posn| (0 "1.0" 1 1 "strings") . 0)) . "1.0e0"))
  <1 (|pf2Sex| ((|$elt| (|Float|) |float|) 1 0 10))

   (2)  1.0
                                                                  Type: Float
(3) -> 1
1
  1> (|pf2Sex| ((|integer| (|posn| (0 "1" 1 1 "strings") . 0)) . "1"))
  <1 (|pf2Sex| 1)

   (3)  1
                                                        Type: PositiveInteger

so you're lying to Axiom and it shows.

pretend is used in algebra code when you've created a primitive domain
representation that has an exact representation of another domain as
a lisp object. So you can do things like (from outform.spad)

          sex := interpret(packageTran(ncParseFromString(s)$Lisp)$Lisp)$Lisp
          sCheck := car(car(sex))
          if (sCheck=sexfloat) = true then
             f := (cdr cdr sex) pretend Float
          else
             if integer?(cdr sex) = true then
                f := (cdr sex) pretend Integer
                f::F
             else
                error "Non-numeric value"

notice that you've actually grabbed the output of a lisp function 
(thus the calls to $Lisp) and are manipulating it to find the
exact representation of the algebra object. if you use pretend
you MUST understand the underlying lisp representations.

you'll also note that this makes it hard to move the axiom algebra
off of lisp and onto aldor. aldor needs to have the exact representation
that axiom uses which implies that aldor would have to have a lisp-like
internal data representation. so first you have to create a common lisp
in aldor then ....

this was the design issue with an aldor C implementation that i most
strongly disagreed with. as long as you don't try to cross the 
aldor-axiom internal representations nothing will break. an aldor
rewrite of the spad compiler in common lisp would not have this issue.

in theory you COULD rewrite this into aldor if you moved the whole
system but you'd have to have primitives like CAR which understood
and could manipulate the underlying code for the domain as data.

this is why lisp wins as an implementation language because the
program==data duality allows this. i don't know how to rip and
tear a C program as data. how do you get the "first statement"
out of a C function, replace it with a different statement and
then execute it? the parenthesis syntax matters.

\start
Date: Tue, 22 Nov 2005 13:24:00 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: B#

Hello,

C Y wrote:
> --- Bill Page wrote:
> 
>> I think of B# as first of all generalizing 'Expression' so that
>> all of the computations that a user is likely to want to do can
>> be done entirely within that one domain - just as if they were
>> calculating using Maple or Mathematica. And then simplifying
>> the syntax and semantics of the Spad language so that it always
>> implicitly refers to this generalized domain. And there is some
>> syntactic sugar to add to make this all a little sweeter.
> 
> Sounds like a good way to make Axiom more friendly for new (and casual)
> users.

Yes, indeed.


>> But rather than Spad, I would argue that Aldor is actually a
>> better choice for the B# implementation language. We have
>> discussed elsewhere on this list the fact that Aldor has 
>> already been used to write a parser for the Aldor language. 
>> Doing something similar for the B# language seems completely 
>> feasible to me.
> 
> I agree this is a job for a high level language, but I would suggest
> that the Aldor licensing situation be clarified before implementing B#
> in it.  (I promise I'll move to axiom-legal if the discussion around
> this heats up ;-).

We all agree on Aldor as an implementation language, but we have to wait 
because of licencing problems. It's a pity. :-(

>> If we use Aldor (or Spad) to implement B#, then a user would
>> start using B# by invoking the read-eval-print-loop within the
>> B# package something like this:

Oh, I favour B# written in Aldor and also to clean up Axiom.
As far as I understand the sources the Axiom Interpreter does not only 
execute (ehm interpret) the commands that are given to it, it also adds 
some mathematical knowledge (especially coercions). Seems to be a good 
idea to make Axiom more user friendly in the past, but with B#, the 
knowledge should be in a BNatural domain/package. It's some guessing 
anyway and all would be concentrated in BNatural.

However, even B# should not make assumptions out of blue sky, if it 
cannot find a function coerce: Float -> Boolean or something similar in 
the underlying Algebra library, it should simply reject it and not look 
for intermediate functions coerce: Float -> Integer, coerce: Integer -> 
Boolean. Shouldn't the library offer enough functionality already?

The library Algebra that comes with Aldor offers a type ExpressionTree, 
which if made a bit richer could serve as the representation of the USER 
type. Furthermore, usually each mathematical type offers functions

extree: % -> ExpressionTree       --export of ExpressionType
eval: ExpressionTree -> Partial % --export of Parsable

I wouldn't mind if the coercion from one type to another on the 
interaction level takes a bit longer. If the user wants to have it 
faster he should take on the burden with the types and write an 
appropriate function (if there isn't already such a function in the 
library--which would have been found by BNatural).

\start
Date: Tue, 22 Nov 2005 13:35:18 -0500
From: Bill Page
To: Tim Daly
Subject: re: Cast = pretend in Spad/Aldor?

Tim,

When I read through your email I have to admit that I felt a
little depressed. I hope I don't sound too "condescending" by
saying this, but I felt like your email moves the discussion
of types in Axiom backwards to nearly "high school programming"
levels, not even computer science 101... :(

In fact I do feel peculiar about taking this role (again). Although
I have been working with computer algebra systems of a long time
(mostly Maple) and programming for much longer, I was never part
of the original group of Axiom developers and I know that you were,
yet lately I always seem to be presumptuously defending positions
that I imagine some of the other members of that team might have
held.

But we do have to start some where I guess. I will try to explain
below what I mean and see where we can go from here.

On November 22, 2005 4:00 AM Tim Daly (root) wrote:

> 
> The example
> 
> > (1) -> I:Integer
> >                                                 Type: Void
> > (2) -> F:Float:=1.0
> > 
> >    (2)  1.0
> >                                                 Type: Float
> > (3) -> I := F pretend Integer
> > 
> >    (3)  1()
> 
> 'pretend' is only for system-internal use.  it basically says:
> i KNOW the exact internal representation of this thing so trust
> me.

No that is not true. 'pretend' (at least as embedded in the rep
and per macros) is essential for programming domains in the Axiom
library. This is the kind of programming that we would expected
an experienced mathematician to do - not a system-internals
programmer.

Axiom is supposed to support strong static typing. This would not
be true of it where necessary to know exact internal representations
in order to use fundamental simple constructs in the language.

When I write 'F pretend Integer' it should mean something that
can be expressed in the Axiom programming language without
reference to the internal representation.


> But here is the exact internal rep of 1.0 (at some level)
> 
> (1) -> )lisp trace |pf2Sex|
> (2) -> 1.0
>    1
> (|pf2Sex| ((|float| (|posn| (0 "1.0" 1 1 "strings") . 
> 0)) . "1.0e0"))
>   <1 (|pf2Sex| ((|$elt| (|Float|) |float|) 1 0 10))
> 
>    (2)  1.0
>                                                               
>                                Type: Float
> (3) -> 1
>    1
>   1> (|pf2Sex| ((|integer| (|posn| (0 "1" 1 1 "strings") . 0)) . "1"))
>   <1 (|pf2Sex| 1)
> 
>    (3)  1
>                                  Type: PositiveInteger
> 
> so you're lying to Axiom and it shows.

I don't know what you mean by "lying to Axiom". Programming is
not a dialogue where one party can lie to another. In the example
above I gave the Axiom interpreter a simple command which is
clearly allowed in the language. In fact, we should easily be
able to agree that this kind of command, although not this
specific example, is essential to the way we use Axiom.

> 
> pretend is used in algebra code when you've created a primitive
> domain representation that has an exact representation of
> another domain as a lisp object.

No where have I ever read anything in reference to 'pretend'
about representations as lisp objects or even that the algebra
code must always have a representation as a lisp object. I think
defining the semantics of a high level language in terms of it's
specific implementation is wrong, at least in those cases where
it is avoidable. It is like saying in order to program in C I have
to know the specific machine architecture on which I am going to
compile my program.

In a related thread with Gaby on this list we have been discussing
the (cast) operator in the C programming language. Gaby has
pointed out (my paraphrase) that use of this construct has been
standardized in such a way as to remove (where possible) any need
to rely on knowledge of the internal representation.

Certainly in other high level languages related to Spad such as
Haskell and ML, there is seldom if any need to know the details
of internal representations.

But still in the algebra code, 'pretend' is necessary for the
implementation of the representation of objects in a domain. This
representation is "internal to the object" but it is not (or at
least should not require knowledge of) the internal representation
of Spad itself. The internal representation of the object should
be presented in terms of Spad data structures. The use of
'pretend' in this case allows a mapping from internal Spad data
structures to a new external object in the domain being defined.
All of this should be done *within* the Spad language itself.

> So you can do things like (from outform.spad)
> 
>           sex := 
> interpret(packageTran(ncParseFromString(s)$Lisp)$Lisp)$Lisp
>           sCheck := car(car(sex))
>           if (sCheck=sexfloat) = true then
>              f := (cdr cdr sex) pretend Float
>           else
>              if integer?(cdr sex) = true then
>                 f := (cdr sex) pretend Integer
>                 f::F
>              else
>                 error "Non-numeric value"
> 
> notice that you've actually grabbed the output of a lisp function 
> (thus the calls to $Lisp) and are manipulating it to find the
> exact representation of the algebra object. if you use pretend
> you MUST understand the underlying lisp representations.
>

I do not agree. This is the Spad programming language. It is not
Lisp. When I make a package call to a function in $Lisp I expect
the result to be something well defined at the Spad level. It is
the responsibility of these functions to prepare their output in
a manner that is compatible with Spad. And in the example that you
give above, this is that case. The type of the variable 'sex' is a
domain in Spad called SExpression. The things you can do with
SExpression are defined by that domain in Spad.

The constructions '(cdr cdr sex) pretend Float' and
'(cdr sex) pretend Integer' seem to me to be poorly chosen
in this usage since as you say, the correct interpretation
depends on a detailed knowledge of the implementation of
Float and Integer. These values should be defined instead
in terms of operations available within the Float, Integer
and SExpression domains themselves. In fact there is an
operation 'integer' with SExpression so we can write

  f := integer(cdr sex)

and there is no need to know the implementation details.
Similarly there is an operation 'float' which might be used
to produce the desired here although it's output is of type
'DoubleFloat' not Float.
 
> you'll also note that this makes it hard to move the axiom
> algebra off of lisp and onto aldor. aldor needs to have the
> exact representation that axiom uses which implies that aldor
> would have to have a lisp-like internal data representation.
> so first you have to create a common lisp in aldor then ....
>

No! That is completely incorrect. In discussions with Peter
Broadbery it is clear that Aldor uses a different internal
representation that Spad for most (all?) Axiom data structures
but that does not prevent us from writing Axiom library code
using both Spad and Aldor. It does mean however that hidden
internally there must be some conversion between representations.
That is done by the Aldor interface that Peter has provided.
When this is working properly it should never be necessary for
an Axiom library programmer to know anything about these
different representations.
 
> this was the design issue with an aldor C implementation that
> i most strongly disagreed with. as long as you don't try to
> cross the aldor-axiom internal representations nothing will
> break. an aldor rewrite of the spad compiler in common lisp
> would not have this issue.

I think perhaps that you do not understand clearly what is
involved in the abstraction of types in high level languages
so your argument with the use of C to implement Aldor is quite
misplaced.

> 
> in theory you COULD rewrite this into aldor if you moved the
> whole system but you'd have to have primitives like CAR which
> understood and could manipulate the underlying code for the
> domain as data.

Having operations like CAR is natural if you have a domain
which implements lisp-like list structures - as Axiom does.
There is nothing unusual and special about this.

> 
> this is why lisp wins as an implementation language because
> the program==data duality allows this. i don't know how to
> rip and tear a C program as data. how do you get the "first
> statement" out of a C function, replace it with a different
> statement and then execute it? the parenthesis syntax matters.
> 

Functions are not first order objects in C but they are in
other languages. If there was a good reason to implement an
operation like "get the first statement" from a function then
this could be done in many other languages besides lisp. But
usually there are much better and more rigorous ways to
manipulate functions as data without resorting to a procedural
statement but statement representation. The ability to do
that naturally is relatively unique to lisp but it does not
give lisp any particular advantage of languages like Haskell.

... and here we are back at the language war-ing again ...

<sigh>

\start
Date: Tue, 22 Nov 2005 20:38:26 +0000
From: Peter Broadbery
To: Bill Page
Subject: Re: Cast = pretend in Spad/Aldor?  (was: B#)

On Mon, 2005-11-21 at 14:27 -0500, Bill Page wrote:
> On November 21, 2005 12:59 PM Gaby wrote:
> 
> > 
> > "Bill Page" writes:
> > 
> > | On November 20, 2005 11:50 PM Gaby wrote:
> > | > | 
> > | > | We have mentioned before on this list the very good article
> > | > | 
> > | > | http://en.wikipedia.org/wiki/Datatype
> > | > | 
> > | > 
> > | > That is interesting but the link above is confused to start
> > | > with. I quote: 
> > | > 
> > | >    An example of the absence of strong typing is a C cast 
> > | >    gone wrong; if you cast a value in C, not only is the
> > | >    compiler required to allow the code, but the runtime is
> > | >    expected to allow it as well.
> > | > 
> > ...
> 
> Actually, perhaps I should simply concede that the above
> article is not particularly good, and I will be glad to do
> so if you can recommend a better alternative that defines
> these terms more accurately.
> 
> But really I don't want to be spending a lot of time arguing
> about the merits of the C programming language on this list.
> What I would really like to think about is strong static typing
> in the context of Axiom, specifically in Spad and in Aldor.
> 
> There is one very important type-related construction in
> Spad and in Aldor that looks as if it might make them "weak"
> in the sense in which the author of the above quote implies
> the use of cast in the C language makes it weak. That is the
> use of 'pretend'.
> 
> It is pretty clear in the following example that the Axiom
> interpreter does something odd:
> 
> (1) -> I:Integer
>                                                 Type: Void
> (2) -> F:Float:=1.0
> 
>    (2)  1.0
>                                                 Type: Float
> (3) -> I := F pretend Integer
> 
>    (3)  1()
>                                                 Type: Integer
> 
> ------
> 
> Yet the ability to use 'pretend' is critical to the concept
> of representation in the construction of Axiom domains.
> 
> For a perhaps overly abstract discussion of this see:
> 
> http://wiki.axiom-developer.org/RepAndPer
> 
> So my question is: Does this feature of the Spad and Aldor
> languages actually make them "weakly typed"?
> 

I'd say it does, at least for some definitions of the term.  I'd very
quickly follow up by saying 'but who cares', since it's obvious that
they occasionally have their uses (as Tim suggests, system level code,
and where you just know that your domain is implemented in a particular
way).  I've rarely seen a need for the second use, but one persons app
level could be system level to someone else, I guess.

For Rep, rep and per, I (personally) believe they should have been
language primitives, except that add-inheritance confuses the issue a
little. They should definitely be thought of as primitive.

There is an idea of adding a third operation 'per?', defined by the
programmer which tests if an object of type Rep is really a member of %,
and would be called immediately before each 'per' operation.  I'd hate
to be forced to write it each time though.

\start
Date: Tue, 22 Nov 2005 16:47:01 -0500
From: Tim Daly
To: Bill Page
Subject: re: Cast = pretend in Spad/Aldor?

ultimately i think the issue comes down to this: i'm a primitivist
by nature and expect programmers, like myself, to know EXACTLY what
the machine will execute when i use high level languages like spad,
lisp, or haskell. (and to send email by tapping on the correct wire pair
in an ethernet cable with a battery.) i "understand clearly what is
involved in the abstraction of types in high level languages" as i've
implemented several languages, 4 of which were sold commercially and
i've been involved in endless language "feature" discussions.

your approach to programming "from the other end of the telescope"
tends to view the machine as a distant abstraction and expect
programming languages to properly support their abstractions in all
their various nuances. thus, you expect that

   type-thing :=               other-type-thing
   type-thing := (cast)        other-type-thing
   type-thing := (coerce)      other-type-thing
   type-thing := thing pretend other-type-thing

to "do the right thing" and i tend to run (disassemble) to figure
out what it ACTUALLY does on the machine. i'd have to be smoking
guano in a batcave before i'd even think to code

    int-i := (cast int) float-f

as this is fundamentally "lying" to the machine. (cast a 747 to
an "airplane" and you can land it on any runway). 

if you approach a language with the expectation of "closed semantics"
(that is, everything you write is well defined) you'd expect the
previous statement to mean something. by nature i tend to expect
languages to have "open semantics" where not everything you can
write has meaning and a native speaker of the language will only
write meaningful statements.

so when you write:

> Axiom is supposed to support strong static typing. This would not
> be true of it where necessary to know exact internal representations
> in order to use fundamental simple constructs in the language.
> 
> When I write 'F pretend Integer' it should mean something that
> can be expressed in the Axiom programming language without
> reference to the internal representation.


we're never going to see eye-to-eye because there is a telescope
between us. your view is clearly correct but only if you start with
your programming assumptions. Axiom DOES support strong static typing
but (at least in my view) it isn't a closed semantics language so
sometimes you have to know the internals. in your view the primitive
domains would export operations that hide the implementation,
fully support the abstractions and have closed semantics.

i can build facade patterned structures using agent-based communication
among network distributed backends in a functional programming language 
specified with full denotational semantics but i still need to know what's 
on the call stack.

ultimately you want to appeal to the documentation to see what a language
construct means. i kneel before the altar of the machine and see what it
does.

   A pretend B

is "knowledge-based lying" in my view and strong static typing in yours.

our axioms of what it means to program differ and thus our views differ.

t

ps. i liked programming in high school. the wang mini with the
hand-punched "toaster" card reader kicked ass. :-)

\start
Date: Wed, 23 Nov 2005 07:51:46 +1000
From: Mike Thomas
To: Bill Page
Subject: RE: axiom conference funding?

Hi Bill.

| Seriously, I have no objections to the suggested location.

It would certainly make a change to have something like this away from
the traditional haunts of the computer algebra community ie the North
Atlantic fringe.

Bear in mind that a flight to Austalia from those parts of the world is
usually about 24 hours worth of travel and hideously expensive.


| Mike, can you think of any possible local funding sources
| and/or host organizations?

I'm not an expert on organising conferences nor an academic, however,
there are three Universities in Brisbane with mathematics departments of
varying sizes:

  http://www.maths.uq.edu.au/

  http://www.maths.qut.edu.au/

  http://www.cit.gu.edu.au/maths/

All three of those universities also have the usual IT, engineering and
science faculties any of which could be regarded as potential sponsors.

An interesting series of questions is:

  Does any reader of this mailing list other than myself come from:

     Brisbane?

     South-east Queensland?

     Australia?

Cheers

Mike Thomas



\start
Date: Tue, 22 Nov 2005 17:50:21 -0500
From: Tim Daly
To: Mike Thomas
Subject: Re: axiom conference funding?

Charles Miller is at the University of Melbourne.
Being an american by training I have no idea where that is but it's certainly
"down under".

\start
Date: Tue, 22 Nov 2005 14:12:41 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: re: Cast = pretend in Spad/Aldor?

--- Tim Daly wrote:

> ultimately i think the issue comes down to this: i'm a 
> primitivist by nature and expect programmers, like myself, to
> know EXACTLY what the machine will execute when i use high
> level languages like spad, lisp, or haskell. (and to send 
> email by tapping on the correct wire pair in an ethernet cable
> with a battery.)

While I agree this is sometimes necessary in practice, isn't the whole
idea of high level languages to avoid this necessity?

> i "understand clearly what is involved in the abstraction of
> types in high level languages" as i've implemented several 
> languages, 4 of which were sold commercially and i've been 
> involved in endless language "feature" discussions.
> 
> your approach to programming "from the other end of the 
> telescope" tends to view the machine as a distant abstraction
> and expect programming languages to properly support their
> abstractions in all their various nuances. thus, you expect
> that
> 
>    type-thing :=               other-type-thing
>    type-thing := (cast)        other-type-thing
>    type-thing := (coerce)      other-type-thing
>    type-thing := thing pretend other-type-thing
> 
> to "do the right thing" and i tend to run (disassemble) to
> figure out what it ACTUALLY does on the machine.

I thought this might be a good use for unit testing actually - defined
the "right thing" on a per-abstraction basis and verify that it
actually does happen on a per-machine basis?

> Axiom DOES support strong static typing but (at least in my
> view) it isn't a closed semantics language so sometimes you
> have to know the internals. in your view the primitive
> domains would export operations that hide the implementation,
> fully support the abstractions and have closed semantics.

At least at the Spad/Aldor level, isn't this desirable?  Or would
BNatural be the logical level for "bullet-proofing" in this fashion?
 
> ultimately you want to appeal to the documentation to see what
> a language construct means. i kneel before the altar of the 
> machine and see what it does.

I always thought what made the most sense was to clearly define the
behaviors an abstraction needs to function properly as part of the
documentation, and have a way in the program to test that those
assumptions actually ARE valid.  That gives you not just assumption of
valid abstractions but verified valid abstractions, and allows one to
work at the abstracted level with confidence.

I suspect I'm missing something though - typing related issues are way
beyond me :-/.

> ps. i liked programming in high school. the wang mini with the
> hand-punched "toaster" card reader kicked ass. :-)

Heh - I always like the idea of punch cards.  They seem a lot more
durable than any of our electronic storage methods, even if their data
density per kilogram is a tad low.

\start
Date: Tue, 22 Nov 2005 19:33:59 -0500
From: Bill Page
To: Cliff Yapp
Subject: re: Cast = pretend in Spad/Aldor?

But, but, ... he sputters ...

I thought Axiom was supposed to be a system for mathematicians,
or at least a system to do mathematics by computer. From that
point of view there is barely a telescope long enough to hide
the dirty details of the entrails of the computer. ;)

On November 22, 2005 5:13 PM C Y wrote:
> 
> --- Tim Daly (root) wrote:
> 
> > ultimately i think the issue comes down to this: i'm a 
> > primitivist by nature and expect programmers, like myself,
> > to know EXACTLY what the machine will execute when i use
> > high level languages like spad, lisp, or haskell.
> ...
>
> While I agree this is sometimes necessary in practice,
> isn't the whole idea of high level languages to avoid this
> necessity?

I agree completely that that is the purpose of high level
languages. In fact, I doubt that one can really successfully
program in a high level language like Spad or Haskell unless
you first accept the abstraction. Even in Lisp (which from
my point view is more like an assembler language for a high
level machine) one must accept the abstraction of the Lisp
"machine". It doesn't do you much good at all to know that
once upon a time on some machine or other (IBM 704 actually)
CAR actually "means" Contents of Address Register and CDR
actually "means" Contents of Decrement Register.

> > ... 
> > your approach to programming "from the other end of the 
> > telescope" tends to view the machine as a distant abstraction
> > and expect programming languages to properly support their
> > abstractions in all their various nuances.

The "telescope" analogy isn't too bad, but a better one might
be something like a "ladder". The machine is not viewed
as a "distant abstraction", quite the contrary, it is the
foundation on which the ladder rests. When I am at the top of
the ladder I only need to know that it is still there acting
as the foundation, but I do not care any longer what it is
made of. But yes I do expect programming languages to properly
and fully support all of the abstractions upon which they are
based. I don't have the time or energy to always climb down
the ladder each time I need another nail for the shingles. :)

> thus, you expect that
> > 
> >    type-thing :=               other-type-thing
> >    type-thing := (cast)        other-type-thing
> >    type-thing := (coerce)      other-type-thing
> >    type-thing := thing pretend other-type-thing
> > 
> > to "do the right thing"

Well, I do expect the "right thing" to at least be well
defined, even better if it serves some useful purpose. I
think this is the approach taken in almost all high level
languages.

> > and i tend to run (disassemble) to figure out what it
> > ACTUALLY does on the machine.
> 
> I thought this might be a good use for unit testing actually -
> defined the "right thing" on a per-abstraction basis and
> verify that it actually does happen on a per-machine basis?

Yes, that's ok for me. But I tend to think of it in more
abstract mathematical terms. When I define abstract data
types I think in terms of the abstract algebra that is
generated by the operators on these structures. It is how
these operators behaviour - the rules that they should obey
that defines this object from an external point of view.
The job of unit testing is to verify that the representation
of this abstract algebra in terms of operations at the
machine level is "faithful". The concept of a faithful
representation is one that is used frequently in mathematics,
e.g. in group theory.

In principle, disassembly is one of the steps in the proof
that a representation is faithful. But that can only be done
if we first have a rigorous definition of the abstraction
itself.

> 
> > Axiom DOES support strong static typing but (at least in my
> > view) it isn't a closed semantics language so sometimes you
> > have to know the internals. in your view the primitive
> > domains would export operations that hide the implementation,
> > fully support the abstractions and have closed semantics.
> 
> At least at the Spad/Aldor level, isn't this desirable?  Or
> would BNatural be the logical level for "bullet-proofing" in
> this fashion?

I think you were right on the first answer. From my point of
view it is absolutely essential at the Spad/Aldor level if we
are in any correct sense to think of these a programming languages
in and of themselves, independent of a specific implementation.

I think the issue at the level of BNatural is rather different.
BNatural is built on top of the Spad/Aldor level and the Axiom
library. It's purpose is to bridge the gap between our intuitive,
ambiguous natural language based expression of mathematical ideas
and their rigorous definition in the Axiom library. But even
here there is a need for the domains that underlie the single
ExpressionTree domain of BNatural to hide their implementation
details from the higher level.

>  
> > ultimately you want to appeal to the documentation to see
> > what a language construct means. i kneel before the altar
> > of the machine and see what it does.
> 
> I always thought what made the most sense was to clearly define
> the behaviours an abstraction needs to function properly as part
> of the documentation, and have a way in the program to test that
> those assumptions actually ARE valid.  That gives you not just
> assumption of valid abstractions but verified valid abstractions,
> and allows one to work at the abstracted level with confidence.
>

Again I completely agree with you. The documentation *must* come
first. In fact since this is mathematics that we are talking about,
the documentation almost always consists of a well developed body
of knowledge and a set of formal theorems. We want to know first
of all whether what we wrote in Spad/Aldor properly represents
this mathematical knowledge - or at least clearly delineate the
range over which this representation is accurate. Doing this does
not involving knowing exactly what the machine does at a low
level.
 
> I suspect I'm missing something though - typing related issues
> are way beyond me :-/.

As far as I am concerned you have a good grasp of at least the
basic ideas. :)

> 
> > ps. i liked programming in high school. the wang mini with the
> > hand-punched "toaster" card reader kicked ass. :-)
> 
> Heh - I always like the idea of punch cards.  They seem a lot
> more durable than any of our electronic storage methods, even
> if their data density per kilogram is a tad low.
> 

You wouldn't say that if you had to load the "dog eared" stack
of the Fortran II compiler (consisting of something like a 1000
punch cards) in front of your painfully punched and re-punched
first 10 line Fortran program for what seems like the 100th time
(not counting the 6 dozen or so miss-feeds) before getting the
reward of 50 newly machine punched cards which you then had to
append along with your single data input card to the back of the
stack of the Loader program (consisting of another 500 or so dog
eared cards), just to get the damned IBM 1401 to compute the
square root of a number ... all at about 4:00 AM in the morning,
because during the day the machine was actually used for more
serious computing.

Believe me, it was a big advance when I got to University and
we actually could do all this during the day using paper tape. ;)

\start
Date: Tue, 22 Nov 2005 23:10:05 -0500
From: Bill Page
To: list
Subject: RE: Cast = pretend in Spad/Aldor?  (was: B#)

On November 22, 2005 3:38 PM Peter Broadbery wrote:

> Bill Page wrote:
> > 
> > Yet the ability to use 'pretend' is critical to the concept
> > of representation in the construction of Axiom domains.
> > 
> > For a perhaps overly abstract discussion of this see:
> > 
> > http://wiki.axiom-developer.org/RepAndPer
> > 
> > So my question is: Does this feature of the Spad and Aldor
> > languages actually make them "weakly typed"?
> > 
> 
> I'd say it does, at least for some definitions of the term.
> I'd very quickly follow up by saying 'but who cares', since
> it's obvious that they occasionally have their uses (as Tim
> suggests, system level code, and where you just know that
> your domain is implemented in a particular way).  I've rarely
> seen a need for the second use, but one persons app level
> could be system level to someone else, I guess.

I would be interested to learn of any examples where this sort
of use of 'pretend' was essential, i.e. where it can not be
replaced with some operations defined on the underlying domains.

> 
> For Rep, rep and per, I (personally) believe they should have
> been language primitives, except that add-inheritance confuses
> the issue a little. They should definitely be thought of as
> primitive.

My reaction on first meeting rep and per in Aldor was the same.
It seemed strange to me that these where not primitives. Peter,
do you know of anything written about Rep, rep and per that
discusses these issues? The only mention I have found so far is
in the Aldor documentation itself.

>From the definition of rep and per as macros:

  macro {
        rep x == x @ % pretend Rep;
        per r == r @ Rep pretend %;
  )

it is seems clear that this use of 'pretend' is always type-safe
since objects of type % are necessarily constructed from something
of type Rep, so the only thing that 'pretend %' does is to "hide"
the internal structure of the Rep object, where as 'pretend Rep'
merely recovers it.

So it seems likely that if we could drop pretend from Aldor and
make rep and per primitives, then Aldor could then be truly
said to be strongly typed (i.e. type-safe in terms of it's own
semantics). Does this make sense?

> 
> There is an idea of adding a third operation 'per?', defined
> by the programmer which tests if an object of type Rep is
> really a member of %, and would be called immediately before
> each 'per' operation.  I'd hate to be forced to write it each
> time though.
> 

By "is a member of %" do you really mean "is a representation
of an object of type %"? I am not sure how one could use 'per?'
since the representation is supposed to be purely internal to
the domain, right?. That some Rep is a representation of some
% presumably depends on the internal logic of the domain. So
would 'per?' act as some kind of assertion to be checked at
run time?

I am fascinated by this construct but I do not feel that I
understand it very well yet in spite of seeing how it is used.
If anyone has recommendations for further research along this
line, I am "all ears".

\start
Date: Wed, 23 Nov 2005 00:01:08 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] Ann: ALLPROSE / Suggestions

Dear Bill,

Page, Bill wrote:
> On Wednesday, November 16, 2005 7:53 AM Ralf Hemmecke wrote:
>> Martin Rubey wrote:
>> 
>>> * it would be very useful - if not necessary - if you provided a 
>>> one page summary on how to use ALLPROSE for the average 
>>> A{ldor,xiom} programmer, separate from the complete 225 pages 
>>> documentation.
>> I thought there is enough overview material at the beginning of the
>>  ALLPROSE documentation, but seemingly one easily gets distracted
>> by the vast amount of documentation of all the make files so that a
>>  short section "How to work with ALLPROSE" is certainly a good
>> idea.
>> 
> 
> I have read quickly through the 225 pages of documentation of 
> ALLPROSE and I have to agree with Martin. A short concise summary in 
> 1 or 2 pages that gives the basic ideas, motivation and a few **very 
> simple** examples is necessary. The examples can be just partial 
> examples - only enough to get the basic idea across.

Unfortunately, I must agree with you. But as it is written somewhere in
the ALLPROSE documentation, it is not yet finished. I wanted to get it
out so that people see that I am working on something. I do not claim
ALLPROSE to be THE solution to all problems. And if the Axiom developers
find it difficult, who else could find it easy?

I will work on all of your suggestions, but don't expect something much
better already tomorrow.

> Although I am strongly in favor of this literate programming 
> methodology, if there is one criticism that I would make against it 
> is it easily leads to excessive verbosity and it does very little to 
> help with documentation organization.

Sad but only half true. ALLPROSE contains 2 parts of documentation.
1) It documents itself, and
2) it documents a library project.

Since 1) is not important anymore if you know how to work with ALLPROSE,
you can turn it of and are left with part 2). After all, ALLPROSE is
meant to help library programmers. Its own documentation only comes as
an additional part.

But in some way you are right. ALLPROSE still lacks a guideline of how
to write good literate programs. I am not quite sure whether I can
provide this, since I am new to this paradigm myself.

> In many cases it is often more difficult for the author of a complex 
> program (or any scientific work for that matter) to write 2 really 
> good pages about the work than it is to write 200 pages. As a result
>  the documentation can get so verbose that it becomes inaccessible 
> even though it is complete.

But clearly, literate programming does not help at all here. LP is just
a tool that enables people to write documents instead of programs.
Unfortunately, the reality is the other way round. Most people find it
difficult to change their minds from programs to documents. So it would
be good to provide many more examples like dhmatrix.spad.

>> However, I am not quite sure what you would like to see in such a 
>> section. What do you think is missing from Section 6 "How to Start
>>  a New Project"?
> 
> I find it is rather difficult to say precisely what is missing 
> because I think that really is not the problem. The issue is more the
>  way the information is presented. The best analogy that I can think 
> of is something like this: suppose that you have been invited to 
> create a one page advertisement for the ALLPROSE product that will be
>  placed in a technical journal such as the mythical "IEEE Advanced 
> Computer Algebra Systems". What do you want to say to the experienced
>  readers who are not likely to take more than 10 minutes at most to 
> review your advertisement?

So you think Section 5 (5.1-5.3) is not good enough? Maybe I should
really turn this into an advertisment.

> I think this is the sort of thing that should appear at the beginning
>  of an literate programming documentation - a sort of technical 
> executive summary.
> 
>>> * maybe you can connect yourself with Eitan Gurari to enable 
>>> automatic translation to html/mathml via tex4ht?
>> Thank you, I would really be happy if somebody could assist me with
>>  that translation.
> 
> What problems are you having using tex4ht? Have you tried any of the 
> other packages for converting LaTeX to HTML?

I think, if any at all then tex4ht would be the only possibility.
latex2html does not understand several things of my style files.
Unfortunately, I have never worked with tex4ht. I only learnt that there
are several different commands. "tex4ht myalps.tex" runs through and
produces an .html file, but that is not really what I would expect, it
is just a text file, no HTML tags, nothing. If somebody gives me an
example of a command line that I could execute, I'd appreciate it.

man tex4th

comes with so many programs and options that I don't know where to start.

\start
Date: Wed, 23 Nov 2005 01:43:00 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: allprose missing file

root wrote:
> despite the missing .sty file it works!
> this is cool. we have to import this technology into axiom.

If you like.

> of course it appears that you've licensed it under GPL and
> we'd need your permission to include it under a second BSD
> license.

It took me quite a long time to read through several of the open source
licenses. I knew that someone would ask me about BSD, since I somehow
tend to support Axiom. Nevertheless, I have chosen GPL, since somehow I
don't like the idea that someone could take my code, add some little
detail, close the source, and sell everything without giving me one cent
or at least the source of his/her extensions. That is a bit unfair in my
eyes. So the current answer to releasing ALLPROSE under BSD is no.

However, that does not mean that Axiom cannot use ALLPROSE. In fact, I 
did on purpose only announce ALLPROSE on aldor-l and not (yet) on the 
axiom-developer mailing list, since I could not see that it would be 
useful out of the box. There are quite a few things missing, I guess.
Don't worry too much about the license. I am a friend of Axiom.

ALLPROSE is a tool for Aldor library-writers and hopefully becomes
some kind of standard for an Axiom Journal.

ALLPROSE in Axiom would only be important for the part that lives under
the algebra directory. Even there it cannot yet be used since that code
is SPAD code which is not supported by ALLPROSE.

But let me tell you what I did last weekend.
I experimented with the .pamphlet files. Happyly, they have a quite
regular structure. Most of them look like,

\documentclass{article}
\usepackage{axiom}
\begin{document}
\title{...}
\author{...}
\maketitle
\begin{abstract}
...
\end{abstract}
...
\end{document}

That is fine, or nearly fine, say. ALLPROSE tries to produce one
document, so all pamphlet files are handed over to noweave as one big
file so that cross-referencing can be done via hyperref. In fact, also
noweb adds some cross-references and indices.
(Unfortunately I had to remove the -index switch for noweave since LaTeX 
runs out of memory with it.)

What I could provide for Axiom would be to extract several parts of
ALLPROSE, so that an Axiom developer could produce a hyperlinked .dvi
file (with "inverse search" enabled, ie, clicking on the .dvi file opens
your favourite editor and jumps immediately to the place in the
corresponding .pamphlet file).

I've already produced such a .dvi file for several subdirectories. If 
somebody is interested in the corresponding (preliminary) code, just 
drop me a mail.

Those Makefiles and .sty files are extracted from ALLPROSE and work on 
an unmodified axiom--main--1--patch-46. I am not sure whether this is 
near to what you want, Tim.

Anyway, I have to use a script to remove
\documentclass, the whole preample and \begin{document}, \end{document}
I wonder why they are there anyway. Noweb could produce a wrapper.
Well, you might say, some files use \usepackage{graphicx} or
\documentclass{book}. That's true, but you can count those files with 
your two hands.

Books are special by their very nature, but as for ordinary code files
in pamphlet format I would like to suggest either

1) no \documentclass, no preample, no \(begin|end){document} or
2) Wrapper in the file in the form
\documentclass{article}
\usepackage{axiom}
\begin{document}
...
\end{document}

I'd prefer 1) because the wrapper for 2 could be done by the "document"
script. If the "document" script will be needed any longer anyway.

It is absolutely vital for me in order to produce ONE big document that
the preample of all files is identical (which is nearly the case anyway
in the current .pamphlet files of axiom--main--1--patch-46). What do you
think?

I looked through the sources but could not find a guideline of how 
.pamphlet files should look like. Obviously, Tim, your intention was 
that each file is a separate document (a complete LaTeX file with added 
<<CHUNKS>>). Where is the pamphlet structure described?

When I designed ALLPROSE I have chosen the extension .nw as a standard. 
If the _one_ DVI file approach of ALLPROSE with all the hyperlinking it 
enables is interesting for Axiom, and the LaTeX-wrapper of the .pamphlet 
files goes away, I would consider to change .nw into .pamphlet. But this 
would mean a little restriction to the general source files (which would 
not include books).

\start
Date: Wed, 23 Nov 2005 00:04:24 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Aldor-l] Ann: ALLPROSE / Suggestions

Dear Bill,

> In many cases it is often more difficult for the author of a complex
> program (or any scientific work for that matter) to write 2 really
> good pages about the work than it is to write 200 pages. As a result
>  the documentation can get so verbose that it becomes inaccessible
> even though it is complete.

But clearly, literate programming does not help at all here. LP is just
a tool that enables people to write documents instead of programs.
Unfortunately, the reality is the other way round. Most people find it
difficult to change their minds from programs to documents. So it would
be good to provide many more examples like dhmatrix.spad.

> I think this is already this is happening in the Axiom documentation.

I recently looked at many of the pamphlet files. Most of them lack their
documentation. But you are right in some respect that Axiom is already
too complex. For example, I wanted to learn more about the building
process of Axiom. I cannot say that I really found that at the time I
was looking for it. I realised that pamphlet files have to be translated
into .dvi files via the "document" command. But that does not help very
much since one does not get the global picture.

So I started at the top-level Makefile. Honestly, that is much to
complicated.


>>> * I really want that your documentation format becomes a
>>> replacement for Axioms Hypertex format.
>> Well, I would be happy if ALLPROSE goes this way.

> I presume that what is most appealing to Martin about the ALLPROSE
> approach is the automatic "lifting" of the +++ comments from the
> source code to the documentation and vice-versa. The availability of
> this documentation coupled with the ability to navigate the algebra
> hierarchy of parents, ancestors, children, descendants (including
> those domains that might be their own grandfathers :) and packages is
> very important for both users and developers.

What I can do with just the source code is quite limited. It is
basically similar to what can be seen in the libaldor and libalgebra
documentation. However, sometimes, I'd like to see ALL the functions,
that a domain provides without clicking from one category to the other.
One needs compiler support for that. The aldordoc.sty in ALLPROSE is
only there to suggest a _convention_ of how the +++ comments should be
structured.

> I like the way you have used hyperref to embed a lot of this
> information directly into the documentation. I think some of this
> could be quite easily grafted onto the pamphlet files that Tim uses
> now for the Axiom source code, although right now none of the
> sections of these pamphlet files is automatically generated.

Are you just speaking of the algebra subdirectory? Or do you mean also
other dirs?

> Or can you imagine this going the other way: Can ALLPROSE as it
> exists now really play the same role as pamphlet files in Axiom? I
> worry that too much is "hard coded" into the way that the ALLPROSE
> makefiles are structured to be easily adaptable to Axiom. Is that
> right?

I don't quite understand, what exactly you would like ALLPROSE to do.
Of course its goal is to support library writers for the Aldor language,

\start
Date: Wed, 23 Nov 2005 11:55:34 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Cast = pretend in Spad/Aldor?  (was: B#)

Bill Page wrote:
> On November 22, 2005 3:38 PM Peter Broadbery wrote:
> 
>> Bill Page wrote:
>>> Yet the ability to use 'pretend' is critical to the concept
>>> of representation in the construction of Axiom domains.
>>>
>>> For a perhaps overly abstract discussion of this see:
>>>
>>> http://wiki.axiom-developer.org/RepAndPer

Just one comment to this website. I don't think that
rep: % -> Rep
could be seen as a forgetful functor. Surely, it forgets the signatures 
of % (ie, its category), but it also introduces a structure.

Take, for example,

IntegerGroup: Group == add {
   Rep == Integer;
   (x: %) + (y: %): % == per(rep x + rep y);
   ...
}

Here rep forgets the Group structure of % and gains (at least) the Ring 
structure of Integer.

>>> So my question is: Does this feature of the Spad and Aldor
>>> languages actually make them "weakly typed"?
>>>
>> I'd say it does, at least for some definitions of the term.
>> I'd very quickly follow up by saying 'but who cares', since
>> it's obvious that they occasionally have their uses (as Tim
>> suggests, system level code, and where you just know that
>> your domain is implemented in a particular way).  I've rarely
>> seen a need for the second use, but one persons app level
>> could be system level to someone else, I guess.
> 
> I would be interested to learn of any examples where this sort
> of use of 'pretend' was essential, i.e. where it can not be
> replaced with some operations defined on the underlying domains.

I think it was nowhere essential. If a programmer thinks for some 
efficiency reasons to pretend that some A is some particular type B that 
might come from the fact that A does not provide certain functions. I 
would argue, that in this case A is simply not rich enough. So the 
design was not the best from the beginning.

See also
   http://www.aldor.org/docs/HTML/chap7.html#6

I cannot remember that I have seen pretend being used in some essential 
way. Anyway, if it were essential, then I'd rather like to have all such 
domains defined at a very low level and forbid "pretend" for all users 
who are going to implement mathematics.

There is some use of "pretend" though, where I could not do without it.
bar(F: Field): F == ...
foo(R: Ring): () == {
   ...
   if R has Field then result:= bar(R);
                  else result:= 1;
   result;
}

The Aldor compiler should be able to compile such code, but the current 
implementation does not realize in all cases that in bar(R) the R is 
actually a field, so I'd have to say "bar(R pretend Field)". However, 
that is a weakness of the compiler and not a necessity for "pretend".
(P.S.: I don't claim that this particular piece of code above does not 
compile, but I remember that I experienced cases, where the structure 
was similar.)

>> For Rep, rep and per, I (personally) believe they should have
>> been language primitives, except that add-inheritance confuses
>> the issue a little. They should definitely be thought of as
>> primitive.

I fully agree, although I don't quite understand that part "except that 
add-inheritance confuses the issue a little". But I think the language 
designers were minimalistic. Instead of introducing two primitives "rep" 
and "per", they introduced only "pretend".

>> There is an idea of adding a third operation 'per?', defined
>> by the programmer which tests if an object of type Rep is
>> really a member of %, and would be called immediately before
>> each 'per' operation.  I'd hate to be forced to write it each
>> time though.

How can they be different anyway? To me it is even not completely clear 
whether Rep is a language primitive or not. I don't remember that I have 
read anything about Rep being a primitive, furthermore, some time ago 
one would have written "Rep ==> Integer" and not "Rep==Integer" as it is 
suggested now. See
http://www.aldor.org/docs/HTML/chap7.html#8 (subsection Representation).

> since the representation is supposed to be purely internal to
> the domain, right?.

And this is an advantage. Let's look at the Aldor libraries. There are 
two variants, libaldor.al and libaldord.al. The second one is a "DEBUG" 
version and sometimes quite handy to find bugs. Take, for example, the 
implementation of PritiveArray in both libraries.

It starts like this.

PrimitiveArray(T:Type): PrimitiveArrayType T == add {
   import from Machine;
#if DEBUG
   Rep == Record(sz:Z, data:Arr);
   local size(x:%):Z == {import from Rep;
     empty? x => 0; rep(x).sz
   }
   local arr(x:Arr, n:Z):% == {import from Rep;
     zero? n => empty; per [n,x]
   }
   local data(x:%):Arr == {
     import from Rep;
     empty? x => (nil$Pointer) pretend Arr;
     rep(x).data;
   }
#else
   Rep == Arr;
   local data(x:%):Arr	  == rep x;
   local arr(x:Arr, n:Z):% == per x;
   local arr(x:Arr):%	  == per x;
#endif
   array(p:Pointer, n:Z):% == arr(p pretend Arr, n);
   pointer(a:%):Pointer == data(a) pretend Pointer;

So if you are going to use PrimitiveArray later in your program, you 
could hardly use "pretend" until you happen to have the sources and know 
the dependency on the DEBUG flag.

But for the outside world both are indistinguishable, because they are 
both of PrimitiveArrayType(T).

Oh, I am just realizing here is also a "pretend Arr". That is low level 
programming and completely hidden in PrimitiveArray. But this also looks 
like efficiency considerations. If there were a better documentation of 
Arr available then it would certainly be unecessary. But then maybe Arr 
would use "pretend" or is completely implemented in C or so. One has to 
start somewhere, so consider PrimitiveArray as a primitive type and 
never worry about "pretend" anymore when building on it.

\start
Date: Wed, 23 Nov 2005 04:24:15 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke, Tim Daly,
Subject: re: allprose missing file

--- Ralf Hemmecke wrote:

> What I could provide for Axiom would be to extract several 
> parts of ALLPROSE, so that an Axiom developer could produce a
> hyperlinked .dvi file (with "inverse search" enabled, ie, 
> clicking on the .dvi file opens your favourite editor and 
> jumps immediately to the place in the corresponding .pamphlet
> file).

That's an interesting idea - sort of an "editing" mode for dvi
production.
 
> Anyway, I have to use a script to remove \documentclass, the 
> whole preample and \begin{document}, \end{document} I wonder 
> why they are there anyway. Noweb could produce a wrapper.
> Well, you might say, some files use \usepackage{graphicx} or
> \documentclass{book}. That's true, but you can count those 
> files with your two hands.

While this is currently true, I expect that as more pamphlet files are
filled out with content the latex used will grow more complex.  In my
current version of the units and dimensions tex file I already have
some relatively uncommon logic in place, and while most of what I have
might be acceptable as general logic for pamphlet files there will
undoubtedly be some point at which this no longer makes sense.

> Books are special by their very nature, but as for ordinary 
> code files in pamphlet format I would like to suggest either
> 
> 1) no \documentclass, no preample, no \(begin|end){document} or
> 2) Wrapper in the file in the form
> \documentclass{article}
> \usepackage{axiom}
> \begin{document}
> ...
> \end{document}
> 
> I'd prefer 1) because the wrapper for 2 could be done by the
> "document" script. If the "document" script will be needed any
> longer anyway.

Actually, I was working myself on evolving an approach to this that
allowed both article and book generation.  The approach I came up with
was something like this:

book.tex.pamphlet
<packagename>_preamble.tex.pamphlet
<packagename>_content.tex.pamphlet

book.tex would be the toplevel logic for making all of the algebra
pamphlets into one large book (or maybe we could do bookvol9,
bookvol10, etc. instead but the basic idea would be the same) using
input to pull in all relevent content files, and the _preamble.tex
files would contain the logic needed for each pamphlet file to become a
standalone dvi/pdf file and an input call to the content file.  the
_content.tex files would contain the actual content, which one would be
able to include in either book or article form without change.

I have created a working trial version of this, but I hesitated to
introduce it since a) there aren't really enough literate pamphlet
files for a full fledged test yet and b) I didn't know if this
variation would be deemed too complex to be of interest.  It's big
payoff is being able to make a book seemlessly without changing any
files except perhaps book.tex.pamphlet but it does mean any pamphlet
authors will have to separate their logic into two files, at least on
cvs commit.
 
> It is absolutely vital for me in order to produce ONE big 
> document that the preample of all files is identical (which is
> nearly the case anyway in the current .pamphlet files of 
> axiom--main--1--patch-46). What do you think?

I agree that most preambles in article form will be similar but I think
the _content.tex idea is a cleaner workaround for this than any kind of
scripting or other approach.

I haven't dug into allprose so I'm not quite sure what benefits Tim is
looking to use and how - I'll have to go back over that discussion. 
But I just wanted to mention the LaTeX approach to pamphlets in both
article and book form, to see if it generates any interest.

\start
Date: Wed, 23 Nov 2005 08:29:49 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [Aldor-l] Ann: ALLPROSE / Suggestions

Ralf,

On November 22, 2005 6:01 PM you wrote:
> ...
> Bill Page wrote:
> > 
> > What problems are you having using tex4ht? Have you tried 
> > any of the other packages for converting LaTeX to HTML?
> 
> I think, if any at all then tex4ht would be the only possibility.
> latex2html does not understand several things of my style files.

You are probably right although I have found some of the others
more tolerant of legacy LaTeX/TeX coding, tex4ht is by far the
most complete.

> Unfortunately, I have never worked with tex4ht. I only learnt 
> that there are several different commands. "tex4ht myalps.tex"
> runs through and produces an .html file, but that is not really
> what I would expect, it is just a text file, no HTML tags, nothing.
> If somebody gives me an example of a command line that I could
> execute, I'd appreciate it.
> 
> man tex4th
> 
> comes with so many programs and options that I don't know 
> where to start.
> 

The web site http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn.html
shows the usual command line for tex4ht. It is just

  % htlatex  filename

tex4ht itself is embedded somewhere down inside the script and
is not normally called directly by the user.

Let me know what you get with this command.

\start
Date: 23 Nov 2005 16:39:09 +0100
From: Martin Rubey
To: Francois Maltey
Subject: Problems compiling modified Spad file under debian

Dear Francois,

I copy axiom-developer, since there might be more help available there. In any
case, you are using a rather old copy of axiom. I think you should upgrade...

http://packages.debian.org/unstable/math/axiom

use the unstable branch! If you run into trouble, please mail again...

Martin

Francois Maltey writes:

> )co manip.spad
>  
>    Compiling AXIOM source code from file 
>       /home/fmy/Axiom/locallib/manip.spad using old system compiler.
>  
>    >> System error:
>    The function INITIALIZE-PREPARSE is undefined.
> 
> protected-symbol-warn called with (NIL)

> $ cat /proc/version
> Linux version 2.6.8-1-686 (joshk@trollwife) 
>   (gcc version 3.3.5 (Debian 1:3.3.5-2)) #1 Thu Nov 25 04:34:30 UTC 2004
> 
> $ axiom -noht
> GCL (GNU Common Lisp)  2.6.6 CLtL1    Jan 18 2005 00:13:38
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
> 
> Use (help) to get some basic information on how to use GCL.
>                         AXIOM Computer Algebra System
>                    Version: Axiom 3.0 Beta (February 2005)
>               Timestamp: Monday February 21, 2005 at 20:01:15

\start
Date: Wed, 23 Nov 2005 17:49:53 +0100
From: Francois Maltey
To: list
Subject: Re: Problems compiling modified Spad file under debian

Hello, 

I try to compile my first axiom package and I get problems :

Martin helps me and I install theses debian packages :

dpkg -l | grep axiom

ii  axiom                              20050901-3
                 A general purpose computer algebra system: m
ii  axiom-databases                    20050901-3
                 A general purpose computer algebra system: g
ii  axiom-doc                          20050901-3
                 A general purpose computer algebra system: d
ii  axiom-graphics                     20050901-3
                 A general purpose computer algebra system: g
ii  axiom-graphics-data                20050901-3
                 A general purpose computer algebra system: g
ii  axiom-hypertex-data                20050201-1
                 A general purpose computer algebra system: h
ii  axiom-source                       20050901-3
                 A general purpose computer algebra system: s
ii  axiom-test                         20050901-3
                 A general purpose computer algebra system: r


I run axiom -noht and I get :


GCL (GNU Common Lisp)  2.6.7 CLtL1    Oct 12 2005 23:38:25
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
                        AXIOM Computer Algebra System
                     Version: Axiom 3.9 (September 2005)
              Timestamp: Thursday October 13, 2005 at 20:30:30
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------


I try to compile again a spad file :

cp /usr/share/axiom-20050901/src/algebra/manip.spad ~/Axiom/locallib
cd ~/Axiom/locallib
axiom -noht

Then I try twice to compile the local manip.spad and get 2 errors :
What is my mistake ?

(1) -> )co manip
   Loading /usr/lib/axiom-20050901/autoload/apply.
   Loading /usr/lib/axiom-20050901/autoload/c-doc.
   Loading /usr/lib/axiom-20050901/autoload/c-util.
   Loading /usr/lib/axiom-20050901/autoload/profile.
   Loading /usr/lib/axiom-20050901/autoload/category.
   Loading /usr/lib/axiom-20050901/autoload/compiler.
   Loading /usr/lib/axiom-20050901/autoload/define.
   Loading /usr/lib/axiom-20050901/autoload/functor.
   Loading /usr/lib/axiom-20050901/autoload/info.
   Loading /usr/lib/axiom-20050901/autoload/iterator.
   Loading /usr/lib/axiom-20050901/autoload/modemap.
   Loading /usr/lib/axiom-20050901/autoload/nruncomp.
   Loading /usr/lib/axiom-20050901/autoload/package.
   Loading /usr/lib/axiom-20050901/autoload/htcheck.
   Loading /usr/lib/axiom-20050901/autoload/xruncomp.
   Compiling AXIOM source code from file manip.spad using old system
      compiler.
   Loading /usr/lib/axiom-20050901/autoload/parsing.
   Loading /usr/lib/axiom-20050901/autoload/bootlex.
   Loading /usr/lib/axiom-20050901/autoload/def.
   Loading /usr/lib/axiom-20050901/autoload/fnewmeta.
   Loading /usr/lib/axiom-20050901/autoload/metalex.
   Loading /usr/lib/axiom-20050901/autoload/metameta.
   Loading /usr/lib/axiom-20050901/autoload/parse.
   Loading /usr/lib/axiom-20050901/autoload/postpar.
   Loading /usr/lib/axiom-20050901/autoload/postprop.

   >> System error:
   Cannot open the file /usr/lib/axiom-20050901/autoload/postprop.

(1) -> )co manip
   Compiling AXIOM source code from file manip.spad using old system
      compiler.

   >> System error:
   The function INITIALIZE-PREPARSE is undefined.

(1) ->

\start
Date: Wed, 23 Nov 2005 12:42:24 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: allprose missing file

> That is fine, or nearly fine, say. ALLPROSE tries to produce one
> document, so all pamphlet files are handed over to noweave as one big
> file so that cross-referencing can be done via hyperref. In fact, also
> noweb adds some cross-references and indices.


one document per file was the original approach and was forced on me
because there was so much to convert. the new plan is to break the
system into volumes. on my machine i currently have 10 book volumes:

vol 1:  tutorial
vol 2:  programming
vol 3:  reference
vol 4:  developers guide
vol 5:  interpreter
vol 6:  compiler
vol 7:  browser
vol 8:  hyperdoc
vol 9:  algebra
vol 10: numerics

i'm trying to follow your lead by applying some of your ideas (though
not your code) to the other volumes. i've introduced the index and
the hyperref mechanisms. if we get it done right then it should be
possible to put all of the axiom documentation online with a call
to tex2html or some such tool.

the algebra volume is going to be different from the others but i'm
still pondering the structure.

> I looked through the sources but could not find a guideline of how 
> .pamphlet files should look like. Obviously, Tim, your intention was 
> that each file is a separate document (a complete LaTeX file with added 
> <<CHUNKS>>). Where is the pamphlet structure described?

there isn't a guideline yet. it's evolving as i discover and steal new
ideas (like allprose).  there is a new section in the developer's
guide being drafted about how to write and maintain axiom within the
volume structure.

\start
Date: Wed, 23 Nov 2005 11:57:23 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Cast = pretend in Spad/Aldor?

On November 23, 2005 5:56 AM Ralf Hemmecke wrote:
> ...
> >> Bill Page wrote:
> >>> http://wiki.axiom-developer.org/RepAndPer
> 
> Just one comment to this website. I don't think that
> rep: % -> Rep could be seen as a forgetful functor.
> Surely, it forgets the signatures of % (ie, its category),
> but it also introduces a structure.

For reference, here is a link to my current favourite online
source:

http://en.wikipedia.org/wiki/Forgetful_functor

Remember that a functor is a morphism (mapping) from one
category (in the sense of category theory) to another. In Axiom
these categories are implemented as domains.

A functor does not actually add or delete structure as such.
The structure remains present in the underlying categories. In
the case of a forgetful functor the image of the source category
in the target looses some of the structure that was present in
the source, but that does not preclude the target category from
having more structure of a different kind.

So what I am suggesting is that 'rep' is a forgetful functor that
is faithful but not full. It can tell us for example that an
object of Float i.e. an Axiom floating point number, corresponds
to a object of record(mantissa:Integer, exponent:Integer) but
certainly the domain record(mantissa:Integer, exponent:Integer)
as a product category has additional structure.

> 
> Take, for example,
> 
> IntegerGroup: Group == add {
>    Rep == Integer;
>    (x: %) + (y: %): % == per(rep x + rep y);
>    ...
> }
> 
> Here rep forgets the Group structure of % and gains (at 
> least) the Ring structure of Integer.

I think this is a good example. The forgetting part is quite
simple, but the really important job is actually done by 'per'.
Here this functor maps the + operation of Integer into the +
operation of IntegerGroup.

> > 
> > I would be interested to learn of any examples where this sort
> > of use of 'pretend' [as system level code] was essential, i.e.
> > where it can not be replaced with some operations defined on
> > the underlying domains.
> 
> I think it was nowhere essential. If a programmer thinks for
> some efficiency reasons to pretend that some A is some
> particular type B that might come from the fact that A does
> not provide certain functions. I would argue, that in this case
> A is simply not rich enough. So the design was not the best
> from the beginning.

I agree.

> 
> See also
>    http://www.aldor.org/docs/HTML/chap7.html#6
>

Here is read:

"Primitive conversions

The language provides one primitive type conversion operation:
pretend. A ``pretend'' expression is used to lie about the type
of a value.

      Expr pretend Type

causes the value computed by Expr to be treated as though it were
of type Type. pretend is the only operator in Aldor which is not
type-safe: using pretend can lead to unchecked type errors which
only reveal themselves when a program is executed. For this reason
pretend should be used with caution. For example, one could use
``pretend'' to examine the bit-level representation of data when a
type does not provide operations to do so.

Two additional type-safe operations are defined in Aldor using
pretend: rep and per. These operators convert between the public
and private views of a type, and are discussed in section 7.8."

--------

Thank you! That is exactly the kind of statement I was looking
for. I guess I must have read that as one time or other but had
forgotten where.

> I cannot remember that I have seen pretend being used in some 
> essential way. Anyway, if it were essential, then I'd rather like
> to have all such domains defined at a very low level and forbid
> "pretend" for all users who are going to implement mathematics.
> 
> There is some use of "pretend" though, where I could not do 
> without it.
>
> bar(F: Field): F == ...
> foo(R: Ring): () == {
>    ...
>    if R has Field then result:= bar(R);
>                   else result:= 1;
>    result;
> }
> 
> The Aldor compiler should be able to compile such code, but the
> current implementation does not realize in all cases that in
> bar(R) the R is actually a field, so I'd have to say
> "bar(R pretend Field)".
> However, that is a weakness of the compiler and not a necessity
> for "pretend". (P.S.: I don't claim that this particular piece
> of code above does not compile, but I remember that I experienced
> cases, where the structure was similar.)

I agree that such a case would be a compiler error. The use of
'pretend' here is clearly type-safe. I wonder if we can find
examples of this in the Axiom Spad code?

> 
> >> For Rep, rep and per, I (personally) believe they should have
> >> been language primitives, except that add-inheritance confuses
> >> the issue a little. They should definitely be thought of as
> >> primitive.
> 
> I fully agree, although I don't quite understand that part 
> "except that add-inheritance confuses the issue a little".
> But I think the language designers were minimalistic. Instead
> of introducing two primitives "rep" and "per", they introduced
> only "pretend".

Since 'pretend' is manifestly type-unsafe and considerably more
dangerous than what is required for 'rep' and 'per', it seems to
me that this design in not consistent with the goals of Aldor.

> 
> >> There is an idea of adding a third operation 'per?', defined
> >> by the programmer which tests if an object of type Rep is
> >> really a member of %, and would be called immediately before
> >> each 'per' operation.  I'd hate to be forced to write it each
> >> time though.
> 
> How can they be different anyway? To me it is even not completely
> clear whether Rep is a language primitive or not. I don't remember 
> that I have read anything about Rep being a primitive, furthermore,
> some time ago one would have written "Rep ==> Integer" and not 
> "Rep==Integer" as it is suggested now. See
> http://www.aldor.org/docs/HTML/chap7.html#8 (subsection 
> Representation).
>

Since 'rep' need not be full (i.e. not surjective) there may be
objects and operations of 'Rep' that do not correspond to any
object or operation of %. But my argument was that we need only
be concerned about those object of 'Rep' that are manipulated
internally by the logic of domain %. I think correct logic
implies that these objects will all be in the image of 'rep'.

As you said earlier, it seems that 'rep', 'per' and 'Rep' where
not chosen by the Aldor language designers as primitive but
rather defined by a macro, just as in Spad. As far as I know for
the purposes of the 'rep' and 'per' macros you can still use the
notation "Rep ==> Integer" interchangeably with "Rep==Integer",
is this not the case?

If the concept of representation in domains was to be made a
primitive in the Aldor language, then I think one might wish
for more syntactic sugar than provided at present. For example
why not a construct like:

  IntegerGroup: Group == add {
     internal Integer;

     (x: %) + (y: %): % == ::(x:: + y::);
     ...
  }

where we must distinguish infix (conversion), prefix ('per') and
postfix ('rep') use of the type symbol :: But I have to admit I
have not spent much time thinking about the consequences of such
notational change. Probably there are better ideas.

> > since the representation is supposed to be purely internal to
> > the domain, right?.
> 
> And this is an advantage. Let's look at the Aldor libraries. 
> There are two variants, libaldor.al and libaldord.al. The second
> one is a "DEBUG" version and sometimes quite handy to find bugs.
> Take, for example, the implementation of PritiveArray in both
> libraries.
> 
> It starts like this.
> 
> PrimitiveArray(T:Type): PrimitiveArrayType T == add {
>    import from Machine;
> #if DEBUG
>    Rep == Record(sz:Z, data:Arr);
>    local size(x:%):Z == {import from Rep;
>      empty? x => 0; rep(x).sz
>    }
>    local arr(x:Arr, n:Z):% == {import from Rep;
>      zero? n => empty; per [n,x]
>    }
>    local data(x:%):Arr == {
>      import from Rep;
>      empty? x => (nil$Pointer) pretend Arr;
>      rep(x).data;
>    }
> #else
>    Rep == Arr;
>    local data(x:%):Arr	  == rep x;
>    local arr(x:Arr, n:Z):% == per x;
>    local arr(x:Arr):%	  == per x;
> #endif
>    array(p:Pointer, n:Z):% == arr(p pretend Arr, n);
>    pointer(a:%):Pointer == data(a) pretend Pointer;
> 
> So if you are going to use PrimitiveArray later in your program,
> you could hardly use "pretend" until you happen to have the 
> sources and know the dependency on the DEBUG flag.
>

For sure. There are probably many other cases where one might
want to change the internal representation of some domain without
affecting any other code in the library. The indiscriminate use
of 'pretend' could make this dangerous.
 
> But for the outside world both are indistinguishable, because 
> they are both of PrimitiveArrayType(T).
> 
> Oh, I am just realizing here is also a "pretend Arr". That is 
> low level programming and completely hidden in PrimitiveArray.
> But this also looks like efficiency considerations. If there were
> a better documentation of Arr available then it would certainly
> be unnecessary. But then maybe Arr would use "pretend" or is
> completely implemented in C or so. One has to start somewhere,
> so consider PrimitiveArray as a primitive type and never worry
> about "pretend" anymore when building on it.
> 

I do not understand the use of 'pretend' in the statements

   array(p:Pointer, n:Z):% == arr(p pretend Arr, n);
   pointer(a:%):Pointer == data(a) pretend Pointer;

above. Also the meaning of type Pointer also worries me.
Could you explain this or refer me to the appropriate section
of the Aldor documentation?

Ralf, thank you very much for your comments!

\start
Date: Wed, 23 Nov 2005 18:10:05 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: allprose missing file

Hi Tim,

> one document per file was the original approach and was forced on me
> because there was so much to convert. the new plan is to break the
> system into volumes. on my machine i currently have 10 book volumes:

> vol 1:  tutorial
> vol 2:  programming
> vol 3:  reference
> vol 4:  developers guide
> vol 5:  interpreter
> vol 6:  compiler
> vol 7:  browser
> vol 8:  hyperdoc
> vol 9:  algebra
> vol 10: numerics

I like that. Does this mean that these volume would also contain all the 
code? That is exacly what I'd like to see.

> i'm trying to follow your lead by applying some of your ideas (though
> not your code) to the other volumes.

Tim you are referring to the license problem. Well, I did not say that I 
am unwilling to contribute to Axiom (even under BSD). I would be even 
happy to work on that. Don't do everything alone.

> the algebra volume is going to be different from the others but i'm
> still pondering the structure.

I would prefer to have this openly discussed. In particular, the 
structure for an API description (which is aldordoc.sty in ALLPROSE). I 
would not like to invent yet another structure for the documentation. 
There should be a good one and that should be fixed. It's a pity that 
the language designers haven't thought about structuring the +++ 
comments. It is high time NOW. aldordoc.sty is my suggestion.

>> I looked through the sources but could not find a guideline of how 
>> .pamphlet files should look like. Obviously, Tim, your intention was 
>> that each file is a separate document (a complete LaTeX file with added 
>> <<CHUNKS>>). Where is the pamphlet structure described?
> 
> there isn't a guideline yet. it's evolving as i discover and steal new
> ideas (like allprose).

Well, if you like to "steal"... wouldn't it be better to invite me to 
contribute? That would raise the manpower working on Axiom.

\start
Date: Wed, 23 Nov 2005 13:00:48 -0500
From: Tim Daly
To: Cliff Yapp
Subject: re: allprose missing file

CY,

i started a reply to your latex work a while ago but i guess i never
sent the email. broken down to its essence i have objections to 
using conditional code in a latex document. if we start down that
path we end up with the whole "C" define horror show. C introduced
#ifdef and #include .h, both of which have caused endless amounts of
grief in my life. a fair percent of my porting problems revolve around
these seemingly simple ideas which are the root of a lot of evil.
because they are so pervasive at this point everyone seems to think
they are useful. "in the small" they are but once you have a large,
complex system they collapse. 

i know this will turn into another point of controversy but before 
you turn on the flames try following (by hand) the expansion of 
your include files under all possible combination of define flags
and you'll see that it is hopeless.

conditional latex, as monty python used to say, is "right out".

\start
Date: Wed, 23 Nov 2005 13:34:09 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: allprose missing file

> I like that. Does this mean that these volume would also contain all the 
> code? That is exacly what I'd like to see.

yes, each volume subsumes the code for those portions of the system.
i'm gradually "combing" the code into the files.

> Tim you are referring to the license problem. Well, I did not say that I 
> am unwilling to contribute to Axiom (even under BSD). I would be even 
> happy to work on that. Don't do everything alone.

nope. didn't worry about the license. but the code isn't applicable to
most of axiom's documentation because it contains no algebra.

> > the algebra volume is going to be different from the others but i'm
> > still pondering the structure.
> 
> I would prefer to have this openly discussed. In particular, the 
> structure for an API description (which is aldordoc.sty in ALLPROSE). I 
> would not like to invent yet another structure for the documentation. 
> There should be a good one and that should be fixed. It's a pity that 
> the language designers haven't thought about structuring the +++ 
> comments. It is high time NOW. aldordoc.sty is my suggestion.

we did think about it. in fact, i went thru all of the algebra (which
contained almost NO +++ or ++ comments at all and wrote them all into
a common format. i also modified the compiler to complain if you did
not include ++ comments on signatures. blame the cheesy comments on me.
but we were under a lot of time pressure because we were trying to 
finish up axiom, write a book, incorporate NAG's libraries, extending
the browser, rewriting the algebra, making it portable, etc so we
could give it to NAG.

commenting the algebra was a tedious exercise that took a long time
but is ultimately not the best (or a good, or even a useful)
solution. we need to make the latex documentation style such that we
can tag and autoextract the documentation for domains.

axiom used to have an "autodoc" facility that generated javadoc-like
information for the algebra. attached you'll find a few memos from
the pre-NAG days. 

i started to write a program that would regenerate the autodoc/javadoc
kind of domain information. the (non-)program is also attached.
autodoc only worked on VM/370 and was never ported. i have a copy
of the paper document which i can scan so you can see what it used
to do.

> 
> >> I looked through the sources but could not find a guideline of how 
> >> .pamphlet files should look like. Obviously, Tim, your intention was 
> >> that each file is a separate document (a complete LaTeX file with added 
> >> <<CHUNKS>>). Where is the pamphlet structure described?
> > 
> > there isn't a guideline yet. it's evolving as i discover and steal new
> > ideas (like allprose).
> 
> Well, if you like to "steal"... wouldn't it be better to invite me to 
> contribute? That would raise the manpower working on Axiom.

take the lead on the algebra book. each book has a standard preamble
so they all have the same "look and feel". i'll send that under a
separate file and explain the parts. (doing that turns out to be
the same work as writing the section on how to write axiom books).

==================================================================
"autodoc memo"
==================================================================
index to files: (file type boot unless specified)
 dinfo  - this file contains the functions that collect
          the information for the tex document and the
          hypertex pages.  The information is taken mostly
          from the lisp-libs, but some info comes from
          $constructorDataTable. once the information
          is found it is stored on hash table.
          in order for the hypertex browse to operatewith resonable
          speed, some of the hash table must be precomputed
          and stored as one file on disk, that is reread
          the first time a user starts up browse.
dhtex -   this file contains the functions needed to create
  the ht pages dynamically.
search -   this file creates the functions that take
   patterns and find the matching constructors, operations
   and keywords (using wildcards and case insensitive completion)
keyword - this small file contains the functions needed
   to separate the keywords out of the comments, and
   shove them appropriately into the hash table.
dtex  - this file formats the information into a file
   that can be latexed into a hard document
   its top level function in driver which takes
   the names of the constructors that we want the document of.
   ex driver('Aggregate, 'Integer, 'Matrix).
   driver can also be called with a "driverFile".
   i have been using "algebra files j" as my driver file.
   it lists the source files that contain the constructors
   that we wish to get an autodoc of.
   to do this give the command driver( ['driverFile,:'"ALGEBRA FILES J"])
   if a driver file is to be used then the function
   generatedatabaseforharddoc() must be invoked.
pfile - contains the functions needed to look at a driver file
  and extract the necessary info.
texidx - this was written by bob sutor.
  /index commands can be inserted in to latex text and
  then when the file is latexed, and IDX file is created which
  contains the info needed to make an index.
  the function processTeXIndexFile(input idx file, output tex file)
  takes the idx file and creates a tex file which can then be
  appended to the end of the actual autodoc tex file (just before
  the last line). then when the tex file is latexed againg,
  it will contain the index.
doctools - contains various functions that are needed
  by the other files and must be read in for anything to work
vmcut - contains functions that work on lispvm
rtcut - defindes the same functions to work on common lisp for unix
rtcut1.lisp  -this is a supplement to rtcut.boot it must also be
   read. As an added bonus, this file has a function that
   reads in all the needed bbin files on the rt , and
   warms up browse by reading the precomputed hash table
   from the disk.  (hash.lisp). the function is called
   helpstart(). (i hate capitalization).
 
----------
 
-----------
how to use
 browse -  see softdoc memo
 autodoc - see harddoc memo









==================================================================
"harddoc" -- instructions for axiom's javadoc-like automatic documenter
==================================================================
heres how you get autodoc tex manuals:
 
(this has only been run on vm) it would take forever on the rt
i only have had the patience to run it on vm at night or weekends

--disk boogie
gime newspad  k b
gime *yourname* A C  -- c or anywher free
--now you may want to copy some of your files from
--your regular disk (now c) to A ..like spadprof input
                                 .. or  profile xedit
gime tdisk 50 a
newspad nruntime
 
-> )read doctools boot j )quiet
-> )read dinfo    boot j )quiet

-> )read dtex     boot j )quiet
-> )read pfile    boot j )quiet
-> )read vmcut    boot j )quiet
 
---> )bo generatedatabaseforharddoc()
---> )bo driver  ['driverFile, : '"DOCFILS FILES J"]
--     --this means use DOCFILS FILES J as the list of files that
--     --contain the source files of the desired constructors
--     --DOCFILS FILES J contains ALL files (I hope) for
--     --the current system
-- 
--if you only want an autodoc for a subset of scratchpad
--you may either write  your own autodoc files file, or
--you may enter the constructor names by hand
ex  )bo driver ('Aggregate, 'HomogeneousAggregate, Matrix)
--if your autodoc is relatively small then
--you won't have to do all of the funny stuff
--with temporary disks
!!!!!!!!!!!UPDATE
the current system on vm does not have a file like DOCFILS which 
list the spad files with descriptiions, so i took the file
ITERP EXPOSED 
and got rid of comment lines, and lines with unexposed constructors
and called it HACK LIST. it is on my a disk.


you can make your own list like that and set the variable
$conListFile
to the file name 
example
)bo $conListFile := '"HACK LIST A"

if you call 
)bo tdoc()

then it looks at the $conListFile   to get the list of constructors to 
document.






-> )quit
 
--now you must run tex you must run it
--a couple times (3 to be safe) to get the
--table of contents and index correctly
vmtex  auto tex (quiet latex duplex asif modcut3
vmtex  auto tex (quiet latex duplex asif modcut3
vmtex  auto tex (quiet latex duplex asif modcut3

!!if vmtex reports errors, then you may have tweek the tex file by hand.
vm doesnt let me xedit very large files, so i resorted to ftp ing the 
file to an rt, editing it there and then sending it back.
(the problem i got was due to some constructors in catdef spad.
 where the word axioms appeared in the first column, but wasnt
 followed by an axiom list)


at this point you should have a file AUTO IDX A which must be
processed to be usable sooooo...
 
newspad nruntime
)read TEXIDX BOOT J )quiet
)bo autIdx()
)quit
 
now you should have a file AUTOIDX TEX A
this file must be put in to the file AUTO TEX A just before
the last line.
 
now issue
vmtex  auto tex (quiet latex duplex on modcut
vmtex  attle   tex j (quiet latex duplex on modcut
 
               --sometimes xedit bitches that it doesnt have
               --room to work ifso then you can use different
               --editor (ftp to rt and use vi)
               --or you'll have to tex the index separately
               --as follows:
----edit file
put at the beginning :
\documentstyle[twoside]{report}
\headsep=0in
\oddsidemargin=0in
\evensidemargin=0in
\topmargin=0in
\textwidth=6.5in
\footskip=1in
\footheight=0in
\textheight=8in
\raggedright
\parindent=0in
\begin{document}
--here goes the index
\end{document}
---- vmtex  autoidx tex (quiet latex duplex on modcut3
 
 
if you want you can specify the copy *num* option with the
vmtex commands to get numerous copies.
 
if there are any problems, track me down and shoot me
(just kiddin')
steve gortler
 



==================================================================
autodoc.lisp 
==================================================================
\documentclass{article}
\usepackage{axiom}
\begin{document}
\title{Autodoc}
\author{Tim Daly}
\maketitle
\begin{abstract}
We want to generate the reference information from axiom source
files automatically.
\end{abstract}
\eject
\tableofcontents
\eject
By design the chunk name has 3 fields. 
The first field is one of \{category, domain, package\}.
The second field is the abbreviation.
The third field is the full name.
This routine will return two lists, the first is the list of
abbreviations and the second is the list of full names.

We keep looping until we run out of input, at which point we
throw out of the loop and catch it here.
<<until done>>
  (catch 'done
@
We open the source file
<<open source file>>=
   (with-open-file (in sourcefile)
@
We read each line, trimming off trailing spaces
<<for each line do>>=
    (loop
     (setq expr (read-line in nil 'done))
     (when (eq expr 'done) (throw 'done nil))
     (setq expr (string-trim '(#\space) expr))
@
We look for lines that begin with a chunk name that
starts with package, domain, or category and end with an
equal sign (which indicates a chunk definition).
<<when package domain or category definition>>=
     (when 
      (and (> (length expr) 4)
           (or
            (string= "@<<pa" (subseq expr 0 4))
            (string= "@<<do" (subseq expr 0 4))
            (string= "@<<ca" (subseq expr 0 4)))
           (char= (elt expr (1- (length expr))) #\=))
@
We remove the 3 characters, two $>$ and an $=$ which make up the chunk name.
<<remove the trailing chunk characters>>=
      (setq expr (subseq expr 0 (- (length expr) 3)))
@
We get the third field from the string which is the long name.
<<capture the long name>>=
      (setq point (position #\space expr :from-end t :test #'char=))
@
We get the second field from the string which is the abbreviation.
<<capture the abbreviation>>=
      (setq mark
       (position #\space 
        (string-right-trim '(#\space)
         (subseq expr 0 (1- point))) :from-end t))
      (push (string-trim '(#\space) (subseq expr mark point)) names)))))
@
<<srcabbrevs>>=
(defun srcabbrevs (sourcefile)
 (let (in expr start end names longnames)
<<until done>>
<<open source file>>
<<for each line do>>
<<when package domain or category definition>>
<<remove the trailing chunk characters>>
<<capture the long name>>
      (format t "~a ~a ~a~%" expr point longnames)
<<capture the abbreviation>>
  (values names longnames))))

@
\section{Doit}
<<doit>>
(srcabbrevs "/new/patch38/src/algebra/acplot.spad.pamphlet")

@
\section{Autodoc}
<<autodoc>>=
<<srcabbrevs>>
<<doit>>
@
\section{Makefile}
<<*>>=
TANGLE=/usr/local/bin/NOTANGLE -t8 
WEAVE=/usr/local/bin/NOWEAVE -delay
LISP=/new/patch38/obj/linux/bin/lisp

all: code doc run

code: autodoc.lisp.pamphlet
	@${TANGLE} -Rautodoc autodoc.lisp.pamphlet >autodoc.lisp

doc: autodoc.lisp.pamphlet
	@${WEAVE} autodoc.lisp.pamphlet >autodoc.tex
	@latex autodoc.tex
	@latex autodoc.tex

run: autodoc.lisp
	@cat autodoc.lisp | ${LISP}

remake:
	@${TANGLE} autodoc.lisp.pamphlet >Makefile

@
\eject
\begin{thebibliography}{99}
\bibitem{1} nothing
\end{thebibliography}
\end{document}

\start
Date: Wed, 23 Nov 2005 12:48:05 -0500
From: Bill Page
To: Francois Maltey
Subject: re: Problems compiling modified Spad file under debian
Cc: Camm Maguire

This looks to me like the Debian build of Axiom is a little broken
(missing /usr/lib/axiom-20050901/autoload/postprop?). I recall an
email by Camm to this effect:

http://lists.nongnu.org/archive/html/axiom-developer/2005-11/msg00160.html

apparently you will need at least the -4 debian package update.

On November 23, 2005 11:50 AM Francois Maltey wrote:

> I try to compile my first axiom package and I get problems :
>
> Martin helps me and I install theses debian packages :
>
> dpkg -l | grep axiom
>
> ii  axiom                              20050901-3
> ii  axiom-databases                    20050901-3
> ...
> I try to compile again a spad file :
> 
> cp /usr/share/axiom-20050901/src/algebra/manip.spad ~/Axiom/locallib
> cd ~/Axiom/locallib
> axiom -noht
> 
> Then I try twice to compile the local manip.spad and get 2 errors :
> What is my mistake ?
> 
> (1) -> )co manip
> ...
>    Compiling AXIOM source code from file manip.spad using old system
>       compiler.
> ...
>    Loading /usr/lib/axiom-20050901/autoload/postprop.
> 
>    >> System error:
>    Cannot open the file /usr/lib/axiom-20050901/autoload/postprop.
> 
> (1) -> )co manip
>    Compiling AXIOM source code from file manip.spad using old system
>       compiler.
> 
>    >> System error:
>    The function INITIALIZE-PREPARSE is undefined.
> 

I can not reproduce this problem on the Axiom version of Windows
nor on the version of Axiom on axiom-developer.org built from
patch-45 on RedHat 9.

\start
Date: Wed, 23 Nov 2005 13:19:57 -0500
From: Bill Page
To: Tim Daly, Ralf Hemmecke
Subject: re: allprose missing file

On November 23, 2005 1:34 PM Tim Daly (root) wrote:

>
> Ralf Hemmecke wrote:
> > I like that. Does this mean that these volume would also 
> > contain all the code? That is exacly what I'd like to see.
> 
> yes, each volume subsumes the code for those portions of the
> system. i'm gradually "combing" the code into the files.
> ... 
> > 
> > >> I looked through the sources but could not find a 
> > >> guideline of how .pamphlet files should look like.
> > >> Obviously, Tim, your intention was that each file is a
> > >> separate document (a complete LaTeX file with added 
> > >> <<CHUNKS>>). Where is the pamphlet structure described?
> > > 
> > > there isn't a guideline yet. it's evolving as i discover 
> > > and steal new ideas (like allprose).
> > 
> > Well, if you like to "steal"... wouldn't it be better to 
> > invite me to contribute? That would raise the manpower
> > working on Axiom.
> 
> take the lead on the algebra book. each book has a standard
> preamble so they all have the same "look and feel". i'll send
> that under a separate file and explain the parts. (doing that
> turns out to be the same work as writing the section on how
> to write axiom books).
> 

The "algebra book" seems like a huge project to me - maybe even
90% of the problem of documenting Axiom. I think it is unlikely
that this can be done in one single "book-sized" volume. Maybe
sub-volumes per major mathematical topic?

Anyway, Ralf if you agree to "take the lead" as Tim suggests
and can apply/refine your ALLPROSE technology to this problem,
then I would be very happy to help with this work under your
guidance.

\start
Date: Wed, 23 Nov 2005 12:47:54 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomCommunity] 

Axiom Projects

  One place to discuss major new features of Axiom and other
related issues is the [Axiom Colloquium]. We have collected a list
of some suggested new features in the Axiom [Wish List] and there
are more described in [Summer of Code].

\start
Date: Wed, 23 Nov 2005 12:58:28 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Colloquium] 

  - BNatural

    B# (pronounced B natural) was a non-typed beginner's user
    interface for Axiom proposed by Janks and Trager in their
    1994 paper: "How to Make Axiom into a ScratchPad"

    http://portal.axiom-developer.org/refs/articles/axiom-scratchpad.pdf/view

    BNatural was never implemented because at about the same time
    IBM decided to discontinue Axiom as a research project and turn
    it over to Numerical Algorithms Group to market as a commercial
    product. But a new project has been proposed to attempt to
    implement BNatural using Aldor as an extension of the open source
    version of Axiom.

  - [Imitation As Complement]

    other websites similar to MathAction

  - [Tuples Products And Records]

    How to write f:A->(B,C) in Axiom

  - [Units and Dimensions]

    Discussion on the design of units package for Axiom

  - [Edit this page to add new headings, Save and then
    click ? to add a new topic]

\start
Date: Wed, 23 Nov 2005 13:44:23 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [BNatural] (new) 

A new project has been proposed to attempt to implement BNatural
using Aldor as an extension of the open source version of Axiom.

Look for updates on this project here.

Initial Email Trail

  **On November 19, 2005 2:05 AM Hans Peter Wuermli wrote:**

In "How to Make AXIOM Into a Scratchpad" Jenks and Trager describe
"... a new user interface language ..." for Axiom, which they called
B# ("B natural") in the article.

http://portal.axiom-developer.org/refs/articles/axiom-scratchpad.pdf/view

If it ever had been implemented, it would offer a lot of the 
language elements at least I would have hoped for in the
interpreter interface for Axiom.
 
Does anybody know what ever happened to that project?

**On November 19, 2005 10:05 PM Bill Page wrote:**

The date on this paper, 1994, closely coincides with the time
when IBM decided to close Axiom as a research project and
negotiated with Numerical Algorithms Group to market Axiom as a
commercial product. It is easy to guess that B# might have been
a causality of this transition.

I agree with Peter that B# is probably what a lot of new users
of Axiom are expecting to find. I like most of the design ideas
for the B# language presented by Jenks and Trager in this paper
so I think implementing B# would be a great project to resurrect
for open source Axiom.

Also interesting in this article is mention of the project GAUSS
which was an attempt to provide an Axiom-like type system in Maple
GAUSS is contrasted with B# because Maple is essentially untyped
while B# was an attempt to provide an untyped user environment
within Axiom. As an active Maple developer at that time, I remember
briefly playing with GAUSS and not being particularly impressed.
My point of view has changed a lot since then. I am convinced of
the value of strong type system in Axiom but I find I often miss
the freedom of expression that the untyped environments of Maple,
Mathematical and Maxima provide. B# might very provide the kind
of bridge that Jenks and Trager envisaged in this paper.

Does anyone else have an interest in investigating the possible
implement of B# ?

**On November 21, 2005 1:41 PM C Y wrote:
 
Sounds like a good way to make Axiom more friendly for new 
(and casual) users.
 
I agree this is a job for a high level language, but I would suggest
that the Aldor licensing situation be clarified before implementing B#
in it.  (I promise I'll move to axiom-legal if the discussion around
this heats up ;-).

Bill Page wrote::
 
  What do you think? Is there enough interest in this to declare
  this as an "official" Axiom open source project?

I would say so!  We want users, and Axiom's type system is frequently
cited as a high hurdle for beginners.

I like the idea of starting out in B-natural, and then for advanced
users being able to "drop down" into the current environment when
strong typing becomes a tool rather than a distraction.  The 
full power of Axiom is hidden but when the user wants to expand
they will find the system able to do so.

**On November 22, 2005 7:24 AM Ralf Hemmecke wrote:**

We all agree on Aldor as an implementation language, but we 
have to wait because of licencing problems. It's a pity. :-(

Oh, I favour B# written in Aldor and also to clean up Axiom.
As far as I understand the sources the Axiom Interpreter does 
not only execute (ehm interpret) the commands that are given
to it, it also adds some mathematical knowledge (especially
coercions). Seems to be a good idea to make Axiom more user
friendly in the past, but with B#, the knowledge should be in
a BNatural domain/package. It's some guessing anyway and all
would be concentrated in BNatural.
 
However, even B# should not make assumptions out of blue sky,
if it cannot find a function coerce: Float -> Boolean or something 
similar in the underlying Algebra library, it should simply reject
it and not look for intermediate functions coerce: Float -> Integer,
coerce: Integer -> Boolean. Shouldn't the library offer enough
functionality already?
 
The library Algebra that comes with Aldor offers a type
ExpressionTree, which if made a bit richer could serve as the
representation of the USER type. Furthermore, usually each
mathematical type offers functions::
 
  extree: % -> ExpressionTree       --export of ExpressionType
  eval: ExpressionTree -> Partial % --export of Parsable
 
I wouldn't mind if the coercion from one type to another on the 
interaction level takes a bit longer. If the user wants to have
it faster he should take on the burden with the types and write
an appropriate function (if there isn't already such a function
in the library--which would have been found by BNatural).

\start
Date: Wed, 23 Nov 2005 14:46:15 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [ScratchPad] (new) 

Scratchpad was a computer algebra system developed at IBM
in the early 1970s. Like M&M (Maple and Mathematical) and
other systems today, Scratchpad had one principal
representation for mathematical formulae based on
"expression trees". Its user interface design was
based on a pattern-matching paradigm with infinite
rewriterule semantics, providing what we believe to be
the most natural paradigm for interactive symbolic problem
solving. Like M&M, however, user programs were interpreted,
often resulting in poor performance relative to similar
facilities coded in standard programming languages such
as FORTRAN and C.

Scratchpad development stopped in 1976 giving way to a
new system design that evolved into AXIOM. AXIOM has a
strongly-typed programming language for building a
library of parameterized types and algorithms, and a
type-inferencing interpreter that accesses the library
and can build any of an infinite number of types for
interactive use.

*From: How to Make Axiom into a ScratchPad", Jenks and Trager, 1994.*

\start
Date: Wed, 23 Nov 2005 13:47:19 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: re: allprose missing file

--- Tim Daly wrote:

> CY,
> 
> i started a reply to your latex work a while ago but i guess 
> i never sent the email. broken down to its essence i have 
> objections to using conditional code in a latex document. if
> we start down that path we end up with the whole "C" define 
> horror show. C introduced #ifdef and #include .h, both of 
> which have caused endless amounts of grief in my life. a fair 
> percent of my porting problems revolve around these seemingly 
> simple ideas which are the root of a lot of evil. because they
> are so pervasive at this point everyone seems to think they 
> are useful. "in the small" they are but once you have a large,
> complex system they collapse. 

OK.  Would it be alright if I post an example of what I have done, if
nothing else to outline the issues I would like to address?  I'm all
for better ways to solve them (lord knows I don't know the best ones!)
but I would like to describe what I have done and why, in case there is
any merit in outlining the issues.
 
> i know this will turn into another point of controversy but
> before  you turn on the flames try following (by hand) the
> expansion of your include files under all possible combination
> of define flags and you'll see that it is hopeless.

No flames.  (I hope I haven't been flaming!)  So far I have only three
cases in all - dvi vs. pdf, large margins vs. small, and book vs.
article.  I'm not sure I'm following what you mean by "possible
combination of define flags" - there are only two cases, article and
book.  Each article has its own preamble file, which will probably be a
standard file in 99% of the cases, and the book is responsible for its
own logic.  Maybe I described what I had in mind wrong?

> conditional latex, as monty python used to say, is "right out".

If anyone is interested I can demonstrate what I have done and why -
since I'm no LaTeX expert perhaps I'm approaching it the wrong way, and
I would be quite happy to be educated on the right way :-).

I suppose I'm about due to throw up the latest state of the Units and
Dimensions paper (the non-code part) - it's not done yet but some
progress has been made.  I'll try to get it online maybe Sunday,
depending on the holiday activities.  Since that's also my testbed for
LaTeX it will server two purposes.

Oh, related question - is there a place where I can upload example pdf
and dvi documents? 

\start
Date: 23 Nov 2005 16:57:46 -0500
From: Camm Maguire
To: Bill Page
Subject: re: Problems compiling modified Spad file under debian

Greetings!

Bill Page writes:

> This looks to me like the Debian build of Axiom is a little broken
> (missing /usr/lib/axiom-20050901/autoload/postprop?). I recall an
> email by Camm to this effect:
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2005-11/msg00160.html
> 

Yes please accept my apologies for forgetting about this.  -4 being
uploaded to Debian servers now.  Please let me know if anything else
is amiss.

Take care,


> apparently you will need at least the -4 debian package update.
> 
> On November 23, 2005 11:50 AM Francois Maltey wrote:
> 
> > I try to compile my first axiom package and I get problems :
> >
> > Martin helps me and I install theses debian packages :
> >
> > dpkg -l | grep axiom
> >
> > ii  axiom                              20050901-3
> > ii  axiom-databases                    20050901-3
> > ...
> > I try to compile again a spad file :
> > 
> > cp /usr/share/axiom-20050901/src/algebra/manip.spad ~/Axiom/locallib
> > cd ~/Axiom/locallib
> > axiom -noht
> > 
> > Then I try twice to compile the local manip.spad and get 2 errors :
> > What is my mistake ?
> > 
> > (1) -> )co manip
> > ...
> >    Compiling AXIOM source code from file manip.spad using old system
> >       compiler.
> > ...
> >    Loading /usr/lib/axiom-20050901/autoload/postprop.
> > 
> >    >> System error:
> >    Cannot open the file /usr/lib/axiom-20050901/autoload/postprop.
> > 
> > (1) -> )co manip
> >    Compiling AXIOM source code from file manip.spad using old system
> >       compiler.
> > 
> >    >> System error:
> >    The function INITIALIZE-PREPARSE is undefined.
> > 
> 
> I can not reproduce this problem on the Axiom version of Windows
> nor on the version of Axiom on axiom-developer.org built from
> patch-45 on RedHat 9.

\start
Date: Wed, 23 Nov 2005 18:29:04 -0500
From: Tim Daly
To: Cliff Yapp
Subject: re: allprose missing file

> OK.  Would it be alright if I post an example of what I have done, if
> nothing else to outline the issues I would like to address?  I'm all
> for better ways to solve them (lord knows I don't know the best ones!)
> but I would like to describe what I have done and why, in case there is
> any merit in outlining the issues.

post away. you don't need permission.

> No flames.  (I hope I haven't been flaming!)  So far I have only three
> cases in all - dvi vs. pdf, large margins vs. small, and book vs.
> article.  I'm not sure I'm following what you mean by "possible
> combination of define flags" - there are only two cases, article and
> book.  Each article has its own preamble file, which will probably be a
> standard file in 99% of the cases, and the book is responsible for its
> own logic.  Maybe I described what I had in mind wrong?

i was referring to the C situation. even "stdio.h" branches wildly from
system to system it seems.

> Oh, related question - is there a place where I can upload example pdf
> and dvi documents? 

do you have a userid on axiom-developer.org? we could set up one that
has web access.

\start
Date: Wed, 23 Nov 2005 21:26:26 -0500
From: Bill Page
To: Tim Daly, Cliff Yapp
Subject: re: allprose missing file

On November 23, 2005 6:29 PM Tim Daly (root) wrote:
> ...
> C Y wrote: 
> > Oh, related question - is there a place where I can upload 
> > example pdf and dvi documents? 
> 
> do you have a userid on axiom-developer.org? we could set up
> one that has web access.
> 

A userid on axiom-developer.org is only necessary if you want to
set up your own (virtual) website on axiom-developer.org or to
use the axiom-developer.org server to do development. But it
isn't necessary just to upload files - that is exactly what the
Axiom Portal site is for. Using the portal is much easier than
creating a new web site from scratch.

But if any Axiom developer wants to set up their own website,
I'm all for that too.

To use the Axiom portal for uploading files, just log in to

http://portal.axiom-developer.org

using the user id and password that you chose when you registered.
If you haven't already registered yet then just click 'join' and
chose a new user id and password.

After logging in, click on 'my folder' and then 'add a new item'.
For pdf and dvi files choose the type 'file'. Click 'Browse...'
and select the file on your local system that you want to upload.
Click 'Open', fill in a title, and a description and hit 'Save'.

That's all there is to it. Very easy. Anybody can do it.

There's a lot more you can do with the Axiom Portal but you
don't have to learn it all right away. And I would be very
pleased to answer any questions you have about it. Right now,
in spite of the fact that nearly 70 people have registered to
use the Axiom Portal web site, I think it's potential still
remains quite under utilized.

If for some reason you prefer to work on the Axiom Wiki site
instead of the portal, then it is also very easy to upload files
there. Click 'edit' and look for the 'Upload' box at the bottom
of the page. Use 'Browse...' the same way as on the portal.

For working files and experiments related to Units on Axiom
you can use the page:

http://wiki.axiom-developer.org/SandBoxUnitsAndDimensions

Because it is SandBox, no email notices of changes to the page
will be broadcast to the list.

Once you have something you want to make permanent and advertise
it to others you can do exactly the same thing with the page:

http://wiki.axiom-developer.org/UnitsAndDimensions

Changes made here (including uploaded files) *will* generate
notices to the axiom-developer email list.

\start
Date: Wed, 23 Nov 2005 23:49:18 -0500
From: Tim Daly
To: Bill Page
Subject: re: allprose missing file

Bill,

methinks you could help the axiom portal/sandbox/wiki by doing
what you suggested to ralf. we need a 1-2 page executive overview
of the axiom site. i didn't know about axiom portal's ability to
do uploads or i would have suggested it.

perhaps posting a couple 1-pagers (man pages?) to axiom-developer
would help.

\start
Date: Thu, 24 Nov 2005 13:16:39 +0100
From: Francois Maltey
To: Camm Maguire
Subject: re: Problems compiling modified Spad file under debian

Hello everybody !

> axiom-4 being uploaded to Debian servers now.
> Please let me know if anything else is amiss.

When will axiom-4 come in debian-unstable ? tomorrow ?

I update my distribution and I get today =E0 12h/Paris :
  Version: Axiom 3.9 (September 2005)

I get the same error when I try to compile a file :

>> System error:
   Cannot open the file /usr/lib/axiom-20050901/autoload/postprop.

\start
Date: Thu, 24 Nov 2005 08:35:40 -0500
From: Bill Page
To: list
Subject: RE: [#237 sqrt(-1/abs(x))-1/sqrt(-abs(x))=>0]

Axiom Developers;

I think I will close Axiom bug submissions at Savannah...
any objections?

It hasn't been used seriously in a long time and now it
just seems like a back door for spam.

Sorry about the email echoed from MathAction, I have cleanup
to offending issue report that was created.

Regards,
Bill Page.

> -----Original Message-----
> From:
> axiom-developer-bounces+bill.page1=synthesis.anikast.ca@nongnu
> .org
> a@nongnu.org] On Behalf Of anonymous
> Sent: November 24, 2005 1:29 AM
> To: MathAction
> Subject: [#237
> sqrt(-1/abs(x))-1/sqrt(-abs(x))=>0]
> (new)sqrt(-1/abs(x))-1/sqrt(-abs(x))=>0
>
>
> Changes
> http://page.axiom-developer.org/zope/mathaction/237Sqrt1AbsX1S
> qrtAbsX0/diff
> --
>
> Follow-up Comment #3, bug #6357 (project axiom):
>
>  <a href='http://pivasik.dynu.net/kozel/busty-babysitters.html'>
> http://pivasik.dynu.net/kozel/busty-babysitters.html - busty
> babysitters </a>

...

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=6357>

\start
Date: Thu, 24 Nov 2005 09:52:39 -0500
From: Bill Page
To: Tim Daly
Subject: re: allprose missing file

On November 23, 2005 11:49 PM Tim Daly (root) wrote:
> 
> methinks you could help the axiom portal/sandbox/wiki by
> doing what you suggested to ralf. we need a 1-2 page
> executive overview of the axiom site. i didn't know about
> axiom portal's ability to do uploads or i would have
> suggested it.
> 
> perhaps posting a couple 1-pagers (man pages?) to
> axiom-developer would help.
> 

You have a good point. Of course, I am totally amazed that
you might not know about the abilities of the Axiom Wiki
and Axiom portal web sites - almost a shock, since we have
been working on these sites for more than a year. I can only
agree that I must be a victim of the same "author's syndrome"
that I discussed with Ralf.

There is also the problem, mentioned by Jergen Wiess recently
on this list that "people don't read" the email on this list.
Since certainly we have discussed the features of the portal
and the wiki numerous times over the last year. Perhaps I would
restate what Jergen said as: "People only read what they are
ready to read.". This means that we have to be ready always to
answer questions which we have long sense taken for granted.

I will see what I can do to write an executive overview. In
the mean time, I can still refer everyone to the following
web page:

http://wiki.axiom-developer.org/AxiomCommunity

\start
Date: 24 Nov 2005 17:06:08 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: [#237 sqrt(-1/abs(x))-1/sqrt(-abs(x))=>0]

Bill Page writes:

> Axiom Developers;
> 
> I think I will close Axiom bug submissions at Savannah...
> any objections?

Please go ahead! Thank you!

\start
Date: 24 Nov 2005 17:57:20 +0100
From: Martin Rubey
To: Bill Page
Subject: Documentation of the Wiki

Dear Bill, *

I insist: the problem is *not* that there wouldn't be enough
documentation. Rather, there is too much too read.

Of course, long text can be good. However, I'm afraid that most pages of the
Wiki where long text passages appear are not read at all.

Thus: please do not 

> I will see what I can do to write an executive overview.

from scratch. Rather -- given that you have the time -- rewrite the existing
pages such that they are more succinct.

In the case at hand, this would probably be 


http://wiki.axiom-developer.org/HelpPage

http://wiki.axiom-developer.org/MathAction

http://wiki.axiom-developer.org/AboutMathAction

especially the existance of the latter two is highly dubious. They seem to be
quite similar...


On the HelpPage, we find

  Click "edit" to change the page's text. You may also be able to rename the
  page, upload a file, or choose other options here.

but no indication how this can be done. Personally, I prefer to see an example,
so maybe a link to a SandBox page would be appropriate.

By the way, concerning the upload feature: Some time ago I realized that
uploading a file with the same name as an already existing file would simply
overwrite the old "version". Maybe uploaded files should be "local" to their
page, if this is feasible...

\start
Date: Thu, 24 Nov 2005 15:39:50 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: Documentation of the Wiki

On Thursday, November 24, 2005 11:57 AM Martin Rubey wrote:
>
> I insist: the problem is *not* that there wouldn't be enough
> documentation. Rather, there is too much to read.
>

In general, I agree with you and I have already said something
similar previously.

> Of course, long text can be good. However, I'm afraid that
> most pages of the Wiki where long text passages appear are
> not read at all.

Actually, on the wiki we can get specific statistics about
how often a page is read. I think the numbers show quite high
hit rates for pages that are accessible from the front page
and those that are indexed on Google quite independent of their
size. If we want, I think we can even make these hit rates
visible on the pages themselves.

But the reasons and the manner in which web pages are read is
quite different than the way email is read. Probably these days
most people are suffering from much more email overload than
used to be the case, so they become quite selective about what
they "read-to-remember" from their email in basket. On the other
hand when people go to the trouble of surfing to a particular
web page, I expect they (usually) take the time to determine if
it really is of interest to them. So I do not think long web
pages are a problem.

Long emails - even this reply - are a different issue. I expect
that most people except maybe you and Tim have already stopped
reading this. ;)

>
> Thus: please do not
>
> > I will see what I can do to write an executive overview.
>
> from scratch.

In reply to Tim's suggestion my intention was not to create any
new web pages, but rather to just a posting to this email list
that could be repeated as necessary when someone asks about the
features related to the web sites. That mostly means finding
stuff on the existing web pages and formatting it as an email.

> Rather -- given that you have the time -- rewrite the existing
> pages such that they are more succinct.

:( Of course I do not really have time for that ... making
something short and succinct takes a lot of time, experience
and thought.

>
> In the case at hand, this would probably be
>
>
> http://wiki.axiom-developer.org/HelpPage
>
> http://wiki.axiom-developer.org/MathAction
>
> http://wiki.axiom-developer.org/AboutMathAction
>
> especially the existence of the latter two is highly dubious.
> They seem to be quite similar...
>

I'll look at the possibility of merging the last two.

>
> On the HelpPage, we find
>
>   Click "edit" to change the page's text. You may also be able
> to rename the page, upload a file, or choose other options here.
>
> but no indication how this can be done. Personally, I prefer
> to see an example, so maybe a link to a SandBox page would be
> appropriate.

Good idea, but I think/hope there are other people more qualified
than me to write good help information. Remember, this is a wiki.
It is supposed to be a community effort.

>
> By the way, concerning the upload feature: Some time ago I
> realized that uploading a file with the same name as an already
> existing file would simply overwrite the old "version". Maybe
> uploaded files should be "local" to their page, if this is
> feasible...
>

Because of it's underlying simplistic design, that is not
possible on the wiki without major changes. The portal however
is both more complex and more flexible because files are
associated with individual users and there is a "workflow",
i.e. review and approval process, associated with making
documents publicly accessible.

On the wiki I suggest that when uploading a file that is specific
to a page, we try to make sure that the name of the file includes
as a prefix the name of the page.

\start
Date: Thu, 24 Nov 2005 16:27:11 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [MathAction] merged page AboutMathAction - better but not shorter

  !MathAction consists of two related web sites. This web site
is a wiki (see below) with support for LaTeX and computer
algebra. There is also a portal web site that provides a
workspace, document publishing and other advanced features
for developers.

  http://wiki.axiom-developer.org  <== You are here

  http://portal.axiom-developer.org

  The purpose of !MathAction is to support the development of
the open source version of Axiom and to promote the use of
computer algebra systems in general. It provides an over-the-web
graphical interface for Axiom (see AxiomInterface) and Reduce
(see ReduceWiki). Try out Axiom and Reduce online in the SandBox.

  !MathAction is based on some customizations of LatexWiki -
itself an extension of ZWiki which in turn is based on
"Zope":http://www.zope.org. It expands on LatexWiki by nicely
formatting the output of Axiom and Reduce commands and the
ability to display graphs using GraphViz. These customizations
work on this wiki and on the portal.

The wiki is discussed in more detail below. For more detailed
information about the portal see [Axiom Portal].

Axiom Wiki

  The wiki Concept: A wiki is a website that is editable by
anyone. It is simple enough that anyone who discovers it on
the web can contribute meaningfully by creating new content or
re-organizating it. The pages themselves have a simple syntax
that resembles the web-page output, and pages are automatically
interlinked via the use of camel-case (mixed upper and lowercase)
noun-phrases called WikiWords.

  This openness and free access perhaps counter-intuitively
*does* seem to result in organization, widespread contribution,
and high-quality content. In some sense it is the open source
philosophy applied to documentation. See also:

    - http://wiki.org/wiki.cgi?WhatIsWiki

    - http://c2.com/cgi/wiki?WikiDesignPrinciples

Folders

  The web pages on this wiki are grouped into folders and the

Search

  The text box in the upper right corner of every page allows
you to search for pages based on their content within the current
folder. Enter a few key words and then press Enter to see a list
of pages.

  The TouchGraph navigator is a java application that displays the
links between all the pages in a folder and to quickly move from
one place to the next.

  The Axiom wiki has grown rapidly over the last year. This graphic

  You can comment on the content or edit all of the pages on this
web site but you are required to identify yourself first by clicking
"preferences":UserOptions. If your browser options allow it, this
information will be saved and used the next time you access the site.

  The Axiom wiki is also able to operate like a mailing list. Anyone
can "subscribe" to the individual web pages or to the whole web
site. First they must identify themselves by clicking preferences
(or logging in) and specifying their name (or pseudonym) and email
address. Then all they have to do is click the "subscribe" link at
the top right side of the page. Any comments subsequently attached
to a page will be automatically distributed by email to all
subscribers.

  **Note:** The Axiom-developer email list itself is already
subscribed to the Axiom Wiki. This means that if you are subscribed
to axiom-developer, then you do not need to separately subscribe
to pages on this website.

  It is also possible for you to use email to reply directly to
the emails sent out by !MathAction. These replies will in turn
be attached to the original web page and again sent out to
subscribers. This way a chronological record of the discussion

  This is an **interactive** web site so please feel free to
"experiment":SandBox. There is a [Help Page] and a page the
describes the use of LaTeX.

This same software can run inside of a Plone portal on Zope.

  "Zope":http://www.zope.org is both a web server and a set of
classes for manipulating web-data stored in its object-oriented
database. One could think of it as server-side scripting with
a persistent object orientation. In other words Zope is an
"integrated web application development environment" consisting
of a web server (Zserver) and an object-oriented database (ZODB)
based on the idea of persistent objects and classes. Zope is
written in Python and was originally a commercial product of
Zope Corporation before it went "open source" (It is still a
commercial product in the sense that Zope Corporation continues
to make money from it's earlier effort, albeit in a different
way.)

  Plone is a very pretty and popular "portal" application
built on top of Zope that allows high-level control like
multiple users, owners, access rights, publication rules,
and web-based site management.

  ZWiki and "Plone":http://www.plone.org are two of quite
a large number of applications built using Zope. More

  Plone is a portal application that is built on top of a layer

CMF in turn is built directly on Zope. Both CMF and ZWiki define
object types that are inherited by Plone.

  ZWiki fits into the hierarchy roughly at the same layer as
CMF - just above Zope. ZWiki is a powerful wiki implementation
that allows several forms of input type (StructuredText,
WikiWikiWeb, MoinMoin, and now Latex) and because it is built
on Zope it is more powerful but not as simple as the original
Wiki idea.

Installing !MathAction

  See InstallingMathAction for information about how to configure
your own Axiom-enabled wiki and web portal.

Testing and Development

  The software for this web site is still

The test and development version of !MathAction is --

The development repository (darcs) for !MathAction is --

Current Version of Axiom

\start
Date: Thu, 24 Nov 2005 18:48:04 -0500
From: Bill Page
To: list
Subject: MathAction to email list connection

Dear Axiom-developer Subscribers;

Gee that was stupid of me, wasn't it ... :(^

Perhaps this is a good time to suggest that we disconnect the
axiom-developer email list from the Axiom Wiki web site?

Originally this connection between the email list and the web site
seemed like a good idea in order to promote the use of the site. But
accidents like this one as well as a few real spam cases that get
through the email filters suggest that it is not really such a good
idea. And besides now in addition to email subscription to the
website, we also have several better ways to keep up to date with
what's new and what's changed on the site such as the RSS newsfeed.

So unless there is any objection, I plan to remove the axiom-developer
list as a subscriber to the Axiom Wiki. This will mean that you will
no longer automatically received notices from the wiki web site. If
you want to continue to receive email notices of changes to the site,
you will have to go to:

http://wiki.axiom-developer.org

set your 'preferences' to include your email address and click on
'subscribe'.


Explanation of my Error

I decided I liked the page named AboutMathAction better than just
MathAction so I did a page rename from MathAction to AboutMathAction
not thinking about how many pages on the web site already use
that name as a link. So ZWiki just did what I said and went through
and blindly changed all the pages where this link occurred and sent
email notices for every one that it changed. Of course I did not
really mean for it to change the contents of the page, only the
links. Arrrghh!

As they say, it takes computer to really screw-up and I must add
one connected to email on the Internet to do it publicly - and
all for the sake of better public relations about how great this
web site is ... <too embarrassing>!

I am very sorry for all the unintentional spam that was generated.

\start
Date: Thu, 24 Nov 2005 19:48:29 -0500
From: Tim Daly
To: Bill Page
Subject: Re: MathAction to email list connection

no problem. i just figured you were having a very busy day. --t

\start
Date: Thu, 24 Nov 2005 16:13:00 -0800
From: Ed Borasky
To: list
Subject: Re: MathAction to email list connection

Yes ... and it's refreshing to get email relating to something I'm 
interested in ... in English ... that I haven't seen before ... from 
someone I actually know ... that doesn't contain a virus or pictures of ...

:)

root wrote:

>no problem. i just figured you were having a very busy day. --t

\start
Date: 25 Nov 2005 01:48:15 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: MathAction to email list connection

Dear Bill,

well, it's ok for me. Although I'm not convinced that it's the right thing to
do... I'll subscribe MathAction anyway, and I hope many others will do so, too.
I'm a little afraid that it won't get as much attention anymore, but I do see
that from time to time it generated quite a bit of spam...

\start
Date: Thu, 24 Nov 2005 20:50:03 -0500
From: Bill Page
To: Martin Rubey
Subject: Axiom Wiki FrontPage re-design

Martin,

In "payment" for my earlier error tonight :), I thought
I would try my hand at a new look for the Front Page
for the Axiom Wiki:

http://wiki.axiom-developer.org/SandBoxFrontPage

Please let me know what you think of this design -
especially you, Martin. Tweek it some, if you feel
like it.

Note that it is based loosely on the design of the
Front Page of http://zwiki.org

Also, in the final version there will not be any
comment form at the bottom.

Thanks.

\start
Date: Thu, 24 Nov 2005 21:12:11 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: MathAction to email list connection

Martin, Tim, Edward, ...

About disconnecting the email list:

Ok, well I will leave it connected for now and wait for
further comments (if any). We can decide next week. Thanks.

\start
Date: Thu, 24 Nov 2005 20:32:56 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Wiki] (new) 

The Axiom Wiki (this web site) is an online enviroment in which
Axiom users and developers can:

* view pages like a traditional web site 

* edit pages to correct and expand on topics of interest

* upload files and images

* create new pages related to their interests

* comment on pages

* submit bug reports and wish list items to IssueTracker

* use LaTeX for mathematics

* experiment with Axiom and Reduce online, either quietly
  in the SandBox or publicly on other pages

* search based on keywords

* subscribe to receive email notices of new or changed pages

* bookmark RSS news feeds on new and changed pages.

See also [Axiom Portal] and MathAction.

\start
Date: Fri, 25 Nov 2005 00:29:25 -0500
From: Tim Daly
To: Bill Page
Subject: Re: MathAction to email list connection

Bill,

They mention an anti-wiki abuse tool on this page
(http://planet.lisp.org) Don't know if you'll find it useful.

\start
Date: Fri, 25 Nov 2005 10:51:05 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: MathAction to email list connection

Page, Bill wrote:
> Dear Axiom-developer Subscribers;
> 
> Gee that was stupid of me, wasn't it ... :(^
> 
> Perhaps this is a good time to suggest that we disconnect the
> axiom-developer email list from the Axiom Wiki web site?

Good idea. I usually just remove those emails. A much better idea would 
be to post a FAQ every month. Or just a link to a FAQ at MathAction. 
Wouldn't that help people to get aware of MathAction and what one can do 
with it? Personally I cannot remember that I have ever changed anything 
on a MathAction page. The problem with too much text also applies here.

However, I don't think that it is actually the amount of text which is a 
problem, it is rather its organisation. I have already agreed that 
ALLPROSE is not (yet) good in providing such an approach, but it is not 
finished anyway.

What I would dream of is ONE main entry point into the AXIOM world. At 
the moment I could see several.
   1. Top-level Makefile
   2. http://www.axiom-developer.org
   3. http://www.axiom-developer.org/zope/mathaction/MathAction
   4. The Axiom Book project
and maybe others.

If I look at (1), there is not reference to (2).

If I am on (2) I see a reference to (3), but being new to Axiom, I ask 
myself, why should I click on MathAction.

If I am on (3), I read...

   The purpose of MathAction is to support the development of the open
   source version of Axiom and to promote the use of computer algebra
   systems in general. It provides an over-the-web graphical interface
   for Axiom (see AxiomInterface) and Reduce (see ReduceWiki). Try out
   Axiom and Reduce online in the SandBox.

"Oh, I just wanted to know what Axiom is about, not develop it. I 
haven't even read what Axiom is. So MathAction is not for me, it's for 
Axiom developers. I don't need to read any further here."

If I am on (4). Is there a link to (2)? -- No.

Anyway, I would suggest to make (2) the main entry point and also 
reference it at least from the top-level Makefile and also from the book.

\start
Date: Fri, 25 Nov 2005 06:58:40 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#219 The interpreter does not understand dependend types] Update

Note that with Peter''s patches the error message 'System Error:
Unfortunate use of dependant type' is directly triggered by the code
produced by aldor. In the lisp file, there line 201 reads::

    (|Halt| (the |SInt| 101))))

'|Halt|' is a function in 'foam_l.lisp'. I do not know why the call to
this error was not produced with the old 'libaxiom.al'. Would be great
if somebody could help here...

\start
Date: 25 Nov 2005 14:13:50 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: MathAction to email list connection

Ralf Hemmecke writes:

> Page, Bill wrote:

> > Perhaps this is a good time to suggest that we disconnect the
> > axiom-developer email list from the Axiom Wiki web site?
>
> Good idea. I usually just remove those emails.

Well, I regard these emails primarily as notices that something was changed. At
least the issuetracker notices should get sent to Axiom-developer, since I
suspect that otherwise some people will not notice that a bug report has been
filed.

Apart from these, there are very few messages sent out usually. (Although I
admit, I did not count.)

> A much better idea would be to post a FAQ every month. Or just a link to a
> FAQ at MathAction.

But not on axiom-developer! If, then on axiom-mail or axiom-math. Please keep
axiom-developer as much for developers as possible. And do direct people who
do not want to assist with development to axiom-math.

> However, I don't think that it is actually the amount of text which
> is a problem, it is rather its organisation. I have already agreed
> that ALLPROSE is not (yet) good in providing such an approach, but
> it is not finished anyway.

I very much hope that "not (yet)" will vanish eventually.
>
> What I would dream of is ONE main entry point into the AXIOM world. At the
> moment I could see several.
>    1. Top-level Makefile

Usually I don't look at the Makef=EDle, but rather at README, INSTALL,
FAQ or the like

>    2. http://www.axiom-developer.org
>    3. http://www.axiom-developer.org/zope/mathaction/MathAction

As most of you know, I would like to see the wiki to be identical to the axiom
world, and, in particular, a superset of the

>    4. The Axiom Book project

and I hope that ALPROSE (!) will accomplish that in the near future.

Did you have success with tex4ht?

\start
Date: 25 Nov 2005 08:53:25 -0500
From: Camm Maguire
To: Francois Maltey
Subject: re: Problems compiling modified Spad file under debian

Greetings!  It appears in the unstable package list at present to me,
and should also be accessbile directly via the package website page.
Please let me know if problems persist, or if anything else is amiss.

Take care,

Francois Maltey writes:

> Hello everybody !
>
> > axiom-4 being uploaded to Debian servers now.
> > Please let me know if anything else is amiss.
>
> When will axiom-4 come in debian-unstable ? tomorrow ?
>
> I update my distribution and I get today =E0 12h/Paris :
>   Version: Axiom 3.9 (September 2005)
>
> I get the same error when I try to compile a file :
>
> >> System error:
>    Cannot open the file /usr/lib/axiom-20050901/autoload/postprop.
>

\start
Date: Fri, 25 Nov 2005 10:55:36 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Fancy LaTeX preamble

--- Tim Daly wrote:

> > I would like to describe what I have done and why, in case
> > there is any merit in outlining the issues.
> 
> post away. you don't need permission.

Just trying to avoid annoying the list :-).

Here is the preamble I am currently using - for any more elaborate
posting I'll have to wait until I'm back home.  I brought this one with
me but didn't have time to sort everything out.

\documentclass{article}
\usepackage{axiom}
\usepackage{ifthen}
\usepackage{fontenc}

% Here we will define some control logic for printing, in order 
% to allow quick switching between using 1 inch margines and 
% smaller margines, while also permitting the user to shrink 
% specified equations in the different cases.  By default we 
% will use the standard pamphlet formatting.

\newboolean{usefullpage}
\setboolean{usefullpage}{false}

% Uncomment this line to use 1 inch page margins:
%\setboolean{usefullpage}{true}

% Here we define control logic for producing a pdf version of 
% the document.  TeTeX 3.0 and up seem to be semi-automatic, so
% using the old 2.x trick in the Maximabook didn't seem to work.

\newboolean{makepdf}
\setboolean{makepdf}{false}

% Uncomment this line to produce a properly formatted pdf 
% document (the main difference is how hyperref is used).
%\setboolean{makepdf}{true}

% The actual ifthen control logic
\ifthenelse{\boolean{usefullpage}}{
   \usepackage{geometry}
   % For different paper sizes or margins adjust the 
   % settings here
   \geometry{verbose,letterpaper,tmargin=1in,bmargin=1in,
             lmargin=1in,rmargin=1in}
   % If we are using the full page, we want to have all  
   % equations full size
   \newcommand\resizeequation[1]{#1}
}{
   % If we are using the normal Axiom mode, we want some 
   % equations to use smaller fonts
   \newcommand\resizeequation[1]{{\tiny #1}}
} 

% These options will change options used for hyperref when 
% pdflatex/pdftex is the generator
\ifthenelse{\boolean{makepdf}}{
  \usepackage[pdftex=true, plainpages=false, colorlinks=true, 
              linkcolor=blue, breaklinks=true, pdfpagelabels, 
              pdftitle={Units and Dimensions in Axiom}, 
              pdfauthor={Clifford Yapp}, pdfsubject={Axiom Units 
              and Dimensions}, pdfkeywords={Axiom, CAS, Computer
              Algebra, Units, Dimensions, Dimensional, Analysis}, 
              bookmarksopen=false, pdfnewwindow=true,
              pdfstartview=FitH, 
              pdfpagemode=UseOutlines]{hyperref}
}{ 
% hyperref calls for dvi file production
  \usepackage[backref=false, colorlinks=false, 
              breaklinks=true]{hyperref}


> > Oh, related question - is there a place where I can upload 
> > example pdf and dvi documents? 
> 
> do you have a userid on axiom-developer.org? we could set up 
> one that has web access.

Don't think so, unless I put one up a while back - I'll check.  What is
involved with getting one?

\start
Date: 25 Nov 2005 15:26:17 -0500
From: Camm Maguire
To: Francois Maltey
Subject: re: Problems compiling modified Spad file under debian

Greetings!

Francois Maltey writes:

> Hello Camm, and thanks a lot !
> 
> When I update axiom on my debian testing (etch) I play with 
> etc/apt/preference :
> 
> Package: *
> Pin: release a=testing
> Pin-Priority: 990
> 
> Package: axiom*
> Pin: release a=unstable
> Pin-Priority: 900
> 
> And an update after, I break the x11 driver (an ati fglrx driver)
> and the ipw2200 module.

Yes, my understanding is that apt will bring in just enough packages
from unstable to satisfy axiom's binary dependencies, which, being
linked against X11 through axiom-graphics, will bring in unstable x11
too. 

This is just a tip for how I do such things -- it works remarkably
well for me. Find a spare partition somewhere on your filesystem
(could just be a directory with enough disk space), and create and
unstable dchroot system in it.  One can then log into this system and
run programs from within it without affecting the stable system housing
the kernel and everything else.   Check the docs, but the outline is:

1) Build debootstrap from source on stable -- apt-get -q -b source
   debootstrap.  (Have your deb-src resources in /etc/apt/sources.list
   point to unstable.)  Likewise with dchroot.  Install these two
   packages on your stable system.

2) Run debootstrap pointing it to the directory you wish to house your
   unstable system.  Configure dchroot to log in to this as a chroot
   environment.  Setup your and root passwords in the chroot.

3) exit out of chroot, and bind mount any partitins you would like to
   share.  e.g. mount -o bind /home /unstable/home.  I suggest at
   least home,tmp, and dev/pts if it is a separate fileystem.  Then
   mount -t proc proc /unstable/proc.

4) dchroot into the chroot, configure apt, update, upgrade, and
   install unstable axiom.  You should then be able to run the latest
   Debian axiom  from within this environment without modifying your
   surrounding stable system.

Take care,

> 
> I pass a lot of hours to try to repare my system, but I can't.
> 
> I'll buy a new disk, and make 2 PARTITIONS on my laptop.
> One with a stable linux (even if it's a testing version)
> and one for frequent update. 
> 
> So I don't test axiom before som days, but I will do it.
> Wait the time I install a clean debian.
> 

\start
Date: Fri, 25 Nov 2005 13:49:48 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: MathAction to email list connection

On Friday, November 25, 2005 4:51 AM Ralf Hemmecke wrote:

> Bill Page wrote:
> > ...
> > Perhaps this is a good time to suggest that we disconnect the
> > axiom-developer email list from the Axiom Wiki web site?
>
> Good idea. I usually just remove those emails. A much better
> idea would be to post a FAQ every month. Or just a link to a
> FAQ at MathAction. Wouldn't that help people to get aware of
> MathAction and what one can do with it?

I will check to see if there is some way on the axiom-developer
and axiom-mail email list server to setup such a "once per
month" message to subscribers. I think that is a good idea as
long as I do not have to remember to do it each month.

> Personally I cannot remember that I have ever changed anything
> on a MathAction page. The problem with too much text also
> applies here.

That is a pity. It is the explicit purpose of the Axiom Wiki
site that Axiom developers will actively make changes to the
site and help improve it's organization. Everyone has unlimited
ability to edit the pages, delete and reorganize content, and
and new material. A wiki is an open interactive environment that
is supposed to take advantage of the fact that anyone with an
interest in the subject can contribute to it's documentation.

If you ever feel motivated and have the time, I would encourage
you the shorten and re-write portions of the pages on this web
site based on your own experience and knowledge.

>
> However, I don't think that it is actually the amount of text
> which is a problem, it is rather its organization. I have
> already agreed that ALLPROSE is not (yet) good in providing
> such an approach, but it is not finished anyway.

A web site like the Axiom Wiki is, in effect, never "finished".
It is intended to dynamically evolve based on the community
of contributors.

>
> What I would dream of is ONE main entry point into the AXIOM
> world. At the moment I could see several.
>    1. Top-level Makefile
>    2. http://www.axiom-developer.org
>    3. http://www.axiom-developer.org/zope/mathaction/MathAction
>    4. The Axiom Book project
> and maybe others.
>

Here is another entry point:

http://portal.axiom-developer.org
http://www.axiom-developer.org/zope/Plone

These original development urls are now out of date but
still work since they are bookmarked in a few places on
the Internet:

http://page.axiom-developer.org
http://page.axiom-developer.org/zope/mathaction
http://page.axiom-developer.org/zope/Plone

> If I look at (1), there is not reference to (2).
>

I think it would be a great idea to include (2) in the
Axiom source distribution in the README file and in the main
dvi files that a first time user might read. These and even
be hyperref links.

In the Windows binary distribution there is an installation
program that sets up some standard "bookmarks" that point to
this site and the Axiom donations page. But this is not easy
to do on Linux because there is no standard way to create such
links on a Linux desktop (at least none that I know of).

Other places where the link (2) might be useful is in the banner
startup of the Axiom console and in front page of HyperDoc.
Also, there should be a hyperref link to (2) in the Axiom book
pdf and dvi files.

> If I am on (2) I see a reference to (3), but being new to
> Axiom, I ask myself, why should I click on MathAction.
>
> If I am on (3), I read...
>
>    The purpose of MathAction is to support the development of
>    the open source version of Axiom and to promote the use of
>    computer algebra systems in general. It provides an over-the-web
>    graphical interface for Axiom (see AxiomInterface) and Reduce
>    (see ReduceWiki). Try out Axiom and Reduce online in the SandBox.
>
> "Oh, I just wanted to know what Axiom is about, not develop it.
> I haven't even read what Axiom is. So MathAction is not for me,
> it's for Axiom developers. I don't need to read any further
> here."
>

I find it very difficult to anticipate how someone will interpret
a given passage of text. Certainly I do not personally get the
same idea that you do from this text. If you have an idea how to
change this text to be more clear about where to find out about
Axiom itself - as opposed to the MathAction website - then I think
it would be great if you were to change the text or add new text
that is clear to you. Very probably if it is clear to you, it
will also be clear to quite a few other people.

By saying that *you* (or anyone else) can or even should make
such changes, I am not implying any indirect reaction to your
criticism. So people do seem to react that way when they are
told that a wiki web site is one where *they* are invited to
make exactly the kind of changes that they are suggesting. But
that is not the point. A wiki web site is not based on the
traditional model of "publishing" a site for others just to view.
It is supposed to be an interactive collaborative environment.

> If I am on (4). Is there a link to (2)? -- No.
>

This is an example of the type of thing that *you* or anyone else
can add when they notice that it is not present. Editing a page
on the Axiom Wiki is very easy. It takes less than a minute.

> Anyway, I would suggest to make (2) the main entry point and
> also reference it at least from the top-level Makefile and
> also from the book.
>

Yes, good ideas. Thanks.

\start
Date: Fri, 25 Nov 2005 19:06:04 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: MathAction to email list connection

On Friday, November 25, 2005 4:51 AM Ralf Hemmecke wrote:
>
> ... I don't think that it is actually the amount of text
> which is a problem, it is rather its organisation.
> ...
> What I would dream of is ONE main entry point into the AXIOM
> world. At the moment I could see several.
>    1. Top-level Makefile
>    2. http://www.axiom-developer.org
>    3. http://www.axiom-developer.org/zope/mathaction/MathAction
> ...
> If I am on (2) I see a reference to (3), but being new to
> Axiom, I ask  myself, why should I click on MathAction.
> ...

Here is a draft alternate page to be displayed when you on (2):

2'. http://www.axiom-developer.org/zope/mathaction/SandBoxFrontPage

Do you think that organization of this new page would be easier
to understand for new Axiom users?

I agree that the MathAction link is not important to new Axiom
users. I hope this alternate page layout makes this more clear.

\start
Date: 26 Nov 2005 10:22:04 +0100
From: Martin Rubey
To: Bill Page, Ralf Hemmecke
Subject: Re: Axiom Wiki FrontPage re-design

Dear Bill, *

Bill Page writes:

> a new look for the Front Page for the Axiom Wiki:
> 
> http://wiki.axiom-developer.org/SandBoxFrontPage

I think that it looks *very* nice -- especially the colors are well
chosen. Before adoption, I would like to think about it, however. Please give
me a little more time.


> On Friday, November 25, 2005 4:51 AM Ralf Hemmecke wrote:
> > 
> > ... I don't think that it is actually the amount of text 
> > which is a problem, it is rather its organisation.

I agree partially. You are probably right that the amount is less of a problem
than it's organisation.

> I agree that the MathAction link is not important to new Axiom users. I hope
> this alternate page layout makes this more clear.

WHAT? Do I parse this sentence correctly? 

I am *absolutely* certain that MathAction is of utmost important to new Axiom
users. All of the documentation can be found there, examples how to use it
(SandBox), bugs that show Axioms deficiencies...

Again: I think that our aim should be to make MathAction be the *only* entry
point to the Axiom world. To reach this aim, one of the first steps -- a huge
step though -- would be to make the pamphlet files and the book browsable. Here
goes a big THANK YOU to Bill for providing the sources of Axiom on MathAction!

The FrontPage would then direct into the various chapters of the new Axiombook,
roughly as proposed by Tim. Of course, a printed or even a dvi version would
*look* a bit different: much of the material would be skipped, the layout of
the FrontPage would not be the same as the layout of the table of contents, and
so on. But in principle, the two would have a lot in common.

What remains is an expert on tex4ht. Reminder: Eitan promised to have a look
how to make jsmath a backend for tex4ht this winter break. Ideally, we (well,
sorry, not me) would have some experience with translating the tex code
produced by "ALLPROSE" or "document" into mathml / html with tex4ht.

Another step is to transform the pamphlet files into the ALLPROSE format --
and, if necessary, extend ALLPROSE so that it can handle Axiom. Ralf, am I
correct that this is not really necessary?

\start
Date: Sat, 26 Nov 2005 09:06:49 -0500
From: Tim Daly
To: Martin Rubey
Subject: re: Axiom Wiki FrontPage re-design

> Again: I think that our aim should be to make MathAction be the *only* entry
> point to the Axiom world. 

Email has one property that a website lacks. It forms a private linear 
queue of work for me to accomplish (or not :-)). Thus it gives me my
own stream of information. I'm already multitasked beyond what I would
have thought possible and I need this private linear queue to manage
the "incoming" workflow requests. Perhaps I'm behind the times and need
to start a "public personal" page or somesuch. I'd be willing to try this.

Bill, is it possible to set up "public personal pages" on a per-user basis?
Nothing fancy, just a place to scribble similar to email. I suppose it
could either be organized by topic (newsgroups) or just a linear page or
both.

\start
Date: 26 Nov 2005 15:29:50 +0100
From: Martin Rubey
To: Tim Daly
Subject: re: Axiom Wiki FrontPage re-design

Tim Daly writes:

> > Again: I think that our aim should be to make MathAction be the *only*
> > entry point to the Axiom world.
> 
> Email has one property that a website lacks. It forms a private linear queue
> of work for me to accomplish (or not :-)). Thus it gives me my own stream of
> information. I'm already multitasked beyond what I would have thought
> possible and I need this private linear queue to manage the "incoming"
> workflow requests. Perhaps I'm behind the times and need to start a "public
> personal" page or somesuch. I'd be willing to try this.

This is a misunderstanding. Of course the mailing lists should be part of
MathAction just as they are now. So, to be precise, MathAction should - in my
opinion - be the door through which the users and developers of Axiom enter the
Axiom house. The various medias -- printed books and articles, the wiki, the
mailing lists should be all accessible through this portal.

Of course, when you know the shortcut, i.e., you know already how to get to the
mailing list, then nobody requires you to use the main entry.

Is this clearer?

I thought that you know that I prefer the mailing lists for discussion. The
Wiki should be a medium where we summarize the discussions for those that did
not follow.

\start
Date: Sat, 26 Nov 2005 11:25:53 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: article "standard" header/footer

Ralf,

I promised to give you some idea of the pamphlet and book file coding
"standards". This is the current "state of the world" which evolves
as I write more pamphlet files. However, as I re-edit old files I
modify them to conform to these standards.

Each file I make into a "literate program" has a "head" and a "tail"
that contains essentially the same code for the same reasons. The only
major deviation is that I will occasionally include the "axiom.sty" file
in the literate document if it is meant to be stand-alone and the user
is unlikely to have it.

First, I've laid out the "head" and then a copy to explain it, 
Second I talk about labeling, index, naming, and testing conventions in
the body and, 
Third, I lay out the "tail" and a copy to explain it. 
Finally I explain the way I work with the literate programs.

So to start a project I open a file, insert the "head" and "tail"
code and then follow the conventions.

I'll send the book "standard" header/footer soon.


So, first, the standard "head" (for articles):

=======================================================================
\documentclass{article}               
\usepackage{axiom}
\usepackage{makeidx}
\makeindex
\begin{document}
\title{no title}
\author{Timothy Daly}
\maketitle
\begin{abstract}
\end{abstract}
\eject
\tableofcontents
\eject
\section{Executive Overview}
=======================================================================

and now the standard "head" with notes:

=======================================================================
\documentclass{article}

   The original Axiom layout had individual files each being a separate
   final .dvi file so article seemed appropriate. I still use this when
   I write a literate program that is intended to be stand-alone but
   Axiom is being rewritten into "book" class files.

\usepackage{axiom}

   The various latex format macros for Axiom live here. This is a
   collection of macros used in both the books and the articles.
   It also includes the latex macros used in noweb so there is no
   need to usepackage{noweb}

(another missing package is the hyperref package but i dont' yet know
 how to use it so it isn't included. but you've convinced me that it
 is a good idea so i plan to add it to all of the documentation after
 i understand how it works and how to write using it)

\usepackage{makeidx}
\makeindex

   Recent work by you has shown me the value of making an index so these
   have become part of my standard usage.

\begin{document}
\title{no title}
\author{Timothy Daly}
\maketitle

   Boilerplate headers

\begin{abstract}
\end{abstract}

   Since these are articles we need to write a few words for the casual
   browser so they can understand what the article is about.

\eject
\tableofcontents
\eject

   Boilerplate headers

\section{Executive Overview}

   Martin has convinced me that this needs to be in the front of every
   document. Literate programs are large, generally running into the
   hundreds of pages in my experience. This section is vitally necessary
   if you plan to make any progress in understanding the whole of it.

=======================================================================







within the article:

=======================================================================

\section{A section name}
\label{sec:Asectionname}

  section names have labels beginning with sec: so the \ref tag
  shows what it refers to. thus 
      \ref{sec:Asectionname}
  can be seen to refer to a section name


\subsection{defun foo}
\label{sec:defunfoo}
A discussion of the function foo.
\index{foo defun!defn}
<<defun foo>>
(defun foo () "whatever")

@
<<runtests>>=
  test the foo function

@


\subsection{defmacro bar}
\label{sec:defmacrofoo}
A discussion of the macro bar.
\index{bar defmacro!defn}
\index{foo defun!use}
<<defun bar>>
(defun bar () (foo))

@
<<runtests>>=
  test the bar macro

@

  defvars, defuns, defmacros, defstructs, etc all are at the subsection
  level so they show up in the table of contents. they also have the
  name of the function (first), that it is a function, and that this
  is the definition 
          \index{foo defun!defn}

  so they show up in the index looking like:

     foo defun
        defn   234
        use    442

     bar defmacro
        defn   442


\section{Code}
\label{sec:Code}
A discussion of the code block.
<<lisp>>=
<<defmacro bar>>
<<defun foo>>

<<runtests>>

@

  The Code section gathers all of the chunks together so they can be
  output into a file (see the makefile below)


  Test cases usually are in one chunk called <<runtests>> which get
  gathered together and added to the end of the <<lisp>> chunk. This
  allows me to automate the testing.



=======================================================================





and now the standard "tail":

=======================================================================
\section{Makefile}
<<*>>=
PROJECT=tpd
TANGLE=/usr/local/bin/NOTANGLE
WEAVE=/usr/local/bin/NOWEAVE
LATEX=/usr/bin/latex
LISP=/sei/lisp
MAKEINDEX=/usr/bin/makeindex

all: ${PROJECT}.lisp ${PROJECT}.dvi test

${PROJECT}.lisp: ${PROJECT}.pamphlet
	${TANGLE} -Rlisp ${PROJECT}.pamphlet >${PROJECT}.lisp

${PROJECT}.dvi:
	${TANGLE} -Rdummyindex ${PROJECT}.pamphlet >${PROJECT}.ind
	${WEAVE} -t8 -delay ${PROJECT}.pamphlet >${PROJECT}.tex
	${LATEX} ${PROJECT}.tex 
	@{MAKEINDEX} ${PROJECT}.idx
	${LATEX} ${PROJECT}.tex 

test:
	cat ${PROJECT}.lisp | ${LISP}

remake:
	${TANGLE} -t8 ${PROJECT}.pamphlet >Makefile.${PROJECT}

@
\eject
\begin{thebibliography}{99}
\bibitem{1} nothing
\end{thebibliography}
<<dummyindex>>=
\begin{theindex}
 \item none
\end{theindex}
\printindex
\input{${PROJECT}.ind}
\end{document}
=======================================================================

and now the standard tail with comments:

=======================================================================
\section{Makefile}
<<*>>=
PROJECT=tpd

  The project name is the same as the filename. The sequence for
  working is that I create a Makefile per project, in this case
  it would be:
                 Makefile.tpd
  and then i can set up an edit-test-debug cycle with
                 make -f Makefile.tpd


TANGLE=/usr/local/bin/NOTANGLE
WEAVE=/usr/local/bin/NOWEAVE
LATEX=/usr/bin/latex
LISP=/sei/lisp
MAKEINDEX=/usr/bin/makeindex

all: ${PROJECT}.lisp ${PROJECT}.dvi test

${PROJECT}.lisp: ${PROJECT}.pamphlet
	${TANGLE} -Rlisp ${PROJECT}.pamphlet >${PROJECT}.lisp

   Here I extract the lisp code (chunk name <<lisp>>) to run.
   Of course, this varies with the project.

${PROJECT}.dvi:
	${TANGLE} -Rdummyindex ${PROJECT}.pamphlet >${PROJECT}.ind

   We need an initial index file the first time we latex the project
   so we include a dummy index and extract it first. The dummy index
   lives at the end of the file under the chunk name <<dummyindex>>

	${WEAVE} -t8 -delay ${PROJECT}.pamphlet >${PROJECT}.tex

   Here we extract the latex for the project

	${LATEX} ${PROJECT}.tex 
	@{MAKEINDEX} ${PROJECT}.idx
	${LATEX} ${PROJECT}.tex 

   and then we do the "latex 2-step" to get the dvi file with an index

test:
	cat ${PROJECT}.lisp | ${LISP}

   after we have the code and the documents we run the test cases.


remake:
	${TANGLE} -t8 ${PROJECT}.pamphlet >Makefile.${PROJECT}

   and sometimes we make changes to the makefile chunk so we have a
   special stanza to "remake" the Makefile.${PROJECT}. The first time
   we have to extract the makefile by hand but after that we can just do:
        make -f Makefile.${PROJECT} remake
   and we get the updated makefile.

@
\eject
\begin{thebibliography}{99}
\bibitem{1} nothing
\end{thebibliography}

   more boilerplate

<<dummyindex>>=
\begin{theindex}
 \item none
\end{theindex}

   we create a dummy .ind file from this chunk so we can include it.
   if we don't do this then the first time we ever latex something
   it will fail.

\printindex

   this requests the index to be printed in the latex file.

\input{${PROJECT}.ind}

   and this includes the index so it is part of the document

\end{document}
=======================================================================




=======================================================================

and now the way I work with these:

=======================================================================


 notangle -t8 foo.pamphlet >Makefile.foo

    this extracts the default chunk <<*>>= which is a makefile and
    names it Makefile.foo.

 make -f Makefile.foo

    this completely rebuilds all of the foo project.

 emacs -nw foo.pamphlet
   (C-x 2     splits the emacs into 2 buffers, both visiting foo.pamphlet)
   (M-x shell starts a shell in one of the emacs buffers)

 in the shell I type:

   xdvi foo.dvi &

 which starts xdvi in a separate process. Every time I rebuild the .dvi file
 and give the focus to xdvi it rereads the .dvi file. So this allows me to
 keep the fully formatted file always available and up to date on the screen.

   (C-x o     switches between buffers)
   
 now I can edit the foo.pamphlet buffer and make changes. When I want to
 rebuild the file I do:

   (C-x o     switches between buffers (over to the *shell* buffer))
   make -f Makefile.foo
   (C-x o     switches between buffers (back to foo.pamphlet))

 and then slide the mouse over to the xdvi window and *poof* ... all
 of my file is newly formatted and the foo program is loaded and the
 tests are run.

 It's all very efficient. Of course, your mileage may vary.

\start
Date: Sat, 26 Nov 2005 17:29:45 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: Axiom Wiki FrontPage re-design

On November 26, 2005 4:22 AM Martin Rubey wrote:
> 
> Bill Page writes:
> 
> > a new look for the Front Page for the Axiom Wiki:
> > 
> > http://wiki.axiom-developer.org/SandBoxFrontPage
> 
> I think that it looks *very* nice -- especially the colors are
> well chosen. Before adoption, I would like to think about it, 
> however. Please give me a little more time.

No problem. Make changes to it if you like. Let me know if/when
you would like me to replace it as the new FrontPage.

> 
> > I agree that the MathAction link is not important to new 
> > Axiom users. I hope this alternate page layout makes this
> > more clear.
> 
> WHAT? Do I parse this sentence correctly? 
> 

No, I think you did not understand my intention. It is taken
a bit out of context. The "MathAction link" to which I was
referring is a link to the 'MathAction' page. I would have liked
to have called this page 'AboutMathAction' so there would be less
confusion about the page with this name versus the two websites
with this name. But my attempt to rename the page caused the
flood of edit emails on the axiom-developer email list because
by default on the Axiom Wiki everywhere 'MathAction' is used
it is automatically interpreted as a link to the page with
that name because of the so called 'WikiWord' convention that
a word with two or more capitals should be treated as a link.

I cancelled the rename operation so the name remains 'MathAction'
perhaps at some time in the next few days I will temporarily
disable the email forwarding and let the rename complete.

> I am *absolutely* certain that MathAction is of utmost 
> important to new Axiom users. All of the documentation can
> be found there, examples how to use it (SandBox), bugs that
> show Axioms deficiencies...

What I am saying is the detailed information on the 'MathAction'
page about how the **web site** works is not very important to
a new user of Axiom. All they want to do is know more about
Axiom - not about the web site itself (at least I think that
is usually the case).

I definitely did not mean to say that the web site is not
important!

\start
Date: Sat, 26 Nov 2005 22:56:02 -0500
From: Tim Daly
To: Bill Page
Subject: re: Axiom Wiki FrontPage re-design

Bill, 

I'm trying to get to IssueTracker. I can get to page.axiom-developer.org
but trying to go to Axiom Portal or MathAction Wiki hangs.

\start
Date: Sat, 26 Nov 2005 23:17:45 -0500
From: Tim Daly
To: Camm Maguire
Subject: debian stable bug?

Camm,

Tim (not me) tried to build axiom on debian STABLE.
Somewhere in the configure it tries to do a sed into conftest.subs

eventually it issues the failure
%@EMACS_SITE_LISP@%Warning: Lisp directory '/usr/local/share/emacs/21.3/site-lisp%g

s%@EMACS_DEFAULT_EL@%Warning: Lisp directory '/usr/local/share/emacs/21.3/site-lisp' does not exist

Warning: Lisp directory '/usr/local/share/emacs/site-lisp' does not exist


doing a few 'mkdir -p /usr/local/share/emacs/....' eventually fixes the 
problem.

\start
Date: Sat, 26 Nov 2005 22:27:14 -0500
From: Bill Page
To: Tim Daly
Subject: re: Axiom Wiki FrontPage re-design

Tim,

I think RoseHosting must be having some computer or
network problems. The axiom-developer.org site has been
very unreliable for me over the last 3 or 4 days. But
I have also had problems with the local Internet connection
here at home and also where I work, so I was not sure
whether to blame the network or the server.

Right now I am not even able to access axiom-developer.org
via ssh. Perhaps you can ask them to re-boot the server?

> -----Original Message-----
> From: root [mailto:Tim Daly] 
> Sent: November 26, 2005 10:56 PM
> To: Bill Page
> Cc: list
> Subject: re: Axiom Wiki FrontPage re-design
> 
> 
> Bill, 
> 
> I'm trying to get to IssueTracker. I can get to 
> page.axiom-developer.org but trying to go to Axiom Portal
> or MathAction Wiki hangs.
> 

\start
Date: Sat, 26 Nov 2005 23:31:14 -0500
From: Tim Daly
To: Bill Page
Subject: re: Axiom Wiki FrontPage re-design

i'm on it. the load is 3.5 and 'plone' is running using 18% of the cpu.

\start
Date: Sun, 27 Nov 2005 01:04:08 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [StructuredText] Hints for using Structured Text

I have changed the **point-and-click** menu that appears below the
'comment' and the 'edit' windows to include some basic some
basic help for StructuredText commands. This works the same way
as for Axiom commands, LaTeX commands, and Latex Symbols.

For example clicking on '**' in the header of the 'Text' area will
display a list of commonly used methods for text highlighting.
To add bold highlighting select some text in the comment or edit
box and click::

  **bold**

This will insert the necessary markup.

If you have any questions about this, please ask.

\start
Date: Sun, 27 Nov 2005 14:43:50 -0500
From: Tim Daly
To: list
Subject: painting on a canvas in a browser

It appears that there is a working draft which includes a canvas
element for html. that would allow us to put the live 3d graphics
in a web page. see

http://www.whatwg.org/specs/web-apps/current-work/#multimedia

\start
Date: 27 Nov 2005 16:52:02 -0500
From: Camm Maguire
To: Tim Daly
Subject: Re: debian stable bug?

Greetings!

Tim Daly writes:

> Camm,
> 
> Tim (not me) tried to build axiom on debian STABLE.
> Somewhere in the configure it tries to do a sed into conftest.subs
> 
> eventually it issues the failure
> %@EMACS_SITE_LISP@%Warning: Lisp directory '/usr/local/share/emacs/21.3/site-lisp%g
> 
> s%@EMACS_DEFAULT_EL@%Warning: Lisp directory '/usr/local/share/emacs/21.3/site-lisp' does not exist
> 
> Warning: Lisp directory '/usr/local/share/emacs/site-lisp' does not exist
> 
> 

OK, I think I've fixed this in 2.6.8pre and cvs head.  Please let me
know if problems persist.  BTW, who are you? :-)

Take care,

> doing a few 'mkdir -p /usr/local/share/emacs/....' eventually fixes the 
> problem.

\start
Date: Sun, 27 Nov 2005 18:26:07 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: debian stable bug?

i'm tim of axiom.

Tim, mentioned in the post, is my son.
He build Axiom on debian stable.

\start
Date: Sun, 27 Nov 2005 22:01:11 -0500
From: Bill Page
To: Tim Daly
Subject: Re: Axiom Wiki FrontPage re-design

On November 26, 2005 9:07 AM Tim Daly (root) wrote:

> ... 
> Bill, is it possible to set up "public personal pages" on a 
> per-user basis? Nothing fancy, just a place to scribble similar
> to email. I suppose it could either be organized by topic
> (newsgroups) or just a linear page or both.
> 

Yes, certainly. That already exists as a function of the
Axiom Portal:

http://portal.axiom-developer.org

Every registered user of this web site has a "home page" which
they can edit and maintain like "blog" if they like. It is also
possible to set up the home page as a personal "Axiom wiki" that
has the same capabilities as the main Axiom Wiki.

Of course, nothing prevents your for maintaining your own page
or set of pages on the Axiom Wiki itself.

If you need some help getting started, just ask. I would be glad
to describe in detail how to set this up.

\start
Date: Mon, 28 Nov 2005 14:42:29 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: article "standard" header/footer

Dear Tim,

I think, it's a good idea that you've posted this "standard". I hope it 
is still in an "discussion" state. I had a quick look at it and there 
are some parts where I would restructure a bit. For other parts I need 
to make up my mind first, so this will take some time.

Just one quick comment... there are several places where you use TeX 
syntax. I'd prefer to promote LaTeX (it's \newpage instead of \eject).
In fact I don't like to see \eject at all. It is the task of the .cls 
file to decide on the pagebreaks --> So maybe "\documentclass{report}" 
would be more appropriate.

What I have seen is that axiom.sty in some way includes the whole of 
noweb.sty and adds some commands related to Axiom. I would rather like 
to see a structure like

\documentclass{...}
\usepackage{metaaxiom}
\begin{document}
...
\end{document}

where metaaxiom.sty (or whatever you call it) whould be the name of a 
package that simply includes all the other packages that are needed. 
Also makeidx and hyperref should appear inside metaaxiom.sty via

\RequirePackage{makeidx}

Please remove

\begin{thebibliography}{99}
\bibitem{1} nothing
\end{thebibliography}

It is old technology. We should promote BibTeX. It would be much easier 
to maintain.

I'll write a follow-up later...

Anyway, I like the idea with \author{} and abstract. Maybe I should 
learn about the term "executive overview". I am not quiet sure what 
"executive" stands for in this phrase. Isn't it a kind of "Introduction" 
what Martin wants? So what could possibly be the difference between 
"Introduction" and "Executive Overview"?

\start
Date: Mon, 28 Nov 2005 10:15:42 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

> I think, it's a good idea that you've posted this "standard". I hope it 
> is still in an "discussion" state. I had a quick look at it and there 
> are some parts where I would restructure a bit. For other parts I need 
> to make up my mind first, so this will take some time.

everything is always in the "discussion state" but sometimes i just
press ahead and try to keep things moving. the "standard" is changing
rapidly due to your allprose hacking. "quick consensus and running
code" as they say in the RFCs. 

> 
> Just one quick comment... there are several places where you use TeX 
> syntax. I'd prefer to promote LaTeX (it's \newpage instead of \eject).
> In fact I don't like to see \eject at all. It is the task of the .cls 
> file to decide on the pagebreaks --> So maybe "\documentclass{report}" 
> would be more appropriate.

\newpage is fine. i'm an old tex person so i tend to use $$, \eject, etc
without knowing that there are "new tex standards" and upgrades. until
someone takes the time to inform me i don't even know to look.

> What I have seen is that axiom.sty in some way includes the whole of 
> noweb.sty and adds some commands related to Axiom. I would rather like 
> to see a structure like
> 
> \documentclass{...}
> \usepackage{metaaxiom}
> \begin{document}
> ...
> \end{document}

well, i'm WAS planning to do a document-and-cleanup cycle on axiom.sty
so that (a) only the things that are used survive (there is cruft from
history in there (b) it formats nicely so i can append it to stand-alone
documents and (c) the macros are documented like everything else. i haven't
done that yet due to time. i did merge a couple macros from other packages
so that we could write axiom documents that only depend on 1 package and
we could include that package as part of the .pamphlet file. i hate
getting documents i can't format because the author hasn't included
ALL of the tree of .sty files. 

plus noweb (WAS) planned to go away in favor of an axiom
implementation that had different features (like support for .booklet
files which use an optional URL syntax in chunk names). that may still
happen but it is open for discussion.

> 
> where metaaxiom.sty (or whatever you call it) whould be the name of a 
> package that simply includes all the other packages that are needed. 
> Also makeidx and hyperref should appear inside metaaxiom.sty via
> 
> \RequirePackage{makeidx}
> 
> Please remove
> 
> \begin{thebibliography}{99}
> \bibitem{1} nothing
> \end{thebibliography}
> 
> It is old technology. We should promote BibTeX. It would be much easier 
> to maintain.

sigh. old technology again. ok. propose something different for the
bibliography. i started on the bibtex thing (there is a bibtex.pamphlet
the src/doc directory which would collect annotated bibtex references
so we could keep them in one place and have a fully documented bibliography.
if you suggest what you'd like to see we can figure out how to connect it
to the bibtex.pamphlet and then spread the new machinery all over axiom.

> 
> I'll write a follow-up later...
> 
> Anyway, I like the idea with \author{} and abstract. Maybe I should 
> learn about the term "executive overview". I am not quiet sure what 
> "executive" stands for in this phrase. Isn't it a kind of "Introduction" 
> what Martin wants? So what could possibly be the difference between 
> "Introduction" and "Executive Overview"?

i tried to figure out the \author of each file. the basic rules i used were
   (1) if the author's names appears in the file use them
   (2) if i knew who wrote the file credit them
   (3) if there were more than 5 authors use 'the axiom team'
   (4) default to 'the axiom team'
credits are, at best, a guess and should be corrected if we learn more.
personally i favor a very liberal credit policy, almost to the point of
"you touched it, you own it". if you start axiom and type:

 -> )credits

you'll see a list i maintain of all of the people who seem to have
contributed. having just done that now i see your name is not on that
list (i'll correct that in the next release). when time permits i run
back over my email and add new people.

re: "Introduction" and "Executive Overview"?

are you familiar with the dilbert cartoon? think of the pointy-haired
boss as your target audience.  an "Executive Overview" is written for
someone who first visits the file and has no clue what is going
on. calling it an "Introduction" tends to make people want to write 5
lines of documentation with a target audience of the experienced
user/developer. the intent is to assume much less knowledge in your
target audience.

the "book standard" is coming... it's been busy here at the circus.

\start
Date: Mon, 28 Nov 2005 10:56:28 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

On November 28, 2005 8:42 AM Ralf Hemmecke wrote:
> ... 
> Anyway, I like the idea with \author{} and abstract. Maybe I
> should learn about the term "executive overview". I am not quite
> sure what "executive" stands for in this phrase. Isn't it a kind
> of "Introduction" what Martin wants? So what could possibly be
> the difference between "Introduction" and "Executive Overview"?
>

The usual phrase is "Executive Summary". It is:

  A nontechnical summary statement designed to provide a quick
  overview of the full-length report on which it is based.

I think this is a good reference:

http://www.columbia.edu/~ftg1/WRITING%20EXECUT.SUMMARY.html

\start
Date: 28 Nov 2005 16:57:54 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: article "standard" header/footer

Ralf Hemmecke writes:

> Maybe I should learn about the term "executive overview". I am not quiet sure
> what "executive" stands for in this phrase. Isn't it a kind of "Introduction"
> what Martin wants? So what could possibly be the difference between
> "Introduction" and "Executive Overview"?

I'm not quite sure what I wanted some months ago, but I suggest the following:

Many contributions consist of several packages, categories and domains, which
are somehow related. We should have documentation for users (!!!) that consists
of the following:

* a short introduction to what the contribution does. An example can be found
  by clicking "examples" in HyperDoc after browsing "RECLOS". For my guessing
  package, it would be everything following the section "Using the package" at 

http://page.axiom-developer.org/zope/mathaction/GuessingFormulasForSequences

  However, this is a bit longish for my taste.

* For every constructor (package, domain, category) a short description what it
  does.  This is the ++ description of the package.

* For every operation a short description what it does. Again, this is the ++
  description of the package.

* Maybe we also need an indroduction that *roughly* describes the mathematical
  background. This would be everything up to "Using the package" in my Guessing
  package example and would not contain details. The details should probably go
  along with the program. This would not contain code, only mathematics.

  Unfortunately, I do not yet have such a description in pamphlet format for my
  guessing package. I attach a draft at the end of this mail. Note however,
  that this is outdated material.

I think that the way these bits of documentation are presented in HyperDoc is
just perfect. I don't think that it would be too difficult to make ALPROSE do
the same. In principle, HyperDoc is a collection of hyperlinked pages -- just
as ALPROSE when viewed in a browser and not a dvi-viewer.

I.e., we would need to devise a tex4ht interface for ALPROSE that suitable
splits the input into a tree of subpages, which can then be accessed by
selecting an item from the index...

Finally I'd like to stress that I strongly believe that AxiomUI should use the
same file format as the documentation. There is no semantic difference between
a worksheet and a literate program, except that a worksheet will be
interpreted, not compiled.


Martin

-------------------------------------------------------------------------------

\section{Guessing formulas with an Abelian term}
In this section we explain in detail how \verb|guessExpRat| works.

The basic idea is to reduce the problem to rational interpolation. Let
$s=(s_1,s_2,\dots,s_m)$ be the given list of values, which are elements of a
field $\mathbb K$. We then follow the following algorithm for each pair $(k,
l)$ with $k+l=m-4$:

\begin{itemize}
\item Let $y_n=s_n (a+bn)^{-n}$, where $a$ and $b$ are indeterminates.
\item Let $p$ be the result of interpolating $(y_1,y_2,\dots,y_{m-3})$ using
  rational interpolation, where the degree of the numerator is $k$, the degree
  of the denominator is $l$.
\item Let $p_i=\numer\left(p(i+m-3)-y(i+m-3)\right)$ for $i\in\{1,2,3\}$.
\end{itemize}
It remains to solve the system of the three polynomial equations $p_i = 0$,
$i\in\{1,2,3\}$ in the two variables $a$ and $b$.
%, such that $a$ and $b$ do not both vanish. 
This can be done reasonably efficiently using resultants:

\begin{itemize}
\item Substitute $A-mb$ for $a$ in the three polynomials $p_1$, $p_2$ and
  $p_3$.
\item Let $r_1=\resultant(p_1, p_3, A)$ and $r_2=\resultant(p_2, p_3, A)$.
\item Compute $r_3=\gcd(r_1, r_2)$ and calculate the solutions $\tilde A$ of
  $r_3=0$. For simplicity, we consider only those that are elements of the
  field.
\item For each $\tilde A$ calculate the solutions $\tilde a$ of $p_2(\tilde
  A, \tilde a)=0$ that satisfy $p_3(\tilde A, \tilde a)=0$, too.
\item If such a solution can be found return $\left(\tilde A + \tilde b
    (n-m)\right)^n p(\tilde a,\tilde b)$ as a formula generating the sequence
  $s$.
\end{itemize}

Clearly, the method to solve three polynomial equations in two unknowns just
outlined is feasible only when the degree of the polynomials is not too large.
The substitution in the first step results in a much lower degree of the
polynomial $p_3$, which speeds up the process significantly. Still, for
sequences with more than about $7$ terms, it is too slow to be useful.
However, numerical evidence supports the following conjecture:

\begin{cnj}
  The order and the degree of the polynomials $r_1$ and $r_2$ is given by the
  following formulas, where $n=m-i$, $m$ is the number of terms in the given
  sequence $s$ and $i$ is the degree of the numerator in $p$:
  \begin{align*}
    \ord r_1 &= \frac{(n - 1)n(3n^2 - n + 2)}{12}\\
    \deg r_1 &= \frac{(n - 1)(3n^3 + (12i + 5)n^2 + (12i^2 + 6i + 20)n 
                             - 12i^2 + 12i + 12)}{12}\\
    \ord r_2 &= \ord r_1 +
    \begin{cases}
      \frac{n(n-1)}{2} &\text{if $i=0$}\\
      0                &\text{otherwise}
    \end{cases}\\
    \deg r_2 &= \deg r_1 + \frac{n^2+(2i+1)n-2i+2}{2}.
  \end{align*}
\end{cnj}

Thus, since it appears that the two resultants have very large orders, it makes
sense to calculate them by interpolation. For example, the values of 
$$\resultant(p_1(A=k),p_3(A=k)) k^{-\ord res_1}$$
at $k\in\{1,2,\dots,\deg r_1-\ord r_1+1\}$ determine $r_1$ uniquely.

Although this yields a significant speedup for sequences longer than $7$ terms,
more work needs to be done to be able to guess more complicated formulas with
\verb|guessExpRat|. For example,
\begin{verbatim}
  guessExpRat(n, [(2*n+3)^n*(4*n^3+3*n^2+2*n+1) for n in 1..7], 
              n+->n)$GuessInteger
\end{verbatim}
takes roughly $13$ seconds, while
\begin{verbatim}
  guessExpRat(n, [(2*n+3)^n*(5*n^4+4*n^3+3*n^2+2*n+1)
                  for n in 1..8], n+->n)$GuessInteger
\end{verbatim}
takes already $55$ seconds on a {\tt Pentium III} with $900$ megahertz and
$512$ Megabytes of memory.

Note that care has to be taken if the original sequence contains zeros. In this
case it might happen that $(a + bn)$ vanishes for some $n\in\{1,2,\dots,m\}$
and the formula would not be found. In this case we set $z(n)=\prod_{s_i=0}
(n-i)$ and $s^\prime$ to the sequence $s$ with the zeros omitted. Then we apply
\verb|guessExpRat| to the list $\left(s^\prime_1/z(1), s^\prime_2/z(2),\dots,
  s^\prime_m/z(m)\right)$ and multiply the results with $z(n)$.

\section{Further work}

To conclude, we would like to point out future directions:
\begin{itemize}
\item Obviously, it would be nice to be able to guess formulas of a more
  general type then those guessed by \verb|guessExpRat|. This would involve
  finding a fast algorithm that tests whether an overdetermined systems of
  equations has a solution. Much work has been done in this direction, for
  starting points see \cite{CoxLittle, EmirisPan2005, Khetan}, but strange
  enough, the naive elimination algorithm detailed above seems to be the
  fastest method available currently.

\item We did not yet implement a guessing algorithm that covers algebraic
  differentially finite functions.
  
\item Finally, maybe there are other interesting operators besides $\Delta_n$
  and $Q_n$ that could be applied to the sequence. The list of transformations
  used in \emph{The online encyclopedia of integer sequences} is available, so
  it might be rewarding to check, which of those extend the class of functions
  already covered significantly.
\end{itemize}

\start
Date: Mon, 28 Nov 2005 17:35:29 +0100
From: Ralf Hemmecke
To: Martin Rubey,
Subject: re: article "standard" header/footer

Hello Martin,

> I.e., we would need to devise a tex4ht interface for ALPROSE that suitable
> splits the input into a tree of subpages, which can then be accessed by
> selecting an item from the index...

I'll think about it, but first I need some time to let tex4ht swallow 
the things reasonably. I had some minor success, but I had to switch to 
"quiet" latex mode, because there were too many errors. But at least 
there was a html page coming out. Not the best but it somehow motivated 
me that the html thing could be done.

And please leave the name ALLPROSE (with two L) as it is. If you google 
for alprose and allprose you certainly recognise one reason for the 
name. The other one is simple: it is just ALL-PROSE, isn't it? ;-)

\start
Date: Mon, 28 Nov 2005 17:37:02 +0100
From: Ralf Hemmecke
To: Martin Rubey,
Subject: re: article "standard" header/footer

Hello Martin,

> I.e., we would need to devise a tex4ht interface for ALPROSE that suitable
> splits the input into a tree of subpages, which can then be accessed by
> selecting an item from the index...

I'll think about it, but first I need some time to let tex4ht swallow 
the things reasonably. I had some minor success, but I had to switch to 
"quiet" latex mode, because there were too many errors. But at least 
there was a html page coming out. Not the best but it somehow motivated 
me that the html thing could be done.

And please leave the name ALLPROSE (with two L) as it is. If you google 
for alprose and allprose you certainly recognise one reason for the 
name. The other one is simple: it is just ALL-PROSE, isn't it? ;-)

\start
Date: Mon, 28 Nov 2005 09:01:36 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Ralf Hemmecke
Subject: re: article "standard" header/footer

--- Tim Daly wrote:

> > I think, it's a good idea that you've posted this
> > "standard". I hope it is still in an "discussion" state. I
> > had a quick look at it and there are some parts where I 
> > would restructure a bit. For other parts I need 
> > to make up my mind first, so this will take some time.
> 
> everything is always in the "discussion state" but sometimes 
> i just press ahead and try to keep things moving. 

That's a Good Thing.  

> the "standard" is changing rapidly due to your allprose 
> hacking. "quick consensus and running code" as they say in the
> RFCs. 

For what it's worth, I would estimate I'll eventually ask to have the
following available, since they are very standard and too big to reall
:

1) hyperref (which I see you've already decided to include)
2) bibtex (I'm working on an example based on the units work, but I
will need to do some thinking before I have a good example ready)
3) XYpic - I think this is gong to prove very very useful once I figure
out how to use it properly - it seems like it might potentially allow
inclusion of graphs directly into pamphlet files and not as graphical
files, among other features - I think it will also allow hyperlinking
nodes of graphs to code, although I'm still trying to come up with a
scheme for layout of such a graph which looks reasonable. 
Unfortunately it is GPL so we can't include it in axiom.sty, but tetex
at least includes it by default so I'm guessing it wouldn't be too much
trouble.  Maybe we could contact the authors and ask if it becomes an
issue.

ifthen and fontenc I'm willing to pass up, but I would like to know how
we will handle:

a)  different options to hyperref based on pdf or dvi creation
b)  line breaking of equations
c)  specifying different sizes, fonts, etc for text.  This is probably
just my ignorance of LaTeX

Unless the breqn package license becomes clarified or someone
reimplements (and maybe expands on) the techniques as part of axiom.sty
I'm not sure what to do.  So far AMS does not seem to be responding to
the issue: 
https://www.redhat.com/archives/fedora-extras-list/2005-November/msg01029.html
 There are documents where the author tried to describe the algorithms
he was using, so perhaps that would be a useful starting point.

I didn't get in until late Sunday, so I haven't had a chance yet, but I
will put together some examples illustrating what each of these
packages is capable of, and the benefits they can provide.  At the same
time, I'll be posting the current state of the Units and Dimensions
writeup - feel free to tear it up, but remember it's still very much a
work in progress and there are still missing/incomplete parts,
formatting inconsistencies, and plain silliness in abundance.

\start
Date: Mon, 28 Nov 2005 09:05:17 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Website down?

Anybody else getting a HTTP 500 - Internal server error?

\start
Date: Mon, 28 Nov 2005 13:22:14 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Website down?

On November 28, 2005 12:05 PM C Y asked:
> 
> Anybody else getting a HTTP 500 - Internal server error?
> 

It's working for me right now. I have not re-set and or changed
anything since last night (about 10:00 pm Eastern Time. I have
noticed that occassionally I get very poor response times (20 or
30 seconds per page). I am beginning to think that there might be
intermittent problems at the ISP where we run axiom-developer.org.

The other possibility is that the once in a while the access rates
to the server exceeds it's capacity to respond in time. This
could especially be the case for Zope application server which
is known to require significant system resourses compared to more
conventional web server software. There are some things that can
sometimes be done to "tune" Zope performance and I will look into
that some more later today.

The web site runs on a shared virtual server and I suppose that
it is possible that other users of the same server have recently
begun to use more system resources than we are used to seeing.
On the other hand, the process status shows that this system now
spends a lot of time waiting for disk access. I don't think that
used to be the case. So I don't really know what is going on.

I don't really trust shared servers very much and if "we" could
afford it, I think it would be much better if we could run the
web site on a dedicated server. But that would probably cost at
least twice as much per month. I wrote "we" in quotes because in
fact Tim Daly (root) is still paying 100% of the cost of operating
this server from his own financial resources. I really wish that
we (no quotes this time) could do something about sharing this
cost and upgrading the service.

Please let me know if you are still having problems accessing

http://wiki.axiom-developer.org

\start
Date: Mon, 28 Nov 2005 11:27:41 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: Website down?

--- Bill Page wrote:

> I really wish that we (no quotes this time) could do something
> about sharing this cost and upgrading the service.

Agreed.  Perhaps a university somewhere could be persuaded to host it?
 
> Please let me know if you are still having problems accessing
> 
> http://wiki.axiom-developer.org

Working fine now.  Must have been a temporary problem.

\start
Date: Mon, 28 Nov 2005 22:25:05 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: MathAction to email list connection

Page, Bill wrote:
> On Friday, November 25, 2005 4:51 AM Ralf Hemmecke wrote:
> 
>> Bill Page wrote:
>>> ... 
>>> Perhaps this is a good time to suggest that we disconnect the
>>> axiom-developer email list from the Axiom Wiki web site?
>> Good idea. I usually just remove those emails. A much better 
>> idea would be to post a FAQ every month. Or just a link to a
>> FAQ at MathAction. Wouldn't that help people to get aware of
>> MathAction and what one can do with it?
> 
> I will check to see if there is some way on the axiom-developer
> and axiom-mail email list server to setup such a "once per
> month" message to subscribers. I think that is a good idea as
> long as I do not have to remember to do it each month.

If people want to get notified about changes at MathAction they should 
subscribe to a corresponding mailing list. There is already one, right?

>> Personally I cannot remember that I have ever changed anything 
>> on a MathAction page. The problem with too much text also 
>> applies here.
> 
> That is a pity. It is the explicit purpose of the Axiom Wiki
> site that Axiom developers will actively make changes to the
> site and help improve it's organization. Everyone has unlimited
> ability to edit the pages, delete and reorganize content, and
> and new material. A wiki is an open interactive environment that
> is supposed to take advantage of the fact that anyone with an
> interest in the subject can contribute to it's documentation.

I understand the principle, but even though I consider myself somewhat 
related to Axiom, I don't yet think that I should modify the texts of 
other people (even if MathAction is intended to do so). There is some 
psychological barrier. Maybe I am not the only one who feels like this.
Well, I must admit that I have not yet time enough to really play with 
MathAction, but if I do so for the first time, I would rather like that 
nobody sees my stupid modifications.

> If you ever feel motivated 

I am

> and have the time,

*smile*

> I would encourage you the shorten and re-write portions of the pages
 > on this web site based on your own experience and knowledge.

As I said, I first need to get the right feeling for MathAction.

> that is not the point. A wiki web site is not based on the
> traditional model of "publishing" a site for others just to view.
> It is supposed to be an interactive collaborative environment.

I understand, but it's a bit like changing one's editor... one has to 
become accustomed to this new kind of collaboration.

Don't be afraid, I'll try to do my share to make to Axiom project 
successful, but I cannot work on all branches. In fact, I would rather 
like to work on the Algebra, but I feel that the underlying 
documentation structure is not yet optimal (at least not the way I would 
like to see it). And anyway, I am waiting for the Aldor compiler to 
become open source.

\start
Date: Tue, 29 Nov 2005 00:11:20 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: MathAction to email list connection

> Here is a draft alternate page to be displayed when you on (2):
> 
> 2'. http://www.axiom-developer.org/zope/mathaction/SandBoxFrontPage
> 
> Do you think that organization of this new page would be easier
> to understand for new Axiom users?

Oh, just beautiful!!!

\start
Date: Tue, 29 Nov 2005 00:41:26 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Axiom Wiki FrontPage re-design

>> On Friday, November 25, 2005 4:51 AM Ralf Hemmecke wrote:
>>> ... I don't think that it is actually the amount of text 
>>> which is a problem, it is rather its organisation.

> I agree partially. You are probably right that the amount is less of
> a problem than it's organisation.

Exactly. If there is a bug somewhere, it is probably better if you have 
as much information as possible (which is hopefully not out of sync).

>> I agree that the MathAction link is not important to new Axiom users. I hope
>> this alternate page layout makes this more clear.
> 
> WHAT? Do I parse this sentence correctly? 

> I am *absolutely* certain that MathAction is of utmost important to new Axiom
> users. All of the documentation can be found there, examples how to use it
> (SandBox), bugs that show Axioms deficiencies...

Hmmm, being new to Axiom, the first thing I would want is a Guided Tour 
(10 min). If I am still interested, a little more detailed tour. Only 
after that I am knowledgable enough to navigate through MathAction, ie, 
I am not longer (completely) "new".

> Again: I think that our aim should be to make MathAction be the
> *only* entry point to the Axiom world. To reach this aim, one of the
> first steps -- a huge step though -- would be to make the pamphlet
> files and the book browsable. Here goes a big THANK YOU to Bill for
> providing the sources of Axiom on MathAction!

Call me old-fashioned, but in order to edit pamphlet files, I would get 
the arch-sources and do something locally and then submit. Only for 
small changes the web-access to the sources makes sense to me. Anyway, 
it is not quite clear to me how modifications to the sources made over 
the web will eventually find their way into axiom--main. Will Tim 
incorporate them by hand? I guess the ChangeSet idea becomes a bit 
blurred here.

> What remains is an expert on tex4ht. Reminder: Eitan promised to have a look
> how to make jsmath a backend for tex4ht this winter break. Ideally, we (well,
> sorry, not me) would have some experience with translating the tex code
> produced by "ALLPROSE" or "document" into mathml / html with tex4ht.

I'll look into tex4ht. I first have to understand how it works.

> Another step is to transform the pamphlet files into the ALLPROSE format --
> and, if necessary, extend ALLPROSE so that it can handle Axiom. Ralf, am I
> correct that this is not really necessary?

Oh, wait a minute. ALLPROSE is for writing Aldor libraries. And I 
somehow tend to keep it that way. For example, ALLPROSE contains 
aldordoc.sty, which is certainly of no interest to the LISP parts of Axiom.

However, I can extract  certain features that are of general interest 
for the whole of the Axiom documentation. I'd be happy to help Axiom 
here. But I will certainly not touch the semantics of building the Axiom 
executable.

\start
Date: Tue, 29 Nov 2005 01:26:09 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: article "standard" header/footer

Hi Martin,

Could you set up a page on MathAction of this discussion thread? Or 
better, could someone tell me how to create a new page.

What you state here are some visions that should be recorded and not be 
forgotten in the mailinglist-archive.


Martin Rubey wrote:
> Ralf Hemmecke writes:
 
>> Maybe I should learn about the term "executive overview". I am not
>> quiet sure what "executive" stands for in this phrase. Isn't it a
>> kind of "Introduction" what Martin wants? So what could possibly be
>> the difference between "Introduction" and "Executive Overview"?
 
> I'm not quite sure what I wanted some months ago, but I suggest the
  following:

> Many contributions consist of several packages, categories and domains, which
> are somehow related.

You see, I also somehow realised that. The Axiom Library would grow in 
bigger steps, not just one cat/dom/pkg at a time. We should start to 
think in Aldor terms. A certain part of mathematics is covered by a 
number of packages, categories and domains. These form one small library 
and are documented together. ALLPROSE could be the environment to 
describe the whole library. And that could form a (refereed) paper in an 
Axiom journal.

> * Maybe we also need an indroduction that *roughly* describes the
>   mathematical background.

Of course together with references to the literature.

>   This would be everything up to "Using the package" in my Guessing
>   package example and would not contain details. The details should
>   probably go along with the program. This would not contain code,
>   only mathematics.

I agree that it is sometimes easier to read the mathematics, but when it 
comes to the algorithmic part... why not writing real code instead of 
pseudo-code?

> I think that the way these bits of documentation are presented in HyperDoc is
> just perfect. I don't think that it would be too difficult to make ALPROSE do
> the same. In principle, HyperDoc is a collection of hyperlinked pages -- just
> as ALPROSE when viewed in a browser and not a dvi-viewer.

My problem with HyperDoc is that there are quite a number of commands 
and no good documentation what they are for. I would clearly prefer my 
aldordoc.sty even though it does not cover all things HyperDoc can do.

> I.e., we would need to devise a tex4ht interface for ALPROSE that suitable
> splits the input into a tree of subpages, which can then be accessed by
> selecting an item from the index...

I've already read in the tex4ht documentation that it can split 
according by \section and \subsection etc. So the most important thing 
is to produce HTML at all.

> Finally I'd like to stress that I strongly believe that AxiomUI
> should use the same file format as the documentation. There is no
> semantic difference between a worksheet and a literate program,
> except that a worksheet will be interpreted, not compiled.

Sorry that I am a bit behind, but I have tried to install jsmath and 
somehow I remember that my Firefox claims that some font is missing. So 
I gave up and thus I have never really seen AxiomUI. On which files does 
it work? Is it a replacement for HyperDoc? Or what is the relation? Is 
there a link to a documentation about AxiomUI.

\start
Date: Tue, 29 Nov 2005 00:50:32 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: re: Axiom Wiki FrontPage re-design

Hi Tim,

root wrote:
>> Again: I think that our aim should be to make MathAction be the
>> *only* entry point to the Axiom world.
> 
> Email has one property that a website lacks. It forms a private
> linear queue of work for me to accomplish (or not :-)).

Well, agreed. But you are certainly not new to Axiom. I also rather read
the mailing list than working on MathAction, but you must agree, that it
is easier to understand Axiom if one starts from MathAction than from
axiom-developer or axiom-mail or whatever. MathAction links to the
mailing lists so it is easy to arrive there. But I think it is easier to
maintain a nice guided tour than several different views on Axiom and
not telling the user how these views are related.

> Thus it gives me my own stream of information.

But nobody wants to steal that stream from you (at least it's not me).

\start
Date: Tue, 29 Nov 2005 03:04:04 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: article "standard" header/footer

Hi Tim,

root wrote:
> Ralf,
> 
> I promised to give you some idea of the pamphlet and book file coding
> "standards". This is the current "state of the world" which evolves
> as I write more pamphlet files. However, as I re-edit old files I
> modify them to conform to these standards.

In ALLPROSE I have specifically introduced a "Convention" environment 
since I found myself using some conventions that were nowhere else 
documented. So the pamphlet standards should go into a section of the 
Axiom book (part documentation).

> Each file I make into a "literate program" has a "head" and a "tail"
> that contains essentially the same code for the same reasons. The only
> major deviation is that I will occasionally include the "axiom.sty" file
> in the literate document if it is meant to be stand-alone and the user
> is unlikely to have it.

Sorry, but I cannot completely agree here. I would NEVER include 
axiom.sty into the document. It would be duplication of code and hard to 
maintain.

I also do not agree to the goal that each file is ONE literate program 
and in some sense stand alone. I, therefore, think that "head" and 
"tail" should not be part of a file, just the things that are inside the 
\begin{document} ... \end{document}.

If you like a wrapper, write a little script like "document" which adds 
"head" and "tail" on the fly. You design them to be equal anyway.

Then, I don't see, why we need standards for "article" and standards for 
"book" and why they should/could differ.

The Axiom book consists of parts. Each part covers a certain area of 
Axiom. So a Part consists of some "executive summary" and then includes 
the code (ehm pamphlet) files that belong to that part.

So the focus is on providing the parts. In the spirit of ALLPROSE that 
could mean the following:

1) Write some chapters about the general idea.
Then a chapter that lists the files names (of the files that form the 
contents of the book) together with a short description of what the 
corresponding file contains. Then simply include all those files.

2) So there are several (about as many as there are parts) special 
files. I call them part.pamhlet files. All other files are ordinary 
pamphlet files.

3) Each pamphlet should be reasonably self-contained. In particular, a 
script could select several pamphlet files and compile them together 
into one document. (An "executive summary" could be missing if it is not 
explicitly included, but who cares?)

> =======================================================================
> \documentclass{article}               
> \usepackage{axiom}
> \usepackage{makeidx}
> \makeindex
> \begin{document}
> \title{no title}
> \author{Timothy Daly}
> \maketitle
> \begin{abstract}
> \end{abstract}
> \eject
> \tableofcontents
> \eject
> \section{Executive Overview}
> =======================================================================


What about just...

\begin{History}
   \logitem{DATE1}{AUTHOR1} DESCRIPTION1
   \logitem{DATE2}{AUTHOR2} DESCRIPTION2
\end{History}
\begin{abstract} ... \end{abstract}
\begin{ExecutiveSummary} ... \end{ExecutiveSummary}
\begin{Content} ... \end{Content}

If you like \title, no problem, but in the book it will probably 
translate into \chapter. In ALLPROSE, the filename is wrapped into a 
\section command via \nwfilename (generated by noweb).

The History could be translated into an \author command by LaTeX or a 
script. It does not mean that the History information shows in the book, 
but it would be in the file for those who dig that deep.

It would be \newenvironment{Content}{}{}, so it is a shield against 
redefining commands within that environment, but is not really 
necessary, since a script could add such an environment on the fly.

If you miss \tableofcontents above ... it is just a question of how the 
environment ExecutiveSummary is actually defined.

[snip-snap]

> \section{A section name}
> \label{sec:Asectionname}
> 
>   section names have labels beginning with sec: so the \ref tag
>   shows what it refers to. thus 
>       \ref{sec:Asectionname}
>   can be seen to refer to a section name

I like the "sec:" part, but it should be clear that each section should 
have a unique label (over ALL Axiom files). Or we agree that a file can 
never reference outside its own file scope. (I don't like the latter idea.)

> \subsection{defun foo}
> \label{sec:defunfoo}
> A discussion of the function foo.
> \index{foo defun!defn}
> <<defun foo>>
> (defun foo () "whatever")
> @

That is to LISP specific for me.

> <<runtests>>=
>   test the foo function
> @

For Aldor we have AldorUnit as a test environment, and it is not always 
clear whether the code that tests something is tightly connected to the 
domain(s) that is/are tested.

> \subsection{defmacro bar}
> \label{sec:defmacrofoo}
> A discussion of the macro bar.
> \index{bar defmacro!defn}
> \index{foo defun!use}
> <<defun bar>>
> (defun bar () (foo))
> @
> <<runtests>>=
>   test the bar macro
> @
> 
>   defvars, defuns, defmacros, defstructs, etc all are at the subsection
>   level so they show up in the table of contents. they also have the
>   name of the function (first), that it is a function, and that this
>   is the definition 
>           \index{foo defun!defn}
> 
>   so they show up in the index looking like:
> 
>      foo defun
>         defn   234
>         use    442
> 
>      bar defmacro
>         defn   442

Maybe you don't like it, but I use a slightly different approach in 
ALLPROSE. What comes out as defn and use in your case comes out in red 
and blue color in the index in ALLPROSE. And you would simply say:
\defineterm{foo} and \useterm{foo}. Read the description of 
rhxterm.sty.nw on http://www.hemmecke.de/aldor. It even hyperlinks the 
foo in \useterm to the foo in \defineterm, not just putting something 
into the index.

> \section{Code}
> \label{sec:Code}
> A discussion of the code block.
> <<lisp>>=
> <<defmacro bar>>
> <<defun foo>>
> 
> <<runtests>>
> 
> @
> 
>   The Code section gathers all of the chunks together so they can be
>   output into a file (see the makefile below)
> 
> 
>   Test cases usually are in one chunk called <<runtests>> which get
>   gathered together and added to the end of the <<lisp>> chunk. This
>   allows me to automate the testing.

If you like your LISP files that way, fine for me. I will not change the 
building and testing process.

> =======================================================================
> and now the standard "tail":
> =======================================================================
> \section{Makefile}
> <<*>>=
> PROJECT=tpd
> TANGLE=/usr/local/bin/NOTANGLE
> WEAVE=/usr/local/bin/NOWEAVE
> LATEX=/usr/bin/latex
> LISP=/sei/lisp
> MAKEINDEX=/usr/bin/makeindex
> 
> all: ${PROJECT}.lisp ${PROJECT}.dvi test
> 
> ${PROJECT}.lisp: ${PROJECT}.pamphlet
> 	${TANGLE} -Rlisp ${PROJECT}.pamphlet >${PROJECT}.lisp
> 
> ${PROJECT}.dvi:
> 	${TANGLE} -Rdummyindex ${PROJECT}.pamphlet >${PROJECT}.ind
> 	${WEAVE} -t8 -delay ${PROJECT}.pamphlet >${PROJECT}.tex
> 	${LATEX} ${PROJECT}.tex 
> 	@{MAKEINDEX} ${PROJECT}.idx
> 	${LATEX} ${PROJECT}.tex 
> 
> test:
> 	cat ${PROJECT}.lisp | ${LISP}
> 
> remake:
> 	${TANGLE} -t8 ${PROJECT}.pamphlet >Makefile.${PROJECT}
> 
> @

No, I cannot follow. You mean the Makefile is part of the file that 
contains the LISP code?

I don't say it is generally a bad idea, but I cannot say that I like it. 
In particular, I don't see, why the variables TANGLE, WEAVE, etc. should 
be repeated in every file.

For the .dvi generation I rather like to write a script so that the 
inverse search becomes available.

By the way, you need "dummyindex" because you have 
\input{${PROJECT}.ind} below. \printindex is enough.

> \eject
> \begin{thebibliography}{99}
> \bibitem{1} nothing
> \end{thebibliography}
> <<dummyindex>>=
> \begin{theindex}
>  \item none
> \end{theindex}
> \printindex
> \input{${PROJECT}.ind}
> \end{document}

The thebibliography environment is superfluous if we agree on ONE big 
.bib file and UNIQUE BibKeys. It is even more flexible.

> =======================================================================
> 
> and now the way I work with these:
> 
> =======================================================================
> 
> 
>  notangle -t8 foo.pamphlet >Makefile.foo
> 
>     this extracts the default chunk <<*>>= which is a makefile and
>     names it Makefile.foo.
> 
>  make -f Makefile.foo
> 
>     this completely rebuilds all of the foo project.

Aha, that means you have one "project" per file. May I ask what a 
"project" is in your case, in particular, how big it is?

>  emacs -nw foo.pamphlet
>    (C-x 2     splits the emacs into 2 buffers, both visiting foo.pamphlet)
>    (M-x shell starts a shell in one of the emacs buffers)
> 
>  in the shell I type:
> 
>    xdvi foo.dvi &
> 
>  which starts xdvi in a separate process. Every time I rebuild the .dvi file
>  and give the focus to xdvi it rereads the .dvi file. So this allows me to
>  keep the fully formatted file always available and up to date on the screen.
> 
>    (C-x o     switches between buffers)
>    
>  now I can edit the foo.pamphlet buffer and make changes. When I want to
>  rebuild the file I do:
> 
>    (C-x o     switches between buffers (over to the *shell* buffer))
>    make -f Makefile.foo
>    (C-x o     switches between buffers (back to foo.pamphlet))
> 
>  and then slide the mouse over to the xdvi window and *poof* ... all
>  of my file is newly formatted and the foo program is loaded and the
>  tests are run.
> 
>  It's all very efficient. Of course, your mileage may vary.

My workflow for ALLPROSE is:

Type in a shell:

   notangle -t8 Makefile.nw > Makefile
   make dvi
   xdvi myalps.dvi&
   xemacs

Go in the dvi file to an interesting place.
Ctrl-MouseLeft
xemacs opens the corresponding .nw file exactly at the place 
corresponding to the dvi file.

-- .emacsrc
   (global-set-key [f9] 'recompile)
   (global-set-key [(control f9)] 'compile)
-- end .emacsrc

I edit something and type C-F9, enter "make; make dvi"
Next time just pressing F9 is enough.

If the Aldor compiler were a little better, I would even get the 
following in case my Aldor file contains an error.

-- .emacsrc
   (global-set-key [f12] 'next-error)
   (global-set-key [(shift f12)] 'previous-error)
   (global-set-key [(control f12)] 'shell)
-- end .emacsrc

Press F12. Emacs opens the .nw file corresponding to the error message 
and jumps to the place where the error occured.

\start
Date: Tue, 29 Nov 2005 10:26:15 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Fancy LaTeX preamble

Hi Clifford,

> Here is the preamble I am currently using - for any more elaborate
> posting I'll have to wait until I'm back home.  I brought this one with
> me but didn't have time to sort everything out.
> 
> \documentclass{article}
> \usepackage{axiom}
> \usepackage{ifthen}
> \usepackage{fontenc}

The ifthen package is not so bad, ALLPROSE uses it implicitly and it is 
a standard package that comes with any reasonable LaTeX distribution.

I am not sure about fontenc. Why would you need it?

> % Here we will define some control logic for printing, in order 
> % to allow quick switching between using 1 inch margines and 
> % smaller margines, while also permitting the user to shrink 
> % specified equations in the different cases.  By default we 
> % will use the standard pamphlet formatting.
> 
> \newboolean{usefullpage}
> \setboolean{usefullpage}{false}
> % Uncomment this line to use 1 inch page margins:
> %\setboolean{usefullpage}{true}

Look at ALLPROSE under the target "laptop". I have added some way to 
load a file local.sty into the preample in order to redefine things that 
you would like to see differently. (Section "Local Modifications" in the 
file allprose.sty)

You would then say

make fullpage dvi

where in the Makefile you'd have a rule:

fullpage:
	@echo '\usepackage{geometry}' >> local.sty
	@echo '\geometry{verbose,letterpaper,tmargin=1in,' >> local.sty
	@echo 'bmargin=1in,lmargin=1in,rmargin=1in}' >> local.sty
	@echo '\renewcommand\resizeequation[1]{#1}' >> local.sty

The non-fullpage stuff goes as the default into the .sty file.
The idea is that "fullpage" is your personal preference not something of 
general interest.

> % Here we define control logic for producing a pdf version of 
> % the document.  TeTeX 3.0 and up seem to be semi-automatic, so
> % using the old 2.x trick in the Maximabook didn't seem to work.
> 
> \newboolean{makepdf}
> \setboolean{makepdf}{false}
> 
> % Uncomment this line to produce a properly formatted pdf 
> % document (the main difference is how hyperref is used).
> %\setboolean{makepdf}{true}
> 
> % The actual ifthen control logic
> \ifthenelse{\boolean{usefullpage}}{
>    \usepackage{geometry}
>    % For different paper sizes or margins adjust the 
>    % settings here
>    \geometry{verbose,letterpaper,tmargin=1in,bmargin=1in,
>              lmargin=1in,rmargin=1in}
>    % If we are using the full page, we want to have all  
>    % equations full size
>    \newcommand\resizeequation[1]{#1}
> }{
>    % If we are using the normal Axiom mode, we want some 
>    % equations to use smaller fonts
>    \newcommand\resizeequation[1]{{\tiny #1}}
> } 



> % These options will change options used for hyperref when 
> % pdflatex/pdftex is the generator
> \ifthenelse{\boolean{makepdf}}{
>   \usepackage[pdftex=true, plainpages=false, colorlinks=true, 
>               linkcolor=blue, breaklinks=true, pdfpagelabels, 
>               pdftitle={Units and Dimensions in Axiom}, 
>               pdfauthor={Clifford Yapp}, pdfsubject={Axiom Units 
>               and Dimensions}, pdfkeywords={Axiom, CAS, Computer
>               Algebra, Units, Dimensions, Dimensional, Analysis}, 
>               bookmarksopen=false, pdfnewwindow=true,
>               pdfstartview=FitH, 
>               pdfpagemode=UseOutlines]{hyperref}
> }{ 
> % hyperref calls for dvi file production
>   \usepackage[backref=false, colorlinks=false, 
>               breaklinks=true]{hyperref}

Hmm, that is a bit harder. But I have found this

	%%% check whether we are running pdflatex
	
	\newif\ifpdf
	\ifx\pdfoutput\undefined
	\pdffalse % we are not running pdflatex
	\else
	\pdfoutput=1 % we are running pdflatex
	\pdfcompresslevel=9     % compression level for text and image;
	\pdftrue
	\fi

on http://www.db.informatik.uni-bremen.de/~mr/pdflatex.html.
So, it's not a big problem. At least you don't need to modify the .tex 
source if you switch from dvi to pdf output.

\start
Date: Tue, 29 Nov 2005 10:51:19 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: article "standard" header/footer

Dear Tim,

> well, i'm WAS planning to do a document-and-cleanup cycle on
> axiom.sty so that (a) only the things that are used survive (there is
> cruft from history in there (b) it formats nicely so i can append it
> to stand-alone documents and (c) the macros are documented like
> everything else. i haven't done that yet due to time. i did merge a
> couple macros from other packages so that we could write axiom
> documents that only depend on 1 package and we could include that
> package as part of the .pamphlet file.

This sounds like hardcoding style files into axiom.sty. Who is going to
maintain them??? Even if axiom.sty is a literate program, it should not
be our task to maintain LaTeX stuff. A few commands is OK, but please
not all of those fancy style packages.

> i hate getting documents i can't format because the author hasn't
> included ALL of the tree of .sty files.

That is not a problem. Just put all necessary .sty files in a .zip 
archive and distribute them with Axiom. Whenever there is a new version 
of a package or just a new version of a whole LaTeX distribution, we 
might have to update. But to maintain the packages ourselves is just a 
waste of time. There are other people who can do it better. Our focus is 
on mathematics, right?

> plus noweb (WAS) planned to go away in favor of an axiom 
> implementation that had different features (like support for .booklet
>  files which use an optional URL syntax in chunk names). that may
> still happen but it is open for discussion.

I've once read something in the noweb documentation why Norman Ramsey 
has not introduced an "include" feature. One can put the files on the 
command line anyway and weave and tangle them together. Can I read 
somewhere about your reasons to introduce such extensions to noweb?
I also don't understand exactly what "booklet" should serve.

> sigh. old technology again. ok. propose something different for the 
> bibliography. i started on the bibtex thing (there is a
> bibtex.pamphlet the src/doc directory which would collect annotated
> bibtex references so we could keep them in one place and have a fully
> documented bibliography. if you suggest what you'd like to see we can
> figure out how to connect it to the bibtex.pamphlet and then spread
> the new machinery all over axiom.

I imagine the following here. We have one big bibtex database. If 
someone adds a contribution, he/she should use bibkeys from that 
database. Only if there is no bibentry there, new entries could be 
provided in an accompanying bibtex file to the persons project (which 
would eventually incorporated into the ONE.

So the wrapper script would write

\bibliographystyle{alpha}
\bibliography{axiom} % the ONE bibliography file
\IfFileExists{\projectname.bib}{\bibliography{\projectname}}{}

at the end of the document (followed by \end{document}).

In the above code piece \projectname expands to the name of the person's 
project.

There is still something to do in a Makefile to generate the .bib file 
from its .pamphlet and run bibtex on the whole stuff. But that is simple.

> -> )credits
> 
> you'll see a list i maintain of all of the people who seem to have 
> contributed. having just done that now i see your name is not on that
>  list (i'll correct that in the next release). when time permits i
> run back over my email and add new people.

I don't remember that I've yet really contributed to Axiom. I haven't 
modified code at all. It's just taking part in the discussion.

\start
Date: Tue, 29 Nov 2005 06:40:01 -0800 (PST)
From: Cliff Yapp
To: list
Subject: PDFs and dvis loaded into Portal, but need some kind of review?

I uploaded a variety of pdf and dvi files into my account on
portal.axiom-developer.org, but apparently they need to be "published"
to be visible to the world.  I "submitted" them but I have no idea who
is supposed to be on the other end to complete the process.

Also, seeing as these are public drafts and technology tests rather
than final copies, I'm a little worried by the "publish" terminology -
it sounds rather final.  I'm assuming (hoping) this step is simply to
keep people from uploading copyrighted work and other things that are
inappropriate?

Anyway, I'll post again with links if and when the process is complete.

\start
Date: Tue, 29 Nov 2005 13:13:38 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Units and Dimensions - example pdf and dvi files

Well, still not approved for public visibility but it looks like a
direct link to each file will allow folks to view them.  This is a
collection of a variety of formatting options that can be achieved with
the options included in the preamble.  For those who want the fanciest
result, I recommend the XYpic diagram version in pdf format:
http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramtest.pdf/download

For those who want to check out dvi vs. pdf, and/or various options,
here are the others:

http://portal.axiom-developer.org/Members/starseeker/axiomunit_standard.dvi/download
http://portal.axiom-developer.org/Members/starseeker/axiomunit_standard.pdf/download
http://portal.axiom-developer.org/Members/starseeker/axiomunit_standardsize_withhyperref.dvi/download
http://portal.axiom-developer.org/Members/starseeker/axiomunit_standardsize_withhyperref.pdf/download
http://portal.axiom-developer.org/Members/starseeker/axiomunit_1inmargins_withhyperref.dvi/download
http://portal.axiom-developer.org/Members/starseeker/axiomunit_1inmargins_withhyperref.pdf/download
http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramtest.dvi/download
http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramtest.pdf/download

\start
Date: Tue, 29 Nov 2005 17:22:34 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: PDFs and dvis loaded into Portal, but need some kind of review?

On Tuesday, November 29, 2005 9:40 AM C Y wrote:
>
> I uploaded a variety of pdf and dvi files into my account on
> portal.axiom-developer.org, but apparently they need to be
> "published" to be visible to the world.  I "submitted" them
> but I have no idea who is supposed to be on the other end to
> complete the process.

That would be me. It could also be any other registered user of
the Axiom Portal who elected to be a "Reviewer". If anyone else
wants this job, I would be glad to add that capability to your
Axiom Portal user id.

What this means is that if someone submits a document for
publication on the Axiom Portal, those users who are designated
as "reviewers" will receive a notice when then log in to the
portal that some document is ready for their review. If the
reviewer decides that it is ok, she can approve it and then it
will appear as a *public* document. Or they can reject it, it
which case it goes back to the submitter with a reason for the
rejection and the cycle can start again.

>
> Also, seeing as these are public drafts and technology tests
> rather than final copies, I'm a little worried by the "publish"
> terminology - it sounds rather final.  I'm assuming (hoping)
> this step is simply to keep people from uploading copyrighted
> work and other things that are inappropriate?

Yes, that is basically correct. Documents on the Axiom portal
can have the following states:

                      new
                       |
                       |
                      \|/    (submit)           (accept)
     private <----> visible <-------->submitted --------> published
                             (reject)
                                                (retract)
                            <----------------------------

By default all new documents are "visible" which means that
if you are logged in to the Axiom Portal with a valid user
id, then you will be allowed to view the document. Only the
"owner" of the document will be allowed to change it.

The owner of the document can "submit" it for publication.
When a "reviewer" decides to "accept" the document then it
will become "published". "Published" documents are accessible
to everyone who accesses the site whether they are logged in
or not.

The owner of a document can also decide to make a document
"private" in which case only they can view it.

>
> Anyway, I'll post again with links if and when the process
> is complete.
>

If you really intended to make this draft publicly accessible
to everyone even if they are not registered users of the Axiom
Portal, then I will approve it. Please let me know. And of
course let me know if you would like me to explain this
process again if anything is unclear.

Thanks for trying this!

\start
Date: 29 Nov 2005 17:46:46 -0500
From: Camm Maguire
To: Sandip Ray
Subject: Re: ACL2 compiling problems
Cc: Matt Kaufmann

Greetings!

Well, less than a stunning progress report thus far.  The saved image
bombs on attempting to grant execution privileges to its heap
(i.e. its data segment, mprotect(address,range,7)).  In other words,
we are failing in a low level system call due to some system
permissions issue. The odd thing is that the raw image does not seem
to suffer from this, only the image produced by unexec when saving the
system.  I have access to another FC4 machine and cannot reproduce
this there.  Here are the unames:

Linux xxxxxxxx 2.6.14-1.1637_FC4smp #1 SMP Wed Nov 9 18:34:11
EST 2005 i686 athlon i386 GNU/Linux

Linux yyyyyyyy 2.6.11-1.1369_FC4 #1 Thu Jun 2
22:55:56 EDT 2005 i686 i686 i386 GNU/Linux

I'm relatively certain this is due to some system security setting
which is forbidding this access to memory.  The sad thing is that it
appears to be a new "feature" as yet not worked around.  What a cat
and mouse game. 

Ring any bells, Tim?

Take care,

Sandip Ray writes:

> PS: The gcl is in /u/installation/gcl. You should have write permissions 
> to the sources in that directory.
> 
> Thanks a lot for your help,
> 
> --- Sandip. 
> 
> On Tue, 29 Nov 2005, Camm Maguire wrote:
> 
> \\Greetings!  What type of machine is this?  Can you arrange remote ssh
> \\access for me to investigate?
> \\
> \\Take care,
> \\
> \\Sandip Ray writes:
> \\
> \\> Hi Camm,
> \\> 
> \\> I got the version 2.6.8pre, and it seems not to have the sbrk problem, but 
> \\> I seem to be getting error in the compilation process, somewhere in 
> \\> unixport directory. I dont quite know what it is. 
> \\> 
> \\> I have the full transcript below. Thanks for your help. 
> \\> 
> \\> --- Sandip.
> \\> 
> \\> [root@horatio-228 gcl-2.6.8pre]# ./configure
> \\> creating cache ./config.cache
> \\> checking host system type... i686-pc-linux-gnu
> \\> host=i686-pc-linux-gnu
> \\> enable_machine=
> \\> use=386-linux
> \\> checking for gcc... gcc
> \\> checking whether the C compiler (gcc    ) works... yes
> \\> checking whether the C compiler (gcc    ) is a cross-compiler... no
> \\> checking whether we are using GNU C... yes
> \\> checking whether gcc accepts -g... yes
> \\> checking how to run the C preprocessor... gcc -E
> \\> checking for gawk... gawk
> \\> checking system version (for dynamic loading)... checking for makeinfo... 
> \\> makeinfo
> \\> Linux-2.6.11-1.1369_FC4
> \\> checking for unistd.h... yes
> \\> checking for sysconf in -lc... yes
> \\> checking for _SC_CLK_TCK... 100
> \\> checking for gmp.h... yes
> \\> checking for __gmpz_init in -lgmp... yes
> \\> checking for external gmp version... checking for leading underscore in 
> \\> object symbols... no
> \\> checking for GNU ld option -Map... yes
> \\> checking for size of gmp limbs... 4
> \\> checking _SHORT_LIMB... no
> \\> checking _LONG_LONG_LIMB... no
> \\> checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
> \\> checking for dnet_ntoa in -ldnet... no
> \\> checking for dnet_ntoa in -ldnet_stub... no
> \\> checking for gethostbyname... yes
> \\> checking for connect... yes
> \\> checking for remove... yes
> \\> checking for shmat... yes
> \\> checking for IceConnectionNumber in -lICE... yes
> \\> -I/usr/X11R6/include
> \\> -L/usr/X11R6/lib
> \\> 
> \\> -lSM -lICE
> \\> checking for main in -lXmu... yes
> \\> checking for main in -lXt... yes
> \\> checking for main in -lXext... yes
> \\> checking for main in -lXaw... yes
> \\> checking for main in -lX11... yes
> \\> checking for bfd.h... yes
> \\> checking for bfd_init in -lbfd... yes
> \\> checking if need to define CONST for bfd... no
> \\> checking for useable bfd_boolean... yes
> \\> checking size of long... 4
> \\> checking sizeof struct contblock... 8
> \\> checking for endian.h... yes
> \\> checking endianness... little
> \\> checking for sbrk... yes
> \\> checking for randomized sbrk... yes
> \\> checking for ADDR_NO_RANOMIZE constant... 0x40000
> \\> checking for sys/personality.h... yes
> \\> checking for randomized brk remedy... yes
> \\> checking finding DBEGIN... got 0
> \\> checking finding CSTACK_ADDRESS... got -1081115328
> \\> checking sizeof long long int... yes
> \\> checking for pagewidth... 12
> \\> checking for getcwd... yes
> \\> checking for getwd... yes
> \\> checking for uname... yes
> \\> checking for gettimeofday... yes
> \\> checking for sys/ioctl.h... yes
> \\> checking for elf.h... yes
> \\> checking for elf_abi.h... no
> \\> checking for BSDgettimeofday... no
> \\> checking for gettimeofday... (cached) yes
> \\> checking for gettimeofday declaration... present
> \\> checking for sin in -lm... yes
> \\> checking for main in -lmingwex... no
> \\> checking for math.h... yes
> \\> checking for values.h... yes
> \\> checking for float.h... yes
> \\> checking for isnormal... yes
> \\> checking for isfinite... yes
> \\> checking for sockets... checking for connect... (cached) yes
> \\> checking for gethostbyname... (cached) yes
> \\> checking for readline/readline.h... yes
> \\> checking for main in -lreadline... yes
> \\> checking for rl_completion_matches in -lreadline... no
> \\> checking For network code for nsocket.c... yes
> \\> checking check for listen using fcntl... yes
> \\> checking for profil... yes
> \\> checking for setenv... yes
> \\> checking for _cleanup... no
> \\> checking FIONBIO vs. O_NONBLOCK for nonblocking I/O... O_NONBLOCK
> \\> checking check for SV_ONSTACK... yes
> \\> checking check for SIGSYS... yes
> \\> checking check for SIGEMT... no
> \\> checking for asm/sigcontext.h... yes
> \\> checking for asm/signal.h... yes
> \\> checking for sigcontext...... sigcontext in signal.h
> \\> checking for emacs... /usr/bin/emacs
> \\> checking emacs site lisp directory... /usr/share/emacs/21.4/site-lisp
> \\> checking emacs default.el... /usr/share/emacs/21.4/site-lisp/default.el
> \\> checking emacs info/dir... /usr/share/info/
> \\> checking for tcl/tk... checking for tclsh... tclsh
> \\> checking for main in -llieee... no
> \\> not found
> \\> checking alloca... yes
> \\> checking Checking for buggy gcc version from redhat... no
> \\> updating cache ./config.cache
> \\> creating ./config.status
> \\> creating makedefc
> \\> creating windows/gcl.iss
> \\> creating windows/sysdir.bat
> \\> creating windows/install.lsp
> \\> creating h/gclincl.h
> \\> makedefc
> \\> 
> \\> # begin makedefs
> \\> 
> \\> # use=386-linux
> \\> 
> \\> # for main link of raw_gcl
> \\> LIBS=    -lm  -lgmp /usr/lib/libbfd.a /usr/lib/libiberty.a -lreadline 
> \\> -lncurses
> \\> 
> \\> #The multi precision library stuff
> \\> MPFILES=$(MPDIR)/@MPI_FILE@ $(MPDIR)/libmport.a
> \\> 
> \\> 
> \\> # root for the installation, eg /usr/local
> \\> # This would cause make install to create /usr/local/bin/gcl and
> \\> # /usr/local/lib/gcl-2-??/* with some basic files.
> \\> prefix=/usr/local
> \\> 
> \\> # where to place the info files
> \\> INFO_DIR=/usr/share/info/
> \\> 
> \\> # where to put emacs lisp files.
> \\> EMACS_SITE_LISP=/usr/share/emacs/21.4/site-lisp
> \\> 
> \\> # the default.el file
> \\> EMACS_DEFAULT_EL=/usr/share/emacs/21.4/site-lisp/default.el
> \\> 
> \\> # numerous TCL/TK variables culled from the tkConfig.sh and tclConfig.sh
> \\> # if these are found.
> \\> TK_CONFIG_PREFIX=
> \\> TK_LIBRARY=
> \\> TCL_LIBRARY=
> \\> TK_XINCLUDES=
> \\> TK_INCLUDE=
> \\> TCL_INCLUDE=
> \\> TK_LIB_SPEC=
> \\> TK_BUILD_LIB_SPEC=
> \\> TK_XLIBSW=
> \\> TK_XINCLUDES=
> \\> TCL_LIB_SPEC=
> \\> TCL_DL_LIBS=
> \\> TCL_LIBS=
> \\> 
> \\> NOTIFY=yes
> \\> CC=gcc
> \\> CFLAGS=  -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I$(GCLDIR)/o
> \\> FINAL_CFLAGS=  -Wall -DVOL=volatile -fsigned-char -pipe 
> \\> NIFLAGS=  -Wall -DVOL=volatile -fsigned-char -pipe   -I$(GCLDIR)/o
> \\> O3FLAGS=-O3 -fomit-frame-pointer
> \\> O2FLAGS=-O
> \\> 
> \\> RL_OBJS=gcl_readline.o
> \\> 
> \\> RL_LIB=
> \\> 
> \\> MAKEINFO=makeinfo
> \\> 
> \\> FLISP=saved_gcl
> \\> SYSTEM=gcl
> \\> BUILD_BFD=
> \\> GMPDIR=gmp3
> \\> X_LIBS= -L/usr/X11R6/lib -lXmu -lXt -lXext -lXaw -lX11
> \\> X_CFLAGS= -I/usr/X11R6/include
> \\> 
> \\> PROCESSOR_FLAGS=
> \\> 
> \\> EXTRA_LOBJS=
> \\> LEADING_UNDERSCORE=
> \\> GNU_LD=1
> \\> add-defs1 386-linux
> \\> using 386-linux.defs
> \\> [root@horatio-228 gcl-2.6.8pre]# make
> \\> (cd o && make ../h/new_decl.h)
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre/o'
> \\> gcc  -o grab_defs  grab_defs.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk plttest.c  
> \\> nm plttest.o | awk '/ U / {a=$2;if (k) sub("^_","",a);\
> \\>                             b=a;gsub("_","",b);\
> \\>                             if (match(j,b)) printf("MY_PLT(%s)\n",a)}' \
> \\> 		j="$(awk '/main/ {i=1;next} {if (!i) next} /^ 
> \\> *[a-zA-Z_]*\(/ {sub("\\(.*$","",$1);print $1}' plttest.c)" k= | sort | awk 
> \\> '{A[++k]=$0} END {for (i=1;i<=k;i++) printf("%s%s\n",A[i],i==k ? "" : 
> \\> ",");}' >plt.h
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E main.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > main.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E alloc.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> alloc.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E gbc.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > gbc.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E bitop.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> bitop.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E typespec.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> typespec.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E eval.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > eval.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E macros.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> macros.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E lex.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > lex.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E bds.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > bds.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E frame.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> frame.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E predicate.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> predicate.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E reference.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> reference.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E assignment.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> assignment.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E bind.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > bind.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E let.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > let.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E conditional.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> conditional.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E block.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> block.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E iteration.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> iteration.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E mapfun.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> mapfun.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E prog.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > prog.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E multival.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> multival.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E catch.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> catch.ini
> \\> gcc -I../h -I../gcl-tk -o ../bin/dpp ../bin/dpp.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp symbol
> \\> dpp: symbol.d -> symbol.c
> \\> ./grab_defs < symbol.c > symbol.ini
> \\> rm symbol.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E cfun.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > cfun.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E cmpaux.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> cmpaux.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp package
> \\> dpp: package.d -> package.c
> \\> ./grab_defs < package.c > package.ini
> \\> rm package.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E big.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > big.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E number.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> number.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E num_pred.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> num_pred.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E num_comp.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> num_comp.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E num_arith.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> num_arith.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E num_sfun.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> num_sfun.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E num_co.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> num_co.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E num_log.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> num_log.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E num_rand.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> num_rand.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E earith.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> earith.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp character
> \\> dpp: character.d -> character.c
> \\> ./grab_defs < character.c > character.ini
> \\> rm character.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp sequence
> \\> dpp: sequence.d -> sequence.c
> \\> ./grab_defs < sequence.c > sequence.ini
> \\> rm sequence.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp list
> \\> dpp: list.d -> list.c
> \\> ./grab_defs < list.c > list.ini
> \\> rm list.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp hash
> \\> dpp: hash.d -> hash.c
> \\> ./grab_defs < hash.c > hash.ini
> \\> rm hash.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E array.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> array.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp string
> \\> dpp: string.d -> string.c
> \\> ./grab_defs < string.c > string.ini
> \\> rm string.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E regexpr.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> regexpr.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E structure.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> structure.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E toplevel.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> toplevel.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp file
> \\> dpp: file.d -> file.c
> \\> ./grab_defs < file.c > file.ini
> \\> rm file.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp read
> \\> dpp: read.d -> read.c
> \\> ./grab_defs < read.c > read.ini
> \\> rm read.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E backq.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> backq.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp print
> \\> dpp: print.d -> print.c
> \\> ./grab_defs < print.c > print.ini
> \\> rm print.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E format.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> format.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp pathname
> \\> dpp: pathname.d -> pathname.c
> \\> ./grab_defs < pathname.c > pathname.ini
> \\> rm pathname.c
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E unixfsys.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> unixfsys.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E unixfasl.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> unixfasl.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E error.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> error.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E unixtime.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> unixtime.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E unixsys.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> unixsys.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E unixsave.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> unixsave.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E funlink.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> funlink.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E plt.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > plt.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E fat_string.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> fat_string.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E run_process.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> run_process.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E nfunlink.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> nfunlink.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E usig.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > usig.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E usig2.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> usig2.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E utils.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> utils.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E makefun.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> makefun.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E sockets.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> sockets.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E gmp_wrappers.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> gmp_wrappers.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E clxsocket.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> clxsocket.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E init_pari.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> init_pari.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E nsocket.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> nsocket.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> gcc -DNO_DEFUN -Wall -DVOL=volatile -fsigned-char -pipe -O3 
> \\> -fomit-frame-pointer  -I/u/installation/gcl/gcl-2.6.8pre/o -I../h 
> \\> -I../gcl-tk -E sfasl.c | sed -e 's:\"[ ]*):\"):g' | ./grab_defs > 
> \\> sfasl.ini
> \\> [ -e ../h/new_decl.h ] || touch ../h/new_decl.h
> \\> ../bin/dpp gcl_readline
> \\> dpp: gcl_readline.d -> gcl_readline.c
> \\> ./grab_defs < gcl_readline.c > gcl_readline.ini
> \\> rm gcl_readline.c
> \\> echo '#include "make-decl.h"' > foo.c
> \\> cat main.ini alloc.ini gbc.ini bitop.ini typespec.ini eval.ini macros.ini 
> \\> lex.ini bds.ini frame.ini predicate.ini reference.ini assignment.ini 
> \\> bind.ini let.ini conditional.ini block.ini iteration.ini mapfun.ini 
> \\> prog.ini multival.ini catch.ini symbol.ini cfun.ini cmpaux.ini package.ini 
> \\> big.ini number.ini num_pred.ini num_comp.ini num_arith.ini num_sfun.ini 
> \\> num_co.ini num_log.ini num_rand.ini earith.ini character.ini sequence.ini 
> \\> list.ini hash.ini array.ini string.ini regexpr.ini structure.ini 
> \\> toplevel.ini file.ini read.ini backq.ini print.ini format.ini pathname.ini 
> \\> unixfsys.ini unixfasl.ini error.ini unixtime.ini unixsys.ini unixsave.ini 
> \\> funlink.ini plt.ini fat_string.ini ./run_process.ini nfunlink.ini usig.ini 
> \\> usig2.ini utils.ini makefun.ini sockets.ini gmp_wrappers.ini clxsocket.ini 
> \\> init_pari.ini nsocket.ini ./sfasl.ini gcl_readline.ini >> foo.c
> \\> gcc -E -I../h foo.c | sed -n -e '/#/d' -e '/DO_/d' -e '/[a-zA-Z;]/p' > 
> \\> ../h/new_decl.h
> \\> rm foo.c
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre/o'
> \\> cat h/config.h | sed -e "1,/Begin for cmpincl/d" \
> \\> 	-e "/End for cmpinclude/,50000d" > tmpx
> \\> echo -e '#include "h/config.h"\n#ifdef SGC\n"#define SGC"\n#else\n"#undef 
> \\> SGC"\n#endif' | cpp 2>/dev/null| grep -v '^ *$' | tail -1l | tr -d '"' 
> \\> >>tmpx
> \\> cat h/cmpincl1.h h/gclincl.h h/compbas.h h/enum.h h/mgmp.h h/object.h 
> \\> h/vs.h h/bds.h h/frame.h h/lex.h h/eval.h    h/funlink.h h/att_ext.h 
> \\> h/new_decl.h h/compbas2.h h/compat.h h/cmponly.h o/regexp.h h//protoize.h 
> \\> >> tmpx
> \\> ./xbin/move-if-changed mv tmpx h/cmpinclude.h
> \\> tmpx and h/cmpinclude.h were not the same.
> \\> ln tmpx h/cmpinclude.h
> \\> ./xbin/move-if-changed cp h/cmpinclude.h o/cmpinclude.h
> \\> h/cmpinclude.h and o/cmpinclude.h were not the same.
> \\> ln h/cmpinclude.h o/cmpinclude.h
> \\> (cd bin; make all)
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre/bin'
> \\> gcc  -I../h  -o append  append.c
> \\> gcc -I../h  -o file-sub file-sub.c
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre/bin'
> \\> make mpfiles
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre'
> \\> make[1]: Nothing to be done for `mpfiles'.
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre'
> \\> rm -f o/cmpinclude.h ; cp h/cmpinclude.h o
> \\> (cd o; make all)
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre/o'
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk main.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk alloc.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk gbc.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk bitop.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk typespec.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk eval.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk macros.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk lex.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk bds.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk frame.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk predicate.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk reference.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk assignment.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk bind.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk let.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk conditional.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk block.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk iteration.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk mapfun.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk prog.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk multival.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk catch.c  
> \\> ../bin/dpp symbol
> \\> dpp: symbol.d -> symbol.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk symbol.c 
> \\> rm symbol.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk cfun.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk cmpaux.c  
> \\> ../bin/dpp package
> \\> dpp: package.d -> package.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk package.c 
> \\> rm package.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk big.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk number.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk num_pred.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk num_comp.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk num_arith.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk num_sfun.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk num_co.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk num_log.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk num_rand.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk earith.c  
> \\> ../bin/dpp character
> \\> dpp: character.d -> character.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk character.c 
> \\> rm character.c
> \\> ../bin/dpp sequence
> \\> dpp: sequence.d -> sequence.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk sequence.c 
> \\> rm sequence.c
> \\> ../bin/dpp list
> \\> dpp: list.d -> list.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk list.c 
> \\> rm list.c
> \\> ../bin/dpp hash
> \\> dpp: hash.d -> hash.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk hash.c 
> \\> rm hash.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk array.c  
> \\> ../bin/dpp string
> \\> dpp: string.d -> string.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk string.c 
> \\> rm string.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk regexpr.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk structure.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk toplevel.c  
> \\> ../bin/dpp file
> \\> dpp: file.d -> file.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk file.c 
> \\> rm file.c
> \\> ../bin/dpp read
> \\> dpp: read.d -> read.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk read.c 
> \\> rm read.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk backq.c  
> \\> ../bin/dpp print
> \\> dpp: print.d -> print.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk print.c 
> \\> rm print.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk format.c  
> \\> ../bin/dpp pathname
> \\> dpp: pathname.d -> pathname.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk pathname.c 
> \\> rm pathname.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk unixfsys.c  
> \\> unixfsys.c: In function -1truename:
> \\> unixfsys.c:277: warning: -1getwd is deprecated (declared at 
> \\> unixfsys.c:151)
> \\> unixfsys.c:360: warning: -1getwd is deprecated (declared at 
> \\> unixfsys.c:151)
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk unixfasl.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk error.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk unixtime.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk unixsys.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk unixsave.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk funlink.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk plt.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk fat_string.c  
> \\> fat_string.c: In function -1fSprofile:
> \\> fat_string.c:53: warning: null argument where non-null required (argument 
> \\> 1)
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk run_process.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk nfunlink.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk usig.c  
> \\> usig.c: In function -1unblock_signals:
> \\> usig.c:93: warning: -1sigblock is deprecated (declared at 
> \\> /usr/include/signal.h:181)
> \\> usig.c:93: warning: -1sigsetmask is deprecated (declared at 
> \\> /usr/include/signal.h:184)
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk usig2.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk utils.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk makefun.c  
> \\> gcc -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk   -c  sockets.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk gmp_wrappers.c  
> \\> gcc -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk   -c  clxsocket.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk init_pari.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk nsocket.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk sfasl.c  
> \\> ../bin/dpp gcl_readline
> \\> dpp: gcl_readline.d -> gcl_readline.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk gcl_readline.c 
> \\> gcl_readline.d: In function -1rl_completion:
> \\> gcl_readline.d:221: warning: implicit declaration of function 
> \\> -1completion_matches
> \\> gcl_readline.d:221: warning: return makes pointer from integer without a 
> \\> cast
> \\> rm gcl_readline.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk bcmp.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk bcopy.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk bzero.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk user_init.c  
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk user_match.c  
> \\> echo '#include "make-init.h"' > new_init.c
> \\> echo 'void NewInit(void){' >> new_init.c
> \\> cat main.ini alloc.ini gbc.ini bitop.ini typespec.ini eval.ini macros.ini 
> \\> lex.ini bds.ini frame.ini predicate.ini reference.ini assignment.ini 
> \\> bind.ini let.ini conditional.ini block.ini iteration.ini mapfun.ini 
> \\> prog.ini multival.ini catch.ini symbol.ini cfun.ini cmpaux.ini package.ini 
> \\> big.ini number.ini num_pred.ini num_comp.ini num_arith.ini num_sfun.ini 
> \\> num_co.ini num_log.ini num_rand.ini earith.ini character.ini sequence.ini 
> \\> list.ini hash.ini array.ini string.ini regexpr.ini structure.ini 
> \\> toplevel.ini file.ini read.ini backq.ini print.ini format.ini pathname.ini 
> \\> unixfsys.ini unixfasl.ini error.ini unixtime.ini unixsys.ini unixsave.ini 
> \\> funlink.ini plt.ini fat_string.ini ./run_process.ini nfunlink.ini usig.ini 
> \\> usig2.ini utils.ini makefun.ini sockets.ini gmp_wrappers.ini clxsocket.ini 
> \\> init_pari.ini nsocket.ini ./sfasl.ini gcl_readline.ini >> new_init.c
> \\> echo '}' >> new_init.c
> \\> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe   
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o -I../h -I../gcl-tk new_init.c -o 
> \\> new_init.o
> \\> rm -f gcllib.a
> \\> ar qc gcllib.a bcmp.o bcopy.o bzero.o user_init.o user_match.o 
> \\> ranlib gcllib.a
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre/o'
> \\> make h/cmpinclude.h
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre'
> \\> make[1]: `h/cmpinclude.h' is up to date.
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre'
> \\> rm -f o/cmpinclude.h ; cp h/cmpinclude.h o
> \\> (cd o; make all)
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre/o'
> \\> make[1]: Nothing to be done for `all'.
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre/o'
> \\> cd unixport && make saved_pre_gcl
> \\> ls: ../lsp/*.o: No such file or directory
> \\> ls: ../cmpnew/*.o: No such file or directory
> \\> ls: ../mod/*.o: No such file or directory
> \\> ls: ../pcl/*.o: No such file or directory
> \\> ls: ../clcs/*.o: No such file or directory
> \\> ls: ../clcs/clcs_*.lisp: No such file or directory
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre/unixport'
> \\> gcc -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o   -c -o sys_pre_gcl.o sys_pre_gcl.c
> \\> rm -rf gmp
> \\> mkdir gmp
> \\> a="" ; \
> \\> for i in $a ; do \
> \\> 	cp $i gmp/$(echo $i | sed -e 's,\.\./,,1' -e 's,/,_,g') ; \
> \\> done
> \\> touch gmpfiles
> \\> rm -rf bfd
> \\> mkdir bfd
> \\> a="" ; \
> \\> for i in $a ; do \
> \\> 	cp $i bfd/$(echo $i | sed -e 's,\.\./,,1' -e 's,/,_,g') ; \
> \\> done 
> \\> touch bfdfiles
> \\> rm -rf libpre_gcl.a
> \\> ar rs libpre_gcl.a ../o/alloc.o ../o/array.o ../o/assignment.o 
> \\> ../o/backq.o ../o/bds.o ../o/big.o ../o/bind.o ../o/bitop.o ../o/block.o 
> \\> ../o/catch.o ../o/cfun.o ../o/character.o ../o/clxsocket.o ../o/cmpaux.o 
> \\> ../o/conditional.o ../o/earith.o ../o/error.o ../o/eval.o 
> \\> ../o/fat_string.o ../o/file.o ../o/format.o ../o/frame.o ../o/funlink.o 
> \\> ../o/gbc.o ../o/gcl_readline.o ../o/gmp_wrappers.o ../o/hash.o 
> \\> ../o/init_pari.o ../o/iteration.o ../o/let.o ../o/lex.o ../o/list.o 
> \\> ../o/macros.o ../o/main.o ../o/makefun.o ../o/mapfun.o ../o/multival.o 
> \\> ../o/new_init.o ../o/nfunlink.o ../o/nsocket.o ../o/num_arith.o 
> \\> ../o/number.o ../o/num_comp.o ../o/num_co.o ../o/num_log.o ../o/num_pred.o 
> \\> ../o/num_rand.o ../o/num_sfun.o ../o/package.o ../o/pathname.o ../o/plt.o 
> \\> ../o/predicate.o ../o/print.o ../o/prog.o ../o/read.o ../o/reference.o 
> \\> ../o/regexpr.o ../o/run_process.o ../o/sequence.o ../o/sfasl.o 
> \\> ../o/sockets.o ../o/string.o ../o/structure.o ../o/symbol.o 
> \\> ../o/toplevel.o ../o/typespec.o ../o/unixfasl.o ../o/unixfsys.o 
> \\> ../o/unixsave.o ../o/unixsys.o ../o/unixtime.o ../o/usig2.o ../o/usig.o 
> \\> ../o/utils.o sys_pre_gcl.o 
> \\> ar: creating libpre_gcl.a
> \\> cp ../o/gcllib.a libgclp.a
> \\> ranlib libgclp.a
> \\> cp init_pre_gcl.lsp.in init_pre_gcl.lsp.tmp
> \\> touch raw_pre_gcl_map
> \\> gcc -o raw_pre_gcl  \
> \\> 	-L.  -Wl,-Map raw_pre_gcl_map   -lpre_gcl -lm  -lgmp 
> \\> /usr/lib/libbfd.a /usr/lib/libiberty.a -lreadline -lncurses -lc -lgclp 
> \\> cat init_pre_gcl.lsp.tmp | sed \
> \\> 	-e "s#@LI-VERS@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \
> \\> 	-e "s#@LI-EXTVERS@#`cat ../minvers | cut -f2 -d.`#1" \
> \\> 	-e "s#@LI-MINVERS@#`cat ../minvers | cut -f1 -d.`#1" \
> \\> 	-e "s#@LI-MAJVERS@#`cat ../majvers`#1" \
> \\> 	-e "s#@LI-CC@#\"gcc -c -Wall -DVOL=volatile -fsigned-char -pipe 
> \\> \"#1" \
> \\> 	-e "s#@LI-LD@#\"gcc -o \"#1" \
> \\> 	-e "s#@LI-LD-LIBS@#\"   -lpre_gcl -lm  -lgmp /usr/lib/libbfd.a 
> \\> /usr/lib/libiberty.a -lreadline -lncurses -lc -lgclp \"#1" \
> \\> 	-e "s#@LI-OPT-THREE@#\"-O3 -fomit-frame-pointer\"#1" \
> \\> 	-e "s#@LI-OPT-TWO@#\"-O\"#1" \
> \\> 	-e "s#@LI-INIT-LSP@#\"init_pre_gcl.lsp\"#1" >init_pre_gcl.lsp
> \\> cp init_pre_gcl.lsp foo
> \\> echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")" >>foo
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/raw_pre_gcl 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/ -libdir 
> \\> /u/installation/gcl/gcl-2.6.8pre/ < foo
> \\> GCL (GNU Common Lisp)  April 1994  131072 pages
> \\> Building symbol table for 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/raw_pre_gcl ..
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_export.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_defmacro.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_evalmacros.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_top.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_module.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_autoload.lsp
> \\> 
> \\> >
> \\> #<"COMPILER" package>
> \\> 
> \\> >
> \\> #<"SLOOP" package>
> \\> 
> \\> >
> \\> #<"SERROR" package>
> \\> 
> \\> >
> \\> #<"ANSI-LOOP" package>
> \\> 
> \\> >
> \\> #<"DEFPACKAGE" package>
> \\> 
> \\> >
> \\> #<"TK" package>
> \\> 
> \\> >
> \\> #<"SYSTEM" package>
> \\> 
> \\> SYSTEM>
> \\> *COMMAND-ARGS*
> \\> 
> \\> SYSTEM>loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_predlib.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_setf.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_arraylib.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_assert.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_defstruct.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_describe.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_iolib.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_listlib.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_mislib.lsp
> \\> 
> \\> Warning: LISP-IMPLEMENTATION-VERSION is being redefined.loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_numlib.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_packlib.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_seq.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_seqlib.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_trace.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_sloop.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_serror.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_destructuring_bind.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_loop.lsp
> \\> 
> \\> Warning: LOOP is being redefined.loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_defpackage.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_make_defpackage.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpinline.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmputil.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_debug.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_info.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmptype.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpbind.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpblock.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpcall.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpcatch.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpenv.lsp
> \\> 
> \\> Warning: PROCLAIM is being redefined.
> \\> Warning: PROCLAMATION is being redefined.loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpeval.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpflet.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpfun.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpif.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmplabel.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmplam.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmplet.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmploc.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpmap.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpmulti.lsp
> \\> loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpspecial.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmptag.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmptop.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpvar.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpvs.lsp
> \\> loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpwt.lsp
> \\> 
> \\> Loading ../cmpnew/gcl_fasdmacros.lsp
> \\> Finished loading ../cmpnew/gcl_fasdmacros.lsp
> \\> Loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/sys-proclaim.lisp
> \\> Finished loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/sys-proclaim.lisp
> \\> Loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/sys-proclaim.lisp
> \\> Finished loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/sys-proclaim.lisp
> \\> Loading /u/installation/gcl/gcl-2.6.8pre/unixport/../gcl-tk/tk-package.lsp
> \\> Finished loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../gcl-tk/tk-package.lsp
> \\> Loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpmain.lsp
> \\> Warning: COMPILE-FILE is being redefined.
> \\> Warning: COMPILE is being redefined.
> \\> Warning: DISASSEMBLE is being redefined.
> \\> Finished loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpmain.lsp
> \\> Loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_lfun_list.lsp
> \\> Finished loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_lfun_list.lsp
> \\> Loading /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpopt.lsp
> \\> Finished loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../cmpnew/gcl_cmpopt.lsp
> \\> Loading /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_auto_new.lsp
> \\> Finished loading 
> \\> /u/installation/gcl/gcl-2.6.8pre/unixport/../lsp/gcl_auto_new.lsp
> \\> 
> \\> T
> \\> 
> \\> >
> \\> #<"USER" package>
> \\> 
> \\> >rm raw_pre_gcl init_pre_gcl.lsp
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre/unixport'
> \\> (cd lsp; touch *.lsp ; make all)
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre/lsp'
> \\> ../xbin/if-exists: line 13:  9612 Segmentation fault      $3
> \\> gcc: gcl_arraylib.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_arraylib.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9618 Segmentation fault      $3
> \\> gcc: gcl_assert.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_assert.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9624 Segmentation fault      $3
> \\> gcc: gcl_defmacro.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_defmacro.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9630 Segmentation fault      $3
> \\> gcc: gcl_defstruct.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_defstruct.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9636 Segmentation fault      $3
> \\> gcc: gcl_describe.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_describe.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9642 Segmentation fault      $3
> \\> gcc: gcl_evalmacros.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_evalmacros.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9648 Segmentation fault      $3
> \\> gcc: gcl_iolib.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_iolib.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9654 Segmentation fault      $3
> \\> gcc: gcl_listlib.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_listlib.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9660 Segmentation fault      $3
> \\> gcc: gcl_mislib.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_mislib.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9666 Segmentation fault      $3
> \\> gcc: gcl_module.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_module.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9672 Segmentation fault      $3
> \\> gcc: gcl_numlib.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_numlib.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9678 Segmentation fault      $3
> \\> gcc: gcl_packlib.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_packlib.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9684 Segmentation fault      $3
> \\> gcc: gcl_predlib.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_predlib.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9690 Segmentation fault      $3
> \\> gcc: gcl_seq.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_seq.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9696 Segmentation fault      $3
> \\> gcc: gcl_seqlib.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_seqlib.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9702 Segmentation fault      $3
> \\> gcc: gcl_setf.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_setf.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9708 Segmentation fault      $3
> \\> gcc: gcl_top.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_top.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9714 Segmentation fault      $3
> \\> gcc: gcl_trace.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_trace.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9720 Segmentation fault      $3
> \\> gcc: gcl_sloop.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_sloop.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9726 Segmentation fault      $3
> \\> gcc: gcl_debug.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_debug.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9732 Segmentation fault      $3
> \\> gcc: gcl_info.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_info.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9738 Segmentation fault      $3
> \\> gcc: gcl_serror.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_serror.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9744 Segmentation fault      $3
> \\> gcc: gcl_destructuring_bind.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_destructuring_bind.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9750 Segmentation fault      $3
> \\> gcc: gcl_defpackage.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_defpackage.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9756 Segmentation fault      $3
> \\> gcc: gcl_make_defpackage.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_make_defpackage.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9762 Segmentation fault      $3
> \\> gcc: gcl_loop.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_loop.data: No such file or directory
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre/lsp'
> \\> (cd cmpnew; touch *.lsp ; make all)
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre/cmpnew'
> \\> ../xbin/if-exists: line 13:  9772 Segmentation fault      $3
> \\> gcc: gcl_cmpbind.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpbind.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9778 Segmentation fault      $3
> \\> gcc: gcl_cmpblock.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpblock.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9784 Segmentation fault      $3
> \\> gcc: gcl_cmpcall.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpcall.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9790 Segmentation fault      $3
> \\> gcc: gcl_cmpcatch.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpcatch.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9796 Segmentation fault      $3
> \\> gcc: gcl_cmpenv.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpenv.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9802 Segmentation fault      $3
> \\> gcc: gcl_cmpeval.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpeval.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9808 Segmentation fault      $3
> \\> gcc: gcl_cmpflet.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpflet.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9814 Segmentation fault      $3
> \\> gcc: gcl_cmpfun.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpfun.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9820 Segmentation fault      $3
> \\> gcc: gcl_cmpif.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpif.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9826 Segmentation fault      $3
> \\> gcc: gcl_cmpinline.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpinline.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9832 Segmentation fault      $3
> \\> gcc: gcl_cmplabel.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmplabel.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9838 Segmentation fault      $3
> \\> gcc: gcl_cmplam.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmplam.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9844 Segmentation fault      $3
> \\> gcc: gcl_cmplet.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmplet.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9850 Segmentation fault      $3
> \\> gcc: gcl_cmploc.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmploc.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9856 Segmentation fault      $3
> \\> gcc: gcl_cmpmap.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpmap.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9862 Segmentation fault      $3
> \\> gcc: gcl_cmpmulti.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpmulti.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9868 Segmentation fault      $3
> \\> gcc: gcl_cmpspecial.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpspecial.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9874 Segmentation fault      $3
> \\> gcc: gcl_cmptag.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmptag.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9880 Segmentation fault      $3
> \\> gcc: gcl_cmptop.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmptop.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9886 Segmentation fault      $3
> \\> gcc: gcl_cmptype.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmptype.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9892 Segmentation fault      $3
> \\> gcc: gcl_cmputil.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmputil.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9898 Segmentation fault      $3
> \\> gcc: gcl_cmpvar.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpvar.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9904 Segmentation fault      $3
> \\> gcc: gcl_cmpvs.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpvs.data: No such file or directory
> \\> ../xbin/if-exists: line 13:  9910 Segmentation fault      $3
> \\> gcc: gcl_cmpwt.c: No such file or directory
> \\> gcc: no input files
> \\> cat: gcl_cmpwt.data: No such file or directory
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre/cmpnew'
> \\> cd unixport && make saved_gcl
> \\> ls: ../mod/*.o: No such file or directory
> \\> ls: ../pcl/*.o: No such file or directory
> \\> ls: ../clcs/*.o: No such file or directory
> \\> ls: ../clcs/clcs_*.lisp: No such file or directory
> \\> make[1]: Entering directory `/u/installation/gcl/gcl-2.6.8pre/unixport'
> \\> gcc -Wall -DVOL=volatile -fsigned-char -pipe -O3 -fomit-frame-pointer  
> \\> -I/u/installation/gcl/gcl-2.6.8pre/o   -c -o sys_gcl.o sys_gcl.c
> \\> rm -rf libgcl.a
> \\> ar rs libgcl.a ../o/alloc.o ../o/array.o ../o/assignment.o ../o/backq.o 
> \\> ../o/bds.o ../o/big.o ../o/bind.o ../o/bitop.o ../o/block.o ../o/catch.o 
> \\> ../o/cfun.o ../o/character.o ../o/clxsocket.o ../o/cmpaux.o 
> \\> ../o/conditional.o ../o/earith.o ../o/error.o ../o/eval.o 
> \\> ../o/fat_string.o ../o/file.o ../o/format.o ../o/frame.o ../o/funlink.o 
> \\> ../o/gbc.o ../o/gcl_readline.o ../o/gmp_wrappers.o ../o/hash.o 
> \\> ../o/init_pari.o ../o/iteration.o ../o/let.o ../o/lex.o ../o/list.o 
> \\> ../o/macros.o ../o/main.o ../o/makefun.o ../o/mapfun.o ../o/multival.o 
> \\> ../o/new_init.o ../o/nfunlink.o ../o/nsocket.o ../o/num_arith.o 
> \\> ../o/number.o ../o/num_comp.o ../o/num_co.o ../o/num_log.o ../o/num_pred.o 
> \\> ../o/num_rand.o ../o/num_sfun.o ../o/package.o ../o/pathname.o ../o/plt.o 
> \\> ../o/predicate.o ../o/print.o ../o/prog.o ../o/read.o ../o/reference.o 
> \\> ../o/regexpr.o ../o/run_process.o ../o/sequence.o ../o/sfasl.o 
> \\> ../o/sockets.o ../o/string.o ../o/structure.o ../o/symbol.o 
> \\> ../o/toplevel.o ../o/typespec.o ../o/unixfasl.o ../o/unixfsys.o 
> \\> ../o/unixsave.o ../o/unixsys.o ../o/unixtime.o ../o/usig2.o ../o/usig.o 
> \\> ../o/utils.o ../lsp/gcl_arraylib.o ../lsp/gcl_assert.o ../lsp/gcl_debug.o 
> \\> ../lsp/gcl_defmacro.o ../lsp/gcl_defpackage.o ../lsp/gcl_defstruct.o 
> \\> ../lsp/gcl_describe.o ../lsp/gcl_destructuring_bind.o 
> \\> ../lsp/gcl_evalmacros.o ../lsp/gcl_info.o ../lsp/gcl_iolib.o 
> \\> ../lsp/gcl_listlib.o ../lsp/gcl_loop.o ../lsp/gcl_make_defpackage.o 
> \\> ../lsp/gcl_mislib.o ../lsp/gcl_module.o ../lsp/gcl_numlib.o 
> \\> ../lsp/gcl_packlib.o ../lsp/gcl_predlib.o ../lsp/gcl_seqlib.o 
> \\> ../lsp/gcl_seq.o ../lsp/gcl_serror.o ../lsp/gcl_setf.o ../lsp/gcl_sloop.o 
> \\> ../lsp/gcl_top.o ../lsp/gcl_trace.o ../cmpnew/gcl_cmpbind.o 
> \\> ../cmpnew/gcl_cmpblock.o ../cmpnew/gcl_cmpcall.o ../cmpnew/gcl_cmpcatch.o 
> \\> ../cmpnew/gcl_cmpenv.o ../cmpnew/gcl_cmpeval.o ../cmpnew/gcl_cmpflet.o 
> \\> ../cmpnew/gcl_cmpfun.o ../cmpnew/gcl_cmpif.o ../cmpnew/gcl_cmpinline.o 
> \\> ../cmpnew/gcl_cmplabel.o ../cmpnew/gcl_cmplam.o ../cmpnew/gcl_cmplet.o 
> \\> ../cmpnew/gcl_cmploc.o ../cmpnew/gcl_cmpmap.o ../cmpnew/gcl_cmpmulti.o 
> \\> ../cmpnew/gcl_cmpspecial.o ../cmpnew/gcl_cmptag.o ../cmpnew/gcl_cmptop.o 
> \\> ../cmpnew/gcl_cmptype.o ../cmpnew/gcl_cmputil.o ../cmpnew/gcl_cmpvar.o 
> \\> ../cmpnew/gcl_cmpvs.o ../cmpnew/gcl_cmpwt.o sys_gcl.o 
> \\> ar: creating libgcl.a
> \\> cp init_gcl.lsp.in init_gcl.lsp.tmp
> \\> cat init_gcl.lsp.tmp | sed \
> \\> 	-e "s#@LI-VERS@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \
> \\> 	-e "s#@LI-EXTVERS@#`cat ../minvers | cut -f2 -d.`#1" \
> \\> 	-e "s#@LI-MINVERS@#`cat ../minvers | cut -f1 -d.`#1" \
> \\> 	-e "s#@LI-MAJVERS@#`cat ../majvers`#1" \
> \\> 	-e "s#@LI-CC@#\"gcc -c -Wall -DVOL=volatile -fsigned-char -pipe 
> \\> \"#1" \
> \\> 	-e "s#@LI-LD@#\"gcc -o \"#1" \
> \\> 	-e "s#@LI-LD-LIBS@#\"   -lgcl -lm  -lgmp /usr/lib/libbfd.a 
> \\> /usr/lib/libiberty.a -lreadline -lncurses -lc -lgclp \"#1" \
> \\> 	-e "s#@LI-OPT-THREE@#\"-O3 -fomit-frame-pointer\"#1" \
> \\> 	-e "s#@LI-OPT-TWO@#\"-O\"#1" \
> \\> 	-e "s#@LI-INIT-LSP@#\"init_gcl.lsp\"#1" >init_gcl.lsp
> \\> touch raw_gcl_map
> \\> gcc -o raw_gcl  \
> \\> 	-L.  -Wl,-Map raw_gcl_map   -lgcl -lm  -lgmp /usr/lib/libbfd.a 
> \\> /usr/lib/libiberty.a -lreadline -lncurses -lc -lgclp 
> \\> ./libgcl.a(sys_gcl.o)(.text+0x34a1): In function `gcl_init_system':
> \\> sys_gcl.c: undefined reference to `init_gcl_cmpwt'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3532):sys_gcl.c: undefined reference to 
> \\> `init_gcl_predlib'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x35c3):sys_gcl.c: undefined reference to 
> \\> `init_gcl_setf'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3654):sys_gcl.c: undefined reference to 
> \\> `init_gcl_assert'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x36e5):sys_gcl.c: undefined reference to 
> \\> `init_gcl_arraylib'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3776):sys_gcl.c: undefined reference to 
> \\> `init_gcl_defstruct'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3807):sys_gcl.c: undefined reference to 
> \\> `init_gcl_describe'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3898):sys_gcl.c: undefined reference to 
> \\> `init_gcl_numlib'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3929):sys_gcl.c: undefined reference to 
> \\> `init_gcl_listlib'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x39ba):sys_gcl.c: undefined reference to 
> \\> `init_gcl_seq'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3a4b):sys_gcl.c: undefined reference to 
> \\> `init_gcl_iolib'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3adc):sys_gcl.c: undefined reference to 
> \\> `init_gcl_packlib'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3b6d):sys_gcl.c: undefined reference to 
> \\> `init_gcl_mislib'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3bfe):sys_gcl.c: undefined reference to 
> \\> `init_gcl_seqlib'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3c8f):sys_gcl.c: undefined reference to 
> \\> `init_gcl_trace'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3d20):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpenv'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3db1):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmputil'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3e42):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmploc'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3ed3):sys_gcl.c: undefined reference to 
> \\> `init_gcl_loop'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3f64):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpif'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x3ff5):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpbind'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4086):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmptag'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4117):sys_gcl.c: undefined reference to 
> \\> `init_gcl_serror'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x41a8):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpflet'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4239):sys_gcl.c: undefined reference to 
> \\> `init_gcl_info'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x42ca):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpmulti'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x435b):sys_gcl.c: undefined reference to 
> \\> `init_gcl_make_defpackage'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x43ec):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmplam'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x447d):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpcall'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x450e):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpvar'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x459f):sys_gcl.c: undefined reference to 
> \\> `init_gcl_sloop'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4630):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpeval'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x46c1):sys_gcl.c: undefined reference to 
> \\> `init_gcl_debug'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4752):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpmap'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x47e3):sys_gcl.c: undefined reference to 
> \\> `init_gcl_defpackage'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4874):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmplabel'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4905):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpblock'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4996):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmptop'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4a27):sys_gcl.c: undefined reference to 
> \\> `init_gcl_destructuring_bind'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4ab8):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpfun'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4b49):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmptype'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4bda):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpspecial'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4c6b):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpinline'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4cfc):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmplet'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4d8d):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpcatch'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x4e1a):sys_gcl.c: undefined reference to 
> \\> `init_gcl_cmpvs'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x5693): In function `gcl_init_init':
> \\> sys_gcl.c: undefined reference to `init_gcl_defmacro'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x5701):sys_gcl.c: undefined reference to 
> \\> `init_gcl_evalmacros'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x576f):sys_gcl.c: undefined reference to 
> \\> `init_gcl_top'
> \\> ./libgcl.a(sys_gcl.o)(.text+0x57dd):sys_gcl.c: undefined reference to 
> \\> `init_gcl_module'
> \\> collect2: ld returned 1 exit status
> \\> make[1]: *** [raw_gcl] Error 1
> \\> rm init_gcl.lsp.tmp raw_gcl_map
> \\> make[1]: Leaving directory `/u/installation/gcl/gcl-2.6.8pre/unixport'
> \\> make: *** [unixport/saved_gcl] Error 2
> \\> [root@horatio-228 gcl-2.6.8pre]#

\start
Date: Tue, 29 Nov 2005 17:58:54 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Units and Dimensions - example pdf and dvi files

On Tuesday, November 29, 2005 4:14 PM C Y wrote:
>
> Well, still not approved for public visibility

Sorry, I've been a bit busy with other things. Do you still
want these documents approved or would you like to wait for a
more final version? No problem either way. I am just hesitating
because I am not sure whether I have explained how this
"publishing" thing works properly yet.

> but it looks like a direct link to each file will allow folks
> to view them.

Yes, by default new documents are "visible" which means that
only users of the portal who are logged-in will see them in the
list of "recent items" and as a result of a search for keywords.
If not logged in they will not see them but a direct link like
in this email will work for anyone.

If a document is "published" then it will be visible even if
not logged in and so (sooner or later) is will also appear in
Google and other search engines who regularly index this site.

> This is a collection of a variety of formatting options that
> can be achieved with the options included in the preamble.
> For those who want the fanciest result, I recommend the XYpic
> diagram version in pdf format:
>
http://portal.axiom-developer.org/Members/starseeker/axiomunit_diagramte
st.pdf
>
> For those who want to check out dvi vs. pdf, and/or various
> options, here are the others:
>
> http://portal.axiom-developer.org/Members/starseeker ...
>  /axiomunit_standard.dvi
>  /axiomunit_standard.pdf
>  /axiomunit_standardsize_withhyperref.dvi
>  /axiomunit_standardsize_withhyperref.pdf
>  /axiomunit_1inmargins_withhyperref.dvi
>  /axiomunit_1inmargins_withhyperref.pdf
>  /axiomunit_diagramtest.dvi
>  /axiomunit_diagramtest.pdf
>

Note: You don't need to include '/download' in the link.

You might also want to add these links to your home page on the
portal. This would let you refer to a shorter url like above.
If you need help doing this, just ask.

I am not sure why you want to display all these different
versions. Are you looking for comments on the format?

Personally I like the one with the hyperref links and the
diagram. Why wouldn't everyone want that? I don't care about
the margins - whatever looks good to you is fine with me.

As to the content, I think it looks very interesting and
is going to require a bit more study.

Thanks again for working on this.

\start
Date: Tue, 29 Nov 2005 18:44:41 -0500
From: Tim Daly
To: Camm Maguire
Subject: Re: ACL2 compiling problems
Cc: Matt Kaufmann, Sandip Ray

===================================================================
FAQ 36: Axiom won't build on FC3
===================================================================
You need to turn off dynamic library load point randomization.
As root do:

echo 0 >/proc/sys/kernel/exec-shield


===================================================================
FAQ 37: Axiom won't build on FC4
===================================================================
You need to turn off dynamic library load point randomization.
As root do:

echo 0 >/proc/sys/kernel/randomize_va_space

or do

setarch i386 -R make axiom

\start
Date: Tue, 29 Nov 2005 19:56:52 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: re: article "standard" header/footer

> My problem with HyperDoc is that there are quite a number of commands 
> and no good documentation what they are for. I would clearly prefer my 
> aldordoc.sty even though it does not cover all things HyperDoc can do.

we probably need to re-think the input language for the browser.
we can take up that problem while writing the browser volume documentation
(that is, once we understand how it works already). there is a lot to
be said for making it html (which didn't exist at the time) or some
other standard that browsers understand.

\start
Date: Tue, 29 Nov 2005 19:59:03 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

> > I promised to give you some idea of the pamphlet and book file coding
> > "standards". This is the current "state of the world" which evolves
> > as I write more pamphlet files. However, as I re-edit old files I
> > modify them to conform to these standards.
> 
> In ALLPROSE I have specifically introduced a "Convention" environment 
> since I found myself using some conventions that were nowhere else 
> documented. So the pamphlet standards should go into a section of the 
> Axiom book (part documentation).

the mail i sent you has already been added to volume 4: developer's guide.
of course it'll all have to be rewritten once we converge on some real
agreed-upon conventions. given that everyone does things differently
already we're in for a real language war :-)

\start
Date: Tue, 29 Nov 2005 19:15:09 -0500
From: Tim Daly
To: Martin Rubey
Subject: re: article "standard" header/footer

whew. hours worth of email! 95 new, nonspam emails! 

> Many contributions consist of several packages, categories and domains, which
> are somehow related. 

There are some clear relations. For instance, many files contain more than
one category, domain, or package (CDP). 

The very highest level of thought I've given to the problem of 
documenting the algebra (the same problem exists in the CATS (computer
algebra test suite) project) and amounts to this:

  is there an existing categorization of math we can use?

    there is a general purpose math categorization but it is too general

    there appears to be a specific one for numeric mathematics done by NIST

    there does not appear to be a specific categorization for 
    symbolic mathematics. we may need to invent one. in fact I 
    wrote up a grant proposal to NIST for exactly this effort
    but they have $0 dollars for new research in this year's budget.
    

At the next level comes the axiom-specific question of how to organize
the algebra code. Bill and I spent a fair amount of time trying to
figure out how to display and organize the algebra hierarchy and, so
far, there is still no output on the problem.

Somehow I envisioned an attack on the problem that kept each CDP in
a separate, hyperref connected, literate document which would be a
\section in a larger \chapter in a larger \subject.

The algebra is a graph at its core and a lattice above the first 50-75
files. This does not lend itself well to any linear layout. Hyperlinking
helps but you REALLY need a good map of where you are. Bill has some
experience with a tool called TOUCHGRAPH.

Writing the algebra is going to first have to attack the "map"
and layout problems so we can each work on subgraphs and know 
where we are.

\start
Date: Tue, 29 Nov 2005 20:12:52 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

> > Each file I make into a "literate program" has a "head" and a "tail"
> > that contains essentially the same code for the same reasons. The only
> > major deviation is that I will occasionally include the "axiom.sty" file
> > in the literate document if it is meant to be stand-alone and the user
> > is unlikely to have it.
> 
> Sorry, but I cannot completely agree here. I would NEVER include 
> axiom.sty into the document. It would be duplication of code and hard to 
> maintain.

Actually there are occasions that I include axiom.sty in documents.
Since everything I write these days starts life as a literate program
(even the stuff I do for work) I find that I'm sending other non-axiom
people literate programs. Without axiom.sty they run into the same
problem I had with ALLPROSE. (remember that I spent a fair amount of
time googling for the .sty files you didn't include). 

So what I do is include the axiom.sty file as a dependent clause in
the Makefile and it gets automatically extracted when the person
tries to build the document. Turns out to be quite convenient. I agree
about the long-term maintenance issue but that has nothing to do with
standalone documents.

I hate getting a document that requires .sty files I can't find.
You point out that people COULD include them in the zip file but
often they just assume everyone has them which is not true.

This is NOT an issue for axiom documents in an axiom system.

As to the maintanence issue Axiom is a large enough project that
maintaining a special .sty file for the project is perfectly reasonable.
their own .sty files for papers and thesis work. Of course, we're
going to have to make the src/doc/axiom.sty.pamphlet file 
have real documentation.

Developers of axiom should use the axiom.sty to get a common, hopefully
agreed-upon style when there is a command that we use already. This 
does NOT mean that we have to swallow all other .sty files (like I 
did with noweb) but there are good reasons to do this if the .sty
file is going to be fundamental and we have things we want to change.
I have long-term ideas about literate programming that go beyond what
noweb provides and expect to have to rewrite the noweb commands to be
more baroque.


\start
Date: Tue, 29 Nov 2005 20:21:49 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

> I also do not agree to the goal that each file is ONE literate program 
> and in some sense stand alone. I, therefore, think that "head" and 
> "tail" should not be part of a file, just the things that are inside the 
> \begin{document} ... \end{document}.
> 
> If you like a wrapper, write a little script like "document" which adds 
> "head" and "tail" on the fly. You design them to be equal anyway.
> 
> Then, I don't see, why we need standards for "article" and standards for 
> "book" and why they should/could differ.
> 
> The Axiom book consists of parts. Each part covers a certain area of 
> Axiom. So a Part consists of some "executive summary" and then includes 
> the code (ehm pamphlet) files that belong to that part.

I agree with this point actually. But for the moment they are all 
standalone. However as I swallow the src/interp files into bookvol5
all of the "tex overhead" disappears. 

I thought about making the document command add the header/footer
information but I was more focused on providing the \author
information for each file. And I started with trying to write
a "canonical example" of an axiom literate program which became
dhmatrix.spad.pamphlet. recovering the historical credit information
was the overriding concern. since \author occurs in the preamble each
file needed a preamble. then there was the bibliography issue (which
was originally only in dhmatrix) which was presumed different for 
each file. eventually i thought about the bibtex approach, wrote
axiom.bib.pamphlet, but only implemented it for one document as a
proof of concept and didn't get it spread everywhere.

so, yes, i agree that i should probably figured out a non-preamble
approach but didn't.

\start
Date: 29 Nov 2005 19:33:36 -0500
From: Camm Maguire
To: Tim Daly
Subject: re: ACL2 compiling problems
Cc: Sandip Ray, Matt Kaufmann

Greetings, and thanks Tim!  I thought this was unnecessary with
2.6.8pre, no?

Take care,

Tim Daly writes:

> ===================================================================
> FAQ 36: Axiom won't build on FC3
> ===================================================================
> You need to turn off dynamic library load point randomization.
> As root do:
> 
> echo 0 >/proc/sys/kernel/exec-shield
> 
> 
> ===================================================================
> FAQ 37: Axiom won't build on FC4
> ===================================================================
> You need to turn off dynamic library load point randomization.
> As root do:
> 
> echo 0 >/proc/sys/kernel/randomize_va_space
> 
> or do
> 
> setarch i386 -R make axiom

\start
Date: Tue, 29 Nov 2005 20:25:20 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer


> 
> So the focus is on providing the parts. In the spirit of ALLPROSE that 
> could mean the following:
> 
> 1) Write some chapters about the general idea.
> Then a chapter that lists the files names (of the files that form the 
> contents of the book) together with a short description of what the 
> corresponding file contains. Then simply include all those files.

this is the "booklet" idea (well, partially). you would be able to say

<<file://$AXIOM/src/doc/foo.pamphlet>>=
@

or 

<<http://wiki.axiom-developer.org/sources/doc/foo.pamphlet>>=
@

or

<<protocol://whatever>>=
@

<<mathml://whatever>>=
@

so SOME chunk names would have recognized syntax to preprocess or
fetch other files.

\start
Date: Tue, 29 Nov 2005 19:48:11 -0500
From: Tim Daly
To: Cliff Yapp
Subject: re: article "standard" header/footer

> 
> For what it's worth, I would estimate I'll eventually ask to have the
> following available, since they are very standard and too big to reall
> :
> 
> 1) hyperref (which I see you've already decided to include)

agreed. this is important because 
(a) the code isn't linear,
(b) we eventually want it all available in a browser frontend and
(c) a way to use this in graphs would give us a good "map" ability

it would be cool to take the src/doc/endpapers.pamphlet and make it
display well on MathAction with hyperref links to the algebra.



> 2) bibtex (I'm working on an example based on the units work, but I
> will need to do some thinking before I have a good example ready)

as i've mentioned before the thought is to use src/doc/axiom-bib.pamphlet
as the basis for an annotated bibliography. i think it is important that
we centralize this and use a common mechanism rather than spread the
bibtex across hundreds of individual files. and the annotations will
be valuable in the long run anyway.

i'm convinced that i need to remove \begin{thebibliography} from
all of the files and use the bibtex mechanism. it's on the todo list.
(of course, i have to re-re-remember how to do bibtex :-) )




> 3) XYpic - I think this is gong to prove very very useful once I figure
> out how to use it properly - it seems like it might potentially allow
> inclusion of graphs directly into pamphlet files and not as graphical
> files, among other features - I think it will also allow hyperlinking
> nodes of graphs to code, although I'm still trying to come up with a
> scheme for layout of such a graph which looks reasonable. 
> Unfortunately it is GPL so we can't include it in axiom.sty, but tetex
> at least includes it by default so I'm guessing it wouldn't be too much
> trouble.  Maybe we could contact the authors and ask if it becomes an
> issue.

we certainly need two kinds of environments, 

one for pictures. i've tried several and they "sort of" work but the
pictures float all over the place and i've never succeeded in getting
two pictures separated by text on the same page. this is still an
outstanding problem with the book.pamphlet file. gotta solve it someday.
the book.pamphlet uses 'GRAPHICX'

one for diagrams. i use a package called PSTRICKS in the
src/doc/endpaper.pamphlet that did the job reasonably well but 
i'm open to other suggestions. we could test competing packages
against rewritten versions of the endpaper pamphlet.




> ifthen and fontenc I'm willing to pass up, but I would like to know how
> we will handle:
> 
> a)  different options to hyperref based on pdf or dvi creation
> b)  line breaking of equations
> c)  specifying different sizes, fonts, etc for text.  This is probably
> just my ignorance of LaTeX

i'm DEEPLY opposed to conditional branching in tex documents. even
if there is one good use i assure you some bright spot down the line
will figure out a way to conditionally build algebra documents
based on half-a-thousand switches. and if something gets skipped
it is hard to recognize that something that "should" be there isn't.

fundamentally the goal of a literate document is to communicate 
with people, most of whom are reading the document because they
want to learn and understand the material. making a document that
has conditions they need to choose up front means that they know
what they want.

i'd rather put all the conditionalization into the build process
before latex runs and keep the documents non-branching.

\start
Date: Tue, 29 Nov 2005 20:29:47 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer


> Maybe you don't like it, but I use a slightly different approach in 
> ALLPROSE. What comes out as defn and use in your case comes out in red 
> and blue color in the index in ALLPROSE. And you would simply say:
> \defineterm{foo} and \useterm{foo}. Read the description of 
> rhxterm.sty.nw on http://www.hemmecke.de/aldor. It even hyperlinks the 
> foo in \useterm to the foo in \defineterm, not just putting something 
> into the index.


ummm, i'm partially colorblind to red and green :-)

the \defineterm and \useterm are perfect examples of axiom.sty commands.
they should be used everywhere. being lazy i didn't write a \newcommand
to do this but just do it inline. but it's a good idea.

\start
Date: Tue, 29 Nov 2005 20:39:32 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

> 
> > =======================================================================
> > and now the standard "tail":
> > =======================================================================
> > \section{Makefile}
> > <<*>>=
> > PROJECT=tpd
> > TANGLE=/usr/local/bin/NOTANGLE
> > WEAVE=/usr/local/bin/NOWEAVE
> > LATEX=/usr/bin/latex
> > LISP=/sei/lisp
> > MAKEINDEX=/usr/bin/makeindex
> > 
> > all: ${PROJECT}.lisp ${PROJECT}.dvi test
> > 
> > ${PROJECT}.lisp: ${PROJECT}.pamphlet
> > 	${TANGLE} -Rlisp ${PROJECT}.pamphlet >${PROJECT}.lisp
> > 
> > ${PROJECT}.dvi:
> > 	${TANGLE} -Rdummyindex ${PROJECT}.pamphlet >${PROJECT}.ind
> > 	${WEAVE} -t8 -delay ${PROJECT}.pamphlet >${PROJECT}.tex
> > 	${LATEX} ${PROJECT}.tex 
> > 	@{MAKEINDEX} ${PROJECT}.idx
> > 	${LATEX} ${PROJECT}.tex 
> > 
> > test:
> > 	cat ${PROJECT}.lisp | ${LISP}
> > 
> > remake:
> > 	${TANGLE} -t8 ${PROJECT}.pamphlet >Makefile.${PROJECT}
> > 
> > @
> 
> No, I cannot follow. You mean the Makefile is part of the file that 
> contains the LISP code?

yes. this goes to the issue of writing the document. to build axiom
you must do the "make" from the root directory as every subdirectory
make gets its environment information managed by its parent make.
this is, ultimately, a bad design on my part but it exists in the
current system. in the future i hope to eliminate most, if not all, 
of the makefiles in the source tree. 

there are two reasons for including a Makefile as the default chunk
(only one of which is axiom related).

someone writing a pamphlet NOW has the problem that they need
to incrementally write/modify/write. and if you move around quite
a bit in the source tree (which i do) it is quite convenient to just type 
  make -f Makefile.foo
and have foo "do the right thing".

Note that these "developement Makefiles" are NOT used by the build
system. they are only there for development use. 

i can't claim it's a good idea for everyone but it makes development
incredibly faster since it gives emacs a way to know how to build 
any file. 

notice that none of the actual sources in the axiom tree contain
these makefiles. so i guess i managed to claim as "standard" my
"local standard" for working which is a bad idea. 

\start
Date: Tue, 29 Nov 2005 20:44:41 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

> 
> I don't say it is generally a bad idea, but I cannot say that I like it. 
> In particular, I don't see, why the variables TANGLE, WEAVE, etc. should 
> be repeated in every file.

oh, this is an artifact of an OLD debate. people want to use their
"standard" version of notangle even though i keep telling them that
axiom applies patches. you ran into the problem (and solved it yet
again in a different way). axiom code needs axiom's notangle. but
i seem to have lost that war.

since i've also been porting axiom to various systems i've taken to
making EVERY command be a makefile variable as a matter of style.
i tried to port to FreeBSD and got bitten by the fact that certain
commands are not the same between systems. windows is a prime example.

it's a false generality in this case because i don't export these
Makefile-enabled pamphlets off my system (unless i send you a non-axiom
standalone program where i always use them)

\start
Date: Tue, 29 Nov 2005 20:45:31 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

> 
> For the .dvi generation I rather like to write a script so that the 
> inverse search becomes available.

this comment is lost on me.
please explain in detail.

\start
Date: Tue, 29 Nov 2005 20:47:43 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

> 
> By the way, you need "dummyindex" because you have 
> \input{${PROJECT}.ind} below. \printindex is enough.
> 
> > \eject
> > \begin{thebibliography}{99}
> > \bibitem{1} nothing
> > \end{thebibliography}
> > <<dummyindex>>=
> > \begin{theindex}
> >  \item none
> > \end{theindex}
> > \printindex
> > \input{${PROJECT}.ind}
> > \end{document}

on my system latex blows up on the \input if project.ind does not exist.
the first time you build a pamphlet project.ind does not exist.
so you have to make sure it exists (hence dummyindex).
i suppose if i were thinking ahead i could have just done 'touch foo.ind'.
sigh. hindsight is good stuff.

\start
Date: Tue, 29 Nov 2005 20:49:18 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

> 
> The thebibliography environment is superfluous if we agree on ONE big 
> .bib file and UNIQUE BibKeys. It is even more flexible.
> 
> > =======================================================================
> > 
> > and now the way I work with these:
> > 
> > =======================================================================
> > 
> > 
> >  notangle -t8 foo.pamphlet >Makefile.foo
> > 
> >     this extracts the default chunk <<*>>= which is a makefile and
> >     names it Makefile.foo.
> > 
> >  make -f Makefile.foo
> > 
> >     this completely rebuilds all of the foo project.
> 
> Aha, that means you have one "project" per file. May I ask what a 
> "project" is in your case, in particular, how big it is?

remember these individual makefiles only work with their own pamphlet.
"project" is the name of the pamphlet file without the .pamphlet 

thus bookvol5.pamphlet has


PROJECT=bookvol5

\start
Date: Tue, 29 Nov 2005 21:24:42 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: re: Axiom Wiki FrontPage re-design

> Call me old-fashioned, but in order to edit pamphlet files, I would get 
> the arch-sources and do something locally and then submit. Only for 
> small changes the web-access to the sources makes sense to me. Anyway, 
> it is not quite clear to me how modifications to the sources made over 
> the web will eventually find their way into axiom--main. Will Tim 
> incorporate them by hand? I guess the ChangeSet idea becomes a bit 
> blurred here.

ok. you're old-fashioned. but so am i so it's a bit of a struggle to
think thru the idea of hacking real sources on a website. however
bill has a good idea with this wiki site and he's managed to get
the sources online and automatically generated.

i'm all in favor of taking an idea and pushing it beyond the reasonable
and into blue-sky territory and this is one of those ideas.

the logical progression is that since we have web sources that can
be modified we should consider moving into the late 90s and stop thinking
"batch process" like CVS/Arch/Darcs and move toward "instant" processes
that would allow us to modify a web page, make axiom, and run it in a
sandbox all online.

since the website maintains a changelog/undo facility many people can
work on their local copy (a DOYEN with a browser?) and transparently
move to the wiki. 

using the wiki this way for math could be VERY cool. suppose you find
that a certain function does not compute a result. what would it take
to click on the function and be taken to it's definition (note that 
this requires tight cooperation with axiom since there are hundreds
of functions with the same name but different type signatures). and
once you've found the definition you study it for a while, write some
comments about what failed, come back in a few days with a solution,
type in the solution (and document it), remake axiom, go back to the
sandbox and test it. if it works you "promote" it to the reviewers
for inclusion into the "approved" source tree. 

each user could have their own branch of axiom.

of course, this will cause major "mainline" headaches for the "approved"
source tree but that's hardly the experimenter's problem. 

we could call this idea "scratchpad"
and make a "scratchpad" wiki where each user has their own branch.

frankly i think it's an exciting idea.

\start
Date: Tue, 29 Nov 2005 17:55:21 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: Units and Dimensions - example pdf and dvi files

--- Bill Page wrote:

> On Tuesday, November 29, 2005 4:14 PM C Y wrote:
> > 
> > Well, still not approved for public visibility
> 
> Sorry, I've been a bit busy with other things. Do you still
> want these documents approved or would you like to wait for a
> more final version? No problem either way. I am just hesitating
> because I am not sure whether I have explained how this
> "publishing" thing works properly yet.

No problem.  If the direct linking works, I think that's plenty for
now.  As I'm sure you've noticed, this version is anything but final. 
I wasn't sure if that link working was accidental or intentional.

> > but it looks like a direct link to each file will allow folks
> > to view them.
> 
> Yes, by default new documents are "visible" which means that
> only users of the portal who are logged-in will see them in the
> list of "recent items" and as a result of a search for
> keywords. If not logged in they will not see them but a direct
> link like in this email will work for anyone.

I like that - it's a good system, and allows lots of flexibility.  I
suppose most folks on this list probably have logins to the portal
anyway, or should by now ;-).

> If a document is "published" then it will be visible even if
> not logged in and so (sooner or later) is will also appear in
> Google and other search engines who regularly index this site.

Ooo, good point.  Yes, better leave them unpublished.  I'll cancel the
submitted status when I get a chance.

> Note: You don't need to include '/download' in the link.

Ah :-).  Excellent.
 
> You might also want to add these links to your home page on the
> portal. This would let you refer to a shorter url like above.
> If you need help doing this, just ask.

OK, I'll take a shot at that when I get a chance.

> I am not sure why you want to display all these different
> versions. Are you looking for comments on the format?

Well, the different formatting options are to show the flexibility of
the header system I'm using.  I'm making my case for the conditional
logic in the preamble by showing what can be achieved - all of those
versions except the xypic diagram ones were the result of simply
commenting or uncommenting a couple of lines in the file.

For those who just want to look at the current state of the units and
dimensions document, the xypic pdf is the recommended one.

> Personally I like the one with the hyperref links and the
> diagram. Why wouldn't everyone want that? I don't care about
> the margins - whatever looks good to you is fine with me.

Well, the drawbacks of that one are a) it uses a VERY non-standard
preamble, and b) the XYpic diagram increases the size quite a bit and
for some reason is relatively slow to render in Acrobat Reader.

I prefer the current "standard" margins for reading, but I like having
the option of easily switching to the 1in margins for printing, since
it saves almost ten pages IIRC.  That's the only utility there.  I got
a bit fancy and allowed automatic resizing of a couple of large
equations based on the two margin sizes, but breqn would be a
preferable solution there if the license is ever straightened out.  (Or
we implement our own version of it.)

> As to the content, I think it looks very interesting and
> is going to require a bit more study.

Thanks.  I apologize in advance for it's unfinished state, but I did
want to at least show that I've been doing SOMETHING.

\start
Date: Tue, 29 Nov 2005 21:51:54 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Units and Dimensions - example pdf and dvi files

CY,

I liked the 'axiomunit_diagramtest' version a lot.
I'll have to try that with src/doc/endpaper.
Can you post or send the diagram code?

re: 1 inch margins (2.54 cm for our other friends :-))

my book publisher told me that a 6 inch line was an industry standard
because, in their experience, it is the least tiring line of text to
read. we complained about this because, as you'll notice, the text
format of the axiom hardcover book has a LOT of margin space (which
we filled with comments). this margin was a fight between book size
and line size.

\start
Date: Tue, 29 Nov 2005 21:55:59 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Units and Dimensions - example pdf and dvi files

> I got a bit fancy and allowed automatic resizing of a couple of large
> equations based on the two margin sizes, but breqn would be a
> preferable solution there if the license is ever straightened out.  (Or
> we implement our own version of it.)

if breqn is an equation line breaker we have one of those.
bill is the keeper of the latest set of changes i believe.

\start
Date: Tue, 29 Nov 2005 18:18:57 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Units and Dimensions - example pdf and dvi files

--- Tim Daly wrote:

> CY,
> 
> I liked the 'axiomunit_diagramtest' version a lot.
> I'll have to try that with src/doc/endpaper.
> Can you post or send the diagram code?

Actually, the whole tex file is posted, I just didn't link to it ;-).

http://portal.axiom-developer.org/Members/starseeker/axiomunit_v2.tex

Tim, if you're opposed to the conditional latex in the preamble what
about the local.sty idea?  Or different .sty files that can be invoked
by the make process?  As you can see a lot can be achieved with various
packages, and I know there is at least one more I intend to use
(sistyle) which was written to output units and quantities in
accordance with the official SI formatting rules.  Of course, that's
highly specific to the Units and Dimensions package for now, but later
on with other scientific pamphlets it may also be of considerable use. 
Then there are other LaTeX routines out there for things like chemical
formulas and High Energy Physics particle names, and I would like to
take advantage of the work those authors have put into getting good
formatting.  I merely mention it here as an issue to think about. 
Obviously I have no examples yet of files that make use of these
efforts, but I hope someday either I or someone else will have good
reason to want to use them.

> re: 1 inch margins (2.54 cm for our other friends :-))
> 
> my book publisher told me that a 6 inch line was an industry
> standard because, in their experience, it is the least tiring 
> line of text to read. we complained about this because, as 
> you'll notice, the text format of the axiom hardcover book has
> a LOT of margin space (which we filled with comments). this
> margin was a fight between book size and line size.

Actually, I'm not too worried about that from a book standpoint - when
we publish, I'm all for making it as readable as possible and I don't
mind buying a slightly thicker book from lulu (maybe a bit more
expensive but I'm inclined to trust the publishers that the 6 inch line
is a good thing).  I like the 1 inch margin for when I need to print
off a draft of a pamphlet to read which will not be perminant - in that
case I get economy minded and want to save paper, since I might wind up
printing a lot of development versions of things.

That reminds me, actually - if we don't do the CD and other fancy stuff
but just do hardbound books, do we still have to have a minimum run of
100?  IIRC our original quote was over a year ago so I'm sort of hoping
things might have changed.  Obviously softbound will do but it would be
nice for libraries and such to have hardbound available, if they are so
inclined :-).

\start
Date: Tue, 29 Nov 2005 18:33:40 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: re: article "standard" header/footer

--- Tim Daly wrote:
> > 
> > 1) hyperref (which I see you've already decided to include)
> 
> agreed. this is important because 
> (a) the code isn't linear,
> (b) we eventually want it all available in a browser frontend 
>     and
> (c) a way to use this in graphs would give us a good "map" 
>     ability

As you can see in the Units file, XYpic enables (c).  Not all the links
are active in that version, but it was 2am and I was tired ;-).

> it would be cool to take the src/doc/endpapers.pamphlet and 
> make it display well on MathAction with hyperref links to the
> algebra.

Hmm :-).  For the inattentive among us, what is endpapers.pamphlet
again?

> > 2) bibtex (I'm working on an example based on the units 
> >    work, but I will need to do some thinking before I 
> >    have a good example ready)
> 
> as i've mentioned before the thought is to use src/doc/axiom-
> bib.pamphlet as the basis for an annotated bibliography. i 
> think it is important that we centralize this and use a common
> mechanism rather than spread the bibtex across hundreds of 
> individual files. and the annotations will be valuable in the 
> long run anyway.

Oh, agreed.  I ment how to structure and format the bib file.
 
> > 3) XYpic - I think this is gong to prove very very useful 
> >    once I figure out how to use it properly - it seems like
> >    it might potentially allow inclusion of graphs directly 
> >    into pamphlet files and not as graphical files, among 
> >    other features - I think it will also allow hyperlinking
> >    nodes of graphs to code, although I'm still trying to 
> >    come up with a scheme for layout of such a graph which 
> >    looks reasonable.  Unfortunately it is GPL so we can't 
> >    include it in axiom.sty, but tetex at least includes it 
> >    by default so I'm guessing it wouldn't be too much
> >    trouble.  Maybe we could contact the authors and ask if 
> >    it becomes an issue.
> 
> we certainly need two kinds of environments, 
> 
> one for pictures. i've tried several and they "sort of" work
> but the pictures float all over the place and i've never 
> succeeded in getting two pictures separated by text on the 
> same page. this is still an outstanding problem with the 
> book.pamphlet file. gotta solve it someday.
> the book.pamphlet uses 'GRAPHICX'

I forget which one I used for Maximabook.  I'll have to check.  Images
are a problem - I'm afraid the only way I ever found to get reasonable
image quality in pdfs with Maximabook was to use uncompressed pngs,
which eat space and make for large pdf files.  But then space is cheap
nowadays...

> one for diagrams. i use a package called PSTRICKS in the
> src/doc/endpaper.pamphlet that did the job reasonably well but 
> i'm open to other suggestions. we could test competing packages
> against rewritten versions of the endpaper pamphlet.

Yes, I saw PSTRICKS - it looks very interesting (I particularly like
the 3d plotting module) but I don't know how it does with pdf output. 
And I don't think it is capable of the hyperlinked diagram I did with
XYpic.

Maybe the advanced PSTRICKS routines could be converted to using XYpic
as a backend?


> i'm DEEPLY opposed to conditional branching in tex documents. 
> even if there is one good use i assure you some bright spot
> down the line will figure out a way to conditionally build 
> algebra documents based on half-a-thousand switches. and if 
> something gets skipped it is hard to recognize that something 
> that "should" be there isn't.

OK.  But that still leaves us with the problem of how to handle
necessary options for pdf vs. dvi.  TeTeX 3.0 and up seem to insist on
making a pdf if the options to hyperref include pdf specific options,
which is why I had to use the ifthen package for hyperref.

I don't mind doing it "differently" I just need to know how to maintain
the functionality while doing so :-).  Unfortunately I'm not really all
that good with LaTeX yet.

> fundamentally the goal of a literate document is to 
> communicate  with people, most of whom are reading the 
> document because they want to learn and understand the 
> material. making a document that has conditions they need to 
> choose up front means that they know what they want.

In this case, pdf vs. dvi is the main choice.  (margins are mainly
suger for developers doing lots of repeated printing.)  That's one they
can't get out of, although I suspect most users will have little
interest in the dvi format, particularly on Windows where I know of no
good free viewer.

> i'd rather put all the conditionalization into the build 
> process before latex runs and keep the documents non-branching.

OK, but as I mentioned TeTeX 3.0 is going to conditionalize its output
based on options to hyperref, so any pdf specific options (which I
would think we would want) are going to cause problems.  If we want to
define local.sty files and have them used by make to configure the
documents as needed on the fly that works for me, if it can be done.

\start
Date: Tue, 29 Nov 2005 22:37:19 -0500
From: Tim Daly
To: Cliff Yapp
Subject: re: article "standard" header/footer

> > it would be cool to take the src/doc/endpapers.pamphlet and 
> > make it display well on MathAction with hyperref links to the
> > algebra.
> 
> Hmm :-).  For the inattentive among us, what is endpapers.pamphlet
> again?

the old axiom hardcover book has two diagrams on the inside
covers of the book, one of the algebra and one of the data structures.
i reproduced those diagrams and put them in src/doc/endpaper.pamphlet
i think it would be cool to hyperlink those diagrams to the related
algebra code. it might make a good wiki page.

\start
Date: Tue, 29 Nov 2005 23:00:22 -0500
From: Tim Daly
To: Cliff Yapp
Subject: re: article "standard" header/footer

> > i'm DEEPLY opposed to conditional branching in tex documents. 
> > even if there is one good use i assure you some bright spot
> > down the line will figure out a way to conditionally build 
> > algebra documents based on half-a-thousand switches. and if 
> > something gets skipped it is hard to recognize that something 
> > that "should" be there isn't.
> 
> OK.  But that still leaves us with the problem of how to handle
> necessary options for pdf vs. dvi.  TeTeX 3.0 and up seem to insist on
> making a pdf if the options to hyperref include pdf specific options,
> which is why I had to use the ifthen package for hyperref.

can you give me an example to play with?
i've never seen latex output a pdf. always a dvi.
this must be new behavior.

\start
Date: Tue, 29 Nov 2005 20:04:14 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: re: article "standard" header/footer

--- Tim Daly wrote:

> > > i'm DEEPLY opposed to conditional branching in tex 
> > > documents. 
> > > even if there is one good use i assure you some bright spot
> > > down the line will figure out a way to conditionally build 
> > > algebra documents based on half-a-thousand switches. and 
> > > if something gets skipped it is hard to recognize that 
> > > something  that "should" be there isn't.
> > 
> > OK.  But that still leaves us with the problem of how to 
> > handle necessary options for pdf vs. dvi.  TeTeX 3.0 and up 
> > seem to insist on making a pdf if the options to hyperref 
> > include pdf specific options, which is why I had to use the
> > ifthen package for hyperref.
> 
> can you give me an example to play with?

The axiomunits tex file will demonstrate this behavior, given the
proper version of tetex - just uncomment the command that sets makepdf
to true and run latex axiomunits_v2.tex to get a pdf.  All that does is
select for the hyperref command with pdf specific options, and that's
enough to trigger pdf output.  At least, that's the behavior I'm
seeing.  I've seen other comments in the Gentoo forums, so I'm not the
only one caught by surprise on this one.

> i've never seen latex output a pdf. always a dvi.
> this must be new behavior.

I believe it is.  This thread is another instance of someone seeing
this behavior:

http://forums.gentoo.org/viewtopic-t-345681-highlight-dvi+pdf+latex.html

I have tested this, and the new behavior seems to be to produce pdf
only if any of the options in the document are pdf specific.

\start
Date: Tue, 29 Nov 2005 20:21:05 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: breqn

--- Tim Daly wrote:

> > I got a bit fancy and allowed automatic resizing of a 
> > couple of large equations based on the two margin sizes, 
> > but breqn would be a preferable solution there if the 
> > license is ever straightened out.  (Or we implement our own
> > version of it.)
> 
> if breqn is an equation line breaker we have one of those.
> bill is the keeper of the latest set of changes i believe.

breqn is a line breaker, but for TeX rather than ascii.  Can Axiom
produce TeX mathematical output that is broken up over lines?  I'm not
even sure how it would know how to do so without knowing the rendering
environment.

An example of breqn is the Maximabook page 45, where the output of a
command is on two lines.  Maximabook can be obtained here:
http://maxima.sourceforge.net/docs/maximabook/maximabook-19-Sept-2004.pdf

I should read over the breqn docs - I've used it but I don't know much
about it.  Dr. Fateman seems to consider it fairly trivial compared to
the general problem of line breaking mathematics (which is true) but
for a lot of VERY common cases it does what is needed.

(I'm on the whole pleased with Maximabook even though it never did take
off - it was an excellent way to learn the basics of LaTeX and I think
the result looks very nice.  The included Maxima sessions are due to
the tremendous work by Jay on the EMaxima environment.  I hope Axiom
will be able to build off of the general ideas there to make an Axiom
specific EAxiom environment someday (clearly pamphlet files add an
extra dimension, and the IO issues involved are also a bit tricky). 
For writing papers with CAS math included EMaxima was the best
environment I have come across, and probably a lot of its abilities
could map usefully into pamphlet editing too - imagine, for example,
editing a pamphlet and being able to execute code blocks in a
background Axiom environment, and test the results as part of writing
the pamphlet file.  Similar to MathAction ideas but for Emacs, which as
an old fogie I find more comfortable as an editing/authoring
environment than a web browser for anything non-trivial.)

\start
Date: Tue, 29 Nov 2005 20:23:41 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: Re: breqn

Perhaps I should clarify that breqn is not a standalone program but a
LaTeX package. \usepackage{breqn} is how you include it, IIRC.  If
Axiom removes the need for it I would be very very interested to see
this - otherwise, given our preference for large margins I think we
should look more deeply into breqn.

\start
Date: Tue, 29 Nov 2005 23:24:05 -0500
From: Bill Page
To: Tim Daly, Cliff Yapp
Subject: RE: Units and Dimensions - example pdf and dvi files

On Tuesday, November 29, 2005 9:56 PM Tim Daly (root) wrote:
>
> > I got a bit fancy and allowed automatic resizing of a
> > couple of large equations based on the two margin sizes,
> > but breqn would be a preferable solution there if the
> > license is ever straightened out.  (Or we implement our
> > own version of it.)

What is the issue of the license for breqn?

>
> if breqn is an equation line breaker we have one of those.
> bill is the keeper of the latest set of changes i believe.
>

breqn is written in LaTeX (TeX?), i.e. it is a LaTeX-only
solution.

The line breaker code (written by Robert Sutor - one of the
original Axiom developers) that we use with Axiom on both
MathAction and in the Windows version of the TeXmacs interface
is written in C.  The original version was run as a filter
but I adapater it slightly to be called as a subroutine. It
accepts a few parameters, one of which is the desired line
size.

\start
Date: Tue, 29 Nov 2005 20:36:39 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Tim Daly
Subject: RE: Units and Dimensions - example pdf and dvi files

--- Bill Page wrote:

>  
> On Tuesday, November 29, 2005 9:56 PM Tim Daly (root) wrote:
> > 
> > > I got a bit fancy and allowed automatic resizing of a 
> > > couple of large equations based on the two margin sizes,
> > > but breqn would be a preferable solution there if the
> > > license is ever straightened out.  (Or we implement our
> > > own version of it.)
> 
> What is the issue of the license for breqn?

Simply put, there is none.  So no one knows what its license terms are.
 People use it but technically the situation is unclear.  I can give a
little more background but if we get into that we should shift over to
axiom-legal.

Also, the current 0.94 release is technically a beta - the author has a
note that some issues still need work.

> > if breqn is an equation line breaker we have one of those.
> > bill is the keeper of the latest set of changes i believe.
> > 
> 
> breqn is written in LaTeX (TeX?), i.e. it is a LaTeX-only
> solution.

Right.

> The line breaker code (written by Robert Sutor - one of the
> original Axiom developers) that we use with Axiom on both
> MathAction and in the Windows version of the TeXmacs interface
> is written in C.  The original version was run as a filter
> but I adapater it slightly to be called as a subroutine. It
> accepts a few parameters, one of which is the desired line
> size.

The problem is how do we know what the size of an equation is relative
to our page size in the output until we render it?

The general solution to this problem is actually an interesting
research problem, as well as an immense challenge. :-).

\start
Date: Tue, 29 Nov 2005 23:47:04 -0500
From: Bill Page
To: Cliff Yapp, Tim Daly
Subject: RE: Units and Dimensions - example pdf and dvi files

On Tuesday, November 29, 2005 11:37 PM C Y wrote:
> ...
> > The line breaker code (written by Robert Sutor - one of the
> > original Axiom developers) that we use with Axiom on both
> > MathAction and in the Windows version of the TeXmacs interface
> > is written in C.  The original version was run as a filter
> > but I adapted it slightly to be called as a subroutine. It
> > accepts a few parameters, one of which is the desired line
> > size.
>
> The problem is how do we know what the size of an equation is
> relative to our page size in the output until we render it?

We just say we want an equation that is 4.5 inches wide and
the algorithm tries really hard to make it that size by
converting the equation into an eqnarry, based on a set of
heuristics like preferentially breaking on a + in a sum
etc. I a few other heuristics involving how to break a
product and how to handle functions etc.

But in some cases it will fail to achieve the desired size.
You can see the effect of this on some pages in MathAction.

>
> The general solution to this problem is actually an
> interesting research problem, as well as an immense
> challenge. :-).
>

If you can read old-fashioned C program code, then I think you
should take a look at this. It seems to me that Robert Sutor
more or less solved this "research problem" about 15 years
ago. :) Seriously, if you are interested and know C, then
there are a few things like I would like to do to improve
the algorithm... but it is not much fun doing it all on my
own. At the moment it is not in the form a pamphlet file
and has very little documentation in the code. But if anyone
wants to work on this, I would be glad to set it up in the
form of a pamphlet on MathAction.

\start
Date: Wed, 30 Nov 2005 00:00:30 -0500
From: Bill Page
To: Cliff Yapp, Tim Daly
Subject: re: article "standard" header/footer

On Tuesday, November 29, 2005 11:04 PM C Y wrote:
>...
> Tim Daly (root) wrote:
> > i've never seen latex output a pdf. always a dvi.
> > this must be new behavior.
>
> I believe it is.  This thread is another instance of someone seeing
> this behavior:
>
>
http://forums.gentoo.org/viewtopic-t-345681-highlight-dvi+pdf+latex.html
>
> I have tested this, and the new behavior seems to be to produce pdf
> only if any of the options in the document are pdf specific.
>

It seems to me that you must be using 'pdfeTeX' which is a
variant of the standard tetex distributed with most linux
systems.

We have this version installed on the axiom-developer.org
server:

% latex -v
pdfeTeX 3.141592-1.21a-2.2 (Web2C 7.5.4)

-------

'pdfeTeX' will generate both dvi and pdf output.

I tried this in a few cases to generate pdf output for the
MathAction implementation of pamphlets but in the end I opted
to use the more conventional approach of 'dvipdfm' which
generates the pdf file from the dvi file. Like this:

  *.tex ----> Latex ----> *.dvi ---> dvipdfm ----> *.pdf

As long as you specific the 'dvipdfm' option as a hyperref
parameter, then this seems to produce good results with
hyperlinks and other hyperref extensions. You can see a few
examples of this in the Axiom source files on MathAction.

\start
Date: Wed, 30 Nov 2005 00:25:38 -0500
From: Bill Page
To: Cliff Yapp, Tim Daly
Subject: Re: article "standard" header/footer

On Tuesday, November 29, 2005 9:34 PM C Y wrote:
>
> Tim Daly (root) wrote:
> > ...
> > (a) the code isn't linear,
> > (b) we eventually want it all available in a browser frontend
> >     and
> > (c) a way to use this in graphs would give us a good "map"
> >     ability
>
> As you can see in the Units file, XYpic enables (c).  Not all
> the links are active in that version, but it was 2am and I was
> tired ;-).
>
> > it would be cool to take the src/doc/endpapers.pamphlet and
> > make it display well on MathAction with hyperref links to the
> > algebra.
>

GraphViz is already available on MathAction.

http://wiki.axiom-developer.org/GraphViz

So far I have not figured out how to do links but his site

http://www.wickle.com/wikis/index.php/Graphviz_extension#More_Sample_wit
h_links

does have an implementation of GraphViz in a wiki that does do
links. So in principle adapting this to MathAction should not
be that difficult.

\start
Date: Wed, 30 Nov 2005 02:22:45 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: Units and Dimensions - example pdf and dvi files

All of the versions of latex I've tried on axiomunit_v2.tex
blow up on the \pdfoutput=1. bad karma has come to haunt me.

rather than trying to generate pdf files in latex i'd suggest
using latex to gen a .dvi file and then use dvipdfm or dvi2pdf.
dvi2pdf is a shell script that reads:

dvips -e 0 -Z -X 600 -Y 600 -D 600 -f <`basename $1 .dvi`.dvi >`basename $1 .dvi`.ps
gs -r600x600 -q -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=`basename $1 .dvi`.pdf `basename $1 .dvi`.ps -c quit

which works every time if you have the fonts.

\start
Date: Wed, 30 Nov 2005 02:31:44 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomInterpreter] 

The Axiom interpret is the part of Axiom responsible for handling
user input during an interactive session.

The interpreter parses the users input expression to create an
expression tree, then does a bottom-up evaluation of the tree.
Each subtree encountered that is not a value consists of a root
node denoting an operation name and one or more leaf nodes
denoting operands. The interpreter resolves type mismatches
and uses type-inferencing and a library database to determine
appropriate types for the operands and the result, and the
operation to be performed.

The interpreter determines the domain in which to perform the
indicated operation, and invokes a function from the domain to
compute a value. The subtree is then replaced by that value and
the process continues. Once the entire tree has been processed,
the value replacing the top node of the tree is displayed back
to the user as the value of the expression.

Input to the interpreter may be read from a file using the
command::

  )read filename.input

\start
Date: Wed, 30 Nov 2005 01:13:08 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: re: article "standard" header/footer

> For what it's worth, I would estimate I'll eventually ask to have the
> following available, since they are very standard and too big to reall

> 1) hyperref (which I see you've already decided to include)
> 2) bibtex (I'm working on an example based on the units work, but I
> will need to do some thinking before I have a good example ready)

Both hyperref an bibtex are so standard that it would be hard to exclude 
them.

> 3) XYpic - I think this is gong to prove very very useful once I figure
> out how to use it properly - it seems like it might potentially allow
> inclusion of graphs directly into pamphlet files and not as graphical
> files, among other features - I think it will also allow hyperlinking
> nodes of graphs to code, although I'm still trying to come up with a
> scheme for layout of such a graph which looks reasonable.

Hmmm... that package is capable of quite a lot. Though I am not sure 
that many people use it. On has to learn quite a lot. However, if we can 
figure out that that package does not conflict with other packages, I 
don't see a reason why not to include it.

> Unfortunately it is GPL so we can't include it in axiom.sty, but tetex
> at least includes it by default so I'm guessing it wouldn't be too much
> trouble.

I don't understand all this licensing troubles. We would just use it. To 
resolve all this trouble, Axiom could come in two archives, one that is 
BSD and the second one which is just an unmodified redistribution of the 
files it contains. Officially the BSD part is called Axiom, but it needs 
some basics software to be build.

If I understand the GPL correctly, then if I use xypic for a paper, I 
would have to distribute that paper under GPL.

Licenses (open or closed) are just existing because there are people who 
don't respect the work of others. The world is not ideal, but all these 
hundreds of different licenses make the world even worse. Sigh. Let's go 
on with the real work and be fair.

> ifthen and fontenc I'm willing to pass up, but I would like to know how
> we will handle:

Several other packages use "ifthen" implicitly, so it is quite hard not 
to depend on it.

> a)  different options to hyperref based on pdf or dvi creation

Check \pdfoutput in the style file.

> b)  line breaking of equations

Do you think this is necessary? I am not sure whether I would like a 
program to decide how to format an equation.

> c)  specifying different sizes, fonts, etc for text.  This is probably
> just my ignorance of LaTeX

Just have a standard size and define a style hook to modify the sizes.

\start
Date: Tue, 29 Nov 2005 23:48:46 +0100
From: Ralf Hemmecke
To: Eitan Gurari
Subject: ALLPROSE and tex4ht

Hello,

just for the record... I partially succeded to htlmify ALLPROSE by using 
tex4ht. See http://www.hemmecke.de/aldor for what I currently achieved.
Eitan, thank you for your tex4ht work.

I had to switch off the "framed" and "srcltx" packages and just don't 
modify the standard "verbatim" package.

srcltx is not needed anyway.

verbatim is not a big problem. The font is just not as small as in the 
dvi file.

framed is for a colored backgrounds. That can certainly achieved in some 
other way. Eitan, do you know how I could achieve it.

Eitan, I also would like to know how exactly do I switch of these 
packages via an allprose.4ht config file. Can you give some hints or 
references to some documentation?

It' is very strange for me that I could not use "\maketitle" together 
with tex4ht. Eitan, why doesn't this work?

If you look at Section 25.7.1 (item 3) you will realize that the tex4ht 
output indents too much after a code chunk. Looks like a bug to me. The 
HTML is not correct.

I don't know why the index does not provide hyperlinks :-(

Hope, you like it, though.

\start
Date: Wed, 30 Nov 2005 10:27:14 +0100
From: Ralf Hemmecke
To: Eitan Gurari
Subject: ALLPROSE and tex4ht

Oh sorry guys,

The link is

http://www.hemmecke.de/aldor/allprose

I have not linked this page from http://www.hemmecke.de/aldor. I will 
only do so if it's a bit more colourful and completely integrated into 
the makefiles.

\start
Date: 30 Nov 2005 10:44:50 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: LaTeX preamble

Dear Ralf, *

I think that it is not a good idea to fix the set of packages allowed. Just an
example: suppose I wanted to write a package dealing with young tableaux -
quite probable, in fact. Then almost certainly I'll use the youngtab
package. But would you have thought of this now already?

So I'd propose to allow that a list of packages and options can be passed to ALLPROSE. 

Of course this raises yet another problem: some packages are not compatible
with each other. So maybe we should leave it to the authors that contribute to
the Axiom source that the latex compiles proberly, and simply leave allprose as
it is -- and if a new package is needed, he needs to add it to the list of
packages ALLPROSE includes...

\start
Date: Wed, 30 Nov 2005 04:47:30 -0500
From: Bill Page
To: Freek Wiedijk
Subject: upate: 12. Axiom

The entry for Axiom at:

http://www.cs.ru.nl/~freek/digimath/index.html

is no longer correct. Please update it as follows:

12. Axiom
    Web Page: http://www.axiom-developer.org
    E-Mail: Tim Daly
    Architect: IBM, NAG, others, open source
    Language: Lisp, C
    Category: Computer Algebra
    Interaction: Dialog, Batch Logic: Classical, Size: Large

\start
Date: Wed, 30 Nov 2005 10:49:41 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: article "standard" header/footer

Hi Tim,

root wrote:
>> Maybe you don't like it, but I use a slightly different approach in 
>> ALLPROSE. What comes out as defn and use in your case comes out in red 
>> and blue color in the index in ALLPROSE. And you would simply say:
>> \defineterm{foo} and \useterm{foo}. Read the description of 
>> rhxterm.sty.nw on http://www.hemmecke.de/aldor. It even hyperlinks the 
>> foo in \useterm to the foo in \defineterm, not just putting something 
>> into the index.

> ummm, i'm partially colorblind to red and green :-)

Haven't you seen? The colors are an additional option. Standard in 
ALLPROSE is black/white. If you like to have your favourate colors, put 
them into a Makefile rule in "Makefile.def.nw" and be happy.
http://www.hemmecke.de/aldor/allprose/#dt:colored
Chunk from "Makefile.def.nw".
%CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
<<local customization of documentation styles>>=
colored:
	@echo '\usepackage{color}' >> local.sty
	@echo '\def\cbx{\colorbox[rgb]}' >> local.sty
	@echo '\def\tcx{\textcolor[rgb]}' >> local.sty
	@echo '\def\defineTermStyle{\textcolor{red}}'>> local.sty
	@echo '\def\useTermStyle{\textcolor{blue}}'>> local.sty
@ %def colored
%$
%TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

> the \defineterm and \useterm are perfect examples of axiom.sty commands.
> they should be used everywhere. being lazy i didn't write a \newcommand
> to do this but just do it inline. but it's a good idea.

rhxterm.sty is actually not part of ALLPROSE, because it is more general 
and I also use it for other purposes. You could just use it for axiom. 
It is a noweb file anyway. But please don't put it into a bigger .sty 
file. I maintain rhxterm.sty, but I don't like to do work twice because 
the Axiom branch is out of sync.

\start
Date: Wed, 30 Nov 2005 11:05:11 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: article "standard" header/footer

No, look at ALLPROSE. There is an index and I don't say \input{blah.ind}.

Let's look at the definitions of \printindex in makeidx.sty.

\newcommand\printindex{\@input@{\jobname.ind}}

It builds on

\def\@input@#1{\InputIfFileExists{#1}{}{\typeout{No file #1.}}}

from the standard latex.ltx.

You see?

Ralf

root wrote:
>> By the way, you need "dummyindex" because you have 
>> \input{${PROJECT}.ind} below. \printindex is enough.
>>
>>> \eject
>>> \begin{thebibliography}{99}
>>> \bibitem{1} nothing
>>> \end{thebibliography}
>>> <<dummyindex>>=
>>> \begin{theindex}
>>>  \item none
>>> \end{theindex}
>>> \printindex
>>> \input{${PROJECT}.ind}
>>> \end{document}
> 
> on my system latex blows up on the \input if project.ind does not exist.
> the first time you build a pamphlet project.ind does not exist.
> so you have to make sure it exists (hence dummyindex).
> i suppose if i were thinking ahead i could have just done 'touch foo.ind'.
> sigh. hindsight is good stuff.

\start
Date: Wed, 30 Nov 2005 06:09:33 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: article "standard" header/footer

yep. got it. 'twas a misunderstanding on my part. -- t

\start
Date: Wed, 30 Nov 2005 11:00:16 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: article "standard" header/footer

root wrote:
>> For the .dvi generation I rather like to write a script so that the 
>> inverse search becomes available.
> 
> this comment is lost on me.
> please explain in detail.

Oh, sorry, what I had in mind is a bit like in ALLPROSE. For development 
(not the final things) just produce a file with all the filenames that 
you are currently interested in. Run a script on them and thus produce a 
.dvi file that you can click and jump to the corresponding .pamphlet 
file. That is similar to this preliminary work of integrating "inverse 
search" into the Axiom world. That was a personal mail to you on Nov 23.
If you like, I can resend it.

\start
Date: Wed, 30 Nov 2005 12:21:58 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: LaTeX preamble

Martin Rubey wrote:
> Dear Ralf, *
> 
> I think that it is not a good idea to fix the set of packages allowed. Just an
> example: suppose I wanted to write a package dealing with young tableaux -
> quite probable, in fact. Then almost certainly I'll use the youngtab
> package. But would you have thought of this now already?

Alright. Clifford mentioned some chemistry packages etc. There are a lot 
of packages around that we simply cannot all put into a common header.

My suggestion would be the following. Split Axiom into Algebra and the 
underlying stuff. For the underlying things I have the impression, we 
could agree on a common preample. And, in fact, it would be a good idea 
to do so, since it is a lot of code to be maintained.

As for Algebra... that is where most (if not all) of the mathematics is.
There are again two parts.
1) The current code.
2) Future code that comes from contributions of other people around the 
world.

Fixing a preample for 1) could be done. But my vision is somewhat 
different. The Algebra documentation should be something like a 
"collection" of articles, that are hyperlinked together but retain a 
certain layered structure. So the articles build up some kind of hierarchy.

I also don't think we can achieve ONE common agreement on the hierarchy 
of domains and categories. We could be close to mathematics, but it 
would not be one-to-one. The language simply imposes some restrictions.

Take for example Ring. That is a Semigroup with respect to 
multiplication and a Group with respect to addition. Wrong! It's an 
AbelianGroup with respect to addition and in Axiom an AbelianGroup is 
not a Group. :-( There is simply no language feature to rename 
operations. Well, that is a other topic...

You should see ALLPROSE in this like light. Several articles(=libraries) 
that build on top of each other and extend Axiom step by step and may at 
some point in time be integrated into Axiom.

Since that is going to be bigger and bigger, I thought already about a 
way to combine two (or more) ALLPROSE projects. Unfortunately, I have 
not succeeded yet, but there is a package "combine" which could probably 
help me here. But I have still a little design problem. I want 
references from one article which refers to a domain in some other 
article (library) to become hyperlinks if both articles are combined. If 
there were no additional value, we could simply leave the articles 
separate and just document how they relate in another article. (The 
latter should be done anyway.)

> So I'd propose to allow that a list of packages and options can be passed to ALLPROSE. 

ALLPROSE allows you to add any package you like. Just write a file 
PROJECTNAME.sty.nw and put the things there. It will all come into the 
preample.

> Of course this raises yet another problem: some packages are not compatible
> with each other. So maybe we should leave it to the authors that contribute to
> the Axiom source that the latex compiles proberly, and simply leave allprose as
> it is -- and if a new package is needed, he needs to add it to the list of
> packages ALLPROSE includes...

As Tim said, the packages that are used by some article should be 
distributed with the article. The problem is that one has to read the 
licenses of those packages in order to know what one is allowed to do.

I think an important thing is to state in the article what version of 
the LaTeX package has been used by the author. Some packages are not 
compatible with earlier versions. I would at most require packages to be 
included, if they cannot be found on CTAN (http://www.ctan.org/).

Any, the rationale is:
A) fix the preample for every book-volume and the corresponding files
    except ALGEBRA.
B) allow any style for Algebra contributions (but still no
    \documentclass{..} ... \begin{document} ... \end{document}
    wrapper---separate style from contents).

\start
Date: Wed, 30 Nov 2005 05:35:41 -0600
From: MathAction (billpage)
To: MathAction
Subject: [FAQ] (new) 

Frequently Asked Questions

  You've got quesitions? We've got answers ... *:)*

- Please review the list of [Common Mistakes] and the list
  of [MathAction Problems] if you are have never used
  MathAction before.

- If you are learning to use Axiom and think that someone
  must have solved some particular problem before you,
  check this list of Common [Axiom Problems].

- The [Issue Tracker] list includes detailed problem reports
  and solutions group by category and status.

- "Search":http://wiki.axiom-developer.org/FrontPage/searchwiki
  for relevant pages on this web site based on keywords from
  the text. Enter keywords in the box at the upper right and
  press 'Enter'.

Finally, if you can not find the answer to your questions here,
then please send an email to:

"axiom-mail@nongnu.org":mailto:axiom-mail@nongnu.org --
for general questions about using Axiom or
search http://lists.nongnu.org/mailman/listinfo/axiom-mail

"axiom-math@nongnu.org":mailto:axiom-math@nongnu.org --
for questions of a mathematical nature or
search http://lists.nongnu.org/mailman/listinfo/axiom-math

"list":mailto:list --
for technical questions about Axiom development and programming
search http://lists.nongnu.org/mailman/listinfo/axiom-developer

\start
Date: Wed, 30 Nov 2005 05:53:04 -0600
From: MathAction (billpage)
To: MathAction
Subject: [WishList] 

  The idea that one should be able to "declare the type" of a
  variable in Axiom is a frequent expectation of new users of Axiom.
  For example, if we know that 'x' and 'y' are Integers than surely
  the symbolic expression 'x+y' must represent an Integer? But this
  is not (quite) what is meant by type in Axiom.

  For more discussion of this issue see the page [Indefinite Types]

\start
Date: Wed, 30 Nov 2005 05:56:28 -0600
From: MathAction (billpage)
To: MathAction
Subject: [Indefinite Types] (new) 

Declaring Types
 
  The idea that one should be able to "declare the type" of a
variable in Axiom by the command
\begin{axiom}
n:PositiveInteger
\end{axiom}

is a frequent expectation of new users of Axiom - especially if one
has used other computer algebra systems, after all Axiom is supposed
to be a "strongly typed" system, right?

Unfortunately Axiom does not attempt to use this type information
when forming expressions - but worse - declaring the type actually
interferes with the use of the variable to form expressions!
\begin{axiom}
n+1
\end{axiom}

When you write 'n:PositiveInteger' what this tells Axiom is that
'n' will be assigned an integer value greater than 0 - only that.
After it is actually assigned some value, then it can be used
exactly like that value, but not before.

To me, this is a tremedous waste of an opportunity in Axiom to
to deal with "domain of computation" issues such as are
addressed in other untyped computer algebra systems by the use
of "assumptions" such as::

  assume(x,PositiveInteger);

Such knowledge can be used to considerably improve the quality
and generality of the computations.

There was plenty of discussion on axiom-developer, but no
concensus yet, I'm afraid. Here are some of the related threads:

-  http://lists.gnu.org/archive/html/axiom-developer/2004-06/msg00191.html

-  http://lists.gnu.org/archive/html/axiom-developer/2004-06/msg00212.html

\start
Date: Wed, 30 Nov 2005 08:34:37 -0500
From: Eitan Gurari
To: Ralf Hemmecke
Subject: ALLPROSE and tex4ht

Ralf,

I rather not have the "framed" and "srcltx" packages switched off, if
there present is natural for the dvi environment.  I think tex4ht
should be configured to support those packages if they are integral
part of the code.  It is not an option for tex4ht to switch them off
as it kicks in after all the *sty files are loaded.

The .log file might give a hint on how makeindex is to be invoked.  If
that is not the case, tex4ht will need to be configured to an
apparently a new definition of the index.

I'll get back to you before the end of December.  I'm currently
overloaded with commitments and deadlines and can't currently deal
with the axiom and aldor stuff.

 > I had to switch off the "framed" and "srcltx" packages and just don't 
 > modify the standard "verbatim" package.
 > 
 > srcltx is not needed anyway.
 > 
 > verbatim is not a big problem. The font is just not as small as in the 
 > dvi file.
 > 
 > framed is for a colored backgrounds. That can certainly achieved in some 
 > other way. Eitan, do you know how I could achieve it.
 > 
 > Eitan, I also would like to know how exactly do I switch of these 
 > packages via an allprose.4ht config file. Can you give some hints or 
 > references to some documentation?
 > 
 > It' is very strange for me that I could not use "\maketitle" together 
 > with tex4ht. Eitan, why doesn't this work?
 > 
 > If you look at Section 25.7.1 (item 3) you will realize that the tex4ht 
 > output indents too much after a code chunk. Looks like a bug to me. The 
 > HTML is not correct.
 > 
 > I don't know why the index does not provide hyperlinks :-(

\start
Date: Wed, 30 Nov 2005 08:53:38 -0800 (PST)
From: Cliff Yapp
To: list
Subject: image placement idea

Tim, you had mentioned earlier difficulty with image placement in
LaTeX.  There are some options to the figure command which might help:

http://www.starlink.rl.ac.uk/star/docs/sun9.htx/node21.html

And if you're using floats this might be of interest:

http://www.tug.org/tex-archive/help/Catalogue/entries/placeins.html

\start
Date: Wed, 30 Nov 2005 13:29:04 -0600
From: Jay Belanger
To: Cliff Yapp
Subject: Re: breqn

Cliff Yapp writes:

> breqn is a line breaker, but for TeX rather than ascii.  Can Axiom
> produce TeX mathematical output that is broken up over lines?  I'm not
> even sure how it would know how to do so without knowing the rendering
> environment.

I agree; where the output should be broken up depends on too many
other things besides the actual equation.

> I should read over the breqn docs - I've used it but I don't know much
> about it.  Dr. Fateman seems to consider it fairly trivial compared to
> the general problem of line breaking mathematics (which is true) but
> for a lot of VERY common cases it does what is needed.

It can't be perfect, but it does seem to work pretty well in most
cases.  I haven't heard of anyone working on it since Michael
Downes; too bad.

> I hope Axiom will be able to build off of the general ideas there to
> make an Axiom specific EAxiom environment someday (clearly pamphlet
> files add an extra dimension, and the IO issues involved are also a
> bit tricky).

I said I'd have some sort of EAxiom to send you a while ago; obviously
I don't.  Sorry!  Right now I'm in the middle of writing my portfolio;
I should be finished with that early next week.  Soon after I expect
to devote a lot of time to Axiom, starting with EAxiom.  I promise to
send something in December.

\start
Date: Wed, 30 Nov 2005 14:32:04 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Website down?

On Monday, November 28, 2005 1:22 PM I wrote:
>
> On November 28, 2005 12:05 PM C Y asked:
> >
> > Anybody else getting a HTTP 500 - Internal server error?
> >
>
> It's working for me right now. I have not re-set and or changed
> anything since last night (about 10:00 pm Eastern Time. I have
> noticed that occasionally I get very poor response times (20 or
> 30 seconds per page). I am beginning to think that there might be
> intermittent problems at the ISP where we run axiom-developer.org.

Looking at the process statistics on the server on Monday and
Tuesday, is seemed that we were getting only about 10% to 15% of
the total CPU capacity of this dual-processor shared virtual
server. The system was spending a lot of time waiting for disk
access and also "idle" but I am not sure exactly how to interpret
these statistics in the case of a shared server - the total
utilization is 100% for each CPU including the idle time. But
perhaps "idle" means that it is serving some other virtual server
on the same machine? In any case performance was definitely
much less that we have been used to in the past.

>
> The other possibility is that the once in a while the access
> rates to the server exceeds it's capacity to respond in time.
> This could especially be the case for Zope application server
> which is known to require significant system recourses compared
> to more conventional web server software. There are some things
> that can sometimes be done to "tune" Zope performance and I will
> look into that some more later today.
>

Since this took some significant effort to do, I thought I would
take the time to explain a little even though this is rather off-
topic for the axiom-developer email list... :) None of what follows
is about Axiom or mathematics, if you are not interested in web
site performance, you can stop reading now.

--------

"Out-of-the-box" Zope runs as a combined database and web server.
The configuration on axiom-developer.org looks something like
this:

                      You
                      /|\
                       |
                    Internet
                      /|\
                       |
               Web cache server (squid?) <----> memory
                      /|\
                       |
               Front-end server (apache) <----- files
                      /|\                  (3)
                       |    (1)
axiom <--->  Application/db server (zope)  <----> memory
                      /|\                   (2)            
                       |
                 Zope File System

(1) My first step in optimization was to ensure that all static
web pages and parts of web pages (e.g. style files) that did not
change are marked as cacheable by the zope. If they are properly
marked then the Web cache server (which is actually part of the
ISP's local network and not on the axiom-developer server itself)
will keep a copy of these in memory for a fixed period of time
(usual 1 hour) and send them directly to the requester without
bothering our server. This is new.

(2) It is also possible to specify that certain frequently used
page templates and scripts are kept in memory for fast access.
In fact it only really affects one file but it is an important
one since it's contents occurs on every web page generated by
this system. This is also new.

(3) Some files such as the image.png files that represent LaTeX
equations in the browser can be accessed directly by the apache
web server. This is controlled by url re-write rules in the
apache configuration file. This is old. No changes here, we
have been doing this since the site was first made public over
a year ago. I just mention it for completeness.

Although these changes improved things some (maybe about a 5%
increase in CPU utilization), on Tuesday the server seemed
overloaded several times during the day. So I decided to make
one final big change to the configuration:

                    ...
                    /|\
                     |   (1)
axiom <--->  Application server (zope)  <----> memory
                    /|\                  (2)            
                     |
           (4) Database server (zeo)
                    /|\
                     |
               Zope File System

(4) The zeo server is an optional component of zope that is
usually only used in higher-performance cluster configurations
that involve more that one physical zope server. Zeo runs as
a separate process and in most cases on a separate physical
machine. It takes a bit of planning to set this up properly
and the documentation is a bit uneven in quality. Some notes
claim that this configuration is in fact more robust and easier
to administer than the simpler setup.

This configuration change is relevant for us even though we
have only one server because the axiom-developer.org server is
actually a dual symmetric multi-processor machine. This means
it can run two processes completely in parallel. By splitting
Zope into two processes: one that does the web page formatting
(application) and one that accesses the underlying database,
these two critical processes can run in parallel and as a
result make better use of the server resources.

The end result was about another 10% increase in CPU utilization.
It's now running between 30% to 35%. And so far this seems good
enough to keep ahead of the aggressive search engines that are
always scanning us plus those people who actually are trying to
run Axiom etc. But I still get the impression that we are running
near the limit of the capacity of this machine.

If anyone has any questions or suggestions I would be happy to
receive them. And of course if you continue to get server error
messages such the one above, please let me know.

\start
Date: Wed, 30 Nov 2005 15:40:00 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Website down?

Bill,

I'll check with my isp to see if they can host a server.

\start
Date: Wed, 30 Nov 2005 13:27:35 -0800 (PST)
From: Cliff Yapp
To: Jay Belanger
Subject: Re: breqn

--- Jay Belanger wrote:

> 
> Cliff Yapp writes:
> 
> > breqn is a line breaker, but for TeX rather than ascii.  
> > Can Axiom produce TeX mathematical output that is broken up
> > over lines?  I'm not even sure how it would know how to do
> > so without knowing the rendering environment.
> 
> I agree; where the output should be broken up depends on too 
> many other things besides the actual equation.

Eventually, I hope to have a GUI interface where we can really start to
work on this problem - by then the STIX fonts will be available, and
with any luck we can focus on those fonts specifically for line
breaking concerns, since they are likely to become the dominate fonts
for mathematical expressions.  (That's assuming the fonts really live
up to their hype, but I'm hopeful they will.)

> > I should read over the breqn docs - I've used it but I 
> > don't know much about it.  Dr. Fateman seems to consider it
> > fairly trivial compared to the general problem of line 
> > breaking mathematics (which is true) but
> > for a lot of VERY common cases it does what is needed.
> 
> It can't be perfect, but it does seem to work pretty well in 
> most cases.  I haven't heard of anyone working on it since 
> Michael Downes; too bad.

I don't think anyone wants to work on it until the license is cleared
up, even assuming we've got people both interested and that skilled in
TeX.

If need be presumably we can implement the ideas in our own
axiom.breakequations.sty file, but that will be very, very nontrivial
:-/.

> > I hope Axiom will be able to build off of the general ideas
> > there to make an Axiom specific EAxiom environment someday 
> > (clearly pamphlet files add an extra dimension, and the IO 
> > issues involved are also a bit tricky).
> 
> I said I'd have some sort of EAxiom to send you a while ago;
> obviously I don't.  Sorry!

No worries - I'm rather behind myself.  I'm still writing the text for
the unit package, and have a ways to go even on that. (Arrrrgh. 
Must... finish... units... and... move... on... to errors...)

> Right now I'm in the middle of writing my portfolio;
> I should be finished with that early next week.  Soon after 
> I expect to devote a lot of time to Axiom, starting with 
> EAxiom.  I promise to send something in December.

Cool! :-).  With any luck, I'll be ready to start actual Axiom coding
about the time you need someone to test EAxiom :-).  Maximabook all
over again ;-).

Actually, I guess what I should do is write both the "pamphlet" file
and a more "normal" tutorial on units using included Axiom sessions,
depending on what features you want to put in EAxiom.  

Which actually leads me to another question.  Tim, what are your
feelings about including Axiom sessions in LaTeX documents ala the
maximabook?  Do you like the way it was done there or should it be
different?  Also, for more "user oriented" documentation that works
above the source code level, should that be part of the bookvol1? 
e.g., for new users I don't expect them to wade through the whole
UnitsandDimensions.pamphlet file to find out how to use units - I would
start with the most "user friendly" parts of the system that a
scientist would want to use, and probably finish up with the idea of
rulesets and a brief description of why they are needed.  For the
knock-down-drag-out discussion of units the user is referred to the
implementation documentation, but I doubt we want to start there.  Or
am I wrong?

\start
Date: Wed, 30 Nov 2005 15:41:08 -0600
From: Jay Belanger
To: Cliff Yapp
Subject: Re: breqn

Cliff Yapp writes:
...
>> It [breqn] can't be perfect, but it does seem to work pretty well in
>> most cases.  I haven't heard of anyone working on it since
>> Michael Downes; too bad.
>
> I don't think anyone wants to work on it until the license is cleared
> up, even assuming we've got people both interested and that skilled in
> TeX.

I was hoping someone at AMS would do some more work on it.

> If need be presumably we can implement the ideas in our own
> axiom.breakequations.sty file, but that will be very, very
> nontrivial :-/.

I suspect if we pushed the AMS hard enough, we could get breqn under a
fairly liberal license.

>> > I hope Axiom will be able to build off of the general ideas
>> > there to make an Axiom specific EAxiom environment someday
>> > (clearly pamphlet files add an extra dimension, and the IO
>> > issues involved are also a bit tricky).
>>
>> I said I'd have some sort of EAxiom to send you a while ago;
>> obviously I don't.  Sorry!
>
> No worries - I'm rather behind myself.  I'm still writing the text for
> the unit package, and have a ways to go even on that. (Arrrrgh.
> Must... finish... units... and... move... on... to errors...)

Speaking of non-trivialities, I didn't realize how much was involved
in researching a units package until I saw what you had done.  Nice
job so far!

\start
Date: Wed, 30 Nov 2005 14:10:48 -0800 (PST)
From: Cliff Yapp
To: Jay Belanger
Subject: Re: breqn

--- Jay Belanger wrote:

> 
> Cliff Yapp writes:
> ...
> >> It [breqn] can't be perfect, but it does seem to work 
> >> pretty well in most cases.  I haven't heard of anyone 
> >> working on it since Michael Downes; too bad.
> >
> > I don't think anyone wants to work on it until the license 
> > is cleared up, even assuming we've got people both 
> > interested and that skilled in TeX.
> 
> I was hoping someone at AMS would do some more work on it.

That's a point.  I wonder if it was an official project?

> > If need be presumably we can implement the ideas in our own
> > axiom.breakequations.sty file, but that will be very, very
> > nontrivial :-/.
> 
> I suspect if we pushed the AMS hard enough, we could get 
> breqn under a fairly liberal license.

Sounds like a plan.  Anybody know anyone in AMS to contact about the
issue?

> > No worries - I'm rather behind myself.  I'm still writing 
> > the text for the unit package, and have a ways to go even 
> > on that. (Arrrrgh. Must... finish... units... and... 
> > move... on... to errors...)
> 
> Speaking of non-trivialities, I didn't realize how much was 
> involved in researching a units package until I saw what you
> had done.  Nice job so far!

Thanks!  Hopefully I'm on the right track.  I think once I've gotten
the rest of the dimensional analysis algorithm written up I might be
able to start looking at actual code along with the text.  Reviewing
the other packages out there is probably going to be a bit of an
ongoing thing, although I will try and write a piece about the Maple
package RSN.  And I also want to give the sistyle package a try - if
that's as useful as I'm hoping it is I would like to expand Axiom's tex
abilities to output sistyle formatting for units.  

Heh - actually, that raises another point.  How should packages deal
with subject specific LaTeX?  Say, for example, that I want to use a
chemical formula style file for a chemical equations package, just like
I want to use sistyle for units.  How do I teach Axiom's TeX routines
new tricks?  Domain specific tex output?

\start
Date: Wed, 30 Nov 2005 18:17:34 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: breqn

> Heh - actually, that raises another point.  How should packages deal
> with subject specific LaTeX?  Say, for example, that I want to use a
> chemical formula style file for a chemical equations package, just like
> I want to use sistyle for units.  How do I teach Axiom's TeX routines
> new tricks?  Domain specific tex output?

I'd use whatever packages were available to get it to work. 

If we need to we can consider including packages used by axiom into to
zips directory which is where I've put other things that are external
to Axiom but hard to find. For a while it held a copy of the X11-devel
rpm, for instance. There have been numerous debates about this in the
past but my take on it is that we want axiom to build everywhere and
if we need to tar up a couple obscure programs to do that then that's
what we'll just have to do. Eventually either they become popular and
widely available or somebody remove the dependency. But a zips file
containing used .sty files is not unreasonable.

\start
Date: Wed, 30 Nov 2005 18:20:36 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Website down?

Tim,

I think there must be something seriously wrong with the
axiom-developer.org server. The performance is really very
unexpectedly poor. It used to be much better until two or
three weeks ago. I think that the change in performance is
very unlikely to have anything to do with the gradual increase
in the size of the web server database (currently about 350Mb.
plus the size of the image files).

I can not see anything specific after look at the performance
statistics for the last two days and trying everything I know
(and a few things I didn't) to make it faster.  The I/O wait
times and the system idle times both seem are very high. 'top'
also shows that the system has not been re-boot for more that
48 days. Maybe it would be a good idea to ask RoseHosting to
do full re-boot of the server and see if that has any
beneficial effect.

I don't know exactly how the virtual disk drive is configured
on this system, but perhaps the ISP could also tell us if they
have made any changes to the SAN environment or if there has
been a significant increase on the part of the other users of
this shared system.

Let me know what you find out about hosting a dedicated
server. I am willing to share some of the cost of such an
arrangement if necessary.

> -----Original Message-----
> Bill,
>
> I'll check with my isp to see if they can host a server.

\start
Date: Wed, 30 Nov 2005 20:16:17 -0500
From: Tim Daly
To: list
Subject: hear this...

http://www.itconversations.com/shows/detail169.html

download the MP3 and listen to it. great stuff.

\start
Date: Wed, 30 Nov 2005 22:23:35 -0500
From: Tim Daly
To: list
Subject: hear this...

to make life even easier (since otherwise it won't happen :-) )

http://www.itconversations.com/audio/download/ITConversations-169.mp3
http://www.itconversations.com/audio/download/ITConversations-662.mp3

\start
Date: Wed, 30 Nov 2005 23:39:02 -0500
From: Tim Daly
To: Robert Lefkowitz
Subject: Semasiology lecture
Cc: list

Robert,

I'm Tim Daly, the lead developer of the Axiom computer algebra
system which is open source, he said, with a grin.

Axiom was originally developed at IBM Research and I was one of
the original authors. IBM sold it to the Numerical Algorithms
Group (NAG) in 1992 and it was on the commercial market as a 
competitor to Mathematica and Maple. In 2001, NAG withdrew the
system and gave me the "source code" under the Modified BSD license.

Fifteen years had passed since I last saw my own code and I was
horrified to find that I no longer understood how it worked. 
Needless to say not one of the hundreds of files and millions
of lines of code had any comments.

Having pondered the problem for a while I spent a year restructuring
the system so that it no longer contains any Makefiles, lisp code,
C code, axiom algebra code or any naked source code at all. Virtually
every file in the system is now a latex document and everything is a
literate program. It is likely the largest literate program in the
world.

At the present time we're involved in rewriting all of the individual
literate files into book volumes. The system currently contains 10
volumes which are intended to contain the executable lines of code.

The realization is that we wrote the original system for the machine.
But computer algebra software is unique in that the integral of the
sine of x will still have the same value a hundred years from now.
If we want computer algebra (or any software) to survive for
a hundred years we need to write for people and not machines.


You have two lectures that I've just discovered

http://www.itconversations.com/audio/download/ITConversations-169.mp3
http://www.itconversations.com/audio/download/ITConversations-662.mp3

where you make this point clearly. I would like permission to include
these two MP3 files as part of the Axiom distribution. I should point
out that I'm asking more from respect than from legal obligation
although the second is still a motivation.

Hoping for a positive response, 




\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
