\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: Mon, 01 Aug 2005 04:20:53 -0500
From: MathAction (Themos Tsikas)
To: MathAction
Subject: [Axiom-mail] Re: input initialization file

Hello

In your axiom.input file add the line
 
)set message prompt frame

as the first line

You will see that the axiom.input definitions belong to the "initial" but you 
are offered a prompt belonging to a new frame. 

Give the command ")frame" to read about frames. To switch back to the frame 
that your axiom.input definitions are in, issue ")frame drop" interactively. 

What's happening is that AXIOMsys stays with the first "initial" frame but 
"axiom" starts a client process ("AXIOMsys" + "spadclient") for which 
AXIOMsys makes a new frame.

Best Regards
Themos Tsikas

PS. All this applies to the NAG version of axiom but it may well apply to the 
version you have.

\start
Date: Mon, 08 Aug 2005 02:46:55 -0500
From: MathAction (unknown)
To: MathAction
Subject: [GraphViz] dummy

\begin{latex}
\digraph[scale=0.5]{MyGraph1}{rankdir=LR; a->b; b->c}
\end{latex}

\start
Date: Mon, 08 Aug 2005 09:33:14 -0500
From: MathAction (unknown)
To: MathAction
Subject: [GraphViz] dummx

  \begin{latex}
  \digraph[scale=1.5]{MyGraph1}{rankdir=LR; a->b; b->c}
  \end{latex}

\start
Date: Mon, 8 Aug 2005 09:26:43 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Ideas for "next generation" CAS?

Hey Tim.  I recall some time back you mentioned some ideas you had for
a "proper" redesign of Axiom, incorporating proof systems and some
fundamental design philosophy considerations, among other things.  Is
there a summary of those thoughts somewhere?  I'm having some trouble
finding it in the archives.

\start
Date: Mon, 8 Aug 2005 09:57:24 -0700 (PDT)
From: Cliff Yapp
To: Cliff Yapp
Subject: Re: Ideas for "next generation" CAS?

In that same vein, does anybody know anything about this effort?

http://www.cs.cornell.edu/Info/Projects/NuPrl/

"The Nuprl proof development system is a framework for the development
of formalized mathematical knowledge as well as for the synthesis,
verification, and optimization of software. It is based on a
significant extension of Martin-Lof's intuitionistic Type Theory
[ML84]..."

Downloadable here:
http://www.cs.cornell.edu/Info/Projects/NuPrl/html/NuprlSystem.html

--- Cliff Yapp wrote:

> Hey Tim.  I recall some time back you mentioned some ideas you had
> for
> a "proper" redesign of Axiom, incorporating proof systems and some
> fundamental design philosophy considerations, among other things.  Is
> there a summary of those thoughts somewhere?  I'm having some trouble
> finding it in the archives.

\start
Date: Mon, 08 Aug 2005 11:57:31 -0500
From: MathAction (C Y)
To: MathAction
Subject: Ideas for "next generation" CAS?

In that same vein, does anybody know anything about this effort?

http://www.cs.cornell.edu/Info/Projects/NuPrl/

"The Nuprl proof development system is a framework for the development
of formalized mathematical knowledge as well as for the synthesis,
verification, and optimization of software. It is based on a
significant extension of Martin-Lof's intuitionistic Type Theory
[ML84]..."

Downloadable here:
http://www.cs.cornell.edu/Info/Projects/NuPrl/html/NuprlSystem.html

--- Cliff Yapp wrote:

> Hey Tim.  I recall some time back you mentioned some ideas you had
> for
> a "proper" redesign of Axiom, incorporating proof systems and some
> fundamental design philosophy considerations, among other things.  Is
> there a summary of those thoughts somewhere?  I'm having some trouble
> finding it in the archives.

\start
Date: Mon, 08 Aug 2005 12:31:41 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [GraphViz] 

  \digraph[scale=0.5]{MyGraph5}{rankdir=LR; a->b; b->c}
  \digraph[scale=0.5]{MyGraph6}{rankdir=LR; a->b; b->c}

\digraph[scale=0.5]{MyGraph7}{rankdir=LR; a->b; b->c}

\digraph[scale=0.5]{MyGraph8}{rankdir=LR; a->b; b->c; c->d}

\digraph[scale=0.5]{MyGraph9}{rankdir=LR; a->b; b->c}

  \digraph[scale=1.5]{MyGraph10}{rankdir=LR; a->b; b->c}

\start
Date: Mon, 08 Aug 2005 19:32:11 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Colloquium] 

  - [Imitation As Complement]

    other websites similar to MathAction

\start
Date: Mon, 08 Aug 2005 19:35:12 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Imitation As Complement] (new) 

MaplePrimes

  A new website: http://beta.mapleprimes.com has been created to offer
  a moderated community for Maple users to communicate and share
  techniques with each other.  This is a great place for all Maple
  users to interact and share their work.

\start
Date: Mon, 08 Aug 2005 19:35:52 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [MaplePrimes] (new) 

Two of the most significant features of MaplePrimes are moderated
forums and weblogs (blogs).

The forums function much like comp.soft-sys.math.maple and other
public Maple forums, where people can post their questions and have
them answered by the community. The difference is that the MaplePrimes
forums will be monitored and moderated by Maplesoft selected community
members. And for questions that the user community cannot answer,
Maplesoft developers will be there to help as well.

The blogs allow any user to share their experiences with Maple and
mathematics. MaplePrimes provides a place where like minded people can
show off their latest findings, share Maple procedures or chat about
their favorite theorems. This is a great place for Maple application
authors to share what they are working on and to get instant user
feedback.

Throughout the site, many special features are available. The most
interesting is the ability to post mathematics in 2D notation like you
would find in a textbook. It is as easy as either entering MathML or
the Maple syntax for the math you want to appear.

Overall, we would like MaplePrimes to become the first complete
Mathematical portal. MaplePrimes should allow anyone with any Math
knowledge get help and share what they find.  We have a number of
ideas in development that will add to this.

Please go and check it out at http://beta.mapleprimes.com I hope that
you will find the site to be very useful and come back to visit often.

Based on email from::

  William Spaetzel
  Application Developer
  Market Development
  Maplesoft
  wspaetzel@maplesoft.com
  519-747-2373x338

http://www.maplesoft.com

http://beta.mapleprimes.com

\start
Date: Mon, 08 Aug 2005 20:18:09 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [other Computer Algebra systems] 

Someday (maybe) we will also include online access to
other systems such as:

Open Source Systems

  Maxima

  Yacas

Commercial Systems

  Maple

  Mathematica

  MathCAD

\start
Date: Mon, 08 Aug 2005 20:28:34 -0500
From: MathAction (billpage)
To: MathAction
Subject: [FrontPage] 

<td onclick="window.self.location='http:/zope/mathaction/FrontPage/searchwiki'">

To "search":http:/zope/mathaction/FrontPage/searchwiki

"please report it":http:/zope/mathaction/FrontPage/issuetracker

<tr><td onclick="window.self.location='http:/zope/mathaction/SandBox'">

<tr><td onclick="window.self.location='http:/zope/mathaction/aboutAxiom'">

"Axiom book":http:/zope/mathaction/Mirrors?go=http:/zope/Plone/refs/books/axiom-book2.pdf&it=Axiom+book

<tr><td onclick="window.self.location='http:/zope/mathaction/theAxiomCommunity'">

<a href="/zope/mathaction/theAxiomCommunity">Axiom Community</a>

<IMG align="middle" src="/seal_small_transparent.png" alt="The CAISS seal">

<a href="/zope/mathaction/FrontPage/editform">

\start
Date: Mon, 08 Aug 2005 20:35:17 -0500
From: MathAction (billpage)
To: MathAction
Subject: [AxiomDownload] change to www.axiom-developer.org as standard site name

sources":http:/zope/mathaction/Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Apr2005-src.tgz&it=April+2005+Sources

  * "February 2005 sources":http:/zope/mathaction/Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-20050201-src.tgz&it=February+2005+source+code

    (binary)":http:/zope/mathaction/Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Apr2005-Redhat9-bin.tgz&it=RedHat+9+binary

    (binary)":http:/zope/mathaction/Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Apr2005-Redhat7.3-bin.tgz&it=RedHat+7.3+binary

  - "Fedora Core 1 (binary)":http:/zope/mathaction/Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Feb2005-Fedora1-bin.tgz&it=Fedora+Core+1+binary

   (binary)":http:/zope/mathaction/Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Feb2005-Fedora3-bin.tgz&it=Fedora+Core+3+binary

  * "Windows version 0.1.4":http:/zope/mathaction/Mirrors?go=http://page.axiom-developer.org/axiom-windows-0.1.4.exe&it=Windows+version+0.1.4 ${\bf\longleftarrow}$ **Recommended Download** 

  * "Windows version 0.1.3":http:/zope/mathaction/Mirrors?go=http://page.axiom-developer.org/axiom-windows-0.1.3.exe&it=Windows+version+0.1.3

  * "Debian version":http:/zope/mathaction/Mirrors?go=http://packages.debian.org/testing/math/axiom.html&it=Debian+version

  above. You may use the "issues":http:/zope/mathaction/FrontPage/issuetracker

    1 Download the "installer":http:/axiom-windows-0.1.3.exe

\start
Date: Mon, 08 Aug 2005 20:47:06 -0500
From: MathAction (billpage)
To: MathAction
Subject: [mirrors] make www.axiom-developer the standard website name

href="http:/zope/mathaction/WishList"

href="http:/zope/mathaction/theAxiomCommunity"

href="http:/zope/mathaction/AxiomDocumentation"

href="http:/zope/mathaction/issuetracker"

href="http:/zope/mathaction/AxiomPromotion"

\start
Date: Mon, 8 Aug 2005 20:57:48 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Ideas for "next generation" CAS

CY,

re: published summary of thoughts.

not really. it's an evolving idea. my current thinking on the subject
revolves around the "30 year horizon" and the "petamachine question".

in 30 years a researcher will have a machine with a Thz of cpu, a
TByte of storage, a PetaByte of disk space, and a Thz of bandwidth
(the so-called petamachine).  they'll have access to all previously
published literature and real-time access to currently written
materials flowing past on the connection, sort of a Napster version of
science.  so what kind of software is needed to do research?

clearly today's methods of building software cannot scale. if we
project axiom into this future situation and scale it by a factor of
100 we get 300 million lines of source, 110,000 domains, 1.1 million
functions, etc. i believe that axiom can scale much better than any
commercially available system because it is built on a better basis
(category theory). unfortunately while the theory will scale the 
current system will not.

why? many reasons. and as we think of them (this is nowhere near a
complete list of the things worth mentioning but time is short and
this margin is narrow :-) ) we need to develop research efforts to
attack these problems. even more unfortunately there is no support
for research at such fundamental levels anymore. (but we can still
do research without support)

consider what axiom "suggests" in its current form. if you look at the
inside cover of the axiom book or in src/doc/endpapers.pamphlet you'll
see an organization of the mathematics and data structures. this
raises several questions worth exploring.

  (a) is there a good graph of the categorical structure of math?
      (good w.r.t to the computational critera). we need a research
      effort to develop a classification scheme and a graph.
  (b) axiom creates categories which exist for computational reasons,
      such as RNG, but which are not reflected in non-computational
      math. we need to investigate the properties of RNG to either
      eliminate it or develop its axiomatic basis.
  (c) each of the categories, such as MONOID, have associated axioms.
      we need to "decorate" the categories with these axiom to provide
      a connection to the proof systems.
  (d) we need to examine the complete matrix of all of the 
      (category x category) and examine each function to ensure that
      it exists in the most general form as well as specific versions.
      this opens up whole research vistas of computational mathematics
      looking for specific algorithms that are more efficient than the
      general purpose case. given enough general vs specific examples
      we could develop theory that defines the classes of optimization
      and let the machine generate specific algorithms in real time.
  (e) given categories decorated with their axioms and program-proof 
      machinery we can look at the functions in each domain and begin
      to construct proofs for these functions. i believe that we could
      do this "in the small" with early categories (such as MONOID) 
      using ACL2 (which is in lisp and can be loaded into an axiom 
      image). only a lack of free time has stopped me from doing this.
  (f) we can look at specific functions from a domain in a category and 
      we can write the pre- and post-conditions. once we collect these
      into a catalog then systems like THEOREMA (Buchberger) can 
      search the catalog for algorithms that "logically cover" the
      constraints. this would allow THEOREMA to dynamically discover
      that the needed algorithm is actually "sort" or "log" and that
      axiom provides it.

PROGRAM PROOF

when we extend the ideas above and worry about the software scaling
issues it becomes clear that we need to research ways to develop
scientific algorithms from first principles. that is, we need to have
a way to specify a needed algorithm and let the machine derive a
complete, correct, valid, and verified program, possibly using logic
extended with programming constraints and technique libraries and
extensions of ACL2 toward generative rather than proof techniques.

in general this is too hard but within the axiom framework it might
be possible. since each function lives within a domain within a 
category and the domain and range of the function can be well specified
it might be possible to develop a language for algorithm specification.
i'd like to work on developing a set of group theory algorithms that
were automatically generated from the axiom category, domain, and
functional constraints. 

proceeding in this way we can think of constructing a new axiom 
library (and associated interpreter/compiler) that is provably
correct. i feel that the current method of developing software must
eventually give way to this kind of technique since it is vitally
important that we can trust the correctness of the computational
mathematics. 
  

LITERATE PROGRAMMING (Doyen)

lets move to another level of research for computational math.
currently papers are published that give algorithms in computational
mathematics. however they do not publish the actual code with the
paper. to me this is like publishing a theorem without showing the
proof. we need to change this for several reasons. ideally we should
be able to go to a conference, attend a talk, drag-and-drop the paper
from a URL and have the running algorithm and associated documentation
automatically added to our local copy of axiom.

there are some efforts on this. i've started the Doyen project 
(http://sourceforge.net/projects/doyencd)
which will be a bootable CD where you will be able to do this 
drag-and-drop kind of additions to science software. Carlo Traverso
at the Univ. of Pisa is trying to start a "literate journal" that
will include source code with published papers. the ACM has been
publishing the ISSAC proceedings on CD for the past two years which
includes software (but not yet literate programs).

we are computational mathematicians and we need to publish our code.
we need to develop review standards. we need to develop code proof
requirements, termination proofs, complexity statements, code
portability standards, etc. i have permission to use a few papers
that have been published as examples of these "standards". these
will be in axiom as soon as i get the actual programs able to be
"dragged and dropped" onto the Doyen version of axiom.

given the complexity of building, maintaining, and expanding
a system as large as axiom we need to intimately combine the
theory and the code into a literate form. otherwise the expertise
that created the code will die off and we won't be able to maintain
such systems in the future. the previous generation of researchers 
have begun to retire or die and all of that expertise is lost.

SCIENCE PLATFORM (Crystal)

we currently do science in arbitrary piles (math, chemistry, physics,
engineering, etc). computational science crosses all of those boundaries.
we need to develop a science platform that can present the algorithms
to the researcher "thru a facet" that makes them seem like special cases.
for example, crystallography algorithms are mostly group theory. the
group theory algorithms should be presented to the crystallographer in
a language they understand even though the underlying algorithms are 
the same as used elsewhere (say in particle physics). so there have to
be ways to customize the display of the information to match the person
who is doing the research. the "model" of the researcher and the "model"
of the problem need to be integrated so the system can maintain the
"intensional stance" (the way the system molds itself to the researcher
and the current problem under study). this "stance" is actually a 
layer between the problem (the semantic net) and the interaction
(the crystal) mentioned below.

consider that all of the published science could now be put on a single
hard drive (except for copyright issues). each researcher could start
with this copy. since the science platform is net-connected and new
papers are being published constantly we need to develop technology 
to keep the information in some common form. there are hints of ways
to do this (see http://www.research.ibm.com/UIMA) but we need to 
stretch the bounds further. the meaning of the terms in the paper
need to be represented and extracted. the meaning of the paper needs
to be represented and extracted. all of these various levels of meaning
and their associations need to be represented. my current thinking is
to extend latex with a new set of semantic markup tools ("semtex?")
so that ideas, terms, definitions, etc can have explicit markup.

there is a technology for knowledge representation (see
http://lists.gnu.org/archives/html/axiom-developer/2003-12/msg00071.html)
that uses a "semantic network" as the primary representation. i'd like
to have a KROPS-like representation as the center of the problem.
research needs to be done to extend the dual OPS5-KREP techniques.

dragging these issues together we get the "crystal" idea. think of
the "problem" that the researcher is working on as a semantic graph
hanging in space. surround the graph with a crystal with many facets.
each facet represents a view (actually, a view-controller in the 
"model-view-controller" sense). one "facet" view might show an annotated
bibliography related to the problem. another facet might show the literate
program. another facet might be a graph of one of the functions in the
problem. another faceet might be a 3D solid model of the topological
space (math), or the bridge under construction (eng), or the molecule
(biochem). changes done in one view are globally reflected since the
semantic net is changed. changes cause automatic literature searches
(we have cpu to spare) and the system can suggest related literature.
based on feedback to the suggestions new literature is filtered (thus
the "intensional stance" of the researcher for this problem is modeled).

so developing a prototype of the crystal idea is a key research project,
at least on my version of the 30 year horizon critical path.

nobody has the political will to fund such long-term research so the
only possible way to develop this technology is thru open
source. axiom was funded for 23 years and is an amazing program. we
need to spend much more time and effort to meet the needs of the
researcher in 2035.  computational math, unlike any other software,
generates timeless software. the integral of "sin(x)" will still be
the same in 30 years.

there is much more and i really ought to put together a talk about it
at some point. perhaps once the doyen project works so i can demonstrate
the ideas.

we really should have a debate about what the future researcher needs
and how use future computers to cope with the information explosion.

if you want more comments or specific details of my local projects 
(like DOYEN, or KROPS, or CATS) just post on this list.

hope this is useful to you.

\start
Date: Tue, 09 Aug 2005 05:00:27 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#196 )set functions compile on] (nouveau) 

For some strange reason, without issuing

\begin{axiom}
  )se fu co on
\end{axiom}

the following will not work and cause the interpreter to crash.
\begin{axiom}
   f(xl: LIST FRAC INT): LIST FRAC INT == map(x +-> x, xl)
   f [1,2,3]
\end{axiom}

The same problem was reported in a different context in bug #165

\start
Date: Tue, 09 Aug 2005 05:02:24 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#196 )set functions compile on] 

the following will not work and cause the interpreter to crash:

f(xl: LIST FRAC INT): LIST FRAC INT == map(x +-> x, xl)

f [1,2,3]

\start
Date: Tue, 09 Aug 2005 08:27:17 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [other Computer Algebra systems] 

  Maxima -- See: http://maxima.sourceforge.net

  Yacas -- See: http://yacas.sourceforge.net/yacas.html

  Maple -- See: MaplePrimes

  Mathematica -- See: http://www.wolfram.com/products/mathematica/index.html

  MathCAD -- See: http://www.mathsoft.com/solutions/calculation_management_suite/mathcad.asp

  Mupad -- See: http://www.mupad.de

\start
Date: Wed, 10 Aug 2005 23:34:09 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: [Gcl-devel] Version_2_7_0t5

Camm,

On Wednesday, August 10, 2005 2:14 PM you wrote:
> ...
> Re: [Gcl-devel] Version_2_7_0t5
> 
> Greetings!  Small correction -- there is a minor issue remaining
> in t5 for axiom.
> 

I am glad to hear that building Axiom (on Linux at least) with
gcl 2.7.0 is so close! :)

Tim has recently moved the Axiom source to Version_2_6_7pre which
builds Axiom on both Linux and windows. Are you still planning
to release an "official" gcl 2.6.7 ? If so, are there any more
features in the Version_2_7_0 series that can be easily, usefully
and portably back-ported to 2.6.7?

\start
Date: 11 Aug 2005 18:39:47 -0400
From: Camm Maguire
To: Bill Page
Subject: re: [Gcl-devel] Version_2_7_0t5

My apologies to all for being so low on 2.6.7.

Take care,

Bill Page writes:

> Camm,
> 
> On Wednesday, August 10, 2005 2:14 PM you wrote:
> > ...
> > Re: [Gcl-devel] Version_2_7_0t5
> > 
> > Greetings!  Small correction -- there is a minor issue remaining
> > in t5 for axiom.
> > 
> 
> I am glad to hear that building Axiom (on Linux at least) with
> gcl 2.7.0 is so close! :)
> 
> Tim has recently moved the Axiom source to Version_2_6_7pre which
> builds Axiom on both Linux and windows. Are you still planning
> to release an "official" gcl 2.6.7 ? If so, are there any more
> features in the Version_2_7_0 series that can be easily, usefully
> and portably back-ported to 2.6.7?

\start
Date: Thu, 11 Aug 2005 18:59:46 -0500
From: MathAction (Ryan Krauss)
To: MathAction
Subject: [Axiom-mail] \begin{axiom} latex on windows

I found this example on the axiom-developer mailing list from about a 
year ago:

  \begin{axiom-input}
  R1:=matrix([[cos a, sin a, 0],[-sin a, cos a, 0],[0, 0, 1]])
  \end{axiom-input}
  Next we define a rotation around the Y axis by a rotation angle of b 
  \begin{axiom-input}
  R2:=matrix([[cos b, 0, -sin b],[0, 1, 0],[sin b, 0, cos b]])
  \end{axiom-input}
  The we compose them (order is important) to form the single
  rotation equivalent to first rotating around X, then around
  the new, displaced Y. 
  \begin{axiom-input}
  R:=R1*R2
  \end{axiom-input}

I would very much like to be able to write LaTeX documents like this on 
Windows XP.  Has anyone done this?

If not, I am a bit of a Python programmer and I was thinking one way to 
make it work would be to have Python parse the tex file and take 
whatever is between the \begin{axiom} and \end{axiom} statements and 
create an input file for axiom with the output set by the file to go to 
numbered .tex files.  Python would then replace the \begin{axiom}... 
with \begin{equation} \input{....###} (i.e. the output files from axiom).

But in order to make something like this work, Python needs to be able 
to call axiom and tell it to run the script (and possibly close axiom 
afterward).  Is there a way to do this on Windows?  Can it be done with 
a dos command?

Is there an easier way?

\start
Date: Thu, 11 Aug 2005 19:29:58 -0500
From: MathAction (Bob McElrath)
To: MathAction
Subject: [Axiom-mail] \begin{axiom} latex on windows

Ryan Krauss wrote:
> I found this example on the axiom-developer mailing list from about a 
> year ago:
> 
>  \begin{axiom-input}
>  R1:=matrix([[cos a, sin a, 0],[-sin a, cos a, 0],[0, 0, 1]])
>  \end{axiom-input}
>  Next we define a rotation around the Y axis by a rotation angle of b 
>  \begin{axiom-input}
>  R2:=matrix([[cos b, 0, -sin b],[0, 1, 0],[sin b, 0, cos b]])
>  \end{axiom-input}
>  The we compose them (order is important) to form the single
>  rotation equivalent to first rotating around X, then around
>  the new, displaced Y. 
>  \begin{axiom-input}
>  R:=R1*R2
>  \end{axiom-input}
> 
> I would very much like to be able to write LaTeX documents like this on 
> Windows XP.  Has anyone done this?

The MathAction wiki
(http://page.axiom-developer.org/zope/mathaction/FrontPage)
allows documents like this.  It runs on the zope server, and some code
pasted together by myself and Bill Page calls axiom on the server to
render the document.

Additionally the "pamphlet" format used natively by axiom supports
running axiom commands, using a similar syntax.

Finally, we are currently working on a more "worksheet" style interface,
and the first iteration I did was a modification of tiddlywiki
(http://www.tiddlywiki.com) to support axiom and jsMath.  (it runs axiom
without a server using some javascript tricks in firefox)  However this
will definitely not work on windows.

> If not, I am a bit of a Python programmer and I was thinking one way to 
> make it work would be to have Python parse the tex file and take 
> whatever is between the \begin{axiom} and \end{axiom} statements and 
> create an input file for axiom with the output set by the file to go to 
> numbered .tex files.  Python would then replace the \begin{axiom}... 
> with \begin{equation} \input{....###} (i.e. the output files from axiom).

The code is all python but does not run standalone, currently.  Trivial
modifications could be made to make it run standalone.

> But in order to make something like this work, Python needs to be able 
> to call axiom and tell it to run the script (and possibly close axiom 
> afterward).  Is there a way to do this on Windows?  Can it be done with 
> a dos command?

I can't comment on windows...

If you're interested in working on this, please join axiom-developer!
;)


\start
Date: Thu, 11 Aug 2005 19:33:09 -0500
From: MathAction (Ryan Krauss)
To: MathAction
Subject: [Axiom-mail] \begin{axiom} latex on windows

I can't find any documentation on the pamphlet format.  Can you tell me 
where I can find out more?

Thanks,

Ryan

Bob McElrath wrote:
> Ryan Krauss [Ryan Krauss] wrote:
> 
>>I found this example on the axiom-developer mailing list from about a 
>>year ago:
>>
>> \begin{axiom-input}
>> R1:=matrix([[cos a, sin a, 0],[-sin a, cos a, 0],[0, 0, 1]])
>> \end{axiom-input}
>> Next we define a rotation around the Y axis by a rotation angle of b 
>> \begin{axiom-input}
>> R2:=matrix([[cos b, 0, -sin b],[0, 1, 0],[sin b, 0, cos b]])
>> \end{axiom-input}
>> The we compose them (order is important) to form the single
>> rotation equivalent to first rotating around X, then around
>> the new, displaced Y. 
>> \begin{axiom-input}
>> R:=R1*R2
>> \end{axiom-input}
>>
>>I would very much like to be able to write LaTeX documents like this on 
>>Windows XP.  Has anyone done this?
> 
> 
> The MathAction wiki
> (http://page.axiom-developer.org/zope/mathaction/FrontPage)
> allows documents like this.  It runs on the zope server, and some code
> pasted together by myself and Bill Page calls axiom on the server to
> render the document.
> 
> Additionally the "pamphlet" format used natively by axiom supports
> running axiom commands, using a similar syntax.
> 
> Finally, we are currently working on a more "worksheet" style interface,
> and the first iteration I did was a modification of tiddlywiki
> (http://www.tiddlywiki.com) to support axiom and jsMath.  (it runs axiom
> without a server using some javascript tricks in firefox)  However this
> will definitely not work on windows.
> 
> 
>>If not, I am a bit of a Python programmer and I was thinking one way to 
>>make it work would be to have Python parse the tex file and take 
>>whatever is between the \begin{axiom} and \end{axiom} statements and 
>>create an input file for axiom with the output set by the file to go to 
>>numbered .tex files.  Python would then replace the \begin{axiom}... 
>>with \begin{equation} \input{....###} (i.e. the output files from axiom).
> 
> 
> The code is all python but does not run standalone, currently.  Trivial
> modifications could be made to make it run standalone.
> 
> 
>>But in order to make something like this work, Python needs to be able 
>>to call axiom and tell it to run the script (and possibly close axiom 
>>afterward).  Is there a way to do this on Windows?  Can it be done with 
>>a dos command?
> 
> 
> I can't comment on windows...
> 
> If you're interested in working on this, please join axiom-developer!
> ;)

\start
Date: Thu, 11 Aug 2005 20:05:42 -0500
From: MathAction (Mike Thomas)
To: MathAction
Subject:  \begin{axiom} latex on windows

Hi Ryan.

| I would very much like to be able to write LaTeX documents like this on 
| Windows XP.  Has anyone done this?

To build Axiom on Windows (including those LaTeX pamphlets), I use the excellent and free software MikTeX:

  http://www.miktex.org/

I believe that Bill Page also uses that package.

\start
Date: Thu, 11 Aug 2005 18:35:42 -0400
From: Camm Maguire
To: Bill Page, Robert Boyer, Warren Hunt, Matt Kaufmann, Gordon Novak
Subject: GCL 2.6.7 is released

Greetings!

Stable version: 2.6.7
Testing Version: (cvs tag) Version_2_7_0t5

Greetings!  The GCL team is happy to announce the release of version
2.6.7, the latest achievement in the 'stable' (as opposed to
'development') series.  Please see http://www.gnu.org/software/gcl for
downloading information.

My apologies to Gordon Novak -- I had intended for this next stable
release to include xgcl support by default, but I have run out of
time, am leaving for a few days next week, and axiom is waiting for
the new webserver features.  xgcl does work with release as with 2.6.6
but must still be built explicitly in the xgcl2 subdirectory.  I will
try to rectify this as soon as feasible.

This release is a minor modification of 2.6.6, incorporating the known
bug fixes that had accumulated on the GCL errata page together with a
few other modifications primarily intended to provide a native
webserver feature to be used by axiom for displaying its documentation
and graphics.  The interested user is advised to consult the info
documentation on SOCKET supplied with the source.  From the
changelog:

  * Fix (listen) with readline on
  * fix control-d with readline
  * libreadline5 support for Debian
  * Support for pre-compiled regexps and new texinfo format
  * Reenable run-process
  * Push function 'accept  into lisp, use select for 'listen on socket
    streams
  * New Upstream release version
  * Native-reloc feature
  * Add daemon capabilities to server sockets, document socket and
    accept
  * Some gcl-tk fixes
  * Update wrapt-literals strategy to be consistent with CVS head --
    wrap evreything but symbols and integers, don't wrap when keeping
    the gazonk files for linking in different images, this is really a
    compile-file operation
  * gcltk demo cleanups
  * Probe-file, open_stream, and the like fail on directories
  * Resolve symlinks in truename
  * Place prototypes for defcfun in header files
  * Support for unique init names for compiler::link and the like
  * libreadline5 for Debian
  * remove _o from init-names
  * gcc-4.0 fixups
  * Bug fix: "gcl: depends on binutils-dev &lt;&lt;= 2.1.5-999), so
    uninstallable in unstable", thanks to Steve Langasek (Closes:
    #318681).  Rebuild with new release to autocompute this dep
  * Bug fix: "gcl: Please switch to po-debconf", thanks to Lucas Wall
    (Closes: #295930). Apply po-debconf patch
  * Newer standards

\start
Date: Fri, 12 Aug 2005 11:02:28 -0500
From: MathAction (David Mentre)
To: MathAction
Subject: [Axiom-mail] \begin{axiom} latex on windows

Hello Ryan,

2005/8/12, Ryan Krauss:
> I can't find any documentation on the pamphlet format.  Can you tell me
> where I can find out more?

I've not followed latest Axiom developments but as far as I know
pamphlet format is the same as noweb format (noweb is the tool used to
parse pamphlets in Axiom).

noweb home page: http://www.eecs.harvard.edu/~nr/noweb/

A single page doc: http://www.eecs.harvard.edu/~nr/noweb/onepage.ps

Some examples : http://www.eecs.harvard.edu/~nr/noweb/examples/index.html

You should also look at axiom-developer mailing list archives, Tim
Daly has made extensive description of pamphlets.

\start
Date: Fri, 12 Aug 2005 11:18:04 -0500
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] \begin{axiom} latex on windows

I just sent one to axiom-math...

\start
Date: Fri, 12 Aug 2005 13:29:37 -0700
From: Bob McElrath
To: Davide P.Cervone
Subject: Re: New version of jsMath

Hello again Davide,

I installed jsMath 2.0 yesterday and it is quite impressive, you've come
a long way!

As you remember, we are working on a browser-based interface to the
computer algebra system.  We have decided to incorporate the SVG and
MathML technologies for this.  While jsMath is a wonderful stepping
stone, it is too slow to render the quantity of math that would appear
in a "worksheet".

Instead, how about using jsMath to convert tex to MathML?  I tried to do
this trivially by creating a XHTML+SVG+MathML page with jsMath, but I
find:
    1) jsMath uses document.write() to add math.  this is incompatible
    with XHTML.  One should instead use DOM-based methods such as
    appendChild, removeChild, etc.
    2) jsMath uses upper case tags in all cases.  (XHTML requires
    lower-case tags)

I think full XHTML-ization of jsMath will not make it incompatible with
existing implementations that use HTML 4.0, as the DOM is still there in
both cases (with minor differences), and one would just disable MathML
when the parent DOCTYPE doesn't support it.

I tried this using your competing tool, ASCIIMathML, but frankly your
tex parsing is far superior to theirs, so I'd like to insert MathML
output into your tex parsing machinery.

I have partially XHTML-ized jsMath.js (file here:
http://mcelrath.org:9674/ZiddlyWiki2/jsMath/jsMath.js) but as I
mentioned due to document.write[ln] it will not work in XHTML.

Would you be opposed to making jsMath XHTML-compatible?  Would you be
opposed to adding a MathML rendering path?

Could you give me any pointers as to how to proceed?  I can convert your
document.write[ln]'s but I am unsure how/where to insert MathML.  I
assume in Typeset() but I keep looking at this code and it keeps being
very opaque to me.

\start
Date: Fri, 12 Aug 2005 23:18:42 -0500
From: Tim Daly
To: Camm Maguire
Subject: gcl-2.6.7

re: slow. hey, life happens, right? i've been really lagged also
so our response times match. i just got back from a business trip today.

i've downloaded 2.6.7 and am working to port the system now.

\start
Date: Sat, 13 Aug 2005 12:27:22 +0200
From: Ruiz Aguilera
To: list
Subject: Axiom on FreeBSD?

Hi.

I want to use Axiom on FreeBSD, is it possible?

\start
Date: Sat, 13 Aug 2005 16:32:34 -0500
From: Tim Daly
To: list
Subject: --patch-44

--patch-44 has been uploaded. to get this type:
    tla get axiom--main--1

Tim

======================================================================

Summary: move to gcl-2.6.7
Keywords: daly gcl-2.6.7

20050813 tpd --patch-44
20050813 tpd Makefile VERSION update to Axiom 3.9 (September 2005)
20050813 tpd lsp/Makefile gcl-2.6.7 patches
20050813 tpd Makefile GCLVERSION=gcl-2.6.7
20050813 tpd gcl-2.6.7.unixport.makefile.patch
20050813 tpd gcl-2.6.7.unixport.init_gcl.lsp.in.patch added
20050813 tpd gcl-2.6.7.h.linux.defs.patch added
20050813 tpd gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch added
20050813 tpd gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch added
20050813 tpd gcl-2.6.7.tgz added

\start
Date: Sat, 13 Aug 2005 16:43:44 -0500
From: Tim Daly
To: Martin Rubey
Subject: Beckermann and Labahn paper

Martin,

Is there any chance of getting permission to use the 
Beckermann and Labahn paper as part of the documentation?
Usually I've been rewriting the paper into a more "documenting"
form as well as embedding the code. But I can only do this with
permission. If you know either of the authors I'd be happy to ask.

\start
Date: Sat, 13 Aug 2005 22:07:08 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Integration in Axiom?

Curosity question - are there any known limitations to Axiom's current
integration routines compared to the "state of the art" algorithms?  I
ask because I get the following doing the same integral in Maxima vs.
Axiom (note I'm not sure if Maxima is correct):

                          AXIOM Computer Algebra System 
                       Version: Axiom 3.6 (June 2005)
               Timestamp: Wednesday July 27, 2005 at 12:16:43 
-----------------------------------------------------------------------------
   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
(1) -> 
(1) -> integrate(sin(x**2),x)
      UserDefinedPartialOrdering 
           x
         ++        2
   (1)   |   sin(%I )d%I
        ++
                                          Type: Union(Expression
Integer,...)
(2) -> 


Maxima 5.9.1.1cvs http://maxima.sourceforge.net
Using Lisp CMU Common Lisp 19b (19B)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
This is a development version of Maxima. The function bug_report()
provides bug reporting information.
(%i1) integrate(sin(x**2),x);
                                            (sqrt(2) %i + sqrt(2)) x
(%o1) sqrt(%pi) ((sqrt(2) %i + sqrt(2)) erf(------------------------)
                                                       2
                                    (sqrt(2) %i - sqrt(2)) x
       + (sqrt(2) %i - sqrt(2)) erf(------------------------))/8
                                               2
(%i2)

\start
Date: Sun, 14 Aug 2005 09:23:44 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: Beckermann and Labahn paper

Tim Daly writes:
 > Martin,
 > 
 > Is there any chance of getting permission to use the 
 > Beckermann and Labahn paper as part of the documentation?

I don't know. But since their paper is available online *and* published, I
don't think it is necessary. (You did notice that I did not document the source
at all so far...)

 > Usually I've been rewriting the paper into a more "documenting"
 > form as well as embedding the code. But I can only do this with
 > permission. If you know either of the authors I'd be happy to ask.

No, I don't know them. And in fact, after a little digging, I find that their
paper is better written than any documentation I could write. I will document
the bits of code where I depart from their paper.

\start
Date: Sun, 14 Aug 2005 14:29:56 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Re: --patch-44

Le samedi 13 ao=FBt 2005 =E0 16:32 -0500, Tim Daly a =E9c=
rit :
> --patch-44 has been uploaded. to get this type:
>     tla get axiom--main--1
>
> Tim
>
> =========================
==========================
=====================
>
> Summary: move to gcl-2.6.7
> Keywords: daly gcl-2.6.7
>
> 20050813 tpd --patch-44
> 20050813 tpd Makefile VERSION update to Axiom 3.9 (September 2005)
> 20050813 tpd lsp/Makefile gcl-2.6.7 patches
> 20050813 tpd Makefile GCLVERSION=gcl-2.6.7
> 20050813 tpd gcl-2.6.7.unixport.makefile.patch
> 20050813 tpd gcl-2.6.7.unixport.init_gcl.lsp.in.patch added
> 20050813 tpd gcl-2.6.7.h.linux.defs.patch added
> 20050813 tpd gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch added
> 20050813 tpd gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch added
> 20050813 tpd gcl-2.6.7.tgz added

More precisely:



BOOT
>======================================
=== algebra bootstrap complete ======
======================================
compiling AHYP.spad to AHYP.NRLIB
                        AXIOM Computer Algebra System
                     Version: Axiom 3.9 (September 2005)
               Timestamp: Sunday August 14, 2005 at 14:27:00
-------------------------------------------------------------------------=
----
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-------------------------------------------------------------------------=
----

   Using local
database /usr/local/axiom/src/share/algebra/compress.daase..   Using
local database /usr/local/axiom/src/share/algebra/interp.daase..
   Using local
database /usr/local/axiom/src/share/algebra/operation.daase..
   Using local
database /usr/local/axiom/src/share/algebra/category.daase..
   Using local
database /usr/local/axiom/src/share/algebra/browse.daase..
(1) ->    Loading /usr/local/axiom/mnt/linux/autoload/apply.
   Loading /usr/local/axiom/mnt/linux/autoload/c-doc.
   Loading /usr/local/axiom/mnt/linux/autoload/c-util.
   Loading /usr/local/axiom/mnt/linux/autoload/profile.
   Loading /usr/local/axiom/mnt/linux/autoload/category.
   Loading /usr/local/axiom/mnt/linux/autoload/compiler.
   Loading /usr/local/axiom/mnt/linux/autoload/define.
   Loading /usr/local/axiom/mnt/linux/autoload/functor.
   Loading /usr/local/axiom/mnt/linux/autoload/info.
   Loading /usr/local/axiom/mnt/linux/autoload/iterator.
   Loading /usr/local/axiom/mnt/linux/autoload/modemap.
   Loading /usr/local/axiom/mnt/linux/autoload/nruncomp.
   Loading /usr/local/axiom/mnt/linux/autoload/package.
   Loading /usr/local/axiom/mnt/linux/autoload/htcheck.
   Loading /usr/local/axiom/mnt/linux/autoload/xruncomp.
   Compiling AXIOM source code from file AHYP.spad using old system
      compiler.
   Loading /usr/local/axiom/mnt/linux/autoload/parsing.
   Loading /usr/local/axiom/mnt/linux/autoload/bootlex.
   Loading /usr/local/axiom/mnt/linux/autoload/def.
   Loading /usr/local/axiom/mnt/linux/autoload/fnewmeta.
   Loading /usr/local/axiom/mnt/linux/autoload/metalex.
   Loading /usr/local/axiom/mnt/linux/autoload/metameta.
   Loading /usr/local/axiom/mnt/linux/autoload/parse.
   Loading /usr/local/axiom/mnt/linux/autoload/postpar.
   Loading /usr/local/axiom/mnt/linux/autoload/postprop.
   Loading /usr/local/axiom/mnt/linux/autoload/preparse.
   AHYP abbreviates category ArcHyperbolicFunctionCategory
------------------------------------------------------------------------
   initializing NRLIB AHYP for ArcHyperbolicFunctionCategory
   compiling into NRLIB AHYP

;;;     ***       |ArcHyperbolicFunctionCategory| REDEFINED
Time: 0.01 SEC.

   Loading /usr/local/axiom/mnt/linux/autoload/bc-matrix.
   Loading /usr/local/axiom/mnt/linux/autoload/bc-misc.
   Loading /usr/local/axiom/mnt/linux/autoload/bc-solve.
   Loading /usr/local/axiom/mnt/linux/autoload/bc-util.
   Loading /usr/local/axiom/mnt/linux/autoload/ht-util.
   Loading /usr/local/axiom/mnt/linux/autoload/htsetvar.
   Loading /usr/local/axiom/mnt/linux/autoload/ht-root.
   Loading /usr/local/axiom/mnt/linux/autoload/br-con.
   Loading /usr/local/axiom/mnt/linux/autoload/br-data.
   Loading /usr/local/axiom/mnt/linux/autoload/showimp.
   Loading /usr/local/axiom/mnt/linux/autoload/br-op1.
   Loading /usr/local/axiom/mnt/linux/autoload/br-op2.
   Loading /usr/local/axiom/mnt/linux/autoload/br-search.
   Loading /usr/local/axiom/mnt/linux/autoload/br-util.
   Loading /usr/local/axiom/mnt/linux/autoload/topics.
   Loading /usr/local/axiom/mnt/linux/autoload/br-prof.
   Loading /usr/local/axiom/mnt/linux/autoload/br-saturn.
   finalizing NRLIB AHYP

   >> System error:
   The function |insertAlist| is undefined.

Any idea ?

\start
Date: Sun, 14 Aug 2005 14:02:08 +0200
From: Vanuxem =?ISO-8859-1?Q?Gr=E9gory?= Gregory Vanuxem
To: Tim Daly
Subject: Re: --patch-44

Hi,

Le samedi 13 ao=FBt 2005 =E0 16:32 -0500, Tim Daly a =E9c=
rit :
> --patch-44 has been uploaded. to get this type:
>     tla get axiom--main--1
>
> Tim
>
> =========================
==========================
=====================
>
> Summary: move to gcl-2.6.7
> Keywords: daly gcl-2.6.7
>
> 20050813 tpd --patch-44
> 20050813 tpd Makefile VERSION update to Axiom 3.9 (September 2005)
> 20050813 tpd lsp/Makefile gcl-2.6.7 patches
> 20050813 tpd Makefile GCLVERSION=gcl-2.6.7
> 20050813 tpd gcl-2.6.7.unixport.makefile.patch
> 20050813 tpd gcl-2.6.7.unixport.init_gcl.lsp.in.patch added
> 20050813 tpd gcl-2.6.7.h.linux.defs.patch added
> 20050813 tpd gcl-2.6.7.cmpnew.gcl_cmpflet.lsp.patch added
> 20050813 tpd gcl-2.6.7.cmpnew.gcl_cmpcall.lsp.patch added
> 20050813 tpd gcl-2.6.7.tgz added
>

compiling STAGG-.lsp to STAGG-.o
compiling SYMBOL.lsp to SYMBOL.o
compiling TSETCAT.lsp to TSETCAT.o
compiling TSETCAT-.lsp to TSETCAT-.o
compiling UFD.lsp to UFD.o
compiling UFD-.lsp to UFD-.o
compiling ULSCAT.lsp to ULSCAT.o
compiling UPOLYC.lsp to UPOLYC.o
compiling UPOLYC-.lsp to UPOLYC-.o
compiling URAGG.lsp to URAGG.o
compiling URAGG-.lsp to URAGG-.o
compiling VECTOR.lsp to VECTOR.o
==========================
============
=== algebra bootstrap complete ======
==========================
============
compiling AHYP.spad to AHYP.NRLIB
make[3]: *** [/usr/local/axiom/int/algebra/AHYP.NRLIB/code.o] Erreur 255
make[3]: quittant le r=E9pertoire =AB /usr/local/axiom/src/algebra =BB
make[2]: *** [algebradir] Erreur 2
make[2]: quittant le r=E9pertoire =AB /usr/local/axiom/src =BB
make[1]: *** [srcdir] Erreur 2
make[1]: quittant le r=E9pertoire =AB /usr/local/axiom =BB
make: *** [all] Erreur 2
ellipse:/usr/local/axiom#

\start
Date: Sun, 14 Aug 2005 09:30:50 -0500
From: Tim Daly
To: Gregory Vanuxem
Subject: --patch-44 build failure

Greg,

Please type:
  
   make NOISE=

and send me the console.

\start
Date: Sun, 14 Aug 2005 09:33:34 -0500
From: Tim Daly
To: Mark Murray
Subject: freebsd

Mark,

As I mentioned, the next step after the gcl-2.6.7 port is to get
Axiom running on FreeBSD. I've set up a freebsd node here and
moved Axiom sources onto it. I'll let you know how it goes.

\start
Date: Sun, 14 Aug 2005 11:02:42 -0500
From: Tim Daly
To: Gregory Vanuxem
Subject: send file

Greg,

insertAlist is defined in src/interp/i-coerfn.boot.pamphlet

please send me the file:
  /usr/local/axiom/int/interp/i-coerfn.clisp

which is the translated file from i-coerfn.boot.

\start
Date: Sun, 14 Aug 2005 11:53:04 -0500
From: Tim Daly
To: Gregory Vanuxem
Subject: send file

Greg,

It appears that you stopped the make in the middle of the translation
of i-coerfn.boot.pamphlet.

Try
    make clean
    rm -rf int obj mnt noweb 
    make NOISE=

\start
Date: Sun, 14 Aug 2005 18:04:48 +0100
From: Peter Broadbery
To: Tim Daly
Subject: Axiom/aldor interface code


Hi Tim,

I've been doing a bit more work on the aldor interface (it will now
compile 90% of the axiom library for use against aldor).  I'm at the
point of pampletising the source files, and should be done pretty soon.
Some may even be documented properly once I'm done.

I can either send patches or try to merge with an existing tla branch -
what do you prefer?

Cheers,

Pete

Oh, excuse the delay in getting back round to this.  I'm interested in
trying to get aldor working, but I think it'll take more testing &
development than I can supply in order to get it working 100%.

\start
Date: Sun, 14 Aug 2005 12:07:22 -0500
From: Tim Daly
To: Peter Broadbery
Subject: Axiom/aldor interface code

Pete,

Excellent. Just send me the pamphlets and I'll work on the merge piece.

re: delay. progress is not measured by time. Once I see what you've
been up to I can work out testing methods and integrate them into 
the whole.

\start
Date: Sun, 14 Aug 2005 13:03:12 -0500
From: Tim Daly
To: Gregory Vanuxem
Subject: Axiom/aldor interface code

Greg,

The process is:

   notangle i-coerfn.boot.pamphlet ==> i-coerfn.boot
   depsys (boottocl) i-coerfn.boot ==> i-coerfn.clisp
   depsys   i-coerfn.clisp         ==> i-coerfn.o

The process can fail in several ways but it appears that you have
a partially translated .boot file resulting in a truncated .clisp file.
The usually indicates a syntax error in the boot file causing the
boottocl translator to stop.

Or if the make is stopped while the .clisp file is partially written
then it will already exist (with only some of the functions translated)
and restarting the make will not retranslate the file (since it exists).

Rebuilding the system from scratch should cure the problem. I've fetched
the sources and will do another rebuild here just to check that the file
was not changed in some way.

\start
Date: Sun, 14 Aug 2005 14:55:39 -0500
From: Tim Daly
To: Gregory Vanuxem
Subject: Axiom/aldor interface code

Greg,

I've refetched and rebuilt the system from the archives and it builds
cleanly here. If you refetch and rebuild does it still fail?

\start
Date: Sun, 14 Aug 2005 21:41:09 +0200
From: Martin Rubey
To: Peter Broadbery
Subject: Re: Axiom/aldor interface code

Wow, this is great news!

Thanks a million times for your efforts!

Martin

Peter Broadbery writes:
 > 
 > Hi Tim,
 > 
 > I've been doing a bit more work on the aldor interface (it will now
 > compile 90% of the axiom library for use against aldor).  I'm at the
 > point of pampletising the source files, and should be done pretty soon.
 > Some may even be documented properly once I'm done.
 > 
 > I can either send patches or try to merge with an existing tla branch -
 > what do you prefer?
 > 
 > Cheers,
 > 
 > Pete
 > 
 > Oh, excuse the delay in getting back round to this.  I'm interested in
 > trying to get aldor working, but I think it'll take more testing &
 > development than I can supply in order to get it working 100%.

\start
Date: Sun, 14 Aug 2005 22:09:11 +0200
From: Gregory Vanuxem
To: Tim Daly
Subject: Re: Axiom/aldor interface code

Le dimanche 14 ao=FBt 2005 =E0 14:55 -0500, Tim Daly a
=E9crit :
> Greg,
>
> I've refetched and rebuilt the system from the archives and it builds
> cleanly here. If you refetch and rebuild does it still fail?

Yes since gcl-2.6.7pre but i don't know why.
I'll retry probably tomorrow.

\start
Date: Mon, 15 Aug 2005 08:43:06 -0500
From: MathAction (gregr)
To: MathAction
Subject: [Lisp's Fraction Integer Domain] Typo error in	interp.patch

There was a typo error in interp.patch.
Corrected in this new patch.

\start
Date: Mon, 15 Aug 2005 10:39:24 -0500
From: MathAction (greg)
To: MathAction
Subject: [#197 DFLOAT format] 

??changed:
-<pre>
-diff -u  /usr/local/axiom/int/algebra/DFLOAT.spad  Axiom/DFLOAT.spad
---- /usr/local/axiom/int/algebra/DFLOAT.spad    2005-08-15 16:48:58.055751184 +0200
-+++ Axiom/DFLOAT.spad   2005-07-24 18:23:33.051285856 +0200
-@@ -62,6 +62,7 @@
-         ++ Gamma(x) is the Euler Gamma function.
-       Beta : (%,%) -> %
-         ++ Beta(x,y) is \spad{Gamma(x) * Gamma(y)/Gamma(x+y)}.
-+      doubleFloatFormat : String -> String
-       rationalApproximation: (%, NonNegativeInteger) -> Fraction Integer
-         ++ rationalApproximation(f, n) computes a rational approximation
-         ++ r to f with relative error \spad{< 10**(-n)}.
-@@ -71,10 +72,17 @@
-          ++ (that is, \spad{|(r-f)/f| < b**(-n)}).
-
-  == add
-+   format: String := "~G"
-    MER ==> Record(MANTISSA:Integer,EXPONENT:Integer)
-
-[21 more lines...]

\start
Date: Mon, 15 Aug 2005 10:37:08 -0500
From: MathAction (greg)
To: MathAction
Subject: [#197 DFLOAT format] (new) 

Add a format option to DFLOAT.spad. Here is a non documented patch
<pre>
diff -u  /usr/local/axiom/int/algebra/DFLOAT.spad  Axiom/DFLOAT.spad
--- /usr/local/axiom/int/algebra/DFLOAT.spad    2005-08-15 16:48:58.055751184 +0200
+++ Axiom/DFLOAT.spad   2005-07-24 18:23:33.051285856 +0200
@@ -62,6 +62,7 @@
         ++ Gamma(x) is the Euler Gamma function.
       Beta : (%,%) -> %
         ++ Beta(x,y) is \spad{Gamma(x) * Gamma(y)/Gamma(x+y)}.
+      doubleFloatFormat : String -> String
       rationalApproximation: (%, NonNegativeInteger) -> Fraction Integer
         ++ rationalApproximation(f, n) computes a rational approximation
         ++ r to f with relative error \spad{< 10**(-n)}.
@@ -71,10 +72,17 @@
          ++ (that is, \spad{|(r-f)/f| < b**(-n)}).

  == add
+   format: String := "~G"
    MER ==> Record(MANTISSA:Integer,EXPONENT:Integer)

    manexp: % -> MER

+   doubleFloatFormat(s:String): String ==
+     ss: String := format
+     format := s
+     ss
+
+
    OMwrite(x: %): String ==
      s: String := ""
      sp := OM_-STRINGTOSTRINGPTR(s)$Lisp
@@ -132,7 +140,7 @@
    -- rational approximation to e accurate to 23 digits
    exp1()           == FLOAT(534625820200,MOST_-POSITIVE_-LONG_-FLOAT$Lisp)$Lisp / FLOAT(196677847971,MOST_-POSITIVE_-LONG_-FLOAT$Lisp)$Lisp
    pi()             == PI$Lisp
-   coerce(x:%):OutputForm == outputForm(x pretend DoubleFloat)
+   coerce(x:%):OutputForm == outputForm(FORMAT(NIL$Lisp,format,x)$Lisp pretend DoubleFloat)
    convert(x:%):InputForm == convert(x pretend DoubleFloat)$InputForm
    x < y            == (x<y)$Lisp
    - x              == (-x)$Lisp
</pre>

\start
Date: Mon, 15 Aug 2005 17:25:34 -0500
From: MathAction (unknown)
To: MathAction
Subject: [MuPAD] 

differentiate(sin x,x)

\start
Date: Mon, 15 Aug 2005 17:27:04 -0500
From: MathAction (unknown)
To: MathAction
Subject: [MuPAD] 

integrate(sin(x),x);

\start
Date: Wed, 17 Aug 2005 18:15:49 +0200
From: Kai Kaminski
To: list
Subject: AxiomUI code

Hi,

an early version of AxiomUI can be found on kaikaminski.gmxhome.de. The 
only dependency is Clisp. I use 2.34 but earlier version that are not 
too old should be fine. All Lisp libraries that are needed are contained 
in the tarball.

There is also a README with instructions. It should be as easy as 
starting a shell script.

\start
Date: Wed, 17 Aug 2005 20:28:19 +0200
From: Gregory Vanuxem
To: list
Subject: Re: AxiomUI code

Le mercredi 17 ao=FBt 2005 =E0 19:03 +0200, Vanuxem Gr=E9gory a =E9crit :
>
> -----Message d'origine-----
> De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
> part de Kai Kaminski
> Envoy=E9 : mercredi 17 ao=FBt 2005 18:16
> =C0 : list
> Objet : AxiomUI code
>
>
> Hi,
>
> an early version of AxiomUI can be found on kaikaminski.gmxhome.de. The
> only dependency is Clisp. I use 2.34 but earlier version that are not
> too old should be fine. All Lisp libraries that are needed are containe=
d
> in the tarball.
>
> There is also a README with instructions. It should be as easy as
> starting a shell script.
>
> Kai

Does not work for me.

A pb of split-sequence. Here is the output.

greg@ellipse:~/Desktop/axiomui-17-08-05/axiomui$ ./run.sh
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2005

;; Loading file run.lisp ...
;;  Loading
file /home/greg/Desktop/axiomui-17-08-05/axiomui/asdf.lisp ...
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS
FORMATTED-SYSTEM-DEFINITION-ERROR> #<BUILT-IN-CLASS T>)>
         dans #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION-ERROR> #<BUILT-IN-CLASS T>)>
         dans #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
MISSING-DEPENDENCY> #<BUILT-IN-CLASS T>)>
         dans #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
MISSING-COMPONENT> #<BUILT-IN-CLASS T>)>
         dans #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
COMPONENT>)> dans
          #<STANDARD-GENERIC-FUNCTION COMPONENT-SYSTEM>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
COMPONENT> #<BUILT-IN-CLASS T>)> dans
          #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
MODULE>)> dans
          #<STANDARD-GENERIC-FUNCTION COMPONENT-RELATIVE-PATHNAME>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
COMPONENT>)> dans
          #<STANDARD-GENERIC-FUNCTION COMPONENT-PATHNAME>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
COMPONENT> #<BUILT-IN-CLASS T>)> dans
          #<STANDARD-GENERIC-FUNCTION COMPONENT-PROPERTY>
         .
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<BUILT-IN-CLASS T> #<STANDARD-CLASS
COMPONENT> #<BUILT-IN-CLASS T>)>
         dans #<STANDARD-GENERIC-FUNCTION (SETF COMPONENT-PROPERTY)>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
COMPONENT> #<BUILT-IN-CLASS T>)> dans
          #<STANDARD-GENERIC-FUNCTION VERSION-SATISFIES>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
MODULE> #<BUILT-IN-CLASS T>)> dans
          #<STANDARD-GENERIC-FUNCTION FIND-COMPONENT>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD ((EQL NIL)
#<BUILT-IN-CLASS T>)> dans
          #<STANDARD-GENERIC-FUNCTION FIND-COMPONENT>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
CL-SOURCE-FILE> #<STANDARD-CLASS MODULE>)>
         dans #<STANDARD-GENERIC-FUNCTION SOURCE-FILE-TYPE>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
C-SOURCE-FILE> #<STANDARD-CLASS MODULE>)>
         dans #<STANDARD-GENERIC-FUNCTION SOURCE-FILE-TYPE>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS JAVA-SOURCE-FILE>
#<STANDARD-CLASS MODULE>)>
         dans #<STANDARD-GENERIC-FUNCTION SOURCE-FILE-TYPE>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
HTML-FILE> #<STANDARD-CLASS MODULE>)> dans
          #<STANDARD-GENERIC-FUNCTION SOURCE-FILE-TYPE>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
STATIC-FILE> #<STANDARD-CLASS MODULE>)>
         dans #<STANDARD-GENERIC-FUNCTION SOURCE-FILE-TYPE>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
SOURCE-FILE>)> dans
          #<STANDARD-GENERIC-FUNCTION COMPONENT-RELATIVE-PATHNAME>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<BUILT-IN-CLASS T>)> dans
          #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD :AFTER
(#<STANDARD-CLASS OPERATION> #<BUILT-IN-CLASS T>)>
         dans #<STANDARD-GENERIC-FUNCTION SHARED-INITIALIZE>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION>)> dans
          #<STANDARD-GENERIC-FUNCTION OPERATION-ANCESTOR>
         .
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS OPERATION>
#<STANDARD-CLASS COMPONENT> #<BUILT-IN-CLASS T>)>
         dans #<STANDARD-GENERIC-FUNCTION VISIT-COMPONENT>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION COMPONENT-VISITED-P>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<BUILT-IN-CLASS T> #<BUILT-IN-CLASS T>
#<BUILT-IN-CLASS T>)>
         dans #<STANDARD-GENERIC-FUNCTION (SETF VISITING-COMPONENT)>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<BUILT-IN-CLASS T> #<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION (SETF VISITING-COMPONENT)>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION COMPONENT-VISITING-P>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION COMPONENT-DEPENDS-ON>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION COMPONENT-SELF-DEPENDENCIES>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION INPUT-FILES>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS MODULE>)> dans
          #<STANDARD-GENERIC-FUNCTION INPUT-FILES>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION OPERATION-DONE-P>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION TRAVERSE>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS SOURCE-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS MODULE>)> dans
          #<STANDARD-GENERIC-FUNCTION PERFORM>
         .
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION EXPLAIN>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD :BEFORE (#<STANDARD-CLASS COMPILE-OP>
#<STANDARD-CLASS SOURCE-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD :AFTER (#<STANDARD-CLASS OPERATION>
#<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS COMPILE-OP>
#<STANDARD-CLASS CL-SOURCE-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS COMPILE-OP>
#<STANDARD-CLASS CL-SOURCE-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION OUTPUT-FILES>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS COMPILE-OP>
#<STANDARD-CLASS STATIC-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS COMPILE-OP>
#<STANDARD-CLASS STATIC-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION OUTPUT-FILES>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS LOAD-OP> #<STANDARD-CLASS
CL-SOURCE-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
LOAD-OP> #<STANDARD-CLASS STATIC-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
LOAD-OP> #<STANDARD-CLASS STATIC-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION OPERATION-DONE-P>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
OPERATION> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION OUTPUT-FILES>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
LOAD-OP> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION COMPONENT-DEPENDS-ON>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS LOAD-SOURCE-OP>
#<STANDARD-CLASS CL-SOURCE-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS LOAD-SOURCE-OP>
#<STANDARD-CLASS STATIC-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS LOAD-SOURCE-OP>
#<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION OUTPUT-FILES>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS LOAD-SOURCE-OP>
#<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION COMPONENT-DEPENDS-ON>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<STANDARD-CLASS LOAD-SOURCE-OP>
#<STANDARD-CLASS SOURCE-FILE>)>
         dans #<STANDARD-GENERIC-FUNCTION OPERATION-DONE-P>.
WARNING: On remplace la m=E9thode #<STANDARD-METHOD (#<STANDARD-CLASS
TEST-OP> #<STANDARD-CLASS COMPONENT>)>
         dans #<STANDARD-GENERIC-FUNCTION PERFORM>.
WARNING: On remplace la m=E9thode
          #<STANDARD-METHOD (#<BUILT-IN-CLASS SYMBOL> #<BUILT-IN-CLASS
T> #<BUILT-IN-CLASS T>)>
         dans #<STANDARD-GENERIC-FUNCTION HYPERDOCUMENTATION>.
;;  Loaded file /home/greg/Desktop/axiomui-17-08-05/axiomui/asdf.lisp
; loading system definition from axiom-hub.asd into #<PACKAGE ASDF8357>
;;  Loading file axiom-hub.asd ...
; registering #<SYSTEM AXIOM-HUB #x000333D17A70> as AXIOM-HUB
;;  Loaded file axiom-hub.asd
; loading system definition from cl-ppcre.asd into #<PACKAGE ASDF8693>
;;  Loading file cl-ppcre.asd ...
; registering #<SYSTEM #:CL-PPCRE #x000333D2FA40> as CL-PPCRE
;;  Loaded file cl-ppcre.asd
; loading system definition from cl-who.asd into #<PACKAGE ASDF8951>
;;  Loading file cl-who.asd ...
; registering #<SYSTEM #:CL-WHO #x000333D35E90> as CL-WHO
;;  Loaded file cl-who.asd
; loading system definition from cl-ajax.asd into #<PACKAGE ASDF8964>
;;  Loading file cl-ajax.asd ...
; registering #<SYSTEM CL-AJAX #x000333D9C3E8> as CL-AJAX
;;  Loaded file cl-ajax.asd
; loading system definition from araneida.asd into #<PACKAGE ASDF8969>
;;  Loading file araneida.asd ...
; registering #<SYSTEM ARANEIDA #x000333D1CA70> as ARANEIDA
;;  Loaded file araneida.asd
*** - component ARANEIDA-SYSTEM::SPLIT-SEQUENCE not found, required by
#<SYSTEM "araneida" #x000333D1CA70>
Rentr=E9es possibles:
SKIP           :R1      skip this form and proceed
STOP           :R2      stop loading file
ABORT          :R3      ABORT
Break 1 [2]>

\start
Date: Wed, 17 Aug 2005 21:00:08 +0200
From: Kai Kaminski
To: Gregory Vanuxem
Subject: Re: AxiomUI code

Vanuxem Grgory wrote:

>Le mercredi 17 aot 2005  19:03 +0200, Vanuxem Grgory a crit :
>  
>
>>-----Message d'origine-----
>>De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
>>part de Kai Kaminski
>>Envoy : mercredi 17 aot 2005 18:16
>> : list
>>Objet : AxiomUI code
>>
>>
>>Hi,
>>
>>an early version of AxiomUI can be found on kaikaminski.gmxhome.de. The
>>only dependency is Clisp. I use 2.34 but earlier version that are not
>>too old should be fine. All Lisp libraries that are needed are contained
>>in the tarball.
>>
>>There is also a README with instructions. It should be as easy as
>>starting a shell script.
>>
>>Kai
>>    
>>
>
>Does not work for me.
>
>A pb of split-sequence. Here is the output.
>
>  
>
Thanks for testing. I forgot to include some of the libraries. Should be 
fixed now.

\start
Date: Wed, 17 Aug 2005 22:02:06 +0200
From: Kai Kaminski
To: list
Subject: AxiomUI code update

Hi,

with Bob's help I found out that you need at least Axiom 3.4 to run my 
code. The April 2005 binaries on the Axiom site are that version. Maybe 
this should be mentioned on the download page.

Also don't forget to set the AXIOM environment variable as described in 
the README. Alternatively you could edit the Lisp source to get the 
pathnames right.

\start
Date: Wed, 17 Aug 2005 18:44:53 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: AxiomUI code update

Kai,

In your axiomui/README file you wrote:

> ...
> If you use Windows the software should work, but
> I can't tell you how to start it. Look at run.sh,
> run.lisp and axiom-hub.lisp for further info.

So I thought I would give it a try. First I installed
clisp-2.34 in a directory path with no spaces c:\clisp-2.34.
I added c:\clisp-2.34 to the executables PATH and made sure
that I could run in from the MSDOS command line.

I extracted your
 http://kaikaminski.gmxhome.de/axiomui-17-08-05.tgz
to c:\axiomui. Then I modified the run.sh to the following
run.bat file:

  set AXIOMUI_STATIC_PAGES="C:\axiomui\static-pages"
  clisp -norc -i run.lisp

------

Typing 'run' produced the following result:

C:\axiomui>run

C:\axiomui>set AXIOMUI_STATIC_PAGES="C:\axiomui\static-pages"

C:\axiomui>clisp -norc -i run.lisp
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2005

;; Loading file C:\axiomui\run.lisp ...
;;  Loading file C:\axiomui\asdf.lisp ...
;;  Loaded file C:\axiomui\asdf.lisp
*** - component "axiom-hub" not found
The following restarts are available:
SKIP           :R1      skip this form and proceed
STOP           :R2      stop loading file
ABORT          :R3      ABORT
Break 1 [2]>

----------

There seems to be something a little non-portable involving
paths and/or component names in Windows vs. Linux.

In run.lisp you wrote:

  (push #P"." asdf:*central-registry*)

Perhaps you need something involving (truename ".")
which returns a real Windows path?

But I don't know enough about clisp on Windows to really
Suggest what might be going wrong here.

Thanks for your hard work!

\start
Date: Wed, 17 Aug 2005 21:12:01 -0500
From: MathAction (unknown)
To: MathAction
Subject: [WishList] Avoid Octave use Scilab

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/

\start
Date: Thu, 18 Aug 2005 02:38:29 -0500
From: MathAction (unknown)
To: MathAction
Subject: [WishList] 

Yes but Scilab is NOT free software. One day or the other, you'll pay it (see the BitKeeper issue for Linux kernel).

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.

\start
Date: Thu, 18 Aug 2005 03:21:16 -0500
From: MathAction (unknown)
To: MathAction
Subject: [WishList] 

I believe you should also cite Q1 from the license FAQ:

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.

(sorry, couldn't find out how nested bullet point lists work)

\start
Date: Thu, 18 Aug 2005 04:44:12 -0500
From: MathAction (unknown)
To: MathAction
Subject: [WishList] 

This Q1 point reinforces my arguments: you cannot modify the software
without explicit INRIA's authorization. This is not Free Software. I
know that all members of Axiom community are not that sensible to Free
Software importance. However I personnally do believe that one cannot
build the 30 years horizon envisioned by Tim without using
**exclusively** Free Software (as defined by the 4 rules, not only
GPLed software). I would never invest time and knowledge in a
development where I'm not sure to keep long term control of it.

\start
Date: Thu, 18 Aug 2005 13:13:43 +0200
From: Kai Kaminski
To: Bill Page
Subject: Re: AxiomUI code update

Hi Bill,

thanks for trying this on Windows.

Page, Bill wrote:

>Kai,
>
>In your axiomui/README file you wrote:
>  
>
>>...
>>If you use Windows the software should work, but
>>I can't tell you how to start it. Look at run.sh,
>>run.lisp and axiom-hub.lisp for further info.
>>    
>>
>
>So I thought I would give it a try. First I installed
>clisp-2.34 in a directory path with no spaces c:\clisp-2.34.
>I added c:\clisp-2.34 to the executables PATH and made sure
>that I could run in from the MSDOS command line.
>
>I extracted your
> http://kaikaminski.gmxhome.de/axiomui-17-08-05.tgz
>to c:\axiomui. Then I modified the run.sh to the following
>run.bat file:
>
>  set AXIOMUI_STATIC_PAGES="C:\axiomui\static-pages"
>  clisp -norc -i run.lisp
>
>  
>
That seems to be right. Please do not forget to also set AXIOM though. 
Alternatively you could change the path to the AXIOMsys executable in 
AXIOM.LISP.

>Typing 'run' produced the following result:
>
>C:\axiomui>run
>
>C:\axiomui>set AXIOMUI_STATIC_PAGES="C:\axiomui\static-pages"
>
>C:\axiomui>clisp -norc -i run.lisp
>  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
>  I I I I I I I      8     8   8           8     8     o  8    8
>  I  \ `+' /  I      8         8           8     8        8    8
>   \  `-+-'  /       8         8           8      ooooo   8oooo
>    `-__|__-'        8         8           8           8  8
>        |            8     o   8           8     o     8  8
>  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8
>
>Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
>Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
>Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
>Copyright (c) Bruno Haible, Sam Steingold 1999-2000
>Copyright (c) Sam Steingold, Bruno Haible 2001-2005
>
>;; Loading file C:\axiomui\run.lisp ...
>;;  Loading file C:\axiomui\asdf.lisp ...
>;;  Loaded file C:\axiomui\asdf.lisp
>*** - component "axiom-hub" not found
>The following restarts are available:
>SKIP           :R1      skip this form and proceed
>STOP           :R2      stop loading file
>ABORT          :R3      ABORT
>Break 1 [2]>
>
>----------
>
>There seems to be something a little non-portable involving
>paths and/or component names in Windows vs. Linux.
>
>In run.lisp you wrote:
>
>  (push #P"." asdf:*central-registry*)
>
>Perhaps you need something involving (truename ".")
>which returns a real Windows path?
>  
>
That line might well be the problem. To see what you have to put there 
you should start Clisp and evaluate *DEFAULT-PATHNAME-DEFAULTS*, because 
that is what ASDF:*CENTRAL-REGISTRY* is initialized with. That should 
give you an idea of what to put there. I believe that TRUENAME only 
works on files. You could try to set another environment variable, 
AXIOMUI_ROOT say, that contains the right path and then use EXT:GETENV 
(see AXIOM.LISP) to push its content onto ASDF:*CENTRAL-REGISTRY*.

>But I don't know enough about clisp on Windows to really
>Suggest what might be going wrong here.
>  
>
I wish I could tell you more, but despite my best efforts I don't have a 
Windows machine to test. If you can get it to work please send me the 
RUN.BAT file, so that I can include it in the future.

If you have further troubles, I'm almost always on #axiom-developer.

\start
Date: Thu, 18 Aug 2005 08:34:26 -0500
From: MathAction (kai Kaminski)
To: MathAction
Subject: [Axiom In Emacs] 

<h3>Editing Axiom's Source Code</h3>

Emacs can be configured to make editing Axiom's source code much
easier. First of all you have to put <a
href="boot-mode.el"><tt>boot-mode.el</tt></a> and
<tt>noweb-mode.el</tt> (included in the noweb distribution, which in
turn is included in the Axiom distribution) into your
<tt>load-path</tt>. Then you add the following to your
<tt>.emacs</tt>:

<pre>
;; NOWEB-MODE
(require 'noweb-mode)

(defun kai:set-code-mode ()
  (let* ((filename (buffer-file-name)))
    (let ((end (string-match "\\.pamphlet" filename)))
      (noweb-set-code-mode
       (assoc-default (substring filename 0 end)
                      auto-mode-alist
                      'string-match
                      'fundamental-mode)))))

(add-hook 'noweb-mode-hook 'kai:set-code-mode)

;; BOOT-MODE
(require 'boot-mode)

;; AUTO-MODE-ALIST

(setq auto-mode-alist
      (list*
       '(".*\\.pamphlet" . noweb-mode)
       '(".*\\.boot" . boot-mode)
       '(".*\\.lisp" . lisp-mode)
       '(".*\\.c" . c-mode)
       auto-mode-alist))
</pre>

This code tries to automatically set the code mode in noweb, which
only works for files with names of the form
<tt>file.ext.pamphlet</tt>, where <tt>ext</tt> indicates the code
mode. For example, <tt>sockio.lisp.pamphlet</tt> would have its code
mode set to <tt>lisp-mode</tt> and <tt>nci.boot.pamphlet</tt> to
<tt>boot-mode</tt>. If the auto-detection can't decide on a mode it
uses <tt>fundamental-mode</tt>.

\start
Date: Thu, 18 Aug 2005 16:47:56 +0200
From: Martin Rubey
To: Kai Kaminski
Subject: Re: AxiomUI code

Dear Kai,

unfortunaltely, I can't get it to work.

Using Version: Axiom 3.6 (June 2005) I get

[rubey@seam101 axiomui]$ ./run.sh
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2002

;; Loading file run.lisp ...
;;  Loading file /home/rubey/Documents/axiomui/asdf.lisp ...
;;  Loaded file /home/rubey/Documents/axiomui/asdf.lisp

*** - ; FUNCALL: the function ; NIL is undefined
; 1. Break ; [; 1]> :bt

EVAL frame for form
; (FORMAT ASDF::*VERBOSE-OUT* ~A~@:>~%" ASDF::ON-DISK *PACKAGE*)
EVAL frame for form ; (LET (:ASDF)))) *PACKAGE*) ASDF::ON-DISK))
EVAL frame for form ; (WHEN ASDF::ON-DISK)))) ASDF::ON-DISK)))
EVAL frame for form ; (LET* ASDF::NAME))) ASDF::ON-DISK))) ASDF::NAME)))))
APPLY frame for call (; FIND-SYSTEM '; COMMON-LISP-USER::AXIOM-HUB)
EVAL frame for form ; (FIND-SYSTEM SYSTEM)
EVAL frame for form ; (IF 'COMPONENT) SYSTEM SYSTEM))
EVAL frame for form
; (LET*
;  ((ASDF::OP
;  (APPLY #'MAKE-INSTANCE ASDF::OPERATION-CLASS :ORIGINAL-INITARGS ASDF::ARGS
;  ASDF::ARGS))
;  (MAKE-BROADCAST-STREAM))) SYSTEM))) SYSTEM)))
;  (LET *ERROR-OUTPUT*)) (SYSTEM::C-REPORT-PROBLEMS))
;  (PROGV
;  (WHEN SYSTEM::*C-TOP-CALL*
;  '(SYSTEM::*ERROR-COUNT* SYSTEM::*WARNING-COUNT*
;  SYSTEM::*STYLE-WARNING-COUNT*))
;  0))
;  (UNWIND-PROTECT
;  (LET (NIL))
;  (LET (ASDF::STEPS))
;  (TAGBODY SYSTEM::BEGIN-LOOP
;  (PROGN SYSTEM::END-LOOP))
;  (LET #:G693)))
;  (BLOCK NIL
;  (TAGBODY #:G694
;  (BLOCK #:G697
;  (LET (#:G698)
;  (TAGBODY
;  (LET*
;  ((SYSTEM::*ACTIVE-RESTARTS*
;  (LIST*
;  (SYSTEM::MAKE-RESTART :NAME 'RETRY :INVOKE-FUNCTION
;  #'(LAMBDA SYSTEM::ARGUMENTS) #:G695)))) SYSTEM::ARGUMENTS)
;  #:G695))
;  :REPORT COMPONENT)))
;  (SYSTEM::MAKE-RESTART :NAME 'ACCEPT :INVOKE-FUNCTION
;  #'(LAMBDA SYSTEM::ARGUMENTS) #:G696)))) SYSTEM::ARGUMENTS)
;  #:G696))
;  :REPORT
;  #'(LAMBDA (ASDF::S)
;  (DECLARE
;  (SYSTEM::SOURCE
;  ((ASDF::S)
;  (FORMAT ASDF::S
;  "~@<Continue, treating ~S on ~S as ~
;                             having been successful.~@:>"
;  ASDF::OP COMPONENT))))
;  (FORMAT ASDF::S
;  "~@<Continue, treating ~S on ~S as ~
;                             having been successful.~@:>"
;  ASDF::OP COMPONENT)))
;  SYSTEM::*ACTIVE-RESTARTS*)))
;  NIL))))
;  #:G695 #:G698)) #:G696 #:G698)))))
;  #:G694)))))
;  #:G692)) SYSTEM::BEGIN-LOOP) SYSTEM::END-LOOP)))
;  (SYSTEM::C-REPORT-PROBLEMS))))))
APPLY frame for call (; OPERATE '; LOAD-OP '; COMMON-LISP-USER::AXIOM-HUB)
EVAL frame for form ; (APPLY #'OPERATE ASDF::ARGS)
APPLY frame for call (; OOS '; LOAD-OP '; COMMON-LISP-USER::AXIOM-HUB)
EVAL frame for form ; (OOS 'LOAD-OP 'COMMON-LISP-USER::AXIOM-HUB)
Printed ; 11 frames
; 1. Break ; [; 1]>

Kai Kaminski writes:
 > Hi,
 > 
 > an early version of AxiomUI can be found on kaikaminski.gmxhome.de. The 
 > only dependency is Clisp. I use 2.34 but earlier version that are not 
 > too old should be fine. All Lisp libraries that are needed are contained 
 > in the tarball.
 > 
 > There is also a README with instructions. It should be as easy as 
 > starting a shell script.

\start
Date: Thu, 18 Aug 2005 17:15:36 +0200
From: Martin Rubey
To: Kai Kaminski
Subject: Re: AxiomUI code

clisp --version
GNU CLISP 2.30 (released 2002-09-15) (built on klama.mandrake.org)
Features:
(CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS
 GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI UNICODE BASE-CHAR=CHARACTER PC386
 UNIX)


Kai Kaminski writes:
 > 
 > Hi Martin,
 > 
 > thanks a lot for trying.  Since it seems to fail rather early it might
 > be an incompatibility between ASDF and your version of Clisp. Could
 > you please tell me what 'clisp --version' says?
 > 
 > Next time I'll instrument my code with more debug code, so that this
 > kind of information is automatically included in the output.
 > 
 > Thanks,
 > Kai

\start
Date: Thu, 18 Aug 2005 18:22:14 +0200
From: Kai Kaminski
To: Martin Rubey
Subject: Re: AxiomUI code

Martin,

thanks for the quick reply.

Martin Rubey writes:

> clisp --version
> GNU CLISP 2.30 (released 2002-09-15) (built on klama.mandrake.org)
> Features:
> (CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS
>  GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI UNICODE BASE-CHAR=CHARACTER PC386
>  UNIX)

This is definitely a problem. The (somewhat related) ASDF-INSTALL
tutorial from Edi Weitz says the following:

Note: CLISP 2.32 cannot compile ASDF due to being not fully
ANSI-compliant. You can download a compiled version (which should work
with all operating systems supported by CLISP) from
http://weitz.de/files/asdf.fas. Newer versions (like 2.33.2) can
compile ASDF, though.


It should be enough to download that asdf.fas file from him and put it
in the same directory as run.sh, but since installing Clisp is really
easy I'd recommend that. Maybe your distribution offers newer
versions, too. The newest version is 2.34, but 2.33.2 should work as I
have used that myself in the past.

\start
Date: Thu, 18 Aug 2005 23:08:25 +0200
From: Kai Kaminski
To: list
Subject: Function definition crashes Axiom

Hi everyone,

I'm currently rebuilding parts of the HyperDoc documentation. One page
(ug06.[p]ht) contains the following commands:

addx x == ((y: Integer): Integer +-> x + y)

g := addx 10

When I enter those commands at the Axiom toplevel, Axiom crashes due
to a segmentation fault. I'm using version 3.8 (patch-43) freshly
built on Ubuntu 5.04. I'm pretty sure that I haven't modified the
source code prior to compiling it, but I'll rebuild it to be sure, if
noone else has this problem.

\start
Date: Thu, 18 Aug 2005 15:48:22 -0700
From: Bob McElrath
To: Kai Kaminski
Subject: Re: Function definition crashes Axiom

Kai Kaminski [Kai Kaminski] wrote:
> 
> Hi everyone,
> 
> I'm currently rebuilding parts of the HyperDoc documentation. One page
> (ug06.[p]ht) contains the following commands:
> 
> addx x == ((y: Integer): Integer +-> x + y)
> 
> g := addx 10
> 
> When I enter those commands at the Axiom toplevel, Axiom crashes due
> to a segmentation fault. I'm using version 3.8 (patch-43) freshly
> built on Ubuntu 5.04. I'm pretty sure that I haven't modified the
> source code prior to compiling it, but I'll rebuild it to be sure, if
> noone else has this problem.

On both axiom 3.0 and 3.4 these two commands also segfault.

So, I don't think it's you.  ;)

\start
Date: Fri, 19 Aug 2005 03:47:04 +0200
From: Kai Kaminski
To: list
Subject: Broken link on front page

The link to the issue tracker on the front page is broken. While the
path is correct, it points to localhost, which won't work in most
cases.

\start
Date: Fri, 19 Aug 2005 06:07:37 -0500
From: MathAction (starseeker)
To: MathAction
Subject: [#198 integrate(sin(x**2),x) is not handled ] Hmm - formatting of text failed

\begin{axiom}
integrate(sin(x**2),x)
\end{axiom}

\start
Date: Fri, 19 Aug 2005 06:06:01 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#198 integrate(sin(x**2),x) is not handled ] (new) 

Axiom doesn't seem to do the integral of sin(x^2), but both Maxima and
Mathematica (per http://integrals.wolfram.com/ anyway) produce
answers.  Confirmed by Martin Rubey, and uploaded at his request to
IssueTracker.

CY

                        AXIOM Computer Algebra System 
                        Version: Axiom 3.6 (June 2005)
                Timestamp: Wednesday July 27, 2005 at 12:16:43 
 
-----------------------------------------------------------------------------
    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
 (1) -> 
 (1) -> integrate(sin(x**2),x)
       UserDefinedPartialOrdering 
            x
          ++        2
    (1)   |   sin(%I )d%I
         ++
                                           Type: Union(Expression
 Integer,...)
 (2) -> 
 
 
 Maxima 5.9.1.1cvs http://maxima.sourceforge.net
 Using Lisp CMU Common Lisp 19b (19B)
 Distributed under the GNU Public License. See the file COPYING.
 Dedicated to the memory of William Schelter.
 This is a development version of Maxima. The function bug_report()
 provides bug reporting information.
 (%i1) integrate(sin(x**2),x);
                                             (sqrt(2) %i + sqrt(2)) x
 (%o1) sqrt(%pi) ((sqrt(2) %i + sqrt(2)) erf(------------------------)
                                                        2
                                     (sqrt(2) %i - sqrt(2)) x
        + (sqrt(2) %i - sqrt(2)) erf(------------------------))/8
                                                2
 (%i2)

\start
Date: Fri, 19 Aug 2005 13:43:35 +0200
From: Martin Rubey
To: list
Subject: Re: integration

I'm resending this because I'm not sure whether it got through...

Thank you!

C Y writes:
 > Well, I tried :-).  Formatting is a hash, I'm afraid - is there a way
 > to paste formatted text I missed?

Yes, just look at the edited text. "::" + indented text is our friend.

and thanks again for spotting the bug. Now: go ahead and fix it :-) A starting
point might be the following:

)tr FSCINT )math
)tr  INTEF )math
)tr INTTR )math
)tr INTAF )math
)tr INTPM )math
)tr INTALG  )math

integrate(sin(x^2),x)

If you know the Risch algorithm, you can certainly spot the point where it
should have done something but didn't do :-)

Unfortunately Manuel Bronstein died. I don't know anybody who would be able to
document these routines.

\start
Date: Fri, 19 Aug 2005 13:40:47 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: integration

Thank you!

C Y writes:
 > Well, I tried :-).  Formatting is a hash, I'm afraid - is there a way
 > to paste formatted text I missed?

Yes, just look at the edited text. "::" + indented text is our friend.

and thanks again for spotting the bug. Now: go ahead and fix it :-) A starting
point might be the following:

)tr FSCINT )math
)tr  INTEF )math
)tr INTTR )math
)tr INTAF )math
)tr INTPM )math
)tr INTALG  )math

integrate(sin(x^2),x)

If you know the Risch algorithm, you can certainly spot the point where it
should have done something but didn't do :-)

Unfortunately Manuel Bronstein died. I don't know anybody who would be able to
document these routines.

\start
Date: Fri, 19 Aug 2005 06:32:35 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: Re: integration

> Thank you!
> 
> C Y writes:
>  > Well, I tried :-).  Formatting is a hash, I'm afraid - is there a
> way
>  > to paste formatted text I missed?
> 
> Yes, just look at the edited text. "::" + indented text is our
> friend.

Ah :-).

> and thanks again for spotting the bug. Now: go ahead and fix it :-)

No problem - I'm beginning to think Axiom is where the most interesting
work on CAS will occur.  I suspect you came to this conclusion long
ago, but I'm beginning to think the Maxima source code will require
such a determined effort to improve to a decent point that it might be
best to just impliment all the features it has that Axiom doesn't in
Axiom.  I'm finding myself posting suggestions that look remarkably
like the ones you were making early on, and at some point after that
(IIRC) you popped up on the Axiom lists :-).  I sense a pattern... 
although I must say I prefer Maxima's ASCII display to Axiom's, at
least for easy reading.  I wonder how hard that would be to impliment?

Re: fixing bug - Well, I can give it a shot if it's simple to find... 
I've got some learning to do though.  Me thinks the Risch algorithm
would be a rather ambitious way to try getting the hang of the Axiom
source code...

> A starting point might be the following:
> 
> )tr FSCINT )math
> )tr  INTEF )math
> )tr INTTR )math
> )tr INTAF )math
> )tr INTPM )math
> )tr INTALG  )math
> 
> integrate(sin(x^2),x)
> 
> If you know the Risch algorithm, you can certainly spot the point
> where it should have done something but didn't do :-)

Ah, yes - the Risch algorithm.  Do you happen to know if the full
algorithm is described online anywhere?  Ideally both Risch's algorithm
and the extensions by Cherry et. al. for special functions would be
formally implimented (or documented since a fair part of it must
already be present.)  Apparently nobody impliments the full algorithm
due to complexity?:  http://mathworld.wolfram.com/RischAlgorithm.html  
I wonder if it's too complex for the Axiom system, given the structure
it has in place.  I've never studied it, but given how critical it is
to both systems it's high time I learned about it.

> Unfortunately Manuel Bronstein died. I don't know anybody who would
> be able to document these routines.

Well, when the great fall the lesser must pick up the torch.  I need to
get ahold of some basic materials (Bronstein's books would be useful,
I'd wager :-) and get as much up to speed as my brain allows.  I need
to learn Axiom's guts anyway and this sounds like a possibly useful
way.  Maybe I could warm up by implimenting a physical units domain in
Axiom, although lord knows how I'd convince it to display things in the
form (numbers and variables)*units, or recognize Newtons out of
a*kg*b*s^-2*c*m.  Does Axiom have provisions for non-standard display
conventions and substitution like that?

\start
Date: Fri, 19 Aug 2005 15:54:21 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: integration

C Y writes:

 > Re: fixing bug - Well, I can give it a shot if it's simple to find... 

Well, what you need to find out is how the Risch algorithm would handle
sin(x^2). Maybe it is simply handled by pattern matching, as exp(-x^2) is... In
this case, fixing it would be easy. Mathematica also has a representation for
sin(x^n), but I don't know whether it is "useful". (It's in terms of incomplete
Gamma functions)

 > I've got some learning to do though.  Me thinks the Risch algorithm
 > would be a rather ambitious way to try getting the hang of the Axiom
 > source code...

Note that Axioms source is very nicely split into two parts: the "Algebra",
implementing its mathematical capabilities, and the rest (compiler,
interpreter, display, graphics, ...)

 > Ah, yes - the Risch algorithm.  Do you happen to know if the full
 > algorithm is described online anywhere?  Ideally both Risch's algorithm
 > and the extensions by Cherry et. al. for special functions would be
 > formally implimented (or documented since a fair part of it must
 > already be present.)  Apparently nobody impliments the full algorithm
 > due to complexity?:  http://mathworld.wolfram.com/RischAlgorithm.html  
 > I wonder if it's too complex for the Axiom system, given the structure
 > it has in place.  I've never studied it, but given how critical it is
 > to both systems it's high time I learned about it.

If you are interested, it's certainly worth the effort.

 > > Unfortunately Manuel Bronstein died. I don't know anybody who would
 > > be able to document these routines.
 > 
 > Well, when the great fall the lesser must pick up the torch.  

With some luck (and brains), the lesser become great that way.

 > I need to get ahold of some basic materials (Bronstein's books would be
 > useful, I'd wager :-) and get as much up to speed as my brain allows.  I
 > need to learn Axiom's guts anyway and this sounds like a possibly useful
 > way.  Maybe I could warm up by implimenting a physical units domain in
 > Axiom, although lord knows how I'd convince it to display things in the form
 > (numbers and variables)*units, or recognize Newtons out of a*kg*b*s^-2*c*m.
 > Does Axiom have provisions for non-standard display conventions and
 > substitution like that?

Output is easy. 

)sh OUTFORM

tells you everything you want to know about it.

Pattern matching is there too. 

)sh PATMATCH

or rather, use HyperDoc.

\start
Date: Fri, 19 Aug 2005 07:27:28 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: Re: integration

--- Martin Rubey wrote:

> Output is easy. 
> 
> )sh OUTFORM
> 
> tells you everything you want to know about it.

Um:  

)sh OUTPUT
   The )show system command is used to display information about types 
      or partial types. For example, )show Integer will show 
      information about Integer .
      OUTPUT is not the name of a known type constructor. If you want 
      to see information about any operations named OUTPUT , issue
                         )display operations OUTPUT

 
> Pattern matching is there too. 
> 
> )sh PATMATCH

Hmm - I'll need to think about this a bit.  A few examples would help
:-).

\start
Date: Fri, 19 Aug 2005 11:47:19 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: Broken link on front page

Kai,

Thanks for the note.

On August 18, 2005 9:47 PM you wrote:

> The link to the issue tracker on the front page is broken.
> While the path is correct, it points to localhost, which
> won't work in most cases.

There are two links to issue tracker on the MathAction front
page. In the header 'issues' is a link to
http://www.axiom-developer.org/zope/mathaction/IssueTracker

and later the text "please report it" has a link to
http:/zope/mathaction/FrontPage/issuetracker which should
default to http://www.axiom-developer.org/...

I am not sure why these link to different versions of the
issuetracker page but they both work the same way for me.

What do you mean by "points to localhost"? What browser are
you using? In the HTML code the second link is coded as:
<a href="http:/zope/mathaction/FrontPage/issuetracker">please report
it</a>
which as I understand it is supposed to default to the current
machine, but might be interpreted incorrectly in some browsers
(I thought that odd behaviour was fixed long ago in most browsers.)
Anyway I will change the link to
<a href="/zope/mathaction/FrontPage/issuetracker">please report it</a>
which should work for everyone.

\start
Date: Fri, 19 Aug 2005 11:13:27 -0500
From: MathAction (Bob McElrath)
To: MathAction
Subject: [#198 integrate(sin(x**2),x) is not handled ] (new)

It's worth noting that both Maple and Mathematica produce the FresnelS
function, which is *defined* in terms of this integral.  However, the
Maxima answer appears to be correct as well.

\start
Date: Fri, 19 Aug 2005 19:12:36 +0200
From: Kai Kaminski
To: Bill Page
Subject: Re: Broken link on front page

Bill,

Bill Page writes:

> On August 18, 2005 9:47 PM you wrote:
>
>> The link to the issue tracker on the front page is broken.
>> While the path is correct, it points to localhost, which
>> won't work in most cases.
>
> There are two links to issue tracker on the MathAction front
> page. In the header 'issues' is a link to
> http://www.axiom-developer.org/zope/mathaction/IssueTracker
>
> and later the text "please report it" has a link to
> http:/zope/mathaction/FrontPage/issuetracker which should
> default to http://www.axiom-developer.org/...
This one was broken.

> What do you mean by "points to localhost"? What browser are
> you using? In the HTML code the second link is coded as:
> <a href="http:/zope/mathaction/FrontPage/issuetracker">please report
> it</a>
> which as I understand it is supposed to default to the current
> machine, but might be interpreted incorrectly in some browsers
> (I thought that odd behaviour was fixed long ago in most browsers.)
I used Safari or Firefox, don't remember. But an hour or so after I
reported this, the link worked again. I just checked to be sure and
both links work in Safari.

\start
Date: Fri, 19 Aug 2005 13:56:07 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: Unit package question

Hi all.  I have a rather odd question, and I don't know if this is
something Axiom even will permit, but it would be useful to know, so...

I want to be able to teach Axiom how to use units.  There are a number
of surprisingly annoying features to handle based on my experience with
Maxima, and one of the worst is the following:

If I enter an expression, Axiom automatically formats it and orders it
according to internal rules.  See
http://www.axiom-developer.org/zope/mathaction/SandBox#msg20050819154916-0500@www.axiom-developer.org
for an example of this.  Normally, this is what one wants to do.  What
I'm not sure of is how to instruct Axiom to display things that are
Units at the end of an expression, e.g.

        kg*m
a*b*z  ------
          2
         s

In Maxima it requires some rather alarming hackery with the display
code to avoid the same default behavior Maxima exhibits.  In one sense
Axiom is an ideal place for certain types of unit operations, since I
can presumably do things like assign both inches and meters the type
Length, and assign simplification rules accordingly :-). but I don't
know how to impliment the display logic above.  Based on the Maxima
experience, I'm guessing the infastructure might not be in place to
support something like this, given it is rather non-standard in normal
mathematical environments.  Is there anybody who knows what the correct
approach to this would be?

\start
Date: Fri, 19 Aug 2005 20:53:26 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Unit package question

Here are few initial ideas about how I think units might
be implemented in Axiom.

On August 19, 2005 4:56 PM C Y wrote:

> Hi all.  I have a rather odd question, and I don't know if
> this is something Axiom even will permit, but it would be
> useful to know, so...
>
> I want to be able to teach Axiom how to use units.

For scientific applications of Axiom, I think units might be
very useful. My first reaction however is to try to imagine
what part of Axiom might be most suitable to represent the
concept of units.

> There are a number of surprisingly annoying features to handle
> based on my experience with Maxima, and one of the worst is
> the following:
>
> If I enter an expression, Axiom automatically formats it and
> orders it according to internal rules.  See
http://www.axiom-developer.org/zope/mathaction/SandBox#msg20050819154916
-0500@www.axiom-developer.org

> for an example of this.  Normally, this is what one wants to do.

I think what you are doing here is ok in Maxima, Maple and
Mathematica but it does not fit well in Axiom. I think it might
be quite awkward to treat units as expressions of this kind in
Axiom.

> What I'm not sure of is how to instruct Axiom to display things
> that are Units at the end of an expression, e.g.
>
>         kg*m
> a*b*z  ------
>           2
>          s

What makes Axiom different is it's strong type system and it's
object-orientation. To me this suggests that units in Axiom
might be best implemented as extensions of the Float domain.
By this I mean we should be able to write something like this:

(1) ->  (2.0::kg + 1.0::lb)::ton

   (1)  0.0027
                      Type: ton

where kg, lb and ton are Axiom domains. Given the right
definitions of these domains we should expect that Axiom would
perform the necessary coercion/conversion from the domains
kg and lb to ton, the same as if we had written:

(2) -> (2.0::Float + 1.0::INT)::SF

   (2)  3.0
                      Type: DoubleFloat

To implement something like:

(3) -> 2.0::m * 3.1::kg

          6.1
                      Type: m*kg

Axiom will have to be told how to multiply meters by kilograms.
This is easily done given Axiom function overloading. Add of
course Axiom needs to know how to construct new units (types)
from old ones. Since types are first order objects in Axiom,
this is also quite easy.

> In Maxima it requires some rather alarming hackery with the
> display code to avoid the same default behavior Maxima exhibits.
> In one sense Axiom is an ideal place for certain types of unit
> operations, since I can presumably do things like assign both
> inches and meters the type Length, and assign simplification
> rules accordingly :-).

Perhaps you are confusing the notion of 'dimension' and 'unit'
here but still I think these ideas both map quite well to
Axiom's type system. For example

(4) -> 1.0::m + 2.0::s

would constitue a type error.

> but I don't know how to impliment the display logic above.
> Based on the Maxima experience, I'm guessing the infastructure
> might not be in place to support something like this, given
> it is rather non-standard in normal mathematical environments.

The display of units as types, e.g.

                      Type: m*kg

should be possible, although I think there my currently be
some built-in assumptions about type expressions that might
currently preclude this nice infix notation. But a type such
as

                      Type: Prod(m,kg)

is certainly possible.

> Is there anybody who knows what the correct approach to this
> would be?

Maple has an elaborate Scientific units and dimension system
that even takes advantage of overloading operations like + * /
such as I suggested above, although Maple does not really have
the notion of strong typing. If you have the opportunity to study
how this was done in Maple perhaps it will suggest a possible
approach in Axiom.

These are just some rough initial ideas. I am not sure how
well this concept of "units as types" will work out in
detail.

\start
Date: Fri, 19 Aug 2005 20:29:50 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Unit package question

> Here are few initial ideas about how I think units might
> be implemented in Axiom.
> 
> For scientific applications of Axiom, I think units might be
> very useful. My first reaction however is to try to imagine
> what part of Axiom might be most suitable to represent the
> concept of units.

It's most likely non-trivial - I've got some digging to do into Axiom
programming philosophy.  I'll try to describe what I had envisioned in 
my mind's eye, and perhaps it will emerge what it would take to teach
Axiom to work with the new concepts.
 
> > There are a number of surprisingly annoying features to handle
> > based on my experience with Maxima, and one of the worst is
> > the following:
> >
> > If I enter an expression, Axiom automatically formats it and
> > orders it according to internal rules.  See
>
http://www.axiom-developer.org/zope/mathaction/SandBox#msg20050819154916
> -0500@www.axiom-developer.org
> 
> > for an example of this.  Normally, this is what one wants to do.
> 
> I think what you are doing here is ok in Maxima, Maple and
> Mathematica but it does not fit well in Axiom. I think it might
> be quite awkward to treat units as expressions of this kind in
> Axiom.

Possibly - I'm not really sure myself yet.  But as I'll explain below
there are reasons for this approach.

> > What I'm not sure of is how to instruct Axiom to display things
> > that are Units at the end of an expression, e.g.
> >
> >         kg*m
> > a*b*z  ------
> >           2
> >          s
> 
> What makes Axiom different is it's strong type system and it's
> object-orientation. To me this suggests that units in Axiom
> might be best implemented as extensions of the Float domain.

The logic of units certainly has some similarities, but one needs to be
careful because there are a fair number of unique options one would
want to have with units.  I'm not sure, on closer analysis, that Floats
are really all that good a match.  I'll try to give a couple examples
below.

> By this I mean we should be able to write something like this:
> 
> (1) ->  (2.0::kg + 1.0::lb)::ton
> 
>    (1)  0.0027
>                       Type: ton
> 
> where kg, lb and ton are Axiom domains. Given the right
> definitions of these domains we should expect that Axiom would
> perform the necessary coercion/conversion from the domains
> kg and lb to ton, the same as if we had written:
> 
> (2) -> (2.0::Float + 1.0::INT)::SF
> 
>    (2)  3.0
>                       Type: DoubleFloat

The problem with this is there would have to be one type/domain for
EVERY SINGLE UNIT we wished to define.  When one includes the metric
prefix system, this can include a LOT of types/domains. Conceptually, I
think it would be more elegant to have Axiom recognize a) a unit is in
an expression b) determine the dimension of each unit and confirm the
expression is dimensionally legal and c) depending on options return
either i) the unsimplified combination of legal terms ii) the
simplified expression according to a global set of user chosen standard
units (MKS by default) or iii) if non-basic dimensions like Force are
enabled, and an expression simplifies to such a dimensional type or a
combination of higher order types, simplify to the most compact form
available.  Of course, this might not be at all elegant in Axiom as it
currently exists, but here's a mockup session of what I'd like to see:

(1) -> (2.0::kg + 1.0::lb)::kg
     Error - incompatible dimensions for Add operation

(1) -> (2.0::kg + 1.0::slugs)::kg

    (1)  3.45939 kg
                                  Type: Mass
(2) -> (2.0::kg + 1.0::slugs)::slugs

    (2)  2.3704355929 53220181 slugs
                                  Type: Mass

Ideally I'd also like Axiom to be able to deal with (2.0*kg +
1.0*slugs)::kg as well, but I don't know if that would be legal or not.
 Conceptually at least, 2.0*kg and 2.0::kg are the same thing.  I'll
add more mockups below as they seem relevant.

> To implement something like:
> 
> (3) -> 2.0::m * 3.1::kg
> 
>           6.1
>                       Type: m*kg
> 
> Axiom will have to be told how to multiply meters by kilograms.
> This is easily done given Axiom function overloading. Add of
> course Axiom needs to know how to construct new units (types)
> from old ones. Since types are first order objects in Axiom,
> this is also quite easy.

I would like to see this feature handle things as follows (I don't know
enough about the type system to know if it could do this yet)

(3) -> (4.0::kg * 3.0::m / 6::s**-2)

             kg m
   (3)  2.0  ----
               2
              s
                                  Type: Mass*Length/Time^2
(4) -> ActivateExtendedUnitTypes(MKS)
        
   (4)  True      (not sure what the "standard" way to do this is)
                                  Type: Bool
(5) -> (4.0::kg * 3.0::m / 6::s**-2)

   (5)  2 N
                                  Type: Force
(6) -> (4.0::kg * 3.0::m / 6::s**-2)::dyn

   (6)  200000 dyn
                                  Type: Force
(7) -> (a::N)::dyn

   (7)  100000 a dyn
                                  Type: VariableForce

There are many other variations on what a user might want - for
example, after doing some calculations in N or dyne they may want to
render their forces in base units, but cm*g/minute^2 rather than MKS. 
Options to set defaults for and override locally all of these
simplifications are needed.  Assignment checking is also needed - for
example, in the last example above a should only be assigned quantities
of type Force.  However, any Force type is legal and should be accepted
and converted as controlled by settings.

> Perhaps you are confusing the notion of 'dimension' and 'unit'
> here

Possibly - I get a bit loose with my terminology sometimes, which won't
do in the Axiom world :-).  To be clear - each unit is associated with
a dimension, and I would like to see the rules governing unit
interactions work on the dimension level, while handling the conversion
between different units with the same dimension automatically based on
circumstances as determined by either default settings or the user's
preferences.

> but still I think these ideas both map quite well to
> Axiom's type system. For example
> 
> (4) -> 1.0::m + 2.0::s
> 
> would constitute a type error.

Right - essentially Axiom's strict typing gives us a chance to have
dimensional analysis as part of all calculations :-).  

> The display of units as types, e.g.
> 
>                       Type: m*kg
> 
> should be possible, although I think there my currently be
> some built-in assumptions about type expressions that might
> currently preclude this nice infix notation. But a type such
> as
> 
>                       Type: Prod(m,kg)
> 
> is certainly possible.

Right, but as I showed in my examples above my preference is for the
units to remain as a displayed part of the expression, and the Type
information to report the dimension of the quantity in question.  This
seems to me to be the most useful thing to do.
 
> > Is there anybody who knows what the correct approach to this
> > would be?
> 
> Maple has an elaborate Scientific units and dimension system
> that even takes advantage of overloading operations like + * /
> such as I suggested above, although Maple does not really have
> the notion of strong typing. If you have the opportunity to study
> how this was done in Maple perhaps it will suggest a possible
> approach in Axiom.

I have looked at the Maple package, and indeed they use many similar
ideas to ones I had arrived at (after much trial and error) in the
Maxima design.  (Boy was that embarassing - a real lesson to do my
homework before beating my head against the nearest wall!)  How it's
ideas map into Axiom's strong typing system is, unfortunately, the real
nut to crack.  Axiom's system offers some exciting possibilities, but
it looks like there might be some roadblocks to plow through too.

I should mention that Maple has the idea of things like (IIRC) unit
space where expressions are encapsulated in a Units() denotation, e.g.
4*z*Units(kg*m/s^2).  This was rejected for the Maxima package - we
felt that the program should be able to handle the "textbook"
                        kg*m
formatting style of 4*z ---- since this is the convention used 
                          2
                         s
almost universally in the sciences (who are most likely to be dealing
with units.)  I have the same hope for Axiom - units, as multiplicative
factors, remaining part of the expression, and the Type information
working on the dimension level.  (As in my examples above.)

> These are just some rough initial ideas. I am not sure how
> well this concept of "units as types" will work out in
> detail.

It might be that that would be the best "mapping" of the idea onto
Axiom's system, although aesthetically I prefer the idea of working
with dimensions and units providing the multiplicative factors for
conversion between each other.  Discussion welcome.

Cheers,
CY

P.S. - there's also the whole idea of error analysis which enters into
this equation - for example, when discussing physical quantities 2.0
has a significance - you are implying a greater measurement accuracy
than just stating 2.  So there may be a collision in the future between
float and integer behavior in Axiom and the handling of accuracy.  For
example, if I have a measurement of 10+-2 and I subtract the quantity
4.0007+-0.0005, the proper return (if I've got this right - it's been a
while) would be 6+-2, since error analysis combining the two errors
would result in 2 + <small amount>, and significant figure rules say to
chop off the <small amount>.  Anyway, there are rules governing such
things and I suspect there might be a collision between those and
"normal" mathematical convention, where all things are exact.  Then
there's the whole issue of errors introduced by the CAS itself, due to
precision limits and such. But that's for another day.

\start
Date: Sat, 20 Aug 2005 08:52:48 +0200
From: Magnus Larsson
To: list
Subject: Building axiom--main--1--patch-44 fails

Hello list

I checked out Axiom using:
tla get axiom--main--1

I can not get the build to complete.

cd axiom--main--1--patch-44
./configure
export AXIOM=/home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/mnt/linux
export PATH=$AXIOM/bin:$PATH
make

causes the build process to hang(?)

I have tried to restart the build by stopping all processes
and starting make again.

The build hangs again, same place:

<snip>
==================================
=== layer 22 of 23 complete ======
==================================
==================================
=== layer 23 of 23 complete ======
==================================
==================================
=== layer 0 copy complete ======
==================================
4304 Building NRLIBS from spad sources
4302 
finished /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/algebra
make[3]: Leaving directory 
`/home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/algebra'
37 making /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/etc
make[3]: Entering directory 
`/home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/etc'
6 finished /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/etc
make[3]: Leaving directory 
`/home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/etc'
5 making /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/clef
make[3]: Entering directory 
`/home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/clef'
6 finished /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/clef
make[3]: Leaving directory 
`/home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/clef'
41 making /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/doc
make[3]: Entering directory 
`/home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/doc'
3 
making /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/mnt/linux/doc/DeveloperNotes.dvi 
from /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/doc/DeveloperNotes.pamphlet
/bin/sh: line 0: [: too many arguments
                                            
All I get is "/bin/sh: line 0: [: too many arguments..". 
The make script does not seem to complete and return to the bash shell
and give me the cursor back. It just waits.

uname -a
Linux lfs 2.6.12 #1 Sat Jun 18 20:54:49 CEST 2005 i686 pentium4 i386 GNU/Linux

\start
Date: Sat, 20 Aug 2005 16:20:43 +0700 (NOVST)
From: Andrey G. Grozin
To: Magnus Larsson
Subject: Re: Building axiom--main--1--patch-44 fails

On Sat, 20 Aug 2005, Magnus Larsson wrote:
> making /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/mnt/linux/doc/DeveloperNotes.dvi 
> from /home/jocelyn/usr/source/axiom/axiom--main--1--patch-44/src/doc/DeveloperNotes.pamphlet
> /bin/sh: line 0: [: too many arguments
>                                             
> All I get is "/bin/sh: line 0: [: too many arguments..". 
> The make script does not seem to complete and return to the bash shell
> and give me the cursor back. It just waits.
I have exactly the same problem with axiom--main--1--patch-44 on Gentoo 
Linux 2005.1.

In the Makefile in the doc directory, making DeveloperNotes.dvi indeed 
includes some if [ <something> ]; but the arguments of [ seem correct - I 
cannot understand this strange behaviour.

\start
Date: Sat, 20 Aug 2005 12:59:03 +0200
From: Magnus Larsson
To: Martin Rubey
Subject: Re: Building axiom--main--1--patch-44 fails

On Saturday 20 August 2005 10.35, Martin Rubey wrote:
> the problem is with the TeX processing of DeveloperNotes.pamphlet. Although
> I was unable to fix it, a workaround is to kill the make, and then (WITHOUT
> cleaning the interupted build) say
>
> make NOISE=
>
> at your shell prompt. After a short while you will see TeX in action
> complaining about a # it shouldn't see. Say
>
> q
>
> at the TeX prompt. This complaint will appear another time, and you should
> again answer with
>
> q
>
> Then the make should continue.
>
> Martin
>
Hello Martin Rubey,

Your workaround works for me to.

                        AXIOM Computer Algebra System
                     Version: Axiom 3.9 (September 2005)
              Timestamp: Saturday August 20, 2005 at 08:39:18
-----------------------------------------------------------------------------
   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
(1) ->
(1) ->

\start
Date: Sat, 20 Aug 2005 09:29:54 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#41 fresh databases are not copied back for build] 

With the fixedPoint script, I noticed that the old database
directories, DEPENDENTS.DAASE and USERS.DAASE, under int/algebra,
are not removed in preparation for the second iteration. Am
I mistaken in thinking that this will influence the subsequent
compilation?

You are correct. The src/algebra/Makefile.pamphlet that I am using
on the axiom--windows--1 branch has been updated to properly rebuild
the databases if any of the *.NRLIBS/code.o files change. In the
linux branches (e.g. axiom--main--1) the database build is still
done via a kludge that requires you to delete the file called
`dbcomplete' in order to force a rebuild. Alternately you could
also delete the int/*.spad files which will force them to be
re-extracted from the pamphlet files and also trigger deletion of
the dbcomplete file.

\start
Date: Sat, 20 Aug 2005 09:40:28 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#198 integrate(sin(x**2),x) is not handled ] 

Note that $sin(x^2)$ is a D-finite function:

\begin{axiom}
f := sin(x^2)
4*x^3*f - D(f,x) + x*D(f,x,2)
\end{axiom}

Thus integration should be "easy"...

\start
Date: Sat, 20 Aug 2005 09:31:09 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#41 fresh databases are not copied back for build] 

Could you please explain the property change!

\start
Date: Sat, 20 Aug 2005 11:05:40 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#198 integrate(sin(x**2),x) is not handled ] 

I browsed the web a little more and came to the conclusion that the
Risch algorithm only deals with elementary functions whose integral is
elementary, too. "Clearly" (looking at maxima's output or browsing the
web), $sin(x^2)$ does not have an elementary antiderivative. Hence, I
suspect that it should be treated just as $e^{-x^2}$, by the
'PatternMatchIntegration' package. This would not be too difficult,
probably.

\start
Date: Sat, 20 Aug 2005 12:30:19 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#198 integrate(sin(x**2),x) is not handled ] 

Although this does not really solve the original problem, I think I found a bug in 'INTPM'. Currently, there is an operation::

           pmComplexintegrate(f, x) ==
             (rc := splitConstant(f, x)).const ^= 1 =>
               (u := pmintegrate(rc.nconst, x)) case "failed" => "failed"
               rec := u::ANS
               [rc.const * rec.special, rc.const * rec.integrand]
             cse := (rec := matcherfei(f, x, true)).which
             cse = ERF  => [rec.coeff * erf(rec.exponent), 0]
             "failed"

It is pretty obvious that the third line should read::

           (u := pmComplexintegrate(rc.nconst, x)) case "failed" => "failed"

instead. If we perform this change, we get instead of
\begin{axiom}
complexIntegrate(-%i/2*e^(%i*x^2),x)
\end{axiom}

the correct answer, same for
\begin{axiom}
complexIntegrate(%i/2*e^(-%i*x^2),x)
\end{axiom}

For some reason, it still won't do 
\begin{axiom}
complexIntegrate(sin(x^2),x)
\end{axiom}

Curiously, the pattern matcher is not even invoked in this case... Even if we enter the integral as
\begin{axiom}
complexIntegrate(-%i/2*e^(%i*x^2)+%i/2*e^(-%i*x^2),x)
\end{axiom}
it fails, although in this case the pattern matcher is invoked. It would need to be invoked on each summand seperately, though.

\start
Date: Sat, 20 Aug 2005 12:57:26 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#199 integrate(exp(-x^2)+exp(x)/x, x)] (nouveau) 

For some reason, the following forgets about one summand:

\begin{axiom}
integrate(exp(-x^2)+exp(x)/x,x)
\end{axiom}

\start
Date: Sat, 20 Aug 2005 15:16:20 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#199 integrate(exp(-x^2)+exp(x)/x,x)] 

The problem is in 'expintegratepoly$INTTR'. There you find the following definition::

  -- returns either
  --   (q in GP, a in F)  st p = q' + a, and a=0 or a has no integral in F
  -- or (q in GP, r in GP) st p = q' + r, and r has no integral elem/UP
      expintegratepoly(p, FRDE) ==
        coef0:F := 0
        notelm := answr := 0$GP
        while p ^= 0 repeat
          ans1 := FRDE(n := degree p, a := leadingCoefficient p)
          answr := answr + monomial(ans1.ans, n)
          if ~ans1.sol? then         -- Risch d.e. has no complete solution
               missing := a - ans1.right
               if zero? n then coef0 := missing
                          else notelm := notelm + monomial(missing, n)
          p   := reductum p
        zero? notelm => [answr, coef0]
      [answr, notelm]

In principle, this function takes a polynomial 'p' and tries to
integrate every coefficient. If it finds an answer, it adds it to
'answr', otherwise to 'notelm'. Note however, that the constant term
of the 'p' will never get added to 'notelm', even if it was not
possible to integrate it. So maybe the last line should read::

      [answr, notelm+monomial(coef0, 0)]

This seems to "work", i.e., the integrals are then returned
unevaluated. However, I'd rather have axiom to use the linearity of
the integral...  Note that

\begin{axiom}
integrate(exp(-x^2)+sin(x),x)
\end{axiom}

is an example for an integral where 'coef0' does not vanish but
'notelm' does. So the more drastic change::

          if ~ans1.sol? then         -- Risch d.e. has no complete solution
               missing := a - ans1.right
               if zero? n then coef0 := missing
               notelm := notelm + monomial(missing, n)
          p   := reductum p
        zero? notelm => [answr, coef0]
      [answr, notelm]

is not necessary - but does not produce wrong results either.

By the way, here are some other - strange - manifestation of the same bug:

\begin{axiom}
integrate(exp(-x^2)+1/x,x)
integrate(exp(x)/x+1/x,x)
\end{axiom}

Although $1/x$ is certainly elementary, and so is its integral, the bug manifests itself.

\start
Date: Sat, 20 Aug 2005 15:56:53 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#198 integrate(sin(x**2),x) is not handled ] 

There is another issue I don't quite understand. Currently axiom
returns the whole integral unevaluated if it does not manage to
evaluate it completely. If it were not for the bug #199, the following
were an example:

\begin{axiom}
integrate(exp(x)/x+exp(-x^2)+1/log(x),x)
\end{axiom}

Although axiom produces the intermediate result
'integrate(exp(x)/x+exp(-x^2),x)+li(x)', it discards it. The
responsible line of code is in 'rinteg$FSINT' ::

    rinteg(i, f, x, h, comp) ==
      not elem? i => integral(f, x)$F
      empty? rest(l := [mkPrimh(f, x, h, comp) for f in expand i]) => first l
      l

Does this make sense?

\start
Date: Sun, 21 Aug 2005 04:32:28 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#193 Symbolic values (without variables) are not ordered properly in 'EXPR INT'] same for 'AlgebraicNumber'

The same problem exists in 'AN'. Although the test for zero in this
domain is mathematical, we have

\begin{axiom}
sqrt(2)<sqrt(3/2)
\end{axiom}

Note that the domain 'RealClosure' is designed to handle such
things. Also, the test for zero in 'RECLOS' is faster than in
'AN'. So, wouldn't it be appropriate to make 'AN' a wrapper for
'RECLOS FRAC INT'? Of course, the appropriate conversion routines
would have to be written, but this would be quite easy.

\start
Date: Sun, 21 Aug 2005 13:09:29 +0200
From: Magnus Larsson
To: list
Subject: Re: AxiomUI code

On Wednesday 17 August 2005 18.15, Kai Kaminski wrote:
> Hi,
>
> an early version of AxiomUI can be found on kaikaminski.gmxhome.de. The
> only dependency is Clisp. I use 2.34 but earlier version that are not
> too old should be fine. All Lisp libraries that are needed are contained
> in the tarball.
>
> There is also a README with instructions. It should be as easy as
> starting a shell script.

Hello Kai Kaminski,

Your axiomUI works for me. I am using GNU CLISP 2.34 and Axiom 3.9 (September 
2005).

However I could not get the KDE Konqueror web browser to execute 
http://127.0.0.1:8080/toplevel/ properly. Konqueror did not present a result 
when return was pressed after an expression was entered. 

Firefox worked fine though.

\start
Date: Mon, 22 Aug 2005 09:30:31 +0200
From: Kai Kaminski
To: Kai Kaminski
Subject: Re: AxiomUI code

Magnus Larsson writes:

> Your axiomUI works for me. I am using GNU CLISP 2.34 and Axiom 3.9 (September 
> 2005).
Thanks for trying this.

> However I could not get the KDE Konqueror web browser to execute 
> http://127.0.0.1:8080/toplevel/ properly. Konqueror did not present a result 
> when return was pressed after an expression was entered. 
> From what I read on the web I'm under the impression that Konqueror is
not very standards compliant. I'll see what I can do.

> Firefox worked fine though.
That's good. Have you installed the proper fonts for jsMath or not?

\start
Date: Mon, 22 Aug 2005 13:00:54 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Unit package question

I would rather suggest to write a package

Mass(R: Ring): Ring == add { ... }

where Ring should actually be something that allows Float to be entered 
for R. Maybe even

Mass(T: with {
   +: (%, %) -> %;
   *: (%, %) -> %;
   ...
})(R: T): T == add { ... }

would be a good idea.
(Well, that is Aldor syntax, but I hope in can be understood.)

In the "add" part the units could be implemented as variables (together 
with some rules to convert from kg to ton or so) of a polynomial domain.
The output would be entirely left to the Mass domain. And the advantage 
of that approach would be that one could have also variables in the 
domain parameter R. Nothing prevents it from being something like a 
polynomial domain. One only has to take care that variables and units 
are separated accordingly.

Then I could imagine to write

kg:=kilogramm$Mass(Float);
ton:=ton$Mass(Float);
mass:=7.3 * ton + 4.3 *kg

which would print in kg, say, as the standard format.

7304.3 * kg
                           Type: Mass(Float)

If you like to see this in tons then say, for example,
convert(mass, ton).

Well... that is just a thought.

If you like more units than just mass, I think, it would be reasonable 
to write a Unit domain similar to the Mass domain given above 
incorporating also seconds, hours or whatever.

Best regards
Ralf

C Y wrote:
> --- Bill Page wrote:
> 
> 
>>Here are few initial ideas about how I think units might
>>be implemented in Axiom.
>>
>>For scientific applications of Axiom, I think units might be
>>very useful. My first reaction however is to try to imagine
>>what part of Axiom might be most suitable to represent the
>>concept of units.
> 
> 
> It's most likely non-trivial - I've got some digging to do into Axiom
> programming philosophy.  I'll try to describe what I had envisioned in 
> my mind's eye, and perhaps it will emerge what it would take to teach
> Axiom to work with the new concepts.
>  
> 
>>>There are a number of surprisingly annoying features to handle
>>>based on my experience with Maxima, and one of the worst is
>>>the following:
>>>
>>>If I enter an expression, Axiom automatically formats it and
>>>orders it according to internal rules.  See
>>
> http://www.axiom-developer.org/zope/mathaction/SandBox#msg20050819154916
> 
>>-0500@www.axiom-developer.org
>>
>>
>>>for an example of this.  Normally, this is what one wants to do.
>>
>>I think what you are doing here is ok in Maxima, Maple and
>>Mathematica but it does not fit well in Axiom. I think it might
>>be quite awkward to treat units as expressions of this kind in
>>Axiom.
> 
> 
> Possibly - I'm not really sure myself yet.  But as I'll explain below
> there are reasons for this approach.
> 
> 
>>>What I'm not sure of is how to instruct Axiom to display things
>>>that are Units at the end of an expression, e.g.
>>>
>>>        kg*m
>>>a*b*z  ------
>>>          2
>>>         s
>>
>>What makes Axiom different is it's strong type system and it's
>>object-orientation. To me this suggests that units in Axiom
>>might be best implemented as extensions of the Float domain.
> 
> 
> The logic of units certainly has some similarities, but one needs to be
> careful because there are a fair number of unique options one would
> want to have with units.  I'm not sure, on closer analysis, that Floats
> are really all that good a match.  I'll try to give a couple examples
> below.
> 
> 
>>By this I mean we should be able to write something like this:
>>
>>(1) ->  (2.0::kg + 1.0::lb)::ton
>>
>>   (1)  0.0027
>>                      Type: ton
>>
>>where kg, lb and ton are Axiom domains. Given the right
>>definitions of these domains we should expect that Axiom would
>>perform the necessary coercion/conversion from the domains
>>kg and lb to ton, the same as if we had written:
>>
>>(2) -> (2.0::Float + 1.0::INT)::SF
>>
>>   (2)  3.0
>>                      Type: DoubleFloat
> 
> 
> The problem with this is there would have to be one type/domain for
> EVERY SINGLE UNIT we wished to define.  When one includes the metric
> prefix system, this can include a LOT of types/domains. Conceptually, I
> think it would be more elegant to have Axiom recognize a) a unit is in
> an expression b) determine the dimension of each unit and confirm the
> expression is dimensionally legal and c) depending on options return
> either i) the unsimplified combination of legal terms ii) the
> simplified expression according to a global set of user chosen standard
> units (MKS by default) or iii) if non-basic dimensions like Force are
> enabled, and an expression simplifies to such a dimensional type or a
> combination of higher order types, simplify to the most compact form
> available.  Of course, this might not be at all elegant in Axiom as it
> currently exists, but here's a mockup session of what I'd like to see:
> 
> (1) -> (2.0::kg + 1.0::lb)::kg
>      Error - incompatible dimensions for Add operation
> 
> (1) -> (2.0::kg + 1.0::slugs)::kg
> 
>     (1)  3.45939 kg
>                                   Type: Mass
> (2) -> (2.0::kg + 1.0::slugs)::slugs
> 
>     (2)  2.3704355929 53220181 slugs
>                                   Type: Mass
> 
> Ideally I'd also like Axiom to be able to deal with (2.0*kg +
> 1.0*slugs)::kg as well, but I don't know if that would be legal or not.
>  Conceptually at least, 2.0*kg and 2.0::kg are the same thing.  I'll
> add more mockups below as they seem relevant.
> 
> 
>>To implement something like:
>>
>>(3) -> 2.0::m * 3.1::kg
>>
>>          6.1
>>                      Type: m*kg
>>
>>Axiom will have to be told how to multiply meters by kilograms.
>>This is easily done given Axiom function overloading. Add of
>>course Axiom needs to know how to construct new units (types)
>>from old ones. Since types are first order objects in Axiom,
>>this is also quite easy.
> 
> 
> I would like to see this feature handle things as follows (I don't know
> enough about the type system to know if it could do this yet)
> 
> (3) -> (4.0::kg * 3.0::m / 6::s**-2)
> 
>              kg m
>    (3)  2.0  ----
>                2
>               s
>                                   Type: Mass*Length/Time^2
> (4) -> ActivateExtendedUnitTypes(MKS)
>         
>    (4)  True      (not sure what the "standard" way to do this is)
>                                   Type: Bool
> (5) -> (4.0::kg * 3.0::m / 6::s**-2)
> 
>    (5)  2 N
>                                   Type: Force
> (6) -> (4.0::kg * 3.0::m / 6::s**-2)::dyn
> 
>    (6)  200000 dyn
>                                   Type: Force
> (7) -> (a::N)::dyn
> 
>    (7)  100000 a dyn
>                                   Type: VariableForce
> 
> There are many other variations on what a user might want - for
> example, after doing some calculations in N or dyne they may want to
> render their forces in base units, but cm*g/minute^2 rather than MKS. 
> Options to set defaults for and override locally all of these
> simplifications are needed.  Assignment checking is also needed - for
> example, in the last example above a should only be assigned quantities
> of type Force.  However, any Force type is legal and should be accepted
> and converted as controlled by settings.
> 
> 
>>Perhaps you are confusing the notion of 'dimension' and 'unit'
>>here
> 
> 
> Possibly - I get a bit loose with my terminology sometimes, which won't
> do in the Axiom world :-).  To be clear - each unit is associated with
> a dimension, and I would like to see the rules governing unit
> interactions work on the dimension level, while handling the conversion
> between different units with the same dimension automatically based on
> circumstances as determined by either default settings or the user's
> preferences.
> 
> 
>>but still I think these ideas both map quite well to
>>Axiom's type system. For example
>>
>>(4) -> 1.0::m + 2.0::s
>>
>>would constitute a type error.
> 
> 
> Right - essentially Axiom's strict typing gives us a chance to have
> dimensional analysis as part of all calculations :-).  
> 
> 
>>The display of units as types, e.g.
>>
>>                      Type: m*kg
>>
>>should be possible, although I think there my currently be
>>some built-in assumptions about type expressions that might
>>currently preclude this nice infix notation. But a type such
>>as
>>
>>                      Type: Prod(m,kg)
>>
>>is certainly possible.
> 
> 
> Right, but as I showed in my examples above my preference is for the
> units to remain as a displayed part of the expression, and the Type
> information to report the dimension of the quantity in question.  This
> seems to me to be the most useful thing to do.
>  
> 
>>>Is there anybody who knows what the correct approach to this
>>>would be?
>>
>>Maple has an elaborate Scientific units and dimension system
>>that even takes advantage of overloading operations like + * /
>>such as I suggested above, although Maple does not really have
>>the notion of strong typing. If you have the opportunity to study
>>how this was done in Maple perhaps it will suggest a possible
>>approach in Axiom.
> 
> 
> I have looked at the Maple package, and indeed they use many similar
> ideas to ones I had arrived at (after much trial and error) in the
> Maxima design.  (Boy was that embarassing - a real lesson to do my
> homework before beating my head against the nearest wall!)  How it's
> ideas map into Axiom's strong typing system is, unfortunately, the real
> nut to crack.  Axiom's system offers some exciting possibilities, but
> it looks like there might be some roadblocks to plow through too.
> 
> I should mention that Maple has the idea of things like (IIRC) unit
> space where expressions are encapsulated in a Units() denotation, e.g.
> 4*z*Units(kg*m/s^2).  This was rejected for the Maxima package - we
> felt that the program should be able to handle the "textbook"
>                         kg*m
> formatting style of 4*z ---- since this is the convention used 
>                           2
>                          s
> almost universally in the sciences (who are most likely to be dealing
> with units.)  I have the same hope for Axiom - units, as multiplicative
> factors, remaining part of the expression, and the Type information
> working on the dimension level.  (As in my examples above.)
> 
> 
>>These are just some rough initial ideas. I am not sure how
>>well this concept of "units as types" will work out in
>>detail.
> 
> 
> It might be that that would be the best "mapping" of the idea onto
> Axiom's system, although aesthetically I prefer the idea of working
> with dimensions and units providing the multiplicative factors for
> conversion between each other.  Discussion welcome.
> 
> Cheers,
> CY
> 
> P.S. - there's also the whole idea of error analysis which enters into
> this equation - for example, when discussing physical quantities 2.0
> has a significance - you are implying a greater measurement accuracy
> than just stating 2.  So there may be a collision in the future between
> float and integer behavior in Axiom and the handling of accuracy.  For
> example, if I have a measurement of 10+-2 and I subtract the quantity
> 4.0007+-0.0005, the proper return (if I've got this right - it's been a
> while) would be 6+-2, since error analysis combining the two errors
> would result in 2 + <small amount>, and significant figure rules say to
> chop off the <small amount>.  Anyway, there are rules governing such
> things and I suspect there might be a collision between those and
> "normal" mathematical convention, where all things are exact.  Then
> there's the whole issue of errors introduced by the CAS itself, due to
> precision limits and such. But that's for another day.

\start
Date: Mon, 22 Aug 2005 06:33:59 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#196 )set functions compile on] 

Another manifestation is reported by Kai Kaminski:

\begin{axiom}
)se fu co on
addx x == ((y: Integer): Integer +-> x + y)
g := addx 10
\end{axiom}

\start
Date: Mon, 22 Aug 2005 13:34:27 +0200
From: Martin Rubey
To: Kai Kaminski
Subject: Re: Function definition crashes Axiom

This is the same as bug #165 and #196. I'll add it there. Would be great if you
could fix that :-)

Martin

Kai Kaminski writes:
 > 
 > Hi everyone,
 > 
 > I'm currently rebuilding parts of the HyperDoc documentation. One page
 > (ug06.[p]ht) contains the following commands:
 > 
 > addx x == ((y: Integer): Integer +-> x + y)
 > 
 > g := addx 10
 > 
 > When I enter those commands at the Axiom toplevel, Axiom crashes due
 > to a segmentation fault. I'm using version 3.8 (patch-43) freshly
 > built on Ubuntu 5.04. I'm pretty sure that I haven't modified the
 > source code prior to compiling it, but I'll rebuild it to be sure, if
 > noone else has this problem.

\start
Date: Mon, 22 Aug 2005 14:19:55 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Unit package question

Dear Ralf, CY,

in fact, I like this idea even better than mine. In private communication, we
developed the domain below, but your idea is conceptually better, I think. The
full blown thing would then be a category Units, that has as domains Mass,
Time, Length, ... I suppose.

Martin

)abb domain UNITS Units
Units(R: Field): Exports == Implementation where
  U == Fraction Polynomial Integer

  Exports == with

    "*": (%,%) -> %

    "+": (%,%) -> %

    coerce: % -> OutputForm

    withUnits: (R, U)  -> %

    setUnitSystem!: String -> String

  Implementation == add
    Rep := Record(expr: R, units: U) 

    system: String := "MKS"
    setUnitSystem! s == 
      t := system
      system := s
      t

    transform: U -> Record(scalar: R, units: U)

    transform u ==
      m := 'm::Symbol::Polynomial(Integer)::U
      v := u
      if system = "MKS"
      then v := eval(u, ['cm,        'dm], _
                        [m*1/100::U, m*1/10::U])$RationalFunction(Integer)

      s: Fraction Integer := leadingCoefficient(numer(v)) _
                           / leadingCoefficient(denom(v))
      r: U := leadingMonomial(numer(v))::U _
            / leadingMonomial(denom(v))::U _
            / s ::U
      [s::R, r]

    withUnits(e, u) == [e, u]::Rep

    x * y  == [(x::Rep).expr * (y::Rep).expr, (x::Rep).units * (y::Rep).units]

    x + y  == 
      ux := transform((x::Rep).units)
      uy := transform((y::Rep).units)
      if ux.units = uy.units
      then [(x::Rep).expr*ux.scalar + (y::Rep).expr*uy.scalar, ux.units]
      else error "+: Units have to match"

    coerce x == coerce((x::Rep).expr)$R * coerce((x::Rep).units)$U

\start
Date: Mon, 22 Aug 2005 20:02:11 +0200
From: Magnus Larsson
To: Kai Kaminski
Subject: Re: AxiomUI code

On Monday 22 August 2005 09.30, Kai Kaminski wrote:
> Magnus Larsson writes:
> > Your axiomUI works for me. I am using GNU CLISP 2.34 and Axiom 3.9
> > (September 2005).
>
> Thanks for trying this.
>
> > However I could not get the KDE Konqueror web browser to execute
> > http://127.0.0.1:8080/toplevel/ properly. Konqueror did not present a
> > result when return was pressed after an expression was entered.
>
> From what I read on the web I'm under the impression that Konqueror is
> not very standards compliant. I'll see what I can do.
>
> > Firefox worked fine though.
>
> That's good. Have you installed the proper fonts for jsMath or not?
Hello Kai Kaminski,
I used jsMath fonts.
Best regards,
Magnus Larsson

\start
Date: Mon, 22 Aug 2005 15:44:46 -0500
From: MathAction (unknown)
To: MathAction
Subject: [FrontPage] integration

the function f(x,y) = 12xy(1-y) for 0<x<1, 0<y<1

the condition of inequality (x-y)> (1/2)

what if the limits of integration are functions of the variable I
am integrating over.

is this somthing which can be done in a simple way, with Axiom?

examples:
Mathimatic 5.1:
In[2]:=Integrate[12*x*y*(1-y)*Boole[x-y>1/2],{y,0,1},{x,0,1}]

Maple:
Doubleint(12*x*y*(1-y)*Heaviside(x-y-1/2),x=0..1,y=0..1);

\start
Date: Mon, 22 Aug 2005 23:17:36 +0100
From: Peter Broadbery
To: Tim Daly
Subject: Re: Axiom/aldor interface code

Hi Tim,

Finally managed to get the interface running and building from pamphlets
properly.  I've attached two files - there is a tar file which should be
unpacked in axiom/src - this contains an 'aldor' directory.  The patch
file contains some minor (but important) changes to files in src/interp.

Typing 'make' in the aldor directory should kick the build off.  It
takes less than an hour on my 2Ghz pentium.

To build, you'll need java, and aldor 1.0.2 set up.  

I've tried to document how the makefiles fit together in the .pamphlet
files, hopefully some of them will make a form of sense.  Basically, the
idea is that the build uses a small java program to dynamically
determine dependencies, and then let make deal with compilation order.  

Minor changes: I've changed where axiom looks for the aldor files - they
go to $AXIOM/aldor, not $AXIOM/compiler, mostly 'cos compiler is too
ambiguous.  The other changes are simple bug fixes.

For testing, I've appended a very stupid aldor domain (the maths inside
is not meant to be taken seriously; 'tis a silly idea that can't work).
The file contains a short test script at the end.

Pete.

On Sun, 2005-08-14 at 12:07 -0500, Tim Daly wrote:
> Pete,
> 
> Excellent. Just send me the pamphlets and I'll work on the merge piece.
> 
> re: delay. progress is not measured by time. Once I see what you've
> been up to I can work out testing methods and integrate them into 
> the whole.
> 
> Tim
-- 
Peter Broadbery

--=-gSIb34c7BTjmb4KTBUPy

KiBsb29raW5nIGZvciBhcmNoQGF4aW9tLWRldmVsb3Blci5vcmctLWF4aW9tL2F4aW9tLS1tYWlu
LS0xLS1wYXRjaC00NCB0byBjb21wYXJlIHdpdGgNCiogY29tcGFyaW5nIHRvIGFyY2hAYXhpb20t
ZGV2ZWxvcGVyLm9yZy0tYXhpb20vYXhpb20tLW1haW4tLTEtLXBhdGNoLTQ0DQpNICBzcmMvaW50
ZXJwL3BhdGNoZXMubGlzcC5wYW1waGxldA0KTSAgc3JjL2ludGVycC9kYWFzZS5saXNwLnBhbXBo
bGV0DQpNICBzcmMvaW50ZXJwL2ZvYW1fbC5saXNwLnBhbXBobGV0DQpNICBzcmMvaW50ZXJwL2F4
LmJvb3QucGFtcGhsZXQNCk0gIHNyYy9pbnRlcnAvaS1zeXNjbWQuYm9vdC5wYW1waGxldA0KDQoq
IG1vZGlmaWVkIGZpbGVzDQoNCi0tLSBvcmlnL3NyYy9pbnRlcnAvYXguYm9vdC5wYW1waGxldA0K
KysrIG1vZC9zcmMvaW50ZXJwL2F4LmJvb3QucGFtcGhsZXQNCkBAIC0yOTQsNiArMjk0LDcgQEAN
CiAgICBvcCA9ICdoYXMgPT4NCiAgICAgICBbbmFtZSx0eXBlXSA6PSBhcmdzDQogICAgICAgaWYg
bmFtZSA9ICckIHRoZW4gbmFtZSA6PSAnJQ0KKyAgICAgIGVsc2UgbmFtZSA6PSBheEZvcm1hdE9w
IG5hbWUNCiAgICAgICBmdHlwZSA6PSBheEZvcm1hdE9wIHR5cGUNCiAgICAgICBpZiBmdHlwZSBp
cyBbJ0RlY2xhcmUsOi5dIHRoZW4NCiAgICAgICAgICAgIGZ0eXBlIDo9IFsnV2l0aCwgW10sIGZ0
eXBlXQ0KDQoNCi0tLSBvcmlnL3NyYy9pbnRlcnAvZGFhc2UubGlzcC5wYW1waGxldA0KKysrIG1v
ZC9zcmMvaW50ZXJwL2RhYXNlLmxpc3AucGFtcGhsZXQNCkBAIC0xNDY1LDcgKzE0NjUsNyBAQA0K
ICAoc2V0IChmb2FtOjpheGlvbXhsLWZpbGUtaW5pdC1uYW1lICJmaWxlY2xpcSIpIE5PUGZ1bmNh
bGwpDQogIChzZXQgKGZvYW06OmF4aW9teGwtZmlsZS1pbml0LW5hbWUgImF0dHJpYiIpIE5PUGZ1
bmNhbGwpDQogOzsgZm9sbG93aW5nIG5lZWRzIHRvIGhhcHBlbiBpbnNpZGUgcmVzdGFydCBzaW5j
ZSAkQVhJT00gbWF5IGNoYW5nZQ0KLSAobGV0ICgoYXNoYXJwcm9vdGxpYiAoc3RyY29uYyAofGdl
dEVudnwgIkFYSU9NIikgIi9jb21waWxlci9saWIvIikpKQ0KKyAobGV0ICgoYXNoYXJwcm9vdGxp
YiAoc3RyY29uYyAofGdldEVudnwgIkFYSU9NIikgIi9hbGRvci9saWIvIikpKQ0KICAgIChzZXQt
ZmlsZS1nZXR0ZXIgKHN0cmNvbmMgYXNoYXJwcm9vdGxpYiAicnVudGltZSIpKQ0KICAgIChzZXQt
ZmlsZS1nZXR0ZXIgKHN0cmNvbmMgYXNoYXJwcm9vdGxpYiAibGFuZyIpKQ0KICAgIChzZXQtZmls
ZS1nZXR0ZXIgKHN0cmNvbmMgYXNoYXJwcm9vdGxpYiAiYXR0cmliIikpDQoNCg0KLS0tIG9yaWcv
c3JjL2ludGVycC9mb2FtX2wubGlzcC5wYW1waGxldA0KKysrIG1vZC9zcmMvaW50ZXJwL2ZvYW1f
bC5saXNwLnBhbXBobGV0DQpAQCAtODg0LDggKzg4NCw4IEBADQogIChjb25kICggKG9yIChOVUxM
IHUpIChOVUxMIHYpKSBuaWwpDQogICAgICAgICggKGFuZCAoQVRPTSB1KSAoQVRPTSB2KSkgKGVx
bCB1IHYpKQ0KICAgICAgICAoIChvciAoQVRPTSB1KSAoQVRPTSB2KSkgbmlsKQ0KLSAgICAgICAo
IChlcXVhbCAobGVuZ3RoIHUpIChsZW5ndGggdikpICh8bWFnaWNFcTF8IHUgdikpIA0KLSAgICAg
ICBuaWwgKSkNCis7OyAgICAgICAoIChlcXVhbCAobGVuZ3RoIHUpIChsZW5ndGggdikpICh8bWFn
aWNFcTF8IHUgdikpDQorICAgICAgICh0IChlcSB1IHYpKSkpDQogDQogKGRlZnVuIHxtYWdpY0Vx
MXwgKHUgdikNCiAgKGNvbmQgKCAoYW5kIChhdG9tIHUpIChhdG9tIHYpKSAofHBvbGl0aWNhbGx5
U291bmR8IHUgdikpDQoNCg0KLS0tIG9yaWcvc3JjL2ludGVycC9pLXN5c2NtZC5ib290LnBhbXBo
bGV0DQorKysgbW9kL3NyYy9pbnRlcnAvaS1zeXNjbWQuYm9vdC5wYW1waGxldA0KQEAgLTc1LDEy
ICs3NSwxMiBAQA0KIG5ldyBhbGRvciBjb21waWxlci56DQogVGhpcyB1c2VkIHRvIHJlYWQ6DQog
XGJlZ2lue3ZlcmJhdGltfQ0KLSAgICAgU1RSQ09OQyhUUlVFTkFNRShTVFJDT05DKEdFVEVOVign
IkFYSU9NIiksJyIvY29tcGlsZXIvYmluLyIpKSwiYXhpb214bCAiLCBhc2hhcnBBcmdzLCAnIiAi
LCBuYW1lc3RyaW5nIGFyZ3MpDQorICAgICBTVFJDT05DKFRSVUVOQU1FKFNUUkNPTkMoR0VURU5W
KCciQUxET1JST09UIiksJyIvYmluLyIpKSwiYWxkb3IgIiwgYXNoYXJwQXJncywgJyIgIiwgbmFt
ZXN0cmluZyBhcmdzKQ0KIFxlbmR7dmVyYmF0aW19DQogYnV0IG5vdyByZWFkczoNCiA8PHJlbW92
ZSBUUlVFTkFNRT4+PQ0KLSAgICAgU1RSQ09OQyhTVFJDT05DKEdFVEVOVignIkFYSU9NIiksJyIv
Y29tcGlsZXIvYmluLyIpLF8NCi0gICAgICAgICAgICAgICAiYXhpb214bCAiLCBhc2hhcnBBcmdz
LCAnIiAiLCBuYW1lc3RyaW5nIGFyZ3MpDQorICAgICBTVFJDT05DKFNUUkNPTkMoR0VURU5WKCci
QUxET1JST09UIiksJyIvYmluLyIpLF8NCisgICAgICAgICAgICAgICAiYWxkb3IgIiwgYXNoYXJw
QXJncywgJyIgIiwgbmFtZXN0cmluZyBhcmdzKQ0KIEANCiANCiBcc2VjdGlvbntMaWNlbnNlfQ0K
DQoNCi0tLSBvcmlnL3NyYy9pbnRlcnAvcGF0Y2hlcy5saXNwLnBhbXBobGV0DQorKysgbW9kL3Ny
Yy9pbnRlcnAvcGF0Y2hlcy5saXNwLnBhbXBobGV0DQpAQCAtMjY2LDcgKzI2Niw3IEBADQogICAo
b3BlcmF0aW9ub3Blbik7OyBhbGwgb2YgdGhlIG9wZXJhdGlvbnMga25vd24gdG8gdGhlIHN5c3Rl
bQ0KICAgKGNhdGVnb3J5b3Blbik7OyBhbnN3ZXIgaGFzQ2F0ZWdvcnkgcXVlc3Rpb24NCiAgIChi
cm93c2VvcGVuKQ0KLSAgKGxldCAoKGFzaGFycHJvb3RsaWIgKHN0cmNvbmMgKHxnZXRFbnZ8ICJB
WElPTSIpICIvY29tcGlsZXIvbGliLyIpKSkNCisgIChsZXQgKChhc2hhcnByb290bGliIChzdHJj
b25jICh8Z2V0RW52fCAiQVhJT00iKSAiL2FsZG9yL2xpYi8iKSkpDQogICAgIChzZXQtZmlsZS1n
ZXR0ZXIgKHN0cmNvbmMgYXNoYXJwcm9vdGxpYiAicnVudGltZS5vIikpDQogICAgIChzZXQtZmls
ZS1nZXR0ZXIgKHN0cmNvbmMgYXNoYXJwcm9vdGxpYiAibGFuZy5vIikpDQogICAgIChzZXQtZmls
ZS1nZXR0ZXIgKHN0cmNvbmMgYXNoYXJwcm9vdGxpYiAiYXR0cmliLm8iKSkNCg0KDQoNCg==


--=-gSIb34c7BTjmb4KTBUPy

CgotLQlSYW5kb20gdmFyaWFibGVzIGFyZSBhc3N1bWVkIHRvIGhhdmUgdGhlIGZvbGxvd2luZyBw
cm9wZXJ0aWVzOgotLQotLSAgIDEuIGNvbXBsZXggY29uc3RhbnRzIGFyZSByYW5kb20gdmFyaWFi
bGVzOwotLSAgIDIuIHRoZSBzdW0gb2YgdHdvIHJhbmRvbSB2YXJpYWJsZXMgaXMgYSByYW5kb20g
dmFyaWFibGU7Ci0tICAgMy4gdGhlIHByb2R1Y3Qgb2YgdHdvIHJhbmRvbSB2YXJpYWJsZXMgaXMg
YSByYW5kb20gdmFyaWFibGU7Ci0tICAgNC4gYWRkaXRpb24gYW5kIG11bHRpcGxpY2F0aW9uIG9m
IHJhbmRvbSB2YXJpYWJsZXMgYXJlIGJvdGggY29tbXV0YXRpdmU7IGFuZAotLSAgIDUuIHRoZXJl
IGlzIGEgbm90aW9uIG9mIGNvbmp1Z2F0aW9uIG9mIHJhbmRvbSB2YXJpYWJsZXMsIHNhdGlzZnlp
bmcKLS0KLS0gICAgICAgKGFiKSogPSBiKiBhKiBhbmQgYSoqID0gYSAKLS0KLS0gICAgICBmb3Ig
YWxsIHJhbmRvbSB2YXJpYWJsZXMgYSwgYiwgYW5kIGNvaW5jaWRpbmcgd2l0aCBjb21wbGV4IGNv
bmp1Z2F0aW9uCi0tICAgICAgaWYgYSBpcyBhIGNvbnN0YW50LgotLQotLVRoaXMgbWVhbnMgdGhh
dCByYW5kb20gdmFyaWFibGVzIGZvcm0gY29tcGxleCBhYmVsaWFuICotYWxnZWJyYXMuIElmIGEg
PSBhKiwKLS10aGUgcmFuZG9tIHZhcmlhYmxlIGEgaXMgY2FsbGVkICJyZWFsIi4KLS0KLS1BbiBl
eHBlY3RhdGlvbiBFIG9uIGFuIGFsZ2VicmEgQSBvZiByYW5kb20gdmFyaWFibGVzIGlzIGEgbm9y
bWFsaXplZCwgcG9zaXRpdmUKLS1saW5lYXIgZnVuY3Rpb25hbC4gV2hhdCB0aGlzIG1lYW5zIGlz
IHRoYXQKLS0KLS0gICAxLiBFKDEpID0gMTsKLS0gICAyLiBFKGEgKiBhKSA+PSAwIGZvciBhbGwg
cmFuZG9tIHZhcmlhYmxlcyBhOwotLSAgIDMuIEUoYSArIGIpID0gRShhKSArIEUoYikgZm9yIGFs
bCByYW5kb20gdmFyaWFibGVzIGEgYW5kIGI7IGFuZAotLSAgIDQuIEUoemEpID0gekUoYSkgaWYg
eiBpcyBhIGNvbnN0YW50LgotLQotLSAgICotYWxnZWJyYQotLSAgIC0tLS0tLS0tLQotLUZyb20g
V2lraXBlZGlhLCB0aGUgZnJlZSBlbmN5Y2xvcGVkaWEuCi0tCi0tSW4gbWF0aGVtYXRpY3MsIGEg
Ki1hbGdlYnJhIGlzIGFuIGFzc29jaWF0aXZlIGFsZ2VicmEgb3ZlciB0aGUgZmllbGQgb2YKLS1j
b21wbGV4IG51bWJlcnMgd2l0aCBhbiBhbnRpbGluZWFyLCBhbnRpYXV0b21vcnBoaXNtICogOiBB
IJKiqiBBIHdoaWNoIGlzIGFuCi0taW52b2x1dGlvbi4gTW9yZSBwcmVjaXNlbHksICogaXMgcmVx
dWlyZWQgdG8gc2F0aXNmeSB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6Ci0tCi0tICAgICogKHgg
KyB5KV4qID0geF4qICsgeV4qIFxxdWFkCi0tICAgICogKHogeCleKiA9IFxvdmVybGluZXt6fSB4
XioKLS0gICAgKiAoeCB5KV4qID0geV4qIHheKiBccXVhZAotLSAgICAqICh4XiopXiogPSB4IFxx
dWFkCi0tCi0tZm9yIGFsbCB4LHkgaW4gQSwgYW5kIGFsbCB6IGluIEMuCi0tCi0tVGhlIG1vc3Qg
b2J2aW91cyBleGFtcGxlIG9mIGEgKi1hbGdlYnJhIGlzIHRoZSBmaWVsZCBvZiBjb21wbGV4IG51
bWJlcnMgQwotLXdoZXJlICogaXMganVzdCBjb21wbGV4IGNvbmp1Z2F0aW9uLiBBbm90aGVyIGV4
YW1wbGUgaXMgdGhlIGFsZ2VicmEgb2YgboHXbgotLW1hdHJpY2VzIG92ZXIgQyB3aXRoICogZ2l2
ZW4gYnkgdGhlIGNvbmp1Z2F0ZSB0cmFuc3Bvc2UuCi0tCi0tQW4gYWxnZWJyYSBob21vbW9ycGhp
c20gZiA6IEEgkqKqIEIgaXMgYSAqLWhvbW9tb3JwaGlzbSBpZiBpdCBpcyBjb21wYXRpYmxlCi0t
d2l0aCB0aGUgaW52b2x1dGlvbnMgb2YgQSBhbmQgQiwgaS5lLgotLQotLSAgICAqIGYoYSAqICkg
PSBmKGEpICogZm9yIGFsbCBhIGluIEEuCi0tCi0tQW4gZWxlbWVudCBhIGluIEEgaXMgY2FsbGVk
IHNlbGYtYWRqb2ludCBpZiBhKiA9IGEuCgoKI2luY2x1ZGUgImF4aW9tIgoKUmFuZG9tQWxnZWJy
YShGOiBGaWVsZCk6IENhdGVnb3J5ID09IHdpdGggewogICAgQWxnZWJyYSBGOwogICAgRTogJSAt
PiBGOwogICAgc2FtcGxlOiAlIC0+IEY7Cn0KCmxvY2FsIFBvbHlIZWxwZXIoRjogRmllbGQpOiB3
aXRoIHsKIGV4cGFuZDogU3BhcnNlVW5pdmFyaWF0ZVBvbHlub21pYWwgRiAtPiBHZW5lcmF0b3Ig
Q3Jvc3MoRiwgTm9uTmVnYXRpdmVJbnRlZ2VyKTsKfQo9PSBhZGQgewogICAgZXhwYW5kKHA6IFNw
YXJzZVVuaXZhcmlhdGVQb2x5bm9taWFsIEYpOiBHZW5lcmF0b3IgQ3Jvc3MoRiwgTm9uTmVnYXRp
dmVJbnRlZ2VyKSA9PSBnZW5lcmF0ZSB7CglkZWZhdWx0IG06IFNwYXJzZVVuaXZhcmlhdGVQb2x5
bm9taWFsIEY7CglpbXBvcnQgZnJvbSBTcGFyc2VVbml2YXJpYXRlUG9seW5vbWlhbCBGOwoJaW1w
b3J0IGZyb20gTGlzdCBTcGFyc2VVbml2YXJpYXRlUG9seW5vbWlhbCBGOwoJZm9yIG0gaW4gbW9u
b21pYWxzIHAgcmVwZWF0IHsKCSAgICB5aWVsZCAobGVhZGluZ0NvZWZmaWNpZW50IG0sIGRlZ3Jl
ZSBtKTsKCX0KICAgIH0KfQoKVW5pdmFyaWF0ZU5vcm1hbFJhbmRvbUFsZ2VicmE6IFJhbmRvbUFs
Z2VicmEgRmxvYXQgd2l0aCB7CiBYOiAoKSAtPiAlOwogdmFyaWFuY2U6ICUgLT4gRmxvYXQ7Cn0g
PT0gYWRkIHsKICAgIFJlcCA9PT4gU3BhcnNlVW5pdmFyaWF0ZVBvbHlub21pYWwgRmxvYXQ7CiAg
ICBpbXBvcnQgZnJvbSBSZXA7CgogICAgMDogJSA9PSBwZXIgMDsKICAgIDE6ICUgPT0gcGVyIDE7
CiAgICBYKCk6ICUgPT0gcGVyKG1vbm9taWFsKDEkRmxvYXQsMSROb25OZWdhdGl2ZUludGVnZXIp
JFJlcCk7CgogICAgY2hhcmFjdGVyaXN0aWMoKTogTm9uTmVnYXRpdmVJbnRlZ2VyID09IDA7Cgog
ICAgLSh4OiAlKTogJSA9PSBwZXIoLXJlcCB4KTsKICAgIChhOiAlKSA9IChiOiAlKTogQm9vbGVh
biA9PSByZXAoYSkgPSByZXAoYik7CgogICAgKGE6ICUpICsgKGI6ICUpOiAlID09IHBlcihyZXAo
YSkgKyByZXAoYikpOwogICAgKGE6ICUpICogKGI6ICUpOiAlID09IHBlcihyZXAoYSkgKiByZXAo
YikpOwogICAgKGE6IEZsb2F0KSAqIChiOiAlKTogJSA9PSBwZXIoYSAqIHJlcChiKSk7CgogICAg
Y29lcmNlKHg6IEludGVnZXIpOiAlID09IHBlcih4OjpSZXApOwogICAgY29lcmNlKHg6IEZsb2F0
KTogJSA9PSBwZXIoeDo6UmVwKTsKCiAgICBjb2VyY2UoeDogJSk6IE91dHB1dEZvcm0gPT0gY29l
cmNlIHJlcCh4KTsKCiAgICBFKFg6ICUpOiBGbG9hdCA9PSAgewoJaW1wb3J0IGZyb20gUG9seUhl
bHBlciBGbG9hdDsKCXo6IEZsb2F0IDo9IDA7Cglmb3IgcCBpbiBleHBhbmQgcmVwKFgpIHJlcGVh
dCB7CgkgICAgKGEsIGIpIDo9IHA7CgkgICAgeiA6PSB6ICsgYSAqIEUoYik7Cgl9Cgl6CiAgICB9
CgogICAgLS0gc2hvdWxkIGJlIGEgcmFuZG9tIHNhbXBsaW5nIG9mIHguCiAgICBzYW1wbGUoWDog
JSk6IEZsb2F0ID09IHsKCSAgICBpbXBvcnQgZnJvbSBQb2x5SGVscGVyIEZsb2F0OwoJICAgIGlt
cG9ydCBmcm9tIEZsb2F0OwoJICAgIHUgOj0gdW5pZm9ybTAxKCkkUmFuZG9tRmxvYXREaXN0cmli
dXRpb25zOwoJICAgIHg6IEZsb2F0IDo9IDA7CgkgICAgZm9yIHAgaW4gZXhwYW5kIHJlcChYKSBy
ZXBlYXQgewoJCShhLCBiKSA6PSBwOwoJCXggOj0geCArIGEgKiB1XmI7CgkgICAgfQoJICAgIHJl
dHVybiB4OwogICAgfQoKCQkKICAgIHZhcmlhbmNlKFg6ICUpOiBGbG9hdCA9PSB7IEEgOj0gKFgt
RShYKSoxKTsgRShBKkEpOyB9CgogICAgLS0gcmV0dXJuIGV4cGVjdGVkIHZhbHVlIG9mIFhebgog
ICAgbG9jYWwgRShuOiBOb25OZWdhdGl2ZUludGVnZXIpOiBGbG9hdCA9PSB7CglwOiBSZXAgOj0g
MTsKCS0tIHl1Y2suICBUaGVyZSBtdXN0IGJlIGEgbmljZXIgd2F5IHRoYW4gdGhpcy4uCglmb3Ig
aSBpbiAxLi5uIHJlcGVhdCBwIDo9IGRpZmZlcmVudGlhdGUocCkgKyBtb25vbWlhbCgxLDEpKnA7
Cgljb2VmZmljaWVudChwLDApOwogICAgfQp9CgoKLS0gdGhpcyBpcyBqdXN0IHRlc3Qgbm9uc2Vu
c2UsIHRoZSBjb21waWxlciB3b24ndCBzZWUgaXQuCiNpZiBURVNUSU5HCgopY28gcnIuYXMKCi0t
ICc/JwphIDo9IFgoKSRVbml2YXJpYXRlTm9ybWFsUmFuZG9tQWxnZWJyYQoKLS0gYSBudW1iZXIs
IG5vcm1hbGx5IGRpc3RyaWJ1dGVkIApzYW1wbGUgYQoKLS0gMApFIGEKCi0tIDEKdmFyaWFuY2Uo
YSkKCi0tIDEKdmFyaWFuY2UoYSs1KQoKLS0gNQp2YXJpYW5jZShhKzUpCgotLSAzLCBhcHBhcmVu
dGx5CnZhcmlhbmNlKGFeMiArIGEpCiNlbmRpZgoK


--=-gSIb34c7BTjmb4KTBUPy

H4sIACNNCkMAA+w8a3PbRpL+qvkVs7J0ImKKsmTZW0VZKVMS7XAjiVqRXl9K9rFAEqSwBgEEAPUo
V/779WNeAB92Upvcbl1YiSVienp6+t09A/nROMn2nvyun+fw+evLl/zz1SH93D/kn+rzZP/5i+cH
h4cvD1/tP3m+fwBfn8iXvy9Z/JnnhZ9J+ST1h1+BC7J8zbjeiP75H/LxSf4X/uegMZnHoyJM4ryR
+rP0NgqKf9EayI9XSt7L5P/XVy+s/A+AhfuvXh4cPpF/CBP/n8v/4zgZzWdBXIwiP8+/+FkRjqLg
F/ER9pv6o8/+NPjSaOzloyxMi3yvCB72/IcwmQHEMJiG8Rc9Hx4UYREFXz5u9a5aZ3t5Ntoj5ZKo
XJOQkPrz4jbJvlwFRZDJkyzxx8Mge4SBGcDQdI3WH+ZF5o8AbUtOgnsJ5EzmkUQ4aRRVfAzisQMq
Xr/+7vvvj8VTufvdrl4WfhXw5F0QB5kfyXSepUnuIJEToBHxCjFL7oLdcLI7uvXjaTCWx/Kj2Agn
8kb+Re5O5FZt35OfjmRxG8QyGN0mcvO77+TJPIzGcuLDUmPCtVU78DaP4EmUB0eIIYhcHAcWx+yO
ceLDo42NDQ07mqXOgNzgIbssIQH6mcwjGcBKJWQSJsGMSSjEG8FcsnIqyd/aP/LqX235/Flv//sH
L/afV+z/5YvDP+3/D/n8+9t//zaQjGimtVTKbiZvk3tZJOwR+J8kC+QoiSfzPIyndXmXRA2531hw
EoAxzOUQzTZHO5S0IUVsGANpE38UyCgcZn722BCdQmbBz/MwCxDcL3hONA1gXN76OfyeBf74UQ4D
MFDEWwhxHg4JbVOIq8iPm1KAab4LCkCbFzKZyOIxRXwJzAKiZym6D3HgKT9VBLLhpxJ3yw4q8Ee3
NA3WpqnihSf7SZpEyTQcgV/LkwzwxnIEc6dJFjLyMXJ6FsaBHPrgI0ZR+PM8EIeefBvGY0NLAzYx
TmZ+GKsd+sBJteexYAmkKYgLaCiA1TGiRkq+fCwKFs4vRjq5BO6SLMZ+4ctxFt7hBPBVMoE5mXAA
Y8t/mT/mRTAD2eJy4TjwEQ9RA1SDguUyv03mkaI6T+bZCLjgwzbGgA52CHY8DYq8LvEZOUtErleT
aQYKndGqyJNgHCKXeZLM5kCPQB6NkYmgpXlAC+VEEFDi3yUh6MtoXhD+1AdqkXcGfx5wPKmDChRA
u/ABQQEqLYssHH1+RJ7hUnNco0gArxC9IJA3NyTPxuzzp08kapAZBJMckZOOIzvisAhByGqhiJeS
9yS3OGgIcZngZkh2eR5OYzRJWSP5NI9/8SSoFPCexYCbZaaFhIbBEAr2ieSJ4jZL5lNgd6HkkWZh
PApTIGEcTiZBFsRgIVo+dsWcNCe486M5MHcswpnic/Qo72+R+MraasJDCjwFtgwfZRwEY1i0FeWJ
jM2mChCBADOhbaE0IBI+jIBWzVVf5jPA/4jSTVjR7kMYHoIpxFOgHwQKbGo5pAJc7/q0LjuX/brs
nvyN5Nr7qVeXEIJhaWPXrF9jowlRlNznYgclv4NY7pPsM/AlA6lEj1qpb262aoDeY78ComWABD0K
5Cmoand+FvpDUDzOWbTlQxaRoT1oB7oYnYUIJ8HPsrZVA6cWYq6AK3l1T8DP5jE8vg2iSI7GMNL6
7073wtsDH45uPBsdyfR+7AnY9DpA4KICBMasA0yG/1SAwDkLiNuL/VlgwD1x1j19f9G+7IM+WiTD
MN7TEUR0m8eJAGcdTjBtuUyyGehbEN+FWcL6bBjWAA46A8g/2NHx1hfY/y/MNXHROYMHsE/9oPu+
Dw9gP7/sAeBPPf1cnHd6V/CdCCuNI3XgBFJx0u32V0IMk6QA5yXhI87ahGk54DhIAQ5Z375evaCC
wsTtQ6B9XhKDZlHIwrikQhVHg2UMkq3zs+71NVCNxpIHRYODXhDncxPGSIFRm3fkfQgyIzWmhe7R
eYaFnitlhwyiTusRFYJm5OEsBXAMX6CVQOx8BD45h0Q9ekQREShiRKsnIcFqEAo3nr2hjPhha8sS
eiwfMDEuJbqbl4mK/SpEZkDMWRLvQAAA15kmIboDDrpjtPNIhd2GLIpJ3NhU+XcebJgPPNhg5CcL
s0Df0AmAQ0tGIZsiBqrNI3feVg1UyzvC78TB63br/Pynwcn7zvnZ8T4n+Z1Lz5gt72DA+QTEZYUM
k/PG1Q/dy5+aKASUN3paFcXkzs0NJGJ+/OnTjqxlAZYmOXg64yKQLo+oBUiMVAMVEmkCxUjEyg8N
eIbU3PugrVAE5SGoCnsj8pIUBFFMtHCzug3B213cX4UBA5ouhEvUb0fmYrEMoyVkaeyNSuzYW+el
uKkTnZsb40Mx2CJTjlDRMYvjVAziBuhxogIbhM17SQkL5FUx6VxYMMdId8jzXLUurn44b/cHbzvn
bTbq8pb4q1Gy2Wf1RMd9B77BiQjs5SJReSJsY+dznNxDfjiFeOMPISovKjzaKhjCzU05bDC+T5+U
/RM5IadAFHB50xDbozl+vQ+LWxW9LrpnbeCR8SjgCOQujolhcOvfhWCTkDqomZJ8SwERLsJwmSLy
uOBMCoY0EuDcuySZAjbMc3YgHs6zHNJDzt8hdc8h74OUE+SRzcCL7HBtjrlkGE8wHlC+wiyglCAv
HiNKw0yMFAJod3YuZ1DhaUVAJ4qijLBWr4VQSeite7x3X+K+ESFYVeey0wdrooRSgFLR/ArYzc3b
zmXrHDissoOSi4UZnOFi9gw5lM04IT3EagUSjIIyC84ES4Tj3nEyulNiPyynrRaYMsYwCJstqx/M
wxTFaLxr/5iCQQaPGZYS/LSUcghjHAzPuR8kUeTsS+CUZWGKg64Q0wpUMfJfiqG5KVbuE4k6rihA
TJCzTKcBb444gEIFcF/vko2AOMgxDxiaYs57B/pVVwrqOG3YtKrWTPKvUXH0yB/jwn8QTMMoyRBf
EpMBqUrGMZxKrtanUSVl4rvRepJ/SWa0P1WP3Nycd04ozxn0W9fv2n0QDtNHGxV6oyQL2iYQQgVQ
YkOqibjyPtDxVgvQHyMqxCFYsk5Nq8NI7eamEn4+ffKqHiycxOV00nXClFcK0ndwbWgTQu9/md8i
I1BZC5k1moOyhvjRqRJR/x2FYm2xGghY4uAetERQzVIq5WrJrRY0OTOlcVXnh7DI8kK7Ptx4Zeel
nTguujKiXbVlBCnEak4IYOCg131/fQoh4RmGBGOnkKP2PGGZXtUS5HdFZhg+F8DExhvKR+79LEZN
7iuRI2O3/kePUpZTmDixqRPsgQnyp+ft1uUC1s1ryjnG5XKZ0yGYXQ3uznYRBfquEANSeeQIylXV
wtwKj6h2xd7sDyDLyBU+awjF4l2Mz2RWVHexTqmiD1t3qDw/z6HAhtxQiPeXnb8PlgVkao84QqAh
qEpKUuG8vZb6RT4fgv/crm8bmupbtSXIXQxn/+jIZRjGd+HKyWL5QFNuw3+23tMyAW3RZZTnoe5c
dju9Nv36xtsUGzUs0LZq4L64+HoDHHemSD0BR9zss6RsKoGrpl5cpDcXmSgsJoYRSsfemIb8Qr1b
rd8Wi4VqVura7dea2n9+vvnD3tJxfL/DEcBXzv9evXpxWD3/e/7y5Z/9/z/i8/v3/w/+3Q4APgb/
hOQOyEVflExgQoH9QP2cMxjYPidSnKKpFiA2KG2Qr/PvxA/9O9EJVHFmbzsL6ArpN8AUrzijhGe9
Yj6ZmNa7zQw1HgAS1UQAQw7ExoEpBfFLNodybBaIp6ugNQCG51YXoChN4UXsEifnrdMfzzs96tq9
vYbkR3bO2qfdiyt53TnD55AOXfevO6fy763zd712/4A3gkJTOTlX11jIJBjBMVXB9BZiP3IdNkSL
MhEDRN29hGBFhI78h+d0cJHDL/jPPv6DJPIcyMEu2hx0W/jgPByqkfPeVU/ySOTDin4Bqe0QMob5
EDYZQU7hPwQPWAWr3T4fnLR67WXwepxaVYNOv31BmDUoHp4gGP4kzPwLI8ff9fx37csSDhQErQJA
QpwFaT4w+1Wf5nH5+YBoo6UrA4peRVNlkHZd5YVSODyRSHUirgoxc/SE0qGtX7m5lM1ugPK6qgH9
dA++pnWVqJbYBYkOqRk9MbiecR/YYqd0qPSgKcvYdRvJz/FrLp3hBiQ9i9P9VCUwAxi2rRlg+DJQ
1WQcJCmfTSD/hRHdb+BBReRf4YO7iuFF6eEyfvB3xZCl/KigWMIThWMl/HLGwFbOOtdqA2pdfuxY
MX6eWUsWF+2Lk/Z1z1V1IsExQk/g/AE23S0YrEhPMbi4T/EULRs5+m85Yq0LIawRGB1SZiuqLbxn
DoxB0rgN/PGSuU+tFUOxgrU5+IMEsm9sWWDzkQtCdol5AOFmXG4SOSU+ljl4kwTL4Va/f91+18hT
WJVOVCGlDoNxYznjc9SXhY03m2s2oqFJUzZG6UpQqBbWYe/jGRedhu85NJua5QqKCZAUNiugoFfM
mhfc9wCFe3h+FmZeZc1NrCHxAo1dONljb5tYpU8U7VT26GfU8ociWD5Q8amOF6i45zw3inCdSDnv
BCztskudDghBxFPyoOQdKezs4mlWOEJniN8HuDvsLoEm4Xeu9FErHa1/5owteUzumZA7QY6xUwYB
dpbj0O4HrOOOdeh/yiFwV7YpuEBoAf+MjwaQbXHqAZNmYRzO8Ki+EueW0rJvDJJQc63sYvSkY40K
xrFE/cRsad/whe1SrV6yOyc6EpCh2AXSDzUQ76ZiwTrgOuu72Jyn7nQNURq2dJYZuN47OHF+KeVa
apiXUftc3t8meCfgFvKg2l88JUFMWcp6hRJfrVl6tOJonVGNdbU+6c0jaUpmrBEsb535OSBOE8oM
e7zFa04naY+ws7yUw0KuqTJ4nVUg7XjsOuiavPSZcyxsqtI9laY2EuEkrc31kGLd6Nq5UZ66Z3Im
SV6LEiY1F12Ni5Kc62tyo9i6sF0RpyL4P+ppVI+Kfo8bgOvr/xfPD6HYr9z/e3X41z/r/z/i8x9V
/3MtzneAf2Ub4GDxHuDr1+COyRuTy+KivHRMOl13I6diL4sFfQXZzB8HWGrRQVc8n8HG6YDOXBsb
B1E4CwvuMuzgDR9AUWs0GpDaQJXt1eFXb0fKtr0KmAf6zMecnZGHrdNRNd0ZnCQZoFF3yoBjO3jN
Y0dd7eCbHr4mgip1usWIF5+w9T5RRyw5X7nAXdLtDDoFUTjCmE7U8PITJKd0i6R5vHBDibbg1fH8
yHPvY5umcBMeSp3aNuW5OsDUR3GhvS3Jh6YaXJ0t2Bl46KqOPWtxEu8aKXo6/GxsXM9ZKOoUjQ4B
QzwgxSOHx2QOkBlgQ8WmE2eaqVfkdklTmhVt69x0fiwsAra68i0daVQ0CjKEHSwNELJzeXr+/gw3
wqBUG9z6dwFLRB9UO+m/agS4J03AeKeho7+iQfa494MlP1203EVpKgpNs8GlozIZKkJ6BAg66tAr
p2YV3WcM7sCMiXuLB1/lkzFrMKsBF99EWXbQZl8DcGhSB/1hzs0MdYYOdjKdP0K+vAQNJ0PLBvh2
2Krsr0zDAsYlmJRpaGPQJ3GYPuF1YVQgTAefOvrER720AWMoaHRoLBuUjnkLjTNlCbbHZlX0EXRf
zcIGWdPeNsZrbg63ME3MF68ZKiNGBHYQbBMctuSU7mRwcXLd8+rzWLVMPeEOWAUdXPzYs0oH37lj
Z7/3L65IieGJYpSivH3eV00YoJd8HG61vlVbwQ8P2zOqyNmqIaznecIALzn1s/XlNhSIFjOubKeq
/SydqopNhgT51xCRV5crUCl2LJ4dzj47c4BWO4WSdCBhcNG6+nXcwPoYPxW6iTG728uY5Rnedy6h
IFC91cWtL6TI25j+Wlpwot2BwTXofhuuZBWm7snfmKhFNN33Kh9fSwp2vLT+LZdnnq7AUFZvVYMZ
IDKGssZXQXjAK5tBFUgTaMCsIFww81TR5ZiRwudsTbdMillqdXWAuywWFXVlxbYoTArvlPqMboPR
Z35/YTxPoxDfTcipn5JN1I0PvJCI/8ePehJdX8p98OOPjICvAKgrJTFGGgiLaUoxkS6t4omCuVfS
sBcrYGycV8ynbh+rKwHuKGx0lMxjLpatRbk+AOHgG1jzrkUFK2NCS4/rCyi3akGWuTzAu3Lk3umC
BMIikL7HYShjrLt42W17d59MFGkjnMol6gBeVijuHpf1q6lDAF7SZgdemgEFb6LuADwO6PaA05n1
1sBOIn+aE+wG6+0aWLwqHek2rQLCxtKyJRYBBKYmv9r16zYJJTZuBPjQuuy3z/QutSgJyvOESoPO
yqNG0Aym0OuUiTwl5CL48kpiUmfO5Kg0oQYvvlowCWN9d6t0/cucmWH3IAK9B3SYlM/82J9yM0Vn
KvpuId+VUZkq3dcx5EG6/yEsbvm2JKakUFXsKErImhbXHQbIWUIeghmkWUCNnDws1JUt/TKENldG
hDdGMr5d6YN5j7kL1BCOWn9AkTLPPdlpKiKRxSXt/9B0hLCQgKj5yHj9yGJxVZocr+kUL4Zjz+0i
b9PF9IGBaMrljs1tHXHD20Uq+Ho4vQCGF7BKnSQDWGolLSJx9J5jh7nG9b5z3m/KTRgHBcKTG7zD
g52l3XTVNqnjVD4tqIZVh2U2eCztkW3rRlc5IC4DtScK3PQC9E4atyIN5iyYlHAWYHWMhRG+T4Em
lPo5lhnj5D6Wd6Gvrz2uSVBbGIfQzHbR3iX1tSnw7eJbsvW6seVtfmDY4CZWqFPjIN0dRQldY0Qs
9Iqtdj8wWFfT8VaxdIDhEXVYt2rw0FOuAXsZ4Eq49FfbxP2NsvmI7yeHkLVnhR9DxAvxJSvV+YB6
PJcN9QoYciaBQb4ESU5liteoTdIN8JOGpKjD4Rf+BwMbu29egXHSOb7yf0S+4Rc6Ngj07/r44k77
qnO23O2qDSIeskniXb97df6Pc8fRKgSkf+6MgbMIvTmzNKmspOKMjLGihfy6BNyZL55ap4Pv3Kh3
txVF0oF0AIOHgmAt3EcqqVYLn3nDvklvxcxWp1l4vGF5sTwvs3MgP1uJayEuq0jL/DZnAZaaBT65
+MgRKD6z+gaonWiiOl7oS+qsy01862NIHFohl2XJpsNqP1k6WVbUwJWO+Dq7cBuKLo+SNPrtmyZW
kiKTO62q5S+7ffmhe/1j5/Kd/KndV5csUn/cw6u5fAKE1ytSP+Nmla3MVzkz3b3x3GgKXl2ato66
ZKvhvFLfZllhqXa+vafOnLDOXIvk9IdvwDKgdH0pLlF6QuhsBF5E4AxhLJE6Cn6P4UT9vqNvYluk
7dMfd+T3JaD+D52eXpa9y3dVENP6qbaqNOC6xs0pVSjmHN/cRafGHZcp2Kr8imyZdmDT8pxU55iY
vbob8r6ep66euix3tfr1zTnXb0jSbK+NZFwhzNHJcj/S3nZYM8NMsU1PmleaIITT1KwyZmUIUpd7
0F+r2YvSqDZMae01ixHP14035SkTtGIDa6wb83xizWCbbXI12eKplYmD2RNLbUyUgYyxlhdsGqvd
dLFgQ2GzZMib+jGb5+avNs/1eeVT2SIHTFfdqLkwzRI+h7F/YsH81QPboC+SaUB/r4COt4NIvfeU
zovKmYU6hlDqVj6HwBf38L1BvOiIkJpvpKGvw/H3FlwRYgs8VYph6kcvKrlvwOC5SxnjWfstNqib
8hJrd9zc7LNK99Rkfb+ANnSB7zGZfTAq7YXDcVMibSq44zEPj5RYQfQqBigFwEmOMTbNyR9hskhI
JqY/vSCURNe0PrV24LFv/xrH16UhN8o3I5ZJxL2AqnpySLy+g9Hc6ClmORzENF1Pg6RPd0lZihKr
fijBJ2GgUu6FCRvxsMnvV8MTOvpTa/yXqQRUk2uoLo/hfS/a8Bm/06o3WGlpfJse0WloSeQbG9ix
oYOoKrH6ZaImZbfK6Sp62d/OhllZxIZTpkAgXDu5MTM+6UggVya8mtd8Me4r/F4VQI2Y3Teq1IkE
p708qiVbOpkQzpUbnSVXwIWw3XA7rIoh259TpY+9NONCe+WYoVF7yo2vceGLPF/05S66hV5XlWQ3
HTAThdgtu/+S6zcodKhin6/CksN/d1S/dWW46A6u31xzTbbHiZG9fQaFSTWbg0f6dvZiqqcTQSKu
51WHVT2sdrYw/NVIZDsZ6uQ/Vm9javtW78Ra18fvbWLgwa6gfnN6FPL7s3iNFEt9+tMtjEOVEKW/
j3PPb6f/b3tvHxtZlt2H9c7MalGljTerwDEiKcEbNlus6i5WN9nzoS0Oe4dssme4yyZ7WZzZGXX3
th6rHsm3XaxXXe/xa6Z7jThAEMfaxvYWPB6sEK/k2IbjCAHSSOCdGIkEJJEC/xMlBuIgQCIkCgzB
gP+wF44TJdLm/M659777vopF9odmJNbOsqvux7nnnnvuOeeee++5HA0FVz+DntPZ69D8DyNs46tV
BksHnFYlIajwqZfLVBhlM+ysF/o0Krz6ypkEZicpsdZV82e8QjWruoxI2AIwVXFExH6DNNPy4loQ
rSVYbsg6DKa5zSYNo1eye/A9lj5aRA2TNAZcVU43UiZ9t08d9y5KGkHN4IaVYIsXz0FwV7wJuC5H
eq7VD2hg9/t+FHnqzvy+yxGD5NIj6xOcC1ZX5oMuweLjIl3Z55503BA7KuoiPZRIW4IYIJZO9xDQ
/IiDN4V8JZtjG9XUFn4U4IhIQIpIfm8GJCQl7AcYaipkHU1r/+iwRtw2ATcwwg6ZEnJawut4HIWE
2SxOZtbzTbQndQQaqTWn3Sdm5Sgmqi7TI9jz9L3srncQcV81aIMRAOAEkA71U5OTHBlsFCBpljfX
0TDa6Xu9DiJ9aYi6Bl/xh/fbno9seagBmwUv+whdoXlkSjj9LCYDZ5gFGCODZZkuhfh81ZoKRXIW
U6OkZgfzuTRRU2s5pt20tWk1xcsq+StwhgNRW0mxlchrDG3638ngJw4tPWMTn6MwspEpmTpmLyvR
jFBB9wKkTTrjWEnQNGpkXYZIZodhNlnJ9cK+clWzXiiY51QtdioRLnq5hPR6GLk7vQbc0o61LOMq
w2vANrfkBHxOO3fb0oW4MA6LDofDji85imJnD5eEcaAbHPJgoQd5821ExtDBBNpeq+P2ZTLI6ali
r8UytoGreWdiCSW4zvJP2apMdLJwrcbX6huiP9uBF5ptLrKMQ4+rKVeLBwYXcRFHSul6CEDE7jRl
/6Lb2iquF3eJ260m3HXxnvIMkvmylCcn38yCuFmv1zMODez3KNNGYgbkpxtDSLZLrMUwTJTrX0d+
OpoW3/I+2hfWPL6PK+5DxlGn1KkxWgxd1EHu1F0UiaVqtPSRLgpYQ9qsTa7cUqZpAiTYL5mQ9EMY
qMlkdidmojWkyWgATzgZA5HTT+pJPGvvcvGeLkc+y6UjNsoTJDUnTb5efFCFO0k17+izQ/FxwBQ1
LWjGP2vObyV2Ts8lftncio09ez+Sfpy7VnUWGrEr8lv61GXpzcjD9pulHc9d5PI1lKJ8t+8ASkF+
OYlyclh1j7ODnRlbApAaVdmePNF4puipz/KUEz8TW81khtp4qjtMTh6ac6spRGVnIh9XdEKYQrlK
jr98SeqKunbDiMKA1CbjeOduendmyLGv1fmvVXFuK8GK1j5z1aYfQWbC4V+Qx6rcyFIHGihFnULS
HN1xJd78DjoupzWLT6dyfhyrJH3wMz6zemSoGDl6enQxOT561lmIz0LnCAxFszKl2pe9jQlmHyxk
plPyFlDkmJJVEyFIuBCW42SpEIvinMH5cikKdmldOBk5U1/5ylcuTdH/6EM5MtuKNfs3EKRFnejS
y1a3Fe3yrnfbb/NqV46N1OsZNQ2wHIlIH6Z6pyuePA7INKFam6g5PbluKDcBsE6J4b5ssFEkLydC
lKRuA/zZCDJi3WdIcu9TbOOo+B+vvpKJ//3a5Uun93+ex+czdf+HW57sK+//E9wGupx3G4ihmxiY
OQE6hl5pyZ6PjU88DV9ziINfeRoOxTPDiSycabUHh3KTeib3fHRkPz6iX5NdIBMhHIk1da6Wt1VQ
f/39G7RafAN5V7ABwKBY06WikZu9EOsj8eriRedQMGIwqDNnVEWdeC6wVbHEtex+01W1j4rfzfW5
67nnui0AvDLOgZGvIvXyW3/dAt17oTbZFNaxzaaRTK3WrCVY0jIhAMb+sI4gGI/B+VTuKCsz+KL4
LYoEEe6fux+fYkOhO+eUI8bujFAw3R/lTVBhbZOk0GskXVwl2CXtEnBlSAFVAt0gUO6B3H1V69qr
HOhR3Duxk1vOXMGD4Vy1Fg2VmG0lt2qve8fGK+DFOGms2gqctZUmBx4Yc5hwUiQugW2eDZoVm24Y
jeWW4CswFSrj3q3mlZiodEheofVED8eUoZ0uTA3eM1H1K/d2Ecu8ktezai6AMVX22jsrV9eXVld0
cQ0yheLkm3EQhBlnYW6uuThLmPIXvEbiHeBYoWTMsHGpglATRHbRv6FhgavjkWU31Pl6J9gixCpW
WD/ghmAdiMBj+sKxF8jkAsCWG6Xm2MXxcb9OX5z78lrBfWe369+L27OLUdszzE/8rEledk7yjOFn
9oKmnnOp5WNTszldpemOdD2Mh1i8vECKvZSxdykpOKopT4pOl9WVhPOYvIJdB95rOMHc7gaTulpi
08Yulj5wNXdjWPCYnu0WMYwdn994a3HFmbtB5c8b/Omr27N9UbZf0z1gnrFmPybofrCDGMAyR68c
XSVnxg6vkDOBh1aohH6jQXbOJFqYpLUfrW27fmeUukfJgiPahWiAg2qSvXpKONwfP3+/6oyIuYag
bvjF8oU5X7OItVGMAERwl1cJFmTOcRoSdku18ZQa0Ltxk+7BJG/PxXSx+seNHQHwpAJwxon6u17V
eaMAdJK7CV8lEJ3pK78wZdxaoTgS6guLy4vri3dIYC+ura2umdio1kRUogCgIQkCjrKVsFXY90Gk
JeyUW0Wi7hsfmG1nYqlepzqx1yRb07Zalps3Jq+sNpzkRQLN171+sNV1DHvb8DgSbO/iZuDu3OnU
g7GqU1GBoWTkxmLHnTiAvkUj1iDR1NuNdIk3UWv8w/n3Fx9A7913xj+UNxMeMJmL0LdxZdrPQDrh
Cpn2Kb6ZeJdLgt7atcYc9U6W6KVRGzLveCFcv3mbIhXBQ4co/Qy6DFTf3dDj/VQatqfvAThi/T/9
+uXX0vE/p185jf/5XD7P4f0vm7lO6AKYxxMr9L1nX2DJLOHjcBuI6ales/Icd4NMgj3fjV/701a5
nL7xfD5f4/IrAzqUY82hctgbLUvQiQ2NQY9DsHEMDj/ydvh23m5PThn0PXOQIWw4cxsb3p4c3aDV
dc0sku0FkOxg6mcq4s7V2evRTnoF1MEO3LHbjagLEdm0/NjUEs7/TESCJy/+207f39qOyBDYJ2y/
yf6AbpBce3EAdV7388FXPNMlsfWFPPJwwoZNFIli2ukQnuwjqVTmV1cRPbxadkihXltdu45vK/z7
xhL+NhEfDv+ury2tvIVvq9cXFt/Fl8Vv4K/EkKICi2/NL60s4Os7K0v0C9/eXbzKmQvXllfn1lFo
/ercOmmQ+4uszu/TtwXZuL7v3F8IdsnAvEaqizLuN73oqryFdkhmVQX/VQFLQB0F6ygo1C14NvDv
wur1IihLpDG3vL7+1nc7C0zbBKjm+9fnV5ePQqh5uLMRdIb1a23uqsbHuba0uAxayqegi5g2xGtI
nev1Oof3YY7YJdbzEL9/zfc67fvVZNuGEuVhLbrYvfDa92mNdqw2K/dxj/W+btFu+voccdZ7TkXY
q1TQ8nU36vsHw3u6Rou54W0137khDTl62KnBovHquf3Qe6fr84nbyLsRdA67wQ5N85GwyNDAwqOa
tED0fDyR9SH6v0no17/t7rnP5AHQ4fr/ldemLqXjf7/66qXXTvX/8/h8Bvz/TQRTpanQ22a3EVwu
OuyO2/Gjw6wvX+JI4AUV9dJfIvh00FOhjkM8UMSAw4Zu1utSb7AeJZxYv6ff2FTJV4Nu12thG8K6
SsB4WBDwdKjo7Aq/GdkPNtyNzqE65l9l5aqxlJv72hZhw0nveLCSL0f8DKMX8ilJJqMEsAqcjvsB
nxVVJz7lXJc6JbUTALh+m8c+NRzw7eKsVXKoX98woafMgdmaOmpc9g6Y1LCzMlSQd5VwxineEVDH
nOWOLKJsEuGxX1Fma6VqPdnJjkE+AMuIUa+Iau1dRpUvTlNboXdvVx6g7CrIUVBWK1H1OCvIZ66M
cN/nOngVNdreEXMn3Pd7+gTwBMlaboSP0vKhW112okYj3d/BuhKvOclIoD6NRBQdEj30lRK2jYA9
W0Zyi9thkbob+Z36+ZlEmh8gpcyTzoH0dT5kxVnmv3hqlClReYvZnnm0qoo8kDIktmiqOgJBin1Y
Ll0nE9lvrwcrQdvD91mOufu2G27Tr0p1plxq8hu0cHXFeZRm8rp4WKogzwy3OQsWUidK3HoF+PGx
T4xe5SpNNxXZrr54/cb6+7wtA0APTA2+seK3Q1NzKQKfgbEhHmaRV/dVGiOBQvKOaAXpdTK+V4gX
SS0CRKkZ8WOfPk7oVuRHlWHVu1yKIJRAGe6k6iN+V/w253Hf6267XcE3TrKIWe/tRlSy5uhMGQ2r
Q3zD7E9Ff5gDqeIycYpqGeEPa476TnAj001GgXJXBIsK/q3abFjfIiaiAroRLtgOo+EVuA1VQ/76
m07FVKPu7nY6ZPKV8FrtPndeRaFdPGh5HKlcw5Dq6IzTUXTinimkaxoZ3ZxKB+lWdyMu2tF5qijy
lrpxFhGuXKJVIj+do9efhnSGViQ2dvvdLHGqzsvSITVD8LDlu0vNpfU717654BDOl2bsxPm5q1+n
xClKJEncDX2+R4fT7tR9SuSptYewLascbSLus9dGXoWJcvE83hobJsxr6jA9qRYXsjvaVgmh5/Zb
27VyiciAHorYgOxUB+xZmnM1deBfauhbAEGvFyCojAh1nCqKj+7XVYzLPq25U7cGEAfE3Mw0B/XL
Jb6swu8Utmg6tfvUtgRTJ+FNKOR0re6cv6gZHYm7kXc1K95iqSbyzyi5rIDMm/AyATNTXg+UGtYj
pIA9w/VUScoAzAsUACu9y7F62hXDPFVMlUsCCi1t7re5TCwTHuipr6dJGJmObJANuCSdidmp3rGK
VKz00P/AI7STfdIg0K8b8MQEu+GQvpniPVN2eB8xF9KdZP7Xt67ymF+Koa2YGDVdw+QDI60U8W8s
YjHq6dIxexiZS8XySJyjSAl2y9KqIk+YO82AGWIZpmSChDmDXnMmp4YxZT0QsRYupXkTfHnhwtFc
aYRpBd8K1BL9VDK+g3FbIGmsbixZg6oKDWPeDOuqOpbWyuA+hDaGNBbr2lrSaMCYPwztawneMiOh
b9TZYIqxAMseOUR+9/mPUJNvfowyONasy04mVSsxoY43TkKhKT0aTHNYxENltFyBLlR4uaTOmYpZ
gX08YZ2UGBWVVCi1KW8E3kfnm6qUrlaTzsbUTdgYnGdzcwJECtGaRbyEeAF2J5EwqEdChv45MQOn
OTRf+ZmOUIqW0THTXhVLzOuLxWOY+iREl2oZomf7FCQkitIBRxNUc7vF7ujGEzJ41gZ5ThaHRUNb
xx6bZfMFcJZTn54iPJJAqxt4Ks4JsKYbLlUV+SpKBgfVXD14fFVoUdUI21zKBhntNopyZC7EbHK7
LUI26JulDC0tbZO4yBIWOhQv7mSFipKE2g23z4K8W3OMqmDg0yPa2SdaVoMGHCyFkMxyebUeBVJQ
hiicNkREpdT0V/wbTicsN6trQo+adMuL18487PZiViAVcWyhUXCkHYA/Q02BHmMKQ4CK5NkCLyOq
i1nZSvFqbHIjFxRSGdootmggOTXuf8IojlU8QibccKNts3CeMi6HcDrpcOhODfE1TCX5cHpI0Wld
VDEZx9bJZ7vEWBtUu4Rjd9p0K9sXhW5NIyNc4IJFkpK9UyzVMQBcIx6B7pTmZw7oD0lGayZaW3a6
lbF63VnQ4YbHmNoK7XzHXJKbpSFm96nEfCT8RHy12FcchVaBJ5uTRm4OVzlcgIg0nVrqEdX43+Kl
niohvZo2yYoqKldxZYkPCiUa8PjafzzmhIiMugyjBsfzBO9B+eEiwiXo7pX4jShDUDMalKyrPsgu
E48aMpY0GJjUoAgxR5LTWQlTuDI8+VJDlkXZJWCBEJVJJBk87Vi82P5u7iA1rEQDTWqqow3Bljb5
xGN287Ys87y2IgHSpm/PCOWUPC1weGtaZLOluRylCO93nT22jBSGsre7QRNRy7FYrWR8ggnlEdrG
q+6brTpMPzHZvEg1pksmbd9UUzaJbHevcmjKcMY6Smgkg1hNVdH+0VQdTTm7ktUzbXfAE+bX2CG2
2dkytdWA3fRvY9J1tmZip+hWqnK6a3FV3aZh8Sxnp+oapBOSCy3H0yStf9OD2M2FoGZ1LiNjtD60
Nl+SnJniRJMpKxFeYA3h8ynmc2XvuHANj8yOsm5IGEFZZqbRgDWUrcxt2QxZ4L0qkkvF89LmrsLK
zUIdLiQbquC1cRzPH0xqYzqLyciFEtTJFafDHDknF6jcwVioakstbfuP5PB7algUiXaehJoLRFtj
4JMS89PHC9Y4h2wpXkouCY7l8X+ixXYxP5Z2vP6Wx5rIXt09SEs+v0hc5aCbEHdpD05WYIIFUvUT
LXeH1RcOyjSv9NdSl8cjr46thGIaFIiYwtVvhqAnmMTShb6Hy0aJRhRtkjlPPOXIvjRayqwEOlWc
REvqXdUuq16xZ9k2FYLENRPiIzaqMyrf6muu2Embrs9a9FBfNI42GVLoH4MISekVUyJryNijWyz8
Uqvb5274WHZ11uxg6n4oUhmb3cp65m39GV6/kkWnM9W6NbHlzzKb8rAzLfVNKspRqoAyFoBj8UsK
calvF0wQM1XawLVMKmWTqC6KUKCR1db5zdtuf0v0TQWSHudt4ODp73YrnDNjA8OmOIfa9bvmnJlj
3gbEg8p4XzBy+xGeU1znU1nBVt/dkRh3ewEtPXlnmqG5HKBCbYfjKGiwiwNIW3xmTgPgGBYI4bjh
6diwZluiJmC0G67m9Gj9WXNwUdCLd0P4ABUO2telE28H+3goqSbxZvmpdJSI98Fdjggrb03GD5CH
rW1vx4sXXROmAr8YyRWiwBwIk2CWHf/eLkckVm1PoLlEeV9C4x5m7/7i3WQ5IlaxLq1v+20qxMCs
Y2lywo33/DusMjAMfX5sWE6B7XhuNw6JycfX1akwoaH1VrOKibuza57S1MfFqnUufP6izVnMUmCX
LEfxXIyN7B1R5Mi+eek25hIkDlLr3r1dtxNWxgxNx6qGuTVF87a3FItCoBgRlgBomCMH4Jzx3x4J
BoyVA4H9HUdWTvFjDpxmssRxOgiGyoE4T8mwEI5Gjia8VR8/l/UTi1ZtSwjwgGdpmB3+hN9urt93
D9nthPx6x+tuRdvVmDmUaGTm4JWZZh4FB/0sdmNhvlT82ekZx3/Dgk8/L1xI+JNf5gb826b/k5Nj
rBo7rK9Urja21BFD1aYcZGM9pw8zhZ7Xbfbwevqsugxn4XIEKrmYsG61oeL+JVQmNLLf5e+W+lK+
Z1Uc/dB0SnVHebusQ3MqT8G7xpHI8Uf6it+VMb73PeZcQI0Lzhiuf49pA4UHg18kmdVL3RB3HI2R
RwgsWDKtskUqvV3jKsYWTmyj5Cw20uam6V3CLi62ldKdLjgpmFAjoNxcp1PZqscbPH67qnDOcyg3
ofF4O7LhjF1wDJbM3jnlzaTBm1UX4pZ5nKL+ocb8Bip8s899xy12oY+VWtFDpX6yHWKsbyFZ3K/j
rLxsfO2dnyT7oRRe9fH06qblRqQ1Kkur5pihEy848khhyjHlDO8MObboaeYpEknFwjQrolTKplrQ
xtKHudtRpoTN4WZycJ0qD5nMeMirIySQgNOm9wjCRipUZzIrVtiWAuzpz4Q/CVlQLm3Vhx011EPS
aqGJeuFxl4IZd/WqTLUWztkWcs5oPDOaWkvZPu00h42os3LUUmmIXhpF93y6lMBzHfgSwoh7VrW2
BIXiXMUVWbbQtlSh+IiC3jItKToJCaLzDnvabuG8aSvPsmk47/LtmZJlEPVCO/OV22l9iHv+ihNm
ykZkETLrfHM1V2ppVBGP5uJFfcc14sD48hS2e3DJwAKCAiwPllFzCVgh14rREVycAnQUdRQIDmjM
FXCxlofTACJ63HD9fkG/NLUUoMRiCs8H9PwW1p67Paw6RH5yQ0nxmZxRXEBkb3GVz6zEtXqlOCbZ
MZhmmlvmCk00ENvcKMfwyUEGec5BwT2SSDACeXbHBlcesYxxkMZKW2yu6dmyXJDqWSuGWFJn6hcJ
j3W8FsET21emmgJZNfONurxiueeTjcBQlWPfVNXMpfgkuD0Cz8qqVfixGpHN+AdxuzFOz6nlUnqO
6VKsMpXBqismz+V9WieaEckHCn8ULrS1D4YculJLYIP+QY5j9+Wt2Dcr1r5yuia8uPG4msJjHAIL
nUxU26rrm0zJApAWxjOcKWuXUMsBjK0ZQi2rT8BWiIE2dAgl5+ZtkjS+aqseYvVbGbvp3Ipum5GL
0UVJUso1rnLzkrG4n6PlcfG8c6Pj0irnLS/5lk2NvYmyInDEmyNqRjLwbsfY4nvr0069Xh+TvTAT
0ZJ9lyhsl5yqDytZ09Ja2ybKE+l37UgbgJd7f5XWcwwqoV/L5y9mLauxkAyJsaRphX8unpcoCOed
RsN5Vzl9cQ0Ub9pzeOHQUSUuZk648HiYWSiTOWuTp3xD1oKacryVXRy7X/NcnBTut63TwoksY1qo
n5vVJAPiKKA34yQmt1NBIgEksHW8TQegYHF1f01mu5j0KJnek1Zu/M7zXktbw2PvE6RNCGVr1mJh
q84bS8fS69POiWZ/UgRmp3+hEJy5eD6PKNf9MNQnWpkucu0RLAtwLDKpdr5sKyRNmtvtVV6CKBbz
pXwNsiIkdWO9Cjg2c0LHj+WMQH37VBzfle7UGAIwdq3tZi6s/PhYsLY436voM9xTNUd/VacK4ysF
5ogp398IcN3Syp1O5k7zBQN9sq87VTeHY+qqzfWg0p2Ok81mIh/9K9x+7mQVbdIzp0LLsVrTBEes
2bGUXi46fTDifRWDF8ouRYmbHgkMjefYjdhrOJPytRVgfGGWdYl1JcYiU259DjmYAHInF4ImyK3o
1i05DKsoonuSpkqGxrciDXgpJgrAxiAf2CQK+y3z3aJS8jAEajVFVeYfQ9FoWtDyMM05QWLXiEfQ
kSWm3rjWFzisc4KmJ4nejzFv5o8Bv7J0ojGwiWXRRcydLFPFtLAKF5FDkTXBzqmaSbKkRtsRG7GX
xD852BkS5SXZqu94nuQhKm34dpV9fv6kO1V+eyrP0eO3pxM+npPsX10u9AUec3/KwPvM+AGf1mZQ
rjG+VTen02n00PQ0T+cMnyS3P81SI+3w6/gbPKPz+IC6hBiZef6+vhcqqmp3X7mk4o84O1aH7Xgk
KQeDTQ9zXjDXyxGzAW9MvDLUzXwUL9iMoDoIy4XoAIbQ5NACTjFIJ4yOYJBCvT50DT10CT1k9SgL
aONesEzIniUiE34Ljnetb0koSicy4pNMxjjNNqDo4QZ6gzflGzG5M+pEo2kmmWcttWW9xdezK4qt
agbDlDM7Y7hKtZgph1mt2fFXFTRCx7dVzUpqBGvuOW9RjqpY6D87zpyKbfQZjHF7+in+SPw/E8D8
TyD+3+VXXrs8lYn/98rp+z/P5fPZiP9rHg8RiHJiEAca237YCvY8rReN7ZUTElBZe/L4e2iOdvI5
xEa5TIsggsON8BsHob/VdWklr6IacbvhISm7A/WeYfktsbe5aYmYmznemFctFdhXWe3qkOmm6/c7
h04/2N3aVm8Uu+1D9c6peyhvmZHIDp1DRGHFWxNBH4/CQcXtdqLQmcQR1X03dFqgmddG4HuiD4aI
X1rD+UmosL636fU5ip6EXirLW2xOx+1u7dKo28GIocVwDGyHacEvvAHI1raKrWdoZfeGi1GX8Dwr
XnjDwdaNQ4vufpdjGoJRJLI8jaa8b3dYRyS8N1W0YRZOHG44xGMEiEUcOhOVclHk1aPDABdWPVGl
I4P8FtYcGtO3GEkdt1fU+ZNF7y1uJY7Ve/xW0jF0YVIc0Z6K0DtCa8Pj9BYTuzgg7+iNFoblLePN
lZkZZ84E1JR3uGkGem0TcJxkhDp9QEUrzMk4jXxBMTXH4HbcDZJo1XLlPrH7Ip9Y9trSXHjfKRPn
358X/1qG1xfv7boS0dkaPuqY4es45DN1pLcbXQv6OwkOhn1sDQbqrgTdFW+L4O55cbkbCN6WSGl6
W5Ax87QGBam4apO+dewyQ2Ii3xdTPZ4VDAFlSe+6HQWest9lEUFfVkmGEqLbC96e3/LuYwCIrKCs
URd8sh17OSz6iZ4oUKaFDUkh4y/hp1Im1Sl0fFd6gtYYYCa88VmpaCXmVCBAJwNqW560oBqkZBw8
3rPNC0QNgR32pVIFEtzhQnomOISi/WKaPOXGORnoG0ngcgmjIYISUlY9r6G3OivtQLAEvn53MzDa
V5egMgiK50YOg5Yd0e+43zk35lRarmhrVLSRZXpKzzJxYstHNasaFTJKLP50S2WFO5bODjLbubmb
XZWbyKb8DNUACXSjfzlFvbOjOt71O6bfY+p5ADVa+ZQtmf5h7c3+HKTGpFTtjQkdea1NJVKUq7t4
fN1lPg5zkHYP5F8z2Fl83d5FhTdeXxoNdSwfpxymnmqB3xwTcXVjbr7hvBN6vBxEw8yLeobIO/Cc
TCvasjMGD5P1QjxD0wEa2SNlVDhZQGNlNepsMCKorrfRd6mBLUQY4bnFCl2yK/e3SNx19+47Y/ye
8FjVKqGqVlpBFwEtuqDphFz+UNXHLpKVSv+RJXFRFb84Rmv6MXlvSoAhhCSrIrxys6FerVGlq+YL
l5jgTTO8BsWkUgRJ8RO7CAA4f8j0Q2M0WvAjOrJ/FUNTLx6NBoyGXo16GowRXwpQEggzjtI/Y5aM
tKxXY5vmCUf9LJNsv/HOusQaxYNM5RyJlRRYBX1Qe3lGJhWKNF0/csbwOl3D+Y6L2NvAgb8vAQ98
w8TLRZGh9NiJQqzY4/DTxG1YbcwdiKEgalBqV3bcHq5iTdxHd6gp6s8uOJqUr4KsJhzYhAv3nQk8
l8R6RLWq5IMI/bKhalyMFY0Z8mPQUMsBRUgDRhFT1I1uNzPUiTUShpuy+Uk+DoSNhRs6qbuc5QYW
0ez01sJdCfbI3ZLH06pJhbCp3exKBymNUqHFJq22cJggjHrqDlk1Jx/O3ZANgp5oDV1UV00kWhCu
yqkXlk2EXD2hh+QxMA4Oq6S5CBorPZdDcJWsxFo9hztE6QOW4rYYmmlA06/bVqREI5M4NzHpdfeq
dhUGxHA0iqNpOUajYD6dSJEZZREzSl2JDLUkO88X60JqjPE4z4yQyzuTqE4yBfw/SbUmlQrhfwhP
Rt7I/Qxcq1Ix782g8qbMhAgxgSdbMAHPm9/niTwcSb+/5yl2zecKxTJHW3zG3lM1MsyUMAI13Bw2
sesfi1c0SIthCrDXXGPQ12QfYlZaEzrBOEewTb78UDzQ0yb30dLkJCOq8VW8ZTdiUUoN3VHC4Rgc
kCNJkoP/zMSDUnEpG0XjmPppUD6O/XwkrGcidq7JkjLpXZtUr1xo59q+27nr9ev1elnLpA4e9ST2
U9JIs6JFXCIpacqdyNiGWKBEJN44UaqVKhW83Q0lI6kTtNKV5yfu83NDBt6keZYCcCuttqpRzQWy
xI9BpEGoJyJGAaBcHCkA6pXLkTDo4njeEwAgnej5W900hE1JHgnEAjtj0xDERTsiAHHSZCBw8kgg
lt2djbabhtDh1JEAkKWxk6nfQuKIAwkXT3YckDoSAHaDparzLflRKs+1M03jkO1ohNvwOlm6UeJo
LbOvLd02EkeqvuZh/deK1oM0jL7KGZUD3d1OZh61JXm0ibSZmcabI1VcJ0TTVfk901Eqv+2G6bp4
inCUqitBpllcHxpp0LKc6o7Ipqv9dE0c3B6h4o2+h7mQHeieZDw/IMt+pLyUaa5X8ShGBKI9oqND
ibikWQq/0+U3h+R5C1GaoshKiKOB7f2J3Z6unqP7Yl3FStBYXxxjk6wNSYEGFGNKLZsty0RwdPtS
UvvohilDKZiPjtI6SWQKG8uDoDRnAYRJ3AJgYilQ7WGwtAZLAMs3IoygGKWsHt9Ryir5n+wPmafn
yUahspMY29QAVKD1TAb1UJeT3D0qq9NVOb0WKSIUVUkXyIxFHvJGAifRH4mLsrntoW3p+XtEU3HH
UBA6bpK9OQci9yYUmGoxOkN4KA8vCOORcRpKh2M2zBrkCWYSVMETVHczY1EoFIbCgePnKYCBREvP
ISwwmUg2xUn2TfbcfpQgMCXDDxxnWHKD54URmKYY6uQzeuTJLkwqWbUbr+GH1tZbOLkgCrJj3IRl
yqqlXGkGyzuPYl1vn8SBWpU7MzMVKTvZ2SaBCQA4UpkgaezJsNZimQLHVi0ygS37WGFmOZOTcyRf
bMsCIdnT4cjqLSz3GGJFtaO2ApNTN5c+rA6Q47r504sN5KKZwbmTvNQ2JQqhSLmRJpkAcvJ0mqyT
8jgmwxAlvm2enmBMLC5GZkKGPob5mCtSI5/Pg3yQuXrUfOJS2QkTD6hqE7/zJpbOJnSKmEzWQkfI
0qGWiKwii4aIc0cYbatcEpTyeSQtPjZa2Q2SMi+Oo7+ya+EYz4Q1GFvIunZ6VS8cgIkkNZPGRyl3
hPNUJiBoH20+chn2klS0J5VlGpfS9izxsBNjKgBZVh4pIws7kEfRUdGOEcjHV20COvAb8LlpeSW3
Ls6zNPOwJyFvepsJmRF6qFJNy3ejKa1e8QJjyBTM6Pf0KoP9lvmMhebze5M3E0Ze+MQQJn3sdx+1
DhqKYQG5LfCMJb5lfJSSWCqkG+cnFqCcMsR/mYOqAMmFUux/YThZJ8wQWFkPCsOw3ShDauc6kjQt
0h6lGE6UqGDRLFeGJjt1lGF/NJOc2LzXlPn0WrV5vX8yI3cYxNFKZ0zg7LIpyTBZ8YCFDXbgDf9p
bTV55X7cryKAKTVtS5fyqDUtfWQP11FV84U0F6ge7ZopgvjcrYhCqjxPc2K4lT/c0igcmxFMDkiM
tNGR7ajZCSgUSppixYZFAZnz0UiZPlLlCU2fofxwbILGKBVRUptDc+22ZQ3lrJnaacdGoUlztMuM
2lNrbaSF1gGzPKqFB9ktyoOcDcqD1HZUHjQs7JR3+SDtoT7IzhbFjlbx+BTVkDFGYTVeIyBhS57i
4ooKhuqKBElD7SiUnJFR4kGiofP7QRcs4ZRnnEUonpB9qT7OHYSOlgPq1TMqI3HCdTriWYMFa3zx
ouZ4Uats7NLE7r46uCcU578T98/dh32DA47L/gZGhA1mORihgVgML+wZg5HFpy2rqvwnWdkWZxVZ
QPCPGA7Ung0kWV89HIeqXKVLYmY6p5zdhik4VVCQj8tXLCd0Qs1wTzT7yxuzjvJv9wWgEylezQDU
+DIMANdj/Q4H6MHBuGItmK/6eEZKYkkOTaD8ZNCfBOWstbk12bTMPpb1atZBWThH7wLHlUVmx1Mm
i+9wNVywnikyH55ovTXMR57RBoULLev8rt3V3OUV4yWLCyNhbSYydWwBzJamHgV7Ey5eh4ln/F7O
nDS7D8aYhRM+ffotzsXhd+lHDN/eHlzzEM8GZ2a+4+JCWNfRuySqWWwY6gWkMdaAnqizfCTFYnxG
OAIY4Sn8PgTL+36Ie/Wrmwj9dl+NQxIyKXIFlv6rfMet8t2GTH94xGLPq6Xu7su5etxQuW8vGNVx
cMNNdhcrgokWRgz8/riXur7Dtoa5UR3fbfuTu1Qt93+vkyKq89dncQF4+P1fSrr0evr+72vTU6f3
f5/H59nf/512wF2QDie8/IsbpnKRlv9O9r0OX2zt78IAQ0U+3Vl3nNW+s01iNwokVf4EYo1t7iJE
Ws3ZCzp155V65oIwpiNBZ6CYnuWzzuT5SY06fS2X/U0IxnGczvd7znjl+urCYrVaW1pZWq+W55aX
78wtL6yu3Zm7cQdXFZpOY7ZMjfibhTWvLa3MLVeppTXuCm4My4MlqavOQOYd8J+8VUI2Zbgd7Hb4
QSE+4L4ZdDrBPt94I1sW70T2vJa/iYAY2lIlEA6J1ztyc+dO2+83RFIv6Eu3+iEUKUGYtD1dST2j
cifgMBFhw5nrUnH54fS9e7sEo01YUnncZ5y8gstO+Dle2Xf7XelOx8EFKPSnQSTI0ouEY25ywzlH
0Bok5d/0WtuB89biijN3AzAIGPjo3EWi7LZHDUAi84nU8TeBQZWQqTnj36oCo2wZyHwBOTYEwFhc
6Fvm+9FtUkkyQqjVBM2rF2ecW6RpyJ6Z3KQa9WinJyky3Fw8Re0q8kuTm25vViocp+foImJfTuLC
1MVblZuTV+Ymf8md/ODS5Fdu3bp968Kt6sX7t6buX9yacN5QCDlErDf1aPYumhENKMlw4vE5sCHc
FNxRL+3cAb7EhPwGt8TlRjKm74anX+5pO+4WVGdUT9fe7LhbxElXuZxcOeckVb+HGyRtdbldQ+un
gWwEQUTfGwYJJEAm9Aw6+hEjCS+Kyadzgm4Z9FhHGm67h7jf3jKhChyyAXoBl9Q1toNOW99LbdvH
mWXqETChnnovyhIGQgSyK0jMNQPCdcff2o6cFkcTZ4ngt+6q56T8tryCROCwx63np76pp5FBHvEO
pyOOkcxNiTUQlwN2VJJg6YACxA5xz+QMf/IRqcjr0QgQO5RZKs6/s7S8fmduFQLRsO4kYhCM4wg5
nniInHM1kopLC9WLbnCRpntAP1dWUXMBNUlW8iRQxqUSE0g3A4DnprrUqu/tEbcdOiG1P4PwCQh6
0PVkDHfxDpaz7YbbfG3AaAoftCIqtXCGnAhMk5FW7OG20w68sDsRUZU98zQXabDQ45gIEyHe/trg
9npBGPoCk2DtBG28d4WXxurfdvdc9XgViNTngeMosARke2enpsYSAYkwbLwPp7t4Z/36jeWleUhB
RSCaoIhJdQ5DZhK5IVbhWkJdX1x7axH5ZFkjlNX4m1VnjFQQMSqxByTDmBFRADHDzjFIIocRBkQO
FQaZlJyzVQsVyBuMjDWUSTyzte8w6jUackuQSRLQYnFI4/oBPo0y4kiRUR3OCoKMIhSlD7Y19Udt
kxqYIQYiGDQapRiiaWVsfFx9dcbHablJ3Rn3q2MzqhyiWMxY9fKqGYqnkNOcLcTnbuqOJfo0XuEB
NBCrceMxvpvBbrc9e2km/t13qLAAQK0ZRzKkEk8eWnTfJC027o85s1LKue3MSB7LGwE6NaPKb/oz
JQ1Ed/tWWcEZH+fSBOkSoDgqj+GYkiVNHEVQf0zBFtBpktIv7jr0j8m3CCP9opFTBPKdK1yUg4sQ
y9QXFpcX1xfvrK7cWVxbW10zdkY8jcpn60sr64tr1xcXlubWF/NKqLlnxFY89dQI2r/rMtKG+/i3
noNzIsEcgtvIm0aLy+uUft5BDE0UMHMTM5M382AkWMr+PO6Qy7+xeq9Qu3e9w9kcrh8/z2xmJjlh
PGNGh5Y9I0wctNVxRDBA9KpJMUK1Djw701cutr29i/ArpFDRlo/YVmL+sKHzvi1eOGXZiU3nnLbI
ir5O5vTs+LhQQgmktK1g7KjAGU7UMWJAVmXci2DLYTz9TefThCRYP4Hk9JVfmGJEeQriSTXCm2+x
Y8DsojPqGTdS3lW8ef3mzp49oGgjsFicf1MpsllH45biiRjPKTENFpbWmoj7axqzWoBmp/+sy8sI
IKUMDnULNdDrIzOLl5s3rAlLFS6e42qN5BS2C2DKQpJjbCevofDkmpWfpoSTi7oUXH1nvQrK6HWf
5eqJ15blT1MIPfH/uBEx7gaxVn3bc9tP2wd0hP9n+rXXX0v5f1575fIrp/6f5/EZ0f9zchcQXl6y
mavQCcTrjpW5t45yBpGhr2O4tSRmls/7cP2+F/YCuSqKiG0SdITb3iVdmvX4wIeBsCdxGb2opeWj
227r1aMvT9TWMZ03Dvfdw2CTROw+reU8tuIxwyef5qds/sS0o3XynMbTCs0Wv2yBpQXvFOr1XT0G
83QxoyV371BWMVhtrtDY931aiDpzHQxGtE2m3lv9YLfnLPs7PlaMU1/5ylQNf6f572X++0r9KeNW
VneAWDfoTdOZss/3XNOp5R231Q8QEjUm63vO7KzzXsPRodjwE1toMwiFGhfr+p0Z6ycuP9NgeHaa
29/wIwwCbuni9YREZo8WjQf+jpusg8V+xzuwk8JtF16V67u8Wk0UdrtBF0S3E7uBh0eUfbebKErN
95MFcRDKx8KYg+R67aYX5WJ/o++1fGzu5DYdXkXI2XYSg1/y+sGCv+fTyjG0c5hf3iE6EVg7veNt
5iXT9OP4Yu+6HQlpZmfuIsTK13EBLhcvgFvBblCizzu7ncjvdahAIVwZx7mtrT7inXk5I9E5zBmL
FbJtm/d23X4i9WtuK9jwl/jl6+gwNdA7uxGjUSH7HxtZiBFtbIV8GZNnNTwFsyHe/4GMe3J4eZ8j
9P/l116djvX/a9D/l1999TT+63P5GAObxDSLSLNvY5jCmIPZfYzm2tVqtVYt07+NWe2K5iUex/Cq
qqBcBHPG6e23q2Vaew8r6JOklIKr818bVjDY+LYq2Hy/GReMveCqeLW8sHr1neuLK+vifFRANvzu
RT2NyquN2UAb7ITg7PiH1J0HQoQyGfeUQGjrBDLxKYHQe3CRCr7f1Onl5SVaerwvTs5EPhrr+GGv
PL+6ul5Ygh3Ph/yKZBn+ACqXXxCHHQ7DMnsxihtUpcplklvYOrnwJnttDsbHeXdljVBxZp0D53a8
ZJSF+IoOdqtd5nXHWQjgAw090hyBRE2R9aR6JoBNrboTRZvduvi1sOwsmQ9WtAJ8PlOLzAbYfWR7
Bi1fuBArurEZu57yUOI3u2vXFmkF9j6vJhdmp8RJsrRSNRwrPbhjHNgK2KZPK9Mbb6+uvN/AdlS5
hSCajXTdsrSRBZpq9Q5XL5dxZkDt8IQnB2ZDibHkJpxE3o256zfepsW12WNMQ5afhsA7d1WKvOtp
fvKWP69IaVZ3k9PaRo7ndxkblmgLe50IOtzZbXs5gBIZFgqpHI1KDJd3QosB84q7ufrO2tVFteg2
ZKC5Cm+C6cPy0jxP8jvrc2tvLa43gX6KHTBKmWLaZ6f3K9d5I4b3PmQ3L+bgyLDvmJYbdwwvXV1e
nFvJQB1b48fvYKnTomfHa4PXFatT7TQPWd0FCMvfbeckXKHiBIXT5G2aUMQHRmwrlwkfS5To0D72
YmHPyO4HrXJ4xw5vNRGKeh+kXH5nZekbd/IYTu0LJLNI2CZGReSXvcVzzuBUG6/kALchLLy75ORB
aO/5hZXL+RkN5xz2kI0a02NC3KK1A+LJYcdpqbnIX9/E7ghvjoxX2n5f7awSxa0qjq6AHFuyJJhN
yYn0DPcOejRMjSwRyzEkKVNWPPZs9H9K1RN1n34bw+2/qddenXrFsv+myP575fLly6f23/P4/MsX
PvfvfP+3fn4G31/8g59z1r33HAnc5UxfuvRq/dIv1qenG9OXL039FSrxuVFA/oQ+v/bC4Zkz3/21
P/oPz5z5tRe+iq9//OfOvPDd7595+Ft3f/ylhX/4T6MzX37rP+H/f7610596/b8Yb9549Md/6137
5NCjz78eEWd+71fueV/seA9/OPaHP/kuPt8/85t/8Ld+/K++9x9/46fPfJEaxP8ZyvTfv/G938BJ
x/6jF//J3xHP0veaD73+4UN8fvgXNr9NlX/rf/kXc7tbNO4fUaHp6doAHX34w/Ezn6PM/+nlr//4
Z6Mv/uXGmRJBLQnkjYOv/LdzynH08Idf+o3/4buP2r/3//343wj+s7/yO6bcS4TBV/6b9W3voxf/
/DrjPyDp+oP/6itAvv7opZ/vrfYH28HH+4MoQM7Hnv4b9L1BfEJpsPdx0OHyU/WHP/wZot2j62fO
/PgLX/9nv3x4BlKgrLt76TG8YR+99Pk1tsbCAZlxA9ZLQr+B3/3ej36fqLHptryBcgs9+sn5v1t/
9FP/9n+5FA3UyQBUdCOpLTFwH/7NL6LdK2fObLvhRy++847b4YcIBhvfe+vf9LzuAA1GD3+dUVtW
yrChfvMbsI9emqlPVT964Q/G3vKiAWTfINgcRITPYe8HBCMEFTY+RsflnMdgujrQS5FB3e0NiGrh
gDTfwHNbVG2b6297aITwsiB99OJfmrxcHayjZ0GPiBdswQ0wgJIaBN1B7CVEm22wx47f9QZYLAwk
cujglergmt9ta0RVI3XpvIqeK1Qie0DTra06zGP+8L9nv47b+gFwjTCyXbQHqv74z/3eP3njwAze
T7V2omjq0icySI+ZC7i3fijM0HYjd9Du+3sMY9vtDgI4dhRW4Kof/T7X+OjFv/zP/W487gOJwlx/
9Pkv/XXCauC3PRdQGXPqqtf9OAoH4uWUviqFNCBFo8C3vS92qT//67IcRQlrj178ydcoG61IUzEC
g17fw3F6Qp0gG8NmIFUHbLwxnTXwoPvRS7f+az5Bwe2H9Udf+Pd+Bmw8cP/qj35/bxD47RBFWrsR
cBr0XOoQhp4a/Z5qNFTPftYevfTXf7hBBVGbwEVRx7BH3wfT3D3E+NEoABt4SmlE6mrUmp6HzE+0
MTp4DGYj9nD9TogWtwPq5T73WD0bPJDW1bOjg/2P3XAAq0uDXAki76MXfu1fCKOEeBaDVpiYg4PK
J43Zx9UBcTcNpIwpqDMAtdmTSyVQgLoieG7zGyB42Ul1CVz2wvJ/hyiPLb9HyLT9n5YXPMwIJ5oM
mVW9vUc/ufc77O0iqP6OGqHO4YBfnWIkrIEXp/JHL7Z+hiuzAUL1NogShwOcoiHB9IM/nuuEwaAb
YKBFcBAC8GqBvXgwulS1Rf0gcivgNAAsRwbhDjV7qERTIIy971NRiJYAwbWIqXDARtF0TvfpB+jT
Ry/8+v9BtZprH1+tDWgJXBvQwvfRC7/+n4NXaPFbG/ibwGygBRZzM7B+9f8SLiOz9+P9UGE1oVh5
QrHJ/sdB/+5AYlh2gCSP/ifi6FBC9bF5pYRF6cMffplEJUP78b/y8ljtB/Y0Dw+nLv1o+8c/90dn
JhqJ6e9PXfrtjUc/eTBBc8MckHt05n98+Uf+w0ffCf7xl4Hg22fOfHL2o89/9Y+Mi2YAF81giIvm
4a9LPThqUFMv6gbGV6MA2x4bFGy1BzlOmwFcLKqG7brJrwHvjV3D9uHk14Abx65hO3NQQ/tzTD1d
UBvhKNSYHeQ6djQWjdlAfWVD+uGvP/zhv0VD9v0zf3DmzOOphw9/BZbNCyPaS+ezls0f/Z9KRz8W
r/OvEi95XUgzdXVsEH0ss1CNc/3hf/QlzTM/2v5tvmMGXpB7Zo/O/PP/GVxw/7f/7pdZDytOSHmm
VJfS/ind6XwvlWYP5avS1Mt1VylIymlVWFT5rfS4sOfqUfkv/mFj9hFVKXJMxTwlTqxC8Lr43xYK
fxNzjuT2zAtKiQVdmqds/sDAUWYPGwqD1Bigkj0MA3GEkRiiHj56sfH/+loq4J3qRy/t/CO2rl5c
+ne9brhrrCQtMiBJJgZYSiupwZjsQ0f6LAQ1lCUWSKRFv/77wIpxVQ2hNiRP6O/0qLLsAJFUDXdb
pJPDzd1ORwmZv224heujLUjuR2d+6yZLjJ//e1/WY/sJPH5o4N5P/gBeP5D25sB2/A1mBweD2zOD
W6oUFDtKYVU8GFsJBkJG4wDEcLILkPpEKh8uQIhG7QIcGEfPQLkADWT4Ab//uYc/+XkkfP/Mr/7k
d9EG2jKuwIHlCmSNH7sCB8oV+OjgN/9+AgBzlvIJ6nR4MgA46VgbTG4Okv6xQdo3+Ohbf/EfaHw3
fU1FtQZHS0TPh4r9oINf+gt/T1lGg4lPeG3/eGJQ6Xs7ARswZJRRiS0jsWGmVbljE5/YLgBUYgsM
4BXfcQ4YQlXqA9t9AusODsNHlN6DjpRzpiREvmwJEVYmrD7Z6NKqZO/l/9SoEnFRCe1siqi+awJm
KZYiqTg0NKESrqunANyGlxoM1iFoe5AoZMaGZusL/9hhjR8mzDa9/PjE6MnBY5B45tGLPz1Ns5UW
ObwcweJmAD8ZmcXKoiKLjSTEfmx6wwjFELUIDUwHP8rMTt/IcPd3f8OQP+nnMYorQYyM43SQdJgO
0p7Rh7Yum1a67MXRVFnppWG67HpAC+QXfvH3ZdU1mLjbDUAIWqlteRMDl601Mr0zQgCij4TDJ0kj
RbB9XI8XliJcf/ZXYFJzFV6qsrWJocDKbqD8we0BduHFFIPD+NGLP/vgcUKUk6wdTHIBWlJuY8T2
fJJgQVeNmwKEcaO2xJYkK64D+xBzig/if8yrRTZmbeDaEH0rQJe3OgTl8CqWChNkBu72Q3+P1YGs
5fF4hs976sRU/R2S4BO8huVlHd4rwiVFWPuagHq9wtQgTRDB0u7wiue6WhdqBD6JCfnRi/tzj3eo
m7thpLm8o1bnA9wJoPYrPrwO/+jf10SsChXdgZBw/xepiYlP4NB/PFFTaJCY+uiFv7H/xS6Ds8u/
8De+hgnEfvrH9QHb0gm9SDVkHYpVcK9vLQO1WiVxxhNHrhEQbvd+h9ZgA6tbsgQDFKg+HlVqFKt8
JfSIjh/jSWFNkeScevTSzf/gMRwiN/9318x5kRLiTaAlj7gSsJKJZ/xWwrzWa38tKrQ8ZoRJAdBS
hbV+uq5e0XyiTgTSBHisEWUPwR9eV0MRKlfGIPqrWGAGyMLkFhwBm0z2rS1PSCEXSohlqJKraSKT
X/OOG3300pv/VKwgnIICZrRE3YOs6hz+KlkQtFT+8B/yBLLV7WPlE/qYs9UaXzchRkB4yN1yD1Rj
4nWgUZTzVmBiPnKlXR3xvM8slCxSfGFCOOnRi1/41x7vYGK1zWxnQW3zBFOEpfrgk/S2zeOa5blw
P3rpTMsmEA8xU4VQ26k/+qn+PxMvUWxqGZNssA9qDZQpphnEbZNBosADJLpuuMjyummLoPJJyrx4
XLVXiBkN8V2oiMcX6F//r/2DH335oVYWvJ2VWsCld+W0dsT8VOoEs1mBUNRMauQcpXFZKY2XRlMa
X/rdYUpDhPpf+rEyzrWpDDGhpET348NB7PCChWPNIJkVsZImi9zoi663D1j9j158a5HdJ8oTxZAG
lWC79qsvfu3PCw+zPlFT7ZPsavlx7WMuQxVPODpp2loau4j8WoXnjBpPhRGGTdW0tgAB4AKsiOR2
aOwFIC56JFyUsy+qmkzvjkrbmfLKkntTW/Bqo3SgNkp5LMe/lS4lG6bGOhhLrsTlxx3bMk3un2bA
qX3Ugb2PqtYJBlyOSWpvm2qYpGsA0oe5ktpYHbSDAa+GsLHKLj4NnP0xssNqMSojIJbjJJZ/LLJ4
hxUsCjcYeyDVDutA77BqoDmblsY+ZC92dqtV0TEx7rLs/og7rPdMB6PsuqaBLby79OhLv/kvc2EN
2X/V3SnYhQWwc43BOctZlRrcxIbsIN6QHfCGrCpeabUZLbMxO8DG7MCqOtAVkZOzhkgxvFrQ5C89
1D6tcFGqR1Qms1iU8qY2s7ktbl9R4vbzo4nbf/3zBeJWC6zzjz734H/DUmPZ7Yi76Lvc8nahe5HI
qErkO57i/DxXg5Wbu+JM1TaiNEGEV4kI//eZMz8X2XuP6Ofn/hp9/cKZz+d7THM35vJ24XL3BnO3
HfN3ZvIdublbcP/PmTM/f/jC7/FntCH9dH1EM5IOnmT5PClqKtx+mndAjjj/OTX1avr+x+vTr5/e
/3gun89A/I813jNzyAreo2WuIyc9BaGcKB6Zqxnlsy+zJzncLp915vqIGbBPpqjEaSuX+SW58Sm8
Rk8Ku1oudUJnfBqbE/oZ2fP8hKxz3zngYHJbfa/nTHyrKkGCJijd3b/rTHwoz6+NX34wgXc1403n
UUFOLhLUWwrszVuRc/uCAnJY0Ajm6o7bO1EDKZCblbFzYYP+u9Udq41fro2/UuUmECJDDkt9k2j2
1a+O0c8DP3Kmy17otsp8KN0cXE+fWP8UXXM7/RR8RP7rxcmziP505PmvV197bTod/+mVqddO5f/z
+HwG5P/zif+EVjbc0G/x9SIT9UVtgvH1Ote+XseRPR1IWYTAmcR3+jfYLGv0pDTPrBln39PxXqdR
Tk7jNnRfvS7u0FEtIgRHjrt5M3QPLt2+rW70qQNIfFLeuvMIj4pz0z2QKHN1N7ytgsqETtCt26AI
CAFbZT3qDgEpVLHQYbIQwghkGDrhbmtbWlVUVZclpWttx980wWYQRYVdabjKxcXLfRPkihSQexeH
rAmsjs4Db5wioRCtjhuaClsOc+OHZlS0zygbSAfg3e6h0/O9FkdrUfdAu+2yvtbQ9iRODmLBUC/2
+34U4ca8hGe5eVOekFdmMfafiXTGlYl+eV755k2O3Ier5ZSLRtXBIR2hi7C/edOEf6EyFvZ8ejpi
BGzca3HsIH60ej+Qm25ldyPYw/VTBJf0uw5YAyUId+bBDhwwePI76G4RvdkzouFGmqRyBpzHTgXD
KdtBlqJgi+8OOhVqbDdyvnLpnA4HxoNRRbybrhPgviB3AWOLCDes68NamRicY+Tw3OvuctQdHmYV
ncjDrRFU3N3A7UPQZ12FxPGp51SdY/OA7BOho+LZ3vUOERIDQDf9fhjpOQS0vDDE1ToyCAGvjJFW
TC0RjDAJ+w6iMXZoXb8t596jbUcCJhFr9DisQNAN6065fA1vER64YMMascBCsEsr5mudwI1k6Ozm
cVvl1mYQRDgB9SHOfBH6E33EB+oclpn8XhjJrVyJDC7tkJBgKdKKiDxMVusiLxpB/EtHDDcWl0Qj
JSD2vP4GASGpa2HWIE6M9F1VmblxufI3PU0CoSUPA1MgDHbERCNRdpeEULYRVSXR1jUfoaIYwIdO
vV53HmSahKwYM+MyxgPDU1A664cycPzWXxw2ztk4tKxlfZXZsHOCk3nigp0QYsoPFasRYRGaCS+u
EVsTyf02Dcm239o2Yk54nlkNzCGZLbfrbIED+agd9w28T6lKopbLq3gBSTi4hwOGoBouoFN7NbBU
tNsn6KhlTUgomo6n56UXlVXoWFSeft3gVLl5c2ll/fZtMFzzrbXVd27I97nltxbn1+aI8YCqUifV
GvqYgOR4HYlVDkjXlhaXF6T+wtK7a0srb92+XZWrVZrhgWHInd4AIDXz/a6hcOeQ77hjsOIwiMl7
ZpXV+a9VL45X6LcctmJ256tmC3NzzUWOEaPuJK2rIB8wB+zLI/t+p91y+21VKLVmqcZ11t+/oetY
waUSdc5xnRqihyWbwm0Q7IbcWVi81rSQIqxpwQdPH2R3+eryN+6sr95YXnx3cRlF3AMaZQS8s7Rq
OX3n6oIGZXRAYYlEY0WFqKW+eweaBjFzCouJe1IMDr48VVTQDS/qfgwvY3URd2ck8ooKo2yuIcUk
1bFOVMwjRYGU4wjxBrcLc5kbBQxHeapTEaqBoEKUAdf+pL852dp2u1teuyb5Nb5eo9omSTEKdidF
zxJET4KlWpk/KywV+CdCkYoxM93Ra784wJziAHNPKm9Cqou5VigoHX77Pts3HETpSdAi0Ams1MBn
kbo6t16Ek6pzQozi24j5BCssoFC3pJ8VEjY/6CHCFLk9W4oxrTleNOJwmlvaWWs3CnoqeibsQrnP
gECdHKRo8cad5aXmOk98ysbNYoF8B4VT2CC01FgSo7EaduRiGYkL1YuqM0UgMn3KATBPugIBsQqB
nMuvR/9fbq4Xt8xlltaq1DQRqgD5d1auri+trmgoejGhHv/tBwi7P6kD70oQVA6ASvm5hMWgW5Rl
A05umycH0yJdThl1/S9JnSNg6Z7oYomuKNaBgclXiNGHD/mnskBqYCb6y5FNudgD079kdCtk3nF7
WqWuXm86saY3JRRYU+hOc520T36hehi5iPEFGWeXjmN32ZH1gGciQa3MEmkKSUm7Ja+PZLVwWnU7
ccxBAbNzF4BYYSvXZxWrF1rMOJtuGI1xzMHCojg57VR45VMdWnSiQnZ1G5GHE+iMVSeG1zJDjBzh
UgGibB1qdSwmarOKgL7FQCetAKAOW3CzVJu/IESlepebf8+I7SXGYFXi1JVKb2ShxqREnDidHmyV
S3FIwyR+Q+RxqmQigYMf2nEzRfRbBSS0MpaZwNbSDJp/xsd9TGultOgfWnHfiztgF0O8Qg5JEEfL
S2UXAdexDAr7mFerZrO+Sov7g3CXpSiAP8aEamYhEIfezouv11OB9SxxYoXZTgruRr6tTRicjePw
JqdSDMCel9KqhNk7q9T3VhzVT0IbkqSuUi4HJjSlLJZ1DySkZM9kFk9LYbu8GkWzs6jGSJM0Uzlu
UJ73xVprkq+QT4yfd0Zq2KrJ8aNCQoXqjp+vHlHfgmAkhXvAcsLCw4KLNy2OwOjkMuKNIVBVCPTC
fCMs3sxVSfyylh2HODGLZErMQ7GJReRUlthXdZe4LA8cnGrGXmsuKsWuE5dWri6TMjZmx9x7lzBx
rn+9GVuuyL0YL88amKqZ6MwZa9murBVXRic6VqdhtYjytBPRrkpVADLLypI9jBAjHOZ5stVzfrm3
3/5lCfjMpoAtecwiEYKsAHlLrSutoEVDEoVqOZ9YdiDrFBULlr6pqCqpbIcvRcnaSKXO8ti1iaVm
tbxc3PP6h+IH81jo5LKZOM/zOEMnG96AnznNHQXdAh10oJFEQ8muW60SQHkgIb/wE3FbuhkVsyeX
vZJ56WEcjclaQbfrteAhVVRLBYXPrOPSzVRrWYOYQ8HTsMYh10kVWmHRzxa6QkyNbJSZRLYVBytD
6Ua6sG3FElWQ1HImNW3SpavJffTYAffM99BloyM5T59z/NepS5n3f1579bXXT/d/n8fnM7D/u2B7
PPBOWA+nZ9vYPNw4dMQoI5MhE97V2fT2k+4SbPft+PwuCC5qOqHn9lusASbjOK8OesP7NXxpgLcK
D8uoylHSchongwXbWQaAiiKr3p7YChx33z00z2pQcoi3SuC62RZ8gIFBlNrqup3DkPdQ3w72PdJT
NaePNz/2XX6MYmO3L0HYXKftHtZJYmzv7EB0zK/ecJrrcP6Xm4vv6a+2aOGCpwdzTj/6I/I/ZUA9
ZQVwlPyfzsb/fv2V0/Ofz+XzGZD/qfOfOzrQoWziIsyHfRLHZEPeYiXsheqMSZfWMVH24M9Sdy+4
y9vQskVqIMh2eXZ3XBYfemGBrXBeV+DZnvSOOL/xCMkrUfnwEBSC1KT7wJFwbCxl11w1wWZt5tGt
CZU7wR2dAAoTNdk69yKjbJDsd9XrWGgQl/b4bqDHu72pLQyyvQVqNbFYgdfKjvtHustzW9v8ymVt
vKLXDnHtqpW6tL543cqir+pJzSrHJi3rEJ84fcseH+BcTZ4sZSqeqq1n8FHvP4QXn2EbLPdffbVI
/rO4NPL/MqVPTb966bUzzqvPECfz+TMu/834x680PPUzwEfo/2nS9mn9P3X51VP9/zw+n6L3P37h
9PUPfsfC/Dl9/eMYuJ2+/nH6+sfp6x/H/sT6Pz4N+Hz9v5dfu0y2Yfr9r9dP4z8/l8/z0P8xZ8XK
n1R9zTnmNSBL94t+xyUEPgKtDtjjGFwQ8b9htLu5mfvKu8LmmertuMcNZxFfQ3EoB+bwNyukU61N
4JzYcS5UC/mGgiIMH7ZkZ7kcZ+jwPRFR5whPMvneMt5g3uq7O7hTciIjwFEfXJI9gNo/cN50zhFY
j69BrHm9GVOm5+HVVCrTpzKUY0qdI4CleT8qUd58ECCixEy51Iz6SKB/SIzj9xL/5AsCS10yNLw+
pXJi/HNlhRNWgu4KVBFpijjvBmfdCEI/mT5POo2bRrgVvwsN5yF5rt+3kumXewg0Ft9iPLytHTZP
Su+sLKk00p97JOncjsl8UNYXQhJ4Ow11G6Rc8iWlQcwT8RhNXhF6tAKv38Ib77qOzrjQcCrnas65
qkopTaYTzqcSyqVZghMnEamp1HdmG+m0culKNrH0Rk7alRyAb2TTyqUPyKz5aoNYwhRTh16Yo4R2
guNUg5G/xP88AJ/g+huRCKwyO3vFaS4xvd0QPFI5qHLigeGimHNsTr7uYpfKqyk+qlm8oopRCyWA
vtHZJZFTwdcat8XdUI1yiet+96gi6/6OV1hElVn8RkNPiXQ59EGDWlkcqRjeQR6l2NHQiMPXA6RK
yQr9rjp8XC3dg6lGqVTJ9P1SKjWmWiOn9HX3oJEuPg8KCgr8PUPdYJ7zmipvXuXNSwep+Xnu2nyi
a6VSufRAuEHNZTSmJl6lY6YeHjsB20FOGVpUOobBQA/UrLgN8PgFp7KBL3GtimajCsShW2OpuFGl
SrrOZH4dZqzCSufzKzGrZSqZWrOOqUbzjqeTTBxhwcLWvjM7pN7KYmG9N4a1t7xeXG9Ye8vF7V3J
tNcNoor7xuyGXSgDXAptMKVogVmhnNI5YvGSGnhm7wpAQHJRdib3EueKvHIytS6lUrm0EoOVbhIV
GiNpJJb3KKIklB7vD0nRl0rdLrYRurG0Y9ZHDh7XFopRGaJmPFEqap5VqlW5z2aT1i7idytVHolu
t+rwXj1DLoHV4jlJ8DEAyOFTX1zE6/fJwBjTSioKAmfD35Jrp2qjPaH6xjBfCeVKl0bQ8D/j2Gho
KASRumJPDzu7Km+ulU/aOiOf07sEbZnVHpDoiFX4MZT3ZEOd8z2ndfIFSKeU2k6nnE+llFhz22la
0eak5RW8kpeWU9BYGxCzGhuTlDRA4nTuW6xOk+nn1ASj6aWkPPrD86ARp2j7AJUsbBKmQLl0bzdI
mzh9bydj5OQbFg/KWUtifkRLIteUSFoOAMWmpherrHlbn4lZ4WQ0k6W6tF0xpIi2K3KLqDK2XZGn
BzW2iyMVs+2KYcWOgqbKfYPGMKuerR6u0YgWFNC2yXyBbaLAKECxcWKDv5RKHWpRnNBemM+3FyZF
GVmlY6aBequ41SPsCs1Hx7ErDGMdx64wrHYCu2L+hHbFfL5dcbRhMX9Cw2L+mRsWtDLHi58kSzc5
bIas5JbEnNWS0oGuby5VnbRdJ3wUq6OmVke6np+xEfxkLtDSUjs/95yas5JrTKEkiybsoGRWnhEU
V7mUV1obQQcJsh0kjKAKifoqk7jm5PEmSRE1Y3jgKjRwPCikDoZVI9mSUy3W7Fl3gaXkk3qtuTST
py0zajGhQBMKMa397ISU6itcK3/KrYmRFHaeYl5KL8655+xFSmjdufeW70yqwkuhNXwN21oRFJUo
vxb0PX+rS8I77MXj5YhN7mAm8iwmK7PRsAY5PUulwLk8CAwA4qSbmqtmYgF1u2PGtwWLuLBPji8m
uZisjm+ZsMr+XUGIDpdEUHeyayopi5cIEEskE6MhI5dWVpaMGAAPq9nLCdZiKJtjS4Cp1Ny/xDIi
sfbR814SmVpHKD+ZuJSjZu5QBaYKn88WTqlIXXJSl8SgloBuoZ5TNWbHNYupqkN1lar0Rly4WM+o
sleyZbO6TMOdzcItKntl1kZ4iKRV5amETcYhMlZVoBJ2hZ2gfZwKsThOuWifkSxOFiL+t4vRz6JV
TCyk/zRL5xKN3jMT2HqAk4vLT4u4VqaVBnEMoa37NbLE7pkKCWmdRhXcaDpjcyojTAkGWV/3t2Rs
uqMk9qns/bMje10ut2ELW5pgUaWpTlMYSavX9GcT8jHe7cM+l/dyw/h6SjjeDGFTadacppY2CfeM
ulMd9FWtt/Rvp0n1N/pu665HIKzkXM9OMyV4Jzi+3EQ6FXHkMokdNydxD/t9E4ktJ91P2eUUWefc
mEmny/ppzWsF/XaF0SDZgxUGvqwh5gBbXi+/7MjTC3JzquWGLRdn5ESo6LBiOA5FwiE+k8YH81qR
BA6sJwUstaL6XVNdrRm5ZLDU+8OdALvVsnvubJG0QehKZ7cbuVtbuI7VxQn3YNOuJ32SEJcrfqdu
8m5kOER/un7nqw3j8jQutJxivagPgzibR92VvDU18ukCPFQN3cZaXCBn7PQn34Nn66bSjQgGt99p
OPTNdnAhh9PpI+qfEpCRdg+lGxUGMZwT9cdN08PwS2yX24R1Kj0lVYSuLEU12qzEetWs+7KI9nrx
r0WI9LICyZE/JBWqtCZeA96+tzbuc4dIY6tmSLzTbw9ZzKgJElgM3PY23d1O5EClJ7f9bV7Fqsfb
6UWHhB6OzCjmtYRVS/sc1oANYygHFixADOGr8O7ZZGatC/qjeCdG/qwumNzWh7VA2M5emnFMbBUe
Hg+xQxuz3QtTM06Xum6NiB4OpZBljGaSeJEaP6dxibPwYBpkPAmDTsrBKMPm3FT+rc7tGYkgU3KM
+0V6WFKuK9X/BElYwJiOalNIFew4ZP0pY+aq2wUIed3Z+WURTDhJJMPC4YN45wVD0anWuQBMPWuM
4pbO5bXE01H1DCBQIQEh9KJrAPsyg6k5oMuoaI+MM4c5TLW6Rpi87KhWoyFdyGmVJXdeo+hpxeoq
GsZARlU2EGGwiwZW4+lk2zxAmwczJqFyKEAIGDY8VB6hgaSXKwc1zWqwH0r8wrXNGIeajVlifmBg
HbKcNGAOawSdkw5QRHK55Q9YbtL/D2bEyD0rRLPsW4C+K7+oApwHJUyjg8Q0uou8u2SSwtlQuquA
GeMiBmobErNxfC9uRbrXSfTpkKO0yjiL9O+YXnYU8mjq5lYC9m2L9LauhwoXzctaf5/P2fIJrDiS
K2n1kpRRgoDaU6PAOxTbSGAseOILOVyQYyuBOvOHhbNIhhoHqOFUNYgRxn07LmyGjSw1KYkB2maa
xhbiuxy+udhGpGVQkyPIWjF15cK3lTCTLR6foZbS9pnqJzAX47z13R6NssRb06Zk19uHmdpc0mYq
apxNeBTcXq9zqBbOWEoiHRauF71sUnXtSrVgh3Gun7MoVjUtGVtMOwysmtyk6w8VU6tVBY965ewB
dlXOHlbHsRq+4nAEKB5YnjY8bw5YEx0itrWZwxxn5oArUwZVJO282+9a9aM+H4FjfieuVmcTOlMK
i9XdqLcb0RJ9B8h0pox+jzNsRV8qHHLupF6+ycop1UnmeFe28jn++Qa+b9g9oWzqCWXEPaGkNyhl
RsiEH2c3QCXdpyPmsT1sWB/x+MvUUtPzTVk28Zzhkxl6D0Mw9rJzNJ6Ynp5sUtPvttgFwXNvDyls
B3j7kponqvbqXHOIrBLQbc8GrbpNOkpNDLvLXL7jdbdoavOmaSEm3r0KexJIvFTzsFKhlSFTutXh
uBBo8deQ1hB9bfA5cfMHw5s0YqWyJ7o6pSYMLSpn96pvCsf4+K29JyWjSGKE/Awyokz26j5j4+tx
9i09clZjwK4sSj/LKn4PUopFEM/+muOzQ0tMGUwXtlyr9Qp658dWP6QKyyhVTdF1T+haqebUJpwJ
r7144fAubn7Egv+6S0vKg8oaGc5k5saCPyEhle1bi/1mIm3XtMh08svVaEWhy93zOtEI4O4RPCpJ
UvgIgHmnR/MlMsR9uJY9AoJliFLNMhY7ibEAMO3d2anW/ZiE0opacnut6dDHeMTbtZkFQ+Vgcsoa
RaOA4hZpFL8tu0hrsou9VkGjFQFPPGC+fpuMt5LignR1ZoU1DeRDHJ+qcMEkrFoMq5ZiDbEM1TzC
kJ0UxXgkny2WhGeT7yW+7e556ky2me4kvDHm5VJGM8HpIYlzG17Hd7tNb8eXE/40NiZTxfNP7u7P
YF2rnlowTWnFbplQ6Zty4NQjLB4z4WJ/fHy6XDrnmBbsQ2qkfIdSQZ+my+CLdm3jZqTDUKMdv8ke
sJmcVLNGua2tKaIOFphhNm4AU0efURil0qgUQYe08FA+vk6wz8vtbX9rm7+QTO9/AMa3XEqxscce
0PSFBWzFrq4s8pMOgcOX42hVgO/8pqS8Jzm548kDCIxbSLVQBZgYNfRLi2urnBKfnqCpwhbUxiFv
HcS7Ah+yoApJUAFfXk/MOCEsM6LfvnYJNB0t0khBUDpaQU/j/Dgb6dxnAnigCyxZBbglQYqX4k69
zgZe03JTwD2xUQM1bnPJhIfTUrU0KAe5yjqxpit1gCKsGKKoWAHbKgXYqiTCSyUq1KuNRlNyNk0S
3PVMX72LY6ywNwhYQtFrVS9Wl7LDOrQ8JViS9IAXYB3EibZaeKOggSvHbuCBNilixZ2+iPIEcuHD
IsHADT4n2XB8yfBs5QJsEpINLedI4aBkg64wnVchW06EzjtwzFd2uxvtNrYTWtM0W9TXIfImKWnU
4y2e6e5EK+BLfuoRE/hygw2y2LWMGUHIFM9nmtAbNUxn+Butgo2SkyhkikDCuOHbfsorGcsRh9+Y
pG5z0xlhxTMkVVKWgSyE6JcWZKpUncmpEx8IkdT7Ph0c3Qzauy2P37Fhd91OuIVp2/Va9SHSECBF
IiqRmJCIIyCJOlksdeqD2BUA0R4mRHsB8A/T4CE2whkycR/ktqOz9aL/CWWxjRE3wjiVjQDLGw0m
HS+9MtgZIV06gex9YKuCzIilMLLxSaGTQUbJ82euMFL6wnmKCiMRKcpc7z0NFzXKx7r/L6fqnsET
oEe8/3n5cub951dff/3S6f3/5/F5Lvf/hbOew+V/udOQE+1no+Nu1+X6PxXih82e7kV288d0t+Fc
2+22OPKeHbEHxoxEGzy9/T/i7X8yaPbwpJ8aXrjQdxANEW4MDtkIOJuK2PpYMCxDBINiQJNasbed
unsgj2GeRgt4VtEC4gUTnyxkI5SWRyXpF3tCFw9wTjL/mCSXZzeAVICZiPKgYwyQDL2yOnBYsu8z
OfFFxlneIgTP6h6pcxNgq7qDmJryHmuE12zbbuRKfqjCcprrl+pBR7xFWi/bNNMrUVlCptpyQT7d
1qVJPK0gzy0eEDgDh4lsrWhlby++wXjktp44vNM7e+xFzNvcS59nZSxXUo1aWU3/g+RZZStvzdvM
xcWu7kVFWBWdkiUKlFInYBOY8nbI2ZI5NCCnaJMY8xkQoVbJ3kvgnbl3mTfSPcHpATnGD1KWMjsQ
gnu8C5HoI1emYokj4Irf47ENOYHokbxqO2x4VMn1oKnqJqsW0VBaclITI6ZlCqyT2DJpHu5sBJ3j
4T2kQcmqdKrjqg+Nc8cJKpLucc4p+MyF3PQVJTjM4ju9pbaX+Nnx7uWcOw97fqRLFe2Q236XwoGz
+4dTeOkOSXn0YbObLGz1QApRvzJlMoWos+ki55IlqP9HlOh4mVZS5JFyIJKEurAoVcSUBeL6XCnL
lQme6JhRL8Uu4ZIOZ9DVHABCcIaBl0NTxo/ImC2cpS2XJWqWzBn2c3HxNJVZKhFhcwunCc6Fie20
lLFORpg6qSGAhDmsKr6MhV+lGreiBwPCb5Qb/ycRQ0P4ePiojyCLrPEe8VrjETLCSV37H9bDJ7mI
d/RNEutk81CCmAvaVX1JIHXxo+huxzO9ejfKraZnMRTHvmJznIE4yTgcexie0mWaeAASb7Jr2m/y
zxOZFTa8ESc0tzbCdLZAJ6f0E2MvQ7geKLTthcUwQZR3/+mIziRaUpZMsjNyDMmE8rRmhBxEStjO
6lhRw7aZ19OXQ9bzbQ214RJ+oCxSXqnIKY5qls95w0lOQlWihKEMR3BUrYcfxPhwCW0hU0fM/SYq
J+3oszbxltN6+v5N7v5c5hijOcLod0AZjADfOdFUmsGx4Pi3zLluyMcdk4FScIYtYf3I+VBdU6RE
ZMFSNwfJuucm1Qmcpn02kg+SNkqFNwbTjEi92OzmmGAtt2/3SCW2cwytvM6prH6v47ZcvXqqJoFx
ZjtzI1OhtdvppAhRMCcKDtLZF0vYlrY6KNZz3A0xnzPmoWoQbF9++oeK7fPEfvrUX+aQnV8tOsUY
H/Pzq+ZEo6/P3emTbiW0o26gr3nqZIyr7grIxSOZAkGPXzXVXihvc9Nv+XjTqS4sXxKz0IgX5h82
M5kl45sNzbgM8RJv+/cTVx/OWQXaUgA9kgJNZVHakoz7a2xIPQdi+9NcNLB4zy7flysClr1qQxd2
NOXVZCRsqkUdltlq3eUgqzYuBgbmTqUufKhCycsemS0gdvE+q4jJf7o+Zv9nx+/6O25r+7nHf740
TT8y8Z+np073f57H5zns/1icVfz4w63jvv4AXaGzcFURh3XY2VqTRxE2Dp2OizaUsz+9I0SCArGi
ITKOtQ2QX7g8fxh5bKa9h28zuNT38svOimz2IO6zH7o7G/7WLuFULl+4cMH5ZXXCaELvb4S6G7T0
3/M6avODNzmMWqmXVa3YxMIeCkqWS9hI0IHMkASPPiGTSnp7SQcgM0nNbNJ8NunqtttPVyS7OJW0
kE3St0+tJDJa00lk36aTbkSZUt8kGzgJ3j4nrSiADOOT1zRIJioqJBObeYnzOYmGGKlURY8kgIWc
REOUZFFFlmSiIkwyUZEmBVRRJ5kKZrf1o7D96fGI088ZS/+H0e6zef3paP0//Xr6/YdXX5uePtX/
z+PzKdH/tT857f/MDoKoGUXyuEnfVOyKiy19/Ng+FKIfA/4zfhzkZE84gboLEhhEv+GU2JTHDZq4
iDltYaUtdc2FTys170SFlZ05VWHlpY5s2DnK8Wglrfa87nU32l7w9vwWGTR23uI9eajIeirIyuX7
m7k56jjGvM8vouWXSZ/dyC+lLk5bTxU1dzdC66Jv5Wp8E6jmLAjx4QO0rwddLYh+tsCODZ6VjdKC
dSfo1GA5/Zx+Tj+nn9PP6ef0c/o5/Zx+Tj+nn9PP6ef0c/o5/Zx+Tj+nn9PP6ef0c/o5/Zx+jv/5
/wHq/reGAAgCAG==


\start
Date: Mon, 22 Aug 2005 23:01:40 -0500
From: Tim Daly
To: Peter Broadbery
Subject: aldor patches

Pete,

I read "Recursive Make Considered Harmful" and he makes some good points.

In Axiom's case I'm not sure that a single, mother-of-all-files, Makefile
is a workable solution. 

First, he claims that a single Makefile is more efficient. But the Makefile
lookup/DAG build is swamped by the size of the Axiom build in the "clean"
case and a "make" of Axiom with a single file changed is very fast.

Second, he claims that the DAG edges get missed when recursive makes
are used. That is probably true in C using include files. He proposes
some solutions (VPATH, GCC -MM) that are not useful for lisp. Axiom
does have some "include"-like issues because lisp macros have to be
in the compile environment at the correct time. You'll notice that Axiom
builds "depsys". This is an image that includes the macros that are used.
Depsys is used to compile the Axiom lisp code where needed. Thus the
"include"-like issue is handled. Changing a depsys file will likely
trigger a complete system rebuild because it is very hard to compute
the macro vs file dependency tree. I certainly don't want that tree
expressed (and hand maintained) in the Makefile stanzas.

Similarly in the algebra subdirectory I originally started using the
Makefile stanzas to decide what needs to be recompiled. Given 1100
domains and their various dependencies this is impractical. In fact,
I would claim that hand-maintaining any dependency graph with 1100
nodes cannot work. And it clearly cannot scale. If Axiom grows by a
factor of 100 over the next 30 years that would mean 110000 stanzas
with who-knows-how-many dependencies.

Third, he misses a key point. While recursive makes are inefficient
they are conceptually manageable. Axiom is a huge system and some of
the Makefiles used to exceed 40000 lines (which brought Bill Page to
open rebellion and rightly so. I used a scheme which had a file-per-stanza
and his scheme uses generic rule patterns). I understand the details of
building Axiom and have expressed the process as clearly and correctly
as possible (modulo some complexity still to be handled like fixed-point
compiles). The directory structure and their associated Makefiles
reflect that understanding.

If I were to combine the Makefiles into one Mother-Makefile it would
probably total 100000 lines which would be a HUGE rule-based program
(maybe the largest I've ever seen and I authored a rule-based programming
language at IBM).

Recursion allows me to dole out the tasks in slightly more manageable
conceptual chunks. Each subdirectory only cares about itself and its
children so the frame of reference is localized.

I'll trade program inefficiency for clarity any day. As for "cross
directory dependency" I used "trigger files" to indicate that a
rebuild is needed. For instance, src/interp/Makefile has the 
'database.date' marker which is touched if the databases get
rebuilt and interpsys needs to be regenerated.

Miller assumes that you can code all of your dependency information
in the Makefile stanzas. In any really complex project this is not
possible (try hand-coding the axiom algebra lattice).

Miller rails against the practice of writing procedural control
related shell scripts in Makefiles which undermine the whole concept
of a rule-based programming language. On this point I agree wholeheartedly.

I've also tried hard to avoid all uses of special tools such as
#if, common includes, dynamic includes (well, 'findSpadFiles' in
src/algebra/Makefile.pamphlet is an exception), and other computed
approaches. Given the one-stanza-per-file method it turns out that
make has very little to do except stat files and build the well-specified
DAG.

In any case, I'm happy to see you didn't include a patch which rewrote
all of the Makefiles into one big Makefile. I'm old and my heart would
not stand such a shock.

\start
Date: Mon, 22 Aug 2005 23:06:10 -0500
From: Tim Daly
To: Peter Broadbery
Subject: aldor patches

Pete,

I'm looking at your patches and reading them in detail.

You mention a shell variable 'ALDORROOT' but don't tell me what
value it is expected to have (a) at compile time and (b) at runtime.

I'm assuming that the aldor compiler will be in 
  mnt/linux/bin
and the libraries would be in 
  mnt/linux/lib


Also in the Makefile.pamphlet you set:

INTERPSYS := ${OBJ}/${SYS}/bin/depsys

Is this what you intended? Why?

I did learn the difference between '=' and ':=' in Makefiles from
your comments so I'll look at back-fitting this into the system
where appropriate.

more questions to follow...

\start
Date: Tue, 23 Aug 2005 09:13:26 +0100
From: Peter Broadbery
To: Tim Daly
Subject: Re: aldor patches


No problem - I've a project which is suitable for non-recursive
makefiles, and nicked the structure from there.  As you say, axiom in
its entirety is not really the kind of thing that can be tackled this
way.  The reference to 'considered harmful' was just to a similar style,
not signalling any intent to change existing code, and I've no argument
with your assesment below.

In the case of the aldor library the non-recursive part is less
important than the ability to list a bunch of files and have make sort
out what targets you mean;  this way I don't need to autogenerate
stanzas, and the build will include new types as they are added to
src/algebra.  Both of these should reduce the amount of maintenance
required by libaxiom, which was an important goal.

Peter

On Mon, 2005-08-22 at 23:01 -0500, Tim Daly wrote:
> Pete,
> 
> I read "Recursive Make Considered Harmful" and he makes some good points.
> 
> In Axiom's case I'm not sure that a single, mother-of-all-files, Makefile
> is a workable solution. 
> 
> First, he claims that a single Makefile is more efficient. But the Makefile
> lookup/DAG build is swamped by the size of the Axiom build in the "clean"
> case and a "make" of Axiom with a single file changed is very fast.
> 
> Second, he claims that the DAG edges get missed when recursive makes
> are used. That is probably true in C using include files. He proposes
> some solutions (VPATH, GCC -MM) that are not useful for lisp. Axiom
> does have some "include"-like issues because lisp macros have to be
> in the compile environment at the correct time. You'll notice that Axiom
> builds "depsys". This is an image that includes the macros that are used.
> Depsys is used to compile the Axiom lisp code where needed. Thus the
> "include"-like issue is handled. Changing a depsys file will likely
> trigger a complete system rebuild because it is very hard to compute
> the macro vs file dependency tree. I certainly don't want that tree
> expressed (and hand maintained) in the Makefile stanzas.
> 
> Similarly in the algebra subdirectory I originally started using the
> Makefile stanzas to decide what needs to be recompiled. Given 1100
> domains and their various dependencies this is impractical. In fact,
> I would claim that hand-maintaining any dependency graph with 1100
> nodes cannot work. And it clearly cannot scale. If Axiom grows by a
> factor of 100 over the next 30 years that would mean 110000 stanzas
> with who-knows-how-many dependencies.
> 
> Third, he misses a key point. While recursive makes are inefficient
> they are conceptually manageable. Axiom is a huge system and some of
> the Makefiles used to exceed 40000 lines (which brought Bill Page to
> open rebellion and rightly so. I used a scheme which had a file-per-stanza
> and his scheme uses generic rule patterns). I understand the details of
> building Axiom and have expressed the process as clearly and correctly
> as possible (modulo some complexity still to be handled like fixed-point
> compiles). The directory structure and their associated Makefiles
> reflect that understanding.
> 
> If I were to combine the Makefiles into one Mother-Makefile it would
> probably total 100000 lines which would be a HUGE rule-based program
> (maybe the largest I've ever seen and I authored a rule-based programming
> language at IBM).
> 
> Recursion allows me to dole out the tasks in slightly more manageable
> conceptual chunks. Each subdirectory only cares about itself and its
> children so the frame of reference is localized.
> 
> I'll trade program inefficiency for clarity any day. As for "cross
> directory dependency" I used "trigger files" to indicate that a
> rebuild is needed. For instance, src/interp/Makefile has the 
> 'database.date' marker which is touched if the databases get
> rebuilt and interpsys needs to be regenerated.
> 
> Miller assumes that you can code all of your dependency information
> in the Makefile stanzas. In any really complex project this is not
> possible (try hand-coding the axiom algebra lattice).
> 
> Miller rails against the practice of writing procedural control
> related shell scripts in Makefiles which undermine the whole concept
> of a rule-based programming language. On this point I agree wholeheartedly.
> 
> I've also tried hard to avoid all uses of special tools such as
> #if, common includes, dynamic includes (well, 'findSpadFiles' in
> src/algebra/Makefile.pamphlet is an exception), and other computed
> approaches. Given the one-stanza-per-file method it turns out that
> make has very little to do except stat files and build the well-specified
> DAG.
> 
> In any case, I'm happy to see you didn't include a patch which rewrote
> all of the Makefiles into one big Makefile. I'm old and my heart would
> not stand such a shock.

\start
Date: Tue, 23 Aug 2005 09:38:19 +0100
From: Peter Broadbery
To: Tim Daly
Subject: Re: aldor patches

On Mon, 2005-08-22 at 23:06 -0500, Tim Daly wrote:
> Pete,
> 
> I'm looking at your patches and reading them in detail.
> 
> You mention a shell variable 'ALDORROOT' but don't tell me what
> value it is expected to have (a) at compile time and (b) at runtime.
> 

ALDORROOT is the location of your aldor distribution; it should always
be set to the place where aldor is installed on your machine - in the
NAG days we could install aldor within the axiom tree - I'm guessing
that this isn't viable with different licenses for the two systems. 

Fortunately the two things are fairly loosely coupled; I don't see any
reason for the aldor lisp generator to change dramatically, and axiom's
requirements are pretty stable. Moving versions should be less painful
than changing lisps for example.

> I'm assuming that the aldor compiler will be in 
>   mnt/linux/bin
> and the libraries would be in 
>   mnt/linux/lib
> 
> 
> Also in the Makefile.pamphlet you set:
> 
> INTERPSYS := ${OBJ}/${SYS}/bin/depsys
> 
> Is this what you intended? Why?

Not sure; I've probably just taken liberties with the conventional
names;  It should be depsys of course.  I probably initially used
interpsys, and then ran into a problem and changed the definition and
not the name.

> 
> I did learn the difference between '=' and ':=' in Makefiles from
> your comments so I'll look at back-fitting this into the system
> where appropriate.
> 
> more questions to follow...
> 
> t

OK - will try to reply quickly, but I'm out and about fairly frequently.

NB: As expected, I missed a bunch of files and certain ones need to have
'document' run on them explicitly - I'll try to prepare a makefile which
explicitly does the document thing first; attrib.as.head.pamphlet
contains a minor error in the \author line; & should be a comma or
something.

\start
Date: Tue, 23 Aug 2005 04:36:40 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Ralf Hemmecke
Subject: Re: Unit package question

> I would rather suggest to write a package
> 
> Mass(R: Ring): Ring == add { ... }
> 
> where Ring should actually be something that allows Float to be
> entered  for R. Maybe even
> 
> Mass(T: with {
>    +: (%, %) -> %;
>    *: (%, %) -> %;
>    ...
> })(R: T): T == add { ... }
> 
> would be a good idea.
> (Well, that is Aldor syntax, but I hope in can be understood.)

Well, about as well as I understand Axiom's syntax... :-/.  I might as
well ask this up front, and I'm sorry in advance if I missed something
obvious and/or am proving myself as intelligent as your average rock:

Is there a tutorial or some such that takes a Category->Domains set of
code and dissects it essentially character by character, answering all
the dumb questions?  Here are some of the ones floating around in my
head which I don't know quite how to answer at the moment.  I'm quite
aware these are an indicator I haven't read and understood something I
need to, so if someone can point me to the correct "Axiom for Dummies"
file I'll be only too glad to fade away until I understand it properly.

Taking this example:

Units(R: Field): Exports == Implementation where
  U == Fraction Polynomial Integer


1)  The syntax (R: Field) - what does this actually denote?  R I guess
is all Rings?  I don't know how to parse this statement - is : a
separator, an indicator that R is being restricted to Field (whatever
that is) or what?  Why is it there at all - I'm assuming it has
something to do with letting Axiom know about the existence of the idea
of <something>*Units?

2)  Exports == Implementation - what is actually being exported here,
and where is it being exported to?

3)  U == Fraction Polynomial Integer  I'm assuming this is part of the
Export - I'm also guessing the $U at the end of the units.spade file
somehow ties off the domain definition?

4)  What is the significance of "%" within a domain definition?

5)  Is there a file in the mnt/linux/doc directories somewhere that
gives a detailed description of the syntax of Axiom's spad code? 
Clearly I need to write a new parser in my head.

What does it mean to define "Exports" from a Category or Domain?  Are
Exports visible to the user on the command line or do they manifest
themselves in the parent Category?

If "Domains" are to be part of a "Category", what responsibilities do
the Domains have to a) label themselves as being part of a category b)
export anything back to the Category?  Can a Category demand certain
abilities or actions be defined for a Domain in order for it to be a
legal part of the Category?

> In the "add" part the units could be implemented as variables
> (together with some rules to convert from kg to ton or so) of a
> polynomial domain. The output would be entirely left to the Mass
> domain. And the advantage of that approach would be that one could
> have also variables in the domain parameter R. Nothing prevents it 
> from being something like a  polynomial domain. One only has to 
> take care that variables and units are separated accordingly.

The gotchas there (which I suppose might be sidesteped somehow and I'm
not seeing it):

There are a LOT of conversions to implement.  This is a significant
part of the grunt work of creating a units package, once the core logic
is in place.  At an absolute minimum, I would suggest having a "pivot"
unit defined for each dimensional domain and define all units in terms
of the pivot unit.  Then the autoconverters can do two conversions and
the definitions file is only 2*n instead of n^2 in size.  I got fancy
in Maxima and handled metric prefixes automatically, but Martin didn't
think that would be a good idea here.

Each "unit" domain (or more properly, dimension domain that defines a
non-basic dimension) needs to know enough about the other domains to
spot significant unit combinations, if we add derived units like Force
into the picture. (We need to for any non-trivial use of a serious
Units package.)  So if we define a Mass domain, a Length domain, and a
Time domain can we somehow define a derived domain which recognizes and
handles the combination Mass*Length/Time^2 as Force?

> Then I could imagine to write
> 
> kg:=kilogramm$Mass(Float);
> ton:=ton$Mass(Float);

This we would want to create as the "units database" for the default
package.  Ideally, loading or activating the units package should have
all those definitions prepared and ready.

> mass:=7.3 * ton + 4.3 *kg
> 
> which would print in kg, say, as the standard format.
> 
> 7304.3 * kg
>                            Type: Mass(Float)
> 
> If you like to see this in tons then say, for example,
> convert(mass, ton).
> 
> Well... that is just a thought.

It's a good thought, and is similar in some respects to what I tried in
Maxima.  

> If you like more units than just mass, I think, it would be
> reasonable to write a Unit domain similar to the Mass domain 
> given above incorporating also seconds, hours or whatever.

--- Martin Rubey wrote:

> Dear Ralf, CY,
> 
> in fact, I like this idea even better than mine. In private
> communication, we developed the domain below, but your idea is
> conceptually better, I think. The full blown thing would then be 
> a category Units, that has as domains Mass, Time, Length, ... I
> suppose.

>From what little I do understand, I like this idea the best of any so
far.  I would call the category Dimensions, since that's what Mass,
Time and Length denote - they are not units until a specific quantity
like 1 kg, 1 sec and 1 meter is defined.  I would define in each domain
a "pivot unit" - this will be the unit that all other units defined in
the domain will need to be defined in terms of.  (Not necessarily by
the user - I'm sure Axiom could process inches defined as a Length in
terms of centimeters into an internal definition of inches in terms of
meters (probably the most logical pivot unit for Length, although any
could be made to work.)  This maps well into defining units easily and
correctly, since each unit defined can be identified as being part of a
unique domain. Then the rules for using it become instantly clear,
being handled at the dimension level, which with the possible exception
of temperature need not and should not concern itself with the details
of converting between units - at that level the rules for dimensional
analysis can be put in place.  After that it's mostly knowing what's
related to what by what ratio, after all.  Then variables can be
defined as being part of the Mass domain, and only accept as
assignments units which are also part of the Mass domain.  Perhaps, if
this logic makes sense at the Category level, an awareness of the
relationships of domains could be encoded.  Simplification of base
dimension combinations into derived combinations is a tricky thing to
create a workable interface for - you have to allow the user to say
things like "I want to simplify base units to Energy when possible, but
not to Force" and then allow them to change their minds later.  Then if
they want you to simplify to BOTH Energy and Force (not a readily
physical situation but it should be handled since predicting all
meaningful unit combinations is an exercise in futility) you must first
check for Energy, and then Force, else you simplify to Force first and
then don't recognize that Force+remaining base dimensions allows for a
further simplification to Energy.  Ideally Axiom would know this, but
it gets tricky because you don't want to ONLY know about simplifying a
dimensional quantity containing Force to Energy - what if the user has
disabled simplifications to Force?  You need to be able to recognize
Energy out of "lower level" dimensions as well...  The answer to this
in Maxima was to define an "order of searching" for derived dimensions,
and then reduce all expressions internally to base units for the
search.  I don't know the best way to approach this in Axiom.

\start
Date: Tue, 23 Aug 2005 15:01:03 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Unit package question

Dear C Y,

I think most of the answers you find in the Aldor User Guide.
http://www.aldor.org/AldorUserGuide/
http://www.aldor.org/docs/HTML/index.html

But let me perhaps say a few things in my own words.

>> Mass(R: Ring): Ring == add { ... }

That is nothing else than the definition of a function Mass.
See http://www.aldor.org/docs/HTML/chap6.html
Remember (almost) everything in Aldor is a first class object. So Aldor
allows you to take domains as a parameter and to return a domain. Ring
is a category (in the library Algebra distributed with Aldor) and it is
the type of R. So whenever you want to call Mass(SOMETHING) this
SOMETHING must be of category Ring. That means it has to export all the
functions that show up in the definition of Ring.
(Look for the definition here:
http://www-sop.inria.fr/safir/WHOSWHO/Manuel.Bronstein/algebra/index.html)

>> Mass(T: with { +: (%, %) -> %; *: (%, %) -> %; ... })(R: T): T ==
>> add { ... }

That one is in fact a bit more complicated. It is a function that
returns a function that returns a domain. I think, it would have also
worked if I had written

Mass((T: with {
    +: (%, %) -> %;
    *: (%, %) -> %;
    ...
}, R: T): T == add { ... }

(A function with two parameters that returns a domain...)

That goes in Aldor under the name of "dependent type".
http://www.aldor.org/docs/HTML/chap7.html#4

> Units(R: Field): Exports == Implementation where U == Fraction
> Polynomial Integer
> 
> 
> 1)  The syntax (R: Field) - what does this actually denote?  R I
> guess is all Rings?  I don't know how to parse this statement - is :
> a separator, an indicator that R is being restricted to Field
> (whatever that is) or what?  Why is it there at all - I'm assuming it
> has something to do with letting Axiom know about the existence of
> the idea of <something>*Units?

Well that code is from Martin, I guess. But yes, it is intended to say
that this <something> is an element of type R and such an R must at
least have all the field properties (ie the signatures of Field).

That parametrization makes the code more flexible. You could leave out
this (R: Field) stuff and restrict to use Float all over, but then you
would have to implement another domain if you come to the problem that
instead of floats you would also like to allow variables.

> 2)  Exports == Implementation - what is actually being exported here,
>  and where is it being exported to?

Exports and Implementation come later in the code. You have not given
them here.

> 3)  U == Fraction Polynomial Integer  I'm assuming this is part of
> the Export - I'm also guessing the $U at the end of the units.spade
> file somehow ties off the domain definition?

coerce((x::Rep).units)$U means "call a function (here coerce) from the
domain U". That is simply to help the compiler. Sometimes it happens
that there is a function f: A->B from domain D1 and f: A->B from D2 in
scope. You would not like the compiler to choose for you. (Aldor would
reject compilation in such a case. You would have to make your
intentions clear by saying f$D1 or f$D2.)
Look for $ on the page http://www.aldor.org/docs/HTML/chap7.html

> 4)  What is the significance of "%" within a domain definition?

Simply translate it to THISTYPE. If you say

Foo(T: with {random: () -> %}): with {random: () -> %} == add {
   Rep == T;
   random(): % == per random();
}

then you could use Foo(Integer) and Foo(MachineInteger) and the % would
in the first occurence be like T (ie Integer or MachineInteger) and in
the second occurence like Foo(T) (ie like Foo(Integer) or
Foo(MachineInteger)). Think of it as a placeholder.

The line
random(): % == per random();
basically says:
in order to define random for Foo(T) use the function random from T.

> 5)  Is there a file in the mnt/linux/doc directories somewhere that 
> gives a detailed description of the syntax of Axiom's spad code?

Well, unfortunately, spad syntax is not exactly the same as Aldor
syntax. It is reasonably close, but there are things that the Aldor
compiler does not allow. (Which is good.)

Take for example the line
x * y  == [(x::Rep).expr  * (y::Rep).expr,
            (x::Rep).units * (y::Rep).units]

As spad code that would be OK (I have not checked it), as Aldor code it
is unacceptable. You have to give the types for x, y and the return
type, ie you would have to write

(x: %) * (y: %): % == ...

You might say, the compiler should be smart enough to fill in missing
information if it is extractable from the environment. Well, sometimes,
for example, for polynomials you migth want to have a function

(x: R) * (y: %): % ==

where R would be the type of coefficients. Now you have two * functions
and reading the code would be quite confusing if both these functions
start via "x*y==...". I think it is good practice too be a bit more
explicit. (Sometimes it's humans that read the code.)

> What does it mean to define "Exports" from a Category or Domain?

I am not quite sure that I understand the question. In the definition of
> Units(R: Field): Exports == Implementation where

the Exports are the functions/constants you see when Units(...) comes
into scope. I think that is called "expose" in Axiom terms. In Aldor you
would say "import from Units(...);" and then you can use the functions
from Units, ie, its exports without using the $Units(..) syntax.

> Are Exports visible to the user on the command line or do they 
> manifest themselves in the parent Category?

What is the parent Category here?

> Each "unit" domain (or more properly, dimension domain that defines a
>  non-basic dimension) needs to know enough about the other domains to
>  spot significant unit combinations, if we add derived units like
> Force into the picture. (We need to for any non-trivial use of a
> serious Units package.)  So if we define a Mass domain, a Length
> domain, and a Time domain can we somehow define a derived domain
> which recognizes and handles the combination Mass*Length/Time^2 as
> Force?

I would opt for a general Unit domain instead of a domain for Mass, 
Length, etc. I somehow fear that Mass*Length (id Domain times Domain) is 
hard to work with. Implementation should be no problem, but I fear to 
convert from such a form into Force could lead to problems. Anyway, such 
a Metadomain would know about combinations of the basic domains and you 
have a Unit domain again which knows about all units.

\start
Date: Tue, 23 Aug 2005 15:26:56 +0200
From: Martin Rubey
To: Cliff Yapp, Bertfried Fauser
Subject: Re: Unit package question

Dear all,

(I'm sending this also to Bertfried, since he was interested at some point)

C Y writes:

 > > (Well, that is Aldor syntax, but I hope in can be understood.)
 > 
 > Well, about as well as I understand Axiom's syntax... :-/.  I might as well
 > ask this up front, and I'm sorry in advance if I missed something obvious
 > and/or am proving myself as intelligent as your average rock:

Never ever say something like this. It is *good* to ask questions, and it is
also good to ask stupid questions. Moreover, it is impossible to tell
beforehand whether a question is stupid or not. In my opinion, there are no
stupid questions. (The reason for my saying that stupid questions are good
questions is that very likely 10 other people in the audience will secretely
hope that somebody else will be asking their "stupid" questions. But noone
dares.)

Elsewhere you wrote:

 > I'm quite aware these [questions] are an indicator I haven't read and
 > understood something I need to, so if someone can point me to the correct
 > "Axiom for Dummies" file I'll be only too glad to fade away until I
 > understand it properly.

PLEASE DON'T FADE AWAY. WE NEED YOU!

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

 > Is there a tutorial or some such that takes a Category->Domains set of code
 > and dissects it essentially character by character, answering all the dumb
 > questions?

There is the Aldor user guide: http://www.aldor.org/docs/HTML/index.html which
is very thorough but maybe a little steep, so I think the following approach is
better for a beginning: 

 > Here are some of the ones floating around in my head which I don't know
 > quite how to answer at the moment. 

 > Taking this example:
 > 
 > Units(R: Field): Exports == Implementation where
 >   U == Fraction Polynomial Integer
 > 
 > 1) The syntax (R: Field) - what does this actually denote?  R I guess is all
 > Rings?

No. R is a identifier, a variable in the computer language sense. So the syntax
is

Name0(Name1: Type1, Name2: Type2, ...): NameA == NameB where

and Type1, Type2, ... are Types like 

* Field, Ring, ... which are categories, in this case Name1 will be taken by
  axiom to denote a domain of category Type1. Example:

------------------------------------------------
Units(R: Field): Exports == Implementation where
------------------------------------------------

R will be some Field from now on. I.e., you can multiply, add and take inverses
of the elements in R. 


* Integer, Polynomial Integer, PrimeField 5, ... which are domains, in which
  case Name1 will be taken by axiom to denote an element of Type1. Example:

-----------------------------------------------------
SquareMatrix(ndim,R): Exports == Implementation where
  ndim : NonNegativeInteger
  R    : Ring
-----------------------------------------------------

ndim will be a NonNegativeInteger and R a Ring. A valid call would be

0$SquareMatrix(5, Polynomial Integer)

which will give a 0 matrix of dimension 5 with entries (all zero) which are
Polynomials with Integer coefficients. Note that you are allowed to put the
type declaration also after the keyword "where".

Another example

------------------------------------------------
PrimeField(p:PositiveInteger): Exp == Impl where
------------------------------------------------

Here p will be a PositiveInteger. A valid call would be

characteristic()$PrimeField(5)

an invalid call would be

characteristic()$PrimeField(x)

unless x *is* an integer at the time of evaluation. 

 > 2) Exports == Implementation - what is actually being exported here, and
 > where is it being exported to?

"Exports" and "Implementation" are just two identifiers. If you read the
sources, you will sometimes also find

     Cat == Capsule

or 

     Cat == Definition

It seems that writing 

     Category ==

is reserved for categories.

So the complete syntax is (incomplete, but useful)

Name0(Name1: Type1, Name2: Type2, ...): NameA == NameB where

  NameA == with

    op1Declaration

    op2Declaration

    op3Declaration

  NameB == add

    op1Definition

    op2Definition

    op3Definition

The keyword 

* "==" means: here comes a macro definition 

* ":" means: here comes a type declaration

* ":=" means: here comes an assignment. 

So we could also write

Name0(Name1: Type1, Name2: Type2, ...): with

    op1Declaration

    op2Declaration

    op3Declaration

  == add

    op1Definition

    op2Definition

    op3Definition

except the indentation is then less clear.

The keyword "with" means: here come declarations the user will see. Note that
the with part may be missing. See below.

The keyword "add" means: here come definitions, declarations and assignments
the user will not see.

 > 4)  What is the significance of "%" within a domain definition?

It means: I am an element of this domain.

 > 5)  ...
 > 
 > If "Domains" are to be part of a "Category", what responsibilities do the
 > Domains have to a) label themselves as being part of a category 

This comes just before the "with" part. (If it is present...). An example is

PrimeField(p:PositiveInteger): Exp == Impl where
  Exp ==> Join(FiniteFieldCategory,FiniteAlgebraicExtensionField($),_
    ConvertibleTo(Integer))
  Impl ==>  InnerPrimeField(p) add
    if not prime?(p)$IntegerPrimesPackage(Integer) then
      error "Argument to prime field must be a prime"

Thus: PrimeField will be an element of the categories

FiniteFieldCategory, FiniteAlgebraicExtensionField($), and
ConvertibleTo(Integer)

(all quite reasonable, isn't it? "$" is the same as "%", as far as I know)

It does not have any additional operations exported -- apart from the
operations it inherits from FiniteFieldCategory, FiniteAlgebraicExtensionField
and ConvertibleTo(Integer).

 > b) ... Can a Category demand certain abilities or actions be defined for a
 > Domain in order for it to be a legal part of the Category?

Yes. ALL operations defined by the category must be implemented. However, you
can define a default implementation in the category itself. For example:

SemiGroup(): Category == SetCategory with
    --operations
      "*": (%,%) -> %                  ++ x*y returns the product of x and y.
      "**": (%,PositiveInteger) -> %   ++ x**n returns the repeated product
                                       ++ of x n times, i.e. exponentiation.
      "^": (%,PositiveInteger) -> %    ++ x^n returns the repeated product
                                       ++ of x n times, i.e. exponentiation.
    add
      import RepeatedSquaring(%)
      x:% ** n:PositiveInteger == expt(x,n)
      _^(x:%, n:PositiveInteger):% == x ** n

Here you find a default declaration of taking the n-th power that is valid for
SemiGroups. It will be overridden (i.e., implemented differently) by some
domains, of course.

 > > The full blown thing would then be 
 > > a category Units, that has as domains Mass, Time, Length, ... I
 > > suppose.
 > 
 > From what little I do understand, I like this idea the best of any so far.
 > I would call the category Dimensions, since that's what Mass, Time and
 > Length denote - they are not units until a specific quantity like 1 kg, 1
 > sec and 1 meter is defined.

To define

a * b

where a is of domain Mass and b of domain Time you probably need the Product
domain. The signature will be (I forgot to say: "++", "+++" and "--" are three
different kinds of comments...

)abb category DIM Dimension
Dimension(F: Field): Category == with

  "+": (%, %) -> %
  ++ elements of units can always be added

  "*": (F, %) -> %
  ++ elements of units can always be multiplied with a scalar

)abb package PRODDIM ProductDimension
ProductDimension(A: Dimension, B: Dimension): Exports == Implementation where

  "*": (A, B) -> Product(A, B)

But I'm not yet sure how you can define

a / b

where a is of domain Mass and b of domain Time...

\start
Date: Tue, 23 Aug 2005 06:29:43 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Unit package question

> Dear C Y,
> 
> I think most of the answers you find in the Aldor User Guide.
> http://www.aldor.org/AldorUserGuide/
> http://www.aldor.org/docs/HTML/index.html

OK, I'll take a look.  Thanks.  (I should note that I don't use Aldor,
just basic Axiom - I tend to stick to open source stuff, so Aldor
specific syntax won't be terribly useful if it's too different from
Axiom's.  Is Aldor's syntax a subset of Axiom's?)
 
[snip interesting stuff I'll need to read carefully]

> > Are Exports visible to the user on the command line or do they 
> > manifest themselves in the parent Category?
> 
> What is the parent Category here?

I guess I was thinking something like a Category Dimension and the
various Domains (Mass, Length, etc.) as members of that Category. 
Sounds like that might not be the right way to work things though.

> I would opt for a general Unit domain instead of a domain for Mass, 
> Length, etc. I somehow fear that Mass*Length (id Domain times Domain)
> is hard to work with. Implementation should be no problem, but I
> fear to convert from such a form into Force could lead to problems.

OK.  What about this - have two domains, Dimensions and Units.  Have
Units depend on Dimensions and define its units in terms of Dimensions.
 Is this allowed?  This would separate things conceptually and would
probably make things like dimensional analysis much simpler.

> Anyway, such a Metadomain would know about combinations of the 
> basic domains and you have a Unit domain again which knows about 
> all units.

Heh - good point :-).

\start
Date: Tue, 23 Aug 2005 16:22:36 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Unit package question

Hello Clifford,

> (I should note that I don't use Aldor, just basic Axiom - I tend to
> stick to open source stuff, so Aldor specific syntax won't be
> terribly useful if it's too different from Axiom's.  Is Aldor's
> syntax a subset of Axiom's?)

I would rather say that Axiom is the subset. The advantage with Aldor is
that it is a real programming language. You know, it developed from
Axiom and Peter Broadbery even seemed to have opened the stage for
programming extensions of Axioms Algebra library in Aldor (not SPAD).

Aldor is much clearer than SPAD. You will agree on that when you later
have to understand what you once have written in SPAD.

I think you should try to ask Stephen Watt, whether the Aldor compiler
will ever become open source. He claims that there is still some
copyright issues to be solved. But I don't know which. Maybe it helps if
many people ask him for opensourcing it. I would be very much in favour
of it. Peter Broadbery once worked with NAG on Aldor and I think he
could do wonderful things with making the Aldor compiler better. Anyway
at least he could document the code properly that he added to the
compiler. So I rather ask you to help making Aldor free.

>>> Are Exports visible to the user on the command line or do they 
>>> manifest themselves in the parent Category?
>> 
>> What is the parent Category here?

> I guess I was thinking something like a Category Dimension and the 
> various Domains (Mass, Length, etc.) as members of that Category. 
> Sounds like that might not be the right way to work things though.

Right. The reason is: what do ALL dimension domains have in common? I
cannot think of a single function, except, maybe "convert".

> OK.  What about this - have two domains, Dimensions and Units.  Have 
> Units depend on Dimensions and define its units in terms of
> Dimensions.

He? Maybe I am missing the difference beteen dimensions and units. What
is what?

> Is this allowed?  This would separate things conceptually and would 
> probably make things like dimensional analysis much simpler.

Ah, I've heard of dimensional analysis once. That rather checks whether
the type of the result has the correct format. Oh, that somehow seems to
suggest the domain way. But first explain. And maybe let me sleep then a
night about it.

>> Anyway, such a Metadomain would know about combinations of the 
>> basic domains and you have a Unit domain again which knows about 
>> all units.

> Heh - good point :-).

Well, yes, but as far as I understand you want to distinguish the type
of the units (length, time, mass, etc.). So maybe the metadomain 
approach would be a good idea.

\start
Date: Tue, 23 Aug 2005 16:10:23 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Aldor / Axiom

C Y writes:

 > I should note that I don't use Aldor, just basic Axiom - I tend to stick to
 > open source stuff, so Aldor specific syntax won't be terribly useful if it's
 > too different from Axiom's.  Is Aldor's syntax a subset of Axiom's?

Aldor and Spad are quite similar. Ralf already pointed out one of the
differences. In Aldor you may choose between "pile" syntax, which is the syntax
used by Spad, i.e., blocks are defined by indentation and C like syntax, where
blocks are defined by pairs of braces. In Spad you have to use "pile" syntax.

You can already write your stuff in Aldor syntax and use it for Axiom. In this
case your file must have the extension .as and you have to have Aldor
installed. Furthermore, you probably need to follow the instructions from the
last comment (by myself) in

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

However, Peter Broadbery seems to have updated his patches and distributed them
this week on the list. I did not try them yet.

One big difference between Aldor and Spad is, that Spad only implements a
subset of Aldors grammar. In my opinion, the two most important points are

* dependent types in full generality, i.e., in Axiom the following signature is
  currently illegal:

  test(n: Integer) -> IntegerMod(n)

  In some cases, this is a show stopper, I'd say. Although William Sit has
  argued that it can be emulated in Axiom, but I'm not really convinced. If you
  look for Marcus Better on the mailing list axiom-math and axiom-developer,
  you will find that his question was in the end not answered. (And I still
  don't know how to do it...)

* the extend keyword is missing. This is explained in detail by the Aldor
  documentation.

Another big difference between Aldor and Axiom are the libraries. Very
unfortunately, the libraries are quite incompatible, as far as I know. So, if
you want to use your program in Axiom, you will need to use the Axiom library,
which is no problem, fortunately.

My sincere hope is that we will somehow be able to make the libraries
converge. This probably means to spend a lot of time thinking about a good
design. I'm quite sure that the Aldor library are better designed, but on the
other hand, a lot of things are missing. So I think we have to look which
domains from Aldor can be integrated in the Axiom type hierarchy. A big
project, which is probably feasible, are the polynomial categories and domains.

However, before this can be done, there is a problem with licensing. We would
need to convince Stephen Watt to free Aldor. I know from private Communication
that Manuel Bronstein was very much in favour of this step, but Stephen Watt
has not been very responsive yet...

If -- alas -- it is not possible to free Aldor, I think the best thing to do
would be to hire a lisp guru who implements the Aldor extension for us. I don't
think that this would be too difficult, and in fact, it would make sense in any
case, whether Aldor becomes free or not.

I suggest that we write a signed petition to Stephen Watt when we come to it.

\start
Date: Tue, 23 Aug 2005 16:44:22 +0200
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Unit package question

Hello Clifford,

Since I have more Aldor background, I would rather suggest to write the 
package as an Aldor library building on libaxiom.al. Maybe you could 
even write your code in such an abstract way that it would also compile 
against libaldor. That would be great. What I see at the moment is that 
you only need multiplication, division and addition or rather partial 
addition
   +: (%, %) -> Partial % (in Aldor terms)
   Union(%, failed) in terms of Axiom (I believe). So the resulting 
domain is not a field.

I would opt of _one_ Unit domain that internally stores the different 
units in terms of "pivot" units.

>> > Furthermore, you use
>> >    U == Fraction Polynomial Integer
>> > as an internal domain and yet do something with it
>> >    withUnits: (R, U)  -> %
>> > :-( OK, I know your code is just a draft. Sorry.
>> > But I would NEVER export the internal units domain.
>>
>>Of course not. It was only a draft.

> Frighteningly, I don't know why this is obvious.  Where do I find out
> why it's obvious?

You certainly know of "information hiding" why would you let a user of 
the Units domain want to know its internal representation? Would you as 
a _user_ of the Float domain like to know its internal structure. No. 
The only thing that is needed is the API, the properties that this 
domain has. That is why I said that U should not be seen outside of the 
Units domain.

>> > I would rather internally represent the domain as
>> >    Fraction DMP(SIbasics, R)
>> > where SIbasics is something like
>> >    [kg, s, m, A, K,...]
>> > and put into the exports all the various units, for example,
>> >   g: %  -- gramm
>> >   h: %  -- hour
>> >   N: %  -- Newton
>> > etc.
>>
>> > Internally everything is represented in base units. 
>>
>>I think this is unnecessary, I'd simply store the appropriate unit
>>and convert only if conversion is necessary, be it because two
>>elements of different unit are added, be it that the user asks for
>>it.
> 
> 
> I agree, but the conversion information itself must be stored, and THAT
> information should be encoded internally in terms of some one unit on a
> per-domain basis - it simplifies life tremendously.  I call that the
> pivot unit.

As you see below. The implementation of the constant g would be
g: % == 1/1000 * kg

>> > When it comes to printing (coercion to OutputForm) then the
>>internal units
>> > are transformed into the desired units. So one might transform
>>kg*m/s^2 into
>> > printing N instead.
>>
>>Ah, that's maybe a different story. I was talking about keeping
>>centimeters as centimeters... 
> 
> 
> I only want to keep centimeters as centimeters if the "global" length
> unit is set as centimeters, at least in my design.  One of the reasons
> to have units in a CAS is to do autoconversion to the units you want.

Hmmm, I still would store internally the units as kg, s, m, etc. If you 
really like auto conversion to the units you are interested in than you 
would have to make the Units domain to carry a state. Something like,

Units(...): ... == add {
   outputUnits: HashTable(String, String) == ["kg", "m", ... ];
   setOutputUnit(length, "cm"): String == ...
   ...
}

(I think String is a bad choice here, but I cannot think of something 
better at the moement.)

>> > Hmmm, I just see that my suggestion of Fraction DMP(SIbasics, R)
>> > is  stupid. One never wants as a result something like 4*m+5*A. I
>> > cannot imaging that this would be useful. 
>>
>>Yes, but it doesn't really matter. AlgebraicNumbers are stored as
>>Expression Integer... 
> 
> 
> Actually, it does matter - Axiom should prevent such an expression from
> being legal at all.  If it occurs anywhere, it's an error.

... or it should return a "failed" value see the +: (%, %) -> Partial % 
suggestion at the beginning.

> Where's the DMP code?  Is it well documented?

Maybe you browse with hyperdoc for DMP. But what I actually meant was, 
that something like a DirectProduct or an Array would do for the 
implementation of the pivot units. Each unit gets a slot and you store 
the corresponding exponent of the unit in that slot. In fact, a good 
implementation of Z^n as a monoid is what you want, maybe 
Vector(Integer) works.

>>Can it happen that the ratio of two units is irrational?

> Irrational as in an irrational number or irrational as in nonsensical
> or nonphysical?  I can't think of a case off hand where this would be
> nonphysical, but that doesn't mean there isn't one.  However, until
> proven otherwise, I think the assumption that multiplication and
> division of dimensional quantities is always legal is the correct one
> to proceed on.

Theoretically the ratio could be an irrational number, but any number 
written out in decimal form that I have ever seen in my life was 
rational. Maybe there is someone who knows of two units that are in 
irrational correspondence. What about a \pi meter?

\start
Date: Tue, 23 Aug 2005 10:50:15 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package question

Very interesting topic, which I have been following.

I like the idea for a "pivotal unit". What better one to use than the
international system of units (SI)? 

http://physics.nist.gov/cuu/Units/

Different schemes for implementation have been proposed, some even coded. I
don't like the idea of having one domain for each dimension (there are 7 base
units listed in SI) because we would then have to have new domains for derived
dimensions like "force".  Axiom has a way to handle number systems and I think
the unit systems can follow this number system model which has an
IntegerNumberSystem category with four domains: Integer, RomanNumeral,
MachineInteger, and SingleInteger. So we can have one category UnitSystem, with
domains like CGSSystem, MKSSystem, InternationalSystem, etc, where
InternationalSystem would be the default, and the other systems convert to and
from this. In the UnitSystem category, we specify dimensions, beginning with the
seven basic dimensions (length, mass, time, electric current, thermodynamic
temperature, amount of substance, and luminous intensity) and expanded to
include other derived dimensions. The UnitSystem category should allow a
parameter S:SetCategory. In principal, units are input/output "decorations"
attached to expressions from any set S. 

The complications of units come from the conversion factors, which are generally
floating point numbers (and dimensionless). This would be ok if we only deal
with numerical quantities. For symbolic quantities, it is the dimensions that
are more important and conversion factors (not to be confused with universal
physical constants) are seldom used, and universal physical constants are often
denoted by a symbol (such as "g" for acceleration due to gravity) without units.
Thus we should leave symbolic computed expressions alone (that is, in the set S,
even though it is actually in some domain of UnitSystem(S), see below). The
verification of dimension on the two sides of a symbolic equation is not a
simple matter since in the applied sciences, one often "balance" dimension with
a constant of proportionality, for which there is no a priori assignment of
dimension in general. However, we can enforce some degree of verification by our
implementation of dimensions (see below). Acutal units are needed once we pass
from symbolic to numerical computation. Thus we should design the UnitSystem
domains to facilitate such passage. We should have a discussion on what
functionalities are to be included in the UnitSystem category. Here are a few
that comes to mind:

unitMass
unitLength
unitTime
unitCurrent
unitTemp
unitAmount
unitLight

All of the above, and below, functions have signatures similar to:

unitMass:S -> %

and

unitMass(s:S) would declare that the expression s has dimension Mass and unit of
Mass for the domain %: UnitSystem(S). I think this is better than the syntax
s::Mass or s::Kg because it avoids the need for many domains (which would be
difficult to maintain).

A representation for any of the domains of unitMass(s:S) would be
 
   Rep:= Record(value:S, dim:Dimension)

where Dimension would be 

  Dimension:=Union("Mass", "Length", ...)

and we can provide queries for any expression in % as to its Dimension. (The
Dimension domain can also be expanded than just this mere text implementation,
if there are functions that are needed).

We can add as many as we like for the derived dimensions:

unitArea
unitVolume
unitForce
unitPressure

etc.

As an (conceptual) example of implementation (forgive me for Axiom syntax
errors, I did not bother to look them up), we can have:

if S has Ring then
  unitArea(s1:%, s2:%):% ==
    if and(s1.dim = "Length", s2.dim = "Length") then 
      [s1.value * s2.value , "Area"]$Rep
    error "Invalid Dimension"

We can have a "pure" declaration:

unitPressure(s:S):% == [s, "Pressure"]$Rep

or a "derived" declaration:

if S has Field then
  unitPressure(f:%, a:%):% ==
    if and(f.dim = "Force", a.dim = "Area") then
      [f/a, "Pressure"]$Rep

We would need to handle outputs of domains of category UnitSystem(S) to make
sure that the units are displayed at the rightmost location, but this is trivial
given the Rep for the domains in this category (see OutputForm for all the
functionality to handle outputs). Notice that all the dimension verifications
can be done by default in UnitSystem category implementations and the actual
domains only need to handle the units for the particular system.

We need a way to include universal constants, the notation of which depends on
the set S.

if S has Field then
  unitAcceleration(dv:%, t:%):% == [dv/t, "Acceleration"]$Rep
  if S has RetractableTo(Symbol) then
    accelerationDueGravity == ['g:Symbol::S, "Acceleration"]$Rep

If S does not have RetractableTo(Symbol), for example S is Float, then we can
use a specific constant such as 9.81 depending on the domain %:UnitSystem
instead of a symbol g.

So far, the above discussion concentrates on the symbolic side. It also
separates conceptually the notions of dimensions vs units. To handle the
numerical side as well as conversion between different unit systems, one can 
have a "lift" (functor) category that performs this (much like the coercions
between different types of polynomial domains when the coefficient domains are
mapped):

   UnitSystemLifting(US:UnitSystem(S), UT:UnitSystem(T))

would take elements of say, US=CGS(S) to UT=CGS(Float), or to UT=MKS(S). The
exports of this category would contain something like:

convertMass(us:US):UT
convertLength(us:US):UT

The unit conversion factors would be included in such packages and the domain S
should have RetractableTo(Float), or whatever (such as coerced to EXPR FLOAT) to
make sense.

Note that this proposed design allows mixed symbolic-numeric domains for S, such
as POLY FLOAT.

These are just some beginning thoughts, which certainly need serious critique
from all.

\start
Date: Tue, 23 Aug 2005 17:13:44 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Unit package question

Ralf Hemmecke writes:
 > Hello Clifford,
 > 
 > I think you should try to ask Stephen Watt, whether the Aldor compiler will
 > ever become open source. He claims that there is still some copyright issues
 > to be solved. But I don't know which. Maybe it helps if many people ask him
 > for opensourcing it.

I think that it is probably better if we speak with one voice instead of asking
Stephen Watt all seperately. I suggest that we draft a letter (maybe in paper)
and all sign it and then send it to Stephen.

Furthermore, I think that we should also ask him to "freeze" the Aldor
spezification. That is: Anything that calls itself Aldor should be an
implementation of the grammar described in the Aldor User Guide.

\start
Date: Tue, 23 Aug 2005 17:25:08 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Unit package question

Ralf Hemmecke writes:

 > >>Can it happen that the ratio of two units is irrational?
 > 
 > > Irrational as in an irrational number or irrational as in nonsensical
 > > or nonphysical?  

in the sense irrational number.
 
 > Theoretically the ratio could be an irrational number, but any number
 > written out in decimal form that I have ever seen in my life was rational.

Well, that's by definition of rational ...

 > Maybe there is someone who knows of two units that are in irrational
 > correspondence. What about a \pi meter?

No, that is not an example, since \pi meter is not a unit. Well, I looked at

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

So the following are problematic:

* Bohr radius for lenght

* circular mil and circular inch for area

* various conversion between angles

* most of the atomic units.

So very probably, one should somehow allow for an additional scalar factor of
type Expression Integer...

\start
Date: Tue, 23 Aug 2005 09:03:02 -0700 (PDT)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Unit package question

> Hello Clifford,
> 
> Aldor is much clearer than SPAD. You will agree on that when you
> later have to understand what you once have written in SPAD.

Hehe - hence's Tim's focus on literate programming becomes important,
although I note at least some of the dvi files produced by my latest
Axiom compile were less useful than I had hoped and had some rendering
issues.  However, it is so incomparibly better than the Maxima source
code situation I'm not dismayed :-).

> I think you should try to ask Stephen Watt, whether the Aldor
> compiler will ever become open source. He claims that there is 
> still some copyright issues to be solved. But I don't know which.
> Maybe it helps if many people ask him for opensourcing it. I would
> be very much in favour of it. Peter Broadbery once worked with NAG 
> on Aldor and I think he could do wonderful things with making the 
> Aldor compiler better. Anyway at least he could document the code 
> properly that he added to the compiler. So I rather ask you to help 
> making Aldor free.

With pleasure.  I like Martin's idea of a petition - getting some big
names on board would help.  I had assumed it was impossible - some
communication I remembered from long ago had indicated that there were
commercial ambitions for Aldor and that would preclude open sourcing it
- perhaps I misunderstood or the situation has changed.  That would be
very good news indeed. 

> > I guess I was thinking something like a Category Dimension and the 
> > various Domains (Mass, Length, etc.) as members of that Category. 
> > Sounds like that might not be the right way to work things though.
> 
> Right. The reason is: what do ALL dimension domains have in common? I
> cannot think of a single function, except, maybe "convert".

Well, yes and no - I agree functions might be limited, but there are
other things.  They all have in common the rule that you can only add
dimensions if the dimensions being added are the same.  They all have
the same requirement for display formatting - e.g.:

    kg*m                a
 23 ----,  23a N, 25 K, - Ohms, etc. 
      2                 b
     s

All metric units share the same prefix convention both for full names
and abbreviations (the programmer in me wants to use that, but I
concede it might be better in the Axiom world not to, though I have not
given up yet).  There are rules that work for all units which tell you
what the units would be for operations like integration even if you
don't DO the integration (see Barton Willis's dimensional analysis
package - I'm not sure how formalized those rules are there, but they
do seem useful.)  There could be global settings which might
potentially apply to multiple dimensions  (like, say, don't use derived
dimensions at all - report everything in base dimensions.)  That kind
of thing was why I thought a category might be useful (not fully
understanding the purpose of categories, granted) but if it would make
it hard to multiply dimensions like Mass*Time then it's a bad idea -
the very notion of derived dimensions rests on those operations.
 
> > OK.  What about this - have two domains, Dimensions and Units. 
> > Have Units depend on Dimensions and define its units in terms of
> > Dimensions.
> 
> He? Maybe I am missing the difference beteen dimensions and units.
> What is what?

A dimension is an abstract concept of a physical property, whereas a
unit is a description of some specific instance or manifestation of
that property.  For example, Length is a dimension, meter is a unit
describing the dimension Length.  Inch would also be a unit describing
the dimension Length, and because they both describe the same dimension
it is legal to consider things like 2*meters+3*inches.  By the same
token, Mass is a dimension, kg is a unit describing the dimension Mass,
and a slug is also a unit describing the dimension Mass.  So
3*kg+2*slugs has meaning, because the dimension of both terms being
added is the same.  However, 3*kg+2*meters is not legal, because
although both are units the dimensions each of those units are
describing a DIFFERENT dimension.

Also, let's consider the equation for parabolic motion:

 x = x0+v0*t+1/2*a*t^2

We know that x and x0 describe distance (e.g. Length), t describes
Time, v0 describes Velocity, which is a derived dimension defined as
Length divided by Time, and a is an Acceleration is a derived
dimension, defined in terms of another derived dimension (Velocity)
divided by Time, or more fundamentally as Length divided by Time
divided by Time.  

We know all this, but if we were to USE this equation we would input
quantities with units, such as 4*m, 5*hrs, 45*km/s, 9.8*m/s^2, etc. 
But we can use ANY units - equally legal would be 4*yottameters,
5*eons, 45*inches/minute, 10*miles/day^2, etc.  Indeed, it is not
uncommon to have some physical constant or experimental data in
inconvenient units - one of the primary purposes of a units package is
to do all the annoying work for you.  So what you want to do is define
your equation, and define the dimension (NOT the units) of the
variables used.  This prevents x0 being assigned 5*kg, but will allow
any unit which makes physical sense to be used successfully.  A
variable has no concept of what unit it is in most physics equations,
for example, and it isn't supposed to know that.  Perhaps constraining
a variable to a specific unit for display could be implimented, but the
check to make there is that it can be converted to the correct unit and
perform this operation automatically. A second option/setting could be
to accept only a form described in the correct unit, e.g. a*meters for
a variable x with set unit meters.  I can see the latter being useful
only to prevent accidental entry of incorrect data, but it might be
useful for that.  Conceptually I would prefer to allow variables to
only know their dimension by default, and require a specific override
on a per variable basis for other behavior, for two reasons:

1)  This allows a global setting to govern the reported units for all
variables, which I think is useful.  If we want to be able to override
this for specific variables I suppose that would be OK (and maybe even
valuable) but I would much prefer the default to be that all
dimensional quantities be reported in the global unit I specify for
that dimension.

2)  It works against the temptation to allow a user from inputing only
a number to a variable and getting a dimensional quantity back.  One of
the biggest problems in introductory labs (and sometimes well beyond
that!) is people who don't write units down.  Sometimes they don't even
KNOW the units, and are just trying to get by without doing the extra
research and figuring out what they are.  (Textbooks sometimes are
unhelpful in this regard, in my experience, so the habit is to be lazy,
manipulate the numbers, and assume everything worked.)  Implimented the
way I have described, a unit will never get automatically assigned to
anything unless a user specifically sets that up, and to do that they
have to know what unit they want.  E.g. even if we define x as meters
and only meters are allowed for assignment, x := 30 is still rejected
as an error.  x := 30 should never be a legal assignment for any kind
of dimensional variable, regardless of settings.  

I think what people are doing, when they say they want to describe the
variable x as being in meters, is that they want the CAS to know x is a
length and to always display it's value in meters.  That I can agree
with, but I would suggest that if such a feature is implimented it be
in such a way that it does NOT accept x := 30 as being an assignment of
the value of 30*m to the variable x.  This is exceptionally bad
practice and should be disallowed.  I prefer that something like the
following be put in place:

DefineDimension(variable, dimension) : This will associate a given
dimension with a variable.  I would suggest that x::dimension be
configured to do this, as well.

DefineDisplayUnit(variable, unit): This will a) automatically assign x
the dimension Length, and b) instruct Axiom to always convert a
displayed value of x into meters, whatever units it was assigned in or
the global settings tell it to display.  I'm not sure if x::unit is a
good idea or not, but probably should be done for consistency. 
Documentation would have to train people to use the more general
x::dimension if they want global unit settings to be workable.

DefineAssignableUnit(variable, unit):  This will allow assignments to
this variable ONLY if the form being assigned is of the form
variable*unit where unit matches the expected unit of the variable.  It
should not enable an assignment without specifying unit.  Perhaps it
should set the output flag of DefineDisplayUnit as well, or best of all
a flag could control whether it does or not, with the default being
yes.

Does this seem to make sense? 

> Ah, I've heard of dimensional analysis once. That rather checks
> whether the type of the result has the correct format. Oh, that 
> somehow seems to suggest the domain way. But first explain. And
> maybe let me sleep then a night about it.

Hopefully the above outlines it - "dimensions are what units describe"
is probably the shortest way to put it I know.  units can share a
dimension, dimensions do not share units.  Dimensional analysis will
report the dimension of an expression, not the units of that expression
(e.g. Time instead of minutes).  It is useful for checking that an
equation gives you the type of dimension you expect - for example if
you define F=ma and dimensional analysis of F gives you Energy, you
know you goofed somewhere (this is less obvious sometimes with units,
particularly in complex cases.)  It also is useful for giving you an
idea of what some quantities in science actually correspond to
physically (also often not as obvious and would be nice.)

Hopefully I'm thinking about all this correctly.  Most people never
need to delve into the nature of units like this - or maybe most other
science types figured this out sooner and more easily than I did,
assuming I've got it right.  Either way, a units package in Axiom will
make it all explicit and documented, if done correctly :-).

> Well, yes, but as far as I understand you want to distinguish the
> type of the units (length, time, mass, etc.). So maybe the 
> metadomain approach would be a good idea.

Distinguishing the type of the units is essential for knowing what
legal operations for "+" are, just for starters.  This is where my
knowledge of Axiom is too limited to know what the good mappings are -
hopefully that will emerge.  I'm pretty sure there IS a good mapping -
it just needs to be hammered out :-).

\start
Date: Tue, 23 Aug 2005 18:08:14 +0200
From: Martin Rubey
To: William Sit
Subject: Re: Unit package question

William Sit writes:

 > The complications of units come from the conversion factors, which
 > are generally floating point numbers (and dimensionless). This
 > would be ok if we only deal with numerical quantities. For symbolic
 > quantities, it is the dimensions that are more important and
 > conversion factors (not to be confused with universal physical
 > constants) are seldom used, and universal physical constants are
 > often denoted by a symbol (such as "g" for acceleration due to
 > gravity) without units.  Thus we should leave symbolic computed
 > expressions alone (that is, in the set S, even though it is
 > actually in some domain of UnitSystem(S), see below).
 
...

 > A representation for any of the domains of unitMass(s:S) would be
 >  
 >    Rep:= Record(value:S, dim:Dimension)
 >
 > where Dimension would be 
 > 
 >   Dimension:=Union("Mass", "Length", ...)

This would not allow for Length/Time

 > We need a way to include universal constants, the notation of which
 > depends on the set S.

 > if S has Field then
 >   unitAcceleration(dv:%, t:%):% == [dv/t, "Acceleration"]$Rep
 >   if S has RetractableTo(Symbol) then
 >     accelerationDueGravity == ['g:Symbol::S, "Acceleration"]$Rep
 > 
 > If S does not have RetractableTo(Symbol), for example S is Float, then we
 > can use a specific constant such as 9.81 depending on the domain
 > %:UnitSystem instead of a symbol g.


This is a nice idea. However, very probably we also need the case of S
being Fraction Integer. So, as I said in my previous post, we may need
to allow for a scalar factor of domain EXPR INT to accomodate
constants which cannot be thrown into S, thus we'd have

  Rep:= Record(value:S, constant: Constant, dim:Dimension)

where Constant would be something like Fraction Polynomial Integer,
with all coefficients equal to one...

\start
Date: Tue, 23 Aug 2005 09:21:51 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Ralf Hemmecke
Subject: Re: Unit package question

> I think that it is probably better if we speak with one voice 
> instead of asking Stephen Watt all seperately. I suggest that we
> draft a letter (maybe in paper) and all sign it and then send it 
> to Stephen.

Sounds good to me.  That oughta be an interesting postage trail :-). 
So it doesn't get lost in the shuffle, who writes it?
 
> Furthermore, I think that we should also ask him to "freeze" the
> Aldor spezification. That is: Anything that calls itself Aldor
> should be an implementation of the grammar described in the Aldor
> User Guide.

Sorta like Java - in order to use the Java trademark Sun insists you
qualify as Java according to the specs?  Sounds good to me!  Is Aldor
trademarked?

\start
Date: Tue, 23 Aug 2005 12:59:43 -0400
From: William Sit
To: Martin Rubey
Subject: Re: Unit package question

Martin Rubey wrote:
> 
> William Sit writes:
 
>  > A representation for any of the domains of unitMass(s:S) would be
>  >
>  >    Rep:= Record(value:S, dim:Dimension)
>  >
>  > where Dimension would be
>  >
>  >   Dimension:=Union("Mass", "Length", ...)
> 
> This would not allow for Length/Time

You can add (among the ...) "Velocity" (I already used "Acceleration" in the
examples). Also, we can expand Dimension to a fuller domain that can do
arithmetic, and equating Length/Time as Velocity (but notice that there are
cases where the fundamental units are the same, but the physical derived unit
can have multiple meaning: Length*Force can be Work or Moment, so dimensions
should not be confused with their component basic dimensions).

>  > We need a way to include universal constants, the notation of which depends on
>  > the set S.
>  >
>  > if S has Field then
>  >   unitAcceleration(dv:%, t:%):% == [dv/t, "Acceleration"]$Rep
>  >   if S has RetractableTo(Symbol) then
>  >     accelerationDueGravity == ['g:Symbol::S, "Acceleration"]$Rep
>  >
>  > If S does not have RetractableTo(Symbol), for example S is Float, then we
>  > can use a specific constant such as 9.81 depending on the domain
>  > %:UnitSystem instead of a symbol g.
> 
> This is a nice idea. However, very probably we also need the case of S being
> Fraction Integer. So, as I said in my previous post, we may need to allow for a
> scalar factor of domain EXPR INT to accomodate constants which cannot be thrown
> into S, thus we'd have
> 
>   Rep:= Record(value:S, constant: Constant, dim:Dimension)
> 
> where Constant would be something like Fraction Polynomial Integer, with all
> coefficients equal to one...

I do not follow the role of constant in the above syntax.
 
The "lift" category I proposed can handle this (by enlarging S when needed).
Meanwhile, S most likely should have RetractableTo(Symbol) and hence we can use
symbolic constants within S. My proposal is to delay all the floating point
computations to the end, in a chosen unit system like CGS, and to do those
computations and displays in CGS(Float).

Moreover, derived dimensions (involving arithmetic of basic dimensions) should
only be allowed to be attached to a value domain S if S has the corresponding
operations.

I don't think the use of mixed unit systems in an expression should be
encouraged: one should not encourage the use of 3 meter + 5 feet (not even 3
meter + 10 kilometer) because the answer must be either in feet or in meter or
something else, but only one unit. So the way to handle mixed unit expression
should be to first convert say 5 feet to meter before addition. I would not
worry about such expressions since that is not "scientific" (Axiom: The
Scientific Computation System).

To repeat, my view of units is that units are "decorations" to be handled in the
domains of UnitCategory(S), using a fixed unit system, and by coercion to
OutputForm;and one should adhere to the standards as given by:

http://physics.nist.gov/Document/checklist.pdf

\start
Date: Tue, 23 Aug 2005 11:31:32 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package question

> Very interesting topic, which I have been following.
> 
> I like the idea for a "pivotal unit". What better one to use than the
> international system of units (SI)? 
> 
> http://physics.nist.gov/cuu/Units/

Sounds good to me.  The only fly in the ointment is kilograms for mass,
but this can be handled.  (It might not be an issue if we don't
automate metric prefixes anyway.)

BTY, what is the actual difference between SI and MKS?
 
> Different schemes for implementation have been proposed, some even
> coded. I don't like the idea of having one domain for each 
> dimension (there are 7 base units listed in SI) because we would 
> then have to have new domains for derived dimensions like "force".  

Is that a bad thing, necessarily?  I know there are a fair number of
derived dimensions, but I think it's on the order of 10^1, not 10^2 or
10^3.  That way we can deal with any quirks on a per-dimension basis,
which would be conceptually a good match with the "real world."  Are
there reasons it's a bad idea to define large numbers of domains in
Axiom?

> Axiom has a way to handle number systems and I think
> the unit systems can follow this number system model which has an
> IntegerNumberSystem category with four domains: Integer,
> RomanNumeral, MachineInteger, and SingleInteger. So we can have 
> one category UnitSystem, with domains like CGSSystem, MKSSystem, 
> InternationalSystem, etc, where InternationalSystem would be the 
> default, and the other systems convert to and from this. 

I like this as a user option, but I'm wary of it as a fundamental
structuring mechanism - what about the case where a user finds it
convenient to adjust dimension to a custom default, say wanting Length
to be displayed as nanometers by default instead of meters, but leave
most SI units in place?  (I do understand and agree with the appeal of
this as a way to group definitions of units in terms of SI units - it
does organize that well.)  Where do we put definitions for units not an
official part of SI or one of the other systems?  What if (for whatever
reason) someone wants to mix and match CGS and MKS over the various
dimensions - what mechanism do we use?  I don't think we want to
restrict that behavior - it might be unusual but can't really be called
bad practice, since having whatever units happen to be intuitive
available is perfectly legit, especially when the tools exist (or will
exist ;-) to automatically standardize all units for publication :-).

> In the UnitSystem category, we specify dimensions,
> beginning with the seven basic dimensions (length, mass, time,
> electric current, thermodynamic temperature, amount of substance, 
> and luminous intensity) and expanded to include other derived 
> dimensions. The UnitSystem category should allow a parameter 
> S:SetCategory. In principal, units are input/output "decorations"
> attached to expressions from any set S. 

Hmm.  So instead of domains, we specify the existance of dimensions in
the category definition, and then create domains based around standard
measurement systems which must provide unit definitions for all defined
domains in their category?  

> The complications of units come from the conversion factors, which
> are generally floating point numbers (and dimensionless). This 
> would be ok if we only deal with numerical quantities. For symbolic
> quantities, it is the dimensions that are more important and 
> conversion factors (not to be confused with universal physical 
> constants) are seldom used, and universal physical constants
> are often denoted by a symbol (such as "g" for acceleration due to 
> gravity) without units.

Yes, I hadn't gotten to physical constants yet - I figured Units should
be in place first :-).  

> Thus we should leave symbolic computed expressions alone (that is,
> in the set S, even though it is actually in some domain of 
> UnitSystem(S), see below). The verification of dimension on the two 
> sides of a symbolic equation is not a simple matter since in the 
> applied sciences, one often "balance" dimension with
> a constant of proportionality, for which there is no a priori
> assignment of dimension in general.

Hmm.  Did you have an example in mind?  Sometimes that helps.  

Are you referring to the problem that some combinations of units that
will occurr will not map to a derived dimension?  We must allow for
expressions which are composed of the product of base and derived
dimensions - that's inevitable.  Does that pose a problem?

If you're looking to determine dimensional equality, the best way I
know is to reduce everything to the seven base dimensions and simplify.
 That might be a bit more CPU intensive than taking shortcuts in the
case of complex expressions, but it is the most general way I know of
and has the best chance of succeeding in general.

[snip]

> unitMass(s:S) would declare that the expression s has dimension Mass
> and unit of Mass for the domain %: UnitSystem(S). I think this is
> better than the syntax s::Mass or s::Kg because it avoids the need 
> for many domains (which would be difficult to maintain).

I guess I'm not understanding the difficulty of maintaining domains -
unless there would be problems setting it up, wouldn't it be a one time
effort to create the domains and then occasional additions and unit
definition updates?

[snip]

> So far, the above discussion concentrates on the symbolic side. It
> also separates conceptually the notions of dimensions vs units. To
> handle the numerical side as well as conversion between different 
> unit systems, one can have a "lift" (functor) category that 
> performs this (much like the coercions between different types of 
> polynomial domains when the coefficient domains are mapped):
> 
>    UnitSystemLifting(US:UnitSystem(S), UT:UnitSystem(T))
> 
> would take elements of say, US=CGS(S) to UT=CGS(Float), or to
> UT=MKS(S).

This works for things contained in systems, but what about
piecemeal/custom setups?

> These are just some beginning thoughts, which certainly need serious
> critique from all.

I like a lot of these ideas, I guess I'm just confused by your
adversion to domains - or rather, I don't fully understand the
difficulties associated with them.  What do we gain by defining
dimensions in the Category, instead of doing the dimensions as domains
and defining the unit systems in terms of specific unit choices for 
available dimensions?

Just curious - lord knows I'm not informed enough to critique :-).

\start
Date: Tue, 23 Aug 2005 11:43:28 -0700 (PDT)
From: Cliff Yapp
To: William Sit, Martin Rubey
Subject: Re: Unit package question

> Martin Rubey wrote:
> > This would not allow for Length/Time
> 
> You can add (among the ...) "Velocity" (I already used 
> "Acceleration" in the examples). Also, we can expand Dimension
> to a fuller domain that can do arithmetic, and equating Length/Time 
> as Velocity (but notice that there are cases where the fundamental 
> units are the same, but the physical derived unit can have multiple
> meaning: Length*Force can be Work or Moment, so dimensions
> should not be confused with their component basic dimensions).

That's a good point, but the distinction is most definitely based on
circumstance.  What would we do if someone assigns or enters a
non-dimensionally-unique unit?  Or one falls out of a calculation?  How
do we do dimensional analysis?  (For that matter, how would that be
handled in the "real world" - are Work and Moment in some sense the
same thing? If not, how can the difference be expressed?)

> I don't think the use of mixed unit systems in an expression should
> be encouraged: one should not encourage the use of 3 meter + 5 feet 
> (not even 3 meter + 10 kilometer) because the answer must be either
> in feet or in meter or something else, but only one unit. 

Right.  I don't understand the difficulty here - the only place mixed
unit systems would be likely to occur is in an input, and the first
thing to do will be to convert them to standard units.  We want people
to be able to enter 3 meter + 5 feed and get x meters out - that's one
of the things a unit package is good for!

> So the way to handle mixed unit expression should be to first 
> convert say 5 feet to meter before addition. I would not
> worry about such expressions since that is not "scientific" (Axiom:
> The Scientific Computation System).

Do you mean worry about preserving them interally or as output?  If so,
I agree.  As input, they should be legal if dimensionally legal and
converted internally to useful form.

> To repeat, my view of units is that units are "decorations" to be
> handled in the domains of UnitCategory(S), using a fixed unit
> system, and by coercion to OutputForm;and one should adhere to the 
> standards as given by:
> 
> http://physics.nist.gov/Document/checklist.pdf

Absolutely agree.  In fact, we should incorporate that document and/or
other relevant documentation into our eventual coding of the output
logic for units, IMO.

\start
Date: Tue, 23 Aug 2005 17:58:54 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package question

C Y wrote:
> 
> --- William Sit wrote:
> 
> > Very interesting topic, which I have been following.
> >
> > I like the idea for a "pivotal unit". What better one to use than the
> > international system of units (SI)?
> >
> > http://physics.nist.gov/cuu/Units/
> 
> Sounds good to me.  The only fly in the ointment is kilograms for mass,
> but this can be handled.  (It might not be an issue if we don't
> automate metric prefixes anyway.)
> 
> BTY, what is the actual difference between SI and MKS?

I have not researched the difference, but that is a minor point in terms of
implementation design. 

 
> > Different schemes for implementation have been proposed, some even
> > coded. I don't like the idea of having one domain for each
> > dimension (there are 7 base units listed in SI) because we would
> > then have to have new domains for derived dimensions like "force".
> 
> Is that a bad thing, necessarily?  I know there are a fair number of
> derived dimensions, but I think it's on the order of 10^1, not 10^2 or
> 10^3.  That way we can deal with any quirks on a per-dimension basis,
> which would be conceptually a good match with the "real world."  Are
> there reasons it's a bad idea to define large numbers of domains in
> Axiom?

Yes Axiom can handle lots of domains, but that does not mean we HAVE to use one
domain for every physical quantity. See the SI pages for all the quantities.
Also separating the physical quantities into its own domain will cause a lot of
unnecessary coercions and since derived dimensions are obtained with arithmetic
operations, a domain like Force may not support that.

> > Axiom has a way to handle number systems and I think
> > the unit systems can follow this number system model which has an
> > IntegerNumberSystem category with four domains: Integer,
> > RomanNumeral, MachineInteger, and SingleInteger. So we can have
> > one category UnitSystem, with domains like CGSSystem, MKSSystem,
> > InternationalSystem, etc, where InternationalSystem would be the
> > default, and the other systems convert to and from this.
> 
> I like this as a user option, but I'm wary of it as a fundamental
> structuring mechanism - what about the case where a user finds it
> convenient to adjust dimension to a custom default, say wanting Length
> to be displayed as nanometers by default instead of meters, but leave
> most SI units in place?  

That is no problem at all. A user can create his/her own unit system domain by
modifying the implemented code for SI or CGS, or whatever. The user unit system
can mix units if that is preferred. The only restriction is that in symbolic
computation, that is, in equations involving physical quantity, the actual unit
should NOT be part of the equation, and if it is dimensionally balanced (all
additive terms have the same physical dimension -- but this is not sufficient,
you should not add Work to Moment), then the units can be handled in the unit
domains by modifying the coercions to OutputForm. For example, if "us"
represents a value s with dimension "Force", and one wants to output "Force" in
lb cm/hr^2, then one can have (syntax of Axiom need not be correct):

   coerce(us:MyUnitSystemDomain)==
     ...
     (dimension(us) case "Force") => 
        factor := ...
        hconcat(value(us)*factor::OutputForm, "lb cm/hr^2"::OutputForm)
     ...

where factor is to be computed depending on the (input) units for mass, length
and time in this domain (which NEED NOT be lb, cm, hr respectively). It can also
be handled by the "lift" packages that provides similar coercions. In other
words, units for each physical quantity does not have to be (but CAN be) derived
from the units of the basic dimensions. Let the coerce function handle all the
conversions.
         

> (I do understand and agree with the appeal of
> this as a way to group definitions of units in terms of SI units - it
> does organize that well.)  Where do we put definitions for units not an
> official part of SI or one of the other systems?  What if (for whatever
> reason) someone wants to mix and match CGS and MKS over the various
> dimensions - what mechanism do we use?  I don't think we want to
> restrict that behavior - it might be unusual but can't really be called
> bad practice, since having whatever units happen to be intuitive
> available is perfectly legit, especially when the tools exist (or will
> exist ;-) to automatically standardize all units for publication :-).

See above example.

> > In the UnitSystem category, we specify dimensions,
> > beginning with the seven basic dimensions (length, mass, time,
> > electric current, thermodynamic temperature, amount of substance,
> > and luminous intensity) and expanded to include other derived
> > dimensions. The UnitSystem category should allow a parameter
> > S:SetCategory. In principal, units are input/output "decorations"
> > attached to expressions from any set S.
> 
> Hmm.  So instead of domains, we specify the existance of dimensions in
> the category definition, and then create domains based around standard
> measurement systems which must provide unit definitions for all defined
> domains in their category?

Yes. A unit system should be coherent (even though this proposed set up will
allow unconventional systems) and Axiom should provide the common ones like CGS,
MKS, FPS (foot-lb-sec). Users can then modify one closest to their liking and
customize it. Other users can then write other domains in categorical terms if
dimensions are involved by referring to UnitSystem category.

> > The complications of units come from the conversion factors, which
> > are generally floating point numbers (and dimensionless). This
> > would be ok if we only deal with numerical quantities. For symbolic
> > quantities, it is the dimensions that are more important and
> > conversion factors (not to be confused with universal physical
> > constants) are seldom used, and universal physical constants
> > are often denoted by a symbol (such as "g" for acceleration due to
> > gravity) without units.
> 
> Yes, I hadn't gotten to physical constants yet - I figured Units should
> be in place first :-).

Physical constants are an integral part. Pi is a good example that appears in
many physical formulae.
 
> > Thus we should leave symbolic computed expressions alone (that is,
> > in the set S, even though it is actually in some domain of
> > UnitSystem(S), see below). The verification of dimension on the two
> > sides of a symbolic equation is not a simple matter since in the
> > applied sciences, one often "balance" dimension with
> > a constant of proportionality, for which there is no a priori
> > assignment of dimension in general.
> 
> Hmm.  Did you have an example in mind?  Sometimes that helps.

How about Weight = Mass * AccelerationDueGravity and
Circumference = Pi * Radius?

Both AccelerationDueGravity and Pi are considered constants (which is correct
only when each is converted to a numerical value after chosing a unit system):
but the first has a dimension of "Acceleration" and the second is dimensionless
(Dimension domain should include "None" in the Union("Mass", etc)).

Another example is specific heat c, defined by the equation: Q = c m dT, giving
c a dimension of energy/(mass * temp). The only way to find the dimension of
such a quantity in general is by "solving" (dimension analysis) but that only
provides the answer in terms of basic dimensions.
 
> Are you referring to the problem that some combinations of units that
> will occurr will not map to a derived dimension?  We must allow for
> expressions which are composed of the product of base and derived
> dimensions - that's inevitable.  Does that pose a problem?

There is no one-to-one conversion from rational expressions of basic dimensions
to physical quantities. When possible, the physical name of the dimension should
be retained (so moment cannot be confused with work; this also remind me that we
should separate scalar quantites from vector quantities).

> If you're looking to determine dimensional equality, the best way I
> know is to reduce everything to the seven base dimensions and simplify.
>  That might be a bit more CPU intensive than taking shortcuts in the
> case of complex expressions, but it is the most general way I know of
> and has the best chance of succeeding in general.
 
Agreed, but see above.
 
> > unitMass(s:S) would declare that the expression s has dimension Mass
> > and unit of Mass for the domain %: UnitSystem(S). I think this is
> > better than the syntax s::Mass or s::Kg because it avoids the need
> > for many domains (which would be difficult to maintain).
> 
> I guess I'm not understanding the difficulty of maintaining domains -
> unless there would be problems setting it up, wouldn't it be a one time
> effort to create the domains and then occasional additions and unit
> definition updates?

The reason against separate domains for each physical quantity (dimension in
this sense) is not just because there are lots of them, but because it would be
difficult to spell out the interrelationships and to create new ones. Yes,
everything is a one time effort, except when it comes to being used.

I suppose if there is no consensus, then we would have to implement with
different designs. Axiom can support that with no problem.
 
> > So far, the above discussion concentrates on the symbolic side. It
> > also separates conceptually the notions of dimensions vs units. To
> > handle the numerical side as well as conversion between different
> > unit systems, one can have a "lift" (functor) category that
> > performs this (much like the coercions between different types of
> > polynomial domains when the coefficient domains are mapped):
> >
> >    UnitSystemLifting(US:UnitSystem(S), UT:UnitSystem(T))
> >
> > would take elements of say, US=CGS(S) to UT=CGS(Float), or to
> > UT=MKS(S).
> 
> This works for things contained in systems, but what about
> piecemeal/custom setups?

I don't follow your question. I already explained above how anyone can design
his/her own unit system in the setup proposed.

> > These are just some beginning thoughts, which certainly need serious
> > critique from all.
> 
> I like a lot of these ideas, I guess I'm just confused by your
> adversion to domains - or rather, I don't fully understand the
> difficulties associated with them.  What do we gain by defining
> dimensions in the Category, instead of doing the dimensions as domains
> and defining the unit systems in terms of specific unit choices for
> available dimensions?

I don't know the difficulties about many domains either, since I have not tried
to implement them. I only have a hunch. It may turn out that having many domains
(one for each dimensional quantity) is easier (to use and to implement). Neither
do I have a clear picture of what I proposed, but at this point, I like it
better (until convinced otherwise). I like it because, as you asked, one can
design one's own unit system once, and then doesn't have to worry about it. I
also like it because it separates the symbolic expression from the units. The
functions of the form unitXXX can be used in assignment statements that carry
out a sequence of computations, verifying the dimensions and they stay in the
same domain (no need to load tons of domains and perform domain-to-domain
conversions (even if that is possible and meaningful). An example of such a
sequence of computation can be (assuming the domain S is FRAC POLY INT and we
use FPS(S) and we have implemented the arithmetic operations in FPS(S), as
inherited from S; the output units are put in brackets to separate them from the
expressions):

ux0:=unitLength('x0)

    x0 [ft]

uv0:=unitVelocity('v0)

    v0 [ft/s]

ut:=unitTime('t)

    t [s]

ua:=unitAcceleration('a)

    a [ft/s^2]


us:=ux0 + uv0*ut + ua * ut^2/2

    x0 + v0*t + a*t^2/2 [ft]

us::MYUnitSystem(S)

    (x0 + v0*t + a*t^2/2)*factor [yd/hr^2]

where factor is a number or an undefined symbolic convertion factor. One can
also input values in other system than the one used:

ux0:=unitLength(50)$MYUnitSystem(S)::FPS(S)

    150 [ft]

would take the input 50 [yd] (yd being the unit of length in MYUNitSystem(S))
and convert it to FPS(S). It is much easier to remember the name of a unit
system than to remember all the units of various dimensional quantities. Using
the Rep proposed in the previous message:

   Rep:=[value:S, dim:Dimension]

the last instruction first creates

   [50, "Length"] in MYUNitSystem(S)

and then converts it to 

   [150, "Length"] in FPS(S).

The conversion factor only arises when we change unit systems. If the conversion
factor is not coercible to S, we can leave it symbolic and undefined, like:

   [50 yd2ft, "Length"] in FPS(S)

and then one can evaluate:

subst(value(ux0), yd2ft, 3.0)

or better:

ux0::FPS(Float) 

   150.0 [ft]

will do the conversion without the user knowing how it is done.
 
> Just curious - lord knows I'm not informed enough to critique :-).

To quote Martin: "Don't say that"! Every question or idea contributes to the
eventual product. 

More critiques are welcome!

In another post, CY wrote:

> are Work and Moment in some sense the
> same thing? If not, how can the difference be expressed?

The two are different. Moment (in physics) is a measure of tendency to produce
motion especially about a point or axis and is computed by the product of
quantity (as a force) and the distance to a particular axis or point. Work is
the transference of energy that is produced by the motion of the point of
application of a force and is measured by multiplying the force and the
displacement of its point of application in the line of action. (Both taken from
Merriam-Webster On-line).

> > So the way to handle mixed unit expression should be to first
> > convert say 5 feet to meter before addition. I would not
> > worry about such expressions since that is not "scientific" (Axiom:
> > The Scientific Computation System).
> 
> Do you mean worry about preserving them interally or as output?  If so,
> I agree.  As input, they should be legal if dimensionally legal and
> converted internally to useful form.
> 
Yes, we CAN allow input like 3 meter + 5 feet, but the question is, how is the
system going to tell whether the user wants meter or feet in the answer? In my
scenario, the user would be forced to do something like

(unitLength(3)$MKS(S) + unitLength(5)$FPS(S))::MKS(S)

    3 + 5*ft2m [meter]

which may not be that bad, because it forces the user to think carefully and
spell out explicitly the units used. (This certainly would have prevented the
crash on Mars). 
In the domain-preferred scenario, this would be:

   (3 meter + 5 feet)::meter

The disadvantage of the former is it is long-winded, but the user does not have
to know the actual units in the systems and there is no new syntax to be
learned. The disadvantage of the latter is that the user needs to know the
units, and the units takes up name space (meter and feet would have to be
reserved words) and either a new syntax has to be constructed or the domains
"meter", etc needs to know about arithmetic. It is certainly more intuitive, for
simple units at least (can anyone name the unit for viscosity or thermal
diffusivity offhand?) Given the number of unit systems and the number of
physical quantities, I would opt for not having to know them except the system
names, or just MYUnitSystem.

\start
Date: Tue, 23 Aug 2005 18:46:30 -0400
From: William Sit
To: Cliff Yapp, Martin Rubey, Ralf Hemmecke
Subject: Re: Unit package question


William Sit wrote:
> For example, if "us"
> represents a value s with dimension "Force", and one wants to output "Force" in
> lb cm/hr^2, then one can have (syntax of Axiom need not be correct):
> 
>    coerce(us:MyUnitSystemDomain)==
>      ...
>      (dimension(us) case "Force") =>
>         factor := ...
>         hconcat(value(us)*factor::OutputForm, "lb cm/hr^2"::OutputForm)
>      ...

Correction: the unit of Force should be slug cm /hr^2 in the above example. lb
is already a unit of force in the US system.

\start
Date: Tue, 23 Aug 2005 15:53:33 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package question - Reply to 1st half 

> That is no problem at all. A user can create his/her own unit 
> system domain by modifying the implemented code for SI or CGS, or 
> whatever.

That, at least, I would prefer to avoid.  If the user sets SI or CGS, I
think we would prefer to avoid requiring them to program spad code to
set up anything customized for a specific situation when a couple of
local overrides would work.

> The user unit system can mix units if that is preferred. 

So you're envisioning a separate level of logic which handles user
settings, and the underlying one organized as outlined below?

> The only restriction is that in symbolic computation, that is, in 
> equations involving physical quantity, the actual unit
> should NOT be part of the equation, and if it is dimensionally
> balanced (all additive terms have the same physical dimension -- 
> but this is not sufficient, you should not add Work to Moment), 
> then the units can be handled in the unit domains by modifying the
> coercions to OutputForm. 

We can make it stronger by requiring all additive terms to have the
same dimension, and not allow derived dimensions with the same units to
be automatically merged.  (Really, if they could be merged all we would
need to do is define a few more aliases for the original dimension, as
opposed to making a separate one. If we make Work and Moment separate
derived dimensions, they won't merge at the symbolic level.  However,
we will have to make a decision as to the mapping of a unit back to a
variable with a dimension matching the unit's MKS base unit definition
- do we assume if someone is assigning a variable with dimension Work a
value with units compatible with Work, it is a Work quantity and not a
Moment quantity?  The same problem holds for dimensional analysis - we
should report something.  Do we report Work, Moment, or both?  If
someone enters a purely unit based expression and wants dimensional
analysis of it, what do we do?  Erroring out with something like
"non-unique dimensional mapping - please specify dimension type for
<error generating unit> - {Work, Moment}" would probably be the most
correct way.  Maybe we could have a setting which was either strict
(above behavior) or fuzzy (assumes in a case where there are multiple
possibilities the user knew what they were doing, in order to avoid
endless aggrevation when working on basic problems?  If a scientist
knows Moment is not part of his system, he can use fuzzy matching for
casual work and get strict about it for the final draft :-). And it
would also be good to document the physical reasons behind such design
decisions, so people who aren't physics gurus could figure out why the
CAS is grumbling at them ;-)

> For example, if "us" represents a value s with dimension "Force", 
> and one wants to output "Force" in lb cm/hr^2, then one can have 
> (syntax of Axiom need not be correct):
> 
>    coerce(us:MyUnitSystemDomain)==
>      ...
>      (dimension(us) case "Force") => 
>         factor := ...
>         hconcat(value(us)*factor::OutputForm, "lb
> cm/hr^2"::OutputForm)
>      ...
> 
> where factor is to be computed depending on the (input) units for
> mass, length and time in this domain (which NEED NOT be lb, cm, hr 
> respectively). It can also be handled by the "lift" packages that 
> provides similar coercions. In other words, units for each physical 
> quantity does not have to be (but CAN be) derived
> from the units of the basic dimensions. Let the coerce function
> handle all the conversions.
          
Well, as long as we put an intuitive front end on everything for the
end user, I'm OK.  A bit of context - for the Maxima units package I
have a function setunits() which takes as an argument a list of
variables, and sets those to be the default output units for each
dimension.  It returns an error if there is more than one unit
corresponding to a given dimension.  I would prefer to be able to do
this in Axiom, as well.  Here's one scenario: I start up Axiom and have
the default system load up in SI units.  I look at my data, and realize
I'm working on a scale of nanometers.  SI is ideal for most everything
I'm going to be doing, but I want Length output to be in nm so I don't
have to visually sort through lots of powers of ten.  In Maxima, I
could simply say setunits(nm) and from that point on, until I told it
differently, all my lengths would be converted and rendered in output
as nanometers.  I would like similar ease of use in Axiom, if it is
compatible with how Axiom works - I'd rather not have to open up the
text editor, whip out a new MyUnits domain, and define things
accordingly - I'd rather that all be hidden.
 
> Yes. A unit system should be coherent (even though this proposed set
> up will allow unconventional systems) and Axiom should provide the 
> common ones like CGS, MKS, FPS (foot-lb-sec). Users can then modify
> one closest to their liking and customize it.

That's the part that worries me a little - as a user I want to just say
"use MKS" and then "but render Mass in slugs" without ever worrying
about domains, convert functions, or any details I don't have to.  At
next axiom startup my "render Mass in slugs" preference is lost, which
is find with me - it was a purely temporary condition.

> Other users can then write other domains in categorical
> terms if dimensions are involved by referring to UnitSystem 
> category.

Depending on how sophisticated the user is, yes.

> Physical constants are an integral part. Pi is a good example that
> appears in many physical formulae.

Pi (3.14... right) is a unitless number, and so (hopefully) isn't a
worry from a units standpoint?  Am I missing something?

Hmm, perhaps I should clarify - when I say physical constants I'm
thinking things like speed of light, Plank's constant, mass of an
electron, etc - i.e. things with units.  Am I using incorrect
terminology?

> How about Weight = Mass * AccelerationDueGravity and
> Circumference = Pi * Radius?
> 
> Both AccelerationDueGravity and Pi are considered constants (which 
> is correct only when each is converted to a numerical value after 
> chosing a unit system): but the first has a dimension of
> "Acceleration" and the second is dimensionless (Dimension domain 
> should include "None" in the Union("Mass", etc)).

Oh, got it (I think) - you're considering how to treat dimensionless
objects in a dimensional analysis?
 
> Another example is specific heat c, defined by the equation: 
> Q = c m dT, giving c a dimension of energy/(mass * temp). The only 
> way to find the dimension of such a quantity in general is 
> by "solving" (dimension analysis) but that only provides the 
> answer in terms of basic dimensions. 

Right, then you do pattern matching to see if those basic dimensions
map into any of the derived dimensions.  (Or at least, that's what I
did in Maxima.  Maybe that's not workable here - I'll have to think
about it a bit.)

OK, gotta run to a dinner appointment - I'll reply to the second half
later :-).  Very interesting stuff!

\start
Date: Tue, 23 Aug 2005 20:49:21 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package question - Reply to 1st half

C Y wrote:
> 
> --- William Sit wrote:
> 
> > That is no problem at all. A user can create his/her own unit
> > system domain by modifying the implemented code for SI or CGS, or
> > whatever.
> 
> That, at least, I would prefer to avoid.  If the user sets SI or CGS, I
> think we would prefer to avoid requiring them to program spad code to
> set up anything customized for a specific situation when a couple of
> local overrides would work.

It is easy to create functions to reset the units in any domain of UnitSystem
category. We just have to do this by providing functions like:

setUnitLength(nm)  -- assuming we use SI abbreviations.

However, for the package to provide such generality would require not only
updating an internal table (it will require one anyway, of all the units
corresponding to physical quantities (dimensions)) but also that the output
coercions figure out the factors before output. This does complicate the output
coercions because there can be many cases to deal with even if we restrict such
user settings to the seven basic dimensions. If a normal range of powers of 10
is from -30 to 30 (which includes nanoscale to astronomical scales, and enlarge
the range if you like), there would be about 20 cases to check for each basic
dimension (allowing one new prefix for every third value of the exponent). On
the other hand, a user custom unit system need only modify simple code for the
specific units. Generalities quickly expands the cases exponentially.

The set functions will also have to do error checking (that is, verify that nm
is indeed a unit of length, or at least among the units it knows). Again, this
would complicate the implementation of the domains for UnitSystem category.
Would you allow, for example, in SI(S), setUnitLength(ft)? (I would vote a
definite No).

Remember, a user can do such unit conversion by coercion if Axiom thinks that
nanoscale is a common unit system and provides one. We can also provide one for
astronomical units. The idea is to allow gradual growth to satisfy user needs,
but the first implementations do not have to be all-encompassing. The design has
to be.

> > The user unit system can mix units if that is preferred.
> 
> So you're envisioning a separate level of logic which handles user
> settings, and the underlying one organized as outlined below?

Yes, but that scenario is not encouraged (indeed discouraged), even though it
can be done. 
 
> > The only restriction is that in symbolic computation, that is, in
> > equations involving physical quantity, the actual unit
> > should NOT be part of the equation, and if it is dimensionally
> > balanced (all additive terms have the same physical dimension --
> > but this is not sufficient, you should not add Work to Moment),
> > then the units can be handled in the unit domains by modifying the
> > coercions to OutputForm.
> 
> We can make it stronger by requiring all additive terms to have the
> same dimension, and not allow derived dimensions with the same units to
> be automatically merged.  (Really, if they could be merged all we would
> need to do is define a few more aliases for the original dimension, as
> opposed to making a separate one. If we make Work and Moment separate
> derived dimensions, they won't merge at the symbolic level. 

All I am saying is that even if an equation is dimensionally correct, it could
still be wrong (in terms of physics) because of this non-unique mapping. We
certainly cannot just use dimensional analysis (reducing to basic dimensions) to
discover that Work = Moment is wrong. 

> However,
> we will have to make a decision as to the mapping of a unit back to a
> variable with a dimension matching the unit's MKS base unit definition
> - do we assume if someone is assigning a variable with dimension Work a
> value with units compatible with Work, it is a Work quantity and not a
> Moment quantity?  

In my scheme, you do not assign a variable to its unit explicitly. You assign a
dimension to the value (which has no unit attached explicitly, and only
implicitly based on the domain the result of unitXXX function). This frees the
symbolic computation of units, the way it is usually done in science.

> The same problem holds for dimensional analysis - we
> should report something.  Do we report Work, Moment, or both?  If
> someone enters a purely unit based expression and wants dimensional
> analysis of it, what do we do?  Erroring out with something like
> "non-unique dimensional mapping - please specify dimension type for
> <error generating unit> - {Work, Moment}" would probably be the most
> correct way. 

I don't understand this question. There is NO unique way to decompose ANY
rational expression in basic dimensions and return it as a result of (rational
expression) in physical derived dimensions. Dimensional analysis is a one-way
method: reduce derived dimensions into its basic dimensions and match the
exponents for each basic dimension. 

> Maybe we could have a setting which was either strict
> (above behavior) or fuzzy (assumes in a case where there are multiple
> possibilities the user knew what they were doing, in order to avoid
> endless aggrevation when working on basic problems?  If a scientist
> knows Moment is not part of his system, he can use fuzzy matching for
> casual work and get strict about it for the final draft :-). And it
> would also be good to document the physical reasons behind such design
> decisions, so people who aren't physics gurus could figure out why the
> CAS is grumbling at them ;-)

Even a so-called "dimensionless" quantity can sometimes have "dimension":

  phase angle: unit radian, dimension m.m^(-1)
  solid angle: unit steradian, dimension m^2. m^(-2)

See: http://physics.nist.gov/cuu/Units/units.html

There is no hope to list all possibilities.  Another example taken from that
page:

  absorbed dose (specific energy imparted), unit gray, dimension m^2.s^(-2). 

The dimension is actually meaningless. Expressed in terms of derived dimensions, 
1 gray is 1 J/kg (makes perfect sense as energy/mass). But one can also say the
dimension is that of velocity^2 in other context.

> 
> > For example, if "us" represents a value s with dimension "Force",
> > and one wants to output "Force" in [slug] cm/hr^2, then one can have
> > (syntax of Axiom need not be correct):
> >
> >    coerce(us:MyUnitSystemDomain)==
> >      ...
> >      (dimension(us) case "Force") =>
> >         factor := ...
> >         hconcat(value(us)*factor::OutputForm, "[slug]
> > cm/hr^2"::OutputForm)
> >      ...
> >
> > where factor is to be computed depending on the (input) units for
> > mass, length and time in this domain (which NEED NOT be lb, cm, hr
> > respectively). It can also be handled by the "lift" packages that
> > provides similar coercions. In other words, units for each physical
> > quantity does not have to be (but CAN be) derived
> > from the units of the basic dimensions. Let the coerce function
> > handle all the conversions.
> 
> Well, as long as we put an intuitive front end on everything for the
> end user, I'm OK.  A bit of context - for the Maxima units package I
> have a function setunits() which takes as an argument a list of
> variables, and sets those to be the default output units for each
> dimension.  It returns an error if there is more than one unit
> corresponding to a given dimension.  I would prefer to be able to do
> this in Axiom, as well.  Here's one scenario: I start up Axiom and have
> the default system load up in SI units.  I look at my data, and realize
> I'm working on a scale of nanometers.  SI is ideal for most everything
> I'm going to be doing, but I want Length output to be in nm so I don't
> have to visually sort through lots of powers of ten.  In Maxima, I
> could simply say setunits(nm) and from that point on, until I told it
> differently, all my lengths would be converted and rendered in output
> as nanometers.  I would like similar ease of use in Axiom, if it is
> compatible with how Axiom works - I'd rather not have to open up the
> text editor, whip out a new MyUnits domain, and define things
> accordingly - I'd rather that all be hidden.

Yes, as explained earlier, we CAN provide such functionality. I don't know how
you implemented that in Maxima, but I think it would be cumbersome if
restrictions are not set.

> > Yes. A unit system should be coherent (even though this proposed set
> > up will allow unconventional systems) and Axiom should provide the
> > common ones like CGS, MKS, FPS (foot-lb-sec). Users can then modify
> > one closest to their liking and customize it.
> 
> That's the part that worries me a little - as a user I want to just say
> "use MKS" and then "but render Mass in slugs" without ever worrying
> about domains, convert functions, or any details I don't have to.  At
> next axiom startup my "render Mass in slugs" preference is lost, which
> is find with me - it was a purely temporary condition.

I really don't think a scientific worker would use slugs with MKS. I would
emphatically discourage you from doing that! Making it very easy for a user to
"violate" a system of units is asking for trouble. Making it more difficult at
least ensures the user knows or thinks about what (s)he is doing. I don't
implement generality for generality's sake. Life is too short.

Don't mix unit systems! Convert first before you start the computations, and
convert back if you really have to.

> > Other users can then write other domains in categorical
> > terms if dimensions are involved by referring to UnitSystem
> > category.
> 
> Depending on how sophisticated the user is, yes.

Alright, other developers, not users.
 
> > Physical constants are an integral part. Pi is a good example that
> > appears in many physical formulae.
> 
> Pi (3.14... right) is a unitless number, and so (hopefully) isn't a
> worry from a units standpoint?  Am I missing something?

Let's see. A circle spans 2 pi radians at its center. So 2 pi radians = 360
degrees.
So pi has unit degree/radian (even though that is dimensionless) when it is
viewed as a unit conversion factor between radians and degrees.

> 
> Hmm, perhaps I should clarify - when I say physical constants I'm
> thinking things like speed of light, Plank's constant, mass of an
> electron, etc - i.e. things with units.  Am I using incorrect
> terminology?

That is correct. And there are physical constants and mathematical constants.
:-)
 
> > How about Weight = Mass * AccelerationDueGravity and
> > Circumference = Pi * Radius?
> >
> > Both AccelerationDueGravity and Pi are considered constants (which
> > is correct only when each is converted to a numerical value after
> > chosing a unit system): but the first has a dimension of
> > "Acceleration" and the second is dimensionless (Dimension domain
> > should include "None" in the Union("Mass", etc)).
> 
> Oh, got it (I think) - you're considering how to treat dimensionless
> objects in a dimensional analysis?

Dimensionless is not always without dimension and physical constants often have
dimensions.
 
> > Another example is specific heat c, defined by the equation:
> > Q = c m dT, giving c a dimension of energy/(mass * temp). The only
> > way to find the dimension of such a quantity in general is
> > by "solving" (dimension analysis) but that only provides the
> > answer in terms of basic dimensions.
> 
> Right, then you do pattern matching to see if those basic dimensions
> map into any of the derived dimensions.  (Or at least, that's what I
> did in Maxima.  Maybe that's not workable here - I'll have to think
> about it a bit.)

One may do a certain amount of guessing or pattern matching, but that is limited
by one's current knowledge (limited, at best). The example I gave earlier,
m^2.s^(-2), would you even have thought of it as absorbed dose? (I certainly
didn't before writing this email). Given the vastness of scientific research,
you need a subject matter expert to increase the chance of meaningful matching.
The user is often the subject matter expert. Let him or her deal with it.


> OK, gotta run to a dinner appointment - I'll reply to the second half
> later :-).  Very interesting stuff!
> 
Dinner bell just rung for me too. Thanks for the discussions.

\start
Date: Tue, 23 Aug 2005 20:38:36 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Exports == Implementation

CY,

One thing to keep in mind is that Axiom defines things from
the category level. Perhaps we need to work out the category
relationship between the ideas of Force, Energy, etc before
we develop the specific domains. I'm picturing a diagram
similar to the endpapers on the Axiom book (or see
src/doc/endpapers.pamphlet)

\start
Date: Tue, 23 Aug 2005 20:36:27 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Exports == Implementation

CY,

This is a convention (not universally followed). The definition of
a domain has a signature, a list of functions it exports and the
implementation of those functions.

Axiom's syntax for a macro is 

  name ==> definition

so you'll see things like:

foo(R: Ring): Exports == Implementation

  Exports ==> ...
  Implementation ==> ...

The left and right sides of the '==' are given in macro definitions.
You could have easily said:

foo(R: Ring): Left == Right

  Left ==> ...
  Right ==> ...

I agree that we need to define the syntax with a real example.
Perhaps if we develop the Dimension package in public we can
use it as an example of developing a domain and a give complete,
step-by-step explanation in the pamphlet. We could include it as
a chapter in the Programmer's Guide in the axiom--book--1 tree.

I wrote a similar chapter for Aldor years ago. I'm not sure if
it is still part of the aldor docs.

\start
Date: Tue, 23 Aug 2005 20:43:56 -0500
From: Tim Daly
To: Cliff Yapp
Subject: 'this'

CY,

$ and % are semantically the same thing but the syntax was changed
late in the development from $ (meaning 'this' domain) to % meaning
the same thing. This was done to make the Aldor and Axiom syntax
the same. The Aldor compiler came late in the Axiom development and
drove a lot of cleanup and changes back into Axiom.

\start
Date: Tue, 23 Aug 2005 21:24:48 -0500
From: Tim Daly
To: Kai Kaminski
Subject: Dr. Dobbs article
Cc: Bill Page

Kai,

I believe you should try to do the Dr. Dobbs article. Publication is a
worthwhile exercise especially for a student. I published an article in
Byte magazine (WAY before your time) and it was a great learning experience.

\start
Date: Tue, 23 Aug 2005 21:19:25 -0500
From: Tim Daly
To: Bill Page
Subject: 'this'

Bill,

Sorry for being so unresponsive but the new job has a deadline of 9/1
and I'm running uphill to try to catch a clue or two.

re: MathAction server costs. Don't worry about it. It's covered.

re: CAISS as sponsor. It's true I no longer work there but we all
owe CAISS and Gilbert Baumslag (the director) more than we can repay.
Leave the sponsorship on the first page.

CMU is a different story and all of my Axiom work is nights/weekends.
If this changes we can list them as a sponsor but please don't do 
anything until I have the discussion and the permission.

\start
Date: Tue, 23 Aug 2005 23:09:58 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package question - Reply to 1st half

C Y wrote:
> Here's one scenario: I start up Axiom and have
> the default system load up in SI units.  I look at my data, and realize
> I'm working on a scale of nanometers.  SI is ideal for most everything
> I'm going to be doing, but I want Length output to be in nm so I don't
> have to visually sort through lots of powers of ten.  In Maxima, I
> could simply say setunits(nm) and from that point on, until I told it
> differently, all my lengths would be converted and rendered in output
> as nanometers.  I would like similar ease of use in Axiom, if it is
> compatible with how Axiom works - I'd rather not have to open up the
> text editor, whip out a new MyUnits domain, and define things
> accordingly - I'd rather that all be hidden.

Actually, we can even do better, without the user doing a setUnitLength(nm), if
the only reason to use nm instead of m is to get rid of annoying powers of 10.
For numerical output (the problem does not arise for symbolic output), the
output coerce routine can sense the magnitude of the value in the unit and shift
the decimal place appropriately and adjusting using a suitable prefix. So one
stays in SI but the output gets rid of the powers of 10.

\start
Date: Tue, 23 Aug 2005 21:01:00 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package question - part 2

> There is no one-to-one conversion from rational expressions of 
> basic dimensions to physical quantities. When possible, the 
> physical name of the dimension should be retained (so moment 
> cannot be confused with work; this also reminds me that we 
> should separate scalar quantites from vector quantities).

So you're saying that dimension(23*J) should return an error, because
without context it's not clear what physical dimension is being
described?  I agree that if the knowledge exists in the definitions it
should be carried along, but without context, as in the above example,
what should be done?

I propose a convention - it is likely that any use Axiom's unit package
will see will be from the physics community, since that is the most
math heavy of the basic physical sciences.  I propose we create a
variable that can be set to select pre-defined behaviors for cases
where a physical unit corresponds to more than one dimension.  For the
PHYSICS convention, I suggest that the above command return a dimension
of Energy, with perhaps a cautionary that this mapping is not unique in
general.  This would correspond to what I would expect.  (Also, are
Energy and Work different physical dimensions?)  A mode STRICT might be
created where the above returns a description in terms of the seven
base dimensions, which will be correct without pinning the definition
specifically to one derived dimension.  What should be the default I
don't know.

> > If you're looking to determine dimensional equality, the best way I

> > know is to reduce everything to the seven base dimensions and 
> > simplify.  That might be a bit more CPU intensive than taking 
> > shortcuts in the case of complex expressions, but it is the most 
> > general way I know of and has the best chance of succeeding in
general.
>
> Agreed, but see above.
 
I think there could be again modes of operation - in this case fuzzy
(which goes ahead and assumes if MKS units are the same the derived
quantities can safely be considered the same) and strict, which will
raise flags and/or provide correct but less useful answers.  I
guarantee that making Axiom too strict in a correctness sense without
providing a way to get things done will lose it much of its audience in
the unit game, since physicists as a rule are not overly concerned with
mathematical rigor. (Compared to mathematicians, anyway ;-)  I think
allowing both strict mode and fuzzy mode is a good idea, which allows
for both full correctness if needed and a more practical working
environment if desired.  I invite comment on this, since I might have
just stomped Axiom philosophy into the carpet :-/.  At a fair number of
usage levels, people might not even know what Moment IS, much less
whether the dimension of the quantity found in the book is Work or not.
(The book itself might make an unstated assumption, which a student
would have no way to be aware of but an expert in the field would know.
 The student would want to make such assumptions initially, and only if
problems arose go back and check hidden assumptions.  (At least, that's
my guess ;-)

> The reason against separate domains for each physical quantity 
> (dimension in this sense) is not just because there are lots of 
> them, but because it would be difficult to spell out the 
> interrelationships and to create new ones. Yes, everything is a 
> one time effort, except when it comes to being used.

OK.  It seems like as long as actual unit transformations are
neglected, things are fairly easy to work with, so I don't think a
design decision change would pose too great a difficulty at the
symbolic level.

> I suppose if there is no consensus, then we would have to implement 
> with different designs. Axiom can support that with no problem.
 
But our limited developer manpower pool can't :-(.


> I don't know the difficulties about many domains either, since I 
> have not tried to implement them. I only have a hunch. It may turn 
> out that having  many domains (one for each dimensional quantity)
> is easier (to use and to implement). Neither do I have a clear 
> picture of what I proposed, but at this point, I like it better 
> (until convinced otherwise).

Fair enough :-).


In another post, CY wrote:

> > are Work and Moment in some sense the
> > same thing? If not, how can the difference be expressed?

> The two are different. Moment (in physics) is a measure of 
> tendency to produce motion especially about a point or axis 
> and is computed by the product of quantity (as a force) and 
> the distance to a particular axis or point.  Work is
> the transference of energy that is produced by the motion 
> of the point of application of a force and is measured by 
> multiplying the force and the displacement of its point of 
> application in the line of action. (Both  taken from
> Merriam-Webster On-line).

Hmm.  Well, the situations in which the labels are used are different,
but I'm not sure what is being described isn't the same thing on a
dimensional level.  But, I'll go ahead on it, since it could be Energy
and Work don't always interchange either...

> Yes, we CAN allow input like 3 meter + 5 feet, but the question is, 
> how is the system going to tell whether the user wants meter or feet 
> in the answer? In my scenario, the user would be forced to do
something 
> like
>
> (unitLength(3)$MKS(S) + unitLength(5)$FPS(S))::MKS(S)
>
>    3 + 5*ft2m [meter]

> which may not be that bad, because it forces the user to think 
> carefully and spell out explicitly the units used. (This certainly 
> would have prevented the crash on Mars).

Well, that sounds like a pretty good argument for at least having a
mode of operation like this :-).
 
> In the domain-preferred scenario, this would be:
>
>   (3 meter + 5 feet)::meter
>
> The disadvantage of the former is it is long-winded, but the user 
> does not have to know the actual units in the systems and there is 
> no new syntax to be learned. The disadvantage of the latter is that 
> the user needs to know the units, and the units takes up name space 
>(meter and feet would have to be reserved words) and either a new 
> syntax has to be constructed or the domains "meter", etc needs to 
> know about arithmetic.

Don't we WANT the units and dimensions to take namespace, at least at
user toplevel?  If the UNITS package were active, we certainly don't
want people using unit names for anything ELSE - it would cause waaay
too much confusion.  I would have viewed it as a design goal that (3
meter + 5 feet)::meter work as expected.

> It is certainly more intuitive, for simple units at least (can anyone
> name the unit for viscosity or thermal diffusivity offhand?) Given
the 
> number of unit systems and the number of physical quantities, I would

> opt for not having to know them except the system names, or just 
> MYUnitSystem.

I guess I would prefer to be able to either "use" the SI system, and
allow local overrides through simple syntax, or "set" the SI system,
and insist on everything being rendered using it.

\start
Date: Tue, 23 Aug 2005 21:34:00 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package question - Reply to 1st half

> It is easy to create functions to reset the units in any domain of
> UnitSystem category. We just have to do this by providing functions
> like:
> 
> setUnitLength(nm)  -- assuming we use SI abbreviations.
> 
> However, for the package to provide such generality would require
> not only updating an internal table (it will require one anyway, 
> of all the units corresponding to physical quantities (dimensions))
> but also that the output coercions figure out the factors before 
> output. This does complicate the output coercions because there can
> be many cases to deal with even if we restrict such user settings 
> to the seven basic dimensions. If a normal range of powers of 10
> is from -30 to 30 (which includes nanoscale to astronomical scales,
> and enlarge the range if you like), there would be about 20 cases 
> to check for each basic dimension (allowing one new prefix for 
> every third value of the exponent). On the other hand, a user 
> custom unit system need only modify simple code for the
> specific units. Generalities quickly expands the cases
> exponentially.

Correct - the Maxima active unit rulesets got quite large.  However,
that is also when they are most useful, at least too me.  I want the
computer doing all my grunt work for me, which includes spotting all
the obscure unit definitions and taking care of them.  Fundamentally,
the set of all units is large, and that's what I want Axiom able to
manage.  Whether or not this will require such exponential data sets is
not totally clear yet, but would not surprise me.

> The set functions will also have to do error checking (that is,
> verify that nm is indeed a unit of length, or at least among the
> units it knows).

Correct.  Maxima's checks first that it is a unit and then that that
unit is a length.

> Again, this would complicate the implementation of the domains for
> UnitSystem category. Would you allow, for example, in SI(S),
> setUnitLength(ft)? (I would vote a definite No).

I would vote yes, because I can't predict what I'll want to do with my
unit environment.

> Remember, a user can do such unit conversion by coercion if Axiom
> thinks that nanoscale is a common unit system and provides one. 
> We can also provide one for astronomical units. The idea is to allow 
> gradual growth to satisfy user needs, but the first implementations
> do not have to be all-encompassing. The design has to be.

Agreed.  I'm not shooting for immediately comprehensive, but for the
ability to be comprehensive in the future.  I can't imagine all the
ways and situations units can be applied, so I don't want to restrict
the user runtime environments that can be set up and customized.

> > > The user unit system can mix units if that is preferred.
> > 
> > So you're envisioning a separate level of logic which handles user
> > settings, and the underlying one organized as outlined below?
> 
> Yes, but that scenario is not encouraged (indeed discouraged), even
> though it can be done. 

But it should be doable, readily, IMHO.  That's what computers are for
- to handle the grunt work associated with such decisions.

> All I am saying is that even if an equation is dimensionally 
> correct, it could still be wrong (in terms of physics) because 
> of this non-unique mapping. We certainly cannot just use 
> dimensional analysis (reducing to basic dimensions) to
> discover that Work = Moment is wrong. 

No.  However, the ultimate burden in such cases will rest with the
scientist in question, and it may be that the dimensional correctness
of the equation is useful information to him/her.  Hence my suggestion
for two modes on dealing with such things.

> In my scheme, you do not assign a variable to its unit explicitly.
> You assign a dimension to the value (which has no unit attached
> explicitly, and only implicitly based on the domain the result of 
> unitXXX function). This frees the symbolic computation of units, 
> the way it is usually done in science.

Agreed.  My question is how dimension(<expr>) should react when <expr>
is not a set of variables, but an expression with units  (E.g. 10 J).
 
> I don't understand this question. There is NO unique way to
> decompose ANY rational expression in basic dimensions and return 
> it as a result of (rational expression) in physical derived 
> dimensions. Dimensional analysis is a one-way method: reduce 
> derived dimensions into its basic dimensions and match the
> exponents for each basic dimension. 

Right, if you are looking at the dimensional equality of two sides of
an expression.  There is also the case where you want to know what
quantity/dimension an expression is.

> Even a so-called "dimensionless" quantity can sometimes have
> "dimension":
> 
>   phase angle: unit radian, dimension m.m^(-1)
>   solid angle: unit steradian, dimension m^2. m^(-2)

I'm not sure what the useful thing to do there is.

> See: http://physics.nist.gov/cuu/Units/units.html
> 
> There is no hope to list all possibilities.  Another example taken
> from that page:
> 
>   absorbed dose (specific energy imparted), unit gray, dimension
> m^2.s^(-2). 
> 
> The dimension is actually meaningless. Expressed in terms of derived
> dimensions, 1 gray is 1 J/kg (makes perfect sense as energy/mass).
> But one can also say the dimension is that of velocity^2 in other
> context.

Right.  So conventions must be defined, preferable default ones as well
as specific ones for things like medical work.

> > In Maxima, I could simply say setunits(nm) and from that point 
> > on, until I told it differently, all my lengths would be 
> > converted and rendered in output as nanometers.  I would like
> > similar ease of use in Axiom, if it is compatible with how Axiom 
> > works - I'd rather not have to open up the text editor, whip out 
> > a new MyUnits domain, and define things accordingly - I'd rather 
> > that all be hidden.
>
> Yes, as explained earlier, we CAN provide such functionality. 
> I don't know how you implemented that in Maxima, but I think it 
> would be cumbersome if restrictions are not set.

Yes, I guess it is cumbersome to implement, but I was willing to pay
that price for the convenience.

> I really don't think a scientific worker would use slugs with 
> MKS. I would emphatically discourage you from doing that! Making
> it very easy for a user to "violate" a system of units is asking
> for trouble. Making it more difficult at least ensures the user 
> knows or thinks about what (s)he is doing. I don't implement
> generality for generality's sake. Life is too short.

That was just an example.  nanometers instead of meters, or light years
instead of meters, would be more realistic examples.

> Don't mix unit systems! Convert first before you start the 
> computations, and convert back if you really have to.

But that's just it - part of the reason for implementing a Unit system
in a CAS in the first place is to get it to do all the converting and
other annoyingly boring and error prone tasks for you - both for input
and output.

> So pi has unit degree/radian (even though that is dimensionless)
> when it is viewed as a unit conversion factor between radians and 
> degrees.

I'm confused - when does it hurt to trivially reduce or ignore this?

> Dimensionless is not always without dimension

That makes no sense to me at all - when is it useful to consider a
dimensionless quantity to have dimension?  Isn't that a logical
contradiction?  F AND ~F -> F

> One may do a certain amount of guessing or pattern matching, 
> but that is limited by one's current knowledge (limited, at best).
> The example I gave earlier, m^2.s^(-2), would you even have thought 
> of it as absorbed dose? (I certainly didn't before writing this 
> email). Given the vastness of scientific research, you need a 
> subject matter expert to increase the chance of meaningful 
> matching. The user is often the subject matter expert. Let him 
> or her deal with it.

OK, but I still think a) we can prepare useful "domains" such as
defaults for physics, and b) if such work is done by subject matter
experts we should be able to incorporate it since it would constitute a
useful tool for work in the subject in question.

Fascinating discussion!

\start
Date: Tue, 23 Aug 2005 21:38:34 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package question - Reply to 1st half
 
> Actually, we can even do better, without the user doing a
> setUnitLength(nm), if the only reason to use nm instead of 
> m is to get rid of annoying powers of 10. For numerical 
> output (the problem does not arise for symbolic output), the
> output coerce routine can sense the magnitude of the value in the
> unit and shift the decimal place appropriately and adjusting 
> using a suitable prefix. So one stays in SI but the output 
> gets rid of the powers of 10.

Are nanometer, etc. considered part of SI then?  Nifty idea, and one
worth following up on, but I would still like to peg things at nm, for
the following reason/scenario:  Let's say I know that my calculations
and data SHOULD be coming out in the nm range.  I set my unit for
length to be nm, proceed, and mostly see small numbers of nm.  All well
and good, until suddenly I have a huge or very small number appearing. 
Red flag!  Not close to 1 nm.  With autoscaling, the number would have
stayed near one and the unit would have changed.  Sometimes useful, I
agree, but I can see arguments for both sides here.

\start
Date: Wed, 24 Aug 2005 02:14:43 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [polymake] (nouveau) 

This is a trivial wrapper for the wonderful polymake package from
Berlin, http://www.math.tu-berlin.de/polymake/ .  Note that this is
rather a proof of concept, so if you think you've got a better design
idea, go ahead and comment below.  So far, only little of the polymake
functionality is covered, but it's mostly very easy to extend.

Usage

  You can find some simple examples in [SandBox polymake]. There, you
  can also try it out online!

Design

  I've decided to communicate with polymake for a start via file I/O,
  but would be easy to change this if necessary. Every polymake object
  created is stored with a "canonical" name: For example, if you ask
  for a cube of dimension 4, axiom will issue the shell command 'cube
  cube4.poly 4'. Then, when you ask for a property of this cube, for
  example, the hvector, then the shell command 'polymake cube4.poly
  H_VECTOR > tmp.poly' is issued. Finally axiom reads the contents of
  'tmp.poly' and converts it to the appropriate type. Thus, the only
  thing that really has to be programmed is a conversion routine for
  every polymake type. Some of these are trivial, like the Boolean,
  vector or matrix types, some others need more thought.


  Currently there are only two domains: 'Polytope' and
  'SimplicialComplex'. If you want a particular polymake property or
  construction supported, or want to have a new domain like 'Graph',
  go ahead and change the contents of this file. If you need help, you
  can always ask me.

\begin{axiom}
)abbrev domain POLYTOPE Polytope
Polytope(): Exports == Implementation where
    Exports == with

      coerce: % -> OutputForm

-------------------------------------------------------------------------------
--               polytope constructions                                      --
-------------------------------------------------------------------------------

      cube: Integer -> %

      cross: Integer -> %

      rand01: (Integer, Integer) -> %

      randSphere: (Integer, Integer) -> %

-------------------------------------------------------------------------------
--               polytope properties                                         --
-------------------------------------------------------------------------------

      fVector: % -> Vector Integer

      f2Vector: % -> Matrix Integer

      hVector: % -> Vector Integer

      facets: % -> Matrix Integer

      vertices: % -> Matrix Integer

      simple: % -> Boolean

    Implementation == add

      Rep := String

      coerce p == coerce(p)$Rep

      String2ListInteger: String -> List Integer
      
      String2ListInteger r ==
        map(PARSE_-INTEGER(#1)$Lisp, split(r, char(" "))$String)_
          $FiniteLinearAggregateFunctions2(String, List String, Integer, _
                                           List Integer)

      getBoolean: () -> Boolean

      getBoolean ==
        f := open(("tmp.poly")::FileName)$TextFile
        read!(f)$TextFile
        r:String := read!(f)$TextFile
        close!(f)$TextFile

        (r="1")

      getIntegerList: () -> List Integer

      getIntegerList ==
        f := open(("tmp.poly")::FileName)$TextFile
        read!(f)$TextFile
        r:String := read!(f)$TextFile
        close!(f)$TextFile

        String2ListInteger(r)

      getIntegerVector: () -> Vector Integer

      getIntegerVector == vector(getIntegerList())$Vector(Integer)

      getIntegerMatrix: () -> Matrix Integer

      getIntegerMatrix ==
        f := open(("tmp.poly")::FileName)$TextFile
        read!(f)$TextFile
        m: List List Integer := []
        r: String
        while not endOfFile?(f) repeat
          r := read!(f)$TextFile
          if not empty? r then 
            m := cons(String2ListInteger r, m)

        close!(f)$TextFile
        matrix(reverse m)$Matrix(Integer)

-------------------------------------------------------------------------------
--               polytope constructions                                      --
-------------------------------------------------------------------------------

      cube n == 
        s: String := "cube" string(n)
        systemCommand("system cube " s ".poly " string(n))$MoreSystemCommands
        s::Rep

      cross n == 
        s: String := "cross" string(n)
        systemCommand("system cross " s ".poly " string(n))$MoreSystemCommands
        s::Rep

      rand01(d, n)  == 
        s: String := "rand01" string(d) string(n) 
        systemCommand("system rand01 " s ".poly " string(d) " " string(n))$MoreSystemCommands
        s::Rep

      randSphere(d, n)  == 
        s: String := "randsphere" string(d) string(n)
        systemCommand("system rand__sphere " s ".poly " string(d) " " string(n))$MoreSystemCommands
        s::Rep

-------------------------------------------------------------------------------
--               polytope properties                                         --
-------------------------------------------------------------------------------

      fVector s ==
        systemCommand("system polymake " (s::Rep) ".poly F__VECTOR > tmp.poly")_
          $MoreSystemCommands
      
        getIntegerVector()

      f2Vector s ==
        systemCommand("system polymake " (s::Rep) ".poly F2__VECTOR > tmp.poly")_
          $MoreSystemCommands
      
        getIntegerMatrix()
        
      hVector s ==
        systemCommand("system polymake " (s::Rep) ".poly H__VECTOR > tmp.poly")_
          $MoreSystemCommands
        
        getIntegerVector()

      facets s ==
        systemCommand("system polymake " (s::Rep) ".poly FACETS > tmp.poly")_
          $MoreSystemCommands
        
        getIntegerMatrix()

      vertices s ==
        systemCommand("system polymake " (s::Rep) ".poly VERTICES > tmp.poly")_
          $MoreSystemCommands
        
        getIntegerMatrix()

      simple s == 
        systemCommand("system polymake " (s::Rep) ".poly SIMPLE > tmp.poly")_
          $MoreSystemCommands

        getBoolean()

)abbrev domain TOPAZ SimplicialComplex
SimplicialComplex(): Exports == Implementation where
    Exports == with

      coerce: % -> OutputForm

-------------------------------------------------------------------------------
--                  topaz constructions                                      --
-------------------------------------------------------------------------------

      boundaryComplex: Polytope -> %

-------------------------------------------------------------------------------
--                  topaz properties                                         --
-------------------------------------------------------------------------------

      facets: % -> List Set Integer

    Implementation == add

      Rep := String

      coerce p == coerce(p)$Rep


      String2SetInteger: String -> Set Integer
      
      String2SetInteger r ==
        s: String := delete(delete(r, #r), 1)
        brace(map(PARSE_-INTEGER(#1)$Lisp, split(s, char(" "))$String)_
          $FiniteLinearAggregateFunctions2(String, List String, Integer, _
                                           List Integer))$Set(Integer)


      getListSetInteger: () -> List Set Integer

      getListSetInteger ==
        f := open(("tmp.poly")::FileName)$TextFile
        read!(f)$TextFile
        m: List Set Integer := []
        r: String
        while not endOfFile?(f) repeat
          r := read!(f)$TextFile
          if not empty? r then 
            m := cons(String2SetInteger r, m)

        close!(f)$TextFile
        reverse m

-------------------------------------------------------------------------------
--                  topaz properties                                         --
-------------------------------------------------------------------------------

      facets s ==
        systemCommand("system polymake -A topaz " (s::Rep) ".top FACETS > tmp.poly")_
          $MoreSystemCommands
        
        getListSetInteger()

-------------------------------------------------------------------------------
--                  topaz constructions                                      --
-------------------------------------------------------------------------------

      boundaryComplex s ==
        systemCommand("system boundary__complex " (s pretend String) ".top " (s pretend String) ".poly")_
          $MoreSystemCommands

        s pretend String :: Rep
\end{axiom}

\start
Date: Wed, 24 Aug 2005 03:54:02 -0400
From: Bill Page
To: Peter Broadbery
Subject: re: aldor patches

Peter,

I would like to install your aldor patches on the MathAction
Website. My idea is to be able to include Aldor source files
on MathAtion something like this

  \begin{aldor}
  Aldor code
  \end{aldor}

SPAD code can already be compile on MathAction like this:

  \begin{axiom}
  ABBREV ...
  SPAD code
  \end{axiom}

I want to be able to call both SPAD and Aldor modules from Axiom
commands like this:

  \begin{axiom}
  Call to Aldor routines etc.
  \end{axiom}

To that end, I have updated the Axiom sources to tla archive
Patch-44 and also applied the patches to INTERP that you sent
to Tim earlier. As describedf in your email, I extracted
src_aldor.tgz to the axiom/src directory and then I ran 'make'.
The log file from the make is attached. It also shows the
versions of javac and aldor installed on the MathAction
(axiom-developer) server.

In the log file you will note that the make failes starting
at this point:

...
/home/page/repository/axiom--main--1/src/aldor/Make.rules:31:
/home/page/reposit
ory/axiom--main--1/src/aldor/Make.functions: No such file or directory
/home/page/repository/axiom--main--1/src/aldor/Make.rules:34:
/home/page/reposit
ory/axiom--main--1/src/aldor/Make.axiom: No such file or directory
/home/page/repository/axiom--main--1/src/aldor/Make.rules:35:
/home/page/reposit
ory/axiom--main--1/src/aldor/Make.aldor: No such file or directory
/home/page/repository/axiom--main--1/src/aldor/types.mk:41:
/home/page/repositor
y/axiom--main--1/int/aldor/all_spad_types.mk: No such file or directory

...

----------

Perhaps this failure has to do with the problems you mentioned
below. I have tried to run document manually on all of the
*.pamphlet files but I still find some missing. Perhaps there are
other problems?

I would be glad to help debug this some more and I look forward to
receiving an updated version of your files.

Thanks.

On Tuesday, August 23, 2005 4:38 AM you wrote:
> ...
> NB: As expected, I missed a bunch of files and certain ones need
> to have 'document' run on them explicitly - I'll try to prepare
> a makefile which explicitly does the document thing first;
> attrib.as.head.pamphlet contains a minor error in the
> \author line; & should be a comma or something.
>

Regards,
Bill Page.


------_=_NextPart_001_01C5A880.FF257BF6
	name="aldor.log"
	filename="aldor.log"

QWxkb3IgdmVyc2lvbiAxLjAuMiBmb3IgTElOVVgoZ2xpYmMyLjMpIAojMSAoV2FybmluZykgTm8g
ZmlsZXMhICBUeXBlIGBhbGRvciAtaGVscCcgZm9yIGhlbHAuCgpUb3RhbHM6CiBUaW1lICAgIDAu
MCBzCiBTdG9yZSAgIDU5MiBLIHBvb2wsIDIyOEsgYWxsb2MgLSAzOUsgZnJlZSAtIDE4SyBnYyA9
IDE3MksgZmluYWwKQnVpbGRpbmcgbGliYXhpb20uYWwgYW5kIGFzc29jaWF0ZWQgZmlsZXMKL2hv
bWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL2ludC9hbGRvcgptYWtlWzFdOiBFbnRl
cmluZyBkaXJlY3RvcnkgYC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMv
YWxkb3InCi9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFr
ZWZpbGU6NDQ6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3Iv
TWFrZS5ydWxlczogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQovaG9tZS9wYWdlL3JlcG9zaXRv
cnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2VmaWxlOjQ1OiAvaG9tZS9wYWdlL3JlcG9z
aXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL2xpYmF4aW9tLm1rOiBObyBzdWNoIGZpbGUg
b3IgZGlyZWN0b3J5Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxk
b3IvTWFrZWZpbGU6NDY6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMv
YWxkb3IvdHlwZXMubWs6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKL2hvbWUvcGFnZS9yZXBv
c2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlZmlsZTo0OTogL2hvbWUvcGFnZS9y
ZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1bGVzOiBObyBzdWNoIGZp
bGUgb3IgZGlyZWN0b3J5CigvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvbW50
L2xpbnV4L2Jpbi9kb2N1bWVudCkgKCkgKC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFp
bi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlcykKKGNkICQoZGlybmFtZSAvaG9tZS9wYWdlL3JlcG9z
aXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXMpOyAvaG9tZS9wYWdlL3Jl
cG9zaXRvcnkvYXhpb20tLW1haW4tLTEvbW50L2xpbnV4L2Jpbi9kb2N1bWVudCAgL2hvbWUvcGFn
ZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1bGVzKQpUaGlzIGlz
IHBkZmVUZVgsIFZlcnNpb24gMy4xNDE1OTItMS4yMWEtMi4yIChXZWIyQyA3LjUuNCkKZW50ZXJp
bmcgZXh0ZW5kZWQgbW9kZQooLi9NYWtlLnJ1bGVzLnRleApMYVRlWDJlIDwyMDAzLzEyLzAxPgpC
YWJlbCA8djMuOGQ+IGFuZCBoeXBoZW5hdGlvbiBwYXR0ZXJucyBmb3IgYW1lcmljYW4sIGZyZW5j
aCwgZ2VybWFuLCBuZ2VybWFuLCBiCmFoYXNhLCBiYXNxdWUsIGJ1bGdhcmlhbiwgY2F0YWxhbiwg
Y3JvYXRpYW4sIGN6ZWNoLCBkYW5pc2gsIGR1dGNoLCBlc3BlcmFudG8sIGUKc3RvbmlhbiwgZmlu
bmlzaCwgZ3JlZWssIGljZWxhbmRpYywgaXJpc2gsIGl0YWxpYW4sIGxhdGluLCBtYWd5YXIsIG5v
cnNrLCBwb2xpcwpoLCBwb3J0dWdlcywgcm9tYW5pYW4sIHJ1c3NpYW4sIHNlcmJpYW4sIHNsb3Zh
aywgc2xvdmVuZSwgc3BhbmlzaCwgc3dlZGlzaCwgdHVyCmtpc2gsIHVrcmFpbmlhbiwgbm9oeXBo
ZW5hdGlvbiwgbG9hZGVkLgooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9s
YXRleC9iYXNlL2FydGljbGUuY2xzCkRvY3VtZW50IENsYXNzOiBhcnRpY2xlIDIwMDQvMDIvMTYg
djEuNGYgU3RhbmRhcmQgTGFUZVggZG9jdW1lbnQgY2xhc3MKKC91c3IvbG9jYWwvdGVUZVgvc2hh
cmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9zaXplMTAuY2xvKSkKKC4uL3NjcmlwdHMvdGV4
L2F4aW9tLnN0eSkKTm8gZmlsZSBNYWtlLnJ1bGVzLmF1eC4KWzFdIFsyXSBbM10gWzRdIFs1XSBb
Nl0gWzddIFs4XSBbOV0gWzEwXSBbMTFdICguL01ha2UucnVsZXMuYXV4KSApCk91dHB1dCB3cml0
dGVuIG9uIE1ha2UucnVsZXMuZHZpICgxMSBwYWdlcywgMTY3NTIgYnl0ZXMpLgpUcmFuc2NyaXB0
IHdyaXR0ZW4gb24gTWFrZS5ydWxlcy5sb2cuClRoaXMgaXMgcGRmZVRlWCwgVmVyc2lvbiAzLjE0
MTU5Mi0xLjIxYS0yLjIgKFdlYjJDIDcuNS40KQplbnRlcmluZyBleHRlbmRlZCBtb2RlCiguL01h
a2UucnVsZXMudGV4CkxhVGVYMmUgPDIwMDMvMTIvMDE+CkJhYmVsIDx2My44ZD4gYW5kIGh5cGhl
bmF0aW9uIHBhdHRlcm5zIGZvciBhbWVyaWNhbiwgZnJlbmNoLCBnZXJtYW4sIG5nZXJtYW4sIGIK
YWhhc2EsIGJhc3F1ZSwgYnVsZ2FyaWFuLCBjYXRhbGFuLCBjcm9hdGlhbiwgY3plY2gsIGRhbmlz
aCwgZHV0Y2gsIGVzcGVyYW50bywgZQpzdG9uaWFuLCBmaW5uaXNoLCBncmVlaywgaWNlbGFuZGlj
LCBpcmlzaCwgaXRhbGlhbiwgbGF0aW4sIG1hZ3lhciwgbm9yc2ssIHBvbGlzCmgsIHBvcnR1Z2Vz
LCByb21hbmlhbiwgcnVzc2lhbiwgc2VyYmlhbiwgc2xvdmFrLCBzbG92ZW5lLCBzcGFuaXNoLCBz
d2VkaXNoLCB0dXIKa2lzaCwgdWtyYWluaWFuLCBub2h5cGhlbmF0aW9uLCBsb2FkZWQuCigvdXNy
L2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2UvYXJ0aWNsZS5jbHMK
RG9jdW1lbnQgQ2xhc3M6IGFydGljbGUgMjAwNC8wMi8xNiB2MS40ZiBTdGFuZGFyZCBMYVRlWCBk
b2N1bWVudCBjbGFzcwooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRl
eC9iYXNlL3NpemUxMC5jbG8pKQooLi4vc2NyaXB0cy90ZXgvYXhpb20uc3R5KSAoLi9NYWtlLnJ1
bGVzLmF1eCkgWzFdIFsyXSBbM10gWzRdIFs1XSBbNl0gWzddCls4XSBbOV0gWzEwXSBbMTFdICgu
L01ha2UucnVsZXMuYXV4KSApCk91dHB1dCB3cml0dGVuIG9uIE1ha2UucnVsZXMuZHZpICgxMSBw
YWdlcywgMTY3NTIgYnl0ZXMpLgpUcmFuc2NyaXB0IHdyaXR0ZW4gb24gTWFrZS5ydWxlcy5sb2cu
CigvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvbW50L2xpbnV4L2Jpbi9kb2N1
bWVudCkgKCkgKC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3Iv
dHlwZXMubWspCihjZCAkKGRpcm5hbWUgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWlu
LS0xL3NyYy9hbGRvci90eXBlcy5tayk7IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFp
bi0tMS9tbnQvbGludXgvYmluL2RvY3VtZW50ICAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20t
LW1haW4tLTEvc3JjL2FsZG9yL3R5cGVzLm1rKQpUaGlzIGlzIHBkZmVUZVgsIFZlcnNpb24gMy4x
NDE1OTItMS4yMWEtMi4yIChXZWIyQyA3LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQgbW9kZQooLi90
eXBlcy5tay50ZXgKTGFUZVgyZSA8MjAwMy8xMi8wMT4KQmFiZWwgPHYzLjhkPiBhbmQgaHlwaGVu
YXRpb24gcGF0dGVybnMgZm9yIGFtZXJpY2FuLCBmcmVuY2gsIGdlcm1hbiwgbmdlcm1hbiwgYgph
aGFzYSwgYmFzcXVlLCBidWxnYXJpYW4sIGNhdGFsYW4sIGNyb2F0aWFuLCBjemVjaCwgZGFuaXNo
LCBkdXRjaCwgZXNwZXJhbnRvLCBlCnN0b25pYW4sIGZpbm5pc2gsIGdyZWVrLCBpY2VsYW5kaWMs
IGlyaXNoLCBpdGFsaWFuLCBsYXRpbiwgbWFneWFyLCBub3JzaywgcG9saXMKaCwgcG9ydHVnZXMs
IHJvbWFuaWFuLCBydXNzaWFuLCBzZXJiaWFuLCBzbG92YWssIHNsb3ZlbmUsIHNwYW5pc2gsIHN3
ZWRpc2gsIHR1cgpraXNoLCB1a3JhaW5pYW4sIG5vaHlwaGVuYXRpb24sIGxvYWRlZC4KKC91c3Iv
bG9jYWwvdGVUZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9hcnRpY2xlLmNscwpE
b2N1bWVudCBDbGFzczogYXJ0aWNsZSAyMDA0LzAyLzE2IHYxLjRmIFN0YW5kYXJkIExhVGVYIGRv
Y3VtZW50IGNsYXNzCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4
L2Jhc2Uvc2l6ZTEwLmNsbykpCiguLi9zY3JpcHRzL3RleC9heGlvbS5zdHkpCk5vIGZpbGUgdHlw
ZXMubWsuYXV4LgpbMV0gWzJdIFszXQpPdmVyZnVsbCBcaGJveCAoMjAuOTk5ODJwdCB0b28gd2lk
ZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDE5MC0tMTkwCiBbXSAgICAgICAgIFxPVDEvY210dC9t
L24vMTAgamF2YSAtY3AgYHB3ZGAgU29ydCBiYXNlICQoTUlEKS9kZXBzL2F4ZXh0ZW5kLmRlcCAK
JChNSUQpL3R5cGVsaXN0ICQoTUlEKS9pbml0ZG9tYWlucyBcW10gIApbNF0KT3ZlcmZ1bGwgXGhi
b3ggKDEzMS4yNDg4NnB0IHRvbyB3aWRlKSBpbiBwYXJhZ3JhcGggYXQgbGluZXMgMjEyLS0yMTIK
IFtdICAgICAgICAgXE9UMS9jbXR0L20vbi8xMCBqYXZhIC1jcCBgcHdkYCBTb3J0IGNvbm5lY3Rl
ZCBzYXhpb20gJChmaWx0ZXItb3V0IAokKHNoZWxsIGNhdCAkKE1JRCkvc2F4MC9zcGFkc2V0Lmxz
dCksICQoQUxMX1NQQURfVFlQRVMpKSlbXSAgCls1XSAoLi90eXBlcy5tay5hdXgpICkKKHNlZSB0
aGUgdHJhbnNjcmlwdCBmaWxlIGZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uKQpPdXRwdXQgd3Jp
dHRlbiBvbiB0eXBlcy5tay5kdmkgKDUgcGFnZXMsIDk1MDAgYnl0ZXMpLgpUcmFuc2NyaXB0IHdy
aXR0ZW4gb24gdHlwZXMubWsubG9nLgpUaGlzIGlzIHBkZmVUZVgsIFZlcnNpb24gMy4xNDE1OTIt
MS4yMWEtMi4yIChXZWIyQyA3LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQgbW9kZQooLi90eXBlcy5t
ay50ZXgKTGFUZVgyZSA8MjAwMy8xMi8wMT4KQmFiZWwgPHYzLjhkPiBhbmQgaHlwaGVuYXRpb24g
cGF0dGVybnMgZm9yIGFtZXJpY2FuLCBmcmVuY2gsIGdlcm1hbiwgbmdlcm1hbiwgYgphaGFzYSwg
YmFzcXVlLCBidWxnYXJpYW4sIGNhdGFsYW4sIGNyb2F0aWFuLCBjemVjaCwgZGFuaXNoLCBkdXRj
aCwgZXNwZXJhbnRvLCBlCnN0b25pYW4sIGZpbm5pc2gsIGdyZWVrLCBpY2VsYW5kaWMsIGlyaXNo
LCBpdGFsaWFuLCBsYXRpbiwgbWFneWFyLCBub3JzaywgcG9saXMKaCwgcG9ydHVnZXMsIHJvbWFu
aWFuLCBydXNzaWFuLCBzZXJiaWFuLCBzbG92YWssIHNsb3ZlbmUsIHNwYW5pc2gsIHN3ZWRpc2gs
IHR1cgpraXNoLCB1a3JhaW5pYW4sIG5vaHlwaGVuYXRpb24sIGxvYWRlZC4KKC91c3IvbG9jYWwv
dGVUZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9hcnRpY2xlLmNscwpEb2N1bWVu
dCBDbGFzczogYXJ0aWNsZSAyMDA0LzAyLzE2IHYxLjRmIFN0YW5kYXJkIExhVGVYIGRvY3VtZW50
IGNsYXNzCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2Uv
c2l6ZTEwLmNsbykpCiguLi9zY3JpcHRzL3RleC9heGlvbS5zdHkpICguL3R5cGVzLm1rLmF1eCkg
WzFdIFsyXSBbM10KT3ZlcmZ1bGwgXGhib3ggKDIwLjk5OTgycHQgdG9vIHdpZGUpIGluIHBhcmFn
cmFwaCBhdCBsaW5lcyAxOTAtLTE5MAogW10gICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIGphdmEg
LWNwIGBwd2RgIFNvcnQgYmFzZSAkKE1JRCkvZGVwcy9heGV4dGVuZC5kZXAgCiQoTUlEKS90eXBl
bGlzdCAkKE1JRCkvaW5pdGRvbWFpbnMgXFtdICAKWzRdCk92ZXJmdWxsIFxoYm94ICgxMzEuMjQ4
ODZwdCB0b28gd2lkZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDIxMi0tMjEyCiBbXSAgICAgICAg
IFxPVDEvY210dC9tL24vMTAgamF2YSAtY3AgYHB3ZGAgU29ydCBjb25uZWN0ZWQgc2F4aW9tICQo
ZmlsdGVyLW91dCAKJChzaGVsbCBjYXQgJChNSUQpL3NheDAvc3BhZHNldC5sc3QpLCAkKEFMTF9T
UEFEX1RZUEVTKSkpW10gIApbNV0gKC4vdHlwZXMubWsuYXV4KSApCihzZWUgdGhlIHRyYW5zY3Jp
cHQgZmlsZSBmb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbikKT3V0cHV0IHdyaXR0ZW4gb24gdHlw
ZXMubWsuZHZpICg1IHBhZ2VzLCA5NTAwIGJ5dGVzKS4KVHJhbnNjcmlwdCB3cml0dGVuIG9uIHR5
cGVzLm1rLmxvZy4KKC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9tbnQvbGlu
dXgvYmluL2RvY3VtZW50KSAoKSAoL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0x
L3NyYy9hbGRvci9saWJheGlvbS5taykKKGNkICQoZGlybmFtZSAvaG9tZS9wYWdlL3JlcG9zaXRv
cnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL2xpYmF4aW9tLm1rKTsgL2hvbWUvcGFnZS9yZXBv
c2l0b3J5L2F4aW9tLS1tYWluLS0xL21udC9saW51eC9iaW4vZG9jdW1lbnQgIC9ob21lL3BhZ2Uv
cmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvbGliYXhpb20ubWspClRoaXMgaXMg
cGRmZVRlWCwgVmVyc2lvbiAzLjE0MTU5Mi0xLjIxYS0yLjIgKFdlYjJDIDcuNS40KQplbnRlcmlu
ZyBleHRlbmRlZCBtb2RlCiguL2xpYmF4aW9tLm1rLnRleApMYVRlWDJlIDwyMDAzLzEyLzAxPgpC
YWJlbCA8djMuOGQ+IGFuZCBoeXBoZW5hdGlvbiBwYXR0ZXJucyBmb3IgYW1lcmljYW4sIGZyZW5j
aCwgZ2VybWFuLCBuZ2VybWFuLCBiCmFoYXNhLCBiYXNxdWUsIGJ1bGdhcmlhbiwgY2F0YWxhbiwg
Y3JvYXRpYW4sIGN6ZWNoLCBkYW5pc2gsIGR1dGNoLCBlc3BlcmFudG8sIGUKc3RvbmlhbiwgZmlu
bmlzaCwgZ3JlZWssIGljZWxhbmRpYywgaXJpc2gsIGl0YWxpYW4sIGxhdGluLCBtYWd5YXIsIG5v
cnNrLCBwb2xpcwpoLCBwb3J0dWdlcywgcm9tYW5pYW4sIHJ1c3NpYW4sIHNlcmJpYW4sIHNsb3Zh
aywgc2xvdmVuZSwgc3BhbmlzaCwgc3dlZGlzaCwgdHVyCmtpc2gsIHVrcmFpbmlhbiwgbm9oeXBo
ZW5hdGlvbiwgbG9hZGVkLgooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9s
YXRleC9iYXNlL2FydGljbGUuY2xzCkRvY3VtZW50IENsYXNzOiBhcnRpY2xlIDIwMDQvMDIvMTYg
djEuNGYgU3RhbmRhcmQgTGFUZVggZG9jdW1lbnQgY2xhc3MKKC91c3IvbG9jYWwvdGVUZVgvc2hh
cmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9zaXplMTAuY2xvKSkKKC4uL3NjcmlwdHMvdGV4
L2F4aW9tLnN0eSkKTm8gZmlsZSBsaWJheGlvbS5tay5hdXguClsxXQpObyBmaWxlIGxpYmF4aW9t
Lm1rLnRvYy4KWzJdIFszXSBbNF0gWzVdIFs2XSAoLi9saWJheGlvbS5tay5hdXgpICkKT3V0cHV0
IHdyaXR0ZW4gb24gbGliYXhpb20ubWsuZHZpICg2IHBhZ2VzLCA1MjkyIGJ5dGVzKS4KVHJhbnNj
cmlwdCB3cml0dGVuIG9uIGxpYmF4aW9tLm1rLmxvZy4KVGhpcyBpcyBwZGZlVGVYLCBWZXJzaW9u
IDMuMTQxNTkyLTEuMjFhLTIuMiAoV2ViMkMgNy41LjQpCmVudGVyaW5nIGV4dGVuZGVkIG1vZGUK
KC4vbGliYXhpb20ubWsudGV4CkxhVGVYMmUgPDIwMDMvMTIvMDE+CkJhYmVsIDx2My44ZD4gYW5k
IGh5cGhlbmF0aW9uIHBhdHRlcm5zIGZvciBhbWVyaWNhbiwgZnJlbmNoLCBnZXJtYW4sIG5nZXJt
YW4sIGIKYWhhc2EsIGJhc3F1ZSwgYnVsZ2FyaWFuLCBjYXRhbGFuLCBjcm9hdGlhbiwgY3plY2gs
IGRhbmlzaCwgZHV0Y2gsIGVzcGVyYW50bywgZQpzdG9uaWFuLCBmaW5uaXNoLCBncmVlaywgaWNl
bGFuZGljLCBpcmlzaCwgaXRhbGlhbiwgbGF0aW4sIG1hZ3lhciwgbm9yc2ssIHBvbGlzCmgsIHBv
cnR1Z2VzLCByb21hbmlhbiwgcnVzc2lhbiwgc2VyYmlhbiwgc2xvdmFrLCBzbG92ZW5lLCBzcGFu
aXNoLCBzd2VkaXNoLCB0dXIKa2lzaCwgdWtyYWluaWFuLCBub2h5cGhlbmF0aW9uLCBsb2FkZWQu
CigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2UvYXJ0aWNs
ZS5jbHMKRG9jdW1lbnQgQ2xhc3M6IGFydGljbGUgMjAwNC8wMi8xNiB2MS40ZiBTdGFuZGFyZCBM
YVRlWCBkb2N1bWVudCBjbGFzcwooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3Rl
eC9sYXRleC9iYXNlL3NpemUxMC5jbG8pKQooLi4vc2NyaXB0cy90ZXgvYXhpb20uc3R5KSAoLi9s
aWJheGlvbS5tay5hdXgpIFsxXSAoLi9saWJheGlvbS5tay50b2MpIFsyXQpbM10gWzRdIFs1XSBb
Nl0gKC4vbGliYXhpb20ubWsuYXV4KSApCk91dHB1dCB3cml0dGVuIG9uIGxpYmF4aW9tLm1rLmR2
aSAoNiBwYWdlcywgNTI5MiBieXRlcykuClRyYW5zY3JpcHQgd3JpdHRlbiBvbiBsaWJheGlvbS5t
ay5sb2cuCm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvaG9tZS9wYWdlL3JlcG9zaXRvcnkv
YXhpb20tLW1haW4tLTEvc3JjL2FsZG9yJwptYWtlWzFdOiBFbnRlcmluZyBkaXJlY3RvcnkgYC9o
b21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3InCi9ob21lL3BhZ2Uv
cmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlczozMTogL2hvbWUv
cGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLmZ1bmN0aW9uczog
Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1h
aW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXM6MzQ6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlv
bS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5heGlvbTogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9y
eQovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UucnVs
ZXM6MzU6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFr
ZS5hbGRvcjogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQovaG9tZS9wYWdlL3JlcG9zaXRvcnkv
YXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL3R5cGVzLm1rOjQxOiAvaG9tZS9wYWdlL3JlcG9zaXRv
cnkvYXhpb20tLW1haW4tLTEvaW50L2FsZG9yL2FsbF9zcGFkX3R5cGVzLm1rOiBObyBzdWNoIGZp
bGUgb3IgZGlyZWN0b3J5Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMv
YWxkb3IvdHlwZXMubWs6NDI6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9p
bnQvYWxkb3IvYWxsX3NwYWRfY2F0cy5tazogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQovaG9t
ZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL3R5cGVzLm1rOjE0ODog
L2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL2ludC9hbGRvci9zYXhpb20vc3Bh
ZHNldC5tayAKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9N
YWtlLnJ1bGVzOjE3OTogQUxMIFNQQURTRVRTICBzYXgwIHNheGlvbQovaG9tZS9wYWdlL3JlcG9z
aXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXM6MjAwOiAoMCwwKQovaG9t
ZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXM6MjA0
OiAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvaW50L2FsZG9yL3NheDAvc3Bh
ZHNldC5tazogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQovaG9tZS9wYWdlL3JlcG9zaXRvcnkv
YXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXM6MjAwOiAoMSwxKQovaG9tZS9wYWdl
L3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXM6MjA0OiAvaG9t
ZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvaW50L2FsZG9yL3NheGlvbS9zcGFkc2V0
Lm1rOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlv
bS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlczoyNzE6IG5vIGZpbGUgbmFtZSBmb3IgYC1p
bmNsdWRlJwovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01h
a2UucnVsZXM6MjcxOiBubyBmaWxlIG5hbWUgZm9yIGAtaW5jbHVkZScKL2hvbWUvcGFnZS9yZXBv
c2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1bGVzOjEwNjogVzogMSBJOiAx
Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxl
czoxMDc6IFc6ICAgICAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvaW50L2Fs
ZG9yL3NheDAvc3BhZHNldC5tawovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEv
c3JjL2FsZG9yL01ha2UucnVsZXM6NDIzOiAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1h
aW4tLTEvc3JjL2FsZG9yL01ha2UuYXhpb206IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKL2hv
bWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1bGVzOjQy
NTogL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLmFs
ZG9yOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5CigvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhp
b20tLW1haW4tLTEvbW50L2xpbnV4L2Jpbi9kb2N1bWVudCkgKCkgKC9ob21lL3BhZ2UvcmVwb3Np
dG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5hbGRvcikKKGNkICQoZGlybmFtZSAv
aG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UuYWxkb3Ip
OyAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvbW50L2xpbnV4L2Jpbi9kb2N1
bWVudCAgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtl
LmFsZG9yKQpUaGlzIGlzIHBkZmVUZVgsIFZlcnNpb24gMy4xNDE1OTItMS4yMWEtMi4yIChXZWIy
QyA3LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQgbW9kZQooLi9NYWtlLmFsZG9yLnRleApMYVRlWDJl
IDwyMDAzLzEyLzAxPgpCYWJlbCA8djMuOGQ+IGFuZCBoeXBoZW5hdGlvbiBwYXR0ZXJucyBmb3Ig
YW1lcmljYW4sIGZyZW5jaCwgZ2VybWFuLCBuZ2VybWFuLCBiCmFoYXNhLCBiYXNxdWUsIGJ1bGdh
cmlhbiwgY2F0YWxhbiwgY3JvYXRpYW4sIGN6ZWNoLCBkYW5pc2gsIGR1dGNoLCBlc3BlcmFudG8s
IGUKc3RvbmlhbiwgZmlubmlzaCwgZ3JlZWssIGljZWxhbmRpYywgaXJpc2gsIGl0YWxpYW4sIGxh
dGluLCBtYWd5YXIsIG5vcnNrLCBwb2xpcwpoLCBwb3J0dWdlcywgcm9tYW5pYW4sIHJ1c3NpYW4s
IHNlcmJpYW4sIHNsb3Zhaywgc2xvdmVuZSwgc3BhbmlzaCwgc3dlZGlzaCwgdHVyCmtpc2gsIHVr
cmFpbmlhbiwgbm9oeXBoZW5hdGlvbiwgbG9hZGVkLgooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90
ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNlL2FydGljbGUuY2xzCkRvY3VtZW50IENsYXNzOiBhcnRp
Y2xlIDIwMDQvMDIvMTYgdjEuNGYgU3RhbmRhcmQgTGFUZVggZG9jdW1lbnQgY2xhc3MKKC91c3Iv
bG9jYWwvdGVUZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9zaXplMTAuY2xvKSkK
KC4uL3NjcmlwdHMvdGV4L2F4aW9tLnN0eSkKTm8gZmlsZSBNYWtlLmFsZG9yLmF1eC4KWzFdCk92
ZXJmdWxsIFxoYm94ICgxMC40OTk5MXB0IHRvbyB3aWRlKSBpbiBwYXJhZ3JhcGggYXQgbGluZXMg
NjctLTY3CiBbXSAgICAgICAgICAgICAgICBcT1QxL2NtdHQvbS9uLzEwICQocGF0c3Vic3QgJChN
SUQpL3RtcC9saWIkKGFvX2xpYnJhcnlfbmFtZSkKXyUubHN0LCAlLCAkKGZpbHRlciAlLmxzdCwg
JF4pKTsgXFtdICAKWzJdIFszXSBbNF0gKC4vTWFrZS5hbGRvci5hdXgpICkKKHNlZSB0aGUgdHJh
bnNjcmlwdCBmaWxlIGZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uKQpPdXRwdXQgd3JpdHRlbiBv
biBNYWtlLmFsZG9yLmR2aSAoNCBwYWdlcywgNTUzNiBieXRlcykuClRyYW5zY3JpcHQgd3JpdHRl
biBvbiBNYWtlLmFsZG9yLmxvZy4KVGhpcyBpcyBwZGZlVGVYLCBWZXJzaW9uIDMuMTQxNTkyLTEu
MjFhLTIuMiAoV2ViMkMgNy41LjQpCmVudGVyaW5nIGV4dGVuZGVkIG1vZGUKKC4vTWFrZS5hbGRv
ci50ZXgKTGFUZVgyZSA8MjAwMy8xMi8wMT4KQmFiZWwgPHYzLjhkPiBhbmQgaHlwaGVuYXRpb24g
cGF0dGVybnMgZm9yIGFtZXJpY2FuLCBmcmVuY2gsIGdlcm1hbiwgbmdlcm1hbiwgYgphaGFzYSwg
YmFzcXVlLCBidWxnYXJpYW4sIGNhdGFsYW4sIGNyb2F0aWFuLCBjemVjaCwgZGFuaXNoLCBkdXRj
aCwgZXNwZXJhbnRvLCBlCnN0b25pYW4sIGZpbm5pc2gsIGdyZWVrLCBpY2VsYW5kaWMsIGlyaXNo
LCBpdGFsaWFuLCBsYXRpbiwgbWFneWFyLCBub3JzaywgcG9saXMKaCwgcG9ydHVnZXMsIHJvbWFu
aWFuLCBydXNzaWFuLCBzZXJiaWFuLCBzbG92YWssIHNsb3ZlbmUsIHNwYW5pc2gsIHN3ZWRpc2gs
IHR1cgpraXNoLCB1a3JhaW5pYW4sIG5vaHlwaGVuYXRpb24sIGxvYWRlZC4KKC91c3IvbG9jYWwv
dGVUZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9hcnRpY2xlLmNscwpEb2N1bWVu
dCBDbGFzczogYXJ0aWNsZSAyMDA0LzAyLzE2IHYxLjRmIFN0YW5kYXJkIExhVGVYIGRvY3VtZW50
IGNsYXNzCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2Uv
c2l6ZTEwLmNsbykpCiguLi9zY3JpcHRzL3RleC9heGlvbS5zdHkpICguL01ha2UuYWxkb3IuYXV4
KSBbMV0KT3ZlcmZ1bGwgXGhib3ggKDEwLjQ5OTkxcHQgdG9vIHdpZGUpIGluIHBhcmFncmFwaCBh
dCBsaW5lcyA2Ny0tNjcKIFtdICAgICAgICAgICAgICAgIFxPVDEvY210dC9tL24vMTAgJChwYXRz
dWJzdCAkKE1JRCkvdG1wL2xpYiQoYW9fbGlicmFyeV9uYW1lKQpfJS5sc3QsICUsICQoZmlsdGVy
ICUubHN0LCAkXikpOyBcW10gIApbMl0gWzNdIFs0XSAoLi9NYWtlLmFsZG9yLmF1eCkgKQooc2Vl
IHRoZSB0cmFuc2NyaXB0IGZpbGUgZm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24pCk91dHB1dCB3
cml0dGVuIG9uIE1ha2UuYWxkb3IuZHZpICg0IHBhZ2VzLCA1NTM2IGJ5dGVzKS4KVHJhbnNjcmlw
dCB3cml0dGVuIG9uIE1ha2UuYWxkb3IubG9nLgooL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9t
LS1tYWluLS0xL21udC9saW51eC9iaW4vZG9jdW1lbnQpICgpICgvaG9tZS9wYWdlL3JlcG9zaXRv
cnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UuYXhpb20pCihjZCAkKGRpcm5hbWUgL2hv
bWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLmF4aW9tKTsg
L2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL21udC9saW51eC9iaW4vZG9jdW1l
bnQgIC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5h
eGlvbSkKVGhpcyBpcyBwZGZlVGVYLCBWZXJzaW9uIDMuMTQxNTkyLTEuMjFhLTIuMiAoV2ViMkMg
Ny41LjQpCmVudGVyaW5nIGV4dGVuZGVkIG1vZGUKKC4vTWFrZS5heGlvbS50ZXgKTGFUZVgyZSA8
MjAwMy8xMi8wMT4KQmFiZWwgPHYzLjhkPiBhbmQgaHlwaGVuYXRpb24gcGF0dGVybnMgZm9yIGFt
ZXJpY2FuLCBmcmVuY2gsIGdlcm1hbiwgbmdlcm1hbiwgYgphaGFzYSwgYmFzcXVlLCBidWxnYXJp
YW4sIGNhdGFsYW4sIGNyb2F0aWFuLCBjemVjaCwgZGFuaXNoLCBkdXRjaCwgZXNwZXJhbnRvLCBl
CnN0b25pYW4sIGZpbm5pc2gsIGdyZWVrLCBpY2VsYW5kaWMsIGlyaXNoLCBpdGFsaWFuLCBsYXRp
biwgbWFneWFyLCBub3JzaywgcG9saXMKaCwgcG9ydHVnZXMsIHJvbWFuaWFuLCBydXNzaWFuLCBz
ZXJiaWFuLCBzbG92YWssIHNsb3ZlbmUsIHNwYW5pc2gsIHN3ZWRpc2gsIHR1cgpraXNoLCB1a3Jh
aW5pYW4sIG5vaHlwaGVuYXRpb24sIGxvYWRlZC4KKC91c3IvbG9jYWwvdGVUZVgvc2hhcmUvdGV4
bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9hcnRpY2xlLmNscwpEb2N1bWVudCBDbGFzczogYXJ0aWNs
ZSAyMDA0LzAyLzE2IHYxLjRmIFN0YW5kYXJkIExhVGVYIGRvY3VtZW50IGNsYXNzCigvdXNyL2xv
Y2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2Uvc2l6ZTEwLmNsbykpCigu
Li9zY3JpcHRzL3RleC9heGlvbS5zdHkpCk5vIGZpbGUgTWFrZS5heGlvbS5hdXguClsxXQpPdmVy
ZnVsbCBcaGJveCAoMTA0Ljk5OTA4cHQgdG9vIHdpZGUpIGluIHBhcmFncmFwaCBhdCBsaW5lcyA4
NC0tODQKIFtdICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIEBlY2hvICIoc2V0cSBjb21wb25lbnRz
IChxdW90ZSAoJChjYWxsIG5vLWluaXRzLCQoUwpQQURTRVRfSVRFTV8kKEMpXyQqKSkpKSApIiA+
PiAkKE1JRCkvdG1wL21rYXhfJCoubHNwW10gIAoKT3ZlcmZ1bGwgXGhib3ggKDYyLjk5OTQ1cHQg
dG9vIHdpZGUpIGluIHBhcmFncmFwaCBhdCBsaW5lcyA4NS0tODUKIFtdICAgICAgICBcT1QxL2Nt
dHQvbS9uLzEwIEBlY2hvICIoc2V0cSBpbml0cyAocXVvdGUgKCQoY2FsbCBpbml0cywkKFNQQURT
RVRfSQpURU1fJChDKV8kKikpKSkgKSIgPj4gJChNSUQpL3RtcC9ta2F4XyQqLmxzcFtdICAKCk92
ZXJmdWxsIFxoYm94ICgxODMuNzQ4NHB0IHRvbyB3aWRlKSBpbiBwYXJhZ3JhcGggYXQgbGluZXMg
ODctLTg3CiBbXSAgICAgICAgXE9UMS9jbXR0L20vbi8xMCBAKGNkICQoTUlEKTsgREFBU0U9IiQo
REFBU0UpIjsgZXhwb3J0IERBQVNFOyAkKElOVEUKUlBTWVMpOyB0cnVlKSA8ICQoTUlEKS90bXAv
bWtheF8kKi5sc3AgPiAkKE1JRCkvdG1wL2dlbl8kKi5sb2cgMj4mMVtdICAKWzJdCk92ZXJmdWxs
IFxoYm94ICg0ODguMjQ1NzRwdCB0b28gd2lkZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDEwMS0t
MTAxCiBbXSAgICAgICAgXE9UMS9jbXR0L20vbi8xMCBAZWNobyAnKHByb2duIChsb2FkICIkKE9C
SikvJChTWVMpL2ludGVycC9mb2FtX2wubyIKKSAoY29tcGlsZS1maWxlICIkKGZpbHRlciAlLmxz
cCwkXikiIDpvdXRwdXQtZmlsZSAiJEAiKSAoJHtCWUV9KSknIHwgJHtERVBTWVN9IAo+ICQoT0JK
KS8kKFNZUykvYWxkb3IvYnVpbGQvJChub3RkaXIgJEApLmxvZyA7W10gIAoKT3ZlcmZ1bGwgXGhi
b3ggKDE0Ni45OTg3MnB0IHRvbyB3aWRlKSBpbiBwYXJhZ3JhcGggYXQgbGluZXMgMTAyLS0xMDIK
IFtdICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIEBpZiB0ZXN0IC1mICRAOyB0aGVuIGVjaG8gIkJ1
aWx0ICQobm90ZGlyICRAKSIgOyBlbApzZSBjYXQgJChPQkopLyQoU1lTKS9hbGRvci9idWlsZC8k
KG5vdGRpciAkQCkubG9nOyBmYWxzZTsgZmlbXSAgClszXSAoLi9NYWtlLmF4aW9tLmF1eCkgKQoo
c2VlIHRoZSB0cmFuc2NyaXB0IGZpbGUgZm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24pCk91dHB1
dCB3cml0dGVuIG9uIE1ha2UuYXhpb20uZHZpICgzIHBhZ2VzLCA0NzI0IGJ5dGVzKS4KVHJhbnNj
cmlwdCB3cml0dGVuIG9uIE1ha2UuYXhpb20ubG9nLgpUaGlzIGlzIHBkZmVUZVgsIFZlcnNpb24g
My4xNDE1OTItMS4yMWEtMi4yIChXZWIyQyA3LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQgbW9kZQoo
Li9NYWtlLmF4aW9tLnRleApMYVRlWDJlIDwyMDAzLzEyLzAxPgpCYWJlbCA8djMuOGQ+IGFuZCBo
eXBoZW5hdGlvbiBwYXR0ZXJucyBmb3IgYW1lcmljYW4sIGZyZW5jaCwgZ2VybWFuLCBuZ2VybWFu
LCBiCmFoYXNhLCBiYXNxdWUsIGJ1bGdhcmlhbiwgY2F0YWxhbiwgY3JvYXRpYW4sIGN6ZWNoLCBk
YW5pc2gsIGR1dGNoLCBlc3BlcmFudG8sIGUKc3RvbmlhbiwgZmlubmlzaCwgZ3JlZWssIGljZWxh
bmRpYywgaXJpc2gsIGl0YWxpYW4sIGxhdGluLCBtYWd5YXIsIG5vcnNrLCBwb2xpcwpoLCBwb3J0
dWdlcywgcm9tYW5pYW4sIHJ1c3NpYW4sIHNlcmJpYW4sIHNsb3Zhaywgc2xvdmVuZSwgc3Bhbmlz
aCwgc3dlZGlzaCwgdHVyCmtpc2gsIHVrcmFpbmlhbiwgbm9oeXBoZW5hdGlvbiwgbG9hZGVkLgoo
L3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNlL2FydGljbGUu
Y2xzCkRvY3VtZW50IENsYXNzOiBhcnRpY2xlIDIwMDQvMDIvMTYgdjEuNGYgU3RhbmRhcmQgTGFU
ZVggZG9jdW1lbnQgY2xhc3MKKC91c3IvbG9jYWwvdGVUZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgv
bGF0ZXgvYmFzZS9zaXplMTAuY2xvKSkKKC4uL3NjcmlwdHMvdGV4L2F4aW9tLnN0eSkgKC4vTWFr
ZS5heGlvbS5hdXgpIFsxXQpPdmVyZnVsbCBcaGJveCAoMTA0Ljk5OTA4cHQgdG9vIHdpZGUpIGlu
IHBhcmFncmFwaCBhdCBsaW5lcyA4NC0tODQKIFtdICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIEBl
Y2hvICIoc2V0cSBjb21wb25lbnRzIChxdW90ZSAoJChjYWxsIG5vLWluaXRzLCQoUwpQQURTRVRf
SVRFTV8kKEMpXyQqKSkpKSApIiA+PiAkKE1JRCkvdG1wL21rYXhfJCoubHNwW10gIAoKT3ZlcmZ1
bGwgXGhib3ggKDYyLjk5OTQ1cHQgdG9vIHdpZGUpIGluIHBhcmFncmFwaCBhdCBsaW5lcyA4NS0t
ODUKIFtdICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIEBlY2hvICIoc2V0cSBpbml0cyAocXVvdGUg
KCQoY2FsbCBpbml0cywkKFNQQURTRVRfSQpURU1fJChDKV8kKikpKSkgKSIgPj4gJChNSUQpL3Rt
cC9ta2F4XyQqLmxzcFtdICAKCk92ZXJmdWxsIFxoYm94ICgxODMuNzQ4NHB0IHRvbyB3aWRlKSBp
biBwYXJhZ3JhcGggYXQgbGluZXMgODctLTg3CiBbXSAgICAgICAgXE9UMS9jbXR0L20vbi8xMCBA
KGNkICQoTUlEKTsgREFBU0U9IiQoREFBU0UpIjsgZXhwb3J0IERBQVNFOyAkKElOVEUKUlBTWVMp
OyB0cnVlKSA8ICQoTUlEKS90bXAvbWtheF8kKi5sc3AgPiAkKE1JRCkvdG1wL2dlbl8kKi5sb2cg
Mj4mMVtdICAKWzJdCk92ZXJmdWxsIFxoYm94ICg0ODguMjQ1NzRwdCB0b28gd2lkZSkgaW4gcGFy
YWdyYXBoIGF0IGxpbmVzIDEwMS0tMTAxCiBbXSAgICAgICAgXE9UMS9jbXR0L20vbi8xMCBAZWNo
byAnKHByb2duIChsb2FkICIkKE9CSikvJChTWVMpL2ludGVycC9mb2FtX2wubyIKKSAoY29tcGls
ZS1maWxlICIkKGZpbHRlciAlLmxzcCwkXikiIDpvdXRwdXQtZmlsZSAiJEAiKSAoJHtCWUV9KSkn
IHwgJHtERVBTWVN9IAo+ICQoT0JKKS8kKFNZUykvYWxkb3IvYnVpbGQvJChub3RkaXIgJEApLmxv
ZyA7W10gIAoKT3ZlcmZ1bGwgXGhib3ggKDE0Ni45OTg3MnB0IHRvbyB3aWRlKSBpbiBwYXJhZ3Jh
cGggYXQgbGluZXMgMTAyLS0xMDIKIFtdICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIEBpZiB0ZXN0
IC1mICRAOyB0aGVuIGVjaG8gIkJ1aWx0ICQobm90ZGlyICRAKSIgOyBlbApzZSBjYXQgJChPQkop
LyQoU1lTKS9hbGRvci9idWlsZC8kKG5vdGRpciAkQCkubG9nOyBmYWxzZTsgZmlbXSAgClszXSAo
Li9NYWtlLmF4aW9tLmF1eCkgKQooc2VlIHRoZSB0cmFuc2NyaXB0IGZpbGUgZm9yIGFkZGl0aW9u
YWwgaW5mb3JtYXRpb24pCk91dHB1dCB3cml0dGVuIG9uIE1ha2UuYXhpb20uZHZpICgzIHBhZ2Vz
LCA0NzI0IGJ5dGVzKS4KVHJhbnNjcmlwdCB3cml0dGVuIG9uIE1ha2UuYXhpb20ubG9nLgooL2hv
bWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL21udC9saW51eC9iaW4vZG9jdW1lbnQp
ICgpICgvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL1NvcnQu
amF2YSkKKGNkICQoZGlybmFtZSAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEv
c3JjL2FsZG9yL1NvcnQuamF2YSk7IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0t
MS9tbnQvbGludXgvYmluL2RvY3VtZW50ICAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1h
aW4tLTEvc3JjL2FsZG9yL1NvcnQuamF2YSkKVGhpcyBpcyBwZGZlVGVYLCBWZXJzaW9uIDMuMTQx
NTkyLTEuMjFhLTIuMiAoV2ViMkMgNy41LjQpCmVudGVyaW5nIGV4dGVuZGVkIG1vZGUKKC4vU29y
dC5qYXZhLnRleApMYVRlWDJlIDwyMDAzLzEyLzAxPgpCYWJlbCA8djMuOGQ+IGFuZCBoeXBoZW5h
dGlvbiBwYXR0ZXJucyBmb3IgYW1lcmljYW4sIGZyZW5jaCwgZ2VybWFuLCBuZ2VybWFuLCBiCmFo
YXNhLCBiYXNxdWUsIGJ1bGdhcmlhbiwgY2F0YWxhbiwgY3JvYXRpYW4sIGN6ZWNoLCBkYW5pc2gs
IGR1dGNoLCBlc3BlcmFudG8sIGUKc3RvbmlhbiwgZmlubmlzaCwgZ3JlZWssIGljZWxhbmRpYywg
aXJpc2gsIGl0YWxpYW4sIGxhdGluLCBtYWd5YXIsIG5vcnNrLCBwb2xpcwpoLCBwb3J0dWdlcywg
cm9tYW5pYW4sIHJ1c3NpYW4sIHNlcmJpYW4sIHNsb3Zhaywgc2xvdmVuZSwgc3BhbmlzaCwgc3dl
ZGlzaCwgdHVyCmtpc2gsIHVrcmFpbmlhbiwgbm9oeXBoZW5hdGlvbiwgbG9hZGVkLgooL3Vzci9s
b2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNlL2FydGljbGUuY2xzCkRv
Y3VtZW50IENsYXNzOiBhcnRpY2xlIDIwMDQvMDIvMTYgdjEuNGYgU3RhbmRhcmQgTGFUZVggZG9j
dW1lbnQgY2xhc3MKKC91c3IvbG9jYWwvdGVUZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgv
YmFzZS9zaXplMTAuY2xvKSkKKC4uL3NjcmlwdHMvdGV4L2F4aW9tLnN0eSkKTm8gZmlsZSBTb3J0
LmphdmEuYXV4LgpbMV0gWzJdIFszXSBbNF0gWzVdIFs2XSBbN10gWzhdIFs5XSBbMTBdIFsxMV0g
WzEyXSBbMTNdIFsxNF0gWzE1XSBbMTZdCk92ZXJmdWxsIFxoYm94ICg1LjI0OTk1cHQgdG9vIHdp
ZGUpIGluIHBhcmFncmFwaCBhdCBsaW5lcyA3NDAtLTc0MAogW10gICAgICAgICAgICAgICAgXE9U
MS9jbXR0L20vbi8xMCBvdXQucHJpbnRsbigiU1BBRFNFVF9JVEVNXyIgKyBkbmFtZSArICJfIiAr
CiBub2RlU2V0LmdldE5hbWUoKSArICIgOj0gXHRcXCIpO1tdICAKCk92ZXJmdWxsIFxoYm94ICg1
LjI0OTk1cHQgdG9vIHdpZGUpIGluIHBhcmFncmFwaCBhdCBsaW5lcyA3NTItLTc1MgogW10gICAg
ICAgICAgICAgICAgXE9UMS9jbXR0L20vbi8xMCBvdXQucHJpbnRsbigiU1BBRFNFVF9ERVBTXyIg
KyBkbmFtZSArICJfIiArCiBub2RlU2V0LmdldE5hbWUoKSArICIgOj0gXHRcXCIpO1tdICAKWzE3
XSBbMThdIFsxOV0gKC4vU29ydC5qYXZhLmF1eCkgKQooc2VlIHRoZSB0cmFuc2NyaXB0IGZpbGUg
Zm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24pCk91dHB1dCB3cml0dGVuIG9uIFNvcnQuamF2YS5k
dmkgKDE5IHBhZ2VzLCAyNTUyMCBieXRlcykuClRyYW5zY3JpcHQgd3JpdHRlbiBvbiBTb3J0Lmph
dmEubG9nLgpUaGlzIGlzIHBkZmVUZVgsIFZlcnNpb24gMy4xNDE1OTItMS4yMWEtMi4yIChXZWIy
QyA3LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQgbW9kZQooLi9Tb3J0LmphdmEudGV4CkxhVGVYMmUg
PDIwMDMvMTIvMDE+CkJhYmVsIDx2My44ZD4gYW5kIGh5cGhlbmF0aW9uIHBhdHRlcm5zIGZvciBh
bWVyaWNhbiwgZnJlbmNoLCBnZXJtYW4sIG5nZXJtYW4sIGIKYWhhc2EsIGJhc3F1ZSwgYnVsZ2Fy
aWFuLCBjYXRhbGFuLCBjcm9hdGlhbiwgY3plY2gsIGRhbmlzaCwgZHV0Y2gsIGVzcGVyYW50bywg
ZQpzdG9uaWFuLCBmaW5uaXNoLCBncmVlaywgaWNlbGFuZGljLCBpcmlzaCwgaXRhbGlhbiwgbGF0
aW4sIG1hZ3lhciwgbm9yc2ssIHBvbGlzCmgsIHBvcnR1Z2VzLCByb21hbmlhbiwgcnVzc2lhbiwg
c2VyYmlhbiwgc2xvdmFrLCBzbG92ZW5lLCBzcGFuaXNoLCBzd2VkaXNoLCB0dXIKa2lzaCwgdWty
YWluaWFuLCBub2h5cGhlbmF0aW9uLCBsb2FkZWQuCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3Rl
eG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2UvYXJ0aWNsZS5jbHMKRG9jdW1lbnQgQ2xhc3M6IGFydGlj
bGUgMjAwNC8wMi8xNiB2MS40ZiBTdGFuZGFyZCBMYVRlWCBkb2N1bWVudCBjbGFzcwooL3Vzci9s
b2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNlL3NpemUxMC5jbG8pKQoo
Li4vc2NyaXB0cy90ZXgvYXhpb20uc3R5KSAoLi9Tb3J0LmphdmEuYXV4KSBbMV0gWzJdIFszXSBb
NF0gWzVdIFs2XSBbN10KWzhdIFs5XSBbMTBdIFsxMV0gWzEyXSBbMTNdIFsxNF0gWzE1XSBbMTZd
Ck92ZXJmdWxsIFxoYm94ICg1LjI0OTk1cHQgdG9vIHdpZGUpIGluIHBhcmFncmFwaCBhdCBsaW5l
cyA3NDAtLTc0MAogW10gICAgICAgICAgICAgICAgXE9UMS9jbXR0L20vbi8xMCBvdXQucHJpbnRs
bigiU1BBRFNFVF9JVEVNXyIgKyBkbmFtZSArICJfIiArCiBub2RlU2V0LmdldE5hbWUoKSArICIg
Oj0gXHRcXCIpO1tdICAKCk92ZXJmdWxsIFxoYm94ICg1LjI0OTk1cHQgdG9vIHdpZGUpIGluIHBh
cmFncmFwaCBhdCBsaW5lcyA3NTItLTc1MgogW10gICAgICAgICAgICAgICAgXE9UMS9jbXR0L20v
bi8xMCBvdXQucHJpbnRsbigiU1BBRFNFVF9ERVBTXyIgKyBkbmFtZSArICJfIiArCiBub2RlU2V0
LmdldE5hbWUoKSArICIgOj0gXHRcXCIpO1tdICAKWzE3XSBbMThdIFsxOV0gKC4vU29ydC5qYXZh
LmF1eCkgKQooc2VlIHRoZSB0cmFuc2NyaXB0IGZpbGUgZm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRp
b24pCk91dHB1dCB3cml0dGVuIG9uIFNvcnQuamF2YS5kdmkgKDE5IHBhZ2VzLCAyNTUyMCBieXRl
cykuClRyYW5zY3JpcHQgd3JpdHRlbiBvbiBTb3J0LmphdmEubG9nLgooamF2YWMgLWQgL2hvbWUv
cGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL2ludC9hbGRvciAvaG9tZS9wYWdlL3JlcG9z
aXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL1NvcnQuamF2YSkKTm90ZTogL2hvbWUvcGFn
ZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9Tb3J0LmphdmEgdXNlcyB1bmNo
ZWNrZWQgb3IgdW5zYWZlIG9wZXJhdGlvbnMuCk5vdGU6IFJlY29tcGlsZSB3aXRoIC1YbGludDp1
bmNoZWNrZWQgZm9yIGRldGFpbHMuCm1ha2VbMV06ICoqKiBObyBydWxlIHRvIG1ha2UgdGFyZ2V0
IGAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL2dlbi1heGlv
bS10eXBlcy5zaCcsIG5lZWRlZCBieSBgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWlu
LS0xL2ludC9hbGRvci90eXBlbGlzdCcuICBTdG9wLgptYWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9y
eSBgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvcicKbWFrZTog
KioqIFthbGxdIEVycm9yIDIK

\start
Date: Wed, 24 Aug 2005 03:37:04 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [polymake] 

Let's try it out:

\begin{axiom}
c4:=cube 4
hVector c4
\end{axiom}

\start
Date: Wed, 24 Aug 2005 04:41:23 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [polymake] 

        f := open(("/tmp/tmp.poly")::FileName)$TextFile
        f := open(("/tmp/tmp.poly")::FileName)$TextFile
        f := open(("/tmp/tmp.poly")::FileName)$TextFile
        systemCommand("system /usr/local/polymake/bin/cube " s ".poly " string(n))$MoreSystemCommands
        systemCommand("system /usr/local/polymake/bin/cross " s ".poly " string(n))$MoreSystemCommands
        systemCommand("system /usr/local/polymake/bin/rand01 " s ".poly " string(d) " " string(n))$MoreSystemCommands
        systemCommand("system /usr/local/polymake/bin/rand__sphere " s ".poly " string(d) " " string(n))$MoreSystemCommands
        systemCommand("system /usr/local/polymake/bin/polymake " (s::Rep) ".poly F__VECTOR > /tmp/tmp.poly")_
        systemCommand("system /usr/local/polymake/bin/polymake " (s::Rep) ".poly F2__VECTOR > /tmp/tmp.poly")_
        systemCommand("system /usr/local/polymake/bin/polymake " (s::Rep) ".poly H__VECTOR > /tmp/tmp.poly")_
        systemCommand("system /usr/local/polymake/bin/polymake " (s::Rep) ".poly FACETS > /tmp/tmp.poly")_
        systemCommand("system /usr/local/polymake/bin/polymake " (s::Rep) ".poly VERTICES > /tmp/tmp.poly")_
        systemCommand("system /usr/local/polymake/bin/polymake " (s::Rep) ".poly SIMPLE > /tmp/tmp.poly")_
        f := open(("/tmp/tmp.poly")::FileName)$TextFile
        systemCommand("system /usr/local/polymake/bin/polymake -A topaz " (s::Rep) ".top FACETS > /tmp/tmp.poly")_
        systemCommand("system /usr/local/polymake/bin/boundary__complex " (s pretend String) ".top " (s pretend String) ".poly")_

\start
Date: Wed, 24 Aug 2005 12:22:41 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Polymake needs permission to write a file

Page, Bill writes:
 > Martin,
 > 
 > On Wednesday, August 24, 2005 5:34 AM you wrote:
 > > 
 > > As you might have seen, for some unknow reason everything works just
 > > fine now.
 > 
 > I changed  "system cube ..." to "system /usr/local/polymake/cube ..."
 > etc.

Ah!

 > > Hopefully in future there will be a better way to communicate with
 > > polymake. As it is, it is also rather slow...
 > 
 > From the polymake documentation it seems like it might be possible
 > to use a socket instead::
 > 
 > polymake SOCKET_FILE
 > polymake HOSTNAME:PORT
 > 
 > If the only argument is a named unix-domain socket (ls -l marks such files
 > with a little s) or an internet address, polymake connects to it and reads
 > the lines with perl expressions. The output goes back to the socket.

Yes, but I have no idea how to use sockets from an axiom domain. Do you? If so,
go ahead and show me a simple example. I can then adapt the domain.

 > I hope that the polymake developers find your approach Interesting.

Yes, I hope so too.

 > BTW, I think there may be a problem with one of the constructors:
 > 
 > $ /usr/local/polymake/bin/rand_sphere randsp.poly 2 3
 > Illegal instruction
 > $

Hm, on my machine here it works just fine... Except that I need to parametrize
the domain, to allow for polytopes with vertices being floats or rational
numbers.

I grepped my polymake directory for "Illegal instruction" but got no
match. Where does this come from?

\start
Date: Wed, 24 Aug 2005 14:48:30 +0200
From: Martin Rubey
To: list
Subject: Axiom Design Question / Polymake feedback

Dear all,

I got already nice feedback from Michael Joswig, one of the heads of
polymake. He said he liked the idea, but they are probably going for
Singular. A very clever choice indeed -- I didn't think of that one. It
probably would make sense to look at Singulars functionality and see how it
compares with axioms.

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

Apart from that I have the following design problem:

I have a domain which contains polytopes. 

)abbrev domain POLYTOPE Polytope
Polytope(): Exports == Implementation where
    Exports == with

-------------------------------------------------------------------------------
--               polytope constructions                                      --
-------------------------------------------------------------------------------

      cube: Integer -> %

      randSphere: (Integer, Integer) -> %

-------------------------------------------------------------------------------
--               polytope properties                                         --
-------------------------------------------------------------------------------

      hvector: % -> List Integer

      vertices: % -> Matrix ???

Now the problem is as follows: the type of the elements of the matrix depends
on the polytope. For some polytopes, they are Integers, for others rationals or
floats, or both.

Now one solution is simply to parametrize the domain:

)abbrev domain POLYTOPE Polytope
Polytope(R: Ring): Exports == Implementation where
    Exports == with

-------------------------------------------------------------------------------
--               polytope constructions                                      --
-------------------------------------------------------------------------------

      cube: Integer -> %

      if R is Float then randSphere: (Integer, Integer) -> %

      vertices: % -> Matrix R

However, I'm not convinced that this is the best solution. One reason being,
that I don't really want that the user has to specify the type of his polytope
all the time.

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

So here is the second idea:

have a package 

)abbrev domain POLYCON PolytopeConstructions
PolytopeConstructions(): Exports == Implementation where
    Exports == with

      cube: Integer -> Polytope Integer

      randSphere: (Integer, Integer) -> Polytope Float

and a parametrized domain as above. I'm not sure whether this is sensible,
either

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

Third idea:

Make all vertices have coordinates of type Fraction Integer. If they happen to
be integers, they can be converted afterwards anyway. It is highly unlikely
that there will be anything around that does not have rational vertices.

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

So what do you think?

\start
Date: Wed, 24 Aug 2005 09:29:17 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Polymake needs permission to write a file

Martin,

On Wednesday, August 24, 2005 6:23 AM you wrote:

> I wrote:
> >
> > polymake SOCKET_FILE
> > polymake HOSTNAME:PORT
> >
>
> Yes, but I have no idea how to use sockets from an axiom domain.
> Do you? If so, go ahead and show me a simple example. I can then
> adapt the domain.

Use of sockets requires compilation of Axiom with the newest
version of GCL (2.6.7). At the present time the lisp functions
for access to sockets is not exposed to the user but doing this
would not be difficult. But in short it can not be done yet
without some lisp programming. I am planning to re-build Axiom
very soon with gcl-2.6.7 and Peter Broadbery's work on Aldor.
When that is done that I will be able to give you an example
of sockets in Axiom.

>
> > BTW, I think there may be a problem with one of the constructors:
> >
> > $ /usr/local/polymake/bin/rand_sphere randsp.poly 2 3
> > Illegal instruction
> > $
>
> Hm, on my machine here it works just fine... Except that I need to
> parametrize the domain, to allow for polytopes with vertices being
> floats or rational numbers.

I don't understand what you mean by "parameterize the domain". This
does not involve Axiom as such although it is called by one of your
"spad wrappers". This is just a direct call to one of the standard
polymake constructors (ref: the polymake user guide):

rand_sphere <file> <dimension> <n> [ -precision <digits> ] [ -seed <s> ]

Produce a d-dimensional polytope with n random vertices on the unit
sphere. Floating-point coordinates are used. Uniform distribution.
The default precision is set to 6 digits.

-------

On your computer if you type:

rand_sphere randsp.poly 2 3

what are the contents of the randsp.poly file?

>
> I grepped my polymake directory for "Illegal instruction" but got
> no match. Where does this come from?
>

This is an error message from the linux operating system indicating
that the program tried to execute an illegal machine instruction (i.e.
an instruction that was not allowed by the CPU in the particular state
that it was in). This one of several different kinds of program aborts
and is usually caused by a programming error or perhaps a compiler
error.
This problem might be solved if we could just re-compile the programs
from source code.

\start
Date: Wed, 24 Aug 2005 16:00:13 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Polymake needs permission to write a file

Hi Bill,

lot of traffic today, eh?

Page, Bill writes:

 > When that is done that I will be able to give you an example
 > of sockets in Axiom.

OK.

 > > > BTW, I think there may be a problem with one of the constructors:
 > > >
 > > > $ /usr/local/polymake/bin/rand_sphere randsp.poly 2 3
 > > > Illegal instruction
 > > > $
 > > 
 > > Hm, on my machine here it works just fine... Except that I need to
 > > parametrize the domain, to allow for polytopes with vertices being
 > > floats or rational numbers.
 > 
 > I don't understand what you mean by "parameterize the domain". 

The polymake domain currently has

     vertices: % -> Matrix Integer

This cannot work, since the vertices are not always integers. See my other
post.


 > On your computer if you type:
 > 
 > rand_sphere randsp.poly 2 3
 > 
 > what are the contents of the randsp.poly file?

depends on the seed, obviously...

_application polytope
_version 2.1.0
_type RationalPolytope

AMBIENT_DIM
2

POINTS
1 -0.063018 -0.998012
1 0.840255 0.542191
1 -0.96204 -0.272908

BOUNDED
1


 > > I grepped my polymake directory for "Illegal instruction" but got no
 > > match. Where does this come from?
 > > 
 > 
 > This is an error message from the linux operating system indicating that the
 > program tried to execute an illegal machine instruction (i.e.  an
 > instruction that was not allowed by the CPU in the particular state that it
 > was in). This one of several different kinds of program aborts and is
 > usually caused by a programming error or perhaps a compiler error.

might it be that you got the wrong RPM? 

 > This problem might be solved if we could just re-compile the programs from
 > source code.

Yes. but the developers themselves say that this is at least very time
consuming, if you don't have enough memory on your machine. Well, I guess you
have...

\start
Date: Wed, 24 Aug 2005 10:29:03 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Axiom Design Question / Polymake feedback

Martin,

On Wednesday, August 24, 2005 8:49 AM you wrote:
> ...
> Now the problem is as follows: the type of the elements of the
> matrix depends on the polytope. For some polytopes, they are
> Integers, for others rationals or floats, or both.

Ideally, I think you might want to return something like:

vertices: % -> Matrix Union (Integer, Float, Fraction Integer)

but unfortunately Axiom does not understand that domain
Union (Integer, Float, Fraction Integer) is actually a RING so
you are not allowed to call it a Matrix.

Instead you might use, for example:

vertices: % -> List List Union (Integer, Float, Fraction Integer)

or maybe

vertices: % -> TwoDimensionalArray Union (Integer, Float, Fraction
Integer)

but note that for some reason

(11) -> x: TwoDimensionalArray Union (Integer, Float, Fraction Integer)
:=new(2,2,0)

   (1)  [0,0,0,0]
          Type: TwoDimensionalArray Union(Integer,Float,Fraction
Integer)

does not print properly (as an rectangular array).

I think there are two possible bug reports here:

1) Union ( list of alternatives that are coercible to some ring )
   should be a RING

2) display of TwoDimensionalArray of type Union(...) is not properly
   formatted

Do you agree?

\start
Date: Wed, 24 Aug 2005 11:04:05 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Polymake needs permission to write a file

Martin,

On Wednesday, August 24, 2005 10:00 AM you wrote:
>
> lot of traffic today, eh?
>

Yah, we're making up for lost time. :)

> I wrote:
>  >
>  > I don't understand what you mean by "parameterize the domain".
>
> The polymake domain currently has
>
>      vertices: % -> Matrix Integer
>
> This cannot work, since the vertices are not always integers.
> See my other post.

Yes, I understand. But this is a separate problem. The problem
that I mention below is a program abort in a polymake constructor.

>
>
>  > On your computer if you type:
>  >
>  > rand_sphere randsp.poly 2 3
>  >
>  > what are the contents of the randsp.poly file?
>
> depends on the seed, obviously...
>
> _application polytope
> _version 2.1.0
> _type RationalPolytope
>
> AMBIENT_DIM
> 2
>
> POINTS
> 1 -0.063018 -0.998012
> 1 0.840255 0.542191

On the axiom-developer server the result is just "Illegal instruction".

> ...
> might it be that you got the wrong RPM?
>

I don't think so. The developers only provide one rpm file for linux
systems.

> > This problem might be solved if we could just re-compile the
> > programs from source code.
>
> Yes. but the developers themselves say that this is at least very
> time consuming, if you don't have enough memory on your machine.
> Well, I guess you have...

We are talking about Axiom here, remember. It is nothing for us if the
build of Axiom talks all day long! So what if building polymake takes
a couple of hours?

Anyway as far as I can tell, there are some errors in the polymake
source code. I would be glad to discuss this with the developers.

\start
Date: Wed, 24 Aug 2005 11:03:10 -0400
From: William Sit
To: Bill Page
Subject: Re: Axiom Design Question / Polymake feedback

I am jumping in here, so excuse me if comments are out of context.

"Page, Bill" wrote:
> 
> I think there are two possible bug reports here:
> 
> 1) Union ( list of alternatives that are coercible to some ring )
>    should be a RING

No! In your case, where the arguments of the union form an ascending chain of
rings, that would be true. In general, you cannot do arithmetic with operands
from different rings. Think about Union(INT, MATRIX INT).

The best one can do in Martin's case would be, as you noted,

   Union(MATRIX INT, MATRIX FRAC INT, MATRIX FLOAT)

To use List List Union(INT, FRAC INT, FLOAT) would require one to do case
statements in every entry of the matrix and also lose the ring properties of
matrices.
 
> 2) display of TwoDimensionalArray of type Union(...) is not properly
>    formatted

Seems like a bug.

\start
Date: Wed, 24 Aug 2005 17:01:10 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Axiom Design Question / Polymake feedback

Page, Bill writes:
 > I think there are two possible bug reports here:
 > 
 > 1) Union ( list of alternatives that are coercible to some ring )
 >    should be a RING

No.

For example:

U := Union(MPOLY([x,y],INT), PF 5); x: U := 2*x; y: U := 3;

x+y does not make much sense. And asking the system to see whether there is a
common supertype is asking for quite a lot and is probably error prone.

 > 2) display of TwoDimensionalArray of type Union(...) is not properly
 >    formatted

Yes.

\start
Date: Wed, 24 Aug 2005 11:14:25 -0400
From: Bill Page
To: William Sit
Subject: RE: Axiom Design Question / Polymake feedback

William,

On Wednesday, August 24, 2005 11:03 AM William Sitt wrote:
> "Page, Bill" wrote:
> >
> > I think there are two possible bug reports here:
> >
> > 1) Union ( list of alternatives that are coercible to some ring )
> >    should be a RING
>
> No! In your case, where the arguments of the union form an ascending
> chain of rings, that would be true. In general, you cannot do
arithmetic
> with operands from different rings. Think about Union(INT, MATRIX
INT).

You are right. I was wrong. I didn't stop to think about it long enough.
Thanks.

>
> The best one can do in Martin's case would be, as you noted,
>
>    Union(MATRIX INT, MATRIX FRAC INT, MATRIX FLOAT)
>

Yes, that seems workable to me.

\start
Date: Wed, 24 Aug 2005 10:17:59 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#200 display of TwoDimensionalArray of type Union(...) is not properly formatted] (new) 

For example:
\begin{axiom}
n:TwoDimensionalArray Union ( Integer, Float):=new(2,2,0)
\end{axiom}

should display a rectangular array of numbers.

\start
Date: Wed, 24 Aug 2005 17:21:00 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Polymake needs permission to write a file

Page, Bill writes:

 > I don't think so. The developers only provide one rpm file for linux
 > systems.

No: Quoting http://www.math.tu-berlin.de/polymake/download_choice.html

Binary packages for RedHat, SuSE, and other Linux distributions with RPM-based
software management

End user package
 polymake-2.1.0-2.athlon.rpm 10046242 20:32 Jan 21 2005

polymake-2.1.0-2.i586.rpm 8716518 19:53 Jan 21 2005

polymake-2.1.0-2.i686.rpm 9995110 21:11 Jan 21 2005

Developer package 
polymake-devel-2.1.0-2.athlon.rpm 878609 20:32 Jan 21 2005

polymake-devel-2.1.0-2.i586.rpm 934404 19:53 Jan 21 2005

polymake-devel-2.1.0-2.i686.rpm 877174 21:11 Jan 21 2005


These packages were compiled under SuSE 9.0. They should fit the recent
versions of other Linux distributions too.

In older distributions the RPM installation might fail complaining about
unresolved dependences on GLIBC or something similar. In this unfortunate case
you will have to take the source RPM and recompile it: rpm --rebuild
polymake-*.src.rpm or rpmbuild --rebuild polymake-*.src.rpm .

Packages are compiled for various CPU models. The i586 variant is a generic
Pentium architecture used in SuSE by default, i586 is optimized for Pentium 4,
and athlon for AMD Athlon XP. Be sure to pick the package most suitable to your
hardware.

\start
Date: Wed, 24 Aug 2005 11:55:52 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Polymake needs permission to write a file

On Wednesday, August 24, 2005 11:38 AM I wrote:
> ...
> I will download and install the i586 version and see if that corrects
> the problem.
>

Ok. That did correct the problem. The rand_sphere command no longer
aborts and now produces the following output (for example):

[root@axiom-developer page]# /usr/local/polymake/bin/rand_sphere
randsp.poly 2 3
[root@axiom-developer page]# cat randsp.poly
_application polytope
_version 2.1.0
_type RationalPolytope

AMBIENT_DIM
2

POINTS
1 -0.962592 -0.270955
1 0.899836 -0.436229
1 -0.853837 0.52054

BOUNDED
1

[root@axiom-developer page]#

------

So it's over to you to solve the result data type problem.

\start
Date: Wed, 24 Aug 2005 11:38:04 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Polymake needs permission to write a file

Martin,

On Wednesday, August 24, 2005 11:21 AM you wrote:
>
> Page, Bill writes:
>
>  > I don't think so. The developers only provide one rpm file for
linux
>  > systems.
>
> No: Quoting http://www.math.tu-berlin.de/polymake/download_choice.html
>
> Binary packages for RedHat, SuSE, and other Linux distributions with
> RPM-based software management
>
> End user package
> polymake-2.1.0-2.athlon.rpm 10046242 20:32 Jan 21 2005
>
> polymake-2.1.0-2.i586.rpm 8716518 19:53 Jan 21 2005
>
> polymake-2.1.0-2.i686.rpm 9995110 21:11 Jan 21 2005
>
> Developer package
> polymake-devel-2.1.0-2.athlon.rpm 878609 20:32 Jan 21 2005
>
> polymake-devel-2.1.0-2.i586.rpm 934404 19:53 Jan 21 2005
>
> polymake-devel-2.1.0-2.i686.rpm 877174 21:11 Jan 21 2005
>

Yes, for different *hardware* but not different versions of linux.

I installed the end user package for the Intel 686 machine:

[page@axiom-developer page]$ ls -l -d poly*.rpm
-rw-rw-r--  1 page  page  9995110 Jan 21  2005 polymake-2.1.0-2.i686.rpm

[page@axiom-developer page]$ 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
[page@axiom-developer page]$

--------

But this is a shared *virtual* server so although this is a i686 machine
maybe we do not get to use the whole i686 instruction set?

Did you install the i586 version?

I will download and install the i586 version and see if that corrects
the problem.

\start
Date: Wed, 24 Aug 2005 12:21:01 -0400
From: Bill Page
To: Kai Kaminski
Subject: AxiomUI graphics (was: [Zaheda Bhorat] SOC Project Articles for Doctor Dobbs Journal)
Cc: Bob McElrath

Kai,

On Wednesday, August 24, 2005 2:02 AM I wrote:
>
> > ...
> > 3. Change the high-level drawing code, so that instead of calling
> >    the low-level drawing code it just prints the list lists of
> >    points, which are to be connected by lines, to standard output
> >    with markers to ease extraction. This might still break existing
> >    code.
> >
> > The approach I'm taking now is essentially #3 with the difference
> > that I copied algebra/draw.spad.pamphlet to uidraw.spad.pamphlet
> > and modified that. It actually seems to work. Right now I'm
> > integrating this with the gui, so that on startup uidraw.spad gets
> > loaded.
>
> Excellent. That is exactly the right way to proceed.
>

It occurs to me to ask if you are already familiar with the following
Axiom commands:

vp1:=draw(sin(x), x=%pi/10..%pi)
g1:=getGraph(vp1,1)
pointLists(g1)
...
g2:=makeGraphImage(lineSegments, lineColors, pointColors, lineSize)
pointLists(g2)

See for example

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

Perhaps uidraw is producing output similar to this?

\start
Date: Wed, 24 Aug 2005 19:08:28 +0200
From: Kai Kaminski
To: Bill Page
Subject: Re: AxiomUI graphics
Cc: Bob McElrath


Bill Page writes:
> On Wednesday, August 24, 2005 2:02 AM I wrote:
>> 
>> > ...
>> > 3. Change the high-level drawing code, so that instead of calling
>> >    the low-level drawing code it just prints the list lists of
>> >    points, which are to be connected by lines, to standard output
>> >    with markers to ease extraction. This might still break existing
>> >    code.
>> >
>> > The approach I'm taking now is essentially #3 with the difference
>> > that I copied algebra/draw.spad.pamphlet to uidraw.spad.pamphlet
>> > and modified that. It actually seems to work. Right now I'm
>> > integrating this with the gui, so that on startup uidraw.spad gets
>> > loaded.
>> 
>> Excellent. That is exactly the right way to proceed.
>>
>
> It occurs to me to ask if you are already familiar with the following
> Axiom commands:
>
> vp1:=draw(sin(x), x=%pi/10..%pi)
> g1:=getGraph(vp1,1)
> pointLists(g1)
> ...
> g2:=makeGraphImage(lineSegments, lineColors, pointColors, lineSize)
> pointLists(g2)
I know these commands and I actually had working code using this
approach. The problem with this is that it messes up the history.

Luckily uidraw.spad is just draw.spad with a few lines added. It's
fairly trivial, really.

\start
Date: Wed, 24 Aug 2005 13:50:44 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package question - part 2

C Y wrote:

> So you're saying that dimension(23*J) should return an error, because
> without context it's not clear what physical dimension is being
> described?  I agree that if the knowledge exists in the definitions it
> should be carried along, but without context, as in the above example,
> what should be done?

Let's be clear. You are requesting a reverse dimensional analysis in essence.
Given a rational expression in the dimensions (basic or derived), you want to
give as meaningful as possible an interpretation (or list of interpretations)
that is relevant to the expert user. 

>From you statement:

   dimension(23*J)

you are assuming that J is a reserved variable in Axiom, or at least
recognizable by the system just like %pi.  I think using up name space with
short names like "J" for Joule, etc is going to be very problematic with the
interpreter. My proposal puts these only as output strings, and does not allow
their direct manipulations as variables. To input 23 J, one would have to do:

   x := unitEnergy(23)$SI(INT)

assuming Joule = Newton-meter is the default energy unit in SI. Under this
setting, one can create a function

   dimension: % -> Dimension

where for example, dimension(x) would return 
  
      "Energy"

(the unit may or may not be given, depending on design; and I think if unit is
what is intended, then we should have:

   unit: % -> OutputForm

and 

   unit(x)

       "J"

or in basic units:

       "N-m"

(adopting notation from SI).  Since I view units I/O as only decorations, they
are all strings and not to be manipulated by arithmetic (but string operations
are allowed of course). All this works in the current proposed scheme.

Now the reverse dimension analysis (RDA) is a totally different problem. The
input to RDA is the outputform of a physical quantity (symbolic or numeric),
perhaps inputted as a string (as I discussed, I object strongly to using up user
namespace). Assuming the string uses SI convention, we can write a parser based
on the grammar defined, first to reduce every additive term to basic units in
the seven basic dimensions, verify that they are all the same, then
re-interpreting the resulting dimension expression in terms of plausible
physical quantities depending on the subject matter expertise. This requires a
substantial amount of math: basically, assuming you have the taxonomy for units
in the expert area, you have to solve a dimension analysis problem, which is a
(fairly large size) linear diophantine problem. A solution is of course
guaranteed since the dimensions of the given terms in the input expression are
solutions, but more likely, you are going to have many solutions (for example,
energy can be produced various ways: potential and kinetic, rotational, work,
Einstein's mass-energy exchange, etc). A decision criterion to choose the
"simplest", perhaps by the minimum total sum of the exponents of all the
basic/derived dimensions allowed, would then present the user with the result or
set of results.

I think the usefulness of such a RDA is minimal. A user typically knows what
that is when he forms the expression. Perhaps letting the system check the
consistency of terms in dimension is the only useful feedback, but that does not
require RDA.
 
> I propose a convention - it is likely that any use Axiom's unit package
> will see will be from the physics community, since that is the most
> math heavy of the basic physical sciences.  I propose we create a
> variable that can be set to select pre-defined behaviors for cases
> where a physical unit corresponds to more than one dimension.  For the
> PHYSICS convention, I suggest that the above command return a dimension
> of Energy, with perhaps a cautionary that this mapping is not unique in
> general.  This would correspond to what I would expect.  (Also, are
> Energy and Work different physical dimensions?)  A mode STRICT might be
> created where the above returns a description in terms of the seven
> base dimensions, which will be correct without pinning the definition
> specifically to one derived dimension.  What should be the default I
> don't know.

Having a system setting to choose a particular unit system as default is
certainly desirable and possible. Axiom has extensive )set commands. The
convenience gained after this )set command

   )set unit SI

will be that the following commands do not require a package call:

   unitMass, etc
   dimension
   unit

> 
> I think there could be again modes of operation - in this case fuzzy
> (which goes ahead and assumes if MKS units are the same the derived
> quantities can safely be considered the same) and strict, which will
> raise flags and/or provide correct but less useful answers.  I
> guarantee that making Axiom too strict in a correctness sense without
> providing a way to get things done will lose it much of its audience in
> the unit game, since physicists as a rule are not overly concerned with
> mathematical rigor. (Compared to mathematicians, anyway ;-)  I think
> allowing both strict mode and fuzzy mode is a good idea, which allows
> for both full correctness if needed and a more practical working
> environment if desired.  I invite comment on this, since I might have
> just stomped Axiom philosophy into the carpet :-/.  At a fair number of
> usage levels, people might not even know what Moment IS, much less
> whether the dimension of the quantity found in the book is Work or not.
> (The book itself might make an unstated assumption, which a student
> would have no way to be aware of but an expert in the field would know.
>  The student would want to make such assumptions initially, and only if
> problems arose go back and check hidden assumptions.  (At least, that's
> my guess ;-)

Being "fuzzy" is certainly against the philosophy of Axiom, but I suppose as
long as it is clearly pointed out, there is no reason not to allow it. Martin
has a "guessing" program for sequences, and it is very useful. So go ahead. I
agree that Axiom suffered commercial failure for its inflexibility.
 
> But, I'll go ahead on it, since it could be Energy
> and Work don't always interchange either...

No, energy is energy and Work is energy, so they are interchangeble. (For
example, work against friction produces heat).
 
> Don't we WANT the units and dimensions to take namespace, at least at
> user toplevel?  If the UNITS package were active, we certainly don't
> want people using unit names for anything ELSE - it would cause waaay
> too much confusion.  I would have viewed it as a design goal that (3
> meter + 5 feet)::meter work as expected.

Well, in my proposal, units names are implicit by using declarative functions
(like unitMass()) in a particular domain of the UnitSystem category. I have
already argued against the use of reserved variables for units. People should be
allowed to use J, nm, etc as their own variables. All system variables (except
domain abbreviations and names) have to be preceded by a % sign, as in %pi. You
have to teach the interpreter to recognize these special names.

> I guess I would prefer to be able to either "use" the SI system, and
> allow local overrides through simple syntax, or "set" the SI system,
> and insist on everything being rendered using it.

As long as you are willing to do the programming :-)

\start
Date: Wed, 24 Aug 2005 13:50:59 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package question - Reply to 1st half

C Y wrote:
> 
> --- William Sit wrote:
> 
> > Actually, we can even do better, without the user doing a
> > setUnitLength(nm), if the only reason to use nm instead of
> > m is to get rid of annoying powers of 10. For numerical
> > output (the problem does not arise for symbolic output), the
> > output coerce routine can sense the magnitude of the value in the
> > unit and shift the decimal place appropriately and adjusting
> > using a suitable prefix. So one stays in SI but the output
> > gets rid of the powers of 10.
> 
> Are nanometer, etc. considered part of SI then?  

SI provides standardized prefixes and abbrevations in the range 10^(-24) to
10^(24), one for every three unit change in the exponent, which are applicable
to ANY physical quantity (with the exception of kilogram, see SI pages, to avoid
double prefixes). More interestingly, SI also has prefixes and abbreviations for
the computer industry: kilibit (1024 bits) vs kilobit (1000 bits). Axiom
implementation definitely should adhere to SI standards and implement all their
standardized and accepted units.

> Nifty idea, and one
> worth following up on, but I would still like to peg things at nm, for
> the following reason/scenario:  Let's say I know that my calculations
> and data SHOULD be coming out in the nm range.  I set my unit for
> length to be nm, proceed, and mostly see small numbers of nm.  All well
> and good, until suddenly I have a huge or very small number appearing.
> Red flag!  Not close to 1 nm.  With autoscaling, the number would have
> stayed near one and the unit would have changed.  Sometimes useful, I
> agree, but I can see arguments for both sides here.

Since SI provides prefixes only for every thousand-fold change, if all
computations you expect are in the scale of 1 nm, you would probably spot these
errors in hundreds of nm. But anyway, every scientist should be aware of units
attached to quantities, especially in graphs! I think autoscaling is good enough
(Note, all digital meters autoscales! Scientists are used to that.)

I think whoever implements this should first program for the correct framework,
and provide basic unit systems based on SI. Then as usage expands, add more unit
system domains. Then if that is not enough, add more friendly user settings. I
am fairly convinced that the framework proposed earlier is able to handle and
facilitate this plan of development. I would like to hear more critique from
others.

Thanks for this interesting discussion.

\start
Date: Wed, 24 Aug 2005 13:50:54 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package question - Reply to 1st half

C Y wrote:

> > Again, this would complicate the implementation of the domains for
> > UnitSystem category. Would you allow, for example, in SI(S),
> > setUnitLength(ft)? (I would vote a definite No).
> 
> I would vote yes, because I can't predict what I'll want to do with my
> unit environment.
> I can't imagine all the
> ways and situations units can be applied, so I don't want to restrict
> the user runtime environments that can be set up and customized.

Fair enough. But there is no reason why one cannot first convert ft to m, use SI
as is, then convert back from m to ft.  If a user really want to use ft instead
of m but retain all other SI units ALWAYS, then create a MYUnitSystem domain,
and use )set unit MYUnitSystem. The implementation would be so much easier and
you still retain the flexibility. Flexibility and generality may complicate
usage as well as simplify usage. We have to balance the them.

> > > > The user unit system can mix units if that is preferred.
> > >
> > > So you're envisioning a separate level of logic which handles user
> > > settings, and the underlying one organized as outlined below?
> >
> > Yes, but that scenario is not encouraged (indeed discouraged), even
> > though it can be done.
> 
> But it should be doable, readily, IMHO.  That's what computers are for
> - to handle the grunt work associated with such decisions.

As long as you are willing to do the programming :-)

> > All I am saying is that even if an equation is dimensionally
> > correct, it could still be wrong (in terms of physics) because
> > of this non-unique mapping. We certainly cannot just use
> > dimensional analysis (reducing to basic dimensions) to
> > discover that Work = Moment is wrong.
> 
> No.  However, the ultimate burden in such cases will rest with the
> scientist in question, and it may be that the dimensional correctness
> of the equation is useful information to him/her.  Hence my suggestion
> for two modes on dealing with such things.

Dimensional correctness does not require RDA or even DA (DA is used to guess an
empirical law).

[snipped]

> There is also the case where you want to know what
> quantity/dimension an expression is.
> 
Reverse dimensional analysis, is useful for providing the user with possibly
different interpretation of the dimension of an expression. Checking dimensional
correctness is a different, though related, issue.

> > I really don't think a scientific worker would use slugs with
> > MKS. 

> That was just an example.  nanometers instead of meters, or light years
> instead of meters, would be more realistic examples.
> 
> > Don't mix unit systems! Convert first before you start the
> > computations, and convert back if you really have to.
> 
> But that's just it - part of the reason for implementing a Unit system
> in a CAS in the first place is to get it to do all the converting and
> other annoyingly boring and error prone tasks for you - both for input
> and output.

Sure, but that does not mean one has to do it for all possible conversions, only
the most useful ones should be provided, with functionality that allows, though
not as convenient, the very special user to change units.

> > So pi has unit degree/radian (even though that is dimensionless)
> > when it is viewed as a unit conversion factor between radians and
> > degrees.
> 
> I'm confused - when does it hurt to trivially reduce or ignore this?

Ignoring it in this example would mean the equation is not dimensionally
balanced, and worse, some may think that degree = radian!
 
> > Dimensionless is not always without dimension
> 
> That makes no sense to me at all - when is it useful to consider a
> dimensionless quantity to have dimension?  Isn't that a logical
> contradiction?  F AND ~F -> F

OK, let me try to explain again.  A quantity is dimensionless means its
dimension can be reduced to 1. But sometimes, it is more meaningful (physically
or mathematically) to view these as a quotient (this is like, but not totally,
we sometimes rewrite 1 as 2/2 to add fractions). Even SI recognizes this in
stating that the unit of a phase angle is m. m^(-1) = 1 because this IS the
definition (arc length spanned by the angle, divided by the radius). Just
because the dimensions cancel out (making it dimensionless) does not mean the
dimension is not there.

> > One may do a certain amount of guessing or pattern matching,
> > but that is limited by one's current knowledge (limited, at best).
> > The example I gave earlier, m^2.s^(-2), would you even have thought
> > of it as absorbed dose? (I certainly didn't before writing this
> > email). Given the vastness of scientific research, you need a
> > subject matter expert to increase the chance of meaningful
> > matching. The user is often the subject matter expert. Let him
> > or her deal with it.
> 
> OK, but I still think a) we can prepare useful "domains" such as
> defaults for physics, and b) if such work is done by subject matter
> experts we should be able to incorporate it since it would constitute a
> useful tool for work in the subject in question.
> 
Definitely. We can have a nanosytem domain, and other domains of UnitSystem(S)
as experts need them. That is the beauty of Axiom's categorical approach:
unifying domains with a common set of API.

\start
Date: Wed, 24 Aug 2005 19:19:25 +0100
From: Peter Broadbery
To: Bill Page
Subject: re: aldor patches

On Wed, 2005-08-24 at 03:54 -0400, Page, Bill wrote:
> Peter,
> 
> I would like to install your aldor patches on the MathAction
> Website. My idea is to be able to include Aldor source files
> on MathAtion something like this
> 
>   \begin{aldor}
>   Aldor code
>   \end{aldor}
> 
> SPAD code can already be compile on MathAction like this:
> 
>   \begin{axiom}
>   ABBREV ...
>   SPAD code
>   \end{axiom}
> 
> I want to be able to call both SPAD and Aldor modules from Axiom
> commands like this:
> 
>   \begin{axiom}
>   Call to Aldor routines etc.
>   \end{axiom}

This ought to work, but not immediately; One problem may be compiling
several aldor stanzas together - in this case you need to be able to
refer to earlier stanzas within the aldor block.

Eg:

\begin{aldor}
	AldorCat: Category == with { funstuff } 
\end{aldor}


\begin{aldor}
	AldorDomain: AldorCat with { ... } == add { ... }
\end{aldor}

To compile the second you'll need access to the .ao file generated by
the first.  One solution may be to keep a list of .ao files within
MathAction's session.  Alternatively, each stanza could implicitly
contain all the previous ones. 

> 
> In the log file you will note that the make failes starting
> at this point:
> 
> ...
> /home/page/repository/axiom--main--1/src/aldor/Make.rules:31:

Yes, this is due to me not testing stuff terribly well.  I've sent Tim a
new .tgz - appended below.

> Regards,
> Bill Page.
> 
-- 
Peter Broadbery

--=-+rpPFA0kuTh18BaWwL/R

H4sIANknDEMAA+xc+3PbNvLPr8ZfgXPsr8VGlh95dEaOO5FtJdVVtnyWcvl2nHw1lEhJvFAkS1J+
TKb/+3cfAAhSj7Sda+9urrprIhGLxWKx2P3sAowbenF68OR3/RzC59uXL/nvVy/o76MX/Lf6PDk6
fA7/O37+7fHRk8Oj48Nvnz+RL39fsfizyHI3lfJJ4o6+Quen2YZ2PRH993/Ix6X1v3Q/+43JIhrn
QRxljcSdJ7PQz/9JY6A+Xqn1XrH+R4eHL9X6H714/vI5rP+rl0eHT+QfosT/8vX/6MXjxdyP8nHo
ZtkXN82Dcej/LD7CfBN3/Nmd+l8ajYNsnAZJnh3k/sOB+xDEc6AY+dMg+qL7w4M8yEP/y8ed/nXr
4iBLxwdkXBKNaxIQU3eRz+L0y7Wf+6k8S2PXG/npIzTMgYa6a7buKMtTdwxsW3Li30sQZ7IIJdJJ
Y6jiox95Fql4/fqb7747FU/l/jf7elj4KuDJOz/yUzeUySJN4sxiIicgI/IVYh7f+fvBZH88c6Op
78lT+VFsBRN5K/8i9ydyp3bkyE8nMp/5kfTHs1huf/ONPFsEoScnLgzlEa+d2rGzfQJPwsw/QQ5+
aPM4LnjM75gnPjzZ2trStON5YjXILW4qhiUmID+LeSJ9GKnETEIn6DEJhJhE2TCIxuHCA/Gap/JI
vBGst2Ll/tVG+OfnX/Yp/D/ulX+25+fPZv9/dPzi1aHx/4fHr8D/v3z+4uWf/v+P+Pz7+//BzJfM
aK6tVMpeKmfxvcxjjgj8R5z6chxHk0UWRNO6vIvDhjxqLAUJ4BhkcoRuO0M/LGlCStggAtEm7tiX
YTBK3fSxITq5TP2fFkHqI7mbc59w6kO7nLkZfE9913uUIx8cNPLNhegGI2LbFOI6dKOmFOCa3/k5
sM1yGU9k/pggvxh6gdDzBMOHOHZUnMp92XATibPlAOW74xl1g7Gpq3juyEGcxGE8DcYQ17I4Bb6R
HEPfaZwGzNxDTc+DyJcjF2LEOAx+WvjihSPfBpFnZGnAJLx47gaRmqELmlRz9gSvQJLAcoEMOag6
QtYoyZePec6L87NZnUyCdmktPDd3pZcGd9gBYpWMoU8qLMKo0L/MHrPcn8Pa4nCB57vIh6QBqcHA
MpnN4kWopM7iRToGLbgwDQ/YwQxhH0/9PKtLfEbBEpnr0WSSgkGnNCrqxPcC1DJ3kukC5BGoIw+V
CFaa+TRQRgKBJO5dHIC9jBc58U9ckBZ1Z/hnPuOJOphADrILFxjkYNIyT4Px50fUGQ61wDHyGPgK
0fd9eXtL69mYf/70iZYa1gzARIbMycZRHVGQB7DIaqCQh5L3tG6R3xDiKsbJ0NplWTCNcEvKGq1P
8/RnR4JJge55GXCyrLSA2DAZUsE8UTyRz9J4MQV152o9khQwRJCACF4wmfipH8EO0etTjJiR5fh3
brgA5XoimCs9h4/yfobCV8ZWHR4S0CmoZfQoI9/3YNBWmMUyMpPKYQkEbBOaFq4GIKGHMciqterK
bA78H3F1Yza0+wCaR7AVoinIDwsKampZogJd/+a8LjtXg7rsnf2V1rX/Y78uAYLB0GZfs315xhLC
ML7PxB6u/B5yuY/Tz6CXFFYlfNRGfXu7UwP2DvsVWFomiNGjAE5FU7tz08AdgeExZtU7H1BkivtB
O9Dl6CxEMPF/krWdGji1ALEijuTUHQF/N0/h8cwPQzn2oKX1v53epXMAPhzdeDo+kcm95wiY9CZC
0KIiBMVsIoxH/1CEoLmCEKcXuXPfkDvionf+/rJ9NUAQapiMguhARxDRa57GApx1MBEAUq/idA72
5kd3QRqzPRuFNUCDVgPqD2Z0uvMF5v8za01cdi7gAcxTP+i9H8ADmM/PB0D4Y18/F91O/xp+k2Cl
dpQOnEAiznq9wVqKURzn4LwkfMRFmzitJvT8BOhQ9e2b9QMqKoTpH3zt8+IILItCFsYlFao4GqxS
kGx1L3o3NyA1bpbMzxsc9PwoW5gwRgaM1rwn7wNYMzJjGugenWeQ675SdmhD1Gk8kkJQjyyYJ0CO
4QusEoRdjMEnZ5CohY+4RESKHHHX0yLBaBAKt569oYzoYWenEPRUPmBiVEp0tq9iFftViExBmIs4
2oMAAK4ziQN0Bxx0PdznoQq7DZnnk6ixrfKvzN8yH3iwxczPlnqBvaETAIcWjwPeihiotk/sfjs1
MC3nBH+TBm/arW73x+HZ+0734vSIk7zOlWO2Lc9gyHgC4rJihslZ4/r73tWPTVwEXG/0tCqKyb3b
WwBibvTp056spT6mphl4OuMiUC6HpAVKjFRDFRKpA8VI5MoPDXmK0ty7YK2QBGcBmAp7I/KSFARx
mWjgZnUagqe7PL+KAobUXQhbqN/OzOZSKIyGkKW2NwrYsbfOSnFTA53bW+NDMdiiUk7Q0BHFMRSD
uAF2HKvABmHzXhJgAVwVkc0FOWuMbIc8z3Xr8vr7bnswfNvptnlTl6fEP42RzT+rJzruW/QNBiIw
l8tY4USYxt7nKL4HfDiFeOOOICovGzzuVdgIt7flsMH8Pn1S+5/ECRgCUcDlSZv6wH2Qz1T0uuxd
tEFHxqOAI5D72CZG/sy9C2BPAnRQPSX5lhwiXIjhMkHmUc5ICpo0E9DcuzieAjfEOXsQDxdpBvCQ
8TtA9wxwH0BOWI90Dl5kj2sziCWDaILxgPAKq4AgQZY/hgTDTIwUAmS3Zi7nkOFpQ0AniksZYq2m
FkAmoafu8NxdifNGhrCrOledAewmApQCjIr6V8hub992rlpd0LBCByUXCz0Y4SJ6BgxVIE6Ah5it
AMDICVkwEiwJjnPHzuhOSf0wnN61oBQPwyBMtmx+0A8hirF4e/8jBAMEjwhLLfy0BDmE2RxMz9gP
QBQ5+xI5oSyEOOgKEVagiZH/UgrNTLJyH0u0cSUBcgLMMp36PDnSAC4qkLt6lrwJSIMc80ChCWLe
O7CvujJQy2nDpFW2ZsC/ZsXRI3uMcvdBsAzjOEV+cUQbSGUy1sapYLUBtapVJr0bq6f1L60ZzU/l
I7e33c4Z4ZzhoHXzrj2AxWH5aKJCT5TWgqYJglACFBch1URcee/reKsX0PWQFfIQvLJWTqvDSO32
thJ+Pn1yqh4smERlOGk7YcKVguwdXBvuCaHnv8pv0SZQqIW2NW4HtRuiRytLRPu3DIqtpbBA4BL5
92AlgnKWUipXi2d6ocmZKYurOj+kRZXn2vXhxCszL83EctGVFu2qC0WQQazXhAAFDvu99zfnEBKe
YUgw+xQwat8RhdKrVoL6rqxZU+e7cgW52HpDuOTeTSO06IFaelTwzv/pVkI7uYkX2xpoD1WwLwY4
77ZbV0vct28Ig3jl9JnhEXApB/uCmaUGZIU+LcBAVW45gTRWlbZ3ghPKabFm/z2scWgbBVsOxeh9
jNu03SgfY1tTySCW9NCoflpA4g2YUYj3V52/DVcFaiqbWItDTZCtlFaL8XwtcfNsMQK/ulvfNTLV
d2ormNscLv7ekas4eHfB2s5idUNT7sL/izxQr81OTWdXWP+/6nX6bfjyZlts1TBl26mBQ+N07A3o
eg01jPoUlH4R84Y5AjFBnxzPeAOXgokVvyA2TDBI4wafLFKqNEDAw1wADLIBbC0YuGpeNhIuGb4C
k2UYaIo/yobfmIOfpby6micuJyVV9Gv7h/+CoxL2lpbj+x2OAL5y/vvq1fMXuv6PVwDw/PcQmv+s
//8Bn9+//n/873YA8NH/B4A7EBd9RDyBDjnWA/VzRjAwfQZSDNFUCRALlEWQr/N30of+TnKCVOwZ
i8oCuij6BpyiNWfU8KyfLyYTU3ovkKHmA0SiCgAwtEAMHJpUEH+kC0jH5r54uo5aE2AYbvWAimAK
D1IMcdZtnf/Q7fSpavf2BsCP7Fy0z3uX1/Kmc4HPAQ7dDG465/Jvre67fntwzBPBRVOYnLNrTGRi
jNQIURDeQoxHrcOEaFAWYoise1cQmkjQsftwSAcXGXzBP47wDxSR+wAGu2xzcG3hg24wUi3d/nVf
ckvowohuDtB2BMhgMYJJhoAd3Af/AbNgNdvD4Vmr315Fr9upVDXsDNqXxFmT4uEJkuHfxJm/MHP8
rvu/a1+VeOBC0ChAJMSFn2RDM1/1aZ6Wnw9JNhq60qDkVTJVGmnWVV0og8MTiUQDcZWImaMnXB2a
+rWNmQoUA5LXVQ7oJgfwM6krgFpSFwAaMjN6Yng94zpwwZ1gT+lBU5a56zKSm+HPTFrNDYA4y93d
RIGGITQXpRlQ+CpSVWQcxgmfTaD+hVm636CDypJ/RQ/2KEYXpYer9MG/lUJW6qPCYoVOFI+19KsV
A1O56NyoCahx+bG1i/HzrNjJ4rJ9eda+6dumTiJYm9AR2H+IRfeCDEakpxhc7Kd4ipaOLfsvNFLs
LqQoNoGxIbVtRbWE98yiMUwaM9/1VvR9WuxiSEowN0eAClgbSxZYfOSEkF1i5kO48cpFIivFx3QG
bxJhOtwaDG7a7xpZAqPSiSpA3cD3GqsVn6G9LE282dwwEU1NlrI1TtaSQm6wifsAz7joNPzAktnk
JtcA4GGlsFgBCb1S1iLnugcY3MPhRZA6lTG3MVfEC1TFwPEBe9u4MPpYyU5Jjn5GJX/ITuQDJZnq
eIGSe8a5YYjjhMp5x7DTrnpU6YAQRDolD0rekcLOPp5mBWN0hvh7iLPD6hJYEv7mTB+t0rL6Z1bb
isfknom5FeSYOyEI2GcZNu1/wKztVIf+pxwC92WbgguEFvDP+GgIaIuhB3SaB1Ewx6P6SpxbKcuR
2ZDEmnNim6Mjrd2oaKydqJ+YKR0ZvfC+VKOX9p0VHYnISGwT6YeaiGdT2cE64Frj29ysp3Z3TVFq
LuQsK3Czd7Di/ErJ9aohLqPyubyfxXgnYAY4qPYXR60gQpayXeGKr7cs3VpxtFar5rrenvTkUTS1
ZmwRvN4a+VkkVvHJNKuqwQ3DSZojzCwrYVjAmgrBa1SBsuOx67BncOkz61jYZKUHCqY2YmGB1uZm
SrGpdWPfMEvsMzkDkjeyhE7NZVdjsyTn+prcKJYUimqFlRH8i2oN1aOi3+MG4Ob8//khXvYu5/8v
Xx2/+jP//yM+/1H5P+fifAf8V5YBjpfvAb5+De6YvDG5LE7KS8ek0003cir7ZTmhrzCbu56PqRYd
dEWLOUycDujMtTHPD4N5kHOVYQ9v+ACLWqPRAGgDWbZTh6/OnpTt4ipg5uszH3N2Rh62TkfVdGdw
EqfARt0pA43t4TWPPXW1g296uFoIytTpFiNefMIS+0QdsWR85QJnSbcz6BRE8QgiOlHDy08ATukW
SfN06YYSTcGp4/mRY9/HN8XaJjyUGto2ZVcdYOqjuKC4LclFZ02uzhCKHnjoqirVtSiO9s0qOjr8
bG3dLHhR1Clarmre93S08BgvgDIFbmjYdOJMPfWIXC5pSjNiUa42lZ+CFglbPfmWiuYViwKEsIep
AVJ2rs677y9wIkxKucHMvfN5RfRBtQX/VSHAPmkCxVsFHf0TN2Sfaz+Y8tNFy31cTSWhKTbYclQ6
Q0ZIj4BBRx16ZVSsovuM/h1sY9Le8sFX+WSs2DDrCZffRFp10Fa8BmLJpA76g4yLGeoMHfbJdPEI
eHkFGwZDqxr4dtg69FeWYYnjCk5qa+jNoE/gED7hdWE0IISDTy174qNemoDZKLjpcLNsERxzlgpn
aicUNbbCRB/B9lUvLJA1i9vGeM3N0hbCxGz5mqHaxMigaIS9CQ5bMqQ7G16e3fSd+iJSJVNH2A2F
gQ4vf+gXRge/uWJX/B5cXpMRwxOlKCV5uztQRRg8dEIfh1Ot79TW6MPB8oxKcnZqSOs4jjDEK073
ivxyFxLEgjOOXHRV81nZVSWbTAnrX0NGTl2uYaXUsXxGOP9s9QFZiy4E0kGE4WXr+tdpA/Nj/FTk
JsXs765SlmN037mChEDVVpenvgSRdxH+FrJgx2IGhtew98t4xes49c7+ykIts+m9V3h8oyhY8dL2
t3o9s2QNh7J5qxzMENFmKFt8lYQbnPI2qBJpAQ1ZsRA2mXmq5LK2keJnTU2XTPJ5UtjqEGeZLxvq
2oxteTEpvBP0Gc/88Wd+f8FbJGGA7yZkVE9JJ+rGB54a88mx7kTXlzIX/PgjM+CjfnWlJMJIA2Ex
SSgm0qVVPFEw90oaxcUKaPOyyvapF4/V0b/dChMdx4uIk+ViR9k+AOngF+zm/YIVjIyAlh7Xl1ju
1Pw0tXWAd+XIvdNFCKRFIn1/w0jGXPfxstvu/hFtUZSNeCqXqAN42aC4ely2r6YOAXhJmx14qQck
vLE6d38c0l0BqzLrbKCdhO40I9otttsNtHhVOtRlWkWEhaVVQywTCIQmv9r16zIJARs7AnxoXQ3a
F3qWeimJynGEgkEX5Vaz0Eym2GvIRJ4SsAi+vBIb6MxIjlITKvDiqwWTINJ3t0rXv8yZGVYPQrB7
YIegfO5G7pSLKRqp6LuFfBtDIVW6n2PEA7j/IchnfFsSISlkFXtKEtpNy+PqmxwhDp7hSzNUyMmC
XF350C9D6O3KjPCWRsq3K13Y3h5XgRrCMusPuKSsc0d2mkpIVHHJ+j80rUVYAiCqPypePyq42CZN
jtdUipfDsWNXkXfpYvrQUDTlasdml4644G0zFXw9nF4A+wplqchkWkpVpuVe1pbgsGJudr3vdAdN
uQ3tYFt4qIOXebDotJ+s0wAVo8oHCdWIa2mziCsry2e7ugZWjpWrSIvDBq6HAXsL4a1ByAyQyT7n
PibOmDPhqxa4uxI3wwzEi+8jeRe4+kbkBuzawhCFO3AfXYGkkjfFxH18gbpeN9t8lx8YNdiYC83N
85P9cRjTBSnkQm9fa88EjXXVHS8cS4sYHlHxdacGDx3lNbDMAV6GqwJqmji/cboY89XlAAB9mrsR
BMMA379SRRFI1TPZUG+HoWZiaOT7keRvpnjD2uBxoJ80JAUkjszwH+w9z34pC/YtHfEr10jiG32h
zwMM8G6A7/S0rzsXqz2ymiDyoe1Kuhv0rrt/71o+WDEg+7N7DK1B6KWalXizgtKZGXPFHfLrsLnV
Xzwt/BG+jqNe61cSSYvSIvQfcqIt6D5StrV+8Vk37Lb0VExvddCFJx+FLlZDtqIPQLe1vJZCtgrC
rG9zTFBIs6Qnmx85AqVnNl8frRO3qA4l+v4623ITXwgZkYbWrMsqHGqp2o1XdpYVM7BXR3xdXTgN
JZdD+I2+/aKOFbxkYNW6NP+qN5Afejc/dK7eyR/bA3X/InG9Pt7W5cMhvHmRuCnXsYqkfZ0z04Ud
xw604NWlqfioe7aazimVdFblnGrmuwfqOApT0I1Mzr//BVyGhORX8hKlJ8SuCM7LDKwmjCVSR8Hv
MJyo73v6knbBtH3+w578rkQ0+L7T18Oyd/mmSmKqQtUqlibcVNM5p+TFHPGba+pU0+MMBquYX1lb
lh3UtBquaviJwNaekPN1CLu+6ypYW9jXL4ZjvwG/FWU4WuOKYJZNlkuVxUWIDT1Ml6IeSv1KHYSw
6p1VxawNQereD/pr1Xt5Naq1VBp7w2Ck803tTXnOAq2ZwIbdjSkAqWa4y3tyvdjiabEmFmdHrNxj
okxkNmt5wKbZtds2F6w1bJc28rZ+zNtz+1dvz8248qlskQOmW3BUd5imMR/RFP/6gvkHEYrafR5P
ffqnDOjk2w/VK1HJIq8cZ6gTCmVu5SMKfKcPXynEO5BIqfVGFvo68L4ryJUgRe6nsjSEfvQOk/1y
DB7JlDletN9i7boprzCtx8nNPyu4pzrrqwc0oUt8xcnMg1lpLxx4TYmyqeCOJ0DcUlIFyasUoAwA
O1mbsWkOBYlTwYTWxJSulxYl1umuS1UfeOwW/1DH11dDbpUvTaxaEftuqirXofD6ekZzq6+UZWkQ
YbruBqBPF1B5FSUWBCA7nwS+gtxLHbaiUZNfvYYndCqoxvgfkwmo+tdI3SvDq2D8uga/7qonWKl2
/DI7ooPS0pJvbWExh86oqsLq94uahG6V01Xysr+dj9LyEhtNmQSBeO1lZpvxIUgMWJn4al3znbmv
6HtdADXLbL9spQ4rGPZyq17Z0qGFsG7jaJRcIReiKJQXzSoZKkp3KvUp7tPY1E45ZmjWjnLjG1z4
ss6XfbnNbqkMVhXZhgOmoxD7Zfdfcv2GhQ5V7PNVWLL0b7fqF6+MFu3GzZNrbkB7DIyKi2mQmFTR
3P+3961tbRzJwu9X6Vd0MD5ItiQMzuVZEbwBgxPOYmARyWaP7fUO0gCzFjOKZoQhwfvb37r1bS6S
wDYnOYueBEt9qe6urq6qrq6uhiTtuF1U9bQiSJ3rNfPZsh+WkRWyZ0oia8kQp4BYLmrq9S3XZS3r
4yudKHjQYKgvVfcjvlqLHqa41ae7VgxDthBe6Jz3fHGdAqXgrdBkpIYXQ1j/aYYn/LLLIO6AjqzA
BKU/nXodCmPZAjnrjT7MCu2+ShaBOWTy9rqyfhYbULOpyzCHrQDTZEOEtRvkiZY219zRlkdyU/Zh
qJq7ZNI1cqV4PD8i7qNZ1DROY8A12fERMuG765A8WuY0gFroG+4E+7R5TpJ3bE3AkDgg5/rjBCb2
/TjKslCu078PKJgQ33skeYIuw3KbPokBFnmSxHwE3lZBioctcscehciA4xtgmJ34CqFFGcV1Sum2
NoU9asnpfpag90gCgoh/nyTAJDkiCBIUXhLES+/no+yqBdS2hBZijEhkSrAjRTgMKUAJkZlNJtKL
TCAo8Y7G1JYajIFYKcCJ1CV8JBehvrIdh5cZjVWDNj1CAOgcpKMAtdjJo9AbAcTN0rk7NoztjMPR
EIOAaYi6Bt3+R8O4ux5J85AJW0dajjCqhaaRFab0B7gYKMNswKgzuC3TpTB0Y7MlUUoe4NKoyeog
OucmWrKXI9ytOudZK7St4r8MZzoQOWWyWiLtMbTq/7bQPzZo6RXrfWb1yO1MzdQxx1xeM4wFPQpE
rW+MIyEBy6hbNBliMhkMi8nC1yvHSlXNfqFinUM1a1SCvujtEqZ30iw4H3XRLK2cbRlVmV4DdXOH
T6DN6fzdgIdgC6Mf6XQ4ZPhiLxU3ezontDFw0P+DmB7ym39h0AwdZ2AQ9ofBmBcDO1ZVWy128YS4
WeYuC11C01m5A65k4iAr92p0477L8nOQhKk5AQPNOA2pmphaQiRwZhc2iEoc4n1kMqeJ/ovD1lpx
p3pI1G7TM9fZ4+Y1TKZ7VCE7xZkNca/T6RQMGnjeI6oNhxMoTzeKEB+XOJthVFFe/gXz84G2vmsu
zGML693cxmXHUDDUiTg1SovBi/h4566pcJhdI6VnmihQG9Jqrb9zy6mmHkgkPz/Bt0MYqH4ymRML
gRzyaDSAl1RBQaT021oSH7inXHTcS0HRSvGIZ+geSo0Tyl+qfVhokFDzrXYrsp6COWw60Ix91rh2
eYeqD71fLrXiwZ57Hgk/Hr5oqq2uNUX+Qztk1r7LQjx+c6Tjw2Uq38JSkB+MFUKpyK/7XfanVY+4
ONmFuQUAuVnl48lbzWcOn9rNp+799E6hQQ11+ynXm1RZNzf2cx3lk4nyvuIgmCjEVHLz7YsvKzra
DMMCA7k2KMfn7/KnM1M8wvY3/7uJLl0eKTrnzE0XfwCZEIf/Inqcyt0idlAC5bBTiZrZAxf2Fg1x
4OzIWe24Svk2XEneJ9S6s86MIsNeqbOLsWfpA7Vl3aRLGIbgrA6p7j1wo4K5PodEdMJvEQp7MDk1
MQoJFcLtOGgqQKLoZ/CoXsuSCewL25la+dOf/vRkBSP7P3kCObzaqiX7XzFOizh76W1r0M8mdOo9
iAa022WPkk6nIKYRLAUp0n5WP8ZsyaNYTUvS2lJLjfgmIl8SwH2KhfuF6Y2gvO5FFcldFPg/FBfE
uc/gk+gnbGNW/I+vvrTxP778ku//PF25v/9zF58/1P0fark9FhP/R9wGelp2G4igmxiYJQE6pl5p
KfrHWrem6RsLtuKLOeGKzS+USBwYtnRoNe7ByPiej47sRy76LT7qMRHCMbElfrV0doL1j/5+AFvC
bzHvGVr5CRSJs1w0cnPg4Xw4Xp3dWU4Fw1qBOJZBFfF4rlBIcR/rKPdmqHJYir97RxsvS/26HQC0
/S2BUS4H9R5bfz1FvI9SrZdJr61ipjuZ25I5+yxf/QAARslw/AyMWeBRLnee7RcanOgtEg8J1w+v
rasaFnr7UKwt7mAYg/nxiMlAwtr6qNAbIV1cEtySbgm0V3ABKYHDAFDBJap6aMsyG9jnFOyR7TjW
ms3OVWiqUM+d3UHDki7nNt0N7sJiA+nRJi00+4k63OtR8IEFRcjjIrYEnuccw8o4CdJsobQEXYNp
QJngXbOsxFJjCDwLW/dGuSAadb4wNPiLiazf+GWC8cwbZSNrlgJYkLIvftx7frSzv6eLa5C5Lra/
s4EQ1tTWxkZvex1Dw+EXfJEmvET/Qc5YIy1SAlEDRLLFf6thIWXb2SV706POMDmFjjWcEH7YNwzY
gVF4zFgo/gLoVgiwH2S5dba8uBh14Iu65hcLrtUkjn6x7bnFoO01oil62qYsuyR5zdA0mTtzT/q0
ynvTcqld0vRA4hDng1Vb2glZc6Q1I/nMo5kzmeh03kZxSI/2MzxeoEOFW6zvOGnrat7pjFss71m1
cTAtgMzItX8YwraOGt9v76mNAyj/yPQfvgYj1+jkGjCDS6IZvP3uLND3yTnGAeY1+mx2lZIVO71C
yQKeWqGRRt0u6DptbKENmzzYxMbRcJ66s3jBjHaRNaAlqk3mO2EO14uPrptqzp5rCHLLz/IXonxN
Is6JMAYhQrt4E2Ahz7lJQ0xuuTY+UQP62K0dXLbpHM7ixRkfNTYD4G0Z4JrKxpOwqb6tAO1TN/RX
GKJaffZfK8Z+lbLFoLO1vbt9tP0WGPb24eH+YVcVF6KwAgSNnCChSFuevkJGDkAt9E7sJxx53xi7
XF0T9+QdqGPNI8Waruay2ztoP9vvKv/GgKbr0Tg5jZUhbxceRX8dLZ8kwfnbYSdZaKqGBIfimVuw
Fjq29PwDZqwLrGk0yXSJ77DW4m+bf9/+gHLvWi3+xu8mfCA0V3Xf7Svhfg25E14j08bD77y32Tbl
IoattaDkrTSWS/M2ZN5yw5D95n2KXBQPHT70D2YbkHEHaUiHpjBln94CMGP/v/rN06/z8T9Xn97H
/7yTzx28/+US1y1NAJv4xAp8H7m3VApbeBtuA2N6ymtWoQqOQR24iAL72qPWyNnFJozIiSagVwZ0
KMeWgnJ4AFrnoBPHugcjCsFGMTiiLDyn23mTEbsSjEPjrZB21cbxcXjB/hmwu26ZTbK7+eFjSv1M
hR1ch6weA98qIN4beMduksEQMtBn6bGpHXTyWcq4n7T5H6hxdHqWgRLwHnr7N7IHxIm/76IA6rTv
J+9WfKaLY+szevjhhGMXKRzFdDiEfpKNpNHY3N/HaOHNugJh+mL/8CV+26PfBzv4t4fx4fDfo8Od
ve/x2/7Lre2f8Mv2X/Evx5CCAtvfb+7sbeHXH/d24Bd++2n7OWVuvdjd3zjCQkfPN45Aelxvkyi/
hm9bfDp9ra63kgkoly9AbEHGdS/MnvNbaFegUjXwvybCYlCzYM2CAsNCywb+u7X/sgrKDkjL03Cs
v42D4Rbh1gPV+/vLzf3dWR3qXZ0fJ8Np4zrceK77o17sbO8iLvlTMURcNkBrmLoxGg2vrlEVcUsc
lXX8+kUUDgfXTb9tg4n6tBYDPKIIB9ewP7tRm41rvMd6rVt0m365AZT1s2owedUqWn4ZZOPocvpI
D2EjN72t3o8H3JDS0w4NVs3XKBin4Y9xRG61WXiQDK/i5ByW+Vy9KODA6UfT1z70eryV5sHyvwfd
7/wruAg+ywOg0+X/l1+vPMnH//7qy2/u3/+8k88fwP7fw2CqsBRGZ2QyQnOLDrsTDKPsqmjL5zgS
+IKKvPTnBZ9ORhLqOMUHighw2tXNhjGMBvei0CeS7/k3NiX5eRLHYR+PIZz7AtQPBwI+Hcoyu0Fv
Ro6T4+B4eCW+/E0SrrqXfHNf6yKkOOkTDxLy9YyeYQxTcoUkNHIAq0QNg1/JIVTcOtl5S1yhzhME
rt/mcV2DE7pCXNRKrvQrGyb0lPGKbYk/cT28JFSjnlXAAr+rhI5M9kRAfJn5IixG2QTE43lFnbSV
pvNkJxkFycuVOgajAqwNJtRVuh0NbaXhLxN+gDIWyFlSl12oPM6K6DP3QmjsG0N8FTU7O2d1J30f
jbSb7xLwWmqE/GXJs1aXXWrBTI/PcU+JrznxTGB9mIksuwJ86HsjpBth70kz4qvailjqJIuGnUdr
XlqUYEqdFp1C7qt+I8FZp7/41ChhovE9kT3RaFOKfOAywLZgqSqGwMV+q9degoocDY6SvWQQ4vd1
irn7Q5Cewa9Gc61e69EbtGjmsnmQZvJifFiqIs9Mt3H4SmEQNWq9gf0j306cvcZzWG4S2a6z/fLg
6O90LIOAPpgadC0lGqSm5k6GdIaEjexhHfM6kaRRJ7AQvyPawPQOKN97QIsgFhFErZfRY58RuuE2
+EeTYHViKgUQaogZGqSMEX83ogHl0dg7wWDQwG+U5CCzM5pkULKldCbPhjMgukb2f2I8RIFQcRco
RVrG8IctJd8BbmaGSV2A3D3uRQP/bbpk2DkFIoICuhEqOEiz6RWoDanBf6MT1TDVYLiT4RBUvhq+
VvueBi9RaLcv+yFFKtcwuDoORg0FTzQy6XRLd0Y3J+mIuv1JRkWHOk+KYt5ObLMAcfUa7BLpuRq9
/zSoM7gCtjEZx0XkNNUXPCBZIfiw5U87vZ2jty/+tqWgz0/W3MTNjed/gcQVSAROHKcRXZZDl3YY
PiTS0rrAsC37FFLCjjkcYF6DkLL8CN8am8bMW+IxD6IlQN6dnUlCGgbj/lmrXgM04AiZbSDvFC96
4uZUTbz6uYZ29U9GowSDyjBTR9ch65/fkRiXY9hz564GYLAPc/3SeOPXa3Qjhd4p7MNyGoyhbQ6m
DswbulAytI56tKwJHRMnWfi8yN4sV2P+Z4RckUGWLXhegIUlrydKpnUGF3BXuF4qPg/AdYEFkJR+
olg9g4YhniYulScMCls6eT+gMpYnfNBLXy+TNDMDOQYdcIcHY8mpM3SKNJz0NPo1hG77Y9IgcFwH
aIlJJumUsZniI1N2+hhxLeQHSfSvr1aVET8Xw7YsMlq6hsnHHmmhiP9aFouzni9tycPwXChWhuIS
QQqw+45UZX5C1GkmzCDLECUhJC2Z9JZqr0wjyk7CbC3dydMm0uXjx7Op0jDTBn6rEEvwU3j8EOdt
C7ixXEtyJlUKTSPeAulKHUdqFfo+BTcGNQ7pulLSSEBLHwb3LY+2zEzoa3MumOpeIMnOnKIovvsZ
6tH1jnkmx1l1xcUktbwFdbN5Ygyt6NkgnKNGPJVH8z3nSoFXiuqSpVhk2Ddj1j7HaEhSJdeGvDlo
Hwffk1K6WosHa7Hr6RiU51KzByLX0ZaDPI+9YO9uw2GwHjAZ+OfWBJyn0HLhZwYCKZpHW6J9zppY
OGaNxxD1bZDO1QpIL44p8TiKyIDZCNXU7pA7DuMjCbyog9yRxuHg0JWxNybZcgZcpNRPJwhnImj/
GJ+KUwnu6aZzVUFfQ3hw0iyVgzcXhQ5WDbMtxWxSkG7zCEeiQlxNQdyHziZjs5WBraWrEldpwoyH
6s0d71CxJHTtIBgTI49byogKAr46p559q2014oAiokAni1Te7GQJF+QpSlcNErFSbvkL/aarnubm
DI3x0eJhhXbvTNPubmYZUhXFVioFM/UA/DNVFRhRT1ERgCJlusAXGLrF7Gy5eNOq3JiLGJIMrRQ7
OOCcFo3fU4qtiMe4CAdBdmY2zivG5JCu+gaHeGWKrWHFp8PVKUVXdVEhMgqgU0523lybrsbQx3jV
DKs4FuluS3eGqSBAEvE5+7Caq+MEUA07A/GKpmcK6I+cDPZMsLccxo2FTkdt6XDDC4Rt6Xa5Yc6n
Zm6IyH3FW4/QP2ZffbIVZ6lT4OPWpOGb00UOFQAkrea2eoA1+rd6qycleFSrJlmwIrlClTVyEvIa
COluv51z6AjPOk+jBkfrBN+DitJtjImgh1ejN6IMQs1sQLKu+qG4TZw1ZcRpcGJyk8LInItPFzlM
5c7w9lsN3hYVt4AVTJQXEWfQsiP24tq7aYDQsLAGWNRQRyuCfa3yscXs1Rve5oUDQQGmrb5ZY8wJ
P60weGtcFLO5uRKhiNbvDllsqVM4laPJMSxEzcesWCnYBD3hkbrKqx6bKzrMOHGxhZk0pkv6um+u
KRdFrrlXDJo8nVZGMY54Epu5Kto+mqujMedWckam9Q60hEUtMoidDE9NbZmwV9EbXHTD0zVrFD3N
Vc4PzVbVbRoSL1J2rq7ptMe5sGW7TPLyNz+JcSkEWdWlhIyz9Ztz+OJTZo4STSbvRGiDNYXOV4jO
Rd8J0DQ8NznyvsFTgorEDLOB2lCxMrXlEmSF9aqKL1WvS5e6Kiv3KmU4o2yqgNfKsV0/uKiN6swq
IxXysFPKTqcZcm7PUGmAlqlqTS2v+89l8Ptkvahi7bQINRWwtMaJ9znm748WnHlOSVN84m8JbmTx
/6jNdjU91s7D8WlIksjd3X3Ic76oil2VdNdjd3kLTpFhIgnk6nstx9PqMwUVmhf5tRPTfJTVcYWQ
xUEFi6nc/RYQeotFzEMYh3jRyGtEcOPnfPSSA/3SSCmzExg20RPNl7vSLole1mdJN2WE2Joe+7BK
dUHkO2MtZTt51fVzsx4Yi+6ji4Zc92+ABJ97WUwUFRl3dquZX253e+eKj6NXF9UOwu5vzJXxsFu0
ZzrWX6P9K2h0OlP2rd6RP/FsyMOTaa5vUrEcpDIoowEoh15yHef6bkEPmbnSBq6jUolOIkNkpgAz
q7XzV2+C8SnLmwZyevS3QQPPeBI3KGfNBYaH4hRPN4qNn5kybwPig8r4vmAWjDN8TvGIvLKS03Fw
zoHsLhLYetLJNEELKAqFHIejK2gyQQekU/KZ0wAoUAXGaTwOdQBYcyzRYjDaDNdSI9h/thReEgzt
aQg5UKGjfYcH8UPyHh9KanFQWXoqHUvYc/CAwr7yW5P2AfK0fxaeh3bTtWQq0IuRVCFLjEMYR6wc
Rr9MKOywtL2EzXnlI45/e1W894vvJrOLWMO5tH4WDaAQAXPc0tjDjc78hyQycBrG9Ngwe4Gdh0Fs
416S+7p4hTEOnbeaJfDt+cQ8pandxZodKvxo2aUsIikklyJF0Vq0SvY5C3LMfvXkDa4l5DiY2gl/
mQTDtLFgcLrQNMStMVp2vCUkigzFsDAPoCGOEoAbxn47EwwSVgkEsnfMrJyjxxI4Pb/ETQaIBFUC
cROSUUOY3TlY8E59/Lmrn1h0ajtMgCa8iMPi9Ht2u43xOLgisxPmd4ZhfJqdNS1xCGsk4qCdmSYe
gYPjrDZj4XppROurayr61oEPPx8/9uzJX1AD0Rsz/nZ7gUTjkOSV5GplS1wMpU12ZCM5p52Z0jCM
eyN8PX1dLsI5fZnRldKekGx1oeLdSxSZKJGjmL474ktsz1Icx6HxlBuOWLscpznJE3gvKNw4/uGx
4u/GAt35XlCPscZjtYBXvxe0gkKTQc+OrOutbor3G42SBx3Ycnha4xRE+qBFVYwu7B2jlGw28uqm
GZ2nF1frSvlBV3gKemIEMbcxHDZOO/aAJxo0pc9lBuUeSjw6juyqhcfK9JLIu6S8WTT4MNVj2zLN
Uza+0j0/wAp/G9PY8QY748dJbeipkp+khxjtm1Fmx3WTnZfbX/fkxyc/LIVP94R6d9MPMpAajZ19
42ao7IajDBWmHGHO0M4Ut8VQE08VS6pmpkUWJSknsqG13IeoW4kq4VK4WRxUp0lTxise+dUMDsTg
tOo9B7PhCs21wo4VdUsG9ulXwv8GL6jXTjvTXA31lPT72ESn0t2lYsU9f85LrY9+tpWUMx/NzCfW
crrPIE9hc8qsErFUmyKX5pE9vy8hcKcTX8NY4aFTbcBBoShXqKJIFlqXqmQfWTLahS3F0OMgOu9q
pPUWylt18hydhvKevlmrOQrRKHUzv3yTl4d4x18oYa1uWBZ05ohurpZyLd1VjEWzvKzvuGYU/Z6f
wg4unxhY2EEGVgbLiDkPVkq1bHe4L6qiO4IdAUFRi6kCXqyl6TSAAB8HQTSuGJfGlgDyNlP4RsAo
6uPeczLCXQfzT2rIZ5/+iqICzHurq/xhOa4zKqEYf2Commlq2ahU0RDZ5kY5Th87MvCbDQJ3JpJQ
CaTVbRWuMmQZ5SDfK62xBWZku3xBauTsGCynLtSvYh5H+CQELexIVDUB2TTrDYa855jn/UZQUWW3
b6hq1pL1BHdn4HNptdI/EiN8GP/Btmv7dEct1/JrTJcikSkKq67o++X9XheaYcmX0n8sXKlrX05x
upItsOn+ZYlh94tTa5tlbV+Mrp4V186rKbxA4a9wkF61046+yeQXQG5hLMOFsm4J2Q7g3Jop1Lz6
FmSF8c+mTiHnvHoDnCaStjop7n4bC6/U6+yNmTnbXSwJQrlFVV49MRr3HWoey4/UwTCAXc73of9g
TYusibwjUGzNYTHDGfg4x8L2z0erqtPpLPBZmIloSbZLLOyWXOlMK9nS3FrrJmKJjGI30gbCK72/
Cvs5AuXJ1/qj5aJmtZCCIrHgq1b4z/IjjoLwSHW76icx+uI1UHzTnmIIp0pKLBc8XGg+zCrkxVzU
yXO2IWdDDTnh3gTd7g/DAD2FxwPHW9jLMqqF/Dxp+gSIroDhmvIWt2pgIgAEsB18gA6BIonL/TVe
7azSY8n8mbSY8Yd3vZd2psc9J8irEKJrtiyzFX9jHlh+fzq81er3WWBx+VcywbXlR2VIeRmlqfZo
JbzwtUckWQRHLBNql/O2StTkqd3d5XlIcYgvZ2vgHSGIG+fpv4W1Wxp+HGME1ne94uiu9LBFELDH
gXPcTIXFjo8b1j7lhw3tw73SUvqreBXaKwXGxZTubyR43dLJXfVzV+mCgfbsi1c6xjmmI20eJY14
1Sabw0Ry/as8fh4WBa1vmZOwciTWNMIx1uxCTi5XeR/MeV/F9AvL7mTeTQ+vh8ZyHGRkNVzL2doq
evx4nWSJcyXGQVNpfQo36AF5WwpBI+R19vo1O8MKRvRI8lgp4Ph1pgHvWKQgWAvyg4uidNw33x0s
+c4QWKvHorLcDUV304FW1tMSDxK3hp1BxVtMfXCtL3A4foJmJN7oF4g2y+eAnlK61Ry4yHLwwupO
kagsLpzCVegQtHrknKvpoyU324p1xJHff3+yCygqS3JF380syVNE2vTjKtd//rYnVdFgpczQEw1W
PRvPbc6vnlbaAm94PmXg/WHsgJ/qMKhUGT/tGO90mD1sepWWc4FO/ONPs9XIG/yG0TGt6DI6gCFh
fMwye984TAWr2txXr0n8EXXuDNiNR5IzMLj4MP6CpVYOSwZ0MPHlVDPzLFpwCUEGiJoL4AEJQqND
MzghkGGazSCQSrk+dQ89dQs9ZffIG2hjXnBUyJHDIj27BcW61rckBNNehvVkMsppsQHBR5DoA96c
bcTkrolHo2nGz3O22rzfouvZDSGrlulhzphdUFy5miXKaVprcf6lgu7QzXVVs5OaQ5u74yPKeQUL
/OfGmZPYRn+w+Lb3n+kfjv9ngpf/L8T/e/olPvaTi//31eo39/H/7uLzx4j/ax4OYYjsMYgOjYMo
7ScXoZaLRvcqCQko2h6/8J4a107yQ+zW67AJAjjUCL1vkEancQA7eYlqRO2mVyDsLuXRwvr3rG9T
0xwxt+DeWFYtF9hXtHZxMj0JovHwSo2TyemZPEQcDK7kMdPgih8sA5adqiuMworvTCRjfPkNRdxk
mKWqjS6q74NU9RFn4QCD3gN+cIroOTX0n0QRNg5PwjFF0ePQS3V+cE0Ng/h0ArPuBiNGKYZuYOeE
C3rGDYGcnklsPYMrdzRUDIaEb7DiM27o2Hp85eA9iimmIRIKR5WH2eRH7K46GAnvO4k2TMyJwg2n
+BABxiJO1VKjXhV5dXYY4Mqqt6o0M8hvZc2pMX2rO6nj9rI4/7jovdWt2Fi9N28lH0MXVYoZ7UmE
3jlamx6ntxrZ1QF552+0MixvHd9bWVtTGyagJj+2DSswHJiA48AjxPsAijaIktEb+bEQNcXgVsEx
cLRmvXEN5L5NHsvhgJtLr1UdKP96k+1rBVrf/mUScERnZ/pgYIaubchnGMhokr1IxuceBaN+7EwG
1t1L4r3wFOBehLbcAQZv81J64SnymE3YgyKqqGoPvg3dMlNiIl+zqm5XBUHAsiB3g6GAh+yfiEXA
l33godDRs63wIuqH1zgBgFbErBEX5NmOZznE+gGfWKAOGxvgQsZeQs+ktMULHb+LnIA9BhITPuTZ
aGghphrIQNsJtM3PWUANEDIKH+45ow2ihkAG+1qtgRxcUSG9EhR00X0xjZ9yo5wC9GMfOF/C6DKj
RC4rT2voo87GIOFeYn+j+CQx0leXgDIYFC/IFIHmE9F/B/9+uKAa/YClNVZ0O0v45JEV4sTWZzUr
jTIaORZ/vqW69B23zgozB6W5J7HketmQX8AaQkK8wb+UIm/syMDjaGjGvSDPA8hslWO2ZsaHe2+y
52CqRaW0t8B4pL02lMhhrhPgC+sB0XFa0ungkv81k13sbzBaln7jy0vzdR23jyuKsCct0HtjzK4O
Nja76sc0pO0gNky0qFcIP/ZOybCjrasFtDA5z8ATNB2gkSxSRoSDBrRQl1knhRGD6obH4wAaOMUI
I7S2SKBzduP6FNhdfHGtFujR4IWmU0KqNvpJjAEtYsTpEl/+kOoLy6Clwn+gSSxL8eUF2NMv8FtT
DAxDSJIowhdujuXFGindNF+oxBIdmuFLUIQqQUiOnshEgIDLp0w/MgazhXZExedXFpq8djQfMJh6
mfU8GMO+BJAPhAhH5M+CwyMd7dXopmXMUT/JxMdvdLLOsUbxMaZ6CcfyGVbFGOQsz/CkSpam62dq
AV+m66p/Bxh7G/tA33ewH/gNF15pFwnKiIwoQIojCj8N1Ia7jY1LVhRYDHLtxnkwwqtYS9c4HGgK
xjNBigbhK5BlwSGZUOGxWsKnkkiOSKvCH5jp1w1WbTESNGbKb4BDzQcEkQaMIJPFjW63MNXeHgmn
G7LpOT4KhI0bNxykHnKRGohFk9FbM3dh7Flwyg+nNX2BcKLN7CKDRKI0YLMJuy10Jkizkdwha5bk
o3E3JYVgxFJDF9VVvUQHwnP2eiHeBJ3reHKIHwKj4LDCzZnROOmlFIJXyWok1Uuog4U+whJqs9BM
Axp/8UBQiY200W+iHcYXTbcKASI4uovzSTnqRsV6upUgM8LCEkpHWIZsyR7RxboUGqN+PCJCKKWd
NlYHnoL034ZabREh9A/0kzpv+H4BrlOpmvbWsPIJr4QMYwK3+6gCPjK/HwF6KJL++CIUci2nCiGZ
2Rqf0fekRoGYPCVQwy0hE7f+jWhFg3QIpqL3mmpM9zXap6iVzoL2CGcG2ZTzD6GBkVa5Z3OT28yo
7q/QltuIgymZulnM4QYUUMJJ/Mn/bOxBRFxOR9F9zP00Xb6J/jwT1mdhOy94S+lb19ryyoU2rr0P
hu/CcafTqWueNMQHPYH8hBtpUnSQCygFSXmeGd0QNygZsDdK5Gq1RgPf7kYhw6lLsNPl5yeu6bkh
A69tnqVAuI3+QGo0S4Hs0GMQeRDyRMQ8AMTEkQMgL1zO1YMY3fM+AgDIxDA6jfMQTjh5LhBbZIzN
Q2AT7ZwA2EhTgEDJc4HYDc6PB0EewpBS5wIAmsZ5oX4fE+ecSDTxFOcBU+cCQGawXHW6JT9P5Y1B
oWl0sp0PccfhsIg3SJyvZbK15dvGxLmqH4a4/+tnR0kexlhy5qXAYDIsrKMBJ8+3kE4Ky/hkropH
0NF8VXrLdJ7KPwRpvi4+RThP1b2k0CxeH5pr0oqUGsxJpvvjfE103J6j4sE4xLVQnOgRZ9wdkN0o
EytlnuolHsWcQLRFdH4oGZU0W+EfY3pziJ+3YKHJgqyGcTTweH9pMtLVS2SflVUkBI32RTE2Qdvg
FJSArEzJttnRTLiPwZhLahvdNGHIBcu7I1LH70xlY2UQRHJWQGjjLQBCloAaTIOlJZgHrFyJMIxi
nrJ6fucpK/zfHw+op49AR4GybZzb3AQ0UOqZDBihLse5F1BWp0s5vRepQhRUyRcozEVZ5w0H9rs/
FxUVcwdT29Lrd0ZTdmBYEGVcm6w5l8z3lgRMs7o7U2iorF/IjOfu01Q83LBhkiAfsZJQFHxE9aAw
F5VMYSocNPx8AjDI0fJrCDeYhCQX48D72qNgnHkIhmS0A9sMh2/QujAM0xTDOuWEnoV8CpNLlnbt
Hn5qbX2EUwqiItv2jUmmLi2VcjPUvMswFofvgR3IrlytrTW4bHt4BgwTAaBLpYdSa8lw9mKFAjcW
LbyAHf1YeuYYk/01Us62eYPgj3R6Z/URVnADtiLtyFGgv3RL8UPiAHOCoHx5kYJctTIot01bbVOi
EgqXm2uRMSBVJtN4n1RGMQWCqNFt8/wCI2RRMVATCvgxxEdUkZv5chokR+bmrPVEpYoLxk6otIm/
yxaWzobuVBEZ74Vm8NKpmgjvIqumiHLnmG2nnA9KbB6+xkdKK5lBcurFTeRXcS9s++lpg1ZD1rXz
u3qmAFxIXNNXPmqlM1wmMhGCttGWd65AXpyK7XFlXsa1vD4LNKxsTxkg8cqZPLJyAGUYnbfbtgPl
/ZVDQIV2A/Kb5ldyO2w8yxMPWRLKlrdZkAWmh1Waef5uJKUzKtpgTFmCBfme32WQ3bKcsLD58tGU
rYS5Nz4WQjvC8+5Z+6CpPaxAtwOeeonfCjZKTqxV4o3yvQ0opUyxX5Z0lYGUQqm2vxCcohFmCqyi
BYVguGaUKbVLDUkaF3mLkoWTeRUcnJXyUH9QsxT72URya/VeY+b3q9WWjf7jlNxpEOcrXVCBi9sm
n2CK7AE3NngCb+hPS6v2s2s7riqAOTHtcpf6vDUdeeRO16yq5UyaCjRnm2aqIN65FlGJlbtUJ6Zr
+dM1jcq5mUPlQI6RVzqKAzUnAZVMSWOsWrGoQHN5N3KqD1f5SNVnKj3cGKG2S1WY1OrQxmDgaEMl
e6ZB3rBRqdLMNplBe7LXxrTUcTArw1p6WTyivCw5oLzMHUeVQcONnViXL/MW6sviahFydIpbL6op
c4yFZb7m6ITLeaqLCxYM1gUFvqI2q0tq7i7RJMHUReMkRpJQ9TW1jYInJVtqhH4HqdJ8QF49gzIc
J1ynYzxrJMEWXbxoqTDr141e6p3ui+MeY5z+Ll0/vEb9Bh0cd6NjnBFSmNkxQgNxCJ7J04LhzafL
q5r0x6/ssrMGbyDoh4WDYs8F4teXh+OwKlWJgc2slpRz2zAFVyoKkrt8wzFCe2KGRqLJn9+YVWLf
HjNAlQmtFgDq/hIMBK7n+kcK0IOOcdVSsFz00YrkxBo7TWD5djJuI+acvbmz2DTPvpH2avZBRTiz
T4FtZebZdskU+ztdDFfsZ6rUh4/ab02zkRekQeVGy/HfdYdaur2ifvHmwnBYl4hMHZcBk6apZ8E9
hLP7MLaM/1KyJs3pg1Fm0Qif936zuej8zuOw8N3jwcMQ49mgz8y/A7wQFit9SiLN4oGh3kAaZQ27
x+KsvJOsMX6mPiIw6CfT+5ReXkcp3qvfP8HQb9cyDz5kEOQCFv5r/Dto0t2Gwnhoxqzl1RF31+xX
jzdUrt0No7iDG2pyh9jgnmhmRMCvF8Pc9R3SNcyNanu37X/vUjXf/30JgqhDXz/HBeDp938h6ck3
+fu/X688ub//exefz3//d1UhdSF3uOXlX7xhyhdp6W97HA7pYut4ggoYViTvzo5S+2N1Bmw3SziV
/ySsjZ1MMERaS10kw476slO4IIzLEaATUFye9Qeq/aituw5f6/XoBBnjInrnRyO12Hi5v7XdbLZ2
9naOmvWN3d23G7tb+4dvNw7e4lWFnuqu16GR6KSy5oudvY3dJrR0SEPBG8P8YEnuqjN25kekP36r
BHTK9CyZDOlBIXJwP0mGw+Q93XgDXRbfiRyF/egEA2JoTRVAKGCvb/nmzttBNO4yp97Sl271Qyhc
AnoyCHUleUblbUJhItKu2oihOP9Q4/CXCcAYQC+hPN5nbD/Dy074c7HxPhjHPJyhwgtQOJ4uoKCI
L2COpcld9RCgdYHLfxf2zxL1/fae2jhAGAAM6ejhMmD2LIQGkCOTR+rid9iDJnSmpRb/0cQeFcsg
z2eQC1MALNhC/zDfZ7cJJUEJgVY9nDeX19RrkDSgz7RPoEYnOx9xCk83Fc9hu4n5tfZJMFrnCjcZ
OQ4RY1+28cLU8uvGq/azjfb/BO1fn7T/9Pr1m9ePXzeXr1+vXC+fLqlvpUMKkPWdns3RspnRBJIM
Jd6cArtMTclbeWnnLfYXiJDe4Oa43JiMy/c41C/3DFRwiqIz6+RrnwyDU6Ck51SOr5xTktQf4Q2S
gVxu19DGeSDHSZLB967pBCYgTxiZ7uhHjDi8KC4+nZPEdcTHEabhbfcU77f3TagCBTrAKKGSusZZ
Mhzoe6kD152Zlx4AY+zJe1EOM2AkgF4BbK6XQF/Po9OzTPUpmjhxhKj/Tp6Tigb8ChKAwzNuvT71
TT3dGcwD2qF0jGPEa5NjDdhy2DsoCbB0QAEgBzsy9uH3H5HKwhHMAJBDnbji5o87u0dvN/aRIRrS
bWMMgkV0IccnHjL1sAVccWeruRwky7DcE/i5t481t7Am8EpaBKJcCpvAdDMB+NxUDK1G4QVQ25VK
of01DJ+AQQ/ikOdwgu9gqbMgPaNrA0ZSRIgrwFIffcgBwbAYYceenqlBEqbxUgZVLszTXCDB0pBi
Iiyl+PbXMbU3StI0YpgA6zwZ4HtX+NJY51/BRSCPVyGSxjRxFAUWgJydn7dkLjEgEU4bncPpIb49
enmwu7OJXFAQBAsUY1I9xCkzidQQiXDNoV5uH36/jfmgWWMoq8XvmmoBRBAQKpAHcoYFw6IQxBoZ
x5ATKeowQqRQYciT/DXbdLqC/AZnxplKv5/F2m+p6y2YcoeRcRJ2i9ghzOuv+OnWMY4UKNXpOneQ
uoiCMkKyNfXnbRMaWAMCAhgwGzUL0bSysLgoX9XiImw3YTiLUXNhTcphFIs1p15ZNYPxXOc0ZTPy
aZh6YN6YFhs0gQZi0zZu+3uSTOLB+pM1+3usoDADwFprijO4Ei0e2HS/Aim2GC2odS6l3qg1ziN+
w0BX1qT8SbRW00D0sF/XBc7iIpUGSE8QipI8gmNK1jRyBKHRgsBm0HmUwi8aOsofk+8ghscFMycI
itQzKkrBRYBkOlvbu9tH22/3995uHx7uHxo9wy6j+oPOzt7R9uHL7a2djaPtshKy9gzbsktPZtD9
3eGZNtRHv/Ua3GAOpgBut2wZbe8eQfojhTE0sYBZm7gy6TAPlQRH2D/CO+T8rxXvDWj3XXi1XkL1
i4+IzMwihx6vmdmBbc8cCwfbGipmDMh6ZVHMUW2Ilp3VZ8uD8GIZ7Qq5rmjNh3UrVn9I0fm7y14o
ZVdZ1bmkLdCiX4I6vb64yJgQhpTXFYwelajpSF0AAiRRRqNIThX1MzpRv6dOIul7nVx99l8r1FFa
gvikGvSbbrHjhLlF1+QZNxDeTXzz+rvzC3dCsY3EIXH6DaVAZ52PWqoXol1TrBps7Rz2MO6vacxp
ASU7/OdcXsYAUqJwyC3URO+PzCre7R04CxYqLD+kal1/CbsFcMkiJ8e5bb/Awu1DJz+PCVXadS64
/+NREzGj932OqcfuLeu/pxB6Jv5bm7b1bX79JT37lHagGfaflZWvvs7Zf75Z/frpvf3nLj5/APvP
YYBPwwJHiy7w6Qbe73KHSqw4UPY9bLNCUrDZkPPF8nEUL6dnwE02xrhnfE9PxOI5Xb1ON4kXVzAa
GehbIE+HIIFXMZSIDiPyiEKIqGt1SYeJp2PY3iz9o8lG4iVID96/U0u/8fXbxacfljCuQp/DecHu
aV6Q7W2A+lrAvnqdqTePBchVRSO4Vs9hr3+bBnIgTxoLD9Mu/Pc6XmgtPm0tftmkJtBEwgL6b4Cz
P/8Z9gzhZZSp1XqYBv26HyE0h/rfE5u7/1R8mP8z1z9/91nCf87g/ytfP3lq+P+XX3/zFdr/v1y5
j/95J58/AP+/G/v/EYeKi/pqgvF5tNVPDIdkueFIU9p8Ri+Vy7Mmqo3fQ4zoVtfd49K0stbwPXLx
91nFcqlC4dPVYw1jQCHGxwBE0Mnhq1f4stCbN4p8P0z4QHrC3QgWfun8lfOs+RsxKuIbRh0XFAAB
YPskR4MpIBkrTnc4vGeY4UF2qlJ8Lp1aFayiBfhYD22AocG1sRGtaNE5Huai3xQWr4/NIQcIoOAd
avQAVltngemEgkJ5ghD07Fh6S2bOqgfoB4Woq/GVGkVhn6x1EnwsHtSZhvBYg+2kaAuEUWC08Ax3
TGyee/WKQ4iJWoyuBYA6NzJpLwzrr16ZkMmQi40OwiyIhuaEBnr/6pUx/0EZp/dkVcuoAwPvlay+
G7cwe58QKaZ1CggJANG5AN+MBNLAEtB3osEhmowx5FMSnwK+KZaqhptplPK2ieZOjKF118ieJach
UUcDGptk6k9PHurjIH4hEu2dsUowqDoNAecWLZz8mlWrDgRONlJae/GErK40zWKdDvF4HytOjtEN
F/FzJCbRCEYO1ck2i2hfSpX4M8E2GU0iCPQkGlNwfVpD2K0wTWF4qBAivDrOtBA1W7BxEY4VnsYP
h1F6RlFx0R2GDeZAGiMJVJt2YEf3Au+iXwZIhi0gASesJk+d2zxawF+fJEkWJ1n42x78ge4vjdE+
PLyqE/rDNGN7O3uGcjvAJIiLcJxdugplY+xiI+j/oFhxI3YJOBIGcRGOjwEIcF2nZ13lhI3llWvL
1f8WahQwLmkaCAMUQ/iMn3h4B0yo2IhU8dqiuLEM4Dd8p019KDSJvGLBzMsCTQwtQR5slPLE0V1v
e2yojq8cbdmEE9Tk7FEyLVwkJzxiwNjCRGqAWDTN441bIGtAeTQIMah+/8ywOaZ5IjUkDs7EMG+n
CcXDx3DLOjIypApHrdf3KUAyNYnP79HihB9ob2whSeFTTyk9CeAsyJTCnup1GWZ15zm61W9Mnxqv
Xu3sHb15gwTX+/5w/8cD/r6x+/325uEGEB4HgCZx0mzhGD1IKhyyrypCerGzvbvF9bd2fjrc2fv+
zZsmATAEjz1MadDHCEhWfhQbDA+vOrSDgsmyx+BkLT3o/V1Ob/Y3/7u5vNiA303aVXHk5vQqrW9t
bPS2yUZIBaGeGHlQHTAn4mjljIaDfjAeSKHcnqVp6xz9/UDXcQ4XvDoPqU4LT4/8pvBkCA/m325t
v+g5nYJeO+HI6893//r2aP9gd/un7V0sElzCLOOBpyNV6/WDjZcHP+xuH8koHmtQRgZUlvAaqyoE
LY2Dtyhp0GZaWQzhvLXvqFV3K0iX9Timl5lviDnLkPVmOInTt1HcH04GSJ8rZDln65244mmznzMt
2l4mdvOKJmrfAceuyiWKZjB0UtCBIlADDdOQgW9MtqOTdv8siE/DQYvz4R/bPeA28/Tutt1zmNnH
9FJ295+rlwL+o7oIxYgg3+r9oz2kFAowvhNli5otOe5xgnbhvCYdiQzxH9MtAO31Sia+2KnnG0dV
fZI6t+yR9v/hVaKq8FZZQEbgMFLHu6j8/Bwt3sHIZYiEcnI9RJcObVEvUZy9B9IlqCb6fJC9e/vg
7e5O74h4A0YwxwSC/BYL53qDpxQLfo8WoEsuu4UOIQgaTBWIwphKAGyC2MGzlUogD8vrwf+7vaPq
lqnMzmETmgZEVXT+x73nRzv7exrKlDiHxp+GfGkgvxSxOOkOZkkXpN7lJtNBXUkZZhM57MyApUei
i3lDEdKhyLW0QGEMvyknsjC/ctZiJxkq9sGMzz8okfi1Wjrvv+wpqzSYEgLWFHrbOwIBVV6ok2YB
HhdNE0s+HHtA5B7f4gi8BB2/2U3T4Xcp7TVfcSmK+rx+oOzBNoM5f4eASCsQ+2oTt0iwY1InQZot
0MF2ZVFoZqQatL1qTi261MCIw+je5nVnobk0vVZZaPwFjUVQqKDVBYvUXhO9xqqBth0vE0Vq4jrU
pi/oByHBn+j3Git4rHE2+TC0Vvu2CNWiEg8jdXpyWq/Zc3O/f1MYdq6kl0An7K5zBssGpwD77+Fe
FnvriA5NP4uLEYXOZRkC/8C2/hc7ALcYHoqTg4Q9ks1lVwHXrhqVYyyr1XJJX9LseNCnopYlaPRB
f0CRZcTGiEtYN8+ys9yRHOI6/MZx6fQ5e7dcr4eOPLA+X/6KsgDc5cmt8pHuAxHzp/YEmY/RgZU3
IZcOwU0ph3KDS3ZfGJnM6tXJ1FdWo2qRVtWYa60WKtsGOZQM7us4POvS4iM1V8NOTXkBfakBdRcf
NWfUdyAUwsXbfjhw8f7EjB7dnlV8OwWquNtW5hue8V2pzKJbnK7Pm7eYeElsouRjlUk1dsgu9g6o
rAwcGvCMQtfbFsmvE3f2nu+CtDZ6ycbPT3DhvPxLz2q4mOs8qd3FFVvwBCxo1W5lLb8KolE5g0a1
hqWrm4jtSqoAKGxha+40Ijchl8J2f6T+OXo/+Cc7F5Ku4DIgsyFFflbReUfui3DQrMHvAmq7Zchy
nSZzWKzYZtfoGEEESiFbAaR12UNJ6jrNHb7Usq7dqLcvwvEV29xCYjqlZMaG+jLK0MmGNtCmnaeO
imEhHrQTvteQP3SnVQDIzvjlhT+K2vLNiC9aKXn5eflpnI/I+kkch320xgrWcg7Ihf1evplmq6gx
k9sxTKt17wVR6LjgPqg0p5gaPMv7Px4+L802B7GGii34br6wq8wCVjCpr9oaN/nSTf/M3hr77s/r
/wM/fNDl885P7QUwy//rSeH+39dfffX1/fn/XXz+AOf/W66ZCu8Jj/CexgAPj4/p/UxQlEGNyx/o
b6iT8L1v48Lj3vOI7gW9RyfZNAzGfZLKbT7kIdUVR0PnddlZeM5HxVd1rEqOtSWN47u5ePqlAcjV
KLl7cpqo4H1wZa7VQHKaxGxvO+P+eK8bQFtxMLxK6Qz9h+R9CLpDS43xzs/7gC6jHE/GMd+WVoPg
qgNc/Oz8HNn55v6B6h3h4U+9t/2z/uqyeyp4z+jvP/rD/D+n1H5iATCL/69+k/f//fqbp/f+v3fy
+QPw/5z/77lAk0N8fFzH9cQy2fQuQf8sCVPxMaK324qOXzvxRfKO3BD4iNxAYHeJoncEbwj1Zg9d
IWivh9f28h4RFOMBOe8D9QP0By+CZtkwzI+BYkC5vWSvCWmCthqFS7dLkrtEA13CLiy12HUizIyw
weQoltux2OA4xIu5+HQrnfbnzp1gP8RQm94GEg2KfDrG9wExQH7QP6MoF63Fht7P2dpNJ3XnaPul
kwVfTZhFgNsVm/NiA72vyQrHL696YouweC+2PsOH+X+QLn/GNojvf/VVFf8ndsn8f/XpN6srwP9X
vwSRoL76jH0yn/9w/m/mP8iAwR53gvTT+4DPkP+rX3/zZV7+AwXcy/+7+Mwp/2+vAoBsNpR1BrK6
UglQ/6X2Nr6f5QqOznfkhZm6fjb9ZIyCLeGH4rJEe/1Sy5MMnYkL28P4ih49tmW0dD0O0WdZx46Q
TR15xh1fwUYuOSlcMWp/yk/d/LGY6yq1ofvpOI2KS7G4TG647ukdC+bT9kw9T0ZXHMMA/T330FU8
6oNetjHEycjOzlP1/TiB/fFudB6h4XXlT39aaeHfVfr7lP5+2fnEfavLC0B0M1SHTFwDBQdfucun
1s+D/jhRv9VrFq0/q/V19XNXaY9a/IkK4FodqcUUi6PhmvMTnz6EyQjdtGB8HGU4CfhGH558eZmj
0Ti5jM4Dvw67wF+6SelZgDFVXk4oVoVXOIiTGJHuJsYJeXBHQewVhebHfkF0y43QNLGP3tzhoBdm
pb0/GIf9CEO7lTadPh8mQHx+D/4nHCdboKaDnpi6OUQvPwKeAKybPgxPypJh+UWoov4UDCeku7qZ
5BP/F3z+qrRfCG4PY8F5Yz6fDLNoNIQClXB5HjdOT8fhaW5yZCaGVyVzsTcZDnu/TIKxl/rfQT85
jnbQqzbKrnITfQ5QsBuNo67CMHbNNUfVLecxZXeGP4n2a+W/9Qa9W/vv06+fgm6Yk/9ffr16L//v
4nMX8t9SlhX+IOpb6obXwBzZz/IdL6GQC7xcsEDfxSSjf9NscnJSGuVNevNZ5bYdcVdt6wiZKQcB
4rNrEkj3UhvAKWs4Z6yldENFEEMesmQsZxeTId0TYnH+887+y/bPuxiD6XQcnOOdolspAUo+eEn6
EsX+pfpOPTQxUw/D0ZopMwoxagqUGUMZyDGlHgLA2maU1SBvMwHOjXK41svGmMCvRuLvHfpJF0Tk
FUhIpUT7c2+PEvaSeA9FEUgKm3dAWQdJGvnpmyDTqOlJBJIuRgkXYvLGeOwkw6/gCrux/T31Izw9
J/Wk9uPejqSB/LwAThcMTSYsG7kQ5PVbdeU2UL0WcUoXiIdfOGw/Y3z0k3Dcxxhvuo7OeNxVjYct
9bApKbV2PuFRLqFeWwc4NglQDaX+vd7Np9Vrz4qJtW9L0p6VAPy2mFav/QpqzZ+7QBKmmDgiEUUx
7riPK13q/BP65wPSCV5/BBQhqayvP1O9HcJ3kCKNNC6blHhpqMhSjkvJLwM8pQpbQkcth1akGLRQ
Q9AHwwmwnAZ+bVFbNAxplEq8jOJZRY6i87CyiJTZ/mtXL4l8ORyDBrW3PVcxjIM0T7HZ0IDCjxJM
5ZIN+N1U5EKYH8FKt1ZrFMb+JJdqsdYtKf0yuOzmi28iBrkL9L2A3WST8nqStyl5mzxAaH6Thrbp
Da1Wq9c+MDXIWsbGZOE1hmbpYbRMJDvkUwYXjaEhMMQH1mwEXaTxx6pxjF9srYYmowayw6BFXPG4
CZV0nXZ5HSKsykqPyisRqRUqmVrrylSDdUfLiRcOk2Bla/9en1Jvb7uy3rfT2ts9qq43rb3d6vae
FdqLk6wRfLt+7BYqAOdCx4Qp2GA2IKf2EEi8JhNP5N1AEMi5ILuQ+4RymV+pQq0nuVQqLWywEftd
gTniRiy/xyLCofR8/waCvlaLYzxGsNHImfQxB4NrMcagDGDTLpSGrLNGs8n3GV3UukWiuNGkmYjj
pqKzeoJcQ1KzaxLg4wRgDnniUZFwPAYFY0ELqSxJ1HF0yteO5aDdE30LaxwFrxHDDBr6pz52uxoK
QIShuMvDzW5ymK76bVunzpeMzsMtkdoHYB1WhN9AeLe74nv9UMvkx8idcmI7n/Iol1Ijye2maUFb
klZW8FlZWklBo20gm9W9MUm+AmLTaWxWnPrpD2WBwfISLo/joXXQtSlaP8BKTm88VaBe+2WS5FWc
cXheUHLKFYsP9aImsTmnJlGqSviaA4IiVTO0ImvTlWesVqiCZHJEl9YrphTRekVpESnj6hVlclD3
dnuuYq5eMa3YLGhS7q8wh0Xx7IzwEGa0ooDWTTYrdBMBI4CscuKCf5JLnapR3FJf2CzXF9osjJzS
lmhQvDWC5gy9QtPRTfQKQ1g30SsMqd1Cr9i8pV6xWa5XzFYsNm+pWGx+dsUCduZpGIIklrj0vJPb
YXVWc0qFsr6301R5vY7pyIqjnhZHul5U0BEiPxe7pbl2ee5DWbOca1Qhn0Q9PcjPKlOCbJUnZaW1
EnTpoe3SU4IawOqbhOKWKqNN4CKyYmjiGjBxNCkgDqZVA95SUs1K9qK5wBHyvlzr7ayVScuCWPQE
qCcQ89LPTciJvsq98u9cm5hLYJcJ5p385pxGTlYkT+pu/Lz7ti2Fd1Jn+rqutsJdFFb+IhmH0WkM
zDsd2flSrJMrXIm0ikHL7HadSc6vUi7wsAwCAUB2EufWqllY2HV3YMa2hRpx5ZhUxCo5q6wqclRY
0X/3MERLACwobsemkmi8gADLkUyMjgJf2tvbMWwAaVhWLyU4m6FijssBVnJr/wnxCG/vo9c9JxK2
Zgg/XriQIyt3qgCTwo+KhXMiUpds65I4qTXsbqWckxrri5rEpOpUWSWVvrWFq+WMlH1WLFuUZRru
ehFuVdln626Hp3BaKQ8lXDRO4bFSAUq4Fc6TwU0qWHacM9F+Jl7sFwL6d4vBz6pdjGXS/5e5cw1m
77MxbD3B/uby98KuRbXSIG7AtPW45ubYI1PB49b5riI1msG4lEodhgTT2UiPt2Z0ulkc+573/ufw
3oDKHbvMFhZY1uiJN4XhtHpP/8Djj/a0D8+5wi+6xtZTQ/dmZDaNXkv1NLfxzDNyzz0ZS63v9W/V
g/rH46D/LgQQTnKpZaeXY7xLFF9wKZ+KcQQLifhiYSHxAs/7lrwjJz1OPuVkXqcO1vLpvH86DPvJ
eNCgbgDvwR0GfjnEcBCkeX3xBfzAoBJ8c6ofpP0AfeSYqeiwcugOBczB+qSRY14/48CRHZ/BQisy
7pYMtWX4kumlPh8eJnhazafn6hS4DYYuVZM4C05P8TpWjB7uyYlbj8fEIU73omHH5B0UKER/4mj4
564xeRoTWkmxUYbvpz0s5sFwOe9QZj5fgKaqq9s4tAVK5k5/yi14rmyqHWSocEfDroJvroELcygd
Piz+IQEz8uahfKNMIIZysvGiaXpa/7zjchexqjESrsJ4JS6qu01CbNQsmi+rcK83/5qF8CgbyDnK
p6QBlQ7ZakDH987BfekU6d7KCrEn/e6UWUL1UOAQ8CA8CSbDTKFI94/9XVrFXU94PsquoHvoMiPE
6zCrvrY5HGJvqIfssOAAIgh/Ruuei2aSuoh/LD60nX+gC/rH+qgtQG/Xn6wpE/aGpifE2LHd9fjx
ypqKYejOjOjpEIHMc7Tm9wvE+EPdF5vVT+IUeTwwg2HOwMjTpl6JfWv4Zo2D+9SUMb/wCGtiupLx
eyghBmMGqlUhKThUoP2JMvM8iBFEGg6RX/2TGRN6EvG0UGQnOnnBqRg2O1QAVT1njmxLD8taouUo
I0MQWMGDkIbZCwT7BYFpKcTLvN2eu88U5jLX6iH05AslrWZThlDSKnHuskZxpA1nqNgwTiS+kg0L
BxV2lsAyn6rY5iW2eblmEhpXDASA4YGH5EE3MOmLxmVLkxrqD7X3Z+hU5BDGlSZj4pi/GlhXxCcN
mKsWQKekSyzCudTyr8Q34f/LNVZyHzDSHP0WQb/jX1ABjQf0gtWlt4zeYd47UEnR2FB7J8CMcmGB
uorEug3KRq3w8IbemK4oSi/PM3P/oRnlUDqPTb069WC/cVDvynp6BpAkL0n99+RnSx5YNpIvSPUa
lxFGAO3JLNAJxRkmUC9o4TM6AkTHqdd1og+nz8wZWhQ0iFJlEjOc9zNb2EwbaGpcEifojHBqNcSf
KHx3tY4I26AeRRB2YirzhW8nYa1Y3PpQc2nXp/oj1EWbdzQZwSxzkDytSsbhe1RTeztaTcUaDzyL
Aj2kLRtn3EpiOmq4YfaFSdW1G82KE8aNccmmWGo6PLYadzixsrhB1l8JUcuugma98eAST1UeXDUX
cTf8TJ6moufncNnQurkkSXSFsc3NGqbYP5dUGTKgIkjnyTh26uMTWEwORNXimzBckV7sT7LRJHuB
T8tDZ4YrRr7bDFfQ1yqnnAapt2+8c8oNkig+4KN8in9/jN+P3ZFANowEMuxIIOlbSFljNOGPB8eI
JT2mGevYnTbcH9H889KS5fkdb5tozZBnhj7D4B6HxTVqF2aoFxvXjOI+mSBo7V1gCukB4XtOLWNV
Fx2qOYVXMehB6IKWYYOMkoXhDpnKD8P4FJY2HZpW9iT8pUGWBGAvzbJeSWht5Clxc3pfADTba0Bq
sLw2/bl185fTmzRspXHBsjonJgwuGg8umt8xxUT4W1tPakaQ2A5Fhc6wMLnoRNSbSM9z5MiRB7oH
ZMqC9Ack4i+QSxELotXfUhEZtFiVweVCmmuz08DRRVbrR65CPEqqCV4vGK+NZklt6DP068JuHH7C
mx+W8b8MYEt52TgExRnUXMv4PQ4pum/L2s2Y2x5qlqnKy7VgR6HL/RIOsznA/QLwoCRw4RkAy7xH
yzkysvv0sOgCgtsQEc08F+feXCAwbd05b3Yii0JuRbbcYX81jXA+7HFtYcPQuGyvOLNoBJBtEWbx
X3yKdMin2IcNbLTB4IEGzNd/gfJWEyrIVydSONRAfkP3qQYV9GG1LKxWjjRYM5R1hFN22y7amfy8
vYR+9uhe4g/BRSg+2Wa5A/PGOa/XCpIJjR6cuIGPIgdxLzyP2MMf5sZkynsO/un+Gu5r5akN05QW
7I4Klb8ph5Q6Q+MxC87a4613OQ9OmRZcJzUQvlOxoL3pCv3Fdl3lZi5nqPncb4oONu22rBoxWztL
RBwLzDQbM4Cpo30U5qk0L0ZwQJp5iI1vmLyn7fZZdHpGX4Cnj39FwndMSlbZIwto/sICHsXu723T
kx6JostxsCvA72F8EY2TGHvTPg/5AQzqWwq1sAr2xIih/9k+3KcU6z0BS4U0qOMrOjqwpwK/EaNK
gVFhf2k/saZS1MwAf++1SaCnNEsDAYFPgONeAEZq8202ptOYAeClLrDjFKCWuFO0FVedDil4PcdM
geaJ4xZi4w2V9CycjqiFSbksFdbenq42xC6iFgMYZS3gTFKwt5IE/ZJE6Xqz2+1xzolJQnM94Vef
4hgt7FsA5gl6LepZ6xI9bAjbU4DFSR9oA4aPybotfFvRwLMbN/BBqxRWcOcvonwEX/itijFQg3fE
G27OGT4vX0CdBHhDX81kDsIbdIXVsgrFcsx0fkTDfGMSHw8GeJzQX4XVIl+n8Buf08jjPaEZ7lI/
oUt+8ogN2nKTY9DYNY+Zg8lUr2dY0MctXM5ob3QKdmvKK2SKIIcJ0h+inFXS8hFFb4zCsKnpArOi
FZIrydtAYkLwSzMyKdUhdOrED4wked9piK6byWDSD+kdIzLXnaenuGzjsN+Zwg0RJHNEYYkeR5yj
k1in2Eud+sGaApC1px5rrwD+Wx48so10DVTcD6Xt6Gy96f9IXuz2iBqhPtUNAyubDUIdbb0KvTNM
unYL3vvBFQWFGcv1yO1PrjuFzgg//+wCIycv1CcUGF6kKHO99z5c1Dwf5/4/e9V9hidgZ7z/+vRp
4f3vr7756v791zv53Mn9f6asO7j8z3caSqL9HA+Dsw5f/4dC9LDdp73Ibv6Y4XbVi0ncp8h7bsQe
VGY42uD97f85b/+DQnOBTzrK9KIJ/RyjIaIZg0I2IpwTQbZ2C0bNEINBEaC2FuwD1Qku+THU+2gB
nytagN0wkWchKaGwParxuMgSun2JfpLlbpJUnswAXAHVRCyPeLQAQdGri8Nhzb3PpOxFxnU6IkSa
1SMSvwkkq47CmJr8Hm+GrxkPgizg/FTCcprrl/KgJ75F26m7ONM7Ud5C5toKEH26rSdtfO6Cn9u8
BHAGDiHZ2dHy2Z69wTjzWI8N3vmTPbIilh3u5f1ZqZd7uUadrF70q++r7OQdhielfXGrh1lVr6q8
ZAEDtZwHrNdTOg55UDNOA+xF6/eYfEAYWzX3LIFO5n4i2siPBL0H2I0fUVkrnEBw3+0phDdGqgzF
PBdwoXc7tyklAD78q7bTpkdKHiU9qetXrcIht6RyC8PiMgdWeUcmvavz42R4s35PaZCzGsPmooyh
+/AmQUXyIy7xgi9cyM1fUUKDmb3TWxuE3s9h+EuJ33k6ijJdquqE3LW7VE6cOz70wssPiMvjGE5i
v7AzAi4E4yqUKRSCweaLPPRLwPhnlBiGhVZy6OFyiCQOdeFgqoooK9j1w1qRKj2aGJpZr1mTcE2H
M4g1BSAiKMPAK8Ep9Q/QWCxcxC2VBWzWjA/7Q1s8j2XiSoDY0sJ5hFNhIDvNZRzPCFMnNwXIYa6a
QpeW+TWathU9Gcj85rnxfxs2NIWOp8/6HLzIme85rzXO4BEqd+1/2gg/5iLe7JskjmfzVISYC9pN
fUkgd/Gj6m7HZ716N8+tps8xFTe+YnOTibjNPNx4Gj7RZRo7AVvJ5HgYvhgmQWZxf0I/b6VWuPDm
XNDU2hzL2QHtL+mP7j1P4VEi3XY3FtMYUdn9pxmD8VoSTcYfDLshmVCezopgRyRPdxa3oq6rMx/l
L4cclesacuCS/ioaKe1U2IujWaRzOnBiT6hG5inKaAjOmp30V9sfKqE1ZBiIud8E5bgd7Wtjj5yO
8vdvSs/nCm6MxoUxGiJmcAbozonG0hq6BdvfvObilNwd/UAp6MPmaT/sH6prMpfIHFhycxC0e2pS
PHB6rm8kOZJ2a5U3BvOECKM4iUtUsH4wdkckiYMSRatscJI1Hg2DfqB3T00fGGUOCjcypVuT4TCH
iIo1UeFI514sIV3aGSBrz3YYrD4X1ENpEMm+/umdil1/4ijv9VdwsouaVV6M1s0vahqPxkj73WlP
txq2IzfQD0PxjAnkrgBfPOIlkIzopVlthQpPTqJ+hG86dZjka6wWGvZC9ENqJpGkvdnQs2WAlujY
f+xdfXjoFBhwARwRF+iJRulyMhqv0SH1GrD6p7lo4NCeW37MVwQcfdWFzuRoystihN40qwbMq9W5
ywFarS2GBEyDyl34kEL+ZY/CERCZeD9XxOT/Wx9z/nMexdF50D+78/jPT1bhRyH+88qT+/Ofu/jc
wfmPQ1nVjz+8vunrDygrdBZeVURnHTK2tvhRhOMrNQywDTH250+EgFFgrGhkGTc6BigvXN+8ykJS
037Gb2t4qe+LL9QeH/Zg3OcoDc6Po9MJ9Klef/z4sfqneBgt6fONVA8Dtv4X4VAOP+iQw4iVTl1q
WRULz1CwZL2GBwk6kBkmoUUfOpNL+mFHByAzSb1i0mYx6flZMM5XBL04l7RVTNK3T50kUFrzSaDf
5pMOskKpv4EO7IN3/aQFA5hhbPIaB36iYMFP7JUlbpYkGmTkUgUfPoCtkkSDFL+ooMVPFMT4iYKa
HFDBjp+KxO7KRyb7e/eI+8//c+R/mk0+z+tPs+X/6jf59x+++npl5V7+38XndyL/W/970v+zOYLI
igJ+3INvErtiua/dj12nEP0Y8H+4O8jtnnBC7G5xYBD9hpN3KI83aGwR423hpO3E5sKnk1rmUeFk
F7wqnLycy4abI4ZHJ2l/FMYvg+xsK7yI+qDQuHnbv/BDRc5TQU4u3d8szRF3jM2IXkQrL5P33Sgv
JRennaeKepPj1Lno23hubwK11BYjH22A7vWg5xXRz7bIsEGrslvbcu4E3Sssd/Mpef8RX+n7pGrA
7Pcf8/6f30Divfy/i8/v6P1HitN0/wLk/QuQt+zb/QuQ9y9A3r8Aef+5/9x/7j/3n/vP/ef+c/+5
/9x/7j/3n/vP/ef+c/+5/9x/7j/3n/vP/ec//vP/Aaut690A4AEA

\start
Date: Wed, 24 Aug 2005 13:34:48 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#200 display of TwoDimensionalArray of type Union(...) is not properly formatted] 

I debugged this a little but hit a wall. In 'ARR2CAT' you find the appropriate conversion operation::

    if R has CoercibleTo(OutputForm) then

      coerce(m:%) ==
        l : List List OutputForm
        l := [[qelt(m,i,j) :: OutputForm _
                  for j in minColIndex(m)..maxColIndex(m)] _
                  for i in minRowIndex(m)..maxRowIndex(m)]
        matrix l

which really looks alright. Note also, that 
\begin{axiom}
  Union(INT, FLOAT) has KOERCE OUTFORM
\end{axiom}

and the operation is not overridden in 'ARRAY2' or 'IIARRAY2'. But the miracle is, inserting a 'print("hi")$Lisp' in the above operation shows that it actually doesn't get invoked. Somehow it seems to me that rather the following function from 'HOAGG' gets invoked::

       coerce(x:%):OutputForm ==
         bracket
            commaSeparate [a::OutputForm for a in parts x]$List(OutputForm)

which can be seen by looking at:
\begin{axiom}
n:TwoDimensionalArray Union(Integer, Float):=new(2,2,0)
n::OUTFORM::SEX
\end{axiom}

\start
Date: Wed, 24 Aug 2005 14:43:33 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package question - part 2

--- William Sit wrote:

> Let's be clear. You are requesting a reverse dimensional analysis 
> in essence. Given a rational expression in the dimensions (basic 
> or derived), you want to give as meaningful as possible an
> interpretation (or list of interpretations) that is relevant to 
> the expert user. 

Right.
 
> From you statement:
> 
>    dimension(23*J)
> 
> you are assuming that J is a reserved variable in Axiom, or at least
> recognizable by the system just like %pi.  I think using up name
> space with short names like "J" for Joule, etc is going to be very
> problematic with the interpreter. My proposal puts these only as
> output strings, and does not allow their direct manipulations as 
> variables.

Ah, OK - yes, I can see how your design implies that.

> To input 23 J, one would have to do:
> 
>    x := unitEnergy(23)$SI(INT)
> 
> assuming Joule = Newton-meter is the default energy unit in SI. 
> Under this setting, one can create a function
> 
>    dimension: % -> Dimension
> 
> where for example, dimension(x) would return 
>   
>       "Energy"
> 
> (the unit may or may not be given, depending on design; and I think
> if unit is what is intended, then we should have:
> 
>    unit: % -> OutputForm
> 
> and 
> 
>    unit(x)
> 
>        "J"
> 
> or in basic units:
> 
>        "N-m"
> 
> (adopting notation from SI).

Makes sense.

> Since I view units I/O as only decorations, they are all strings
> and not to be manipulated by arithmetic (but string operations
> are allowed of course). All this works in the current proposed
> scheme.

Yes, with the exception of the namespace issue it looks good.  You have
a valid point about using up namespace - more on that below.

> Now the reverse dimension analysis (RDA) is a totally different
> problem. The input to RDA is the outputform of a physical quantity
> (symbolic or numeric), perhaps inputted as a string (as I 
> discussed, I object strongly to using up user namespace). Assuming
> the string uses SI convention, we can write a parser based
> on the grammar defined, first to reduce every additive term to basic
> units in the seven basic dimensions, verify that they are all the
> same, then re-interpreting the resulting dimension expression in
> terms of plausible physical quantities depending on the subject 
> matter expertise. This requires a substantial amount of math: 
> basically, assuming you have the taxonomy for units
> in the expert area, you have to solve a dimension analysis problem,
> which is a (fairly large size) linear diophantine problem. A 
> solution is of course guaranteed since the dimensions of the given 
> terms in the input expression are solutions, but more likely, you 
> are going to have many solutions (for example, energy can be 
> produced various ways: potential and kinetic, rotational, work,
> Einstein's mass-energy exchange, etc). A decision criterion 
> to choose the "simplest", perhaps by the minimum total sum of the 
> exponents of all the basic/derived dimensions allowed, would then
> present the user with the result or set of results.

I guess that's pretty much what I pictured, yes.  I think it's less
important to identify things like potential vs. kinetic energy and just
identify that <quantity> IS an energy.  This can be helpful in building
an intuition about the system you are working on, even without more
specific information.

> I think the usefulness of such a RDA is minimal. A user typically
> knows what that is when he forms the expression.

At the student level I'm not sure I agree.

> Perhaps letting the system check the consistency of terms in 
> dimension is the only useful feedback, but that does not
> require RDA.

There have been times in the past when I would have liked to have RDA
to help me understand the calculations I was working on in a "physical"
way, but this can probably be defined as a deficiency on my part.

> Having a system setting to choose a particular unit system as 
> default is certainly desirable and possible. Axiom has extensive 
> )set commands. The convenience gained after this )set command
> 
>    )set unit SI
> 
> will be that the following commands do not require a package call:
> 
>    unitMass, etc
>    dimension
>    unit

That's most definitely a good feature to design in - I might set
UnitSystem rather than unit, but that's just a quibble.

What about by default creating a UserUnits system, and "importing" the
SI definitions into it as the "default" state?  This would amount to
putting user-friendly tools on creating a custom unitsystem domain, and
hide the need to do so from the user.  The system need only define the
standard environments, but if we allow the UserUnits system to
automatically import definitions while preserving and allowing local
overrides transparently, this would allow for full flexibility.  Best
of all, it can be defined "above" the more correct, structured systems
and ignored unless it is actually of interest.  So, upon consideration,
I vote for the SI/MKS/CGS domain proposal, since it can be built upon
for other environments which might be less "Axiom-like" in behavior.

> Being "fuzzy" is certainly against the philosophy of Axiom, but I
> suppose as long as it is clearly pointed out, there is no reason 
> not to allow it. Martin has a "guessing" program for sequences, and 
> it is very useful. So go ahead. I agree that Axiom suffered 
> commercial failure for its inflexibility.

To my mind the important things are a) to be able to work in a useful
way for the target audience, and b) to start with definitions in full
rigor and build "looser and friendlier" systems on top of that, so
additional power up to fully rigorous is available depending on the
situation.  I am very appreciative of these emails - they have made me
think about dimensions and units in ways I hadn't previously
considered, and that is valuable as an insight into the nature of those
systems all by itself :-).
  
> No, energy is energy and Work is energy, so they are interchangeble.
> (For example, work against friction produces heat).

OK.  I guess we would need to find some place where such things are
cataloged, and impliment that catalog in Axiom - unfortunately I have
no idea where to go for such a document.

> > Don't we WANT the units and dimensions to take namespace, at least
> > at user toplevel?  If the UNITS package were active, we certainly
> > don't want people using unit names for anything ELSE - it would
> > cause waaay too much confusion.  I would have viewed it as a 
> > design goal that (3 meter + 5 feet)::meter work as expected.

> Well, in my proposal, units names are implicit by using declarative
> functions (like unitMass()) in a particular domain of the UnitSystem
> category. I have already argued against the use of reserved 
> variables for units. People should be allowed to use J, nm, etc as 
> their own variables. All system variables (except domain
> abbreviations and names) have to be preceded by a % sign, as in 
> %pi. You have to teach the interpreter to recognize these special
> names.

I disagree here, although I concede you have valid points and the
default should probably be your way.  When I (or a student) am working
in Axiom on a physics problem, I have certain definite meanings
attached to symbols like J, nm, N, etc.  I want my use of these symbols
as variables to be illegal, since if I do so I am introducing the
chance for MASSIVE confusion down the road.  My mind is trained to look
at kg as kilograms when I am working on a problem with units as opposed
to numbers, and I would prefer that the CAS enforce this to make sure I
don't make mistakes.  However, based on my experience with Maxima you
are correct about the difficulties this introduces, and so if it is
done it should be built as an extension to the "correct" units
environment, not as the default.  I think this is doable, and the
design of the main units package does not need to specifically
accomidate it.

> > I guess I would prefer to be able to either "use" the SI system, 
> > and allow local overrides through simple syntax, or "set" the SI 
> > system, and insist on everything being rendered using it.
>
> As long as you are willing to do the programming :-)

Heh - well, that's certainly fair enough :-).

\start
Date: Wed, 24 Aug 2005 17:48:12 -0400
From: Bill Page
To: Peter Broadbery
Subject: Re: aldor patches

Peter,

On Wednesday, August 24, 2005 2:19 PM you wrote:
> >
> >   \begin{aldor}
> >   Aldor code
> >   \end{aldor}
> >
>
> This ought to work, but not immediately; One problem may be compiling
> several aldor stanzas together - in this case you need to be able to
> refer to earlier stanzas within the aldor block.
>
> Eg:
>
> \begin{aldor}
> 	AldorCat: Category == with { funstuff }
> \end{aldor}
>
> \begin{aldor}
> 	AldorDomain: AldorCat with { ... } == add { ... }
> \end{aldor}
>

In the case of \begin{axiom} sections, what MathAction does is
generate a .input or .spad file for each section and then calls
Axiom just once using stdin to pass )read or )compile commands
for each section as appropriate. So, for each web page there is
only one Axiom session and the namespace is the same for the
entire page. (Except for comments containing \begin{axiom}
sections which are initially each run in their own Axiom session
before being appended to the page.)

Perhaps I can do the same thing for Aldor? Can I run Aldor
with a series of 'include' files - one for each \begin{aldor}
section? Would that solve the problem of referring to earlier
sections?

To make this work properly I also need some kind of unique separator
string between the Aldor compiler output for each include file.
In the case of Axiom that separator is the interpreter '(99) -> '
prompt sequence. For Spad sections, the \begin{axiom} \end{axiom}
group is replaced with <pre>formatted</pre> HTML tag containing
the Spad code followed by a <div> ... </div> section containing
the Spad compiler output (which appears as "folded" text"). Can
you suggest a way to generate such a separator for Aldor compiler
output if the input consists of a series of 'include' files?

> To compile the second you'll need access to the .ao file generated
> by the first.  One solution may be to keep a list of .ao files
> within MathAction's session.  Alternatively, each stanza could
> implicitly contain all the previous ones.

The use of 'include' files above should handle this case, right?

Where do the .ao files need to be stored in order to be accessible
to Axiom commands? Can more than one .ao file be generate per run
of the Aldor compiler? Is it sufficient if they are saved in the
current working directory?

>
> >
> > In the log file you will note that the make failes starting
> > at this point:
> >
> > ...
> > /home/page/repository/axiom--main--1/src/aldor/Make.rules:31:
>
> Yes, this is due to me not testing stuff terribly well.  I've sent Tim
a
> new .tgz - appended below.
>

Thanks for sending this revised file. It gets further, but
Unfortunately it still does not complete.

The new src_aldor.tgs file that you sent does not contain any
Makefile, however I figured that you expected me to initially
do

  # document Makefile.pamphlet

in order to generate the Makefile and the type

  # make 2>&1 | tee aldor.log

The result of doing this is contained in the new attached log
file.

The log file contains two runs of make in sequence. The first run
stops with the message:

make[1]: *** No rule to make target
`/home/page/repository/axiom--main--1/int/aldor/dep_spad.stamp', needed
by `/home/page/repository/axiom--main--1/int/aldor/saxiom/spadset.mk'.
Stop.

To continue I did

  # touch ../../int/aldor/dep_spad.stamp
  # make 2>&1 | tee -a aldor.log

Is this due to another missing file? I noticed that your new src_aldor
File is a smaller than the previous one. Should I have first untarred
the previous file and then overlayed it with the new one?

The build progressed further but then apparently stopped because
a statement in the generated Makefile exceeded some command line
length limit for either make or /bin/sh.

What linux operating system and utility versions are you using
to do your development? I am trying to build this on the
axiom-developer/MathAction server which is running RedHat 9
(updated almost, I think, to the level when RedHat discontinued
it's development about two years ago in favor of Fedora). The
server runs in shared virtual server mode.

Is there some way your java program can easily generate a more
Portable Makefile? Or do you know of anyway to allocate a
Larger command line buffer?

Regards,
Bill Page.


------_=_NextPart_001_01C5A8F5.86FF18C4
	name="aldor2.log"
	filename="aldor2.log"

QnVpbGRpbmcgbGliYXhpb20uYWwgYW5kIGFzc29jaWF0ZWQgZmlsZXMKL2hvbWUvcGFnZS9yZXBv
c2l0b3J5L2F4aW9tLS1tYWluLS0xL2ludC9hbGRvcgptYWtlWzFdOiBFbnRlcmluZyBkaXJlY3Rv
cnkgYC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3InCi9ob21l
L3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZWZpbGU6NDQ6IC9o
b21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlczog
Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1h
aW4tLTEvc3JjL2FsZG9yL01ha2VmaWxlOjQ1OiAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20t
LW1haW4tLTEvc3JjL2FsZG9yL2xpYmF4aW9tLm1rOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5
Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZWZpbGU6
NDY6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvdHlwZXMu
bWs6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9t
LS1tYWluLS0xL3NyYy9hbGRvci9NYWtlZmlsZTo0OTogL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4
aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1bGVzOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0
b3J5Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9tbnQvbGludXgvYmluL2Rv
Y3VtZW50ICAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01h
a2UucnVsZXMKKGNkICQoZGlybmFtZSAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4t
LTEvc3JjL2FsZG9yL01ha2UucnVsZXMpOyAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1h
aW4tLTEvbW50L2xpbnV4L2Jpbi9kb2N1bWVudCAgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9t
LS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1bGVzKQpUaGlzIGlzIHBkZmVUZVgsIFZlcnNpb24g
My4xNDE1OTItMS4yMWEtMi4yIChXZWIyQyA3LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQgbW9kZQoo
Li9NYWtlLnJ1bGVzLnRleApMYVRlWDJlIDwyMDAzLzEyLzAxPgpCYWJlbCA8djMuOGQ+IGFuZCBo
eXBoZW5hdGlvbiBwYXR0ZXJucyBmb3IgYW1lcmljYW4sIGZyZW5jaCwgZ2VybWFuLCBuZ2VybWFu
LCBiCmFoYXNhLCBiYXNxdWUsIGJ1bGdhcmlhbiwgY2F0YWxhbiwgY3JvYXRpYW4sIGN6ZWNoLCBk
YW5pc2gsIGR1dGNoLCBlc3BlcmFudG8sIGUKc3RvbmlhbiwgZmlubmlzaCwgZ3JlZWssIGljZWxh
bmRpYywgaXJpc2gsIGl0YWxpYW4sIGxhdGluLCBtYWd5YXIsIG5vcnNrLCBwb2xpcwpoLCBwb3J0
dWdlcywgcm9tYW5pYW4sIHJ1c3NpYW4sIHNlcmJpYW4sIHNsb3Zhaywgc2xvdmVuZSwgc3Bhbmlz
aCwgc3dlZGlzaCwgdHVyCmtpc2gsIHVrcmFpbmlhbiwgbm9oeXBoZW5hdGlvbiwgbG9hZGVkLgoo
L3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNlL2FydGljbGUu
Y2xzCkRvY3VtZW50IENsYXNzOiBhcnRpY2xlIDIwMDQvMDIvMTYgdjEuNGYgU3RhbmRhcmQgTGFU
ZVggZG9jdW1lbnQgY2xhc3MKKC91c3IvbG9jYWwvdGVUZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgv
bGF0ZXgvYmFzZS9zaXplMTAuY2xvKSkKKC4uL3NjcmlwdHMvdGV4L2F4aW9tLnN0eSkKTm8gZmls
ZSBNYWtlLnJ1bGVzLmF1eC4KWzFdIFsyXSBbM10gWzRdIFs1XSBbNl0gWzddIFs4XSBbOV0gWzEw
XSBbMTFdICguL01ha2UucnVsZXMuYXV4KSApCk91dHB1dCB3cml0dGVuIG9uIE1ha2UucnVsZXMu
ZHZpICgxMSBwYWdlcywgMTY3NzYgYnl0ZXMpLgpUcmFuc2NyaXB0IHdyaXR0ZW4gb24gTWFrZS5y
dWxlcy5sb2cuClRoaXMgaXMgcGRmZVRlWCwgVmVyc2lvbiAzLjE0MTU5Mi0xLjIxYS0yLjIgKFdl
YjJDIDcuNS40KQplbnRlcmluZyBleHRlbmRlZCBtb2RlCiguL01ha2UucnVsZXMudGV4CkxhVGVY
MmUgPDIwMDMvMTIvMDE+CkJhYmVsIDx2My44ZD4gYW5kIGh5cGhlbmF0aW9uIHBhdHRlcm5zIGZv
ciBhbWVyaWNhbiwgZnJlbmNoLCBnZXJtYW4sIG5nZXJtYW4sIGIKYWhhc2EsIGJhc3F1ZSwgYnVs
Z2FyaWFuLCBjYXRhbGFuLCBjcm9hdGlhbiwgY3plY2gsIGRhbmlzaCwgZHV0Y2gsIGVzcGVyYW50
bywgZQpzdG9uaWFuLCBmaW5uaXNoLCBncmVlaywgaWNlbGFuZGljLCBpcmlzaCwgaXRhbGlhbiwg
bGF0aW4sIG1hZ3lhciwgbm9yc2ssIHBvbGlzCmgsIHBvcnR1Z2VzLCByb21hbmlhbiwgcnVzc2lh
biwgc2VyYmlhbiwgc2xvdmFrLCBzbG92ZW5lLCBzcGFuaXNoLCBzd2VkaXNoLCB0dXIKa2lzaCwg
dWtyYWluaWFuLCBub2h5cGhlbmF0aW9uLCBsb2FkZWQuCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJl
L3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2UvYXJ0aWNsZS5jbHMKRG9jdW1lbnQgQ2xhc3M6IGFy
dGljbGUgMjAwNC8wMi8xNiB2MS40ZiBTdGFuZGFyZCBMYVRlWCBkb2N1bWVudCBjbGFzcwooL3Vz
ci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNlL3NpemUxMC5jbG8p
KQooLi4vc2NyaXB0cy90ZXgvYXhpb20uc3R5KSAoLi9NYWtlLnJ1bGVzLmF1eCkgWzFdIFsyXSBb
M10gWzRdIFs1XSBbNl0gWzddCls4XSBbOV0gWzEwXSBbMTFdICguL01ha2UucnVsZXMuYXV4KSAp
Ck91dHB1dCB3cml0dGVuIG9uIE1ha2UucnVsZXMuZHZpICgxMSBwYWdlcywgMTY3NzYgYnl0ZXMp
LgpUcmFuc2NyaXB0IHdyaXR0ZW4gb24gTWFrZS5ydWxlcy5sb2cuCi9ob21lL3BhZ2UvcmVwb3Np
dG9yeS9heGlvbS0tbWFpbi0tMS9tbnQvbGludXgvYmluL2RvY3VtZW50ICAvaG9tZS9wYWdlL3Jl
cG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL3R5cGVzLm1rCihjZCAkKGRpcm5hbWUg
L2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci90eXBlcy5tayk7
IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9tbnQvbGludXgvYmluL2RvY3Vt
ZW50ICAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL3R5cGVz
Lm1rKQpUaGlzIGlzIHBkZmVUZVgsIFZlcnNpb24gMy4xNDE1OTItMS4yMWEtMi4yIChXZWIyQyA3
LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQgbW9kZQooLi90eXBlcy5tay50ZXgKTGFUZVgyZSA8MjAw
My8xMi8wMT4KQmFiZWwgPHYzLjhkPiBhbmQgaHlwaGVuYXRpb24gcGF0dGVybnMgZm9yIGFtZXJp
Y2FuLCBmcmVuY2gsIGdlcm1hbiwgbmdlcm1hbiwgYgphaGFzYSwgYmFzcXVlLCBidWxnYXJpYW4s
IGNhdGFsYW4sIGNyb2F0aWFuLCBjemVjaCwgZGFuaXNoLCBkdXRjaCwgZXNwZXJhbnRvLCBlCnN0
b25pYW4sIGZpbm5pc2gsIGdyZWVrLCBpY2VsYW5kaWMsIGlyaXNoLCBpdGFsaWFuLCBsYXRpbiwg
bWFneWFyLCBub3JzaywgcG9saXMKaCwgcG9ydHVnZXMsIHJvbWFuaWFuLCBydXNzaWFuLCBzZXJi
aWFuLCBzbG92YWssIHNsb3ZlbmUsIHNwYW5pc2gsIHN3ZWRpc2gsIHR1cgpraXNoLCB1a3JhaW5p
YW4sIG5vaHlwaGVuYXRpb24sIGxvYWRlZC4KKC91c3IvbG9jYWwvdGVUZVgvc2hhcmUvdGV4bWYt
ZGlzdC90ZXgvbGF0ZXgvYmFzZS9hcnRpY2xlLmNscwpEb2N1bWVudCBDbGFzczogYXJ0aWNsZSAy
MDA0LzAyLzE2IHYxLjRmIFN0YW5kYXJkIExhVGVYIGRvY3VtZW50IGNsYXNzCigvdXNyL2xvY2Fs
L3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2Uvc2l6ZTEwLmNsbykpCiguLi9z
Y3JpcHRzL3RleC9heGlvbS5zdHkpCk5vIGZpbGUgdHlwZXMubWsuYXV4LgpbMV0gWzJdIFszXSBb
NF0KT3ZlcmZ1bGwgXGhib3ggKDIwLjk5OTgycHQgdG9vIHdpZGUpIGluIHBhcmFncmFwaCBhdCBs
aW5lcyAxOTgtLTE5OAogW10gICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIGphdmEgLWNwIGBwd2Rg
IFNvcnQgYmFzZSAkKE1JRCkvZGVwcy9heGV4dGVuZC5kZXAgCiQoTUlEKS90eXBlbGlzdCAkKE1J
RCkvaW5pdGRvbWFpbnMgXFtdICAKCk92ZXJmdWxsIFxoYm94ICgxMzEuMjQ4ODZwdCB0b28gd2lk
ZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDIyMC0tMjIwCiBbXSAgICAgICAgIFxPVDEvY210dC9t
L24vMTAgamF2YSAtY3AgYHB3ZGAgU29ydCBjb25uZWN0ZWQgc2F4aW9tICQoZmlsdGVyLW91dCAK
JChzaGVsbCBjYXQgJChNSUQpL3NheDAvc3BhZHNldC5sc3QpLCAkKEFMTF9TUEFEX1RZUEVTKSkp
W10gIApbNV0gKC4vdHlwZXMubWsuYXV4KSApCihzZWUgdGhlIHRyYW5zY3JpcHQgZmlsZSBmb3Ig
YWRkaXRpb25hbCBpbmZvcm1hdGlvbikKT3V0cHV0IHdyaXR0ZW4gb24gdHlwZXMubWsuZHZpICg1
IHBhZ2VzLCA5NjQ4IGJ5dGVzKS4KVHJhbnNjcmlwdCB3cml0dGVuIG9uIHR5cGVzLm1rLmxvZy4K
VGhpcyBpcyBwZGZlVGVYLCBWZXJzaW9uIDMuMTQxNTkyLTEuMjFhLTIuMiAoV2ViMkMgNy41LjQp
CmVudGVyaW5nIGV4dGVuZGVkIG1vZGUKKC4vdHlwZXMubWsudGV4CkxhVGVYMmUgPDIwMDMvMTIv
MDE+CkJhYmVsIDx2My44ZD4gYW5kIGh5cGhlbmF0aW9uIHBhdHRlcm5zIGZvciBhbWVyaWNhbiwg
ZnJlbmNoLCBnZXJtYW4sIG5nZXJtYW4sIGIKYWhhc2EsIGJhc3F1ZSwgYnVsZ2FyaWFuLCBjYXRh
bGFuLCBjcm9hdGlhbiwgY3plY2gsIGRhbmlzaCwgZHV0Y2gsIGVzcGVyYW50bywgZQpzdG9uaWFu
LCBmaW5uaXNoLCBncmVlaywgaWNlbGFuZGljLCBpcmlzaCwgaXRhbGlhbiwgbGF0aW4sIG1hZ3lh
ciwgbm9yc2ssIHBvbGlzCmgsIHBvcnR1Z2VzLCByb21hbmlhbiwgcnVzc2lhbiwgc2VyYmlhbiwg
c2xvdmFrLCBzbG92ZW5lLCBzcGFuaXNoLCBzd2VkaXNoLCB0dXIKa2lzaCwgdWtyYWluaWFuLCBu
b2h5cGhlbmF0aW9uLCBsb2FkZWQuCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3Qv
dGV4L2xhdGV4L2Jhc2UvYXJ0aWNsZS5jbHMKRG9jdW1lbnQgQ2xhc3M6IGFydGljbGUgMjAwNC8w
Mi8xNiB2MS40ZiBTdGFuZGFyZCBMYVRlWCBkb2N1bWVudCBjbGFzcwooL3Vzci9sb2NhbC90ZVRl
WC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNlL3NpemUxMC5jbG8pKQooLi4vc2NyaXB0
cy90ZXgvYXhpb20uc3R5KSAoLi90eXBlcy5tay5hdXgpIFsxXSBbMl0gWzNdIFs0XQpPdmVyZnVs
bCBcaGJveCAoMjAuOTk5ODJwdCB0b28gd2lkZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDE5OC0t
MTk4CiBbXSAgICAgICAgIFxPVDEvY210dC9tL24vMTAgamF2YSAtY3AgYHB3ZGAgU29ydCBiYXNl
ICQoTUlEKS9kZXBzL2F4ZXh0ZW5kLmRlcCAKJChNSUQpL3R5cGVsaXN0ICQoTUlEKS9pbml0ZG9t
YWlucyBcW10gIAoKT3ZlcmZ1bGwgXGhib3ggKDEzMS4yNDg4NnB0IHRvbyB3aWRlKSBpbiBwYXJh
Z3JhcGggYXQgbGluZXMgMjIwLS0yMjAKIFtdICAgICAgICAgXE9UMS9jbXR0L20vbi8xMCBqYXZh
IC1jcCBgcHdkYCBTb3J0IGNvbm5lY3RlZCBzYXhpb20gJChmaWx0ZXItb3V0IAokKHNoZWxsIGNh
dCAkKE1JRCkvc2F4MC9zcGFkc2V0LmxzdCksICQoQUxMX1NQQURfVFlQRVMpKSlbXSAgCls1XSAo
Li90eXBlcy5tay5hdXgpICkKKHNlZSB0aGUgdHJhbnNjcmlwdCBmaWxlIGZvciBhZGRpdGlvbmFs
IGluZm9ybWF0aW9uKQpPdXRwdXQgd3JpdHRlbiBvbiB0eXBlcy5tay5kdmkgKDUgcGFnZXMsIDk2
NDggYnl0ZXMpLgpUcmFuc2NyaXB0IHdyaXR0ZW4gb24gdHlwZXMubWsubG9nLgovaG9tZS9wYWdl
L3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvbW50L2xpbnV4L2Jpbi9kb2N1bWVudCAgL2hvbWUv
cGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9saWJheGlvbS5tawooY2Qg
JChkaXJuYW1lIC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3Iv
bGliYXhpb20ubWspOyAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvbW50L2xp
bnV4L2Jpbi9kb2N1bWVudCAgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3Ny
Yy9hbGRvci9saWJheGlvbS5taykKVGhpcyBpcyBwZGZlVGVYLCBWZXJzaW9uIDMuMTQxNTkyLTEu
MjFhLTIuMiAoV2ViMkMgNy41LjQpCmVudGVyaW5nIGV4dGVuZGVkIG1vZGUKKC4vbGliYXhpb20u
bWsudGV4CkxhVGVYMmUgPDIwMDMvMTIvMDE+CkJhYmVsIDx2My44ZD4gYW5kIGh5cGhlbmF0aW9u
IHBhdHRlcm5zIGZvciBhbWVyaWNhbiwgZnJlbmNoLCBnZXJtYW4sIG5nZXJtYW4sIGIKYWhhc2Es
IGJhc3F1ZSwgYnVsZ2FyaWFuLCBjYXRhbGFuLCBjcm9hdGlhbiwgY3plY2gsIGRhbmlzaCwgZHV0
Y2gsIGVzcGVyYW50bywgZQpzdG9uaWFuLCBmaW5uaXNoLCBncmVlaywgaWNlbGFuZGljLCBpcmlz
aCwgaXRhbGlhbiwgbGF0aW4sIG1hZ3lhciwgbm9yc2ssIHBvbGlzCmgsIHBvcnR1Z2VzLCByb21h
bmlhbiwgcnVzc2lhbiwgc2VyYmlhbiwgc2xvdmFrLCBzbG92ZW5lLCBzcGFuaXNoLCBzd2VkaXNo
LCB0dXIKa2lzaCwgdWtyYWluaWFuLCBub2h5cGhlbmF0aW9uLCBsb2FkZWQuCigvdXNyL2xvY2Fs
L3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2UvYXJ0aWNsZS5jbHMKRG9jdW1l
bnQgQ2xhc3M6IGFydGljbGUgMjAwNC8wMi8xNiB2MS40ZiBTdGFuZGFyZCBMYVRlWCBkb2N1bWVu
dCBjbGFzcwooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNl
L3NpemUxMC5jbG8pKQooLi4vc2NyaXB0cy90ZXgvYXhpb20uc3R5KQpObyBmaWxlIGxpYmF4aW9t
Lm1rLmF1eC4KWzFdCk5vIGZpbGUgbGliYXhpb20ubWsudG9jLgpbMl0gWzNdIFs0XSBbNV0gWzZd
ICguL2xpYmF4aW9tLm1rLmF1eCkgKQpPdXRwdXQgd3JpdHRlbiBvbiBsaWJheGlvbS5tay5kdmkg
KDYgcGFnZXMsIDUyOTIgYnl0ZXMpLgpUcmFuc2NyaXB0IHdyaXR0ZW4gb24gbGliYXhpb20ubWsu
bG9nLgpUaGlzIGlzIHBkZmVUZVgsIFZlcnNpb24gMy4xNDE1OTItMS4yMWEtMi4yIChXZWIyQyA3
LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQgbW9kZQooLi9saWJheGlvbS5tay50ZXgKTGFUZVgyZSA8
MjAwMy8xMi8wMT4KQmFiZWwgPHYzLjhkPiBhbmQgaHlwaGVuYXRpb24gcGF0dGVybnMgZm9yIGFt
ZXJpY2FuLCBmcmVuY2gsIGdlcm1hbiwgbmdlcm1hbiwgYgphaGFzYSwgYmFzcXVlLCBidWxnYXJp
YW4sIGNhdGFsYW4sIGNyb2F0aWFuLCBjemVjaCwgZGFuaXNoLCBkdXRjaCwgZXNwZXJhbnRvLCBl
CnN0b25pYW4sIGZpbm5pc2gsIGdyZWVrLCBpY2VsYW5kaWMsIGlyaXNoLCBpdGFsaWFuLCBsYXRp
biwgbWFneWFyLCBub3JzaywgcG9saXMKaCwgcG9ydHVnZXMsIHJvbWFuaWFuLCBydXNzaWFuLCBz
ZXJiaWFuLCBzbG92YWssIHNsb3ZlbmUsIHNwYW5pc2gsIHN3ZWRpc2gsIHR1cgpraXNoLCB1a3Jh
aW5pYW4sIG5vaHlwaGVuYXRpb24sIGxvYWRlZC4KKC91c3IvbG9jYWwvdGVUZVgvc2hhcmUvdGV4
bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9hcnRpY2xlLmNscwpEb2N1bWVudCBDbGFzczogYXJ0aWNs
ZSAyMDA0LzAyLzE2IHYxLjRmIFN0YW5kYXJkIExhVGVYIGRvY3VtZW50IGNsYXNzCigvdXNyL2xv
Y2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2Uvc2l6ZTEwLmNsbykpCigu
Li9zY3JpcHRzL3RleC9heGlvbS5zdHkpICguL2xpYmF4aW9tLm1rLmF1eCkgWzFdICguL2xpYmF4
aW9tLm1rLnRvYykgWzJdClszXSBbNF0gWzVdIFs2XSAoLi9saWJheGlvbS5tay5hdXgpICkKT3V0
cHV0IHdyaXR0ZW4gb24gbGliYXhpb20ubWsuZHZpICg2IHBhZ2VzLCA1MjkyIGJ5dGVzKS4KVHJh
bnNjcmlwdCB3cml0dGVuIG9uIGxpYmF4aW9tLm1rLmxvZy4KbWFrZVsxXTogTGVhdmluZyBkaXJl
Y3RvcnkgYC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3InCm1h
a2VbMV06IEVudGVyaW5nIGRpcmVjdG9yeSBgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1t
YWluLS0xL3NyYy9hbGRvcicKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3Ny
Yy9hbGRvci9NYWtlLnJ1bGVzOjMxOiAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4t
LTEvc3JjL2FsZG9yL01ha2UuZnVuY3Rpb25zOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Ci9o
b21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlczoz
NDogL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLmF4
aW9tOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlv
bS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlczozNTogL2hvbWUvcGFnZS9yZXBvc2l0b3J5
L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLmFsZG9yOiBObyBzdWNoIGZpbGUgb3IgZGly
ZWN0b3J5Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvdHlw
ZXMubWs6NDU6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9pbnQvYWxkb3Iv
YWxsX3NwYWRfdHlwZXMubWs6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKL2hvbWUvcGFnZS9y
ZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci90eXBlcy5tazo0NjogL2hvbWUvcGFn
ZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL2ludC9hbGRvci9hbGxfc3BhZF9jYXRzLm1rOiBO
byBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFp
bi0tMS9zcmMvYWxkb3IvdHlwZXMubWs6MTU2OiAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20t
LW1haW4tLTEvaW50L2FsZG9yL3NheGlvbS9zcGFkc2V0Lm1rIAovaG9tZS9wYWdlL3JlcG9zaXRv
cnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXM6MTc5OiBBTEwgU1BBRFNFVFMg
IHNheDAgc2F4aW9tCi9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxk
b3IvTWFrZS5ydWxlczoyMDA6ICgwLDApCi9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFp
bi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlczoyMDQ6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlv
bS0tbWFpbi0tMS9pbnQvYWxkb3Ivc2F4MC9zcGFkc2V0Lm1rOiBObyBzdWNoIGZpbGUgb3IgZGly
ZWN0b3J5Ci9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFr
ZS5ydWxlczoyMDA6ICgxLDEpCi9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9z
cmMvYWxkb3IvTWFrZS5ydWxlczoyMDQ6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFp
bi0tMS9pbnQvYWxkb3Ivc2F4aW9tL3NwYWRzZXQubWs6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv
cnkKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1
bGVzOjI3MTogbm8gZmlsZSBuYW1lIGZvciBgLWluY2x1ZGUnCi9ob21lL3BhZ2UvcmVwb3NpdG9y
eS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlczoyNzE6IG5vIGZpbGUgbmFtZSBm
b3IgYC1pbmNsdWRlJwovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2Fs
ZG9yL01ha2UucnVsZXM6MTA2OiBXOiAxIEk6IDEKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9t
LS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1bGVzOjEwNzogVzogICAgIC9ob21lL3BhZ2UvcmVw
b3NpdG9yeS9heGlvbS0tbWFpbi0tMS9pbnQvYWxkb3Ivc2F4MC9zcGFkc2V0Lm1rCi9ob21lL3Bh
Z2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlczo0MjM6IC9o
b21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5heGlvbTog
Tm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1h
aW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXM6NDI1OiAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhp
b20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UuYWxkb3I6IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rv
cnkKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL21udC9saW51eC9iaW4vZG9j
dW1lbnQgIC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFr
ZS5hbGRvcgooY2QgJChkaXJuYW1lIC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0t
MS9zcmMvYWxkb3IvTWFrZS5hbGRvcik7IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFp
bi0tMS9tbnQvbGludXgvYmluL2RvY3VtZW50ICAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20t
LW1haW4tLTEvc3JjL2FsZG9yL01ha2UuYWxkb3IpClRoaXMgaXMgcGRmZVRlWCwgVmVyc2lvbiAz
LjE0MTU5Mi0xLjIxYS0yLjIgKFdlYjJDIDcuNS40KQplbnRlcmluZyBleHRlbmRlZCBtb2RlCigu
L01ha2UuYWxkb3IudGV4CkxhVGVYMmUgPDIwMDMvMTIvMDE+CkJhYmVsIDx2My44ZD4gYW5kIGh5
cGhlbmF0aW9uIHBhdHRlcm5zIGZvciBhbWVyaWNhbiwgZnJlbmNoLCBnZXJtYW4sIG5nZXJtYW4s
IGIKYWhhc2EsIGJhc3F1ZSwgYnVsZ2FyaWFuLCBjYXRhbGFuLCBjcm9hdGlhbiwgY3plY2gsIGRh
bmlzaCwgZHV0Y2gsIGVzcGVyYW50bywgZQpzdG9uaWFuLCBmaW5uaXNoLCBncmVlaywgaWNlbGFu
ZGljLCBpcmlzaCwgaXRhbGlhbiwgbGF0aW4sIG1hZ3lhciwgbm9yc2ssIHBvbGlzCmgsIHBvcnR1
Z2VzLCByb21hbmlhbiwgcnVzc2lhbiwgc2VyYmlhbiwgc2xvdmFrLCBzbG92ZW5lLCBzcGFuaXNo
LCBzd2VkaXNoLCB0dXIKa2lzaCwgdWtyYWluaWFuLCBub2h5cGhlbmF0aW9uLCBsb2FkZWQuCigv
dXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2UvYXJ0aWNsZS5j
bHMKRG9jdW1lbnQgQ2xhc3M6IGFydGljbGUgMjAwNC8wMi8xNiB2MS40ZiBTdGFuZGFyZCBMYVRl
WCBkb2N1bWVudCBjbGFzcwooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9s
YXRleC9iYXNlL3NpemUxMC5jbG8pKQooLi4vc2NyaXB0cy90ZXgvYXhpb20uc3R5KQpObyBmaWxl
IE1ha2UuYWxkb3IuYXV4LgpbMV0KT3ZlcmZ1bGwgXGhib3ggKDEwLjQ5OTkxcHQgdG9vIHdpZGUp
IGluIHBhcmFncmFwaCBhdCBsaW5lcyA2Ny0tNjcKIFtdICAgICAgICAgICAgICAgIFxPVDEvY210
dC9tL24vMTAgJChwYXRzdWJzdCAkKE1JRCkvdG1wL2xpYiQoYW9fbGlicmFyeV9uYW1lKQpfJS5s
c3QsICUsICQoZmlsdGVyICUubHN0LCAkXikpOyBcW10gIApbMl0gWzNdIFs0XSAoLi9NYWtlLmFs
ZG9yLmF1eCkgKQooc2VlIHRoZSB0cmFuc2NyaXB0IGZpbGUgZm9yIGFkZGl0aW9uYWwgaW5mb3Jt
YXRpb24pCk91dHB1dCB3cml0dGVuIG9uIE1ha2UuYWxkb3IuZHZpICg0IHBhZ2VzLCA1NTM2IGJ5
dGVzKS4KVHJhbnNjcmlwdCB3cml0dGVuIG9uIE1ha2UuYWxkb3IubG9nLgpUaGlzIGlzIHBkZmVU
ZVgsIFZlcnNpb24gMy4xNDE1OTItMS4yMWEtMi4yIChXZWIyQyA3LjUuNCkKZW50ZXJpbmcgZXh0
ZW5kZWQgbW9kZQooLi9NYWtlLmFsZG9yLnRleApMYVRlWDJlIDwyMDAzLzEyLzAxPgpCYWJlbCA8
djMuOGQ+IGFuZCBoeXBoZW5hdGlvbiBwYXR0ZXJucyBmb3IgYW1lcmljYW4sIGZyZW5jaCwgZ2Vy
bWFuLCBuZ2VybWFuLCBiCmFoYXNhLCBiYXNxdWUsIGJ1bGdhcmlhbiwgY2F0YWxhbiwgY3JvYXRp
YW4sIGN6ZWNoLCBkYW5pc2gsIGR1dGNoLCBlc3BlcmFudG8sIGUKc3RvbmlhbiwgZmlubmlzaCwg
Z3JlZWssIGljZWxhbmRpYywgaXJpc2gsIGl0YWxpYW4sIGxhdGluLCBtYWd5YXIsIG5vcnNrLCBw
b2xpcwpoLCBwb3J0dWdlcywgcm9tYW5pYW4sIHJ1c3NpYW4sIHNlcmJpYW4sIHNsb3Zhaywgc2xv
dmVuZSwgc3BhbmlzaCwgc3dlZGlzaCwgdHVyCmtpc2gsIHVrcmFpbmlhbiwgbm9oeXBoZW5hdGlv
biwgbG9hZGVkLgooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRleC9i
YXNlL2FydGljbGUuY2xzCkRvY3VtZW50IENsYXNzOiBhcnRpY2xlIDIwMDQvMDIvMTYgdjEuNGYg
U3RhbmRhcmQgTGFUZVggZG9jdW1lbnQgY2xhc3MKKC91c3IvbG9jYWwvdGVUZVgvc2hhcmUvdGV4
bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9zaXplMTAuY2xvKSkKKC4uL3NjcmlwdHMvdGV4L2F4aW9t
LnN0eSkgKC4vTWFrZS5hbGRvci5hdXgpIFsxXQpPdmVyZnVsbCBcaGJveCAoMTAuNDk5OTFwdCB0
b28gd2lkZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDY3LS02NwogW10gICAgICAgICAgICAgICAg
XE9UMS9jbXR0L20vbi8xMCAkKHBhdHN1YnN0ICQoTUlEKS90bXAvbGliJChhb19saWJyYXJ5X25h
bWUpCl8lLmxzdCwgJSwgJChmaWx0ZXIgJS5sc3QsICReKSk7IFxbXSAgClsyXSBbM10gWzRdICgu
L01ha2UuYWxkb3IuYXV4KSApCihzZWUgdGhlIHRyYW5zY3JpcHQgZmlsZSBmb3IgYWRkaXRpb25h
bCBpbmZvcm1hdGlvbikKT3V0cHV0IHdyaXR0ZW4gb24gTWFrZS5hbGRvci5kdmkgKDQgcGFnZXMs
IDU1MzYgYnl0ZXMpLgpUcmFuc2NyaXB0IHdyaXR0ZW4gb24gTWFrZS5hbGRvci5sb2cuCi9ob21l
L3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9tbnQvbGludXgvYmluL2RvY3VtZW50ICAv
aG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UuYXhpb20K
KGNkICQoZGlybmFtZSAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2Fs
ZG9yL01ha2UuYXhpb20pOyAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvbW50
L2xpbnV4L2Jpbi9kb2N1bWVudCAgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0x
L3NyYy9hbGRvci9NYWtlLmF4aW9tKQpUaGlzIGlzIHBkZmVUZVgsIFZlcnNpb24gMy4xNDE1OTIt
MS4yMWEtMi4yIChXZWIyQyA3LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQgbW9kZQooLi9NYWtlLmF4
aW9tLnRleApMYVRlWDJlIDwyMDAzLzEyLzAxPgpCYWJlbCA8djMuOGQ+IGFuZCBoeXBoZW5hdGlv
biBwYXR0ZXJucyBmb3IgYW1lcmljYW4sIGZyZW5jaCwgZ2VybWFuLCBuZ2VybWFuLCBiCmFoYXNh
LCBiYXNxdWUsIGJ1bGdhcmlhbiwgY2F0YWxhbiwgY3JvYXRpYW4sIGN6ZWNoLCBkYW5pc2gsIGR1
dGNoLCBlc3BlcmFudG8sIGUKc3RvbmlhbiwgZmlubmlzaCwgZ3JlZWssIGljZWxhbmRpYywgaXJp
c2gsIGl0YWxpYW4sIGxhdGluLCBtYWd5YXIsIG5vcnNrLCBwb2xpcwpoLCBwb3J0dWdlcywgcm9t
YW5pYW4sIHJ1c3NpYW4sIHNlcmJpYW4sIHNsb3Zhaywgc2xvdmVuZSwgc3BhbmlzaCwgc3dlZGlz
aCwgdHVyCmtpc2gsIHVrcmFpbmlhbiwgbm9oeXBoZW5hdGlvbiwgbG9hZGVkLgooL3Vzci9sb2Nh
bC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNlL2FydGljbGUuY2xzCkRvY3Vt
ZW50IENsYXNzOiBhcnRpY2xlIDIwMDQvMDIvMTYgdjEuNGYgU3RhbmRhcmQgTGFUZVggZG9jdW1l
bnQgY2xhc3MKKC91c3IvbG9jYWwvdGVUZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgvYmFz
ZS9zaXplMTAuY2xvKSkKKC4uL3NjcmlwdHMvdGV4L2F4aW9tLnN0eSkKTm8gZmlsZSBNYWtlLmF4
aW9tLmF1eC4KWzFdCk92ZXJmdWxsIFxoYm94ICgxMDQuOTk5MDhwdCB0b28gd2lkZSkgaW4gcGFy
YWdyYXBoIGF0IGxpbmVzIDg0LS04NAogW10gICAgICAgIFxPVDEvY210dC9tL24vMTAgQGVjaG8g
IihzZXRxIGNvbXBvbmVudHMgKHF1b3RlICgkKGNhbGwgbm8taW5pdHMsJChTClBBRFNFVF9JVEVN
XyQoQylfJCopKSkpICkiID4+ICQoTUlEKS90bXAvbWtheF8kKi5sc3BbXSAgCgpPdmVyZnVsbCBc
aGJveCAoNjIuOTk5NDVwdCB0b28gd2lkZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDg1LS04NQog
W10gICAgICAgIFxPVDEvY210dC9tL24vMTAgQGVjaG8gIihzZXRxIGluaXRzIChxdW90ZSAoJChj
YWxsIGluaXRzLCQoU1BBRFNFVF9JClRFTV8kKEMpXyQqKSkpKSApIiA+PiAkKE1JRCkvdG1wL21r
YXhfJCoubHNwW10gIAoKT3ZlcmZ1bGwgXGhib3ggKDE4My43NDg0cHQgdG9vIHdpZGUpIGluIHBh
cmFncmFwaCBhdCBsaW5lcyA4Ny0tODcKIFtdICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIEAoY2Qg
JChNSUQpOyBEQUFTRT0iJChEQUFTRSkiOyBleHBvcnQgREFBU0U7ICQoSU5URQpSUFNZUyk7IHRy
dWUpIDwgJChNSUQpL3RtcC9ta2F4XyQqLmxzcCA+ICQoTUlEKS90bXAvZ2VuXyQqLmxvZyAyPiYx
W10gIApbMl0KT3ZlcmZ1bGwgXGhib3ggKDQ4OC4yNDU3NHB0IHRvbyB3aWRlKSBpbiBwYXJhZ3Jh
cGggYXQgbGluZXMgMTAxLS0xMDEKIFtdICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIEBlY2hvICco
cHJvZ24gKGxvYWQgIiQoT0JKKS8kKFNZUykvaW50ZXJwL2ZvYW1fbC5vIgopIChjb21waWxlLWZp
bGUgIiQoZmlsdGVyICUubHNwLCReKSIgOm91dHB1dC1maWxlICIkQCIpICgke0JZRX0pKScgfCAk
e0RFUFNZU30gCj4gJChPQkopLyQoU1lTKS9hbGRvci9idWlsZC8kKG5vdGRpciAkQCkubG9nIDtb
XSAgCgpPdmVyZnVsbCBcaGJveCAoMTQ2Ljk5ODcycHQgdG9vIHdpZGUpIGluIHBhcmFncmFwaCBh
dCBsaW5lcyAxMDItLTEwMgogW10gICAgICAgIFxPVDEvY210dC9tL24vMTAgQGlmIHRlc3QgLWYg
JEA7IHRoZW4gZWNobyAiQnVpbHQgJChub3RkaXIgJEApIiA7IGVsCnNlIGNhdCAkKE9CSikvJChT
WVMpL2FsZG9yL2J1aWxkLyQobm90ZGlyICRAKS5sb2c7IGZhbHNlOyBmaVtdICAKWzNdICguL01h
a2UuYXhpb20uYXV4KSApCihzZWUgdGhlIHRyYW5zY3JpcHQgZmlsZSBmb3IgYWRkaXRpb25hbCBp
bmZvcm1hdGlvbikKT3V0cHV0IHdyaXR0ZW4gb24gTWFrZS5heGlvbS5kdmkgKDMgcGFnZXMsIDQ3
MjQgYnl0ZXMpLgpUcmFuc2NyaXB0IHdyaXR0ZW4gb24gTWFrZS5heGlvbS5sb2cuClRoaXMgaXMg
cGRmZVRlWCwgVmVyc2lvbiAzLjE0MTU5Mi0xLjIxYS0yLjIgKFdlYjJDIDcuNS40KQplbnRlcmlu
ZyBleHRlbmRlZCBtb2RlCiguL01ha2UuYXhpb20udGV4CkxhVGVYMmUgPDIwMDMvMTIvMDE+CkJh
YmVsIDx2My44ZD4gYW5kIGh5cGhlbmF0aW9uIHBhdHRlcm5zIGZvciBhbWVyaWNhbiwgZnJlbmNo
LCBnZXJtYW4sIG5nZXJtYW4sIGIKYWhhc2EsIGJhc3F1ZSwgYnVsZ2FyaWFuLCBjYXRhbGFuLCBj
cm9hdGlhbiwgY3plY2gsIGRhbmlzaCwgZHV0Y2gsIGVzcGVyYW50bywgZQpzdG9uaWFuLCBmaW5u
aXNoLCBncmVlaywgaWNlbGFuZGljLCBpcmlzaCwgaXRhbGlhbiwgbGF0aW4sIG1hZ3lhciwgbm9y
c2ssIHBvbGlzCmgsIHBvcnR1Z2VzLCByb21hbmlhbiwgcnVzc2lhbiwgc2VyYmlhbiwgc2xvdmFr
LCBzbG92ZW5lLCBzcGFuaXNoLCBzd2VkaXNoLCB0dXIKa2lzaCwgdWtyYWluaWFuLCBub2h5cGhl
bmF0aW9uLCBsb2FkZWQuCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xh
dGV4L2Jhc2UvYXJ0aWNsZS5jbHMKRG9jdW1lbnQgQ2xhc3M6IGFydGljbGUgMjAwNC8wMi8xNiB2
MS40ZiBTdGFuZGFyZCBMYVRlWCBkb2N1bWVudCBjbGFzcwooL3Vzci9sb2NhbC90ZVRlWC9zaGFy
ZS90ZXhtZi1kaXN0L3RleC9sYXRleC9iYXNlL3NpemUxMC5jbG8pKQooLi4vc2NyaXB0cy90ZXgv
YXhpb20uc3R5KSAoLi9NYWtlLmF4aW9tLmF1eCkgWzFdCk92ZXJmdWxsIFxoYm94ICgxMDQuOTk5
MDhwdCB0b28gd2lkZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDg0LS04NAogW10gICAgICAgIFxP
VDEvY210dC9tL24vMTAgQGVjaG8gIihzZXRxIGNvbXBvbmVudHMgKHF1b3RlICgkKGNhbGwgbm8t
aW5pdHMsJChTClBBRFNFVF9JVEVNXyQoQylfJCopKSkpICkiID4+ICQoTUlEKS90bXAvbWtheF8k
Ki5sc3BbXSAgCgpPdmVyZnVsbCBcaGJveCAoNjIuOTk5NDVwdCB0b28gd2lkZSkgaW4gcGFyYWdy
YXBoIGF0IGxpbmVzIDg1LS04NQogW10gICAgICAgIFxPVDEvY210dC9tL24vMTAgQGVjaG8gIihz
ZXRxIGluaXRzIChxdW90ZSAoJChjYWxsIGluaXRzLCQoU1BBRFNFVF9JClRFTV8kKEMpXyQqKSkp
KSApIiA+PiAkKE1JRCkvdG1wL21rYXhfJCoubHNwW10gIAoKT3ZlcmZ1bGwgXGhib3ggKDE4My43
NDg0cHQgdG9vIHdpZGUpIGluIHBhcmFncmFwaCBhdCBsaW5lcyA4Ny0tODcKIFtdICAgICAgICBc
T1QxL2NtdHQvbS9uLzEwIEAoY2QgJChNSUQpOyBEQUFTRT0iJChEQUFTRSkiOyBleHBvcnQgREFB
U0U7ICQoSU5URQpSUFNZUyk7IHRydWUpIDwgJChNSUQpL3RtcC9ta2F4XyQqLmxzcCA+ICQoTUlE
KS90bXAvZ2VuXyQqLmxvZyAyPiYxW10gIApbMl0KT3ZlcmZ1bGwgXGhib3ggKDQ4OC4yNDU3NHB0
IHRvbyB3aWRlKSBpbiBwYXJhZ3JhcGggYXQgbGluZXMgMTAxLS0xMDEKIFtdICAgICAgICBcT1Qx
L2NtdHQvbS9uLzEwIEBlY2hvICcocHJvZ24gKGxvYWQgIiQoT0JKKS8kKFNZUykvaW50ZXJwL2Zv
YW1fbC5vIgopIChjb21waWxlLWZpbGUgIiQoZmlsdGVyICUubHNwLCReKSIgOm91dHB1dC1maWxl
ICIkQCIpICgke0JZRX0pKScgfCAke0RFUFNZU30gCj4gJChPQkopLyQoU1lTKS9hbGRvci9idWls
ZC8kKG5vdGRpciAkQCkubG9nIDtbXSAgCgpPdmVyZnVsbCBcaGJveCAoMTQ2Ljk5ODcycHQgdG9v
IHdpZGUpIGluIHBhcmFncmFwaCBhdCBsaW5lcyAxMDItLTEwMgogW10gICAgICAgIFxPVDEvY210
dC9tL24vMTAgQGlmIHRlc3QgLWYgJEA7IHRoZW4gZWNobyAiQnVpbHQgJChub3RkaXIgJEApIiA7
IGVsCnNlIGNhdCAkKE9CSikvJChTWVMpL2FsZG9yL2J1aWxkLyQobm90ZGlyICRAKS5sb2c7IGZh
bHNlOyBmaVtdICAKWzNdICguL01ha2UuYXhpb20uYXV4KSApCihzZWUgdGhlIHRyYW5zY3JpcHQg
ZmlsZSBmb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbikKT3V0cHV0IHdyaXR0ZW4gb24gTWFrZS5h
eGlvbS5kdmkgKDMgcGFnZXMsIDQ3MjQgYnl0ZXMpLgpUcmFuc2NyaXB0IHdyaXR0ZW4gb24gTWFr
ZS5heGlvbS5sb2cuCi9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9tbnQvbGlu
dXgvYmluL2RvY3VtZW50ICAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3Jj
L2FsZG9yL1NvcnQuamF2YQooY2QgJChkaXJuYW1lIC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlv
bS0tbWFpbi0tMS9zcmMvYWxkb3IvU29ydC5qYXZhKTsgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4
aW9tLS1tYWluLS0xL21udC9saW51eC9iaW4vZG9jdW1lbnQgIC9ob21lL3BhZ2UvcmVwb3NpdG9y
eS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvU29ydC5qYXZhKQpUaGlzIGlzIHBkZmVUZVgsIFZl
cnNpb24gMy4xNDE1OTItMS4yMWEtMi4yIChXZWIyQyA3LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQg
bW9kZQooLi9Tb3J0LmphdmEudGV4CkxhVGVYMmUgPDIwMDMvMTIvMDE+CkJhYmVsIDx2My44ZD4g
YW5kIGh5cGhlbmF0aW9uIHBhdHRlcm5zIGZvciBhbWVyaWNhbiwgZnJlbmNoLCBnZXJtYW4sIG5n
ZXJtYW4sIGIKYWhhc2EsIGJhc3F1ZSwgYnVsZ2FyaWFuLCBjYXRhbGFuLCBjcm9hdGlhbiwgY3pl
Y2gsIGRhbmlzaCwgZHV0Y2gsIGVzcGVyYW50bywgZQpzdG9uaWFuLCBmaW5uaXNoLCBncmVlaywg
aWNlbGFuZGljLCBpcmlzaCwgaXRhbGlhbiwgbGF0aW4sIG1hZ3lhciwgbm9yc2ssIHBvbGlzCmgs
IHBvcnR1Z2VzLCByb21hbmlhbiwgcnVzc2lhbiwgc2VyYmlhbiwgc2xvdmFrLCBzbG92ZW5lLCBz
cGFuaXNoLCBzd2VkaXNoLCB0dXIKa2lzaCwgdWtyYWluaWFuLCBub2h5cGhlbmF0aW9uLCBsb2Fk
ZWQuCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2UvYXJ0
aWNsZS5jbHMKRG9jdW1lbnQgQ2xhc3M6IGFydGljbGUgMjAwNC8wMi8xNiB2MS40ZiBTdGFuZGFy
ZCBMYVRlWCBkb2N1bWVudCBjbGFzcwooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0
L3RleC9sYXRleC9iYXNlL3NpemUxMC5jbG8pKQooLi4vc2NyaXB0cy90ZXgvYXhpb20uc3R5KQpO
byBmaWxlIFNvcnQuamF2YS5hdXguClsxXSBbMl0gWzNdIFs0XSBbNV0gWzZdIFs3XSBbOF0gWzld
IFsxMF0gWzExXSBbMTJdIFsxM10gWzE0XSBbMTVdIFsxNl0KT3ZlcmZ1bGwgXGhib3ggKDUuMjQ5
OTVwdCB0b28gd2lkZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDc0MC0tNzQwCiBbXSAgICAgICAg
ICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIG91dC5wcmludGxuKCJTUEFEU0VUX0lURU1fIiArIGRu
YW1lICsgIl8iICsKIG5vZGVTZXQuZ2V0TmFtZSgpICsgIiA6PSBcdFxcIik7W10gIAoKT3ZlcmZ1
bGwgXGhib3ggKDUuMjQ5OTVwdCB0b28gd2lkZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDc1Mi0t
NzUyCiBbXSAgICAgICAgICAgICAgICBcT1QxL2NtdHQvbS9uLzEwIG91dC5wcmludGxuKCJTUEFE
U0VUX0RFUFNfIiArIGRuYW1lICsgIl8iICsKIG5vZGVTZXQuZ2V0TmFtZSgpICsgIiA6PSBcdFxc
Iik7W10gIApbMTddIFsxOF0gWzE5XSAoLi9Tb3J0LmphdmEuYXV4KSApCihzZWUgdGhlIHRyYW5z
Y3JpcHQgZmlsZSBmb3IgYWRkaXRpb25hbCBpbmZvcm1hdGlvbikKT3V0cHV0IHdyaXR0ZW4gb24g
U29ydC5qYXZhLmR2aSAoMTkgcGFnZXMsIDI1NTIwIGJ5dGVzKS4KVHJhbnNjcmlwdCB3cml0dGVu
IG9uIFNvcnQuamF2YS5sb2cuClRoaXMgaXMgcGRmZVRlWCwgVmVyc2lvbiAzLjE0MTU5Mi0xLjIx
YS0yLjIgKFdlYjJDIDcuNS40KQplbnRlcmluZyBleHRlbmRlZCBtb2RlCiguL1NvcnQuamF2YS50
ZXgKTGFUZVgyZSA8MjAwMy8xMi8wMT4KQmFiZWwgPHYzLjhkPiBhbmQgaHlwaGVuYXRpb24gcGF0
dGVybnMgZm9yIGFtZXJpY2FuLCBmcmVuY2gsIGdlcm1hbiwgbmdlcm1hbiwgYgphaGFzYSwgYmFz
cXVlLCBidWxnYXJpYW4sIGNhdGFsYW4sIGNyb2F0aWFuLCBjemVjaCwgZGFuaXNoLCBkdXRjaCwg
ZXNwZXJhbnRvLCBlCnN0b25pYW4sIGZpbm5pc2gsIGdyZWVrLCBpY2VsYW5kaWMsIGlyaXNoLCBp
dGFsaWFuLCBsYXRpbiwgbWFneWFyLCBub3JzaywgcG9saXMKaCwgcG9ydHVnZXMsIHJvbWFuaWFu
LCBydXNzaWFuLCBzZXJiaWFuLCBzbG92YWssIHNsb3ZlbmUsIHNwYW5pc2gsIHN3ZWRpc2gsIHR1
cgpraXNoLCB1a3JhaW5pYW4sIG5vaHlwaGVuYXRpb24sIGxvYWRlZC4KKC91c3IvbG9jYWwvdGVU
ZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9hcnRpY2xlLmNscwpEb2N1bWVudCBD
bGFzczogYXJ0aWNsZSAyMDA0LzAyLzE2IHYxLjRmIFN0YW5kYXJkIExhVGVYIGRvY3VtZW50IGNs
YXNzCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2Uvc2l6
ZTEwLmNsbykpCiguLi9zY3JpcHRzL3RleC9heGlvbS5zdHkpICguL1NvcnQuamF2YS5hdXgpIFsx
XSBbMl0gWzNdIFs0XSBbNV0gWzZdIFs3XQpbOF0gWzldIFsxMF0gWzExXSBbMTJdIFsxM10gWzE0
XSBbMTVdIFsxNl0KT3ZlcmZ1bGwgXGhib3ggKDUuMjQ5OTVwdCB0b28gd2lkZSkgaW4gcGFyYWdy
YXBoIGF0IGxpbmVzIDc0MC0tNzQwCiBbXSAgICAgICAgICAgICAgICBcT1QxL2NtdHQvbS9uLzEw
IG91dC5wcmludGxuKCJTUEFEU0VUX0lURU1fIiArIGRuYW1lICsgIl8iICsKIG5vZGVTZXQuZ2V0
TmFtZSgpICsgIiA6PSBcdFxcIik7W10gIAoKT3ZlcmZ1bGwgXGhib3ggKDUuMjQ5OTVwdCB0b28g
d2lkZSkgaW4gcGFyYWdyYXBoIGF0IGxpbmVzIDc1Mi0tNzUyCiBbXSAgICAgICAgICAgICAgICBc
T1QxL2NtdHQvbS9uLzEwIG91dC5wcmludGxuKCJTUEFEU0VUX0RFUFNfIiArIGRuYW1lICsgIl8i
ICsKIG5vZGVTZXQuZ2V0TmFtZSgpICsgIiA6PSBcdFxcIik7W10gIApbMTddIFsxOF0gWzE5XSAo
Li9Tb3J0LmphdmEuYXV4KSApCihzZWUgdGhlIHRyYW5zY3JpcHQgZmlsZSBmb3IgYWRkaXRpb25h
bCBpbmZvcm1hdGlvbikKT3V0cHV0IHdyaXR0ZW4gb24gU29ydC5qYXZhLmR2aSAoMTkgcGFnZXMs
IDI1NTIwIGJ5dGVzKS4KVHJhbnNjcmlwdCB3cml0dGVuIG9uIFNvcnQuamF2YS5sb2cuCihqYXZh
YyAtZCAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvaW50L2FsZG9yIC9ob21l
L3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvU29ydC5qYXZhKQpOb3Rl
OiAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL1NvcnQuamF2
YSB1c2VzIHVuY2hlY2tlZCBvciB1bnNhZmUgb3BlcmF0aW9ucy4KTm90ZTogUmVjb21waWxlIHdp
dGggLVhsaW50OnVuY2hlY2tlZCBmb3IgZGV0YWlscy4KbWFrZVsxXTogKioqIE5vIHJ1bGUgdG8g
bWFrZSB0YXJnZXQgYC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9pbnQvYWxk
b3IvZGVwX3NwYWQuc3RhbXAnLCBuZWVkZWQgYnkgYC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlv
bS0tbWFpbi0tMS9pbnQvYWxkb3Ivc2F4aW9tL3NwYWRzZXQubWsnLiAgU3RvcC4KbWFrZVsxXTog
TGVhdmluZyBkaXJlY3RvcnkgYC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9z
cmMvYWxkb3InCm1ha2U6ICoqKiBbYWxsXSBFcnJvciAyCkJ1aWxkaW5nIGxpYmF4aW9tLmFsIGFu
ZCBhc3NvY2lhdGVkIGZpbGVzCi9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9p
bnQvYWxkb3IKbWFrZVsxXTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvaG9tZS9wYWdlL3JlcG9zaXRv
cnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yJwovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20t
LW1haW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXM6MzE6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9h
eGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5mdW5jdGlvbnM6IE5vIHN1Y2ggZmlsZSBvciBk
aXJlY3RvcnkKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci90
eXBlcy5tazo0NTogL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL2ludC9hbGRv
ci9hbGxfc3BhZF90eXBlcy5tazogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeQovaG9tZS9wYWdl
L3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL3R5cGVzLm1rOjQ2OiAvaG9tZS9w
YWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvaW50L2FsZG9yL2FsbF9zcGFkX2NhdHMubWs6
IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3RvcnkKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1t
YWluLS0xL3NyYy9hbGRvci90eXBlcy5tazoxNTY6IC9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlv
bS0tbWFpbi0tMS9pbnQvYWxkb3Ivc2F4aW9tL3NwYWRzZXQubWsgCi9ob21lL3BhZ2UvcmVwb3Np
dG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvTWFrZS5ydWxlczoxNzk6IEFMTCBTUEFEU0VU
UyAgc2F4MCBzYXhpb20KL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9h
bGRvci9NYWtlLnJ1bGVzOjIwMDogKDAsMCkKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1t
YWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1bGVzOjIwNDogL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4
aW9tLS1tYWluLS0xL2ludC9hbGRvci9zYXgwL3NwYWRzZXQubWs6IE5vIHN1Y2ggZmlsZSBvciBk
aXJlY3RvcnkKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9N
YWtlLnJ1bGVzOjIwMDogKDEsMSkKL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0x
L3NyYy9hbGRvci9NYWtlLnJ1bGVzOjIwNDogL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1t
YWluLS0xL2ludC9hbGRvci9zYXhpb20vc3BhZHNldC5tazogTm8gc3VjaCBmaWxlIG9yIGRpcmVj
dG9yeQovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2Uu
cnVsZXM6MjcxOiBubyBmaWxlIG5hbWUgZm9yIGAtaW5jbHVkZScKL2hvbWUvcGFnZS9yZXBvc2l0
b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRvci9NYWtlLnJ1bGVzOjI3MTogbm8gZmlsZSBuYW1l
IGZvciBgLWluY2x1ZGUnCi9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMv
YWxkb3IvTWFrZS5ydWxlczoxMDY6IFc6IDEgSTogMQovaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhp
b20tLW1haW4tLTEvc3JjL2FsZG9yL01ha2UucnVsZXM6MTA3OiBXOiAgICAgL2hvbWUvcGFnZS9y
ZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL2ludC9hbGRvci9zYXgwL3NwYWRzZXQubWsKL2hvbWUv
cGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL21udC9saW51eC9iaW4vZG9jdW1lbnQgIC9o
b21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3IvZ2VuYXgubHNwCihj
ZCAkKGRpcm5hbWUgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3NyYy9hbGRv
ci9nZW5heC5sc3ApOyAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvbW50L2xp
bnV4L2Jpbi9kb2N1bWVudCAgL2hvbWUvcGFnZS9yZXBvc2l0b3J5L2F4aW9tLS1tYWluLS0xL3Ny
Yy9hbGRvci9nZW5heC5sc3ApClRoaXMgaXMgcGRmZVRlWCwgVmVyc2lvbiAzLjE0MTU5Mi0xLjIx
YS0yLjIgKFdlYjJDIDcuNS40KQplbnRlcmluZyBleHRlbmRlZCBtb2RlCiguL2dlbmF4LmxzcC50
ZXgKTGFUZVgyZSA8MjAwMy8xMi8wMT4KQmFiZWwgPHYzLjhkPiBhbmQgaHlwaGVuYXRpb24gcGF0
dGVybnMgZm9yIGFtZXJpY2FuLCBmcmVuY2gsIGdlcm1hbiwgbmdlcm1hbiwgYgphaGFzYSwgYmFz
cXVlLCBidWxnYXJpYW4sIGNhdGFsYW4sIGNyb2F0aWFuLCBjemVjaCwgZGFuaXNoLCBkdXRjaCwg
ZXNwZXJhbnRvLCBlCnN0b25pYW4sIGZpbm5pc2gsIGdyZWVrLCBpY2VsYW5kaWMsIGlyaXNoLCBp
dGFsaWFuLCBsYXRpbiwgbWFneWFyLCBub3JzaywgcG9saXMKaCwgcG9ydHVnZXMsIHJvbWFuaWFu
LCBydXNzaWFuLCBzZXJiaWFuLCBzbG92YWssIHNsb3ZlbmUsIHNwYW5pc2gsIHN3ZWRpc2gsIHR1
cgpraXNoLCB1a3JhaW5pYW4sIG5vaHlwaGVuYXRpb24sIGxvYWRlZC4KKC91c3IvbG9jYWwvdGVU
ZVgvc2hhcmUvdGV4bWYtZGlzdC90ZXgvbGF0ZXgvYmFzZS9hcnRpY2xlLmNscwpEb2N1bWVudCBD
bGFzczogYXJ0aWNsZSAyMDA0LzAyLzE2IHYxLjRmIFN0YW5kYXJkIExhVGVYIGRvY3VtZW50IGNs
YXNzCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2Uvc2l6
ZTEwLmNsbykpCiguLi9zY3JpcHRzL3RleC9heGlvbS5zdHkpCk5vIGZpbGUgZ2VuYXgubHNwLmF1
eC4KWzFdIFsyXQpPdmVyZnVsbCBcaGJveCAoMzYuNzQ5NjhwdCB0b28gd2lkZSkgaW4gcGFyYWdy
YXBoIGF0IGxpbmVzIDEwNi0tMTA2CiBbXSAgICAgICAgICAgICAgICAgIFxPVDEvY210dC9tL24v
MTAgKHBwcmludCAoYXBwZW5kICAofG1ha2VBeEV4cG9ydEZvcm18IGZuYW0KZSAobWFwY2FuICd8
ZmlsZUNvbnN0cnVjdG9yc3wgY29udGVudCkpW10gIApbM10gWzRdCk92ZXJmdWxsIFxoYm94ICg1
Mi40OTk1NHB0IHRvbyB3aWRlKSBpbiBwYXJhZ3JhcGggYXQgbGluZXMgMTY1LS0xNjUKIFtdICAg
ICAgICBcT1QxL2NtdHQvbS9uLzEwICh3aXRoLW9wZW4tZmlsZSAoZGVwc3RyIChkZXAtZmlsZS1u
YW1lIChwYXRobmFtZS1uYQptZSAocGF0aG5hbWUgaW5maWxlKSkpIDpkaXJlY3Rpb24gOm91dHB1
dClbXSAgCls1XSBbNl0gWzddIFs4XSBbOV0gWzEwXSBbMTFdIFsxMl0gKC4vZ2VuYXgubHNwLmF1
eCkgKQooc2VlIHRoZSB0cmFuc2NyaXB0IGZpbGUgZm9yIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24p
Ck91dHB1dCB3cml0dGVuIG9uIGdlbmF4LmxzcC5kdmkgKDEyIHBhZ2VzLCAxOTAyOCBieXRlcyku
ClRyYW5zY3JpcHQgd3JpdHRlbiBvbiBnZW5heC5sc3AubG9nLgpUaGlzIGlzIHBkZmVUZVgsIFZl
cnNpb24gMy4xNDE1OTItMS4yMWEtMi4yIChXZWIyQyA3LjUuNCkKZW50ZXJpbmcgZXh0ZW5kZWQg
bW9kZQooLi9nZW5heC5sc3AudGV4CkxhVGVYMmUgPDIwMDMvMTIvMDE+CkJhYmVsIDx2My44ZD4g
YW5kIGh5cGhlbmF0aW9uIHBhdHRlcm5zIGZvciBhbWVyaWNhbiwgZnJlbmNoLCBnZXJtYW4sIG5n
ZXJtYW4sIGIKYWhhc2EsIGJhc3F1ZSwgYnVsZ2FyaWFuLCBjYXRhbGFuLCBjcm9hdGlhbiwgY3pl
Y2gsIGRhbmlzaCwgZHV0Y2gsIGVzcGVyYW50bywgZQpzdG9uaWFuLCBmaW5uaXNoLCBncmVlaywg
aWNlbGFuZGljLCBpcmlzaCwgaXRhbGlhbiwgbGF0aW4sIG1hZ3lhciwgbm9yc2ssIHBvbGlzCmgs
IHBvcnR1Z2VzLCByb21hbmlhbiwgcnVzc2lhbiwgc2VyYmlhbiwgc2xvdmFrLCBzbG92ZW5lLCBz
cGFuaXNoLCBzd2VkaXNoLCB0dXIKa2lzaCwgdWtyYWluaWFuLCBub2h5cGhlbmF0aW9uLCBsb2Fk
ZWQuCigvdXNyL2xvY2FsL3RlVGVYL3NoYXJlL3RleG1mLWRpc3QvdGV4L2xhdGV4L2Jhc2UvYXJ0
aWNsZS5jbHMKRG9jdW1lbnQgQ2xhc3M6IGFydGljbGUgMjAwNC8wMi8xNiB2MS40ZiBTdGFuZGFy
ZCBMYVRlWCBkb2N1bWVudCBjbGFzcwooL3Vzci9sb2NhbC90ZVRlWC9zaGFyZS90ZXhtZi1kaXN0
L3RleC9sYXRleC9iYXNlL3NpemUxMC5jbG8pKQooLi4vc2NyaXB0cy90ZXgvYXhpb20uc3R5KSAo
Li9nZW5heC5sc3AuYXV4KSBbMV0gWzJdCk92ZXJmdWxsIFxoYm94ICgzNi43NDk2OHB0IHRvbyB3
aWRlKSBpbiBwYXJhZ3JhcGggYXQgbGluZXMgMTA2LS0xMDYKIFtdICAgICAgICAgICAgICAgICAg
XE9UMS9jbXR0L20vbi8xMCAocHByaW50IChhcHBlbmQgICh8bWFrZUF4RXhwb3J0Rm9ybXwgZm5h
bQplIChtYXBjYW4gJ3xmaWxlQ29uc3RydWN0b3JzfCBjb250ZW50KSlbXSAgClszXSBbNF0KT3Zl
cmZ1bGwgXGhib3ggKDUyLjQ5OTU0cHQgdG9vIHdpZGUpIGluIHBhcmFncmFwaCBhdCBsaW5lcyAx
NjUtLTE2NQogW10gICAgICAgIFxPVDEvY210dC9tL24vMTAgKHdpdGgtb3Blbi1maWxlIChkZXBz
dHIgKGRlcC1maWxlLW5hbWUgKHBhdGhuYW1lLW5hCm1lIChwYXRobmFtZSBpbmZpbGUpKSkgOmRp
cmVjdGlvbiA6b3V0cHV0KVtdICAKWzVdIFs2XSBbN10gWzhdIFs5XSBbMTBdIFsxMV0gWzEyXSAo
Li9nZW5heC5sc3AuYXV4KSApCihzZWUgdGhlIHRyYW5zY3JpcHQgZmlsZSBmb3IgYWRkaXRpb25h
bCBpbmZvcm1hdGlvbikKT3V0cHV0IHdyaXR0ZW4gb24gZ2VuYXgubHNwLmR2aSAoMTIgcGFnZXMs
IDE5MDI4IGJ5dGVzKS4KVHJhbnNjcmlwdCB3cml0dGVuIG9uIGdlbmF4LmxzcC5sb2cuCkNyZWF0
aW5nIGRlcGVuZGVuY2llcyBmb3Igc3BhZCBDOiAxMDQyCm1ha2VbMV06IFsvaG9tZS9wYWdlL3Jl
cG9zaXRvcnkvYXhpb20tLW1haW4tLTEvaW50L2FsZG9yL2RlcF9zcGFkLnN0YW1wXSBFcnJvciAy
NTUgKGlnbm9yZWQpCi9iaW4vc2g6IC1jOiBsaW5lIDE6IHN5bnRheCBlcnJvciBuZWFyIHVuZXhw
ZWN0ZWQgdG9rZW4gYDsnCi9iaW4vc2g6IC1jOiBsaW5lIDE6IGAoZm9yIGkgaW4gQTFBR0cgQUJF
TEdSUCBBQkVMTU9OIEFCRUxTRyBBQ0YgQUNGUyBBQ1BMT1QgQUYgQUdHIEFIWVAgQUxBR0cgQUxH
RUJSQSBBTEdGQUNUIEFMR0ZGIEFMR01BTklQIEFMR01GQUNUIEFMR1BLRyBBTEdTQyBBTElTVCBB
TVIgQU5PTiBBTiBBTlRJU1lNIEFOWTEgQU5ZIEFQUExZT1JFIEFQUFJVTEUgQVJSMkNBVCBBUlJB
WTEyIEFSUkFZMSBBUlJBWTIgQVNQMTAgQVNQMTIgQVNQMTkgQVNQMSBBU1AyMCBBU1AyNCBBU1Ay
NyBBU1AyOCBBU1AyOSBBU1AzMCBBU1AzMSBBU1AzMyBBU1AzNCBBU1AzNSBBU1A0MSBBU1A0MiBB
U1A0OSBBU1A0IEFTUDUwIEFTUDU1IEFTUDYgQVNQNzMgQVNQNzQgQVNQNzcgQVNQNzggQVNQNyBB
U1A4MCBBU1A4IEFTUDkgQVNTT0NFUSBBU1RBQ0sgQVRSSUcgQVRUUkJVVCBBVFRSRUcgQVVUT01P
UiBCQUxGQUNUIEJBU1RZUEUgQkJUUkVFIEJFWk9VVCBCRlVOQ1QgQkdBR0cgQklOQVJZIEJJTkZJ
TEUgQklUUyBCTU9EVUxFIEJPT0xFQU4gQk9QMSBCT1AgQk9VTkRaUk8gQlBBRElDUlQgQlBBRElD
IEJSQUdHIEJSSUxMIEJTVFJFRSBCVEFHRyBCVENBVCBCVE9VUk4gQlRSRUUgQ0FCTU9OIENBQ0hT
RVQgQ0FSRCBDQVJURU4yIENBUlRFTiBDQ0xBU1MgQ0RFTiBDRkNBVCBDSEFSTlogQ0hBUlBPTCBD
SEFSIENIQVJaIENIVkFSIENJTlRTTFBFIENMQUdHIENMSUYgQ0xJUCBDTVBMWFJUIENPTE9SIENP
TUJGIENPTUJJTkFUIENPTUJPUEMgQ09NTU9OT1AgQ09NTSBDT01NVVBDIENPTVBDQVQgQ09NUEZB
Q1QgQ09NUExFWDIgQ09NUExFWCBDT01QTFBBVCBDT01QUFJPUCBDT01SSU5HIENPTlRGUkFDIENP
T1JEU1lTIENQSU1BIENQTUFUQ0ggQ1JBUEFDSyBDUkZQIENTVFRPT0xTIENUUklHTU5QIENWTVAg
Q1lDTEVTIENZQ0xPVE9NIEQwMUFHTlQgRDAxQUpGQSBEMDFBS0ZBIEQwMUFMRkEgRDAxQU1GQSBE
MDFBTkZBIEQwMUFQRkEgRDAxQVFGQSBEMDFBU0ZBIEQwMUZDRkEgRDAxR0JGQSBEMDFUUk5TIEQw
MVdHVFMgRDAyQUdOVCBEMDJCQkZBIEQwMkJIRkEgRDAyQ0pGQSBEMDJFSkZBIEQwM0FHTlQgRDAz
RUVGQSBEMDNGQUZBIERCQVNFIERCTFJFU1AgRERGQUNUIERFQ0lNQUwgREVGSU5URUYgREVGSU5U
UkYgREVHUkVEIERFUVVFVUUgREVSSEFNIERGSU5UVExTIERGTE9BVCBERlNGVU4gREhNQVRSSVgg
RElBR0cgRElGRVhUIERJRlJJTkcgRElPUFMgRElPU1AgRElSUENBVCBESVJQUk9EMiBESVJQUk9E
IERJU1BMQVkgRElWUklORyBETEFHRyBETElTVCBETFAgRE1QIERQTU0gRFBNTyBEUE9MQ0FUIERR
QUdHIERSQVdDRlVOIERSQVdDVVJWIERSQVdDWCBEUkFXSEFDSyBEUkFXUFQgRFJBVyBEUk9QVDAg
RFJPUFQxIERST1BUIERTTVAgRFZBUkNBVCBFMDRBR05UIEUwNERHRkEgRTA0RkRGQSBFMDRHQ0ZB
IEUwNEpBRkEgRTA0TUJGQSBFMDROQUZBIEUwNFVDRkEgRUFCIEVGIEVGU1RSVUMgRUZVTFMgRUZV
UFhTIEVMQUdHIEVMRU1GVU4gRUxGVVRTIEVMVEFCIEVMVEFHRyBFTVIgRU5USVJFUiBFUCBFUTIg
RVEgRVFUQkwgRVJST1IgRVMxIEVTMiBFU0NPTlQxIEVTQ09OVCBFUyBFU1RPT0xTMSBFU1RPT0xT
MiBFU1RPT0xTIEVVQ0RPTSBFVkFMQUIgRVZBTENZQyBFWElUIEVYUEVYUEFOIEVYUFIyIEVYUFIy
VVBTIEVYUFJPREUgRVhQUiBFWFBSVFVCRSBFWFBVUFhTIEZBQ1RGVU5DIEZBQ1VUSUwgRkFHUk9V
UCBGQU1PTkMgRkFNT05PSUQgRkFNUiBGQVJSQVkgRkFYRiBGQ09NUCBGQ1BBSzEgRkMgRkRJVjIg
RkRJVkNBVCBGRElWIEZFVkFMQUIgRkVYUFIgRkZDQVQyIEZGQ0FUIEZGQ0dQIEZGQ0cgRkZDR1gg
RkZGIEZGSE9NIEZGSUVMREMgRkZJTlRCQVMgRkZOQlAgRkZOQiBGRk5CWCBGRlBPTFkyIEZGUE9M
WSBGRlAgRkZTTFBFIEZGIEZGWCBGR0xNSUNQSyBGR1JPVVAgRklFTEQgRklMRUNBVCBGSUxFIEZJ
TkFBTEcgRklOSVRFIEZJTlJBTEcgRkxBR0cyIEZMQUdHIEZMQUxHIEZMQVNPUlQgRkxJTkVYUCBG
TE9BVENQIEZMT0FUUlAgRkxPQVQgRk0xIEZNQ0FUIEZNQyBGTUZVTiBGTU9OT0lEIEZNIEZNVEMg
Rk5BTUUgRk5DQVQgRk5MQSBGT1AgRk9SREVSIEZPUk1VTEExIEZPUk1VTEEgRk9SVENBVCBGT1JU
Rk4gRk9SVFJBTiBGT1JUIEZQQVJGUkFDIEZQQVRNQUIgRlBDIEZQUyBGUjIgRlJBQzIgRlJBQyBG
UkFNQUxHIEZSRVRSQ1QgRlJJREVBTDIgRlJJREVBTCBGUk1PRCBGUk5BQUYyIEZSTkFBTEcgRlIg
RlJVVElMIEZTMkVYUFhQIEZTMiBGUzJVUFMgRlNBR0cyIEZTQUdHIEZTQ0lOVCBGU0VSSUVTIEZT
SU5UIEZTUEVDRiBGU1BSTUVMVCBGU1JFRCBGUyBGU1QgRlNVUEZBQ1QgRlRFTSBGVCBGVU5DVElP
TiBGVkMgRlZGVU4gR0FMRkFDVCBHQUxGQUNUVSBHQUxQT0xZVSBHQUxVVElMIEdBVVNTRkFDIEdC
RVVDTElEIEdCRiBHQklOVEVSTiBHQiBHQ0RET00gR0NOQUFMRyBHRE1QIEdFTkVFWiBHRU5NRkFD
VCBHRU5QR0NEIEdFTlVGQUNUIEdFTlVQUyBHSEVOU0VMIEdNT0RQT0wgR09TUEVSIEdQT0xTRVQg
R1JBTEcgR1JBWSBHUkRFRiBHUklNQUdFIEdSTU9EIEdST0VCU09MIEdST1VQIEdTRVJJRVMgR1NU
QkwgR1RTRVQgSEFDS1BJIEhBU0hUQkwgSEIgSERNUCBIRFAgSEVBUCBIRUxMRkRJViBIRVVHQ0Qg
SEVYQURFQyBIT0FHRyBIWVBDQVQgSUFMR0ZBQ1QgSUFOIElBUlJBWTEgSUFSUkFZMiBJQkFDSElO
IElCQVRPT0wgSUJJVFMgSUJQVE9PTFMgSUNBUkQgSUNERU4gSURFQUwgSURFQ09NUCBJRFBBRyBJ
RFBBTSBJRFBDIElEUE9BTSBJRFBPQU1TIElEUE8gSUVWQUxBQiBJRkFNT04gSUZBUlJBWSBJRkYg
SUlBUlJBWTIgSUxJU1QgSU1BVExJTiBJTUFUUUYgSU1BVFJJWCBJTkJGRiBJTkNSTUFQUyBJTkRF
IElORVAgSU5GSU5JVFkgSU5GT1JNMSBJTkZPUk0gSU5GUFJPRDAgSU5GU1AgSU5NT0RHQ0QgSU5O
TUZBQ1QgSU5QUk9ERkYgSU5QUk9EUEYgSU5QU0lHTiBJTlMgSU5UQUJMIElOVEFGIElOVEFMRyBJ
TlRCSVQgSU5UQ0FUIElOVERPTSBJTlRFRiBJTlRGQUNUIElOVEZUQkwgSU5URzAgSU5USEVPUlkg
SU5USEVSQUwgSU5USEVSVFIgSU5UUEFDSyBJTlRQQUYgSU5UUE0gSU5UUkFUIElOVFJFVCBJTlRS
RiBJTlRSVkwgSU5UU0xQRSBJTlQgSU5UVE9PTFMgSU5UVFIgSU5WTEFQTEEgSVBBRElDIElQRiBJ
UFJOVFBLIElSMkYgSVIyIElST09UIElSUkVERkZYIElSUkYyRiBJUlNOIElSIElSVVJQSyBJU1RS
SU5HIElTVU1QIElTVVBTIElUQVlMT1IgSVRGVU4yIElURlVOMyBJVFJJR01OUCBJVFVQTEUgSVZF
Q1RPUiBJWEFHRyBKT1JEQU4gS0FGSUxFIEtEQUdHIEtFUk5FTDIgS0VSTkVMIEtPRVJDRSBLT05W
RVJUIEtPVkFDSUMgTEFMRyBMQVBMQUNFIExBIExBVVBPTCBMQVpNM1BLIExFQURDREVUIExFWFAg
TEVYVFJJUEsgTEZDQVQgTEYgTEdST0JQIExJQiBMSUVDQVQgTElFIExJTUlUUFMgTElNSVRSRiBM
SU5ERVAgTElORVhQIExJU1QyTUFQIExJU1QyIExJU1QzIExJU1QgTE1ESUNUIExNT0RVTEUgTE1P
UFMgTE5BR0cgTE9ERUVGIExPRE8xIExPRE8yIExPRE9DQVQgTE9ET0YgTE9ET09QUyBMT0RPIExP
R0lDIExPIExQRUZSQUMgTFBPTFkgTFNBR0cgTFNNUDEgTFNNUCBMU1BQIExTUU0gTFdPUkQgTFpT
VEFHRyBNM0QgTUFHTUEgTUFQSEFDSzEgTUFQSEFDSzIgTUFQSEFDSzMgTUFQUEtHMSBNQVBQS0cy
IE1BUFBLRzMgTUFUQ0FUMiBNQVRDQVQgTUFUTElOIE1BVFJJWCBNQVRTVE9SIE1DQUxDRk4gTUNE
RU4gTUNNUExYIE1EQUdHIE1EREZBQ1QgTUVTSCBNRklORkFDVCBNRkxPQVQgTUhST1dSRUQgTUlO
VCBNS0JDRlVOQyBNS0NIU0VUIE1LRkxDRk4gTUtGVU5DIE1LUkVDT1JEIE1LVUNGVU5DIE1MSUZU
IE1MTyBNTUFQIE1PREZJRUxEIE1PRE1PTk9NIE1PRE1PTiBNT0RPUCBNT0RSSU5HIE1PRFVMRSBN
T0VCSVVTIE1PTkFEIE1PTkFEV1UgTU9OT0dFTiBNT05PSUQgTU9OT1RPT0wgTVBDMiBNUEMzIE1Q
Q1BGIE1QT0xZIE1QUkZGIE1SQVRGQUMgTVJGMiBNUklORyBNU0VUQUdHIE1TRVQgTVNZU0NNRCBN
VEhJTkcgTVRTQ0FUIE1VTFRGQUNUIE1VTFRTUUZSIE5BQUxHIE5BR0MwMiBOQUdDMDUgTkFHQzA2
IE5BR0QwMSBOQUdEMDIgTkFHRDAzIE5BR0UwMSBOQUdFMDIgTkFHRTA0IE5BR0YwMSBOQUdGMDIg
TkFHRjA0IE5BR0YwNyBOQUdTUCBOQUdTIE5BUk5HIE5BU1JJTkcgTkNFUCBOQ05URlJBQyBOQ09E
SVYgTkZJTlRCQVMgTklQUk9CIE5MSU5TT0wgTk5JIE5PREUxIE5PTkUxIE5PTkUgTk9STU1BIE5P
Uk1QSyBOT1JNUkVUUiBOUENPRUYgTlJFUCBOU01QIE5TVVAyIE5TVVAgTlRQT0xGTiBOVFNDQVQg
TlVNRVJJQyBOVU1GTVQgTlVNSU5UIE5VTU9ERSBOVU1RVUFEIE5VTVRVQkUgT0FHUk9VUCBPQU1P
TiBPQU1PTlMgT0FTR1AgT0NBTU9OIE9DIE9DVENUMiBPQ1QgT0RFQ0FUIE9ERUNPTlNUIE9ERUVG
IE9ERUlGVEJMIE9ERUlOVCBPREVQQUNLIE9ERVBBTCBPREVQUklNIE9ERVBST0IgT0RFUFJSSUMg
T0RFUkFUIE9ERVJFRCBPREVSVFJJQyBPREVTWVMgT0RFVE9PTFMgT0RQT0wgT0RQIE9EUiBPRFZB
UiBPRk1PTk9JRCBPSU5URE9NIE9NQ09OTiBPTURFViBPTUVOQyBPTUVSUksgT01FUlIgT01FWFBS
IE9NTE8gT01QS0cgT01TQUdHIE9NU0VSVkVSIE9NIE9ORUNPTVAyIE9ORUNPTVAgT1BRVUVSWSBP
UCBPUFRDQVQgT1BUUEFDSyBPUFRQUk9CIE9SRENPTVAyIE9SRENPTVAgT1JERklOIE9SREZVTlMg
T1JETU9OIE9SRFJJTkcgT1JEU0VUIE9SRVBDQVQgT1JFUENUTyBPUkVTVVAgT1JFVVAgT1JUSFBP
TCBPU0kgT1VURk9STSBPVVQgT1ZBUiBPV1AgUEFERVBBQyBQQURFIFBBRElDQ1QgUEFESUNSQVQg
UEFESUNSQyBQQURJQyBQQUxFVFRFIFBBTjJFWFBSIFBBUlBDMiBQQVJQQ1VSViBQQVJTQzIgUEFS
U0NVUlYgUEFSU1UyIFBBUlNVUkYgUEFSVFBFUk0gUEFUQUIgUEFUTFJFUyBQQVRNQUIgUEFUTUFU
Q0ggUEFUUkVTMiBQQVRSRVMgUEFUVEVSTjEgUEFUVEVSTjIgUEFUVEVSTiBQQldMQiBQQ09NUCBQ
REVDQVQgUERFQ09NUCBQREVQQUNLIFBERVBST0IgUERSSU5HIFBFTkRUUkVFIFBFUk1BTiBQRVJN
Q0FUIFBFUk1HUlAgUEVSTSBQRkJSIFBGQlJVIFBGRUNBVCBQRk9RIFBGTyBQRk9UT09MUyBQRlJQ
QUMgUEZSIFBGIFBHQ0QgUEdFIFBHUk9FQiBQSUNPRVJDRSBQSUQgUElOVEVSUEEgUElOVEVSUCBQ
SSBQTEVRTiBQTE9UMSBQTE9UM0QgUExPVCBQTE9UVE9PTCBQTUFTU0ZTIFBNQVNTIFBNRE9XTiBQ
TUZTIFBNSU5TIFBNS0VSTkVMIFBNTFNBR0cgUE1QTENBVCBQTVBSRURGUyBQTVBSRUQgUE1RRkNB
VCBQTVNZTSBQTVRPT0xTIFBOVEhFT1JZIFBPSU5UIFBPTFRPUE9MIFBPTFVUSUwgUE9MWTIgUE9M
WTJVUCBQT0xZQ0FUUSBQT0xZQ0FUIFBPTFlMSUZUIFBPTFlST09UIFBPTFkgUFBDVVJWRSBQUkVB
U1NPQyBQUklNQVJSMiBQUklNQVJSIFBSSU1DQVQgUFJJTUVMVCBQUklNRVMgUFJJTlQgUFJPRFVD
VCBQUlFBR0cgUFIgUFJTIFBSVElUSU9OIFBTQ0FUIFBTQ1VSVkUgUFNFVENBVCBQU0VUUEsgUFNF
VURMSU4gUFNRRlIgUFRDQVQgUFRGVU5DMiBQVFBBQ0sgUFRSQU5GTiBQVVNIVkFSIFBXRkZJTlRC
IFFBTEdTRVQyIFFBTEdTRVQgUUNNUEFDSyBRRVFVQVQgUUZDQVQyIFFGQ0FUIFFGT1JNIFFVQUdH
IFFVQVRDQVQgUVVBVENUMiBRVUFUIFFVRVVFIFJBRENBVCBSQURGRiBSQURJWCBSQURVVElMIFJB
TkRTUkMgUkFURkFDVCBSQVRSRVQgUkNBR0cgUkNGSUVMRCBSREVFRiBSREVFRlMgUkRFVFIgUkRF
VFJTIFJESVNUIFJESVYgUkVBTDBRIFJFQUwwIFJFQUxTT0xWIFJFQUwgUkVDTE9TIFJFRE9SREVS
IFJFRiBSRUdTRVQgUkVQMSBSRVAyIFJFUERCIFJFUCBSRVBTUSBSRVNMQVRDIFJFU1JJTkcgUkVT
VUxUIFJFVFJBQ1QgUkVUU09MIFJGRElTVCBSRkZBQ1RPUiBSRkZBQ1QgUkYgUkdDSEFJTiBSSURJ
U1QgUklORyBSSU5URVJQIFJNQVRDQVQgUk1BVFJJWCBSTUNBVDIgUk1PRFVMRSBSTkcgUk5TIFJP
SVJDIFJPTUFOIFJPVVRJTkUgUlBPTENBVCBSUkNDIFJTRENNUEsgUlNFVENBVCBSU0VUR0NEIFJV
TEVDT0xEIFJVTEVTRVQgUlVMRSBSVVJQSyBTQUVGQUNUIFNBRVJGRkMgU0FFIFNBT1MgU0NBQ0hF
IFNDUEtHIFNEUE9MIFNEVkFSIFNFRzIgU0VHQklORDIgU0VHQklORCBTRUdDQVQgU0VHIFNFR1hD
QVQgU0VUQUdHIFNFVENBVCBTRVRNTiBTRVQgU0VYQ0FUIFNFWE9GIFNFWCBTRk9SVCBTRlFDTVBL
IFNGUkdDRCBTRlJUQ0FUIFNHQ0YgU0dST1VQIFNIRFAgU0hQIFNJR05FRiBTSUdOUkYgU0lNUEFO
IFNJTlQgU0tBR0cgU01BVENBVCBTTUlUSCBTTVAgU01UUyBTTlRTQ0FUIFNPTFZFRk9SIFNPTFZF
UkFEIFNPTFZFU0VSIFNPTFZFVFJBIFNPUlRQQUsgU1BBQ0UzIFNQQUNFQyBTUEVDT1VUIFNQRkNB
VCBTUExOT0RFIFNQTFRSRUUgU1FNQVRSSVggU1JBR0cgU1JEQ01QSyBTUkVHU0VUIFNUQUNLIFNU
QUdHIFNUQkwgU1RFUCBTVElOUFJPRCBTVFJFQU0xIFNUUkVBTTIgU1RSRUFNMyBTVFJFQU0gU1RS
SUNBVCBTVFJJTkcgU1RSVEJMIFNUVEFZTE9SIFNUVEZOQyBTVFRGIFNVQlJFU1AgU1VCU1BBQ0Ug
U1VDSCBTVUxTIFNVTUZTIFNVTVJGIFNVUDIgU1VQRlJBQ0YgU1VQIFNVUFhTIFNVVFMgU1dJVENI
IFNZTUJPTCBTWU1GVU5DIFNZTVBPTFkgU1lNUyBTWU1UQUIgU1lTU09MUCBUQUJMQlVNUCBUQUJM
RUFVIFRBQkxFIFRBTkVYUCBUQkFHRyBUQkNNUFBLIFRFTVVUTCBURVgxIFRFWCBURVhURklMRSBU
T09MU0lHTiBUT1BTUCBUUkFORlVOIFRSRUUgVFJJR0NBVCBUUklHTU5JUCBUUklNQVQgVFJNQU5J
UCBUU0VUQ0FUIFRTIFRVQkUgVFVCRVRPT0wgVFVQTEUgVFdPRkFDVCBUWVBFIFVEUE8gVURWTyBV
RkQgVUxTMiBVTFNDQVQgVUxTQ0NBVCBVTFNDT05TIFVMUyBVTklGQUNUIFVOSVNFRzIgVU5JU0VH
IFVQMiBVUENERU4gVVBERUNPTVAgVVBESVZQIFVQTVAgVVBPTFlDMiBVUE9MWUMgVVBTQ0FUIFVQ
IFVQU1FGUkVFIFVQWFMyIFVQWFNDQVQgVVBYU0NDQSBVUFhTQ09OUyBVUFhTU0lORyBVUFhTIFVS
QUdHIFVUUzIgVVRTQ0FUIFVUU09ERSBVVFNPREVUTCBVVFMgVkFSSUFCTEUgVkVDVENBVCBWRUNU
T1IyIFZFQ1RPUiBWSUVXMkQgVklFVzNEIFZJRVdERUYgVklFVyBWT0lEIFZTUEFDRSBXRUlFUiBX
RkZJTlRCUyBXUCBXVVRTRVQgWEFMRyBYRFBPTFkgWEVYUFBLRyBYRkFMRyBYRiBYUEJXUE9MWSBY
UE9MWUMgWFBPTFkgWFBSIFhSUE9MWSBZU1RSRUFNIFpEU09MVkUgWkxJTkRFUCBaTU9EOyAgZG8g
IGNhdCAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1haW4tLTEvaW50L2FsZG9yL2dlbmRl
cHMvJGkuZGVwIHwgc29ydCB8IHVuaXEgPiAvaG9tZS9wYWdlL3JlcG9zaXRvcnkvYXhpb20tLW1h
aW4tLTEvaW50L2FsZG9yL2dlbmRlcHMvJGkudG1wOwkgbXYgL2hvbWUvcGFnZS9yZXBvc2l0b3J5
L2F4aW9tLS1tYWluLS0xL2ludC9hbGRvci9nZW5kZXBzLyRpLnRtcCAvaG9tZS9wYWdlL3JlcG9z
aXRvcnkvYXhpb20tLW1haW4tLTEvaW50L2FsZG9yL2dlbmRlcHMvJGk7CQkJIDsgIGRvbmUpJwpt
YWtlWzFdOiAqKiogWy9ob21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9pbnQvYWxk
b3IvZGVwX3NwYWQuc3RhbXBdIEVycm9yIDIKbWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgYC9o
b21lL3BhZ2UvcmVwb3NpdG9yeS9heGlvbS0tbWFpbi0tMS9zcmMvYWxkb3InCm1ha2U6ICoqKiBb
YWxsXSBFcnJvciAyCg==

\start
Date: Wed, 24 Aug 2005 18:02:26 -0400
From: Bill Page
To: list
Subject: Re: Unit package question

Axiom Developers;

I think the continuing exchange on the units package for Axiom is
very interesting and potentially useful to a wider audience, therefore
I have created an initial summary of the discussion on the design
here:

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

The authors (and other interested parties!) are invited to review
these wiki pages and update/correct/edit them as seems appropriate.
New pages on this subject can also easily be added. I would like
these pages to gradually evolve to reflect design decisions and
trial code segments as this package is developed.

Thanks everyone!

\start
Date: Wed, 24 Aug 2005 19:13:00 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [MathAction] 

!TouchGraph Navigator

  MathAction has grown rapidly over the last year. This grpahic
generated by the ToughGraph navigator interface should give you
a general idea of the amount of Axiom related information
available here.

<img src="/mathaction-now.png" />

Web Site

  The !MathAction development home page is --
  http://page.axiom-developer.org

  The Axiom Portal is at --
  http://page.axiom-developer.org/zope/Plone

  This web site is --
  http://page.axiom-developer.org/zope/mathaction

  The test and development version of !MathAction is --
  http://test.axiom-developer.org

  The development repository (darcs) for !MathAction is --
  MathActionRepository

\start
Date: Wed, 24 Aug 2005 18:59:37 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package question - Reply to 1st half

--- William Sit wrote:

> C Y wrote:
> 
> > I would vote yes, because I can't predict what I'll want to 
> > do with my unit environment. I can't imagine all the
> > ways and situations units can be applied, so I don't want to
> > restrict the user runtime environments that can be set up and 
> > customized.
> 
> Fair enough. But there is no reason why one cannot first convert
> ft to m, use SI as is, then convert back from m to ft.  If a user
> really want to use ft instead of m but retain all other SI units 
> ALWAYS, then create a MYUnitSystem domain, and use )set unit 
> MYUnitSystem. The implementation would be so much easier and
> you still retain the flexibility. Flexibility and generality may
> complicate usage as well as simplify usage. We have to balance 
> the them.

Agreed.  What about this - create such a domain as the "default"
domain, "use" SI units for defaults, and provide tools for the user to
make changes?  The changes would occur within the Default "working"
unit domain, assuming any were made - otherwise, it would look just
like the SI domain.  If one wanted to work in an environment which flat
out disallowed such setting changes, )set UnitSystem SI (or whatever
system desired) would take the user to the system defined SI domain
instead of the Default environment.  Does this map to what Axiom can
do?
 
> > But it should be doable, readily, IMHO.  That's what computers 
> > are for - to handle the grunt work associated with such 
> > decisions.
> 
> As long as you are willing to do the programming :-)

Hehe - fair enough!  In fact, I think such things can be built as a
layer on top of your system, which is undoubtedly the most robust way
to handle things.  So I vote for doing it your way, and then if I
really want some of what I say I want it can be implimented on top of
the core system.
 
> > There is also the case where you want to know what
> > quantity/dimension an expression is.
>
> Reverse dimensional analysis, is useful for providing the user 
> with possibly different interpretation of the dimension of an 
> expression. Checking dimensional correctness is a different, 
> though related, issue.

Ah :-). Thanks for helping clarify all of this - it's definitely
broadened my understanding of units/dimensions/etc. :-).
 
> > > Don't mix unit systems! Convert first before you start the
> > > computations, and convert back if you really have to.
> 
> > But that's just it - part of the reason for implementing a Unit
> > system in a CAS in the first place is to get it to do all the
> > converting and other annoyingly boring and error prone tasks for
> >  you - both for input and output.
> 
> Sure, but that does not mean one has to do it for all possible
> conversions, only the most useful ones should be provided, with
> functionality that allows, though not as convenient, the very 
> special user to change units.

OK, point.  As a possible future extension to this environment though,
I may try and code up a way to do as many such conversions (arbitrary
unit -> current environment) as possible, since usually the unit that
causes the biggest problem in a problem is the obscure uncommon one you
have to go dig up the conversion factor for.  This argues for as broad
a knowledge of units in Axiom as possible, although I admit this should
probably be done over time and not as part of the initial effort.
 
> Ignoring it in this example would mean the equation is not
> dimensionally balanced, and worse, some may think that 
> degree = radian!

I think this is a weak spot in my understanding of dimensionality, so I
apologize if I'm being dense here.  If we take C=%pi*d where C is a
circumference, %pi is %pi, and d is diameter, and look at the
dimensions, we have:

          degree
Length =  ------ Length
          radian

Casually, this doesn't look at all balanced.  Does it mean that when we
define the dimensionality of the variable C we need to define it as:

 degree
 ------ Length
 radian

rather than just Length?  I suppose in once sense this preserves the
information that C is a curve instead of a straight line, but I don't
quite see how the ramifications of that play out.  I suppose if you
then describe the distance a wheel would move in x if you rotate it
around its center n times the degree/radian information might be
pertinant, so perhaps there is reason to do this after all, but I think
it will require careful though on how to deal with this situation.

> OK, let me try to explain again.  A quantity is dimensionless 
> means its dimension can be reduced to 1. But sometimes, it is 
> more meaningful (physically or mathematically) to view these as a 
> quotient (this is like, but not totally, we sometimes rewrite 1 as 
> 2/2 to add fractions). Even SI recognizes this in stating that the 
> unit of a phase angle is m. m^(-1) = 1 because this IS the 
> definition (arc length spanned by the angle, divided by the radius).
> Just because the dimensions cancel out (making it dimensionless) 
> does not mean the dimension is not there.

OK, I think I'm getting it.  So what we need to do is examine the cases
where it is actually useful to retain this information, and see what
behaviors are rigorous/needed/useful.  Definitely in some cases we need
to canel dimensions out - we don't want something described in (say)
kg/s multiplied by seconds to wind up as kg*s/s, but if there are cases
where m/m is useful to preserve there would seem to be a problem with
having a general rule.  Could unit and dimension cancelation be handled
on a per dimension basis? 

> Definitely. We can have a nanosytem domain, and other domains of
> UnitSystem(S) as experts need them. That is the beauty of Axiom's 
> categorical approach: unifying domains with a common set of API.

OK, cool.  So we might actually develop a situation where, for
different kinds of work, we have different standard domains defined
(say, as an example, if someone is working with radio telescope data
and equations, they can do )set UnitSystem RadioTelescope having
previously defined the desired unit conventions for such work.  I
guess, thinking about it, my scenarios for unit use were too narrowly
focused on the case of students, where arbitrary units will appear for 
any reason and no reason (sometimes just to make them look them up and
do the conversion, which always annoyed me as an extra and unnecessary
potential source of numerical errors but in retrospect was probably
good training.)  For "real world" use, that case is not terribly
useful, and Axiom is definitely not focused on introductory student
problems :-).

\start
Date: Wed, 24 Aug 2005 19:11:21 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package question - Reply to 1st half

--- William Sit wrote:

> SI provides standardized prefixes and abbrevations in the range
> 10^(-24) to 10^(24), one for every three unit change in the 
> exponent, which are applicable to ANY physical quantity (with the 
> exception of kilogram, see SI pages, to avoid double prefixes).

Oh, OK!  Well, there goes my most compelling reason to want to be able
to peg individual dimensions to specific units :-).

> More interestingly, SI also has prefixes and abbreviations for
> the computer industry: kilibit (1024 bits) vs kilobit (1000 bits).
> Axiom implementation definitely should adhere to SI standards and 
> implement all their standardized and accepted units.

Agreed.  That could actually be very handy for certain types of
questions about the finer low level points of computer memory :-).
 
> Since SI provides prefixes only for every thousand-fold change, if
> all computations you expect are in the scale of 1 nm, you would
> probably spot these errors in hundreds of nm. But anyway, every 
> scientist should be aware of units attached to quantities, 
> especially in graphs! 

Well, that last argument has got me dead to rights ;-).  Conceded.

> I think autoscaling is good enough (Note, all digital meters 
> autoscales! Scientists are used to that.)

Good point.  Perhaps we could make the autoscaling configurable though,
so people can avoid scaling to less used prefixes unless they so
desire?  (This is so people have the option of only using metric
prefixes they can readily match to some physical standard they are
familiar with, such as a centimeter.)  Usually when the computer tries
to be "smart" like that it is a good idea to allow the user to take
matters into their own hands if they so desire.  (At least, in my
experience - evidently not all software developers agree with me :-/)
 
> I think whoever implements this should first program for the correct
> framework, and provide basic unit systems based on SI. Then as usage
> expands, add more unit system domains. Then if that is not enough,
> add more friendly user settings. I am fairly convinced that the 
> framework proposed earlier is able to handle and
> facilitate this plan of development. I would like to hear more
> critique from others.

So would I - I think I've finally understood the overall arguments now,
and for myself I'm deeply impressed with the insight you have brought
to this problem.  For what it's worth, you have convinced me your
overall direction is the best one to take, and can serve as a good
foundation for tweaks and extensions as desired.
 
> Thanks for this interesting discussion.

Thank you!  This has been an education in and of itself, which I think
is one of the real benefits of a system like Axiom - it forces you to
think deeply about what you are really trying to do.  (Or at least, to
work at understanding others who are up to the deep thinking ;-)

\start
Date: Wed, 24 Aug 2005 19:19:32 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Unit package question

--- Bill Page wrote:

> Axiom Developers;
> 
> I think the continuing exchange on the units package for Axiom is
> very interesting and potentially useful to a wider audience,
> therefore I have created an initial summary of the discussion on 
> the design here:
> 
> http://www.axiom-developer.org/zope/mathaction/UnitsAndDimensions
> 
> The authors (and other interested parties!) are invited to review
> these wiki pages and update/correct/edit them as seems appropriate.
> New pages on this subject can also easily be added. I would like
> these pages to gradually evolve to reflect design decisions and
> trial code segments as this package is developed.

Do you want a complete summary of the email list discussions, or just
the ones that seem to lead to what eventually becomes the final design?
 (I must confess I'm not really sure how archiving of Axiom's email
system works, since I just save most of them myself on my machine in
Kmail - should the wiki be used to preserve discarded ideas and the
reasons they were discarded, or just focus on what is eventually
accepted and provide links to the full discussion?  If the email
archive is stable and readily available it would probably be cleaner to
focus the wiki page on the actual workable design related emails, with
links to the discussion tree for other stuff.)

\start
Date: Wed, 24 Aug 2005 22:50:04 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Unit package question

C Y,

> Bill Page wrote:
> >
> > The authors (and other interested parties!) are invited to review
> > these wiki pages and update/correct/edit them as seems appropriate.
> > New pages on this subject can also easily be added. I would like
> > these pages to gradually evolve to reflect design decisions and
> > trial code segments as this package is developed.
>

On Wednesday, August 24, 2005 10:20 PM you asked:

>
> Do you want a complete summary of the email list discussions, or
> just the ones that seem to lead to what eventually becomes the
> final design?

I think the summary should be more *constructive* and *synthetic*
rather than archival. It should accurately reflect (within reason)
the current understanding of the problem and solution - not the
history - except perhaps for attribution of relevant ideas to
original authors etc. This usually means that some (now irrelevant)
parts of the discussion, proposals and experimental code should
actually be deleted after the direction is clear and more
well-advanced.

> (I must confess I'm not really sure how archiving of Axiom's
> email system works, since I just save most of them myself on
> my machine in Kmail)

All axiom-developer emails (including notices of changes on the
MathAction wiki) are archived at:

http://mail.nongnu.org/archive/html/axiom-developer

This is the primary and complete archive. There are also a few
other places on the web where our discussions are duplicated,
e.g. gmane.

> - should the wiki be used to preserve discarded ideas and the
> reasons they were discarded, or just focus on what is eventually
> accepted and provide links to the full discussion?

I say definitely just the latter: focus on what is eventually
accepted and what remains controversial. Eliminate the stuff
in between.

> If the email archive is stable and readily available it would
> probably be cleaner to focus the wiki page on the actual workable
> design related emails, with links to the discussion tree for other
> stuff.)

I think the Internet email archives are very stable. Although like
you, for convenience I often rely more on my own local archive of
these emails, after several system upgrades, failures and re-
organization I now find that my personal archive is less reliable
than mail.nongnu.org.

So I agree that the wiki pages should focus on actual workable
design ideas. Often the original text of the emails also has to
be adjusted periodically to use the current terminology etc. It
often takes more time to be concise and accurate so that someone
can quickly understand the main points (that what the wiki pages
are good for), rather than just record the complete and verbose
history (that's what the dumb archives are good for).

>
> Good idea!
>

Thanks. I hope that it helps your project. Please feel free to
change and edit the contents of these pages as suits your own
purposes. :)

\start
Date: Thu, 25 Aug 2005 11:13:02 +0200
From: Ralf Hemmecke
To: list
Subject: Re: Axiom Design Question / Polymake feedback

 > )abbrev domain POLYTOPE Polytope
 > Polytope(R: Ring): Exports == Implementation where
 >     Exports == with
 > ------------------------------------------------------------
 > --               polytope constructions 
          > ------------------------------------------------------------
 >       cube: Integer -> %
 >       if R is Float then randSphere: (Integer, Integer) -> %
 >       vertices: % -> Matrix R

 > However, I'm not convinced that this is the best solution. One reason
 > being, that I don't really want that the user has to specify the type
 > of his polytope all the time.

If you don't like it and you can somehow determine the type of R 
automatically, and it is something simple like Integer then why not writing

Polytope(): Exports == Implementation where
     Exports == with
       vertices: % -> (R: Ring, Matrix R);
       ...

That should work in Axiom (+ dependent types).

By the way, is there a reason for constructing a nullary function 
Polytop() instead of just the constant Polytope? (Sorry, I have not 
looked at polymake.)

\start
Date: Thu, 25 Aug 2005 11:10:42 +0200
From: Ralf Hemmecke
To: list
Subject: strict vs. fuzzy Axiom

> C Y wrote:

>> I guarantee that making Axiom too strict in a correctness sense
>> without providing a way to get things done will lose it much of its
>> audience in the unit game, since physicists as a rule are not
>> overly concerned with mathematical rigor. (Compared to
>> mathematicians, anyway ;-)  I think allowing both strict mode and
>> fuzzy mode is a good idea, which allows for both full correctness
>> if needed and a more practical working environment if desired.  I
>> invite comment on this, since I might have just stomped Axiom
>> philosophy into the carpet :-/.

> Being "fuzzy" is certainly against the philosophy of Axiom, but I
> suppose as long as it is clearly pointed out, there is no reason not
> to allow it. Martin has a "guessing" program for sequences, and it is
> very useful. So go ahead. I agree that Axiom suffered commercial
> failure for its inflexibility.

As some of you might know Aldor's intermediate name was A# (A-sharp). I 
once heard of a project which was called B-flat and if I am not wrong it 
did exactly address the "problem" that Axiom was to complicated for a 
wider audience. (Please correct me if I am wrong.) In my opinion, the 
idea should be that internally Axiom/Aldor is strict and that should 
NEVER change. However, I couln't say anything against another layer (I 
my eyes that could be the work of a user interface) which tries hard to 
guess what the user had in mind. The user input would be equipped with 
all the necessary type information to run a strict program internally. 
One cannot expect everyone to know all the hairy details of the 
algorithms. How many people bother to understand the Risch algorithm 
just to solve an intergral. If they have a CAS at hand which translates 
their input and gives a reasonable output _and_ is able to tell what the 
output actually means (that may depend on the an ambiguous 
interpretation of the input).

So I would vote for a two-layered AXIOM.
1) internal libraries (strict)
2) user interface (fuzzy)
and I would like to see these layers being separate things.
A user should however always be allowed to just use the strict mode if 
he is knowledgable enough. And other people should be encouraged to 
provide enough information.

One approach could be like that...
http://www-sop.inria.fr/cafe/Manuel.Bronstein/sumit/sumitdoc/node628.html

\start
Date: Thu, 25 Aug 2005 05:57:55 -0500
From: MathAction (unknown)
To: MathAction
Subject: [SymbolicIntegration] integrate(exp(x)/x^2)

Axiom does not perform the integration (while it perform the integration of exp(x)/x ), but the integration can be given in terms of Ei(x)

integrate(exp(x)/x^2,x)  -->  Ei(x)-exp(x)/x 

\start
Date: Thu, 25 Aug 2005 12:51:26 +0100
From: Peter Broadbery
To: Bill Page
Subject: re: aldor patches

On Wed, 2005-08-24 at 17:48 -0400, Page, Bill wrote:
> Peter,
> 
> On Wednesday, August 24, 2005 2:19 PM you wrote:
> > >
> > >   \begin{aldor}
> > >   Aldor code
> > >   \end{aldor}
> > >
> > 
> > This ought to work, but not immediately; One problem may be compiling
> > several aldor stanzas together - in this case you need to be able to
> > refer to earlier stanzas within the aldor block.
> > 
> > Eg:
> > 
> > \begin{aldor}
> > 	AldorCat: Category == with { funstuff }
> > \end{aldor}
> > 
> > \begin{aldor}
> > 	AldorDomain: AldorCat with { ... } == add { ... }
> > \end{aldor}
> >
> 
> In the case of \begin{axiom} sections, what MathAction does is
> generate a .input or .spad file for each section and then calls
> Axiom just once using stdin to pass )read or )compile commands
> for each section as appropriate. So, for each web page there is
> only one Axiom session and the namespace is the same for the
> entire page. (Except for comments containing \begin{axiom}
> sections which are initially each run in their own Axiom session
> before being appended to the page.)
> 
> Perhaps I can do the same thing for Aldor? Can I run Aldor
> with a series of 'include' files - one for each \begin{aldor}
> section? Would that solve the problem of referring to earlier
> sections?
> 

This would work, I think (and the problem with .ao files goes away),
although a page wouldn't be able to redefine an operator.

> To make this work properly I also need some kind of unique separator
> string between the Aldor compiler output for each include file.
> In the case of Axiom that separator is the interpreter '(99) -> '
> prompt sequence. For Spad sections, the \begin{axiom} \end{axiom}
> group is replaced with <pre>formatted</pre> HTML tag containing
> the Spad code followed by a <div> ... </div> section containing
> the Spad compiler output (which appears as "folded" text"). Can
> you suggest a way to generate such a separator for Aldor compiler
> output if the input consists of a series of 'include' files?
> 

The only compiler output will be error messages from the compiler; If
you call the compiler via axiom (ie. ')co aldor-section.as'), then an
axiom prompt should be a perfectly good separator.


> The use of 'include' files above should handle this case, right?
> 
Yep.

> Where do the .ao files need to be stored in order to be accessible
> to Axiom commands? Can more than one .ao file be generate per run
> of the Aldor compiler? Is it sufficient if they are saved in the
> current working directory?
> 

Storing them in the current working directory should be fine, though 


>   # document Makefile.pamphlet
> 
> in order to generate the Makefile and the type
> 
>   # make 2>&1 | tee aldor.log
> 
> The result of doing this is contained in the new attached log
> file.
> 
> The log file contains two runs of make in sequence. The first run
> stops with the message:
> 
> make[1]: *** No rule to make target
> `/home/page/repository/axiom--main--1/int/aldor/dep_spad.stamp', needed
> by `/home/page/repository/axiom--main--1/int/aldor/saxiom/spadset.mk'.
> Stop.


> The build progressed further but then apparently stopped because
> a statement in the generated Makefile exceeded some command line
> length limit for either make or /bin/sh.
> 
> What linux operating system and utility versions are you using
> to do your development? I am trying to build this on the
> axiom-developer/MathAction server which is running RedHat 9
> (updated almost, I think, to the level when RedHat discontinued
> it's development about two years ago in favor of Fedora). The
> server runs in shared virtual server mode.

I'm using SuSE 9.2; the make version is 3.80 (you may have the previous
version; 3.80 was released in october 2002). The problem seems to be
that Make.functions hasn't been generated from Make.functions.pamphlet;
if you do this manually, it'll get further.

The second error was not due to an excessively long command line, IIRC
bash has no such limit, especially in 'for' statements.  The problem was
an ungenerated include file.

> 
> Is there some way your java program can easily generate a more
> Portable Makefile? Or do you know of anyway to allocate a
> Larger command line buffer?
> 

"Easily", not sure - I think it would mean a different approach, since
the java program currently just spits out sets of mutually dependent
domains, and is just there to help make on its way. 

One way of simplifying matters would be to invoke 3 sequential builds;
Once to run document on everything, then for the dependency graphs, and
then once more to build the library.  However, this may well still need
a more recent make.

\start
Date: Thu, 25 Aug 2005 08:14:57 -0500
From: MathAction (Stefano Simonucci)
To: MathAction
Subject: [Axiom-mail] Non elementary integration 

Hi.
In the axiom manual I find

"Integration is the reverse process of differentiation, that is, an 
integral of a function f with respect to a variable x is any function g 
such that D(g, x) is equal to f.
....
Given an elementary function to integrate, Axiom returns a formal 
integral as above only when it can prove that the integral is not 
elementary and not when it cannot determine the integral. In this rare 
case it prints a message that it cannot determine if an elementary 
integral exists.

Now if I write
integrate(exp(x)/x,x)
I obtain
Ei(x)
while if I write
integrate(exp(x)/x^2,x)
I get a form integral. But the integral of exp(x)/x^2 can be given in 
terms of Ei(x) as exp(x).
In fact I believed that the axiom can be able to find the solution that is

integrate(exp(x)/x^2,x) --> Ei(x)-exp(x)/x

But from the manual I deduce that exp(x)/x^2  can be prooved not 
elementary integrable. Why  exp(x)/x  is integrable while  exp(x)/x^2 not?

\start
Date: Thu, 25 Aug 2005 09:07:38 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [other Computer Algebra systems] Derive

Except for Reduce (by the kind permission of it's author) we do not
have any commerical software on MathAction. I did approach both
MapleSoft (Maple developers) and Wolfram (Mathematica developers) to
see if they would provide a copy of their software and allow us to
integrate it here on MathAction. But so far Maplesoft has officially
(but respectfully) declined and Wolfram did not even reply to my
email.

Apparently Derive is only available for Windows systems. Development
of Derive seems to have essentially stopped.

How much does Derive cost? What are it's significant features compared
to Axiom? Maple? Mathematica?

\start
Date: Thu, 25 Aug 2005 09:24:47 -0500
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] Non elementary integration 

Dear Stefano,

Stefano Simonucci writes:

 > Now if I write
 > integrate(exp(x)/x,x)
 > I obtain
 > Ei(x)
 > while if I write
 > integrate(exp(x)/x^2,x)

 > I get a form integral. But the integral of exp(x)/x^2 can be given in terms
 > of Ei(x) as exp(x).  In fact I believed that the axiom can be able to find
 > the solution that is
 
 > integrate(exp(x)/x^2,x) --> Ei(x)-exp(x)/x

this would be correct, yes.

 > But from the manual I deduce that exp(x)/x^2 can be prooved not elementary
 > integrable. Why exp(x)/x is integrable while exp(x)/x^2 not?

Well, exp(x)/x is *not* elementarily integrable, Ei(x) is simply defined to be
its integral. Ei(x) is *not* an elementary function. (in the mathematical
sense)

However, Axiom should still be able to figure out your integral. The
corresponding code is in intpm.spad, but your integral doesn't fit, it seems.

If you are willing to do some research, we might be able to figure out how to
improve the pattern matcher. There is also code by Manuel Bronstein (written in
maple), that would handle special functions. Maybe this should be integrated,
too.

Note that there are also two bugs (with fixes) filed on IssueTracker, so if you
rely heavily on integrals, you might want to patch your axiom:

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

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

The first patch is hidden in a comment, you'll have to look for it.

\start
Date: Thu, 25 Aug 2005 09:39:04 -0500
From: MathAction (root)
To: MathAction
Subject:  Non elementary integration

Stefano,

The key words are "elementary function". Some integration is done by
the Risch Algorithm. Essentially the Risch Algorithm can integrate
any function which results in something like

    f(x) + log 

exp(x)/x^2 cannot be integrated into this form. Axiom does some
integration by pattern matching and it appears that the pattern
matcher does not know exp(x)/x^2

\start
Date: Thu, 25 Aug 2005 10:52:44 -0400
From: Bill Page
To: Peter Broadbery
Subject: re: aldor patches

Executive Summary:

  The axiom/aldor build seems to have completed successfully
  but we are missing an include file named 'axiom...'

On Thursday, August 25, 2005 7:51 AM Peter Broadbery wrote:
> ...
> The only compiler output will be error messages from the compiler;
> If you call the compiler via axiom (ie. ')co aldor-section.as'),
> then an axiom prompt should be a perfectly good separator.
>

Ah, yes I see. That would be real easy for me to integrate with
MathAction. If we *only* provide Aldor compilation via axiom
(as opposed to directly calling the compiler) is this a significant
limitation? Or is this the expected mode of interaction?

> > The use of 'include' files above should handle this case, right?
> >
> Yep.

Suppose I generate a series of Aldor compiles from axiom like this:

  )co aldor-section1.as
  )co aldor-section2.as
  )co aldor-section3.as

instead of using Aldor includes. Does the problem of having to
know the names of previous Aldor compiles return? Maybe this will
be more clear once I actually have Aldor running inside Axiom and
get a chance to play with it.

> ...
> I'm using SuSE 9.2; the make version is 3.80 (you may have the
> previous version; 3.80 was released in october 2002).

Yes I had the previous version 3.79.x. I just downloaded and
compiled Gnu make 3.80.

> The problem seems to be that Make.functions hasn't been generated
> from Make.functions.pamphlet; if you do this manually, it'll get
> further.

Yes that did it! The Aldor/Axiom build has now in the process of
compiling the Axiom library. What I did was the following:

  1) Built Axiom from axiom--main--1--Patch-44
  2) cd src; tar xzvf src_aldor.tgz
  3) document Makefile.pamphlet
  4) make
  5) touch .../aldor/int/dep_spad.stamp
  6) document Make.functions.pamphlet
  7) make

Probably the intermediate make attempt step 4) is unnecessary.
The build has just completed successfully. The log ends like this:

...
AOBUILD LIB: axiom ELT: ZMOD DEPS: 4
LIB libaxiom.al ZMOD.ao D: 22 files
BUILT:  libaxiom.al
cp -p /home/page/repository/axiom--main--1/int/aldor/lib/libaxiom.al
/home/page/repository/axiom--main--1/mnt/linux/algebra/libaxiom.al
echo built
/home/page/repository/axiom--main--1/mnt/linux/algebra/libaxiom.al
built /home/page/repository/axiom--main--1/mnt/linux/algebra/libaxiom.al
cp /usr/local/aldor/linux/1.0.2/lib/runtime.lsp
/home/page/repository/axiom--main--1/mnt/linux/aldor/lib/runtime.lsp
echo LSP->O: runtime.o
Built runtime.o
warning Targets are sources all_libaxiom all_runtime
Built libaxiom
make[1]: Leaving directory
`/home/page/repository/axiom--main--1/src/aldor'
[root@axiom-developer aldor]#

----------

> ...
> the java program currently just spits out sets of mutually dependent
> domains, and is just there to help make on its way.
>

In contrast to Tim Daly, I am very much in favor of this approach
to building a complex system like Axiom. I would like to see this
done in the Axiom build. But that is another story. :)

> One way of simplifying matters would be to invoke 3 sequential
> builds; Once to run document on everything, then for the dependency
> graphs, and then once more to build the library.  However, this may
> well still need a more recent make.
>

Yes, I upgraded to gnu make 3.8. That might well be a factor in
the successful completion of your aldor/axiom build.

Ok, so I need to test this thing. What do you suggest? Should
I try to compile the rr.as file?

[root@axiom-developer page]# AXIOMsys
                        AXIOM Computer Algebra System
                     Version: Axiom 3.9 (September 2005)
               Timestamp: Tuesday August 23, 2005 at 22:37:35
------------------------------------------------------------------------
-----
   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
(1) -> )co rr.as
   Compiling AXIOM source code from file /home/page/rr.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'
"/home/page/rr.as", line 54:
#include "axiom"
^
[L54 C1] #2 (Error) Could not open file `axiom'.

   The )library system command was not called after compilation.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/bc-matrix.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/bc-misc.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/bc-solve.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/bc-util.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/ht-util.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/htsetvar.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/ht-root.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/br-con.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/br-data.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/showimp.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/br-op1.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/br-op2.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/br-search.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/br-util.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/topics.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/br-prof.
   Loading
/home/page/repository/axiom--main--1/mnt/linux/autoload/br-saturn.
(1) ->

-------

Looks like we are almost there now.

Oops. I seem to be missing an include file named 'axiom...'.
Or maybe in the Patch-44 distribution it is looking in the
wrong place. Where do I get that?

\start
Date: Thu, 25 Aug 2005 09:53:53 -0500
From: MathAction (Ed Borasky)
To: MathAction
Subject: [other Computer Algebra systems] [other Computer Algebra systems] Derive

List price for Derive is about $200US and student price is about $100US. 
Its core-level mathematical capabilities are equivalent to nearly every 
"general" CAS out there, and anything you can implement in them can be 
implemented in Derive. I have never been able to afford Maple or 
Mathematica or even Reduce, so I can't comment on them.

Ease of use: Derive is much easier to use than Maxima, although I think 
that's just because I've been using Derive since about 1994 (on DOS back 
then!). I just started with Axiom, so I can't comment on it either. 
Axiom has a great reputation on the "gentoo-science" mailing list, so 
I'm learning how to use it.

Development does appear to have slowed down -- I wouldn't say stopped. 
The release level is 6.1. A couple of years ago, the founders of Soft 
Warehouse sold the business to Texas Instruments, so the business 
decisions are made now by TI rather than the founders as near as I can 
tell. In any event, Derive is essentially "complete" -- its main market 
is students.

I haven't found anything it can't do in a professional environment, 
though. My needs for a CAS right now are mostly to deal with equations 
in computer performance modeling -- Markov chains, ODEs, Laplace 
Transforms, etc. Derive handles them well and was my only practical 
alternative on Windows systems until I got a working Maxima port a year 
or so ago. But if you need Grobner basis calculations, well, they have 
that too ... :)

Bill Page wrote:

>Except for Reduce (by the kind permission of it's author) we do not have any commerical software on MathAction. I did approach both MapleSoft (Maple developers) and Wolfram (Mathematica developers) to see if they would provide a copy of their software and allow us to integrate it here on MathAction. But so far Maplesoft has officially (but respectfully) declined and Wolfram did not even reply to my email.
>
>Apparently Derive is only available for Windows systems. Development of Derive seems to have essentially stopped.
>
>How much does Derive cost? What are it's significant features compared to Axiom? Maple? Mathematica?

-- 
Ed Borasky

http://www.borasky-research.net/
http://borasky-research.blogspot.com/

http://pdxneurosemantics.com
http://pdx-sales-coach.com
http://algocompsynth.com

\start
Date: Thu, 25 Aug 2005 11:16:53 -0400
From: Bill Page
To: Peter Broadbery
Subject: re: aldor patches

Peter,

On Thursday, August 25, 2005 10:53 AM I wrote:
>
> Executive Summary:
>
>   The axiom/aldor build seems to have completed successfully
>   but we are missing an include file named 'axiom...'
>

Ok, I followed step 2. from Martin's web page:

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

and created axiom.as in $ALDORROOT/include

Now the compile of rr.as completes successfully and Martin's
example factorial code in step 3. Great!

So the final step is just for me to put this version of
Axiom into production on the MathAction server.

Thanks again, and again.

Regards,
Bill Page.

> Peter Broadbery wrote:
> > The problem seems to be that Make.functions hasn't been generated
> > from Make.functions.pamphlet; if you do this manually, it'll get
> > further.
>
> Yes that did it! The Aldor/Axiom build has now in the process of
> compiling the Axiom library. What I did was the following:
>
>   1) Built Axiom from axiom--main--1--Patch-44
>   2) cd src; tar xzvf src_aldor.tgz
>   3) document Makefile.pamphlet
>   4) make
>   5) touch .../aldor/int/dep_spad.stamp
>   6) document Make.functions.pamphlet
>   7) make
>
> > However, this may well still need a more recent make.
> >
>
> Yes, I upgraded to gnu make 3.8. That might well be a factor in
> the successful completion of your aldor/axiom build.

\start
Date: Thu, 25 Aug 2005 15:01:18 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AldorForAxiom] 


Support for domains and packages is now in the testing stage. The
Axiom/Aldor interface has been updated for the open source version of
Axiom (as of Patch-44) by Peter Broadbery. **Thanks Peter!** A new
version of Axiom based on axiom--main--1--Patch-44 and Peter's
interface has been installed here on MathAction.

Aldor on MathAction

  This is a simple example of how to use Aldor on MathAction.

First compile some function, for example this non-recursive
method to compute the factorial:
\begin{aldor}
#include "axiom.as"

fact(n: PositiveInteger): PositiveInteger == {
    n <= 1 => 1;
    res: PositiveInteger := 1;
    while n > 1 repeat {
        res := res * n;
        n := n-1;
    }
    res
 }
\end{aldor}

Now call the function in Axiom as you would any other
Axiom function:
\begin{axiom}
fact(11)
\end{axiom}

Building Axiom with Aldor

  (preliminary instructions)

We plan to (re-)integrate the linkage of Axiom with the Aldor as an
optional part of the Axiom build in the next release of Axiom 3 beta.
Until then to build Axiom with Aldor support you must do the following:

1. Make sure you have the most up to date version of gnu make

   make --version
   GNU Make 3.80

   If not, then upgrade your version of make or linux first.

2. Install the Java development kit JDK

   http://java.sun.com/j2se/1.5.0/download.jsp

3. Download and install Aldor as described here:

   http://www.aldor.org

   Be sure to set ALDORROOT and the PATH to Aldor properly for
   your system.

4. Download Peter's Aldor patches and make files here

   "aldor.diff":aldor.diff

   "src_aldor2.tgz":src_aldor2.tgz

5. Update your Axiom source code to Patch-44 (or greater):

     cd axiom--main--1
     tla update

6. Apply the Aldor patches::

     patch -p 1 < ~/aldor.diff

7. Now build a new version of Axiom::

     ./configure
     (set AXIOM environment variables)
     make

8. Extract the Aldor make files::

     cd src
     tar xzvf ~/src_aldor2.tgz

9. Build the Aldor interface using the following commands:

   1. cd aldor

   2. document Makefile.pamphlet

   3. touch ../../int/aldor/dep_spad.stamp

   4. document Make.functions.pamphlet

   5. make 2>&1 | tee aldor.log

   The build might take up to 2 hours or some machines. 

10. Finally, download and save the file

    "axiom.as":axiom.as

    into 'aldor/1.0.2/linux/include/' of your aldor (binary) distribution.

    Congratulations! Now you should be able to compile Aldor files in Axiom.

11. Save the fact example above into a file named 'fact.as'

12. Start Axiom

13. Compile and run the example file

    )co fact.as
    fact(5)

<hr />
Out of Date

  The information below is out of date and will be soon replaced

Unfortunately, support for domains and packages is still buggy, but
it's nearly working - thanks to Peter!

\start
Date: Thu, 25 Aug 2005 15:15:56 -0500
From: MathAction (billpage)
To: MathAction
Subject: [AldorForAxiom] 

13. Compile and run the example file::

      )co fact.as
      fact(5)

\start
Date: Thu, 25 Aug 2005 23:04:09 +0200
From: Gregory Vanuxem
To: Peter Broadbery
Subject: re: aldor patches

Le mercredi 24 ao=FBt 2005 =E0 19:19 +0100, Peter Broadbery a =E9crit :

>
> Yes, this is due to me not testing stuff terribly well.  I've sent Tim =
a
> new .tgz - appended below.
>

\start
Date: Thu, 25 Aug 2005 17:46:03 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Include images in pamphlet files?

I suppose this might be an odd question, but I was wondering if it was
possible to include figures in the traditional way in Axiom's literate
code files?  (/includegraphics or some such?)

\start
Date: Thu, 25 Aug 2005 21:13:28 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Include images in pamphlet files?

Yes, it's possible. The book includes figures.
see src/doc/book.pamphlet

\start
Date: Thu, 25 Aug 2005 21:17:46 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Include images in pamphlet files?

Pamphlet files are latex files with three additional pieces of syntax:

1) chunk definition


<<any string>>=
    this can be anything and is called a chunk definition.
@

2) chunk use

This is the use of a chunk. You just use <<any string>> (assuming it has
a definition somehwhere. The information will be expanded in place. Think
of chunks as macros with no parameters.

3)

You can quote any string inline using [[some string]]



Other than that a pamphlet file is a latex file. The steps are:

   notangle foo.pamphlet --> foo.code (pure code)
   noweave  foo.pamphlet --> foo.tex  (pure latex)


So if you know how to do something in latex it all works the same.

\start
Date: Fri, 26 Aug 2005 23:32:44 +0700 (NOVST)
From: Andrey G. Grozin
To: list
Subject: steps towards better TeXmacs interface

Hello *,

If some program (e.g., TeXmacs) wants to communicate with axiom (via 
pipes), it must know in a reliable way, where axiom prompts begin and end, 
when axiom waits for input, where parts of axiom output written in LaTeX 
begin and end, which parts of output are error messages, information about 
the type of the expression just calculated, etc. In order to do so 
reliably, axiom has to insert some (parametrized) markers at some key 
positions of its output. Approach based on partial parsing of the plain 
text output is (1) unreliable (as a user, I can print any string, and 
confuse the interface); (2) ugly (axiom already knows where are its 
prompts, but this information is not obvious in its plain-text output; why 
should the interface guess, if axiom can tell it for sure?). The current 
interface (written by me long ago) uses this last approach.

Another free computer algebra system, maxima, has incorporated inserting 
of parametrized markers in the key positions of its output some time ago. 
Now it is easy to interface it to almost any external program: one just 
assigns appropriate values to the marker strings, and then maxima speaks 
the protocol required by this external program. Maxima developers called 
this "the transition from the stone age to the bronze age" (the idea is 
that using corba or some such thing would be the enlightment era).

Axiom is still in the stone age in this respect (a more structured and 
predictable input-output). I am now trying to move it to the bronze age. 
The first (and rather obvious) place is interp/i-util.boot.pamphlet
I renamed the procedure MKPROMPT to MKPROMPT0, and inserted

$InterfaceStrings : Record(PromptPrefix:String,PromptSuffix:String) := ['"[",'"]"]

MKPROMPT() ==
  STRCONC($InterfaceStrings.PromptPrefix,MKPROMPT0(),$InterfaceStrings.PromptSuffix)

This works, and my prompts are now in brackets (of course, this is just a 
test). The next step is to find all the other prompt-like things in axiom 
(i.e., output strings immediately preceeding user input). One of them is 
the exit confirmation, for example; I'm sure there are many others. Each 
prompt-like string should now be preceeded by 
$InterfaceStrings.PromptPrefix and followed by 
$InterfaceStrings.PromptSuffix . And this is only the first step, there 
will be, e.g., $InterfaceStrings.LatexPrefix and 
$InterfaceStrings.LatexSuffix and some other markers.

So, I have a few questions to the gurus:

1. What is the correct file to put the definition and initialisation of 
$InterfaceStrings ?

2. Is there some way in which this initialisation could be made dependent 
on external conditions? For example, can I pass a command-line argument to 
AXIOMsys, and check it in boot code? Or check an environment variable in 
the boot code?
At the moment, I know only one way to pass some information to axiom: 
.axiom.input. But it would not be a good idea for TeXmacs, for example, to 
overwrite the user's .axiom.input (if the user has one).

Making text exchanges between axiom and an external program to follow some 
structured, predictable protocol (without playing guessing games) is the 
first and the most important goal. But there are further necessary steps. 
The current TeX generation (algebra/tex.spad.pamphlet) was written 15 
years ago. Naturally, it does not produce modern standard LaTeX. I've made 
a number of changes in tex.spad.pamphlet, to produce more 
standards-complying LaTeX code instead of some historic relicts ( \over , 
\sub , \root ... \of ... , etc.). But this is not exactly what's needed. 
TeXmacs has some strange requirements of its own (e.g., using \* for 
multiplication). Therefore, I want to leave the old TeX generation alone, 
and to introduce the new kind of output: texmacs. So that it will be 
possible to say
)set output texmacs on
OK, I can easily duplicate tex.spad.pamphlet (should this be a new file, 
texmacs.spad.pamphlet, or I just double the contents of tex.spad.pamphlet 
?) I'll rename the domain TexFormat to TexmacsFormat, and make the 
improvements I want. But what to do next? My (very incomplete...) 
understanding is that I should insert the necessary pieces into 
setvars.boot.pamphlet and setvart.boot.pamphlet (based on the TeX pieces, 
with renamings and some small changes). But setvars.boot.pamphlet says 
that if I change the boot code (and I'm going to do this), I have to 
translate it to lisp and insert it into the same file. How do I do this, 
exactly?

The new domain TexmacsFormat is the natural place to put the line-breaking 
functionality. Some ideas can be taken from the C code which does such 
line-breaking, and which is available. Of course, it is much more natural 
to do this in the spad domain, where all the information about the 
expression structure is available. Also, this C code generates LaTeX which 
gives a reasonably-looking output, but is mathematically meaningless (it 
uses \array's all over the place for things which are not arrays). This 
leads to the fact that, if this C code is used, it is absolutely 
impossible (and never will be possible) to copy a (part of) output by the 
mouse and insert in into an input field (because it is not possible to 
reconstruct the mathematical meaning of an expression from this obfuscated 
LaTeX). And this goal is highly desirable. Therefore, the aim of 
TexmacsForm will be to generate a meaningful LaTeX, with line breaking, 
which can be used as a source of drag-and-drop in TeXmacs.

There is another possibility, which requires some thought. What if we send 
expression tree from axiom to TeXmacs as an S-expression, instead of 
serializing it via LaTeX? TeXmacs understands not only latex: fields, but 
also scheme: fields. Generating scheme syntax from an axiom expression may 
well be easier than generating LaTeX. Line breaking can be done on the 
TeXmacs side, where the necessary information is available (it is in 
principle impossible to tell, what is the width of a sub-expression after 
typesetting, without actually typesetting it). But this is, probably, a 
more long-term project. For now, I'd better keep as much as possible from 
the current interface, but make it more robust and less ugly.

What do you think?

\start
Date: Fri, 26 Aug 2005 19:03:39 +0200
From: Martin Rubey
To: Andrey G. Grozin
Subject: Re: steps towards better TeXmacs interface

Dear Andrey,

just two comments:

regarding the markers and in and output parsing you should short circuit
yourself wiht Kai Kaminski, I suppose.

Second:

Andrey G. Grozin writes:

 > ... if this C code is used, it is absolutely impossible (and never will be
 > possible) to copy a (part of) output by the mouse and insert in into an
 > input field (because it is not possible to reconstruct the mathematical
 > meaning of an expression from this obfuscated LaTeX). And this goal is
 > highly desirable.

Although this goal may be highly desirable, it will work only for some
domains. For others it is doomed to fail, simply because not all the
information is in the output. In fact, it will probably work only for those
domains that are ConvertibleTo InputForm...

So the probably better way to do this is to capture the label of the
output. The object is stored there, you don't need to reconstruct it. Example:

(1) -> )lib POLYTOPE

(1) -> cube 3

   (1)  "cube3"
                                                               Type: Polytope
(2) -> %::INFORM
 
   Cannot convert from type Polytope to InputForm for value
   "cube3"

(2) -> %::SEX
 
   Cannot convert from type Polytope to SExpression for value
   "cube3"

(2) -> %%(1)

   (2)  "cube3"
                                                               Type: Polytope
(3) -> hVector(%%(1))

   (3)  [1,3,3,1]
                                                         Type: Vector Integer

\start
Date: Sat, 27 Aug 2005 01:05:48 +0700 (NOVST)
From: Andrey G. Grozin
To: list
Subject: Re: steps towards better TeXmacs interface

I forgot to ask one more practical question. The prompt prefix and suffix 
will contain non-printable chars, \0x02 (ctrl-b) and \0x05 (ctrl-e). How 
can I include them in a boot string? Is literal embedding of these bytes 
inside a string enough? (in emacs, ctrl-q ctrl-something inserts the 
literal ctrl-something byte at the cursor position). Should it be prefixed 
by _ ? In common lisp this method works: any strange byte within a string 
will be printed, when the string is printed (I used this in the maxima 
source for communication with TeXmacs).

\start
Date: Fri, 26 Aug 2005 11:46:35 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Andrey G. Grozin
Subject: Re: steps towards better TeXmacs interface

--- Martin Rubey wrote:

> Andrey G. Grozin writes:
> 
> > ... if this C code is used, it is absolutely impossible (and never
> > will be possible) to copy a (part of) output by the mouse and 
> > insert in into an input field (because it is not possible to
> > reconstruct the mathematical meaning of an expression from this 
> > obfuscated LaTeX). And this goal is highly desirable.
> 
> Although this goal may be highly desirable, it will work only for
> some domains. For others it is doomed to fail, simply because not
> all the information is in the output. In fact, it will probably 
> work only for those domains that are ConvertibleTo InputForm...

I am not surprised at this, but I suspect handling it well will be
critically important to the acceptability of Axiom for a wide variety
of applications.
 
> So the probably better way to do this is to capture the label of the
> output. The object is stored there, you don't need to reconstruct it.

[snip]  

Does this imply that for a significant subset of mathematical
expressions, it should not be legal to select a subset of the
expression piecemeal?

I think I know what Andrey is thinking about here.  Let's say we have
the following expression:

				  2
				 b  + 2 a
				 -------- + c
				    d
 				 ------------
				    f + e

and we want to select:

				    2
				   b  + 2 a
				   -------- 
				      d

as our input in the next line.  The natural thing to want to do in a
graphical mathematical document environment is graphically select the
desired subexpression and paste that to the input line.  I suspect the
objection is that there may be hidden or non-hidden constraints within
Axiom's knowledge of the original expression that make selection of the
subset problematic, and won't be preserved?  Perhaps one way to do this
"safely" would be to "flatten" the expression to the basic types you
would get if you just typed in the displayed variables, and warn that
all original mathematical knowledge of the parent object has been lost
in the copying process?

This, however, is a violation of Axiom's philosophy of wanting to "Do
It Right."  The more interesting, but far more challenging problem, is
to map the constraints of Axiom's mathematical knowledge into a
graphical interface environment.  I rather suspect there will be a
fundamental clash between the "beginner mentality" that is often
associated with the use of such environments and Axiom's philosophy,
but that just makes it more interesting :-).  The ideal case would be
to have the ability to make assumptions about one's environment, and as
those assumptions are added or removed the interface behavior changes
according to what is allowed in the new "environment."  E.g., there
will be operations that might be legal if certain assumptions are made,
that are not true in general, and if your environment is less or more
general the interface knows that and acts accordingly.

Not sure that's even doable in the case of TeXmacs - IIRC it's rules
for mathematical interaction are those of a document editor, and not
really responsive to mathematical constraints. It would be difficult
even with something like a lisp interface, because interaction
behaviors would have to be defined, and some kind of mapping made
between those mappings and mathematical behavior.  What a nifty
research project :-).

\start
Date: Fri, 26 Aug 2005 15:39:47 -0400
From: Tim Daly
To: Andrey G. Grozin
Subject: Re: steps towards better TeXmacs interface

> 1. What is the correct file to put the definition and initialisation of 
>    $InterfaceStrings ?

choose a new file.

> 2. Is there some way in which this initialisation could be made dependent 
>  on external conditions? For example, can I pass a command-line argument to 
>  AXIOMsys, and check it in boot code? Or check an environment variable in 
>  the boot code?
>  At the moment, I know only one way to pass some information to axiom: 
>  .axiom.input. But it would not be a good idea for TeXmacs, for example, to 
>  overwrite the user's .axiom.input (if the user has one).

Generally when you want a certain special output mode in Axiom the technique
is to use
  )set output texmacs on
which sets a flag enabling the output.

> Making text exchanges between axiom and an external program to follow some 
> structured, predictable protocol (without playing guessing games) is the 
> first and the most important goal. But there are further necessary steps. 
> The current TeX generation (algebra/tex.spad.pamphlet) was written 15 
> years ago. Naturally, it does not produce modern standard LaTeX. I've made 
> a number of changes in tex.spad.pamphlet, to produce more 
> standards-complying LaTeX code instead of some historic relicts ( \over , 
> \sub , \root ... \of ... , etc.). But this is not exactly what's needed. 

It's "old-style" tex but still seems to work. The book uses it everywhere.
Why is it necessary to change it? Given the hundreds of things that need
work this is pretty low on my list but you're welcome to investigate what
might be needed. I believe that the line-break algorithm might be sensitive
to these tex symbols but memory fails me in the details.

> TeXmacs has some strange requirements of its own (e.g., using \* for 
> multiplication). Therefore, I want to leave the old TeX generation alone, 
> and to introduce the new kind of output: texmacs. So that it will be 
> possible to say
> )set output texmacs on

This would be the correct path. Then texmacs can adapt axiom to its needs.
Writing output delimiters could be transparent since they would not
normally be seen by users and can be removed by Texmacs

> OK, I can easily duplicate tex.spad.pamphlet (should this be a new file, 
> texmacs.spad.pamphlet, or I just double the contents of tex.spad.pamphlet 
> ?) I'll rename the domain TexFormat to TexmacsFormat, and make the 
> improvements I want. But what to do next? My (very incomplete...) 
> understanding is that I should insert the necessary pieces into 
> setvars.boot.pamphlet and setvart.boot.pamphlet (based on the TeX pieces, 
> with renamings and some small changes). But setvars.boot.pamphlet says 
> that if I change the boot code (and I'm going to do this), I have to 
> translate it to lisp and insert it into the same file. How do I do this, 
> exactly?

I wish I knew what needed to be done exactly but I haven't modified that
code in 15 years so your guess is nearly as good as mine. All I can suggest
is to experiment and document. Please document as you go so we don't have
to reverse engineer it a second time.

> The new domain TexmacsFormat is the natural place to put the line-breaking 
> functionality. Some ideas can be taken from the C code which does such 
> line-breaking, and which is available. Of course, it is much more natural 
> to do this in the spad domain, where all the information about the 
> expression structure is available. Also, this C code generates LaTeX which 
> gives a reasonably-looking output, but is mathematically meaningless (it 
> uses \array's all over the place for things which are not arrays). This 
> leads to the fact that, if this C code is used, it is absolutely 
> impossible (and never will be possible) to copy a (part of) output by the 
> mouse and insert in into an input field (because it is not possible to 
> reconstruct the mathematical meaning of an expression from this obfuscated 
> LaTeX). And this goal is highly desirable. Therefore, the aim of 
> TexmacsForm will be to generate a meaningful LaTeX, with line breaking, 
> which can be used as a source of drag-and-drop in TeXmacs.

I'm not sure what it means to "drag and drop" a 2D expression into a 1D
input line. Who flattens the line? I've never seen a specification of a
mapping from 1D <-> 2D. We do it all the time by hand, of course, but 
that's not good enough for a machine. Furthermore each Axiom domain
determines its own OutputForm representation (internal structure -> 2D).
The surface structure (print representation) might not carry all of
the needed information, most of which is hidden in the internal type.

> There is another possibility, which requires some thought. What if we send 
> expression tree from axiom to TeXmacs as an S-expression, instead of 
> serializing it via LaTeX? TeXmacs understands not only latex: fields, but 
> also scheme: fields. Generating scheme syntax from an axiom expression may 
> well be easier than generating LaTeX. Line breaking can be done on the 
> TeXmacs side, where the necessary information is available (it is in 
> principle impossible to tell, what is the width of a sub-expression after 
> typesetting, without actually typesetting it). But this is, probably, a 
> more long-term project. For now, I'd better keep as much as possible from 
> the current interface, but make it more robust and less ugly.

The notion of an S-expression form of an expression comes up a few times
a year. Axiom does not have such a notion. The closest you can come to
it (as far as I'm aware) is to:

===================================================================
FAQ 19: How can I get equations written on one line?
===================================================================

> Dear Axiom supporters,
> 2. I would also like to have the output of kind
> 
>  "  - (s-1) * (s+1) * (p^4 +(2*e^3 + (24*s^2 - 4)*e)*p^3 * ...) * ... 
>  "
> 
> For example, my DoCon program can read this format ...
> 
> 2.1 It prints these polynomials like for  (Z[e])[p]:  
>                                               " (e^2 + 2e)*p "
>     How to print it like for  Z[p,e]: 
>                                               " 2*p*e + e^2 "

You may wish to use the InputForm domain, where you can find some
bizarre functions. In your case, "unparse" may help you, as follows.

(1) -> p:=(a+b+y)^2*y+1-(x+y+z)^4

   (1)
        4               3        2             2  2
     - z  + (- 4y - 4x)z  + (- 6y  - 12x y - 6x )z
   + 
          3        2      2      3      4              3        2            2
     (- 4y  - 12x y  - 12x y - 4x )z - y  + (- 4x + 1)y  + (- 6x  + 2b + 2a)y
   + 
          3    2           2      4
     (- 4x  + b  + 2a b + a )y - x  + 1
                                                     Type: Polynomial Integer
(2) -> pi:=p::InputForm

  (2)
  (+
     (+
       (+  (+ (* - 1 (** z 4)) (* (+ (* - 4 y) (* - 4 x)) (** z 3)))
       (* (+ (+ (* - 6 (** y 2)) (* (* - 12 x) y)) (* - 6 (** x 2))) (** z 2)))

      (*
         (+
           (+  (+ (* - 4 (** y 3)) (* (* - 12 x) (** y 2)))
           (* (* - 12 (** x 2)) y))
          (* - 4 (** x 3)))
        z)
      )

    (+
       (+
         (+  (+ (* - 1 (** y 4)) (* (+ (* - 4 x) 1) (** y 3)))
         (* (+ (* - 6 (** x 2)) (+ (* 2 b) (* 2 a))) (** y 2)))
        (* (+ (* - 4 (** x 3)) (+ (+ (** b 2) (* (* 2 a) b)) (** a 2))) y))
      (+ (* - 1 (** x 4)) 1))
    )
                                                              Type: InputForm
(3) -> unparse(pi)

   (3)
  "(-z**4)+((-4*y)+(-4*x))*z**3+((-6*y*y)+(-12*x*y)+(-6*x*x))*z*z+((-4*y**3)+(-
  12*x*y*y)+(-12*x*x*y)+(-4*x**3))*z+(-y**4)+((-4*x)+1)*y**3+((-6*x*x)+2*b+2*a)
  *y*y+((-4*x**3)+b*b+2*a*b+a*a)*y+(-x**4)+1"
                                                                 Type: String


Aternatively you can get the LaTex output string:

(4) -> )lisp (|parseAndInterpret| "integrate(sin(x),x)::TexFormat::OutputForm")


   (4)  ["$$","-{\cos ","\left(","{x} ","\right)}","$$"]
                                                             Type: OutputForm
Value = ((|OutputForm|) WRAPPED BRACKET (AGGLST "\"$$\"" "\"-{\\cos \""
"\"\\left(\"" "\"{x} \"" "\"\\right)}\"" "\"$$\""))

or the text form:

(5) -> )lisp (|parseAndInterpret| "integrate(sin(x),x)::OutputForm")

   (5)  - cos(x)
                                                             Type: OutputForm
Value = ((|OutputForm|) WRAPPED "-" (|cos| |x|))

or the actual string output:

Axiom's algebra gets output to a stream called |$algebraOutputStream|
Thus you can get the output you want by:

)set message autoload off
)lisp (progn
          ; we need a new output stream that is backed by a string
        (setq tmpout (make-string-output-stream))
          ; we hold on to the regular algebra output stream
        (setq save |$algebraOutputStream|)
          ; we capture the algebra output into the string stream
        (setq |$algebraOutputStream| tmpout)
          ; we generate output from string input
        (|parseAndInterpret| "(x+1)^9")
          ; we save the output into the result variable
        (setq result (get-output-stream-string |$algebraOutputStream|))
          ; we restore the regular algebra output stream
        (setq |$algebraOutputStream| save)
          ; and we return the string as our value
        result)

)lisp result

result contains the output from axiom that you want.

===================================================================
FAQ 32: How can I input an equation as a string?
===================================================================

There is an embedded command server within AXIOMsys.
Look at:
http://daly.axiom-developer.org/TimothyDaly_files/lisptalk/pages/lisp35.html

In particular, see the function

  parseAndInterpret stringBuf

(which is boot language code. So in lisp I have
to tack on the | | onto the function name and then I can
call it like this:

  (1) -> )lisp (|parseAndInterpret| "integrate(sin x,x)")

   (1)  - cos(x)
                          Type: Union(Expression Integer,...)

  Value = ((|Union| (|Expression| (|Integer|)) (|List| (|Expression|
(|Integer|)))
  ) WRAPPED 0 (1 #<vector 10ccde54> (1 0 . -1)) 0 . 1)

  (2) ->

and sure enough! Axiom parses and interprets the string.

The result appears as stdout and the value returned
seems to contain the type information. The "WRAPPED"
information is the lisp data structure.

> The string output function mentioned in FAQ 19 is a linear
> form of the output. However Axiom's native output machinery
> is called CHARYBDIS which was a research project from the
> 60s with the goal of printing mathematics on typewriters.
> Axiom still uses that code.

\start
Date: Fri, 26 Aug 2005 21:59:56 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: steps towards better TeXmacs interface

C Y writes:
 > I think I know what Andrey is thinking about here.  Let's say we have
 > the following expression:
 > 
 > 				  2
 > 				 b  + 2 a
 > 				 -------- + c
 > 				    d
 >  				 ------------
 > 				    f + e
 > 
 > and we want to select:
 > 
 > 				    2
 > 				   b  + 2 a
 > 				   -------- 
 > 				      d
 > 
 > as our input in the next line. 

I'd say that this is not the way things work in Axiom. There is a hack on
MathAction that does this kind of thing.

But please keep the following in mind:

Axiom is designed in a way that you can, for example, replace the domain EXPR ?
with something entirely different, keeping only the interface the same. Of
course, coercing to SExpression is part of the interface, but I would suggest
that you don't work against Axioms philosophy.

Note also that "hidden" type information is crucial:

(13) -> 3*(y*x::XPOLY INT)

   (13)  y x 3
                                                    Type: XPolynomial Integer
(14) -> 3*y*x

   (14)  3x y
                                                     Type: Polynomial Integer

(XPOLY: variables do not commute)

\start
Date: Fri, 26 Aug 2005 16:28:40 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: steps towards better TeXmacs interface

On August 26, 2005 4:00 PM Martin Rubey wrote:
> 
> C Y writes:
> > I think I know what Andrey is thinking about here.  Let's 
> > say we have the following expression:
> > 
> > 				  2
> > 				 b  + 2 a
> > 				 -------- + c
> > 				    d
> >  				 ------------
> > 				    f + e
> > 
> > and we want to select:
> > 
> > 				    2
> > 				   b  + 2 a
> > 				   -------- 
> > 				      d
> > 
> > as our input in the next line. 
>

I think that is a very good and entirely plausible example.
 
> I'd say that this is not the way things work in Axiom. There 
> is a hack on MathAction that does this kind of thing.
>

Martin, could you be more specific? What "hack on MathAction"
are you referring to?

Although I think I see your point about "not the way things
work in Axiom", I also think you are being too strict when
it comes to user interface. Axiom is designed as a deeply
nested series of levels. A the user interface level a lot of
"less strict" things are done in the name of being more
"user friendly". This is a difficult problem and I think
achieving a truly effective user interface is still more a
matter of art (and luck) than it is a matter of good design
or engineering.

> But please keep the following in mind:
> 
> Axiom is designed in a way that you can, for example, replace 
> the domain EXPR ? with something entirely different, keeping
> only the interface the same. Of course, coercing to Sexpression
> is part of the interface, but I would suggest that you don't
> work against Axioms philosophy.
> 
> Note also that "hidden" type information is crucial:
> 
> (13) -> 3*(y*x::XPOLY INT)
> 
>    (13)  y x 3
>                                                     Type: 
> XPolynomial Integer
> (14) -> 3*y*x
> 
>    (14)  3x y
>                                                      Type: 
> Polynomial Integer
> 
> (XPOLY: variables do not commute)
> 

We should not forget that Numerical Algorithms Group put a lot
of work into Axiom to produce OpenMath output. One of the goals
of OpenMath is to encode precisely this kind of information with
an aim to being able to communicate mathematics in full generality
between different computer algebra systems. And of course this
could also include between a compute algebra system and an
intelligent editor/user interface. All of the NAG OpenMath code
is availabe but has not (yet) been integrated into the open source
version of Axiom.

\start
Date: Fri, 26 Aug 2005 16:02:15 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [reading structures from a file] (nouveau) 

This package provides operations that all take a filename and return
an axiom structure which is supposed to be in some standard notation
in this file. Geared towards polymake.

\begin{axiom}
)abbrev package READFILE ReadFile
ReadFile(): Exports == Implementation where
    Exports == with

      getBoolean: FileName -> Boolean

      getInteger: FileName -> Integer

      getListInteger: FileName -> List Integer

      getListFraction: FileName -> List Fraction Integer

      getVectorInteger: FileName -> Vector Integer

      getVectorFraction: FileName -> Vector Fraction Integer

      getSetInteger: FileName -> Set Integer

      getMatrixInteger: FileName -> Matrix Integer

      getMatrixFraction: FileName -> Matrix Fraction Integer

      getListSetInteger: FileName -> List Set Integer

    Implementation == add

      getBoolean polytmpfile ==
        f := open(polytmpfile)$TextFile
        read!(f)$TextFile
        r:String := read!(f)$TextFile
        close!(f)$TextFile

        (r="1")

      getInteger polytmpfile ==
        f := open(polytmpfile)$TextFile
        read!(f)$TextFile
        r:String := read!(f)$TextFile
        close!(f)$TextFile

        coerce(r)$StringConversions

      getListInteger polytmpfile ==
        f := open(polytmpfile)$TextFile
        read!(f)$TextFile
        r:String := read!(f)$TextFile
        close!(f)$TextFile
        coerce(r)$StringConversions

      getListFraction polytmpfile ==
        f := open(polytmpfile)$TextFile
        read!(f)$TextFile
        r:String := read!(f)$TextFile
        close!(f)$TextFile
        coerce(r)$StringConversions

      getVectorInteger polytmpfile == 
        vector(getListInteger polytmpfile)$Vector(Integer)

      getVectorFraction polytmpfile == 
        vector(getListFraction polytmpfile)$Vector(Fraction Integer)

      getSetInteger polytmpfile == 
        f := open(polytmpfile)$TextFile
        read!(f)$TextFile
        r:String := read!(f)$TextFile
        close!(f)$TextFile
        coerce(r)$StringConversions

      getMatrixInteger polytmpfile ==
        f := open(polytmpfile)$TextFile
        read!(f)$TextFile
        m: List List Integer := []
        r: String
        while not endOfFile?(f) repeat
          r := read!(f)$TextFile
          if not empty? r then 
            m := cons(coerce(r)$StringConversions, m)

        close!(f)$TextFile
        matrix(reverse m)$Matrix(Integer)

      getMatrixFraction polytmpfile ==
        f := open(polytmpfile)$TextFile
        read!(f)$TextFile
        m: List List Fraction Integer := []
        r: String
        while not endOfFile?(f) repeat
          r := read!(f)$TextFile
          if not empty? r then 
            m := cons(coerce(r)$StringConversions, m)

        close!(f)$TextFile
        matrix(reverse m)$Matrix(Fraction Integer)

      getListSetInteger polytmpfile ==
        f := open(polytmpfile)$TextFile
        read!(f)$TextFile
        m: List Set Integer := []
        r: String
        while not endOfFile?(f) repeat
          r := read!(f)$TextFile
          if not empty? r then 
            m := cons(coerce(r)$StringConversions, m)

        close!(f)$TextFile
        reverse m
\end{axiom}

\start
Date: Fri, 26 Aug 2005 15:59:26 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [string conversions] (nouveau) 

Here is a package that converts strings to numbers. It is only to be considered as a starting point. There is no error checking, it is probably slow and certainly buggy...

\begin{axiom}
)abbrev package STRCNV StringConversions
StringConversions(): Exports == Implementation where
    Exports == with

      coerce: String -> Integer

      coerce: String -> Fraction Integer

      coerce: String -> List Fraction Integer

      coerce: String -> List Integer

      coerce: String -> Set Integer
      
    Implementation == add
      
      sexfloat:SExpression:=convert(coerce("Float")@Symbol)$SExpression

      coerce(s: String): Fraction Integer ==
        if not NUMBERP(READ_-FROM_-STRING(s)$Lisp)$Lisp
        then error "coerce: String -> Fraction Integer: not a number"
        else
          sex := interpret(packageTran(ncParseFromString(s)$Lisp)$Lisp)$Lisp
          if (car car sex = sexfloat) then
             retract((cdr cdr sex) pretend Float)@Fraction(Integer)
          else
            if integer?(cdr sex) then
              ((cdr sex) pretend Integer)::Fraction Integer
            else
              (cdr cdr sex) pretend Fraction Integer

      coerce(s: String): Integer ==
        PARSE_-INTEGER(s)$Lisp

      coerce(r: String): List Fraction Integer ==
        map(coerce #1, split(r, char(" "))$String)_
          $FiniteLinearAggregateFunctions2(String, List String, Fraction Integer, _
                                           List Fraction Integer)

      coerce(r: String): List Integer ==
        map(coerce(#1), split(r, char(" "))$String)_
          $FiniteLinearAggregateFunctions2(String, List String, Integer, _
                                           List Integer)

      coerce(r: String): Set Integer ==
        s: String := delete(delete(r, #r), 1)
        brace(map(PARSE_-INTEGER(#1)$Lisp, split(s, char(" "))$String)_
          $FiniteLinearAggregateFunctions2(String, List String, Integer, _
                                           List Integer))$Set(Integer)

\end{axiom}

Let's try it:

\begin{axiom}
coerce("123.12")@FRAC INT
\end{axiom}

\start
Date: Fri, 26 Aug 2005 16:03:40 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [reading structures from a file] 

This package provides operations that all take a filename and return an axiom structure which is supposed to be in some standard notation in this file. Geared towards polymake. Needs 'StringConversions'

\begin{axiom}
)lib STRCNV
\end{axiom}

\start
Date: Fri, 26 Aug 2005 17:08:12 -0400
From: Tim Daly
To: Camm Maguire
Subject: gcl-2.6.7 and FC4

GCL-2.6.7 fails to build on FC4.
I'm trying to debug it now but I thought I'd mention it in case
anyone already knows why.


\start
Date: 26 Aug 2005 18:03:03 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: gcl-2.6.7 and FC4

Greetings!

This is the first I've heard -- please keep me posted of your
findings.  

It appears that every single FC release is going to break lisp as new
'enhancement/feature'.

Take care,

Tim Daly writes:

> GCL-2.6.7 fails to build on FC4.
> I'm trying to debug it now but I thought I'd mention it in case
> anyone already knows why.

\start
Date: Fri, 26 Aug 2005 16:56:01 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [polymake] 

\begin{axiom}
)lib STRCNV READFILE
\end{axiom}

    Cardinal ==> NonNegativeInteger
    Scalar   ==> Fraction Integer

      points: % -> Matrix Scalar
      ++ Points such that the polyhedron is their convex hull. Redundancies are
      ++ allowed. Vector (x0 x1 .. xd) represents a point in (d+1)-space
      ++ (homogeneous coordinates.) Affine points are identified by x0 >
      ++ 0. Points with x0 = 0 can be interpreted as rays.  polymake
      ++ automatically normalizes each coordinate vector, dividing them by the
      ++ first non-zero element. The clients and rule subroutines can always
      ++ assume that x0 is either 0 or 1. Dual to INEQUALITIES.  Input section
      ++ only. Ask for VERTICES if you want to compute a V-representation from
      ++ an H-representation.

      vertices: % -> Matrix Scalar
      ++ Vertices of the polyhedron. No redundancies are allowed. The
      ++ coordinates are normalized the same way as POINTS. Dual to FACETS.

      inequalities: % -> Matrix Scalar
      ++ Inequalities that describe half-spaces such that the polyhedron is
      ++ their intersection. Redundancies are allowed. Dual to POINTS.  A
      ++ vector (A0 A1 .. Ad) defines the (closed affine) half-space of points
      ++ (1,x1,..,xd) such that A0 + A1 x1 + .. + Ad xd >= 0.  Input section
      ++ only. Ask for FACETS and AFFINE_HULL if you want to compute an
      ++ H-representation from a V-representation.

      facets: % -> Matrix Scalar
      ++ Facets of the polyhedron, encoded as INEQUALITIES. Dual to VERTICES. 

      equations: % -> Matrix Scalar
      ++ Equations that hold for all points of the polyhedron.  A vector (A0 A1
      ++ .. Ad) describes the hyperplane of all points (1,x1,..,xd) such that
      ++ A0 + A1 x1 + .. + Ad xd = 0.  Input section only. Ask for AFFINE_HULL
      ++ if you want to see an irredundant description of the affine span.

      affineHull: % -> Matrix Scalar
      ++ Dual basis of the affine hull of the polyhedron. 

      vertexNormals: % -> Matrix Scalar
      ++ The i-th row is the normal vector of a hyperplane separating the i-th
      ++ vertex from the rest ones. This property is a by-product of redundant
      ++ point elimination algorithm.

      validPoint: % -> Vector Scalar
      ++ Some point belonging to the polyhedron. 

      dim: % -> Cardinal 
      ++ Dimension of the affine hull of the polyhedron = dimension of the
      ++ polyhedron. If the polytope is given purely combinatorically, it's the
      ++ dimension of a minimal embedding space deduced from the combinatorial
      ++ structure.

      ambientDim: % -> Cardinal 
      ++ Dimension of the space where the polyhedron lives in. 

      feasible: % -> Boolean 
      ++ True if the polyhedron is not empty. 

      pointed: % -> Boolean 
      ++ True if the polyhedron does not contain an affine line. 

      farFace: % -> Set Cardinal
      ++ Indices of vertices that are rays. 

      unboundedFacets: % -> Set Cardinal
      ++ Indices of facets that are unbounded. 

      bounded: % -> Boolean 
      ++ True if the polyhedron is a bounded polytope. 

      centered: % -> Boolean 
      ++ True if (1,0,0,..) is a relative interior point. Polar to BOUNDED. 

      positive: % -> Boolean 
      ++ True if all vertices of the polyhedron have non-negative coordinates,
      ++ that is, it lies entirely in the positive orthant.

      polydir: String := "/tmp/"

      polytmp: String := polydir "tmp.poly"

      polylib: String := "/usr/local/polymake/bin/"

      polytmpfile:FileName := polytmp::FileName

      polycons: (String, String, String) -> %
      polycons(rep, cmd, prm) ==
        systemCommand("system " polylib cmd " " polydir rep ".poly " prm)_
                     $MoreSystemCommands
        rep::Rep

      polyprop: (%, String) -> Void
      polyprop(rep, cmd) ==
       systemCommand("system " polylib "polymake " polydir (rep::Rep) ".poly "_
                      cmd " > " polytmp)$MoreSystemCommands

        polycons("cube" string(n), "cube", string(n))

        polycons("cross" string(n), "cross", string(n))

      rand01(d, n) == 
        polycons("rand01" string(d) string(n), "rand01", _
                 string(d) " " string(n))

      randSphere(d, n) ==  
        polycons("randsphere" string(d) string(n), "rand__sphere", _
                 string(d) " " string(n))

        polyprop(s, "F__VECTOR")
        getVectorInteger(polytmpfile)$ReadFile

        polyprop(s, "F2__VECTOR")
        getMatrixInteger(polytmpfile)$ReadFile

        polyprop(s, "H__VECTOR")
        getVectorInteger(polytmpfile)$ReadFile

      simple s == 
        polyprop(s, "SIMPLE")
        getBoolean(polytmpfile)$ReadFile

      points s == 
        polyprop(s, "POINTS")
        getMatrixFraction(polytmpfile)$ReadFile

        polyprop(s, "VERTICES")
        getMatrixFraction(polytmpfile)$ReadFile

      inequalities s == 
        polyprop(s, "INEQUALITIES")
        getMatrixFraction(polytmpfile)$ReadFile

      facets s == 
        polyprop(s, "FACETS")
        getMatrixFraction(polytmpfile)$ReadFile

      equations s == 
        polyprop(s, "EQUATIONS")
        getMatrixFraction(polytmpfile)$ReadFile

      affineHull s == 
        polyprop(s, "AFFINE__HULL")
        getMatrixFraction(polytmpfile)$ReadFile

      vertexNormals s == 
        polyprop(s, "VERTEX__NORMALS")
        getMatrixFraction(polytmpfile)$ReadFile

      validPoint s == 
        polyprop(s, "VALID__POINT")
        getVectorFraction(polytmpfile)$ReadFile

      dim s == 
        polyprop(s, "DIM")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      ambientDim s == 
        polyprop(s, "AMBIENT__DIM")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      feasible s == 
        polyprop(s, "FEASIBLE")
        getBoolean(polytmpfile)$ReadFile

      pointed s == 
        polyprop(s, "POINTED")
        getBoolean(polytmpfile)$ReadFile

      farFace s == 
        polyprop(s, "FAR__FACE")
        map(#1 pretend Cardinal, getSetInteger(polytmpfile)$ReadFile)_
           $FiniteSetAggregateFunctions2(Integer, Set Integer, 
                                         Cardinal, Set Cardinal)


      unboundedFacets s == 
        polyprop(s, "UNBOUNDED__FACETS")
        map(#1 pretend Cardinal, getSetInteger(polytmpfile)$ReadFile)_
           $FiniteSetAggregateFunctions2(Integer, Set Integer, 
                                         Cardinal, Set Cardinal)

      bounded s == 
        polyprop(s, "BOUNDED")
        getBoolean(polytmpfile)$ReadFile

      centered s == 
        polyprop(s, "CENTERED")
        getBoolean(polytmpfile)$ReadFile

      positive s == 
        polyprop(s, "POSITIVE")
        getBoolean(polytmpfile)$ReadFile

\start
Date: 26 Aug 2005 23:36:54 -0400
From: Camm Maguire
To: Juho Snellman
Subject: Re: [Gcl-devel] Re: gcl-2.6.7 and FC4

Greetings!

Here is what we've been doing since early FC:

int
main(int argc, char **argv, char **envp) {

#ifdef NEED_NONRANDOM_SBRK
#if SIZEOF_LONG == 4
	if (!syscall(SYS_personality,PER_LINUX32))
#else
        if (!syscall(SYS_personality,PER_LINUX))
#endif
	  execvp(argv[0],argv);
#endif


so either:

1) configure is not detecting the situation and defining
   NEED_NONRANDOM_SBRK
2) the syscall syntax is changed
3) the problem lies somewhere else

it would appear.

Take care,


Juho Snellman writes:

> Tim Daly wrote:
> > GCL-2.6.7 fails to build on FC4.
> > I'm trying to debug it now but I thought I'd mention it in case
> > anyone already knows why.
> 
> FC4 randomizes the brk (and a bunch of other memory regions) more
> agressively than the exec-shield patches in previous Fedora kernels.
> Also the old methods of marking the executable as non-randomizable
> don't work any more. To test whether this is the reason, try building
> under setarch ("setarch i386 -R make"). 
> 
> The only working method of disabling the randomization seems to be
> doing something like this at startup:
> 
>     {
>        long pers = personality(-1);
>        /* 0x40000 aka. ADDR_NO_RANDOMIZE */
>        if (!(pers & 0x40000)) {
>            personality(pers | 0x40000);
>            execve(argv[0], argv, envp);
>        }
>     }   
> 
> See the sbcl-devel thread "Memory randomization problems coming" for
> some more information on this.
> 
> -- 
> Juho Snellman

\start
Date: Sat, 27 Aug 2005 00:10:20 -0400
From: Bill Page
To: list
Subject: JavaView - Interactive 3D Geometry and	Visualization

http://www.javaview.de

JavaView is a 3D geometry viewer and a mathematical visualization
software. The web-integration allows display of 3D geometries and
interactive geometry experiments in any HTML document on the internet.
JavaView also runs as application on local computers from a Unix or Dos
command  prompt. The open API of JavaView enables a smooth integration
as 3D viewer and advanced visualization toolkit into commercial software
like  Mathematica and Maple.

JavaView-Lite: this tiny version of JavaView is optimized for fast
download and contains the viewer module only, without any dialogs,
inspectors and geometry algorithms. The lite version is mainly used to
display precomputed geometry models inside web pages such as the solid
shown to the right.

----------

JavaView looks very interesting both for integration with Axiom
and (possibly) for interactive graphics via MathAction and (maybe)
also in the new AxiomUI project.

At the above web site I was not able to find any information
about licensing. During download it says "registration" is
required but it does not seem to place any other restrictions
on the use or duplication of the code.

Does anyone know whether it might be possible to consider
this program "open source"?

\start
Date: Sat, 27 Aug 2005 09:39:33 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Mathaction and polymake problem

Sending this also to axiom-developer...

Thank you Bill for your fast actions! That's really great! I tried around a
little, but I didn't have the idea to write the error message into a
file... stupid me.

While we are at it: I'd suggest that you disable the possibility to comment on
FrontPage, if this is easily done. (If it's more than five minutes of work,
don't do it)

Sometime in the future there should also be a redesign of the structure of
MathAction, but I'd like to think a little about it. IssueTracker has become
the most important tool for me. Maybe the contents of the pages WishList and
SummerOfCode should be transferred to individual IssueTracker pages. On the
other hand, I'd like to be able to group the issues somehow by topic: it is
quite handy to have a page with integration problems where they are all grouped
together. Maybe the solution is to keep the pages as they are -- i.e., with a
short description - but to point to the appropriate IssueTracker pages for
elaborations.

The second thing that really occupies me: I think it's high time to make some
advertisements for axiom again. It has changed quite a bit from the last
announcement. Tim: if we make an announcement in (mid-)September, which patch
number will be the regular Axiom version? (CVS, I believe) 

patch-44 or patch-45 ? 
Would the aldor stuff make it?
if I send you a (documented) patch for the integration issue #199, would it
make it into the release?

I think we somehow need to manage to find a group that chooses axiom as it's
development platform. Otherwise axiom will stay what it is, and that's just not
good enough. I think your efforts with the Conference and the various efforts
by Bill are really great Contributions to this end. I'd like to say thank you
again!

I talked a little with Ralf about the petition to free Aldor. I'll set up a
page on MathAction to design an appropriate letter this weekend, I hope.

\start
Date: Sat, 27 Aug 2005 14:23:21 +0700 (NOVST)
From: Andrey G. Grozin
To: Cliff Yapp
Subject: Re: steps towards better TeXmacs interface

On Fri, 26 Aug 2005, C Y wrote:
> I think I know what Andrey is thinking about here.  Let's say we have
> the following expression:
> 
> 				  2
> 				 b  + 2 a
> 				 -------- + c
> 				    d
>  				 ------------
> 				    f + e
> 
> and we want to select:
> 
> 				    2
> 				   b  + 2 a
> 				   -------- 
> 				      d
> 
> as our input in the next line.  The natural thing to want to do in a
> graphical mathematical document environment is graphically select the
> desired subexpression and paste that to the input line.
Yes. This is currently possible in TeXmacs/maxima (well, in most cases...)

\start
Date: Sat, 27 Aug 2005 14:25:46 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [reading structures from a file] 

      getFraction: FileName -> Fraction Integer

      getFraction polytmpfile ==
        f := open(polytmpfile)$TextFile
        read!(f)$TextFile
        r:String := read!(f)$TextFile
        close!(f)$TextFile

        coerce(r)$StringConversions

\start
Date: Sat, 27 Aug 2005 15:32:45 -0500
From: MathAction (unknown)
To: MathAction
Subject: [build Axiom] cvs problem

cvs -z3 -d:ext:anoncvs@savannah.nongnu.org:/cvsroot/axiom co axiom
nongnu.org: Operation timed out
cvs [checkout aborted]: end of file from server (consult above messages if any)

\start
Date: Sat, 27 Aug 2005 15:29:21 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] link broken

Bill:

The links to April-2005-Sources 

http:/zope/mathaction/Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Apr2005-src.tgz&it=April+2005+Sources

and February-2005-Sources on this page are broken.

\start
Date: Sat, 27 Aug 2005 16:15:01 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] Re: link broken

William,

I just tested and both of these links worked fine for me but they
were using the 'http:/xxx/yyy' type of url without an explicit machine
name. On some (weird old browsers) this type of link apparently doesn't
work. When I use FireFox 1.0.5 on Windows they work fine and I never
had trouble with Windows Explorer 6. What browser and version are you
using? What error message did you get?

Anyway, I changed the links to remove the 'http:' prefix which seems
to work better in some cases. Let me know if it works for you now.

\start
Date: Sat, 27 Aug 2005 16:11:01 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] Maybe a problem with http: prefix without machine name

sources":/zope/mathaction/Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Apr2005-src.tgz&it=April+2005+Sources

  * "February 2005 sources":/zope/mathaction/Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-20050201-src.tgz&it=February+2005+source+code

\start
Date: Sat, 27 Aug 2005 19:40:42 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] Works now

Thanks Bill. I was using Safari on a Mac OS X.

\start
Date: Sat, 27 Aug 2005 23:30:33 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [polymake] 

\begin{spad}

      nPoints: % -> Cardinal 
      ++ Number of points. 

      nInequalities: % -> Cardinal 
      ++ Number of inequalities. 

      vertexBarycenter: % -> Vector Scalar
      ++ The center of gravity of the vertices of a bounded polytope. 

      minimalVertexAngle: % -> Scalar 
      ++ The minimum angle between any two vertices (seen from the
      ++ VERTEXBARYCENTER).  

      zonotopeInputVectors: % -> Matrix Scalar
      ++ Contains the vector configuration for which a zonotope can be built.

      reverseTransformation: % -> Matrix Scalar
      ++ Some invertible linear transformation that can be used to get back a
      ++ previous coordinate repersentation of the polytope. It operates from
      ++ the right on point row vectors (e.g. in properties like POINTS,
      ++ VERTICES, REL_INT_POINT); its inverse operates from the left on
      ++ hyperplane column vectors.

      galeTransform: % -> Matrix Scalar
      ++ Coordinates of the Gale transform.

      steinerPoints: % -> Matrix Scalar
      ++ A weighted inner point depending on the outer angle called Steiner
      ++ point for all faces of dimensions 2 to d. 

--  Combinatorics
   
      nVertices: % -> Cardinal 
      ++ Number of vertices.

      nBoundedVertices: % -> Cardinal 
      ++ Number of bounded vertices (non-rays).

      nFacets: % -> Cardinal 
      ++ Number of facets.

      nVertexFacetInc: % -> Cardinal 
      ++ Number of pairs of incident vertices and facets.

      nEdges: % -> Cardinal 
      ++ Number of edges.

      nRidges: % -> Cardinal 
      ++ Number of ridges.

      diameter: % -> Cardinal 
      ++ Graph theoretical diameter of GRAPH.

      dualDiameter: % -> Cardinal 
      ++ Graph theoretical diameter of DUAL_GRAPH.

      triangleFree: % -> Boolean 
      ++ True if GRAPH does not contain a triangle.

      dualTriangleFree: % -> Boolean 
      ++ True if DUAL_GRAPH does not contain a triangle.

      altshulerDet: % -> Cardinal 
      ++ Let M be the vertex-facet incidence matrix, then the Altshulter
      ++ determinant is defined as max{det(M?MT), det(MT?M)}.

      fVector: % -> Vector Cardinal
      ++ fk is the number of k-faces.

      f2Vector: % -> Matrix Cardinal
      ++ fik is the number of incident pairs of i-faces and k-faces; the main
      ++ diagonal contains the F_VECTOR.

      flagVector: % -> Vector Cardinal
      ++ Condensed form of the flag vector. Use Dehn-Sommerville equations, via
      ++ user function N_FLAGS, to extend.

      cdIndexCoefficients: % -> Vector Cardinal
      ++ Coefficients of the cd-index.

      hVector: % -> Vector Cardinal
      ++ Simplicial h-vector. Defined for simplicial polytopes and also for
      ++ their duals.

      cubicalHVector: % -> Vector Cardinal
      ++ undocumented

      essentiallyGeneric: % -> Boolean 
      ++ all intermediate polytopes (with respect to the given insertion order)
      ++ in the beneath-and-beyond algorithm are simplicial. We have the ++
      ++ implication : VERTICES in general position => ESSENTIALLY_GENERIC =>
      ++ SIMPLICIAL

      simplicial: % -> Boolean 
      ++ True if the polytope is simplicial.

      simple: % -> Boolean 
      ++ True if the polytope is simple. Dual to SIMPLICIAL.

      even: % -> Boolean 
      ++ True if the GRAPH of the polytope is bipartite.

      dualEven: % -> Boolean 
      ++ True if the DUAL_GRAPH of the polytope is bipartite. Dual to EVEN.

      connectivity: % -> Cardinal 
      ++ Node connectivity of the GRAPH of the polytope, that is, the minimal
      ++ number of nodes to be removed from the graph such that the result is
      ++ disconnected.

      dualConnectivity: % -> Cardinal 
      ++ Node connectivity of the DUAL_GRAPH of the polytope. Dual to
      ++ CONNECTIVITY.

      simpliciality: % -> Cardinal 
      ++ Maximal dimension in which all faces are simplices.

      simplicity: % -> Cardinal 
      ++ Maximal dimension in which all dual faces are simplices.

      faceSimplicity: % -> Cardinal 
      ++ Maximal dimension in which all faces are simple polytopes.

      cubical: % -> Boolean 
      ++ True if all facets are cubes.

      cubicality: % -> Cardinal 
      ++ Maximal dimension in which all facets are cubes.

      cocubical: % -> Boolean 
      ++ Dual to CUBICAL.

      cocubicality: % -> Cardinal 
      ++ Dual to CUBICALITY.

      neighborly: % -> Boolean 
      ++ True if the polytope is neighborly.

      neighborliness: % -> Cardinal 
      ++ Maximal dimension in which all facets are neighborly.

      balanced: % -> Boolean 
      ++ Dual to NEIGHBORLY.

      balance: % -> Cardinal 
      ++ Maximal dimension in which all facets are balanced.

      fatness: % -> Scalar 
      ++ Parameter describing the shape of the face-lattice of a 4-polytope.

      complexity: % -> Scalar 

      polylib: String := "/usr/local/polymake/bin"

        systemCommand("system " cmd " " polydir rep ".poly " prm)_

        systemCommand("system polymake " polydir (rep::Rep) ".poly "_

        getSetInteger(polytmpfile)$ReadFile pretend Set Cardinal

        polyprop(s, "UNBOUNDED__FACETS") 
        getSetInteger(polytmpfile)$ReadFile pretend Set Cardinal

      nPoints s ==
        polyprop(s, "N__POINTS")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      nInequalities s ==
        polyprop(s, "N__INEQUALITIES")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      vertexBarycenter s ==
        polyprop(s, "VERTEX__BARYCENTER")
        getVectorFraction(polytmpfile)$ReadFile

      minimalVertexAngle s ==
        polyprop(s, "MINIMAL__VERTEX__ANGLE")
        getFraction(polytmpfile)$ReadFile

      zonotopeInputVectors s ==
        polyprop(s, "ZONOTOPE__INPUT__VECTORS")
        getMatrixFraction(polytmpfile)$ReadFile

      reverseTransformation s == 
        polyprop(s, "REVERSE__TRANSFORMATION")
        getMatrixFraction(polytmpfile)$ReadFile

      galeTransform s ==
        polyprop(s, "GALE__TRANSFORM")
        getMatrixFraction(polytmpfile)$ReadFile

      steinerPoints s ==
        polyprop(s, "STEINER__POINTS")
        getMatrixFraction(polytmpfile)$ReadFile

--  Combinatorics
   
      nVertices s ==
        polyprop(s, "N__VERTICES")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      nBoundedVertices s ==
        polyprop(s, "N__BOUNDED__VERTICES")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      nFacets s ==
        polyprop(s, "N__FACETS")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      nVertexFacetInc s ==
        polyprop(s, "N__VERTEX__FACET__INC")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      nEdges s ==
        polyprop(s, "N__EDGES")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      nRidges s ==
        polyprop(s, "N__RIDGES")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      diameter s ==
        polyprop(s, "DIAMETER")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      dualDiameter s ==
        polyprop(s, "DUAL__DIAMETER")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      triangleFree s ==
        polyprop(s, "TRIANGLE__FREE")
        getBoolean(polytmpfile)$ReadFile

      dualTriangleFree s ==
        polyprop(s, "DUAL__TRIANGLE__FREE")
        getBoolean(polytmpfile)$ReadFile

      altshulerDet s ==
        polyprop(s, "ALTSHULER__DET")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      fVector s ==
        polyprop(s, "F__VECTOR")
        getVectorInteger(polytmpfile)$ReadFile pretend Vector Cardinal

      f2Vector s ==
        polyprop(s, "F2__VECTOR")
        getMatrixInteger(polytmpfile)$ReadFile pretend Matrix Cardinal

      flagVector s ==
        polyprop(s, "FLAG__VECTOR")
        getVectorInteger(polytmpfile)$ReadFile pretend Vector Cardinal

      cdIndexCoefficients s ==
        polyprop(s, "CD__INDEX__COEFFICIENTS")
        getVectorInteger(polytmpfile)$ReadFile pretend Vector Cardinal

      hVector s ==
        polyprop(s, "H__VECTOR")
        getVectorInteger(polytmpfile)$ReadFile pretend Vector Cardinal

      cubicalHVector s ==
        polyprop(s, "CUBICAL__H__VECTOR")
        getVectorInteger(polytmpfile)$ReadFile pretend Vector Cardinal

      essentiallyGeneric s ==
        polyprop(s, "ESSENTIALLY__GENERIC")
        getBoolean(polytmpfile)$ReadFile

      simplicial s ==
        polyprop(s, "SIMPLICIAL")
        getBoolean(polytmpfile)$ReadFile

      simple s ==
        polyprop(s, "SIMPLE")
        getBoolean(polytmpfile)$ReadFile

      even s ==
        polyprop(s, "EVEN")
        getBoolean(polytmpfile)$ReadFile

      dualEven s ==
        polyprop(s, "DUAL__EVEN")
        getBoolean(polytmpfile)$ReadFile

      connectivity s ==
        polyprop(s, "CONNECTIVITY")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      dualConnectivity s ==
        polyprop(s, "DUAL__CONNECTIVITY")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      simpliciality s ==
        polyprop(s, "SIMPLICIALITY")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      simplicity s ==
        polyprop(s, "SIMPLICITY")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      faceSimplicity s ==
        polyprop(s, "FACE__SIMPLICITY")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      cubical s ==
        polyprop(s, "CUBICAL")
        getBoolean(polytmpfile)$ReadFile

      cubicality s ==
        polyprop(s, "CUBICALITY")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      cocubical s ==
        polyprop(s, "COCUBICAL")
        getBoolean(polytmpfile)$ReadFile

      cocubicality s ==
        polyprop(s, "COCUBICALITY")
        getInteger(polytmpfile)$ReadFile :: Cardinal

      neighborly s ==
        polyprop(s, "NEIGHBORLY")
[75 more lines...]

\start
Date: Sun, 28 Aug 2005 11:11:57 -0400
From: William Sit
To: Tim Daly
Subject: axiom on Mac OSX

Tim:

With some help from my son, I have finally tried to compile axiom on
my Mac. I got to this far (see below):

I am using gcc 4.0 running under OS 10.4. The problem seems to be that MacOS
10.4 missing some library functions, such as sigaction, read, write, etc and
localtime, the last one finally is more than a warning.

Also, the shell has no command called notdir, used in setting

  SYS=$(notdir $(AXIOM))

which can be patched using

  SYS=MACOSX

I tried the FreeBSD localtime.c, but it does not compile (standalone) with many
compatibility errors.

William

-- Console transcript:

18 making /Users/wyscc/axiom--main--1/src
1 making /Users/wyscc/axiom--main--1/src/scripts
1 making /Users/wyscc/axiom--main--1/src/scripts
17 making /Users/wyscc/axiom--main--1/src/lib
2 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/bsdsignal.o from /
Users/wyscc/axiom--main--1/int/lib/bsdsignal.c
/Users/wyscc/axiom--main--1/int/lib/bsdsignal.c: In function
'bsdSignal':
/Users/wyscc/axiom--main--1/int/lib/bsdsignal.c:68: warning: implicit
declaration of function 'sigaction'
10 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/cursor.o from /
Users/wyscc/axiom--main--1/int/lib/cursor.c
14 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/edin.o from /
Users/wyscc/axiom--main--1/int/lib/edin.c
/Users/wyscc/axiom--main--1/int/lib/edin.c: In function 'do_reading':
/Users/wyscc/axiom--main--1/int/lib/edin.c:161: warning: implicit
declaration of function 'read'
/Users/wyscc/axiom--main--1/int/lib/edin.c:421: warning: implicit
declaration of function 'write'
18 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/fnct_key.o from /
Users/wyscc/axiom--main--1/int/lib/fnct_key.c
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c: In function
'set_editor_key':
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c:86: warning: implicit
declaration of function 'getpid'
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c: In function 'get_key':
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c:196: warning: implicit
declaration of function 'read'
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c: In function
'handle_function_key':
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c:325: warning: implicit
declaration of function 'access'
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c:327: warning: implicit
declaration of function 'write'
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c:329: warning: implicit
declaration of function 'close'
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c:344: warning: implicit
declaration of function 'fork'
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c:349: warning: implicit
declaration of function 'execlp'
/Users/wyscc/axiom--main--1/int/lib/fnct_key.c:349: warning:
incompatible implicit declaration of built-in function 'execlp'
22 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/halloc.o from /
Users/wyscc/axiom--main--1/int/lib/halloc.c
30 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/openpty.o from /
Users/wyscc/axiom--main--1/int/lib/openpty.c
34 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/pixmap.o from /
Users/wyscc/axiom--main--1/int/lib/pixmap.c
38 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/prt.o from /
Users/wyscc/axiom--main--1/int/lib/prt.c
42 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/sockio-c.o from /
Users/wyscc/axiom--main--1/int/lib/sockio-c.c
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c: In function 'sread':
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c:151: warning: implicit
declaration of function 'read'
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c:156: warning: implicit
declaration of function 'close'
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c: In function 'swrite':
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c:184: warning: implicit
declaration of function 'write'
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c: In function
'send_signal':
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c:822: warning: implicit
declaration of function 'kill'
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c: In function
'connect_to_local_server_new':
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c:907: warning: implicit
declaration of function 'sleep'
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c:915: warning: implicit
declaration of function 'getpid'
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c: In function
'close_socket':
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c:1063: warning:
implicit declaration of function 'unlink'
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c: In function
'redirect_stdio':
/Users/wyscc/axiom--main--1/int/lib/sockio-c.c:1253: warning:
implicit declaration of function 'dup2'
46 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/spadcolors.o
from /Users/wyscc/axiom--main--1/int/lib/spadcolors.c
/Users/wyscc/axiom--main--1/int/lib/spadcolors.c: In function
'HSVtoRGB':
/Users/wyscc/axiom--main--1/int/lib/spadcolors.c:73: warning: 'rgb$b'
may be used uninitialized in this function
/Users/wyscc/axiom--main--1/int/lib/spadcolors.c:73: warning: 'rgb$g'
may be used uninitialized in this function
/Users/wyscc/axiom--main--1/int/lib/spadcolors.c:73: warning: 'rgb$r'
may be used uninitialized in this function
/Users/wyscc/axiom--main--1/int/lib/spadcolors.c: In function
'AllocCells':
/Users/wyscc/axiom--main--1/int/lib/spadcolors.c:573: warning: 'xcolor
$pixel' is used uninitialized in this function
50 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/util.o from /
Users/wyscc/axiom--main--1/int/lib/util.c
/Users/wyscc/axiom--main--1/int/lib/util.c: In function 'checker':
/Users/wyscc/axiom--main--1/int/lib/util.c:63: warning: implicit
declaration of function 'getpid'
54 making /Users/wyscc/axiom--main--1/obj/MACOSX/lib/wct.o from /
Users/wyscc/axiom--main--1/int/lib/wct.c
/Users/wyscc/axiom--main--1/int/lib/wct.c: In function 'printTime':
/Users/wyscc/axiom--main--1/int/lib/wct.c:299: warning: implicit
declaration of function 'localtime'
/Users/wyscc/axiom--main--1/int/lib/wct.c:299: warning: assignment
makes pointer from integer without a cast
/Users/wyscc/axiom--main--1/int/lib/wct.c:301: error: dereferencing
pointer to incomplete type
/Users/wyscc/axiom--main--1/int/lib/wct.c:301: error: dereferencing
pointer to incomplete type
/Users/wyscc/axiom--main--1/int/lib/wct.c:301: error: dereferencing
pointer to incomplete type
/Users/wyscc/axiom--main--1/int/lib/wct.c:302: error: dereferencing
pointer to incomplete type
/Users/wyscc/axiom--main--1/int/lib/wct.c:302: error: dereferencing
pointer to incomplete type
/Users/wyscc/axiom--main--1/int/lib/wct.c:302: error: dereferencing
pointer to incomplete type
/Users/wyscc/axiom--main--1/int/lib/wct.c: In function 'reread1Wct':
/Users/wyscc/axiom--main--1/int/lib/wct.c:385: warning: implicit
declaration of function 'read'
make[3]: *** [/Users/wyscc/axiom--main--1/obj/MACOSX/lib/wct.o] Error 1
make[2]: *** [libdir] Error 2
make[1]: *** [srcsetup] Error 2
make: *** [all] Error 2

\start
Date: Sun, 28 Aug 2005 18:22:26 +0200
From: Kai Kaminski
To: William Sit
Subject: Re: axiom on Mac OSX

Hi William,

since I'm using OS X myself I'd be much interested in an OS X
port. I've tried to compile Axiom on Panther a few weeks ago and it
didn't work either. Just like you I had (different) problems
concerning C library functions or header files. I've studied some of
the C code in some detail and I have the impression that almost all C
code is for the HyperDoc, Graphics or the management processes (axiom,
session manager etc). There seem to be only very few places
(sockio.lisp, cfuns.lisp, unlisp.lisp, hash.lisp) where AXIOMsys uses
C code. When I last looked at this code it didn't seem to have much
potential for compilation problems. Besides most of it could be
replaced by dummy functions (for example in
sockio.lisp.pamphlet). Compiling AXIOMsys would already allow using
most of Axiom's functionality (everything but HyperDoc and Graphics
pretty much) as well as the Emacs and Texmacs interfaces.

\start
Date: Sun, 28 Aug 2005 15:50:22 -0400
From: Tim Daly
To: William Sit
Subject: Re: axiom on Mac OSX

William,

Actually there is a MACOSX stanza in the Makefile.pamphlet file
which should be extracted by just setting your AXIOM shell variable to:

AXIOM=/Users/wyscc/mnt/MACOSX

The Mac port is only partially done. I don't have a mac so it makes it
hard to do the port. I'm working on the FreeBSD version which should
already work but I'm unable to get it running yet. It appears that I
don't have all of the tools properly installed and I'm struggling with
figuring out how to get the tool chain working. 

There is no such thing as a simple job.

\start
Date: Sun, 28 Aug 2005 16:20:19 -0400
From: William Sit
To: Kai Kaminski
Subject: Re: axiom on Mac OSX

Kai Kaminski wrote:
> Besides most of it could be
> replaced by dummy functions (for example in
> sockio.lisp.pamphlet). 

I tried to "import" localtime() from FreeBSD library: wrap it in a pamphlet
file, modify the src/lib/Makefile.pamphlet to include this and do a make clean
at top level. However, the Makefile in src/lib created this error:

17 making /users/wyscc/axiom--main--1/src/lib
Makefile 12: *** commands commence before first target. Stop.
make[2]: *** [libdir] Error 2
make[1]: *** [srcsetup] Error 2
make: *** [all] Error 2

I find modifying src/lib/Makefile.pamphlet (adding localtime.c.pamphlet) very
tedious -- I even put all the files in alphabetical order, resequence the echo
numbers, etc (see attached). Don't know why it didn't work. Perhaps Tim has some
tools to insert and delete c.pamphlet files without doing so manually, which is
error prone.

Tim wrote:
> Actually there is a MACOSX stanza in the Makefile.pamphlet file
> which should be extracted by just setting your AXIOM shell variable to:
> 
> AXIOM=/Users/wyscc/mnt/MACOSX

I already did that, and I also tried the FreeBSD version. I am also working with
the newest download (September 2005), but it makes no difference even if I use
the April 2005 version.

Can someone point out how to "dummy" out these, I believe non-existing under
MacOSX, files to force the compile to continue? or replacement files? (for a
start, some version of localtime.c that wct.c would like.  MACOSX must have some
equivalent time functions.

\start
Date: Sun, 28 Aug 2005 16:58:16 -0400
From: William Sit
To: Tim Daly
Subject: Re: axiom on Mac OSX (attachment)

Sorry, I deleted it already! Please ignore.

\start
Date: Sun, 28 Aug 2005 17:48:47 -0500
From: MathAction (Jens Axel Segaard)
To: MathAction
Subject: [Axiom-mail] Lexicographic order

Hi all,

Is there a smarter way than the following to write lexorder?(p,q) ?

lexorder?(p,q) ==
   if empty?(variables(p))
   then return ~empty(variables(q))
   else
     vars := members(difference( set(variables( secret1*p + secret2*q)),
                                 set([secret1, secret2])))
     a := members(degree( p::DMP(vars,?) ))
     b := members(degree( q::DMP(vars,?) ))
     return negative?( first(a) - first(b) )


My first attempt used:

   vars := sort(members(union(set(variables(p), variables(q)))))

but was surprised to see

  > sort([x,y,z])
  [z,y,x]

  > sort([x,z,y])
  [y,z,x]

and thus made up the secret-trick in order to avoid sort.

\start
Date: Mon, 29 Aug 2005 00:15:41 -0400
From: Bill Page
To: Martin Rubey
Subject: begin{axiom},	begin{spad} and begin{aldor} (was: new version of polymake.spad)

On August 27, 2005 3:38 PM Martin Rubey wrote:
> 
> I suppose you hate seeing my email address by now...
> 

Not at all! I am still very enthusiastic to try to help anyone
who is willing to share their expertise with other Axiom users
and developers. I think you are setting an excellent example to
others. Thank you for all your contributions.

> Anyway: I had problems uploading my most recent version of the
> polymake wrapper. MathAction keeps responding with Site Error...
> 

I am sorry that it took me a little longer to find the source of
this problem. In this case it had nothing specifically to do with
your polymake code. Instead it turned out that the Site Error is
directly related to a recent email to axiom-developer.

In a recent thread with subject "steps towards better TeXmacs
interface" Andrey G. Grozin addressed the issue that the output
of Axiom is not well suited for processing as input to another
program such as TeXmacs. This is also a problem on the MathAction
website which must capture Axiom output and prepare it for
display on a web page.

The problem in this case is that the output of the SPAD compiler
is very verbose and quite messy. This output was causing the
MathAction parsing routines (based on some moderately complex
python regular expressions) to blow-up and abort the conversion
process.

In fact, I knew that this problem also occurred on some other
pages on MathAction. The most significant example was your code
for the 'Guess' routines. If saved as page type StructuredText+
LaTeX in order to trigger the Axiom SPAD compiler, that also
caused the Site Error and so previously it had to be saved as a
PlainText format page. The Site Error did not prevent the SPAD
compiler from running and compiling the code but it was impossible
to save the page unless the page type was changed to PlainText
because the Site Error aborts just prior to the save process.

The solution was also similar to that mentioned in the message by
Andrey: I had to insert additional markers in the Axiom output.
I did this using the following Axiom commands:

  )sys echo <SPAD>
  )sys cat code.spad
  )sys echo </SPAD>
  )co code.spad
    SPAD compiler output

to more simply delimit the SPAD code from the associated compiler
output. This allowed me to avoid the more complex output parsing.

The other thing that happened recently was that I upgraded the
version of Axiom on MathAction to Patch-44 plus Peter Broadbery's
patches to support Aldor. So now it is possible to write both
SPAD and Aldor library routines on MathAction. To distinguish
between SPAD and Aldor I introduced the follow two new
environments:

\begin{aldor}
  Aldor library code here
\end{aldor}

and

\begin{spad}
  SPAD library code here
\end{spad}

The older \begin{axiom} ... environment still exists and is
intended to be used only for Axiom interpreter commands. For the
time being the deprecated form:

\begin{axiom}
)abbrev ...
  SPAD library code here
\end{axiom}

still works but after everything that uses this form is converted
to form, this will be eliminated.

Only the new environment \begin{spad} ... produces the new
syntactic markers that permits SPAD compiler output to be handled
reliably. So this should be used for all new library code on
MathAction.

> I attach it, maybe you are luckier than me, probably more 
> knowledgeable in any case...
> 

In your polymake page I have changed the delimiters to:

\begin{spad}
...
\end{spad}

and inserted your new code.

> 
> )abbrev domain POLYTOPE Polytope
> Polytope(): Exports == Implementation where
> ...

Now the page compiles and renders properly on MathAction.
I also did the same on you page named 'Guess' and now it
also is compiled and saved properly.

Let me know if you have any questions about this.

\start
Date: Mon, 29 Aug 2005 08:50:42 +0100
From: Mark Murray
To: Tim Daly
Subject: re: axiom on Mac OSX 

root writes:
>The Mac port is only partially done. I don't have a mac so it makes it
>hard to do the port. I'm working on the FreeBSD version which should
>already work but I'm unable to get it running yet. It appears that I
>don't have all of the tools properly installed and I'm struggling with
>figuring out how to get the tool chain working. 

How can I help? I've done this a few times before! :-)

\start
Date: Mon, 29 Aug 2005 09:52:46 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: begin{axiom}, begin{spad} and begin{aldor} (was: new version of polymake.spad)

No questions but three comments:

* introducing the new "spad" environment is very sensible -- also from a
  philosophical point of view.

* introducing the new "aldor" environment is superb. Ralf will like this one,
  too!

* thanks for your prompt actions! it's really nice to work together with such
  responsive people!

\start
Date: Mon, 29 Aug 2005 04:31:46 -0500
From: MathAction (Martin Rubey)
To: MathAction
Subject: [Axiom-mail] Lexicographic order

Dear Jens,

Although I'm not 100% sure what lexorder? ought to do exactly, you might want
to notice the following:

the first matching type the interpreter finds for [x,y,z] is 

(13) -> [x,y,z]

   (13)  [x,y,z]
                                       Type: List OrderedVariableList [x,y,z]

which means that in sort([x,z,y]) you are using the order imposed by
OrderedVariableList [x,y,z], which is z < y < x.

So, although 

 >   > sort([x,y,z])
 >   [z,y,x]
 > 
 >   > sort([x,z,y])
 >   [y,z,x]

is surprising, it shouldn't be ;-) (<- please note the smiley !)

If you say

sort([x,z,y]::List Symbol), you will get the expected output.

I'm not totally sure how you can find out what ordering a domain uses. But very
likely, if its name doesn't contain something like "Ordered", it is the usual
lexicographic order.

Hope this helps,

Martin

Jens Axel Seaard writes:
 > Hi all,
 > 
 > Is there a smarter way than the following to write lexorder?(p,q) ?
 > 
 > lexorder?(p,q) ==
 >    if empty?(variables(p))
 >    then return ~empty(variables(q))
 >    else
 >      vars := members(difference( set(variables( secret1*p + secret2*q)),
 >                                  set([secret1, secret2])))
 >      a := members(degree( p::DMP(vars,?) ))
 >      b := members(degree( q::DMP(vars,?) ))
 >      return negative?( first(a) - first(b) )
 > 
 > 
 > My first attempt used:
 > 
 >    vars := sort(members(union(set(variables(p), variables(q)))))
 > 
 > but was surprised to see
 > 
 >   > sort([x,y,z])
 >   [z,y,x]
 > 
 >   > sort([x,z,y])
 >   [y,z,x]
 > 
 > and thus made up the secret-trick in order to avoid sort.

\start
Date: Mon, 29 Aug 2005 07:03:56 -0400
From: Tim Daly
To: Mark Murray
Subject: re: axiom on Mac OSX

Martin,

I'm somewhat confused about the FreeBSD environment. 

The first issue is that FreeBSD outputs a 30 second LOUD beep before
it boots which I have not found a way to turn off. Does this happen
to you? How can I turn it off?

The second issue is that despite the fact that I asked for emacs to
be installed (I installed several times) I cannot find it anywhere.
How can I install emacs after the fact? 

Third, where can I find GNU make? Originally I had written the Makefiles
so they did not care which make was used but changes have been made which
require gnu make. I thought I asked for it to be installed but can't find
it. I also asked for the Linux-compat environment to be installed but 
that seems lost also. 

My only guess is that there is a disk volume somewhere that contains
all these packages but isn't getting mounted. 

All of my pure unix experience predates any package-handling mechanisms.

Where is a good FAQ location so I can get educated? I picked up a FreeBSD
book but it isn't really a user's guide.

In theory, given the work you've already done I should just have to compile
Axiom, make a few final tweaks to the Makefile, test the lot and we're
good to go. Unfortunately I'm still struggling with the mundane.

There is no such thing as a simple job.

\start
Date: Mon, 29 Aug 2005 12:47:44 +0100
From: Mark Murray
To: Tim Daly
Subject: re: axiom on Mac OSX 

root writes:
>Martin,

That would be "Mark" :-)

>I'm somewhat confused about the FreeBSD environment.

Ok...

>The first issue is that FreeBSD outputs a 30 second LOUD beep before
>it boots which I have not found a way to turn off. Does this happen to
>you? How can I turn it off?

Hmm. Sounds like something with the hardware. Check your BIOS settings
make sure your keyboard and VGA settings are OK. FreeBSD itself doesn't
beep at you during the boot.

If you let me know at which part of the boot process this happens, I can
try to hunt it down further.

>The second issue is that despite the fact that I asked for emacs to be
>installed (I installed several times) I cannot find it anywhere.  How
>can I install emacs after the fact?

All the third-party/optional software is installed in /usr/local
and /usr/X11R6, so make sure you have /usr/local/[s]bin and
/usr/X11R6/[sb]in in your path.

Also check out "man 7 hier" to see how the system is layed out.

>Third, where can I find GNU make? Originally I had written the
>Makefiles so they did not care which make was used but changes
>have been made which require gnu make. I thought I asked for it to
>be installed but can't find it. I also asked for the Linux-compat
>environment to be installed but that seems lost also.

Gnu make would be "gmake" in /usr/local/bin

>My only guess is that there is a disk volume somewhere that contains
>all these packages but isn't getting mounted.

Nope :-). just a path problem.

>All of my pure unix experience predates any package-handling
>mechanisms.

Yeah. In the good old days, we all had to DIY this sort of stuff. ;-)

>Where is a good FAQ location so I can get educated? I picked up a
>FreeBSD book but it isn't really a user's guide.

Sure - http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/index.html

>In theory, given the work you've already done I should just have to
>compile Axiom, make a few final tweaks to the Makefile, test the lot
>and we're good to go. Unfortunately I'm still struggling with the
>mundane.

Steep curve at the beginning, but once you've sorted out the (not very
many) niggles, you'll find that *BSD is a very clean system (I hope!).

>There is no such thing as a simple job.

Ain't that the truth!

\start
Date: Mon, 29 Aug 2005 08:19:20 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#115 color highlighting of Axiom compiler output] compiler output is folded

In addition to being shaded lightgrey, the compiler output is now
also "folded", i.e. the output is collapsed to a single header line.
You will notice a + sign in from the word 'axiom' on the right hand
side of the header. Clicking the + will display the compiler output.
The '+ axiom' turns to '- axiom'. If you click the - then the
compiler output will be hidden.

Note also the +/- menu items at the top of the page. Clicking + will
expand all folded output. Clicking - will hide it all.

\start
Date: Mon, 29 Aug 2005 08:45:04 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#201 New issue categories for Aldor] (new) 

I have added two new categories to support Aldor:

- Aldor Library Compiler

  Report problems with using Aldor as a library compiler for Axiom

- Aldor Standalone Compiler

  Report problems with using Aldor as a stand alone compiler
  independent of Axiom

Note: "Aldor:http://www.aldor.org is not open source but access to source
code is by request. Contact: Laurentiu Dragan ldragan@scl.csd.uwo.ca
or Cosmin Oancea coancea@scl.csd.uwo.ca

\start
Date: Mon, 29 Aug 2005 18:50:01 +0200
From: Jens Axel Segaard
To: list
Subject: Bug report

I belive the following session must be due to a bug in the compiler:

(1) -> firstNegative(l) == first(remove( x +-> x>=0, l))
                                                             Type: Void
(2) -> firstNegative([1,2,0,-3,4])
    Compiling function firstNegative with type List Integer -> Integer

Segmentation fault


The same happens in Windows.

\start
Date: Mon, 29 Aug 2005 12:50:32 -0500
From: MathAction (Jens Axel Segaard)
To: MathAction
Subject: [Axiom-mail] Lexicographic order

Hi Martin,

 > Although I'm not 100% sure what lexorder? ought to do exactly, you
 > might want to notice the following:
 >
 > the first matching type the interpreter finds for [x,y,z] is
 >
 > (13) -> [x,y,z]
 >
 >    (13)  [x,y,z]
 >                                        Type: List OrderedVariableList 
[x,y,z]
 >
 > which means that in sort([x,z,y]) you are using the order imposed by
 > OrderedVariableList [x,y,z], which is z < y < x.

Ah!

 > If you say
 >
 > sort([x,z,y]::List Symbol), you will get the expected output.

That worked.

 > I'm not totally sure how you can find out what ordering a domain uses.
 > But very likely, if its name doesn't contain something like "Ordered",
 > it is the usual lexicographic order.

Part of my problem was that I had to polynomials, which might be belong
to polynomial rings over different variables. I am probably not going
to use lexorder?, I am just trying to get used to the Axiom way of
doing things. Fortunately it feels very Lispy to me (if it weren't for 
the fact that tail recursion wasn't supported, I'd had said Schemy).

Lexorder examines the difference of exponent vectors of the multivariate
polynomials p and q. If the leftmost non-zero entry is positive, then p>q.

lexorder?(p,q) ==
   if  empty?(variables(p))
   then return ~empty?(variables(q))
   else
     vars := sort(members(union(set(variables(p)),
                                set(variables(q))))::List Symbol)
     a := vector(members(degree( p::DMP(vars,?) )))
     b := vector(members(degree( q::DMP(vars,?) )))
     n := select( x +-> ~zero?(x), members(a-b))
     if empty?(n)
     then return false
     else return positive?(first(n))

\start
Date: Mon, 29 Aug 2005 13:05:22 -0500
From: MathAction (William Sit)
To: MathAction
Subject:  Lexicographic order


> Part of my problem was that I had to polynomials, which might be belong
> to polynomial rings over different variables. I am probably not going
> to use lexorder?, 
> 
For multivariate polynomial domains:

DMP  uses lexicographic order of variables
HDMP uses degree reverse lex
GDMP uses any order function you provide
SMP  uses order of the variable set (unmixed)
POLY same as SMP using order in Symbol

All are built-in. Please check Axiom book or hyperdoc for details.

\start
Date: Mon, 29 Aug 2005 13:41:04 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#196 )set functions compile on] Still another	manifestation of )se fu co on

On Mon, 2005-08-29 at 18:50 +0200, Jens Axel Seaard wrote:
I belive the following session must be due to a bug in the compiler:
> 
> (1) -> firstNegative(l) == first(remove( x +-> x>=0, l))
>                                                              Type: Void
> (2) -> firstNegative([1,2,0,-3,4])
>     Compiling function firstNegative with type List Integer -> Integer
> 
> Segmentation fault
> 
> 
> The same happens in Windows.
> 

\start
Date: Mon, 29 Aug 2005 13:43:41 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#196 )set functions compile on] 

I belive the following session must be due to a bug in the compiler::
 
 (1) -> firstNegative(l) == first(remove( x +-> x>=0, l))
                                                              Type: Void
 (2) -> firstNegative([1,2,0,-3,4])
     Compiling function firstNegative with type List Integer -> Integer
 
 Segmentation fault
 
The same happens in Windows.

\start
Date: Mon, 29 Aug 2005 14:35:54 -0400
From: Bill Page
To: Jens Axel Segaard
Subject: Re: Bug report

Jens,

This is another example of the known problem with the current
open source version of Axiom. A work-a-round is to use the
commend:

)set functions compile on

before using anonymous functions like:  x +-> x>=0

See the issue report at:

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

[wspage@localhost axiom--main--1]$ AXIOMsys
                        AXIOM Computer Algebra System
                       Version: Axiom 3.6 (June 2005)
                Timestamp: Monday July 18, 2005 at 13:13:36
-----------------------------------------------------------------------------
   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
(1) -> )se fu co on
(1) -> firstNegative(l) == first(remove( x +-> x>=0, l))
                                              Type: Void
(2) -> firstNegative([1,2,0,-3,4])
   Compiling function firstNegative with type List Integer -> Integer

   (2)  - 3
                                              Type: Integer
(3) ->

------

Regards,
Bill Page.

On Mon, 2005-08-29 at 18:50 +0200, Jens Axel Seaard wrote:
> I belive the following session must be due to a bug in the compiler:
> 
> (1) -> firstNegative(l) == first(remove( x +-> x>=0, l))
>                                                              Type: Void
> (2) -> firstNegative([1,2,0,-3,4])
>     Compiling function firstNegative with type List Integer -> Integer
> 
> Segmentation fault
> 
> 
> The same happens in Windows.
> 

\start
Date: Mon, 29 Aug 2005 14:10:56 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AldorForAxiom] 

1. Make sure you have the most up to date version of gnu make::

     make --version
     GNU Make 3.80

5. Update your Axiom source code to Patch-44 (or greater)::

\start
Date: Mon, 29 Aug 2005 14:20:14 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AldorForAxiom] 

   3. make

      make stops with an error message. The next two step corrects the problem.

   4. touch ../../int/aldor/dep_spad.stamp

   5. document Make.functions.pamphlet

   6. make 2>&1 | tee aldor.log

\start
Date: Mon, 29 Aug 2005 14:52:20 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AldorForAxiom] 

     $ make --version

2. Install the Java development kit JDK:

   It may be necessary to adjust symbolic links or the PATH to point
   to the correct version of java::

     $ ls -l `which java`
     lrwxrwxrwx  1 root root 30 Jun  3 22:00 /usr/bin/java -> /usr/java/jre1.5.0_03/bin/java
     $ javac -version
     $ javac 1.5.0_03


     $ cd axiom--main--1
     $ tla update

     $ patch -p 1 < ~/aldor.diff

     $ ./configure

     $ make

     $ cd src
     $ tar xzvf ~/src_aldor2.tgz

9. Build the Aldor interface

   Issue the following commands::

     $ cd aldor
     $ document Makefile.pamphlet
     $ make

   make stops with an error message. The next two steps correct the problem::

     $ touch ../../int/aldor/dep_spad.stamp
     $ document Make.functions.pamphlet

   Now complete build of the Aldor interface::

     $ make 2>&1 | tee aldor.log

\start
Date: Mon, 29 Aug 2005 17:17:34 -0500
From: MathAction (root)
To: MathAction
Subject:  Lexicographic order

Actually, tail recursion is supported automatically.

\start
Date: Mon, 29 Aug 2005 20:36:24 -0500
From: MathAction (daly)
To: MathAction
Subject: [AldorForAxiom] 

   If not, then upgrade your version of "make":http://savannah.gnu.org/projects/make or linux first.

\start
Date: Mon, 29 Aug 2005 21:52:14 -0400
From: Tim Daly
To: Bill Page, Peter Broadbery
Subject: aldor for axiom

Bill, Peter,

As a practical matter we can't expect axiom users to upgrade both make
and java just to build Axiom. I'm following the directions you put on
the AldorForAxiom page just to verify that I understand the process.

I need to rebuild the machinery so it works with any version of make
and doesn't require java. It's been a standing goal (so far achieved)
that you can build axiom on a reasonable linux distro by just typing
'make'. Virtually all of the distros I have distribute pre 3.8 makes
it seems.

And since it seems we can't distribute the aldor binaries with Axiom
the whole aldor install is going to require the user to fetch aldor
(probably into the zips directory) and then 
  make aldor

\start
Date: Mon, 29 Aug 2005 20:38:43 -0500
From: MathAction (daly)
To: MathAction
Subject: [AldorForAxiom] 

1. Make sure you have the most up to date version of gnu "make":http://savannah.gnu.org/projects/make ::

   If not, then upgrade your version of make or linux first.

\start
Date: Mon, 29 Aug 2005 21:53:40 -0400
From: Tim Daly
To: Bill Page, Peter Broadbery
Subject: aldor for axiom

Bill, Peter,

Also, I have javac 1.5.0_04. Can I assume you don't actually REQUIRE
javac 1.5.0_03?

\start
Date: Mon, 29 Aug 2005 22:16:22 -0400
From: Tim Daly
To: Bill Page, Peter Broadbery
Subject: patches

Peter,

I don't see any obvious reason why your patches can't be permanently
applied to the axiom sources. Did I miss something that would break
if aldor is not around?

\start
Date: Mon, 29 Aug 2005 22:21:30 -0400
From: Bill Page
To: Tim Daly, Peter Broadbery
Subject: RE: [Aldor-l] aldor for axiom

Tim wrote:

> 
> As a practical matter we can't expect axiom users to upgrade
> both make and java just to build Axiom. I'm following the
> directions you put on the AldorForAxiom page just to verify
> that I understand the process.

Great.

> 
> I need to rebuild the machinery so it works with any version of
> make and doesn't require java. It's been a standing goal (so far
> achieved) that you can build axiom on a reasonable linux distro by
> just typing 'make'. Virtually all of the distros I have distribute
> pre 3.8 makes it seems.

make 3.8 was released in 2002. I wonder why 3.79.x is still so
common?

Upgrading to make 3.8 seems to be as simple as download, configure,
make ...

Since Peter claims his java code is "simple" perhaps it is possible to
use GNU java (gcj). That is easily available on most linux distros.

Another possibility would be to use Peter's java program to create
a static list of dependencies which we can then just include in
the axiom build files.

> 
> And since it seems we can't distribute the aldor binaries with Axiom
> the whole aldor install is going to require the user to fetch aldor
> (probably into the zips directory) and then 
>   make aldor
> 

That makes sense.

\start
Date: Mon, 29 Aug 2005 22:11:47 -0400
From: Bill Page
To: Tim Daly, Peter Broadbery
Subject: RE: aldor for axiom

> Also, I have javac 1.5.0_04. Can I assume you don't actually REQUIRE
> javac 1.5.0_03?

Yes. In fact I am not 100% sure that it is Sun's JDK 1.5.x that is
required but I have verified that it works. Peter never said exactly
what java compiler he is using.

It would be nice if one could use the GNU gcj compiler. But my first
attempt to do that failed so I assumed he was talking about Sun's java.

\start
Date: Mon, 29 Aug 2005 22:12:34 -0500
From: MathAction (daly)
To: MathAction
Subject: [AldorForAxiom] 

   "src_aldor2.tgz":src_aldor2.tgz (despite the name this file is not compressed, only tarred)

\start
Date: Mon, 29 Aug 2005 22:46:14 -0500
From: MathAction (daly)
To: MathAction
Subject: [AldorForAxiom] 

   "src_aldor2.tgz":src_aldor2.tgz 

\start
Date: Tue, 30 Aug 2005 10:44:51 +0200
From: Jens Axel Segaard
To: list
Subject: Re:  Lexicographic order

root wrote:

> Actually, tail recursion is supported automatically.

I tried the following and ran out of stack space:

loop : INT -> INT

loop (n) == loop (n)

loop (1)

   >> System error:
   Invocation history stack overflow.


Is there a way to turn off the invocation history?

\start
Date: Tue, 30 Aug 2005 11:23:16 +0200
From: Martin Rubey
To: Jens Axel Segaard
Subject: re:  Lexicographic

 > I tried the following and ran out of stack space:
 > 
 > loop : INT -> INT
 > 
 > loop (n) == loop (n)
 > 
 > loop (1)
 > 
 >    >> System error:
 >    Invocation history stack overflow.

Although this is not a nice way for Axiom to fail, two questions:

* is this an instance of tail-recursion?

* what result would you expect?

\start
Date: Tue, 30 Aug 2005 21:44:29 +0200
From: Jens Axel Segaard
To: Martin Rubey
Subject: re:  Lexicographic order

Martin Rubey wrote:
>  > I tried the following and ran out of stack space:
>  >
>  > loop : INT -> INT
>  >
>  > loop (n) == loop (n)
>  >
>  > loop (1)
>  >
>  >    >> System error:
>  >    Invocation history stack overflow.
>
> Although this is not a nice way for Axiom to fail, two questions:
>
> * is this an instance of tail-recursion?
>
> * what result would you expect?

Hi Martin,

Yes - if tail recursion were supported, then the above would be
an infinite loop. I haven't got any complaints over the wording
of the error message.


If tail recursion is supported, the above will result in an infinite
loop.

A loose definition of a tail call is: If in the body of f, a call
to g is made in a position, where the result of the call, is to
be returned by f, then the call to g is a /tail call/.

In

  summa(n) ==
    if n=0
    then 0
    else n + summa(n-1)

 > summa(10)
55

the call to summa is not a tail cail, since the result of calling
summa(n-1) needs to be added to n before a value can be returned.

On the other hand in:

  -- a stands for accumulator
  summa2(n, a) ==
    if n=0
    then a
    else summa2(n-1, n+a)

 > summa(10,0)
55

the result of calling summa2(n-1,n+a) is returned immediately
as the result of summa2(n,a) and is thus a tail call.


A call is /active/ if the function called hasn't returned yet.

Proper[1] tail recursion is supported, if an unbounded number
of active tail calls only use a bounded amount of stack space.

In Scheme a call summa(10000) would cause a stack overflow, just
as in Axiom, but a call summa2(10000,0) would work withput any
problems. However, in some Scheme implementations one can
turn the stack history on and off - so perhaps there is
magic switch somewhere?

See
<http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-6.html#%_=
sec_3.5>
for a more formal definition.

[1] Here "Proper Tail Recursion" is a technical term, and doesn't
     mean "tail recursion done right".

--
Jens Axel Segaard

\start
Date: Tue, 30 Aug 2005 17:06:38 -0400
From: Bill Page
To: Andrey G. Grozin
Subject: steps towards a Maxima interface in MathAction (was: steps towards better TeXmacs interface)
Cc: Bill Page

On Friday, August 26, 2005 12:33 PM Andrey G. Grozin wrote:
> ...
> Another free computer algebra system, maxima, has incorporated
> inserting of parametrized markers in the key positions of its
> output some time ago. Now it is easy to interface it to almost
> any external program: one just assigns appropriate values to the
> marker strings, and then maxima speaks the protocol required by
> this external program. Maxima developers called this "the transition
> from the stone age to the bronze age" (the idea is that using corba
> or some such thing would be the enlightment era).
>

For some time now I have been wanting to implement an interface
to Maxima in MathAction. I am not a Maxima user, although I have
installed it and played with it a little. I was hoping that someone
with more Maxima experience would come forward and offer to help
me to do this ... :)

Where would be the best place to look for a definition of these
parameterized markers in Maxima? What would you suggest as a
simple example of a program that parses Maxima output using these
markers?

The problem of interfacing with MathAction is not exactly the same
as in the case of TeXmacs. TeXmacs which starts a parallel external
session. It then sends commands, receives and formats output in a
synchronous manner while the user edits the document. In the case
of MathAction, the entire web page is edited in "text-mode" and is
only processed by an external program (such Axiom) once when the user
clicks 'Save' or 'Preview'. Since a web page consists of multiple
sections of alternating formatted text, LaTeX commands, and commands
to external programs, these sections must be collected in some
manner and then sent to the external program. The output of the
program must be parsed and separated into output sections that
correspond one-for-one with the specific input sections. Then during
the rendering of the page as HTML, MathAction replaces each of the
input sections with selected and possibly reformatted parts of the
output (e.g. LaTeX generated by Axiom).

In the case of both Axiom and Reduce I solved this problem by
constructing a .input file for each section and then running Axiom
(or Reduce) with a script that executes each .input file by a
series of )read commands. The output corresponding to each )read
command is automatically delimited by the Axiom (Reduce) prompt
sequence. So separating the output into sections is quite straight
forward. (But of course would be even easier if Axiom was specifically
designed to delimit the output in the way that Andrey suggests.)

The problem that I have with Maxima right now is that I do not
know how to run Maxima in this manner, i.e. in a "batch mode"
to process a series of input sections and then parse the output
into a series of corresponding output sections.
 
> Axiom is still in the stone age in this respect (a more structured
> and predictable input-output). I am now trying to move it to the
> bronze age. The first (and rather obvious) place is interp/i-
> util.boot.pamphlet I renamed the procedure MKPROMPT to MKPROMPT0,
> and inserted
>
> $InterfaceStrings : Record(PromptPrefix:String,PromptSuffix:String)
>  := ['"[",'"]"]
>
> MKPROMPT() ==
>
> STRCONC($InterfaceStrings.PromptPrefix,MKPROMPT0(),
>  $InterfaceStrings.PromptSuffix)
>
> This works, and my prompts are now in brackets (of course, this is
> just a test). The next step is to find all the other prompt-like
> things in axiom (i.e., output strings immediately preceeding user
> input). One of them is the exit confirmation, for example; I'm sure
> there are many others. Each prompt-like string should now be preceeded
> by $InterfaceStrings.PromptPrefix and followed by
> $InterfaceStrings.PromptSuffix . And this is only the first step,
> there will be, e.g., $InterfaceStrings.LatexPrefix and
> $InterfaceStrings.LatexSuffix and some other markers.
>

>From my experience with MathAction I know that it is important to be
able to efficiently and reliably parse the Axiom output to identify
and separate the LaTeX output $$ ... $$ from non-LaTeX output like
error messages and other informative messages, and also to identify
the Type: ... information. Axiom's current output format is just
barely able to support this. New $InterfaceStrings to support this
parsing would be very welcome!

> So, I have a few questions to the gurus:
>
> 1. What is the correct file to put the definition and initialization
>  of $InterfaceStrings ?
>
> 2. Is there some way in which this initialisation could be made
>  dependent on external conditions? For example, can I pass a
>  command-line argument to AXIOMsys, and check it in boot code? Or
>  check an environment variable in the boot code? At the moment,
>  I know only one way to pass some information to axiom:
> .axiom.input. But it would not be a good idea for TeXmacs, for
> example, to overwrite the user's .axiom.input (if the user has one).
>

My preference would be to pass InterfaceStrings via one or more
environment variables. Reading environment variables in boot code
amounts simply to calling the corresponding lisp system function.


> ...
> TeXmacs has some strange requirements of its own (e.g., using \* for
> multiplication).

This is not a "strange requirement" since one of the goals of TeXmacs
is to retain more of the mathematical semantics then what "normal"
LaTeX allows. This is the same goal that the developers of OpenMath
had in mind.

> Therefore, I want to leave the old TeX generation alone, and to
> introduce the new kind of output: texmacs. So that it will be
> possible to say
> )set output texmacs on

I think that this is an excellent idea. A couple of years ago
When Tim Daly and I first discussed this, Tim provided some
notes on how the )set output commands were processed in Axiom.
If you are interested, I think I could probably find them in
the axiom-developer email archives.

> OK, I can easily duplicate tex.spad.pamphlet (should this be a
> new file, texmacs.spad.pamphlet, or I just double the contents of
> tex.spad.pamphlet ?)

I think a new file is better unless you find that there is a
large overlap in the source code, i.e. same set of helper
routines etc.

> I'll rename the domain TexFormat to TexmacsFormat, and make
> the improvements I want. But what to do next?

Since this is going to be specific to TeXmacs anyway, have
you considered using TeXmacs' scheme format instead of LaTeX?
This way you can avoid the complications of the TeXmacs LaTeX
conversion.

> My (very incomplete...) understanding is that I should insert the
> necessary pieces into setvars.boot.pamphlet and setvart.boot.pamphlet
> (based on the TeX pieces, with renamings and some small changes).

Tim described some of this in his emails of two years ago on
axiom-developer.

> But setvars.boot.pamphlet says that if I change the boot code (and
> I'm going to do this), I have to translate it to lisp and insert it
> into the same file. How do I do this, exactly?

Specifically in setvars.boot.pamphlet it says:

This file contains both the {\bf boot} code and the {\bf Lisp}
code that is the result of the {\bf boot to lisp} translation.
We need to keep the translated code around so we can bootstrap
the system. In other words, we need this boot code translated
so we can build the boot translator.

{\bf NOTE WELL: IF YOU CHANGE THIS BOOT CODE YOU MUST
TRANSLATE THIS CODE TO LISP AND STORE THE RESULTING LISP
CODE BACK INTO THIS FILE.}

-------

Boot is a compiler. I presume that that lisp code that you need
to insert into this file can be generated just by compiling the
new boot code (the way it is done now in the part of the Axiom
Makefile that builds INTERPSYS. You should be able to capturing
the lisp output in the NRLIB directory. Is that right Tim?

> ...
> There is another possibility, which requires some thought. What if
> we send expression tree from axiom to TeXmacs as an S-expression,
> instead of serializing it via LaTeX? TeXmacs understands not only
> latex: fields, but also scheme: fields. Generating scheme syntax
> from an axiom expression may well be easier than generating LaTeX.
> Line breaking can be done on the TeXmacs side, where the necessary
> information is available (it is in principle impossible to tell,
> what is the width of a sub-expression after typesetting, without
> actually typesetting it). But this is, probably, a more long-term
> project. For now, I'd better keep as much as possible from
> the current interface, but make it more robust and less ugly.
>
> What do you think?
>

I like your last idea best. I think it would be a mistake to spend
too much effort simply tweaking the LaTeX output to make the current
interface more robust. The idea of having a )set output mode that
generates semantically rich S-expression output is very appealing
not only for use in TeXmacs but also for the work that Kai Kaminski
is doing right now with the new AxiomUI. I think that many of the
hooks that might be necessary to do this in Axiom must already be
present in Axiom since this goal is very similar to to goal that
NAG had towards the end of the commercial development of Axiom to
produce OpenMath output.

After the current (rush) phase of the Summer of Code AxiomUI project
is over at the beginning of September, I hope that Kai will have
a chance to discuss here more of what he had in mind of AxiomUI in
this regard.

\start
Date: Tue, 30 Aug 2005 19:08:56 -0400
From: Bill Page
To: Jens Axel Segaard, Martin Rubey
Subject: Tail recursion (was: Lexicographic order)

On Tuesday, August 30, 2005 3:44 PM Jens Axel Segaard wrote:

> >  >
> >  > loop : INT -> INT
> >  >
> >  > loop (n) == loop (n)
> >  >
> >  > loop (1)
> >  >
> >  >    >> System error:
> >  >    Invocation history stack overflow.
> >

> Martin Rubey wrote:
> > Although this is not a nice way for Axiom to fail, two questions:
> >
> > * is this an instance of tail-recursion?
> >
> > * what result would you expect?
>
> Yes - if tail recursion were supported, then the above would be
> an infinite loop. I haven't got any complaints over the wording
> of the error message.
>

I think the example at:

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

shows that something more subtle is happening here than just
tail-recursion elimination (or not).

For one thing, the call to summa(1000000) did not fail with a
"Invocation history stack overflow" as Jens predicted above
but summa2(1000000,0) did fail.

The definition::

  summa(n) ==
    if n=0
    then 0
    else n + summa(n-1)

is apparently treated specially by Axiom as a "recurrence
relation" and so does not produce a stack overflow.

Similarly a stack overflow does occur in this simpler case:
\begin{axiom}
loop : INT -> INT
loop (n) == loop (n)
\end{axiom}

\begin{axiom}
loop (1)
\end{axiom}

Now let's see what happens if we tell Axiom to compile the
function (see web page above):

\begin{axiom}
)set functions compile on
\end{axiom}

\begin{axiom}
  -- a stands for accumulator
  summa3(n, a) ==
    if n=0
    then a
    else summa3(n-1, n+a)
\end{axiom}

\begin{axiom}
summa3(1000000,0)
\end{axiom}

Now this function returns a correct value without the stack
overflow. And similarly

\begin{axiom}
loop : INT -> INT
loop (n) == loop (n)
\end{axiom}

if called here with 'loop(1)' becomes an infinite loop.

So it seems that perhaps the tail recursion elimination only
works when the function is compiled unless it is recognized as
special case of a recurrence relation.

The message "Invocation history stack overflow" is actually generated
by gcl (gcl 2.6.6 is the lisp compiler used to build Axiom on =
MathAction).
Although the examples above seem to suggest that tail recursion
elimination is working as expected in the case where the Axiom =
interpreter
functions are compiled, a search of the web returned the following hits
which suggest that some previous versions of gcl may have had some =
problems
with tail recursion:

- https://savannah.gnu.org/task/?func=detailitem&item_id=788

- http://lists.gnu.org/archive/html/gcl-devel/2002-03/msg00032.html

- http://www.mail-archive.com/gcl-devel@gnu.org/msg00287.html

So maybe there is still a problem lurking out there?

\start
Date: Tue, 30 Aug 2005 19:42:34 -0400
From: Bill Page
To: Tim Daly
Subject: )set functions compile on

Tim et al.,

There are some known problems in the current version of Axiom with
certain function definitions in the case of

)set functions compile off

which is the current default state. See

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

Of course we would like to know what causes this problem and to
fix it, but the work-a-round is simply to turn it on.

On page 241 (258 of 1105) the Axiom book says:

When a function is compilable, you have the choice of whether it
is compiled to Common Lisp and then interpreted by the Common Lisp
interpreter or then further compiled from Common Lisp to machine
code. The option is controlled via )set functions compile. Issue
)set functions compile on to compile all the way to machine code.
With the default setting )set functions compile off, Axiom has its
Common Lisp code interpreted because the overhead of further
compilation is larger than the run-time of most of the functions
our users have defined. You may find that selectively turning this
option on and off will give you the best performance in your
particular application. For example, if you are writing functions
for graphics applications where hundreds of points are being
computed, it is almost certainly true that you will get the best
performance by issuing )set functions compile on.

--------

With gcl on modern computer systems function compilation does
not seem to take any noticeable amount of time. Can you think
of any good reason why

)set functions compile on

should not be the default?

\start
Date: Wed, 31 Aug 2005 01:58:51 +0200
From: Jens Axel Segaard
To: Bill Page
Subject: Re: Tail recursion (was: Lexicographic order)

Page, Bill wrote:

> I think the example at:
>
> http://www.axiom-developer.org/zope/mathaction/SandBoxTailRecursion
>
> shows that something more subtle is happening here than just
> tail-recursion elimination (or not).
>
> For one thing, the call to summa(1000000) did not fail with a
> "Invocation history stack overflow" as Jens predicted above
> but summa2(1000000,0) did fail.
>
> The definition::
>
>   summa(n) ==
>     if n=0
>     then 0
>     else n + summa(n-1)
>
> is apparently treated specially by Axiom as a "recurrence
> relation" and so does not produce a stack overflow.

Ok - I choose a bad example.

> Now let's see what happens if we tell Axiom to compile the
> function (see web page above):
>
> \begin{axiom}
> )set functions compile on
> \end{axiom}
>
> \begin{axiom}
>   -- a stands for accumulator
>   summa3(n, a) ==
>     if n=0
>     then a
>     else summa3(n-1, n+a)
> \end{axiom}
>
> \begin{axiom}
> summa3(1000000,0)
> \end{axiom}
>
> Now this function returns a correct value without the stack
> overflow. And similarly
>
> \begin{axiom}
> loop : INT -> INT
> loop (n) == loop (n)
> \end{axiom}
>
> if called here with 'loop(1)' becomes an infinite loop.
>
> So it seems that perhaps the tail recursion elimination only
> works when the function is compiled unless it is recognized as
> special case of a recurrence relation.

It does seem to work in cases, where the tail recursive call is
to the function itself.

I tried another tail recursive loop in the Octorber 2004 version:

)set functions compile on
foo : INT -> INT
bar : INT -> INT
foo (n) == bar (n)
bar (n) == foo (n)
foo (1)

and got a

   >> System error:
   Value stack overflow.

However, I am not sure the above is the correct way to define
two mutually recursive functions.

> The message "Invocation history stack overflow" is actually generated
> by gcl (gcl 2.6.6 is the lisp compiler used to build Axiom on MathActio=
n).
> Although the examples above seem to suggest that tail recursion
> elimination is working as expected in the case where the Axiom interpre=
ter
> functions are compiled, a search of the web returned the following hits
> which suggest that some previous versions of gcl may have had some prob=
lems
> with tail recursion:
>
> - https://savannah.gnu.org/task/?func=detailitem&item_id=788
 >
> - http://lists.gnu.org/archive/html/gcl-devel/2002-03/msg00032.html
>
> - http://www.mail-archive.com/gcl-devel@gnu.org/msg00287.html
>
> So maybe there is still a problem lurking out there?

That depends on the Axiom interpreter/compiler. Since Common Lisp
doesn't guarantee proper tail recursion, it isn't an error that
tail recursive code can run out of stack space in GCL. Some
Common Lisp compilers make an effort to optimize som tail recursive
calls, but it is usually unsafe to rely on it.

The code from SICP (which uses Scheme) that Maguire is trying is
thus not supposed to work an all Common Lisp implementations.


\start
Date: Tue, 30 Aug 2005 20:46:06 -0400
From: Bill Page
To: Jens Axel Segaard
Subject: RE: Tail recursion

On Tuesday, August 30, 2005 7:59 PM Jens Axel Segaard wrote:

> ...
> It does seem to work in cases, where the tail recursive call is
> to the function itself.
>
> I tried another tail recursive loop in the Octorber 2004 version:
>
> )set functions compile on
> foo : INT -> INT
> bar : INT -> INT
> foo (n) == bar (n)
> bar (n) == foo (n)
> foo (1)
>
> and got a
>
>    >> System error:
>    Value stack overflow.
>
> However, I am not sure the above is the correct way to define
> two mutually recursive functions.
>

I think that what you are writing is correct. With Axiom from the
most recent Patch-44 which used gcl-2.6.6 I tried:

(3) -> )set functions compile on
(3) -> foo : INT -> INT
                               Type: Void
(4) -> bar : INT -> INT
                               Type: Void
(5) -> foo (n) == bar (n)
                               Type: Void
(6) -> bar (n) == foo (n)
                               Type: Void
(7) -> foo (1)
   Compiling function bar with type Integer -> Integer

---------

This behaviour is odd. It should have returned either a result
or an error message. So I repeat the command.

(7) -> foo (1)

   >> System error:
   The function |*1;foo;1;initial| is undefined.

---------

This time I get an error message but not the one I expected.
I don't know what this message means. (Axiom is busted ... )

Let's try a slightly more complicated mutual recursion:

(7) -> foo (n) == if n>0 then bar (n-1)+1 else 0
   Compiled code for foo has been cleared.
   Compiled code for bar has been cleared.
   1 old definition(s) deleted for function or rule foo
                                    Type: Void
(8) -> bar (n) == if n>0 then foo (n-1)+1 else 0
   1 old definition(s) deleted for function or rule bar
                                    Type: Void
(9) -> foo (1)
   Compiling function bar with type Integer -> Integer
   Compiling function foo with type Integer -> Integer

   (9)  1
                                    Type: PositiveInteger
(10) -> foo (100)

   (10)  100
                                    Type: PositiveInteger
(11) -> foo (1000000)

   >> System error:
   Value stack overflow.

Here is the error message which as you suggest implies that
Axiom/GCL did not recognize this as a case where tail recursion
can be eliminated.

Even this "proper" case is apparently not recognized:

(12) -> bar2 (n,a) == if n>0 then foo2 (n-1,n+a) else a
                                    Type: Void
(13) -> foo2 (n,a) == if n>0 then bar2 (n-1,n+a) else a
                                    Type: Void
 (14) -> foo2(1,0)
   Compiling function bar2 with type (Integer,Integer) -> Integer
   Compiling function foo2 with type (Integer,Integer) -> Integer

   (14)  1
                              Type: PositiveInteger
(15) -> foo2(100,0)

   (15)  5050
                              Type: PositiveInteger
(16) -> foo2(10000,0)

   (16)  50005000
                              Type: PositiveInteger
(17) -> foo2(1000000,0)

   >> System error:
   Value stack overflow.

--------

So I think your caution about tail recursion elimination not being
guaranteed is well taken.

I wonder when should expect a "Value stack overflow" instead of
an "Invocation history stack overflow"?

Thanks for your comments.

\start
Date: Tue, 30 Aug 2005 21:34:36 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AldorForAxiom] 

More Examples

  Having put the following simple domain in a file 'test.as' ::

\begin{aldor}
#include "axiom.as"

Test: with { fact: PositiveInteger -> PositiveInteger }
   == add  { fact(n: PositiveInteger): PositiveInteger == 
              { n <= 1 => 1;
                res: PositiveInteger := 1;
                while n > 1 repeat {
                  res := res * n;
                  n := n-1; }
                res } }
\end{aldor}

  )co test.as

\begin{axiom}  
)sh Test
\end{axiom}

\begin{axiom}
fact(5)$Test
\end{axiom}

Known Problems

  On Tue, 11 Jan 2005 15:43:53 +0100 **Martin Rubey** wrote:

The following Aldor construct does not yet work in Axiom.

I just tried another example, which is in fact the reason why
I would love to have Aldor working. I did not expect it to work,
and it does not, but it works *almost*. The code is as follows:

\begin{aldor}
#include "axiom"

Test: with { f: (n: PositiveInteger) -> PrimeField(n) } 
   == add { f(n: PositiveInteger): PrimeField(n) == 
              10::Integer::PrimeField(n) }
\end{aldor}

Note that such a construction -- the resulting domain depending on
the function parameter -- is currently illegal in Axiom. In Aldor
it is fine.

I compiled it with Aldor as usual, and then loaded it into Axiom.
As signature I got the slightly unusual:
\begin{axiom}
)di op f
\end{axiom}

and trying it out I obtained:
\begin{axiom}
f(5)$Test
\end{axiom}

which is roughly what I expected. However, to my great surprise,
if you turn on the debugger (beforehand. You always have to start
a fresh axiom because of the error I told you about in my previous
message) with::

  )lisp (setq |$monitorNewWorld| t)

and thus trace::

  (1) -> f(1783)$Test

the final bit reads::

  protected-symbol-warn called with (NIL)..IntegerMod 1783 wants
   positiveRemainder : (%,%) -> % from  Integer
  ---->Integer----> searching op table for:
   positiveRemainder : (%,%) -> % from  Integer
  <----#<compiled-function |INT;positiveRemainder;3$;28|> Integer
  goget stuffing slot 47 of IntegerMod 1783
  <------#<compiled-function |INT;positiveRemainder;3$;28|> Integer

  PrimeField n activating lazy slot 8: Integer
  PrimeField n activating lazy slot 9: IntegerPrimesPackage Integer

  ..PrimeField n wants
   prime? : Integer -> Boolean from  IntegerPrimesPackage Integer
  ---->IntegerPrimesPackage Integer----> searching op table for:
   prime? : Integer -> Boolean from  IntegerPrimesPackage Integer
  <----#<compiled-function |PRIMES;prime?;IB;4|>(IntegerPrimesPackage,Integer)
  goget stuffing slot 10 of PrimeField n
  <------#<compiled-function |PRIMES;prime?;IB;4|>(IntegerPrimesPackage,Integer)

which clearly tells you, that the calculation is done alright, only the
signature interferes with success.

Any ideas?

Peter said, that it's on the interpreter side. You can read the whole
thread on 
http://lists.gnu.org/archive/html/axiom-developer/2005-01/msg00154.html

Concerning his patches, Peter also pointed out that

--removed:
-Indeed, the following Aldor construct does not yet work in Axiom::
-
-  #include "axiom"
-  
-  Test: with { f: (n: PositiveInteger) -> PrimeField(n) } 
-     == add { f(n: PositiveInteger): PrimeField(n) == 
-                10::Integer::PrimeField(n) }
-
-It nearly works, as one can see from a trace done with 
-')lisp (setq |$monitorNewWorld| t)', but not quite... Peter said, that it's on the 
-interpreter side. You can read the whole thread on 
-http://lists.gnu.org/archive/html/axiom-developer/2005-01/msg00154.html

\start
Date: Tue, 30 Aug 2005 23:40:57 -0400
From: Tim Daly
To: Bill Page
Subject: Re: )set functions compile on

Bill,

I've merged Peter's Aldor changes and am going to recompile the system.
I'll do two builds, one with 
  )set functions compile off
and one with 
  )set functions compile on
and see what breaks.

If nothing breaks then I have no objections to changing the default.

\start
Date: Wed, 31 Aug 2005 01:32:32 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AldorForAxiom] 

functions which you then can use Axiom. For details see:

- http://www.aldor.org/docs/HTML/chap18.html

Here is an example from http://www.aldor.org/docs/HTML/chap18.html

\begin{aldor}
#include "axiom.as"
#pile

MatrixSymmetry(R:Field): with
        symmetricPart : Matrix R -> Matrix R
                ++ `symmetricPart(M)' returns a symmetric
                ++ matrix `S', computed as `(M + transpose M)/2'.
                ++ The difference `M - S' is antisymmetric.

        antisymmetricPart : Matrix R -> Matrix R
                ++ `antisymmetricPart(M)' returns an antisymmetric
                ++ matrix `A', computed as `(M - transpose M)/2'.
                ++ The difference `M - A' is symmetric.
== add
        import from R, Integer

        symmetricPart(m: Matrix R): Matrix R ==
                mt := transpose m
                inv(2::R) * (m + mt)

        antisymmetricPart(m: Matrix R): Matrix R ==
                mt := transpose m
                inv(2::R) * (m - mt)
\end{aldor}

\begin{axiom}
m := matrix[[1/2,1/3],[1/4,1/5]]
s := symmetricPart m
a := antisymmetricPart m
\end{axiom}

See also a more complex example in [RandomAlgebra]

\start
Date: Wed, 31 Aug 2005 08:50:15 +0200
From: Martin Rubey
To: Tim Daly
Subject: re: )set functions compile on

But, on the other hand, I think we should really track down the cause of the
frequent failures when working without )se fu co on

I suspect that this could lead to some insights about how the interpreter
differs from the compiler, and it should be a priority goal to make the
semantics of both the same.

I'm unable to do this, I'd like to stick to the algebra part of Axiom. But who
is in charge of interpreter and compiler?

Martin

root writes:
 > Bill,
 > 
 > I've merged Peter's Aldor changes and am going to recompile the system.
 > I'll do two builds, one with 
 >   )set functions compile off
 > and one with 
 >   )set functions compile on
 > and see what breaks.
 > 
 > If nothing breaks then I have no objections to changing the default.

\start
Date: Wed, 31 Aug 2005 09:44:59 +0200
From: Martin Rubey
To: Bill Page
Subject: re: )set functions compile on

Page, Bill writes:
 > On Wednesday, August 31, 2005 2:50 AM Martin Rubey wrote:
 > > 
 > > But, on the other hand, I think we should really track down the
 > > cause of the frequent failures when working without )se fu co on

 > > I suspect that this could lead to some insights about how the
 > > interpreter differs from the compiler [...]
 > 
 > Be careful here not to confuse the reference to 'compile' in
 > ')set function compile on' with the )compile command. 

Thanks for the clarification. Quite true. So the goal really should read

"to make the semantics of all the same."

I'm aware of the fact that there are fundamental differences between 
interpreter / SPAD / Aldor which are not bugs. But I think, in order to make
Axiom interesting for more people, SPAD should go away (not #pile as an
alternative *syntax* though!) and the semantics of the interpreter should be as
close as possible to the semantics of the compiler.

First step: document interpreter and compiler.

Second step might be to incorporate the "extend" keyword of Aldor, and the
possibility to have dependent types usable (not yet definable, maybe) in Axiom.

Would it be a fitting *challenge* for comp.lang.lisp to devise a *simple*
compiler for the Aldor language as described in the Aldor User Guide? Maybe
with a price of 500$?

\start
Date: Wed, 31 Aug 2005 03:31:01 -0400
From: Bill Page
To: Martin Rubey
Subject: re: )set functions compile on

On Wednesday, August 31, 2005 2:50 AM Martin Rubey wrote:
>
> But, on the other hand, I think we should really track down the
> cause of the frequent failures when working without )se fu co on
>

Agreed.

> I suspect that this could lead to some insights about how the
> interpreter differs from the compiler, and it should be a priority
> goal to make the semantics of both the same.
>

Be careful here not to confuse the reference to 'compile' in
')set function compile on' with the )compile command. In the first
case we are talking about the lisp compiler (i.e. compile lisp to
machine code). In the second case it refers to either the SPAD or
Aldor compilers, both of which compile high level library code to
lisp code and then automatically invoke the lisp compiler to
produce machine code.

For extraordinary debugging situations I believe that it is possible
to run Axiom without compiling the library code to machine code and
to let lisp interpret the generated lisp code directly. (Is that
right Tim?) But normally all library code is compiled twice, once
from SPAD/Aldor to lisp and then a second time from lisp to machine
code.

When ')set function compile off' is in effect, the interpreter
does not call the lisp compiler. Instead it allows lisp to simply
interpret the lisp code that it generates for function definitions.

In the case of the interpreter, in principle there should be no
differences in the semantics between compiling the lisp code or
not. Any difference would constitute a programming error either in
Axiom or in the lisp interpreter/compiler (GCL).

Of course in the case of the )compile command, there *are* significant
differences between the high level language accepted by the interpreter
and the language accepted by the library compiler (SPAD or Aldor). I
suspect that when you say: "make the semantics of both the same" you
have in mind this latter case?

> I'm unable to do this, I'd like to stick to the algebra part of
> Axiom. But who is in charge of interpreter and compiler?
>

Who is in charge? Well, this is open source. We are all in charge.
But the only person I know who has the skills and is active here
is Tim Daly. I am :) because he's here, but :( because there are
still so few other people who are willing and able to contribute
their time to do this kind of work.

\start
Date: Wed, 31 Aug 2005 04:06:41 -0400
From: Bill Page
To: Martin Rubey
Subject: re: )set functions compile on

On Wednesday, August 31, 2005 3:45 AM Martin Rubey wrote:

> ...
> Would it be a fitting *challenge* for comp.lang.lisp to devise a
> *simple* compiler for the Aldor language as described in the Aldor
> User Guide? Maybe with a price of 500$?
>

??? Why would you want a compiler written in lisp for the Aldor
language when there already is an Aldor compiler written in C? I do
not see how it can possibly be "simple".

If you can find anyone willing to write another compiler for a
language like Aldor for $500 then I have a lot of other jobs
I would like them to do first! :)

Seriously. I don't understand your point of view here. Could you
explain what you mean?

\start
Date: Wed, 31 Aug 2005 09:54:25 +0100
From: Mark Murray
To: Tim Daly
Subject: re: axiom on Mac OSX 
Cc: Mark Murray

root writes:
>I'm somewhat confused about the FreeBSD environment. 

How is it going? Anything else I can help with? :-)

\start
Date: Wed, 31 Aug 2005 10:36:48 +0200
From: Martin Rubey
To: Bill Page
Subject: re: )set functions compile on

Page, Bill writes:
 > On Wednesday, August 31, 2005 3:45 AM Martin Rubey wrote:

 > ??? Why would you want a compiler written in lisp for the Aldor
 > language when there already is an Aldor compiler written in C? 

There are (at least) two reasons:

* it is not too unlikely that Aldor will not become free software

* it is always a good thing to have several implementations of the *same*
  language. Mind that I'm not talking about dialects, it is important that the
  implementations strive to satisfy the *same* semantics. A good example is the
  variety of Ansi Common Lisp implementations around.

 > I do not see how it can possibly be "simple".

I suspect that it is *relatively* easy to write a *simple* compiler (i.e., no
optimizations etc.) for Aldor in Lisp.

\start
Date: 31 Aug 2005 12:14:22 -0400
From: Camm Maguire
To: Bill Page
Subject: re: Tail recursion
Cc: Jens Axel Segaard

Greetings!

Bill Page writes:

> On Tuesday, August 30, 2005 7:59 PM Jens Axel Segaard wrote:
>
> > ...
> > It does seem to work in cases, where the tail recursive call is
> > to the function itself.
> >
> > I tried another tail recursive loop in the Octorber 2004 version:
> >
> > )set functions compile on
> > foo : INT -> INT
> > bar : INT -> INT
> > foo (n) == bar (n)
> > bar (n) == foo (n)
> > foo (1)
> >
> > and got a
> >
> >    >> System error:
> >    Value stack overflow.
> >
> > However, I am not sure the above is the correct way to define
> > two mutually recursive functions.
> >
>
> I think that what you are writing is correct. With Axiom from the
> most recent Patch-44 which used gcl-2.6.6 I tried:
>
> (3) -> )set functions compile on
> (3) -> foo : INT -> INT
>                                Type: Void
> (4) -> bar : INT -> INT
>                                Type: Void
> (5) -> foo (n) == bar (n)
>                                Type: Void
> (6) -> bar (n) == foo (n)
>                                Type: Void
> (7) -> foo (1)
>    Compiling function bar with type Integer -> Integer
>
> ---------
>
> This behaviour is odd. It should have returned either a result
> or an error message. So I repeat the command.
>
> (7) -> foo (1)
>
>    >> System error:
>    The function |*1;foo;1;initial| is undefined.
>
> ---------
>

Don't know what to say about this offhand.

But I do recommend that the )set functions compile on feature
automatically proclaim the function signature before compiling, i.e.
running the following in this case:

(proclaim '(ftype (function (t) t) foo))
(proclaim '(ftype (function (t) t) bar))

or even

(proclaim '(ftype (function (integer) integer) foo))
(proclaim '(ftype (function (integer) integer) bar))


> This time I get an error message but not the one I expected.
> I don't know what this message means. (Axiom is busted ... )
>
> Let's try a slightly more complicated mutual recursion:
>
> (7) -> foo (n) == if n>0 then bar (n-1)+1 else 0
>    Compiled code for foo has been cleared.
>    Compiled code for bar has been cleared.
>    1 old definition(s) deleted for function or rule foo
>                                     Type: Void
> (8) -> bar (n) == if n>0 then foo (n-1)+1 else 0
>    1 old definition(s) deleted for function or rule bar
>                                     Type: Void
> (9) -> foo (1)
>    Compiling function bar with type Integer -> Integer
>    Compiling function foo with type Integer -> Integer
>
>    (9)  1
>                                     Type: PositiveInteger
> (10) -> foo (100)
>
>    (10)  100
>                                     Type: PositiveInteger
> (11) -> foo (1000000)
>
>    >> System error:
>    Value stack overflow.
>
> Here is the error message which as you suggest implies that
> Axiom/GCL did not recognize this as a case where tail recursion
> can be eliminated.

Yes, currently we do not eliminate mutual tail recursive calls -- we
can only do this with special support from the C compiler such as
gcc.  When we do implement eventually, somehow axiom would have to
group these two functions into the same C file or otherwise instruct
GCL to do so, as this is a requirement of the GCC mutual tail
recursion elimination support.


>
> Even this "proper" case is apparently not recognized:
>
> (12) -> bar2 (n,a) == if n>0 then foo2 (n-1,n+a) else a
>                                     Type: Void
> (13) -> foo2 (n,a) == if n>0 then bar2 (n-1,n+a) else a
>                                     Type: Void
>  (14) -> foo2(1,0)
>    Compiling function bar2 with type (Integer,Integer) -> Integer
>    Compiling function foo2 with type (Integer,Integer) -> Integer
>
>    (14)  1
>                               Type: PositiveInteger
> (15) -> foo2(100,0)
>
>    (15)  5050
>                               Type: PositiveInteger
> (16) -> foo2(10000,0)
>
>    (16)  50005000
>                               Type: PositiveInteger
> (17) -> foo2(1000000,0)
>
>    >> System error:
>    Value stack overflow.
>
> --------
>
> So I think your caution about tail recursion elimination not being
> guaranteed is well taken.
>
> I wonder when should expect a "Value stack overflow" instead of
> an "Invocation history stack overflow"?

If the calls pass arguments and return types via the list stack, such
as is the case when the functions are not proclaimed, or when running
in debugging mode, or (at present) when the function returns mutiple
values for example, one fills up the value stack as well as the
invocation history stack and it is undetermined which will fill first.
If all argument passing is done via the C stack, such as is the case
for proclaimed functions of simple argument and return types which are
compiled and debugging is off, then one will  either overrun the C
stack with a segfault or proceed forevever depending on whether GCL
has eliminated the recursion.  One can see explicitly what is going on
by examining the compiler notes.  I think Tim may be patching the GCL
source to eliminate these completely, but in 2.6.7 and later, there is
a simple switch:

compiler::*suppress-compiler-notes*

which can be set to achieve the same thing and give the user the
option to see them if needed.  Defaults to nil on 2.6.7 and t in 2.7.0
and higher.


\start
Date: 31 Aug 2005 11:59:46 -0400
From: Camm Maguire
To: Jens Axel Segaard
Subject: re: Tail recursion (was: Lexicographic order)

Greetings!

Jens Axel Segaard writes:

> Page, Bill wrote:
>
> > I think the example at:
> > http://www.axiom-developer.org/zope/mathaction/SandBoxTailRecursion
> > shows that something more subtle is happening here than just
> > tail-recursion elimination (or not).
> > For one thing, the call to summa(1000000) did not fail with a
> > "Invocation history stack overflow" as Jens predicted above
> > but summa2(1000000,0) did fail.
> > The definition::
> >   summa(n) ==
> >     if n=0
> >     then 0
> >     else n + summa(n-1)
> > is apparently treated specially by Axiom as a "recurrence
> > relation" and so does not produce a stack overflow.
>
> Ok - I choose a bad example.
>
> > Now let's see what happens if we tell Axiom to compile the
> > function (see web page above):
> > \begin{axiom}
> > )set functions compile on
> > \end{axiom}
> > \begin{axiom}
> >   -- a stands for accumulator
> >   summa3(n, a) ==
> >     if n=0
> >     then a
> >     else summa3(n-1, n+a)
> > \end{axiom}
> > \begin{axiom}
> > summa3(1000000,0)
> > \end{axiom}
> > Now this function returns a correct value without the stack
> > overflow. And similarly
> > \begin{axiom}
> > loop : INT -> INT
> > loop (n) == loop (n)
> > \end{axiom}
> > if called here with 'loop(1)' becomes an infinite loop.
> > So it seems that perhaps the tail recursion elimination only
> > works when the function is compiled unless it is recognized as
> > special case of a recurrence relation.
>
> It does seem to work in cases, where the tail recursive call is
> to the function itself.
>
> I tried another tail recursive loop in the Octorber 2004 version:
>
> )set functions compile on
> foo : INT -> INT
> bar : INT -> INT
> foo (n) == bar (n)
> bar (n) == foo (n)
> foo (1)
>
> and got a
>
>    >> System error:
>    Value stack overflow.
>
> However, I am not sure the above is the correct way to define
> two mutually recursive functions.

Just wanted to confirm the basic gist of this thread -- GCL will
implement tail recursion when:

1) the call is to the function itself
2) the function is compiled
3) the argument list and return types are known and not variable
   (i.e. proclaimed)
4) one is not running in degugging mode (si::use-fast-links nil)

One thing I'd like to do is to extend this to optional arguments, and
perhaps multiple value returns.

As far as mutual recursion goes, this cannot be done in C without
special non-standard support from the C compiler.  Thankfully, GCL
prvides this.  I have a patch, not yet committed, which gets mutual
tail recursion elimination when

1) the above is satisfied
2) the two calls are in the same file
3) the two functions have exactly the same argument and return types.

As for the old example from SICP, it is true that lisp is not required
to eliminate this, but that's not really relevenat for GCL as we do
want to do tail recursion where possible.  On looking at it again, I
don't see why it is tail recursive at all, even if one grants mutual
tail recursion.  I'm probably just overlooking something.

>
> > The message "Invocation history stack overflow" is actually generated
> > by gcl (gcl 2.6.6 is the lisp compiler used to build Axiom on MathActio=
n).
> > Although the examples above seem to suggest that tail recursion
> > elimination is working as expected in the case where the Axiom interpre=
ter
> > functions are compiled, a search of the web returned the following hits
> > which suggest that some previous versions of gcl may have had some prob=
lems
> > with tail recursion:
> > - https://savannah.gnu.org/task/?func=detailitem&item_id=788
>  >
> > - http://lists.gnu.org/archive/html/gcl-devel/2002-03/msg00032.html
> > - http://www.mail-archive.com/gcl-devel@gnu.org/msg00287.html
> > So maybe there is still a problem lurking out there?
>
> That depends on the Axiom interpreter/compiler. Since Common Lisp
> doesn't guarantee proper tail recursion, it isn't an error that
> tail recursive code can run out of stack space in GCL. Some
> Common Lisp compilers make an effort to optimize som tail recursive
> calls, but it is usually unsafe to rely on it.
>
> The code from SICP (which uses Scheme) that Maguire is trying is
> thus not supposed to work an all Common Lisp implementations.


\start
Date: Wed, 31 Aug 2005 14:55:59 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [FormalFraction] (new) 

Author -- M.G. Richardson

Date Created -- 1996 Jan. 23

Related Constructors -- Fraction

URL -- http://page.axiom-developer.org/repository/axiom--main--1/src/algebra/ffrac.as.pamphlet

N.B. --  ndftip.as inlines this, must be recompiled if this is.

Description:

 This type represents formal fractions - that is, pairs displayed as
 fractions with no simplification.

 If the elements of the pair have a type X which is an integral
 domain, a FFRAC X can be coerced to a FRAC X, provided that this
 is a valid type.  A FRAC X can always be coerced to a FFRAC X.
 If the type of the elements is a Field, a FFRAC X can be coerced
 to X.

 Formal fractions are used to return results from numerical methods
 which determine numerator and denominator separately, to enable
 users to inspect these components and recognise, for example,
 ratios of very small numbers as potentially indeterminate.

\begin{aldor}
#include "axiom.as"

FFRAC ==> FormalFraction ;
 
OF    ==> OutputForm ;
SC    ==> SetCategory ;
FRAC  ==> Fraction ;
ID    ==> IntegralDomain ;

FormalFraction(X : SC) : SC with {

-- Could generalise further to allow numerator and denominator to be of
-- different types, X and Y, both SCs.  "Left as an exercise."

  / : (X,X) -> % ;
++ / forms the formal quotient of two items.

  numer : % -> X ;
++ numer returns the numerator of a FormalFraction.

  denom : % -> X ;
++ denom returns the denominator of a FormalFraction.

  if X has ID then {
  
    coerce : % -> FRAC(X pretend ID) ;
++ coerce x converts a FormalFraction over an IntegralDomain to a
++ Fraction over that IntegralDomain.

    coerce : FRAC(X pretend ID) -> % ;
++ coerce converts a Fraction to a FormalFraction.

  }

  if X has Field then coerce : % -> (X pretend Field) ;

} == add {

  import from Record(num : X, den : X) ;
  
  Rep == Record(num : X, den : X) ; -- representation

  ((x : %) = (y : %)) : Boolean ==
    ((rep(x).num = rep(y).num) and (rep(x).den = rep(y).den)) ;

  ((n : X)/(d : X)) : % == per(record(n,d)) ;

  coerce(r : %) : OF == (rep(r).num :: OF) / (rep(r).den :: OF) ;

  numer(r : %) : X == rep(r).num ;

  denom(r : %) : X == rep(r).den ;

  if X has ID then {
 
    coerce(r : %) : FRAC(X pretend ID)
      == ((rep(r).num)/(rep(r).den)) @ (FRAC(X pretend ID)) ;

    coerce(x : FRAC(X pretend ID)) : % == x pretend % ; 

  }

  if X has Field then coerce(r : %) : (X pretend Field)
    == ((rep(r).num)/(rep(r).den)) $ (X pretend Field) ;

}
\end{aldor}

\begin{axiom}
f1 : FormalFraction Integer
f1 := 6/3

--       6
--       -
--       3

f2 := (3.6/2.4)$FormalFraction Float

--       3.6
--       ---
--       2.4

numer f1

--       6

denom f2

--       2.4

f1 :: FRAC INT

--       2

% :: FormalFraction Integer      

--       2
--       -
--       1

f2 :: Float

--       1.5

\end{axiom}

\start
Date: Thu, 01 Sep 2005 01:14:53 +0200
From: Kai Kaminski
To: list
Subject: [UI] Plot Support

Hi!

I have just uploaded a new version of AxiomUI to my homepage at
kaikaminski.gmxhome.de. It now supports two-dimensional plots. Some
options do not work, but there are a few examples in the README to
demonstrate what is possible.

I should mention that at the moment quite a bit of debugging output is
printed, which makes everything a lot slower than it usually is. Also
keep in mind that when you first plot something, all the necessary
libraries have to be loaded, which also takes some time.

\start
Date: Wed, 31 Aug 2005 19:44:46 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AldorForAxiom] 

To compile an Aldor function, for example this non-recursive method
to compute a factorial, in MathAction the Aldor code appears
between !\begin{aldor}![fact] ... \end{aldor} tags on the edit page.

The optional ![name] parameter is used to name the compiled library
file which can be used later on another page in a ')library' command.

\start
Date: Wed, 31 Aug 2005 20:07:06 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AldorForAxiom] 

If you care to, you can also look at the "Aldor
source":http://page.axiom-developer.org/zope/mathaction/images/fact.as
generated "lisp
code":http://page.axiom-developer.org/zope/mathaction/images/fact.lsp
and the final "compiled
result":http://page.axiom-developer.org/zope/mathaction/images/fact.asy
at http://page.axiom-developer.org/zope/mathaction/images/![name].as,
.lsp and .asy




\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
