\start
Date: Wed, 1 Jun 2005 15:49:46 +0200
From: Martin Rubey
To: list
Subject: summer of code

I think we should participate as mentoring organization in "summer of code":

http://code.google.com/mentfaq.html

Deadline is June 14, but very likely we would have to be ready this weekend.

\start
Date: Wed, 1 Jun 2005 10:02:38 -0500
From: Tim Daly
To: Martin Rubey
Subject: summer of code

seems reasonable to me.

i already have 3 students working with me on the doyencd project.

the key problem is finding students who are self-learners and
self-motivated. i managed to do that using the interview process.
i'm not sure how to conduct an interview process in this case.
i'll send a note to google and ask.

i'll also join the google newsgroup and post some information
about the axiom project.

we could use students to:

work on the reference volume of the book 
  visit each algebra file and make a complete listing of all of
  the function signatures with boiler-plate documentation (e.g.
  the types in the argument lists). construct an index for the book.

work on the tutorial volume of the book
  choose a textbook (linear algebra for dummies?) or an online
  course (linear algebra at ocw.mit.edu?) and develop a tutorial
  based on the source material using axiom.

work on the windows version of the browser and graphics
  work out the lisp code necessary to read browser pages and
  render them as TK pages

work on the wiki version of the browser and graphics
  work out the wiki code to use the browser pages directly in
  the wiki. figure out how to get the wiki to accept the browser
  page syntax.

develop regression testing
  create a systematic way of regression testing and implement it
  
develop test cases
  create a domain-by-domain set of reference test cases with
  explanations, boundary cases, etc.

test code
  use the handbook of curves and surfaces to comprehensively test
  the graphics routines.

drag-and-drop
  given a literate program that includes axiom algebra code and
  some text figure out how to "drag and drop" the paper onto axiom.
  that is, figure out how to get the code in the right place, the
  makefile to accept the code, the paper in the right place and
  integrated into the documentation

dvi organization
  work out an automated way to organize the hundreds of dvi files
  so they can be browsed.

booklet mechanism
  pamphlets use random names in code chunks. develop a full URL
  syntax and create a booklet mechanism. That is, one should be
  able to define a chunk as:
    <<file:///something>>
  and have something inserted inline or
    <<http:///something>>
  and have something inserted inline.

semantic markups
  develop latex macros for marking "concepts" in latex files
  mark up literate programs and math papers and create a concept
  index, similar to the word index mechanism latex now uses

\start
Date: Wed, 1 Jun 2005 11:12:36 -0500
From: Tim Daly
To: code@google.com
Subject: summer of code

I'm Tim Daly, the lead developer on the Axiom project
(http://savannah.nongnu.org/projects/axiom
 http://sourceforge.net/projects/axiom
 http://page.axiom-developer.org)

I saw the announcement about the summer of code. I posted some
possible tasks on the summer-discuss list but that was a bit
premature.

It appears that there is a process to get certified as a "mentor"
organization. Is Axiom eligible? What do I need to do to get the
project certified?

\start
Date: Wed, 01 Jun 2005 12:04:39 -0500
From: MathAction (unknown)
To: MathAction
Subject: [build Axiom] problems with graphics on Fedora 3

Axiom builds successfully but did not install properly. On the
installed location, the internal program links are of the directory
where it was built NOT of the installed directory.  Besides, even on
running it from the directory where it was built, the graphical front
end does not start. text interface works, though.

\start
Date: Wed, 01 Jun 2005 12:09:12 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] Installation and graphics Problems on Fedora 3

Axiom builds successfully but did not install properly. On the
installed location, the internal program links are of the directory
where it was built NOT of the installed directory. Besides, even on
running it from the directory where it was built, the graphical front
end does not start. text interface works, though.

\start
Date: Wed, 1 Jun 2005 10:33:18 -0700
From: Chris DiBona
To: Tim Daly
Subject: Re: [M#27311421] summer of code

Individuals are not eligible to be mentors, you must provide a backup
and a list of ideas on a site. Let us know if you can do that, then
we'll determine if we can accomodate another . Thans!

Chris

On 6/1/05, Tim Daly wrote:
> ------------------------ Trakken Ticket Info ------------------------
> Ticket ID: 27311421                   Ticket State: Open
> Message Type: Incoming Message        Queue: Code
> Acknowledge: ALL products:WorkFlow:Auto Replies:Code autoreply
>
> Ticket URL: http://google.trakken.com/cgi-bin/search.py?ticket_id=27311421
>
> -------------------------- Message Follows --------------------------
>
> I'm Tim Daly, the lead developer on the Axiom project
> (http://savannah.nongnu.org/projects/axiom
>  http://sourceforge.net/projects/axiom
>  http://page.axiom-developer.org)
>
> I saw the announcement about the summer of code. I posted some
> possible tasks on the summer-discuss list but that was a bit
> premature.
>
> It appears that there is a process to get certified as a "mentor"
> organization. Is Axiom eligible? What do I need to do to get the
> project certified?
>

\start
Date: Wed, 1 Jun 2005 12:40:43 -0500
From: Tim Daly
To: list
Subject: summer of code

Chris,

I'm polling the membership for a backup person.
I've posted a list of ideas on the summer newsgroup but
I'll put together a web page on the Axiom site and let
you know where it appears.

Tim


> Individuals are not eligible to be mentors, you must provide a backup
> and a list of ideas on a site. Let us know if you can do that, then 
> we'll determine if we can accomodate another . Thanks@
> 
> Chris
> 
> 
> > I'm Tim Daly, the lead developer on the Axiom project
> > (http://savannah.nongnu.org/projects/axiom
> >  http://sourceforge.net/projects/axiom
> >  http://page.axiom-developer.org)
> > 
> > I saw the announcement about the summer of code. I posted some
> > possible tasks on the summer-discuss list but that was a bit
> > premature.
> > 
> > It appears that there is a process to get certified as a "mentor"
> > organization. Is Axiom eligible? What do I need to do to get the
> > project certified?

\start
Date: Wed, 1 Jun 2005 12:50:22 -0500
From: Tim Daly
To: Bill Page
Subject: summer of code

Bill,

Google is sponsoring a "summer of code" where they will pay 
students to work on open source projects for the summer. The
students get $4500 and the organization gets $500. This could
be a useful source of visibility, people, and revenue.

In order to qualify as a sponsoring organization (there are about
10 so far) we need to have a couple volunteers who are mentors
(to hire, guide, and evaluate the student work) and a website
listing ideas.

I tried to set a website page off the FrontPage but it does not
appear to be user-editable. Could you set up a page link to a 
page I can edit? I'd like to add the following on that page.

we could use students to:

work on the reference volume of the book 
  visit each algebra file and make a complete listing of all of
  the function signatures with boiler-plate documentation (e.g.
  the types in the argument lists). construct an index for the book.

work on the tutorial volume of the book
  choose a textbook (linear algebra for dummies?) or an online
  course (linear algebra at ocw.mit.edu?) and develop a tutorial
  based on the source material using axiom.

work on the windows version of the browser and graphics
  work out the lisp code necessary to read browser pages and
  render them as TK pages

work on the wiki version of the browser and graphics
  work out the wiki code to use the browser pages directly in
  the wiki. figure out how to get the wiki to accept the browser
  page syntax.

develop regression testing
  create a systematic way of regression testing and implement it
  
develop test cases
  create a domain-by-domain set of reference test cases with
  explanations, boundary cases, etc.

test code
  use the handbook of curves and surfaces to comprehensively test
  the graphics routines.

drag-and-drop
  given a literate program that includes axiom algebra code and
  some text figure out how to "drag and drop" the paper onto axiom.
  that is, figure out how to get the code in the right place, the
  makefile to accept the code, the paper in the right place and
  integrated into the documentation

dvi organization
  work out an automated way to organize the hundreds of dvi files
  so they can be browsed.

booklet mechanism
  pamphlets use random names in code chunks. develop a full URL
  syntax and create a booklet mechanism. That is, one should be
  able to define a chunk as:
    <<file:///something>>
  and have something inserted inline or
    <<http:///something>>
  and have something inserted inline.

semantic markups
  develop latex macros for marking "concepts" in latex files
  mark up literate programs and math papers and create a concept
  index, similar to the word index mechanism latex now uses

\start
Date: Wed, 1 Jun 2005 12:39:31 -0500
From: Tim Daly
To: list
Subject: summer of code

*

We can certainly provide a site of ideas (I've already listed about
10 on the google site) but we need someone to volunteer as a backup.

> Individuals are not eligible to be mentors, you must provide a backup
> and a list of ideas on a site. Let us know if you can do that, then 
> we'll determine if we can accomodate another . Thanks@
> 
> Chris
> 
> 
> > I'm Tim Daly, the lead developer on the Axiom project
> > (http://savannah.nongnu.org/projects/axiom
> >  http://sourceforge.net/projects/axiom
> >  http://page.axiom-developer.org)
> > 
> > I saw the announcement about the summer of code. I posted some
> > possible tasks on the summer-discuss list but that was a bit
> > premature.
> > 
> > It appears that there is a process to get certified as a "mentor"
> > organization. Is Axiom eligible? What do I need to do to get the
> > project certified?

\start
Date: Wed, 1 Jun 2005 12:39:26 -0500
From: Tim Daly
To: list
Subject: summer of code

*

We can certainly provide a site of ideas (I've already listed about
10 on the google site) but we need someone to volunteer as a backup.

t


> Individuals are not eligible to be mentors, you must provide a backup
> and a list of ideas on a site. Let us know if you can do that, then 
> we'll determine if we can accomodate another . Thanks@
> 
> Chris
> 
> 
> > I'm Tim Daly, the lead developer on the Axiom project
> > (http://savannah.nongnu.org/projects/axiom
> >  http://sourceforge.net/projects/axiom
> >  http://page.axiom-developer.org)
> > 
> > I saw the announcement about the summer of code. I posted some
> > possible tasks on the summer-discuss list but that was a bit
> > premature.
> > 
> > It appears that there is a process to get certified as a "mentor"
> > organization. Is Axiom eligible? What do I need to do to get the
> > project certified?

\start
Date: Wed, 01 Jun 2005 13:07:21 -0500
From: MathAction (billpage)
To: MathAction
Subject: [Summer of Code] (new) 

We could use students to:

1 work on the reference volume of the book

  visit each algebra file and make a complete listing of all of
  the function signatures with boiler-plate documentation (e.g.
  the types in the argument lists). construct an index for the book.

2 work on the tutorial volume of the book

  choose a textbook (linear algebra for dummies?) or an online
  course (linear algebra at ocw.mit.edu?) and develop a tutorial
  based on the source material using axiom.

3 work on the windows version of the browser and graphics

  work out the lisp code necessary to read browser pages and
  render them as TK pages

4 work on the wiki version of the browser and graphics

  work out the wiki code to use the browser pages directly in
  the wiki. figure out how to get the wiki to accept the browser
  page syntax.

5 develop regression testing

  create a systematic way of regression testing and implement it
  
6 develop test cases

  create a domain-by-domain set of reference test cases with
  explanations, boundary cases, etc.

7 test code

  use the handbook of curves and surfaces to comprehensively test
  the graphics routines.

8 drag-and-drop

  given a literate program that includes axiom algebra code and
  some text figure out how to "drag and drop" the paper onto axiom.
  that is, figure out how to get the code in the right place, the
  makefile to accept the code, the paper in the right place and
  integrated into the documentation

9 dvi organization

  work out an automated way to organize the hundreds of dvi files
  so they can be browsed.

10 booklet mechanism

   pamphlets use random names in code chunks. develop a full URL
   syntax and create a booklet mechanism. That is, one should be
   able to define a chunk as::

     <<file:///something>>

   and have something inserted inline or ::

     <<http:///something>>

   and have something inserted inline.

11 semantic markups

   develop latex macros for marking "concepts" in latex files
   mark up literate programs and math papers and create a concept
   index, similar to the word index mechanism latex now uses

12 etc

   (under construction)

\start
Date: Wed, 1 Jun 2005 14:10:10 -0400 
From: Bill Page
To: Tim Daly
Subject: RE: summer of code

Tim,

I set up the following editable page:

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

On Wednesday, June 01, 2005 1:50 PM you wrote:

> ...
> Could you set up a page link to a page I can edit?
> I'd like to add the following on that page.
> ...

Let me know if you need help with formatting or anything.

\start
Date: Wed, 1 Jun 2005 11:34:25 -0700
From: Bob McElrath
To: Tim Daly
Subject: Re: summer of code

Tim Daly [Tim Daly] wrote:
> 
> We can certainly provide a site of ideas (I've already listed about
> 10 on the google site) but we need someone to volunteer as a backup.

I'd like to volunteer to mentor someone to write a field theory module
(a la FeynCalc) for Axiom.

Most of the ideas on SummerOfCode are "janitor" duties, and those that
are not would appeal mostly to CS students.

Let's try to get some people working on mathematics?

> > Individuals are not eligible to be mentors, you must provide a backup
> > and a list of ideas on a site. Let us know if you can do that, then 
> > we'll determine if we can accomodate another . Thanks@
> > 
> > Chris
> > 
> > 
> > > I'm Tim Daly, the lead developer on the Axiom project
> > > (http://savannah.nongnu.org/projects/axiom
> > >  http://sourceforge.net/projects/axiom
> > >  http://page.axiom-developer.org)
> > > 
> > > I saw the announcement about the summer of code. I posted some
> > > possible tasks on the summer-discuss list but that was a bit
> > > premature.
> > > 
> > > It appears that there is a process to get certified as a "mentor"
> > > organization. Is Axiom eligible? What do I need to do to get the
> > > project certified?

\start
Date: Wed, 1 Jun 2005 14:18:25 -0500
From: Tim Daly
To: Bob McElrath
Subject: summer of code

Bob,

I have no objections to mathematical projects. I've just been
concentrating on something that could be done by someone with
no Axiom experience in a couple months time.

Bill has set up a page
http://page.axiom-developer.org/zope/mathaction/SummerOfCode
where we can propose projects.

\start
Date: Wed, 1 Jun 2005 14:31:29 -0500
From: Tim Daly
To: Bob McElrath
Subject: summer of code

Bob,

I added 3 mathematical tasks to the wiki page as well
as categorized them.

\start
Date: Wed, 01 Jun 2005 14:30:17 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [Summer of Code] 

DOCUMENTATION

* work on the reference volume of the book

* work on the tutorial volume of the book

* language translation

   Axiom is a worldwide project. It is used in multiple countries
   and runs on platforms like Red Flag Linux (Chinese). We have
   some introductory documentation in French but we need people 
   who can translate the book into any non-english language.

USER INTERFACE

* work on the windows version of the browser and graphics

* work on the wiki version of the browser and graphics

SYSTEM BUILDING and TESTING

* develop regression testing

* develop test cases

* test code

NEW FEATURES

* drag-and-drop

* dvi organization

* booklet mechanism

* semantic markups

MATHEMATICAL WORK

* Field Theory Module (ala FeynCalc)

* Literate Program to implement "Primes is in P" algorithm

* Symbolic Summation algorithm 

\start
Date: Wed, 1 Jun 2005 14:22:26 -0500
From: Tim Daly
To: Chris DiBona
Subject: summer of code

Chris,

We have a web page we've set up on a wiki at
http://page.axiom-developer.org/zope/mathaction/SummerOfCode

We're going to be adding projects to that web page with additional
explanations.

A second person (Bob McElrath), one of our
developers, is looking for students to handle mathematical tasks such
as a FeynCalc module.

What other requirements are there to be a Summer of Code mentor project?

\start
Date: Wed, 01 Jun 2005 17:19:34 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [Summer of Code] 

++added:
Axiom is documented with 4 books which are under development,
a tutorial, a programmer's guide, a reference volume, and a
developer's guide.


  The reference volume is intended to provide complete lookup
  coverage of the Axiom system. There are over 11,000 functions
  within Axiom which require standardized documentation.
 
  This project would involve visiting each algebra file (approx
  300 files) to make a complete listing of all of the function
  signatures and their type information. Ideally this should be
  automated as the information is available. The output should be
  a set of Latex files which will contain boiler-plate documentation.
  The Latex output should be able to produce an index for the 
  reference volume.

  Propose and get agreement on a textbook (linear algebra for dummies?)
  or an online course (linear algebra at ocw.mit.edu?) and develop a  
  tutorial based on the source material using Axiom. The tutorial should
  be organized so that it demonstrates a wide variety of Axiom's abilities
  such as graphics and the ability to generate user-defined browser pages.
  Ideally it should be useful for the classroom. 

  The subject matter could be chosen from any computational domain, e.g.
  math, physics, chemistry, biology, etc.

* literate documentation

  Axiom consists of literate programs. Each lisp, C, Makefile, etc is
  written by combining Latex and source code into a Latex document.
  At build time the source code and technical paper are extracted from
  these documents automatically.

  There are several thousand files in Axiom each of which needs to be
  understood and properly documented. Choose an algorithm (such as 
  the greatest common divisor) or an area (such as p-adic numbers) and
  provide the required documentation for the algorithms.

  Axiom is a worldwide project. It is used in multiple countries
  and runs on platforms like Red Flag Linux (Chinese). We have
  some introductory documentation in French but we need people 
  who can translate the book into any non-english language.

  This requires that you be fluent in both languages. The result
  should be a set of latex documents that are a complete translation
  of the original material

  Axiom has a browser and a graphics component. Both of these
  user interface components are written in C using X11 and are
  hard to port to Windows. We're experimenting with methods of
  creating a platform independent method of implementing these
  components. 

  Common Lisps can communicate with TK which provides a platform
  independent way of displaying graphics. We need to work out the
  lisp code necessary to read browser pages and render them as TK 
  pages

  An alternative project is to use a browser as the standard front
  end to both the Axiom browser and the graphics. We need to

  the wiki. 

  The task is to figure out how to get the wiki to accept the browser
  page syntax and how to inline graphics in wiki pages.

  Axiom has several hundred test cases that are run during the
  build of the system. Each of these test cases generate output.
  Create a systematic way of using this test suite for systematic
  regression testing and implement it.

  The result should be integrated into the Axiom Makefile machinery.

  Axiom has about 1100 "domains" which include about 11,000
  functions. We need to systematically create and organize a
  domain-by-domain set of reference test cases with 

* test graphics code

  The Graphics component on Axiom has not been systematically
  tested. Use the handbook of curves and surfaces to 
  comprehensively test the graphics routines.

  The result should be a set of input files which recreate
  all of the graphics in the CRC handbook and a set of bug
  reports that document failure cases.

  An alternative result is to modify the graphics code to
  handle the failure cases. This would require learning the
  details of C, X11, and the graphics code.

  Axiom uses Knuth's idea of literate programs as the basic file
  format for all of its code. There is a project called Doyen
  which needs to be able to drag-and-drop a literate program onto
  a running Axiom system and have that code and documentation 
  automatically added to the system. 

  Given a literate program that includes axiom algebra code and

++added:
  The result should be a working demonstration.


  As part of the build process Axiom generates hundreds of dvi
  files (output from Latex) that represent the documentation 
  associated with every source file. Currently these are minimally
  organized by directory. The task is to work out an automated way
  of organizing these files. One possibility is to organize the
  algebra file documentation according to the algebra lattice. 

  The output should a program that can be run to create the
  proper organization, likely as a Latex file.

  Pamphlets use random names in code chunks. Develop a full URL
  syntax and create a booklet mechanism. That is, one should be
  able to define a chunk as::

    <<file:///something>>

  and have something inserted inline or ::

    <<http:///something>>

  and have something inserted inline.

  The result should be a rewrite of the booklet command.

  In the future Axiom is intended to allow searches of the 
  computational literates (such as math papers) based on concepts.
  In order to do this we need to develop latex macros for marking 
  "concepts" in latex files. This will allow the author to mark
  up literate programs and math papers and create a concept index, 
  similar to the word index mechanism latex now uses.

  The result should be a latex.sty style file.

* flash integration

  Axiom does not know how to dynamically create flash files.
  The flash file format is open source.

  The task is to develop an interface that will allow algebra
  programs to generate flash animation output. An example is to
  compute and animate the surface wave of water struck by a 
  round pebble dropped from a given height.

++added:
  Axiom has permission to use the paper "Primes is in P" as
  example documentation. This paper is widely known. It has
  the theory, a proof of the theory, an algorithm and a proof
  of the algorithm. However it lacks an implementation in Axiom.

  Implement the algorithm as a literate program (we already have
  the paper as a pamphlet file) and integrate it into both the
  Axiom documentation and the Axiom sources.


++added:

  There is an algorithm for computing Symbolic Sums but 
  it is not currently implemented in Axiom. Study this
  algorithm and implement it.

  The result should be a literate program that can do
  symbolic summation in Axiom complete with a test suite.

* CATS, a Computer Algebra Test Suite

  There are many different computer algebra systems and they
  all develop their own ad-hoc test suites. These suites have
  no organizational structure nor any verified results. 

  The National Institute of Standards and Technologies (NIST)
  has a categorization of numerical mathematical algorithms.
  A similar categorization does not exist for symbolic math.

  The task would involve creating a taxonomy of symbolic
  math that provides reference problems with verified results
  as well as an implementation for these cases using Axiom.
  Note that the taxonomy should not be Axiom specific.

  The result would be a taxonomy, the reference cases, the
  Axiom cases, and the Makefile machinery to automate testing.
  There should also be bug reports filed for failure cases.

\start
Date: Wed, 01 Jun 2005 17:32:01 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [Summer of Code] 

++added:

* Magnus integration

  Magnus is an open source implementation of infinite group
  theory algorithms.

  These need to be extracted, documented, and implemented
  in Axiom

  The first result would be the category/domain hierarchy
  to support infinite group theory.

  The second and continuing result would be the implementation
  of the algorithms as literate programs.

\start
Date: Wed, 01 Jun 2005 19:35:35 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Summer of Code] some smaller-scale math projects

Here are a few more ideas for "math-oriented" summer
coding projects:

* expand Axiom's set of linear algebra algorithm's to
  include symbolic LU decomposition and other missing
  common operations

* extend the functionality of Axiom's non-commutative
  polynomial domains (XPOLY) to permit substitions and
  rule-based pattern matching.

* implement a new Axiom matematical category of directed graphs
  to serve as the foundation for several other projects ranging
  from the domain of categories (in the sense of category theory)
  to more pedesteran concerns such as data structures operations
  on graphs (based on graph theory) and integration of tools for
  the efficient display of large graphs (of particular interest
  to future maintenance and development of complex dependency
  structure of the Axiom library itself).

\start
Date: Wed, 01 Jun 2005 20:24:35 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [Summer of Code] 

* Expand Axiom's set of linear algebra algorithm's to

  common operations.

* Extend the functionality of Axiom's non-commutative

++added:
* Graph the algebra lattice

  Axiom has a large type lattice that needs to be documented.
  One of the key tools for understanding the dependent relations
  would be a graph of the lattice. The current graph would include
  about 1100 nodes and, so far, has resisted efforts to construct
  a graph.

  The result would be a graph, likely using a dynamic visualization
  tool since printing it would not be useful.

>From BillPage Wed Jun 1 13:47:08 -0500 2005
From: Bill Page
Date: Wed, 01 Jun 2005 13:47:08 -0500
Subject: Axiom Foundation

Google's *Summer of Code* requires a
"Mentoring Organization":http://code.google.com/mentfaq.html

I think the [Axiom Foundation] would be ideal for this purpose.
Let's try to get the [Axiom Foundation] added to the list at
http://code.google.com/summerofcode.html

\start
Date: Thu, 2 Jun 2005 09:05:56 +0200
From: Martin Rubey
To: Bob McElrath
Subject: Re: summer of code

Bob McElrath writes:
 > Tim Daly [Tim Daly] wrote:
 > > 
 > > We can certainly provide a site of ideas (I've already listed about
 > > 10 on the google site) but we need someone to volunteer as a backup.
 > 
 > I'd like to volunteer to mentor someone to write a field theory module
 > (a la FeynCalc) for Axiom.
 > 
 > Most of the ideas on SummerOfCode are "janitor" duties, and those that
 > are not would appeal mostly to CS students.
 > 
 > Let's try to get some people working on mathematics?

In fact, *that* was my intention. Not the things that Tim listed. I'd like to
have somebody work on 

  Rational Interpolation
 
  Solving Inequalities

  Porting hyp/hypq

and more generally, those items on the WishList.

\start
Date: Thu, 2 Jun 2005 09:31:12 +0200
From: Martin Rubey
To: Bill Page, Tim Daly, Bob McElrath
Subject: Summer of Code / WishList

I think that the SummerOfCode Page is a great start. However, many items
coincide with the items on the WishList, but have additional pointers there. I
"maintained" the WishList page for exactly this purpose and tried to keep it
"tidy".

I suggest that we try to merge the two pages. (I won't have time until Friday
evening)

\start
Date: Thu, 2 Jun 2005 08:14:18 -0500
From: Tim Daly
To: list
Subject: summer of code

All,

Axiom has been accepted as a Summer of Code project.

This represents a great opportunity for us as we can get paid
labor to work on particular topics. And it represents an interesting
experiment in open source support.

I need some people to volunteer to review the students resumes.

I'm in the process of switching jobs (from CCNY to CMU) which
will involve a move so my net connection might be interrupted
for a short while.

\start
Date: Thu, 2 Jun 2005 08:17:48 -0500
From: Tim Daly
To: Martin Rubey
Subject: summer of code

Martin,

Please try to merge your WishList items with the Summer of Code page.

The people we can hire are required to be students so it is not clear
that they can handle particularly difficult problems (unless they
happen to be exceptionally talented) within the span of a summer.

I've tried to make sure that every SOC item has an expected
result or deliverable. We need some goal or measure to decide
if the work was reasonably performed.

\start
Date: Thu, 2 Jun 2005 08:56:20 -0500
From: Tim Daly
To: hitchhiker2004@gmail.com, Heow Eide-Goodman
Subject: summer of code

Heow, Dan,

There seems to be a bit of confusion about whether Axiom is or is
not a sponsoring organization. I've received an letter from Chris
DiBona saying we are yet he posted an entry saying we are not.

Dan contacted me with an interest in doing a summer of code project.
Since the NYC group is a sponsoring organization perhaps you can work
on one of their projects.

Tim

\start
Date: Thu, 2 Jun 2005 08:54:27 -0500
From: Tim Daly
To: Kai Kaminski, Heow Eide-Goodman
Subject: summer of code

Heow, Kai,

Heow, congrats on being accepted.

There seems to be a bit of confusion about whether Axiom is or is
not a sponsoring organization. I've received an letter from Chris
DiBona saying we are yet he posted an entry saying we are not.

On our list (http://page.axiom-developer.org/zope/mathaction/SummerOfCode)
we list two projects that Kai Oliver Kaminski is interested in. 

The first is the platform independent user interface using Common Lisp
and TK. We have a couple axiom features that we cannot port and we need
them rewritten in common lisp. After much debate TK seems to be the
front-runner for platform GUI graphics.

The second is the "drag-and-drop" question. If you remember during the
talk I gave to NYC CL last month I mentioned literate programming
(combining code and latex). We'd like to be able to use these literate
programs in a drag-and-drop manner.

Frankly for the short term I'm much more interested in the CL/TK issue
for the short term as the Axiom Windows port is wildly successful yet
we still have no graphics. Thus this project will have a much larger
impact in the short term. However either project is fine with me.

How can we work out the details on this?

\start
Date: Thu, 2 Jun 2005 08:33:58 -0500
From: Tim Daly
To: Chris DiBona
Subject: summer of code

Chris,

I'm confused. 

I received an letter from you last night accepting Axiom as a
mentoring organization with an invitation to join the private
summer-administrators newgroup. I joined and replied to the
(Who'se is on this list?) entry. You can see my entry at 12:14am.

You placed an entry in the summer-discuss newsgroup item
(Axiom Computer Algebra Project) at 2:37am suggesting that Axiom
was not supported.

Are we in or are we out?

\start
Date: Thu, 2 Jun 2005 09:02:09 -0500
From: Tim Daly
To: Martin Rubey
Subject: summer of code

Martin,

At 12:14 AM this morning we were approved as a sponsoring project.
I received a letter from Chris DiBona and was given access to the
private summer-administrators newsgroup where I posted.

At 2:37 Chris posted a note in the summer-discuss newsgroup saying
we were not accepted but I've gotten no mail to that effect. We
are not listed on the master list but Chris noted that there were
still several projects to go.

Thus we appear to be in a limbo state.

I've sent a note to Chris and posted a note in the summer-administrators
newsgroup but so far have not heard a reply.

\start
Date: 02 Jun 2005 10:09:33 -0400
From: Heow Eide-Goodman
To: Tim Daly
Subject: Re: summer of code
Cc: hitchhiker2004@gmail.com

Dan, Tim,

LispNYC would be more than happy to sponsor Axioms projects, so
regardless of the outcome hard decisions don't have to be made.

- Heow

\start
Date: Thu, 02 Jun 2005 11:22:14 -0400
From: William Sit
To: Tim Daly
Subject: Re: summer of code

Tim Daly wrote:
 
> Axiom has been accepted as a Summer of Code project.

Great, although I noted that you later said we are in limbo.

> This represents a great opportunity for us as we can get paid
> labor to work on particular topics. And it represents an interesting
> experiment in open source support.

> I need some people to volunteer to review the students resumes.

Count me in. I have edited the Summer of Code page to add item labels so it
would be easy to refer to potential students and they can simply provide the
item labels of the projects they like.

At the bottom of the page is a section for mentors. I am hoping that volunteers
will insert their information (in alphabetical order by last name) there. I put
yours in and hope that all student applications should be channeled through you
(please check the page to see if that is ok).

> I'm in the process of switching jobs (from CCNY to CMU) which
> will involve a move so my net connection might be interrupted
> for a short while.
 
Wishing you the best at CMU,

\start
Date: Thu, 02 Jun 2005 10:58:32 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Summer of Code] Other Axiom-related projects

Although I am sure that we have enough projects listed above
to keep an army of students busy for several years, I think
creating this list is a very useful exercise in and of itself.

Maybe another category would be a good idea. Something like:

 VI AXIOM-RELATED PROJECTS

  1 Complete the (re-)integration of the
    "Aldor compiler":http://www.aldor.org
    into the open source version of Axiom.

    Aldor (previously known as the AXIOMXL library compiler)
    is a stand alone compiler that is compatible with the
    AXIOM SPAD programming language. Aldor can be used to
    write new algorthms and more efficient versions of existing
    library code.

  2 Extensions to MathAction - the Axiom Wiki

    1 Extend the interface to Axiom to permit display
      of Axiom graphics on MathAction

      Axiom graphics requires the X-windows environment. This
      can be done on the server using the virtual framebuffer
      driver Xfbdev and fbrun or gRun.

      When Axiom is run to process commands from a wiki page
      the Axiom command, e.g.::

        viewport1 := draw(sin x, x=-%Pi..Pi)

      needs to be able to communicate with the graphics
      processor in the X-windows environment to create the
      graphic image. Additional Axiom commands can write
      this to a postscript file and display in on the
      web page. E.g.::

        write(viewport1, "graphic1.ps")
        \\begin{latex}
        \\psfig {graphic1.ps} ...
        \\end{latex}

    2 Add web interfaces to other open source mathematical
      
      In addition to Axiom, MathAction already has interfaces
      to several other packages including Reduce and Graphvz.
      Interfaces to other open source mathematical packages
      such as listed on the RosettaStone page could help to
      build a stronger community amoung mathematical software
      developers. This in turn would lead to improvements in
      Axiom and all related packages.

\start
Date: Thu, 2 Jun 2005 13:32:06 -0500
From: Tim Daly
To: list
Subject: summer of code

*,

I just heard back from Chris DiBona, the person running the google
Summer of Code project. Axiom was withdrawn and my admin access was 
cancelled.

Heow Eide-Goodman is the leader of the Lisp NYC group where I gave
my talk last month. He's one of the accepted groups and he is 
interested in cooperating with us on this. Please direct any
requests to Heow Eide-Goodman

\start
Date: Thu, 2 Jun 2005 15:22:42 -0400
From: Bill Page
To: Tim Daly
Subject: RE: summer of code

Tim,

On June 2, 2005 2:32 PM you wrote:

> I just heard back from Chris DiBona, the person running
> the google Summer of Code project. Axiom was withdrawn
> and my admin access was cancelled.

:((

Were any specific reasons given for this decision?
Of course Google only has so much money :) and they
can't fund everyone etc., etc.

But it might be useful to know what we did wrong...

\start
Date: Thu, 2 Jun 2005 15:30:21 -0500
From: Tim Daly
To: list
Subject: summer of code

*,

The latest version is up in the arch archive,
soon to be pushed to the sourceforge and savannah sites
once "round-trip" testing completes.

Release was delayed due to moving and google summer effort.

Tim

==============================================================
20050502 tpd --patch-38
20050502 tpd src/interp/setq.lisp add Evelyn Zoernack
20050502 tpd README add Evelyn Zoernack
20050502 tpd src/interp/setq.lisp add Sandra Wityak
20050502 tpd README add Sandra Wityak
20050502 tpd src/interp/setq.lisp add Claire Di Crescenzo
20050502 tpd README add Claire Di Crescenzo
20050502 tpd src/interp/setq.lisp add Howard Levy
20050502 tpd README add Howard Levy
20050502 tpd src/interp/setq.lisp add Paul Kosinski
20040502 tpd README add Paul Kosinski
20050528 tpd src/boot/Makefile respect NOISE flag
20050528 tpd src/interp/Makefile respect NOISE flag
20050528 tpd src/input/Makefile add VIEW2D.output
20050528 tpd src/algebra/Makefile add VIEW2D.input test
20050528 tpd src/algebra/view2D.spad document making multiple graphs
20050521 tpd FAQ 32 added

\start
Date: Thu, 2 Jun 2005 19:15:15 -0500
From: Tim Daly
To: Chris DiBona
Subject: summer of code

re: mistakes. no problem. the confusion passes.

Despite the fact that Axiom didn't make the list I'm happy
to see that Google is willing to help the open source community
with funding. It's a key issue and this is a good model.

I was previously with City College of New York and will shortly
be at CMU. We had an open source lab at CCNY but there was no
external funding source so it is not really a sustainable model.
The NSF, a traditional fund source, is unwilling to fund open source.

Year long academic grants would be more effective because it
takes a long time to get familiar with projects as complex as Axiom.

If google grants were available to students during the school
year we could certainly have employed more than the 3 students
we could afford. At CCNY I led three open source projects 
(axiom: http://page.axiom-developer.org,
magnus: http://sourceforge.net/projects/magnus, and
doyen: http://daly.axiom-developer.org/doyen).

If there is any interest in helping fund students at university 
open source labs I have people you can contact. There are a few good
students I've met who are quite effective and capable of making
a strong contribution to open source projects. Google could make
a major difference here by helping both students and schools.

In any case, thank you for your efforts.

\start
Date: Fri, 03 Jun 2005 02:51:14 +0200
From: Gregory Vanuxem
To: list
Subject: http://page.axiom-developer.org/zope/mathaction/SummerOfCode

Hi,

About,

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

May be add reference to XML for documentation project.

I think, if this will be accepted, to add a 
reference's link to a generic 'translator'
("public" XML engine).
 
PS:I  think we need a portable language.

\start
Date: Thu, 02 Jun 2005 19:37:56 -0500
From: MathAction (Billinghurst,	David (CALCRTS))
To: MathAction
Subject: [Axiom-mail] Google Summer of Code

I just noticed the Google "Summer of Code" program at http://code.google.com/summerofcode.html.  This may be of interest to some readers of this list.

LispNYC are a sponsoring organisation and have a list of possible projects at http://www.lispnyc.org/summerofcode.html

\start
Date: Fri, 3 Jun 2005 08:52:54 +0200
From: Martin Rubey
To: Bill Page, Tim Daly, Heow Eide-Goodman
Subject: Summer Of Code

Dear Heow (especially!), dear Tim, Bill,

since is not going to be supported (would have been to good to be true), I
would like to embrace your offer, Heow!

Looking through the WishList and SummerOfCode page, I find the following two
projects which are probably Lisp related:

II. 1. work on the windows version of the browser and graphics

(this is definitely Lisp)

VI. 1. Complete the (re-)integration of the Aldor compiler into the open source
version of Axiom.

(not sure about this one. Certainly more difficult, however. On the other hand,
since Lisp is *the* language for implementing languages and Aldor is completely
specified, maybe it would be worthwhile and not too difficult to write a little
Aldor compiler in Lisp? -- even though this is sort of a different goal then
VI. 1.)

see

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

for details.

It would be wonderful, wonderful, wonderful if one or both of these projects
would be completed.

\start
Date: Fri, 03 Jun 2005 06:22:46 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomProblem] Axiom fails to solve "separable" system of equations

This doesn't work on mine michen:
\begin{axiom}
L := [ A = 2*P1+P2, B = 2*P2+P1, C = 2*Q1+Q2, D = 2*Q2+Q1]
solve(L, [P1,P2])
\end{axiom}
But it should, observe this:
\begin{axiom}
solve([L.1,L.2],[P1,P2])
solve([L.3,L.4],[Q1,Q2])
\end{axiom}
First two equationa do not depend on $Q_i$, the later two don't depend on $P_i$.

\start
Date: Fri, 03 Jun 2005 15:01:54 +0200
From: Francois Maltey
To: list
Subject: how to expand trig functions ?

Hello, 

I play with expand(sin(...)) :

expand (sin (x+y)) is right, but 

1/ I can't get expand (sin (2*x)) 

2/ The result of expand (sin (x+y+z)) doesn't seem complete. 
   axiom only apply twice the expanded sin (a+b) and cos (a+b).
   I prefer the maple and mupad method. The formula is completly expanded.

Is there a reason for this ?

Do you think the axiom-code must remain as now ?
or is it possible to improve it ? If you think so, I propose to look at this.

Am I right when I see it's comming from this src/algebra/manip.spad file ?

)abbrev package TRMANIP TranscendentalManipulations
++ Transformations on transcendental objects
++ Author: Bob Sutor, Manuel Bronstein
++ Date Created: Way back
++ Date Last Updated: 22 January 1996, added simplifyLog MCD.
++ Description:
++   TranscendentalManipulations provides functions to simplify and
++   expand expressions involving transcendental operators.
++ Keywords: transcendental, manipulation.
TranscendentalManipulations(R, F): Exports == Implementation where
  R : Join(OrderedSet, GcdDomain)
  F : Join(FunctionSpace R, TranscendentalFunctionCategory)
...

\start
Date: Fri, 3 Jun 2005 15:32:14 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: how to expand trig functions ?

 > Do you think the axiom-code must remain as now ?

No. It MUST NOT (il ne doit pas) stay as it is :-)

 > or is it possible to improve it ? If you think so, I propose to look at
 > this.

It is your DUTY to improve it :-)

\start
Date: Fri, 3 Jun 2005 09:07:39 -0500
From: Tim Daly
To: Francois Maltey
Subject: how to expand trig functions

Francois,

I'm not sure which package the expansion functions use. If you type

)set message bottomup on

you can see the function mappings the interpreter tries to use.
>From these you can probably find the functions used.

Axiom code certainly has to change but the changes are going to
be carefully checked, documented, and tested.

\start
Date: Fri, 3 Jun 2005 09:19:33 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: ALPS

Ralf,

Both links you sent me point to the same file.
The "color" sections show up a big black-filled boxes.

The parts of the document I can read look very interesting, however.
I'll read over those parts and see if we can work together on improving
the standard of literate programming in Axiom. 

\start
Date: 03 Jun 2005 12:00:35 -0400
From: Camm Maguire
To: Mike Thomas
Subject: Re: [Gcl-devel] RE: building Axiom with GCL Version_2_6_7pre fails

So 2.6.7pre is axiom ready vis-a-vis this issue?  (I know gcl-tk is
still pending.)  (How is the axiom gcl-tk gui coming?)

Take care,

Mike Thomas writes:

> Hi Bill.
> 
> | I think that there is one more place in daase.lisp.pamphlet
> | near you last patch where probe-file should be changed to
> | truename:
> |
> |   (dolist (dir dirlist)
> |           (localdatabase nil
> |                          (list (list '|dir|
> |                                      (namestring (probe-file
> |                                                   (format nil "./~a"
> |                                                           dir)))))
> |                          'make-database))
> 
> I ignored that as it didn't break the build, so I'll leave you to decide and
> prepare the official patch modding the above or otherwise.

\start
Date: 03 Jun 2005 12:07:20 -0400
From: Camm Maguire
To: Mike Thomas
Subject: re: [Gcl-devel] Possible GCL 2.6.7 for axiom
Cc: Bill Page

Mike Thomas writes:

> Hi Camm.
> 
> |   6) On Windows (at least) GCL 2.6.6 Axiom (not 2.6.5) has a problem with
> | equation system solutions:
> | ===========================================
> | (1) -> solve([3*x**3+y+1,y**2-4],[x,y])
> |    Loading C:/Program Files/axiom/mnt/windows/algebra/UPMP.o for
> |       package UnivariatePolynomialMultiplicationPackage
> |
> |    >> System error:
> |    The function SYSTEM::DEBUGGER is undefined.
> |
> | protected-symbol-warn called with (NIL)
> | (1) -> solve([3*x**3+y+1,y**2-4],[x,y])
> |
> |    >> System error:
> |    Arg or result mismatch in call to  |devaluateList|
> |
> | protected-symbol-warn called with (NIL)
> |
> | ===========================================
> 
> 
> On the subject of AXIOM, Windows and surrent directories I just got to the
> bottom of the above bug too.
> 
> The problem occurs when the AXIOM environment variable is set globally to
> one particular AXIOM system while running an AXIOMsys.exe from a separate
> AXIOM system (eg in my case, my development source tree).
> 
> This causes the second system to load object files from the first Axiom
> system causing objections about missing functions (in my particular case the
> function SYSTEM::DEBUGGER which is relatively new).
> 
> I would suggest removal of the the AXIOM environment variable at least on
> the global level, or better, completely.
> 
> I also suggest avoiding a wrapper batch file as that will be fraught with
> other difficulties - notably the absence of a simple way to get the working
> directory in batch files on all versions of Windows, but also because it
> usually poor programming practice on Windows to use application-specific
> environment variables.  Nor would it be appropriate in this instance to use
> the Windows registry.
> 
> The right thing to do I think is to add a new crossplatform GCL system
> package function "get-current-directory" - a relatively simple task for the
> platforms upon which GCL currently runs.
> 

No problem adding a GCL function, but the axiom environment variable
issue is a question for Tim, I think.

\start
Date: Fri, 3 Jun 2005 12:02:00 -0500
From: Tim Daly
To: Kai Kaminski, Heow Eide-Goodman
Subject: Axiom/TK project

Axiom runs on multiple systems but there are two GUI components,
the browser and the graphics, that are not portable. They are
written in C using X11.

The Axiom/TK project will recreate the same functionality using
lisp and TK. Since both of these systems run on all platforms
we will eliminate the portability problem and remove the remaining
portion of C code from Axiom.

The tasks are listed below and are designed as steps that show progress
in small increments that could take anywhere from a day to two weeks.

The project has two subgoals, a running browser and a running graphics.

The browser steps are:

Get a running lisp
  GCL is preferred but any common lisp will do
Get a running TK
  Initially we can use a binary version
  Later we need to build it from sources
Connect lisp and TK
  TK uses sockets so the lisp must handle sockets
  GCL has an LTK (Lisp-TK) package but it is untested
Show primitive capability
  A newly started lisp should be able to start TK 
Show the first browser screen
  The first browser screen layout should be created from lisp
Show an image in the browser screen
  The browser shows images in the browser so this must be demonstrated
Handle the buttons
  The browser uses buttons for navigation so callbacks must be handled
Handle the hyperlink
  The browser uses callbacks to find the next page and open other windows
Handle user input
  The browser has text input which needs to be transmitted back to lisp
Handle fonts
  The browser uses bold and italic fonts
Parse the browser pages
  The browser uses a latex style page language which must be parsed in lisp.
Connect to Axiom
  The browser connects to the running Axiom thru sman and sockets
Send commands to Axiom
  The browser sends commands to Axiom thru sockets
Receive commands from Axiom
  Axiom sends page commands to the browser

The graphics subtask is very similar to the above and builds on the same code.
However there are additional requirements.

Draw in a window
  Initially we need to open a window and draw a line between two points
Open a command window
  Clicking on the graph opens a command window with controls
Handle dual window interactions
  Clicking on control buttons needs to change the graph
Handle rotate, translate
  The graphics controls know how to rotate and translate the graph
Handle 2D drawing
  Axiom has code that knows how to scale, draw axes, etc
Handle 3D drawing
  Axiom knows how to shade and smooth 3D objects
Handle Axiom requests
  Axiom sends point lists to the graphics
Handle Axiom commands
  Axiom can command rotations, shading, etc

\start
Date: Fri, 3 Jun 2005 12:05:57 -0500
From: Tim Daly
To: Kai Kaminski, k0k@gmx.de, Heow Eide-Goodman
Subject: Axiom/TK project (resend)

Axiom runs on multiple systems but there are two GUI components,
the browser and the graphics, that are not portable. They are
written in C using X11.

The Axiom/TK project will recreate the same functionality using
lisp and TK. Since both of these systems run on all platforms
we will eliminate the portability problem and remove the remaining
portion of C code from Axiom.

The tasks are listed below and are designed as steps that show progress
in small increments that could take anywhere from a day to two weeks.

The project has two subgoals, a running browser and a running graphics.

The browser steps are:

Get a running lisp
  GCL is preferred but any common lisp will do
Get a running TK
  Initially we can use a binary version
  Later we need to build it from sources
Connect lisp and TK
  TK uses sockets so the lisp must handle sockets
  GCL has an LTK (Lisp-TK) package but it is untested
Show primitive capability
  A newly started lisp should be able to start TK 
Show the first browser screen
  The first browser screen layout should be created from lisp
Show an image in the browser screen
  The browser shows images in the browser so this must be demonstrated
Handle the buttons
  The browser uses buttons for navigation so callbacks must be handled
Handle the hyperlink
  The browser uses callbacks to find the next page and open other windows
Handle user input
  The browser has text input which needs to be transmitted back to lisp
Handle fonts
  The browser uses bold and italic fonts
Parse the browser pages
  The browser uses a latex style page language which must be parsed in lisp.
Connect to Axiom
  The browser connects to the running Axiom thru sman and sockets
Send commands to Axiom
  The browser sends commands to Axiom thru sockets
Receive commands from Axiom
  Axiom sends page commands to the browser

The graphics subtask is very similar to the above and builds on the same code.
However there are additional requirements.

Draw in a window
  Initially we need to open a window and draw a line between two points
Open a command window
  Clicking on the graph opens a command window with controls
Handle dual window interactions
  Clicking on control buttons needs to change the graph
Handle rotate, translate
  The graphics controls know how to rotate and translate the graph
Handle 2D drawing
  Axiom has code that knows how to scale, draw axes, etc
Handle 3D drawing
  Axiom knows how to shade and smooth 3D objects
Handle Axiom requests
  Axiom sends point lists to the graphics
Handle Axiom commands
  Axiom can command rotations, shading, etc

\start
Date: Fri, 03 Jun 2005 15:30:24 -0500
From: MathAction (Bob McElrath)
To: MathAction
Subject: [Summer of Code] 

"Linux Fund":http://www.linuxfund.org/ may be another source of funds
for work on axiom.

\start
Date: Fri, 03 Jun 2005 15:27:34 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [AxiomTK] (new) 

Axiom runs on multiple systems but there are two GUI components,
the browser and the graphics, that are not portable. They are
written in C using X11.

The Axiom/TK project will recreate the same functionality using
lisp and TK. Since both of these systems run on all platforms
we will eliminate the portability problem and remove the remaining
portion of C code from Axiom.

The tasks are listed below and are designed as steps that show progress
in small increments that could take anywhere from a day to two weeks.

The project has two subgoals, a running browser and a running graphics.

The browser steps are:

Get a running lisp
  GCL is preferred but any common lisp will do
Get a running TK
  Initially we can use a binary version
  Later we need to build it from sources
Connect lisp and TK
  TK uses sockets so the lisp must handle sockets
  GCL has an LTK (Lisp-TK) package but it is untested
Show primitive capability
  A newly started lisp should be able to start TK 
Show the first browser screen
  The first browser screen layout should be created from lisp
Show an image in the browser screen
  The browser shows images in the browser so this must be demonstrated
Handle the buttons
  The browser uses buttons for navigation so callbacks must be handled
Handle the hyperlink
  The browser uses callbacks to find the next page and open other windows
Handle user input
  The browser has text input which needs to be transmitted back to lisp
Handle fonts
  The browser uses bold and italic fonts
Parse the browser pages
  The browser uses a latex style page language which must be parsed in lisp.
Connect to Axiom
  The browser connects to the running Axiom thru sman and sockets
Send commands to Axiom
  The browser sends commands to Axiom thru sockets
Receive commands from Axiom
  Axiom sends page commands to the browser

The graphics subtask is very similar to the above and builds on the same code.
However there are additional requirements.

Draw in a window
  Initially we need to open a window and draw a line between two points
Open a command window
  Clicking on the graph opens a command window with controls
Handle dual window interactions
  Clicking on control buttons needs to change the graph
Handle rotate, translate
  The graphics controls know how to rotate and translate the graph
Handle 2D drawing
  Axiom has code that knows how to scale, draw axes, etc
Handle 3D drawing
  Axiom knows how to shade and smooth 3D objects
Handle Axiom requests
  Axiom sends point lists to the graphics
Handle Axiom commands
  Axiom can command rotations, shading, etc

\start
Date: 03 Jun 2005 15:29:56 -0400
From: Heow Eide-Goodman
To: Tim Daly
Subject: Re: Axiom/TK project (resend)
Cc: Kai Kaminski

Tim, Kai et al,

There is no discussion on the SoC-admin list regarding Google's
application form.  There are scant mentionings of this on the
SoC-discussion list, but then again there are 352 messages since
yesterday!  ...so I'm relying on my seaching skills rather than my
patience.

Regardless, it looks like there is no feedback from Google.  So I'd
treat this much like a job application form:

  1. be polite
  2. no stupid mistakes
  3. cross Ts, dot Is

Using those steps should put us one step above the "unwashed masses",
other than that I'm going to re-read the FAQs to try and read their
minds.  :-)

For instance:

    Google believes that there are more Open Source Developers
    out in the world waiting to be discovered and that this
    program might help reveal who they are.

...might help us determine Google's motivation.


\start
Date: Sat, 4 Jun 2005 23:02:53 -0500
From: Tim Daly
To: list
Subject: savannah, sourceforge cvs

The savannah and sourceforge CVS versions have been brought up to date
as of --patch-39

\start
Date: Sun, 05 Jun 2005 05:15:25 -0500
From: MathAction (unknown)
To: MathAction
Subject: [mirrors] Splitting Axiom

Yes, it is indeed a good idea to split the windows package.
Also separate the gui, the text interface, documentation, and tutorials. Make them available separately so that one can down load the axiom "kernel" first then the gui/tutorials samples etc as and when required. Also, many people already have some TeX implementation for windows. For them size will be the only concern.
Most of the people have limited bandwidth. Why inhibit them from  using axiom because of d/l speed.

\start
Date: Tue, 07 Jun 2005 05:08:07 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#164 min row and min col in IndexedOneDimensionalArray's IndexedTwoDimensionalArray ] (new) 

In array2.spad

<pre>
\section{domain IARRAY2 IndexedTwoDimensionalArray}
<<domain IARRAY2 IndexedTwoDimensionalArray>>=
)abbrev domain IARRAY2 IndexedTwoDimensionalArray
IndexedTwoDimensionalArray(R,mnRow,mnCol):Exports == Implementation where
  ++ An IndexedTwoDimensionalArray is a 2-dimensional array where
  ++ the minimal row and column indices are parameters of the type.
  ++ Rows and columns are returned as IndexedOneDimensionalArray's with
  ++ minimal indices matching those of the IndexedTwoDimensionalArray.
  ++ The index of the 'first' row may be obtained by calling the
  ++ function 'minRowIndex'.  The index of the 'first' column may
  ++ be obtained by calling the function 'minColIndex'.  The index of
  ++ the first element of a 'Row' is the same as the index of the
  ++ first column in an array and vice versa.
  R : Type
  mnRow, mnCol : Integer
  Row ==> IndexedOneDimensionalArray(R,mnCol)
  Col ==> IndexedOneDimensionalArray(R,mnRow)
                                      ^^^^^^


  Exports ==> TwoDimensionalArrayCategory(R,Row,Col)

  Implementation ==>
    InnerIndexedTwoDimensionalArray(R,mnRow,mnCol,Row,Col)
</pre>

In IndexedOneDimensionalArray(*)
</br>
Col => min index of row (mnRow)
</br>
Row => min index of column (mnCol)
</br>
Is it a bug ?

\start
Date: 07 Jun 2005 09:52:34 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Axiom/TK project
Cc: Heow Eide-Goodman, Kai Kaminski

Hi Tim!  Just checking here as I know you've already done some work on
the gcl-tk first page I sent.  What's the current status?

It would appear that almost all the issues mentioned below are already
worked out in gcl-tk, at least on Linux at the moment, leaving only
the relatively simple but perhaps tedious job of writing the lisp
functions for the various pages.  No?

Take care,

Tim Daly writes:

> Axiom runs on multiple systems but there are two GUI components,
> the browser and the graphics, that are not portable. They are
> written in C using X11.
> 
> The Axiom/TK project will recreate the same functionality using
> lisp and TK. Since both of these systems run on all platforms
> we will eliminate the portability problem and remove the remaining
> portion of C code from Axiom.
> 
> The tasks are listed below and are designed as steps that show progress
> in small increments that could take anywhere from a day to two weeks.
> 
> The project has two subgoals, a running browser and a running graphics.
> 
> The browser steps are:
> 
> Get a running lisp
>   GCL is preferred but any common lisp will do
> Get a running TK
>   Initially we can use a binary version
>   Later we need to build it from sources
> Connect lisp and TK
>   TK uses sockets so the lisp must handle sockets
>   GCL has an LTK (Lisp-TK) package but it is untested
> Show primitive capability
>   A newly started lisp should be able to start TK 
> Show the first browser screen
>   The first browser screen layout should be created from lisp
> Show an image in the browser screen
>   The browser shows images in the browser so this must be demonstrated
> Handle the buttons
>   The browser uses buttons for navigation so callbacks must be handled
> Handle the hyperlink
>   The browser uses callbacks to find the next page and open other windows
> Handle user input
>   The browser has text input which needs to be transmitted back to lisp
> Handle fonts
>   The browser uses bold and italic fonts
> Parse the browser pages
>   The browser uses a latex style page language which must be parsed in lisp.
> Connect to Axiom
>   The browser connects to the running Axiom thru sman and sockets
> Send commands to Axiom
>   The browser sends commands to Axiom thru sockets
> Receive commands from Axiom
>   Axiom sends page commands to the browser
> 
> The graphics subtask is very similar to the above and builds on the same code.
> However there are additional requirements.
> 
> Draw in a window
>   Initially we need to open a window and draw a line between two points
> Open a command window
>   Clicking on the graph opens a command window with controls
> Handle dual window interactions
>   Clicking on control buttons needs to change the graph
> Handle rotate, translate
>   The graphics controls know how to rotate and translate the graph
> Handle 2D drawing
>   Axiom has code that knows how to scale, draw axes, etc
> Handle 3D drawing
>   Axiom knows how to shade and smooth 3D objects
> Handle Axiom requests
>   Axiom sends point lists to the graphics
> Handle Axiom commands
>   Axiom can command rotations, shading, etc

\start
Date: Tue, 07 Jun 2005 13:45:36 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#164 min row and min col in IndexedOneDimensionalArray's IndexedTwoDimensionalArray ] 

No, this is correct. A one-dimensional row vector has columns, and the number of columns need to be specified as mnCol. Similarly, a one-dimensional column vector has rows, and the number of rows need to be specified as mnRow.

\start
Date: Tue, 07 Jun 2005 14:46:29 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#164 min row and min col in IndexedOneDimensionalArray's IndexedTwoDimensionalArray ] Exact

mnCol is minimal column index used, for example, in row creation after extraction.

\start
Date: Wed, 08 Jun 2005 11:20:46 -0500
From: MathAction (unknown)
To: MathAction
Subject: [build Axiom] 

\begin{axiom}
solve([a**2*x+b*x+c],[x])
\end{axiom}

\start
Date: Wed, 08 Jun 2005 16:08:07 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#44 IssueTracker needs to be able to use old Axiom versions] 

One day the Axiom running on MathAction will be updated, which is
fine, but then all the "live failures" provided on IssueTracker will
vanish. Thus I propose to provide an optional argument to the
axiom-environment, which specifies which axiom to run:

\start
Date: Wed, 08 Jun 2005 17:10:31 -0500
From: MathAction (unknown)
To: MathAction
Subject: [MathAction problems] Sandbox optimization

Obviously, this page is not used to report problems?

Is there any way to break Sandbox into pages and still retain the
no-email property? The sandbox now has lots of computation and each
change seem to require all of these to be recomputed (is that right)?
So separating these into pages (that is, allowing anyone to create a
new Sandbox page) will allow a more organized and efficient display.

\start
Date: Wed, 08 Jun 2005 19:01:14 -0500
From: MathAction (billpage)
To: MathAction
Subject: [MathAction problems] You can report MathAction problems in IssueTracker

but I don't mind if you find this more convenient for comments
like this.

I thought your idea was a good one, so I have changed MathAction
so that all pages whose name starts with SandBox will be
*quiet pages*, i.e. editing and creating new such pages will
not generate email notices of any kind.

Let me know if this seems ok.

\start
Date: Wed, 08 Jun 2005 19:04:09 -0500
From: MathAction (billpage)
To: MathAction
Subject: [MathAction problems] You can report MathAction problems in IssueTracker

Some special Axiom-specific LaTeX commands might not be understood
by MathAction. For example::

This LaTeX definition has to go in the preamble that is stored in
the wiki page LatexTemplate. This template is used when LaTeX
commands are converted to images. \\zag is used in the output
generated by the following commands:

\start
Date: Thu, 09 Jun 2005 01:33:36 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [Guessing Sequence] (new) 

This page makes test uses of the Guess package by Martin Rubey. Feel free to change the sequence to ones you like to try.

We need to load these packages:

\begin{axiom}
)lib RINTERPA RINTERP PCDEN GUESS GUESSINT GUESSP
\end{axiom}

Click [Guess] for the source code.

\begin{axiom}
guessExpRat(n,[(1+x)^x for x in 1..4],i+->i)$GUESSINT
\end{axiom}

A workaround is necessary, because of bug #128

\begin{axiom}
l := [1, 1, 1+q, 1+q+q^2, 1+q+q^2+q^3+q^4, 1+q+q^2+q^3+2*q^4+q^5+q^6, 1+q+q^2+q^3+2*q^4+2*q^5+2*q^6+q^7+q^8+q^9, (1+q^4+q^6)*(1+q+q^2+q^3+q^4+q^5+q^6), (1+q^4)*(1+q+q^2+q^3+q^4+q^5+2*q^6+2*q^7+2*q^8+2*q^9+q^10+q^11+q^12)]

(guessPRec(n,l,i+->q^i)$GUESSP).1
\end{axiom}

\begin{axiom}
listA := [1, 9, 113, 1719, 28981, 521103];
listB := [1, 9,  49,  279,  1793,  12441];
listC := [1, 9, 113, 1711, 28729, 514615];
listD := [1, 9,  49,  271,  1613,  10013];
guessExpRat(n,listA,i+->i)$GUESSINT
guessPRec(n,listA,i+->i)$GUESSP
guessExpRat(n,listB,i+->i)$GUESSINT
guessPRec(n,listB,i+->i)$GUESSP
guessExpRat(n,listC,i+->i)$GUESSINT
guessPRec(n,listC,i+->i)$GUESSP
guessExpRat(n,listD,i+->i)$GUESSINT
guessPRec(n,listD,i+->i)$GUESSP
\end{axiom}

\start
Date: Thu, 09 Jun 2005 01:33:35 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [Guessing Sequence] (renamed)

This page was renamed from QuestionMark to Guessing Sequence.

\start
Date: Thu, 09 Jun 2005 04:30:22 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [MathAction problems] Sandbox breaking up

Great, and thanks. So it's time to break up the Sandbox page into shorter pages. I tried to move Rubey's guessing sequence to a new Sandbox.GuessingSequence and it seems to work well. I did make a mistake by naming the page incorrectly without the Sandbox prefix. I also had to remove QuestionMark as subtopic.

For the brief time that the old Sandbox is breaking up, each change on that page still takes a fair amount of time, but as more and more are moved, it will be faster.

We can use this to set up pages where common or new packages can be tested like a tutorial -- much like the hyperdoc demos.

\start
Date: Thu, 09 Jun 2005 06:21:51 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#109 hyperdoc uncompress failed] 

(from William Sitt, email of Monday, February 21, 2005 2:51 AM)

I would like to report that compiling Feb 2005 release on Fedora FC2 was successful. However, when running Hyperdoc and selecting Topic, graphics, 2d-graphics, Parametric Curves, draw(...) I got the error: 

  sh: line1: uncompress: command not found.

To solve the problem, I put in the following symbolic links::

  su
  cd /bin
  ln -s gzip compress
  ln -s gunzip uncompress

and that solves the problem.

Perhaps Axiom should change its use of these obsolete commands?

\start
Date: Thu, 09 Jun 2005 11:21:13 -0500
From: MathAction (unknown)
To: MathAction
Subject: [Enhanced Fraction Domain] It's alpha code

Example: (* -2147483648/2203319546073 4926328811737/4294967296) =>
Error: Caught fatal error [memory may be damaged] on my machine (AMD64
(kernel 2.6.11.11 => which works around a bug in the AMD K8 CPUs.))

\start
Date: Thu, 09 Jun 2005 12:13:09 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Enhanced Fraction Domain] Seems to work for me...

(-2147483648/2203319546073) * (4926328811737/4294967296)

\start
Date: Thu, 09 Jun 2005 12:10:02 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Enhanced Fraction Domain] Seems to work for me...

While I haven't used nor fully digested the axiom related patches, the
author is apparently the same individual who so helpfully suggested an
improvement to GCL ratio arithmetic recently, which has been
implemented in CVS head (2.7.0).  Rational arithmetic is now much
faster in many regards, as GCL makes use of more functionality in the
highly optimized gmp library.  The bulk of the axiom patch appears to
be intended to call the lisp arithmetic functions directly -
apparently the spad compilation process results in a number of layers
between axiom and lisp here (not verified).  This is of course not
particular to any implementation of lisp, it is just that one can at
least expect significant performance advantages when GCL is the lisp.
There are still calls to cancelGcd -- perhaps it would be useful to
bring forward the gmp library function GCL uses internally for this
purpose.

\start
Date: Thu, 09 Jun 2005 12:09:06 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Enhanced Fraction Domain] Seems to work for me...

I don't really understand your example, but this works for me:
\begin{axiom}
[-2147483648/2203319546073, 4926328811737/4294967296]
\end{axiom}

\start
Date: Thu, 09 Jun 2005 13:06:18 -0500
From: MathAction (unknown)
To: MathAction
Subject: [Enhanced Fraction Domain] Come probably from the gcl.patch

With this patch on 64bits_kernel/Debian_AMD64/gcc-3.3 gcl caught a fatal error

\start
Date: Fri, 10 Jun 2005 09:30:06 +0200
From: Antoine Hersen
To: list
Subject: Port MacOS X

Hello,

I am planning to spending some time on porting Axiom to MacOS X.

I am aware of effort already put, I will like to know the current  
situation in order to be effective.

I have already contacted Pierre Doucy who is a friend of mine I did  
not manage to get the address of Chuck Miller.

Thanks in advance.

\start
Date: Fri, 10 Jun 2005 17:30:01 +0200
From: Martin Rubey
To: list
Subject: Manuel Bronstein

Dear Fellows,

today morning, Stephen Watt posted very sad news on the aldor mailing list:

> I am sorry to have to pass on the news that yesterday Manuel Bronstein
> died of a heart attack.   He was returning from a conference trip and
> this was completely unexpected.  He leaves behind a wife, Carola, and
> six children.  I have spoken with Carola to express our sympathy.
> 
> -- Stephen

Although I only got a glimpse of him, I appreciated his kindness and
helpfulness with regards to digging up old code and get collaboration started.

Sad news.

In one of his last emails to me he wrote:

> I really hope that the 2 efforts (axiom and aldor) will converge and that the
> new aldor libraries can be used as engines for the renewed axiom system in
> the near future.

\start
Date: Fri, 10 Jun 2005 18:16:19 +0200
From: Gregory Vanuxem
To: Martin Rubey
Subject: RE: Manuel Bronstein

Hi,

> -----Message d'origine-----
> De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
> part de Martin Rubey
> Envoye : vendredi 10 juin 2005 17:30
> A : list
> Objet : Manuel Bronstein
> 
> 
> Dear Fellows,
> 
> today morning, Stephen Watt posted very sad news on the aldor 

Yes really sad news

Cheers,

Greg

> mailing list:
> 
> > I am sorry to have to pass on the news that yesterday Manuel Bronstein
> > died of a heart attack.   He was returning from a conference trip and
> > this was completely unexpected.  He leaves behind a wife, Carola, and
> > six children.  I have spoken with Carola to express our sympathy.
> > 
> > -- Stephen
> 
> Although I only got a glimpse of him, I appreciated his kindness and
> helpfulness with regards to digging up old code and get 
> collaboration started.
> 
> Sad news.
> 
> In one of his last emails to me he wrote:
> 
> > I really hope that the 2 efforts (axiom and aldor) will 
> converge and that the
> > new aldor libraries can be used as engines for the renewed 
> axiom system in
> > the near future.

\start
Date: Fri, 10 Jun 2005 11:11:45 -0700 (PDT)
From: Clifton Williamson
To: Martin Rubey
Subject: Re: Manuel Bronstein

Manuel was my office mate when I worked on Axiom (then
Scratchpad) at IBM Watson labs and I later worked with
him at ETH Zurich.  Manuel was a world expert in
symbolic integration and extended many of the
techniques of that field to the problem of finding
closed form solutions to differential equations.  His
death is a great loss for the computer algebra
community in general, and for the Axiom/Aldor
communtity in particular.

For those of us who knew Manuel, we have lost a great
human being and a wonderful friend.  He had a great
sense of humor.  I will never forget his practical
jokes, having been a victim of his jokes on more than
one occasion!  He has left me fond memories of ski
trips (in Connecticut, of all places), hikes, and
flying single engine planes in the Alps.  Manuel truly
will be missed.  My heart goes out to Karola and the
kids.

Clifton

--- Martin Rubey wrote:

> Dear Fellows,
> 
> today morning, Stephen Watt posted very sad news on
> the aldor mailing list:
> 
> > I am sorry to have to pass on the news that
> yesterday Manuel Bronstein
> > died of a heart attack.   He was returning from a
> conference trip and
> > this was completely unexpected.  He leaves behind
> a wife, Carola, and
> > six children.  I have spoken with Carola to
> express our sympathy.
> > 
> > -- Stephen
> 
> Although I only got a glimpse of him, I appreciated
> his kindness and
> helpfulness with regards to digging up old code and
> get collaboration started.
> 
> Sad news.
> 
> In one of his last emails to me he wrote:
> 
> > I really hope that the 2 efforts (axiom and aldor)
> will converge and that the
> > new aldor libraries can be used as engines for the
> renewed axiom system in
> > the near future.

\start
Date: Fri, 10 Jun 2005 15:11:21 -0400
From: William Sit
To: Martin Rubey
Subject: Re: Manuel Bronstein

Hi *,

Martin Rubey wrote on Fri, 10 Jun 2005 17:30:01 +0200:

> today morning, Stephen Watt posted very sad news on the aldor mailing > list:

This is a real shock and very sad indeed.
To be exact, the actual post of Stephen Watt was dated June 7:

http://www.aldor.org/pipermail/aldor-l/2005-June/000076.html

Manuel and I worked in the same office (hi, Clifton, just read your message)
while I was visiting IBM to do work on Axiom and he was extremely helpful to me
(although I must admit that I couldn't be helped much at the time, especially
because Manuel was an extremely fast thinker, typist and speaker -- it was not
possible to stop him nor follow him in real time, even when he slowed down). We
also worked in 1998 together to edit a special issue of the Journal of Symbolic
Computation on Differential Algebra and Differential Equations. He visited New
York in November, 2002 and gave a talk at the Kolchin Seminar in Differential
Algebra. 

Manuel contributed a substantial portion of the Axiom/Aldor libraries and his
newer packages SumIt, bernina and shasta make his work easily available to the
wider scientific community. Even though his life was cut short, he had done more
than quite a few put together. 

We just lost a very productive and talented member in computer algebra.

\start
Date: Sat, 11 Jun 2005 05:01:16 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [recurrence relation operator] D-finite functions

I just realised that this should be implemented rather as a domain, namely the domain of D-finite (or P-recursive) functions. They have quite a lot of structure: you can multiply them, add them, take the hadamard product, differentiate them...

\start
Date: Sat, 11 Jun 2005 05:11:20 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [statistical functions] (nouveau) 

I just started to hack together a couple of statistical functions. Should be extended of course. The median could be implemented in 'O(n)' steps, but I don't have the time.

\begin{axiom}
)abb package STAT StatisticalFunctions
StatisticalFunctions(F:Field): Exports == Implementation where

    Exports == with
      mean: List F -> F

      stddev: List F -> F

      if F has OrderedRing then
        median: List F -> F


    Implementation == add

      mean l == 
        n := #l::F
        if n = 0 then error "The mean of an empty list is not defined"
        reduce(_+, l)/n

      stddev l ==
        n := #l::F
        if n = 0 then error "The standard deviation of an empty list is not _
                             defined"

        m := mean l
        reduce(_+, map((#1-m)**2, l)$ListFunctions2(F,F))/(n-1)

      if F has OrderedRing then
        median l == 
          n := #l
          if n = 0 then error "The median of an empty list is not defined"
          sort(l).(n quo 2)
\end{axiom}

\start
Date: Sat, 11 Jun 2005 07:02:10 -0500
From: MathAction (unknown)
To: MathAction
Subject: [statistical functions] Old hacks

Here is some old hack.
\begin{axiom}
)abbrev package STAT StatPackage
++ Description:
++ This package exports statistics utilities
StatPackage(S,A) : Exports == Implementation where 
  S: SetCategory
  A: Collection(S) with (finiteAggregate)
  Exports == with
	if A has FiniteLinearAggregate(S) and S has OrderedSet then
		median: A -> S
		++ median(a) median of a collection
  	if S has Field then
		mean: A -> S
		++ mean(a) arithmetic mean of a collection
		hmean: A -> S
		++ hmean(a) harmonic mean of a collection
		moment: (A,Integer) -> S
		++ moment(a,i) i nth moment of a collection
		variance: A -> S
		++ variance(a) variance of a collection
		center: A -> A
		++ center(a) center collection
		if A has shallowlyMutable then
			center_!: A -> A
			++ center!(a) center collection
		if S has RadicalCategory then
			gmean: A -> S
			++ gmean(a) geometric mean of a collection
			stdev: A -> S
			++ stdev(a) root mean square of a collection
			stdize: A -> A
			++ stdize(a) standardize a collection	
			if A has shallowlyMutable then
				stdize_!: A -> A
				++ stdize!(a) standardize a collection	
  Implementation == add
	if A has FiniteLinearAggregate(S) and S has OrderedSet then
		median(m)==
			n := sort(m)
			i:= divide(#m,2)
			if (zero? i.remainder) then
				j:= elt(n,i.quotient+minIndex(m)-1)
			else
				j:= elt(n,i.quotient+minIndex(m))
		        j

	if S has Field then
		if A has OneDimensionalArrayAggregate(S) then
			sums: A ->List S
			sums(m)==
				j:=0::S
				j2:=0::S
				for i in minIndex(m)..maxIndex(m) repeat
					h:= elt(m,i)
					j := j + h
					j2 := j2 + h*h
				[j,j2]
			variance(m)==
				i := center(m)
				s := sums(i)		
				k := (s.2 - s.1/#m::S)/(#m::S - 1::S)
				k
			if S has RadicalCategory then
				stdize(m)==
					i := mean(m)
					j := map(#1-i,m)
					s := sums(j)
					k := sqrt((s.2 - s.1/#m::S)/(#m::S - 1::S))
					map((#1-i)/k,m)
				if A has shallowlyMutable then
					stdize_!(m)==
						i := mean(m)
						j := map(#1-i,m)
						s := sums(j)
						k := sqrt((s.2 - s.1/#m::S)/(#m::S - 1::S))
						map_!((#1-i)/k,m)

		else
     			variance(m)==
				i := center(m)
				j := reduce("+",i)
				j2 := reduce("+", map(#1*#1,i))
				k := (j2 - j/#m::S)/(#m::S - 1::S)
				k
			if S has RadicalCategory then
     				stdize(m)==
					me:= mean(m)
					i := map(#1-me,m)
					j := reduce("+",i)
					j2 := reduce("+", map(#1*#1,i))
					k := sqrt((j2 - j/#m::S)/(#m::S - 1::S))
					map((#1-me)/k,m)
				if A has shallowlyMutable then
	     				stdize_!(m)==
						me:= mean(m)
						i := map(#1-me,m)
						j := reduce("+",i)
						j2 := reduce("+", map(#1*#1,i))
						k := sqrt((j2 - j/#m::S)/(#m::S - 1::S))
						map_!((#1-me)/k,m)


		if A has FiniteLinearAggregate(S) and S has OrderedSet then
			median(m)==
				n := sort(m)
				min := minIndex(m)
				i:= divide(#m,2)
				if (zero? i.remainder) then
					j:= (elt(n,i.quotient+min-1)+elt(n,i.quotient+min))/2::S
				else
					j:=elt(n,i.quotient+min)
		        	j
		mean(m)==
			i := reduce("+", m)
			(i / (#m::S))

		hmean(m)==
			i := map(1::S/#1,m)
			j := reduce("+", i)
			((#m::S) / j)
		        
		moment(m,n)==
			n = 0 => 1
			n = 1 => mean(m)
			i := map(#1**n, m)
			j := reduce("+",i)
			(j / (#m::S))

     		center(m)==
			i := mean(m)
			map(#1-i,m)

		if A has shallowlyMutable then
	     		center_!(m)==
				i := mean(m)
				map_!(#1-i,m)
				m
		if S has RadicalCategory then
			gmean(m)==
				i := reduce("*", m)
				nthRoot(i,#m)
			stdev(m)==
				sqrt(variance(m))

)abbrev package IDSTAT IntegralDomainStatPackage
++ Description:
++ This package exports statistics utilities over IntegralDomain
IntegralDomainStatPackage(S,A) : Exports == Implementation where 
  S: IntegralDomain
  A: Collection(S) with (finiteAggregate)
  Exports == with
	mean: A -> Fraction(S)
	++ mean(a) arithmetic mean of a collection
	moment: (A,NonNegativeInteger) -> Fraction(S)
	++ moment(m,n) nth moment of a collection

  Implementation == add
	mean(m)==
		i := reduce("+", m)
		i / #m::S
	moment(m,n)==
		n = 0 => 1
		n = 1 => mean(m)
		i := map(#1**n, m)
		j := reduce("+",i)
		j / #m::S
)abbrev package MSTAT MatrixStatPackage
++ Description:
++ This package exports statistics utilities on two dimensional arrays
++ Compute with column major order
MatrixStatPackage(S,Row,Col,M) : Exports == Implementation where 
  S: SetCategory
  Row : FiniteLinearAggregate S
  Col : FiniteLinearAggregate S
  M   : TwoDimensionalArrayCategory(S,Row,Col)
  Exports == with
	if Col has shallowlyMutable then
		if S has OrderedSet then
			median: M -> Col
			++ median(a) median of a two dimensional array
  		if S has Field then
			mean: M -> Col
			++ mean(a) arithmetic mean of a two dimensional array
			hmean: M -> Col
			++ hmean(a) harmonic mean of a two dimensional array
			variance: M -> Col
			++ variance(a) variance of a two dimensional array
			moment: (M,Integer) -> Col
			++ moment(a,i) i nth moment of a two dimensional array
			center: M -> M
			++ center(a) center two dimensional array
			center_!: M -> M
			++ center!(a) center two dimensional array
			if M has MatrixCategory(S,Row,Col) then
				cov:  M -> M
				++ cov(a): covariance matrix
			if S has RadicalCategory then
				gmean: M -> Col
				++ gmean(a) geometric mean of a two dimensional array
				stdev: M -> Col
				++ stdev(a) root mean square of a two dimensional array
				stdize: M -> M
				++ stdize(a) standardize two dimensional array
				stdize_!: M -> M
				++ stdize!(a) standardize two dimensional array
				if M has MatrixCategory(S,Row,Col) then
					cor:  M -> M
					++ cor(a): correlation matrix

  Implementation == add
	import Lisp
	import StatPackage(S,Col)
	if Col has shallowlyMutable then
		colReduce: (Col -> S, M) -> Col
		colReduce(fx,m)==
			ret : Col := new(ncols(m),NIL$Lisp)
			j := minColIndex(m) - 1
			for i in j+1..maxColIndex(m) repeat
				setelt(ret,i-j,fx(column(m,i)))
			ret
		if S has OrderedSet then
			median(m) ==
				ret := colReduce(median$StatPackage(S,Col),m)
				ret
		if S has Field then
			mean(m)==
				ret := colReduce(mean$StatPackage(S,Col),m)
			        ret
			hmean(m)==
				ret := colReduce(hmean$StatPackage(S,Col),m)
			        ret
			variance(m)==
				ret := colReduce(variance$StatPackage(S,Col),m)
				ret
			moment(m,pow)==
				ret : Col := new(ncols(m),NIL$Lisp)
				j := minColIndex(m) - 1
				for i in j+1..maxColIndex(m) repeat
					setelt(ret,i-j,moment(column(m,i),pow)$StatPackage(S,Col))
				ret
     			center(m)==
				ret : M := new(nrows(m),ncols(m),NIL$Lisp)
				j := minColIndex(m) - 1
				for i in j+1..maxColIndex(m) repeat
					setColumn_!(ret,i-j,center_!(column(m,i))$StatPackage(S,Col))
				ret
     			center_!(m)==
				j := minColIndex(m) - 1
				for i in j+1..maxColIndex(m) repeat
					setColumn_!(m,i-j,center_!(column(m,i))$StatPackage(S,Col))
				m
			if M has MatrixCategory(S,Row,Col) then
	     			cov(m)==
					ret := center(m)
					transpose(ret/(nrows(m)-1)::S) * ret
				
			if S has RadicalCategory then
				gmean(m)==
					colReduce(gmean$StatPackage(S,Col),m)
				stdev(m)==
					colReduce(stdev$StatPackage(S,Col),m)
	     			stdize(m)==
					ret : M := new(nrows(m),ncols(m),NIL$Lisp)
					j := minColIndex(m) - 1
					for i in j+1..maxColIndex(m) repeat
						setColumn_!(ret,i-j,stdize_!(column(m,i))$StatPackage(S,Col))
					ret
     				stdize_!(m)==
					j := minColIndex(m) - 1
					for i in j+1..maxColIndex(m) repeat
						setColumn_!(m,i-j,stdize_!(column(m,i))$StatPackage(S,Col))
					m
				if M has MatrixCategory(S,Row,Col) then
		     			cor(m)==
						ret := stdize(m)
						(transpose(ret/((nrows(m)-1)::S)) * ret)

\end{axiom}

\start
Date: Sat, 11 Jun 2005 07:11:54 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [statistical functions] Old hacks

\begin{axiom}
a:= ["a","c","d","g","z"]
b:= [1,7,8,9,2,4,6,17,18,14,32]
median a
median b
mean b
hmean b
moment(b,1)
moment(b,2)
moment(b,3)
variance b
stdev b
gmean b
stdize b
\end{axiom}

Martin, you can do what you want with these packages.
They are not checked.

\start
Date: Sat, 11 Jun 2005 17:25:37 +0200
From: Gregory Vanuxem
To: list
Subject: Rectangular and square matrix category definition

Hi,

Do you know why there is no the shallowlyMutable attribute in 
rectangular and square matrix category (RMATCAT and SMATCAT
respectively) ?

In RectangularMatrixCategoryFunctions2,
the map function contains new(m,n,0)$Matrix(R2) pretend M2
(M2 is approximatively RMATCAT)

In other words, map can't use the 'new' definition in 
RMATCAT (it is not defined) nor qsetelt.
map has to use a domain's function, here Matrix.

One consequence is that it is not possible to use the functions from
these package with new data representation (see chapter 13.7 "Multiple
Representations" in axiom book).

PS: there is a lot of these things in axiom library.

\start
Date: Sat, 11 Jun 2005 15:14:20 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [statistical functions] Thank you!

whoever you are, this is great! I would like to know your name, though... I suspect there are more treasures to be found!

Martin

\start
Date: Sat, 11 Jun 2005 15:27:38 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [statistical functions] library code must begin with )abbrev

Your original statistics code above did not compile here
on MathAction because MathAction requires that Axiom
library code must beging with exactly::

  )abbrev ...

Typing ')abb' is not enough even though that works in
Axiom itself. Look here:

  [SandBox Statistics]

It's great to see some real application code being
posted here. Thanks Martin and thanks Anonymous!

\start
Date: Sat, 11 Jun 2005 22:23:12 -0500
From: Tim Daly
To: list
Subject: Manuel Bronstein

Manuel Bronstein died this week of a heart attack at age 42.
Manuel leaves behind Karola (his wife) and six children. 

I just returned from a house-hunting trip in Pittsburgh 
to hear this terrible news.

I worked with him at IBM Research and have maintained contact
with him since that time. In fact, he got me to volunteer for
another ACM/ISSAC CD project just last week.

Manuel was one of the fundamental people on the Axiom project.
He's given us permission to use his PhD thesis as documentation
for the integration routines. He has contributed quite a bit of
effort behind the scenes through personal communication with me.

Manuel was one of the key computational mathematicians of our time.
He had a major impact on the organization and implementation of the
Axiom library which will be a useful legacy for future generations.
He should have had 40 more years enrich us all.

More importantly, Manuel was a good person and a friend. We spent
much time together talking about and flying airplanes. I have a
set of pictures he sent me from his soaring trips in the Alps and
fond memories of our flying trips along the Hudson River in NY.

I'd like to figure out some way to mark his passing. At minimum
I believe we should include his obituary in the ISSAC proceedings.
If there are any other efforts or suggestions please contact me 
so I can help.

In sadness,
Tim Daly

\start
Date: Sun, 12 Jun 2005 12:09:25 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#165 stream2.input] (new) 

---------------------------------------------------------------------
stream2.input.pamphlet
---------------------------------------------------------------------
in general this fixes the problems:

)set functions compile on

but the way axiom is initialized seems to leave something
in a broken state which the set command fixes.

)set streams calculate 10
[j for j in 4.. | j < 10 ] 
does not stop
m==[j for j in 4.. | j < 10 ]
m
causes GCL to exit, CCL to never complete
but
[j for j in 0.. | j < 10 ] 
works! issue seems to be 0 vs 4 in loop index

)set streams calculate 10
u==[i+j for i in (-4)..10 | i < 5 for j in 4.. | j < 10]
u
causes GCL to exit, CCL works
u==[i+j for i in 0..10 | i < 5 for j in 0.. | j < 10]
also fails. issue seems to be end test compile.

)set streams calculate 10
u==[[i+j for i in 0..] for j in 0..]
u
causes GCL to exit, CCL works
issue seems to have something to do with macros
because
[[i+j for i in 0..] for j in 0..]
works. also the sequence
)set fun comp on
v==[[i+j for i in 0..] for j in 0..]
v
works! something appears to be set funny when
axiom starts.

)set streams calculate 10
u(m,n)==[[i*j for j in m..] for i in n..]
u(3,6)
causes GCL to exit, CCL works
but
)set streams calculate 10
[[[i+j+k for i in 0..] for j in 0..] for k in 0..]
works!
[i+j+k for i in 0.. for j in 0.. for k in 0..]
works!!

\start
Date: Sun, 12 Jun 2005 12:16:35 -0500
From: MathAction (daly)
To: MathAction
Subject: [#166 elemnum.input] (new) 

20050510 tpd src/interp/vmlisp.lisp define DFLOAT sec, csc, acsc, asec, csch
20050510 tpd src/interp/vmlisp.lisp define DFLOAT coth sech acsch acoth asech

The problem is that DFLOAT calls these lisp functions directly
but they have no definitions. I added the simple case definitions
that use the lisp versions. The proper fix would be to create
an "infinite float package" that could do arbitrary length
floating point computations. A less portable solution is to
use the hardware doublefloat, possibly thru gmp.


---------------------------------------------------------------------
in elemnum.input:
---------------------------------------------------------------------

x := 0.7::DoubleFloat ==>  0.69999999999999996
but should be              0.7

[exp log x] ==>  [0.69999999999999996]
but should be    [0.7]

x := 0.7::DoubleFloat
acsc  x ==>    ACSC is invalid as a function.
but should be  Result is not real

x := 0.7::DoubleFloat
asec  x ==>    A is invalid as a function.
but should be  Result is not real

x := 0.7::DoubleFloat
acoth x ==>    ACOTH is invalid as a function.
but should be  Result is not real

x := 1.1::DoubleFloat ==> 1.1000000000000001
but should be             1.1

[                          tan atan x,  cot acot x, csc acsc x,   sec asec x  ]
                ==> ACSC is invalid as a function
but should be   [1.1,1.1,1.1,1.1]

[asin sin x,  acos cos x,  atan tan x,  acot cot x, acsc csc x,   asec sec x  ]
                ==> CSC is invalid as a function
but should be   [1.1,1.1,1.1,1.1,1.1,1.1]

[sinh asinh x,cosh acosh x,             coth acoth x,csch acsch x             ]
                ==> ACOTH is invalid as a function
but should be   [1.1,1.1,1.1,1.1]

[asinh sinh x,acosh cosh x,atanh tanh x,acoth coth x,acsch csch x,asech sech x]
                ==> COTH is invalid as a function
but should be   [1.1,1.1,1.1,1.1,1.1,1.1]

asech x         ==> ASECH is invalid as a function.
but should be   Result is not real

qtest(sa, sb, 1)
 
   Compiling function qtest with type (DoubleFloat,DoubleFloat,
      PositiveInteger) -> List Complex DoubleFloat 

   (28)
   [1.1102230246251565E-16, 2.2204460492503131E-16 - 4.4408920985006262E-16%i,
    1.1102230246251565E-16,
    - 4.4408920985006262E-16 - 2.2204460492503131E-16%i,
    4.4408920985006262E-16 + 2.2204460492503131E-16%i,
    - 1.1102230246251565E-16,
    - 2.2204460492503131E-16 - 2.2204460492503131E-16%i,
    1.1102230246251565E-16,
    - 2.2204460492503131E-16 - 2.2204460492503131E-16%i,
    2.2204460492503131E-16 + 2.2204460492503131E-16%i,
    3.3306690738754696E-16 - 2.2204460492503131E-16%i, 0.0,
    - 6.6613381477509392E-16%i, - 1.1102230246251565E-16,
    - 3.3306690738754696E-16 - 4.4408920985006262E-16%i,
    3.3306690738754696E-16 - 2.2204460492503131E-16%i,
    - 2.2204460492503131E-16,
    - 3.3306690738754696E-16 - 4.4408920985006262E-16%i,
    3.3306690738754696E-16 - 2.2204460492503131E-16%i,
    - 5.5511151231257827E-16, - 2.2204460492503131E-16,
    - 1.1102230246251565E-16, 1.1102230246251565E-16, 0.0,
    - 1.1102230246251565E-16, - 1.1102230246251565E-16]
                                               Type: List Complex DoubleFloat

but should be:

qtest(sa, sb, 1)
 
   Compiling function qtest with type (DoubleFloat,DoubleFloat,
      PositiveInteger) -> List Complex DoubleFloat 

   (35)
   [1.11022302462516e-16, 1.11022302462516e-16 - 2.22044604925031e-16%i,
    1.11022302462516e-16 - 2.22044604925031e-16%i, - 1.11022302462516e-16,
    1.1102230246251565e-16, 1.1102230246251565e-16 + 2.2204460492503131e-16%i,
    2.2204460492503131e-16%i, 1.11022302462516e-16,
    1.11022302462516e-16 - 2.22044604925031e-16%i,
    1.11022302462516e-16 - 2.22044604925031e-16%i, 3.3306690738754696e-16,
    3.3306690738754696e-16 - 2.2204460492503131e-16%i,
    1.1102230246251565e-16 - 2.2204460492503131e-16%i, - 1.11022302462516e-16,
    0.0, 1.11022302462516e-16, 1.11022302462516e-16, 0.0,
    1.1102230246251565e-16 - 2.2204460492503131e-16%i,
    - 5.5511151231257827e-16, 1.11022302462516e-16, - 1.11022302462516e-16,
    0.0, 2.2204460492503131e-16 + 2.2204460492503131e-16%i,
    3.3306690738754696e-16,
    - 2.2204460492503131e-16 + 2.2204460492503131e-16%i]
                                               Type: List Complex DoubleFloat


qerr % ==>     1.1899284087167906E-31
but should be  5.6889007588053731e-32


qtest(sa, sb, 2)
 

   (32)
   [- 1.1102230246251565E-16,
    - 2.2204460492503131E-16 - 4.4408920985006262E-16%i,
    - 3.3306690738754696E-16,
    4.4408920985006262E-16 - 2.2204460492503131E-16%i,
    - 4.4408920985006262E-16 + 2.2204460492503131E-16%i,
    - 1.1102230246251565E-16 - 2.2204460492503131E-16%i,
    3.3306690738754696E-16 - 2.2204460492503131E-16%i,
    - 1.1102230246251565E-16,
    - 2.2204460492503131E-16 - 4.4408920985006262E-16%i,
    - 2.2204460492503131E-16 + 2.2204460492503131E-16%i,
    2.2204460492503131E-16 - 2.2204460492503131E-16%i,
    - 1.1102230246251565E-16 - 2.2204460492503131E-16%i,
    2.2204460492503131E-16 - 2.2204460492503131E-16%i, 0.0,
    3.3306690738754696E-16 - 4.4408920985006262E-16%i,
    - 1.1102230246251565E-16, 2.2204460492503131E-16,
    3.3306690738754696E-16 - 4.4408920985006262E-16%i,
    - 1.1102230246251565E-16, 8.8817841970012523E-16, 2.2204460492503131E-16,
    1.1102230246251565E-16, 3.3306690738754696E-16,
    - 1.1102230246251565E-16 + 2.2204460492503131E-16%i,
    1.1102230246251565E-16, 2.2204460492503131E-16 - 2.2204460492503131E-16%i]
                                               Type: List Complex DoubleFloat

but should be
qtest(sa, sb, 2)
 

   (39)
   [- 1.11022302462516e-16, - 1.11022302462516e-16 - 2.22044604925031e-16%i,
    - 3.33066907387547e-16 - 2.22044604925031e-16%i, 1.11022302462516e-16,
    - 1.1102230246251565e-16, - 2.2204460492503131e-16, 2.2204460492503131e-16,
    - 1.11022302462516e-16, - 3.33066907387547e-16 - 2.22044604925031e-16%i,
    - 1.11022302462516e-16 - 2.22044604925031e-16%i, - 3.3306690738754696e-16,
    - 2.2204460492503131e-16,
    - 1.1102230246251565e-16 - 2.2204460492503131e-16%i, 0.0, 0.0,
    - 1.11022302462516e-16, - 1.11022302462516e-16, 0.0,
    - 1.1102230246251565e-16 - 2.2204460492503131e-16%i,
    8.8817841970012523e-16, - 1.11022302462516e-16, 1.11022302462516e-16, 0.0,
    - 2.2204460492503131e-16 + 2.2204460492503131e-16%i,
    - 3.3306690738754696e-16,
    2.2204460492503131e-16 + 2.2204460492503131e-16%i]
                                               Type: List Complex DoubleFloat


qerr %          ==>  1.355854680848614E-31
but should be        7.7748310370340103e-32

qtest(sa, sb, 3)
 

   (36)
   [- 1.1102230246251565E-16, 0.0,
    - 2.2204460492503131E-16 + 4.4408920985006262E-16%i,
    - 2.2204460492503131E-16, 0.0, - 4.4408920985006262E-16,
    - 1.1102230246251565E-16, - 1.1102230246251565E-16,
    - 2.2204460492503131E-16 + 4.4408920985006262E-16%i,
    - 2.2204460492503131E-16 - 2.2204460492503131E-16%i,
    2.2204460492503131E-16 + 2.2204460492503131E-16%i,
    - 1.1102230246251565E-16 + 2.2204460492503131E-16%i,
    2.2204460492503131E-16 + 2.2204460492503131E-16%i, 0.0, 0.0,
    - 3.3306690738754696E-16 + 2.2204460492503131E-16%i,
    - 1.1102230246251565E-16, 0.0,
    - 3.3306690738754696E-16 + 2.2204460492503131E-16%i,
    8.8817841970012523E-16, 2.2204460492503131E-16, 1.1102230246251565E-16,
    3.3306690738754696E-16,
    - 1.1102230246251565E-16 - 2.2204460492503131E-16%i,
    1.1102230246251565E-16, 2.2204460492503131E-16 + 2.2204460492503131E-16%i]
                                               Type: List Complex DoubleFloat

but should be
qtest(sa, sb, 3)
 

   (43)
   [- 1.11022302462516e-16, - 1.11022302462516e-16 + 2.22044604925031e-16%i,
    - 3.33066907387547e-16 + 2.22044604925031e-16%i, 1.11022302462516e-16,
    - 1.1102230246251565e-16, - 2.2204460492503131e-16, 2.2204460492503131e-16,
    - 1.11022302462516e-16, - 3.33066907387547e-16 + 2.22044604925031e-16%i,
    - 1.11022302462516e-16 + 2.22044604925031e-16%i, - 3.3306690738754696e-16,
    - 2.2204460492503131e-16,
    - 1.1102230246251565e-16 + 2.2204460492503131e-16%i, 0.0, 0.0,
    - 1.11022302462516e-16, - 1.11022302462516e-16, 0.0,
    - 1.1102230246251565e-16 + 2.2204460492503131e-16%i,
    8.8817841970012523e-16, - 1.11022302462516e-16, 1.11022302462516e-16, 0.0,
    - 2.2204460492503131e-16 - 2.2204460492503131e-16%i,
    - 3.3306690738754696e-16,
    2.2204460492503131e-16 - 2.2204460492503131e-16%i]
                                               Type: List Complex DoubleFloat


qerr %        ==>  1.0002983834232781E-31
but should be      7.7748310370340103e-32


qtest(sa, sb, 4)
 

   (40)
   [1.1102230246251565E-16, 0.0,
    3.3306690738754696E-16 + 4.4408920985006262E-16%i, 2.2204460492503131E-16,
    0.0, 2.2204460492503131E-16 - 2.2204460492503131E-16%i,
    2.2204460492503131E-16 + 2.2204460492503131E-16%i, 1.1102230246251565E-16,
    - 2.2204460492503131E-16 + 2.2204460492503131E-16%i,
    2.2204460492503131E-16 - 2.2204460492503131E-16%i,
    3.3306690738754696E-16 + 2.2204460492503131E-16%i, 0.0,
    6.6613381477509392E-16%i, - 1.1102230246251565E-16, 0.0,
    1.1102230246251565E-16, 1.1102230246251565E-16, 0.0,
    1.1102230246251565E-16, - 6.6613381477509392E-16, - 2.2204460492503131E-16,
    - 1.1102230246251565E-16, 1.1102230246251565E-16, 0.0,
    - 1.1102230246251565E-16, - 1.1102230246251565E-16]
                                               Type: List Complex DoubleFloat

but should be
qtest(sa, sb, 4)
 

   (47)
   [1.11022302462516e-16, 1.11022302462516e-16 + 2.22044604925031e-16%i,
    1.11022302462516e-16 + 2.22044604925031e-16%i, - 1.11022302462516e-16,
    1.1102230246251565e-16, 1.1102230246251565e-16 - 2.2204460492503131e-16%i,
    - 2.2204460492503131e-16%i, 1.11022302462516e-16,
    1.11022302462516e-16 + 2.22044604925031e-16%i,
    1.11022302462516e-16 + 2.22044604925031e-16%i, 3.3306690738754696e-16,
    3.3306690738754696e-16 + 2.2204460492503131e-16%i,
    1.1102230246251565e-16 + 2.2204460492503131e-16%i, - 1.11022302462516e-16,
    0.0, 1.11022302462516e-16, 1.11022302462516e-16, 0.0,
    1.1102230246251565e-16 + 2.2204460492503131e-16%i,
    - 5.5511151231257827e-16, 1.11022302462516e-16, - 1.11022302462516e-16,
    0.0, 2.2204460492503131e-16 - 2.2204460492503131e-16%i,
    3.3306690738754696e-16,
    - 2.2204460492503131e-16 - 2.2204460492503131e-16%i]
                                               Type: List Complex DoubleFloat
qerr %       ==>  7.5852010117404986E-32
but should be     5.6889007588053731e-32


x:=0.7::Float
csc x ==> 1.55227
  the Float csc function comes from FLOAT
  which comes from TrigonometricFunctionCategory (TRIGCAT)
  (defun CSC (x) (/ 1 (sin x))) gives a value
x:=0.7::DoubleFloat
csc x ==> CSC is invalid as a function

x:=0.7::Float
acsch x ==> 1.15447
x:=0.7::DoubleFloat
acsch x ==> ACSCH is invalid as a function

x:=0.7::Float
coth x ==> 1.65462
x:=0.7::DoubleFloat
coth x ==> COTH is invalid as a function

x:=0.7::DoubleFloat
asec x ==> A is invalid as a function

x:=1.1::Float
acsc x ==> 1.14109
x:=1.1::DoubleFloat
acsc x ==> ACSC is invalid as a function

x:=1.1::Float
csc x ==> 1.100000
x:=1.1::DoubleFloat
csc x ==> CSC is invalid as a function

x:=1.1::Float
acoth x ==> 1.52226
x:=1.1::DoubleFloat
acoth x ==> ACOTH is invalid as a function

x:=1.1::Float
coth x ==> 1.24922
x:=1.1::DoubleFloat
coth x ==> COTH is invalid as a function

x:=1.1::Float
asech x ==> invalid argument to acosh
x:=1.1::DoubleFloat
asech x ==> ASECH is invalid as a function

\start
Date: Sun, 12 Jun 2005 12:20:25 -0500
From: MathAction (daly)
To: MathAction
Subject: [#167 Infinite Floats Domain] (new) 

We need a way to handle infinite but bounded length floating
point computation. At present we have FLOAT and DFLOAT but
we really need general purpose floating point algorithms
similar in spirit to infinite length integers.

\start
Date: Sun, 12 Jun 2005 12:33:56 -0500
From: Tim Daly
To: list
Subject: --patch-40

*,

patch-40 is up on arch. i've been working on the failures that are
uncovered by the input file tests. i've fixed one failure and found
a workaround for the other. the third wasn't really a failure at all.

elemnum fails because we call lisp functions from within the algebra
DoubleFloat code and these functions do not exist in lisp. i've defined
these functions and they work but i need to write a whole battery of
test cases. plus the definitions are not "double float" but they give
the same answers as the original NAG version. 

which raises the desire for an "infinite float domain" that is similar
in spirit to the infinite precision integer domain. 

stream2.input fails because the interpreter seems to be started in
some sort of badly-initialized state with respect to compiling functions.
the workaround is to do ")set functions compile on" which seems to do
the right initializations. i'll track down the differences shortly.

ode.input failed simply because it did not have ")set break resume"
and the intentionally failing test stopped the input. this is fixed.

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

Summary: fix input file bugs
Keywords: daly test cases

20050612 tpd --patch-40
20050611 tpd src/input/*.pamphlet \usepackage{axiom}
20050611 tpd src/input/Makefile  add dvi files
20050611 tpd src/input/Makefile  add stream2.output
20050611 tpd src/input/stream2.input add )set functions compile on
20050610 tpd src/interp/vmlisp.lisp define DFLOAT sec, csc, acsc, asec, csch
20050610 tpd src/interp/vmlisp.lisp define DFLOAT coth sech acsch acoth asech
20050609 tpd src/input/Makefile  add elemnum.output
20050609 tpd src/input/elemnum.input add )set break resume
20050609 tpd src/input/Makefile  add ode.output
20050609 tpd src/input/ode.input add )set break resume

\start
Date: Sun, 12 Jun 2005 14:27:00 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#167 Infinite Floats Domain] ??? FLOAT

Tim,

What is the domain FLOAT if not already "infinite but bounded
length"? I thought that FLOAT has internal representation based
on a pair of "infinite but bounder length" INT's.

>From 'float.spad.pamphlet' I read::

  )abbrev domain FLOAT Float

  B ==> Boolean
  I ==> Integer
  S ==> String
  PI ==> PositiveInteger
  RN ==> Fraction Integer
  SF ==> DoubleFloat
  N ==> NonNegativeInteger

  ++ Author: Michael Monagan
  ++ Date Created:
  ++   December 1987
  ++ Change History:
  ++   19 Jun 1990
  ++ Basic Operations: outputFloating, outputFixed, outputGeneral, outputSpacing,
  ++   atan, convert, exp1, log2, log10, normalize, rationalApproximation,
  ++   relerror, shift, / , **
  ++ Keywords: float, floating point, number
  ++ Description: \spadtype{Float} implements arbitrary precision floating
  ++ point arithmetic.
  ++ The number of significant digits of each operation can be set
  ++ to an arbitrary value (the default is 20 decimal digits).
  ...
  ++ The underlying representation for floats is binary
  ++ not decimal. The implications of this are described below.
  ++
  ++ The model adopted is that arithmetic operations are rounded to
  ++ to nearest unit in the last place, that is, accurate to within
  ++ \spad{2**(-\spadfunFrom{bits}{FloatingPointSystem})}.
  ++ Also, the elementary functions and constants are
  ++ accurate to one unit in the last place.
  ++ A float is represented as a record of two integers, the mantissa
  ++ and the exponent.  The \spadfunFrom{base}{FloatingPointSystem}
  ++ of the representation is binary, hence
  ++ a \spad{Record(m:mantissa,e:exponent)} represents the number \spad{m * 2 ** e
  ...
  Rep := Record( mantissa:I, exponent:I )
  ...

\start
Date: Sun, 12 Jun 2005 17:17:54 -0500
From: Tim Daly
To: Bill Page
Subject: infinite floats domain

you're right, of course. 
my mind is mush at the moment. 
i've been driving all week.

\start
Date: Sun, 12 Jun 2005 17:40:37 -0500
From: Tim Daly
To: Kai Kaminski
Subject: summer of code
Cc: Heow Eide-Goodman

Kai,

I've been on the road all week without internet access so I've been 
unable to keep in contact.

The implementation should be a literate program. In some sense it is
more important that you document what you do than that you accomplish
the goals.  A key person who helped develop Axiom died this past week
which means, among other things, that he will no longer be able to
answer questions about his code.

If you use a TK-like front end it would be useful to create a design
document that lists the commands that it will accept and what each one
is intended to do. That will give the API for the lisp code. Since I 
don't see whether you've chosen the TK path or the firefox path it is
not clear what the API might be. This might require some experimentation
to see what the front-end will do.

Other than that it looks fine.

Since this is open source development try to copy the mailing list
(list), which is archived, so we can keep a 
record of the discussions and let the community join in. Part of
this effort is intended as a learning experience for you in the
ways of open source. You haven't really lived until you do something
stupid in public (like asking for "infinite floats" which have existed
since 1987). If you can program, have a clue, and are willing to work
you're among equals here.

\start
Date: Sun, 12 Jun 2005 21:24:48 -0400
From: Bill Page
To: Tim Daly
Subject: RE: infinite floats domain

On June 12, 2005 6:18 PM Tim Daly wrote:

> you're right, of course. 
> my mind is mush at the moment. 
> i've been driving all week.

Yah, that'll do it to ya ... :) How's CMU?

Seriously, I think that there *are* some issues that
should be dealt with here. There may very well be some
situations that could make more efficient and/or effective
use of Axiom's "infinite precision" floats. I expect that
just as in the case of "infinite" integers, there may be
some better ways and some worse ways of doing calculations
with this objects.

For that matter, mathematically speaking just what is Axiom's
Float type? Is it formally equivalent (though obviously not
computationally equivalent) to FRAC INT? How does it relate
to standard (IEEE ?) definitions of floating point? How does
it differ mathematically from the reals, c.f. RealClosure,
etc.

\start
Date: Sun, 12 Jun 2005 20:56:50 -0500
From: Tim Daly
To: Camm Maguire
Subject: gcl-2.6.7

timeline? this is open source. whenever we get the time.

i'll move to gcl-2.6.7pre shortly.

\start
Date: Mon, 13 Jun 2005 07:49:16 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#167 Infinite Floats Domain] Float and DFloat

What is the domain 'FLOAT' if not already "infinite but bounded


> you're right, of course.
> my mind is mush at the moment.
> i've been driving all week.

Yah, that'll do it to ya ... :) How's CMU?

Seriously, I think that there *are* some issues that
should be dealt with here. There may very well be some
situations that could make more efficient and/or effective
use of Axiom's "infinite precision" floats. I expect that
just as in the case of "infinite" integers, there may be
some better ways and some worse ways of doing calculations
with this objects.

For that matter, mathematically speaking just what is Axiom's
'Float' type? Is it formally equivalent (though obviously not
computationally equivalent) to 'FRAC INT'? How does it relate
to standard (IEEE ?) definitions of floating point? How does
it differ mathematically from the reals, c.f. 'RealClosure',
etc.

<hr>
>From wyscc Mon, 13 Jun 2005 07:00:00 -4:00

Axiom has 'DoubleFloat' (used to be called 'SmallFloat', hence
'sf.spad', I think), and 'Float' ('float.spad'). 'DoubleFloat' is IEEE
or "native precision" (according to 'sf.spad'). Any floating point
system is only, mathematically speaking, a small subset, and not
evenly distributed one for that, of the reals, and for that matter, of
the rationals. It is definitely not 'FRAC INT', which <B>is</B>
mathematically equivalent to the field of rational numbers.

In a fixed precision floating point system, there are only finitely
many numbers, so it cannot be 'FRAC INT'. In such a system, a floating
point number has the form $m \times b^e$, where $m$ is the mantissa
(assume finite precision), $b$ is the base (fixed), and $e$ is the
exponent (assume also finite precision). In practice, there is an
offset when $m$ and $e$ are stored so that $m$ is usually interpreted
with a "base-point" and the most significant digit is normalized to be
non-zero, and $e$ has an offset depending on the machine word length
and how a word is divided between $m, e$ (and the signs, which for
simplicity, we will assume are included in $m$ and $e$).

Axiom implementation uses the simplified representation of $m \times
b^e$ as it mathematically stands ($m$ is still normalized to give a
unique representation, but the base point is to the right of the least
significant digit). The intrinsic properties do not depend on the base
or the word length, so let's assume $b = 10$ for discussion purposes.

Let's say the exponent has precision one (that is, only one digit plus
one sign bit). So there are 19 exponents (from $-9$ to 9). Say the
mantissa m has precision 2 (that is, only two digits plus one sign
bit). So there are 181 possible mantissas (from $-99$ to $-10$, 0, 10
to 99). For simplicity, we will only discuss positive numbers. So one
sees that there can only be $19 \times 90$ positive numbers. But these
are not evenly distributed. There are 90 positive numbers for ANY two
successive exponents: so 90 positive numbers between 10 and 99, 90
between 100 and 990, and 90 between 1000 and 9900. It is clear that
the accuracy of a real number by a floating point number in this
system becomes less and less as the exponent goes up.  This is the
source of round-off errors.

This is basically the situation in DFLOAT (on Intel processors), where
$b = 2$, $m$ has 53 bits stored in a 52 bit field (not including sign,
note that in base 2, the most significant digit normalized must be 1,
so no need to store it!) and $e$ has 11 bits (including sign, ranging
from $-1075$ to $971$ which accounts for an offset of 53 because the
base point location). This is exactly equivalent to the IEEE-754
standard for 64 bit floating point. The actual arithmetics is done via
Lisp, which I assume calls the hardware.

In 'FLOAT', conceptually the infinite precision floating point system,
is basically also finite precision floating point system, with the
ability to increase precision as requested. However, this promotion is
not automatic. In other words, every 'FLOAT' number has its own
precision, implicit in the length of its mantissa. In effect, 'FLOAT'
is the union of floating point systems with various precisions, but
without any coercion between them. So Tim is not entirely wrong is
saying we don't have infinite precision floating point in the spirit
of INT. The real question for the developers is then:

<B>Shall we improve 'FLOAT' or shall we implement a new domain of
infinite precision float (and if so, how, or rather, what are the
specifications of such a domain)?</B>

Example. Addition of two 'FLOAT' with different orders of magnitude
will not lead to a higher precision answer. What should be the right
answer depends on your point of view: if the precision of the number
is important, then this is correct. If exact arithmetic with floating
point is what you want, this is not correct.

If 'x' and 'y' are 'FLOAT', but 'y' is much larger than 'x', say the
exponent of 'y' exceeds that of 'x' (when both 'x' and 'y' are
normalized) by the current precision of 'FLOAT', then 'x+y' would be
'y', not 'x+y' with precision extended (see routine 'plus' in
'float.spad'). Note that 68 bits is approximately 20 decimal
digits. The display for 'y' should have 9 trailing zeros after the
decimal.

\begin{axiom}
bits()$Float
x:Float:=2^(-34)
y:Float:=2^35
x+y
\end{axiom}

By the way, in interpreting correctness of displayed answers for
floating point computation, there is another source of error besides
round off. For example,

\begin{axiom}
x:Float:=sqrt(2)
bits(100)$Float
z:Float:=sqrt(2)
z - x
\end{axiom}

Most people would expect the answer of 'z-x' to be '0.16887242 E-20'
but this ignores the fact that the display is converted from an
internal binary representation to a decimal one. During the conversion
there is truncation error (think of 0.1 in base 3 converted to decimal
0.3333... with output at any finite precision). So 'x' is not what it
seems, and neither is 'z'. Below, the constants are converted to
binary internally before computation, at a higher precision than x
(resp. z) to bring out the differences. We can now see that 'x' is
larger than 'z'. So Axiom is correct and the expectated answer is
wrong.

\begin{axiom}
x - 1.4142135623730950488
bits(120)$Float
z - 1.4142135623730950488016887242
\end{axiom}

\start
Date: Mon, 13 Jun 2005 08:18:59 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#167 Infinite Floats Domain] Float is arbitrary precision, not infinite precision

In 'FLOAT', conceptually the infinite precision floating point system,
is basically also finite precision floating point system, with the
ability to increase precision as requested. However, this promotion is
not automatic. In other words, every 'FLOAT' number has its own
precision, implicit in the length of its mantissa. In effect, 'FLOAT'
is the union of floating point systems with various precisions, but
without exact arithmetic. So Tim is not entirely wrong in saying we
don't have infinite precision floating point in the spirit of
INT. What we have in 'FLOAT' is arbitrary precision, not infinite
precision (exact arithmetic). The real question for the developers is
then:

\start
Date: Mon, 13 Jun 2005 08:08:55 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#167 Infinite Floats Domain] Float and DFloat

$m$ has 53 bits stored in a 52 bit field (not including sign, note
that in base 2, the most significant digit normalized must be 1, so no
need to store it!) and $e$ has 11 bits (including sign, ranging from
$-1075$ to $971$ which accounts for an offset of 53 because the base
point location). This is exactly equivalent to the IEEE-754 standard
for 64 bit floating point. The actual arithmetic operations are done
via Lisp, which I assume calls the hardware.

In 'FLOAT', conceptually the infinite precision floating point system,
is basically also finite precision floating point system, with the
ability to increase precision as requested. However, this promotion is
not automatic. In other words, every 'FLOAT' number has its own
precision, implicit in the length of its mantissa. In effect, 'FLOAT'
is the union of floating point systems with various precisions, but
without exact arithmetic. So Tim is not entirely wrong in saying we
don't have infinite precision floating point in the spirit of INT. The
real question for the developers is then:

Example. Addition of two 'FLOAT' with different orders of magnitude
will not lead to a higher precision answer. What should be the right
answer depends on your point of view: if the precision of the numbers
are important, then this example is correctly handled in Axiom. If
exact arithmetic with floating point is what you want, this is not
correct.

\start
Date: Mon, 13 Jun 2005 09:13:07 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#167 Infinite Floats Domain] 

Most people would expect the answer of 'z-x' to be '0.16887242 E-20'
but this ignores the fact that the display is converted from an
internal binary representation to a decimal one. During the conversion
there is truncation error (think of 0.1 in base 3 converted to decimal
0.3333... with output at any finite precision). So 'x' is not what it
seems, and neither is 'z'. Below, the constants are converted to
binary internally before computation, at a higher precision than x
(resp. z) to bring out the differences. We can now see that 'x' is
larger than 'z'. So Axiom is correct and the expected answer is wrong.

\start
Date: Mon, 13 Jun 2005 16:18:44 +0200
From: Gregory Vanuxem
To: Oswald Gschnitzer
Subject: Rectangular and square matrix category definition in Axiom CAS

Hi,
 
Do you know why there is not the shallowlyMutable attribute in
rectangular (RMATCAT) and square matrix category in axiom (CAS) ?


Documentation of RMATCAT:
++   \spadtype{RectangularMatrixCategory} is a category of matrices of
++   fixed dimensions.  The dimensions of the matrix will be parameters
++   of the domain.  Domains in this category will be R-modules and will
++   be non-mutable.


In RectangularMatrixCategoryFunctions2, the map function contains
new(m,n,0)$Matrix(R2) pretend M2 (M2 is approximatively RMATCAT)
 
In other words, map can't use the 'new' definition in RMATCAT (it is not
defined) nor qsetelt.  map has to use a domain's function, here Matrix.

\start
Date: Mon, 13 Jun 2005 09:51:10 -0500
From: MathAction (daly)
To: MathAction
Subject: [#167 Infinite Floats Domain] 

++added:

<hr>

Now that I'm awake the idea is coming back to me. What originally
triggered the thought was that we need a way to compute an answer
to a variable number of decimal places which could be expanded later.
Thus we could compute the coefficients of a polynomial to 3 decimal
places for display but expand them to 200 decimal places when we are
evaluating the polynomial at a point.

The idea was to have a different representation that stored a closure
of the computation, similar to the series mechanism, so we could "continue"
to get more digits at a later time.

This raises the same kind of implementation issue that indefinite
computation raises except that indefinites are symbolic and infinite
precision floats are not.

The issue is that we want to keep the state of a computation in a
form that we can expand. This involves storing functions and 
composition of functions. This would imply that floating point
computations are no longer strictly numeric. So the product of
two infinite floats (INFL) object would be stored in such a way
to keep the original values as well as the result. Ideally we
could stop a computation, store it as a closure, and restart it
when we need more digits.

I have to give some thought to the more general case of a "closure"
based mathematical object that captures the computations. As we push
for more "symbolic" answers this issue keeps appearing.

\start
Date: Mon, 13 Jun 2005 10:34:57 -0500
From: MathAction (daly)
To: MathAction
Subject: [#167 Infinite Floats Domain] computable real numbers

>From Kai Kaminski:

> I just read your posts about infinite precision floats on the Axiom 
> list and I recalled that I have seen something like this a while ago. I 
> am not sure if this is what you are looking for but it sounds like it:

>  http://www.haible.de/bruno/MichaelStoll/reals.html

> It is implemented in Common Lisp apparently.

yes, this is exactly the idea. 

\start
Date: Mon, 13 Jun 2005 10:53:23 -0500
From: Tim Daly
To: Michael Stoll
Subject: CREALs

Michael,

I'm Tim Daly, the lead developer on Axiom. Axiom was originally
developed at IBM Research, was bought to NAG and was a commercial
competitor to Mathematica and Maple. It was withdrawn from the
market and is now free and open source software. (see
http://savannah.nongnu.org/projects/axiom
http://sourceforge.net/projects/axiom
http://page.axiom-developer.org

We've been discussing a new infinite-precision reals package and
someone pointed me to your work. I'd like your permission to use
and modify the common lisp code which is available at:
http://www.haible.de/bruno/MichaelStoll/reals.html

Axiom is released under the Modified BSD license. I don't see a
license associated with your code so I'm not sure if I have your
permission to use and modify it.

Almost all of the code will end up being written in our algebra
language which will simplify the whole type issue.

\start
Date: Mon, 13 Jun 2005 11:08:21 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#167 Infinite Floats Domain] That's cool but ...

How is this different than what Axiom already does?
I can write:
\begin{axiom}
a:=2*asin(1)
a::Expression Float
digits(100)
a::Expression Float
\end{axiom}

So %pi already has this kind of "closure" built-in.
Is it really possible to do this more generally for
all possible computations with real numbers?

How are "computable reals" different than actual
real numbers?

wyscc wrote:

> Any floating point system is only, mathematically speaking,
> a small subset, and not evenly distributed one for that,
> of the reals, and for that matter, of the rationals. It is
> definitely not FRAC INT, which is mathematically equivalent
> to the field of rational numbers.

But surely there is an isomorphism between the domain of
**infinite precision** floating point numbers and the domain
of rationals, no?

Maybe these **computable reals** are something else? Isn't
it related to the RealClosure as already implemented in
Axiom?

\start
Date: Mon, 13 Jun 2005 11:51:53 -0500
From: Tim Daly
To: Michael Stoll
Subject: rational points on curves

Michael,

I also understand from your web page that you've done work in
finding rational points on curves.

Do you have explicit algorithms that you can point me to?
I'd like to look at how these might be implemented in Axiom.

\start
Date: Mon, 13 Jun 2005 13:15:13 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [RealClosure] 

  Renaud Rioboo::

	LIP6 Case 168, Thème SPI
  	Universtité Pierre et Marie Curie
  	4 Place Jussieu
  	F-75252 Paris CEDEX 05
 
  	Tel : +33 1 4427 3341
  	Fax : +33 1 4427 4042
  	mailto:Renaud Rioboo


Axiom Software

  - http://ftp.lip6.fr/lip6/softs/formel/Axiom/RealClosures

  - http://www-calfor.lip6.fr/~rr/HDR/reclos_frisco.pdf

  - http://page.axiom-developer.org/zope/Plone/refs/articles/axiom-field.pdf

Related Papers

  - "Infinitesimals and real closure":http://www.lip6.fr/fr/production/publications-rapport-fiche.php?RECORD_KEY%28rapports%29=id&id(rapports)=185

  - "Polymorphic Data Types, Objects, Modules and Functors: is it too.much.?":http://www.lip6.fr/fr/production/publications-rapport-fiche.php?RECORD_KEY%28rapports%29=id&id(rapports)=139

\start
Date: Mon, 13 Jun 2005 14:37:38 -0500
From: MathAction (unknown)
To: MathAction
Subject: [Enhanced Fraction Domain] Update gcl.patch

About (* -2147483648/2203319546073 4926328811737/4294967296) bug, -2147483648 
is the MOST-NEGATIVE-FIXNUM. If we negate it, it become a bignum
and it is handled differently.
</br>
This new patch (for gcl-2.6.6) fix this bug.
For old gcl,  edit the old gcl.patch and change
<pre>
  if (type_of(y)==t_fixnum && type_of(x)==t_fixnum) 
    return make_fixnum(fix(x)/fix(y)); /* no in_place for fixnums as could be small */;
</pre>
to
<pre>
  if (type_of(x)==t_fixnum){
    if (type_of(y)==t_fixnum)
       return make_fixnum(fix(x)/fix(y)); /* no in_place for fixnums as could be small */;
    // ABS (MOST-NEGATIVE-FIXNUM) => BIGNUM
    return make_fixnum(-1);
  }
</pre>
in integer_exact_quotient function.

\start
Date: Mon, 13 Jun 2005 14:18:41 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [statistical functions] 

++ This package exports statistic utilities

		++ median(a) median of a collection (ordering from OrderedSet)

++ This package exports statistic utilities over IntegralDomain

++ This package exports statistic utilities on two dimensional arrays
++ Function are applied column by column

			++ median(a) median of a two dimensional array (ordering from OrderedSet)

++added:

-- beware, the following is not mathematically justified since
-- median use ordering from OrderedSet (and not OrderedRing)
c := [3+7*%i,5+8*%i,8+3*%i,4+5*%i]
median c

\start
Date: Tue, 14 Jun 2005 09:25:22 -0500
From: MathAction (unknown)
To: MathAction
Subject: [Enhanced Fraction Domain] Update gcl.patch

This is correct -- equivalent being committed to CVS head.

\start
Date: Tue, 14 Jun 2005 19:30:31 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#167 Infinite Floats Domain] Float, Real, RealClosure

<hr>
>From William Sit, Tuesday June 14 20:06:00 -4:00<br>
Subject: Float, Real, RealClosure

Tim wrote:

>This raises the same kind of implementation issue that indefinite
 computation raises except that indefinites are symbolic and infinite
 precision floats are not.

But that is a very big difference. For example, Axiom using 'FLOAT'
can simulate arbitrary precision with automatic recomputation right
now. All one has to do is instead of storing the value of any
identifier in a fixed floating point representation, store it as a
function (or macro) to compute that value. This is exactly the idea
used by Michael Stoll. In Mathematica, it is using 'SetDelayed'
instead of 'Set' and in Axiom, it is using '==' instead of ':='.  The
defining expression (function) is stored with the identifier, but no
composition is actually stored. Instead, when evaluation time comes,
the values of the identifiers involved are recursively computed (the
actual implementation may be more clever and efficient, but this is
discussion on the conceptual level). Evaluation is always possible as
long as all the identifiers at the leaves are.

However, in my view, this still is not infinite precision in the sense
of that $2^(-35) + 2^34$ will not compute exactly because the system
does not *automatically* increase precision in 'FLOAT' (it won't, even
using macros).  But one *can* compute it by *manually* increasing the
precision (which precision is by no means obvious). Compare this with
'FRAC INT' where there is no need to manually increase the length of
integers in numerators or denominators. Floating point systems are
designed to compute only significant digits.  (More comments on
implementing infinite precision below).

\begin{axiom}
)clear all
bits(68)$Float
x == 2^(-34)::Float
y == 2^(35)::Float
z == y+x
x
y
z
bits(200)$Float
z
bits(68)$Float
2^(-34)+2^35
\end{axiom}

  In contrast, evaluation is not always possible for indefinites (a
  topic to be discussed separately). It is difficult to evaluate
  indefinites since that results in the recursive composition of
  functions (technique involved bears similarity to code optimization
  by compiler, but unfortunately, we do not just want the code, but a
  mathematically readable expression). The indefinites *are* the
  functions themselves, *not* their functional values. The *output
  form* of an indefinite is either the defining expression (typically
  useless, since no computation is performed), or recursively composed
  (typically a mess), or recursively analyzed into cases
  (proviso-attached expressions, and extremely computationally
  demanding to simplify provisos). When an indefinite is involved in a
  loop control construct, it is difficult to "simplify". None of these
  difficulties are present in infinite precision 'FLOAT', however it
  is to be implemented.

Bill Page wrote:

> So %pi already has this kind of "closure" built-in.
> Is it really possible to do this more generally for
> all possible computations with real numbers?

Yes.

\begin{axiom}
bits(68)$Float
x == sin(1/sqrt(2)::Float)
x
bits(100)$Float
x
\end{axiom}

> But surely there is an isomorphism between the domain of
> **infinite precision** floating point numbers and the domain
> of rationals, no?

If by such a domain, you meant a floating point representation where
the mantissa has infinite precision (not arbitrary precision), then
you might as well use infinite sequences of rational numbers in
decimal (or binary) expansion, and you could represent, in theory,
$\sqrt{2}$ and perform exact arithmetic like $1/3 + 1/5$. Since the
set of rational numbers is dense in the set of real numbers, and FRAC
INT is the field of rational numbers, rational number sequences are
better for approximating real numbers, and of course, they would be
exact on rationals (unlike FPS).  In that case the isomorphism would
be with the field of real numbers.

But this is of course not what floating point systems are. In FPS, you
may be capturing more and more rational numbers as the precision is
increased, but the gaps between two consecutive 'FLOAT' numbers remain
large at higher exponents (they amplify the gaps). Also, not every
rational number has a finite decimal (or binary) expansion (1/3 would
not be representable in an arbitrary precision FPS with base 10). So
any rational with a recurring fractional (non-terminating) expansion
in the base will not be representable and there cannot be a bijection
(not to mention an isomorphism since floating point operations don't
respect even the associative law).

Another way of stating the difference is that IPFPS requires the
limiting value of mantissa (and associated exponent to locate the
fractional point), which does not exist in APFPS (which I view as the
infinite union of $k$-precision FPS over all positive $k$; your view
may be different). There are problems with simulating IPFPS by
automatically adjusting the precision to yield exact results on
floating point computation. The resulting system still cannot perform
exact arithmetic on all rational (therefore, real) numbers due to
truncation and round off. Whether the error term tends to zero would
depend on the particular computation involved (problem may be
ill-conditioned). We also need algorithms to automatically adjust the
precision, worry about efficiency because of repeated recalculation to
increase precision, and perhaps worry about termination. There is also
an intrinsic problem in the representation.

Consider the problem of extending the precision of two FP numbers,
which have identical FP representation at 10-bit precision. To avoid
truncation errors due to binary to decimal conversion, we will work
with internal representations of 'FLOAT' only.

\begin{axiom}
z == sqrt(3)::Float
bits(10)$Float
mz := mantissa z
ez := exponent z
z10 := mz*2^ez
z10float == z10::Float
mantissa z10float
exponent z10float
mantissa(z-z10float)
\end{axiom}

So here we have two identical 10-bit floating point numbers, both
defined as macros. If we extend the precision, they would no longer be
the same.

\begin{axiom}
bits(20)$Float
mantissa z
mantissa z10float
\end{axiom}

This raises some questions. It showed that the current representation
of 'FLOAT' is not equipped to handle "infinite precision" floating
point computation, whatever that may be, and indeed, not even
arbitrary precision, since extending the precision of a number depends
not just on the number, but on the functions used to define it. An
accompanying question is how to test equality. Similarly, if we are to
find the squares of 'z' and 'z10float', what precisions should be set
for the proposed "infinite precision" FPS?

There should be a lot of similarities between IPFP and power series
because we should treat IPFP numbers as infinite sequences, not
floats. In power series, we start off with the infinite, compute with
the infinite (lazy evaluation), but display finitely. In 'FLOAT', we
start with the finite and extend, and there is no unique way to do so.
In using 'FLOAT' to simulate IPFP, we start with the infinite when we
use macros, compute either finitely (':=') or infinitely ('==', the
equivalent of lazy evaluation) and display finitely; but the objects
are not correctly stored in the data representation. Just as we don't
simulate power series using polynomials, we shouldn't simulate IPFP
using FPS. This *is* Axiom, afterall.



> Maybe these **computable reals** are something else? Isn't
> it related to the RealClosure as already implemented in
> Axiom?

APFPS  is not the same as RealClosure. 

For some background material, see Lang: Algebra.  Here I recall a few
basic definitions. A field $K$ is a *real field* if $-1$ is not the
sum of squares in $K$.  A field $K$ is *real closed* if $K$ is real,
and any algebraic extension of $K$ that is real must be $K$ itself.
Every real closed field has a unique ordering. The *real closure* of a
real field $K$ is an algebraic extension of $K$ that is real
closed. Every real field $K$ has a real closure $L$, and if $K$ is
ordered, $L$ is unique (up to a unique isomorphism). In $L$, every
positive element is a square and the algebraic closure of $L$ is
$L[\sqrt{-1}]$.

RealClosure implements computation in a real closure of a base
field. In particular, it does not compute any element that is
transcendental over the base field. RealClosure provides two modes of
computation, one in terms of minimal polynomials and the other, an
interval containing the particular root is used for approximation. Its
relation with 'FLOAT', I believe, would be for solving polynomial
equations numerically.

\start
Date: Tue, 14 Jun 2005 20:53:46 -0500
From: Tim Daly
To: Bill Page, Kai Kaminski
Subject: XML
Cc: Heow Eide-Goodman

having lost a year of my life working with XML, XSLT, DOM, SAX, JDOM, etc.
i can honestly say that i'm religiously opposed to XML.

you're welcome to try to convince me otherwise but i warn you that it
is a hard fight as i have a lot of really bad war stories. XML is a
dead-end technology. it is the PL/I of web standards. i'd bet you don't
program in PL/I (which i did) and you won't use XML in 5 years.

that said, this IS open source so you're welcome to pursue the path
you feel will be best regardless of the curmudgeon in the corner.

if we do plan to rewrite the syntax of browser pages i'd prefer a
lisp-like syntax which would allow us to (a) use the lisp (read)
and (b) define functions dynamically. this would be especially useful
as most of the new browser is to be implemented in lisp. so instead of

<a href="foo.html">foo</a>

you get something like:

(anchor "foo.html" "foo")

however the browser pages are fairly close to latex and the latex-wiki
code can display latex so why rewrite them completely? besides there
is functionality there which does not exist in XML. For instance you'll
see pages which say:

\spadcommand{x:=2}\bound{x}
\spadcommand{y:=3}\bound{y}
\spadcommand{x*y}\free{x}\free{y}

clicking on the third expression tells the browser that it needs to 
find a meaning for x and a meaning for y somewhere prior in the page.
these are determined by the \bound expression.

given the 90 days and assuming 100 lines of code per day (ah, to have
such productivity i'd give a leg) we're talking 9k lines of code for
the summer. 

\start
Date: Tue, 14 Jun 2005 23:24:06 -0400
From: Bill Page
To: Tim Daly
Subject: RE: XML
Cc: Heow Eide-Goodman, Kai Kaminski

On Tuesday, June 14, 2005 9:54 PM Tim Daly wrote:

> having lost a year of my life working with XML, XSLT, DOM, SAX,
> JDOM, etc. i can honestly say that i'm religiously opposed to XML.
>
> you're welcome to try to convince me otherwise but i warn you that
> it is a hard fight as i have a lot of really bad war stories. XML
> is a dead-end technology.

I never argue about religion :) But I used to be a statistician ...

A Google search says:

  Results 1 - 10 of about 191,000,000 for xml
  Results 1 - 10 of about  48,300,000 for xhtml
  Results 1 - 10 of about   8,430,000 for XSLT

> it is the PL/I of web standards. i'd bet you don't program in PL/I
> (which i did) and you won't use XML in 5 years.

As a matter of fact my first programming language *was* PL/I on
an IBM 360 (my second was FORTRAN on an even older IBM computer)
when I was still in high school. And there was APL on a CDC 6400 ...
but don't get me started!

IBM still supports PL/I on UNIX and on Microsoft Windows

http://www-306.ibm.com/software/awdtools/pli/

There is even an active open source project to revive PL/I as a
GNU language

http://pl1gcc.sourceforge.net/

A Google search says:

  Results 1 - 10 of about 1,240,000 for "PL/I"

So I think it is safe for me to make the counter-claim that PL/I
is not dead and also that XML is more than likely to be still
around in 30 years time.

> that said, this IS open source so you're welcome to pursue the
> path you feel will be best regardless of the curmudgeon in the
> corner.

I like old war stories as much as the next guy ;)

> if we do plan to rewrite the syntax of browser pages i'd prefer
> a lisp-like syntax which would allow us to (a) use the lisp
> (read) and (b) define functions dynamically. this would be
> especially useful as most of the new browser is to be implemented
> in lisp.

Don't get me wrong, I like lisp (although I probably haven't
written more than 20 lines of lisp code in my life) but I
sometimes wonder where lisp will be 30 years from now?

A current Google search returns:

  Results 1 - 10 of about   3,410,000 for lisp  

Keeping programs like Axiom, Maxima and ACL2 alive could very
well help to keep lisp itself alive.

But anyway, I don't see the relevance of either (a) or (b) in
this context. I don't see much difference in parsing a text
stream delimited by parenthesis ( ) compared to brackets < >
Defining lisp functions seems way beyond what would normally
be expected of a browser.

I don't see why you say "most of the new browser is to be
implemented in lisp". As I understand it, that is only one
possible option (if we were to use something like GTK). What
Kai is proposing on the other hand is using an off-the-shelf
web browser (such as FireFox or Mozilla). The lisp code that
he would write implements only the web *server* component, not
the browser. And most of the needed lisp code already exists
in common lisp. What he needs to do is develop the interface
between the web server and Axiom.  One possible option for
doing that involves just writing lisp code in Axiom itself.

>  so instead of
> 
> <a href="foo.html">foo</a>
>
> you get something like:
>
> (anchor "foo.html" "foo")

But what do you gain by doing this?

> however the browser pages are fairly close to latex and the
> latex-wiki code can display latex so why rewrite them
> completely?

LatexWiki depends on a huge set of software: Python+PIL, Zope,
ZWiki, tex, ghostscript, etc. just to name the major components.
This is a very large stack of code for a workstation just to
edit and display some mathematics! The web page layout in
LatexWiki is still ultimately done by HTML and the web browser
even though for easy editing it also supports a simpler layout
language called "structured text" as an input language.

In a browser like FireFox a fairly large javascript program
called jsMath (about 140 Kbytes) can be use to render latex
equations and math symbols, but this does *not* include the
text layout, which in web browsers is done by HTML and CSS.

For compatibility with a web browser, the existing latex-like
coding for the Axiom browser pages (except for the mathematics
itself) must be re-coded as HTML (which in modern form is
known as XHTML and is a particular application of XML).

> besides there is functionality there which does not exist in
> XML. For instance you'll see pages which say:
>
> \spadcommand{x:=2}\bound{x}
> \spadcommand{y:=3}\bound{y}
> \spadcommand{x*y}\free{x}\free{y}

It is peculiar to say that something does not exist is XML since
XML is only a meta syntax. One might as well say that it does not
exist in lisp. But that is irrelevant. In XML nothing stops us
from inventing a syntax for the commands above. For example:

<spadcommand bound="x"}>{x:=2}</spadcommand>
<spadcommand bound="y">{y:=3}</spadcommand>
<spadcommand free="x,y">{x*y}</spadcommand>

In fact that is (more or less) exactly what OpenMath attempts
to do.

> clicking on the third expression tells the browser that it
> needs to find a meaning for x and a meaning for y somewhere
> prior in the page. these are determined by the \bound expression.

I can understand why Axiom needs to know this kind of thing,
but I don't understand how the Axiom browser would use this
kind of information. Can you give an example?

> given the 90 days and assuming 100 lines of code per day (ah,
> to have such productivity i'd give a leg) we're talking 9k
> lines of code for the summer. 

I think for this reason the most effective use of resources is
to write as little new code as possible. One can get the most
mileage out of integrating and modifying existing code for our
purposes. One major component of this is to assume the use of
a modern web browser at the primary means to implement the user
interface. The other existing major components include javascript
such as jsMath and AJAX (aka Asynchronous JavaScript and XML)
and common lisp code for the web server.

I think one should be able to do quite a lot with 9k lines of
lisp and javascript in such an environment.

\start
Date: Tue, 14 Jun 2005 23:00:59 -0500
From: Tim Daly
To: Bill Page, Kai Kaminski
Subject: XML
Cc: Heow Eide-Goodman

<spadcommand bound="x">{x:=2}</spadcommand>
<spadcommand bound="y">{y:=3}</spadcommand>
<spadcommand free="x,y">{x*y}</spadcommand>

requires a huge program to parse (DOM or SAX, callbacks) vs

(spadcommand "x:=2" (bound 'x))
(spadcommand "y:=3" (bound 'y))
(spadcommand "x*y" (free '(x y)))

requires (read) to parse and (eval (read)) to execute.

(defun spadcommand (expr bindings)
 (when (eq (car bindings) 'bound) (hashput (cdr bindings) expr))
 (when (eq (car bindings) 'free)  (axiomeval (hashget (cdr bindings))))
 (axiomeval expr))

\start
Date: Tue, 14 Jun 2005 23:00:13 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#167 Infinite Floats Domain] Continued on another page see RealNumbers

William, thank you very much for your comments on this issue.
Your presentation above is very instructive and useful to me.
I agree completely with your statements about the relevance of

> infinite sequences of rational numbers

and also that my presumption of an

> isomorphism between the domain of infinite precision floating
> point numbers and the domain of rationals

was wrong.

In fact I think this subject, on the boarder between symbolic
and numeric computations, is very relevant to Axiom and to
computer algebra systems in general. For that reason and
since this is not really an issue about Axiom itself,
I propose that we continue this elsewhere on another page.

I've create a new page named RealNumbers. Please joint me
there. I hope others will also contribute to this subject.

\start
Date: Tue, 14 Jun 2005 22:51:40 -0500
From: Tim Daly
To: Bill Page, Kai Kaminski
Subject: XML
Cc: Heow Eide-Goodman

> > \spadcommand{x:=2}\bound{x}
> > \spadcommand{y:=3}\bound{y}
> > \spadcommand{x*y}\free{x}\free{y}
> > 
> > clicking on the third expression tells the browser that it needs to 
> > find a meaning for x and a meaning for y somewhere prior in the page.
> > these are determined by the \bound expression.
> 
> Can you give an example?

cd mnt/linux/doc/hypertex/pages
fgrep free *

\start
Date: Tue, 14 Jun 2005 23:06:15 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [RealNumbers] (new) 

Axiom implements the number domains Integer, Float and even
Fraction(Integer) i.e. rational numbers, but it does not
implement anything called Real numbers. *Why is that?*

\start
Date: Tue, 14 Jun 2005 23:33:18 -0500
From: MathAction (billpage)
To: MathAction
Subject: [RealNumbers] 

This subject was discussed in issue #167 Infinite Floats Domain

\start
Date: Tue, 14 Jun 2005 23:42:11 -0500
From: Tim Daly
To: list
Subject: Mathematics Subject Classification

There is a mathematics subject classification scheme list at
http://www.ams.org/msc
and it appears to be used at
http://www.math-atlas.org

An interesting project would be to classify Axiom's math algorithms
relative to this scheme.

\start
Date: Tue, 14 Jun 2005 23:36:03 -0500
From: MathAction (billpage)
To: MathAction
Subject: [RealNumbers] 

Computable Numbers

  In mathematics, theoretical computer science and mathematical logic,
the computable numbers, also known as the recursive numbers, are the
subset of the real numbers consisting of the numbers which can be
computed by a finite, terminating algorithm. They can be defined
equivalently using the axioms of recursive functions, Turing machines
or lambda-calculus. In contrast, the reals require the more powerful
axioms of Zermelo-Fraenkel set theory. The computable numbers form a
real closed field and can be used in the place of real numbers for some,
but by no means all, mathematical purposes.

See: http://encyclopedia.laborlawtalk.com/Computable_number

\start
Date: Tue, 14 Jun 2005 23:42:47 -0500
From: MathAction (billpage)
To: MathAction
Subject: [RealNumbers] 

++added:
Real Numbers

  In mathematics, the real numbers are intuitively defined as numbers
that are in one-to-one correspondence with the points on an infinite
line—the number line. The term "real number" is a retronym coined in
response to "imaginary number".

Real numbers may be rational or irrational; algebraic or transcendental;
and positive, negative, or zero. ...

A real number is said to be computable if there exists an algorithm that
yields its digits. Because there are only countably many algorithms, but
an uncountable number of reals, most real numbers are not computable. Some
constructivists accept the existence of only those reals that are computable.
The set of definable numbers is broader, but still only countable.

Computers can only approximate most real numbers with rational numbers;
these approximations are known as floating point numbers or fixed-point
numbers; see real data type. Computer algebra systems are able to treat
some real numbers exactly by storing an algebraic description (such as $\sqrt{2}$)
rather than their decimal approximation. 

See: http://encyclopedia.laborlawtalk.com/Real_number

\start
Date: Wed, 15 Jun 2005 00:22:40 -0500
From: Tim Daly
To: Bill Page
Subject: Real Numbers

see http://cch.loria.fr/documentation/IEEE754

in particular see William Kahan and IEEE 754. William (Velvel aka Wolf) Kahan
is the curmudgeon of floating point "real" numbers.

\start
Date: Wed, 15 Jun 2005 02:06:47 -0400
From: Bill Page
To: Tim Daly
Subject: RE: XML
Cc: Heow Eide-Goodman, Kai Kaminski

On Wednesday, June 15, 2005 12:01 AM Tim Daly wrote:

> 
> <spadcommand bound="x">{x:=2}</spadcommand>
> <spadcommand bound="y">{y:=3}</spadcommand>
> <spadcommand free="x,y">{x*y}</spadcommand>
> 
> requires a huge program to parse (DOM or SAX, callbacks) vs

No. This syntax can be easily described as a regular expression
that in principle requires nothing more complex than a simple
finite state machine to recognize. The equivalent of this has
been done in every web browser since the beginning of time. DOM,
SAX and the mechanism of callbacks refers to some specific (large
and complex) API library which may or may not be suitable to the
a depending on what one wants to do. I think this says it quite
well:

http://www.megginson.com/blogs/quoderat/archives/2005/02/08/the-complexity-o
f-xml-parsing-apis/

> (spadcommand "x:=2" (bound 'x))
> (spadcommand "y:=3" (bound 'y))
> (spadcommand "x*y" (free '(x y)))
>
> requires (read) to parse and (eval (read)) to execute.
> 
> (defun spadcommand (expr bindings)
>  (when (eq (car bindings) 'bound) (hashput (cdr bindings) expr))
>  (when (eq (car bindings) 'free)  (axiomeval (hashget (cdr bindings))))
>  (axiomeval expr))

This comparison is not reasonable since the parser you are using
is just built-in to lisp. How large is the resulting lisp code (on
typical hardware) compared to the size of the DOM and SAX libaries?
More or less the same, I expect.

There are better ways to do this. My choice for a simple "one-off"
programming problem would be a hand written recursive decent parser
consisting of a few simple routines. In C this probably wouldn't be
much larger than your lisp code.

Maybe someday I might try it this way:

http://www.codeproject.com/cpp/yard-xml-parser.asp

But these days, if a more general and complex task demands it and
it isn't a transformation that I could easily do with an XSLT
template, then I would probably choose StAX or some derivative.
For example:

http://www.oracle.com/technology/oramag/oracle/03-sep/o53devxml.html

http://www.xmlpull.org/history/index.html

http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/

Anyway, all this is irrelevant if one starts with the assumption that
a web browser already exists that understands the syntax. No new
programming is necessary.

\start
Date: Wed, 15 Jun 2005 02:25:05 -0400
From: Bill Page
To: Tim Daly
Subject: RE: XML
Cc: Heow Eide-Goodman, Kai Kaminski

On Tuesday, June 14, 2005 11:52 PM Tim Daly wrote:

> > > \spadcommand{x:=2}\bound{x}
> > > \spadcommand{y:=3}\bound{y}
> > > \spadcommand{x*y}\free{x}\free{y}
> > > 
> > > clicking on the third expression tells the browser that it needs to 
> > > find a meaning for x and a meaning for y somewhere prior in the page.
> > > these are determined by the \bound expression.
> > 
> > Can you give an example?
>
> cd mnt/linux/doc/hypertex/pages
> fgrep free *

Yes, I see it everywhere. But what does it do?

You said: "clicking on the third expression tells the browser that
it needs to find a meaning for x and a meaning for y somewhere prior
in the page."

What do you mean by "find a meaning for x"? Do you mean that when
you click on some expression (presumably intending that Axiom execute
this expression), that the browser actually builds some kind of
dependency tree and then executes (i.e. passes commands to Axiom)
the minimum number of commands needed to compute this expression?
This would be a form of lazy evaluation.

If this is the case, then Axiom's browser is doing a lot more than
just browsing. This is more or less the problem to which I was
referring when I asked in a previous email what we could do about
a set of related pages in which one page contained Axiom calculations
that depended calculations contained on one another page. In that
case I can see how this "free" and "bound" thing might be used.

Does the Axiom browser only look for bound variables occurring
earlier on the same page?

\start
Date: Wed, 15 Jun 2005 01:28:52 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [RealNumbers] real references

++added:

<hr>
>From wyscc Wed Jun 15 01:36:00 -4:00<br>

Bill, thanks for creating this page. I enjoyed reading the links and was wondering how a site on labor laws need to know the foundations of mathematics. Actually, they gave credit to the following (open) source::

http://en.wikipedia.org/wiki/Real_number<br>
http://en.wikipedia.org/wiki/Computable_number

It is interesting to note that order relations are not computable and that sums of digit-enumerable real numbers are in general not digit-enumerable. This reminds me that when I teach power series solution to differential equations, I use the analog of decimal numbers and comment that power series are easier, because they involve no carry. The same reason shows the infinite sequence approach to infinite precision floating point (essentially using digit-enumeration Turing machines) discussed in #167 Infinite Floats Domain will not work. IPFP is different from power series!

Wikipedia also has an introduction to floating point systems::

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

For in depth study, I recommend the book::

Pat H. Sterbenz, Floating-Point Computation, Prentice Hall, 1974.

Sterbenz worked at IBM Systems Research Institute, New York at the time of writing the book.

William

\start
Date: Wed, 15 Jun 2005 01:36:26 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [RealNumbers] 

Bill, thanks for creating this page. I enjoyed reading the links.

++added:

<hr>
>From Tim Daly Wednesday, June 15, 2005 1:23 AM

Subject: Real Numbers

see http://cch.loria.fr/documentation/IEEE754

in particular see William Kahan and IEEE 754. William (Velvel aka Wolf) Kahan
is the curmudgeon of floating point "real" numbers.

\start
Date: Wed, 15 Jun 2005 01:56:08 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [mathematical algorithms] 

++added:

<hr>
On Wednesday, June 15, 2005 12:42 AM Tim Daly wrote:

Subject: Mathematics Subject Classification


There is a mathematics subject classification scheme list at

http://www.ams.org/msc

and it appears to be used at

http://www.math-atlas.org

An interesting project would be to classify Axiom's math algorithms
relative to this scheme.

\start
Date: Wed, 15 Jun 2005 02:35:48 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#168 Linux Hyperdoc searches do not work] (new) 

I think the most urgent task is not to reimplement hyperdoc, but to make sure that it still works as it was (say in the NAG version). This meant all the searches and links must work. Currently (at least for the Feb release), searching does NOT work. In the NAG version, if I enter *float*, and click constructors, I get

DoubleFloat
DoubleFloatSpecialFunctions
Float
FloatingComplexPackage
FloatingPointSystem
FloatingRealPackage
*InnerNumericFloatSolvePackage
MachineFloat
MakeFloatCompiledFunction
*RandomFloatDistributions

In the Linux version, I get 

There is no constructor matching pattern "*float*"

I have also reported that links for sources do not work.

\start
Date: Wed, 15 Jun 2005 02:48:15 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#168 Linux Hyperdoc searches do not work] 

I think the most urgent task is not to reimplement hyperdoc, but to make sure that it still works as it was (say in the NAG version). This meant all the searches and links must work. Currently (at least for the Feb release), searching does NOT work. In the NAG version, if I enter 
\begin{verbatim}
*float*
\end{verbatim}
and click constructors, I get

There is no constructor matching pattern 

\begin{verbatim}
"*float*"
\end{verbatim}

I have also reported that links for source (spad files) do not work and that the names of packages and file names do not correspond.

\start
Date: Wed, 15 Jun 2005 03:54:47 -0400
From: William Sit
To: Bill Page
Subject: re: XML
Cc: Heow Eide-Goodman, Kai Kaminski

"Page, Bill" wrote:
> 
> On Tuesday, June 14, 2005 11:52 PM Tim Daly wrote:
> 
> > > > \spadcommand{x:=2}\bound{x}
> > > > \spadcommand{y:=3}\bound{y}
> > > > \spadcommand{x*y}\free{x}\free{y}
> > > >
> > > > clicking on the third expression tells the browser that it needs to
> > > > find a meaning for x and a meaning for y somewhere prior in the page.
> > > > these are determined by the \bound expression.
> > >
> > > Can you give an example?
> >
> > cd mnt/linux/doc/hypertex/pages
> > fgrep free *
> 
> Yes, I see it everywhere. But what does it do?
> 
> You said: "clicking on the third expression tells the browser that
> it needs to find a meaning for x and a meaning for y somewhere prior
> in the page."
> 
> What do you mean by "find a meaning for x"? Do you mean that when
> you click on some expression (presumably intending that Axiom execute
> this expression), that the browser actually builds some kind of
> dependency tree and then executes (i.e. passes commands to Axiom)
> the minimum number of commands needed to compute this expression?
> This would be a form of lazy evaluation.

This is exactly what the Axiom browser can do. In hyperdoc, if you click on an
example, you can click on any of the command lines even though the command
depends on earlier commands. It then opens a new frame in Axiom (that is, a
totally new and independent session) to perform the computation, making sure to
resolve all the referenced variables (I think on the same page) before
completing the clicked command. This technology is one that I find extremely
clever and so far, I have not seen the like of it (in Mathematica FrontEnd or
Maple). 

One way to appreciate this would be to try to imitate that in MathAction pages.
The advantage would be that no Axiom calls are made until the user initiates it
(this would allow some test code that are computationally intensive without
affecting user interactions like minor editing), but the user can initiate it at
any command, rather than click through from beginning to end one by one (which
presents the problem of missing one and causing subsequent problems). Also, by
starting a new frame, a user can immediately modify the command to "play" with
it, or insert any other commands.

> If this is the case, then Axiom's browser is doing a lot more than
> just browsing. This is more or less the problem to which I was
> referring when I asked in a previous email what we could do about
> a set of related pages in which one page contained Axiom calculations
> that depended calculations contained on one another page. In that
> case I can see how this "free" and "bound" thing might be used.

These declaration is how hyperdoc knows which commands on the example page need
to be fed to the new Axiom frame.
 
> Does the Axiom browser only look for bound variables occurring
> earlier on the same page?

I'll let Tim answer this one. (I believe so).

One more comment on this Axiom browser discussion: 
I think the most urgent task is not to reimplement hyperdoc, but to make sure
that it still works as it was (say in the NAG version). (see new Issue #168).

\start
Date: Wed, 15 Jun 2005 02:50:59 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomProblems] Linear Agebra problem

This doesn't work:
\begin{axiom}
L := [ A = 2*P1+P2, B = 2*P2+P1, C = 2*Q1+Q2, D = 2*Q2+Q1]
solve(L, [P1,P2])
\end{axiom}
But it should, observe this:
\begin{axiom}
SA:=solve([L.1,L.2],[P1,P2])
SB:=solve([L.3,L.4],[Q1,Q2])
\end{axiom}
First two equationa do not depend on $Q_i$, the later two don't depend on $P_i$.
Now check it again the initial set:
\begin{axiom}
S:=[SA.1.1,SA.1.2,SB.1.1,SB.1.2]
map(x+->eval(x,S),L)
\end{axiom}

\start
Date: Wed, 15 Jun 2005 03:21:54 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [RealNumbers] Computing with Exact Real Arithmetic

There is apparently a lot of work on this subject.

Some History

  http://www.rbjones.com/rbjpub/cs/cs006.htm

> The lazy digit sequence approach (similar to lazy power series) has,
> for example, been implemented by Michael Stoll in Common Lisp, 1988.

http://www.haible.de/bruno/MichaelStoll/reals.html

XR - Exact Real Arithmetic

  Overview

    This is an implementation of exact (or constructive) real arithmetic,
including python and C++ versions. It is an alternative to multiple-
precision floating-point codes. An important distinction is that in
multiple-precision floating-point one sets the precision before starting
a computation, and then one cannot be sure of the final result. Interval
arithmetic is an improvement on this, but still not an ideal solution
because if the final interval is larger than desired, there is no simple
way to restart the computation at higher precision. By constrast, in XR
no precision level is set in advance, and no computation takes place
until a final request takes place for some output.

http://more.btexact.com/people/briggsk2/XR.html

Others

A Calculator for Exact Real Number Computation

  Abstract

The most usual approach to real arithmetic on computers consists
of using floating point approximations. Unfortunately, floating
point arithmetic can sometimes produce wildly erroneous results.
One alternative approach is to use exact real arithmetic. Exact
real arithmetic allows exact real number computation to be performed
without the roundoff errors characteristic of other methods.

http://www.dcs.ed.ac.uk/home/mhe/plume

Formalising exact Arithmetic

... deals with exact rational and real arithmetic in constructive type
theory. Parts of the thesis are formalised in Coq. The thesis can be
downloaded at the following URL:

http://www.cs.ru.nl/~milad/proefschrift/thesis.pdf

\start
Date: Wed, 15 Jun 2005 03:52:19 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomProblem] Axiom fails to solve "separable" system of equations

Simpler:

\begin{axiom}
L :=[a = b, c = d]
solve(L,[b])
\end{axioim}

\start
Date: Wed, 15 Jun 2005 04:08:06 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [RealNumbers] implementing Exact Real Numbers

A certified, corecursive implementation
of exact Real Numbers

Alberto Ciaffaglione a, Pietro Di Gianantonio

http://www.dimi.uniud.it/~ciaffagl/Papers/reals.pdf

Abstract
We implement exact real numbers in the logical framework Coq using streams, i.e.,
infinite sequences, of digits, and characterize constructive real
numbers through a minimal axiomatization. We prove that our
construction inhabits the axiomatization, working formally with
coinductive types and corecursive proofs. Thus we obtain reliable,
corecursive algorithms for computing on real numbers.

\start
Date: Wed, 15 Jun 2005 07:59:45 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#169 Print empty two dimensional array (i.e. Matrix, TwonDimensionalArray ...)] (new) 

Empty one dimensional arrays are printed but no empty two dimensional array

\start
Date: Wed, 15 Jun 2005 08:09:43 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#169 Print empty two dimensional array (i.e. Matrix, TwonDimensionalArray ...)] 

++added:
in console.

\begin{axiom}
empty()$Vector(INT)
\end{axiom}
<pre>
-- without  output tex on
-- empty()$Matrix(INT)
</pre>

\start
Date: Wed, 15 Jun 2005 09:18:36 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#169 Print empty two dimensional array (i.e. Matrix, TwonDimensionalArray ...)] 

++added:
Text Mode -- empty Matrix not printed

\begin{axiom}
)set output algebra on
)set output tex off
\end{axiom}

++added:
empty()$Matrix(INT)

LaTeX mode -- empty Matrix causes error

\begin{axiom}
)set output algebra off
)set output tex on
\end{axiom}
\begin{axiom}
empty()$Vector(INT)
empty()$Matrix(INT)
\end{axiom}

\start
Date: 15 Jun 2005 10:37:29 -0400
From: Heow Eide-Goodman
To: Bill Page
Subject: RE: XML
Cc: Kai Kaminski

I'll have to agree with Tim on this...

  1. XML is open
  2. XML is standard
  3. XML really sucks

Sometimes you realize that particular practices, procedures and entire
social systems are fundementally broken.  That said, it dosen't mean you
must follow them, especially if it negatively affects your productivity.

Honestly, life is too short for me to deal with things that slow me or
stop me from writing great software, which is one of the reasons I love
and use Lisp.

"Those that do not understand Lisp are doomed to reinvent it, badly."

\start
Date: Wed, 15 Jun 2005 09:59:06 -0500
From: Tim Daly
To: list
Subject: Permission

*

Michael Stoll has given us permission to use his CREAL lisp code in
Axiom. He has power series code which we can use if we want.  Further,
he doing work in finding rational points on curves (a private
discussion elsewhere) so this is another area of potential
interest. He points out that the main inner loop is in assembler for
speed.

It turns out that my new job involves assembly code and machine
architecture and I had planned to practice on the gmp numeric
code so there is a bit of overlap.

Many thanks to Michael.

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

Dear Tim,

please feel free to use whatever you like (giving appropriate credit, of 
course). I wasn't even aware that the stuff is available somewhere - I'd be 
hard put to find it myself by now!

BTW, I have also written code to deal with power series in a similar spirit 
(including a macro that solves fairly complicated (fixed point) equations if 
that is formally possible, i.e., the n-th coefficient of the right hand side 
only involves earlier coefficients of the left hand side, as in
  F(z) = 1 + zF(z)
where the multiplication by z is encoded by a shift), which might be 
interesting for you. I'm not sure I can find it, but Bruno (who I would guess 
is the "someone" pointing out my work to you) probably has that somewhere, 
too.

Thanks for your interest,
Michael Stoll

On Monday 13 June 2005 17:53, you wrote:
> Michael,
>
> I'm Tim Daly, the lead developer on Axiom. Axiom was originally
> developed at IBM Research, was bought to NAG and was a commercial
> competitor to Mathematica and Maple. It was withdrawn from the
> market and is now free and open source software. (see
> http://savannah.nongnu.org/projects/axiom
> http://sourceforge.net/projects/axiom
> http://page.axiom-developer.org
>
> We've been discussing a new infinite-precision reals package and
> someone pointed me to your work. I'd like your permission to use
> and modify the common lisp code which is available at:
> http://www.haible.de/bruno/MichaelStoll/reals.html
>
> Axiom is released under the Modified BSD license. I don't see a
> license associated with your code so I'm not sure if I have your
> permission to use and modify it.
>
> Almost all of the code will end up being written in our algebra
> language which will simplify the whole type issue.

Dear Tim,

this is a very complex subject in general. What is certainly possible (and 
maybe this is what you are referring to) is to use my "ratpoints" program to 
search for rational points on curves of the form y^2 = f(x). However, it will 
be quite hard to achieve the same speed by an implementation in Lisp - it 
mostly depends on the efficiency of the innermost loop, which in the best 
case consists only of a handful of assembler instructions without memory 
references. It would be interesting to see, though, how fast you can get with 
Common Lisp bit vectors. Maybe it's not so bad if they are efficiently 
implemented...

Other than this, algorithms in this area tend to be rather complex and involve 
lots of number theory, which is why I am implementing these things in Magma 
(which might be interesting for you to check out if you don't know it yet; it 
appears to have some similarities regarding the strong typing with algebraic 
structures).

Best wishes,
Michael Stoll

On Monday 13 June 2005 18:51, you wrote:
> Michael,
>
> I also understand from your web page that you've done work in
> finding rational points on curves.
>
> Do you have explicit algorithms that you can point me to?
> I'd like to look at how these might be implemented in Axiom.

\start
Date: Wed, 15 Jun 2005 12:04:33 -0400
From: Bill Page
To: Heow Eide-Goodman
Subject: RE: XML
Cc: Kai Kaminski

Heow,

I think I have already explained why I think both you and Tim
are right but your conclusion is wrong. At the risk of
perpetuating a thread with marginal value, but since every
time I look on the web I find that some else has already said
it better than me, let me just quote Aaron Crane:

http://xmlsucks.org/but_you_have_to_use_it_anyway

"20. Doing It Anyway

    * XML qua technology almost seems to be a bad joke
    * But you have to do it anyway
    * Two main reasons:
         1. It's (just) good enough technologically
         2. More importantly: everyone else is doing it"

"21. Worse is Better

    * XML has many flaws
    * But the esthetic appeal of the technology is comparatively
      uninteresting
    * In practice, XML's flaws can be lived with
          o An example of 'worse is better':
            http://www.jwz.org/doc/worse-is-better.html

"Therefore, the worse-is-better software first will gain acceptance,
second will condition its users to expect less, and third will be
improved to a point that is almost the right thing. In concrete terms,
even though Lisp compilers in 1987 were about as good as C compilers,
there are many more compiler experts who want to make C compilers
better than want to make Lisp compilers better."

"one can conclude only that the Lisp community needs to seriously
rethink its position on Lisp design ..."

          o Since XML is good enough, it isn't worth replacing it"

"27. Conclusions

    * XML does have a number of technological problems, but:
          o The technological problems can be managed
          o The political and commercial advantages of working with
            the same open standard as everyone else are enormous
    * There are open-source and Linux-friendly tools which actually
      help you get your work done in an XML-besotted world, including:
          o GNOME libxml and libxslt
          o SAX-Machines or similar systems
    * XML is here to stay"

---------

>From my point of view, life is too short for me to rewrite
everything I need from scratch (in lisp) to properly apply
computer algebra to theoretical physics, but a little lisp
added in the right place goes a long way, which is why I also
love lisp and plan to use it where it makes the most sense.

-----Original Message-----
From: Heow Eide-Goodman [mailto:Heow Eide-Goodman]

I'll have to agree with Tim on this...

  1. XML is open
  2. XML is standard
  3. XML really sucks

Sometimes you realize that particular practices, procedures and entire
social systems are fundementally broken.  That said, it dosen't mean you
must follow them, especially if it negatively affects your productivity.

Honestly, life is too short for me to deal with things that slow me or
stop me from writing great software, which is one of the reasons I love
and use Lisp.

"Those that do not understand Lisp are doomed to reinvent it, badly."

\start
Date: Wed, 15 Jun 2005 11:37:57 -0500
From: Tim Daly
To: Bill Page
Subject: Floating Point

I just finished reading the details of IEEE Standard 754 (floating
point numbers). It's quite an impressive document. Highly recommended
reading.

\start
Date: Wed, 15 Jun 2005 11:34:32 -0500
From: Tim Daly
To: Bill Page, Heow Eide-Goodman, Kai Kaminski
Subject: XML

Since you're the one writing the code you're welcome to choose
whatever path you'd like. If you can make an XML path work then
that's fine with me.

\start
Date: Wed, 15 Jun 2005 19:56:16 +0200
From: Antoine Hersen
To: list
Subject: Port Tiger

Hello,

Here the progress I made so far in porting axiom to Tiger

Modified configure to add Darwin -> darwin

Modified Makefile.pamphlet Makefile.MACOSX -> Makefile.darwin
      Did not change PLF MACOSXplatform

Remove -I/usr/include/sys from CCF who caused sigaction not to be  
recognized properly

Other take care of malloc.h

My effort are now to make gcl working.

diff -u -r original/axiom/Makefile.pamphlet axiom/Makefile.pamphlet
--- original/axiom/Makefile.pamphlet    2005-06-05 05:59:28.000000000  
+0200
+++ axiom/Makefile.pamphlet    2005-06-13 22:54:49.000000000 +0200
@@ -1851,7 +1851,7 @@
<<clean>>
@
-\subsection{Makefile.MACOSX}
+\subsection{Makefile.darwin}
On the MAC OSX someone decided (probably a BSDism) to rename the
[[SIGCLD]] signal to [[SIGCHLD]]. In order to handle this in the
low level C socket code (in particular, in [[src/lib/fnct_key.c]])
@@ -1863,13 +1863,13 @@
We need to add [[-I/usr/include/sys]] because [[malloc.h]] has been
moved on this platform.
-<<Makefile.MACOSX>>=
+<<Makefile.darwin>>=
# System dependent Makefile for the MAC OSX platform
# Platform variable
PLF=MACOSXplatform
# C compiler flags
CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} \
-     -I/usr/X11/include -I/usr/include/sys"
+     -I/usr/X11/include "
# Loader flags
LDF= -L/usr/X11R6/lib
# C compiler to use
diff -u -r original/axiom/configure axiom/configure
--- original/axiom/configure    2005-06-05 05:59:28.000000000 +0200
+++ axiom/configure    2005-06-13 19:18:07.000000000 +0200
@@ -5,6 +5,7 @@
#       SunOS          --> Solaris9
#       Fedora Core 3  --> fedora3
#       freebsd        --> freebsd
+#    Darwin           --> darwin
#
# The solaris platform needs patch->gpatch, awk->gawk, tar->gtar
@@ -25,6 +26,7 @@
     elif  [ "$SYSNAME" = "MINGW32_NT-5.1" ] ; then SYSNAME=windows
     elif  [ "$SYSNAME" = "SunOS" ] ; then SYSNAME=solaris9
     elif  [ "$SYSNAME" = "freebsd" ] ; then SYSNAME=freebsd
+   elif  [ "$SYSNAME" = "Darwin" ] ; then SYSNAME=darwin
     else
       echo Your system name is $SYSNAME
       echo We do not know how to build for this kind of system
@@ -136,6 +138,7 @@
#       SunOS          --> Solaris9
#       Fedora Core 3  --> fedora3
#       freebsd        --> freebsd
+#    Darwin           --> darwin
# (1) We test for the AWK variable. We need one of gawk, nawk, or awk
#     in order to build the noweb software.
# (2) Then we output the final message for the user.
--- original/axiom/src/include/xpm.h    2003-10-09 12:45:16.000000000  
+0200
+++ axiom/src/include/xpm.h    2005-06-14 00:02:51.000000000 +0200
@@ -61,7 +61,9 @@
#ifdef FOR_MSW
# define SYSV            /* uses memcpy string.h etc. */
+#if   !defined(BSDplatform) && !defined(MACOSXplatform)
# include <malloc.h>
+#endif /*MACOSXplatform */
# include "simx.h"        /* defines some X stuff using MSW types */
#define NEED_STRCASECMP        /* at least for MSVC++ */
#else /* FOR_MSW */

--- original/axiom/src/lib/XDither.c.pamphlet    2005-06-05  
05:59:29.000000000 +0200
+++ axiom/src/lib/XDither.c.pamphlet    2005-06-14 00:03:23.000000000  
+0200
@@ -51,7 +51,7 @@
#include <stdio.h>
#include <stdlib.h>
-#if !defined(BSDplatform)
+#if   !defined(BSDplatform) && !defined(MACOSXplatform)
#include <malloc.h>
#endif
diff -u -r original/axiom/src/lib/XShade.c.pamphlet axiom/src/lib/ 
XShade.c.pamphlet
--- original/axiom/src/lib/XShade.c.pamphlet    2005-06-05  
05:59:29.000000000 +0200
+++ axiom/src/lib/XShade.c.pamphlet    2005-06-14 00:03:48.000000000  
+0200
@@ -51,7 +51,7 @@
#include "useproto.h"
#include <stdio.h>
-#if !defined(BSDplatform)
+#if   !defined(BSDplatform) && !defined(MACOSXplatform)
#include <malloc.h>
#endif
#include <stdlib.h>
diff -u -r original/axiom/src/lib/cfuns-c.c.pamphlet axiom/src/lib/ 
cfuns-c.c.pamphlet
--- original/axiom/src/lib/cfuns-c.c.pamphlet    2005-06-05  
05:59:29.000000000 +0200
+++ axiom/src/lib/cfuns-c.c.pamphlet    2005-06-14 00:04:13.000000000  
+0200
@@ -52,7 +52,7 @@
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
-#if !defined(BSDplatform)
+#if   !defined(BSDplatform) && !defined(MACOSXplatform)
#include <malloc.h>
#endif
#include <sys/types.h>

\start
Date: Wed, 15 Jun 2005 14:13:06 -0400
From: William Sit
To: Bill Page
Subject: Instructions for updates

Bill:

Could you help me and others by posting a page (with a link on FrontPage) how to
update Axiom (instead of downloading anew)? I do not mean a one-click type (that
would be nice), but some step by step instructions, even if manually entered,
would be ok (as long as it is faster than recompiling the world). The
instructions should include how/where to download/install any packages not part
of Axiom distribution, and also how to download/apply patches.

BTW: I have searched the entire wiki site for "update", but if you already have
the info, perhaps you can make it easier to find?

\start
Date: Wed, 15 Jun 2005 15:43:00 -0500
From: MathAction (billpage)
To: MathAction
Subject: [update Axiom] (new) 

How to update Axiom

  (instead of downloading it anew)

This page contains some manual step-by-step instructions which are
normally faster than recompiling Axiom from new sources. The
instructions include how/where to download/install any packages
that are not part of Axiom distribution, and also how to download
and apply patches.

\start
Date: Wed, 15 Jun 2005 15:38:02 -0500
From: MathAction (billpage)
To: MathAction
Subject: [FrontPage] 

You can "download Axiom":AxiomDownload or [build Axiom] from source code and [update Axiom]</td></tr>

\start
Date: Thu, 16 Jun 2005 04:41:00 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#170 Axiom fails to solve "separable" system of equations] 

Some examples:

\begin{axiom}
L := [ A = 2*P1+P2, B = 2*P2+P1, C = 2*Q1+Q2, D = 2*Q2+Q1]
solve(L, [P1,P2])
\end{axiom}

However:

\begin{axiom}
solve([L.1,L.2],[P1,P2])
solve([L.3,L.4],[Q1,Q2])
solve(L,[P1,P2,Q1,Q2])
\end{axiom}

Simpler:

\begin{axiom}
solve([a - b = 0, c - d = 0],[b])
linSolve([a - b, c - d],[b])
\end{axiom}

The operation 'solve' calls 'linSolve', which sets up the corresponding matrix
and vector and solves it using 'solve\$LinearSystemMatrixPackage'. This in turn
returns "failed", since the last columns of the matrix contain zeros, the
vector does not. In the example above, the matrix and vector are::

         +- 1+
   [mat= |   |,vec= [- a,d - c]]
         + 0 +


Note that 

\begin{axiom}
linSolve([a - b, 0],[b])
\end{axiom}

works.

The same happens, if the equation is not linear:

\begin{axiom}
L := [ A = 2*P1^2+P2, B = 2*P2+P1, C = 2*Q1+Q2, D = 2*Q2+Q1]
solve(L, [P1,P2])
solve([L.3,L.4],[P1,P2,Q1,Q2])
\end{axiom}

So, very probably, a fix would need to do two things:

- seperate the equations into those that do and those that don't contain the
  given variables.

- check whether those that don't contain the variables are contradicting.

- solve the others.

The second point is necessary, since

\begin{axiom}
L := [ A = P+Q, B = P-Q, C = 1, C = -1]
solve(L, [P,Q])
solve(L,[P,Q,C])
\end{axiom}

really has no solution.

\start
Date: Thu, 16 Jun 2005 05:03:09 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#170 Axiom fails to solve "separable" system of equations] 

L := [ A = 2*X+Y, B = 2*Y+X, C = 2*U+V, D = 2*V+U];
solve(L, [X,Y])

solve(L,[X,Y,U,V])

returns '"failed"', since the last columns of the matrix contain zeros, the

L := [ A = 2*X^2+Y, B = 2*Y+X, C = 2*U+V, D = 2*V+U];
solve(L, [X, Y])
)set output algebra on
)set output tex off
solve(L, [X, Y, U, V])
)set output algebra off
)set output tex on

L := [ A = P+Q, B = P-Q, C = 1, C = -1];

\start
Date: Thu, 16 Jun 2005 06:03:21 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#170 Axiom fails to solve "separable" system of equations] 

really has no solution. As far as I know, this would have to be done in the very last function defined in 'syssolp.spad', which is::

       -- general solver. Input in polynomial style  --
       solve(lr:L F,vl:L SE) ==
           empty? vl => empty()
           checkLinear(lr,vl) =>
                            -- linear system --
               soln := linSolve(lr, vl)
               soln case "failed" => []
               eqns: L EQ F := []
               for i in 1..#vl repeat
                   lhs := (vl.i::(P R))::F
                   rhs :=  rhs soln.i
                   eqns := append(eqns, [lhs = rhs])
               [eqns]

                         -- polynomial system --
           if R has GcdDomain then
             parRes:=triangularSystems(lr,vl)
             [[makeEq(map(makeR2F,f)\$PP2,vl) for f in pr]
                                                        for pr in parRes]
           else [[]]


The letter 'F' is a macro for 'FRAC POLY R' here. To check whether an equation contains a variable we have to check numerator and denominator of both sides of the equation with 'variables\$POLY R'. I do not know however, how to find out whether the equations independent of 'vl' are contradicting.

\start
Date: Fri, 17 Jun 2005 07:29:51 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#109 hyperdoc uncompress failed] Fix

The command 'uncompress' appears only in line 114 of 'src/lib/pixmap.c.pamphlet' and should be replaced by 'gunzip' there.

\start
Date: Fri, 17 Jun 2005 07:25:36 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#97 match not working] Fix

I think that this could easily be fixed, since

\begin{axiom}
stringMatch("*to*","yorktown",CHARACTER("*")$Lisp)$Lisp
\end{axiom}

works.

So we need to say::

   match(pattern,target,wildcard) == stringMatch(pattern,target,CHARACTER(wildcard)$Lisp)$Lisp

instead of::

  match(pattern,target,wildcard) == stringMatch(pattern,target,wildcard)$Lisp

in 'ISTRING'.

\start
Date: Fri, 17 Jun 2005 08:20:16 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#171 Solve handles lists of expressions differently] (nouveau) 

There are several forms of 'solve' defined in 'TRANSOLVE', among them one that takes a list of equations, another one that takes a single equation. After fixing bug #102 and #137,

\begin{axiom}
solve([exp(x)=2], [x])
\end{axiom}

returns the empty list, whereas

\begin{axiom}
solve(exp(x)=2, x)
\end{axiom}

gives the correct answer.

\start
Date: Fri, 17 Jun 2005 08:13:08 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#102 solve(sinh(z)=cosh(z), z) ] Fix

This one and bug #137 can be resolved by using the three-argument form of reduce in SOLVETRA, for example::

     solveList(lexpr:L RE, lvar:L S):L L EQ RE ==
        ans1 := solveRetract(lexpr, lvar)
        not(ans1 case "failed") => ans1 :: L L EQ RE
        lfrac:L Fraction Polynomial RE :=
           [makeFracPoly(expr, lvar) for expr in lexpr]
        trianglist := triangularSystems(lfrac, lvar)
        l: L L L EQ RE := [solve1Sys(plist, lvar) for plist in trianglist]
        reduce(append, l, [])

and similarly in all places, where '"append"/' is used. Maybe there is an alternative fix, '"append"/' does not call reduce, does it?

\start
Date: Fri, 17 Jun 2005 15:03:41 +0200
From: Constantine Frangos
To: list
Subject: (no subject)

17 June 2005

Some time ago, I managed to get axiom running under suse linux 7.2 (graphics 
not working). Recently I downloaded the latest version and got it running 
under suse linux 9.2 (with working graphics) on another machine.

I am trying to convert some of my Matlab m-files to axiom. Any
assistance with the following will be much appreciated:


(1) Is there a short way of declaring all variables in an axiom 
    function to be local ?

    In Matlab this is automatically the case and global variables have
    to be specifically declared. 

    In axiom it seems that its the opposite, creating the possibility
    of errors. Is this a design error in an otherwise very
    advanced language ?

(2) In Matlab I have a main function (in an m-file) calling another
    function, which in turn calls another function etc. Its not clear
    from the axiom book how to implement this. Does one have to use
    )read fun1.input, )read fun2.input, ...etc, and then fun1(); ?

    Any papers, reports or tutorials on the details of axiom programming
    involving multiple functions defined in separate files, calling
    each other, etc as described above would be helpful.

(3) Is there a setting in axiom to avoid having to use underscore _,
    to insert blank lines between program lines in files defining
    functions ? This seems awkward and error prone.

(4) I am using the Matlab symbolic toolbox (Maple engine). Its not
    clear from the axiom book how to typecast a unit matrix (integer
    or float) to type expression or variable in order to add it to
    another matrix containing expressions in the variable/symbol x,
    for example: A:= I + matrixins;

(5) System commands like )read, etc don't seem to work within
    functions ?

(6) Is there an axiom equivalent to Matlab's pause command ?

(7) I tried using a list to return  multiple variables from a
    function. However, this turns out to be of type any. These variables 
    can be displayed but not used in operations any further. This means
    that you have to remember the types of each variable in the list.
    Then, manually in the calling function extract and explicitly
    typecast each variable in the returned list. Is there an easier
    way of doing this ??

(8) Does the current axiom distribution with working graphics have to
    be recompiled on my older suse linux 7.2 machine (first one took 
    about 12 hours) or can I somehow copy the directory of the latest
    axiom via ethernet from  my newer suse linux 9.2 machine ?
    
\start
Date: Fri, 17 Jun 2005 16:07:52 +0200
From: Gregory Vanuxem
To: Constantine Frangos
Subject: Re: [Axiom-math] (no subject)

 C.Frangos,

Le vendredi 17 juin 2005 =E0 15:03 +0200, C.Frangos a =E9crit :
> 17 June 2005
>
> Some time ago, I managed to get axiom running under suse linux 7.2 (gra=
phics
> not working). Recently I downloaded the latest version and got it runni=
ng
> under suse linux 9.2 (with working graphics) on another machine.
>
> I am trying to convert some of my Matlab m-files to axiom. Any
> assistance with the following will be much appreciated:
>
>
> (1) Is there a short way of declaring all variables in an axiom
>     function to be local ?
>
>     In Matlab this is automatically the case and global variables have
>     to be specifically declared.
>
>     In axiom it seems that its the opposite, creating the possibility
>     of errors. Is this a design error in an otherwise very
>     advanced language ?
>
> (2) In Matlab I have a main function (in an m-file) calling another
>     function, which in turn calls another function etc. Its not clear
>     from the axiom book how to implement this. Does one have to use
>     )read fun1.input, )read fun2.input, ...etc, and then fun1(); ?
>
>     Any papers, reports or tutorials on the details of axiom programmin=
g
>     involving multiple functions defined in separate files, calling
>     each other, etc as described above would be helpful.
>
> (3) Is there a setting in axiom to avoid having to use underscore _,
>     to insert blank lines between program lines in files defining
>     functions ? This seems awkward and error prone.
>
> (4) I am using the Matlab symbolic toolbox (Maple engine). Its not
>     clear from the axiom book how to typecast a unit matrix (integer
>     or float) to type expression or variable in order to add it to
>     another matrix containing expressions in the variable/symbol x,
>     for example: A:= I + matrixins;

May be this can help,
if it's not "mathematically correct", use data stucture operation,
(TwoDimensionalArray), in other words, you have to coerce yourself
matrix(INT) for example to Matrix(POLY INT))


(205) -> a

          +99  5  5  +
          |          |
   (205)  |9   5  1  |
          |          |
          +1   5  1  +

(206) -> map(i+->i*x,a)

          + 99x  5x  5x  +
          |              |
(206)     | 9x   5x   x  |
          |              |
          +  x  5x   x   +


>
> (5) System commands like )read, etc don't seem to work within
>     functions ?
>
> (6) Is there an axiom equivalent to Matlab's pause command ?
>
> (7) I tried using a list to return  multiple variables from a
>     function. However, this turns out to be of type any. These variable=
s
>     can be displayed but not used in operations any further. This means
>     that you have to remember the types of each variable in the list.
>     Then, manually in the calling function extract and explicitly
>     typecast each variable in the returned list. Is there an easier
>     way of doing this ??
>
> (8) Does the current axiom distribution with working graphics have to
>     be recompiled on my older suse linux 7.2 machine (first one took
>     about 12 hours) or can I somehow copy the directory of the latest
>     axiom via ethernet from  my newer suse linux 9.2 machine ?
>    
> Regards,
>
> C. Frangos.

\start
Date: Fri, 17 Jun 2005 16:38:03 +0200
From: Gregory Vanuxem
To: Constantine Frangos
Subject: re: [Axiom-math] (no subject)

Hi,

Le vendredi 17 juin 2005 =E0 16:07 +0200, Vanuxem Gr=E9gory a =E9crit :
>  C.Frangos,
>
> Le vendredi 17 juin 2005 =E0 15:03 +0200, C.Frangos a =E9crit :
> > 17 June 2005
> >
> > Some time ago, I managed to get axiom running under suse linux 7.2 (g=
raphics
> > not working). Recently I downloaded the latest version and got it run=
ning
> > under suse linux 9.2 (with working graphics) on another machine.
> >
> > I am trying to convert some of my Matlab m-files to axiom. Any
> > assistance with the following will be much appreciated:
> >
> >
> > (1) Is there a short way of declaring all variables in an axiom
> >     function to be local ?
> >
> >     In Matlab this is automatically the case and global variables hav=
e
> >     to be specifically declared.
> >
> >     In axiom it seems that its the opposite, creating the possibility
> >     of errors. Is this a design error in an otherwise very
> >     advanced language ?
> >
> > (2) In Matlab I have a main function (in an m-file) calling another
> >     function, which in turn calls another function etc. Its not clear
> >     from the axiom book how to implement this. Does one have to use
> >     )read fun1.input, )read fun2.input, ...etc, and then fun1(); ?
> >
> >     Any papers, reports or tutorials on the details of axiom programm=
ing
> >     involving multiple functions defined in separate files, calling
> >     each other, etc as described above would be helpful.
> >
> > (3) Is there a setting in axiom to avoid having to use underscore _,
> >     to insert blank lines between program lines in files defining
> >     functions ? This seems awkward and error prone.
> >
> > (4) I am using the Matlab symbolic toolbox (Maple engine). Its not
> >     clear from the axiom book how to typecast a unit matrix (integer
> >     or float) to type expression or variable in order to add it to
> >     another matrix containing expressions in the variable/symbol x,
> >     for example: A:= I + matrixins;

If matrixins is a variable,

>
> May be this can help,
> if it's not "mathematically correct", use data stucture operation,
> (TwoDimensionalArray), in other words, you have to coerce yourself
> matrix(INT) for example to Matrix(POLY INT))
>
>
> (205) -> a
>
>           +99  5  5  +
>           |          |
>    (205)  |9   5  1  |
>           |          |
>           +1   5  1  +
>
> (206) -> map(i+->i*x,a)
>
>           + 99x  5x  5x  +
>           |              |
> (206)     | 9x   5x   x  |
>           |              |
>           +  x  5x   x   +

Sorry, typo error

(206) -> map(i+->i+x,a)
          + 99+x  5+x  5+x +
          |                |
(206)     | 9+x   5+x  1+x |
          |                |
          + 9+x   5+x  1+x +

>
> >
> > (5) System commands like )read, etc don't seem to work within
> >     functions ?
> >
> > (6) Is there an axiom equivalent to Matlab's pause command ?
> >
> > (7) I tried using a list to return  multiple variables from a
> >     function. However, this turns out to be of type any. These variab=
les
> >     can be displayed but not used in operations any further. This mea=
ns
> >     that you have to remember the types of each variable in the list.
> >     Then, manually in the calling function extract and explicitly
> >     typecast each variable in the returned list. Is there an easier
> >     way of doing this ??
> >
> > (8) Does the current axiom distribution with working graphics have to
> >     be recompiled on my older suse linux 7.2 machine (first one took
> >     about 12 hours) or can I somehow copy the directory of the latest
> >     axiom via ethernet from  my newer suse linux 9.2 machine ?

\start
Date: Fri, 17 Jun 2005 16:20:13 +0200
From: Martin Rubey
To: Constantine Frangos
Subject: Re: [Axiom-math] (no subject)

C. Frangos writes:
 > 
 > 17 June 2005
 > 
 > Some time ago, I managed to get axiom running under suse linux 7.2 (graphics
 > not working). Recently I downloaded the latest version and got it running
 > under suse linux 9.2 (with working graphics) on another machine.

great!

 > I am trying to convert some of my Matlab m-files to axiom. 

even better!

 > Any assistance with the following will be much appreciated:

let's try!

 > (1) Is there a short way of declaring all variables in an axiom function to
 >     be local ?


If you compile your files, this is automatically the case. However, it seems
that you want to use .input files, not .spad files?

Thinking about it, it should be automatically the case in .input files,
too. Could you send an example?

 >     In Matlab this is automatically the case and global variables have
 >     to be specifically declared. 

Mostly the same in Axiom. See section 6.16 of the Axiom Book.
 
 >     In axiom it seems that its the opposite, creating the possibility
 >     of errors. Is this a design error in an otherwise very
 >     advanced language ?
 
 > (2) In Matlab I have a main function (in an m-file) calling another
 >     function, which in turn calls another function etc. Its not clear
 >     from the axiom book how to implement this. Does one have to use
 >     )read fun1.input, )read fun2.input, ...etc, and then fun1(); ?

No, functions can call each other within on input file.

 >     Any papers, reports or tutorials on the details of axiom programming
 >     involving multiple functions defined in separate files, calling
 >     each other, etc as described above would be helpful.

See below. I'll include my latest input file that deals with garch processes.
 
 > (3) Is there a setting in axiom to avoid having to use underscore _,
 >     to insert blank lines between program lines in files defining
 >     functions ? This seems awkward and error prone.

You don't have to do this usually. Only if you want to continue a line.


 > (4) I am using the Matlab symbolic toolbox (Maple engine). Its not
 >     clear from the axiom book how to typecast a unit matrix (integer
 >     or float) to type expression or variable in order to add it to
 >     another matrix containing expressions in the variable/symbol x,
 >     for example: A:= I + matrixins;

Don't do this. You want to use the + from MATRIX INT, for example.

m1 := [[1,2],[3,4]]
m2 := [[x,y],[u,v]]

m1+m2 should add the two without complaining

 > (5) System commands like )read, etc don't seem to work within
 >     functions ?

No.

 > (6) Is there an axiom equivalent to Matlab's pause command ?

Don't know.
 
 > (7) I tried using a list to return multiple variables from a
 > function. However, this turns out to be of type any. These variables can be
 > displayed but not used in operations any further. This means that you have
 > to remember the types of each variable in the list.  Then, manually in the
 > calling function extract and explicitly typecast each variable in the
 > returned list. Is there an easier way of doing this ??

They shouldn't be converted to type ANY. Often it helps to declare your
functions. See below.

 > (8) Does the current axiom distribution with working graphics have to be
 > recompiled on my older suse linux 7.2 machine (first one took about 12
 > hours) or can I somehow copy the directory of the latest axiom via ethernet
 > from my newer suse linux 9.2 machine ?

Yes, that should work. (If the paths are the same...)

Here comes a .input from my research.

epsilon contains a garch process after you said

)re garch.input

from within axiom


Hope this helps a little bit. I'll try to detail (2) coming monday.

-- n:=100; max:=1.2*Lik2(n,w,a,b,eps); draw((w:DoubleFloat,a:DoubleFloat):DoubleFloat +-> min(Lik2(n,w,a,b,eps),max),0..3,0..4)
-- draw((w:DoubleFloat):DoubleFloat +-> Lik2(n,w,a,b,eps),0..0.5)
-- draw([[i,eps.i]::Point Float for i in 1..1000])


-- eta:=normal(0,1)$RFDIST

eta:=uniform(-sqrt(3),sqrt(3))$RFDIST

-- eta aus -1, 1, 3, 5 -> eps > w

-- eta():INT == 2*(uniform(0..3)$RIDIST)()-1 

w := 0.3356; a := 2; b := 0;

-- without this line it's not a Garch process!
)set fun cache 2 epsilon 
 
epsilon(0) == 0;
epsilon(t:INT):FLOAT == sigma(t)*eta();

)set fun cache 2 sigma

sigma(0) == 0;
sigma(t:INT):FLOAT == 
  sqrt(w+a*epsilon(t-1)^2 + b*sigma(t-1)^2)

precision(20);
eps := [epsilon(t) for t in 1..1000];

)set fun cache 2 sigma2

sigma2(0,w,a,b,eps) == 0;
sigma2(t:INT,w:FLOAT,a:FLOAT,b:FLOAT,eps:LIST FLOAT):FLOAT == 
  w + a*(eps.t)^2 + b*sigma2(t-1,w,a,b,eps)

sigma2p(0,w,x,y,eps) == 0;
sigma2p(t:INT,w:FLOAT,x:FLOAT,y:FLOAT,eps:LIST FLOAT):FLOAT == 
  w*(1 + x*(eps.t)^2 + y*sigma2p(t-1,w,x,y,eps))

Likp(n:INT,x:FLOAT,eps:LIST FLOAT):FLOAT ==
  log(1/n*reduce(+,[(eps.(t+1))^2/(1+x*(eps.t)^2) for t in 1..n])) _ 
   -1/n*reduce(+,[log(1/(1+x*(eps.t)^2)) for t in 1..n])+1

lik(t:INT,w:FLOAT,a:FLOAT,b:FLOAT,eps:LIST FLOAT):Union(FLOAT, "fail") ==
  s := sigma2(t,w,a,b,eps)
  if s <= 0
  then "fail"
  else log(s)+(eps.(t+1))^2/s

lik2(t:INT,w:FLOAT,a:FLOAT,b:FLOAT,eps:LIST FLOAT):FLOAT == 
  (l := lik(t,w,a,b,eps)) case "fail" => 1000000.0
  l

lik3(t,w,a,eps) ==
  s := w+a*eps.t^2
  if s <= 0
  then "fail"
  else log(s)+(eps.(t+1))^2/s

Lik(n:INT,w:FLOAT,a:FLOAT,b:FLOAT,eps:LIST FLOAT):Union(FLOAT, "fail") == 
  ll := 0.0
  for t in 1..n repeat
    (l := lik(t,w,a,b,eps)) case "fail" => return "fail"
    ll := ll + l::Float
  ll/n

Lik2(n:INT,w:FLOAT,a:FLOAT,b:FLOAT,eps:LIST FLOAT):FLOAT == 
  (ll := Lik(n,w,a,b,eps)) case "fail" => 1000000.0
  ll

Lik3(n,w,a,eps) == 
  1/n*reduce(+,[lik3(t,w,a,eps) for t in 1..n])

minInd(l: List List Float): List List INT == 
  m := l.(1,1)
  ind := [[1,1]]
  for i in 1..#l repeat
    for j in 1..#l.i repeat
      if l.i.j = m then 
        ind := cons([i,j], ind)
      if l.i.j < m then 
        m := l.i.j
        ind := [[i,j]]
  ind

minInd1(l: List Float): List INT == 
  m := l.1
  ind := [1]
  for i in 1..#l repeat
    if l.i = m then 
      ind := cons(i, ind)
    if l.i < m then 
      m := l.i
      ind := [i]
  ind

Likp2(n,x,eps) ==
  log(1/n*reduce(+,[(eps.(t+1))^2/(1+x*(eps.t)^2) for t in 1..n])) _ 
   -1/n*reduce(+,[log(1/(1+x*(eps.t)^2)) for t in 1..n])+1

Likp2a(n,x,eps) == log(1/n*reduce(+,[(eps.(t+1))^2/(1+x*(eps.t)^2) for t in 1..n]))

Likp2b(n,x,eps) == -1/n*reduce(+,[log(1/(1+x*(eps.t)^2)) for t in 1..n])+1

LikpLim(n,eps) == LikpLima(n,eps) + LikpLimb(n,eps) + 1

LikpLima(n,eps) == 
  log(reduce(+,[eps.(i+1)^2/eps.i^2 for i in 1..n])/n)

LikpLimb(n,eps) == 
  log(reduce(*,[eps.i^2 for i in 1..n]))/n

e:=[concat("e",i::String)::Symbol::EXPR INT for i in 1..20];

f(2)==e.1^4*e.3^2+e.2^6
f(n)==(n-1)*(reduce(*,[e.i for i in 1..n-1])^4*e.(n+1)^2+e.n^4*f(n-1)/(n-2))

g(2)==e.2^2+e.3^2
g(n)==g(n-1)*e.(n+1)^2+reduce(*,[e.i^2 for i in 1..n-2])*e.n^2*e.(n+1)^2

-- n := 5; factor(reduce(+, select(e +-> leadingCoefficient (e) = n-1, monomials leadingCoefficient(numer(D(Likp2(n,x,[e1,e2,e3,e4,e5,e6]),x)::FRAC POLY INT::FRAC UP(x, POLY INT)))))::DMP([e1,e2,e3,e4,e5,e6], INT))-f(n)

-- n := 5; factor(reduce(+, select(e +-> leadingCoefficient (e) = -1, monomials leadingCoefficient(numer(D(Likp2(n,x,[e1,e2,e3,e4,e5,e6]),x)::FRAC POLY INT::FRAC UP(x, POLY INT)))))::DMP([e1,e2,e3,e4,e5,e6], INT))



-- n:=normal(0,1)$RFDIST
-- 
-- epsilon(w,a,b,0) == 0
-- epsilon(w:FLOAT,a:FLOAT,b:FLOAT,t:INT):FLOAT == sigma(w,a,b,t)*rnormal()
-- 
-- sigma(w,a,b,0) == 0
-- sigma(w:FLOAT,a:FLOAT,b:FLOAT,t:INT):FLOAT == sqrt(w+a*epsilon(w,a,b,t-1)^2+b*sigma(w,a,b,t-1)^2) 
-- 
-- sigma2(0,w,a,b,eps) == 0
-- sigma2(t:INT,w:FLOAT,a:FLOAT,b:FLOAT,eps:LIST FLOAT):FLOAT == w+a*(eps.t)^2+b*sigma2(t-1,w,a,b,eps)^2
-- 
-- lik(t:INT,w:FLOAT,a:FLOAT,b:FLOAT,eps:LIST FLOAT):FLOAT == log(sigma2(t,w,a,b,eps))+(eps.(t+1))^2/sigma2(t,w,a,b,eps)
-- Lik(n:INT,w:FLOAT,a:FLOAT,b:FLOAT,eps:LIST FLOAT):FLOAT == reduce(+,[lik(t,w,a,b,eps) for t in 1..n])/n
-- 
-- precision(10)
-- eps := [epsilon(1,1/2,1/2,t) for t in 1..10]

\start
Date: 17 Jun 2005 10:35:40 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: GCL HTTP
Cc: Kai Kaminski

Greetings!  

Yes, we are only waiting on 2.6.7 for Windows gcl-tk.  If axiom is
going the web route instead, we could push it out asap.  I'm still a
little unclear as to which of the gcl-tk/webserver options axiom will
be using for docs and graphics.  If we can clarify this, it would help
me plan official gcl releases.

Take care,

Bill Page writes:

> Kai,
> 
> You are right that it is GCL problem. As I said previously
> this only works with GCL tagged version VERSION_2_6_7pre
> (and probably also GCL CVS head, but I haven't tested this).
> If you are still using GCL 2.6.6 then you also need the
> patch that Camm gave here:
> 
> http://lists.gnu.org/archive/html/axiom-developer/2005-04/msg00141.html
> 
> I have run this code on both Fedora Core 3 x86-64 and on
> Windows XP but I don't know anyone who has tried it on
> a MAC. Let me know how it goes.
> 
> BTW, if you haven't started using the axiom archives yet,
> I think you will find that it contains a lot of useful
> stuff. For example, at
> 
> http://lists.gnu.org/archive/html/axiom-developer
> 
> try this:
> 
> http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=%22simple+web+serv
> er%22&submit=Search%21&idxname=axiom-developer&max=10&result=normal&sort
> =date%3Aearly
> 
> Also, if you haven't yet subscribed to the gcl-devel email
> list, you might also be interested to know that there is has
> been some recent and ongoing work on the GCL on OS/X.
> 
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> Regards,
> Bill Page.
> 
> --------
> On June 17, 2005 8:22 AM you wrote:
> 
> > I tried to figure out what the problem might be and this is
> > what I found so far. The problem is that GCL does not create
> > a socket.
> > Suppose I type
> > 
> > GCL> (defun server (stream) (close stream))
> > GCL> (setq s (si::socket 11111 :server #'server))
> > 
> > Then GCL successfully creates a socket, according to netstat.
> > If I connect to localhost:11111 with netcat that also works,
> > according to netstat. Nevertheless (si::listen s) and (listen s)
> > always return NIL. Even if I type something in Netcat and send it.
> > This explains why your code does not work on my system. Ignoring
> > (listen s) and just reading from s does not work, by the way.
> > An end-of-file condition is signaled. Writing to s, e.g.
> > (format s "Text"), provokes an error message ("Error in FORMAT
> > [or a callee]: error writing to socket: errno= 57") and throws me
> > into the debugger.
> >
> > To me this looks like a GCL/Mac problem.

\start
Date: Fri, 17 Jun 2005 11:37:40 -0400
From: Bill Page
To: Constantine Frangos
Subject: RE: (no subject)

On June 17, 2005 9:04 AM C. Frangos wrote:

> (1) Is there a short way of declaring all variables in an
>    axiom function to be local ?
>
>    In Matlab this is automatically the case and global variables
>    have to be specifically declared. 
>
>    In axiom it seems that its the opposite, creating the
>    possibility of errors. Is this a design error in an
>    otherwise very advanced language ?

When you say "axiom function" I suppose you mean
defining functions in the Axiom interpreter. The
Axiom interpreter is really intended primarily for
online interactive use.

If you are converting a lot of Matlab code I think
you would be much better advised to write Axiom
library packages and/or new domains.

> (2) In Matlab I have a main function (in an m-file) calling
>   another function, which in turn calls another function etc.
>   Its not clear from the axiom book how to implement this.
>   Does one have to use )read fun1.input, )read fun2.input,
> ...etc, and then fun1(); ?

No. )read only instructions the interpret to get it's input
from a file instead of from the console.

Calling functions in Axiom is done the same way as
in most other high level languages except that Axiom's
programming language (library compiler) permits simple
overloading of function names based on types. So for
example a function named 'average' may do quite different
things if is applied to matrix compared to a list etc.

>   Any papers, reports or tutorials on the details of axiom
>   programming involving multiple functions defined in separate
>   files, calling each other, etc as described above would be
>   helpful.

I highly recommend reading the Chapter 11 Packages in the
Axiom Book.

> (3) Is there a setting in axiom to avoid having to use
>     underscore _, to insert blank lines between program
>     lines in files defining functions ? This seems awkward
>     and error prone.

This is an artifact of trying to use the Axiom interpreter
environment for programming. _ is not required in .input
files read by )read nor is is used in Axiom library
programming.

> (4) I am using the Matlab symbolic toolbox (Maple engine). Its
>    not clear from the axiom book how to typecast a unit matrix
>    (integer or float) to type expression or variable in order
>    to add it to another matrix containing expressions in the
>    variable/symbol x, for example: A:= I + matrixins;

I am not sure what you mean, but this works for me for example

  1> A:=matrix [[x,y],[z,w]]
  2> A+1

See

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

> (5) System commands like )read, etc don't seem to work within
>    functions ?

It is not clear to me why you want to do this.

> (6) Is there an axiom equivalent to Matlab's pause command ?

I don't think so. Probably a call to a simple lisp function
could do this.

> (7) I tried using a list to return  multiple variables from a
>    function. However, this turns out to be of type any. These
>    variables can be displayed but not used in operations any
>    further. This means that you have to remember the types of
>    each variable in the list. Then, manually in the calling
>    function extract and explicitly typecast each variable in
>    the returned list. Is there an easier way of doing this ??

Axiom remembers the actual type. Try this

  1> f() = [x,"x",1]
  2> f().1 + 1
  3> concat(f().2,"y")
  4> f().3 + 1

> (8) Does the current axiom distribution with working graphics
>    have to be recompiled on my older suse linux 7.2 machine
>   (first one took about 12 hours) or can I somehow copy the
>   directory of the latest axiom via ethernet from  my newer
>   suse linux 9.2 machine ?
    
You might have problems with incompatible versions of system
librarys if you try to copy Axiom compiled on a newer
version of suse to an older one. You might be able to just
do

  cvs update
  ./configure
  (set variables)
  make

on your old system. In principle this *might* not require
a complete rebuild of Axiom.

\start
Date: Fri, 17 Jun 2005 16:07:03 -0700
From: Bob McElrath
To: Martin Rubey
Subject: Re: Summer Of Code
Cc: Heow Eide-Goodman

Google just expanded the "Summer of code" to include 400 participants
(double).  http://code.google.com

Who was coordinating with google?  Can we request to be a sponsoring
organization again?

Martin Rubey [Martin Rubey] wrote:
> Dear Heow (especially!), dear Tim, Bill,
> 
> since is not going to be supported (would have been to good to be true), I
> would like to embrace your offer, Heow!
> 
> Looking through the WishList and SummerOfCode page, I find the following two
> projects which are probably Lisp related:
> 
> II. 1. work on the windows version of the browser and graphics
> 
> (this is definitely Lisp)
> 
> VI. 1. Complete the (re-)integration of the Aldor compiler into the open source
> version of Axiom.
> 
> (not sure about this one. Certainly more difficult, however. On the other hand,
> since Lisp is *the* language for implementing languages and Aldor is completely
> specified, maybe it would be worthwhile and not too difficult to write a little
> Aldor compiler in Lisp? -- even though this is sort of a different goal then
> VI. 1.)
> 
> see
> 
> http://page.axiom-developer.org/zope/mathaction/SummerOfCode
> 
> for details.
> 
> It would be wonderful, wonderful, wonderful if one or both of these projects
> would be completed.

\start
Date: 17 Jun 2005 19:27:59 -0400
From: Heow Eide-Goodman
To: Bob McElrath
Subject: Re: Summer Of Code

I'm (Heow from LispNYC) coordinating with Google.

Still waiting for my login to their system so I'm hearing everything
second-hand ...and you third-hand.  :-)

Anyway, LispNYC is still working on procedures for processing of the
applications (which it looks like we're doing) with the words
"inclusive" as our mantra.

Cheers,

- Heow

On Fri, 2005-06-17 at 19:07, Bob McElrath wrote:
> Google just expanded the "Summer of code" to include 400 participants
> (double).  http://code.google.com
> 
> Who was coordinating with google?  Can we request to be a sponsoring
> organization again?
> 
> Martin Rubey [Martin Rubey] wrote:
> > Dear Heow (especially!), dear Tim, Bill,
> > 
> > since is not going to be supported (would have been to good to be true), I
> > would like to embrace your offer, Heow!
> > 
> > Looking through the WishList and SummerOfCode page, I find the following two
> > projects which are probably Lisp related:
> > 
> > II. 1. work on the windows version of the browser and graphics
> > 
> > (this is definitely Lisp)
> > 
> > VI. 1. Complete the (re-)integration of the Aldor compiler into the open source
> > version of Axiom.
> > 
> > (not sure about this one. Certainly more difficult, however. On the other hand,
> > since Lisp is *the* language for implementing languages and Aldor is completely
> > specified, maybe it would be worthwhile and not too difficult to write a little
> > Aldor compiler in Lisp? -- even though this is sort of a different goal then
> > VI. 1.)
> > 
> > see
> > 
> > http://page.axiom-developer.org/zope/mathaction/SummerOfCode
> > 
> > for details.
> > 
> > It would be wonderful, wonderful, wonderful if one or both of these projects
> > would be completed.

\start
Date: Fri, 17 Jun 2005 19:10:13 -0500
From: Tim Daly
To: Chris DiBona
Subject: summer of code expansion
Cc: Bob McElrath

Chris,

I understand that the summer of code has been expanded to 400 participants.
Is there any openings for new sponsoring organizations?
If so, can I resubmit Axiom's entry?
We're already working with a potential summer of code student thru LispNYC.

Tim Daly

\start
Date: Fri, 17 Jun 2005 18:43:45 -0700
From: Bob McElrath
To: Tim Daly
Subject: axiom server crash?

Tim, it looks like the main axiom site is down.  After a long wait I get
a "Bad Gateway!" error:

     The proxy server received an invalid response from an upstream
     server. 

     The proxy server could not handle the request <EM><A
     HREF="/zope/mathaction">GET&nbsp;/zope/mathaction</A></EM>.<P>
     Reason: <STRONG>Error reading from remote server</STRONG> 

\start
Date: Fri, 17 Jun 2005 21:02:23 -0500
From: Tim Daly
To: Bob McElrath
Subject: axiom server crash?
Cc: list

your check didn't clear :-)

http://savannah.nongnu.org/projects/axiom works
http://sourceforge.net/projects/axiom works
http://page.axiom-developer.org works

\start
Date: Fri, 17 Jun 2005 19:13:22 -0700
From: Bob McElrath
To: Tim Daly
Subject: Re: axiom server crash?

Tim Daly [Tim Daly] wrote:
> your check didn't clear :-)
> 
> http://savannah.nongnu.org/projects/axiom works
> http://sourceforge.net/projects/axiom works
> http://page.axiom-developer.org works

Check your logs, because the error it gave me was from your server, and
couldn't have been local to me...

\start
Date: Fri, 17 Jun 2005 21:33:02 -0500
From: Tim Daly
To: Bob McElrath
Subject: axiom server crash?

which one?

http://savannah.nongnu.org/projects/axiom works
http://sourceforge.net/projects/axiom works
http://page.axiom-developer.org works

\start
Date: Fri, 17 Jun 2005 22:03:57 -0500
From: Tim Daly
To: Bob McElrath
Subject: macosx axiom

Most of the heavy lifting to BSD has been done by Mark Murray.
He's sent me a set of patches, most of which have been merged.
The outstanding issue is that there is a change to GCL that
needs to be made, which I believe is now in the latest gcl-pre.

Once that happens then we can conditionalize the lisp code in the
makefiles and it is rumored to work. This is still to be tested.

\start
Date: Fri, 17 Jun 2005 19:53:10 -0700
From: Bob McElrath
To: Tim Daly
Subject: macosx

Can someone tell me the status of the macosx port of axiom?

One of my collaborators wants to use it, and mac's are incredibly common
among physicists these days.

FYI we're discussing teaching a computer algebra course, and I hope to
get axiom involved here.

\start
Date: Fri, 17 Jun 2005 19:35:42 -0700
From: Bob McElrath
To: Tim Daly
Subject: Re: axiom server crash?

Tim Daly [Tim Daly] wrote:
> which one?
> 
> http://savannah.nongnu.org/projects/axiom works
> http://sourceforge.net/projects/axiom works
> http://page.axiom-developer.org works

It was a zope error on page.axiom-developer.org.  And my browser crashed
so I don't have it on my screen anymore.

They all work now...

\start
Date: Fri, 17 Jun 2005 23:27:06 -0500
From: MathAction (unknown)
To: MathAction
Subject: [mirrors] Axiom and Suse

Will Axiom run under Suse Linux?

\start
Date: Sat, 18 Jun 2005 01:40:26 -0500
From: MathAction (unknown)
To: MathAction
Subject: [mirrors] AXIOM on SuSE

I have had runing AXIOM on several SuSE versions up to 9.1 (not
checked for newer ones). If you compile AXIOM, as I do, you need
probably to install additional packages, eg TeX (teTeX is fine) and
some xdeveloper packages. Perhaps you need also binutils installed
either. Somewhere around is a list what packages are needed.

\start
Date: Sat, 18 Jun 2005 08:46:59 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#172 bezout.spad.pamphlet and Knuth's reference]

  ++ Reference: Knuth, The Art of Computer Programming, 3rd edition,
  ++            Vol. 2, p. 673, problem 12.

\start
Date: Sat, 18 Jun 2005 08:45:38 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#172 bezout.spad.pamphlet and Knuth's reference] (new) 

It's written::

 ++ Reference: Knuth, The Art of Computer Programming, 2nd edition,
 ++            Vol. 2, p. 619, problem 12.

I propose to add or change::

  ++ Reference: Knuth, The Art of Computer Programming, 2nd edition,
  ++            (third edition) Vol. 2, p. 673, problem 12.

Or answers to exercices (section 4.6.1: Divisions of Polynomials).

\start
Date: Sat, 18 Jun 2005 10:14:13 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#173 (1 . failed) cannot be coerced to mode (Integer) in TriangularMatrixOperations] (new) 

a:=matrix ([[1,2],[0,9]])
inverse(a)
)expose TriangularMatrixOperations
UpTriBddDenomInv(a,9)
UpTriBddDenomInv(a,7)
a:=transpose(a)
inverse(a)
LowTriBddDenomInv(a,9)
LowTriBddDenomInv(a,7)

\start
Date: Sat, 18 Jun 2005 10:13:47 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#173 (1 . failed) cannot be coerced to mode (Integer) in TriangularMatrixOperations] (new) 

a:=matrix ([[1,2],[0,9]])
inverse(a)
)expose TriangularMatrixOperations
UpTriBddDenomInv(a,9)
UpTriBddDenomInv(a,7)
a:=transpose(a)
inverse(a)
LowTriBddDenomInv(a,9)
LowTriBddDenomInv(a,7)

\start
Date: Sat, 18 Jun 2005 10:14:28 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#174 (1 . failed) cannot be coerced to mode (Integer) in TriangularMatrixOperations] (new) 

a:=matrix ([[1,2],[0,9]])
inverse(a)
)expose TriangularMatrixOperations
UpTriBddDenomInv(a,9)
UpTriBddDenomInv(a,7)
a:=transpose(a)
inverse(a)
LowTriBddDenomInv(a,9)
LowTriBddDenomInv(a,7)

\start
Date: Sat, 18 Jun 2005 10:24:47 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#173 (1 . failed) cannot be coerced to mode (Integer) in TriangularMatrixOperations] 

++added:
>From functions's declaration::

    UpTriBddDenomInv: (M,R) -> M
      ++ UpTriBddDenomInv(B,d) returns M, where
      ++ B is a non-singular upper triangular matrix and d is an
      ++ element of R such that \spad{M = d * inv(B)} has entries in R.

Here, it's false, but may be use another error message

\start
Date: Sat, 18 Jun 2005 10:28:23 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#173 (1 . failed) cannot be coerced to mode (Integer) in TriangularMatrixOperations] 

a:=matrix ([[1,2],[0,9]])

\start
Date: Sat, 18 Jun 2005 10:14:22 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#174 (1 . failed) cannot be coerced to mode (Integer) in TriangularMatrixOperations] (new) 

a:=matrix ([[1,2],[0,9]])
inverse(a)
)expose TriangularMatrixOperations
UpTriBddDenomInv(a,9)
UpTriBddDenomInv(a,7)
a:=transpose(a)
inverse(a)
LowTriBddDenomInv(a,9)
LowTriBddDenomInv(a,7)

\start
Date: Sun, 19 Jun 2005 11:00:20 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#175 Works on implementation and/or documentation of LieSquareMatrix] (new) 

>From the implemetation of LieSquuareMatrix::

    Exports ==> Join(SquareMatrixCategory(n,R,Row,Col), CoercibleTo Matrix R,_
      FramedNonAssociativeAlgebra R)


\begin{axiom}
lieAlgebra?()$LieSquareMatrix(2,FRAC INT)
a:=matrix([[1/2,3/4],[7/2,5/7]])$LieSquareMatrix(2,FRAC INT)
a*a
b:=matrix([[2,4/7],[7/2,5/7]])$LieSquareMatrix(2,FRAC INT)
a*b
1$LieSquareMatrix(2,FRAC INT)
\end{axiom}
\begin{axiom}
a:=matrix([[1/2,3/4],[7/2,5/7]])$LieSquareMatrix(2,FRAC INT)
minRowIndex a
\end{axiom}

\start
Date: Sun, 19 Jun 2005 11:25:08 -0500
From: Tim Daly
To: list
Subject: Manuel Bronstein

As I've mentioned on these mailing lists before, the Axiom 
community lost another major contributor. Like Dick Jenks,
Manuel Bronstein was one of the key developers of the original
Axiom system. He was also active with me behind the scenes,
has contributed his thesis work for documentatin purposes,
and has done large pieces of software (SUMit and  as a
supervisor for Niklaus Mannhart, PIit, plus an integrator
for Maple).

There have been several emails crossing my desk about Manuel
but this one I want to share with you mostly out of concern
for his family. Manuel leaves behind a wife and 6 children.

Tim

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

Date: Sun, 19 Jun 2005 02:19:22 -0400
From: Emil Volcheck
To: sigsam_officers@acm.org
Subject: From Manuel's brother Yonah

Hello, everyone,

Manuel's brother Yonah relays some unfortunate news.  Manuel did not
have life insurance, and his family needs financial help.  See below.

I replied asking him to provide bank account information for people
outside the US who might want to make transfers.  When I get that
information, I'll send out a broader announcement.  I also asked if he
needs help finding people to sort through Manuel's scientific papers.

.....[snip].....

FYI: the organization Yonah refers to is an orthodox Lubavitcher
synagogue, Chabad of Greater South Bay,
http://www.chabadpaloalto.com/  .

Thanks,

--Emil


----- Forwarded message from manukarola@free.fr -----

Date: Fri, 17 Jun 2005 14:46:13 +0200
From: manukarola@free.fr
To: Emil Volcheck
Cc: yab@ASTAV.net
Subject: Re: Condolences

Dear Mr. Volcheck,

This is Yonah Alexandre Bronstein, Manuel's brother, helping Tamara with her
emails. I came in to help bury Manu and help Tamara deal with the aftermath of
his death.

If you can forgive me for being practical, Manuel unfortunately passed away
without life insurance (he was in between 2 contracts), and so now Tamara and
her 6 kids face some financial difficulties as well.

I have therefore organized a support fund for Manuel's family, based in
California (where I live and will be able to help manage it). Those who want to
help can send checks:
.to the order of: CHABAD
.mention: "MANUEL BRONSTEIN FAMILY FUND"
.address:
CHABAD
3070 LOUIS ROAD
PALO ALTO, CA 94303
USA

I'd be most grateful if you could diffuse that information as you feel is
appropriate, through the ACM and other professional organizations who knew
Manuel.

Thank you very much,

Yonah Alexandre Bronstein, Ph.D.
yab@ASTAV.net
1-650-799-0627

\start
Date: Mon, 20 Jun 2005 16:11:42 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: [Axiom-math] (no subject)
Cc: Constantine Frangos

>  > (7) I tried using a list to return multiple variables from a
>  > function. However, this turns out to be of type any. These variables can be
>  > displayed but not used in operations any further. This means that you have
>  > to remember the types of each variable in the list.  Then, manually in the
>  > calling function extract and explicitly typecast each variable in the
>  > returned list. Is there an easier way of doing this ??

I am somehow surprised that Axiom cannot work with multivalues.

(1) -> foo(a: Integer, b: Integer): (String, Integer) == ("sum", a+b);

    The constructor Tuple takes 1 argument and you have given  2  .
(1) -> foo: (Integer, Integer) -> (String, Integer)

    The constructor Tuple takes 1 argument and you have given  2  .

In Aldor the following program works just fine.

Ralf

------------ multi.as -------------------------------------
-- Run the program via
-- aldor -grun -laldor multi.as
-- and get the output
--: We call the function foo
--: foo(7, 11) = (Sum, 18)

#include "aldor"
#include "aldorio"

import from Integer;
foo(a: Integer, b: Integer): (String, Integer) == ("Sum", a+b);
main(): () == {
	stdout << "We call the function foo" << newline;
	(s, c) := foo(7, 11);
	stdout << "foo(7, 11) = (" << s << ", " << c << ")" << newline;
}
main();

\start
Date: Mon, 20 Jun 2005 16:25:26 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: [Axiom-math] (no subject)
Cc: Constantine Frangos

Ralf Hemmecke writes:

 > >  > (7) I tried using a list to return multiple variables from a
 > >  > function. However, this turns out to be of type any. These variables
 > >  > can be displayed but not used in operations any further. This means
 > >  > that you have to remember the types of each variable in the list.
 > >  > Then, manually in the calling function extract and explicitly typecast
 > >  > each variable in the returned list. Is there an easier way of doing
 > >  > this ??
 > 
 > I am somehow surprised that Axiom cannot work with multivalues.
 > 
 > (1) -> foo(a: Integer, b: Integer): (String, Integer) == ("sum", a+b);
 > 
 >     The constructor Tuple takes 1 argument and you have given  2  .
 > (1) -> foo: (Integer, Integer) -> (String, Integer)
 > 
 >     The constructor Tuple takes 1 argument and you have given  2  .
 > 

In axiom you need to use records:

foo(a: Integer, b: Integer): Record(s: String, r:Integer) == ("sum", a+b);

Martin

(Although I'm completely convinced that Aldor is superiour)

\start
Date: Mon, 20 Jun 2005 17:03:57 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: [Axiom-math] (no subject)
Cc: Constantine Frangos

> In axiom you need to use records:
> 
> foo(a: Integer, b: Integer): Record(s: String, r:Integer) == ("sum", a+b);

Oh, interesting. I would have thought that your line gives a syntax 
error. At least according to the axiom book pp 141 (Section 2.4) one 
should write

foo(a:Integer,b:Integer):Record(s:String,r:Integer)==["sum",a+b];
u := foo(7,11)
u.s
u.r

The Axiom interpreter seems to be clever enough to correctly convert 
("sum", a+b) into the record ["sum", a+b].

For programming, however, I prefer the Aldor way where it gives on your 
line above the following ...

--- begin multi.as
#include "aldor"
#include "aldorio"
import from Integer;
foo(a:Integer,b:Integer):Record(s:String,s:Integer)==("Sum",a+b);
--- end multi.as

aldor -grun -laldor multi.as
"multi.as", line 11:
foo(a: Integer, b: Integer): Record(s: String, s: Integer) == ("Sum", a+b);
...............................................................^
[L11 C64] #1 (Error) Have determined 1 possible types for the expression.
	Meaning 1: String, AldorInteger
   The context requires an expression of type Record(s: String, s: 
AldorInteger).

Ralf

\start
Date: Mon, 20 Jun 2005 16:41:19 +0200
From: Ralf Hemmecke
To: list
Subject: compiling axiom ... The root module <<*>> was not defined.

There seems to be a little error in the documentation (see below)
I hope that does not turn into some missing documentation somewhere.
I found this by accident and wondered why the compilation process did 
not stop when there is obviously something not as it should be.

Ralf

--- snip ---
1 making 
/home/hemmecke/OTHER/Axiom/axiom--main--1--patch-40/int/doc/axiom.bib 
from 
/home/hemmecke/OTHER/Axiom/axiom--main--1--patch-40/src/doc/axiom.bib.pamphlet
3 making 
/home/hemmecke/OTHER/Axiom/axiom--main--1--patch-40/mnt/linux/doc/DeveloperNotes.dvi 
from 
/home/hemmecke/OTHER/Axiom/axiom--main--1--patch-40/src/doc/DeveloperNotes.pamphlet
The root module <<*>> was not defined.
4 making 
/home/hemmecke/OTHER/Axiom/axiom--main--1--patch-40/mnt/linux/doc/book.dvi 
from 
/home/hemmecke/OTHER/Axiom/axiom--main--1--patch-40/src/doc/book.pamphlet
The root module <<*>> was not defined.
5 building 
/home/hemmecke/OTHER/Axiom/axiom--main--1--patch-40/mnt/linux/doc/Rosetta.dvi 
from 
/home/hemmecke/OTHER/Axiom/axiom--main--1--patch-40/src/doc/Rosetta.pamphlet
The root module <<*>> was not defined.
--- snap ---

\start
Date: Mon, 20 Jun 2005 10:17:09 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#176 Factored Polynomials aren't differentiated correctly] (new) 

\begin{axiom}
p := -x*y^2+x*y+x^3-x^2
D(factor(p),x)
D(p,x)
\end{axiom}

Note that the factorization is correct. It's the D(.,x) that misses the sign.

\start
Date: Mon, 20 Jun 2005 10:46:08 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: compiling axiom...

Ralf,

The message 

  The root module <<*>> was not defined

just means that there was no code in the file.
I'll fix it. 

\start
Date: Mon, 20 Jun 2005 14:06:50 -0500
From: MathAction (unknown)
To: MathAction
Subject: [FrontPage] Axiom problems

Few days ago I posted a problem to "Axiom problems" page. Since then, I cannot enter that page to check what is the status of this problem! Anytime I try to enter "Axiom problems" page, the server seems to hangup (at least I do not get any response). That's why I post this comment to this page. Anyone knows what's up?

\start
Date: Mon, 20 Jun 2005 14:08:02 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#177 expand (cos (2*x))] (new) 

expand (cos (x+y)) and expand (cos (x+y+z)) are right.

Is it possible to expand cos (2*x) = 2*cos(x)^2-1 or 1 - 2*sin(x)^2

\start
Date: Mon, 20 Jun 2005 15:29:19 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#178 Linear Agebra problem] (new) 

This doesn't work:
\begin{axiom}
L := [ A = 2*P1+P2, B = 2*P2+P1, C = 2*Q1+Q2, D = 2*Q2+Q1]
solve(L, [P1,P2])
\end{axiom}
But it should, observe this:
\begin{axiom}
SA:=solve([L.1,L.2],[P1,P2])
SB:=solve([L.3,L.4],[Q1,Q2])
\end{axiom}
First two equationa do not depend on $Q_i$, the later two don't depend on $P_i$.
Now check it again the initial set:
\begin{axiom}
S:=[SA.1.1,SA.1.2,SB.1.1,SB.1.2]
map(x+->eval(x,S),L)
\end{axiom}

\start
Date: Mon, 20 Jun 2005 15:31:09 -0500
From: MathAction (billpage)
To: MathAction
Subject: [AxiomProblems] See issue #178

This problem has been documented as #178 Linear Agebra problem

\start
Date: Mon, 20 Jun 2005 15:35:55 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [FrontPage] [FrontPage] Axiom problems

Dear Unknown,

(You should set preferences to identify yourself.)

> Anyone knows what's up?

I don't know what was causing the problem exactly.
But the last comment posted to AxiomProblems definitely
was causing the server to go into some kind of loop.
When I deleted that message everything seems ok.

The contents of that comment has been copied to issue
#178. Please continue discussion there.

Regards,
Bill Page.

\start
Date: Mon, 20 Jun 2005 18:35:08 -0500
From: Tim Daly
To: Bill Page, Kai Kaminski, Camm Maguire, Martin Rubey
Subject: axiom, browsers, and crystal

taking this discussion away from the short term summer of code 
so we can think about the bigger issues.....

in the long term (the 30 year horizon) it seems clear that some
sort of browser-like capabilities are assumed. the limitations we
have now seems to be things like:

*  the syntax of the web page does not have a semantic model

we're trying to build a research science platform, not a display GUI object.
we'd like the GUI piece of the system to have a clean, programmable semantics
so we can reason about user actions. we want to reflect user actions (say
handwriting, gestures, clicks, eye-gazes) and system state (say branch cut
crossings, solid model data structure stresses, hill climbing search progress,
as subtle changes to the screen. 

Think of a search space program that does hill climbing (or root finding, 
or ...) that presents it's current state on the system. The user gaze
shifts to various areas and the gaze tracking hardware gives us a vector
for a direction to explore.

*  the DOM model is hierarchical

the DOM is a Document Object Model. it's basically a hierarchical data
structure and it suffers from the same problems that databases used to
suffer, that is, the hierarchy. Hierarchical databases ruled the day
until new theory came around and the world went relational (I know most
of you don't remember it but there was a HUGE fight about this. I attended
a committee meeting about this at a database conference and the major
objection was there would never be enough horsepower or memory to handle
relational searches... beware the future).

*  the DOM model is not really math-aware

i'd envision the DOM being a surface-level representation of the actual
data structures used. the DOM would be available in one of the facets
of the crystal, possibly to support old browsers. there are much more
useful and efficient data structures for representing problem spaces,
state spaces, and system state.

*  the browser cannot interact with the filesystem
*  the browser pages cannot be drawn upon
*  the browser pages are "paper-like"

the browser is a dumb tool at the moment. we need to break out of the
mold, pick a particular browser, and make our own version of it. our
version can be modified to do read/write of the file system, handle
socket connections, present tabbed pages or sub-areas as an active
canvas so Axiom can write graphics or text to them in real time, present
a section of the screen as command-line I/O, show axiom state in special
tabs, allow the browser to start axiom, let it speak lisp, etc.

in short, we need to stop struggling with the limits of current browser
technology, take a standard browser and extend it to our purposes. in
fact, i expect we could do what we do with GCL: package our own version
from a tgz file and add patches to do what axiom needs.

in the 30 year horizon we need something that is useful, impressive,
and reasonably modern. today's tools just hint at what will be common.
we need to listen to the hints, anticipate the needs, and get out in front.
the term i've been using is a "crystal" which is an object with many facets
that "floats" around a central problem description in its own representation.

we need to think about the researcher's problem space in a much deeper
form than current systems do (including Axiom). in the long term we want
to be at the center of the tool set that researchers use to solve problems.

research is long-term, detail-tedious, and takes a lot of work to build
up a big picture. we want to be able to capture problem state, suggest
relevant papers, perform proofs in the background, do speculative 
computations for possible suggestions, pre-generate literate pamphlets
with references and code, etc. we want to draw a wide range of tools
together (math language, graphics, 3D models (organic, engineering, etc),
full-text searches, collaborative tools, etc).


related to the current suggestions i think we are limiting ourselves too
much and creating too tight a straight-jacket by trying to work within
the limits of current browsers and MMA-like worksheets.

choose a browser, get the source, add it to axiom, and extend it in various
ways so we can experiment with ideas. just making it possible for the browser
to read/write the filesystem and present a "canvas" area to axiom puts us
far ahead of the world. it's not ideal but it works.

\start
Date: Mon, 20 Jun 2005 22:52:58 -0400
From: Bill Page
To: Tim Daly
Subject: RE: axiom, browsers, and crystal
Cc: Kai Kaminski

On June 20, 2005 7:35 PM Tim Daly wrote:

> ...
> some sort of browser-like capabilities are assumed.

Yes, most certainly. As usual, I find I agree with many things
you say below, but disagree strong on some specific points.

> the limitations we have now seems to be things like:
>
> * the syntax of the web page does not have a semantic model
>

I think this is not accurate. I might agree if you said
this differently. For example, I do think that the conventional
document semantics of HTML is too limited for our purposes.
Fortunately there is a lot of very active research going
on right now concerning how extended HTML to be a much
richer language or rather, a set of application-specific
related languages such as MathML, SVG, RDF and many more.

> we're trying to build a research science platform, not a
> display GUI object. we'd like the GUI piece of the system to
> have a clean, programmable semantics so we can reason about
> user actions. we want to reflect user actions (say handwriting,
> gestures, clicks, eye-gazes) and system state (say branch cut
> crossings, solid model data structure stresses, hill climbing
> search progress, as subtle changes to the screen.

I don't think any of these requirements are significantly
different than any other sophisticated web-based application
being built today. In fact I think all of them have already
been used to greater or lesser degree. The problem here, I think,
is just that none of these "virtual reality type" of user
interfaces have ever approached the degree of standardization
that would make web franchising feasible. I mean: not enough
people and projects have bought-in to any one such approach.

> ...
> *  the DOM model is hierarchical
>
> the DOM is a Document Object Model. it's basically a hierarchical
> data structure and it suffers from the same problems that databases
> used to suffer, that is, they are hierarchy.

I hierarchical data structure is obviously appropriate if the object
you wish to model is hierarchical. Right?

> Hierarchical databases ruled the day until new theory came around
> and the world went relational (I know most of you don't remember
> it but there was a HUGE fight about this. I attended a committee
> meeting about this at a database conference and the major objection
> was there would never be enough horsepower or memory to handle
> relational searches... beware the future).

Actually, I was probably at that same meeting. :) Funny that
you should mention this example, because I think that,
in reverse, it actually demonstrates your point and also
lets me make a point I want to make.

The relational data model actually had *less* semantics than
many of the data base systems that were in common use at that
time - both hierarchical and network. In this respect it was
rather like XML today compared to early HTML and SGML. The
compromise was less semantics for greater generality and
mathematical rigour. At the time no one knew how to deal in a
general and rigorous way with data structures more complex
than relations. The lack of semantics is what made people worry
that implementing such general operations would require too
much horsepower, and for a while this was true. It is still
very hard for a purely relational system to match the
performance of a hierarchical database for something that
is naturally hierarchical, for example something like a book
or document.

But here we have examples of two strange principles at
work: 1) less is more, i.e. that lack of semantics is
a good thing if what you want to do is generalize and
formalize something. And 2) worse is better. The fact that
the relational model of data is now very widely accepted
is a good thing in spite of the fact that it is worse at
representing many important data objects.

When we are thinking about a browser for the future
Axiom, I think we need to keep these principles in mind.

> ...
> *  the browser cannot interact with the filesystem
> *  the browser pages cannot be drawn upon
> *  the browser pages are "paper-like"
>
> the browser is a dumb tool at the moment. we need to
> break out of the mold, pick a particular browser, and make
> our own version of it. our version can be modified to do
> read/write of the file system, handle socket connections,
> present tabbed pages or sub-areas as an active canvas so
> Axiom can write graphics or text to them in real time,
> present a section of the screen as command-line I/O, show
> axiom state in special tabs, allow the browser to start
> axiom, let it speak lisp, etc.

Here is one place that I disagree strongly... :)

If there is one lesson that is really clear to me about open
source and the Internet in general, it is that doing really
big things requires collaboration, not cooperation (cooperation
in the sense of the verb to co-opt). By that I mean we have to
learn to depend on and take advantage of the work of others
(other projects) rather than attempt to acquire and control
them.

I think this is a really hard lesson for a traditional programmer
to learn. I always used to hate learning to use someone else's
subroutine library since they never seemed to "think the way
I did". And often there were good reasons related to efficiency,
correctness, and trust that justified this view. But for me
open source, the Internet and very rapidly increasing and
affordable computer power has completely changed my views
about this.

> in short, we need to stop struggling with the limits of
> current browser technology, take a standard browser and
> extend it to our purposes. in fact, i expect we could do
> what we do with GCL: package our own version from a tgz file
> and add patches to do what axiom needs.

No, no, no!

Other people much smarter and more dedicated than us are
already doing almost everything of this sort that we need.
What we need to do is exactly the opposite. We need to learn
to incorporate and utilize the features and extensions of
current and future generations of browser technology. Axiom's
requirements (along with many other sophisticated browser
based applications) can help to influence the evolution of
browser technology but it should *not* attempt to co-opt and
control it.

This is a matter of design philosophy. Standards are a
very important part of that philosophy. This is one of
the reasons that worse (at least less than ideal) is often
better in the long run.

> in the 30 year horizon we need something that is useful,
> impressive, and reasonably modern. today's tools just hint
> at what will be common. we need to listen to the hints,
> anticipate the needs, and get out in front.

Again, I find myself wanting to label this as "inappropriate
behaviour" for the Internet and open source. What you are
describing fits quite well with the old corporate model
was largely defined by IBM and then taken to the extreme
by Microsoft, but not with where IBM is today and not with
the open source movement.

> we need to think about the researcher's problem space in
> a much deeper form than current systems do (including Axiom).
> in the long term we want to be at the center of the tool
> set that researchers use to solve problems.

To blend another metaphor (anyone remember Carlos Castaneda?)
I think a much better attitude more or less in keeping with
today's "extreme programming" is the "warrior's attitude".
By design we should try to make Axiom flexible and adaptable
and able to take advantage of new browser technology as it
becomes available, even though today we don't know exactly
what that might be. Again, *standards* are one of the best
ways to try to achieve that.

If we can do this I think we might have a good chance of
being at least one of the players in the center of the tool
set. I think proprietary systems will have a much harder
time being and staying in this position.

> research is long-term, detail-tedious, and takes a lot
> of work to build up a big picture. we want to be able to
> capture problem state, suggest relevant papers, perform
> proofs in the background, do speculative computations for
> possible suggestions, pre-generate literate pamphlets with
> references and code, etc. we want to draw a wide range of
> tools together (math language, graphics, 3D models
> (organic, engineering, etc), full-text searches,
> collaborative tools, etc).

Yes about this I agree completely. And from my point of
view this is almost exactly the same goal of much of the
leading edge research and development on the web today.

> related to the current suggestions i think we are limiting
> ourselves too much and creating too tight a straight-jacket
> by trying to work within the limits of current browsers and
> MMA-like worksheets.

I agree that we have to push those limits, but I think we
are in a very good position to do that from within the
environment of open source and advanced web application
development in general.

> choose a browser, get the source, add it to axiom, and
> extend it in various ways so we can experiment with ideas.

Again: no, no, no. :)

> just making it possible for the browser to read/write the
> filesystem and present a "canvas" area to axiom puts us
> far ahead of the world. it's not ideal but it works.

But here: yes, yes, yes!

"it's not ideal but it works." is exactly how I want to
characterize the choice of using standard web browsers
on which to base the new (and future) Axiom user interface.

-------

Thanks for your message and thanks for opening this debate,
Tim. Although we often both agree and disagree on many
serious points, I am glad that we have been able to continue
to work together on Axiom and I fully expect this arrangement
to continue. So I know you wont and I don't want others
to think these points of disagreement are a bad thing.
I hope other people will feel free to share their opinions
and reasoning.

\start
Date: Mon, 20 Jun 2005 20:55:44 -0700
From: Bob McElrath
To: Tim Daly
Subject: Re: axiom, browsers, and crystal
Cc: Martin Rubey, Kai Kaminski, Camm Maguire

Tim Daly [Tim Daly] wrote:
> *  the DOM model is not really math-aware

It doesn't have to be.  All it needs to have is nodes that contain
expressions, figures, or input.  It is totally appropriate to
encapsulate these.  The DOM is for the presentation end, not
calculation.

> *  the browser cannot interact with the filesystem

This is not true.  (Did you try the save button on tiddlywiki?)  Mozilla
will complain about security, but you can tell mozilla to allow it to do
so.  Technically tiddly uses XUL for mozilla and ActiveX under IE.

> *  the browser pages cannot be drawn upon

You mean like this? http://chat.ma.la/draw.html

> *  the browser pages are "paper-like"

I think this is more a reflection of people's thought patterns than the
ability of the technology.  Being able to address and modify the
document in response to user requests is hardly "paper-like".

In particular, I like the ability of DOM to address and modify MathML
elements...

> the browser is a dumb tool at the moment. we need to break out of the
> mold, pick a particular browser, and make our own version of it.

I don't think we should make our own version, but I think we should
standardize on Mozilla, which is available under similar licenses to
Axiom.

> our version can be modified to do read/write of the file system, 

Already available.

> handle socket connections, 

Already available (AJAX).

> present tabbed pages or sub-areas as an active
> canvas so Axiom can write graphics or text to them in real time, 

Remember all interaction is by user request.  Never should the server
need to spontaneously put something on the user's screen.

> present a section of the screen as command-line I/O, 

Demonstrated by Kai to be possible already.

> show axiom state in special tabs, 

If axiom binds to ports no localhost, one page could show internal state.

> allow the browser to start axiom,

Either make a startup script that starts axiom then the web browser, or
possibly one of File.execute or Install.execute in the XPInstall object.

> let it speak lisp, 

I don't think this is necessary, except by interaction with axiom.

> etc.

I'm sorry, I meant to have a working demo before I brought this up
again.  From my perspective, everything is possible, it's just a matter
of finding time to paste it all together...

I'm not sure this discussion is useful, what we need is code... ;)

\start
Date: Mon, 20 Jun 2005 22:47:43 -0500
From: Tim Daly
To: Bill Page
Subject: axiom, browsers, and crystal

we're debating, not disagreeing. although you're clearly wrong :-)

i agree standards are a *good thing*(TM) but standards come after practice,
not before. when they come before practice they are generally large,
expensive, and overbuilt (e.g. XML)

i agree that browsers are a good thing. they are platform independent,
use standards, and allow marvelous things to happen. or not. in particular
they explicitly do not allow themselves to be used as a useful front-end
for local programs.

i agree that we don't want to re-invent the world and that we want to
follow standard practice. However i disagree that we should work solely
within standards.

what i see us doing is using cheesey work-around languages like javascript
and badly designed data structures like DOM. we're going to end up with
  (a) a program that is "more of the same"
  (b) is in a hard to maintain language that isn't very portable
  (c) hamstrung by the standard-per-browser problem
  (d) encoding our information in latex -> XML -> javascript hacks
  (e) unable to "really communicate" with the user thru the browser
  (f) bending the world to fit the doorway
  (g) unable to start local programs, save state, really interact

think about what we want. we want a portable front-end to axiom that
we can extend in various ways to do truly cool NEW things. we want the
end user of axiom (the spad programmer) to be able to make the front-end
do truly cool NEW things. we want our documentation (pamphlets) to be magic
drag-and-drop, clip and execute, inline moving graphics, managing multiple
programs like axiom, our graphics, ACL2, and other tools. We want to be
able to save state back into a representation that axiom and the front-end
can both use.

current browser technology won't allow us to "extend" it in various ways
(such as making one of the tabs be an axiom shell session). it won't 
read and write pamphlet files (inline latex, inline chunks). it won't
allow drag-and-drop of pamphlets. it can't start or manage local programs.
it can't handle giving up screen real estate as canvas areas. it can't
write to the file system, etc.

yes, you can do some of those tricks with acres of javascript, special
certificates, plugins, cookies, and other hacks. but think of all of
the code you have to write in javascript, html, xml, C, etc. it will
only get MUCH worse as you try to write javascript to read the semantic
network problem data structure and render the appropriate html. javascript
is a horrible language and we have two great languages (spad and lisp).

i'd agree with your approach if we could do something like graph the
algebra hierarchy without a ton of java and a plugin or draw a graph
on a tab from lisp. 

i can almost envision the C code necessary to start axiom (or some other
program) from the browser, hand it the screen area of a tabbed pane, and
present an API from the browser code to draw. if it is 1000 lines i'd
be astonished. all the cross-platform work is already done.

use the browser, keep the standards. but extend the tool to do what you want.
i don't change GCL, i simply extend it to be useful. 
i don't change noweb. i simply add functionality i need.
we won't change the browser, we just need to extend it to be useful.

think of the browser as having solved the cross-platform problem and as
a large library of useful code. now we want to make it sing and dance
to our new ways of thinking. we still do what a browser does (we have
the same base code) but we do so much more.

\start
Date: Mon, 20 Jun 2005 20:38:23 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Tim Daly
Subject: re: axiom, browsers, and crystal
Cc: Kai Kaminski

--- Bill Page wrote:

> On June 20, 2005 7:35 PM Tim Daly wrote:
>
> > we're trying to build a research science platform, not a
> > display GUI object. we'd like the GUI piece of the system to
> > have a clean, programmable semantics so we can reason about
> > user actions. we want to reflect user actions (say handwriting,
> > gestures, clicks, eye-gazes) and system state (say branch cut
> > crossings, solid model data structure stresses, hill climbing
> > search progress, as subtle changes to the screen.
> 
> I don't think any of these requirements are significantly
> different than any other sophisticated web-based application
> being built today. In fact I think all of them have already
> been used to greater or lesser degree. The problem here, I think,
> is just that none of these "virtual reality type" of user
> interfaces have ever approached the degree of standardization
> that would make web franchising feasible. I mean: not enough
> people and projects have bought-in to any one such approach.
 
If I may jump in, I'm not clear why there is so much focus on "web" if
by that you mean "world wide web."  My approach to this sort of thing
is to create the ability to visualize what you want to visualize, and
then look to any advantages that might be obtainable from a "networked"
approach.  A big selling point for me on an interface is that any
"networked" or "web aware" parts are nice features, but NOT integral to
the core functionality.  (Not strictly relevant, but an example would
be the CUPS habit of using a custom web server and configuring one's
printers in a web browser.  This has never felt "robust" to me.  It
could be a bias of terminology - to me a "web browser" is something I
use to go look up information on the internet, and therefore by
definition not to be trusted for mission-critical work - I don't want
to have to rely on the "network" working.  Too much openness to the net
is also a security nightmare - I think this is something Maxima might
have to look at some day due to our use of sockets and servers.)  I
prefer to lean towards "stand alone with some helpful web features"
rather than "web browser as GUI."  Maybe I'm just being a grumpy old
stick in the mud.  I suppose a web browser being a GUI on a local
machine could more properly be called a GUI implimentation platform,
but I can't help the feeling of too many layers being piled on one
another.

[snip]

> But here we have examples of two strange principles at
> work: 1) less is more, i.e. that lack of semantics is
> a good thing if what you want to do is generalize and
> formalize something. And 2) worse is better. The fact that
> the relational model of data is now very widely accepted
> is a good thing in spite of the fact that it is worse at
> representing many important data objects.

<cringe>.  I have heard the worse is better argument, and I suppose it
may be correct in the end, but I always had the feeling that if
something really could be done right the first time (REALLY done, not
just discussed) it would win out.  (TeX might arguably be an example of
this.)  If I understand correctly worse is better is in essence a
variation of the "first to market" idea, but Axiom (and Maxima for that
matter) don't need to worry about this - Mathematica and Maple are
already first, and have most all of the market share.  We don't have
anything to lose by doing it "right" - doing it "right" puts us in a
better position for the 30 year horizon and beyond.

[snip]

> If there is one lesson that is really clear to me about open
> source and the Internet in general, it is that doing really
> big things requires collaboration, not cooperation (cooperation
> in the sense of the verb to co-opt). By that I mean we have to
> learn to depend on and take advantage of the work of others
> (other projects) rather than attempt to acquire and control
> them.

I suspect (perhaps Tim you agree with me) that there is very little
software on the internet (or even in the commercial world) written to
the standard to which Axiom wants to aspire.  I am assuming when I make
this statement that Axiom would want to document with literate
programming things like graphing algorithms, 3D techniques, data
visualization routines, 2D mathematical display algorithms, etc. in the
same fashion it has and is documenting the more strictly mathematical
parts of the code base.  I am not aware of any formal work done on
plotting algorithms or the formalization of the rules of 2D
mathematical display.  Hopefully that is just me not knowing enough,
and if such work does exist wouldn't Axiom want to incorporate it?  To
me this is Axiom's true merit and uniqueness - the complete, total
obsession with Doing It Right.
 
> > in short, we need to stop struggling with the limits of
> > current browser technology, take a standard browser and
> > extend it to our purposes. in fact, i expect we could do
> > what we do with GCL: package our own version from a tgz file
> > and add patches to do what axiom needs.

Again, I don't understand the focus on browsers.  As a rule what I
think of as a "browser" is almost by definition insufficient for the
general power you're proposing be added Tim.  What you're talking about
would be almost a whole new class of application.  (A very, VERY
powerful one, with networking features to be sure, but not what I tend
to think of as a "browser" ~= "information viewer," not information
editor.

> This is a matter of design philosophy. Standards are a
> very important part of that philosophy. This is one of
> the reasons that worse (at least less than ideal) is often
> better in the long run.

In the computer version of "long run" I agree worse does tend to be
better, but I think the TRUE long term (i.e. hundreds of years) will
tend to favor code which, as much as possible, is written trying for
the ideal.  Computers and computer software are very short lived by the
standards of almost any other product of similar magnitude, and that is
generally a sign of immaturity.  And after all, look at how long COBAL
has hung around - it could be argued that the whole y2k issue was due
to "worse is better" thinking.
 
> > in the 30 year horizon we need something that is useful,
> > impressive, and reasonably modern. today's tools just hint
> > at what will be common. we need to listen to the hints,
> > anticipate the needs, and get out in front.
> 
> Again, I find myself wanting to label this as "inappropriate
> behaviour" for the Internet and open source. What you are
> describing fits quite well with the old corporate model
> was largely defined by IBM and then taken to the extreme
> by Microsoft, but not with where IBM is today and not with
> the open source movement.

Eh?  I'm moderately confused.  I think Tim is saying that we should aim
for what we would want in a tool, not so much thinking about what the
limits of the current tools are.  That I would agree with - why
shouldn't open source lead the way?

> > we need to think about the researcher's problem space in
> > a much deeper form than current systems do (including Axiom).
> > in the long term we want to be at the center of the tool
> > set that researchers use to solve problems.
> 
> To blend another metaphor (anyone remember Carlos Castaneda?)
> I think a much better attitude more or less in keeping with
> today's "extreme programming" is the "warrior's attitude".
> By design we should try to make Axiom flexible and adaptable
> and able to take advantage of new browser technology as it
> becomes available, even though today we don't know exactly
> what that might be. Again, *standards* are one of the best
> ways to try to achieve that.

Wouldn't a robust design be flexible and adaptable by definition? 
Supporting standards is a good idea, but one shouldn't be afraid to
move beyond them either - that's where new, better standards come from.

> > related to the current suggestions i think we are limiting
> > ourselves too much and creating too tight a straight-jacket
> > by trying to work within the limits of current browsers and
> > MMA-like worksheets.

Um.  Not sure I agree with MMA-like worksheets being a limit - I prefer
to think of them as a starting point.  They do some things that are
very good (2D input and output) and some things I'm not so crazy about
(their syntax I don't care for at all.)  But I tend to think of a
"mathematical document" as a paper sized canvas which will accept
arbitrary visualizations and representations, even if MMA doesn't have
that level of flexibility.  Structure is needed in mathematical display
in some form or fashion, and I would tend to think of anything that
offers that (and can preferably be printed to hard copy) as a
mathematical document.
 
> I agree that we have to push those limits, but I think we
> are in a very good position to do that from within the
> environment of open source and advanced web application
> development in general.

Well, as usual, real products DO win out over vapor.  Someday I hope a
powerful McCLIM based environment is no longer vapor, but that is for
the future :-/.

\start
Date: Mon, 20 Jun 2005 23:17:02 -0500
From: Tim Daly
To: Bob McElrath
Subject: axiom, browsers, and crystal

i'm currently working on making the ISSAC Proceeding CD so i can't 
check out your references at the moment but i will as soon as i can.

i did want to respond to your comment that you didn't think discussion
was useful and that we need running code....

i think the focus on running code is great and i'm a great believer
in "making it work" but in this case i'm trying to raise the discussion
and our eyesight toward the 30 year horizon. 

i am trying to avoid 1.2 million lines of javascript with browser
dependent ifdefs. we already have that problem with C. instead of
trying to work "on top" of the browser, which limits our abilities
to the current available set, i'm trying to think of it as a large 
library of code we can exploit in new ways. and the careful choice
of a lisp available API would make the browser more useful as a
front end and be less maintenance in the long run.

we want to do everything the browser does (because people use them)
but locally we want to do so much more. restricting ourselves to 
require a network and vanilla browser code severely limits the possible
creative choices.

i want people to see axiom do things and get excited about doing more.
so far there is very little i've seen "on the net" that gives me that feel.
i want what i call the "knoppix" reaction.... klaus knopper modified a
standard distribution, made it bootable, and as a result i'm now trying
to build the doyen project. 

anyway, we need to think about the 30 year horizon and what we want when
get there. thus, the discussion.


back to the grind...

\start
Date: Mon, 20 Jun 2005 21:40:36 -0700
From: Bob McElrath
To: Tim Daly
Subject: Re: axiom, browsers, and crystal

Tim Daly [Tim Daly] wrote:
> i am trying to avoid 1.2 million lines of javascript with browser
> dependent ifdefs. we already have that problem with C. instead of
> trying to work "on top" of the browser, which limits our abilities
> to the current available set, i'm trying to think of it as a large 
> library of code we can exploit in new ways. and the careful choice
> of a lisp available API would make the browser more useful as a
> front end and be less maintenance in the long run.

No browser-dependent code.  Pick a browser.  Sorry folks, no
IE/Opera/Safari.  Mozilla is free and people who want to use Axiom will
have to install it.

> we want to do everything the browser does (because people use them)
> but locally we want to do so much more. restricting ourselves to 
> require a network and vanilla browser code severely limits the possible
> creative choices.

Not vanilla.  I don't want to have anything to do with browser detection
or making it work in more than one browser.

The ability to independently address parts of the document is very
powerful.  In essence, the browser provides interaction with output math
for us.  We can attach javascript to MathML and know which element the
user clicked on after he clicked the "simplify" button.  We can have a
"show integers" button that will turn the variable "i" red.  We can
"hide output".  We can have mouse-overs indicate the domain of the
object under the mouse cursor.

All of the important user-interaction fundamentals are there.  The
entire mozilla API is accessible from javascript.  Output rendering is
there (jsMath or MathML).  Input editing is there.  Documentation in the
form of hyperlinks and mouse-overs is there.

It seems to me that the options are:
1) Build the math into the browser
2) Build the browser into the math

If a new C++ application is created which embeds the necessary mozilla
components, it will still require javascript ties to user interface
elements.  One step at a time... ;)

\start
Date: Tue, 21 Jun 2005 05:55:23 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#176 Factored Polynomials aren't differentiated correctly] Fix

It intends to use the formula 

$$\frac{d}{dx} f(x)) = \sum_{i=1}^n \frac{f(x)}{f_i(x)}\frac{d}{dx}f_i(x)$$

where

$$f(x)=\prod_{i=1}^n f_i(x).$$

Therefore, the fix is to leave away the 'fr'::

    differentiate(u:%, deriv: R -> R) ==
      ans := deriv(unit u) * ((u exquo unit(u)::%)::%)
      ans + (_+/[fact.xpnt * deriv(fact.fctr) *
       ((u exquo nilFactor(fact.fctr, 1))::%) for fact in factorList u])

\start
Date: Tue, 21 Jun 2005 05:45:05 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#176 Factored Polynomials aren't differentiated correctly] Fix

The mistake is in differentiate\$FR which currently reads::

    differentiate(u:%, deriv: R -> R) ==
      ans := deriv(unit u) * ((u exquo (fr := unit(u)::%))::%)
      ans + fr * (_+/[fact.xpnt * deriv(fact.fctr) *
       ((u exquo nilFactor(fact.fctr, 1))::%) for fact in factorList u])

\start
Date: Tue, 21 Jun 2005 12:45:42 +0200
From: Marcus Better
To: Tim Daly
Subject: Re: [Axiom-math] axiom, browsers, and crystal

> current browser technology won't allow us to "extend" it in various ways
> (such as making one of the tabs be an axiom shell session). it won't 
> read and write pamphlet files (inline latex, inline chunks). it won't
> allow drag-and-drop of pamphlets. it can't start or manage local programs.

Couldn't this be done within a desktop system like KDE or Gnome? These
desktops can be extended in various ways using IPC protocols and
component architectures like DCOP. Admittedly it is not (yet) portable
across desktop systems.

\start
Date: Tue, 21 Jun 2005 21:43:14 +0200
From: Gregory Vanuxem
To: list
Subject: Memory leak in Axiom

Hi,


It seems that there is a memory leak in Axiom;

Open a shell, type 'top' and observe residual and virtual memory.

Open AXIOMsys
and type 

 new(1000,1000,0.0)$Matrix(SF);

and repeat this action.


A (1000,1000) C double float array takes 7.63 Mb.

If I alloc a contiguous storage memory array of 1000x1000,
amount of virtual and residual memory augment of 10Mb. It seems
it is never released.

I haven't found this in gcl.

\start
Date: Tue, 21 Jun 2005 14:05:11 -0700
From: Bob McElrath
To: Kai Kaminski, Martin Rubey,	Bill Page, Camm Maguire
Subject: Re: More AxiomUI

Kai Oliver Kaminski [Kai Kaminski] wrote:
> What kind of dependency tracking would you need? Just within a single 
> page? For multiple pages? Send me use cases, tell me what you need.

I've been thinking about this a lot lately.

Mathematica seems to keep an array of input and output.  (In[] and
Out[]).  If we treat these as simple variables, dependency tracking
would be as simple as keeping a linked list among variables.  (e.g.
a "has" or "indeterminants" function)  In addition to that each variable
would need a "modified" flag.  Any time a "modified" flag is toggled,
axiom could traverse the dependency tree and mark outputs with a
"recompute" flag.

For example:

    (1) -> integrate(x+y^2*z, x)

               2    1  2
       (1)  x y z + - x
                    2
                                                Type: Polynomial Fraction Integer
Here (pseudo-code):
    in[1] = {
        value: "integrate(x+y^2*z,x)"
        indets: "y,z"
        modified: false
        recompute: false
    }
    out[1] = {
        value: "x*y^2*z+1/2*x^2"
        indets: in[1]
        modified: false
        recompute: false
    }

    (2) -> y:=3

       (2)  3
                                                            Type: PositiveInteger

Upon executing this, the code would search the dependency tree for
anything with "y" in "indets".  The "recompute" flag for in[1] would be
toggled, followed by the same flag for out[1].  Traversing the tree,
axiom should know to recompute in[1] (which puts its result in out[1]
and changes its recompute flag).  A user interface could choose to
highlight out[1] as needs-recomputing, or just go ahead and do it.
(spreadsheet-style)

\start
Date: Tue, 21 Jun 2005 18:42:27 -0400
From: Bill Page
To: Bob McElrath
Subject: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

On Tuesday, June 21, 2005 5:05 PM Bob McElrath

> Kai Oliver Kaminski [Kai Kaminski] wrote:
>> What kind of dependency tracking would you need? Just within a
>> single page? For multiple pages? Send me use cases, tell me what
>> you need.
>
>I've been thinking about this a lot lately.

Although I have not played with this much but both Tim Daly and
William Sit assure me that the old Axiom Hypertex browser
already implements this kind of dependency tracking. That is
apparently the purpose of the \free{} and \bound{} attributes
embedded the Axiom commands contained in the hypertex pages.

I would prefer to call this something like "lazy re-evaluation".

I think it is notable that neither Maple nor Mathematica have
lazy re-evaluation in their standard worksheet interfaces.
But Maple (and perhaps Mathematica as well) does have a kind
of "spread sheet" worksheet sub-mode that does this in the
context of a tabular array of related commands. There is also
an external interface between Maple and Excel (the Microsoft
spreadsheet) that allows worksheet cells to contain Maple
commands and display their output.

This bring up a related issue: Maybe we should also be thinking
about a similar interface between say OpenOffice spreadsheets
and Axiom? For that matter, why not between OpenOffice documents
in general and Axiom? I think the missing link here might be
the ability to easily display LaTeX math in this environment -
something that is possible given jsMath in a browser. And it
is possible by design using TeXmacs. (BTW, TeXmacs has some
interesting new features and there are some improvements that
could be made to the existing TeXmacs - Axiom interface.)

Unfortunately the authoring of hypertex pages in Axiom is not
an easily accessible user feature, so in spite of having the
possibiliy of lazy re-evaluation, right now it only applies to
hypertex browser pages. It does not really provide this as a
"worksheet" option as such.

> Mathematica seems to keep an array of input and output.
> (In[] and Out[]).  If we treat these as simple variables,
> dependency tracking would be as simple as keeping a linked
> list among variables.  (e.g. a "has" or "indeterminants"
> function)  In addition to that each variable would need a
> "modified" flag.  Any time a "modified" flag is toggled,
> axiom could traverse the dependency tree and mark outputs
> with a "recompute" flag.

Of course Axiom also keeps a list of inputs and has a fairly
sophisticated )history command.

Can \free and \bound names really be determined automatically?
I think it is awkward to require the use to declare them
separately the way it is done now in the hypertex browser.
Perhaps this is possible with the help of some new code in
Axiom itself. Should this be a front-end browser function or
a back-end Axiom function. For example a function in Axiom
might be able to return the list of input history numbers of
those commands that need to be re-executed. These could be
mapped to corresponding output areas in the browser.

> [clip nice example]

> A user interface could choose to highlight out[1] as needs-
> recomputing, or just go ahead and do it. (spreadsheet-style)

I think it would be pretty neat if the browser could do such
highlighting and very useful if with one click you could ask
Axiom to minimally recompute just those comands that need
re-computing. This should be quite easy in principle using the
kind of AJAX techniques that Kai mentioned elsewhere. The hardest
part would be writing the Axiom code that dynamically computes
the dependency tree.

\start
Date: Tue, 21 Jun 2005 19:11:29 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Memory leak in Axiom

On Tuesday, June 21, 2005 3:43 PM Vanuxem Gr=E9gory wrote:

> It seems that there is a memory leak in Axiom;
>
> Open a shell, type 'top' and observe residual and virtual memory.
>
> Open AXIOMsys and type
>
>  new(1000,1000,0.0)$Matrix(SF);
>
> and repeat this action.

I can not reproduce this error using the Windows version
of Axiom 0.1.4. This version of Axiom is based GCL 2.6.5.
On windows I can monitor memory usage with Task Manager,
Performance tab.

What version of Axiom and operating system are you using
for your test? What version of GCL was used to build Axiom?

> A (1000,1000) C double float array takes 7.63 Mb.
>
> If I alloc a contiguous storage memory array of 1000x1000,
> amount of virtual and residual memory augment of 10Mb. It seems
> it is never released.
>
> I haven't found this in gcl.

Could you describe the test you use on GCL? What version of
gcl are you using?

>
> Any idea ?

If you repeat this process several times:

1) Open Axiom
2) Allocate Matrix
3) Close Axiom
4) display residual and virtural memory

For example do this 5 times in a row, do you find that the
total available memory is constantly decreasing?

If this is not that case, but only occurs on the first
iteration, then what you might be seeing is some kind of
executable cacheing being done by the operating system.
(Does linux do that? Some versions of Windows do. I see
such an effect under Windows XP.)

\start
Date: Tue, 21 Jun 2005 17:31:57 -0700
From: Bob McElrath
To: Bill Page, Martin Rubey, Kai Kaminski
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

Page, Bill [Bill Page] wrote:
> Can \free and \bound names really be determined automatically?

It can be done in maple via the indets() command.  I think the
equivalent in MMA is Variables[].

If you have an expression as a tree, one just needs to traverse it and
examine symbols therein.

\start
Date: Wed, 22 Jun 2005 03:09:38 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Memory leak in Axiom

Hi,

> -----Message d'origine-----
> De : Page, Bill [mailto:Bill Page]
> Envoy=E9 : mercredi 22 juin 2005 01:11
> =C0 : 'Vanuxem Gr=E9gory'
> Cc : list
> Objet : RE: Memory leak in Axiom
>
>
> On Tuesday, June 21, 2005 3:43 PM Vanuxem Gr=E9gory wrote:
>
> > It seems that there is a memory leak in Axiom;
> >
> > Open a shell, type 'top' and observe residual and virtual memory.
> >
> > Open AXIOMsys and type
> >
> >  new(1000,1000,0.0)$Matrix(SF);
> >
> > and repeat this action.
>
> I can not reproduce this error using the Windows version
> of Axiom 0.1.4. This version of Axiom is based GCL 2.6.5.
> On windows I can monitor memory usage with Task Manager,
> Performance tab.
>
> What version of Axiom and operating system are you using
> for your test? What version of GCL was used to build Axiom?

GCL-2.6.6 on axiom patch 40

>
> > A (1000,1000) C double float array takes 7.63 Mb.
> >
> > If I alloc a contiguous storage memory array of 1000x1000,
> > amount of virtual and residual memory augment of 10Mb. It seems
> > it is never released.
> >
> > I haven't found this in gcl.
>
> Could you describe the test you use on GCL? What version of
> gcl are you using?

(make-array '(1000 1000) :element-type 'long-float :initial-element 0)

about 50 times

>
> >
> > Any idea ?
>
> If you repeat this process several times:
>

Sorry,
1) Open Axiom
4) display residual and virtural memory
-- avoid printing
new(1000,1000,0)$Matrix(SF);
-- memory has increased of 10Mb
new(1000,1000,0)$Matrix(SF);
-- memory has increased of 10Mb
new(1000,1000,0)$Matrix(SF);
-- memory has increased of 10Mb
new(1000,1000,0)$Matrix(SF);
-- memory has increased of 10Mb
new(1000,1000,0)$Matrix(SF);
-- memory has increased of 10Mb
new(1000,1000,0)$Matrix(SF);
-- memory has increased of 10Mb
new(1000,1000,0)$Matrix(SF);
-- memory has increased of 10Mb
.
.
.
a lot of times (axiom will crash) => xmalloc failed

>
> For example do this 5 times in a row, do you find that the
> total available memory is constantly decreasing?
>
> If this is not that case, but only occurs on the first
> iteration, then what you might be seeing is some kind of
> executable cacheing being done by the operating system.
> (Does linux do that? Some versions of Windows do. I see
> such an effect under Windows XP.)

\start
Date: Wed, 22 Jun 2005 03:09:38 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Memory leak in Axiom

Hi,

> -----Message d'origine-----
> De : Page, Bill [mailto:Bill Page]
> Envoy=E9 : mercredi 22 juin 2005 01:11
> =C0 : 'Vanuxem Gr=E9gory'
> Cc : list
> Objet : RE: Memory leak in Axiom
>
>
> On Tuesday, June 21, 2005 3:43 PM Vanuxem Gr=E9gory wrote:
>
> > It seems that there is a memory leak in Axiom;
> >
> > Open a shell, type 'top' and observe residual and virtual memory.
> >
> > Open AXIOMsys and type
> >
> >  new(1000,1000,0.0)$Matrix(SF);
> >
> > and repeat this action.
>
> I can not reproduce this error using the Windows version
> of Axiom 0.1.4. This version of Axiom is based GCL 2.6.5.
> On windows I can monitor memory usage with Task Manager,
> Performance tab.
>
> What version of Axiom and operating system are you using
> for your test? What version of GCL was used to build Axiom?

GCL-2.6.6 Axiom patch 40 on linux.

>
> > A (1000,1000) C double float array takes 7.63 Mb.
> >
> > If I alloc a contiguous storage memory array of 1000x1000,
> > amount of virtual and residual memory augment of 10Mb. It seems
> > it is never released.
> >
> > I haven't found this in gcl.
>
> Could you describe the test you use on GCL? What version of
> gcl are you using?
>
> >
> > Any idea ?
>
> If you repeat this process several times:
>
> 1) Open Axiom
> 2) Allocate Matrix
> 3) Close Axiom
> 4) display residual and virtural memory

Sorry I do

1) Open Axiom
4) display residual and virtural memory
2) Allocate Matrix


-- use ';' to avoid printing
new(1000,1000,0)$Matrix(SF);
new(1000,1000,0)$Matrix(SF);
new(1000,1000,0)$Matrix(SF);
new(1000,1000,0)$Matrix(SF);
new(1000,1000,0)$Matrix(SF);
new(1000,1000,0)$Matrix(SF);

3) Close Axiom


>
> For example do this 5 times in a row, do you find that the
> total available memory is constantly decreasing?
>
> If this is not that case, but only occurs on the first
> iteration, then what you might be seeing is some kind of
> executable cacheing being done by the operating system.
> (Does linux do that? Some versions of Windows do. I see
> such an effect under Windows XP.)

\start
Date: Tue, 21 Jun 2005 21:49:35 -0400
From: Bill Page
To: Gregoy Vanuxem
Subject: RE: Memory leak in Axiom

I wrote:
> ...
> If you repeat this process several times:
>
> 1) Open Axiom
> 2) Allocate Matrix
> 3) Close Axiom
> 4) display residual and virtural memory
>
> For example do this 5 times in a row, do you find that the
> total available memory is constantly decreasing?
> ...
>
> Could you describe the test you use on GCL? What version of
> gcl are you using?

On Tuesday, June 21, 2005 9:10 PM Vanuxem Gr=E9gory wrote:

> (make-array '(1000 1000) :element-type 'long-float :initial-element =
0)
>
> about 50 times
>

I GCL I am not certain that this function will necessarily allocate
all of the memory that might be required if each element of the
array was explicitly given some value.

> ...
> Sorry,
> 1) Open Axiom
> 4) display residual and virtural memory
> -- avoid printing
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> .
> .
> .
> a lot of times (axiom will crash) => xmalloc failed

Why do say that this sort of test represents a "memory leak"?
If you do not close Axiom between these allocations of memory
you can not be testing for the conditional called a "memory leak".
A memory leak is a serious problem that occurs when a process does
not give back to the operating system some memory that it allocated
when it closes.

It seems quite normal to me that allocating many large arrays
eventually uses up all available virtual memory. It is possible
that Axiom is using a different data structure for representing
a Matrix then the GCL make-array.

\start
Date: Tue, 21 Jun 2005 18:47:00 -0700
From: Bob McElrath
To: Bill Page, Kai Kaminski
Subject: Re: More AxiomUI

Page, Bill [Bill Page] wrote:
> "Suppose we try a naive approach. We could decorate each domain (those
> parts of Axiom which have an internal representation) with a function
> that would return the internal representation recursively expanded
> into a lisp s-expression. We could also give each domain a function
> that takes this s-expression and tries to simplify it. But we run into
> an issue. What would be the return type of such a simplify function?"

The integrate() function seems to work quite well, despite the fact that
I might add two disparate things.

(8) -> integrate(log(x)+x, x)
(8) -> 
                     2
        2x log(x) + x  - 2x
   (8)  -------------------
                 2
                                          Type: Union(Expression Integer,...)

Simplification rules must be domain-specific.  However the domain that
is used in most engineering-type CAS' (maple/mathematica/maxima) is
essentially "Complex Expression".  Is Union(Expression Integer,...)
equivalent?

It's been mentioned before that the "Expression" domain needs a lot of
work.  This talk of simplification probably belongs there.

However if we were very smart we would have domain-specific rules, and a
generic format (such as the s-expression example you mention above), and
*one* set of simplify/factor/expand functions.  The result would be as
it is from integrate(), Union(something) or Expression(something).  The
type should be derivable...

\start
Date: Tue, 21 Jun 2005 21:55:21 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Memory leak in Axiom : mistake

On Tuesday, June 21, 2005 9:38 PM Vanuxem Gr=E9gory wrote:

> Sorry,

Why do you write that you are your sorry???

> Section 0.4.2 of axiom book => accessing earlier result.

Quote:

0.4.2 Accessing Earlier Results

The "%" macro represents the result of the previous computation.
The "%%" macro is available which takes a single integer argument.
If the argument is positive then it refers to the step number of
the calculation where the numbering begins from one and can be
seen at the end of each prompt (the number in parentheses). If
the argument is negative then it refers to previous results counting
backwards from the last result. That is, "%%(-1)" is the same as
"%". The value of "%%(0)" is not defined and will generate an error
if requested.

--------

> It's a little dangerous in term of memory management...

Why do you say this is dangerous? This is only a way to refer
to the result of a previous computation.

\start
Date: Wed, 22 Jun 2005 03:38:25 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Memory leak in Axiom : mistake

Hi,

Sorry,

Section 0.4.2 of axiom book => accessing earlier result.
It's a little dangerous in term of memory management...

> -----Message d'origine-----
> De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
> part de Vanuxem Gr=E9gory
> Envoy=E9 : mercredi 22 juin 2005 03:10
> =C0 : Bill Page (E-mail)
> Cc : list
> Objet : RE: Memory leak in Axiom
>
>
> Hi,
>
> > -----Message d'origine-----
> > De : Page, Bill [mailto:Bill Page]
> > Envoy=E9 : mercredi 22 juin 2005 01:11
> > =C0 : 'Vanuxem Gr=E9gory'
> > Cc : list
> > Objet : RE: Memory leak in Axiom
> >
> >
> > On Tuesday, June 21, 2005 3:43 PM Vanuxem Gr=E9gory wrote:
> >
> > > It seems that there is a memory leak in Axiom;
> > >
> > > Open a shell, type 'top' and observe residual and virtual memory.
> > >
> > > Open AXIOMsys and type
> > >
> > >  new(1000,1000,0.0)$Matrix(SF);
> > >
> > > and repeat this action.
> >
> > I can not reproduce this error using the Windows version
> > of Axiom 0.1.4. This version of Axiom is based GCL 2.6.5.
> > On windows I can monitor memory usage with Task Manager,
> > Performance tab.
> >
> > What version of Axiom and operating system are you using
> > for your test? What version of GCL was used to build Axiom?
>
> GCL-2.6.6 on axiom patch 40
>
> >
> > > A (1000,1000) C double float array takes 7.63 Mb.
> > >
> > > If I alloc a contiguous storage memory array of 1000x1000,
> > > amount of virtual and residual memory augment of 10Mb. It seems
> > > it is never released.
> > >
> > > I haven't found this in gcl.
> >
> > Could you describe the test you use on GCL? What version of
> > gcl are you using?
>
> (make-array '(1000 1000) :element-type 'long-float :initial-element 0)
>
> about 50 times
>
> >
> > >
> > > Any idea ?
> >
> > If you repeat this process several times:
> >
>
> Sorry,
> 1) Open Axiom
> 4) display residual and virtural memory
> -- avoid printing
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> new(1000,1000,0)$Matrix(SF);
> -- memory has increased of 10Mb
> .
> .
> .
> a lot of times (axiom will crash) => xmalloc failed
>
>
> >
> > For example do this 5 times in a row, do you find that the
> > total available memory is constantly decreasing?
> >
> > If this is not that case, but only occurs on the first
> > iteration, then what you might be seeing is some kind of
> > executable cacheing being done by the operating system.
> > (Does linux do that? Some versions of Windows do. I see
> > such an effect under Windows XP.)

\start
Date: Tue, 21 Jun 2005 21:33:11 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: More AxiomUI
Cc: Bob McElrath

> ...
> Am 20.06.2005 um 22:05 schrieb Bob McElrath:
>> I've also been thinking about the worksheet interface.  One of
>> the main drawbacks I see is the concept of "state".  The server
>> has some state that is different from the worksheet state.
> ...

On Tuesday, June 21, 2005 7:00 AM Kai Oliver Kaminski wrote:
> That's why I proposed to create a GUI backend in Common Lisp.
> The browser is abused as a portable GUI framwork with scripting
> support. Javascript will only offer convenience features like
> nicer input, communication without page reload etc. The heavy
> lifting will be done by the backend. Axiom's output to the
> backend would not be, as some people imagine, geared towards
> presentaion but towards presering the semantics. That way the
> backend can do dependency tracking between different expression
> and automatically update pages or parts of them if necessary.

It is certainly possible to do "dependency tracking" as part of
the "back-end" process separate from Axiom - more or less the
same way it is done in the Axiom hypertex browser now. But why?
It is Axiom's job to understand Axiom command syntax and semantics.
If it isn't already done, it seems to me that the most logical
place to deal with the dependencies between Axiom commands is
in Axiom itself. Axiom already has a powerful )history command.
It is the state of Axiom's objects compared to the state of the
browser display that we are worrying about. Adding a layer in
between just seems to make this more complex.

Since Axiom is a very high level language allowing functions as
first order objects etc, doing this reliably and automatically
outside of Axiom seems very difficult to me. Having to mark each
variable as either \bound or \free in each command (as in the
current hypertex browser) seems very awkward. Therefore I think
what we need is function within Axiom that the browser interface
can call which will list those Axiom commands which depend on any
Axiom objects that we have just re-defined.

>> What if I could select the result of an expression and click on
>> "simlify" or "combine these terms".  The interface could insert
>> the relevant commands in the same execution block as I just ran,
>> *without* recomputing that block.  e.g. if I sequentially apply
>> "combine these terms", "factor this", etc.  I should be able to
>> in-place simplify by hand, and *also* have the execution block
>> reflect those operations.
>>
>> For example:
>>
>>> integrate(something complicated, z=0..1)
>>
>>     hideous output
>>
>> When I click on sub-expressions in "hideous output" it would
>> insert the relevant operation such as "simplify(%)" just below
>> "integrate", such that if I re-execute that block it looks the
>> same as it does now.

What Bob describes is much better than what is possible now on
Maple. It is possible in Maple to "click on sub-expressions" and
to paste the corresponding sub-expressions back into Maple as
input but this does not create any permanent "relevant operation".

>>
>> FYI this would never work in Maple, since it uses non-
>> deterministic expression sorting...the first term will not
>> necessarily be the same upon subsequent evaluations, so
>> "simplify(op(1,%)+op(2,%))" will not necessarily be operating
>> on the same terms.  I don't know if Axiom has this same disease...

Actually it is usually possible in Maple to do this using
operations like select() which selects sub expressions based
on their content instead of their "position" like op(). But
that is not really the point.

I think you will find that Axiom has a rather different "disease"
(or maybe it's a mutation with some advantages as well):

For the most part Axiom really does not have any uniform notion
of "sub expression"! For example Tim Daly wrote:

"Axiom does not use a tree representation in general although
particular types might."
http://lists.gnu.org/archive/html/axiom-math/2003-10/msg00039.html

"The issue was how to correctly perform simplification. In particular,
we'd like to raise simplification to a user controlled level rather
than keep it embedded in the interpreter."
http://lists.gnu.org/archive/html/axiom-math/2003-10/msg00040.html

Related: "... the differences between Axiom's approach and a
tree-based approach like in the three Ms." (Dylan Thurston)
http://lists.gnu.org/archive/html/axiom-math/2003-10/msg00035.html

>
> If Axiom is able (after possible modification) to give unique 
> identifiers to the subexpressions this should be possible, if
> tedious to implement.

I think this might be quite hard. The modifications would perhaps
be similar to what Tim described in axiom-math/2003-10/msg00040
above:

"Suppose we try a naive approach. We could decorate each domain (those
parts of Axiom which have an internal representation) with a function
that would return the internal representation recursively expanded
into a lisp s-expression. We could also give each domain a function
that takes this s-expression and tries to simplify it. But we run into
an issue. What would be the return type of such a simplify function?"

\start
Date: Tue, 21 Jun 2005 22:27:00 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: More AxiomUI
Cc: Kai Kaminski

Bob,

On Tuesday, June 21, 2005 9:47 PM you wrote:

> The integrate() function seems to work quite well, despite the fact
> that I might add two disparate things.
>
> (8) -> integrate(log(x)+x, x)
>
>                     2
>        2x log(x) + x  - 2x
>   (8)  -------------------
>                 2
>                              Type: Union(Expression Integer,...)
>
> Simplification rules must be domain-specific.  However the domain
> that is used in most engineering-type CAS' (maple/mathematica/maxima)
> is essentially "Complex Expression".

Yes. As I understand the Expression domain was an attempt to "simulate"
this enginerring-type CAS concept in Axiom.

>  Is Union(Expression Integer,...) equivalent?

No. Union(Expression Integer,...) is just an abbreviation for the full
type of the result. You can ask Axiom for the complete type information
using the fuction `typeOf'

(1) -> integrate(log(x)+x, x)
                     2
        2x log(x) + x  - 2x
   (1)  -------------------
                 2
                            Type: Union(Expression Integer,...)
(2) -> typeOf %

   (2)  Union(Expression Integer,List Expression Integer)
                            Type: Domain

So the result is either of type Expression Integer or a List of
that type. On the other hand

(3) -> integrate(x^2, x)
   Loading C:/Program Files/axiom/mnt/windows/algebra/POLY2.o for
      package PolynomialFunctions2

        1  3
   (3)  - x
        3
                            Type: Polynomial Fraction Integer

> It's been mentioned before that the "Expression" domain needs a
> lot of work.  This talk of simplification probably belongs there.

Yes maybe. I think this is partly a philosophical design issue.
There is a sense in which the Expression domain does not really
conform to Axiom's apparent original design philosophy. The reason
is that as a *mathematical domain* the concept of Expression is
too weak. It represents perhaps a kind of compromise. Should it be
possible in principle to coerce any object in Axiom to something
of type Expression Integer?

In general I still find the Axiom concept of domain and it's
relationship to type rather hard to "grok". Sometimes it seems
to be talking about semantics (in the sense of mathematics)
and sometimes it has more to do with representation and syntax -
like the distinction between Polynomial Integer and Expression
Integer.

> However if we were very smart we would have domain-specific rules,
> and a generic format (such as the s-expression example you mention
> above), and *one* set of simplify/factor/expand functions.  The
> result would be as it is from integrate(), Union(something) or
> Expression(something).  The type should be derivable...

In the case of the above examples, this conversion seems quite
interesting:

(4) -> %%(1)::InputForm

   (4)  (/ (+ (* (* 2 x) (log x)) (+ (** x 2) (* - 2 x))) 2)
                                             Type: InputForm
(5) -> %%(3)::InputForm

   (5)  (* (/ 1 3) (** x 3))
                                             Type: InputForm

But I am not so sure how it could be used to achieve the results
you are looking for. I'll have to think about this some more.

\start
Date: Tue, 21 Jun 2005 22:27:10 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Manipulating Expressions] (new) 

The domain InputForm can be quite useful for manipulating parts
of expressions. For example

\begin{axiom}
ex1:=integrate(log(x)+x, x)
%::InputForm
ex2:=interpret((%::InputForm).2.2)
\end{axiom}

\start
Date: Tue, 21 Jun 2005 22:25:32 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomProblems] 

Changes http://page.axiom-developer.org/zope/mathaction/AxiomProblems/diff
--

++added:
- [Definite Integration]

- [Dynamic Function Domains]::

    functions with signatures like (a,b,B(a))->(C(a,b))

- [efficiency problem]

- "GCD in EXPR":EXPR_GCD

- [indexed variables]

- [List To Matrix]

- [Manipulating Expressions]

- [Mutual Recursion]::

    Odd(0)=false, Odd(n)=Even(n-1)
    Even(0)=true, Even(n)=Odd(n-1)

- [Numerical Integration]

- [numerical linear algebra]

- [Pattern Matching]

- [Piecewise Functions]

- [Polynomial Coefficients]


--removed:
-- [indexed variables]
-
-- an [efficiency problem]
-

??changed:
-- a problem with "GCD in EXPR":EXPR_GCD
-
-- NumericalIntegration
-
-- SymbolicIntegration
-
-- DefiniteIntegration
-
-- DynamicFunctionDomains::
-
-    functions with signatures like (a,b,B(a))->(C(a,b))
-
-- MutualRecursion::
-
-    Odd(0)=false, Odd(n)=Even(n-1)
-    Even(0)=true, Even(n)=Odd(n-1);
-
-- [numerical linear algebra]
-
-[230 more lines...]
- [Symbolic Integration]

\start
Date: Tue, 21 Jun 2005 22:46:27 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Polynomial Coefficients] (new) 

Let's examine a simple case:
\begin{axiom}
Dg :=  [p3 - 3*p2 + 3*p1 - p0,3*p2 - 6*p1 + 3*p0,3*p1 - 3*p0,p0]
\end{axiom}
Now calculate coefficients in two ways:
\begin{axiom}
map(coefficients, Dg::List MPOLY([p0,p1,p2,p3],?))
\end{axiom}
and
\begin{axiom}
map(coefficients, Dg::List MPOLY([p3,p2,p1,p0],?))
\end{axiom}
As you see the list are all reversed, but... they were not padded
with zeros. While in my opinion they should be - we have a given
order of variables, and alone 1 in the last list suggests that this
is a coefficient of p3 while it isn't. It is a coefficient of p0.

According to the Axiom book function 'coefficients' does not
include zeros in the list. Furthermore it does not say explicitly
in what order the coefficients themselves are listed. Remember
that there are also terms of degree higher than 1. In fact the
two multivariate polynomials that you used above are formally
identical
\begin{axiom}
(Dg::List MPOLY([p0,p1,p2,p3],?)=Dg::List MPOLY([p3,p2,p1,p0],?))::Boolean
\end{axiom}

To produce a list of coefficients of the terms of degree 1,
including the zeros and in a specific order, use the function
'coefficient' like this:
\begin{axiom}
[[coefficient(p,x,1) for x in [p0,p1,p2,p3]] for p in Dg]
\end{axiom}

And of course you can use this to produce a matrix.
\begin{axiom}
matrix %
\end{axiom}

\start
Date: Tue, 21 Jun 2005 22:38:38 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [InputForm] (new) 

Over forty domains belong to the category !ConvertibleTo !InputForm.

See section: **6.14** *Making Functions from Objects* in the [Axiom Book]

\begin{axiom}
)show InputForm
\end{axiom}

For example

\begin{axiom}
x^2+2*x+3
%::InputForm
\end{axiom}

\start
Date: Tue, 21 Jun 2005 22:42:20 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Pattern Matching] (new) 

Say, I have
\begin{axiom}
test:=D(sin(z)^2, z)
\end{axiom}

What is the easiest way to see, if the output has sin(z) ?
\begin{axiom}
member?(sin(z),kernels(test))
\end{axiom}

\start
Date: Tue, 21 Jun 2005 23:12:12 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [List To Matrix] (new) 

Assume that I have a 'List', like:
\begin{axiom}
L := [[- 1,3,- 3,1],[3,- 6,3],[- 3,3],[1]]
\end{axiom}
(which is calculated from some earlier expressions).
How can I convert it into a 'SquareMatrix'.
\begin{axiom}
L2:=[concat([L.i.j for j in 1..#L.i],[0 for j in ((#L.i)+1)..reduce(max,map(#,L))]) for i in 1..#L]
\end{axiom}

Namely I want to have a matrix like:
\begin{axiom}
A := matrix L2
\end{axiom}
so that I can do
\begin{axiom}
vp := vector[p0,p1,p2,p3]
\end{axiom}
and
\begin{axiom}
vp * A
\end{axiom}

\start
Date: Tue, 21 Jun 2005 23:18:53 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Piecewise Functions] (new) 

Consider the following function, given in recursive manner:
\begin{axiom}
N0(t|(t<0) or (t>1))==0
N0(t|(t>=0) and (t<=1))==1
N(t,i,0)==N0(t-i)
N(t,i,p|p>0)==(t-i)/p*N(t,i,p-1)+(i+1-t)/p*N(t,i+1,p-1)
\end{axiom}
This is a way to create (uniform) bsplines. Now try to differentiate $N$
\begin{axiom}
D(N(t,0,3),t)
\end{axiom}

Yack!!! This is obviously wrong! $t\mapsto N(t,0,3)$ is $C^2$ continuous
and **is not constant** Despite what Axiom seems to claim here.

\begin{axiom}
N(t,0,3)
\end{axiom}

On the other hand the function is not constant.
See this:
\begin{axiom}
N0(t|(t<0) or (t>1))==0;
N0(t|(t>=0) and (t<=1))==1;
N(t,i,0)==N0(t-i);
N(t,i,p|p>0)==(t-i)/p*N(t,i,p-1)+(i+1-t)/p*N(t,i+1,p-1);
for x in -5..15 repeat output N(x/10,0,3)
\end{axiom}

Drawing the plot (unfortunately not available here) would
show it even more clearly.

But in 'D(N(t,0,3),t)' you are not calling the function N
with numeric parameters. In 'N(t,0,3)' the type of t is
'Variable t'. Ultimately 'N(t,0,3)=0' because of your function
definition 'N0(t|(t<0) or (t>1))==0'. This is '0' because
't>1' is 'true' when 't' is of type 'Variable t'. You can
see why if you use the option ')set message bottomup on' to
see the mode map selection
\begin{axiom}
)set message bottomup on
t>1
\end{axiom}

Axiom interprets both 't' and '1' as being of type 'POLY INT'
and the function '>' is defined by the lexical ordering of the
polynomials.

This result is counter-intuitive, but once you understand why
Axiom gives this result then you will be in a good position to
understand the rest of Axiom's type system!

It is possible to write the function N0 so that it returns the
desired result. See ExampleSolution1.

\start
Date: Wed, 22 Jun 2005 00:35:14 -0400
From: Bill Page
To: Bob McElrath
Subject: Manipulating expressions in Axiom (was: More AxiomUI)
Cc: Kai Kaminski

Bob,

> Am 20.06.2005 um 22:05 schrieb Bob McElrath:
>> ...
>> FYI this would never work in Maple, since it uses non-
>> deterministic expression sorting...the first term will not
>> necessarily be the same upon subsequent evaluations, so
>> "simplify(op(1,%)+op(2,%))" will not necessarily be operating
>> on the same terms.  I don't know if Axiom has this same
>> disease...

I now think that Axiom probably does not have this disease. See:

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

for an example of using InputForm.

Regards,
Bill Page.

On Tuesday, June 21, 2005 10:27 PM I wrote:

> ...
>
> (1) -> integrate(log(x)+x, x)
> (2) -> typeOf %
> (3) -> integrate(x^2, x)
>
> ... this conversion seems quite interesting:
>
> (4) -> %%(1)::InputForm
>
>    (4)  (/ (+ (* (* 2 x) (log x)) (+ (** x 2) (* - 2 x))) 2)
>                                   Type: InputForm
> (5) -> %%(3)::InputForm

>    (5)  (* (/ 1 3) (** x 3))
>                                   Type: InputForm
>
> But I am not so sure how it could be used to achieve the
> results you are looking for. I'll have to think about this
> some more.

\start
Date: Tue, 21 Jun 2005 23:51:42 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [List To Matrix] 

L2:=[concat([L.i.j for j in 1..#L.i],[0 for j in ((#L.i)+1)..#L]) for i in 1..#L]

\start
Date: Wed, 22 Jun 2005 01:45:59 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: More AxiomUI
Cc: Kai Kaminski

Martin,

As you know, on MathAction we can write a pseudo-environment

\begin{axiom}
guess([1,1+q,1+q+q^2])
$GUESS(n,FRAC POLY INT,i+->q^i,FRAC POLY INT, EXPR INT, i+->i, i+->i)
\end{axiom}

to achieve the kind of output you describe below.

It would not be difficult at all to achieve this same result with
Axiom documentation written in pamphlet format. The command

  $ noweave guess.pamphlet

just creates the LaTeX output from the pamphlet file. This file can
contain the same Axiom pseudo-environments as on MathAction. But
before it can be processed by the latex command it would first have
to be pre-processed by Axiom to convert the \begin{axiom} sections
to actual latex. The process would be like this:

  $ noweave example.pamphlet > example.axiom
  $ runaxiom < example.axiom > example.tex
  $ latex example.tex

This could be make part of the existing `document' script.

Your example file would then look like this:

% ------------------------ example.pamphlet -------------------------

The exported function takes a list of elements of [[F]] and returns a
list of expressions over [[R]] that seem to fit the data. For example,

<<inputfile>>=
guess([1,1+q,1+q+q^2])
$GUESS(n,FRAC POLY INT,i+->q^i,FRAC POLY INT, EXPR INT, i+->i, i+->i)
@

returns

\begin{axiom}
<<inputfile>>
\end{axiom}

% ---------------------------end of example --------------------------

If this is really of interest to you, I can provide the `runaxiom'
script based on a simplified version of the Python code that we
use on MathAction.

Having it "compare Axiom's output with a given result and raise a
warning if the two differ" is certainly possible. This is often
called regression testing. Tim Daly has discussed it several times
before on this list (see CATS computer algebra test suite). There
already some provision for this in the current Axiom makefiles but
it is not yet fully functional.

Implementing this properly still requires a bit more design of how
to document the expected results and how to perform the comparison.
For example: should the comparison be based on the LaTeX generated
or just on text output? Is a simple `diff' of the output and expected
result adequate?

Regards,
Bill Page.

On Tuesday, June 21, 2005 5:39 AM you wrote:

> ...
> I think that the pamphlet file syntax we currently have is not too
> bad (as "external representation"), but I wouldn't mind if it were
> replaced by something else.
>
> One thing I dislike about it is the following: Currently I have to
> write:
>
> % --------------------------------- example -------------------------
>
> The exported function takes a list of elements of [[F]] and returns a
> list of expressions over [[R]] that seem to fit the data. For example,
>
> <<inputfile>>=
> guess([1,1+q,1+q+q^2])
> $GUESS(n,FRAC POLY INT,i+->q^i,FRAC POLY INT, EXPR INT, i+->i, i+->i)
> @
>
> returns
>
> [[      n 
>       q  - 1
> (1)  [------]                                      
>        q - 1                                       
>             Type: List Expression Integer 
>]]
>
> % ---------------------------end of example --------------------------
>
> However, I'd really like to have axiom compute the result. The best
> thing would be, if axiom computes the result and, if present, it
> compares it with the given result and raises a warning if the two differ.

\start
Date: Wed, 22 Jun 2005 02:33:26 -0400
From: Bill Page
To: Tim Daly
Subject: RE: axiom, browsers, and crystal

On Tuesday, June 21, 2005 12:17 AM Tim Daly wrote:

> i am trying to avoid 1.2 million lines of javascript with browser
> dependent ifdefs.  we already have that problem with C.

I agree. For desktop use we can easily standardize on one browser.
I recommend Mozilla's FireFox. Except for jsMath which is provided
by another project, I don't expect a browser-based interface to
Axiom to require more than a few hunderd lines of JavaScript.

> instead of trying to work "on top" of the browser, which limits our
> abilities to the current available set, i'm trying to think of it
> as a large library of code we can exploit in new ways.

Because of the DOM api and extensions, it is possible to work with
the browser "as a large library of code" without having to get
inside.

> and the careful choice of a lisp available API would make the
> browser more useful as a front end and be less maintenance in
> the long run.

As pointed out in another email, it is possible that a lisp API
for the Mozilla browser will be implemented by other developers.
If it exists we could in principle use it instead of JavaScript.
I would expect it to be some time before it was a stable as the
current JavaScript API.

> we want to do everything the browser does (because people use
> them) but locally we want to do so much more. restricting ourselves
> to require a network and vanilla browser code severely limits the
> possible creative choices.

For desktop use no network is required.

I would not characterize Mozilla as simply a "vanilla browser". It
has a lot of provisions for plug-ins and extensions.

For access to a Doyen-like server over the web, I think we may
have to be more flexible with the choice of browser.

\start
Date: Wed, 22 Jun 2005 01:11:41 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Manipulating Expressions] 

If you would like to do this with a more common type of
expression and hide the details, you can define
\begin{axiom}
op(n,x) == interpret((x::InputForm).(n+1))
\end{axiom}

Then manipulating expressions looks like this:
\begin{axiom}
op(1,op(1,ex1))
(op(1,op(1,ex1))-op(2,op(1,ex1)))/op(2,ex1)

\start
Date: Wed, 22 Jun 2005 01:51:15 -0500
From: Tim Daly
To: Bill Page, Kai Kaminski
Subject: dependency tracking and back-end state

axiom has the ability to maintain independent multiple stateful sessions 
at the same time. i'm buried at the moment but we can talk about it later.

\start
Date: Wed, 22 Jun 2005 03:22:01 -0400
From: Bill Page
To: Tim Daly
Subject: RE: axiom, browsers, and crystal

On Monday, June 20, 2005 11:48 PM Tim Daly wrote:

> i agree standards are a *good thing*(TM) but standards come
> after practice, not before.

On the contrary, many standards have value even though they
may never be put into practice. Standards (should) drive design.
But standards are meant to be broken (and then fixed, again
and again).

> when they come before practice they are generally large,
> expensive, and overbuilt (e.g. XML)

In what sense do you think XML is expensive or overbuilt? The
syntax of XML consists of just three production rules.

  xml :== tag [ xml | value ] /tag
  tag :== <name [att]>
  att := name=value

where [ ] means optional and | means alternative. The rest is just
semantics and that gets complicated no matter what language you
choose.

> i agree that browsers are a good thing. they are platform
> independent, use standards, and allow marvelous things to happen.
> or not. in particular they explicitly do not allow themselves to
> be used as a useful front-end for local programs.

Have you used a Linux desktop lately? If you have, chances are you
have probably already used a browser as a front-end for local
programs and not even known it. Web browser front-ends are also
becoming very popular for embedded applications like network routers,
printer configuration. One of the most popular web browser front-ends

http://www.webmin.com

provides a complete system management interface for Linux servers.

> ...

think about what we want. we want a portable front-end to axiom
that we can extend in various ways to do truly cool NEW things.

Agreed.

> we want the end user of axiom (the spad programmer) to be able
> to make the front-end do truly cool NEW things.

I am not sure that "spad programmer" is a good description of
the Axiom end user since I expect many people will use Axiom
without programming in spad. But I agree that the gui front-end
needs to be easily accessible to the more ambitious Axiom
programmer.

> we want our documentation (pamphlets) to be magic drag-and-drop,
> clip and execute, inline moving graphics, managing multiple
> programs like axiom, our graphics, ACL2, and other tools.

Agreed.

> We want to be able to save state back into a representation
> that axiom and the front-end can both use.

I think the separation between the front-end state and axiom
state is undesirable. State is something that Axiom should
manage. The front-end just needs to be able to render that
state accurately in a variety of visual/audio/tactile ways.

> ...
> yes, you can do some of those tricks with acres of javascript,
> special certificates, plugins, cookies, and other hacks. but
> think of all of the code you have to write in javascript, html,
> xml, C, etc. it will only get MUCH worse as you try to write
> javascript to read the semantic network problem data structure
> and render the appropriate html.

Tim, I really think you are just "fear mongering"! In fact most
of the things you mention are already possible in a browser
like Mozilla very little or no any additional JavaScript coding.
JavaScript is mostly required just to provide the glue.

> javascript is a horrible language and we have two great languages
> (spad and lisp).

I am not at all fond of Java in general. JavaScript is just a
dialect of Java specialized for the browser API. I don't think
that it is any worse than Java in general. And Java has been
touted as a kind of "lisp for C programmers"... well, I wouldn't
have exactly said that, but it can't be that bad given the effort
spent on it's development and the amount of open source code that
is available in java.

> i'd agree with your approach if we could do something like graph
> the algebra hierarchy without a ton of java and a plugin or draw 
> a graph on a tab from lisp. 

Well, as you know TouchGraph (a Java application integrated with
the MathAction website) can already do a credible job of graphing
and navigating a complex network.

Kai has demonstrated that drawing a graph using SVG on a browser
can be done with a few hundred lines of GCL lisp code.

> ...

Sigh. The debate wears thin ... :)

\start
Date: Wed, 22 Jun 2005 02:56:45 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [Piecewise Functions] 

Yack!!! This is obviously wrong! The map $$t\mapsto N(t,0,3)$$ is $C^2$ continuous
and **is not constant**, despite what Axiom seems to claim here.

\start
Date: Wed, 22 Jun 2005 10:55:35 +0200
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: Re: Memory leak in Axiom : mistake

Well, there is something else. How is Axiom supposed to behave in the
following case? (See axiom--main--1--patch-40/mnt/linux/doc/book.dvi
Section 1.15.1)

--start axiom
top:
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
17381 hemmecke  16   0 44072 8492 3016 S  0.0  1.7   0:00.12 AXIOMsys

a:=new(1000,1000,0.0)$Matrix(SF);
b:=new(1001,1001,0.0)$Matrix(SF);

Now top says
17381 hemmecke  17   0 44116  21m 3060 S  0.0  4.3   0:00.34 AXIOMsys

)undo -2

And top says
17381 hemmecke  16   0 44116  21m 3088 S  0.0  4.3   0:00.34 AXIOMsys

I understand that due to %% and )undo previous results must be cached,
but why doesn't )undo release memory? Do I read the values of the top
command incorrectly?

Ralf

Vanuxem Gr=E9gory wrote:
> Hi,
>
> Sorry,
>
> Section 0.4.2 of axiom book => accessing earlier result.
> It's a little dangerous in term of memory management...

>
>>-----Message d'origine-----
>>De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org

>>part de Vanuxem Gr=E9gory
>>Envoy=E9 : mercredi 22 juin 2005 03:10
>>=C0 : Bill Page (E-mail)
>>Cc : list
>>Objet : RE: Memory leak in Axiom
>>
>>
>>Hi,
>>
>>
>>>-----Message d'origine-----
>>>De : Page, Bill [mailto:Bill Page]
>>>Envoy=E9 : mercredi 22 juin 2005 01:11
>>>=C0 : 'Vanuxem Gr=E9gory'
>>>Cc : list
>>>Objet : RE: Memory leak in Axiom
>>>
>>>
>>>On Tuesday, June 21, 2005 3:43 PM Vanuxem Gr=E9gory wrote:
>>>
>>>
>>>>It seems that there is a memory leak in Axiom;
>>>>
>>>>Open a shell, type 'top' and observe residual and virtual memory.
>>>>
>>>>Open AXIOMsys and type
>>>>
>>>> new(1000,1000,0.0)$Matrix(SF);
>>>>
>>>>and repeat this action.
>>>
>>>I can not reproduce this error using the Windows version
>>>of Axiom 0.1.4. This version of Axiom is based GCL 2.6.5.
>>>On windows I can monitor memory usage with Task Manager,
>>>Performance tab.
>>>
>>>What version of Axiom and operating system are you using
>>>for your test? What version of GCL was used to build Axiom?
>>
>>GCL-2.6.6 on axiom patch 40
>>
>>
>>>>A (1000,1000) C double float array takes 7.63 Mb.
>>>>
>>>>If I alloc a contiguous storage memory array of 1000x1000,
>>>>amount of virtual and residual memory augment of 10Mb. It seems
>>>>it is never released.
>>>>
>>>>I haven't found this in gcl.
>>>
>>>Could you describe the test you use on GCL? What version of
>>>gcl are you using?
>>
>>(make-array '(1000 1000) :element-type 'long-float :initial-element 0)
>>
>>about 50 times
>>
>>
>>>>Any idea ?
>>>
>>>If you repeat this process several times:
>>>
>>
>>Sorry,
>>1) Open Axiom
>>4) display residual and virtural memory
>>-- avoid printing
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>.
>>.
>>.
>>a lot of times (axiom will crash) => xmalloc failed
>>
>>>For example do this 5 times in a row, do you find that the
>>>total available memory is constantly decreasing?
>>>
>>>If this is not that case, but only occurs on the first
>>>iteration, then what you might be seeing is some kind of
>>>executable cacheing being done by the operating system.
>>>(Does linux do that? Some versions of Windows do. I see
>>>such an effect under Windows XP.)

\start
Date: Wed, 22 Jun 2005 10:53:48 +0200
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: Re: Memory leak in Axiom : mistake

Well, there is something else. How is Axiom supposed to behave in the
following case? (See axiom--main--1--patch-40/mnt/linux/doc/book.dvi
Section 1.15.1)

--start axiom
top:
   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
17381 hemmecke  16   0 44072 8492 3016 S  0.0  1.7   0:00.12 AXIOMsys

a:=new(1000,1000,0.0)$Matrix(SF);
b:=new(1001,1001,0.0)$Matrix(SF);

Now top says
17381 hemmecke  17   0 44116  21m 3060 S  0.0  4.3   0:00.34 AXIOMsys

)undo -2

And top says
17381 hemmecke  16   0 44116  21m 3088 S  0.0  4.3   0:00.34 AXIOMsys

I understand that due to %% and )undo previous results must be cached,
but why doesn't )undo release memory? Do I read the values of the top
command incorrectly?

Ralf

Vanuxem Gr=E9gory wrote:
> Hi,
>
> Sorry,
>
> Section 0.4.2 of axiom book => accessing earlier result.
> It's a little dangerous in term of memory management...
>
>>-----Message d'origine-----
>>De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org

>>part de Vanuxem Gr=E9gory
>>Envoy=E9 : mercredi 22 juin 2005 03:10
>>=C0 : Bill Page (E-mail)
>>Cc : list
>>Objet : RE: Memory leak in Axiom
>>
>>
>>Hi,
>>
>>
>>>-----Message d'origine-----
>>>De : Page, Bill [mailto:Bill Page]
>>>Envoy=E9 : mercredi 22 juin 2005 01:11
>>>=C0 : 'Vanuxem Gr=E9gory'
>>>Cc : list
>>>Objet : RE: Memory leak in Axiom
>>>
>>>
>>>On Tuesday, June 21, 2005 3:43 PM Vanuxem Gr=E9gory wrote:
>>>
>>>
>>>>It seems that there is a memory leak in Axiom;
>>>>
>>>>Open a shell, type 'top' and observe residual and virtual memory.
>>>>
>>>>Open AXIOMsys and type
>>>>
>>>> new(1000,1000,0.0)$Matrix(SF);
>>>>
>>>>and repeat this action.
>>>
>>>I can not reproduce this error using the Windows version
>>>of Axiom 0.1.4. This version of Axiom is based GCL 2.6.5.
>>>On windows I can monitor memory usage with Task Manager,
>>>Performance tab.
>>>
>>>What version of Axiom and operating system are you using
>>>for your test? What version of GCL was used to build Axiom?
>>
>>GCL-2.6.6 on axiom patch 40
>>
>>
>>>>A (1000,1000) C double float array takes 7.63 Mb.
>>>>
>>>>If I alloc a contiguous storage memory array of 1000x1000,
>>>>amount of virtual and residual memory augment of 10Mb. It seems
>>>>it is never released.
>>>>
>>>>I haven't found this in gcl.
>>>
>>>Could you describe the test you use on GCL? What version of
>>>gcl are you using?
>>
>>(make-array '(1000 1000) :element-type 'long-float :initial-element 0)
>>
>>about 50 times
>>
>>
>>>>Any idea ?
>>>
>>>If you repeat this process several times:
>>>
>>
>>Sorry,
>>1) Open Axiom
>>4) display residual and virtural memory
>>-- avoid printing
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>new(1000,1000,0)$Matrix(SF);
>>-- memory has increased of 10Mb
>>.
>>.
>>.
>>a lot of times (axiom will crash) => xmalloc failed
>>
>>>For example do this 5 times in a row, do you find that the
>>>total available memory is constantly decreasing?
>>>
>>>If this is not that case, but only occurs on the first
>>>iteration, then what you might be seeing is some kind of
>>>executable cacheing being done by the operating system.
>>>(Does linux do that? Some versions of Windows do. I see
>>>such an effect under Windows XP.)

\start
Date: Wed, 22 Jun 2005 06:01:42 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Memory leak in Axiom : mistake

On Wednesday, June 22, 2005 4:56 AM Ralf Hemmecke wrote:

> Well, there is something else. How is Axiom supposed to behave in the
> following case? (See axiom--main--1--patch-40/mnt/linux/doc/book.dvi
> Section 1.15.1)
>
> --start axiom
> top:
>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 17381 hemmecke  16   0 44072 8492 3016 S  0.0  1.7   0:00.12 AXIOMsys
>
> a:=new(1000,1000,0.0)$Matrix(SF);
> b:=new(1001,1001,0.0)$Matrix(SF);
>
> Now top says
> 17381 hemmecke  17   0 44116  21m 3060 S  0.0  4.3   0:00.34 AXIOMsys
>
> )undo -2
>
> And top says
> 17381 hemmecke  16   0 44116  21m 3088 S  0.0  4.3   0:00.34 AXIOMsys
>
> I understand that due to %% and )undo previous results must be cached,
> but why doesn't )undo release memory? Do I read the values of the top
> command incorrectly?

Don't forget that Axiom runs as a lisp application (GCL). This means
memory allocation is dynamic and that memory usage can be affected by
when lisp decides to do garbage collection. You can force GCL to do
garbage collection and return unused memory. Try using the command:

  )lisp (gbc 3)

after the )undo -2

On my Windows version of Axiom this returns some memory to the operating
system. I don't have the linux version here right now to try this.
Please let me know what you get.

\start
Date: Wed, 22 Jun 2005 12:44:59 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Memory leak in Axiom : mistake

Hi,

Le mercredi 22 juin 2005 =E0 06:01 -0400, Page, Bill a =E9crit :
> On Wednesday, June 22, 2005 4:56 AM Ralf Hemmecke wrote:
>
> > Well, there is something else. How is Axiom supposed to behave in the
> > following case? (See axiom--main--1--patch-40/mnt/linux/doc/book.dvi
> > Section 1.15.1)

Thanks for this information, I have to write a script that records my
history and restore my variables.

> >
> > --start axiom
> > top:
> >    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> > 17381 hemmecke  16   0 44072 8492 3016 S  0.0  1.7   0:00.12 AXIOMsys
> >
> > a:=new(1000,1000,0.0)$Matrix(SF);
> > b:=new(1001,1001,0.0)$Matrix(SF);
> >
> > Now top says
> > 17381 hemmecke  17   0 44116  21m 3060 S  0.0  4.3   0:00.34 AXIOMsys
> >
> > )undo -2
> >
> > And top says
> > 17381 hemmecke  16   0 44116  21m 3088 S  0.0  4.3   0:00.34 AXIOMsys
> >
> > I understand that due to %% and )undo previous results must be cached=
,
> > but why doesn't )undo release memory? Do I read the values of the top
> > command incorrectly?
>
> Don't forget that Axiom runs as a lisp application (GCL). This means
> memory allocation is dynamic and that memory usage can be affected by
> when lisp decides to do garbage collection. You can force GCL to do
> garbage collection and return unused memory. Try using the command:
>
>   )lisp (gbc 3)
>
> after the )undo -2
>
> On my Windows version of Axiom this returns some memory to the operatin=
g
> system. I don't have the linux version here right now to try this.
> Please let me know what you get.

No memory released.
A new matrix allocation re-increase used memory.

\start
Date: Wed, 22 Jun 2005 12:27:59 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: More AxiomUI
Cc: Kai Kaminski

Dear Bill,

in fact, I "knew" that what you describe below can be done. The sole purpose of
my mail was to try to get things organised. I have the feeling that it is not
at all clear what "we" want, and in fact, there are several different "we"s,
since some of us are doing math research, some want to use axiom for teaching,
others to use axiom as a platform to try out new ideas, ...

Even the group that does research will very probably have several different,
possibly conflicting "ideals".

Concerning regression testing: I would use the domain specific equality
function of Axiom. After all, Axiom's philosophy is that "simplifications" are
done by user interaction, Axiom itself coerces the stuff only into the domains
representation.

Martin

Page, Bill writes:
 > Martin,
 > 
 > As you know, on MathAction we can write a pseudo-environment
 > 
 > \begin{axiom}
 > guess([1,1+q,1+q+q^2])
 > $GUESS(n,FRAC POLY INT,i+->q^i,FRAC POLY INT, EXPR INT, i+->i, i+->i)
 > \end{axiom}
 > 
 > to achieve the kind of output you describe below.
 > 
 > It would not be difficult at all to achieve this same result with
 > Axiom documentation written in pamphlet format. The command
 > 
 >   $ noweave guess.pamphlet
 > 
 > just creates the LaTeX output from the pamphlet file. This file can
 > contain the same Axiom pseudo-environments as on MathAction. But
 > before it can be processed by the latex command it would first have
 > to be pre-processed by Axiom to convert the \begin{axiom} sections
 > to actual latex. The process would be like this:
 > 
 >   $ noweave example.pamphlet > example.axiom
 >   $ runaxiom < example.axiom > example.tex
 >   $ latex example.tex
 > 
 > This could be make part of the existing `document' script.
 > 
 > Your example file would then look like this:
 > 
 > % ------------------------ example.pamphlet -------------------------
 > 
 > The exported function takes a list of elements of [[F]] and returns a
 > list of expressions over [[R]] that seem to fit the data. For example,
 > 
 > <<inputfile>>=
 > guess([1,1+q,1+q+q^2])
 > $GUESS(n,FRAC POLY INT,i+->q^i,FRAC POLY INT, EXPR INT, i+->i, i+->i)
 > @
 > 
 > returns
 > 
 > \begin{axiom}
 > <<inputfile>>
 > \end{axiom}
 > 
 > % ---------------------------end of example --------------------------
 > 
 > If this is really of interest to you, I can provide the `runaxiom'
 > script based on a simplified version of the Python code that we
 > use on MathAction.
 > 
 > Having it "compare Axiom's output with a given result and raise a
 > warning if the two differ" is certainly possible. This is often
 > called regression testing. Tim Daly has discussed it several times
 > before on this list (see CATS computer algebra test suite). There
 > already some provision for this in the current Axiom makefiles but
 > it is not yet fully functional.
 > 
 > Implementing this properly still requires a bit more design of how
 > to document the expected results and how to perform the comparison.
 > For example: should the comparison be based on the LaTeX generated
 > or just on text output? Is a simple `diff' of the output and expected
 > result adequate?
 > 
 > Regards,
 > Bill Page.
 > 
 > On Tuesday, June 21, 2005 5:39 AM you wrote:
 > 
 > > ...
 > > I think that the pamphlet file syntax we currently have is not too
 > > bad (as "external representation"), but I wouldn't mind if it were
 > > replaced by something else.
 > >
 > > One thing I dislike about it is the following: Currently I have to
 > > write:
 > >
 > > % --------------------------------- example -------------------------
 > >
 > > The exported function takes a list of elements of [[F]] and returns a
 > > list of expressions over [[R]] that seem to fit the data. For example,
 > >
 > > <<inputfile>>=
 > > guess([1,1+q,1+q+q^2])
 > > $GUESS(n,FRAC POLY INT,i+->q^i,FRAC POLY INT, EXPR INT, i+->i, i+->i)
 > > @
 > >
 > > returns
 > >
 > > [[      n 
 > >       q  - 1
 > > (1)  [------]                                      
 > >        q - 1                                       
 > >             Type: List Expression Integer 
 > >]]
 > >
 > > % ---------------------------end of example --------------------------
 > >
 > > However, I'd really like to have axiom compute the result. The best
 > > thing would be, if axiom computes the result and, if present, it
 > > compares it with the given result and raises a warning if the two differ.
 > 

\start
Date: Wed, 22 Jun 2005 12:02:14 +0200
From: Ralf Hemmecke
To: list
Subject: axiom book

For those who read the axiom book via

xdvi $AXIOM/mnt/linux/doc/book.dvi

... You might want to add the hyperref package at the beginning of
axiom--main--1--patch-40/src/doc/book.pamphlet and remake the book via

cd $AXIOM;
make book

%-- book.pamphlet --
\documentclass{book}
%\usepackage{axiom}
\usepackage{graphicx}
\usepackage{hyperref} %<-- this line
.... (rest of the file)
%-- end book.pamplet

Unfortunately, there are not too many places where this is helpful, but 
at least one gets hyperlinks from the table of contents to the 
corresponding section.

To the developers...
It is confusing why in there is code in

axiom--main--1--patch-40/src/doc/Makefile.pamphlet

to make book.dvi and also in

axiom--main--1--patch-40/Makefile.pamphlet

where the latter does not take the commands from 
src/doc/Makefile.pamphlet into account.

I even suspect that the commands in src/doc/Makefile.pamphlet are never 
used. They probably don't work anyway in the directory seemingly 
src/doc, because the variable SRC is not set.

\start
Date: Wed, 22 Jun 2005 13:53:24 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Memory leak in Axiom

Hi,

Le mardi 21 juin 2005 =E0 21:49 -0400, Page, Bill a =E9crit :
> I wrote:
> > ...
> > If you repeat this process several times:
> >
> > 1) Open Axiom
> > 2) Allocate Matrix
> > 3) Close Axiom
> > 4) display residual and virtural memory
> >
> > For example do this 5 times in a row, do you find that the
> > total available memory is constantly decreasing?
> > ...
> >
> > Could you describe the test you use on GCL? What version of
> > gcl are you using?
>
> On Tuesday, June 21, 2005 9:10 PM Vanuxem Gr=E9gory wrote:
>
> > (make-array '(1000 1000) :element-type 'long-float :initial-element 0=
)
> >
> > about 50 times
> >
>
> I GCL I am not certain that this function will necessarily allocate
> all of the memory that might be required if each element of the
> array was explicitly given some value.
>
> > ...
> > Sorry,
> > 1) Open Axiom
> > 4) display residual and virtural memory
> > -- avoid printing
> > new(1000,1000,0)$Matrix(SF);
> > -- memory has increased of 10Mb
> > new(1000,1000,0)$Matrix(SF);
> > -- memory has increased of 10Mb
> > new(1000,1000,0)$Matrix(SF);
> > -- memory has increased of 10Mb
> > new(1000,1000,0)$Matrix(SF);
> > -- memory has increased of 10Mb
> > new(1000,1000,0)$Matrix(SF);
> > -- memory has increased of 10Mb
> > new(1000,1000,0)$Matrix(SF);
> > -- memory has increased of 10Mb
> > new(1000,1000,0)$Matrix(SF);
> > -- memory has increased of 10Mb
> > .
> > .
> > .
> > a lot of times (axiom will crash) => xmalloc failed
>
> Why do say that this sort of test represents a "memory leak"?
> If you do not close Axiom between these allocations of memory
> you can not be testing for the conditional called a "memory leak".
> A memory leak is a serious problem that occurs when a process does
> not give back to the operating system some memory that it allocated
> when it closes.

I thought it's a forgotten allocated memory.

example in C language:
a = malloc(x)
do work and never release this memory.

Memory is released when the process exit.

>
> It seems quite normal to me that allocating many large arrays
> eventually uses up all available virtual memory. It is possible
> that Axiom is using a different data structure for representing
> a Matrix then the GCL make-array.

\start
Date: Wed, 22 Jun 2005 14:00:37 +0200
From: Ralf Hemmecke
To: list
Subject: Re: Memory leak in Axiom : mistake

OK, let's do it again.

%axiom

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27271 hemmecke  16   0 44072 8492 3016 S  0.0  1.7   0:00.13 AXIOMsys

a:=new(1000,1000,0.0)$Matrix(SF);
b:=new(1001,1001,0.0)$Matrix(SF);

27271 hemmecke  17   0 44116  21m 3060 S  0.0  4.3   0:00.33 AXIOMsys

)undo -2
27271 hemmecke  16   0 44116  21m 3088 S  0.0  4.3   0:00.33 AXIOMsys

)lisp (gbc 3)
27271 hemmecke  17   0 44116  25m 3088 S  0.0  5.2   0:00.40 AXIOMsys

That is funny. Why does AXIOMsys now use even more space???

Ralf

Vanuxem Gr=E9gory wrote:
> Hi,
>
> Le mercredi 22 juin 2005 =E0 06:01 -0400, Page, Bill a =E9crit :
>
>>On Wednesday, June 22, 2005 4:56 AM Ralf Hemmecke wrote:
>>
>>
>>>Well, there is something else. How is Axiom supposed to behave in the
>>>following case? (See axiom--main--1--patch-40/mnt/linux/doc/book.dvi
>>>Section 1.15.1)
>
>
> Thanks for this information, I have to write a script that records my
> history and restore my variables.
>
>
>>>--start axiom
>>>top:
>>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>17381 hemmecke  16   0 44072 8492 3016 S  0.0  1.7   0:00.12 AXIOMsys
>>>
>>>a:=new(1000,1000,0.0)$Matrix(SF);
>>>b:=new(1001,1001,0.0)$Matrix(SF);
>>>
>>>Now top says
>>>17381 hemmecke  17   0 44116  21m 3060 S  0.0  4.3   0:00.34 AXIOMsys
>>>
>>>)undo -2
>>>
>>>And top says
>>>17381 hemmecke  16   0 44116  21m 3088 S  0.0  4.3   0:00.34 AXIOMsys
>>>
>>>I understand that due to %% and )undo previous results must be cached,=

>>>but why doesn't )undo release memory? Do I read the values of the top
>>>command incorrectly?
>>
>>Don't forget that Axiom runs as a lisp application (GCL). This means
>>memory allocation is dynamic and that memory usage can be affected by
>>when lisp decides to do garbage collection. You can force GCL to do
>>garbage collection and return unused memory. Try using the command:
>>
>>  )lisp (gbc 3)
>>
>>after the )undo -2
>>
>>On my Windows version of Axiom this returns some memory to the operatin=
g
>>system. I don't have the linux version here right now to try this.
>>Please let me know what you get.
>
>
> No memory released.
> A new matrix allocation re-increase used memory.

\start
Date: Wed, 22 Jun 2005 14:39:33 +0200
From: Martin Rubey
To: list
Subject: re: More AxiomUI
Cc: Kai Kaminski, Bob McElrath

Hm, an afterthought: I'm not quite sure whether what  

Martin Rubey thought:
 > I would also think that it is a bad idea to do the dependency checking outside
 > of axiom. 

makes sense.

Here a first shot at organizing the things axiom should consist of:

* a compiler

* an interpreter

* a user interface

* hyperdoc

What does the interpreter do? 

  * parse the input

  * find appropriate signatures

  * if it is

      a call to a compiled function: evaluate

      a function definition: add it to the workspace

Currently, the parser of the interpreter and the parser of the compiler are
different. For example, you cannot define packages, domains or categories in
the interpreter.

In fact, this is also a question of future direction, since I hope very much
that Aldor will become *the* language for Axiom. 

Maybe it would make sense to make the type inference as much independent of the
interpreter as possible. It seems, that quite a few type coercions are defined
for the interpreter only. Why aren't they in the algebra? One example is the
coercion from UP to POLY, I think.

\start
Date: Wed, 22 Jun 2005 14:09:34 +0200
From: Martin Rubey
To: Bill Page
Subject: re: More AxiomUI
Cc: Kai Kaminski, Bob McElrath

Dear all,

I would also think that it is a bad idea to do the dependency checking outside
of axiom. By the way, axiom does it already:

(1) -> f(x:INT):INT == 5
   Function declaration f : Integer -> Integer has been added to 
      workspace.
                                                                   Type: Void
(2) -> g(x:INT):INT == f(x)
   Function declaration g : Integer -> Integer has been added to 
      workspace.
                                                                   Type: Void
(3) -> f(x:INT):INT == 10
   Function declaration f : Integer -> Integer has been added to 
      workspace.
   1 old definition(s) deleted for function or rule f 
                                                                   Type: Void
\start
Date: Wed, 22 Jun 2005 15:13:10 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: how to expand trig functions ?

Dear Fran=E7ois,

I justed tried out what you wrote:

Francois Maltey writes:
 > expand (sin (x+y)) is right, but

yes.

 > 1/ I can't get expand (sin (2*x))

well, the documentation says that expand deals only with sums...
I guess that you would like to have expand sin(n*x) use the chebyshev
polynomials? I think that this would be reasonable.

 > 2/ The result of expand (sin (x+y+z)) doesn't seem complete.
 >    axiom only apply twice the expanded sin (a+b) and cos (a+b).
 >    I prefer the maple and mupad method. The formula is completly exp=
anded.

It is complete in my axiom:

(23) -> expand sin (x+y+z)

   (23)
     (- sin(x)sin(y) + cos(x)cos(y))sin(z) + cos(x)cos(z)sin(y)
   +
     cos(y)cos(z)sin(x)
                                                     Type: Expression I=
nteger
did you expect something else?


 > Am I right when I see it's comming from this src/algebra/manip.spad =
file ?

\start
Date: Wed, 22 Jun 2005 10:19:37 -0400
From: William Sit
To: Bill Page
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

"Page, Bill" wrote:
> 
> On Tuesday, June 21, 2005 5:05 PM Bob McElrath
> 
> > Kai Oliver Kaminski [Kai Kaminski] wrote:
> >> What kind of dependency tracking would you need? Just within a
> >> single page? For multiple pages? Send me use cases, tell me what
> >> you need.
> >
> >I've been thinking about this a lot lately.
> 
> Although I have not played with this much but both Tim Daly and
> William Sit assure me that the old Axiom Hypertex browser
> already implements this kind of dependency tracking. That is
> apparently the purpose of the \free{} and \bound{} attributes
> embedded the Axiom commands contained in the hypertex pages.
> 
> I would prefer to call this something like "lazy re-evaluation".
> 
> I think it is notable that neither Maple nor Mathematica have
> lazy re-evaluation in their standard worksheet interfaces.

I am not sure what you meant by "lazy re-evaluation" here (or it could be my
ignorance about the concept). Mathematica has two modes of assignments:
SetDelayed (:=) for functions and Set (=) for immediate evaluation and so does
Axiom: macro (==) and assign (:=). Both SetDelayed and macro can be used to
define *any* identifier, not necessarily a function (just think of it as
function without arguments although there may be a minor difference: "x == ..."
instead of "x() == ..."). Each time an identifier defined using SetDelayed or
macro is referenced, it is recomputed in Set or assignment (and in SetDelayed or
macro when these are computed), and this occurs recursively until all
identifiers at the "leaves" are resolved with Set or assigned values. The
SetDelayed or macro defined identifiers have no "values" associated and the
values are computed on demand. Do you consider this delayed computation lazy
re-evaluation? [I put "values" in quotation because the word value can have
different meanings at different levels; at a functional level, the SetDelayed or
macro defined identifiers of course have associated "values".]

The above delayed evaluation (which is automatically evaluated when needed) only
occurs *after* the SetDelayed or macro definitions have been executed earlier
(known the Axiom's run time system). This is different from the hyperdoc
browser, which may have only *read in* the input file, but *not yet* run any
assignment (delayed or otherwise). This is like in Mathematica when the you read
in a Notebook, commands are not executed (unless marked as initialisation cells
and the system set to automatically run these on loading). Now if a user
*skipped* some assignments (delayed or otherwise) that, say, defines x, y, and
*jumped* to an assignment for z that involves x, y, normally in the Axiom
interpreter, the x, y would be treated as undefined symbols
and perhaps cause either a syntax error or a wrong evaluation. In hyperdoc, the
system will know whether x and y are free or bound (because these are declared
in the input file when it is built for hyperdoc from regular input file), it
knows to search for their definitions and execute those assignments. 

So the hyperdoc action, as I understand it, is unrelated to "lazy re-evaluation"
of the first paragraph.

>  [spreadsheet interface discussion snipped]

> Unfortunately the authoring of hypertex pages in Axiom is not
> an easily accessible user feature, so in spite of having the
> possibiliy of lazy re-evaluation, right now it only applies to
> hypertex browser pages. It does not really provide this as a
> "worksheet" option as such.
> 
> > Mathematica seems to keep an array of input and output.
> > (In[] and Out[]).  If we treat these as simple variables,
> > dependency tracking would be as simple as keeping a linked
> > list among variables.  (e.g. a "has" or "indeterminants"
> > function)  In addition to that each variable would need a
> > "modified" flag.  Any time a "modified" flag is toggled,
> > axiom could traverse the dependency tree and mark outputs
> > with a "recompute" flag.
> 
> Of course Axiom also keeps a list of inputs and has a fairly
> sophisticated )history command.
> 
> Can \free and \bound names really be determined automatically?
> I think it is awkward to require the use to declare them
> separately the way it is done now in the hypertex browser.
> Perhaps this is possible with the help of some new code in
> Axiom itself. 

As you know, nothing is *automatic* unless the automation is designed into the
system using some convention or protocol and people follow them. In Axiom, there
is the compiler and there is the interpreter. The hyperdoc dependency resolver
enabled files (if I may call it that, an example would be odpol.htx) is
generated (automatically as far as authors of constructors are concerned) from a
source file (say dpol.xmp) created by the authors, but in principle, this source
file could have been extractable from the spad file or pamphlet file. The
convention is simply to have the documentation as text (with some embedded
hyperlinks), the input to the interpreter as -- comments after a key line "--
Examples" placed after the ++ comments for a function. In particular, no
declaration of \free or \bound is needed. During 1990-2, Bob Sutor was working
on the Axiom book and the .tex files were used for the book as well. It was, if
memory serves, experimental at the time and the .xmp files were basically
extracted from the spad file by deleting the code except for signatures, ++
comments, and examples. I remember I thought this was so cool I actually
included "-- Examples" in several spad files I wrote. However, these were not
incorporated into the hyperdoc browser database or the book (perhaps due to
space and time limitation of the book).  From the .xmp files, I think the
regression testing .input files are generated as well (correct me, Tim, if this
is not right; there is a odpoly.input in the distribution), and these .input
files probably also support the hyperdoc examples.

You can test the odpol examples in the hyperdoc browser by going to
Examples->Domains->OrderlyDifferentialPolynomial.

The file odpol.htx is now generated by ht.awk (I don't know where this is, may
be the file is $AXIOM/src/hyper/ex2ht.pamphlet) and renamed
$AXIOM/mnt/linux/doc/hypertex/pages/ODPOL.ht (see also ODPOL.pht, a pamphlet
version with output included). Tim added internal links. The file odpol.input is
in the $AXIOM/mnt/linux/input directory.

Unfortunately, I was not able to locate any dpol.xmp file from the current Axiom
distribution (Feb, 2005). I was able to find in my own archive an older
(partially damaged?) version of dpol.xmp (dated 9/13/1991) which contains
examples for other related packages as well, and what seems to be the current
version of odpol.htx (dated 2/7/1992), and also a tex file odpol.tex (dated
2/18/1992) which is a tex segment for the hyperdoc with Axiom outputs. These
two, and others were generated automatically (Bob Sutor, I believe, was the one
who implemented this, but I do not know the command/program that did it). The
two files do not match, but do give the flavor. I believe Tim must have the
"current" version. There should be a directory containing .xmp files.

So any package can have such a .xmp file extracted and converted into the
hyperdoc dependency resolver enabled .ht file.


> Should this be a front-end browser function or
> a back-end Axiom function. For example a function in Axiom
> might be able to return the list of input history numbers of
> those commands that need to be re-executed. 

This is unreasonable. The purpose to edit earlier input lines may also rearrange
the order of execution of the lines. Only the user knows what order of execution
is needed for his/her purpose. However, as you probably know, you can use:

)history )write filename.input

to capture the input lines (if you have ")history on") and edit it.
However, the resulting .input file captures all input lines, including all the
ones that did not work due to typos or syntax, etc, and so needs to be cleaned.

What is desirable in the interpreter interface, is the ability to edit previous
input lines in a 2D way. Mathematica allows it and makes it very easy to do
quick exploratory computations during the development phrase. The final order of
execution can be done with cut and paste right there on screen in the FrontEnd
and there is no need to save the history into a file first (because the
interface *is* the editor as well). Maybe an emacs or TeXmacs interface can do
that?

> These could be
> mapped to corresponding output areas in the browser.

A browser (web browser) is not a text editor (yet). In fact, it is probably
undesirable to make a browser into an editor. As nice as Wiki is, one still have
to edit the source text, rather than the rendered text. In Mathematica, this
would be like requiring editing the Notebook file in text mode (which one *can*
do, even on a cell-by-cell basis). I can't imagine editing XML in text mode (I
have tolerated editing html, including those generated by MS Word or including
Chinese, but I think direct editing XML is not for me).

Speaking of XML, Microsoft "opens" up its XML technology, drawing a lot of fire.
Do a google on "eweek XML Microsoft open source" for more.

> > [clip nice example]
> 
> > A user interface could choose to highlight out[1] as needs-
> > recomputing, or just go ahead and do it. (spreadsheet-style)
> 
> I think it would be pretty neat if the browser could do such
> highlighting and very useful if with one click you could ask
> Axiom to minimally recompute just those comands that need
> re-computing. This should be quite easy in principle using the
> kind of AJAX techniques that Kai mentioned elsewhere. The hardest
> part would be writing the Axiom code that dynamically computes
> the dependency tree.

Am I missing something here? Can't one simply use == and := to achieve the same
thing already? As I commented above, it is *not* Axiom's job to decide for me
what needs recomputing and what does not. (Think about all the "automated"
choices MS Word provides -- I spend more time undoing them than actual writing).
I decide by correctly using == and := and recalling inputs.  What may be needed
and would be extremely helpful in terms of user experience, is again what
Mathematica allows: 2D editing, with multiple selection of cells, not
necessarily adjacent, and then one shift-enter does it. I would love to have
Mathematica FrontEnd working for Axiom (the best of both worlds). There are many
many features of the FrontEnd that are great and unparallelled (to name just a
few besides those already mentioned: all Notebooks are ASCII, include editable
input and output, graphics, incorporated style sheets,
independent of platform or operating systems, can be converted into html, tex,
etc; the entire Mathematica documentation available, with live editable
examples, and programmable using FrontEnd commands).

\start
Date: Wed, 22 Jun 2005 11:27:51 -0400
From: William Sit
To: Martin Rubey
Subject: re: More AxiomUI
Cc: Kai Kaminski, Bob McElrath

Martin Rubey wrote:
> Currently, the parser of the interpreter and the parser of the compiler are
> different. For example, you cannot define packages, domains or categories in
> the interpreter.

Much I would agree with you that the difference between the two parsers is a
constant headache and certainly makes it harder to go from interpreter to
compiler, I can understand the roles and necessity of both. Being a strongly
typed language, to require a casual user or beginner to declare types for all
identifiers and to use package calls is too much. Other CAS like Maple or
Mathematica are not even typed. 

> In fact, this is also a question of future direction, since I hope very much
> that Aldor will become *the* language for Axiom.

What features of Aldor do you want to add to Axiom?

> Maybe it would make sense to make the type inference as much independent of the
> interpreter as possible. It seems, that quite a few type coercions are defined
> for the interpreter only. Why aren't they in the algebra? One example is the
> coercion from UP to POLY, I think.

First, a direct coercion between two domains of the same category is by design,
I think, not practical. Domains may differ by their mathematical meaning, but
even if they do not, they differ by their data structure (and hence
implementation). When a domain is constructed, it should not be required to be
aware of other domains in the same category (providing coercion would), because
for one thing, it may be the first. Thus such a requirement would require
constant updating of all older domains that in principle are coercible to other
"younger" ones. Note that by the same reasoning, only a younger domain can be
CoercibleTo an older domain, not the other way round. (By making CoercibleTo go
the other way would make "older" become the "younger"). 

Axiom handles this problem with maps. In the polynomial situation, there is
POLYLIFT, which allows one in the compiler programs to map one polynomial of a
domain into another in perhaps some other domain.  I suspect that the
interpreter applies this (mapping facility) to do certain "coercions" that are
not explicitly available (as in CoercibleTo, ConvertibleTo, RetractableTo) and
for some reason, the choice of these maps is not shown in )set mess bot on.

\start
Date: Wed, 22 Jun 2005 11:08:13 -0500
From: Tim Daly
To: list
Subject: peta-machine

i keep muttering about the mythical "peta-machine". that is, a machine
with a petabyte of disk, a terabyte of storage, a terahertz of cpu, and
10 gigabyte internet bandwidth.

this is the "target machine" i've been using with the claim that it will
be available in 30 years and that we need to plan for its arrival so it
can be used effectively by a researcher.

well it appears my imagination is WAY too weak. the machine just arrived:

http://linuxdevices.com/news/NS2659179152.html

now if we could just get $1M/year funding for Axiom we could really
get somewhere :-)

\start
Date: Wed, 22 Jun 2005 18:34:02 +0200
From: Ralf Hemmecke
To: William Sit
Subject: Aldor/Axiom convergence

>>In fact, this is also a question of future direction, since I hope very much
>>that Aldor will become *the* language for Axiom.

> What features of Aldor do you want to add to Axiom?

I am much in favour of Martin's position. There are 3 languages...
Citing from http://www.aldor.org/docs/HTML/chap18.html#5
A source of possible confusion is that there are now three similar but 
different programming languages associated with AXIOM:

     * Aldor, a new programming language;
     * the language supported by the old system compiler;
     * the language supported by the system interpreter.

I simply think that Aldor is more advanced and better described in the 
Aldor User Guide (http://www.aldor.org/docs/HTML/) than is the spad 
language. Well the Aldor compiler still has bugs, but that is some other 
issue.

I'd simply wish to reduce the number of languages. And I agree with 
Martin that Aldor should be the way to go.

At the moment the situation is confusing. I have not yet heard a 
suggestion of whether to write new Axiom library code by using the spad 
compiler or the Aldor compiler.

\start
Date: Wed, 22 Jun 2005 13:35:20 -0400
From: Bill Page
To: William Sit
Subject: RE: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

William,

I am sorry that this is a rather long email, but I think this is
an important subject that has not yet been properly dealt with
in any computer algebra system.

> Bill Page wrote:
>> ... both Tim Daly and William Sit assure me that the old Axiom
>> Hypertex browser already implements this kind of dependency
>> tracking. That is apparently the purpose of the \free{} and
>> \bound{} attributes embedded the Axiom commands contained in
>> the hypertex pages.
>> 
>> I would prefer to call this something like "lazy re-evaluation".
>> 
>> I think it is notable that neither Maple nor Mathematica have
>> lazy re-evaluation in their standard worksheet interfaces.

On Wednesday, June 22, 2005 10:20 AM William Sit wrote:

> I am not sure what you meant by "lazy re-evaluation" here (or it
> could be my ignorance about the concept).

"Lazy re-evaluation" is a concept that has been discussed in the
context of discrete event simulation, parallel computation and
transaction processing roll-back in databases systems. See for
example:

An Efficient Implementation of Lazy Re-evaluation
Avinash C. Palaniswamy, Sandeep Aji, and Philip A.
http://portal.acm.org/citation.cfm?id=306961

"Lazy Reevaluation is a technique designed to reduce unnecessary
re-compilation after processing a rollback event. That is, if an
event e causes rollback and the processing does not alter the
process state, then the process can jump over the events that it
has already processed."

Also related to "mostly functional" programming:

Worlds in Collision: A Mostly Functional Model of Concurrency
Control and Recovery

http://home.pipeline.com/~hbaker1/TreeShadow.html

"We therefore advocate a style of programming called "mostly
functional programming". Unlike purely functional programming,
which attempts to completely finesse  the issue of state, we
realize that state is an essential part of the "real world"
and must be dealt with. For example, synchronization of two
processes requires at least one bit of state--which process
arrived first--and so state cannot be avoided in a parallel
system which performs any communication. Since state is a
"necessary evil", we seek to control it by making it accessible
and utilize state-accessing and state-changing operations as
sparingly as possible."

> Mathematica has two modes of assignments: SetDelayed (:=) for
> functions and Set (=) for immediate evaluation and so does
> Axiom: macro (==) and assign (:=). Both SetDelayed and macro can
> be used to define *any* identifier, not necessarily a function
> (just think of it as function without arguments although there
> may be a minor difference: "x == ..." instead of "x() == ...").
> Each time an identifier defined using SetDelayed or macro is
> referenced, it is recomputed in Set or assignment (and in SetDelayed
> or macro when these are computed), and this occurs recursively
> until all identifiers at the "leaves" are resolved with Set or
> assigned values. The SetDelayed or macro defined identifiers have
> no "values" associated and the values are computed on demand.

In Maple this is written as

  x := '....';

The use of quotes prevents evaluation so that x literally represents
the expression enclosed in quotes instead of it's "value".

> Do you consider this delayed computation lazy re-evaluation? [I put
> "values" in quotation because the word value can have different
> meanings at different levels; at a functional level, the SetDelayed
> or macro defined identifiers of course have associated "values".]

No what you describe is usually just called "delayed evaluation". It is a
type of lazy *evaluation*, not lazy *re-evaluation*.

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

"Delayed evaluation is used particularly in functional languages. When
using delayed evaluation, an expression is not evaluated as soon as it
gets bound to a variable, but when the evaluator is forced to produce
the expression's value."

Lazy evaluation in functional programming languages usually means
something more than just delayed evaluation. For reasons of
efficiency it also involves "updating" or caching of values. As
far as I know, Axiom does not do this when evaluating the ==
construct but in might apply in the case of Axiom's iterator
expressions. I don't know about Mathematica but I do know that in
the case of Maple it is possible to associate this kind of caching
with function evaluation.

http://computing-dictionary.thefreedictionary.com/lazy%20evaluation

"lazy evaluation - An evaluation strategy combining normal order
evaluation with updating. Under normal order evaluation (outermost or
call-by-name evaluation) an expression is evaluated only when its value
is needed in order for the program to return (the next part of) its
result. Updating means that if an expression's value is needed more
than once (i.e. it is shared), the result of the first evaluation is
remembered and subsequent requests for it will return the remembered
value immediately without further evaluation. This is often implemented
by graph reduction. An unevaluated expression is represented as a
closure - a data structure containing all the information required to
evaluate the expression."

> The above delayed evaluation (which is automatically evaluated when
> needed) only occurs *after* the SetDelayed or macro definitions have
> been executed earlier (known the Axiom's run time system). This is
> different from the hyperdoc browser, which may have only *read in*
> the input file, but *not yet* run any assignment (delayed or otherwise).
> This is like in Mathematica when the you read in a Notebook, commands
> are not executed (unless marked as initialisation cells and the
> system set to automatically run these on loading). Now if a user
> *skipped* some assignments (delayed or otherwise) that, say, defines
> x, y, and *jumped* to an assignment for z that involves x, y, normally
> in the Axiom interpreter, the x, y would be treated as undefined symbols
> and perhaps cause either a syntax error or a wrong evaluation. In
> hyperdoc, the system will know whether x and y are free or bound
> (because these are declared in the input file when it is built for
> hyperdoc from regular input file), it knows to search for their
> definitions and execute those assignments.

I don't see any difference in principle between a 'bound' variable
in hyperdoc and a delayed evaluation in Axiom. In both case the
definitions are "read-in" but not yet acted upon. It's just that
this is occurring at a different level in the system. There is a
difference however in the case where the command in Axiom is not a
delayed evaluation. In effect in this case the value of a variable
is being updated ("cached" i.e. stored) and should not have to be
evaluated again.

> So the hyperdoc action, as I understand it, is unrelated to
> "lazy re-evaluation" of the first paragraph.

That is correct. Re-evaluation is a little different. It involves a
series of operations (transactions) which have already altered the
state of the program, i.e. a series of updates. Like this:

  (1) -> a:=1
  (2) -> b:=a
  (3) -> a:=2
  (4) -> c:=a+b
  ...

At the end of this sequence of commands the state of Axiom is
given by

  )display values

   Value of a: PositiveInteger:  2
   Value of b: PositiveInteger:  1
   Value of c: PositiveInteger:  2

Now think of these commands, (1), (2), ... as editable text embedded
inside an Axiom "worksheet" e.g. displayed on a page of the new
AxiomUI browser. The user decides that they want to change command
(2) to read:

  (2) -> b:=a+1

The simplest thing (but not the most efficient thing) for us to do
in this case is just to scrap the state of the whole calculate

  )clear values all

(i.e. roll-back) then re-do all four commands again.

  (5) -> a:=1
  (6) -> b:=a+1
  (7) -> a:=2
  (8) -> c:=a+b

This is what one must do now for example in Maple. There is even a
special button labeled !!! that performs the ')clear all' (reset;)
and re-execution in one click. (and then wait ... :).

A lazy re-evaluation on the other hand would recognize that after
changing command (2) the minimum number of commands that need to
be re-executed so that the state of Axiom is consistent with the
revised browser page is just these two:
  
  (5) b:=%%(1)+1
  (6) c:=a+b

>  [spreadsheet interface discussion snipped]

> ...
>> Should this be a front-end browser function or a back-end Axiom
>> function. For example a function in Axiom might be able to return
>> the list of input history numbers of those commands that need to
>> be re-executed. 
>
> This is unreasonable. The purpose to edit earlier input lines may
> also rearrange the order of execution of the lines. Only the user
> knows what order of execution is needed for his/her purpose.

I disagree. Given Axiom's history of the commands that have already
been executed and a list of the modifications to the input lines
(contents of the browser page), it is quite possible to determine
the minimum number and order of (re-)execution and/or execution of
new commands that is required to compute a consistent state.

> However, as you probably know, you can use:
>
> )history )write filename.input
>
> to capture the input lines (if you have ")history on") and edit
> it. However, the resulting .input file captures all input lines,
> including all the ones that did not work due to typos or syntax,
> etc, and so needs to be cleaned.

That is equivalent to the brute force method that is necessary
now with Maple. It is possible to do much better than this!

> What is desirable in the interpreter interface, is the ability to
> edit previous input lines in a 2D way. Mathematica allows it and
> makes it very easy to do quick exploratory computations during the
> development phrase.

2-d editing might be possible if we can use mathML. In that case
it is possible to select displayed 2-d sub-expressions, modify them
with a few keystrokes (e.g. by typing the corresponding linear 1-d
sub-expression). But in general wysiwyg equation editing is often
awkward at best. And input of commands actually involves more
semantics than what is normally explicit in the 2-d display. Both
Maple and Mathematica have invested a great deal of effort in a user
interface that (in principle) allows this. But even after all this
effort, I really don't like to use it. I am too used to the "old" way
of doing it, I guess - using a separate linear 1-d "input syntax"
to type the commands.

> The final order of execution can be done with cut and paste right
> there on screen in the FrontEnd and there is no need to save the
> history into a file first (because the interface *is* the editor
> as well). Maybe an emacs or TeXmacs interface can do that?

The information in the history file is necessary if we want to
perform lazy re-evaluation as I described above.

>> These could be mapped to corresponding output areas in the
>> browser.
>
> A browser (web browser) is not a text editor (yet). In fact, it
> is probably undesirable to make a browser into an editor.

I disagree. Have you tried Kai's AxiomUI demo yet?

> As nice as Wiki is, one still have to edit the source text, rather
> than the rendered text.

That is true, but in most cases I would argue that this is *more
efficient* then 2-d editing of the commands whose output generated
some rendered mathematics.

> In Mathematica, this would be like requiring editing the Notebook
> file in text mode (which one *can* do, even on a cell-by-cell basis).
> I can't imagine editing XML in text mode (I have tolerated editing
> html, including those generated by MS Word or including Chinese, but
> I think direct editing XML is not for me).

It is not expected that an AxiomUI user would edit XML markup. It
is also likely that we can avoid almost all HTML except in the
case of some complex page structures.

> ...
>>> [clip nice example]
>> Bob McElrath wrote: 
>>> A user interface could choose to highlight out[1] as needs-
>>> recomputing, or just go ahead and do it. (spreadsheet-style)
>> 
>> I think it would be pretty neat if the browser could do such
>> highlighting and very useful if with one click you could ask
>> Axiom to minimally recompute just those comands that need
>> re-computing. This should be quite easy in principle using the
>> kind of AJAX techniques that Kai mentioned elsewhere. The hardest
>> part would be writing the Axiom code that dynamically computes
>> the dependency tree.
>
> Am I missing something here? Can't one simply use == and := to
> achieve the same thing already?

I think you are *definitely* missing something ... :). I don't
see what == and := have to do with this.

> As I commented above, it is *not* Axiom's job to decide for me
> what needs recomputing and what does not.

I disagree. To paraphrase what Bob wrote several emails earlier:
"Why should it be necessary for me to do something complex
like figuring out an efficient re-calculation sequence when
this is something that a computer can do very easily?"

> (Think about all the "automated" choices MS Word provides --
> I spend more time undoing them than actual writing).

MS Word is a rotten example. I agree that we don't want that!

> I decide by correctly using == and := and recalling inputs.
> What may be needed and would be extremely helpful in terms of
> user experience, is again what Mathematica allows: 2D editing,
> with multiple selection of cells, not necessarily adjacent,
> and then one shift-enter does it.

"Selection of cells" is essentially what Bob and I were discussing
above that you seemed to "miss".

> I would love to have Mathematica FrontEnd working for Axiom
> (the best of both worlds). There are many many features of the
> FrontEnd that are great and unparallelled (to name just a
> few besides those already mentioned: all Notebooks are ASCII,
> include editable input and output, graphics, incorporated style
> sheets, independent of platform or operating systems, can be
> converted into html, tex, etc; the entire Mathematica documentation
> available, with live editable examples, and programmable using
> FrontEnd commands).

Don't get me wrong: I think there are some very good things about
both the Mathematica and Maple user interfaces. But user preferences
for particular worksheet interfaces is a very subjective thing.
Because of the high learning curves it is often dictated largely
by one's individual experience and emotions like product loyalty
(or the opposite of loyalty ;) which are often generated by intense
intellectual investment. Disagreements on user interface design
probably generates just as much or more "heat" then opinions
about programming languages.

\start
Date: Wed, 22 Jun 2005 19:42:53 +0200
From: Martin Rubey
To: William Sit
Subject: re: More AxiomUI
Cc: Kai Kaminski, Bob McElrath

Since I'm in a hurry, only part of an answer:

William Sit writes:
 
> Martin Rubey wrote:

 > > Currently, the parser of the interpreter and the parser of the
 > > compiler are different. For example, you cannot define packages,
 > > domains or categories in the interpreter.  > > Much I would agree
 > > with you that the difference between the two parsers is a >
 > > constant headache and certainly makes it harder to go from
 > > interpreter to > compiler, I can understand the roles and
 > > necessity of both. Being a strongly > typed language, to require
 > > a casual user or beginner to declare types for all > identifiers
 > > and to use package calls is too much. Other CAS like Maple or >
 > > Mathematica are not even typed.

Of course the interpreter needs to be able to do type inference, just
as it does now -- or better :-) In fact, this is also a question
of future direction, since I hope very much that Aldor will become
*the* language for Axiom. What features of Aldor do you want to
add to Axiom?

A clear grammar, dependent types, post-facto extensions, and all the splendid
algorithms available in the libraries distributed with aldor. (many of which
are by Manuel Bronstein)

 > > Maybe it would make sense to make the type inference as much
 > > independent of the interpreter as possible. It seems, that quite
 > > a few type coercions are defined for the interpreter only. Why
 > > aren't they in the algebra? One example is the coercion from UP
 > > to POLY, I think.  > > First, a direct coercion between two
 > > domains of the same category is by > design, I think, not
 > > practical. Domains may differ by their mathematical > meaning,
 > > but even if they do not, they differ by their data structure (and
 > > > hence implementation). When a domain is constructed, it should
 > > not be > required to be aware of other domains in the same
 > > category (providing > coercion would), because for one thing, it
 > > may be the first. Thus such a > requirement would require
 > > constant updating of all older domains that in > principle are
 > > coercible to other "younger" ones. Note that by the same >
 > > reasoning, only a younger domain can be CoercibleTo an older
 > > domain, not the > other way round. (By making CoercibleTo go the
 > > other way would make "older" > become the "younger").

Part of this problem is solved (in a fine manner) by post-facto extensions,
described in the Aldor user guide.

 > Axiom handles this problem with maps. In the polynomial situation,
 > there is POLYLIFT, which allows one in the compiler programs to map
 > one polynomial of a domain into another in perhaps some other
 > domain.  I suspect that the interpreter applies this (mapping
 > facility) to do certain "coercions" that are not explicitly
 > available (as in CoercibleTo, ConvertibleTo, RetractableTo) and for
 > some reason, the choice of these maps is not shown in )set mess bot
 > on.

\start
Date: Wed, 22 Jun 2005 11:14:54 -0700
From: Bob McElrath
To: William Sit
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski, Bill Page

First let me give a simple definition of lazy re-evaluation.  Imagine a
worksheet interface, that when read from top to bottom, is *always*
consistent.  In Maple and Mathematica the user must remember what he has
executed, and keep much information about the kernel's state in his/her
head.  It is very easy to miss that an output block has changed and
should be re-evaluated.  This state information is easy to keep and deal
with in axiom itself, and would *never* make mistakes.  A user with a
1000 input worksheet will surely make a mistake about which output lines
need re-evaluation sooner or later.  I certainly do.  But then, I'm a
world-renowned software-breaker.

William Sit [William Sit] wrote:
> I am not sure what you meant by "lazy re-evaluation" here (or it could be my
> ignorance about the concept). Mathematica has two modes of assignments:
> SetDelayed (:=) for functions and Set (=) for immediate evaluation and so does
> Axiom: macro (==) and assign (:=). Both SetDelayed and macro can be used to
> define *any* identifier, not necessarily a function (just think of it as
> function without arguments although there may be a minor difference: "x == ..."
> instead of "x() == ..."). Each time an identifier defined using SetDelayed or
> macro is referenced, it is recomputed in Set or assignment (and in SetDelayed or
> macro when these are computed), and this occurs recursively until all
> identifiers at the "leaves" are resolved with Set or assigned values. The
> SetDelayed or macro defined identifiers have no "values" associated and the
> values are computed on demand. Do you consider this delayed computation lazy
> re-evaluation? [I put "values" in quotation because the word value can have
> different meanings at different levels; at a functional level, the SetDelayed or
> macro defined identifiers of course have associated "values".]

Bill pointed out that this is really "lazy evaluation".

I think lazy evaluation also deserves some thought.  It could be used to
simulate lazy re-evaluation, but again it forces a full recomputation
each time.  Re-evaluation aims to compute as little as possible to
return the worksheet to a consistent state.

The combination of macros/SetDelayed and Eval have always bothered me a
lot.  It is generally possible to have multiple levels of this, so that
to compute an expression requires multiple evals:
eval(eval(expression)).  Some functions (like Plot) do not evaluate
their argument while most others do.

The situation is highly confusing.  I think there may be a smarter way
to do it, implementing lazy re-evaluation, while at the same time hiding
*all* of the SetDelayed/Eval mess from the user.  I find myself in a
situation occasionally: "How many times do I have to evaluate this to
get a number?"  "Do I need to use evalc() or evalm()?"  (evalc and evalm
are Maple's complex and matrix evaluators)

Can anyone think of an example using axiom macros demonstrating a
calculation that cannot be done any other way?  Can we think of a way to
map it onto a different paradigm (lazy re-evaluation maybe?) that can
also arrive at the correct answer?

\start
Date: Wed, 22 Jun 2005 20:30:18 +0200
From: Gregory Vanuxem
To: William Sit
Subject: re: More AxiomUI
Cc: Kai Kaminski, Bob McElrath

Hi,

Le mercredi 22 juin 2005 =E0 11:27 -0400, William Sit a =E9crit :
> Martin Rubey wrote:

> > Currently, the parser of the interpreter and the parser of the compiler are
> > different. For example, you cannot define packages, domains or categories in
> > the interpreter.
>
> Much I would agree with you that the difference between the two parsers is a
> constant headache and certainly makes it harder to go from interpreter to
> compiler, I can understand the roles and necessity of both. Being a strongly
> typed language, to require a casual user or beginner to declare types for all
> identifiers and to use package calls is too much. Other CAS like Maple or
> Mathematica are not even typed.

> > In fact, this is also a question of future direction, since I hope
> > very much that Aldor will become *the* language for Axiom.  > >
> > What features of Aldor do you want to add to Axiom?  > Maybe it
> > would make sense to make the type inference as much independent of
> > the interpreter as possible. It seems, that quite a few type
> > coercions are defined for the interpreter only. Why aren't they in
> > the algebra? One example is the coercion from UP to POLY, I think.

> First, a direct coercion between two domains of the same category is
> by design, I think, not practical. Domains may differ by their
> mathematical meaning, but even if they do not, they differ by their
> data structure (and hence implementation). When a domain is
> constructed, it should not be required to be aware of other domains
> in the same category (providing coercion would), because for one
> thing, it may be the first. Thus such a requirement would require
> constant updating of all older domains that in principle are
> coercible to other "younger" ones. Note that by the same reasoning,
> only a younger domain can be CoercibleTo an older domain, not the
> other way round. (By making CoercibleTo go the other way would make
> "older" become the "younger").

> Axiom handles this problem with maps. In the polynomial situation,
> there is POLYLIFT, which allows one in the compiler programs to map
> one polynomial of a domain into another in perhaps some other
> domain.  I suspect that the interpreter applies this (mapping
> facility) to do certain "coercions" that are not explicitly
> available (as in CoercibleTo, ConvertibleTo, RetractableTo) and for
> some reason, the choice of these maps is not shown in )set mess bot
> on.

As far as I know,

for a category or 'domain' there are

categoryfunction2 with map and other functions
or
domainfunctions2 with map and other functions

These maps are shown in the interpreter with )set mess bott on
(The interpreter uses probably a 'pattern matching function' to find
these packages)

In the interpreter, two files do a lot of known coercions:

i-coerfn.boot
i-resolv.boot

They contains some specific code.

\start
Date: Wed, 22 Jun 2005 13:55:51 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#179 differentiating sums with respect to a bound is wrong]

Update of bug #9216 (project axiom):

                  Status:                    None => transferred            
Example of code trigerring the bug: f:=operator 'f
D(sum(f(i),i=a..x),x)
 => f:=operator 'f
D(sum(f(i),i=a..x),x)

\start
Date: Wed, 22 Jun 2005 14:15:39 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#180 bug #9216 differentiating sums with respect to a bound is wrong]

Mathematically axiom produces correct output now, however I'm not sure
whether my patch is best possible.

Maybe there should be a function D in OutputForm that displays unevaluated
differentiation. Also, I find it ugly to use the raw %diff operator in COMBF.
Furthermore, is it necessary to substitute a dummy variable for the variable
of differentiation?

Update of Savannah patch # 3148 (project axiom):

Mon 06/21/2004 at 11:15, comment #1::

  Also, it does not fix bug #9218
  Martin Rubey <kratt6>

Tue 12/28/2004 at 14:35, comment #2::

  What is the status of this patch?
  Bill Page <billpage1>
  Project AdministratorIn charge of this item.

Continuation of issue #179

Attached Files

  dvdpatch.patch added by kratt6 (2.07KB)
 
\start
Date: Wed, 22 Jun 2005 14:09:19 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#179 differentiating sums with respect to a bound is wrong]

Example of code trigerring the bug:
\begin{axiom}
f:=operator 'f

is nonsense. The problem is in COMBF/dvdsum:

\begin{axiom}
dvdsum(l, x) ==
  x = retract(y := third l)@SE => 0
  k := retract(d := second l)@K
  differentiate(h := third rest rest l,x) * eval(f := first l, k, h)
  - differentiate(g := third rest l, x) * eval(f, k, g)
  + opdsum [differentiate(f, x), d, y, g, h]
\end{axiom}

Although this:

$$d/dx \sum_i^x f(i) = f(x)$$

is a nice try, it is wrong. It seems that the order of magnitude is
roughly correct, but that's about it.

Unfortunately, I do not know how to return the thing unevaluated,
so I cannot fix the bug yet

\start
Date: Wed, 22 Jun 2005 15:07:28 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#180 bug #9216 differentiating sums with respect to a bound is wrong]

++added:
Compile and Test

  SPAD files for the functional world should be compiled in the
  following order::

    op  kl  function  funcpkgs  manip  algfunc
    elemntry  constant  funceval  COMBFUNC  fe

<pre>!\begin{axiom}
)abbrev category COMBOPC CombinatorialOpsCategory
++ Category for summations and products
++ Author: Manuel Bronstein
++ Date Created: ???
++ Date Last Updated: 22 February 1993 (JHD/BMT)
++ Description:
++   CombinatorialOpsCategory is the category obtaining by adjoining
++   summations and products to the usual combinatorial operations;
CombinatorialOpsCategory(): Category ==
  CombinatorialFunctionCategory with
    factorials : $ -> $
      ++ factorials(f) rewrites the permutations and binomials in f
      ++ in terms of factorials;
    factorials : ($, Symbol) -> $
      ++ factorials(f, x) rewrites the permutations and binomials in f
      ++ involving x in terms of factorials;
    summation  : ($, Symbol)            -> $
      ++ summation(f(n), n) returns the formal sum S(n) which verifies
      ++ S(n+1) - S(n) = f(n);
    summation  : ($, SegmentBinding $)  -> $
      ++ summation(f(n), n = a..b) returns f(a) + ... + f(b) as a
      ++ formal sum;
    product    : ($, Symbol)            -> $
      ++ product(f(n), n) returns the formal product P(n) which verifies
      ++ P(n+1)/P(n) = f(n);
    product    : ($, SegmentBinding  $) -> $
      ++ product(f(n), n = a..b) returns f(a) * ... * f(b) as a
      ++ formal product;

)abbrev package COMBF CombinatorialFunction
++ Provides the usual combinatorial functions
++ Author: Manuel Bronstein
++ Date Created: 2 Aug 1988
++ Date Last Updated: 14 December 1994
++ Description:
++   Provides combinatorial functions over an integral domain.
++ Keywords: combinatorial, function, factorial.
++ Examples:  )r COMBF INPUT



CombinatorialFunction(R, F): Exports == Implementation where
  R: Join(OrderedSet, IntegralDomain)
  F: FunctionSpace R

  OP  ==> BasicOperator
  K   ==> Kernel F
  SE  ==> Symbol
  O   ==> OutputForm
  SMP ==> SparseMultivariatePolynomial(R, K)
  Z   ==> Integer

  POWER       ==> "%power"::Symbol
  OPEXP       ==> "exp"::Symbol
  SPECIALDIFF ==> "%specialDiff"
  SPECIALDISP ==> "%specialDisp"

  Exports ==> with
    belong?    : OP -> Boolean
      ++ belong?(op) is true if op is a combinatorial operator;
    operator   : OP -> OP
      ++ operator(op) returns a copy of op with the domain-dependent
      ++ properties appropriate for F;
      ++ error if op is not a combinatorial operator;
    "**"       : (F, F) -> F
      ++ a ** b is the formal exponential a**b;
    binomial   : (F, F) -> F
      ++ binomial(n, r) returns the number of subsets of r objects
      ++ taken among n objects, i.e. n!/(r! * (n-r)!);
    permutation: (F, F) -> F
      ++ permutation(n, r) returns the number of permutations of
      ++ n objects taken r at a time, i.e. n!/(n-r)!;
    factorial  : F -> F
      ++ factorial(n) returns the factorial of n, i.e. n!;
    factorials : F -> F
      ++ factorials(f) rewrites the permutations and binomials in f
      ++ in terms of factorials;
    factorials : (F, SE) -> F
      ++ factorials(f, x) rewrites the permutations and binomials in f
      ++ involving x in terms of factorials;
    summation  : (F, SE) -> F
      ++ summation(f(n), n) returns the formal sum S(n) which verifies
      ++ S(n+1) - S(n) = f(n);
    summation  : (F, SegmentBinding F)  -> F
      ++ summation(f(n), n = a..b) returns f(a) + ... + f(b) as a
      ++ formal sum;
    product    : (F, SE) -> F
      ++ product(f(n), n) returns the formal product P(n) which verifies
      ++ P(n+1)/P(n) = f(n);
    product    : (F, SegmentBinding  F) -> F
      ++ product(f(n), n = a..b) returns f(a) * ... * f(b) as a
      ++ formal product;
    iifact     : F -> F
      ++ iifact(x) should be local but conditional;
    iibinom    : List F -> F
      ++ iibinom(l) should be local but conditional;
    iiperm     : List F -> F
      ++ iiperm(l) should be local but conditional;
    iipow      : List F -> F
      ++ iipow(l) should be local but conditional;
    iidsum     : List F -> F
      ++ iidsum(l) should be local but conditional;
    iidprod    : List F -> F
      ++ iidprod(l) should be local but conditional;
    ipow       : List F -> F
      ++ ipow(l) should be local but conditional;

  Implementation ==> add
    ifact     : F -> F
    iiipow    : List F -> F
    iperm     : List F -> F
    ibinom    : List F -> F
    isum      : List F -> F
    idsum     : List F -> F
    iprod     : List F -> F
    idprod    : List F -> F
    ddsum     : List F -> O
    ddprod    : List F -> O
    ddiff     : 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 works if we don't accidently use such a symbol as a bound of summation
-- or product 
    opfact  := operator("factorial"::Symbol)$CommonOperators
    opperm  := operator("permutation"::Symbol)$CommonOperators
    opbinom := operator("binomial"::Symbol)$CommonOperators
    opsum   := operator("summation"::Symbol)$CommonOperators
    opdsum  := operator("%defsum"::Symbol)$CommonOperators
    opprod  := operator("product"::Symbol)$CommonOperators
    opdprod := operator("%defprod"::Symbol)$CommonOperators
    oppow   := operator(POWER::Symbol)$CommonOperators
    opdiff  := operator("%diff"::Symbol)$CommonOperators


    factorial x          == opfact x
    binomial(x, y)       == opbinom [x, y]
    permutation(x, y)    == opperm [x, y]

    import F
    import Kernel F

    number?(x:F):Boolean ==
      if R has RetractableTo(Z) then
        ground?(x) or
         ((retractIfCan(x)@Union(Fraction(Z),"failed")) case Fraction(Z))
      else
        ground?(x)

    x ** y               == 
      -- Do some basic simplifications
      is?(x,POWER) =>
        args : List F := argument first kernels x
        not(#args = 2) => error "Too many arguments to **"
        number?(first args) and number?(y) =>
          oppow [first(args)**y, second args]
        oppow [first args, (second args)* y]
      -- Generic case
      exp : Union(Record(val:F,exponent:Z),"failed") := isPower x
      exp case Record(val:F,exponent:Z) =>
        expr := exp::Record(val:F,exponent:Z)
        oppow [expr.val, (expr.exponent)*y]
      oppow [x, y]

    belong? op           == has?(op, "comb")
    fourth l             == third rest l
    dvpow1 l             == second(l) * first(l) ** (second l - 1)
    factorials x         == facts(x, variables x)
    factorials(x, v)     == facts(x, [v])
    facts(x, l)          == smpfact(numer x, l) / smpfact(denom x, l)
    summand l            == eval(first l, retract(second l)@K, third l)

    product(x:F, i:SE) ==
      dm := dummy
      opprod [eval(x, k := kernel(i)$K, dm), dm, k::F]

    summation(x:F, i:SE) ==
      dm := dummy
      opsum [eval(x, k := kernel(i)$K, dm), dm, k::F]

    dvsum(l, x) ==
      k  := retract(second l)@K
[456 more lines...]

\start
Date: Wed, 22 Jun 2005 16:13:09 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#181 (5) -> random(0)

Expect a "library error but...
\begin{axiom}
random(0)
\end{axiom}

\start
Date: Thu, 23 Jun 2005 10:54:35 +0700 (NOVST)
From: Andrey G. Grozin
To: Bill Page
Subject: RE: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

On Wed, 22 Jun 2005, Page, Bill wrote:
> > This is unreasonable. The purpose to edit earlier input lines may
> > also rearrange the order of execution of the lines. Only the user
> > knows what order of execution is needed for his/her purpose.
> I disagree. Given Axiom's history of the commands that have already
> been executed and a list of the modifications to the input lines
> (contents of the browser page), it is quite possible to determine
> the minimum number and order of (re-)execution and/or execution of
> new commands that is required to compute a consistent state.
I disagree. Only the user can decide *which* consistent state [s]he wants.
Suppose there is a code fragment
n:=1
x:=f(n)
n:=2
y:=f(n)
Do you consider the state of Axiom after it inconsistent? I don't. This is 
an imperative language, after all. If the user edits the first line to 
read
n:=3
and then re-executes the second line, are you sure the user wants to 
re-execute the fourth line too? I am not. I'd hate it if the system would 
make such decisions for me.

\start
Date: Thu, 23 Jun 2005 00:50:36 -0400
From: Bill Page
To: Andrey G. Grozin
Subject: RE: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

On Wednesday, June 22, 2005 11:55 PM Andrey G. Grozin wrote:

> ...
> Only the user can decide *which* consistent state [s]he wants.
> Suppose there is a code fragment:
>
>   (1)   n:=1
>   (2)   x:=f(n)
>   (3)   n:=2
>   (4)   y:=f(n)
>
> Do you consider the state of Axiom after it inconsistent?
> I don't. This is an imperative language, after all.

I agree with you. The state of Axiom after executing this just
this sequence of commands would be consistent by definition.
"Consistent" means that the commands have been executed in the
order implied by their appearance on the page. I have added line
numbers such as (2) for reference.

Let's assume that f is defined as:

(0)  f:=operator 'f

   (0)  f
                                         Type: BasicOperator

then here is an actual example from Axiom:

(1) -> n:=1

   (1)  1
                                         Type: PositiveInteger
(2) -> x:=f(n)

   (2)  f(1)
                                         Type: Expression Integer
(3) -> n:=2

   (3)  2
                                         Type: PositiveInteger
(4) -> y:=f(n)

   (4)  f(2)
                                         Type: Expression Integer

(5) -> )display values
   Value of f: BasicOperator:  f
   Value of n: PositiveInteger:  2
   Value of x: Expression Integer:  f(1)
   Value of y: Expression Integer:  f(2)

The state of the computation is given by the output of the
)display command

> If the user edits the first line to read:
>
> (1)   n:=3
>

As soon as the user edits the first line, the current contents
of the page displayed page is no longer consistent with the
the current state of Axiom. In order to restore consistency
it is necessary to "roll-back" the sequence of calculations
and repeat some of the previously executed commands again,
beginning in this case is the first (1).

> and then re-executes the second line,

Yes I agree the second line (2) must be re-evaluated. Line
(3) will also have to be repeated because we have destroyed
the expected value of n by executing the revised line (1)
and it's old value must now be restored.

> are you sure the user wants to re-execute the fourth line
> too? I am not.

I agree with you. The fourth line (4) does not have to be
re-executed. It depends only on the value that n had when (3)
was first executed and n still has the value. So Axiom only
has to do the following:

(1) -> n:=3

   (1)  3
                                          Type: PositiveInteger
(2) -> x:=f(n)

   (2)  f(3)
                                           Type: Expression Integer
(3) -> n:=2

   (3)  2
                                           Type: PositiveInteger

(5) -> )display values
   Value of f: BasicOperator:  f
   Value of n: PositiveInteger:  2
   Value of x: Expression Integer:  f(3)
   Value of y: Expression Integer:  f(2)

And now the state of Axiom is consistent with the appearance of
the page again.

> I'd hate it if the system would make such decisions for me.

I don't understand. This is exactly the same decision that
you just said that you would have made.

\start
Date: Thu, 23 Jun 2005 01:24:06 -0400
From: Bill Page
To: Andrey G. Grozin
Subject: RE: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

On Thursday, June 23, 2005 12:51 AM I wrote:

> ...
> So Axiom only has to do the following:
>
> (1') -> n:=3
>
>    (1)  3
>                                           Type: PositiveInteger
> (2') -> x:=f(n)
>
>    (2)  f(3)
>                                           Type: Expression Integer
> (3') -> n:=2
>
>    (3)  2
>                                           Type: PositiveInteger
>

Actually I just made a small mistake. In fact line (3) does not
have to be re-executed as such. Since Axiom maintains a history,
all that we need to do is to restore it's value:

(3') -> n := %%(3)

where I have added the primes ' to emphasize that these commands
are being repeated (or as in the case of (3), restored).

Of course in this very simple example there is no significant
difference. But if line (3) happened to involve a very lengthy
calculation, it would be greatly to our advantage that we can
simply restore the value that is consistent with what is now
displayed on the page.

As Bob McElrath stated earlier, in a long and complex calculation,
it would be much better to be able to depend on the fact that the
machine is always going to do just the minimum that is required
in order to ensure that the state of Axiom is consistent with the
sequence of commands on the page. I have also sometimes found
myself in the situation that Bob describes where I seem to be
unable to reproduce a desired result displayed in my worksheet
simply because I have forgotten one critical link in the chain of
dependencies while making some side-attempt to solve some other
apparently unrelated problem. Of course one soon becomes suspicious
of this possibility and probably hits the !!! button to re-execute
the whole worksheet and then goes to lunch while the machine
tediously retraces all of it's steps... it seems a pity that we
have to waste machine resources on something like this.

\start
Date: Thu, 23 Jun 2005 02:34:33 -0400
From: William Sit
To: Bill Page
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

Bill:

This is Part II. Re-evaluation (focusing on what needs to be recomputed) and bad
2D editing in Maple

> Re-evaluation is a little different. It involves a
> series of operations (transactions) which have already altered the
> state of the program, i.e. a series of updates. Like this:
> 
>   (1) -> a:=1
>   (2) -> b:=a
>   (3) -> a:=2
>   (4) -> c:=a+b
>   ...
> 
> At the end of this sequence of commands the state of Axiom is
> given by
> 
>   )display values
> 
>    Value of a: PositiveInteger:  2
>    Value of b: PositiveInteger:  1
>    Value of c: PositiveInteger:  2

My understanding (and I actually run this in Axiom and Maple -- assuming the
code is Axiom code; or Maple if semicolons are added at the end) is $c$ should
have value 3, not 2. That is, the state of the identifier $a$ has changed, but
not $b$ when $c$ is computed. Perhaps this is just a typo in your last line
above?

(1) -> )set mess autoload off
(1) -> a:=1

   (1)  1
                                                        Type: PositiveInteger
(2) -> b:=a

   (2)  1
                                                        Type: PositiveInteger
(3) -> a:=2

   (3)  2
                                                        Type: PositiveInteger
(4) -> c:=a+b

   (4)  3
                                                        Type: PositiveInteger
(5) -> )display values
   Value of %: PositiveInteger:  3
   Value of %e:  (none)
   Value of %i:  (none)
   Value of %infinity:  (none)
   Value of %minusInfinity:  (none)
   Value of %pi:  (none)
   Value of %plusInfinity:  (none)
   Value of SF:  (none)
   Value of a: PositiveInteger:  2
   Value of b: PositiveInteger:  1
   Value of c: PositiveInteger:  3

> Now think of these commands, (1), (2), ... as editable text embedded
> inside an Axiom "worksheet" e.g. displayed on a page of the new
> AxiomUI browser. The user decides that they want to change command
> (2) to read:
> 
>   (2) -> b:=a+1
> 
> The simplest thing (but not the most efficient thing) for us to do
> in this case is just to scrap the state of the whole calculate
> 
>   )clear values all
> 
> (i.e. roll-back) then re-do all four commands again.
> 
>   (5) -> a:=1
>   (6) -> b:=a+1
>   (7) -> a:=2
>   (8) -> c:=a+b
> 
> This is what one must do now for example in Maple. There is even a
> special button labeled !!! that performs the ')clear all' (reset;)
> and re-execution in one click. (and then wait ... :).

In Maple 9 (on a Mac OS X), when I go to the second line and modify it to 

   b:=a+1;

Maple returns the answer b:=2 (leaving the old answer 1 below it).

Maple does not support 2D editing that well. The "wait" can be interrupted by
clicking on a menu bar item. In any case, lines (3) and (4) are not
re-evaluated, but the displayed result suggests that (1) is re-evaluated. Worst,
if I now move the cursor to line (4) and re-execute this, the value of $c$ is 4,
which means that $b$ is not re-evaluated when $a$ has changed. The means that
the definition of an identifier in Maple is tied to its *position* in the input
sequence! In other words, editing a previous line is *different* from
re-entering it with the same edited command. Yuck!
 
> A lazy re-evaluation on the other hand would recognize that after
> changing command (2) the minimum number of commands that need to
> be re-executed so that the state of Axiom is consistent with the
> revised browser page is just these two:
> 
>   (5) b:=%%(1)+1
>   (6) c:=a+b

The automation of this is exactly what I was afraid of. In your (and Maple's)
interpretation of the user's changing (2) b:=a  to (6) b:=a+1, it is assumed
that a total "roll back" is what the user has in mind. It did not take into
account what the next computation the user wants to do after this change.   In
Maple, if the user follows (4) with

  (5)' b:= a + 1         %% newly entered (semicolon omitted)
 
  (6)' c:= a+b           %% re-entered

Then the value of $b$ is 3, and of $c$ is 5 because $a$ is bound to 2 (same for
both Axiom and Maple). Axiom does not have 2D editing, fine. In Maple, if the
user now goes to (4) and re-execute, it gives the value 5 (so it is not a "roll
back", which would give 4). Very confusing in Maple. I don't want Axiom to
imitate that.

In Mathematica (using Set (=)  for :=), when (2) is changed to $b$ = a+1, b gets
the value 3, reflecting that $a$ has changed. If the user wants to do a roll
back, then it is easy to select all the cells involved and do a shift-enter,
which would give the final $c$ to be 4. This is very consistent and intuitive.
The control is in the hands (er fingers) of the user, not Mathematica. If Axiom
is to have a 2D input-editing capability, and I think this should be a high
priority, then I much prefer it to imitate Mathematica.

What you have illustrated with (5) is only that in computing:

  (1) a:=1
  (2) b:=f(a)   %% f is any previously or explicitly defined function of a

then it would be efficient to evaluate this as

  (1) a:=1
  (2) b:= f(%%(1))

to avoid re-evaluation of the right hand side of (1). But in Axiom, := is
immediate assignment, $a$ already is bound to the value of the right hand side
(evaluated). There is not much difference in efficiency between b:=f(%%(1)) and
b:= f(a) at the time (2) is executed; in neither case is the rhs of (1)
re-evaluated. 

The situation would be different if (1) is a == 1 instead. Then detecting that
the left hand side of (1) has not changed would perhaps save time.

> 
> > ...
> >>> [clip nice example]
> >> Bob McElrath wrote:
> >>> A user interface could choose to highlight out[1] as needs-
> >>> recomputing, or just go ahead and do it. (spreadsheet-style)
> >>
> >> I think it would be pretty neat if the browser could do such
> >> highlighting and very useful if with one click you could ask
> >> Axiom to minimally recompute just those comands that need
> >> re-computing. This should be quite easy in principle using the
> >> kind of AJAX techniques that Kai mentioned elsewhere. The hardest
> >> part would be writing the Axiom code that dynamically computes
> >> the dependency tree.
> >
> > Am I missing something here? Can't one simply use == and := to
> > achieve the same thing already?
> 
> I think you are *definitely* missing something ... :). I don't
> see what == and := have to do with this.

Consider the example below:

(1) -> a:=1

   (1)  1
                                       Type: PositiveInteger
(2) -> b==a
                                       Type: Void
(3) -> a:=2

   (3)  2
                                       Type: PositiveInteger
(4) -> c==a+b
                                       Type: Void
(5) -> c
   Compiling body of rule b to compute value of type PositiveInteger
   Compiling body of rule c to compute value of type PositiveInteger

   (5)  4
                                       Type: PositiveInteger
(6) -> b==a+1
   Compiled code for b has been cleared.
   Compiled code for c has been cleared.
   1 old definition(s) deleted for function or rule b
                                       Type: Void
(7) -> c
   Compiling body of rule b to compute value of type PositiveInteger
   Compiling body of rule c to compute value of type PositiveInteger

   (7)  5
                                       Type: PositiveInteger

I think Axiom does not recompute the identifier $a$ each time. I do not need
select cells (lines) to make Axiom (re-)evaluate what needs to be re-evaluated
to get $c$. It knows because I declared $b$ to be recomputed each time. Note
that in (6),  the code for $c$ is already cleared (and so is the code for $b$).
Axiom *knows* dependency, much better than Maple. But $b$ is not compiled in
(6). This is certainly lazy. They were only recompiled when I force the
evaluation of $c$ (but $b$ was automatically recomputed). Actually, for real
efficiency, there is no need to recompile $c$, only relinking.

Too bad that in Axiom, the following would not work, although in principle, it
should, with some higher level values on the rhs of assignments:

dpol == ODPOL FRAC INT
w == makeVariable('w)$dpol
w.5

Both == have to be replaced by :=. I don't know if this is a bug or not,

dpol:=ODPOL FRAC INT
w == makeVariable('w)$dpol
w.5

Even though w is defined, the system could not find the function w because the
interpreter is looking for w in a library!

But the following works.

dpol := ODPOL FRAC INT
w() == makeVariable('w)$dpol
w().5

So there is some subtle difference between w and w() after all.

[comment on MS Word, snipped] 
[below quotation moved out of sequence]
 
> > What may be needed and would be extremely helpful in terms of
> > user experience, is again what Mathematica allows: 2D editing,
> > with multiple selection of cells, not necessarily adjacent,
> > and then one shift-enter does it.
> 
> "Selection of cells" is essentially what Bob and I were discussing
> above that you seemed to "miss".

If that is all I missed, no problem. I did address this! However, I think you
missed something :-) about == and :=. In using macros or delayed assignment, the
identifier is recomputed each time. May be not by LRE, but Bob did not use the
term LRE above. See Part II on RE and Part III on LRE.

By using ==, I did not imply that the system should not cache repeatedly used
values. In a recursive definition of the fibonacci sequence,

f(1)==1
f(2)==1
f(n | n>2) == f(n-1)+f(n-2)

it would be mightily inefficient if the values are not cached in
[f(n) for n in 1..100]

> 
> > As I commented above, it is *not* Axiom's job to decide for me
> > what needs recomputing and what does not.
> 
> I disagree. To paraphrase what Bob wrote several emails earlier:
> "Why should it be necessary for me to do something complex
> like figuring out an efficient re-calculation sequence when
> this is something that a computer can do very easily?"

In my case, because *I* want to be in the driver seat. Also by being forced to
do so, I understand my algorithm much better. The resulting sequence of
computations will be part of my final algorithm which, for better or worse,
represents my best effort. No matter how efficient this re-calculation is done
by the system, I want a repeatable computation; LRE is not repeatable because it
depends on a history of interaction. See Part III on Maple.

This is not the same issue as efficient implementation of recursion, where I
would *definitely* want the system to handle it.
 
\start
Date: Thu, 23 Jun 2005 02:34:48 -0400
From: William Sit
To: Bill Page
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

Bill: 

This is Part IV: History, 2D editing


> [comments on using )history snipped]
> 
> > What is desirable in the interpreter interface, is the ability to
> > edit previous input lines in a 2D way. Mathematica allows it and
> > makes it very easy to do quick exploratory computations during the
> > development phrase.
> 
> 2-d editing might be possible if we can use mathML. In that case
> it is possible to select displayed 2-d sub-expressions, modify them
> with a few keystrokes (e.g. by typing the corresponding linear 1-d
> sub-expression). But in general wysiwyg equation editing is often
> awkward at best. And input of commands actually involves more
> semantics than what is normally explicit in the 2-d display. Both
> Maple and Mathematica have invested a great deal of effort in a user
> interface that (in principle) allows this. But even after all this
> effort, I really don't like to use it. I am too used to the "old" way
> of doing it, I guess - using a separate linear 1-d "input syntax"
> to type the commands.

You know what, I agree 100% with you on this. But you misunderstood my
interpretation of 2D editing (well I guess was not clear). I mean the ability to
edit "previous input lines in a 2D-way". This means being able to jump to (mouse
to?) an input line on screen, edit this in a 2D way (screen editing, like what
can be done even in vi). I do not mean the extra fancy things like selecting
subexpression from outputs! Yes, M and M allow that, but they don't work well
precisely for the reason you mentioned. (Derive did it really well).
 
> > The final order of execution can be done with cut and paste right
> > there on screen in the FrontEnd and there is no need to save the
> > history into a file first (because the interface *is* the editor
> > as well). Maybe an emacs or TeXmacs interface can do that?
> 
> The information in the history file is necessary if we want to
> perform lazy re-evaluation as I described above.

I would say a cleaned history file: only commands that were executed correctly
should be in the history file.

> >> These could be mapped to corresponding output areas in the
> >> browser.
> >
> > A browser (web browser) is not a text editor (yet). In fact, it
> > is probably undesirable to make a browser into an editor.
> 
> I disagree. Have you tried Kai's AxiomUI demo yet?

No. How?
I think you might have misunderstood my comment above. Why would any web site
(other than Wiki sites; commercial ones especially) allow users to edit a page?
Editing user inputs, yes, but that is different. Embedding an editor and giving
some real estate to it is not what I had in mind.
 
> > As nice as Wiki is, one still have to edit the source text, rather
> > than the rendered text.
> 
> That is true, but in most cases I would argue that this is *more
> efficient* then 2-d editing of the commands whose output generated
> some rendered mathematics.

I did not comment on editing output. I used "rendered text". I think it is more
efficient to be able to edit rendered text without resorting to a separate
region running an external editor (which allows screen (2D) editing). However,
that would not be desirable for other reasons.
 
> > In Mathematica, this would be like requiring editing the Notebook
> > file in text mode (which one *can* do, even on a cell-by-cell basis).
> > I can't imagine editing XML in text mode (I have tolerated editing
> > html, including those generated by MS Word or including Chinese, but
> > I think direct editing XML is not for me).
> 
> It is not expected that an AxiomUI user would edit XML markup. It
> is also likely that we can avoid almost all HTML except in the
> case of some complex page structures.

Sure, it is "not expected". But since when is it true that when things are
editable that it is not edited? They say the same thing when html first came
out. You know how big those html files are when generated automatically by MS
word? As I said, neither is Mathematica Notebook expected to be edited, but
occasionally, it is necessary, if only on a cell basis.

> > What may be needed and would be extremely helpful in terms of
> > user experience, is again what Mathematica allows: 2D editing,
> > with multiple selection of cells, not necessarily adjacent,
> > and then one shift-enter does it.
> 
> "Selection of cells" is essentially what Bob and I were discussing
> above that you seemed to "miss".

Glad we agree on the feature. But this editing feature is separate from, though
can be used for, the problem about re-evaluation.

> 
> > I would love to have Mathematica FrontEnd working for Axiom
> > (the best of both worlds). There are many many features of the
> > FrontEnd that are great and unparallelled (to name just a
> > few besides those already mentioned: all Notebooks are ASCII,
> > include editable input and output, graphics, incorporated style
> > sheets, independent of platform or operating systems, can be
> > converted into html, tex, etc; the entire Mathematica documentation
> > available, with live editable examples, and programmable using
> > FrontEnd commands).
> 
> Don't get me wrong: I think there are some very good things about
> both the Mathematica and Maple user interfaces. But user preferences
> for particular worksheet interfaces is a very subjective thing.
> Because of the high learning curves it is often dictated largely
> by one's individual experience and emotions like product loyalty
> (or the opposite of loyalty ;) which are often generated by intense
> intellectual investment. Disagreements on user interface design
> probably generates just as much or more "heat" then opinions
> about programming languages.
> 
There you have it. We agree to disagree.

\start
Date: Thu, 23 Jun 2005 02:34:26 -0400
From: William Sit
To: Bill Page
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

Bill: 

To avoid really long messages and also to focus on issues separately, I'll
answer yours in several less long ones. 

This is Part I: hyperdoc evaluations

"Page, Bill" wrote:

>  [information on lazy-evaluation, delayed-evaluation, lazy-re-evaluation 
    snipped]

Many thanks for a quick education on these.

> > The above delayed evaluation (which is automatically evaluated when
> > needed) only occurs *after* the SetDelayed or macro definitions have
> > been executed earlier (known the Axiom's run time system). This is
> > different from the hyperdoc browser, which may have only *read in*
> > the input file, but *not yet* run any assignment (delayed or otherwise).
> > This is like in Mathematica when the you read in a Notebook, commands
> > are not executed (unless marked as initialisation cells and the
> > system set to automatically run these on loading). Now if a user
> > *skipped* some assignments (delayed or otherwise) that, say, defines
> > x, y, and *jumped* to an assignment for z that involves x, y, normally
> > in the Axiom interpreter, the x, y would be treated as undefined symbols
> > and perhaps cause either a syntax error or a wrong evaluation. In
> > hyperdoc, the system will know whether x and y are free or bound
> > (because these are declared in the input file when it is built for
> > hyperdoc from regular input file), it knows to search for their
> > definitions and execute those assignments.
> 
> I don't see any difference in principle between a 'bound' variable
> in hyperdoc and a delayed evaluation in Axiom. In both case the
> definitions are "read-in" but not yet acted upon. It's just that
> this is occurring at a different level in the system. There is a
> difference however in the case where the command in Axiom is not a
> delayed evaluation. In effect in this case the value of a variable
> is being updated ("cached" i.e. stored) and should not have to be
> evaluated again.

There is a difference, at least, observed difference. In hyperdoc's case,
"read-in" means merely it was read in for the purpose of displaying it, not
"read-in" by Axiom (that is, hyperdoc has not passed the information to Axiom;
in Mathematica, that would be the FrontEnd has not passed the information to the
Kernel). If you try in the hyperdoc browser:

Examples->Domains->OrderlyDifferentialPolynomial and scroll down to the button
next to w.5, click it

then a new frame is started, and the buttons above the one clicked are examined
for dependencies to evaluate w.5, in this case, these are sent to the Axiom
frame for execution (now "read-in" *by Axiom*):

dpol := ODPOL (FRAC INT)
w:= makeVariable('w)$dpol
w.5

Note that the line 

z:= makeVariable('z)$dpol

which has a button and placed right after the second line above and before the
third line (w.5) above in hyperdoc page, is *not* passed to Axiom Interpreter.
Indeed, if you now type

z 

in the frame, you get

(4) z      Type: Variable z

Now I don't think this is anything sophisticated to implement (these are short
files, so efficiency is not a problem, we can do a brute force search for
dependencies), but it is not entirely trivial either, and makes it convenient
for the user to be able to click any button without worrying about omitting some
buttons in a sequence. It is the equivalent of selecting a sequence of (perhaps
non adjacent) cells to execute except that the selection is automatic.

> > So the hyperdoc action, as I understand it, is unrelated to
> > "lazy re-evaluation" of the first paragraph.
> 
> That is correct. 

I would now revise my statement:

So the hyperdoc action, as I understand it, is unrelated to
"lazy evaluation" of the first paragraph since all it does is selecting a subset
of commands to pass onto Axiom.

\start
Date: Thu, 23 Jun 2005 02:34:41 -0400
From: William Sit
To: Bill Page
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

Bill:

This is Part III. History, and Lazy Re-evaluation

> >> Should this be a front-end browser function or a back-end Axiom
> >> function. For example a function in Axiom might be able to return
> >> the list of input history numbers of those commands that need to
> >> be re-executed.
> >
> > This is unreasonable. The purpose to edit earlier input lines may
> > also rearrange the order of execution of the lines. Only the user
> > knows what order of execution is needed for his/her purpose.
> 
> I disagree. Given Axiom's history of the commands that have already
> been executed and a list of the modifications to the input lines
> (contents of the browser page), it is quite possible to determine
> the minimum number and order of (re-)execution and/or execution of
> new commands that is required to compute a consistent state.
> 

First, as I pointed out previously, Axiom's history command does not
discriminate between syntax-valid and syntax-invalid commands, nor does it know
whether some commands as just for "testing the water" purposes. The user must,
after saving the input lines, editing the file. Axiom can be modified to remove
the syntax-invalid lines, but it still has no way to know the intention of the
user.

What you have in mind is not for a browser interactive session. Rather, if the
action involved is 

(1) read an input file and run it
(2) after seeing the results and not satisfied, use an external editor     to
modify the input file
(3) read the edited input file and run it

This is the full "roll back" model. This setting separates the issue of LRE from
browser-editing issues (I think these are separate and independent issues; Maple
confuses the two, see Part II). This does not forbid editing done within the
same browser, as long as it is a separately spawned process (much like editing
Wiki pages now). Then I would agree that Axiom may be able to detect the
difference and perform lazy-re-evaluation.

In your example, say the first input file (labels not part of the input) is:

(1) a:=1
(2) b:=a
(3) a:=2
(4) c:=a+b

where $c$ gets the value 3, and the edited file is

(1') a:=1
(2') b:=a+1
(3') a:=2
(4') c:=a+b

where $c$ gets the value 4. In running the edited input file, if
lazy-re-evaluation (LRE) is applied, one has to decide whether the (1') is
re-executed. This depends on whether Axiom cached the rhs of (1). Now at the
time (1) is run, is there any reason for Axiom to cache the rhs of (1)? I would
say no. (Note, caching the rhs of (1) is not the same as bounding $a$ to the rhs
of (1); in bounding, there is no way to get to the rhs of (1) again without
re-evaluation. Referencing $a$ is not an option because $a$ may have been
rebound by the time (1') is executed.)

Assuming that, then there has to be a switch to instruct Axiom to cache or not
to cache rhs. Let's continue and assume that the rhs of (1) is cached and say
(1') is done by LRE, that is, $a$ is rebound to 1, without re-evaluating the rhs
of (1). The rhs of (2') is now recompiled and evaluated, binding $b$ to the
value 2.
(3') is also done by LRE. Now it gets interesting. (4') is the same as (4). So
accordingly, one may be tempted to use LRE, that is, used the cached value of
the rhs of (4), which is 3. But that is clearly wrong. So the LRE algorithm must
not just cache the value of rhs, but also track dependencies and the states. It
must determine that the $a$ on the rhs of (4') is the same as the $a$ of (4),
which means that a *history* of $a$ be maintained, not just the current state.
That is, it must know from (3) and (3') that the two $a$ at different times have
the same value. Similarly, it must know that the two $b$ in (4) and (4') have
different values. 


This is a very simple example. In more complicated situations, the value of $b$
may have been rebound as side-effects (as in (2) and (2') having the form
d:=f(a,b)). Not only must the LRE algorithm detect these situations, it must
also maintain other commands the user made in between the two reads, which could
also have modified some of the varibles explicitly appearing in the input files.
There is obviously trade off between this overhead on recomputations.
Experts in LRE probably have all this figured out, but to a casual user, who
most likely would not understand this behind the scene actions, the displayed
results may be very baffling and confusing (Maple is such an example already,
and we have seen lots of examples in Axiom due to lack of understanding of
types).

As far as users are concerned, most need not know the details of implementation
or how the results are arrived at, as long as they are what are expected. I
think this is a very important design principle for user interfaces.

In developing a final input file that may be used again and again with minor
changes to embedded parameters, the user wants an environment that each time the
input file is run, whether this is from a fresh session or during the middle of
one, the results should be identical to one from a fresh session. The easiest
way to assure this is to include ")clear all" at the beginning of the file,
which would defeat most of the advantages or efficiency gains by LRE.

\start
Date: Thu, 23 Jun 2005 03:39:34 -0400
From: Bill Page
To: Martin Rubey
Subject: Vicious circles (was: More AxiomUI)
Cc: Kai Kaminski, Bob McElrath

I think this discussion of Aldor's "post facto extension"
mechanism is directly related to the issues of circular
dependencies and Mutual Recursion in the Axiom libraries
that we discussed some months ago. See for example:

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

On Wednesday, June 22, 2005 1:43 PM Martin Rubey wrote:
> ...
> In fact, this is also a question of future direction, since I
> hope very much that Aldor will become *the* language for Axiom.
> ...
> William Sit writes:
>> 
>> What features of Aldor do you want to add to Axiom?
>
> A clear grammar, dependent types, post-facto extensions, and all
> the splendid algorithms available in the libraries distributed
> with aldor.
> ...
>> a direct coercion between two domains of the same category is
>> by design, I think, not practical. Domains may differ by their
>> mathematical meaning, but even if they do not, they differ by
>> their data structure (and hence implementation). When a domain
>> is constructed, it should not be required to be aware of other
>> domains in the same category (providing coercion would), because
>> for one thing, it may be the first. Thus such a requirement
>> would require constant updating of all older domains that in
>> principle are coercible to other "younger" ones. Note that by
>> the same reasoning, only a younger domain can be CoercibleTo an
>> older domain, not the other way round. (By making CoercibleTo
>> go the other way would make "older" become the "younger").
>
> Part of this problem is solved (in a fine manner) by post-facto
> extensions, described in the Aldor user guide.
>

Reference:

ALDOR Compiler User Guide,
Chapter 10: Post facto extensions

http://www.aldor.org/docs/HTML/chap10.html

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

In Axiom this "problem" of mutual recursion and circular dependencies
still exists. Axiom has a very large number of algebra domains,
categories and packages (over 1,000) which over time with each new
extension have grown more and more tightly inter-related. The
graph of dependencies between these modules contains more that
30,000 directed edges. As Tim discussed way back in the early
days of the open source Axiom project, this graph contains many
loops and so these modules can not be topologically sorted into
a partial ordering that allows a single execution pass which will
produce consistent compiled code.

As an interim measure Tim designed a "lisp bootstrap" into the
current Axiom build process. A relatively small number domains and
packages (about 30) have been coded in both lisp and in the Spad
language. The set of 30 modules have been chosen so as to break
all of the circular dependencies in the Axiom library. These
modules are initially compiled directly from the low level lisp
code. Then all of the dependent domains and packages are compiled
from the Spad source code in a series of "layers" which do not
contain any cycles. Finally the original 30 bootstrap modules
are also re-compiled from their Spad sources. And the result is
a runnable Axiom system.

Remarkably perhaps, it turns out that this bootstrap procedure
is not sufficient to produce completely consistent code for
all of the Axiom modules. When one compares the intermediate
lisp code that is generated from the first pass of compilation
of the Spad sources to the lisp code generated by a second pass
one discovers that there a small number of modules (about 10)
in which the generated lisp code changes from one iteration to
the next. These changes are not trivial changes such as non
semantic changes in the names of internal symbols, but rather
involve actual changes in the detailed lisp logic generated by
the Spad compiler. It currently takes 3 complete re-build
iterations before the lisp code generated between iterations
reaches a "fixed point".

A preliminary (but incomplete) analysis of these changes was done
by Steve Wilson, Tim Daly and me. Our conclusions was that most
(maybe all?) of changes that we could trace involved additional
optimizations done by the Spad compiler based on the more complete
information on other domains in the various loops that become
available as each re-compilation iteration takes place. So far
we have not found any cases were the detectibly different results
are computed by the code modified (optimized?) but the iterations,
although in some cases bounds on the maximum size of index
variables do change because the compiler makes different choices
regarding data types (for example machine integers instead of
infinite precision integers).

At the present time only the Windows binary versions of Axiom
have been compiled to the "fixed point". The make script for
the Linux versions and for Windows source code version performs
only one iteration of the algebra compiles.

----------

In any case, the reason that I reviewed all this here is because
I think it relates to the problem discussed by Martin and William
above. It seems likely that the mechanism of post facto extension
in Aldor was conceived partly in response to the designer's
experience with the complex dependency structure of the Axiom
algebra library.

The issue of object-oriented programming and type inheritance
has recently been re-consider by


who seem to reach similar conclusions to those of the original
Axiom developers: the conventional type inheritance rules of
(most) modern hierarchical object oriented programming languages
is not really adequate for programming mathematical algorithms.
See for example:

"Approaching Inheritance from a "Natural" Mathematical Perspective
and from a Java Driven Viewpoint" by Marc Conrad, Tim French,
Carsten Maple, and Sandra Pott

http://page.axiom-developer.org/zope/Plone/refs/articles/McTfCmSp-axiom.pdf/
view


"Mathematical Use Cases lead naturally to non-standard Inheritance
Relationships" by Marc Conrada, Tim French, Carsten Maple and
Sandra Pott

http://page.axiom-developer.org/zope/Plone/refs/articles/m_conrad-axiom.pdf/
view

--------

In fact I think Axiom already implements this same sort of post facto
extension of domains, al beit in a less well-structured way by
exploiting mutual recursion and circular dependencies. The bootstrap
mechanism developed by Tim seems to provide just enough "pre-facto"
information in the Axiom bootstrap so that the post-facto extension
is (probably?) is not needed.

It may come as a surprise to some people that it is possible at all,
in principle, to compile consistent computer code from what amounts
to essentially circular definitions. This might be especially worrisome
in the context of a *mathematical* software system such as Axiom
since it seems to suggest that Axiom's implementation of the mathematics
might somehow be fundamentally flawed and could be at least formally
not well-founded. It seems however that some mathematicians have
had some new ideas bout this sort of circular dependency and non-
well foundedness just in time for possible application to Axiom.

The book "Vicious circles: on the mathematics of non-well-founded
phenomena" by Jon Barwise and Lawrence Moss, Publisher: Center for
the Study of Language and Inf. (August 4, 2004).

"Circular analyses of philosophical, linguistic, or computational
phenomena have been attacked on the assumption that they conflict
with mathematical rigor. Barwise and Moss have undertaken to prove
this assumption false. This volume is concerned with extending the
modelling capabilities of set theory to provide a uniform treatment
of circular phenomena. As a means of guiding the reader through
the concrete examples of the theory, the authors have included many
exercises and solutions: these exercises range in difficulty and
ultimately stimulate the reader to come up with new results. Vicious
Circles is intended for use by researchers who want to use hypersets;
although some experience in mathematics is necessary, the book is
accessible to people with widely differing backgrounds and interests.

The following partial table of contents shows that it deals with
many issues that are potentially applicable to Axiom's algebra
library and computer algebra in general.

2. Background on set theory
3. Circularity in computer science
4. Circularity in philosophy
5. Circularity and paradox
6. The solution dilemma
7. Bisimulation
8. Graphs
9. Modal logic
10. Streams
11. Games
12. Modeling the semantic paradoxes
13. Greatest fixed points
14. Uniform operators
15. Corecursion 

---------

While I have to agree that the Aldor probably represents a significant
technical advance in terms of compiler design over the older library
compiler that is built-in to Axiom, I am not yet completely satisfied
that Aldor necessarily provides a complete solution to problems of
dealing with the complex circular dependencies in the Axiom algebra
library. The flexibility that is inherent in the current less
structured approach to building Axiom's library code might very well
be one factor that has contributed to the remarkable breadth of
mathematical knowledge that is captured in this computer code. If
we move to a more rigorous and formally structured library compiler
language such as Aldor, will we be giving up some important features
of Axiom's design (accidental or not as it may or may not be) just
because we do not quite understand yet how to formalize it?

\start
Date: Thu, 23 Jun 2005 04:04:18 -0400
From: William Sit
To: Bill Page
Subject: Re: Consistency (was Lazy Evaluation)
Cc: Kai Kaminski

"Page, Bill" wrote:
> 
> On Wednesday, June 22, 2005 11:55 PM Andrey G. Grozin wrote:
> 
> > ...
> > Only the user can decide *which* consistent state [s]he wants.
> > Suppose there is a code fragment:
> >
> >   (1)   n:=1
> >   (2)   x:=f(n)
> >   (3)   n:=2
> >   (4)   y:=f(n)
> >
> > Do you consider the state of Axiom after it inconsistent?
> > I don't. This is an imperative language, after all.
> 
> I agree with you. The state of Axiom after executing this just
> this sequence of commands would be consistent by definition.
> "Consistent" means that the commands have been executed in the
> order implied by their appearance on the page. I have added line
> numbers such as (2) for reference.

I don't agree that consistency is a desirable feature for a 2D editable
interface. But for the sake of discussion, in this model, the screen is an
infinitely long sheet and the location where one enters or edits a command line
is important. 

But why don't we separate the issue of lazy re-evaluation from the editing and
display issues? I would prefer to visualize the state of the screen as a batch
file. After editing this batch file (don't care how), you want to minimize the
recomputation so that the results are as if the batch has been re-executed from
the beginning to end in a fresh session. So this is the full roll back model I
discussed in Part III.


By definition, when a batch file is run, the system is consistent.

> > If the user edits the first line to read:
> >
> > (1)   n:=3
> >
> 
> As soon as the user edits the first line, 
> the current contents
> of the page displayed page is no longer consistent with the
> the current state of Axiom. 

This is temporary, and has nothing to do with LRE. If you run the new batch
again, it would be consistent. The problem is not restoring consistency, but
rather deciding what computations may be avoided, if the system cached the rhs
values.

> In order to restore consistency ... [what to re-evaluate snipped]

If the LRE algorithm is clever, then it need not evaluate (3') and(4') but
evaluate the rhs of (1') without binding it to n, evaluate only f at the result,
and binding that to x without changing the state of n (which remain having a
value of 2), and display the rest (or leave them alone).


> And now the state of Axiom is consistent with the appearance of
> the page again.
> 
> > I'd hate it if the system would make such decisions for me.
> 
> I don't understand. This is exactly the same decision that
> you just said that you would have made.

Come to think of it, that is what spreadsheet did all the time. (Now I get the
connection to spreadsheet).

It should not matter to the user how LRE works and I would now agree that LRE
has a role to play. However, this should be done for batch mode files, not
interactively on screen, because then each edited line will cause the system to
maintain consistency, causing unnessary re-evaluation perhaps. In the roll back
model, the user is only concerned with the results of a batch file. In the
interactive environment, there should be a button to activate re-evaluation
(much like a spreadsheet) and an option to have this as default or not.

If the user makes substantial editing, including rearranging order of lines, it
would make LRE harder. Also, if a user is simply exploring some what-if
situation, the system automated changes in related values may not be desirable
when these are statically bound. In general, I do not like that the result of a
command depends on its screen location.

\start
Date: Thu, 23 Jun 2005 03:20:34 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#182 Floating point error round(-3.77623) etc.]

earlier versions of axiom gave::

  round(3.77623) => 4 
  round(-3.77623) => -5 ** wrong!

This was fixed by Dylan with [Patch #2074] :
\begin{axiom}
round(3.77623)
round(-3.77623)
\end{axiom}

\start
Date: Thu, 23 Jun 2005 03:28:25 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#180 bug #9216 differentiating sums with respect to a bound is wrong] Old Discussion

> >  > #3148:  bug #9216 differentiating sums with respect to a 
> > bound is wrong [A]
> > 
> > in my opinion correct beyond doubt.
> 
> In the patch report you wrote:
> 
> "Mathematically axiom produces correct output now, however
> I'm not sure whether my patch is best possible.
> 
> Maybe there should be a function D in OutputForm that displays
> unevaluated differentiation. Also, I find it ugly to use the
> raw %diff operator in COMBF. Furthermore, is it necessary to
> substitute a dummy variable for the variable of differentiation?"
> 
> I am concerned that this is another case of a "quick fix" for
> which we should consider a more general solution of the kind
> that you suggest above.

In this case the situation is a tiny little bit different, since here also 
Axioms internal representation is wrong. Worse: the design of Axioms Algebra 
currently doesn't provide "unevaluated differentiation". Obviously, it was 
thought that anything can be differentiated. In fact, I'm almost sure that 
attempting to differentiate a sum by one of its bound should signal an error, 
because it is impossible to assign a mathematically correct meaning to it. In 
this sense, I'd suggest that we aim to reach consensus until end of January.

\start
Date: Thu, 23 Jun 2005 03:39:04 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#183 #3161: any? and every? should exit when the result is clear ] (nouveau) 

> >  > #3161:  any? and every? should exit when the result is clear [A]
> > 
> > I don't have the time to look it up right now, whether the 
> > "mixed" behaviour TREE would vanish with this patch or not.
> > In any case, this "bug" will never produce mathematically
> > incorrect results. It will only waste cpu cycles.
> 
> Can we be sure that functions applied during evaluating 'any?'
> and 'every?' are not being executed for their side-effects?
> I worry that changing the semantics here could have unexpected
> effects in other places in Axiom where 'any?' and 'every?' are
> used.
> 
> > In fact, I included the comment regarding TREE only to document 
> > that if there would be code that depends on the "evaluate all"
> > code, it wouldn't work with TREE anyway, so it would be broken
> > already. Bottom line: no danger.
> 
> I am not convinced. I think this needs more analysis, i.e. look
> at each case were 'any?' and 'every?' are actually used or else
> we have to be prepared to do a lot of testing.

I did some analysis and I'm quite sure that no code will be broken. However, 
this is a patch I won't push, since it won't produce incorrect results. 

\start
Date: Thu, 23 Jun 2005 03:54:02 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#183 #3161: any? and every? should exit when the result is clear ] 

any? and every? should exit when the result is clear.

As discussed in the thread starting with
http://lists.gnu.org/archive/html/axiom-developer/2004-06/msg00196.html
I believe that the following behaviour of 'any?' and 'every?' is bad, because things are computed unnecessarily::

\begin{axiom}
any?(i+->(output(i);(i=1)::Boolean),[1,2,3])
\end{axiom}
 
The attached patch fixes this for HOAGG and CLAGG in 'aggcat.spad'. This makes axioms behaviour more consistent also: in TBAGG, A1AGG, ARR2CAT, LZSTAGG the functions are done as in the patch, in TREE a mixed behaviour is exhibited (and should be fixed)
 
Martin

Bill wrote:

Can we be sure that functions applied during evaluating 'any?'
and 'every?' are not being executed for their side-effects?
I worry that changing the semantics here could have unexpected
effects in other places in Axiom where 'any?' and 'every?' are
used.


Martin replied:

In fact, I included the comment regarding TREE only to document 
that if there would be code that depends on the "evaluate all"
code, it wouldn't work with TREE anyway, so it would be broken
already. Bottom line: no danger.


Bill replied:

I am not convinced. I think this needs more analysis, i.e. look
at each case were 'any?' and 'every?' are actually used or else
we have to be prepared to do a lot of testing.

Martin replied:

\start
Date: Thu, 23 Jun 2005 03:38:41 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#8 (Savannah bug #9297) output misses some parenthesis] 

summation(i^2, i=a..b)^(d-c+1)

I also would like to add that the obvious mathematical blunder in 

\begin{axiom}
product(summation(i*j, i=a..b),j=c..d)
\end{axiom}

should be fixed in axiom--main--1--patch-25.

\start
Date: Thu, 23 Jun 2005 03:03:20 -0700
From: Bob McElrath
To: William Sit
Subject: Re: Consistency (was Lazy Evaluation)
Cc: Kai Kaminski

William Sit [William Sit] wrote:
> Come to think of it, that is what spreadsheet did all the time. (Now I get the
> connection to spreadsheet).

I think that is the best analogy.  Mma/Maple are really a poor editor
interface for dispatching out-of-order commands to a behind-the-scenes
kernel.  Their kernels (and axiom's) are best viewed as a batch system.

But (I think) the front-end might be better viewed like a spreadsheet.

> It should not matter to the user how LRE works and I would now agree that LRE
> has a role to play. However, this should be done for batch mode files, not
> interactively on screen, because then each edited line will cause the system to
> maintain consistency, causing unnessary re-evaluation perhaps. In the roll back
> model, the user is only concerned with the results of a batch file. In the
> interactive environment, there should be a button to activate re-evaluation
> (much like a spreadsheet) and an option to have this as default or not.

I completely agree.  I would personally mark output blocks when it is
known that they need to be re-evaluated.  An option could turn on forced
re-evaluation.  Personally, I would not turn that on...but students
working on relatively simple worksheets would probably like it.  Also I
think each output block should keep timing information.  The kernel
could intelligently decide not to re-evaluate something that took 10
minutes last time, but go ahead and re-evaluate things that took 10 ms
last time.

I've had a visual of a CSS <div> in a browser, and just turning the
background pink, with a little "re-evaluate" button in the UR corner,
and a "re-evaluate all" button somewhere in the interface.

> If the user makes substantial editing, including rearranging order of lines, it
> would make LRE harder. Also, if a user is simply exploring some what-if
> situation, the system automated changes in related values may not be desirable
> when these are statically bound. 

After substantial editing is also when humans tend to fail to figure out
what needs to be re-executed.  If the whole sheet is red because the
user rearranged everything, then so be it.  It all needs to be
re-evaluated.  A human cannot figure out dependencies any better than we
could, algorithmically.

There is nothing a human knows about state that we cannot determine by
looking at the sequence of commands.

> In general, I do not like that the result of a command depends on its
> screen location.

This is in violent opposition to the example suggested earlier by
Andrey:
    n:=1
    x:=f(n)
    n:=2
    y:=f(n)
A perfectly reasonable thing to do, and the result *absolutely* depends
on screen location.

A worksheet is read from top to bottom, as a document, not a
batch-system-dispatcher.  As a document, it should make sense if I read
it in order.  The idea that a command's result is independent of its
screen location forces the user to keep considerable state information
in his head.  By putting the state information into the document, in
order from top to bottom, the user is freed from having to keep *any*
state information in his head, because he can simply read it off the
document.

\start
Date: Thu, 23 Jun 2005 05:56:50 -0400
From: William Sit
To: Bill Page
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

"Page, Bill" wrote:

> Of course in this very simple example there is no significant
> difference. But if line (3) happened to involve a very lengthy
> calculation, it would be greatly to our advantage that we can
> simply restore the value that is consistent with what is now
> displayed on the page.
> 

I think LRE is a double edge sword. Consider the example below:

(1) n:=2
(2) x:=f(n)
(3) n:=n+1
(4) y:=g(n)


Suppose f is a very expensive (or even outside the ability of the machine)
function to compute if n is 3, say f(n) = 2^(2^(2^(2^n))), and g is a simple
one, like n^2. Suppose further that I want to keep the value of x at f(2). If I
change the first line to n:=3 what would LRE do? It would re-execute line (2) to
evaluate the expensive f(3) and probably never get to reevaluating (3) and (4).
If I were able to manually select the sequence of recomputation, I would be able
to just re-executive (1), (3) and (4).

Of course in this simple example, I may be able to rearrange the code to get
around LRE recomputing x (like inserting n:=2 after (2) and editing that
instead), but why should I?


> As Bob McElrath stated earlier, in a long and complex calculation,
> it would be much better to be able to depend on the fact that the
> machine is always going to do just the minimum that is required
> in order to ensure that the state of Axiom is consistent with the
> sequence of commands on the page. I have also sometimes found
> myself in the situation that Bob describes where I seem to be
> unable to reproduce a desired result displayed in my worksheet
> simply because I have forgotten one critical link in the chain of
> dependencies while making some side-attempt to solve some other
> apparently unrelated problem. Of course one soon becomes suspicious
> of this possibility and probably hits the !!! button to re-execute
> the whole worksheet and then goes to lunch while the machine
> tediously retraces all of it's steps... it seems a pity that we
> have to waste machine resources on something like this.
> 
> Regards.
> Bill Page.

I certainly have such experience as well. But I have also experienced the other
side: I have selected to re-evaluate the entire sequence only to notice that
there is one very long computation that I do not want to re-evaulate because I
had changed the size of the computation (like n:=3 above) and the only recourse
I have is to cancel the evaluation and then select only the ones I want to do.
Occasionally, the computation cannot be stopped and such attempt even cause the
program to crash (of course without saving first).

So I think if LRE is available, it should not be automatic and the control to
use it or not should remain the choice of the user. Neither is consistency a
must.

\start
Date: Thu, 23 Jun 2005 05:16:25 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#180 bug #9216 differentiating sums with respect to a bound is wrong] Mail from Manuel Bronstein

Hello,

I finally took at look at your patch 3148 on dvdsum.
Your changes to dvdsum are fine, however the lines::

+    ddiff l ==
+      prefix(sub(D::O, third(l)::O), [eval(first(l), second(l), third(l))::O])
+
and
+    setProperty(opdiff, SPECIALDISP, ddiff@(List F -> O) pretend None)

should be removed from the code: this property is being set in fspace.spad
already, and you are duplicating that code (with differences). Each source
file initializes the properties of the operators that it is particularly
responsible for. CommonOperators() ensures that the operators are shared by 
the clients, so the opdiff you are getting in combfunc.spad will have its
SPECIALDISP property set by fspace.spad at some point before it ever gets
displayed.

Sorry that I don't know how to update your patch on savannah, I would have
done so directly otherwise.

\start
Date: Thu, 23 Jun 2005 03:08:44 -0700
From: Bob McElrath
To: Andrey G. Grozin
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

Andrey G. Grozin [Andrey G. Grozin] wrote:
> I disagree. Only the user can decide *which* consistent state [s]he wants.
> Suppose there is a code fragment
> n:=1
> x:=f(n)
> n:=2
> y:=f(n)
> Do you consider the state of Axiom after it inconsistent? I don't. This is 
> an imperative language, after all. If the user edits the first line to 
> read
> n:=3
> and then re-executes the second line, are you sure the user wants to 
> re-execute the fourth line too? I am not. I'd hate it if the system would 
> make such decisions for me.

You have done two things:
1) edit a line
2) re-evaluate an *un-edited* line

With lazy re-evaluation, (2) would never be needed.  (and in fact,
doesn't make sense because the output would always be identical)

When I have said inconsistent, I mean that if I re-execute the commands
in order, I get something different than currently appears as output in
the worksheet.

In fact perhaps the concept of "executing" a block should go as well.
There would only be a concept of "done-editing" a block, at which point
the interface would go evaluate whatever was necessary.  One would never
go back and re-evaluate something unless an edit was made on *that*
line.

\start
Date: Thu, 23 Jun 2005 05:54:45 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#180 bug #9216 differentiating sums with respect to a bound is wrong]

  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. The fix I propose is thus

\start
Date: Thu, 23 Jun 2005 05:52:58 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#180 bug #9216 differentiating sums with respect to a bound is wrong]

  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. The fix I propose is thus

<a href="dvdpatch2.patch">dvdpatch2.patch</a>


??changed:
-+    ddiff l ==
-+      prefix(sub(D::O, third(l)::O), [eval(first(l), second(l), third(l))::O])
-+
-and
-+    setProperty(opdiff, SPECIALDISP, ddiff@(List F -> O) pretend None)
  +    ddiff l ==
  +      prefix(sub(D::O, third(l)::O), [eval(first(l), second(l), third(l))::O])
  +

and::

  +    setProperty(opdiff, SPECIALDISP, ddiff@(List F -> O) pretend None)

\start
Date: Thu, 23 Jun 2005 06:51:38 -0400
From: William Sit
To: Bob McElrath
Subject: Re: Consistency (was Lazy Evaluation)
Cc: Kai Kaminski

Bob McElrath wrote:

  William Sit wrote:
> > In general, I do not like that the result of a command depends on its
> > screen location.

> A worksheet is read from top to bottom, as a document, not a
> batch-system-dispatcher.  As a document, it should make sense if I read
> it in order.  The idea that a command's result is independent of its
> screen location forces the user to keep considerable state information
> in his head.  By putting the state information into the document, in
> order from top to bottom, the user is freed from having to keep *any*
> state information in his head, because he can simply read it off the
> document.
> 

I don't disagree that most *finished* worksheet read from top to
bottom, and the commands run from top to bottom, but that need not be
the norm. Document is a good analogy: modern documents are not linear,
because we now have hyperlinks; we can, and want to, skip around! A
program is the same, the code need not be linear in structure: we may
have parts A, B, C in parallel followed by D that depends on A, B, C;
code can even have a circular structure (like Axiom
domains). Compilers do code optimization by exploring the non-linear
structure of the code.

During development of this final product, just like writing any essay,
we gather together ideas, pieces, expand them, rearrange them, put
them into sections, chapters. Until the document is finished, it is
*not* consistent! The state of consistency is approached only
gradually. So in developing a computation worksheet, as I often do in
Mathematica, I start with exploratory routines, test ideas, revise,
expand, change, etc and finally reorganizing this into a logical
sequence of commands. The entire sequence is not necessarily linearly
ordered, as the location of some functions (especially those defined
with SetDelayed, which I would consider as library functions) are
unimportant except for grouping into some theme. The main executable
(using immediate assignments) sequence would be linear mostly.

 Why should I need consistency during the development? If I am only
working on one single subroutine, why shouldn't I be able to test this
in isolation? If I keep track of dependencies with SetDelayed, there
is no need to worry about the eventual consistency. Even if I can
place code in a linear space order, why can't I prefer just a linear
logical order? All I need is consistency of the final code, which if
it works, is automatic.

For developers, it is the revision cycle that is time consuming. I
would like to have all the freedom available.

\start
Date: Thu, 23 Jun 2005 13:23:08 +0200
From: Martin Rubey
To: Bob McElrath
Subject: Re: Consistency (was Lazy Evaluation)
Cc: Kai Kaminski

Bob McElrath writes:

 > I would personally mark output blocks when it is known that they need to be
 > re-evaluated.  

I think I like this idea.

 > An option could turn on forced re-evaluation.  Personally, I would not turn
 > that on...but students working on relatively simple worksheets would
 > probably like it.  Also I think each output block should keep timing
 > information.  The kernel could intelligently decide not to re-evaluate
 > something that took 10 minutes last time, but go ahead and re-evaluate
 > things that took 10 ms last time.

Well, that's ok too, but I'd turn it off...

\start
Date: Thu, 23 Jun 2005 06:29:13 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#114 Map on Functions crash] 

This problem does not occur on the NAG version::

  !\begin{axiom}
  dom:=(INT->INT)
  g(f:dom):dom== x+->(f(x))^2
  p(x:INT):INT == x-1
  \end{axiom}

The next line crashes Axiom. (Here the crash is indicated by not
showing the result for <code>q</code> which should be something like
<code>theMap(LAMBDA_ibs3ze_708.174)</code> (from NAG version)::

  !\begin{axiom}
  q:= g p
  \end{axiom}

\start
Date: Thu, 23 Jun 2005 13:28:59 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

Axiom also allows to do something like that...
What should the line (6) f(n) return after a user modified line (5) to
n:=3? Will f(n) return 6 or 7? And what did the user expect?

Ralf

(1) -> k:=1

    (1)  1
                                                         Type:
PositiveInteger
(2) -> f(n)==(free k; k:=k+1; n+k);

Type: Void
(3) -> n:=2

    (3)  2
                                                         Type:
PositiveInteger
(4) -> f(n)
    Compiling function f with type PositiveInteger -> PositiveInteger

    (4)  4
                                                         Type:
PositiveInteger
(5) -> n:=2

    (5)  2
                                                         Type:
PositiveInteger
(6) -> f(n)

    (6)  5
                                                         Type:
PositiveInteger

\start
Date: Thu, 23 Jun 2005 13:56:28 +0200
From: Martin Rubey
To: Tim Daly, Camm Maguire, Bill Page
Subject: proposed fixes

Dear Tim, Bill, Camm, *

this is to inform you that I tried to organize the issues on IssueTracker a
little. I'd like to ask you to go through those issues where fixes are
proposed, and see which ones you would accept for the next "major" release. I
think that Axiom 3.9 or 3.10, i.e., September or October, would be a good point
to inform the general public about Axiom's progress.

Bill: could you transfer the remaining open bugs from savannah, especially
#9298...

Camm: when Bill has done this, could you please upload your (temporary) fix for
the bug in new!

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

I must say that I'm a bit unhappy about the bug fixing - pro{c,gr}ess. I think:

Since Axiom is an Open Source project, and little to no funding is available,
we should rather try to fix things quickly, rather than wait months until
everybody in the project had time to review the fix. If it turns out that the
fix is bad, it is trivial to remove it again.

I do agree (now) that my fix for the parenthesis problem in sums and products
is not good. However:

* this was spotted quite soon

* there is still no alternative fix available, and my fix at least gives
  correct answers.

We simply don't have the (wo)manpower to do everything the "right" way
immediately. I'm absolutely certain that a bad fix is better than no fix.

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

Bounties:

I'd like to propose two bounties:

* a bounty for somebody who implements a fast rational interpolation algorithm

* a bounty for somebody who implements an interpreter for aldor in lisp.

If you reply before tommorow afternoon (european time), I could formulate these
bounties and send them to comp.lang.lisp and sci.math.

I'd give only symbolic prices, i.e., 200$ each.

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

I'm off for two weeks of holidays saturday, so: no email, no axiom.

\start
Date: Thu, 23 Jun 2005 17:39:25 +0200
From: Francois Maltey
To: list
Subject: Re: proposed fixes

Hello everybody !

> This is to inform you that I tried to organize the issues on
> IssueTracker a little. I'd like to ask you to go through those
> issues where fixes are proposed, and see which ones you would accept
> for the next "major" release.

> I think that Axiom 3.9 or 3.10, i.e., September or October, would be
> a good point to inform the general public about Axiom's progress.

The better way is before the beginning of the scool year,
before 1/9 or 15/9.

So every teacher (and I) can speak about axiom to other teachers, 
to students, and so.

When everybody have began to work, the announce has less effects.
And the choices of the year are made.

> I'm off for two weeks of holidays saturday, so: no email, no axiom.

Have good holydays !

\start
Date: Thu, 23 Jun 2005 11:20:13 -0500
From: Tim Daly
To: Martin Rubey
Subject: reorg

Martin,

> I must say that I'm a bit unhappy about the bug fixing - pro{c,gr}ess

I'm in the midst of packing/moving to a new city and, at the same time,
trying to build the ISSAC proceedings on a CD (a major distribution of
Axiom and Aldor among other things) so life is hectic and torn up.

That said, it would be much easier for me to apply bug fixes if I got
email that included a patch file. Given a file Foo.org and Foo.fixed

diff -Naur Foo.org Foo.fixed >Foo.patch

and send a patch by email.

The wiki seems like a good place for discussion but it is a hard place
for me to get patches.

As for being offline... I'm going to lose my net connection while the
house transition takes place. And I'm on the road between here and
CMU which sucks up a whole day of driving time for each direction.
So my whole net personna is going to be a bit flaky for a while.

\start
Date: Thu, 23 Jun 2005 11:29:10 -0500
From: Tim Daly
To: Martin Rubey
Subject: reorg

Martin,

And I should note that the Foo.fixed file should contain a rather
well written explanation of what the old code didn't do, what the
new code does, and why the change was necessary. The new Axiom is
made up of literate programs and simple code changes are not enough.
A patch that comes my way without a full explanation means that I
have to generate the explanation which can take a lot of time since
I have to recover all of the prior discussions.

t

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

> I must say that I'm a bit unhappy about the bug fixing - pro{c,gr}ess

I'm in the midst of packing/moving to a new city and, at the same time,
trying to build the ISSAC proceedings on a CD (a major distribution of
Axiom and Aldor among other things) so life is hectic and torn up.

That said, it would be much easier for me to apply bug fixes if I got
email that included a patch file. Given a file Foo.org and Foo.fixed

diff -Naur Foo.org Foo.fixed >Foo.patch

and send a patch by email.

The wiki seems like a good place for discussion but it is a hard place
for me to get patches.

As for being offline... I'm going to lose my net connection while the
house transition takes place. And I'm on the road between here and
CMU which sucks up a whole day of driving time for each direction.
So my whole net personna is going to be a bit flaky for a while.

\start
Date: Thu, 23 Jun 2005 12:26:42 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: proposed fixes
Cc: Camm Maguire

Martin,

On Thursday, June 23, 2005 7:56 AM you wrote:

> Dear Tim, Bill, Camm, *
>
> this is to inform you that I tried to organize the issues on
> IssueTracker a little. I'd like to ask you to go through those
> issues where fixes are proposed, and see which ones you would
> accept for the next "major" release. I think that Axiom 3.9 or
> 3.10, i.e., September or October, would be a good point to inform
> the general public about Axiom's progress.

Great! Thanks for doing this.

> Bill: could you transfer the remaining open bugs from savannah,
> especially #9298...

Ok. Do you know if any other reports form Savannah are missing?

> Camm: when Bill has done this, could you please upload your
> (temporary) fix for the bug in new!

Is that an Axiom patch or a GCL patch? If it is GCL then it
might already be in the version of GCL that we use to build
Axiom.

> -------------------------------------------------------------------
>
> I must say that I'm a bit unhappy about the bug fixing - pro{c,gr}ess.
> I think:
> 
> Since Axiom is an Open Source project,

You just said the *Operative Words* -- Axiom is an Open Source project.
Being unhappy about something can only result in an invitation that
*you* do something about it! :)

> and little to no funding is available, we should rather try to fix
> things quickly, rather than wait months until everybody in the project
> had time to review the fix.

I don't think we are really waiting, as such, for anyone to review the
fixes. Whether someone reviews them or not depends entirely on their
personal whims.

The bottleneck in getting proposed fixes into Axiom is just that
no besides Tim Daly is actually posting any changes to the Axiom
source archives. Tim has a million other things to do in this
project beside test patches and commit changes to the archive, so
these get done when he manages to steal time from something else
that he would rather be doing. (We all have lives besides Axiom,
I guess ... but we tend to forget that of others. :)

So the best solution of this problem is if someone (or more
people) besides Tim would start to actively contribute changes
directly to one of the source archives.


> If it turns out that the fix is bad, it is trivial to remove it
> again.

Certainly committing a bad fix to a source repository and later
reversing it is not a major problem. I think the issue (for the
Axiom project at least) is usually more of a philosophical and
design nature. Axiom is a large and conceptually complex system
that, in my opinion has to be treated with a lot of respect for
the presumed but often ill-defined brilliance of it's original
designers - many of whom are no longer available for consultation!

> I do agree (now) that my fix for the parenthesis problem in
> sums and products is not good. However:
>
> * this was spotted quite soon
>
> * there is still no alternative fix available, and my fix at
> least gives correct answers.
>
> We simply don't have the (wo)manpower to do everything the
> "right" way immediately.

I certainly agree with that!

> I'm absolutely certain that a bad fix is better than no fix.

We definitely have different opinions about this. I think
that usually a "bad fix" is much worse than "no fix". As long
as we clearly document what the problem is, then most users
can compensate for such "known problems". The existence of
these known problems is what motivates proper solutions. If
one accepts temporary "bad" solutions, these very often become
permanent since we have no extra resources to correct things
that are now "more or less ..." working.

Of course there is a limit to how many such problems one
can live with.

> -----------------------------------------------------------
>
> Bounties:
>
> I'd like to propose two bounties:
>
> * a bounty for somebody who implements a fast rational
>   interpolation algorithm

Sounds like a good one to me.

> * a bounty for somebody who implements an interpreter for
>   aldor in lisp.

Say what?! Isn't that exactly what Axiom's interpreter is
right now? What do you mean?

Aldor used to be Axiom's prefer library compiler. I don't
see any reason why this cant be again. Only a few technical
problems remain for it's re-integration in to the new open
source version of Axiom.

> If you reply before tommorow afternoon (european time),
> I could formulate these bounties and send them to
> comp.lang.lisp and sci.math.

I think that is a good idea.

> I'd give only symbolic prices, i.e., 200$ each.

Sounds good to me. The Axiom Foundation is very poor
financially speaking and could afford much more than that
anyway.

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

> I'm off for two weeks of holidays saturday, so: no email,
> no axiom.

Ah, a life beside Axiom ... :) How's your (new) family coming
along?

\start
Date: Thu, 23 Jun 2005 12:49:13 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: Consistency (was Lazy Evaluation)
Cc: Kai Kaminski

On Thursday, June 23, 2005 7:23 AM Martin Rubey wrote:

> Bob McElrath writes:
>
>> I would personally mark output blocks when it is known that
>> they need to be re-evaluated.  
>
> I think I like this idea.

Yes this gentle approach, having the system highlight what
it has determined to be inconsistent, makes sense to me
especially if it is coupled with the ability to easily tell
the system (say, just one click) to just mechanically resolve
the inconsistencies as efficiently as possible. I expect there
will often be cases, for example while making major changes to
a worksheet, where one would not want the system always
"re-calculating" everything.

>> An option could turn on forced re-evaluation.  Personally,
>> I would not turn that on...
>
> Well, that's ok too, but I'd turn it off...

Ah, this is the mark of a true hacker: Someone who spends a lot
of time doing something sophisticated and complicated using tools
with their back covers removed, wires sticking out of the insides
and all the safety features disabled! :)

\start
Date: Thu, 23 Jun 2005 14:20:12 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

On Thursday, June 23, 2005 7:29 AM Ralf Hemmecke wrote:

> Axiom also allows to do something like that...
> What should the line (6) f(n) return after a user modified
> line (5) to n:=3?

The answer is

   (6)  6
                                       Type: PositiveInteger

The way to know for sure that this is correct is just to start
a new Axiom session, or use ')clear completely' and repeat steps
(1) to (4), the revised (5), and then (6).

> Will f(n) return 6 or 7? And what did the user expect?

Since you are using a free (i.e. global) variable in your
function definition and the execution of the function involves
hidden side-effects, this a little more complicated. See especially
the comments about caching of functions results in section 6.12
"Caching Previously Computed Results" page 249 and 6.16
"Free and Local Variables" in the Axiom book.

But in general it is possible to replace an imperative programming
style construct involving side-effects like this with something
more "functional", making the hidden side-effects explicit.
So that your line (2) could re-written as:

  f(k,n)==[k+1,n+k+1]

and the Axiom session looks like this:

(7) -> )clear completely
   All user variables and function definitions have been cleared.
   All )browse facility databases have been cleared.
   Internally cached functions and constructors have been cleared.
   )clear completely is finished.
(1) -> k:=1

   (1)  1
                                                        Type:
PositiveInteger
(2) -> f(k,n)==[k+1,n+k+1]
                                                                   Type:
Void
(3) -> n:=2

   (3)  2
                                                        Type:
PositiveInteger
(4) -> [k,x]:=f(k,n)
   Compiling function f with type (PositiveInteger,PositiveInteger) ->
      List PositiveInteger

   (4)  [2,4]
                                                   Type: List
PositiveInteger
(5) -> n:=2

   (5)  2
                                                        Type:
PositiveInteger
(6) -> [k,x]:=f(k,n)

   (6)  [3,5]
                                                   Type: List
PositiveInteger
(7) ->

Now I think that it is more obvious (at least to a program that
is trying to do lazy re-evaluation!) that changing  line (5)
to n:=3 will return the result 6. In fact calculation only
needs to be rolled-back to the state at line (4) and then (5)
and (6) repeated:

(4') -> [k,x]:=%%(4)

   (4')  [2,4]
                                       Type: List PositiveInteger
(5') -> n:=3

   (5')  3
                                       Type: PositiveInteger
(6') -> [k,x]:=f(k,n)

   (6')  [3,6]
                                       Type: List PositiveInteger

-------

where the primes ' mean that these expressions replace the
output on the page of the same numbered expression unprimed.

Regards,
Bill Page.

> Ralf
>
> -------
>
> (1) -> k:=1
>
>    (1)  1
>                                      Type: PositiveInteger
> (2) -> f(n)==(free k; k:=k+1; n+k);
>
> Type: Void
> (3) -> n:=2
>
>     (3)  2
>                                      Type: PositiveInteger
> (4) -> f(n)
>    Compiling function f with type PositiveInteger -> PositiveInteger
>
>     (4)  4
>                                       Type: PositiveInteger
> (5) -> n:=2
>
>    (5)  2
>                                       Type: PositiveInteger
> (6) -> f(n)
>
>    (6)  5
>                                       Type: PositiveInteger

\start
Date: Thu, 23 Jun 2005 11:41:07 -0700
From: Bob McElrath
To: Ralf Hemmecke
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

Let me understand this better.
(1) -> f(n)==(free k; k:=k+1; n+k);
                                                                   Type: Void
(2) -> f(1)
   Loading /usr/lib/axiom-20050201/algebra/UPMP.o for package 
      UnivariatePolynomialMultiplicationPackage 
   Compiling function f with type PositiveInteger -> Polynomial Integer
      
   Compiled code for f has been cleared.

   (2)  k + 2
                                                     Type: Polynomial Integer
(3) -> f(1)
   Compiling function f with type PositiveInteger -> Polynomial Integer
      

   (3)  k + 3
                                                     Type: Polynomial Integer
(4) -> f(1)

   (4)  k + 4
                                                     Type: Polynomial Integer

First of all, why does it claim to have compiled the function twice?  Why does
it claim after line 2 that "compiled code for f has been cleared"?

The "free" statement declares k to be in the global namespace, yet when
it is assigned in f(), the output does not seem to know that it is a
global with a bound value...???

A similar function in Mathematica:

    f[n_] == Block[{}, (k:=k+1; n+k)]

complains that "Recursion depth of 256 exceeded" which makes more sense
because it is searching for a definition of k.  (actually it makes that
complaint even if I define k first -- I think I've not written an
equivalent example)

And the moral of the story is that side-effects suck.  Lisp and the
lambda calculus have the right idea... ;)

A dependency tree for such an example would probably look like this (for
your example below):

    line 6: depends on n from line 5, k from line 4; modifies: k
    line 5: depends on nothing                     ; modifies: n
    line 4: depends on n from line 3, k from line 1; modifies: k
    line 3: depends on nothing                     ; modifies: n
    line 2: depends on nothing                     ; modifies: f
    line 1: depends on nothing                     ; modifies: k

Searching the dependency tree for after modifying line 5 would reveal:
    
    line 6 must be recomputed because it depends on line 5 (modified)
    line 5 must be recomputed because it was modified
    line 4 must be recomputed because line 6 depends on k from line 4
    line 3 must be recomputed because it modifies n which is used on line 4
    line 1 must be recomputed because line 4 depends on k from it.

and the minimum set of recomputations is lines 1,3,4,5,6 in that order.

As in my earlier example, the dependency tracker must keep track of
which inputs modify which variables.  But, I do not think it necessary
to cache their values.  Caching could be done for speed, but I think
needs more debate...

Ralf Hemmecke [Ralf Hemmecke] wrote:
> Axiom also allows to do something like that...
> What should the line (6) f(n) return after a user modified line (5) to
> n:=3? Will f(n) return 6 or 7? And what did the user expect?
> 
> Ralf
> 
> (1) -> k:=1
> 
>    (1)  1
>                                                         Type:
> PositiveInteger
> (2) -> f(n)==(free k; k:=k+1; n+k);
> 
> Type: Void
> (3) -> n:=2
> 
>    (3)  2
>                                                         Type:
> PositiveInteger
> (4) -> f(n)
>    Compiling function f with type PositiveInteger -> PositiveInteger
> 
>    (4)  4
>                                                         Type:
> PositiveInteger
> (5) -> n:=2
> 
>    (5)  2
>                                                         Type:
> PositiveInteger
> (6) -> f(n)
> 
>    (6)  5
>                                                         Type:
> PositiveInteger

\start
Date: Thu, 23 Jun 2005 15:58:49 -0400
From: Bill Page
To: William Sit
Subject: RE: Consistency (was Lazy Evaluation)
Cc: Kai Kaminski

On Thursday, June 23, 2005 6:52 AM William Sit wrote:

> In general, I do not like that the result of a command depends
> on its screen location.
>
> Bob McElrath wrote:
>> A worksheet is read from top to bottom, as a document, not a
>> batch-system-dispatcher.  As a document, it should make sense
>> if I read it in order.  The idea that a command's result is
>> independent of its screen location forces the user to keep
>> considerable state information in his head.  By putting the
>> state information into the document, in order from top to
>> bottom, the user is freed from having to keep *any* state
>> information in his head, because he can simply read it off
>> the document.
>

Yes, that's it exactly!

I think this view is very much in keeping with the intentions
of Axiom's original designers. Axiom was originally called
"ScratchPad" (written with a internal capital letter just like
WikiWord, still ahead of it's time). Hmmm... that gives me an
idea:

Why don't we name the *new* Axiom user interface ScratchPad?

Anyway, I think the type of user interface we want should be a
kind of "intelligent" scratch pad, not just a plain dumb old
piece of paper. If I erase something that I previously scratched-
in near the top of the page and replace it with something better,
I want my intelligent ScratchPad to be able magically re-assemble
itself as if that was what I had written all along. No more,
rewriting, crumpling up old pages, and throwing them in the
waste basket.

It would be even nicer if it could warn me more gently using
shading and color that my change is going to affect two or
three others things way down near the bottom of the page but
not anything in between. These in between calculations were
ok and don't need to be re-done. But the other things might
need more attention or maybe they just need to be repeated
rotely with some simple substitution of values or symbols.

> I don't disagree that most *finished* worksheet read from
> top to bottom, and the commands run from top to bottom, but
> that need not be the norm. Document is a good analogy: modern
> documents are not linear, because we now have hyperlinks;
> we can, and want to, skip around! A program is the same,
> the code need not be linear in structure: we may have parts
> A, B, C in parallel followed by D that depends on A, B, C;
> code can even have a circular structure (like Axiom
> domains). Compilers do code optimization by exploring the
> non-linear structure of the code.

I think that that is a very good point.

The "Intelligent Paper" (tm) described above is one kind of smart
user interface, but you are right that the way we use the web
and other smart document interfaces these days is gradually
changing the way we view what used to be limited by the nature
of the recoding technique on ordinary paper. To work in this
new way, we need to be able to "navigate" easily and fluently
through a network structure in a sort of multi-dimensional manner.
This is exactly what excites so many people about the Web.

So I agree completely that the new ScratchPad needs to be very
much aware of and integrated with the (still evolving) Web point
of view about organizing pages into a very dynamic kind of
"document", i.e. web site. What Tim Daly calls "Doyen" is exactly
this kind of web site - a kind of Public ScratchPad. The Axiom
MathAction web site is a kind of prototype for what Doyen should
eventually become. We need the new personal ScratchPad to
integrate smoothly with this Public ScratchPad. This is the way
that private mathematical "work in progress" may someday be
published and shared rapidly with others.

It seems to me that right now the planets must surely be in
a favorable alignment since we seem to be recognizing this
need for a new approach just at the time that exactly this
new kind of web technology is being experimentally developed.
For example I think we can learn a lot from this project:

http://www.tiddlywiki.com

Bob McElrath already has a version of this web interface
that provides pretty mathematics in addition to all of the
other editing and hyper linking features:

http://bob.mcelrath.org/tiddlymath/tiddlyjsmath.html

I think that for people who are already comfortable with this
new multi-dimensional hypertext way of writing and working as
one of their own personal tools, we also need to be able to
provide this kind of flexibility for the new ScratchPad user
interface.

> During development of this final product, just like writing
> any essay, we gather together ideas, pieces, expand them,
> rearrange them, put them into sections, chapters. Until the
> document is finished, it is *not* consistent! The state of
> consistency is approached only gradually.

That is certainly one way of working that we need to accommodate.

Another approach that is perhaps more popular among computer
programmers than it is among mathematicians is a kind of iterative
approach. In this way of working one strives to always maintain
one's creation in a consistent state. Programs are dynamic things
that have complex and sometimes apparently unpredictable behaviors.
In order to place some bounds on the amount of complexity that
we have to deal with, we often write programs in small iterative
steps. First a very simple version of the program is written that
does some basic things - makes certain limited calculations - but
does them right and consistently. Next we begin to make small
iterative improvements, testing each improvement in an attempt to
ensure that we have not "broken" anything by our changes.

I think that as more and better computer tools become available
for mathematics, more mathematics may actually be done in this
way.

> So in developing a computation worksheet, as I often do in
> Mathematica, I start with exploratory routines, test ideas,
> revise, expand, change, etc and finally reorganizing this
> into a logical sequence of commands. The entire sequence is
> not necessarily linearly ordered, as the location of some
> functions (especially those defined with SetDelayed, which
> I would consider as library functions) are unimportant except
> for grouping into some theme. The main executable (using
> immediate assignments) sequence would be linear mostly.

What you are describing reminds me very much of the literate
programming style that was promoted by Knuth and which Tim
has adopted so whole heartedly for the Axiom source code.
Literate programs a complex documents which can be processed
and viewed in several different ways. Most notably there is
the "weave" view of the document which is most similar to
a paper-based kind of publication. But there is also the
"tangle" view that is necessary to extract the programming
code for the computer.

I agree that this kind of flexible multiple views of a
single complex object is probably also a very good paradigm
to adopt for literate mathematical programming, i.e. what
most people want to do with Axiom.

> Why should I need consistency during the development? If
> I am only working on some single subroutine, why shouldn't
> I be able to test this in isolation?

To my mind these are two very different things. We need
consistency during development in order to help manage the
complexity which otherwise could very easily overwhelm our
limited human abilities.

Yes, testing and working with smaller pieces of a mathematical
calculation, or proof, or program, is often best done in
a isolated more controlled "environment". Programmers often
set up special "test harnesses" which are special programming
environments specifically for isolating and testing specific
features of some new piece of code. This is very similar to
the practices in other types of engineering and also in
experimental sciences. In engineering terms this is usually
called "unit test". It is one important step in the development
of complex systems.

I agree that the new ScratchPad user interface should be able
to support this kind of use.

> If I keep track of dependencies with SetDelayed, there is
> no need to worry about the eventual consistency. Even if I
> can place code in  a linear space order, why can't I prefer
> just a linear logical order? All I need is consistency of the
> final code, which if it works, is automatic.

"which if it works, is automatic" ... that is the common
presupposition of many less experienced computer programmers
and software development companies with whom I have worked.
They are often very reluctant to become involved in system
testing and business case scenarios because they usually feel
like this a waste of time since they have already shown with
there unit tests that everything "should" (implying that it
"will") work. But in every case that I know of, these people
have been wrong. There is a whole computer science literature
on this subject.

> For developers, it is the revision cycle that is time
> consuming. I would like to have all the freedom available.

Reducing the revision cycle time is exactly what lazy
re-evaluation is all about. I don't think that it needs
to restrict your freedom in any way.


\start
Date: Thu, 23 Jun 2005 14:11:33 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: Consistency (was Lazy Evaluation)
Cc: Kai Kaminski

Page, Bill [Bill Page] wrote:
> > I don't disagree that most *finished* worksheet read from
> > top to bottom, and the commands run from top to bottom, but
> > that need not be the norm. Document is a good analogy: modern
> > documents are not linear, because we now have hyperlinks;
> > we can, and want to, skip around! A program is the same,
> > the code need not be linear in structure: we may have parts
> > A, B, C in parallel followed by D that depends on A, B, C;
> > code can even have a circular structure (like Axiom
> > domains). Compilers do code optimization by exploring the
> > non-linear structure of the code.
> 
> I think that that is a very good point.

Perhaps it would be good to point out that even within one
document/worksheet, one could have independent subsets.  e.g. If section
A does not depend on any definitions from outside, then it exists as an
independent unit.  Functions defined there can be used elsewhere,
without causing anything in section A to be recomputed.

C++ and other languages have elevated this to the level of "namespaces"
which is an incredibly good idea.  Mma/Maple worksheets tend to have a
poor separation between global and local variables.  Over-use of global
variables was recognized long ago as a large source of errors and bugs.
Yet in math we assume implicitly that there is one global namespace.

My point is that lazy re-evaluation is not mutually exclusive with
non-linear documents.

Circular dependencies, however, deserve more thought.  This could break
lazy re-evaluation logic.  But, is there any *sensible* document with
circular dependencies?  I would call a circular dependency a "bug".
(one which an intelligent front-end could warn the user about)

Here is some discussion on this from the smv language (some kind of
formal verification tool)
    http://www.cis.ksu.edu/santos/smv-doc/language/node17.html
In the realm of classes, people seem to agree that creating interfaces
is the way to remove cyclical dependencies:
    http://java.sun.com/docs/books/tutorial/java/concepts/interface.html
Another recommended method to resolve circular dependencies is to
specify an evaluation order.  However, that's exactly what is provided
by a worksheet.

\start
Date: Thu, 23 Jun 2005 17:13:15 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

Bob,

On Thursday, June 23, 2005 2:41 PM you wrote:

>Let me understand this better.
>
> (1) -> f(n)==(free k; k:=k+1; n+k);
>                                     Type: Void
> (2) -> f(1)
>   Loading /usr/lib/axiom-20050201/algebra/UPMP.o for package 
>      UnivariatePolynomialMultiplicationPackage 
>   Compiling function f with type PositiveInteger -> Polynomial Integer
>      
>   Compiled code for f has been cleared.
>
>   (2)  k + 2
>                                     Type: Polynomial Integer
> (3) -> f(1)
>   Compiling function f with type PositiveInteger -> Polynomial Integer
>
>   (3)  k + 3
>                                     Type: Polynomial Integer
> (4) -> f(1)
>
>  (4)  k + 4
>                                     Type: Polynomial Integer
>
> First of all, why does it claim to have compiled the function
> twice?

Interesting!

I think this must occur because the global variable k initially has
no type information. As such it defaults to being of type Variable k.

Axiom told you that it compiled the function assuming that the
function would return a Polynomial. That is a pretty smart thing
for Axiom to have guessed but it could have been wrong.

> Why does it claim after line 2 that "compiled code for f has
> been cleared"?

The message "Compiled code for f has been cleared." is avoided
if you declare

  k:Polynomial Integer

before applying f for the first time. You can also declare it as

  k:Expression Integer

or any other type that permits the operation + when k is unassigned
(it might have a type but no associate value). I presume that
Axiom does this in case the result of the first application of the
function actually resulted in k being of some other type. This
actually happens in this case but the difference in type is not
significant. To see this note that when f(1) is first called k
is of still of type Variable k by default. During the execution
of f(1) k becomes of type Polynomial Integer because of the
assignment k:=k+1.

> The "free" statement declares k to be in the global namespace,
> yet when it is assigned in f(), the output does not seem to
> know that it is a global with a bound value...???

Why do you say that? When f() is first called k is of type
Variable k and it's value is just k. During the execution of
f() k becomes something of type Polynomial Integer and its
value is set of k+1 where the k in this expression refers to
the k of type Variable k. Try this:

(7) -> )clear completely
   All user variables and function definitions have been cleared.
   All )browse facility databases have been cleared.
   Internally cached functions and constructors have been cleared.
   )clear completely is finished.
(1) -> typeOf k

   (1)  Variable k
                                           Type: Domain
(2) -> f(n)==(free k; k:=k+1; n+k);
                                           Type: Void
(3) -> f(1)
   Compiling function f with type PositiveInteger -> Polynomial Integer

   Compiled code for f has been cleared.

   (3)  k + 2
                                           Type: Polynomial Integer
(4) -> k

   (4)  k + 1
                                           Type: Polynomial Integer
(5) -> subst(k,'k=1)

   (5)  2
                                           Type: Expression Integer
(6) ->

The result of line (4) is probably quite unexpected. You can see
in fact that the k in the expression that is value of k is just the
variable 'k. Axiom apparently has no trouble with such a circularity.
And why should it?

> A similar function in Mathematica:
>
>    f[n_] == Block[{}, (k:=k+1; n+k)]
>
> complains that "Recursion depth of 256 exceeded" which makes more
> sense because it is searching for a definition of k.  (actually it
> makes that complaint even if I define k first -- I think I've not
> written an equivalent example)

In Maple I would write:

> f := proc (n) global k; k := k+1; n+k end proc
> f(1)
 Error, (in f) too many levels of recursion 

So Maple and Mathematica agree about this. But if I write:

> k:=1;
> f := proc (n) global k; k := k+1; n+k end proc
> f(1)
                   3

I can try this:

> x:= 'x' + 1;
Error, recursive assignment

which fails, but it turns out though that I can write a delayed
evaluation like this

> x:=''x'+1';
> subs('x'=1,x);
                  2

This is probably also possible in Mathematica using some similar
delayed evaluation expressions.

In Axiom I can just write this

> x:= 'x + 1

   (12)  x + 1
                        Type: Polynomial Integer
> subst(x,'x=1)

   (13)  2
                        Type: Expression Integer

No problem. 

> And the moral of the story is that side-effects suck.  Lisp
> and the lambda calculus have the right idea... ;)

I think that Axiom seems mostly to inherit this right idea.


\start
Date: Thu, 23 Jun 2005 14:48:47 -0700
From: Bob McElrath
To: William Sit
Subject: Re: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

William Sit [William Sit] wrote:
> > > As I commented above, it is *not* Axiom's job to decide for me
> > > what needs recomputing and what does not.
> >
> > I disagree. To paraphrase what Bob wrote several emails earlier:
> > "Why should it be necessary for me to do something complex
> > like figuring out an efficient re-calculation sequence when
> > this is something that a computer can do very easily?"
>
> In my case, because *I* want to be in the driver seat. Also by being forc=
ed to
> do so, I understand my algorithm much better. The resulting sequence of
> computations will be part of my final algorithm which, for better or wors=
e,
> represents my best effort. No matter how efficient this re-calculation is=
 done
> by the system, I want a repeatable computation; LRE is not repeatable bec=
ause it
> depends on a history of interaction. See Part III on Maple.

Let me quote: "LRE is not repeatable because it depends on a history of
interaction".  This is exactly opposite of the truth!

A traditional Mma/Maple worksheet is not repeatable because it depends
on the history.  I can go back and re-execute lines out of order,
resulting in a kernel state that is very different than what is written
on the screen, that I must remember!

With LRE the kernel state is represented correctly by what is on the
screen, *no matter what order I entered the commands*.

> This is not the same issue as efficient implementation of recursion, wher=
e I
> would *definitely* want the system to handle it.

I disagree.  It's exactly the same issue.

The computer can efficently track, tell you about, and re-evaluate
dependencies, so that the things you have entered (in the *order* they
are placed on the screen) are always accurate, so why not have it do
just that?

Using the previous example f(n)==(free k; k:=k+1;k+n), if at any poin=
t I
want to insert f(n) into the middle of my document somewhere, and I want
to know what k is, all I have to do is add at the point I want:
    k
    f(n)
Which will tell me the value of k used.  Note this would not cause
anything above it to be re-evaluated if values are cached, but would
cause any f(n) calls below it to be re-evaluated.  In a simpler example,
I could look two lines above and see what value was assigned to k there.

Due to the err...twisted nature of this example, if values are not
cached, such a modification would cause any k assignments and f(n) calls
to be re-evaluated.  If a user wants to evaluate f(n) using the
*current* value of k, he simply needs to place f(n) at the *end* of the
document, and *nothing* would be re-evaluated.

So, our little experiments at the end of our worksheets are always safe
=66rom forcing a full re-evaluation, unless we edit/execute out of order,
in which case I *want* to be notified that things are in an inconsistent
state.

I think that it is *always impossible* to trigger a re-evaluation by
adding code strictly to the end of a worksheet.  But please come up with
a counter-example to this hypothesis.

I would even advocate an "experiment" tab, which would be effectively a
sub-document.  That is, when used it would copy the kernel's entire
state from the main document.  Therefore interactions which might cause
a full re-evaluation (such as adding two f(n) and then editing the first
one in the experimental tab) would not infect the main document.
However, the dependency tracking could easily tell the user that what is
now in the experimental tab is not consistent with the main document.  A
full re-eval would start by copying the main kernel state, rather than
re-evaluating the main worksheet.

Keeping a full variable state for each input line would reduce re-evals
even more, and obviate the need for an "experiment" tab, at the expense
of memory usage.  (again: toggleable user preference)  As Mma keeps In[]
and Out[] anyway, I don't think a full variable history could be any
worse in size than Out[].  You only need to know the variable state at
the end of each block, not each time a variable is modified.

\start
Date: Thu, 23 Jun 2005 20:32:21 -0400
From: Bill Page
To: William Sit
Subject: RE: Lazy re-evaluation (was: More AxiomUI)
Cc: Kai Kaminski

On Thursday, June 23, 2005 2:35 AM William Sit wrote:

> Bill Page wrote: 
>> 2-d editing might be possible if we can use mathML. In that case
>> it is possible to select displayed 2-d sub-expressions, modify them
>> with a few keystrokes (e.g. by typing the corresponding linear 1-d
>> sub-expression).
>> ...
> You know what, I agree 100% with you on this. But you misunderstood
> my interpretation of 2D editing (well I guess was not clear). I mean
> the ability to edit "previous input lines in a 2D-way". This means
> being able to jump to (mouse to?) an input line on screen, edit this
> in a 2D way (screen editing, like what can be done even in vi).
> I do not mean the extra fancy things like selecting subexpression
> from outputs! Yes, M and M allow that, but they don't work well
> precisely for the reason you mentioned. (Derive did it really well).
 
Oh, I see. I am sorry that I did not understand what you meant.

Yes, this sort to "2-d editing" is exactly what I have been
writing about - the ability to pick some mathematical expression
displayed on the computer screen from a larger mathematical
document, the contents of which have been partly generated
by the user (in the normal way with LaTeX notation or whatever)
and partly generated by an interface to Axiom. Just like what
you see on the MathAction wiki, but with the additional ability
to pick out and edit the commands that generated individual
equations and Axiom output.

Even without the kind of "2-d editing" that we agree is not very
useful in Maple and Mathematica, I think it is possible to do a
good job of designing an easy to use browser-based user interface
that allows the LaTeX and Axiom commands to be edited in their
common text form. After editing, these commands would then need to
be re-executed. It is in this context that Bob McElrath and I have
been defending the idea of "lazy re-evaluation" as a way to update
the document after such changes are made.

\start
Date: Thu, 23 Jun 2005 20:07:55 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Consistency (was Lazy Evaluation)
Cc: Kai Kaminski

On Thursday, June 23, 2005 5:12 PM Bob McElrath wrote:
> ...
> Circular dependencies, however, deserve more thought.  This could
> break lazy re-evaluation logic.  But, is there any *sensible*
> document with circular dependencies?  I would call a circular
> dependency a "bug". (one which an intelligent front-end could warn
> the user about)
>

Jon Barwise and Lawrence Moss (see previous email refering to their
book "Vicious Circles"), disagree strongly with your opinion and
demontrate many cases where circular definitions do make sense
and are very efficent formal descriptions of some phenomena or
idea. Unfortunately Jon Barwise died in ca. 2000. 

I think calling a circular dependency a "bug" is not so different
from those people who would claim that doing mathematics on a
computer is impossible because it easy to show that there are
many more real numbers than there are integers and computers only
have finite memory so they can not even represent all the integers!
I know some people who have even argued that this problem demonstrates
that artifical intellegence is impossible because obviously human
beings (mathematicans) can reason effectively about real numbers.
And we believe that we use them all the time in physics and in
engineering. But in using computer algebra systems we know that
this argument about fundamental limitations of the ability of
computers is wrong. It is quite possible to write programs
which manipulate and appear to reason about infinite objects.

Many of the things (not all) that can be described in a circular
manner turn out to be infinite objects, in fact what mathematicians
might call *very big* objects (in a specific technical sense).

Here is another plug for book and a very useful review paper:

http://cogprints.org/336/
http://page.axiom-developer.org/zope/Plone/refs/articles/akman-vicious.pdf/v
iew

"To a greater or lesser degree, every scientific advance marks some
departure from the common sense that preceded it." These words of
Irving M. Copi (Copi, 1979, p.195) apparently summarize the nature
of Vicious Circles in the most concise fashion. Following the steps
of Aczel's ground-breaking monograph (Aczel, 1988) which marked a
departure from the `common sense' that is attributed to classical set
theory, this new book (abbreviated as VC in the sequel) of Jon Barwise
and Larry Moss not only offers an introduction to the revolutionary
and fascinating topic of non-wellfounded sets (a.k.a. hypersets) but
also becomes the most authoritative source for any serious researcher
(mathematician, philosopher, or computer scientist alike) who wants
to understand and further pursue this timely topic."

And in a footnote the reviewer write:

"It is hard to tell why circularity has always been regarded with
doubt in mathematical circles. One reason may be that circular
arguments or structures are thought to be diffcult to grasp, most
probably due to our educational make-up in linear thinking. On a
more personal note: I tend to think that popular works such as
Escher's drawings may have helped to create the illusion that
circularity invites nonsense."

> Here is some discussion on this from the smv language (some kind
> of formal verification tool)
>
> http://www.cis.ksu.edu/santos/smv-doc/language/node17.html
>

"There are cases where a combinational [i.e. circular] loop
``makes sense'', in that there is always a solution of the
equations. In this case, the order in which signals are evaluated
may be conditional on the values of some signals. For example,
take the following system:

        x := c ? y : 0;
        y := ~c ? x : 1;

If c is false, then we may first evaluate x, then y, obtaining
x = 0, then y = 0. On the other hand, if c is true, we may
first evaluate y, then x, obtaining y = 1, then x = 1. The
existence of conditional schedules such as this is difficult
to determine, since it may depend on certains states (or signal
values) being ``unreachable''. For example, if we have

        x := c ? y : 0;
        y := d ? x : 1;

it may be the case that c and d are never true at the same time,
in which case x and y can always be evaluated in some order.
Loops of this kind do sometimes occur in hardware designs
(especially in buses and ring-structured arbiters). The
expected approach to this problem is require the user to
provide constraints on the order of evaluation (so that the
program can be compiled), and to verify that these constraints
always have a solution."

I think these examples are good ones and are probably similar
to many of the kinds of circularities that are found in Axioms
algebra library. I think it is easy to see that there is nothing
"fundamentally wrong" with these definitions and that it
should be possible in principle to use such statements as
reliable specifications for a program. Of course this does not
necessarily mean that compiling such specifications into a
runnable program is going to be easy. On the other hand there
seem to quite a large number of cases where a "fixed point"
iteration procedure starting from some inconsistent partial
solution, will necessarily lead to the unique and real
solution. Specifically, I think that this is the case in the
case of the Axiom library.

\start
Date: Thu, 23 Jun 2005 23:19:36 -0400
From: William Sit
To: Bill Page
Subject: Re: Consistency (was Lazy Evaluation)
Cc: Kai Kaminski

"Page, Bill" wrote:

> Why don't we name the *new* Axiom user interface ScratchPad?

"Intelligent ScratchPad"? (to steal from your TM and comments)

  [snipped]

> Another approach that is perhaps more popular among computer
> programmers than it is among mathematicians is a kind of iterative
> approach. In this way of working one strives to always maintain
> one's creation in a consistent state. Programs are dynamic things
> that have complex and sometimes apparently unpredictable behaviors.
> In order to place some bounds on the amount of complexity that
> we have to deal with, we often write programs in small iterative
> steps. First a very simple version of the program is written that
> does some basic things - makes certain limited calculations - but
> does them right and consistently. Next we begin to make small
> iterative improvements, testing each improvement in an attempt to
> ensure that we have not "broken" anything by our changes.
> 
> I think that as more and better computer tools become available
> for mathematics, more mathematics may actually be done in this
> way.

One should not depend on "intelligent tools" to guide one's behavior. The
approach you mentioned above is already the practice of the day for me. Surely
each small piece of code or ideas for proof developed should be tested to a
consistent state before moving on. If some prefers these intelligent tools, fine
for them.  (I keep thinking of MS Word, and you may be right: more documents are
done the MS way.)
 
> [snipped]
> 
> > Why should I need consistency during the development? If
> > I am only working on some single subroutine, why shouldn't
> > I be able to test this in isolation?
> 
> To my mind these are two very different things. We need
> consistency during development in order to help manage the
> complexity which otherwise could very easily overwhelm our
> limited human abilities.

Ok, I will say that there are pauses in the development process when it is
important to check consistency before going on. What I meant was I do not need
to have consistency all the time and so I do not re-evaluation (or lazy one) all
the time.

[snipped]

> I agree that the new ScratchPad user interface should be able
> to support this kind of use.

Axiom already allows isolated tests if one starts a new frame. But Mathematica
and Maple do not. There are advantages and disadvantages to both. Some tests
cannot be totally isolated or need a simulated environment that is more
difficult to create than to just test them within the real main development.
 
> > If I keep track of dependencies with SetDelayed, there is
> > no need to worry about the eventual consistency. Even if I
> > can place code in  a linear space order, why can't I prefer
> > just a linear logical order? All I need is consistency of the
> > final code, which if it works, is automatic.
> 
> "which if it works, is automatic" ... that is the common
> presupposition of many less experienced computer programmers
> and software development companies with whom I have worked.
> They are often very reluctant to become involved in system
> testing and business case scenarios because they usually feel
> like this a waste of time since they have already shown with
> there unit tests that everything "should" (implying that it
> "will") work. But in every case that I know of, these people
> have been wrong. There is a whole computer science literature
> on this subject.

True. I should add, if it does not work, it is not the "final code".
In such case, how would LRE help me identify the "bugs"? In fact, I had just
recently written some code that helps me prove a mathematical result and my
first two or three versions are consistent, but wrong (because I overlooked some
cases)! Consistency simply say that the results you see are what the code
computes. There is no implication that the results reflect a correct solution to
the original problem.

> > For developers, it is the revision cycle that is time
> > consuming. I would like to have all the freedom available.
> 
> Reducing the revision cycle time is exactly what lazy
> re-evaluation is all about. I don't think that it needs
> to restrict your freedom in any way.
> 
Especially if I do not use it! 

Don't take this seriously; LRE has its role to reduce cycle time, as long as I
do not have to check the automatically recomputed results, which I almost ALWAYS
have to do in large spreadsheets --- not because the recomputations are wrong,
for Excel follows all the dependencies correctly, giving me always a consistent
spreadsheet, but because of MY mistakes --- to get to what I want eventually. My
point is, if one forgets to change some lines when one modifies another, even if
the state of the system is consistent, the answers may still be wrong. Sometimes
LRE will make you see the mistake faster, but more often, it won't tell you
where the logical mistakes are and it is still better if you can keep the
*logical state* in your head and make ALL the changes to a correct *logicial
state* before applying a recomputation. I would say that if recomputation (even
for LRE) takes a long time, I save time by not using it than using it if I
cannot keep the logical states clearly in my head.

\start
Date: Fri, 24 Jun 2005 04:55:11 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x),-sin(x)],[sin(x),cos(x)]]
eigen:=eigenvalues(A)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 04:54:15 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x),-sin(x)],[sin(x),cos(x)]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 12:34:01 +0200
From: Francois Maltey
To: list
Subject: comments with axiom

Hello, 

Comments in axiom begins with -- or ++ ? or only with -- ?

Are -- and ++ exactly the same or not ? in *.spad file and *.input files ?

Is it possible to get the help there is after ++ ?
Can I put such help in a *.input file ?

\start
Date: Fri, 24 Jun 2005 13:30:16 +0200
From: Martin Rubey
To: Francois Maltey
Subject: Re: comments with axiom

See

http://lists.nongnu.org/archive/html/axiom-developer/2004-09/msg00082.html

Martin

(for .input files, I don't know.)

Francois Maltey writes:
 > Hello, 
 > 
 > Comments in axiom begins with -- or ++ ? or only with -- ?
 > 
 > Are -- and ++ exactly the same or not ? in *.spad file and *.input files ?
 > 
 > Is it possible to get the help there is after ++ ?
 > Can I put such help in a *.input file ?

\start
Date: Fri, 24 Jun 2005 07:59:24 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x),-sin(x)],[sin(x),cos(x)]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 07:57:45 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x),-sin(x)],[sin(x),cos(x)]]
\end{axiom

\start
Date: Fri, 24 Jun 2005 07:59:56 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x),-sin(x)],[sin(x),cos(x)]]
A(1,1)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:22:23 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] 

\begin{axiom}
e=solve(x^2=4,x)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:11:23 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:10:35 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
L
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:21:53 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] 

\begin{axiom}
e=vector[1,2]
e=solve(x^2=4,x)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:05:20 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
A(1,1)*A(2,2)-A(2,1)*A(1,2)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:17:01 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
solve(x^2,x)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:17:44 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
sqrt(2)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:13:03 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
L(1)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:13:41 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
L.1
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:07:43 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:06:33 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
A(1,1)*A(2,2)
A(2,1)*A(1,2)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:18:46 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] 

\begin{axiom}
solve(x^2=4,x)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:20:16 -0500
From: MathAction (unknown)
To: MathAction
Subject: [numerical linear algebra] test

\begin{axiom}
solve(x^2=4,x)
x
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:28:15 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
B
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:28:33 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
B.1
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:27:04 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
B(1)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:27:22 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
B
\end{axiom}

\start
Date: Fri, 24 Jun 2005 08:26:34 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:05:06 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] 

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
v:=vector[v11,v12]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:03:51 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
v:=[[v11],[v12]]
A*v=B*v
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:04:30 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
v:=vector[[v11],[v12]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:26:02 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
LA:=matrix[sqrt(-1)*sin(x)+cos(x),-sqrt(-1)*sin(x)+cos(x)]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:25:39 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
LA:=[sqrt(-1)*sin(x)+cos(x),-sqrt(-1)*sin(x)+cos(x)]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:22:34 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] 

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
[a,b]:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
a
b.2
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:21:41 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] 

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
[a,b]:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
a
b
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:21:09 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] 

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
[a,b]:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:27:03 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
sqrt(-1)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:14:21 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
B:=solve(A(1,1)*A(2,2)-A(2,1)*A(1,2)=0,L)
v:=matrix[[B.1],[B.2]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:30:10 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[a,b]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:28:14 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
LA:=matrix[sqrt(-1)*sin(x)]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:29:32 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[cos(x)-L]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:36:45 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
A*D
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:31:08 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[a],[b]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:39:13 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1)*v
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:33:48 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
LA:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:34:12 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
LAM:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:34:26 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
L:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:33:05 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)*cos(x)]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:38:12 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:41:44 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
solve(A*v=D(1,1)3v,v11)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:45:04 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
solve(A*v=D(1,1)*v,v)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:43:08 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v=D(1,1)*v
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:43:59 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
solve(A*v=D(1,1)*v,v11)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:30:29 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[a,b]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:31:54 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[sqrt(-1)*sin(x)+cos(x)],[b]]
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:40:09 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:42:11 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
solve(A*v=D(1,1)*v,v11)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:48:12 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v-D(1,1)*v=0
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:48:29 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v-D(1,1)*v=0
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:46:50 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
solve((A-D(1,1))v=0,v)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:48:54 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v-D(1,1)*v
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:48:33 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v-D(1,1)*v=0
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:49:43 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x),-sin(x)],[sin(x),cos(x)]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v-D(1,1)*v
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:54:39 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v-D(1,1)*v
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:53:07 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x),-sin(x)],[sin(x),cos(x)]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
solve(A*v-D(1,1)*v=0,v11)
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:52:40 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x),-sin(x)],[sin(x),cos(x)]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
solve(A*v-D(1,1)*v=0,v(1,1))
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:48:15 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v-D(1,1)*v=0
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:48:17 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v-D(1,1)*v=0
\end{axiom}

\start
Date: Fri, 24 Jun 2005 09:48:29 -0500
From: MathAction (unknown)
To: MathAction
Subject: [List To Matrix] test

\begin{axiom}
A:=matrix[[cos(x)-L,-sin(x)],[sin(x),cos(x)-L]]
D:=matrix[[sqrt(-1)*sin(x)+cos(x)],[-sqrt(-1)*sin(x)+cos(x)]]
v:=matrix[[v11],[v12]]
A*v
D(1,1)*v
A*v-D(1,1)*v=0
\end{axiom}

\start
Date: Fri, 24 Jun 2005 16:42:18 -0300
From: Felipe Bugno
To: "axiom-developer" <list>
Subject: Texmacs output field problem

Hello!!

Well, i'm doing some look on axiom, and i'm very impressed with it!! Wond=
erful software... i'm glad to all developers who donate time for the proj=
ect.

The only problem who are annoying me, is when using texmacs as interface =
for axiom, it don't show the output when you do some input... in fact, it=
 show the first output only after several other inputs.
On command line it works fine.
Since i don't now how to explain exactly what are occurring, and even aft=
er look (and tried) several output settings with the help of hyperdoc, i'=
ll show a example:

(*texmacs started, first input, with multiline input disabled*)
-> integrate(log(x),x)   
->
->
->
->
-> 
   (1)  x log(x) - x
                                          Type: Union(Expression Integer,=
...)
(*look the blank inputs, i think the output need to be just after the inp=
ut*)

My axiom is the latest from Debian sid repository (2005/02/01), with all =
optional packages installed, and texmacs is 1.0.5 (latest of Debian sid t=
oo). All setting are default on both.
Since i really don't know if that is a bug or misconfiguration, i'm posti=
ng on devel group. I'm unable to find in the issue page of axiom wiki a s=
imilar problem.

\start
Date: Sat, 25 Jun 2005 23:00:47 -0500
From: Tim Daly
To: list
Subject: congrats

congrats to Kai! and thanks go to Hoew.

re: dependency tracking
I'd suggest reading the book section on the use of the
)frame command before designing anything new.

re: axiom web server
axiom already has an embedded web server of sorts.
i'll have to look for where the code exists but the main loop is there.

\start
Date: Sun, 26 Jun 2005 08:27:07 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#184 Complex argument is false.] (new) 

argument (-%i)    computes %pi/2 and not -%pi/2
argument (-1+0%i) computes 0 and not %pi
argument (-1) fails, perhaps it's possible to add an automatic coerce ?

Francois Maltey.

\start
Date: Sun, 26 Jun 2005 09:33:20 -0500
From: Tim Daly
To: Kai Kaminski
Subject: congrats

Kai,

I'll be in Berlin the first week of August.
If you're anywhere near there I can buy you a beer
and introduce you to my son who also lives in Germany 
and is looking to port Axiom to ansi common lisp.

\start
Date: Sun, 26 Jun 2005 10:03:05 -0500
From: Tim Daly
To: Kai Kaminski
Subject: congrats

Kai,

I'm actually less concerned about your design decisions or
your choice of tools, even XML if you feel you must. Do whatever
it takes to solve some part of the problem.

Believe it or not one of my main concerns is that the code
be well documented or should I say that "the document is
well coded". Try to keep the mindset that you're writing
a paper explaining the problems and their solutions rather than
the mindset that you're writing code and will "document" it later.

It's a hard transition to make but it's a hard lesson to learn
after the fact. Axiom will actually benefit more from a description
of what your plan of attack is, what tools you plan to use (along
with prototype skeleton examples), what the architecture and API 
you've chosen for communication (as well as code), what problems you
see that still need to be solved with pointers to parts of axiom
that might need changes, etc. In my recent experience of documenting
the current Axiom code every line of working code takes at least 10 
lines of documentation, which is much harder to construct if you
didn't write the code. I'm currently documenting the coercion
code and it's turned into a real research task.

It seems like a lot of work but you'll already be doing it in
your head and you'll benefit from having to think about it clearly
enough to write it down as you code it.

We'll all also benefit in the long term because the next programmer
to "pick up the torch" won't have to re-invent the world (like
embedding another web-server or maintaining "frames" of values that 
axiom can already do).

A second piece of advice is to "release often". I know it feels
like criticism when many people "jump in" but there are a large
number of very clever and motivated people on this list who can
be very helpful.

My last piece of advice is the make sure your work get integrated
into the overall "make". People who get open source expect it to
work "out of the box" by typing "make".

My "next+1" piece of advice is to have fun. Enjoy it, learn something
from it and do things because YOU think they're worth doing. That's
really the essence of open source programming.

I envy you your summer job.

\start
Date: Sun, 26 Jun 2005 10:10:06 -0500
From: Tim Daly
To: Constantine Frangos
Subject: Axiom on SUSE

It appears that you do not have the developer libraries for X11
installed. I have the RPM for RedHat but not for SUSE. There are
a set of libraries for X11 that are not needed for normal X11 use
but Axiom needs them because it include X11 code.

\start
Date: Sun, 26 Jun 2005 16:37:05 +0200
From: Constantine Frangos
To: list
Subject: (no subject)

I have tried to compile axiom on an amd64 3500+ machine running suse linux
9.2 (64 bit), but it did not work (see below).

Is it possible to compile axiom on this machine using 32 bit libraries only ?

Any assistance on what to do would be much appreciated - thanks.

Regards,

C. Frangos.


Output written on Makefile.dvi (50 pages, 96988 bytes).
Transcript written on Makefile.log.
make[1]: Entering directory `/home/apps/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=/home/apps/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp
DAASE=/home/apps/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
18 making /home/apps/axiom/src
make[2]: Entering directory `/home/apps/axiom/src'
1 making /home/apps/axiom/src/scripts
make[3]: Entering directory `/home/apps/axiom/src/scripts'
1 making /home/apps/axiom/src/scripts
make[3]: Leaving directory `/home/apps/axiom/src/scripts'
17 making /home/apps/axiom/src/lib
make[3]: Entering directory `/home/apps/axiom/src/lib'
72 finished making /home/apps/axiom/src/lib
make[3]: Leaving directory `/home/apps/axiom/src/lib'
make[2]: Leaving directory `/home/apps/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=/home/apps/axiom/mnt/linux/compiler O=o BYE=bye LISP=lsp
DAASE=/home/apps/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 /home/apps/axiom/src/scripts to /home/apps/axiom/mnt/linux/bin
19 making /home/apps/axiom/lsp
make[2]: Entering directory `/home/apps/axiom/lsp'
make[2]: `gcldir' is up to date.
make[2]: Leaving directory `/home/apps/axiom/lsp'
15 making /home/apps/axiom/src
make[2]: Entering directory `/home/apps/axiom/src'
21 making /home/apps/axiom/src/boot
make[3]: Entering directory `/home/apps/axiom/src/boot'
make[3]: `/home/apps/axiom/obj/linux/bin/bootsys' is up to date.
make[3]: Leaving directory `/home/apps/axiom/src/boot'
25 making /home/apps/axiom/src/interp
make[3]: Entering directory `/home/apps/axiom/src/interp'
618 finished /home/apps/axiom/src/interp
make[3]: Leaving directory `/home/apps/axiom/src/interp'
9 making /home/apps/axiom/src/share
make[3]: Entering directory `/home/apps/axiom/src/share'
3 finished /home/apps/axiom/src/share
make[3]: Leaving directory `/home/apps/axiom/src/share'
29 making /home/apps/axiom/src/algebra
make[3]: Entering directory `/home/apps/axiom/src/algebra'
4304 Building NRLIBS from spad sources
4302 finished /home/apps/axiom/src/algebra
make[3]: Leaving directory `/home/apps/axiom/src/algebra'
37 making /home/apps/axiom/src/etc
make[3]: Entering directory `/home/apps/axiom/src/etc'
6 finished /home/apps/axiom/src/etc
make[3]: Leaving directory `/home/apps/axiom/src/etc'
5 making /home/apps/axiom/src/clef
make[3]: Entering directory `/home/apps/axiom/src/clef'
6 finished /home/apps/axiom/src/clef




make[3]: Leaving directory `/home/apps/axiom/src/clef'
41 making /home/apps/axiom/src/doc
make[3]: Entering directory `/home/apps/axiom/src/doc'
9 finished /home/apps/axiom/src/doc
make[3]: Leaving directory `/home/apps/axiom/src/doc'
45 making /home/apps/axiom/src/graph
make[3]: Entering directory `/home/apps/axiom/src/graph'
1 making /home/apps/axiom/src/graph/viewman
make[4]: Entering directory `/home/apps/axiom/src/graph/viewman'
1 linking /home/apps/axiom/mnt/linux/lib/viewman
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux/bin/
ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for -lX11
 /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux/bin
/ld: skipping incompatible /usr/X11R6/lib/libX11.a when searching for -lX11
 /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux/bin
/ld: cannot find -lX11
collect2: ld returned 1 exit status
make[4]: *** [/home/apps/axiom/mnt/linux/lib/viewman] Error 1
make[4]: Leaving directory `/home/apps/axiom/src/graph/viewman'
make[3]: *** [viewmandir] Error 2
make[3]: Leaving directory `/home/apps/axiom/src/graph'
make[2]: *** [graphdir] Error 2
make[2]: Leaving directory `/home/apps/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/apps/axiom'
make: *** [all] Error 2

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

\start
Date: Sun, 26 Jun 2005 18:27:41 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: congrats

Hi Tim,

thanks for your mail.

>A second piece of advice is to "release often". I know it feels
>like criticism when many people "jump in" but there are a large
>number of very clever and motivated people on this list who can
>be very helpful.
>  
>
I'm planning to do that. When I said earlier that "all hell broke loose" 
I didn't mean it like that. I was just a bit overwhelmed.

>My last piece of advice is the make sure your work get integrated
>into the overall "make". People who get open source expect it to
>work "out of the box" by typing "make".
>  
>
I'm not sure if I like this one. Makefiles aren't very lispy in the 
first place and they add some complication for little gain. I'm sure if 
someone can be bothered to download and compile an experimental version 
of Axiom he can be bothered to type make twice. For end users we should 
offer binaries.

>My "next+1" piece of advice is to have fun. Enjoy it, learn something
>from it and do things because YOU think they're worth doing. That's
>really the essence of open source programming.
>  
>
I certainly will :-)

>I envy you your summer job.
>  
>
I'm sure you do. I still can't believe I made it.

\start
Date: Mon, 27 Jun 2005 00:24:48 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: AxiomUI development process

On June 26, 2005 12:22 PM Kai Kaminski wrote:

> before we start working on AxiomUI we should work out how
> to organize development. This is a quick list of some thoughts
> and questions:
>
> I don't know MathAction very well, so I don't know what role
> it could play.

I assume that was question? :)

MathAction is a web site that can be easily modified over
the web (usually called a wiki). Web pages on MathAction can
contain display LaTeX mathematics and can run Axiom and Reduce
commands which display output as LaTeX mathematics. It also
has a web-based application called "IssueTracker" for user
problem reports. Besides that it is just a web site that can
do all the things that web sites do these days, so what role
it can play is basically wide-open.

> I believe that it would be good to keep AxiomUI separate
> from Axiom, hence I have already asked for a new project at
> Savannah. If you disagree, we can always remove the project
> again. The reason for this is that it allows me to get up
> and running faster (I hope).

I don't really have a problem with that. My view is that as
one of the project "mentors" I have agreed to be more vocal
about my advice (especially when you ask) but I don't intend
to try to influence your work in on this project in any other
way except as I would any other open source colleague. This is
open source development and the AxiomUI project is your show.
You should use whatever open source tools that you find useful
and efficient, e.g. Savannah, SourceForge, MathAction or whatever.

The Axiom project still maintains project sites on both Savannah
and Sourceforge but most of the ongoing development and user
support is now done on MathAction.

> ...
> Which license do we want to use? Do I have to assign the
> copyright to someone?

For maximum compatibility with Axiom itself, I would suggests
a BSD-style license based on the Axiom main license. Axiom
already has multiple open source licenses and I don't see any
harm in adding a new one compatible with the existing licenses
but specific to AxiomUI and more up to date, if you think that
might be a good idea.

Copyright to Axiom itself is held by Numerical Algorithms Group
as part of the agreement that lead to the release of Axiom as
open source. Since the BSD license is very "free and open"
I don't think copyright is such an important issue. My personal
preference would be for copyright to be held by an independent
group specifically devoted to Axiom such as the Axiom Foundation
but since the Axiom Foundation is not legally incorporated under
any national or international law, that might be impossible.
So the next best choice I think is if you simply retain your
personal copyright on the work (for now at least).

> Finally I would like to avoid the Axiom build system.
> I haven't really seen it yet, but Axiom doesn't build on
> my favourite box anyway

I think Axiom has been build on MAC OS/X with some tweaking.
(check the axiom-developer email archives). If the current
release does not build on your system out-of-the-box, then
I think you should report the problem to the axiom-developers :)

> and besides makefiles aren't very lispy.

Not true, although I agree there are other similar tools
implemented in lisp, just like there similar tools for Java
(e.g. ANT). But make is (almost) universal in open source.

> If we decide to use it, someone will have to help me with
> the makefiles. I haven't used any for at least two or three
> years.

No problem. Just ask.

> I understand that we need excellent documentation, but I'm
> not sure how Lisp and literate programming go together.

Lisp and literate programming work just fine. For example:
see the Axiom source code. :)

> Due to Lisps dynamic nature doc strings and comments seem to
> be a more natural fit, but maybe I'm wrong.

Literate programming is a style that assumes writing a program
is better viewed as writing a document (i.e something intended
to be read comfortably by a human being) that contains and fully
describes all of the programming code necessary to implement a
program. This does not conflict with "lisps dynamic nature"
(whatever that is?) any more than any other programming language.
>From the point of view of literate programming doc strings and
comments are not of much use.

> In that case I would love to hear how your typical development
> work goes. How do you use slime or just any CL environment with
> noweb?

As far as I know, and could determine from a quick web search, no
one does this in an integrated manner. But you can certainly use
emacs to write a noweb document. Automating the noweb weave to
generate documentation and the noweb tangle to generate lisp source
is possible. Then using Slime to develop and test the lisp code is
easy. But properly re-inserting the new lisp code back into the
noweb document along with appropriate text would require some
extra discipline.

> Ok, I just received an email from Tim. On the one hand he gives
> me quite a bit of leeway, on the other hand his advice contradicts
> my points about the Axiom build system and literate programming.
> What are your feelings about this?

I agree with Tim about the importance of literate programming to
the Axiom project as a whole. I would really like the AxiomUI
project also to use this style of programming. Axiom currently
uses the noweb for literature programming throughout, I do not
think that this is necessarily the best available tool for the
job, but it works. 

> The one thing I feel strongest about is to separate Axiom's
> mathematical core and its user interface into separate processes.
> ...
> 3) Somebody else might want to develop another GUI. If we modify
> Axiom so that it speaks some sexp-based protocol that's not a
> problem.

I think modifying Axiom so that it speaks "some sexp-based
protocol" as well as it now produces LaTeX is probably a be *big*
project that would require quite deep knowledge of Axiom internals.
It is probably beyond what you would want to get into during the
time frame of the Summer of Code funded part of this project.
There has been some previous work by NAG to implement OpenMath
as an output format for Axiom but even reviving that is very
likely another *big* project.

I think that in the initial design of AxiomUI you should assume
that Axiom will deliver it's output to the back-end gui process
in LaTeX format. To do otherwise would mean having to duplicate
all of what Axiom does right now in rendering LaTeX.

Later enhancements such as graphically manipulating sub-expressions
might well require a more sophisticated format but I think that
borders on research rather than implementation.

\start
Date: Mon, 27 Jun 2005 00:39:08 -0400
From: Bill Page
To: Kai Kaminski, Bob McElrath
Subject: RE: AxiomUI project funded

On June 26, 2005 5:18 AM Kai Kaminski wrote:

> ...
> It seems obvious to me that using a web browser to replace hyperdoc
> is a good idea. A browser can also be used to implement a GUI,
> although I would love to see a portable GUI written in CL using
> wxWidgets bindings (which don't exist yet).

Also not easily portable to Windows, I think.

> I'm not so fond of TeXmacs though. While it is a great piece of
> software it has been a bit sluggish when I used it in the past.
> It also doesn't look very native on OS X and presumably Windows.

The Windows version is "ok" but you are right that it does not
look completely "native".

> It also uses TeX to render its output I believe.

No. It has it's own renderer. TeX is not used but it does
use TeX fonts.

> That's good for quality but not so good for development.

TeXmacs typeset quality is very good and it's conversion from
LaTeX (such as used by the Axiom interface for TeXmacs) is
good but not perfect. I think quite a few people do use Axiom
this way on both Linux and Windows.

But I think the idiosyncratic style of TeXmacs C++ source code
is also not so good for development.

> Since cl-typesetting seems to be very much alive and under
> active development by some of the best OSS Lisp developers
> it might be possible to develop a GUI from scratch.

Sounds way too much like hard work to me!

\start
Date: Mon, 27 Jun 2005 00:23:39 -0500
From: Tim Daly
To: Kai Kaminski
Subject: (no subject)

Kai,

As I mentioned it is important to the long term goals of the project
that we document the new work we are doing. The original developers,
including myself, did not do a good job documenting the system which
makes it very difficult to maintain and modify. Going forward we don't
want to continue making the same mistake.

Attached is a simple, stripped down pamphlet file that uses lisp.

This document contains the explanation of the lisp code, it contains
the source code for the lisp, and it contains a Makefile to build itself.

You need to extract the Makefile before you can use it. This is done with
the 'notangle' command from noweb. Once you've extracted the Makefile all
you ever need to type is 'make' and everything is automatically rebuilt.
That way you can write a new paragraph, add new code and type 'make'.

As this was literally ripped out of my local working environment it's
not likely that it will run the first time but it should be close.

To use this file you need to 
  (0) store this file somewhere (e.g. /tmp/autodoc.lisp.pamphlet)
  (1) get noweb-2.10a.tgz 
        cd /tmp
        mkdir noweb
        cd noweb
        wget http://daly.axiom-developer.org/noweb-2.10a.tgz
  (2) untar noweb
        tar -zxf noweb-2.10a.tgz
  (3) make noweb
        ./awkname gawk
        make all install
      this will install a few commands, two of which you need.
      One is called 'notangle' and the other is 'noweave'.
      Be sure they show up on your path.
  (4) extract the makefile using notangle. (notangle is a command 
      to extract code from a pamphlet. noweave is a command to 
      extract latex from a pamphlet)
        cd /tmp
	notangle autodoc.lisp.pamphlet >Makefile                
  (5) get axiom.sty
        wget http://daly.axiom-developer.org/axiom.sty
  (6) modify the Makefile to point at your lisp command and
      your notangle and noweave commands.
  (7) build the document and run the lisp code
        make

If you do
        xdvi autodoc.dvi &
        emacs autodoc.lisp.pamphlet
           (and start an emacs subshell)
        then you can modify the file 
             type make
             and switch the focus to the xdvi window which will
             automatically refresh with the new changes.
It's a very fast way to develop a pamphlet file.

Let me know if you need more detail or can't get it to work.

===================================================================
\documentclass{article}
\usepackage{axiom}
\begin{document}
\title{Autodoc}
\author{Tim Daly}
\maketitle
\begin{abstract}
We want to generate the reference information from axiom source
files automatically.
\end{abstract}
\eject
\tableofcontents
\eject
By design the chunk name has 3 fields. 
The first field is one of \{category, domain, package\}.
The second field is the abbreviation.
The third field is the full name.
This routine will return two lists, the first is the list of
abbreviations and the second is the list of full names.

We keep looping until we run out of input, at which point we
throw out of the loop and catch it here.
<<until done>>=
  (catch 'done
@
We open the source file
<<open source file>>=
   (with-open-file (in sourcefile)
@
We read each line, trimming off trailing spaces
<<for each line do>>=
    (loop
     (setq expr (read-line in nil 'done))
     (when (eq expr 'done) (throw 'done nil))
     (setq expr (string-trim '(#\space) expr))
@
We look for lines that begin with a chunk name that
starts with package, domain, or category and end with an
equal sign (which indicates a chunk definition).
<<when package domain or category definition>>=
     (when 
      (and (> (length expr) 4)
           (or
            (string= "@<<pa" (subseq expr 0 4))
            (string= "@<<do" (subseq expr 0 4))
            (string= "@<<ca" (subseq expr 0 4)))
           (char= (elt expr (1- (length expr))) #\=))
@
We remove the 3 characters, two $>$ and an $=$ which make up the chunk name.
<<remove the trailing chunk characters>>=
      (setq expr (subseq expr 0 (- (length expr) 3)))
@
We get the third field from the string which is the long name.
<<capture the long name>>=
      (setq point (position #\space expr :from-end t :test #'char=))
@
We get the second field from the string which is the abbreviation.
<<capture the abbreviation>>=
      (setq mark
       (position #\space 
        (string-right-trim '(#\space)
         (subseq expr 0 (1- point))) :from-end t))
      (push (string-trim '(#\space) (subseq expr mark point)) names)))))
@
<<srcabbrevs>>=
(defun srcabbrevs (sourcefile)
 (let (in expr start end names longnames)
<<until done>>
<<open source file>>
<<for each line do>>
<<when package domain or category definition>>
<<remove the trailing chunk characters>>
<<capture the long name>>
      (format t "~a ~a ~a~%" expr point longnames)
<<capture the abbreviation>>
  (values names longnames))))

@
\section{Doit}
<<doit>>=
(srcabbrevs "/new/patch38/src/algebra/acplot.spad.pamphlet")

@
\section{Autodoc}
<<autodoc>>=
<<srcabbrevs>>
<<doit>>
@
\section{Makefile}
<<*>>=
TANGLE=/usr/local/bin/notangle -t8 
WEAVE=/usr/local/bin/noweave -delay
LISP=/new/patch38/obj/linux/bin/lisp

all: code doc run

code: autodoc.lisp.pamphlet
	@${TANGLE} -Rautodoc autodoc.lisp.pamphlet >autodoc.lisp

doc: autodoc.lisp.pamphlet
	@${WEAVE} autodoc.lisp.pamphlet >autodoc.tex
	@latex autodoc.tex
	@latex autodoc.tex

run: autodoc.lisp
	@cat autodoc.lisp | ${LISP}

remake:
	@${TANGLE} autodoc.lisp.pamphlet >Makefile

@
\eject
\begin{thebibliography}{99}
\bibitem{1} nothing
\end{thebibliography}
\end{document}

\start
Date: Mon, 27 Jun 2005 10:05:09 +0200
From: Kai Kaminski
To: list
Subject: re: AxiomUI development process

Hi Bill!

Bill Page wrote:

>>I believe that it would be good to keep AxiomUI separate
>>from Axiom, hence I have already asked for a new project at
>>Savannah. If you disagree, we can always remove the project
>>again. The reason for this is that it allows me to get up
>>and running faster (I hope).
>>    
>>
>
>I don't really have a problem with that. My view is that as
>one of the project "mentors" I have agreed to be more vocal
>about my advice (especially when you ask) but I don't intend
>to try to influence your work in on this project in any other
>way except as I would any other open source colleague. This is
>open source development and the AxiomUI project is your show.
>You should use whatever open source tools that you find useful
>and efficient, e.g. Savannah, SourceForge, MathAction or whatever.
>  
>
I'd certainly appreciate if you were very vocal about your advice. I 
also reconsidered and am now convinced that I should probably put 
AxiomUI in the Axiom source tree. This leads to the next question: 
Should we have a new branch of AxiomUI?

>>...
>>Which license do we want to use? Do I have to assign the
>>copyright to someone?
>>    
>>
>
>For maximum compatibility with Axiom itself, I would suggests
>a BSD-style license based on the Axiom main license. Axiom
>already has multiple open source licenses and I don't see any
>harm in adding a new one compatible with the existing licenses
>but specific to AxiomUI and more up to date, if you think that
>might be a good idea.
>  
>
I must admit that I have no good understanding of the differences 
between all the open source licenses. I have a rough idea about GPL and 
BSD, but that's about it. I'll just look at Axiom and try to do the same 
if no-one stops me.

>>Finally I would like to avoid the Axiom build system.
>>I haven't really seen it yet, but Axiom doesn't build on
>>my favourite box anyway
>>    
>>
>  
>
Forget about this. I'll try to put everything into the Axiom source tree 
and integrate it with Axiom's build system.

>I think Axiom has been build on MAC OS/X with some tweaking.
>(check the axiom-developer email archives). If the current
>release does not build on your system out-of-the-box, then
>I think you should report the problem to the axiom-developers :)
>
>  
>
I did and I found some discussions but no report of success. I'll write 
an email to the Axiom-OS X people.

>>and besides makefiles aren't very lispy.
>>    
>>
>
>Not true, although I agree there are other similar tools
>implemented in lisp, just like there similar tools for Java
>(e.g. ANT). But make is (almost) universal in open source.
>
>  
>
That's not quite what I meant. In a C project with makefiles the typical 
workflow is roughly like this:

- write some code
- run make
- run program => crash/bug/...
- iterate

With Lisp it's different. I load the libraries and the existing code in 
my Lisp image and modify everything while it's running. For example I've 
done some simple experiments with Araneida (a CL web server) and never 
had to restart it even once. In that sense makefiles are unlispy.

>>If we decide to use it, someone will have to help me with
>>the makefiles. I haven't used any for at least two or three
>>years.    
>>    
>>
Tim has taken care of this problem by sending me a makefile with comments.

>>I understand that we need excellent documentation, but I'm
>>not sure how Lisp and literate programming go together.
>>    
>>
>
>Lisp and literate programming work just fine. For example:
>see the Axiom source code. :)
>  
>
I'm more concerned with using Slime and literate programming at the same 
time. But I'll probably do it anyway.

>>In that case I would love to hear how your typical development
>>work goes. How do you use slime or just any CL environment with
>>noweb?
>>    
>>
>
>As far as I know, and could determine from a quick web search, no
>one does this in an integrated manner. But you can certainly use
>emacs to write a noweb document. Automating the noweb weave to
>generate documentation and the noweb tangle to generate lisp source
>is possible. Then using Slime to develop and test the lisp code is
>easy. But properly re-inserting the new lisp code back into the
>noweb document along with appropriate text would require some
>extra discipline.
>  
>
The latter is exactly what I'm worrying about. But I'll find a way.

>>The one thing I feel strongest about is to separate Axiom's
>>mathematical core and its user interface into separate processes.
>>...
>>3) Somebody else might want to develop another GUI. If we modify
>>Axiom so that it speaks some sexp-based protocol that's not a
>>problem.
>>    
>>
>
>I think modifying Axiom so that it speaks "some sexp-based
>protocol" as well as it now produces LaTeX is probably a be *big*
>project that would require quite deep knowledge of Axiom internals.
>It is probably beyond what you would want to get into during the
>time frame of the Summer of Code funded part of this project.
>There has been some previous work by NAG to implement OpenMath
>as an output format for Axiom but even reviving that is very
>likely another *big* project.
>  
>
I'm surprised that this should be difficult. After all Axiom is written 
in Lisp and presumably has all its data in Lisp data structures anyway. 
But I'll look into this. If it's too hard, I'll do something else.

>I think that in the initial design of AxiomUI you should assume
>that Axiom will deliver it's output to the back-end gui process
>in LaTeX format. To do otherwise would mean having to duplicate
>all of what Axiom does right now in rendering LaTeX.
>  
>
Actually I might keep LaTeX format for math output, because jsMath can 
render that directly. But Axiom has output other than mathematical 
expressions, e.g. plots.

\start
Date: Mon, 27 Jun 2005 10:08:28 +0200
From: Kai Kaminski
To: list
Subject: re: AxiomUI project funded

Hi Bill!

Bill Page wrote:

>On June 26, 2005 5:18 AM Kai Kaminski wrote:
>
>  
>
>>...
>>It seems obvious to me that using a web browser to replace hyperdoc
>>is a good idea. A browser can also be used to implement a GUI,
>>although I would love to see a portable GUI written in CL using
>>wxWidgets bindings (which don't exist yet).
>>    
>>
>
>Also not easily portable to Windows, I think.
>  
>
WxWidgets are very portable. The bindings could be, they don't exist yet.

>>I'm not so fond of TeXmacs though. While it is a great piece of
>>software it has been a bit sluggish when I used it in the past.
>>It also doesn't look very native on OS X and presumably Windows.
>>    
>>
>
>The Windows version is "ok" but you are right that it does not
>look completely "native".
>  
>
Since Tim wants a mind-blowing, novel GUI "ok" is probably not enough ;-)

>>No. It has it's own renderer. TeX is not used but it does
>>use TeX fonts.
>>    
>>
Oh, I obviously didn't know that. If we ever want to render math 
ourselves we might want to steal their code.

>>Since cl-typesetting seems to be very much alive and under
>>active development by some of the best OSS Lisp developers
>>it might be possible to develop a GUI from scratch.
>>    
>>
>
>Sounds way too much like hard work to me!
>  
>
Yes, it is too hard for now. But within the next thirty years, who 
knows. Besides a lot of the work would be done by other people.

\start
Date: Mon, 27 Jun 2005 04:44:41 -0700
From: Bob McElrath
To: list
Subject: Tiddly Axiom Wiki

I have gotten a preliminary *local* web-browser interface for Axiom
working.  It uses pipes for communication.  Get it here:
    http://bob.mcelrath.org/moz-axiom.tar.gz
Un tar it, change to the moz-axiom directory that will be created, and
run: ./fifo-axiom
This will start axiom and set up communications pipes to talk to the web
browser, then attempt to run firefox.  (edit this script if you want to
use mozilla or some other browser -- but only mozilla-derived browsers
will work) I copied an example from hyperdoc on Hilbert Matrices just to
test.

Also I implemented lazy re-evaluation the maximally stupid way: each new
tiddler is fully re-evaluated (e.g. I issue a )clear all first).

Please play with it, I hope it can be a means of discussing exactly how
(and if) we want to involve a web browser in all this.

The tiddlywiki extensions I made earlier (allowing $x$) are still there.

Axiom commands are included in \begin{axiom}...\end{axiom} just like on
the MathAction Wiki, and in addition I copied some of Kai's work to add
an input line to each tiddler.

While I'm still disappointed with the rendering speed of jsMath (we can
move to MathML in the future), it's quite a bit snappier than texmacs.
Make sure to turn animations off in the options panel.

Undoubtedly there are bugs, but this is more a toy prototype...

\start
Date: Mon, 27 Jun 2005 10:19:13 -0400
From: Bill Page
To: Constantine Frangos
Subject: Axiom on x86-64 architectures

On June 26, 2005 10:37 AM C. Frangos wrote:

> I have tried to compile axiom on an amd64 3500+ machine running
> suse linux 9.2 (64 bit), but it did not work (see below).

I run Axiom on Fedora Core 3 x86-64 on an amd64 3500+ machine.
It's nice! GCL and Axiom are really fast on this architecture.
To get it to build I had to make some simple changes to the
Makefile.pamphlet. See below.

>
> Is it possible to compile axiom on this machine using 32 bit
> libraries only ?
>

It is possible, but it is not necessary. Obviously 64 bit is
better.

>Any assistance on what to do would be much appreciated - thanks.

For a quick fix, you need to find the secion of the Makefile.pamphlet
that applies to your configuration. In my case it is the code chunk
named <<Makefile.fedora3>>. Then you need to change a variable that
points to the X libraries. These are marked by ### below.

In Makefile.pamphlet:

<<Makefile.fedora3>>=
# System dependent Makefile for the Intel/Linux platform (Fedora Core 3)
# Platform variable
PLF=LINUXplatform
# C compiler flags
CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE -D${PLF} -
I/usr/X11/include"
# Loader flags
LDF= -L/usr/X11R6/lib64               ### change for x86-64 architecture
# C compiler to use
CC=gcc
AWK=gawk
RANLIB=ranlib
TOUCH=touch
TAR=tar
AXIOMXLROOT=${AXIOM}/compiler
O=o
BYE=bye
LISP=lsp
DAASE=${SRC}/share
# where the libXpm.a library lives
XLIB=/usr/X11R6/lib                          
<<GCLOPTS-LOCBFD>>
<<SRCDIRS>>

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

After you edit Makefile.pamphlet. You should do

  .\configure
    (set env. vars.)
  make clean
  make

The proper way to do this of course would be to modify the
Axiom ./configure to recognize the machine architecture and
then to write a separate chunk in the Makefile.pamphlet for
that architecture.

During the sprint session at the Axiom meeting this spring we
all agreed that Axiom should adopt the standard autoconfig
tools that are used in many (most?) other open source projects
to identify machine architectures and configure the Axiom
makefiles. Camm said he would look at this but obvious he has
his hands full. If there are any other Axiom developers out
there that have some time to spend doing this, I think
everyone would really appreciate it!

> ...
> 45 making /home/apps/axiom/src/graph
> make[3]: Entering directory `/home/apps/axiom/src/graph'
> 1 making /home/apps/axiom/src/graph/viewman
> make[4]: Entering directory `/home/apps/axiom/src/graph/viewman'
> 1 linking /home/apps/axiom/mnt/linux/lib/viewman
>
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux
/bin/
> ld: skipping incompatible /usr/X11R6/lib/libX11.so when searching for
-lX11
>
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux
/bin
> /ld: skipping incompatible /usr/X11R6/lib/libX11.a when searching for
-lX11
>
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.4/../../../../x86_64-suse-linux
/bin
> /ld: cannot find -lX11
> collect2: ld returned 1 exit status
> make[4]: *** [/home/apps/axiom/mnt/linux/lib/viewman] Error 1
> make[4]: Leaving directory `/home/apps/axiom/src/graph/viewman'
> make[3]: *** [viewmandir] Error 2

This error message is cause by a wrong setting for the
variable LDF in the Makefile.pamphlet section that applies
to your machine architecture. You need to change this as
specified above.

\start
Date: Mon, 27 Jun 2005 17:15:19 +0200
From: Kai Kaminski
To: list
Subject: Re: Tiddly Axiom Wiki

Hi Bob!

Bob McElrath wrote:

>Please play with it, I hope it can be a means of discussing exactly how
>(and if) we want to involve a web browser in all this.
>  
>
I played with it and I like it a lot. I haven't looked at the source 
code yet. I also think that eventually we will have to use sockets 
instead of pipes, as AJAX only works over sockets. There might be some 
Mozilla specific feature that allows something similar for pipes but I'm 
not sure if we should give up portability so easily.

I'll look at it again later.

\start
Date: Mon, 27 Jun 2005 10:59:15 -0700
From: Bob McElrath
To: Kai Kaminski
Subject: Re: Tiddly Axiom Wiki

Kai Kaminski [Kai Kaminski] wrote:
> Hi Bob!
> 
> Bob McElrath wrote:
> 
> >Please play with it, I hope it can be a means of discussing exactly how
> >(and if) we want to involve a web browser in all this.
> > 
> I played with it and I like it a lot. I haven't looked at the source 
> code yet. I also think that eventually we will have to use sockets 
> instead of pipes, as AJAX only works over sockets. There might be some 
> Mozilla specific feature that allows something similar for pipes but I'm 
> not sure if we should give up portability so easily.

I think we should give up portability so easily.  We should write to the
standards XML/XHTML/MathML/SVG, and the only browser which supports all
this in one document is Mozilla.  Furthermore our application can be an
XPCOM component, and therefore not be restricted to the minimalistic set
of API's available to javascript.

One of the biggest problems with this example is that the file reads
will block if you're not careful.  AJAX won't have this problem.  But, I
leave hacking a web server into axiom to you.  ;)

\start
Date: Mon, 27 Jun 2005 18:42:42 -0500
From: MathAction (billpage)
To: MathAction
Subject: [Kai Kaminski] (new) 

Biography

  Kai Kaminski is a student of mathematics and computer science with a
strong background in programming. While in high-school he was mostly
interested in computer graphics and low-level programming. Later his
focus shifted to high-level languages and algorithmic problems. His
interests cover pure as well as applied mathematics, software
development and theoretical computer science. Before discovering his
affinity towards Lisp in general and Common Lisp in particular he used
Python, C and, to a lesser extent, C++. He also seems to fondly
remember bits and pieces of Pascal, x86 Assembler and several Basic
dialects. University-related and commercial projects allowed him to
gain valuable experience in software development. Among those projects
were the design and implementation of large parts of a vector drawing
application and a module to control a soccer team of Lego Mindstorm
robots. Last year he was member of a small team taking part in the
ICFP contest placing 44th and 63rd out of 361 participants (Team
Pants, http://www.cis.upenn.edu/proj/plclub/contest/results.php). His
mathematical interests cover data mining and wavelet-based compression
as well as several pure fields in analysis.

\start
Date: Mon, 27 Jun 2005 18:51:02 -0500
From: MathAction (billpage)
To: MathAction
Subject: [MathML] (new) 

http://www.w3.org/Math/

What is MathML?

  !MathML 2.0, a W3C Recommendation was released on 21 Feb 2001. A product
of the W3C Math working group, !MathML is a low-level specification for
describing mathematics as a basis for machine to machine communication.
It provides a foundation for the inclusion of mathematical expressions
in Web pages.

\start
Date: Mon, 27 Jun 2005 18:41:50 -0500
From: MathAction (billpage)
To: MathAction
Subject: [AxiomUI] (new) 

by [Kai Kaminski]

Synopsis

  The goal of this project is to provide a portable and user-friendly
graphical user interface for the Axiom computer algebra system. The
implementation described in this proposal takes advantage of the
capabilities of modern web browsers to achieve both goals.

Benefits to the Lisp/OSS community

  The Common Lisp community will benefit from this project in three
ways. First of all new libraries will be created, for example to
generate well-formed SVG (and possibly X3D) output. Already available
libraries will receive testing on multiple platforms and consequent
improvements if necessary. Finally it will serve as an example for the
construction of platform independent user interfaces.
For the broader OSS community the most interesting aspect of this
project will be easier access to the Axiom computer algebra
system. Axiom is unique among open source projects through its scope
and vision. It strives to provide and open and powerful platform for
computational mathematics and related fields (see [1] for
details). Its potential users are researchers, teachers and students
alike. While the kernel of Axiom is very mature after more than thirty
years of ongoing development, the need of a modern, portable user
interface has become obvious.

.. [1] http://page.axiom-developer.org/zope/mathaction/AboutAxiom

Deliverables

  The graphical user interface described in this proposal will have the
following properties:

- It allows interaction with Axiom in a fashion similar to
  Mathematica, that is

  1  one can browse the Axiom hypertext documentation

  2  it is possible to enter a command on a page and have the input as
     well as the result appended to the same page without a page reload

  3  mathematical expressions are displayed in reasonable quality
     almost matching that of TeX

- It is portable to most platforms including but not limited to
  Linux/Unix running Firefox, Windows
  running IE or Firefox, and MacOS X running Safari or Firefox.

- It is able to display static two-dimensional plots generated by
  Axiom. The plots are of production quality so that they can be used
  in scientific publications. Animated two-dimensional and
  three-dimensional plots will be easy to integrate. In fact, this
  will be implemented during this project if time permits.

- It is solely implemented in portable Common Lisp and languages which
  are understood by web browser, i.e. HTML, Javascript, CSS. It does
  not require any external programs beyond a web browser or the use of
  a foreign function interface. It tries to conform to existing or
  upcoming W3C standards as far as possible.

- It meets all other requirements contained in the project description
  at http://www.alphageeksinc.com/cgi-bin/lispnyc.cgi?AxiomUI. The
  code will also adhere to the general coding standards and design
  guidelines of the Axiom project, e.g. literal programming.


Project Details

  AxiomUI will consist of two components. A simple, standalone http
server written in Common Lisp and a collection of Javascript
functions. The server component connects to Axiom and provides the
Javascript front-end access to Axiom's mathematical functionality. It
is also responsible for converting the pages of the Axiom hypertext
system to HTML.
The Javascript component will change the web browser into a fully
featured user interface. The most important aspects are to support the
user entering 
commands and to dynamically modify the page to incorporate Axiom's
answers to the user's requests. Furthermore the Javascript component
will provide convenience functions, e.g. writing a transcript of the
session as a LaTeX document.

Implementation of the server

  The server will contain a small portability layer for networking and
possibly file i/o. Beyond that it is written in ANSI Common
Lisp. The other components of the server are a parser for Axiom's
hypertext page description language, HTML and SVG generators and code
to implement the Ajax mechanism and to translate messages between the
Javascript front-end and Axiom.

The parser for the Axiom hypertext documentation pages will probably
be written from scratch. If convenient existing parser generators for
Common Lisp might be used.

To display static two-dimensional plots the server will generate SVG
files. SVG allows a high degree of control over the appearance of the
output and is reasonably well supported by modern browser. There are
also free viewers for a wide range of platforms. As a bonus, SVG files
allow the embedding of Javascript. This could be used to create
animations or even embed some controls for the modification of a plot
into the corresponding SVG file.

Implementation of the Javascript front-end

  The Javascript front-end will be written from scratch apart from
jsMath, a library which allows the display of complicated mathematical
formulas in browser without MathML support. While MathML would be the
cleaner way to display mathematics in a web browser it is not
sufficiently well supported by current browsers. A later release of
AxiomUI might of course take advantage of the then (hopefully)
improved MathML support. Using jsMath has the additional advantage
that it will not be necessary to parse LaTeX math syntax and convert
it to MathML, a non-trivial problem.

While working on this proposal the author implemented prototypes
for some of the techniques described above to make sure that this
implementation strategy actually works.

\start
Date: Mon, 27 Jun 2005 20:01:12 -0500
From: MathAction (TIm Daly)
To: MathAction
Subject: [Summer of Code] 

++added:

<li> Television/DVD presentation<br>

<p> We need to design and script an effective introduction to Axiom
  for new users. The most effective way to do this (at least from the
  new user's point of view) would be a DVD/TV kind of presentation.
  Rather than just a dry presentation of fact we would need to script
  a light, fast-moving presentation similar to the courses by
  <a href="http://www.cerebellum.com/">Cerebellum</a> on General Chemistry.
  This would require background in areas like video editing, script writing,
  production, direction, etc. and would be ideal for a liberal arts person
  who wanted to explore educational activities. For an online example view
  <a href="http://www.go-opensource.org/">go-opensource</a>. If done carefully
  it could be coordinated with <a href="http://ocw.mit.edu/index.html">MIT</a>.
  MIT's Open Courseware Site has their Mathematics online and some courses,
  notably Gilbert Strang's Linear Algebra (18.06) has a complete 
  <a href="http://ocw.mit.edu/OcwWeb/Mathematics/18-06Linear-AlgebraFall2002/VideoLectures/index.htm">
  video lecture</a> online.



++added:

<li> Simulation integration<br>

<p> There is a bridge simulation game called Pontefex (now called
  Bridge Builder, I believe) by <a href="http://www.bridgebuilder-game.com/links.php">
  ChronicLogic</a>. Bridges are constructed from beams. Beams can be modeled
  by two matrices, one at each end. Forces can be vectors and can be 
  applied and resolved into forces of compression or tension, twisting
  or bending. All of these can be written using Axiom. So the idea is to
  combine the Bridge Builder program with Axiom in order to be able to 
  model the forces on a bridge and try to accurately predict where the
  bridge will fail prior to running the simulation. 

<p> This would combine Axiom with a commercial product to better illustrate
  the power available. It would require contacting the company, negotiating
  the deal, and leading a project to integrate the two pieces of software in
  effective ways. Overall, a very big, long term project.

\start
Date: Mon, 27 Jun 2005 20:46:36 -0500
From: Tim Daly
To: Bill Page, Kai Kaminski
Subject: cross-platform api

See http://www.libsdl.org/index.php

\start
Date: Mon, 27 Jun 2005 20:26:59 -0700
From: Bob McElrath
To: Kai Kaminski
Subject: Re: AxiomUI project funded

Kai Kaminski [Kai Kaminski] wrote:
> Sure. The cl-typesetting library is currently developed by Marc Battyani 
> (http://www.fractalconcept.com/) and is "intended to be an alternative 
> to the TeX like typesetting systems." It is still under heavy 
> development but is already used by some people. 

I think there is simply too much momentum behind TeX and MathML to
contemplate an alternative typesetting system.  Dealing with these two
will be headache enough...

> But Axiom doesn't only send mathematical expressions as output. What 
> about plots, for example? We'd also have to integrate an SVG library in 
> Axiom then, or generate the SVG in the browser using Javascript. Not 
> only am I confused as to wether the latter is actually possible, it's 
> also a nuisance to have to use Javascript. Another example are 
> conditions. If some part of Axiom throws a condition it would be cool if 
> Axiom could communicate that to the front-end together with a list of 
> restarts. Then the front-end could ask the user what to do and offer him 
> to send a bug report. Of course, Axiom could instead generate an 
> HTML-page offering the user a list of restarts, but that would mean even 
> more non-math code in Axiom.

We should enumerate an API specifying what input the back-end expects,
and what output it can give.

> Well, for other reason I want a separate GUI back-end written in Lisp 
> anyway. That back-end would read the sexp-based output and emit XML/HTML 
> for the browser. Implementing an sexp parser in a web browser is not a 
> good idea, I agree. One thing to consider is that Axiom has its 
> knowledge in some Lisp data structures anyway, I suppose. Hence writing 
> the output in a format that is native to Lisp (sexps) should be very 
> straightforward.

So you're proposing *three* applications?
1) axiom
2) sexp -> xml converter
3) web browser/javascript

I think the middle application is probably unnecessary, but let's get
into the nitty gritty of what we want to exchange.

I suspect that any potential GUI will want the same things, and will
want those things in either sexp or XML format.  Building both those
into axiom will be fruitful.  But I think the middle layer would end up
being nothing more than a format converter... no?

I think the API should consist of RPC calls, with arguments marshalled
in either sexp or XML.  Unless there is a strong reason to believe we
cannot simply do a 1:1 conversion between XML and sexp, I advocate a
single API and a single XML <-> sexp converter.  This is already
present, to a large degree, in the axiom language.

> But it shouldn't hang. And it should also continue to deliver help pages 
> while a computation is running. Whenever I'm waiting some long-running 
> process to finish I start reading documentation. If we don't have either 
> threading or separate processes that's pretty much impossible.

Why should axiom "deliver" help pages at all?  Why can't the interface
read them directly off the disk?  And when those help pages contain an
axiom session, why can't the interface start a new session for
evaluation (so that it does not interfere with the main computation).

This will still require threading in the server, but it's simply
threading of axiom sessions, and not truly "interface code".

The only thing missing from this idea is "search".

> >It should be easy to use these existing pieces to enable a 
> >   )set output sexp on
> >and
> >   )set output mathml on
> >by converting sexp's to mathml.
> > 
> That's my point. If we have sexp output it is trivial to convert that to 
> any kind of XML we'd like, apart from semantics, but no format would 
> solve that problem.

What do you mean by "no format would solve that problem"?  What are you
referring to with "format"?  And the problem is conversion of sexp <->
xml?

Now that hyperdoc is working...I just discovered axiom's graphics
capabilities.  Graphics will require a lot more thought.  My google
searches turned up basically nothing as far as scientific graphics in
lisp.

\start
Date: Tue, 28 Jun 2005 12:10:50 +0200
From: Kai Kaminski
To: Bob McElrath
Subject: Re: AxiomUI project funded

Bob McElrath wrote:

>Kai Kaminski [Kai Kaminski] wrote:
>  
>
>>Sure. The cl-typesetting library is currently developed by Marc Battyani 
>>(http://www.fractalconcept.com/) and is "intended to be an alternative 
>>to the TeX like typesetting systems." It is still under heavy 
>>development but is already used by some people. 
>>    
>>
>
>I think there is simply too much momentum behind TeX and MathML to
>contemplate an alternative typesetting system.  Dealing with these two
>will be headache enough...
>
The cl-typesetting project is not so much about creating a new input 
syntax for documents but a typesetting engine. For example someone 
contributed a module supporting XML-FO and IIRC they would love to have 
a module supporting LaTeX-like input. But I'm not promoting doing 
expression rendering ourselves at this point, so maybe we can just leave 
it at that.

>>But Axiom doesn't only send mathematical expressions as output. What 
>>about plots, for example? We'd also have to integrate an SVG library in 
>>Axiom then, or generate the SVG in the browser using Javascript. Not 
>>only am I confused as to wether the latter is actually possible, it's 
>>also a nuisance to have to use Javascript. Another example are 
>>conditions. If some part of Axiom throws a condition it would be cool if 
>>Axiom could communicate that to the front-end together with a list of 
>>restarts. Then the front-end could ask the user what to do and offer him 
>>to send a bug report. Of course, Axiom could instead generate an 
>>HTML-page offering the user a list of restarts, but that would mean even 
>>more non-math code in Axiom.
>>    
>>
>
>We should enumerate an API specifying what input the back-end expects,
>and what output it can give.
>  
>
I agree.

>>Well, for other reason I want a separate GUI back-end written in Lisp 
>>anyway. That back-end would read the sexp-based output and emit XML/HTML 
>>for the browser. Implementing an sexp parser in a web browser is not a 
>>good idea, I agree. One thing to consider is that Axiom has its 
>>knowledge in some Lisp data structures anyway, I suppose. Hence writing 
>>the output in a format that is native to Lisp (sexps) should be very 
>>straightforward.
>>    
>>
>
>So you're proposing *three* applications?
>1) axiom
>2) sexp -> xml converter
>3) web browser/javascript
>  
>
Not really. I'm proposing that the GUI be implemented as a separate 
process from Axiom. That's all. The first version of that GUI happens to 
use a web browser to display output, but that may change in the future. 
Suppose in a couple of month someone starts working on wxWidgets 
bindings. Instead of generating 3d plots as X3D documents we might want 
to use wxWidgets OpenGL widget to display them directly. There is 
another widget allowing the embedding of Mozilla, hence we could still 
use Mozilla for the HyperDoc pages.

Even in the beginning part 2) will be more than an sexp-to-xml 
converter. Take plots as an example. Axiom supplies a list of points 
that have to be connected with straight lines/splines/whatever. Then 
part 2) generates SVG output, which isn't too hard but not trivial 
either. Suppose the plot contains some text, like a title or a 
description. We can't just stuff the text into the SVG file, because in 
XML certain characters have to be escaped. I don't want to implement all 
this in Javascript. But I don't want to have an SVG generator in Axiom 
either.

>I think the middle application is probably unnecessary, but let's get
>into the nitty gritty of what we want to exchange.  
>
Well, maybe it is, but I'm not convinced yet. I agree that we should 
start by clarifying what kinds of output Axiom will have to send and 
define a useful format. We might consider using something compatible to 
xmls (http://common-lisp.net/project/xmls/). The other question is how 
we implement that in Axiom. I don't know Axiom's architecture, and Bill 
said it might be too difficult. Opinions?

>I suspect that any potential GUI will want the same things, and will
>want those things in either sexp or XML format.  Building both those
>into axiom will be fruitful.  But I think the middle layer would end up
>being nothing more than a format converter... no?
>  
>
That's exactly what I'm aiming at. Axiom's output should be 
GUI-independent, contain as much information as possible and be easy to 
parse from a variety of languages. Sexps and XML seem to fit the bill 
(XML can often be seen as a verbose way of writing sexps). The middle 
part is not just a format converter. The GUI will become more complex 
over time. Suppose we want to support LaTeX as an input syntax for 
HyperDoc pages or something similar (Martin Rubey wants this, as I 
understand). Do we want to put a LaTeX parser into Axiom? Do we want to 
implement one in Javascript? Sure, we can possibly use existing 
converters to HTML/XML, but they might not quite do what we need and 
even if they do, we might havee to do some additional processing, like 
injecting some Javascript.

GUIs are complex and Javascript is an awful language without a 
development environment (correct me if I'm wrong). If, some day, we add 
complex behaviour to the Axiom GUI I'd much rather implement that in 
Common Lisp and push the results to a web browser than implementing all 
that in Javascript.

>I think the API should consist of RPC calls, with arguments marshalled
>in either sexp or XML.  Unless there is a strong reason to believe we
>cannot simply do a 1:1 conversion between XML and sexp, I advocate a
>single API and a single XML <-> sexp converter.  This is already
>present, to a large degree, in the axiom language.
>  
>
As long as we don't do really fancy XML this should be no problem. In 
fact the XML parser that I mentioned a few posts back has a nice mapping 
between sexps and XML.

>>But it shouldn't hang. And it should also continue to deliver help pages 
>>while a computation is running. Whenever I'm waiting some long-running 
>>process to finish I start reading documentation. If we don't have either 
>>threading or separate processes that's pretty much impossible.
>>    
>>
>
>Why should axiom "deliver" help pages at all?  Why can't the interface
>read them directly off the disk?  And when those help pages contain an
>axiom session, why can't the interface start a new session for
>evaluation (so that it does not interfere with the main computation).
>  
>
AJAX wouldn't work then, but using Mozilla-specific extensions there is 
obviously a way around this as you have shown with your example. But if 
someone creates a new HyperDoc page he will have to include the 
necessary Javascript as well and he will have to write it in HTML. I 
would much prefer to have a different format for HyperDoc pages than 
HTML, because HTML doesn't capture the semantics of Axiom or HyperDoc. 
Consider the command line as an example. If we store the pages as HTML 
so that they can be read by a browser we would probably include some 
Javascript similar to what I've used for my dynamic jsMath demo. Now 
imagine that maybe in two years the W3C includes a tag in HTML that does 
pretty much the same, just better or more beautiful. Then we'll have to 
go through all pages using a command line, rip out the old code put in 
the new one. If we have our own format for HyperDoc pages (XML with a 
HyperDoc DTD, sexp-based, LaTeX-based,...) we just change the code in 
the middle process that is responsible for rendering the HyperDoc pages 
to HTML and they are all new and shiny. Of course we could just do the 
conversion once, every time something like this happens, but that would 
require us to keep two versions of every page around and sooner or later 
people would try and modify the rendered HTML instead of the page source.

>This will still require threading in the server, but it's simply
>threading of axiom sessions, and not truly "interface code".
>  
>
I guess we could just start several instances of Axiom.

>The only thing missing from this idea is "search".
>  
>
Good example. Search is complex. Do we implement that in Javascript or 
will the search code be part of Axiom? If we have a process between 
Axiom an browser we can just put it in there.

>>>It should be easy to use these existing pieces to enable a 
>>>  )set output sexp on
>>>and
>>>  )set output mathml on
>>>by converting sexp's to mathml.
>>>
>>>      
>>>
>>That's my point. If we have sexp output it is trivial to convert that to 
>>any kind of XML we'd like, apart from semantics, but no format would 
>>solve that problem.
>>    
>>
>
>What do you mean by "no format would solve that problem"?  What are you
>referring to with "format"?  And the problem is conversion of sexp <->
>xml?
>  
>
What I meant is that converting sexps to XML is trivial in the sense 
that "(tag :attribute value ...)" becomes "<tag attribute="value"> ... 
</tag>". Rendering things to XHTML on the other hand can be more 
difficult. Tim once remarked that he couldn't see how we can associate 
meaning to XML data. The answer is that it's difficult, but that is not 
a specific problem of XML.

>Now that hyperdoc is working...I just discovered axiom's graphics
>capabilities.  Graphics will require a lot more thought.  My google
>searches turned up basically nothing as far as scientific graphics in
>lisp.
>  
>
I'm not sure what you mean here, but I assume that Axiom already 
incorporates code to generate plot data. We can use that to create SVG 
files, which look very nice. PDF is also easy, because of cl-pdf.

\start
Date: Tue, 28 Jun 2005 05:35:24 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#185 append vs concat] (new) 

The append function in axiom has the lisp background.  
axiom and lisp don't duplicate the last list.

L1 := [1,2,3] ; L2 := [10,11,12] ; L := append (L1, L2) ; L2.2 := 100 
L.5 -- is 100, not 11

There is also a concat function that I understand in a mathematical way.
today concat works as append.

L1 := [1,2,3] ; L2 := [10,11,12] ; Lc := concat (L1, L2) 

Lc doesn't change if I change L1, and Lc change if I modify L2.
Is it possible to change concat in order to copy L2, as 
concat (L1, L2) == append (L1, copy (L2))

The concat function becomes just a little slower.
And then list are here a real hi-level n-uple oblject, not a lisp object.
 
F.Maltey

\start
Date: Tue, 28 Jun 2005 12:37:58 +0200
From: Kai Kaminski
To: list
Subject: HyperDoc

Hi,

I'm currently fighting my way through the hyper source code to 
understand how everything works. The first thing on my list is to parse 
the HyperDoc pages so that I can process them in some way. I think that 
we need a new format for HyperDoc pages as the old one contains commands 
and environments that don't make much sense in a web browser.

One of the questions is if it is easier to implement a parser in Lisp or 
to modify hyper to produce the new format. Another is wether people 
would prefer to have a LaTeX-like input syntax for HyperDoc pages 
instead of some XML-based format, I guess the answer is yes. Since it 
will be useful to be able to generate HyperDoc pages from LaTeX articles 
implementing a parser in Lisp is probably the way to go.

What should the new page description language be like, i.e. XML or 
LaTeX, and which commands/environments should be supported?

If anyone has compiled hyper on OS X I would love to know about that. 
Other hints concerning hyper, the HyperDoc language or an existing 
grammar for the latter are always welcome.

\start
Date: Tue, 28 Jun 2005 08:57:16 -0500
From: Tim Daly
To: Bill Page, Kai Kaminski, Bob McElrath
Subject: converting sexps to XML

I should amplify the point made earlier given this comment:

> What I meant is that converting sexps to XML is trivial in the sense
> that "(tag :attribute value ...)" becomes "<tag attribte="value" ...
> </tag>". 

Ummm. nope. You assume no runtime meaning; that it is just syntax so that

(anchor "slashdot" "slashdot.org")

==>  <a href="slashdot.org">slashdot</a>

but lisp allows runtime behaviour thus

(defun getAnchor (name) (gethash name URLhash))

(anchor name (getAnchor name))

==> ?

We can certainly specify an API of function calls with restricted
meaning and requirements. This requires a balance between at least
two mindsets for very large values of two.

Mindset one is that we want to be able to generate any XML. Thus we
want to look at the XML spec and make sure we "cover" it, that is,
make sure we can generate the full range of XML.

Mindset two is that we want to be able to reproduce the existing
browser functionality. Thus we want to look at the range of abilities
of the existing browser and make sure we can implement it.

Mindset three is that we want to take advantage of the new browser
abilities, like tabs, bookmarks, popups, javascript, jsMath, etc.
and want to reflect these abilities in the API so we can write code 
to generate them.

Mindset four .....

Ah, there is a carnival of voices in my head....

\start
Date: Tue, 28 Jun 2005 17:30:31 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: converting sexps to XML

Hi Tim and everyone!

Tim Daly wrote:

>I should amplify the point made earlier given this comment:  
>
>>What I meant is that converting sexps to XML is trivial in the sense
>>that "(tag :attribute value ...)" becomes "<tag attribte="value" ...
>></tag>". 
>>    
>>
>
>Ummm. nope. You assume no runtime meaning; that it is just syntax so that
>
>(anchor "slashdot" "slashdot.org")
>
>==>  <a href="slashdot.org">slashdot</a>
>
>but lisp allows runtime behaviour thus
>
>(defun getAnchor (name) (gethash name URLhash))
>
>(anchor name (getAnchor name))
>
>==> ?
>  
>
That's correct. I'm only considering XML as a syntax. You could do 
something like
<defun name="getAnchor" params="name">
    <call name="gethash" params="name URLhash" />
</defun>

or something similar, although you probably wouldn't want to. You can't 
compare Lisp and XML, Lisp is a language, XML is a mark-up scheme. 
That's why I always say sexp and not Lisp, sexps are just Lisp lists 
without any semantics attached. As far as I understand, the question 
here is wether we want a simple mark-up language for the HyperDoc pages 
or a full-blown programming language somewhat geared towards hypertext 
generation (macros could certainly do so, another example is Scribe 
(http://www-sop.inria.fr/mimosa/fp/Scribe/)).
We could actually adapt Scribe to some extent (with Common Lisp 
semantics, of course).

I suggest that we first aim for consensus regarding the expressive power 
of the page description language and then discuss the possible syntax.

Of course, we could offer tags like
<link style="axiom" ref="axiom/config">Axiom configuration</link>
<link style="internet" 
ref="http://reviews.com/articles/axiom-is-great.html">Axiom Review</link>
<link style="axiom" ref="axiom/command_line">Command line for this Axiom 
session</link>
<link type="axiom" ref="community/developer">Axiom Developer Site</link>

or other tags which process some of the input. For example the last link 
would automatically lead to axiom-developer.org or some other 
appropriate site, even if its URL changes.

>We can certainly specify an API of function calls with restricted
>meaning and requirements. This requires a balance between at least
>two mindsets for very large values of two.
>
>Mindset one is that we want to be able to generate any XML. Thus we
>want to look at the XML spec and make sure we "cover" it, that is,
>make sure we can generate the full range of XML.
>
>Mindset two is that we want to be able to reproduce the existing
>browser functionality. Thus we want to look at the range of abilities
>of the existing browser and make sure we can implement it.
>
>Mindset three is that we want to take advantage of the new browser
>abilities, like tabs, bookmarks, popups, javascript, jsMath, etc.
>and want to reflect these abilities in the API so we can write code 
>to generate them.
>
>  
>
Do we really need the ability to generate all kinds of XML from within a 
HyperDoc page? I thought that the HyperDoc pages would look something 
like this (in LaTeX notation):

\begin{paragraph}[editable]
  some text
\end{paragraph}

and that the back-end would transform this to something like
<p class="editable" ...>
  some text
</p>

and also insert the necessary Javascript to make sure the paragraph is 
actually editable. I'm not sure if it is really desirable to give an 
author the ability to do whatever he wants. That way we couldn't 
guarantee a somewhat standard look-and-feel. I understand that there are 
some special pages in HyperDoc, e.g. for configuration, which might make 
good use of having Lisp at their disposal, but we can implement those as 
Lisp functions in the back-end.

Another issue with having too powerful a page language is that it is 
difficult to process automatically. You can't validate the pages, you 
never know if they'll finish rendering eventually or not. We would not 
only have bugs in the GUI and Axiom but also in the documentation. And 
if we ever change some aspect of the standard look-and-feel someone will 
have to go and hunt down and fix dozens if not hundreds of pages 
containing some Lisp that doesn't mix well with the new standard. If the 
language is simple markup, we just change the rendering code in the GUI 
back-end and all pages look all new and shiny.

If we really want to offer the full power of Lisp, that's easy, too. 
Give the user the option to supply a Lisp source file as the page 
source. We would offer some convenience functions/macros of course, 
something like the following maybe:

(define-hyperdoc-page
    :title "MyPowerfulPage"
    :axiom-ref "MPP"
    :content #'my-powerful-page)

(defun my-powerful-page (stream)
    (with-html
       ....))

But I don't think that forcing that degree of control onto everyone on 
every occasion is a good idea. The other problem is that people would 
have to learn Lisp or something similar. A good datapoint is LaTeX. It 
is programmable, but most people don't care. Everyone uses \newcommand, 
but mostly for abbreviations and other simple things.


Finally I'd like to note that I might have missed some capabilities of 
the old HyperDoc browser. Also I'm not writing many HyperDoc pages so 
it's really not my decision what to do.

>Ah, there is a carnival of voices in my head....  
>
I just spend several hours reading about US tax law and relevant 
treaties. Nothing can be worse than that. ;-)


\start
Date: Tue, 28 Jun 2005 17:49:15 +0200
From: Ralf Hemmecke
To: list
Subject: Axiom crash

I have two things.

1)

E := Expression Integer
F := E -> E

Why doesn't Axiom let me define the following function in this way.

compose(f:F, g:F)(e:E):E == f(g(e))

    All or none of the arguments and result type of compose must be
       declared.

There are all arguments defined.

I have to say something like

compose(f:F, g:F):F == (e:E):E +-> f(g(e))


2) Axiom patch40 crashes (at least on my Debian installation) on the 
following code.

E := Expression Integer
F := E -> E
compose(f:F, g:F):F == (e:E):E +-> f(g(e))
p(e:E):E == 2*e+1
q(e:E):E == 3*e+1
compose(p,q)

\start
Date: Tue, 28 Jun 2005 11:09:18 -0500
From: MathAction (TIm Daly)
To: MathAction
Subject: [#186 compose function crashes Axiom] (new) 

2) Axiom patch40 crashes (at least on my Debian installation) on the 
following code.

E := Expression Integer
F := E -> E
compose(f:F, g:F):F == (e:E):E +-> f(g(e))
p(e:E):E == 2*e+1
q(e:E):E == 3*e+1
compose(p,q)

\start
Date: Tue, 28 Jun 2005 11:43:35 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#186 compose function crashes Axiom] See #114	MapOnFunctionsCrash

following code::

  E := Expression Integer
  F := E -> E
  compose(f:F, g:F):F == (e:E):E +-> f(g(e))
  p(e:E):E == 2*e+1
  q(e:E):E == 3*e+1
  compose(p,q)

\start
Date: Tue, 28 Jun 2005 12:48:41 -0400
From: Eugene Surowitz
To: list
Subject: Review of algebra/computation packages - Computing in Science & Engineering magazine
Cc: Norman Chonacky, David Winch

The magazine Computing in Science & Engineering,
jointly published by the American Institute of Physics and the IEEE,
has published a series "review" type articles by Norman Chonacky and 
David Winch.
Chonacky is the magazine's editor in chief.

The articles are focused on the commercial packages Maple, Mathematica, 
and Matlab.
They appear in the Jan/Feb, Mar/Apr, May/June, and July/Aug issues.

The series so far gives open source / free software packages
effectively no consideration or mention.

\start
Date: Tue, 28 Jun 2005 14:28:18 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Sanbox Functional Addition] (new) 

This library code is based directly on MappingPackage3 in
'mappkg.spad.pamphlet'

\begin{axiom}
)abbrev package MAPHAC2X MapPackInternalHac2x
++ Description:
++ This package defines the function to be returned by
++ functional operator below.

MapPackInternalHac2x(A: SetCategory, B: Ring):
  MPcat == MPdef where

    MPcat == with
        addit:  (A->B, A->B, A) -> B
          ++\spad{comp(f,g,x)} is \spad{f(g x)}.

    MPdef == add
        addit(g,h,x)  == ((g x) + (h x))$B
\end{axiom}


\begin{axiom}
)abbrev package MAPPK2X MappingPackage2x
++ Description: various Currying operations.
MappingPackage2x(A:SetCategory, B:Ring):
  MPcat == MPdef where

    MPcat ==  with

        "+":   (A->B, A->B) -> (A->B)
          ++\spad{f+g} is the function \spad{h}
          ++ such that \spad{h x = f x + g x}.

    MPdef == add


        MapPackInternalHac2x(A, B)

        fab:  A -> B

        -- Functional addition
        fab+fab == addit(fab,fab,#1)

\end{axiom}

\begin{axiom}
f := (x:INT):INT +-> 3*x
g := (x:INT):INT +-> 2*x+3
(f+g)(3)
\end{axiom}

\start
Date: Tue, 28 Jun 2005 14:43:27 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Sanbox Functional Addition] 

++ Description: Mapping hack for Addition
++ The function \spad{addit(f,g,x)} is \spad{fx+gx} which is needed below

??changed:
-  MPcat == MPdef where
-
-    MPcat == with
-        addit:  (A->B, A->B, A) -> B
-          ++\spad{comp(f,g,x)} is \spad{f(g x)}.
-
-    MPdef == add
-        addit(g,h,x)  == ((g x) + (h x))$B
   with addit:  (A->B, A->B, A) -> B ==
      add addit(g,h,x)  == ((g x) + (h x))$B

++added:
This package is the one that actually provides the Functional
Addition operator. The overloaded symbol + also represents this
type of addition.

++ Description: Functional Addition
++ Given functions f and g, returns the function \spad{fx+gx}
++ \spad{f+g} is the function \spad{h} such that \spad{h x = f x + g x}.

   with "+":   (A->B, A->B) -> (A->B) ==
      add
         MapPackInternalHac2x(A, B)
         fab:  A -> B
         fab+fab == addit(fab,fab,#1)

\start
Date: Tue, 28 Jun 2005 13:26:25 -0700
From: Bob McElrath
To: Kai Kaminski
Subject: Re: converting sexps to XML

Kai Kaminski [Kai Kaminski] wrote:
> or something similar, although you probably wouldn't want to. You can't 
> compare Lisp and XML, Lisp is a language, XML is a mark-up scheme. 

I think we can reduce this problem to one of *validating* XML (or
sexp's).  Assuming the sexp is solely data (no macros or functions),
we can always 1:1 translate a tree into another tree (regardless of
markup), what we must do is make sure that the set of tags and
attributes are defined by the schema.  Validation could be done directly
on an sexp if the scheme were known.

This page has a whole lot of discussion of XML, sexp's (from scheme's
perspective), validations, and transformations:
    http://okmij.org/ftp/Scheme/xml.html

> Do we really need the ability to generate all kinds of XML from within a 
> HyperDoc page? I thought that the HyperDoc pages would look something 
> like this (in LaTeX notation):
> 
> \begin{paragraph}[editable]
>  some text
> \end{paragraph}
> 
> and that the back-end would transform this to something like
> <p class="editable" ...>
>  some text
> </p>

I think these two ideas are very distinct.  A latex document is
processed from top to bottom, once.  A change requires essentially a
re-compile of the entire document.  Syntactic validity cannot be ensured
in a sub-document of latex.  (e.g. I could insert "\end{paragraph}" in
the middle of my paragraph...causing the parser to totally barf)  

On the other hand XML has the concept of a DOM, which allows me to
examine nodes individually, add/remove nodes, and modify the text inside
a node, all in a self-contained manner.

Do we want to have both forward and backward translation of hyperdoc to
xml?  This seems very redundant.  I would say pick one format and be
done with it.  However I suspect if I suggest translating all documents
to XML/SGML I will get pelted with rotten tomatoes.

> and also insert the necessary Javascript to make sure the paragraph is 
> actually editable. 

This is almost trivial and actually requires the insertion of *no*
javascript.  e.g. the interface finds the paragraph clicked on with the
"editable" class, and modifies it.  The paragraph itself need not have
any javascript.  (not even an onClick).  Before displaying the document
the javascript can always traverse all "editable" objects and add the
onClick property.

> another issue with having too powerful a page language is that it is 
> difficult to process automatically. you can't validate the pages, you 
> never know if they'll finish rendering eventually or not. We would not 
> only have bugs in the GUI and Axiom but also in the documentation. And 
> if we ever change some aspect of the standard look-and-feel someone will 
> have to go and hunt down and fix dozens if not hundreds of pages 
> containing some Lisp that doesn't mix well with the new standard. If the 
> language is simple markup, we just change the rendering code in the GUI 
> back-end and all pages look all new and shiny.

Perhaps this is a nice separation between interface and documentation.
The document (whether latex/xml/sexp) contains no code, only "hints"
such as "editable".

I worry that in our mad rush to make an interface, somewhere we will
make it not possible to simply print a page and call it "documentation"
without the interaction piece.  (I think hyperdoc already has this
problem)

> If we really want to offer the full power of Lisp, that's easy, too. 
> Give the user the option to supply a Lisp source file as the page 
> source. We would offer some convenience functions/macros of course, 
> something like the following maybe:
> 
> (define-hyperdoc-page
>    :title "MyPowerfulPage"
>    :axiom-ref "MPP"
>    :content #'my-powerful-page)
> 
> (defun my-powerful-page (stream)
>    (with-html
>       ....))
> 
> But I don't think that forcing that degree of control onto everyone on 
> every occasion is a good idea. The other problem is that people would 
> have to learn Lisp or something similar. A good datapoint is LaTeX. It 
> is programmable, but most people don't care. Everyone uses \newcommand, 
> but mostly for abbreviations and other simple things.

I think adding too much power to the document is something to be
avoided.  Both Maple and Mathematica are converging on having a full
operating system, window manager, object-oriented, functional,
list-based language built in.  (not to mention math)  This is just too
big.  The number of bugs scales as the number of
(features/lines-of-code/api calls)^N where N is large.  Furthermore you
end up with a system that is so complex, and has so many interactions
that no one can use it.

For instance, in Mma, copy some output text, and paste it to an input
line.  You get an error:
    "You are attempting to paste a TraditionalForm expression into a
    StandardForm cell.  If you want to be sure that the meaning of the
    expression will be preserved, you should first convert it to
    StandardForm."  

    (Paste with a FormBox wrapper) (Paste literally) (cancel)

What the hell is all this and why should I care?  Why does a math
program have an interface element built in?  (FormBox)  After I paste it
literally it becomes some beast that one cannot edit any longer.  If I
paste it with FormBox it is not executable.  Why does it let me paste
non-executable things into an executable input cell?  Finally, I cannot
convert to StandardForm without entering
%//StandardForm, then hunting through to find what I originally
%selected, re-cut and paste.

Point is, all this is complicated, and unnecessary.  I believe we should
avoid at all costs design decisions which will push us to add buttons,
boxes, etc. to mathematics.  Interface should be interface and math
should be math.

Where interface/math interactions are required, the interface should
identify the piece of math (e.g. term 7 in expression 5) and tell that
to the back-end, and *never* actually go through the step of capturing
output and feeding it back to the back-end as input.

simplify simplify simplify.

I think this suggestion can be accomplished entirely by marking text.
e.g. in some MathML every identifier can be labelled with an id and
class.  It is the interface's responsibility to tell the back-end to do
something with id=47 in class=sum.  We must keep the interface from
having to know any math, lest we find ourselves re-implementing axiom in
the interface.

\start
Date: Tue, 28 Jun 2005 17:44:40 -0500
From: Tim Daly
To: list
Subject: Axiom on Knoppix DVD

Klaus Knopper sent me a note confirming that Axiom will be on the 
Knoppix DVD.

\start
Date: Tue, 28 Jun 2005 16:31:58 -0700
From: Bob McElrath
To: Kai Kaminski
Subject: document, graphics

I would like to separate this discussion for the purpose of clarity.
First, I have been discussing mostly document processing, and
interaction with mathematical output.  As I've suggested, I think this
can be accomplished with an absolutely minimal API:
    AppendInput(input)
    ModifyInput(line, newinput)
    GetOutput(line)
    ComputationStatus()
where the GetOutput call returns an sexp or xml document containing no
code, but hints such as "sumterm1", "paragraph", "type".  Dependency
tracking/re-evaluation can be handled inside Axiom.  The last call
ComputationStatus should return a list of lines for which computation is
underway or need re-computation.

The second part of the discussion is non-mathematical input/output.
e.g. graphs, diagrams.  Can we do the same thing as for mathematical
output?  (e.g. the output contains only data structures and hints, and
no code?)  This requires a graph renderer/manipulator which understands
the underlying data structure.  (e.g. 1-dimensional point set,
2-dimensional graph, 3d point set with mesh, etc) "understanding the
data structure" is a separate problem from "communicating the data
structure" since the latter can be simply marshalled into an sexp or XML
data structure.

Furthermore "draw" should really be an alias for "give me a point-set
approximation".  Axiom generates a point-set.  The *user-interface* must
decide what to do with it.  Axiom shouldn't care whether it ends up in a
pie chart or bar chart.  These are user-interface concepts, not
mathematical concepts.

So, I seem to be convincing myself that I want a back-end which knows
absolutely nothing about user interfaces, but can serialize its output
in either sexp or xml.

Kai Kaminski [Kai Kaminski] wrote:
> >So you're proposing *three* applications?
> >1) axiom
> >2) sexp -> xml converter
> >3) web browser/javascript
> >
[...]
> Even in the beginning part 2) will be more than an sexp-to-xml 
> converter. Take plots as an example. Axiom supplies a list of points 
> that have to be connected with straight lines/splines/whatever. Then 
> part 2) generates SVG output, which isn't too hard but not trivial 
> either. Suppose the plot contains some text, like a title or a 
> description. We can't just stuff the text into the SVG file, because in 
> XML certain characters have to be escaped. I don't want to implement all 
> this in Javascript. But I don't want to have an SVG generator in Axiom 
> either.

Why would escaping of characters not be part of a sexp->xml converter?
It's a general translation problem, no?

If there is not an svg generator in axiom, what format should axiom
present?

I looked a bit for lisp/scheme scientific graphics libraries, it seems
such a thing is almost non-existant.  :(  SVG scientific graphing is
also non-existant.  Perhaps a scientific SVG generator should be a
completely separate project.

Knowing how we are going to plot...what format the data should be
in...what interactions are possible...would be useful.

> Suppose we want to support LaTeX as an input syntax for 
> HyperDoc pages or something similar (Martin Rubey wants this, as I 
> understand). Do we want to put a LaTeX parser into Axiom? Do we want to 
> implement one in Javascript? 

This is fundamentally impossible because LaTeX is mathematically
amgibuous.  e.g.
    \int_a^b x d x
    \int_a^b d x d x
'd' is a constant.  For that matter presentation MathML is also
mathematically ambiguous.  (hence the creation of content mathml and
OpenMath)

> GUIs are complex and Javascript is an awful language without a 
> development environment (correct me if I'm wrong). If, some day, we add 
> complex behaviour to the Axiom GUI I'd much rather implement that in 
> Common Lisp and push the results to a web browser than implementing all 
> that in Javascript.

I agree on the awful part.  However by writing an XPCOM component for
mozilla, we can offload intensive processing (such as real-time graph
manipulation) to native code.

We should restrict javascript to solely interface elements, and not
allow it to do any mathematical processing.

> >Why should axiom "deliver" help pages at all?  Why can't the interface
> >read them directly off the disk?  And when those help pages contain an
> >axiom session, why can't the interface start a new session for
> >evaluation (so that it does not interfere with the main computation).
>
> AJAX wouldn't work then, but using Mozilla-specific extensions there is 
> obviously a way around this as you have shown with your example. But if 
> someone creates a new HyperDoc page he will have to include the 
> necessary Javascript as well and he will have to write it in HTML.

One wouldn't need AJAX for help pages...or even file access as I have
used in my example, but rather just <a href="file:///...">.

Re: "new hyperdoc page".  For the time being I think we should
concentrate on all new hyperdoc being in the current pamphlet format.
For this interface we can convert to HTML.  In the future we can
contemplate converting pamphlet -> html en masse.  But for now let's
keep an HTML UI document separate from a pamphlet.  We should engineer
things so that we can do a trivial HTML UI document -> pamphlet
conversion.  Javascript is in the document for UI elements, but would be
stripped for pamphlet conversion.  A proper pamphlet representation
should not depend on javascript, or running any code other than what can
be delivered to the axiom engine.

(Does the reverse hold?  Do pamphlets have additional logic other than
what is delivered to axiom?)

> I would much prefer to have a different format for HyperDoc pages than
> HTML, because HTML doesn't capture the semantics of Axiom or HyperDoc. 

Who cares?  We have axiom input (which is just text -- and always should
be) and output which is proper HTML/XML.

> Consider the command line as an example. If we store the pages as HTML 
> so that they can be read by a browser we would probably include some 
> Javascript similar to what I've used for my dynamic jsMath demo. Now 
> imagine that maybe in two years the W3C includes a tag in HTML that does 
> pretty much the same, just better or more beautiful. 

"Pretty much the same" -- you mean rendering the latex?  You mean
MathML?

Yes, HTML documents which jsMath/latex in them will have to be rebuilt,
but this should be as simple as typing "make" if axiom knows how to
generate both latex amd MathML.

> Then we'll have to 
> go through all pages using a command line, rip out the old code put in 
> the new one. If we have our own format for HyperDoc pages (XML with a 
> HyperDoc DTD, sexp-based, LaTeX-based,...) we just change the code in 
> the middle process that is responsible for rendering the HyperDoc pages 
> to HTML and they are all new and shiny.

What I am saying is equivalent.  But you're forgetting that the hyperdoc
pages are built as part of the build process.  So the "code in the
middle" is essentially the build code.

> Of course we could just do the 
> conversion once, every time something like this happens, but that would 
> require us to keep two versions of every page around and sooner or later 
> people would try and modify the rendered HTML instead of the page source.

As I mention above, let's keep "pamphlet" as our primary format for the
time being, and convert it.

When/if we have a new format that we deem as powerful and a suitable
replacement for the latex-based pamphlets, we can convert en masse.  But
that's far down the road.

[re: documentation]
> >The only thing missing from this idea is "search".
>
> Good example. Search is complex. Do we implement that in Javascript or 
> will the search code be part of Axiom? If we have a process between 
> Axiom an browser we can just put it in there.

Neither.  It is a user interface issue, not a mathematical issue.  It
should be in the user interface, somewhere.  (though god no...not in
javascript)  An XPCOM component could do it.

Also note that one could generate an index file with words and URI's.
This could be parsed by javascript to make an efficent search engine.
(But, all the logic has been moved to the build system which generates
the index file)

> I'm not sure what you mean here, but I assume that Axiom already 
> incorporates code to generate plot data. We can use that to create SVG 
> files, which look very nice. PDF is also easy, because of cl-pdf.

I installed a mozilla svg build.  (Hard to find actually -- SVG is not
enabled on linux yet)  I found some interesting examples:
    http://www.croczilla.com/svg/samples/dom2/dom2.xml
this one rotates/translates/scales a polygon using DOM/javascript.  Also
hit "Dump XForms" after doing a couple of operations.  It keeps a list
of transformations that in principle can be converted to axiom commands
and passed back.  Note that this really is "knowledge of the algebra"
that I advocated avoiding above.  Graphics implies a much tighter
coupling between the algebra and graphs.  Nonetheless, I think axiom
should generate point-sets, and an interface should generate axiom
commands.
    http://www.croczilla.com/svg/samples/events2/events2.xml
Someone was worried about drawing on the screen.  With SVG I think it
would be trivial.
    http://www.croczilla.com/svg/samples/xbl-shapes2/xbl-shapes2.xml
Another user-interaction with SVG.

Keep in mind that SVG+DOM has all the elements for a user interface to
graphs.

\start
Date: Tue, 28 Jun 2005 23:40:21 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#187 trouoble with tuples] (new) 

There error messages indicate some serious problems
with the Axiom Tuple domain::

  System error: The function |Domain| is undefined.
  The constructor Tuple takes 1 argument and you have given  2

Axioim allows functions to have a tuple as input but it
fails if a function generates two or more outputs.

For example:
\begin{axiom}
f:(INT,INT)->INT,INT
g:INT->(INT,INT)
List Any
DirectProduct(2,Any)
Tuple Any
\end{axioms}

Tuple Any should work in a similar way to List Any and
DirectProduct(2,Any).

Axiom's non-homogeneous Record and Union domains are
functionally superior but the tuple construct but it makes
functional notation awkward. See [SandBox Direct Product]

\start
Date: Wed, 29 Jun 2005 01:04:08 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#187 trouoble with tuples] 

Try this (which gets around the error messages and bug):
\begin{axiom}
a:Tuple INT
a:=(1,2,3,4)
dom:=Tuple Any
b:dom:=(1::INT, 2::FLOAT,3::POLY INT)
h:INT->Tuple INT
h(x)==(x, 2+x)
h(5)
\end{axiom}

\start
Date: Wed, 29 Jun 2005 01:43:30 -0500
From: MathAction (billpage)
To: MathAction
Subject: [#187 trouoble with tuples] Any suggestions

How to do composition of functions with two arguments and two outputs?

\begin{axiom}
f1:INT->Tuple INT
f1(x)==(x,2+x)
f2:(INT,INT)->INT
f2(x,y)=x*y
f2(f1(4))
f3:Tuple INT -> INT
f3(x) == *(x)
f3(f1(5))
\end{axiom}

\start
Date: Wed, 29 Jun 2005 01:50:56 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#184 Complex argument is false.] 

\begin{axiom}
argument(-%i)
argument(-1+0*%i)
argument(-1)
\end{axiom}

\start
Date: Wed, 29 Jun 2005 01:45:48 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#185 append vs concat] 

\begin{axiom}
L1 := [1,2,3] ;
L2 := [10,11,12] ; 
L := append (L1, L2) ; 
L2.2 := 100 

\end{axiom}

\begin{axiom}
L1 := [1,2,3];
L2 := [10,11,12] ; 
Lc := concat (L1, L2) 
L1.2 :
Lc.2
L2.2 :=30
Lc.5
\end{axiom}

\start
Date: Wed, 29 Jun 2005 02:01:48 -0500
From: MathAction (wyscc)
To: MathAction
Subject: [#183 #3161: any? and every? should exit when the result is clear ] Have both?

How about just adding a more efficient any? and every? (don't overload
them though) in an auxilliary package? Nothing will be broken and you
can have both at your finger tips. I believe this is philosophy behind
many of the post-facto packages.

\start
Date: Wed, 29 Jun 2005 02:49:53 -0500
From: MathAction (unknown)
To: MathAction
Subject: [#183 #3161: any? and every? should exit when the result is clear ] any? and every?

The better way is to have a general policy for the axiom langage, not
to have more and more packages.  It must be possible to explain axiom
with very few words, and I find it's better to say that axiom is a
lazy language, so I believe that every? and any? must change.

\start
Date: Wed, 29 Jun 2005 01:32:10 -0700
From: Bob McElrath
To: list
Subject: point-sets and help systems

How do I generate a point-set from a graph?

e.g. draw(sin(x), x=0..6.28)
but I want a point-set instead of the graphics interface.

How can I find this out for myself, aside from poring through the 
code/axiom book?

For comparison, it took about 5 minutes to construct this in maxima:

    makelist(float([x*%pi/100,sin(x*%pi/100)]),x,0,200);

After 3 hours I finally figured out how to do it in axiom.  (I don't
give up that easily...)

    [[sin(i*%pi/100)$Float, i*%pi/100] for i in 1..200]

And the moral of the story is...hyperdoc is where the documentation is.
This should be made obvious from the command line.  Virtually any
attempt at getting help from the command line sends me on a wild goose
chase of ')what op' ')display op' ')help' etc.

Would it be possible to hide all that and not present it to the user as
if it was a working help system?  The 3-hour wild goose chase I just
went on will deter 99% of users right off the bat.

\start
Date: Wed, 29 Jun 2005 05:00:14 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: document, graphics

On Tuesday, June 28, 2005 7:32 PM Bob McElrath wrote:

> I would like to separate this discussion for the purpose of
> clarity. First, I have been discussing mostly document processing,
> and interaction with mathematical output.  As I've suggested,
> I think this can be accomplished with an absolutely minimal API:

I think this is a good design. :)

>    AppendInput(input)

What is the size of the unit input transaction? Would one Axiom
command per transaction might be too limiting? Of course it
might consist of multiple lines even for a single command. But
what about multi-line function definitions? What about compiling
SPAD code, versus interactive use? Should we treat a SPAD
compile as a unit transaction?

What about Axiom commands that do not increment the line counter
such as

 )set output autoload off

Should we prevent the gui user from accessing controls that
might interfere with the communication and state?

The API should always accept input without blocking. It will
perform buffering and queuing when Axiom is busy.

It will be important to design the API code carefully so that
it each transaction uniquely identified.

>    ModifyInput(line, newinput)

I assume you mean replace input line? (no need for API to computer
deltas) Ok if transaction size is small (one command only). At
this initial stage I think we should assume that editing will
remain basically a text editing problem, editing Axiom commands
for output and editing native HTML with jsMath extensions for
static text.

Maybe a little later we can play with HTML WYSIWYG gui editing
interfaces such as provided by Mozilla and/or javascript like
Kupu. I tried Kupu on the MathAction wiki but the embedded
LaTeX really makes this impossible. With a lot of work in
might be possible to use Kupu and jsMath together but for now
basic text-based editing seems like the best place to start.

>    GetOutput(line)

What happens if the output is not ready? Again non-blocking, gui
gets a "not ready" reply?

>    ComputationStatus()

Perhaps a timing and synchronization function in the API could
make this more efficient.

     WaitForOutput(line)

Some protocols might make use of "call backs" from the API back
to the browser. I think we should avoid this if possible.

I suppose the computation must be interruptible by the user.
Also in some cases (used to happen in Maple a lot :) the
following might be necessary

    KillAxiomAndRestart()

And maybe two more editing functions?

    DeleteInput(line)
    InsertInput(line, input)

Of course these could be implemented by ModifyInput but separating
them makes sense for efficiency.

Tracking all these things while performing some variation of the
LRE algorithm, sounds like a substantial coding effort. But I really
like this separation of function and isolating the browser from the
million little details. The idea of keeping the gui side as simple
as possible is the right approach. This also maximizes the benefits
since this API might very well be used by more than one interface -
for example TeXmacs would also greatly benefit.

The new TeXmacs/Axiom interface program on Windows is written in
C and makes extensive use of threading. Besides resolving timing
issues, it also does some significant recoding of the LaTeX
output (line folding) and accepts a limited set of commands to
control the state of the interface. I think LaTeX line folding
will remain an issue even with jsMath and MathML. Both MathAction
and the TexMacs interface make use of some fairly old and intricate
C code to do this manipulation. It works well but it is a bit
over due for some maintenance and code upgrading. I assume that
the new API will continue to do this LaTeX line folding?

> where the GetOutput call returns an sexp or xml document
> containing no code, but hints such as "sumterm1", "paragraph",
> "type".

The more I think about it, the less I think modifying Axiom to
produce a new output format is not a good idea for this project.
I think it is necessary to start setting some reasonable attainable
goals for the work over the next 3 - 4 months. I strongly suggest
that we retain the LaTeX output generated by Axiom for this stage
of the work.

I also think that attempting to use a lot of new XML to generalize
things is not a good idea at this time.

I recommend staying as close as possible to XHTML. Embedding
LaTeX as per the jsMath <span class=math> and <div class=math>
approach (in order to conform with as much as possible. LaTeX
embedded in XHTML still presents some coding challenges. To
minimize unexpected parsing failures CDATA bracketing might be
a good idea.

> Dependency tracking/re-evaluation can be handled inside Axiom.

I would say that Axiom should be used where possible with a
minimum of new coding. I expect a little archeology might dig
up some very useful pieces of interface code. I recall some
specific conversations with Mike Dewar regarding the extensions
that NAG coded in Axiom to support the Texplorer browser interface.
I am sure that most of that is still there but poorly documented.

I think however that a substantial part of the re-evaluation logic
will have to reside in the API. From my point of view, because
Axiom is so large, complex and largely undocumented, and the learning
curve is very high, I think making major modifications to Axiom
is just beyond the scope of this work.

> The last call ComputationStatus should return a list of lines
> for which computation is underway or need re-computation.

These could be used for worksheet status markup on the gui
display right?

> The second part of the discussion is non-mathematical input/output.
> e.g. graphs, diagrams.  Can we do the same thing as for mathematical
> output?  (e.g. the output contains only data structures and hints, and
> no code?)  This requires a graph renderer/manipulator which understands
> the underlying data structure.  (e.g. 1-dimensional point set,
> 2-dimensional graph, 3d point set with mesh, etc) "understanding the
> data structure" is a separate problem from "communicating the data
> structure" since the latter can be simply marshaled into an sexp
> or XML data structure.
>
> Furthermore "draw" should really be an alias for "give me a point-set
> approximation".  Axiom generates a point-set.  The *user-interface*
> must decide what to do with it.

I am not convinced that a "point-set" language would be adequate
given problems of resolution, scaling, rotation etc.

> Axiom shouldn't care whether it ends up in a pie chart or bar chart.
> These are user-interface concepts, not mathematical concepts.

This sounds very hard to me. I know that both Maple and Mathematica
have spent a lot of effort doing this sort of work over many years.

But I agree in principle if you are implying that it might be
a good idea to consider a modular approach, i.e. make it possible
to use a variety of external tools from gnuplot to fancy VRML
and large-scale emersion environments. If we can spend some time
to implement some of the new web standards here for graphics,
I think the pay-off would be great in the long run.

> So, I seem to be convincing myself that I want a back-end which
> knows absolutely nothing about user interfaces, but can serialize
> its output in either sexp or xml.

It makes me nervous the more generalized you make it sound.
I think it is important not to be ambitious. Instead we should
be able to make the most ground by sticking close to ground :)
We should do thinks that we now work now. Get a complete working
system for initial alpha release available as soon as possible.
And then work incrementally at replacing the kludge parts with
more well thought out code. That's the way it seems to go in
open source most of the time anyway, right?

I would even go so far as to suggest jumping immediately on to
your Tiddlywiki prototype as a good place for a running start.
(Great work by the way, Bob!) I think getting started fast with
our vision set at this high level is much better than continuing
to worry about low level details and other best practice issues.

Kai Kaminski [Kai Kaminski] wrote:
> >So you're proposing *three* applications?
> >1) axiom
> >2) sexp -> xml converter
> >3) web browser/javascript
> >
[...]
> Even in the beginning part 2) will be more than an sexp-to-xml 
> converter. Take plots as an example. Axiom supplies a list of points 
> that have to be connected with straight lines/splines/whatever. Then 
> part 2) generates SVG output, which isn't too hard but not trivial 
> either.

I think doing this much with SVG is a good idea.

> Suppose the plot contains some text, like a title or a description.
> We can't just stuff the text into the SVG file, because in XML
> certain characters have to be escaped. I don't want to implement
> all this in Javascript. But I don't want to have an SVG generator
> in Axiom either.

Your approach makes sense to me. In fact that is more or less the
way Axiom does it now. There is an Axiom-side component of the
graphics and then there is a separate graphics process communicating
via sockets that renders and manipulates the graph. Ideally
the rendering and manipulation part can be absorbed into the
new gui API layer. And then you need to learn in great detail
how the existing Axiom-side code used to talk to that external
process. Most of this is just a matter of patient software
archeology. But since all of this is working on the Linux platform
at least the code is not cold!

> If there is not an svg generator in axiom, what format should
> axiom present?

We need to check out exactly what it does now. I think the best
approach would be to change the Axiom side as little as possible.
Then the problem becomes emulating the graphics processor part
in a portable platform independent way. From my point of view
if this is one of the only major accomplishments of the summer of
code project, then I would still be very very happy.


> Suppose we want to support LaTeX as an input syntax for HyperDoc
> pages or something similar (Martin Rubey wants this, as I 
> understand). Do we want to put a LaTeX parser into Axiom? Do
> we want to implement one in Javascript?

No! I think that if general LaTeX to new HyperDoc is really
desirable, it should be done by stand alone tools, as much off
the shelf as possible. Ultimately we should depend as much a
possible on common HTML and CSS for the document formatting
and layout.

> This is fundamentally impossible because LaTeX is mathematically
> ambiguous.  e.g.
>    \int_a^b x d x
>    \int_a^b d x d x
> 'd' is a constant.  For that matter presentation MathML is also
> mathematically ambiguous.  (hence the creation of content mathml
> and OpenMath)

This is a different issue.

> ...
> We should restrict javascript to solely interface elements, and
> not allow it to do any mathematical processing.

With the exception of jsMath prior to MathML, I agree completely.

> ...
> One wouldn't need AJAX for help pages...or even file access as
> I have used in my example, but rather just <a href="file:///...">.

Remember that some browser pages allow for live tutorial kind of
interaction with Axiom. Static web pages are not sufficient for
this purpose.

> Re: "new hyperdoc page".  For the time being I think we should
> concentrate on all new hyperdoc being in the current pamphlet
> format. For this interface we can convert to HTML.  In the future
> we can contemplate converting pamphlet -> html en masse.  But
> for now let's keep an HTML UI document separate from a pamphlet.
> We should engineer things so that we can do a trivial HTML UI
> document -> pamphlet conversion.  Javascript is in the document
> for UI elements, but would be stripped for pamphlet conversion.
> A proper pamphlet representation should not depend on javascript,
> or running any code other than what can be delivered to the axiom
> engine.

Don't confuse the hyperdoc format with the literate programming
pamphlet files. Right now these are two rather different variations
on LaTeX for quite different purposes. It is true though what you
imply using pamphlet format for maintaining the hyperdoc files
might not be such a bad idea *if* we can reliably and automatically
convert then to the actually presentation format used on the
new AxiomUI. This sound like a fairly big job to add on to what
is already a big job.

> ...
> What I am saying is equivalent.  But you're forgetting that
> the hyperdoc pages are built as part of the build process.
> So the "code in the middle" is essentially the build code.

Could you describe this process in more detail? I don't
know much about it. But I had assumed that pamphlet files,
if they are used at all for the hyperdoc files, would just
be passive containers.

Of course Tim is the guy to talk to about all this!

> ... let's keep "pamphlet" as our primary format for the
> time being, and convert it.

Convert it during the build and install process? Continue
to maintain it in the format used now. Right?

[re: documentation]
> >The only thing missing from this idea is "search".
>
> Good example. Search is complex. Do we implement that in Javascript
> or will the search code be part of Axiom? If we have a process
> between Axiom an browser we can just put it in there.
>
> Neither.  It is a user interface issue, not a mathematical issue.
> It should be in the user interface, somewhere.  (though god no...
> not in javascript)  An XPCOM component could do it.

This is a web browser/desktop environment so why not use one of
the free desktop search tools?

Some quick references:

http://nutch.sourceforge.net/blog/2005/02/open-source-desktop-search.html
http://wiki.apache.org/jakarta-lucene/PoweredBy
http://www.activemath.org/
http://labs.commerce.net/wiki/images/0/06/CN-TR-04-04.pdf

I really like the idea of these sort of tools being integrated
with the rest of the web but able to be customized for individual
researchers and Axiom users. The web is the only way to fly,
even when it's just that 10 gigabytes of stuff sitting on your
desktop ...

> Also note that one could generate an index file with words and
> URI's. This could be parsed by javascript to make an efficient
> search engine. (But, all the logic has been moved to the build
> system which generates the index file)

No, no. I would stay far away from this stuff. I think that
just as with everything else, we should "collaborate" with
other open source developers and integrate major components
like this where ever possible.

[Thanks for the great references to work on SVG. :]

> Keep in mind that SVG+DOM has all the elements for a user interface
> to graphs.

Yes, I think that this is probably the right approach for at
least the 2-d graphics. 3-d interactive graphics might be better
handled as a later enhancement. There is still a possibility in
this case to make use of the prior work by NAG on the OpenInventor
VRML interface. This was the graphics interface that was used
with the Techexplorer browser on windows. So I think a lot of
the code must still be in there somewhere.

\start
Date: Wed, 29 Jun 2005 05:55:36 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: Tiddly Axiom Wiki
Cc: Camm Maguire

Bob,

On Monday, June 27, 2005 7:45 AM you wrote:

> I have gotten a preliminary *local* web-browser interface for
> Axiom working.  It uses pipes for communication.  Get it here:
>    http://bob.mcelrath.org/moz-axiom.tar.gz
> Un tar it, change to the moz-axiom directory that will be created,
> and run: ./fifo-axiom

Tres neat! I like it. I like it a lot! It's already starting
to look like my new preferred Axiom user interface, besides
MathAction, that is ...

> This will start axiom and set up communications pipes to talk
> to the web browser, then attempt to run firefox.  (edit this
> script if you want to use mozilla or some other browser -- but
> only mozilla-derived browsers will work) I copied an example
> from hyperdoc on Hilbert Matrices just to test.

It runs fine on Linux but of course not on Windows :(. I tried
several different ways to get it to go but I think in the end
Windows handling of pipes is just too different - even under
MSYS and Cygwin. I had so much trouble that I even began to
wonder how the TeXmacs/Axiom interface that I wrote last year
manages to make this work. It's a small C program written using
native Windows threads and process handling, though it talks to
both Axiom and TeXmacs through pipes. I tried for a while to
duplicate some of this in Python based on the way it works on
MathAction, but again things on Windows where just too different
and I couldn't even get Python to talk reliably to Axiom. Anyway
I know that this is possible, in fact maybe it is even a good
idea to use the TeXmacs/Axiom interface since it includes the
LaTeX line breaking code and a few other TeX to LaTeX tweaks
that were required by TeXmacs. And on Windows at least, native
threads are fast!

I am still planning real soon now to port this threaded TeXmacs
interface program back over to linux and some more portable
threads library.

But really the right and portable way to do this would be via
sockets and HTTP. Now that the AxiomUI project is off to a
running start, I think it would be a good idea to move Axiom
to the new version of GCL (currently Version_2_6_7pre) that
does sockets on Windows properly. Camm asked last week if we
thought he should just commit GCL 2.6.7 to CVS. He had been
waiting to see if more work could be done on the TK graphics
under Windows, but that looks unlikely now, and mostly no
longer relevant (for AxiomUI at least). So I think you should
go ahead and freeze GCL 2.6.7, Camm and we will move Axiom to
GCL 2.6.7 on both Linux and Windows.

Then we can start to use GCL with sockets they way this is
supposed to work.

> Also I implemented lazy re-evaluation the maximally stupid
> way: each new tiddler is fully re-evaluated (e.g. I issue a
> )clear all first).

Surprising how well that works even now!

> Please play with it, I hope it can be a means of discussing
> exactly how (and if) we want to involve a web browser in all
> this.

I think you have just answered the *if* with a very positive
"YES" demonstration.

> The tiddlywiki extensions I made earlier (allowing $x$) are
> still there.
>
> Axiom commands are included in \begin{axiom}...\end{axiom}
> just like on the MathAction Wiki, and in addition I copied
> some of Kai's work to add an input line to each tiddler.

Lovely!

> While I'm still disappointed with the rendering speed of
> jsMath (we can move to MathML in the future), it's quite a
> bit snappier than texmacs. Make sure to turn animations off
> in the options panel.

Yes, it does seem faster than TexMacs to me. Amazing.

> Undoubtedly there are bugs, but this is more a toy prototype...

It looks to me more like a prototype prototype. I hope that
Kai and others will agree to use this as a model.

As usual, Great Work. And Thanks!

\start
Date: Wed, 29 Jun 2005 11:48:54 +0200
From: Michel Lavaud
To: Bob McElrath
Subject: re: converting sexps to XML

Hello Bob,

On 28 Jun 2005 at 13:26, Bob McElrath wrote:

> I think these two ideas are very distinct.  A latex document is
> processed from top to bottom, once.  A change requires essentially a
> re-compile of the entire document. 

I don't agree with you on that point : I have devised a software (AsTeX as=
sistant) that 
allows to tune parts of TeX/LateX documents by selecting small portions of=
 the 
document and displaying it without compiling the whole document - for exam=
ple select 
a formula or part of formula, or part of a table - and display only the fo=
rmula, or part of 
the formula or table or etc.. You have just to select the portion of docum=
ent in your 
favorite editor (Emacs, or any other editor, even Word), click on the Disp=
lay button of 
AA, and the selected portion is displayed in the dvi viewing window. You c=
an even use 
predefined commands such as \def\g{\gamma} defined outside the selected te=
xt (say, 
defined in a special file such as mymacros.tex), or commands defined in La=
TeX 
packages. For illustrations, cf.

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/nouv31a/html/nouv31.htm

for part of a table + included figure + colored maths, and

http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/assist/html/aase7.htm

for part of a formula.

Of course, if one forces incorrect commands or undefined commands inside t=
he 
selected portion, the display is incorrect, in the same way as the result =
is incorrect if 
one forces an incorrect command or undefine variable in Axiom, or Maxima, =
or other 
interactive software. AA was presented at TUG2000 in Oxford, and various o=
ther 
places.

> Syntactic validity cannot be
> ensured in a sub-document of latex.  (e.g. I could insert
> "\end{paragraph}" in the middle of my paragraph...causing the parser
> to totally barf)  
> On the other hand XML has the concept of a DOM, which allows me to
> examine nodes individually, add/remove nodes, and modify the text
> inside a node, all in a self-contained manner.

I think one ought to compare what is comparable : it seems that you
consider the possibility to write an incorrect LaTeX document by
omitting \end{paragraph} in a dumb editor (say notepad under Windows)
? Well, OK, but I cannot see what would prevent me from writing an
incorrect XML document with the same editor ? It seems to me that,
either one uses a dumb editor and run an external software to check
the validity of the TeX or XML document, or one uses a specialized
editor for TeX or XML that prevents most or all errors. If one uses
LyX, one cannot introduce syntactic errors such as trailing
\end{paragraph} (except if one does it on purpose - but one could
create a version that forbids it). If one uses Emacs with AUC-TeX, or
any editor + AsTeX assistant to insert TeX/LaTeX commands, or other
"intelligent editors", one gets a mostly syntactically correct
document with the existing softwares ("mostly" in the sense that
errors would have a human origin, not because of TeX or the editor
used). One could even have an always syntactically correct document
with more effort (at least with AA, I had not the time to do it but
the plan is there). And if there are XML constructions that do not
exist in LaTeX, I suppose it could be possible to add commands in
LaTeX that implement them, in the same way LaTeX builds on Plain TeX
by adding \begin{} \end{}, \tableofcontents etc., and builds on
PostScript via \special{} to implement color (although TeX knows only
of B&W), or figures, rotations, etc. I would be very astonished if one
could prove that it is impossible to implement the DOM concept, or
other XML concepts, in LaTeX ?

\start
Date: Wed, 29 Jun 2005 06:55:58 -0400
From: Bill Page
To: Michel Lavaud
Subject: re: converting sexps to XML

On Wednesday, June 29, 2005 5:49 AM Michel Lavaud wrote:

> ... I have devised a software (AsTeX assistant) that allows to tune
> parts of TeX/LateX documents by selecting small portions of the
> document and displaying it without compiling the whole document - for
> example select a formula or part of formula, or part of a table - and
> display only the formula, or part of the formula or table or etc..
> You have just to select the portion of document in your favorite =
editor
> (Emacs, or any other editor, even Word), click on the Display button
> of AA, and the selected portion is displayed in the dvi viewing =
window.
> ... For illustrations, cf.
>
http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/nouv31a/html/nouv31.ht=
m
>

This sounds very similar to WhizzyTeX: "An Emacs minor mode for
incremental viewing of LaTeX documents."

http://pauillac.inria.fr/whizzytex/

WhizzyTeX is remarkably fast for what it does: Using ADVI it displays
in one window an up to date rendered version of the LaTeX document that
you are editing using Emacs in another window. On a 500+ MHz machine
with at least 256 Mb ram, this is acceptably fast for normal usage.
I have even successfully run this on my Zaurus 6000 handheld computer.
I learned about it from a colleague how uses it all of the time for his
writing. And this is now my preferred way of writing LaTeX documents
on my main office computer.

I have seriously considered whether it would be worth hacking the
Emacs code to run Axiom on the \begin{axiom} ... sections before it
is passed to ADVI. I am sure this would be very cool for the average
Emacs hacker. But there are just so many good options available
to do what we want with Axiom these days, that I haven't looked at
doing this more seriously. One idea that I had was to write macros
for TeX to invoke Axiom and process the Axiom commands. This way
it would be completely transparent to LaTeX users.

>...
> I would be very astonished if one could prove that it is impossible
> to implement the DOM concept, or other XML concepts, in LaTeX ?

I would not dare to take-on the challenge of an "impossibility proof"
but there are quite a lot of well known deficiencies and ambiguities
in LaTeX when it comes to representing meaning of mathematical
expressions. LaTeX is designed to be efficient at mathematical
typesetting and it does that extremely well. But if you would
like to design a graphical user interface that would for example
allow a user to select parts of an expressions from the typeset
mathematics displayed by LaTeX and feed that back into a computer
algebra system like Axiom, you would soon discover that in many
cases this is very difficult to do without the help of a human
being to interpret the expressions. Something as simple as the
standard conventions of multiplication and application of operators
can completely confuse the input system of most computer algebra
systems.

\start
Date: Wed, 29 Jun 2005 13:56:28 +0200
From: Ralf Hemmecke
To: Michel Lavaud
Subject: re: converting sexps to XML

I know a normal LaTeX user wouldn't do that but I am just wondering
whether AsTeX correctly outputs

   ac

(no equals sign, no b, no d) if I select the align* environment from the =

following file.

\documentclass{article}
\usepackage{amsmath}
\catcode`\&=14% & is now a character introducing a comment like %.
\begin{document}
\begin{align*}
   a&=b\\
   c&=d\\
\end{align*}
\end{document}

TeX is a programming language. No character has a fixed meaning. One can =

even redefine \ (backslash). Any parser of LaTeX code that is not TeX
(the program) itself will sooner or later run into trouble. The only way =

out would be to restrict to some subset of (La)TeX.

Ralf

Michel Lavaud wrote:
> Hello Bob,
>
> On 28 Jun 2005 at 13:26, Bob McElrath wrote:
>
>
>>I think these two ideas are very distinct.  A latex document is
>>processed from top to bottom, once.  A change requires essentially a
>>re-compile of the entire document.
>

> I don't agree with you on that point : I have devised a software
> (AsTeX assistant) that allows to tune parts of TeX/LateX documents
> by selecting small portions of the document and displaying it
> without compiling the whole document - for example select a formula
> or part of formula, or part of a table - and display only the
> formula, or part of the formula or table or etc.. You have just to
> select the portion of document in your favorite editor (Emacs, or
> any other editor, even Word), click on the Display button of AA, and
> the selected portion is displayed in the dvi viewing window. You can
> even use predefined commands such as \def\g{\gamma} defined outside
> the selected text (say, defined in a special file such as
> mymacros.tex), or commands defined in LaTeX packages. For
> illustrations, cf.

> http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/nouv31a/html/nouv31.htm

> for part of a table + included figure + colored maths, and

> http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/assist/html/aase7.htm

> for part of a formula.

> Of course, if one forces incorrect commands or undefined commands
> inside the selected portion, the display is incorrect, in the same
> way as the result is incorrect if one forces an incorrect command or
> undefine variable in Axiom, or Maxima, or other interactive
> software. AA was presented at TUG2000 in Oxford, and various other
> places.

>
>>Syntactic validity cannot be
>>ensured in a sub-document of latex.  (e.g. I could insert
>>"\end{paragraph}" in the middle of my paragraph...causing the parser
>>to totally barf) 
>>On the other hand XML has the concept of a DOM, which allows me to
>>examine nodes individually, add/remove nodes, and modify the text
>>inside a node, all in a self-contained manner.
>

> I think one ought to compare what is comparable : it seems that you
> consider the possibility to write an incorrect LaTeX document by
> omitting \end{paragraph} in a dumb editor (say notepad under
> Windows) ? Well, OK, but I cannot see what would prevent me from
> writing an incorrect XML document with the same editor ? It seems to
> me that, either one uses a dumb editor and run an external software
> to check the validity of the TeX or XML document, or one uses a
> specialized editor for TeX or XML that prevents most or all
> errors. If one uses LyX, one cannot introduce syntactic errors such
> as trailing \end{paragraph} (except if one does it on purpose - but
> one could create a version that forbids it). If one uses Emacs with
> AUC-TeX, or any editor + AsTeX assistant to insert TeX/LaTeX
> commands, or other "intelligent editors", one gets a mostly
> syntactically correct document with the existing softwares ("mostly"
> in the sense that errors would have a human origin, not because of
> TeX or the editor used). One could even have an always syntactically
> correct document with more effort (at least with AA, I had not the
> time to do it but the plan is there). And if there are XML
> constructions that do not exist in LaTeX, I suppose it could be
> possible to add commands in LaTeX that implement them, in the same
> way LaTeX builds on Plain TeX by adding \begin{} \end{},
> \tableofcontents etc., and builds on PostScript via \special{} to
> implement color (although TeX knows only of B&W), or figures,
> rotations, etc. I would be very astonished if one could prove that
> it is impossible to implement the DOM concept, or other XML
> concepts, in LaTeX ?

\start
Date: Wed, 29 Jun 2005 12:04:13 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: point-sets and help systems

On Wednesday, June 29, 2005 4:32 AM Bob McElrath wrote:

> How do I generate a point-set from a graph?
>
> e.g. draw(sin(x), x=0..6.28)
> but I want a point-set instead of the graphics interface.

For more technical information take a look at

 axom--main--1/src/graph/fileformats.pamphlet

\author{The Axiom Team} (aka. Tim Daly, the optimist :) has
made a good start at describing the "point set" data that is
passed from Axiom to the graphics processor.

> How can I find this out for myself, aside from poring through
> the code/axiom book?
>
> For comparison, it took about 5 minutes to construct this
> in maxima:
>
>    makelist(float([x*%pi/100,sin(x*%pi/100)]),x,0,200);
>

What part of the maxima user interface contributed to making it
possible for you to find the necessary information? Your view
as a *user* is very important. So often the people who develop
complex systems devote almost no effort to making the system
easy to use - after all they know exactly how to use it. But
somebody new walking up to the system for the first time will
see something entirely different. It is very useful to harness
their energy and bottle it for others, e.g. that's why so many
open source software projects are waiting and hoping that new
users will actually produce documentation in return for free
access to the software. The web site wiki interface was supposed
to enable this - and it has worked in a few cases.

Unfortunately it seems that most people who came to work on Axiom
for the first time were often already caught up in intricate details
of heir own complex project or PhD thesis or whatever and didn't
have much time to devote to user interface.

Of course as you point out below, the Axiom hyperdoc project
was an early attempt to solve this problem.

> After 3 hours I finally figured out how to do it in axiom. 
> (I don't give up that easily...)
>
>    [[sin(i*%pi/100)$Float, i*%pi/100] for i in 1..200]
>

You should get an "A" for that solution, but I'll give you an "B"
(: You'll get the rest of your mark when you add a paragraph to
the wiki site explaining how it works. See something near:

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

Email doesn't really count since someone else (some day, if ever)
will have to mine the list of useful tid-bits like this. You
are done once a quick search with a couple of likely keywords
returns your example and explanation.

> And the moral of the story is...hyperdoc is where the documentation
> is. This should be made obvious from the command line.

Hmmm, well if I type

  axiom

from the Linux shell I do get hyperdoc right up front. You mean
you also need a reminder from the Axiom command line?

> Virtually any attempt at getting help from the command line
> sends me on a wild goose chase of ')what op' ')display op'
> ')help' etc.

Actually you are right. As I consider myself a more experienced
(and impatient) user I almost never start Axiom with hyperdoc and
I have to remind myself that it is available for questions like
these. I would be nice if typing

  )help

actually launched hyperdoc, instead of the other way around.

> Would it be possible to hide all that and not present it to
> the user as if it was a working help system?  The 3-hour wild
> goose chase I just went on will deter 99% of users right off
> the bat.

I agree with this. In fact I think this is one reason why the
AxiomUI project should have such a high priority. Hyperdoc is
not available for the Windows users of Axiom - where a lot of
these sort of questions are most like to be asked - and even
on Linux the old hyperdoc browser (useful though it is!) looks
old, unapproachable and basically just ugly by today's standards.

One thing that I always wanted to do but never found time was
to extract just the HTML-able and LaTeX-able parts of the hyperdoc
pages and make them available as essential static pages on the
Axiom web site. As documentation this would be great even though
it would be missing most of the dynamic browser features that
depend on the Axiom database to define the relationships between
algebra components. Of course it would be possible to load the
Axiom database itself in some from accessible to a web site. This
would also be a major part of the new stand alone AxiomUI browser,
so efforts to convert the hyperdoc pages (using one of the
tex-to-html tools) could serve two purposes: stand alone and
online Axiom web site support. Mostly what we have to decide
is how to implement the navigation in an HTML friendly manner.

BTW, when you were spending your 3 hours learning this lesson,
did you happen to think of doing a search on MathAction?

\start
Date: 29 Jun 2005 11:31:19 -0400
From: Camm Maguire
To: Bill Page
Subject: 2.6.7 [was Re: Tiddly Axiom Wiki]
Cc: Mike Thomas

Greetings!

Bill Page writes:

> Bob,
> 
> On Monday, June 27, 2005 7:45 AM you wrote:
> 
> > I have gotten a preliminary *local* web-browser interface for
> > Axiom working.  It uses pipes for communication.  Get it here:
> >    http://bob.mcelrath.org/moz-axiom.tar.gz
> > Un tar it, change to the moz-axiom directory that will be created,
> > and run: ./fifo-axiom
> 
> Tres neat! I like it. I like it a lot! It's already starting
> to look like my new preferred Axiom user interface, besides
> MathAction, that is ...
> 

Thanks for your work!  Will try to find time to check it out soon.  In
general, please everyone accept my apologies regarding my absense in
this thread.  I'm tied down this summer with making the gcl ansi image
compliant, which I think will serve us all well in the long term.

My $0.02 regarding UI for browsing and graphics:

1) I agree with Martin, we need an emacs interface option too.(!)  It
   is the only tool in which I can get any real work done.

2) Please make sure we centralize on freely available (as in free
   software, 'libre', not beer), widely distributed, maximally
   portable, longstanding and lightweight solutions.  I have my own
   questions regarding jsmath, mathml, and the like, mostly stemming
   from my ignorance of them, and general suspicion of anything which
   might make us depend on java (do these?).  I don't think anything
   can match TeX in scientific user mindshare.  To the extent we can
   lever this avenue for result presentation, I think we'll be set for
   life.  I realize however that this might not be a total solution.

3) I defer whole heartedly to the opinions of you wonderful souls who
   are actually doing the work!  Please consider the maintainability
   of the solution by others should you ever be separated from the
   project. 

> But really the right and portable way to do this would be via
> sockets and HTTP. Now that the AxiomUI project is off to a
> running start, I think it would be a good idea to move Axiom
> to the new version of GCL (currently Version_2_6_7pre) that
> does sockets on Windows properly. Camm asked last week if we
> thought he should just commit GCL 2.6.7 to CVS. He had been
> waiting to see if more work could be done on the TK graphics
> under Windows, but that looks unlikely now, and mostly no
> longer relevant (for AxiomUI at least). So I think you should
> go ahead and freeze GCL 2.6.7, Camm and we will move Axiom to
> GCL 2.6.7 on both Linux and Windows.
> 
> Then we can start to use GCL with sockets they way this is
> supposed to work.

Tim, are you no longer interested in gcl-tk?

Mike, any news on this front?  Will be replying separately to your
other email, but in general I think that if this is close, making this
a portable option on Windows for 2.6.7 is more important than working
on 2.7.0 at this burning point in time, as the latter is in such a
state of flux.  I would appreciate, however, as 2.7 develops, if you
could scan over the commit logs and give me a notice if you see
anything being put in place which you know will give us troubles later
on in Windows.  I know of no such development at this point, save that
which can be addressed by some edits to configure.in.

If Tim doesn't need gcl-tk and wants the sockets, or if Mike states
that gcl-tk is far off on Windows in any case, please both so state,
and I'll test and tag the 2.6.7pre branch for release.  There is one
other thing which should have gone in but I don't have time for right
now -- we need to buld xgcl as a loadable module by default where
possible for people who need it at the University of Texas.

Mike, if and when we release 2.6.7, then any help you can lend on the
ansi front would be most appreciated.

\start
Date: Wed, 29 Jun 2005 12:39:17 -0500
From: Tim Daly
To: Camm Maguire
Subject: introduction

Camm,

re: Emil. you missed a phone conversation. i was telling him that we
had trouble getting lisp running under SELinux and, as he knows the
guys that wrote it, he wanted to give them feedback. 

re: gcl-tk and gcl-2.6.7pre -> gcl-2.6.7 
i'd place the priority of getting the gcl-2.6.7pre -> gcl-2.6.7 
transition to take place. progress on that front is more important
than the gcl-tk code.

\start
Date: Wed, 29 Jun 2005 19:57:03 +0200
From: David Mentre
To: Kai Kaminski
Subject: About noweb and literate programming

Hello Kai and other Axiom developers,

Tim Daly writes:

> We get the second field from the string which is the abbreviation.
> <<capture the abbreviation>>=
[...]
> @
> <<srcabbrevs>>=
[...]
> <<capture the abbreviation>>
>   (values names longnames))))
> @

Against Tim opinion and use, I would recommend to *never* use the
ability of noweb to include recursively code chunks, for two reasons:

 1. technically, noweb code chunk inclusion is a poor man macro system,
    which is dangerous and can produce difficult bugs. It does not
    handle variable binding as, for example, any Lisp macro system does;

 2. personally, I find that it clutters the output and make the reading
    not so easy.

I much prefer this style:

<<file.cl>>
(defun blabla ....)
@

<<file.cl>>
(defun blibli
  (blabla ....))
@

Other than that ;-), I strongly agree with Tim that literate programming
is a huge step towards having long term maintainable code. For what it
is worth, I'm developing my own pet project with noweb. You'll find the
produced output and source code in following links.

 http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-book-0.5.1.pdf
 http://www.linux-france.org/~dmentre/demexp/latest-src/demexp-0.5.1.tar.gz

\start
Date: Wed, 29 Jun 2005 21:03:48 +0200
From: Michel Lavaud
To: list
Subject: (Fwd) re: converting sexps to XML

Hello Ralf,

I forgot a step in my preceding message : after selecting with the the
mouse, the four lines of you text in Pegasus mail, I click on the
"Display" button of AA, of course!

And, if you want to trick the behaviour of Assistant AsTeX : every
global redefinition  is not considered, except if it is in the
selected portion of text. For example, if you define \g to mean \gamma
in latex2e.beg, and you redefine \g somewhere in your book to mean
something else, \g will mean \gamma correctly in the partial display
before the redefinition, but also \gamma incorrectly after the
redefinition.

Best wishes,
Michel

> I know a normal LaTeX user wouldn't do that but I am just wondering
> whether AsTeX correctly outputs
> 
>    ac
> 
> (no equals sign, no b, no d) if I select the align* environment from
> the following file.
> 
> \documentclass{article}
> \usepackage{amsmath}
> \catcode`\&=14% & is now a character introducing a comment like %.
> \begin{document} \begin{align*}
>    a&=b\\
>    c&=d\\
> \end{align*}
> \end{document}
> 
> TeX is a programming language. No character has a fixed meaning. One
> can even redefine \ (backslash). Any parser of LaTeX code that is
> not TeX (the program) itself will sooner or later run into trouble.
> The only way out would be to restrict to some subset of (La)TeX.
> 
> Ralf
> 
> Michel Lavaud wrote:
> > Hello Bob,
> > 
> > On 28 Jun 2005 at 13:26, Bob McElrath wrote:
> > 
> > 
> >>I think these two ideas are very distinct.  A latex document is
> >>processed from top to bottom, once.  A change requires essentially
> >>a re-compile of the entire document. 
> > 
> > 
> > I don't agree with you on that point : I have devised a software
> > (AsTeX assistant) that allows to tune parts of TeX/LateX documents
> > by selecting small portions of the document and displaying it
> > without compiling the whole document - for example select a
> > formula or part of formula, or part of a table - and display only
> > the formula, or part of the formula or table or etc.. You have
> > just to select the portion of document in your favorite editor
> > (Emacs, or any other editor, even Word), click on the Display
> > button of AA, and the selected portion is displayed in the dvi
> > viewing window. You can even use predefined commands such as
> > \def\g{\gamma} defined outside the selected text (say, defined in
> > a special file such as mymacros.tex), or commands defined in LaTeX
> > packages. For illustrations, cf.
> > 
> > http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/nouv31a/html/nou
> > v3 1.htm
> > 
> > for part of a table + included figure + colored maths, and
> > 
> > http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/assist/html/aase
> > 7. htm
> > 
> > for part of a formula.
> > 
> > Of course, if one forces incorrect commands or undefined commands
> > inside the selected portion, the display is incorrect, in the same
> > way as the result is incorrect if one forces an incorrect command
> > or undefine variable in Axiom, or Maxima, or other interactive
> > software. AA was presented at TUG2000 in Oxford, and various other
> > places.
> > 
> > 
> >>Syntactic validity cannot be
> >>ensured in a sub-document of latex.  (e.g. I could insert
> >>"\end{paragraph}" in the middle of my paragraph...causing the
> >>parser to totally barf)  On the other hand XML has the concept of
> >>a DOM, which allows me to examine nodes individually, add/remove
> >>nodes, and modify the text inside a node, all in a self-contained
> >>manner.
> > 
> > 
> > I think one ought to compare what is comparable : it seems that
> > you consider the possibility to write an incorrect LaTeX document
> > by omitting \end{paragraph} in a dumb editor (say notepad under
> > Windows) ? Well, OK, but I cannot see what would prevent me from
> > writing an incorrect XML document with the same editor ? It seems
> > to me that, either one uses a dumb editor and run an external
> > software to check the validity of the TeX or XML document, or one
> > uses a specialized editor for TeX or XML that prevents most or all
> > errors. If one uses LyX, one cannot introduce syntactic errors
> > such as trailing \end{paragraph} (except if one does it on purpose
> > - but one could create a version that forbids it). If one uses
> > Emacs with AUC-TeX, or any editor + AsTeX assistant to insert
> > TeX/LaTeX commands, or other "intelligent editors", one gets a
> > mostly syntactically correct document with the existing softwares
> > ("mostly" in the sense that errors would have a human origin, not
> > because of TeX or the editor used). One could even have an always
> > syntactically correct document with more effort (at least with AA,
> > I had not the time to do it but the plan is there). And if there
> > are XML constructions that do not exist in LaTeX, I suppose it
> > could be possible to add commands in LaTeX that implement them, in
> > the same way LaTeX builds on Plain TeX by adding \begin{} \end{},
> > \tableofcontents etc., and builds on PostScript via \special{} to
> > implement color (although TeX knows only of B&W), or figures,
> > rotations, etc. I would be very astonished if one could prove that
> > it is impossible to implement the DOM concept, or other XML
> > concepts,  in LaTeX ?

\start
Date: Wed, 29 Jun 2005 13:44:42 -0500
From: Tim Daly
To: David Mentre
Subject: About noweb and literate programming

David,

re: recursive chunking

you're assuming that the whole of a function is to be documented
in one long set of paragraphs. this isn't the style used by knuth
in the tex documentation. it also will end up being used everywhere
in axiom because the method of bug fixes uses it. when a piece of
code is fixed i remove the piece of code, replace it with a chunk
name, and add a subsection explaining what the old code did, what
the bug was, and what the new code does.

i've looked at your PDF and it appears that you are doing a 
linear description of the code. with Axiom there is no linear
development of code in a file so your repeated use of the
chunkname (with implicit concatenation) isn't going to carry
over into the axiom domain.

that said (and who doesn't argue about style :-) ) i'm happy
to see that you're using noweb to document your code.

re: noweb

Tim Daly, Jr. is writing a version of noweb in lisp. That way we
can have the same functionality embedded everywhere rather than
just as a preprocessor.

\start
Date: Wed, 29 Jun 2005 12:09:59 -0700
From: Bob McElrath
To: Camm Maguire
Subject: Re: 2.6.7 [was Re: Tiddly Axiom Wiki]
Cc: Mike Thomas

Camm Maguire [Camm Maguire] wrote:
> My $0.02 regarding UI for browsing and graphics:
> 
> 1) I agree with Martin, we need an emacs interface option too.(!)  It
>    is the only tool in which I can get any real work done.

As long as we keep text/tex output and text input, I don't think this
will ever be a problem.  (e.g. keep the UI and Axiom as decoupled as
possible)

> 2) Please make sure we centralize on freely available (as in free
>    software, 'libre', not beer), widely distributed, maximally
>    portable, longstanding and lightweight solutions.  I have my own
>    questions regarding jsmath, mathml, and the like, mostly stemming
>    from my ignorance of them, and general suspicion of anything which
>    might make us depend on java (do these?).

Java != Javascript.  Perhaps we should be saying emcascript instead
(which is an ISO standard).  No one has suggested using java for
anything at all.  There is absolutely no reason to add another language
to the mix, except as may relate to creating user interfaces.
Emcascript is solely a scripting language used to bind actions to UI
elements in a web browser.  It is already built into all web browsers.
My tiddly-axiom-wiki example contains a large amount of emcascript code.
This is undesirable...but it's just a prototype...

It *could* be done in java, but I wouldn't touch it with a 10 foot pole.
Besides, if in java, then why not in lisp?  I agree on the libre point.
The technologies we are discussing (mozilla, emcascript, jsmath, mathml,
svg) are all libre or defined standards by recognized standards bodies
such as the W3C and ISO.

Someone has been spamming the AxiomUI page with anti-java remarks.
Dunno who.  I reverted them.  But this project has absolutely nothing to
do with java.

> I don't think anything
>    can match TeX in scientific user mindshare.  To the extent we can
>    lever this avenue for result presentation, I think we'll be set for
>    life.  I realize however that this might not be a total solution.

For the near future we will depend on tex output, and have it rendered
in the UI using jsMath.  In the future we should switch to MathML
(probably with a tex->MathML translator such as itex in the middle for a
while), because this will allow greater interaction with expressions.
(e.g. highlighting terms, etc -- which isn't possible with jsMath)

If I have anything to say about it, tex will *always* be an output
format.  I don't see myself writing physics papers with MathML anytime
soon.

\start
Date: Wed, 29 Jun 2005 12:25:06 -0700
From: Bob McElrath
To: Michel Lavaud
Subject: re: converting sexps to XML

Michel Lavaud [Michel Lavaud] wrote:
> Hello Bob,
> 
> On 28 Jun 2005 at 13:26, Bob McElrath wrote:
> 
> > I think these two ideas are very distinct.  A latex document is
> > processed from top to bottom, once.  A change requires essentially a
> > re-compile of the entire document. 
> 
> I don't agree with you on that point : I have devised a software
> (AsTeX assistant) that allows to tune parts of TeX/LateX documents by
> selecting small portions of the document and displaying it without
> compiling the whole document - for example select a formula or part of
> formula, or part of a table - and display only the formula, or part of
> the formula or table or etc.. You have just to select the portion of
> document in your favorite editor (Emacs, or any other editor, even
> Word), click on the Display button of AA, and the selected portion is
> displayed in the dvi viewing window. You can even use predefined
> commands such as \def\g{\gamma} defined outside the selected text
> (say, defined in a special file such as mymacros.tex), or commands
> defined in LaTeX packages. For illustrations, cf.

So you have essentially forced a DOM on top of an otherwise free-form
latex document.

The distiction is that in a free-form latex document I can create an
invalid document.  Using a DOM I must insert only well-formed parts.
(e.g. every \begin{name} must have a corresponding \end{name})

This can be done, and I'm not surprised someone did it because the idea
of a DOM is quite powerful.  However, it is not something tex was
designed to do.  Since tex is a programming language I'm sure there is
some combination of macros I could define in the preamble which would
totally break enforcing your DOM.

On the other hand, XML is *not* a programming language, it is solely a
data structure.  This conforms to the "principle of least power":

    http://www.w3.org/DesignIssues/Principles.html

(at the bottom).  I ran into that page the other day and found it quite
compelling.  I wouldn't call myself an XML aficionado, but as long as I
don't have to actually *type* an xml document and *type* angle brackets,
I might be able to live with it...and the interface possibilities are
truly stunning.  (I'm going to send some SVG examples and info in a day
or two)

TeX, lisp, and sexps are all turing-complete languages.  Therefore it is
always possible to do *anything at all* in them.

However separating what is data, what is interface, and what does
computation allows our wee human brains to organize effectively.

\start
Date: Wed, 29 Jun 2005 21:00:39 +0200
From: Michel Lavaud
To: list
Subject: (Fwd) re: converting sexps to XML

Hello Ralf,

On 29 Jun 2005 at 13:56, Ralf Hemmecke wrote:

> I know a normal LaTeX user wouldn't do that but I am just wondering
> whether AsTeX correctly outputs
> 
>    ac
> 
> (no equals sign, no b, no d) if I select the align* environment from
> the following file.
> 
> \documentclass{article}
> \usepackage{amsmath}
> \catcode`\&=14% & is now a character introducing a comment like %.
> \begin{document} \begin{align*}
>    a&=b\\
>    c&=d\\
> \end{align*}
> \end{document}
> 
> TeX is a programming language. No character has a fixed meaning. One
> can even redefine \ (backslash). Any parser of LaTeX code that is
> not TeX (the program) itself will sooner or later run into trouble.
> The only way out would be to restrict to some subset of (La)TeX.

Yes, it works without any problem. I send you two screen copies as
attached files, one of the original location of your portion of text,
as selected directly in my mailer. And a second, a copy of the dvi
windows that displays the correct output.

The purpose of AA is to work with any TeX-like input, so it uses TeX
itself, not a LaTeX parser, and it works also with Plain TeX and
TeXinfo. It works with an input file with "beg" extension, that
contains or loads the special definitions used for the document. For
your example, I have just added amsmath and the \catcode line in the
default file latex2e.beg. But if you have different documents, for
example two books you are writing in parallel, with (let's consider
the worst case) different and even incompatible macros, you can add
these definitions in two files with beg extension and the names of the
main files of your two books. If an xyz.beg file exists for the book
xyz.tex, the xyz.beg file is used. Otherwise, the default file
latex2e.beg file is used, or plain.beg file if you use Plain TeX for
your book.

And the type of the file xyz.tex (Plain or LaTeX) is stored in another
initialisation file xyz.env. The latter stores also other informations
(such as paths for tfm, TeX format, paths of figures, type of
compilation etc.) necessary to compile the document. As for beg files,
there is also a default env file that stores default values if xyz.env
is not defined.

To summarize the steps I used :

1 - I opened your message in my mailer (Pegasus mail)
2 - I clicked on the button "Head L2e" of the panels of AA devoted to
TeX treatment; that opened the header file latex2e.beg 3 - I added the
two lines indicated above in this file latex2e.beg and saved the
modifs 4 - I selected "Pegasus mail" as input window in AA 5 - I
selected the 4 lines to be displayed in the align* environment.

The first 3 steps have to be done only once - or each time you add a
LaTeX package, or define your own macro if everything was not planned
from the beginning. The 4th step is used only once, when you change
the source window, for ex when you change from Emacs to Pegasus mail,
or to Word, etc.

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  Redimensionnement de Ralf01.jpg
     Date:  29 Jun 2005, 15:03
     Size:  57347 bytes.
     Type:  JPEG-image

--Message-Boundary-7958

/9j/4QEaRXhpZgAASUkqAAgAAAAIABIBAwABAAAAAQAAABoBBQABAAAAbgAAABsBBQABAAAA
dgAAACgBAwABAAAAAgAAADEBAgAcAAAAfgAAADIBAgAUAAAAmgAAABMCAwABAAAAAQAAAGmH
BAABAAAArgAAAAAAAABIAAAAAQAAAEgAAAABAAAAQUNEIFN5c3RlbXMgRGlnaXRhbCBJbWFn
aW5nADIwMDU6MDY6MjkgMTU6MDM6NTQABQAAkAcABAAAADAyMjCQkgIAAwAAADkwAAACoAQA
AQAAAIACAAADoAQAAQAAAMcBAAAFoAQAAQAAAPAAAAAAAAAAAgABAAIABAAAAFI5OAACAAcA
BAAAADAxMDAAAAAANwYAAP/AABEIAccCgAMBIgACEQEDEQH/2wCEAAcEBQYFBAcGBQYHBwcI
ChELCgkJChUPEAwRGRYaGhgWGBgcHygiHB0mHhgYIy8jJikqLS0tGyExNDErNCgsLSsBCwsL
Dw0PHhERHkArJCtAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA
QEBAQEBAQP/EALsAAQACAwEBAQAAAAAAAAAAAAAFBgIDBAcBCBAAAQIEAwIFCw8ICAYCAgID
AQIDAAQFEQYSIRMxFCJBUWEHFRcyUlR0lKLR0hYjNDU2U1VWcYGRkpOxsjNCcnN1obPBRmKC
lbTCw+EIJCU3o/AY02PxZYNDRIQBAQEBAQEBAAAAAAAAAAAAAAABAgMEBREBAAIBAgYCAQEH
BQAAAAAAAAERAhITBCExQVFhAyKRgRQkcaGxwfAjMkJi8f/aAAwDAQACEQMRAD8Aw6oGJcXO
dWOqYfodYqstLoQhxtEqhCktDKkrUrNaydd99Ljkis1LEnVGp2KqdhybxfNNVSceaacZWhOW
X2pGQlQBB0VqBuII1id6sfUvxDibqiVOp0qakmpd/K3lceUlRsgJIICTpcRWJPqMYzkamxUG
J+mtzcu4lxp0zCyUKSQUkXRyECPofFouJmYqvXhiXZOVzqppSF0/EM/OpylS05UtONarACkK
AIJDaynnANo0M17qwPrYQ1U59S3wciQ8ze42ZIUPzT683obHjiNlO6lWO6a1MtSVTpbTc2QX
k7YkLICgDYo3gLVY79TEzMYN6oq5GSYanqO1wW5LxcK1PKOy1XmbsqxYbIuLgp3x6pz+GOmn
8JUq4jFHVbWGstUqN3kFaElxoKKQoIJI3jjKA1jEYw6qDc/TpadxBOSnXF9LDK3FtkAlQTcg
AkAE80TjGBuqZLPtPM1ymtrZWtxNl2GZZuokbOxuQN99wtujkc6mfVBd4Hnq9NPAnzMsWeIy
O3Bz/k9TcDfeLufB/wBSpbJ2d6r0qkJNdm1vqnJiVSyFISVbHLmcBIAyEqABvrEdV8W9UukU
PrlP4knmLPoYLCwkLzK2uu61gWVDnvyRLuYF6prwQH6/IvJQnIEvPlactkjKQWyCLITp0A74
5q11NeqDWmVM1Or019tTgdUhTxAKwVm+jY5XHPrGEZ/B3nH8HNU+y3jv4yz3k+aHZbx38ZZ7
yfNEt2DcUd80n7dfoQ7BuKO+aT9uv0I67nCekrJE9lvHfxlnvJ80Oy3jv4yz3k+aJYdQzFJ3
TFJPyPr9CB6hmKQbGYpI/wD71+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNEt2DcU980n7df
oQHUMxSd0xSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNEseoZikGxmKSDzbdfoQ7BuKe
+aT9uv0IbnCeiskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/br9CHYNxT3zSft1+hDc4T0
Vkiey3jv4yz3k+aHZbx38ZZ7yfNEt2DMU98Un7dfoQ7BuKe+aT9uv0IbnCeiskT2W8d/GWe8
nzQ7LeO/jLPeT5oluwbijvmk/br9CHYNxT3zSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7y
fNEt2DMU98Un7dfoQ7BuKO+aT9uv0IbnCeiskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/
br9CHYNxR3zSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNEt2DcUd80n7dfoQ7BuKO+aT
9uv0IbnCeiskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/br9CHYNxR3zSft1+hDc4T0Vki
ey3jv4yz3k+aHZbx38ZZ7yfNEt2DcUd80n7dfoQ7BuKO+aT9uv0IbnCeiskT2W8d/GWe8nzQ
7LeO/jLPeT5oluwbijvmk/br9CHYNxR3zSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNE
t2DcUd80n7dfoQ7BuKO+aT9uv0IbnCeiskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/br9
CHYNxR3zSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNEt2DcUd80n7dfoQ7BuKO+aT9uv
0IbnCeiskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/br9CHYNxR3zSft1+hDc4T0Vkiey3
jv4yz3k+aHZbx38ZZ7yfNEt2DcUd80n7dfoQ7BuKO+aT9uv0IbnCeiskT2W8d/GWe8nzQ7Le
O/jLPeT5oluwbijvmk/br9CHYNxR3zSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNEt2D
cUd80n7dfoQ7BuKO+aT9uv0IbnCeiskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/br9CHY
NxR3zSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNEt2DcUd80n7dfoQ7BuKO+aT9uv0Ib
nCeiskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/br9CHYNxR3zSft1+hDc4T0Vkiey3jv4
yz3k+aHZbx38ZZ7yfNEt2DcUd80n7dfoQ7BuKO+aT9uv0IbnCeiskT2W8d/GWe8nzQ7LeO/j
LPeT5oluwbijvmk/br9CHYNxR3zSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNEt2DcUd
80n7dfoQ7BuKO+aT9uv0IbnCeiskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/br9CHYNxR
3zSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNEt2DcUd80n7dfoQ7BuKO+aT9uv0IbnCe
iskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/br9CHYNxR3zSft1+hDc4T0Vkiey3jv4yz3
k+aHZbx38ZZ7yfNEt2DcUd80n7dfoQ7BuKO+aT9uv0IbnCeiskT2W8d/GWe8nzQ7LeO/jLPe
T5oluwbijvmk/br9CHYNxR3zSft1+hDc4T0Vkiey3jv4yz3k+aHZbx38ZZ7yfNEt2DcUd80n
7dfoQ7BuKO+aT9uv0IbnCeiskT2W8d/GWe8nzQ7LeO/jLPeT5oluwbijvmk/br9CHYNxR3zS
ft1+hDc4T0Vkiey3jv4yz3k+aLt1F8X4nxhiSckq1iWrlhiSU+kS7yG1FQWhOpyHSyjFf7Bu
KO+aT9uv0IsXU/6nmMMGVOanJYUSZVMyqpYpcm3E5QVJVcFKb34v745fPnw0/HOir/RYu3o1
al5uUpb77GIsSBxAGUqnkEaqA3bLpjimpuoMVF5pMxi9cm1NmVM515lwNHNnmybPNa/ReIlq
mY2Zp78omWo7iHikqVM1aZfULEHQrBtuja/JY1emHXFSdECXZgzCmRU5jZ5yvP2uXdm1tHyf
t6/k220epzgo9bqVXxBidbFPq0xK/wDLzSLtsN5OOobPW2YlR5hu0jmrdcmjL0d+mVmvvSNU
XMtKTPPpUl5oMLKVJAQCEqIBB5RbTWNMjRMXsSE9JzNMwzNsztRcqC0PTb1s6ighNgnUAoB1
38sYTlAxEsyjk3IUGQkKcqZmlIkZhxRJW0sKslSbDVV7CwjczN9q/TwL7jlpx5iptMhwrWqw
2aSpXbC9gN+l4rzkjVW1FyjXbZCcqAtsMrIJSVcQ2ANwbX5Pli51JlT9XmUNMrdWXFWSgqJP
zAxFNT0o7PuSTJC3mUBbqUrV62DuvrvOunRHnpbbZcOiWbEwpKncgCykWBVbW3zxXJZE4iqz
5YlJ5Ly5hSkvlpCUlraAkIWrlKd2YWizEf8AJTM4loGWlVZXnNsRlOh3Zrm1xBKULUkNoKyr
tQlajm5dNYTNc5ELhiRqcmSam6VJ2CEBAcCgFDed28339HyRsxRwxcs0zIqW0VLKluoZW6U5
dUiyNdVWPNZJHLEsC2T2p59VrH84h6zimi0aealai9slOb1ZllKObNY6Xi44zl/t5pllGPWX
E8ziCZU6+A41tWFI2aXW05blRASCNLcS5Vroq0bWZfETbjKTMoLYQoK7Q5Txgkcl9NnY663v
Flk5YTTuRsAcUqvmWdAL8hjKblmpdTYQ8xMBxJIUy6tQ5OW/SIlKrK0Yi2YyLTm2KQcykaKz
i9v6xTfoHOY7aQiqomD1ycStvYo1GUDPYZrAa8+v0Xja5UW5d1SZyUfYRk2jS86l7VNyNEpJ
I3biI3l9DjDa5NpMwp4BTaA+pJWm1yRc66a2iRlE9FmJhx4oYRM0V5osOPuKBDQbQpRSu2h4
uo+WOZTdTDquAJcaks3EbGRCg3dGiQoXSv8AKXzaaiJCSn5eaUtB2IWlIWEpmSsqQRcKtcED
5RpHY62tmU4S7JTLbFgQ4sLSmx3ak8txCZiOqTyi0JS2KyzONqnFpU0tSlPBKk2uUptbl3jc
NN8d9blnJykTUtLqyuOoypN7W1H8rwn5wM0lU5LNBailBQl1biQcygBfW43x2P0qrMT7Uk7M
UFL7vao2sz0DU7he4tffcWiitTkvPszRpsgmY4OQnK4GQhrlKrkDRV8u42tcb4+ty+I0zZcD
qQlxxBczqQrcEg2AtZHb2G/UXi1N4frbkwthD1AU62AVJD8xcA3t9x+iMWqJWHpt6VbmcPKm
GSA40JiYzJuLjT5ICHpDdUbmCKi7tW9gjjXQPXLDNYJHPm105N8ZYi26ZJDkltS+hwZQhtS9
CClVwnoJI6QInfUriP8A/hPtZmHqVxH/APwn2sxAUyVlqyq6pV55GQFrM83kUpCB63osbzvU
RzxtVL4gE088FqupGUBLjdrguFOUEaI1Re/GNjaLarC+I0pKv+iaC/5WZiJKKiCRtaLccmea
vAaKS3V0zbvXN9hbABDezTYqN7XPzC/yrPNplW9sFSS2FzCAiYzOKYZ2pCcix2tjfUjfHXIO
pmqdKTKmwkzEu28UhxdgVJCrb+mOtcm6iTbmly52DiilKg4o63tqL6aiApzEviHgQu4rZNoC
0BacqyUqCtRvvcK0tYggRO0LhvAAakVbUkEZykqAypvfKAO2zfNa+sdU2/LScq5MTJDTLSSt
a1LXZIG/ljCnzTE9KImGmnUIXuDudCvoJhfZdM1fZ0QjTMzMrLNuuPrShLKM7l3F3SnntfoM
cVOr1Nn59+Ra2rc0wnM408HEEDn1MWp6sTnjE1M80nCIio4lpEgwH3VuOM5UrU6yHFpSFdrc
g8tjaNr1cp7T6EKJLa5YzW2C15clwBy3JN+SFSsZRMzET06+klCI2l1ynVKefkmA6ial9XGX
Q4hSfpMZ1uqytHlUvPtOOFasiG21KKlneba82sTL6xcsxnjOOqJ5O+Eam5iXXKCZuEslG0zr
WtICbXubnT54iaZiml1CbZl2nGwp/wDJ3eXxuLewvoo81t416Ilw6RjMxcQm4QsjuPLX54WR
3Hlr88VCELI7jy1+eFkdx5a/PAIQsjuPLX54WR3Hlr88AhCyO48tfnhZHceWvzwCELI7jy1+
eFkdx5a/PAIQsjuPLX54WR3Hlr88AhCyO48tfnhZHceWvzwCELI7jy1+eFkdx5a/PAIQsjuP
LX54WR3Hlr88AhCyO48tfnhZHceWvzwCELI7jy1+eFkdx5a/PAIQsjuPLX54WR3Hlr88AhCy
O48tfnhZHceWvzwCELI7jy1+eFkdx5a/PAIQsjuPLX54WR3Hlr88AhCyO48tfnhZHceWvzwC
ELI7jy1+eFkdx5a/PAIQsjuPLX54WR3Hlr88AhCyO48tfnhZHceWvzwCELI7jy1+eFkdx5a/
PAIQsjuPLX54WR3Hlr88AhCyO48tfnhZHceWvzwCELI7jy1+eFkdx5a/PAI5K17Sz3gzv4DH
XZHceWvzxyVoJ6yz1k2PBnfzlH8w85gJWrzE5Lz1QFNfEtMOlTaXynMWgSLqA5TppfTljhl6
dTae2kU1t0OL1fcdOZTqu6UreVHUncOiI3EqsQTeMKjK0WZl0ts2WUuMo4oNhfMojlMcnW/G
3fkh9mz6UW5qkqLtLrUoUx6SNN2m0USVpmwhC+MSMyLa3Fgb82lo2UdU1TZSV2IYMwy0EEOX
KN1juiE4BjbvyQ+oz6UfOAY178p/1GfTiTFxUrHJOKM9NVITc+8yvK2UIQ2kgC5B5T0RX3sF
yTtTTMuISo65nCtWbX+qbjNyZtLDcL2I2cAxr35T/qM+nDgGNe/Kf9Rn04fFO1GnDlDOeEZz
eS00uYRIzCXChZQlBQEtnXUWFrmNUw8t9LaVKUS2hSdopCUlV7akJNidN/yRW+AY178p/wBR
n04cAxr35T/qM+nFvlTSNXhav0udXUKHWlPzjiC3eZWWktJO+wTe5PTu5N8TMhR5iawkxTsR
bF2aS0UrXLmwBF8pSbCxtbX5Y0cAxr35T/qM+nDgGNe/Kf8AUZ9OLllq6wfH/pzeMtXU8wu3
h7DyUuyyWqlMpKptxSgpRVc2FxyAW0HTF0YnwdgJvbOpl8i2RZHrK0jLdJ5dCRr+6KhwDGvf
lP8AqM+nDgGNe/Kf9Rn04xpiIpvPOc8pynrKTVIOvUcShU2hwrSSpRJSLOBXIOYRaH26G9Nb
VU3NJbJUVMgaKusOb8ubRYuLHo3WEUTgGNe/Kf8AUZ9OHAMa9+U/6jPpxWFnThrCqJFMoian
kthxLhy2BUQLD83TS/0q5zHfSZLD9On3ZxM5OPvvPbd1boF1ruog8VIsLqVoNNYpPAMa9+U/
6jPpw4BjXvyn/UZ9OA9V9UlO99V9Ux99UlO99V9Ux5TwDGvflP8AqM+nDgGNe/Kf9Rn04D1G
bxHJGVdEuoLdyHIld0gnkBNjYdNjHnCaQ+iru1VFMoSZ95oMrmRNuZ1IG4X2P/thzRy8Axr3
5T/qM+nDgGNe/Kf9Rn04CblJZUrS5SULiFrYlGmVLRfKVJQEki4BtcREcAqol1S5s4xmUQ2u
bJSAVE2tl3XO6NfAMa9+U/6jPpw4BjXvyn/UZ9OJMWtuieo0xNYPcpDj6Hn3JfYl565F+fn0
5Ik5Bky8iwypLaVNtpQQ32osLadEQnAMa9+U/wCoz6cOAY178p/1GfThXO11Tp09nXXMPMVh
by333m1OSxl05NMlzfN0m9tDppEHhLAr9Kq8zP1aopnVOoW2llpBQgBVgSQTvsLdESPAMa9+
U/6jPpw4BjXvyn/UZ9ON6pqnGfiwnKM65wiMS9T1+oOMilVXgjYS2h0OoK1cQWSpJBGtrfQI
k3sKrdlBTBMqTItyCZdDqjmc2gN845tQCe6+a8bOAY178p/1GfThwDGvflP+oz6cWM5g2sLn
Kuc9XFgnBczQqvM1Ko1JM286FJQ20gobSFEXVYnfYAdETuJKSazTTKh8snMDcoCknoIO/wA8
R/AMa9+U/wCoz6cOAY178p/1GfTjGX2ipMfiwxw0RHJNNyoZpglG1lYQzskqe45OlgVX3xTc
LYIqtIr0tUJmoSroGYzWUKKnyQbHUbwdQeTkiY4BjXvyn/UZ9OHAMa9+U/6jPpxmcYl6MPky
wxnHHpKxQiu8Axr35T/qM+nDgGNe/Kf9Rn0405rFCK7wDGvflP8AqM+nDgGNe/Kf9Rn04CxQ
iu8Axr35T/qM+nDgGNe/Kf8AUZ9OAsUIrvAMa9+U/wCoz6cOAY178p/1GfTgLFCK7wDGvflP
+oz6cOAY178p/wBRn04CxQiu8Axr35T/AKjPpw4BjXvyn/UZ9OAsUIrvAMa9+U/6jPpw4BjX
vyn/AFGfTgLFCK7wDGvflP8AqM+nDgGNe/Kf9Rn04CxQiu8Axr35T/qM+nHPU/VdTJNU1Nz0
klpJSklDDSzdRCRoFX3kQFqhFE6+Yh7+a8QT54dfMQ9/NeIJ88Be4RROvmIe/mvEE+eHXzEP
fzXiCfPAXuEUTr5iHv5rxBPnjEYhrp3VOXPySaPPAX2EUtE/itaQpDq1JULgimXBEfeG4t7t
z+64C5wimcNxb3bn91w4bi3u3P7rgLnCKZw3Fvduf3XDhuLe7c/uuAucIpnDcW925/dcOG4t
7tz+64C5wimcNxb3bn91w4bi3u3P7rgLnCKZw3Fvduf3XDhuLe7c/uuAucIpnDcW925/dcOG
4t7tz+64C5wimcNxb3bn91w4bi3u3P7rgLnCKZw3Fvduf3XDhuLe7c/uuAucIpnDcW925/dc
OG4t7tz+64C5wimcNxb3bn91w4bi3u3P7rgLnHJWvaWe8Gd/AYq/DcW925/dcalVStrU/K1G
aRlVLu52jJhtVtmojluN0Bd5dam8cYlWhRSpMkSCN4NxEUzVqlN4YZmpOcqjkzxg64AopzAk
ZQMtubWJRkZsb4mSN5kiP3iIamJxNS6amQkTTCwlalguLXmuo3O4brxnOcoj6xcrFd2uj4lq
4pdamH515a5WVDiNpbinOL7xzaRVKl1X6vJ7AbVRU+oJSXS22kE9Nj90W2Vok+ulVtM1sdpN
yqWgGXDvzDlIint9Syorm5Sb9fKpVSVsqZWlBCk9qq+uoNjzXEXrByWChY0xBWKWzOy84EJe
JSlKkpJuL8oFrab46mcTYney5ZkpCk5klTaQFbt2nSI4aVhKv02RZlmW3FhpZczrUnMpRJJJ
tpyx2CiYjCQkSqQBbm5LeYfRFhGbWJcSuqsicB9dLVw2LAjn03RgjFGJ12yvOG4uLMp3adHS
PpjUjDlfQUlMqAUuF0ajtjGwUPEYKSJcXSABqOS1vwiAyGJsUm9nXTY2PrKd/wBHTGIxViYh
JEwuytQdknmvzc0axS66hWXI0FIIFipNxbL6KY+GlVtSQlTbSgE5bFadRa1j80BvXifEyCgG
ZUc6cws2nzRgzizETr5Z4blWkKJCmwLWFzydEYCl1wZRs2bJSUJGZNgDvA6I1dZKuHi6lppK
yCCoODW97n5dYDqcxRiVBP8AzRUAAoqS0LWIvzc0fGsV4icQVJnRcOBvLs03Kjfo6I09aa3s
dkUNlJFtVi+633aQl6NVmGVobYbSpSwoKDoGXQjQfIYDoVibEweU3wokpVlKktAi/wAtukfT
HxGKMTrtlfcNxcWZTu06OkfTGpNMriUpGRo2sblSSSRuJPKRugml1xNsqGha35ydbZdT9VP0
QGfqrxLtNnwhzPzbEeaM3cTYnaWtJmVHISCUtJI0vfk6D9Ec3Was7TMW2zxMhSVpylNrWtGa
6ZXVqBKWrhecELTvuT9FyYDc1ifE7i0JEyoBZAClNJA1tbk3aj6YxTinEyrZX3DcXHrSd2/m
6Y1imV0G+VokLzi60773+i4j63S6ylKkqYYWCjLYrTzAAnnsABAbE4oxOogJfcJJsBsU79ej
oP0RkMUYi2hT1wRo0HSdmDxTbovyxoNMrp3pbJuTcrTy3v8AiMYOUWrFXrTKGxsUsn10ElIt
y/NAdDuKMTNqWDMqIQbFQbTbk6OkfTGDeLcSOJKm5lahe1w0nfzbo1rpNbcaLa22lJO8Fadd
3mEYs0WsMpSENM8VedJKkkpOmo+gQHSMT4oN7POGxANmU8u7kjEYrxKW84mFlNr32Sd2vR0H
6I1GlVooKAhlKbZbJWkWFraR9XTK45nzpaOffx0jktp80B0qxHilIF313UbBOyTe97c2nzxq
VivEqG1LVMLCUGyiWk6cnNGvrZXONxGeMoqPGTvJJP3mPq6XV3JZxtxhpSnNM+0SLC4Nh84g
NicVYmUQBMOEkXA2SdR9HSPpj6nFGJ19q84dL/kU9HR0iNKKXW0ABKGQAnL26d1wf5CMmqbW
UIKSwwohICCVJ4llBWnzi/ykwGaMV4lU40gTSgp0gIzNpF7/ADRi7i3EbSQpyaUlJ0BLSdf3
RpNGrJLR2bV2TmQc6b3/APRHx+i1h5sIW0zlBB0WkXsLD92kBn6tK939/wCNPmh6tK939/40
+aOf1N1P3pv7UQ9TdT96b+1EB0erSvd/f+NPmh6tK939/wCNPmjm9TdT96b+1EffU3U/eW/t
RAdHq0r3f3/jT5oerSvd/f8AjT5o5/U3U/em/tRD1N1P3pv7UQHR6tK939/40+aHq0r3f3/j
T5o5/U3U/em/tRD1N1P3pv7UQHR6tK939/40+aHq0r3f3/jT5o5/U3U/em/tRD1N1P3pv7UQ
HR6tK939/wCNPmh6tK939/40+aOf1N1P3pv7UQ9TdT96b+1EB0erSvd/f+NPmh6tK939/wCN
Pmjn9TdT96b+1EPU3U/em/tRAdHq0r3f3/jT5oerSvd/f+NPmjn9TdT96b+1EPU3U/em/tRA
dHq0r3f3/jT5oerWvd/f+NPmjn9TdT96b+1EPU3U/em/tRAdHq1r3f3/AI0+aLJh+qVGfpCJ
uaqc0FrcWjK0lsABNudJ54qfqbqfvTf2ojrclMQt0dqnSTGxCHFOGYZn0tOG/wCbq2oW0gLD
Uq1NSLwK6jUFMolX5hzKhorOzyaJGUC5zHf0RG1HGE+xS6g8lFflJiVlFzDaZ9lhKHMpAtxL
neoc0R7sviJ9lDT9OlXQJR2WUtdR9cXnyXUTs7X4nNyxz1KnYlqEnNsvysutczLLlw45OpOz
SogkgJaTc8UbzAWet4oZoTzTNUrVTbcdbCmsrCVbZWgyIsg3XdQsneRrzxVsZ1OZmZh2ScdK
mZSoMpRdCUqOaXWo3ygDef3R04hp1Rrs2l6eoEm6Wk5WD11WgtG446cqeK5xRxhqBpe14i8R
SlQbK5ypsMMLnKi0pKGndoAEsLTvsObmgM6yqpVbqkyVAYxVU6KwrD7D7Dcq/lDj1t1uXS5N
tTlikdUBzqg4PrzEm9iutOyk0sJYmi+tNySAQRfQi8WvqidTqrYnxDS6zSqlKyapenSzaNpn
zBSU3uLA84iNr3U1xlWwgT+IKUciw4Nm2tHGG4myeTW3yx7/AIsoxyxnVGmucTH9OTM9EHUp
jH7VZnKdS8X1SeXJzBlnFqnUthTpUsIQmzirqVs12BsdNY6dh1RlmZ4NjCouhDLS5YcLUFTS
1lgZEpKrixmEgqOmkdMv1JsYS8zNTDGKJZt6cUVzDiVu3dUSTmJy77qVrv1PPG5PUyxylhTK
cXtJbWUkgOvDVOTL+bybNH1E80evd+HzH4ZqUCt/qoIPGxHPAFaUJUaoBmKkKXoCb6JQq+l9
LbyL16dx9jeTnHpZ/E9XDrKy2sCcUQCDY63i+K6lWM1OBasUyhIWHALuWzBJSDbLbtSR8hMc
E31D8QTky7Mzdcp777yitx1wuqUtRNySSnUmN4/Pw/8AymPwlSpvZHxn8aKx42uHZHxn8aKx
42uLb2Bq18L0z6HPRh2Bq18L0z6HPRje/wAJ6/BWSpdkfGfxorHja4dkfGfxorHja4tvYHrP
wvTPoc9GHYHrPwvTPoc9GG/wnr8FZKl2R8Z/GiseNrh2R8Z/GiseNri29gatfC9M+hz0Ydga
tfC9M+hz0Yb/AAnr8FZKl2R8Z/GiseNrh2R8Z/GiseNri29gatfC9M+hz0YdgatfC9M+hz0Y
b/CevwVkqXZHxn8aKx42uHZHxn8aKx42uLb2Bq18L0z6HPRh2B6z8L0z6HPRhv8ACevwVkqX
ZHxn8aKx42uHZHxn8aKx42uLb2B6z8L0z6HPRh2Bq18L0z6HPRhv8J6/BWSpdkfGfxorHja4
/SztDabWpIqGIlBOmbrzMeePFuwPWvhemfQ56MX6bouNZqrpqbr2GOEpIKSlU4Ei27iBeU/O
I8XGfJ8eVbUx/RrGJ7u99qabWW5Nyuz7y5uYbSheIn2Ettthvl1ubrji2k29ifDsouer0m3N
rn0TkuK289cstkpsvTS4voBzRi5RscOdvM4ZzbZx4LQJpBBXlzC6VDTiDSNAw5jVNUp0+ibw
ylynmYLSckyoKLySlZUSSSdSd++PHjOV85aSDNTkpupVKly0xilE9TmnVzGesvZWrD1s3z8b
PvFtw7axiuYenJmoMtzc8+5MTD1JaW464rMpajLr1JiYFBxgkqLSMGNLIdG0blXwobX8ob33
qOp6QIjadTHKLMrpj7iHHJSmtsqWi+VREuvUXjOUzp5yPS5b3d4j8D/mmNcwgrbskX1BIva4
vqI2S3u7xH4H/NMbpMsCZHCiAjXfexPMba2+SOSuemofRLTYdN0BCANb/nD/AHiB6o+JJ7Dh
lXKfS3KkX0OhTbSSVJKWQpB0/NzWzdFyN0WpyYQ5wpDI2EplCsouoAhQAJJA1tfQaWjmfmGl
OkodTawF8wF7ACAqcvjdBWlp6lTgWHGGVrFgkqcAuoA6hIO6+8RgrqgyiW5dRpc/d4K4oA4l
lKTxjutxCSRe3LyXtm3T78n68YuqZebU28ptxCu2Ssgg/KDAQWFMWsYjfWiXkJqXSloOBx0p
KVdrusdRxtDuNjzRYLCMG1sttpbbU2hCRZKUkAJHMByR92rfviPrCAj6dMqlapW1ha0pDrBs
lVrnYpjv67DW8y6kAgZio2N//wBRzSMs03Pz7777QTMONqbA41srYSb/ADgx1lmnne619mPP
AYmqkKIU++ki2/NrpePhq6QFETTpygk2KozDUgABtm7DdxB54BqQF/Xm9d/rY88BsROOuJJS
+7obG6iIjJaqKp9JqM2866UtT8wLBdirjJCUgnpNh8sSKRJoBCJlCb66I/3jnlJWTaZebfmW
nQucdmU3buBmII3neLQHMcXU8WvUnACM2YheW1gSb2tYAi53C8YPYwkmW3luTU0kNKCCClYJ
UU5soB5d2+28c4jsFOowFgmVtZQtsRuUbqG/lI1jDrTQ8qRspSyTcDYjf9MBpbxZJKKEmfdS
pd7aOEaGxN7bgdCeQ6b4kZafXMyyH2X3i24nMkkqBt8h1jlbplFbKihEqnMLGzI1GnT0COhl
uRYZS0w+222gWShKLAD6YCPZqjlPplTmlKdc2dSdTlCyCQdkAL811E/OY+JxdJJQ1wmeXLuO
ozhtalGwuRv+b9401jrlJaUaamUPTTbgenFzIGTdfJYb94KL/RDrdRi9tSmW2m7NsRfffn54
DTN4okpRpDj1QUlC0pWCVK1Qdyt27+em+M5DEkpPvpZlKgpx1QKgi6gbDfod0bXZOlPISh0y
60pSEJCmgbJG4DXdH1iVpjCgphbLagLApbANrAb78yU/QIDp4Q97879cxF0h1bk1VdotS8s8
oJzG9hs2zb6ST88SOaV77T9X/eOWny0vKvTq1TqFCZmS8kBHagoQmx1/qwHTCMs0r30n6v8A
vDNK99J+r/vAYwjLNK99J+r/ALwzSvfSfq/7wGMIyzSvfSfq/wC8M0r30n6v+8BjCMs0r30n
6v8AvDNK99J+r/vARRnMs4tKHws5kgJue6AIt9MaakK0KohUmUGX2jYCdycllZ8/Le9t3Rbl
ibzy3fY+r/vDNK99J+r/ALwEJiI1gOK60AlPBHOb8rmTltfltfoteOyoOFEiOEr2SjbMWtbn
TQX5Dr9Ed+aV76T9X/eGeVG6bH1f94CNpZcmZLZtrccCXQhKlHKop0JufnI+aJIywYYuQQtS
+VzNpb5TAqlTvmwf7P8AvHzNK99J+r/vARMk3Pioo2i07BIUScyyVi1hoRYG+sSsZZpXvtP1
f94ZpXvpP1f94DGEZZpXvpP1f94ZpXvpP1f94DGEZZpXvpP1f94ZpXvpP1f94DGEZZpXvpP1
f94ZpXvpP1f94DGEZZpXvpP1f94ZpXvpP1f94DGEZZpXvpP1f94ZpXvpP1f94DGEZZpXvpP1
f94ZpXvpP1f94DGEZZpXvpP1f94ZpXvpP1f94DGKz1RPYFP8NH8NyLRmle+k/V/3isdUYtGQ
p2ydDn/Oi9ha3rbnTAWNr2HKeCs/w0xX5ulVBibXMSkyxLhx1Wd3aFBUlRWoFdxrlJSANbgb
wIsDXsSU8FZ/hpjlxDMUJyicGflHJl5TYQpD7Ktmp2351xlVrz3EYzz0VcfhYi0dRpapNzaF
TdcbnADq0lSbEWVfQDnKCOYAiJ0b9d0fK1RMK02Wpb9Ap1FlZxcykLVJNtpWQW13HF5Icmm+
Ok1fJFdnaHV3UPpaqTaRMu7ZQspIQrNpz5gAEjLxQbcnLJ0WWm5OWLc0pDilvOOKXtVLPGVf
eUi8ddUqFPap2SQZnHJwNZb7JYGe286AHXlMR06/VU1+SalmmzKLQpTy1ZrC1tN1s2ptGPiy
3L7V5TOdNd0rEA7QZ5uZmH6fUBLuTDqlrISAbFwqAvl5iN991hYGJ5y+zVlvextaOeq1KWDz
jdMl5gglCWl7NabajMVAgDUX+iJnnpmOTURaHdpWITsUN1uyRbaKPbK0Gb83ugbbrAka8nbR
5Gqy044uo1LhTJRlQ3a2U3Gu7fv1vrfdpBtdYNdImG2G6YGuMpCypZObksN9r3+bljpnKi2u
eW3Iy7wbVMJDa9ktKQ3y3BAA0tF+SdGUR1vwzhOqLqnak2UDzG8Vk4fqaJIMSs81KhV0upav
Z0WUMxunec2o6BrpFkOUW2hUEXGbLvy3F7W6LxrqlQklzDTdIYmuM6My1tLSkI5dCABGcs9M
xFdWohXmaPXGXWw5XxtSUpy3AzIBJsBl6d1joLXsdLMd55I8jxtJy5qFddLKStM2AFkm4BAv
Y8m+PWWkhDKEgWASAPktGsctVuHxfLuTlFdJRlVoq52fM43MKZcQylDKk2BSsKUSb2JtZW4E
X5bxzKpNcVLKR179cKioKU2FAagp0tu7bTX83XSOyoUjB5oU7UJpuSNfBeyqL6g6FBZycXNv
ta2nNGiqGsrnXAESqabwd3aKzlS1acWwtorl5rX6I6aYnpLc5VMRTOmU6sS8y0udqqn2U9u2
UAlXFP51hfWx3RLxX6nh7B0nL1CZo7dGQ+26rgxQ+4p3QpsU8ex1vbSLAd5iTp7NkIQiBCEI
BFHrfuvqngqf4C4vEUet+6+qeCp/gLgLsyrJjfEyu5kifoKYj5Kbq81Jy803IU9CX2kOpSqo
KCgFJChezW+xEd492WKPAFfyjnoMtWXaBTVs4eqDjfAmAlYdYAUA2kXF3L8kB101yoGXmuGt
SzSQlBSWZpTpvmHIUJt8sR1YxAadNy8shqamXXSFLDd7NN7iondfkCd513AXiYYl6izKTJn6
XNSKSEBKnltKCjmGgyLV++IWrYhkaRNNS06qZS48grbDbC1hQG+xAtcaab7awEo3MKcbStDq
ylQuDcx9DrmRHri9UJPbHuRGph0PsodSlxIWLgOJKVD5QdRH1SsrKVczaTv/AKogMJiamG3k
BBWUWurUnltzxo67uEA5XRYgquu5AjbwlEu2+qemJVKWV5StlwqSbgEWvY31I+aM6O/K1mZd
Zk3toGiM6shPJfQcvyb4Dah5xSASpYJF7FR0jGYmHkMLUhaypKSQLnfGybQ2zNllp1L6QDdx
IsLgi4HPv3/NGclLmafDYVl0JJtew+Tl+SA4lVB5tWRSXlKA1KT/AC/93GMTVHAsJyP3IJ7b
daOyaDTM0ppD6HG0pJL25NwRf79+6OKVqDM4XkyjiVFpYQSslKbndrzQHTLTLrrCVqWoE33K
Nt8Zh1zZpO0XqD+ce6MaZZxTjZK1MrUlaklTKsyTYkXBMbEDMhsDebjylQGMxMutpTZ0pBVY
qJJA0MaFVVSVEEO6C54/J8n3xI1KWRIpQA+HHVEZmwkgoBIFyfn05+SOJMzLuT5k9oNqlIUu
6SQkX57ckBuQ84pIJUsEi9io6R92rnvi/rGNtXVIyc6JNhbjj9wlRuMidL795NrcwjCVYMw+
lpJte5vv3dHL8kByPzsw2/lSlxSOLxgT03/laPiqm6EBWR4/IvT6fpjrnUtS00GUTCHUgKzO
9qlJABI1+X5t2+MMPvytXqCmG3rJbWUKUbgE2vYG0BltXPfF/WMEuuZL7RfbkdseZMYOTMm7
NKakFOrSgXK12F9eQb7dJ3x9T+T/ALavuTAa5qaebKMjiuNfQkm+mg+eNCqo8FkJbeI1A43L
/wC8kSctKbZlbq5hmXbTfjOqsDYXMRNYnHpaSLkrkCg8G7uAkW57D5oDrlZx18KvtEZTbVW+
Nu1c98X9YxDUSenJioTUtNuMupYQkhSEFJJJPzW0iXgMJmYmEpSGVqKlKtqeg9MaRUX72yO3
ukE5jbX/APRiQn5YSMrtXX2lL19YSePpqdOYDW8Yya5BUw8xPzamFpbzNhIvmNyOY80BjtXP
fF/WMfEuuWX64vQp/OPMY52Jlp5xbba7rb3ixGh3HXkMbk7nPlT9yoDCamXW2wUulN1AEkk2
EaFVV1CsqkO5u5z2I3fu6Y7pRLa5hCXnEtoO9RVlHyX5I7HKUXVJVIp9cU3cNkg5+5AXoOfT
X90BGS8466tY46QnddR11PmjbtXPfF/WMYq0cWi4JbOVVjcX6DyxukGkvzzDTgJQtwJVY20J
gND8w623nSpagDqATe0c4qT4UULbfKk6EpOl+joibnZaUTJF1pIaIUAVFwkWsb/dENT6nTpy
qy0kzMF1by7WSk7gRfX5IDobfcUhKsyxcXsVHSPqXXMyvXF9p3R7oRvLLuxeW9Iol0pICFpe
KyTm3WvzXjmT2y/0B+IQGW1c98X9YxycPmEHjh1QJVbKbWAPyx0jfGmWWZwyvA5hpbrzxZXK
kgLB11HLpbU7tRAZys268hSipQsogDMd2kbdq574v6xj46C3MOMrIzt2CrG4Hz/MY+QHyYmH
UMqUlw3HOoxpFRczlAS+ogA3BI39ESMpJodl3H3phLDaL8ZSSR+7d/PdETPza2ghLS22SqYD
Jcf7VAIvmI5BbeIDqlppx9kOXcRfkKo2B1zOPXF9qr8480R8rMqNUelDPyU8lDKXNrKpIAJU
RY3J10juH5Qfoq+6A1TE1Mod9bKlISnMrXfrGpVVWFKGV0kC9gvX/wB5+aO6XZU+8G0EAm5J
PIBqTHybbTLzWxS82+QCVLaNwm1ja/PY3gOI1R4G5besd3G1jpZmXHUZsy06kWKjyRBMYobc
m2U7G0u/MmWbcCrkqA325r2ET0BjMPvpQnZLUVKWE777/njlTVHwVZ23VcYhJCiLgRKTEqli
RD7j6Q4oXQzY3XpfQ7vl5uWI1+pSzDks2t31yYKQlCdSLi4vAdaX1nc6o/2jH3aue+L+sYhq
hXJSSfbbcmn1vLItLoYuq+YDJa2+1yDeJZJuASCOg8kBntXPfF/WMVnqjKUqRp2ZRP8Azo3n
/wDG5Fkis9UT2BT/AA0fw3ICw09mp1J9EpSpWVd4PISrji35ktduggAAIVftD9MdT+HsSBhZ
dp1JWgJJKTPqN7f/ANUdvU39u579lU/7nYuM77De/Vq+4wHnaMN11tjhLdIoqLIz3TOkG1r+
8xtVRMSpli+ZCl5QjPbrgq9rX96i8n2lPg/+WDvtKrwc/hgKG7SsRtJaK5CmeukBP/UFbzuv
61pGiUlqzNcK2UtSrSigl4mfXYEi+h2Vj83LpF2mqS3NybKJipTbYyi3Gb101FlJIMfKRRWq
TKznWiY2z7xBzPlJSlQTZIsgCwt0Q7JzU1ElWVlAS1R+OCReoOC1r77s6bjobbjzR9TJVpQQ
Us0fjqyp/wCoOA303jY6bxvtvHOItiqA880W3XW0JeA25TdRzAqIIJAvfNc33cnRtXSJx0XW
8wlS3kurKQq6CkJSkpPLoncoWuejXF5eGLy8Kk9Sq+w8lp6WpCFr3A1Bf7zsbD598JWk4gmw
oy0tSHMpsq1QWLc29nlGoPLFwm6M68pSOEqW28lCXVu6rAQsqFrADebaxnSaU5JSLkuXy2DY
I2JIyWFrjNfU2uf/AExbm1vK+iomgYmCgngNKudR/wBQX/8ATDrDiW9uBUnfbWor3/ZRbKpI
zMxPyjkvY8FQVZ3TotWZOhtruBN7c3PpxM4YWJUofdYcc2TiUL2Z4ilBsZhfdbIenWEzPgnK
e0KdP4UnDOjh1Hw6qYeIUS5NqJURuJOxtyaX5o6EyVZKEZWaNZRypHD3B+7Y6DUanTUc4i81
eRmZ91LWZkSZQcwJObMQQDusbXuBz68gjkXQph1bjjjzQXMI2ToSDZKLJF0854nLpr0ayZnt
Cc4nlCrS9Hr80pYZlKQ4UGyv+oL0+lnUdO7SN3qexP3hSv7wX/8AVFypck/LTEy8+tsl4gkN
hViR+dqTbSwsNBbpjvjUNxdc3n3qcxN8H0n+8Ff/AEw9T2J+8KV/eC//AKo9BhFV596nsT94
Ur+8F/8A1RrmaLiOWZU6/J0pCE7zw9Z6NwZvHosc1TlROSa2VNsu3IUEPJJSSDcXt8n/AO4S
k9FARS6+t1DYlqQHHEFxKFVBaVFIIBNizcbxvjE06uh1xoS1JU42kqUkVBe4b9djY2uL80Xi
Xpi2lSy1LQ4plpxCgoGysxBAvzC1teSOeph6WE7OzoQphtlSWQyla1pBtcZQDck83MOmM3KX
KgTT9UlpV2YXK00oabU4QmeXcgC5t6z0RVqwoLxXUVjcuRbWOjNLKP8AOO9cpsJirzqJrE00
5Pyy2+CPSTpZQcpCQhIaGW17b9b63iPqyFN4nnULSUqTTmUqB3giUIIjTS7f0xxT+z1fyi7Y
J9xtG8AY/hpik/0xxT+z1fyi74J9xtG8AY/hpgMMY+1BsPzxy25YpUxKtzIbExLtO7JwOozq
QcqxuUNdDF1xj7UH9NP3xT4BZXcj7RPnjW+wX5csrBCSgJJS6kHQAaG/RGyEBHU6gyVPEwGG
VLEyUlwPTCXL5b2tc6b4kEoUjVCMnGKrodCbk7zcGPsQUzTJnhVUnmAgTBuZU7BBXfYpAKVn
Uca+m76YCcynPnKbqtbMp4KNvnVABYIIBBG4peCT9IVEHPN1dDjjUo9Nq1AS4SkjZ2GtyPym
bNydrHTS259qaWJt2ZcaIVlKyk2IcWE7huKAgnnOu+Ak8iivMU5lEZbqeCjbfbVUaZySRMy6
mXUFCFnMrZupQSflvGivy7s3SXmGEha1lACVC4IzpJuLi4sDcXiIfYq8k1s5BtSFB5S7SrYD
WhSEgJJ0SU3JubXzb9ICZpFJYpMutiSbcCXHC4raPhZKiAN5PQI68qtmElI3EflE85PP0xXJ
WlzrdDqKCHxMvNNIaClBVsqEjT+1m5eeM55iutVN5cq8XkOKR66Gwi5A0ukHtbk33ckBYFha
7bTMuxBGeYzajdvVHxLeVa1pbSFLtmO0TxrbuXpMV19qvplVrZfm1PFF0oJRYKJdB0tyANW+
W+tzGyYarbKliXemXm9osEuEFQbCkZSmwvmIK/8A0CAkJekZJ4zb7rj7oWpTd3UpCQdNwOpt
yn6I77LuLCxGoKXgkj5wYr77dZeknG3kvLmSlsgIypZIBQTc7wrMFXtyRulDWzV2+En1i/H0
4pFjmtzca2Xly/PATOzJXnKSpQBAK381gd+9XRGLjS1MuIas0pYJzpWi4UeXfEdPNTjMw9MK
mFKaNg2UqKSwCUgjLYhVxfjHUc0ckxPOLm8iX3SylWhIPIRlINt9r/zjOWUQxlnGKTpdKEhm
WCt15aQla1Opsbcyb2EdoCwmxSO2J/KJ5h09EVR+alkNBqYdVmQhCW+KFFIsMxIULW3nTeb8
wjpZnFoZdclZpRK3Ds0rJKQjJxeTU6AXvGdyGY+WFiCnkpUlDjqEqtdKJgAG3ReOWfkTNShZ
BykuBwqU4lRKr3N+NEY3OurUnaTjqE3SOKCDluq5N03vbLHxqffKAtc25ntcotxb5kWFrbrF
f/touuF3Id9Opi5OcmZhS0rU+EjKFJATa/8AWPPHfZfcj7RPniCYqL2UcImF2za7NJzZrclx
2l4wM++2zlQ8AM6iMoUTYqURyb75ei3zw3IN2E+6l19vZvOPOIsE5VTIItzb90aX5QvO7Qqc
Sf6jqBEZU58Oy4Ql5w3RZWxSRddxvuO1tePja52oNuIbfAeSsFLgWpAaOtyBbjJ3cXdFjKLp
YziZpKy8olha1pSVOOWClrdSSQNw3xuAWArijUg/lE8l+npjFsKS2kOLzqAAUq1sx5TbkjKN
Nvlldyn66fPGbbkw02pttZCFpylKloWPmzE238loxhAYobUjNYA3I0zoAAAsAANANI2sOOMP
odQlOZCgoXWm1/pjCEBuemHHbgtoSCb2StI/nHPKNiTcQuXZabLdstlIFhe9t+6+sZQgOiYm
3X75m203NyEqSP5xzgLBUco1Tb8onnB54QgMH2lPNKbOZAVoSh1INvlvGUuFyoIlUNMgpyEA
NnTk3x9hAYNtKQpRsDcAWCkJAAvuAPSYzsvuR9onzwhAYlK9bFxN94RMZQfoVGp6SS62ElJS
Q4HQsPJzBYNwq5J10jfCA5paQDEyuYKnXXltoaK3X0qORN7Df0mOgBeYHKNxH5RPKPlj7CAJ
LqFhSCUKSbhSHkpI+cGCgtTgWvMtQBAKnwbXIJ5eiEIDgboso3NNvpZPrS1OtNl8bNtau2UE
3sCeeO+y+5H2ifPCEBgporQUK2hQQRl4SbWO8WzWj6G7ZbNo4na8dGmltNeaMoQHK5T0OVRm
eKU7VppTYGZGtzvve9xu+eOqy+5H2ifPCEBmlh9QulhageUEH+cVfqjBSZSQQsZVpnUkpKgS
LtuWuBuicxVMYgYlpD1OSkvMrKUF4TMwppIbubhNgeMefcOmKjjYrNSdLgUFGblLhRuR6w9A
ek9Tf27nv2VT/udi4zvsN79Wr7jFO6m/t3Pfsqn/AHOxcZ32G9+rV9xgNJ9pT4P/AJYO+0qv
Bz+GB9pT4P8A5YO+0qvBz+GAj52VqszKSxlxJBbdlAlxaSNN4OU/RbXdHHSqPM0mQqz1SbVO
qmSlZZlVqW45ZNiLkJuT82mm6Ouo1B9uUlly8rPnLa4Syog6biE6/PyfujkoU7UTJVaZq77k
i0lSVNuzLZShpOXjEBdjYdPLr0Reyd0Wmk1LYp4DLzDLy0ZpZZBbTK8ZwuIF9UDjJA57Dm03
mnzeRrglNmm0pm0OyqFABLYSEZkqGa7eZQWcwBuM3dWOKsQ1SXaK0zCX1NpCmWlNpzTCFKc1
VlHbJCU3CbAa36Ny6/NNZQmpNPhqaQLhLed9opbKyABxrFZSAixvluTYgxXVUJOpTFVYcmZY
LdOxDTjBJbZCXSXrk2IzN2G7XdHZQac5TqXMqkpRiWmJh9boZWMqEi+VAOW9uIlO7lvzxx1O
uzKZwKZLkqlCWSiXfZGZ4rdUhenbHKkBQy8+ukbcL1qZmqZMvzm0mVNFBCWUBSjmSDYZbA6n
dvA33OsB9rs7PS9YpyZYKcKGlOTbUugLVkzIGgOtr3+Wx5og1S2KJgS01wZwTiC4pIdKUpBL
beXOEmx4wUOXdE9irEZosqw6hhKy4hTqkOryEITa410B4w3n5jHOzi4cLS3MMsstrUo7RTtt
kAlziruNF3b3cx6NQwwuzVTWlTFUM6ULlMjefRNg4TxtAc+u+w0+SI1VPffQ87K0ueYadLmS
WWgpUh7KkNOm51VcKJXfTTlBMStDrr0/hiZqNQnpSSSHlWebsrZN3Fgb6ZrGw0N7jQ7ojXsR
VWVlc6n23H2wEbEoSc6S0V7U5eUEAHKct7j5AO0uf4PNNzMpNqK0LRMOIQHdo4VkocylQ2gS
mw6LjTTS4UtLyKbLJmUZHg0kOJz57KsLjNy/LFabrs0mel2RPtvIRObFRs3meaJAC7AXVxjl
uiwFiTe1otw3QCEIQCEIQFZnJOdOMEzKWn9iE/lEciMhBsrk4xHrdtTZV9NMJeUm2qrNvOsu
oFn9s8o6OhS0lkDnypCh/V3csSk7NTbWIZVhDrKZZ2WeUUKTqVpKLEq5ALnQc8RrNUmZipTM
u68lSFCYCmQkeshtaUoOmvGBJ136WtAZEm2+PKcU+7us+DJ/w649WO6PKcU+7us+DJ/w64C3
f0xxT+z1fyi74J9xtG8AY/hpikf0xxT+z1fyi74J9xtG8AY/hpgMMY+1B/TH3xT4uGMfag/p
j74p8AhCNU06WJV55LZcLbalhAUElRAJtc6C+650gNsIquHcZLnV7CqyQlZpSrBprPmRZlTp
C0rSlQsEKAUAUq5DvtoHVBYVKTb/AAGZbQnMZR1aPW3rNNu5SQbheVZJG7TfeAsNYaccdktn
NTTAXMoaXsHMoKSFXvoeYaxrpNRem3VIdDaLAEgA3bVdQ2arnt7AKvzHdyxHIx1SnnZlmSZn
5t9mZ4Khlli6n13X2lyAQNmu9yO16RfuoVddqrk2nrZOMIlp1UqFLCdwQFZlC9xvAI3glPTY
JGdcW1LKW0Eld0gZgSNVAcnyxwdcJlKwFtoWcq1AIBG7OLcvc3+f54+4uqPWnDU9P8HbmTLt
hQadvlVxgNbAnlvoOSKzLY0pUvJLfrNNYQOGKlWnJOWUpLuVILhyLSlacl7KBF72sDGZib5M
ZRMzyWczj4eUttxl5pKEdok2cJWU3Trpp8u6FPn3ZmYRtkhtGVVwCLE8TTedRcjf8wjmxE+z
S6DOT7VKly6wtKG0PoCUuXcSgKum5ynNfn03RGnEVOTiuoUU02VeXJS6l2l8inXHEJSpxAQb
G1lixNrkKHJErJNOXlKMVd4FpK0pWA2FO6cewCSo2+c8nJpeM+uzyJpLTyGUi4DmvaapuTru
so6kAacsRDeKKQ86yZakuzCJpptcm21Kp2syVuOJTlBIGUhtSgSRoPkjS7jXDyEFxmkzkwyG
tqHWZNGUjYh4jUg3DdydNLEbyLzTl5TTn5Tb1WcIStCmkpCzZNjd1Iz6jo4ov9+6NSp6ZbWp
TcxtXUtlZYUdb3tltu3XOlrac+vFiPEtEpklMKkJNiqTbTDzpl5VtC9mG05lF3uALpB5ddxs
Y55fEWFOGTSBKKTwJ5LTrimfWUFSshULm1kr4p0vqCARrCccvJOOflPmqOLedMsWVtNICyoA
nN2twCD/AFjz7o2Ss/MrKEqZWriBZKT+aQLbyNb5r/JFamsZ0PK61JU0rnG5dp/ZPS4QkZ9m
cilC9lBLgVzclzrHScUUNbgbl6POPuOupblUIk0ZpsKWtAW3ci6czahrY7ja2sWslrLymVTj
z8whrIwSpyxzoKtl22h13kJB5N8aperzIZs6nVLYJUo63snjHXcSTvsNN/NCrxthYEhEq44E
yfCzkkxonKVZDzLygm27S17x3yk6l2qTcs/RWJZDUgmdbS6hId1UtJSsC4GqLixOhF9dIVl5
NOXl2sVWbdZLoDNkqCLa8YnNre+7ijn3743KnHnqchbT4S4p1KSpI5M4BtYn6QTFOouOJN6R
fnKtSZRDDTDDmaUZXdLjp4jJS6lJKiDcKF02B13RbZF2mTkgJ9EkhEophL6XnWAkKQUlR03g
pA1BA+eFZEY5eXdIOvOyjTr6k53EhZCAQBcXtqY35jzn6YrHqxp8nTmZg0qqS7TyFzCUcEAI
l0pQpT5AV2gC0/1tbW0jMY2pwfcQ7LT7TSFrQJhxpIbUEPJZWoHNfKlS0kkgaXte1o3DpHRZ
Mx5z9MfCSd5JiqudUSiNqKVJncwkzOEBi9kZSsDf2xQkqHJYjW5tGLuNyzMTYm6ROybMq+00
pUwE5lBbK3TYJUbKsjQHkOtjpAWyEVdzHkg3LrWunVYOtpU4qW4OkuBpLQdLhGa2UIUk7762
tEhVMSSlOnKbLOsTbiqjbZKbbBSm5SBmJI14w0Fza+kBMQirMdUGjzMguclWag+yiYTLgty9
8ylA7O2uoWRlHTa9rxsfxxIS4m9rJVRPBi6EkS4IfLToacyEHXKpSbk2FjfkMBZYRBu4lSWK
G/KyMy81V39mNUgspyLWVHWx7Q7idLnXQHZQcRMV9t4U5mYadS0h5kTbeQPNuBWycFr8RRSe
nTdATEIpDfVDUZWVnXpBpqSXPpkX17fMppSUFTyxYWKUmwHKoXOmkSOCsVvYkmnm1SIl0ttK
dBCyo2DqkC+nMAfngLNCEIBCEIBCEIBCEIBCEIBCEIBCEIBCEIBCEIDVP0ilurbdfpso8642
FLW4gkqOvT0RSMWS8vKzrrUpLtS7YnJU5GhYXLD0XmcmZsqbSxR6o+hDYTtGm28qt+66wba8
0UzGbE2l4TM1JTEml+dYDaXwkKVlZeBNkk6XIgPSOpv7dz37Kp/3OxcZ32G9+rV9xindTf27
nv2VT/udi4zvsN79Wr7jAaT7Snwf/LB32lV4OfwwPtKfB/8ALB32lV4OfwwHLNVZmUlpYodY
UFABQzAm1t4F/wD35Y5qHW1VtNRbMm2tMutKUNqIusKTfjA3A/fp06R1zKKeiUl0zkow4heU
DO2gpBtpe+7fb5455Cao85JT8vIp4Oy0cjypZOS5I3pKN/NccsOySwarLEu2FmQbbRL3SotE
HLmUocTQXBKNTpyb429ckMpaQuntIDcwls5VDK2pQBBTxd9lXO7l1Ol8GxRVbILccUAnKoPZ
gNCoAOXAAI4wANuW0fUoo6kthTkwc7mVQWXLrJygBwHk7QDN0c8c7ny53l5dE5U2ETKVtsom
EshJLqFAlOdRQMmmpuNdR88faPVJaZYeISywGiFLyrBSMwzanSx11HPzx9nGKa3Ny6Xylpxw
2Q2klKV5br1A001NzuMKO1TzLOJlCXUqI2heuVK00vm1ItuPLvi87a531bZ6ak0vSzT7YeU6
rM1ZAXbcM37xu544uvVIeSQEB1Lis6srOYEAX2h6LC9zrpHdUJOVmAwmaOVKVjIjPlCjyC3L
uiPepVKbmZdvhBau4toNJctnJTfJpyBIOkJ1diZy7PiK5SnGVomWUtBallSFtg5glRSFEct8
ht8kfevchLlGwkng4ClpKAxkUASm6Rp/WSbdPy2yRTqM5MBpK0qW4hSkpDt8yVFW7nAJXYDd
cxudptMmlpssbQrK0KbfIVmGW5FjyZE/+mH2T711a+vFLbCcjSglmyWyGcoSojtEk2sq17gc
xjqnKjs5BE5KNomGVJC8xcygpNrW0Nyb6D94jjmGaOyHJRzOgghzNZR44AGirWKrHcNTcxlM
OUuZEs1wl5kM6oCFLQEEAiytNDobA66GFz5Lny+orinXkMtSoLjxOxCnbBQBVfMbcU8U6a8k
bpCrCcm0NBkoQ5Lh9ClK1INt4tbl5CdxvbS+uVp9OmkLdltsghZAOZSFtHW4ANinedOmOqWp
krLPh1pCgUpyoSVkpQLWOUHdoBu5oRqWNTrjTOvKl5Vx1CAsoTexNh8pNjp8gJ6DG6OeopYM
k4ZpxTTSBnU4lZQU21vcc1o1LU9EfL1tE1My7RlfyzIX2wKhdN7Wta2lt978nLGyafSp+dYE
ts1JZQsu6euAlQtprpbl541SyKPwlksOKClJzoN1BJUU3CiTpnyknXW1zG+cXKKdm0tLCppD
CA4ASbJuop6N+b/20SL8s4zPeUYd0eU4p93dZ8GT/h1x6sd0eU4p93dZ8GT/AIdcabW8C+Ms
Ugcsgr+UTODMWyCcIUdIanFASLIuGdDZAHPEM37tMT+An+URODHEIwhSErJChJNXBSe5HRAX
itVuXqlOcbl25hBQUqJcbyjeBzxARk3MMtyE4644lDbaEla18UJGbeSYjev1H+Faf4yjzwEh
EfO1Btt2Yl3pRx1hpsKmHOKUJSoHekm5Fgb2B0h1+o/wrT/GUeeOGZm6O/MvOGvSiWphCUPM
h9qywkEWvvFwSDYwHG7R8HMIbppkJYoW+OKNpxSEKAJVe+QJCk78ouRprH2cwthmZpzzsuyi
TS6lLDj7KTny8VOQBQNiQlCdBmta2+Pi5XDrkwt1dcljnzJUnhDXGSrNmSTvNwsi97jS0dUu
9QGKa7Joq9Ps6rOtZda1OmuXduSOSAT1Ows5LzSZuXkw1MKE09cKSM175gR2puomybHjE21M
bqU1QxUHm6awG3UKbeXkStKc+VTY03AgJIII5r66jgEthsOZzWZVSsqbqMy2VFQAGa+/ckC2
6O6WnaNL1CZmm65KXmVZ3GzMNkXzKOnL+cYDvrKJVymOoqLO2lVZQ4g7rZhqegGx+aIqaYw/
Pz0w9NySFvmdG1cXcZnEoI2m/tcqVJJ5ctje0dz9Zor7DjLlUp5Q4kpUOEo3EW54j1IwytpL
blTk1JTKGUIM2jjJO8nXtt+vSYDZXhSpyjOyS5l1lM+8k3ZBLgcLqNbKBCeMBoQBvsI3Vek0
tFPXwilibGd19zIAlRUtKtqsquO2BVfXW9hHG0mgNBIarkq3daVvZH2htsq84uOTXmtpHTO1
CmTkk2w7iCRQoEF1TbrVnbchSq4y31t0c0Bol6PhyoZ5VNJb2LqVFCiClKwhwqVlsboyrWe5
7Y20jc7SsPJmHZJ2QlmyGCspsUpKC0ppVrHkbSUnotCVmaCxVHZ81iRcfdBTdT7QsCQSLixO
qRv3RzudZXAVHEbW22Za2xmGSrZlJTl103KPGOsB1Tchh3EiUy0zLyk6Gc1klKhYdqqxFrjk
IueS/JHJMS9DKajLTFFUDOJzTbJA9dbAzFZ41huuQLKJ5CdY65GcoUmWS3WJNWxQ42kKmkbl
rCzy84jmCqMW1B3EUu6tRXmdLzIUpKxZaTbTUAC+8WFrQGFScw8XXpuapyVrmgloOEhAmEpW
BfVQAylI1NjZI3iPlWwzh4yrbr1M2QmZxl91EuNVrKjYKINkpzOFRyka6jWOlp+isKKpavyz
KkgpZKZlo7IFWYgX7YE91eN3DqCKe1JJq0kllrZ5f+aQTxFBQ5edIgNDVJw8+/NMKpTLWwl0
yjl02SWbEBJCTpoDvAVlPMY52KjT3KgqsLMy6qpS6ZVuXK2iNmk5jaxvclzVJJOugjuYn6O1
MuPmuyri1jLdcy3om5OW4tfU7zqBYRzOqoTylrer0utx1JbdcMy1dbZABQeQaAajXpgNtTpl
FTsG5ikl1kMtyQcSCA22lXraN4UbKGmUEjeLXjrpD9PclHZiXaSw0lCW151DIEJTxRvKbWVq
PmOsc03PUmZmmnXK/KZGwobEPtZTe4JvvBsbAg6DpN4ykJ6hybK2xV5F0OWzZ32wCAkJAsLD
cBya7zAR/WjCRlJZpilSz8oSmaSpu6kNhZCATxrkEhKcguOLqLCN0y3RiJiXmaMsK2b4caUB
csu2ceUeNoCQCR219wjc6/h9RaDdVkGW20JbLTcw2EqQlWZKd+liL6andGkKo5bUHsRy7rii
vO6XmQpSVgBYNtNQAL7xYWtAbmqdQqpMrCqa2orlCwlahYPMJOzIsDuGqdQDY6aGO2doFKnZ
h1+bkWnXHgkOKJPHypUkXANrhKlC/MY5ZKcoUm8Vt1iTICShtCpluzaSrMQNbnja635o6+v1
H+Faf4yjzwEXifA1Kr7CW3C7Ka8dUuE3cGzDYBzA7kAAWt03iUnaFTZ5yUcnJRD65PLsFLUe
LYgi9jY6pSdb6i8Ov1H+Faf4yjzw6/Uf4Vp/jKPPAaF4UoS5ZUuulyxZU4p0tm+XMoEEgX00
Jtbdc2tGqVwdRGOGFUml5ydcW4864o5zmc2lgQRayraix4ouTaOzr9R/hWn+Mo88Ov1H+Faf
4yjzwH1FDpiJKTlESTSWJBxLkq2m4DShexGt76n5bm97xjTaDSqYzMtU+RZlkTV9sG7jPoRb
foLE2AsBc2tH3r9R/hWn+Mo88Ov1H+Faf4yjzwGpeGKItGVVMlijZpay2NsgbU2Ba9u0UpPy
H5IxXhaiKm0zXW9CX0KKgtDi0G5VmN7KAPG1sdI39fqP8K0/xlHnh1+o/wAK0/xlHngJCER/
X6j/AArT/GUeeHX6j/CtP8ZR54CQhEf1+o/wrT/GUeeHX6j/AArT/GUeeAkIRH9fqP8ACtP8
ZR54dfqP8K0/xlHngJCER/X6j/CtP8ZR54dfqP8ACtP8ZR54CQhEf1+o/wAK0/xlHnh1+o/w
rT/GUeeAkIRH9fqP8K0/xlHnh1+o/wAK0/xlHngJCER/X6j/AArT/GUeeHX6j/CtP8ZR54CQ
hEf1+o/wrT/GUeeHX6j/AArT/GUeeAkIRH9fqP8ACtP8ZR54dfqP8K0/xlHngLMxOS8tKsIe
UvMWwrRN+U9MUXqn1Rueel5dlCgJWba46vz87Tp3clrRzYyqGF8QcFlqrJoqDckpKm1pmWAC
ob7HaAlJ3EHfEbiCZTPpM6w3kYcnpdtHHbVqhh0EcRRA3iA9R6m/t3Pfsqn/AHOxcZ32G9+r
V9xindTf27nv2VT/ALnYuM77De/Vq+4wGk+0p8H/AMsHfaVXg5/DA+0p8H/ywd9pVeDn8MBx
TNKlpiUYTMT020SnikTFieLqNb30hSaVL0+XnU0ebzzLpGZx5e0yKCQE3AtyW0jGdkqpNycv
sHpNKkAEXStNtN4IN7xz0SiTFJlak5OJTPOTSkr2LRN12TaxUs6knnP7oT0ZluOH1OtbN2ZQ
EupG1yJN1EFRBBJ5c2t7/NGa6M+6AXJpm63g4opaN0qSkJSUG+hsnlvvPNHAKROFsBiXUy4t
N21khAlzdZUkWJyg5hYC9+WNiqbMHIWZBTVphLjIJQA1lCbhQvxQSCbp1+kiOX6Of6Jd+mJd
aZb2zpS2tSipaitSgUKTa5/S/dGuQpSmGHkPTCipwJTmaughKRYW5b88fXpOYdmJB5/I44w8
oqLd0pCShYvYnfcgR8p0m/KS02hnKha5ha2y6SsEEjU635+WN1z6N1z6PtUpZnNlldAyNqaO
0TmNlWuof1hl0PSY438PKdbDe2ZCUqUAvY8cpUlYJJvqrj792nTHTVpeeeKFS7rqS3LuGzS8
oU7xct77x22h0545AxWytZS44kk5F5lixKiQVo5gkZSBpuPyxJiL6JMRfR9OHnFTBdW/Lp2g
GcNskZCFZhkN+KNBf5zGbGHUMzUm629lRLttoKEgpBKL2IANhe5ve+6OQyuIFpcSt90WUojZ
rCbqCF5bEk8W+TTTUbt8ZGSqrVSWtrhSjlSlp1TqSm17qzjed6raadGkZ5eGeXhIT1NmZycU
44+xs0hOwGRV0EFKtdbG5Tru00HLfQmhupdUsTaEqWvbuet3s4CogjXtbq3Hm3xrlZWsMzsm
FPuLZDaC6XFZjmsdoFagb7WsDbW1oVOScmKm4tqQcTkCczvF/wCYGZBUm972sCAk6E83LfdL
NdaSVIkzIy6myts51lYS2CEJva+UEk79flJjsBBFwbxWkUycS/nEoSCsrbGcJ2bd13avfi3B
AsNPoiVw9LLlZJba21Np2qlISoJSqx11CeKNb6DktykxrGe1NYz2pIxy1OSTPSpZW640LhWZ
BHJrrcEWjqjlqovIOWlVTZsLMAjj68tyBbn/AJxZ6NT0R8nQlS0xLOcLDqmWUozLTxlWTltp
plN77r35Y6p6WyrmZnOOOwlBQBuspRv5X7oi5ClzLM/LOBh0Ntt2/NTZOU3AsbpNzogHLax3
iOh6XPXCbf4G4wEtFAdIT69cpJJN76WsARzxnH+DGP8ABzHdHlOKfd3WfBk/4dcerHdHlOKf
d3WfBk/4dcbdFu/pjin9nq/lF3wV7jaNqfYDHL/+NMUj+mOKf2er+UXfBPuNo3gDH8NMBGdV
f3EzoOva7/00xMKm201KYlODNnYywfzaa3UoWtb+r++Ifqre4mc/s/jTE0+7TGpt5195hD6k
bFwqcscoBXa3yFSvkgIqXxXTXZeXdEo6tLrIdWtltK22xxQvjXF8pUAbXN76aG2xzFFIZvtm
3GwU52yWb7VPIU233sqw38U6RzUxeEpmnGZlFSyGFsIYUnaFOVBACQRfTtBqO536R8p83hR6
rbBot8KYfOzDylcVaVON5UXOgBz2A04wtqYDvncQUqUo6aktOeXWtSUFKE8bKTci5AtxSRrr
yXjKertPlHmEKl3XEutJeLiGQUtoKgkKUTblI0Fz0RzvM4ZmJKSpweYS0gqYlWmX1IVuyqSC
kgkWUL/KOeN00KJw8yMy2EqalQCtRIbS2khQSVXtcWCrb7awGp3E9Nby/wDJzSytJcSEsJN2
gCra7+1IBty6brx8bxRTSHNrJzTBQgqs8ylNzZKst72ByuINzYC+pBBA5waKJ2XZlqdNTSZt
DiEPocBQhFrLTxlgpSkHtQNLm0bZ5OHFMpfcTnbUpRS+ytZyuJSgAAg3CrNpy8+XTU6hlKYk
lJynTE7KyiVtNOstpzWBVnKQb6aWKjz3tv1jpq9ZkqfPsSBbQZqZ4rWZIyZjcJB5bEi1wDbl
tpGC6fRJGniTfHBW51aTlcmFBxSwQRxs18wNtb740ON4abmG3350KdYeS2FOTi1FTiSVJCuN
xyOMRe9rHm0DVKYplWmGFVpuTlnJhaw2hlWbipXkKjmCT21tACdd2+JKk1FNQnZiW4I02qV4
jxzAjPmIATpqLC9+S9t4UBzy6cOTYleDPS6wM62S28RmGbMrUHjJvxrHTS43RpRXMNyU3LIY
ebC9kQhxskjIV2VmVy8bU35yeWA3u4jpbfBbMuLM22042A2kXSvNl1JAvxTpv5gY1s4qpMxM
8HkmlzTxd2SW2EIUVaKurfoOIrtrHTdqIzXRKCxLTOdS0MthLb4M25ZCUglLZGbRNnO13WVG
Dr2G6XKO1bashuX9fzIcKspKFaJTfS4Us5RzmA3T+IaRIzjsrM8V5venZXvoCLfLmsOcg80f
G8RUxea7LiCGVPgKZHGaAuFjoI3cuh0EArDdVm3HAuSmH1uNJWQu5K2yooHyg5tOggxHtN4T
ny7KNvAlLplzaZcSVAoTxEqB/J2UBYcUboDJ3GEm1LNvqpzqmy6tDq20BQbsFkDnKiEA2t+c
Nefqbr6XatLSiKS6EPOLZW4vICy4lJUQoXOlspuCe26I6XcLUd3KFyhypJOQPLCSSFC5ANib
KULnkPyR1GkSRmUPhopdQ8XwpLihxynKSddQRpbdARsziKUZqSZUSLq0KDiUOpbFnHELSgto
5zdRGthxTyaxrrOJZeQk5WalqeucamEOKuhIBRktcEHW9yRpyiJB7DtNemVzC2V7RWaxDywE
EqCipIBslRKQbixuIzmKFTpiXl2HJf1qXvs0JWpIAO8Gx1B6b66wEVUMW02Tl8zko6HiVo2K
kICgtOgSdeU2FxcC4vaN71dZYMgp+nOpbmpVUy4oJSeDgFF83Rx94vu3GOmZw3Spl5bjsuq7
is7gS8tIcN8wzAGxsbkX3RseoVPeEqHW3V8FbLTd3l6oOW6Va8cHKm4Ve9oDi9UMm5P06VlZ
Nx4z11ZsgSG02Wbm/SgiwjqFSlkM1F59hKG5F0tqIAOYBCVX6O2t82+Pkvhqly84iaaZdS82
oFCuEOWQBm4oF7BPHVxd2vyR0v0qTfYmWXGeJMr2jtlEEq4tlA8hGVO7mgIVnF9LmMvBZKbf
vp62wkgK4/Fve17NrNxpYb9ReR67SHDpKXSlKuGt7RkhveCCRfTTQRlLYdpksbty5KisuFa3
VqUpRCwSSTcn1xf0/JGD2HpR6aacWp1KJdhLLCGllBaA5QoHNe2m/dfngOAYqkXlspkZF2Y2
jzLZ4qE5Q4Lg2JvpcbwL8l7R0zmJKPJTTktM8R1skKTstx4tvpCgRzgK5jG9GGqWgsZGXRwc
ISyNu560E2sE66dqm/PbW8bn6HTJiZW+/JtOOrcQ4pShfMpAKUk/ICR88BHLxNTkqy8DmSoI
U64AwPW2xlOdWu4hYItc79LgiNExi+mS8ytD0spDORKmXVBCQ/cqByXIFgEKOpB6NReUaw9T
G21oTLXDjamlFTiiShWW6bk3tZKQOYDSMFYYpKnXHODrC121S8sZACo2RrxBxlaJtfMYDjOK
accy25SYWyM2RYYHrxCkJ4nPqtO+2/oMbWsRU9x5poSkwFqdDLg2I9YWVFIC7HlKTqLj6RHa
aFTSEjgqbJUpQGY6FSkqPLzpSfmjkmMMSrtWZnEuLaQ27t1MouA45mKgpRvrYqJsb25LQEwG
Wve0fVENi172j6ojOEBhsWve0fVENi172j6ojOEBhsWve0fVENi172j6ojOEBhsWve0fVENi
172j6ojOEBhsWve0fVENi172j6ojOEBhsWve0fVENi172j6ojOEBhsWve0fVENi172j6ojOE
BhsWve0fVENi172j6ojOEBhsWve0fVENi172j6ojOEBhsWve0fVENi172j6ojOEB5pj2q1em
15pqj0d2oMrdHCFNvttBlFtSAojMrltu0OsU/GKlLaeKySeviNT4GmLtiWlSSq5NKcTNqUte
Ynh8wnU8wCwAOgCKLihltiUdbZCwgVxFgtxTh9hj85RJP0wHpHU39u579lU/7nYuM77De/Vq
+4xTupv7dz37Kp/3OxcZ32G9+rV9xgNJ9pT4P/lg77Sq8HP4YH2lPg/+WDvtKrwc/hgI6ozU
4JOWVLSE8Sm1wkJIOnKAsXH3b446LMVBiQq01XZh6nshSVoefAAaSE8YpSSbD5SddeW0d09X
ZWSlJZSJuVIIAUC4m9rclyBf7404dr8xWUVEssS6zLuJSynaDW6b8Yi4vy6X5t8XsndDCu1R
tkLl5wzLgQFSrVkLMwkqcvmyjjKSEpvlsAd++Nyq3MthvY1QzCUTSNn2hVMt2bKwkhNlkKUp
ISMpHPxY6hi1bLCnnpFoNMCzqmnL5sylhKm7gXScl9bbxv5dhxWGJtiSmZdgTappDTiUP2S2
haUkOC4BPbhNranNyCIrtnJydVNUpaNrJtPTC23mHm0lShsnFAkgkAXSDpv5+SNOHKkuYkp2
aYm11eXDo2BbU2VqGUXtawAvcgHW2u4iNkxiJszaBI8HmpUbHavIdzflXC2nLa4NlDW5Gm6N
9MqyHZSbmJ1pqQRLzC2lZ3U2ABFiToATcacm65gOHGVbmabTbyy2JNxyXccDs1uSpIFkAA2z
nNcb+1OhjiZxdOPLeQuWYk0pdybeZVZDPb8VdlE3OQAXy6rGh5ZurV2Up2yW8c6HGi6goIso
BSEixJCR241JEcUtjCnTIaWhmb4O84htL6mgEFakpVY630Chc2sLHWA4nMV1FdRdlJeRbQdq
20lbpJCMy0JzEA5iCFkjip7XfrpynFtTD8mp4yLIcljMbI5vXbgFLaSdc+igP0txtrLnGdKQ
pJccUnaPKbRmASSlOW69SLjjp3XNlbt9u6WqblQpBnJKUUjMfWhNkNhQ7vS5Cd/TpAQbmKqm
yZVTkg2sTTrmQI0slLmQIJUoXWe20B3EWO+OnFVUfk6ghun1BPDEMrdEicllpCF2JHbKJUAE
gHkO8Axr9WDiJRM29IoLSbNqCXDmLpb2gKbjtCnlOuu6N7GKELrErTXmGBNqmFsPlLws0Qgq
SRcXOa1gNNx6LhGO1uebmlNytQVMsNqHBHbIVwxRLeZFwLKtmXomxFuiJnCk+7OPTyVzgnGk
uJUy4khQyqB0JAGVVwboNykEam8TgA0sBpugABugPsaKhtjIvcGdDTuQ5VlGbKbb7csb40zq
3m5ZapZDa3QOKHF5UjpJtuG+ArMhWZlydpYVUErU7KJVMNKA4qi0FBSk5Qct9SsKsNE21uM2
KjNP1SaYcmCtNpgOMWFmQhaQ0d1xmSSdSb7xujbTsUOzU9KsOSSfXm7koWTclJUCkkAZSE6A
kKIINraxtNZXNTL8sqXShpYeS0sKuolpYSvMLc6tLE9MBpO6PKcU+7us+DJ/w649WO6PKcU+
7us+DJ/w64C3f0xxT+z1fyi74J9xtG8AY/hpikf0xxT+z1fyi74J9xtG8AY/hpgIzqre4mc/
s/jTHdWMLyVWn1zcyt4OKQ2jiqtlCF5rjmJF0noJEcPVW9xM5/Z/GmLQICuTuDJOaal0qmH8
0uyhltRtuGcEkC1yQ4oc26NrGFGG2Zhhcy8tl5SMqMoGRCXS6E9OqiL80T8ICDw/heVokwl6
XdcUpLamteVJyBN+XQIH0mE1hWRmXnZlxTnC3XVLL5ObQjLlynilOTiWI3dMTkICFYw20Jdl
uamn5jZpeScx0IcFiBvIAG7WNMhhCSlpYsLcdcbJzEXy8YJCUqvvulIFtdDqLG1rBCAjZmkq
feln+GOpfZbLTjmRJ2qCQVAi1gSUjUdPzccthVhmYbdMy8osILTIsBkbyqAT02zqN9+7556E
BXH8F0995lTq3VJRLIl1gntwhJSk9BAUrk5t0bJnDjkw62/MTy5lxCbLQpCUJdsQUgkDijSx
Ou/5In4QELT8P8Hw+mQdmXFvlxL6pgnMdqlQUk67wClItzJjinMGJmEuI65TDaXiXHsraCVu
kLGa5GgusnKOYRZ4QFalsLTAAdmakpUyzMOvS60tJyt53Ss3HLe4+TkvvKRwgJMMpbqMwQy6
lwKyJC+1QFDMLaKLYuLW1Om61lhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhA
IQhAIQhAIQhAIQhAIQhAIQhAIQhAUbEnt0/8o+6PPMXfkXv24j/Bpj0PEnt0/wDKPujzzF35
F79uI/waYD0Xqb+3c9+yqf8Ac7FxnfYb36tX3GKd1N/bue/ZVP8Audi4zvsN79Wr7jAaT7Sn
wf8Aywd9pVeDn8MD7Snwf/LB32lV4OfwwGuZmJeXk5fhLSFIWEi67ZUm283jhYqVJrFOqLDb
TnBmrNu7C42gUPzCjU82kbpimSL0rLomX5pskcTLNuJJ4uoGvNGEjT5OVlKg3Q50NTS7bV91
ZfLSgkZSoKPIm2hIip3cLUxholraoes2koc4TtCG7FQCXcxte+cJzXtra1xGbXqZKJUPSw2q
5xLbSZptSng8AFJuVXULJykXNgLfJGKcNS8yy2y5UWltzDY2gZTYvZCohSSVEjVZKjxrnmj6
MLMzbzc+5VX1P7dCy5LKyNryFICQm5tfIATe5I6ABFd1UXSUVVjhja9snIcyQrIkFR2e0tp2
98t78a9rR0USZkZnhQk2nGlB4qdQ62pCiVAHNZXIR9x5o5JihMidZDU6tsL2eZt5anVubJZc
TlUpV9FHXfputvjdR6atMhMNzs6ibcfcKnZiWCmVKULA6pWSLWtoRYC0BoxAzS3KxIpqkwpL
jiFolmkKLZBTZa15gQRYJTrfS554Ip+GmKSEAyYkhrdUxdJzt5NVFWt0G2/XfG6uUBqrMttL
fdbShpbYsSVHME65r30yj5YjjgmXU2kLmlkk53QUlSXHM+YL4xJuAVpFydFa3sIDtalKA+ph
xsy4LjhLJQ/l2pSlIIFlcZNkI4uo4oNo+zQo7+HODs5pqQ0bSiRcUsqsb5QUG/Jrr8scs1g9
mYnA+qbdALq1rQMwBBc2gFgoDRXKQbjkB1jqek9nh1FMkamxLGXQ3LreKAbAAApsFDKTu36X
0gOATOGnztFB2YCmgApwuLDqikAJ1PGdyqA7qxtfm6JMYcXOU5tDCFTi1OPMF1tSnUrRdKyp
RucwJI4x37t0a1YZadeUgTzaSypL6Wm2gNk7lSASM3aWQLJ37+MY2SWFWmKoxUhPzSnkuLdc
SlVmnFLzXsnXKm6iQLnfykkwFhhCEAjirrUq/Snmp5D7jCwApDBWFr1FgMtjqf8AfSO2OWro
fcpryZWbRJOFOkwtGcNjlNrjkvrfTfAQkjMUB6eYLQmS+W7lbinTs1BJHrhJ4rgTmGZWoGlx
cCNuekmdnBKIWJopXxjmyKIUNpkvpfNlzW3m17xrp2HZdioMTDE3K7TZpcAaasV5UbNJBzE7
OxBKbm51vG7rSiXm5l5M2HS2HFJZCQFILygpWY31BKeLoLC++A0HdHlOKfd3WfBk/wCHXHqr
qg00tx0hCEJKlKUbAAakmPKcSrS5jerrbUFIXKoUlQ3EGWUQYC3/ANMcU/s9X8ou+CfcbRvA
GP4aYpH9McU/s9X8ou+CfcbRvAGP4aYCM6q3uJnP7P40xaBFX6q3uJnP7P40xaBAVevz2IW6
6GqUy6pkJICVM3QobNRzZrWBCgkaqvyZbHNE5RluuSIU8uZc4xyrmWg24pN9CUi33D5I7YQC
EIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQC
EIQCEIQCEIQCEIQCEIQCEIQFGxJ7dP8Ayj7o88xd+Re/biP8GmPQ8Se3T/yj7o88xd+Re/bi
P8GmA9F6m/t3Pfsqn/c7FxnfYb36tX3GKd1N/bue/ZVP+52LjO+w3v1avuMBpPtKfB/8sHfa
VXg5/DA+0p8H/wAsHfaVXg5/DAcU5TqhOyTCW52WQUgHWXXzc4WDcaGOSm0F6j06pKcQ3VHZ
myxLgZAspFrErUb3OpJMb6g7PrlJVUrTphakWNkrbPJyjOLj544qPw+Rp9Xmq+9MyTJKVpcJ
SShITxilIKgnmA1598XsndxHDU+6yUMy4l3JhIVtVLSODqCnCsAJJsFZxYJvpv6cl4eqz05L
TLDMnLy7U61MJlHTq2UpShS+Icu5JsP6xO86aE1OqpZSqTnH5h0oCpNsEObVJU5nCiNFqQAg
E8h+XXYKtVETEq3JGoTUgJ5scKQhLm1SoJCkFRsbBZWSbaWA5DaKk6jSai/PoW8liaWoMAPo
GyS1s3StQsVEjMkhN0k3trYR0YekJ6Uk5wIbaklvOhxpLgS5kOVIIIRlBTxQE7jYXOscVXql
QRPNrSxOMupSyqXkgpBMwS4oOjQlJIQARrxb3jpwrUKk7S512oS047MtTTiQ2tCGyRoQlOts
ovYEnW0BniOnVOdcljKTLyNmyoLLD5ZBcK2tbA68UOWve14hqpS8UKfLck/MobTtUNrTN/8A
+M7XLclV82rdjlJ0vm3iJXGNfm6NKMOSrKA44hSyh4XvltxLg9sb8mYm2gtcjjma9W3Nvklm
mES8s6pd2VlTrrZSFBBChZJKtDqdNLwElTpGdlMQukGYckC3ZKn5lS8psmwAKzf84klIPSb2
ES/RpqZmnZoUYMhKygS2drK4jK4lKtDYqzLzHNYgaC5Bv11KoFnDDjk/PTEu4uafabUhYbUs
hxwITmI4osAb8w5RvjnKlUg/lXPPEFZTOqQLJZZC0BLie4CkFRv8/JoBzC9WXKqlEcHCti62
++6okTaVlJCdDmFstiVchsN9xa6Ew/K0WTYnA2H2mEIcDfahQSAbdEV7D1UrD+IJNmdZnhKK
lnglamk5HSFJKXFKvfVJAAsN5NtdLdAIQhAI4q4Fmlu7GRTPuCxRLqUkBRuLXKtLDf8ANHbH
DiCZYk6Q+/NzLsqygDO412wBIFhzE7vn5ICBp9GmWZ2RUiQW2iXaVnWpxsFYUk3ACdUqBNkg
KKAkncbRtZpc1L1CamHWUoQlMyS9mBLwcWlSBprxQCNei1446TUJ/hkohyfW4riixUHEFjZF
RcJGiileVJXpqOS8dUvOTbtUnGnHnVjJMbZojitJSsBkgcmZJUf63zaBVKwB1lntB7Fd/AYp
9S90k5+zWP8ACGLhWPaWe8Fd/AYp9S90k5+zWP8ACGAu/wDTHFP7PV/KLvgn3G0bwBj+GmKR
/THFP7PV/KLvgn3G0bwBj+GmAjOqt7iZz+z+NMSNRrhkZ55jgy3g2GQA2RmWt1ZSkC5AAFrk
3iO6q3uJnP7P40x01KbpUviJaJxLxeEs28s7MqRxXDs7WFyu+awGthugN9PxLLTswy0hiYQH
FlkrVlsh2xVszY77JJuNOnWNSsXSBnn5NpDzr7bhaQlGX1xYUEFO/i2URqqwOpF7RzylQw61
UnXGmUtLl7BLoGZK89zdIBN9Co5raC+oF42zUzhtQmHVuyy1O5CsBwg3KylJT3JKknUW1Tcn
lgNjGLJJyn8LWxNNIDpZUlaUgpUGy4b623C2/f8ATHJL41YdeV/yjwaBQi5UlOVZUsG5JCbW
QLG/GvpGiUlsINy5aTleEtmbAUlwkm6kHKAOMRxk5kgkAb9I2zQw3JsyCUSu1ZqhzodQpeVx
NsxUtV9Qc+5W/NywEnW8QM0t9bLjLpUGFPZ+KEmwUbAEgqPF1A3XF98aJjFTTU2mXbp868p1
xbTCkZAl1SVZFb1C1lX323XEEvUSvvtcIazurbUA27mtyixtxSqxJtvAN9BG+Ww3Is1hypLz
vPqUVIz2CWrm5ygAcvLAblVqXGHlVgNvKYDBf2YAzkWva17X+eOVvE7BfLLspMtONuJbmAcp
DBUoJQSQdQSQOLe3La0d7dKlG5R2VDWaWdSElhSiUBIFrAcgj4ujyC5sTKpVsvBZcza6q01P
Idw37iAd8Bys1s9fH5B+VcQhL6WGpgEFK1loOZSL3Btm1tbTfeMqxXmqZNoYclph0FvauON5
craMwTc3IJ1O4A8sbnqJIOzb81scky+gpW82opV2uXMOZQGgVvAjdM0+UmlFUwwhxRRsyVby
m4NvpAMBxy9flnZWZmHG3mWpdgTRKwDnZIUUrFid+VWh103Rpka5Mv1IS8xIKlUmaVLWWsFY
UGUug8UkWIz8vIIkJalyUsh5DMs2Evk7RJFwoc2vJqdN2p0jRKUKRk32nZVtTezWtzKFEhS1
JCcxvck5RYa7oDnp1cdnq3wRuXtLoacWt4kA5kvKbCQL3/MJvy3G6PgxElqgyVQmZdZM1YFL
agEoNidVKIAGnKdTYRJy8hKyzqnWGENrUCCpI1N1FZ8pRPzxqfpMi9IIkly6eDo0S2lRSAN1
tDusTpywEJNY6pzTqwi5aYdUl5w6gJSF5iAOUKRaxte9xpHSxipmbl1rkZSYfW2hSnQkps1v
Aub6gkHVN+cxIdZKcXFLMo0oqVmIUCQDYjQbh2x3c5O+PgodOGxvKpUWb5SpSlE37q542uut
9dYCJnMTzkvLUp1NKU4qdYS64hLqbtkrZTl32P5U69Avyx0SuLpB+ptU8oebmVqKFoVlJbXd
QsbE31QrUXG7nju6x07JJoMskpkhlYBUo5BdJtv11Sk637Uc0bG6VJNzQmES6EugqVcX1KiS
SRuJupWp3XNt8BEVrGEtT5x2UbZcW62QCo2Kd6cw0NwQlVxe17fPGb2LWGnW2xIzrxdUG21t
hASty6AU6qFrFY1Omh5te1/DtKmJtcy/JNOOLuSVEkXNrkC9gTlFyBrYXjS3hinprHXFxKnF
pA2TarBLVspuABqeInU33QGVKqk7UJ+4kUt07Yn15Tl1h5KyhSCkaWGXeDYxxM42kZlWSRl5
maWpVkJbKBdOVSsxJUABxFaHXdprFgl5dqWb2bDaW0ZlKsnnJJJ+ckmOZqjyDThWiVbzZioE
3OUkEG3MLE6DTU88BEuY0kdkh1tmaWksreWgIGZISCQnttFHKSOjmuI2vYqZYJS5Ize0zhkI
TkOZ26boBzWuMwN92/XSO/rHTNmUcBYym1xl32QEfhAHyRk7SJB2bVMuSranVFJKjfeCCDbd
e6U679BzQESvGLIdU0mmz6loJQuxbASsBZKblXIG1m+7dzwTjWQeeLUoxMzLilhttLeQFZvl
O9Qy2PdWvvF4lus1PzrXwRnMtZcUbb1EKBP0LWP7Rj41Rae06HESqAoKSpOpskp3EC9h82/l
gItjFDszQqvUmJBeSSBLKVuJBes2lRB10sSRGbOKUhsGZkZlBTtNoq6LBLasji7ZicoVpbeR
qBEjL0Wny7EywzKoS1NCzzYJyr0y7r82kfXqRIPBsOSrZDTinE7xxlKzK+UEm5B0vAR0hipm
cnWJfgM4yH8uRxzJbjBZTeyiddmv5LC++OZjFrqZ+YbnKY63LsuFBfQtKgBt1tBRF72OUaAX
39ETbVJkGltrblWkqay5CB2uUKCfozq+kxg3Rachb60yjeaYWHHL3OZQVnG/+tr8sBqw7X5O
vMuOyOfKgjtrEEKF0kEXGo5N45YlI55GRlpFCkyrQbClZjYk/fyDkG4ckdEAhCEAhCEAhCEA
hCEAhCEAhCEAhCEAhCEAhCEBRsSe3T/yj7o88xd+Re/biP8ABpj0PEnt0/8AKPujzzF35F79
uI/waYD0Xqb+3c9+yqf9zsXGd9hvfq1fcYp3U39u579lU/7nYuM77De/Vq+4wGk+0p8H/wAs
HfaVXg5/DA+0p8H/AMsHfaVXg5/DAR1Qr8rJSkstM4wEmwWCpIuLchOgP37o1YWrs1Wk1FSQ
wQw4lLNlAixTfjKTcG3R8nTEo/OpkpWXU6nirABUVWCdN5jhlqzI1uTqDXB3nWWLNrCATtgo
XGW1j0cnPu1i9klrNfmGmVOvMtqQyBnKSRtMxUEqTfcOLfXn+nJzERl5pqTmODCYL6G3PXco
CFAEKAOpN1AW6CY52qtQ0ltTsu83sApDqnklQYN1DKvU3N0rt23yi4vuZqdGbblWVyy2nHJt
LKGXG7rS7YKBOpsMpSb30uBv0jnWXlisvLqfrQLoVJ7N+XQGytSVElWdZQAnkuCOXfGdKqS1
yTjtU2cs61lLjZSU7K40B1N/lEa6tO02XqDXDWlqW2lKlu5bpaCiQjPryqBA0NjrpvjLDM5I
Tsotylsrbaz9sU6K00INyCLcl9NxA3Ram2qyttqNXaki16y8+HUFwKatYJBSL6kcqxHLM4ml
mLJU0+ldlZhYHIoZtDY86Tru3a6x3TxkTNMtTmy2riSlvOoAnjJJA1udQn6IjH3cNLeC5h6S
BcWoJzPCziuUgA2P5S1zuzcxEJjLskxl2SNVmpmVLSmENLQVhKkknMq51Ceawubnm+eI3r9M
5NGWivYcL3m2zy5sv6XJfd0ckb65M0+Vn5d6fYmPW9OEpCg21fUBRuL3KdwB5L2vHD1yoYb2
a5J5BSvaOtqb1ZTpxla9pZSdBfQ7tDZMT2JjK+STo1aaqk5NtsFkts5ShSHAorBvqRyag2iU
iPpM3ITs1PKkUjaMPcHfWEZcykgGwPKBmtfnvEhFi+7UXXMhCEVSOSrz6KdIrfWU3GiEqWEh
SjuFzujrjnqLzcvJuOutLdSkdolNyro10+c2A5SISkuCTqU1NPSKmeDOMzEtt1JQSSNBuVex
4xA3c8a3qot2amZJxCU+tOKSnXMkJIFzyWVmBFv/ANfZGq0db8sxLAoW/I7ZACCnIwm1gTyd
sbDlseaMDN05yanW5dpaX1Ics4oHK4UEBzLrpY5QdBc89ozUs1KkVj2lnvBXfwGKfUvdJOfs
1j/CGLhWPaWe8Fd/AYp9S90k5+zWP8IY02u/9McU/s9X8ou+CfcbRvAGP4aYpH9McU/s9X8o
u+CfcbRvAGP4aYCM6q3uJnP7P40xMT9GZnJozW2fZmAEhDjZHEKSuxAIIvx1DW+hiH6q3uJn
P7P40xaBAQLeDqeworlXZphdglKkrBKBlKSBcHeCb3vzi0fDgqj3BQh5BDinE5XNxUkJt8lk
iw+XniwQgICfw2UpZepUwpqcYzbJx1VwnMpRUdx14xGoOnTqOhOHZc02QlHnnl8CZDKVggFd
gkXPTxREvCAg5HCdPkahw2WLiXgDZRSgkKKcua+W98ulr26InIQgEIQgEIQgEIQgEIQgEIQg
EIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgKPiR
CuvT/FVycnRHneLwQy8CCP8AriN/gaY9GqmF6JNVKYfmKay4644pS1qWu5N/0opvVMpcjSqV
TWqbKtyzblRzrSi/GVsVC5ueYAfNAXHqb+3c9+yqf9zsXGd9hvfq1fcYp3U39u579lU/7nYu
M77De/Vq+4wGk+0p8H/ywd9pVeDn8MD7Snwf/LB32lV4OfwwHG9S6Y5LyyJpLoUoDJkfdSSc
uoBSb7o1yspTWJOpM0ScEo/uffKy4ppWXQqzk7k8+kZzdLnZ6SZSmoIRlAPGl7jd0KBvuI1j
nptAdotOqBaDVSefyrQwtOyQSkWAuSrl1J54vZO7maoVOm2pdldUaeRMNWKGSkcICCohSdSd
M5uRe51PLfJvDlNmyzPuVR159UwhXCGJjIhwoIARlScv5oB5SR8w43MMz8yw43kbYVNgLdcU
sEtLCnCdByKK9LHQXv05uYaqszOy86FyUuludafEqtBc2eVKUKUFAgXKU6C2gJ5zEVIztBpy
X2pcznB230hK5dTt1PBtRWMpUcwsVEm19OaMsPU2mKp8wzKTzU80sobWphwAJCEgJTxDoctr
nl+SwjVNUaoOT7anXGpnacHzvkBsthp4udqL3zA5dDyaxIU+QmWac+No2xOTDy3VuJTtACVc
Ua2vZASn5oDmq9FcnanJLYmESwk2SWVHjqKsyN6TvSAnffeoc2vJLYWkZWWXJqqTilvMOy5K
igKOdLQUbDl9bSbf1vkjfXWqmurU8yIde4M2XHwFFpDpzIAF+1ubKNuYdIvDepivvMyy3Jpp
ubb2hDyni4WipCALXGtlJVAWKsUhVUqCA7O2l0tKSqV2YJ4wUkrBvcGxIB5NeeIs0WmvJccc
rTa1uucEmVpWgBeiQGhY8VdkI3a79NRbLC9DnJGrGbnmwrPK7JKi9ctALJCLco1vfW2ojmco
lSmw6+uny8u6825LlkPJKG0KSlKFJsPzQDfS5zG2gAgJmg06m0VdQ4JOrWkrSp5D00XBL5UA
W4xOXQX1/lEzFGqOEKpOU5+Tbdk2wlh1q7qStM1mWVpuAQUgG173vryb7tLpWlhtLykqcCQF
FIsCba2FzAZwhCARz1OWVOSTjDbxZKxbNkSsEcoKVCxB3EcxOo3x0QgKzI0Ok06uSxZqi01F
DbgEuqa/KFQGuyzWAAToALADojf1tlmJydcbnQ640hxQlwU3ZLpCllVtdSkWvu138nbNyK5i
sJmXEIWyzLrS2nNqXFGxPRxRa/8AWPzxjVKmpedmH3UthptMypKwq5c2q0qAtyZcttd+loCo
Vj2lnvBXfwGKfUvdJOfs1j/CGLhWPaWe8Fd/AYp9S90k5+zWP8IYC7/0xxT+z1fyi74J9xtG
8AY/hpikf0xxT+z1fyi74J9xtG8AY/hpgIzqre4mc/s/jTHTXJeoNVJT0imYMvMJSJky5G0R
kJ7UHlIUPmT8kc3VW9xM5/Z/GmOqr1Z6kVxpMwtIkZop47miWbZgvXkvdvf0wETSmMSytOl2
CmaQpuXQlaSUEBvKm+X/APNfP0buS0bag9iNDC2ae1UVFxCCw44GipAAXmzndm7TTX741Ixh
UVSpdMuwpSmGnUobR+SSrJdaypYsBmJsoJFh22+2TGL55W2U6zLZ2kAqlUIUXEJ2OfaE3tlv
YWA/OHG5wzm5bE0sXUykxNPtZ1pJeUknZBTdinKAcxBd+joEaKjT8RzNJcM29PuOqdQlxqXU
hHrQaSolI7rOCL35+QxtksUz87KuBapVhYDiW1JQpRmSCR63YkApABPbDXfbWNTmMKhLy0kF
yyUvObPO0+myyDkG8GxUQoq4oVbcQLEgOiearymg6huccmWXlrN1ICAS24kFvlIspOh5em8a
ZMYmyIDq6hmUl5KCUIGzTdeVRBJzG2TQkHdqNQMZnGVSacWhpiVfUEtrUlCCksKUFnYrzLAK
roCbjW9+KdBGdUxNPU2YmlpQFKMyUJYe1CUpQ0ciSCOMorJ0zHdxdDlDCYXVAuVK2nxN8FdS
yFKu5+WQFK1G/Z6gDjWza7o536fiWZpzUxOOVRUyy6Q0yhTaRbYrSlSk3N7qKb3J3mO4Yiri
UpUtqRIW2lYSWnEBOZLpF1Zju2Quba5uS1yYxHV5t1sSolNkrKkuLllm6iHiVDK4QR60ALEg
5r33QG2pS9bfLoYTMqmEPpW3tCkMABXrZHLutm+foj5h0VEV2U64m72wfzbQccNXay5unPnt
fkvaI6fxfUnplpplUvJIUULWooKlN6oBSoE7lZ9CQndpmGsSFFqlWVUKYzPubRS0JDmzRkSo
KZz3IUTqkp3i2/dAW6EIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEI
QCEIQCEIQCEIQCEIQCEIQCEIQFfmvZTv6Z++KF1YPYFK8O/0lxfZr2U7+mfvihdWD2BSvDv9
JcBZupv7dz37Kp/3OxcZ32G9+rV9xindTf27nv2VT/udi4zvsN79Wr7jAaT7Snwf/LB32lV4
OfwwPtKfB/8ALB32lV4OfwwEbUeuLspLKlqeVrbsRZ5HNzGwI5/l+ccdGYnqdT6vNVxUywhx
SXAWlBbgATZWVKL25gB0cusdlRrjMnJyy0PlKdAoFBAULbrlOh5o04ZrU/VWqm4SykNLSGCs
HIkFNzdQtmt83N0xeyd0QmZq+xCpF+edeUnNJpKlrTlKnM6VFWiikZBdWu62/XZwysiYlRIN
VN+nJnmiHs4KnEkJC0KzkLyhWck25huFo6XMVT8sw6/MMy60S4SVgJUgvhalhCxcnILIBsb3
vvEJjGDklUWKdNrkuEmbbbdWSWxs1pSQUpJJzXXa1z2pOmgiK21Oaqap5sqam5d4pa4OwyvO
lR2ittcjik7PKeNoOTWNuE5ipda5pbyH5l1Kk5EurKcxsMwuvUEG9+QHQRnOYjc2pcp6W3Zd
pLJWlaVJU6XXVNgAm2WxTe5Bvfk3xlQcRGal5xdQAQZQozqSytNsyb5cpuTY6XGh6IDDF9Xq
NNlZZUiz66tKlqSW1OAkW4l0g6m53DW28RzIxDUmZm84wUywcIeUJdZLCsq7N6XzahBzDuuk
RMVOtIkVyfrK1tTJ1eJyIQNLXJG85tAbbj8kRTGN2JhKVy8jMrQpJezE5bMhObNxrXNvzRy8
vLAYUWoTBwpOTVdmZ7OH1FaWmVNuNglJDabC9tbXG4HeLXEcZisplgmUmJ16aCBsshWtJZ2R
JPGFlKC7DMeMbDnjvZxylCP+cknAuzjnrJKhkzuJbO7erZm9yLfdnMYvmUuIYbpS0zC30MhD
j6SFElvMLg6WS6k357ixsLhzSk3WDWaemXaqLlJE6oIeKwdo2W1Wz5znypIJuRqSN9he5xWV
YyRkUtMg9kDiWEqKxxninMU2AJsAFcbdppvjvqFUmFUaXn6XswHkJWht9pRW4VAFKAkEWJvq
Tu32OsBLwirS2I5+anZeVaTKtrnSosrKFKDSUldwoXGcnJvBG/ltrlhfF7ddq5lW+DITwND4
QHLuZyeOLdyLgXtqQeS0BZ40VBtx2ReQy6tlakEJcbAzJ6RfljfCAp9MXPoqEg7NTM26tyTa
CmlIdSGAGiVOq42RZzGxBTe5HNG+XenF1ScS6uZUMkxtkrzZEpzjYZQdBdObtd/LqIl5qemm
q9LSaGWlMPS7rmYqOcrSUWHMBxt+vJHAKxMTM0/LuIaDLiZlLYSDmSWVhBJN7HNmvoBa3LAU
yse0s94K7+AxT6l7pJz9msf4QxcKx7Sz3grv4DFPqXuknP2ax/hDAXf+mOKf2er+UXfBPuNo
3gDH8NMUj+mOKf2er+UXfBPuNo3gDH8NMBGdVb3Ezn9n8aYkahWXZKqKk9gHVvJQZRIVk2ij
mzAk6C2UG/8AWER3VW9xM5/Z/GmOnEFSpyJzgdTpypq6kISUtbQlLgWdAATvasbdBgOaqYvd
Zm25WQkFPOuONtpK3LJzKUjMkqFwDlUbanUbrax0JxE22yJhqnLCpw7ZqziQXmwi+dXMcqNx
5gL77a3n8JTD61OMyLqy0OOGL5hZNkpNtVWycUa7owNTwypp0GTSpLj91tiSWVqdGYqzJy3B
GRV/kPPqHyaxlsX2XESi1SUwhaWHCo5nXAtCAMoBKRdR1sd3095rauASlSICJGYcSF7RBStl
KkkAnXu7DduP0x9QqVBaNSnHKa1MKS0QXGmc630htDitwuEgKbuo6XtzCJFdYoymFSwAdQgh
CWES6lZ7X7RIHGAynUXAymAiKDX2JGQm3XpOWliJgDZNqSyrKoXSVZ1WsQLjUEj80WIjqma6
3Tpwzhl5ZqVmpLhBWld1uOBTaEhShxbccC+vPewjoZqWHqUkuyqG2S+4W/8Al5dWZxYIGWyR
c6rFvljMYmoiss0XiFBNkrWwtKsh1JFxfJxDc7uLAQqcZz5psjPJZl3mZmVCi4yham9rZech
V+1SUji7yCTfSJet4hVL0FE5IIUt91ZQlpTRUsFJO04txcpCVEi/JvOl+ecr1GszLSsgqcKl
LlWkCWUEW4wXYlNsl0ZSRcajkiUk5Wm1OhSqUybRkltocbZUgWSCLjTn1gNE1XeDyMnMJbMy
qYaWsJljmCylBVxSbXBtobaxrdqiXWKfPM09ExOPurlmgHQNmbKUq6iNPyZuLXvoREoadJKl
0MGUYLLaSlDeQZUgixAHILaRkxJSrDTLTMu0hDJzNpCe0NiCR06nXpMBAereSSw3Muy7zcq4
QA6SOKbJKrjmGZOvLr8/VK4mZmaTMzyZZ5HB1pZU04QFB0hN0HpClAHfre14kE0mnJJKZGVG
ZCWz60NUptYfILD6BzRsdkJR2XdYclmVNOqKnEFAspW+56b8sBGtYh29KlJliSdL806tlEut
WQhaM+cEkaWyK3jm3cnE3i1xCnhNSNk7R1EutDg9cKVJSAQLkHjDde9jYbrzZpNPMgmRMlLc
FSbhnZjIDe+75ST88fXqVIPNlt2Sl1JOY2LY3kgk/OQPoEBBy2MTMyy3mqY+EpKWgFuAKU8f
zAkAq011tfTdvsGLHZumom6XT1LC3GG07d0I461N5kkbxZLm/XUbueZFFpgk+CJp8qmXuFbN
LQCbjcbCPiqFSlIyGnSmXZpayhoABCbZUjoFhb5BzQETIYwRUZhhmSkXlqmFgoUtWROzso5i
SN/FOgvya83RUMRqlJ6Yl0Sa3xL7RbigtKQlCENLURfefXRYabju3xKMU2Sl3S4zKsIWVleZ
KADmIsT9EZLkZVa3FrlmVKdCkrJQLqBABB57hKR/ZHNAV2l4sm5hlImaYEvKKUJyPjKpaycg
3XAskkk7uS8fXsZAmVelZJa5Nx4MuuKWAoLKM2UJ+dOu7f0GJtFHpyJZ2XRIyyWXjmcQGwAo
3vc/PHx+iUt90OPU+UWsN7IKU0LhFrWHMLG0BHP4oSDOhiUcUmRDm3WVpGWxUE2BPGuUH5NP
mwOK8sxslSDnrjimZdW1T664laUEEfmi6hqb8um68mihUpCW0op0olLYUEANCwCu2+m5v8ph
P0eTnJRbBaS0FhXHaSkKGYgq3g7yBfTWA4JjE6WaEzP8DdLrq1oTLhQKroKs2qQb9qdwPJu3
x0qriFLk0y0u47wlkTBupKMjZsL67zdQ0+XovsboFLTSmacuSZdlWRxG3UhQG+5+e5v8sdDl
Pk3dhtJVhQlyCyCget23W5uT6BAQM1jNLDSXBTn1hbJmkgOpF5fKpWfXlIQri89teUZDFjyp
syqKU4p5DiWXBwhACXFFYSL8o4hJPJ0xMppFOSHAJGWs6VFY2Y4xULKv8o0MbBISYdU6JVgO
KWFlWQXKhexvz6n6TAV5rHEvMKCZSRmXVOFtLQPFBUooBBJFhbaJ5Tex03X2S2JJyYkazMcD
aaEgLNZnM2ZYHGBtyBQNiN4tuiabpUg2sKbkpdKgEAENjQIsU/RYW+Qc0fUUyRQp8ok5dJmB
Z6yB64Lk8bn3n6YCvN42YRt+ENKVkQhxKUJNwlSEkX3i5UoCw1tc7hHVP1+aVhtNSp0sQoLU
l0OtqOzy5gTbQkZkgZtLBWYjSJfrbI7PZ8Dl8m/Lsxbtcv4dPkjNMlKpkuCCXa4Ply7LKMtu
a0BH4argq6XkraWy62onZqQU2RmUka8puhQO7UH5TLxzsyEoy+4+1LNIddVnWtKQCpViLn6T
9JjogEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgK/Neynf0z98ULqwewKV4d/pLi+zXsp3
9M/fFC6sHsCleHf6S4CzdTf27nv2VT/udi4zvsN79Wr7jFO6m/t3Pfsqn/c7FxnfYb36tX3G
A0n2lPg/+WDvtKrwc/hgfaU+D/5YO+0qvBz+GAxfnTJysuVIKkqACjc8XTfYC5/lvjglKpKY
hlajLPyK3mGiG1NqTfbpUL9qbED5eTXdGyYpdIXLSyJuVQSu2TKFXvbnEYSDVHYlaizSn0SK
mzaZdQbKaVl0JKri4EOyTbSxMUVgtL63bHgoUgqUhKtgSVDLvN7kK3XHyXjfLTFLlmZeVRIl
jNNBKWA2DkXYKCjY23FOt9LgRpYlaPMJl2hU23kvt8VCXEAPBJVYi3NdW7590fW6fRppLM4q
fD61vpCJgTGXaLSeKiySAd2619Ix9mPu76mZBE/KOTkttHrqDbpbvs7JKjc8miTHzD5kESym
adKCUQgg7IJA0Iuk6c4+i1ozek6e2JWWJbYTtFFpoKCdoooUCAOXilR05rxhTpCRVLvtIeTO
JUrZOkqCrZNAg25R9PPF5219rbKqinKcl1VJDKlJXdouC9jpr8m7U6boipyWw2Z6WLrLKlJf
XYBPECym5Urosgi+7eOeJadpjU0GxmW0EILRCLcZs2unUadqNRrGh2hNOspZVMTGxSpWVvSw
SUqSU7v6x137oTq7E6uzlbGHVziWky0tndC3AS1YErUQu99xJve/ddMbSigVRKEqYlH0vnMk
qa7Y8WxvblypseXKLbozNBbW6px2amFl223BCQHSDcE2GlrDdbdBNFkeuLC85U/LNNjKqxUU
puEKOlxrm3Wv80Psl5tc91slkqknqZZhy1sraQlxQCUpSNb3tlAOg0teNcy5R6k5LtTkgF8H
VkBWgWl1m6cuh/qkXFx06x2zNJ4RNOPOzTxCwkIRkT63YgjKbX7YA67+XQCOB+SowmHpabqC
CtKNvMsrdSkqsSc6rapAKuSw1ET7H2vk65KTpNVkXX0SDWymnCVhxoJKylRFyPlBPz9JiRRL
socDiGkJWEBAUBqE83ydEcFHXTJNtuVkpxtZmCt9tKn86lhRJJFze2v7vljvl32phvaS7rbq
LlOZCgoXBIIuOYgj5o1F1zai65tka5l5Muwt1YWoIF7ITcn5BGyNM8+xLSjjs28hllKeO4tV
gkbt8VXCZ6XmZmVzyLig+wpaHjlORBSCoEXzD80Gw32jB5MimaqAl5UNzOwSp13Z2zg3AF+X
dr83zfZB2lh+Valag0t4yoal07RJUUD84Dl3eTGU0uTW/PbKZQuaRLpQ60FglABUQSOTtjEi
2Yt5/WPaWe8Fd/AYp9S90k5+zWP8IYuFY9pZ7wV38Bin1L3STn7NY/whitLv/THFP7PV/KLv
gn3G0bwBj+GmKR/THFP7PV/KLvgn3G0bwBj+GmAjOqt7iZz+z+NMVPqtdUigYZxO1IVWm4jX
OSjPCW5mmhvKEqIH5yhexI0I5RFs6q3uJnP7P40x+f8A/iVrjNL6rFRl5gziNtIMhp6VcCVt
XHG3775U826AnV9XfqeJS45IULEDDjiAhtRl2iErTlsq4cCieKnl5L259tM6vGB5VscIpeKZ
qZWpxTjhbaupSgsK4u00HHV+7mjxdvGEtNBppcm1JguqKli9mwSshYIBssZ94T+aN+4ZVbFy
ZeZLUkueWUMtNGYW4ULdCS0STpex2fLziA9mX1ccFCWWTSsUtS02lRaLDbKV7PIlt0Ehw3Sd
mk3sDcHWN8x1d8DykwpJo2LJeYRx2ihLOaXSb3CfXDYHMrfff8lvE5TFUjLTDE2GHM2SymGh
2oDzi8pBGUhQcTrrqDxdRbow/XW6tXWEMNzjL4LKWmZXMp6YUlTh2aQlOoVnFweUCA9mkerb
gyo1UPSdCxjMLazTaWUpaKU5SlS16uXPaC9yeXnjFzq09T+YqUrTZihYiQ+C0w3tEMKASSba
5yLEObxra1jujyet4X6oNRZKW8JYobUHCUKMq6crZbSgoGmg03bo+K6n2MXMW055vCVcDEuZ
VtTvW91IOQIClajdoddNAID9fzWGpVaGlSq3WX5dTimF5yQlSlFRuOUXJ05txG+JGlSTdOps
vJtaoYbS2DYC9ha9hz746B/OPsAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAh
CEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEBX5r2U7+mfvihdWD2BSvDv9JcX2a9lO/pn
74oXVg9gUrw7/SXAWbqb+3c9+yqf9zsXGd9hvfq1fcYp3U39u579lU/7nYuM77De/Vq+4wGk
+0p8H/ywd9pVeDn8MD7Snwf/ACwd9pVeDn8MBxTdJenZFlBqTiLAHjMtqB05rRppdAcotPne
ALanZh+ym0PgNtBSRYDig2F9TpvjKotVN+TllS0owVt2IPCbEadKLfKI5qBT52my1VmKsHTt
1JXlYWXHFWTY2ypGp3AAbrfLF7JLlcwpPTLDrTimGuFhKphzOVqS4lSzccUBWYr6LWtrGT2F
6pM1BmeXNy0utE02/wAH2e1SnKlCCoK4pzFKObQG3PfYluoBpPBeF7UpvL3z2QLrzpObmGUX
Vv0tGf8A1MPMCUYm1SaZpChdwpURZIUFBXGyg5j0noGvPX6Y1+kk5SXFP015x8TD0o+pannU
JSsoLa02GUAb1J+iFNpLknKTjDLqZbbTC3WlMJByJNuQi19DycsZzCJtx+QdcDjRS8oOtsuF
ScuzXqTYX1t88aqIXODTTsqh853LtszRWgjQXJKgSL79Bb57xq2tXNqxBQnamppQcQtbMo62
2pxRTZ5RRlXZOlxlOvJfSOAYZqRccVwxLRKsi1JcUdulRIcWRyLykAb7FA1tEniR2dElkl9s
0VsruqXbLitpYZU7tAbq103DURytztZUp0TLa2Ww5ZS22i4pvtrBIy6g2R3XbHXmk5VNJOcR
NItWDak4h1D88l0FS1JzOEBS9m4lLhypHGBWjeVEZAb6CNqsJTrdUW9KmWbbISll0PLzywBz
KsLWObjA6/nE63MSC5qtuTrjQbLTZcQnOlu5QkqSMwuLXIKr6qtbcOXQX6yl2WW6qZzbErsm
W4pcIFm1ADQXG86i51ETWa/TCQwrOSVSpzjM0ES8uy2FoQrcsA57EpJVnJFzcdrreOmrUmoT
9TU5sJVDMupDksoPEFawpClFYyaE5coNzYa63sPq5muN8HIQV7VxZUFN2CLLslOiSbZbm5I3
b+SNte2q51CJLhaZpLalIWkL2faqASNMtybXvusOiLqNaNVheorcdKJliWVMv8KW6i61MLzL
OVIIAV2/babibRM4Upb1Go6ZJ91lzI66pGxbyJShS1KSLXO4H/3fEY6idDqjJondiDeUSrOO
Pxb5r6gdv22m/oiTw7w7/neuLTqFmYzJzuBQsUJ0TbckG4/3vCMrmiMrmkrHDXpEVCmrYLSH
jmQsNrdU2FFKgocZOo1G/wDcY7ojXmJhdTm7PTKWnJVISUqsEqurtdNDbl37uiLMtTNI+Xpd
U4VKpnmpaYl2EqXtOEHOpwpUAFXTxglJCQSbnUnmj4mjzMtNPzDpa2DaZlTZSolS9stKyCLa
Zctt5v0R0Sco6qYknnhMoWzJBTqypeqyALEXsSOMSLb7R8esuozpb4UkIYUle1SvK4dCCm4y
2G7Tfc80S01KPWPaWe8Fd/AYp9S90k5+zWP8IYuFY9pZ7wV38Bin1L3STn7NY/whjTS7/wBM
cU/s9X8ou+CfcbRvAGP4aY83qaUnqkVIkAlMq+Qeb1kx6Rgn3G0bwBj+GmAjOqt7iZz+z+NM
fmP/AIvf+8T/AIEx9xj9OdVb3Ezn9n8aY/Mf/F7/AN4n/AmPuMBSqFM4faoBRUCnhJUFXS2d
qlQcTqk5SLZM29QHJlvYnorNZo8xV+FvKRN7RlIUlDKloaWCbhO0IUU63BJJ1tuAvHU+mSL1
MlnVrbSpxwB2YcfCUsnPbIUbyCnjXHP0GJHEMjRRWyqYUzKsONJU2229kUg3N0r2bS05h0Aa
WOpJgPr1ZpREuC8yQ4w1LLU1LlK2UbHIvObcYhYQpNie05Nx7epjMMzvVuw3NsG/CKjLuOCx
GVwkZx9a5+QiOOSkKS3RspbllKmlNNtTTr6Scym3CbJ3pCXAhJJ0I3747Opk3Lp6t2G3JPIJ
d+oy7yEINw2FEEo6MpJT80B+4xuEfY+Aiw1EfYBCEIBCEIBCEIBCEIBCEIBCEIBCEIBCEIBC
EIBCEIBCEIBCEIBCEIBCEIBCEIBCEIBCEIBCEIBCEIBCEIBCEIBCEICvzXsp39M/fFC6sHsC
leHf6S4vs17Kd/TP3xQurB7ApXh3+kuAs3U39u579lU/7nYuM77De/Vq+4xTupv7dz37Kp/3
OxcZ32G9+rV9xgNJ9pT4P/lg77Sq8HP4YH2lPg/+WDvtKrwc/hgI6pVfg0nLLZE1bTMBLuWV
puuEEjo6Y0YYqlRn26k5NqDKG1p2KnWlJSgZbnVQSVAc5trfkiVmJ0yctLEJzBQAVa5IFt9h
qenojiplYRW26gy5IFxDCko2bg/LBSbi6VAW+fksYvZmWhdanpdpTjobWGUpOUoKS6FFeVX9
XRINtd5+b65VZ9t/ItbZZYVd55CE5iCEEWQTe3HI0vyRmzVJBgIWaeGRLhSVKShJ2JJULJtv
BKTqICpSTcxLSnW5pt1LhIQrIlLR4puDa1yFjd0xx/Vzv26JiquGbHB9GkbLMlxpSVLzuFHL
Yi1r7tY3yE86qXmXJwJuy+tFmEKVoCLaC5J15o+T83LtT7QclQ6tvKdrYEtZ1FKbX11ItpG2
mzQfVMIMsZZba+Mk2N7gEEkaXsdR/tG469W469Wmp1USS2QlpThebKkJNwScyQBaxP53Nybo
45fE21ZRMKkyiXUsIKy6MyeIFqJFtwBPLybo6aw5Itz0uJ9kvbZC0cdOZtCRZSiRa2pCflsL
QNQozEoSSwhpCgkoDJBSogi2W1wbAjdyERJmb6pMzfVzDEqQUgyrxzuKsACbIARroDqc6TY2
5dY7WJ56apBm1bKTzDMlS1bQJTzndr0fJGPDaW4Wy6loHaEpztG6VA5bm44p5Nbc0ZOPSs5S
AqXkxNy6wChpbYQkjeDZQAty3hF+SL8ox2tz8vLl15LWZBDSm1IKSVFvPnOun6Py6xtRUp7h
yW3Vo2DLoZdcQlN3FFQA4t7ga2uL6/JH1mq08BDjVPCAUBlo5EgkkA7PoHGGu7fGUnUJJ2oy
8o1INNuMpNs2VOxN1ApTpr2p3ckT9WYn2nIQhHR2I56m6WJB51Luy2aCsryhVgNTod8dEapx
aESrinGlPJCSS2lOYq6LQlJ6OCWmZ9EzJMTOwWp2WWtwpBSS4Mu7mHG6YTUy+qZnpZwNhpEs
laMt81yVA3+r/wC8hNRExMSoMkVNzDBcDhUklCSkE3G/lA03kiMpuZbccnZdLKkuNS6VFwpA
Cgc1gOXSx6NfljMMx/F57WPaWe8Fd/AYp9S90k5+zWP8IYuFY9pZ7wV38Bin1L3STn7NY/wh
jTaz1L/uPU/BX/4Rj0fBPuNo3gDH8NMecVL/ALj1PwV/+EY9HwT7jaN4Ax/DTARnVW9xM5/Z
/GmPz9/xP0Jus9Vh9xD2wEvJtcJUpSd2W6CnMUi54w1UO1+n9A9Vb3Ezn9n8aYpXVT6muHcR
YymK1WKvXKbNJZYS1wGYbQlzt0jLmTooWVvO49MB+ZHMGpbJa645320F10IZugIC1p4qr3Ur
iXAsAb2vG13C8kRlYceAWGVB1yyVIQZcOrKkkgC5Ol1AW3E749sZ6hmBS5ml8Q4tLYsGn0Kb
yuKslaUoOS5PGBHJflvG2V6jWHVEg1rFaHHHFuLUp9ozCXEOFlAB2dwVcblAsN5teA8QquDG
pJDYMyohAcLziWySoJzqulJI/NCdCd99bRnK0pvCVdl6g1VJsTFPKJwqZlw2pLYeDd0lRNl6
3sUkdMe20nqNYQBaqL1dxShQKlXmVNuJS5qcpu3faZeNbp33jbUOoHg+YM1N1Ov4sS6EoU+l
4thQC3CALbPUZkk6abjAeX1zqxY5Zk5WbpmKaklh9bqQHwypdkrskkZB+aR0XBj9WdTKoTVW
6neH6hUXlPzU1TmHnnVAArWpAJOnTHiz3USwHMSrTc1WMUS7Us2UtJdQy1cqyqCblGqiHEHX
ugCRYgeq0WvUjC+EJWn0xE/Oy9Lk0MNrKBxylBsgqGmYhJvbS4+SAusI4aNUeuMu6tTQZcae
WytvNmsUn91xY/P88d0AhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEA
hCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEBX5r2U7+mfvihdWD2BSvDv9JcX2a9lO/pn74oXVg9
gUrw7/SXAWbqb+3c9+yqf9zsXGd9hvfq1fcYp3U39u579lU/7nYuM77De/Vq+4wGk+0p8H/y
wd9pVeDn8MD7Snwf/LB32lV4OfwwHJMU+kKlZZucp8s4F5QkFgHjWjTJGiIkqizTFN09LRyz
LjCQ2UKtvvaxNtL682+Nk3SROSTKHqlMtgJFrhog6brKRaNdMofWeQnes7yJiZesUcJyhtKg
LJFm0iw5dBF7I1MihviXbM+HUut2yKUEhwJKrZgEixHGtu3HfaAdozjLSeuLzwmnCFAEkvWy
iygE6ADJrYaEa668jmE5qZl1svOsNJmkpMypKlLUFpKzmF0jNmK7m9rWsL8m1zDU49MmcWqV
bnHF6vNleaXSEoTdB/OJDYJChbXeQNc6YTTCRmmKTLTzDKnUSq3LEMt2SleVRUm4tpZVyN1z
prujOitSMxTnGmZrriyVkOF4JVdWh1skXvobnnBGlo5JuhTbk0FJnNuhwM7VyZAKxsnS4mwS
kAgk2N7WHPG+kUqcl5abTMTQZdmXNpeWJVkVYAkFwE623G4SNBuvCoXTDsn6XKzraW30cRKF
NhCdBY25PmEc6MPyCUthIUClJAKSE5uMFXsABe/MNxI5Y5cR4c68OS6lrbXsGVNhTybnMVtH
NpuNkKGndfLENVMEzs0+UszEshj10ItmTkQra+tgAbrLT+cALdruMNMGmJWR2gyD0wl5aSpa
VKXc2N7qzcouBfXS0cs1PUdymKkxVC01LlDS1IUMxA0A1Sbg5TewtoemPtPoRkMROzcq3Ksy
i28oQhIzXskADijKBlOgJBvuBuTyvUSqTM0udf4CmZQspZyuLKdkUrQE9qCmwXm0vc33C1lQ
aYbpg0VLj5enyVM5VrAVfKs5UhYAGqr5RYXFyNBeO6TkJZ5ph9p6YcaB2oSs2C13JzkECxuS
dLDo0EQqcIupYbl3OCTTEoFFhLwUNoVLQs5rdrYo0IvvuRpY2KkyzspTmWJh4vuITZSzfn3a
66btddIaYNMOqEIRVI+LSFJKTuItH2EBEoepsnU5eR4QpE0WAwylQPagFWhta9hc/JGupTsk
k1BUupyZm25cIWwzYqIBNrA2BN1a66aXtHXMSLj1U4UsoW2iWU020q9ipRBUT0WSkfOYjRR3
5WZemHHGiy2H1NBN8xLy0rUDyDKU2Fr3vyRKSoUaomov02ZYboFXzuMLQm7bdrlJA/P6Yq9Y
bUziqfacFlt09lChzEShB/fHrpAtHlOKfd3WfBk/4dcVU9Uv+49T8Ff/AIRj0fBPuNo3gDH8
NMecVL/uPU/BX/4Rj0fBPuNo3gDH8NMBGdVb3Ezn9n8aYm6nR5KpqQubbJcbBDa0rKVIuRqC
OXQRCdVb3Ezn9n8aYn3anIsTaZV6dlm5hZAS0t5IWbnSwJvAcysPUxTQb4NZIWVjKtQyqyhN
xrobAW5iL745/UvJpdb2a3Q0lCwoFalLUpTm0z575goKub9PJEypxCVZVLSFWKrE62G8/JBL
iFEBK0nMMwsb3HP8kBFNYXpLTYaTLrU0EkbNby1JJtbMbnVdjbNvtB/DNNfCQ8mZXokLvMue
u2UVJz68axJIvzxLwgIt7DtMeSQuXN73BC1XByoSCOYgNosei8YvYZpT0m5LOMLLblioh1QU
SElN73vexPz6xLQgOKjU8U2WW3tS6px1bq1kWJKjf/aO2EfCQBc6CA+wj4lQUkKSQQRcEbjH
xS0pKQpQBUbJBO87/wCRgMoQhAIQhAIRgp5pBWFOITkAUq6gMoO4nm3GM4BCMc6c+TMM9r5b
6257RlAIQj4hSVpCkKCkncQbgwH2EYlaQsIKgFKuQm+ptvjKAQhGCnmkvJaU4gOLBKUFQuoD
fYQGcIR8SpKioJUCUmygDuNr6/MRAfYQhAIR8SpKiQkg5TY2O4x9gEI1KmWEzSZZTzQfUnMl
orGYjnA32jbAIQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAV+a9lO/pn74oXVg9gUrw7/SX
F9mvZTv6Z++KF1YPYFK8O/0lwFm6m/t3Pfsqn/c7FxnfYb36tX3GKd1N/bue/ZVP+52LjO+w
3v1avuMBpPtKfB/8sHfaVXg5/DA+0p8H/wAsHfaVXg5/DAR89L1SZlJYyzUmFt2UCX1JI03g
5D9FtRpHNQqTN0qWqj9TSZhUypKyiWcLji7JsdcqdT0DdpHRUKk61KSypeXnzltmSmXcIOm4
5QT8/IY58OTtSeZqb1UW5KtpWksrmGlIS2nLxrZwCQOc8vRpFnozLUmSng2ngjcwhxSby5IU
kM6rK067hqkC++wt0fVSL5cbdal5jZocPB5dxu6LkIuVX1TqlRv8p5dc1VieYbKy4hwtpBQg
oALyVFdibbiAkGw6b9H1dTnEPAGZQuXYVx3EZA45cIIATYg2zEaWO7l38OTl9XRUG6iuaS5w
cKmAG9hs1q2aSFkruq2l02B013CNtBaqTEhMpmWhwjbrUjbPFQWDY3uBoN9haMZyqvCZBZu2
lAbIZebyl0rcKDv1AAF7jn10jOiTzxkXVTq1zDzWUr2IC0m4B4mUC4/fGoq2orU+YjfqbUuz
1vQ5tClRVskZxmFrJ3bjrvsNN/IeZ4Vt3a51OpS2y4lKEIQQ6tOUBRuNyrk203R21erOSSmQ
zLpcDjZcVtFlBACkJtax1usfJaOCcxQuX4ipZOZJW24UudqsZ91xqOIenXdCZi+plMXzlvnW
1ihramZaYfWt90JQApVrrXlUoJ1KQLH6I41yk5tdW5pxIUeEqN7vNZk5Rb845Qq4HSOXWWrE
w8y8wmWmG0uKULMFIJcAPGJJ1AA5uW3yRE9epzZX27fsfhOfIO2y5tl/7xrfTEmkyq26lSUy
1VGHnm3lrKbHaoFmm7KtZW/NqAQec814sURFFnJh6dfbm3EqUcy20NqSpKE5rAEgAhW7Q35e
aJeN41XJvCIrkQhCNNkctWUlNPdK2HphNhdpq+Zeu7Tk5+i8dUc1TdLMk4pLqWlaBKlW3k2A
F9LncL6XMSeiT0Q8nL5ZqRRspxK2WipT+yXaxCrNpvuA6ddE7zGSW6gmoVJycasy4ykNqD2Z
IspVgE2FjY3PSfkj7JVWYdmZIKeZVtGyl1AA4rmUnW2upB17Ww5bgxumX3lzk00mYQ80ho7R
CUgbJVxlF95Nrk36N14xFOeNOI7o8pxT7u6z4Mn/AA649WO6PKcU+7us+DJ/w646OqeqX/ce
p+Cv/wAIx6Pgn3G0bwBj+GmPOKl/3Hqfgr/8Ix6Pgn3G0bwBj+GmAjOqt7iZz+z+NMSVZpsz
NVBmYk1NNONy8w2l5QuULUE5Da2tim8RvVW9xM5/Z/GmN1ema+K4iWpSEIl1tDI6pJUkqObN
m4ptlsi3GTvOiuQOOVw7VJinhieeQCha3El1Wc6pCdmbEnIohSlam4IAtyd9ep9RnUhbAW2k
y4CmWn7cfaJJHICLAjeL9ERk1VMVqcLjMkppDjKnWmi1mUnRXFUAkjMLII4wuVEWVySZVWkU
ycZD7y5hMywhmYMunMW1bPOrKBlNsy+TS2t7QGjEtOrc3RJNmRVkmkMkLU1MFOV3KMpzK3pB
vqbndob3H2vSVUm687wFL6AJVoNTHCFIbbVmczjJuUVJyi/JcHSwjnM7iNucmWnUu8HbXkU8
lnOtLYWAFoAQApRRdRAz2PILWiPlnsULpLsqUziCZJ3I4WyHSS2opVqjRzPYZc2g/N5YCQfo
lYlWwmTmnkbNjivF9bhQchzpym5WVLIVfXd0AHlptLqs01OzjDc5LIyqEixMTjpKL2BNiRv4
1r8/JvjrbVX5ZKxLB5SJYpQyyplNnrzDqSVKtf8AJhs6EWvfcbRvpq65UMOThnApqcSc0uRd
CipICrHip0zgp3ajlO+A4KdhqsLUkz8xMFsOWS3w1Ys1d45TlIH5zX1bXNtck4crewQ6qbdM
5lKlq4Ysgr2iLG27RGcbra9Mb8TTM887/wAqqcYWZNt1ptlBK7l5G04nKUpy6dJ33jRM1XEq
JmWTKSz7ouQnaSxAfQVKCVLsniGwSTcotfcb6B9mKNVpSXVNKffWsEB4ImHFlbQbQChIF7XU
lWoFxe8bWqfVZnDEoZdtxmaamn3m0TL6itDag8GxmOtwFp05Pmj4Jmt8Ol3ZcTz7BZUlx52X
2akcdG5qwzEG43DignjaX5ROYg0dIns2z2antgcoOYHME7O/OO0J6SONAbKdQK23LvOvTDzb
6FtmUvNKXsk7VRXdIOUnKQLG/NfljnpkpX3GJ1yVZm0ofaUw2l+bWkhwoRd0ZxcDMFaAX16T
bc0/iOoKlG5hc5LuLVLuOKZl8iWAQnOCFJ1NyrlWNNQmwBlMPTc8up5Z/abRUm2XkFJGVzO4
AbDRJUka8mg3QENNyNclX5uZnBNPyziwDLsPrJdVdyxSU3KQLtm5IvltYcsjham12UnUv1OY
cdRwdKVNqcvc2RYG5NymyrnS97630VxyvIqb9Qp7DhlpZCmUNBaipzim6w1lsrjlFje9kKtv
jWufr8m83KLcU+5MLSw0tbKEkKUhCi5YWBSj1zT5Ab3vAb8R4enJ2cqE3JBgOvy7TADirBxA
K86VaaWzApPOOYmN9LptWal6glcwWnXWsjbinS5d7jXeA/NBuni8mXdz6apVKk3iV+Wkds8l
lllYl0y4UlQVtM5K+RQCU2Fxc899OCmzuJ5vhJddeZQy0tbS1SR9dVlbsDdAJsSvckE25bah
ucw7PPuommW3JVxplSWUqnlrKF7RJuTyjRRsbjXpIGEjQq4uqqdm3nAwDtNnwxWVToC7Gw1K
blG/m3C1owfqeKSkcFlnsvB1lCnWbqWoBepAbGtwjKDkvftTyTNbXVJGny6JV2YfXxto+lhK
1lWUlAygWAKrAm2g5RvgIikUavNrzz+1ebU6FJa4aUlC8qbuXF9AQri3N817cg55fDNeYlEy
0nMKlG0SzjaENvnikhYIzXuMyilQNri28WsZNCKhLUydmZkzq3l1NpwpSkqKWg43mCQkXKAk
K57i++MajP1Gdr0rKsS80aY/lS6Fyy0ZkFKsyicoKbEJGqkn+qb3gOiv4eXNCVTJFaEyrD4b
PCFpUHFBOQ3vc6jlPNEVMUTELkzOOOLdUlae0RNcVxQWMulwbBN76p5LDTX7Tk1ulS9LYlJV
1LTiAuZLpccUpeaywq4URZAuNU68p3GYoSJ9l90zaJlQU1eUDiyQhAJshf8AX1TcneLDekkh
zYpp1bnGJFMgsIW2gFam5gpCXAU63O8aK3gnXkvcbaxRJp7EBqMsm92EMnLMKbKgA/ppu4y2
zfo6I5jP1zgLak8LLhzFV5KxD2UWatb8mVZhnsNw43LHFNzmIxUXHW0TgIQUPIDBDbA2hsWy
EKzkgJ5FWzHdyBvTQ8TbdomqELDJSXgq4z2VdVuZRKDa2mW1xYX6pKizfWudYDTknwqoMvBs
TilrDQ2IWCsG+oQvS+425Y1V5FZmHKMUPTks840BMJlWszaV7WXJvcG1khy1zuBGuoMfX57E
5adk5dE92jzW1bleMtProSsFKLBVkoO8anRJuDAb38PYgTLNNys86m6U7S8wpZLnHGYEnQJB
bPzbjbXPrDW5mulc286JNTnrwRNqSHUhXFsBru3jQcluU99bmKo2SuQL+z4M2oO7AlajnNxY
IVZVrfmG3MOTKrv1lTUs7I8IayyS33G9glRW6CjKhW+2hXcJ38h0gI9nD9bVLDhU04t5ppwt
ETawA5ZoIJtvtkXvvv6THVhJFQTVZ1cyzObLI22px5awl1wKcKlpQrtRYoGmm7mjSw/Wn63I
GaM62wiYVtghiyUrKHBkvl4zYsghfOe25B9qklOyFRqU7SpZ5ThSxkUXFkAKUraqSk5hcCxs
Enk0MB0VGkTrr020y2gmYfTMonM4CmsoTxLb/wA0gEG1lH5DHO4crrTbTUnOOpbCUXvMKWoO
5AC5dRvoQTbW9+1Mdkmau7MSszOtTCWRs+FttlQzr1yqSmwNhdGYC1zycVQPJitVReenkSMx
PofbeCUIlklfrZlHMlwAbAuki+moGosDATdTk55ysNvMArbDQDZ4QpsMrBUVFSR2wUCkbjbL
yb4gJDD1eW3NKm33kq2LhlkmdVxXyluyiAd2ZKiLlW/psOyamcSy1URKsJVMy6XgkTDjQBcB
DZIOVFrDMvXi6ptc2sbZAIQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAV+a9lO/pn74oXVg9gUr
w7/SXF9mvZTv6Z++KF1YPYFK8O/0lwFm6m/t3Pfsqn/c7FxnfYb36tX3GKd1N/bue/ZVP+52
LjO+w3v1avuMBpPtKfB/8sHfaVXg5/DA+0p8H/ywd9pVeDn8MBzzNSRKS0sUKaUFABQBzEC2
8Ab4oXVL6pk3QcKzM/KyckQ3PsypE42paS2tClXUgG4PF0F+UX6L5My9MErLonJGWdSvKAFs
oKQbaXvoOb54p3VAwzK44w4ql4YNMknJGoNzDpfl/WV5Uq5Eiyt/yaGOnx6dUauiS87a6tmK
Q4y3KU7DedQJlkmVdRYWQpQVx+IeOnTW+vRf431ccScBMwzIYeW02M8u2iVUHFqusKIQXQRY
oVqm5sQbbxGDfULxI5KLnZXE1CaacJdS82y4Nne2bKSLjMUi/wAkameoZiB5/M1iGhsrS2dk
lUm62WANSpOZIKdVk3/rX5Bb3fuf+WxzJHq+4unUtuLpNBamCtxMuhyXduSlAUu5z8XikW33
6N8fKx/xAYtos0iUbpNBdWsqJS1LuiygohW5ZB1B3G/OAdI2s/8AD9illtafVXR1rILiXXEu
KW2CAlSkqOoBAAJ5hGM5/wAO+JpqYad9U9HaW2kqRsUOItc8ZQtzneY1+5X/AOn2cjH/ABF4
ym5WZmEUOhqTK22mZtzig3PKu/5u6OpXVuxsp7MvD2GQ8AlI2lwpSlleVCfXLkkoV/6dd9L/
AOHfEUnJvIartGf4S4FuqdQ4tLicqha1uUqJvfkHTfbMdQHGL80mYXiOihaHUOpyyywApJWR
oBu9cVp8nNCf2O+VfzKyRlL/AOIHElaWT1sw7wtuxaS5Kum3GSLlefi6kW33OmlxHanq4YnW
2hbdPw4pp531i8o6Ct66t4z8XVCuNqd2mpt8kP8AhzxLIyK5Zit0MFTgdDxYc2iVDdZXRvA5
zG8/8P8Ai25CMQURCQPW0JllgNK146dNFcZWvT8lpP7HfL+5WSPrX/ENiikLbUim0F5T4CnH
G2VZMwAuApLpzEXtrY7tLERH/wDyhxX8EUT6jvpxKTv/AA14km2GWV16iobauQlphaQpRsCo
2G8gD6I5P/i1XvjBSvs3PNG8f2Guf9z7Ob/5Q4r+CKJ9R304f/KHFfwRRPqO+nHT/wDFqvfG
ClfZueaH/wAWq98YKV9m55o1fAf5Z9nN/wDKHFfwRRPqO+nG+Q/4kcWVSaRJik4fCXdFqdQ7
kSnlKuPuA1Mciv8AhyqKVOJOJqXdBAIDDxJ39rxeMNDqL2sY66X/AMPFelZ//puLqay+E6La
S8kKGlwFWsd4uL8ojM5cBXL+6XLtf6veKGmJx4U7DilSb3BVHgzoFs2W2Yr03Xta1hqb2Bl8
C9Vuu4ixPISM5T6GymeKEzK5aXWlxKVtqcRZRUc1wjW40038kPPdRDED/DDNYoobrrj5TMOJ
lXC4skhwoJSm5G4kcgG8ARL4D6klYw9imnTszXqVNs08lxaGGXAp5KUFCRnIsrKF236X15I4
/JPCaJ09f1WJ5vV+SPKcU+7us+DJ/wAOuPVuSPKcU+7us+DJ/wAOuPnuieqX/cep+Cv/AMIx
6Pgn3G0bwBj+GmPOKl/3Hqfgr/8ACMej4J9xtG8AY/hpgIzqre4mc/s/jTG2v4ndpVTmZdDM
s4hhhDuQukOrKtpaybdqMmp5iebXV1VvcTOf2fxpjqqtao1Lq7xnGVCcyJSpQbzEosop1voC
bpG66iBzQHK9imbkypM3JsLWhPGaYcVmJKC4FAEdoBxSee8amMWzjhnPWacpuSslxxp9Sg4p
SilOXTnte56OmJDr9TZxwMuS8wFPtKLaikArayqVmBBuAch00NwNBoYj6RXJJEoxKU6lnYvT
IZd5UoStagkrJNySBe2vMTAaZbGdQmhdiRkgEqU0oqmCeOlLqiRlBFrMnlOqujWTarzxlJ58
puG1S62xcDKl1KOKTbUgk68xHyxivE8nIuTbc9KKlmpd5TLTgCcjxAToNRY8e2thv13xk5Xp
KVkJaoSsqpcrPTCzMLBBLeRpZUo62VbYgcW+g0vpARstjCdl5MLnmpaYWGVKHBybuKClaW/N
sE635ib8kZyWIalUavJtN7OXaW6hLqFJBKgEzBUUnXRRaTv3CJhVUlGZN2b63PJfaeTLLlw2
jahbik2Te+WxzpPbW11ji9WNJaS8htleaVOzKElsBNlZCCc1kBKrjjEA8l7wHLUsYvSzsw11
tVnZeWwl3NpmTdSt40GzyqBtYk25Lx002uTy6bV5hzZPuSkyW20myABe2p5bb+c7uWPsvipL
zrjTtLmEFL5RtOIpGUu7JKjxr3J0tb90dHX1ExMyTDFNeXLT61p2qwkJUjIpWcC+oOW1jr0a
iA4TjFaWg6JZp5ARYoQshalZCvOAR+TFiknnvvtr9TiqcLjpErKuNSpbS8tt1RLpW4WwW9LE
acp33HTHVIYgl1PqQ/T3GFNPqls6QgpQ3ti02TY3AUpNrAaW1AGsb5iuSMlPOyPB3AtlKMqU
hAzklIQlKSQTqoC9soN9RYwHBQcTztYnJdlqRaZStKnXFOrNwgbM2SB+d65Y3sNOnT7P4mfY
qDstKycupxT6ZdGdwpKVZ0JzrAGiTn057dOmw4rkmHVNtU2dJQpSV7NDYCXLLUtJOYagNrJO
7TebiOqkYgplWqDzEnxnUpzFdk8YJVY7jcWUbWUBzi++A4cQ4gm6TOlr1hajKoUlCjlTnuvM
bm2lk8pAiOpuM5l0sOvybT5edWUFne20pYARfuhcE84A54mm8SU2dlnHHJZ0pS0t4pWhCjlQ
U3uATZXHHFNiNb2jmlcUyfBGX5umusPrIWEgNgWVmTnCiQADkI1IJ0FtRAb0VeoKpFNmRLSQ
mqk4hITtFZG0qQpYubXUQBbcN/JHCcYvzDkqzIMSannpZL7ud8kNcVxRSQBe/rdtbbzza9ac
XSb9TYkaewqZWZvg6yFIGQALClb9LKTaxsTe4BEZVjEEtTGp4ykgp59kLtZKUpddCQpSb3vc
A3JOh11vAfJ7EMwkyXA2GyucYaWhLrlkpK1pGthc2B+f98RknjGdUJpx5uSKUKUpLYcIUEob
bKkDTValKJSOYHmicn6uuVmkMCVbWpCGC4SbZS48GwB8nHPzDnhUavT5OtMU9xgGZfUnKsIS
QlWuUn87kOoFhz6wHNU6xUZfFSadK8CW2821kS6pQUgkPqUrQaizQFucxyJxps2i7MsyyEGX
XMBe3sEWQVBtRI0WLajk0j61iVwTCZ6bakWZJMmJhxdlF1AvlKAd3b8u6N5xBKzCZXgsow6i
cdIbzlNkvJWEqKrXBGuigTc2F7qEBFt4ynkSqHnEMzFnnlKbljmXkQpwbNQtoo2Tb9ExZcN1
VdVkC682lpxK1I4p0Xa3GHRr+6JBDLSFFSW0JUo3JCQCTH1tptpKUttoQlIskJSAAOaAqC6l
WZOfcQ1P8MCZx1nJNoQlIQhkOb0IBveJHDmJl1ipLY4GplvZlaVKOosUjXnvmuLcg6Yn8ib3
yp+iPiGm0LUpCEpUoAKIFibbrwFUVi6dcCEy0rJqW42X7qeVZtAQpWRVh+UGWxHJcfPuomKH
5uYlpZ2XCnJt1amlC9tkFOZibC105Up6SpPPFlSy2nNlbQMxKjZI1J3mNaJNhE2ZlLfrpRkz
XOib3sBuFzvtvsL7hAVycxi5KTb7LtPUAy+tgulRCcyQXDyXtsrKvbebdMY0/GLz6kMuSbZe
cmODN7NzMFrBQVbr5bIXm1P5qr2i1lKTvSDy7vmjnTT5VL7TyWUpUykpbA0Sm++yd1+S9r20
gIWu4ocpk3MNplm3EsptlUshajkK81rdoLWJ5/kjKiV52qYon5Vp2TVJS7QDYbXmWpYUQVXG
ltwPMQOeJ5TSFLzqQkqylNyNbHePkj41LstFJaabRlTlGVIFhzfJAbI+WGa9hci14+wgEIQg
EIQgEIQgEIQgEIQgEIQgEIQgEIQgEIQgK/Neynf0z98ULqwewKV4d/pLi+zXsp39M/fFC6sH
sCleHf6S4CzdTf27nv2VT/udi4zvsN79Wr7jFO6m/t3Pfsqn/c7FxnfYb36tX3GA0n2lPg/+
WDvtKrwc/hgfaU+D/wCWDvtKrwc/hgOKapLMzJsJmKhNtcXT15OvF1FlAg6RrkMPycvJTstI
zbi+FKSl9alpJCQALDKAEnLpu5bxlOylUmpOX4OuSC0WUCStJGm8EX/3jgp1Fq1Mp1ULTjTk
9PKSG1oUVbM2ylaiqxNrlXzWEOyTFpdukFEq/LiZcUhbiXkFzjKQsEKN+cXANvljTP0ydn0o
W/MSyXEBQCUIOUgqQbXOv5vNyxxS0nWqfhybkJZLW3ZUDKrQSUlskEpGY3zJGYC/9WORqTxO
82FqnJppwbNDWqcqUkrzFSTclQGS9zyaa3jOmE0w7mMNOsshvbMKAasriq4ygQRvJIAsOXk1
B5S8MOOk7aaSsKQAoFOlwAnLlGmWwvbn5I5VDEalbWZeclA6guE50FuVQQrMlR5VJ4lj0Hkv
GDb2KJ4yU40Aw1MLKy12wbF0gX3cUoCla31V8kNEJt4rc2lKEBKEhKRoABYCMo4MOy8zL0eW
TPvPvTSm0qeL6gpQWQMw0FrXvoI7402QhCAQhCAQhCAhZmlTsyt1112XDxWNk4jOkoRxhYa6
Gyt/Lc9FvtKoXW2YKmXEFsC2qTmcOnbc9rafL9MzCM6YZ0R1RFRoqprb5XEAOOhzIpJt2mU3
sb9Okam6OZATLqXUlCkqJITZThUQbr5NLG1ucxrqMvtsUS60yE0jYoKzOoSDn4igGwb3SNbn
TU5ekxzMSM0zVJp91haBZ8uvkizwUtJZG+5ypBGva7hvhpi7NEXbYd0eU4p93dZ8GT/h1x6s
d0eU4p93dZ8GT/h1xppPVL/uPU/BX/4Rj0fBPuNo3gDH8NMecVL/ALj1PwV/+EY9HwT7jaN4
Ax/DTARnVW9xM5/Z/GmJ2ZpUjNvLdmZVp1xYSlSlDUhK8yR8ytYguqt7iZz+z+NMTr9Vp8tO
ok5idl25ldillbgCiCSBp0kGA53sN0l5taFygstRUcri0kXBFgQbhNlK4o01OmsfUYdpTbjC
25NCDLqC28qlABQJIJF7Ei5te9rm0d0zNS8qnNMvNtAgm61BOgFz9ABMbEKStAUggpIuCOWA
j1UCmKmJh8yo2kwSXFZ1dsbcYa8VXFTqLHQc0bHqPIvyrEu8wFtMKzoSpajrYg3141wpV73v
c3vHbCA42KVJsyol0M3bDiXeOpSiVpIIUSTckEDeeQRg5RJBZeOyWkvm6i28tFtbnLYjLc6m
1r8t474QEbL0Cly+02MmhAcKSUhSrDKrMLC+gBF7C2sZN0OnNPoebl8rjbu1QQtXFNiLDXRN
lK4u7U6RIQgI9FCpyZnbiW9c2qntVqIKicxNr2PG4wG4G5FjrGU1R5GbmFPzLJcWpOXjOKsn
dqBewVoOMLHTfHdCAj0UKmoTlEojnJJJJOVSbk31NlqFzvuY2ydMk5J1bkszsyoZbBSiAOgE
2F95ta51MdcICJdwxSHQoOSpXmJzFTzhKhpxSc1ynijinTQaR9ThulIllsIlSltw3UEurFxr
xb37XjK4u7U6axKwgI/rFTtsHUy+VaXUupyuKAQoX3AGwGpuBobm4MZP0WnvvuvPSyFreTlX
cmx3XNr2uQACd5AAjuhAR8/RpWemFOzG0IW2ltaErKQrKsLSbixBSq5BB5TGHqepwfafDKy8
0QULW8tZzC+VRuo5iMxsTe26JOEBHy1DkGJREvsEuBLAlypepUkG+vSTrfnjNFHkEMrb4OlS
XEZFlaioqF76km97m9999d8dsIDFtAbTlTe3SSfvjKEIBCEIBCEIBCEIBCEIBCEIBCEIBCEI
BCEIBCEIBCEIBCEIBCEIBCEIBCEICvzXsp39M/fFC6sHsCleHf6S4vs17Kd/TP3xQurB7ApX
h3+kuAs3U39u579lU/7nYuM77De/Vq+4xTupv7dz37Kp/wBzsXGd9hvfq1fcYDSfaU+D/wCW
DvtKrwc/hgfaU+D/AOWDvtKrwc/hgI2ozs0iTllS0lPkptcIbuDpuIBvb7t/RHBS52tM06qz
U43MJO1b2IebIDaTYLUlJ1sm5Op1t0xKTlal5OVliiZllAgBQ2iSbW5NQP8A3njipeKlTUvU
H1MNlEtMMtICVi5DhSLqtcXGa9h8m+L2Tu1VGrTbMqmWoVQcq804vMFIQ04ptCRc3IypIKsi
ecBRPJGLlRmnpiZmpWrPtMcDZfQ08lvI2pa1pUCchItltckhJFzcAiJap1qTpc4xT0JQmYmO
KykjKjMb5Qba6kbwDbltpHDKYtYbl2VVlMrKrmVrShDTpXxUryFRzBOma2gBOvyxFd+FZ1U9
IOKcedeU24UFbhbVfQHRaOKoa7wBzEXBiWiJpVVEy9MSzcoG+BgpeCFAgLubBIA1BAvfTeBv
CgOVeMqYpKRKOKfcVfKkJIvxAu97btQm/PcckBYIRF0avS1VdSiWOa7IdzJ1SdbEBW42Nwek
GJSAQhCAQhCAQhCAQhENUa67Kz78qmTupCGdktbgAcU44UC9gSEg2ud++w01DXUJ9aMSMSkt
Ums+UrelVlASlvIqyj+cSVAWsRoFfLHIzU5mYqczLuvhaSJgLYyj1kIWlLZ0FxmBJ1JvyWjK
RxM3PVZDApyQpJLbjiibheVRyoJTZXa7rgkG9rCN5q/CZmYl+DJbQsOpbcCrqUWlhKswtpqr
TU8u6A0ndHlOKfd3WfBk/wCHXHqx3R5Tin3d1nwZP+HXAT1S/wC49T8Ff/hGPR8E+42jeAMf
w0x5xUv+49T8Ff8A4Rj0fBPuNo3gDH8NMBGdVb3Ezn9n8aY6avQJmeq0xNIm1JYdQyhcrmAQ
+lCllaV8UkXCtCDya6RzdVb3Ezn9n8aYtAgKM7gyqTbk5wt2VU2+hSSlTpUlayHBmtl0vmTv
Kjpv0EXlCQhISkWA0Aj7CAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQh
CAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQhCAQhCAr817Kd/TP3xQurB7ApXh3+kuL7
Neynf0z98ULqwewKV4d/pLgLN1N/bue/ZVP+52LjO+w3v1avuMU7qb+3c9+yqf8Ac7Fymklc
s6lIuSggD5oDQfaU+D/5YO+0qvBz+GMi0vrVsspz7HLl6ctrQcbWaUpoJOcslOXpy2tAc80u
TZk5cTbDS0Lyi60pypNtL33c3zxHGo0KepU+2hpaZZhxtLhlUEFayoFBQW9Sc1hccojveojE
1KtIdenkKSBqmZWDusRvjnVhWSFNmpRpx8CacbW6txxS1KyFJAvcEaJtpFRplZWhTDzEy47M
JfaeQ2Ezcw4hxTgJUgKSojMRmuAb6ERu4Lh53ZBD0reXK1JyTIuBmzLBsdRcgkHQaRz1rCDU
60yzJPiVaRmzpUlSyolSTmvmBJ4oHGJG7TQRyVXBG0pS2ZN1jbBpptIUwAlWRDideg7Qm3R0
3iKlmJqgykw2GJiXQ6iXzoKXblxtRUb7/XNUqPKb3PLrx8EwowmW0lG75GGgHCFJ2hUtCSL3
GbMoi/PH1WEUutTpemm9tObMqWhiwQUuFZyi9wDe1r855Y1SuDDLTLTyJ7OWXUuIDqVKHbBS
gRmsL20sBblvAdUs9h+k1OZalihqYYZbS8hGYhtJsEC24E6bhzGJZVRkkpzKnJYJ2uxuXU22
ncb+26N8RVSwwidnnpnhOQu20DdyLBA33/q/vjiYwWqXYSlmfIdSpIQ8sLUpLYBAGq7E663G
U9zAWuEIQCEIQCEIQCOOcpUpOLcW+2StxCUFaVlJASrMkgjcQo3BGsdkICADFClas3LpztPo
Fgcy8gXlJuTu2mXMbnjWuY+f9J4dOcEz8KyL1VmyXzDaZL8W+bLmty2vHRMUIuV9NTTMJCkp
0Cm7qHFKcua/aG+Ypte/LGo0Uyj782p8LbSl5TbeSxBdUFrzG+oukWsBYXveA5zujynFPu7r
Pgyf8OuLK5j1iafq1OkkOJqFPl1uOhcq6lLZykpOZXFN945xFTrDinsVT7rhzLcp7K1HnJlC
SfpgLLUv+49T8Ff/AIRj0fBPuNo3gDH8NMecVL/uPU/BX/4Rj0bBJHqNo3gDH8NMBG9Vb3Ez
n9n8aYkalUJ5qpmWlUsbPiDM4hSjdQcJOhGgyDTp5Ijuqt7iZz+z+NMd1VXJissszNOlptT9
hdKQt1Gu9SSO06b6RMknGcujXL1qYeaQSltkuBSgleYqXxiMqOkAAnQ7xu3xoTXqjLsMIfZb
fdUhtZcSnKFXSDk1UOMTfUfVjXUH5CUmJps0NhSWJhlsOplQUBK8lyo84zH90ca61R1lhxik
SgYUSpxTkuL5OKQRpvyqOnIRHPn5I+H5JSztVmmJGUeUvMol3aBSdNCQm+6w+cDTUjfGtnEU
2uUK1y7QUMytoLlGUKKL3vbttd9rcttYxneBJpMw8zRZVuaZfbYW0qXS5YrUjcEkZuKsG1xz
RolZympStE7RpbaNLIdIlUtlCOKAooJJFyoaXOmvLaLz8ptfJ2dDOJ3lS4KmGlPleVDSFElw
ALupO/S6d+o6TGldXm3nXGTPsoa2qv8Ammk2bCQlNrE30vfl3qSL62jrw+3IVKWQZmiykvMF
ht5SNkhQKVg2II6Uq06I7ZrDlHmUBLtOluKbhSEZFD5CLGFZTHVnLDOOUyh6fiGYZlc0w408
hcsHWnFKvdwketg2GYgEHdfW3IY6UVqoZ2tow0suNbYJbSoWFl8U33ni79N+6JCVw7R5VBSz
TZXU3KlNhSiekm5jb1mpfwdJ/Yp80Ixy8pGOflyLq0xwJDxYEslxfFmHx62lBuUqIvfcANba
qjhdrlRATM7AIbzKTsAg5hxUm6iSBYFRPJoN/NM9ZaX8HSf2KfNDrNTPg6T+xT5osxl5Wccv
KEmsTzbSWsssznU2SUqPbaKsoWJ04oOmbfv5+3rtNtVJuUmBL222yUpCTdZISRZJVcAZt4zb
tbDWO7rNTPg6T+xT5odZaX8HSf2KfNCsvJpy8uJM5PrxAtpp1lUsopCQpsnKkICjYg6klW/k
tyxG1vFNSkZmbYYpoc2DhaS6QrKVFG0SbDkyBdzz254sDdIpra0rbkJRKkm6SllIIP0R2RqI
mOrWMTHVTK3iKrysjMN55NmZSzmzpbVdIKM+2AKvyae0N+XW43RJUDEE1UqlNS77DTLbK7JW
SNbLKQLBRPGAzC4GhGh3xYYRWiEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEIQCEI
QCEIQCEIQCEIQCEIQCEIQFfmvZTv6Z++KF1X/YFK8O/0lxfZr2U7+mfvihdV/wBg0rw//SXA
Z4cx1Q6HOPPuPTTi3ZSWl1ITJOkJLSVXOYDXVZ+jpib7L1B7mc8Te9GPLIQHqfZeoPcznib3
ow7L1B7mc8Te9GPLIQHqfZeoPcznib3ow7L1B7mc8Te9GPLIQHqfZeoPcznib3ow7L1B7mc8
Te9GPLIQHqfZeoPcznib3ow7L1B7mc8Te9GPLIQHqfZeoPcznib3ow7L1B7mc8Te9GPLIQHq
fZeoPcznib3ow7L1B7mc8Te9GPLIQHqfZeoPcznib3ow7L1B7mc8Te9GPLIQHqfZeoPcznib
3ow7L1B7mc8Te9GPLIQHqfZeoPcznib3ow7L1B7mc8Te9GPLIQHqfZeoPcznib3oxz1LqsUe
YkXmZZcyy6tJSlxynvLSk85SAL/SI80hATUziKXmJZ5hVbAS82ptRFBfvYgj3zpiOmJqXna/
PPyReXL8DQ0hbrSmyrJLKSTYjojmjbK9u5+oe/hqgJ7HE5MyONag9IvBl48TOWwuwKbHQ6bo
jRijEqQAmtkAaACTaAH7o7OqH7sJ/wDSH3RBQFgk6xVqlh+tt1SoGaQiXbUhJZSjKdqkX0j2
h6elpecSw+otLdsELUkhKzc2Tm3X6L35o8MovtHXvBmv4yY90dkJZ+bRMvN7RxvtM6iUpN94
Tuv02vBYruzVKS68+ZltW0Ula7p7ZSbWJ6RYfQI0ppMgm1pNjiqKhdF7E28w+iOyEC5cfWqR
4AqS4K1wdRuW7aE3uD8twPoEG6TINpZSiUZAZUVN8W9ieX/98w5o7IQLlxylKkpMIEnLpl0o
VmCWrpF8pTqBvFju3COyEIEzM9SEIQQhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAh
CEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEAhCEBXpu3Cnf0z98UTqv8AsGleH/6S4lMe
VmvU6vNNUWncOZedCHVcLDIl7i+YjKbp37tb8msU7GTrjyHlOuKWrr4gXUb/AP8ApiAhoQhA
IQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAIQhAI2yvbufqHv4ao1Rtle3c/UPfw1QEx1Q/
dhP/AKQ+6IKJ3qh+7Cf/AEh90QUBK0fSg1+3erf8VMemu4rmk1d2RQlvM3mUbpPa58o+fWPL
aXOSUvTapLz80ZXhbCG21hlbvGCwrtUi/J0RJOYuaXMLeNckgpaio2os1ym9u354D0LCteqF
Rw/Kzc08lTrucqIQANHFAfuAiT64zXvnkiPPcPY1w/SaLLSK5955TIUFOJkHkhRKirQWNt/P
Hd2RsO99THib3owF064zXvnkiHXGa988kRS+yNh3vqY8Te9GHZGw731MeJvejAXTrjNe+eSI
dcZr3zyRFL7I2He+pjxN70YdkbDvfUx4m96MBdOuM1755Ih1xmvfPJEUvsjYd76mPE3vRh2R
sO99THib3owF064zXvnkiHXGa988kRS+yNh3vqY8Te9GHZGw731MeJvejAXTrjNe+eSIdcZr
3zyRFL7I2He+pjxN70YdkbDvfUx4m96MBdOuM1755Ih1xmvfPJEUvsjYd76mPE3vRh2RsO99
THib3owF064zXvnkiHXGa988kRS+yNh3vqY8Te9GHZGw731MeJvejAXTrjNe+eSIdcZr3zyR
FL7I2He+pjxN70YdkbDvfUx4m96MBdOuM1755Ih1xmvfPJEUvsjYd76mPE3vRh2RsO99THib
3owF064zXvnkiHXGa988kRS+yNh3vqY8Te9GHZGw731MeJvejAXTrjNe+eSIdcZr3zyRFL7I
2He+pjxN70YdkbDvfUx4m96MBdOuM1755Ih1xmvfPJEUvsjYd76mPE3vRh2RsO99THib3owF
064zXvnkiHXGa988kRS+yNh3vqY8Te9GHZGw731MeJvejAXTrjNe+eSIdcZr3zyRFL7I2He+
pjxN70YdkbDvfUx4m96MBdOuM1755Ih1xmvfPJEUvsjYd76mPE3vRh2RsO99THib3owF064z
XvnkiHXGa988kRS+yNh3vqY8Te9GHZGw731MeJvejAXTrjNe+eSIdcZr3zyRFL7I2He+pjxN
70YdkbDvfUx4m96MBdOuM1755Ih1xmvfPJEUvsjYd76mPE3vRh2RsO99THib3owF064zXvnk
iHXGa988kRS+yNh3vqY8Te9GHZGw731MeJvejAXTrjNe+eSIdcZr3zyRFL7I2He+pjxN70Yd
kbDvfUx4m96MBdOuM1755Ih1xmvfPJEUvsjYd76mPE3vRh2RsO99THib3owF064zXvnkiHXG
a988kRS+yNh3vqY8Te9GHZGw731MeJvejAXTrjNe+eSIdcZr3zyRFL7I2He+pjxN70YdkbDv
fUx4m96MBdE1CZKgC5vIHaiIYYvmzUFSobQVJRtCcpIy5rankiDX1RqBkVspt0OW4pXIvEA8
lwALiK8MWNC//XZOyiCR1lmtSN35/SYDvpksut0+WqU/PVNc1NtpdcLc44hOY8yQbAcwERmM
JOWlKJJcEW+5tatmccedU4VqDCk6KO8AADm0jdIV+gSlElqeKu+di0G1rFOeGewtu5ATv1vb
S/LEdier0uekJGTpky9MuIntssqlFtWTslJuSRbm5gNABYQEbCEIBCEIBCEIBCEIBCEIBCEI
BCEIBCEIBCEIBCEIBCEIBG2V7dz9Q9/DVGqNsr27n6h7+GqAtWNKBPz2JpyYl0MbJS7ArmEI
Og10JvER6lqp3Mp4416UXavlwT1RUx+WCHNnoCc1xbf02ittTOJJMMNFlqdCygrcWTdFwcwv
YXsRvIsL25oCN9S1VH5sr4416UPUvVe5lfHGvSielJ+ruyzyn5NLTiW0FAy2uT22hOpHNpyC
8aWOvLYQ66+8oqdmCpvKlQCLK2WlhbUJ0B5dTAQ/qXqvcyvjjXpQ9S9V7mV8ca9KJqpTtbYf
QuUlUPJLCczQ1AduokX000SL7he+sap2fxCwraS0mzMBbbN0EEBteUlwi2pF7C2/p01CK9S9
V7mV8ca9KHqWqvcyvjjXpRNYaqFXmS+3VZfZbJSkhZRa5zbr7laHeALWtrExnV3X7oCm+paq
9zK+ONelD1LVXuZXxxr0ouWdXdfuhnV3X7oCm+paq9zK+ONelD1LVXuZXxxr0ouWdXdfuhnV
3X7oCm+paq9zK+ONelD1LVXuZXxxr0ouWdXdfuhnV3X7oCm+paq9zK+ONelD1LVXuZXxxr0o
uWdXdfuhnV3X7oCm+paq9zK+ONelD1LVXuZXxxr0ouWdXdfuhnV3X7oCm+paq9zK+ONelD1L
VXuZXxxr0ouWdXdfuhnV3X7oCm+paq9zK+ONelH31K1a18ktY8vC2/Si451d1+6PiDqk6XAc
1t/WEBTvUtVe5lfHGvSh6lqr3Mr4416UXLOruv3Qzq7r90BTfUtVe5lfHGvSh6lqr3Mr4416
UXLOruv3Qzq7r90BTfUtVe5lfHGvSh6l6r3Mr4416UXMOG4udL80V+n1LEVg3MU0EISgFxZC
VKNiVHmPa205VpvuMBGepeq9zK+ONelD1LVXuZXxxr0o7XaviZyRUlNJLL5S564lGbLoMhCS
Qbk30O4WJvy2XOruv3QFN9S1V7mV8ca9KHqWqvcyvjjXpRcs6u6/dDOruv3QFN9S1V7mV8ca
9KHqWqvcyvjjXpRcs6u6/dH0LVca/ugKacK1YAEolhfdebb18qPnqWqvcyvjjXpRcGjZIVpf
ZI1t0mMs6u6/dAU31L1XuZXxxr0oepeq9zK+ONelFnrJm105wSTzjT10kKbbC1WzC4A0vcXH
zxHTlRxCw2jgtOae4jYOdRKkqKQVkkb7G6dB07oCJ9S1V7mV8ca9KHqXqvcyvjjXpRPSE/Vn
FuJqEkmXAQSgs+uFRF93INwIvvuOm3K9UqzKU6VUxKuzDjiyFiYb46brACVWtuBPGtY26bwE
X6lqr3Mr4416UPUvVe5lfHGvSiSFZxEVvK6yjZi+xTfjq35c2thfS+vF+eNtMn67MT0sJ+UT
KtWWXMiSQdDluTusbaW133tpARHqWqvcyvjjXpR9GFasTYIlieibaP8Ami451d1+6GYlaQTf
RX4TAU/1J1j3pjxpvzw9SdY96Y8ab88W+EBUPUnWPemPGm/PD1J1j3pjxpvzxb4QFQ9SdY96
Y8ab88PUnWPemPGm/PFvhAVD1J1j3pjxpvzw9SdY96Y8ab88W+EBUPUnWPemPGm/PD1J1j3p
jxpvzxb4QFQ9SdY96Y8ab88PUnWPemPGm/PFvhAVD1JVf3mX8ab88PUlV/eZfxpvzxb4QFQ9
SVX95l/Gm/PD1JVf3mX8ab88W+EBUPUlV/eZfxpvzw9SVX95l/Gm/PFvhAVD1JVf3mX8ab88
PUlV/eZfxpvzxb4QFQ9SVX95l/Gm/PD1JVf3mX8ab88W+EBUPUlV/eZfxpvzw9SVX95l/Gm/
PFvhAVD1JVf3mX8ab88PUlV/eZfxpvzxb4QFQ9SVX95l/Gm/PD1JVf3mX8ab88W+EBUPUlV/
eZfxpvzw9SVX95l/Gm/PFvhAVD1JVf3mX8ab88PUlV/eZfxpvzxap50sMl1DLjxS2VbJoAqX
u0F+WIGQrs25WWpdyXmXWn0JXmaZGybCt3GNibWIO/cbgRjLOMZiJ7szlETTj9SVX95l/Gm/
PD1JVf3mX8ab88WqamJVqmzUwubTLOSt1FDgHrnQOgDXp5Iiq/iNqkUZudVLPuuvICm5dKFF
R0B1sDYC8dMYnKagyyjGLlFepKr+8y/jTfnj4vDlSkmJiYmG2Q03LulRTMIUfyahuBvFhw/V
5euUpqelkPNJXopp5BQttQ3gg/fuMZ1sgUWeuQLyzo1PLkMTo0i6l1ScKOVGZWmouEKWbEMO
jS/ydEc/ZFwp3+79m95o8Sf/AC7n6R++MID3Dsi4U7/d+ze80OyLhTv937N7zR4fCA9w7IuF
O/3fs3vNDsi4U7/d+ze80eHwgPcOyLhTv937N7zQ7IuFO/3fs3vNHh8ID3Dsi4U7/d+ze80O
yLhTv937N7zR4fCA9w7IuFO/3fs3vNDsi4U7/d+ze80eHwgPcOyLhTv937N7zQ7IuFO/3fs3
vNHh8ID3Dsi4U7/d+ze80OyLhTv937N7zR4fCA9w7IuFO/3fs3vNDsi4U7/d+ze80eHwgPcO
yLhTv937N7zQ7IuFO/3fs3vNHh8ID3Dsi4U7/d+ze80feyNhWwAn1gAEaNO31NzraPDoQHuH
ZFwp3+79m95odkXCnf7v2b3mjw+EB7h2RcKd/u/ZveaHZFwp3+79m95o8PhAe4dkXCnf7v2b
3mh2RcKd/u/ZveaPD4QHuHZEwp3+79m95odkXCnf7v2b3mjw+EB7h2RcKd/u/ZveaHZFwp3+
79m95o8PhAe4dkXCnf7v2b3mh2RcKd/u/ZveaPD4QHuHZGwru4esAJCQA06NB80OyLhTv937
N7zR4fCA9w7IuFO/3fs3vNDsi4U7/d+ze80eHwgPcOyLhTv937N7zQ7IuFO/3fs3vNHh8ID3
Dsi4U7/d+ze80OyLhTv937N7zR4fCA9w7IuFO/3fs3vNAdUbCoNxPuXsQCWnTa/zR4fCA9w7
I2F/hFXi7now7I2F/hFXi7nox4fCA9w7I2F/hFXi7now7I2F/hFXi7nox4fCA9w7I2F/hFXi
7now7I2F/hFXi7nox4fCA9w7I2F/hFXi7now7I2F/hFXi7nox4fCA9w7I2F/hFXi7now7I2F
/hFXi7nox4fCA9w7I2F/hFXi7now7I2F/hFXi7nox4fCA9w7I2F/hFXi7now7I2F/hFXi7no
x4fCA9w7I2F/hFXi7now7I2F/hFXi7nox4fCA9w7I2F/hFXi7now7I2F/hFXi7nox4fCA9w7
I2F/hFXi7now7I2F/hFXi7nox4fCA9w7I2F/hFXi7now7I2F/hFXi7nox4fCA9w7I2F/hFXi
7now7I2F/hFXi7nox4fCA9w7I2F/hFXi7now7I2F/hFXi7nox4fCA9w7I2F/hFXi7now7I2F
/hFXi7nox4fCA9w7I2F/hFXi7now7I2F/hFXi7nox4fCA9wPVGwuSCairQW9juejGlOO8Hpm
DMJmkh43u4JVd9d/5vLaPFYQHtMxjrBsytKpmZQ6pBukrlFmx+rG8dUfDA3VJY//AOdzzR4f
CA9wPVHwwTrUln5ZdzzRGVbHdAmWZgipg+supbbDDnKhQ7nedPp5hr5FGC+0V+ifuMB//9k=
--Message-Boundary-7958

   ---- File information -----------
     File:  Redimensionnement de Ralf02.jpg
     Date:  29 Jun 2005, 15:04
     Size:  10549 bytes.
     Type:  JPEG-image

--Message-Boundary-7958

/9j/4QEaRXhpZgAASUkqAAgAAAAIABIBAwABAAAAAQAAABoBBQABAAAAbgAAABsBBQABAAAA
dgAAACgBAwABAAAAAgAAADEBAgAcAAAAfgAAADIBAgAUAAAAmgAAABMCAwABAAAAAQAAAGmH
BAABAAAArgAAAAAAAABIAAAAAQAAAEgAAAABAAAAQUNEIFN5c3RlbXMgRGlnaXRhbCBJbWFn
aW5nADIwMDU6MDY6MjkgMTU6MDQ6NDEABQAAkAcABAAAADAyMjCQkgIABAAAADM4MAACoAQA
AQAAAIACAAADoAQAAQAAACABAAAFoAQAAQAAAPAAAAAAAAAAAgABAAIABAAAAFI5OAACAAcA
BAAAADAxMDAAAAAAAAAAAP/AABEIASACgAMBIgACEQEDEQH/2wCEAAcEBQYFBAcGBQYHBwcI
ChELCgkJChUPEAwRGRYaGhgWGBgcHygiHB0mHhgYIy8jJikqLS0tGyExNDErNCgsLSsBCwsL
Dw0PHhERHkArJCtAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA
QEBAQEBAQP/EAJ8AAQEAAwEBAQEAAAAAAAAAAAAGBAUHAQMCCBAAAQMBBAYGBggFAwQBBQAA
AAECAwQFBhHREhchMVWTBxZSVJKUE0FRVnSxFCIyNDZhcrIVQnGBkSMkMyViZKEIRHOis8EB
AQEBAQEBAAAAAAAAAAAAAAABAgMFBBEBAAEDBQABAgcBAAAAAAAAAAECAxETFFFSkWEhMRIj
QUNTcdHw/9oADAMBAAIRAxEAPwDI6XL93yszpUZdu6tbTwsnhY9qTsboR71c5zl3NRExNX0g
X26Q7svppqS3KOupqlWtRsMDXyROVukiOTBMUciOVFRPUpq//kFa8li9My1cKYPbSRYORNqf
aRf6pgq4psx9qLgpvpbLr7DvJZ1vxOs59AyL61MxdBGyObhpqqquCrpORHLgjcURVwVVPtmI
t001VR/X0j685Z+6csrpM6UrUo3VVJVUqQNqUpfSTNghT0ypijE01TF2HqPNZnSslfZ9E5Vb
U2i9Y6WJ1LGjnuSRY3N2/ZVHNVFRcMN67NpP2peCxpqW2bEteO04UkvE+0EfBExXaKI9isVr
nJou+t+eHsPtL0oLURXhmms7Rrq6pmqrMlZIq/w986aE+C7FXSjwRPY5MUwU9GLNM/WLceMZ
+W7Z0l9Kr7dhsds0X06aBKhkSxQpjGsfpdLSxwRNBNLfuMW1ulzpJslsDq2tp2x1LFfDLHFF
JHIiLgui9uLVwVMFTHYaKhvrQRX5s62ZaWpSmprIZZ0jGaKvxSiWnVyYrhhiuOCruMmzb/UN
i3cdY1mRVzmss2sp4at6NZIk1Q+FXOwRVRrUbDhsVV+sv5YWbFMY/Ljwz8sqp6b7/U8zopLU
pVc3escUT2/5biinz16374nD5ZmR9rb6T7PrX2lUU1kytrEa9lkzPc3ClbNEyOfSRE2/ZcrM
NyvcplWn0sUElqw1tn0NRS+iWrkhjaxqLSulpliY1jlcv1WuVFwRGN+qio3EaVP8UGflr9et
++Jw+WZkNet++Jw+WZkQ0doytopaZ0VM9Jn6bppIWulRdm56ppJu9vrX2nQ7w3zsqK5llWTT
1dVPM+x6OFy0+joUMrKj0jpG7UX0ui3R9X2vtYbDddi3TMRpwmZ5ZFV0q9KNLj6aRURKOOuc
raRjkbA/R0JFw3NXSbv9qGt16374nD5ZmR+7Hv5ZtDdeGOeWskr/AKPNZsrWYo58CVEdRFI7
+VfremjVMVXB6riqYIbeTpWs227Zgiq6eaKCasa9ZKnQVkX/AFFs7Xuw24NgT0ezcmKJsVTn
pUx+3C5+WDSdMPSRV2bW19PWRPpaFGLUSJTx4R6btFuP9V2bD5Wh00dItnVklJaFWlNURLg+
Kaja1zdmO1FTZsUzrYv/AGLaF4aiz5qmpWz6iO0qaotSdiOerZXpJBoozFVbHJGxUwVMcV2N
THHHtTpVoLRbacrqGqjqK188q6eEiP8ASUscPo3fWRFaxzHKiua7Y7FEaoi1TP7UGflha9b9
8Th8szIa9b98Th8szIzLU6VaKtsiWg+h1ixOppKdGv0FRGrQNgYn9EmR0v8AdF3m1vX0lWFS
3pT6Oye14YqpszKhuho07fobocIMfY96P/l+tGnr+sjTo/igz8tDB04X/nmZDDaMT5JHI1rU
pmYqq7k3GTbfS/0k2Hak1nWrVx01XAqJJE6njVW4oipu2blQ1V5b/wAFfd+vs2z2VrJKuGgg
lqpFaj6lsDJUe6TBVXFyvZ612MTFfUfCvvhZdX0msvVJR1D4YamlmbRyNYqStjaxr0cuOCfY
2bF37cDcWaP1tx/2DPy3dZ0x9I9HRUdXU1kUcFdG6SnetPH/AKjWvVir/ZzVTb7D4S9N9/Ym
xudalKqSN0m6MMTlRMVTaibl2blwXcvrQ+7uk2yJWWfQ2rQ2jbln01G1kyVr2NklnjndLE7H
F31cHrGqY4qxy+skL83nW9L7MqJmP+lU9K6OqkciIksjp5ZVcmHq/wBRE/sKLFEz9bcGflZ1
fS10mUdmUVoVNSyOkr3PbTSupo8JVbo6WHr2aTf8mTbvSX0rWDTrPa720sX0mSk0n08Sp6Vn
227PZjv3Ezc289kUrLtU9rxyMjsWvq7RkcqKrZnKyNYo00dqYvhRqqqYJpIu1EU1NpXmS0Lm
MsupZI+tW157Rln2I13pI424YJ68WKvs2iLFGcfgjz+zPypNet++Jw+WZkNet++Jw+WZkc6B
22tnrHiZl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ
6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Z
l0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XX
rfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvi
cPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlm
ZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXr
fvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvic
PlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZ
HOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgN
rZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x
4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0
XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl0XXrfvicPlmZDXrfvicPlmZHOgNrZ6x4Zl/THRx
bF7L2XRgtqsvfNRummliSGCzIZETQVNuKqm/E2tuPvJZti1tdHfatldTU75kY6yKdEcrWquC
rpbNxE9Fd6KGx+iajgZW2Stotq53JS1le2nxarmbVXBVTcuGzbgbm0r52dX3OtaO0LQsSmq3
00zI4Ka021Gmis2bcG7VXFMMPmeDfqmm5VTERjPEf46R9mxty8FTYVouoLU6R6+OqY1rnMju
+2RERUxTa3FDCtO8V4WzXb/g19aisgt20W0aTS2TFH6NqqqK5ExxVUVMMFwMusvpZdHeK0p6
S1LIqYal0Stc21oo8FYzRVFRfz9ZNWpbtlLalylda1mudBeFamo9HWMkbCx0j34uduwRHJiu
4zRXM1RExHkf4q1mqLVgdUNn6Rpo3UsSTVCPsumRYo1xwe76+xuxdv5E9ee8NvUdrLY0t45b
Uoa+xKypc51JHAuyJ2jgrFXFF3mvvslgXntSKs61XegSjhT6KxzmP9LJpo5Unx+1F9VMGp61
Vd6IY167VobWvvTy0FdR1mhd6ubK6llR7Wu9G5VTLH1Epqmr6TEfaf0jj+h0y9t27Fta8FRP
adkUNZPpIxJJ4Gvdgm5MV/qTtJYdw6yf0NJZlgTSY4aMcDFXfh7PaWtsKjbZncu5Jcdn9iIs
ilrFseloqSW14KqNWukWqSZsLETS+xpJhvc1dFN+H5GIuVR9IlcM1bm3USZsK3fsdJXNV7WL
SsxVqKiKuGG7FU/yh7Hcy6skaSR3eshzF3OSlbgv/owm2DXOkgmjidSS08Ktb/v3yaUunCqv
9mCox+zamOGKH5bYduJVse+rcqNiwRyT/Z+q9FauO1UVVRccP7pgNSvmUxDYdSbre7tk+Vbk
Y1fdq5Vnoxa+x7Dp0kVUZ6SnYmkqb8NhvbMp1pLNpqd7nOfHE1r3Per1c7D6yq5dq4rjtNbe
BJm2nZ08MloxJE2fSkoadZXJpIxERfqOTDYv+BqV8yYh+I7mXUkibJHd6x3xuRFa9tKxUVF3
Ki4H66kXYxw6t2Vj8I3I1r7EtF1ayosmWrpotHCJZZlj0WqxyO043JpafpHK/FME/LEw6egt
K0oJls/00VM2VqJE6qe5FX0OCua5+G5+K4e13r3I1K+ZMQ3vUm63u7ZPlWZGJX3duRZzmNr7
JsKndIiqxJKdiK5EwxVNnqxT/JR07Hx08bJXrI9rGtc9d7lRExX+67TT242Vtu0s8c1qwRtp
ZI3Ps+n9I5Vc9ioi/UcibGqvt3DUr5kxD8dTrpekaz+AWNpOarmp9GZirUw27t21Nv5n76kX
X93LJ2f+I3I1lj2Nav0mkm9JJBBHE2NuDliVjWsVqt0XbU0nfX+z6/ywP3/BbX/hscKppPay
VsaJWOasUjkZoSquODtFUf8AVTtbsVUalfMmIZsdz7pSMV8dgWM5rVc1XJTMwRWqqOTd6lRU
X+h7Hcy6kiKsd3rIcjVVFVKVuxf8GHU2DasjZ6Zr41p6qV6yL9Ic1GNWSdy/VRNukkrMcMPs
r+QprEtWKOGNVx9Hg2FUrHYUuD0XSw/nTQTRw27vzGpXzJiGd1Juv7uWT5VuR4+5l1WMc993
rIa1qKqqtKzYib/Ufa7tnVlnuk+lSue2SNqqjpnSf6mnIrl27k0VjTZs+r+RsqyV8FJNNFG6
V8bHObG1FVXKibE2Iq7V9g1K+ZMQ0Fn3ZuXaLHus+xrDqWsXB6xU7F0Vwx27PYZHUm6+GPVy
ycPhG5GugitC06Bqvs6tZOjpHVLaiZ0CzyuYiNlR2CbGqn2fUmG8+lXYtsytnaydyTvY9Fq0
q3N9Iixta1qN/lVHIrtLD5jUr5kxDNW5N1033csnyrch1Jut7u2T5VmR9bJsupobTlkWV60z
vTIjHzufg30qLCiIu7Bmkn99uJtnLotVyoq4Jjg1MV/sNSvmTEJynuxcupqJYKexrDllh/5G
Mp2KrNuG3Z7T7PubdSNyNfd+x2ucqIiLSsxVf8GkrFr5LGp6OGitKCSzqZYYZ/RSx+mVdBuK
Lo4x7EVVxxXFfXvM9bvWilotq6ZyUjsXxsb9Kc9aeLT0kbj/ADpjio1K+ZMQzupF1/dyyfKN
yHUm6/u5ZO3/AMVuRgLYNqSU6tY59K1sblZElc93+t6FWo9XIu5ZNF2Hq0ccPUbWyaKtp7Xr
pql2lDNtYrplcqrjju3IiJs3Ivq2ptGpXzJiHx6k3W93bJ8qzI+aXRuiquRLBsZVbJ6NcKZm
x+xdFdm/an+UN5UvfFTyyRR+lkYxzmxr/OqJiibPauwkLLs+02VDY6WqrVdO5stVLUUL6VEe
1yqrkX+dV01RU9jW+walfMmIbVtzbqOmdE279jrIxEVzEpWYtRccFVMPXgv+D9dSbre7tk+V
Zkah93rXVj3RN9EjvQpJF9MWRZVZHI1zsVVMPruR2GP/AL2FbQxyQ0UEU8iyysia18jlxV7k
REVV3b1GpXzJiE9bN0btUllVE8N3rHSSNqK1VpGKm9E9n5n7qLtXdfNUfwu4diVUEEz4Vlkc
kXpHtXByMTBccF2Kq6KY4pjsXDa3jXCwqtU9TEX/APJDS19iwfTpaa2IbdkZTzy/RZrNmma1
8TpHPRHJG5ER6K5yYuwRdi44Y4NSvmTENZeuz7sQXUZaVkXXsaGR8rWf6tIiujXSwc1WrsRy
Kiopsq2xLqQMkWC5135I6dY4pqipckEfpXo3CNFwXF31m4pgiJpNTHFcDR29aFPaFy61zEfD
V/xRX1lHKiNfSyOdsYqezRRMHbnbVQ2N7LuJakUtFXrabad1UyspqihSV6N0nRvkjeyNyKq4
sXRcqbNLYqKm1qV8yYh5b9lXXiupWV1DdKx6Wrgf6J8c1MjnQyI5EcipuXfinqVFRfWeusy7
cENFGlyLFq5paGKplk9E5u1ydlkbvWi+xNxh19VSPuxeKmiZVU1VFPHp0dY7GaONEayNznYr
p6TW46eK7Vwx2bcu0WNkdZzXMbIv8HpV0VYj+1twWN/yT+p0tVVV1xTNU+kvxLSXSlsa0nR3
RsGmtClglkSLQ9Lo6LlYjlRURU2oi4KibFRduOzY3Zuzdesu7RVdbdixJJpolfI/6MjE+25N
ybETBENQ9qR0dqMRqM/6TMuijEb/ADx+r0bPkv8AX1G3orOmtTo+s2np5vRu9Fpqxy4MmRJH
/Ud+S/NExRU2EuVV0VTT+KSMPu27ty6myPp9Ddew5oXxLJFI2D6r027U/LYYFxbu3cta7NLW
V92LFmqJXvRXNpEYmxUw2Ifu6NjVlmWHWVFa5YVqqfFKJdL/AGyor8U2ucmK6SfZwTYfi6Vn
y2p0ZU9HT1S0kkkiqkyaX1cHscv2VRcFRFTYqbzGpXzJiGyo7t3JrqZZ6O7NhTRo5zNJsO5z
VVHIvsVFTDA111bs3dtOw4ququ7Y3pXySoujRsRMGyvanq9iIfS4liVtnRy1FY36Ijmuj+jM
VcJMHLhI7FVVMU3bccHLiu5EzrgfhWm/+5P/APukGpXzJiHvUm63u7ZPlWZDqTdb3dsnyrMj
eAalfMmIaPqTdb3dsnyrMh1Jut7u2T5VmRvANSvmTENH1Jut7u2T5VmQ6k3W93bJ8qzI3gGp
XzJiGj6k3W93bJ8qzIdSbre7tk+VZkbwDUr5kxDR9Sbre7tk+VZkOpN1vd2yfKsyN4BqV8yY
ho+pN1vd2yfKsyHUm63u7ZPlWZG8A1K+ZMQ0fUm63u7ZPlWZDqTdb3dsnyrMjeAalfMmIaPq
Tdb3dsnyrMh1Jut7u2T5VmRvANSvmTENH1Jut7u2T5VmQ6k3W93bJ8qzI3gGpXzJiGj6k3W9
3bJ8qzIdSbre7tk+VZkbwDUr5kxDR9Sbre7tk+VZkOpN1vd2yfKsyN4BqV8yYho+pN1vd2yf
KsyHUm63u7ZPlWZG8A1K+ZMQ0fUm63u7ZPlWZDqTdb3dsnyrMjeAalfMmIaPqTdb3dsnyrMh
1Jut7u2T5VmRvANSvmTENH1Jut7u2T5VmQ6k3W93bJ8qzI3gGpXzJiGj6k3W93bJ8qzIdSbr
e7tk+VZkbwDUr5kxDR9Sbre7tk+VZkOpN1vd2yfKsyN4BqV8yYho+pV1vd2yPKsyHUq63u7Z
HlWZG8A1K+ZMQ0fUq63u7ZHlWZDqVdb3dsjyrMjeAalfMmIaPqVdb3dsjyrMjGtm7Vh2XYFq
VNm2PZ9JO2hnRJYYGsciLG5FTFEKU1t6/wALWr8FN+xwm5XP3lcLZLBbaVVVTuqHRqkytwRi
LuRD9dUI++P5aZm0sbdV/Eu+SGeYE51RZ3x/LTMdUWd8fy0zKMATnVFnfH8tMx1Rj74/lpmU
YAnOqMffH8tMz1bpMVcVrZFX840zKIATnVFnfH8tMx1Rj74/lpmUYAnOqMffH8tMx1RZ3x/L
TMowBOdUWd8fy0zHVFnfH8tMyjAE51RZ3x/LTMdUY++P5aZlGAJzqjGn/wBY/lpmOqLO+P5a
ZlGAJzqizvj+WmY6os74/lpmUYAnEujGm6sfy0zHVFnfH8tMyjAE51RZ3x/LTMdUWd8fy0zK
MATnVGPvj+WmY6oR98fy0zKMATnVFnfH8tMx1RZ3x/LTMowBLWhciKtoZqZ9fKxsrcFc2NMU
24+v+h8pLjSPkc91u1uLlVy/6Ufr/sVwAg7W6Laa1ad8NXa9Y5Hua5zkijRyq3diqJtw3f3M
3qI9cMbdrdiImyKPIrwBDWl0ZQWlTSwVVsVjmytRjnJDGjsEXFExwxwx24B/RjSywwxVFoyT
tgjbHH6WkhfotRERETFq+wuQBCO6LaJaWenjtCWGOojWOT0NLDGrkX82tQ+1D0dpRUUNLT25
XNihboMT0Ue7FV9n5qWoAj5Lgukjcx9uVytcmCp6OPan+DHsno0jsqzo6KktyubDEqq1PRx4
7d/qLgASHUR+GH8druVHke2PcCnsqz2UcFfM6NjnuRXxpj9ZyuXd+blK4ATnVFnfH8tMx1RZ
3x/LTMowBOdUWd8fy0zHVFnfH8tMyjAE51RZ3x/LTMdUWd8fy0zKMATnVFnfH8tMx1RZ3x/L
TMowBOdUWd8fy0zHVFnfH8tMyjAE51RZ3x/LTMdUWd8fy0zKMATnVFnfH8tMx1RZ3x/LTMow
BOdUWd8fy0zHVFnfH8tMyjAE51RZ3x/LTMdUWd8fy0zKMATnVFnfH8tMx1RZ3x/LTMowBOdU
Wd8fy0zHVFnfH8tMyjAE51RZ3x/LTMdUWd8fy0zKMATnVFnfH8tMx1RZ3x/LTMowBOdUWd8f
y0zHVFnfH8tMyjAE51RZ3x/LTMdUWd8fy0zKMATnVFnfH8tMx1RZ3x/LTMowBOdUWd8fy0zH
VFnfH8tMyjAE51RZ3x/LTMdUWd8fy0zKMATnVFnfH8tMx1RZ3x/LTMowBCVlHS0lS6CSonVz
ezEi/wD9Ji/1bBS2PLSQeklWspatque1G6CMge/2rjjhgfXpWoILw1MtA28y2Sxr2rN9FljR
71TBURVVcW4Km5PXv3E9e2Vn8OooHWnHaM8VHXJJOis0n/7V/wBZWtXBFA7fY26r+Jd8kM8w
LG3VfxLvkhngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHPrfoLPZa86JZdlriukquoIXKqrtVVV
W4quJF3/AIKeGKnWno6KnVaavxWnpo4lX/av3q1qYlbbrrwT2vUvp7AifEj1axzrTjarkTYi
4aOzH2EvfGzrbns2Srr7Mgo6ejpKtz3JWslV2nA9iIiIietQOw2Nuq/iXfJDPMCxt1X8S75I
Z4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoPFAnp/vEn6l+ZP9IX4Itf4SX9ilBP94k/UvzJ/pC/
BFr/AAkv7FAs7G3VfxLvkhnmBY26r+Jd8kM8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4p6FAnZ/
vEn6l+ZP9IX4Itf4SX9ilBP94k/UvzJ/pC/BFr/CS/sUCzsbdV/Eu+SGeYFjbqv4l3yQzwAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAHinp4oE9P8AeJP1L8yf6QvwRa/wkv7FKCf7xJ+pfmT/AEhf
gi1/hJf2KBZ2Nuq/iXfJDPMCxt1X8S75IZ4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAlb9Wdb1e9yWRI70X0OSNjWT+iVs7nNRJFXZtazT0f8AuX+ioFUCfsSzbRZa
s1Vaj5nSenlWJWVH+mkKoiMZo+tURMVx/mVV27CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAB4p6FAnZ/vEn6l+ZP9IX4Itf4SX9ilBP8AeJP1L8yf6QvwRa/wkv7FAs7G
3VfxLvkhnmBY26r+Jd8kM8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB4p6eKBPT/88n6l+ZP9IX4I
tf4SX9ilBP8AeJP1L8yf6QvwRa/wkv7FAs7G3VfxLvkhnmBY26r+Jd8kM8AAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAUHigT0/wDzyfqX5k/0hfgi1/hJf2KUE/3iT9S/Mn+kL8EWv8JL+xQLOxt1
X8S75IZ5gWNuq/iXfJDPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFB4oE9P94k/UvzJ/pC/BFr/C
S/sUoJ/vEn6l+ZP9IX4Itf4SX9igWdjbqv4l3yQzzAsbdV/Eu+SGeAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAA8U9PFAnp/vEn6l+ZP8ASF+CLX+El/YpQT/eJP1L8yf6QvwRa/wkv7FAs7G3VfxL
vkhnmBY26r+Jd8kM8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUHigT0/3iT9S/Mn+kL8EWv8JL+x
Sgn+8SfqX5k/0hfgi1/hJf2KBZ2Nuq/iXfJDPMCxt1X8S75IZ4AAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAADxT0KBOz/8APJ+pfmT/AEhfgi1/hJf2KUE/3iT9S/Mn+kL8EWv8JL+xQLOxt1X8S75I
Z5gWNuq/iXfJDPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFB4oE9P94k/UvzJ/pC/BFr/CS/sUoJ
/wDnk/UvzJ/pC/BFr/CS/sUCzsbdV/Eu+SGeYFjbqv4l3yQzwAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAHinoUCdn+8SfqX5k/wBIX4Itf4SX9ilBP94k/UvzJ/pC/BFr/CS/sUCzsbdV/Eu+SGeY
Fjbqv4l3yQzwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACWtCsgp62SN6TOci4roMRU27faSPSVb
sbbCloIYXu+m01Ujnv8Aq6CMge/Ym3HHDAxuliz7JvHVzUkl4P4ZUwSJozUtckb2Ls0muTST
Hdhgu5f/AHP3qfZ0Vn0VFZlXFOyCjrmoiVKTPw+iv2uXFVVfzUDpV5LVfY9LV1aPlbHFLLJI
kUem5Wta1djcMVXfsQiZL6Vt5+iya2I3zUrauJ6tYjk0mtSXRT6yIm1UTbh7TJvV0h2Y20Xx
WbWWLVxNlc/0zrWZFtVETBE0V3Yb8SWtK89FUWDUWXR9XaSOZFwRlsx6LVV+kq4Iz1riv9wO
rWjalZHaNSxk7ka2Z6ImCbERy/kayy6+qqb9ytmqJHNbZKKjdLBEX0+/BNmP5klV9IsE9XNM
n8CT0kjn4fxyPZiuPYPpdq+dksvLPaNqWlY9JGtClMxsVosmVzvS6eOxEwTADp+m/tu8SjTf
23eJSX1i3S49Qc9uY1i3S49Qc9uYFPpv7bvEp7pv7bvEpL6xbpceoOe3MaxbpceoOe3MCn03
9t3iUab+27xKTGsW6XHqDntzGsW6XHqDntzAp9N/bd4lPdN/bd4lJfWLdLj1Bz25jWLdLj1B
z25gU+m/tu8Snum/tu8SkvrFulx6g57cxrFulx6g57cwKjTf23eJTzTf23eJSY1i3S49Qc9u
Y1i3S49Qc9uYFRpv7bvEp5pv7bvEpMaxbpceoOe3MaxbpceoOe3MCn039t3iUab+27xKTGsW
6XHqDntzGsW6XHqDntzAp9N/bd4lGm/tu8SkxrFulx6g57cxrFulx6g57cwKfTf23eJRpv7b
vEpMaxbpceoOe3MaxbpceoOe3MCo039t3iUab+27xKS+sW6XHqDntzGsW6XHqDntzAp9N/bd
4lPdN/bd4lJfWLdLj1Bz25jWLdLj1Bz25gU+m/tu8SjTf23eJSY1i3S49Qc9uY1i3S49Qc9u
YFPpv7bvEp7pv7bvEpL6xbpceoOe3MaxbpceoOe3MCn039t3iU9039t3iUl9Yt0uPUHPbmNY
t0uPUHPbmBUab+27xKeab+27xKTGsW6XHqDntzGsW6XHqDntzAqNN/bd4lPNN/bd4lJjWLdL
j1Bz25jWLdLj1Bz25gU+m/tu8SjTf23eJSY1i3S49Qc9uY1i3S49Qc9uYFPpv7bvEo039t3i
UmNYt0uPUHPbmNYt0uPUHPbmBT6b+27xKNN/bd4lJjWLdLj1Bz25jWLdLj1Bz25gVGm/tu8S
jTf23eJSX1i3S49Qc9uY1i3S49Qc9uYFPpv7bvEp7pv7bvEpL6xbpceoOe3MaxbpceoOe3MC
n039t3iUab+27xKTGsW6XHqDntzGsW6XHqDntzAp9N/bd4lPdN/bd4lJfWLdLj1Bz25jWLdL
j1Bz25gU+m/tu8Snum/tu8SkvrFulx6g57cxrFulx6g57cwKjTf23eJTzTf23eJSY1i3S49Q
c9uY1i3S49Qc9uYFRpv7bvEp5pv7bvEpMaxbpceoOe3MaxbpceoOe3MCn039t3iUab+27xKT
GsW6XHqDntzGsW6XHqDntzAp9N/bd4lGm/tu8SkxrFulx6g57cxrFulx6g57cwKfTf23eJRp
v7bvEpMaxbpceoOe3MaxbpceoOe3MCo039t3iUab+27xKS+sW6XHqDntzGsW6XHqDntzAp9N
/bd4lPdN/bd4lJfWLdLj1Bz25jWLdLj1Bz25gU+m/tu8SjTf23eJSY1i3S49Qc9uY1i3S49Q
c9uYFPpv7bvEp7pv7bvEpL6xbpceoOe3MaxbpceoOe3MCn039t3iU9039t3iUl9Yt0uPUHPb
mNYt0uPUHPbmBUab+27xKeab+27xKTGsW6XHqDntzGsW6XHqDntzAobQqZoKJ0kUjmu02pjv
2bfaRV3ukCpvCy3aaNaiCeyqmalkXR+o7R0ka5rsN6omKpvT+mCnt4+kixfozIrKrrJq1e7F
6y2iyHQw3YYouOOP9sCbZfOihpZYKZl3oGyrI5yMtqNEV78Vc5fqbVVVxVQN9dizqGa7Vlyz
UNHJI+jhc976djnOVWNVVVVTFVX2qeXlpqGmsG1WU1FTsnSgmc50MDG+jasbsNJUTZj6k9e/
cYVkXosOhu/QUaW/Y6VMNPFC5y1LXNYrWIjnIn82GGxNmPrMG2bw2E6xLQay2rMle+kqEa36
WjnaTmKmP/c93rcu5MGogH//2Q==

\start
Date: Wed, 29 Jun 2005 14:38:45 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [AxiomGraphics] 

The 'draw' command works only under an X-Windows environment (unix/linux).  The
command is described in Chapter 7 of the AxiomBook.  The syntax of the command is::
    
    draw(f(x), x=a..b, options)

\begin{axiom}
draw(sin(x), x=a..b)
\end{axiom}

\start
Date: Wed, 29 Jun 2005 15:05:19 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [AxiomGraphics] 

The 'draw' command works only under an X-Windows environment (unix/linux).
Work is underway to create a new user interface (AxiomUI) that among other
things will allow graphics to be viewed under other operating systems.  If
you're interested in graphics, please pitch in!

The command is described in Chapter 7 of the AxiomBook.  The syntax of the
command is::

++added:
    draw(f(x,y), x=a..b, y=c..d, options)

The points in such a graph can be constructed as follows:

\begin{axiom}
lineSegments := [[point [sin(x*%pi/10)$DoubleFloat, x*%pi/10], point [sin((x+1)*%pi/10)$DoubleFloat, (x+1)*%pi/10]] for x in 0..20]
lineColors := [dark blue() for i in 1..20]
pointColors  := [dark blue() for i in 1..20]
lineSize := [6 for i in 1..20]
makeGraphImage(lineSegments, lineColors, pointColors, lineSize)
\end{axiom}

\start
Date: Wed, 29 Jun 2005 13:33:35 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: point-sets and help systems

Page, Bill [Bill Page] wrote:
> > How can I find this out for myself, aside from poring through
> > the code/axiom book?
> >
> > For comparison, it took about 5 minutes to construct this
> > in maxima:
> >
> >    makelist(float([x*%pi/100,sin(x*%pi/100)]),x,0,200);
> 
> What part of the maxima user interface contributed to making it
> possible for you to find the necessary information? 

'describe(makelist)'.  In particular, there is no equivalent in axiom to
answer the question "what does this function/class/domain *do*"?

However the user is presented with several opportunities which might
seem to lead to an answer by the right combination of )what op, )display
op, etc. that are totally opaque.

Can someone replace the default help page for the next release?
How about:

    There are no library operations named $input.

    For help start the hyperdoc browser with )hyperdoc, read the axiom
    book at /usr/share/axiom-doc/book.pdf or visit the mathaction wiki
    http://page.axiom-developer.org/zope/mathaction/

---

    You have specified incorrect arguments to the function $input.
    Possible alternatives are:
        ... list ...

    For help start the hyperdoc browser with )hyperdoc, read the axiom
    book at /usr/share/axiom-doc/book.pdf or visit the mathaction wiki
    http://page.axiom-developer.org/zope/mathaction/

Do not tell the user that )what op (etc) even exist, as they are not
helpful to new users.  Advanced users will find them.

> > After 3 hours I finally figured out how to do it in axiom. 
> > (I don't give up that easily...)
> >
> >    [[sin(i*%pi/100)$Float, i*%pi/100] for i in 1..200]
> 
> You should get an "A" for that solution, but I'll give you an "B"
> (: You'll get the rest of your mark when you add a paragraph to
> the wiki site explaining how it works. See something near:
> 
> http://page.axiom-developer.org/zope/mathaction/Streams

It's not a stream...I replaced AxiomGraphics instead.

However the code in chapter 7 of the axiom book also
fails...'makeGraphImage' fails with an odd error claiming that the
function doesn't exist!  When it is coerced to a GRIMAGE (why must
'makeGraphImage' be coerced to a 'GraphImage'?!?) it fails with "index
out of range".

Also I seem to have triggered some output parsing bug on mathaction too:
    http://page.axiom-developer.org/zope/mathaction/AxiomGraphics

> from the Linux shell I do get hyperdoc right up front. You mean
> you also need a reminder from the Axiom command line?

Yes.  When I get an error I am given a hint as to how to fix it.  That
hint is totally useless except for experts.  I suspect there are 3 axiom
experts.  I suspect they're all on this list.  ;)

> I would be nice if typing
> 
>   )help
> 
> actually launched hyperdoc, instead of the other way around.

It does not seem possible to launch hyperdoc from the command line,
right?  I could not find how.

> > Would it be possible to hide all that and not present it to
> > the user as if it was a working help system?  The 3-hour wild
> > goose chase I just went on will deter 99% of users right off
> > the bat.
> 
> I agree with this. In fact I think this is one reason why the
> AxiomUI project should have such a high priority. Hyperdoc is
> not available for the Windows users of Axiom - where a lot of
> these sort of questions are most like to be asked - and even
> on Linux the old hyperdoc browser (useful though it is!) looks
> old, unapproachable and basically just ugly by today's standards.

Definitely.

> One thing that I always wanted to do but never found time was
> to extract just the HTML-able and LaTeX-able parts of the hyperdoc
> pages and make them available as essential static pages on the
> Axiom web site.

I was under the impression Kai was going to attempt this as part of his
AxiomUI project?

I think the contents of input/ could be imported to the mathaction wiki
with trivial transformation.  e.g. wrap text in \begin{axiom} and make
-- a wiki paragraph.  This, at least, would provide a searchable
database of working examples.  (though they are poorly commented)  My
lisp is poor but I could do it in perl or python in an hour.

The relevant info seems to be in browse.daase.  Also the hypertex format
seems to be relatively simple.  It shouldn't be too much work to convert
it to a wiki format so that it can be dumped on mathaction.  (or into a
tiddlywiki ;)

Rather than lauching hyperdoc we could launch a web browser...

> BTW, when you were spending your 3 hours learning this lesson,
> did you happen to think of doing a search on MathAction?

Of course, but there are multiple resources:
    )commands
    pamphlet documentation
    axiom book
    mathaction
which I tried in that order.  For a self-described "literate" system,
finding the answers to my questions in the first 2 resources (e.g. the
"literate" part) is woefully difficult.  We've got to fix that.

\start
Date: Wed, 29 Jun 2005 16:04:09 -0500
From: Tim Daly
To: Bob McElrath
Subject: hypertex standalone

Bob,

you can run hypertex standalone:

export AXIOM=/wherever/mnt/linux
export HTPATH=$AXIOM/doc/hypertex/pages
export PATH=$AXIOM/bin:$PATH
hypertex

\start
Date: Wed, 29 Jun 2005 16:38:15 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomGraphics] need to )expose GraphImage and	use same llist sizes

++added:
First we need this domain

)expose GraphImage
\end{axiom}

\begin{axiom}
lineSegments := [[point [sin(x*%pi/10)$DoubleFloat, _
                  x*%pi/10], point [sin((x+1)*%pi/10)$DoubleFloat, _
                 (x+1)*%pi/10]] for x in 1..10]
\end{axiom}
\begin{axiom}
lineColors := [light blue() for i in 1..10]
\end{axiom}
\begin{axiom}
pointColors  := [dark blue() for i in 1..10]
\end{axiom}
\begin{axiom}
lineSize := [6 for i in 1..10]
\end{axiom}
\begin{axiom}

\start
Date: Wed, 29 Jun 2005 16:41:26 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomGraphics] need to )expose GraphImage and	use same llist sizes

draw(sin(x), x=%pi/10..%pi)

\start
Date: Wed, 29 Jun 2005 15:49:26 -0700
From: Bob McElrath
To: list
Subject: examples for the wiki

The contents of src/input can be translated into wiki pages (thereby
enhancing our documentation and making more stuff searchable) with the
attached perl script.  Run it in the same directory as *.input.pamphlet.

Can we just dump them all on the wiki?

Hyperdoc will require a little more work.

--
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]

    "One of the best ways to get yourself a reputation as a dangerous citizen
    these days is to go about repeating the very phrases which our founding
    fathers used in the great struggle for independence." --Charles A. Beard

--RHdRtM27np9fZUoh

#!/usr/bin/perl 

my($inaxiom) = 0;

foreach my $file (<*.input.p=
amphlet>) {
    my @lines = `notangle $file`;
    $fname = $file;=

    $fname =~ s/\.input\.pamphlet//;
    print $fname . "\n";
    =
open(OUT, ">$fname.stxlatex");

    for($i=0;$i<=$#lines;$i++) {
=
        if($lines[$i] =~ m/^\s*--(.*)/g) {
            if($inaxiom) { p=
rint OUT "\\end{axiom}\n"; }
            print OUT $1 . "\n";
         =
   $inaxiom=0;
        }
        elsif ($lines[$i] !~ /^\s+$/) {
  =
          if(!$inaxiom) { print OUT "\\begin{axiom}\n"; }
            pri=
nt OUT $lines[$i];
            $inaxiom=1;
        } else {
       =
     print OUT $lines[$i];
        }
    }
    if($inaxiom) { print O=
UT "\\end{axiom}\n"; }
    close(OUT);
    $inaxiom=0;
}


\start
Date: Wed, 29 Jun 2005 17:44:37 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomGraphics] need to )expose GraphImage and	use same llist sizes

vp1:=draw(sin(x), x=%pi/10..%pi)

This command creates a "view port" and would normally (on linux for
example) also display the graph.

Although due to technical limitations of this system (no Xwindows
environment on the Web server) we are not yet able to display the
graph. But we can still extract extract the graph data from the view
port. Then for example we can display the list of data points that
would be plotted in the graph.

(Note: we disable LaTeX output typesetting in order to save
spage.)

\begin{axiom}
)set output tex off
)set output algebra on
g1:=getGraph(vp1,1)
pointLists(g1)
)set output algebra off
)set output tex on
\end{axiom}

Using lower level functions the points in such a graph can also
be constructed as follows:

??changed:
-makeGraphImage(lineSegments, lineColors, pointColors, lineSize)
g2:=makeGraphImage(lineSegments, lineColors, pointColors, lineSize)
)set output tex off
)set output algebra on
pointLists(g2)
)set output algebra off
)set output tex on

\start
Date: Wed, 29 Jun 2005 19:22:51 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: document, graphics

On Wednesday, June 29, 2005 5:00 AM I wrote:

> ...
> Maybe a little later we can play with HTML WYSIWYG gui editing
> interfaces such as provided by Mozilla and/or javascript like
> Kupu. I tried Kupu on the MathAction wiki but the embedded
> LaTeX really makes this impossible. With a lot of work in
> might be possible to use Kupu and jsMath together but for now
> basic text-based editing seems like the best place to start.

Kupu,

http://kupu.oscom.org/

works quite well in the Zope environment (sans LaTeX) but is a
fairly big java app. The following javascript on the other hand
makes use of the "rich text" editing features that are already
built-in to Mozilla and reverts to more complex java code if
this is not possible:

http://www.dynamicdrive.com/dynamicindex16/richtexteditor/index.htm

"Description:  Replace a form's textarea field(s) with a custom one
that supports WYSIWYG formatting with this Rich Text Editor script.
It allows the user to easily format the entered content, such as make
it bold, change its size, colors etc. The resulting source code is
then submitted as regular text for further processing by your form
script.

This script works in IE5+/Mozilla 1.3+/Mozilla Firebird/Firefox
0.6.1+/Netscape 7.1+. In Mozilla, it relies on the Mozilla Rich
Text Editing API. Browsers that aren't supported should see just
a regular form textarea."

---------


The output of the textarea is just XHTML code. Click the little
checkbox at the bottom of the edit area to see the raw code and
edit it if you want. For example this could be easily plugged
into the TiddlyWiki.

After seeing what you and Kai have been able to do with a little
(and then a little more :) javascript, I am starting to be quite
turned-on by what is possible with very short and simple javascripts.
There are several other interesting javascript/DHTML gadgets at
this site:

http://www.dynamicdrive.com/

\start
Date: Wed, 29 Jun 2005 19:03:08 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: point-sets and help systems

On Wednesday, June 29, 2005 4:34 PM Bob McElrath wrote:

> ...
> Bill Page wrote: 
>> What part of the maxima user interface contributed to making
>> it possible for you to find the necessary information? 
>
> 'describe(makelist)'.  In particular, there is no equivalent in
> axiom to answer the question "what does this function/class/domain
> *do*"?

Yes, you are right. I would have thought that at least the
command

  )display op ...

would include the ++ documentation lines from the SPAD files.
Maybe these are even in the database (daase) files? 

> However the user is presented with several opportunities which
> might seem to lead to an answer by the right combination of
> )what op, )display op, etc. that are totally opaque.

Well, I would agree with "marginally useful" maybe. :)

> Can someone replace the default help page for the next release?
> How about:

    There are no library operations named $input.

    For help start the hyperdoc browser with )hyperdoc, read the axiom
    book at /usr/share/axiom-doc/book.pdf or visit the mathaction wiki
    http://page.axiom-developer.org/zope/mathaction/

---

    You have specified incorrect arguments to the function $input.
    Possible alternatives are:
        ... list ...

    For help start the hyperdoc browser with )hyperdoc, read the axiom
    book at /usr/share/axiom-doc/book.pdf or visit the mathaction wiki
    http://page.axiom-developer.org/zope/mathaction/

---

That sounds very good to me. Can you send Tim a patch file?

> Do not tell the user that )what op (etc) even exist, as they are
> not helpful to new users.  Advanced users will find them.

Agreed.

>> ... See something near:
>> 
>> http://page.axiom-developer.org/zope/mathaction/Streams
>
>It's not a stream...I replaced AxiomGraphics instead.
>

You are right. Thanks.

> However the code in chapter 7 of the axiom book also fails...
> 'makeGraphImage' fails with an odd error claiming that the
> function doesn't exist!

The book neglected to tell you that you could first make the
GRIMAGE domain available by

  )expose GraphImage

> When it is coerced to a GRIMAGE (why must 'makeGraphImage' be
> coerced to a 'GraphImage'?!?) it fails with "index out of range".

In the example on page 306:

  g := makeGraphImage(llp,lpc,lc,lsize)$GRIMAGE

$GRIMAGE is not a "coercion" ( :: ) it is a "direct package call"
( $ ). This says specifically to call the function named
makeGraphImage defined in the domain GraphImage (abbrev GRIMAGE)

The error message "index out of range" was caused by a different
problem. In your original example one of the lists contained
21 elements (0..20) while the others contained 20 ( 1..20).
I have changed them all to just 10 points for brevity.

> Also I seem to have triggered some output parsing bug on mathaction
> too:
>    http://page.axiom-developer.org/zope/mathaction/AxiomGraphics

Yes, there seemed to be some problem with the insertion of
images, perhaps because you had two identical images on the
same page. I vaguely recall see that that causes an error in
the version of LatexWiki we are using. I change "dark blue()"
to "light blue" for the line segments just so the output would
be slightly different. That caused the problem to disappear.
You might also have run across a problem trying to LaTeX rather
large expressions. Sometimes (rarely) that causes an incomplete
png image to be generated and they are hard to get rid of except
by deleting the file the hard way.

> ...
>> It would be nice if typing
>> 
>>   )help
>> 
>> actually launched hyperdoc, instead of the other way around.
>
> It does not seem possible to launch hyperdoc from the command
> line, right?  I could not find how.

Tim's the guy to ask. I think that it is possible. But normally
all of the Axiom components include graphics, hyperdoc and Axiom
itself are launched by a master process called 'sman'. You could
try

  )sys axiom -ht -nogr

(or something similar to that) from the Axiom command line.

> ...
>> One thing that I always wanted to do but never found time was
>> to extract just the HTML-able and LaTeX-able parts of the hyperdoc
>> pages and make them available as essential static pages on the
>> Axiom web site.
>
> I was under the impression Kai was going to attempt this as
> part of his AxiomUI project?

Yes, I think so although it is a separable part of the project.

> I think the contents of input/ could be imported to the
> mathaction wiki with trivial transformation.  e.g. wrap text
> in \begin{axiom} and make -- a wiki paragraph.  This, at least,
> would provide a searchable database of working examples.

Yes, when I looked at this quickly I thought it should be possible
and then went on to other things ... :)

> (though they are poorly commented)  My lisp is poor but I could
> do it in perl or python in an hour.

If you would care to tackle this I (and a lot of other people)
would be eternally grateful to you! For one thing it would make
all of that documentation immediately available to the large
number of windows users.

> The relevant info seems to be in browse.daase.

Yes. Do you think you can extract it in a form that would
be navigable?

> Also the hypertex format seems to be relatively simple.  It
> shouldn't be too much work to convert it to a wiki format so
> that it can be dumped on mathaction.  (or into a tiddlywiki ;)

Yes. Excellent!

> Rather than lauching hyperdoc we could launch a web browser...

Yes. That's what I have been saying all along. :) :) :)

>> BTW, when you were spending your 3 hours learning this lesson,
>> did you happen to think of doing a search on MathAction?
>
> Of course, but there are multiple resources:
>    )commands
>    pamphlet documentation
>    axiom book
>    mathaction
> which I tried in that order.  For a self-described "literate"
> system, finding the answers to my questions in the first
> 2 resources (e.g. the "literate" part) is woefully difficult.
> We've got to fix that.

I agree. Perhaps there might be some tool that would make it
possible to search through all the multitude of dvi files,
i.e. to index them for searching? I know there is a way to do
that using Acrobat (the commercial package).

But really, in my opinion the more of this material that
we can get on the web site, the better.

\start
Date: Wed, 29 Jun 2005 16:17:22 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: point-sets and help systems

Page, Bill [Bill Page] wrote:
> That sounds very good to me. Can you send Tim a patch file?

Eventually.  That requires me to figure out the build system, and where
to put it.

Thanks to Tim's recent email for Kai describing how to get going on
that, I should be able to do it soon...

*poke* Tim should make a wiki page about using emacs/dvi for pamphlet
development.  ;)  (as outlined in his email to Kai)

\start
Date: Wed, 29 Jun 2005 18:17:11 -0500
From: Tim Daly
To: Bill Page
Subject: woeful documentation sources

Bill

you can get a lot of information in the databases from a 
stand alone C program called asq (i.e. ask):

export AXIOM=/wherever/mnt/linux
export PATH=$AXIOM/bin:$PATH
asq  <=== gives help string
asq Integer
asq -sh Integer

\start
Date: Thu, 30 Jun 2005 02:15:18 +0200
From: Michel Lavaud
To: Bill Page
Subject: re: converting sexps to XML

Hello Bill,

On 29 Jun 2005 at 6:55, Page, Bill wrote:

> > etc.. You have just to select the portion of document in your
> > favorite editor (Emacs, or any other editor, even Word), click on
> > the Display button of AA, and the selected portion is displayed in
> > the dvi viewing window. ... For illustrations, cf.
> >
> http://www.univ-orleans.fr/EXT/ASTEX/astex/doc/fr/nouv31a/html/nouv31.
> htm >
> 
> This sounds very similar to WhizzyTeX: "An Emacs minor mode for
> incremental viewing of LaTeX documents."

Thank you very much for pointing out this program, it seems very
interesting and I will test it. From your comments, it seems WhizzyTeX
is half way between the mode I described (I called partial
compilation) and a second mode (automatic compilation) that launches
compilation on the whole document every X seconds in the background
(i.e.  without intervention of the user ) iff the document has been
modified in the interval.  This third mode of WhizzyTeX seems to be
quite useful, according to your description, and it would be very nice
to add it to AA. From the technical point of view, the two programs
seem to be quite different : AsTeX Assistant is completely independent
of Emacs, and it can be used with other editors, and also with
mailers, spreadsheets, etc.  One of the motivations to write AA was to
ease the use of TeX under Windows, to help colleagues (i.e. teachers,
researchers and students) to switch from Word to TeX. This is why AA
has also many more possibilities I didn't describe in the preceding
message, in particular the ability to insert TeX commands in Word or
other editors, or in spreadshets, mailers, etc (cf the User's Manual
of AA)..

> I have seriously considered whether it would be worth hacking the
> Emacs code to run Axiom on the \begin{axiom} ... sections before it is
> passed to ADVI. I am sure this would be very cool for the average
> Emacs hacker. But there are just so many good options available to do
> what we want with Axiom these days, that I haven't looked at doing
> this more seriously. One idea that I had was to write macros for TeX
> to invoke Axiom and process the Axiom commands. This way it would be
> completely transparent to LaTeX users.

That sounds very interesting indeed, especially because Advi is a 
remarkable software.

\start
Date: Wed, 29 Jun 2005 17:26:58 -0700
From: Bob McElrath
To: Tim Daly
Subject: Re: woeful documentation sources

Since )help does not return anything useful, can we make )help call asq?

It looks like what we want is asq -doc

Asq is a C program that outputs lisp!

It looks like )what and )display read the .daase files, but no axiom
command reads browse.daase, where this documentation lives?  Is that
correct?

Tim Daly [Tim Daly] wrote:
> Bill
> 
> you can get a lot of information in the databases from a 
> stand alone C program called asq (i.e. ask):
> 
> export AXIOM=/wherever/mnt/linux
> export PATH=$AXIOM/bin:$PATH
> asq  <=== gives help string
> asq Integer
> asq -sh Integer

\start
Date: Thu, 30 Jun 2005 03:31:41 +0200
From: Michel Lavaud
To: Bob McElrath
Subject: re: converting sexps to XML

Hello Bob,

On 29 Jun 2005 at 12:25, Bob McElrath wrote:

> designed to do.  Since tex is a programming language I'm sure there is
> some combination of macros I could define in the preamble which would
> totally break enforcing your DOM.

Well, I'm not so sure, because TeX itself is used in the compilation,
so any correct set of macros in the preamble is treated correctly
(cf. the example proposed by Ralf yesterday). One exception I can
think of is a change of definition inside the text, not in the
preamble. This is the only "requirement" I can think of to ensure
that, in all cases, partial compilation will provide the same result
as complete compilation.  Automatic numberings are also incorrect, but
their exact values are irrelevant in the tuning process.
 
> On the other hand, XML is *not* a programming language, it is solely a
> data structure.  This conforms to the "principle of least power":

> TeX, lisp, and sexps are all turing-complete languages.  Therefore it
> is always possible to do *anything at all* in them.

Yes I agree that they can do anything at all. I would add that, as for
TeX, I wonder if the possibilities offered by TeX, in particular by
changing the catcode of characters and making use of \specials, are
not underestimated ? Indeed, although $AB$ means AB by default, it
could also mean anything else, for example "Bring coffee then Add
sugar in coffee", and be interpreted as such by the dvi viewer, if we
design it to drive a coffee machine :-) or, more difficult, it could
contain (in AB) and treat (in the dvi driver) a whole sequence of XML
tags ;-)

\start
Date: Thu, 30 Jun 2005 17:44:43 +0200
From: Michel Lavaud
To: list
Subject: Interactive Editing of MathML Markup Using TeX	Syntax

Hello,

The work of Luca Padovani, in particular a communication he gave at TUG 
Conference last year at Xanthi ("Interactive Editing of MathML Markup Usin=
g 
TeX Syntax") might be interesting for Axiom ? His interesting thesis (2003=
) is 
available online on his web page.

Cf also the EdiTeX program at 

http://helm.cs.unibo.it/software/editex/

\start
Date: Thu, 30 Jun 2005 18:17:35 +0200
From: Kai Kaminski
To: Tim Daly
Subject: Re: cross-platform api

Tim Daly wrote:

>See http://www.libsdl.org/index.php
>
I know libsdl, but it seems to be meant for games and doesn't include 
any widgets. It would only give us canvasses and OpenGL widgets, but any 
widget set does that too. I like wxWidgets (www.wxwidgets.org). If we 
are only looking for a rendering library we should also consider Cairo 
(http://www.cairographics.org/introduction).

\start
Date: Thu, 30 Jun 2005 18:38:53 -0400
From: William Sit
To: Michel Lavaud
Subject: Re: Dispaying special characters on MathAction

Michel Lavaud wrote:
> 
> Hello,
> 
> When displaying the page
> 
> http://page.axiom-developer.org/zope/mathaction/MathematicalAlgorithms
> 
> under Firefox, I obtain the line 1 :
> 
> math=B7e=B7mat=B7i=B7cal (math'?-mat'i-k?l)
> 
> with u accent on the a and i, which looks rather strange, and on the upper
> right corner

I thought that was deliberate, taken from a dictionary and the
punctuations and accents are meant to be pronunciation help and
presumably use special Unicode-8 characters. It's the same whether I
use Firefox or IE. Changing the encoding (even to English) will make
that worse.

