File: 2005-10.txt

package info (click to toggle)
axiom 20170501-4
links: PTS
area: main
in suites: buster
size: 1,048,504 kB
sloc: lisp: 3,600; makefile: 505; cpp: 223; ansic: 138; sh: 96
file content (27998 lines) | stat: -rw-r--r-- 1,089,176 bytes
parent folder | download | duplicates (3)
\start
Date: Sat, 01 Oct 2005 22:46:56 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] (new) 

We would like to be able to edit and display Axiom pamphlet
files on MathAction. Pamphlet files contain both source code
and documentation. All of the files necessary to build Axiom
are pamphlet files. The format is LaTeX plus some extra markup
for code sections and must be preprocessed by a "noweb" filter
before LaTeX.

Pamphlet files on MathAction would allow easy access to Axiom
system documentation plus the ablity to collaboratively edit
the Axiom source and documentation through the web. Development
versions of Axiom could then be built directly from the modified
pamphlet files. This should significantly shorten the time
required to enhance and maintain the system.

Proposed Design: Embedded PDF

  See example page [SandBox Embeded PDF]

It is well known that conversion to HTML does not produce hiqh
quality presentations of LaTeX content. LaTeX can be easily
rendered as publication quality pdf, but the pdf format itself
is not well suited as a web format. pdf is a proprietary format
although viewers, browser plugins and pdf creation software is
freely. The use of pdf is a compromize that is made necessary by technical limitations of current web browser software.

It is possible to embed a pdf document inside an HTML web page
and to automatically generate such pages from pamphlet source
files stored as a new 'pamphlet' ZWiki PageType on MathAction.
Pamphlet files would be edited like any other wiki page and
rendered as pdf embedded in HTML, as shown on the example page, when 'Preview' or 'Save' is clicked.

In case no pdf viewer plug-in is installed in the browser,
ordinary links are provided to download the pdf file, or
alternatively a dvi format file, and also the source file
itself.

In addition to rendering the pamphlet content as pdf, clicking
the 'Save' button will also automatically update an associated
source code archive with the modified source. This will enable
developers to quickly build and test new versions of Axiom.



Please visit [SandBox Embeded PDF] to see an example of how a
pamphlet file will look in MathAction. At present this is just
a mockup built from files generated manually. In the final
working system clicking 'edit' will allow editing of the
pamphlet source code. It would be very useful if you could
leave a comment on this page describing how the page looks in
your browser.

Implementation of the new 'pamphlet' PageType in Axiom is
estimated to require only about two or three days of programming
and testing.

Your comments on this design would be most welcome.

\start
Date: Sun, 2 Oct 2005 12:25:42 -0700
From: Antoine Hersen
To: list
Subject: Master Thesis Subject

Hello,

I am pursuing a master degree in CS at California State University of  
Sacramento and an Engineering degree in France.

I am looking for a Master Thesis subject in CS and I will be very  
interested to do something related to CAS and Axiom.
I have fairly decent ability in math as I am planning to get a master  
in math after.
And I am good at functional language even if I am more familiar with  
ML and Scheme than CL.

I will really appreciate any idea with some track to begin.
And hope to make a positive contribution to Axiom.

\start
Date: Sun, 02 Oct 2005 14:41:18 -0500
From: MathAction (Martin Rubey)
To: MathAction
Subject: [#210 Pamphlet support on MathAction]

I think that the idea is quite good, especially, since it seems to be easy to
implement. 

One (probably minor) problem is that I won't be able to use that feature at
home, since downloading the pdf files takes just too long. 

My version of Konqueror (3.1.4, very old, I know) doesn't display the pdf
embedded, but outside Konqueror (using Kghostview). Maybe I'd need to configure
something...

I think that the solution is great for a start, but in the long run I'd be
happier with a solution la axiomui.

Still, it's great that there is support after all!

\start
Date: Sun, 02 Oct 2005 15:50:33 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#211 Products are differentiated incorrectly]	(nouveau) 

\begin{axiom}
D(product((1-q^(n-i))/(1-q^(m-i)),i=0..m-1),q)
f:=operator 'f;
D(product(f(i,q),i=0..m),q)
\end{axiom}

I'll try to correct this tomorrow...

\start
Date: Sun, 02 Oct 2005 22:07:54 -0500
From: MathAction
To: MathAction
Subject: [Programming Axiom] 

The language used for programming Axiom is called [SPAD]. In fact, [SPAD] has a
cousin, originally intended as a successor called [Aldor] which can be used
alternatively to 'spad'. There has not been a decision yet as to whether

A-sharp (A#), !AxiomXL, and now Aldor. Aldor programs will run in Axiom

\start
Date: Sun, 02 Oct 2005 21:36:47 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [DesignIssues] Re: Expression Integer type

Type 'Expression Integer' refers to any expression with 'coefficients'
that are integers. If you don't tell Axiom otherwise, then Axiom
"thinks" of 'sin(x)' as '1*sin(x)' i.e. and 'Expression' with the
'Integer' coefficient 1. For example, what would you expect the
result of the expression '1.0*sin(x)' to be?
\begin{axiom}
1.0*sin(x)
\end{axiom}

The type of the result of some calculation in Axiom is always
expressed as an object with of the same type as operation that
created it. So in your example 'asin(1)' is an 'Expression Integer'
for the same reason as sin(x) is an 'Expression Integer' and the
result is still and 'Expression Integer' even though Axiom decides
to display the value of 'asin(1)' in a more convenient form.
Ditto 'sqrt(%pi)'.

In princple in should be possible to ask Axiom to represent the
result of a calculation in a different form. E.g.
\begin{axiom}
asin(1)::Expression Float
sqrt(%pi)::Expression Float
\end{axiom}

But in some cases the result is unexpected. For example:
\begin{axiom}
asin(1)::Pi
\end{axiom}
'Pi' is a type for certain constant-valued expressions in $\pi$.
However in this case it seems that the domain Expression Integer
is not sufficiently complete to perform this conversion, though
it works in the other direction
\begin{axiom}
%pi/2
%::Expression Integer
\end{axiom}

\start
Date: Sun, 02 Oct 2005 22:32:56 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] 

and testing. This is much less effort then would have been
required to complete the original approach described below.

Your comments on this new design would be most welcome.

Previous Work

  The initial approach for pamphlet support in MathAction 
turned out to be much more complicated than expected and work
on this was delayed and subsquently abandoned.

The approach was to use Norman Ramsey's Latex to HTML [l2h]
noweave filter. This filter together with noweave, is able
to produce HTML files directly from noweb (pamphlet) files.
[l2h] is written in Icon - so over the last couple of days
I had to learn yet another language. Icon is quite tidy and
fast and apparently well suited language for this sort of
complex conversion. I have modified and extended [l2h] so that
inline and display math environments as well as the axiom,
aldor and reduce pseudo-environments are passed straight
through the conversion. Now that I understand Icon and
thanks to Norman's literate programming style, I have also
added some missing things needed my first set of test files.

The output of the modified l2h can then be given directly
to LatexWiki (or MathAction) as an HTML+LaTeX file. When
it is fully integrated into MathAction, the pamphlet file
itself will be stored and converted transparently using
noweave with the modified l2h filter when clicking Save.

<hr />

happier with a solution la axiomui.

\start
Date: Sun, 02 Oct 2005 22:10:49 -0500
From: MathAction (billpage)
To: MathAction
Subject: [SPAD] (new) 

The language used in Axiom is called Spad (a contraction of Scratchpad,
the original name for Axiom). The Scratchpad compiler was rewritten
many tims as both Axiom and its language developed as an ongoing,
evolving research effort). The result was both the current internal
SPAD compiler, that lives in the interpreter, and an external stand-alone
compiler written in C called Aldor.

\start
Date: Sun, 02 Oct 2005 22:45:26 -0500
From: MathAction (billpage)
To: MathAction
Subject: [FrontPage] 

<tr><td style="text-align:center">o</td><td>
The [Axiom Development] process makes extensive use of [Literate Programming]</td></tr>

Axiom supports both [SPAD] and [Aldor] as library compilers</td></tr>

Discuss Axiom in the [Axiom Colloquium] and 
contribute ideas for [Future Development]</td></tr>

\start
Date: Sun, 02 Oct 2005 23:52:33 -0500
From: MathAction (billpage)
To: MathAction
Subject: [Literate Programming] (new) 

The standard form for all Axiom programs and documentation is
the noweb literate programming extension of LaTeX (called
"pamphlet files" in Axiom terminology). Pamphlet files contain
both documentation and the program code itself. This format
is used for all internal Axiom coding and the entire Algebra
library. It is expected that new Algebra that is intended by
it's author to be shared with other Axiom users will also be
prepared in pamphlet format.


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

  Single page summary -- "pdf":/public/onepage.pdf
      from http://www.eecs.harvard.edu/~nr/noweb/onepage.ps
                       
  Some examples --
      http://www.eecs.harvard.edu/~nr/noweb/examples/index.html

>From http://www.literateprogramming.com:

Donald Knuth:

"The practitioner of literate programming can be regarded as an
essayist, whose main concern is with exposition and excellence
of style. Such an author, with thesaurus in hand, chooses the
names of variables carefully and explains what each variable
means. He or she strives for a program that is comprehensible
because its concepts have been introduced in an order that is
best for human understanding, using a mixture of formal and
informal methods that reinforce each other."

Ross Williams:

"A traditional computer program consists of a text file containing
program code. Scattered in amongst the program code are comments
which describe the various parts of the code.

In literate programming the emphasis is reversed. Instead of
writing code containing documentation, the literate programmer
writes documentation containing code. No longer does the English
commentary injected into a program have to be hidden in comment
delimiters at the top of the file, or under procedure headings,
or at the end of lines. Instead, it is wrenched into the daylight
and made the main focus. The "program" then becomes primarily a
document directed at humans, with the code being herded between
"code delimiters" from where it can be extracted and shuffled
out sideways to the language system by literate programming
tools."

Historical sketch

  http://www.vivtek.com/litprog.html

The term literate programming, and the original literate
programming system (WEB) which implemented the concept, were
both the creation of Donald Knuth, one of the most literate
programmers the world has ever known. Knuth, of course, is
the author of "The Art of Computer Programming", the TeX
typesetting system, and other works of the programming art.
It was Knuth's intention to provide a system of programming
by which the programmer could typeset his or her work in book
or article form, so that each choice of implementation, each
algorithm, was clearly explained and justified. The resulting
work of art would then stand as the quintessential definition
of a solution for the problem it addressed.

Knuth used and developed this system while writing TeX and
Metafont, and the resulting two books of code/documentation
remain the most readable and usable collections of code I have
ever seen. TeX, of course, is the standard of typesetting software
in the academic world (usually in its LaTeX incarnation, which
runs as a macro package on basic TeX), and has been for nearly
twenty years. Twenty years for a software package! Only Unix
has comparable staying power.

Literate programming, however, is not a mainstream technique.
Those who use literate programming tools often wonder why not.
There have been no studies done of which I am aware, but the
basic shortcoming of literate programming is that it is difficult
to write a literate program quickly. Yes, once it is written,
it is impeccably documented, easily debugged (in those cases
where it isn't already provably correct), simply maintained
by the original author and others, and in general simply has
a far higher quality in every respect than an "illiterate"
program. But it takes longer to see results.

\start
Date: Mon, 03 Oct 2005 00:25:43 -0500
From: MathAction (billpage)
To: MathAction
Subject: [Future Development] (new) 

Ideas and plans for the future development of Axiom

Related Pages:

  [Wish List] --
     unclassified, unprioritized, open list

  [Summer Of Code] --
     Project list originally prepared for Google's Summer of Code, 2005

  [Axiom Current State] --
     circa 2004

  [Axiom Development] --
     Axiom development strategy and practice

\start
Date: Mon, 03 Oct 2005 00:54:35 -0500
From: MathAction (billpage)
To: MathAction
Subject: [WebLog] 

 archive="['200510', '200509','200508','200507','200506','200505','200504','200503''200502','200501','200412','200411','200410','200409','200408','200407','200406','200405','200404']"
 archtxt="['Oct, 2005','Sept, 2005','Aug, 2005','July, 2005','June, 2005','May, 2005','Apr, 2005','Mar, 2005','Feb, 2005','Jan, 2005','Dec, 2004','Nov, 2004','Oct, 2004','Sep, 2004','Aug, 2004','Jul, 2004','Jun, 2004','May, 2004','Apr, 2004']"

\start
Date: Mon, 03 Oct 2005 01:08:58 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#212 substituting for an operator in a sum does not apply the summation algorithms] (new) substituting for an	operator in a sum does not apply the summation algorithms

Update of bug #9217 (project axiom):

                  Status:                    None => transferred            
          Internal cause: first the sum is evaluated. Since the argument --
f(x)-- is not a polynomial or rational function, using first iidsum, than
idsum of COMBF. Afterwards the substitution is performed. Now the sum has the
internal format
%defsum [%A, %A, i, a, b], which is again evaluated with iidsum and idsum of
COMBF. The function sum$InnerPolySum is never called, of course. A general
solution is to call sum from within idsum, but in this case, care has to be
taken that summation algorithms that can fail (such as Gosper's) do not
produce an infinite loop. (In fact I think this is OK, I only did not have
the time to check)  => first the sum is evaluated. Since the argument --
f(x)-- is not a polynomial or rational function, using first iidsum, than
idsum of COMBF. Afterwards the substitution is performed. Now the sum has the
internal format
%defsum [%A, %A, i, a, b], which is again evaluated with iidsum and idsum of
COMBF. The function sum$InnerPolySum is never called, of course. A general
solution is to call sum from within idsum, but in this case, care has to be
taken that summation algorithms that can fail (such as Gosper's) do not
produce an infinite loop. (In fact I think this is OK, I only did not have
the time to check) 

\start
Date: Mon, 3 Oct 2005 01:52:12 -0400
From: Bill Page
To: Antoine Hersen
Subject: RE: Master Thesis Subject

On October 2, 2005 3:26 PM Antoine Hersen wrote:
> 
> I am pursuing a master degree in CS at California State 
> University of Sacramento and an Engineering degree in
> France.
> 
> I am looking for a Master Thesis subject in CS and I will be
> very interested to do something related to CAS and Axiom.

Great! I think Axiom provides a lot of opportunities for
mathematically oriented computer science at the masters level
(and Phd level too). Axiom would benefit greatly by the attention
of a new generation of researchers and developers.

> I have fairly decent ability in math as I am planning to
> get a master in math after. And I am good at functional
> language even if I am more familiar with ML and Scheme
> than CL.

Although it is true that Axiom is implemented in Common Lisp,
a knowledge of lisp is not essential for using Axiom or even
programming in Axiom at the level of mathematical algorithms.
The Axiom languages SPAD and Aldor do have some elements of
functional-style programming.

> 
> I will really appreciate any idea with some track to
> begin. And hope to make a positive contribution to Axiom.
> 

There are a lot of ideas for work on Axiom described on the
Axiom website. See for example:

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

Since Axiom is an open source project primarily supported by
volunteers, most of these projects are likely only to be
undertaken by one of the volunteers if/when they have a direct
need ... or maybe never.

To get an idea of what it is like working with Axiom, you
might want to attempt a simple project from those listed on
the web site. But my best advice to a master's student is to
*first* find a thesis adviser at your institution who has
interests similar to your own, or at least is sympathetic to
what you want to study.

If you post an outline of a proposal here in this mailing
list, I think you will find many people willing to offer
suggestions and support.

\start
Date: Mon, 03 Oct 2005 01:13:52 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [DesignIssues] 

Type 'Expression Integer' refers to any expression involving
functions (or operators) and integers. If you don't tell Axiom otherwise, then Axiom
"thinks" of 'sin(x)' as 'sin(1*x)' i.e. an 'Expression' involving the function 'sin()', a polynomial function 'x' with coefficient '1'. For example, what would you expect the
result of the expression 'sin(1.0*x)' to be?

sin(1.0*x)

The type of the result of some calculation in Axiom is often
expressed as an object of the same type as the operands that

result is still an 'Expression Integer' even though Axiom decides

In princple it should be possible to ask Axiom to represent the

<hr>
Comments from wyscc: 

This is a quite common problem whenever a result can be expressed in a
subdomain. In this case, the subdomain is 'Pi'. The correct way to
perform conversion of types in this situation is to 'retract', not
'coerce' since 'coerce' is supposedly always possible, whereas
'retract' is not. The Interpreter will use 'retract' if it is
available even when '::' is used. However, 'Expression Integer' does
not have 'RetractableTo(Pi)' (we can add this if we like). An example
where this works is:

\begin{axiom}
4/3 * 6/2
(4/3 * 6/2)::Integer
retract(4/3 * 6/2)@Integer
\end{axiom}

whereas this fails.

\begin{axiom}
coerce(4/3*6/2)@Integer
\end{axiom}

\start
Date: Mon, 03 Oct 2005 01:21:10 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#212 substituting for an operator in a sum does not apply the summation algorithms] 

Original Savannah bug 9217

Summary:

Although axiom can evaluate this sum, it does not.

Example of code trigerring the bug:

\begin{axiom}
f := operator 'f
sum(f(i),i=a..b)
eval(%,f,x+->x)
\end{axiom}

Internal Cause

  first the sum is evaluated. Since the argument 'f(x)' is not a polynomial
or rational function, using first iidsum, than idsum of COMBF. Afterwards
the substitution is performed. Now the sum has the internal format
'%defsum [%A, %A, i, a, b]', which is again evaluated with iidsum and idsum of
COMBF. The function 'sum$InnerPolySum' is never called, of course. A general

\start
Date: Mon, 03 Oct 2005 01:26:39 -0500
From: MathAction (billpage)
To: MathAction
Subject: [WishList] 

  I think that a general concept is needed in order to fix #212 and to

\start
Date: Mon, 3 Oct 2005 10:36:54 +0200
From: Michael Brickenstein
To: Bill Page
Subject: Re: Openmath, Singular

Hello Bill Page!
Thanks for your positive response. I am very pleased with this welcome.

Actually I had a discussion in sci.math.symbolic and my conversation 
partner stated that he would like to see our functionality in your 
system. Additionally I have heared in our team, that you have made 
some things about Openmath. So this was my entry point for axiom. And 
of course I have heared of your extremely mathematical type system.

Of course I am interested in MathAction, if we would be able to 
implement a Singular demonstration in the mid. future this would be 
extremely nice and a good demonstration for what I do.

So for further steps, I suggest

- for me to take a closer look at your openmath library
- for you I suggest to
     -check, if axiom is compatible with openmath 2
     -have a look on the polyd CD which is not from the Singular team 
but especially suited
         for Gr=F6bner bases and everything which is based on it

At the moment, I use

"groebner"
"DMP"
"DMPL"
"SDMP"
"term"
"graded_reverse_lexicographic"
"lexicographic"
"groebnerd"

from polyd.
I also use the symbol "Q" from fieldname.
In near future, there is a symbol FreeField or so which will be 
supported.



Further you are invited to make a wishlist, which functions from our 
System (http://www.singular.uni-kl.de) you like to see in a Openmath 
content dictionary.

At the moment, the prototype is nothing as the pure mechanism with 
groebner basis as proof of concept (which is not the easiest possible 
example).
In the next weeks (I have a job as System Administrator and Software 
Developer for my institutes databases, so don't expect me to work 
full time on this), I will improve the basis for the implementation.
My Openmath implementation is based on Python which is embedded in 
Singular and plays together with the Singular interpreter nicely (can 
dynamically call all (a the moment nearly all) interpreter and kernel 
functions). This is written by me and not yet released officially.
Python is in fact a strongly typed language, which doesn't do 
implicit conversions (at default), I only mention this, as I know 
that axiom focuses very much on a type system.
This basis will be improved (mainly bug fixing in the next weeks).

And then I will have time to spend more time the Openmath path.

I will send you some examples of polynomial system encodings using 
polyd, you can of course check, if my understandig of the standard is 
correct.
I also will send you an archive of the polyd CD , as http://
www.openmath.org gives only internal errors at the moment (not so 
unusual there).

Yours,
Michael Brickenstein

\start
Date: Mon, 3 Oct 2005 13:32:30 -0400
From: Bill Page
To: Michael Brickenstein
Subject: RE: Openmath, Singular

On October 3, 2005 4:37 AM Michael Brickenstein wrote:
>
> Actually I had a discussion in sci.math.symbolic and my
> conversation partner stated that he would like to see our
> functionality in your system.

I almost never hang out in the usenet news groups, but
I am glad that some people there are saying good things
about Axiom.

> Additionally I have heard in our team, that you have made
> some things about Openmath. So this was my entry point for
> axiom. And  of course I have heard of your extremely
> mathematical type system.

Let me make clear here that when you say "you have made some
things" and you refer to Axiom as "your system", that does
not refer personally to me. I presume you mean it collectively
in the sense of all the people who have contributed to Axiom
over it's long history. If there is any single person right
now to whom this might apply personally, then it would have
to be Tim Daly. I just happen to be one of the most vocal and
verbose supporters of Axiom at this time.

I hope other Axiom developers will also comment about
OpenMath and Singular.

The closest thing that the Axiom project has to "leadership"
is referred to as the Axiom Foundation. See

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

This is a group of three people (called "members") who have
agreed to help steer the project by being responsible for at
least some of the critical decisions and controlling any
financial support. Although I helped to set this up, I am not
one of the three members. Neither is Tim Daly (by his choice).
Either fortunately or unfortunately, depending on one's point
of view, the Axiom Foundation so far has had very little to
do. The idea is that membership in the Axiom Foundation would
rotate through those individuals most motivated to support
Axiom, but always consist of at least three people.

>
> Of course I am interested in MathAction, if we would be able
> to implement a Singular demonstration in the mid. future
> this would be extremely nice and a good demonstration for
> what I do.

Now, MathAction (as opposed to Axiom) is something for which
I am largely responsible. :) I would be start to look into
adding a web interface to Singular on MathAction.

>
> So for further steps, I suggest
>
> - for me to take a closer look at your openmath library

If you haven't already done this, I suggest you start by
reviewing references to openmath in the axiom-developer archives:

http://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=openmath&submit=Sea
rch%21&idxname=axiom-developer&max=10&result=normal&sort=date%3Aearly

For example:

http://lists.nongnu.org/archive/html/axiom-developer/2004-01/msg00035.html
http://lists.nongnu.org/archive/html/axiom-developer/2003-12/msg00030.html
http://lists.nongnu.org/archive/html/axiom-developer/2003-07/msg00000.html
http://lists.nongnu.org/archive/html/axiom-developer/2003-06/msg00078.html
http://lists.nongnu.org/archive/html/axiom-developer/2003-06/msg00069.html
http://lists.nongnu.org/archive/html/axiom-developer/2002-12/msg00003.html

and a few more ... :) Unfortunately as far as I know, none of this
discussion lead to any substantial work on resurrecting the OpenMath
work in the open source version of Axiom.

> - for you I suggest to
>      -check, if axiom is compatible with openmath 2
>      -have a look on the polyd CD which is not from the
>       Singular team but especially suited for Gr=F6bner bases
>       and everything which is based on it
>
> At the moment, I use
>
> "groebner"
> "DMP"
> "DMPL"
> "SDMP"
> "term"
> "graded_reverse_lexicographic"
> "lexicographic"
> "groebnerd"
>
> from polyd.
> I also use the symbol "Q" from fieldname.
> In near future, there is a symbol FreeField or so which will be 
> supported.
>

Ok, I will look at this.

>
> Further you are invited to make a wishlist, which functions from
> our System (http://www.singular.uni-kl.de) you like to see in a
> Openmath content dictionary.

Probably we need to start something similar for Axiom.

>
> At the moment, the prototype is nothing as the pure mechanism
> with groebner basis as proof of concept (which is not the
> easiest possible  example).
>
> In the next weeks (I have a job as System Administrator and
> Software Developer for my institutes databases, so don't expect
> me to work full time on this), I will improve the basis for
> the implementation.

No problem.

> My Openmath implementation is based on Python which is embedded
> in Singular and plays together with the Singular interpreter
> nicely (can dynamically call all (a the moment nearly all)
> interpreter and kernel functions). This is written by me and
> not yet released officially. Python is in fact a strongly typed
> language, which doesn't do implicit conversions (at default),
> I only mention this, as I know that axiom focuses very much on
> a type system. This basis will be improved (mainly bug fixing
> in the next weeks).

As I understand it Python is a dynamically typed language. To
use the word "strong" seems a little miss-leading.

MathAction is based on software (Zope) written in Python. So
your work with Python in Singular might be some advantage.
>
> And then I will have time to spend more time the Openmath
> path.
>
> I will send you some examples of polynomial system encodings
> using  polyd, you can of course check, if my understanding of
> the standard is  correct.

First I need to understand it. :)

> I also will send you an archive of the polyd CD , as http://
> www.openmath.org gives only internal errors at the moment
> (not so  unusual there).
>

Thanks, I will look into this and probably ask you a lot
of questions later.

\start
Date: Mon, 3 Oct 2005 20:03:03 +0200
From: Michael Brickenstein
To: Bill Page
Subject: Re: Openmath, Singular

Hello!
I am very sorry for not expressing me more clearly. I hope nobody  
feels offended. I appreciate the work of all axiom Developers. It was  
only some weakness of english language (in German you say "Dein"  for  
Singular and "Euer" in Plural as translation for "your").
My view is, that such a software can only be written and maintained  
by a good team, which is also the case for Singular.
In particularly I am a big friend of the open source movement.

For connecting Singular to MathAction directly via Python: This will  
not be possible.
Singular is not a library, so the only thing possible for me was  
writing some embedding not an extension, which is a subtil  
difference, but means that Python runs inside Singular and not  
Singular inside Python.

I am looking forward, actually openmath itself is not so a difficult  
thing to get run, it only needs some motiviation to implement it.
There is no motivation, if nobody uses it.

This is a point, where I attack. Additionaly to axiom I am in contact  
to Sage, and a CAS for representation theory which is in planing. I  
also know from cocoa, that Openmath is their big new feature (and  
some other systems, for which I don't know how important it is for  
them).
Of course I will further increase my contacts in the community.
Together we should form a critical mass.

Yours,
Michael Brickenstein

\start
Date: Mon, 03 Oct 2005 21:27:27 +0200
From: Jens Axel Segaard
To: list
Subject: Re: Openmath, Singular

Bill Page wrote:
> On October 3, 2005 4:37 AM Michael Brickenstein wrote:

>>My Openmath implementation is based on Python which is embedded
>>in Singular and plays together with the Singular interpreter 
>>nicely (can dynamically call all (a the moment nearly all)
>>interpreter and kernel functions). This is written by me and
>>not yet released officially. Python is in fact a strongly typed
>>language, which doesn't do implicit conversions (at default),
>>I only mention this, as I know that axiom focuses very much on
>>a type system. This basis will be improved (mainly bug fixing
>>in the next weeks).
> 
> As I understand it Python is a dynamically typed language. To
> use the word "strong" seems a little miss-leading.

Most likely we just use the words differently, but I don't
see an inherent conflict between "dynamically" and "strong".


I consider a language "strongly typed" if there is an
guarantee that at runtime, it is not possible to use
an operation on operands with other types than the operand
expects - without getting an error.

If a language supports "static typing" it can be determined
at compile time whether a program contains a type error.

If a language is "dynamically typed" then values contain
type information that can be used to do type checking
at runtime.

I consider Scheme a language which is both dynamically
typed and strongly typed.


However, I am aware that not all use the words the same way
as I.

See also the Wikipedia article on "Strongly Typed" :

     <http://en.wikipedia.org/wiki/Strongly_typed>.

\start
Date: Mon, 3 Oct 2005 22:02:47 -0400
From: Bill Page
To: Jens Axel Segaard
Subject: re: Openmath, Singular

On October 3, 2005 3:27 PM Jens Axel S=F8gaard wrote:
>
> Bill Page wrote:
>> On October 3, 2005 4:37 AM Michael Brickenstein wrote:
>
>>> ... Python is in fact a strongly typed language, which
>>> doesn't do implicit conversions (at default), I only
>>> mention this, as I know that axiom focuses very much on
>>> a type system.
>>
>> As I understand it Python is a dynamically typed language.
>> To use the word "strong" seems a little miss-leading.
>
> Most likely we just use the words differently, but I don't
> see an inherent conflict between "dynamically" and "strong".
>

I agree with you. The use of "strong" in this context is
probably correct. But as the article that you cite

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

points out, it is not a very useful distinction.

A more relevant point is that Axiom is "statically" typed,
meaning that types are associated with variables. But in
Python types are associated with values. E.g. in Python we
can write

  x=10
  x="xxx"

In the Axiom compilers we must write

  x:Integer

so that x denotes some object from the domain Integer. E.g.

  x:=10

But

  x:="xxx"

is a type error.

On the other hand in Axiom the values themselves have no
implicit type. For example 1 might mean

  1$Integer
  1$Float
  1$SquareMatrix(2,Integer)
  etc.

By the usual mathematical convention adopted by Axiom library
programmers, 1 denotes the unit with respect to multiplication
in some domain.

\start
Date: Mon, 3 Oct 2005 22:38:08 -0400
From: Bill Page
To: Michael Brickenstein
Subject: RE: Openmath, Singular

On October 3, 2005 2:03 PM Michael Brickenstein wrote:

> I am very sorry for not expressing me more clearly. I hope
> nobody feels offended. I appreciate the work of all axiom
> Developers. It was only some weakness of English language
> (in German you say "Dein"  for Singular and "Euer" in Plural
> as translation for "your").> ...

Nema problema. One would expect that the developers of English
would have corrected such bugs by now! ;)

>
> For connecting Singular to MathAction directly via Python:
> This will not be possible. Singular is not a library, so the
> only thing possible for me was writing some embedding not an
> extension, which is a subtle difference, but means that Python
> runs inside Singular and not Singular inside Python.

Ok. Similarly, Axiom does not "run inside Python" but is simply
called as in external process communicating by stdin and stdout.
If your extensions of Singular need to call Python that is not
a problem.

>
> I am looking forward, actually openmath itself is not so a
> difficult thing to get run, it only needs some motivation to
> implement it. There is no motivation, if nobody uses it.
>

I agree. I think the goals of OpenMath are noble, even though
perhaps overly ambitious and (arguably) a little na=EFve.

> This is a point, where I attack. Additionally to axiom I am in
> contact to Sage, and a CAS for representation theory which is
> in planning. I  also know from cocoa, that Openmath is their big
> new feature (and some other systems, for which I don't know how
> important it is for them). Of course I will further increase my
> contacts in the community. Together we should form a critical
> mass.
>

That is a good plan.

One of the original design goals of MathAction was to be able
to support a large number of different mathematical software
with the same user interface. OpenMath goes beyond that by
providing the means (in principle) to exchange mathematical
results between different programs. I would really like to
see such a thing work, even if not in 100% of cases.

I think Axiom provides a good test environment for OpenMath
precisely because of it's very general approach to static
typing of mathematical objects. I don't know of any other
CAS which does this so consistently.

\start
Date: Mon, 3 Oct 2005 23:31:53 -0400
From: Bill Page
To: Michael Brickenstein
Subject: RE: Openmath, Singular

Michael,

On October 3, 2005 10:38 PM I wrote:
> 
> One of the original design goals of MathAction was to be able
> to support a large number of different mathematical software
> with the same user interface. OpenMath goes beyond that by
> providing the means (in principle) to exchange mathematical
> results between different programs. I would really like to
> see such a thing work, even if not in 100% of cases.
> 

You might be interested to know that Martin Rubey has
already developed an experimental interface between PolyMake
and Axiom, although without the aid of OpenMath. See

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

Also it might be of some interest that MathAction supports
Reduce in addition of Axiom. Extensions to Reduce have been
developed for OpenMath, e.g.

http://www.bath.ac.uk/~masjhd/ReduceOpenMath/index.html

I think it would great to provide a OpenMath link between Axiom
and Reduce on MathAction.

\start
Date: Mon, 3 Oct 2005 23:53:47 -0400
From: Bill Page
To: Tony Hearn
Subject: RE: New Version of REDUCE 
Cc: Winfried Neun

Tony Hearn,

You will recall I am sure, that a little more than a year
ago, with your kind approval I installed Reduce on the
axiom-developer server. The axiom-developer server runs
the wiki-based web application that I call MathAction which
provides a web-based interface for both Axiom and Reduce.

Here is an updated URL for the web site:

http://wiki.axiom-developer.org

I have been reviewing my notes about Reduce on MathAction
and I see that the version we are running is the older
version 3.7. Perhaps through an oversight I apparently did
not receive the updated Reduce version 3.8 package that I
discussed with Winfried Neun. Would it be possible for me
to obtain the newer version for linux to install on the
axiom-developer server?

I am especially interested in installing version 3.8 because
of it's support for OpenMath. Recently I have become motivated
again to look at OpenMath and MathML support in both Axiom
and Reduce.

Kind Regards,
Bill Page.

> -----Original Message-----
> From: Winfried Neun [mailto:Winfried Neun] 
> Sent: August 10, 2004 5:23 AM
> To: Bill Page (E-mail)
> Cc: Tony Hearn
> Subject: Re: mathML, "bad(" problem, (was: Patch for rlfi)
> 
> Right,
> 
> You have got REDUCE 3.7. It might be useful to use a more recent
> patches file, but I think I will be able to distribute REDUCE 3.8
> for Linux this month, perhaps you just wait for it.
> 
> Winfried
> 
> Page, Bill wrote:
> 
> >When I start Reduce I see:
> >
> >Loading image file :/usr/local/reduce/lisp/psl/linux/red/reduce.img
> >REDUCE 3.7, 15-Apr-1999, patched to 14-Jun-2001 ...
> >
> >So I guess what Winfried gave me was really Reduce 3.7?
> >
> >  
> >
> >>-----Original Message-----
> >>From: Tony Hearn [mailto:hearn@rand.org]
> >>Sent: Monday, August 09, 2004 4:02 PM
> >>To: Bill Page (E-mail)
> >>Subject: Re: mathML, "bad(" problem, (was: Patch for rlfi) 
> >>
> >>
> >>You should work with Winfried on the MathML stuff --- he 
> >>wrote the code (but he may be on vacation now --- it's
> >>August, after all).
> >>
> >>As far as the version is concerned, there should be a banner 
> >>when you run it that tells you the version.  Otherwise, you
> >can say
> >>
> >>   lisp version!*;
> >>
> >>in REDUCE and it will tell you.
> >>
> >>    
> >>
> 

> -----Original Message-----
> From: Tony Hearn [mailto:hearn@rand.org] 
> Sent: July 22, 2004 6:58 PM
> To: Bill Page
> Cc: Winfried Neun; hearn@rand.org
> Subject: Re: New Version of REDUCE 
> 
> 
> > I would like to know your opinion regarding the possibility of 
> > including a web-based interface to REDUCE in our system. Would
> > the licensing conditions permit this?
> 
> Even though there is a (relatively) modest fee charged for 
> the distribution of REDUCE, it is "open source" in the sense 
> that all sources are distributed with the so-called 
> professional version.  So I would certainly encourage you to 
> develop such an interface --- there are no licensing 
> restrictions affecting this (assuming you don't include a 
> copy of REDUCE with your code!)
> 
> Winfried Neun Winfried Neun is the one who developed the 
> MathML interface, and he would be happy to work further with 
> you on your interface, as would I.  For starters, you 
> probably need a copy of the software.  Please tell Winfried 
> what platform you use, and he'll supply the appropriate version.
> 
> When things are working, we could put the code on the REDUCE 
> web site, or put a pointer there to wherever you have things stored.

\start
Date: Tue, 4 Oct 2005 00:23:30 -0400
From: Bill Page
To: Michael Brickenstein
Subject: RE: Openmath, Singular

Michael,

I have tried to build Singular from source on the axiom-
developer server but but after compiling a large part of
the system, the build terminates with the following error:

...
make[2]: Leaving directory `/home/page/Singular-3-0-0/modules/modgen'
for file in loctriv; do \
        if test -d ${file}; then \
          echo Directory ${file} exists! Ignoring ${file}; \
          echo Use make mod_clean or remove directory by hand; \
        else \
          ./modgen/modgen ${file}.mod >${file}.log ;\
        fi; \
done
for SUBDIR in  loctriv; \
do \
        if test -d ${SUBDIR}; then \
           echo make modules in ${SUBDIR}; \
           ( cd ${SUBDIR} && make ;) \
        fi;\
        if test ! -d ${SUBDIR}; then \
           echo directory ${SUBDIR} does not exist!; \
        fi;\
done
make modules in loctriv
make[2]: Entering directory `/home/page/Singular-3-0-0/modules/loctriv'
gcc -DNDEBUG -DBUILD_MODULE -I. -I/home/page/Singular-3-0-0/kernel
-I/home/page/Singular-3-0-0/Singular
-I/home/page/Singular-3-0-0/ix86-Linux/include -c -fPIC -DPIC loctriv.cc -o
loctriv.o
make[2]: Leaving directory `/home/page/Singular-3-0-0/modules/loctriv'
(cd modgen; make install)
make[2]: Entering directory `/home/page/Singular-3-0-0/modules/modgen'
../../Singular/mkinstalldirs /home/page/Singular-3-0-0/ix86-Linux
../../Singular/install-sh -c modgen
/home/page/Singular-3-0-0/ix86-Linux/modgen-3-0-0
rm -f /home/page/Singular-3-0-0/ix86-Linux/modgen
cd /home/page/Singular-3-0-0/ix86-Linux; ln -s modgen-3-0-0 modgen;\
if test ! -x /home/page/Singular-3-0-0/ix86-Linux/modgen; then \
        ln -s modgen-3-0-0 /home/page/Singular-3-0-0/ix86-Linux/modgen;\
fi
make[2]: Leaving directory `/home/page/Singular-3-0-0/modules/modgen'
for SUBDIR in  loctriv; \
do \
        echo make install in ${SUBDIR}; \
        ( cd ${SUBDIR} && make install;) || true; \
done
make install in loctriv
make[2]: Entering directory `/home/page/Singular-3-0-0/modules/loctriv'
/home/page/Singular-3-0-0/modules/mkinstalldirs
/home/page/Singular-3-0-0/ix86-Linux
/home/page/Singular-3-0-0/modules/mkinstalldirs
/home/page/Singular-3-0-0/ix86-Linux/MOD
/home/page/Singular-3-0-0/Singular/install-sh -c kstd.so
/home/page/Singular-3-0-0/ix86-Linux/MOD/kstd.so
install:  kstd.so does not exist
make[2]: Leaving directory `/home/page/Singular-3-0-0/modules/loctriv'
make[1]: Leaving directory `/home/page/Singular-3-0-0/modules'
------

The axiom-developer.org server is running linux RedHat 9.
I am using gcc --version 4.0.1. I downloaded the source via
wget from
http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/src/3-0-0/Singular-3-0
-0-9.tar.gz

First, I consulted the build instructions at:

http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/src/README

:( Note: The README.* files in the above source distribution appear
to be quite out of date. )

Then I used the following common commmands:

 tar xzvf Sing*
 cd Singular-3-0-0
 ./configure
 su
 make install

----------

Do you know why I might receive the message

"kstd.so does not exist"

after apparently building a large part of the system?

Who would you recommend I contact for help with this?

\start
Date: Tue, 4 Oct 2005 01:19:06 -0400
From: Bill Page
To: Tim Daly
Subject: Axiom Lisp API for OpenMath

Tim,

I searched through my source archives but I did not find the
file 'src/cslbase/openmath.c' referred to by Mike Dewar in the
email below. Apparently we need to write something analogous
for GCL to interface with the Open Math library in OMCv1.4a.tgz

OMCv1.4a.tgz is in the current zips directory. It compiles
but does not pass the make tests (maybe not significant as
implied by warning in the README).

Do you know where I can file src/cslbase/openmath.c?

Regards,
Bill Page.

--------

From: 	Mike Dewar
Subject: 	re: ... user interface issues.
Date: 	Tue, 1 Jul 2003 10:06:07 +0100

Oops, I think this is because Axiom isn't being built with the OpenMath
libraries from INRIA.  I took this out when passing the sources to Tim
because of licensing issues - there is a general free license but we
have access to the libraries under a different arrangement.  You can
download the libraries at http://www.openmath.org/software/OMCv1.4a.tgz
if you're interested, but you'll need to look at the appropriate part of
CCL (src/cslbase/openmath.c which Tim has) to work out what the Lisp API
should look like.

Mike.

On Thu, Jun 26, 2003 at 11:28:39AM +1000, Jason White wrote:
> Mike Dewar writes:
>  > On Wed, Jun 25, 2003 at 07:53:47PM +1000, Jason White wrote:
>  > > While on the subject of output formats, as a longer-term goal, MathML
>  > > would probably be a useful addition.
>  > I agree.  Actually we started including OpenMath (which in a way is a
>  > superset of MathML) and were planning to include MathML once it
>  > stabilised.
>  >
>  > G82328 (2) -> OMwrite sin(x)
>
> Interesting. Upon issuing this command under Tim's test release I get:
>
> (1) -> OMwrite sin(x)
> 
>    >> System error:
>    OM-STRINGTOSTRINGPTR is invalid as a function.
>
> protected-symbol-warn called with (NIL)
>
> Another item for the bug list?

\start
Date: Tue, 4 Oct 2005 07:28:13 +0200
From: Michael Brickenstein
To: Bill Page
Subject: Re: Openmath, Singular

Hello Bill!

I will forward the mail about the bug report to the singular mailing  
list (singular@mathematik.uni-kl.de).
But you shouldn't care about it, Singular should work fine without  
this dynamic module "kstd.so".
In fact, dynamic modules are quite new in Singular and still  
experimental.

The only problem which could arise: At the moment gcc-4.0.x does not  
support boost::python on my Mac, which is needed for the python  
interface, on which openmath depends.
So for that, it might me necessary to use a different compiler. But  
time will solve this, boost is one of the
projects with biggest compiler support.

The most important I wanted to write you is, that while you cannot  
use Singular directly on a python level, I can licence my python  
openmath library to you. At the moment, I did not yet decide for a  
certain licence. Using GPL would simplify things very much.

In principal however I tend to use a very liberal licence and have  
yet to check, if this would exclude me from using Singular (which is  
GPL), which I have strictly to avoid.

It is generic (doesn't depend on any CAS), uses only standard python  
libraries, is designed to be customizable (at least offers the  
possibility to improve this point), compact.

The limitations are: I have to clean up code and add some more  
documentations than "FIXME:" comments.
While there exists some Singular plugin and everything is strictly  
seperated, there does not exist a sophisticated plugin mechanism at  
the moment. Also, it does not yet provide network support.
The cleanup will need a little bit time.

Since I am in contact with SAGE, which also uses Python, the library  
could be the base for a common work, using the CAS as plugins, so it  
will be improved in time.  If also MathAction would use it, this  
would be a joy of my heart: I write my software for being used (very  
surprising). ;-)

\start
Date: Tue, 04 Oct 2005 05:45:59 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#213 No equality of operators which use dummy	variables] (nouveau) 

Unfortunately, axiom fails to recognize equality of some expressions like in
\begin{axiom}
x:=sum(1/i,i=1..m)/sum(1/i,i=1..m)
\end{axiom}

The reason is that the internal representation is different: 
\begin{axiom}
map(argument, kernels x)
\end{axiom}

\start
Date: Tue, 04 Oct 2005 07:36:46 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#211 Products are differentiated incorrectly] fix

Fortunately, a fix is quite easy, since we know how to differentiate
products according to Leibniz rule: Here is a patch to
'combfunc.spad.pamphlet' that also fixes some leftover problems with
differentiating sums without bounds and displaying sums and products
with and without bounds:

<a href="combfunc.spad.pamphlet.patch">combfunc.spad.pamphlet.patch</a>

\start
Date: Tue, 4 Oct 2005 08:29:17 -0400
From: Tim Daly
To: Bill Page
Subject: ccl/src/cslbase/openmath.c

/* openmath.c                                  Copyright (C) 1998 NAG Ltd. */

#ifdef OPENMATH

/*
 * Reading and writing of OpenMath objects, using the INRIA OpenMath library.
 * Developed as a deliverable of the OpenMath Project (ESPRIT Project 24969).
 *
 * Initial version: Vilya Harvey, Nov 24th, 1998.
 *
 * Note: to add this to CCL, the following files had to be modified:
 * Makefile
 * cslbase\entries.h
 * cslbase\externs.h
 * cslbase\restart.c
 * cclbase\exports.lsp
 *
 * Note: to make sure that the OpenMath support is compiled into CCL, the
 * symbol OPENMATH must be #defined.
 */

#include <stdarg.h>
#include <string.h>
#include <ctype.h>

#ifdef __WATCOMC__
#include <float.h>
#endif

#include "machine.h"
#include "tags.h"
#include "cslerror.h"
#include "externs.h"
#include "entries.h"
#include "arith.h"
#include "read.h"

#include <OM.h>
#include <OMconn.h>
#include <math.h>

#include "openmath.h"


#define OMCCL_ELEM_BITS	31					/* #bits in bignum element. */
#define OMCCL_MAX_BITS	15					/* Must be < OMCCL_ELEM_BITS */
#define OMCCL_MAX_VAL	(1 << OMCCL_MAX_BITS)
#define OMCCL_MAX_MASK	(OMCCL_MAX_VAL - 1)

#define OMCCL_INV_LOG_2	1.44269504			/* 1 / ln(2) */


/*
 * Error reporting macro. The status parameter should be of type OMstatus; the
 * return value is a Lisp_Object representing the appropriate error.
 */
#define om_error(status)		error(0, (int)(status) + 33)


/*
 * Local functions for dealing with property lists.
 */

Lisp_Object om_getLispProperty(Lisp_Object obj, Lisp_Object name);
Lisp_Object om_setLispProperty(Lisp_Object obj, Lisp_Object name, Lisp_Object val);


/*
 * External CCL functions.
 */
extern char *get_string_data(Lisp_Object name, char *why, int32 *l);


OMdev
om_toDev(Lisp_Object obj)
/* This routine converts a Lisp_Object to an OMdev. It does
 * not check that the object it is given actually *is* an
 * OMdev - that's the caller's responsibility.
 */
{
	OMdev dev;
	
	/* DEBUG */
	if (!is_bignum(obj)) {
		err_printf("[om_toDev] not a bignum!\n");
	}
	else {
		int blen = (bignum_length(obj) >> 2) - 1;
		if (blen != 1)
			err_printf("[om_toDev] bignum length is %d (should be 1)!\n", blen);
	}
	/* END DEBUG */
	
	if (!is_bignum(obj))
		return NULL;
	else if (((bignum_length(obj) >> 2) - 1) != 1)
		return NULL;
	dev = (OMdev) ( bignum_digits(obj)[0] );
	return dev;
}


Lisp_Object
om_fromDev(OMdev dev)
{
	Lisp_Object obj;
	obj = make_one_word_bignum((int32)dev);
	return obj;
}


OMstatus
om_toStatus(Lisp_Object obj)
{
	OMstatus status;
	if (!is_fixnum(obj))
		return OMinternalError;
	status = (OMstatus)( int_of_fixnum(obj) );
	return status;
}


Lisp_Object
om_fromStatus(OMstatus status)
{
	Lisp_Object obj;
	obj = fixnum_of_int((int32)status);
	return obj;
}


OMencodingType
om_toEncodingType(Lisp_Object obj)
{
	OMencodingType enc;
	if (!is_fixnum(obj))
		return OMencodingUnknown;
	enc = (OMencodingType)( int_of_fixnum(obj) );
	return enc;
}


Lisp_Object
om_fromEncodingType(OMencodingType enc)
{
	Lisp_Object obj;
	obj = fixnum_of_int((int32)enc);
	return obj;
}


char *
om_toBigNumStr(Lisp_Object num)
{
	static char hexdigit[] = "0123456789ABCDEF";
	char *str;
	int numDigits, digit;
	int bdigit, boffset;
	int i, j, val;
	int strPos;
	int leading;

	/* Determine the number of digits needed. */
	i = ((bignum_length(num) >> 2) - 1) * 31;
	numDigits = (i >> 2) + (((i & 0x3) != 0) ? 1 : 0);

	str = (char *)malloc((numDigits + 1) * sizeof(char));
	memset(str, 0, (numDigits + 1) * sizeof(char));

	strPos = 0;
	leading = 1;
	digit = 0;
	while (digit < numDigits) {
		i = (numDigits - digit - 1) << 2;
		bdigit = i / 31;
		boffset = i % 31;
		j = 31 - boffset;
		
		switch (j) {
		case 3:
			val = (bignum_digits(num)[bdigit] >> boffset) & 0x7;
			val |= ((bignum_digits(num)[bdigit+1] & 0x1) << 3);
			break;
		case 2:
			val = (bignum_digits(num)[bdigit] >> boffset) & 0x3;
			val |= ((bignum_digits(num)[bdigit+1] & 0x3) << 2);
			break;
		case 1:
			val = (bignum_digits(num)[bdigit] >> boffset) & 0x1;
			val |= ((bignum_digits(num)[bdigit+1] & 0x7) << 1);
			break;
		default:
			val = (bignum_digits(num)[bdigit] >> boffset) & 0xF;
			break;
		}
		
		str[strPos] = hexdigit[val];
		digit++;
		if (hexdigit[val] != '0' || !leading) {
			leading = 0;
			strPos++;
		}
	}

	return str;
}


Lisp_Object
om_fromBigNumStr(char *inData, int len, int sign, OMbigIntType fmt)
{
	Lisp_Object obj, radix, digit;
	int i;

	if (len == 0)
		return fixnum_of_int(0);
	else
		obj = fixnum_of_int(0);

	switch (fmt) {
	case OMbigIntBase10:
		radix = fixnum_of_int(10);
		break;
	case OMbigIntBase16:
		radix = fixnum_of_int(16);
		break;
	default:
		return om_error(OMinternalError);
	}

	for (i = 0; i < len; i++) {
		obj = times2(obj, radix);

		switch (fmt) {
		case OMbigIntBase10:
			digit = fixnum_of_int( (int)(inData[i] - '0') );
			break;
		case OMbigIntBase16:
			if (inData[i] >= 'a' && inData[i] <= 'f')
				digit = fixnum_of_int( (int)(inData[i] - 'a') + 10 );
			else if (inData[i] >= 'A' && inData[i] <= 'F')
				digit = fixnum_of_int( (int)(inData[i] - 'A') + 10 );
			else
				digit = fixnum_of_int( (int)(inData[i] - '0') );
			break;
		}

		obj = plus2(obj, digit);
	}

	if (sign < 0)
		obj = negateb(obj);

	return obj;
}


OMconn
om_toConn(Lisp_Object obj)
{
	OMconn conn;
	
	/* DEBUG */
	if (!is_bignum(obj)) {
		err_printf("[om_toConn] not a bignum!\n");
	}
	else {
		int blen = (bignum_length(obj) >> 2) - 1;
		if (blen != 1)
			err_printf("[om_toConn] bignum length is %d (should be 1)!\n", blen);
	}
	/* END DEBUG */
	
	if (!is_bignum(obj))
		return NULL;
	else if (((bignum_length(obj) >> 2) - 1) != 1)
		return NULL;
	conn = (OMconn)(bignum_digits(obj)[0]);
	return conn;
}


Lisp_Object
om_fromConn(OMconn conn)
{
	Lisp_Object obj;
	obj = make_one_word_bignum((int32)conn);
	return obj;
}


char **
om_toCString(Lisp_Object obj)
/* Converts a lisp object which wraps a C string into a C string (a char
 * pointer, where the memory block is allocated on the heap, outside of the
 * control of the CCL garbage collection). Does not check that the Lisp object
 * *is* a C string though.
 */
{
	char **pstr = NULL;
	
	/* DEBUG */
	if (!is_bignum(obj) && !stringp(obj)) {
		err_printf("[om_toCString] not a bignum or a string!\n");
	}
	else if (is_bignum(obj)) {
		int blen = (bignum_length(obj) >> 2) - 1;
		if (blen != 1)
			err_printf("[om_toCString] bignum length is %d (should be 1)!\n", blen);
	}
	/* END DEBUG */
	
	if (!is_bignum(obj) && !stringp(obj))
		return NULL;
	else if (is_bignum(obj)) {
		if (((bignum_length(obj) >> 2) - 1) != 1)
			return NULL;
		pstr = (char **)(bignum_digits(obj)[0]);
	}
	else {
		char *tmp = NULL;
		int len = 0;
		tmp = get_string_data(obj, "om_toCString", &len);
		tmp[len] = '\0';
		pstr = (char **)malloc(sizeof(char *));
		*pstr = strdup(tmp);
	}
	return pstr;
}


Lisp_Object
om_fromCString(char **str)
{
	Lisp_Object obj;
	obj = make_one_word_bignum((int32)str);
	return obj;
}


Lisp_Object
om_cStringFromLispString(Lisp_Object lstr)
{
	Lisp_Object cstr;
	cstr = om_fromCString(om_toCString(lstr));
	return cstr;
}


Lisp_Object
om_lispStringFromCString(Lisp_Object cstr)
{
	Lisp_Object lstr;
	char **pstr = om_toCString(cstr);
	lstr = make_string(*pstr);
	return lstr;
}


/*
 * Local functions for dealing with property lists.
 */

Lisp_Object
om_getLispProperty(Lisp_Object obj, Lisp_Object name)
{
	return get(obj, name, C_nil);
}


Lisp_Object
om_setLispProperty(Lisp_Object obj, Lisp_Object name, Lisp_Object val)
{
	return putprop(obj, name, val);
}


/*
 * Exposed OpenMath Device manipulation functions.
 */

Lisp_Object MS_CDECL
om_openFileDev(Lisp_Object nil, int nargs, ...)
/* Opens a file and creates an OpenMath device for it. The return value is the
 * LISP object which wraps the created device. The parameters are:
 *   fname	- string	- the name of the file to open.
 *   fmode	- string	- the mode, as passed to the fopen routine.
 *   fenc	- string	- the OpenMath encoding type of the file.
 */
{
	va_list args;
	Lisp_Object lname, lmode, lenc;
	char *fname, *fmode;
	OMencodingType fenc;
	FILE *f;
	OMdev dev;
	int32 len;
	Lisp_Object lispDev;

	CSL_IGNORE(nil);

	/* Unpack the parameters into Lisp_Objects. */
	argcheck(nargs, 3, "om_openFileDev");
	va_start(args, nargs);
	lname = va_arg(args, Lisp_Object);
	lmode = va_arg(args, Lisp_Object);
	lenc = va_arg(args, Lisp_Object);
	va_end(args);

	push3(lname, lmode, lenc);

	/* Convert the parameters into their C equivalents. */
	if (!is_vector(lname) || !(type_of_header(vechdr(lname)) == TYPE_STRING))
		return aerror("om_openFileDev");
	errexitn(3);
	fname = get_string_data(lname, "om_openFileDev", &len);
	errexitn(3);
	fname[len] = '\0';

	if (!is_vector(lmode) || !(type_of_header(vechdr(lmode)) == TYPE_STRING))
		return aerror("om_openFileDev");
	errexitn(3);
	fmode = get_string_data(lmode, "om_openFileDev", &len);
	errexitn(3);
	fmode[len] = '\0';

	if (!is_fixnum(lenc))
		return aerror("om_openFileDev");
	errexitn(3);
	/* This gets OMencodingTypes as an integer then casts it to OMencodingType.
	 * That may be a bit dodgy... */
	fenc = om_toEncodingType(lenc);

	pop3(lname, lmode, lenc);

	f = fopen(fname, fmode);
	if (f == NULL)
		return aerror("om_openFileDev: couldn't open named file!");

	/* Create an OpenMath device on the given file. */
	dev = OMmakeDevice(fenc, OMmakeIOFile(f));

	/* Wrap the OpenMath device in a LISP object and return it. */
	lispDev = om_fromDev(dev);

	return onevalue(lispDev);
}


Lisp_Object
om_openStringDev(Lisp_Object nil, Lisp_Object lstr, Lisp_Object lenc)
/* Creates an OpenMath string device on an existing string. The return value is
 * the LISP object which wraps the created device. The parameters are:
 *	lstr	- string	- The string to create the device on. This must be a C
						  string pointer wrapped in a Lisp object.
 *	lenc	- int		- The OpenMath encoding type of the string.
 */
{
	/* There may be a problem with the OM library directly accessing the string
	 * data of a Lisp_Object - see if there is a way around that (if it is a
	 * problem).
	 */

	char **pstr = NULL;
	OMencodingType enc;
	OMdev dev;
	Lisp_Object ldev;

	CSL_IGNORE(nil);
	push2(lstr, lenc);

	pstr = om_toCString(lstr);
	errexitn(2);

	enc = om_toEncodingType(lenc);
	errexitn(2);
	
	dev = OMmakeDevice(enc, OMmakeIOString(pstr));
	ldev = om_fromDev(dev);

	pop2(lstr, lenc);
	return onevalue(ldev);
}


Lisp_Object
om_closeDev(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;

	CSL_IGNORE(nil);
	push(ldev);

	dev = om_toDev(ldev);
	errexitn(1);
	OMcloseDevice(dev);

	pop(ldev);
	return lisp_true;
}


Lisp_Object
om_setDevEncoding(Lisp_Object nil, Lisp_Object ldev, Lisp_Object lenc)
{
	OMdev dev;
	OMencodingType enc;

	CSL_IGNORE(nil);
	push2(ldev, lenc);

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_setDevEncoding: invalid device");
	errexitn(2);

	if (!is_fixnum(lenc))
		return aerror("om_setDevEncoding: invalid encoding");
	errexitn(2);
	/* This gets OMencodingTypes as an integer then casts it to OMencodingType.
	 * That may be a bit dodgy... */
	enc = om_toEncodingType(lenc);
	errexitn(2);

	pop2(ldev, lenc);

	OMsetDeviceEncoding(dev, enc);
	return onevalue(om_fromDev(dev));
}


/*
 * Exposed OpenMath Connection manipulation functions.
 */


Lisp_Object
om_makeConn(Lisp_Object nil, Lisp_Object ltimeout)
{
	OMconn conn;
	int32 timeout;

	CSL_IGNORE(nil);
	push(ltimeout);

	if (!is_fixnum(ltimeout))
		return aerror("om_makeConn: timeout value must be a fixnum");
	errexitn(1);

	timeout = int_of_fixnum(ltimeout);
	errexitn(1);
	conn = OMmakeConn(timeout);

	pop(ltimeout);

	return onevalue(om_fromConn(conn));
}


Lisp_Object
om_closeConn(Lisp_Object nil, Lisp_Object lconn)
{
	OMconn conn;
	OMstatus status;

	CSL_IGNORE(nil);
	push(lconn);

	conn = om_toConn(lconn);
	errexitn(1);
	if (!conn)
		return aerror("om_toConn");
	errexitn(1);

	pop(lconn);

	status = OMconnClose(conn);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_getConnInDev(Lisp_Object nil, Lisp_Object lconn)
{
	OMconn conn;
	OMdev dev;

	CSL_IGNORE(nil);
	push(lconn);

	conn = om_toConn(lconn);
	errexitn(1);
	if (!conn)
		return aerror("om_toConn");
	errexitn(1);

	pop(lconn);

	dev = OMconnIn(conn);
	return onevalue(om_fromDev(dev));
}


Lisp_Object
om_getConnOutDev(Lisp_Object nil, Lisp_Object lconn)
{
	OMconn conn;
	OMdev dev;

	CSL_IGNORE(nil);
	push(lconn);

	conn = om_toConn(lconn);
	errexitn(1);
	if (!conn)
		return aerror("om_toConn");
	errexitn(1);

	pop(lconn);

	dev = OMconnOut(conn);
	return om_fromDev(dev);
}


/*
 * Exposed OpenMath client/server functions.
 */

Lisp_Object MS_CDECL
om_connectTCP(Lisp_Object nil, int nargs, ...)
{
	va_list args;
	Lisp_Object lconn, lhost, lport;
	OMconn conn;
	char *host = NULL;
	int32 hostlen;
	int32 port;
	OMstatus status;

	CSL_IGNORE(nil);

	/* Unpack the parameters into Lisp_Objects. */
	argcheck(nargs, 3, "om_connectTCP");
	va_start(args, nargs);
	lconn = va_arg(args, Lisp_Object);
	lhost = va_arg(args, Lisp_Object);
	lport = va_arg(args, Lisp_Object);
	va_end(args);

	push3(lconn, lhost, lport);

	/* Convert the parameters into their C equivalents. */
	conn = om_toConn(lconn);
	errexitn(3);
	if (!conn)
		return aerror("om_toConn");
	errexitn(3);
	
	if (!stringp(lhost))
		return aerror("om_connectTCP: host name must be a string");
	errexitn(3);
	host = get_string_data(lhost, "om_putString", &hostlen);
	errexitn(3);
	if (host != NULL)
		host[hostlen] = '\0';

	if (!is_fixnum(lport))
		return aerror("om_connectTCP: port number must be a fixnum");
	errexitn(3);
	port = int_of_fixnum(lport);
	errexitn(3);

	pop3(lconn, lhost, lport);

	status = OMconnTCP(conn, host, port);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_bindTCP(Lisp_Object nil, Lisp_Object lconn, Lisp_Object lport)
{
	OMconn conn;
	int32 port;
	OMstatus status;

	CSL_IGNORE(nil);
	push2(lconn, lport);

	conn = om_toConn(lconn);
	errexitn(2);
	if (!conn)
		return aerror("om_toConn");
	errexitn(2);

	if (!is_fixnum(lport))
		return aerror("om_bindTCP: port number must be a fixnum");
	errexitn(2);
	port = int_of_fixnum(lport);
	errexitn(2);

	pop2(lconn, lport);

	status = OMbindTCP(conn, port);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


/*
 * Exposed OpenMath Device output functions.
 */

Lisp_Object
om_putApp(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputApp(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putEndApp(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputEndApp(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putAtp(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputAtp(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putEndAtp(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputEndAtp(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putAttr(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputAttr(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putEndAttr(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputEndAttr(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putBind(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputBind(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putEndBind(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputEndBind(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putBVar(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputBVar(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putEndBVar(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputEndBVar(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putError(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputError(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putEndError(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputEndError(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putObject(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputObject(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putEndObject(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMputEndObject(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putInt(Lisp_Object nil, Lisp_Object ldev, Lisp_Object val)
/* This routine expects val to be a Lisp integer of some sort.
 * The decision of whether to put it as an int32 or a bigint
 * will be made by this routine.
 */
{
	OMdev dev;
	OMstatus status;
	int size, sign;
	char *data;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	if (!is_number(val) || is_float(val))
		return aerror("om_putInt");
	
	if (is_fixnum(val)) {
		int32 ival = int_of_fixnum(val);
		status = OMputInt32(dev, ival);
	}
	else {
		data = om_toBigNumStr(val);
		size = strlen(data);
		sign = minusp(val) ? -1 : 1;
		status = OMputBigInt(dev, data, size, sign, OMbigIntBase16);
		free(data);
	}

	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putFloat(Lisp_Object nil, Lisp_Object ldev, Lisp_Object val)
/* This routine expects val to be a real-valued number of some
 * sort (this includes floats, rationals, etc.) and puts it
 * out as an IEEE 64-bit floating point number.
 */
{
	/* TODO: check this generates correct output for all real numbers. */
	OMdev dev;
	OMstatus status;
	double fval;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	if (!is_number(val))
		return aerror("om_putFloat");

	fval = float_of_number(val);

	/* err_printf("[om-putFloat] fval = %.30lf\n", fval); */

	status = OMputFloat64(dev, &fval);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


Lisp_Object
om_putByteArray(Lisp_Object nil, Lisp_Object ldev, Lisp_Object val)
/* This routine expects val to be a Lisp vector of 8-bit values.
 */
{
	OMdev dev;
	OMstatus status;
	int32 len;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	if (!is_vector(val) || !(type_of_header(vechdr(val)) == TYPE_VEC8))
		return aerror("om_toDev");
	
	/* Get the length of the array. */
	len = length_of_header(val) - 4; /* is this correct??? */

	/* Write out the array data. */
	status = OMputByteArray(dev, ((char *)val - TAG_VECTOR + 4), len);
	if (status != OMsuccess) return om_error(status);
	else return lisp_true;
}


Lisp_Object
om_putVar(Lisp_Object nil, Lisp_Object ldev, Lisp_Object val)
/* This routine expects val to be a symbol.
 */
{
	OMdev dev;
	OMstatus status;
	char *name;
	int32 len;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	if (!is_symbol(val))
		return aerror("om_putVar");
	
	/* Do I need to free the memory for name myself? I don't know... */
	name = get_string_data(val, "om_putVar", &len);
	if (name == NULL)
		return om_error(OMinternalError);
	else {
		status = OMputVarN(dev, name, len);
		if (status != OMsuccess)
			return om_error(status);
		else
			return lisp_true;
	}
}


Lisp_Object
om_putString(Lisp_Object nil, Lisp_Object ldev, Lisp_Object val)
/* This routine expects val to be a Lisp string.
 */
{
	OMdev dev;
	OMstatus status;
	char *name;
	int32 len;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	if (!is_vector(val) || !(type_of_header(vechdr(val)) == TYPE_STRING))
		return aerror("om_putString");

	/* Do I need to free the memory for name myself? I don't know... */
	name = get_string_data(val, "om_putString", &len);
	if (name == NULL)
		return om_error(OMinternalError);
	else {
		status = OMputStringN(dev, name, len);
		if (status != OMsuccess)
			return om_error(status);
		else
			return lisp_true;
	}
}


Lisp_Object
om_putSymbol(Lisp_Object nil, Lisp_Object ldev, Lisp_Object val)
/* This routine expects val to be a cons cell where the first element is the
 * name of the content dictionary and the second (and final) element is the
 * name of the symbol.
 */
{
	Lisp_Object cdObj, nameObj;

	/* Check that the value passed in is in the correct format. */
	if (!is_cons(val))
		return aerror("om_putSymbol");

	/* Get the cd and name properties (checking that they are set). */
	cdObj = qcar(val);
	if (cdObj == nil)
		return aerror("om_putSymbol: The cd property was not set");
	nameObj = qcar(qcdr(val));
	if (nameObj == nil)
		return aerror("om_putSymbol: The name property was not set");

	/* Invoke the verbose form of the putSymbol routine to output the data. */
	return om_putSymbol2(nil, 3, ldev, cdObj, nameObj);
}


Lisp_Object MS_CDECL
om_putSymbol2(Lisp_Object nil, int nargs, ...)
/*
 * A different form of putSymbol, where the cd and symbol names are given as strings.
 * The parameters are: (om-putSymbol omdevice "cdname" "symbolname")
 */
{
	va_list args;
	Lisp_Object ldev;
	Lisp_Object lcd, lname;
	OMdev dev;
	char *cd, *name;
	int32 cdLen, nameLen;
	OMstatus status;

	/* Get the arguments from the arglist. */
	argcheck(nargs, 3, "om_putSymbol2");
	va_start(args, nargs);
	ldev = va_arg(args, Lisp_Object);
	lcd = va_arg(args, Lisp_Object);
	lname = va_arg(args, Lisp_Object);
	va_end(args);

	/* err_printf("[om_putSymbol2] about to convert params to C equivalents...\n"); */
	
	/* Convert the parameters into their C equivalents. */
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	if (!is_vector(lcd) || !(type_of_header(vechdr(lcd)) == TYPE_STRING))
		return aerror("om_putSymbol2");
	cd = get_string_data(lcd, "om_putSymbol2", &cdLen);
	if (cd == NULL) {
		status = OMinternalError;
		return om_error(status);
	}

	/* err_printf("[om_putSymbol2] converted cd name (%s)\n", cd); */

	if (!is_vector(lname) || !(type_of_header(vechdr(lname)) == TYPE_STRING))
		return aerror("om_putSymbol2");
	name = get_string_data(lname, "om_putSymbol2", &nameLen);
	if (name == NULL) {
		status = OMinternalError;
		return om_error(status);
	}

	/* err_printf("[om_putSymbol2] converted symbol name (%s)\n", name); */

	/* Now write out the symbol. */
	status = OMputSymbolN(dev, cd, cdLen, name, nameLen);
	if (status != OMsuccess)
		return om_error(status);
	else
		return lisp_true;
}


/*
 * OpenMath input routines.
 */

Lisp_Object
om_getApp(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetApp(dev);
	if (status != OMsuccess)
		return om_error(status);
	else 
		return make_undefined_symbol("OMA");
}


Lisp_Object
om_getEndApp(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetEndApp(dev);
	if (status != OMsuccess)
		return om_error(status);
	else 
		return make_undefined_symbol("OMA-END");
}


Lisp_Object
om_getAtp(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetAtp(dev);
	if (status != OMsuccess)
		return om_error(status);
	else 
		return make_undefined_symbol("OMATP");
}


Lisp_Object
om_getEndAtp(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetEndAtp(dev);
	if (status != OMsuccess)
		return om_error(status);
	else 
		return make_undefined_symbol("OMATP-END");
}


Lisp_Object
om_getAttr(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetAttr(dev);
	if (status != OMsuccess)
		return om_error(status);
	else 
		return make_undefined_symbol("OMATTR");
}


Lisp_Object
om_getEndAttr(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetEndAttr(dev);
	if (status != OMsuccess)
		return om_error(status);
	else 
		return make_undefined_symbol("OMATTR-END");
}


Lisp_Object
om_getBind(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");
	
	status = OMgetBind(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return make_undefined_symbol("OMBIND");
}


Lisp_Object
om_getEndBind(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetEndBind(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return make_undefined_symbol("OMBIND-END");
}


Lisp_Object
om_getBVar(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetBVar(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return make_undefined_symbol("OMBVAR");
}


Lisp_Object
om_getEndBVar(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetEndBVar(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return make_undefined_symbol("OMBVAR-END");
}


Lisp_Object
om_getError(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetError(dev);
	if (status != OMsuccess)
		return om_error(status);
	else 
		return make_undefined_symbol("OME");
}


Lisp_Object
om_getEndError(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetEndError(dev);
	if (status != OMsuccess)
		return om_error(status);
	else 
		return make_undefined_symbol("OME-END");
}


Lisp_Object
om_getObject(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetObject(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return make_undefined_symbol("OMOBJ");
}


Lisp_Object
om_getEndObject(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	
	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetEndObject(dev);
	if (status != OMsuccess)
		return om_error(status);
	else
		return make_undefined_symbol("OMOBJ-END");
}


Lisp_Object
om_getInt(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	OMtokenType ttype;
	Lisp_Object obj;

	dev = om_toDev(ldev);
	if (!dev)
		return aerror("om_toDev");

	status = OMgetType(dev, &ttype);
	if (status == OMsuccess) {
		switch (ttype) {
			case OMtokenInt32:
			{
				int32 val;
				status = OMgetInt32(dev, &val);
				if (status == OMsuccess) {
					/* If none of the top 4 bits are set, we can make this a
					 * fixnum */
					/* On second thoughts, the top bit is the sign, and the <<
					 * operation is sign preserving (I believe), so we only
					 * need to check bits 28-30. */
					if ((val & 0x70000000) == 0)
						obj = fixnum_of_int(val);
					else
						obj = make_one_word_bignum(val);
				}
				break;
			}
			case OMtokenBigInt:
			{
				/* TODO: This is broken. Fix it. */
				char *data;
				int len, sign;
				OMbigIntType fmt;

				status = OMgetBigInt(dev, &data, &len, &sign, &fmt);
				if (status == OMsuccess)
					obj = om_fromBigNumStr(data, len, sign, fmt);
				free(data);
				break;
			}
			default:
			{
				obj = om_error(OMmalformedInput);
				break;
			}
		}
	}
	else obj = om_error(status);

	return onevalue(obj);
}


Lisp_Object
om_getFloat(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	OMtokenType ttype;
	double val;

	dev = om_toDev(ldev);
	if (dev == NULL)
		return aerror("om_toDev");

	status = OMgetType(dev, &ttype);
	if (status == OMsuccess) {
		status = OMgetFloat64(dev, &val);
		if (status == OMsuccess) {
			/* err_printf("[om_getFloat] fval = %.30lf\n", val); */
			return make_boxfloat(val, TYPE_DOUBLE_FLOAT);
		}
		else
			return om_error(status);
	}
	else return om_error(status);
}


Lisp_Object
om_getByteArray(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	int len;
	Lisp_Object obj;

	dev = om_toDev(ldev);
	if (dev == NULL)
		return aerror("om_toDev");
	
	status = OMgetLength(dev, &len);
	if (status != OMsuccess)
		return om_error(status);
	else {
		/* I hope this is right... */
		obj = getvector(TAG_VECTOR, TYPE_VEC8, len + 4);
		status = OMgetByteArrayN(dev, ((char *)obj - TAG_VECTOR + 4), len);
		if (status != OMsuccess)
			return om_error(status);
		else
			return obj;
	}
}


Lisp_Object
om_getVar(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	char *var;
	Lisp_Object obj;

	dev = om_toDev(ldev);
	if (dev == NULL)
		return aerror("om_toDev");

	status = OMgetVar(dev, &var);
	if (status != OMsuccess)
		return om_error(status);
	else {
		obj = make_symbol(var, 2, /* do not convert name to upper case */
			undefined1, undefined2, undefinedn);
		free(var);
		return obj;
	}
}


Lisp_Object
om_getString(Lisp_Object nil, Lisp_Object ldev)
{
	OMdev dev;
	OMstatus status;
	char *str;
	Lisp_Object obj;

	dev = om_toDev(ldev);
	if (dev == NULL)
		return aerror("om_toDev");

	status = OMgetString(dev, &str);
	if (status != OMsuccess)
		return om_error(status);
	else {
		obj = make_string(str);
		free(str);
		return obj;
	}
}


Lisp_Object
om_getSymbol(Lisp_Object nil, Lisp_Object ldev)
/* This returns the Lisp symbol OMS, with a cd property and a name property set
 * to appropriate string values.
 */
{
  OMdev dev;
  OMstatus status;
  char *cd, *name;
  int cdLen, nameLen;
  Lisp_Object cdstr, namestr, obj;

  CSL_IGNORE(nil);
  push(ldev);

  dev = om_toDev(ldev);
  errexitn(1);
  if (dev == NULL)
    return aerror("om_toDev");
  errexitn(1);

  pop(ldev);

  status = OMgetSymbolLength(dev, &cdLen, &nameLen);
  if (status != OMsuccess)
    return om_error(status);
  cd = (char *)malloc(sizeof(char) * (cdLen + 1));
  name = (char *)malloc(sizeof(char) * (nameLen + 1));
  if (cd == NULL || name == NULL) {
    if (cd != NULL) free(cd);
    else if (name != NULL) free(name);
    return om_error(OMinternalError);
  }
  cd[cdLen] = '\0';
  name[nameLen] = '\0';

  status = OMgetSymbolN(dev, cd, cdLen, name, nameLen);
  if (status != OMsuccess)
    obj = om_error(status);
  else {
    cdstr = make_string(cd);
    namestr = make_string(name);
    /* FIXME: is this needed?  push2(cdstr, namestr);*/
    obj = cons(cdstr, cons(namestr, C_nil));
  }

  free(cd);
  free(name);
  /*return onevalue(obj);*/
  return obj;
}


#define om_errmsg0(msg)			\
	err_printf("[om_getType] %s\n", msg)
#define om_errmsg1(msg,a1)		\
	err_printf("[om_getType] %s%s\n", msg,a1)
#define om_errmsg2(msg,a1,a2)	\
	err_printf("[om_getType] %s%s%s\n", msg,a1,a2)


Lisp_Object
om_getType(Lisp_Object nil, Lisp_Object ldev)
{
	static char *typenames[] = {
		"OMtokenApp",		"OMtokenEndApp",
		"OMtokenAtp",		"OMtokenEndAtp",
		"OMtokenAttr",		"OMtokenEndAttr",
		"OMtokenBind",		"OMtokenEndBind",
		"OMtokenBVar",		"OMtokenEndBVar",
		"OMtokenError",		"OMtokenEndError",
		"OMtokenObject",	"OMtokenEndObject",
		"OMtokenInt",
		"OMtokenFloat",
		"OMtokenByteArray",
		"OMtokenVar",
		"OMtokenString",
		"OMtokenSymbol"
	};
	
	OMdev dev;
	OMstatus status;
	OMtokenType ttype;
	char *typename;
	Lisp_Object obj;

	dev = om_toDev(ldev);
	if (dev == NULL)
		return aerror("om_toDev");

	status = OMgetType(dev, &ttype);
	if (status != OMsuccess)
		return om_error(status);
	else {
		switch (ttype) {
			case OMtokenApp:		typename = typenames[0];	break;
			case OMtokenEndApp:		typename = typenames[1];	break;
			case OMtokenAtp:		typename = typenames[2];	break;
			case OMtokenEndAtp:		typename = typenames[3];	break;
			case OMtokenAttr:		typename = typenames[4];	break;
			case OMtokenEndAttr:	        typename = typenames[5];	break;
			case OMtokenBind:		typename = typenames[6];	break;
			case OMtokenEndBind:	        typename = typenames[7];	break;
			case OMtokenBVar:		typename = typenames[8];	break;
			case OMtokenEndBVar:	        typename = typenames[9];	break;
			case OMtokenError:		typename = typenames[10];	break;
			case OMtokenEndError:	        typename = typenames[11];	break;
			case OMtokenObject:		typename = typenames[12];	break;
			case OMtokenEndObject:	        typename = typenames[13];	break;
			case OMtokenInt32:		typename = typenames[14];	break;
			case OMtokenBigInt:		typename = typenames[14];	break;
			case OMtokenFloat64:	        typename = typenames[15];	break;
			case OMtokenByteArray:	        typename = typenames[16];	break;
			case OMtokenVar:		typename = typenames[17];	break;
			case OMtokenString:		typename = typenames[18];	break;
			case OMtokenSymbol:		typename = typenames[19];	break;
		}

		obj = make_undefined_symbol(typename);
		return obj;
	}
}


Lisp_Object
om_stringToStringPtr(Lisp_Object nil, Lisp_Object lstr)
{
	return om_cStringFromLispString(lstr);
}


Lisp_Object
om_stringPtrToString(Lisp_Object nil, Lisp_Object lpstr)
{
	return om_lispStringFromCString(lpstr);
}


setup_type const om_setup[] = {
	/* LISP Name */			/* Unary */			/* Binary */		/* Nary */
	{"om-openFileDev",		wrong_no_3a,		wrong_no_3b,		om_openFileDev},
	{"om-openStringDev",            too_few_2,		om_openStringDev,	wrong_no_2},
	{"om-closeDev",			om_closeDev,		too_many_1,		wrong_no_1},
	{"om-setDevEncoding",	        too_few_2,		om_setDevEncoding,	wrong_no_2},

	{"om-makeConn",			om_makeConn,		too_many_1,		wrong_no_1},
	{"om-closeConn",		om_closeConn,		too_many_1,		wrong_no_1},
	{"om-getConnInDev",		om_getConnInDev,	too_many_1,		wrong_no_1},
	{"om-getConnOutDev",	        om_getConnOutDev,	too_many_1,		wrong_no_1},

	{"om-connectTCP",		wrong_no_3a,		wrong_no_3b,		om_connectTCP},
	{"om-bindTCP",			too_few_2,		om_bindTCP,		wrong_no_2},

	{"om-putApp",			om_putApp,		too_many_1,		wrong_no_1},
	{"om-putEndApp",		om_putEndApp,		too_many_1,		wrong_no_1},
	{"om-putAtp",			om_putAtp,		too_many_1,		wrong_no_1},
	{"om-putEndAtp",		om_putEndAtp,		too_many_1,		wrong_no_1},
	{"om-putAttr",			om_putAttr,		too_many_1,		wrong_no_1},
	{"om-putEndAttr",		om_putEndAttr,		too_many_1,		wrong_no_1},
	{"om-putBind",			om_putBind,		too_many_1,		wrong_no_1},
	{"om-putEndBind",		om_putEndBind,		too_many_1,		wrong_no_1},
	{"om-putBVar",			om_putBVar,		too_many_1,		wrong_no_1},
	{"om-putEndBVar",		om_putEndBVar,		too_many_1,		wrong_no_1},
	{"om-putError",			om_putError,		too_many_1,		wrong_no_1},
	{"om-putEndError",		om_putEndError,		too_many_1,		wrong_no_1},
	{"om-putObject",		om_putObject,		too_many_1,		wrong_no_1},
	{"om-putEndObject",		om_putEndObject,	too_many_1,		wrong_no_1},

	{"om-putInt",			too_few_2,		om_putInt,		wrong_no_2},
	{"om-putFloat",			too_few_2,		om_putFloat,		wrong_no_2},
	{"om-putByteArray",		too_few_2,		om_putByteArray,	wrong_no_2},
	{"om-putVar",			too_few_2,		om_putVar,		wrong_no_2},
	{"om-putString",		too_few_2,		om_putString,		wrong_no_2},
	{"om-putSymbol",		too_few_2,		om_putSymbol,		om_putSymbol2},

	{"om-getApp",			om_getApp,		too_many_1,		wrong_no_1},
	{"om-getEndApp",		om_getEndApp,		too_many_1,		wrong_no_1},
	{"om-getAtp",			om_getAtp,		too_many_1,		wrong_no_1},
	{"om-getEndAtp",		om_getEndAtp,		too_many_1,		wrong_no_1},
	{"om-getAttr",			om_getAttr,		too_many_1,		wrong_no_1},
	{"om-getEndAttr",		om_getEndAttr,		too_many_1,		wrong_no_1},
	{"om-getBind",			om_getBind,		too_many_1,		wrong_no_1},
	{"om-getEndBind",		om_getEndBind,		too_many_1,		wrong_no_1},
	{"om-getBVar",			om_getBVar,		too_many_1,		wrong_no_1},
	{"om-getEndBVar",		om_getEndBVar,		too_many_1,		wrong_no_1},
	{"om-getError",			om_getError,		too_many_1,		wrong_no_1},
	{"om-getendError",		om_getEndError,		too_many_1,		wrong_no_1},
	{"om-getObject",		om_getObject,		too_many_1,		wrong_no_1},
	{"om-getEndObject",		om_getEndObject,	too_many_1,		wrong_no_1},

	{"om-getInt",			om_getInt,		too_many_1,		wrong_no_1},
	{"om-getFloat",			om_getFloat,		too_many_1,		wrong_no_1},
	{"om-getByteArray",		om_getByteArray,	too_many_1,		wrong_no_1},
	{"om-getVar",			om_getVar,		too_many_1,		wrong_no_1},
	{"om-getString",		om_getString,		too_many_1,		wrong_no_1},
	{"om-getSymbol",		om_getSymbol,		too_many_1,		wrong_no_1},

	{"om-getType",			om_getType,		too_many_1,		wrong_no_1},

	{"om-stringToStringPtr",     om_stringToStringPtr,      too_many_1,		wrong_no_1},
	{"om-stringPtrToString",     om_stringPtrToString,      too_many_1,		wrong_no_1},

	{NULL,	0,	0,	0}
};

#endif /* OPENMATH */

\start
Date: Tue, 4 Oct 2005 14:38:34 +0200
From: Martin Rubey
To: Tim Daly
Subject: patch for combfunc.spad.pamphlet

Dear Tim,

it'd be nice if the attached patch would go in the next release. It fixes a bug
in the differentiation of products and sums and a display bug concerning sums
and products without bounds.


--XLyDQVDl0e
	filename="combfunc.spad.pamphlet.patch"

KioqIC9ob21lL3J1YmV5L3RtcC9jb21iZnVuYy5zcGFkLnBhbXBobGV0fgkyMDA1LTEwLTAzIDE2
OjA2OjE5LjAwMDAwMDAwMCArMDIwMAotLS0gY29tYmZ1bmMuc3BhZC5wYW1waGxldAkyMDA1LTEw
LTA0IDE0OjExOjEzLjAwMDAwMDAwMCArMDIwMAoqKioqKioqKioqKioqKioKKioqIDEzMCwxMzYg
KioqKgotLS0gMTMwLDEzOCAtLS0tCiAgICAgIGlkc3VtICAgICA6IExpc3QgRiAtPiBGCiAgICAg
IGlwcm9kICAgICA6IExpc3QgRiAtPiBGCiAgICAgIGlkcHJvZCAgICA6IExpc3QgRiAtPiBGCisg
ICAgIGRzdW0gICAgICA6IExpc3QgRiAtPiBPCiAgICAgIGRkc3VtICAgICA6IExpc3QgRiAtPiBP
CisgICAgIGRwcm9kICAgICA6IExpc3QgRiAtPiBPCiAgICAgIGRkcHJvZCAgICA6IExpc3QgRiAt
PiBPCiAgICAgIGZvdXJ0aCAgICA6IExpc3QgRiAtPiBGCiAgICAgIGR2cG93MSAgICA6IExpc3Qg
RiAtPiBGCioqKioqKioqKioqKioqKgoqKiogMTM4LDE1MCAqKioqCiAgICAgIHN1bW1hbmQgICA6
IExpc3QgRiAtPiBGCiAgICAgIGR2c3VtICAgICA6IChMaXN0IEYsIFNFKSAtPiBGCiAgICAgIGR2
ZHN1bSAgICA6IChMaXN0IEYsIFNFKSAtPiBGCiAgICAgIGZhY3RzICAgICA6IChGLCBMaXN0IFNF
KSAtPiBGCiAgICAgIEsyZmFjdCAgICA6IChLLCBMaXN0IFNFKSAtPiBGCiAgICAgIHNtcGZhY3Qg
ICA6IChTTVAsIExpc3QgU0UpIC0+IEYKICAKICAgICAgZHVtbXkgPT0gbmV3KCkkU0UgOjogRgog
IEAKLSAKICBUaGlzIG1hY3JvIHdpbGwgYmUgdXNlZCBpbiBbW3Byb2R1Y3RdXSBhbmQgW1tzdW1t
YXRpb25dXSwgYm90aCB0aGUgJDUkIGFuZCAkMyQKICBhcmd1bWVudCBmb3Jtcy4gSXQgaXMgdXNl
ZCB0byBpbnRyb2R1Y2UgYSBkdW1teSB2YXJpYWJsZSBpbiBwbGFjZSBvZiB0aGUKICBzdW1tYXRp
b24gaW5kZXggd2l0aGluIHRoZSBzdW1tYW5kcy4gVGhpcyBpbiB0dXJuIGlzIG5lY2Vzc2FyeSB0
byBrZWVwIHRoZQotLS0gMTQwLDE1MyAtLS0tCiAgICAgIHN1bW1hbmQgICA6IExpc3QgRiAtPiBG
CiAgICAgIGR2c3VtICAgICA6IChMaXN0IEYsIFNFKSAtPiBGCiAgICAgIGR2ZHN1bSAgICA6IChM
aXN0IEYsIFNFKSAtPiBGCisgICAgIGR2cHJvZCAgICA6IChMaXN0IEYsIFNFKSAtPiBGCisgICAg
IGR2ZHByb2QgICA6IChMaXN0IEYsIFNFKSAtPiBGCiAgICAgIGZhY3RzICAgICA6IChGLCBMaXN0
IFNFKSAtPiBGCiAgICAgIEsyZmFjdCAgICA6IChLLCBMaXN0IFNFKSAtPiBGCiAgICAgIHNtcGZh
Y3QgICA6IChTTVAsIExpc3QgU0UpIC0+IEYKICAKICAgICAgZHVtbXkgPT0gbmV3KCkkU0UgOjog
RgogIEAKICBUaGlzIG1hY3JvIHdpbGwgYmUgdXNlZCBpbiBbW3Byb2R1Y3RdXSBhbmQgW1tzdW1t
YXRpb25dXSwgYm90aCB0aGUgJDUkIGFuZCAkMyQKICBhcmd1bWVudCBmb3Jtcy4gSXQgaXMgdXNl
ZCB0byBpbnRyb2R1Y2UgYSBkdW1teSB2YXJpYWJsZSBpbiBwbGFjZSBvZiB0aGUKICBzdW1tYXRp
b24gaW5kZXggd2l0aGluIHRoZSBzdW1tYW5kcy4gVGhpcyBpbiB0dXJuIGlzIG5lY2Vzc2FyeSB0
byBrZWVwIHRoZQoqKioqKioqKioqKioqKioKKioqIDE1NSwxNjcgKioqKgogIHByb2R1Y3QuCiAg
CiAgTm90ZSB0aGF0IHVwIHRvIFtbcGF0Y2gtLTI1XV0gdGhpcyB1c2VkIHRvIHJlYWQKLSAKICBc
YmVnaW57dmVyYmF0aW19CiAgICAgIGR1bW15IDo9IG5ldygpJFNFIDo6IEYKICBcZW5ke3ZlcmJh
dGltfQotIAogIHRodXMgaW50cm9kdWNpbmcgdGhlIHNhbWUgZHVtbXkgdmFyaWFibGUgZm9yIGFs
bCBwcm9kdWN0cyBhbmQgc3VtbWF0aW9ucywgd2hpY2gKISBjYXVzZWQgbmVzdGVkIHByb2R1Y3Rz
IGFuZCBzdW1tYXRpb25zIGZhaWwuIChJc3N1ZX5cIzcyKQogIAogIDw8cGFja2FnZSBDT01CRiBD
b21iaW5hdG9yaWFsRnVuY3Rpb24+Pj0KICAgICAgb3BmYWN0ICA6PSBvcGVyYXRvcigiZmFjdG9y
aWFsIjo6U3ltYm9sKSRDb21tb25PcGVyYXRvcnMKLS0tIDE1OCwxNjggLS0tLQogIHByb2R1Y3Qu
CiAgCiAgTm90ZSB0aGF0IHVwIHRvIFtbcGF0Y2gtLTI1XV0gdGhpcyB1c2VkIHRvIHJlYWQKICBc
YmVnaW57dmVyYmF0aW19CiAgICAgIGR1bW15IDo9IG5ldygpJFNFIDo6IEYKICBcZW5ke3ZlcmJh
dGltfQogIHRodXMgaW50cm9kdWNpbmcgdGhlIHNhbWUgZHVtbXkgdmFyaWFibGUgZm9yIGFsbCBw
cm9kdWN0cyBhbmQgc3VtbWF0aW9ucywgd2hpY2gKISBjYXVzZWQgbmVzdGVkIHByb2R1Y3RzIGFu
ZCBzdW1tYXRpb25zIHRvIGZhaWwuIChJc3N1ZX5cIzcyKQogIAogIDw8cGFja2FnZSBDT01CRiBD
b21iaW5hdG9yaWFsRnVuY3Rpb24+Pj0KICAgICAgb3BmYWN0ICA6PSBvcGVyYXRvcigiZmFjdG9y
aWFsIjo6U3ltYm9sKSRDb21tb25PcGVyYXRvcnMKKioqKioqKioqKioqKioqCioqKiAyMTksMjMz
ICoqKioKICAgICAgICBvcHN1bSBbZXZhbCh4LCBrIDo9IGtlcm5lbChpKSRLLCBkbSksIGRtLCBr
OjpGXQogIAogIEAKLSAKICBUaGVzZSB0d28gb3BlcmF0aW9ucyByZXR1cm4gdGhlIHByb2R1Y3Qg
b3IgdGhlIHN1bSBhcyB1bmV2YWx1YXRlZCBvcGVyYXRvcnMuIEEKICBkdW1teSB2YXJpYWJsZSBp
cyBpbnRyb2R1Y2VkIHRvIG1ha2UgdGhlIGluZGV4aW5nIHZhcmlhYmxlIFxscSBsb2NhbFxycS4K
ICAKICA8PHBhY2thZ2UgQ09NQkYgQ29tYmluYXRvcmlhbEZ1bmN0aW9uPj49CiAgICAgIGR2c3Vt
KGwsIHgpID09CiEgICAgICAgayAgOj0gcmV0cmFjdChzZWNvbmQgbClASwohICAgICAgIGRpZmZl
cmVudGlhdGUodGhpcmQgbCwgeCkgKiBzdW1tYW5kIGwKISAgICAgICAgICAgKyBvcHN1bSBbZGlm
ZmVyZW50aWF0ZShmaXJzdCBsLCB4KSwgc2Vjb25kIGwsIHRoaXJkIGxdCiAgCiAgICAgIGR2ZHN1
bShsLCB4KSA9PQogICAgICAgIHggPSByZXRyYWN0KHkgOj0gdGhpcmQgbClAU0UgPT4gMAotLS0g
MjIwLDIzMSAtLS0tCiAgICAgICAgb3BzdW0gW2V2YWwoeCwgayA6PSBrZXJuZWwoaSkkSywgZG0p
LCBkbSwgazo6Rl0KICAKICBACiAgVGhlc2UgdHdvIG9wZXJhdGlvbnMgcmV0dXJuIHRoZSBwcm9k
dWN0IG9yIHRoZSBzdW0gYXMgdW5ldmFsdWF0ZWQgb3BlcmF0b3JzLiBBCiAgZHVtbXkgdmFyaWFi
bGUgaXMgaW50cm9kdWNlZCB0byBtYWtlIHRoZSBpbmRleGluZyB2YXJpYWJsZSBcbHEgbG9jYWxc
cnEuCiAgCiAgPDxwYWNrYWdlIENPTUJGIENvbWJpbmF0b3JpYWxGdW5jdGlvbj4+PQogICAgICBk
dnN1bShsLCB4KSA9PQohICAgICAgIG9wc3VtIFtkaWZmZXJlbnRpYXRlKGZpcnN0IGwsIHgpLCBz
ZWNvbmQgbCwgdGhpcmQgbF0KICAKICAgICAgZHZkc3VtKGwsIHgpID09CiAgICAgICAgeCA9IHJl
dHJhY3QoeSA6PSB0aGlyZCBsKUBTRSA9PiAwCioqKioqKioqKioqKioqKgoqKiogMjM4LDI0OSAq
KioqCiAgICAgICAgICBvcGRzdW0gW2RpZmZlcmVudGlhdGUoZmlyc3QgbCwgeCksIHNlY29uZCBs
LCB5LCBnLCBoXQogIAogIEAKISAKISBUaGUgYWJvdmUgb3BlcmF0aW9uIGltcGxlbWVudHMgZGlm
ZmVyZW50aWF0aW9uIG9mIHN1bXMgd2l0aCBib3VuZHMuIE5vdGUgdGhhdAohIHRoZSBmdW5jdGlv
bgohIAogICQkblxtYXBzdG9cc3VtX3trPTF9Xm4gZihrLG4pJCQKLSAKICBpcyB3ZWxsIGRlZmlu
ZWQgb25seSBmb3IgaW50ZWdyYWwgdmFsdWVzIG9mICRuJCBncmVhdGVyIHRoYW4gb3IgZXF1YWwg
dG8gemVyby4KICBUaGVyZSBpcyBub3QgZXZlbiBjb25zZW5zdXMgaG93IHRvIGRlZmluZSB0aGlz
IGZ1bmN0aW9uIGZvciAkbjwwJC4gVGh1cywgaXQgaXMKICBub3QgZGlmZmVyZW50aWFibGUuIFRo
ZXJlZm9yZSwgd2UgbmVlZCB0byBjaGVjayB3aGV0aGVyIHdlIGVycm9uZW91c2x5IGFyZQotLS0g
MjM2LDI0NCAtLS0tCiAgICAgICAgICBvcGRzdW0gW2RpZmZlcmVudGlhdGUoZmlyc3QgbCwgeCks
IHNlY29uZCBsLCB5LCBnLCBoXQogIAogIEAKISBUaGUgYWJvdmUgdHdvIG9wZXJhdGlvbnMgaW1w
bGVtZW50IGRpZmZlcmVudGlhdGlvbiBvZiBzdW1zIHdpdGggYW5kIHdpdGhvdXQKISBib3VuZHMu
IE5vdGUgdGhhdCB0aGUgZnVuY3Rpb24KICAkJG5cbWFwc3RvXHN1bV97az0xfV5uIGYoayxuKSQk
CiAgaXMgd2VsbCBkZWZpbmVkIG9ubHkgZm9yIGludGVncmFsIHZhbHVlcyBvZiAkbiQgZ3JlYXRl
ciB0aGFuIG9yIGVxdWFsIHRvIHplcm8uCiAgVGhlcmUgaXMgbm90IGV2ZW4gY29uc2Vuc3VzIGhv
dyB0byBkZWZpbmUgdGhpcyBmdW5jdGlvbiBmb3IgJG48MCQuIFRodXMsIGl0IGlzCiAgbm90IGRp
ZmZlcmVudGlhYmxlLiBUaGVyZWZvcmUsIHdlIG5lZWQgdG8gY2hlY2sgd2hldGhlciB3ZSBlcnJv
bmVvdXNseSBhcmUKKioqKioqKioqKioqKioqCioqKiAyNzUsMjg3ICoqKioKLS0tIDI3MCwzNTUg
LS0tLQogICAgICAgICAgICAgICArIG9wZHN1bSBbZGlmZmVyZW50aWF0ZShmLCB4KSwgZCwgeSwg
ZywgaF0KICBcZW5ke3ZlcmJhdGltfQogIAorIFVwIHRvIFtbcGF0Y2gtLTQ1XV0gYSBzaW1pbGFy
IG1pc3Rha2UgY291bGQgYmUgZm91bmQgaW4gdGhlIGNvZGUgZm9yCisgZGlmZmVyZW50aWF0aW9u
IG9mIGZvcm1hbCBzdW1zLCB3aGljaCByZWFkCisgXGJlZ2lue3ZlcmJhdGltfQorICAgICBkdnN1
bShsLCB4KSA9PQorICAgICAgIGsgIDo9IHJldHJhY3Qoc2Vjb25kIGwpQEsKKyAgICAgICBkaWZm
ZXJlbnRpYXRlKHRoaXJkIGwsIHgpICogc3VtbWFuZCBsCisgICAgICAgICAgICsgb3BzdW0gW2Rp
ZmZlcmVudGlhdGUoZmlyc3QgbCwgeCksIHNlY29uZCBsLCB0aGlyZCBsXQorIFxlbmR7dmVyYmF0
aW19CisgCisgPDxwYWNrYWdlIENPTUJGIENvbWJpbmF0b3JpYWxGdW5jdGlvbj4+PQorICAgICBk
dnByb2QobCwgeCkgPT0KKyAgICAgICBkbSA6PSByZXRyYWN0KGR1bW15KUBTRQorICAgICAgIGYg
Oj0gZXZhbChmaXJzdCBsLCByZXRyYWN0KHNlY29uZCBsKUBLLCBkbTo6RikKKyAgICAgICBwIDo9
IHByb2R1Y3QoZiwgZG0pCisgCisgICAgICAgb3BzdW0gW2RpZmZlcmVudGlhdGUoZmlyc3QgbCwg
eCkvZmlyc3QgbCAqIHAsIHNlY29uZCBsLCB0aGlyZCBsXQorIAorIAorICAgICBkdmRwcm9kKGws
IHgpID09CisgICAgICAgeCA9IHJldHJhY3QoeSA6PSB0aGlyZCBsKUBTRSA9PiAwCisgICAgICAg
aWYgbWVtYmVyPyh4LCB2YXJpYWJsZXMoaCA6PSB0aGlyZCByZXN0IHJlc3QgbCkpIG9yIAorICAg
ICAgICAgIG1lbWJlcj8oeCwgdmFyaWFibGVzKGcgOj0gdGhpcmQgcmVzdCBsKSkgdGhlbgorICAg
ICAgICAgZXJyb3IgImEgcHJvZHVjdCBjYW5ub3QgYmUgZGlmZmVyZW50aWF0ZWQgd2l0aCByZXNw
ZWN0IHRvIGEgYm91bmQiCisgICAgICAgZWxzZQorICAgICAgICAgb3Bkc3VtIGNvbnMoZGlmZmVy
ZW50aWF0ZShmaXJzdCBsLCB4KS9maXJzdCBsLCByZXN0IGwpICogb3BkcHJvZCBsIAorIAorIEAg
CisgVGhlIGFib3ZlIHR3byBvcGVyYXRpb25zIGltcGxlbWVudCBkaWZmZXJlbnRpYXRpb24gb2Yg
cHJvZHVjdHMgd2l0aCBhbmQgd2l0aG91dAorIGJvdW5kcy4gTm90ZSBhZ2FpbiwgdGhhdCB3ZSBj
YW5ub3QgZXZlbiBwcm9wZXJseSBkZWZpbmUgcHJvZHVjdHMgd2l0aCBib3VuZHMKKyB0aGF0IGFy
ZSBub3QgaW50ZWdyYWwuCisgCisgVG8gZGlmZmVyZW50aWF0ZSB0aGUgcHJvZHVjdCwgd2UgdXNl
IExlaWJuaXogcnVsZToKKyAkJFxmcmFje2R9e2R4fVxwcm9kX3tpPWF9XmIgZihpLHgpID0gCisg
ICBcc3VtX3tpPWF9XmIgXGZyYWN7XGZyYWN7ZH17ZHh9IGYoaSx4KX17ZihpLHgpfVxwcm9kX3tp
PWF9XmIgZihpLHgpCisgJCQKKyAKKyBUaGVyZSBpcyBvbmUgc2l0dWF0aW9uIHdoZXJlIHRoaXMg
ZGVmaW5pdGlvbiBtaWdodCBwcm9kdWNlIHdyb25nIHJlc3VsdHMsCisgbmFtZWx5IHdoZW4gdGhl
IHByb2R1Y3QgaXMgemVybywgYnV0IGF4aW9tIGZhaWxlZCB0byByZWNvZ25pemUgaXQ6IGluIHRo
aXMKKyBjYXNlLAorICQkCisgICBcZnJhY3tkfXtkeH0gZihpLHgpL2YoaSx4KSAgCisgJCQKKyBp
cyB1bmRlZmluZWQgZm9yIHNvbWUgJGkkLiBIb3dldmVyLCBJIHdhcyBub3QgYWJsZSB0byBjb21l
IHVwIHdpdGggYW4KKyBleGFtcGxlLiBUaGUgYWx0ZXJuYXRpdmUgZGVmaW5pdGlvbgorICQkCisg
ICBcZnJhY3tkfXtkeH1ccHJvZF97aT1hfV5iIGYoaSx4KSA9IAorICAgXHN1bV97aT1hfV5iIFxs
ZWZ0KFxmcmFje2R9e2R4fSBmKGkseClccmlnaHQpXHByb2Rfe2o9YSxqXG5lcSBpfV5iIGYoaix4
KQorICQkCisgaGFzIHRoZSBzbGlnaHQgKGRpc3BsYXkpIHByb2JsZW0gdGhhdCB3ZSB3b3VsZCBo
YXZlIHRvIGNvbWUgdXAgd2l0aCBhIG5ldyBpbmRleAorIHZhcmlhYmxlLCB3aGljaCBsb29rcyB2
ZXJ5IHVnbHkuIEZ1cnRoZXJtb3JlLCBpdCBzZWVtcyB0byBtZSB0aGF0IG1vcmUKKyBzaW1wbGlm
aWNhdGlvbnMgd2lsbCBvY2N1ciB3aXRoIHRoZSBmaXJzdCBkZWZpbml0aW9uLgorIAorIDw8VEVT
VCBDT01CRj4+PQorICAgZiA6PSBvcGVyYXRvciAnZgorICAgRChwcm9kdWN0KGYoaSx4KSxpPTEu
Lm0pLHgpCisgQAorIAorIE5vdGUgdGhhdCB1cCB0byBbW3BhdGNoLS00NV1dIHRoZXNlIGZ1bmN0
aW9ucyBkaWQgbm90IGV4aXN0IGFuZCBwcm9kdWN0cyB3ZXJlCisgZGlmZmVyZW50aWF0ZWQgYWNj
b3JkaW5nIHRvIHRoZSB1c3VhbCBjaGFpbiBydWxlLCB3aGljaCBnYXZlIGluY29ycmVjdAorIHJl
c3VsdHMuIChJc3N1ZX5cIzIxMSkKKyAKICA8PHBhY2thZ2UgQ09NQkYgQ29tYmluYXRvcmlhbEZ1
bmN0aW9uPj49CisgICAgIGRwcm9kIGwgPT0KKyAgICAgICBwcm9kKHN1bW1hbmQobCk6Ok8sIHRo
aXJkKGwpOjpPKQorIAogICAgICBkZHByb2QgbCA9PQogICAgICAgIHByb2Qoc3VtbWFuZChsKTo6
TywgdGhpcmQobCk6Ok8gPSBmb3VydGgobCk6Ok8sIGZvdXJ0aChyZXN0IGwpOjpPKQogIAorICAg
ICBkc3VtIGwgPT0KKyAgICAgICBzdW0oc3VtbWFuZChsKTo6TywgdGhpcmQobCk6Ok8pCisgCiAg
ICAgIGRkc3VtIGwgPT0KICAgICAgICBzdW0oc3VtbWFuZChsKTo6TywgdGhpcmQobCk6Ok8gPSBm
b3VydGgobCk6Ok8sIGZvdXJ0aChyZXN0IGwpOjpPKQogIAorIEAgCisgVGhlc2UgZm91ciBvcGVy
YXRpb25zIGhhbmRsZSB0aGUgY29udmVyc2lvbiBvZiBzdW1zIGFuZCBwcm9kdWN0cyB0bworIFtb
T3V0cHV0Rm9ybV1dLiBOb3RlIHRoYXQgdXAgdG8gW1twYXRjaC0tNDVdXSB0aGUgZGVmaW5pdGlv
bnMgZm9yIHN1bXMgYW5kCisgcHJvZHVjdHMgd2l0aG91dCBib3VuZHMgd2VyZSBtaXNzaW5nIGFu
ZCBvdXRwdXQgd2FzIGlsbGVnaWJsZS4KKyAKKyA8PHBhY2thZ2UgQ09NQkYgQ29tYmluYXRvcmlh
bEZ1bmN0aW9uPj49CiAgICAgIHByb2R1Y3QoeDpGLCBzOlNlZ21lbnRCaW5kaW5nIEYpID09CiAg
ICAgICAgayA6PSBrZXJuZWwodmFyaWFibGUgcykkSwogICAgICAgIGRtIDo9IGR1bW15CioqKioq
KioqKioqKioqKgoqKiogMjkzLDI5OSAqKioqCiAgICAgICAgb3Bkc3VtIFtldmFsKHgsayxkbSks
IGRtLCBrOjpGLCBsbyBzZWdtZW50IHMsIGhpIHNlZ21lbnQgc10KICAKICBACi0gCiAgVGhlc2Ug
dHdvIG9wZXJhdGlvbnMgcmV0dXJuIHRoZSBwcm9kdWN0IG9yIHRoZSBzdW0gYXMgdW5ldmFsdWF0
ZWQgb3BlcmF0b3JzLiBBCiAgZHVtbXkgdmFyaWFibGUgaXMgaW50cm9kdWNlZCB0byBtYWtlIHRo
ZSBpbmRleGluZyB2YXJpYWJsZSBcbHEgbG9jYWxccnEuCiAgCi0tLSAzNjEsMzY2IC0tLS0KKioq
KioqKioqKioqKioqCioqKiA0NjYsNDg4ICoqKioKICAgICAgICAgICAgICAgICAgICAgIGxvZyhm
aXJzdCBsKSAqIGZpcnN0KGwpICoqIHNlY29uZChsKQogIAogIEAKLSAKICBUaGlzIG9wZXJhdGlv
biBpbXBsZW1lbnRzIHRoZSBkaWZmZXJlbnRpYXRpb24gb2YgdGhlIHBvd2VyIG9wZXJhdG9yIFtb
JXBvd2VyXV0KICB3aXRoIHJlc3BlY3QgdG8gaXRzIHNlY29uZCBhcmd1bWVudCwgaS5lLiwgdGhl
IGV4cG9uZW50LiBJdCB1c2VzIHRoZSBmb3JtdWxhCiEgCiEgJCRcZnJhY3tkfXtkeH0gZyh5KV54
ID0gXGZyYWN7ZH17ZHh9IGVee3hcbG9nIGcoeSl9ID0gXGxvZyBnKHkpIGcoeSleeCQkLgogIAog
IElmICRnKHkpJCBlcXVhbHMgemVybywgdGhpcyBmb3JtdWxhIGlzIG5vdCB2YWxpZCwgc2luY2Ug
dGhlIGxvZ2FyaXRobSBpcyBub3QKICBkZWZpbmVkIHRoZXJlLiBBbHRob3VnaCBzdHJpY3RseSBz
cGVha2luZyAkMF54JCBpcyBub3QgZGlmZmVyZW50aWFibGUgYXQgemVybywKICB3ZSByZXR1cm4g
emVybyBmb3IgY29udmVuaWVuY2UuIAogIAogIE5vdGUgdGhhdCB1cCB0byBbW3BhdGNoLS0yNV1d
IHRoaXMgdXNlZCB0byByZWFkCi0gCiAgXGJlZ2lue3ZlcmJhdGltfQogICAgICBpZiBGIGhhcyBF
bGVtZW50YXJ5RnVuY3Rpb25DYXRlZ29yeSB0aGVuCiAgICAgICAgZHZwb3cyIGwgPT0gbG9nKGZp
cnN0IGwpICogZmlyc3QobCkgKiogc2Vjb25kKGwpCiAgXGVuZHt2ZXJiYXRpbX0KLSAKICB3aGlj
aCBjYXVzZWQgZGlmZmVyZW50aWF0aW5nICQwXngkIHRvIGZhaWwuIChJc3N1ZX5cIzE5KQogIAog
IDw8cGFja2FnZSBDT01CRiBDb21iaW5hdG9yaWFsRnVuY3Rpb24+Pj0KLS0tIDUzMyw1NTEgLS0t
LQogICAgICAgICAgICAgICAgICAgICAgbG9nKGZpcnN0IGwpICogZmlyc3QobCkgKiogc2Vjb25k
KGwpCiAgCiAgQAogIFRoaXMgb3BlcmF0aW9uIGltcGxlbWVudHMgdGhlIGRpZmZlcmVudGlhdGlv
biBvZiB0aGUgcG93ZXIgb3BlcmF0b3IgW1slcG93ZXJdXQogIHdpdGggcmVzcGVjdCB0byBpdHMg
c2Vjb25kIGFyZ3VtZW50LCBpLmUuLCB0aGUgZXhwb25lbnQuIEl0IHVzZXMgdGhlIGZvcm11bGEK
ISAkJFxmcmFje2R9e2R4fSBnKHkpXnggPSBcZnJhY3tkfXtkeH0gZV57eFxsb2cgZyh5KX0gPSBc
bG9nIGcoeSkgZyh5KV54LiQkCiAgCiAgSWYgJGcoeSkkIGVxdWFscyB6ZXJvLCB0aGlzIGZvcm11
bGEgaXMgbm90IHZhbGlkLCBzaW5jZSB0aGUgbG9nYXJpdGhtIGlzIG5vdAogIGRlZmluZWQgdGhl
cmUuIEFsdGhvdWdoIHN0cmljdGx5IHNwZWFraW5nICQwXngkIGlzIG5vdCBkaWZmZXJlbnRpYWJs
ZSBhdCB6ZXJvLAogIHdlIHJldHVybiB6ZXJvIGZvciBjb252ZW5pZW5jZS4gCiAgCiAgTm90ZSB0
aGF0IHVwIHRvIFtbcGF0Y2gtLTI1XV0gdGhpcyB1c2VkIHRvIHJlYWQKICBcYmVnaW57dmVyYmF0
aW19CiAgICAgIGlmIEYgaGFzIEVsZW1lbnRhcnlGdW5jdGlvbkNhdGVnb3J5IHRoZW4KICAgICAg
ICBkdnBvdzIgbCA9PSBsb2coZmlyc3QgbCkgKiBmaXJzdChsKSAqKiBzZWNvbmQobCkKICBcZW5k
e3ZlcmJhdGltfQogIHdoaWNoIGNhdXNlZCBkaWZmZXJlbnRpYXRpbmcgJDBeeCQgdG8gZmFpbC4g
KElzc3VlflwjMTkpCiAgCiAgPDxwYWNrYWdlIENPTUJGIENvbWJpbmF0b3JpYWxGdW5jdGlvbj4+
PQoqKioqKioqKioqKioqKioKKioqIDQ5NSw1MDYgKioqKgogICAgICBldmFsdWF0ZShvcHByb2Qs
IGlwcm9kKQogICAgICBldmFsdWF0ZShvcGRwcm9kLCBpaWRwcm9kKQogICAgICBkZXJpdmF0aXZl
KG9wcG93LCBbZHZwb3cxLCBkdnBvdzJdKQohICAgICBzZXRQcm9wZXJ0eShvcHN1bSxTUEVDSUFM
RElGRixkdnN1bUAoKExpc3QgRixTRSkgLT4gRikgcHJldGVuZCBOb25lKQohICAgICBzZXRQcm9w
ZXJ0eShvcGRzdW0sU1BFQ0lBTERJRkYsZHZkc3VtQCgoTGlzdCBGLFNFKS0+RikgcHJldGVuZCBO
b25lKQohICAgICBzZXRQcm9wZXJ0eShvcGRzdW0sICBTUEVDSUFMRElTUCwgIGRkc3VtQChMaXN0
IEYgLT4gTykgcHJldGVuZCBOb25lKQogICAgICBzZXRQcm9wZXJ0eShvcGRwcm9kLCBTUEVDSUFM
RElTUCwgZGRwcm9kQChMaXN0IEYgLT4gTykgcHJldGVuZCBOb25lKQogIAohIEAKICBcc2VjdGlv
bntwYWNrYWdlIEZTUEVDRiBGdW5jdGlvbmFsU3BlY2lhbEZ1bmN0aW9ufQogIDw8cGFja2FnZSBG
U1BFQ0YgRnVuY3Rpb25hbFNwZWNpYWxGdW5jdGlvbj4+PQogIClhYmJyZXYgcGFja2FnZSBGU1BF
Q0YgRnVuY3Rpb25hbFNwZWNpYWxGdW5jdGlvbgotLS0gNTU4LDU4MyAtLS0tCiAgICAgIGV2YWx1
YXRlKG9wcHJvZCwgaXByb2QpCiAgICAgIGV2YWx1YXRlKG9wZHByb2QsIGlpZHByb2QpCiAgICAg
IGRlcml2YXRpdmUob3Bwb3csIFtkdnBvdzEsIGR2cG93Ml0pCiEgICAgIHNldFByb3BlcnR5KG9w
c3VtLCAgIFNQRUNJQUxESUZGLCBkdnN1bUAoKExpc3QgRiwgU0UpIC0+IEYpIHByZXRlbmQgTm9u
ZSkKISAgICAgc2V0UHJvcGVydHkob3Bkc3VtLCAgU1BFQ0lBTERJRkYsIGR2ZHN1bUAoKExpc3Qg
RiwgU0UpLT5GKSBwcmV0ZW5kIE5vbmUpCiEgICAgIHNldFByb3BlcnR5KG9wcHJvZCwgIFNQRUNJ
QUxESUZGLCBkdnByb2RAKChMaXN0IEYsIFNFKS0+RikgcHJldGVuZCBOb25lKQohICAgICBzZXRQ
cm9wZXJ0eShvcGRwcm9kLCBTUEVDSUFMRElGRiwgZHZkcHJvZEAoKExpc3QgRiwgU0UpLT5GKSBw
cmV0ZW5kIE5vbmUpCiEgQAohIFRoZSBsYXN0IGZvdXIgcHJvcGVydGllcyBkZWZpbmUgc3BlY2lh
bCBkaWZmZXJlbnRpYXRpb24gcnVsZXMgZm9yIHN1bXMgYW5kCiEgcHJvZHVjdHMuIE5vdGUgdGhh
dCB1cCB0byBbW3BhdGNoLS00NV1dIHRoZSBydWxlcyBmb3IgcHJvZHVjdHMgd2VyZSBtaXNzaW5n
LgohIFRodXMgcHJvZHVjdHMgd2VyZSBkaWZmZXJlbnRpYXRlZCBhY2NvcmRpbmcgdGhlIHVzdWFs
IGNoYWluLXJ1bGUsIHdoaWNoIGdhdmUKISBpbmNvcnJlY3QgcmVzdWx0cy4KISAKISA8PHBhY2th
Z2UgQ09NQkYgQ29tYmluYXRvcmlhbEZ1bmN0aW9uPj49CiEgICAgIHNldFByb3BlcnR5KG9wc3Vt
LCAgIFNQRUNJQUxESVNQLCBkc3VtQChMaXN0IEYgLT4gTykgcHJldGVuZCBOb25lKQohICAgICBz
ZXRQcm9wZXJ0eShvcGRzdW0sICBTUEVDSUFMRElTUCwgZGRzdW1AKExpc3QgRiAtPiBPKSBwcmV0
ZW5kIE5vbmUpCiEgICAgIHNldFByb3BlcnR5KG9wcHJvZCwgIFNQRUNJQUxESVNQLCBkcHJvZEAo
TGlzdCBGIC0+IE8pIHByZXRlbmQgTm9uZSkKICAgICAgc2V0UHJvcGVydHkob3BkcHJvZCwgU1BF
Q0lBTERJU1AsIGRkcHJvZEAoTGlzdCBGIC0+IE8pIHByZXRlbmQgTm9uZSkKICAKISBAIAohIEZp
bmFsbHksIHdlIHNldCB0aGUgcHJvcGVydGllcyBmb3IgZGlzcGxheWluZyBzdW1zIGFuZCBwcm9k
dWN0cy4KISAKISAKICBcc2VjdGlvbntwYWNrYWdlIEZTUEVDRiBGdW5jdGlvbmFsU3BlY2lhbEZ1
bmN0aW9ufQogIDw8cGFja2FnZSBGU1BFQ0YgRnVuY3Rpb25hbFNwZWNpYWxGdW5jdGlvbj4+PQog
IClhYmJyZXYgcGFja2FnZSBGU1BFQ0YgRnVuY3Rpb25hbFNwZWNpYWxGdW5jdGlvbgo=
--XLyDQVDl0e

\start
Date: Tue, 04 Oct 2005 10:02:18 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#213 No equality of operators which use dummy	variables] fix

Another fix that was not too difficult. Fortunately, there is a property '%specialEqual' just intended for this purpose...

<a href="combfunc.spad.pamphlet.patch">combfunc.spad.pamphlet.patch</a>

\start
Date: Tue, 4 Oct 2005 17:09:03 +0200
From: Martin Rubey
To: Tim Daly, list
Subject: another fix...

Dear Tim, *

I had a good day today, another fix that makes Axiom reduce

sum(1/i,i=1..n)-sum(1/i,i=1..n)

reduce to zero, as it should...

One thing remains on my wishlist: teaching axiom to handle limits of sums and
products, but I'm afraid, this one won't be that easy.

Martin


--zT/QG/sMQ4
	filename="combfunc.spad.pamphlet.patch"

KioqIC9ob21lL3J1YmV5L3RtcC9jb21iZnVuYy5zcGFkLnBhbXBobGV0CTIwMDUtMTAtMDQgMTY6
NTM6MTEuMDAwMDAwMDAwICswMjAwCi0tLSBjb21iZnVuYy5zcGFkLnBhbXBobGV0CTIwMDUtMTAt
MDQgMTY6NTY6NTkuMDAwMDAwMDAwICswMjAwCioqKioqKioqKioqKioqKgoqKiogMTMwLDE1MCAq
KioqCiAgICAgIGlkc3VtICAgICA6IExpc3QgRiAtPiBGCiAgICAgIGlwcm9kICAgICA6IExpc3Qg
RiAtPiBGCiAgICAgIGlkcHJvZCAgICA6IExpc3QgRiAtPiBGCiAgICAgIGRkc3VtICAgICA6IExp
c3QgRiAtPiBPCiAgICAgIGRkcHJvZCAgICA6IExpc3QgRiAtPiBPCiAgICAgIGZvdXJ0aCAgICA6
IExpc3QgRiAtPiBGCiAgICAgIGR2cG93MSAgICA6IExpc3QgRiAtPiBGCiAgICAgIGR2cG93MiAg
ICA6IExpc3QgRiAtPiBGCiAgICAgIHN1bW1hbmQgICA6IExpc3QgRiAtPiBGCiAgICAgIGR2c3Vt
ICAgICA6IChMaXN0IEYsIFNFKSAtPiBGCiAgICAgIGR2ZHN1bSAgICA6IChMaXN0IEYsIFNFKSAt
PiBGCiAgICAgIGZhY3RzICAgICA6IChGLCBMaXN0IFNFKSAtPiBGCiAgICAgIEsyZmFjdCAgICA6
IChLLCBMaXN0IFNFKSAtPiBGCiAgICAgIHNtcGZhY3QgICA6IChTTVAsIExpc3QgU0UpIC0+IEYK
ICAKICAgICAgZHVtbXkgPT0gbmV3KCkkU0UgOjogRgogIEAKLSAKICBUaGlzIG1hY3JvIHdpbGwg
YmUgdXNlZCBpbiBbW3Byb2R1Y3RdXSBhbmQgW1tzdW1tYXRpb25dXSwgYm90aCB0aGUgJDUkIGFu
ZCAkMyQKICBhcmd1bWVudCBmb3Jtcy4gSXQgaXMgdXNlZCB0byBpbnRyb2R1Y2UgYSBkdW1teSB2
YXJpYWJsZSBpbiBwbGFjZSBvZiB0aGUKICBzdW1tYXRpb24gaW5kZXggd2l0aGluIHRoZSBzdW1t
YW5kcy4gVGhpcyBpbiB0dXJuIGlzIG5lY2Vzc2FyeSB0byBrZWVwIHRoZQotLS0gMTMwLDE1NSAt
LS0tCiAgICAgIGlkc3VtICAgICA6IExpc3QgRiAtPiBGCiAgICAgIGlwcm9kICAgICA6IExpc3Qg
RiAtPiBGCiAgICAgIGlkcHJvZCAgICA6IExpc3QgRiAtPiBGCisgICAgIGRzdW0gICAgICA6IExp
c3QgRiAtPiBPCiAgICAgIGRkc3VtICAgICA6IExpc3QgRiAtPiBPCisgICAgIGRwcm9kICAgICA6
IExpc3QgRiAtPiBPCiAgICAgIGRkcHJvZCAgICA6IExpc3QgRiAtPiBPCisgICAgIGVxdWFsc3Vt
cHJvZCAgOiAoSywgSykgLT4gQm9vbGVhbiAKKyAgICAgZXF1YWxkc3VtcHJvZCA6IChLLCBLKSAt
PiBCb29sZWFuIAogICAgICBmb3VydGggICAgOiBMaXN0IEYgLT4gRgogICAgICBkdnBvdzEgICAg
OiBMaXN0IEYgLT4gRgogICAgICBkdnBvdzIgICAgOiBMaXN0IEYgLT4gRgogICAgICBzdW1tYW5k
ICAgOiBMaXN0IEYgLT4gRgogICAgICBkdnN1bSAgICAgOiAoTGlzdCBGLCBTRSkgLT4gRgogICAg
ICBkdmRzdW0gICAgOiAoTGlzdCBGLCBTRSkgLT4gRgorICAgICBkdnByb2QgICAgOiAoTGlzdCBG
LCBTRSkgLT4gRgorICAgICBkdmRwcm9kICAgOiAoTGlzdCBGLCBTRSkgLT4gRgogICAgICBmYWN0
cyAgICAgOiAoRiwgTGlzdCBTRSkgLT4gRgogICAgICBLMmZhY3QgICAgOiAoSywgTGlzdCBTRSkg
LT4gRgogICAgICBzbXBmYWN0ICAgOiAoU01QLCBMaXN0IFNFKSAtPiBGCiAgCiAgICAgIGR1bW15
ID09IG5ldygpJFNFIDo6IEYKICBACiAgVGhpcyBtYWNybyB3aWxsIGJlIHVzZWQgaW4gW1twcm9k
dWN0XV0gYW5kIFtbc3VtbWF0aW9uXV0sIGJvdGggdGhlICQ1JCBhbmQgJDMkCiAgYXJndW1lbnQg
Zm9ybXMuIEl0IGlzIHVzZWQgdG8gaW50cm9kdWNlIGEgZHVtbXkgdmFyaWFibGUgaW4gcGxhY2Ug
b2YgdGhlCiAgc3VtbWF0aW9uIGluZGV4IHdpdGhpbiB0aGUgc3VtbWFuZHMuIFRoaXMgaW4gdHVy
biBpcyBuZWNlc3NhcnkgdG8ga2VlcCB0aGUKKioqKioqKioqKioqKioqCioqKiAxNTUsMTY3ICoq
KioKICBwcm9kdWN0LgogIAogIE5vdGUgdGhhdCB1cCB0byBbW3BhdGNoLS0yNV1dIHRoaXMgdXNl
ZCB0byByZWFkCi0gCiAgXGJlZ2lue3ZlcmJhdGltfQogICAgICBkdW1teSA6PSBuZXcoKSRTRSA6
OiBGCiAgXGVuZHt2ZXJiYXRpbX0KLSAKICB0aHVzIGludHJvZHVjaW5nIHRoZSBzYW1lIGR1bW15
IHZhcmlhYmxlIGZvciBhbGwgcHJvZHVjdHMgYW5kIHN1bW1hdGlvbnMsIHdoaWNoCiEgY2F1c2Vk
IG5lc3RlZCBwcm9kdWN0cyBhbmQgc3VtbWF0aW9ucyBmYWlsLiAoSXNzdWV+XCM3MikKICAKICA8
PHBhY2thZ2UgQ09NQkYgQ29tYmluYXRvcmlhbEZ1bmN0aW9uPj49CiAgICAgIG9wZmFjdCAgOj0g
b3BlcmF0b3IoImZhY3RvcmlhbCI6OlN5bWJvbCkkQ29tbW9uT3BlcmF0b3JzCi0tLSAxNjAsMTcw
IC0tLS0KICBwcm9kdWN0LgogIAogIE5vdGUgdGhhdCB1cCB0byBbW3BhdGNoLS0yNV1dIHRoaXMg
dXNlZCB0byByZWFkCiAgXGJlZ2lue3ZlcmJhdGltfQogICAgICBkdW1teSA6PSBuZXcoKSRTRSA6
OiBGCiAgXGVuZHt2ZXJiYXRpbX0KICB0aHVzIGludHJvZHVjaW5nIHRoZSBzYW1lIGR1bW15IHZh
cmlhYmxlIGZvciBhbGwgcHJvZHVjdHMgYW5kIHN1bW1hdGlvbnMsIHdoaWNoCiEgY2F1c2VkIG5l
c3RlZCBwcm9kdWN0cyBhbmQgc3VtbWF0aW9ucyB0byBmYWlsLiAoSXNzdWV+XCM3MikKICAKICA8
PHBhY2thZ2UgQ09NQkYgQ29tYmluYXRvcmlhbEZ1bmN0aW9uPj49CiAgICAgIG9wZmFjdCAgOj0g
b3BlcmF0b3IoImZhY3RvcmlhbCI6OlN5bWJvbCkkQ29tbW9uT3BlcmF0b3JzCioqKioqKioqKioq
KioqKgoqKiogMjE5LDIzMyAqKioqCiAgICAgICAgb3BzdW0gW2V2YWwoeCwgayA6PSBrZXJuZWwo
aSkkSywgZG0pLCBkbSwgazo6Rl0KICAKICBACi0gCiAgVGhlc2UgdHdvIG9wZXJhdGlvbnMgcmV0
dXJuIHRoZSBwcm9kdWN0IG9yIHRoZSBzdW0gYXMgdW5ldmFsdWF0ZWQgb3BlcmF0b3JzLiBBCiAg
ZHVtbXkgdmFyaWFibGUgaXMgaW50cm9kdWNlZCB0byBtYWtlIHRoZSBpbmRleGluZyB2YXJpYWJs
ZSBcbHEgbG9jYWxccnEuCiAgCiAgPDxwYWNrYWdlIENPTUJGIENvbWJpbmF0b3JpYWxGdW5jdGlv
bj4+PQogICAgICBkdnN1bShsLCB4KSA9PQohICAgICAgIGsgIDo9IHJldHJhY3Qoc2Vjb25kIGwp
QEsKISAgICAgICBkaWZmZXJlbnRpYXRlKHRoaXJkIGwsIHgpICogc3VtbWFuZCBsCiEgICAgICAg
ICAgICsgb3BzdW0gW2RpZmZlcmVudGlhdGUoZmlyc3QgbCwgeCksIHNlY29uZCBsLCB0aGlyZCBs
XQogIAogICAgICBkdmRzdW0obCwgeCkgPT0KICAgICAgICB4ID0gcmV0cmFjdCh5IDo9IHRoaXJk
IGwpQFNFID0+IDAKLS0tIDIyMiwyMzMgLS0tLQogICAgICAgIG9wc3VtIFtldmFsKHgsIGsgOj0g
a2VybmVsKGkpJEssIGRtKSwgZG0sIGs6OkZdCiAgCiAgQAogIFRoZXNlIHR3byBvcGVyYXRpb25z
IHJldHVybiB0aGUgcHJvZHVjdCBvciB0aGUgc3VtIGFzIHVuZXZhbHVhdGVkIG9wZXJhdG9ycy4g
QQogIGR1bW15IHZhcmlhYmxlIGlzIGludHJvZHVjZWQgdG8gbWFrZSB0aGUgaW5kZXhpbmcgdmFy
aWFibGUgXGxxIGxvY2FsXHJxLgogIAogIDw8cGFja2FnZSBDT01CRiBDb21iaW5hdG9yaWFsRnVu
Y3Rpb24+Pj0KICAgICAgZHZzdW0obCwgeCkgPT0KISAgICAgICBvcHN1bSBbZGlmZmVyZW50aWF0
ZShmaXJzdCBsLCB4KSwgc2Vjb25kIGwsIHRoaXJkIGxdCiAgCiAgICAgIGR2ZHN1bShsLCB4KSA9
PQogICAgICAgIHggPSByZXRyYWN0KHkgOj0gdGhpcmQgbClAU0UgPT4gMAoqKioqKioqKioqKioq
KioKKioqIDIzOCwyNDkgKioqKgogICAgICAgICAgb3Bkc3VtIFtkaWZmZXJlbnRpYXRlKGZpcnN0
IGwsIHgpLCBzZWNvbmQgbCwgeSwgZywgaF0KICAKICBACiEgCiEgVGhlIGFib3ZlIG9wZXJhdGlv
biBpbXBsZW1lbnRzIGRpZmZlcmVudGlhdGlvbiBvZiBzdW1zIHdpdGggYm91bmRzLiBOb3RlIHRo
YXQKISB0aGUgZnVuY3Rpb24KISAKICAkJG5cbWFwc3RvXHN1bV97az0xfV5uIGYoayxuKSQkCi0g
CiAgaXMgd2VsbCBkZWZpbmVkIG9ubHkgZm9yIGludGVncmFsIHZhbHVlcyBvZiAkbiQgZ3JlYXRl
ciB0aGFuIG9yIGVxdWFsIHRvIHplcm8uCiAgVGhlcmUgaXMgbm90IGV2ZW4gY29uc2Vuc3VzIGhv
dyB0byBkZWZpbmUgdGhpcyBmdW5jdGlvbiBmb3IgJG48MCQuIFRodXMsIGl0IGlzCiAgbm90IGRp
ZmZlcmVudGlhYmxlLiBUaGVyZWZvcmUsIHdlIG5lZWQgdG8gY2hlY2sgd2hldGhlciB3ZSBlcnJv
bmVvdXNseSBhcmUKLS0tIDIzOCwyNDYgLS0tLQogICAgICAgICAgb3Bkc3VtIFtkaWZmZXJlbnRp
YXRlKGZpcnN0IGwsIHgpLCBzZWNvbmQgbCwgeSwgZywgaF0KICAKICBACiEgVGhlIGFib3ZlIHR3
byBvcGVyYXRpb25zIGltcGxlbWVudCBkaWZmZXJlbnRpYXRpb24gb2Ygc3VtcyB3aXRoIGFuZCB3
aXRob3V0CiEgYm91bmRzLiBOb3RlIHRoYXQgdGhlIGZ1bmN0aW9uCiAgJCRuXG1hcHN0b1xzdW1f
e2s9MX1ebiBmKGssbikkJAogIGlzIHdlbGwgZGVmaW5lZCBvbmx5IGZvciBpbnRlZ3JhbCB2YWx1
ZXMgb2YgJG4kIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byB6ZXJvLgogIFRoZXJlIGlzIG5vdCBl
dmVuIGNvbnNlbnN1cyBob3cgdG8gZGVmaW5lIHRoaXMgZnVuY3Rpb24gZm9yICRuPDAkLiBUaHVz
LCBpdCBpcwogIG5vdCBkaWZmZXJlbnRpYWJsZS4gVGhlcmVmb3JlLCB3ZSBuZWVkIHRvIGNoZWNr
IHdoZXRoZXIgd2UgZXJyb25lb3VzbHkgYXJlCioqKioqKioqKioqKioqKgoqKiogMjc1LDI4NyAq
KioqCi0tLSAyNzIsMzc5IC0tLS0KICAgICAgICAgICAgICAgKyBvcGRzdW0gW2RpZmZlcmVudGlh
dGUoZiwgeCksIGQsIHksIGcsIGhdCiAgXGVuZHt2ZXJiYXRpbX0KICAKKyBVcCB0byBbW3BhdGNo
LS00NV1dIGEgc2ltaWxhciBtaXN0YWtlIGNvdWxkIGJlIGZvdW5kIGluIHRoZSBjb2RlIGZvcgor
IGRpZmZlcmVudGlhdGlvbiBvZiBmb3JtYWwgc3Vtcywgd2hpY2ggcmVhZAorIFxiZWdpbnt2ZXJi
YXRpbX0KKyAgICAgZHZzdW0obCwgeCkgPT0KKyAgICAgICBrICA6PSByZXRyYWN0KHNlY29uZCBs
KUBLCisgICAgICAgZGlmZmVyZW50aWF0ZSh0aGlyZCBsLCB4KSAqIHN1bW1hbmQgbAorICAgICAg
ICAgICArIG9wc3VtIFtkaWZmZXJlbnRpYXRlKGZpcnN0IGwsIHgpLCBzZWNvbmQgbCwgdGhpcmQg
bF0KKyBcZW5ke3ZlcmJhdGltfQorIAogIDw8cGFja2FnZSBDT01CRiBDb21iaW5hdG9yaWFsRnVu
Y3Rpb24+Pj0KKyAgICAgZHZwcm9kKGwsIHgpID09CisgICAgICAgZG0gOj0gcmV0cmFjdChkdW1t
eSlAU0UKKyAgICAgICBmIDo9IGV2YWwoZmlyc3QgbCwgcmV0cmFjdChzZWNvbmQgbClASywgZG06
OkYpCisgICAgICAgcCA6PSBwcm9kdWN0KGYsIGRtKQorIAorICAgICAgIG9wc3VtIFtkaWZmZXJl
bnRpYXRlKGZpcnN0IGwsIHgpL2ZpcnN0IGwgKiBwLCBzZWNvbmQgbCwgdGhpcmQgbF0KKyAKKyAK
KyAgICAgZHZkcHJvZChsLCB4KSA9PQorICAgICAgIHggPSByZXRyYWN0KHkgOj0gdGhpcmQgbClA
U0UgPT4gMAorICAgICAgIGlmIG1lbWJlcj8oeCwgdmFyaWFibGVzKGggOj0gdGhpcmQgcmVzdCBy
ZXN0IGwpKSBvciAKKyAgICAgICAgICBtZW1iZXI/KHgsIHZhcmlhYmxlcyhnIDo9IHRoaXJkIHJl
c3QgbCkpIHRoZW4KKyAgICAgICAgIGVycm9yICJhIHByb2R1Y3QgY2Fubm90IGJlIGRpZmZlcmVu
dGlhdGVkIHdpdGggcmVzcGVjdCB0byBhIGJvdW5kIgorICAgICAgIGVsc2UKKyAgICAgICAgIG9w
ZHN1bSBjb25zKGRpZmZlcmVudGlhdGUoZmlyc3QgbCwgeCkvZmlyc3QgbCwgcmVzdCBsKSAqIG9w
ZHByb2QgbCAKKyAKKyBAIAorIFRoZSBhYm92ZSB0d28gb3BlcmF0aW9ucyBpbXBsZW1lbnQgZGlm
ZmVyZW50aWF0aW9uIG9mIHByb2R1Y3RzIHdpdGggYW5kIHdpdGhvdXQKKyBib3VuZHMuIE5vdGUg
YWdhaW4sIHRoYXQgd2UgY2Fubm90IGV2ZW4gcHJvcGVybHkgZGVmaW5lIHByb2R1Y3RzIHdpdGgg
Ym91bmRzCisgdGhhdCBhcmUgbm90IGludGVncmFsLgorIAorIFRvIGRpZmZlcmVudGlhdGUgdGhl
IHByb2R1Y3QsIHdlIHVzZSBMZWlibml6IHJ1bGU6CisgJCRcZnJhY3tkfXtkeH1ccHJvZF97aT1h
fV5iIGYoaSx4KSA9IAorICAgXHN1bV97aT1hfV5iIFxmcmFje1xmcmFje2R9e2R4fSBmKGkseCl9
e2YoaSx4KX1ccHJvZF97aT1hfV5iIGYoaSx4KQorICQkCisgCisgVGhlcmUgaXMgb25lIHNpdHVh
dGlvbiB3aGVyZSB0aGlzIGRlZmluaXRpb24gbWlnaHQgcHJvZHVjZSB3cm9uZyByZXN1bHRzLAor
IG5hbWVseSB3aGVuIHRoZSBwcm9kdWN0IGlzIHplcm8sIGJ1dCBheGlvbSBmYWlsZWQgdG8gcmVj
b2duaXplIGl0OiBpbiB0aGlzCisgY2FzZSwKKyAkJAorICAgXGZyYWN7ZH17ZHh9IGYoaSx4KS9m
KGkseCkgIAorICQkCisgaXMgdW5kZWZpbmVkIGZvciBzb21lICRpJC4gSG93ZXZlciwgSSB3YXMg
bm90IGFibGUgdG8gY29tZSB1cCB3aXRoIGFuCisgZXhhbXBsZS4gVGhlIGFsdGVybmF0aXZlIGRl
ZmluaXRpb24KKyAkJAorICAgXGZyYWN7ZH17ZHh9XHByb2Rfe2k9YX1eYiBmKGkseCkgPSAKKyAg
IFxzdW1fe2k9YX1eYiBcbGVmdChcZnJhY3tkfXtkeH0gZihpLHgpXHJpZ2h0KVxwcm9kX3tqPWEs
alxuZXEgaX1eYiBmKGoseCkKKyAkJAorIGhhcyB0aGUgc2xpZ2h0IChkaXNwbGF5KSBwcm9ibGVt
IHRoYXQgd2Ugd291bGQgaGF2ZSB0byBjb21lIHVwIHdpdGggYSBuZXcgaW5kZXgKKyB2YXJpYWJs
ZSwgd2hpY2ggbG9va3MgdmVyeSB1Z2x5LiBGdXJ0aGVybW9yZSwgaXQgc2VlbXMgdG8gbWUgdGhh
dCBtb3JlCisgc2ltcGxpZmljYXRpb25zIHdpbGwgb2NjdXIgd2l0aCB0aGUgZmlyc3QgZGVmaW5p
dGlvbi4KKyAKKyA8PFRFU1QgQ09NQkY+Pj0KKyAgIGYgOj0gb3BlcmF0b3IgJ2YKKyAgIEQocHJv
ZHVjdChmKGkseCksaT0xLi5tKSx4KQorIEAKKyAKKyBOb3RlIHRoYXQgdXAgdG8gW1twYXRjaC0t
NDVdXSB0aGVzZSBmdW5jdGlvbnMgZGlkIG5vdCBleGlzdCBhbmQgcHJvZHVjdHMgd2VyZQorIGRp
ZmZlcmVudGlhdGVkIGFjY29yZGluZyB0byB0aGUgdXN1YWwgY2hhaW4gcnVsZSwgd2hpY2ggZ2F2
ZSBpbmNvcnJlY3QKKyByZXN1bHRzLiAoSXNzdWV+XCMyMTEpCisgCisgPDxwYWNrYWdlIENPTUJG
IENvbWJpbmF0b3JpYWxGdW5jdGlvbj4+PQorICAgICBkcHJvZCBsID09CisgICAgICAgcHJvZChz
dW1tYW5kKGwpOjpPLCB0aGlyZChsKTo6TykKKyAKICAgICAgZGRwcm9kIGwgPT0KICAgICAgICBw
cm9kKHN1bW1hbmQobCk6Ok8sIHRoaXJkKGwpOjpPID0gZm91cnRoKGwpOjpPLCBmb3VydGgocmVz
dCBsKTo6TykKICAKKyAgICAgZHN1bSBsID09CisgICAgICAgc3VtKHN1bW1hbmQobCk6Ok8sIHRo
aXJkKGwpOjpPKQorIAogICAgICBkZHN1bSBsID09CiAgICAgICAgc3VtKHN1bW1hbmQobCk6Ok8s
IHRoaXJkKGwpOjpPID0gZm91cnRoKGwpOjpPLCBmb3VydGgocmVzdCBsKTo6TykKICAKKyBAIAor
IFRoZXNlIGZvdXIgb3BlcmF0aW9ucyBoYW5kbGUgdGhlIGNvbnZlcnNpb24gb2Ygc3VtcyBhbmQg
cHJvZHVjdHMgdG8KKyBbW091dHB1dEZvcm1dXS4gTm90ZSB0aGF0IHVwIHRvIFtbcGF0Y2gtLTQ1
XV0gdGhlIGRlZmluaXRpb25zIGZvciBzdW1zIGFuZAorIHByb2R1Y3RzIHdpdGhvdXQgYm91bmRz
IHdlcmUgbWlzc2luZyBhbmQgb3V0cHV0IHdhcyBpbGxlZ2libGUuCisgCisgPDxwYWNrYWdlIENP
TUJGIENvbWJpbmF0b3JpYWxGdW5jdGlvbj4+PQorICAgICBlcXVhbHN1bXByb2QoczEsIHMyKSA9
PQorICAgICAgIGwxIDo9IGFyZ3VtZW50IHMxCisgICAgICAgbDIgOj0gYXJndW1lbnQgczIKKyAK
KyAgICAgICAoZXZhbChmaXJzdCBsMSwgcmV0cmFjdChzZWNvbmQgbDEpQEssIHNlY29uZCBsMikg
PSBmaXJzdCBsMikKKyAKKyAgICAgZXF1YWxkc3VtcHJvZChzMSwgczIpID09CisgICAgICAgbDEg
Oj0gYXJndW1lbnQgczEKKyAgICAgICBsMiA6PSBhcmd1bWVudCBzMgorIAorICAgICAgICgodGhp
cmQgcmVzdCBsMSA9IHRoaXJkIHJlc3QgbDIpIGFuZAorICAgICAgICAodGhpcmQgcmVzdCByZXN0
IGwxID0gdGhpcmQgcmVzdCByZXN0IGwyKSBhbmQKKyAgICAgICAgKGV2YWwoZmlyc3QgbDEsIHJl
dHJhY3Qoc2Vjb25kIGwxKUBLLCBzZWNvbmQgbDIpID0gZmlyc3QgbDIpKQorIAorIEAgCisgVGhl
IHByZWNlZGluZyB0d28gb3BlcmF0aW9ucyBoYW5kbGUgdGhlIHRlc3RpbmcgZm9yIGVxdWFsaXR5
IG9mIHN1bXMgYW5kCisgcHJvZHVjdHMuIFRoaXMgZnVuY3Rpb25hbGl0eSB3YXMgbWlzc2luZyB1
cCB0byBbW3BhdGNoLS00NV1dLiAoSXNzdWV+XCMyMTMpCisgVGhlIGNvcnJlc3BvbmRpbmcgcHJv
cGVydHkgW1slc3BlY2lhbEVxdWFsXV0gc2V0IGJlbG93IGlzIGNoZWNrZWQgaW4KKyBbW0tlcm5l
bF1dLiBOb3RlIHRoYXQgd2UgY2FuIGFzc3VtZSB0aGF0IHRoZSBvcGVyYXRvcnMgYXJlIGVxdWFs
LCBzaW5jZSB0aGlzCisgaXMgY2hlY2tlZCBpbiBbW0tlcm5lbF1dIGl0c2VsZi4KKworIDw8cGFj
a2FnZSBDT01CRiBDb21iaW5hdG9yaWFsRnVuY3Rpb24+Pj0KICAgICAgcHJvZHVjdCh4OkYsIHM6
U2VnbWVudEJpbmRpbmcgRikgPT0KICAgICAgICBrIDo9IGtlcm5lbCh2YXJpYWJsZSBzKSRLCiAg
ICAgICAgZG0gOj0gZHVtbXkKKioqKioqKioqKioqKioqCioqKiAyOTMsMjk5ICoqKioKICAgICAg
ICBvcGRzdW0gW2V2YWwoeCxrLGRtKSwgZG0sIGs6OkYsIGxvIHNlZ21lbnQgcywgaGkgc2VnbWVu
dCBzXQogIAogIEAKLSAKICBUaGVzZSB0d28gb3BlcmF0aW9ucyByZXR1cm4gdGhlIHByb2R1Y3Qg
b3IgdGhlIHN1bSBhcyB1bmV2YWx1YXRlZCBvcGVyYXRvcnMuIEEKICBkdW1teSB2YXJpYWJsZSBp
cyBpbnRyb2R1Y2VkIHRvIG1ha2UgdGhlIGluZGV4aW5nIHZhcmlhYmxlIFxscSBsb2NhbFxycS4K
ICAKLS0tIDM4NSwzOTAgLS0tLQoqKioqKioqKioqKioqKioKKioqIDQ2Niw0ODggKioqKgogICAg
ICAgICAgICAgICAgICAgICAgbG9nKGZpcnN0IGwpICogZmlyc3QobCkgKiogc2Vjb25kKGwpCiAg
CiAgQAotIAogIFRoaXMgb3BlcmF0aW9uIGltcGxlbWVudHMgdGhlIGRpZmZlcmVudGlhdGlvbiBv
ZiB0aGUgcG93ZXIgb3BlcmF0b3IgW1slcG93ZXJdXQogIHdpdGggcmVzcGVjdCB0byBpdHMgc2Vj
b25kIGFyZ3VtZW50LCBpLmUuLCB0aGUgZXhwb25lbnQuIEl0IHVzZXMgdGhlIGZvcm11bGEKISAK
ISAkJFxmcmFje2R9e2R4fSBnKHkpXnggPSBcZnJhY3tkfXtkeH0gZV57eFxsb2cgZyh5KX0gPSBc
bG9nIGcoeSkgZyh5KV54JCQuCiAgCiAgSWYgJGcoeSkkIGVxdWFscyB6ZXJvLCB0aGlzIGZvcm11
bGEgaXMgbm90IHZhbGlkLCBzaW5jZSB0aGUgbG9nYXJpdGhtIGlzIG5vdAogIGRlZmluZWQgdGhl
cmUuIEFsdGhvdWdoIHN0cmljdGx5IHNwZWFraW5nICQwXngkIGlzIG5vdCBkaWZmZXJlbnRpYWJs
ZSBhdCB6ZXJvLAogIHdlIHJldHVybiB6ZXJvIGZvciBjb252ZW5pZW5jZS4gCiAgCiAgTm90ZSB0
aGF0IHVwIHRvIFtbcGF0Y2gtLTI1XV0gdGhpcyB1c2VkIHRvIHJlYWQKLSAKICBcYmVnaW57dmVy
YmF0aW19CiAgICAgIGlmIEYgaGFzIEVsZW1lbnRhcnlGdW5jdGlvbkNhdGVnb3J5IHRoZW4KICAg
ICAgICBkdnBvdzIgbCA9PSBsb2coZmlyc3QgbCkgKiBmaXJzdChsKSAqKiBzZWNvbmQobCkKICBc
ZW5ke3ZlcmJhdGltfQotIAogIHdoaWNoIGNhdXNlZCBkaWZmZXJlbnRpYXRpbmcgJDBeeCQgdG8g
ZmFpbC4gKElzc3VlflwjMTkpCiAgCiAgPDxwYWNrYWdlIENPTUJGIENvbWJpbmF0b3JpYWxGdW5j
dGlvbj4+PQotLS0gNTU3LDU3NSAtLS0tCiAgICAgICAgICAgICAgICAgICAgICBsb2coZmlyc3Qg
bCkgKiBmaXJzdChsKSAqKiBzZWNvbmQobCkKICAKICBACiAgVGhpcyBvcGVyYXRpb24gaW1wbGVt
ZW50cyB0aGUgZGlmZmVyZW50aWF0aW9uIG9mIHRoZSBwb3dlciBvcGVyYXRvciBbWyVwb3dlcl1d
CiAgd2l0aCByZXNwZWN0IHRvIGl0cyBzZWNvbmQgYXJndW1lbnQsIGkuZS4sIHRoZSBleHBvbmVu
dC4gSXQgdXNlcyB0aGUgZm9ybXVsYQohICQkXGZyYWN7ZH17ZHh9IGcoeSleeCA9IFxmcmFje2R9
e2R4fSBlXnt4XGxvZyBnKHkpfSA9IFxsb2cgZyh5KSBnKHkpXnguJCQKICAKICBJZiAkZyh5KSQg
ZXF1YWxzIHplcm8sIHRoaXMgZm9ybXVsYSBpcyBub3QgdmFsaWQsIHNpbmNlIHRoZSBsb2dhcml0
aG0gaXMgbm90CiAgZGVmaW5lZCB0aGVyZS4gQWx0aG91Z2ggc3RyaWN0bHkgc3BlYWtpbmcgJDBe
eCQgaXMgbm90IGRpZmZlcmVudGlhYmxlIGF0IHplcm8sCiAgd2UgcmV0dXJuIHplcm8gZm9yIGNv
bnZlbmllbmNlLiAKICAKICBOb3RlIHRoYXQgdXAgdG8gW1twYXRjaC0tMjVdXSB0aGlzIHVzZWQg
dG8gcmVhZAogIFxiZWdpbnt2ZXJiYXRpbX0KICAgICAgaWYgRiBoYXMgRWxlbWVudGFyeUZ1bmN0
aW9uQ2F0ZWdvcnkgdGhlbgogICAgICAgIGR2cG93MiBsID09IGxvZyhmaXJzdCBsKSAqIGZpcnN0
KGwpICoqIHNlY29uZChsKQogIFxlbmR7dmVyYmF0aW19CiAgd2hpY2ggY2F1c2VkIGRpZmZlcmVu
dGlhdGluZyAkMF54JCB0byBmYWlsLiAoSXNzdWV+XCMxOSkKICAKICA8PHBhY2thZ2UgQ09NQkYg
Q29tYmluYXRvcmlhbEZ1bmN0aW9uPj49CioqKioqKioqKioqKioqKgoqKiogNDk1LDUwNiAqKioq
CiAgICAgIGV2YWx1YXRlKG9wcHJvZCwgaXByb2QpCiAgICAgIGV2YWx1YXRlKG9wZHByb2QsIGlp
ZHByb2QpCiAgICAgIGRlcml2YXRpdmUob3Bwb3csIFtkdnBvdzEsIGR2cG93Ml0pCiEgICAgIHNl
dFByb3BlcnR5KG9wc3VtLFNQRUNJQUxESUZGLGR2c3VtQCgoTGlzdCBGLFNFKSAtPiBGKSBwcmV0
ZW5kIE5vbmUpCiEgICAgIHNldFByb3BlcnR5KG9wZHN1bSxTUEVDSUFMRElGRixkdmRzdW1AKChM
aXN0IEYsU0UpLT5GKSBwcmV0ZW5kIE5vbmUpCiEgICAgIHNldFByb3BlcnR5KG9wZHN1bSwgIFNQ
RUNJQUxESVNQLCAgZGRzdW1AKExpc3QgRiAtPiBPKSBwcmV0ZW5kIE5vbmUpCiAgICAgIHNldFBy
b3BlcnR5KG9wZHByb2QsIFNQRUNJQUxESVNQLCBkZHByb2RAKExpc3QgRiAtPiBPKSBwcmV0ZW5k
IE5vbmUpCiAgCi0gQAogIFxzZWN0aW9ue3BhY2thZ2UgRlNQRUNGIEZ1bmN0aW9uYWxTcGVjaWFs
RnVuY3Rpb259CiAgPDxwYWNrYWdlIEZTUEVDRiBGdW5jdGlvbmFsU3BlY2lhbEZ1bmN0aW9uPj49
CiAgKWFiYnJldiBwYWNrYWdlIEZTUEVDRiBGdW5jdGlvbmFsU3BlY2lhbEZ1bmN0aW9uCi0tLSA1
ODIsNjEyIC0tLS0KICAgICAgZXZhbHVhdGUob3Bwcm9kLCBpcHJvZCkKICAgICAgZXZhbHVhdGUo
b3BkcHJvZCwgaWlkcHJvZCkKICAgICAgZGVyaXZhdGl2ZShvcHBvdywgW2R2cG93MSwgZHZwb3cy
XSkKISAgICAgc2V0UHJvcGVydHkob3BzdW0sICAgU1BFQ0lBTERJRkYsIGR2c3VtQCgoTGlzdCBG
LCBTRSkgLT4gRikgcHJldGVuZCBOb25lKQohICAgICBzZXRQcm9wZXJ0eShvcGRzdW0sICBTUEVD
SUFMRElGRiwgZHZkc3VtQCgoTGlzdCBGLCBTRSktPkYpIHByZXRlbmQgTm9uZSkKISAgICAgc2V0
UHJvcGVydHkob3Bwcm9kLCAgU1BFQ0lBTERJRkYsIGR2cHJvZEAoKExpc3QgRiwgU0UpLT5GKSBw
cmV0ZW5kIE5vbmUpCiEgICAgIHNldFByb3BlcnR5KG9wZHByb2QsIFNQRUNJQUxESUZGLCBkdmRw
cm9kQCgoTGlzdCBGLCBTRSktPkYpIHByZXRlbmQgTm9uZSkKISBACiEgVGhlIGxhc3QgZm91ciBw
cm9wZXJ0aWVzIGRlZmluZSBzcGVjaWFsIGRpZmZlcmVudGlhdGlvbiBydWxlcyBmb3Igc3VtcyBh
bmQKISBwcm9kdWN0cy4gTm90ZSB0aGF0IHVwIHRvIFtbcGF0Y2gtLTQ1XV0gdGhlIHJ1bGVzIGZv
ciBwcm9kdWN0cyB3ZXJlIG1pc3NpbmcuCiEgVGh1cyBwcm9kdWN0cyB3ZXJlIGRpZmZlcmVudGlh
dGVkIGFjY29yZGluZyB0aGUgdXN1YWwgY2hhaW4tcnVsZSwgd2hpY2ggZ2F2ZQohIGluY29ycmVj
dCByZXN1bHRzLgohIAohIDw8cGFja2FnZSBDT01CRiBDb21iaW5hdG9yaWFsRnVuY3Rpb24+Pj0K
ISAgICAgc2V0UHJvcGVydHkob3BzdW0sICAgU1BFQ0lBTERJU1AsIGRzdW1AKExpc3QgRiAtPiBP
KSBwcmV0ZW5kIE5vbmUpCiEgICAgIHNldFByb3BlcnR5KG9wZHN1bSwgIFNQRUNJQUxESVNQLCBk
ZHN1bUAoTGlzdCBGIC0+IE8pIHByZXRlbmQgTm9uZSkKISAgICAgc2V0UHJvcGVydHkob3Bwcm9k
LCAgU1BFQ0lBTERJU1AsIGRwcm9kQChMaXN0IEYgLT4gTykgcHJldGVuZCBOb25lKQogICAgICBz
ZXRQcm9wZXJ0eShvcGRwcm9kLCBTUEVDSUFMRElTUCwgZGRwcm9kQChMaXN0IEYgLT4gTykgcHJl
dGVuZCBOb25lKQorICAgICBzZXRQcm9wZXJ0eShvcHN1bSwgICBTUEVDSUFMRVFVQUwsIGVxdWFs
c3VtcHJvZEAoKEssSykgLT4gQm9vbGVhbikgcHJldGVuZCBOb25lKQorICAgICBzZXRQcm9wZXJ0
eShvcGRzdW0sICBTUEVDSUFMRVFVQUwsIGVxdWFsZHN1bXByb2RAKChLLEspIC0+IEJvb2xlYW4p
IHByZXRlbmQgTm9uZSkKKyAgICAgc2V0UHJvcGVydHkob3Bwcm9kLCAgU1BFQ0lBTEVRVUFMLCBl
cXVhbHN1bXByb2RAKChLLEspIC0+IEJvb2xlYW4pIHByZXRlbmQgTm9uZSkKKyAgICAgc2V0UHJv
cGVydHkob3BkcHJvZCwgU1BFQ0lBTEVRVUFMLCBlcXVhbGRzdW1wcm9kQCgoSyxLKSAtPiBCb29s
ZWFuKSBwcmV0ZW5kIE5vbmUpCisgCisgQCAKKyBGaW5hbGx5LCB3ZSBzZXQgdGhlIHByb3BlcnRp
ZXMgZm9yIGRpc3BsYXlpbmcgc3VtcyBhbmQgcHJvZHVjdHMgYW5kIHRlc3RpbmcgZm9yCisgZXF1
YWxpdHkuCisgCiAgCiAgXHNlY3Rpb257cGFja2FnZSBGU1BFQ0YgRnVuY3Rpb25hbFNwZWNpYWxG
dW5jdGlvbn0KICA8PHBhY2thZ2UgRlNQRUNGIEZ1bmN0aW9uYWxTcGVjaWFsRnVuY3Rpb24+Pj0K
ICApYWJicmV2IHBhY2thZ2UgRlNQRUNGIEZ1bmN0aW9uYWxTcGVjaWFsRnVuY3Rpb24K
--zT/QG/sMQ4--

\start
Date: Tue, 04 Oct 2005 16:19:37 +0200
From: Winfried Neun
To: Bill Page
Subject: Re: New Version of REDUCE
Cc: Tony Hearn

Bill,

it looks as though I missed something.

I remember that you got the software via ftp last time.

Do you prefer the 64 bit version for AMD64 / Intel EMT
or the traditional 32 bit version for Linux?

Regards,

Winfried

>Tony Hearn,
>
>You will recall I am sure, that a little more than a year
>ago, with your kind approval I installed Reduce on the
>axiom-developer server. The axiom-developer server runs
>the wiki-based web application that I call MathAction which
>provides a web-based interface for both Axiom and Reduce.
>
>Here is an updated URL for the web site:
>
>http://wiki.axiom-developer.org
>
>I have been reviewing my notes about Reduce on MathAction
>and I see that the version we are running is the older
>version 3.7. Perhaps through an oversight I apparently did
>not receive the updated Reduce version 3.8 package that I
>discussed with Winfried Neun. Would it be possible for me
>to obtain the newer version for linux to install on the
>axiom-developer server?
>
>I am especially interested in installing version 3.8 because
>of it's support for OpenMath. Recently I have become motivated
>again to look at OpenMath and MathML support in both Axiom
>and Reduce.
>
>Kind Regards,
>Bill Page.
>
>  
>
>>-----Original Message-----
>>From: Winfried Neun [mailto:Winfried Neun] 
>>Sent: August 10, 2004 5:23 AM
>>To: Bill Page (E-mail)
>>Cc: Tony Hearn
>>Subject: Re: mathML, "bad(" problem, (was: Patch for rlfi)
>>
>>Right,
>>
>>You have got REDUCE 3.7. It might be useful to use a more recent
>>patches file, but I think I will be able to distribute REDUCE 3.8
>>for Linux this month, perhaps you just wait for it.
>>
>>Winfried
>>
>>Page, Bill wrote:
>>
>>    
>>
>>>When I start Reduce I see:
>>>
>>>Loading image file :/usr/local/reduce/lisp/psl/linux/red/reduce.img
>>>REDUCE 3.7, 15-Apr-1999, patched to 14-Jun-2001 ...
>>>
>>>So I guess what Winfried gave me was really Reduce 3.7?
>>>
>>> 
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Tony Hearn [mailto:hearn@rand.org]
>>>>Sent: Monday, August 09, 2004 4:02 PM
>>>>To: Bill Page (E-mail)
>>>>Subject: Re: mathML, "bad(" problem, (was: Patch for rlfi) 
>>>>
>>>>
>>>>You should work with Winfried on the MathML stuff --- he 
>>>>wrote the code (but he may be on vacation now --- it's
>>>>August, after all).
>>>>
>>>>As far as the version is concerned, there should be a banner 
>>>>when you run it that tells you the version.  Otherwise, you
>>>>        
>>>>
>>>can say
>>>      
>>>
>>>>  lisp version!*;
>>>>
>>>>in REDUCE and it will tell you.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>
>  
>
>>-----Original Message-----
>>From: Tony Hearn [mailto:hearn@rand.org] 
>>Sent: July 22, 2004 6:58 PM
>>To: Bill Page
>>Cc: Winfried Neun; hearn@rand.org
>>Subject: Re: New Version of REDUCE 
>>
>>
>>    
>>
>>>I would like to know your opinion regarding the possibility of 
>>>including a web-based interface to REDUCE in our system. Would
>>>the licensing conditions permit this?
>>>      
>>>
>>Even though there is a (relatively) modest fee charged for 
>>the distribution of REDUCE, it is "open source" in the sense 
>>that all sources are distributed with the so-called 
>>professional version.  So I would certainly encourage you to 
>>develop such an interface --- there are no licensing 
>>restrictions affecting this (assuming you don't include a 
>>copy of REDUCE with your code!)
>>
>>Winfried Neun Winfried Neun is the one who developed the 
>>MathML interface, and he would be happy to work further with 
>>you on your interface, as would I.  For starters, you 
>>probably need a copy of the software.  Please tell Winfried 
>>what platform you use, and he'll supply the appropriate version.
>>
>>When things are working, we could put the code on the REDUCE 
>>web site, or put a pointer there to wherever you have things stored.
>>
>>Regards,
>>Tony
>>
>>    
>>
>
>
>  
>


--------------050704060506080403060600

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Bill,<br>
<br>
it looks as though I missed something.<br>
<br>
I remember that you got the software via ftp last time.<br>
<br>
Do you prefer the 64 bit version for AMD64 / Intel EMT<br>
or the traditional 32 bit version for Linux?<br>
<br>
Regards,<br>
<br>
Winfried<br>
<br>
<blockquote cite="mid009c01c5c897$3f3b6080$6700a8c0@asus" type="cite">
  <pre wrap="">Tony Hearn,

You will recall I am sure, that a little more than a year
ago, with your kind approval I installed Reduce on the
axiom-developer server. The axiom-developer server runs
the wiki-based web application that I call MathAction which
provides a web-based interface for both Axiom and Reduce.

Here is an updated URL for the web site:

<a class="moz-txt-link-freetext" href="http://wiki.axiom-developer.org">http://wiki.axiom-developer.org</a>

I have been reviewing my notes about Reduce on MathAction
and I see that the version we are running is the older
version 3.7. Perhaps through an oversight I apparently did
not receive the updated Reduce version 3.8 package that I
discussed with Winfried Neun. Would it be possible for me
to obtain the newer version for linux to install on the
axiom-developer server?

I am especially interested in installing version 3.8 because
of it's support for OpenMath. Recently I have become motivated
again to look at OpenMath and MathML support in both Axiom
and Reduce.

Kind Regards,
Bill Page.

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: Winfried Neun [<a class="moz-txt-link-freetext" href="mailto:Winfried Neun">mailto:Winfried Neun</a>] 
Sent: August 10, 2004 5:23 AM
To: Bill Page (E-mail)
Cc: Tony Hearn
Subject: Re: mathML, "bad(" problem, (was: Patch for rlfi)

Right,

You have got REDUCE 3.7. It might be useful to use a more recent
patches file, but I think I will be able to distribute REDUCE 3.8
for Linux this month, perhaps you just wait for it.

Winfried

Page, Bill wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">When I start Reduce I see:

Loading image file :/usr/local/reduce/lisp/psl/linux/red/reduce.img
REDUCE 3.7, 15-Apr-1999, patched to 14-Jun-2001 ...

So I guess what Winfried gave me was really Reduce 3.7?

 

      </pre>
      <blockquote type="cite">
        <pre wrap="">-----Original Message-----
From: Tony Hearn [<a class="moz-txt-link-freetext" href="mailto:hearn@rand.org">mailto:hearn@rand.org</a>]
Sent: Monday, August 09, 2004 4:02 PM
To: Bill Page (E-mail)
Subject: Re: mathML, "bad(" problem, (was: Patch for rlfi) 


You should work with Winfried on the MathML stuff --- he 
wrote the code (but he may be on vacation now --- it's
August, after all).

As far as the version is concerned, there should be a banner 
when you run it that tells you the version.  Otherwise, you
        </pre>
      </blockquote>
      <pre wrap="">can say
      </pre>
      <blockquote type="cite">
        <pre wrap="">  lisp version!*;

in REDUCE and it will tell you.

   

        </pre>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: Tony Hearn [<a class="moz-txt-link-freetext" href="mailto:hearn@rand.org">mailto:hearn@rand.org</a>] 
Sent: July 22, 2004 6:58 PM
To: Bill Page
Cc: Winfried Neun; <a class="moz-txt-link-abbreviated" href="mailto:hearn@rand.org">hearn@rand.org</a>
Subject: Re: New Version of REDUCE 


    </pre>
    <blockquote type="cite">
      <pre wrap="">I would like to know your opinion regarding the possibility of 
including a web-based interface to REDUCE in our system. Would
the licensing conditions permit this?
      </pre>
    </blockquote>
    <pre wrap="">Even though there is a (relatively) modest fee charged for 
the distribution of REDUCE, it is "open source" in the sense 
that all sources are distributed with the so-called 
professional version.  So I would certainly encourage you to 
develop such an interface --- there are no licensing 
restrictions affecting this (assuming you don't include a 
copy of REDUCE with your code!)

Winfried Neun <a class="moz-txt-link-rfc2396E" href="mailto:Winfried Neun">&lt;Winfried Neun&gt;</a> is the one who developed the 
MathML interface, and he would be happy to work further with 
you on your interface, as would I.  For starters, you 
probably need a copy of the software.  Please tell Winfried 
what platform you use, and he'll supply the appropriate version.

When things are working, we could put the code on the REDUCE 
web site, or put a pointer there to wherever you have things stored.

Regards,
Tony

    </pre>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
<br>
</body>
</html>

\start
Date: Tue, 4 Oct 2005 13:18:47 -0400
From: Bill Page
To: Winfried Neun
Subject: RE: New Version of REDUCE
Cc: Tony Hearn

Winfried,

No problem. Yes, I got the previous version of Reduce at an ftp
location that you sent to me.

We need the 32-bit linux version for the shared RedHat 9 host that
runs MathAction but I am glad to hear that an AMD 64-bit version is
available. On my development server I run Fedora Core 3 x86-64 on
AMD 3500+ and it's fast.

At some time in the future we might upgrade MathAction to a 64-bit
server.

Thanks.

Regards,
Bill Page.

________________________________

	Bill,

	it looks as though I missed something.

	I remember that you got the software via ftp last time.

	Do you prefer the 64 bit version for AMD64 / Intel EMT
	or the traditional 32 bit version for Linux?

\start
Date: Wed, 05 Oct 2005 00:28:33 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [OpenMath] (new) 

Changes http://wiki.axiom-developer.org/OpenMath/diff
--
http://www.openmath.org

The OpenMath Society

  OpenMath is an emerging standard for representing mathematical
objects with their semantics, allowing them to be exchanged between
computer programs, stored in databases, or published on the worldwide
web. While the original designers were mainly developers of computer
algebra systems, it is now attracting interest from other areas of
scientific computation and from many publishers of electronic
documents with a significant mathematical content. There is a strong
relationship to the MathML recommendation from the Worldwide Web
Consortium, and a large overlap between the two developer communities.
MathML deals principally with the presentation of mathematical objects,
while OpenMath is solely concerned with their semantic meaning or
content. While MathML does have some limited facilities for dealing
with content, it also allows semantic information encoded in OpenMath
to be embedded inside a MathML structure. Thus the two technologies
may be seen as highly complementary.

Mathematical objects encoded in OpenMath can be

* displayed in a browser

* exchanged between software systems

* cut and pasted for use in different contexts

* verified as being mathematically sound (or not!)

* used to make interactive documents really interactive.

OpenMath is highly relevant for persons working with mathematics on
computers, for those working with large documents (e.g. databases,
manuals) containing mathematical expressions, and for technical and
mathematical publishing.

Comments

  From an email by Tim Daly on Tue, 10 Dec 2002 20:26:57 -0500

    Subject: Axiom and OpenMath/MathML

    ... the fundamental idea is that there are libraries of semantics
that define what the symbols used in a communication mean. That
way the sender and receiver have a common point of reference.
I suppose this might be possible but it would be a fundamentally
hard problem.

    Just to get down to cases lets assume that Maple, for example
(and I confess that it is years since I've actually used Maple so
my examples might no longer hold true) and Axiom. Let me try to 
illustrate why *I* believe the problem is harder than you might
suspect.

    First, there is the fundamental mismatch of the designs of
the systems. I classify Maple as an "Engineering" system. That
is, the Maple system is designed for ease of use. It strives to
make the answers "work out ok". A subtle side-effect of this
design are cases where you subtract two matrices and get a
0 integer rather than the 0 matrix. This zero integer can be
used in further computations unrelated to matrices.

    I classify Axiom as a "theory" system. That is, Axiom is
designed for correctness. It strives to make the answers match
the theory. Thus, subtracting two matrices will give you a
0 matrix. This strong typing is anything but easy to use. 

    So the two systems started with different mindsets and
virtually every level of the design is constructed to support
that mindset. What is easy to write in 5 lines of Maple can
take a great deal of struggle in Axiom. The reverse is also
true.

    OpenMath presumes that there are two systems that support
its semantic definitions. That can be very hard for Maple if
the semantics are deeply related to the type. It can be very
hard for Axiom is the semantics are type-ambiguous.

    Second, there is the semantic mismatch between Maple and
Axiom. Axiom's mathematics assume an inheritance model, local
scoping of variables in algebra code, etc. Maple's mathematics
don't support inheritance, variables have global scope, etc.
It's like the difference between Java and Basic. You made the
point that surely Maple could be programmed to accept Axiom's
types. Yes, it could but you'd end up building an Axiom
interpreter in Maple's interpreter language. I fail to see
how OpenMath would address such wildly differing environments
like Java and Basic or like Maple and Axiom. A great deal of
the semantics in Axiom's answers is encoded in the type. If
I send an equation to Maple I need the correct type returned.
It can't be lost or I've lost fundamental semantics.

    Third, there is the syntactic mismatch. For primitive math
you might hope that Maple and Axiom use the same notation, at
least. Unfortunately this isn't true. Life gets much worse when
you try to represent higher objects like Ideals or a Groebner
basis.

Even the integrate function, which they both support heavily,
shares little, if any, syntax.

    OpenMath is a good idea and is supported by a lot of clever
people. It might succeed. I could even be classified as a 
"mild supporter". But it doesn't stir my blood to want to write
code for it. If you're interested, however, I'm willing to
discuss ways to experiment with it. It is, after all, leading
edge research (my definition of research is doing something no
one in the world knows how to do) and Axiom has always been a
great platform for doing research.

  On Thu, 13 May 2004 10:03:12 +0100 Mike Dewar wrote:

    There are two separate issues here.  The first is the problem
of reading and writing streams of OpenMath tokens.  It is this
which uses the underlying C Library code (which by the way will
probably be obsolote soon: we are hoping to finalise OpenMath 2
in the next week or two).

The second is the question of serialising Axiom objects in
OpenMath encodings.  This is done in Axiom code via the OpenMath
category, but is only implemented for a few domains.

  On Thu, May 13, 2004 at 09:47:00AM -0400, Tim Daly wrote:

    Where can I get the new library?

  On Thu, 13 May 2004 15:40:57 +0100 Mike Dewar wrote:

    There isn't one as yet.  I don't know whether a library similar
to the old INRIA one will be produced, the world has moved on and
people tend to be using OpenMath much more as a document format
than an interchange mechanism.  For those that do want to use it
as an interchange mechanism, Java libraries that use mechanisms
like SOAP, XML-RPC etc. are more useful than the old TCP/IP-based
one.  
 
    ...  Everything else that you need is already freely available
in browsers, implemented according to defined or de-facto standards.
You can do text layout in XHTML, implement fancy folding menus
with javascript, handle graphics with plug-ins to get interactivity
and render the Maths with MathML.  If you want a hard-copy on the
other hand, then its very easy to write an XSL stylesheet to
produce LaTeX from your original document, or you can probably
find existing tools to do this on the web.  This isn't fantasy
by the way, its exactly what we are doing at NAG with our
documentation and its proving very successful.

    ... based on XML and thats just Lisp with fancy brackets :-)

  On Thu, May 13, 2004 at 09:47:00AM -0400, Tim Daly wrote:

    I don't see how to carry Axiom's Types in OpenMath's data
representation.

  On Thu, 13 May 2004 15:40:57 +0100 Mike Dewar wrote:

    You use the OMATTR constructor to attribute the object with
its Axiom type.  (In OpenMath 2 you can make this stronger by
declaring it to be a semantic attribute.)  MathML has an element
called "semantics" which allows you to do a similar thing, there
is a whole document devoted to this problem at
http://www.w3.org/TR/mathml-types

    ... if I were in your position I would try and use generic
technologies inside a browser, rather than do something ad-hoc.

See also:

  AxiomUI

\start
Date: Wed, 05 Oct 2005 01:01:08 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [OpenMath]  XML/Aldor/OpenMath

"Bill Naylor:http://www.cs.bath.ac.uk/~wn provides some
"Aldor libraries":http://www.cs.bath.ac.uk/~wn/AldorXML
for dealing with XML objects such as OpenMath and MathML.
Perhaps this could be adapted for use within Axiom.

\start
Date: Wed, 05 Oct 2005 01:28:07 -0500
From: MathAction (Ed Borasky)
To: MathAction
Subject: [OpenMath] [OpenMath] (new)

That URL (http://www.openmath.org) doesn't work. :(

As to the difference between a CAS designed for mathematicians 
(theoretical, presumably) and one for engineers (or statisticians or 
applied mathematicians or "numericians" or whatever) I suspect it's not 
as large gap for the workers as you think. For example, I've seen 
FORTRAN numerical codes that did a little symbolic differentiation and 
some Taylor series calculations on their way to solving hairy ODEs.

I've done "number crunching" in Derive and it's not as inefficient as 
you might think. And I suspect I could do a computer performance 
modeling project / queuing network solver in Axiom, Maxima, Lisp, Ruby, 
Derive, Perl, Maple, Mathematica, R or Visual Basic with approximately 
the same level of efficiency of execution. Only direct compiled to 
hardware languages -- Forth, C or FORTRAN -- would be faster. If I 
needed to do a lot of text processing to get my data, that would narrow 
the field considerably -- down to R, Perl and Ruby, in fact.

Bill Page wrote:

>Changes http://wiki.axiom-developer.org/OpenMath/diff
>--
>http://www.openmath.org
>
>The OpenMath Society
>
>  OpenMath is an emerging standard for representing mathematical
>objects with their semantics, allowing them to be exchanged between
>computer programs, stored in databases, or published on the worldwide
>web. While the original designers were mainly developers of computer
>algebra systems, it is now attracting interest from other areas of
>scientific computation and from many publishers of electronic
>documents with a significant mathematical content. There is a strong
>relationship to the MathML recommendation from the Worldwide Web
>Consortium, and a large overlap between the two developer communities.
>MathML deals principally with the presentation of mathematical objects,
>while OpenMath is solely concerned with their semantic meaning or
>content. While MathML does have some limited facilities for dealing
>with content, it also allows semantic information encoded in OpenMath
>to be embedded inside a MathML structure. Thus the two technologies
>may be seen as highly complementary.
>
>Mathematical objects encoded in OpenMath can be
>
>* displayed in a browser
>
>* exchanged between software systems
>
>* cut and pasted for use in different contexts
>
>* verified as being mathematically sound (or not!)
>
>* used to make interactive documents really interactive.
>
>OpenMath is highly relevant for persons working with mathematics on
>computers, for those working with large documents (e.g. databases,
>manuals) containing mathematical expressions, and for technical and
>mathematical publishing.
>
>Comments
>
>  From an email by Tim Daly on Tue, 10 Dec 2002 20:26:57 -0500
>
>    Subject: Axiom and OpenMath/MathML
>
>    ... the fundamental idea is that there are libraries of semantics
>that define what the symbols used in a communication mean. That
>way the sender and receiver have a common point of reference.
>I suppose this might be possible but it would be a fundamentally
>hard problem.
>
>    Just to get down to cases lets assume that Maple, for example
>(and I confess that it is years since I've actually used Maple so
>my examples might no longer hold true) and Axiom. Let me try to 
>illustrate why *I* believe the problem is harder than you might
>suspect.
>
>    First, there is the fundamental mismatch of the designs of
>the systems. I classify Maple as an "Engineering" system. That
>is, the Maple system is designed for ease of use. It strives to
>make the answers "work out ok". A subtle side-effect of this
>design are cases where you subtract two matrices and get a
>0 integer rather than the 0 matrix. This zero integer can be
>used in further computations unrelated to matrices.
>
>    I classify Axiom as a "theory" system. That is, Axiom is
>designed for correctness. It strives to make the answers match
>the theory. Thus, subtracting two matrices will give you a
>0 matrix. This strong typing is anything but easy to use. 
>
>    So the two systems started with different mindsets and
>virtually every level of the design is constructed to support
>that mindset. What is easy to write in 5 lines of Maple can
>take a great deal of struggle in Axiom. The reverse is also
>true.
>
>    OpenMath presumes that there are two systems that support
>its semantic definitions. That can be very hard for Maple if
>the semantics are deeply related to the type. It can be very
>hard for Axiom is the semantics are type-ambiguous.
>
>    Second, there is the semantic mismatch between Maple and
>Axiom. Axiom's mathematics assume an inheritance model, local
>scoping of variables in algebra code, etc. Maple's mathematics
>don't support inheritance, variables have global scope, etc.
>It's like the difference between Java and Basic. You made the
>point that surely Maple could be programmed to accept Axiom's
>types. Yes, it could but you'd end up building an Axiom
>interpreter in Maple's interpreter language. I fail to see
>how OpenMath would address such wildly differing environments
>like Java and Basic or like Maple and Axiom. A great deal of
>the semantics in Axiom's answers is encoded in the type. If
>I send an equation to Maple I need the correct type returned.
>It can't be lost or I've lost fundamental semantics.
>
>    Third, there is the syntactic mismatch. For primitive math
>you might hope that Maple and Axiom use the same notation, at
>least. Unfortunately this isn't true. Life gets much worse when
>you try to represent higher objects like Ideals or a Groebner
>basis.
>
>Even the integrate function, which they both support heavily,
>shares little, if any, syntax.
>
>    OpenMath is a good idea and is supported by a lot of clever
>people. It might succeed. I could even be classified as a 
>"mild supporter". But it doesn't stir my blood to want to write
>code for it. If you're interested, however, I'm willing to
>discuss ways to experiment with it. It is, after all, leading
>edge research (my definition of research is doing something no
>one in the world knows how to do) and Axiom has always been a
>great platform for doing research.
>
>  On Thu, 13 May 2004 10:03:12 +0100 Mike Dewar wrote:
>
>    There are two separate issues here.  The first is the problem
>of reading and writing streams of OpenMath tokens.  It is this
>which uses the underlying C Library code (which by the way will
>probably be obsolote soon: we are hoping to finalise OpenMath 2
>in the next week or two).
>
>The second is the question of serialising Axiom objects in
>OpenMath encodings.  This is done in Axiom code via the OpenMath
>category, but is only implemented for a few domains.
>
>  On Thu, May 13, 2004 at 09:47:00AM -0400, Tim Daly wrote:
>
>    Where can I get the new library?
>
>  On Thu, 13 May 2004 15:40:57 +0100 Mike Dewar wrote:
>
>    There isn't one as yet.  I don't know whether a library similar
>to the old INRIA one will be produced, the world has moved on and
>people tend to be using OpenMath much more as a document format
>than an interchange mechanism.  For those that do want to use it
>as an interchange mechanism, Java libraries that use mechanisms
>like SOAP, XML-RPC etc. are more useful than the old TCP/IP-based
>one.  
> 
>    ...  Everything else that you need is already freely available
>in browsers, implemented according to defined or de-facto standards.
>You can do text layout in XHTML, implement fancy folding menus
>with javascript, handle graphics with plug-ins to get interactivity
>and render the Maths with MathML.  If you want a hard-copy on the
>other hand, then its very easy to write an XSL stylesheet to
>produce LaTeX from your original document, or you can probably
>find existing tools to do this on the web.  This isn't fantasy
>by the way, its exactly what we are doing at NAG with our
>documentation and its proving very successful.
>
>    ... based on XML and thats just Lisp with fancy brackets :-)
>
>  On Thu, May 13, 2004 at 09:47:00AM -0400, Tim Daly wrote:
>
>    I don't see how to carry Axiom's Types in OpenMath's data
>representation.
>
>  On Thu, 13 May 2004 15:40:57 +0100 Mike Dewar wrote:
>
>    You use the OMATTR constructor to attribute the object with
>its Axiom type.  (In OpenMath 2 you can make this stronger by
>declaring it to be a semantic attribute.)  MathML has an element
>called "semantics" which allows you to do a similar thing, there
>is a whole document devoted to this problem at
>http://www.w3.org/TR/mathml-types
>
>    ... if I were in your position I would try and use generic
>technologies inside a browser, rather than do something ad-hoc.
>
>See also:
>
>  AxiomUI

\start
Date: Wed, 5 Oct 2005 07:23:57 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Web based bibtex

Bill, I'm assuming the Axiom Portal uses this for Bibliography stuff?
http://plone.org/products/cmfbibliographyat

I'm trying to figure out if it is searchable and can be organized by
category, but so far I'm not having much luck.  I think for future
purposes we will need something with search capabilities.  Also, if
possible, it would be nice to be able to identify which part(s) of
Axiom a particular paper is relevant to.

\start
Date: Wed, 5 Oct 2005 11:19:05 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Web based bibtex

On Wednesday, October 05, 2005 10:24 AM C Y wrote:
>
> Bill, I'm assuming the Axiom Portal uses this for Bibliography stuff?
> http://plone.org/products/cmfbibliographyat
>

Yes, but we are still at the previous older version
CMFBibliographyAT-0.4.

>From your link above I see that the current version is

http://plone.org/products/cmfbibliographyat/releases/0.7.0

CMF Bibliography AT 0.7.0

and that these is a new candidate release 0.8.0rc1.

That's good news! I think this a great product for plone and it's been
around for a while, but the original developer sort of lost interest.

The latest info is:

--------

A reference release to make the original status available before
the changes introduced with 0.8. Might be relevant for people using
it in custom settings already. New users should start with 0.8 or
above.

Available downloads

Download CMF Bibliography AT 0.7.0 for all platforms (108.6 kB)
Download CMF Bibliography AT 0.8.0rc1 for all platforms (111.0 kB)

First release since a long time. Therefore the version jump from 0.4
to 0.7. Too many changes to list them here. Most important addition
might be the BibTeX marshaller. Also, the package structure now
follows AT's conventions.
  Created by raphael
  Last modified 2005-09-16 06:53 AM

----------

I think it would be a good idea if we upgraded the MathAction site
to at least the new 0.7.0 version.

We are also a little behind in the Plone releases. The current Plone
is 2.1. On MathAction we are at 2.0.4.

All it takes is someone (like you! :) to say they are interested in
this and I would be glad to spend some time doing the upgrades.

> I'm trying to figure out if it is searchable

Yes, it is searchable by default as part of the plone portal
site. If you enter keywords in the search box on the upper right
some of the things you find will be BibTeX records. In the
Advanced Search you can limit the search to just BibTeX records.
See

http://page.axiom-developer.org/zope/Plone/search_form

Click 'Item type' ( ) Select All/None, then check off as many of
the *reference* types as you want. Enter some Search Text e.g.
"quadratic" and then click 'Search'. You should see 4 bibtex
references.

> and can be organized by category, but so far I'm not having much
> luck.

I don't know how to do that exactly, but I do know that it is
possible to have multiple bibliographies and to search them all
together or separately. In Plone we could organize the separate
bibliographies into a hierarchical folder structure.

> I think for future purposes we will need something with search
> capabilities.  Also, if possible, it would be nice to be able to
> identify which part(s) of Axiom a particular paper is relevant
> to.
>

I think that it is possible to add such notes to the bibtex entries.

\start
Date: Wed, 5 Oct 2005 10:44:21 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Web based bibtex

--- Bill Page wrote:

> Yes, but we are still at the previous older version
> CMFBibliographyAT-0.4.

Hmm.  OK.

[snip]
 
> That's good news! I think this a great product for plone and it's
> been around for a while, but the original developer sort of lost 
> interest.

Ah, no wonder.  I was doing a web search for online bibtex organizers,
which is how I stumbled onto the fact that you had already implemented
one!  ooops.

> I think it would be a good idea if we upgraded the MathAction site
> to at least the new 0.7.0 version.

Agreed.  It might be worthwhile to ask the developer about a) release
timeframe for 8.0 and b) how hard the migration path from 7.0 to 8.0 is
expected to be, when deciding.
 
> We are also a little behind in the Plone releases. The current Plone
> is 2.1. On MathAction we are at 2.0.4.
> 
> All it takes is someone (like you! :) to say they are interested in
> this and I would be glad to spend some time doing the upgrades.

Well, doing background work on Dimensional Analysis gives me the
impression that completely converting Axiom to literate programming
will result in a HUGE number of references, given how much of
mathematics it covers.  We might as well establish how to handle this
now.

> > I'm trying to figure out if it is searchable
> 
> Yes, it is searchable by default as part of the plone portal
> site. If you enter keywords in the search box on the upper right
> some of the things you find will be BibTeX records. In the
> Advanced Search you can limit the search to just BibTeX records.
> See
> 
> http://page.axiom-developer.org/zope/Plone/search_form

Ah!  Got it.

> Click 'Item type' ( ) Select All/None, then check off as many of
> the *reference* types as you want. Enter some Search Text e.g.
> "quadratic" and then click 'Search'. You should see 4 bibtex
> references.

Nice.  We should have some kind of documentation explaining what all
the categories actually refer to - for example, is the wiki search the
Axiom wiki + the Reduce wiki?

> > and can be organized by category, but so far I'm not having much
> > luck.
> 
> I don't know how to do that exactly, but I do know that it is
> possible to have multiple bibliographies and to search them all
> together or separately. In Plone we could organize the separate
> bibliographies into a hierarchical folder structure.

We might not need (or want) to do it that way - I was thinking more
along the lines of being able to search for (say) all papers referenced
by the Unit package, or the High Energy Physics package.  There might
be overlap in those two search results, which is fine, but we would
only want one bibtex entry to be shared between both, to help keep the
size reasonable.

BTY, who can add bibtex entries?  Is it just the site admin?  Clearly
there should be come kind of quality standard but I'm not sure how to
go about it.

> > I think for future purposes we will need something with search
> > capabilities.  Also, if possible, it would be nice to be able to
> > identify which part(s) of Axiom a particular paper is relevant
> > to.
> 
> I think that it is possible to add such notes to the bibtex entries.

That might be the best way - if we could have searchable notes on which
Axiom Domains (or whatnot) refer to a given paper.  Ideally that
information could be autogenerated, but I don't know how to go about
setting that up.  I think the Sixpack bibliography program can do that
but I don't know of any web interface like it.  Heh - maybe sixpack
could be reimplemented as a web interface.

IMHO we should figure out how to make this general and robust from the
beginning, because it will be very important to the literate
programming effort to have a good structure for references set up.

\start
Date: Wed, 5 Oct 2005 10:55:59 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: re: Web based bibtex

--- Cliff Yapp wrote:

> That might be the best way - if we could have searchable notes on
> which Axiom Domains (or whatnot) refer to a given paper.  Ideally 
> that information could be autogenerated, but I don't know how to go 
> about setting that up.  I think the Sixpack bibliography program can
> do that but I don't know of any web interface like it.

I said that poorly - I think sixpack can search keyword type
information, but not autogenerate it.  Sorry for any confusion.

\start
Date: Wed, 5 Oct 2005 15:18:04 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Web based bibtex

On Wednesday, October 05, 2005 1:44 PM C Y wrote:

> Bill Page wrote:
> > In the Advanced Search you can limit the search to just BibTeX
> > records. See
> >
> > http://page.axiom-developer.org/zope/Plone/search_form
>
> Ah!  Got it.
>
> > Click 'Item type' ( ) Select All/None, then check off as many
> > of  the *reference* types as you want. Enter some Search Text
> > e.g. "quadratic" and then click 'Search'. You should see 4
> > bibtex references.
>
> Nice.  We should have some kind of documentation explaining what
> all the categories actually refer to - for example, is the wiki
> search the Axiom wiki + the Reduce wiki?

First: It is important to remember that the Axiom Wiki

http://wiki.axiom-developer.org

is a completely separate web site from the Axiom Portal

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

The Axiom Wiki has it's own separate search function and no
bibliography.

It might be a bit confusing that there are also a set of pages
on the Portal called "Axiom Wiki". These pages are local to the
Portal - not the same as the ones on the wiki.axiom-developer.org.
And on the Portal there is another set of pages called "Reduce
Wiki". These pages are here primarily because I had not yet
decided whether it was better to support Axiom using a pure wiki
or whether to use a wiki pages embedded in the Plone portal
environment. Martin Rubey, who has spent a lot of time helping
develop the content on wiki.axiom-developer.org, does not
particularly like the Plone user interface. I agreed that Plone
is more complex so the primary site for Axiom became the
wiki.axiom-develop.org site by default. Plone on the other hand
might still be more suitable for registered users who want more
control over the content and structure of their web pages.

Some registered users of the portal (such as me :) also have
publicly accessible wiki pages in their personal folder.

So to summarize, you are right that if you check ( ) Wiki Page
in the Axiom portal advanced search, your search will include all
non-private Wiki pages anywhere on the Axiom portal. But this
does *not* include those pages on wiki.axiom-developer.org web
site.

Second: The 'Item type' checkbox categories actually refer to the
Plone object types/classes. Remember: The Zope web application
server, on which both ZWiki and Plone are based is a strongly-typed
object-oriented  database. (Yes, just like Axiom! :) Each page
in the database is an object of type.  The object type determines
the properties and methods that can act on that page. Wiki pages
are just one of the object types that are supported in Plone.
Zwiki, on the other hand only contains wiki page objects.

> ...
> BTY, who can add bibtex entries?  Is it just the site admin?

No. Any registered user of the Axiom Portal can add bibtex
entries. They can also create their own private bibliographies
and other private web content. Later they can make these
pages selectively visible to other registered users or they
can "publish" this content so that non-registered users can
also see it. (Publication requires approval of a user who is
designated as a 'reviewer'.)

> Clearly there should be come kind of quality standard but
> I'm not sure how to go about it.

I think simply requiring people to register is probably
sufficient to ensure some level of quality. After all, the
entire wiki.axiom-develop.org site is open and editable by
anyone, but in spite of that we actually have very little
spam or other inappropriate content on that site.

So I think in this environment, the best way to implement
a "quality standard" is just by having someone assume some
responsibility for creation and editing of public content.
This is just a matter of someone stepping forward and taking
the time to do it. If several people wanted to do that,
even better. The wiki and the portal are collaborative
environments and by design they are intended to foster
cooperation between collaborators... blah, blah...

>
> IMHO we should figure out how to make this general and
> robust from the beginning, because it will be very important
> to the literate programming effort to have a good structure
> for references set up.
>

I agree.

\start
Date: Wed, 5 Oct 2005 12:46:08 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Web based bibtex

--- Bill Page wrote:

> Martin Rubey, who has spent a lot of time helping
> develop the content on wiki.axiom-developer.org, does not
> particularly like the Plone user interface. I agreed that Plone
> is more complex so the primary site for Axiom became the
> wiki.axiom-develop.org site by default. 

I still think the Plone look is more "professional" than the wiki, but
I suppose that could be just a function of what I am accustomed to.  I
guess I just worry a little that people will visit the
www.axiom-developer.org address, see a page that looks pretty unlike
anything they might be used to, and conclude Axiom is not a serious
project.  I suppose people who would conclude that might not be the
target users for Axiom, granted...

> Plone on the other hand
> might still be more suitable for registered users who want more
> control over the content and structure of their web pages.

I am uneasy about doing any significant work in the Plone environment,
because I have a feeling it might never be part of the "active" Axiom
website (I doubt Plone-Axiom gets many web hits, for example.)  I would
prefer to work in just one environment, perhaps implementing an
alternative bibliography solution in the wiki or some such - maybe this
would be of interest? http://wikindx.sourceforge.net/index.html

I think there needs to be one solution, rather than risk fragmenting
efforts over several wildly different systems, but that's just me.

> > BTY, who can add bibtex entries?  Is it just the site admin?
> 
> No. Any registered user of the Axiom Portal can add bibtex
> entries. They can also create their own private bibliographies
> and other private web content. Later they can make these
> pages selectively visible to other registered users or they
> can "publish" this content so that non-registered users can
> also see it. (Publication requires approval of a user who is
> designated as a 'reviewer'.)

Hmm.  Nifty!  Can a user select a subset of entries to generate a
bibtex file, or is it only one at a time?

> > Clearly there should be come kind of quality standard but
> > I'm not sure how to go about it.
> 
> I think simply requiring people to register is probably
> sufficient to ensure some level of quality. After all, the
> entire wiki.axiom-develop.org site is open and editable by
> anyone, but in spite of that we actually have very little
> spam or other inappropriate content on that site.

That will hold unless/until we gain in popularity.  Then it's anybody's
guess.

> > IMHO we should figure out how to make this general and
> > robust from the beginning, because it will be very important
> > to the literate programming effort to have a good structure
> > for references set up.
> 
> I agree.

Another thought is that a "global" bibtex file generated from this
system could provide the foundation bib file for the Axiom codebase,
assuming one can be automatically generated.  Maybe we could even rig
up a way to have the codebase repository updated each time a
bibliography update is committed via web, and have the website updated
every time a new bibtex entry is put into the repository.

\start
Date: Wed, 5 Oct 2005 16:59:32 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Web based bibtex

On Wednesday, October 05, 2005 3:46 PM C Y
>
> I am uneasy about doing any significant work in the Plone
> environment, because I have a feeling it might never be
> part of the "active" Axiom website (I doubt Plone-Axiom
> gets many web hits, for example.)

The web site statistics for September

http://page.axiom-developer.org/usage/usage_200509.html

show 671 hits on /zope/plone/login_form - compared to the
4576 hits on /zope/mathaction/FrontPage that's pretty small.
But we are sort of comparing "apples to oranges". Many many
more people read pages from the Axiom wiki aka MathAction
compared to the number of people who edit them or even bother
to comment on them. It's a very public place.

The Plone site, on the other hand is primarily focused on
those people who might have some interest in creating some
content - either for their own use or for distribution to
others. So, actually I find 671 attempts to login as a
registered user of the Axiom portal rather impressive! But
still the evidence is that the majority of users still only
read content here also instead of creating it. :(

> I would prefer to work in just one environment,

It depends on what kind of "work" you want to do, doesn't
it? Both of these environments are built as Zope applications
so they have a lot in common in spite of the outer appearance.
In fact, it turns out that there is a way to configure zope
with ZWiki and Plone so that the same wiki content appears in
both user interfaces. The different user interfaces can be
completely controlled by applying different "skins". This means
that a user can, but default say access the site as if it
was "just" a wiki the way wiki.axiom-developer.org looks now.
But if they choose, they can click on a "Plone" link which
invokes the "portal skin" so that the other Plone bells and
whistles (e.g. the bibliography) become visible and the
wiki appears just as embedded in the portal. In the portal skin
they can then log in and also create private content etc.

In effect, I think this is the "best of both worlds" but it
is a little complicated to setup. I have a test version setup
here

http://test.axiom-developer.org/mathaction

Clicking on the "plone" link in the upper right corner asks you
to log in and then it displays the same wiki contents with the
Plone wrapper. I haven't had a lot of time to play with this,
so it may not be working quite 100% yet. But I would be quite
interested in your opinion of this effort.

The versions of Zope, Plone and ZWiki on which this test
environment was based are already quite out of date, although
they were current as of about 7 months ago.

I forget actually, exactly what I was doing with this test site
7 months ago beside the wiki/portal skin thing. Just looking at
it now I see that the LaTeX wiki part of the site seems broken
so perhaps that was when I was also experimenting with Bob
McElrath's then dvipng-based approach to generated graphics
from LaTeX.

Recently Bob and I have been discussing via #axiom-developer irc
some ideas about again upgrading MathAction to the newest releases
(including his latest LatexWiki stuff) *and* also setting up a
live mirror site for MathAction as a backup. I guess we think we
know how to do what we want to do, but of course then there is the
question of when and how to find the time to impermanent it. :(
There is never enough time... there is never enough time...

> perhaps implementing an alternative bibliography solution in the
> wiki or some such - maybe this would be of interest?
> http://wikindx.sourceforge.net/index.html
>

I am aware of WIKINDX. It's a nice effort but it lives in a very
different software environment than ZWiki and Plone::

  WIKINDX Requirements:

   1. PHP >= v4.3.x
   2. MySQL >= v3.23.xx
   3. Apache >= v1.3.x

PHP is the "other way" to design web applications these days -
probably more popular than Zope. The difference between Zope
and PHP is quite literally quite similar to the difference between
Axiom and Maxima. One of the difficulties of building applications
with Zope is the strongly typed object-oriented environment that
I mentioned earlier. On the other hand, if one is prepared to
invest the time to learn to use Zope properly, then it is possible
to build some rather sophisticated applications with very little
coding, compared to the large amount of (relatively easy) "hacking"
required to get a PHP application off the ground. It is essentially
the same thing with Axiom.

I rather like this accidental family relationship between Zope
and Axiom. In fact, it goes even deeper since Zope is implemented
in Python which is a strongly-typed (but dynamic) language with a
"pile" block syntax just like SPAD which is strongly-typed
(but static) programming language.

PHP on the other hand is essentially a variant of Perl - another
"engineering-oriented" language ;) to steal Tim Daly's phrase.

>
> Hmm.  Nifty!  Can a user select a subset of entries to
> generate a bibtex file, or is it only one at a time?
>

If you login in at

http://page.axiom-developer.org/zope/Plone/refs/axiombib

The 'download' tab will download the entire contents of
the Axiom bibliography as one large BibTeX file.

The 'contents' tab will allow you to delete and copy entries.

I don't know anyway how to download just a subset based on a
query. But perhaps there is some way to do this in the newer
release of the bibliography product.

>
> Another thought is that a "global" bibtex file generated from
> this system could provide the foundation bib file for the
> Axiom codebase, assuming one can be automatically generated.

Yes, this could be done automatically using crontab job and
wget to trigger the kind of 'download' that I described above.

> Maybe we could even rig up a way to have the codebase repository
> updated each time a bibliography update is committed via web,

Yes, at least it could be done nightly or whatever using wget.

> and have the website updated every time a new bibtex entry is
> put into the repository.
>

I am less sure how to do that but that is also likely possible
based on a tla -diff or something of that sort.

\start
Date: Wed, 05 Oct 2005 17:54:48 -0400
From: William Sit
To: Cliff Yapp
Subject: Units in a calculus problem using Maple

Dear CY:

I came across a problem in a calculus text that is an example of the kind of
care one has to be aware of in dealing with automatic dimensional analysis in
CAS.

>From Goldstein, Lay, and Schneider: Calculus & Its Applications, 10th ed.,
Pearson Education Inc., 2004. p. 181, Problem 26:

A ship uses 5x^2 dollars of fuel per hour when traveling at a speed of x miles
per hour. The other expenses of operating the ship amount to $2000 per hour.
What speed minimizes the cost of a 500-mile trip? [Hint snipped]

Imagine trying to do this problem and declaring that x has the dimension of
velocity. To verify that the expression written down to give the cost as a
function of x is dimensionally correct, the computer would have to know a priori
that the "constant" 5 actually has a dimension. With the proposed design, which
allows a declaration of an expression to be of a certain dimension, this can be
deduced, and implicitly the dimension for 5 can be ignored. It would be more
natural if one works on the expression level and view 5x^2 by itself of
dimension dollars per hour, and to ignore the  than if one is required to
declare the correct dimension for the number 5.

Entering the expression for cost in terms of x with units (except for 5) in
Maple will give this error:

> restart:
> interface(warnlevel=0):
> interface(displayprecision=4):
> with(Units):
> with(Units[Natural]):

> myCost := 500 * miles/(x * miles /hour) *(2000 * dollars/hour + 5 * (x * miles /hour)^2);

Error, (in Units:-Standard:-+) the units `USD/s` and `m^2/s^2` have incompatible
dimensions


Doing this problem step by step works better in Maple:


> distance:= 500* miles;

                         distance := 500 [mi]

Amazing: why wasn't [mi] converted to [m]?

> velocity:= x * miles/hour;

                                   1397
                       velocity := ---- x [m/s]
                                   3125

> fixedCost:= 2000*dollars/hour;

                                         [USD]
                        fixedCost := 5/9 [---]
                                         [ s ]

> fuelRate:= 5*x^2*dollars/hour;

                                         2 [USD]
                      fuelRate := 1/720 x  [---]
                                           [ s ]

Note: NOT 5*velocity^2*dollars/hour;

> cost:=distance/velocity * (fixedCost + fuelRate);

                                  /       2 \
                                  |      x  |
                          1800000 |5/9 + ---|
                                  \      720/
                  cost := ------------------- [USD]
                                   x

> a:=solve(diff(cost, x)=0,x);

                             a := 20, -20

> velocity;

                             1397
                             ---- x [m/s]
                             3125

> eval(velocity, x=a);

                              5588
                              ---- [m/s]
                              625

> eval(cost, x=a);

                             100000 [USD]
 

So far, so good.
Why isn't x = -20 not substituted? (Maple's Unit internals expect only positive
values?)
And, watch this:

> x: * miles/hour;

                                5588
                           x := ---- [m/s]
                                625

> cost;

         281250000 //      1951609       2\            (-1)\
         --------- ||5/9 + -------- [m/s] | [USD] [m/s]    |
           1397    \\      17578125       /                /

Yuks! A student may be at a loss with this. So there seems to be two types of
symbols: one of which is the kind no units should be attached? That would seem
very inconsistent.

Will Axiom do better?  Several improvement suggestions for Maple:

(1) remove all those multiplication operators!
(2) allow a declaration for the units of x so it can be implicit
(3) keep the units as inputted as much as possible and get rid of those
conversion factors (unless specifically asked to make the conversion by the
user)
(4) (not sure) allow automatic assignment of dimension/unit to numeric constants
to balance dimension in an expression (what physicists do) and give a warning

\start
Date: Wed, 05 Oct 2005 21:38:09 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Working example of pamphlet support on MathAction

See [SandBox Pamphlet] for a real working example of an Axiom
pamphlet file which renders as PDF and DVI.

Additional work is still required for:

  1 source code archive check-in

  2 pre-rendering of {axiom}, {spad}, {aldor} and {reduce}
    psuedo environments

\start
Date: Thu, 06 Oct 2005 07:29:12 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#214 limit on products and sums] (nouveau) 

It should be possible to teach Axiom to distribute limits through sums and products as in
\begin{axiom}
limit(product((1-q^(N-i))/(1-q^(m-i)),i=0..m-1),q=1)
\end{axiom}

However, it is not clear to me where this should be done. Limits of this kind are currently handled in 'limitps.spad', where  Axiom tries to do a Puiseux expansion of the expression.

\start
Date: Thu, 6 Oct 2005 06:37:51 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Web based bibtex

--- Bill Page wrote:

> The web site statistics for September
> 
> http://page.axiom-developer.org/usage/usage_200509.html
> 
> show 671 hits on /zope/plone/login_form - compared to the
> 4576 hits on /zope/mathaction/FrontPage that's pretty small.
> But we are sort of comparing "apples to oranges". Many many
> more people read pages from the Axiom wiki aka MathAction
> compared to the number of people who edit them or even bother
> to comment on them. It's a very public place.

Just curious - is each visit to the page logged as a "hit" or is it
unique IP addresses?  (Not a criticism, I'm just interested - counting
web statistics is not as straightforward as one might hope.)

> The Plone site, on the other hand is primarily focused on
> those people who might have some interest in creating some
> content - either for their own use or for distribution to
> others. So, actually I find 671 attempts to login as a
> registered user of the Axiom portal rather impressive! But
> still the evidence is that the majority of users still only
> read content here also instead of creating it. :(

I'm working on that - there's a lot of research to do before I'll feel
confident to contribute even basic stuff for Axiom - I want to be able
to maintain the extremely high quality standards.  This ain't your
typical "hack on it for a few evenings" open source project! :-). 
(That's a good thing.)
 
> > I would prefer to work in just one environment,
> 
> It depends on what kind of "work" you want to do, doesn't
> it? Both of these environments are built as Zope applications
> so they have a lot in common in spite of the outer appearance.
> In fact, it turns out that there is a way to configure zope
> with ZWiki and Plone so that the same wiki content appears in
> both user interfaces.

Neat!

> The different user interfaces can be
> completely controlled by applying different "skins". This means
> that a user can, but default say access the site as if it
> was "just" a wiki the way wiki.axiom-developer.org looks now.
> But if they choose, they can click on a "Plone" link which
> invokes the "portal skin" so that the other Plone bells and
> whistles (e.g. the bibliography) become visible and the
> wiki appears just as embedded in the portal.
> In the portal skin they can then log in and also create private 
> content etc.

Wow - I had no idea of the flexibility available in these systems.

> In effect, I think this is the "best of both worlds" but it
> is a little complicated to setup. I have a test version setup
> here
> 
> http://test.axiom-developer.org/mathaction
> 
> Clicking on the "plone" link in the upper right corner asks you
> to log in and then it displays the same wiki contents with the
> Plone wrapper. I haven't had a lot of time to play with this,
> so it may not be working quite 100% yet. But I would be quite
> interested in your opinion of this effort.

I love it!  I tried to set up a login but it doesn't like my yahoo
email address for some reason.  
 
> Recently Bob and I have been discussing via #axiom-developer irc
> some ideas about again upgrading MathAction to the newest releases
> (including his latest LatexWiki stuff) *and* also setting up a
> live mirror site for MathAction as a backup. I guess we think we
> know how to do what we want to do, but of course then there is the
> question of when and how to find the time to impermanent it. :(
> There is never enough time... there is never enough time...

Amen.
 
> > perhaps implementing an alternative bibliography solution in the
> > wiki or some such - maybe this would be of interest?
> > http://wikindx.sourceforge.net/index.html
> > 
> 
> I am aware of WIKINDX. It's a nice effort but it lives in a very
> different software environment than ZWiki and Plone::
> 
>   WIKINDX Requirements:
> 
>    1. PHP >= v4.3.x
>    2. MySQL >= v3.23.xx
>    3. Apache >= v1.3.x

Oooh.  Good point.

> PHP is the "other way" to design web applications these days -
> probably more popular than Zope. The difference between Zope
> and PHP is quite literally quite similar to the difference between
> Axiom and Maxima. One of the difficulties of building applications
> with Zope is the strongly typed object-oriented environment that
> I mentioned earlier. On the other hand, if one is prepared to
> invest the time to learn to use Zope properly, then it is possible
> to build some rather sophisticated applications with very little
> coding, compared to the large amount of (relatively easy) "hacking"
> required to get a PHP application off the ground. It is essentially
> the same thing with Axiom.

Heh - I'm convinced :-).  It's quite fitting that the website is done
the "Axiom" way.

> I rather like this accidental family relationship between Zope
> and Axiom. In fact, it goes even deeper since Zope is implemented
> in Python which is a strongly-typed (but dynamic) language with a
> "pile" block syntax just like SPAD which is strongly-typed
> (but static) programming language.

I really should read up on Zope.  I tend to shy away from web based
environments (I don't like needing an active internet connection) but
since this is hardly an either/or situation...

[snip]
 
> > Another thought is that a "global" bibtex file generated from
> > this system could provide the foundation bib file for the
> > Axiom codebase, assuming one can be automatically generated.
> 
> Yes, this could be done automatically using crontab job and
> wget to trigger the kind of 'download' that I described above.
>
> > Maybe we could even rig up a way to have the codebase repository
> > updated each time a bibliography update is committed via web,
> 
> Yes, at least it could be done nightly or whatever using wget.

Would that be safe, do you think?  I assume one of the benefits of
content management is that we could just roll back any vandalism that
occurs?

It would be really neat to expose the bibliography like that, IMHO -
whenever any of us find something we should have in there, we could
just flip open the web browser, log in, add the bibtex info with a few
comments about what part of Axiom it pertains to (maybe we could add a
pulldown menu with "standard" choices) and hey-presto it's not only on
the web but part of the Axiom codebase!  I usually stumble onto papers
I'm interested in while web browsing - it would be really neat to be
able to add them in right away.  Or perhaps, to have some semblance of
order, we could have individual bibliographies for each user, and then
we could "submit" entries for entry into the global file which could be
reviewed by two other people (to avoid things like dupes, ensure they
are relevant, etc.).
 
> > and have the website updated every time a new bibtex entry is
> > put into the repository.
>
> I am less sure how to do that but that is also likely possible
> based on a tla -diff or something of that sort.

I guess it could be done once an hour or something like that -
immediate update is probably too difficult.  The only way I can think
of offhand is to use some kind of file monitor or something to watch
the bib file and trigger events if it is changed, and I doubt that's
worth the trouble.

\start
Date: Thu, 6 Oct 2005 07:32:35 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Units in a calculus problem using Maple

--- William Sit wrote:

> Dear CY:
> 
> I came across a problem in a calculus text that is an example of the
> kind of care one has to be aware of in dealing with automatic 
> dimensional analysis in CAS.
> 
> From Goldstein, Lay, and Schneider: Calculus & Its Applications, 10th
> ed., Pearson Education Inc., 2004. p. 181, Problem 26:
> 
> A ship uses 5x^2 dollars of fuel per hour when traveling at a speed
> of x miles per hour. The other expenses of operating the ship amount
> to $2000 per hour.
> What speed minimizes the cost of a 500-mile trip? [Hint snipped]
> 
> Imagine trying to do this problem and declaring that x has the
> dimension of velocity. To verify that the expression written down
> to give the cost as a function of x is dimensionally correct, the 
> computer would have to know a priori that the "constant" 5 actually 
> has a dimension. With the proposed design, which allows a 
> declaration of an expression to be of a certain dimension, this can 
> be deduced, and implicitly the dimension for 5 can be ignored.

Hmm.  An interesting case.  For starters, the unit dollars and the unit
miles per hour are not from the same type of UnitSystem - miles and
hours are from Physical Units while dollars is from Economic Units. 
There are no well defined algorithms for correspondance between these
two systems - the equation d [dollars/hour] = 5*(x [miles/hour])^2 is
in fact defining the "translation" from Physical Units to Economic
Units for this particular problem, and even there it is not unique.  I
could say equally well (even in the same problem) that ship2 uses 3*x^4
dollars of fuel per hour.  The conclusion would seem to be that
dimensional and unit equality between different types of UnitSystems is
meaningless as far as ensuring any kind of correctness is concerned. 
The real difficulty is the term "hours" - this is a physical concept,
not an economic one.  Also, we still have the problem of ensuring
correctness in Economic Units and Physical Units respectively - e.g. if
x has specific units fixed at miles/hour we need to ensure any specific
value assigned to x has a) dimension of velocity and b) is converted to
miles/hour before assignment.  Likewise, if we tried to add the cost of
some ship3 which has its costs defined in terms of (say) 2*x^6 cents of
fuel per day to the cost of ship1 we need to make sure that ship3 is
converted to dollars/hour prior to that conversion.  (Assuming dollars
is the "global" currency unit.)

> It would be more natural if one works on the expression level and 
> view 5x^2 by itself of dimension dollars per hour, and to ignore 
> the  than if one is required to declare the correct dimension for 
> the number 5.

Rather than think about 5 as having dimension, I prefer to think that
the Economic Unit System and the Physical Unit System can be delt with
separately.  So, rather than trying to make the jump from velocity^2 ->
dollars/hour, I prefer to address each side of the equation separately
without insisting on Physical Unit equality.  This works since
"dollars" can adsorb any arbitrary Physical Units.  So, in the "short
form" Axiom input, defining this relationship would look something
like:

d := 5*(x [miles/hour])^2 [dollars/hour];

This expression would have a rather complex Axiom type, but the
Physical Unit System would worry about this only insofar as to ensure
that any assignment to x is in terms of miles/hour, and that any
interaction of the quantity dollars/hour with (say) cents/day works by
converting from cents/day -> cents/hour.  After that, it's up to the
Economic Unit system.  So when an assignment to x is made, the Physical
Unit System is the one which will insist on the correctness of any
assignment. The Economical Unit System uses only the numbers, and
coherces the result into the Economic units of dollars/hour, with
dimension <Money>/<Time>.  So now we have some quantity a
[dollars/hour].  If we want to then add b[cents/day] to that, we first
check dimensions -> Money = Money, and Time = Time, so that's OK.  Now
for conversions, we treat the top and bottom units separately.  Money
is an Economic Unit, so the Economic subroutines are called to find the
factor 1/100 and multiply by it.  Because Time is a Physical Quantity,
the Physical subroutines find the factor of 24 and multiply by that.

Essentially, I think the general property needs to be that when
Economic units are involved, dimensional equality needs to be somewhat
redefined.  What the EXACT rules should be I don't know, but this is
why I prefer to stick to physical units until they are fully
straightened out.

> Doing this problem step by step works better in Maple:

> > fuelRate:= 5*x^2*dollars/hour;
> 
>                                          2 [USD]
>                       fuelRate := 1/720 x  [---]
>                                            [ s ]
> 
> Note: NOT 5*velocity^2*dollars/hour;

Here, you have sidesteped the issue by never assigning x any specific
dimension, but treating it like a number.  This is OK, since that's
what would be done by a human working out this problem, but it does
sort of dodge the issue. 
 
> > cost:=distance/velocity * (fixedCost + fuelRate);
> 
>                                   /       2 \
>                                   |      x  |
>                           1800000 |5/9 + ---|
>                                   \      720/
>                   cost := ------------------- [USD]
>                                    x
> 
> > a:=solve(diff(cost, x)=0,x);
> 
>                              a := 20, -20
> 
> > velocity;
> 
>                              1397
>                              ---- x [m/s]
>                              3125
> 
> > eval(velocity, x=a);
> 
>                               5588
>                               ---- [m/s]
>                               625
> 
> > eval(cost, x=a);
> 
>                              100000 [USD]
> So far, so good.

Right - you "hid" the dimensional information associated with x for the
purpose of the calculation, if I understand correctly.  When you solved
for x, you got back only a number.  I'm not sure if this is compatible
with Axiom's approach.

> Why isn't x = -20 not substituted? (Maple's Unit internals expect
> only positive values?)
> And, watch this:
> 
> > x: * miles/hour;
> 
>                                 5588
>                            x := ---- [m/s]
>                                 625
> 
> > cost;
> 
>          281250000 //      1951609       2\            (-1)\
>          --------- ||5/9 + -------- [m/s] | [USD] [m/s]    |
>            1397    \\      17578125       /                /
> 
> Yuks! A student may be at a loss with this. So there seems to be two
> types of symbols: one of which is the kind no units should be
> attached? That would seem very inconsistent.

Hmm.  I need to think about that last expression a bit.

> Will Axiom do better?  Several improvement suggestions for Maple:
> 
> (1) remove all those multiplication operators!
> (2) allow a declaration for the units of x so it can be implicit
> (3) keep the units as inputted as much as possible and get rid of
> those conversion factors (unless specifically asked to make the 
> conversion by the user)

This should be configurable.  Sometimes you want to automatically
convert everything.

> (4) (not sure) allow automatic assignment of dimension/unit to
> numeric constants to balance dimension in an expression (what 
> physicists do) and give a warning

Maybe, but I think keeping Economic and Physical units separate will
help solve a lot of the problem.  I'll take another look later when
I've got more time.

\start
Date: Fri, 7 Oct 2005 16:13:20 +0200
From: Martin Rubey
To: list
Subject: series for sums 

Dear all,

in an attempt to teach axiom to handle limits of sums and products, as in

limit(product((1-q^(N-i))/(1-q^(m-i)),i=0..m-1),q=1)

I ended up with the following patch to fs2ups.spad

    kernelToUPS(ker,posCheck?,atanFlag) ==
      -- converts a kernel to a power series
      (sym := symbolIfCan(ker)) case Symbol =>
        (sym :: Symbol) = x => [monomial(1,1)]
        [monomial(ker :: FE,0)]
      empty?(args := argument ker) => [monomial(ker :: FE,0)]
      not member?(x, variables(ker :: FE)) => [monomial(ker :: FE,0)]
      empty? rest args =>
        arg := first args
        is?(ker,"abs" :: Symbol) =>
          nthRootToUPS(arg*arg,2,posCheck?,atanFlag)
        is?(ker,"%paren" :: Symbol) => exprToUPS(arg,posCheck?,atanFlag)
        is?(ker,"log" :: Symbol) => logToUPS(arg,posCheck?,atanFlag)
        is?(ker,"exp" :: Symbol) =>
          applyIfCan(expIfCan,arg,"exp",posCheck?,atanFlag)
        tranToUPS(ker,arg,posCheck?,atanFlag)
      is?(ker,"%power" :: Symbol) => powToUPS(args,posCheck?,atanFlag)
      is?(ker,"nthRoot" :: Symbol) =>
        n := retract(second args)@I
        nthRootToUPS(first args,n :: NNI,posCheck?,atanFlag)
!     is?(ker,"%defsum" :: Symbol) =>
!       (summand := exprToUPS(first args,posCheck?,atanFlag)) case %problem => 
!         summand
!       op := operator("%defsum"::Symbol)$CommonOperators
!       mp:FE->FE:=op cons(#1, rest args)
!       [map(mp, summand.%series)$UPS]

      stateProblem(string name ker,"unknown kernel")

which nearly works. In fact, mathematically, everything is (nearly)
OK. However, there is an evaluation problem:

(58) -> series(sum(i^x,i=1..m),x=1)

   (58)
     %defsum(%CD,%CD,i,1,m) + %defsum(%CD log(%CD),%CD,i,1,m)(x - 1)
   + 
                         2
             %CD log(%CD)                   2            3
     %defsum(-------------,%CD,i,1,m)(x - 1)  + O((x - 1) )
                   2
                        Type: UnivariatePuiseuxSeries(Expression Integer,x,1)


Does anybody know how to make axiom to evaluate these sums? Note that
%defsum(%CD,%CD,i,1,m) is

sum(i,i=1..m)=m*(m+1)/2

of course, %defsum(%CD log(%CD),%CD,i,1,m) will not simplify, it should simply
be displayed as a sum. I suspect that the problem is in map$UPS, but I don't
really know...

\start
Date: Fri, 7 Oct 2005 16:36:19 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: series for sums 

Well, here is a stupid alternative, which works better on the surface:

      if FE has CombinatorialOpsCategory then
        is?(ker,"%defsum" :: Symbol) =>
          (summand := exprToUPS(first args,posCheck?,atanFlag)) case %problem => 
            summand
--          op := operator("%defsum"::Symbol)$CommonOperators
--          mp:FE->FE:=op cons(#1, rest args)
          eq := equation(retract(third args)@Symbol, args.4..args.5)$SegmentBinding(FE)
          mp:FE->FE:=summation(eval(#1, retract(second args)@K, third args), eq)
          [map(mp, summand.%series)$UPS]

now Axiom displays beautiful sums, but they won't be evaluated because of a bug
equivalent to issue #212.

The summation design is seriously broken, I'd say.

\start
Date: Fri, 7 Oct 2005 17:57:22 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: series for sums 

Dear all,

I'm just trying to do the same for products, however, I came across a little
mathematical difficulty. It seems to obtain the coefficient of x^k I need to 

* generate all compositions of k

* for each composition (i1,i2,..,il), generate a multiple sum of the form

  sum(a(i1,j1)*a(i2,j2)*...*a(il,jl),j1<j2<...<jl)

Of course this is doable (although I will have to use ugly newsymbols for the
j's), but I wonder whether somebody can think of a better alternative.

Martin

Martin Rubey writes:
 > Well, here is a stupid alternative, which works better on the surface:
 > 
 >       if FE has CombinatorialOpsCategory then
 >         is?(ker,"%defsum" :: Symbol) =>
 >           (summand := exprToUPS(first args,posCheck?,atanFlag)) case %problem => 
 >             summand
 > --          op := operator("%defsum"::Symbol)$CommonOperators
 > --          mp:FE->FE:=op cons(#1, rest args)
 >           eq := equation(retract(third args)@Symbol, args.4..args.5)$SegmentBinding(FE)
 >           mp:FE->FE:=summation(eval(#1, retract(second args)@K, third args), eq)
 >           [map(mp, summand.%series)$UPS]
 > 
 > now Axiom displays beautiful sums, but they won't be evaluated because of a bug
 > equivalent to issue #212.
 > 
 > The summation design is seriously broken, I'd say.

\start
Date: Fri, 07 Oct 2005 11:47:12 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#215 sin asin(7.0::COMPLEX FLOAT)] (new) 

\begin{axiom}
sin asin(7.0::COMPLEX FLOAT)
\end{axiom}
normal result: 7.0

\start
Date: Fri, 07 Oct 2005 12:45:30 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

This is impossible for me to view.

Acroread on linux has serious stability issues and consistently
crashes my browser or forcibly grabs my mouse and won't let go.  All
open-source pdf viewers (xpdf, gpdf, etc) have inferior font rendering
and often cannot anti-alias the fonts.

The net result is that any user has to jump through a ton of hoops
just to look at these pamphlet pages, and in the end, they're
bypassing the chosen medium (the web) altogether!

While the rendering quality of the latexwiki-image or mathml is
currently inferior, I don't think jumping through all these hoops is
worth the small increase in rendering quality.  Instead, I think we
should use the technologies built into the browser already
(images/mathml) and push the browser developers to improve their
rendering quality.

For instance, the mozilla people have just checked in a "patch which
improves printing of transparent
png's":https://bugzilla.mozilla.org/show_bug.cgi?id=141656.
Previously they printed black-on-black and were unreadable.  Another
recently checked-in patch "properly aligns equations that are
generated by
latex2html":https://bugzilla.mozilla.org/show_bug.cgi?id=192077.

Undoubtedly, we will encounter many bugs in the rendering of mathml.
But, I think pushing forward with "math on the web" is a desirable
goal, and sidestepping the problem by embedding pdf will hurt rather
than help the whole situation.  It seems to me the natural migration
route is send images for old browsers, mathml for new browsers, and
report bugs against the browsers when this falls down.

I know current pamphlets are a latex format, but the subset of latex
actually used is quite small.  There are two ways to go here...1)
write a zwiki "pagetype" which renders the subset, or 2) call
latex2html or tth (or some other tool) on the backend to render as
html with embedded images or mathml.

Unfortunately I am quite busy and won't be able to work on this any
time soon.  :(

-- Bob

\start
Date: Fri, 07 Oct 2005 13:23:39 -0500
From: MathAction (root)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

Is it possible to get a handle to a "canvass" in a browser?
If so it would be possible to do both graphics and a dvi mechanism.

\start
Date: Fri, 07 Oct 2005 13:25:31 -0500
From: MathAction (Bob McElrath)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

> Is it possible to get a handle to a "canvass" in a browser?
> If so it would be possible to do both graphics and a dvi mechanism.

Yes, SVG has this capability.

\start
Date: Fri, 07 Oct 2005 13:27:37 -0500
From: MathAction (root)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

Actually, in answer to my canvas question:
http://developer.mozilla.org/en/docs/Canvas_tutorial

shows that it possible to use a <canvas> tag and draw into it.

Tim

\start
Date: Fri, 07 Oct 2005 13:32:00 -0500
From: MathAction (Bob McElrath)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

root [MathAction] wrote:
> shows that it possible to use a <canvas> tag and draw into it.

Coooooolllll....

http://mozilla.doslash.org/stuff/canvas/shell.html

\start
Date: Fri, 07 Oct 2005 13:47:49 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

> 
> The net result is that any user has to jump through a ton
> of hoops just to look at these pamphlet pages, and in the
> end, they're bypassing the chosen medium (the web)
> altogether!
>

That's odd. It worked "right out of the box" for me using
Konquorer on Fedora Core 3. Even the embed PDF looks nice
with properly aliased fonts. I didn't have to touch a thing.
It doesn't seem like "bypassing the web" to me, although
using a proprietary format like PDF is admittedly not very
compatible with the open source philosphy.
 
Increasing rendering quality is not the objective of pamphlet
support. The goal is to provide a source format that is
identical to the noweb file format used by the Axiom
distribution. It should be possible to edit Axiom pamphlet
files through the web and have the result displayable in a
format that allows the quality to be checked and the changes
in code re-compile. This pages can then be directly included
in the Axiom source archive.

Being able to view pamphlet files online is an "extra"
feature that may work better on some configurations than
others. That is why I provided a link to the dvi. To bad
there doesn't seem to be an "embedded dvi viewer"...

> 
> I know current pamphlets are a latex format, but the subset 
> of latex actually used is quite small.  There are two ways
> to  go here...1) write a zwiki "pagetype" which renders the 
> subset,

Pamphlet files are latex plus noweb markup with embedded
code. I tried rendering just a subset of latex (see previous
work) but that ate a lot of time and failed.

> or 2) call latex2html or tth (or some other tool) on the
> backend to render as html with embedded images or mathml.
>

Maybe, but integration with Zwiki/LatexWiki is a pain.
 
> Unfortunately I am quite busy and won't be able to work
> on this any time soon.  :(
> 
> Just my 2 cents.
> 

And there-in lies **all** of our problems. :)

\start
Date: Fri, 07 Oct 2005 13:54:00 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

> 
> ... "canvass" in a browser?
> If so it would be possible to do both graphics and a dvi
> mechanism.
> 

Neat stuff! I think especially interesting for AxiomUI ...
but does it really do dvi?

\start
Date: Fri, 07 Oct 2005 14:09:12 -0500
From: MathAction (root)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

dvi plugin from several places. this page appears to claim that techexplorer
can do it:

http://www.damtp.cam.ac.uk/user/kp229/ndvi

\start
Date: Fri, 07 Oct 2005 14:15:32 -0500
From: MathAction (C Y)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

--- Bill Page <MathAction> wrote:

> That's odd. It worked "right out of the box" for me using
> Konquorer on Fedora Core 3. Even the embed PDF looks nice
> with properly aliased fonts. I didn't have to touch a thing.
> It doesn't seem like "bypassing the web" to me, although
> using a proprietary format like PDF is admittedly not very
> compatible with the open source philosphy.

I must be misunderstanding something - AFAIK pdf isn't proprietary. 
It's fully documented, and there is no restriction on creating either
viewers or generaters for it.  In what sense it is more or less
proprietary than postscript or dvi or mathml?

Now the open source viewers might not quite be up to the Acrobat Reader
standard in rendering quality, but to the best of my knowledge that
isn't because pdf is proprietary.  (BTY, I recommend the recent
releases of kpdf - it is getting quite good.)

\start
Date: Fri, 07 Oct 2005 14:27:48 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] ndvi

If anyone can get ndvi to work with FireFox then I will get
very excited.

Yes, "techexplorer can do it" (and a lot more too!) but
unfortunately techexplorer went proprietary :( and that's
where it sits ... Techexplorer used to be part of the
commercial distribution of Axiom on windows. I **wish**
that we could have kept it as part of the open source
version of Axiom!!

\start
Date: Fri, 07 Oct 2005 14:29:50 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] real demonstration of pamphlet files

In can anyone hasn't notice the new link on the FrontPage
you can see some real examples of Axiom pamphlet files here:

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

\start
Date: Fri, 07 Oct 2005 16:14:38 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] 

\begin{axiom}
P:=matrix[[a, b], [1.0 - a, 1.0 - b]]
eigenvectors(P)

\end{axiom}

\start
Date: Fri, 07 Oct 2005 20:03:30 -0500
From: MathAction (Ed Borasky)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

unknown wrote:

>Changes http://wiki.axiom-developer.org/210PamphletSupportOnMathAction/diff
>--
>This is impossible for me to view.

>Acroread on linux has serious stability issues and consistently
 crashes my browser or forcibly grabs my mouse and won't let go.  All
 open-source pdf viewers (xpdf, gpdf, etc) have inferior font
 rendering and often cannot anti-alias the fonts.
  

I've had a few problems with Acroread 7 on Linux but for the most part 
they only happen when viewing a PDF off the web with Firefox. If you 
download the file to your hard drive and open it, it should work fine. 
Be sure you have the latest Acroread and Firefox. What distro are you 
running?

>While the rendering quality of the latexwiki-image or mathml is
 currently inferior, I don't think jumping through all these hoops is
 worth the small increase in rendering quality.  Instead, I think we
 should use the technologies built into the browser already
 (images/mathml) and push the browser developers to improve their
 rendering quality.
  
Yes, I agree. Have you tried Amaya? They're trying to be the "reference 
browser", and I know they want to fix any rendering issues. I'm on their 
mailing list.

>Undoubtedly, we will encounter many bugs in the rendering of mathml.
 But, I think pushing forward with "math on the web" is a desirable
 goal, and sidestepping the problem by embedding pdf will hurt rather
 than help the whole situation.  It seems to me the natural migration
 route is send images for old browsers, mathml for new browsers, and
 report bugs against the browsers when this falls down.

Yes, I agree. Start with Amaya; they're likely to be more responsive 
than Firefox/Mozilla.

\start
Date: Fri, 07 Oct 2005 21:37:07 -0500
From: MathAction (michel.lavaud)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

On 7 Oct 2005 at 14:15, C Y wrote:

> I must be misunderstanding something - AFAIK pdf isn't proprietary.
> It's fully documented, and there is no restriction on creating either
> viewers or generaters for it.  In what sense it is more or less
> proprietary than postscript or dvi or mathml?

The pdf format is proprietary _and_ fully documented - as is the Word
format. And what Microsoft did, Adobe can do it : that is, he can
decide some day to change the pdf format in a way incompatible with
previous versions (as MS did for Word - to enhance performances, or
increase his income or whatever reason), users cannot do anything
against that. And if the modifications are not strictly upward
compatible with preceding ones, some formulas included in scientific
articles could become inexact, without the author being aware of it,
and without the reader being able to notice it :for texts, the reader
can easily detect and correct errors while reading, but this is
impossible for formulas, in general.This could be as catastrophic for
science as the burning of Alexandria's library.

Unfortunately, many scientists are not aware of this problem with
pdf. Even among TeX developers, many promote replacing dvi by pdf. Pdf
is acceptable for short-life documents, but not (IMHO) for scientific
documents : only exactness certified over very long periods of time
ought to be taken into consideration for science. It does not seem
reasonable to rely on proprietary formats such as Word or pdf and
cross one's fingers, hoping they won't do something wrong. Because
some day, they will :-(

The most critical community against pdf lately were not scientists but
lawyers, because of Enron and other affairs, that generated "tons" of
electronic documents, and they fear that these documents could become
unreadable in the long term. The problem of defining an A-pdf format
(Archival-pdf) was resurrected on this occasion.  For scientists, I
think it would be important that everybody realize the problem, before
our libraries of pdf documents "burn".  The dvi format is completely
safe because it is frozen and very simple, and is very well suited
because it has been devised for science.

\start
Date: Fri, 07 Oct 2005 21:49:50 -0500
From: MathAction (root)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] Math on the web

Actually, I continue to maintain the position that documents should be
available in SOURCE form, not pdf, not dvi, etc. Only source allows you
the ability to use the information in any way.

\start
Date: Sun, 9 Oct 2005 01:20:35 -0400
From: Bill Page
To: list
Subject: PDF/A and pamphlet support on MathAction

Since this is not directly related to the original issue
tracker entry for Pamphlet support in MathAction, I decided
to move this discussion to the axiom-developer email list.
Later I can put a summary on the web site if it seems useful.

On 7 Oct 2005 at 14:15, C Y wrote:

> I must be misunderstanding something - AFAIK pdf isn't
> proprietary. It's fully documented, and there is no
> restriction on creating either viewers or generators for
> it. In what sense it is more or less proprietary than
> postscript or dvi or mathml?

On October 7, 2005 10:37 PM michel.lavaud wrote:

> The pdf format is proprietary _and_ fully documented - as 
> is the Word format. And what Microsoft did, Adobe can do
> it: that is, he can decide some day to change the pdf format
> in a way incompatible with previous versions (as MS did for
> Word) ...

I think this comparison to WORD is at best inaccurate. Even
Richard Stallman - defender of free software - was willing
to accept PDF format email attachments as early as 2002.

http://www.gnu.org/philosophy/no-word-attachments.html

In his recommended response to the receipt of an email
with a WORD attachment he wrote:

"You sent the attachment in Microsoft Word format, a secret
proprietary format, so I cannot read it. If you send me
the plain text, HTML, or PDF, then I could read it."

> 
> The most critical community against pdf lately were not 
> scientists but lawyers, because of Enron and other affairs,
> that generated "tons" of electronic documents, and they
> fear that these documents could become unreadable in 
> the long term. The problem of defining an A-pdf format
> (Archival-pdf) was resurrected on this occasion.

Apparently this movement was successful. :)

So I think C Y is right. At least now there is a version
of PDF that is no longer proprietary. It seems that PDF has
recently been accepted as a standard by the International
Standards Organization.

"More exactly, it's ISO 19005-1:2005, "Document management-
Electronic document file format for long-term preservation-
Part 1: Use of PDF 1.4 (PDF/A-1)".

See:

http://www.pdfzone.com/article2/0,1895,1859083,00.asp

"ISO Approves PDF/A
By Nettie Hartsock
September 14, 2005 	

The International Organization for Standardization has
approved PDF/A, a standard for creating PDF documents for
long-term archiving.

"This document will ensure that a PDF document will be
rendered as it was created 50 years from now regardless
of the reader used," said Betsy Fanning, director of
standards and content for AIIM, a non-profit international
organization dealing with enterprise content management.
AIIM and NPES, an organization representing suppliers for
the printing and publishing industries, initiated the work
on a standard in 2002, said Fanning."

"Fanning said the PDF/A standard defines an open file
format for PDF archiving of electronic documents, with no
proprietary language. PDF/A is a subset of PDF."

On October 7, 2005 10:50 PM Tim Daly wrote:
> --
> Actually, I continue to maintain the position that documents
> should be available in SOURCE form, not pdf, not dvi, etc.
> Only source allows you the ability to use the information
> in any way.
> 

Of course this depends on what you mean by "use". If you
were a lawyer or historian and your purpose was to prove a
point about authorship or priority of discovery, then most
source documents in and of themselves would be of little
use. PDF format at least does contain some limited information
about the document (meta data) in addition to the ability
to render (when it was created, by who, by what software
etc.)

On the other hand original source is ok *provided* that it
is accompanied by a reliable long term archival storage.
This is one of the functions provided by the eprint archive
http://www.arXiv.org

Although the arXiv still prefers to archive TeX source
if possible (and derives other formats like PDF from these
sources), it does permit submissions in PDF format.

http://arxiv.org/help/submit_pdf

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

But in Axiom we are primarily talking about sharing scientific
research via literate programming, i.e. mathematical documents
that contain embedded computer algebra programs. Providing a
document format like PDF which would allow source code to be
extracted in a compilable form but not the original source text
seems rather pointless. Perhaps what we need instead is a widely
accepted archival service something like arXiv but which would
accepts e-prints in a literate programming format. From this
point of view, it seems to me that Tim's choice of noweb as the
basis for Axiom's "pamphlet" format was a wise one.

So one thing that I am trying to do with the new support for
Pamphlet format on MathAction is to allow the creation of an
archive of this kind. And because this approach is fully
general, this also provides the basis for further development
of the Axiom system itself which is already represented in
the form of a complete set of pamphlet files.

On MathAction pamphlet files are stored in their original
source format but can be delivered in a variety of ways:
as PDF documents (either embedded in HTML in the browser
or downloaded as a separate file), dvi format documents,
as complete noweb source documents, or individual source
code chunks.

MathAction also allows pamphlet files to edited directly
over the web either within a browser text window or via the
interface to an external editor such as emacs. Like other
content on MathAction, notices of changes will be sent to
email list subscribes and a history of recent changes to
the source is also maintained (currently set for 30 days).

I am also considering adding some typical developer tools
such as 'diff' and 'patch', to allow pamphlet source to be
compared to an offline copy and to update pamphlets by
uploading and applying a standard patch file. Since it is
also quite easy to directly extract the source text
programmatically, say by a makefile running remotely, this
means MathAction could function as a fully collaborative
literate programming development environment. One could
simply build a new completely up to date working copy of
Axiom directly from the pamphlet files stored on MathAction.

Although this is technically easy to accomplish with existing
tools, given the rather low participation rate in developing
collaborative content on MathAction so far, I am quite
uncertain how successful this experiment might be with Axiom
itself.

\start
Date: Sun, 9 Oct 2005 18:09:18 +0200
From: Martin Rubey
To: Martin Rubey
Subject: Re: series for sums 

Dear all,

  (still hoping for some response)

given a series from some domain in UPSCAT, it is possible to create a new one
by using 

map(function, series)

which applies function (lazily) to every coefficient.

However, for the problem of expanding products in Puiseux series, to obtain a
certain coefficient, I need to know *all* previous coefficients.

Is there some operation similar to map which I could use for this purpose?

Martin

Martin Rubey writes:
 > Dear all,
 > 
 > I'm just trying to do the same for products, however, I came across a little
 > mathematical difficulty. It seems to obtain the coefficient of x^k I need to 
 > 
 > * generate all compositions of k
 > 
 > * for each composition (i1,i2,..,il), generate a multiple sum of the form
 > 
 >   sum(a(i1,j1)*a(i2,j2)*...*a(il,jl),j1<j2<...<jl)
 > 
 > Of course this is doable (although I will have to use ugly newsymbols for the
 > j's), but I wonder whether somebody can think of a better alternative.
 > 
 > Martin
 > 
 > Martin Rubey writes:
 >  > Well, here is a stupid alternative, which works better on the surface:
 >  > 
 >  >       if FE has CombinatorialOpsCategory then
 >  >         is?(ker,"%defsum" :: Symbol) =>
 >  >           (summand := exprToUPS(first args,posCheck?,atanFlag)) case %problem => 
 >  >             summand
 >  > --          op := operator("%defsum"::Symbol)$CommonOperators
 >  > --          mp:FE->FE:=op cons(#1, rest args)
 >  >           eq := equation(retract(third args)@Symbol, args.4..args.5)$SegmentBinding(FE)
 >  >           mp:FE->FE:=summation(eval(#1, retract(second args)@K, third args), eq)
 >  >           [map(mp, summand.%series)$UPS]
 >  > 
 >  > now Axiom displays beautiful sums, but they won't be evaluated because of a bug
 >  > equivalent to issue #212.
 >  > 
 >  > The summation design is seriously broken, I'd say.

\start
Date: Sun, 9 Oct 2005 18:18:44 +0200
From: Martin Rubey
To: Antoine Hersen
Subject: Re: Master Thesis Subject

Dear Antoine,

I don't know whether you are still considering to work with Axiom for your
thesis, but I just realized that there is a third *big topic* which would need
somebody writing a thesis on it, namely calculations with proviso. Currently we
have

(2) -> series(1/(a-x),x=0)

        1    1      1  2    1  3    1  4      5
   (2)  - + -- x + -- x  + -- x  + -- x  + O(x )
        a    2      3       4       5
            a      a       a       a
                        Type: UnivariatePuiseuxSeries(Expression Integer,x,0)

but we really want


        1    1      1  2    1  3    1  4      5
   (2)  - + -- x + -- x  + -- x  + -- x  + O(x )
        a    2      3       4       5
            a      a       a       a

   provided a<>0

   1
   -
   x

   provided a=0
                        Type: UnivariatePuiseuxSeries(Expression Integer,x,0)

A lot of work has been done, theoretical work as well as actual code, but for
some reason unknown it never made it into the distribution.

I guess that this would be somehow inbetween my to earlier suggestions. Not
entirely applied, not entirely theoretical.

Again, I think I could help here.

Martin

Antoine Hersen writes:
 > Hello,
 > 
 > I am pursuing a master degree in CS at California State University of  
 > Sacramento and an Engineering degree in France.
 > 
 > I am looking for a Master Thesis subject in CS and I will be very  
 > interested to do something related to CAS and Axiom.
 > I have fairly decent ability in math as I am planning to get a master  
 > in math after.
 > And I am good at functional language even if I am more familiar with  
 > ML and Scheme than CL.
 > 
 > I will really appreciate any idea with some track to begin.
 > And hope to make a positive contribution to Axiom.

\start
Date: Mon, 10 Oct 2005 03:01:45 +0200
From: Michel Lavaud
To: list
Subject: Re: PDF/A and pamphlet support on MathAction

On 9 Oct 2005 at 1:20, Bill Page wrote:

> > The pdf format is proprietary _and_ fully documented - as 
> > is the Word format. And what Microsoft did, Adobe can do
> > it: that is, he can decide some day to change the pdf format
> > in a way incompatible with previous versions (as MS did for
> > Word) ...
> 
> I think this comparison to WORD is at best inaccurate. Even
> Richard Stallman - defender of free software - was willing
> to accept PDF format email attachments as early as 2002.
> 
> http://www.gnu.org/philosophy/no-word-attachments.html
> 
> In his recommended response to the receipt of an email
> with a WORD attachment he wrote:
> 
> "You sent the attachment in Microsoft Word format, a secret
> proprietary format, so I cannot read it. If you send me
> the plain text, HTML, or PDF, then I could read it."

Well, I think this criticism of Stallmann is pointless for Windows users, obsolete for 
Linux, Macintosh, Solaris and BSD users, and at best misleading for all e-mail users ;-)  

- It is pointless for Windows users, because Microsoft provides freely a viewer of Word 
documents, aka Adobe's Acrobat Reader for pdf documents.

- It is obsolete for Linux, Mac, Solaris and BSD users, because Open Office is "able to 
read and write Microsoft Office files. This allows users to open and save Word, Excel 
and PowerPoint files on their preferred platform incl. Windows, Linux and Solaris", as 
can be read on OOo site, cf.  

http://www.openoffice.org/dev_docs/features/1.1/

- It is misleading for all e-mail users, because the main problem with Word 
attachments is not that some people cannot read them (even RS can read them now, if 
he wants), but the possibility that they vehiculate viruses. And the same is true for html, 
pdf and several other types of attachments. It would have been more useful for users 
to say "avoid Word and html and pdf attachments because they can bring you viruses, 
instead of "avoid Word attachments because I cannot read it".

As for the the parallel between pdf documents and Word documents : the underlying 
format of Word documents is rtf format, which is publicly available on the web. For 
example, version 1.5 can be obtained for ex. at the url :  

http://www.biblioscape.com/rtf15_spec.htm

and version 1.6 is available (since 1999, according to MS site) for ex. at 

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnrtfspec/html/rtfspec.asp

The rtf specs were used in versions of Word up to 2000, and the latest versions use 
XML, according to MS site. Therefore, I still think that comparing pdf to Word, as for 
the potential danger in using them, is not "at best inaccurate". There is a strong 
analogy between pdf documents and Word documents : both use a proprietary and 
fully documented format, and their editors both provide a free viewer for the documents 
written in their proprietary formats. And presenting the adoption of pdf/a by the ISO as 
an argument in favor of pdf is a sophism ;-)  Rigorously speaking, its adoption ought to 
be considered as an official recognition that using pdf poses severe problems for 
archiving document (as I explained in my preceding mail).

> > The most critical community against pdf lately were not 
> > scientists but lawyers, because of Enron and other affairs,
> > that generated "tons" of electronic documents, and they
> > fear that these documents could become unreadable in 
> > the long term. The problem of defining an A-pdf format
> > (Archival-pdf) was resurrected on this occasion.
> 
> Apparently this movement was successful. :)
> So I think C Y is right. At least now there is a version
> of PDF that is no longer proprietary.

No, PDF/A is not a version of PDF, it is _based on_ a specific version of pdf. Pdf is still 
proprietary, as far as I know. Or did you see any declaration of Adobe saying they will 
adopt pdf/a as the new version of pdf ? 

> It seems that PDF has
> recently been accepted as a standard by the International
> Standards Organization.

No, once again, it is not pdf that has been accepted as a standard by the ISO.
 
> "This document will ensure that a PDF document will be
> rendered as it was created 50 years from now regardless
> of the reader used," said Betsy Fanning, director of
> standards and content for AIIM,

A contrario, this suggests that present pdf documents could be incorrectly rendered 
within 50 years, which I agree completely since it was exactly my point. The main 
problem with pdf/a is that users of pdf must be convinced of the danger of using pdf for 
archiving purposes. Otherwise, they will continue to use the version that proposes the 
largest number of possibilities, and their documents will be sooner or later rendered 
incorrectly.  

\start
Date: Sun, 9 Oct 2005 19:14:07 -0700 (PDT)
From: Cliff Yapp
To: Michel Lavaud
Subject: Re: PDF/A and pamphlet support on MathAction

--- Michel Lavaud wrote:

> There is a strong analogy between pdf documents and Word 
> documents : both use a proprietary and fully documented format, 

I'm not aware of Word's format being fully documented - AFAIK rtf is a
subset of Word's format, not the whole format itself.  I could be
wrong, but to the best of my knowledge OpenOffice.org is STILL not
fully compatible with all Word documents.

> No, PDF/A is not a version of PDF, it is _based on_ a specific
> version of pdf. Pdf is still proprietary, as far as I know. Or did 
> you see any declaration of Adobe saying they will
> adopt pdf/a as the new version of pdf ?

I'm a bit confused.  What is the issue at stake here again?  Presumably
we want all of our documents in pamphlet format, which can be rendered
however we want?  If we have to re-render it years down the road, why
would that be an issue?  We can't possibly assume rendering technology
will remain static, if you're proposing picking one rendering method
which will be around fifty years from now.  I wouldn't bet even an
penny that ANY current rendering method will survive fifty years as a
front line tool, except maybe ASCII text viewers.  Some of the names of
formats might survive but their internals and methods of working will
most likely change as improvements are made.

> A contrario, this suggests that present pdf documents could be
> incorrectly rendered within 50 years, which I agree completely 
> since it was exactly my point.

Isn't the same true with ANY format?  Who's to say dvi wouldn't change
in that amount of time?  Or LaTeX itself, for that matter?  So long as
new features are incorporated into a document format it CANNOT be a
static protocal, and I think if we want to render something both
readable and viable in the long term we are going to have problems. 
Hence the argument for source which is re-rendered as the protocals
change.

> The main problem with pdf/a is that users of pdf must be convinced 
> of the danger of using pdf for archiving purposes.

I'm clearly missing something.  Archiving electronic documents is a
problem for anything above the level of ascii text - that's actually
the exact reason Project Gutenberg uses ascii only.  Even older LaTeX
documents can be hard to re-render sometimes.

> Otherwise, they will continue to use the version that proposes the
> largest number of possibilities, and their documents will be sooner
> or later rendered incorrectly.

Isn't that up to the viewer, whether or not something is rendered
correctly?  Or are you worried that the standard will be redefined in
such a way that older documents are no longer correct, and that no
"compatibility mode" will be included?  I would very much doubt this
will happen with the pdf format - it's whole reason for EXISTING is to
be as universal as possible.  Word has different motivations for
breaking backwards compatibility, like forcing everyone to quit using
older versions of Word and buy new ones to avoid compatibility issues. 
If it is an issue for pdf some day, all the free tools and renderers
can just move to PDF/A and continue as normal, couldn't they?

\start
Date: Mon, 10 Oct 2005 04:40:42 +0200
From: Michel Lavaud
To: list
Subject: Re: [#210 Pamphlet support on MathAction] Pamphlet support on Mat

On 7 Oct 2005 at 21:49, root wrote:

> Changes
> http://page.axiom-developer.org/zope/mathaction/210PamphletSupportOnMa
> thAction/diff -- Actually, I continue to maintain the position that
> documents should be available in SOURCE form, not pdf, not dvi, etc.
> Only source allows you the ability to use the information in any way.

Yes, of course, I was comparing pdf and dvi.

However, I don't agree with you when you say source form, not dvi. In
my opinion, it is necessary that documents be available in both forms,
source _and_ dvi. Indeed, the source form is potentially ambiguous
because it can be rendered differently on different installations (cf
example below). This is a consequence of the fact that a source
document in TeX is in fact a computer program.

On the contrary, a dvi file is not a computer program, it is a
sequence of instructions that describe how glyphs are placed on pages,
It is the electronic equivalent of a set of sheets of paper. It is
completely freed from any ambiguity that could arise from the
programmatic nature of the source document, and it is rendered the
same way on all machines. Once it has been checked by the author (as
one does with galley proofs for paper articles) it is not necessary to
check it anymore. It is unfalsifiable, as a printed article in a
review.

A simple example : some years ago, a buggy version of a TeX style file
for French language, broke the rendering of fractions. As it is
possible to include any set of TeX commands in a TeX format, this
means that any French user who would have included this file into his
formats (to accelerate compilations) would have an installation that
could display incorrectly some results.Of course, this is a very
extreme and improbable example, but nothing can rule it out, nor rule
out more subtle differences between formats that could make a document
rendered differently on different installations Another problem with
source files : referencing equations is done not by numbers but by
labels, so an author who would want to cite a result of an article
could not use "Equation number 12 page 32".

For users (i.e. not the author), source file + dvi file allows double
checking. For authors, source files are the equivalent of the drafts
that one writes when doing research work, and dvi files are the
equivalent of published articles, for the outer world. Both are
necessary, in my opinion.

\start
Date: Mon, 10 Oct 2005 13:49:44 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] Hyperdoc and Axiom Help menu in the TeXmacs interface

Is there a possibility of using the hyperdoc type in the commands in
the TeXmacs interface (to get a nicely formatted output)? I tried to
replace the tm_axiom program with the one that launches axiom or sman
instead of AXIOMsys but doing that causes me to press the enter key
several times to get the commands accepted and that is really
annoying.  I am using a Fedora-3. The problem seems to be in the sman
or axiom as when I launch it separately, the same thing occurs--ie, I
have to press the enter key several times to get the command
accepted. I have used axiom built from the April 2005 sources as well
as that from the September 2005 sources and the problem continues.

Also can the axiom help/reference be lanched from within the TeXmacs
as it can be done using MuPAD from TeXmacs.

\start
Date: Mon, 10 Oct 2005 13:55:17 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] RE:Hyperdoc and Axiom Help menu in the TeXmacs interface

I also face the same problem but on Mandrake Linux. Accessing online
help would definately be wonderful idea. I know that Hyperdoc exists
for this purpose but the way HyperDoc does this needs a lot of
improvement to be useful.

\start
Date: Mon, 10 Oct 2005 13:57:15 -0500
From: MathAction (root)
To: MathAction
Subject: [AxiomDownload] [AxiomDownload] Hyperdoc and Axiom Help menu in the TeXmacs interface

AXIOMsys does direct reads from its terminal.

axiom is a script that launches sman (superman).
sman starts hyperdoc, AXIOMsys, and 
clef which is a command-line completion program.

I don't know but I suspect "clef" is getting in the way.
Try changing the call to 'axiom' to use 'axiom -noclef'
and see if the behavior changes.

Tim

\start
Date: Mon, 10 Oct 2005 14:02:33 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] HyperDoc dows not work with numpad turned on

HyperDoc does not take any input if the NmPd key is on. I use KDE/3.3
on a Fedora-3. Is this peculiar to me or is a bug/feature of the
HyperDoc :) Anyway I think its more convinient to enter numbers from
the Numeric Kepad

\start
Date: Tue, 11 Oct 2005 02:21:49 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] TeXmacs

The problem with starting axiom (or sman) instead of AXIOMsys from
TeXmacs is that it writes the prompt twice instead of once when it
starts. One can modify tm_axiom.c to wait for two prompts at start-up
time. This was done in the old TeXmacs interface with commercial
Axiom.

Is it possible to get rid of the first prompt? Having prompts not
preceeding user input is very annoying.

\start
Date: Tue, 11 Oct 2005 14:44:09 +0200
From: Martin Rubey
To: list
Subject: Important! Cannot Install on Fedora

Dear all,

I'm writing on behalf of Renaud Rioboo, who tried to install axiom on Fedora 3
and Fedora 4 without success. He wrote:

> All I got from the preinstalled versions (FC3 and FC4) is a segmentation
> fault when running AXIOMsys. With the CVS version I could not build gcl and
> the install failed under FC3 and FC4. I was not able to perform the install
> with an existing version of gcl 2.6.7-4.fc4 for FC4 which I found in the
> extras rpm repository.

It would be absolutely vital (for me!) that Renaud manages to get a running
Axiom. Is the above a known issue? 

\start
Date: Tue, 11 Oct 2005 09:44:22 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: Important! Cannot Install on Fedora

Martin,

The problem with building the lisp has to do with a default setting
in FC3 and FC4. There is a variable in the proc directory that can
be set which fixes the problem. Camm Maquire has mentioned this 
problem. I'll search the email archive to see if I can find the
command.

\start
Date: Tue, 11 Oct 2005 09:52:37 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: Important! Cannot Install on Fedora

Martin,

see 
http://lists.gnu.org/archive/html/axiom-developer/2003-11/msg00195.html
http://lists.gnu.org/archive/html/axiom-developer/2004-03/msg00034.html

so you can try
  echo 0 >/proc/sys/kernel/exec-shield

before trying the build and see if that fixes the problem.

\start
Date: Tue, 11 Oct 2005 10:15:42 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Important! Cannot Install on Fedora

On October 11, 2005 8:44 AM Martin Rubey wrote:
> 
> I'm writing on behalf of Renaud Rioboo, who tried to
> install axiom on Fedora 3 and Fedora 4 without success.
> He wrote:
> 
> > All I got from the preinstalled versions (FC3 and FC4) is
> > a segmentation fault when running AXIOMsys.

It is VERY IMPORTANT to provide complete details of the
operating system versrion. Please say exactly what very
of FC3 and what version of FC4. Which kernel? What hardware
e.g. is it 32-bit or 64-bit linux?

> With the CVS version I could not build gcl and the install
> failed under FC3 and FC4.

Again it is ABSOLUTELY ESSENTIAL that when reporting a
failure of this kind to provide complete information about
what version of operating system. And also to report in
detail the messages generated during the attempt to install.

I am able to build Axiom from tla on Fedora Core 3 x86-64.

> > I was not able to perform the install with an existing
> > version of gcl 2.6.7-4.fc4 for FC4 which I found in the
> > extras rpm repository.

The current Axiom build on all linux systems *except* Debian
is designed to use gcl re-built from the Axiom CVS. Only on
Debian, a different make script makes it possible to use a
pre-existing installation of gcl.

> 
> It would be absolutely vital (for me!) that Renaud manages
> to get a running Axiom. Is the above a known issue? 
> 
> PLEASE HELP!
> 

Axiom is know to work on both Fedora Core 3 and 4.

If you provide sufficient information I am sure that it
will be possible to discouver what is going wrong.

\start
Date: Tue, 11 Oct 2005 10:28:29 -0400
From: Bill Page
To: Martin Rubey, Tim Daly
Subject: RE: Important! Cannot Install on Fedora

On October 11, 2005 9:53 AM Tim Daly wrote:
> 
> see 
> http://lists.gnu.org/archive/html/axiom-developer/2003-11/msg00195.html
> http://lists.gnu.org/archive/html/axiom-developer/2004-03/msg00034.html
>
> so you can try
>  echo 0 >/proc/sys/kernel/exec-shield
>
> before trying the build and see if that fixes the problem.

Note that this should only be necessary on Fedora Core 4. On
my Fedora Core 3 system gcl automatically detects and sets
the appropriate compatibility option. I do not need to set
this option globally.

On Fedora Core 4,

echo 0 >/proc/sys/kernel/exec-shield

is required before building from CVS or running the pre-
installed binary.

Newer versions of gcl (not yet in the Axiom CVS) will also
detect Fedora Core 4 properly.

As an interim measure, I think the FC4 pre-installed binary
should set the global option in the 'axiom' script.

\start
Date: Tue, 11 Oct 2005 09:37:01 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] nicely formatted output

Unknown wrote:

> Is there a possibility of using the hyperdoc type in the commands
> in the TeXmacs interface (to get a nicely formatted output)?

Axiom 'hyperdoc' is **not** required to get nicely formatted output
in TeXmacs. AXIOMsys generates Tex/LaTeX output that is processed
by TeXmacs.

Could you please describe what effect you would like to achieve
in TeXmacs? In what way is the current TeXmacs output not nicely
formatted?

\start
Date: Tue, 11 Oct 2005 11:52:19 -0400
From: Bill Page
To: Tim Daly, Martin Rubey
Subject: RE: Important! Cannot Install on Fedora

On October 11, 2005 10:28 AM Bill Page wrote:
> 
> On October 11, 2005 9:53 AM Tim Daly wrote:
>
>> so you can try
>>  echo 0 >/proc/sys/kernel/exec-shield
>>
>> before trying the build and see if that fixes the problem.

> Note that this should only be necessary on Fedora Core 4.
>
> Newer versions of gcl (not yet in the Axiom CVS) will also
> detect Fedora Core 4 properly.

Here are some more recent references to the FC4 issue:

http://lists.gnu.org/archive/html/axiom-developer/2005-09/msg00296.html

On Thu, 29 Sep 2005 23:10:04 -0400 Camm Maquire wrote:

> 1) fedora has changed their address randomization again. 2.6.8pre
> and later should build on fc4 and earlier out of the box. Thanks
> to Juho Snellman <address@hidden for the critical info.

http://lists.gnu.org/archive/html/axiom-developer/2005-09/msg00097.html
http://lists.gnu.org/archive/html/axiom-developer/2005-07/msg00119.html

\start
Date: Tue, 11 Oct 2005 14:09:29 -0500
From: MathAction (Varun)
To: MathAction
Subject: [AxiomDownload] AxiomDownload Hyperdoc and Axiom Help menu in the TeXmacs interface

I've already tried using axiom -noclef but to no help.
As per Andrey:
One can modify tm_axiom.c to wait for two prompts at start-up time. This was done in the old TeXmacs interface with commercial Axiom.

Can someone tell how this can be done or change the tm_axiom and distribute the code.

Any help is welcome.

Varun.

\start
Date: Tue, 11 Oct 2005 14:30:57 -0500
From: MathAction (Varun)
To: MathAction
Subject: [AxiomDownload] RE: Hyperdoc and Axiom Help menu in the TeXmacs interface

Bill Page wrote:
>nicely formatted output --Bill Page, Tue, 11 Oct 2005 09:36:59 -0500 >reply
>Unknown wrote: 

>Is there a possibility of using the hyperdoc type in the commands in
 >the TeXmacs interface (to get a nicely formatted output)?

>Axiom hyperdoc is not required to get nicely formatted output in
>TeXmacs. AXIOMsys generates Tex/LaTeX output that is processed by
>TeXmacs.  What I intended was: Can I use the HyperDoc while still
working under TeXmacs and get nicely formatted output.  Sorry for my
not being clear.

>Could you please describe what effect you would like to achieve in
 >TeXmacs? In what way is the current TeXmacs output not nicely
 >formatted?

There are a lot of things that can be improved in TeXmacs. First of
all an online reference would certainely help a lot (those who are
Turbo C IDE fans would know this)--one just presses some hot key and
gets more information on the command he wishes to use and is not so
sure about. He can get some examples on how to use the system, just
fill in some entries and get the command output without having to
learn hundreds of functions. This would be most beneficial to users
new to axiom and to those who have just started to use Computer
Algebra Systems. Not only that, this I think would save time of those
users who are just using the 'interactive' axiom and not programming
with it.

\start
Date: Tue, 11 Oct 2005 23:10:33 +0200
From: Renaud Rioboo
To: list
Subject: Re: Important! Cannot Install on Fedora

Dear Axiom gurus,

I could not use the messages cited by Tim or Bill. I had a working axiom for
FC1 thanks to those Tim cited which seem now quite obsolete to me. As of the
message cited by Bill I don't understand what I have to do. Am I supposed to
patch the Makefile myself ?

> Again it is ABSOLUTELY ESSENTIAL that when reporting a
> failure of this kind to provide complete information about
> what version of operating system. And also to report in
> detail the messages generated during the attempt to install.

Here is what I have when I try to run the compiled binaries

[rr@roamrr ~]$ export AXIOM=/usr/local/Install/OpenAxiom/PrecompiledAxiom/axiom/mnt/linux/
[rr@roamrr ~]$ PATH=$AXIOM/bin:$PATH
[rr@roamrr ~]$ axiom

[rr@roamrr ~]$ AXIOMsys
Segmentation fault
[rr@roamrr ~]$ which axiom
/usr/local/Install/OpenAxiom/PrecompiledAxiom/axiom/mnt/linux/bin/axiom
[rr@roamrr ~]$ which AXIOMsys
/usr/local/Install/OpenAxiom/PrecompiledAxiom/axiom/mnt/linux/bin/AXIOMsys
[rr@roamrr ~]$ cat /proc/sys/kernel/exec-shield
0
[rr@roamrr ~]$ uname -a
Linux roamrr.rioboo.org 2.6.13-1.1526_FC4 #1 Wed Sep 28 19:15:10 EDT 2005 i686 i686 i386 GNU/Linux
[rr@roamrr ~]$ cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

And here is what I have when I try to build axiom

[root@roamrr axiom]# make > /tmp/axiom.build 2>&1
[root@roamrr axiom]# uname -a
Linux roamrr.rioboo.org 2.6.13-1.1526_FC4 #1 Wed Sep 28 19:15:10 EDT 2005 i686 i686 i386 GNU/Linux
[root@roamrr axiom]# cat /proc/sys/kernel/exec-shield
0
[root@roamrr axiom]# cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.
SELINUXTYPE=targeted

and the content of /tmp/axiom.build is


--=-=-=

13 making noweb
patching file modules.c
patching file Makefile
mnt.o(.text+0x392): In function `emitfile':
mnt.c: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
make[1]: [install-shell] Error 1 (ignored)
make[1]: [install-code] Error 1 (ignored)
texhash: Updating /root/.texmf-config/ls-R...
texhash: Updating /root/.texmf-var/ls-R...
texhash: Updating /usr/share/texmf/ls-R...
texhash: Updating /usr/share/texmf-config/ls-R...
texhash: Updating /usr/share/texmf-var/ls-R...
texhash: Updating /var/lib/texmf/ls-R...
texhash: Done.
make[1]: [install-elisp] Error 1 (ignored)
0 SPAD=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux SYS=linux SPD=/usr/local/Install/OpenAxiom/CvsAxiom/axiom LSP=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp GCLDIR=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7 SRC=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src INT=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/int OBJ=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj MNT=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt ZIPS=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/zips TMP=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/tmp SPADBIN=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/bin INC=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/include CCLBASE=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.7 TANGLE=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/bin/lib/notangle VERSION=Axiom 3.9 (September 2005) PATCH=patch DOCUMENT=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/bin/document
10 copying /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/scripts to /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/bin
1 making a linux system, PART=cprogs SUBPART=everything
2 Environment SPAD=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux SYS=linux SPD=/usr/local/Install/OpenAxiom/CvsAxiom/axiom LSP=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp GCLDIR=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7 SRC=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src INT=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/int OBJ=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj MNT=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt ZIPS=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/zips TMP=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/tmp SPADBIN=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/bin INC=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/include CCLBASE=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/ccl/ccllisp PART=cprogs SUBPART=everything NOISE=-o /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/tmp/trace GCLVERSION=gcl-2.6.7 TANGLE=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/bin/lib/notangle VERSION=Axiom 3.9 (September 2005) PATCH=patch DOCUMENT=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/bin/document
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./src/scripts/tex/axiom.sty)
No file Makefile.aux.
[1]
No file Makefile.toc.
[2] [3] [4] [5] [6] [7]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 281--284
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]
[23] [24] [25] [26]
Overfull \hbox (83.99927pt too wide) in paragraph at lines 1050--1050
 []\OT1/cmtt/m/n/10 CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D$
{PLF} -I/usr/X11R6/include -I/usr/local/include"[]
[27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41]
[42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] (./Makefile.aux)

LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

 )
(see the transcript file for additional information)
Output written on Makefile.dvi (52 pages, 78304 bytes).
Transcript written on Makefile.log.
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./Makefile.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german, ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch, esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar, norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish, swedish, tur
kish, ukrainian, nohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./src/scripts/tex/axiom.sty)
(./Makefile.aux) [1] (./Makefile.toc [2]) [3] [4] [5] [6] [7] [8]
Overfull \hbox (34.22025pt too wide) in paragraph at lines 281--284
[]\OT1/cmr/m/n/10 The \OT1/cmtt/m/n/10 DOCUMENT \OT1/cmr/m/n/10 vari-able is no
w set to re-place the di-rect call to the \OT1/cmtt/m/n/10 $SPADBIN/document
[9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23]
[24] [25] [26] [27]
Overfull \hbox (83.99927pt too wide) in paragraph at lines 1050--1050
 []\OT1/cmtt/m/n/10 CCF="-O2 -pipe -fno-strength-reduce -Wall -D_GNU_SOURCE -D$
{PLF} -I/usr/X11R6/include -I/usr/local/include"[]
[28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42]
[43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] (./Makefile.aux) )
(see the transcript file for additional information)
Output written on Makefile.dvi (53 pages, 101616 bytes).
Transcript written on Makefile.log.
make[1]: Entering directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom'
11 checking directory structure
12 Environment: PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=gawk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/share XLIB=/usr/X11R6/lib GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=128*1024 SRCDIRS=bootdir interpdir sharedir algebradir etcdir clefdir docdir graphdir smandir hyperdir inputdir  PATCH=patch
16 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/Makefile from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/Makefile.pamphlet
18 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src
make[2]: Entering directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src'
2 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/scripts/Makefile from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/scripts/Makefile.pamphlet
1 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/scripts
make[3]: Entering directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/scripts'
1 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/scripts
make[3]: Leaving directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/scripts'
18 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/Makefile from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/Makefile.pamphlet
17 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib
make[3]: Entering directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib'
1 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/bsdsignal.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/bsdsignal.c.pamphlet
2 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/bsdsignal.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/bsdsignal.c
9 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/cursor.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/cursor.c.pamphlet
10 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/cursor.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/cursor.c
13 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/edin.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/edin.c.pamphlet
14 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/edin.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/edin.c
17 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/fnct_key.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/fnct_key.c.pamphlet
18 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/fnct_key.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/fnct_key.c
21 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/halloc.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/halloc.c.pamphlet
22 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/halloc.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/halloc.c
29 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/openpty.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/openpty.c.pamphlet
30 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/openpty.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/openpty.c
33 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/pixmap.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/pixmap.c.pamphlet
34 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/pixmap.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/pixmap.c
37 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/prt.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/prt.c.pamphlet
38 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/prt.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/prt.c
41 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/sockio-c.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/sockio-c.c.pamphlet
42 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/sockio-c.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/sockio-c.c
45 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/spadcolors.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/spadcolors.c.pamphlet
46 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/spadcolors.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/spadcolors.c
/usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/spadcolors.c: In function =E2=80=98HSVtoRGB=E2=80=99:
/usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/spadcolors.c:73: warning: =E2=80=98rgb.b=E2=80=99 may be used uninitialized in this function
/usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/spadcolors.c:73: warning: =E2=80=98rgb.g=E2=80=99 may be used uninitialized in this function
/usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/spadcolors.c:73: warning: =E2=80=98rgb.r=E2=80=99 may be used uninitialized in this function
/usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/spadcolors.c: In function =E2=80=98AllocCells=E2=80=99:
/usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/spadcolors.c:573: warning: =E2=80=98xcolor.pixel=E2=80=99 is used uninitialized in this function
49 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/util.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/util.c.pamphlet
50 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/util.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/util.c
53 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/wct.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/wct.c.pamphlet
54 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/wct.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/wct.c
57 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/XDither.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/XDither.c.pamphlet
58 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/XDither.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/XDither.c
61 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/XShade.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/XShade.c.pamphlet
62 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/XShade.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/XShade.c
65 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/XSpadFill.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/XSpadFill.c.pamphlet
66 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/XSpadFill.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/XSpadFill.c
73 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/libspad.a
ar: creating /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/libspad.a
5 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/cfuns-c.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/cfuns-c.c.pamphlet
6 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/cfuns-c.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/cfuns-c.c
25 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/hash.c from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/hash.c.pamphlet
26 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lib/hash.o from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/lib/hash.c
11 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/axiom.sty from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/doc/axiom.sty.pamphlet
3 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/bsdsignal.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/bsdsignal.c.pamphlet
4 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/bsdsignal.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/bsdsignal.c.dvi
7 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/cfuns-c.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/cfuns-c.c.pamphlet
8 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/cfuns-c.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/cfuns-c.c.dvi
11 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/cursor.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/cursor.c.pamphlet
12 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/cursor.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/cursor.c.dvi
15 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/edin.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/edin.c.pamphlet
16 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/edin.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/edin.c.dvi
19 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/fnct_key.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/fnct_key.c.pamphlet
20 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/fnct_key.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/fnct_key.c.dvi
23 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/halloc.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/halloc.c.pamphlet
24 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/halloc.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/halloc.c.dvi
27 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/hash.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/hash.c.pamphlet
28 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/hash.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/hash.c.dvi
31 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/openpty.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/openpty.c.pamphlet
32 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/openpty.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/openpty.c.dvi
35 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/pixmap.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/pixmap.c.pamphlet
36 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/pixmap.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/pixmap.c.dvi
39 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/prt.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/prt.c.pamphlet
40 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/prt.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/prt.c.dvi
43 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/sockio-c.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/sockio-c.c.pamphlet
44 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/sockio-c.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/sockio-c.c.dvi
71 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/Makefile.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/Makefile.dvi
47 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/spadcolors.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/spadcolors.c.pamphlet
48 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/spadcolors.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/spadcolors.c.dvi
51 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/util.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/util.c.pamphlet
52 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/util.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/util.c.dvi
55 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/wct.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/wct.c.pamphlet
56 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/wct.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/wct.c.dvi
59 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/XDither.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/XDither.c.pamphlet
60 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/XDither.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/XDither.c.dvi
63 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/XShade.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/XShade.c.pamphlet
64 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/XShade.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/XShade.c.dvi
67 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/XSpadFill.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib/XSpadFill.c.pamphlet
68 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/doc/src/lib/XSpadFill.c.dvi from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/int/doc/src/lib/XSpadFill.c.dvi
72 finished making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib
make[3]: Leaving directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/lib'
make[2]: Leaving directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src'
0 PLF=LINUXplatform CCF=-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -DLINUXplatform -I/usr/X11/include LDF=-L/usr/X11R6/lib CC=gcc AWK=gawk RANLIB=ranlib TOUCH=touch TAR=tar AXIOMXLROOT=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp DAASE=/usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/share XLIB=/usr/X11R6/lib GCLOPTS=--enable-vssize=65536*2 --enable-statsysbfd --enable-maxpage=128*1024 SRCDIRS=bootdir interpdir sharedir algebradir etcdir clefdir docdir graphdir smandir hyperdir inputdir  PATCH=patch
10 copying /usr/local/Install/OpenAxiom/CvsAxiom/axiom/src/scripts to /usr/local/Install/OpenAxiom/CvsAxiom/axiom/mnt/linux/bin
20 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/Makefile from /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/Makefile.pamphlet
19 making /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp
make[2]: Entering directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp'
2 building gcl-2.6.7
3 applying EXTRAS patch to h/linux.defs
patching file linux.defs
4 setup ini files for EXTRAS patch
6 applying libspad.a patch to unixport/makefile
patching file makefile
7 applying toploop patch to unixport/init_gcl.lsp
patching file init_gcl.lsp.in
11 applying tail-recursive noise patch
patching file gcl_cmpflet.lsp
12 applying tail-recursive noise patch
patching file gcl_cmpcall.lsp
26 copy gcl_collectfn.lsp to /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lsp/collectfn.lsp
27 copy sys-proclaim.lisp to /usr/local/Install/OpenAxiom/CvsAxiom/axiom/obj/linux/lsp/sys-proclaim.lisp
creating cache ./config.cache
checking host system type... i686-pc-linux-gnu
host=i686-pc-linux-gnu
enable_machineuse=386-linux
checking for gcc... gcc
checking whether the C compiler (gcc    ) works... yes
checking whether the C compiler (gcc    ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for gawk... gawk
checking system version (for dynamic loading)... checking for makeinfo... makeinfo
Linux-2.6.13-1.1526_FC4
checking for unistd.h... yes
checking for sysconf in -lc... yes
checking for _SC_CLK_TCK... 100
checking for gmp.h... yes
checking for __gmpz_init in -lgmp... yes
checking for external gmp version... checking for leading underscore in object symbols... no
checking for GNU ld option -Map... yes
checking for size of gmp limbs... 4
checking _SHORT_LIMB... no
checking _LONG_LONG_LIMB... no
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
-I/usr/X11R6/include
-L/usr/X11R6/lib

-lSM -lICE
checking for main in -lXmu... yes
checking for main in -lXt... yes
checking for main in -lXext... yes
checking for main in -lXaw... yes
checking for main in -lX11... yes
checking for bfd.h... yes
checking for bfd_init in -lbfd... yes
checking if need to define CONST for bfd... no
checking for useable bfd_boolean... yes
checking size of long... 4
checking sizeof struct contblock... 8
checking for endian.h... yes
checking endianness... little
checking for sbrk... yes
checking for randomized sbrk... yes
checking for randomized brk remedy... no
Cannot build with randomized sbrk
make[3]: Entering directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7'
rm -f bin/gcl xbin/gcl
MGCLDIR=`echo /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7 | sed -e 'sX^\([a-z]\):X/\1Xg'` ; \
GCLDIR=`echo /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7` ; \
make install-command "INSTALL_LIB_DIR=$GCLDIR" "prefix=$GCLDIR" "BINDIR=$MGCLDIR/unixport"
make[4]: Entering directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7'
rm -f /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/bin/gcl
(echo '#!/bin/sh' ; \
echo exec /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/unixport/ \\ ; \
echo '   -dir' /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/unixport/ \\ ; \
echo '   -libdir' /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/ \\ ; \
echo '   -eval '\''(setq si::*allow-gzipped-file* t)'\' \\ ;\
! [ -d "" ] || echo '   -eval '\''(setq si::*tk-library* '\"\"')'\' \\;\
echo '     '\"\$@\" ) > /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/bin/gcl;
echo '#' other options: -load "/tmp/foo.o" -load "jo.lsp" -eval '"(joe 3)"' >> /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/bin/gcl
chmod a+x /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/bin/gcl
rm -f /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/bin/gclm.bat
if gcc --version | grep mingw >/dev/null 2>&1 ; then (echo '@SET cd='; \
 echo '@SET promp%prompt%'; \
 echo '@PROMPT SET cd'; \
 echo '@CALL>%temp%.\setdir.bat'; \
 echo '@'; \
 echo '% do not delete this line %'; \
 echo '@ECHO off'; \
 echo 'PROMPT %promp'; \
 echo 'FOR %%c IN (CALL DEL) DO %%c %temp%.\setdir.bat'; \
 echo 'set cwd=%cd%'; \
 echo 'set libdir=%cd%\..\lib\gcl-`cat majvers`.`cat minvers`'; \
 echo 'set unixportdir=%libdir%\unixport'; \
 echo 'path %cd%\..\mingw\bin;%PATH%'; \
 echo "start %unixportdir%\.exe -dir %unixportdir% -libdir %libdir% -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9" ) > /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/bin/gclm.bat ; fi
rm -f /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/bin/gclfinal.bat
if gcc --version | grep -i mingw >/dev/null 2>&1 ; then (echo 'ECHO path %1\mingw\bin;%PATH% > gcli.bat'; \
 echo "ECHO start %1\lib\gcl-`cat majvers`.`cat minvers`\unixport\.exe -dir %1\lib\gcl-`cat majvers`.`cat minvers`\unixport -libdir %1\lib\gcl-`cat majvers`.`cat minvers` -eval \"(setq si::*allow-gzipped-file* t)\" %1 %2 %3 %4 %5 %6 %7 %8 %9 >> gcli.bat" ) > /usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/bin/gclfinal.bat ; fi
make[4]: Leaving directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7'
(cd xbin ; cp ../bin/gcl .)
cd cmpnew && make gcl_collectfn.o
make[4]: Entering directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/cmpnew'
../unixport/saved_pre_gcl ../unixport/ -compile gcl_collectfn.lsp
make[4]: ../unixport/saved_pre_gcl: Command not found
make[4]: *** [gcl_collectfn.o] Error 127
make[4]: Leaving directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7/cmpnew'
make[3]: *** [cmpnew/gcl_collectfn.o] Error 2
make[3]: Leaving directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp/gcl-2.6.7'
/bin/sh: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom/lsp'
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory `/usr/local/Install/OpenAxiom/CvsAxiom/axiom'
make: *** [all] Error 2

--=-=-

Thank you for any help.

		Renaud

\start
Date: Tue, 11 Oct 2005 23:08:33 -0400
From: Bill Page
To: Renaud Rioboo
Subject: RE: Important! Cannot Install on Fedora

Renaud,

I am sorry that you are having some problems getting Axiom to
work on Fedora Core 4. Thank you for your patience and for
sending the detailed information about your configuration and
the make log file!

The information you sent seems to confirm that in both the
pre-compiled binary version and in your attempt to build Axiom
from source you are experiencing a well known problem in FC4
regarding sbrk address randomization.

The short answer seems to be

  echo 0 > /proc/sys/kernel/randomize_va_space

The longer answer follows.

On October 11, 2005 5:11 PM wrote you wrote:
> 
> I could not use the messages cited by Tim or Bill. I had a 
> working axiom for FC1 thanks to those Tim cited which seem
> now quite obsolete to me. As of the message cited by Bill
> I don't understand what I have to do. Am I supposed to
> patch the Makefile myself ?
> 

No, I don't think it will be necessary for you to patch the
Makefile yourself... but if you have the skills and time to
do this then certainly your help would be greatly appreciated.
:)

I do not have FC4 installed (I am currently using FC3 on
x86-64) so I can not directly reproduce the problem that you
reported. But I have spent some time looking into the issue
and I hope I can help in a more specific way than my previous
email.

You are apparently right that the instructions referred to by
Tim are in fact out of date for FC4 as this message from Juho
Snellman to the gcl developer list shows:

http://lists.gnu.org/archive/html/gcl-devel/2005-08/msg00074.html

>From this information I can guess that the following commands
might allow you to run the pre-compiled version of Axiom on
your system:

  export
AXIOM=/usr/local/Install/OpenAxiom/PrecompiledAxiom/axiom/mnt/linux/
  PATH=$AXIOM/bin:$PATH
  setarch i386 -R AXIOMsys

---------

Another message on gcl-devel reveals how Tim was able to compile
Axiom on FC4:

http://lists.gnu.org/archive/html/gcl-devel/2005-09/msg00024.html

Apparently the command you need to do this is:

  echo 0 > /proc/sys/kernel/randomize_va_space

**not**

  echo 0 >/proc/sys/kernel/exec-shield

which apparently no longer applies to FC4. The command

  echo 0 > /proc/sys/kernel/randomize_va_space

should also allow you to run the pre-compiled version
of Axiom for FC4.

The best solution obviously would be to upgrade the Axiom sources
to the newest version of gcl that supports Axiom.

http://lists.gnu.org/archive/html/axiom-developer/2005-09/msg00296.html

To do this we would need to obtain gcl from CVS as described
in Camm's email:

  export CVS_RSH=ssh
  export CVSROOT=:ext:subversions.gnu.org:/cvsroot/gcl
  cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

-------

then construct a tarball with the contents of 2.6.8pre, but
calling it gcl-2.6.7.tgz. Use it to replace zips/gcl-2.6.7.tgz
with the updated version of gcl. Then rebuild Axiom by

  ./configure
  make clean
  make

------

If this works, then the Axiom makefile can be updated to include
the new 2.6.8pre tarball and the appropriate new sections in
Makefile.pamphlet. I expect that Tim has this scheduled for some
time real soon now ... ;)

Please let me know if this helps.

\start
Date: Tue, 11 Oct 2005 22:18:04 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [TeXmacs] discussion of TeXmacs interface moved

>From unknown Mon Sep 12 12:42:27 -0500 2005
From: unknown
Date: Mon, 12 Sep 2005 12:42:27 -0500
Subject: Graphics does not work under the TeXmacs 1.0.5 interface

Under linux with TeXmacs, the graphics doesn't appear at all. Just the
message indicating the type is shown.  I even followed the
instructions on the FAQ and changed the AXIOMsys to axiom and even
sman. But if I do that though HyperDoc appears, I have to press return
several times(may be upto 7 times) before the answer appears on the
texmacs interface. Just blank lines with the red axiom prompt keep on
appearing.

>From unknown Mon Oct 10 13:49:38 -0500 2005
From: unknown
Date: Mon, 10 Oct 2005 13:49:38 -0500
Subject: Hyperdoc and Axiom Help menu in the TeXmacs interface

Is there a possibility of using the hyperdoc type in the commands in
the TeXmacs interface (to get a nicely formatted output)? I tried to
replace the tm_axiom program with the one that launches axiom or sman
instead of AXIOMsys but doing that causes me to press the enter key
several times to get the commands accepted and that is really
annoying.

I am using a Fedora-3. The problem seems to be in the sman or axiom as
when I launch it separately, the same thing occurs--ie, I have to
press the enter key several times to get the command accepted. I have
used axiom built from the April 2005 sources as well as that from the
September 2005 sources and the problem continues.

Also can the axiom help/reference be lanched from within the TeXmacs
as it can be done using MuPAD from TeXmacs.

>From unknown Mon Oct 10 13:55:10 -0500 2005
From: unknown
Date: Mon, 10 Oct 2005 13:55:10 -0500
Subject: RE:Hyperdoc and Axiom Help menu in the TeXmacs interface

I also face the same problem but on Mandrake Linux. Accessing online
help would definately be wonderful idea. I know that Hyperdoc exists
for this purpose but the way HyperDoc does this needs a lot of
improvement to be useful.

>From root Mon Oct 10 13:57:15 -0500 2005
From: root
Date: Mon, 10 Oct 2005 13:57:15 -0500
Subject: [AxiomDownload] Hyperdoc and Axiom Help menu in the TeXmacs interface
	(MathAction)

AXIOMsys does direct reads from its terminal.

axiom is a script that launches sman (superman).
sman starts hyperdoc, AXIOMsys, and 
clef which is a command-line completion program.

I don't know but I suspect "clef" is getting in the way.
Try changing the call to 'axiom' to use 'axiom -noclef'
and see if the behavior changes.

Tim


>From unknown Mon Oct 10 14:02:32 -0500 2005
From: unknown
Date: Mon, 10 Oct 2005 14:02:32 -0500
Subject: HyperDoc dows not work with numpad turned on

HyperDoc does not take any input  if the NmPd key is on. I use KDE/3.3 on a Fedora-3. Is this peculiar to me or is a bug/feature of the HyperDoc :)
Anyway I think its more convinient to enter numbers from the Numeric Kepad

>From unknown Tue Oct 11 02:21:42 -0500 2005
From: unknown
Date: Tue, 11 Oct 2005 02:21:42 -0500
Subject: TeXmacs

The problem with starting axiom (or sman) instead of AXIOMsys from TeXmacs is that it writes the prompt twice instead of once when it starts. One can modify tm_axiom.c to wait for two prompts at start-up time. This was done in the old TeXmacs interface with commercial Axiom.

Is it possible to get rid of the first prompt? Having prompts not preceeding user input is very annoying.

Andrey


>From BillPage Tue Oct 11 09:36:59 -0500 2005
From: Bill Page
Date: Tue, 11 Oct 2005 09:36:59 -0500
Subject: nicely formatted output

Unknown wrote:

> Is there a possibility of using the hyperdoc type in the commands
> in the TeXmacs interface (to get a nicely formatted output)?

Axiom 'hyperdoc' is **not** required to get nicely formatted output
in TeXmacs. AXIOMsys generates Tex/LaTeX output that is processed
by TeXmacs.

Could you please describe what effect you would like to achieve
in TeXmacs? In what way is the current TeXmacs output not nicely
formatted?

>From Varun Tue Oct 11 14:09:26 -0500 2005
From: Varun
Date: Tue, 11 Oct 2005 14:09:26 -0500
Subject: AxiomDownload Hyperdoc and Axiom Help menu in the TeXmacs interface

I've already tried using axiom -noclef but to no help.
As per Andrey:
One can modify tm_axiom.c to wait for two prompts at start-up time. This was done in the old TeXmacs interface with commercial Axiom.

Can someone tell how this can be done or change the tm_axiom and distribute the code.

Any help is welcome.

Varun.

>From Varun Tue Oct 11 14:30:56 -0500 2005
From: Varun
Date: Tue, 11 Oct 2005 14:30:56 -0500
Subject: RE: Hyperdoc and Axiom Help menu in the TeXmacs interface

Bill Page wrote:
>nicely formatted output --Bill Page, Tue, 11 Oct 2005 09:36:59 -0500 >reply
>Unknown wrote: 

>Is there a possibility of using the hyperdoc type in the commands in
 >the TeXmacs interface (to get a nicely formatted output)?

>Axiom hyperdoc is not required to get nicely formatted output in
>TeXmacs. AXIOMsys generates Tex/LaTeX output that is processed by
>TeXmacs.  What I intended was: Can I use the HyperDoc while still
working under TeXmacs and get nicely formatted output.  Sorry for my
not being clear.

>Could you please describe what effect you would like to achieve in
 >TeXmacs? In what way is the current TeXmacs output not nicely
 >formatted?

There are a lot of things that can be improved in TeXmacs. First of
all an online reference would certainely help a lot (those who are
Turbo C IDE fans would know this)--one just presses some hot key and
gets more information on the command he wishes to use and is not so
sure about. He can get some examples on how to use the system, just
fill in some entries and get the command output without having to
learn hundreds of functions. This would be most beneficial to users
new to axiom and to those who have just started to use Computer
Algebra Systems. Not only that, this I think would save time of those
users who are just using the 'interactive' axiom and not programming
with it.

\start
Date: Tue, 11 Oct 2005 22:26:47 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [TeXmacs] TeXmacs interface improvements

Yes, I agree that TeXmacs has great potential as an graphical user
interface for Axiom (and many other computer algebra packages as
well). In principle it should be possible to implement almost all
of the hyperdoc functionality directly in TeXmacs as well as support
for incorporating Axiom graphics into TeXmacs documents and even
compiling SPAD and Aldor library programs.

Unfortunately, not a lot of resources are available to do this.
At this time, the only person that I know who is working on this
is Andrey G. Grozin. See

http://lists.gnu.org/archive/html/axiom-developer/2005-08/msg00229.html

\start
Date: Wed, 12 Oct 2005 03:55:57 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#216 terminating condition for 'nextSubsetGray' incorrectly documented] 

<a href="combfunc.spad.pamphlet.patch">perman.spad.pamphlet.patch</a>

\start
Date: Wed, 12 Oct 2005 03:50:00 -0500
From: MathAction (unknown)
To: list
Subject: [TeXmacs] TeXmacs

Changes http://www.axiom-developer.org/zope/mathaction/TeXmacs/diff
--
It is easy to modify tm_axiom.c to start axiom (with hypertex and graphics)

Instead of starting AXIOMsys, it should start axiom -noclef

Also, in void session(void), declare
int prompts=0;
and, a few lines later, replace the line
else if (code==PROMPT) break;
by the line
else if (code==PROMPT) { if ((++prompts)==2) break; }

However, it would be much better to fix this damn double-prompt problem once and for all. Axiom *must not* write a prompt when it is not prompting the user to input something.

\start
Date: Wed, 12 Oct 2005 03:54:00 -0500
From: MathAction (kratt6)
To: list
Subject: [#216 terminating condition for 'nextSubsetGray' incorrectly documented] (nouveau) 

Changes http://page.axiom-developer.org/zope/mathaction/216TerminatingConditionForNextSubsetGrayIncorrectlyDocumented/diff
--
The documentation of 'GRAY' incorrectly states that
'vv.2.1 = n' means that 'vv.1' is the last subset.

It should read 'n+1'. Here is a patch:

\start
Date: Wed, 12 Oct 2005 10:59:16 -0400
From: Bill Page
To: Yoriaki Fujimori
Subject: RE: [Gcl-devel] axiom-Sept2005 on opensuse10.0/amd64

On October 12, 2005 9:10 AM yoriaki fujimori wrote to
gcl-devel@gnu.org:

> 
> I changed one line in Makefile.pamphlet, in the
> Makefile.linux section:
> LDF=-L/usr/X11R6/lib64 ...
> 
> and the compilation went on fine.
> This may not be a good solution.

Yes, that is the correct solution for 64-bit linux. I did
the same on my Fedora Core 3 x86-64 system.

> I hope that in future someone wrote separate
> Makefile.linux64.
> 

We would be very happy if you could submit a patch to
Makefile.pamphlet containing a new section for linux64. :)
Also, ./configure should be changed to automatically
detect this architecture.

\start
Date: Wed, 12 Oct 2005 18:01:08 +0200
From: Renaud Rioboo
To: list
Subject: Summary of Install of axiom on FC3 and FC4

Dear Axiom Gurus,

Thank you all for your help concerning the install of axiom under recent
Fedora versions.

It seems that Fedora enabled a kernel feature which randomizes memory for
security reasons and this is causing problems to run/build axiom. I used two
machines to test.

rr@roamrr->uname -a
Linux roamrr.rioboo.org 2.6.13-1.1526_FC4 #1 Wed Sep 28 19:15:10 EDT 2005 i686 i686 i386 GNU/Linux
rr@gate->uname -a
Linux gate.rioboo.org 2.6.12-1.1378_FC3 #1 Wed Sep 14 04:24:31 EDT 2005 i686 athlon i386 GNU/Linux


I Checked out the content of

rr@roamrr->cat /proc/sys/kernel/randomize_va_space
1

If I turn off this by issuing

echo 0 > /proc/sys/kernel/randomize_va_space

I can run the preinstalled version for FC3 and FC4 and compile the Cvs version
correctly. This has however the inconvenient that the feature is globally
turned off for the whole system.

In FC4 there is a setarch command which disables randomization on a per
process basis. I was not able to find a way to find an equivalent under
FC3. Thus in FC4

rr@roamrr->setenv AXIOM /usr/local/Install/OpenAxiom/PrecompiledAxiom/axiom/mnt/linux
rr@roamrr->set path = ( $AXIOM/bin $path)
rr@roamrr->setarch `arch` -R axiom

works correctly with the advantage that you can run this without requiring a
global modification.

You can also compile the Cvs version of axiom by issuing

setarch =E0rch`-R make

to build the system.

I hope this will be of some help for other axiom users.

\start
Date: Wed, 12 Oct 2005 11:39:29 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] 

Changes http://wiki.axiom-developer.org/AxiomDownload/diff
--

++added:
         0) echo 0 > /proc/sys/kernel/randomize_va_space

++added:
Note: See comments from RenaudRioboo below concerning item 0).


++added:
>From RenaudRioboo Wed Oct 12 12:01:00 -0500 2005
From: Renaud Rioboo
Date: Wed, 12 Oct 2005 12:01:00 -0500
Subject: Summary of Install of axiom on FC3 and FC4

Dear Axiom Gurus,

Thank you all for your help concerning the install of axiom under recent
Fedora versions.

It seems that Fedora enabled a kernel feature which randomizes memory
for security reasons and this is causing problems to run/build axiom.
I used two machines to test::

  rr@roamrr->uname -a
  Linux roamrr.rioboo.org 2.6.13-1.1526_FC4 #1 Wed Sep 28 19:15:10 EDT 2005 i686 i686 i386 GNU/Linux
  rr@gate->uname -a
  Linux gate.rioboo.org 2.6.12-1.1378_FC3 #1 Wed Sep 14 04:24:31 EDT 2005 i686 athlon i386 GNU/Linux

I Checked out the content of::

  rr@roamrr->cat /proc/sys/kernel/randomize_va_space
  1

If I turn off this by issuing::

  echo 0 > /proc/sys/kernel/randomize_va_space

I can run the preinstalled version for FC3 and FC4 and compile the
Cvs version correctly. This has however the inconvenient that the
feature is globally turned off for the whole system. 

In FC4 there is a setarch command which disables randomization on a per
process basis. I was not able to find a way to find an equivalent under
FC3. Thus in FC4::

  rr@roamrr->setenv AXIOM /usr/local/Install/OpenAxiom/PrecompiledAxiom/axiom/mnt/linux
  rr@roamrr->set path = ( $AXIOM/bin $path)
  rr@roamrr->setarch `arch` -R axiom

works correctly with the advantage that you can run this without
requiring a global modification.

You can also compile the Cvs version of axiom by issuing::

  setarch ch`-R make

to build the system.

I hope this will be of some help for other axiom users.

\start
Date: Wed, 12 Oct 2005 11:53:17 -0500
From: MathAction (greg)
To: MathAction
Subject: [AxiomDownload] 

Changes http://wiki.axiom-developer.org/AxiomDownload/diff
--

??changed:
-  rr@roamrr->set path = ( $AXIOM/bin $path)
  rr@roamrr->set path = ( \$AXIOM/bin \$path)

\start
Date: Wed, 12 Oct 2005 16:05:00 -0500
From: MathAction (unknown)
To: MathAction
Subject: [update Axiom] Automated update will be welcome

If axiom could be updated automatically through a program or a script
which does not require any human intervention, it would be a great
relief.  Such an updater would only download the required portions
from the server (both source or binary as required) and update the
files locally and save users from manually downloading, compiling it
from scratch.

\start
Date: Wed, 12 Oct 2005 23:29:02 +0200
From: Renaud Rioboo
To: list
Subject: Cylindrical Algebraic Decompostion for Axiom

Dear Axiom fans,

In the last few years there have been a regain of interest in some Computer
Algebra users circles about Cylindrical Algebraic Decomposition (aka CAD). As
some of you may know my thesis was about CAD and I am regularly receiving
queries about CAD and the Axiom implementation I wrote.

I already privately gave sources or ran particular problems for some people
but I have never officially released my sources because I do not think they
are at production level and many work has still to be done on them.

Recently Martin Rubey thought it could be a good idea to release them and I
have of course no objection on that point nor on sharing these sources with
the community. If there is some interest on it you may include it into the
Axiom distribution with the same permissions than the rest of the software.

While I wait for my lab to give me the necessary permissions to be able to use
Axiom and export this software you may find it's sources at the unlisted url

http://rioboo.free.fr/CadPub/

I would like to add just a few words about that work which is a
straightforward implementation of the standard papers by Arnon, Collins and
McCallum which are more than 20 years old now.

My work on Cad is 15 years old and was developped for the defense of my thesis
where CAD was an sample application for real algebraic numbers
manipulations. By the time I wrote it I also needed some subresultant
calculations which were not in Axiom (Scratchpad by that time) and the
required machinery to work with real algebraic numbers.

Along the times, real algebraic numbers were included into Axiom and
subresultant calculations which are used in several places of the Axiom
Library were modified to all use Lionel Ducos's package which enables a
performance gain. While making these modifications to Axiom I tried to keep my
CAD package up-to-date with the Axiom Library and have used it as a test for
other packages. It thus should compile under recent Axiom versions and should
compute something that resembles a CAD.

Don't expect this package to be the absolute CAD program, I never found time
to further work on it in order to include many enhancements which are present
in other CAD packages. While Axiom versions evolved I had to remove what I
thought were enhancements and remove some support for generalization. As of
today it only includes one projection method which is the McCallum projection
and no reconstruction nor adjacency's are taken into account.

However it did reasonabily compare with more recent techniques such as
Rational Univariate Representation (aka RUR) for simple cases though it could
not produce results for some more complicated cases. By the time this
comparison was made Axiom had some severe memory restrictions which seem to
have disappear now. I thus think that many objections to using CAD could now
be revised.

For hard problems this package should thus not be worse than any other CAD
package except that you cannot fall into an optimzation drawback :-) There is
no optimization !

I will of course try to maintain the package to the best of my ability. One
thing I should do is include comments describing the different functions, but
even that requires going into the code and the algorithms which are quite old
for me now.

Let me know if there is some interest on it.

\start
Date: Wed, 12 Oct 2005 16:42:54 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomContributions] 


++added:
[CommonDenominator for polynomials]

[Cylindrical Algebraic Decomposition]

"Dynamic Real Algebraic Closure":http://www.math.uvsq.fr/~lecerf/software/drc/index.html

[Guessing formulas for sequences]

[Lisp's Fraction Integer Domain]

[recurrence relation operator]

[statistical functions]

[polymake]

[Rational Interpolation]

[reading structures from a file]


??changed:
-"Dynamic Real Algebraic Closure":http://www.math.uvsq.fr/~lecerf/software/drc/index.html
-
-[Rational Interpolation]
-
-[CommonDenominator for polynomials]
-
-[Guessing formulas for sequences]
[string conversions]

--removed:
-[Lisp's Fraction Integer Domain]
-
-[recurrence relation operator]
-
-[statistical functions]
-
-[polymake]
-
-[string conversions]
-
-[reading structures from a file]

\start
Date: Wed, 12 Oct 2005 16:49:34 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Cylindrical Algebraic Decomposition] (new) 

**On Wednesday, October 12, 2005 5:29 PM Renaud Rioboo wrote:**

Dear Axiom fans,

In the last few years there have been a regain of interest in some Computer
Algebra users circles about Cylindrical Algebraic Decomposition (aka CAD). As
some of you may know my thesis was about CAD and I am regularly receiving
queries about CAD and the Axiom implementation I wrote.

I already privately gave sources or ran particular problems for some people
but I have never officially released my sources because I do not think they
are at production level and many work has still to be done on them.

Recently Martin Rubey thought it could be a good idea to release them and I
have of course no objection on that point nor on sharing these sources with
the community. If there is some interest on it you may include it into the
Axiom distribution with the same permissions than the rest of the software.

While I wait for my lab to give me the necessary permissions to be able to use
Axiom and export this software you may find it's sources at the unlisted url

http://rioboo.free.fr/CadPub/

I would like to add just a few words about that work which is a
straightforward implementation of the standard papers by Arnon, Collins and
McCallum which are more than 20 years old now.

My work on Cad is 15 years old and was developped for the defense of my thesis
where CAD was an sample application for real algebraic numbers
manipulations. By the time I wrote it I also needed some subresultant
calculations which were not in Axiom (Scratchpad by that time) and the
required machinery to work with real algebraic numbers.

Along the times, real algebraic numbers were included into Axiom and
subresultant calculations which are used in several places of the Axiom
Library were modified to all use Lionel Ducos's package which enables a
performance gain. While making these modifications to Axiom I tried to keep my
CAD package up-to-date with the Axiom Library and have used it as a test for
other packages. It thus should compile under recent Axiom versions and should
compute something that resembles a CAD.

Don't expect this package to be the absolute CAD program, I never found time
to further work on it in order to include many enhancements which are present
in other CAD packages. While Axiom versions evolved I had to remove what I
thought were enhancements and remove some support for generalization. As of
today it only includes one projection method which is the McCallum projection
and no reconstruction nor adjacency's are taken into account.

However it did reasonabily compare with more recent techniques such as
Rational Univariate Representation (aka RUR) for simple cases though it could
not produce results for some more complicated cases. By the time this
comparison was made Axiom had some severe memory restrictions which seem to
have disappear now. I thus think that many objections to using CAD could now
be revised.

For hard problems this package should thus not be worse than any other CAD
package except that you cannot fall into an optimzation drawback :-) There is
no optimization !

I will of course try to maintain the package to the best of my ability. One
thing I should do is include comments describing the different functions, but
even that requires going into the code and the algorithms which are quite old
for me now.

\begin{spad}
)ab pack CADU CylindricalAlgebraicDecompositionUtilities

CylindricalAlgebraicDecompositionUtilities(R,P) : PUB == PRIV where

-- Tese are some standard tools which are needed to compute with univariate
-- polynomials. 
--
-- A gcd basis for a set of polynomials is a set of pairwise relatively prime 
-- polynomials which all divide the original set and whose product is the
-- same than the product of the original set.
--
-- A square free basis for a list of polynomials is just a list
-- of square free polynomials which are pairwise relatively primes and have
-- the same roots than the original polynomials.

  R : GcdDomain
  P : UnivariatePolynomialCategory(R)

  PUB == with
      squareFreeBasis : List(P) -> List(P)
        ++ 
      gcdBasis : List(P) -> List(P)
        ++ decompose a list of polynomials into pairwise relatively 
        ++ prime polynomials
      gcdBasisAdd : (P,List(P)) -> List(P)
        ++ add one polynomial to list of pairwise relatively prime polynomials

  PRIV == add

     squareFreeBasis(lpols) ==
       lpols = [] => []
       pol := first(lpols)
       sqpol := unitCanonical(squareFreePart(pol))
       gcdBasis(cons(sqpol,squareFreeBasis(rest(lpols))))
         
     gcdBasisAdd(p,lpols) ==
       (degree(p) = 0) => lpols
       null lpols => [unitCanonical p]
       p1 := first(lpols)
       g := gcd(p,p1)
       (degree(g) = 0) => cons(p1,gcdBasisAdd(p,rest lpols))
       p := (p exquo g)::P
       p1 := (p1 exquo g)::P
       basis := gcdBasisAdd(p,rest(lpols))
       if degree(p1) > 0 then basis := cons(p1,basis)
       gcdBasisAdd(g,basis)
       

     gcdBasis(lpols) ==
       (#lpols <= 1) => lpols
       basis := gcdBasis(rest lpols)
       gcdBasisAdd(first(lpols),basis)
\end{spad}

\begin{spad}
)ab domain SCELL SimpleCell

-- This domain is made to work with one-dimensional semi-algebraic cells
-- ie either an algebraic point, either an interval. The point is specified as 
-- specification of an algebraic value.

SimpleCell(TheField,ThePols) : PUB == PRIV where
  TheField : RealClosedField
  ThePols : UnivariatePolynomialCategory(TheField)
  O           ==> OutputForm
  B           ==> Boolean
  Z           ==> Integer
  N           ==> NonNegativeInteger

--  VARS ==> VariationsPackage(TheField,ThePols)
  VARS ==> RealPolynomialUtilitiesPackage(TheField,ThePols)
  LF ==> List(TheField)

  PUB == CoercibleTo(O) with

     allSimpleCells : (ThePols,Symbol) -> List %
     allSimpleCells : (List(ThePols),Symbol) -> List %
     hasDimension? : % -> B
     samplePoint : % -> TheField
     stablePol : % -> ThePols
     variableOf : % -> Symbol
     separe : (LF,TheField,TheField) -> LF
     pointToCell : (TheField,B,Symbol) -> %

  PRIV == add

     Rep := Record(samplePoint:TheField,
                   hasDim:B,
                   varOf:Symbol)

     samplePoint(c) == c.samplePoint

     stablePol(c) == error "Prout"

     hasDimension?(c) == c.hasDim

     variableOf(c) == c.varOf

     coerce(c:%):O ==
       o : O := ((c.varOf)::O) = ((c.samplePoint)::O)
       brace [o,(c.hasDim)::O]

     separe(liste,gauche,droite) ==
       milieu : TheField := (gauche + droite) / (2::TheField)
       liste = [] => [milieu]
       #liste = 1 => [gauche,first(liste),droite]
       nbe := first(liste)
       lg :List(TheField) := []
       ld :List(TheField) := rest(liste)
       sg := sign(milieu-nbe)
       while sg > 0 repeat
         lg := cons(nbe,lg)
         ld = [] => return(separe(reverse(lg),gauche,milieu))
         nbe := first(ld)
         sg := sign(milieu-nbe)
         ld := rest(ld)
       sg < 0 =>
         append(separe(reverse(lg),gauche,milieu),
                rest(separe(cons(nbe,ld),milieu,droite)))
       newDroite := (gauche+milieu)/(2::TheField)
       null lg =>
           newGauche := (milieu+droite)/(2::TheField)
           while newGauche >= first(ld) repeat
             newGauche := (milieu+newGauche)/(2::TheField)
           append([gauche,milieu],separe(ld,newGauche,droite))
       while newDroite <= first(lg) repeat
         newDroite := (newDroite+milieu)/(2::TheField)
       newGauche := (milieu+droite)/(2::TheField)
       null ld => append(separe(reverse(lg),gauche,newDroite),[milieu,droite])
       while newGauche >= first(ld) repeat
         newGauche := (milieu+newGauche)/(2::TheField)
       append(separe(reverse(lg),gauche,newDroite),
              cons(milieu,separe(ld,newGauche,droite)))


     pointToCell(sp,hasDim?,varName) ==
       [sp,hasDim?,varName]$Rep

     allSimpleCells(p:ThePols,var:Symbol) ==
       allSimpleCells([p],var)

     PACK ==> CylindricalAlgebraicDecompositionUtilities(TheField,ThePols)
     allSimpleCells(lp:List(ThePols),var:Symbol) ==
       lp1 := gcdBasis(lp)$PACK
       null(lp1) => [pointToCell(0,true,var)]
       b := ("max" / [ boundOfCauchy(p)$VARS for p in lp1 ])::TheField
       l := "append" / [allRootsOf(makeSUP(unitCanonical(p))) for p in lp1]
       l := sort(l)
       l1 := separe(l,-b,b)
       res : List(%) := [pointToCell(first(l1),true,var)]
       l1 := rest(l1)
       while not(null(l1)) repeat
         res := cons(pointToCell(first(l1),false,var),res)
         l1 := rest(l1)
         l1 = [] => return(error "Liste vide")
         res := cons(pointToCell(first(l1),true,var),res)
         l1 := rest(l1)
       reverse! res
\end{spad}

\begin{spad}
)ab domain CELL Cell

Cell(TheField) : PUB == PRIV where
  TheField : RealClosedField

  ThePols ==> Polynomial(TheField)

  O           ==> OutputForm
  B           ==> Boolean
  Z           ==> Integer
  N           ==> NonNegativeInteger
  BUP         ==> SparseUnivariatePolynomial(TheField)
  SCELL       ==> SimpleCell(TheField,BUP)


  PUB == CoercibleTo(O) with

     samplePoint : % -> List(TheField)
     dimension : % -> N
     hasDimension? :  (%,Symbol) -> B
     makeCell : List(SCELL) -> %
     makeCell : (SCELL,%) -> %
     mainVariableOf : % -> Symbol
     variablesOf : % -> List Symbol
     projection : % -> Union(%,"failed")
     


  PRIV == add

    Rep := List(SCELL)

    coerce(c:%):O == 
      paren [sc::O for sc in c]

    projection(cell) ==
      null cell => error "projection: should not appear"
      r := rest(cell)
      null r => "failed"
      r

    makeCell(l:List(SCELL)) == l

    makeCell(scell,toAdd) == cons(scell,toAdd)

    mainVariableOf(cell) == 
      null(cell) => 
        error "Should not appear"
      variableOf(first(cell))

    variablesOf(cell) ==
      null(cell) => []
      cons(mainVariableOf(cell),variablesOf(rest(cell)::%))

    dimension(cell) ==
      null(cell) => 0
      hasDimension?(first(cell)) => 1+dimension(rest(cell))
      dimension(rest(cell))

    hasDimension?(cell,var) ==
      null(cell) => 
        error "Should not appear"
      sc : SCELL := first(cell)
      v := variableOf(sc)
      v = var => hasDimension?(sc)
      v < var => false
      v > var => true
      error "Caca Prout"

    samplePoint(cell) ==
      null(cell) => []
      cons(samplePoint(first(cell)),samplePoint(rest(cell)))
\end{spad}

\begin{spad}
)ab pack CAD CylindricalAlgebraicDecompositionPackage

CylindricalAlgebraicDecompositionPackage(TheField) : PUB == PRIV where

  TheField : RealClosedField

  ThePols ==> Polynomial(TheField)
  P ==> ThePols
  BUP ==> SparseUnivariatePolynomial(TheField)
  RUP ==> SparseUnivariatePolynomial(ThePols)

  Z           ==> Integer
  N           ==> NonNegativeInteger

  CELL ==> Cell(TheField)
  SCELL ==> SimpleCell(TheField,BUP)

  PUB == with

      cylindricalDecomposition: List P ->        List CELL
      cylindricalDecomposition: (List(P),List(Symbol)) ->        List CELL
      projectionSet: (List RUP)                ->    List P
      coefficientSet: RUP                ->    List P
      discriminantSet : List RUP -> List(P)
      resultantSet :  List RUP -> List P 
      principalSubResultantSet : (RUP,RUP) -> List P
      specialise : (List(ThePols),CELL) -> List(BUP)

  PRIV == add

     cylindricalDecomposition(lpols) ==
       lv : List(Symbol) := []
       for pol in lpols repeat
         ground?(pol) => "next pol"
         lv := removeDuplicates(append(variables(pol),lv))
       lv := reverse(sort(lv))
       cylindricalDecomposition(lpols,lv)

     cylindricalDecomposition(lpols,lvars) ==
       lvars = [] => error("CAD: cylindricalDecomposition: empty list of vars")
       mv := first(lvars)
       lv := rest(lvars)
       lv = [] =>
         lp1 := [ univariate(pol) for pol in lpols ]
         scells := allSimpleCells(lp1,mv)$SCELL
         [ makeCell([scell]) for scell in scells ]
       lpols1 := projectionSet [univariate(pol,mv) for pol in lpols]
       previousCad := cylindricalDecomposition(lpols1,lv)
       res : List(CELL) := []
       for cell in previousCad repeat
         lspec := specialise(lpols,cell)
         scells := allSimpleCells(lspec,mv)
         res := append(res,[makeCell(scell,cell) for scell in scells])
       res


     PACK1 ==> CylindricalAlgebraicDecompositionUtilities(ThePols,RUP)
     PACK2 ==> CylindricalAlgebraicDecompositionUtilities(TheField,BUP)

     specialise(lpols,cell) ==
       lpols = [] => error("CAD: specialise: empty list of pols")
       sp := samplePoint(cell)
       vl := variablesOf(cell)
       res : List(BUP) := []
       for pol in lpols repeat
         p1 := univariate(eval(pol,vl,sp))
--         zero?(p1) => return(error "Bad sepcialise")
         degree(p1) = 0 => "next pol"
         res := cons(p1,res)
       res


     coefficientSet(pol) ==
       res : List(ThePols) := []
       for c in coefficients(pol) repeat
         ground?(c) => return(res)
         res := cons(c,res)
       res

     SUBRES ==> SubResultantPackage(ThePols,RUP)
     discriminantSet(lpols) ==
       res : List(ThePols) := []
       for p in lpols repeat
         v := subresultantVector(p,differentiate(p))$SUBRES
         not(zero?(degree(v.0))) => return(error "Bad discriminant")
         d : ThePols :=  leadingCoefficient(v.0)
--         d := discriminant p
         zero?(d) => return(error "Non Square Free polynomial")
         if not(ground? d) then res := cons(d,res)
       res

     principalSubResultantSet(p,q) ==
        if degree(p) < degree(q)
        then (p,q) := (q,p)
        if degree(p) = degree(q)
        then (p,q) := (q,pseudoRemainder(p, q))
        v := subresultantVector(p,q)$SUBRES
        [coefficient(v.i,i) for i in 0..(((#v)-2)::N)]

     resultantSet(lpols) ==
       res : List(ThePols) := []
       laux := lpols
       for p in lpols repeat
         laux := rest(laux)
         for q in laux repeat
           r : ThePols :=  first(principalSubResultantSet(p,q))
--           r := resultant(p,q)
           zero?(r) => return(error "Non relatively prime polynomials")
           if not(ground? r) then res := cons(r,res)
       res

     projectionSet(lpols) ==
       res : List(ThePols) := []
       for p in lpols repeat
         c := content(p)
         ground?(c) => "next p"
         res := cons(c,res)
       lp1 := [primitivePart p for p in lpols]
       f : ((RUP,RUP) -> Boolean) := (degree(#1) <= degree(#2))
       lp1 := sort(f,lp1)
       lsqfrb := squareFreeBasis(lp1)$PACK1
       lsqfrb := sort(f,lsqfrb)
       for p in lp1 repeat
         res := append(res,coefficientSet(p))
       res := append(res,discriminantSet(lsqfrb))
       append(res,resultantSet(lsqfrb))
\end{spad}

\begin{axiom}
)lib )dir .
)lib SCELL CELL CAD
Ran := RECLOS(FRAC INT)
Cad := CAD(Ran)
p1 : POLY(Ran) := x^2+y^2-1
p2 : POLY(Ran) := y-x^2
lpols : List(POLY(Ran)) := [p1,p2]
cad := cylindricalDecomposition(lpols)$Cad
precision(30)
ls := [ samplePoint cell for cell in cad]
lf := [ [relativeApprox(coord,2^(-precision()))::Float for coord in point] for point in ls]
lp := [ point(term::List(DoubleFloat))$Point(DoubleFloat) for term in lf ]
[ sign(eval(p1,variables(p1),samplePoint(cell))::Ran) for cell in cad ]
--[ sign(eval(p2,variables(p2),samplePoint(cell))::Ran) for cell in cad ]
\end{axiom}

\start
Date: Wed, 12 Oct 2005 18:55:13 -0400
From: Tim Daly
To: Renaud Rioboo
Subject: Re: Cylindrical Algebraic Decompostion for Axiom

I'm extremely interested. In particular, it would be helpful to get
permission to use the papers (and/or your thesis) as documentation
to both the algorithm and the program.

Axiom's been moved to using "literate programs" so that all of the files
are now latex documents. Source code for the programs are extracted at
build time. This isn't all that apparent because the algebra source
code for most files is the only contents of the latex file (the literate
program). The only real example of the future form of documentation is
in dhmatrix.spad.pamphlet. I'd like to see the CAD work brought up to
that level of documentation.

Are there any papers you could include in the released materials that
could be merged with code?

\start
Date: Wed, 12 Oct 2005 20:18:13 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: FW: Important! Cannot Install on Fedora

On Wednesday, October 12, 2005 7:28 PM Camm Maguire wrote:
> ...
> Bill Page wrote:
> > I don't know much about Debian, but I understand that there is
> > some utility for accessing Debian products on "alien" linuxes.
> > Has anyone tried using this approach to install Axiom on other
> > platforms?
> >
>
> The alien program can convert the .deb to a .rpm, which should
> save everyone a lot of work I'd think.  One can even unpack a
> tarball from the deb -- details on request.
>

This is what I have tried so far on the axiom-developer.org
server (which is running RedHat 9). If anyone has some experience
with doing this and has some suggestions and explanations to
offer, I would greatly appreciate it!

First I go here

http://kitenet.net/programs/alien/

to download and install the 'alien' program from 'Latest source code'

Then I visit

http://packages.debian.org/unstable/math/axiom

click on i386, choose a mirror and download the *.deb file

I become root and then run

  # alien --to-rpm axiom_20050901-2_i386.deb

It gives me some warnings about omitting "scripts":

  Warning: Skipping conversion of scripts in package axiom: postinst
postrm
  Warning: Use the --scripts parameter to include the scripts.
  axiom-20050901-3.i386.rpm generated

Should I have used the --scripts parameter?

Now I can try a test run:

  # rpm -ihv --test axiom-20050901-3.i386.rpm

It tells me:

  error: Failed dependencies:
        libreadline.so.5 is needed by axiom-20050901-3

--------

Hmmm... I guess this sort of is working :) but where to go from
here? Should I continue to try to satisfy a dependencies like
libreadline.so.5 from Debian binaries?

\start
Date: 12 Oct 2005 20:35:09 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: FW: Important! Cannot Install on Fedora

Greetings!

Bill Page writes:

> On Wednesday, October 12, 2005 7:28 PM Camm Maguire wrote:
> > ...
> > Bill Page wrote: 
> > > I don't know much about Debian, but I understand that there is
> > > some utility for accessing Debian products on "alien" linuxes.
> > > Has anyone tried using this approach to install Axiom on other
> > > platforms?
> > > 
> > 
> > The alien program can convert the .deb to a .rpm, which should
> > save everyone a lot of work I'd think.  One can even unpack a
> > tarball from the deb -- details on request.
> >
> 
> This is what I have tried so far on the axiom-developer.org
> server (which is running RedHat 9). If anyone has some experience
> with doing this and has some suggestions and explanations to
> offer, I would greatly appreciate it!
> 
> First I go here
> 
> http://kitenet.net/programs/alien/
> 
> to download and install the 'alien' program from 'Latest source code'
> 
> Then I visit
> 
> http://packages.debian.org/unstable/math/axiom
> 
> click on i386, choose a mirror and download the *.deb file
> 
> I become root and then run
> 
>   # alien --to-rpm axiom_20050901-2_i386.deb
> 
> It gives me some warnings about omitting "scripts":
> 
>   Warning: Skipping conversion of scripts in package axiom: postinst
> postrm
>   Warning: Use the --scripts parameter to include the scripts.
>   axiom-20050901-3.i386.rpm generated
> 
> Should I have used the --scripts parameter?
> 
> Now I can try a test run:
> 
>   # rpm -ihv --test axiom-20050901-3.i386.rpm
> 
> It tells me:
> 
>   error: Failed dependencies:
>         libreadline.so.5 is needed by axiom-20050901-3
> 
> --------
> 
> Hmmm... I guess this sort of is working :) but where to go from
> here? Should I continue to try to satisfy a dependencies like
> libreadline.so.5 from Debian binaries?
> 

I agree this appears to be working.  You can either continue
converting from the debs (all of which are listed on the Debian
package webpage), or you can grab the libs from your distribution
using whatever method they use.  libreadline, libncurses, and libgmp3
should be all the unusual libs you need.

\start
Date: Wed, 12 Oct 2005 21:31:06 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: FW: Important! Cannot Install on Fedora

On Wednesday, October 12, 2005 8:35 PM Camm Maguire wrote:
> Bill Page wrote:
> >
> > First I go here
> >
> > http://kitenet.net/programs/alien/
> >
> > to download and install the 'alien' program from 'Latest
> source code'
> >
> > Then I visit
> >
> > http://packages.debian.org/unstable/math/axiom
> >
> > click on i386, choose a mirror and download the *.deb file
> >
> > I become root and then run
> >
> >   # alien --to-rpm axiom_20050901-2_i386.deb
> >
> > It gives me some warnings about omitting "scripts":
> >
> >   Warning: Skipping conversion of scripts in package axiom: postinst
> > postrm
> >   Warning: Use the --scripts parameter to include the scripts.
> >   axiom-20050901-3.i386.rpm generated
> >
> > Should I have used the --scripts parameter?
> >
> > Now I can try a test run:
> >
> >   # rpm -ihv --test axiom-20050901-3.i386.rpm
> >
> > It tells me:
> >
> >   error: Failed dependencies:
> >         libreadline.so.5 is needed by axiom-20050901-3
> >
> > --------
> >
> > Hmmm... I guess this sort of is working :) but where to go from
> > here? Should I continue to try to satisfy a dependencies like
> > libreadline.so.5 from Debian binaries?
> >
>
> I agree this appears to be working.  You can either continue
> converting from the debs (all of which are listed on the Debian
> package webpage), or you can grab the libs from your distribution
> using whatever method they use.  libreadline, libncurses, and
> libgmp3 should be all the unusual libs you need.
>

Cool!

I probably have libgmp3 already installed for other reasons
so that dependency is already satisfied.

Now I continued as follows:

On page http://packages.debian.org/unstable/math/axiom
I clicked the 'libreadline5' dependency, chose a mirror and
downloaded

  libreadline5_5.0-11_i386.deb

I ran

  # alien --to-rpm libreadline5_5.0-11_i386.deb

and then

  # rpm -ihv libreadline5_5.0-11_i386.rpm

I also notice from http://packages.debian.org/unstable/math/axiom
that 'axiom-databases' is a dependency so I click, and download

  axiom-databases_20050901-2_all.deb

and run

    # alien --to-rpm axiom-databases_20050901-2_all.deb
    # rpm -ihv axiom-databases_20050901-2_all.rpm

Finally (with a momemt's hesitation ...) I actually run

    # rpm -ihv axiom-20050901-3.i386.rpm

I exit from root and type:

[page@axiom-developer page]$ /usr/bin/axiom

Et voil=E0!
---------

GCL (GNU Common Lisp)  2.6.7 CLtL1    Sep 29 2005 18:04:31
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
                        AXIOM Computer Algebra System
                     Version: Axiom 3.9 (September 2005)
             Timestamp: Thursday September 29, 2005 at 20:04: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.
-----------------------------------------------------------------

(1) -> D(sin x,x)
   Loading /usr/lib/axiom-20050901/algebra/EXPR.o for domain Expression
   ...

   (1)  cos(x)
                                        Type: Expression Integer

------
Amazingly easy! I love Debian - even Debian on non-Debian linux.  :-)

Of course this is just command line Axiom, but I presume that
I could continue like this and install the rest of Axiom,

http://packages.debian.org/unstable/math/axiom-graphics
http://packages.debian.org/unstable/math/axiom-hypertex

Even better now I have set of 'rpm' files that I can include on
the AxiomDownload page on the Axiom wiki and then anyone with an
'rpm-style' linux should be able to just downlaod and install these
rpm's as if they were native.

Simply wonderful technology. :-))

If anyone else can confirm that this works for them, then
I will add an appropriate section to the AxiomDownload page.

\start
Date: Wed, 12 Oct 2005 21:43:24 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] 

??changed:
-  The following binary versions of Axiom are available for testing:
  An experimental binary distribution of Axiom consisting of the following
  RPM files was prepared from the current
  "Axiom on Debian":http://packages.debian.org/unstable/math/axiom distribution
  using the "alien":http://kitenet.net/programs/alien program.

  - "axiom-20050901-3.i386.rpm":Mirrors?go=/public/axiom-20050901-3.i386.rpm&it=axiom-20050901-3.i386.rpm
    ${\bf\longleftarrow}$ **Required**

  - "axiom-databases-20050901-3.noarch.rpm":Mirrors?go=/public/axiom-databases-20050901-3.noarch.rpm&it=axiom-databases-20050901-3.noarch.rpm
    ${\bf\longleftarrow}$ **Required**

  - "axiom-doc-20050901-3.noarch.rpm":Mirrors?go=/public/axiom-doc-20050901-3.noarch.rpm&it=axiom-doc-20050901-3.noarch.rpm 

  - "axiom-graphics-20050901-3.i386.rpm":Mirrors?go=/public/axiom-graphics-20050901-3.i386.rpm&it=axiom-graphics-20050901-3.i386.rpm 

  - "axiom-graphics-data-20050901-3.noarch.rpm":Mirrors?go=/public/axiom-graphics-data-20050901-3.noarch.rpm&it=axiom-graphics-data-20050901-3.noarch.rpm 

  - "axiom-hypertex-20050901-3.i386.rpm":Mirrors?go=/public/axiom-hypertex-20050901-3.i386.rpm&it=axiom-hypertex-20050901-3.i386.rpm 

  - "axiom-hypertex-data-20050901-3.noarch.rpm":Mirrors?go=/public/axiom-hypertex-data-20050901-3.noarch.rpm&it=axiom-hypertex-data-20050901-3.noarch.rpm 

  - "axiom-source-20050901-3.noarch.rpm":Mirrors?go=/public/axiom-source-20050901-3.noarch.rpm&it=axiom-source-20050901-3.noarch.rpm 

  - "axiom-test-20050901-3.noarch.rpm":Mirrors?go=/public/axiom-test-20050901-3.noarch.rpm&it=axiom-test-20050901-3.noarch.rpm 

  - "axiom-tex-20050901-3.noarch.rpm":Mirrors?go=/public/axiom-tex-20050901-3.noarch.rpm&it=axiom-tex-20050901-3.noarch.rpm 

  These files should work on most linux systems that support 'rpm' (such as
  RedHat, Fedora, Suse, Mandrake etc.). Download at least the first two rpm's
  above and then install via::

    # rpm -ihv axiom-20050901-3.i386.rpm axiom-databases-20050901-3.noarch.rpm

  For missing dependencies consult the
  "Axiom on Debian":http://packages.debian.org/unstable/math/axiom page.

  Since this distribution of Axiom is still experimental please report both
  success or failure in the comment form at the bottom of this page.
 
  Additional binary tarballs for Axiom compiled on specific platforms are
  also available for testing:

--removed:
-    ${\bf\longleftarrow}$ **Recommended Download**

\start
Date: Wed, 12 Oct 2005 21:51:38 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] 


??changed:
- 


++added:

  - "Debian version":http://packages.debian.org/unstable/math/axiom.html

    Use the command::

      # apt-get install axiom

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

??changed:
-  above. You may use the "issues":http:/zope/mathaction/FrontPage/issuetracker
-  system to report problems.
  above. You may use the "issues":issuetracker system to report problems.

\start
Date: Wed, 12 Oct 2005 21:53:07 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] 


??changed:
-Note: See comments from RenaudRioboo below concerning item 0).
  Note: See comments from RenaudRioboo below concerning installation step 0).

\start
Date: Thu, 13 Oct 2005 05:17:32 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#217 Severe Compiler error?] (nouveau) 

I'm afraid I found my first severe compiler error. Unfortunately, I do
not know yet how to workaround. I cannot even see how to localize
it. I put an example on SandBox3, but I'll try to reproduce it here.

\start
Date: Thu, 13 Oct 2005 05:27:27 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#217 Severe Compiler error?] 


??changed:

-I'm afraid I found my first severe compiler error. Unfortunately, I
 do not know yet how to workaround. I cannot even see how to localize
 it. I put an example on SandBox3, but I'll try to reproduce it here.

I'm afraid I found my first severe compiler error. Unfortunately, I do
not know yet how to workaround. I cannot even see how to localize it.

\begin{spad}
)abbrev package TEST Test
Test(): Exports == Implementation where

   NNI ==> NonNegativeInteger

   Exports == with

     subsetToComp: List Integer -> List NNI

   Implementation == add
         
     subsetToComp v ==
       res: List NNI := []
\end{spad}

\begin{axiom}
)set stream calculate 3
s := coefficients series(q^(m-i),q=1)
)lib TEST
eval(s.2,i,%A)
eval(s.2,i,%B)
\end{axiom}

Obviously, the final lines should read 'm-%A' and 'm-%B'. The error
seems to go away if the series is generated after the ')lib' command
or if the series contains no other variables apart from 'q' and
'i'. Furthermore, '%A' seems to be somehow special, but I cannot
reproduce this peculiarity here.

I would be very grateful if somebody could at least localize the
error, so that I can determine when it happens. This bug has
unfortunately tremendous implications, for example, a product like
$\prod_{i=1}^n f(i)$ is replaced by $f(i)^n$...

\start
Date: Thu, 13 Oct 2005 08:06:27 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#217 Severe Compiler error?] Workaround

If we issue the ')lib' command before defining any variables, the
problem goes away. Hence, it is rather an inconvenience. Still, I have
the feeling that there might be some bad surprise lurking around...

\start
Date: Thu, 13 Oct 2005 08:06:53 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#217 Severe Compiler error?] easy workaround,	therefore only minor

Severity: critical => minor 

\start
Date: 13 Oct 2005 09:59:42 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: FW: Important! Cannot Install on Fedora

Bill Page writes:

> Cool!
>
> I probably have libgmp3 already installed for other reasons
> so that dependency is already satisfied.
>
> Now I continued as follows:
>
> On page http://packages.debian.org/unstable/math/axiom
> I clicked the 'libreadline5' dependency, chose a mirror and
> downloaded
>
>   libreadline5_5.0-11_i386.deb
>
> I ran
>
>   # alien --to-rpm libreadline5_5.0-11_i386.deb
>
> and then
>
>   # rpm -ihv libreadline5_5.0-11_i386.rpm
>
> I also notice from http://packages.debian.org/unstable/math/axiom
> that 'axiom-databases' is a dependency so I click, and download
>
>   axiom-databases_20050901-2_all.deb
>
> and run
>
>     # alien --to-rpm axiom-databases_20050901-2_all.deb
>     # rpm -ihv axiom-databases_20050901-2_all.rpm
>
> Finally (with a momemt's hesitation ...) I actually run
>
>     # rpm -ihv axiom-20050901-3.i386.rpm
>
> I exit from root and type:
>
> [page@axiom-developer page]$ /usr/bin/axiom
>
> Et voil=E0!
> ---------
>
> GCL (GNU Common Lisp)  2.6.7 CLtL1    Sep 29 2005 18:04:31
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
> Modifications of this banner must retain notice of a compatible license
> Dedicated to the memory of W. Schelter
>
> Use (help) to get some basic information on how to use GCL.
>                         AXIOM Computer Algebra System
>                      Version: Axiom 3.9 (September 2005)
>              Timestamp: Thursday September 29, 2005 at 20:04: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.
> -----------------------------------------------------------------
>
> (1) -> D(sin x,x)
>    Loading /usr/lib/axiom-20050901/algebra/EXPR.o for domain Expression
>    ...
>
>    (1)  cos(x)
>                                         Type: Expression Integer
>
> ------
> Amazingly easy! I love Debian - even Debian on non-Debian linux.  :-)
>

Glad to hear you are pleased.  I am too -- I think the system in
general is quite well designed.  And what keeps it running is open
source licensing -- i.e. everyone sharing the fruits of each others'
efforts.  If aldor can ever meet this standard, I would be happy to
try to do the same for it, though I understand securing such
permission might be difficult.  BTW, what language is aldor written
in?

Take care,

> Of course this is just command line Axiom, but I presume that
> I could continue like this and install the rest of Axiom,
>
> http://packages.debian.org/unstable/math/axiom-graphics
> http://packages.debian.org/unstable/math/axiom-hypertex
>
> Even better now I have set of 'rpm' files that I can include on
> the AxiomDownload page on the Axiom wiki and then anyone with an
> 'rpm-style' linux should be able to just downlaod and install these
> rpm's as if they were native.
>
> Simply wonderful technology. :-))
>
> If anyone else can confirm that this works for them, then
> I will add an appropriate section to the AxiomDownload page.

\start
Date: 13 Oct 2005 11:46:24 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Axiom Lisp API for OpenMath

Do I take it that this entails making lisp functions with the
following names in some appropriate package with the functionality of
the C code listed adjacent to them?:

setup_type const om_setup[] = {
	/* LISP Name */			/* Unary */			/* Binary */		/* Nary */
	{"om-openFileDev",		wrong_no_3a,		wrong_no_3b,		om_openFileDev},
	{"om-openStringDev",            too_few_2,		om_openStringDev,	wrong_no_2},
	{"om-closeDev",			om_closeDev,		too_many_1,		wrong_no_1},
	{"om-setDevEncoding",	        too_few_2,		om_setDevEncoding,	wrong_no_2},

	{"om-makeConn",			om_makeConn,		too_many_1,		wrong_no_1},
	{"om-closeConn",		om_closeConn,		too_many_1,		wrong_no_1},
	{"om-getConnInDev",		om_getConnInDev,	too_many_1,		wrong_no_1},
	{"om-getConnOutDev",	        om_getConnOutDev,	too_many_1,		wrong_no_1},

	{"om-connectTCP",		wrong_no_3a,		wrong_no_3b,		om_connectTCP},
	{"om-bindTCP",			too_few_2,		om_bindTCP,		wrong_no_2},

	{"om-putApp",			om_putApp,		too_many_1,		wrong_no_1},
	{"om-putEndApp",		om_putEndApp,		too_many_1,		wrong_no_1},
	{"om-putAtp",			om_putAtp,		too_many_1,		wrong_no_1},
	{"om-putEndAtp",		om_putEndAtp,		too_many_1,		wrong_no_1},
	{"om-putAttr",			om_putAttr,		too_many_1,		wrong_no_1},
	{"om-putEndAttr",		om_putEndAttr,		too_many_1,		wrong_no_1},
	{"om-putBind",			om_putBind,		too_many_1,		wrong_no_1},
	{"om-putEndBind",		om_putEndBind,		too_many_1,		wrong_no_1},
	{"om-putBVar",			om_putBVar,		too_many_1,		wrong_no_1},
	{"om-putEndBVar",		om_putEndBVar,		too_many_1,		wrong_no_1},
	{"om-putError",			om_putError,		too_many_1,		wrong_no_1},
	{"om-putEndError",		om_putEndError,		too_many_1,		wrong_no_1},
	{"om-putObject",		om_putObject,		too_many_1,		wrong_no_1},
	{"om-putEndObject",		om_putEndObject,	too_many_1,		wrong_no_1},

	{"om-putInt",			too_few_2,		om_putInt,		wrong_no_2},
	{"om-putFloat",			too_few_2,		om_putFloat,		wrong_no_2},
	{"om-putByteArray",		too_few_2,		om_putByteArray,	wrong_no_2},
	{"om-putVar",			too_few_2,		om_putVar,		wrong_no_2},
	{"om-putString",		too_few_2,		om_putString,		wrong_no_2},
	{"om-putSymbol",		too_few_2,		om_putSymbol,		om_putSymbol2},

	{"om-getApp",			om_getApp,		too_many_1,		wrong_no_1},
	{"om-getEndApp",		om_getEndApp,		too_many_1,		wrong_no_1},
	{"om-getAtp",			om_getAtp,		too_many_1,		wrong_no_1},
	{"om-getEndAtp",		om_getEndAtp,		too_many_1,		wrong_no_1},
	{"om-getAttr",			om_getAttr,		too_many_1,		wrong_no_1},
	{"om-getEndAttr",		om_getEndAttr,		too_many_1,		wrong_no_1},
	{"om-getBind",			om_getBind,		too_many_1,		wrong_no_1},
	{"om-getEndBind",		om_getEndBind,		too_many_1,		wrong_no_1},
	{"om-getBVar",			om_getBVar,		too_many_1,		wrong_no_1},
	{"om-getEndBVar",		om_getEndBVar,		too_many_1,		wrong_no_1},
	{"om-getError",			om_getError,		too_many_1,		wrong_no_1},
	{"om-getendError",		om_getEndError,		too_many_1,		wrong_no_1},
	{"om-getObject",		om_getObject,		too_many_1,		wrong_no_1},
	{"om-getEndObject",		om_getEndObject,	too_many_1,		wrong_no_1},

	{"om-getInt",			om_getInt,		too_many_1,		wrong_no_1},
	{"om-getFloat",			om_getFloat,		too_many_1,		wrong_no_1},
	{"om-getByteArray",		om_getByteArray,	too_many_1,		wrong_no_1},
	{"om-getVar",			om_getVar,		too_many_1,		wrong_no_1},
	{"om-getString",		om_getString,		too_many_1,		wrong_no_1},
	{"om-getSymbol",		om_getSymbol,		too_many_1,		wrong_no_1},

	{"om-getType",			om_getType,		too_many_1,		wrong_no_1},

	{"om-stringToStringPtr",     om_stringToStringPtr,      too_many_1,		wrong_no_1},
	{"om-stringPtrToString",     om_stringPtrToString,      too_many_1,		wrong_no_1},

	{NULL,	0,	0,	0}
};


Take care,

Bill Page writes:

> Tim,
> 
> I searched through my source archives but I did not find the
> file 'src/cslbase/openmath.c' referred to by Mike Dewar in the
> email below. Apparently we need to write something analogous
> for GCL to interface with the Open Math library in OMCv1.4a.tgz
> 
> OMCv1.4a.tgz is in the current zips directory. It compiles
> but does not pass the make tests (maybe not significant as
> implied by warning in the README).
> 
> Do you know where I can file src/cslbase/openmath.c?
> 
> Regards,
> Bill Page.
> 
> --------
> 
> From: 	Mike Dewar
> Subject: 	re: ... user interface issues.
> Date: 	Tue, 1 Jul 2003 10:06:07 +0100
> 
> Oops, I think this is because Axiom isn't being built with the OpenMath
> libraries from INRIA.  I took this out when passing the sources to Tim
> because of licensing issues - there is a general free license but we
> have access to the libraries under a different arrangement.  You can
> download the libraries at http://www.openmath.org/software/OMCv1.4a.tgz
> if you're interested, but you'll need to look at the appropriate part of
> CCL (src/cslbase/openmath.c which Tim has) to work out what the Lisp API
> should look like.
> 
> Mike.
> 
> On Thu, Jun 26, 2003 at 11:28:39AM +1000, Jason White wrote:
> > Mike Dewar writes:
> >  > On Wed, Jun 25, 2003 at 07:53:47PM +1000, Jason White wrote:
> >  > > While on the subject of output formats, as a longer-term goal, MathML
> >  > > would probably be a useful addition.
> >  > I agree.  Actually we started including OpenMath (which in a way is a
> >  > superset of MathML) and were planning to include MathML once it
> >  > stabilised.
> >  > 
> >  > G82328 (2) -> OMwrite sin(x)
> > 
> > Interesting. Upon issuing this command under Tim's test release I get:
> > 
> > (1) -> OMwrite sin(x)
> >  
> >    >> System error:
> >    OM-STRINGTOSTRINGPTR is invalid as a function.
> > 
> > protected-symbol-warn called with (NIL)
> > 
> > Another item for the bug list?

\start
Date: Thu, 13 Oct 2005 12:53:29 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Axiom Lisp API for OpenMath

On Thursday, October 13, 2005 11:46 AM Camm Maguire wrote:
>
> Do I take it that this entails making lisp functions with the
> following names in some appropriate package with the functionality
> of the C code listed adjacent to them?:
>
> setup_type const om_setup[] = {
> 	/* LISP Name */			/* Unary */	=09
> 	/* Binary */		/* Nary */
> 	{"om-openFileDev",		wrong_no_3a,	=09
> wrong_no_3b,		om_openFileDev},
> 	{"om-openStringDev",            too_few_2,	=09
> om_openStringDev,	wrong_no_2},
> 	{"om-closeDev",			om_closeDev,	=09
> too_many_1,		wrong_no_1},
> ...

Yes, sort of. What is required I think, are lisp bindings to
the existing OpenMath version 1 library (freely available and
written in C). We have a prototype for these bindings written
for ccl lisp :(of course not directly usable in GCL).

Some of these functions look a little peculiar and specific
to Axiom's internal representation, for example there is a
function that returns a pointer to an Axiom string which is
used as a global buffer to accumulate OpenMath output. But
if this worked once (albeit with ccl lisp), it seems likely
that it can be made to work again.

As an alternative there is a freely available XML/OpenMath
library written in Aldor. But interfacing the current Axiom
OpenMath functionality to this Aldor library seems likely to
be more work then just getting the OpenMath version 1 library
to work again, even if the end result might be more maintainable
in the long run. Version 2 of the OpenMath specification is
already available, but according to Mike Dewar there are
currently no plans to make a version 2 of the OpenMath library.
Having the library available in Aldor would be an advantage.

\start
Date: Fri, 14 Oct 2005 00:46:17 -0400
From: Tim Daly
To: Brian Kennedy
Subject: Building on Axiom... funding Axiom...

(posted with permission)

Brian Kennedy wrote:

> Tim,
>
> On the Axiom Community wiki, you state:
> 
> > Clearly I have no creative new ideas about how to get money. However 
> > if you take the "30 year view" of computer algebra it is clear that we 
> > need to build on the current systems rather than start from scratch. 
> > For one thing there is already 30 years of funding investment in Axiom 
> > which shows just how expensive it can be to develop a "real" system. 
> > For another it is clear that no-one is going to support another 30 
> > years of funding just to achieve the same level as Axiom has reached.
> 
> How about the way the Mac OS X effort helped fund and develop the free 
> Darwin Unix kernel?

I'm not familiar with this effort.

> 
> If you could find a commercial system that needed a CAS at its core, 
> AND was willing to fund development of a free CAS rather than 
> developing yet-another-CAS on its own nickel...  would the Axiom 
> development community be interested?

Actually I gave a little hint in that direction. KOffice has a 
math-based front end. The thought was that we could use it as
a generally available front end for axiom that would then be
distributed with KDE. Still a lot of work just to get this to go.

> 
> On that note... what is the state of Axiom development?  How many 
> developers are working on it?  And are they working on it full time, or 
> just part time?  Is there any funding right now?  (Sorry, but I've just 
> started perusing the Axiom site... so, there's some basics that I 
> haven't uncovered yet.)

There are probably a dozen active developers although the actual 
number of registered developers is about 80 or so. People come and
go as time and interest allow.

> 
> 
> Let me introduce myself.  My company is currently developing a Product 
> Development system targeted at engineers.  It is not at all a CAS... 
> but at its core, it could leverage a subset of CAS functionality.  I 
> can develop what I need incrementally... not a problem... a small 
> subset will do for a while, and I can gradually build out the rest that 
> I need.  But I HATE re-inventing wheels!  And given Axiom has 30 years 
> of development on it, even if light development, it would be very nice 
> to start with that!  Long-term, I'm sure some of that other well-tested 
> functionality will come in quite handy.

If you're only looking for a small subset of a CAS I would point out
that there are about 80 that already exist.I put together a "Rosetta"
CD years ago that contained some of them. They are quite easy to find.
Most people who like the idea of writing a CAS end up making the seemingly
novel connection between operator overloading and polynomial arithmetic.
They end up with a project that takes about 6 months and generate a
library of polynomial manipulation code, freely distributed, that others
can use, which rarely happens. 

If you only want simple functionality you probably want to look at
what is already available that might suit your needs.

> 
> Two big drawbacks to just building on the free Axiom code:
> 1) I'm sure there will be a huge learning curve in figuring out how to 
> best leverage / integrate Axiom into my system (I don't think there's a 
> nice .NET library for Axiom);
> 2) The additions that I make to Axiom will be hacks for my purpose, 
> rather than being made such that they can benefit all users of Axiom.
> In fact, it would probably be quicker and easier (for the first year or 
> so) for me to throw together the minimal subset I need in C# than to 
> try to understand how to get that subset implemented in Axiom and all 
> the other interfacing and so on.  Unless, perhaps, if I have some Axiom 
> experts helping me out.

You're free to use Axiom any way you like. We don't require that you
give code to the project although that's always welcome. Axiom has a
steep learning curve and there are hardly anyone that claims "expert"
status, including myself.

> 
> While my system won't be a CAS, a subset of my users would benefit from 
> a CAS to help them develop the equations that they need to input into 
> my system.  Via MathML cut n' paste, they'll be able to use any of  the 
> "3M's" to do that.  But packaging up a free alternative for that could 
> open the door for a much more integral solution in the future... and 
> would bring more users to Axiom.
> 

There has been some discussion of MathML and Axiom. When Axiom was a
commercial product the interface used to work. The library is still
there but has not been re-integrated. I don't have anything that will
display MathML so I haven't felt the need to raise the priority of
the task as I can't test the result.

> 
> Anyway, before I fill your email box any further, I should ask:
> 
> Would there be any interest from the Axiom developers in working with a 
> commercial software company to develop out some functionality to make 
> Axiom usable as a core to that commercial system (funded, of course)?
> If so, would there be any capacity to do so near-term?
> If not, when would there be capacity? what timeline should I have in 
> mind?

I can't answer for the community. For myself I'm busy with tasks that
are so very far behind the scenes that no-one will notice. We had a
student funded by Google for the summer to work on a user interface
and the idea of purpose-directed funding seems to have worked out well.
If you wanted to sponsor someone to work on MathML or any other 
well-defined task that could probably be arranged. We also have a
fund for specific tasks managed by a committee (of which I'm not a
member).

> 
> More specifically, is there interest in adding the following to Axiom:
> 1) Support for units (somewhat like Maple has)?
> 2) Support for content MathML, both in and out?
> 3) .NET interfaces to allow it to serve as the core of a .NET app?

Units are a very hot topic this month. See the mail archives for notes
from CY Student and William Sit.

MathML seems to have become another active interest. Bill Page and
Camm Maguire have recently discussed this (some time in the last few
days if memory serves).

So far no one has mentioned .NET

> 
> If the community has no interest in those things, then it wouldn't be 
> much of a win to have a company funding the development of such things.
> 
> Thanks for listening,
> Brian

So far the only funding Axiom has received is either donations or
Google funding.

I've copied the mailing list to see what other people think (this is,
after all, a community project).

\start
Date: Fri, 14 Oct 2005 03:06:19 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#218 New version Reduce 3.8 includes MathML]	(new) 

Winfried Neun and Tony Hearn kindly provided an upgrade to
Reduce. The new version 3.8 (dated May 2005) has been
installed on the MathAction website (both wiki and portal).

Most noticable is that Reduce now has experimental supports
for MathML input and output. Some changes are required to the
Reduce interface to support rendering of MathML output. See
a preliminary example here: [SandBox Reduce And MathML]. Work
on the MathML interface is continuing.

For more information about version 3.8 of Reduce see:
http://www.reduce-algebra.com

\start
Date: Fri, 14 Oct 2005 06:40:22 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#210 Pamphlet support on MathAction] links updated after rename

??changed:
-See [SandBox Pamphlet] for a real working example of an Axiom
See SandBoxPamphlet for a real working example of an Axiom

\start
Date: Fri, 14 Oct 2005 07:20:39 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Brian Kennedy
Subject: Re: Building on Axiom... funding Axiom...

> >
> > More specifically, is there interest in adding the following to
> > Axiom:
> > 1) Support for units (somewhat like Maple has)?
> > 2) Support for content MathML, both in and out?
> > 3) .NET interfaces to allow it to serve as the core of a .NET app?
> 
> Units are a very hot topic this month. See the mail archives for
> notes from CY Student and William Sit.

I'm CY Student (Cliff Yapp).  I suppose I really should quit using that
abbreviation...

Glad to see more interest in units (grin) but I'm not sure you'd find
what we've been working towards would quite meet your needs, and I'm
even less sure it will reach functionality anytime soon (I'm still
slugging it out with fundamental notions of why dimensions like Work
and Moment are really different - I want to really understand at a gut
level what's going on there and it appears to involving bending some
fairly stubborn parts of my brain into new shapes.)  The archives will
give you some idea of how we're thinking, but I should warn you that
those ideas have continued to change and my current version (of just
the ideas!) is a bit different from even the most recent discussions on
the list.  Nor is this version likely to see the light of day, since
once it's ready for attack (which will be a while for the sake of Dr.
Sit's sanity) I'll send it to him to check, he will point out a myrid
of basic flaws, which we'll try to hammer out, and so on - it actually
reminds me of my thesis a little.  I might throw my latest brainstorm
up on the wiki so it doesn't get lost if my computer dies, but it's
pure latex and pure background at this stage.  We (well Dr. Sit anyway
;-) definitely have good ideas of how to handle most parts of it, but
the more subtle aspects of the issue, as well as reviewing other unit
systems people have created, are time consuming.  Part of the problem
is we seem to be addressing some points at a level of strictness almost
never applied in the real world - this is in part a consequence of
Axiom's design philosophy and partially bull-headedness ;-).  Also,
we're trying to do this as a true literate document, with all relevant
material included, so it's not just a matter of whipping up the code
and going.  We're researching what we want the code to do at this point
(or in my case doing remedial education so I can figure out what it
should be doing) and creating the documentation for what we want to
exist as we go.  Then we'll go back and see if Axiom CAN do it and if
so how to make it work.
I'll be glad to answer any questions I can - they usually make me think
(<grin> or at least try to!).  What features specifically were you
looking for?

Actually, for what you are describing (your overall goal for your
application) you might find Axiom is major overkill (or has the wrong
focus) and you might find Yacas, Giac/Xcas, or Ginac more appropriate
to your goals.  Maxima contains my first real attempt (with a great
deal of help from the Maxima list) to build a units package, which is
intended to work something like Maple's, but it is incomplete and
somewhat unwieldy.  (A few bugs left and a lot of unit definitions to
add, and a fair number of features found in other packages not present
yet.)  You may find the functionality useful, and Barton Willis has
also created a dimensional analysis package (which isn't hooked into
the unit package - those are two separate tasks as far as Maxima is
concerned).  I believe MathSoft and Dr. Fateman are also looking at the
possibility of Maxima as a symbolic core in MathCAD, so you might
contact Dr. Fateman about what's going on with that.

\start
Date: Fri, 14 Oct 2005 10:37:09 -0400
From: Bill Page
To: Brian Kennedy
Subject: RE: Building on Axiom... funding Axiom...

On Friday, October 14, 2005 12:46 AM Tim Daly wrote:
>
> Brian Kennedy wrote:
> >
> > If you could find a commercial system that needed a CAS
> > at its core, AND was willing to fund development of a
> > free CAS rather than developing yet-another-CAS on its
> > own nickel... would the Axiom development community be
> > interested?

My answer would be an emphatic: "Yes"! To me this seems
like a win-win situation for both the developers of the
commercial system and the Axiom community as a whole. Of
course we need to be clear on licensing issues, but I do
not see this as a problem so long as the CAS itself remains
free.

> >
> > Two big drawbacks to just building on the free Axiom
> > code:
> > 1) I'm sure there will be a huge learning curve in
> >    figuring out how to  best leverage / integrate Axiom
> >    into my system (I don't think there's a nice .NET
> >    library for Axiom);

The interface with Axiom is currently mostly at a low level
and ad hoc. However some work was done recently as part of
the AxiomUI Google-funded Summer of Code project. Kai Kaminski
the developer of AxiomUI, started by writing a small
application programmer's interface in lisp. With sufficient
time and resources this could be developed into a .NET-like
service.

The MathAction webserver interface to Axiom on the other
hand interacts with Axiom at a high level mostly through
Python regular expression parsing, filters and pipes. But
performance and reliably suffer because of the hacks that
work around problems dealing with an interface that was
designed for interaction with a human.

Andrey Grozin has devoted some effort to correcting some
syntactic deficiencies in the Axiom user interface in order
to improve the interaction with TeXmacs.

And there is some interest in MathML.

> >
> > ... Via MathML cut n' paste, they'll be able to use  any of
> >  the "3M's" to do that.

It is my hope that MathML (and/or OpenMath) will lead to this
sort of flexibility but I fear that the world is still not
so simple and straight-forward.

>
> There has been some discussion of MathML and Axiom. When
> Axiom was a commercial product the interface used to work.
> The library is still there but has not been re-integrated.

I think restoring the experimental OpenMath functionality
that Axiom had as a commercial product should not be a
difficult problem. But keep in mind that this was only in
the testing stage at that time. After putting it back
together (i.e. writing the lisp bindings for the OpenMath
library), there is likely still some significant work to
do to complete the implementation.

> >
> > Would there be any interest from the Axiom developers
> > in working with a  commercial software company to develop
> > out some functionality to make Axiom usable as a core to
> > that commercial system (funded, of course)?

Yes, interest!

> > If so, would there be any capacity to do so near-term?
> > If not, when would there be capacity? what timeline
> > should I have in mind?
>

Timeline? Capacity? Near-term? These are all terms that
are largely incompatible with open source development.
On the other hand, I am confident that an open but funded
project would generate quite a lot of interest if our
recent positive experience with the Google Summer of Code
project is any guide.

> ...
> If you wanted to sponsor someone to work on MathML or any
> other well-defined task that could probably be arranged.
> We also have a fund for specific tasks managed by a
> committee (of which I'm not a member).

Yes, I think that is a good approach.

>
> >
> > More specifically, is there interest in adding the
> following to Axiom:
> > 1) Support for units (somewhat like Maple has)?

Yes.

> > 2) Support for content MathML, both in and out?

Yes.

> > 3) .NET interfaces to allow it to serve as the core
> > of a .NET app?

Could you tell us more about how you envisage this
working? Can you give some examples?

\start
Date: Fri, 14 Oct 2005 11:45:39 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [the Axiom Community] 

++added:
  - <form action="http://www.polarhome.com/cgi-bin/chat/irc.cgi">
    <input type="hidden" name="interface" value="nonjs" />
    <input type="text" name="Nickname" />
    <input type="hidden" name="Server" value="irc.freenode.net" />
    <input type="hidden" name="Channel" value="%23axiom-developer" />
    <input type="submit" name="login" value="chat" />
    </form>

\start
Date: Fri, 14 Oct 2005 11:46:42 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [the Axiom Community] 

??changed:
-    <input type="hidden" name="Channel" value="%23axiom-developer" />
    <input type="hidden" name="Channel" value="#axiom-developer" />

\start
Date: Fri, 14 Oct 2005 18:57:39 +0200
From: Martin Rubey
To: list
Subject: Again a problem, probably about dependend types...

in my effort to teach axiom expanding products in Puiseux series, I ran into a
new problem. We touched this before, it seems to me, but maybe our knowledge
has increased since then.

To make it brief, the following signature is given (I have little possibility
of changing it):

)abbrev package TEST Test
Test(R, FE, Expon, UPS, z:Symbol): Exports == Implementation where
  R     : Join(OrderedSet, GcdDomain)
  FE    : Join(FunctionSpace R, CombinatorialOpsCategory)
  Expon : OrderedAbelianMonoid
  UPS   : UnivariatePowerSeriesCategory(FE, Expon)

this is roughly the signature of FS2UPS. z is supposed to be the variable of
the series the packages is dealing with.

To expand a product

product(a(i,z),z=1..m)

into a Puiseux series, I can expand a(i,z) into a Puiseux series and apply the
product afterwards. For example, if a(i,z)=1/(i-z), we have

(45) -> s:=series(1/(i-z),=0)

         1    1      1  2      3
   (45)  - + -- z + -- z  + O(z )
         i    2      3
             i      i
                        Type: UnivariatePuiseuxSeries(Expression Integer,z,0)
(46) -> ps := prodToUPS(s,i,1,m)$Test(INT, EXPR INT, NNI, UTS(EXPR INT, z, 0), z)

   (46)
       m          m       m
     ++-++  1   ++-++  1 --+     1
      | |   - +  | |   - >      ---z
      | |   i    | |   i --+    %IF
     i= 1       i= 1    %IF= 1
   + 
                      %IF - 1
                        --+     1
                        >      ---
        m       m       --+    %IH     m       m
      ++-++  1 --+    %IH= 1         ++-++  1 --+      1   2      3
     ( | |   - >      ------------ +  | |   - >      ----)z  + O(z )
       | |   i --+         %IF        | |   i --+       2
      i= 1    %IF= 1                 i= 1    %IF= 1  %IF
                         Type: UnivariateTaylorSeries(Expression Integer,z,0)

To do so, I believe I currently extract the stream of coefficients of the
series corresponding to a(i,z) and then consider all compositions of k to
obtain the coefficient of z^k.

This works well for Taylor series, apart from the fact that it is obviously an
exponential problem: there are 2^(k-1) compositions of k, so it *really* works
only if we say something like

)set stream calculate 3

before.

However, the although the mathematics works just as well for any Puiseux
series, I don't see how to extract a stream of coefficients from a UPS in my
package. To illustrate the problem, suppose that the series is retractable to a
Taylor series, i.e., only nonnegative, integral exponents occur.

In this case I would like to retract the series to a Taylor series, but this
cannot be done without knowing the center, since the target type is unknown: I
would like say

     prodToUPS(series, var, lo, hi) ==
       if UPS has retract: UPS -> UnivariateTaylorSeries(FE, z, center(series))
       then 
         ps := retract(series)$UPS
         series prodseries(coefficients ps, var, lo, hi)
       else error "no coefficients"

but this fails. (It compiles, but then aborts with memory damage :-)

Is there any way to correct this?

\start
Date: Fri, 14 Oct 2005 10:58:20 +0200
From: Martin Rubey
To: list
Subject: Aldor and Lisp

I intend to send the following text to the lisp newsgroup today
afternoon. Comments welcome.

Dear all,

I'm one of the developers of the Axiom project, a pretty sophisticated --
meanwhile free -- Computer Algebra System. One of the distinguished features of
this system is it's extension language, which is -- in my opinion -- extremely
well designed.

However, there is a slight problem. Some years ago, this extension language --
than a commercial product -- was redesigned and in the process rewritten in
C. The new language was called Aldor.

Time passed by and Aldor became something gratis, but unfortunately, not quite
free. In particular, this means that the source cannot easily be obtained and
there is very little development on the source itself.

One important point is that at that time, Axiom (the computer algebra system)
was not free at all and available only to few people. Meanwhile, this has
changed, and it seems that there is quite a lot of interest in it. Bugs get
fixed and great contributions make the system become partly superiour to the
big players. In fact, you can try it out online:

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

Although Aldor can be used as the extension language for Axiom, some of its
most remarkable features cannot, since they lack support from Axiom.

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

So why am I posting to the Lisp community? 

The reason is, that Axiom is written in Lisp -- it currently runs on
GCL. (Porting to "other common lisps" would also be greatly appreciated...)

I believe that it would be wonderful to have an Aldor compiler and interpreter
written in Lisp.

Of course, the current compiler and interpreter for Axiom's extension language
("spad"), is written in a dialect of lisp (called "boot"), which itself is
written in lisp.

The greatest thing would be to enhance the present spad compiler and
interpreter to be compatible with Aldor. The semantics of Aldor are available
online, see Chapter 22 of 

http://www.aldor.org/docs/aldorug.pdf.gz

and do not differ greatly from the semantics of spad.

A milestone would be to enable the Axiom interpreter to use the features
provided by Aldor -- in fact, this boils down to *one* feature that is missing.
("dependent signatures")

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

If you are interested to work on this subject, please join us! There is a lot
more information available, and quite a bit of work has been done already. The
appropriate mailing list is list

\start
Date: Fri, 14 Oct 2005 15:36:45 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Aldor and Lisp

Martin,

On Friday, October 14, 2005 4:58 AM you wrote:
>
> I intend to send the following text to the lisp newsgroup
> today afternoon. Comments welcome.
>
> ...

I think this attempt to interest people who read the lisp
news group is a good idea.

I am skeptical however about the hope to extended the SPAD
compiler to include Aldor functionality. I think that one
should presume that such an approach was considered by the
original Axiom development team and rejected for good
reasons (at least what probably seemed like good reasons
at the time). SPAD was (and still is) no doubt a rather
tangled mass of code, having evolved over a long period
of time and in spite of having been completely re-written
several times. But most programs reach a point where it
is no longer economical to continue to extend and
maintain them.

Since we have both done some programming in SPAD and in
Aldor, I am sure that you will understand what I mean
when I say that I greatly prefer Aldor over SPAD, even
though the fundamental idea of the two languages are
largely the same. Because of obscure error messages and
extraneous compiler output, using SPAD has the feeling
of working with someone's unfinished experimental code.
There seem to be many cases when things I write that I
think should work, don't work even though usually I find
a way around it only to discover that I was not quite
using SPAD in the way it was intended.

Aldor on the other hand has quite clear and informative
compiler output. It's behavior seems more predictable
and as a consequence I find it is easier and faster to
get some algorithm working first in Aldor and then
back-convert it to SPAD for use in Axiom.

In my opinion, our best option is still to find a way
around the red tape that is currently making it impossible
for us to include Aldor as part of Axiom.

That said, I do think that there is a lot of work that
needs to be done on Axiom by people with serious lisp
experience. The Interpreter in particular should be
analyzed carefully and extended where possible to better
support the Aldor extensions, e.g. dependent types
should work in the Interpreter.

Work also needs to continue on the development of the
new user interface (AxiomUI). A large part of this work
will consist in completing the implementation of the
application programmer interface - new module that was
written in lisp by Kai Kaminski as part of the Summer of
Code project.

\start
Date: 14 Oct 2005 17:13:11 -0400
From: Camm Maguire
To: Martin Rubey
Subject: Re: Aldor and Lisp

Greetings, and thank you for this initiative!

Martin Rubey writes:

> I intend to send the following text to the lisp newsgroup today
> afternoon. Comments welcome.
> 
> Dear all,
> 
> I'm one of the developers of the Axiom project, a pretty sophisticated --
> meanwhile free -- Computer Algebra System. One of the distinguished features of
> this system is it's extension language, which is -- in my opinion -- extremely
> well designed.
> 
> However, there is a slight problem. Some years ago, this extension language --
> than a commercial product -- was redesigned and in the process rewritten in
> C. The new language was called Aldor.
> 
> Time passed by and Aldor became something gratis, but unfortunately, not quite
> free. In particular, this means that the source cannot easily be obtained and
> there is very little development on the source itself.
> 
> One important point is that at that time, Axiom (the computer algebra system)
> was not free at all and available only to few people. Meanwhile, this has
> changed, and it seems that there is quite a lot of interest in it. Bugs get
> fixed and great contributions make the system become partly superiour to the
> big players. In fact, you can try it out online:
> 
> http://page.axiom-developer.org/zope/mathaction/FrontPage
> 
> Although Aldor can be used as the extension language for Axiom, some of its
> most remarkable features cannot, since they lack support from Axiom.
> 

If someone can concisely specify exactly what is missing in SPAD vis a
vis Aldor, it would be most helpful.  What are these most remarkable
features?  Examples?  Alas, I lack time to plough through the 300 page
aldor manual.

Just my 2 cents here -- it really doesn't matter what tool we use, as
long as it is open source and we can get mind-share circled around its
development.  I know this first hand in working with GCL from scratch
knowing no lisp at all.  Once one decides to invest in the learning
curve, the very last thing we should do is flip flop -- expertise is
the value we supply and it takes time and is hard to come by.  Given
where the cards appear to lay right now, extending/fixing SPAD to
match Aldor appears the obvious choice.  I am assuming a lot here, but
it is primarily that the factors behind the Aldor rewrite decision
went something like 1) this code has cruft, time for a rewrite 2)
we're in the AI winter, nobody uses lisp anymore, and its slow, 2.5)
its more fun and easier to start over than try to understand and build
upon the work of others, even if it does effectively destroy the value
of everyone's time spent on the older stuff, 3) lets build something
totally new in C.  These motivations are not commensurate with those
we face in the open source world.  I'm also assuming that Aldor is
basically like spad but nicer, faster, and a little more powerful.  If
I'm missing something as is quite likely, the conclusion obviously
does not hold.

> -------------------------------------------------------------------------------
> 
> So why am I posting to the Lisp community? 
> 
> The reason is, that Axiom is written in Lisp -- it currently runs on
> GCL. (Porting to "other common lisps" would also be greatly appreciated...)
> 

Here too, it is a complete waste of time, IMHO, trying to make sure
axiom or any system runs on 11 different compilers.  Choose one,
establish the expertise needed to ensure that it will remain
servicable for the indefinite future, and then concentrate on adding
functionality to AXIOM.  

I've been having a lot of correspondence lately with theorem-prover
authors, and I've come to appreciate Tim's original idea of using one
to verify AXIOM.  Having something like this would clearly put AXIOM
at the head of the pack IMHO.

> I believe that it would be wonderful to have an Aldor compiler and interpreter
> written in Lisp.
> 
> Of course, the current compiler and interpreter for Axiom's extension language
> ("spad"), is written in a dialect of lisp (called "boot"), which itself is
> written in lisp.
> 
> The greatest thing would be to enhance the present spad compiler and
> interpreter to be compatible with Aldor. The semantics of Aldor are available

Again, specifics here would be most helpful.  I don't think anyone has
time for the document below.

> online, see Chapter 22 of 
> 
> http://www.aldor.org/docs/aldorug.pdf.gz
> 
> and do not differ greatly from the semantics of spad.
> 
> A milestone would be to enable the Axiom interpreter to use the features
> provided by Aldor -- in fact, this boils down to *one* feature that is missing.
> ("dependent signatures")

Intriguing -- more here please?  Sounds like some kind of ML like
feature, which I have been thinking about in other contexts recently. 

\start
Date: Fri, 14 Oct 2005 16:16:50 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [the Axiom Community] 

    <input type="text" name="Nickname" value="YourNickName" />

\start
Date: Fri, 14 Oct 2005 19:42:01 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire, Martin Rubey
Subject: Re: Aldor and Lisp


> Greetings, and thank you for this initiative!

Second that!
 
> If someone can concisely specify exactly what is missing in SPAD vis
> a vis Aldor, it would be most helpful.  What are these most 
> remarkable features?  Examples?  Alas, I lack time to plough through 
> the 300 page aldor manual.

Agree there, unfortunately.  As soon as we decide definitely on Aldor
either due to its finally being released or updating/modernizing our
own SPAD code to become a new Aldor implementation I'll have to go
through it, but currently I'm still trying to figure out dimensionless
dimensions and other fun.  I guess I'm kinda hoping that by the time I
finally get this well enough to try any actual coding the decision as
to which path to take will have been made and progress begun.

> Just my 2 cents here -- it really doesn't matter what tool we use, as
> long as it is open source and we can get mind-share circled around
> its development.  I know this first hand in working with GCL from 
> scratch knowing no lisp at all. Once one decides to invest in the 
> learning curve, the very last thing we should do is flip flop -- 
> expertise is the value we supply and it takes time and is hard to 
> come by.

Bingo.  Another reason I'm not really worried about coding yet - I do
NOT want to figure out SPAD only to have to redo everything again in
Aldor.  At the level of exactitude of mathematical programming, I'm not
sure there is really such thing as a minor difference in languages.  A
mathematical proof failing for a "minor" reason as opposed to a "major"
one still fails, and the same could be said for a slightly
mistranslated Axiom program.

> Given where the cards appear to lay right now, extending/fixing 
> SPAD to match Aldor appears the obvious choice.  

I know Bill is concerned about the amount of work that would take, and
I agree with him, but I agree - open source comes above any convenience
gained by using a closed source Aldor.  One Macsyma Inc. is enough - we
don't want to depend on ANY closed source technology, at any level.  

The other point is that we don't want to wait indefinitely trying to
free up Aldor as it currently stands, or we will lose momentum.

> I am assuming a lot here, but it is primarily that the factors 
> behind the Aldor rewrite decision went something like 1) this code 
> has cruft, time for a rewrite 2) we're in the AI winter, nobody uses
> lisp anymore, and its slow, 2.5) its more fun and easier to start 
> over than try to understand and build upon the work of others, even 
> if it does effectively destroy the value of everyone's time spent on 
> the older stuff, 3) lets build something totally new in C.  These 
> motivations are not commensurate with those we face in the open 
> source world.  I'm also assuming that Aldor is basically like spad 
> but nicer, faster, and a little more powerful.  If I'm missing 
> something as is quite likely, the conclusion obviously does not hold.

Heh - I would be sorry to lose the potential underlying flexibility and
power of lisp.  Axiom's mathematical power might reside in
SPAD/Aldor/Whatever but having lisp underneath it could have some real
advantages.  (Yes, I'll admit my bias - I still think the lisp gui
toolkits could be used to make an out of this world Mathematics GUI
someday.) 

> Here too, it is a complete waste of time, IMHO, trying to make sure
> axiom or any system runs on 11 different compilers.  Choose one,
> establish the expertise needed to ensure that it will remain
> servicable for the indefinite future, and then concentrate on adding
> functionality to AXIOM.  

The problem there, Camm, is that there is no way to ensure ANYTHING
will remain servicable for the indefinite future.  Where would GCL be
without you, for example?

The way I would prefer to say it (which you might agree with) is that
Axiom should target running as much as possible on ANSI Common Lisp as
defined in the standard, and GCL (which is also striving to reach the
goal of being ANSI) should remain its primary development platform. 
(At least for a while - there is one direction I would like to see
things head that I doubt GCL could support, but its so speculative it's
not worth worrying about now.) If both achieve the ANSI goal, then
other standards compliant lisps should also have no trouble with Axiom
as a bonus.  But being standards compliant is the key. 
 
> I've been having a lot of correspondence lately with theorem-prover
> authors, and I've come to appreciate Tim's original idea of using one
> to verify AXIOM.  Having something like this would clearly put AXIOM
> at the head of the pack IMHO.

I have also been looking at this a little, and I agree fully.  I think
that if (when?) we finally decide Axiom will become fully based on
Aldor, we should also at that time incorporate methods for
incorporating whatever features are necessary or desirable for
interacting with theorem provers.  Here I think, unlike the lisp issue,
that it is important to be flexible with what is possible because
provers differ from each other not only in implementation but kind.  It
needs looking at, but I also agree that this could be an honest to
goodness "killer feature" that puts Axiom on the map in a very, very
big way.  But if we're going to be rewriting over into Aldor anyway, we
should also put the full power of everything modern proof software can
bring to bear into the mix.

Actually Camm, do you know anything about proving compilers? (I know
it's a different problem from the mathematical proof question, but not
as much as one might think - after all, the correct execution of every
mathematical Aldor/SPAD statement depends on the correct functioning of
all support software.)  I don't expect us to be able to write a
provable compiler, but I would like us to design things in such a way
that they would be amenible to future proof efforts.  For example, have
each element of the Aldor language state properties it relies on, and
have the compiler (or maybe translater/parser?) that goes from Aldor ->
Lisp might someday verify properties requested are true in the lisp
structure built?  I suppose this would require an explicit statement of
a lot of stuff lisp doesn't usually make explicit though.

I've been thinking about this some - mathematicians are very reluctant
to accept the idea of computers as useful or reliable tools in matters
such as proofs, and given the behavior of modern software its a bit
hard to blame them.  I think something like the following the only way
the diehards will ever come around:

a)  Axiom and similar pieces of software are capable of constructing
proof arguments for any and all mathematical outputs.
b)  Automatic provers can verify the proof, based on already proven
libraries or verification of supplied logic (or auto-generated
arguments if that type of prover is mature enough to be useful)
c)  provers are programmed using modern provable software techniques
(the B method, Z, VMD, bitc, what have you)
d)  provers are compiled to machine code by compilers also verified
with proof techniques
e)  assembly language, machine language, and hardware designs are also
subject to proof of advertized properties.  In the case of hardware,
probability of error calculations are the root truth of the situation,
so the probability of any possible error or sequence of errors is
always nonzero, but since the same thing may be said for the human
brain and there it is impossible to quantify...

Of course, at some point in the basic design human beings have to
verify and certify proofs to avoid circularity, but I think that point
should be well defined and as close to minimum as possible.  

Some of the steps might be wrong or I might have missed some, but I
think eventually the entire software and hardware stack of a proof
system will have to be subject to formal methods and formal proofs,
insofar as that is possible.  But I am not convinced the human brain
has any fundamental advantage over a computer when it comes to
verifying proofs are correct, and I think the maximum obtainable
certainty with a proof verified by a maximally verified computer will
be greater than that obtainable from human examination, particularly as
proof complexity grows.  

Of course, I don't propose the Axiom project tackle all this - it's far
beyond the scope of the project.  However, I would like to see things
written to allow a) use of current, already useful tools and b) be
ready should the opportunity arise to fit Axiom and Aldor on top of a
proven software and hardware stack.


> > Of course, the current compiler and interpreter for Axiom's
> > extension language ("spad"), is written in a dialect of lisp 
> > (called "boot"), which itself is written in lisp.

If I may ask, how come the boot step is needed?  Do we need it in the
Aldor -> Lisp translation?  I understand the need to limit the power of
Lisp in Aldor (if I understand correctly we actually don't WANT to
express mathematics in a turing complete language because of the
undecidability of various problems in such an environment?) but surely
it is possible to write code in Lisp itself to generate logical
structures with the necessary properties without having to define a
secondary "boot" language?  (I confess here I'm thinking of the
undesirability of proving the Aldor -> boot step as well as the boot ->
Lisp step in the future.)  Tim Daly wrote a summary of the languages in
Axiom some time ago, I'll have to go dig it up and read it again.

\start
Date: Fri, 14 Oct 2005 22:28:08 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#218 New version Reduce 3.8 includes MathML] links updated after rename

a preliminary example here: [Reduce And MathML]. Work

\start
Date: Fri, 14 Oct 2005 22:28:29 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Reduce And MathML] (renamed)

This page was renamed from SandBox Reduce And MathML to Reduce And MathML.

\start
Date: Fri, 14 Oct 2005 22:30:55 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Content MathML] (renamed)

This page was renamed from SandBoxContentMathML to Content MathML.

\start
Date: Sat, 15 Oct 2005 00:04:53 -0400
From: Bill Page
To: list
Subject: Content MathML on MathAction and Reduce
Cc: Bob McElrath

I have recently installed the new version 3.8 of Reduce that
includes support for input and output of MathML. Content MathML,
as opposed to Presentation MathML retains a large part of the
mathematical semantics (but not as much as OpenMath) so it is
interesting from the point of view of exchange between different
computer algebra systems. We have plans also to resurrect the
work on OpenMath in Axiom.

Both Content MathML and OpenMath can in principle also be
rendered as 2-d mathematics but it is a bit more difficult to
process than Presentation MathML. It is Presentation MathML
that is just becoming available on new web browsers but Content
MathML is not yet directly supported on any browser (so far as
I know).

Fortunately there is a way to deal with Content MathML and
some of the rough edges in Presentation MathML using XSLT.

http://www.w3.org/Math/XSL/Overview-tech.html

XSLT style sheets for MathML

http://www.w3.org/Math/XSL/Overview.html

Putting mathematics on the Web with MathML

After a lot of head scratching and help from Bob McElrath I
managed to modify the MathAction wiki to support the XML
compatible combination of XHTML and MathML and also to
implement XSLT style sheets. So now (with a suitably
configured browser) this allows us to generate content
MathML output from Reduce and display in as part of a web
page in the browser.

One of the difficult parts of these modifications was to
find a way to ensure that the MathAction website would send
only valid XHTML to the browser in spite of the fact that
users are free to edit the wiki pages and their edits may
not always produce properly formatted XHTML. When MathML
is also used with XHTML conformance to the XML standard is
even more important. And it is also necessary to properly
identify the content type to the browser so the browser
will do the necessary post processing.

The approach that I finally settle on was to incorporate
the 'mxTidy' (Python binding htmlTidy) HTML filter  as the
last step of rendering a page, just before delivering it
to the user. http://www.egenix.com/files/python/mxTidy.html

mxTidy is able to intelligently correct most poorly formed
HTML and XHTML code. It also will generate warnings and error
messages that will be attached as comments to the web page.
These can be used by the page designer to correct formatting
problems.

So far I have been able to test that this works for both
FireFox 1.0.7 and in Explorer 6 with the TechExplorer
add-on. I would be interested to receive reports from
other people about success of failure with their favorite
browser.

Please feel free to experiment with the following example
pages:

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

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

Your comments and questions on this work would be most
appreciated.

\start
Date: Sat, 15 Oct 2005 11:10:01 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Aldor and Lisp
Cc: Camm Maguire

Dear Camm, Cliff, *,

thank you for responding. It seems that my post went ignored on comp.lang.lisp
-- except by you, folks :-) -- so maybe I have to "augment" my
strategy. Details follow below, along with explanations. Sorry, it's a long
post.

First things first: the ultimate goal of this and other posts is to attract
or keep alive interest in axiom. I think that it is a shame that axiom makes so
little noise. I guess that most people just don't know it.

I.) Of course, one possibility is to regularly scan the questions on
sci.math.symbolic and see how we answer them with axiom. Unfortunately, many
things people want cannot really done with axiom: This concerns, for example,

* optimization
* summation
* solving inequalities

Aha! The latter point is *nearly* solved now, since Renaud made his CAD
algorithm available. I did not have time to show how to use it to solve
inequalities, but I know that it should be easy now. I'll do so as soon as
possible.

II.) Apart from this, I'm constantly looking for "side areas", where Axiom
could attract interest. One of these was the AxiomUI effort with
summerofcode. This was WONDERFUL. Well, AxiomUI is not finished, and it is not
certain when it will be, but *at least* one person, namely Kai Kaminski now
knows a fair bit about Axiom. I hope he will recommend it, or at least use it
himself if in need.

Of course "side area" is *not* a pejorative term here. But you don't need to
know any mathematics to play in it. It happens that Kai is a mathematician, but
this was not necessary.

I see two more side areas: porting Axiom to other Lisps and the Aldor - Lisp
issue.

IMPORTANT: I don't intend to convince anybody working on Axiom anyway that he
should port Axiom to Ansi Common Lisp. I want to convince people who are *not*
working on Axiom to start working on Axiom.

So, maybe Camm (since you are known on comp.lang.lisp), you could post a reply
saying something like

"Uh yes, a port of Axiom to ANSI Common Lisp would be nice. It wouldn't be too
much work anyway, as far as I know Axiom. By the way, it's really a nice
system..."

:-)

I'm not a marketing guru, but I think we are allowed to use dirty tricks.

III.) The Aldor issue is *much* more complicated than anything else. That's for
certain. So here follows a short description of what is missing.

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

The difference between Aldor and Spad is *not that* big. Aldor adds

* a new, but alternative(!) syntax. I.e., the Aldor compiler understands two
  different syntaxes, one of which is the syntax used by Spad. No work on this
  side.

* it adds the "extend" keyword. This allows you to add code to already existing
  domains and categories. For example, you have a domain
  "UnivariateTaylorSeries", short "UTS". It works and you don't want to touch
  that code. However, you really would like to allow sums and products of
  Taylor series, since the can be computed explicitely, as in

  sum((a0(i)+a1(i)*q+a2(i)*q^2+...),i=1..m) =
  sum(a0(i),i=1..m)+sum(a1(i),i=1..m)*q+sum(a2(i),i=1..m)*q^2+...

  (Products are more complicated)

  Currently, we would have to modify the code in UTS. With the "extend"
  keyword, we could say (I don't have the syntax handy)

  extend domain UTS(Coeff, var, cen) = sum: (%, SegmentBinding Coeff) -> %

* Aldor adds "really" dependent types, as in

  Test: with {f:(n:Integer)->IntegerMod(n) } 
    == add {f(n:Integer):IntegerMod(n) == coerce(10)$IntegerMod(n) }
  
  Note that the signature of f depends on its argument. This is currently
  impossible in Spad, leading to ugly constructs for example in
  ExpressionToUnivariatePowerSeries(R,FE) world: All signatures there go to
  type Any, since we would need a signature like

    iTaylor: (fcn:FE,x:SY,a:FE) -> UTS(FE,x,a).


There are some other small differences, I don't know by heart.

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

Fortunately, only one of these differences cannot be used by Axiom: dependent
types. An example for that failure can be found on MathAction, I'll make it an
Issue today.

Even there, it seems that Axiom does all the computations correct, it seems to
fail rather towards the end, maybe only when it comes to *displaying* the
type of the result. Not sure here.

So, the first step would be to make the Axiom interpreter understand all code
produced by Aldor, i.e., Axiom (the interpreter) should learn to deal with
dependend types.

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

Here follow some random answers:

Dear Camm,

Camm writes:

> Just my 2 cents here -- it really doesn't matter what tool we use, as
> long as it is open source and we can get mind-share circled around its
> development.  I know this first hand in working with GCL from scratch
> knowing no lisp at all.  Once one decides to invest in the learning
> curve, the very last thing we should do is flip flop -- expertise is
> knowing no lisp at all.  Once one decides to invest in the learning
> curve, the very last thing we should do is flip flop -- expertise is
> the value we supply and it takes time and is hard to come by.  Given
> where the cards appear to lay right now, extending/fixing SPAD to
> match Aldor appears the obvious choice.  I am assuming a lot here, but
> it is primarily that the factors behind the Aldor rewrite decision
> went something like 1) this code has cruft, time for a rewrite 2)
> we're in the AI winter, nobody uses lisp anymore, and its slow, 2.5)
> its more fun and easier to start over than try to understand and build
> upon the work of others, even if it does effectively destroy the value
> of everyone's time spent on the older stuff, 3) lets build something
> totally new in C.  These motivations are not commensurate with those
> we face in the open source world.  I'm also assuming that Aldor is
> basically like spad but nicer, faster, and a little more powerful. 

I think you are absolutely correct here. At least, I hope so...


> > (Porting to "other common lisps" would also be greatly appreciated...)
> 
> Here too, it is a complete waste of time, IMHO, trying to make sure axiom or
> any system runs on 11 different compilers.

As I detailed above, I think it depends on *who* is doing the port. If some
lisp guru who is not (yet) interested at all in Mathematics does it: great! If
you would be doing it: Camm, STOP it! :-)

> I've been having a lot of correspondence lately with theorem-prover
> authors, and I've come to appreciate Tim's original idea of using one
> to verify AXIOM.  Having something like this would clearly put AXIOM
> at the head of the pack IMHO.

This would be very nice, but I doubt that a theorem prover could be used to
verify Axiom. And, I think that it would be a waste of time. There are
thousends of hidden assumptions in Axioms code. Maybe in Maxima there are
millions, but still. A correctness prover would simply tell you: incorrect. :-)

I rather think that Axiom should provide the functionality of a Theorem prover,
as for example, "Theorema" from Bruno Buchberger / RISC Linz does for
Mathematica.

PS: Could you PLEASE post your (preliminary) patch to the new()$Symbol bug to
IssueTracker or to this list -- then I'll put it on IssueTracker! I ran into
this bug again...

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

Dear Cliff,

> [...] but currently I'm still trying to figure out dimensionless dimensions
> and other fun.  I guess I'm kinda hoping that by the time I finally get this
> well enough to try any actual coding the decision as to which path to take
> will have been made and progress begun.

You can safely code in either Spad or Aldor. There is even an automated
translater from Spad to Aldor, so this route is completely "safe". If you
decide to code in Aldor, backporting to Spad is mostly trivial --if you don't
use dependent types, that is.

PLEASE stick to your project! It is important to us, as you can see from that
commercial guy.

> A mathematical proof failing for a "minor" reason as opposed to a "major" one
> still fails,

As a mathematician: a "minor" mistake is one that can be fixed (by myself), a
"major" one is one that I don't know how to fix...


[big snip]

> mathematicians are very reluctant to accept the idea of computers as useful
> or reliable tools in matters such as proofs, and given the behavior of modern
> software its a bit hard to blame them.

Don't worry. Most Mathematicians I know accept Computer proofs meanwhile. The
point rather is that we would like to *understand* the proofs. And a paper and
pencil proof is usually easier to understand than two thousend lines of
computer generated calculations.

I made an experience I'd like to share: In the course of proving something, I
needed to prove that a certain polynomial inequality holds. I only knew that my
polynomial would have positive coefficients, to put you into the picture. I
failed. However, I was able to prove it for polynomials of degree 3.

For polynomials of degree 4, Mathematicas InequalitySolve proved
it. Unfortunately, I don't know how, since it only answered "True". Of course,
it did use a CAD, but it was impossible for me to see what it really did. I
hope that we can modify Renauds package so that
 
> a) Axiom and similar pieces of software are capable of constructing proof
> arguments for any and all mathematical outputs.

Again, I'm pretty sure that trying to prove the correctness of Axiom itself is
the wrong path. If you are *really* interested and have the talent, go
ahead. But if you think that anybody would use Axiom because it was proven
correct, I'm sure that you are mistaken.
 
> > > Of course, the current compiler and interpreter for Axiom's extension
> > > language ("spad"), is written in a dialect of lisp (called "boot"), which
> > > itself is written in lisp.
 
> If I may ask, how come the boot step is needed?  

As far as I know, it's a historical failure. Some people working on Axiom
didn't like Lisps parens and prefix notation...

> Do we need it in the Aldor -> Lisp translation?  I understand the need to
> limit the power of Lisp in Aldor

No, Aldor is just as powerful as Lisp in the Turing sense. From the programmers
perspective, it is not as powerful since it doesn't have macros. By the way,
Lisp was originally designed as a means to prove things about computer
language. It was at first not intended to be actually used for programming. So,
I'd say that proving things about Aldor programs will be much harder than
proving things about Lisp programs :-(

All the best and keep your Units project alive!

\start
Date: Sat, 15 Oct 2005 06:01:10 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [AldorForAxiom] 


??changed:
-  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.
-[65 more lines...]
see Issue #219

\start
Date: Sat, 15 Oct 2005 06:03:20 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#219 The interpreter does not understand dependend types] 


??changed:
-
The following Aldor construct does not yet work in Axiom.

This 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::

  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

- aldor "extend" does not work

- The algebra defined in libaxiom.al is not current, and for it to be rebuilt
  various .as files need to be available to the build process (axextend.as and
  friends)

- exported attributes from aldor domains are explicitly killed off by this
  patch (it's probably easy to fix, just no time at the moment).  

- Only tested the most trivial domains he could find.

\start
Date: Sat, 15 Oct 2005 06:04:09 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#219 The interpreter does not understand dependend types] property change

Severity: normal => wishlist 

\start
Date: Sat, 15 Oct 2005 13:13:03 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: IssueTracker Failure

Martin,

My new email address is:

  Bill Page

On October 15, 2005 7:06 AM you wrote:
> 
> I'm afraid I killed IssueTracker by adding an Issue witout
> any text...
> 
> If you look at the source of 
> 
> http://page.axiom-developer.org/zope/mathaction/IssueTracker
> 
> you find that tidyhtml complains about errors that must be
> fixed.
> 

This was caused by something I did, not you. After implementing
the 'HTMLtidy' program, I only checked a small sample of pages
and completely forgot IssueTracker. It turns out that there was
in fact a serious HTML error hidden in that page. There really
a <table> tag without a closing > . It is all fixed now.

Please let me know if you find anything also strange on the
axiom-developer website that might be a consequence of these
changes.

\start
Date: Sat, 15 Oct 2005 13:56:09 -0400
From: Bill Page
To: Eitan Gurari, Martin Rubey
Subject: RE: tex4ht and jsmath
Cc: Kai Kaminski, Davide P.Cervone, Bob McElrath

On October 15, 2005 11:14 AM Eitan Gurari wrote:
> 
> I just reviewed the jsmath site and was very impressed of what
> it offers.  
> 
> I think it would be an interesting exercise requiring a few days
> of work to add to tex4ht a jsmath output format.  It looks like
> all that will be required is just a variant of the mathml.4ht file
> tailored for jsmath. I'll be glad to work on it but I'll probably
> not be able to do so before the winter break.
> 

Excellent! I think tex4ht with jsmath rendering of equations
would be a great combination. We could use this right away for
'pamphlet' files (noweb format with LaTeX and Axiom program
source code) on the Axiom wiki http://wiki.axiom-developer.org

If I were to attempt to change the mathml.4ht config file
myself can you suggest some documentation/tutorial to get me
started quickly?

\start
Date: Sat, 15 Oct 2005 11:56:41 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey
Subject: Re: Aldor and Lisp

--- Martin Rubey wrote:
>
> Dear Cliff,
>
> > [...] but currently I'm still trying to figure out dimensionless 
> > dimensions and other fun.  I guess I'm kinda hoping that by the 
> > time I finally get this well enough to try any actual coding the 
> > decision as to which path to take will have been made and progress
> > begun.

> You can safely code in either Spad or Aldor. There is even an 
> automated translater from Spad to Aldor, so this route is 
> completely "safe". If you decide to code in Aldor, backporting to 
> Spad is mostly trivial --if you don't use dependent types, that is.

Heh - don't know what we will need yet for sure - I'd be a bit
surprised if it comes to that.  I'm still a ways away from coding -
along with straightening out my own ideas, I've got to review the
papers and whatnot associated with a number of other systems still. 
It's really too bad I won't be able to pass this off as a thesis
somewhere :-/.

> PLEASE stick to your project! It is important to us, as you can see 
> from that commercial guy.

I think I'm now in "stubborn" mode, which is a good sign - also I'm
resolving one of the most basic things that bothered me about units and
dimensions in undergrad physics.  I always had the sense that behind
the seeming simplicity of units and dimensions lurked a monster - and
until I came to grips with it I would never really understand units or
dimensions.  So I guess in some sense this is my bid for true
understanding...

> > A mathematical proof failing for a "minor" reason as opposed to a 
> > "major" one still fails,

> As a mathematician: a "minor" mistake is one that can be fixed (by 
> myself), a "major" one is one that I don't know how to fix...

Ah :-).  True, but until even an "easy" mistake is corrected the proof
is still wrong...

[big snip]

> > mathematicians are very reluctant to accept the idea of computers 
> > as useful or reliable tools in matters such as proofs, and given 
> > the behavior of modern software its a bit hard to blame them.

> Don't worry. Most Mathematicians I know accept Computer proofs 
> meanwhile. The point rather is that we would like to *understand* 
> the proofs. And a paper and pencil proof is usually easier to 
> understand than two thousend lines of computer generated 
> calculations.

Hmm.  I'm betting human understandable proofs are probably possible
only for a small subset of what is provable.  So there are really two
distinct goals here - verify that something is true and understanding
the verification of why something is true.  I guess to me the first is
of more interest, but I see the merit of the second for creating new
proofs.

> I made an experience I'd like to share: In the course of proving 
> something, I needed to prove that a certain polynomial inequality 
> holds. I only knew that my polynomial would have positive 
> coefficients, to put you into the picture. I failed. However, I 
> was able to prove it for polynomials of degree 3.

OK.

> For polynomials of degree 4, Mathematicas InequalitySolve proved
> it. Unfortunately, I don't know how, since it only answered "True".
> Of course, it did use a CAD, but it was impossible for me to see 
> what it really did.

I am not sure I would agree right off that it proved it, particularly
since you couldn't generate a list of arguments on which that proof was
founded.  All proofs have to trust SOMETHING, even if only the human
brain, and it should be clear what we are trusting.  In this case it
involves trusting Mathematica's internal algorithms and design are
fully "correct."

> I hope that we can modify Renauds package

I agree - transparency should be a design goal.
 
> > a) Axiom and similar pieces of software are capable of 
> > constructing proof arguments for any and all mathematical outputs.

> Again, I'm pretty sure that trying to prove the correctness of 
> Axiom itself is the wrong path. If you are *really* interested and
> have the talent, go ahead. But if you think that anybody would use 
> Axiom because it was proven correct, I'm sure that you are mistaken.

I suppose, but I view it as a way of increasing confidence in the
software.  If you want to think of it one way, the whole notion of
doing symbolic mathematics via computer involves bridging the gap
between fundamentally continuous processes (e.g. integration) and
fundamentally numerical, digital ones (the machine level workings of a
digital computer).  I think that process can stand some verification -
it's a hard job and each parts correctness is theoretically limited by
the correctness of what it relies on.

I'm hoping the day will come when to be taken seriously a program HAS
to present as much verification as can be performed.  

> > If I may ask, how come the boot step is needed?  

> As far as I know, it's a historical failure. Some people working on
> Axiom didn't like Lisps parens and prefix notation...

Arrgh.  Thank you, Fortran and friends.

> > Do we need it in the Aldor -> Lisp translation?  I understand the
> > need to limit the power of Lisp in Aldor
>
> No, Aldor is just as powerful as Lisp in the Turing sense. 

Hmm. OK.

> From the programmers perspective, it is not as powerful since it 
> doesn't have macros. By the way, Lisp was originally designed as a
> means to prove things about computer language. It was at first not
> intended to be actually used for programming. So, I'd say that 
> proving things about Aldor programs will be much harder than
> proving things about Lisp programs :-(

Sigh.  Figures.  Well, both will have to be done anyway someday if I
really make a go at verified results, but I have a lot to learn about
proof logic first.

> All the best and keep your Units project alive!

Oh, it lives :-).  I'm just trying to do my homework this time around! 
I'm hoping after this and Error Analysis a lot of really solid
scientific logic can be built on top of these Domains.  Error Analysis
is going to get me into REAL trouble, and probably annoy the heck out
of everybody (for example, the need to establish a way to handle and
quantify the uncertainty associated with any numerical calculation in
Axiom).

\start
Date: Sat, 15 Oct 2005 21:27:46 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Units

Dear Cliff,

I'm very much surprised that there is anything sophisticated behind units, but
you probably were, too. In fact, I'd love to see an example.

C Y writes:

 > Hmm.  I'm betting human understandable proofs are probably possible only for
 > a small subset of what is provable.

You are quite in line with Doron Zeilberger here.

 > If you want to think of it one way, the whole notion of doing symbolic
 > mathematics via computer involves bridging the gap between fundamentally
 > continuous processes (e.g. integration) and fundamentally numerical, digital
 > ones (the machine level workings of a digital computer).

I fail to see anything continous behind the process of integration. Well, we
call the objects continous, but still, these are discrete objects. We are never
ever treating a continous family of objects. 

\start
Date: Sun, 16 Oct 2005 04:30:11 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#220 'StepThrough' is braindead] (nouveau) 

The 'StepThrough' category provides a function 'init()' which yields
an initial element of the domain and a function 'nextItem(n)' which
produces the element after 'n', or '"failed"' if there is no such
element.

This sounds quite like an implementation of countable sets. But
unfortunately, it isn't. The documentation says, that it is not
required that all elements of the domain are eventually produced.

This given, *any* domain could belong to 'STEP'. Inspecting the
domains in Axiom we find however, that (nearly) exactly those domains
that contain a countable number of elements have 'STEP', while, for
example 'EXPR' and 'Float' don't.

I would argue that this should be changed and I will provide an
implementation shortly. There is little danger of breaking anything,
since 'STEP' is only used at two different places, namely in 'GENPGCD'
and in 'PFBRU'.

\start
Date: Sun, 16 Oct 2005 04:37:19 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#221 'PI' does not have 'OASGP'] (nouveau) 

Strange enough, the current definitions of 'OrderedAbelianSemiGroup'
and 'OrderedAbelianMonoid' coincide::

  )abbrev category OASGP OrderedAbelianSemiGroup
  ++ Ordered sets which are also abelian semigroups, such that the addition
  ++ preserves the ordering.
  ++   \spad{ x < y => x+z < y+z}

  OrderedAbelianSemiGroup(): Category == Join(OrderedSet, AbelianMonoid)

  )abbrev category OAMON OrderedAbelianMonoid
  ++ Ordered sets which are also abelian monoids, such that the addition
  ++ preserves the ordering.

  OrderedAbelianMonoid(): Category ==
          Join(OrderedAbelianSemiGroup, AbelianMonoid)

The definition of 'OASGP' should read::

    OrderedAbelianSemiGroup(): Category == Join(OrderedSet, AbelianSemiGroup)

\start
Date: Sun, 16 Oct 2005 18:10:01 +0200
From: Gregory Vanuxem
To: list
Subject: proxy error at	http://wiki.axiom-developer.org/FrontPage

In an attempt to join http://wiki.axiom-developer.org/FrontPage
I received

Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /FrontPage.

Reason: Error reading from remote server

Additionally, a 502 Bad Gateway error was encountered while trying to use an
ErrorDocument to handle the request.


\start
Date: Sun, 16 Oct 2005 16:58:20 -0400
From: Bill Page
To: Gregory Vanuxem, Martin Rubey
Subject: RE: proxy error

Martin, Gr=E9gory;

I am not sure exactly what happened. I also could not access the
wiki on axiom-developer early today. It seems that the Zope server
was in a bad state. So I just now re-booted Zope and things seem
to be back to normal.

I am sorry for the inconvenience. Please let me know if any have
any more problems.

About the usage statistics at

http://page.axiom-developer.org/usage/usage_200510.html

It seems that there were a very large number of downloads of
the Fedora Core 4 binaries 'axiom-Sept2005-FC4-bin.tgz': 466
downloads so far this month and only 56 in the previous month.
My guess is that a lot of these must have occurred on Oct 14.
If you look at the tables 'Total Sites' and 'Total Sites By
Kbytes' you can see which sites did the most downloading.

I hope what this means that we now have 466 new users of Axiom
on linux. But if you think that there might be a problem, I can
look at the detailed logs but my policy so far has been to only
do this in the cases of obvious abuse.

Regards,
Bill Page.

> -----Original Message-----
> From: Martin Rubey [mailto:Martin Rubey]
> Sent: October 16, 2005 3:02 AM
> To: bill page
> Subject: Wiki not accessible
>
>
> Dear Bill,
>
> the wiki seems to be unaccessible since yesterday evening. The host
> page.axiom-developer.org seems to be working,
> wiki.axiom-developer.org does
> not...
>
> BTW, I had a look at the usage statistics. Do you know what
> happened on Oktober 14? 43% of all downloads happened on this
> day...
>
> Martin
>
>

> -----Original Message-----
> From:
> axiom-developer-bounces+bill.page1=synthesis.anikast.ca@nongnu
> .org
> a@nongnu.org] On Behalf Of Vanuxem Gr=E9gory
> Sent: October 16, 2005 12:10 PM
> To: Axiom-Developer
> Subject: proxy error
> athttp://wiki.axiom-developer.org/FrontPage
>
>
> Hi,
>
> In an attempt to join http://wiki.axiom-developer.org/FrontPage
> I received
>
> Proxy Error
> The proxy server received an invalid response from an upstream server.
> The proxy server could not handle the request GET /FrontPage.
>
> Reason: Error reading from remote server
>
> Additionally, a 502 Bad Gateway error was encountered while
> trying to use an ErrorDocument to handle the request.

\start
Date: Mon, 17 Oct 2005 08:48:56 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: proxy error

 > It seems that there were a very large number of downloads of
 > the Fedora Core 4 binaries 'axiom-Sept2005-FC4-bin.tgz': 466
 > downloads so far this month and only 56 in the previous month.
 > My guess is that a lot of these must have occurred on Oct 14.
 > If you look at the tables 'Total Sites' and 'Total Sites By
 > Kbytes' you can see which sites did the most downloading.
 > 
 > I hope what this means that we now have 466 new users of Axiom
 > on linux. 

They are all from one single site from russia. Some institute of applied
mathematics, but the particular adress (namely h140.keldysh.ru) seems to be
well known in downloading many megabytes... (just google)

\start
Date: Mon, 17 Oct 2005 09:57:59 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: MathAction again unaccessible...

I have the server running again, now in a mode that lets me
monitor more closely what's happening. I suspect, but I don't
know for sure, that the problem my be caused by the htmlTidy
program that I added to the server last week. This program
takes significantly more memory and cpu resources to ensure
that all HTML code output by the server conforms to the XHTML
standard by making corrections "on-the-fly", i.e. just before
delivering each page. Correct XHTML coding is required to
support MathML.

There are other ways of ensuring the correctness of the coding
of the pages, that does not take as many resources but they
would take longer to implement. If I can determine that htmlTidy
is causing the problem, then I can at least restrict it's use
to only those pages that actually use MathML.

What do you find "strange" about the usage statistics?

> -----Original Message-----
> There seems to be something severely wrong.
> 
> And the usage statistics are strange, too.

\start
Date: Mon, 17 Oct 2005 16:44:06 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: MathAction again unaccessible...

Bill Page writes:
 > Martin,
 > 
 > I have the server running again, now in a mode that lets me
 > monitor more closely what's happening. 

Thank you!

I saw, you looked already at tex4ht + jsMath. This would be a wonderful
combination, it seems to me. If you want, I put a post on comp.text.tex, maybe
somebody has the time to do it quickly?

 > What do you find "strange" about the usage statistics?

Well, the peaks Oct 14 (downloads) and 15 (pages) were somewhat
surprising. 34801293 kBytes on one day do seem a bit much. That's 33
GigaByte... Maybe they had problems with the download. 

Pages seem to be due to ul.warwick.net. Seems to be a soccer club.

But since you have a good explanation of the crashes, I'm not worried
anymore. (I only find it strange)

\start
Date: Mon, 17 Oct 2005 16:43:43 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: MathAction again unaccessible...

Bill Page writes:
 > Martin,
 > 
 > I have the server running again, now in a mode that lets me
 > monitor more closely what's happening. 

Thank you!

I saw, you looked already at tex4ht + jsMath. This would be a wonderful
combination, it seems to me. If you want, I put a post on comp.text.tex, maybe
somebody has the time to do it quickly?

 > What do you find "strange" about the usage statistics?

Well, the peaks Oct 14 (downloads) and 15 (pages) were somewhat
surprising. 34801293 kBytes on one day do seem a bit much. That's 33
GigaByte... Maybe they had problems with the download. 

Pages seem to be due to ul.warwick.net. Seems to be a soccer club.

But since you have a good explanation of the crashes, I'm not worried
anymore. (I only find it strange)

\start
Date: Mon, 17 Oct 2005 12:47:30 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: MathAction again unaccessible...

Martin,

On October 17, 2005 10:44 AM you wrote:
> 
> Bill Page writes:
>  > Martin,
>  > 
>  > I have the server running again, now in a mode that lets me
>  > monitor more closely what's happening. 
> 
> Thank you!
>

I have confirmed that unfortunately it was the use of htmlTidy
that was causing the problem. :( Apparently a small memory leak
that eventually crashes Zope after htmlTidy has been called many
times. So I disabled htmlTidy for general pages on MathAction and
only call it for pages containing MathML since I still can't
avoid the use of htmlTidy in that case. I don't think this should
cause any more problems, but I will continue to look for other
solutions.
 
> I saw, you looked already at tex4ht + jsMath. This would be
> a wonderful combination, it seems to me.

I agree.

> If you want, I put a post on comp.text.tex, maybe somebody has
> the time to do it quickly?

Yes, I think you should do this - if for no other reason than
to continue your philosophy of exposing Axiom to a wider audience
as you explained in a earlier email. And if we are lucky, you
are right that we just might find someone to do it quickly. :)

> 
>  > What do you find "strange" about the usage statistics?
> 
> Well, the peaks Oct 14 (downloads) and 15 (pages) were somewhat
> surprising. 34801293 kBytes on one day do seem a bit much. That's
> 33 GigaByte... Maybe they had problems with the download.

If this occurs again, I will send an email to the network admin at
the Keldysh Institute and ask if they can trace the access. If
someone is having problems downloading Axiom, I would like to be
able to help.

> 
> Pages seem to be due to ul.warwick.net. Seems to be a soccer club.

??? My preliminary investigations suggests instead that this url
belongs to an ISP in the New Jersey area of U.S.A.

http://www.warwick.net/

(probably a gateway or firewall address). The large number access
could be from one or more of their subscribers.

> 
> But since you have a good explanation of the crashes, I'm not
> worried anymore. (I only find it strange)
> 

I agree that these are probably legitimate access to our web
site, provided of course that this doesn't happen too frequently.
The Internet is a wild place these days and you never know what
someone "out there" might do. This type of access for example
might represent someone running a spider to take a snapshot of
the entire website. I think we have to be tolerant, so long as
such use doesn't seriously impact other users.

Actually, I am hoping that some of this new activity on
MathAction might be due to your recent post to comp.lang.lisp.
In spite of the two odd cases you mention, this might still be
the case since people often seem shy about posting to a newsgroup
or sending an email but they will click on a web link and take
a good look around web site with much less hesitation.

\start
Date: Mon, 17 Oct 2005 13:34:35 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#102 solve(sinh(z)=cosh(z),z) ] Why is "append" written with quotation marks?

Martin, can you explain to me what this function call in the original code
is supposed to do::

"append"/[solve1Sys(plist, lvar) for plist in trianglist]

\start
Date: Mon, 17 Oct 2005 19:52:37 +0100
From: Peter Broadbery
To: Martin Rubey
Subject: Re: Aldor and Lisp

On Sat, 2005-10-15 at 11:10 +0200, Martin Rubey wrote:
> Dear Camm, Cliff, *,
> 

If there's a rewrite of Spad using a little more of aldor, then I'd also
be interested in helping occasionaly (unless a really freely available
Aldor comes along). 

> There are some other small differences, I don't know by heart.
> 
> -------------------------------------------------------------------------------
> 

I guess you've missed generators, exceptions (implemented late, and IMHO
badly), and a very strong code optimisation phase.  

Ideally, I'd like to see an Axiom extension language written mostly in
that language or a strictly defined subset (in a similar way to boot and
spad, but without the syntax differences). That's just my preference,
the only advantage being that it may lead to more  testing of the
compiler.

Anyway, just thought I'd offer some support.  Anyone know of a lisp
parser generator?

\start
Date: Mon, 17 Oct 2005 20:48:27 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Reduce And MathML] MathML support on linux

Bob McElrath has some very useful notes on how to install
MathML on linux here:

http://mcelrath.org/Notes/MathML

Beware that the information at:

http://www.mozilla.org/projects/mathml/fonts/

is confusing, confused, and somewhat out of date.

\start
Date: Tue, 18 Oct 2005 03:53:32 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#102 solve(sinh(z)=cosh(z), z) ] 

What it does is easily explained: '"foo"/l' maps the function 'foo'
over the list 'l'. However, it appears that it doesn't use reduce but
rather some lisp primitive. It is hard to trace, since it doesn't work
in the interpreter. I suppose that it is some leftover of the elder
days of 'spad'. In any case, when you 'grep' the 'algebra' directory,
there doesn't appear to be a three argument form of this construct, so
I propose to (gradually) replace it by 'reduce' everywhere.

\start
Date: Tue, 18 Oct 2005 03:47:41 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#102 solve(sinh(z)=cosh(z), z) ] 

  "append"/[solve1Sys(plist, lvar) for plist in trianglist]

\start
Date: Tue, 18 Oct 2005 06:09:11 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#69 sqrt(-1/abs(x))-1/sqrt(-abs(x))] 

Just for the archive, here is the patch::

  --- /home/rubey/axiom/mnt/linux/src/algebra/algfunc.spad	2004-05-21 18:51:30.000000000 +0200
  +++ algfunc.spad	2004-05-25 13:39:19.000000000 +0200
  @@ -431,9 +431,20 @@
         hackroot(x, n) ==
   --        one? n or one? x => x
           (n = 1) or (x = 1) => x
  +
  +--  the following is FALSE! if x can be negative. Example: x=-1/2 would pass the
  +--  test and give 1/(-2)^(1/n) ~= (-1/2)^(1/n)
   --        (x ^= -1) and (one?(num := numer x) or (num = -1)) =>
  -        (x ^= -1) and (((num := numer x) = 1) or (num = -1)) =>
  -           inv hackroot((num * denom x)::F, n)
  +--        (x ^= -1) and (((num := numer x) = 1) or (num = -1)) =>
  +--           inv hackroot((num * denom x)::F, n)
  +
  +--  permissible when denom x is a positive number
  +
  +        (((dx := denom x) ^= 1) and
  +	 ((rx := retractIfCan(dx)@Union(Integer,"failed")) case Integer) and
  +	 positive?(rx))
  +         => hackroot((numer x)::F, n)/hackroot(rx::Integer::F, n)
  +
           (x = -1) and n = 4 =>
             ((-1::F) ** (1::Q / 2::Q) + 1) / ((2::F) ** (1::Q / 2::Q))
           kernel(oproot, [x, n::F])
\start
Date: 18 Oct 2005 10:40:15 -0400
From: Camm Maguire
To: Peter Broadbery
Subject: Re: Aldor and Lisp

Peter Broadbery writes:

> On Sat, 2005-10-15 at 11:10 +0200, Martin Rubey wrote:
> > Dear Camm, Cliff, *,
> > 
> 
> If there's a rewrite of Spad using a little more of aldor, then I'd also
> be interested in helping occasionaly (unless a really freely available
> Aldor comes along). 
> 
> > There are some other small differences, I don't know by heart.
> > 
> > -------------------------------------------------------------------------------
> > 
> 
> I guess you've missed generators, exceptions (implemented late, and IMHO
> badly), and a very strong code optimisation phase.  
> 

Thank you so much for this.  If you have time, it would be msot
helpful to give a brief example showing how each of these enhancements
works. 

> Ideally, I'd like to see an Axiom extension language written mostly in
> that language or a strictly defined subset (in a similar way to boot and
> spad, but without the syntax differences). That's just my preference,
> the only advantage being that it may lead to more  testing of the
> compiler.
> 

Nice idea.

> Anyway, just thought I'd offer some support.  Anyone know of a lisp
> parser generator?
> 

Heard good things about Zebu, but no direct experience.  Had an idea
once about a GCL lisp interface to flex and bison, but it is not clear
how much use this would ever see.

\start
Date: Tue, 18 Oct 2005 08:29:53 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire, Peter Broadbery
Subject: Re: Aldor and Lisp

> > Anyway, just thought I'd offer some support.  Anyone know of a lisp
> > parser generator?
> 
> Heard good things about Zebu, but no direct experience.  

That's this one?  http://www.cliki.net/Zebu  Does it work with GCL? 
There might be some confusion with license issues, judging by the Cliki
discussion, but it sounds like a simple question of contacting the
right people and verifying that we can use the output of Zebu in a
non-GPL context.  Perhaps it would be worth following up on - it seems
to have a rather impressive feature list.  Any other opinions on this?

\start
Date: Tue, 18 Oct 2005 08:39:22 -0700 (PDT)
From: Cliff Yapp
To: Camm Maguire
Subject: Re: Aldor and Lisp
Cc: Ralf Hemmecke, Peter Broadbery

> Greetings!
> 
> Martin Rubey writes:
> 
> > So I'd *rather* go the other way: replace Boot by Lisp. The Lisp
> > Community is rapidly growing, and it would be a shame not to be 
> > able to connect with them. I am absolutely convinced that Lisp is
> > the ideal language for writing compilers for others. Of course, I 
> > realize that my post on comp.lang.lisp has gone
> > unanswered so far, but I don't give up hope.
> 
> Indeed, the internal trees of gcc et.al. resemble lisp quite closely.
> But do we have to write a new compiler, or just modify SPAD?  I have
> some experience with the GCL compiler, which is written in lisp, so
> may be able to help.  But it seems a lot of work compared to building
> on what already exists.

A possibly related question, or rather consideration:  Given the effort
to make Axiom an exercise in literate programming, would we want to
document in a literate fashion the design and implementation of the
parser, compiler, what have you as well?  My thinking on this is a very
definite yes, particularly given how vital such fundamental parts are
to the correct functioning of the rest of the Axiom system.  I don't
know what the state of the code defining the SPAD compiler is, or how
convoluted the SPAD->boot->lisp situation currently is, but I submit
that untangling the mess here and now as part of the Aldor language
effort would undoubtedly pay long term dividends.  Whether the best way
to do that is document and refactor what is there or simply define
Aldor->Lisp and SPAD->Lisp compilers from scratch I don't know -
anybody have an opinion on that one?

\start
Date: Tue, 18 Oct 2005 11:39:11 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Aldor and Lisp
Cc: Peter Broadbery

On October 18, 2005 10:40 AM Camm Maguire wrote:
>
> Peter Broadbery writes:
> > Anyway, just thought I'd offer some support.  Anyone know
> > of a lisp parser generator?
> > 
> 
> Heard good things about Zebu, but no direct experience.  Had
> an idea once about a GCL lisp interface to flex and bison, but
> it is not clear how much use this would ever see.
> 

Having built Aldor once on Linux and after trying to get it to
build on Windows MSYS (not working yet), I have learnt a little
about its internals. It seems that Aldor's grammar is parsed by
flex and bison - natural I suppose since Aldor is written
mostly in "C".

Although Aldor is still not open source so it might not be
kosher simply to steal the grammar code directly, perhaps this
grammar has been published elsewhere, so that we would not
have to regenerate it?

Camm, what do you mean by "GCL lisp interface to flex and
bison"? These are external programs that produce "C" code.
Do you just mean creating the bindings that would allow the
generated parser code to be called from lisp?

On another related subject, I think this thread in gcl-devel
is very relevant to our discussion of the future of SPAD and
Aldor:

http://lists.gnu.org/archive/html/gcl-devel/2005-10/msg00045.html

within which Robert Boyer discussing ML, strong typing and
proof theory.

\start
Date: Tue, 18 Oct 2005 11:45:03 -0400
From: Bill Page
To: Cliff Yapp, Camm Maguire
Subject: RE: Aldor and Lisp
Cc: Peter Broadbery

On October 18, 2005 11:30 AM C Y wrote:
> > 
> > Heard good things about Zebu, but no direct experience.  
> 
> That's this one?  http://www.cliki.net/Zebu  Does it work with
> GCL? There might be some confusion with license issues, judging
> by the Cliki discussion, but it sounds like a simple question of
> contacting the right people and verifying that we can use the
> output of Zebu in a non-GPL context.  Perhaps it would be worth
> following up on - it seems to have a rather impressive feature
> list.  Any other opinions on this?
> 

Following a few links from:

"Note that Zebu does not seem to have a way for the user to control
operator precedence and associativity, making it hard to use it to
generate a parse for all but the simplest languages. Not meaning
to slam Zebu, but it may be more effective to use CL-Yacc or even
Bovine or Wisent running under Emacs until Zebu is made more
featureful (see also my contribution to the license argument below).
 -- Joe Corneli"

I found:

http://www.pps.jussieu.fr/~jch/software/cl-yacc

"CL-Yacc - a LALR(1) parser generator for Common Lisp

CL-Yacc is a LALR(1) parser generator for Common Lisp,
similar in spirit to AT&T Yacc, Berkeley Yacc, GNU Bison,
Zebu, lalr.cl or lalr.scm.

CL-Yacc uses the algorithm due to Aho and Ullman, which is
the one also used by AT&T Yacc, Berkeley Yacc and Zebu. It
does not use the faster algorithm due to DeRemer and Pennello,
which is used by Bison and lalr.scm (not to be confused with
lalr.cl).

While CL-Yacc has undergone no systematic testing, I use it
for compiling a grammar for a superset of < C > (over 400
productions) that routinely parses thousands of lines of
< C > code.Features

\start
Date: 18 Oct 2005 20:25:29 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Aldor and Lisp
Cc: Camm Maguire, Peter Broadbery

Bill Page writes:

[...]

| Although Aldor is still not open source

Is there a hope that it will ever be?  If not, what are the odds of
creating a freely available compiler that accepts Aldor programs?

\start
Date: Tue, 18 Oct 2005 20:20:59 +0100
From: Peter Broadbery
To: Camm Maguire
Subject: Re: Aldor and Lisp

On Tue, 2005-10-18 at 10:40 -0400, Camm Maguire wrote:
> Greetings!
> 
> Peter Broadbery writes:
> 
> > On Sat, 2005-10-15 at 11:10 +0200, Martin Rubey wrote:
> > > Dear Camm, Cliff, *,
> > > 
> > 
> > If there's a rewrite of Spad using a little more of aldor, then I'd also
> > be interested in helping occasionaly (unless a really freely available
> > Aldor comes along). 
> > 
> > > There are some other small differences, I don't know by heart.
> > > 
> > > -------------------------------------------------------------------------------
> > > 
> > 
> > I guess you've missed generators, exceptions (implemented late, and IMHO
> > badly), and a very strong code optimisation phase.  
> > 
> 
> Thank you so much for this.  If you have time, it would be msot
> helpful to give a brief example showing how each of these enhancements
> works. 
> 

Generators let you say '[f(x) for x in someCollection()]' in types
other than the pre-defined axiom ones.  The type Generator represents
a possibly unbounded sequence of values (like Stream, but with less
baggage).  The form 'for x in E' represents iteration over the stream,
and the bracket function collects the values together.  If you look in
axextend.as there should be some real examples.

A rather pointless example would be
generator(x: Integer): Generator Integer == generate { yield x; yield x+1 }

[x+100 for x in 22] -- will return a list containing 122 and 123.

The first line is a stream of 2 values, the second iterates over it (the
'generator' function is implicitly called on the target of a for loop).
axextend.as contains many more useful examples.

Exceptions are try and catch blocks in C++/java terms, or catch and
throw in lisp. An example will take too long, I think..

The optimiser's main jobs are to try to inline definitions of functions
and unwind generator uses.

Function inlining is important since axiom's types tend to have several
layers of representations.  A function inliner will peel back the
layers, so that for example, a test for zero in POLY will wind up being
a simple test against null.

\start
Date: Tue, 18 Oct 2005 17:56:01 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Aldor and Lisp
Cc: Camm Maguire, Peter Broadbery

On Tuesday, October 18, 2005 2:25 PM Gabriel Dos Reis wrote:
>
> Bill Page writes:
>
> [...]
>
> | Although Aldor is still not open source
>
> Is there a hope that it will ever be?

I think there is still a good chance that Aldor will be licensed
for open source. I called Steven Watt again today. He wasn't there
but I left a detailed voice message. I told him that there have
been some discussions on the axiom-developer email list about
writing a new open source version of Aldor and that in my opinion
it would be much better if Aldor itself could be made available
under an open source license. I hope to hear from him soon.

I think it would help if some of the other subscribers to the
axiom-developer list were to contact Steven Watt and make a similar
argument. I understand that he is busy with other research (aren't
we all?) and I don't mean that we should harass him in anyway about
this, but I do think that it is important that he understands that
the availability of Aldor as open source matters to more than just
a few people.

> If not, what are the odds of creating a freely available compiler
> that accepts Aldor programs?
>

Unless a major workforce of several knowledgeable compiler writers
step forward who know lisp and have experience with SPAD in Axiom,
I have serious doubts that it will be possible to write a new
open source compiler that accepts Aldor programs. After all, Aldor
is a complex very high level language - not so different from
Haskell or Ocaml and it certainly took a major effort to implement
usable compilers for those languages.

An alternative that does exist (maybe) is to make incremental
improvements to Axiom's built-in SPAD compiler that would make
it more compatible with Aldor. In effect this would amount to
"back-porting" some of the improvements that where made to the
SPAD language when Aldor was originally implemented. The result
will be a compiler that works within Axiom to write better Axiom
library code. But it would not have the option of running as a
stand-alone compiler the way Aldor can now.

I still think however that even improving SPAD will not be easy.
It will require rather deep knowledge of the largely undocumented
legacy code that currently implements SPAD in Axiom. It is notable
I think, that the original Axiom developers chose to re-implement
SPAD as Aldor (written in C) rather than continue to make
improvements to SPAD.

\start
Date: 19 Oct 2005 00:43:17 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Aldor and Lisp
Cc: Camm Maguire, Peter Broadbery

Thank you very much for taking the time to offer a thorough answer.

Bill Page writes:

[...]

| > If not, what are the odds of creating a freely available compiler
| > that accepts Aldor programs?
| > 
| 
| Unless a major workforce of several knowledgeable compiler writers
| step forward who know lisp and have experience with SPAD in Axiom,
| I have serious doubts that it will be possible to write a new
| open source compiler that accepts Aldor programs. After all, Aldor
| is a complex very high level language - not so different from
| Haskell or Ocaml and it certainly took a major effort to implement
| usable compilers for those languages.

Indeed.  But the positive side of it is that those are now part of
common knowledge and it is not like everything has to be rediscovered
over again.  We have more foresight -- based on the accumulated knowledge
-- than they did when they started implementing those compilers :-)
And I bet the experience with Haskell or Ocaml or functional language
with dependent types will be valuable for implementing Aldor.  So,
while I agree with your points, we must also keep in fore that one
would not start totally "clueless"...

\start
Date: Tue, 18 Oct 2005 17:50:02 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#102 solve(sinh(z)=cosh(z),z) ] "foo"/list is a BOOT construction

This construct occurs frequently in the BOOT code in src/interp so
I guess that this is actually a carry-over from the BOOT language.

In http://wiki.axiom-developer.org/axiom--test--1/src/algebra/Aggcat2Spad
'reduce' is defined as either::

      reduce(fn, v, ident) ==
        val := ident
        for i in minIndex v .. maxIndex v repeat
          val := fn(qelt(v, i), val)
        val

for array-like structures or recursively (for lists)::

      reduce(fn, l, ident) ==
        empty? l => ident
        reduce(fn, rest l, fn(first l, ident))

It seems doubtful to me that either of these would be optimized
by SPAD to a simple lisp primitive (but I could be wrong). Anyway
I agree that it makes more sense to use 'reduce' in the algebra
code especially since there is no "/" operation defined in the
domain 'List', although this might introduce more circularity
(mutual recursion) in the algebra code.

I wonder if it would work to define the operation::

  "/":((S, R) -> R, A, R) -> R

as a synonym for 'reduce' in 'List' and then recompile most of
the algebra code or would SPAD die of embarrassment?

\start
Date: Tue, 18 Oct 2005 19:07:24 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Aldor and Lisp
Cc: Camm Maguire, Peter Broadbery

On Tuesday, October 18, 2005 6:43 PM Gaby wrote:
>
> Bill Page writes:
>
> | ... Aldor is a complex very high level language - not so
> | different from Haskell or Ocaml and it certainly took a major
> | effort to implement usable compilers for those languages.
>
> Indeed.  But the positive side of it is that those are now part
> of common knowledge and it is not like everything has to be
> rediscovered over again.  We have more foresight -- based on
> the accumulated knowledge -- than they did when they started
> implementing those compilers :-) And I bet the experience with
> Haskell or Ocaml or functional language with dependent types
> will be valuable for implementing Aldor.  So, while I agree
> with your points, we must also keep in fore that one would not
> start totally "clueless"...
>

I agree. In fact to take best advantage of this knowledge, perhaps
we might seriously consider the possibility of writing "new Aldor"
in a language like Ocaml. I think Ocaml might be a better choice
than Haskell since both Ocaml and Aldor are not strictly functional
languages like Haskell. Also, given the interest in applying
proof techniques in Axiom, it might be interesting to note that
Coq http://coq.inria.fr/ is written in Ocaml http://caml.inria.fr/ocaml/
which is supposed to be a "high-performance native-code compiler".

\start
Date: 18 Oct 2005 22:14:47 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Aldor and Lisp
Cc: Peter Broadbery

Bill Page writes:

> On Tuesday, October 18, 2005 6:43 PM Gaby wrote:
> > 
> > Bill Page writes:
> > 
> > | ... Aldor is a complex very high level language - not so
> > | different from Haskell or Ocaml and it certainly took a major
> > | effort to implement usable compilers for those languages.
> > 
> > Indeed.  But the positive side of it is that those are now part
> > of common knowledge and it is not like everything has to be
> > rediscovered over again.  We have more foresight -- based on
> > the accumulated knowledge -- than they did when they started
> > implementing those compilers :-) And I bet the experience with
> > Haskell or Ocaml or functional language with dependent types
> > will be valuable for implementing Aldor.  So, while I agree
> > with your points, we must also keep in fore that one would not
> > start totally "clueless"...
> > 
> 
> I agree. In fact to take best advantage of this knowledge, perhaps
> we might seriously consider the possibility of writing "new Aldor"
> in a language like Ocaml. I think Ocaml might be a better choice
> than Haskell since both Ocaml and Aldor are not strictly functional
> languages like Haskell. Also, given the interest in applying
> proof techniques in Axiom, it might be interesting to note that
> Coq http://coq.inria.fr/ is written in Ocaml http://caml.inria.fr/ocaml/
> which is supposed to be a "high-performance native-code compiler".
> 

Can't believe this thread has come full circle like this!  Wow.  May I
please suggest if this is ever of interest that we consider using the
ML that built atop GCL for many years and appears quite close to doing
so now?    Then everything stays in one image.  Or at least we could
use it as the basis for a complete implementation in lisp.

I still remain confused on a point though -- I thought there was a
reliable translator from aldor to spad and vice versa?  Why do we need
to reimplement an aldor compiler, rather than provide spad with the
missing abilities?

\start
Date: 18 Oct 2005 22:20:43 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Aldor and Lisp
Cc: Peter Broadbery

Bill Page writes:

> On Tuesday, October 18, 2005 2:25 PM Gabriel Dos Reis wrote:
> > 
> > Bill Page writes:
> > 
> > [...]
> > 
> > | Although Aldor is still not open source
> > 
> > Is there a hope that it will ever be?
> 
> I think there is still a good chance that Aldor will be licensed
> for open source. I called Steven Watt again today. He wasn't there
> but I left a detailed voice message. I told him that there have
> been some discussions on the axiom-developer email list about
> writing a new open source version of Aldor and that in my opinion
> it would be much better if Aldor itself could be made available
> under an open source license. I hope to hear from him soon.
> 
> I think it would help if some of the other subscribers to the
> axiom-developer list were to contact Steven Watt and make a similar
> argument. I understand that he is busy with other research (aren't
> we all?) and I don't mean that we should harass him in anyway about
> this, but I do think that it is important that he understands that
> the availability of Aldor as open source matters to more than just
> a few people. 
> 

Always best if it pans out.  OK, perhaps you can share his contact
info?

> > If not, what are the odds of creating a freely available compiler
> > that accepts Aldor programs?
> > 
> 
> Unless a major workforce of several knowledgeable compiler writers
> step forward who know lisp and have experience with SPAD in Axiom,
> I have serious doubts that it will be possible to write a new
> open source compiler that accepts Aldor programs. After all, Aldor
> is a complex very high level language - not so different from
> Haskell or Ocaml and it certainly took a major effort to implement
> usable compilers for those languages.
> 

Agreed, this is a *very* big job.

> An alternative that does exist (maybe) is to make incremental
> improvements to Axiom's built-in SPAD compiler that would make
> it more compatible with Aldor. In effect this would amount to
> "back-porting" some of the improvements that where made to the
> SPAD language when Aldor was originally implemented. The result
> will be a compiler that works within Axiom to write better Axiom
> library code. But it would not have the option of running as a
> stand-alone compiler the way Aldor can now.
> 

This is the option that appears best to me.  It is certainly simpler,
and I don't think we have much use for a standalone aldor compiler in
the axiom community.

> I still think however that even improving SPAD will not be easy.
> It will require rather deep knowledge of the largely undocumented
> legacy code that currently implements SPAD in Axiom. It is notable
> I think, that the original Axiom developers chose to re-implement
> SPAD as Aldor (written in C) rather than continue to make
> improvements to SPAD.
> 

Agreed the task is still involved, but much more tractable.   I feel
the motivations for the aldor rewrite need not coincide with our
motivations in the open-source axiom community, as I suggested in an
earlier post.  Tim could clear this all up -- Is SPAD irreparably
deficient in some way?

\start
Date: Tue, 18 Oct 2005 21:22:03 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [noweb] (new) 

<H2>NAME</H2><PRE>
     notangle,  noweave,  nountangle   -   noweb,   a   literate-
     programming tool


</PRE>
<H2>SYNOPSIS</H2><PRE>
     notangle [-Rrootname  ...]  [-filter  command]  [-L[format]]
     [file] ...
     nountangle [-ml|-m3|-c|-c++|-awk|-tex|-f77|-f90] [-Rrootname
     ...] [-filter command] [-wwidth] [file] ...
     noweave [options] [file] ...


</PRE>
<H2>DESCRIPTION</H2><PRE>
     <U>Noweb</U> is a literate-programming tool like Knuth's <U>WEB</U>,  only
     simpler.   A  <U>noweb</U> file contains program source code inter-
     leaved with documentation.  When <U>notangle</U> is given  a  <U>noweb</U>
     file,  it  writes  the  program  on  standard  output.  When
     <U>noweave</U> is given a <U>noweb</U> file, it reads the <U>noweb</U> source and
     produces, on standard output, <U>LaTeX</U>, <U>TeX</U>, or <U>HTML</U> source for
     typeset documentation.  <U>nountangle</U> converts a literate  pro-
     gram  into  an ordinary program by turning interleaved docu-
     mentation into comments.  The file name `-' refers to  stan-
     dard input.


</PRE>
<H2>FORMAT OF NOWEB FILES</H2><PRE>
     A <U>noweb</U> file is a sequence of <U>chunks</U>, which  may  appear  in
     any  order.   A  chunk  may  contain  code or documentation.
     Documentation chunks begin with a line that starts  with  an
     at  sign  (@)  followed by a space or newline.  They have no
     names.  Code chunks begin with
     &lt;&lt;<U>chunk</U> <U>name</U>&gt;&gt;=
     on a line by itself.  The double  left  angle  bracket  (&lt;&lt;)
     must  be  in the first column.  Chunks are terminated by the
     beginning of another chunk, or by end of file.  If the first
     line  in the file does not mark the beginning of a chunk, it
     is assumed to be the first line of a documentation chunk.

     Documentation chunks contain text that is ignored by  <U>notan-</U>
     <U>gle</U>  and  copied  verbatim  to  standard  output  by <U>noweave</U>
     (except for quoted code).   <U>noweave</U>  can  work  with  <U>LaTeX</U>,
     plain  <U>TeX</U>, or <U>HTML</U>.  With plain <U>TeX</U>, it inserts a reference
     to a <U>TeX</U> macro package, <U>nwmac</U>, which defines  commands  like
     \chapter and \section.

     Code chunks contain program source code  and  references  to
     other  code  chunks.   Several code chunks may have the same
     name; <U>notangle</U> concatenates their definitions to  produce  a
     single chunk, just as does <B>tangle</A></B>. Code chunk definitions
     are like macro definitions; <U>notangle</U> extracts a  program  by
     expanding  one  chunk  (by  default, the chunk named &lt;&lt;*&gt;&gt;).
     The definition of that chunk contains  references  to  other
     chunks,   which   are   themselves   expanded,  and  so  on.
     <U>notangle</U>'s output is readable; it preserves the  indentation
     of  expanded chunks with respect to the chunks in which they
     appear.

     Code may be quoted within documentation  chunks  by  placing
     double  square  brackets  ([[...]]) around it.  These double
     square brackets are ignored by <U>notangle</U>,  but  they  may  be
     used  by <U>noweave</U> to give the code special typographic treat-
     ment, e.g., hypertext links.  If quoted code ends with three
     or  more square brackets, <U>noweave</U> choose the rightmost pair,
     so that, for example, [[a[i]]]  is  parsed  correctly.   The
     names  of  code  chunks may appear within quoted code unless
     that quoted code is itself part of the name of a code chunk.

     If double left and right angle brackets are not paired, they
     are  treated as literal &lt;&lt; and &gt;&gt;.  Users can force any such
     brackets, even paired brackets, to be treated as literal  by
     using a preceding at sign (e.g. @&lt;&lt;).

     Some programming or formatting languages may require a  sin-
     gle @ sign in the first column. Noweb users may achieve this
     effect by putting a doubled @@ in the first column; in  this
     position only, it stands for a single @ sign.

     Any line beginning with `@ ' terminates a code chunk, but if
     the line has the form
     @ %def <U>identifiers</U>
     it is taken to mean that the  preceding  chunk  defines  the
     identifiers  listed in <U>identifiers</U>. This list contains iden-
     tifiers separated by whitespace; any  sequence  of  nonwhite
     characters  may  be  an  identifier.   <U>noweb</U>  uses  a simple
     heuristic to avoid recognizing  identifiers  that  are  sub-
     strings of other identifiers.


</PRE>
<H2>TANGLING</H2><PRE>
     <U>notangle</U> and <U>nountangle</U> accept  the  same  set  of  options,
     although some options have effects only on one or the other.
     The options are:

     -R<U>name</U>
          Expand the &lt;&lt;<U>name</U>&gt;&gt; code chunk.  The -R option  can  be
          repeated,  in  which  case each chunk is written to the
          output.  If no -R option is  given,  expand  the  chunk
          named  &lt;&lt;*&gt;&gt;.

     -L<U>format</U>
          Emit line number indications at  chunk  boundaries.   A
          line  number  indication  identifies  the source of the
          line that follows it.  In <U>format</U>, %F indicates the name
          of the source file, %L indicates the line number of the
          source file, %N indicates a newline, and %% indicates a
          percent sign.  A sign and digit may be inserted between
          the percent sign and the `L', in which  case  the  line
          number  will  be adjusted by that amount.  If <U>format</U> is
          omitted, the default format is that accepted by  the  C
          preprocessor:   `#line  %L  "%F"%N'.   When  using  the
          -L<U>format</U> option, <U>notangle</U> ensures that all text appears
          in  the  same  column  in input and output.  <U>nountangle</U>
          ignores this option.

          To solve the converse problem, that is, to get noweb to
          do  something sensible with #line in its input, see the
          sharpline filter in the examples directory.

     -t<U>k</U>   Copy tabs untouched from input to output, and use tabs
          for  indentation,  assuming  stops every <U>k</U> columns.  By
          default, tabs are expanded to spaces with stops every 8
          columns.

     -filter <U>cmd</U>
          Filter the <U>noweb</U> source through <U>cmd</U> after converting it
          to  tool  form and before tangling.  <U>notangle</U> looks for
          <U>cmd</U>   first   on   the    user's    PATH,    then    in
          /usr/cs/contrib/lib/noweb.  Such filters can be used to
          add  features  to  <U>notangle</U>;   for   an   example   see
          /usr/cs/contrib/lib/noweb/emptydefn. For experts only.

     -markup <U>parser</U>
          Use <U>parser</U> to parse the input  file.   Enables  use  of
          noweb tools on files in other formats; for example, the
          numarkup  parser  understands  <B>nuweb</B>  format.    See
          <B>nowebfilters</B>  for  more  information.   For  experts
          only.

     -tex  | -awk | -c | -icn | -icon | -ml | -m3 | -pascal | -f77  |  -f90
          When <U>nountangle</U> transforms  documentation  chunks  into
          comments, use the comment format of the language named.
          -c is the default.  <U>notangle</U> ignores these options.

     -w<U>n</U>  When <U>nountangle</U> transforms  documentation  chunks  into
          comments,  create comments on lines of width <U>n</U>.  <U>notan-</U>
          <U>gle</U> ignores this option.


</PRE>
<H2>WEAVING</H2><PRE>
     Output from <U>noweave</U> can be used in <U>TeX</U> documents that \input
     nwmac,  in  <U>LaTeX</U> documents that  use the noweb package (see
     <B>nowebstyle</B>), and in <U>HTML</U> documents  to  be  browsed  with
     <B>Mosaic</A></B>.  <U>Noweave</U>  treats  code chunks somewhat like <U>LaTeX</U>
     <U>list</U> <U>environments</U>. If the ``@  ''  that  terminates  a  code
     chunk is followed immediately by text, that text follows the
     code chunk without a paragraph break.  If the  rest  of  the
     line  is blank, <U>noweave</U> puts <U>TeX</U> into ``vertical mode,'' and
     later text starts a fresh, indented paragraph.
     No page breaks occur in the middle  of  code  chunks  unless
     necessary  to  avoid  an  overfull  vbox.  The documentation
     chunk immediately preceding a code chunk appears on the same
     page  as  that  code chunk unless doing so would violate the
     previous rule.

     <U>Noweave</U> inserts no extra newlines in its <U>TeX</U> output, so  the
     line  numbers  given  in  <U>TeX</U> error messages are the same as
     those in the input file.

     <U>noweave</U> has options that dictate  choice  of  formatter  and
     that  support  different formatting idioms and tools.  Basic
     options are described here; options  related  to  index  and
     cross-reference  information  are  described in the INDEXING
     AND CROSS-REFERENCE section.

     -latex
          Emit LaTeX, including wrapper in article style with the
          noweb package and page style. (Default)

     -tex
          Emit plain TeX, including wrapper with nwmac macros.

     -html
          Emit HTML, using HTML wrapper.   The  output  is  unin-
          teresting without -index or -x.  The tags &lt;nowebchunks&gt;
          and &lt;nowebindex&gt;, on lines  by  themselves,  produce  a
          list  of  chunks  and  an index of identifiers, respec-
          tively.  If these tags are not present,  the  list  and
          index are placed at the end of the file.

     -latex+html
          Assume documentation chunks  are  LaTeX,  but  generate
          HTML  for  code  chunks,  suitably marked so conversion
          with <B>latex2html</B> yields reasonable output.   A  LaTeX
          wrapper is implied, but can be turned off with -n.  <U>Use</U>
          <U>of</U> <U>this</U> <U>option</U> <U>is</U> deprecated; use -html with   - filter
          l2h instead.

     -troff
          Emit <B>troff</B> markup (with  no  wrapper).   The  result
          should  be  processed with <B>noroff</B>. Bug reports for -
          troff to Phil Bewig &lt;pbewig@netcom.com&gt;.

     -n    Don't use  any  wrapper  (header  or  trailer).   This
          option  is  useful when <U>noweave</U>'s output will be a part
          of a larger document.  See also -delay.

     -filter <U>cmd</U>
          Filters the <U>noweb</U> source through <U>cmd</U>  after  converting
          it  to  tool form and before converting to <U>TeX</U>. <U>noweave</U>
          looks for  <U>cmd</U>  first  on  the  user's  PATH,  then  in
          /usr/cs/contrib/lib/noweb.  Such filters can be used to
          add  features  to  <U>noweave</U>;   for   an   example,   see
          /usr/cs/contrib/lib/noweb/noxref.krom. <U>Noweave</U> supports
          up to four filters; one can get more by shell trickery,
          for example, -filter "icon.filter | noidx".  The -auto-
          defs, -x, -index, and  -indexfrom  options  are  imple-
          mented  as  filters.   Filters  are  executed  with the
          shell's eval command, so <U>cmd</U> should be  quoted  accord-
          ingly.

     -markup <U>parser</U>
          Use <U>parser</U> to parse the input  file.   Enables  use  of
          noweb tools on files in other formats; for example, the
          numarkup  parser  understands  <B>nuweb</B>  format.    See
          <B>nowebfilters</B>  for  more  information.   For  experts
          only.

     -option <U>opt</U>
          Adds  \noweboptions{<U>opt</U>}  to  the  <U>LaTeX</U>  header.   See
          <B>nowebstyle</B>  for  values of <U>opt</U>. Normally useful only
          with the -latex option, but   - option  longxref  works
          black magic with -html.

     -delay
          By default, <U>noweave</U> puts file-name and  other  informa-
          tion into the output before the first chunk of the pro-
          gram.  -delay delays that information until  after  the
          first documentation chunk, making act a little bit like
          the <U>WEB</U> ``limbo.''  The option  is  typically  used  to
          enable a user to put a specialized <U>LaTeX</U> \documentclass
          command and other preamble material in the first  docu-
          mentation  chunk.   This  option  also  forces trailing
          cross-referencing information to be emitted just before
          the final chunk, instead of at the end of the document;
          the final chunk is expected to contain  \end{document}.
          The -delay option implies the -n option.

     -t<U>k</U>   Expand tabs with stops every <U>k</U> columns.   (Default  is
          to expand every 8 columns.)

     -t    Copy tabs to the output.

     -v    Print the pipeline and RCS info on standard error.


</PRE>
<H2>INDEXING AND CROSS-REFERENCE</H2><PRE>
     When used with <U>LaTeX</U> or <U>HTML</U>, <U>noweave</U> can  provide  indexing
     and   cross-reference   information   for   chunks  and  for
     programming-language  identifiers.   Identifier  definitions
     may  be  marked  by hand using @ %def, or for some languages
     they may be found automatically using the -autodefs  option.
     This  section  describes  the  indexing  and cross-reference
     options; it might well be skipped on first reading.

     -x    For <U>LaTeX</U>, add a page number to each chunk name  iden-
          tifying  the  location  of that chunk's definition, and
          emit cross-reference information  relating  definitions
          and  uses.   For  <U>HTML</U>,  create hypertext links between
          uses and definitions of chunks.   When  noweave  -x  is
          used  with  <U>LaTeX</U>,  the  control  sequence \nowebchunks
          expands to a sorted list of all code chunks.

     -index
          Build cross-reference information (or hypertext  links)
          for identifiers defined by
          @ %def <U>identifiers</U>
          Definitions are those found in input  files.   Requires
          <U>LaTeX</U>  or  <U>HTML</U>. -index implies -x; including both will
          generate strange-looking output.  <U>noweave</U> does not gen-
          erate  cross-references  to  identifiers that appear in
          quoted code (@[[...@]]), but it does generate hypertext
          links.   When  noweave  -index  is used with <U>LaTeX</U>, the
          control sequence \nowebindex expands  to  an  index  of
          identifiers.

     -indexfrom <U>index</U>
          Like -index, but the  identifiers  to  be  indexed  are
          taken from file <U>index</U>.  See <B>noindex</B>.

     -autodefs <U>lang</U>
          Discover identifier definitions automatically.  Code in
          chunks  must  be  in  language <U>lang</U>.  Permissible <U>lang</U>s
          vary but may include tex or icon.  Useless  without   -
          index, which it must precede.

     -showautodefs
          Show values of <U>lang</U> usable with -autodefs.


</PRE>
<H2>ERROR MESSAGES</H2><PRE>
     If <U>notangle</U> or <U>noweave</U> encounters a chunk name within  docu-
     mentation,  it assumes that this indicates an error, usually
     misspelling ``&lt;&lt;name&gt;&gt;=''.  Other error messages  should  be
     self-explanatory.

     It is incorrect to refer to a chunk that is  never  defined,
     but it is OK for chunks to be defined and not used.


</PRE>
<H2>EXAMPLES</H2><PRE>
     If you have trouble digesting  this  man  page,  you're  not
     alone.   Here  are  a few examples to get you started.  I'll
     assume you have a foo.nw file with  a  C  program  in  chunk
     &lt;&lt;foo.c&gt;&gt;  and  a  header  file in chunk &lt;&lt;foo.h&gt;&gt;, and that
     your documentation is marked up using LaTeX.  I'll  show
     you how to build things using the most common options.

     To rebuild your C source, try
          notangle -L -Rfoo.c foo.nw &gt; foo.c
     To rebuild your header file, try
          notangle -Rfoo.h foo.nw | cpif foo.h
     There are two compromises here.  Omitting -L keeps #line out
     of  your  header  file,  and using cpif prevents the command
     from rewriting  foo.h  unless  the  contents  have  changed.
     Thus, this is good code to put in a Makefile rule.

     To build a printed document, run
          noweave -autodefs c -index foo.nw &gt; foo.tex
     If you have your own preamble, containing \documentclass and
     all, you will also need the -delay option.

     To build a web page, run
          noweave -filter l2h -autodefs c -index -html  foo.nw  |
          htmltoc &gt; foo.html
     Have fun!


</PRE>
<H2>FILES</H2><PRE>
     /usr/cs/contrib/lib/noweb/markup                               markup preprocessor
     /usr/cs/contrib/lib/noweb/unmarkup                             inverts markup
     /usr/cs/contrib/lib/noweb/nt                                   notangle proper
     /usr/cs/contrib/lib/noweb/finduses                             find uses of identifiers for index
     /usr/cs/contrib/lib/noweb/noidx                                generate index and cross-reference info
     /usr/cs/contrib/lib/noweb/totex                                back end to emit <U>TeX</U> or <U>LaTeX</U>
     /usr/cs/contrib/lib/noweb/tohtml                               back end to emit HTML
     /usr/cs/contrib/share/texmf/tex/latex2e/contrib/nwmac.tex      formatting <U>TeX</U> macros
     /usr/cs/contrib/share/texmf/tex/latex2e/contrib/noweb.sty      use in <U>LaTeX</U> documents; see <B>nowebstyle</B>


</PRE>
<H2>BUGS</H2><PRE>
     <U>notangle</U> and <U>nountangle</U> fail if names used  on  the  command
     line contain single quotes.

     Ignoring unused chunks can cause problems; if  a  chunk  has
     multiple  definitions  and one is misspelled, the misspelled
     definition is silently ignored.  <B>noroots</B> can be  used  to
     catch this mistake.

     <U>noweb</U> requires the new version of <U>awk</U>, assumed to be  called
     <U>nawk</U>. DEC <U>nawk</U> has a bug in that that causes noweave to fail
     to translate braces correctly.   GNU  <U>gawk</U>  is  reported  to
     work.

     DEC <U>sh</U> has a bug that causes the  - filter  option  to  fail
     whenever the filter command contains more than one word.

     The default <U>LaTeX</U> pagestyles don't  set  the  width  of  the
     boxes  containing  headers  and  footers.   Since <U>noweb</U> code
     paragraphs are extra wide, this <U>LaTeX</U> bug sometimes  results
     in  extra-wide  headers and footers.  The remedy is to rede-
     fine the relevant ps@* commands; ps@noweb in  noweb.sty  can
     be used as an example.

     <B>latex2html</B> mangles some source files.

     <U>noweave</U> has too many options, and this man page is too long.


</PRE>
<H2>VERSION</H2><PRE>
     This man page is from <U>noweb</U> version 2.8a.


</PRE>
<H2>AUTHOR</H2><PRE>
     Norman Ramsey, University  of  Virginia.   Internet  address
     nr@cs.virginia.edu.
     Noweb home page at <a href="http://www.cs.virginia.edu/~nr/noweb">
     http://www.cs.virginia.edu/~nr/noweb</a>.

</PRE>
<HR>
<ADDRESS>
Man(1) output converted with
<a href="http://www.oac.uci.edu/indiv/ehood/man2html.html">man2html</a>
</ADDRESS>

\start
Date: 18 Oct 2005 22:25:22 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Aldor and Lisp
Cc: Peter Broadbery

Bill Page writes:

> Camm, what do you mean by "GCL lisp interface to flex and
> bison"? These are external programs that produce "C" code.
> Do you just mean creating the bindings that would allow the
> generated parser code to be called from lisp?

Well, I meant defining some lisp representation if the flex and bison
input, which upon compilation wrote flex and bison C routines which
are loaded in the normal way.  In GCL, one really does have access to
anything one has in C.

If we were ever to pursue this, I really would advocate not using an
experimental lexer and parser.  No need to reinvent critical tools
when well tested ones are available with a little glue.

Take care,

> 
> On another related subject, I think this thread in gcl-devel
> is very relevant to our discussion of the future of SPAD and
> Aldor:
> 
> http://lists.gnu.org/archive/html/gcl-devel/2005-10/msg00045.html
> 
> within which Robert Boyer discussing ML, strong typing and
> proof theory.

\start
Date: Wed, 19 Oct 2005 00:35:55 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Aldor and Lisp

On Tuesday, October 18, 2005 10:15 PM Camm Maguire wrote:
>
> Bill Page writes:
> >
> > In fact to take best advantage of this knowledge, perhaps we
> > might seriously consider the possibility of writing "new Aldor"
> > in a language like Ocaml.
> >
>
> Can't believe this thread has come full circle like this! Wow.

Perhaps I should have written my previous comment with a ;) because
in a sense I was only "half serious". The main point I wanted to
emphasise was that writing a new compiler was a big and difficult
job. The skills required to do it properly and according to modern
practices require some familiarity with other modern advanced
programming languages. One way to ensure this would be to write it
in such a modern advanced programming language.

> May I please suggest if this is ever of interest that we
> consider using the ML that built atop GCL for many years and
> appears quite close to doing so now?

ML in GCL might be interesting in and of itself but I am not sure
how it could be used to help build a new compiler for Aldor.
Could ML in GCL be made to function something like BOOT in Axiom
or is it purely interpreted?

> Then everything stays in one image.  Or at least we could
> use it as the basis for a complete implementation in lisp.

Aldor runs as a separate image but produces lisp as intermediate
code which is then "compiled" by GCL in the same way as the
lisp produced by SPAD. This makes integration with Axiom as a
library compiler relatively easy.

Perhaps ML in GCL could be made to do the same? According to the
docs, Ocaml compiles to either to an architecuture independent
"byte code" or to "machine code" on a particular hardware. I wonder
if there is still some "lisp" in there somewhere?

>
> I still remain confused on a point though -- I thought there
> was a reliable translator from aldor to spad and vice versa?

There is only a tool for doing an initial conversion of SPAD into
Aldor. Additional editing of the code is often necessary to get
it to compile with Aldor.

> Why do we need to reimplement an aldor compiler, rather than
> provide spad with the missing abilities?
>

Right now, quite aside from some missing language features, I think
that programmig in SPAD is a major pain compared to programming in
Aldor. The output from the SPAD compiler is a largely uninterptable
mess - unless you happen to know enough about Axiom internals. The
SPAD error messages are close to meaningless - unless you know how
SPAD translates high level statements into lisp. As I said earlier,
my impression is that this is a tool that never got much beyond the
prototype stage. The fact that so much useful and working library
code was written using this compiler amazes me, except that one
must remember that a lot of this library code was written by the
same brillant people who were working on the compiler (or sitting
close by :).

I think Aldor on the other hand is clearly a working compiler that
would meet most of the expectations of modern programmers. It seems
to me that getting SPAD to this level, even without adding new
featuers, would still be a major effort (but certainly worthwhile
if we did not have Aldor).

And the SPAD language itself is a rather ill-defined thing. Creating
a rigorous definition of the language that was largely compatible
with SPAD was one of the major things that the Aldor developers
accomplished. But in the design of Aldor some the pecularities of
SPAD were deliberately eliminated as being undesirable. This is
what makes converting SPAD to Aldor less than completely automatic.

\start
Date: Wed, 19 Oct 2005 00:43:06 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Aldor and Lisp

On Tuesday, October 18, 2005 10:21 PM Camm Maguire wrote:
>
> Bill Page writes:
> >
> > I think it would help if some of the other subscribers to the
> > axiom-developer list were to contact Steven Watt and make a
> > similar argument. I understand that he is busy with other
> > research (aren't we all?) and I don't mean that we should harass
> > him in anyway about this, but I do think that it is important
> > that he understands that the availability of Aldor as open source
> > matters to more than just a few people.
> >
>
> Always best if it pans out.  OK, perhaps you can share his
> contact info?

I would be glad to, but I prefer to do it by private email.
There is also some contact information at the Aldor web site.
See: http://www.aldor.org/contact.html

\start
Date: 19 Oct 2005 07:09:25 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Aldor and Lisp
Cc: Peter Broadbery

Bill Page writes:

| On Tuesday, October 18, 2005 6:43 PM Gaby wrote:
| > 
| > Bill Page writes:
| > 
| > | ... Aldor is a complex very high level language - not so
| > | different from Haskell or Ocaml and it certainly took a major
| > | effort to implement usable compilers for those languages.
| > 
| > Indeed.  But the positive side of it is that those are now part
| > of common knowledge and it is not like everything has to be
| > rediscovered over again.  We have more foresight -- based on
| > the accumulated knowledge -- than they did when they started
| > implementing those compilers :-) And I bet the experience with
| > Haskell or Ocaml or functional language with dependent types
| > will be valuable for implementing Aldor.  So, while I agree
| > with your points, we must also keep in fore that one would not
| > start totally "clueless"...
| > 
| 
| I agree. In fact to take best advantage of this knowledge, perhaps
| we might seriously consider the possibility of writing "new Aldor"
| in a language like Ocaml. I think Ocaml might be a better choice
| than Haskell since both Ocaml and Aldor are not strictly functional
| languages like Haskell. 

Haskell is not strictly functional either -- despite the banners.
It has an imperative skin.

That said, I would not like to get into "language war".  My compiler
implementation experience is with languages like C, C++ and Haskell --
for writing compilers for those language in themselves.  

| Also, given the interest in applying proof techniques in Axiom,

My current work on designing and implementing a general, efficient,
scalable, complete representation of ISO C++ (with concepts) in C++
has led me to look at the materials on proof techniques in Axiom.
I've read claims that Type:Type is inconsistent with
types-as-propositions stance.  I'm curious to learn how the type/proof
techniques in Aldor would get away with that. 

\start
Date: Wed, 19 Oct 2005 07:04:16 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Aldor and Lisp

On Wednesday, October 19, 2005 4:40 AM Martin Rubey wrote:
> ...
> Bill Page wrote:
> > > I still think however that even improving SPAD will not
> > > be easy.  It will require rather deep knowledge of the
> > > largely undocumented legacy code that currently implements
> > > SPAD in Axiom.
>
> We will need this knowledge anyway to understand the
> interpreter, I guess.
>

The interpreter and the SPAD compiler are largely separate
as is obviously since Aldor is able to substitute for SPAD.
But I agree that a deep knowledge of the interpreter is
also required for other reasons, e.g. incorporating some
of the Aldor extensions.

> > > It is notable I think, that the original Axiom
> > > developers chose to re-implement SPAD as Aldor
> > > (written in C) rather than continue to make
> > > improvements to SPAD.
>
> I'm absolutely certain that the reason for this was rather
> a political than a technical one.
>

Could you explain what makes you absolutely certain of this?
Can you cite any references to Axiom or Aldor literature?

In what sense was it "political"? Who stood to gain by such
a decision?

To me the technical reasons seem rather obvious. So please
forgive me if I seem rather skeptical.

\start
Date: Wed, 19 Oct 2005 10:39:41 +0200
From: Martin Rubey
To: Camm Maguire
Subject: Re: Aldor and Lisp
Cc: Peter Broadbery

Dear all,

concerning the freeing of Aldor, Ralf told me a week ago or so that there is
some hope. It seems that Stephen is looking at the issue, but "it's not settled
yet".

 > > An alternative that does exist (maybe) is to make incremental improvements
 > > to Axiom's built-in SPAD compiler that would make it more compatible with
 > > Aldor. In effect this would amount to "back-porting" some of the
 > > improvements that where made to the SPAD language when Aldor was
 > > originally implemented. The result will be a compiler that works within
 > > Axiom to write better Axiom library code. But it would not have the option
 > > of running as a stand-alone compiler the way Aldor can now.
 > 
 > This is the option that appears best to me.  It is certainly simpler, and I
 > don't think we have much use for a standalone aldor compiler in the axiom
 > community.

As you probably know by now, this is my favorite option, too. I would like to
point out, that we will not be able to use "full" Aldor for Axiom, even if it's
free, since the Axiom interpreter doesn't understand dependend
types. Generators and exceptions don't seem to be so important to me. In fact,
concerning generators, I don't see the advantage over Stream yet.

And I think that Spad should be improved by using boot or common lisp. Not yet
another language to learn! Spad/Aldor itself would be acceptable to me, but as
I detailed before, I think it will be easier to attract Lisp knowledge than
anything else. (Thanks Camm, by the way, for supportin my post!)

 > > I still think however that even improving SPAD will not be easy.  It will
 > > require rather deep knowledge of the largely undocumented legacy code that
 > > currently implements SPAD in Axiom.

We will need this knowledge anyway to understand the interpreter, I guess.

 > > It is notable I think, that the original Axiom developers chose to
 > > re-implement SPAD as Aldor (written in C) rather than continue to make
 > > improvements to SPAD.

I'm absolutely certain that the reason for this was rather a political than a
technical one.

 > Is SPAD irreparably deficient in some way?

definitely not. Note however that there is *no* Aldor -> Spad translator. There
is however a Spad -> Aldor translator, which mainly transforms pile syntax
(i.e., indentation sensitive style) to the "nopile" syntax (i.e., blocks
delimited by braces.)

I can deal with both syntaxes and Aldor does so, too.

I do think that the Spad compiler could need improving, but my goal is rather
to have a good Algebra hierarchy and sufficiently many developers. A dozen is
just not enough. And, moreover, we need to attract more genuine mathematicians,
i.e., researchers. If this doesn't change within a year or so, Axiom is
probably doomed to die. In this vein, getting into contact with Singular is the
one of the best things that could happen to us. A second community, that is
*huge* and were several people are interested in contact is R. By coincidence,
the sit in Vienna, and I'm at the institute of statistics currently. So I
guess, this is my job. I'll post a message, I think.

\start
Date: Wed, 19 Oct 2005 03:20:06 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#102 solve(sinh(z)=cosh(z), z) ] 

It *should* work, given that the compiler does not stumble over some bug. However, I don't think it is the right direction to take anyway: 

- The bugs mentioned here won't go away, since you would have to provide the third argument, and
- I think that 'reduce' is easier to understand for the casual reader.

Concerning the optimization: in an ideal world, reduce would be optimized away. We are not in an ideal world, and we will never be, but we should strive to make it better...

\start
Date: Wed, 19 Oct 2005 11:02:26 +0200
From: Martin Rubey
To: Christian Aistleitner
Subject: Re: Aldor and Lisp
Cc: Peter Broadbery, Camm Maguire

great that you pop in -- you are not at RISC-Linz anymore, are you?

Christian Aistleitner writes:

 > I wrote that parser almost 1.5 years ago (I guess). I still have it on some
 > Backup if someone is interested. It was implemented in Aldor. I could parse
 > all source files I tested.

This is great news! I suppose, however, that it parses only the nopile syntax,
doesn't it?
 
 > However, the code is more or less worthless, as it is _not_ properly  
 > documented. 

I disagree slightly :-)

 > Nevertheless, the parser is as far as I remember complete. But if one does
 > not want to restrict oneself to implementing the compiler in Aldor, I guess
 > you'd be better of with some compiler compiler.

Am I correct that Aldor is able to compile to lisp? Then it would probably be
possible to run this Aldor parser in a Lisp image, maybe our Lisp gurus could
do some magic with this?

In fact, I know nearly nothing about compilers and interpreters. So maybe
somebody could detail here the bits and pieces needed to morph the current Spad
compiler and interpreter of Axiom into an Aldor compiler and interpreter for
Axiom?

As far as I understand, one "problem" is that the Axiom interpreter knows quite
a bit about the Algebra, to do it's type inference, which is a "must have"...

\start
Date: 19 Oct 2005 14:40:27 +0200
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: Aldor and Lisp
Cc: Camm Maguire, Peter Broadbery

Martin Rubey writes:

[...]

|just not enough. And, moreover, we need to attract more genuine mathematicians,
| i.e., researchers.

:-)

What criteria do you propose for use to recognize "genuine"
mathematician from a "fake" one?

\start
Date: Wed, 19 Oct 2005 06:51:30 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Camm Maguire
Subject: RE: Aldor and Lisp


> On Tuesday, October 18, 2005 10:15 PM Camm Maguire wrote:
> > 
> > Bill Page writes:
> > > 
> > > In fact to take best advantage of this knowledge, perhaps we
> > > might seriously consider the possibility of writing "new Aldor"
> > > in a language like Ocaml.
> > > 
> > 
> > Can't believe this thread has come full circle like this! Wow.
> 
> Perhaps I should have written my previous comment with a ;) because
> in a sense I was only "half serious". The main point I wanted to
> emphasise was that writing a new compiler was a big and difficult
> job. The skills required to do it properly and according to modern
> practices require some familiarity with other modern advanced
> programming languages. One way to ensure this would be to write it
> in such a modern advanced programming language.

With apologies to Camm, there is one sense in which arriving at ocaml
is neither full circle nor unattractive, and that is the coq theorem
prover.  If there is indeed serious interest in backing Axiom with a
powerful theorem prover, COQ is definitely up there on the list of
candidates.  In fact, some work was done in France a while back on
coq+Axiom - as yet I have not yet located a copy of that thesis,
unfortunately.  I think I posted here about it and got no response. 
Now, before anybody panics let me say I don't think the best option
would be to rely on one prover, any more than I like depending on one
Lisp, and that removes coq+axiom in one image as attractive.  The
reasons for not relying on one prover are also rather more compelling
than the different lisp implementations debate, since these provers
often operate in different styles (guided vs. automatic) and using
different foundational theories.  In an ideal world we would select one
"main" proof engine but be able to work with several others if a user
needed or wanted to.

I know the interest in this topic is spotty, but this is the time and
place to raise the question - if we DO want to be able to back Axiom
with formal provers, what are the design considerations that need to be
taken into account?  What precisely will the prover be used to do, how
would we interact with it, and how would we store and use the results? 
If I'm the only one thinking this way I guess that nominates me to look
into this, but since I have almost no formal training in such matters I
would much prefer to hear from professionals who could make more
definite statements on both the goals and the techniques that would
come into play here.  I'm not proposing to hook a prover into Axiom
right now, or even as part of the Aldor conversion process (although
that would be nice) but I think we should try to define any necessary
logic and/or APIs to enable future use of proof systems in the future. 
I know there has alreay been at least one other effort to study Axiom
with proof logic mentioned here earlier that has its writeup online
(not with coq) so that's probably the place to start.

\start
Date: Wed, 19 Oct 2005 07:24:32 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Camm Maguire
Subject: Re: Aldor and Lisp
Cc: Peter Broadbery

> Dear all,
> 
> concerning the freeing of Aldor, Ralf told me a week ago or so that
> there is some hope. It seems that Stephen is looking at the issue, 
> but "it's not settled yet".

Good news!

> > > An alternative that does exist (maybe) is to make incremental
> > > improvements to Axiom's built-in SPAD compiler that would make 
> > > it more compatible with Aldor. 

[snip]

> As you probably know by now, this is my favorite option, too. I would
> like to point out, that we will not be able to use "full" Aldor for 
> Axiom, even if it's free, since the Axiom interpreter doesn't 
> understand dependend types. 

I thought one of the goals was to expand Axiom's abilities as needed to
take advantage of Aldor?

> Generators and exceptions don't seem to 
> be so important to me. In fact, concerning generators, I don't see 
> the advantage over Stream yet.

Um.  Not qualified to have an opinion - need an Aldor guru here.

> And I think that Spad should be improved by using boot or common
> lisp. Not yet another language to learn! Spad/Aldor itself would be
> acceptable to me, but as I detailed before, I think it will be 
> easier to attract Lisp knowledge than anything else. (Thanks Camm,
> by the way, for supportin my post!)

I agree I would hate to abandon Lisp.
 
> > > I still think however that even improving SPAD will not be 
> > > easy.  It will require rather deep knowledge of the largely 
> > > undocumented legacy code that currently implements SPAD in Axiom.
> 
> We will need this knowledge anyway to understand the interpreter, I
> guess.

More than that, I don't think we can regard SPAD being "undocumented
legacy code" as being compatible with the 30 year horizon.  I don't
think we can regard the compiler and supporting code as being exempt
from the literate programming requirements - they are essential to the
system and the choices put into the language design have far reaching
consequences.  Because of this, to me the debate of reusing Aldor vs.
updating SPAD vs. just sticking with SPAD is a bit moot, because
regardless of which way we go we are going to have to dive in and
create a functioning language support for Axiom that is both well
understood and well documented as literate programming code.  That's
the hard part, and the specific code we wind up using is almost a
detail.  Several people have noted that we are faced with a large task
because we don't have people available with the required expertise in
Aldor/SPAD/Lisp/compiler design/what have you.  To me this is the most
compelling argument yet for getting in there, doing the research,
making literate documents out of everything, and documenting the
reasons for design decisions.

> I'm absolutely certain that the reason for this was rather a
> political than a technical one.

I take it you mean in the sense that they figured they wouldn't be able
to get programmer effort devoted to Aldor if it were written in Lisp? 
Or some manager said "why hire expensive lisp programmers when we can
do this in C?"

>  > Is SPAD irreparably deficient in some way?

[snip]

> I do think that the Spad compiler could need improving, but my goal
> is rather to have a good Algebra hierarchy and sufficiently many 
> developers. A dozen is just not enough. And, moreover, we need to 
> attract more genuine mathematicians, i.e., researchers. If this 
> doesn't change within a year or so, Axiom is probably doomed to 
> die.

As somebody said, "it ain't over 'til it's over."  I take it you are
concerned that technical issues like the compiler will distract from
mathematical improvements?  This is a concern but remember one of the
goals of Axiom is to be robust "in the long term," which is difficult
if the supporting superstructure shifts under it too much.  I don't
think mathematical development need wait on these issues, surely - we
are already functional and I doubt enough new work will happen to make
the situation of shifting compilers any more overwhelming than it
already is.  We aren't going to throw out all the work done to date -
on the contrary.  We want to polish it up and preserve it.

> In this vein, getting into contact with Singular is one of the best
> things that could happen to us. 

Agreed.  But unless I'm misunderstanding something I don't think
mathematical developments with the Singular team need wait on compiler
issues?

> A second community, that is *huge* and were several people are 
> interested in contact is R. By coincidence, the sit in Vienna, and
> I'm at the institute of statistics currently. So I
> guess, this is my job. I'll post a message, I think.

Sounds good!  My recollection is that R is a largely numerical tool -
are you thinking it would make a good replacement for the NAG
libraries?  

I agree we need more attention from academic institutions and
researchers, but I'm not sure how to go about it except attempt to
force our way in by sheer merit.  One idea might be to pick several
modern ideas from recent journals, implement them in Axiom, and
demonstrate some non-trivial academic benefit that can be gained once
they are implemented in Axiom.  The problem is the academic community
is used to new systems appearing - it is not clear what would make a
given system into a "winner" that would result in mass adoption.  The
best idea I can come up with is demonstrate non-trivial useful research
on current hot topics as assisted by Axiom.  Mathematica seems to have
made itself secure by being demonstrably useful in a wide variety of
practical engineering and scientific situations - perhaps the same
technique could work for Axiom on the more theoretical side.

\start
Date: Wed, 19 Oct 2005 16:29:08 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: Aldor and Lisp
Cc: Camm Maguire, Peter Broadbery

Gabriel Dos Reis writes:
 > Martin Rubey writes:
 > 
 > | just not enough. And, moreover, we need to attract more genuine mathematicians,
 > | i.e., researchers.
 > 
 > :-)
 > 
 > What criteria do you propose for use to recognize "genuine" mathematician
 > from a "fake" one?

None. What I tried to say is: active in a field of research relevant to
computer algebra, or, in a field of research where computer algebra is a major
player.

Thanks for pointing out my silly sentence :-)

\start
Date: Wed, 19 Oct 2005 13:47:10 -0400
From: Bill Page
To: Martin Rubey, Christian Aistleitner
Subject: RE: Aldor and Lisp

On Wednesday, October 19, 2005 5:02 AM Martin Rubey wrote:
>
> Christian Aistleitner writes:
>
> > I wrote that parser almost 1.5 years ago (I guess). I still
> > have it on some Backup if someone is interested. It was
> > implemented in Aldor. I could parse all source files I tested.

An Aldor parser written in Aldor?! I did not receive the rest
of the background of this email, but it certainly sounds
interesting. Could you forward a copy to the email list?

>
> This is great news! I suppose, however, that it parses only
> the nopile syntax, doesn't it?
> 
> > However, the code is more or less worthless, as it is _not_
> > properly documented.
>
> I disagree slightly :-)
>

I disagree completely. I think an Aldor parser written in Aldor
is would be very worthwhile. If you make it available on the
web, then we can help document it.

> > Nevertheless, the parser is as far as I remember complete.
> > But if one does not want to restrict oneself to implementing
> > the compiler in Aldor, I guess you'd be better off with some
> > compiler compiler.
>

I think that it has value in any case as a rigorous definition
of the grammar. And Aldor is close to SPAD, so it is not out
the question to port this code to SPAD.

> Am I correct that Aldor is able to compile to lisp?

Yes. This is already used in the Aldor/Axiom integration.

> Then it would probably be possible to run this Aldor parser
> in a Lisp image, maybe our Lisp gurus could do some magic with
> this?

That should be simple. But machine generated lisp is not likely
to be very easy to maintain as primary source and if we can't
get rid of the Aldor dependence then there doesn't seem to be
much point.

>
> In fact, I know nearly nothing about compilers and interpreters.
> So maybe somebody could detail here the bits and pieces needed
> to morph the current Spad compiler and interpreter of Axiom into
> an Aldor compiler and interpreter for Axiom?

One thing to keep in mind is that successfully parsing a language
is probably about only 1% of the overall problem - main issues
really being code generation and optimization.

BTW here is another very good paper on the Aldor language:
http://portal.axiom-developer.org/refs/articles/thompson-aldor.pdf/view
It includes "a formal account of the semantics and type system of
Aldor". There formal semantics are the kind of specification on
which the code generation must be based.

>
> As far as I understand, one "problem" is that the Axiom
> interpreter knows quite a bit about the Algebra, to do it's
> type inference, which is a "must have"...
>

I don't think that this is a problem, per se.

The Axiom interpreter remains a central component of Axiom
that needs to access and manipulate especially the type
information from the Axiom library. This is done now largely
through the database (daase) files. Both SPAD and the Aldor
Axiom interface code already update the database. A new
compiler would have to do the same.

\start
Date: Wed, 19 Oct 2005 16:30:51 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Aldor and Lisp
Cc: Peter Broadbery

On Wednesday, October 19, 2005 1:09 AM Gaby wrote:
>
> My current work on designing and implementing a general,
> efficient, scalable, complete representation of ISO C++ (with
> concepts) in C++ has led me to look at the materials on proof
> techniques in Axiom. I've read claims that Type:Type is
> inconsistent with types-as-propositions stance.  I'm curious
> to learn how the type/proof techniques in Aldor would get
> away with that.
>

I think this is a very interesting question. It relates also
to an email exchange a few weeks ago between Peter Broadbery,
Ralf Hemmecke, Tim Daly, me and a few others concerning the
structure of the upper levels of Axiom's type system.

http://lists.gnu.org/archive/html/axiom-developer/2005-09/msg00225.html

I think that our conclusion was (at least it was my view :) that
Axiom's concept of Category as the type of Domain and Type as a
Category is not implemented consistently in the current system.

http://wiki.axiom-developer.org/206InterpreterCodeGenerationFailedForFun
ctionReturningAType

On the following page I tried to summarize Axiom's use of these
terms:

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

Aldor on the other hand seems to take the concept of types as
values more seriously than SPAD but the "two-level object model
of categories and domains" still seems to lead to some confusion
between domains and types.

Here are few more references to "types as values" in the Aldor
literature:

From: http://www.cs.kent.ac.uk/people/staff/sjt/Atypical/technical.html
by Simon Thompson, John Shackell and Erik Poll

"A feature of the Axiom/Aldor is that types can be treated as values,
so that the type Type is itself a type and so the system allows
functions over types, such as the function which taking a type ty
to a type of queues over ty, say, or a type of fields F to the
category of vector spaces over F."

--------

From: http://www.cs.ru.nl/~erikpoll/talks/axiom.pdf
by Erik Poll

Types as values

Alternatively, using Aldor's notation for lambda,

polyid : (T:Type)->T->T
== (T:Type)(t:T):T +-> t;

idType : Type -> Type
== (T:Type):Type +-> T;

In Aldor, (lambda x:A.b) is written as (x:A):B +-> b

--------

Impredicativity and Type:Type

The type of the polymorphic identity is a type

PolyidType : Type == (T:Type)->T -> T;

In fact, Type is a type

MyType : Type == Type;
MyTypeArrowType : Type == Type -> Type;
MyType2 : Type == (polyid Type) Type ;

Warning: application associates to the right!

----------

From:
http://lists.gnu.org/archive/html/axiom-developer/2005-09/msg00234.html
On  26 Sep 2005 16:30:49 +0200 Ralf Hemmecke wrote:

Re: types as values

But having defined the function tt2 in Aldor like this:

#include "axiom.as";
testtype2(): with {
    tt2: (Integer) -> Type;
} == add {
    tt2(x:Integer):Type == {
      x=0 => Integer;
      Float;
      }
    }

How can I use it in Axiom in a useful manner?

-----------

Now specifically about the idea that "Type is a Type" might
be inconsistent with types-as-propositions: I think that this
is true only in the most restricted definition of what one
means by a proposition. Certainly under this definition Type
is too "large" to be a Set. But this does not mean that we
cannot reason about it's properties using other formal methods,
for example by means of equational logic in purely algebraic/
co-algebraic terms. There is quite a large literature about
equational proof methods.

Lately I have been reading the book "Vicious Circles: On the
Mathematics of Non-Well-founded Phenomena" by Barwise and Moss.
It seems clear that set theory based on the anti-foundation
axiom (AFA) should, in principle provide formal proof methods
for dealing with objects such as Aldor's Type. But I do not
know of any specific research in this area. In addition, the
book discusses the generalization of AFA to greatest fixed
points, systems of equations, co-algebras and co-recursion
which provide formal methods of reasoning about types such as
streams, generators and iterators.

It seems plausible to me to suppose that a large part of the
mathematical expressiveness of the Axiom and Aldor languages
is due to the apparent non-well-foundedness of it's type
system. In this sense non-well-foundedness is a good thing:
it makes it seem more likely that Type is "large enough" to
contain to "all of mathematics" (whatever we might want that
to mean :).

I hope some of the contents of this email are useful to you
and I look forward to hearing your views about Type:Type.

\start
Date: Wed, 19 Oct 2005 18:31:42 -0400
From: Tim Daly
To: list
Subject: debugging information

I'm in the debugsys image chasing a few things and came across this
interesting variable. In an axiom image type:

  )lisp (setq |$reportInstantiations| t)

and then type an expression such as 

 -> 1

# instantiated/# dropped/domain name

1 0 PositiveInteger
1 0 OutputForm
1 0 NonNegativeInteger
1 0 List OutputForm
1 0 Integer
 Totals: 5 instantiated
         0 inside coerceInteractive
         0 inside canCoerceFrom
         0 inside evalMmCond
         0 reinstantiated
         0 dropped
         5 distinct domains instantiated/dropped

I'm not sure how useful you'll find that information but it's useful
to know you can get it. I'm writing a chapter on debugging in book 4
of the axiom volumes which will contain this and other debugging tips,
techniques and useful tidbits.

Tim

\start
Date: Wed, 19 Oct 2005 19:06:43 -0400
From: Bill Page
To: Tim Daly
Subject: RE: debugging information

On Wednesday, October 19, 2005 6:32 PM you wrote:
>
> I'm in the debugsys image chasing a few things and came
> across this interesting variable. In an axiom image type:
>
>   )lisp (setq |$reportInstantiations| t)
>

I believe that flag is controlled by the Axiom command:

)set message instant on/off

> ...
> I'm not sure how useful you'll find that information but
> it's useful to know you can get it.

Agreed!

> I'm writing a chapter on debugging in book 4 of the axiom
> volumes which will contain this and other debugging tips,
> techniques and useful tidbits.
>

Gee, that reminds me of our plans long ago to publish
hardcopies of these volumes on www.lulu.com . I haven't
looked at these volumes lately. What would be your estimate
of how much work remains before we could submit something?
Do you think getting these published should have a higher/
lower priority than some of the other (more interesting?)
stuff?

Since I now just about have the pamphlet support on MathAction
working the way I want and the new book volumes are in the
form of pamphlet files, I wonder if it would make it easier for
other to contribute if I were to put these up on MathAction?
This would allow direct editing through the web. If I did this,
because of their size, maybe it would be a good idea to split
the volumes out further to chapter sized documents and then
define a master document for printing?

It reminds me also that we had talked about making it possible
to order CDrom containing installable versions of Axiom, the
source code and documentation. I think this can be done on
lulu with a bit of effort. I know that it is quite easy to
sell CDs through www.cafepress.com where we currently have
the Axiom Foundation Store (Axiom Gear).

I wonder if there is anyone out there who would like to take
on the task to prepare such a CD? I could help but I don't
want to lead the effort.

\start
Date: Wed, 19 Oct 2005 20:24:20 -0400
From: Tim Daly
To: Bill Page
Subject: Re: debugging information

> Gee, that reminds me of our plans long ago to publish
> hardcopies of these volumes on www.lulu.com . I haven't
> looked at these volumes lately. What would be your estimate
> of how much work remains before we could submit something?
> Do you think getting these published should have a higher/
> lower priority than some of the other (more interesting?)
> stuff?

There are 4 volumes in book--main--1:
  Vol 1: Tutorial
  Vol 2: Programming
  Vol 3: Reference
  Vol 4: Developers Guide

I've been working my way back thru the email archives and extracting
emails that need to be integrated into these volumes. I've also split
up the book into the related volumes. 

There is much work to be done and I have no time estimate. 
Documentation is vital and good documentation takes much longer
than anyone expects. I'm looking into parts of the system and
have decided to write some debugging techniques and documentation
on writing pamphlet files so most of my effort is going into volume 4.

> 
> Since I now just about have the pamphlet support on MathAction
> working the way I want and the new book volumes are in the
> form of pamphlet files, I wonder if it would make it easier for
> other to contribute if I were to put these up on MathAction?
> This would allow direct editing through the web. If I did this,
> because of their size, maybe it would be a good idea to split
> the volumes out further to chapter sized documents and then
> define a master document for printing?

We can try putting the volumes online. Provided they still retain
their pamphlet format (ie latex) I think it's a reasonable idea.
I'm a little concerned about changes that would use things like
structured text, html, or other non-latex information in the files.
Those are fine for the wiki but not for the system files, of which
the book volumes are the cornerstone in my mind. 

Later I want to develop a few more volumes that are related to
pieces of the system. For example I think 

  Vol 5: Categories, Domains, and Package Internals
  Vol 6: The compiler
  Vol 7: The interpreter
  Vol 8: The algebra

where these contain, structure, and build upon the sources.
Volume 5 would explain the static and dynamic data structures,
file structures and manipulation functions. Volume 6 would
explain the compiler internals. Volume 7 would explain the
interpreter internals, and Volume 8 would document the algebra.

These 4 volumes would contain and structure the actual source
code of the system. So the current pamphlets would become
chapters within these volumes.

The system would be built from the books.

Eventually modifying Axiom becomes a job of authoring or
editing a section of one of the volumes.

I have a bit of machinery already (due to David Mentre) that
extends the pamphlet idea to "booklets". The basic change is
that chunk names have semantics. Thus in addition to the
standard random chunk name syntax:

<<random chunk name>>=
@

you can use a URI kind of syntax as in:

<<pamphlet:foo.pamphlet>> to include a pamphlet
<<file://....>> to include a file
<<http://....>> to include from a web source

etc. We can create our own protocols as needed.
  

> 
> It reminds me also that we had talked about making it possible
> to order CDrom containing installable versions of Axiom, the
> source code and documentation. I think this can be done on
> lulu with a bit of effort. I know that it is quite easy to
> sell CDs through www.cafepress.com where we currently have
> the Axiom Foundation Store (Axiom Gear).
> 
> I wonder if there is anyone out there who would like to take
> on the task to prepare such a CD? I could help but I don't
> want to lead the effort.

I can look into the installable CDRom issue.
I've already built iso images for ISSAC.

\start
Date: Wed, 19 Oct 2005 19:28:06 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Bill Page
Subject: Re: debugging information

--- Tim Daly wrote:

> > Gee, that reminds me of our plans long ago to publish
> > hardcopies of these volumes on www.lulu.com . 

Heh, funny I was just looking at lulu.com myself.

> There are 4 volumes in book--main--1:
>   Vol 1: Tutorial
>   Vol 2: Programming
>   Vol 3: Reference
>   Vol 4: Developers Guide

Sounds good!
 
> I've been working my way back thru the email archives and extracting
> emails that need to be integrated into these volumes. I've also split
> up the book into the related volumes. 
> 
> There is much work to be done and I have no time estimate. 
> Documentation is vital and good documentation takes much longer
> than anyone expects. 

Amen.  I've yet to write one line of code or get past reviewing other
work and the fundamentals and already I've got 20 pages of content on
Units and Dimensions.  'course, I'm probably going overboard...

> I'm looking into parts of the system and
> have decided to write some debugging techniques and documentation
> on writing pamphlet files so most of my effort is going into volume
> 4.

Neat! And here I'm cut off from my tla tools...
 
> > [snip] maybe it would be a good idea to split
> > the volumes out further to chapter sized documents and then
> > define a master document for printing?

FWIW, that's what we did with Maxima Book, although it was never web
based.

> Later I want to develop a few more volumes that are related to
> pieces of the system. For example I think 
> 
>   Vol 5: Categories, Domains, and Package Internals
>   Vol 6: The compiler
>   Vol 7: The interpreter
>   Vol 8: The algebra
> 
> where these contain, structure, and build upon the sources.

I LIKE that idea!

> Volume 5 would explain the static and dynamic data structures,
> file structures and manipulation functions. Volume 6 would
> explain the compiler internals. Volume 7 would explain the
> interpreter internals, and Volume 8 would document the algebra.

One comment - the algebra volume could wind up containing a really
really large amount of data.  Perhaps after 5, 6, and 7 have been
tackled we should look at breaking down the algebra into more managable
chunks?

> These 4 volumes would contain and structure the actual source
> code of the system. So the current pamphlets would become
> chapters within these volumes.
> 
> The system would be built from the books.
>
> Eventually modifying Axiom becomes a job of authoring or
> editing a section of one of the volumes.

Awesome!  So a set of printed volumes of Axiom books would not be
simply a document but actually define the entire system, in all its
detail, from implementation to mathematics to user interface! 
Depending on how much effort gets put into the algebra over the years
Axiom might become a virtual encyclopedia of mathematics, at least
mathematics at or above the level of that comprising the foundation of
Axiom.

> > It reminds me also that we had talked about making it possible
> > to order CDrom containing installable versions of Axiom, the
> > source code and documentation. I think this can be done on
> > lulu with a bit of effort. I know that it is quite easy to
> > sell CDs through www.cafepress.com where we currently have
> > the Axiom Foundation Store (Axiom Gear).
> > 
> > I wonder if there is anyone out there who would like to take
> > on the task to prepare such a CD? I could help but I don't
> > want to lead the effort.
> 
> I can look into the installable CDRom issue.
> I've already built iso images for ISSAC.

Just curious - are you talking about the auto-install CDs like
Mathematica has that you just pop in the disk and it starts up the
install wizard?  I know that doesn't fly on Linux and I have no idea
about Mac (assuming we are in shape to run on the Mac and Windows in
the first place, of course) but it might be kind of neat to use
whatever that trick is and make a professional looking install CD.  As
far as installer tools for Windows go, I've been curious to check out
the Nullsoft installer at http://nsis.sourceforge.net/  (of course, not
having a Windows box kind of puts a damper on that ambition.)  Anybody
know anything about it?

\start
Date: Wed, 19 Oct 2005 22:54:31 -0400
From: Bill Page
To: Cliff Yapp, Tim Daly
Subject: RE: debugging information

On Wednesday, October 19, 2005 10:28 PM C Y wrote:
>
> One comment - the algebra volume could wind up containing a really
> really large amount of data.  Perhaps after 5, 6, and 7 have been
> tackled we should look at breaking down the algebra into more
> manageable chunks?

I agree completely. At something like 10,000 pages I seriously
doubt that anyone with an environmental conscience would dare to
print it or even order the volumes! In fact I doubt that most
people would be that interested in printed material after the
first tutorial and programming guide. These days when it comes
to printed material **smaller** is better. The rest of the stuff
just stays on the CDrom (or web site) just in case you might want
to take the time to look at it.

So when it comes to publishing hardcopy, I think we should be
quite selective - at least at first. Lulu is "print on demand"
so creating material is no problem - just extra work with
perhaps little payoff.

>
> Awesome!  So a set of printed volumes of Axiom books would not
> be simply a document but actually define the entire system, in
> all its detail, from implementation to mathematics to user
> interface!

But this will never work. Paper is just too awkward a media to
maintain a "crystal" system of this size. Of course I am just
promoting my own approach with MathAction, but I seriously doubt
that we can realistically continue to maintain Axiom unless we
can solve the problem of really *collaborating* over the Internet.

> Depending on how much effort gets put into the algebra over the
> years Axiom might become a virtual encyclopedia of mathematics,
> at least mathematics at or above the level of that comprising the
> foundation of Axiom.

Useless in my opinion unless it can be made to be very easily
accessible online.

>
> Just curious - are you talking about the auto-install CDs like
> Mathematica has that you just pop in the disk and it starts up
> the install wizard?

Auto-install on windows is a piece of cake - just a couple of
extra files on the CD.

Something similar is possible on some versions of linux, but
usually linux people it isn't worth it since they want to know
exactly what it is doing anyway. For linux there is at least
RPM (see new files in AxiomDownload page) and Debian apt-get
(which can be made to read from CDrom).

> I know that doesn't fly on Linux and I have no idea about Mac
> (assuming we are in shape to run on the Mac and Windows in
> the first place, of course)

Mac, no I don't think so. Not yet. Someone used to be working
on it but I haven't heard anything recently. On Windows, yes
(but not graphics or hyperdoc). This is where we need to complete
the work on the new AxiomUI interface which is intended to run
on both linux and windows and provide a functionally similar
interface as hyperdoc but using a standard browser.

> but it might be kind of neat to use whatever that trick is and
> make a professional looking install CD.  As far as installer
> tools for Windows go, I've been curious to check out the Nullsoft
> installer at http://nsis.sourceforge.net/  (of course, not
> having a Windows box kind of puts a damper on that ambition.)
> Anybody know anything about it?

"Damper on ambition", did you say? :) !!!

    Where have you been this last year???

We have been using the Nullsoft installer for the Windows
version of Axiom since December last year. What would you
like to know about it?

\start
Date: Wed, 19 Oct 2005 23:56:29 -0400
From: Bill Page
To: Eitan Gurari
Subject: RE: tex4ht and jsmath

Eitan,

On Saturday, October 15, 2005 2:05 PM you wrote:
> Bill Page wrote:
> > If I were to attempt to change the mathml.4ht config file
> > myself can you suggest some documentation/tutorial to get me
> > started quickly?
>
> Take a look at the literate source tex4ht-mathml.tex of
> mathml.4ht, available at the bugfixes distribution branch.

Thanks for the pointer to the source and documentation.

I took a look at this file but this sort of LaTeX coding is
way past my level of incompetence! I will be very happy if
or when you have time to modify it to create a jsmath mode! :)

In the meantime I did download and install Tex4ht on the
Axiom-developer web server to try to gain some understanding
of how to use it. I installed the Debian version:
'tex4ht_20050402.1817-1_i386.deb' from your web site.

I tried it in MathML mode on several files. Some are nearly
ok, i.e. they display properly in Firefox with only minimal
hand editing of a dozen misplaced <msub> </msub> start and
end tags. But our "acid test" - a pamphlet file called
'dhmatrix.spad.pamphlet', which can be processed by dvipdfm
to a good quality pdf file - fails quite miserably with many
oddly placed MathML tags ... :( As a result I gave up trying
to hand edit it to get the browser simply to parse the XML.

In fact of those TeX to HTML/MathML systems that I have tried
so far, Hevea, Tth, and Tex4ht; none have successfully processed
this file in a manner that I would judge to be acceptable to an
online reader.

So, for now I guess I remain stuff with making due with the
Acrobat browser plug-in.

\start
Date: 20 Oct 2005 07:43:14 +0200
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Aldor and Lisp
Cc: Peter Broadbery

Bill Page writes:

| On Wednesday, October 19, 2005 1:09 AM Gaby wrote:
| > 
| > My current work on designing and implementing a general,
| > efficient, scalable, complete representation of ISO C++ (with
| > concepts) in C++ has led me to look at the materials on proof
| > techniques in Axiom. I've read claims that Type:Type is
| > inconsistent with types-as-propositions stance.  I'm curious
| > to learn how the type/proof techniques in Aldor would get
| > away with that. 
| >
| 
| I think this is a very interesting question. It relates also
| to an email exchange a few weeks ago between Peter Broadbery,
| Ralf Hemmecke, Tim Daly, me and a few others concerning the
| structure of the upper levels of Axiom's type system.
| 
| http://lists.gnu.org/archive/html/axiom-developer/2005-09/msg00225.html
| 
| I think that our conclusion was (at least it was my view :) that
| Axiom's concept of Category as the type of Domain and Type as a
| Category is not implemented consistently in the current system.

Thank you very much for the links!  
Obvsiouly, I have not been paying enough attention to the axiom
mailing list traffic :-(

[...]

| Now specifically about the idea that "Type is a Type" might
| be inconsistent with types-as-propositions: I think that this
| is true only in the most restricted definition of what one
| means by a proposition. Certainly under this definition Type
| is too "large" to be a Set. But this does not mean that we
| cannot reason about it's properties using other formal methods,
| for example by means of equational logic in purely algebraic/
| co-algebraic terms. There is quite a large literature about
| equational proof methods.
| 
| Lately I have been reading the book "Vicious Circles: On the
| Mathematics of Non-Well-founded Phenomena" by Barwise and Moss.
| It seems clear that set theory based on the anti-foundation
| axiom (AFA) should, in principle provide formal proof methods
| for dealing with objects such as Aldor's Type. But I do not
| know of any specific research in this area. In addition, the
| book discusses the generalization of AFA to greatest fixed
| points, systems of equations, co-algebras and co-recursion
| which provide formal methods of reasoning about types such as
| streams, generators and iterators.

Funny we arrived to the same sources through totally different roads :-)
After we designed the IPR and decided that a type is an expression,
therefore has a type (which is itself), I was worried about its
soundness -- IPR is intended to support program static analysis and
semantics-based transformations where symbolic manipulations are keys
-- and arrived to the non-well-founded literature.  I've seen the
reference to "Vicious Circles" several times but did not get to read it.
I guess now is a good time.  Thanks for the wrapup.

| It seems plausible to me to suppose that a large part of the
| mathematical expressiveness of the Axiom and Aldor languages
| is due to the apparent non-well-foundedness of it's type
| system. In this sense non-well-foundedness is a good thing:
| it makes it seem more likely that Type is "large enough" to
| contain to "all of mathematics" (whatever we might want that
| to mean :).
| 
| I hope some of the contents of this email are useful to you
| and I look forward to hearing your views about Type:Type.

Sure your message is helpful and I will certainly send more comments
once I've made enough progress with the "problem" that appears to be
common to both Axiom/Aldor and IPR.

\start
Date: Thu, 20 Oct 2005 01:36:58 -0400
From: Eitan Gurari
To: Bill Page
Subject: RE: tex4ht and jsmath

 > I took a look at this file but this sort of LaTeX coding is
 > way past my level of incompetence! I will be very happy if
 > or when you have time to modify it to create a jsmath mode! :)

I'll provide a jsmath mode. Probably during the winter break.  Maybe
before that.

 > But our "acid test" - a pamphlet file called
 > 'dhmatrix.spad.pamphlet', which can be processed by dvipdfm
 > to a good quality pdf file - fails quite miserably with many
 > oddly placed MathML tags ... :( 

I got the xhtml+mathml code:

    http://www.cse.ohio-state.edu/~gurari/temp/ax.xml
    http://www.cse.ohio-state.edu/~gurari/temp/ax.pdf

Some visual problems need to be corrected, in particular for \eqno.

I made the following modifications to get the above outcome.

* Removed the 
     <<....>>
     ...
     @
  fragments, since I was not able to locate axiom.tex.

* Fixed in mathml.4ht

     \T<\a:mathml mtr>

  into

     \Tg<\a:mathml mtr>

* Added {\csname HCode\endcsname{}} before ^ in the following three formulas

      ${^{HAND}{\bf tv}}_{\bf x}$, 
      ${^{HAND}{\bf tv}}_{\bf y}$, 
      ${^{HAND}{\bf tv}}_{\bf z}$. 
      $${\bf Rot(k,\theta)} = {\bf Rot(^C{\bf z},\theta)}\eqno(1.60)$$ 

  As far as TeX is concerned, in all of the cases a base {} should have
  been included.  TeX4ht in many occasions has problems with empty bases
  because they don't show in the dvi code.  The code
  {\csname HCode\endcsname{}} works for TeX and TeX4ht.

* Replaced

      \begin{tabular}{ll} 
      vectors & {\bf v}, {\bf x1}, {\bf x} \\ 
      planes  & $\bigp$, $\bigq$ \\ 
      coordinate frames & {\bf I}, {\bf A}, {\bf CONV}\\ 
      \end{tabular}\\ 

   with 

      \begin{tabular}{ll} 
      vectors & {\bf v}, {\bf x1}, {\bf x} \\ 
      planes  & $\bigp$, $\bigq$ \\ 
      coordinate frames & {\bf I}, {\bf A}, {\bf CONV}\\ 
      \end{tabular}

   The extra \\ at the end is also inappropriate for LaTeX.

 > In fact of those TeX to HTML/MathML systems that I have tried
 > so far, Hevea, Tth, and Tex4ht; none have successfully processed
 > this file in a manner that I would judge to be acceptable to an
 > online reader.

Well, garbage in garbage out ;-)

  Wrong way to introduce text:   $${\rm {or\  as\ \ \ }} ... $$ 
  Wrong way to introduce 
         functions (sin, cos):   sin \theta &  cos \theta & 0 & 0\cr 
  Wrong way to emphasize math:   {\bf x}
  etc......

\start
Date: Thu, 20 Oct 2005 01:55:22 -0500
From: MathAction (billpage)
To: MathAction
Subject: [Axiom Documentation] 

You can find the working drafts of the new Axiom books (Volumes 1, 2,
3 and 4) here: "book--main--1":http://wiki.axiom-developer.org/book--main--1 .

\start
Date: Thu, 20 Oct 2005 02:34:28 -0500
From: MathAction (billpage)
To: MathAction
Subject: [Axiom Book] 

www.lulu.com's print-on-demand services I've been setting up
a way we can work on it.

Process

  There is a new way to review and edit the Book drafts on-line.
See "Accessing and Updating the Axiom Book Online" below.

How to work on the Axiom book.

  **From**::
    Tim Daly
    Sunday, November 28, 2004 1:48 AM

  There are various things that need to be cleaned up.

  *From::
    Tim Daly
    Sunday, November 28, 2004 2:51 PM
 
I think we might consider the CD rom as part of the first volume
which just does the introduction work (Dunstan's tutorial). From
this book the users would be able to install and run Axiom. The
CD rom would contain all of the volumes anyway so nothing is lost.
We could have this volume out in short order as it just involves
cutting down the material and packaging the CD. If we minimize
our royalties on this volume we could get the most penetration
of the market.

Please check with lulu.com about CD pricing.

A second volume devoted to programming, both interactive and library
would be useful. Some work would have to be done to write up more
details of the compiler. I expect this is the high profit volume.

A third volume of library reference information. This could be a
medium to high profit volume. Most programmers have a "completion
mania", meaning they need to have all volumes even if they never
use them.

Well, we could always include a coupon in the first book for a free CD.
They are not that hard to make.

Accessing and Updating the Axiom Book Online

  It is now possible to access and edit the source pamphlet
files for the Axiom book volumes on-line throught the web
in the same way that other pages on this web site are edited.

At "book--main--1":http://wiki.axiom-developer.org/book--main--1
you will see a list of volumes of the draft of new Axiom book.
When you click on a volume the first page will be displayed in
graphic format. Click on 'pdf' or 'dvi' to access the full
document.

If you would like to comment on the text, please type your
message at the bottom of the page, the way you would on any
other page of this web site.

If you want to make improvements to the text, first you must
idendify yourself by clicking 'preferences' and entering your
name and email address. Then return to the document page and
click 'edit'. You many not edit the source text of the document.
When you click 'Save', the modified text will be automatically
processed by Latex and converted to the standard display
formats.

Changes made to these draft documents will be periodically
reviewed and applied to the final draft versions stored in
the archive..

Instructions for Access to Archive
 
  If you already have 'tla' installed skip to the next section.

More details are availabe at ArchUsage.

Getting started with tla:

**Use tla to get the contents of any archive on
axiom-developer.org**

If you already have set up your tla identity skip to the next
section::

Use tla to get the Book

  'tla get book--main--1'
 
Building the book

  To change the book you have three choices. If you do not
have write permission to the main book archive, you can
still edit the draft volumes as described previous. Or you
can send patches as follows::

++added:

  **From**:
  Bill Page
  Sunday, November 28, 2004 2:01 PM

  It would be nice if we could figure out a way to get lulu.com
  to either create and ship CDs with the book or possibly just
  ship CDs we make for them. I don't see anything on their site
  about it but it's always fun to be the first, right?

I would like to hear more from subscribers to axiom-developer

++added:
Background

  Here is a summary of the first few emails that initiated this project.
See the section titled **Process** below for a detailed discussion
of the process that we plan to use to produce the final draft publication.

**From**::

  Bill Page
  Thursday, November 25, 2004 8:04 PM

Have you heard about Lulu, the new "print on demand" book
publishers? They are for real and quite serious. I have a
friend who is publishing some very serious physics monographs
this way. Just to get an idea, see his books here:

http://people.lulu.com/users/index.php?fHomepage=42530

See more about Lulu at the end of this email.

Anyway, so here is my idea:

I think the Axiom Foundation should publish the book that Tim
Daly has recently finished updating and revising:
"AXIOM - The 30 Year Horizon":http://page.axiom-developer.org/zope/Plone/refs/books/axiom-book2.pdf

This book is the essential replacement for the original book:
"AXIOM - The Scientific Computation System"
by Richard Jenks and Robert Sutor and published by the
Numerical Algorithms Group, in Springer-Verlag, (c) 1992.

The new book weighs in at over 1000 pages and a dauntingly big
download and print job of anyone! But Lulu to the rescue...
Now anyone can order a convenient printed copy of the book
for a very reasonable price.

The Axiom Foundation (with Tim's and possibly NAG's approval
of course) could offer the new book for sale through Lulu.
Profits from the sale of the book could go to help fund the
Axiom Foundation initiatives that we have only just begun
to consider such as Bounty incentives for Axiom development
work.

Based on the cost and commission figures at:
http://www.lulu.com/static/on-demand-books2.php

I think that setting a price of say $50 per book (quantity 1)
could yield a net royalty of about $20 for each book sold.
This could help promote Axiom is more than one way at the
same time.

Now, that is not all! Lulu now also sells software. (See more
below.)

So, the Foundation could also use Lulu to offer Axiom CDrom
"boxed sets" for end-user installation. Ok, so maybe that is
a bit premature right now, but I think we will get to that
stage pretty soon now.

(Does all this sound like a "too-good-to-be-true" sales pitch?
maybe I am getting just a little too enthusiastic, but I do
think that this might work.

 
-  http://www.lulu.com/static/pr/11_03.php

-  http://www.lulu.com/static/on-demand-books1.php

**From**::

  Page, Bill
  Friday, November 26, 2004 9:47 AM

Members, et al.

Ok in my official capacity as Secretary to the Foundation, since
both Tim Daly and NAG (aka Mike Dewar) apparently agree to the
idea of publishing the new Axiom book at http://www.lulu.com ,
I would like to seek approval from the members of the Axiom
Foundation to proceed with making the necessary arrangements.

Would the members please let me know at least *positive* or
*negative* as soon as you get a chance? Thanks.

... And of course I was wondering if there were any volunteers
who would like to step forward to help me with doing this? :))

One issue that will have to be decided is what price to attach
to the sale of the book. I did a quick calculation based on
a size of 1000 pages and a royalty of $20 based on the information
at

- http://www.lulu.com/static/on-demand-books2.php

and I got a price of just under $50 per single copy. The
Foundation would recieve $20 from each sale. Does that sound
reasonable? Do you think I did the calculation correctly?

**From**::

  Mike Dewar
  On Friday, November 26, 2004 5:17 AM

I don't think that NAG would object, provided that the terms
of the license were complied with (which is only that the copyright
notices and license text appear in the book, e.g. on the same page
as the Library of Congress/ISBN metadata).

I would also hope that the original contributors, particularly the
principle authors Dick Jenks and Bob Sutor, were acknowledged in
an appropriate way.

**From**::

  Tim Daly wrote:
  On Thu, Nov 25, 2004 at 09:15:32PM -0500
 
Not a bad idea, actually.

The book is partially composed of text released under the
Modifed-BSD license, partially composed of some text by
Martin Dunstan (the tutorial), who gave me permission to use
and freely republish it under the Modified-BSD.

The picture on the front (Blue Bayou) is by Jocelyn Guidry
(http://www.jocelynguidry.com) and I have her permission to freely
distribute it under the Modified-BSD.

The rest of the text, including composing it into tex, typesetting
the equations, etc. was written by me and I give the same permission
to use work under the Modified-BSD.

Of course, the graphics chapter needs work as does the 
cross reference
information in the back.  There is no such thing as a simple job.
 
Perhaps we could even cut a deal with the cheap CD place to include
a CD with Axiom on it. 

**From**::

  Bill Page
  Friday, November 26, 2004 11:15 AM

One thing we should seriously consider I think is to
purchase an ISBN (International Standard Book Number)
for the new Axiom book. See:

http://www.lulu.com/services/isbn.php

This is important because I can seriously imagine that
some universities *might* be interested in using the
Axiom book in a course on Computer Algebra and although
the book will still be available for free downloading
I expect that most university book stores would prefer
to be able to order copies of the book through the usual
channels.

What do you think?

**From**::

  Tim Daly
  Friday, November 26, 2004 5:22 PM

I read the ISBN section and it seems reasonable. Before we order one
we should probably be sure we have a printable book worth buying.

Some work needs to be applied to make the book "publication ready".
I'll create a axiom--book--1 branch so we can work on it. 

We need to :

* know what format they accept 

* look at how cover art

* work on an index

* work on chapter 8 (graphics)

* work on the algebra reference information

**From**::

  Tim Daly
  Friday, November 26, 2004 5:28 PM

There isn't an ISBN/Metadata page at the moment but there will be.
We'll add the license terms there as well as a statement that 
copyright
resides with the original holders (rather redundant but why not?).

Currently all of the original authors are listed on the cover, plus
Martin Dunstan (the tutorial section) and Jocelyn Guidry (the artist).

It's been policy to give credit to all contributors so any additional
people who work on the book would be added to that list.
[118 more lines...]

This all sounds fascinating and I wish you the best of luck with
the project. It's nice to see that the old book still has life to
it and is living on and evolving.

\start
Date: Thu, 20 Oct 2005 02:47:18 -0500
From: MathAction (billpage)
To: MathAction
Subject: [AxiomGraphics] 

Graphics in Axiom

The graphics commands are described in Chapter 7 of the AxiomBook.
The syntax is::

graph here . But we can still extract the graph data from the view

++added:

Obsolete Instructions

  You need the latest version of Axiom from the Savannah CVS::
 
    cd /tmp                     <-- or someplace where you want axiom
    export CVS_RSH=ssh
    cvs -z3 -d:ext:anoncvs@savannah.gnu.org/cvsroot/axiom co axiom
    cd axiom
    export AXIOM=/tmp/axiom/mnt/linux
    export PATH=$AXIOM/bin:$PATH
    make
    .... (get coffee)
    sman  (lots of warnings but the axiom interpreter should start)
    draw(sin(x), x=-10..10)
    draw(sin(x*y), x=-10..10, y=-10..10)
 
The sman process will eventually be merged into the axiom command
as soon as I finish up the graphics integration. The sman (superman)
process is used to communicate between the axiom interpreter and the
graphics process. If you just start axiom directly with the axiom
command rather than the sman command the draw function won't 
do anything.

  -- or --

You need the latest version of Axiom from the arch website::
 
  cd /tmp                     <-- or someplace where you want axiom
  tla get axiom--main--1 axiom
  cd axiom
  export AXIOM=/tmp/axiom/mnt/linux
  export PATH=$AXIOM/bin:$PATH
  make
  .... (get coffee)
  sman  (lots of warnings but the axiom interpreter should start)
  draw(sin(x), x=-10..10)
  draw(sin(x*y), x=-10..10, y=-10..10)
 
The sman process will eventually be merged into the axiom command
as soon as I finish up the graphics integration. The sman (superman)
process is used to communicate between the axiom interpreter and the
graphics process. If you just start axiom directly with the axiom
command rather than the sman command the draw function won't 
do anything.

\start
Date: Thu, 20 Oct 2005 04:29:31 -0400
From: Bill Page
To: Eitan Gurari
Subject: RE: tex4ht and jsmath

On Thursday, October 20, 2005 1:37 AM you wrote:
>
> I'll provide a jsmath mode. Probably during the winter break.
> Maybe before that.

Thanks!

>
>  > But our "acid test" - a pamphlet file called
>  > 'dhmatrix.spad.pamphlet', which can be processed by dvipdfm
>  > to a good quality pdf file - fails quite miserably with many
>  > oddly placed MathML tags ... :(
>
> I got the xhtml+mathml code:
>
>     http://www.cse.ohio-state.edu/~gurari/temp/ax.xml
>     http://www.cse.ohio-state.edu/~gurari/temp/ax.pdf
>

Very Nice! - By far the best MathML result I have seen so far!

But maybe it's a bit shocking though that the MathML result
is nearly twice the size of the pdf file. :( Well, I guess
I knew that MathML was verbose ...

> Some visual problems need to be corrected, in particular for
> \eqno.

I think that's a macro in axiom.sty?

>
> I made the following modifications to get the above outcome.
>
> * Removed the
>      <<....>>
>      ...
>      @
>   fragments, since I was not able to locate axiom.tex.
>

These fragments are the 'noweb' source code markups that are
normally handled by the 'noweave' preprocessing which produces
pure LaTeX output. Editing this by hand is ok for this test but
noweave will also generate some extra LaTeX coding that will be
inserted before processing by 'latex'.

> * Fixed in mathml.4ht
>
>      \T<\a:mathml mtr>
>
>   into
>
>      \Tg<\a:mathml mtr>
>

This was a bug and patch to tex4ht, right?

When you have time, could you also look at the result of
processing the 'tex' from the following page:

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

(right-click, save-as on the 'tex' link). This is the example
where I found many occurrences of </msub>...<msub> with improper
start and end tags. Does that also happen to you?

> * Added {\csname HCode\endcsname{}} before ^ in the following
> three formulas
>
>       ${^{HAND}{\bf tv}}_{\bf x}$,
>       ${^{HAND}{\bf tv}}_{\bf y}$,
>       ${^{HAND}{\bf tv}}_{\bf z}$.
>       $${\bf Rot(k,\theta)} = {\bf Rot(^C{\bf
> z},\theta)}\eqno(1.60)$$
>
>   As far as TeX is concerned, in all of the cases a base {}
> should have been included.  TeX4ht in many occasions has
> problems with empty bases because they don't show in the dvi
> code.

Ah I see, like this ${{}^{HANB} ... $

> The code {\csname HCode\endcsname{}} works for TeX and TeX4ht.

What does this code do? (Do I need to know? :) It looks very
contrived as a synonym for {}.

>       coordinate frames & {\bf I}, {\bf A}, {\bf CONV}\\
>       \end{tabular}\\
> ...
>    The extra \\ at the end is also inappropriate for LaTeX.
>
> Well, garbage in garbage out ;-)
>
>   Wrong way to introduce text:   $${\rm {or\  as\ \ \ }} ... $$
>   Wrong way to introduce
>          functions (sin, cos):   sin \theta &  cos \theta & 0 & 0\cr
>   Wrong way to emphasize math:   {\bf x}
>   etc......
>

Well, please define "wrong way" - latex and dvipdfm swallowed all
that with out a complaint. I will agree that the contents of the
file is a little crufty, but certainly no worse that a code of LaTeX
coding I have seen.

Besides a stronger discipline, how can we insure that our LaTeX
coding meets certain minimum standards so that it doesn't cause
the conversion programs to barf? Do you know of any sort of 'lint'
program for LaTeX that could detect and warn about the "wrong way"
of doing things?

\start
Date: Thu, 20 Oct 2005 05:00:47 -0400
From: Bill Page
To: Tim Daly
Subject: RE: debugging information

On Wednesday, October 19, 2005 8:24 PM you wrote:
> ...
> There is much work to be done and I have no time estimate.
> Documentation is vital and good documentation takes much
> longer than anyone expects.

Understood. "takes longer that anyone wants to admit", too
I think.

> I'm looking into parts of the system and have decided to
> write some debugging techniques and documentation on
> writing pamphlet files so most of my effort is going
> into volume 4.

Sounds good to me.

>
> We can try putting the volumes online. Provided they still
> retain their pamphlet format (ie latex) I think it's a
> reasonable idea.

Yes, the pamphlet files on MathAction now have **exactly**
the same format as in the source code distribution (latex,
noweb markup and code).

You can access the volumes on-line here:

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

Clicking on a volume displays it's first page (in png graphics
format). You can click on either the

 'pdf' or 'dvi' links to view or download the full document

 'src' for the full pamphlet source

 'tex' for the output of noweave

 'log' for the contents of the LaTeX log file

and on pamphlet files that contain code chunks you can also
select a chunk name and click

 'tangle' to extract the code

For example of pamphlets with source code see:

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

Please let me know what you think of this approach.

> I'm a little concerned about changes that would use things
> like structured text, html, or other non-latex information
> in the files. Those are fine for the wiki but not for the
> system files, of which the book volumes are the cornerstone
> in my mind.

I agree.

>
>   Vol 5: Categories, Domains, and Package Internals
>   Vol 6: The compiler
>   Vol 7: The interpreter
>   Vol 8: The algebra
> ...
> The system would be built from the books.
>

Great.

> Eventually modifying Axiom becomes a job of authoring or
> editing a section of one of the volumes.
>
> I have a bit of machinery already (due to David Mentre)
> that extends the pamphlet idea to "booklets". etc.
> We can create our own protocols as needed.
>

I don't see any problem implementing that but I think we should
look carefully at what doing this implies for the eventual
structure of the Axiom code and documentation. More and more
these days I think we need to shift to a more dynamic and
richer model for source code then just the relatively static
literate program document. I think one way to work towards this
is through web-based services like we are building on the Axiom
wiki. So instead of a "dead" book, a complex program becomes a
dynamically changing web site, freely mixing source code and
documentation; and allowing fast and efficient navigation,
multiple "crystal" views of the same pages in different contexts
etc.

> >
> > I wonder if there is anyone out there who would like to take
> > on the task to prepare such a CD? I could help but I don't
> > want to lead the effort.
>
> I can look into the installable CDRom issue.
> I've already built iso images for ISSAC.
>

Well, as usual you are pretty busy and your time might best be
spent other ways but ... Anyway, lets try to plan to get it out
"before Christmas", ok? :)

\start
Date: Thu, 20 Oct 2005 11:21:58 +0200
From: Martin Rubey
To: Cliff Yapp
Subject: Re: Singular

 > > In this vein, getting into contact with Singular is one of the best things
 > > that could happen to us.
 > 
 > Agreed.  But unless I'm misunderstanding something I don't think
 > mathematical developments with the Singular team need wait on compiler
 > issues?

No, not at all.

 > > A second community, that is *huge* and were several people are interested
 > > in contact is R. By coincidence, the sit in Vienna, and I'm at the
 > > institute of statistics currently. So I guess, this is my job. I'll post a
 > > message, I think.
 > 
 > Sounds good!  My recollection is that R is a largely numerical tool - 

yes

 > are you thinking it would make a good replacement for the NAG libraries?

no, it's something entirely different. It's all about statistics.

\start
Date: Thu, 20 Oct 2005 11:52:39 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Aldor and Lisp

Page, Bill writes:
 > On Wednesday, October 19, 2005 4:40 AM Martin Rubey wrote:

 > > > > It is notable I think, that the original Axiom developers chose to
 > > > > re-implement SPAD as Aldor (written in C) rather than continue to make
 > > > > improvements to SPAD.

 > > I'm absolutely certain that the reason for this was rather a political
 > > than a technical one.
 > 
 > Could you explain what makes you absolutely certain of this?  Can you cite
 > any references to Axiom or Aldor literature?

Well, disclaimer: *I* am absolutely certain. This does still not mean that it's
true. I don't have any references.

 > In what sense was it "political"? Who stood to gain by such a decision?

At that time, Axiom and Aldor were commercial products, and Lisp was said to be
slow and Axiom had a reputation of being so slow, close to being unusable.

 > To me the technical reasons seem rather obvious. So please forgive me if I
 > seem rather skeptical.

Citing Renaud:

> I was quite disappointed with Aldor, the main interest was the ability to
> produce fast code by compiling to C and using the latest bignum libraries,
> when I went at NAG to port the real closure in Aldor the efficiency gain was
> quite low just a factor of 1.5 to 2.5 ... I think that will be much reduced
> for current versions of axioms since gcl is able to produce efficient code
> and it also uses recent versions of gmp.

\start
Date: Thu, 20 Oct 2005 11:45:22 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: tex4ht and jsmath
Cc: Eitan Gurari, list

Dear Bill, Dear Eitan,

Page, Bill writes:
 > Eitan
 > 
 > On Thursday, October 20, 2005 1:37 AM you wrote:
 > > 
 > > I'll provide a jsmath mode. Probably during the winter break.  Maybe
 > > before that.

This would be wonderful!

 > But maybe it's a bit shocking though that the MathML result is nearly twice
 > the size of the pdf file. :( Well, I guess I knew that MathML was verbose
 > ...

Oh dear. This is really true? Would this be better with jsMath? Alternatively,
is it possible to compress MathMl on the fly -- I heard that "it compresses
very well :-)" ?

 > > * Added {\csname HCode\endcsname{}} before ^ in the following 
 > > three formulas
 > > 
 > >       ${^{HAND}{\bf tv}}_{\bf x}$, 
 > >       ${^{HAND}{\bf tv}}_{\bf y}$, 
 > >       ${^{HAND}{\bf tv}}_{\bf z}$. 
 > >       $${\bf Rot(k,\theta)} = {\bf Rot(^C{\bf 
 > > z},\theta)}\eqno(1.60)$$ 
 > >
 > >   As far as TeX is concerned, in all of the cases a base {} should have
 > > been included.  TeX4ht in many occasions has problems with empty bases
 > > because they don't show in the dvi code.
 > 
 > Ah I see, like this ${{}^{HANB} ... $
 > 
 > > The code {\csname HCode\endcsname{}} works for TeX and TeX4ht.

So ${{}^{HANB} ... $ would not work for tex4ht? This seems like a problem for
me. 

 > >    The extra \\ at the end is also inappropriate for LaTeX.
 > > 
 > > Well, garbage in garbage out ;-)
 > > 
 > >   Wrong way to introduce text:   $${\rm {or\  as\ \ \ }} ... $$ 
 > >   Wrong way to introduce 
 > >          functions (sin, cos):   sin \theta &  cos \theta & 0 & 0\cr 
 > >   Wrong way to emphasize math:   {\bf x}
 > >   etc......
 > 
 > Well, please define "wrong way" - latex and dvipdfm swallowed all that with
 > out a complaint. I will agree that the contents of the file is a little
 > crufty, but certainly no worse that a code of LaTeX coding I have seen.
 > 
 > Besides a stronger discipline, how can we insure that our LaTeX coding meets
 > certain minimum standards so that it doesn't cause the conversion programs
 > to barf? Do you know of any sort of 'lint' program for LaTeX that could
 > detect and warn about the "wrong way" of doing things?

I think that chktex does this:

http://baruch.ev-en.org/proj/chktex/

it issues warnings about possible typographical errors.

On the other hand, we could simply say: a proper pamphlet file is a file that
is correctly processed by latex and tex4ht. :-)

\start
Date: Thu, 20 Oct 2005 14:43:26 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: debugging information

I'd just like to say THANK YOU for your great job on MathAction!

Page, Bill writes:

 > You can access the volumes on-line here:
 > 
 > http://wiki.axiom-developer.org/book--main--1
 > 

\start
Date: Thu, 20 Oct 2005 06:47:43 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Tim Daly
Subject: RE: debugging information

> On Wednesday, October 19, 2005 10:28 PM C Y wrote:
> > 
> > One comment - the algebra volume could wind up containing a really
> > really large amount of data.  Perhaps after 5, 6, and 7 have been
> > tackled we should look at breaking down the algebra into more 
> > manageable chunks?
> 
> I agree completely. At something like 10,000 pages I seriously
> doubt that anyone with an environmental conscience would dare to
> print it or even order the volumes! In fact I doubt that most
> people would be that interested in printed material after the
> first tutorial and programming guide. These days when it comes
> to printed material **smaller** is better. The rest of the stuff
> just stays on the CDrom (or web site) just in case you might want
> to take the time to look at it.

Well, I guess I view it as being kind of like the Oxford Unabridged
Dictionary - most mere mortals might not want one, but libraries and
archival institutions might be interested.  Paper is a LOT more durable
than any electronic technology, and we just might be creating something
here worth preserving for the long haul.  Of course, as a living
project any one "snapshot" will be out of date, but we may reach some
"stable" point where the core supporting technology is clear and well
documented, at which point it might be worth making the effort to
preserve it.

Also, if the program is a document, I find it easier to read documents
in print than on an electronic screen.  I might never read ALL the
documentation associated with the entire Axiom system, but it would be
a nice reference to have some day.

> So when it comes to publishing hardcopy, I think we should be
> quite selective - at least at first. Lulu is "print on demand"
> so creating material is no problem - just extra work with
> perhaps little payoff.

Well, I don't know how much extra work it would be, really - after all
we want to be able to generate nice pdfs, dvis, what have you and from
pdf to printed book doesn't seem like TOO huge a step.

> > Awesome!  So a set of printed volumes of Axiom books would not
> > be simply a document but actually define the entire system, in
> > all its detail, from implementation to mathematics to user
> > interface! 
> 
> But this will never work. Paper is just too awkward a media to
> maintain a "crystal" system of this size. Of course I am just
> promoting my own approach with MathAction, but I seriously doubt
> that we can realistically continue to maintain Axiom unless we
> can solve the problem of really *collaborating* over the Internet.

I'm not advocating the paper copy be any kind of living tie to the
project - its just that paper is a much better long term storage
mechanism.  (Good paper anyway.)  I suppose its a small concern, but
one of the things I like to think about is how to preserve information
over long periods of time.  (Curiously enough, it might be that metal
punch cards would be the most viable long term way to store digital
information - they have the lowest technological hurdle to accessing
them, and can be made physically robust.)

> > Depending on how much effort gets put into the algebra over the
> > years Axiom might become a virtual encyclopedia of mathematics,
> > at least mathematics at or above the level of that comprising the
> > foundation of Axiom.
> 
> Useless in my opinion unless it can be made to be very easily
> accessible online.

Oh, agreed.  I'm thinking about another aspect of this all together,
one I agree won't interest most people.

> > Just curious - are you talking about the auto-install CDs like
> > Mathematica has that you just pop in the disk and it starts up
> > the install wizard?
> 
> Auto-install on windows is a piece of cake - just a couple of
> extra files on the CD.

Ah, good :-).

> Something similar is possible on some versions of linux, but
> usually linux people it isn't worth it since they want to know
> exactly what it is doing anyway. For linux there is at least
> RPM (see new files in AxiomDownload page) and Debian apt-get
> (which can be made to read from CDrom).

Sounds good.
 
> "Damper on ambition", did you say? :) !!!
> 
>     Where have you been this last year???
> 
> We have been using the Nullsoft installer for the Windows
> version of Axiom since December last year. What would you
> like to know about it?

<<turns bright red>> I knew that!  Er, well, I sure should have.  I
guess I was thinking we might be able to whip up some custom graphics
and such and make it real jazzy, but that's a completely petty
ambition.  I'll have to find a Windows box somewhere and try it out!

\start
Date: Thu, 20 Oct 2005 16:15:19 +0200
From: Gregory Vanuxem
To: list
Subject: FramedNonAssociativeAlgebraFunctions2

I don't know if it's false but in FramedNonAssociativeAlgebraFunctions2

    Implementation ==> add
      map(fn : R -> S, u : AR): AS ==
        rank()$AR > rank()$AS => error("map: ranks of algebras do not fit")
        vr : V R := coordinates u
        vs : V S := map(fn,vr)$VectorFunctions2(R,S)
        rank()$AR = rank()$AR => represents(vs)$AS
        ba := basis()$AS
        represents(vs,[ba.i for i in 1..rank()$AR])


rank()$AR = rank()$AR => represents(vs)$AS

has may be to be changed to:

rank()$AR = rank()$AS => represents(vs)$AS

\start
Date: Thu, 20 Oct 2005 10:19:35 +0200
From: Christian Aistleitner
To: Martin Rubey
Subject: Re: Aldor and Lisp
Cc: Camm Maguire, Peter Broadbery

> great that you pop in -- you are not at RISC-Linz anymore, are you?

currently, i am still at RISC.

>  > I wrote that parser almost 1.5 years ago (I guess). I still have it  
> on some
>  > Backup if someone is interested. It was implemented in Aldor. I could  
> parse
>  > all source files I tested.
>
> This is great news! I suppose, however, that it parses only the nopile  
> syntax,
> doesn't it?

You are perfectly right. My parser cannot parse piles. I do not know about  
Axiom, but in Aldor, piles are typically not used. I am not a fan of them  
either. Therefore I neglected piles, as they meant too much work for  
something that is never used. If you want to use piles, you would  
definitely have to apply changes in at least the scanner.

\start
Date: Thu, 20 Oct 2005 10:56:29 +0200
From: Christian Aistleitner
To: Bill Page, Martin Rubey
Subject: Re: Aldor and Lisp

>> [Aldor Parser in Aldor]
> An Aldor parser written in Aldor?! I did not receive the rest
> of the background of this email, but it certainly sounds
> interesting. Could you forward a copy to the email list?

i do not want to mess up the mailing list with public posting of binary  
files. However I sent the Parser in a private mail to you. Everybody who  
wants to see the code, is more than welcome to drop me a private mail.

>> > However, the code is more or less worthless, as it is _not_
>> > properly documented.
>>
>> I disagree slightly :-)
>>
>
> I disagree completely. I think an Aldor parser written in Aldor
> is would be very worthwhile. If you make it available on the
> web, then we can help document it.

I have to admit that I am a bit paranoid about pulishing things on the  
web. And I suggest you take a look at the code first.

However I am completely overwhelmed by the momentum of this mailing list.  
I wish the Aldor people had that much energy and manpower to share :)

\start
Date: Thu, 20 Oct 2005 13:43:32 +0200
From: David Mentre
To: Bill Page
Subject: Re: debugging information

2005/10/20, Page, Bill Bill Page:
> For example of pamphlets with source code see:
>
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra
>
> Please let me know what you think of this approach.

It would be nice and very useful (think Google indexing) to have the
content of the books available as HTML. Maybe it is already done and I
haven't seen it?

\start
Date: Thu, 20 Oct 2005 11:00:22 -0400
From: Tim Daly
To: Bill Page
Subject: online algebra files

I just saw the page
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FrontPage

This ROCKS! Nice work.

Being able to create/update axiom online would be great because it
would make the modification task "embarrassingly parallel" in most
aspects. It will, of course, make my life of integrating it all a
living hell but it would be worthwhile anyway.

There are still a lot of "quality" tasks that go on behind the scenes.
I document changes, update the CHANGELOG, rebuild from scratch, hand
check the testcase output, cross-build on various platforms, and
"round-trip" the changes (checkin, erase, checkout, rebuild, retest)
before release. And finally the release gets pushed to all three
archives (arch, savannah, sourceforge).  I don't see how these tasks
can be performed in parallel. I do feel they are necessary to make
sure the quality stays high. Every step is there because it eliminates
some problem that has bitten me in the past.

We need to think about ways to merge a web-based changes to the
official archive. How do you see this happening? Would it be 
possible to do a 

  diff -Naur archive.version web.version >web.version.patch

for changed files? The "diff -Naur old new" is my primary tool.

\start
Date: Thu, 20 Oct 2005 11:17:59 -0400
From: Bill Page
To: Cliff Yapp
Subject: Ocaml, Coq, and ACL2
Cc: Camm Maguire, list

On Wednesday, October 19, 2005 9:52 AM C Y wrote:
> ...
> With apologies to Camm, there is one sense in which arriving at
> ocaml is neither full circle nor unattractive, and that is the
> coq theorem prover.  If there is indeed serious interest in
> backing Axiom with a powerful theorem prover, COQ is definitely
> up there on the list of candidates.  In fact, some work was done
> in France a while back on coq+Axiom - as yet I have not yet
> located a copy of that thesis, unfortunately.

I already have Ocaml and Coq running on the axiom-developer.org
server. If there is some interest, it would not be difficult for
me to provide:

\begin{ocaml}
...
\end{ocaml}

and

\begin{coq}
...
\end{coq}

on MathAction to allow these to be accessed through the web
like {axiom} {spad} {aldor} and {reduce}. This would not
provide axiom/coq integration as such, but at least it would
provide the possibility of exhibiting a coq proof along with
some Axiom code should an author wish to do that.

> I think I posted here about it and got no response.

I am definitely interested by lack time right now to do
anything serious.

> ...
> I know the interest in this topic is spotty, but this is the
> time and place to raise the question - if we DO want to be
> able to back Axiom with formal provers, what are the design
> considerations that need to be taken into account?  What
> precisely will the prover be used to do, how would we interact
> with it, and how would we store and use the results?

As you know, I am rather put-off by just "talking" about doing
these things. Since quite a lot of code is freely available and
easily accessed, I would prefer to just to dig-in and work/play
with one or more of these tools ... then, maybe later, decide on
which might be best and what if anything we really want to do
with Axiom and theorem proving software.

The "other" proof system is obviously of interest would be ACL2.
Camm and some of the other lisp developer have a good connection
to that project and so if we were to work with ACL2 and Axiom,
I think we could expect a lot of support.

So far I have not installed ACL2 on the axiom-developer server
yet, but if even one other person says they are interested then
I would be glad to do that and also make in available on MathAction
via

\begin{acl2}
...
\end{acl2}

\start
Date: Thu, 20 Oct 2005 17:30:29 +0200
From: Martin Rubey
To: Gregory Vanuxem
Subject: Re: FramedNonAssociativeAlgebraFunctions2

Thank you for finding this bug! Do you actually use one of the related =
domains?
If yes, you will become the maintainer :-)

Could you please

* file an issue on MathAction -- ideally showing an example where the m=
istake
  leads to an unintended result

  (category: Axiom Library, fix proposed, normal)

* produce a patch and send it to Tim and include it into the issue abov=
e.

Thank you,

Martin

Vanuxem Gr=E9gory writes:
 > Hi,
 >
 > I don't know if it's false but in FramedNonAssociativeAlgebraFunctio=
ns2
 >
 >     Implementation ==> add
 >       map(fn : R -> S, u : AR): AS ==
 >         rank()$AR > rank()$AS => error("map: ranks of algebras do =
not fit")
 >         vr : V R := coordinates u
 >         vs : V S := map(fn,vr)$VectorFunctions2(R,S)
 >         rank()$AR = rank()$AR => represents(vs)$AS
 >         ba := basis()$AS
 >         represents(vs,[ba.i for i in 1..rank()$AR])
 >
 >
 > rank()$AR = rank()$AR => represents(vs)$AS
 >
 > has may be to be changed to:
 >
 > rank()$AR = rank()$AS => represents(vs)$AS

\start
Date: Thu, 20 Oct 2005 10:50:33 -0500
From: MathAction (anonyme)
To: MathAction
Subject: [#222 FramedNonAssociativeAlgebraFunctions2 and map] (nouveau) 

I don't know if it's false but in FramedNonAssociativeAlgebraFunctions2::

    Implementation ==> add
      map(fn : R -> S, u : AR): AS ==
        rank()$AR > rank()$AS => error("map: ranks of algebras do not fit")
        vr : V R := coordinates u
        vs : V S := map(fn,vr)$VectorFunctions2(R,S)
        rank()$AR = rank()$AR => represents(vs)$AS
        ba := basis()$AS
        represents(vs,[ba.i for i in 1..rank()$AR])

rank()$AR = rank()$AR => represents(vs)$AS

has may be to be changed to:

rank()$AR = rank()$AS => represents(vs)$AS

\start
Date: Thu, 20 Oct 2005 10:53:19 -0500
From: MathAction (greg)
To: MathAction
Subject: [#222 FramedNonAssociativeAlgebraFunctions2 and map] 

        rank()\$AR > rank()\$AS => error("map: ranks of algebras do not fit")

        vs : V S := map(fn,vr)\$VectorFunctions2(R,S)
        rank()\$AR = rank()\$AR => represents(vs)\$AS
        ba := basis()\$AS
        represents(vs,[ba.i for i in 1..rank()\$AR])

rank()\$AR = rank()\$AR => represents(vs)\$AS

rank()\$AR = rank()\$AS => represents(vs)\$AS

\start
Date: Thu, 20 Oct 2005 17:45:46 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Ocaml, Coq, and ACL2

I'd just like to add that Renaud Rioboo is working on Focal, which seems to be
exactly what Cliff Yapp is looking for. However, it is (and will stay)
disconnected from Axiom.

As far as I know it is based on Coq and Ocaml. See

http://focal.inria.fr/site/manual.html

I have no idea in what sense a theorem prover would be useful in a
CAS-context. Maybe Bruno Buchberger has some answers:

http://www.risc.uni-linz.ac.at/research/theorema/description/

\start
Date: Thu, 20 Oct 2005 18:10:55 +0200
From: Gregory Vanuxem
To: Martin Rubey
Subject: RE: FramedNonAssociativeAlgebraFunctions2

> -----Message d'origine-----
> Dear Greg,
>
> Thank you for finding this bug! Do you actually use one of the
> related domains?
> If yes, you will become the maintainer :-)
>
> Could you please
>
> * file an issue on MathAction -- ideally showing an example where
> the mistake
>   leads to an unintended result

I filed an issue but no patch since I'm not sure.

Cheers,

Greg

>   (category: Axiom Library, fix proposed, normal)
>
> * produce a patch and send it to Tim and include it into the issue abov=
e.
>
> Thank you,
>
> Martin
>
> Vanuxem Gr=E9gory writes:
>  > Hi,
>  >
>  > I don't know if it's false but in FramedNonAssociativeAlgebraFunctio=
ns2
>  >
>  >     Implementation ==> add
>  >       map(fn : R -> S, u : AR): AS ==
>  >         rank()$AR > rank()$AS => error("map: ranks of algebras
> do not fit")
>  >         vr : V R := coordinates u
>  >         vs : V S := map(fn,vr)$VectorFunctions2(R,S)
>  >         rank()$AR = rank()$AR => represents(vs)$AS
>  >         ba := basis()$AS
>  >         represents(vs,[ba.i for i in 1..rank()$AR])
>  >
>  >
>  > rank()$AR = rank()$AR => represents(vs)$AS
>  >
>  > has may be to be changed to:
>  >
>  > rank()$AR = rank()$AS => represents(vs)$AS

\start
Date: Thu, 20 Oct 2005 09:24:56 -0700
From: Bob McElrath
To: Tim Daly
Subject: Re: online algebra files

root [Tim Daly] wrote:
> Bill,
> 
> I just saw the page
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/FrontPage
> 
> This ROCKS! Nice work.

Ok that is cool.

A few (very obvious) directions for future work...I wish I had more
time...
1) HTML instead of images
2) Fill in abstracts for each domain
3) Disable comments on these pages.  (Or, organize them differently...we
surely don't want to be appending comments to the source code!)

\start
Date: Thu, 20 Oct 2005 09:26:40 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Bill Page
Subject: Re: Ocaml, Coq, and ACL2

> I'd just like to add that Renaud Rioboo is working on Focal, which
> seems to be exactly what Cliff Yapp is looking for. However, it is 
> (and will stay) disconnected from Axiom.

Neat!

> As far as I know it is based on Coq and Ocaml. See
> 
> http://focal.inria.fr/site/manual.html

I'll add that to my reading list.

> I have no idea in what sense a theorem prover would be useful in a
> CAS-context. Maybe Bruno Buchberger has some answers:
> 
> http://www.risc.uni-linz.ac.at/research/theorema/description/

I've seen a couple efforts along those lines scattered around, but I
haven't taken the time to study them in depth.  Guess I should do that
before anything else.

\start
Date: Thu, 20 Oct 2005 09:33:56 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: Re: Ocaml, Coq, and ACL2
Cc: Camm Maguire, list

> I already have Ocaml and Coq running on the axiom-developer.org
> server. If there is some interest, it would not be difficult for
> me to [snip] allow these to be accessed through the web
> like {axiom} {spad} {aldor} and {reduce}. This would not
> provide axiom/coq integration as such, but at least it would
> provide the possibility of exhibiting a coq proof along with
> some Axiom code should an author wish to do that.

Sounds interesting, but it might not be needed for a while yet, if at
all - I certainly have a long learning curve ahead of me with regards
to coq.  

> I am definitely interested by lack time right now to do
> anything serious.

Know that feeling...

> As you know, I am rather put-off by just "talking" about doing
> these things. Since quite a lot of code is freely available and
> easily accessed, I would prefer to just to dig-in and work/play
> with one or more of these tools ... then, maybe later, decide on
> which might be best and what if anything we really want to do
> with Axiom and theorem proving software.

Fair enough.  OK, I'll start digging.

> The "other" proof system is obviously of interest would be ACL2.
> Camm and some of the other lisp developer have a good connection
> to that project and so if we were to work with ACL2 and Axiom,
> I think we could expect a lot of support.

Yes, ACL2 and HOL were my other main interests in this department, with
Otter being of possible interest due to a somewhat different approach
(I still don't fully understand all the differences.)  However, proof
logic is a topic in and of itself so clearly there is a lot to learn to
be able to use any of these tools to do anything interesting/useful, so
I guess I'd better focus on the dimension and unit stuff first rather
than get sucked into proof issues.  

\start
Date: Thu, 20 Oct 2005 12:34:27 -0400
From: Eitan Gurari
To: Bill Page
Subject: RE: tex4ht and jsmath

 > But maybe it's a bit shocking though that the MathML result
 > is nearly twice the size of the pdf file. :( Well, I guess
 > I knew that MathML was verbose ...

TeX4ht adds many hints into the MathML code to facilitate
post-processing of the code.  It is quite easy to get rid of that extra
fat.  A proper insertion of math text and function names will also
offer some reduction in size.

 > > Some visual problems need to be corrected, in particular for
 > > \eqno.
 > 
 > I think that's a macro in axiom.sty?

No, it is a primitive instruction of TeX.

 > >      <<....>>
 > >      ...
 > >      @
 > >   fragments, since I was not able to locate axiom.tex.
 > 
 > These fragments are the 'noweb' source code markups that are
 > normally handled by the 'noweave' preprocessing which produces
 > pure LaTeX output. Editing this by hand is ok for this test but
 > noweave will also generate some extra LaTeX coding that will be
 > inserted before processing by 'latex'.

Yes, I know it is a noweb code.  The latex file without the axiom.sty
file doesn't take care of those code fragments in any mode (tex4ht,
dvi, pdf).  Hence, I deleted them manually.

 > >      \T<\a:mathml mtr>
 > > 
 > >   into
 > > 
 > >      \Tg<\a:mathml mtr>
 > 
 > This was a bug and patch to tex4ht, right?

Yes.

 > When you have time, could you also look at the result of
 > processing the 'tex' from the following page:
 > 
 > http://wiki.axiom-developer.org/axiom--test--1/src/algebra/fspace.spad

Can you provide me a pointer to axiom.sty (and the other required
files?).  The fspace file consists just of noweb macros.  No direct
math there.  Any math that comes into play there is through the noweb
macros.

 > > * Added {\csname HCode\endcsname{}} before ^ in the following 
 > > three formulas

 > What does this code do? (Do I need to know? :) It looks very
 > contrived as a synonym for {}.

The code {\csname HCode\endcsname{}} inserts into the dvi code 
empty bases {} for the superscripts and subscripts.  A {} alone
doesn't provide any footprints in the dvi code.

 > Well, please define "wrong way"

Having latex source code specified for the visual effects instead of
for the mathematical semantics meaning.

 > latex and dvipdfm swallowed all
 > that with out a complaint.

Sure, the compilers just care about drawing bits and curves.  Their
attitude is to satisfy the users' wishes. The authors are in charge of
properly expressing their wishes.  

Take a look at the pdf output of

    \documentclass{article} 
    \begin{document} 
       $ sin x $, 
       $ \sin x $ 
    \end{document} 

 > I will agree that the contents of the
 > file is a little crufty, but certainly no worse that a code of LaTeX
 > coding I have seen.

Well, I would expect the axiom people to be among the leaders when
math comes into play ;-)

 > Besides a stronger discipline, how can we insure that our LaTeX
 > coding meets certain minimum standards so that it doesn't cause
 > the conversion programs to barf? Do you know of any sort of 'lint'
 > program for LaTeX that could detect and warn about the "wrong way"
 > of doing things?

When latex barfs users go back to the source code to understand the
cause of the problems.  Any reason not do the same when the conversion
programs barf?

\start
Date: Thu, 20 Oct 2005 12:47:08 -0400
From: Bill Page
To: Tim Daly
Subject: RE: online algebra files

On Thursday, October 20, 2005 11:00 AM you wrote:
> ...
> Being able to create/update axiom online would be great because
> it would make the modification task "embarrassingly parallel"
> in most aspects. It will, of course, make my life of integrating
> it all a living hell but it would be worthwhile anyway.

;) Actually, my intention was to make your life **easier**
and also to reduce the amount of time required to make patches
to Axiom.

>
> There are still a lot of "quality" tasks that go on behind the
> scenes. I document changes, update the CHANGELOG, rebuild from
> scratch, hand check the test case output, cross-build on various
> platforms, and "round-trip" the changes (checkin, erase, checkout,
> rebuild, retest) before release. And finally the release gets
> pushed to all three archives (arch, savannah, sourceforge).

You can (should?) of course continue to do this. I agree that it
is important to maintain at lease one Axiom source archive that
can be treated as "authoritative".

> I don't see how these tasks can be performed in parallel. I do
> feel they are necessary to make sure the quality stays high.
> Every step is there because it eliminates some problem that has
> bitten me in the past.

I think each developer has his own style and preferred tools.
I do not see anything wrong with other developers working in
parallel with their versions of the Axiom sources and submitting
patches to you - better using the new MathAction online access
to the 'axiom--test--1' archive.

One thing that we need to insist on, however is that all developers
take the time to write documentation about the changes they are
making. HI think having the Axiom pamphlet source on-line and
visible should help to encourage developers to do this.

>
> We need to think about ways to merge a web-based changes to the
> official archive. How do you see this happening? Would it be
> possible to do a
>
>   diff -Naur archive.version web.version >web.version.patch
>
> for changed files? The "diff -Naur old new" is my primary tool.
>

What I have in mind is for updates of the Axiom source on
MathAction to be mirrored in a separate tla branch archive
I have called 'axiom--test--1'. This is not implemented yet
but it will be very easy to do. That way, after making some
changes online, a developer could just do a

  % cd axiom--test--1
  % tla update
  % ./configure
  % make

and immediately start testing the new experimental version.

To (selectively) transfer these changes to the 'axiom--main--1'
branch tla has some simple built-in diff-style commands for
comparing versions between branches and applying patches. Of
course one could also continue to do it the old fashioned manually
intensive way with just "diff -Naur old new".

\start
Date: Thu, 20 Oct 2005 12:50:13 -0400
From: Eitan Gurari
To: Martin Rubey
Subject: RE: tex4ht and jsmath

 >  > > I'll provide a jsmath mode. Probably during the winter break.  Maybe
 >  > > before that.
 > 
 > This would be wonderful!

Looks like an email of mine from Saturday saying the same got lost
somewhere.

 > Oh dear. This is really true? Would this be better with jsMath?

I believe so.

 >  > > The code {\csname HCode\endcsname{}} works for TeX and TeX4ht.
 > 
 > So ${{}^{HANB} ... $ would not work for tex4ht?

It is not guaranteed to work.

 > This seems like a problem for
 > me. 

Can't do much for that :-( 

> http://baruch.ev-en.org/proj/chktex/

Thanks for the pointer.

 > On the other hand, we could simply say: a proper pamphlet file is a file that
 > is correctly processed by latex and tex4ht. :-)

Plus validates against a xhlatex+mathml dtd! Why not?

\start
Date: Thu, 20 Oct 2005 13:12:51 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: online algebra files

On Thursday, October 20, 2005 12:25 PM Bob McElrath wrote:
>
> A few (very obvious) directions for future work...I wish I had more
> time...
> 1) HTML instead of images

Well, yes but ... :)

The only image used is just the first page of the document
derived by 'dvipng' from the associated 'dvi' file. You should
think of this as only a kind of "thumbnail" for the actual
document. It is much smaller than any HTML representation of
the actual document and therefore displays more quickly on
less powerful workstations and slow network connections.

This is the whole problem using pure LaTeX source on LateWiki.
After some experiments with embedded PDF, I had to agree with
your initial revulsion to that approach. So I had hoped instead
to be able to use a good LaTeX to XHTML+MathML (such as tex4ht)
and really present the document to the user this way. But as
we know there are still many problems with this approach. At
this time I am still considering whether to provide 'mml' as
a display option along with 'dvi' and 'pdf'.

> 2) Fill in abstracts for each domain

Yes! Please, someone start to do this ASAP.

> 3) Disable comments on these pages.  (Or, organize them
> differently...we surely don't want to be appending comments
> to the source code!)

The current pamphlet source format on MathAction has two
parts: the '\documentclass ... \end{document}' part containing
the actual pamphlet source from the Axiom distribution, followed
immediately by the LatexWiki-style StructuredText+LaTeX+Axiom
content (possibly none).

The page is rendered by first applying 'noweave' to the entire
page source. This has the side-effect of ignoring any material
following \end{document}. The resulting LaTeX source is then
processed by the following sequence of commands:

  latex
  latex
  dvipdfm
  dvipng -l 1

A header contain the png graphic and linking to the other
formats is created and then the remaining part of the source
(if any) is simply processed as if it was of pagetype

  StructuredText + LaTeX ( + Axiom )

As usual, comments are simply appended to the end of the
page source and so are rendered in the same way as before.

I do not see any problems with collecting comments as part
of the page source. Because of the literate programming noweb
format these will remain invisible to the extracted source
code and to the rendered documentation. But as time permits
it will be possible for pamphlet editors to easily review
these comments and either discard them or incorporate them
into the pamphlet source. 

To me, this seemed like "the best of both worlds". :)

\start
Date: Thu, 20 Oct 2005 13:45:09 -0400
From: Bill Page
To: Eitan Gurari
Subject: RE: tex4ht and jsmath

On Thursday, October 20, 2005 12:34 PM Eitan Gurari wrote:
> ...
> > > Some visual problems need to be corrected, in particular
> > > for \eqno.
>  >
>  > I think that's a macro in axiom.sty?
>
> No, it is a primitive instruction of TeX.
>

Oh ya... in fact there are quite a number of places where Axiom
documentation and even Axiom itself using "old fashioned" TeX
coding styles. I agree that these should (eventually) be weeded
out and replaced. Right now there is an axiom developer (Andreas?)
who is doing some work to replace the TeX generated by Axiom with
better LaTeX. His immediate motivation is to better support tools
like TeXmacs.

Will tex4ht convert any of these legacy codes?

>
>  > When you have time, could you also look at the result of
>  > processing the 'tex' from the following page:
>  >
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/fspace.spad
>
> Can you provide me a pointer to axiom.sty (and the other required
> files?).  The fspace file consists just of noweb macros.  No direct
> math there.  Any math that comes into play there is through the
> noweb macros.

See:

http://wiki.axiom-developer.org/axiom--test--1/src/scripts/tex

All the files required to build Axiom from source should be part of
this source tree on the Axiom wiki. If you notice anything else
missing, please let me know.

>
>  > > * Added {\csname HCode\endcsname{}} before ^ in the following
>  > > three formulas
>
> ...
> > Well, please define "wrong way"
>
> Having latex source code specified for the visual effects instead
> of for the mathematical semantics meaning.

Hmmm... wouldn't that imply {\csname HCode\endcsname{}} is the
"wrong way"? But anyway, I understand that there are always
compromises we have to make to standards.

\start
Date: Thu, 20 Oct 2005 13:45:57 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: FramedNonAssociativeAlgebraFunctions2

Clearly this is a bug because the line:

    rank()$AR = rank()$AR => represents(vs)$AS

is always true and cannot be the intended meaning. The line you propose

    rank()$AR = rank()$AS => represents(vs)$AS

seems to be correct according to my reading of the file. That is, if the
rank of the algebras is the same then we can use the vector basis of AS.
If they are of different rank then we need to return a smaller basis.

I've make this fix in the current system.

\start
Date: Thu, 20 Oct 2005 13:56:33 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: tex4ht and jsmath
Cc: Eitan Gurari, list

On Thursday, October 20, 2005 5:45 AM you wrote:
> ...
> Bill Page wrote:
> >
> > Besides a stronger discipline, how can we insure that our
> > LaTeX coding meets certain minimum standards so that it
> > doesn't cause the conversion programs to barf? Do you know
> > of any sort of 'lint' program for LaTeX that could detect
> > and warn about the "wrong way" of doing things?
>
> I think that chktex does this:
>
> http://baruch.ev-en.org/proj/chktex/
>
> it issues warnings about possible typographical errors.
>

Excellent! I think I will add this as an online tool in
MathAction.

> On the other hand, we could simply say: a proper pamphlet
> file is a file that is correctly processed by latex and
> tex4ht. :-)
>

No!! That would be a mistake similar to defining HTML as the
language accepted by the Microsoft Internet Explorer browser.
Since we can do much better than that, we should.

\start
Date: Thu, 20 Oct 2005 12:58:09 -0500
From: MathAction (greg)
To: MathAction
Subject: [#222 FramedNonAssociativeAlgebraFunctions2 and map] property change

Status: fix proposed => pending (next release) 

\start
Date: Thu, 20 Oct 2005 14:40:21 -0400
From: Eitan Gurari
To: Bill Page
Subject: RE: tex4ht and jsmath

 > Will tex4ht convert any of these legacy codes?

Yes, provided native latex can compile the file.

 > > http://wiki.axiom-developer.org/axiom--test--1/src/algebra/fspace.spad

 > http://wiki.axiom-developer.org/axiom--test--1/src/scripts/tex

The file doesn't compile at my place for native latex on a few
different machines.

    latex fspace.spad.tex  
    =====================
    This is TeX, Version 3.14159 (Web2C 7.3.1) 
    (fspace.spad.tex 
    LaTeX2e <1999/12/01> patch level 1 
    Babel <v3.6Z> and hyphenation patterns for american, french, german,
    ngerman, n 
    ohyphenation, loaded. 
    (/usr/local/teTeX/share/texmf/tex/latex/base/article.cls 
    Document Class: article 1999/09/10 v1.4a Standard LaTeX document class
    
    (/usr/local/teTeX/share/texmf/tex/latex/base/size10.clo)) (axiom.sty) 
    No file fspace.spad.aux. 
    [1] 
    No file fspace.spad.toc. 
    [2] 
    ! Missing number, treated as zero. 
    <to be read again>  
                       a 
    l.13 ...ename{fspace.spad.pamphlet}\nwbegincode{1} 
                                                      \moddef{category ES
    Expres... 
     
    ?  

The axiom.sty will need a short counter axiom.4ht file to take care of
creature such as

  \setbox\plusequivbox=\hbox{$\mathord{+}\mathord{\equiv}$}
  \def\@nwsubscriptident#1#2{\mbox{$\mbox{#1}_{\mathrm{\subpageref{#2}}}$}}


 > Hmmm... wouldn't that imply {\csname HCode\endcsname{}} is the
 > "wrong way"? But anyway, I understand that there are always
 > compromises we have to make to standards.

Yes, {\csname HCode\endcsname{}} is ugly -- I don't like it.  Can be a
little nicer if inserted indirectly through a macro. In fact,
typically an empty base is employed for tensors and in the case of
mathml a special construct multiscripts is offered for tensors.

\start
Date: Thu, 20 Oct 2005 14:47:46 -0400
From: Eitan Gurari
To: Bill Page
Subject: RE: tex4ht and jsmath

 > > http://baruch.ev-en.org/proj/chktex/
 > > 
 > > it issues warnings about possible typographical errors.
 > >
 > 
 > Excellent! I think I will add this as an online tool in
 > MathAction.
 >  
 > > On the other hand, we could simply say: a proper pamphlet 
 > > file is a file that is correctly processed by latex and
 > > tex4ht. :-)
 > > 
 > 
 > No!! That would be a mistake similar to defining HTML as the
 > language accepted by the Microsoft Internet Explorer browser.
 > Since we can do much better than that, we should.

I think validating the output visually (latex) and against dtds
(tex4ht) is very important.  Chktex seems to be  a useful tool but
far from being sufficient for doing the whole job.

\start
Date: Thu, 20 Oct 2005 15:17:31 -0400
From: Bill Page
To: Eitan Gurari
Subject: RE: tex4ht and jsmath

On Thursday, October 20, 2005 2:40 PM Eitan Gurari wrote:
> ...
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/fspace.spad
>
> http://wiki.axiom-developer.org/axiom--test--1/src/scripts/tex
>
> The file doesn't compile at my place for native latex on a few
> different machines.
>
>     latex fspace.spad.tex 
>     =====================
>     This is TeX, Version 3.14159 (Web2C 7.3.1)
>     (fspace.spad.tex
>     LaTeX2e <1999/12/01> patch level 1
>     Babel <v3.6Z> and hyphenation patterns for american,
>     french, german, ngerman, nohyphenation, loaded.
>

On the axiom-developer.org server we are running:

[root@axiom-developer algebra]# latex -v
pdfeTeX 3.141592-1.21a-2.2 (Web2C 7.5.4)
kpathsea version 3.5.4
...
----------

This is another major release newer that yours. On this system
'fspace.spad.tex' compiles with only warnings. And 'mzlatex'
actually produces an 'xml' file but with a few start and end
tags out of place.

As a LaTeX expert can you see what might be making fspace.spad.tex
incompatible with older versions of LaTeX? As you said the LaTeX
contents of this file consists almost entirely of noweb insertions
and I know there are a lot more just like it among the Axiom
distribution pamphlet files.

>
> The axiom.sty will need a short counter axiom.4ht file to
> take care of creature such as
>
>   \setbox\plusequivbox=\hbox{$\mathord{+}\mathord{\equiv}$}
>  
>
\def\@nwsubscriptident#1#2{\mbox{$\mbox{#1}_{\mathrm{\subpageref{#2}}}$}
}
>

If you tell me explicitly what needs to go where, I would be
glad to try it. But a lot of this magic I do not understand.

\start
Date: Thu, 20 Oct 2005 16:25:10 -0400
From: Tim Daly
To: Bill Page
Subject: re: tex4ht and jsmath
Cc: Eitan Gurari

ok, i'll bite.
what could "old latex" mean?
does anyone have a pointer to a document?

\start
Date: Thu, 20 Oct 2005 16:35:56 -0400
From: Bill Page
To: Tim Daly
Subject: re: tex4ht and jsmath
Cc: Eitan Gurari

On Thursday, October 20, 2005 4:25 PM you asked:
>
> ok, i'll bite.
> what could "old latex" mean?
> does anyone have a pointer to a document?
>

See:

http://www.ams.org/jourhtml/latexbenefits.html

Appendix 1: How To Tell Whether a LaTeX Document is Old LaTeX or LaTeX
2e?

\start
Date: Thu, 20 Oct 2005 16:41:11 -0400
From: Tim Daly
To: Bill Page
Subject: old vs new latex
Cc: Eitan Gurari

technically all of the documents are latex2e (documentclass).
the style guide seems specific to ams latex, which axiom is not.
if there is a document that deprecates certain forms i'd be happy
to rewrite using them.

\start
Date: Thu, 20 Oct 2005 18:47:25 -0500
From: MathAction (billpage)
To: MathAction
Subject: [MathAction] Folders in MathAction

  The web pages in MathAction are grouped into folders and the
folders are arranged in a tree structure just like directories and
sub-directories in Linux and Windows. The top level folder (root of
the tree) is simply called 'mathaction'. Inside each folder there
are web pages and possibly more nested folders. 'FrontPage' is the
name of the page that introduces the contents of a folder.

  Your current location in the tree is shown as a path listing
each of the nested folders at the top of each page. For example
the path::

    /mathaction/axiom--test--1/src/algebra/!FrontPage

  is displayed when you are looking at the following
"list of files":/axiom--test--1/src/algebra in the Axiom source
code tree.

  You can click on any folder name in the path to jump directly to
that location in the tree.

Installing MathAction

  See InstallingMathAction for information about how to configure

\start
Date: Thu, 20 Oct 2005 19:12:10 -0500
From: MathAction (billpage)
To: MathAction
Subject: [Axiom Documentation] 

  An updated electronic version (last update 20 October 2005) of the wonderful
Axiom book by Richard D. Jenks and Robert S. Sutor is available

as a large (4.5 Mbyte) pdf file. It contains some new content and improved
hyperlinks.  It is also included with the source code "distribution":AxiomDownload.

\start
Date: Thu, 20 Oct 2005 19:30:04 -0500
From: MathAction (billpage)
To: MathAction
Subject: [FrontPage] 

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

\start
Date: Thu, 20 Oct 2005 19:53:37 -0500
From: MathAction (billpage)
To: MathAction
Subject: [FrontPage] 

"Axiom book":/Mirrors?go=/public/book2.pdf&it=Axiom+Book

\start
Date: Fri, 21 Oct 2005 11:18:42 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: FramedNonAssociativeAlgebraFunctions2

could you put the patch also on IssueTracker, please. (If you don't want to,
tell me and I'll do it.)

I suppose that you added

 > The line you propose
 > 
 >     rank()$AR = rank()$AS => represents(vs)$AS
 > 
 > seems to be correct according to my reading of the file. That is, if the
 > rank of the algebras is the same then we can use the vector basis of AS.
 > If they are of different rank then we need to return a smaller basis.

to the pamphlet.

\start
Date: Fri, 21 Oct 2005 11:42:40 +0200
From: Juergen Weiss
To: list
Subject: RE: Aldor and Lisp

"as someone who shared his office for a few years
with Knut Wolf, who had been working for about a year
on A# (aldor), I can say" ;-) :

The old code was difficult to maintain. There was (is)
litte documentation. The error messages of the compiler
are not really very helpful. Errors in the code were hard
to fix. On the typical hardware of that time
(AIX Workstation), the compiler was quit slow. (There
were some changes to speed up the SPAD compiler later).

I think, there had been an attempt for a reimplementation
in Lisp/Boot before.

Why they decided to reimplement in C and not in Lisp
I do not know.

So there were quite a few technical reasons for a rewrite.

> > > > It is notable I think, that the original Axiom
> > > > developers chose to re-implement SPAD as Aldor
> > > > (written in C) rather than continue to make
> > > > improvements to SPAD.
> >
> > I'm absolutely certain that the reason for this was rather
> > a political than a technical one.
> >
>
> Could you explain what makes you absolutely certain of this?
> Can you cite any references to Axiom or Aldor literature?
>
> In what sense was it "political"? Who stood to gain by such
> a decision?
>
> To me the technical reasons seem rather obvious. So please
> forgive me if I seem rather skeptical.
>

\start
Date: Fri, 21 Oct 2005 11:56:36 -0400
From: Bill Page
To: list
Subject: open source aldor
Cc: Camm Maguire

Some good news about Aldor!

I received a private email from Steven Watt today confirming
that: "we are now contemplating adopting a complete open source
license for everyone" and also since that might take some time
to accomplish, as an interim measure he is still willing to
proceed on the basis of individual requests.

\start
Date: Fri, 21 Oct 2005 11:55:29 -0400
From: Tim Daly
To: Bill Page
Subject: Re: open source aldor
Cc: Camm Maguire

excellent.

\start
Date: Fri, 21 Oct 2005 11:03:53 -0500
From: MathAction (Tim Daly)
To: MathAction
Subject: [#222 FramedNonAssociativeAlgebraFunctions2 and map] 

The fix, as proposed, now reads:
rank()$AR = rank()$AS => represents(vs)$AS

\start
Date: Fri, 21 Oct 2005 12:00:01 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: FramedNonAssociativeAlgebraFunctions2

done

\start
Date: Fri, 21 Oct 2005 11:40:00 -0500
From: MathAction (greg)
To: MathAction
Subject: [#222 FramedNonAssociativeAlgebraFunctions2 and map] 

rank()\$AR = rank()\$AS => represents(vs)\$AS

\start
Date: Fri, 21 Oct 2005 13:36:52 -0400
From: Bill Page
To: list
Subject: RE: Aldor and Lisp

On October 21, 2005 5:43 AM Juergen Weiss wrote:
> ...
> [about Aldor] 
> I think, there had been an attempt for a reimplementation
> in Lisp/Boot before. 
> 
> Why they decided to reimplement in C and not in Lisp
> I do not know. 
>

I wouldn't want to start a "language war" or anything, but
seriously does anyone know of any production (as opposed
to experimental or prototype) compiler written in lisp?
(besides lisp itself, of course)

I recall a posting by Paul Dietz suggesting that gcc should
be re-written in lisp. (perhaps he was not entirely serious ;)

\start
Date: Fri, 21 Oct 2005 13:56:13 -0400
From: Tim Daly
To: Bill Page
Subject: Re: Aldor and Lisp

There is a PHP production compiler written in scheme.
http://www.roadsend.com

\start
Date: Fri, 21 Oct 2005 20:07:53 +0200
From: Juergen Weiss
To: Bill Page
Subject: RE: Aldor and Lisp

Most lisp compilers are written in lisp:
the famous Maclisp compiler, for example
and the CMU Common Lisp Compiler Python.

In my opinion, a drawback of the current
implementation of AXIOM in BOOT/LISP is,
that BOOT/LISP does not easily allow the use of
typed variables (defstruct). In more modern
lisp programming lists are out, defstruct
is in (if we forget OO altogether) ;-). So
the implementation technique of the AXIOM
interpreter/compiler lacks a feature (typed data),
for which AXIOM is famous as a computer algebra
system. This is rather unfortunate.

So you could extend BOOT with defstruct,
drop BOOT and convert everything to lisp,
define the data with defstruct in lisp
and use the accessor functions from BOOT.

> -----Original Message-----
>
> On October 21, 2005 5:43 AM Juergen Weiss wrote:
> > ...
> > [about Aldor]
> > I think, there had been an attempt for a reimplementation
> > in Lisp/Boot before.
> >
> > Why they decided to reimplement in C and not in Lisp
> > I do not know.
> >
>
> I wouldn't want to start a "language war" or anything, but
> seriously does anyone know of any production (as opposed
> to experimental or prototype) compiler written in lisp?
> (besides lisp itself, of course)
>
> I recall a posting by Paul Dietz suggesting that gcc should
> be re-written in lisp. (perhaps he was not entirely serious ;)

\start
Date: Fri, 21 Oct 2005 21:24:59 -0400
From: Bill Page
To: Tim Daly
Subject: compiler written in C

On October 21, 2005 1:56 PM Tim Daly wrote:

> 
> There is a PHP production compiler written in scheme.
> http://www.roadsend.com
> 

Well, I have to admit that counts as one!

Can PHP development really live in a closed source world?
These guys have a lot of guts ...  I wonder where they get
it from? :)

\start
Date: Fri, 21 Oct 2005 21:53:23 -0400
From: Bill Page
To: Juergen Weiss
Subject: RE: Aldor and Lisp

On October 21, 2005 2:08 PM Juergen Weiss wrote:
> 
> In my opinion, a drawback of the current 
> implementation of AXIOM in BOOT/LISP is,
> that BOOT/LISP does not easily allow the use of
> typed variables (defstruct). In more modern
> lisp programming lists are out, defstruct
> is in (if we forget OO altogether) ;-). So
> the implementation technique of the AXIOM 
> interpreter/compiler lacks a feature (typed data),
> for which AXIOM is famous as a computer algebra
> system. This is rather unfortunate.
>

I think that is a very valuable observation which
is especially relevant if we are contemplating
making significant improvements to the Axiom
interpreter. Regarding the compiler, I am still
convinced that Aldor is by far the best way forward.

Did you mean the following as alternatives?

> So you could extend BOOT with defstruct,

This makes a lot of sense to me. Making improvements
to Axiom making improvements in it's foundations
sounds like a reasonable long term strategy.

> drop BOOT and convert everything to lisp,

Contrary to some people, I think BOOT was and still
is very important in the overall design of Axiom. You
can see everywhere examples of how the language in
which something is written affects the look and feel
of things written in that language. Clearly no one
wanted ScratchPad to look and feel like lisp (but
perhaps work like lisp, yes). So it was an inspired
idea, I think to first write a language that was
"half way in between" so as to speak.

If one were to drop boot, I think one might risk
the long term logical integrity of this design.
 
In BOOT you still have low level access to the
features of lisp that are essential for symbolic
mathematics, but it is dressed in a syntax closer
to the SPAD high level target language. If we want
some of advantages of new features of lisp (e.g.
defstruct and types) to be available to Axiom,
the best place to start is BOOT - in other words
BOOT with primitive types.

> define the data with defstruct in lisp
> and use the accessor functions from BOOT.

Could you explain a little more what you mean by
this approach? Do you mean using the built-in ability
in BOOT to escape to lisp when necessary or more
convenient? What are the "accessor functions" in
BOOT?

\start
Date: Sat, 22 Oct 2005 14:31:35 +0200
From: Juergen Weiss
To: Bill Page
Subject: RE: Aldor and Lisp

> -----Original Message-----
> Subject: RE: Aldor and Lisp
>
> On October 21, 2005 2:08 PM Juergen Weiss wrote:
> >
> > In my opinion, a drawback of the current
> > implementation of AXIOM in BOOT/LISP is,
> > that BOOT/LISP does not easily allow the use of
> > typed variables (defstruct). In more modern
> > lisp programming lists are out, defstruct
> > is in (if we forget OO altogether) ;-). So
> > the implementation technique of the AXIOM
> > interpreter/compiler lacks a feature (typed data),
> > for which AXIOM is famous as a computer algebra
> > system. This is rather unfortunate.
> >
>
> I think that is a very valuable observation which
> is especially relevant if we are contemplating
> making significant improvements to the Axiom
> interpreter. Regarding the compiler, I am still
> convinced that Aldor is by far the best way forward.

If the problems with the inclusion of Aldor into
the Axiom distribution are resolved, we should
certainly consider moving the algebra library
to the Aldor language. I have no idea how much
work would be involved doing that. But I would
guess that writing a new compiler is much more
work. To achieve a reasonable design, it could
not be 100 compatible to the old compiler written
in lisp. So we had to migrate the algebra
library to a new language anyhow.

> Did you mean the following as alternatives?

Yes.
>
> > So you could extend BOOT with defstruct,
>
> This makes a lot of sense to me. Making improvements
> to Axiom making improvements in it's foundations
> sounds like a reasonable long term strategy.
>
> > drop BOOT and convert everything to lisp,
>
> Contrary to some people, I think BOOT was and still
> is very important in the overall design of Axiom. You
> can see everywhere examples of how the language in
> which something is written affects the look and feel
> of things written in that language. Clearly no one
> wanted ScratchPad to look and feel like lisp (but
> perhaps work like lisp, yes). So it was an inspired
> idea, I think to first write a language that was
> "half way in between" so as to speak.
>
> If one were to drop boot, I think one might risk
> the long term logical integrity of this design.
> 
> In BOOT you still have low level access to the
> features of lisp that are essential for symbolic
> mathematics, but it is dressed in a syntax closer
> to the SPAD high level target language. If we want
> some of advantages of new features of lisp (e.g.
> defstruct and types) to be available to Axiom,
> the best place to start is BOOT - in other words
> BOOT with primitive types.

I would not advise that road either.

> > define the data with defstruct in lisp
> > and use the accessor functions from BOOT.
>
> Could you explain a little more what you mean by
> this approach? Do you mean using the built-in ability
> in BOOT to escape to lisp when necessary or more
> convenient? What are the "accessor functions" in
> BOOT?

Yes, in lisp the functions to access parts of a structure
(defstruct) are just ordinary lisp macros which can
get called from BOOT as well. One could define lisp macros
to set parts of a structure. On the long run,
an extension of the BOOT syntax for assignment (setf in lisp)
and some more "syntactic sugar" to handle defstructs
would be nice.

\start
Date: Sat, 22 Oct 2005 16:11:51 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Juergen Weiss
Subject: RE: Aldor and Lisp
 
> Contrary to some people, I think BOOT was and still
> is very important in the overall design of Axiom. You
> can see everywhere examples of how the language in
> which something is written affects the look and feel
> of things written in that language. Clearly no one
> wanted ScratchPad to look and feel like lisp (but
> perhaps work like lisp, yes). 

Is this still true?  I have heard a couple variations of the BOOT/Lisp
story, but I haven't heard there was a concensus that the look and feel
of Lisp should be avoided.  If so, I would be very interested in the
rational behind this decision.  SPAD/Aldor definitely doesn't look like
lisp, so perhaps I am missing something - how does BOOT usefully impact
the "feel" of Axiom to the normal programmer (who will mostly be
working with SPAD/Aldor?)  Below the level of SPAD/Aldor I guess I'm
confused as to how lisp vs. non-lisp is helpful - are some concrete
examples available?

> So it was an inspired
> idea, I think to first write a language that was
> "half way in between" so as to speak.

The problem with such a language is that it raises the bar even further
for new programmers.  Lisp has survived a VERY long time, is well
defined, and had some truly amazing software created using it - I at
least could use some convincing that BOOT has concrete benefits that
justify another learning curve.  Aldor I can see, since that level of
Axiom coding is geared very specifically toward mathematics, but below
that level it's not as clear to me.  This could simply be ignorance on
my part.

> If one were to drop boot, I think one might risk
> the long term logical integrity of this design.

Are there some design documents somewhere from the original project
that detail this goal?  I confess the impression I had of BOOT was that
it was the consequence of irreconcilable differences among the original
developers about coding style, but perhaps there was more to it than
that.

\start
Date: Sat, 22 Oct 2005 19:04:55 -0500
From: MathAction (unknown)
To: MathAction
Subject: [SymbolicIntegration] 

int(sqrt(x), x)

\start
Date: Sat, 22 Oct 2005 20:32:21 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Aldor and Lisp

A bit of history....

(Please note that this is NOT a criticism of either Dick Jenks
or Bill Burge, both of whom rank among the best people I've ever
met in this business. Dick was like a father to me on the Scratchpad
project. I'm the opinionated, stubborn son(-of-a-bitch) in this story)

Boot grew out of work Dick Jenks did in Meta which was some
pre-scratchpad work he did. He and Bill Burge (another group
member) were very interested in parsing issues. Bill Burge has
a book out on parsing techniques (ISBN 0-201-14450-6) and knows
everything worth knowing about the subject.

(an aside. There was another portion of the system written in Meta
which I've already removed).

Scratchpad was originally written in a combination of boot and maclisp.
By the time I joined the project it had been moved to VMLisp on an IBM/370
mainframe. I had a very wide range of experience with many different lisps.
A previous project (Eclipse, a rule-based language) was implemented in
VMLisp and I had moved it to Common Lisp on a Symbolics Machine. Later
we moved it to Lucid Common Lisp.

At the time the IBM PC was becoming more popular and IBM had introduced
its new IBM/RT Risc processor (aka "the hairdryer" because both used about
1500 Watts and had the equivalent compute power). We wanted to move 
Scratchpad off the mainframe and onto the RT.

I connected with Scott Fahlman at CMU and got the sources for CMU Spice Lisp
(now known as CMUCL) and built it on the RT. We wanted our own version of
Common Lisp and took out a contract with Bill Schelter for AKCL which was
his version and extension of KCL (Kyoto Common Lisp, AKCL stands for
Austin-Kyoto Common Lisp as Schelter was a professor from Austin Texas).
AKCL is now GNU Common Lisp (GCL). I worked closely with Schelter on various
implementation details (like GC and tail recursion which we needed badly
as the top level loop of Axiom is tail-recursive)

I rewrote large chunks of scratchpad from VMLisp/Maclisp to Common Lisp.
As part of that effort there were numerous, sometimes heated, discussions
of Boot vs Lisp. Dick was firmly planted on the Boot side and I was firmly
planted on the Lisp side. Since Dick fathered the Boot language this is
perfectly understandable. Boot was one of many dozens (hundreds) of attempts
to make a paren-less version of lisp (Python is the latest attempt). 

I rewrote the whole system into Common Lisp at one point but was unable
to convince Dick or the rest of the group that this was acceptable and
the code was erased.

Bill Burge wrote several parsers for Boot which added new features that
were showing up in Common Lisp. There were so many "new" parsers that
we had a running jokefest about the "new-new-new-new version" vs the
"new-new-new-new-new version" of the language. You'll see references
to "Shoe" in some function names. "Shoe" was an improved Boot. (Bill
had a very dry sense of humor.)

Being firmly in the Lisp camp I wrote all of my code in Common Lisp.
Thus if you look at the sources the .lisp files were likely authored
(or re-written) by me as the rest of the group continued to use Boot.

I'm fundamentally opposed to Boot and have stated many times that my
goal is to rewrite the interpreter to elide Boot completely. There are
several reasons.

Boot gives up one of the fundamental features of lisp, the equivalent
representation of program and data. In fact, Axiom uses this equivalence
at various points and fundamentally depends on it.

Boot adds another layer of complexity to the system, a very difficult
layer. The effects are widespread. You need a Boot compiler to compile
Boot, which is written in Boot. Bill liked to build parsers in his new
language and, as a consequence, there was never a version of Boot that
would build from scratch. Up until the time I got Axiom as open source
it was always true that you needed a running Axiom system to build Axiom.
(Since I didn't have one available that could be shipped as open source
I had to solve the bootstrapping-Boot problem).

Boot breaks the lisp debugging tools because, while it compiles to lisp
it generates "compiler code" which is very hard to read unless you're
very familiar with the transformations it performs. Sure, it is valid
common lisp but look at the int/interp/*.clisp files and you'll see
some hairy-looking code. And when it breaks in mid-code the traceback
is not intuitive at a time when you need intuition the most.

There are interpreter-level support functions for working in Boot
which allow you to recompile and reload files. These are not needed
for Lisp code.

The whole Boot compiler subsystem can be removed if Boot is removed.
This reduces the Axiom build time and complexity quite a bit as there
is no need to bootstrap the compiler nor to compile the boot code.

Boot is a language known to very, very few people and is likely to
have an ever shrinking set of people as the original developers die.
The learning curve is either very steep or trivial depending on who
you talk to but it is still a learning curve. Boot, like all languages,
has some very pretty features but nothing fundamentally immortal.

I need to do this rewrite anyway as the whole interpreter needs to be
made into a literate, well documented program. Given that level of effort
it only makes sense to do all the cleanup/rewrite/refactoring at the same
time.

Not everyone agrees with me, of course, so it is ultimately up to me
to make this change if I ever want it to happen. As they say in free
software "Advocacy is volunteering" :-)

\start
Date: Sat, 22 Oct 2005 22:47:11 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Aldor and Lisp

On October 22, 2005 7:12 PM C Y wrote:
> 
> --- Bill Page wrote:
>  
> > Contrary to some people, I think BOOT was and still
> > is very important in the overall design of Axiom. You
> > can see everywhere examples of how the language in
> > which something is written affects the look and feel
> > of things written in that language. Clearly no one
> > wanted ScratchPad to look and feel like lisp (but
> > perhaps work like lisp, yes). 
> 
> Is this still true?  I have heard a couple variations
> of the BOOT/Lisp story, but I haven't heard there was
> a consensus that the look and feel of Lisp should be
> avoided.

I am sorry Clifford but your question strikes me as very
peculiar. As I said, I thought this was obvious. Let me
illustrate with some examples chosen at random.

In Axiom here is an example of some of the lisp code:

(defun MAKE-HASHTABLE (id1 &optional (id2 nil))
 (declare (ignore id2))
   (let ((test (case id1
          ((EQ ID) #'eq)
          (CVEC #'equal)
          (EQL #'eql)
          #+Lucid ((UEQUAL EQUALP) #'EQUALP)
          #-Lucid ((UEQUAL EQUAL) #'equal)
          (otherwise (error "bad arg to make-hashtable")))))
      (make-hash-table :test test)))

----------

Here is some example BOOT code:

genTempCategoryTable() ==
  for con in allConstructors()  repeat
    GETDATABASE(con,'CONSTRUCTORKIND) =
     'category => addToCategoryTable con
  for id in HKEYS _*ANCESTORS_-HASH_* repeat
    item := HGET(_*ANCESTORS_-HASH_*, id)
    for (u:=[.,:b]) in item repeat
      RPLACD(u,simpCatPredicate simpBool b)
    HPUT(_*ANCESTORS_-HASH_*,id,
      listSort(function GLESSEQP,item))

---------

And finally here is an example of some SPAD code:

Table(Key: SetCategory, Entry: SetCategory):
  Exports == Implementation where
    Exports ==> TableAggregate(Key, Entry) with
                     finiteAggregate

    Implementation ==> InnerTable(Key, Entry,
        if hashable(Key)$Lisp then HashTable(Key,
             Entry, "UEQUAL")
          else AssociationList(Key, Entry))

-------

(Exercise for reader: find where in the Axiom source
these code segments are taken from. ;)

The point that I was making is that the target language
for the Axiom library (SPAD) is intended as a higher level
description of the mathematical algorithm, whereas BOOT
looks like most high level programming languages in common
use today (e.g. Python), but in comparative terms lisp
looks at best like a high level assembler language. It
is too close to the machine to be good for expressing
general abstract mathematical ideas.

It seems obvious to me that ScratchPad was intended to
present to the user the highest level language possible
for the expression of mathematics but which could still
be interpreted and compiled by a computer.

> If so, I would be very interested in the rational behind
> this decision. SPAD/Aldor definitely doesn't look like
> lisp, so perhaps I am missing something - how does BOOT 
> usefully impact the "feel" of Axiom to the normal programmer
> (who will mostly be working with SPAD/Aldor?)

Of course I cannot speak to the actual rational - I wasn't
there. Tim Daly has described the environment in which this
work as done very clearly.

But you missed my point. BOOT has nothing directly to do
with the SPAD/Aldor programmer. Lisp was used to create BOOT.
It doesn't look much like lisp anymore but in some ways it
still "feels" like lisp. BOOT was used to create the SPAD
language. The structure of SPAD was of course influenced
by the look and feel of the BOOT language.

The BOOT language is relevant to those people who want to
debug, maintain and enhance the Axiom system.

> Below the level of SPAD/Aldor I guess I'm confused as to
> how lisp vs. non-lisp is helpful - are some concrete
> examples available?

The issue is not lisp vs. non-lisp. All of Axiom *is* \1
ultimately written in lisp. Instead the issue is how lisp
is used in various parts of the system. Large parts of Axiom
were built in a layered manner, i.e. as a series of levels.
This is a common and effective design strategy for complex
systems. From my point of view BOOT forms a very important
intermediate level in Axiom because it allows programmers
to write at a more abstract level than just low level lisp.

Some of the opposition to the use of BOOT on the part of
lisp programmers is quite natural since BOOT (by design)
limits some of the types of programming styles that a lisp
programmer might find natural. But I think this may have
been one of the intentions of the overall design of Axiom
since as I said, I think people wanted the Axiom programming
language to look very different than lisp.

Footnote:

1\ Of course Aldor, as the next generation of SPAD, was
actually written in "C" not lisp (that is another story).
But the design of Aldor was inherited from SPAD.

> 
> > So it was an inspired idea, I think to first write a
> > language that was "half way in between" so as to speak.
> 
> The problem with such a language is that it raises the bar 
> even further for new programmers.

No, I don't think so. BOOT is written in lisp and if it
was properly documented, then I think understanding it's
relationship to lisp and how to use it to create SPAD and
the Axiom interpreter would be quite straight forward.

In lisp, it is a very natural design strategy to use lisp
to write a new language or to enhance lisp in other ways
as a step towards creating a final product. So understanding
a design necessarily might include understanding some
intermediate language specifically created for the purpose
of the design. The situation is not so different from say,
having to learn how to use lex and yacc when writing a
Fortran compiler in the C language.

> Lisp has survived a VERY long time, is well defined, and
> had some truly amazing software created using it - I at
> least could use some convincing that BOOT has concrete
> benefits that justify another learning curve.

No, you do not understand. BOOT is written in lisp and was
an integral part of the original Axiom design. Yes, Axiom
could have been designed without BOOT, but then one might
have lost the advantages of the hierarchical design strategy.
As a result it would have been more difficult to create
nearly some complex and high level a language as SPAD.

I might venture to guess that at least in part some of the
differences in Maxima versus Axiom is due to this design
strategy.

> Aldor I can see, since that level of Axiom coding is geared
> very specifically toward mathematics, but below that level
> it's not as clear to me.  This could simply be ignorance on
> my part.

Think about building Axiom as a series of layers. The top
level is the Axiom interpreter. Slightly below that would be
the SPAD/Aldor library. Below that BOOT. And below that lisp.
(Actually, Tim Daly has also described some other intermediate
layers in Axiom that are also present.)

> 
> > If one were to drop boot, I think one might risk
> > the long term logical integrity of this design.
> 
> Are there some design documents somewhere from the original
> project that detail this goal?  I confess the impression
> I had of BOOT was that it was the consequence of irreconcilable
> differences among the original developers about coding style,
> but perhaps there was more to it than that.
> 

Perhaps I am deluding myself, but I like to think that I am
in a sense, continuing to represent that side of the Axiom
project that maintained this apparently irreconcilable view -
since Tim Daly is still here to represent the opposition. :)
I think that this "tension" was (and still is) an important
part of the reason for Axiom's phenomenal success in the
representation of mathematics by computer. Of course that
might be just empty philosophy and maybe we really cannot
know why one project succeeds and another fails or how to
do it again...

\start
Date: Sun, 23 Oct 2005 01:44:10 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#223 Gerald Farmer] (new) 

I am unable to create a differential operator to generate Legendre
Polynomials using the Axiom Book prescription or using HyoerDoc.  I
have tried on both Windows and Mandrake Linux versions and the result
is the same.

\start
Date: Sun, 23 Oct 2005 04:47:59 -0500
From: MathAction (unknown)
To: MathAction
Subject: [Units and Dimensions] Emacs Calc implements Units

The Emacs calculator (Debian package 'calc') implements units.  They
kind of act like variables, for simplifications, but you can convert
between units.  Maybe it's worth a look at?

\start
Date: Sun, 23 Oct 2005 12:41:16 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#223 Legendre Polynomials] 

I am unable to create a differential operator to generate Legendre Polynomials using the Axiom Book prescription or using HyoerDoc.  I have tried on both Windows and Mandrake Linux versions and the result is the same.

Gerald Farmer  

\start
Date: Sun, 23 Oct 2005 12:51:00 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#223 Legendre Polynomials] Legendre example

Axiom book page 720:

\begin{axiom}
L n ==
  n = 0 => 1
  n = 1 => x
  (2*n-1)/n * x * L(n-1) - (n-1)/n * L(n-2)
\end{axiom}
\begin{axiom}
dx := operator("D") :: OP(POLY FRAC INT)
evaluate(dx, p +-> D(p, ’x))
E n == (1 - x**2) * dx**2 - 2 * x * dx + n*(n+1)
\end{axiom}
\begin{axiom}
L 15
E 15
(E 15)(L 15)
\end{axiom}

\start
Date: Sun, 23 Oct 2005 12:59:30 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#223 Legendre Polynomials] Legendre example

Dp(p) == D(p, 'x)
evaluate(dx, Dp)

\start
Date: Sun, 23 Oct 2005 11:50:47 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Aldor and Lisp

> > Is this still true?  I have heard a couple variations
> > of the BOOT/Lisp story, but I haven't heard there was
> > a consensus that the look and feel of Lisp should be
> > avoided.
> 
> I am sorry Clifford but your question strikes me as very
> peculiar.

Sorry, I didn't mean to offend - clearly I'm missing something
fundamental.

> As I said, I thought this was obvious. 

We all got nervous in Calculus class when a professor said something
was obvious ;-).

[snip]

> The point that I was making is that the target language
> for the Axiom library (SPAD) is intended as a higher level
> description of the mathematical algorithm, whereas BOOT
> looks like most high level programming languages in common
> use today (e.g. Python), but in comparative terms lisp
> looks at best like a high level assembler language. It
> is too close to the machine to be good for expressing
> general abstract mathematical ideas.

Oh, OK.  I see what you're saying.

> It seems obvious to me that ScratchPad was intended to
> present to the user the highest level language possible
> for the expression of mathematics but which could still
> be interpreted and compiled by a computer.

So the way things are organized is SPAD built on BOOT built on Lisp? 
And the core reason for this is that BOOT makes it much easier to build
SPAD than building it in straight Lisp would be?

[snip]

> But you missed my point. BOOT has nothing directly to do
> with the SPAD/Aldor programmer. Lisp was used to create BOOT.
> It doesn't look much like lisp anymore but in some ways it
> still "feels" like lisp. BOOT was used to create the SPAD
> language. The structure of SPAD was of course influenced
> by the look and feel of the BOOT language.

OK.  I guess I didn't appreciate how SPAD might be influenced by BOOT.

> The BOOT language is relevant to those people who want to
> debug, maintain and enhance the Axiom system.
>
> > Below the level of SPAD/Aldor I guess I'm confused as to
> > how lisp vs. non-lisp is helpful - are some concrete
> > examples available?
> 
> The issue is not lisp vs. non-lisp. All of Axiom *is* \1
> ultimately written in lisp. Instead the issue is how lisp
> is used in various parts of the system. Large parts of Axiom
> were built in a layered manner, i.e. as a series of levels.
> This is a common and effective design strategy for complex
> systems.

Ah, this is the key point I was missing.  I had the view (I guess
because of my Maxima experience) that the logical way to proceed was
use lisp for everything up to the point where the primary goal becomes
the expression of mathematical knowledge.  Separating it into a series
of layers, each with its matching language, wasn't obvious to me. ;-)

> From my point of view BOOT forms a very important
> intermediate level in Axiom because it allows programmers
> to write at a more abstract level than just low level lisp.

This being the case, we should be very clear in the literate
documentation on the purpose for each language, the reasons behind it,
and the advantages to using it (if we provide people with the full
rational, they'll probably be more willing to learn it.)  For myself, I
confess I thought the presence of BOOT was an unnecessary and
unbenficial complication, but that's an uninformed opinion and should
be revisited.

> Some of the opposition to the use of BOOT on the part of
> lisp programmers is quite natural since BOOT (by design)
> limits some of the types of programming styles that a lisp
> programmer might find natural. But I think this may have
> been one of the intentions of the overall design of Axiom
> since as I said, I think people wanted the Axiom programming
> language to look very different than lisp.

So BOOT was made different from Lisp to allow SPAD to be different? 
And the major objection to lisp is that it is too low level?  (Sorry if
those are more dumb questions, I'm just trying to get a sense of the
modes of thinking involved.)

> Footnote:
> 
> 1\ Of course Aldor, as the next generation of SPAD, was
> actually written in "C" not lisp (that is another story).
> But the design of Aldor was inherited from SPAD.

So if at some point Aldor becomes free and we can switch to it, what
are the implications for Lisp and BOOT in Axiom?
 
> > The problem with such a language is that it raises the bar 
> > even further for new programmers.
> 
> No, I don't think so. BOOT is written in lisp and if it
> was properly documented, then I think understanding it's
> relationship to lisp and how to use it to create SPAD and
> the Axiom interpreter would be quite straight forward.

OK.  In that case proper documentation becomes of paramount importance,
and I would say one of our highest priority tasks (if BOOT survives the
Aldor conversion) should be to get our languages documented so we can
have a reasonable expectation of people being able to learn and program
in them quickly.
 
> In lisp, it is a very natural design strategy to use lisp
> to write a new language or to enhance lisp in other ways
> as a step towards creating a final product. So understanding
> a design necessarily might include understanding some
> intermediate language specifically created for the purpose
> of the design. The situation is not so different from say,
> having to learn how to use lex and yacc when writing a
> Fortran compiler in the C language.

Ah!  OK, that makes sense.

> > Lisp has survived a VERY long time, is well defined, and
> > had some truly amazing software created using it - I at
> > least could use some convincing that BOOT has concrete
> > benefits that justify another learning curve.
> 
> No, you do not understand. BOOT is written in lisp and was
> an integral part of the original Axiom design. Yes, Axiom
> could have been designed without BOOT, but then one might
> have lost the advantages of the hierarchical design strategy.
> As a result it would have been more difficult to create
> nearly some complex and high level a language as SPAD.

So Lisp -> BOOT -> SPAD is kind of a "bootstrapping" process wherein
each level enables a more abstract or "high level" style of programming
than the previous stage?

> I might venture to guess that at least in part some of the
> differences in Maxima versus Axiom is due to this design
> strategy.

Well, it's hard to argue with success.  The more I see of Axiom the
more impressed I am.

> > Aldor I can see, since that level of Axiom coding is geared
> > very specifically toward mathematics, but below that level
> > it's not as clear to me.  This could simply be ignorance on
> > my part.
> 
> Think about building Axiom as a series of layers. The top
> level is the Axiom interpreter. Slightly below that would be
> the SPAD/Aldor library. Below that BOOT. And below that lisp.
> (Actually, Tim Daly has also described some other intermediate
> layers in Axiom that are also present.)

I guess I'm used to the line of thought that goes "the fewer
programming languages in a project, the better" but that might just be
the consequence of not thinking about the magnitude of the work
involved in the Axiom effort - it could very well be that the effort
put in to learn to work in each layer of abstraction pays off in
increased productivity.

> > > If one were to drop boot, I think one might risk
> > > the long term logical integrity of this design.
> > 
> > Are there some design documents somewhere from the original
> > project that detail this goal?  I confess the impression
> > I had of BOOT was that it was the consequence of irreconcilable
> > differences among the original developers about coding style,
> > but perhaps there was more to it than that.
> 
> Perhaps I am deluding myself, but I like to think that I am
> in a sense, continuing to represent that side of the Axiom
> project that maintained this apparently irreconcilable view -
> since Tim Daly is still here to represent the opposition. :)

Heh :-).  Fair enough.

> I think that this "tension" was (and still is) an important
> part of the reason for Axiom's phenomenal success in the
> representation of mathematics by computer. Of course that
> might be just empty philosophy and maybe we really cannot
> know why one project succeeds and another fails or how to
> do it again...

I think the effect of that tension is to keep people continually
arguing about and defending their design decisions, which is likely to
result in more robust decisions in the end.  I didn't mean to come off
as overly agressive, but I see reading my original email I might have
done so.  Sorry about that - I'm well aware I'm the introductory
student in this project.  Normally a concern in an open source project
is handling things in such a way that we attract developers, but this
is not an ordinary open source project and so I should worry less about
any barriors to entry posed by multiple languages and more about how
they benefit the quality and power of the result.

\start
Date: Sun, 23 Oct 2005 15:50:27 -0500
From: MathAction (unknown)
To: MathAction
Subject: [TeXmacs] HyperDoc and TeXMacs

Thanks Andrey. I followed your tips and HyperDoc now seems to work
except for problems created when I use HyperDoc to enter commands.

Varun

\start
Date: Sun, 23 Oct 2005 19:27:54 -0400
From: Tim Daly
To: list
Subject: literate programming

i'm having a side-debate, not on this list, with someone about the
use of tex and noweb as opposed to another tool, like javadoc. i
think it's worth repeating my portion of the discussion here as it
goes to the 30 year horizon issue and my basic motivation to rewrite
axiom in pamphlets.

for the purposes of understanding this note (since i can't share the
original without permission) just consider this as a reply to the
question "why not use javadoc" (insert your favorite pseudo-markup
language)

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

well, it's "ok", i guess.

the key flaw, in my opinion, is that it still makes the act of
programming the main task whereas literate programming is a complete
change of mindset making the creation of the document (as opposed to
the documentation) the primary task.

this approach has the same flaw as javadoc. the comments are placed
in structured places and nicely formatted. unfortunately they are
just that, "comments on the program".

it's hard to explain the difference if you don't see it. in literate
programming you're writing for people. in this kind of documentation
you're writing for the machine and commenting about it to people.

of course, if your target audience is another programmer like myself
then it's probably adequate.

at the technical level i'd have to ask why you'd want to settle for
a simple hack when you can have the full power of tex available. it's
like settling for basic when you can have lisp. if you're just going
to document a program one time then "basic-like" ability is fine. if
you're going to change your viewpoint to become a literate programmer
then "basic-like" capabilities are extremely limiting.

\start
Date: Sun, 23 Oct 2005 20:29:15 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Aldor and Lisp

> 
> --- Bill Page wrote: 
> > 
> > I am sorry Clifford but your question strikes me as
> > very peculiar.
> 
> Sorry, I didn't mean to offend - clearly I'm missing
> something fundamental.
> 
> > As I said, I thought this was obvious. 
> 
> We all got nervous in Calculus class when a professor said
> something was obvious ;-).
>

No offence. In fact my comment was an admission on my part
that perhaps what I wrote wasn't obvious except to me. I
think you are right to raise your antennae when someone
says something is "obvious". Sometimes this means either
that they are too lazy to explain properly or that they do
not in fact understand it themselves.

Anyway, I think your questions are good ones and serve as
motivation to write something that would otherwise not
be proper expressed.
 
> 
> So the way things are organized is SPAD built on BOOT built
> on Lisp? And the core reason for this is that BOOT makes it
> much easier to build SPAD than building it in straight Lisp
> would be?

Of course as Tim Daly would likely point out, that is a matter
of opinion conditioned by personal style and degree of
familiarity with programming in Lisp. But it is clear that
many (most?) of the original Axiom developers seem to have
held such a view.

> 
> > From my point of view BOOT forms a very important
> > intermediate level in Axiom because it allows programmers
> > to write at a more abstract level than just low level lisp.
> 
> This being the case, we should be very clear in the literate
> documentation on the purpose for each language, the reasons
> behind it, and the advantages to using it ...

We all seem to agree that documentation is key to Axiom's
future. The question is: how can we make sure that this
documentation gets written? And after it is written, that it
is accessible when someone needs it? I have been devoting some
effort to building tools to make this easier, such as the new
support for pamphlet files in the Axiom wiki

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

So now you can view the literate documentation for each module
of Axiom source online and correcting or expanding the
documentation is as easy as clicking 'edit' and then adding
or changing whatever you want.

But I am worried that just making it easy will not in itself
make it easier to write useful documentation because in order
to write documentation, you first have to understand what you
are writing about. And without existing documentation *that* is
the really hard part.

> 
> So BOOT was made different from Lisp to allow SPAD to be
> different? And the major objection to lisp is that it is too
> low level? (Sorry if those are more dumb questions, I'm just
> trying to get a sense of the modes of thinking involved.)

Maxim1: "there is no such thing as an easy job"
Maxim2: "there is not such thing as a dumb question"

Yes, I think you understand my point. But it is not quite
correct to call lisp "too low level". For many purposes lisp
can be considered to be a very high level language. But the
concept of level here is relative to the purpose. So, for the
purpose of expressing abstract mathematics, yes lisp was too
low level.

> 
> > Footnote:
> > 
> > 1\ Of course Aldor, as the next generation of SPAD, was
> > actually written in "C" not lisp (that is another story).
> > But the design of Aldor was inherited from SPAD.
> 
> So if at some point Aldor becomes free and we can switch to
> it, what are the implications for Lisp and BOOT in Axiom?
>  

Ah, another very good question!

Even with Aldor to replace SPAD, lisp and BOOT are still very
important for the interpreter part of Axiom. The interpreter
provides the user interface and must translate user instructions
into operations from the Axiom library.

It is possible to go further and to imagine writing the Axiom
interpreter itself in Aldor. One can guess that this is one of
the reasons that Aldor was specifically designed also to work
as a stand-alone compiler and not just as the Axiom library
compiler like SPAD. I do not know how much work, if any, has
ever been done along these lines. Unlike changing Aldor for
SPAD as the library compiler, changing the interpreter to Aldor
would not be just an incremental change. The interpreter would
have to be completely re-written from ground up.

Personally I am not sure whether re-writing the interpreter in
Aldor would be such a good idea. Certainly one would gain the
advantage of easily working at the same level as the code in
which the mathematical library is written. But outside of it's
application as a replacement for SPAD, Aldor is still largely
an experimental language. I think it's advantages and disadvantages
relatively to lisp and BOOT or other high level object-oriented
languages like Java, Python, Haskell and Ocaml are largely
unknown. In a sense, this is where research in the Axiom project
left-off when the money ran out... But it is one of the parts
of Axiom that intrigues me most.

> OK.  In that case proper documentation becomes of paramount 
> importance, and I would say one of our highest priority tasks
> (if BOOT survives the Aldor conversion) should be to get our
> languages documented so we can have a reasonable expectation
> of people being able to learn and program in them quickly.

I don't think it is possible to say that too often unless
saying it happens to get in the way of actually doing it ...
:)

> 
> So Lisp -> BOOT -> SPAD is kind of a "bootstrapping" process
> wherein each level enables a more abstract or "high level" style
> of programming than the previous stage?

Hence the name "BOOT".

> 
> I guess I'm used to the line of thought that goes "the fewer
> programming languages in a project, the better" but that might
> just be the consequence of not thinking about the magnitude of
> the work involved in the Axiom effort - it could very well be
> that the effort put in to learn to work in each layer of
> abstraction pays off in increased productivity.

I would say that "productivity" is not so much the issue as
"creativity". Working at a higher level of abstraction allows
you to concentrate on different aspects of a problem. And of
course this mirrors how a lot of mathematics is also done. So
this approach fits the application quite well.

> 
> > I think that this "tension" was (and still is) an important
> > part of the reason for Axiom's phenomenal success in the
> > representation of mathematics by computer. Of course that
> > might be just empty philosophy and maybe we really cannot
> > know why one project succeeds and another fails or how to
> > do it again...
> 
> I think the effect of that tension is to keep people
> continually arguing about and defending their design
> decisions, which is likely to result in more robust
> decisions in the end.

Maybe that is a good thing, maybe it is a bad thing. I think
we have to try to make sure that it does not lead to a stalemate
and end up reducing everyone's motivation to make progress
towards improving Axiom as a whole. I think one thing that we can
use it for is to use it as motivation to continue writing about
and hopefully, documenting more of Axiom.

> I didn't mean to come off as overly aggressive, but I see reading
> my original email I might have done so.  Sorry about that - I'm
> well aware I'm the introductory student in this project.

Not at all. This might sound "soapy" but I do think that when
you stop being a student is when you stop learning anything new.
So I hope we are all students here.

> Normally a concern in an open source project is handling things
> in such a way that we attract developers, but this is not an
> ordinary open source project and so I should worry less about
> any barriers to entry posed by multiple languages and more about
> how they benefit the quality and power of the result.
> 

Yes, the "spin" you put on it is important. I think you are
right to be concerned about how to attract developers to the
Axiom project. One thing I am sure Axiom can offer open source
developers is the challenge of working on a leading edge
research project. And I think this is made even more enjoyable
with the knowledge that this line of research already dates
back more than 30 years.

\start
Date: Sun, 23 Oct 2005 21:35:48 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Aldor and Lisp

> On October 23, 2005 2:51 PM C Y wrote:
> > 
> > So the way things are organized is SPAD built on BOOT built
> > on Lisp? And the core reason for this is that BOOT makes it
> > much easier to build SPAD than building it in straight Lisp
> > would be?
> 
> Of course as Tim Daly would likely point out, that is a matter
> of opinion conditioned by personal style and degree of
> familiarity with programming in Lisp. But it is clear that
> many (most?) of the original Axiom developers seem to have
> held such a view.

Hmm.  I guess in a situation like that he who codes first and best wins
:-).  I do know enough about language debates to know that no
resolution is possible and such discussions have no end ;-).  I need to
study what's going on much more carefully to see if I can "catch the
feel of" the intent of BOOT.


> > This being the case, we should be very clear in the literate
> > documentation on the purpose for each language, the reasons
> > behind it, and the advantages to using it ...
> 
> We all seem to agree that documentation is key to Axiom's
> future. The question is: how can we make sure that this
> documentation gets written? 

In this particular case, that would require someone knowing quite a lot
about the BOOT language and its design philosophy.  Aside from the time
honored method of drawing up a list of such people and bothering them
;-) the only way I know to do it would be to start from the beginning
and sort of "learn by analysis" what the code is doing, and deduce from
that the philosophy and intent of the program.

> And after it is written, that it
> is accessible when someone needs it? I have been devoting some
> effort to building tools to make this easier, such as the new
> support for pamphlet files in the Axiom wiki
> 
>   http://wiki.axiom-developer.org/axiom--test--1
> 
> So now you can view the literate documentation for each module
> of Axiom source online and correcting or expanding the
> documentation is as easy as clicking 'edit' and then adding
> or changing whatever you want.

That should be an excellent answer to increasing accessibility and the
possibility of small scale corrections, but to build the foundation we
need someone who can write up the original goals and how BOOT achieves
them.

> But I am worried that just making it easy will not in itself
> make it easier to write useful documentation because in order
> to write documentation, you first have to understand what you
> are writing about. And without existing documentation *that* is
> the really hard part.

Bingo.  In some ways I guess that's why the thought of major changes at
that level doesn't scare me as much as it should - thanks to the
literate programming ideal the amount of work needed to do the job
properly is virtually the same for a rewrite as to understand properly
the current code.  The advantage should be that once done it won't have
to be redone in any significant way for a long, long time.

> > So BOOT was made different from Lisp to allow SPAD to be
> > different? And the major objection to lisp is that it is too
> > low level? (Sorry if those are more dumb questions, I'm just
> > trying to get a sense of the modes of thinking involved.)
> 
> Maxim1: "there is no such thing as an easy job"
> Maxim2: "there is not such thing as a dumb question"
> 
> Yes, I think you understand my point. But it is not quite
> correct to call lisp "too low level". For many purposes lisp
> can be considered to be a very high level language. But the
> concept of level here is relative to the purpose. So, for the
> purpose of expressing abstract mathematics, yes lisp was too
> low level.

Ah :-).  Got it.

> > > Footnote:
> > > 
> > > 1\ Of course Aldor, as the next generation of SPAD, was
> > > actually written in "C" not lisp (that is another story).
> > > But the design of Aldor was inherited from SPAD.
> > 
> > So if at some point Aldor becomes free and we can switch to
> > it, what are the implications for Lisp and BOOT in Axiom?
> >  
> 
> Ah, another very good question!
> 
> Even with Aldor to replace SPAD, lisp and BOOT are still very
> important for the interpreter part of Axiom. The interpreter
> provides the user interface and must translate user instructions
> into operations from the Axiom library.

Hmm.  A bit off topic, but I've been wondering about the interpreter
vs. compiler a bit - IIRC there have been one or two cases we've run
into where the interpreter handles code differently than the compiler
does - e.g. making assumptions the compiler won't.  I can see why this
would be desirable (programming often calls for avoiding assumptions
that are normally quite useful to the user) but it should also be very
carefully documented and discussed, because it also would seem to allow
for the situation of someone testing code in the interpreter, saving it
to a file, and getting different behavior when they try to compile and
run it.  Am I missing something?

> It is possible to go further and to imagine writing the Axiom
> interpreter itself in Aldor. One can guess that this is one of
> the reasons that Aldor was specifically designed also to work
> as a stand-alone compiler and not just as the Axiom library
> compiler like SPAD. I do not know how much work, if any, has
> ever been done along these lines. Unlike changing Aldor for
> SPAD as the library compiler, changing the interpreter to Aldor
> would not be just an incremental change. The interpreter would
> have to be completely re-written from ground up.

Eeek.  Of course, Tim already mentioned that the interpreter needs to
become a literate document too, so perhaps while it's being documented
it could be ported...  

> Personally I am not sure whether re-writing the interpreter in
> Aldor would be such a good idea. Certainly one would gain the
> advantage of easily working at the same level as the code in
> which the mathematical library is written. But outside of it's
> application as a replacement for SPAD, Aldor is still largely
> an experimental language. I think it's advantages and disadvantages
> relatively to lisp and BOOT or other high level object-oriented
> languages like Java, Python, Haskell and Ocaml are largely
> unknown. In a sense, this is where research in the Axiom project
> left-off when the money ran out... But it is one of the parts
> of Axiom that intrigues me most.

Hmm.  Well, if Axiom is modular enough perhaps different interpreters
could be swapped in and out to see how they work, if different
implementations were coded up?

> > OK.  In that case proper documentation becomes of paramount 
> > importance, and I would say one of our highest priority tasks
> > (if BOOT survives the Aldor conversion) should be to get our
> > languages documented so we can have a reasonable expectation
> > of people being able to learn and program in them quickly.
> 
> I don't think it is possible to say that too often unless
> saying it happens to get in the way of actually doing it ...
> :)

I'm innocent here - I don't know enough about BOOT to even ask the
right questions on the first try!  It would be nice if one of the
original architects could be lured into the free project to write up
their work...

> > So Lisp -> BOOT -> SPAD is kind of a "bootstrapping" process
> > wherein each level enables a more abstract or "high level" style
> > of programming than the previous stage?
> 
> Hence the name "BOOT".

Oh!  Duh :-).  It's beginning to make sense, little by little...

> I would say that "productivity" is not so much the issue as
> "creativity". Working at a higher level of abstraction allows
> you to concentrate on different aspects of a problem. And of
> course this mirrors how a lot of mathematics is also done. So
> this approach fits the application quite well.

True.

> > I think the effect of that tension is to keep people
> > continually arguing about and defending their design
> > decisions, which is likely to result in more robust
> > decisions in the end.
> 
> Maybe that is a good thing, maybe it is a bad thing. I think
> we have to try to make sure that it does not lead to a stalemate
> and end up reducing everyone's motivation to make progress
> towards improving Axiom as a whole.

Definitely.  I think Tim would agree that with or without BOOT in there
Axiom is worth moving ahead with full steam.  And the beauty of it is
the mathematical part (e.g. the meaty part) doesn't have to care about
BOOT vs. Lisp :-).

> I think one thing that we can
> use it for is to use it as motivation to continue writing about
> and hopefully, documenting more of Axiom.

Agreed.  I think maybe I'm catching this bug a bit too much, but I'm
beginning to like this whole "write the document, with the code being
simply a part of the document" idea, regardless of how much time it
takes to get up to speed.  If I'm thinking about it correctly, language
issues become a bit moot at that point - in theory someone could take a
document, read it, redo all the code segments in their language of
choice, and hey-presto a port to a new language.  I know it's not quite
that simple in reality, but it would be a lot easier than any other way
I've ever heard of.  And you also have the advantage that in order to
write a proper document, the coder needs to really understand what
he/she is doing.  Which may solve quite a few problems right there ;-).

> > Normally a concern in an open source project is handling things
> > in such a way that we attract developers, but this is not an
> > ordinary open source project and so I should worry less about
> > any barriers to entry posed by multiple languages and more about
> > how they benefit the quality and power of the result.
> 
> Yes, the "spin" you put on it is important. I think you are
> right to be concerned about how to attract developers to the
> Axiom project. One thing I am sure Axiom can offer open source
> developers is the challenge of working on a leading edge
> research project. And I think this is made even more enjoyable
> with the knowledge that this line of research already dates
> back more than 30 years.

I think once the core parts of the system are documented and stable, we
will be able to begin building momentum.  Axiom has the virtually
unique challenge of needing to attract mathematical authors as much as
(or even more than!) regular coders.  As with most such things,
momentum is only built slowly over time - as a new project (at least as
open source) Axiom is currently risky and not well established.  The
only cure for this is time and work, but I think Axiom has got what it
takes.  I think Aldor's release as free software, if it does happen,
will set a lot of events in motion.  Probably including the re-tooling
of Aldor into pamphlet files ;-).

Now, back to the murky world of units and dimensions! :-)

\start
Date: Mon, 24 Oct 2005 10:27:52 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#224 ICARD fails to display database info ] (new) 

The ICARD domain implements a container of information
about the AXIOM library
\begin{axiom}
info:="diferentiate"::ICARD
info(name)
info(kind)
info(abbreviation)
\end{axiom}

\start
Date: Tue, 25 Oct 2005 11:06:25 -0500
From: MathAction (Bertrand Roessli)
To: MathAction
Subject: [Axiom-mail] vector

Hello,

I am really new to axiom, so my question is 
naive. 
How is it possible to multiply two vectors??

thanks,

-- 
Dr. Bertrand Roessli
Laboratory for Neutron Scattering
ETHZ and Paul Scherrer Institut
CH-5232 Villigen, PSI

\start
Date: Tue, 25 Oct 2005 11:50:59 -0500
From: MathAction (Vanuxem)
To: MathAction
Subject: [Axiom-mail] vector

Le mardi 25 octobre 2005  11:32 +0200, Bertrand Roessli a crit :
> Hello,
> 
> I am really new to axiom, so my question is 
> naive. 
> How is it possible to multiply two vectors??

multiplication element by element

a:= vector [1,2,3,5,6]
map(*,a,a)

otherwise use Matrix 

a:= matrix [[1,2,3,4,5,6]]
a * transpose a

\start
Date: Tue, 25 Oct 2005 12:05:58 -0500
From: MathAction (root)
To: MathAction
Subject: [Axiom-mail] vector

)clear all

-- make three vectors
u : VECTOR INT := new(5,12)
v : VECTOR INT := vector([1,2,3])
w : VECTOR INT := vector([2,3,4])
-- multiply them
cross(v,w)
-- dot product
dot(v,w)
-- ask for the length
#(v)
-- access an element
v.2
-- set an element
v.3 := 99
-- show the vector
v
-- multiply by a constant
5 * v
-- on either side
v * 7
-- add them
v + w
-- substract them
v - w
-- display all possible functions
)show Vector(Integer)

\start
Date: Tue, 25 Oct 2005 14:37:38 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Colloquium] 

++added:
    How to write f:A->(B,C) in Axiom


++added:
  - [Complex Polynomial]

    Should that be 'p:Complex Polynomial Integer' or
    'p:Polynomial Complex Integer'? Is 'conjugate(p)' of
    the same type as 'p'?

\start
Date: Tue, 25 Oct 2005 14:41:37 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Complex Polynomial] (new) 

*Andrea Bedini wrote:*

I'm just learning how to do some computations with Axiom,
but I've a problem with complex numbers.
 
Why this evalutate to zero ?
 
\begin{axiom}
A: Complex Polynomial Integer
A*conjugate A - A^2
\end{axiom}
 
Definitely wrong.  It looks like the source of the problem is:
\begin{axiom}
conjugate(a)
\end{axiom}

*Bill Page wrote:*

Of course I agree that it is wrong. But what would you expect
the answer to::

  conjugate(a)

to be? It could return unevaluated as just::

  conjugate(a)

but then what should the Type: be? Is such an expression
still necessarily a Complex Polynomial Integer?

This is dangerously close to the discussion that we had some
months ago about the meaning of "indeterminants", objects
which have a type but no specific value. For example, I can
say::

  A:Integer

but if I write::

  A+1

If you answered "yes" to the idea that 'conjugate(a)' is still
of type Complex Polynomial Integer, then surely 'A+1' is still
of type Integer is the same sense, but Axiom complains that
"A has not been given a value".

Perhaps evaluating the expression::

  conjugate(a)

should also complain about the lack of a value?

>From root Wed Dec 29 00:47:32 -0600 2004
From: root
Date: Wed, 29 Dec 2004 00:47:32 -0600
Subject: complex numbers

seems to be a categorical error of some sort.

A: Complex Polynomial Integer

tells the system that 'A' is expected to have a value which is
Complex Polynomial Integer.

'conjugate' works on values, not potential values.

Thus, conjugate(A) has no meaning as 'A' has no value.
This should probably be an error.

If axiom could work with so that conjugate worked on the type
then axiom could work at some sort of an 'axiomatic' level
rather than a symbolic computation level. Perhaps when we join
forces with the ACL2 crowd we could state certain theorems and
have them applied in the absence of a value.

Tim

>From BillPage Wed Dec 29 01:02:59 -0600 2004
From: Bill Page
Date: Wed, 29 Dec 2004 01:02:59 -0600
Subject: complex numbers

Tim,


I know that this is opening up the whole big subject again,
but I do think that Axiom is already "two-faced" about this.

Consider for example that we can write:

(7) -> A: Complex Polynomial Integer
                                         Type: Void
(8) -> B: Complex Polynomial Integer
                                         Type: Void
(9) -> A+B

   (9)  B + A
                               Type: Complex Polynomial Integer

Neither A or B "has a value" but Axiom has no trouble agreeing
that A+B is still of type Complex Polynomial Integer.

I do not see any essential difference between this and

(10) -> A:Integer
                                         Type: Void
(11) -> B:Integer
                                         Type: Void
(12) -> A+B

   A is declared as being in Integer but has not been given a value.

Regards,
Bill Page.


>From root Wed Dec 29 01:36:08 -0600 2004
From: root
Date: Wed, 29 Dec 2004 01:36:08 -0600
Subject: complex numbers


Clearly you're right and I agree with you.

The problem, as I see it, is that there are subtle degrees of meaning
that are easily stepped around when you work on paper but must be
clarified in computational mathematics.

A: Integer

might mean that 1) 'A' will hold a value which is an integer
under interpretation (1)

A+1 

is an error since 'A' has no value. But what does the type of
an unbound thing mean? Lisp assigns types to the values, not
the boxes. This is like labeling a box 'television'.

or perhaps that 2) 'A' is an indefinite object of type integer
under interpretation (2)

A+1

is another indeterminant integer, where '+' comes from Integer.

or perhaps that 3) 'A' obeys the laws applied to integers
under interpretation (3)

A+1

is a polynomial with 2 integers, representing a constant, where
'+' comes from Polynomial.

or perhaps that 4) 'A' is a symbol which hold integers
under interpretation (4)

A+1

is a polynomial in A with integer coefficients ignoring 'A's type
where '+' comes from Polynomial.

or perhaps that 5) 'A' is an element of a Ring and theorems can be applied
under interpretation (5)

A+1

is 'B', a new member of the Ring since '+' is a ring operator and both
'A' and '1' are ring elements. Ideally Axiom's types would be decorated
with axioms, like the ring axioms making reasoning about unbound but
typed objects possible. The '+' comes from the Category axioms of Integer.


The exact interpretation chosen appears to be dictated by the 
underlying code and is not the same everywhere.

Axiom is the product of many people, some of whom have chosen
different interpretations. Indeed, some of the interpretations
didn't exist before the computational aspects of mathematics
came into play.

There are quite a few areas of research that could be followed.
Indeed, working out the implications of the several meanings of 
'A' is a PhD topic, and a rather hard one at that. The issue 
heads off into questions of provisos, questions of reasoning with
theorems and axioms, etc.

Axiom's main strength has always been as a research platform where
it is possible to work out these ideas and reduce them to practice.

Unfortunately, research funding seems nowhere to be found.

Tim


>From BobMcElrath Wed Dec 29 12:12:44 -0600 2004
From: Bob McElrath
Date: Wed, 29 Dec 2004 12:12:44 -0600
Subject: complex numbers


root [Tim Daly] wrote:
> Clearly you're right and I agree with you.
> 
> The problem, as I see it, is that there are subtle degrees of meaning
> that are easily stepped around when you work on paper but must be
> clarified in computational mathematics.

Why cannot we allow *all*?  I expect I should be able to coerce 'A+1' to
an Integer, Polynomial Integer, Expression Integer, etc.  The default
seems to be Integer, which seems fine.

The error seems to be in the Polynomial domain:

    (16) -> c:Complex Integer           
                                                      Type: Void
    (17) -> conjugate(c)     
     
       c is declared as being in Complex Integer but has not been given a 
          value.
    (17) -> c:Complex Polynomial Integer
                                                      Type: Void
    (18) -> conjugate(c)

       (18)  c
                                    Type: Complex Polynomial Integer

Adding the Polynomial to its domain causes this to go wrong...

    (19) -> c:Polynomial Complex Integer
                                                                       Type: Void
    (20) -> conjugate(c)
       There are 4 exposed and 1 unexposed library operations named 
          conjugate having 1 argument(s) but none was determined to be 
        ...

I'm surprised this doesn't work.  A Polynomial on a Ring is still a
member of that ring and should inherit its functions.  (in this case,
conjugate)  It also strikes me that Polynomial Complex Integer is the
proper type here, not Complex Polynomial Integer...clearly they are
inequivalent.

> A: Integer
> 
> might mean that 1) 'A' will hold a value which is an integer
> under interpretation (1)
> 
> A+1 
> 
> is an error since 'A' has no value. But what does the type of
> an unbound thing mean? Lisp assigns types to the values, not
> the boxes. This is like labeling a box 'television'.

This is the approach taken by Integer, Complex, and Float it seems.

> or perhaps that 2) 'A' is an indefinite object of type integer
> under interpretation (2)
> 
> A+1
> 
> is another indeterminant integer, where '+' comes from Integer.
> 
> or perhaps that 3) 'A' obeys the laws applied to integers
> under interpretation (3)
> 
> A+1
> 
> is a polynomial with 2 integers, representing a constant, where
> '+' comes from Polynomial.

I cannot seem to construct an example of type (3).  Given: c:Integer and
I want to construct a Polynomial Integer containing 'c', how would I do
it?

> or perhaps that 4) 'A' is a symbol which hold integers
> under interpretation (4)
> 
> A+1
> 
> is a polynomial in A with integer coefficients ignoring 'A's type
> where '+' comes from Polynomial.

The type of 'A' cannot be ignored since 'A+1' must Polynomial must have
a Field such as Integer in its constructor.

> or perhaps that 5) 'A' is an element of a Ring and theorems can be applied
> under interpretation (5)
> 
> A+1
> 
> is 'B', a new member of the Ring since '+' is a ring operator and both
> 'A' and '1' are ring elements. Ideally Axiom's types would be decorated
> with axioms, like the ring axioms making reasoning about unbound but
> typed objects possible. The '+' comes from the Category axioms of Integer.

Now this truly is a research project.  ;)

> The exact interpretation chosen appears to be dictated by the 
> underlying code and is not the same everywhere.
> 
> Axiom is the product of many people, some of whom have chosen
> different interpretations. Indeed, some of the interpretations
> didn't exist before the computational aspects of mathematics
> came into play.

I think this *must* be clarified, and a unifying set of assumptions be
applied across all domains.

> There are quite a few areas of research that could be followed.
> Indeed, working out the implications of the several meanings of 
> 'A' is a PhD topic, and a rather hard one at that. The issue 
> heads off into questions of provisos, questions of reasoning with
> theorems and axioms, etc.

This does not seem so hard, but maybe I am being naive.

\start
Date: Tue, 25 Oct 2005 14:53:20 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [FAQ] 

How to multiply two vectors??

  Multiplication element by element:

*Vanuxem Grégory replies:*

\begin{axiom}
a:= vector [1,2,3,5,6]
map(*,a,a)
\end{axiom}

otherwise use Matrix:
\begin{axiom}
a:= matrix [[1,2,3,4,5,6]]
a * transpose a
\end{axiom}

Tim Daly replies:

make three vectors
\begin{axiom}
)clear all
u : VECTOR INT := new(5,12)
v : VECTOR INT := vector([1,2,3])
w : VECTOR INT := vector([2,3,4])
\end{axiom}
multiply them
\begin{axiom}
cross(v,w)
\end{axiom}
dot product
\begin{axiom}
dot(v,w)
\end{axiom}
ask for the length
\begin{axiom}
#(v)
\end{axiom}
access an element
\begin{axiom}
v.2
\end{axiom}
set an element
\begin{axiom}
v.3 := 99
\end{axiom}
show the vector
\begin{axiom}
v
\end{axiom}
multiply by a constant
on either side
\begin{axiom}
5 * v
v * 7
\end{axiom}

add them
\begin{axiom}
v + w
\end{axiom}

substract them
\begin{axiom}
v - w
\end{axiom}

display all possible functions
\begin{axiom}
)show Vector(Integer)
\end{axiom}

\start
Date: Tue, 25 Oct 2005 19:37:39 -0400
From: Tim Daly
To: list
Subject: documentation

ok, people, we're clearly missing a trend here...

the latest idea i've seen in documentation is movies.
we need to figure out how to make a movie that shows how to start 
up an axiom session, perform a computation, and shut it down.

once we can figure out that technology we can each make movies of
our portions. i could make a movie of the steps needed to build a
system.

it would be a fast and effective way to communicate user interaction.

anybody know how to do this?

\start
Date: Tue, 25 Oct 2005 19:50:03 -0400
From: Tim Daly
To: Bill Page
Subject: documentation

did you see this web-based file storage mechanism?
http://www.msblabs.org/tinydisk/index.php

my thought is that we could use something like this to
store pamphlet files for algebra. then the user could
access the files online with a "drag and drop" mechanism
that would pick up the file from a web page, drop it into
a running axiom, compile it, load it, and make it available.

\start
Date: Tue, 25 Oct 2005 19:37:38 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: documentation

> ok, people, we're clearly missing a trend here...
> 
> the latest idea i've seen in documentation is movies.
> we need to figure out how to make a movie that shows how to start 
> up an axiom session, perform a computation, and shut it down.
>
> once we can figure out that technology we can each make movies of
> our portions. i could make a movie of the steps needed to build a
> system.
> 
> it would be a fast and effective way to communicate user interaction.
> 
> anybody know how to do this?

Are you thinking of the SLIME movie that's been getting rave reviews?
(it's about an hour and rather in depth) 
http://bc.tech.coop/blog/050728.html

(for those without bittorrent here's the 149 meg mov file:
http://common-lisp.net/movies/slime.mov)

Or just something shorter?  In the case of the above movie I don't know
how it was made, but there is a flash demo of SLIME made using vnc here
(which I can't play on my work computer so I have no idea if it's any
good):
http://www.unixuser.org/~euske/vnc2swf/slime.html

I've never tried the software used for this
(http://www.unixuser.org/~euske/vnc2swf/ and
http://www.unixuser.org/~euske/vnc2swf/edit_vnc2swf.html) so I can't
comment on it.  Apparently there also exists the program wink
(http://www.debugmode.com/wink/) which is a free download but not open
source.  Also for Linux there is xvidcap (http://xvidcap.sf.net) which
will produce mpeg files.

There are movies that have been made of the new e17 environment using
xvidcap - based on a comment from the e17 author xvidcap isn't great
for smooth motion capture but I think for what we will be using it for
it would work fine.  I think this is one of them (not sure how avi
conversion was done): http://www.rasterman.com/files/e17_movie-02.avi

Not sure how to actually use xvidcap - normally I don't do much with
video on Linux.  Also I don't know anything about recording audio.  

\start
Date: Tue, 25 Oct 2005 23:07:19 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: documentation

well i'm thinking that volume 1, the tutorial volume could come with
a CD that contains the sources and/or a DVD that contains sections,
one per topic, that we could continue to expand. 

that way we can create documentation that is easy to learn.
just follow the leader kind of docs.

and other useful docs, like how to fill out a proper bug report,
how to use history files, how to write a simple input file,
how to draw a graph, etc.

i'll look at the tools you mentioned.

\start
Date: Tue, 25 Oct 2005 23:30:17 -0400
From: Tim Daly
To: list
Subject: summer of code 2006

We participated in the Summer of Code last year as a sub-project
of LispNYC. Because of the time constraints last year there was
a bit of confusion (we got a direct accept notice then got dropped).
Kai Kaminski did an excellent job for us and we are quite pleased
with the result.

We have collected some problems we think would make good summer projects
and will continue to do so for our own purposes. If you plan to have
another summer of code in 2006 I'd like to get some idea of the feedback
you got from the 2005 effort.

Are there criteria we should strive to achieve that will make us more
acceptable when the time comes? If we have advance notice I can contact
various professors at universities who can recommend candidates.

I thought the whole summer of code idea was excellent and, properly
managed, could really help open source projects such as Axiom.

\start
Date: Wed, 26 Oct 2005 07:46:51 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: documentation

On Tuesday, October 25, 2005 10:38 PM C Y wrote:
>
> --- Tim Daly wrote:
>
> >
> > the latest idea i've seen in documentation is movies.
> > we need to figure out how to make a movie that shows how to
> > start up an axiom session, perform a computation, and shut
> > it down.
> ...
>
> There is a flash demo of SLIME made using vnc here (which I can't
> play on my work computer so I have no idea if it's any good):
> http://www.unixuser.org/~euske/vnc2swf/slime.html

Works real nice for me on windows with both FireFox 1.0.7 with
Flash plug-in installed and Internet Explorer 6 with active X
enabled.

>
> I've never tried the software used for this
> (http://www.unixuser.org/~euske/vnc2swf/ and
> http://www.unixuser.org/~euske/vnc2swf/edit_vnc2swf.html) so
> I can't comment on it.

I think it works very well. It works on both Windows and Linux.
Here is my first attempt at a movie that shows how to edit a
pamphlet file on MathAction.

http://page.axiom-developer.org/pamphlet-2.html

It is also possible to do this with sound, but I didn't have
the necessary hardware last night.

> Apparently there also exists the program wink
> (http://www.debugmode.com/wink/) which is a free download but
> not open source.

This one is pretty neat too - also works on both Windows and
Linux. Here is a movie made with wink that includes some
annotations added to some of the frames.

http://page.axiom-developer.org/pamphlet-1.html

vnc2swf is harder to setup but it seems a little faster and
smoother than wink, at least on my hardware (1GHz, 512Mb.)
In general I think that if you are going to do video, that
faster the machine you use, the better.

\start
Date: Wed, 26 Oct 2005 08:04:38 -0400
From: Tim Daly
To: Bill Page
Subject: Re: documentation

excellent!

pamphlet-1 played well on my windows machine without problems.
pamphlet-2 never starts.

the edit example you show is perfect...exactly what i was thinking.
these could easily make up a volume in the tutorial.

how long did it take to create?
how large is it?

\start
Date: Wed, 26 Oct 2005 09:38:30 -0400
From: Bill Page
To: Tim Daly
Subject: RE: documentation

On Wednesday, October 26, 2005 8:05 AM you wrote:
>
> pamphlet-1 played well on my windows machine without
> problems. pamphlet-2 never starts.
>

I am sorry. I had a typo in the html coding for pamphlet-2.
It should work fine now.

> the edit example you show is perfect...exactly what i was
> thinking. these could easily make up a volume in the
> tutorial.

You mean like on CDrom, right? We could stream them too
as MPEG or other format, but they would take up quite a
lot of disk space if we were to get ambitious.

>
> how long did it take to create?

About 10 minutes, after I downloaded and installed the
software. I took about 10 minutes to install Wink and
maybe about 1/2 hour to install vnc2swf because of the
dependency on RealVNC and less than turn-key packaging.

Both packages are very easy to use once installed.
vnc2swf is more command-line oriented and has a some
associated editing, mixing and conversion utilities.  

> how large is it?
>

The shockwave file (SWF) for pamphlet-1 is 1.5 Mbyte and
pamphlet-2 is 2 Mbyte. They are both about 2 minutes long
so very roughly you can figure about 1 Mbyte/minute. I
think there may be some compression options available that
I am not using yet.

\start
Date: Wed, 26 Oct 2005 13:28:50 -0400
From: Bill Page
To: Tim Daly
Subject: RE: documentation

On Wednesday, October 26, 2005 7:47 AM I wrote:
> ...
> >
> > (http://www.unixuser.org/~euske/vnc2swf
>
> I think it works very well. It works on both Windows and Linux.

Here is my second attempt at a movie that shows how to edit a
pamphlet file on MathAction - with sound!

 http://page.axiom-developer.org/pamphlet-3.html

(music just to keep people from being bored while they watch :)

Of course it is also possible to do this with a recorded voice,
but I didn't have a microphone on this old machine.

\start
Date: Wed, 26 Oct 2005 19:19:50 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [mirrors] 

href="../WishList"

href="../theAxiomCommunity"

href="../AxiomDocumentation"

href="../IssueTracker"

href="../AxiomPromotion"

href="/public/donate.html"

<a href="<dtml-if go>&dtml-go;<dtml-else>../AxiomDownload</dtml-if>" class="hover-red">

onclick='window.location.href ="<dtml-if go>&dtml-go;<dtml-else>../AxiomDownload</dtml-if>";' /></a>

<a href="/public/donate.html" class="hover-red">

onclick='window.location.href ="<dtml-if go>&dtml-go;<dtml-else>../AxiomDownload</dtml-if>";'/></a>

\start
Date: Wed, 26 Oct 2005 21:24:34 -0400
From: Tim Daly
To: Bill Page
Subject: Re: documentation

cool, man, panther cool.

i'm off to try wink. i like the idea of adding comment balloons
to draw attention to important points.

\start
Date: Wed, 26 Oct 2005 19:41:46 -0700
From: Bob McElrath
To: list
Subject: Fwd: [Bug 120198] [trk] Rendering errors on MathML demos

Several significant improvements to Mozilla's MathML rendering have just
been checked in to their tree.  These will all be in Firefox 1.5 when it
is released.

----- Forwarded message from bugzilla-daemon@mozilla.org -----

> Do not reply to this email.  You can add comments to this bug at
> https://bugzilla.mozilla.org/show_bug.cgi?id=120198
> 
> ------- Comment #88 from rbs@maths.uq.edu.au  2005-10-26 19:09 PDT -------
> Re: Comment #86
> &nbsp; has been fixed in bug 297464.

----- End forwarded message -----
----- Forwarded message from bugzilla-daemon@mozilla.org -----

> Do not reply to this email.  You can add comments to this bug at
> https://bugzilla.mozilla.org/show_bug.cgi?id=120198
> 
> ------- Comment #89 from rbs@maths.uq.edu.au  2005-10-26 19:12 PDT -------
> Re: Comment #78
> Gecko 1.8-based browsers have significant inter-space improvements via bug
> 306543.

----- End forwarded message -----
----- Forwarded message from bugzilla-daemon@mozilla.org -----

> Do not reply to this email.  You can add comments to this bug at
> https://bugzilla.mozilla.org/show_bug.cgi?id=120198
> 
> ------- Comment #90 from rbs@maths.uq.edu.au  2005-10-26 19:21 PDT -------
> Re: Comment #88
> I meant bug 247151.
> 
> Re: Comment #75
> Gaps in stretchy characters have been fixed in bug 307157 and bug 311046.
> The problems with 2061 (ApplyFunction) and 2062 (Invisible Times) were also
> fixed in bug 306543.
> 
> All these fixes will be in Gecko 1.8-based browsers such as Firefox 1.5.

\start
Date: Wed, 26 Oct 2005 19:59:09 -0700
From: Bob McElrath
To: list
Subject: blahtex

There is a new tool in use by the mediawiki folks to translate tex to
MathML:

    http://meta.wikimedia.org/wiki/Blahtex

It is very similar in spirit and operation to itex2mml.  Also like
itex2mml it is basically a single yacc program.

Unfortunately like itex2mml, it is a single yacc program, and as such
will probably never implement properly \def, \newcommand, and has some
syntactical differences from tex.

\start
Date: Wed, 26 Oct 2005 23:07:50 -0400
From: Tim Daly
To: list
Subject: fyi

there appears to be mail coming from the user 'admin' 
at 'axiom-developer.org'. this is faked. there is no 'admin' user.
ignore it.

\start
Date: Thu, 27 Oct 2005 01:16:32 -0400
From: Bill Page
To: Tim Daly
Subject: RE: documentation

On Wednesday, October 26, 2005 9:25 PM you wrote:

> > http://page.axiom-developer.org/pamphlet-3.html
>
> cool, man, panther cool.
>

It turns out that there is a way to do audio with Wink as
well. See:

http://www.debugmode.com/userforums/viewtopic.php?t=2080

SWFtools http://www.swftools.org and Audacity (way cool!)
http://audacity.sourceforge.net are also, like Wink,
available on both linux and windows.

> i'm off to try wink. i like the idea of adding comment
> balloons to draw attention to important points.
>

How is Wink working on linux?

Here's my entertainment for tonight. :) It's a demonstration
of installing Axiom on Windows:

http://page.axiom-developer.org/AxiomIn5.html

I created the screen video and balloon markup with Wink
(on a faster workstation than before) and then added the
sound track with Audacity and SWFtools.

Fun.

So, do you have any ideas for other "productions" and
about how we should package these things?

\start
Date: Thu, 27 Oct 2005 01:52:23 -0400
From: Bill Page
To: Tim Daly
Subject: RE: documentation

On Thursday, October 27, 2005 1:17 AM I wrote:

> ...
> http://page.axiom-developer.org/AxiomIn5.html
>
> I created the screen video and balloon markup with Wink
> (on a faster workstation than before) and then added the
> sound track with Audacity and SWFtools.

Just for the record, the soundtrack is a little re-mixed from
the version of "On The Trail" here:

http://class-midi.com/canyon.htm

The midi sequences are by Robert C. Goodyear and of course
the music is by Ferde Grof=E9.

http://www.sbgmusic.com/html/teacher/reference/composers/grofe.html

So far as I can tell there are no copyright restrictions.

\start
Date: 27 Oct 2005 12:58:26 +0200
From: Martin Rubey
To: list
Subject: compile with Debian fails

since my computer died last month, I have a hard time to get everything running
again. In the process, I was switching to a debian system (grown by my
sysad). So, after getting patch 45 with darcs, I get

isds153:/home/rubey/axiom--main--1# export AXIOM=/home/rubey/axiom--main--1/mnt/linux
isds153:/home/rubey/axiom--main--1# export PATH=$AXIOM/bin:$PATH
isds153:/home/rubey/axiom--main--1# make AWK=/usr/bin/nawk
13 making noweb
patching file modules.c
patching file Makefile
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change lib/emptydefn
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change lib/unmarkup
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change lib/toascii
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change lib/btdefn
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change awk/noidx
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change awk/totex
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change awk/tohtml
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change awk/noindex
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change shell/nocount
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change shell/nountangle
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change shell/noweb
sed: -e expression #1, char 11: unknown option to `s'
awkname: failed to change shell/noroots
notangle.nw:23:19: stdio.h: No such file or directory
notangle.nw:24:20: string.h: No such file or directory
notangle.nw:25:20: stdlib.h: No such file or directory
notangle.nw:26:19: ctype.h: No such file or directory
In file included from notangle.nw:28:
getline.h:1: error: syntax error before '*' token
getline.h:4: error: syntax error before '*' token
In file included from notangle.nw:29:
modules.h:32: error: syntax error before "FILE"
modules.h:35: error: syntax error before '*' token
In file included from notangle.nw:33:
notangle.h:1: error: syntax error before '*' token
notangle.h:2: error: syntax error before '*' token
notangle.nw:37: error: syntax error before '*' token
notangle.nw: In function `emit_module_named':
notangle.nw:38: error: `NULL' undeclared (first use in this function)
notangle.nw:38: error: (Each undeclared identifier is reported only once
notangle.nw:38: error: for each function it appears in.)
notangle.nw:40: error: `rootname' undeclared (first use in this function)
notangle.nw:42: error: `locformat' undeclared (first use in this function)
notangle.nw:42: error: `out' undeclared (first use in this function)
notangle.nw: At top level:
notangle.nw:56: error: syntax error before '*' token
notangle.nw: In function `read_defs':
notangle.nw:59: error: `NULL' undeclared (first use in this function)
notangle.nw:63: error: `in' undeclared (first use in this function)
notangle.nw: In function `insist':
notangle.nw:176: error: `NULL' undeclared (first use in this function)
make[2]: *** [notangle.o] Error 1
make[1]: *** [all] Error 2
make: *** [noweb] Error 2

\start
Date: Thu, 27 Oct 2005 14:28:02 +0200
From: Ralf Hemmecke
To: axiom-dev <list>
Subject: Re: compile with Debian fails

Hello Martin,

I suggest, you install the noweb package on debian.

apt-get install nowebm

(you need to be root)

Ralf


Martin Rubey wrote:
 > Dear all,
 >
 > since my computer died last month, I have a hard time to get 
everything running
 > again. In the process, I was switching to a debian system (grown by my
 > sysad). So, after getting patch 45 with darcs, I get
 >
 > isds153:/home/rubey/axiom--main--1# export 
AXIOM=/home/rubey/axiom--main--1/mnt/linux
 > isds153:/home/rubey/axiom--main--1# export PATH=$AXIOM/bin:$PATH
 > isds153:/home/rubey/axiom--main--1# make AWK=/usr/bin/nawk
 > 13 making noweb
 > patching file modules.c
 > patching file Makefile
 > sed: -e expression #1, char 11: unknown option to `s'
 > awkname: failed to change lib/emptydefn

\start
Date: Thu, 27 Oct 2005 08:51:36 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: compile with Debian fails

clearly noweb is not working for you.
do a `which noweb` to see if it is installed already.
you may be using an installed version rather than axiom's version.

and a missing 'stdio.h' bodes not well.
check to see if there is one in /usr/include.
  if not, the system setup is broken
    else, something is wrong in your environment, try env and post the result

you can also try 
   apt-get install axiom
to see if that works. the apt-get version is about 1 year downlevel
i believe but if it works then i'm puzzled.

\start
Date: Thu, 27 Oct 2005 06:06:34 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Tim Daly
Subject: RE: documentation

> Tim,
> 
> On Wednesday, October 26, 2005 9:25 PM you wrote:
> 
> > > http://page.axiom-developer.org/pamphlet-3.html
> > 
> > cool, man, panther cool.
> >
> 
> It turns out that there is a way to do audio with Wink as
> well. See:
> 
> http://www.debugmode.com/userforums/viewtopic.php?t80
> 
> SWFtools http://www.swftools.org and Audacity (way cool!)
> http://audacity.sourceforge.net are also, like Wink,
> available on both linux and windows.

Neat!  Too bad f4l seems to be stalled - we could have an entirely open
source toolchain for this process.  I guess for this particular
activity it doesn't matter too much though.

> > i'm off to try wink. i like the idea of adding comment
> > balloons to draw attention to important points.
> 
> How is Wink working on linux?
> 
> Here's my entertainment for tonight. :) It's a demonstration
> of installing Axiom on Windows:
> 
> http://page.axiom-developer.org/AxiomIn5.html

Hmm - I'm getting the initial screen, but then when I press next I get
a black screen.  Maybe my work machine's flash install is too old?

> I created the screen video and balloon markup with Wink
> (on a faster workstation than before) and then added the
> sound track with Audacity and SWFtools.
> 
> Fun.
> 
> So, do you have any ideas for other "productions" and
> about how we should package these things?

The first idea that comes to mind for this format is a demonstration of
the draw command and interactive tools it pops up, but that would
require wink on Linux.

Out of curosity, what hardware are you using to record your voice? 
Voice recording was one thing I've never set up - never had the
hardware.  Can one get decent sound quality with inexpensive hardware?

\start
Date: Thu, 27 Oct 2005 06:17:42 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, list
Subject: Re: compile with Debian fails

I can't speak to these specific errors, but my first suggestion is to
check whether you have all the dev packages installed.  Debian
separates out the files needed to JUST run things and those needed to
actually compile things against libraries - I think there is some
systematic way to install these but I'm not sure what it is.  You're
not finding things like stdio.h, so that's why I'm thinking maybe the
dev packages aren't installed.  That caused me a lot more grief than I
care to admit, back in my Debian days.  

> Dear all,
> 
> since my computer died last month, I have a hard time to get
> everything running
> again. In the process, I was switching to a debian system (grown by
> my
> sysad). So, after getting patch 45 with darcs, I get
> 
> isds153:/home/rubey/axiom--main--1# export
> AXIOM=/home/rubey/axiom--main--1/mnt/linux
> isds153:/home/rubey/axiom--main--1# export PATH=$AXIOM/bin:$PATH
> isds153:/home/rubey/axiom--main--1# make AWK=/usr/bin/nawk
> 13 making noweb
> patching file modules.c
> patching file Makefile
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change lib/emptydefn
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change lib/unmarkup
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change lib/toascii
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change lib/btdefn
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change awk/noidx
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change awk/totex
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change awk/tohtml
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change awk/noindex
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change shell/nocount
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change shell/nountangle
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change shell/noweb
> sed: -e expression #1, char 11: unknown option to `s'
> awkname: failed to change shell/noroots
> notangle.nw:23:19: stdio.h: No such file or directory
> notangle.nw:24:20: string.h: No such file or directory
> notangle.nw:25:20: stdlib.h: No such file or directory
> notangle.nw:26:19: ctype.h: No such file or directory
> In file included from notangle.nw:28:
> getline.h:1: error: syntax error before '*' token
> getline.h:4: error: syntax error before '*' token
> In file included from notangle.nw:29:
> modules.h:32: error: syntax error before "FILE"
> modules.h:35: error: syntax error before '*' token
> In file included from notangle.nw:33:
> notangle.h:1: error: syntax error before '*' token
> notangle.h:2: error: syntax error before '*' token
> notangle.nw:37: error: syntax error before '*' token
> notangle.nw: In function `emit_module_named':
> notangle.nw:38: error: `NULL' undeclared (first use in this function)
> notangle.nw:38: error: (Each undeclared identifier is reported only
> once
> notangle.nw:38: error: for each function it appears in.)
> notangle.nw:40: error: `rootname' undeclared (first use in this
> function)
> notangle.nw:42: error: `locformat' undeclared (first use in this
> function)
> notangle.nw:42: error: `out' undeclared (first use in this function)
> notangle.nw: At top level:
> notangle.nw:56: error: syntax error before '*' token
> notangle.nw: In function `read_defs':
> notangle.nw:59: error: `NULL' undeclared (first use in this function)
> notangle.nw:63: error: `in' undeclared (first use in this function)
> notangle.nw: In function `insist':
> notangle.nw:176: error: `NULL' undeclared (first use in this
> function)
> make[2]: *** [notangle.o] Error 1
> make[1]: *** [all] Error 2
> make: *** [noweb] Error 2

\start
Date: Thu, 27 Oct 2005 10:27:34 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: compile with Debian fails

Axiom includes it's own copy of noweb which has some bug fixes.
These bug fixes were not accepted back into the noweb sources.

\start
Date: Thu, 27 Oct 2005 12:41:17 -0400
From: Bill Page
To: Tim Daly, Martin Rubey
Subject: RE: compile with Debian fails

Martin, Tim,

On Thursday, October 27, 2005 8:52 AM Tim Daly wrote:
>
> clearly noweb is not working for you.
> do a `which noweb` to see if it is installed already.
> you may be using an installed version rather than axiom's
> version.

There are two different ways to build Axiom on Debian:
The Debian way and Tim Daly's way ... :)

Of on Debian, the Debian way is by far the easiest. In
this case all you have to do is to configure your apt
to access the unstable sources.

  $ apt-setup

See: http://wiki.debian.org/AptCLI

Also: "Working with Source Packages"
http://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html

And then do

  # apt-get build-dep axiom

To download and intstall the environment you need to build axiom.

To get the sources

  $ apt-get source axiom

Etc.

I have also built Axiom "Tim's Way" on Debian, but it is
rather hard to get all the dependencies right. The 'apt-get
build-dep' should fix that, so you should also then be able
to do a

  .\configure
  make

>
> and a missing 'stdio.h' bodes not well.
> check to see if there is one in /usr/include.
>   if not, the system setup is broken
>     else, something is wrong in your environment, try env and
> post the result
>
> you can also try
>    apt-get install axiom
> to see if that works. the apt-get version is about 1 year
> downlevel i believe but if it works then i'm puzzled.

If the Debian axiom binary install doesn't work, then that
would be a problem! I never had any trouble with that after
at least 10 installs on different versions of Debian.

The Debian "unstable" release is from the Sept 2005 sources,
i.e. completely up to date. See:

http://packages.debian.org/unstable/math/axiom

\start
Date: Thu, 27 Oct 2005 13:39:28 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: documentation

On Thursday, October 27, 2005 9:07 AM C Y wrote:

> ...
> Hmm - I'm getting the initial screen, but then when I press
> next I get a black screen.  Maybe my work machine's flash
> install is too old?

According to the Wink web site: http://www.debugmode.com/wink

"Generated flash file plays in Flash players from version 3
and above ... "

Which of the other screencasts work for you?

http://page.axiom-developer.org/pamphlet-1.html

  This one is silent, with just balloon markup.

http://page.axiom-developer.org/pamphlet-2.html

  This one is silent, made using pyvnc2swf. No markup. I think
  it is in SWF "video" format. This might be a problem. From

  http://www.unixuser.org/~euske/vnc2swf/pyvnc2swf.html

  "The second encoding method, "video" provides a smaller SWF
  movie. This is, however, not recommended to use within vnc2swf.py
  for two reasons: This type of encoding is only supported by
  Flash Player version 7 or newer."

http://page.axiom-developer.org/pamphlet-3.html

  This is the same as pamphlet-2 (vncswf) but with a soundtrack
  added using pyvnc2swf/edit.py

http://page.axiom-developer.org/AxiomIn5.html

  The latest one was made using Wink but with a soundtrack
  added using SWFtools

I am not sure whether adding the soundtracks affects what
version of SWF is needed.

> ...
> >
> > So, do you have any ideas for other "productions" and
> > about how we should package these things?
>
> The first idea that comes to mind for this format is a
> demonstration of the draw command and interactive tools it
> pops up, but that would require wink on Linux.

Unless Tim gets to it first, I could try something like
that this weekend.

>
> Out of curiosity, what hardware are you using to record your
> voice?

So far none of my SWF screencasts are using voice. The
soundtrack has been derived from pre-recorded sources. But
on other hardware (not available where I am now) I have used
voice recognition software. But after some intense experiments
experiments I don't use it much anymore - I found that I
"think better" when I am typing rather than speaking. Must
be the way my brain is wired or something. :) But in that
case I started with the usual duplex CreativeLabs SoundBlaster
card with a cheap quality headset with mic.

> Voice recording was one thing I've never set up - never had
> the hardware.

It's easy and cheap on Windows. On up-to-date Linux distributions
its now also pretty easy. Windows still has the widest range of
audio/visual software but recently the software on Linux seems
to have made some major advances.

> Can one get decent sound quality with inexpensive hardware?
>

Short answer: "No." :(  But of course it depends on what you
want to do and what you mean by "inexpensive". If you want to
do reliable voice recognition, the most expensive part would be
the microphone (maybe $200?). You really need something with good
ambient noise cancellation and frequency range - more or less
studio quality. A headset mic (e.g. the kind you get on a hands
free cell phone) is not likely to give good results. But if all
you want to do is add a voice over soundtrack to a SWF screencast,
then probably just about anything will do. A $25 audio card
and a $15 headset with mic should be fine.

\start
Date: Thu, 27 Oct 2005 10:58:00 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: documentation

> On Thursday, October 27, 2005 9:07 AM C Y wrote:
> 
> > ... 
> > Hmm - I'm getting the initial screen, but then when I press
> > next I get a black screen.  Maybe my work machine's flash
> > install is too old?
> 
> According to the Wink web site: http://www.debugmode.com/wink
> 
> "Generated flash file plays in Flash players from version 3
> and above ... "
> 
> Which of the other screencasts work for you?
> 
> http://page.axiom-developer.org/pamphlet-1.html
> 
>   This one is silent, with just balloon markup.

Get initial screen, but when I click next everything goes white.
 
> http://page.axiom-developer.org/pamphlet-2.html
> 
>   This one is silent, made using pyvnc2swf. No markup. I think
>   it is in SWF "video" format. This might be a problem. From
> 
>   http://www.unixuser.org/~euske/vnc2swf/pyvnc2swf.html
> 
>   "The second encoding method, "video" provides a smaller SWF
>   movie. This is, however, not recommended to use within vnc2swf.py
>   for two reasons: This type of encoding is only supported by
>   Flash Player version 7 or newer."

Actually, that one works perfectly.  

> http://page.axiom-developer.org/pamphlet-3.html
> 
>   This is the same as pamphlet-2 (vncswf) but with a soundtrack
>   added using pyvnc2swf/edit.py

I get a prompt asking if I want to install Flash 8.

> http://page.axiom-developer.org/AxiomIn5.html
> 
>   The latest one was made using Wink but with a soundtrack
>   added using SWFtools
> 
> I am not sure whether adding the soundtracks affects what
> version of SWF is needed.

Screen goes black when I click next.

> > ...
> > > 
> > > So, do you have any ideas for other "productions" and
> > > about how we should package these things?
> > 
> > The first idea that comes to mind for this format is a 
> > demonstration of the draw command and interactive tools it
> > pops up, but that would require wink on Linux.
> 
> Unless Tim gets to it first, I could try something like
> that this weekend.

Cool :-).

> > Out of curiosity, what hardware are you using to record your
> > voice?
> 
> So far none of my SWF screencasts are using voice. The
> soundtrack has been derived from pre-recorded sources. But
> on other hardware (not available where I am now) I have used
> voice recognition software. But after some intense experiments
> experiments I don't use it much anymore - I found that I
> "think better" when I am typing rather than speaking. Must
> be the way my brain is wired or something. :) But in that
> case I started with the usual duplex CreativeLabs SoundBlaster
> card with a cheap quality headset with mic.

I usually don't worry about voice recognition - I was thinking more
about voice overs for movies :-).

> > Voice recording was one thing I've never set up - never had
> > the hardware.
> 
> It's easy and cheap on Windows. On up-to-date Linux distributions
> its now also pretty easy. Windows still has the widest range of
> audio/visual software but recently the software on Linux seems
> to have made some major advances.

Ah, good.  Definitely don't plan on installing Windows anytime soon.

> > Can one get decent sound quality with inexpensive hardware? 
> 
> Short answer: "No." :(  But of course it depends on what you
> want to do and what you mean by "inexpensive". If you want to
> do reliable voice recognition, the most expensive part would be
> the microphone (maybe $200?). You really need something with good
> ambient noise cancellation and frequency range - more or less
> studio quality. A headset mic (e.g. the kind you get on a hands
> free cell phone) is not likely to give good results. But if all
> you want to do is add a voice over soundtrack to a SWF screencast,
> then probably just about anything will do. A $25 audio card
> and a $15 headset with mic should be fine.

Cool.  Voiceover would be all I'm after.  Don't know if I'll ever be
making any movies, but it would be nice to be able to do voice on them.

\start
Date: Thu, 27 Oct 2005 19:26:31 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: another fix...

Your patches to combfunc have been applied.
They will be in the upcoming release.

Do you happen to have some test cases and a paragraph to say what
the problem was that was fixed?

\start
Date: Fri, 28 Oct 2005 01:10:18 -0400
From: Tim Daly
To: list
Subject: subtext and crystal?

subtextual.org...

this is a completely different approach to programming 
(which i'm struggling to understand). the key fact of 
interest is that it appears to be "correctness preserving"
that is, the program is alway runnable (rather than typing
partial characters to break a program while editing).

i can see how to create such a program in lisp. i just
have not fully appreciated this approach.

the idea seems interesting and novel and could related to
either the way we make web pages or to the eventual presentation
in crystal.

anyway, i bring it to your attention as an interesting idea...

\start
Date: 28 Oct 2005 10:03:04 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: another fix...
Cc: Tim Daly

Tim Daly writes:

> Martin,
> 
> Your patches to combfunc have been applied.
> They will be in the upcoming release.
> 
> Do you happen to have some test cases and a paragraph to say what
> the problem was that was fixed?

But I added *lot's* of documentation? Is this missing in your version? You
should have, for example, the following paragraph concerning equality of sums
and products:

  The preceding two operations handle the testing for equality of sums and
  products. This functionality was missing up to [[patch--45]]. (Issue~\#213)
  The corresponding property [[%specialEqual]] set below is checked in
  [[Kernel]]. Note that we can assume that the operators are equal, since this
  is checked in [[Kernel]] itself.

Issue~\#213 refers to the issue on IssueTracker, of course.

By the way, in my patch to combfunc.spad.pamphlet, I forgot to add the line

  SPECIALEQUAL ==> %specialEqual

in the appropriate place. I'll send you the corrected patch this
afternoon. Sorry about this.

\start
Date: Thu, 27 Oct 2005 15:05:48 -0700
From: Karl Hegbloom
To: list
Subject: [Hyperdoc] Series examples improvement idea.

Under Topics --> Calculus --> Series, I found the example confusing at
first.  I think it should begin with:

 (1) -> S := series 'n

So that the series looks more like the S_n I see in my Calculus
textbook:

  S = \Sigma_{n = 1}^{\infty}{a_n}

  S_n = \Sigma_{k = 1}^{n}{a_k}

  lim_{n \rightarrow \infty} S_n = S

\start
Date: Fri, 28 Oct 2005 10:22:33 -0500
From: MathAction (Transgressive Computing 2006 Conference)
To: MathAction
Subject: [Axiom-mail] TC 2006. Call for Papers

   Transgressive Computing TC'2006: THIRD CALL FOR PAPERS.

A conference in honor of Jean Della Dora will be held next year
at the University of Granada (Spain) from the 24th to the 26th
of April 2006, a few weeks after his 60th birthday. In order
to acknowledge the many innovative contributions of Jean, this 
event will be called "Transgressive Computing 2006".

TC'2006 web page: www.orcca.on.ca/conferences/tc2006
TC'2006 e-mail: tc2006@orcca.on.ca

Important Dates

Deadline for Submissions:    November 15, 2005
Notification of Acceptance:  January 15, 2006
Camera-ready copy received:  February 15, 2006

Conference Topics

The presentations will include invited and contributed talks which
topics comprise, but are not limited to, the 
various research interests of Jean; among those: Computer Algebra, 
Differential Equations, Pade Approximants, Parallel Computing, 
Linear Algebra, Complexity Theory, Dynamical Systems, Hybrid Systems, 
Complex Networks, Optimal Control, Algorithmic Number Theory and
Cryptology, Programming Languages and Categorical Semantics, Open Software 
and Applications of the previous topics to Biology, Environment, 
Physics, DNA Computing, Genetics, Robotics,  Automatics etc.

Instructions to Authors

Authors are invited to submit an extended abstract of at least 
4 pages or a full paper of at most 16 pages in LaTeX 11pt article 
size. This submitted article can be written in English, French 
or Spanish but must include in any case English versions of the 
title and abstract. LaTeX templates in each of the three languages 
are available at
http://www.orcca.on.ca/conferences/tc2006/site/submission/submission.html

Original research results and insightful analysis of current concerns 
are solicited for submission. Submissions must not substantially duplicate 
work published or submitted for publication elsewhere. Late submissions
will be rejected. Papers will be reviewed by the program committee 
and additional referees. Proceedings will be distributed at the
symposium.  Electronic submission is mandatory and the submission 
web page is
http://www.easychair.org/TC2006/submit/

Each submission should have an abstract as well as an introductory 
section that: describes the problem, motivates the study of the 
problem, states the main results and compares them to other work 
(including theoretical or empirical performance) and summarizes the 
original aspects of the contribution. Authors of accepted papers 
are expected to present their work at the symposium, or to make 
arrangements to have it presented.

Invited Speakers:

   * Jean Della Dora, INPG, Grenoble, France
   * Eugene Asarin, Univ. Paris 7, France
   * Leon Brenig, Univ. Libre de Bruxelles, Belgium
   * Claude Brezinski, Univ. Lille 1, France
   * Alessandra Carbone, IHES, France.
   * Michel Cosnard, INRIA, France
   * Victor Fairen, UNED, Spain
   * Jean-Pierre Ramis, Univ. Paul Sabatier, France
   * Stephen M. Watt, Univ. Western Ontario, Canada

TC'2006 Program Committee:

   * Leon Brenig, Belgium
   * Claude Brezinski, France
   * Bernard Brogliato, France
   * Bernhard Beckermann, France
   * Guoting Chen, France
   * Robert M. Corless, Canada
   * Dominique Duval, France
   * Roderick Edwards, Canada
   * Victor Fairen, Spain
   * Mark Giesbrecht, Canada
   * Aziz Hilali, Morocco
   * Francisco-Jesus Castro-Jimenez, Spain
   * Lila Kari, Canada
   * Franck Leprevost, Luxembourg
   * Luis Miguel Pardo, Spain
   * Michel Petitot, France
   * Jean-Pierre Ramis, France
   * B. David Saunders, USA
   * Eric Schost, France
   * Yun Tang, China
   * Gilles Villard, France
   * Stephen M. Watt, Canada
   * Jean-Louis Roch, France
   * Timothy P. Daly, USA
 and
   * Jean-Guillaume Dumas, France 
     (Proceeding Editor)
   * Jose Gomez-Torrecillas, Spain 
     (Local Arrangements Chair)
   * Francoise Jung, France 
     (Treasurer)
   * Francois Lemaire, France 
     (Web Master)
   * Francisco-Javier Lobillo-Borrero, Spain 
     (Local Arrangements Chair)
   * Marc Moreno Maza, Canada
     (General Chair)
   * Tomas Recio Muniz, Spain
     (Program Chair)
   * Evelyne Tournier, France
     (Publicity Chair)

\start
Date: 28 Oct 2005 18:25:20 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: another fix...

Dear all,

here is the corrected patch to combfunc.spad.pamphlet. (only one line has been
changed...)


*** /home/rubey/axiom-20050901/src/algebra/combfunc.spad.pamphlet	2005-09-05 20:50:32.000000000 +0200
--- combfunc.spad.pamphlet	2005-10-28 18:23:13.759042424 +0200
***************
*** 66,75 ****
    SMP ==> SparseMultivariatePolynomial(R, K)
    Z   ==> Integer
  
!   POWER       ==> "%power"::Symbol
!   OPEXP       ==> "exp"::Symbol
!   SPECIALDIFF ==> "%specialDiff"
!   SPECIALDISP ==> "%specialDisp"
  
    Exports ==> with
      belong?    : OP -> Boolean
--- 66,76 ----
    SMP ==> SparseMultivariatePolynomial(R, K)
    Z   ==> Integer
  
!   POWER        ==> "%power"::Symbol
!   OPEXP        ==> "exp"::Symbol
!   SPECIALDIFF  ==> "%specialDiff"
!   SPECIALDISP  ==> "%specialDisp"
!   SPECIALEQUAL ==> "%specialEqual"
  
    Exports ==> with
      belong?    : OP -> Boolean
***************
*** 130,150 ****
      idsum     : List F -> F
      iprod     : List F -> F
      idprod    : List F -> F
      ddsum     : List F -> O
      ddprod    : List F -> O
      fourth    : List F -> F
      dvpow1    : List F -> F
      dvpow2    : List F -> F
      summand   : List F -> F
      dvsum     : (List F, SE) -> F
      dvdsum    : (List F, SE) -> F
      facts     : (F, List SE) -> F
      K2fact    : (K, List SE) -> F
      smpfact   : (SMP, List SE) -> F
  
      dummy == new()$SE :: F
  @
- 
  This macro will be used in [[product]] and [[summation]], both the $5$ and $3$
  argument forms. It is used to introduce a dummy variable in place of the
  summation index within the summands. This in turn is necessary to keep the
--- 131,156 ----
      idsum     : List F -> F
      iprod     : List F -> F
      idprod    : List F -> F
+     dsum      : List F -> O
      ddsum     : List F -> O
+     dprod     : List F -> O
      ddprod    : List F -> O
+     equalsumprod  : (K, K) -> Boolean 
+     equaldsumprod : (K, K) -> Boolean 
      fourth    : List F -> F
      dvpow1    : List F -> F
      dvpow2    : List F -> F
      summand   : List F -> F
      dvsum     : (List F, SE) -> F
      dvdsum    : (List F, SE) -> F
+     dvprod    : (List F, SE) -> F
+     dvdprod   : (List F, SE) -> F
      facts     : (F, List SE) -> F
      K2fact    : (K, List SE) -> F
      smpfact   : (SMP, List SE) -> F
  
      dummy == new()$SE :: F
  @
  This macro will be used in [[product]] and [[summation]], both the $5$ and $3$
  argument forms. It is used to introduce a dummy variable in place of the
  summation index within the summands. This in turn is necessary to keep the
***************
*** 155,167 ****
  product.
  
  Note that up to [[patch--25]] this used to read
- 
  \begin{verbatim}
      dummy := new()$SE :: F
  \end{verbatim}
- 
  thus introducing the same dummy variable for all products and summations, which
! caused nested products and summations fail. (Issue~\#72)
  
  <<package COMBF CombinatorialFunction>>=
      opfact  := operator("factorial"::Symbol)$CommonOperators
--- 161,171 ----
  product.
  
  Note that up to [[patch--25]] this used to read
  \begin{verbatim}
      dummy := new()$SE :: F
  \end{verbatim}
  thus introducing the same dummy variable for all products and summations, which
! caused nested products and summations to fail. (Issue~\#72)
  
  <<package COMBF CombinatorialFunction>>=
      opfact  := operator("factorial"::Symbol)$CommonOperators
***************
*** 219,233 ****
        opsum [eval(x, k := kernel(i)$K, dm), dm, k::F]
  
  @
- 
  These two operations return the product or the sum as unevaluated operators. A
  dummy variable is introduced to make the indexing variable \lq local\rq.
  
  <<package COMBF CombinatorialFunction>>=
      dvsum(l, x) ==
!       k  := retract(second l)@K
!       differentiate(third l, x) * summand l
!           + opsum [differentiate(first l, x), second l, third l]
  
      dvdsum(l, x) ==
        x = retract(y := third l)@SE => 0
--- 223,234 ----
        opsum [eval(x, k := kernel(i)$K, dm), dm, k::F]
  
  @
  These two operations return the product or the sum as unevaluated operators. A
  dummy variable is introduced to make the indexing variable \lq local\rq.
  
  <<package COMBF CombinatorialFunction>>=
      dvsum(l, x) ==
!       opsum [differentiate(first l, x), second l, third l]
  
      dvdsum(l, x) ==
        x = retract(y := third l)@SE => 0
***************
*** 238,249 ****
          opdsum [differentiate(first l, x), second l, y, g, h]
  
  @
! 
! The above operation implements differentiation of sums with bounds. Note that
! the function
! 
  $$n\mapsto\sum_{k=1}^n f(k,n)$$
- 
  is well defined only for integral values of $n$ greater than or equal to zero.
  There is not even consensus how to define this function for $n<0$. Thus, it is
  not differentiable. Therefore, we need to check whether we erroneously are
--- 239,247 ----
          opdsum [differentiate(first l, x), second l, y, g, h]
  
  @
! The above two operations implement differentiation of sums with and without
! bounds. Note that the function
  $$n\mapsto\sum_{k=1}^n f(k,n)$$
  is well defined only for integral values of $n$ greater than or equal to zero.
  There is not even consensus how to define this function for $n<0$. Thus, it is
  not differentiable. Therefore, we need to check whether we erroneously are
***************
*** 275,287 ****
--- 273,379 ----
               + opdsum [differentiate(f, x), d, y, g, h]
  \end{verbatim}
  
+ Up to [[patch--45]] a similar mistake could be found in the code for
+ differentiation of formal sums, which read
+ \begin{verbatim}
+     dvsum(l, x) ==
+       k  := retract(second l)@K
+       differentiate(third l, x) * summand l
+           + opsum [differentiate(first l, x), second l, third l]
+ \end{verbatim}
+ 
+ <<package COMBF CombinatorialFunction>>=
+     dvprod(l, x) ==
+       dm := retract(dummy)@SE
+       f := eval(first l, retract(second l)@K, dm::F)
+       p := product(f, dm)
+ 
+       opsum [differentiate(first l, x)/first l * p, second l, third l]
+ 
+ 
+     dvdprod(l, x) ==
+       x = retract(y := third l)@SE => 0
+       if member?(x, variables(h := third rest rest l)) or 
+          member?(x, variables(g := third rest l)) then
+         error "a product cannot be differentiated with respect to a bound"
+       else
+         opdsum cons(differentiate(first l, x)/first l, rest l) * opdprod l 
+ 
+ @ 
+ The above two operations implement differentiation of products with and without
+ bounds. Note again, that we cannot even properly define products with bounds
+ that are not integral.
+ 
+ To differentiate the product, we use Leibniz rule:
+ $$\frac{d}{dx}\prod_{i=a}^b f(i,x) = 
+   \sum_{i=a}^b \frac{\frac{d}{dx} f(i,x)}{f(i,x)}\prod_{i=a}^b f(i,x)
+ $$
+ 
+ There is one situation where this definition might produce wrong results,
+ namely when the product is zero, but axiom failed to recognize it: in this
+ case,
+ $$
+   \frac{d}{dx} f(i,x)/f(i,x)  
+ $$
+ is undefined for some $i$. However, I was not able to come up with an
+ example. The alternative definition
+ $$
+   \frac{d}{dx}\prod_{i=a}^b f(i,x) = 
+   \sum_{i=a}^b \left(\frac{d}{dx} f(i,x)\right)\prod_{j=a,j\neq i}^b f(j,x)
+ $$
+ has the slight (display) problem that we would have to come up with a new index
+ variable, which looks very ugly. Furthermore, it seems to me that more
+ simplifications will occur with the first definition.
+ 
+ <<TEST COMBF>>=
+   f := operator 'f
+   D(product(f(i,x),i=1..m),x)
+ @
+ 
+ Note that up to [[patch--45]] these functions did not exist and products were
+ differentiated according to the usual chain rule, which gave incorrect
+ results. (Issue~\#211)
+ 
  <<package COMBF CombinatorialFunction>>=
+     dprod l ==
+       prod(summand(l)::O, third(l)::O)
+ 
      ddprod l ==
        prod(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O)
  
+     dsum l ==
+       sum(summand(l)::O, third(l)::O)
+ 
      ddsum l ==
        sum(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O)
  
+ @ 
+ These four operations handle the conversion of sums and products to
+ [[OutputForm]]. Note that up to [[patch--45]] the definitions for sums and
+ products without bounds were missing and output was illegible.
+ 
+ <<package COMBF CombinatorialFunction>>=
+     equalsumprod(s1, s2) ==
+       l1 := argument s1
+       l2 := argument s2
+ 
+       (eval(first l1, retract(second l1)@K, second l2) = first l2)
+ 
+     equaldsumprod(s1, s2) ==
+       l1 := argument s1
+       l2 := argument s2
+ 
+       ((third rest l1 = third rest l2) and
+        (third rest rest l1 = third rest rest l2) and
+        (eval(first l1, retract(second l1)@K, second l2) = first l2))
+ 
+ @ 
+ The preceding two operations handle the testing for equality of sums and
+ products. This functionality was missing up to [[patch--45]]. (Issue~\#213) The
+ corresponding property [[%specialEqual]] set below is checked in
+ [[Kernel]]. Note that we can assume that the operators are equal, since this is
+ checked in [[Kernel]] itself.
+ <<package COMBF CombinatorialFunction>>=
      product(x:F, s:SegmentBinding F) ==
        k := kernel(variable s)$K
        dm := dummy
***************
*** 293,299 ****
        opdsum [eval(x,k,dm), dm, k::F, lo segment s, hi segment s]
  
  @
- 
  These two operations return the product or the sum as unevaluated operators. A
  dummy variable is introduced to make the indexing variable \lq local\rq.
  
--- 385,390 ----
***************
*** 466,488 ****
                      log(first l) * first(l) ** second(l)
  
  @
- 
  This operation implements the differentiation of the power operator [[%power]]
  with respect to its second argument, i.e., the exponent. It uses the formula
! 
! $$\frac{d}{dx} g(y)^x = \frac{d}{dx} e^{x\log g(y)} = \log g(y) g(y)^x$$.
  
  If $g(y)$ equals zero, this formula is not valid, since the logarithm is not
  defined there. Although strictly speaking $0^x$ is not differentiable at zero,
  we return zero for convenience. 
  
  Note that up to [[patch--25]] this used to read
- 
  \begin{verbatim}
      if F has ElementaryFunctionCategory then
        dvpow2 l == log(first l) * first(l) ** second(l)
  \end{verbatim}
- 
  which caused differentiating $0^x$ to fail. (Issue~\#19)
  
  <<package COMBF CombinatorialFunction>>=
--- 557,575 ----
                      log(first l) * first(l) ** second(l)
  
  @
  This operation implements the differentiation of the power operator [[%power]]
  with respect to its second argument, i.e., the exponent. It uses the formula
! $$\frac{d}{dx} g(y)^x = \frac{d}{dx} e^{x\log g(y)} = \log g(y) g(y)^x.$$
  
  If $g(y)$ equals zero, this formula is not valid, since the logarithm is not
  defined there. Although strictly speaking $0^x$ is not differentiable at zero,
  we return zero for convenience. 
  
  Note that up to [[patch--25]] this used to read
  \begin{verbatim}
      if F has ElementaryFunctionCategory then
        dvpow2 l == log(first l) * first(l) ** second(l)
  \end{verbatim}
  which caused differentiating $0^x$ to fail. (Issue~\#19)
  
  <<package COMBF CombinatorialFunction>>=
***************
*** 495,506 ****
      evaluate(opprod, iprod)
      evaluate(opdprod, iidprod)
      derivative(oppow, [dvpow1, dvpow2])
!     setProperty(opsum,SPECIALDIFF,dvsum@((List F,SE) -> F) pretend None)
!     setProperty(opdsum,SPECIALDIFF,dvdsum@((List F,SE)->F) pretend None)
!     setProperty(opdsum,  SPECIALDISP,  ddsum@(List F -> O) pretend None)
      setProperty(opdprod, SPECIALDISP, ddprod@(List F -> O) pretend None)
  
- @
  \section{package FSPECF FunctionalSpecialFunction}
  <<package FSPECF FunctionalSpecialFunction>>=
  )abbrev package FSPECF FunctionalSpecialFunction
--- 582,612 ----
      evaluate(opprod, iprod)
      evaluate(opdprod, iidprod)
      derivative(oppow, [dvpow1, dvpow2])
!     setProperty(opsum,   SPECIALDIFF, dvsum@((List F, SE) -> F) pretend None)
!     setProperty(opdsum,  SPECIALDIFF, dvdsum@((List F, SE)->F) pretend None)
!     setProperty(opprod,  SPECIALDIFF, dvprod@((List F, SE)->F) pretend None)
!     setProperty(opdprod, SPECIALDIFF, dvdprod@((List F, SE)->F) pretend None)
! @
! The last four properties define special differentiation rules for sums and
! products. Note that up to [[patch--45]] the rules for products were missing.
! Thus products were differentiated according the usual chain-rule, which gave
! incorrect results.
! 
! <<package COMBF CombinatorialFunction>>=
!     setProperty(opsum,   SPECIALDISP, dsum@(List F -> O) pretend None)
!     setProperty(opdsum,  SPECIALDISP, ddsum@(List F -> O) pretend None)
!     setProperty(opprod,  SPECIALDISP, dprod@(List F -> O) pretend None)
      setProperty(opdprod, SPECIALDISP, ddprod@(List F -> O) pretend None)
+     setProperty(opsum,   SPECIALEQUAL, equalsumprod@((K,K) -> Boolean) pretend None)
+     setProperty(opdsum,  SPECIALEQUAL, equaldsumprod@((K,K) -> Boolean) pretend None)
+     setProperty(opprod,  SPECIALEQUAL, equalsumprod@((K,K) -> Boolean) pretend None)
+     setProperty(opdprod, SPECIALEQUAL, equaldsumprod@((K,K) -> Boolean) pretend None)
+ 
+ @ 
+ Finally, we set the properties for displaying sums and products and testing for
+ equality.
+ 
  
  \section{package FSPECF FunctionalSpecialFunction}
  <<package FSPECF FunctionalSpecialFunction>>=
  )abbrev package FSPECF FunctionalSpecialFunction

\start
Date: Sun, 30 Oct 2005 04:23:55 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] Large download

Please break the main axiom download into pieces (that work) so that
when one downloads one piece, he is able to do that stuff and download
other pieces as and when necessary

\start
Date: Sun, 30 Oct 2005 08:14:14 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] More small downloads

Do you mean like in the case of the rpm files for Linux?
I think this is about the smallest sized pieces possible
for Axiom. With some effort it might be possible to do
something similar for the Windows binaries.

Axiom is a large and complex piece of software. Breaking it
into pieces is fundamentally difficult. So we would be glad
to receive your suggestions as to how to accomplish this.

\start
Date: Sun, 30 Oct 2005 08:34:37 -0600
From: MathAction (root)
To: MathAction
Subject: [AxiomDownload] [AxiomDownload] Large download

There is no logical breakdown of Axiom that would allow this
without having a very axiom-educated user doing the download.

The only parts that could be broken out this way would be the
documentation and portions of the algebra. But, currently,
installing new algebra requires a lot of knowledge, some of
which will be contained in the documentation.

What problem are you really trying to solve? Are the download
times too long? Is your connection unreliable?

\start
Date: Sun, 30 Oct 2005 10:03:05 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#225 Series examples improvement idea] (new) 

On October 27, 2005 6:06 PM Karl Hegbloom wrote:

Under [HyperDoc] Topics --> Calculus --> Series

I found the example confusing at first.
I think it should begin with::

 (1) -> S := series 'n

So that the series looks more like the $S_n$ I see in my
Calculus textbook:
$$
  S = \Sigma_{n = 1}^{\infty}{a_n}
  S_n = \Sigma_{k = 1}^{n}{a_k}
  lim_{n \rightarrow \infty} S_n = S
$$

\start
Date: Sun, 30 Oct 2005 10:17:59 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [HyperDoc] (new) 

The open source version of Axiom for Linux is a "feature complete"
release of Axiom that includes all of the functionality of the
original commercial release. It includes all of the algebra we
have available, working graphics, and a working HyperDoc browser.

The graphics and HyperDoc functions are not yet available for
Windows.

HyperDoc allows you to access online help and tutorial information
as well as browsing the algebra database and running Axiom commands
by simple point-and-click.

Once you instal or build the system you can test it by typing::

  axiom

when the HyperDoc browser starts choose::

  Basic Commands -> Draw -> A function of two variables -> Continue -> Do It

and a graph will appear. Click anywhere on the graph to get the
control panel.

\start
Date: Sun, 30 Oct 2005 11:04:14 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#221 'PI' does not have 'OASGP'] 

This is a very deep change and I'm going to have to devote 
a fair bit of time to testing the system before this one
gets released into the wild.

\start
Date: Sun, 30 Oct 2005 11:11:54 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#216 terminating condition for 'nextSubsetGray' incorrectly documented] 

patch applied for axiom--main--1--patch-46

\start
Date: Sun, 30 Oct 2005 09:27:40 -0800 (PST)
From: Cliff Yapp
To: list
Subject: ANSI Lisp?

Out of curosity, how far away from ANSI is the current Axiom lisp code?
 I know there was a cmucl port attempt a while back - is it ANSI issues
that are the problem or are there other, deeper issues?

\start
Date: Sun, 30 Oct 2005 13:08:55 -0500
From: Tim Daly
To: Cliff Yapp
Subject: Re: ANSI Lisp?

it's not far away. there are minor package issues but very little else.
once gcl becomes ansi i'll port it.

i could probably make it run in an ansi common lisp within a few days.

\start
Date: Sun, 30 Oct 2005 12:39:08 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#205 Hyperdoc does not work in patch 44] unable to reproduce

Status: fix proposed => closed 

\start
Date: Sun, 30 Oct 2005 12:40:22 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#205 Hyperdoc does not work in patch 44] 

I diffed the patch-44 version with patch-5 and there has been no change.
I'm unable to reproduce this so I'm closing it.

\start
Date: Sun, 30 Oct 2005 12:43:12 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#216 terminating condition for nextSubsetGray incorrectly documented] property change

Name: '#216 terminating condition for 'nextSubsetGray' incorrectly documented' => '#216 terminating condition for <code>nextSubsetGray</code> incorrectly documented' 
Status: fix proposed => pending (next release) 

\start
Date: Sun, 30 Oct 2005 12:57:01 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#109 hyperdoc uncompress failed] property change

Status: fix proposed => pending (next release) 

\start
Date: Sun, 30 Oct 2005 12:57:59 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#109 hyperdoc uncompress failed] 

gunzip properly handles .Z compress files.
I checked with FC4 and uncompress is missing.
Since you need gzip to build Axiom you likely have gunzip.

\start
Date: Sun, 30 Oct 2005 12:59:47 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#202 Axiom Tutorial PDF on Windows - Bitmap fonts used] property change

Status: fix proposed => closed 

\start
Date: Sun, 30 Oct 2005 13:00:26 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#202 Axiom Tutorial PDF on Windows - Bitmap fonts used] 

There was no change made for this bug.
Bill's proposed fix seems to solve the problem.

\start
Date: Sun, 30 Oct 2005 13:02:47 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#66 one? function calls need to be restored] 

one? was a built-in function in CCL.
It is not built-in and does not exist in GCL.
All code was changed to rewrite these calls.

\start
Date: Sun, 30 Oct 2005 13:04:55 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#66 one? function calls need to be restored] property change

Status: fix proposed => closed 

\start
Date: Sun, 30 Oct 2005 13:12:51 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#153 make install does not install a needed libdb.text for HyperDoc] 

good catch. this has been added to the src/algebra/Makefile.pamphlet.
Does anyone know who 'loli' is so I can give proper credit?

\start
Date: Sun, 30 Oct 2005 13:13:03 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#153 make install does not install a needed libdb.text for HyperDoc] property change

Status: fix proposed => pending (next release) 

\start
Date: Sun, 30 Oct 2005 13:14:24 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#165 stream2.input] property change

Status: pending (next release) => closed 

\start
Date: Sun, 30 Oct 2005 13:19:10 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#159 build directory captured in scripts] property change

Status: pending (next release) => closed 

\start
Date: Sun, 30 Oct 2005 13:21:19 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#133 missing \begin{quote} in Chapter on "Using Types and Modes"] property change

Status: open => pending (next release) 

\start
Date: Sun, 30 Oct 2005 13:21:49 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#133 missing \begin{quote} in Chapter on "Using Types and Modes"] 

seems to be there already. But I've checked it anyway. --Tim

\start
Date: Sun, 30 Oct 2005 13:27:28 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#71 The current free Axiom has no complete documentation] property change

Category:  => Aldor Library Compiler 
Status:  => closed 

\start
Date: Sun, 30 Oct 2005 13:29:21 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [#71 The current free Axiom has no complete documentation] 

The reworked version of the original book is part of the distribution.
See $AXIOM/doc/book.dvi

This is still a problem but will get better as time goes on.
See $AXIOM/doc/src/algebra/bookvol5.dvi

\start
Date: Sun, 30 Oct 2005 14:44:16 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#165 stream2.input] 

In general this fixes the problems::

  )set functions compile on

Test 1::

  !\begin{axiom}
  )set streams calculate 10
  [j for j in 4.. | j < 10 ] 
  \end{axiom}

does not stop.

Test 2::

  !\begin{axiom}
  m==[j for j in 4.. | j < 10 ]
  m
  \end{axiom}

causes GCL to exit, CCL to never complete.

but:
\begin{axiom}
[j for j in 0.. | j < 10 ]
\end{axiom}
works!

issue seems to be 0 vs 4 in loop index

Test 3::

  !\begin{axiom}
  )set streams calculate 10
  u==[i+j for i in (-4)..10 | i < 5 for j in 4.. | j < 10]
  u
  \end{axiom}

causes GCL to exit, CCL works.

Test 4::

  !\begin{axiom}
  )set streams calculate 10
  u==[i+j for i in 0..10 | i < 5 for j in 0.. | j < 10]
  u
  \end{axiom}

also fails.

issue seems to be end test compile.

Test 5::

  !\begin{axiom}
  )set streams calculate 10
  u==[[i+j for i in 0..] for j in 0..]
  u
  \end{axiom}

causes GCL to exit, CCL works.


??changed:
-because
-[[i+j for i in 0..] for j in 0..]
-works. also the sequence

because::

  [[i+j for i in 0..] for j in 0..]

works::

  !\begin{axiom}
  [[i+j for i in 0..] for j in 0..]
  \end{axiom}

also the sequence:
\begin{axiom}

??changed:
-works! something appears to be set funny when
\end{axiom}
works!

something appears to be set funny when

++added:
Test 6:
\begin{axiom}

??changed:
-causes GCL to exit, CCL works
-but
-)set streams calculate 10
\end{axiom}
causes GCL to exit, CCL works.

but:
\begin{axiom}
)set streams calculate 5

??changed:
-works!
\end{axiom}
works, and
\begin{axiom}

++added:
\end{axiom}

\start
Date: Sun, 30 Oct 2005 14:50:27 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#165 stream2.input] Tests 1, 2, 3, 4,	and 5 still fail

In the version of Axiom used on MathAction which was compiled
from the tla archive on Tuesday August 23, 2005 at 22:37:35

Current Axiom version:
\begin{axiom}
)version
\end{axiom}

Will these work in the pending October 2005 release?

\start
Date: Sun, 30 Oct 2005 20:08:13 -0500
From: Tim Daly
To: Bill Clementson
Subject: Axiom

Bill,

You missed Axiom, a full featured system that was developed at IBM Research
for 23 years, sold commercially as a competitor to Mathematica and Maple
for 7 years by the Numerical Algorithms Group and then released as free
and open source software under the BSD license. It's been in development
for the last 4 years.

It's written almost entirely in Common Lisp. The only non-lisp portion
of the multi-million lines of code is the graphics front end. We'd like
to rewrite this into lisp by haven't found the right approach.

The system was completely rewritten in a literate programming sytle
when it became free. There are no lisp files, no C files, no Makefiles,
etc. Everything is a latex document. The actual code is embedded in the
documents and extracted at build time. The idea is due to Knuth (Web)
and we use an implementation that is language independent (noweb, by
Norman Ramsey). I think you'll find the idea of literate lisp interesting.

In addition you should check out the wiki front end that Bill Page 
has developed. http://wiki.axiom-developer.org. The sandbox link will
allow you to input algebra and output the results. We think it's the
way to go in the future.

\start
Date: Sun, 30 Oct 2005 21:12:34 -0500
From: Tim Daly
To: MathAction
Subject: Re: [#165 stream2.input]

no, those are unchanged.

i've been concentrating on the problem of documentation.
at present i see that the system is too large and difficult
for anyone to really begin to make changes, do real debugging,
and add new features; all of which we need.

i'm working on organizing and documenting what i know so others
can begin to understand.

the key change in this release and in this direction is the file
$AXIOM/doc/bookvol5.dvi This file begins to document the interpreter.
A similar file will begin to document the compiler, the browser,
the graphics, the algebra, etc.

\start
Date: Sun, 30 Oct 2005 20:16:57 -0600
From: MathAction (root)
To: MathAction
Subject: [#165 stream2.input] [#165 stream2.input]

no, those are unchanged.

i've been concentrating on the problem of documentation.
at present i see that the system is too large and difficult
for anyone to really begin to make changes, do real debugging,
and add new features; all of which we need.

i'm working on organizing and documenting what i know so others
can begin to understand.

the key change in this release and in this direction is the file
$AXIOM/doc/bookvol5.dvi This file begins to document the interpreter.
A similar file will begin to document the compiler, the browser,
the graphics, the algebra, etc.

\start
Date: Sun, 30 Oct 2005 21:21:18 -0500
From: Tim Daly
To: list
Subject: --patch46

--patch-46 is up on arch. soon, but not yet, up on savannah or sourceforge.

the executable images are building.

the key change in this version is to be found in
${AXIOM}/doc/bookvol5.dvi

This is the beginning of the documentation of the interpreter.
Later work will document the compiler, the browser, the graphics,
the algebra, etc.

t

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

20051030 tpd --patch-46
20051030 tpd src/interp/Makefile add BOOK, mv bookvol5 to ${BOOK}
20051030 tpd src/interp/HowItWorks removed
20051030 tpd src/etc/Makefile remove AXIOM variable from axiom cmd
20051030 tpd src/algebra/Makefile copy libdb.text to mnt/linux/algebra
20051030 wys src/lib/pixmap.c uncompress -> gunzip
20051030 mxr src/algebra/perman.spad nextSubsetGray documentation fix
20051030 mxr src/algebra/transsolve.spad patch solveList for empty list
20051030 tpd src/interp/vmlisp.lisp remove statisticsInitialization
20051030 tpd src/interp/util.lisp loadExposureGroupData
20051030 tpd src/interp/util.lisp remove reroot, init-memory-config, spad-save
20051030 tpd src/interp/util.lisp remove make-absolute-filename, initroot
20051030 tpd src/interp/sockio.lisp remove SpadServerName
20051030 tpd src/interp/setq.lisp remove history variables
20051030 tpd src/interp/pathname.boot remove history functions
20051030 tpd src/interp/patches.lisp remove restart, set-restart-hook
20051030 tpd src/interp/packtran.boot remove ncTopLevel
20051030 tpd src/interp/nci.lisp remove ncIntLoop
20051030 tpd src/interp/Makefile remove i-hist, undo. add bookvol5
20051030 tpd src/interp/i-util.boot remove makeInitialModemapFrame
20051030 tpd src/interp/i-toplev.boot remove spad, runspad
20051030 tpd src/interp/i-syscmd.boot remove )frame handling
20051030 tpd src/interp/int-top.boot remove SpadInterpretStream
20051030 tpd src/interp/int-top.boot remove intloop
20051030 tpd src/interp/int-top.boot remove intloopReadConsole
20051030 tpd src/interp/intint.lisp remove intSpadServer
20051030 tpd src/interp/i-hist.boot deleted
20051030 tpd src/interp/debugsys add shell variable checking
20051030 tpd src/interp/debugsys use *sys*, not *src*
20051030 tpd src/interp/debugsys bookvol5 added
20051030 tpd src/interp/bookvol5 added
20051030 tpd Makefile fix clean to remove int, obj, mnt
20051030 tpd Makefile add WEAVE ENV variable
20051027 mxr src/algebra/combfunc.spad reduce equal sums to zero
20051025 tpd src/doc/msgs/s2-us.msgs add S2IH0029, missing msg
20051020 gxv src/algebra/naalg.spad fix FRNAAF2 bug
20051019 tpd FAQ explain how to run debugsys.lisp
20051019 tpd src/interp/debugsys check shell variable settings
20051019 tpd src/interp/debugsys introduce *build-version* variable
20051019 tpd src/interp/debugsys lookup ${SYS} and insert in code
20050915 tpd Makefile --enable-maxpage changed from 128 to 256

\start
Date: Sun, 30 Oct 2005 20:43:26 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#165 stream2.input] why closed?

Tim,

I agree with your emphasis on documentation.

Since these problems remain, then perhaps the status
change that you made at 13:14:24 -0600 today:

> Status: pending (next release) => closed

was not what you intended?

\start
Date: Sun, 30 Oct 2005 20:47:29 -0600
From: MathAction (root)
To: MathAction
Subject: [#165 stream2.input] [#165 stream2.input] why closed?

clearly not. please change it back.

\start
Date: Sun, 30 Oct 2005 21:15:31 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#165 stream2.input] closed in error

Status: closed => open 

\start
Date: Sun, 30 Oct 2005 22:36:36 -0500
From: Balbir Thomas
To: list
Subject: 3D canvas for Tcl/Tk

I remember that there was some talk about rewriting the axiom
graphics interface in Tcl/Tk. I would just like to draw the 
attention of the concerned developers to 
http://3dcanvas.tcl.tk
in this regard.

\start
Date: Sun, 30 Oct 2005 22:50:41 -0500
From: Tim Daly
To: Balbir Thomas
Subject: Re: 3D canvas for Tcl/Tk

do you know if this runs on windows?

\start
Date: Sun, 30 Oct 2005 23:34:27 -0500
From: Bill Page
To: Tim Daly
Subject: RE: --patch46

On October 30, 2005 9:21 PM you wrote;
> 
> --patch-46 is up on arch. soon, but not yet, up on savannah 
> or sourceforge.
> 
> the executable images are building.
>
> ... 
> 20050915 tpd Makefile --enable-maxpage changed from 128 to 256
>

I did a 'tla update' on the axiom sources on axiom.developer.org
and then tried the build of patch-46. It fails with the following
error:

echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")" >>foo
/home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/raw_pre_gcl
/home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/ -libdir
/home/page/repository/axiom--main--1/lsp/gcl-2.6.7/ < foo
GCL (GNU Common Lisp)  April 1994  262144 pages

Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
make[4]: *** [saved_pre_gcl] Error 134

-------

I know from previous attempts that this error is due to
the change in the gcl configure parameter --enable-maxpage.
128 builds but 256 fails.

I asked Camm about this about a month ago but I do not
recall a specific answer as to the specific cause or cure.

Are you able to build with this value of maxpage on your
systems?

\start
Date: Sun, 30 Oct 2005 23:33:48 -0500
From: Tim Daly
To: Bill Page
Subject: Re: --patch46

yep. it's building right now on redhat9 and fc4.

but i build as root so i don't have any ulimit issues that arise.
check your ulimits.

\start
Date: Sun, 30 Oct 2005 23:44:45 -0500
From: Bill Page
To: Tim Daly
Subject: RE: --patch46

Hmmm, that's a good thought...

Here's the output of ulimit -a

[page@axiom-developer page]$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) 32
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 12288
virtual memory        (kbytes, -v) unlimited

-------

Any idea which of these I should tweak?

Regards,
Bill Page.

> -----Original Message-----
> 
> yep. it's building right now on redhat9 and fc4.
> 
> but i build as root so i don't have any ulimit issues that arise.
> check your ulimits.

\start
Date: Sun, 30 Oct 2005 23:43:05 -0500
From: Tim Daly
To: Bill Page
Subject: Re: --patch46

try building as root and see if that fixes the problem.
if so, it's probably a ulimit.

\start
Date: Mon, 31 Oct 2005 00:07:46 -0500
From: Bill Page
To: Tim Daly
Subject: RE: --patch46

On axiom-developer I am not able to actually run a 'root'.
The closest I can come to that is 'sudo /bin/bash' which is
probably not entirely equivalent to 'root' when it comes
to ulimits.

Building with 'sudo /bin/bash' fails with the same error.
It also fails even if I double the stack size limit:

  $ ulimit -s 16384

which is the only limit which seems logically related to
this problem.

Any other ideas?

Could this have something to do with running as a virtual
server?

> -----Original Message-----
> 
> try building as root and see if that fixes the problem.
> if so, it's probably a ulimit.

\start
Date: Mon, 31 Oct 2005 00:15:39 -0500
From: Tim Daly
To: Bill Page
Subject: Re: --patch46

not a virtual server problem. i'm building the FC4 in a vmware machine.
hmmm. mod the code to lower the limit, i guess. debugging the problem
will just take you down a different path you probably don't want to go.
it'll probably be a waste of time. i only jacked the limit because we
thought it would solve a previous problem but i think that problem got
cured anyway, right?

\start
Date: Mon, 31 Oct 2005 01:04:46 -0500
From: Bill Page
To: Tim Daly
Subject: RE: --patch46
Cc: Camm Maguire

Tim,

On October 31, 2005 12:16 AM you wrote:
>
> not a virtual server problem. i'm building the FC4 in a vmware
> machine. hmmm. mod the code to lower the limit, i guess. debugging
> the problem will just take you down a different path you probably
> don't want to go.

Right! :)

The build completes with --enable-maxpage=128*1024

> it'll probably be a waste of time. i only jacked the limit
> because we thought it would solve a previous problem
>

Yes. In an email on 15 Septembre 2005 Vanuxem Gr=E9gory claimed
that this did solve the problem. But I was not able to reproduce
that on MathAction since I was not able to complete the build.

>  but i think that problem got cured anyway, right?

No unfortunately not, althought there is a kind of work around
by setting:

  )lisp (si::allocate-contiguous-pages 3000 t)

in the Axiom session. My last email to Camm on this issue is
attached. So far he has not replied. All this GCL memory
management stuff seems like a mystery to me so I don't know
how to follow his suggestion of "you can allocate page types
explicitly with the #'allocate".

Regards,
Bill Page.


> -----Original Message-----
> From: Page, Bill [mailto:Bill Page]
> Sent: September 27, 2005 6:11 PM
> To: Camm Maguire
> Cc: list; gcl-devel@gnu.org; Bill Page
> Subject: RE: FW: How to set default for ALLOCATE-CONTIGUOUS-PAGES?
>
>
> Camm,
>
> On Tuesday, September 27, 2005 5:10 PM you wrote:
> >
> > Greetings, and please exsude the delay!
> >
>
> No problem! I exsude (sic) delay myself ;)
>
> On Thursday, September 15, 2005 12:17 PM Bill Page wrote:
> > >
> > > On Thursday, September 15, 2005 12:07 PM I wrote:
> > > > > ...
> > > > > GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> > > > > --enable-maxpage=256*1024"
> > > > >
> > >
> > > Oops... the build just died with: NULL_OR_ON_C_STACK macro invalid
> > >
> > > ...
> > > echo " (in-package \"USER\")(system:save-system
> \"saved_pre_gcl\")"
> > > >>foo
> > >
> >
> /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/ra
> w_pre_gcl
> > >
> /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/ -libdir
> > > /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/ < foo
> > > GCL (GNU Common Lisp)  April 1994  262144 pages
> > >
> > > Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
> >
> > What kind of machine is this?
>
> This is the axiom-developer server where we run MathAction. It
> is a x686 shared virtual server running RedHat 9.  The error
> occurs when trying to build Axiom patch-44 which includes
> gcl-2.6.7. The build succeeds if I use the normal Axiom default
> of --enable-maxpage=128*1024, but then I get the
> ALLOCATE-CONTINUOUS-PAGES error. See below. That is why I was
> trying to increase maxpage.
>
> > The purpose of this macro is to distinguish the stack address
> > space. Addresses of local variables should return true, and
> > others false. GCL tests this on starup on a local variable, NIL,
> > and core_end. One can see what the macro expands to by doing
> > 'cpp -I../h main.c' in the o directory.  Most likely there was
> > some problem in detecting CSTACK_ADDRESS in the configure stage.
> > I recommend looking at the configure output for this.
>
> Ok. Here is where CSTACK_ADDRESS is mentioned in the configure
> output:
>
> ...
> checking for randomized sbrk... no
> checking finding DBEGIN... got 0x8000000
> checking finding CSTACK_ADDRESS... got 1073738356
> ...
>
> In config.log I see
>
> ...
> configure:3780: checking for sbrk
> configure:3798: gcc -o conftest      conftest.c  1>&5
> configure:3814: checking for randomized sbrk
> configure:3831: gcc -o conftest      conftest.c  1>&5
> configure:3863: gcc -o conftest      conftest.c  1>&5
> configure:3984: checking finding DBEGIN
> configure:4028: gcc -o conftest     conftest.c  1>&5
> configure:4051: checking finding CSTACK_ADDRESS
> configure:4068: gcc -o conftest      conftest.c  1>&5
> ...
>
> So I don't see a problem here. Do you?
>
> On Thursday, September 15, 2005 5:58 AM Bill Page wrote:
> > > >
> > > > On Thursday, September 15, 2005 5:22 AM I wrote:
> > > >
> > > > > ...
> > > > > Yes, I think you are right. I changed the short name
> > > > > (abbreviation=file name?) of my Aldor category from
> > > > > upper case to lower case and now it **sometimes** works.
> > > > > See:
> > > > >
> > > > > http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs
> > > > >
> > > > > But often when I try to save this page I get:
> > > > >
> > > > >     >> System error:
> > > > >     Contiguous blocks exhausted.
> > > > >   Currently, 1354 pages are allocated.
> > > > >   Use ALLOCATE-CONTIGUOUS-PAGES to expand the space.
> > > > >
> >
> > You can allocate page types explicitly with the #'allocate function
> > (see the docs if needed),
>
> I do not know what you mean by "allocate page types explicitly".
> Is this a function like si::allocate-contiguous-pages that I used
> in the Axiom )lisp command below? Or does this have something to
> do with the gcl configuration?
>
> > but this is not necessary, as you are totally out of memory here,
> > and this will just forestall total failure.
>
> As I mentioned in the previous email, all seems well if I call
>
>   )lisp (si::allocate-contiguous-pages 3000 t)
>
> inside Axiom before access the Aldor category. Why do you say
> that I am "totally out of memory"?
>
> > You need to configure with a greater --enable-maxpage.
>
> That is what I tried to do but the build of gcl fails as
> I mentioned above.
>
> >
> > Do I understand right that someone is layering aldor on top
> > of axiom?
>
> Aldor used to be available as an optional library compiler
> for the commercial version of Axiom. The current open source
> version of Axiom was released without Aldor because NAG had
> previously and separately given the rights to the Aldor source
> to "aldor.org" (aka. Stephen Watt). "aldor.org" makes binary
> versions of Aldor available for free for non-commmercial use
> but does not follow the current open source licensing model.
>
> Recently Peter Broadbery was able to configure the open source
> version of Axiom to use the Aldor binary on linux. So now
> Axiom functions the way it used to in the commercial release
> but the license status of Aldor is still uncertain. I have made
> several requests to Stephen Watt to obtain a copy of the
> source code license for Aldor but I have not yet heard from
> him.
>
> > Can we distribute such in Debian yet?
>
> I presuemt that to distribute on Debian we would require
> a GPL-compatible source license to Aldor, right?
>
> > If so, I might be persuaded to package it, and thereby ensure
> > that it works :-).
>
> Wonderful. I think we should try hard to make this happen.
> I would love to be able to just 'apt-get install aldor'! :)

\start
Date: 31 Oct 2005 08:59:37 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: ANSI Lisp?

Tim Daly writes:

> it's not far away. there are minor package issues but very little else.
> once gcl becomes ansi i'll port it.
> 
> i could probably make it run in an ansi common lisp within a few days.

If you have the time, I think this would be worthwile. 

A related topic: I recall you saying that you have once rewritten all the boot
code in lisp? Does this code still exist?

Finally, I wonder whether you'd be able to fix the "bug" about dependent types
described in Issue #219...

\start
Date: Mon, 31 Oct 2005 05:05:12 -0600
From: MathAction (unknown)
To: MathAction
Subject: [Axiom Book] Royalty

Tim Daly wrote:

And, no, you won't make a dime on royalties. I'm one of the original
authors and haven't seen money from it. So if you're thinking that
this will be an income stream you're mistaken. The funds for this
effort, if there are any, are intended to go to the Axiom Foundation
(of which I'm not an official member but suspect I have an
influence). The idea is to try to pay people to do subprojects from
funds that the book generates.

\start
Date: Mon, 31 Oct 2005 06:49:54 -0500
From: Tim Daly
To: Bill Page
Subject: Re: --patch46
Cc: Camm Maguire

> No unfortunately not, althought there is a kind of work around
> by setting:
> 
>   )lisp (si::allocate-contiguous-pages 3000 t)
> 
> in the Axiom session. My last email to Camm on this issue is
> attached. So far he has not replied. All this GCL memory
> management stuff seems like a mystery to me so I don't know
> how to follow his suggestion of "you can allocate page types
> explicitly with the #'allocate".

see init-memory-config in src/interp/bookvol5.pamphlet.
i'll make that change there and back out the 256 change.

\start
Date: Mon, 31 Oct 2005 07:05:17 -0500
From: Tim Daly
To: Martin Rubey
Subject: Re: ANSI Lisp?

> > it's not far away. there are minor package issues but very little else.
> > once gcl becomes ansi i'll port it.
> > 
> > i could probably make it run in an ansi common lisp within a few days.
> 
> If you have the time, I think this would be worthwile. 

yeah, it's coming eventually. i'm waiting for an ansi version of GCL
which is "in process". 

it would be harder to port the whole build process to a "production
version" that used another lisp than it would to do the ansi port.

when i say "a few days" i really mean my normal, coffee-fueled, 24-hour
hackathon kind of "few days". they are hard to find on a part-time
basis. when Axiom was a full-time job and IBM Research would let me
work at home i could burn a whole week and get great things done.
perhaps on my next vacation....

> 
> A related topic: I recall you saying that you have once rewritten all the 
> boot code in lisp? Does this code still exist?

nope. huge discussion. lots of religion. bad timing and all that rot...
so i simply erased it. it's coming back again though. look at 
src/interp/bookvol5.pamphlet in --patch-46

> 
> Finally, I wonder whether you'd be able to fix the "bug" about dependent 
> types described in Issue #219...

i've decided that documenting the system is a higher priority than
chasing bugs for me. if i chase bugs they die one at a time but there
are hundreds of them. if i cleanly, clearly document the system in a
literate fashion so others can read and understand it then other people
can join in the bug fixing. of course, as i document the system i'm
beginning to discover bugs and am fixing them as i go.

\start
Date: 31 Oct 2005 14:42:20 +0100
From: Martin Rubey
To: list
Subject: Re: compile with Debian fails

I just wanted to say that following Bills instructions, namely

Bill Page writes:

> Of on Debian, the Debian way is by far the easiest. In
> this case all you have to do is to configure your apt
> to access the unstable sources.
> 
>   $ apt-setup
> 
> See: http://wiki.debian.org/AptCLI
> 
> Also: "Working with Source Packages"
> http://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html
> 
> And then do
> 
>   # apt-get build-dep axiom
> 
> To download and intstall the environment you need to build axiom.
> 
> To get the sources
> 
>   $ apt-get source axiom
> 
> Etc.
> 
> I have also built Axiom "Tim's Way" on Debian, but it is
> rather hard to get all the dependencies right. The 'apt-get
> build-dep' should fix that, so you should also then be able
> to do a
> 
>   .\configure
>   make

worked, *after* having said

apt-get install binutils-dev

(although it appears to me that this should be done by apt-get build-dep axiom,
but it isn't...)

Unfortunately, building axiom from the darcs sources does not work: it seems
that for some files the executable bit is not set (for example for configure),
so I said

chmod -R u+x *

and gcl-2.6.7.* is missing (I copied them from the debian distribution). Now
the build seems to be working.

I did not yet set up tla.

\start
Date: Mon, 31 Oct 2005 05:51:30 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Online source code no longer working?

Is anyone else getting file not found errors with the online pamphlet
files?

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

Did we decide to take this down?

\start
Date: 31 Oct 2005 09:30:41 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: --patch46

Greetings!  And please excuse me -- this thread has slipped under the
radar here.

Bill Page writes:

> > > The purpose of this macro is to distinguish the stack address
> > > space. Addresses of local variables should return true, and
> > > others false. GCL tests this on starup on a local variable, NIL,
> > > and core_end. One can see what the macro expands to by doing
> > > 'cpp -I../h main.c' in the o directory.  Most likely there was
> > > some problem in detecting CSTACK_ADDRESS in the configure stage.
> > > I recommend looking at the configure output for this.
> > 
> > Ok. Here is where CSTACK_ADDRESS is mentioned in the configure
> > output:
> > 
> > ...
> > checking for randomized sbrk... no
> > checking finding DBEGIN... got 0x8000000
> > checking finding CSTACK_ADDRESS... got 1073738356
> > ...
> > 

Bill, here is the problem -- Redhat 9 is apparently placing the stack
within the first 1Gb of memory, but you are requesting this amount for
your heap.  GCL won't (or tries not to) allow the head to overrun the
stack: 

p/x -1073750720   /* This is my cstack address.  Just built 2.6.7 with */
$1 = 0xbfffdd40   /* 256*1024 maxpages just fine*/
(gdb) p/x 1073738356 /* here is yours */
$2 = 0x3ffff274
(gdb) p/x 256*1024*4096+0x8000000
$3 = 0x48000000   /* here is the end of your requested heap */
(gdb) 


In all of the machines I've looked at, this is about the worst stack
placement I've seen.  Is this 'enterprise' or 'normal'?   I thought
the former had a sophisticated mechanism to push the stack and the
shared memory area as high up in memory as possible.

I know of no way to change this short of getting a different Linux
kernel, where the issue should be addressable.

One thing we could do is relax the power of two constraint on
maxpages if a lesser amount would suffice.


You say there is another work around with
si::allocate-contiguous-pages, which I suspect to be a feather-edge
manipulation issue, but am not sure.  You can check this out by doing
(room) after your job has completed and seeing how close you are to
OOM. In addition to the contiguous page function you've found, here
are some other ways to explicitly allocate memory to various types:

(si::allocate 'cons 400)
(si::allocate-relocatable-pages 10000)
<will explain the allocate sgc functions later if desired>

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

Here is a bit of clarification on the room report:

   211/211    42.9%         CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
   
   ^  pages allocated for this type
        ^  maximum pages before triggering GC
              ^  Percent of the allocated pages holding live objects

=============================================================================
>(room)(si::allocate 'cons 400)(room)

   211/211    42.9%         CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
     2/28     40.8%         FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE READTABLE SPICE
    47/49     72.9%         SYMBOL STREAM
     1/2      12.8%         PACKAGE
     1/38     56.8%         ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME CCLOSURE CLOSURE
    16/32     85.8%         STRING
     3/27     98.3%         CFUN BIGNUM
     6/115    88.1%         SFUN GFUN VFUN AFUN CFDATA

   347/512                  contiguous (86 blocks)
       13107                hole
       5242    0.0%         relocatable

       287 pages for cells
     18983 total pages
    101769 pages available
     10320 pages in heap but not gc'd + pages needed for gc marking
    131072 maximum pages

>
T

>
   211/400    44.2%         CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
     2/28     47.5%         FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE READTABLE SPICE
    47/49     72.9%         SYMBOL STREAM
     1/2      12.8%         PACKAGE
     1/38     56.8%         ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME CCLOSURE CLOSURE
    16/32     85.8%         STRING
     3/27     98.3%         CFUN BIGNUM
     6/115    88.1%         SFUN GFUN VFUN AFUN CFDATA

   347/512                  contiguous (86 blocks)
       13107                hole
       5242    0.0%         relocatable

       287 pages for cells
     18983 total pages
    101769 pages available
     10320 pages in heap but not gc'd + pages needed for gc marking
    131072 maximum pages

>=============================================================================



Take care,


> > In config.log I see
> > 
> > ...
> > configure:3780: checking for sbrk
> > configure:3798: gcc -o conftest      conftest.c  1>&5
> > configure:3814: checking for randomized sbrk
> > configure:3831: gcc -o conftest      conftest.c  1>&5
> > configure:3863: gcc -o conftest      conftest.c  1>&5
> > configure:3984: checking finding DBEGIN
> > configure:4028: gcc -o conftest     conftest.c  1>&5
> > configure:4051: checking finding CSTACK_ADDRESS
> > configure:4068: gcc -o conftest      conftest.c  1>&5
> > ...
> > 
> > So I don't see a problem here. Do you?
> > 
> > On Thursday, September 15, 2005 5:58 AM Bill Page wrote:
> > > > > 
> > > > > On Thursday, September 15, 2005 5:22 AM I wrote: 
> > > > > 
> > > > > > ... 
> > > > > > Yes, I think you are right. I changed the short name 
> > > > > > (abbreviation=file name?) of my Aldor category from
> > > > > > upper case to lower case and now it **sometimes** works.
> > > > > > See:
> > > > > > 
> > > > > > http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs
> > > > > > 
> > > > > > But often when I try to save this page I get:
> > > > > > 
> > > > > >     >> System error:
> > > > > >     Contiguous blocks exhausted.
> > > > > >   Currently, 1354 pages are allocated.
> > > > > >   Use ALLOCATE-CONTIGUOUS-PAGES to expand the space.
> > > > > > 
> > > 
> > > You can allocate page types explicitly with the #'allocate function
> > > (see the docs if needed),
> > 
> > I do not know what you mean by "allocate page types explicitly".
> > Is this a function like si::allocate-contiguous-pages that I used
> > in the Axiom )lisp command below? Or does this have something to
> > do with the gcl configuration?
> > 
> > > but this is not necessary, as you are totally out of memory here,
> > > and this will just forestall total failure.
> > 
> > As I mentioned in the previous email, all seems well if I call
> > 
> >   )lisp (si::allocate-contiguous-pages 3000 t)
> > 
> > inside Axiom before access the Aldor category. Why do you say
> > that I am "totally out of memory"?
> > 
> > > You need to configure with a greater --enable-maxpage.
> > 
> > That is what I tried to do but the build of gcl fails as
> > I mentioned above.
> > 
> > > 
> > > Do I understand right that someone is layering aldor on top
> > > of axiom?
> > 
> > Aldor used to be available as an optional library compiler
> > for the commercial version of Axiom. The current open source
> > version of Axiom was released without Aldor because NAG had
> > previously and separately given the rights to the Aldor source
> > to "aldor.org" (aka. Stephen Watt). "aldor.org" makes binary
> > versions of Aldor available for free for non-commmercial use
> > but does not follow the current open source licensing model.
> > 
> > Recently Peter Broadbery was able to configure the open source
> > version of Axiom to use the Aldor binary on linux. So now
> > Axiom functions the way it used to in the commercial release
> > but the license status of Aldor is still uncertain. I have made
> > several requests to Stephen Watt to obtain a copy of the
> > source code license for Aldor but I have not yet heard from
> > him.
> > 
> > > Can we distribute such in Debian yet?
> > 
> > I presuemt that to distribute on Debian we would require
> > a GPL-compatible source license to Aldor, right?
> > 
> > > If so, I might be persuaded to package it, and thereby ensure
> > > that it works :-).
> > 
> > Wonderful. I think we should try hard to make this happen.
> > I would love to be able to just 'apt-get install aldor'! :)

\start
Date: Mon, 31 Oct 2005 10:10:43 -0500
From: Bill Page
To: Tim Daly
Subject: interp/Bookvol5 (was: ANSI Lisp?)

Tim,

On October 31, 2005 7:05 AM you wrote:

> > 
> > A related topic: I recall you saying that you have once 
> > rewritten all the boot code in lisp? Does this code still
> > exist?
> 
> nope. huge discussion. lots of religion. bad timing and all 
> that rot... so i simply erased it. it's coming back again
> though. look at src/interp/bookvol5.pamphlet in --patch-46

Argggh!!! Bad Tim. Bad Tim.

  Documentation GOOD.
  Rewriting boot into lisp BAD.

Here's the new bookvol5.pamphlet on MathAction:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/Bookvol5

I am glad to see that you have at least retained the original
boot code adjacent to the lisp. In every case I very much prefer
the original boot code to the new lisp code.

As I said earlier several times, I think what you are doing here
is wrong. I wish I could call on the spirits of the Axiom Founding
Developers to help prevent this forking of the Axiom code. So far
open source Axiom has remained very close to the prior commercial
release and also to most of the other versions still "out there".
I think the commercial release still provides a very valuable
baseline against which to measure the open source release. If you
continue to do this kind of re-writing, very soon we will loose
this baseline. And we may lose the input of those people who are
still running these versions.

Of course, sooner or later open source Axiom will have to
"go it's own way". Maybe it already has. But I think we need to
decide the direction very carefully and not simply on the basis
of one person's whim. (Although I must say in spite of this,
I do have great respect for your whim's. :)

Sigh. I know this is nature of open source development - things
will move in the direction the active developer(s) decide. *If*
the changes you are making could possibly result in more people
being able to actively develop and debug axiom, *then* *maybe*
I not feel quite so strongly about this. But so far, I do not see
any evidence of this. The documentation is great, but recoding
things in lisp just seems to be moving the goal posts further
away from me. :(

\start
Date: Mon, 31 Oct 2005 10:14:28 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Online source code no longer working?

On October 31, 2005 8:52 AM C Y wrote:
> 
> Is anyone else getting file not found errors with the online
> pamphlet files?
> 
> http://www.axiom-developer.org/zope/mathaction/axiom--test--1/
> 
> Did we decide to take this down?
> 

No, this is still available. Keep in mind that this is still
experimental. There is a problem with using the older url's to
reference these files. You should use the shorter (but equivalent)
Axiom wiki url instead:

http://wiki.axiom-developer.org

and

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

\start
Date: 31 Oct 2005 16:08:52 +0100
From: Martin Rubey
To: Martin Rubey
Subject: Re: Tla seems to be ok

I'm now trying to compile patch 46, after having set up tla. It seems that this
works.

\start
Date: Mon, 31 Oct 2005 07:22:15 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Martin Rubey
Subject: Re: ANSI Lisp?

> yeah, it's coming eventually. i'm waiting for an ansi version of GCL
> which is "in process". 
> 
> it would be harder to port the whole build process to a "production
> version" that used another lisp than it would to do the ansi port.

Does this mean the build process is heavily dependant on GCL?  I
confess I haven't looked at it too closely, so I'm not sure what we're
using.  Lisp tradition would probably point to asdf as being a good,
standard, widely used way to organize the build of the lisp parts but I
don't know offhand how asdf and GCL get along.

I'd like to see Axiom at least on cmucl since that seems to currently
be the best platform for McCLIM, but I know that's not a compelling
reason by itself so I'll just wait for the ANSI shift and go from
there.  (While trying to figure out McCLIM in the meantime...)

> when i say "a few days" i really mean my normal, coffee-fueled,
> 24-hour hackathon kind of "few days". they are hard to find on a 
> part-time basis. when Axiom was a full-time job and IBM Research 
> would let me work at home i could burn a whole week and get great 
> things done. perhaps on my next vacation....

Darn it, I wish we could get some universities to sponsor a few folks
working on this thing.

> > A related topic: I recall you saying that you have once rewritten
> > all the  boot code in lisp? Does this code still exist?
> 
> nope. huge discussion. lots of religion. bad timing and all that
> rot...
> so i simply erased it. it's coming back again though. look at 
> src/interp/bookvol5.pamphlet in --patch-46

Would it be possible to put up a bookvol5.pdf somewhere?  My home
machine is off the net for a while and my Windows box at work doesn't 
have the necessary tools to handle pamphlet files.

> > Finally, I wonder whether you'd be able to fix the "bug" about
> > dependent types described in Issue #219...
> 
> i've decided that documenting the system is a higher priority than
> chasing bugs for me. 

Agreed!  Your knowledge of the system is not something we can easily
re-generate, which makes it uniquely valuable.  I think this is the
time for documentation, design polishing, and other things that are
long term rather than short term.  Reporting bugs is critical, because
it points out issues which need to be addressed as various parts of the
code are documented and made robust, but fixing them should (hopefully)
fall out of proper documentation and code review.  Design issues are
another matter of course, but Axiom seems to be designed well enough to
make it worth figuring out what the Right Way is ;-).

> if i chase bugs they die one at a time but there are hundreds of 
> them. if i cleanly, clearly document the system in a literate 
> fashion so others can read and understand it then other people
> can join in the bug fixing. of course, as i document the system i'm
> beginning to discover bugs and am fixing them as i go.

:-)  That's a good sign!

\start
Date: Mon, 31 Oct 2005 07:29:52 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: Online source code no longer working?

--- Bill Page wrote:

> On October 31, 2005 8:52 AM C Y wrote:
> > 
> > Is anyone else getting file not found errors with the online
> > pamphlet files?
> > 
> > http://www.axiom-developer.org/zope/mathaction/axiom--test--1/
> > 
> > Did we decide to take this down?
> 
> No, this is still available. Keep in mind that this is still
> experimental. 

No problem :-).  I'm still being amazed at what you've accomplished.

> There is a problem with using the older url's to
> reference these files. You should use the shorter (but equivalent)
> Axiom wiki url instead:
> 
> http://wiki.axiom-developer.org
> 
> and
> 
> http://wiki.axiom-developer.org/axiom--test--1

Confirmed - that works.  We might want to change the link on
http://www.axiom-developer.org/zope/mathaction/FrontPage - it currently
points to http://www.axiom-developer.org/zope/mathaction/axiom--test--1
 That's an admin edits only page (which makes sense) so I can't tweak
it myself.

\start
Date: Mon, 31 Oct 2005 10:46:48 -0500
From: Bill Page
To: Camm Maguire
Subject: RE: --patch46

On October 31, 2005 9:31 AM you wrote:
> 
> Greetings!  And please excuse me -- this thread has slipped under
> the radar here.

No problem.

> 
> Bill, here is the problem -- Redhat 9 is apparently placing the
> stack within the first 1Gb of memory, but you are requesting this
> amount for your heap.  GCL won't (or tries not to) allow the head
> to overrun the stack: 
> ... 
> In all of the machines I've looked at, this is about the worst
> stack placement I've seen.  Is this 'enterprise' or 'normal'?

Actually, I don't know very much about this server. It is a
"Unmanaged Virtual Servers (VPS/VDS)" hosted at a commercial
ISP called RoseHosting. (This is the system which runs MathAction
and for which Tim Daly is still paying the full operational
costs.) http://www.rosehosting.com

Can you deduce anything from the following system information:

  # uname -a
    Linux axiom-developer.org 2.6.11.10-RH1956 #9 SMP
      Fri May 20 20:48:44 CDT 2005 i686 i686 i386 GNU/Linux

I think that what we have is a legacy RedHat 9 configuration.
According to the RoseHosting website, we could probably upgrade
to a Fedora Core 4 configuration.

Perhaps if I contacted the admins at RoseHosting, I might be
able to get more details.

> I thought the former had a sophisticated mechanism to push
> the stack and the shared memory area as high up in memory
> as possible.
> 
> I know of no way to change this short of getting a different
> Linux kernel, where the issue should be addressable.
> 

I think the above info suggests we are running 2.6.11.10.
That's fairly new isn't it?

> One thing we could do is relax the power of two constraint
> on maxpages if a lesser amount would suffice.
>

Yes, very likely a lesser amount would suffice.
 
> 
> You say there is another work around with
> si::allocate-contiguous-pages, which I suspect to be a
> feather-edge manipulation issue, but am not sure.  You
> can check this out by doing (room) after your job has
> completed and seeing how close you are to OOM.

Ok. Here is the output of (room) in the case of setting
si::allocate-contiguous-pages, see:

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

)lisp (room)
  1528/1528   59.3%       4 CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
    94/200    99.9%         FIXNUM SHORT-FLOAT CHARACTER
                            RANDOM-STATE READTABLE SPICE
   340/500    75.9%         SYMBOL STREAM
     1/8      23.1%         PACKAGE
    65/400    99.0%         ARRAY HASH-TABLE VECTOR BIT-VECTOR
                            PATHNAME CCLOSURE CLOSURE
   500/500    53.3%       1 STRING
   195/331    99.8%       2 CFUN BIGNUM
    40/115    97.6%         SFUN GFUN VFUN AFUN CFDATA
  3000/3000               2 contiguous (237 blocks)
       1476                 hole
       1000   73.5%       1 relocatable
      2763 pages for cells
      8239 total pages
    116036 pages available
      6797 pages in heap but not gc'd + pages needed for
           gc marking
    131072 maximum pages
Value = NIL

-------

>From this output how can I tell how "close I am to OOM"? Maybe
the FIXNUM ... memory is a problem? What can I do about that?

> In addition to the contiguous page function you've found, here
> are some other ways to explicitly allocate memory to various
> types:
> 
> (si::allocate 'cons 400)
> (si::allocate-relocatable-pages 10000)
> <will explain the allocate sgc functions later if desired>

How can I related these to the output of (room)?

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

Where do FIXNUM ... things live?

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

Thanks for the help.

\start
Date: Mon, 31 Oct 2005 09:48:45 -0600
From: MathAction (billpage)
To: MathAction
Subject: [FrontPage] 

You can "download Axiom":AxiomDownload or [build Axiom] from "source code":http://wiki.axiom-developer.org/axiom--test--1 and [update Axiom]</td></tr>

\start
Date: Mon, 31 Oct 2005 11:04:17 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: compile with Debian fails

On October 31, 2005 8:42 AM you wrote:
> ... 
> Unfortunately, building axiom from the darcs sources does
> not work: it seems that for some files the executable bit
> is not set (for example for configure), so I said
> 
> chmod -R u+x *
>

I don't understand this problem with the executable bit.
the 'configure' file in the darcs repository does have the
executable bit set.
 
> and gcl-2.6.7.* is missing (I copied them from the debian 
> distribution).

This was my problem. I had forgotten to do

  darcs add zips/gcl-2.6.7*

after doing the 'tla update' and before the 'darcs record'
to update the darcs repository from the main tla archive.

> Now the build seems to be working.

Great.

> 
> I did not yet set up tla.
> 

darcs is much easier than tla but tla is more flexible.
I have a feeling that we are not using tla in an optimal
manner. In particular perhaps we should be using "revision
libraries" to reduce the amount of network traffic that
tla generates? Are there any tla guru's out there who
could advise?

\start
Date: Mon, 31 Oct 2005 11:08:38 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: ANSI Lisp?

> 
> Would it be possible to put up a bookvol5.pdf somewhere?  My
> home machine is off the net for a while and my Windows box at
> work doesn't have the necessary tools to handle pamphlet files.
>

See:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/Bookvol5

click on 'pdf'

\start
Date: Mon, 31 Oct 2005 08:33:33 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Tim Daly
Subject: Boot vs. Lisp

--- Bill Page wrote:

> Tim,
> 
> On October 31, 2005 7:05 AM you wrote:
> 
> > > 
> > > A related topic: I recall you saying that you have once 
> > > rewritten all the boot code in lisp? Does this code still
> > > exist?
> > 
> > nope. huge discussion. lots of religion. bad timing and all 
> > that rot... so i simply erased it. it's coming back again
> > though. look at src/interp/bookvol5.pamphlet in --patch-46
> 
> Argggh!!! Bad Tim. Bad Tim.
> 
>   Documentation GOOD.
>   Rewriting boot into lisp BAD.

Heh - I'm betting some developers out there are getting deja vu
feelings right about now...
 
> Here's the new bookvol5.pamphlet on MathAction:
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/interp/Bookvol5

Great! Thanks!  *grabs pdf*

> I am glad to see that you have at least retained the original
> boot code adjacent to the lisp. In every case I very much prefer
> the original boot code to the new lisp code.

I take it you are looking at things like interloop? (pg. 21, or 30 by
Acrobat's counter at the bottom)

My first reaction is to wonder if this is normal lisp indentation?  (By
normal meaning the cl-indent style that SLIME uses?)  It seems like a
large number of line returns in some of these, but maybe that's just
the nature of the beast.

> As I said earlier several times, I think what you are doing here
> is wrong. I wish I could call on the spirits of the Axiom Founding
> Developers to help prevent this forking of the Axiom code. So far
> open source Axiom has remained very close to the prior commercial
> release and also to most of the other versions still "out there".
> I think the commercial release still provides a very valuable
> baseline against which to measure the open source release.

But since those versions are commercial, with source code invisible,
how are they useful except possibly for feature comparisions and
consistency?

> If you continue to do this kind of re-writing, very soon we will 
> loose this baseline. And we may lose the input of those people who
> are still running these versions.

Won't they still be able to compare mathematical results with the
current Axiom?

> Of course, sooner or later open source Axiom will have to
> "go it's own way". Maybe it already has. But I think we need to
> decide the direction very carefully and not simply on the basis
> of one person's whim. (Although I must say in spite of this,
> I do have great respect for your whim's. :)

I agree, both counts.

> Sigh. I know this is nature of open source development - things
> will move in the direction the active developer(s) decide. *If*
> the changes you are making could possibly result in more people
> being able to actively develop and debug axiom, *then* *maybe*
> I not feel quite so strongly about this. But so far, I do not see
> any evidence of this.

Lisp has a wide variety of tools written for it, SLIME being a prime
example.  We don't see as much of this as might be because we are using
GCL and thus (up until recently) miss out on much of the ANSI code
development that has occurred.  GCL is seldom a target platform for
such tools right now.  But hopefully with ANSI GCL and ANSI Axiom we
can start to leverage the work out there by the Lisp community.  It's
speculative, I admit, but BOOT will present another learning curve to
new developers and has virtually no development community behind it.  I
should state that I consider a learning curve to be more than learning
what the syntax of a language is and how it works - the programmer
needs to be able to "read" the code with reasonable fluency.  I agree
the BOOT code looks easier to read to an eye used to reading Axiom's
SPAD code, and might even be more compact and efficient in expressing
ideas relevant to that part of the Axiom system.  But most of the
Lisp/BOOT level code will be written once and then never touched again
(hopefully).  The best arguments I know for using one language over
another is the expressive power gained by using that language, and the
support available for that language.  Most of the significant work on
Axiom in the decades to come will hopefully be in the level of
SPAD/Aldor - e.g. the language for mathematical functionality - and not
in either Lisp or BOOT.  I view these two levels as two completely
different levels of coding, and with any luck most of the need and work
will happen in Aldor.  Hopefully functionality written at Lisp/BOOT
levels will be a documented, solved problem.  If the expectation is
that only infrequent work will need to be done at the Lisp/BOOT level,
I would prefer literate well documented Lisp code to literate well
documented BOOT code for the simple reason that Lisp has survived for
decades.  The skill to understand and debug lisp is likely to be more
common down the road than the same skills for BOOT code.  If the
literate documentation is written well the language of the code itself
should be little more than a detail.

As I said before I'm willing to be convinced that the BOOT code adds
enough functionality and power to justify imposing a second (however
minor) learning curve on new programmers, but I can't do it on my own. 
Aldor/SPAD I can see because the programming at that level is tailored
to one specific job - the expression of mathematical knowledge.  Other
than that, Lisp's development environment, long track record, available
development tools like SLIME, and the potential of tools like McCLIM
make BOOT a hard sell for me.  Aldor/SPAD code and code below that
level are in my mind two completely separate jobs, just like writting C
code is different from writing the assembler needed to translate C to
machine code.

> The documentation is great, but recoding
> things in lisp just seems to be moving the goal posts further
> away from me. :(

That in itself is definitely an argument in favor of BOOT - you're
worth quite a few speculative lisp coders!  I definitely think there
should be a discussion on this point, if only to make sure we've
spotted all the issues involved with both courses of action.

\start
Date: Mon, 31 Oct 2005 12:24:35 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Boot vs. Lisp

On October 31, 2005 11:34 AM C Y wrote:

> ...
> Bill Page wrote: 
> > I am glad to see that you have at least retained the
> > original boot code adjacent to the lisp. In every case
> > I very much prefer the original boot code to the new
> > lisp code.
> 
> I take it you are looking at things like interloop?
> (pg. 21, or 30 by Acrobat's counter at the bottom)
> 

Sure that's a pretty good example, but my comment still
applies to all the other cases as well. In this case the
lisp style seems especially obtuse. Perhaps Tim did not
spend much time here cleaning up the original boot
compiler output?

> My first reaction is to wonder if this is normal lisp
> indentation?  (By normal meaning the cl-indent style
> that SLIME uses?)  It seems like a large number of line
> returns in some of these, but maybe that's just the nature
> of the beast.

To me the indentation style seems motivated by the "pile
syntax" used by boot and spad. Does SLIME impose something
different?

> > *If* the changes you are making could possibly result in
> > more people being able to actively develop and debug axiom,
> > *then* *maybe* I not feel quite so strongly about this. But
> > so far, I do not see any evidence of this.
> 
> Lisp has a wide variety of tools written for it, SLIME being
> a prime example.  We don't see as much of this as might be
> because we are using GCL and thus (up until recently) miss out
> on much of the ANSI code development that has occurred.

As Kai Kaminski has pointed out, Axiom's pamphlet format and the
current build process does not lend itself easily to these lisp
development tools.

Kai has done a lot of development in lisp for the AxiomUI project.
In a separate email (still off-list, I think) he has commented
about the difficulty of using "modern" lisp tools with the Axiom
source code. I think he has the intention of writing something
about his approach for posting on MathAction, right Kai? :)

>...  The best arguments I know for using one language over
> another is the expressive power gained by using that language,
> and the support available for that language.

+1 and 0 for boot, I guess. But we could move support to +1 for
boot if we could write some good documentation about how it
works. After all, the Axiom code already contains a lot of good
examples.

> ...
> I would prefer literate well documented Lisp code to literate
> well documented BOOT code for the simple reason that Lisp has
> survived for decades.  The skill to understand and debug lisp
> is likely to be more common down the road than the same skills
> for BOOT code.

Well, BOOT has also survived for decades inside Axiom. And as
Tim Daly has said, we can think of BOOT as an early experiment
in high level dynamically typed languages similar to Python.
So as much as I do respect lisp, I have serious doubts about
the claim that "The skill to understand and debug lisp is likely
to be more common down the road". For example, I think that in
the short time that Python has existed (relative to lisp), it
currently has many many more active programmers than lisp. Of
course BOOT is not Python, but my point is that a typical Python
programmer (e.g. "me" :) has much less resistance learning BOOT
then learning lisp.

> If the literate documentation is written well the language
> of the code itself should be little more than a detail.

Of course that is true only up to a point. In writing any
documentation one is forced to make some assumptions about the
skills and backgrounds of the readers. It is usually impractical
to teach someone how to program in a particular language while
trying to describe how a particular program works.

> ... Lisp's development environment, long track record, available
> development tools like SLIME, and the potential of tools like
> McCLIM make BOOT a hard sell for me.

As you know BOOT is written in lisp, so I don't see any problem
in principle using these tools with BOOT - the complications of
dealing with pamphlet files and literate programming in lisp not
withstanding.

\start
Date: Mon, 31 Oct 2005 12:45:24 -0500
From: Bill Page
To: Cliff Yapp
Subject: re: Boot vs. Lisp

Concerning lisp style, I think the following article is
particularly good:

Tutorial on Good Lisp Programming Style

http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf

Being dated August 10, 1993, perhaps it is not entirely up
to date with the available tools. And what it has to say about
documentation seems very much oriented to the typical lisp
programmer's view rather than Knuth's literate programming
view, i.e. writing *code* that is intended to be read by a
programmer as opposed to writing a *document* that contains
code intended to be processed by the computer.

With regard to BOOT, you should note what Peter Norvig says
about "Syntactic abstractions". I wish he had written more
about that.

\start
Date: Mon, 31 Oct 2005 12:51:23 -0500
From: Bill Page
To: Cliff Yapp
Subject: re: Boot vs. Lisp

> 
> Tutorial on Good Lisp Programming Style
> 
> http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf
> 
> ... 
> With regard to BOOT, you should note what Peter Norvig says
> about "Syntactic abstractions". I wish he had written more
> about that.
> 

Much more Norvig:

http://www.norvig.com

Notice his more recent work in Python. See especially:

Python for Lisp Programmers

http://www.norvig.com/python-lisp.html

\start
Date: Mon, 31 Oct 2005 12:12:05 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] Large Download

Tim wrote:
There is no logical breakdown of Axiom that would allow this without having a very axiom-educated user doing the download.

The only parts that could be broken out this way would be the documentation and portions of the algebra. But, currently, installing new algebra requires a lot of knowledge, some of which will be contained in the documentation.

What problem are you really trying to solve? Are the download times too long? Is your connection unreliable?

Tim
----

Yes download times are really too long. I takes me several days to
download axiom (on a slow dial-up connection).  I use kget to download
and that is pretty reliable( I can pause and resume and that has
worked for me for perhaps all the softwre I have downloaded till
now). However, I had to build axiom from sources as my Linux is not
directly supported here. So after downloading, I have to wait for
another 2 hours to get a running axiom (actually, it is more than that
because Axiom is not always(oftenn)n) successfully build. Last time I
(sept sources) I could not get the gcl 7 working 'out of the box'. I
had do some modifications and got it working somehow on the
preinstalled gcl 6.something. Even with the earlier sources, when I
issued make install, the system was copied onto /usr/share/axiom (I
don't remember where) but the links that the program used internally
to call utilities distributed pointed to the location where I had
built axiom. That is too much of work and is !  horrible for a new
user--another reason for the less popularity of axiom.

After downloading axiom, a new user, say, would not find axiom as easy
to use. Axiom is much larger to download than maxima(Of course I feell
it is better), to cite an example and is not easy to get it up.

My suggestion is ( I don't know if that is possible) to take some idea
from a web browser: distribute a very basic version of axiom as a core
package and let the users download other portions of the package when
the need may be. What does firefox do if it encounters a flash object?
It informs the user that it is not able to display the content, checks
its servers with the user's permission if some plugin is available,
downloads, configurers and installs it without the user playing an
active part and displays the content. Can we not follow the same model
here? So that a possible user downloads 'plugins' to the core axiom
system?  When a user issues a plot command, the core checks whether
the package is available locally or not, if not whether that is a
valid command and if is, download, configure, build and install the
package.  On windows, that could simply be a matter of copying a dll
from the server to its directory, perhaps?

I earnestly appreciate the efforts that everyone here has put to help
axiom get better and I wish it would be the best system and outperform
any commercial system available, it is a long road to follow to reach
the destination.

\start
Date: Mon, 31 Oct 2005 10:16:39 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: re: Boot vs. Lisp

--- Bill Page wrote:

> Concerning lisp style, I think the following article is
> particularly good:
> 
> Tutorial on Good Lisp Programming Style
> 
> http://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf

Looks interesting.
 
> Being dated August 10, 1993, perhaps it is not entirely up
> to date with the available tools. And what it has to say about
> documentation seems very much oriented to the typical lisp
> programmer's view rather than Knuth's literate programming
> view, i.e. writing *code* that is intended to be read by a
> programmer as opposed to writing a *document* that contains
> code intended to be processed by the computer.

I'm not entirely sure that's incompatible - I see no reason that human
readibility of code shouldn't be a factor in the code in literate
documents.  After all, it's part of the document!  Obtuse code
associated with a documentation of the theory and reason for it might
technically be literate programming, but I'll be more impressed if the
code itself is also well layed out and organized (in the cases where
there is an irreducibly complex bit of code that it doesn't make sense
to break up and document).

> With regard to BOOT, you should note what Peter Norvig says
> about "Syntactic abstractions". I wish he had written more
> about that.

Oh, I agree that a language suited to its task is a good thing, but
this is true if and only if it makes that job so much easier it is
worth learning the additional syntax rules required to work with it. 
Any new syntax has to demonstrate it does this, or it is detrimental to
the program's maintainability - e.g. it would be simpler to figure out
a slightly more complex program in one language than to learn a new
language to figure out a simpler routine.  Maybe it would help to lay
out:

a)  What problems in Axiom BOOT is used to address.  My understanding
was that its primary task was to enable writing the SPAD/Aldor
languages - is there going to be enough work on these languages that
figuring out lisp code vs. BOOT code will impose a significant drag on
features/maintainability/what have you?

b)  A design document and spec detailing the purposes of BOOT, the
problems it solves, and formalizing the language itself so we can do
things like write advanced Emacs modes and try to adapt the SLIME
development tools to working with it.  

Tim, being as you've been through this once before, can you give us
your thoughts on this?   I'm trying to figure out a way to frame this
question so it can be decided on the merits, but it's a bit diffcult
and I'm probably not really the one who should be trying.

\start
Date: Mon, 31 Oct 2005 12:56:27 -0600
From: MathAction (unknown)
To: MathAction
Subject: [StructuredText] Usage on every page


Any hint about the usage of structured text on all the pages that are
editable will be useful. It is rather hard to remember all of these
all the times(esp. at the times of need) and would be helpful to any
newcomers.

\start
Date: Tue, 1 Nov 2005 07:01:11 +1000
From: Mike Thomas
To: Bill Page
Subject: re: Boot vs. Lisp

| So as much as I do respect lisp, I have serious doubts about
| the claim that "The skill to understand and debug lisp is
| likely to be more common down the road". For example, I think
| that in the short time that Python has existed (relative to
| lisp), it currently has many many more active programmers
| than lisp. Of course BOOT is not Python, but my point is that
| a typical Python programmer (e.g. "me" :) has much less
| resistance learning BOOT then learning lisp.

Ditto from my Haskell/ML perspective.  Once I understood the
relationship between BOOT and the Axiom language I found it much more
readable.

One wonders, however, just how complicated a build system actually has
to be particularly as Lisp is used elsewhere in Axiom.

\start
Date: Mon, 31 Oct 2005 09:06:58 -0800
From: Bob McElrath
To: Davide P.Cervone
Subject: the XHTML-ization of jsMath

I decided to try my hand again at xhtml-izing jsMath.

Important developments in this space are:
1) firefox (1.5 betas) fixed innerHTML with XHTML documents.  (It is
still depricated, but works anyway)
2) I figured out how to do document.write in XHTML using the DOMParser
class:
    jsMath.domparser = new DOMParser();
    jsMath.write = function(s) {
        var newelement = jsMath.domparser.parseFromString(
            '<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"><body>'
            +s+'</body></html>','application/xhtml+xml');
        var appendme = newelement.firstChild.firstChild.firstChild;  // node is
            // Document, child is html, child of child is body, child of child of
            // child is the requested text.
        document.getElementsByTagName('body')[0].appendChild(appendme);
    }
using this functions rather than document.write basically fixes jsMath
for XHTML mode.  Using these methods, styles written to the head with
jsMath.writehead get applied and scripts written with jsMath.write get
loaded and evaluated.  (So no need for AJAX/XMLHTTPRequest as we
previously discussed)

Attached are several patches.
    1) jsMath-xhtml-lowercase.patch
        lower-cases all HTML and adds closing / to tags like <br />,
        <img ... /> etc.  This is required by XHTML and doesn't affect
        HTML.  (no functionality change)  This patch is huge, but
        trivial.  (Note that due to some strange line formatting in your
        distributed mimeTeX.js, this patch replaces that file, but the
        only changes are as described)
    2) jsMath-xhtml-mozfix.patch
        Fixes several warnings and errors generated by Firefox 1.5 beta:
            1. If a function ever returns a value, it must always return
                a value.  e.g. 
                    function() { if(a) { return 1 } return; }
                generates this warning.
            2. "variable hides argument" when a variable is declared
                with the same name as a function argument.
            3. various missing variable declarations, missing
                semicolons, etc.
            4. use cloneNode rather than setting innerHTML in
                jsMath-controls.html. (the old method fails in XHTML
                mode, the new way works for HTML and XHTML)
    3) jsMath-xhtml.patch 
        1. document.write replacement: adds the functions jsMath.write and
        jsMath.writehead.  (document.writeln is redundant so I replaced
        it with jsMath.write)  This may require some more tooling to be
        more cross-browser.  By isolating the document.write business we
        can be both cross browser and cross HTML/XHTML.

        2. Rewrote jsMath.Setup.Script to use DOM to add scripts, since
        document.write and innerHTML are depricated, and my jsMath.write
        doesn't actually load scripts (I think this is a mozilla bug:
            https://bugzilla.mozilla.org/show_bug.cgi?id=314435 )

(the patches should be applied in this order)

With all that, XHTML works, but it seems that the offsetWidth and
offsetHeight functions you use in BBoxFor do not work (they are always
zero), which results in a couple of NaN's in the generated code, and
obviously, things being measured improperly.  I'm trying to track down
whether this is a mozilla bug, and report it if so...

I would appreciate any comments on this, and if you could add these to
jsMath.  Obviously XHTML support will require further testing
(especially on other browsers).  However the first two patches above
involve no functionality change, and are the bulk of what is required
for XHTML, so I'd appreciate if you could incorporate those two into
jsMath.

--mojUlQ0s9EVzWg2t

diff -ur jsMath-2.3b/jsMath-controls.html jsMath-2.3b-lowercase/jsMath-cont=
rols.html
--- jsMath-2.3b/jsMath-controls.html	2005-08-19 17:11:00.000000000 -0700
+++ jsMath-2.3b-lowercase/jsMath-controls.html	2005-10-30 11:11:18.00000000=
0 -0800
@@ -1,5 +1,5 @@
-<HTML>
-<HEAD>
+<html>
+<head>
 <!--
  | jsMath-controls.html
  |
@@ -23,10 +23,10 @@
  | along with jsMath; if not, write to the Free Software
  | Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  U=
SA
 -->
-</HEAD>
-<BODY>
+</head>
+<body>

-<SCRIPT>
+<script>
 while (!window.jsMath) {
   try {
     window.jsMath = window.parent.jsMath;
@@ -169,132 +169,132 @@

 });

-</SCRIPT>
+</script>

 <!------------------------------------------------------------>

-<DIV ID="jsMath.panel">
-<DIV STYLE="text-align:center">
-<B STYLE="font-size:large">jsMath
-<SCRIPT>document.write('v'+jsMath.version)</SCRIPT></B><BR>
-<SMALL>(<SPAN ID="jsMath.fontType">type</SPAN> fonts)</SMALL>
+<div id="jsMath.panel">
+<div style="text-align:center">
+<b style="font-size:large">jsMath
+<script>document.write('v'+jsMath.version)</script></b><br/>
+<small>(<span id="jsMath.fontType">type</span> fonts)</small>
 <p>
-<TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0" STYLE="margin:0p=
t 1em">
-<TR><TD ALIGN="CENTER"><TABLE BORDER="0" CELLSPACING="0" CELLPADDING=
="0">
-<TR><TD ALIGN="CENTER" COLSPAN="2">
-<TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0">
-<TR><TD>
-<UL STYLE="text-align:left; margin:0pt 0pt; padding-left:1em; padding-bo=
ttom:1em">
-<LI><A TARGET="_blank" HREF="http://www.math.union.edu:/locate/jsMath/=
users/quickstart.html">Quick Start</A></LI>
-<LI><A TARGET="_blank" HREF="http://www.math.union.edu:/locate/jsMath"=
>Home Page</A></LI>
-<LI><A TARGET="_blank" HREF="http://www.math.union.edu:/locate/jsMath/=
download/fonts.html">Download Fonts</A></LI>
-<LI><A TARGET="_blank" HREF="http://www.math.union.edu:/locate/jsMath/=
users/">Documentation</A></LI>
-<LI><A TARGET="_blank" HREF="http://www.math.union.edu:/locate/jsMath/=
bugs.html">Known Bugs</A></LI>
-<LI><A ID="jsMath.mailto" HREF="mailto:Davide P.Cervone?subject=jsMath=
 Bug Report">Bug Reports</A></LI>
-</UL>
-</TD></TR>
-</TABLE>
-</TD></TR>
-<TR><TD ALIGN="CENTER" COLSPAN="2">
-<INPUT TYPE="BUTTON" ID="jsMath.resolution" VALUE="Hi-Res Fonts for =
Printing"
-       STYLE="width:17em" onClick="jsMath.Controls.PrintResolution()">
-</TD></TR>
-<TR><TD HEIGHT="5"></TD></TR>
-<TR><TD ALIGN="LEFT">
-<INPUT TYPE="BUTTON" VALUE="Options" ID="jsMath.opts" STYLE="width=
:8em" onClick="jsMath.Controls.Options()">
+<table border="0" cellspacing="0" cellpadding="0" style="margin:0p=
t 1em">
+<tr><td align="center"><table border="0" cellspacing="0" cellpadding=
="0">
+<tr><td align="center" colspan="2">
+<table border="0" cellspacing="0" cellpadding="0">
+<tr><td>
+<ul style="text-align:left; margin:0pt 0pt; padding-left:1em; padding-bo=
ttom:1em">
+<li><a target="_blank" href="http://www.math.union.edu:/locate/jsMath/=
users/quickstart.html">Quick Start</a></li>
+<li><a target="_blank" href="http://www.math.union.edu:/locate/jsMath"=
>Home Page</a></li>
+<li><a target="_blank" href="http://www.math.union.edu:/locate/jsMath/=
download/fonts.html">Download Fonts</a></li>
+<li><a target="_blank" href="http://www.math.union.edu:/locate/jsMath/=
users/">Documentation</a></li>
+<li><a target="_blank" href="http://www.math.union.edu:/locate/jsMath/=
bugs.html">Known Bugs</a></li>
+<li><a id="jsMath.mailto" href="mailto:Davide P.Cervone?subject=jsMath=
 Bug Report">Bug Reports</a></li>
+</ul>
+</td></tr>
+</table>
+</td></tr>
+<tr><td align="center" colspan="2">
+<input type="button" id="jsMath.resolution" value="Hi-Res Fonts for =
Printing"
+       style="width:17em" onClick="jsMath.Controls.PrintResolution()" =
/>
+</td></tr>
+<tr><td height="5em"></td></tr>
+<tr><td align="left">
+<input type="button" value="Options" id="jsMath.opts" style="width=
:8em" onClick="jsMath.Controls.Options()" />
 &nbsp;
-</TD><TD ALIGN="RIGHT">
-<INPUT TYPE="BUTTON" VALUE="Done" ID="jsMath.done" STYLE="width:8e=
m" onClick="jsMath.Controls.Close()">
-</TD></TR>
-</TABLE></TD></TR>
-<TR><TD HEIGHT="10"></TD></TR>
-<TR><TD ALIGN="CENTER" COLSPAN="2" STYLE="width:20em; font-size:x-sm=
all">
-<I>Click on the jsMath floating button or <NOBR>ALT-click</NOBR> on a
-mathematical expression to get this dialog at any time.</I>
-</TD></TR>
-</TABLE><p>
-</DIV>
-</DIV>
+</td><td align="right">
+<input type="button" value="Done" id="jsMath.done" style="width:8e=
m" onClick="jsMath.Controls.Close()" />
+</td></tr>
+</table></td></tr>
+<tr><td height="10em"></td></tr>
+<tr><td align="center" colspan="2" style="width:20em; font-size:x-sm=
all">
+<i>Click on the jsMath floating button or <nobr>ALT-click</nobr> on a
+mathematical expression to get this dialog at any time.</i>
+</td></tr>
+</table><p>
+</div>
+</div>

 <!------------------------------------------------------------>

-<DIV ID="jsMath.options">
-<DIV STYLE="text-align:center">
-<B STYLE="font-size:large">jsMath Options</B> <SMALL>[<A TARGET="_blan=
k" HREF="http://www.math.union.edu/locate/jsMath/users/help.html">help</A=
>]</SMALL>
+<div id="jsMath.options">
+<div style="text-align:center">
+<b style="font-size:large">jsMath Options</b> <small>[<a target="_blan=
k" href="http://www.math.union.edu/locate/jsMath/users/help.html">help</a=
>]</small>
 <p>
-<FORM ACTION="javascript:" STYLE"margin:0">
-<TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0" STYLE="text-alig=
n:left">
+<form action="javascript:" style="margin:0">
+<table border="0" cellspacing="0" cellpadding="0" style="text-alig=
n:left">

-<TR><TD>Scale all mathematics to <INPUT TYPE="TEXT" ID="jsMath.scale" =
VALUE="100" SIZE="3">%</TD></TR>
+<tr><td>Scale all mathematics to <input type="text" id="jsMath.scale" =
value="100" size="3" />%</td></tr>

-<TR><TD HEIGHT="5"></TD></TR>
+<tr><td height="5em"></td></tr>

-<TR><TD><INPUT TYPE="RADIO" NAME="jsMath.font" VALUE="tex" onClick=
="jsMath.Controls.NoAuto()">
-<SPAN ID="jsMath.texText">Use native TeX fonts</SPAN>
-<SMALL>(<A TARGET="_blank" HREF="http://www.math.union.edu/locate/jsMa=
th/download/fonts.html">download</A>)</SMALL>
-</TD></TR>
-<TR><TD><INPUT TYPE="RADIO" NAME="jsMath.font" VALUE="image" onClick=
="jsMath.Controls.NoAuto()">
-<SPAN ID="jsMath.imageText">Use image fonts
-(<INPUT TYPE="CHECKBOX" ID="jsMath.scaleImg" VALUE="1"> scalable)</S=
PAN></TD></TR>
-<TR><TD><INPUT TYPE="RADIO" NAME="jsMath.font" VALUE="symbol" onClic=
k="jsMath.Controls.NoAuto()">
-<SPAN ID="jsMath.symbolText">Use images for symbols only</SPAN></TD></TR>
-<TR><TD HEIGHT="2"></TD></TR>
-<TR><TD><INPUT TYPE="RADIO" NAME="jsMath.font" VALUE="unicode" onCli=
ck="jsMath.Controls.NoAuto()">
-Use native Unicode fonts</TD></TR>
-
-<TR><TD HEIGHT="8"></TD></TR>
-
-<TR><TD><INPUT TYPE="CHECKBOX" ID="jsMath.autofont" VALUE="1"> Autos=
elect best font</TD></TR>
-<TR><TD><INPUT TYPE="CHECKBOX" ID="jsMath.alpha" VALUE="1"> <SPAN ID=
="jsMath.alphaText">Use image alpha channels</SPAN></TD></TR>
-<TR><TD><INPUT TYPE="CHECKBOX" ID="jsMath.warn" VALUE="1"> Show font=
 warnings</TD></TR>
-<TR><TD><INPUT TYPE="CHECKBOX" ID="jsMath.button" VALUE="1"> Show js=
Math button</TD></TR>
-
-<TR><TD HEIGHT="8"></TD></TR>
-
-<TR><TD>Save settings for
-
-<SELECT ID="jsMath.keep">
-<OPTION VALUE="0D">this session only
-<OPTION VALUE="1D">1 day
-<OPTION VALUE="2D">2 days
-<OPTION VALUE="3D">3 days
-<OPTION VALUE="1W">1 week
-<OPTION VALUE="2W">2 weeks
-<OPTION VALUE="1M">1 month
-<OPTION VALUE="2M">2 months
-<OPTION VALUE="3M">3 months
-<OPTION VALUE="6M">6 months
-<OPTION VALUE="1Y">1 year
-<OPTION VALUE="5Y">5 years
-</SELECT>
-
-</TD></TR>
-
-<TR><TD HEIGHT="13"></TD></TR>
-
-<TR><TD ALIGN="CENTER">
-<TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
-<TR>
-<TD ALIGN="Left">
-<INPUT TYPE="BUTTON" VALUE="Back" ID="jsMath.back" STYLE="width:8e=
m" onClick="jsMath.Controls.SaveOptions(0)">
+<tr><td><input type="radio" name="jsMath.font" value="tex" onClick=
="jsMath.Controls.NoAuto()" />
+<span id="jsMath.texText">Use native TeX fonts</span>
+<small>(<a target="_blank" href="http://www.math.union.edu/locate/jsMa=
th/download/fonts.html">download</a>)</small>
+</td></tr>
+<tr><td><input type="radio" name="jsMath.font" value="image" onClick=
="jsMath.Controls.NoAuto()" />
+<span id="jsMath.imageText">Use image fonts
+(<input type="checkbox" id="jsMath.scaleImg" value="1" /> scalable)<=
/span></td></tr>
+<tr><td><input type="radio" name="jsMath.font" value="symbol" onClic=
k="jsMath.Controls.NoAuto()" />
+<span id="jsMath.symbolText">Use images for symbols only</span></td></tr>
+<tr><td height="2em"></td></tr>
+<tr><td><input type="radio" name="jsMath.font" value="unicode" onCli=
ck="jsMath.Controls.NoAuto()" />
+Use native Unicode fonts</td></tr>
+
+<tr><td height="8em"></td></tr>
+
+<tr><td><input type="checkbox" id="jsMath.autofont" value="1" /> Aut=
oselect best font</td></tr>
+<tr><td><input type="checkbox" id="jsMath.alpha" value="1" /> <span =
id="jsMath.alphaText">Use image alpha channels</span></td></tr>
+<tr><td><input type="checkbox" id="jsMath.warn" value="1" /> Show fo=
nt warnings</td></tr>
+<tr><td><input type="checkbox" id="jsMath.button" value="1" /> Show =
jsMath button</td></tr>
+
+<tr><td height="8em"></td></tr>
+
+<tr><td>Save settings for
+
+<select id="jsMath.keep">
+<option value="0D">this session only
+<option value="1D">1 day
+<option value="2D">2 days
+<option value="3D">3 days
+<option value="1W">1 week
+<option value="2W">2 weeks
+<option value="1M">1 month
+<option value="2M">2 months
+<option value="3M">3 months
+<option value="6M">6 months
+<option value="1Y">1 year
+<option value="5Y">5 years
+</select>
+
+</td></tr>
+
+<tr><td height="13em"></td></tr>
+
+<tr><td align="center">
+<table border="0" cellspacing="0" cellpadding="0" width="100%">
+<tr>
+<td align="left">
+<input type="button" value="Back" id="jsMath.back" style="width:8e=
m" onClick="jsMath.Controls.SaveOptions(0)" />
 &nbsp;&nbsp;
-</TD>
-<TD ALIGN="RIGHT">
-<INPUT TYPE="BUTTON" VALUE="Done" ID="jsMath.done" STYLE="width:8e=
m" onClick="jsMath.Controls.SaveOptions(1)">
-</TD>
-</TR>
-</TABLE>
-</TD></TR>
-
-</TABLE>
-</FORM>
-</DIV>
-</DIV>
+</td>
+<td align="right">
+<input type="button" value="Done" id="jsMath.done" style="width:8e=
m" onClick="jsMath.Controls.SaveOptions(1)" />
+</td>
+</tr>
+</table>
+</td></tr>
+
+</table>
+</form>
+</div>
+</div>

 <!------------------------------------------------------------>

-<SCRIPT>
+<script>
 if (jsMath.Controls.openMain) {jsMath.Controls.Main()}
-</SCRIPT>
-</BODY>
-</HTML>
+</script>
+</body>
+</html>
diff -ur jsMath-2.3b/jsMath-fallback-mac.js jsMath-2.3b-lowercase/jsMath-fa=
llback-mac.js
--- jsMath-2.3b/jsMath-fallback-mac.js	2005-10-08 17:27:22.000000000 -0700
+++ jsMath-2.3b-lowercase/jsMath-fallback-mac.js	2005-10-30 11:11:18.000000=
000 -0800
@@ -61,7 +61,7 @@
     {c: '&#xB4;', tclass: 'accent'},
     {c: '&#x2C7;', tclass: 'accent'},
     {c: '&#x2D8;', tclass: 'accent'},
-    {c: '<SPAN STYLE="position:relative; top:.1em">&#x2C9;</SPAN>', tcla=
ss: 'accent'},
+    {c: '<span style="position:relative; top:.1em">&#x2C9;</span>', tcla=
ss: 'accent'},
     {c: '&#x2DA;', tclass: 'accent'},
     {c: '&#x0327;', tclass: 'normal'},
     {c: '&#xDF;', tclass: 'normal'},
@@ -177,17 +177,17 @@
  
   cmmi10: [
     // 00 - 0F
-    {c: '<I>&Gamma;</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '5=
8': -0.111, '127': 0.0833}, tclass: 'greek'},
-    {c: '<I>&Delta;</I>', krn: {'127': 0.167}, tclass: 'greek'},
-    {c: '<I>&Theta;</I>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'greek=
'},
-    {c: '<I>&Lambda;</I>', krn: {'127': 0.167}, tclass: 'greek'},
-    {c: '<I>&Xi;</I>', ic: 0.0757, krn: {'127': 0.0833}, tclass: 'greek'},
-    {c: '<I>&Pi;</I>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58=
': -0.0556, '127': 0.0556}, tclass: 'greek'},
-    {c: '<I>&Sigma;</I>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'greek=
'},
-    {c: '<I>&Upsilon;</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, =
'58': -0.111, '127': 0.0556}, tclass: 'greek'},
-    {c: '<I>&Phi;</I>', krn: {'127': 0.0833}, tclass: 'greek'},
-    {c: '<I>&Psi;</I>', ic: 0.11, krn: {'61': -0.0556, '59': -0.0556, '58'=
: -0.0556, '127': 0.0556}, tclass: 'greek'},
-    {c: '<I>&Omega;</I>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'greek=
'},
+    {c: '<i>&Gamma;</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '5=
8': -0.111, '127': 0.0833}, tclass: 'greek'},
+    {c: '<i>&Delta;</i>', krn: {'127': 0.167}, tclass: 'greek'},
+    {c: '<i>&Theta;</i>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'greek=
'},
+    {c: '<i>&Lambda;</i>', krn: {'127': 0.167}, tclass: 'greek'},
+    {c: '<i>&Xi;</i>', ic: 0.0757, krn: {'127': 0.0833}, tclass: 'greek'},
+    {c: '<i>&Pi;</i>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58=
': -0.0556, '127': 0.0556}, tclass: 'greek'},
+    {c: '<i>&Sigma;</i>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'greek=
'},
+    {c: '<i>&Upsilon;</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, =
'58': -0.111, '127': 0.0556}, tclass: 'greek'},
+    {c: '<i>&Phi;</i>', krn: {'127': 0.0833}, tclass: 'greek'},
+    {c: '<i>&Psi;</i>', ic: 0.11, krn: {'61': -0.0556, '59': -0.0556, '58'=
: -0.0556, '127': 0.0556}, tclass: 'greek'},
+    {c: '<i>&Omega;</i>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'greek=
'},
     {c: '&alpha;', a:0, ic: 0.0037, krn: {'127': 0.0278}, tclass: 'greek'},
     {c: '&beta;', d:1, ic: 0.0528, krn: {'127': 0.0833}, tclass: 'greek'},
     {c: '&gamma;', a:0, d:1, ic: 0.0556, tclass: 'greek'},
@@ -223,10 +223,10 @@
     {c: '&#x21BD;', a:0, d:-.1, tclass: 'harpoon'},
     {c: '&#x21C0;', a:0, d:-.2, tclass: 'harpoon'},
     {c: '&#x21C1;', a:0, d:-.1, tclass: 'harpoon'},
-    {c: '<SPAN STYLE="font-size: 133%; position:relative; top:.1em; marg=
in:-.2em; left:-.05em">&#x02D3;</SPAN>', a:.1, tclass: 'lucida'},
-    {c: '<SPAN STYLE="font-size: 133%; position:relative; top:.1em; marg=
in:-.2em; left:-.05em">&#x02D2;</SPAN>', a:.1, tclass: 'lucida'},
-    {c: '<SPAN STYLE="font-size:50%">&#x25B7;</SPAN>', tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size:50%">&#x25C1;</SPAN>', tclass: 'symbol'},
+    {c: '<span style="font-size: 133%; position:relative; top:.1em; marg=
in:-.2em; left:-.05em">&#x02D3;</span>', a:.1, tclass: 'lucida'},
+    {c: '<span style="font-size: 133%; position:relative; top:.1em; marg=
in:-.2em; left:-.05em">&#x02D2;</span>', a:.1, tclass: 'lucida'},
+    {c: '<span style="font-size:50%">&#x25B7;</span>', tclass: 'symbol'},
+    {c: '<span style="font-size:50%">&#x25C1;</span>', tclass: 'symbol'},
     // 30 - 3F
     {c: '0', tclass: 'normal'},
     {c: '1', tclass: 'normal'},
@@ -241,76 +241,76 @@
     {c: '.', a:-.3, tclass: 'normal'},
     {c: ',', a:-.3, d:.2, tclass: 'normal'},
     {c: '&lt;', a:.1, tclass: 'normal'},
-    {c: '<SPAN STYLE="font-size:133%; position:relative; top:.1em">/</SP=
AN>', d:.1, krn: {'1': -0.0556, '65': -0.0556, '77': -0.0556, '78': -0.0556=
, '89': 0.0556, '90': -0.0556}, tclass: 'normal'},
+    {c: '<span style="font-size:133%; position:relative; top:.1em">/</sp=
an>', d:.1, krn: {'1': -0.0556, '65': -0.0556, '77': -0.0556, '78': -0.0556=
, '89': 0.0556, '90': -0.0556}, tclass: 'normal'},
     {c: '&gt;', a:.1, tclass: 'normal'},
-    {c: '<SPAN STYLE="font-size:50%">&#x2605;</SPAN>', a:0, tclass: 'sym=
bol'},
+    {c: '<span style="font-size:50%">&#x2605;</span>', a:0, tclass: 'sym=
bol'},
     // 40 - 4F
     {c: '&#x2202;', ic: 0.0556, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>A</I>', krn: {'127': 0.139}, tclass: 'normal'},
-    {c: '<I>B</I>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>C</I>', ic: 0.0715, krn: {'61': -0.0278, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>D</I>', ic: 0.0278, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>E</I>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>F</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>G</I>', krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>H</I>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
-    {c: '<I>I</I>', ic: 0.0785, krn: {'127': 0.111}, tclass: 'normal'},
-    {c: '<I>J</I>', ic: 0.0962, krn: {'61': -0.0556, '59': -0.111, '58': -=
0.111, '127': 0.167}, tclass: 'normal'},
-    {c: '<I>K</I>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
-    {c: '<I>L</I>', krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>M</I>', ic: 0.109, krn: {'61': -0.0556, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>N</I>', ic: 0.109, krn: {'61': -0.0833, '61': -0.0278, '59': -=
0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>O</I>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>A</i>', krn: {'127': 0.139}, tclass: 'normal'},
+    {c: '<i>B</i>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>C</i>', ic: 0.0715, krn: {'61': -0.0278, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>D</i>', ic: 0.0278, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>E</i>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>F</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>G</i>', krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>H</i>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
+    {c: '<i>I</i>', ic: 0.0785, krn: {'127': 0.111}, tclass: 'normal'},
+    {c: '<i>J</i>', ic: 0.0962, krn: {'61': -0.0556, '59': -0.111, '58': -=
0.111, '127': 0.167}, tclass: 'normal'},
+    {c: '<i>K</i>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
+    {c: '<i>L</i>', krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>M</i>', ic: 0.109, krn: {'61': -0.0556, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>N</i>', ic: 0.109, krn: {'61': -0.0833, '61': -0.0278, '59': -=
0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>O</i>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'normal'},
     // 50 - 5F
-    {c: '<I>P</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>Q</I>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>R</I>', ic: 0.00773, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>S</I>', ic: 0.0576, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>T</I>', ic: 0.139, krn: {'61': -0.0278, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>U</I>', ic: 0.109, krn: {'59': -0.111, '58': -0.111, '61': -0.=
0556, '127': 0.0278}, tclass: 'normal'},
-    {c: '<I>V</I>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
-    {c: '<I>W</I>', ic: 0.139, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
-    {c: '<I>X</I>', ic: 0.0785, krn: {'61': -0.0833, '61': -0.0278, '59': =
-0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>Y</I>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
-    {c: '<I>Z</I>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>P</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>Q</i>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>R</i>', ic: 0.00773, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>S</i>', ic: 0.0576, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>T</i>', ic: 0.139, krn: {'61': -0.0278, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>U</i>', ic: 0.109, krn: {'59': -0.111, '58': -0.111, '61': -0.=
0556, '127': 0.0278}, tclass: 'normal'},
+    {c: '<i>V</i>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
+    {c: '<i>W</i>', ic: 0.139, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
+    {c: '<i>X</i>', ic: 0.0785, krn: {'61': -0.0833, '61': -0.0278, '59': =
-0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>Y</i>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
+    {c: '<i>Z</i>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
     {c: '&#x266D;', tclass: 'symbol2'},
     {c: '&#x266E;', tclass: 'symbol2'},
     {c: '&#x266F;', tclass: 'symbol2'},
-    {c: '<SPAN STYLE="position: relative; top:.5em">&#x2323;</SPAN>', a:=
0, d:-.1, tclass: 'normal'},
-    {c: '<SPAN STYLE="position: relative; top:-.3em">&#x2322;</SPAN>', a=
:0, d:-.1, tclass: 'normal'},
+    {c: '<span style="position: relative; top:.5em">&#x2323;</span>', a:=
0, d:-.1, tclass: 'normal'},
+    {c: '<span style="position: relative; top:-.3em">&#x2322;</span>', a=
:0, d:-.1, tclass: 'normal'},
     // 60 - 6F
     {c: '&#x2113;', krn: {'127': 0.111}, tclass: 'symbol'},
-    {c: '<I>a</I>', a:0, tclass: 'normal'},
-    {c: '<I>b</I>', tclass: 'normal'},
-    {c: '<I>c</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>d</I>', krn: {'89': 0.0556, '90': -0.0556, '106': -0.111, '102=
': -0.167, '127': 0.167}, tclass: 'normal'},
-    {c: '<I>e</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>f</I>', d:1, ic: 0.108, krn: {'59': -0.0556, '58': -0.0556, '1=
27': 0.167}, tclass: 'normal'},
-    {c: '<I>g</I>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'n=
ormal'},
-    {c: '<I>h</I>', krn: {'127': -0.0278}, tclass: 'normal'},
-    {c: '<I>i</I>', tclass: 'normal'},
-    {c: '<I>j</I>', d:1, ic: 0.0572, krn: {'59': -0.0556, '58': -0.0556}, =
tclass: 'normal'},
-    {c: '<I>k</I>', ic: 0.0315, tclass: 'normal'},
-    {c: '<I>l</I>', ic: 0.0197, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>m</I>', a:0, tclass: 'normal'},
-    {c: '<I>n</I>', a:0, tclass: 'normal'},
-    {c: '<I>o</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>a</i>', a:0, tclass: 'normal'},
+    {c: '<i>b</i>', tclass: 'normal'},
+    {c: '<i>c</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>d</i>', krn: {'89': 0.0556, '90': -0.0556, '106': -0.111, '102=
': -0.167, '127': 0.167}, tclass: 'normal'},
+    {c: '<i>e</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>f</i>', d:1, ic: 0.108, krn: {'59': -0.0556, '58': -0.0556, '1=
27': 0.167}, tclass: 'normal'},
+    {c: '<i>g</i>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'n=
ormal'},
+    {c: '<i>h</i>', krn: {'127': -0.0278}, tclass: 'normal'},
+    {c: '<i>i</i>', tclass: 'normal'},
+    {c: '<i>j</i>', d:1, ic: 0.0572, krn: {'59': -0.0556, '58': -0.0556}, =
tclass: 'normal'},
+    {c: '<i>k</i>', ic: 0.0315, tclass: 'normal'},
+    {c: '<i>l</i>', ic: 0.0197, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>m</i>', a:0, tclass: 'normal'},
+    {c: '<i>n</i>', a:0, tclass: 'normal'},
+    {c: '<i>o</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
     // 70 - 7F
-    {c: '<I>p</I>', a:0, d:1, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>q</I>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0833}, tclass: 'n=
ormal'},
-    {c: '<I>r</I>', a:0, ic: 0.0278, krn: {'59': -0.0556, '58': -0.0556, '=
127': 0.0556}, tclass: 'normal'},
-    {c: '<I>s</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>t</I>', krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>u</I>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>v</I>', a:0, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'normal=
'},
-    {c: '<I>w</I>', a:0, ic: 0.0269, krn: {'127': 0.0833}, tclass: 'normal=
'},
-    {c: '<I>x</I>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>y</I>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0556}, tclass: 'n=
ormal'},
-    {c: '<I>z</I>', a:0, ic: 0.044, krn: {'127': 0.0556}, tclass: 'normal'=
},
-    {c: '<I>&#x131;</I>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>j</I>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>p</i>', a:0, d:1, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>q</i>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0833}, tclass: 'n=
ormal'},
+    {c: '<i>r</i>', a:0, ic: 0.0278, krn: {'59': -0.0556, '58': -0.0556, '=
127': 0.0556}, tclass: 'normal'},
+    {c: '<i>s</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>t</i>', krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>u</i>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>v</i>', a:0, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'normal=
'},
+    {c: '<i>w</i>', a:0, ic: 0.0269, krn: {'127': 0.0833}, tclass: 'normal=
'},
+    {c: '<i>x</i>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>y</i>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0556}, tclass: 'n=
ormal'},
+    {c: '<i>z</i>', a:0, ic: 0.044, krn: {'127': 0.0556}, tclass: 'normal'=
},
+    {c: '<i>&#x131;</i>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>j</i>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
     {c: '&#x2118;', a:0, d:1, krn: {'127': 0.111}, tclass: 'normal'},
-    {c: '<SPAN STYLE="position:relative; left: .4em; top: -.8em; font-si=
ze: 50%">&#x2192;</SPAN>', ic: 0.154, tclass: 'symbol'},
+    {c: '<span style="position:relative; left: .4em; top: -.8em; font-si=
ze: 50%">&#x2192;</span>', ic: 0.154, tclass: 'symbol'},
     {c: '&#x0311;', ic: 0.399, tclass: 'normal'}
   ],

@@ -319,7 +319,7 @@
     {c: '&#x2212;', a:.1, tclass: 'symbol'},
     {c: '&#xB7;', a:0, d:-.2, tclass: 'symbol'},
     {c: '&#xD7;', a:0, tclass: 'symbol'},
-    {c: '<SPAN STYLE="position:relative; top:.3em">&#x2A;</SPAN>', a:0, =
tclass: 'symbol'},
+    {c: '<span style="position:relative; top:.3em">&#x2A;</span>', a:0, =
tclass: 'symbol'},
     {c: '&#xF7;', a:0, tclass: 'symbol'},
     {c: '&#x25CA;', tclass: 'lucida'},
     {c: '&#xB1;', a:.1, tclass: 'symbol'},
@@ -330,7 +330,7 @@
     {c: '&#x2298;', tclass: 'symbol'},
     {c: '&#x2299;', tclass: 'symbol3'},
     {c: '&#x25EF;', tclass: 'symbol'},
-    {c: '<SPAN STYLE="position:relative; top:.25em;">&#xB0;</SPAN>', a:0=
, d:-.1, tclass: 'symbol'},
+    {c: '<span style="position:relative; top:.25em;">&#xB0;</span>', a:0=
, d:-.1, tclass: 'symbol'},
     {c: '&#x2022;', a:0, d:-.2, tclass: 'symbol'},
     // 10 - 1F
     {c: '&#x224D;', a:.1, tclass: 'symbol'},
@@ -367,14 +367,14 @@
     {c: '&#x2199;', h:1, tclass: 'arrows'},
     {c: '&#x221D;', a:.1, tclass: 'symbol'},
     // 30 - 3F
-    {c: '<SPAN STYLE="font-size: 133%; margin-right: -.1em; position: re=
lative; top:.4em">&#x2032;</SPAN>', a: 0, tclass: 'lucida'},
+    {c: '<span style="font-size: 133%; margin-right: -.1em; position: re=
lative; top:.4em">&#x2032;</span>', a: 0, tclass: 'lucida'},
     {c: '&#x221E;', a:.1, tclass: 'symbol'},
     {c: '&#x2208;', tclass: 'symbol'},
     {c: '&#x220B;', tclass: 'symbol'},
     {c: '&#x25B3;', tclass: 'symbol'},
     {c: '&#x25BD;', tclass: 'symbol'},
     {c: '/', tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size:50%; position:relative; top:-.3em; margi=
n-right:-.2em">|</SPAN>', a:0, tclass: 'normal'},
+    {c: '<span style="font-size:50%; position:relative; top:-.3em; margi=
n-right:-.2em">|</span>', a:0, tclass: 'normal'},
     {c: '&#x2200;', tclass: 'symbol'},
     {c: '&#x2203;', tclass: 'symbol'},
     {c: '&#xAC;', a:0, d:-.1, tclass: 'symbol1'},
@@ -432,10 +432,10 @@
     {c: '||', d:.1, tclass: 'vertical'},
     {c: '&#x2195;', h:1, d:.15, tclass: 'arrow1a'},
     {c: '&#x21D5;', a:.2, d:.1, tclass: 'arrows'},
-    {c: '<SPAN STYLE="margin:-.1em">&#x2216;</SPAN>', a:.3, d:.1, tclass=
: 'lucida'},
-    {c: '<SPAN STYLE="font-size: 75%; margin:-.3em">&#x2240;</SPAN>', tc=
lass: 'symbol'},
+    {c: '<span style="margin:-.1em">&#x2216;</span>', a:.3, d:.1, tclass=
: 'lucida'},
+    {c: '<span style="font-size: 75%; margin:-.3em">&#x2240;</span>', tc=
lass: 'symbol'},
     // 70 - 7F
-    {c: '<SPAN STYLE="position:relative; top: .86em">&#x221A;</SPAN>', h=
:.04, d:.9, tclass: 'lucida'},
+    {c: '<span style="position:relative; top: .86em">&#x221A;</span>', h=
:.04, d:.9, tclass: 'lucida'},
     {c: '&#x2210;', a:.4, tclass: 'symbol'},
     {c: '&#x2207;', tclass: 'symbol'},
     {c: '&#x222B;', h:1, d:.1, ic: 0.111, tclass: 'root'},
@@ -482,8 +482,8 @@
     {c: '&#xF8FB;', h: 0.04, d: 2.36, n: 37, tclass: 'delim3'},
     {c: '&#xF8EE;', h: 0.04, d: 2.36, n: 38, tclass: 'delim3'},
     {c: '&#xF8F9;', h: 0.04, d: 2.36, n: 39, tclass: 'delim3'},
-    {c: '<SPAN STYLE="margin: -.1em">{</SPAN>', h: 0.04, d: 2.36, n: 40,=
 tclass: 'delim3'},
-    {c: '<SPAN STYLE="margin: -.1em">}</SPAN>', h: 0.04, d: 2.36, n: 41,=
 tclass: 'delim3'},
+    {c: '<span style="margin: -.1em">{</span>', h: 0.04, d: 2.36, n: 40,=
 tclass: 'delim3'},
+    {c: '<span style="margin: -.1em">}</span>', h: 0.04, d: 2.36, n: 41,=
 tclass: 'delim3'},
     {c: '&#x3008;', h: 0.04, d: 2.36, n: 42, tclass: 'delim3c'},
     {c: '&#x3009;', h: 0.04, d: 2.36, n: 43, tclass: 'delim3c'},
     {c: '&#x2215;', h: 0.04, d: 2.36, n: 44, tclass: 'delim3b'},
@@ -497,8 +497,8 @@
     {c: '&#xF8FB;', h: 0.04, d: 2.96, n: 53, tclass: 'delim4'},
     {c: '&#xF8EE;', h: 0.04, d: 2.96, n: 54, tclass: 'delim4'},
     {c: '&#xF8F9;', h: 0.04, d: 2.96, n: 55, tclass: 'delim4'},
-    {c: '<SPAN STYLE="margin: -.1em">{</SPAN>', h: 0.04, d: 2.96, n: 56,=
 tclass: 'delim4'},
-    {c: '<SPAN STYLE="margin: -.1em">}</SPAN>', h: 0.04, d: 2.96, n: 57,=
 tclass: 'delim4'},
+    {c: '<span style="margin: -.1em">{</span>', h: 0.04, d: 2.96, n: 56,=
 tclass: 'delim4'},
+    {c: '<span style="margin: -.1em">}</span>', h: 0.04, d: 2.96, n: 57,=
 tclass: 'delim4'},
     {c: '&#x3008;', h: 0.04, d: 2.96, tclass: 'delim4c'},
     {c: '&#x3009;', h: 0.04, d: 2.96, tclass: 'delim4c'},
     {c: '&#x2215;', h: 0.04, d: 2.96, tclass: 'delim4b'},
@@ -571,303 +571,303 @@
     {c: '&#xF8FB;', h: 0.04, d: 1.76, n: 23, tclass: 'delim2'},
     {c: '&#xF8EE;', h: 0.04, d: 1.76, n: 24, tclass: 'delim2'},
     {c: '&#xF8F9', h: 0.04, d: 1.76, n: 25, tclass: 'delim2'},
-    {c: '<SPAN STYLE="margin: -.1em">{</SPAN>', h: 0.04, d: 1.76, n: 26,=
 tclass: 'delim2'},
-    {c: '<SPAN STYLE="margin: -.1em">}</SPAN>', h: 0.04, d: 1.76, n: 27,=
 tclass: 'delim2'},
+    {c: '<span style="margin: -.1em">{</span>', h: 0.04, d: 1.76, n: 26,=
 tclass: 'delim2'},
+    {c: '<span style="margin: -.1em">}</span>', h: 0.04, d: 1.76, n: 27,=
 tclass: 'delim2'},
     // 70 - 7F
-    {c: '<SPAN STYLE="font-size: 125%; position:relative; top:.95em">&#x=
221A;</SPAN>', h: 0.04, d: 1.16, n: 113, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 190%; position:relative; top:.925em">&#=
x221A;</SPAN>', h: 0.04, d: 1.76, n: 114, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 250%; position:relative; top:.925em">&#=
x221A;</SPAN>', h: 0.06, d: 2.36, n: 115, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 320%; position:relative; top:.92em">&#x=
221A;</SPAN>', h: 0.08, d: 2.96, n: 116, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 400%; position:relative; top:.92em">&#x=
221A;</SPAN>', h: 0.1, d: 3.75, n: 117, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 500%; position:relative; top:.9em">&#x2=
21A;</SPAN>', h: .12, d: 4.5, n: 118, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 625%; position:relative; top:.9em">&#x2=
21A;</SPAN>', h: .14, d: 5.7, tclass: 'root'},
+    {c: '<span style="font-size: 125%; position:relative; top:.95em">&#x=
221A;</span>', h: 0.04, d: 1.16, n: 113, tclass: 'root'},
+    {c: '<span style="font-size: 190%; position:relative; top:.925em">&#=
x221A;</span>', h: 0.04, d: 1.76, n: 114, tclass: 'root'},
+    {c: '<span style="font-size: 250%; position:relative; top:.925em">&#=
x221A;</span>', h: 0.06, d: 2.36, n: 115, tclass: 'root'},
+    {c: '<span style="font-size: 320%; position:relative; top:.92em">&#x=
221A;</span>', h: 0.08, d: 2.96, n: 116, tclass: 'root'},
+    {c: '<span style="font-size: 400%; position:relative; top:.92em">&#x=
221A;</span>', h: 0.1, d: 3.75, n: 117, tclass: 'root'},
+    {c: '<span style="font-size: 500%; position:relative; top:.9em">&#x2=
21A;</span>', h: .12, d: 4.5, n: 118, tclass: 'root'},
+    {c: '<span style="font-size: 625%; position:relative; top:.9em">&#x2=
21A;</span>', h: .14, d: 5.7, tclass: 'root'},
     {c: '||', h:.65, d:.15, delim: {top: 126, bot: 127, rep: 119}, tclass:=
 'vertical2'},
     {c: '&#x25B5;', h:.4, delim: {top: 120, rep: 63}, tclass: 'arrow1b'},
     {c: '&#x25BF;', h:.38, delim: {bot: 121, rep: 63}, tclass: 'arrow1b'},
-    {c: '<SPAN STYLE="font-size: 67%; position:relative; top:.35em; marg=
in-left:-.5em">&#x256D;</SPAN>', h:.1, tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 67%; position:relative; top:.35em; marg=
in-right:-.5em">&#x256E;</SPAN>', h:.1, tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 67%; position:relative; top:.35em; marg=
in-left:-.5em">&#x2570;</SPAN>', h:.1, tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 67%; position:relative; top:.35em; marg=
in-right:-.5em">&#x256F;</SPAN>', h:.1, tclass: 'symbol'},
+    {c: '<span style="font-size: 67%; position:relative; top:.35em; marg=
in-left:-.5em">&#x256D;</span>', h:.1, tclass: 'symbol'},
+    {c: '<span style="font-size: 67%; position:relative; top:.35em; marg=
in-right:-.5em">&#x256E;</span>', h:.1, tclass: 'symbol'},
+    {c: '<span style="font-size: 67%; position:relative; top:.35em; marg=
in-left:-.5em">&#x2570;</span>', h:.1, tclass: 'symbol'},
+    {c: '<span style="font-size: 67%; position:relative; top:.35em; marg=
in-right:-.5em">&#x256F;</span>', h:.1, tclass: 'symbol'},
     {c: '&#x25B5;', h:.5, delim: {top: 126, rep: 119}, tclass: 'arrow2b'},
     {c: '&#x25BF;', h:.6, d:-.1, delim: {bot: 127, rep: 119}, tclass: 'arr=
ow2b'}
   ],
  
   cmti10: [
     // 00 - 0F
-    {c: '<I>&Gamma;</I>', ic: 0.133, tclass: 'greek'},
-    {c: '<I>&Delta;</I>', tclass: 'greek'},
-    {c: '<I>&Theta;</I>', ic: 0.094, tclass: 'greek'},
-    {c: '<I>&Lambda;</I>', tclass: 'greek'},
-    {c: '<I>&Xi;</I>', ic: 0.153, tclass: 'greek'},
-    {c: '<I>&Pi;</I>', ic: 0.164, tclass: 'greek'},
-    {c: '<I>&Sigma;</I>', ic: 0.12, tclass: 'greek'},
-    {c: '<I>&Upsilon;</I>', ic: 0.111, tclass: 'greek'},
-    {c: '<I>&Phi;</I>', ic: 0.0599, tclass: 'greek'},
-    {c: '<I>&Psi;</I>', ic: 0.111, tclass: 'greek'},
-    {c: '<I>&Omega;</I>', ic: 0.103, tclass: 'greek'},
-    {c: '<I>ff</I>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.10=
4, '41': 0.104, '93': 0.104}, lig: {'105': 14, '108': 15}, tclass: 'normal'=
},
-    {c: '<I>fi</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>fl</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>ffi</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>ffl</I>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>&Gamma;</i>', ic: 0.133, tclass: 'greek'},
+    {c: '<i>&Delta;</i>', tclass: 'greek'},
+    {c: '<i>&Theta;</i>', ic: 0.094, tclass: 'greek'},
+    {c: '<i>&Lambda;</i>', tclass: 'greek'},
+    {c: '<i>&Xi;</i>', ic: 0.153, tclass: 'greek'},
+    {c: '<i>&Pi;</i>', ic: 0.164, tclass: 'greek'},
+    {c: '<i>&Sigma;</i>', ic: 0.12, tclass: 'greek'},
+    {c: '<i>&Upsilon;</i>', ic: 0.111, tclass: 'greek'},
+    {c: '<i>&Phi;</i>', ic: 0.0599, tclass: 'greek'},
+    {c: '<i>&Psi;</i>', ic: 0.111, tclass: 'greek'},
+    {c: '<i>&Omega;</i>', ic: 0.103, tclass: 'greek'},
+    {c: '<i>ff</i>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.10=
4, '41': 0.104, '93': 0.104}, lig: {'105': 14, '108': 15}, tclass: 'normal'=
},
+    {c: '<i>fi</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>fl</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>ffi</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>ffl</i>', ic: 0.103, tclass: 'normal'},
     // 10 - 1F
-    {c: '<I>&#x131;</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>j</I>', d:.2, ic: 0.0374, tclass: 'normal'},
-    {c: '<I>&#x60;</I>', tclass: 'accent'},
-    {c: '<I>&#xB4;</I>', ic: 0.0969, tclass: 'accent'},
-    {c: '<I>&#x2C7;</I>', ic: 0.083, tclass: 'accent'},
-    {c: '<I>&#x2D8;</I>', ic: 0.108, tclass: 'accent'},
-    {c: '<I>&#x2C9;</I>', ic: 0.103, tclass: 'accent'},
-    {c: '<I>&#x2DA;</I>', tclass: 'accent'},
-    {c: '<I>?</I>', d: 0.17, w: 0.46, tclass: 'normal'},
-    {c: '<I>&#xDF;</I>', ic: 0.105, tclass: 'normal'},
-    {c: '<I>&#xE6;</I>', a:0, ic: 0.0751, tclass: 'normal'},
-    {c: '<I>&#x153;</I>', a:0, ic: 0.0751, tclass: 'normal'},
-    {c: '<I>&#xF8;</I>', ic: 0.0919, tclass: 'normal'},
-    {c: '<I>&#xC6;</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>&#x152;</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>&#xD8;</I>', ic: 0.094, tclass: 'normal'},
+    {c: '<i>&#x131;</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>j</i>', d:.2, ic: 0.0374, tclass: 'normal'},
+    {c: '<i>&#x60;</i>', tclass: 'accent'},
+    {c: '<i>&#xB4;</i>', ic: 0.0969, tclass: 'accent'},
+    {c: '<i>&#x2C7;</i>', ic: 0.083, tclass: 'accent'},
+    {c: '<i>&#x2D8;</i>', ic: 0.108, tclass: 'accent'},
+    {c: '<i>&#x2C9;</i>', ic: 0.103, tclass: 'accent'},
+    {c: '<i>&#x2DA;</i>', tclass: 'accent'},
+    {c: '<i>?</i>', d: 0.17, w: 0.46, tclass: 'normal'},
+    {c: '<i>&#xDF;</i>', ic: 0.105, tclass: 'normal'},
+    {c: '<i>&#xE6;</i>', a:0, ic: 0.0751, tclass: 'normal'},
+    {c: '<i>&#x153;</i>', a:0, ic: 0.0751, tclass: 'normal'},
+    {c: '<i>&#xF8;</i>', ic: 0.0919, tclass: 'normal'},
+    {c: '<i>&#xC6;</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>&#x152;</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>&#xD8;</i>', ic: 0.094, tclass: 'normal'},
     // 20 - 2F
-    {c: '<I>?</I>', krn: {'108': -0.256, '76': -0.321}, tclass: 'normal'},
-    {c: '<I>!</I>', ic: 0.124, lig: {'96': 60}, tclass: 'normal'},
-    {c: '<I>&#x201D;</I>', ic: 0.0696, tclass: 'normal'},
-    {c: '<I>#</I>', ic: 0.0662, tclass: 'normal'},
-    {c: '<I>$</I>', tclass: 'normal'},
-    {c: '<I>%</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>&amp;</I>', ic: 0.0969, tclass: 'normal'},
-    {c: '<I>&#x2019;</I>', ic: 0.124, krn: {'63': 0.102, '33': 0.102}, lig=
: {'39': 34}, tclass: 'normal'},
-    {c: '<I>(</I>', d:.2, ic: 0.162, tclass: 'normal'},
-    {c: '<I>)</I>', d:.2, ic: 0.0369, tclass: 'normal'},
-    {c: '<I>*</I>', ic: 0.149, tclass: 'normal'},
-    {c: '<I>+</I>', a:.1, ic: 0.0369, tclass: 'normal'},
-    {c: '<I>,</I>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
-    {c: '<I>-</I>', a:0, ic: 0.0283, lig: {'45': 123}, tclass: 'normal'},
-    {c: '<I>.</I>', a:-.25, tclass: 'normal'},
-    {c: '<I>/</I>', ic: 0.162, tclass: 'normal'},
+    {c: '<i>?</i>', krn: {'108': -0.256, '76': -0.321}, tclass: 'normal'},
+    {c: '<i>!</i>', ic: 0.124, lig: {'96': 60}, tclass: 'normal'},
+    {c: '<i>&#x201D;</i>', ic: 0.0696, tclass: 'normal'},
+    {c: '<i>#</i>', ic: 0.0662, tclass: 'normal'},
+    {c: '<i>$</i>', tclass: 'normal'},
+    {c: '<i>%</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>&amp;</i>', ic: 0.0969, tclass: 'normal'},
+    {c: '<i>&#x2019;</i>', ic: 0.124, krn: {'63': 0.102, '33': 0.102}, lig=
: {'39': 34}, tclass: 'normal'},
+    {c: '<i>(</i>', d:.2, ic: 0.162, tclass: 'normal'},
+    {c: '<i>)</i>', d:.2, ic: 0.0369, tclass: 'normal'},
+    {c: '<i>*</i>', ic: 0.149, tclass: 'normal'},
+    {c: '<i>+</i>', a:.1, ic: 0.0369, tclass: 'normal'},
+    {c: '<i>,</i>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
+    {c: '<i>-</i>', a:0, ic: 0.0283, lig: {'45': 123}, tclass: 'normal'},
+    {c: '<i>.</i>', a:-.25, tclass: 'normal'},
+    {c: '<i>/</i>', ic: 0.162, tclass: 'normal'},
     // 30 - 3F
-    {c: '<I>0</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>1</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>2</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>3</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>4</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>5</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>6</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>7</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>8</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>9</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>:</I>', ic: 0.0582, tclass: 'normal'},
-    {c: '<I>;</I>', ic: 0.0582, tclass: 'normal'},
-    {c: '<I>&#xA1;</I>', ic: 0.0756, tclass: 'normal'},
-    {c: '<I>=</I>', a:0, d:-.1, ic: 0.0662, tclass: 'normal'},
-    {c: '<I>&#xBF;</I>', tclass: 'normal'},
-    {c: '<I>?</I>', ic: 0.122, lig: {'96': 62}, tclass: 'normal'},
+    {c: '<i>0</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>1</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>2</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>3</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>4</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>5</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>6</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>7</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>8</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>9</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>:</i>', ic: 0.0582, tclass: 'normal'},
+    {c: '<i>;</i>', ic: 0.0582, tclass: 'normal'},
+    {c: '<i>&#xA1;</i>', ic: 0.0756, tclass: 'normal'},
+    {c: '<i>=</i>', a:0, d:-.1, ic: 0.0662, tclass: 'normal'},
+    {c: '<i>&#xBF;</i>', tclass: 'normal'},
+    {c: '<i>?</i>', ic: 0.122, lig: {'96': 62}, tclass: 'normal'},
     // 40 - 4F
-    {c: '<I>@</I>', ic: 0.096, tclass: 'normal'},
-    {c: '<I>A</I>', krn: {'110': -0.0256, '108': -0.0256, '114': -0.0256, =
'117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256, '67': -0.02=
56, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256, '85': -0.0=
256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0256, '84': -=
0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.0511, '97': -0=
=2E0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '11=
3': -0.0511}, tclass: 'normal'},
-    {c: '<I>B</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>C</I>', ic: 0.145, tclass: 'normal'},
-    {c: '<I>D</I>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
-    {c: '<I>E</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>F</I>', ic: 0.133, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>G</I>', ic: 0.0872, tclass: 'normal'},
-    {c: '<I>H</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>I</I>', ic: 0.158, tclass: 'normal'},
-    {c: '<I>J</I>', ic: 0.14, tclass: 'normal'},
-    {c: '<I>K</I>', ic: 0.145, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>L</I>', krn: {'84': -0.0767, '89': -0.0767, '86': -0.102, '87'=
: -0.102, '101': -0.0511, '97': -0.0511, '111': -0.0511, '100': -0.0511, '9=
9': -0.0511, '103': -0.0511, '113': -0.0511}, tclass: 'normal'},
-    {c: '<I>M</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>N</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>O</I>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
+    {c: '<i>@</i>', ic: 0.096, tclass: 'normal'},
+    {c: '<i>A</i>', krn: {'110': -0.0256, '108': -0.0256, '114': -0.0256, =
'117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256, '67': -0.02=
56, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256, '85': -0.0=
256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0256, '84': -=
0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.0511, '97': -0=
=2E0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '11=
3': -0.0511}, tclass: 'normal'},
+    {c: '<i>B</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>C</i>', ic: 0.145, tclass: 'normal'},
+    {c: '<i>D</i>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
+    {c: '<i>E</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>F</i>', ic: 0.133, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>G</i>', ic: 0.0872, tclass: 'normal'},
+    {c: '<i>H</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>I</i>', ic: 0.158, tclass: 'normal'},
+    {c: '<i>J</i>', ic: 0.14, tclass: 'normal'},
+    {c: '<i>K</i>', ic: 0.145, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>L</i>', krn: {'84': -0.0767, '89': -0.0767, '86': -0.102, '87'=
: -0.102, '101': -0.0511, '97': -0.0511, '111': -0.0511, '100': -0.0511, '9=
9': -0.0511, '103': -0.0511, '113': -0.0511}, tclass: 'normal'},
+    {c: '<i>M</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>N</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>O</i>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
     // 50 - 5F
-    {c: '<I>P</I>', ic: 0.103, krn: {'65': -0.0767}, tclass: 'normal'},
-    {c: '<I>Q</I>', d: 1, ic: 0.094, tclass: 'normal'},
-    {c: '<I>R</I>', ic: 0.0387, krn: {'110': -0.0256, '108': -0.0256, '114=
': -0.0256, '117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256,=
 '67': -0.0256, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256=
, '85': -0.0256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0=
256, '84': -0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.05=
11, '97': -0.0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0=
=2E0511, '113': -0.0511}, tclass: 'normal'},
-    {c: '<I>S</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>T</I>', ic: 0.133, krn: {'121': -0.0767, '101': -0.0767, '111'=
: -0.0767, '114': -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, t=
class: 'normal'},
-    {c: '<I>U</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>V</I>', ic: 0.184, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>W</I>', ic: 0.184, krn: {'65': -0.0767}, tclass: 'normal'},
-    {c: '<I>X</I>', ic: 0.158, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>Y</I>', ic: 0.194, krn: {'101': -0.0767, '111': -0.0767, '114'=
: -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, tclass: 'normal'},
-    {c: '<I>Z</I>', ic: 0.145, tclass: 'normal'},
-    {c: '<I>[</I>', d:.1, ic: 0.188, tclass: 'normal'},
-    {c: '<I>&#x201C;</I>', ic: 0.169, tclass: 'normal'},
-    {c: '<I>]</I>', d:.1, ic: 0.105, tclass: 'normal'},
-    {c: '<I>&#x2C6;</I>', ic: 0.0665, tclass: 'accent'},
-    {c: '<I>&#x2D9;</I>', ic: 0.118, tclass: 'accent'},
+    {c: '<i>P</i>', ic: 0.103, krn: {'65': -0.0767}, tclass: 'normal'},
+    {c: '<i>Q</i>', d: 1, ic: 0.094, tclass: 'normal'},
+    {c: '<i>R</i>', ic: 0.0387, krn: {'110': -0.0256, '108': -0.0256, '114=
': -0.0256, '117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256,=
 '67': -0.0256, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256=
, '85': -0.0256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0=
256, '84': -0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.05=
11, '97': -0.0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0=
=2E0511, '113': -0.0511}, tclass: 'normal'},
+    {c: '<i>S</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>T</i>', ic: 0.133, krn: {'121': -0.0767, '101': -0.0767, '111'=
: -0.0767, '114': -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, t=
class: 'normal'},
+    {c: '<i>U</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>V</i>', ic: 0.184, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>W</i>', ic: 0.184, krn: {'65': -0.0767}, tclass: 'normal'},
+    {c: '<i>X</i>', ic: 0.158, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>Y</i>', ic: 0.194, krn: {'101': -0.0767, '111': -0.0767, '114'=
: -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, tclass: 'normal'},
+    {c: '<i>Z</i>', ic: 0.145, tclass: 'normal'},
+    {c: '<i>[</i>', d:.1, ic: 0.188, tclass: 'normal'},
+    {c: '<i>&#x201C;</i>', ic: 0.169, tclass: 'normal'},
+    {c: '<i>]</i>', d:.1, ic: 0.105, tclass: 'normal'},
+    {c: '<i>&#x2C6;</i>', ic: 0.0665, tclass: 'accent'},
+    {c: '<i>&#x2D9;</i>', ic: 0.118, tclass: 'accent'},
     // 60 - 6F
-    {c: '<I>&#x2018;</I>', ic: 0.124, lig: {'96': 92}, tclass: 'normal'},
-    {c: '<I>a</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>b</I>', ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, '111'=
: -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.0511}, =
tclass: 'normal'},
-    {c: '<I>c</I>', a:0, ic: 0.0565, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
-    {c: '<I>d</I>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
-    {c: '<I>e</I>', a:0, ic: 0.0751, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
-    {c: '<I>f</I>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.104=
, '41': 0.104, '93': 0.104}, lig: {'105': 12, '102': 11, '108': 13}, tclass=
: 'normal'},
-    {c: '<I>g</I>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
-    {c: '<I>h</I>', ic: 0.0767, tclass: 'normal'},
-    {c: '<I>i</I>', ic: 0.102, tclass: 'normal'},
-    {c: '<I>j</I>', d:1, ic: 0.145, tclass: 'normal'},
-    {c: '<I>k</I>', ic: 0.108, tclass: 'normal'},
-    {c: '<I>l</I>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
-    {c: '<I>m</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>n</I>', a:0, ic: 0.0767, krn: {'39': -0.102}, tclass: 'normal'=
},
-    {c: '<I>o</I>', a:0, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
+    {c: '<i>&#x2018;</i>', ic: 0.124, lig: {'96': 92}, tclass: 'normal'},
+    {c: '<i>a</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>b</i>', ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, '111'=
: -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.0511}, =
tclass: 'normal'},
+    {c: '<i>c</i>', a:0, ic: 0.0565, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
+    {c: '<i>d</i>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
+    {c: '<i>e</i>', a:0, ic: 0.0751, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
+    {c: '<i>f</i>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.104=
, '41': 0.104, '93': 0.104}, lig: {'105': 12, '102': 11, '108': 13}, tclass=
: 'normal'},
+    {c: '<i>g</i>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
+    {c: '<i>h</i>', ic: 0.0767, tclass: 'normal'},
+    {c: '<i>i</i>', ic: 0.102, tclass: 'normal'},
+    {c: '<i>j</i>', d:1, ic: 0.145, tclass: 'normal'},
+    {c: '<i>k</i>', ic: 0.108, tclass: 'normal'},
+    {c: '<i>l</i>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
+    {c: '<i>m</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>n</i>', a:0, ic: 0.0767, krn: {'39': -0.102}, tclass: 'normal'=
},
+    {c: '<i>o</i>', a:0, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
     // 70 - 7F
-    {c: '<I>p</I>', a:0, d:1, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0=
511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': =
-0.0511}, tclass: 'normal'},
-    {c: '<I>q</I>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
-    {c: '<I>r</I>', a:0, ic: 0.108, krn: {'101': -0.0511, '97': -0.0511, '=
111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.051=
1}, tclass: 'normal'},
-    {c: '<I>s</I>', a:0, ic: 0.0821, tclass: 'normal'},
-    {c: '<I>t</I>', ic: 0.0949, tclass: 'normal'},
-    {c: '<I>u</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>v</I>', a:0, ic: 0.108, tclass: 'normal'},
-    {c: '<I>w</I>', a:0, ic: 0.108, krn: {'108': 0.0511}, tclass: 'normal'=
},
-    {c: '<I>x</I>', a:0, ic: 0.12, tclass: 'normal'},
-    {c: '<I>y</I>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
-    {c: '<I>z</I>', a:0, ic: 0.123, tclass: 'normal'},
-    {c: '<I>&#x2013;</I>', a:.1, ic: 0.0921, lig: {'45': 124}, tclass: 'no=
rmal'},
-    {c: '<I>&#x2014;</I>', a:.1, ic: 0.0921, tclass: 'normal'},
-    {c: '<I>&#x2DD;</I>', ic: 0.122, tclass: 'accent'},
-    {c: '<I>&#x2DC;</I>', ic: 0.116, tclass: 'accent'},
-    {c: '<I>&#xA8;</I>', tclass: 'accent'}
+    {c: '<i>p</i>', a:0, d:1, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0=
511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': =
-0.0511}, tclass: 'normal'},
+    {c: '<i>q</i>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
+    {c: '<i>r</i>', a:0, ic: 0.108, krn: {'101': -0.0511, '97': -0.0511, '=
111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.051=
1}, tclass: 'normal'},
+    {c: '<i>s</i>', a:0, ic: 0.0821, tclass: 'normal'},
+    {c: '<i>t</i>', ic: 0.0949, tclass: 'normal'},
+    {c: '<i>u</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>v</i>', a:0, ic: 0.108, tclass: 'normal'},
+    {c: '<i>w</i>', a:0, ic: 0.108, krn: {'108': 0.0511}, tclass: 'normal'=
},
+    {c: '<i>x</i>', a:0, ic: 0.12, tclass: 'normal'},
+    {c: '<i>y</i>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
+    {c: '<i>z</i>', a:0, ic: 0.123, tclass: 'normal'},
+    {c: '<i>&#x2013;</i>', a:.1, ic: 0.0921, lig: {'45': 124}, tclass: 'no=
rmal'},
+    {c: '<i>&#x2014;</i>', a:.1, ic: 0.0921, tclass: 'normal'},
+    {c: '<i>&#x2DD;</i>', ic: 0.122, tclass: 'accent'},
+    {c: '<i>&#x2DC;</i>', ic: 0.116, tclass: 'accent'},
+    {c: '<i>&#xA8;</i>', tclass: 'accent'}
   ],
  
   cmbx10: [
     // 00 - 0F
-    {c: '<B>&Gamma;</B>', tclass: 'greek'},
-    {c: '<B>&Delta;</B>', tclass: 'greek'},
-    {c: '<B>&Theta;</B>', tclass: 'greek'},
-    {c: '<B>&Lambda;</B>', tclass: 'greek'},
-    {c: '<B>&Xi;</B>', tclass: 'greek'},
-    {c: '<B>&Pi;</B>', tclass: 'greek'},
-    {c: '<B>&Sigma;</B>', tclass: 'greek'},
-    {c: '<B>&Upsilon;</B>', tclass: 'greek'},
-    {c: '<B>&Phi;</B>', tclass: 'greek'},
-    {c: '<B>&Psi;</B>', tclass: 'greek'},
-    {c: '<B>&Omega;</B>', tclass: 'greek'},
-    {c: '<B>ff</B>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0=
=2E0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 14, '108': 15}, tclass: =
'normal'},
-    {c: '<B>fi</B>', tclass: 'normal'},
-    {c: '<B>fl</B>', tclass: 'normal'},
-    {c: '<B>ffi</B>', tclass: 'normal'},
-    {c: '<B>ffl</B>', tclass: 'normal'},
+    {c: '<b>&Gamma;</b>', tclass: 'greek'},
+    {c: '<b>&Delta;</b>', tclass: 'greek'},
+    {c: '<b>&Theta;</b>', tclass: 'greek'},
+    {c: '<b>&Lambda;</b>', tclass: 'greek'},
+    {c: '<b>&Xi;</b>', tclass: 'greek'},
+    {c: '<b>&Pi;</b>', tclass: 'greek'},
+    {c: '<b>&Sigma;</b>', tclass: 'greek'},
+    {c: '<b>&Upsilon;</b>', tclass: 'greek'},
+    {c: '<b>&Phi;</b>', tclass: 'greek'},
+    {c: '<b>&Psi;</b>', tclass: 'greek'},
+    {c: '<b>&Omega;</b>', tclass: 'greek'},
+    {c: '<b>ff</b>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0=
=2E0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 14, '108': 15}, tclass: =
'normal'},
+    {c: '<b>fi</b>', tclass: 'normal'},
+    {c: '<b>fl</b>', tclass: 'normal'},
+    {c: '<b>ffi</b>', tclass: 'normal'},
+    {c: '<b>ffl</b>', tclass: 'normal'},
     // 10 - 1F
-    {c: '<B>&#x131;</B>', a:0, tclass: 'normal'},
-    {c: '<B>j</B>', d:.2, tclass: 'normal'},
-    {c: '<B>&#x60;</B>', tclass: 'accent'},
-    {c: '<B>&#xB4;</B>', tclass: 'accent'},
-    {c: '<B>&#x2C7;</B>', tclass: 'accent'},
-    {c: '<B>&#x2D8;</B>', tclass: 'accent'},
-    {c: '<B>&#x2C9;</B>', tclass: 'accent'},
-    {c: '<B>&#x2DA;</B>', tclass: 'accent'},
-    {c: '<B>?</B>', tclass: 'normal'},
-    {c: '<B>&#xDF;</B>', tclass: 'normal'},
-    {c: '<B>&#xE6;</B>', a:0, tclass: 'normal'},
-    {c: '<B>&#x153;</B>', a:0, tclass: 'normal'},
-    {c: '<B>&#xF8;</B>', tclass: 'normal'},
-    {c: '<B>&#xC6;</B>', tclass: 'normal'},
-    {c: '<B>&#x152;</B>', tclass: 'normal'},
-    {c: '<B>&#xD8;</B>', tclass: 'normal'},
+    {c: '<b>&#x131;</b>', a:0, tclass: 'normal'},
+    {c: '<b>j</b>', d:.2, tclass: 'normal'},
+    {c: '<b>&#x60;</b>', tclass: 'accent'},
+    {c: '<b>&#xB4;</b>', tclass: 'accent'},
+    {c: '<b>&#x2C7;</b>', tclass: 'accent'},
+    {c: '<b>&#x2D8;</b>', tclass: 'accent'},
+    {c: '<b>&#x2C9;</b>', tclass: 'accent'},
+    {c: '<b>&#x2DA;</b>', tclass: 'accent'},
+    {c: '<b>?</b>', tclass: 'normal'},
+    {c: '<b>&#xDF;</b>', tclass: 'normal'},
+    {c: '<b>&#xE6;</b>', a:0, tclass: 'normal'},
+    {c: '<b>&#x153;</b>', a:0, tclass: 'normal'},
+    {c: '<b>&#xF8;</b>', tclass: 'normal'},
+    {c: '<b>&#xC6;</b>', tclass: 'normal'},
+    {c: '<b>&#x152;</b>', tclass: 'normal'},
+    {c: '<b>&#xD8;</b>', tclass: 'normal'},
     // 20 - 2F
-    {c: '<B>?</B>', krn: {'108': -0.278, '76': -0.319}, tclass: 'normal'},
-    {c: '<B>!</B>', lig: {'96': 60}, tclass: 'normal'},
-    {c: '<B>&#x201D;</B>', tclass: 'normal'},
-    {c: '<B>#</B>', tclass: 'normal'},
-    {c: '<B>$</B>', tclass: 'normal'},
-    {c: '<B>%</B>', tclass: 'normal'},
-    {c: '<B>&amp;</B>', tclass: 'normal'},
-    {c: '<B>&#x2019;</B>', krn: {'63': 0.111, '33': 0.111}, lig: {'39': 34=
}, tclass: 'normal'},
-    {c: '<B>(</B>', d:.2, tclass: 'normal'},
-    {c: '<B>)</B>', d:.2, tclass: 'normal'},
-    {c: '<B>*</B>', tclass: 'normal'},
-    {c: '<B>+</B>', a:.1, tclass: 'normal'},
-    {c: '<B>,</B>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
-    {c: '<B>-</B>', a:0, lig: {'45': 123}, tclass: 'normal'},
-    {c: '<B>.</B>', a:-.25, tclass: 'normal'},
-    {c: '<B>/</B>', tclass: 'normal'},
+    {c: '<b>?</b>', krn: {'108': -0.278, '76': -0.319}, tclass: 'normal'},
+    {c: '<b>!</b>', lig: {'96': 60}, tclass: 'normal'},
+    {c: '<b>&#x201D;</b>', tclass: 'normal'},
+    {c: '<b>#</b>', tclass: 'normal'},
+    {c: '<b>$</b>', tclass: 'normal'},
+    {c: '<b>%</b>', tclass: 'normal'},
+    {c: '<b>&amp;</b>', tclass: 'normal'},
+    {c: '<b>&#x2019;</b>', krn: {'63': 0.111, '33': 0.111}, lig: {'39': 34=
}, tclass: 'normal'},
+    {c: '<b>(</b>', d:.2, tclass: 'normal'},
+    {c: '<b>)</b>', d:.2, tclass: 'normal'},
+    {c: '<b>*</b>', tclass: 'normal'},
+    {c: '<b>+</b>', a:.1, tclass: 'normal'},
+    {c: '<b>,</b>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
+    {c: '<b>-</b>', a:0, lig: {'45': 123}, tclass: 'normal'},
+    {c: '<b>.</b>', a:-.25, tclass: 'normal'},
+    {c: '<b>/</b>', tclass: 'normal'},
     // 30 - 3F
-    {c: '<B>0</B>', tclass: 'normal'},
-    {c: '<B>1</B>', tclass: 'normal'},
-    {c: '<B>2</B>', tclass: 'normal'},
-    {c: '<B>3</B>', tclass: 'normal'},
-    {c: '<B>4</B>', tclass: 'normal'},
-    {c: '<B>5</B>', tclass: 'normal'},
-    {c: '<B>6</B>', tclass: 'normal'},
-    {c: '<B>7</B>', tclass: 'normal'},
-    {c: '<B>8</B>', tclass: 'normal'},
-    {c: '<B>9</B>', tclass: 'normal'},
-    {c: '<B>:</B>', tclass: 'normal'},
-    {c: '<B>;</B>', tclass: 'normal'},
-    {c: '<B>&#xA1;</B>', tclass: 'normal'},
-    {c: '<B>=</B>', a:0, d:-.1, tclass: 'normal'},
-    {c: '<B>&#xBF;</B>', tclass: 'normal'},
-    {c: '<B>?</B>', lig: {'96': 62}, tclass: 'normal'},
+    {c: '<b>0</b>', tclass: 'normal'},
+    {c: '<b>1</b>', tclass: 'normal'},
+    {c: '<b>2</b>', tclass: 'normal'},
+    {c: '<b>3</b>', tclass: 'normal'},
+    {c: '<b>4</b>', tclass: 'normal'},
+    {c: '<b>5</b>', tclass: 'normal'},
+    {c: '<b>6</b>', tclass: 'normal'},
+    {c: '<b>7</b>', tclass: 'normal'},
+    {c: '<b>8</b>', tclass: 'normal'},
+    {c: '<b>9</b>', tclass: 'normal'},
+    {c: '<b>:</b>', tclass: 'normal'},
+    {c: '<b>;</b>', tclass: 'normal'},
+    {c: '<b>&#xA1;</b>', tclass: 'normal'},
+    {c: '<b>=</b>', a:0, d:-.1, tclass: 'normal'},
+    {c: '<b>&#xBF;</b>', tclass: 'normal'},
+    {c: '<b>?</b>', lig: {'96': 62}, tclass: 'normal'},
     // 40 - 4F
-    {c: '<B>@</B>', tclass: 'normal'},
-    {c: '<B>A</B>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
-    {c: '<B>B</B>', tclass: 'normal'},
-    {c: '<B>C</B>', tclass: 'normal'},
-    {c: '<B>D</B>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
-    {c: '<B>E</B>', tclass: 'normal'},
-    {c: '<B>F</B>', krn: {'111': -0.0833, '101': -0.0833, '117': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67': -0.0278, =
'71': -0.0278, '81': -0.0278}, tclass: 'normal'},
-    {c: '<B>G</B>', tclass: 'normal'},
-    {c: '<B>H</B>', tclass: 'normal'},
-    {c: '<B>I</B>', krn: {'73': 0.0278}, tclass: 'normal'},
-    {c: '<B>J</B>', tclass: 'normal'},
-    {c: '<B>K</B>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
-    {c: '<B>L</B>', krn: {'84': -0.0833, '89': -0.0833, '86': -0.111, '87'=
: -0.111}, tclass: 'normal'},
-    {c: '<B>M</B>', tclass: 'normal'},
-    {c: '<B>N</B>', tclass: 'normal'},
-    {c: '<B>O</B>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
+    {c: '<b>@</b>', tclass: 'normal'},
+    {c: '<b>A</b>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
+    {c: '<b>B</b>', tclass: 'normal'},
+    {c: '<b>C</b>', tclass: 'normal'},
+    {c: '<b>D</b>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
+    {c: '<b>E</b>', tclass: 'normal'},
+    {c: '<b>F</b>', krn: {'111': -0.0833, '101': -0.0833, '117': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67': -0.0278, =
'71': -0.0278, '81': -0.0278}, tclass: 'normal'},
+    {c: '<b>G</b>', tclass: 'normal'},
+    {c: '<b>H</b>', tclass: 'normal'},
+    {c: '<b>I</b>', krn: {'73': 0.0278}, tclass: 'normal'},
+    {c: '<b>J</b>', tclass: 'normal'},
+    {c: '<b>K</b>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
+    {c: '<b>L</b>', krn: {'84': -0.0833, '89': -0.0833, '86': -0.111, '87'=
: -0.111}, tclass: 'normal'},
+    {c: '<b>M</b>', tclass: 'normal'},
+    {c: '<b>N</b>', tclass: 'normal'},
+    {c: '<b>O</b>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
     // 50 - 5F
-    {c: '<B>P</B>', krn: {'65': -0.0833, '111': -0.0278, '101': -0.0278, '=
97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
-    {c: '<B>Q</B>', d: 1, tclass: 'normal'},
-    {c: '<B>R</B>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
-    {c: '<B>S</B>', tclass: 'normal'},
-    {c: '<B>T</B>', krn: {'121': -0.0278, '101': -0.0833, '111': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'nor=
mal'},
-    {c: '<B>U</B>', tclass: 'normal'},
-    {c: '<B>V</B>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
-    {c: '<B>W</B>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
-    {c: '<B>X</B>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
-    {c: '<B>Y</B>', ic: 0.025, krn: {'101': -0.0833, '111': -0.0833, '114'=
: -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'normal'},
-    {c: '<B>Z</B>', tclass: 'normal'},
-    {c: '<B>[</B>', d:.1, tclass: 'normal'},
-    {c: '<B>&#x201C;</B>', tclass: 'normal'},
-    {c: '<B>]</B>', d:.1, tclass: 'normal'},
-    {c: '<B>&#x2C6;</B>', tclass: 'accent'},
-    {c: '<B>&#x2D9;</B>', tclass: 'accent'},
+    {c: '<b>P</b>', krn: {'65': -0.0833, '111': -0.0278, '101': -0.0278, '=
97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
+    {c: '<b>Q</b>', d: 1, tclass: 'normal'},
+    {c: '<b>R</b>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
+    {c: '<b>S</b>', tclass: 'normal'},
+    {c: '<b>T</b>', krn: {'121': -0.0278, '101': -0.0833, '111': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'nor=
mal'},
+    {c: '<b>U</b>', tclass: 'normal'},
+    {c: '<b>V</b>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
+    {c: '<b>W</b>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
+    {c: '<b>X</b>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
+    {c: '<b>Y</b>', ic: 0.025, krn: {'101': -0.0833, '111': -0.0833, '114'=
: -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'normal'},
+    {c: '<b>Z</b>', tclass: 'normal'},
+    {c: '<b>[</b>', d:.1, tclass: 'normal'},
+    {c: '<b>&#x201C;</b>', tclass: 'normal'},
+    {c: '<b>]</b>', d:.1, tclass: 'normal'},
+    {c: '<b>&#x2C6;</b>', tclass: 'accent'},
+    {c: '<b>&#x2D9;</b>', tclass: 'accent'},
     // 60 - 6F
-    {c: '<B>&#x2018;</B>', lig: {'96': 92}, tclass: 'normal'},
-    {c: '<B>a</B>', a:0, krn: {'118': -0.0278, '106': 0.0556, '121': -0.02=
78, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>b</B>', krn: {'101': 0.0278, '111': 0.0278, '120': -0.0278, '1=
00': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.0556, '1=
21': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>c</B>', a:0, krn: {'104': -0.0278, '107': -0.0278}, tclass: 'n=
ormal'},
-    {c: '<B>d</B>', tclass: 'normal'},
-    {c: '<B>e</B>', a:0, tclass: 'normal'},
-    {c: '<B>f</B>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0.=
0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 12, '102': 11, '108': 13}, =
tclass: 'normal'},
-    {c: '<B>g</B>', a:0, d:1, ic: 0.0139, krn: {'106': 0.0278}, tclass: 'n=
ormal'},
-    {c: '<B>h</B>', krn: {'116': -0.0278, '117': -0.0278, '98': -0.0278, '=
121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>i</B>', tclass: 'normal'},
-    {c: '<B>j</B>', d:1, tclass: 'normal'},
-    {c: '<B>k</B>', krn: {'97': -0.0556, '101': -0.0278, '97': -0.0278, '1=
11': -0.0278, '99': -0.0278}, tclass: 'normal'},
-    {c: '<B>l</B>', tclass: 'normal'},
-    {c: '<B>m</B>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>n</B>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>o</B>', a:0, krn: {'101': 0.0278, '111': 0.0278, '120': -0.027=
8, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.055=
6, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>&#x2018;</b>', lig: {'96': 92}, tclass: 'normal'},
+    {c: '<b>a</b>', a:0, krn: {'118': -0.0278, '106': 0.0556, '121': -0.02=
78, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>b</b>', krn: {'101': 0.0278, '111': 0.0278, '120': -0.0278, '1=
00': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.0556, '1=
21': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>c</b>', a:0, krn: {'104': -0.0278, '107': -0.0278}, tclass: 'n=
ormal'},
+    {c: '<b>d</b>', tclass: 'normal'},
+    {c: '<b>e</b>', a:0, tclass: 'normal'},
+    {c: '<b>f</b>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0.=
0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 12, '102': 11, '108': 13}, =
tclass: 'normal'},
+    {c: '<b>g</b>', a:0, d:1, ic: 0.0139, krn: {'106': 0.0278}, tclass: 'n=
ormal'},
+    {c: '<b>h</b>', krn: {'116': -0.0278, '117': -0.0278, '98': -0.0278, '=
121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>i</b>', tclass: 'normal'},
+    {c: '<b>j</b>', d:1, tclass: 'normal'},
+    {c: '<b>k</b>', krn: {'97': -0.0556, '101': -0.0278, '97': -0.0278, '1=
11': -0.0278, '99': -0.0278}, tclass: 'normal'},
+    {c: '<b>l</b>', tclass: 'normal'},
+    {c: '<b>m</b>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>n</b>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>o</b>', a:0, krn: {'101': 0.0278, '111': 0.0278, '120': -0.027=
8, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.055=
6, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
     // 70 - 7F
-    {c: '<B>p</B>', a:0, d:1, krn: {'101': 0.0278, '111': 0.0278, '120': -=
0.0278, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': =
0.0556, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>q</B>', a:0, d:1, tclass: 'normal'},
-    {c: '<B>r</B>', a:0, tclass: 'normal'},
-    {c: '<B>s</B>', a:0, tclass: 'normal'},
-    {c: '<B>t</B>', krn: {'121': -0.0278, '119': -0.0278}, tclass: 'normal=
'},
-    {c: '<B>u</B>', a:0, krn: {'119': -0.0278}, tclass: 'normal'},
-    {c: '<B>v</B>', a:0, ic: 0.0139, krn: {'97': -0.0556, '101': -0.0278, =
'97': -0.0278, '111': -0.0278, '99': -0.0278}, tclass: 'normal'},
-    {c: '<B>w</B>', a:0, ic: 0.0139, krn: {'101': -0.0278, '97': -0.0278, =
'111': -0.0278, '99': -0.0278}, tclass: 'normal'},
-    {c: '<B>x</B>', a:0, tclass: 'normal'},
-    {c: '<B>y</B>', a:0, d:1, ic: 0.0139, krn: {'111': -0.0278, '101': -0.=
0278, '97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
-    {c: '<B>z</B>', a:0, tclass: 'normal'},
-    {c: '<B>&#x2013;</B>', a:.1, ic: 0.0278, lig: {'45': 124}, tclass: 'no=
rmal'},
-    {c: '<B>&#x2014;</B>', a:.1, ic: 0.0278, tclass: 'normal'},
-    {c: '<B>&#x2DD;</B>', tclass: 'accent'},
-    {c: '<B>&#x2DC;</B>', tclass: 'accent'},
-    {c: '<B>&#xA8;</B>', tclass: 'accent'}
+    {c: '<b>p</b>', a:0, d:1, krn: {'101': 0.0278, '111': 0.0278, '120': -=
0.0278, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': =
0.0556, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>q</b>', a:0, d:1, tclass: 'normal'},
+    {c: '<b>r</b>', a:0, tclass: 'normal'},
+    {c: '<b>s</b>', a:0, tclass: 'normal'},
+    {c: '<b>t</b>', krn: {'121': -0.0278, '119': -0.0278}, tclass: 'normal=
'},
+    {c: '<b>u</b>', a:0, krn: {'119': -0.0278}, tclass: 'normal'},
+    {c: '<b>v</b>', a:0, ic: 0.0139, krn: {'97': -0.0556, '101': -0.0278, =
'97': -0.0278, '111': -0.0278, '99': -0.0278}, tclass: 'normal'},
+    {c: '<b>w</b>', a:0, ic: 0.0139, krn: {'101': -0.0278, '97': -0.0278, =
'111': -0.0278, '99': -0.0278}, tclass: 'normal'},
+    {c: '<b>x</b>', a:0, tclass: 'normal'},
+    {c: '<b>y</b>', a:0, d:1, ic: 0.0139, krn: {'111': -0.0278, '101': -0.=
0278, '97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
+    {c: '<b>z</b>', a:0, tclass: 'normal'},
+    {c: '<b>&#x2013;</b>', a:.1, ic: 0.0278, lig: {'45': 124}, tclass: 'no=
rmal'},
+    {c: '<b>&#x2014;</b>', a:.1, ic: 0.0278, tclass: 'normal'},
+    {c: '<b>&#x2DD;</b>', tclass: 'accent'},
+    {c: '<b>&#x2DC;</b>', tclass: 'accent'},
+    {c: '<b>&#xA8;</b>', tclass: 'accent'}
   ]
 });

@@ -893,8 +893,8 @@
       var ph = Math.round(h*jsMath.em);
       if (h > jsMath.hd) {
         box.bd = jsMath.EmBoxFor(jsMath.HTML.Class(c.tclass,c.c)
-                   + '<IMG SRC="'+jsMath.blank+'" STYLE="'
-                   + 'width: 1; height: '+ph+'px">').h - h;
+                   + '<img src="'+jsMath.blank+'" style="'
+                   + 'width: 1px; height: '+ph+'px" />').h - h;
         box.bh = h - box.bd;
       }
       c.bh = box.bh/scale;
@@ -904,7 +904,7 @@
       // hack to avoid Font changing back to the default
       // font when a unicode reference is not followed
       // by a letter or number
-      box.html += '<SPAN STYLE="display: none">x</SPAN>'
+      box.html += '<span style="display: none">x</span>'
     }
     return box;
   }
@@ -965,26 +965,26 @@
  */

 jsMath.noAppleSymbols =  (jsMath.BBoxFor('&#x2223;').w ==
-    jsMath.BBoxFor('<SPAN STYLE="font-family: Apple Symbols">&#x2223;</S=
PAN>').w);
+    jsMath.BBoxFor('<span style="font-family: Apple Symbols">&#x2223;</s=
pan>').w);

 if (jsMath.noAppleSymbols) {
   jsMath.Update.TeXfonts({
     cmsy10: {
-      '16': {c: '<SPAN STYLE="position:relative;top:.25em; font-size: 67=
%">&#x2323;</SPAN><SPAN STYLE="position:relative;top:-.15em;font-size:67%=
;margin-left:-1em">&#x2322;</SPAN>', tclass: 'normal'},
-      '22': {c: '&#x227A;<SPAN STYLE="position:relative;top:.3em; margin=
-left:-1em">&mdash;</SPAN>', tclass: 'normal'},
-      '23': {c: '&#x227B;<SPAN STYLE="position:relative;top:.3em; margin=
-left:-1em">&mdash;</SPAN>', tclass: 'normal'},
+      '16': {c: '<span style="position:relative;top:.25em; font-size: 67=
%">&#x2323;</span><span style="position:relative;top:-.15em;font-size:67%=
;margin-left:-1em">&#x2322;</span>', tclass: 'normal'},
+      '22': {c: '&#x227A;<span style="position:relative;top:.3em; margin=
-left:-1em">&mdash;</span>', tclass: 'normal'},
+      '23': {c: '&#x227B;<span style="position:relative;top:.3em; margin=
-left:-1em">&mdash;</span>', tclass: 'normal'},
       '91': {c: '&#x222A;'},
       '92': {c: '&#x2229;'},
-      '93': {c: '&#x222A;<SPAN STYLE="font-size: 50%; margin-left:-1.1em=
; position: relative; top:-.3em; margin-right:.4em">+</SPAN>'},
+      '93': {c: '&#x222A;<span style="font-size: 50%; margin-left:-1.1em=
; position: relative; top:-.3em; margin-right:.4em">+</span>'},
       '94': {c: '&#x2227;'},
       '95': {c: '&#x2228;'},
-      '96': {c: '|<SPAN STYLE="position:relative; top:-.15em; margin-lef=
t:-.1em">&ndash;</SPAN>', tclass: 'normal'},
-      '109': {c: '&#x21D1;<SPAN STYLE="position:relative; top:.1em; marg=
in-left:-.6em">&#x21D3;</SPAN>', h:.9, d:.2, tclass: 'arrow2a'}
+      '96': {c: '|<span style="position:relative; top:-.15em; margin-lef=
t:-.1em">&ndash;</span>', tclass: 'normal'},
+      '109': {c: '&#x21D1;<span style="position:relative; top:.1em; marg=
in-left:-.6em">&#x21D3;</span>', h:.9, d:.2, tclass: 'arrow2a'}
     },
    
     cmex10: {
-      '85': {c: '&#x222A;<SPAN STYLE="font-size: 50%; margin-left:-1.1em=
; position: relative; top:-.3em; margin-right:.4em">+</SPAN>'},
-      '93': {c: '&#x222A;<SPAN STYLE="font-size: 50%; margin-left:-1.1em=
; position: relative; top:-.3em; margin-right:.4em">+</SPAN>'}
+      '85': {c: '&#x222A;<span style="font-size: 50%; margin-left:-1.1em=
; position: relative; top:-.3em; margin-right:.4em">+</span>'},
+      '93': {c: '&#x222A;<span style="font-size: 50%; margin-left:-1.1em=
; position: relative; top:-.3em; margin-right:.4em">+</span>'}
     }
   });

@@ -1003,9 +1003,9 @@
 if (navigator.accentColorName) {
   jsMath.Update.TeXfonts({
     cmsy10: {
-      '55':  {c: '<SPAN STYLE="font-size: 75%; position:relative; left:.=
3em; top:-.15em; margin-left:-.3em">&#x02EB;</SPAN>'},
-      '104': {c: '<SPAN STYLE="position:relative; top:.2em; margin-left:=
-.55em">&#x3008;</SPAN>'},
-      '105': {c: '<SPAN STYLE="position:relative; top:.2em; margin-right=
:-.55em">&#x3009;</SPAN>'}
+      '55':  {c: '<span style="font-size: 75%; position:relative; left:.=
3em; top:-.15em; margin-left:-.3em">&#x02EB;</span>'},
+      '104': {c: '<span style="position:relative; top:.2em; margin-left:=
-.55em">&#x3008;</span>'},
+      '105': {c: '<span style="position:relative; top:.2em; margin-right=
:-.55em">&#x3009;</span>'}
     }
   });
  
@@ -1016,9 +1016,9 @@
   if (jsMath.noAppleSymbols) {
     jsMath.Update.TeXfonts({
       cmsy10: {
-        '22': {c: '&#x227A;<SPAN STYLE="position:relative;top:.25em; mar=
gin-left:-.8em; margin-right:.2em">&ndash;</SPAN>', tclass: 'normal'},
-        '23': {c: '&#x227B;<SPAN STYLE="position:relative;top:.25em; mar=
gin-left:-.7em; margin-right:.1em">&ndash;</SPAN>', tclass: 'normal'},
-        '96': {c: '<SPAN STYLE="font-size:80%; position:relative; top:-.=
15em">|</SPAN><SPAN STYLE="position:relative; top:-.1em; margin-left:-.1e=
m">&ndash;</SPAN>', tclass: 'normal'}
+        '22': {c: '&#x227A;<span style="position:relative;top:.25em; mar=
gin-left:-.8em; margin-right:.2em">&ndash;</span>', tclass: 'normal'},
+        '23': {c: '&#x227B;<span style="position:relative;top:.25em; mar=
gin-left:-.7em; margin-right:.1em">&ndash;</span>', tclass: 'normal'},
+        '96': {c: '<span style="font-size:80%; position:relative; top:-.=
15em">|</span><span style="position:relative; top:-.1em; margin-left:-.1e=
m">&ndash;</span>', tclass: 'normal'}
       }
     });
   }
diff -ur jsMath-2.3b/jsMath-fallback-mac-mozilla.js jsMath-2.3b-lowercase/j=
sMath-fallback-mac-mozilla.js
--- jsMath-2.3b/jsMath-fallback-mac-mozilla.js	2005-04-23 13:06:44.00000000=
0 -0700
+++ jsMath-2.3b-lowercase/jsMath-fallback-mac-mozilla.js	2005-10-30 11:11:1=
8.000000000 -0800
@@ -35,22 +35,22 @@
   cmmi10: {
 //  '41':  // leftharpoondown
 //  '43':  // rightharpoondown   
-    '44': {c: '<SPAN STYLE="position:relative; top:.15em; margin-right:-=
=2E1em; margin-left:-.2em">&#x02D3;</SPAN>'},
-    '45': {c: '<SPAN STYLE="position:relative; top:.15em; margin-right:-=
=2E1em; margin-left:-.2em">&#x02D2;</SPAN>'},
-    '47': {c: '<SPAN STYLE="font-size:60%">&#x25C1;</SPAN>'},
+    '44': {c: '<span style="position:relative; top:.15em; margin-right:-=
=2E1em; margin-left:-.2em">&#x02D3;</span>'},
+    '45': {c: '<span style="position:relative; top:.15em; margin-right:-=
=2E1em; margin-left:-.2em">&#x02D2;</span>'},
+    '47': {c: '<span style="font-size:60%">&#x25C1;</span>'},
 //  '92':  // natural
-    '126': {c: '<SPAN STYLE="position:relative; left: .3em; top: -.7em; =
font-size: 50%">&#x2192;</SPAN>'}
+    '126': {c: '<span style="position:relative; left: .3em; top: -.7em; =
font-size: 50%">&#x2192;</span>'}
   },

   cmsy10: {
     '0':  {c: '&ndash;', tclass: 'normal'},
-    '11': {c: '<SPAN STYLE="font-size: 70%">&#x25EF;</SPAN><SPAN STYLE=
="position:relative; margin-left:-.5em; top:.1em; margin-right:.3em">/</S=
PAN>', tclass: 'normal'},
+    '11': {c: '<span style="font-size: 70%">&#x25EF;</span><span style=
="position:relative; margin-left:-.5em; top:.1em; margin-right:.3em">/</s=
pan>', tclass: 'normal'},
     '42': {c: '&#x2963;'}, '43': {c: '&#x2965'},
-    '48': {c: '<SPAN STYLE="font-size: 133%; margin-right: -.75em; posit=
ion: relative; top:.4em">&#x2032;</SPAN>', tclass: 'normal'},
-    '93': {c: '&#x222A;<SPAN STYLE="font-size: 50%; margin-left:-1.3em; =
position: relative; top:-.3em; margin-right:.6em">+</SPAN>'},
-    '104': {c: '<SPAN STYLE="position:relative; top:.15em; margin-left:-=
=2E6em">&#x3008;</SPAN>'},
-    '105': {c: '<SPAN STYLE="position:relative; top:.15em; margin-right:=
-.6em">&#x3009;</SPAN>'},
-    '109': {c: '&#x2963;<SPAN STYLE="position:relative; top:.1em; margin=
-left:-1em">&#x2965;</SPAN>'}
+    '48': {c: '<span style="font-size: 133%; margin-right: -.75em; posit=
ion: relative; top:.4em">&#x2032;</span>', tclass: 'normal'},
+    '93': {c: '&#x222A;<span style="font-size: 50%; margin-left:-1.3em; =
position: relative; top:-.3em; margin-right:.6em">+</span>'},
+    '104': {c: '<span style="position:relative; top:.15em; margin-left:-=
=2E6em">&#x3008;</span>'},
+    '105': {c: '<span style="position:relative; top:.15em; margin-right:=
-.6em">&#x3009;</span>'},
+    '109': {c: '&#x2963;<span style="position:relative; top:.1em; margin=
-left:-1em">&#x2965;</span>'}
 //, '116':  // sqcup
 //  '117':  // sqcap
 //  '118':  // sqsubseteq
@@ -58,24 +58,24 @@
   },
  
   cmex10: {
-    '10': {c: '<SPAN STYLE="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</SPAN>'},
-    '11': {c: '<SPAN STYLE="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</SPAN>'},
+    '10': {c: '<span style="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</span>'},
+    '11': {c: '<span style="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</span>'},
     '14': {c: '/'}, '15': {c: '\\'},
-    '28': {c: '<SPAN STYLE="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</SPAN>'},
-    '29': {c: '<SPAN STYLE="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</SPAN>'},
+    '28': {c: '<span style="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</span>'},
+    '29': {c: '<span style="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</span>'},
     '30': {c: '/'}, '31': {c: '\\'},
-    '42': {c: '<SPAN STYLE="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</SPAN>'},
-    '43': {c: '<SPAN STYLE="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</SPAN>'},
+    '42': {c: '<span style="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</span>'},
+    '43': {c: '<span style="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</span>'},
     '44': {c: '/'}, '45': {c: '\\'},
     '46': {c: '/'}, '47': {c: '\\'},
-    '68': {c: '<SPAN STYLE="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</SPAN>'},
-    '69': {c: '<SPAN STYLE="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</SPAN>'},
+    '68': {c: '<span style="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</span>'},
+    '69': {c: '<span style="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</span>'},
 //  '70':  // sqcup
 //  '71':  // big sqcup
     '72': {ic: .194},  '73': {ic: .444},
     '82': {tclass: 'bigop1cx', ic: .15}, '90': {tclass: 'bigop2cx', ic:.6},
-    '85': {c: '&#x222A;<SPAN STYLE="font-size: 50%; margin-left:-1.3em; =
position: relative; top:-.3em; margin-right:.6em">+</SPAN>'},
-    '93': {c: '&#x222A;<SPAN STYLE="font-size: 50%; margin-left:-1.3em; =
position: relative; top:-.3em; margin-right:.6em">+</SPAN>'}
+    '85': {c: '&#x222A;<span style="font-size: 50%; margin-left:-1.3em; =
position: relative; top:-.3em; margin-right:.6em">+</span>'},
+    '93': {c: '&#x222A;<span style="font-size: 50%; margin-left:-1.3em; =
position: relative; top:-.3em; margin-right:.6em">+</span>'}
   }
  
 });
diff -ur jsMath-2.3b/jsMath-fallback-mac-msie.js jsMath-2.3b-lowercase/jsMa=
th-fallback-mac-msie.js
--- jsMath-2.3b/jsMath-fallback-mac-msie.js	2005-04-23 13:06:30.000000000 -=
0700
+++ jsMath-2.3b-lowercase/jsMath-fallback-mac-msie.js	2005-10-30 11:11:18.0=
00000000 -0800
@@ -44,50 +44,50 @@
     '8':  {c: 'F', tclass: 'greek'},
     '9':  {c: 'Y', tclass: 'greek'},
     '10': {c: 'W', tclass: 'greek'},
-    '22': {c: '<SPAN STYLE="position:relative; top:.1em">&#96;</SPAN>', =
tclass: 'symbol3'}
+    '22': {c: '<span style="position:relative; top:.1em">&#96;</span>', =
tclass: 'symbol3'}
   },
  
   cmti10: {
-    '0':  {c: '<I>G</I>', tclass: 'greek'},
-    '1':  {c: '<I>D</I>', tclass: 'greek'},
-    '2':  {c: '<I>Q</I>', tclass: 'greek'},
-    '3':  {c: '<I>L</I>', tclass: 'greek'},
-    '4':  {c: '<I>X</I>', tclass: 'greek'},
-    '5':  {c: '<I>P</I>', tclass: 'greek'},
-    '6':  {c: '<I>S</I>', tclass: 'greek'},
-    '7':  {c: '<I>&#161;</I>', tclass: 'greek'},
-    '8':  {c: '<I>F</I>', tclass: 'greek'},
-    '9':  {c: '<I>Y</I>', tclass: 'greek'},
-    '10': {c: '<I>W</I>', tclass: 'greek'},
-    '22': {c: '<SPAN STYLE="position:relative; top:.1em">&#96;</SPAN>', =
tclass: 'symbol3'}
+    '0':  {c: '<i>G</i>', tclass: 'greek'},
+    '1':  {c: '<i>D</i>', tclass: 'greek'},
+    '2':  {c: '<i>Q</i>', tclass: 'greek'},
+    '3':  {c: '<i>L</i>', tclass: 'greek'},
+    '4':  {c: '<i>X</i>', tclass: 'greek'},
+    '5':  {c: '<i>P</i>', tclass: 'greek'},
+    '6':  {c: '<i>S</i>', tclass: 'greek'},
+    '7':  {c: '<i>&#161;</i>', tclass: 'greek'},
+    '8':  {c: '<i>F</i>', tclass: 'greek'},
+    '9':  {c: '<i>Y</i>', tclass: 'greek'},
+    '10': {c: '<i>W</i>', tclass: 'greek'},
+    '22': {c: '<span style="position:relative; top:.1em">&#96;</span>', =
tclass: 'symbol3'}
   },
  
   cmbx10: {
-    '0':  {c: '<B>G</B>', tclass: 'greek'},
-    '1':  {c: '<B>D</B>', tclass: 'greek'},
-    '2':  {c: '<B>Q</B>', tclass: 'greek'},
-    '3':  {c: '<B>L</B>', tclass: 'greek'},
-    '4':  {c: '<B>X</B>', tclass: 'greek'},
-    '5':  {c: '<B>P</B>', tclass: 'greek'},
-    '6':  {c: '<B>S</B>', tclass: 'greek'},
-    '7':  {c: '<B>&#161;</B>', tclass: 'greek'},
-    '8':  {c: '<B>F</B>', tclass: 'greek'},
-    '9':  {c: '<B>Y</B>', tclass: 'greek'},
-    '10': {c: '<B>W</B>', tclass: 'greek'},
-    '22': {c: '<SPAN STYLE="position:relative; top:.1em">&#96;</SPAN>', =
tclass: 'symbol3'}
+    '0':  {c: '<b>G</b>', tclass: 'greek'},
+    '1':  {c: '<b>D</b>', tclass: 'greek'},
+    '2':  {c: '<b>Q</b>', tclass: 'greek'},
+    '3':  {c: '<b>L</b>', tclass: 'greek'},
+    '4':  {c: '<b>X</b>', tclass: 'greek'},
+    '5':  {c: '<b>P</b>', tclass: 'greek'},
+    '6':  {c: '<b>S</b>', tclass: 'greek'},
+    '7':  {c: '<b>&#161;</b>', tclass: 'greek'},
+    '8':  {c: '<b>F</b>', tclass: 'greek'},
+    '9':  {c: '<b>Y</b>', tclass: 'greek'},
+    '10': {c: '<b>W</b>', tclass: 'greek'},
+    '22': {c: '<span style="position:relative; top:.1em">&#96;</span>', =
tclass: 'symbol3'}
   },
   cmmi10: {
-    '0':  {c: '<I>G</I>', tclass: 'greek'},
-    '1':  {c: '<I>D</I>', tclass: 'greek'},
-    '2':  {c: '<I>Q</I>', tclass: 'greek'},
-    '3':  {c: '<I>L</I>', tclass: 'greek'},
-    '4':  {c: '<I>X</I>', tclass: 'greek'},
-    '5':  {c: '<I>P</I>', tclass: 'greek'},
-    '6':  {c: '<I>S</I>', tclass: 'greek'},
-    '7':  {c: '<I>&#161;</I>', tclass: 'greek'},
-    '8':  {c: '<I>F</I>', tclass: 'greek'},
-    '9':  {c: '<I>Y</I>', tclass: 'greek'},
-    '10': {c: '<I>W</I>', tclass: 'greek'},
+    '0':  {c: '<i>G</i>', tclass: 'greek'},
+    '1':  {c: '<i>D</i>', tclass: 'greek'},
+    '2':  {c: '<i>Q</i>', tclass: 'greek'},
+    '3':  {c: '<i>L</i>', tclass: 'greek'},
+    '4':  {c: '<i>X</i>', tclass: 'greek'},
+    '5':  {c: '<i>P</i>', tclass: 'greek'},
+    '6':  {c: '<i>S</i>', tclass: 'greek'},
+    '7':  {c: '<i>&#161;</i>', tclass: 'greek'},
+    '8':  {c: '<i>F</i>', tclass: 'greek'},
+    '9':  {c: '<i>Y</i>', tclass: 'greek'},
+    '10': {c: '<i>W</i>', tclass: 'greek'},
     '11': {c: 'a', tclass: 'greek'},
     '12': {c: 'b', tclass: 'greek'},
     '13': {c: 'g', tclass: 'greek'},
@@ -116,21 +116,21 @@
 //  '44':  // hook left
 //  '45':  // hook right
 //  '92':  // natural
-    '94': {c: '<SPAN STYLE="position:relative; top:.3em">&#xFE36;</SPAN>=
'},
-    '95': {c: '<SPAN STYLE="position:relative; top:-.2em">&#xFE35;</SPAN=
>'}
+    '94': {c: '<span style="position:relative; top:.3em">&#xFE36;</span>=
'},
+    '95': {c: '<span style="position:relative; top:-.2em">&#xFE35;</span=
>'}
 //  '127': // half-circle down accent?
   },

   cmsy10: {
     '0':  {c: '&ndash;', tclass: 'normal'},
-    '11': {c: '<SPAN STYLE="font-size: 70%">&#x25EF;</SPAN><SPAN STYLE=
="position:relative; margin-left:-.5em; top:.1em; margin-right:.3em">/</S=
PAN>', tclass: 'normal'},
-    '16': {c: '<SPAN STYLE="position:relative;top:-.1em; font-size: 67%"=
>&#xFE35;</SPAN><SPAN STYLE="position:relative;top:.1em;font-size:67%;mar=
gin-left:-1em">&#xFE36;</SPAN>', tclass: 'normal'},
-    '48': {c: '<SPAN STYLE="font-size: 133%; margin-left:-.1em; margin-r=
ight: -.6em; position: relative; top:.4em">&#x2032;</SPAN>'},
-    '93': {c: '&#x222A;<SPAN STYLE="font-size: 50%; margin-left:-1.3em; =
position: relative; top:-.3em; margin-right:.6em">+</SPAN>'},
-    '96': {c: '<SPAN STYLE="font-size:67%; position:relative; top:-.3em;=
">|</SPAN><SPAN STYLE="position:relative; top:-.15em; margin-left:-.1em">=
&ndash;</SPAN>', tclass: 'normal'},
-    '104': {c: '<SPAN STYLE="position:relative; top:.2em; margin-left:-.=
6em">&#x3008;</SPAN>'},
-    '105': {c: '<SPAN STYLE="position:relative; top:.2em; margin-right:-=
=2E6em">&#x3009;</SPAN>'},
-    '109': {c: '&#x21D1;<SPAN STYLE="position:relative; top:.1em; margin=
-left:-1em">&#x21D3;</SPAN>'},
+    '11': {c: '<span style="font-size: 70%">&#x25EF;</span><span style=
="position:relative; margin-left:-.5em; top:.1em; margin-right:.3em">/</s=
pan>', tclass: 'normal'},
+    '16': {c: '<span style="position:relative;top:-.1em; font-size: 67%"=
>&#xFE35;</span><span style="position:relative;top:.1em;font-size:67%;mar=
gin-left:-1em">&#xFE36;</span>', tclass: 'normal'},
+    '48': {c: '<span style="font-size: 133%; margin-left:-.1em; margin-r=
ight: -.6em; position: relative; top:.4em">&#x2032;</span>'},
+    '93': {c: '&#x222A;<span style="font-size: 50%; margin-left:-1.3em; =
position: relative; top:-.3em; margin-right:.6em">+</span>'},
+    '96': {c: '<span style="font-size:67%; position:relative; top:-.3em;=
">|</span><span style="position:relative; top:-.15em; margin-left:-.1em">=
&ndash;</span>', tclass: 'normal'},
+    '104': {c: '<span style="position:relative; top:.2em; margin-left:-.=
6em">&#x3008;</span>'},
+    '105': {c: '<span style="position:relative; top:.2em; margin-right:-=
=2E6em">&#x3009;</span>'},
+    '109': {c: '&#x21D1;<span style="position:relative; top:.1em; margin=
-left:-1em">&#x21D3;</span>'},
     '110': {c: '\\', d:0, tclass: 'normal'}
 //  '111': // wr
 //, '113': // amalg
@@ -141,24 +141,24 @@
   },

   cmex10: {
-    '10': {c: '<SPAN STYLE="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</SPAN>'},
-    '11': {c: '<SPAN STYLE="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</SPAN>'},
+    '10': {c: '<span style="position:relative; top:.1em; margin-left:-.6=
em">&#x3008;</span>'},
+    '11': {c: '<span style="position:relative; top:.1em; margin-right:-.=
6em">&#x3009;</span>'},
     '14': {c: '/'}, '15': {c: '\\'},
-    '28': {c: '<SPAN STYLE="position:relative; top:.05em; margin-left:-.=
6em">&#x3008;</SPAN>'},
-    '29': {c: '<SPAN STYLE="position:relative; top:.05em; margin-right:-=
=2E6em">&#x3009;</SPAN>'},
+    '28': {c: '<span style="position:relative; top:.05em; margin-left:-.=
6em">&#x3008;</span>'},
+    '29': {c: '<span style="position:relative; top:.05em; margin-right:-=
=2E6em">&#x3009;</span>'},
     '30': {c: '/'}, '31': {c: '\\'},
-    '42': {c: '<SPAN STYLE="margin-left:-.6em">&#x3008;</SPAN>'},
-    '43': {c: '<SPAN STYLE="margin-right:-.6em">&#x3009;</SPAN>'},
+    '42': {c: '<span style="margin-left:-.6em">&#x3008;</span>'},
+    '43': {c: '<span style="margin-right:-.6em">&#x3009;</span>'},
     '44': {c: '/'}, '45': {c: '\\'},
     '46': {c: '/'}, '47': {c: '\\'},
-    '68': {c: '<SPAN STYLE="margin-left:-.6em">&#x3008;</SPAN>'},
-    '69': {c: '<SPAN STYLE="margin-right:-.6em">&#x3009;</SPAN>'},
+    '68': {c: '<span style="margin-left:-.6em">&#x3008;</span>'},
+    '69': {c: '<span style="margin-right:-.6em">&#x3009;</span>'},
 //  '70':  // sqcup
 //  '71':  // big sqcup
     '72': {ic: 0},  '73': {ic: 0},
     '82': {tclass: 'bigop1cx', ic: .15}, '90': {tclass: 'bigop2cx', ic:.6},
-    '85': {c: '&#x222A;<SPAN STYLE="font-size: 50%; margin-left:-1.25em;=
 position: relative; top:-.3em; margin-right:.6em">+</SPAN>'},
-    '93': {c: '&#x222A;<SPAN STYLE="font-size: 50%; margin-left:-1.25em;=
 position: relative; top:-.3em; margin-right:.6em">+</SPAN>'},
+    '85': {c: '&#x222A;<span style="font-size: 50%; margin-left:-1.25em;=
 position: relative; top:-.3em; margin-right:.6em">+</span>'},
+    '93': {c: '&#x222A;<span style="font-size: 50%; margin-left:-1.25em;=
 position: relative; top:-.3em; margin-right:.6em">+</span>'},
 //  '96': // coprod
 //  '97': // big coprod
     '98': {c: '&#xFE3F;', h: 0.722, w: .58, tclass: 'wide1'},
diff -ur jsMath-2.3b/jsMath-fallback-pc.js jsMath-2.3b-lowercase/jsMath-fal=
lback-pc.js
--- jsMath-2.3b/jsMath-fallback-pc.js	2005-10-08 17:27:32.000000000 -0700
+++ jsMath-2.3b-lowercase/jsMath-fallback-pc.js	2005-10-30 11:15:00.0000000=
00 -0800
@@ -177,17 +177,17 @@
  
   cmmi10: [
     // 00 - 0F
-    {c: '<I>&Gamma;</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '5=
8': -0.111, '127': 0.0833}, tclass: 'greek'},
-    {c: '<I>&Delta;</I>', krn: {'127': 0.167}, tclass: 'greek'},
-    {c: '<I>&Theta;</I>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'greek=
'},
-    {c: '<I>&Lambda;</I>', krn: {'127': 0.167}, tclass: 'greek'},
-    {c: '<I>&Xi;</I>', ic: 0.0757, krn: {'127': 0.0833}, tclass: 'greek'},
-    {c: '<I>&Pi;</I>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58=
': -0.0556, '127': 0.0556}, tclass: 'greek'},
-    {c: '<I>&Sigma;</I>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'greek=
'},
-    {c: '<I>&Upsilon;</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, =
'58': -0.111, '127': 0.0556}, tclass: 'greek'},
-    {c: '<I>&Phi;</I>', krn: {'127': 0.0833}, tclass: 'greek'},
-    {c: '<I>&Psi;</I>', ic: 0.11, krn: {'61': -0.0556, '59': -0.0556, '58'=
: -0.0556, '127': 0.0556}, tclass: 'greek'},
-    {c: '<I>&Omega;</I>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'greek=
'},
+    {c: '<i>&Gamma;</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '5=
8': -0.111, '127': 0.0833}, tclass: 'greek'},
+    {c: '<i>&Delta;</i>', krn: {'127': 0.167}, tclass: 'greek'},
+    {c: '<i>&Theta;</i>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'greek=
'},
+    {c: '<i>&Lambda;</i>', krn: {'127': 0.167}, tclass: 'greek'},
+    {c: '<i>&Xi;</i>', ic: 0.0757, krn: {'127': 0.0833}, tclass: 'greek'},
+    {c: '<i>&Pi;</i>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58=
': -0.0556, '127': 0.0556}, tclass: 'greek'},
+    {c: '<i>&Sigma;</i>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'greek=
'},
+    {c: '<i>&Upsilon;</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, =
'58': -0.111, '127': 0.0556}, tclass: 'greek'},
+    {c: '<i>&Phi;</i>', krn: {'127': 0.0833}, tclass: 'greek'},
+    {c: '<i>&Psi;</i>', ic: 0.11, krn: {'61': -0.0556, '59': -0.0556, '58'=
: -0.0556, '127': 0.0556}, tclass: 'greek'},
+    {c: '<i>&Omega;</i>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'greek=
'},
     {c: '&alpha;', a:0, ic: 0.0037, krn: {'127': 0.0278}, tclass: 'greek'},
     {c: '&beta;', d:1, ic: 0.0528, krn: {'127': 0.0833}, tclass: 'greek'},
     {c: '&gamma;', a:0, d:1, ic: 0.0556, tclass: 'greek'},
@@ -223,8 +223,8 @@
     {c: '&#x21BD;', a:0, d:-.1, tclass: 'arrows'},
     {c: '&#x21C0;', a:0, d:-.2, tclass: 'arrows'},
     {c: '&#x21C1;', a:0, d:-.1, tclass: 'arrows'},
-    {c: '<SPAN STYLE="position:relative; top:-.1em">&#x02D3;</SPAN>', a:=
=2E1, tclass: 'symbol'},
-    {c: '<SPAN STYLE="position:relative; top:-.1em">&#x02D2;</SPAN>', a:=
=2E1, tclass: 'symbol'},
+    {c: '<span style="position:relative; top:-.1em">&#x02D3;</span>', a:=
=2E1, tclass: 'symbol'},
+    {c: '<span style="position:relative; top:-.1em">&#x02D2;</span>', a:=
=2E1, tclass: 'symbol'},
     {c: '&#x25B9;', tclass: 'symbol'},
     {c: '&#x25C3;', tclass: 'symbol'},
     // 30 - 3F
@@ -241,85 +241,85 @@
     {c: '.', a:-.3, tclass: 'normal'},
     {c: ',', a:-.3, d:.2, tclass: 'normal'},
     {c: '&lt;', a:.1, tclass: 'normal'},
-    {c: '<SPAN STYLE="font-size:133%; position:relative; top:.1em">/</SP=
AN>', d:.1, krn: {'1': -0.0556, '65': -0.0556, '77': -0.0556, '78': -0.0556=
, '89': 0.0556, '90': -0.0556}, tclass: 'normal'},
+    {c: '<span style="font-size:133%; position:relative; top:.1em">/</sp=
an>', d:.1, krn: {'1': -0.0556, '65': -0.0556, '77': -0.0556, '78': -0.0556=
, '89': 0.0556, '90': -0.0556}, tclass: 'normal'},
     {c: '&gt;', a:.1, tclass: 'normal'},
     {c: '&#x22C6;', a:0, tclass: 'arial'},
     // 40 - 4F
     {c: '&#x2202;', ic: 0.0556, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>A</I>', krn: {'127': 0.139}, tclass: 'normal'},
-    {c: '<I>B</I>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>C</I>', ic: 0.0715, krn: {'61': -0.0278, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>D</I>', ic: 0.0278, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>E</I>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>F</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>G</I>', krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>H</I>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
-    {c: '<I>I</I>', ic: 0.0785, krn: {'127': 0.111}, tclass: 'normal'},
-    {c: '<I>J</I>', ic: 0.0962, krn: {'61': -0.0556, '59': -0.111, '58': -=
0.111, '127': 0.167}, tclass: 'normal'},
-    {c: '<I>K</I>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
-    {c: '<I>L</I>', krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>M</I>', ic: 0.109, krn: {'61': -0.0556, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>N</I>', ic: 0.109, krn: {'61': -0.0833, '61': -0.0278, '59': -=
0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>O</I>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>A</i>', krn: {'127': 0.139}, tclass: 'normal'},
+    {c: '<i>B</i>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>C</i>', ic: 0.0715, krn: {'61': -0.0278, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>D</i>', ic: 0.0278, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>E</i>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>F</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>G</i>', krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>H</i>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
+    {c: '<i>I</i>', ic: 0.0785, krn: {'127': 0.111}, tclass: 'normal'},
+    {c: '<i>J</i>', ic: 0.0962, krn: {'61': -0.0556, '59': -0.111, '58': -=
0.111, '127': 0.167}, tclass: 'normal'},
+    {c: '<i>K</i>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
+    {c: '<i>L</i>', krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>M</i>', ic: 0.109, krn: {'61': -0.0556, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>N</i>', ic: 0.109, krn: {'61': -0.0833, '61': -0.0278, '59': -=
0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>O</i>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'normal'},
     // 50 - 5F
-    {c: '<I>P</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>Q</I>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>R</I>', ic: 0.00773, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>S</I>', ic: 0.0576, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>T</I>', ic: 0.139, krn: {'61': -0.0278, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>U</I>', ic: 0.109, krn: {'59': -0.111, '58': -0.111, '61': -0.=
0556, '127': 0.0278}, tclass: 'normal'},
-    {c: '<I>V</I>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
-    {c: '<I>W</I>', ic: 0.139, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
-    {c: '<I>X</I>', ic: 0.0785, krn: {'61': -0.0833, '61': -0.0278, '59': =
-0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>Y</I>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
-    {c: '<I>Z</I>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>P</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>Q</i>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>R</i>', ic: 0.00773, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>S</i>', ic: 0.0576, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>T</i>', ic: 0.139, krn: {'61': -0.0278, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>U</i>', ic: 0.109, krn: {'59': -0.111, '58': -0.111, '61': -0.=
0556, '127': 0.0278}, tclass: 'normal'},
+    {c: '<i>V</i>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
+    {c: '<i>W</i>', ic: 0.139, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
+    {c: '<i>X</i>', ic: 0.0785, krn: {'61': -0.0833, '61': -0.0278, '59': =
-0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>Y</i>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
+    {c: '<i>Z</i>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
     {c: '&#x266D;', tclass: 'symbol'},
     {c: '&#x266E;', tclass: 'symbol'},
     {c: '&#x266F;', tclass: 'symbol'},
-    {c: '<SPAN STYLE="position: relative; top:-.3em; font-size:75%">&#x2=
03F;</SPAN>', a:0, d:-.1, tclass: 'arial'},
-    {c: '<SPAN STYLE="position: relative; top:.4em; font-size:75%">&#x20=
40;</SPAN>', a:0, d:-.1, tclass: 'arial'},
+    {c: '<span style="position: relative; top:-.3em; font-size:75%">&#x2=
03F;</span>', a:0, d:-.1, tclass: 'arial'},
+    {c: '<span style="position: relative; top:.4em; font-size:75%">&#x20=
40;</span>', a:0, d:-.1, tclass: 'arial'},
     // 60 - 6F
     {c: '&#x2113;', krn: {'127': 0.111}, tclass: 'normal'},
-    {c: '<I>a</I>', a:0, tclass: 'normal'},
-    {c: '<I>b</I>', tclass: 'normal'},
-    {c: '<I>c</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>d</I>', krn: {'89': 0.0556, '90': -0.0556, '106': -0.111, '102=
': -0.167, '127': 0.167}, tclass: 'normal'},
-    {c: '<I>e</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>f</I>', d:1, ic: 0.108, krn: {'59': -0.0556, '58': -0.0556, '1=
27': 0.167}, tclass: 'normal'},
-    {c: '<I>g</I>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'n=
ormal'},
-    {c: '<I>h</I>', krn: {'127': -0.0278}, tclass: 'normal'},
-    {c: '<I>i</I>', tclass: 'normal'},
-    {c: '<I>j</I>', d:1, ic: 0.0572, krn: {'59': -0.0556, '58': -0.0556}, =
tclass: 'normal'},
-    {c: '<I>k</I>', ic: 0.0315, tclass: 'normal'},
-    {c: '<I>l</I>', ic: 0.0197, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>m</I>', a:0, tclass: 'normal'},
-    {c: '<I>n</I>', a:0, tclass: 'normal'},
-    {c: '<I>o</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>a</i>', a:0, tclass: 'normal'},
+    {c: '<i>b</i>', tclass: 'normal'},
+    {c: '<i>c</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>d</i>', krn: {'89': 0.0556, '90': -0.0556, '106': -0.111, '102=
': -0.167, '127': 0.167}, tclass: 'normal'},
+    {c: '<i>e</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>f</i>', d:1, ic: 0.108, krn: {'59': -0.0556, '58': -0.0556, '1=
27': 0.167}, tclass: 'normal'},
+    {c: '<i>g</i>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'n=
ormal'},
+    {c: '<i>h</i>', krn: {'127': -0.0278}, tclass: 'normal'},
+    {c: '<i>i</i>', tclass: 'normal'},
+    {c: '<i>j</i>', d:1, ic: 0.0572, krn: {'59': -0.0556, '58': -0.0556}, =
tclass: 'normal'},
+    {c: '<i>k</i>', ic: 0.0315, tclass: 'normal'},
+    {c: '<i>l</i>', ic: 0.0197, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>m</i>', a:0, tclass: 'normal'},
+    {c: '<i>n</i>', a:0, tclass: 'normal'},
+    {c: '<i>o</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
     // 70 - 7F
-    {c: '<I>p</I>', a:0, d:1, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>q</I>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0833}, tclass: 'n=
ormal'},
-    {c: '<I>r</I>', a:0, ic: 0.0278, krn: {'59': -0.0556, '58': -0.0556, '=
127': 0.0556}, tclass: 'normal'},
-    {c: '<I>s</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>t</I>', krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>u</I>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>v</I>', a:0, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'normal=
'},
-    {c: '<I>w</I>', a:0, ic: 0.0269, krn: {'127': 0.0833}, tclass: 'normal=
'},
-    {c: '<I>x</I>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>y</I>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0556}, tclass: 'n=
ormal'},
-    {c: '<I>z</I>', a:0, ic: 0.044, krn: {'127': 0.0556}, tclass: 'normal'=
},
-    {c: '<I>&#x131;</I>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>j</I>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>p</i>', a:0, d:1, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>q</i>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0833}, tclass: 'n=
ormal'},
+    {c: '<i>r</i>', a:0, ic: 0.0278, krn: {'59': -0.0556, '58': -0.0556, '=
127': 0.0556}, tclass: 'normal'},
+    {c: '<i>s</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>t</i>', krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>u</i>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>v</i>', a:0, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'normal=
'},
+    {c: '<i>w</i>', a:0, ic: 0.0269, krn: {'127': 0.0833}, tclass: 'normal=
'},
+    {c: '<i>x</i>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>y</i>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0556}, tclass: 'n=
ormal'},
+    {c: '<i>z</i>', a:0, ic: 0.044, krn: {'127': 0.0556}, tclass: 'normal'=
},
+    {c: '<i>&#x131;</i>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>j</i>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
     {c: '&#x2118;', a:0, d:1, krn: {'127': 0.111}, tclass: 'arial'},
-    {c: '<SPAN STYLE="position:relative; left: .3em; top: -.65em; font-s=
ize: 67%">&#x2192;</SPAN>', ic: 0.154, tclass: 'symbol'},
+    {c: '<span style="position:relative; left: .3em; top: -.65em; font-s=
ize: 67%">&#x2192;</span>', ic: 0.154, tclass: 'symbol'},
     {c: '&#x0311;', ic: 0.399, tclass: 'normal'}
   ],

   cmsy10: [
     // 00 - 0F
-    {c: '<SPAN STYLE="position:relative; top:.1em">&#x2212;</SPAN>', a:.=
1, tclass: 'symbol'},
+    {c: '<span style="position:relative; top:.1em">&#x2212;</span>', a:.=
1, tclass: 'symbol'},
     {c: '&#xB7;', a:0, d:-.2, tclass: 'normal'},
     {c: '&#xD7;', a:0, tclass: 'normal'},
-    {c: '<SPAN STYLE="position:relative; top:.3em">&#x2A;</SPAN>', a:0, =
tclass: 'normal'},
+    {c: '<span style="position:relative; top:.3em">&#x2A;</span>', a:0, =
tclass: 'normal'},
     {c: '&#xF7;', a:0, tclass: 'normal'},
     {c: '&#x25CA;', tclass: 'symbol'},
     {c: '&#xB1;', a:.1, tclass: 'normal'},
@@ -367,14 +367,14 @@
     {c: '&#x2199;', a:.1, tclass: 'arrows'},
     {c: '&#x221D;', a:.1, tclass: 'normal'},
     // 30 - 3F
-    {c: '<SPAN STYLE="font-size: 133%; margin-right: -.1em; position: re=
lative; top:.4em">&#x2032;</SPAN>', a: 0, tclass: 'lucida'},
+    {c: '<span style="font-size: 133%; margin-right: -.1em; position: re=
lative; top:.4em">&#x2032;</span>', a: 0, tclass: 'lucida'},
     {c: '&#x221E;', a:.1, tclass: 'symbol'},
     {c: '&#x2208;', tclass: 'symbol'},
     {c: '&#x220B;', tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 150%; position:relative; top:.2em">&#x2=
5B3;</SPAN>', tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 150%; position:relative; top:.2em">&#x2=
5BD;</SPAN>', tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 133%; position:relative; top:.2em">/</S=
PAN>', d:1, tclass: 'normal'},
-    {c: '<SPAN STYLE="font-size: 67%; position: relative; top:-.15em; ma=
rgin-right:-.3em">&#x22A2;</SPAN>', tclass: 'symbol'},
+    {c: '<span style="font-size: 150%; position:relative; top:.2em">&#x2=
5B3;</span>', tclass: 'symbol'},
+    {c: '<span style="font-size: 150%; position:relative; top:.2em">&#x2=
5BD;</span>', tclass: 'symbol'},
+    {c: '<span style="font-size: 133%; position:relative; top:.2em">/</s=
pan>', d:1, tclass: 'normal'},
+    {c: '<span style="font-size: 67%; position: relative; top:-.15em; ma=
rgin-right:-.3em">&#x22A2;</span>', tclass: 'symbol'},
     {c: '&#x2200;', tclass: 'symbol'},
     {c: '&#x2203;', tclass: 'symbol'},
     {c: '&#xAC;', a:0, d:-.1, tclass: 'symbol'},
@@ -435,10 +435,10 @@
     {c: '&#x2216;', a:.3, d:.1, tclass: 'symbol'},
     {c: '&#x2240;', tclass: 'symbol'},
     // 70 - 7F
-    {c: '<SPAN STYLE="position:relative; top: .8em">&#x221A;</SPAN>', h:=
=2E04, d:.8, tclass: 'symbol'},
+    {c: '<span style="position:relative; top: .8em">&#x221A;</span>', h:=
=2E04, d:.8, tclass: 'symbol'},
     {c: '&#x2210;', a:.4, tclass: 'symbol'},
     {c: '&#x2207;', tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 85%; left:-.1em; margin-right:-.2em">&#=
x222B;</SPAN>', a:.4, d:.1, ic: 0.111, tclass: 'lucida'},
+    {c: '<span style="font-size: 85%; left:-.1em; margin-right:-.2em">&#=
x222B;</span>', a:.4, d:.1, ic: 0.111, tclass: 'lucida'},
     {c: '&#x2294;', tclass: 'symbol'},
     {c: '&#x2293;', tclass: 'symbol'},
     {c: '&#x2291;', tclass: 'symbol'},
@@ -463,8 +463,8 @@
     {c: '&#x2309;', h: 0.04, d: 1.16, n: 107, tclass: 'delim1a'},
     {c: '&#x230A;', h: 0.04, d: 1.16, n: 108, tclass: 'delim1a'},
     {c: '&#x230B;', h: 0.04, d: 1.16, n: 109, tclass: 'delim1a'},
-    {c: '<SPAN STYLE="margin-left:-.1em">{</SPAN>', h: 0.04, d: 1.16, n:=
 110, tclass: 'delim1'},
-    {c: '<SPAN STYLE="margin-right:-.1em">}</SPAN>', h: 0.04, d: 1.16, n=
: 111, tclass: 'delim1'},
+    {c: '<span style="margin-left:-.1em">{</span>', h: 0.04, d: 1.16, n:=
 110, tclass: 'delim1'},
+    {c: '<span style="margin-right:-.1em">}</span>', h: 0.04, d: 1.16, n=
: 111, tclass: 'delim1'},
     {c: '&#x2329;', h: 0.04, d: 1.16, n: 68, tclass: 'delim1b'},
     {c: '&#x232A;', h: 0.04, d: 1.16, n: 69, tclass: 'delim1b'},
     {c: '&#x2223;', h:.7, d:.1, delim: {rep: 12}, tclass: 'symbol'},
@@ -482,8 +482,8 @@
     {c: '&#x2309;', h: 0.04, d: 2.36, n: 37, tclass: 'delim3a'},
     {c: '&#x230A;', h: 0.04, d: 2.36, n: 38, tclass: 'delim3a'},
     {c: '&#x230B;', h: 0.04, d: 2.36, n: 39, tclass: 'delim3a'},
-    {c: '<SPAN STYLE="position:relative; left:-.1em; margin-right:-.1em"=
>{</SPAN>', h: 0.04, d: 2.36, n: 40, tclass: 'delim3'},
-    {c: '<SPAN STYLE="position:relative; left:-.05em; margin-right:-.1em=
">}</SPAN>', h: 0.04, d: 2.36, n: 41, tclass: 'delim3'},
+    {c: '<span style="position:relative; left:-.1em; margin-right:-.1em"=
>{</span>', h: 0.04, d: 2.36, n: 40, tclass: 'delim3'},
+    {c: '<span style="position:relative; left:-.05em; margin-right:-.1em=
">}</span>', h: 0.04, d: 2.36, n: 41, tclass: 'delim3'},
     {c: '&#x2329;', h: 0.04, d: 2.36, n: 42, tclass: 'delim3b'},
     {c: '&#x232A;', h: 0.04, d: 2.36, n: 43, tclass: 'delim3b'},
     {c: '/', h: 0.04, d: 2.36, n: 44, tclass: 'delim3a'},
@@ -497,8 +497,8 @@
     {c: '&#x2309;', h: 0.04, d: 2.96, n: 53, tclass: 'delim4a'},
     {c: '&#x230A;', h: 0.04, d: 2.96, n: 54, tclass: 'delim4a'},
     {c: '&#x230B;', h: 0.04, d: 2.96, n: 55, tclass: 'delim4a'},
-    {c: '<SPAN STYLE="position:relative; left:-.1em; margin-right:-.1em"=
>{</SPAN>', h: 0.04, d: 2.96, n: 56, tclass: 'delim4'},
-    {c: '<SPAN STYLE="position:relative; left:-.1em; margin-right:-.1em"=
>}</SPAN>', h: 0.04, d: 2.96, n: 57, tclass: 'delim4'},
+    {c: '<span style="position:relative; left:-.1em; margin-right:-.1em"=
>{</span>', h: 0.04, d: 2.96, n: 56, tclass: 'delim4'},
+    {c: '<span style="position:relative; left:-.1em; margin-right:-.1em"=
>}</span>', h: 0.04, d: 2.96, n: 57, tclass: 'delim4'},
     {c: '&#x2329;', h: 0.04, d: 2.96, tclass: 'delim4b'},
     {c: '&#x232A;', h: 0.04, d: 2.96, tclass: 'delim4b'},
     {c: '/', h: 0.04, d: 2.96, tclass: 'delim4a'},
@@ -521,7 +521,7 @@
     {c: '&#xED;', h: .8, d: .2, delim: {rep: 63}, tclass: 'delimx'},
     {c: '&#xFD;', h: .8, d: .2, delim: {rep: 119}, tclass: 'delimx'},
     {c: '&#xEF;', h: .8, d: .2, delim: {rep: 62}, tclass: 'delimx'},
-    {c: '<SPAN STYLE="margin:.125em">|</SPAN>', h: .8, d: 0, delim: {top=
: 120, bot: 121, rep: 63}, tclass: 'normal'},
+    {c: '<span style="margin:.125em">|</span>', h: .8, d: 0, delim: {top=
: 120, bot: 121, rep: 63}, tclass: 'normal'},
     // 40 - 4F
     {c: '&#xE8;', h: .8, d: .2, delim: {top: 56, bot: 59, rep: 62}, tclass=
: 'delimx'},
     {c: '&#xF8;', h: .8, d: .2, delim: {top: 57, bot: 58, rep: 62}, tclass=
: 'delimx'},
@@ -571,303 +571,303 @@
     {c: '&#x2309;', h: 0.04, d: 1.76, n: 23, tclass: 'delim2a'},
     {c: '&#x230A;', h: 0.04, d: 1.76, n: 24, tclass: 'delim2a'},
     {c: '&#x230B;', h: 0.04, d: 1.76, n: 25, tclass: 'delim2a'},
-    {c: '<SPAN STYLE="position:relative; left:-.1em; margin-right:-.1em"=
>{</SPAN>', h: 0.04, d: 1.76, n: 26, tclass: 'delim2'},
-    {c: '<SPAN STYLE="position:relative; margin-right:-.1em; left:-.05em=
">}</SPAN>', h: 0.04, d: 1.76, n: 27, tclass: 'delim2'},
+    {c: '<span style="position:relative; left:-.1em; margin-right:-.1em"=
>{</span>', h: 0.04, d: 1.76, n: 26, tclass: 'delim2'},
+    {c: '<span style="position:relative; margin-right:-.1em; left:-.05em=
">}</span>', h: 0.04, d: 1.76, n: 27, tclass: 'delim2'},
     // 70 - 7F
-    {c: '<SPAN STYLE="font-size: 150%; position:relative; top:.8em">&#x2=
21A;</SPAN>', h: 0.04, d: 1.16, n: 113, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 220%; position:relative; top:.8em">&#x2=
21A;</SPAN>', h: 0.04, d: 1.76, n: 114, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 310%; position:relative; top:.8em; marg=
in-right:-.01em">&#x221A;</SPAN>', h: 0.06, d: 2.36, n: 115, tclass: 'root'=
},
-    {c: '<SPAN STYLE="font-size: 400%; position:relative; top:.8em; marg=
in-right:-.025em">&#x221A;</SPAN>', h: 0.08, d: 2.96, n: 116, tclass: 'root=
'},
-    {c: '<SPAN STYLE="font-size: 490%; position:relative; top:.8em; marg=
in-right:-.03em">&#x221A;</SPAN>', h: 0.1, d: 3.75, n: 117, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 580%; position:relative; top:.775em; ma=
rgin-right:-.04em">&#x221A;</SPAN>', h: .12, d: 4.5, n: 118, tclass: 'root'=
},
-    {c: '<SPAN STYLE="font-size: 750%; position:relative; top:.775em;mar=
gin-right:-.04em">&#x221A;</SPAN>', h: .14, d: 5.7, tclass: 'root'},
-    {c: '<SPAN STYLE="margin-left:.02em">|</SPAN><SPAN STYLE="margin-l=
eft:.08em; margin-right:.125em">|</SPAN>', h:.8, d:0, delim: {top: 126, bot=
: 127, rep: 119}, tclass: 'normal'},
+    {c: '<span style="font-size: 150%; position:relative; top:.8em">&#x2=
21A;</span>', h: 0.04, d: 1.16, n: 113, tclass: 'root'},
+    {c: '<span style="font-size: 220%; position:relative; top:.8em">&#x2=
21A;</span>', h: 0.04, d: 1.76, n: 114, tclass: 'root'},
+    {c: '<span style="font-size: 310%; position:relative; top:.8em; marg=
in-right:-.01em">&#x221A;</span>', h: 0.06, d: 2.36, n: 115, tclass: 'root'=
},
+    {c: '<span style="font-size: 400%; position:relative; top:.8em; marg=
in-right:-.025em">&#x221A;</span>', h: 0.08, d: 2.96, n: 116, tclass: 'root=
'},
+    {c: '<span style="font-size: 490%; position:relative; top:.8em; marg=
in-right:-.03em">&#x221A;</span>', h: 0.1, d: 3.75, n: 117, tclass: 'root'},
+    {c: '<span style="font-size: 580%; position:relative; top:.775em; ma=
rgin-right:-.04em">&#x221A;</span>', h: .12, d: 4.5, n: 118, tclass: 'root'=
},
+    {c: '<span style="font-size: 750%; position:relative; top:.775em;mar=
gin-right:-.04em">&#x221A;</span>', h: .14, d: 5.7, tclass: 'root'},
+    {c: '<span style="margin-left:.02em">|</span><span style="margin-l=
eft:.08em; margin-right:.125em">|</span>', h:.8, d:0, delim: {top: 126, bot=
: 127, rep: 119}, tclass: 'normal'},
     {c: '&#x2191;', h:.7, d:0, delim: {top: 120, rep: 63}, tclass: 'arrow1=
a'},
     {c: '&#x2193;', h:.65, d:0, delim: {bot: 121, rep: 63}, tclass: 'arrow=
1a'},
-    {c: '<SPAN STYLE="margin-left:-.1em"></SPAN><SPAN STYLE="position:=
relative; top:.55em; margin-right:-.3em">&#x25DC;</SPAN>', h: 0.05, tclass:=
 'symbol'},
-    {c: '<SPAN STYLE="margin-left:-.3em"></SPAN><SPAN STYLE="position:=
relative; top:.55em; margin-right:-.1em">&#x25DD;</SPAN>', h: 0.05, tclass:=
 'symbol'},
-    {c: '<SPAN STYLE="margin-left:-.1em"></SPAN><SPAN STYLE="position:=
relative; top:.15em; margin-right:-.3em">&#x25DF;</SPAN>', h: 0.05, tclass:=
 'symbol'},
-    {c: '<SPAN STYLE="margin-left:-.3em"></SPAN><SPAN STYLE="position:=
relative; top:.15em; margin-right:-.1em">&#x25DE;</SPAN>', h: 0.05, tclass:=
 'symbol'},
+    {c: '<span style="margin-left:-.1em"></span><span style="position:=
relative; top:.55em; margin-right:-.3em">&#x25DC;</span>', h: 0.05, tclass:=
 'symbol'},
+    {c: '<span style="margin-left:-.3em"></span><span style="position:=
relative; top:.55em; margin-right:-.1em">&#x25DD;</span>', h: 0.05, tclass:=
 'symbol'},
+    {c: '<span style="margin-left:-.1em"></span><span style="position:=
relative; top:.15em; margin-right:-.3em">&#x25DF;</span>', h: 0.05, tclass:=
 'symbol'},
+    {c: '<span style="margin-left:-.3em"></span><span style="position:=
relative; top:.15em; margin-right:-.1em">&#x25DE;</span>', h: 0.05, tclass:=
 'symbol'},
     {c: '&#x21D1;', h: .7, d:0, delim: {top: 126, rep: 119}, tclass: 'arro=
w1a'},
     {c: '&#x21D3;', h: .7, d:0, delim: {bot: 127, rep: 119}, tclass: 'arro=
w1a'}
   ],
  
   cmti10: [
     // 00 - 0F
-    {c: '<I>&Gamma;</I>', ic: 0.133, tclass: 'greek'},
-    {c: '<I>&Delta;</I>', tclass: 'greek'},
-    {c: '<I>&Theta;</I>', ic: 0.094, tclass: 'greek'},
-    {c: '<I>&Lambda;</I>', tclass: 'greek'},
-    {c: '<I>&Xi;</I>', ic: 0.153, tclass: 'greek'},
-    {c: '<I>&Pi;</I>', ic: 0.164, tclass: 'greek'},
-    {c: '<I>&Sigma;</I>', ic: 0.12, tclass: 'greek'},
-    {c: '<I>&Upsilon;</I>', ic: 0.111, tclass: 'greek'},
-    {c: '<I>&Phi;</I>', ic: 0.0599, tclass: 'greek'},
-    {c: '<I>&Psi;</I>', ic: 0.111, tclass: 'greek'},
-    {c: '<I>&Omega;</I>', ic: 0.103, tclass: 'greek'},
-    {c: '<I>ff</I>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.10=
4, '41': 0.104, '93': 0.104}, lig: {'105': 14, '108': 15}, tclass: 'normal'=
},
-    {c: '<I>fi</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>fl</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>ffi</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>ffl</I>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>&Gamma;</i>', ic: 0.133, tclass: 'greek'},
+    {c: '<i>&Delta;</i>', tclass: 'greek'},
+    {c: '<i>&Theta;</i>', ic: 0.094, tclass: 'greek'},
+    {c: '<i>&Lambda;</i>', tclass: 'greek'},
+    {c: '<i>&Xi;</i>', ic: 0.153, tclass: 'greek'},
+    {c: '<i>&Pi;</i>', ic: 0.164, tclass: 'greek'},
+    {c: '<i>&Sigma;</i>', ic: 0.12, tclass: 'greek'},
+    {c: '<i>&Upsilon;</i>', ic: 0.111, tclass: 'greek'},
+    {c: '<i>&Phi;</i>', ic: 0.0599, tclass: 'greek'},
+    {c: '<i>&Psi;</i>', ic: 0.111, tclass: 'greek'},
+    {c: '<i>&Omega;</i>', ic: 0.103, tclass: 'greek'},
+    {c: '<i>ff</i>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.10=
4, '41': 0.104, '93': 0.104}, lig: {'105': 14, '108': 15}, tclass: 'normal'=
},
+    {c: '<i>fi</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>fl</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>ffi</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>ffl</i>', ic: 0.103, tclass: 'normal'},
     // 10 - 1F
-    {c: '<I>&#x131;</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>j</I>', d:.2, ic: 0.0374, tclass: 'normal'},
-    {c: '<I>&#x2CB;</I>', tclass: 'accent'},
-    {c: '<I>&#x2CA;</I>', ic: 0.0969, tclass: 'accent'},
-    {c: '<I>&#x2C7;</I>', ic: 0.083, tclass: 'accent'},
-    {c: '<I>&#x2D8;</I>', ic: 0.108, tclass: 'accent'},
-    {c: '<I>&#x2C9;</I>', ic: 0.103, tclass: 'accent'},
-    {c: '<I>&#x2DA;</I>', tclass: 'accent'},
-    {c: '<I>?</I>', d: 0.17, w: 0.46, tclass: 'normal'},
-    {c: '<I>&#xDF;</I>', ic: 0.105, tclass: 'normal'},
-    {c: '<I>&#xE6;</I>', a:0, ic: 0.0751, tclass: 'normal'},
-    {c: '<I>&#x153;</I>', a:0, ic: 0.0751, tclass: 'normal'},
-    {c: '<I>&#xF8;</I>', ic: 0.0919, tclass: 'normal'},
-    {c: '<I>&#xC6;</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>&#x152;</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>&#xD8;</I>', ic: 0.094, tclass: 'normal'},
+    {c: '<i>&#x131;</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>j</i>', d:.2, ic: 0.0374, tclass: 'normal'},
+    {c: '<i>&#x2CB;</i>', tclass: 'accent'},
+    {c: '<i>&#x2CA;</i>', ic: 0.0969, tclass: 'accent'},
+    {c: '<i>&#x2C7;</i>', ic: 0.083, tclass: 'accent'},
+    {c: '<i>&#x2D8;</i>', ic: 0.108, tclass: 'accent'},
+    {c: '<i>&#x2C9;</i>', ic: 0.103, tclass: 'accent'},
+    {c: '<i>&#x2DA;</i>', tclass: 'accent'},
+    {c: '<i>?</i>', d: 0.17, w: 0.46, tclass: 'normal'},
+    {c: '<i>&#xDF;</i>', ic: 0.105, tclass: 'normal'},
+    {c: '<i>&#xE6;</i>', a:0, ic: 0.0751, tclass: 'normal'},
+    {c: '<i>&#x153;</i>', a:0, ic: 0.0751, tclass: 'normal'},
+    {c: '<i>&#xF8;</i>', ic: 0.0919, tclass: 'normal'},
+    {c: '<i>&#xC6;</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>&#x152;</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>&#xD8;</i>', ic: 0.094, tclass: 'normal'},
     // 20 - 2F
-    {c: '<I>?</I>', krn: {'108': -0.256, '76': -0.321}, tclass: 'normal'},
-    {c: '<I>!</I>', ic: 0.124, lig: {'96': 60}, tclass: 'normal'},
-    {c: '<I>&#x201D;</I>', ic: 0.0696, tclass: 'normal'},
-    {c: '<I>#</I>', ic: 0.0662, tclass: 'normal'},
-    {c: '<I>$</I>', tclass: 'normal'},
-    {c: '<I>%</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>&amp;</I>', ic: 0.0969, tclass: 'normal'},
-    {c: '<I>&#x2019;</I>', ic: 0.124, krn: {'63': 0.102, '33': 0.102}, lig=
: {'39': 34}, tclass: 'normal'},
-    {c: '<I>(</I>', d:.2, ic: 0.162, tclass: 'normal'},
-    {c: '<I>)</I>', d:.2, ic: 0.0369, tclass: 'normal'},
-    {c: '<I>*</I>', ic: 0.149, tclass: 'normal'},
-    {c: '<I>+</I>', a:.1, ic: 0.0369, tclass: 'normal'},
-    {c: '<I>,</I>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
-    {c: '<I>-</I>', a:0, ic: 0.0283, lig: {'45': 123}, tclass: 'normal'},
-    {c: '<I>.</I>', a:-.25, tclass: 'normal'},
-    {c: '<I>/</I>', ic: 0.162, tclass: 'normal'},
+    {c: '<i>?</i>', krn: {'108': -0.256, '76': -0.321}, tclass: 'normal'},
+    {c: '<i>!</i>', ic: 0.124, lig: {'96': 60}, tclass: 'normal'},
+    {c: '<i>&#x201D;</i>', ic: 0.0696, tclass: 'normal'},
+    {c: '<i>#</i>', ic: 0.0662, tclass: 'normal'},
+    {c: '<i>$</i>', tclass: 'normal'},
+    {c: '<i>%</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>&amp;</i>', ic: 0.0969, tclass: 'normal'},
+    {c: '<i>&#x2019;</i>', ic: 0.124, krn: {'63': 0.102, '33': 0.102}, lig=
: {'39': 34}, tclass: 'normal'},
+    {c: '<i>(</i>', d:.2, ic: 0.162, tclass: 'normal'},
+    {c: '<i>)</i>', d:.2, ic: 0.0369, tclass: 'normal'},
+    {c: '<i>*</i>', ic: 0.149, tclass: 'normal'},
+    {c: '<i>+</i>', a:.1, ic: 0.0369, tclass: 'normal'},
+    {c: '<i>,</i>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
+    {c: '<i>-</i>', a:0, ic: 0.0283, lig: {'45': 123}, tclass: 'normal'},
+    {c: '<i>.</i>', a:-.25, tclass: 'normal'},
+    {c: '<i>/</i>', ic: 0.162, tclass: 'normal'},
     // 30 - 3F
-    {c: '<I>0</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>1</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>2</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>3</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>4</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>5</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>6</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>7</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>8</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>9</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>:</I>', ic: 0.0582, tclass: 'normal'},
-    {c: '<I>;</I>', ic: 0.0582, tclass: 'normal'},
-    {c: '<I>&#xA1;</I>', ic: 0.0756, tclass: 'normal'},
-    {c: '<I>=</I>', a:0, d:-.1, ic: 0.0662, tclass: 'normal'},
-    {c: '<I>&#xBF;</I>', tclass: 'normal'},
-    {c: '<I>?</I>', ic: 0.122, lig: {'96': 62}, tclass: 'normal'},
+    {c: '<i>0</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>1</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>2</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>3</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>4</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>5</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>6</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>7</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>8</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>9</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>:</i>', ic: 0.0582, tclass: 'normal'},
+    {c: '<i>;</i>', ic: 0.0582, tclass: 'normal'},
+    {c: '<i>&#xA1;</i>', ic: 0.0756, tclass: 'normal'},
+    {c: '<i>=</i>', a:0, d:-.1, ic: 0.0662, tclass: 'normal'},
+    {c: '<i>&#xBF;</i>', tclass: 'normal'},
+    {c: '<i>?</i>', ic: 0.122, lig: {'96': 62}, tclass: 'normal'},
     // 40 - 4F
-    {c: '<I>@</I>', ic: 0.096, tclass: 'normal'},
-    {c: '<I>A</I>', krn: {'110': -0.0256, '108': -0.0256, '114': -0.0256, =
'117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256, '67': -0.02=
56, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256, '85': -0.0=
256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0256, '84': -=
0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.0511, '97': -0=
=2E0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '11=
3': -0.0511}, tclass: 'normal'},
-    {c: '<I>B</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>C</I>', ic: 0.145, tclass: 'normal'},
-    {c: '<I>D</I>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
-    {c: '<I>E</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>F</I>', ic: 0.133, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>G</I>', ic: 0.0872, tclass: 'normal'},
-    {c: '<I>H</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>I</I>', ic: 0.158, tclass: 'normal'},
-    {c: '<I>J</I>', ic: 0.14, tclass: 'normal'},
-    {c: '<I>K</I>', ic: 0.145, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>L</I>', krn: {'84': -0.0767, '89': -0.0767, '86': -0.102, '87'=
: -0.102, '101': -0.0511, '97': -0.0511, '111': -0.0511, '100': -0.0511, '9=
9': -0.0511, '103': -0.0511, '113': -0.0511}, tclass: 'normal'},
-    {c: '<I>M</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>N</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>O</I>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
+    {c: '<i>@</i>', ic: 0.096, tclass: 'normal'},
+    {c: '<i>A</i>', krn: {'110': -0.0256, '108': -0.0256, '114': -0.0256, =
'117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256, '67': -0.02=
56, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256, '85': -0.0=
256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0256, '84': -=
0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.0511, '97': -0=
=2E0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '11=
3': -0.0511}, tclass: 'normal'},
+    {c: '<i>B</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>C</i>', ic: 0.145, tclass: 'normal'},
+    {c: '<i>D</i>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
+    {c: '<i>E</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>F</i>', ic: 0.133, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>G</i>', ic: 0.0872, tclass: 'normal'},
+    {c: '<i>H</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>I</i>', ic: 0.158, tclass: 'normal'},
+    {c: '<i>J</i>', ic: 0.14, tclass: 'normal'},
+    {c: '<i>K</i>', ic: 0.145, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>L</i>', krn: {'84': -0.0767, '89': -0.0767, '86': -0.102, '87'=
: -0.102, '101': -0.0511, '97': -0.0511, '111': -0.0511, '100': -0.0511, '9=
9': -0.0511, '103': -0.0511, '113': -0.0511}, tclass: 'normal'},
+    {c: '<i>M</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>N</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>O</i>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
     // 50 - 5F
-    {c: '<I>P</I>', ic: 0.103, krn: {'65': -0.0767}, tclass: 'normal'},
-    {c: '<I>Q</I>', d: 1, ic: 0.094, tclass: 'normal'},
-    {c: '<I>R</I>', ic: 0.0387, krn: {'110': -0.0256, '108': -0.0256, '114=
': -0.0256, '117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256,=
 '67': -0.0256, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256=
, '85': -0.0256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0=
256, '84': -0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.05=
11, '97': -0.0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0=
=2E0511, '113': -0.0511}, tclass: 'normal'},
-    {c: '<I>S</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>T</I>', ic: 0.133, krn: {'121': -0.0767, '101': -0.0767, '111'=
: -0.0767, '114': -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, t=
class: 'normal'},
-    {c: '<I>U</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>V</I>', ic: 0.184, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>W</I>', ic: 0.184, krn: {'65': -0.0767}, tclass: 'normal'},
-    {c: '<I>X</I>', ic: 0.158, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>Y</I>', ic: 0.194, krn: {'101': -0.0767, '111': -0.0767, '114'=
: -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, tclass: 'normal'},
-    {c: '<I>Z</I>', ic: 0.145, tclass: 'normal'},
-    {c: '<I>[</I>', d:.1, ic: 0.188, tclass: 'normal'},
-    {c: '<I>&#x201C;</I>', ic: 0.169, tclass: 'normal'},
-    {c: '<I>]</I>', d:.1, ic: 0.105, tclass: 'normal'},
-    {c: '<I>&#x2C6;</I>', ic: 0.0665, tclass: 'accent'},
-    {c: '<I>&#x2D9;</I>', ic: 0.118, tclass: 'accent'},
+    {c: '<i>P</i>', ic: 0.103, krn: {'65': -0.0767}, tclass: 'normal'},
+    {c: '<i>Q</i>', d: 1, ic: 0.094, tclass: 'normal'},
+    {c: '<i>R</i>', ic: 0.0387, krn: {'110': -0.0256, '108': -0.0256, '114=
': -0.0256, '117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256,=
 '67': -0.0256, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256=
, '85': -0.0256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0=
256, '84': -0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.05=
11, '97': -0.0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0=
=2E0511, '113': -0.0511}, tclass: 'normal'},
+    {c: '<i>S</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>T</i>', ic: 0.133, krn: {'121': -0.0767, '101': -0.0767, '111'=
: -0.0767, '114': -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, t=
class: 'normal'},
+    {c: '<i>U</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>V</i>', ic: 0.184, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>W</i>', ic: 0.184, krn: {'65': -0.0767}, tclass: 'normal'},
+    {c: '<i>X</i>', ic: 0.158, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>Y</i>', ic: 0.194, krn: {'101': -0.0767, '111': -0.0767, '114'=
: -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, tclass: 'normal'},
+    {c: '<i>Z</i>', ic: 0.145, tclass: 'normal'},
+    {c: '<i>[</i>', d:.1, ic: 0.188, tclass: 'normal'},
+    {c: '<i>&#x201C;</i>', ic: 0.169, tclass: 'normal'},
+    {c: '<i>]</i>', d:.1, ic: 0.105, tclass: 'normal'},
+    {c: '<i>&#x2C6;</i>', ic: 0.0665, tclass: 'accent'},
+    {c: '<i>&#x2D9;</i>', ic: 0.118, tclass: 'accent'},
     // 60 - 6F
-    {c: '<I>&#x2018;</I>', ic: 0.124, lig: {'96': 92}, tclass: 'normal'},
-    {c: '<I>a</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>b</I>', ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, '111'=
: -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.0511}, =
tclass: 'normal'},
-    {c: '<I>c</I>', a:0, ic: 0.0565, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
-    {c: '<I>d</I>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
-    {c: '<I>e</I>', a:0, ic: 0.0751, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
-    {c: '<I>f</I>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.104=
, '41': 0.104, '93': 0.104}, lig: {'105': 12, '102': 11, '108': 13}, tclass=
: 'normal'},
-    {c: '<I>g</I>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
-    {c: '<I>h</I>', ic: 0.0767, tclass: 'normal'},
-    {c: '<I>i</I>', ic: 0.102, tclass: 'normal'},
-    {c: '<I>j</I>', d:1, ic: 0.145, tclass: 'normal'},
-    {c: '<I>k</I>', ic: 0.108, tclass: 'normal'},
-    {c: '<I>l</I>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
-    {c: '<I>m</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>n</I>', a:0, ic: 0.0767, krn: {'39': -0.102}, tclass: 'normal'=
},
-    {c: '<I>o</I>', a:0, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
+    {c: '<i>&#x2018;</i>', ic: 0.124, lig: {'96': 92}, tclass: 'normal'},
+    {c: '<i>a</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>b</i>', ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, '111'=
: -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.0511}, =
tclass: 'normal'},
+    {c: '<i>c</i>', a:0, ic: 0.0565, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
+    {c: '<i>d</i>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
+    {c: '<i>e</i>', a:0, ic: 0.0751, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
+    {c: '<i>f</i>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.104=
, '41': 0.104, '93': 0.104}, lig: {'105': 12, '102': 11, '108': 13}, tclass=
: 'normal'},
+    {c: '<i>g</i>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
+    {c: '<i>h</i>', ic: 0.0767, tclass: 'normal'},
+    {c: '<i>i</i>', ic: 0.102, tclass: 'normal'},
+    {c: '<i>j</i>', d:1, ic: 0.145, tclass: 'normal'},
+    {c: '<i>k</i>', ic: 0.108, tclass: 'normal'},
+    {c: '<i>l</i>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
+    {c: '<i>m</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>n</i>', a:0, ic: 0.0767, krn: {'39': -0.102}, tclass: 'normal'=
},
+    {c: '<i>o</i>', a:0, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
     // 70 - 7F
-    {c: '<I>p</I>', a:0, d:1, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0=
511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': =
-0.0511}, tclass: 'normal'},
-    {c: '<I>q</I>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
-    {c: '<I>r</I>', a:0, ic: 0.108, krn: {'101': -0.0511, '97': -0.0511, '=
111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.051=
1}, tclass: 'normal'},
-    {c: '<I>s</I>', a:0, ic: 0.0821, tclass: 'normal'},
-    {c: '<I>t</I>', ic: 0.0949, tclass: 'normal'},
-    {c: '<I>u</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>v</I>', a:0, ic: 0.108, tclass: 'normal'},
-    {c: '<I>w</I>', a:0, ic: 0.108, krn: {'108': 0.0511}, tclass: 'normal'=
},
-    {c: '<I>x</I>', a:0, ic: 0.12, tclass: 'normal'},
-    {c: '<I>y</I>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
-    {c: '<I>z</I>', a:0, ic: 0.123, tclass: 'normal'},
-    {c: '<I>&#x2013;</I>', a:.1, ic: 0.0921, lig: {'45': 124}, tclass: 'no=
rmal'},
-    {c: '<I>&#x2014;</I>', a:.1, ic: 0.0921, tclass: 'normal'},
-    {c: '<I>&#x2DD;</I>', ic: 0.122, tclass: 'accent'},
-    {c: '<I>&#x2DC;</I>', ic: 0.116, tclass: 'accent'},
-    {c: '<I>&#xA8;</I>', tclass: 'accent'}
+    {c: '<i>p</i>', a:0, d:1, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0=
511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': =
-0.0511}, tclass: 'normal'},
+    {c: '<i>q</i>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
+    {c: '<i>r</i>', a:0, ic: 0.108, krn: {'101': -0.0511, '97': -0.0511, '=
111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.051=
1}, tclass: 'normal'},
+    {c: '<i>s</i>', a:0, ic: 0.0821, tclass: 'normal'},
+    {c: '<i>t</i>', ic: 0.0949, tclass: 'normal'},
+    {c: '<i>u</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>v</i>', a:0, ic: 0.108, tclass: 'normal'},
+    {c: '<i>w</i>', a:0, ic: 0.108, krn: {'108': 0.0511}, tclass: 'normal'=
},
+    {c: '<i>x</i>', a:0, ic: 0.12, tclass: 'normal'},
+    {c: '<i>y</i>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
+    {c: '<i>z</i>', a:0, ic: 0.123, tclass: 'normal'},
+    {c: '<i>&#x2013;</i>', a:.1, ic: 0.0921, lig: {'45': 124}, tclass: 'no=
rmal'},
+    {c: '<i>&#x2014;</i>', a:.1, ic: 0.0921, tclass: 'normal'},
+    {c: '<i>&#x2DD;</i>', ic: 0.122, tclass: 'accent'},
+    {c: '<i>&#x2DC;</i>', ic: 0.116, tclass: 'accent'},
+    {c: '<i>&#xA8;</i>', tclass: 'accent'}
   ],
  
   cmbx10: [
     // 00 - 0F
-    {c: '<B>&Gamma;</B>', tclass: 'greek'},
-    {c: '<B>&Delta;</B>', tclass: 'greek'},
-    {c: '<B>&Theta;</B>', tclass: 'greek'},
-    {c: '<B>&Lambda;</B>', tclass: 'greek'},
-    {c: '<B>&Xi;</B>', tclass: 'greek'},
-    {c: '<B>&Pi;</B>', tclass: 'greek'},
-    {c: '<B>&Sigma;</B>', tclass: 'greek'},
-    {c: '<B>&Upsilon;</B>', tclass: 'greek'},
-    {c: '<B>&Phi;</B>', tclass: 'greek'},
-    {c: '<B>&Psi;</B>', tclass: 'greek'},
-    {c: '<B>&Omega;</B>', tclass: 'greek'},
-    {c: '<B>ff</B>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0=
=2E0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 14, '108': 15}, tclass: =
'normal'},
-    {c: '<B>fi</B>', tclass: 'normal'},
-    {c: '<B>fl</B>', tclass: 'normal'},
-    {c: '<B>ffi</B>', tclass: 'normal'},
-    {c: '<B>ffl</B>', tclass: 'normal'},
+    {c: '<b>&Gamma;</b>', tclass: 'greek'},
+    {c: '<b>&Delta;</b>', tclass: 'greek'},
+    {c: '<b>&Theta;</b>', tclass: 'greek'},
+    {c: '<b>&Lambda;</b>', tclass: 'greek'},
+    {c: '<b>&Xi;</b>', tclass: 'greek'},
+    {c: '<b>&Pi;</b>', tclass: 'greek'},
+    {c: '<b>&Sigma;</b>', tclass: 'greek'},
+    {c: '<b>&Upsilon;</b>', tclass: 'greek'},
+    {c: '<b>&Phi;</b>', tclass: 'greek'},
+    {c: '<b>&Psi;</b>', tclass: 'greek'},
+    {c: '<b>&Omega;</b>', tclass: 'greek'},
+    {c: '<b>ff</b>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0=
=2E0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 14, '108': 15}, tclass: =
'normal'},
+    {c: '<b>fi</b>', tclass: 'normal'},
+    {c: '<b>fl</b>', tclass: 'normal'},
+    {c: '<b>ffi</b>', tclass: 'normal'},
+    {c: '<b>ffl</b>', tclass: 'normal'},
     // 10 - 1F
-    {c: '<B>&#x131;</B>', a:0, tclass: 'normal'},
-    {c: '<B>j</B>', d:.2, tclass: 'normal'},
-    {c: '<B>&#x2CB;</B>', tclass: 'accent'},
-    {c: '<B>&#x2CA;</B>', tclass: 'accent'},
-    {c: '<B>&#x2C7;</B>', tclass: 'accent'},
-    {c: '<B>&#x2D8;</B>', tclass: 'accent'},
-    {c: '<B>&#x2C9;</B>', tclass: 'accent'},
-    {c: '<B>&#x2DA;</B>', tclass: 'accent'},
-    {c: '<B>?</B>', tclass: 'normal'},
-    {c: '<B>&#xDF;</B>', tclass: 'normal'},
-    {c: '<B>&#xE6;</B>', a:0, tclass: 'normal'},
-    {c: '<B>&#x153;</B>', a:0, tclass: 'normal'},
-    {c: '<B>&#xF8;</B>', tclass: 'normal'},
-    {c: '<B>&#xC6;</B>', tclass: 'normal'},
-    {c: '<B>&#x152;</B>', tclass: 'normal'},
-    {c: '<B>&#xD8;</B>', tclass: 'normal'},
+    {c: '<b>&#x131;</b>', a:0, tclass: 'normal'},
+    {c: '<b>j</b>', d:.2, tclass: 'normal'},
+    {c: '<b>&#x2CB;</b>', tclass: 'accent'},
+    {c: '<b>&#x2CA;</b>', tclass: 'accent'},
+    {c: '<b>&#x2C7;</b>', tclass: 'accent'},
+    {c: '<b>&#x2D8;</b>', tclass: 'accent'},
+    {c: '<b>&#x2C9;</b>', tclass: 'accent'},
+    {c: '<b>&#x2DA;</b>', tclass: 'accent'},
+    {c: '<b>?</b>', tclass: 'normal'},
+    {c: '<b>&#xDF;</b>', tclass: 'normal'},
+    {c: '<b>&#xE6;</b>', a:0, tclass: 'normal'},
+    {c: '<b>&#x153;</b>', a:0, tclass: 'normal'},
+    {c: '<b>&#xF8;</b>', tclass: 'normal'},
+    {c: '<b>&#xC6;</b>', tclass: 'normal'},
+    {c: '<b>&#x152;</b>', tclass: 'normal'},
+    {c: '<b>&#xD8;</b>', tclass: 'normal'},
     // 20 - 2F
-    {c: '<B>?</B>', krn: {'108': -0.278, '76': -0.319}, tclass: 'normal'},
-    {c: '<B>!</B>', lig: {'96': 60}, tclass: 'normal'},
-    {c: '<B>&#x201D;</B>', tclass: 'normal'},
-    {c: '<B>#</B>', tclass: 'normal'},
-    {c: '<B>$</B>', tclass: 'normal'},
-    {c: '<B>%</B>', tclass: 'normal'},
-    {c: '<B>&amp;</B>', tclass: 'normal'},
-    {c: '<B>&#x2019;</B>', krn: {'63': 0.111, '33': 0.111}, lig: {'39': 34=
}, tclass: 'normal'},
-    {c: '<B>(</B>', d:.2, tclass: 'normal'},
-    {c: '<B>)</B>', d:.2, tclass: 'normal'},
-    {c: '<B>*</B>', tclass: 'normal'},
-    {c: '<B>+</B>', a:.1, tclass: 'normal'},
-    {c: '<B>,</B>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
-    {c: '<B>-</B>', a:0, lig: {'45': 123}, tclass: 'normal'},
-    {c: '<B>.</B>', a:-.25, tclass: 'normal'},
-    {c: '<B>/</B>', tclass: 'normal'},
+    {c: '<b>?</b>', krn: {'108': -0.278, '76': -0.319}, tclass: 'normal'},
+    {c: '<b>!</b>', lig: {'96': 60}, tclass: 'normal'},
+    {c: '<b>&#x201D;</b>', tclass: 'normal'},
+    {c: '<b>#</b>', tclass: 'normal'},
+    {c: '<b>$</b>', tclass: 'normal'},
+    {c: '<b>%</b>', tclass: 'normal'},
+    {c: '<b>&amp;</b>', tclass: 'normal'},
+    {c: '<b>&#x2019;</b>', krn: {'63': 0.111, '33': 0.111}, lig: {'39': 34=
}, tclass: 'normal'},
+    {c: '<b>(</b>', d:.2, tclass: 'normal'},
+    {c: '<b>)</b>', d:.2, tclass: 'normal'},
+    {c: '<b>*</b>', tclass: 'normal'},
+    {c: '<b>+</b>', a:.1, tclass: 'normal'},
+    {c: '<b>,</b>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
+    {c: '<b>-</b>', a:0, lig: {'45': 123}, tclass: 'normal'},
+    {c: '<b>.</b>', a:-.25, tclass: 'normal'},
+    {c: '<b>/</b>', tclass: 'normal'},
     // 30 - 3F
-    {c: '<B>0</B>', tclass: 'normal'},
-    {c: '<B>1</B>', tclass: 'normal'},
-    {c: '<B>2</B>', tclass: 'normal'},
-    {c: '<B>3</B>', tclass: 'normal'},
-    {c: '<B>4</B>', tclass: 'normal'},
-    {c: '<B>5</B>', tclass: 'normal'},
-    {c: '<B>6</B>', tclass: 'normal'},
-    {c: '<B>7</B>', tclass: 'normal'},
-    {c: '<B>8</B>', tclass: 'normal'},
-    {c: '<B>9</B>', tclass: 'normal'},
-    {c: '<B>:</B>', tclass: 'normal'},
-    {c: '<B>;</B>', tclass: 'normal'},
-    {c: '<B>&#xA1;</B>', tclass: 'normal'},
-    {c: '<B>=</B>', a:0, d:-.1, tclass: 'normal'},
-    {c: '<B>&#xBF;</B>', tclass: 'normal'},
-    {c: '<B>?</B>', lig: {'96': 62}, tclass: 'normal'},
+    {c: '<b>0</b>', tclass: 'normal'},
+    {c: '<b>1</b>', tclass: 'normal'},
+    {c: '<b>2</b>', tclass: 'normal'},
+    {c: '<b>3</b>', tclass: 'normal'},
+    {c: '<b>4</b>', tclass: 'normal'},
+    {c: '<b>5</b>', tclass: 'normal'},
+    {c: '<b>6</b>', tclass: 'normal'},
+    {c: '<b>7</b>', tclass: 'normal'},
+    {c: '<b>8</b>', tclass: 'normal'},
+    {c: '<b>9</b>', tclass: 'normal'},
+    {c: '<b>:</b>', tclass: 'normal'},
+    {c: '<b>;</b>', tclass: 'normal'},
+    {c: '<b>&#xA1;</b>', tclass: 'normal'},
+    {c: '<b>=</b>', a:0, d:-.1, tclass: 'normal'},
+    {c: '<b>&#xBF;</b>', tclass: 'normal'},
+    {c: '<b>?</b>', lig: {'96': 62}, tclass: 'normal'},
     // 40 - 4F
-    {c: '<B>@</B>', tclass: 'normal'},
-    {c: '<B>A</B>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
-    {c: '<B>B</B>', tclass: 'normal'},
-    {c: '<B>C</B>', tclass: 'normal'},
-    {c: '<B>D</B>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
-    {c: '<B>E</B>', tclass: 'normal'},
-    {c: '<B>F</B>', krn: {'111': -0.0833, '101': -0.0833, '117': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67': -0.0278, =
'71': -0.0278, '81': -0.0278}, tclass: 'normal'},
-    {c: '<B>G</B>', tclass: 'normal'},
-    {c: '<B>H</B>', tclass: 'normal'},
-    {c: '<B>I</B>', krn: {'73': 0.0278}, tclass: 'normal'},
-    {c: '<B>J</B>', tclass: 'normal'},
-    {c: '<B>K</B>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
-    {c: '<B>L</B>', krn: {'84': -0.0833, '89': -0.0833, '86': -0.111, '87'=
: -0.111}, tclass: 'normal'},
-    {c: '<B>M</B>', tclass: 'normal'},
-    {c: '<B>N</B>', tclass: 'normal'},
-    {c: '<B>O</B>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
+    {c: '<b>@</b>', tclass: 'normal'},
+    {c: '<b>A</b>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
+    {c: '<b>B</b>', tclass: 'normal'},
+    {c: '<b>C</b>', tclass: 'normal'},
+    {c: '<b>D</b>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
+    {c: '<b>E</b>', tclass: 'normal'},
+    {c: '<b>F</b>', krn: {'111': -0.0833, '101': -0.0833, '117': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67': -0.0278, =
'71': -0.0278, '81': -0.0278}, tclass: 'normal'},
+    {c: '<b>G</b>', tclass: 'normal'},
+    {c: '<b>H</b>', tclass: 'normal'},
+    {c: '<b>I</b>', krn: {'73': 0.0278}, tclass: 'normal'},
+    {c: '<b>J</b>', tclass: 'normal'},
+    {c: '<b>K</b>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
+    {c: '<b>L</b>', krn: {'84': -0.0833, '89': -0.0833, '86': -0.111, '87'=
: -0.111}, tclass: 'normal'},
+    {c: '<b>M</b>', tclass: 'normal'},
+    {c: '<b>N</b>', tclass: 'normal'},
+    {c: '<b>O</b>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
     // 50 - 5F
-    {c: '<B>P</B>', krn: {'65': -0.0833, '111': -0.0278, '101': -0.0278, '=
97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
-    {c: '<B>Q</B>', d: 1, tclass: 'normal'},
-    {c: '<B>R</B>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
-    {c: '<B>S</B>', tclass: 'normal'},
-    {c: '<B>T</B>', krn: {'121': -0.0278, '101': -0.0833, '111': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'nor=
mal'},
-    {c: '<B>U</B>', tclass: 'normal'},
-    {c: '<B>V</B>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
-    {c: '<B>W</B>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
-    {c: '<B>X</B>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
-    {c: '<B>Y</B>', ic: 0.025, krn: {'101': -0.0833, '111': -0.0833, '114'=
: -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'normal'},
-    {c: '<B>Z</B>', tclass: 'normal'},
-    {c: '<B>[</B>', d:.1, tclass: 'normal'},
-    {c: '<B>&#x201C;</B>', tclass: 'normal'},
-    {c: '<B>]</B>', d:.1, tclass: 'normal'},
-    {c: '<B>&#x2C6;</B>', tclass: 'accent'},
-    {c: '<B>&#x2D9;</B>', tclass: 'accent'},
+    {c: '<b>P</b>', krn: {'65': -0.0833, '111': -0.0278, '101': -0.0278, '=
97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
+    {c: '<b>Q</b>', d: 1, tclass: 'normal'},
+    {c: '<b>R</b>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
+    {c: '<b>S</b>', tclass: 'normal'},
+    {c: '<b>T</b>', krn: {'121': -0.0278, '101': -0.0833, '111': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'nor=
mal'},
+    {c: '<b>U</b>', tclass: 'normal'},
+    {c: '<b>V</b>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
+    {c: '<b>W</b>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
+    {c: '<b>X</b>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
+    {c: '<b>Y</b>', ic: 0.025, krn: {'101': -0.0833, '111': -0.0833, '114'=
: -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'normal'},
+    {c: '<b>Z</b>', tclass: 'normal'},
+    {c: '<b>[</b>', d:.1, tclass: 'normal'},
+    {c: '<b>&#x201C;</b>', tclass: 'normal'},
+    {c: '<b>]</b>', d:.1, tclass: 'normal'},
+    {c: '<b>&#x2C6;</b>', tclass: 'accent'},
+    {c: '<b>&#x2D9;</b>', tclass: 'accent'},
     // 60 - 6F
-    {c: '<B>&#x2018;</B>', lig: {'96': 92}, tclass: 'normal'},
-    {c: '<B>a</B>', a:0, krn: {'118': -0.0278, '106': 0.0556, '121': -0.02=
78, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>b</B>', krn: {'101': 0.0278, '111': 0.0278, '120': -0.0278, '1=
00': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.0556, '1=
21': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>c</B>', a:0, krn: {'104': -0.0278, '107': -0.0278}, tclass: 'n=
ormal'},
-    {c: '<B>d</B>', tclass: 'normal'},
-    {c: '<B>e</B>', a:0, tclass: 'normal'},
-    {c: '<B>f</B>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0.=
0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 12, '102': 11, '108': 13}, =
tclass: 'normal'},
-    {c: '<B>g</B>', a:0, d:1, ic: 0.0139, krn: {'106': 0.0278}, tclass: 'n=
ormal'},
-    {c: '<B>h</B>', krn: {'116': -0.0278, '117': -0.0278, '98': -0.0278, '=
121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>i</B>', tclass: 'normal'},
-    {c: '<B>j</B>', d:1, tclass: 'normal'},
-    {c: '<B>k</B>', krn: {'97': -0.0556, '101': -0.0278, '97': -0.0278, '1=
11': -0.0278, '99': -0.0278}, tclass: 'normal'},
-    {c: '<B>l</B>', tclass: 'normal'},
-    {c: '<B>m</B>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>n</B>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>o</B>', a:0, krn: {'101': 0.0278, '111': 0.0278, '120': -0.027=
8, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.055=
6, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>&#x2018;</b>', lig: {'96': 92}, tclass: 'normal'},
+    {c: '<b>a</b>', a:0, krn: {'118': -0.0278, '106': 0.0556, '121': -0.02=
78, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>b</b>', krn: {'101': 0.0278, '111': 0.0278, '120': -0.0278, '1=
00': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.0556, '1=
21': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>c</b>', a:0, krn: {'104': -0.0278, '107': -0.0278}, tclass: 'n=
ormal'},
+    {c: '<b>d</b>', tclass: 'normal'},
+    {c: '<b>e</b>', a:0, tclass: 'normal'},
+    {c: '<b>f</b>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0.=
0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 12, '102': 11, '108': 13}, =
tclass: 'normal'},
+    {c: '<b>g</b>', a:0, d:1, ic: 0.0139, krn: {'106': 0.0278}, tclass: 'n=
ormal'},
+    {c: '<b>h</b>', krn: {'116': -0.0278, '117': -0.0278, '98': -0.0278, '=
121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>i</b>', tclass: 'normal'},
+    {c: '<b>j</b>', d:1, tclass: 'normal'},
+    {c: '<b>k</b>', krn: {'97': -0.0556, '101': -0.0278, '97': -0.0278, '1=
11': -0.0278, '99': -0.0278}, tclass: 'normal'},
+    {c: '<b>l</b>', tclass: 'normal'},
+    {c: '<b>m</b>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>n</b>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>o</b>', a:0, krn: {'101': 0.0278, '111': 0.0278, '120': -0.027=
8, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.055=
6, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
     // 70 - 7F
-    {c: '<B>p</B>', a:0, d:1, krn: {'101': 0.0278, '111': 0.0278, '120': -=
0.0278, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': =
0.0556, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>q</B>', a:0, d:1, tclass: 'normal'},
-    {c: '<B>r</B>', a:0, tclass: 'normal'},
-    {c: '<B>s</B>', a:0, tclass: 'normal'},
-    {c: '<B>t</B>', krn: {'121': -0.0278, '119': -0.0278}, tclass: 'normal=
'},
-    {c: '<B>u</B>', a:0, krn: {'119': -0.0278}, tclass: 'normal'},
-    {c: '<B>v</B>', a:0, ic: 0.0139, krn: {'97': -0.0556, '101': -0.0278, =
'97': -0.0278, '111': -0.0278, '99': -0.0278}, tclass: 'normal'},
-    {c: '<B>w</B>', a:0, ic: 0.0139, krn: {'101': -0.0278, '97': -0.0278, =
'111': -0.0278, '99': -0.0278}, tclass: 'normal'},
-    {c: '<B>x</B>', a:0, tclass: 'normal'},
-    {c: '<B>y</B>', a:0, d:1, ic: 0.0139, krn: {'111': -0.0278, '101': -0.=
0278, '97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
-    {c: '<B>z</B>', a:0, tclass: 'normal'},
-    {c: '<B>&#x2013;</B>', a:.1, ic: 0.0278, lig: {'45': 124}, tclass: 'no=
rmal'},
-    {c: '<B>&#x2014;</B>', a:.1, ic: 0.0278, tclass: 'normal'},
-    {c: '<B>&#x2DD;</B>', tclass: 'accent'},
-    {c: '<B>&#x2DC;</B>', tclass: 'accent'},
-    {c: '<B>&#xA8;</B>', tclass: 'accent'}
+    {c: '<b>p</b>', a:0, d:1, krn: {'101': 0.0278, '111': 0.0278, '120': -=
0.0278, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': =
0.0556, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>q</b>', a:0, d:1, tclass: 'normal'},
+    {c: '<b>r</b>', a:0, tclass: 'normal'},
+    {c: '<b>s</b>', a:0, tclass: 'normal'},
+    {c: '<b>t</b>', krn: {'121': -0.0278, '119': -0.0278}, tclass: 'normal=
'},
+    {c: '<b>u</b>', a:0, krn: {'119': -0.0278}, tclass: 'normal'},
+    {c: '<b>v</b>', a:0, ic: 0.0139, krn: {'97': -0.0556, '101': -0.0278, =
'97': -0.0278, '111': -0.0278, '99': -0.0278}, tclass: 'normal'},
+    {c: '<b>w</b>', a:0, ic: 0.0139, krn: {'101': -0.0278, '97': -0.0278, =
'111': -0.0278, '99': -0.0278}, tclass: 'normal'},
+    {c: '<b>x</b>', a:0, tclass: 'normal'},
+    {c: '<b>y</b>', a:0, d:1, ic: 0.0139, krn: {'111': -0.0278, '101': -0.=
0278, '97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
+    {c: '<b>z</b>', a:0, tclass: 'normal'},
+    {c: '<b>&#x2013;</b>', a:.1, ic: 0.0278, lig: {'45': 124}, tclass: 'no=
rmal'},
+    {c: '<b>&#x2014;</b>', a:.1, ic: 0.0278, tclass: 'normal'},
+    {c: '<b>&#x2DD;</b>', tclass: 'accent'},
+    {c: '<b>&#x2DC;</b>', tclass: 'accent'},
+    {c: '<b>&#xA8;</b>', tclass: 'accent'}
   ]
 });

@@ -893,8 +893,8 @@
       var ph = Math.round(h*jsMath.em);
       if (h > jsMath.hd) {
         box.bd = jsMath.EmBoxFor(jsMath.HTML.Class(c.tclass,c.c)
-                   + '<IMG SRC="'+jsMath.blank+'" STYLE="'
-                   + 'width: 1; height: '+ph+'px">').h - h;
+                   + '<img src="'+jsMath.blank+'" style="'
+                   + 'width: 1px; height: '+ph+'px" />').h - h;
         box.bh = h - box.bd;
       }
       c.bh = box.bh/scale;
@@ -904,7 +904,7 @@
       // hack to avoid Font changing back to the default
       // font when a unicode reference is not followed
       // by a letter or number
-      box.html += '<SPAN STYLE="display: none">x</SPAN>'
+      box.html += '<span style="display: none">x</span>'
     }
     return box;
   }
@@ -992,8 +992,8 @@
 if (jsMath.browser == "MSIE") {
   jsMath.Update.TeXfonts({
     cmex10: {
-      '63': {c: '<SPAN STYLE="position:relative; left:.125em; margin-rig=
ht:.125em">|</SPAN>'},
-      '119': {c: '<SPAN STYLE="position:relative; left:.02em; margin-rig=
ht=.08em">|</SPAN><SPAN STYLE="margin-right:.125em">|</SPAN>'}
+      '63': {c: '<span style="position:relative; left:.125em; margin-rig=
ht:.125em">|</span>'},
+      '119': {c: '<span style="position:relative; left:.02em; margin-rig=
ht=.08em">|</span><span style="margin-right:.125em">|</span>'}
     }
   });
 }
diff -ur jsMath-2.3b/jsMath-fallback-symbols.js jsMath-2.3b-lowercase/jsMat=
h-fallback-symbols.js
--- jsMath-2.3b/jsMath-fallback-symbols.js	2005-09-21 17:34:16.000000000 -0=
700
+++ jsMath-2.3b-lowercase/jsMath-fallback-symbols.js	2005-10-30 11:11:18.00=
0000000 -0800
@@ -46,8 +46,8 @@
       var ph = Math.round(h*jsMath.em);
       if (h > jsMath.hd) {
         box.bd = jsMath.EmBoxFor(jsMath.HTML.Class(c.tclass,c.c)
-                   + '<IMG SRC="'+jsMath.blank+'" STYLE="'
-                   + 'width: 1; height: '+ph+'px">').h - h;
+                   + '<img src="'+jsMath.blank+'" style="'
+                   + 'width: 1; height: '+ph+'px" />').h - h;
         box.bh = h - box.bd;
       }
       c.bh = box.bh/scale;
@@ -57,7 +57,7 @@
       // hack to avoid Font changing back to the default
       // font when a unicode reference is not followed
       // by a letter or number
-      box.html += '<SPAN STYLE="display: none">x</SPAN>'
+      box.html += '<span style="display: none">x</span>'
     }
     return box;
   }
diff -ur jsMath-2.3b/jsMath-fallback-unix.js jsMath-2.3b-lowercase/jsMath-f=
allback-unix.js
--- jsMath-2.3b/jsMath-fallback-unix.js	2005-09-21 17:34:42.000000000 -0700
+++ jsMath-2.3b-lowercase/jsMath-fallback-unix.js	2005-10-30 11:11:18.00000=
0000 -0800
@@ -61,7 +61,7 @@
     {c: '&#xB4;', tclass: 'accent'},
     {c: '&#x2C7;', tclass: 'accent'},
     {c: '&#x2D8;', tclass: 'accent'},
-    {c: '<SPAN STYLE="position:relative; top:.1em">&#x2C9;</SPAN>', tcla=
ss: 'accent'},
+    {c: '<span style="position:relative; top:.1em">&#x2C9;</span>', tcla=
ss: 'accent'},
     {c: '&#x2DA;', tclass: 'accent'},
     {c: '&#x0327;', tclass: 'normal'},
     {c: '&#xDF;', tclass: 'normal'},
@@ -177,17 +177,17 @@
  
   cmmi10: [
     // 00 - 0F
-    {c: '<I>&Gamma;</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '5=
8': -0.111, '127': 0.0833}, tclass: 'greek'},
-    {c: '<I>&Delta;</I>', krn: {'127': 0.167}, tclass: 'greek'},
-    {c: '<I>&Theta;</I>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'greek=
'},
-    {c: '<I>&Lambda;</I>', krn: {'127': 0.167}, tclass: 'greek'},
-    {c: '<I>&Xi;</I>', ic: 0.0757, krn: {'127': 0.0833}, tclass: 'greek'},
-    {c: '<I>&Pi;</I>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58=
': -0.0556, '127': 0.0556}, tclass: 'greek'},
-    {c: '<I>&Sigma;</I>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'greek=
'},
-    {c: '<I>&Upsilon;</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, =
'58': -0.111, '127': 0.0556}, tclass: 'greek'},
-    {c: '<I>&Phi;</I>', krn: {'127': 0.0833}, tclass: 'greek'},
-    {c: '<I>&Psi;</I>', ic: 0.11, krn: {'61': -0.0556, '59': -0.0556, '58'=
: -0.0556, '127': 0.0556}, tclass: 'greek'},
-    {c: '<I>&Omega;</I>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'greek=
'},
+    {c: '<i>&Gamma;</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '5=
8': -0.111, '127': 0.0833}, tclass: 'greek'},
+    {c: '<i>&Delta;</i>', krn: {'127': 0.167}, tclass: 'greek'},
+    {c: '<i>&Theta;</i>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'greek=
'},
+    {c: '<i>&Lambda;</i>', krn: {'127': 0.167}, tclass: 'greek'},
+    {c: '<i>&Xi;</i>', ic: 0.0757, krn: {'127': 0.0833}, tclass: 'greek'},
+    {c: '<i>&Pi;</i>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58=
': -0.0556, '127': 0.0556}, tclass: 'greek'},
+    {c: '<i>&Sigma;</i>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'greek=
'},
+    {c: '<i>&Upsilon;</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, =
'58': -0.111, '127': 0.0556}, tclass: 'greek'},
+    {c: '<i>&Phi;</i>', krn: {'127': 0.0833}, tclass: 'greek'},
+    {c: '<i>&Psi;</i>', ic: 0.11, krn: {'61': -0.0556, '59': -0.0556, '58'=
: -0.0556, '127': 0.0556}, tclass: 'greek'},
+    {c: '<i>&Omega;</i>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'greek=
'},
     {c: '&alpha;', a:0, ic: 0.0037, krn: {'127': 0.0278}, tclass: 'greek'},
     {c: '&beta;', d:1, ic: 0.0528, krn: {'127': 0.0833}, tclass: 'greek'},
     {c: '&gamma;', a:0, d:1, ic: 0.0556, tclass: 'greek'},
@@ -223,10 +223,10 @@
     {c: '&#x21BD;', a:0, d:-.1, tclass: 'harpoon'},
     {c: '&#x21C0;', a:0, d:-.2, tclass: 'harpoon'},
     {c: '&#x21C1;', a:0, d:-.1, tclass: 'harpoon'},
-    {c: '<SPAN STYLE="font-size: 133%; position:relative; top:-.1em; mar=
gin:-.2em; left:-.05em">&#x02D3;</SPAN>', a:.1, tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 133%; position:relative; top:-.1em; mar=
gin:-.2em; left:-.05em">&#x02D2;</SPAN>', a:.1, tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size:50%">&#x25B7;</SPAN>', tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size:50%">&#x25C1;</SPAN>', tclass: 'symbol'},
+    {c: '<span style="font-size: 133%; position:relative; top:-.1em; mar=
gin:-.2em; left:-.05em">&#x02D3;</span>', a:.1, tclass: 'symbol'},
+    {c: '<span style="font-size: 133%; position:relative; top:-.1em; mar=
gin:-.2em; left:-.05em">&#x02D2;</span>', a:.1, tclass: 'symbol'},
+    {c: '<span style="font-size:50%">&#x25B7;</span>', tclass: 'symbol'},
+    {c: '<span style="font-size:50%">&#x25C1;</span>', tclass: 'symbol'},
     // 30 - 3F
     {c: '0', tclass: 'normal'},
     {c: '1', tclass: 'normal'},
@@ -243,36 +243,36 @@
     {c: '&lt;', a:.1, tclass: 'normal'},
     {c: '/', krn: {'1': -0.0556, '65': -0.0556, '77': -0.0556, '78': -0.05=
56, '89': 0.0556, '90': -0.0556}, tclass: 'normal'},
     {c: '&gt;', a:.1, tclass: 'normal'},
-    {c: '<SPAN STYLE="font-size:50%">&#x2605;</SPAN>', a:0, tclass: 'sym=
bol'},
+    {c: '<span style="font-size:50%">&#x2605;</span>', a:0, tclass: 'sym=
bol'},
     // 40 - 4F
     {c: '&#x2202;', ic: 0.0556, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>A</I>', krn: {'127': 0.139}, tclass: 'normal'},
-    {c: '<I>B</I>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>C</I>', ic: 0.0715, krn: {'61': -0.0278, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>D</I>', ic: 0.0278, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>E</I>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>F</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>G</I>', krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>H</I>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
-    {c: '<I>I</I>', ic: 0.0785, krn: {'127': 0.111}, tclass: 'normal'},
-    {c: '<I>J</I>', ic: 0.0962, krn: {'61': -0.0556, '59': -0.111, '58': -=
0.111, '127': 0.167}, tclass: 'normal'},
-    {c: '<I>K</I>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
-    {c: '<I>L</I>', krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>M</I>', ic: 0.109, krn: {'61': -0.0556, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>N</I>', ic: 0.109, krn: {'61': -0.0833, '61': -0.0278, '59': -=
0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>O</I>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>A</i>', krn: {'127': 0.139}, tclass: 'normal'},
+    {c: '<i>B</i>', ic: 0.0502, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>C</i>', ic: 0.0715, krn: {'61': -0.0278, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>D</i>', ic: 0.0278, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>E</i>', ic: 0.0576, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>F</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>G</i>', krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>H</i>', ic: 0.0812, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
+    {c: '<i>I</i>', ic: 0.0785, krn: {'127': 0.111}, tclass: 'normal'},
+    {c: '<i>J</i>', ic: 0.0962, krn: {'61': -0.0556, '59': -0.111, '58': -=
0.111, '127': 0.167}, tclass: 'normal'},
+    {c: '<i>K</i>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0556}, tclass: 'normal'},
+    {c: '<i>L</i>', krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>M</i>', ic: 0.109, krn: {'61': -0.0556, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>N</i>', ic: 0.109, krn: {'61': -0.0833, '61': -0.0278, '59': -=
0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>O</i>', ic: 0.0278, krn: {'127': 0.0833}, tclass: 'normal'},
     // 50 - 5F
-    {c: '<I>P</I>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>Q</I>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>R</I>', ic: 0.00773, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>S</I>', ic: 0.0576, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>T</I>', ic: 0.139, krn: {'61': -0.0278, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>U</I>', ic: 0.109, krn: {'59': -0.111, '58': -0.111, '61': -0.=
0556, '127': 0.0278}, tclass: 'normal'},
-    {c: '<I>V</I>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
-    {c: '<I>W</I>', ic: 0.139, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
-    {c: '<I>X</I>', ic: 0.0785, krn: {'61': -0.0833, '61': -0.0278, '59': =
-0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
-    {c: '<I>Y</I>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
-    {c: '<I>Z</I>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>P</i>', ic: 0.139, krn: {'61': -0.0556, '59': -0.111, '58': -0=
=2E111, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>Q</i>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>R</i>', ic: 0.00773, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>S</i>', ic: 0.0576, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>T</i>', ic: 0.139, krn: {'61': -0.0278, '59': -0.0556, '58': -=
0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>U</i>', ic: 0.109, krn: {'59': -0.111, '58': -0.111, '61': -0.=
0556, '127': 0.0278}, tclass: 'normal'},
+    {c: '<i>V</i>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
+    {c: '<i>W</i>', ic: 0.139, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
+    {c: '<i>X</i>', ic: 0.0785, krn: {'61': -0.0833, '61': -0.0278, '59': =
-0.0556, '58': -0.0556, '127': 0.0833}, tclass: 'normal'},
+    {c: '<i>Y</i>', ic: 0.222, krn: {'59': -0.167, '58': -0.167, '61': -0.=
111}, tclass: 'normal'},
+    {c: '<i>Z</i>', ic: 0.0715, krn: {'61': -0.0556, '59': -0.0556, '58': =
-0.0556, '127': 0.0833}, tclass: 'normal'},
     {c: '&#x266D;', tclass: 'symbol2'},
     {c: '&#x266E;', tclass: 'symbol2'},
     {c: '&#x266F;', tclass: 'symbol2'},
@@ -280,37 +280,37 @@
     {c: '&#x2322;', a:0, d:-.1, tclass: 'normal'},
     // 60 - 6F
     {c: '&#x2113;', krn: {'127': 0.111}, tclass: 'symbol'},
-    {c: '<I>a</I>', a:0, tclass: 'normal'},
-    {c: '<I>b</I>', tclass: 'normal'},
-    {c: '<I>c</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>d</I>', krn: {'89': 0.0556, '90': -0.0556, '106': -0.111, '102=
': -0.167, '127': 0.167}, tclass: 'normal'},
-    {c: '<I>e</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>f</I>', d:1, ic: 0.108, krn: {'59': -0.0556, '58': -0.0556, '1=
27': 0.167}, tclass: 'normal'},
-    {c: '<I>g</I>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'n=
ormal'},
-    {c: '<I>h</I>', krn: {'127': -0.0278}, tclass: 'normal'},
-    {c: '<I>i</I>', tclass: 'normal'},
-    {c: '<I>j</I>', d:1, ic: 0.0572, krn: {'59': -0.0556, '58': -0.0556}, =
tclass: 'normal'},
-    {c: '<I>k</I>', ic: 0.0315, tclass: 'normal'},
-    {c: '<I>l</I>', ic: 0.0197, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>m</I>', a:0, tclass: 'normal'},
-    {c: '<I>n</I>', a:0, tclass: 'normal'},
-    {c: '<I>o</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>a</i>', a:0, tclass: 'normal'},
+    {c: '<i>b</i>', tclass: 'normal'},
+    {c: '<i>c</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>d</i>', krn: {'89': 0.0556, '90': -0.0556, '106': -0.111, '102=
': -0.167, '127': 0.167}, tclass: 'normal'},
+    {c: '<i>e</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>f</i>', d:1, ic: 0.108, krn: {'59': -0.0556, '58': -0.0556, '1=
27': 0.167}, tclass: 'normal'},
+    {c: '<i>g</i>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'n=
ormal'},
+    {c: '<i>h</i>', krn: {'127': -0.0278}, tclass: 'normal'},
+    {c: '<i>i</i>', tclass: 'normal'},
+    {c: '<i>j</i>', d:1, ic: 0.0572, krn: {'59': -0.0556, '58': -0.0556}, =
tclass: 'normal'},
+    {c: '<i>k</i>', ic: 0.0315, tclass: 'normal'},
+    {c: '<i>l</i>', ic: 0.0197, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>m</i>', a:0, tclass: 'normal'},
+    {c: '<i>n</i>', a:0, tclass: 'normal'},
+    {c: '<i>o</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
     // 70 - 7F
-    {c: '<I>p</I>', a:0, d:1, krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>q</I>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0833}, tclass: 'n=
ormal'},
-    {c: '<I>r</I>', a:0, ic: 0.0278, krn: {'59': -0.0556, '58': -0.0556, '=
127': 0.0556}, tclass: 'normal'},
-    {c: '<I>s</I>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
-    {c: '<I>t</I>', krn: {'127': 0.0833}, tclass: 'normal'},
-    {c: '<I>u</I>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>v</I>', a:0, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'normal=
'},
-    {c: '<I>w</I>', a:0, ic: 0.0269, krn: {'127': 0.0833}, tclass: 'normal=
'},
-    {c: '<I>x</I>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>y</I>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0556}, tclass: 'n=
ormal'},
-    {c: '<I>z</I>', a:0, ic: 0.044, krn: {'127': 0.0556}, tclass: 'normal'=
},
-    {c: '<I>&#x131;</I>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
-    {c: '<I>j</I>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>p</i>', a:0, d:1, krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>q</i>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0833}, tclass: 'n=
ormal'},
+    {c: '<i>r</i>', a:0, ic: 0.0278, krn: {'59': -0.0556, '58': -0.0556, '=
127': 0.0556}, tclass: 'normal'},
+    {c: '<i>s</i>', a:0, krn: {'127': 0.0556}, tclass: 'normal'},
+    {c: '<i>t</i>', krn: {'127': 0.0833}, tclass: 'normal'},
+    {c: '<i>u</i>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>v</i>', a:0, ic: 0.0359, krn: {'127': 0.0278}, tclass: 'normal=
'},
+    {c: '<i>w</i>', a:0, ic: 0.0269, krn: {'127': 0.0833}, tclass: 'normal=
'},
+    {c: '<i>x</i>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>y</i>', a:0, d:1, ic: 0.0359, krn: {'127': 0.0556}, tclass: 'n=
ormal'},
+    {c: '<i>z</i>', a:0, ic: 0.044, krn: {'127': 0.0556}, tclass: 'normal'=
},
+    {c: '<i>&#x131;</i>', a:0, krn: {'127': 0.0278}, tclass: 'normal'},
+    {c: '<i>j</i>', d:1, krn: {'127': 0.0833}, tclass: 'normal'},
     {c: '&#x2118;', a:0, d:1, krn: {'127': 0.111}, tclass: 'normal'},
-    {c: '<SPAN STYLE="position:relative; left: .4em; top: -.8em; font-si=
ze: 50%">&#x2192;</SPAN>', ic: 0.154, tclass: 'symbol'},
+    {c: '<span style="position:relative; left: .4em; top: -.8em; font-si=
ze: 50%">&#x2192;</span>', ic: 0.154, tclass: 'symbol'},
     {c: '&#x0311;', ic: 0.399, tclass: 'normal'}
   ],

@@ -319,7 +319,7 @@
     {c: '&#x2212;', a:.1, tclass: 'symbol'},
     {c: '&#xB7;', a:0, d:-.2, tclass: 'symbol'},
     {c: '&#xD7;', a:0, tclass: 'symbol'},
-    {c: '<SPAN STYLE="position:relative; top:.2em">&#x2A;</SPAN>', a:0, =
tclass: 'symbol'},
+    {c: '<span style="position:relative; top:.2em">&#x2A;</span>', a:0, =
tclass: 'symbol'},
     {c: '&#xF7;', a:0, tclass: 'symbol'},
     {c: '&#x25CA;', tclass: 'symbol'},
     {c: '&#xB1;', a:.1, tclass: 'symbol'},
@@ -330,7 +330,7 @@
     {c: '&#x2298;', tclass: 'symbol'},
     {c: '&#x2299;', tclass: 'symbol'},
     {c: '&#x25EF;', tclass: 'symbol'},
-    {c: '<SPAN STYLE="position:relative; top:.25em;">&#xB0;</SPAN>', a:0=
, d:-.1, tclass: 'symbol'},
+    {c: '<span style="position:relative; top:.25em;">&#xB0;</span>', a:0=
, d:-.1, tclass: 'symbol'},
     {c: '&#x2022;', a:0, d:-.2, tclass: 'symbol'},
     // 10 - 1F
     {c: '&#x224D;', a:.1, tclass: 'symbol'},
@@ -367,14 +367,14 @@
     {c: '&#x2199;', h:1, tclass: 'arrows'},
     {c: '&#x221D;', a:.1, tclass: 'symbol'},
     // 30 - 3F
-    {c: '<SPAN STYLE="font-size: 133%; margin-right: -.1em; position: re=
lative; top:.4em">&#x2032;</SPAN>', a: 0, tclass: 'symbol'},
+    {c: '<span style="font-size: 133%; margin-right: -.1em; position: re=
lative; top:.4em">&#x2032;</span>', a: 0, tclass: 'symbol'},
     {c: '&#x221E;', a:.1, tclass: 'symbol'},
     {c: '&#x2208;', tclass: 'symbol'},
     {c: '&#x220B;', tclass: 'symbol'},
     {c: '&#x25B3;', tclass: 'symbol'},
     {c: '&#x25BD;', tclass: 'symbol'},
     {c: '/', tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size:50%; position:relative; top:-.3em; margi=
n-right:-.2em">|</SPAN>', a:0, tclass: 'normal'},
+    {c: '<span style="font-size:50%; position:relative; top:-.3em; margi=
n-right:-.2em">|</span>', a:0, tclass: 'normal'},
     {c: '&#x2200;', tclass: 'symbol'},
     {c: '&#x2203;', tclass: 'symbol'},
     {c: '&#xAC;', a:0, d:-.1, tclass: 'symbol1'},
@@ -435,7 +435,7 @@
     {c: '&#x2216;', a:.3, d:.1, tclass: 'normal'},
     {c: '&#x2240;', tclass: 'symbol'},
     // 70 - 7F
-    {c: '<SPAN STYLE="position:relative; top: .8em">&#x221A;</SPAN>', h:=
=2E04, d:.9, tclass: 'normal'},
+    {c: '<span style="position:relative; top: .8em">&#x221A;</span>', h:=
=2E04, d:.9, tclass: 'normal'},
     {c: '&#x2210;', a:.4, tclass: 'symbol'},
     {c: '&#x2207;', tclass: 'symbol'},
     {c: '&#x222B;', h:1, d:.1, ic: 0.111, tclass: 'root'},
@@ -574,300 +574,300 @@
     {c: '{', h: 0.04, d: 1.76, n: 26, tclass: 'delim2'},
     {c: '}', h: 0.04, d: 1.76, n: 27, tclass: 'delim2'},
     // 70 - 7F
-    {c: '<SPAN STYLE="font-size: 125%; position:relative; top:.95em">&#x=
221A;</SPAN>', h: 0.04, d: 1.16, n: 113, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 190%; position:relative; top:.925em">&#=
x221A;</SPAN>', h: 0.04, d: 1.76, n: 114, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 250%; position:relative; top:.925em">&#=
x221A;</SPAN>', h: 0.06, d: 2.36, n: 115, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 320%; position:relative; top:.92em">&#x=
221A;</SPAN>', h: 0.08, d: 2.96, n: 116, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 400%; position:relative; top:.92em">&#x=
221A;</SPAN>', h: 0.1, d: 3.75, n: 117, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 500%; position:relative; top:.9em">&#x2=
21A;</SPAN>', h: .12, d: 4.5, n: 118, tclass: 'root'},
-    {c: '<SPAN STYLE="font-size: 625%; position:relative; top:.9em">&#x2=
21A;</SPAN>', h: .14, d: 5.7, tclass: 'root'},
-    {c: '<SPAN STYLE="margin:.001em">||</SPAN>', h:.65, d:0, delim: {top=
: 126, bot: 127, rep: 119}, tclass: 'vertical'},
+    {c: '<span style="font-size: 125%; position:relative; top:.95em">&#x=
221A;</span>', h: 0.04, d: 1.16, n: 113, tclass: 'root'},
+    {c: '<span style="font-size: 190%; position:relative; top:.925em">&#=
x221A;</span>', h: 0.04, d: 1.76, n: 114, tclass: 'root'},
+    {c: '<span style="font-size: 250%; position:relative; top:.925em">&#=
x221A;</span>', h: 0.06, d: 2.36, n: 115, tclass: 'root'},
+    {c: '<span style="font-size: 320%; position:relative; top:.92em">&#x=
221A;</span>', h: 0.08, d: 2.96, n: 116, tclass: 'root'},
+    {c: '<span style="font-size: 400%; position:relative; top:.92em">&#x=
221A;</span>', h: 0.1, d: 3.75, n: 117, tclass: 'root'},
+    {c: '<span style="font-size: 500%; position:relative; top:.9em">&#x2=
21A;</span>', h: .12, d: 4.5, n: 118, tclass: 'root'},
+    {c: '<span style="font-size: 625%; position:relative; top:.9em">&#x2=
21A;</span>', h: .14, d: 5.7, tclass: 'root'},
+    {c: '<span style="margin:.001em">||</span>', h:.65, d:0, delim: {top=
: 126, bot: 127, rep: 119}, tclass: 'vertical'},
     {c: '&#x25B5;', h:.45, delim: {top: 120, rep: 63}, tclass: 'arrow1'},
     {c: '&#x25BF;', h:.45, delim: {bot: 121, rep: 63}, tclass: 'arrow1'},
-    {c: '<SPAN STYLE="font-size: 67%; position:relative; top:.35em; marg=
in-left:-.5em">&#x256D;</SPAN>', h:.1, tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 67%; position:relative; top:.35em; marg=
in-right:-.5em">&#x256E;</SPAN>', h:.1, tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 67%; position:relative; top:.35em; marg=
in-left:-.5em">&#x2570;</SPAN>', h:.1, tclass: 'symbol'},
-    {c: '<SPAN STYLE="font-size: 67%; position:relative; top:.35em; marg=
in-right:-.5em">&#x256F;</SPAN>', h:.1, tclass: 'symbol'},
+    {c: '<span style="font-size: 67%; position:relative; top:.35em; marg=
in-left:-.5em">&#x256D;</span>', h:.1, tclass: 'symbol'},
+    {c: '<span style="font-size: 67%; position:relative; top:.35em; marg=
in-right:-.5em">&#x256E;</span>', h:.1, tclass: 'symbol'},
+    {c: '<span style="font-size: 67%; position:relative; top:.35em; marg=
in-left:-.5em">&#x2570;</span>', h:.1, tclass: 'symbol'},
+    {c: '<span style="font-size: 67%; position:relative; top:.35em; marg=
in-right:-.5em">&#x256F;</span>', h:.1, tclass: 'symbol'},
     {c: '&#x25B5;', h:.5, delim: {top: 126, rep: 119}, tclass: 'arrow2'},
     {c: '&#x25BF;', h:.5, delim: {bot: 127, rep: 119}, tclass: 'arrow2'}
   ],
  
   cmti10: [
     // 00 - 0F
-    {c: '<I>&Gamma;</I>', ic: 0.133, tclass: 'greek'},
-    {c: '<I>&Delta;</I>', tclass: 'greek'},
-    {c: '<I>&Theta;</I>', ic: 0.094, tclass: 'greek'},
-    {c: '<I>&Lambda;</I>', tclass: 'greek'},
-    {c: '<I>&Xi;</I>', ic: 0.153, tclass: 'greek'},
-    {c: '<I>&Pi;</I>', ic: 0.164, tclass: 'greek'},
-    {c: '<I>&Sigma;</I>', ic: 0.12, tclass: 'greek'},
-    {c: '<I>&Upsilon;</I>', ic: 0.111, tclass: 'greek'},
-    {c: '<I>&Phi;</I>', ic: 0.0599, tclass: 'greek'},
-    {c: '<I>&Psi;</I>', ic: 0.111, tclass: 'greek'},
-    {c: '<I>&Omega;</I>', ic: 0.103, tclass: 'greek'},
-    {c: '<I>ff</I>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.10=
4, '41': 0.104, '93': 0.104}, lig: {'105': 14, '108': 15}, tclass: 'normal'=
},
-    {c: '<I>fi</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>fl</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>ffi</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>ffl</I>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>&Gamma;</i>', ic: 0.133, tclass: 'greek'},
+    {c: '<i>&Delta;</i>', tclass: 'greek'},
+    {c: '<i>&Theta;</i>', ic: 0.094, tclass: 'greek'},
+    {c: '<i>&Lambda;</i>', tclass: 'greek'},
+    {c: '<i>&Xi;</i>', ic: 0.153, tclass: 'greek'},
+    {c: '<i>&Pi;</i>', ic: 0.164, tclass: 'greek'},
+    {c: '<i>&Sigma;</i>', ic: 0.12, tclass: 'greek'},
+    {c: '<i>&Upsilon;</i>', ic: 0.111, tclass: 'greek'},
+    {c: '<i>&Phi;</i>', ic: 0.0599, tclass: 'greek'},
+    {c: '<i>&Psi;</i>', ic: 0.111, tclass: 'greek'},
+    {c: '<i>&Omega;</i>', ic: 0.103, tclass: 'greek'},
+    {c: '<i>ff</i>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.10=
4, '41': 0.104, '93': 0.104}, lig: {'105': 14, '108': 15}, tclass: 'normal'=
},
+    {c: '<i>fi</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>fl</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>ffi</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>ffl</i>', ic: 0.103, tclass: 'normal'},
     // 10 - 1F
-    {c: '<I>&#x131;</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>j</I>', d:.2, ic: 0.0374, tclass: 'normal'},
-    {c: '<I>&#x60;</I>', tclass: 'accent'},
-    {c: '<I>&#xB4;</I>', ic: 0.0969, tclass: 'accent'},
-    {c: '<I>&#x2C7;</I>', ic: 0.083, tclass: 'accent'},
-    {c: '<I>&#x2D8;</I>', ic: 0.108, tclass: 'accent'},
-    {c: '<I>&#x2C9;</I>', ic: 0.103, tclass: 'accent'},
-    {c: '<I>&#x2DA;</I>', tclass: 'accent'},
-    {c: '<I>?</I>', d: 0.17, w: 0.46, tclass: 'normal'},
-    {c: '<I>&#xDF;</I>', ic: 0.105, tclass: 'normal'},
-    {c: '<I>&#xE6;</I>', a:0, ic: 0.0751, tclass: 'normal'},
-    {c: '<I>&#x153;</I>', a:0, ic: 0.0751, tclass: 'normal'},
-    {c: '<I>&#xF8;</I>', ic: 0.0919, tclass: 'normal'},
-    {c: '<I>&#xC6;</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>&#x152;</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>&#xD8;</I>', ic: 0.094, tclass: 'normal'},
+    {c: '<i>&#x131;</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>j</i>', d:.2, ic: 0.0374, tclass: 'normal'},
+    {c: '<i>&#x60;</i>', tclass: 'accent'},
+    {c: '<i>&#xB4;</i>', ic: 0.0969, tclass: 'accent'},
+    {c: '<i>&#x2C7;</i>', ic: 0.083, tclass: 'accent'},
+    {c: '<i>&#x2D8;</i>', ic: 0.108, tclass: 'accent'},
+    {c: '<i>&#x2C9;</i>', ic: 0.103, tclass: 'accent'},
+    {c: '<i>&#x2DA;</i>', tclass: 'accent'},
+    {c: '<i>?</i>', d: 0.17, w: 0.46, tclass: 'normal'},
+    {c: '<i>&#xDF;</i>', ic: 0.105, tclass: 'normal'},
+    {c: '<i>&#xE6;</i>', a:0, ic: 0.0751, tclass: 'normal'},
+    {c: '<i>&#x153;</i>', a:0, ic: 0.0751, tclass: 'normal'},
+    {c: '<i>&#xF8;</i>', ic: 0.0919, tclass: 'normal'},
+    {c: '<i>&#xC6;</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>&#x152;</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>&#xD8;</i>', ic: 0.094, tclass: 'normal'},
     // 20 - 2F
-    {c: '<I>?</I>', krn: {'108': -0.256, '76': -0.321}, tclass: 'normal'},
-    {c: '<I>!</I>', ic: 0.124, lig: {'96': 60}, tclass: 'normal'},
-    {c: '<I>&#x201D;</I>', ic: 0.0696, tclass: 'normal'},
-    {c: '<I>#</I>', ic: 0.0662, tclass: 'normal'},
-    {c: '<I>$</I>', tclass: 'normal'},
-    {c: '<I>%</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>&amp;</I>', ic: 0.0969, tclass: 'normal'},
-    {c: '<I>&#x2019;</I>', ic: 0.124, krn: {'63': 0.102, '33': 0.102}, lig=
: {'39': 34}, tclass: 'normal'},
-    {c: '<I>(</I>', d:.2, ic: 0.162, tclass: 'normal'},
-    {c: '<I>)</I>', d:.2, ic: 0.0369, tclass: 'normal'},
-    {c: '<I>*</I>', ic: 0.149, tclass: 'normal'},
-    {c: '<I>+</I>', a:.1, ic: 0.0369, tclass: 'normal'},
-    {c: '<I>,</I>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
-    {c: '<I>-</I>', a:0, ic: 0.0283, lig: {'45': 123}, tclass: 'normal'},
-    {c: '<I>.</I>', a:-.25, tclass: 'normal'},
-    {c: '<I>/</I>', ic: 0.162, tclass: 'normal'},
+    {c: '<i>?</i>', krn: {'108': -0.256, '76': -0.321}, tclass: 'normal'},
+    {c: '<i>!</i>', ic: 0.124, lig: {'96': 60}, tclass: 'normal'},
+    {c: '<i>&#x201D;</i>', ic: 0.0696, tclass: 'normal'},
+    {c: '<i>#</i>', ic: 0.0662, tclass: 'normal'},
+    {c: '<i>$</i>', tclass: 'normal'},
+    {c: '<i>%</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>&amp;</i>', ic: 0.0969, tclass: 'normal'},
+    {c: '<i>&#x2019;</i>', ic: 0.124, krn: {'63': 0.102, '33': 0.102}, lig=
: {'39': 34}, tclass: 'normal'},
+    {c: '<i>(</i>', d:.2, ic: 0.162, tclass: 'normal'},
+    {c: '<i>)</i>', d:.2, ic: 0.0369, tclass: 'normal'},
+    {c: '<i>*</i>', ic: 0.149, tclass: 'normal'},
+    {c: '<i>+</i>', a:.1, ic: 0.0369, tclass: 'normal'},
+    {c: '<i>,</i>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
+    {c: '<i>-</i>', a:0, ic: 0.0283, lig: {'45': 123}, tclass: 'normal'},
+    {c: '<i>.</i>', a:-.25, tclass: 'normal'},
+    {c: '<i>/</i>', ic: 0.162, tclass: 'normal'},
     // 30 - 3F
-    {c: '<I>0</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>1</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>2</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>3</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>4</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>5</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>6</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>7</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>8</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>9</I>', ic: 0.136, tclass: 'normal'},
-    {c: '<I>:</I>', ic: 0.0582, tclass: 'normal'},
-    {c: '<I>;</I>', ic: 0.0582, tclass: 'normal'},
-    {c: '<I>&#xA1;</I>', ic: 0.0756, tclass: 'normal'},
-    {c: '<I>=</I>', a:0, d:-.1, ic: 0.0662, tclass: 'normal'},
-    {c: '<I>&#xBF;</I>', tclass: 'normal'},
-    {c: '<I>?</I>', ic: 0.122, lig: {'96': 62}, tclass: 'normal'},
+    {c: '<i>0</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>1</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>2</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>3</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>4</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>5</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>6</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>7</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>8</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>9</i>', ic: 0.136, tclass: 'normal'},
+    {c: '<i>:</i>', ic: 0.0582, tclass: 'normal'},
+    {c: '<i>;</i>', ic: 0.0582, tclass: 'normal'},
+    {c: '<i>&#xA1;</i>', ic: 0.0756, tclass: 'normal'},
+    {c: '<i>=</i>', a:0, d:-.1, ic: 0.0662, tclass: 'normal'},
+    {c: '<i>&#xBF;</i>', tclass: 'normal'},
+    {c: '<i>?</i>', ic: 0.122, lig: {'96': 62}, tclass: 'normal'},
     // 40 - 4F
-    {c: '<I>@</I>', ic: 0.096, tclass: 'normal'},
-    {c: '<I>A</I>', krn: {'110': -0.0256, '108': -0.0256, '114': -0.0256, =
'117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256, '67': -0.02=
56, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256, '85': -0.0=
256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0256, '84': -=
0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.0511, '97': -0=
=2E0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '11=
3': -0.0511}, tclass: 'normal'},
-    {c: '<I>B</I>', ic: 0.103, tclass: 'normal'},
-    {c: '<I>C</I>', ic: 0.145, tclass: 'normal'},
-    {c: '<I>D</I>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
-    {c: '<I>E</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>F</I>', ic: 0.133, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>G</I>', ic: 0.0872, tclass: 'normal'},
-    {c: '<I>H</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>I</I>', ic: 0.158, tclass: 'normal'},
-    {c: '<I>J</I>', ic: 0.14, tclass: 'normal'},
-    {c: '<I>K</I>', ic: 0.145, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>L</I>', krn: {'84': -0.0767, '89': -0.0767, '86': -0.102, '87'=
: -0.102, '101': -0.0511, '97': -0.0511, '111': -0.0511, '100': -0.0511, '9=
9': -0.0511, '103': -0.0511, '113': -0.0511}, tclass: 'normal'},
-    {c: '<I>M</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>N</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>O</I>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
+    {c: '<i>@</i>', ic: 0.096, tclass: 'normal'},
+    {c: '<i>A</i>', krn: {'110': -0.0256, '108': -0.0256, '114': -0.0256, =
'117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256, '67': -0.02=
56, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256, '85': -0.0=
256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0256, '84': -=
0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.0511, '97': -0=
=2E0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '11=
3': -0.0511}, tclass: 'normal'},
+    {c: '<i>B</i>', ic: 0.103, tclass: 'normal'},
+    {c: '<i>C</i>', ic: 0.145, tclass: 'normal'},
+    {c: '<i>D</i>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
+    {c: '<i>E</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>F</i>', ic: 0.133, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>G</i>', ic: 0.0872, tclass: 'normal'},
+    {c: '<i>H</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>I</i>', ic: 0.158, tclass: 'normal'},
+    {c: '<i>J</i>', ic: 0.14, tclass: 'normal'},
+    {c: '<i>K</i>', ic: 0.145, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>L</i>', krn: {'84': -0.0767, '89': -0.0767, '86': -0.102, '87'=
: -0.102, '101': -0.0511, '97': -0.0511, '111': -0.0511, '100': -0.0511, '9=
9': -0.0511, '103': -0.0511, '113': -0.0511}, tclass: 'normal'},
+    {c: '<i>M</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>N</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>O</i>', ic: 0.094, krn: {'88': -0.0256, '87': -0.0256, '65': -=
0.0256, '86': -0.0256, '89': -0.0256}, tclass: 'normal'},
     // 50 - 5F
-    {c: '<I>P</I>', ic: 0.103, krn: {'65': -0.0767}, tclass: 'normal'},
-    {c: '<I>Q</I>', d: 1, ic: 0.094, tclass: 'normal'},
-    {c: '<I>R</I>', ic: 0.0387, krn: {'110': -0.0256, '108': -0.0256, '114=
': -0.0256, '117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256,=
 '67': -0.0256, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256=
, '85': -0.0256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0=
256, '84': -0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.05=
11, '97': -0.0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0=
=2E0511, '113': -0.0511}, tclass: 'normal'},
-    {c: '<I>S</I>', ic: 0.12, tclass: 'normal'},
-    {c: '<I>T</I>', ic: 0.133, krn: {'121': -0.0767, '101': -0.0767, '111'=
: -0.0767, '114': -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, t=
class: 'normal'},
-    {c: '<I>U</I>', ic: 0.164, tclass: 'normal'},
-    {c: '<I>V</I>', ic: 0.184, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>W</I>', ic: 0.184, krn: {'65': -0.0767}, tclass: 'normal'},
-    {c: '<I>X</I>', ic: 0.158, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
-    {c: '<I>Y</I>', ic: 0.194, krn: {'101': -0.0767, '111': -0.0767, '114'=
: -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, tclass: 'normal'},
-    {c: '<I>Z</I>', ic: 0.145, tclass: 'normal'},
-    {c: '<I>[</I>', d:.1, ic: 0.188, tclass: 'normal'},
-    {c: '<I>&#x201C;</I>', ic: 0.169, tclass: 'normal'},
-    {c: '<I>]</I>', d:.1, ic: 0.105, tclass: 'normal'},
-    {c: '<I>&#x2C6;</I>', ic: 0.0665, tclass: 'accent'},
-    {c: '<I>&#x2D9;</I>', ic: 0.118, tclass: 'accent'},
+    {c: '<i>P</i>', ic: 0.103, krn: {'65': -0.0767}, tclass: 'normal'},
+    {c: '<i>Q</i>', d: 1, ic: 0.094, tclass: 'normal'},
+    {c: '<i>R</i>', ic: 0.0387, krn: {'110': -0.0256, '108': -0.0256, '114=
': -0.0256, '117': -0.0256, '109': -0.0256, '116': -0.0256, '105': -0.0256,=
 '67': -0.0256, '79': -0.0256, '71': -0.0256, '104': -0.0256, '98': -0.0256=
, '85': -0.0256, '107': -0.0256, '118': -0.0256, '119': -0.0256, '81': -0.0=
256, '84': -0.0767, '89': -0.0767, '86': -0.102, '87': -0.102, '101': -0.05=
11, '97': -0.0511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0=
=2E0511, '113': -0.0511}, tclass: 'normal'},
+    {c: '<i>S</i>', ic: 0.12, tclass: 'normal'},
+    {c: '<i>T</i>', ic: 0.133, krn: {'121': -0.0767, '101': -0.0767, '111'=
: -0.0767, '114': -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, t=
class: 'normal'},
+    {c: '<i>U</i>', ic: 0.164, tclass: 'normal'},
+    {c: '<i>V</i>', ic: 0.184, krn: {'111': -0.0767, '101': -0.0767, '117'=
: -0.0767, '114': -0.0767, '97': -0.0767, '65': -0.102, '79': -0.0256, '67'=
: -0.0256, '71': -0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>W</i>', ic: 0.184, krn: {'65': -0.0767}, tclass: 'normal'},
+    {c: '<i>X</i>', ic: 0.158, krn: {'79': -0.0256, '67': -0.0256, '71': -=
0.0256, '81': -0.0256}, tclass: 'normal'},
+    {c: '<i>Y</i>', ic: 0.194, krn: {'101': -0.0767, '111': -0.0767, '114'=
: -0.0767, '97': -0.0767, '117': -0.0767, '65': -0.0767}, tclass: 'normal'},
+    {c: '<i>Z</i>', ic: 0.145, tclass: 'normal'},
+    {c: '<i>[</i>', d:.1, ic: 0.188, tclass: 'normal'},
+    {c: '<i>&#x201C;</i>', ic: 0.169, tclass: 'normal'},
+    {c: '<i>]</i>', d:.1, ic: 0.105, tclass: 'normal'},
+    {c: '<i>&#x2C6;</i>', ic: 0.0665, tclass: 'accent'},
+    {c: '<i>&#x2D9;</i>', ic: 0.118, tclass: 'accent'},
     // 60 - 6F
-    {c: '<I>&#x2018;</I>', ic: 0.124, lig: {'96': 92}, tclass: 'normal'},
-    {c: '<I>a</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>b</I>', ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, '111'=
: -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.0511}, =
tclass: 'normal'},
-    {c: '<I>c</I>', a:0, ic: 0.0565, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
-    {c: '<I>d</I>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
-    {c: '<I>e</I>', a:0, ic: 0.0751, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
-    {c: '<I>f</I>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.104=
, '41': 0.104, '93': 0.104}, lig: {'105': 12, '102': 11, '108': 13}, tclass=
: 'normal'},
-    {c: '<I>g</I>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
-    {c: '<I>h</I>', ic: 0.0767, tclass: 'normal'},
-    {c: '<I>i</I>', ic: 0.102, tclass: 'normal'},
-    {c: '<I>j</I>', d:1, ic: 0.145, tclass: 'normal'},
-    {c: '<I>k</I>', ic: 0.108, tclass: 'normal'},
-    {c: '<I>l</I>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
-    {c: '<I>m</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>n</I>', a:0, ic: 0.0767, krn: {'39': -0.102}, tclass: 'normal'=
},
-    {c: '<I>o</I>', a:0, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
+    {c: '<i>&#x2018;</i>', ic: 0.124, lig: {'96': 92}, tclass: 'normal'},
+    {c: '<i>a</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>b</i>', ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, '111'=
: -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.0511}, =
tclass: 'normal'},
+    {c: '<i>c</i>', a:0, ic: 0.0565, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
+    {c: '<i>d</i>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
+    {c: '<i>e</i>', a:0, ic: 0.0751, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
+    {c: '<i>f</i>', ic: 0.212, krn: {'39': 0.104, '63': 0.104, '33': 0.104=
, '41': 0.104, '93': 0.104}, lig: {'105': 12, '102': 11, '108': 13}, tclass=
: 'normal'},
+    {c: '<i>g</i>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
+    {c: '<i>h</i>', ic: 0.0767, tclass: 'normal'},
+    {c: '<i>i</i>', ic: 0.102, tclass: 'normal'},
+    {c: '<i>j</i>', d:1, ic: 0.145, tclass: 'normal'},
+    {c: '<i>k</i>', ic: 0.108, tclass: 'normal'},
+    {c: '<i>l</i>', ic: 0.103, krn: {'108': 0.0511}, tclass: 'normal'},
+    {c: '<i>m</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>n</i>', a:0, ic: 0.0767, krn: {'39': -0.102}, tclass: 'normal'=
},
+    {c: '<i>o</i>', a:0, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0511, =
'111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.05=
11}, tclass: 'normal'},
     // 70 - 7F
-    {c: '<I>p</I>', a:0, d:1, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0=
511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': =
-0.0511}, tclass: 'normal'},
-    {c: '<I>q</I>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
-    {c: '<I>r</I>', a:0, ic: 0.108, krn: {'101': -0.0511, '97': -0.0511, '=
111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.051=
1}, tclass: 'normal'},
-    {c: '<I>s</I>', a:0, ic: 0.0821, tclass: 'normal'},
-    {c: '<I>t</I>', ic: 0.0949, tclass: 'normal'},
-    {c: '<I>u</I>', a:0, ic: 0.0767, tclass: 'normal'},
-    {c: '<I>v</I>', a:0, ic: 0.108, tclass: 'normal'},
-    {c: '<I>w</I>', a:0, ic: 0.108, krn: {'108': 0.0511}, tclass: 'normal'=
},
-    {c: '<I>x</I>', a:0, ic: 0.12, tclass: 'normal'},
-    {c: '<I>y</I>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
-    {c: '<I>z</I>', a:0, ic: 0.123, tclass: 'normal'},
-    {c: '<I>&#x2013;</I>', a:.1, ic: 0.0921, lig: {'45': 124}, tclass: 'no=
rmal'},
-    {c: '<I>&#x2014;</I>', a:.1, ic: 0.0921, tclass: 'normal'},
-    {c: '<I>&#x2DD;</I>', ic: 0.122, tclass: 'accent'},
-    {c: '<I>&#x2DC;</I>', ic: 0.116, tclass: 'accent'},
-    {c: '<I>&#xA8;</I>', tclass: 'accent'}
+    {c: '<i>p</i>', a:0, d:1, ic: 0.0631, krn: {'101': -0.0511, '97': -0.0=
511, '111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': =
-0.0511}, tclass: 'normal'},
+    {c: '<i>q</i>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
+    {c: '<i>r</i>', a:0, ic: 0.108, krn: {'101': -0.0511, '97': -0.0511, '=
111': -0.0511, '100': -0.0511, '99': -0.0511, '103': -0.0511, '113': -0.051=
1}, tclass: 'normal'},
+    {c: '<i>s</i>', a:0, ic: 0.0821, tclass: 'normal'},
+    {c: '<i>t</i>', ic: 0.0949, tclass: 'normal'},
+    {c: '<i>u</i>', a:0, ic: 0.0767, tclass: 'normal'},
+    {c: '<i>v</i>', a:0, ic: 0.108, tclass: 'normal'},
+    {c: '<i>w</i>', a:0, ic: 0.108, krn: {'108': 0.0511}, tclass: 'normal'=
},
+    {c: '<i>x</i>', a:0, ic: 0.12, tclass: 'normal'},
+    {c: '<i>y</i>', a:0, d:1, ic: 0.0885, tclass: 'normal'},
+    {c: '<i>z</i>', a:0, ic: 0.123, tclass: 'normal'},
+    {c: '<i>&#x2013;</i>', a:.1, ic: 0.0921, lig: {'45': 124}, tclass: 'no=
rmal'},
+    {c: '<i>&#x2014;</i>', a:.1, ic: 0.0921, tclass: 'normal'},
+    {c: '<i>&#x2DD;</i>', ic: 0.122, tclass: 'accent'},
+    {c: '<i>&#x2DC;</i>', ic: 0.116, tclass: 'accent'},
+    {c: '<i>&#xA8;</i>', tclass: 'accent'}
   ],
  
   cmbx10: [
     // 00 - 0F
-    {c: '<B>&Gamma;</B>', tclass: 'greek'},
-    {c: '<B>&Delta;</B>', tclass: 'greek'},
-    {c: '<B>&Theta;</B>', tclass: 'greek'},
-    {c: '<B>&Lambda;</B>', tclass: 'greek'},
-    {c: '<B>&Xi;</B>', tclass: 'greek'},
-    {c: '<B>&Pi;</B>', tclass: 'greek'},
-    {c: '<B>&Sigma;</B>', tclass: 'greek'},
-    {c: '<B>&Upsilon;</B>', tclass: 'greek'},
-    {c: '<B>&Phi;</B>', tclass: 'greek'},
-    {c: '<B>&Psi;</B>', tclass: 'greek'},
-    {c: '<B>&Omega;</B>', tclass: 'greek'},
-    {c: '<B>ff</B>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0=
=2E0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 14, '108': 15}, tclass: =
'normal'},
-    {c: '<B>fi</B>', tclass: 'normal'},
-    {c: '<B>fl</B>', tclass: 'normal'},
-    {c: '<B>ffi</B>', tclass: 'normal'},
-    {c: '<B>ffl</B>', tclass: 'normal'},
+    {c: '<b>&Gamma;</b>', tclass: 'greek'},
+    {c: '<b>&Delta;</b>', tclass: 'greek'},
+    {c: '<b>&Theta;</b>', tclass: 'greek'},
+    {c: '<b>&Lambda;</b>', tclass: 'greek'},
+    {c: '<b>&Xi;</b>', tclass: 'greek'},
+    {c: '<b>&Pi;</b>', tclass: 'greek'},
+    {c: '<b>&Sigma;</b>', tclass: 'greek'},
+    {c: '<b>&Upsilon;</b>', tclass: 'greek'},
+    {c: '<b>&Phi;</b>', tclass: 'greek'},
+    {c: '<b>&Psi;</b>', tclass: 'greek'},
+    {c: '<b>&Omega;</b>', tclass: 'greek'},
+    {c: '<b>ff</b>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0=
=2E0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 14, '108': 15}, tclass: =
'normal'},
+    {c: '<b>fi</b>', tclass: 'normal'},
+    {c: '<b>fl</b>', tclass: 'normal'},
+    {c: '<b>ffi</b>', tclass: 'normal'},
+    {c: '<b>ffl</b>', tclass: 'normal'},
     // 10 - 1F
-    {c: '<B>&#x131;</B>', a:0, tclass: 'normal'},
-    {c: '<B>j</B>', d:.2, tclass: 'normal'},
-    {c: '<B>&#x60;</B>', tclass: 'accent'},
-    {c: '<B>&#xB4;</B>', tclass: 'accent'},
-    {c: '<B>&#x2C7;</B>', tclass: 'accent'},
-    {c: '<B>&#x2D8;</B>', tclass: 'accent'},
-    {c: '<B>&#x2C9;</B>', tclass: 'accent'},
-    {c: '<B>&#x2DA;</B>', tclass: 'accent'},
-    {c: '<B>?</B>', tclass: 'normal'},
-    {c: '<B>&#xDF;</B>', tclass: 'normal'},
-    {c: '<B>&#xE6;</B>', a:0, tclass: 'normal'},
-    {c: '<B>&#x153;</B>', a:0, tclass: 'normal'},
-    {c: '<B>&#xF8;</B>', tclass: 'normal'},
-    {c: '<B>&#xC6;</B>', tclass: 'normal'},
-    {c: '<B>&#x152;</B>', tclass: 'normal'},
-    {c: '<B>&#xD8;</B>', tclass: 'normal'},
+    {c: '<b>&#x131;</b>', a:0, tclass: 'normal'},
+    {c: '<b>j</b>', d:.2, tclass: 'normal'},
+    {c: '<b>&#x60;</b>', tclass: 'accent'},
+    {c: '<b>&#xB4;</b>', tclass: 'accent'},
+    {c: '<b>&#x2C7;</b>', tclass: 'accent'},
+    {c: '<b>&#x2D8;</b>', tclass: 'accent'},
+    {c: '<b>&#x2C9;</b>', tclass: 'accent'},
+    {c: '<b>&#x2DA;</b>', tclass: 'accent'},
+    {c: '<b>?</b>', tclass: 'normal'},
+    {c: '<b>&#xDF;</b>', tclass: 'normal'},
+    {c: '<b>&#xE6;</b>', a:0, tclass: 'normal'},
+    {c: '<b>&#x153;</b>', a:0, tclass: 'normal'},
+    {c: '<b>&#xF8;</b>', tclass: 'normal'},
+    {c: '<b>&#xC6;</b>', tclass: 'normal'},
+    {c: '<b>&#x152;</b>', tclass: 'normal'},
+    {c: '<b>&#xD8;</b>', tclass: 'normal'},
     // 20 - 2F
-    {c: '<B>?</B>', krn: {'108': -0.278, '76': -0.319}, tclass: 'normal'},
-    {c: '<B>!</B>', lig: {'96': 60}, tclass: 'normal'},
-    {c: '<B>&#x201D;</B>', tclass: 'normal'},
-    {c: '<B>#</B>', tclass: 'normal'},
-    {c: '<B>$</B>', tclass: 'normal'},
-    {c: '<B>%</B>', tclass: 'normal'},
-    {c: '<B>&amp;</B>', tclass: 'normal'},
-    {c: '<B>&#x2019;</B>', krn: {'63': 0.111, '33': 0.111}, lig: {'39': 34=
}, tclass: 'normal'},
-    {c: '<B>(</B>', d:.2, tclass: 'normal'},
-    {c: '<B>)</B>', d:.2, tclass: 'normal'},
-    {c: '<B>*</B>', tclass: 'normal'},
-    {c: '<B>+</B>', a:.1, tclass: 'normal'},
-    {c: '<B>,</B>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
-    {c: '<B>-</B>', a:0, lig: {'45': 123}, tclass: 'normal'},
-    {c: '<B>.</B>', a:-.25, tclass: 'normal'},
-    {c: '<B>/</B>', tclass: 'normal'},
+    {c: '<b>?</b>', krn: {'108': -0.278, '76': -0.319}, tclass: 'normal'},
+    {c: '<b>!</b>', lig: {'96': 60}, tclass: 'normal'},
+    {c: '<b>&#x201D;</b>', tclass: 'normal'},
+    {c: '<b>#</b>', tclass: 'normal'},
+    {c: '<b>$</b>', tclass: 'normal'},
+    {c: '<b>%</b>', tclass: 'normal'},
+    {c: '<b>&amp;</b>', tclass: 'normal'},
+    {c: '<b>&#x2019;</b>', krn: {'63': 0.111, '33': 0.111}, lig: {'39': 34=
}, tclass: 'normal'},
+    {c: '<b>(</b>', d:.2, tclass: 'normal'},
+    {c: '<b>)</b>', d:.2, tclass: 'normal'},
+    {c: '<b>*</b>', tclass: 'normal'},
+    {c: '<b>+</b>', a:.1, tclass: 'normal'},
+    {c: '<b>,</b>', a:-.3, d:.2, w: 0.278, tclass: 'normal'},
+    {c: '<b>-</b>', a:0, lig: {'45': 123}, tclass: 'normal'},
+    {c: '<b>.</b>', a:-.25, tclass: 'normal'},
+    {c: '<b>/</b>', tclass: 'normal'},
     // 30 - 3F
-    {c: '<B>0</B>', tclass: 'normal'},
-    {c: '<B>1</B>', tclass: 'normal'},
-    {c: '<B>2</B>', tclass: 'normal'},
-    {c: '<B>3</B>', tclass: 'normal'},
-    {c: '<B>4</B>', tclass: 'normal'},
-    {c: '<B>5</B>', tclass: 'normal'},
-    {c: '<B>6</B>', tclass: 'normal'},
-    {c: '<B>7</B>', tclass: 'normal'},
-    {c: '<B>8</B>', tclass: 'normal'},
-    {c: '<B>9</B>', tclass: 'normal'},
-    {c: '<B>:</B>', tclass: 'normal'},
-    {c: '<B>;</B>', tclass: 'normal'},
-    {c: '<B>&#xA1;</B>', tclass: 'normal'},
-    {c: '<B>=</B>', a:0, d:-.1, tclass: 'normal'},
-    {c: '<B>&#xBF;</B>', tclass: 'normal'},
-    {c: '<B>?</B>', lig: {'96': 62}, tclass: 'normal'},
+    {c: '<b>0</b>', tclass: 'normal'},
+    {c: '<b>1</b>', tclass: 'normal'},
+    {c: '<b>2</b>', tclass: 'normal'},
+    {c: '<b>3</b>', tclass: 'normal'},
+    {c: '<b>4</b>', tclass: 'normal'},
+    {c: '<b>5</b>', tclass: 'normal'},
+    {c: '<b>6</b>', tclass: 'normal'},
+    {c: '<b>7</b>', tclass: 'normal'},
+    {c: '<b>8</b>', tclass: 'normal'},
+    {c: '<b>9</b>', tclass: 'normal'},
+    {c: '<b>:</b>', tclass: 'normal'},
+    {c: '<b>;</b>', tclass: 'normal'},
+    {c: '<b>&#xA1;</b>', tclass: 'normal'},
+    {c: '<b>=</b>', a:0, d:-.1, tclass: 'normal'},
+    {c: '<b>&#xBF;</b>', tclass: 'normal'},
+    {c: '<b>?</b>', lig: {'96': 62}, tclass: 'normal'},
     // 40 - 4F
-    {c: '<B>@</B>', tclass: 'normal'},
-    {c: '<B>A</B>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
-    {c: '<B>B</B>', tclass: 'normal'},
-    {c: '<B>C</B>', tclass: 'normal'},
-    {c: '<B>D</B>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
-    {c: '<B>E</B>', tclass: 'normal'},
-    {c: '<B>F</B>', krn: {'111': -0.0833, '101': -0.0833, '117': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67': -0.0278, =
'71': -0.0278, '81': -0.0278}, tclass: 'normal'},
-    {c: '<B>G</B>', tclass: 'normal'},
-    {c: '<B>H</B>', tclass: 'normal'},
-    {c: '<B>I</B>', krn: {'73': 0.0278}, tclass: 'normal'},
-    {c: '<B>J</B>', tclass: 'normal'},
-    {c: '<B>K</B>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
-    {c: '<B>L</B>', krn: {'84': -0.0833, '89': -0.0833, '86': -0.111, '87'=
: -0.111}, tclass: 'normal'},
-    {c: '<B>M</B>', tclass: 'normal'},
-    {c: '<B>N</B>', tclass: 'normal'},
-    {c: '<B>O</B>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
+    {c: '<b>@</b>', tclass: 'normal'},
+    {c: '<b>A</b>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
+    {c: '<b>B</b>', tclass: 'normal'},
+    {c: '<b>C</b>', tclass: 'normal'},
+    {c: '<b>D</b>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
+    {c: '<b>E</b>', tclass: 'normal'},
+    {c: '<b>F</b>', krn: {'111': -0.0833, '101': -0.0833, '117': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67': -0.0278, =
'71': -0.0278, '81': -0.0278}, tclass: 'normal'},
+    {c: '<b>G</b>', tclass: 'normal'},
+    {c: '<b>H</b>', tclass: 'normal'},
+    {c: '<b>I</b>', krn: {'73': 0.0278}, tclass: 'normal'},
+    {c: '<b>J</b>', tclass: 'normal'},
+    {c: '<b>K</b>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
+    {c: '<b>L</b>', krn: {'84': -0.0833, '89': -0.0833, '86': -0.111, '87'=
: -0.111}, tclass: 'normal'},
+    {c: '<b>M</b>', tclass: 'normal'},
+    {c: '<b>N</b>', tclass: 'normal'},
+    {c: '<b>O</b>', krn: {'88': -0.0278, '87': -0.0278, '65': -0.0278, '86=
': -0.0278, '89': -0.0278}, tclass: 'normal'},
     // 50 - 5F
-    {c: '<B>P</B>', krn: {'65': -0.0833, '111': -0.0278, '101': -0.0278, '=
97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
-    {c: '<B>Q</B>', d: 1, tclass: 'normal'},
-    {c: '<B>R</B>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
-    {c: '<B>S</B>', tclass: 'normal'},
-    {c: '<B>T</B>', krn: {'121': -0.0278, '101': -0.0833, '111': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'nor=
mal'},
-    {c: '<B>U</B>', tclass: 'normal'},
-    {c: '<B>V</B>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
-    {c: '<B>W</B>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
-    {c: '<B>X</B>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
-    {c: '<B>Y</B>', ic: 0.025, krn: {'101': -0.0833, '111': -0.0833, '114'=
: -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'normal'},
-    {c: '<B>Z</B>', tclass: 'normal'},
-    {c: '<B>[</B>', d:.1, tclass: 'normal'},
-    {c: '<B>&#x201C;</B>', tclass: 'normal'},
-    {c: '<B>]</B>', d:.1, tclass: 'normal'},
-    {c: '<B>&#x2C6;</B>', tclass: 'accent'},
-    {c: '<B>&#x2D9;</B>', tclass: 'accent'},
+    {c: '<b>P</b>', krn: {'65': -0.0833, '111': -0.0278, '101': -0.0278, '=
97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
+    {c: '<b>Q</b>', d: 1, tclass: 'normal'},
+    {c: '<b>R</b>', krn: {'116': -0.0278, '67': -0.0278, '79': -0.0278, '7=
1': -0.0278, '85': -0.0278, '81': -0.0278, '84': -0.0833, '89': -0.0833, '8=
6': -0.111, '87': -0.111}, tclass: 'normal'},
+    {c: '<b>S</b>', tclass: 'normal'},
+    {c: '<b>T</b>', krn: {'121': -0.0278, '101': -0.0833, '111': -0.0833, =
'114': -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'nor=
mal'},
+    {c: '<b>U</b>', tclass: 'normal'},
+    {c: '<b>V</b>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
+    {c: '<b>W</b>', ic: 0.0139, krn: {'111': -0.0833, '101': -0.0833, '117=
': -0.0833, '114': -0.0833, '97': -0.0833, '65': -0.111, '79': -0.0278, '67=
': -0.0278, '71': -0.0278, '81': -0.0278}, tclass: 'normal'},
+    {c: '<b>X</b>', krn: {'79': -0.0278, '67': -0.0278, '71': -0.0278, '81=
': -0.0278}, tclass: 'normal'},
+    {c: '<b>Y</b>', ic: 0.025, krn: {'101': -0.0833, '111': -0.0833, '114'=
: -0.0833, '97': -0.0833, '65': -0.0833, '117': -0.0833}, tclass: 'normal'},
+    {c: '<b>Z</b>', tclass: 'normal'},
+    {c: '<b>[</b>', d:.1, tclass: 'normal'},
+    {c: '<b>&#x201C;</b>', tclass: 'normal'},
+    {c: '<b>]</b>', d:.1, tclass: 'normal'},
+    {c: '<b>&#x2C6;</b>', tclass: 'accent'},
+    {c: '<b>&#x2D9;</b>', tclass: 'accent'},
     // 60 - 6F
-    {c: '<B>&#x2018;</B>', lig: {'96': 92}, tclass: 'normal'},
-    {c: '<B>a</B>', a:0, krn: {'118': -0.0278, '106': 0.0556, '121': -0.02=
78, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>b</B>', krn: {'101': 0.0278, '111': 0.0278, '120': -0.0278, '1=
00': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.0556, '1=
21': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>c</B>', a:0, krn: {'104': -0.0278, '107': -0.0278}, tclass: 'n=
ormal'},
-    {c: '<B>d</B>', tclass: 'normal'},
-    {c: '<B>e</B>', a:0, tclass: 'normal'},
-    {c: '<B>f</B>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0.=
0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 12, '102': 11, '108': 13}, =
tclass: 'normal'},
-    {c: '<B>g</B>', a:0, d:1, ic: 0.0139, krn: {'106': 0.0278}, tclass: 'n=
ormal'},
-    {c: '<B>h</B>', krn: {'116': -0.0278, '117': -0.0278, '98': -0.0278, '=
121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>i</B>', tclass: 'normal'},
-    {c: '<B>j</B>', d:1, tclass: 'normal'},
-    {c: '<B>k</B>', krn: {'97': -0.0556, '101': -0.0278, '97': -0.0278, '1=
11': -0.0278, '99': -0.0278}, tclass: 'normal'},
-    {c: '<B>l</B>', tclass: 'normal'},
-    {c: '<B>m</B>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>n</B>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>o</B>', a:0, krn: {'101': 0.0278, '111': 0.0278, '120': -0.027=
8, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.055=
6, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>&#x2018;</b>', lig: {'96': 92}, tclass: 'normal'},
+    {c: '<b>a</b>', a:0, krn: {'118': -0.0278, '106': 0.0556, '121': -0.02=
78, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>b</b>', krn: {'101': 0.0278, '111': 0.0278, '120': -0.0278, '1=
00': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.0556, '1=
21': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>c</b>', a:0, krn: {'104': -0.0278, '107': -0.0278}, tclass: 'n=
ormal'},
+    {c: '<b>d</b>', tclass: 'normal'},
+    {c: '<b>e</b>', a:0, tclass: 'normal'},
+    {c: '<b>f</b>', ic: 0.0778, krn: {'39': 0.0778, '63': 0.0778, '33': 0.=
0778, '41': 0.0778, '93': 0.0778}, lig: {'105': 12, '102': 11, '108': 13}, =
tclass: 'normal'},
+    {c: '<b>g</b>', a:0, d:1, ic: 0.0139, krn: {'106': 0.0278}, tclass: 'n=
ormal'},
+    {c: '<b>h</b>', krn: {'116': -0.0278, '117': -0.0278, '98': -0.0278, '=
121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>I</b>', tclass: 'normal'},
+    {c: '<b>j</b>', d:1, tclass: 'normal'},
+    {c: '<b>k</b>', krn: {'97': -0.0556, '101': -0.0278, '97': -0.0278, '1=
11': -0.0278, '99': -0.0278}, tclass: 'normal'},
+    {c: '<b>l</b>', tclass: 'normal'},
+    {c: '<b>m</b>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>n</b>', a:0, krn: {'116': -0.0278, '117': -0.0278, '98': -0.02=
78, '121': -0.0278, '118': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>o</b>', a:0, krn: {'101': 0.0278, '111': 0.0278, '120': -0.027=
8, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': 0.055=
6, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
     // 70 - 7F
-    {c: '<B>p</B>', a:0, d:1, krn: {'101': 0.0278, '111': 0.0278, '120': -=
0.0278, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': =
0.0556, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
-    {c: '<B>q</B>', a:0, d:1, tclass: 'normal'},
-    {c: '<B>r</B>', a:0, tclass: 'normal'},
-    {c: '<B>s</B>', a:0, tclass: 'normal'},
-    {c: '<B>t</B>', krn: {'121': -0.0278, '119': -0.0278}, tclass: 'normal=
'},
-    {c: '<B>u</B>', a:0, krn: {'119': -0.0278}, tclass: 'normal'},
-    {c: '<B>v</B>', a:0, ic: 0.0139, krn: {'97': -0.0556, '101': -0.0278, =
'97': -0.0278, '111': -0.0278, '99': -0.0278}, tclass: 'normal'},
-    {c: '<B>w</B>', a:0, ic: 0.0139, krn: {'101': -0.0278, '97': -0.0278, =
'111': -0.0278, '99': -0.0278}, tclass: 'normal'},
-    {c: '<B>x</B>', a:0, tclass: 'normal'},
-    {c: '<B>y</B>', a:0, d:1, ic: 0.0139, krn: {'111': -0.0278, '101': -0.=
0278, '97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
-    {c: '<B>z</B>', a:0, tclass: 'normal'},
-    {c: '<B>&#x2013;</B>', a:.1, ic: 0.0278, lig: {'45': 124}, tclass: 'no=
rmal'},
-    {c: '<B>&#x2014;</B>', a:.1, ic: 0.0278, tclass: 'normal'},
-    {c: '<B>&#x2DD;</B>', tclass: 'accent'},
-    {c: '<B>&#x2DC;</B>', tclass: 'accent'},
-    {c: '<B>&#xA8;</B>', tclass: 'accent'}
+    {c: '<b>p</b>', a:0, d:1, krn: {'101': 0.0278, '111': 0.0278, '120': -=
0.0278, '100': 0.0278, '99': 0.0278, '113': 0.0278, '118': -0.0278, '106': =
0.0556, '121': -0.0278, '119': -0.0278}, tclass: 'normal'},
+    {c: '<b>q</b>', a:0, d:1, tclass: 'normal'},
+    {c: '<b>r</b>', a:0, tclass: 'normal'},
+    {c: '<b>s</b>', a:0, tclass: 'normal'},
+    {c: '<b>t</b>', krn: {'121': -0.0278, '119': -0.0278}, tclass: 'normal=
'},
+    {c: '<b>u</b>', a:0, krn: {'119': -0.0278}, tclass: 'normal'},
+    {c: '<b>v</b>', a:0, ic: 0.0139, krn: {'97': -0.0556, '101': -0.0278, =
'97': -0.0278, '111': -0.0278, '99': -0.0278}, tclass: 'normal'},
+    {c: '<b>w</b>', a:0, ic: 0.0139, krn: {'101': -0.0278, '97': -0.0278, =
'111': -0.0278, '99': -0.0278}, tclass: 'normal'},
+    {c: '<b>x</b>', a:0, tclass: 'normal'},
+    {c: '<b>y</b>', a:0, d:1, ic: 0.0139, krn: {'111': -0.0278, '101': -0.=
0278, '97': -0.0278, '46': -0.0833, '44': -0.0833}, tclass: 'normal'},
+    {c: '<b>z</b>', a:0, tclass: 'normal'},
+    {c: '<b>&#x2013;</b>', a:.1, ic: 0.0278, lig: {'45': 124}, tclass: 'no=
rmal'},
+    {c: '<b>&#x2014;</b>', a:.1, ic: 0.0278, tclass: 'normal'},
+    {c: '<b>&#x2DD;</b>', tclass: 'accent'},
+    {c: '<b>&#x2DC;</b>', tclass: 'accent'},
+    {c: '<b>&#xA8;</b>', tclass: 'accent'}
   ]
 });

@@ -896,8 +896,8 @@
       var ph = Math.round(h*jsMath.em);
       if (h > jsMath.hd) {
         box.bd = jsMath.EmBoxFor(jsMath.HTML.Class(c.tclass,c.c)
-                   + '<IMG SRC="'+jsMath.blank+'" STYLE="'
-                   + 'width: 1; height: '+ph+'px">').h - h;
+                   + '<img src="'+jsMath.blank+'" style="'
+                   + 'width: 1px; height: '+ph+'px">').h - h;
         box.bh = h - box.bd;
       }
       c.bh = box.bh/scale;
@@ -907,7 +907,7 @@
       // hack to avoid Font changing back to the default
       // font when a unicode reference is not followed
       // by a letter or number
-      box.html += '<SPAN STYLE="display: none">x</SPAN>'
+      box.html += '<span style="display: none">x</span>'
     }
     return box;
   }
diff -ur jsMath-2.3b/jsMath.js jsMath-2.3b-lowercase/jsMath.js
--- jsMath-2.3b/jsMath.js	2005-10-21 19:26:22.000000000 -0700
+++ jsMath-2.3b-lowercase/jsMath.js	2005-10-30 11:14:09.000000000 -0800
@@ -131,7 +131,7 @@
    *  Get the width and height (in pixels) of an HTML string
    */
   BBoxFor: function (s) {
-    this.hidden.innerHTML = '<SPAN CLASS="jsM_scale">'+s+'</SPAN>';
+    this.hidden.innerHTML = '<span class="jsM_scale">'+s+'</span>';
     var bbox = {w: this.hidden.offsetWidth, h: this.hidden.offsetHeight};
     this.hidden.innerHTML = '';    // avoid MSIE bug on the Mac
     return bbox;
@@ -150,7 +150,7 @@
    */
   EmBoxForItalics: function (s) {
     var bbox = this.BBoxFor(s);
-    if (s.match(/<I>|CLASS="icm/i)) {
+    if (s.match(/<i>|class="icm/i)) {
       bbox.w = this.BBoxFor(s+jsMath.Browser.italicString).w
                 - jsMath.Browser.italicCorrection;
     }
@@ -167,12 +167,12 @@
         alert("It looks like jsMath failed to set up properly.");
       } else {
         alert("You must call jsMath.Setup.Body() explicitly when jsMath is=
" +
-              "loaded as part of the <HEAD> section");
+              "loaded as part of the <head> section");
       }
       jsMath.Setup.Init(); // may fail to load fallback files properly
     }
     if (em) {this.em = em}
-       else {this.em = this.BBoxFor('<DIV STYLE="width: 10em; height: =
1em"></DIV>').w/10}
+       else {this.em = this.BBoxFor('<div style="width: 10em; height: =
1em"></div>').w/10}
     if (jsMath.Browser.italicString)
       jsMath.Browser.italicCorrection = jsMath.BBoxFor(jsMath.Browser.it=
alicString).w;
     if (jsMath.Browser.hiddenSpace != '') {
@@ -184,14 +184,14 @@
                       jsMath.Browser.hiddenSpace).w/5;
     }
     var h = this.BBoxFor('x').h;    // Line height and depth to baseline
-    var d = this.BBoxFor('x<IMG SRC="'+jsMath.blank+'" HEIGHT="'+(h*=
jsMath.Browser.imgScale)+'" WIDTH="1">').h - h;
+    var d = this.BBoxFor('x<img src="'+jsMath.blank+'" height="'+(h*=
jsMath.Browser.imgScale)+'em" width="1em" />').h - h;
     this.h = (h-d)/this.em; this.d = d/this.em;
     this.hd = this.h + this.d;
     this.ph = h-d; this.pd = d;
    
     this.Setup.TeXfonts();
    
-    var x_height = this.EmBoxFor('<SPAN CLASS="cmr10">M</SPAN>').w/2;
+    var x_height = this.EmBoxFor('<span class="cmr10">M</span>').w/2;
     this.TeX.M_height = x_height*(26/14);
     this.TeX.h = this.h; this.TeX.d = this.d; this.TeX.hd = this.hd;
     // factor for \big and its brethren
@@ -210,7 +210,7 @@
    *  Get the em size and if it has changed, reinitialize the sizes
    */
   ReInit: function () {
-    var em = this.BBoxFor('<SPAN STYLE="width: 10em; height: 1em"></SP=
AN>').w/10;
+    var em = this.BBoxFor('<span style="width: 10em; height: 1em"></sp=
an>').w/10;
     if (em != this.em) {this.Init(em)}
   },
  
@@ -269,14 +269,14 @@
       if (!document.body.hasChildNodes) {document.body.appendChild(div)}
         else {document.body.insertBefore(div,document.body.firstChild)}
     } catch (err) {
-      var html = '<DIV ID="jsMath.'+id+'"';
+      var html = '<div id="jsMath.'+id+'"';
       for (var id in attributes) {html += ' '+id+'="'+attributes[id]+'=
"'}
       if (styles) {
-        html += ' STYLE="';
+        html += ' style="';
         for (var id in styles) {html += ' '+id+':'+styles[id]+';'}
         html += '"';
       }
-      html += '</DIV>';
+      html += '</div>';
       if (!document.body.insertAdjacentHTML) {document.write(html)}
         else {document.body.insertAdjacentHTML('AfterBegin',html)}
       div = jsMath.Element(id);
@@ -289,11 +289,11 @@
    */
   Script: function (file) {
     if (!file.match('^([a-zA-Z]+:/)?/')) {file = jsMath.root + file}
-    document.write('<SCRIPT SRC="'+file+'"></SCRIPT>');
+    document.write('<script src="'+file+'"></script>');
   },
  
   /*
-   *  Use a hidden <DIV> for measuring the BBoxes of things
+   *  Use a hidden <div> for measuring the BBoxes of things
    */
   HTML: function () {
     jsMath.hidden = this.TopHTML("Hidden",{'class':"normal"},{
@@ -307,7 +307,7 @@
    *  the other .js and .gif files)
    */
   Source: function () {
-    var script = document.getElementsByTagName('SCRIPT');
+    var script = document.getElementsByTagName('script');
     if (script) {
       for (var i = 0; i < script.length; i++) {
         var src = script[i].src;
@@ -369,10 +369,10 @@
    */
   TeXfont: function (name) {
     var font = jsMath.TeX[name];
-    var WH = jsMath.EmBoxFor('<SPAN CLASS="'+name+'">'+font[65].c+'</S=
PAN>');
+    var WH = jsMath.EmBoxFor('<span class="'+name+'">'+font[65].c+'</s=
pan>');
     font.hd = WH.h;
-    font.d = jsMath.EmBoxFor('<SPAN CLASS="'+name+'">'+ font[65].c +
-      '<IMG SRC="'+jsMath.blank+'" STYLE="height:'+(font.hd*jsMath.Bro=
wser.imgScale)+'em; width:1"></SPAN>').h
+    font.d = jsMath.EmBoxFor('<span class="'+name+'">'+ font[65].c +
+      '<img src="'+jsMath.blank+'" style="height:'+(font.hd*jsMath.Bro=
wser.imgScale)+'em; width:1em" /></span>').h
       - font.hd;
     font.h = font.hd - font.d;
     font.dh = .05;
@@ -413,9 +413,9 @@
       styles = jsMath.styles;
       styles['.jsM_scale'] = 'font-size:'+jsMath.Controls.cookie.scale+'=
%';
     }
-    document.writeln('<STYLE TYPE="text/css" ID="jsMath.styles">');
+    document.writeln('<style type="text/css" id="jsMath.styles">');
     for (var id in styles) {document.writeln('  '+id+'  {'+styles[id]+'}')}
-    document.writeln('</STYLE>');
+    document.writeln('</style>');
   },
  
   /*
@@ -437,7 +437,7 @@
     jsMath.Setup.User();  //  do user-specific initialization

     //make sure browser-specific loads are done before this
-    document.write('<SCRIPT>jsMath.Font.Check()</SCRIPT>');
+    document.write('<script>jsMath.Font.Check()</script>');
    
     this.inited = 1;
   },
@@ -515,13 +515,13 @@
   valignBug: 0,               // Konqueror doesn't nest vertical-align

   /*
-   *  Determine if the "top" of a <SPAN> is always at the same height
+   *  Determine if the "top" of a <span> is always at the same height
    *  or varies with the height of the rest of the line (MSIE).
    */
   TestSpanHeight: function () {
-    jsMath.hidden.innerHTML = '<SPAN><IMG SRC="'+jsMath.blank+'" STYLE=
="height: 2em"></SPAN>';
-    var span = jsMath.hidden.getElementsByTagName('SPAN')[0];
-    var img  = jsMath.hidden.getElementsByTagName('IMG')[0];
+    jsMath.hidden.innerHTML = '<span><img src="'+jsMath.blank+'" style=
="height: 2em" /></span>';
+    var span = jsMath.hidden.getElementsByTagName('span')[0];
+    var img  = jsMath.hidden.getElementsByTagName('img')[0];
     this.spanHeightVaries = (span.offsetHeight == img.offsetHeight);
     jsMath.hidden.innerHTML = '';
   },
@@ -532,9 +532,9 @@
    *  returned by getElementByName.
    */
   TestRenameOK: function () {
-    jsMath.hidden.innerHTML = '<SPAN ID="jsMath.test"></SPAN>';
+    jsMath.hidden.innerHTML = '<span id="jsMath.test"></span>';
     var test = document.getElementById('jsMath.test');
-    test.setAttribute('NAME','jsMath_test');
+    test.setAttribute('name','jsMath_test');
     this.renameOK = (document.getElementsByName('jsMath_test').length > =
0);
     jsMath.hidden.innerHTML = '';
   },
@@ -582,23 +582,23 @@
         jsMath.Update.TeXfonts({
           cmr10:  {'10': {c: '&Omega;', tclass: 'normal'}},
           cmmi10: {
-	     '10':  {c: '<I>&Omega;</I>', tclass: 'normal'},
-	     '126': {c: '&#x7E;<SPAN STYLE="margin-left:.1em"></SPAN>'}
+	     '10':  {c: '<i>&Omega;</i>', tclass: 'normal'},
+	     '126': {c: '&#x7E;<span style="margin-left:.1em"></span>'}
 	  },
           cmsy10: {
 	    '10': {c: '&#x2297;', tclass: 'arial'},
-	    '55': {c: '<SPAN STYLE="margin-right:-.54em">7</SPAN>'}
+	    '55': {c: '<span style="Margin-right:-.54em">7</span>'}
 	  },
-          cmex10: {'10': {c: '<SPAN STYLE="font-size: 67%">D</SPAN>'}},
-          cmti10: {'10': {c: '<I>&Omega;</I>', tclass: 'normal'}},
-          cmbx10: {'10': {c: '<B>&Omega;</B>', tclass: 'normal'}}
+          cmex10: {'10': {c: '<span style="font-size: 67%">D</span>'}},
+          cmti10: {'10': {c: '<i>&Omega;</i>', tclass: 'normal'}},
+          cmbx10: {'10': {c: '<b>&Omega;</b>', tclass: 'normal'}}
         });
         this.allowAbsoluteDelim = 1;
 	this.separateSkips = 1;
         this.msieFontBug = 1; this.msieIntegralBug = 1;
 	this.msieAlphaBug = 1; this.alphaPrintBug = 1;
         this.msieCenterBugFix = 'position:relative; ';
-        this.msieSpaceFix = '<IMG SRC="'+jsMath.blank+'" CLASS="math=
HD">';
+        this.msieSpaceFix = '<img src="'+jsMath.blank+'" class="math=
HD" />';
         this.msieInlineBlockFix = ' display: inline-block;';
         jsMath.Macro('joinrel','\\mathrel{\\kern-5mu}'),
         jsMath.styles['.arial'] = "font-family: 'Arial unicode MS'";
@@ -614,12 +614,12 @@
           this.imgScale *= screen.logicalXDPI/screen.deviceXDPI;
           jsMath.Controls.cookie.alpha = 0;
         }
-        this.italicString = '<I>x</I>';
+        this.italicString = '<i>x</i>';
         jsMath.EmBoxFor = jsMath.EmBoxForItalics;
       } else if (navigator.platform == 'MacPPC') {
         this.msieAbsoluteBug = 1; this.msieButtonBug = 1;
         jsMath.Setup.Script('jsMath-msie-mac.js');
-        jsMath.Parser.prototype.macros.angle = ['Replace','ord','<FONT F=
ACE="Symbol">&#x8B;</FONT>','normal'];
+        jsMath.Parser.prototype.macros.angle = ['Replace','ord','<font f=
ace="Symbol">&#x8B;</font>','normal'];
         jsMath.styles['.jsM_panel'] = 'width:25em; ' + jsMath.styles['.j=
sM_panel'].replace(/width:auto/,"");
         jsMath.styles['.jsM_button'] = 'width:1px; ' + jsMath.styles['.j=
sM_button'].replace(/width:auto/,"");
       }
@@ -636,11 +636,11 @@
       if (navigator.platform == 'MacPPC') {
         jsMath.Update.TeXfonts({
           cmr10:  {'10': {c: '&Omega;', tclass: 'normal'}},
-          cmmi10: {'10': {c: '<I>&Omega;</I>', tclass: 'normal'}},
+          cmmi10: {'10': {c: '<i>&Omega;</i>', tclass: 'normal'}},
           cmsy10: {'10': {c: '&otimes;', tclass: 'normal'}},
-          cmex10: {'10': {c: '<SPAN STYLE="font-size: 67%">D</SPAN>'}},
-          cmti10: {'10': {c: '<I>&Omega;</I>', tclass: 'normal'}},
-          cmbx10: {'10': {c: '<B>&Omega;</B>', tclass: 'normal'}}
+          cmex10: {'10': {c: '<span style="font-size: 67%">D</span>'}},
+          cmti10: {'10': {c: '<i>&Omega;</i>', tclass: 'normal'}},
+          cmbx10: {'10': {c: '<b>&Omega;</b>', tclass: 'normal'}}
         });
       } else {
         jsMath.Setup.Script('jsMath-mozilla.js');
@@ -679,7 +679,7 @@
           '20': {c: '&#x2C7;', tclass: 'normal'}
         },
         cmmi10: {
-          '10': {c: '<I>&Omega;</I>', tclass: 'normal'},
+          '10': {c: '<i>&Omega;</i>', tclass: 'normal'},
           '20': {c: '&kappa;', tclass: 'normal'}
         },
         cmsy10: {
@@ -687,16 +687,16 @@
           '20': {c: '&#x2264;', tclass: 'normal'}
         },
         cmex10: {
-          '10': {c: '<SPAN STYLE="font-size: 67%">D</SPAN>'},
-          '20': {c: '<SPAN STYLE="font-size: 82%">"</SPAN>'}
+          '10': {c: '<span style="font-size: 67%">D</span>'},
+          '20': {c: '<span style="font-size: 82%">"</span>'}
         },
         cmti10: {
-          '10': {c: '<I>&Omega;</I>', tclass: 'normal'},
-          '20': {c: '<I>&#x2C7;</I>', tclass: 'normal'}
+          '10': {c: '<i>&Omega;</i>', tclass: 'normal'},
+          '20': {c: '<i>&#x2C7;</i>', tclass: 'normal'}
         },
         cmbx10: {
-          '10': {c: '<B>&Omega;</B>', tclass: 'normal'},
-          '20': {c: '<B>&#x2C7;</B>', tclass: 'normal'}
+          '10': {c: '<b>&Omega;</b>', tclass: 'normal'},
+          '20': {c: '<b>&#x2C7;</b>', tclass: 'normal'}
         }
       });
       this.allowAbsolute = 0;
@@ -731,9 +731,9 @@
         cmr10:  {'20': {c: '&#x2C7;', tclass: 'normal'}},
         cmmi10: {'20': {c: '&kappa;', tclass: 'normal'}},
         cmsy10: {'20': {c: '&#x2264;', tclass: 'normal'}},
-        cmex10: {'20': {c: '<SPAN STYLE="font-size: 84%">"</SPAN>'}},
-        cmti10: {'20': {c: '<I>&#x2C7;</I>', tclass: 'normal'}},
-        cmbx10: {'20': {c: '<B>&#x2C7;</B>', tclass: 'normal'}}
+        cmex10: {'20': {c: '<span style="font-size: 84%">"</span>'}},
+        cmti10: {'20': {c: '<i>&#x2C7;</i>', tclass: 'normal'}},
+        cmbx10: {'20': {c: '<b>&#x2C7;</b>', tclass: 'normal'}}
       });
       this.allowAbsolute = 0;
       this.allowAbsoluteDelim = 0;
@@ -761,13 +761,13 @@

   // the HTML for the missing font message
   message:   
-    '<B>No TeX fonts found</B> -- using image fonts instead.<BR>\n'
-      + 'These may be slow and might not print well.<BR>\n'
+    '<b>No TeX fonts found</b> -- using image fonts instead.<br/>\n'
+      + 'These may be slow and might not print well.<br/>\n'
       + 'Use the jsMath control panel to get additional information.',
      
   extra_message:
-    'Extra TeX fonts not found: <B><SPAN ID="jsMath.ExtraFonts"></SPAN><=
/B><BR>'
-      + 'Using image fonts instead.  This may be slow and might not print =
well.<BR>\n'
+    'Extra TeX fonts not found: <b><span id="jsMath.ExtraFonts"></span><=
/b><br/>'
+      + 'Using image fonts instead.  This may be slow and might not print =
well.<br/>\n'
       + 'Use the jsMath control panel to get additional information.',
  
   /*
@@ -777,16 +777,16 @@
    */
   Test1: function (name,n,factor) {
     if (n == null) {n = 124}; if (factor == null) {factor = 2}
-    var wh1 = jsMath.BBoxFor('<SPAN STYLE="font-family: '+name+', seri=
f">'+jsMath.TeX[name][n].c+'</SPAN>');
-    var wh2 = jsMath.BBoxFor('<SPAN STYLE="font-family: serif">'+jsMat=
h.TeX[name][n].c+'</SPAN>');
+    var wh1 = jsMath.BBoxFor('<span style="font-family: '+name+', seri=
f">'+jsMath.TeX[name][n].c+'</span>');
+    var wh2 = jsMath.BBoxFor('<span style="font-family: serif">'+jsMat=
h.TeX[name][n].c+'</span>');
     //alert([wh1.w,wh2.w,wh1.h,factor*wh2.w]);
     return (wh1.w > factor*wh2.w && wh1.h != 0);
   },

   Test2: function (name,n,factor) {
     if (n == null) {n = 124}; if (factor == null) {factor = 2}
-    var wh1 = jsMath.BBoxFor('<SPAN STYLE="font-family: '+name+', seri=
f">'+jsMath.TeX[name][n].c+'</SPAN>');
-    var wh2 = jsMath.BBoxFor('<SPAN STYLE="font-family: serif">'+jsMat=
h.TeX[name][n].c+'</SPAN>');
+    var wh1 = jsMath.BBoxFor('<span style="font-family: '+name+', seri=
f">'+jsMath.TeX[name][n].c+'</span>');
+    var wh2 = jsMath.BBoxFor('<span style="font-family: serif">'+jsMat=
h.TeX[name][n].c+'</span>');
     //alert([wh2.w,wh1.w,wh1.h,factor*wh1.w]);
     return (wh2.w > factor*wh1.w && wh1.h != 0);
   },
@@ -806,7 +806,7 @@
    */
   Check: function () {
     var cookie = jsMath.Controls.cookie;
-    var wh = jsMath.BBoxFor('<SPAN STYLE="font-family: cmex10">'+jsMat=
h.TeX.cmex10[1].c+'</SPAN>');
+    var wh = jsMath.BBoxFor('<span style="font-family: cmex10">'+jsMat=
h.TeX.cmex10[1].c+'</span>');
     jsMath.nofonts = ((wh.w*3 > wh.h || wh.h == 0) && !this.Test1('c=
mr10'));
     if (jsMath.nofonts) {
       if (cookie.autofont || cookie.font == 'tex') {
@@ -843,7 +843,7 @@
    *  The message for when no TeX fonts.  You can eliminate this message
    *  by including
    * 
-   *      <SCRIPT>jsMath = {Font: {Message: function () {}}}</SCRIPT>
+   *      <script>jsMath = {Font: {Message: function () {}}}</script>
    *
    *  in your HTML file, before loading jsMath.js, if you want.  But this
    *  means the user may not know that he or she can get a better version
@@ -853,15 +853,15 @@
     if(jsMath.Element("Warning")) return;
     var div = jsMath.Setup.TopHTML("Warning",{'class':'jsM_Warning'},{});
     div.innerHTML =
-      '<CENTER><TABLE><TR><TD>'
-      + '<DIV CLASS="jsM_noFont">' + message
-      + '<DIV STYLE="text-align:left"><SPAN STYLE="float:left; margin:=
 8px 0px 0px 20px">'
-      + '<A HREF="javascript:jsMath.Controls.Panel()" CLASS="jsM_fontL=
ink">jsMath Control Panel</A>'
-      + '</SPAN><SPAN STYLE="margin: 8px 20px 0px 0px; float:right">'
-      + '<A HREF="javascript:jsMath.Font.HideMessage()" CLASS="jsM_fon=
tLink">Hide this Message</A>'
-      + '</SPAN></DIV><BR CLEAR="ALL"></DIV>'
-      + '<DIV STYLE="width:22em; height:1px"></DIV>'
-      + '</TD></TR></TABLE></CENTER><HR>';
+      '<center><table><tr><td>'
+      + '<div class="jsM_noFont">' + message
+      + '<div style="text-align:left"><span style="float:left; margin:=
 8px 0px 0px 20px">'
+      + '<a href="javascript:jsMath.Controls.Panel()" class="jsM_fontL=
ink">jsMath Control Panel</a>'
+      + '</span><span style="margin: 8px 20px 0px 0px; float:right">'
+      + '<a href="javascript:jsMath.Font.HideMessage()" class="jsM_fon=
tLink">Hide this Message</a>'
+      + '</span></div><br clear="all"/></div>'
+      + '<div style="width:22em; height:1px"></div>'
+      + '</td></tr></table></center><hr/>';
   },
  
   HideMessage: function () {
@@ -972,9 +972,9 @@
   Button: function () {
     var button = jsMath.Setup.TopHTML("jsMath",{'class':'jsM_button'},{}=
);
     button.innerHTML =
-      '<A HREF="javascript:jsMath.Controls.Panel()" '+
-         'STYLE="text-decoration:inherit; color:inherit">' +
-      '<SPAN TITLE="Open jsMath Control Panel">jsMath</SPAN></A>'
+      '<a href="javascript:jsMath.Controls.Panel()" '+
+         'style="text-decoration:inherit; color:inherit">' +
+      '<span title="Open jsMath Control Panel">jsMath</span></a>'
     if (!this.cookie.button) {button.style.display = "none"}
   },
  
@@ -997,10 +997,10 @@
       else {setTimeout("jsMath.Controls.Button()",500)}
     if (jsMath.Browser.safariIFRAMEbug) {
       document.write(
-         '<IFRAME SRC="'+jsMath.root+'/jsMath-controls.html" '
-         + 'ID="jsMath.Frame" SCROLLING="no" '
-         + 'STYLE="visibility:hidden; position:absolute; width:1em; heig=
ht:1em;">'
-         + '</IFRAME>\n');
+         '<iframe src="'+jsMath.root+'/jsMath-controls.html" '
+         + 'id="jsMath.Frame" scrolling="no" '
+         + 'style="visibility:hidden; position:absolute; width:1em; heig=
ht:1em;">'
+         + '</iframe>\n');
       return;
     }
     try {
@@ -1012,9 +1012,9 @@
       document.body.insertBefore(frame,this.panel);
       this.iframe = frame;
     } catch (err) {
-      document.write('<IFRAME SRC="" ID="jsMath.Frame" SCROLLING="no=
" '
-         + 'STYLE="visibility:hidden; position:absolute; width:1em; heig=
ht:1em;">'
-         + '</IFRAME>\n');
+      document.write('<iframe src="" id="jsMath.Frame" scrolling="no=
" '
+         + 'style="visibility:hidden; position:absolute; width:1em; heig=
ht:1em;">'
+         + '</iframe>\n');
     }
   },

@@ -2078,7 +2078,7 @@
       if (window.location.protocol != 'file:') {jsMath.Controls.SetCooki=
e(0)}
       if (jsMath.Browser.alphaPrintBug) {jsMath.Controls.cookie.alpha = =
0}
     }
-    document.writeln('<SCRIPT SRC="'+this.URL(name,"")+'"></SCRIPT>');
+    document.writeln('<script src="'+this.URL(name,"")+'"></script>');
     this.loaded = 1;
   }
  
@@ -2111,9 +2111,9 @@
   Spacer: function (w) {
     if (w == 0) {return ''};
     return jsMath.Browser.msieSpaceFix
-      + '<SPAN STYLE="margin-left: '
+      + '<span style="margin-left: '
       +    this.Em(w-jsMath.Browser.spaceWidth)+'">'
-      + jsMath.Browser.hiddenSpace + '</SPAN>';
+      + jsMath.Browser.hiddenSpace + '</span>';
   },

   /*
@@ -2127,11 +2127,11 @@
     if (!c) {c = 'black'};
     if (pos) {pos = 'absolute;'} else
              {pos = 'relative; margin-right: '+this.Em(-(w+2/jsMath.em))=
+'; '}
-    return '<IMG SRC="'+jsMath.blank+'" STYLE="position:' + pos
+    return '<img src="'+jsMath.blank+'" style="position:' + pos
              + 'vertical-align: '+this.Em(y)+'; left: '+this.Em(x)+'; '
              + 'width:' +this.Em(w*jsMath.Browser.imgScale)+'; '
              + 'height:'+this.Em(h*jsMath.Browser.imgScale)+'; '
-             + 'border: 1px solid '+c+';">';
+             + 'border: 1px solid '+c+';" />';
   },

   /*
@@ -2147,21 +2147,21 @@
     w *= jsMath.Browser.imgScale;
     h = Math.round(h*jsMath.em*jsMath.Browser.imgScale+.25);
     if (h < 1) {h = 1};
-    return '<IMG SRC="'+jsMath.blank+'" HSPACE="0" VSPACE="0" '
-              + 'STYLE="width:'+this.Em(w)+'; height:1px; '
+    return '<img src="'+jsMath.blank+'" hspace="0" vspace="0" '
+              + 'style="width:'+this.Em(w)+'; height:1px; '
               + 'vertical-align:-1px; '
-              + 'border:0px none; border-top:'+h+'px solid">';
+              + 'border:0px none; border-top:'+h+'px solid" />';
   },
  
   /*
-   *  Add a <SPAN> tag to activate a specific CSS class
+   *  Add a <span> tag to activate a specific CSS class
    */
   Class: function (tclass,html) {
-    return '<SPAN CLASS="'+tclass+'">'+html+'</SPAN>';
+    return '<span class="'+tclass+'">'+html+'</span>';
   },
  
   /*
-   *  Use a <SPAN> to place some HTML at a specific position.
+   *  Use a <span> to place some HTML at a specific position.
    *  (This can be replaced by the ones below to overcome
    *   some browser-specific bugs.)
    */
@@ -2169,29 +2169,29 @@
     if (Math.abs(x) < .0001) {x = 0}
     if (Math.abs(y) < .0001) {y = 0}
     if (x || y) {
-      var span = '<SPAN STYLE="position: relative;';
+      var span = '<span style="position: relative;';
       if (x) {span += ' margin-left:'+this.Em(x)+';'}
       if (y) {span += ' top:'+this.Em(-y)+';'}
-      html = span + '">' + html + '</SPAN>';
+      html = span + '">' + html + '</span>';
     }
     return html;
   },
  
   /*
    *  For MSIE on Windows, backspacing must be done in a separate
-   *  <SPAN>, otherwise the contents will be clipped.  Netscape
+   *  <span>, otherwise the contents will be clipped.  Netscape
    *  also doesn't combine vertical and horizontal spacing well.
-   *  Here the x and y positioning are done in separate <SPAN> tags
+   *  Here the x and y positioning are done in separate <span> tags
    */
   PlaceSeparateSkips: function (html,x,y) {
     if (Math.abs(x) < .0001) {x = 0}
     if (Math.abs(y) < .0001) {y = 0}
-    if (y) {html = '<SPAN STYLE="position: relative; top:'+this.Em(-y)=
+';'
-                       + '">' + html + '</SPAN>'}
+    if (y) {html = '<span style="position: relative; top:'+this.Em(-y)=
+';'
+                       + '">' + html + '</span>'}
     if (x) {html = jsMath.Browser.msieSpaceFix
-                       + '<SPAN STYLE="margin-left:'
+                       + '<span style="margin-left:'
                        +    this.Em(x-jsMath.Browser.spaceWidth)+';">'
-                       +  jsMath.Browser.hiddenSpace + '</SPAN>' + html}
+                       +  jsMath.Browser.hiddenSpace + '</span>' + html}
     return html;
   },
  
@@ -2201,8 +2201,8 @@
   PlaceAbsolute: function (html,x,y) {
     if (Math.abs(x) < .0001) {x = 0}
     if (Math.abs(y) < .0001) {y = 0}
-    html = '<SPAN STYLE="position: absolute; left:'+this.Em(x)+'; '
-              + 'top:'+this.Em(y)+';">' + html + '&nbsp;</SPAN>';
+    html = '<span style="position: absolute; left:'+this.Em(x)+'; '
+              + 'top:'+this.Em(y)+';">' + html + '&nbsp;</span>';
               //  space normalizes line height
     return html;
   },
@@ -2212,24 +2212,24 @@
     if (d && d != "none") {align = ' vertical-align: '+jsMath.HTML.Em(=
-d)+';'}
     if (y != "none") {
       if (Math.abs(y) < .0001) {y = 0}
-      html = '<SPAN STYLE="position: absolute; '
+      html = '<span style="position: absolute; '
                + 'top:'+jsMath.HTML.Em(y)+'; left: 0em;">'
                + html + '&nbsp;' // space normalizes line height in script=
 styles
-             + '</SPAN>';
+             + '</span>';
     }
-    html += '<IMG SRC="'+jsMath.blank+'" STYLE="'
+    html += '<img src="'+jsMath.blank+'" style="'
               + 'width:' +jsMath.HTML.Em(w*jsMath.Browser.imgScale)+'; '
-              + 'height:'+jsMath.HTML.Em(h*jsMath.Browser.imgScale)+';'+al=
ign+'">';
+              + 'height:'+jsMath.HTML.Em(h*jsMath.Browser.imgScale)+';'+al=
ign+'" />';
     if (jsMath.Browser.msieAbsoluteBug) {           // for MSIE (Mac)
-      html = '<SPAN STYLE="position: relative;">' + html + '</SPAN>';
+      html = '<span style="position: relative;">' + html + '</span>';
     }
-    html =   '<SPAN STYLE="position: relative;'
+    html =   '<span style="position: relative;'
            +     ' width: '+jsMath.HTML.Em(w)+';'   // for MSIE
            +     ' height: '+jsMath.HTML.Em(H)+';'  // for MSIE
            +     jsMath.Browser.msieInlineBlockFix  // for MSIE
            +     '">'
            +   html
-           + '</SPAN>';
+           + '</span>';
     return html;
   }

@@ -2302,7 +2302,7 @@
         // hack to avoid Font changing back to the default
         // font when a unicode reference is not followed
         // by a letter or number
-        box.html += '<SPAN STYLE="display: none">x</SPAN>'
+        box.html += '<span style="display: none">x</span>'
       }
     }
     if (c.img != null) {
@@ -2350,14 +2350,14 @@
                          "": " vertical-align:"+v+';';
     var URL = jsMath.Img.URL(font,jsMath.Img.fonts[id],C);
     if (jsMath.Browser.msieAlphaBug && jsMath.Controls.cookie.alpha) {
-      c.c = '<IMG SRC="'+jsMath.blank+'" '
-               + 'STYLE="'+jsMath.Browser.msieCenterBugFix
+      c.c = '<img src="'+jsMath.blank+'" '
+               + 'style="'+jsMath.Browser.msieCenterBugFix
 	       + resize + vadjust + wadjust
 	       + ' filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src=
=' + "'"
-	       + URL + "', sizingMethod='scale'" + ');">';
+	       + URL + "', sizingMethod='scale'" + ');" />';
     } else {
-      c.c = '<IMG SRC="'+URL+'" STYLE="'+jsMath.Browser.msieCenterBu=
gFix
-                  + resize + vadjust + wadjust + '">';
+      c.c = '<img src="'+URL+'" style="'+jsMath.Browser.msieCenterBu=
gFix
+                  + resize + vadjust + wadjust + '" />';
     }
     c.tclass = "normal";
     c.img.bh = h+d; c.img.bd = -d;
@@ -2601,7 +2601,7 @@
       html += this.AddClass(rep.tclass,ehtml,rep.font) + jsMath.HTML.Spa=
cer(w);
       ehtml = ''; for (var i = m; i < n; i++) {ehtml += ext};
       html += this.AddClass(rep.tclass,ehtml,rep.font);
-      if (jsMath.Browser.msieFontBug) {html += '<SPAN STYLE="display: =
none">x</SPAN>'}
+      if (jsMath.Browser.msieFontBug) {html += '<span style="display: =
none">x</span>'}
       html += jsMath.HTML.Place(this.AddClass(right.tclass,right.c,right=
=2Efont),-.4,0);
     }
     w = jsMath.EmBoxFor(html).w;
@@ -3667,7 +3667,7 @@
   AddStyle: function (style,size,html) {
     if      (style == "S" || style == "S'")   {size = Math.max(0=
,size-2)}
     else if (style == "SS" || style == "SS'") {size = Math.max(0=
,size-4)}
-    if (size != 4) {html = '<SPAN CLASS="size'+size+'">' + html + '<=
/SPAN>'}
+    if (size != 4) {html = '<span class="size'+size+'">' + html + '<=
/span>'}
     return html;
   },

@@ -3732,7 +3732,7 @@
   /*
    *  Typeset an mlist (i.e., turn it into HTML).
    *  Here, text items of the same class and style are combined
-   *  to reduce the number of <SPAN> tags used (though it is still
+   *  to reduce the number of <span> tags used (though it is still
    *  huge).  Spaces are combined, when possible.
    *  ###  More needs to be done with that.  ###
    *  The width of the final box is recomputed at the end, since
@@ -3837,42 +3837,42 @@
   },

   /*
-   *  Add a <SPAN> to position an item's HTML, and
+   *  Add a <span> to position an item's HTML, and
    *  adjust the item's height and depth.
    *  (This may be replaced buy one of the following browser-specific
    *   versions by Browser.Init().)
    */
   Place: function (item) {
-    var html = '<SPAN STYLE="position: relative;';
+    var html = '<span style="position: relative;';
     if (item.x) {html += ' margin-left:'+jsMath.HTML.Em(item.x)+';'}
     if (item.y) {html += ' top:'+jsMath.HTML.Em(-item.y)+';'}
-    item.html = html + '">' + item.html + '</SPAN>';
+    item.html = html + '">' + item.html + '</span>';
     item.h += item.y; item.d -= item.y;
     item.x = 0; item.y = 0;
   },
  
   /*
    *  For MSIE on Windows, backspacing must be done in a separate
-   *  <SPAN>, otherwise the contents will be clipped.  Netscape
+   *  <span>, otherwise the contents will be clipped.  Netscape
    *  also doesn't combine vertical and horizontal spacing well.
    *  Here, the horizontal and vertical spacing are done separately.
    */
   PlaceSeparateSkips: function (item) {
     if (item.y) {
-      if (item.html.match(/^<IMG[^>]*>(<SPAN STYLE="margin-left: [-0-9.]=
*em"><\/SPAN>)?$/i) && !item.html.match(/top:/)) {
-        item.html = item.html.replace(/STYLE="/,
-            'STYLE="position:relative; top:'+jsMath.HTML.Em(-item.y)+';'=
);
+      if (item.html.match(/^<img[^>]*>(<span style="margin-left: [-0-9.]=
*em"><\/span>)?$/i) && !item.html.match(/top:/)) {
+        item.html = item.html.replace(/style="/,
+            'style="position:relative; top:'+jsMath.HTML.Em(-item.y)+';'=
);
       } else {
-        item.html = '<SPAN STYLE="position: relative; '
+        item.html = '<span style="position: relative; '
                        + 'top:'+jsMath.HTML.Em(-item.y)+';'
-                       + '">' + item.html + '</SPAN>'
+                       + '">' + item.html + '</span>'
       }
     }
     if (item.x)
       {item.html = jsMath.Browser.msieSpaceFix
-                       + '<SPAN STYLE="margin-left:'
+                       + '<span style="margin-left:'
                        +    jsMath.HTML.Em(item.x-jsMath.Browser.spaceWidt=
h)+';">'
-                       + jsMath.Browser.hiddenSpace + '</SPAN>' + item.htm=
l}
+                       + jsMath.Browser.hiddenSpace + '</span>' + item.htm=
l}
     item.h += item.y; item.d -= item.y;
     item.x = 0; item.y = 0;
   }
@@ -4239,8 +4239,8 @@
     ker:          ['NamedOp',0],
     lg:           ['NamedOp',0],
     lim:           'NamedOp',
-    liminf:       ['NamedOp',null,'lim<SPAN STYLE="margin-left: '+1/6+'e=
m"></SPAN>inf'],
-    limsup:       ['NamedOp',null,'lim<SPAN STYLE="margin-left: '+1/6+'e=
m"></SPAN>sup'],
+    liminf:       ['NamedOp',null,'lim<span style="margin-left: '+1/6+'e=
m"></span>inf'],
+    limsup:       ['NamedOp',null,'lim<span style="margin-left: '+1/6+'e=
m"></span>sup'],
     ln:           ['NamedOp',0],
     log:          ['NamedOp',0],
     max:           'NamedOp',
@@ -4733,7 +4733,7 @@
   Color: function (name) {
     var color = this.GetArgument(this.cmd+name); if (this.error) return;
     // check that it looks like a color?
-    this.AddHTML(name,['<SPAN STYLE="color: '+color+'">','</SPAN>']);
+    this.AddHTML(name,['<span style="color: '+color+'">','</span>']);
   },
  
   /*
@@ -4741,7 +4741,7 @@
    */
   Href: function (name) {
     var href = this.GetArgument(this.cmd+name); if (this.error) return;
-    this.AddHTML(name,['<A CLASS="mathlink" HREF="'+href+'">','</A>']);
+    this.AddHTML(name,['<a class="mathlink" href="'+href+'">','</a>']);
   },
  
   /*
@@ -4749,7 +4749,7 @@
    */
   Class: function (name) {
     var clss = this.GetArgument(this.cmd+name); if (this.error) return;
-    this.AddHTML(name,['<SPAN CLASS="'+clss+'">','</SPAN>']);
+    this.AddHTML(name,['<span class="'+clss+'">','</span>']);
   },
  
   /*
@@ -4757,7 +4757,7 @@
    */
   Style: function (name) {
     var style = this.GetArgument(this.cmd+name); if (this.error) return;
-    this.AddHTML(name,['<SPAN STYLE="'+style+'">','</SPAN>']);
+    this.AddHTML(name,['<span style="'+style+'">','</span>']);
   },
  
   /*
@@ -5010,22 +5010,22 @@
     if (h != 0) {h = Math.max(1.05/jsMath.em,h)}
     if (h == 0 || w == 0) {style = "blank"}
     if (w == 0) {
-      html = '<IMG SRC="'+jsMath.blank+'" STYLE="'
+      html = '<img src="'+jsMath.blank+'" style="'
                 + 'border:0px none; width:1px; margin-right:-1px; '
-                + 'height:'+jsMath.HTML.Em(h*jsMath.Browser.imgScale)+'">';
+                + 'height:'+jsMath.HTML.Em(h*jsMath.Browser.imgScale)+'" /=
>';
     } else if (style == "blank") {
-      html = '<IMG SRC="'+jsMath.blank+'" STYLE="border:0px none; '
+      html = '<img src="'+jsMath.blank+'" style="border:0px none; '
                 + 'height:'+jsMath.HTML.Em(h*jsMath.Browser.imgScale)+'; '
-                + 'width:' +jsMath.HTML.Em(w*jsMath.Browser.imgScale)+'">';
+                + 'width:' +jsMath.HTML.Em(w*jsMath.Browser.imgScale)+'" /=
>';
     } else {
-      html = '<IMG SRC="'+jsMath.blank+'" STYLE="'
+      html = '<img src="'+jsMath.blank+'" style="'
                 + 'position: relative; top:1px; height:1px; border:0px non=
e; '
                 + 'border-top:'+jsMath.HTML.Em(h*jsMath.Browser.imgScale)+=
' solid; '
-                + 'width:' +jsMath.HTML.Em(w*jsMath.Browser.imgScale)+'">';
+                + 'width:' +jsMath.HTML.Em(w*jsMath.Browser.imgScale)+'" /=
>';
     }
     if (d) {
-      html = '<SPAN STYLE="vertical-align:'+jsMath.HTML.Em(-d)+'">'
-           +  html + '</SPAN>';
+      html = '<span style="vertical-align:'+jsMath.HTML.Em(-d)+'">'
+           +  html + '</span>';
     }
     this.mlist.Add(jsMath.mItem.Typeset(new jsMath.Box('html',html,w,h-d,d=
)));
   },
@@ -5353,7 +5353,7 @@
   /*
    *  Produce the final HTML.
    * 
-   *  We have to wrap the HTML it appropriate <SPAN> tags to hide its
+   *  We have to wrap the HTML it appropriate <span> tags to hide its
    *  actual dimensions when these don't match the TeX dimensions of the
    *  results.  We also include an image to force the results to take up
    *  the right amount of space.  The results may need to be vertically
@@ -5362,7 +5362,7 @@
   Typeset: function () {
     var data = this.mlist.init;
     var box = this.typeset = this.mlist.Typeset(data.style,data.size);
-    if (this.error) {return '<SPAN CLASS="error">'+this.error+'</SPAN>'}
+    if (this.error) {return '<span class="error">'+this.error+'</span>'}
     if (box.format == 'null') {return ''};

     box.Styled().Remeasured(); var isSmall = 0; var isBig = 0;
@@ -5380,18 +5380,18 @@
       } else if (!jsMath.Browser.valignBug) {
         // remove line height and try to hide the depth
         var dy = jsMath.HTML.Em(Math.max(0,box.bd-jsMath.hd)/3);
-        html = '<SPAN STYLE="line-height: 0;'
+        html = '<span style="line-height: 0px;'
                + ' position:relative; top:'+dy+'; vertical-align:'+dy
-               + '">' + html + '</SPAN>';
+               + '">' + html + '</span>';
       }
     }
     if (isBig) {// add height and depth to the line (force a little
                 //    extra to separate lines if needed)
-      html += '<IMG SRC="'+jsMath.blank+'" CLASS="mathHD" STYLE="'
+      html += '<img src="'+jsMath.blank+'" class="mathHD" style="'
                + 'height:'+jsMath.HTML.Em((box.h+box.d+.2)*jsMath.Browser.=
imgScale)+'; '
-               + 'vertical-align:'+jsMath.HTML.Em(-box.d-.1)+';">'
+               + 'vertical-align:'+jsMath.HTML.Em(-box.d-.1)+';" />'
     }
-    return '<NOBR><SPAN CLASS="jsM_scale">'+html+'</SPAN><NOBR>';
+    return '<nobr/><span class="jsM_scale">'+html+'</span><nobr/>';
   }

 });
@@ -5416,7 +5416,7 @@
  *  you must double the backslash in order to include control sequences
  *  within your replacement string.  E.g.,
  * 
- *      <SCRIPT> jsMath.Macro('R','{\\rm R}') </SCRIPT>
+ *      <script> jsMath.Macro('R','{\\rm R}') </script>
  *
  *  would make \R produce a bold-faced R.
  * 
@@ -5424,14 +5424,14 @@
  *  requires.  These are substituted for #1, #2, etc. within the
  *  replacement string of the macro.  For example
  * 
- *      <SCRIPT> jsMath.Macro('x','{\\vec x}_{#1}',1) </SCRIPT>
+ *      <script> jsMath.Macro('x','{\\vec x}_{#1}',1) </script>
  * 
  *  would make \x1 produce {\vec x}_{1} and \x{i+1} produce {\vec x}_{i+1}.
  *
  *  You can put several jsMath.Macro calls together into one .js file, and
  *  then include that into your web page using a command of the form
  * 
- *      <SCRIPT SRC="..."></SCRIPT>
+ *      <script src="..."></script>
  * 
  *  in your main HTML page.  This way you can include the same macros
  *  into several web pages, for example.
@@ -5453,9 +5453,9 @@
  *  These routines look through the web page for math elements to process.
  *  There are two main entry points you can call:
  * 
- *      <SCRIPT> jsMath.Process() </SCRIPT>
+ *      <script> jsMath.Process() </script>
  *  or
- *      <SCRIPT> jsMath.ProcessBeforeShowing() </SCRIPT>
+ *      <script> jsMath.ProcessBeforeShowing() </script>
  *
  *  The first will process the page asynchronously (so the user can start
  *  reading the top of the file while jsMath is still processing the botto=
m)
@@ -5507,7 +5507,7 @@
    *  processed and reinitialize sizes for that location.
    */
   ResetHidden: function (element) {
-    element.innerHTML = '<SPAN CLASS="normal" STYLE="position:absolu=
te; top:0;left:0;"></SPAN>';
+    element.innerHTML = '<span class="normal" style="position:absolu=
te; top:0;left:0;"></span>';
     element.className='';
     jsMath.hidden = element.firstChild;
     jsMath.ReInit();
@@ -5538,9 +5538,9 @@
    */
   ProcessElement: function (element) {
     try {
-      if (element.tagName == 'DIV') {
+      if (element.tagName.toLowerCase() == 'div') {
         this.ConvertDisplay(element);
-      } else if (element.tagName == 'SPAN') {
+      } else if (element.tagName.toLowerCase() == 'span') {
         this.ConvertText(element);
         //
 	// Overcome a bug in MSIE where were tex2math can't insert DIV's inside
@@ -5608,20 +5608,20 @@
     var element = [];
     if (!obj) {obj = document}
     if (typeof(obj) == 'string') {obj = document.getElementById(obj)}
-    if (!obj.getElementsByTagName) return
-    var math = obj.getElementsByTagName('DIV');
+    if (!obj.getElementsByTagName) return null;
+    var math = obj.getElementsByTagName('div');
     for (var k = 0; k < math.length; k++) {
       if (math[k].className == 'math') {
         if (jsMath.Browser.renameOK && obj.getElementsByName)
-               {math[k].setAttribute('NAME','_jsMath_')}
+               {math[k].setAttribute('name','_jsMath_')}
           else {element[element.length] = math[k]}
       }
     }
-    math = obj.getElementsByTagName('SPAN');
+    math = obj.getElementsByTagName('span');
     for (var k = 0; k < math.length; k++) {
       if (math[k].className == 'math') {
         if (jsMath.Browser.renameOK && obj.getElementsByName)
-               {math[k].setAttribute('NAME','_jsMath_')}
+               {math[k].setAttribute('name','_jsMath_')}
           else {element[element.length] = math[k]}
       }
     }
@@ -5636,13 +5636,13 @@

   /*
    *  Remove the window message about processing math
-   *  and clean up any marked <SPAN> or <DIV> tags
+   *  and clean up any marked <span> or <div> tags
    */
   ProcessComplete: function () {
     if (jsMath.Browser.renameOK) {
       var element = document.getElementsByName('_jsMath_');
       for (var i = element.length-1; i >= 0; i--) {
-        element[i].removeAttribute('NAME');
+        element[i].removeAttribute('name');
       }
     }
     jsMath.element = [];
diff -ur jsMath-2.3b/jsMath-mozilla.js jsMath-2.3b-lowercase/jsMath-mozilla=
=2Ejs
--- jsMath-2.3b/jsMath-mozilla.js	2005-04-23 13:05:30.000000000 -0700
+++ jsMath-2.3b-lowercase/jsMath-mozilla.js	2005-10-30 11:11:18.000000000 -=
0800
@@ -190,7 +190,7 @@
 jsMath.Update.TeXfonts({
   cmr10:  {'20': {c: '&#x02C7;', tclass: 'normal', w: .3}},
   cmmi10: {
-    '20': {c: '<I>&kappa</I>', tclass: 'normal'},
+    '20': {c: '<i>&kappa</i>', tclass: 'normal'},
     '58': {c: '.', tclass: 'normal'},
     '59': {c: ',', tclass: 'normal'},
     '61': {c: '&#x2F;', tclass: 'cmr10'}
@@ -203,9 +203,9 @@
     '39': {c: '&#x2243;'},
     '20': {c: '&le;', tclass: 'normal'}
   },
-  cmex10: {'20': {c: '<SPAN STYLE="font-size: 80%">&#xEFBD;</SPAN>'}},
-  cmti10: {'10': {c: '<I>&Omega;</I>', tclass: 'normal'}},
-  cmbx10: {'10': {c: '<B>&Omega;</B>', tclass: 'normal'}}
+  cmex10: {'20': {c: '<span style="font-size: 80%">&#xEFBD;</span>'}},
+  cmti10: {'10': {c: '<i>&Omega;</i>', tclass: 'normal'}},
+  cmbx10: {'10': {c: '<b>&Omega;</b>', tclass: 'normal'}}
 });


diff -ur jsMath-2.3b/jsMath-msie-mac.js jsMath-2.3b-lowercase/jsMath-msie-m=
ac.js
--- jsMath-2.3b/jsMath-msie-mac.js	2005-04-23 13:05:20.000000000 -0700
+++ jsMath-2.3b-lowercase/jsMath-msie-mac.js	2005-10-30 11:11:18.000000000 =
-0800
@@ -34,9 +34,9 @@
 jsMath.Update.TeXfonts({

   cmr10: {
-    '3':  {c: '<FONT FACE="Symbol">L</FONT>', tclass: 'normal'},
-    '5':  {c: '<FONT FACE="Symbol">P</FONT>', tclass: 'normal'},
-    '10': {c: '<FONT FACE="Symbol">W</FONT>', tclass: 'normal'},
+    '3':  {c: '<font face="Symbol">L</font>', tclass: 'normal'},
+    '5':  {c: '<font face="Symbol">P</font>', tclass: 'normal'},
+    '10': {c: '<font face="Symbol">W</font>', tclass: 'normal'},
     '16': {c: '&#x0131;', tclass: 'normal'},
     '20': {c: '&#xAD;'},
     '22': {c: '&#xAF;', tclass: 'normal', w: .3},
@@ -46,20 +46,20 @@
   },

   cmmi10: {
-    '3':  {c: '<I><FONT FACE="Symbol">L</FONT></I>', tclass: 'normal'},
-    '5':  {c: '<I><FONT FACE="Symbol">P</FONT></I>', tclass: 'normal'},
-    '10': {c: '<I><FONT FACE="Symbol">W</FONT></I>', tclass: 'normal'},
-    '15': {c: '<I><FONT FACE="Symbol">e</FONT></I>', tclass: 'normal'},
-    '16': {c: '<I><FONT FACE="Symbol">z</FONT></I>', tclass: 'normal'},
-    '20': {c: '<I><FONT FACE="Symbol">k</FONT></I>', tclass: 'normal'},
-    '22': {c: '<I><FONT FACE="Symbol">m</FONT></I>', tclass: 'normal'},
-    '25': {c: '<I><FONT FACE="Symbol">p</FONT></I>', tclass: 'normal'},
-    '26': {c: '<I><FONT FACE="Symbol">r</FONT></I>', tclass: 'normal'},
-    '27': {c: '<I><FONT FACE="Symbol">s</FONT></I>', tclass: 'normal'}
+    '3':  {c: '<i><font face="Symbol">L</font></i>', tclass: 'normal'},
+    '5':  {c: '<i><font face="Symbol">P</font></i>', tclass: 'normal'},
+    '10': {c: '<i><font face="Symbol">W</font></i>', tclass: 'normal'},
+    '15': {c: '<i><font face="Symbol">e</font></i>', tclass: 'normal'},
+    '16': {c: '<i><font face="Symbol">z</font></i>', tclass: 'normal'},
+    '20': {c: '<i><font face="Symbol">k</font></i>', tclass: 'normal'},
+    '22': {c: '<i><font face="Symbol">m</font></i>', tclass: 'normal'},
+    '25': {c: '<i><font face="Symbol">p</font></i>', tclass: 'normal'},
+    '26': {c: '<i><font face="Symbol">r</font></i>', tclass: 'normal'},
+    '27': {c: '<i><font face="Symbol">s</font></i>', tclass: 'normal'}
   },

   cmsy10: {
-    '3':  {c: '<SPAN STYLE="vertical-align:-.3em">*</SPAN>', tclass: 'no=
rmal'},
+    '3':  {c: '<span style="vertical-align:-.3em">*</span>', tclass: 'no=
rmal'},
     '5':  {c: '&#x389;', tclass: 'normal'},
     '10': {c: '&otimes;', tclass: 'normal'},
     '15': {c: '&#x2022;', tclass: 'normal'},
@@ -67,45 +67,45 @@
     '20': {c: '&le;', tclass: 'normal'},
     '22': {c: '&le;', tclass: 'normal'},
     '25': {c: '&#x2248;', tclass: 'normal'},
-    '26': {c: '<FONT FACE="Symbol">&#xCC;</FONT>', tclass: 'normal'},
-    '27': {c: '<FONT FACE="Symbol">&#xC9;</FONT>', tclass: 'normal'}
+    '26': {c: '<font face="Symbol">&#xCC;</font>', tclass: 'normal'},
+    '27': {c: '<font face="Symbol">&#xC9;</font>', tclass: 'normal'}
   },

   cmex10: {
-    '3':  {c: '<SPAN STYLE="font-size: 67%">&#x69;</SPAN>'},
-    '5':  {c: '<SPAN STYLE="font-size: 67%">&#x6B;</SPAN>'},
-    '10': {c: '<SPAN STYLE="font-size: 67%">&#x44;</SPAN>'},
-    '15': {c: '<SPAN STYLE="font-size: 55%">&#xC2;</SPAN>'},
-    '16': {c: '<SPAN STYLE="font-size: 83%">&#xB5;</SPAN>'},
-    '20': {c: '<SPAN STYLE="font-size: 83%">"</SPAN>'},
-    '22': {c: '<SPAN STYLE="font-size: 83%">$</SPAN>'},
-    '25': {c: '<SPAN STYLE="font-size: 83%">\'</SPAN>'},
-    '26': {c: '<SPAN STYLE="font-size: 83%">(</SPAN>'},
-    '27': {c: '<SPAN STYLE="font-size: 83%">)</SPAN>'}
+    '3':  {c: '<span style="font-size: 67%">&#x69;</span>'},
+    '5':  {c: '<span style="font-size: 67%">&#x6B;</span>'},
+    '10': {c: '<span style="font-size: 67%">&#x44;</span>'},
+    '15': {c: '<span style="font-size: 55%">&#xC2;</span>'},
+    '16': {c: '<span style="font-size: 83%">&#xB5;</span>'},
+    '20': {c: '<span style="font-size: 83%">"</span>'},
+    '22': {c: '<span style="font-size: 83%">$</span>'},
+    '25': {c: '<span style="font-size: 83%">\'</span>'},
+    '26': {c: '<span style="font-size: 83%">(</span>'},
+    '27': {c: '<span style="font-size: 83%">)</span>'}
   },

   cmti10: {
-    '3':  {c: '<I><FONT FACE="Symbol">L</FONT></I>', tclass: 'normal'},
-    '5':  {c: '<I><FONT FACE="Symbol">P</FONT></I>', tclass: 'normal'},
-    '10': {c: '<I><FONT FACE="Symbol">W</FONT></I>', tclass: 'normal'},
-    '16': {c: '<I>&#x0131;</I>', tclass: 'normal'},
-    '20': {c: '<I>&#xAD;</I>'},
-    '22': {c: '<I>&#xAF;</I>', tclass: 'normal', w: .3},
-    '25': {c: '<I>&#xDF;</I>', tclass: 'normal'},
-    '26': {c: '<I>&#xE6;</I>', tclass: 'normal'},
-    '27': {c: '<I>&#x153;</I>', tclass: 'normal'}
+    '3':  {c: '<i><font face="Symbol">L</font></i>', tclass: 'normal'},
+    '5':  {c: '<i><font face="Symbol">P</font></i>', tclass: 'normal'},
+    '10': {c: '<i><font face="Symbol">W</font></i>', tclass: 'normal'},
+    '16': {c: '<i>&#x0131;</i>', tclass: 'normal'},
+    '20': {c: '<i>&#xAD;</i>'},
+    '22': {c: '<i>&#xAF;</i>', tclass: 'normal', w: .3},
+    '25': {c: '<i>&#xDF;</i>', tclass: 'normal'},
+    '26': {c: '<i>&#xE6;</i>', tclass: 'normal'},
+    '27': {c: '<i>&#x153;</i>', tclass: 'normal'}
   },

   cmbx10: {
-    '3':  {c: '<B><FONT FACE="Symbol">L</FONT></B>', tclass: 'normal'},
-    '5':  {c: '<B><FONT FACE="Symbol">P</FONT></B>', tclass: 'normal'},
-    '10': {c: '<B><FONT FACE="Symbol">W</FONT></B>', tclass: 'normal'},
-    '16': {c: '<B>&#x0131;</B>', tclass: 'normal'},
-    '20': {c: '<B>&#xAD;</B>'},
-    '22': {c: '<B>&#xAF;</B>', tclass: 'normal', w: .3},
-    '25': {c: '<B>&#xDF;</B>', tclass: 'normal'},
-    '26': {c: '<B>&#xE6;</B>', tclass: 'normal'},
-    '27': {c: '<B>&#x153;</B>', tclass: 'normal'}
+    '3':  {c: '<b><font face="Symbol">L</font></b>', tclass: 'normal'},
+    '5':  {c: '<b><font face="Symbol">P</font></b>', tclass: 'normal'},
+    '10': {c: '<b><font face="Symbol">W</font></b>', tclass: 'normal'},
+    '16': {c: '<b>&#x0131;</b>', tclass: 'normal'},
+    '20': {c: '<b>&#xAD;</b>'},
+    '22': {c: '<b>&#xAF;</b>', tclass: 'normal', w: .3},
+    '25': {c: '<b>&#xDF;</b>', tclass: 'normal'},
+    '26': {c: '<b>&#xE6;</b>', tclass: 'normal'},
+    '27': {c: '<b>&#x153;</b>', tclass: 'normal'}
   }
 });

diff -ur jsMath-2.3b/plugins/autoload.js jsMath-2.3b-lowercase/plugins/auto=
load.js
--- jsMath-2.3b/plugins/autoload.js	2005-10-08 16:52:50.000000000 -0700
+++ jsMath-2.3b-lowercase/plugins/autoload.js	2005-10-30 11:16:30.000000000=
 -0800
@@ -73,10 +73,10 @@
   if (!obj) {obj = document}
   if (typeof(obj) == 'string') {obj = document.getElementById(obj)}
   if (!obj.getElementsByTagName) {return false}
-  var math = obj.getElementsByTagName('DIV');
+  var math = obj.getElementsByTagName('div');
   for (var k = 0; k < math.length; k++)
     {if (math[k].className == 'math') {return true}}
-  math = obj.getElementsByTagName('SPAN');
+  math = obj.getElementsByTagName('span');
   for (var k = 0; k < math.length; k++)
     {if (math[k].className == 'math') {return true}}
   return false;
@@ -107,7 +107,7 @@
     if (element.nodeName == '#text') {
       if (pattern.exec(element.nodeValue.replace(/\n/g,' '))) {return true}
     } else if (!element.tagName ||
-               !element.tagName.match(/^(SCRIPT|NOSCRIPT|STYLE|TEXTAREA)$/=
i)) {
+               !element.tagName.match(/^(script|noscript|style|textarea)$/=
i)) {
       if (this.FindPattern(method,element.firstChild,1)) {return true};
     }
     element = element.nextSibling;
@@ -124,7 +124,7 @@
  */
 jsMath.Autoload.LoadJsMath = function () {
   if (!jsMath.Autoload.root) {
-    var script = document.getElementsByTagName('SCRIPT');
+    var script = document.getElementsByTagName('script');
     if (script) {
       for (var i = 0; i < script.length; i++) {
         var src = script[i].src;
@@ -136,9 +136,9 @@
     }
   }
   if (jsMath.Autoload.root) {
-    document.write('<SCRIPT SRC="'+jsMath.Autoload.root+'jsMath.js"></'+=
'SCRIPT>');
+    document.write('<script src="'+jsMath.Autoload.root+'jsMath.js"></'+=
'script>');
     if (jsMath.Autoload.findTeXstrings || jsMath.Autoload.findLaTeXstrings)
-      {document.write('<SCRIPT SRC="'+jsMath.Autoload.root+'plugins/tex2=
math.js"></'+'SCRIPT>')}
+      {document.write('<script src="'+jsMath.Autoload.root+'plugins/tex2=
math.js"></'+'script>')}
   } else {
     alert("Can't determine URL for jsMath.js");
   }
@@ -151,7 +151,7 @@
   var fonts = jsMath.Autoload.loadFonts;
   if (typeof(fonts) != 'object') {fonts = [fonts]}
   for (var i in fonts) {
-    document.writeln('<SCRIPT>jsMath.Font.Load("'+fonts[i]+'")</'+'SCRIPT>=
');
+    document.writeln('<script>jsMath.Font.Load("'+fonts[i]+'")</'+'script>=
');
   }
 }

@@ -162,7 +162,7 @@
   var files = jsMath.Autoload.loadFiles;
   if (typeof(files) != 'object') {files = [files]}
   for (var i in files) {
-    document.writeln('<SCRIPT>jsMath.Setup.Script("'+files[i]+'")<'+'/SCRI=
PT>');
+    document.writeln('<script>jsMath.Setup.Script("'+files[i]+'")<'+'/scri=
pt>');
   }
 }

diff -ur jsMath-2.3b/plugins/mimeTeX.js jsMath-2.3b-lowercase/plugins/mimeT=
eX.js
--- jsMath-2.3b/plugins/mimeTeX.js	2005-07-10 15:20:44.000000000 -0700
+++ jsMath-2.3b-lowercase/plugins/mimeTeX.js	2005-10-30 11:11:18.000000000 =
-0800
@@ -1 +1,195 @@
-/*=0D *  Treat ~ as space=0D */=0DjsMath.Parser.prototype.nextIsSpace = =
function () {=0D  return this.string.charAt(this.i) == ' ' ||=0D       =
  this.string.charAt(this.i) == '~';=0D}=0DjsMath.Parser.prototype.spec=
ial['~'] = 'Space';=0D=0D/*=0D *  Implement \[ ... \], \( ... \), etc.=0D=
 */=0DjsMath.Macro('[','\\left[');  jsMath.Macro(']','\\right]');=0DjsMath.=
Macro('(','\\left(');  jsMath.Macro(')','\\right)');=0DjsMath.Macro('<','\\=
left<');  jsMath.Macro('>','\\right>');=0D// can't do \. in a reasonable wa=
y=0DjsMath.Parser.prototype.macros['|'] = ['HandleLR','|','|'];=0DjsMath.=
Parser.prototype.macros['='] = ['HandleLR','\\|','\\|'];=0D=0D/*=0D *  =
Make non-standard \left{ and \right} work=0D */=0DjsMath.Parser.prototype.d=
elimiter['}'] = [5,2,0x67,3,0x09];=0DjsMath.Parser.prototype.delimiter['{=
'] = [4,2,0x66,3,0x08];=0D=0D=0D/*=0D *  Immitate mimeTeX \big... and \Bi=
g... ops=0D */=0D=0D// make the normal ones in text mode=0DjsMath.Macro('in=
t','\\intop\\nolimits');=0DjsMath.Macro('oint','\\ointop\\nolimits');=0DjsM=
ath.Macro('sum','\\sumop\\nolimits');=0DjsMath.Macro('prod','\\prodop\\noli=
mits');=0DjsMath.Macro('coprod','\\coprodop\\nolimits');=0D=0DjsMath.Macro(=
'bigint','\\bigintop\\nolimits'); =0DjsMath.Macro('bigoint','\\bigointop\\n=
olimits');=0DjsMath.Macro('bigsum','\\bigsumop\\nolimits');=0DjsMath.Macro(=
'bigprod','\\bigprodop\\nolimits');=0DjsMath.Macro('bigcoprod','\\bigcoprod=
op\\nolimits');=0D=0DjsMath.Macro('Bigint','\\bigintop\\limits');=0DjsMath.=
Macro('Bigoint','\\bigointop\\limits');=0DjsMath.Macro('Bigsum','\\bigsumop=
\\limits');=0DjsMath.Macro('Bigprod','\\bigprodop\\limits');=0DjsMath.Macro=
('Bigcoprod','\\bigcoprod\\limits');=0D=0D/*=0D *  The characters needed fo=
r the macros above=0D */=0DjsMath.Parser.prototype.mathchardef['coprodop'] =
= [1,3,0x60];=0DjsMath.Parser.prototype.mathchardef['prodop']   = [1,3,=
0x51];=0DjsMath.Parser.prototype.mathchardef['sumop']    = [1,3,0x50];=0D=
=0DjsMath.Parser.prototype.mathchardef['bigintop']    = [1,3,0x5A];=0DjsM=
ath.Parser.prototype.mathchardef['bigointop']   = [1,3,0x49];=0DjsMath.Pa=
rser.prototype.mathchardef['bigcoprodop'] = [1,3,0x61];=0DjsMath.Parser.p=
rototype.mathchardef['bigprodop']   = [1,3,0x59];=0DjsMath.Parser.prototy=
pe.mathchardef['bigsumop']    = [1,3,0x58];=0D=0D/*=0D * Unlink the small=
 versions so they don't enlarge in display mode=0D */=0DjsMath.TeX['cmex10'=
][0x48].n = null;=0DjsMath.TeX['cmex10'][0x50].n = null;=0DjsMath.TeX['=
cmex10'][0x51].n = null;=0DjsMath.TeX['cmex10'][0x52].n = null;=0DjsMat=
h.TeX['cmex10'][0x60].n = null;=0D=0D=0D/*=0D *  Some other missing items=
=0D */=0DjsMath.Macro('/','{}'); // insert an empty box \/=0DjsMath.Macro('=
raisebox','\\raise #1px ',1); // convert to \raise=0DjsMath.Macro('hfill','=
\\quad ',1); // punt=0DjsMath.Macro('fbox','\\oldfbox{$#1$}',1); // do fbox=
 in math mode=0D=0D/*=0D *  These get new JavaScript routines=0D */=0DjsMat=
h.Parser.prototype.macros['unitlength'] = 'unitlength';=0DjsMath.Parser.p=
rototype.macros['hspace']     = 'hspace';=0DjsMath.Parser.prototype.macro=
s['fs']         = 'fs';=0DjsMath.Parser.prototype.macros['oldfbox']    =
= 'FBox';=0D=0D/*=0D *  Add some JavaScript functions to the parser=0D */=
=0DjsMath.Package(jsMath.Parser,{=0D  =0D  /*=0D   *  Implement \left x ...=
 \right x=0D   */=0D  HandleLR: function (name,data) {=0D    var arg = th=
is.GetUpto(name,name); if (this.error) return;=0D    this.string = '\\lef=
t'+data[0]+arg+'\\right'+data[1];=0D    this.i = 0;=0D  },=0D=0D  /*=0D  =
 *  Hold the unit length in mlist.data=0D   */=0D  unitlength: function (na=
me) {=0D    var n = this.GetArgument(this.cmd+name); if (this.error) retu=
rn;=0D    if (!n.match(/^-?(\d+(\.\d*)?|\.\d+)$/)) {=0D      this.Error("Ar=
gument for "+this.cmd+name+" must be a number");=0D      return;=0D    }=0D=
    this.mlist.data['unitlength'] = n;=0D  },=0D=0D  /*=0D   *  Get the l=
ength (converted to ems) and multiply by the unit length=0D   */=0D  hspace=
: function (name) {=0D    var w = this.GetArgument(this.cmd+name); if (th=
is.error) return;=0D    if (!w.match(/^-?(\d+(\.\d*)?|\.\d+)$/)) {=0D      =
this.Error("Argument for "+this.cmd+name+" must be a number");=0D      retu=
rn;=0D    }=0D    w /= jsMath.em=0D    if (this.mlist.data['unitlength'])=
 {w *= this.mlist.data['unitlength']}=0D    this.mlist.Add(jsMath.mItem.S=
pace(w));=0D  },=0D  =0D  /*=0D   *  Implement \fs{...} for font-size chang=
ing=0D   */=0D  fs: function (name) {=0D    var n = this.GetArgument(this=
=2Ecmd+name); if (this.error) return;=0D    if (!n.match(/^[-+]?\d+$/)) {=
=0D      this.Error("Argument for "+this.cmd+name+" must be an integer");=
=0D      return;=0D    }=0D    if (n.match(/[-+]/)) {n = n - 0; n += th=
is.mlist.data.size}=0D    this.mlist.data.size = n = Math.max(0,Math.mi=
n(9,n));=0D    this.mlist.Add(new jsMath.mItem('size',{size: n}));=0D  },=
=0D=0D  /*=0D   *  Repalce the Array function by one that accepts an option=
al=0D   *  parameter for the column types, and that handle's mimeTeX's=0D  =
 *  "preamble" format.=0D   */=0D  Array: function (name,delim) {=0D    var=
 columns = delim[2]; var cspacing = delim[3];=0D    if (!columns && thi=
s.GetNext() == '{') {=0D      columns = this.GetArgument(this.cmd+'be=
gin{'+name+'}');=0D      if (this.error) return;=0D    } else {=0D      col=
umns = '';=0D    }=0D    columns = columns.replace(/[^clr]/g,'');=0D   =
 columns = columns.split('');=0D    var data = this.mlist.data;=0D    v=
ar arg = this.GetEnd(name); if (this.error) return;=0D    if (arg.match(/=
\$/)) {arg = arg.replace(/^([^$]*)\$/,''); columns = RegExp.$1}=0D    v=
ar parse = new jsMath.Parser(arg+'\\\\',null,data.size);=0D    parse.matr=
ix = name; parse.row = []; parse.table = [];=0D    parse.Parse(); if =
(parse.error) {this.Error(parse); return}=0D    parse.HandleRow(name,1);  /=
/ be sure the last row is recorded=0D    var box = jsMath.Box.Layout(data=
=2Esize,parse.table,columns,cspacing);=0D    // Add parentheses, if needed=
=0D    if (delim[0] && delim[1]) {=0D      var left  = jsMath.Box.Delimit=
er(box.h+box.d,this.delimiter[delim[0]],'T');=0D      var right = jsMath.=
Box.Delimiter(box.h+box.d,this.delimiter[delim[1]],'T');=0D      box = js=
Math.Box.SetList([left,box,right],data.style,data.size);=0D    }=0D    this=
=2Emlist.Add(jsMath.mItem.Atom((delim[0]? 'inner': 'ord'),box));=0D  },=0D=
=0D  /*=0D   *  Similarly for Matrix (used by \matrix and \array)=0D   */=
=0D  Matrix: function (name,delim) {=0D    var data = this.mlist.data;=0D=
    var arg = this.GetArgument(this.cmd+name); if (this.error) return;=0D=
    if (arg.match(/\$/)) {arg = arg.replace(/^([^$]*)\$/,''); delim[2] =
= RegExp.$1}=0D    var parse = new jsMath.Parser(arg+'\\\\',null,data.s=
ize);=0D    parse.matrix = name; parse.row = []; parse.table = [];=0D=
    parse.Parse(); if (parse.error) {this.Error(parse); return}=0D    parse=
=2EHandleRow(name,1);  // be sure the last row is recorded=0D    var box =
= jsMath.Box.Layout(data.size,parse.table,delim[2]);=0D    // Add parenth=
eses, if needed=0D    if (delim[0] && delim[1]) {=0D      var left  = jsM=
ath.Box.Delimiter(box.h+box.d,this.delimiter[delim[0]],'T');=0D      var ri=
ght = jsMath.Box.Delimiter(box.h+box.d,this.delimiter[delim[1]],'T');=0D =
     box = jsMath.Box.SetList([left,box,right],data.style,data.size);=0D =
   }=0D    this.mlist.Add(jsMath.mItem.Atom((delim[0]? 'inner': 'ord'),box)=
);=0D  }=0D});
\ No newline at end of file
+/*
+ *  Treat ~ as space
+ */
+jsMath.Parser.prototype.nextIsSpace = function () {
+  return this.string.charAt(this.i) == ' ' ||
+         this.string.charAt(this.i) == '~';
+}
+jsMath.Parser.prototype.special['~'] = 'Space';
+
+/*
+ *  Implement \[ ... \], \( ... \), etc.
+ */
+jsMath.Macro('[','\\left[');  jsMath.Macro(']','\\right]');
+jsMath.Macro('(','\\left(');  jsMath.Macro(')','\\right)');
+jsMath.Macro('<','\\left<');  jsMath.Macro('>','\\right>');
+// can't do \. in a reasonable way
+jsMath.Parser.prototype.macros['|'] = ['HandleLR','|','|'];
+jsMath.Parser.prototype.macros['='] = ['HandleLR','\\|','\\|'];
+
+/*
+ *  Make non-standard \left{ and \right} work
+ */
+jsMath.Parser.prototype.delimiter['}'] = [5,2,0x67,3,0x09];
+jsMath.Parser.prototype.delimiter['{'] = [4,2,0x66,3,0x08];
+
+
+/*
+ *  Immitate mimeTeX \big... and \Big... ops
+ */
+
+// make the normal ones in text mode
+jsMath.Macro('int','\\intop\\nolimits');
+jsMath.Macro('oint','\\ointop\\nolimits');
+jsMath.Macro('sum','\\sumop\\nolimits');
+jsMath.Macro('prod','\\prodop\\nolimits');
+jsMath.Macro('coprod','\\coprodop\\nolimits');
+
+jsMath.Macro('bigint','\\bigintop\\nolimits');
+jsMath.Macro('bigoint','\\bigointop\\nolimits');
+jsMath.Macro('bigsum','\\bigsumop\\nolimits');
+jsMath.Macro('bigprod','\\bigprodop\\nolimits');
+jsMath.Macro('bigcoprod','\\bigcoprodop\\nolimits');
+
+jsMath.Macro('Bigint','\\bigintop\\limits');
+jsMath.Macro('Bigoint','\\bigointop\\limits');
+jsMath.Macro('Bigsum','\\bigsumop\\limits');
+jsMath.Macro('Bigprod','\\bigprodop\\limits');
+jsMath.Macro('Bigcoprod','\\bigcoprod\\limits');
+
+/*
+ *  The characters needed for the macros above
+ */
+jsMath.Parser.prototype.mathchardef['coprodop'] = [1,3,0x60];
+jsMath.Parser.prototype.mathchardef['prodop']   = [1,3,0x51];
+jsMath.Parser.prototype.mathchardef['sumop']    = [1,3,0x50];
+
+jsMath.Parser.prototype.mathchardef['bigintop']    = [1,3,0x5A];
+jsMath.Parser.prototype.mathchardef['bigointop']   = [1,3,0x49];
+jsMath.Parser.prototype.mathchardef['bigcoprodop'] = [1,3,0x61];
+jsMath.Parser.prototype.mathchardef['bigprodop']   = [1,3,0x59];
+jsMath.Parser.prototype.mathchardef['bigsumop']    = [1,3,0x58];
+
+/*
+ * Unlink the small versions so they don't enlarge in display mode
+ */
+jsMath.TeX['cmex10'][0x48].n = null;
+jsMath.TeX['cmex10'][0x50].n = null;
+jsMath.TeX['cmex10'][0x51].n = null;
+jsMath.TeX['cmex10'][0x52].n = null;
+jsMath.TeX['cmex10'][0x60].n = null;
+
+
+/*
+ *  Some other missing items
+ */
+jsMath.Macro('/','{}'); // insert an empty box \/
+jsMath.Macro('raisebox','\\raise #1px ',1); // convert to \raise
+jsMath.Macro('hfill','\\quad ',1); // punt
+jsMath.Macro('fbox','\\oldfbox{$#1$}',1); // do fbox in math mode
+
+/*
+ *  These get new JavaScript routines
+ */
+jsMath.Parser.prototype.macros['unitlength'] = 'unitlength';
+jsMath.Parser.prototype.macros['hspace']     = 'hspace';
+jsMath.Parser.prototype.macros['fs']         = 'fs';
+jsMath.Parser.prototype.macros['oldfbox']    = 'FBox';
+
+/*
+ *  Add some JavaScript functions to the parser
+ */
+jsMath.Package(jsMath.Parser,{
+ 
+  /*
+   *  Implement \left x ... \right x
+   */
+  HandleLR: function (name,data) {
+    var arg = this.GetUpto(name,name); if (this.error) return;
+    this.string = '\\left'+data[0]+arg+'\\right'+data[1];
+    this.i = 0;
+  },
+
+  /*
+   *  Hold the unit length in mlist.data
+   */
+  unitlength: function (name) {
+    var n = this.GetArgument(this.cmd+name); if (this.error) return;
+    if (!n.match(/^-?(\d+(\.\d*)?|\.\d+)$/)) {
+      this.Error("Argument for "+this.cmd+name+" must be a number");
+      return;
+    }
+    this.mlist.data['unitlength'] = n;
+  },
+
+  /*
+   *  Get the length (converted to ems) and multiply by the unit length
+   */
+  hspace: function (name) {
+    var w = this.GetArgument(this.cmd+name); if (this.error) return;
+    if (!w.match(/^-?(\d+(\.\d*)?|\.\d+)$/)) {
+      this.Error("Argument for "+this.cmd+name+" must be a number");
+      return;
+    }
+    w /= jsMath.em
+    if (this.mlist.data['unitlength']) {w *= this.mlist.data['unitlength=
']}
+    this.mlist.Add(jsMath.mItem.Space(w));
+  },
+ 
+  /*
+   *  Implement \fs{...} for font-size changing
+   */
+  fs: function (name) {
+    var n = this.GetArgument(this.cmd+name); if (this.error) return;
+    if (!n.match(/^[-+]?\d+$/)) {
+      this.Error("Argument for "+this.cmd+name+" must be an integer");
+      return;
+    }
+    if (n.match(/[-+]/)) {n = n - 0; n += this.mlist.data.size}
+    this.mlist.data.size = n = Math.max(0,Math.min(9,n));
+    this.mlist.Add(new jsMath.mItem('size',{size: n}));
+  },
+
+  /*
+   *  Repalce the Array function by one that accepts an optional
+   *  parameter for the column types, and that handle's mimeTeX's
+   *  "preamble" format.
+   */
+  Array: function (name,delim) {
+    var columns = delim[2]; var cspacing = delim[3];
+    if (!columns && this.GetNext() == '{') {
+      columns = this.GetArgument(this.cmd+'begin{'+name+'}');
+      if (this.error) return;
+    } else {
+      columns = '';
+    }
+    columns = columns.replace(/[^clr]/g,'');
+    columns = columns.split('');
+    var data = this.mlist.data;
+    var arg = this.GetEnd(name); if (this.error) return;
+    if (arg.match(/\$/)) {arg = arg.replace(/^([^$]*)\$/,''); columns =
= RegExp.$1}
+    var parse = new jsMath.Parser(arg+'\\\\',null,data.size);
+    parse.matrix = name; parse.row = []; parse.table = [];
+    parse.Parse(); if (parse.error) {this.Error(parse); return}
+    parse.HandleRow(name,1);  // be sure the last row is recorded
+    var box = jsMath.Box.Layout(data.size,parse.table,columns,cspacing);
+    // Add parentheses, if needed
+    if (delim[0] && delim[1]) {
+      var left  = jsMath.Box.Delimiter(box.h+box.d,this.delimiter[delim[=
0]],'T');
+      var right = jsMath.Box.Delimiter(box.h+box.d,this.delimiter[delim[=
1]],'T');
+      box = jsMath.Box.SetList([left,box,right],data.style,data.size);
+    }
+    this.mlist.Add(jsMath.mItem.Atom((delim[0]? 'inner': 'ord'),box));
+  },
+
+  /*
+   *  Similarly for Matrix (used by \matrix and \array)
+   */
+  Matrix: function (name,delim) {
+    var data = this.mlist.data;
+    var arg = this.GetArgument(this.cmd+name); if (this.error) return;
+    if (arg.match(/\$/)) {arg = arg.replace(/^([^$]*)\$/,''); delim[2] =
= RegExp.$1}
+    var parse = new jsMath.Parser(arg+'\\\\',null,data.size);
+    parse.matrix = name; parse.row = []; parse.table = [];
+    parse.Parse(); if (parse.error) {this.Error(parse); return}
+    parse.HandleRow(name,1);  // be sure the last row is recorded
+    var box = jsMath.Box.Layout(data.size,parse.table,delim[2]);
+    // Add parentheses, if needed
+    if (delim[0] && delim[1]) {
+      var left  = jsMath.Box.Delimiter(box.h+box.d,this.delimiter[delim[=
0]],'T');
+      var right = jsMath.Box.Delimiter(box.h+box.d,this.delimiter[delim[=
1]],'T');
+      box = jsMath.Box.SetList([left,box,right],data.style,data.size);
+    }
+    this.mlist.Add(jsMath.mItem.Atom((delim[0]? 'inner': 'ord'),box));
+  }
+});
\ No newline at end of file
diff -ur jsMath-2.3b/plugins/tex2math.js jsMath-2.3b-lowercase/plugins/tex2=
math.js
--- jsMath-2.3b/plugins/tex2math.js	2005-10-21 20:09:14.000000000 -0700
+++ jsMath-2.3b-lowercase/plugins/tex2math.js	2005-10-30 11:11:18.000000000=
 -0800
@@ -5,8 +5,8 @@
  *
  *  This file is a plugin that searches text wthin a web page
  *  for \(...\), \[...\], $...$ and $$...$$ and converts them to
- *  the appropriate <SPAN CLASS="math">...</SPAN> or
- *  <DIV CLASS="math">...</DIV> tags.
+ *  the appropriate <span class="math">...</span> or
+ *  <div class="math">...</div> tags.
  *
  *  ---------------------------------------------------------------------
  *
@@ -95,7 +95,7 @@

     //
     //  MSIE won't let you insert a DIV within tags that are supposed to
-    //  contain in-line data (like <P> or <SPAN>), so we have to fake it
+    //  contain in-line data (like <p> or <span>), so we have to fake it
     //  using SPAN tags that force the formatting to work like DIV.  We
     //  use a separate SPAN that is the full width of the containing
     //  item, and that has the margins from the div.typeset style
@@ -109,7 +109,7 @@
         tag.className = (jsMath.tex2math.center)? "jsMath.recenter": "";
         tag.style.width = "100%"; tag.style.margin = jsMath.tex2math.m=
argin;
         tag.style.display = "inline-block";
-        text = '<SPAN CLASS="math">\\displaystyle{'+text+'}</SPAN>';
+        text = '<span class="math">\\displaystyle{'+text+'}</span>';
       }
       tag.innerHTML = text;
       return tag;

--mojUlQ0s9EVzWg2t

diff -ur jsMath-2.3b-lowercase/jsMath.js jsMath-2.3b-xhtml/jsMath.js
--- jsMath-2.3b-lowercase/jsMath.js	2005-10-30 11:14:09.000000000 -0800
+++ jsMath-2.3b-xhtml/jsMath.js	2005-10-29 13:58:55.000000000 -0700
@@ -270,14 +270,14 @@
         else {document.body.insertBefore(div,document.body.firstChild)}
     } catch (err) {
       var html = '<div id="jsMath.'+id+'"';
-      for (var id in attributes) {html += ' '+id+'="'+attributes[id]+'"'}
+      for (var id2 in attributes) {html += ' '+id2+'="'+attributes[id2]+'"'}
       if (styles) {
         html += ' style="';
-        for (var id in styles) {html += ' '+id+':'+styles[id]+';'}
+        for (var id2 in styles) {html += ' '+id2+':'+styles[id2]+';'}
         html += '"';
       }
       html += '</div>';
-      if (!document.body.insertAdjacentHTML) {document.write(html)}
+      if (!document.body.insertAdjacentHTML) {jsMath.write(html)}
         else {document.body.insertAdjacentHTML('AfterBegin',html)}
       div = jsMath.Element(id);
     }
@@ -2143,7 +2144,7 @@
    */
   Rule: function (w,h) {
     if (h == null) {h = jsMath.TeX.default_rule_thickness}
-    if (w == 0 || h == 0) return;  // should make an invisible box?
+    if (w == 0 || h == 0) return '';  // should make an invisible box?
     w *= jsMath.Browser.imgScale;
     h = Math.round(h*jsMath.em*jsMath.Browser.imgScale+.25);
     if (h < 1) {h = 1};
@@ -2385,7 +2386,7 @@
    */
   Rule: function (w,h) {
     if (h == null) {h = jsMath.TeX.default_rule_thickness}
-    html = jsMath.HTML.Rule(w,h);
+    var html = jsMath.HTML.Rule(w,h);
     return new jsMath.Box('html',html,w,h,0);
   },
 
@@ -2410,7 +2411,7 @@
    *  Return the character, font, style and actual height used.
    */
   DelimBestFit: function (H,c,font,style) {
-    if (c == 0 && font == 0) return;
+    if (c == 0 && font == 0) return null;
     var C; var h; font = jsMath.TeX.fam[font];
     var isSS = (style.charAt(1) == 'S');
     var isS  = (style.charAt(0) == 'S');
@@ -2424,6 +2425,7 @@
       if (h >= H || C.n == null) {return [c,font,'T',h]}
       c = C.n
     }
+    return null;
   },
   
   /*
@@ -3066,7 +3068,7 @@
    *  contains an \over (or \above, etc).
    */
   Over: function () {
-    var over = this.data.overI; var from = this.data.overF
+    var over = this.data.overI; var from = this.data.overF;
     var atom = jsMath.mItem.Fraction(from.name,
       {type: 'mlist', mlist: this.Range(open+1,over-1)},
       {type: 'mlist', mlist: this.Range(over)},
@@ -4497,7 +4499,7 @@
   Process: function (arg) {
     var data = this.mlist.data;
     arg = jsMath.Parse(arg,data.font,data.size,data.style);
-      if (arg.error) {this.Error(arg); return}
+      if (arg.error) {this.Error(arg); return null}
     if (arg.mlist.Length() == 0) {return null}
     if (arg.mlist.Length() == 1) {
       var atom = arg.mlist.Last();
@@ -4515,7 +4517,8 @@
     var letter = /^([a-z]+|.) ?/i;
     var cmd = letter.exec(this.string.slice(this.i));
     if (cmd) {this.i += cmd[1].length; return cmd[1]}
-    this.Error("Missing control sequnece name at end of string or argument"); return
+    this.Error("Missing control sequnece name at end of string or argument"); 
+    return null;
   },
 
   /*
@@ -4524,8 +4527,8 @@
    */
   GetArgument: function (name,noneOK) {
     while (this.nextIsSpace()) {this.i++}
-    if (this.i >= this.string.length) {if (!noneOK) this.Error("Missing argument for "+name); return}
-    if (this.string.charAt(this.i) == this.close) {if (!noneOK) this.Error("Extra close brace"); return}
+    if (this.i >= this.string.length) {if (!noneOK) this.Error("Missing argument for "+name); return null}
+    if (this.string.charAt(this.i) == this.close) {if (!noneOK) this.Error("Extra close brace"); return null}
     if (this.string.charAt(this.i) == this.cmd) {this.i++; return this.cmd+this.GetCommand()}
     if (this.string.charAt(this.i) != this.open) {return this.string.charAt(this.i++)}
     var j = ++this.i; var pcount = 1; var c = '';
@@ -4534,18 +4537,19 @@
       if (c == this.cmd) {this.i++}
       else if (c == this.open) {pcount++}
       else if (c == this.close) {
-        if (pcount == 0) {this.Error("Extra close brace"); return}
+        if (pcount == 0) {this.Error("Extra close brace"); return null}
         if (--pcount == 0) {return this.string.slice(j,this.i-1)}
       }
     }
     this.Error("Missing close brace");
+    return null;
   },
 
   /*
    *  Get an argument and process it into an mList
    */
   ProcessArg: function (name) {
-    var arg = this.GetArgument(name); if (this.error) return;
+    var arg = this.GetArgument(name); if (this.error) return null;
     return this.Process(arg);
   },
 
@@ -4557,10 +4561,11 @@
     var c = this.string.charAt(this.i);
     if (this.i < this.string.length) {
       this.i++;
-      if (c == this.cmd) {c = '\\'+this.GetCommand(name); if (this.error) return}
+      if (c == this.cmd) {c = '\\'+this.GetCommand(name); if (this.error) return null}
       if (this.delimiter[c] != null) {return this.delimiter[c]}
     }
     this.Error("Missing or unrecognized delimiter for "+name);
+    return null;
   },
   
   /*
@@ -4578,7 +4583,7 @@
       advance = 1;
     }
     var match = rest.match(/^\s*([-+]?(\.\d+|\d+(\.\d*)?))(pt|em|ex|mu|px)/);
-    if (!match) {this.Error("Missing dimension or its units for "+name); return}
+    if (!match) {this.Error("Missing dimension or its units for "+name); return null}
     if (advance) {
       this.i += match[0].length;
       if (this.nextIsSpace()) {this.i++}
@@ -4610,7 +4615,7 @@
       if (c == '{') {pcount++}
       else if (c == '}') {
         if (pcount == 0)
-          {this.Error("Extra close brace while looking for ']'"); return}
+          {this.Error("Extra close brace while looking for ']'"); return null}
         pcount --;
       } else if (c == this.cmd) {
         this.i++;
@@ -4619,6 +4624,7 @@
       }
     }
     this.Error("Couldn't find closing ']' for argument to "+this.cmd+name);
+    return null;
   },
   
   /*
@@ -4632,7 +4638,7 @@
       if (c == '{') {pcount++}
       else if (c == '}') {
         if (pcount == 0)
-          {this.Error("Extra close brace while looking for "+this.cmd+token); return}
+          {this.Error("Extra close brace while looking for "+this.cmd+token); return null}
         pcount --;
       } else if (c == this.cmd) {
         // really need separate counter for begin/end
@@ -4655,6 +4661,7 @@
       }
     }
     this.Error("Couldn't find "+this.cmd+token+" for "+name);
+    return null;
   },
 
   /*
@@ -4662,7 +4669,7 @@
    *  process it to get its mlist
    */
   ProcessUpto: function (name,token) {
-    var arg = this.GetUpto(name,token); if (this.error) return;
+    var arg = this.GetUpto(name,token); if (this.error) return null;
     return this.Process(arg);
   },
 
@@ -4672,8 +4679,8 @@
   GetEnd: function (env) {
     var body = ''; var name = '';
     while (name != env) {
-      body += this.GetUpto('begin{'+env+'}','end'); if (this.error) return;
-      name = this.GetArgument(this.cmd+'end'); if (this.error) return;
+      body += this.GetUpto('begin{'+env+'}','end'); if (this.error) return null;
+      name = this.GetArgument(this.cmd+'end'); if (this.error) return null;
     }
     return body;
   },

--mojUlQ0s9EVzWg2t

diff -ur jsMath-2.3b-lowercase-mozfix/jsMath-controls.html jsMath-2.3b-xhtml/jsMath-controls.html
--- jsMath-2.3b-lowercase-mozfix/jsMath-controls.html	2005-10-31 08:41:27.000000000 -0800
+++ jsMath-2.3b-xhtml/jsMath-controls.html	2005-10-31 08:41:22.000000000 -0800
@@ -76,7 +76,7 @@
   Main: function () {
     this.oldCookie = {}; jsMath.Add(this.oldCookie,this.cookie);
     this.panel.innerHTML = ""; // for MSIE on the Mac
-    this.panel.innerHTML = document.getElementById("jsMath.panel").innerHTML;
+    this.panel.appendChild(document.getElementById("jsMath.panel").cloneNode(true));
 
     jsMath.Element("fontType").innerHTML =
       ({tex:"TeX",
@@ -109,7 +109,7 @@
 
   Options: function () {
     this.panel.innerHTML = ""; // for MSIE on the Mac
-    this.panel.innerHTML = document.getElementById("jsMath.options").innerHTML;
+    this.panel.appendChild(document.getElementById("jsMath.options").cloneNode(true));
     jsMath.Element("scale").value = this.cookie.scale;
     jsMath.Element("keep").value = this.cookie.keep;
     for (var id in {autofont:1, scaleImg:1, alpha:1, warn:1, button:1}) {
diff -ur jsMath-2.3b-lowercase-mozfix/jsMath.js jsMath-2.3b-xhtml/jsMath.js
--- jsMath-2.3b-lowercase-mozfix/jsMath.js	2005-10-31 08:41:28.000000000 -0800
+++ jsMath-2.3b-xhtml/jsMath.js	2005-10-31 09:03:22.000000000 -0800
@@ -289,7 +289,9 @@
    */
   Script: function (file) {
     if (!file.match('^([a-zA-Z]+:/)?/')) {file = jsMath.root + file}
-    document.write('<script src="'+file+'"></script>');
+    var loader = document.createElement("script");
+    loader.src = file;
+    document.getElementsByTagName('body')[0].appendChild(loader);
   },
   
   /*
@@ -297,7 +299,7 @@
    */
   HTML: function () {
     jsMath.hidden = this.TopHTML("Hidden",{'class':"normal"},{
-      position:"absolute", top:0, left:0, border:0, padding:0, margin:0
+       position:"absolute", top:0, left:0, border:0, padding:0, margin:0
     });
     return;
   },
@@ -413,9 +415,10 @@
       styles = jsMath.styles;
       styles['.jsM_scale'] = 'font-size:'+jsMath.Controls.cookie.scale+'%';
     }
-    document.writeln('<style type="text/css" id="jsMath.styles">');
-    for (var id in styles) {document.writeln('  '+id+'  {'+styles[id]+'}')}
-    document.writeln('</style>');
+    var style = '<style type="text/css" id="jsMath.styles">';
+    for (var id in styles) { style += '  '+id+'  {'+styles[id]+'}\n'}
+    style += '</style>'
+    jsMath.writehead(style);
   },
   
   /*
@@ -437,7 +440,7 @@
     jsMath.Setup.User();  //  do user-specific initialization
 
     //make sure browser-specific loads are done before this
-    document.write('<script>jsMath.Font.Check()</script>');
+    jsMath.write('<script>jsMath.Font.Check()</script>');
     
     this.inited = 1;
   },
@@ -996,7 +999,7 @@
     if (!jsMath.Browser.msieButtonBug) {this.Button()}
       else {setTimeout("jsMath.Controls.Button()",500)}
     if (jsMath.Browser.safariIFRAMEbug) {
-      document.write(
+      jsMath.write(
          '<iframe src="'+jsMath.root+'/jsMath-controls.html" '
          + 'id="jsMath.Frame" scrolling="no" '
          + 'style="visibility:hidden; position:absolute; width:1em; height:1em;">'
@@ -1012,7 +1015,7 @@
       document.body.insertBefore(frame,this.panel);
       this.iframe = frame;
     } catch (err) {
-      document.write('<iframe src="" id="jsMath.Frame" scrolling="no" '
+      jsMath.write('<iframe src="" id="jsMath.Frame" scrolling="no" '
          + 'style="visibility:hidden; position:absolute; width:1em; height:1em;">'
          + '</iframe>\n');
     }
@@ -2078,7 +2081,7 @@
       if (window.location.protocol != 'file:') {jsMath.Controls.SetCookie(0)}
       if (jsMath.Browser.alphaPrintBug) {jsMath.Controls.cookie.alpha = 0}
     }
-    document.writeln('<script src="'+this.URL(name,"")+'"></script>');
+    jsMath.write('<script src="'+this.URL(name,"")+'"></script>');
     this.loaded = 1;
   }
   
@@ -2099,9 +2102,11 @@
    *  using 0 when the value is near zero.
    */
   Em: function (m) {
+    //if(isnan(m)) { alert("jsMath.HTML.Em passed a NaN"); }
     var n = 5; if (m < 0) {n++}
     if (Math.abs(m) < .000001) {m = 0}
     var s = String(m); s = s.replace(/(\.\d\d\d).+/,'$1');
+    //alert("Em("+m+")="+s+"em");
     return s+'em'
   },
 
@@ -5297,11 +5302,16 @@
     } else if (name.match(/withdelims$/)) {
       this.mlist.data.overF.left  = this.GetDelimiter(this.cmd+name); if (this.error) return;
       this.mlist.data.overF.right = this.GetDelimiter(this.cmd+name); if (this.error) return;
+    } else {
+      this.mlist.data.overF.left  = null;
+      this.mlist.data.overF.right = null;
     }
     if (name.match(/^above/))
     {
       this.mlist.data.overF.thickness = this.GetDimen(this.cmd.name,1);
       if (this.error) return;
+    } else {
+      this.mlist.data.overF.thickness = null; 
     }
   },
 
@@ -5675,6 +5685,32 @@
 /*
  *  Initialize everything
  */
+
+jsMath.domparser = new DOMParser();
+try { 
+    document.write(""); 
+    jsMath.write = function(s) { document.write(s); }
+    jsMath.writehead = function(s) { document.write(s); }
+}
+catch(err) {
+    jsMath.write = function(s) {
+        var newelement = jsMath.domparser.parseFromString(
+            '<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"><body>'
+            +s+'</body></html>','application/xhtml+xml');
+        var appendme = newelement.firstChild.firstChild.firstChild;  // node is
+            // Document, child is html, child of child is body, child of child of
+            // child is the requested text.
+        document.getElementsByTagName('body')[0].appendChild(appendme);
+    }
+    jsMath.writehead = function(s) {
+        var newelement = (new DOMParser()).parseFromString(
+            '<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"><head>'
+            +s+'</head></html>','application/xhtml+xml');
+        var appendme = newelement.firstChild.firstChild.firstChild;
+        document.getElementsByTagName('head')[0].appendChild(appendme);
+    }
+}
+
 jsMath.Loaded();
 jsMath.Controls.GetCookie();
 if (document.body) {jsMath.Setup.Body()}
Only in jsMath-2.3b-xhtml/: .jsMath.js.swl
Only in jsMath-2.3b-xhtml/: .jsMath.js.swm
Only in jsMath-2.3b-xhtml/: .jsMath.js.swn
Only in jsMath-2.3b-xhtml/: .jsMath.js.swo
Only in jsMath-2.3b-xhtml/: .jsMath.js.swp

\start
Date: Mon, 31 Oct 2005 16:51:40 -0500
From: Bill Page
To: Mike Thomas
Subject: re: Boot vs. Lisp

I trust all is well.

On October 31, 2005 4:01 PM you wrote:

> ... 
> One wonders, however, just how complicated a build system
> actually has to be particularly as Lisp is used elsewhere
> in Axiom.
> 

I agree that using *both* Lisp and BOOT is probably more
complicated than it needs to be. But my solution to this
would be precisely opposite the solution proposed by Tim.
What I would greatly prefer is to replace the Lisp in
Axiom with BOOT, where possible. I think the only place
where Lisp is required is in the bootstrap for the BOOT
compiler itself. And even there, BOOT could be weened from
it's mother Lisp and live on it's own like ML, Aldor, and
some other languages that started out in Lisp - but I am
not really advocating that in the short term.

If someone thinks Lisp is essential to Axiom then I would
be glad to see some examples. In my writing I may appear to
be overly opinionated, but really deep down my intention is
to be open-minded. :)

\start
Date: Tue, 1 Nov 2005 08:11:47 +1000
From: Mike Thomas
To: Bill Page
Subject: re: Boot vs. Lisp

Hi Bill.

| I agree that using *both* Lisp and BOOT is probably more
| complicated than it needs to be. But my solution to this
| would be precisely opposite the solution proposed by Tim.
| What I would greatly prefer is to replace the Lisp in
| Axiom with BOOT, where possible. I think the only place
| where Lisp is required is in the bootstrap for the BOOT
| compiler itself. And even there, BOOT could be weened from
| it's mother Lisp and live on it's own like ML, Aldor, and
| some other languages that started out in Lisp - but I am
| not really advocating that in the short term.
|
| If someone thinks Lisp is essential to Axiom then I would
| be glad to see some examples.

It clearly isn't, although as you imply there are practical constraints
due to pre-existing work which basically does the job and insufficient
person-work-hours. 

| In my writing I may appear to
| be overly opinionated,

With respect to "overly", not that I've noticed. 

| but really deep down my intention is
| to be open-minded. :)

That is also clear.

\start
Date: Mon, 31 Oct 2005 18:22:10 -0500
From: Tim Daly
To: Bill Page
Subject: Re: compile with Debian fails

we have a darcs server?

we could reconsider the arch/darcs/cvs/subversion/git issue 
if you'd like. i moved to arch because it was the first one
that seemed to support "changesets". Tagging in cvs was just
a pain and i never got it right.

opinions?

\start
Date: Mon, 31 Oct 2005 15:34:54 -0800 (PST)
From: Cliff Yapp
To: Bill Page, Mike Thomas
Subject: RE: Boot vs. Lisp

--- Bill Page wrote:

> Hello Mike,
> 
> I trust all is well.
> 
> On October 31, 2005 4:01 PM you wrote:
> 
> > ... 
> > One wonders, however, just how complicated a build system
> > actually has to be particularly as Lisp is used elsewhere
> > in Axiom.
> 
> I agree that using *both* Lisp and BOOT is probably more
> complicated than it needs to be. But my solution to this
> would be precisely opposite the solution proposed by Tim.
> What I would greatly prefer is to replace the Lisp in
> Axiom with BOOT, where possible. I think the only place
> where Lisp is required is in the bootstrap for the BOOT
> compiler itself. And even there, BOOT could be weened from
> it's mother Lisp and live on it's own like ML, Aldor, and
> some other languages that started out in Lisp - but I am
> not really advocating that in the short term.

In doing so we basically commit to writing our own development
environments and tools, as well as leaving a language that has an
established ANSI standard.  That may be worth it, but I'm going to be a
hard sell. ;-)

> If someone thinks Lisp is essential to Axiom then I would
> be glad to see some examples. 

Clearly it is not, any more that BOOT is - either could function as the
sole supportive language given sufficient motivation.  The question
facing us is whether the tradeoff of losing Lisp's history,
flexibility, community and existing tools/libraries/experience is worth
the better logical match between BOOT and the SPAD and Aldor languages.
 The only think I know for sure about such a question is I am
unqualified to deside.  I just hope that whatever decision is made BOOT
is not a requirement for writing a tightly bound GUI, because the
prospect of trying to reimplement McCLIM and QT bindings in BOOT is not
something I even want to think about.

> In my writing I may appear to
> be overly opinionated, but really deep down my intention is
> to be open-minded. :)

Same here - I really don't know which is the best way.  I suppose I'm a
bit dazzled by Lisp's history with CAS work and the praise it seems to
garner from those who understand it, so that should be taken into
account.  My concern is that if we go with BOOT at too low a level we
are going to find ourselves completely on our own for any tools above
the level of gcc and noweb.  That is not a comforting thought.

There might be one other way.  We have BOOT to Lisp mappings, albeit
somewhat behind the times from what I understand.  What if we go the
other way as well - make a preprocessor that parses Lisp into BOOT?  If
the mapping really is robust shouldn't it be possible to write in
EITHER lisp or BOOT and achieve results that are readable in the other
language?

\start
Date: Mon, 31 Oct 2005 19:33:59 -0600
From: MathAction (anonymous)
To: MathAction
Subject: [#226 Equality in FunctionCalled] (new) 

The equality test seems to have a bug.
\begin{axiom}
p:Integer->Integer
p(x)==x
p
t:Boolean:(p=p)
\end{axiom}

\start
Date: Mon, 31 Oct 2005 19:35:43 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#226 Equality in FunctionCalled] 

t:Boolean:=(p=p)

\start
Date: Mon, 31 Oct 2005 19:45:34 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#226 Equality in FunctionCalled] 

++added:
)set mess bot on
t:=(p=p)

++added:

In fact, in variable.spad, the result should be true always.

\begin{verbatim}
)abbrev domain FUNCTION FunctionCalled
++ Description:
++ This domain implements named functions
FunctionCalled(f:Symbol): SetCategory with 
        name: % -> Symbol 
                ++ name(x) returns the symbol
  == add
   name r                 == f
   coerce(r:%):OutputForm == f::OutputForm
   x = y                  == true
   latex(x:%):String      == latex f
\end{verbatim}

So the code has no bugs! The Interpreter uses the wrong equality test function.

\start
Date: Mon, 31 Oct 2005 21:59:41 -0500
From: Tim Daly
To: list
Subject: BAD tim

Ah, language wars ... the only thing that out-emotions a license war

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


POINT 1: Axiom needs to be future-proofed.

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


POINT 2: The rewriting will change existing code. 

   If we look at the "startup sequence" we see:

              restart (lisp)
   init-memory-config (lisp)
             initroot (lisp)
               reroot (lisp)
                 spad (boot)
              runspad (boot)
           ncTopLevel (boot)
            ncIntLoop (lisp)
              intloop (boot)
  SpadInterpretStream (boot)
   intloopReadConsole (boot)

  and, if you follow the side-paths you'll see the constant switching
  between boot and lisp at every level in nearly every function.

  This inhibits "collapsing and rewriting" code which will have to happen
  during the rewrite. Functions will either have to be collapsed into lisp
  or boot.

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


POINT 3: Boot is a dead language. 

   There are approximately 10 people still living who have coded in
   boot and every one of them is doing something else with their
   life. You have to be careful in boot. It is case sensitive so APPEND
   is not the same as append. It is often not clear what a construct
   will translate to and you end up reading the lisp to learn. 
   A single, misplaced space will change the meaning of the code.

POINT 4: Boot SERIOUSLY complicates the Axiom system. For instance:

  1) Bootstrapping boot

   The boot compiler is written in boot and needs to be compiled
   using itself. If you have a running Axiom system this is not a
   problem. However if you start from a clean lisp system it is a
   big problem. I cheesed up a way to do this but it is fragile and
   ugly. But given that we build from scratch there is no other way.

  2) Makefiles come in multiple stages

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

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

  3) lsp, lisp, clisp, ${LISP}

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

  4) The interpreter has a boot compiler built in

   There are complications to the interpreter to handle boot-related
   development from the command line which no-one is ever likely to
   do again. This code could disappear and, having gone away, simplify
   the interpreter



POINT 5: The boot language is undocumented 

   It is likely to remain so as one of the authors is dead and the other
   one might be. There are no primary sources of documentation.

POINT 6: Boot does not give you the full power of common lisp.

   Boot cannot handle backquote, defstruct, and other primitives
   not to mention CLOS, CLIM, etc. So as lisp evolves boot will
   "further fork" away from the living edge of lisp ideas and 
   limit the axiom programmer. 

   Witness the data structures used in boot, mostly lists. Frames
   are lists of lists, history is a circular list of lists, etc.
   Where are the data structures? Who will redesign, rewrite, and
   document boot extensions to fully cover common lisp?

POINT 7: Boot loses program-data symmetry.

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

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

POINT 8: Tools don't support boot

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

   Boot is unsupported anywhere by anything.


POINT 9: Where are the programmers?

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

POINT 10: Boot was an experiment in surface syntax

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

POINT 11: Do language design where it counts.

   If we are going to devote research effort toward language design
   lets do it at the Spad/Aldor level where it counts. This is where
   the real language expertise should be applied. For instance, why
   do I have to write programs to express functions? Why can't I
   write a domain using equations? Why doesn't the Spad language
   support that?

POINT 12: Future directions assume lisp

   Notice that one of the near future goals is to connect Axiom and
   ACL2. ACL2 understands lisp-ish kind of languages, not boot.


and now, on to the recent changes

POINT 13: Don't break code until you understand it.

   I'm working hard to understand the code so the existing code is a
   straightforward translation (well, mostly, with some rewrites that
   I know are logically equivalent).

   Once I've completely figured out the various twists and turns,
   uses and references, and other points I'll be recoding the whole
   process. There is no reason (other than historical) why there are
   a dozen entry points into the interpreter that set wierd, undocumented,
   stateful flags. All that cruft must go away.

   So the code is ugly. At the moment. But it will get better, cleaner,
   clearer, more robust, and easier to change. History and Frames, for
   example will use structures that don't depend on 
      (caar (cdddddr (cdddddr x)))

   It takes time. It takes work, probably 2-3 years worth of work.
  
and now, on to the personal...

POINT 14: I'm a lisp programmer 
   
   (clearly)

The Evil One,
Bad Tim

\start
Date: Mon, 31 Oct 2005 21:40:55 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#226 Equality in FunctionCalled] 

In fact, in 'variable.spad', the result should be true always.

 Moreover, even this function gives the wrong answer. According to the
 ')set mess bot on message', the test function is taken from the
 domain '(INT->INT)', which is 'Mapping(INT, INT)'. Unfortunately,
 Mapping is an Axiom primitive and according to available
 documentation:

\begin{axiom}
)show Mapping
\end{axiom}

In any case, according to Hyperdoc, there is only one function
exported: (you guessed it) equality testing. I have no idea where the
code is or how the testing is done. Equivalence of functions (lambda
terms) is undecidable, so I suppose equality here means equality in
implementation? But surely, 'p' should be equal to 'p' however you
test it.