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

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Thu, 01 Sep 2005 02:56:19 -0400
From: William Sit
To: Camm Maguire
Subject: re: Tail recursion (what does")clear all" NOT do?)
Cc: Jens Axel Segaard

I tried the simple tail recursion code by Bill, and repeat after )clear all,
with slight variations. Here are two transcripts. I also verify that if one
starts a FRESH session of Axiom, f and g behave symmetrically when lines (5) of
the FIRST trial are switched from f to g. Comments added in transcripts.

Transcript 1:
                        AXIOM Computer Algebra System
              Version of Tuesday November 30, 2004 at 21:11:14
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

(1) -> )set mess autoload off
(1) -> )set functions compile on

Comments: Trial A:

(1) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> f(1)
   Compiling function g with type Integer -> Integer
(5) -> f(1)

   >> System error:
   The function |*1;f;1;initial| is undefined.

protected-symbol-warn called with (NIL)
(5) -> g(1)

   >> System error:
   The function |*1;f;1;initial| is undefined.

protected-symbol-warn called with (NIL)

Comments on Trial A: same as Bill's. Now Trial B.

(5) -> )clear all
   All user variables and function definitions have been cleared.
(1) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> g(1)
   Compiling function f with type Integer -> Integer
(5) -> f(2)

   >> System error:
   Invocation history stack overflow.

protected-symbol-warn called with (NIL)
(5) -> f(1)

   >> System error:
   Invocation history stack overflow.

protected-symbol-warn called with (NIL)

Comments on Trial B: why does f(2) make a difference? If the stack overflowed,
should it be cleared? If yes, computational result may be lost? Does an
overflowed stack still have any usefulness? If not (as it seems), will forcing a
user to exit Axiom cause loss of data (including previously computed results in
the same session if the user did not )spool? 
Now Trial C.

(5) -> )clear all
   All user variables and function definitions have been cleared.
(1) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> g(1)
   Compiling function f with type Integer -> Integer
(5) -> g(1)

   >> System error:
   Invocation history stack overflow.

protected-symbol-warn called with (NIL)

Comments on Trial C: why does g(1) make a difference? Could this be because
")clear all" does not clear all (such as the Invocation history stack? It does
not clear input history: is that the same?)

Transcript 2:
                        AXIOM Computer Algebra System
              Version of Tuesday November 30, 2004 at 21:11:14
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------


(1) -> )set mess autoload off
(1) -> )set functions compile on

Comments: Trial D, same as Trial A.

(1) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> f(1)
   Compiling function g with type Integer -> Integer
(5) -> f(1)

   >> System error:
   The function |*1;f;1;initial| is undefined.

protected-symbol-warn called with (NIL)

Comments on Trial D: none. Now Trial E.

(5) -> )clear all
   All user variables and function definitions have been cleared.
(1) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> f(1)
   Compiling function g with type Integer -> Integer

Comments on Trial E: The next )clear all was accidental. Now Trial F.

(5) -> )clear all
   All user variables and function definitions have been cleared.
(1) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> f(1)
   Compiling function g with type Integer -> Integer
(5) -> f(1)

   >> System error:
   The function |*1;f;1;initial| is undefined.

protected-symbol-warn called with (NIL)
(5) -> g(2)

   >> System error:
   The function |*1;f;1;initial| is undefined.

protected-symbol-warn called with (NIL)

Comments on Trial F: Why doesn't "Invocation Stack Overflow" occur in g(2)? as
in Trial B of Transcript 1? How was the symmetry in f and g broken? Does the
accident Trial E has anything to do with this?  Now Trial G, which repeats Trial
F.

(5) -> )clear all
   All user variables and function definitions have been cleared.
(1) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> f(1)
   Compiling function g with type Integer -> Integer
(5) -> g(2)

   >> System error:
   The function |*1;f;1;initial| is undefined.

protected-symbol-warn called with (NIL)

Comments on Trial G, a repeat of Trial F, no surprise. Now Trial H.

(5) -> )clear all
   All user variables and function definitions have been cleared.
(1) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> g(1)
   Compiling function f with type Integer -> Integer
(5) -> f(2)

   >> System error:
   Invocation history stack overflow.

protected-symbol-warn called with (NIL)
(5) ->

Comments on Trial H: This is the same as Trial F except in (5) g and f are
switched. symmetry broken again?

Final comments: Axiom should be consistent after a ")clear all", and f and g
should behave symmetrically. Moreover, using f(1) or f(2) should make no
difference to the error messages in the above code. And, of course, the first
call in (5) should already return an error message, as Bill noted already.

\start
Date: Thu, 1 Sep 2005 05:33:42 -0400
From: Cliff Yapp
To: list
Subject: Re: Unit package question

Least anyone think I have abandoned this, I just want to give a brief update:

I've started trying to create a units.spad.pamphlet file, but as yet I've not 
written any actual code - I'm trying to set up the structure of the latex 
document itself and provide a useful background on units, dimensions, and 
issues surrounding them.  This is not strictly speaking useful to the Axiom 
implementation part of this discussion, but has proven very educational for 
me about units, measurement, and standards :-).  I figure this is the moral
equalevent of documenting algorithms and domains in normal Axiom usage,
so I'll try to cram in all the potentially important information.  I suspect 
what I'll wind up with might be overkill, but it can always be trimmed down.

I'm trying to lay things out overall along the lines which have evolved from
the previous discussions, but those discussions printed out are well over 60 
pages so it's a lot to go through.  I'm going to add a couple sections to the 
document that initially won't see much (if any) work, as they are parts 
William disliked (ways to make units populate the top level namespace, 
Reverse Dimensional Analysis, user level tools for a MyUnits environment, 
etc.) and aren't necessary to the core functionality in any case.  Right now, 
I'm just trying to define terms, document the reasoning behind design 
decisions, find and cite useful and important sources like the NIST 
definition documents, and generally get set up so the nitty gritty 
implementation details have a framework to go in.  My first cut  will 
probably not be very good, but at least it will be something to tear apart 
and redo.  Once I've reached a stage where it might be of interest to someone 
I'll be glad to post it.  I may throw in a little code attempting to do 
something like define the top level Category, but it will almost certainly be 
completely wrong the first time around ;-).

Anyway, just wanted to let everyone know I hadn't lost interest.  (Real life 
can get rather annoying at times, too - jobs sure can eat up time :-/.)  

Thought we'd get more comment (other than from me anyway) on William's overall 
design ideas - maybe we got too longwinded and lost the audience? ;-)  

\start
Date: Thu, 1 Sep 2005 11:57:23 +0200
From: Martin Rubey
To: Bill Page
Subject: optional argument to aldor environment

Dear Bill, *,

I just noticed that you augmented the aldor environment on MathAction to allow
for an optional argument, specifying some library.

Although I do not exactly know the background, I think that this is not a good
idea. I'm quite certain we should reserve the optional argument to allow for
specifying the version/patch number of the CAS in question, in line with my
feature request 

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

Is there maybe a different possibility to achieve the same goal? Furthermore it
seems to me that the name specified should also be visible on the rendered
MathAction page, which is not the case, currently.

I hope that there is a solution which does not make it more difficult to
specify versions later on. (If this is not the case anyway, please ignore this
email)

\start
Date: Thu, 1 Sep 2005 06:36:04 -0400
From: Bill Page
To: list
Subject: Aldor rep and per: object-oriented programming or category theory?

Dear Axiom enthusiasts and category theorists:

Having spent a few days trying to absorb the Aldor programming
philosophy from the point of view of it's evolution from previous
incarnations of the Axiom library compiler, as described here:

http://www.aldor.org/docs/HTML/chap18.html

I find there is one construct in particular in Aldor that really
stands out in my mind - it's the concept of representation and
it's opposite (abstraction?). In Aldor these are formally denoted
by two very peculiar coercion operations: rep and pre.

In older SPAD terms, rep and per can be written as the following
macros:

macro {
        rep x == x @ % pretend Rep;
        per r == r @ Rep pretend %;
)

The expression rep(x) describes an object x of this domain but
treats it as belonging to a different domain Rep.

The expression per(y) describes an object y from the Rep domain
which is to be treated as belonging to this domain.

In looking through older SPAD code it is clear that these
combinations occur frequently and their encapsulation as rep
and pre makes reading Aldor code much easier than SPAD.

My question is: does anyone know of any formal programming
language research papers that describe the semantics of rep
and per in a general way?

If this sort of mechanism is present in other languages, what
form does it take?

It seems to me that rep and pre constitute the essence of the
peculiar object-oriented programming style pioneered by Axiom
and Aldor. But what are these constructs in formal (categorical)
terms?

Below are my first attempts to answer these questions. Your
comments, corrections and opinions would be most welcome.

--------

It seems appropriate to me to think of rep and per as forming
a pair of adjoint functors:

             rep
            ---->
   % domain       Rep domain
            <----
             per

rep is a "forgetful functor" that maps the abstract structure
(objects and operations) of this domain into it's internal
representation. It "forgets" about the abstract relationships.
The objects of the external domain however are viewed only in
terms of the relationships between objects. The image of this
domain under rep in representation has its internal structure
exposed.

per on the other hand constructs abstract members of this
domain from the underlying representation. It encapsulates
the internal operations of the representation in terms of
the abstract structure of this domain.

domains must be thought of in terms of categories both in the
sense of category theory and in Axiom's sense of "category".
The appropriate categories usually have at least the structure
of a Cartesian closed category which they inherit from
Axiom's basic types constructors, record, union and mapping.
See discussion:
http://www.axiom-developer.org/zope/mathaction/TuplesProductsAndRecords

In terms of category theory there is a natural transformation,
called the 'unit', that partitions elements of the Rep domain
into classes (as an abstract quotient of the representation).

  x --> rep(per(x))

and rep is right adjoint of per.

In category theoretic terms Rep domain is some Cartesian closed
category, i.e. consisting of products (records), co-products
(unions) and exponentials (functions) over some basic set
of component domains. It's operations are formed freely from
the operations of it's components.

The implementation of the domain in terms of the representation
establishes a natural bi-jection between the operation of the
external domain and the operation of it's internal representation.

   x -> rep y    (representation)
  ------------
   per x -> y    (domain)

The book: "Basic Category Theory for Computer Scientists", by
Benjamin Pierce, MIT Press, 1991, is a good reference. See
especially section 2.4. Pierce gives an excellent example in
terms of definition of the 'List' constructor.

Also: "Categories, Types and Structures. An introduction to Category
Theory for the working computer scientist." by Andrea Asperti and
Giuseppe Longo, M.I.T. Press, 1991, which is downloadable from here:
http://www.di.ens.fr/users/longo/download.html

\start
Date: Thu, 1 Sep 2005 06:32:05 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: optional argument to aldor environment

Martin,

On Thursday, September 01, 2005 5:57 AM you wrote:
>
> I just noticed that you augmented the aldor environment on
> MathAction to allow for an optional argument, specifying
> some library.
>
> Although I do not exactly know the background, I think that
> this is not a good idea.

The reason I did this (only for \begin{aldor}[name] ... so far)
is because of the way that the Aldor compiler works.

In the case of SPAD a call to the compiler

)compile xxxx.spad

produces lisp and object code in a location /NRLIB.NAME/...
determined by the

)abbrev NAME LongName

command inside the xxxxx.spad file and does not depend on
the file name. And on a later page you can write

)lib NAME

and the appropriate object module gets loaded.

In the case of Aldor a call to the compiler

)compile xxxx.as

produces lisp and object code in the locations xxxx.lsp and
xxxx.asy determined by the name of the xxxx.as file. Now in
a later page you need to write

)lib xxxx

When MathAction collections Axiom, SPAD and Aldor sections
for execution, it prepares a series of files - one for each
environment section. Until introducing Aldor, the names of
these files did not matter and they were just generated
randomly by the system. But because the name matters to
Aldor, it is very awkward to have to refer to an Aldor-
compiled object file later based on some randomly generated
largely numerical name.

> I'm quite certain we should reserve the optional argument
> to allow for specifying the version/patch number of the CAS
> in question, in line with my feature request
>
> http://page.axiom-developer.org/zope/mathaction/44IssueTracker
NeedsToBeAbleToUseOldAxiomVersions
>

As I explained earlier, because of the design of MathAction
it would be quite awkward to mix different versions of the
same external program on the same page. MathAction would
have to make a separate pass over the contents of the page
for each version of each external program. I think that
could soon become to prohibitive in terms of the time required
to parse and save a page.

A better idea, I think, would perhaps be to introduce a
paramter associated with the whole page - similar to the
way the pagetype is specified now.

I am really not convinced however how useful running
multiple version of Axiom on MathAction would be. If we
want to "freeze" the output to be that generated by a
certain version of Axiom for later reference, then we
could always just keep the static HTML that was generated
by that version but cut-and-paste.

> Is there maybe a different possibility to achieve the same
> goal? Furthermore it seems to me that the name specified
> should also be visible on the rendered MathAction page,
> which is not the case, currently.

The name is visible inside the compiler output section.
Click on the '+ aldor' link to expand it.

>
> I hope that there is a solution which does not make it more
> difficult to specify versions later on. (If this is not
> the case anyway, please ignore this email)
>

I don't think that this is that case, but I would never
just ignore your email. :)


\start
Date: Thu, 1 Sep 2005 07:07:21 -0400
From: Tim Daly
To: William Sit
Subject: re: Tail recursion (what does")clear all" NOT do?)
Cc: Camm Maguire, Jens Axel Segaard

William,

)clear all 

does not clear the cached functions. Try

)clear completely

\start
Date: Thu, 1 Sep 2005 07:19:24 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: Unit package question

CY

EXCELLENT!!!

It's good to see someone taking the time and energy to document the
background and primary information about the how and why of category
and domain instruction. My hope is that this will be the way Axiom
is developed in the future. The code can always be improved but the
design decisions are vital. I'm trying to document existing code and
the questions ALWAYS arise: "WHY is this code here?", "WHAT were they
trying to do?", "WHERE is this code used?", etc. The questions arise
even in code *I* wrote years ago.

Coding is the easy part once you understand the issues. It is the
understanding that takes a long time. I believe that writing down
what you come to understand is what will make Axiom into a living
system (in the Christopher Alexander sense). Write for the next
generation who will have to maintain it and change it.

\start
Date: Thu, 1 Sep 2005 07:22:02 -0400
From: Tim Daly
To: Martin Rubey
Subject: Re: optional argument to aldor environment

I believe there is a way to set compiler options in Axiom.

)set compiler args -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra

\start
Date: Thu, 01 Sep 2005 07:33:06 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package question - Reply to 1st half

Dear C Y:

This long-winded email started more than a week ago and school started got in
the way. In addition, computer problems, mainly: network and
crashing OS without saving :-( , but also some hardware ones. 

I am glad to know that you are working on this project. I meant to form the
ideas below more thoroughly before posting them but I see you have already
started real work. So I hope these new suggestions, incomplete as they may be,
perhaps should be made known to you and we can discuss this and if I got time to
revise them (probably during labor day weekend), I'll do so. 

It seems that a thorough study of dimensions and units in relation to symbolic
computations is not available and your work/paper would be very useful.

I have added comments on the draft below using [comments: ...].

William
--

I think we are in general agreement regarding how to implement the UnitSystem
domains. Your provoking questions led me to propose modifications to the
original scheme (and even that, is far from a final design as I have been
changing them constantly as I write). The new scheme hopefully will solve some
of the design problems we discussed. I hope before long the new proposal will
approach a practical one. After waiting a short period of further discussions, a
summary of the final design should be posted at MathAction for others to comment
on. 


C Y wrote:
> 
> --- William Sit wrote:
> > Flexibility and generality may
> > complicate usage as well as simplify usage. We have to balance
> > the them.
> 
> Agreed.  What about this - create such a domain as the "default"
> domain, "use" SI units for defaults, and provide tools for the user to
> make changes?  The changes would occur within the Default "working"
> unit domain, assuming any were made - otherwise, it would look just
> like the SI domain.  If one wanted to work in an environment which flat
> out disallowed such setting changes, )set UnitSystem SI (or whatever
> system desired) would take the user to the system defined SI domain
> instead of the Default environment.  Does this map to what Axiom can
> do?

I actually prefer your use of ")set UnitSystem ..." to ")set unit
...". But note ")set UnitSystem" IS setting the session default for the
user. Axiom allows a user to set his preferences in a file called axiom.input
(which is in the directory $AXIOM/input). So by putting ")set UnitSystem
MYUnitSystem" in that file, Axiom will use MYUNitSystem as the default unit
system when the functions 'unitMass' etc (to be grouped into a new function
'setDim', see below) are called.  MYUnitSystem can be SI, CGS,
or some modified version of the standard SI (but once modified, it should be
called something else). Of course, this needs some code or setup to modify the
interpreter, but it can be done (Tim Daly or Bill Page would no doubt know how
and can assist you when that time comes). Most likely, it is a matter of adding
one or two lines to a database.

As for tools to do the dynamic modification from standard unit systems like SI,
here are several changes to the previous setup that will facilitate this and
improve the organization of the domains as well. 

[Comments: I have not decided whether there should be more than one category,
and also what to call them. Also there is a difficulty with dimensions(),
units() because they do not return a domain, to be used in the signatures. So
you may safely ignored the next paragraph for now. However, what I had in mind
was to allow many domains like Dimension = Union("Mass", etc) and corresponding
Unit = Union("slug", etc) for people (students ?) who don't need the full set,
as well as the ability to add new supersets later. Unfortunately, we cannot
have:

  Dimension(dims:List String) == Union(dims)

]

FIRST (alternative): On the category level: 

There will be 

(I) a UnitConversion category, whose details I have not investigated, but its
domains will contain tables for all dimensions for a particular expert field,
units, and conversion factors from SI. There will probably be one comprehensive
such domain to start the ball rolling, but we will surely miss some dimensions
and units in some not-so-common expert areas or new areas. The category will
provide guidelines to add these new areas.

UnitSystem(S, D, U):Category == Exports where
   S: SetCategory
   D: List String
   U: List String

   dimensions: ()->List String
   units: ()->List String
   convertFactor: String -> Float

For example, dimensions() = ["Mass", "Length", ...] (which replaces
Dimension = Union("Mass", "Length", ...), making this local to a unit
system rather than one global list.

(II) ??? Dimension(dims:List String) == Union(dims)


[Comments: The ideas from now on are more or less well formed. However, I have
not finished rearranging these in a more logical sequence. So read it a few
times! I might have made some obsolete claims as I reorganized my thoughts
without revising the claims.]

FIRST: Consolidate all the unitXXX and setUnitXXX functions to::

UnitSystemCategory(S: SetCategory):Category == Exports where

  Dimension ==> Union("Mass", "Length", ...)
  Unit ==> Union("kg", "m", ...)
  Join(RetractableTo S,...) with 
   
    setDimUnit: (Dimension, Unit, S) -> %
    setUnit: (Dimension, Unit) -> Null (?)
    setUnitAll: (Dimension, Unit) -> Null (?)

where 'setDimUnit(dim, unit, s)' is a LOCAL command affecting ONLY s:S, and
'setUnit(dim, unit)' would be a GLOBAL command affecting ALL s:S (more on this
later).  Null may be replaced with a new state vector?

Note that the way Dimension and Unit are defined (as Union("Mass",
"Length", ...) and Union("slug", "ft", ...)) is very close to making
each dimension and unit a domain of its own, except that here each
domain consists of just its name (string). You may also consult the
way BasicOperators and CommonOperators are designed, but at least for
the moment, the simpler setup probably suffices.

SECOND: To support the implementation for 'setUnit' (a dynamical
change of units), I propose to add a state vector for each unit system
domain: this state vector stores the current unit for each dimension,
which is updated by the 'setUnit' command. The 'setDimUnit' command
can check this state vector before generating the Rep (see
below). Some care has to be considered: we have to decide whether a
'setUnit(dim, unit)' command should affect the other derived units
that depends on 'dim' or not, and also those the variables whose
dimensions were set before this 'setUnit' command and invole 'dim'. I
have added 'setUnitAll' for the case every current variable will be
updated.


Thus, we can replace unitLength(len) by setDim("Length", len) when the default
unit is used, where::

    setDim(dim: Dimension, s:S):% == setDimUnit: (dim, unit(dim), s)

and 'unit(dim)' is a look-up function using the state-vector of the
present unit system.


SECOND: Extend the Rep in these domains to include units and
conversion factors.
 
   Rep:=Record(value:S, dim:Dimension, unit:Unit, factor:(Float, String), 
               absfactor:(Float, String))

My original proposed Rep is simpler because I was not planning for
dynamic changes to the unit system, so unit and factor (which would be
1 always) are "hard-wired". The more general record allows more
flexibility. This is slightly less efficient in terms of storage, but
not that bad, because no matter what, somewhere, the system has to
store the conversion factors. The conversion factors can probably be
implemented in a UnitConversion domain, which would be a lookup table
(maybe tables), which drives the 'setDimUnit' and 'setUnit'
commands. Axiom has a number of data structures with extensive tools
to create lookup tables (see domains of category TableAggregate in
table.spad).

In the new Rep, besides the unit, two factors are included: One
relative to the current system (to provide a relative factor to
convert within this system when a user changes a unit, and one
relative to SI (to provide an absolute factor to convert between
systems: for SI derived unit system, just one factor would suffice;
but we should aim for uniformity to simplify the code). Each factor
has both a value (Float) and a name (String). The value of the factor
is when numerical output is needed, that is, when S is coerced to
Float (via the "lift" mechanism). The name would be used in output for
symbolic computations to indicate a conversion factor is needed,
without spoiling the elegance of symbolic computation or more
importantly, going outside the domain S. It is only a decoration in
the output (so it can be used with even Float alone), but it serves
two important roles as well: it can be used as an index key to the
UnitConversion table(s) to look up the value of the factor, and it can
also be used to provide an audit trail in numerical computations:
typically, if the answer is simply in numeric form set to the user's
unit, the user may not have any idea of how what factors are used in
its computation; by delaying the use of numerical values for
conversion factors, the user can track each conversion in symbolic
form for numerical inputs to verify correctness and then compute when
everything is ok (in case there are bugs, for example, this can be
used for debugging too).

The above setup would make the coercion to OutputForm quite straight
forward and uniform (which should ignore the factors if they are (1.0,
"1")).




The following scenario will illustrate the potential problems and I'll put in
some suggestions on how to solve some of these.

Assuming the above extended Rep: unit is initialialised to the
standard one for the system, factor initialized to (1.0, "1"),
absfactor initialized to (absfactorvalue, absfactorname).  Let's
assume the default unit system is FPS (foot-pound-second, a
non-scientific system still used in the US), see:

http://medical-dictionary.thefreedictionary.com/foot-pound-second+system

When a user runs the command:

(1)   ulen: := setDim("Length", len)

Axiom will return:

      len [ft]

but internally, the Rep is

    [value = len, dim = "Length", unit = "ft", factor = (1.0,"1"),
     absfactor = (0.3048, "ft2m")]

Here the absfactor says 1 ft is 0.3048 m. The name can be constructed
dynamically using string concatenation using the UnitConversion table.

(By the way, you can find lots of conversion factors on line: for example
 http://www.onlineconversion.com/
Just learn a bit more! Let's just stay with English for this discussion.)

In a STATIC change environment (this is, at compile time), if the user prefers
"in" GLOBALLY as the unit for length, the command 

(2) setUnit("Length", "in") 

Here is a design question: we can let setUnit("Length", "in") to
modify ONLY the unit of the "Length" dimension and not any derived
dimension that involves "Length". This would be the most flexible so
that we can allow will change the state-vector to reflect all units
that involve a "Length" dimension as component

len ft2in [in]

with the internal Rep now:

   [value = len, dim = "Length", unit = "in", factor = (12, "ft2in"), 
    absfactor = (0.0254, "in2m")]

where 0.0254 can be computed from 0.3048 by dividing by 12, some other means.
The absfactor will faciliate converting FPS to SI, and hence to other system as
well.


If the user prefers "cm" as the unit for length in an otherwise FPS system, the
command unitLength can be modified to produce:

(3)   len ft2cm [cm]

with the internal Rep now:

   [value = len, dim = "Length", unit = "cm", factor = (30.48, "ft2cm"),
    absfactor = (0.01, "cm2m")]

This is all not difficult for STATIC changes, that is, changes that
are effected at Axiom start time. Now consider DYNAMIC changes:
suppose again the default is FPS system, and the user has already set
the variable ulen as in (1).

Now if the user later runs:
  
(4)    setUnitLength("cm")

What does this involve? You are now in a run-time environment, you
cannot change the code for unitLength in the FPS domain, you can only
change data. (Code modification is in theory possible if you know
enough, but I don't think that is a good practice in Axiom).  To
handle FUTURE assignments, we can design the code for unitLength to
depend on a state vector for the domain: this state vector stores one
unit for each dimension, and is updated by the setUnitLength and
similar commands. The unitLength (and similar commands) can check this
state vector before generating the Rep.

But what about those variables already defined, like ulen defined in (1)? If
ulen is used in some computation requiring ulen to be an input parameter, then
we can update it. For example, if the user now wants to compute the area for a
square with side ulen using one of the following syntax:

     uarea := ulen * ulen
     uarea := unitArea(ulen, ulen)

the routine * or unitArea can check the units of its arguments and update them
before computation. However, if the user simply types

     ulen

the interpreter can only redisplay the output (1). The interpreter has
no reason to call the FPS(S) domain to perform an update and change
the unit of ulen and display the output (3). Perhaps the domain FPS(S)
should provide a function update(ulen).
     

 
I made the factor:Union(Float, Symbol) to allow a delay of the
computation when symbolic computation is more prevalent and also when
S does not have RetractableTo(Float).  This still requires S to have
RetractableTo(Symbol).  The exact meaning of factor needs some
discussion: perhaps there should be two factors! One relative to the
current system (to provide a relative factor to convert within this
system when users changes a unit, and one relative to SI (to provide
an absolute factor to convert between systems).


> > > But it should be doable, readily, IMHO.  That's what computers
> > > are for - to handle the grunt work associated with such
> > > decisions.
> >
> > As long as you are willing to do the programming :-)
> 
> Hehe - fair enough!  In fact, I think such things can be built as a
> layer on top of your system, which is undoubtedly the most robust way
> to handle things.  So I vote for doing it your way, and then if I
> really want some of what I say I want it can be implimented on top of
> the core system.
> 
> > > There is also the case where you want to know what
> > > quantity/dimension an expression is.
> >
> > Reverse dimensional analysis, is useful for providing the user
> > with possibly different interpretation of the dimension of an
> > expression. Checking dimensional correctness is a different,
> > though related, issue.
> 
> Ah :-). Thanks for helping clarify all of this - it's definitely
> broadened my understanding of units/dimensions/etc. :-).
> 
> > > > Don't mix unit systems! Convert first before you start the
> > > > computations, and convert back if you really have to.
> >
> > > But that's just it - part of the reason for implementing a Unit
> > > system in a CAS in the first place is to get it to do all the
> > > converting and other annoyingly boring and error prone tasks for
> > >  you - both for input and output.
> >
> > Sure, but that does not mean one has to do it for all possible
> > conversions, only the most useful ones should be provided, with
> > functionality that allows, though not as convenient, the very
> > special user to change units.
> 
> OK, point.  As a possible future extension to this environment though,
> I may try and code up a way to do as many such conversions (arbitrary
> unit -> current environment) as possible, since usually the unit that
> causes the biggest problem in a problem is the obscure uncommon one you
> have to go dig up the conversion factor for.  This argues for as broad
> a knowledge of units in Axiom as possible, although I admit this should
> probably be done over time and not as part of the initial effort.
> 
> > Ignoring it in this example would mean the equation is not
> > dimensionally balanced, and worse, some may think that
> > degree = radian!
> 
> I think this is a weak spot in my understanding of dimensionality, so I
> apologize if I'm being dense here.  If we take C=%pi*d where C is a
> circumference, %pi is %pi, and d is diameter, and look at the
> dimensions, we have:
> 
>           degree
> Length =  ------ Length
>           radian
> 
> Casually, this doesn't look at all balanced. 

Of course not. But that is exactly the point: a dimensionless constant takes on
different dimensions in different conversions or equations. So even thought
these have the same VALUE pi, the pi in C = pi*d and the pi in 180 deg = pi
radians are different because their (hidden) dimensions are different. In each
equation, only their values are the same.


> Does it mean that when we
> define the dimensionality of the variable C we need to define it as:
> 
>  degree
>  ------ Length
>  radian
> 
> rather than just Length?  


No, dimension of C is length and is not dependent on any equation it
is in. This is a major difference between physical quantities and
mathematical constants.  Perhaps we should start using the term
"dimension" to mean the one used in the definition, which may involve
derived dimensions, and the term "reduced dimension" to mean a
simplified form in terms of the basic dimensions. Then we can say the
reduced dimensions of pi in both equations are the same, namely 1 (or
dimensionless), but the dimensions are different. This terminology
would work to say work and moment have the same reduced dimensions,
but their dimensions are different (when vectors are used to indicate
the direction of the distance with respect to the forces). How vectors
may be expressed in dimensions is another thing to study.

> > OK, let me try to explain again.  A quantity is dimensionless
> > means its dimension can be reduced to 1. But sometimes, it is
> > more meaningful (physically or mathematically) to view these as a
> > quotient (this is like, but not totally, we sometimes rewrite 1 as
> > 2/2 to add fractions). Even SI recognizes this in stating that the
> > unit of a phase angle is m. m^(-1) = 1 because this IS the
> > definition (arc length spanned by the angle, divided by the radius).
> > Just because the dimensions cancel out (making it dimensionless)
> > does not mean the dimension is not there.
> 
> OK, I think I'm getting it.  So what we need to do is examine the cases
> where it is actually useful to retain this information, and see what
> behaviors are rigorous/needed/useful.  Definitely in some cases we need
> to canel dimensions out - we don't want something described in (say)
> kg/s multiplied by seconds to wind up as kg*s/s, but if there are cases
> where m/m is useful to preserve there would seem to be a problem with
> having a general rule.  Could unit and dimension cancelation be handled
> on a per dimension basis?

May be, or may be not. It depends on the physical meanings of the variables. If
I have price at $5/m multiplied by 7 m, I should get $35. If I have 8 N divided
by 2 m^2 for pressure, and N has dimension kg-m/s^2, is it ok to cancel one of
the m? So a single rule of Length (m) is not applicable to all cases.
 
> > Definitely. We can have a nanosytem domain, and other domains of
> > UnitSystem(S) as experts need them. That is the beauty of Axiom's
> > categorical approach: unifying domains with a common set of API.
> 
> OK, cool.  So we might actually develop a situation where, for
> different kinds of work, we have different standard domains defined
> (say, as an example, if someone is working with radio telescope data
> and equations, they can do )set UnitSystem RadioTelescope having
> previously defined the desired unit conventions for such work.  I
> guess, thinking about it, my scenarios for unit use were too narrowly
> focused on the case of students, where arbitrary units will appear for
> any reason and no reason (sometimes just to make them look them up and
> do the conversion, which always annoyed me as an extra and unnecessary
> potential source of numerical errors but in retrospect was probably
> good training.)  For "real world" use, that case is not terribly
> useful, and Axiom is definitely not focused on introductory student
> problems :-).
> 

Actually, you scenarios are not narrow but general and right! There
should be no difference between units as used by students and units as
used by researchers.  The idea of units is not limited to even
SI. Currency conversions are conversions in monetary units. But we
should be able to use Axiom's unit system for grocery as well (Back to
my unfinished idea on different Dimension domains)

Dimension=Union("Orange", "120z-Coke", ...) is as useful as
Dimension=Union("Mass", "Length", ...). 

(Yes, a supermarket manager using Axiom, that'll be the day: not so
far-fetched if you think of the operation research problems involved).

\start
Date: Thu, 01 Sep 2005 07:57:26 -0400
From: William Sit
To: Tim Daly
Subject: re: Tail recursion (what does")clear all" NOT do?)
Cc: Camm Maguire, Jens Axel Segaard

root wrote:
> 
> William,
> 
> )clear all
> 
> does not clear the cached functions. Try
> 
> )clear completely
> 
> Tim

Here's a new transcript (not as extensive as previous), but symmetry is still
broken.

Transcript 3:
                        AXIOM Computer Algebra System
              Version of Tuesday November 30, 2004 at 21:11:14
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

(1) -> )set mess autoload off
(1) -> )set functions compile on

[Comments: Trial AA]

(1) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> f(2)
   Compiling function g with type Integer -> Integer
(5) -> g(1)

   >> System error:
   The function |*1;f;1;initial| is undefined.

protected-symbol-warn called with (NIL)

[Comments: Trial BB, same as AA]

(5) -> )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) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> f(2)
   Compiling function g with type Integer -> Integer
(5) -> g(1)

   >> System error:
   The function |*1;f;1;initial| is undefined.

protected-symbol-warn called with (NIL)

[Comments: Trial CC, with g and f reversed in (5)]

(5) -> )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) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> g(2)
   Compiling function f with type Integer -> Integer
(5) -> f(1)

   >> System error:
   Invocation history stack overflow.

protected-symbol-warn called with (NIL)
(5) ->

[Comments on Trial CC: why? Now Trial DD, same as CC]

(5) -> )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) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> g(2)
   Compiling function f with type Integer -> Integer
(5) -> f(1)

   >> System error:
   Invocation history stack overflow.

protected-symbol-warn called with (NIL)

[Comments:ok; Now trial EE, reversing back to AA]
(5) -> )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) -> f:INT->INT
                                                                   Type: Void
(2) -> g:INT->INT
                                                                   Type: Void
(3) -> f(n)==g(n)
                                                                   Type: Void
(4) -> g(n)==f(n)
                                                                   Type: Void
(5) -> f(2)
   Compiling function g with type Integer -> Integer
(5) -> g(1)

   >> System error:
   Invocation history stack overflow.

protected-symbol-warn called with (NIL)
(5) ->

[COmments:Trial EE: This differs from AA.]

Final comments: ")clear completely" does not seem to clear completely either.
Symmetry is still broken.

\start
Date: Thu, 01 Sep 2005 14:57:19 +0200
From: Gregory Vanuxem
To: Kai Kaminski
Subject: Re: [UI] Plot Support

Le jeudi 01 septembre 2005 =E0 01:14 +0200, Kai Kaminski a =E9crit :
> Hi!
>
> I have just uploaded a new version of AxiomUI to my homepage at
> kaikaminski.gmxhome.de. It now supports two-dimensional plots. Some
> options do not work, but there are a few examples in the README to
> demonstrate what is possible.
>
> I should mention that at the moment quite a bit of debugging output is
> printed, which makes everything a lot slower than it usually is. Also
> keep in mind that when you first plot something, all the necessary
> libraries have to be loaded, which also takes some time.
>
> Kai

The adress is

http://127.0.0.1:5050/

no ?

\start
Date: Thu, 1 Sep 2005 14:20:37 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: optional argument to aldor environment

Page, Bill writes:

 > > I'm quite certain we should reserve the optional argument to allow for
 > > specifying the version/patch number of the CAS in question, in line with
 > > my feature request
 > > 
 > > http://page.axiom-developer.org/zope/mathaction/44IssueTracker
 > NeedsToBeAbleToUseOldAxiomVersions
 > >
 > 
 > As I explained earlier, because of the design of MathAction it would be
 > quite awkward to mix different versions of the same external program on the
 > same page. MathAction would have to make a separate pass over the contents
 > of the page for each version of each external program. I think that could
 > soon become to prohibitive in terms of the time required to parse and save a
 > page.

Since you are the master of MathAction, I believe you, although I don't quite
understand. Did I understand correctly: Currently you save the content of every
section into a file and then you say something like

axiom                (start axiom)
for file in filelist
  case type(file) of
    axiom: )re file
     spad: )co file
    aldor: )co file
)qu

So maybe the following could be a solution: have a LaTeX-syntax-wiki-switch
like

\setAxiomVersion{patchnumber}

and

\setAxiomVersionCurrent

that quits the current axiom process and starts a new one with the indicated
pachnumber. Furthermore, these commands should print the indicated
patchnumber... So this would result in the following structure

for version in versionlist
  axiom--version       (start axiom)
  for file in filelist
    case type(file) of
      axiom: )re file
       spad: )co file
      aldor: )co file
  )qu

Would this be doable?

 > A better idea, I think, would perhaps be to introduce a paramter associated
 > with the whole page - similar to the way the pagetype is specified now.

Well, the idea is that I can write on IssueTracker

Up to Axiom version
\setAxiomVersion{44}

the following produced wrong output:
\begin{axiom}
  code formerly producing wrong output
\end{axiom}

However, meanwhile this is fixed, as you can see for example in the current
version 
\setAxiomVersionCurrent

\begin{axiom}
  code formerly producing wrong output
\end{axiom}

\start
Date: Thu, 1 Sep 2005 14:57:28 +0200
From: Martin Rubey
To: Kai Kaminski
Subject: axiomui

Dear Kai,

I just tried to get your code running, but somehow it failed. After entering
any command in the toplevel, I get the following in the clisp terminal:

Logged error: 404 Not Found NIL (http://127.0.0.1:5050/static/styles/toplevel.css)
Logged error: 404 Not Found NIL (http://127.0.0.1:5050/static/javascript/toplevel.js)
Logged error: 404 Not Found NIL (http://127.0.0.1:5050/static/javascript/jsMath/jsMath.js)

\start
Date: Thu, 1 Sep 2005 10:12:35 -0400
From: Bill Page
To: Martin Rubey
Subject: different axiom versions on mathaction

Martin,

On Thursday, September 01, 2005 8:21 AM you wrote:

> Did I understand correctly: Currently you save the content
> of every section into a file and then you say something like
>
> axiom                (start axiom)
> for file in filelist
>   case type(file) of
>     axiom: )re file
>      spad: )co file
>     aldor: )co file
> )qu
>

Yes that is essentially correct except that what you write
as a loop, my program generates as a linear script like this:

1)  extract Axiom sections:
      section_n --> file_n.xx
        where xx = 'input' or 'spad' or 'as'

2)  in parallel generate script:

      axiom           (start axiom)
      )re file1.input
      )co file2.spad
      )re file3.input
      )co file4.as
        ...
      )yy file_n.xx
      )qu

        where yy = 're' if xx = 'spad' else 'co'

3)  execute script

4)  collect output into output1, output2, ... output_n

5)  replace section_n <-- output_n for all n

This is just for the Axiom sections. The same process is repeated
entirely once again for Reduce and then one more time for LaTeX.
Of course it is important that the LaTeX pass come last since it
must process sections created by the previous two passes.

> So maybe the following could be a solution: have a
> LaTeX-syntax-wiki-switch like
>
> \setAxiomVersion{patchnumber}
>
> and
>
> \setAxiomVersionCurrent
>
> that quits the current axiom process and starts a new one
> with the indicated pachnumber. Furthermore, these commands
> should print the indicated patchnumber... So this would
> result in the following structure
>
> for version in versionlist
>   axiom--version       (start axiom)
>   for file in filelist
>     case type(file) of
>       axiom: )re file
>        spad: )co file
>       aldor: )co file
>   )qu
>
> Would this be doable?

Well, I think what you wrote above would amount to repeating
all n commands m  times, once for each axiom--version.

> ...
> Well, the idea is that I can write on IssueTracker
>
> Up to Axiom version
> \setAxiomVersion{44}
>
> the following produced wrong output:
> \begin{axiom}
>   code formerly producing wrong output
> \end{axiom}
>
> However, meanwhile this is fixed, as you can see for example
> in the current version
> \setAxiomVersionCurrent
>
> \begin{axiom}
>   code formerly producing wrong output
> \end{axiom}
>

So in that case I think the following might work:

1)  extract Axiom sections:
      section_n --> file_n.xx
        where xx = 'input' or 'spad' or 'as'

2)  in parallel generate script include version changes:

      start axiom -version=current
      )re file1.input
      )co file2.spad
      )qu

      start axiom -version=44
      )re file3.input
      )qu

      start axiom -version=current
      )co file4.as
        ...
      )yy file_n.xx
      )qu

3)  execute script and append output of each session

4)  collect output into output1, output2, ... output_n

5)  replace section_n <-- output_n for all n

But when designing the page the author would have to keep in mind
that each version change results in complete loss of context.
The other thing to understand is that stopping and starting Axiom
sessions is much more expensive in computer time than actually
doing most calculations! The more version switches the longer the
author will have to wait when they click 'Save'.

\start
Date: Thu, 1 Sep 2005 11:07:44 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Unit package question

On Thursday, September 01, 2005 5:34 AM Clifford wrote:
>
> Least anyone think I have abandoned this, I just want to give
> a brief update:
>
> [writing design documentation]
>
> ... so I'll try to cram in all the potentially important
> information.  I suspect what I'll wind up with might be
> overkill, but it can always be trimmed down.

I shall always remember that a famous physicist (Dirac, I think)
once started his presentation at a conference by apologizing that
"he did not have enough time to write a shorter paper" ...

The point being, I guess that it is relatively easy to but down
a lot of poorly organized stuff dealing generally or maybe in too
much detail with partly the wrong stuff, etc. But he made an
apology because he felt that by doing so he was being somewhat
discourteous to his audience. One of his responsibilities as a
writer is to say clearly and exactly what the audience needs to
know and this takes *more* time than being verbose.

A related issue is that we need to take account of the fact
that human beings have some built-in limitations when it comes
to appreciating complex subjects when they are presented with
too many unorganized ideas at once. If it is at all possible
we need to choose a mode of expression that is more powerful,
i.e. say more with less but carefully chosen words. This is
often where mathematics ( = 10,000 words) , pictures (= 1,000
words) and demonstrations ( = 1,00 words) should come into play.

While I appreciate all of the documentation that exists about
Axiom (It is much better than if there was none at all!) but I
am rather afraid that we are already well past the point of having
to apologize to new people who come to our documentation and our
web site to understand as quickly as possible what they need to
know about Axiom. :( Even give Axiom's "30 year horizon" and the
chance that I might actually live that long, I do have doubts that
I will ever end up reading all of the material about Axiom that
we already have.

I am thinking more and more these days that we have to think
about improving the quality of what we have (and therefore
reducing it's length) while at the same time producing more
quantity.

> ...
> Thought we'd get more comment (other than from me anyway) on
> William's overall design ideas - maybe we got too longwinded
> and lost the audience? ;-) 
>

Aw, proving my point above! In fact I did read all 60+ pages,
but I must say that at some point I began to feel like I had
lost the path to enlightenment. :) So that's when I went back
to the first few emails and put Martin's example code on the
web:

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

After seeing Martin's idea work almost exactly in the way you
originally imagined that it might, I became less convinced of
of my original presumption that there should be a close connection
between units/dimensions and Axiom domains.

Now I would like to see what Ralf sketched in Aldor written and
demonstrated in about this same level of detail and functionality.

Then perhaps we could code something similar to William's
approach (to the extent that I understand that it differs from
both Martin and Ralf).

Then after experimenting with these "toy" examples a little,
I expect/hope that I might be able to see it "fall into place".

Some people might be concerned that writing code too soon risks
freezing-in less suitable ideas, but lately I am beginning to
take a more "extreme programming" point of view: writing code
is in fact the whole point of the exercise. Yes it needs to be
documented and understood, but this is (and will often continue
to be) a moving target. We should be prepared to write, correct,
re-write, factor and re-organize our code fluently while making
an effort to keep it clear, concise and easily understood by
others. We need to think-build-experiment-rebuild-rethink-
build ... in an iterative and hopefully inspired manner.

Of course this is not possible. :) Our tools and our skill are
not (yet) quite up to this task. But at least in the open
source world, I think it is clear that this approach works much
better than the classical engineering "design, implement, test,
and sell" model.

There. Now I've probably written more than even I will be
willing re-read and have, finally, illustrated my own point.

Carry on.

\start
Date: Thu, 01 Sep 2005 17:42:33 +0200
From: Kai Kaminski
To: Martin Rubey
Subject: Re: axiomui

Martin,

thanks for trying.

Martin Rubey writes:

> I just tried to get your code running, but somehow it failed. After entering
> any command in the toplevel, I get the following in the clisp terminal:
>
> Logged error: 404 Not Found NIL (http://127.0.0.1:5050/static/styles/toplevel.css)
> Logged error: 404 Not Found NIL (http://127.0.0.1:5050/static/javascript/toplevel.js)
> Logged error: 404 Not Found NIL (http://127.0.0.1:5050/static/javascript/jsMath/jsMath.js)

My mistake. There are two ways to fix this. Either download the whole
tar ball again, or just download the file
http://kaikaminski.gmxhome.de/axiom-hub.lisp and put it in the
axiomui/http-server/ dirrectory. That should fix it.

Yet another way to fix this problem is to edit axiom-hub.lisp and make
sure that the variable *static-pages-path* actually points to the
axiomui/static-pages/ directory.

\start
Date: Thu, 01 Sep 2005 18:17:20 +0200
From: Kai Kaminski
To: Gregory Vanuxem
Subject: Re: [UI] Plot Support

>> Hi!
>> 
>> I have just uploaded a new version of AxiomUI to my homepage at
>> kaikaminski.gmxhome.de. It now supports two-dimensional plots. Some
>> options do not work, but there are a few examples in the README to
>> demonstrate what is possible.
>> 
>> I should mention that at the moment quite a bit of debugging output is
>> printed, which makes everything a lot slower than it usually is. Also
>> keep in mind that when you first plot something, all the necessary
>> libraries have to be loaded, which also takes some time.
>> 
>> Kai
>
> The adress is 
>
> http://127.0.0.1:5050/

Yes, it is. I just checked. What kind of problem do you have? Is it
the same as Martin's? In any case you will have to replace the file
axiomui/http-server/axiom-hub.lisp with the one available at
kaikaminski.gmxhome.de or download the tar ball again. The version you
downloaded contained a wrong pathname and won't work.

\start
Date: Thu, 1 Sep 2005 09:56:44 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Unit package question

--- Bill Page wrote:

> On Thursday, September 01, 2005 5:34 AM Clifford wrote:
> > 
> > Least anyone think I have abandoned this, I just want to give 
> > a brief update:
> > 
> > [writing design documentation]
> >
> > ... so I'll try to cram in all the potentially important 
> > information.  I suspect what I'll wind up with might be
> > overkill, but it can always be trimmed down.
> 
> I shall always remember that a famous physicist (Dirac, I think)
> once started his presentation at a conference by apologizing that
> "he did not have enough time to write a shorter paper" ...

If he didn't, I'm dubious that open source developers will either ;-).

> The point being, I guess that it is relatively easy to but down
> a lot of poorly organized stuff dealing generally or maybe in too
> much detail with partly the wrong stuff, etc. But he made an
> apology because he felt that by doing so he was being somewhat
> discourteous to his audience. One of his responsibilities as a
> writer is to say clearly and exactly what the audience needs to
> know and this takes *more* time than being verbose.

There are three stages writing a paper goes through:

1)  Where you are trying to pull together enough information that you
can actually cover what you need to to do a proper treatment of a
subject

2)  Where you are trying to write up all of this information in a way
that makes coherent sense

3)  Where you have a good grasp of all the details and essentials of
what you have written and can turn your attention to boiling it down to
its clear, precise essence

I am currently at stage one.  Understanding the subtle issues releated
to Dimensions, Units, and using them "correctly" is not something I am
fully comfortable with, and the first order of business is to get a
good idea of what correct is.  This involves both understanding the
concepts themselves, and expressing them in Axiom - unfortunately I am
busy trying to understand the concepts and have yet to move on to the
Axiom part.
 
> A related issue is that we need to take account of the fact
> that human beings have some built-in limitations when it comes
> to appreciating complex subjects when they are presented with
> too many unorganized ideas at once. If it is at all possible
> we need to choose a mode of expression that is more powerful,
> i.e. say more with less but carefully chosen words. This is
> often where mathematics ( = 10,000 words) , pictures (= 1,000
> words) and demonstrations ( = 1,00 words) should come into play.

Unfortunately, this is only likely in the case of really mature topics.
 Not to mention that doing this is as much an art as a science, and I
think relatively few people in any disicipline have mastered it.

> While I appreciate all of the documentation that exists about
> Axiom (It is much better than if there was none at all!) but I
> am rather afraid that we are already well past the point of having
> to apologize to new people who come to our documentation and our
> web site to understand as quickly as possible what they need to
> know about Axiom. :( Even give Axiom's "30 year horizon" and the
> chance that I might actually live that long, I do have doubts that
> I will ever end up reading all of the material about Axiom that
> we already have.

I think part of the problem (certainly I can speak to my own case) is
that people don't necessarily know "what they need to know".  Axiom is
an environment that enforces correctness, and that is going to cause
problems for people trying to quickly solve casually framed problems. 
It's a more subtle manifestation of the reason lab students don't want
to record units - half the time they don't KNOW what units the
measurement is in, and don't want to try to find out.  So I think a lot
of times Axiom is forcing people to think about things they SHOULD be
thinking about, but want to brush under the rug.  I can't really bring
myself to consider that a bad thing.  We should probably have a way for
people to say things like "I'm dealing only with reals, quit bothering
me about issues related to all these obscure types!" in settings, but
those settings will then be explicit statements of what domains and
constraints are in place.  This should be well defined always, even in
things like physics where they want to get on with it and not worry
about the details.  Provide a working environment, but that working
environment should be based on sound, well defined principles which are
programmed and available, even if the user doesn't have to explicitly
set them all.

There is something I like to call "irreducible complexity" in software,
and in ideas and interfaces as well - some things simply ARE hard. 
Axiom is trying to be correct, and as a result it has to both ask and
answer many many questions that are routinely ignored, treated as a
matter of course in sub-topics of mathematics, or in some cases not
well defined at all.  I may be overestimating the authors and designers
of Axiom, but at this point I have a feeling that the effort to be
fully correct is responsible for much of the verbosity of Axiom.  Being
precise in meaning and correct in definition is a hard, hard problem. 
It is probably impossible to meet those goals and remain readily
comprehensible, simply because most people don't think about things in
a fully precise and correct matter.

> I am thinking more and more these days that we have to think
> about improving the quality of what we have (and therefore
> reducing it's length) while at the same time producing more
> quantity.

I would actually suggest we start thinking seriously about
using/incorporating ACL2 or HOL4 or some such system and using proof
logic, since that is the purest expression of meaning I know.  The hard
part is translating this type of logic into human-friendly English, and
that's where I think most of the verbosity comes in.  That translation
is both necessary and not well defined.

> > ... 
> > Thought we'd get more comment (other than from me anyway) on
> > William's overall design ideas - maybe we got too longwinded
> > and lost the audience? ;-)  
> > 
> 
> Aw, proving my point above! In fact I did read all 60+ pages,
> but I must say that at some point I began to feel like I had
> lost the path to enlightenment. :) So that's when I went back
> to the first few emails and put Martin's example code on the
> web:
> 
> http://www.axiom-developer.org/zope/mathaction/UnitsAndDimensions
> 
> After seeing Martin's idea work almost exactly in the way you
> originally imagined that it might, I became less convinced of
> of my original presumption that there should be a close connection
> between units/dimensions and Axiom domains.

Uh oh :-)

> Now I would like to see what Ralf sketched in Aldor written and
> demonstrated in about this same level of detail and functionality.
> 
> Then perhaps we could code something similar to William's
> approach (to the extent that I understand that it differs from
> both Martin and Ralf).
> 
> Then after experimenting with these "toy" examples a little,
> I expect/hope that I might be able to see it "fall into place".

I have a feeling I'll have to play around with things at almost all
levels of detail, including various toy implementations, before I can
try anything "for real."

> Some people might be concerned that writing code too soon risks
> freezing-in less suitable ideas, but lately I am beginning to
> take a more "extreme programming" point of view: writing code
> is in fact the whole point of the exercise. Yes it needs to be
> documented and understood, but this is (and will often continue
> to be) a moving target. We should be prepared to write, correct,
> re-write, factor and re-organize our code fluently while making
> an effort to keep it clear, concise and easily understood by
> others. We need to think-build-experiment-rebuild-rethink-
> build ... in an iterative and hopefully inspired manner.

Uh oh :-).  I tend to prefer the school of do it once, do it right, and
never think about it again - after that just use it ;-).  We've got
Mathematica, Maple, Maxima, and others to "get the job done" - Axiom's
virtues are in doing things the "right way."  

Ultimately, both approaches aren't mutually exclusive.  It just spreads
overall resources a bit thinner, but since Axiom is no longer
commercial and doesn't seem to have much competition in the "Do It
Right" space I'm not too worried ;-).  Many of us are still learning
which end is up in Axiom (and then asking what it means to be up ;-) so
I think things will eventually improve.

> Of course this is not possible. :) Our tools and our skill are
> not (yet) quite up to this task. But at least in the open
> source world, I think it is clear that this approach works much
> better than the classical engineering "design, implement, test,
> and sell" model.

Well, define better - it does produce more code, but I'm not convinced
it necessarily produces higher quality code.

> There. Now I've probably written more than even I will be
> willing re-read and have, finally, illustrated my own point.

Hehe :-).
 
> Carry on.

Will do - distilling things down to their essence is something that a
group of eyeballs is very helpful at.  I may disagree about what the
scope of "essence" is, but I would like to mention one other principle
I have heard over and over in experimental situations:

"There is no such thing as too much information.  It is possible to
function by ignoring irrelevant data, it is impossible to function if
you discover data you considered irrelevant and didn't record has
suddenly become relevant.  Always better to know too much than too
little.  You are far more likely to underestimate what you will need to
know than overestimate."

I think it is possible to define user documentation, which keeps it
simple and straightforward, and programming documentation which should
deal with all relevant issues.  I think pamphlets are the place for the
latter, and the volumes of the Axiom book the place for the former.  Or
did I misunderstand this, Tim?

Note this is not ment to encourage poor or unclear writing, which is an
altogether different matter and something I'm probably guilty of quite
often.

\start
Date: Thu, 1 Sep 2005 10:25:20 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: Unit package question

--- Tim Daly wrote:

> CY
> 
> EXCELLENT!!!
> 
> It's good to see someone taking the time and energy to document the
> background and primary information about the how and why of category
> and domain instruction. 

Heh - I'm not actually there yet - I'm currently trying to properly
define things like the meaning of Units and Dimensions (Dimension turns
out to be very tricky to define!) and the thinking behind overall
design concerns. William is way ahead of me right now - I'm not close
yet to translating what I'm learning into Axiom code as such.

> My hope is that this will be the way Axiom
> is developed in the future. The code can always be improved but the
> design decisions are vital. I'm trying to document existing code and
> the questions ALWAYS arise: "WHY is this code here?", "WHAT were they
> trying to do?", "WHERE is this code used?", etc. The questions arise
> even in code *I* wrote years ago.

Agreed.  After my experience playing with Maxima I'll never ask again
why documenting things is important.

> Coding is the easy part once you understand the issues. It is the
> understanding that takes a long time. I believe that writing down
> what you come to understand is what will make Axiom into a living
> system (in the Christopher Alexander sense). Write for the next
> generation who will have to maintain it and change it.

What I'm not sure about is whether or not having things like the
physical basis for SI units documented in the pamphlet is a good thing.
 My thinking on this is yes because a) I like having all possibly
relevant info in one place and b) it's fundamental to the meaning of
units and therefore seems like appropriate knowledge to have in the
Axiom pamphlet file, but it may wind up being enough to make people
roll their eyes at me ;-).  Plus, sometimes a document that is readily
available at one point in time gets harder to find later, or may be
hard to access for someone in another country with limited internet
access, or who knows.  So I tend to favor the idea of a pamphlet file
which is as internally consistent and complete as possible, even at the
risk of verbosity.  But that's just me ;-)  Once I've actually got
something I'll post it and take my lumps.

\start
Date: Thu, 1 Sep 2005 16:26:21 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: different axiom versions on mathaction

Page, Bill writes:
 > > for version in versionlist
 > >   axiom--version       (start axiom)
 > >   for file in filelist
 > >     case type(file) of
 > >       axiom: )re file
 > >        spad: )co file
 > >       aldor: )co file
 > >   )qu
 > > 
 > > Would this be doable?
 > 
 > Well, I think what you wrote above would amount to repeating all n commands
 > m times, once for each axiom--version.

Yes, should read

 > But when designing the page the author would have to keep in mind that each
 > version change results in complete loss of context.  

Yes, this is obvious. It's just a change as changing between reduce and axiom.

 > The other thing to understand is that stopping and starting Axiom sessions
 > is much more expensive in computer time than actually doing most
 > calculations! The more version switches the longer the author will have to
 > wait when they click 'Save'.

Yes, but this wouldn't really matter, since it is supposed to be used only to
document old behaviour. So, I think that two things apply:

* usually there will be only one or two versions used within one page. (On
  IssueTracker two or maybe three, otherwise one)

* when several versions are used within one page, the page is very likely to be
  rather static, i.e., changes will be posted only rarely.

If you could implement this behaviour, I'd be very grateful.

\start
Date: Thu, 1 Sep 2005 18:31:28 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: Unit package question

Page, Bill writes:
 > Now I would like to see what Ralf sketched in Aldor written and
 > demonstrated in about this same level of detail and functionality.
 > 
 > Then perhaps we could code something similar to William's
 > approach (to the extent that I understand that it differs from
 > both Martin and Ralf).

I think that this is a very good idea.

And, I have to say that I think that you are quite right about the amount of
the material. HOWEVER: I dare say that too much documentation (in your sense)
is better than too little documentation.

In fact, I also feel *slightly* (!) at unease with the pamphlet approach. At
least on my computer it does take a little while to display the .dvi file,
searching text in .dvi is not as comfortable as in the .spad file, changing
things in the .pamphlet is not as comfortable either. So I end up experimenting
with the .spad file, then doing an ediff with the old pamphlet. It's ok, but
it's not perfect. An important thing would either be a fantastic pamphlet mode
for emacs or the possibility to retain a little of the documentation in the
source file.

I think that ++, +++ and -- comments might be very helpful in this regard. For
me, personally, it was always obvious that we should maintain the ++ and +++
comments. Meanwhile I think that we should also maintain -- comments. It is not
yet quite clear to me though, what sort of comments should go there so that
they fit in nicely in the pamphlet structure.

Well, I like the quote

"An ideal world is left as an exercise to the reader"...

\start
Date: Thu, 1 Sep 2005 18:52:05 +0200
From: Martin Rubey
To: Kai Kaminski
Subject: axiomui graphics

Dear Kai,

thanks for the update. I tried it and it works. However, the quality of the
graphics is not -- well, not as good as I would have expected. It rather looks
like ascii art. Did I do something wrong?

\start
Date: Thu, 01 Sep 2005 22:12:04 +0200
From: David Mentre
To: Martin Rubey
Subject: Pamplhet mode for emacs (was: Re: Unit package	question)

Hello,

Martin Rubey writes:

> An important thing would either be a fantastic pamphlet mode for emacs
> or the possibility to retain a little of the documentation in the
> source file.

noweb (the tool behind Tim's pamphlets) provides an emacs mode
(noweb-mode). It allows to use simultaneously two modes, latex-mode for
the LaTeX part and another mode for the program part. With most emacs
modes, font coloring and auto indentation is correct (except sometimes
the first line of a code chunk). Maybe you were thinking at more
elaborate things but this is a first start.

For what it's worth, I'm using following code in my .emacs:

;; To have noweb mode automatically
(setq auto-mode-alist
      (append '(("\\.pamphlet$"  . noweb-mode)
                ) auto-mode-alist))

;; many thanks to Hubert Canon <hcanon@alussinan.org> for this code
(add-hook 'noweb-mode-hook 'my-noweb-set-mode-code)
(defun my-noweb-set-mode-code ()
  (let* ((filename (file-name-nondirectory buffer-file-name))
	 (mode (cond ((string-match "^Makefile" filename) 'makefile-mode)
		     ((string-match "\\.lisp\\.pamphlet$" filename) 'lisp-mode)
		     ((string-match "\\.lsp\\.pamphlet$" filename) 'lisp-mode)
		     ((string-match "\\.clisp\\.pamphlet$" filename) 'lisp-mode)
		     ((string-match "\\.c\\.pamphlet$" filename) 'c-mode)
		     ((string-match "\\.h\\.pamphlet$" filename) 'c-mode)
		     ((string-match "\\.ml\\.nw$" filename) 'caml-mode)
		     ((string-match "\\.mli\\.nw$" filename) 'caml-mode)
		     ((string-match "\\.cd\\.nw$" filename) 'caml-mode)
		     ((string-match "\\.c\\.nw$" filename) 'c-mode)
		     ((string-match "\\.h\\.nw$" filename) 'c-mode)
		     ((string-match "\\.xdr\\.nw$" filename) 'c-mode)
		     ((string-match "\\.dtd\\.nw$" filename) 'sgml-mode)
		     ((string-match "\\.ui\\.nw$" filename) 'nxml-mode)
		     (t 'fundamental-mode))))
    (noweb-set-code-mode mode)))

\start
Date: Thu, 01 Sep 2005 21:59:41 +0200
From: Kai Kaminski
To: list
Subject: Re: axiomui graphics

Hi Martin,

thanks for your patience.

> thanks for the update. I tried it and it works. However, the quality of the
> graphics is not -- well, not as good as I would have expected. It rather looks
> like ascii art. Did I do something wrong?
The plots need some improvements, but I don't think that they look
like ASCII art, so presumably something's going wrong.

To find out what it is, please visit kaikaminski.gmxhome.de and look
at the files 1.png, 2.png and 3.png. They correspond to the three plot
commands from the README. If your output doesn't look like this,
something is wrong.

The files 1.svg, 2.svg and 3.svg contain the SVG output from AxiomUI
that is used to display the plots in your browser window. They were
also used to generate the three PNG files with ImageMagick (convert
foo.svg foo.png). Please download them and load them from your
harddisk in your browser (loading them directly off my web site might
not work, because my provider is too stupid to send the correct
content type). If they don't display correctly then there is probably
a problem with your browser's SVG support. All three files are valid
SVG 1.1 according to the W3C validator and ImageMagick, Safari and
Firefox (Deer Park 2 for Linux) display them correctly.

I seem to remember that you're using Konqueror. The version of
Konqueror that is installed on my Linux box (3.4) does not display
them correctly. In fact it only displays a few ASCII letters, some of
which seem to be from the plot title. Is that what you see?

There seems to be an SVG project for Konqueror, but I don't know if
that is already integrated into Konqueror and how well it works. Maybe
upgrading Konqueror helps, maybe it doesn't.

\start
Date: Thu, 01 Sep 2005 18:53:03 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Interval Arithmetic] (new) 

Author -- Mike Dewar

Date Created -- November 1996

Description: --
This category is an implementation of interval arithmetic and
transcendental functions over intervals.

**Note:** -- It appears to be nearly identical to the SPAD category
'interval.spad'.

\begin{aldor}[interval2]

#include "axiom.as"

FUNCAT ==> Join(FloatingPointSystem,TranscendentalFunctionCategory);

define IntervalCategory2(R:FUNCAT): Category ==
 Join(GcdDomain, OrderedSet, TranscendentalFunctionCategory, RadicalCategory,
      RetractableTo(Integer))
 with {
  approximate;
  interval : (R,R) -> %;
    ++ interval(inf,sup) creates a new interval, either \axiom{[inf,sup]} if
    ++ \axiom{inf <= sup} or \axiom{[sup,in]} otherwise.
  qinterval : (R,R) -> %;
    ++ qinterval(inf,sup) creates a new interval \axiom{[inf,sup]}, without
    ++ checking the ordering on the elements.
  interval : R -> %;
    ++ interval(f) creates a new interval around f.
  interval : Fraction Integer -> %;
    ++ interval(f) creates a new interval around f.
  inf : % -> R;
    ++ inf(u) returns the infinum of \axiom{u}.
  sup : % -> R;
    ++ sup(u) returns the supremum of \axiom{u}.
  width : % -> R;
    ++ width(u) returns \axiom{sup(u) - inf(u)}.
  positive? : % -> Boolean;
    ++ positive?(u) returns \axiom{true} if every element of u is positive,
    ++ \axiom{false} otherwise.
  negative? : % -> Boolean;
    ++ negative?(u) returns \axiom{true} if every element of u is negative,
    ++ \axiom{false} otherwise.
  contains? : (%,R) -> Boolean;
    ++ contains?(i,f) returns true if \axiom{f} is contained within the interval
    ++ \axiom{i}, false otherwise.
}

Interval2(R:FUNCAT): IntervalCategory2(R) == add {

  import from Integer;
  import from R;

  Rep ==> Record(Inf:R, Sup:R);

  import from Rep;

  local roundDown(u:R):R == 
    if zero?(u) then float(-1,-(bits() pretend Integer));
                else float(mantissa(u) - 1,exponent(u));

  local roundUp(u:R):R   == 
    if zero?(u) then float(1, -(bits()) pretend Integer);
                else float(mantissa(u) + 1,exponent(u));

  -- Sometimes the float representation does not use all the bits (e.g. when
  -- representing an integer in software using arbitrary-length Integers as
  -- your mantissa it is convenient to keep them exact).  This function 
  -- normalises things so that rounding etc. works as expected.  It is only
  -- called when creating new intervals.
  local normaliseFloat(u:R):R == 
    if zero? u then u else {
    m : Integer := mantissa u;
    b : Integer := bits() pretend Integer;
    l : Integer := length(m);
    if (l < b) then {
      BASE : Integer := base()$R pretend Integer;
      float(m*BASE**((b-l) pretend PositiveInteger),exponent(u)-b+l);
    }
    else
      u;
  }

  interval(i:R,s:R):% == {
    i > s =>  per [roundDown normaliseFloat s,roundUp normaliseFloat i];
    per [roundDown normaliseFloat i,roundUp normaliseFloat s];
  }

  interval(f:R):% == { 
    zero?(f) => 0;
    one?(f)  => 1;
    -- This next part is necessary to allow e.g. mapping between Expressions:
    -- AXIOM assumes that Integers stay as Integers!
    import from Union(value1:Integer,failed:'failed');
    fnew : R := normaliseFloat f;
    retractIfCan(f)@Union(value1:Integer,failed:'failed') case value1 =>
      per [fnew,fnew];
    per [roundDown fnew, roundUp fnew];
  }

  qinterval(i:R,s:R):% ==
    per [roundDown normaliseFloat i,roundUp normaliseFloat s];

  local exactInterval(i:R,s:R):% == per [i,s];
  local exactSupInterval(i:R,s:R):% == per [roundDown i,s];
  local exactInfInterval(i:R,s:R):% == per [i,roundUp s];

  inf(u:%):R == (rep u).Inf;
  sup(u:%):R == (rep u).Sup;
  width(u:%):R == (rep u).Sup - (rep u).Inf;

  contains?(u:%,f:R):Boolean == (f > inf(u)) and (f < sup(u));

  positive?(u:%):Boolean == inf(u) > 0;
  negative?(u:%):Boolean == sup(u) < 0;

  (<)(a:%,b:%):Boolean ==
    if inf(a) < inf(b) then
      true
    else if inf(a) > inf(b) then
      false
    else
      sup(a) < sup(b);

  (+)(a:%,b:%):% == {
    -- A couple of blatent hacks to preserve the Ring Axioms!
    if zero?(a) then return(b) else if zero?(b) then return(a);
    if a=b then return qinterval(2*inf(a),2*sup(a));
    qinterval(inf(a) + inf(b), sup(a) + sup(b));
  }

  (-)(a:%,b:%):% ==  {
    if zero?(a) then return(-b) else if zero?(b) then return(a);
    if a=b then 0 else qinterval(inf(a) - sup(b), sup(a) - inf(b));
  }

  (*)(a:%,b:%):% == {
    -- A couple of blatent hacks to preserve the Ring Axioms!
    if one?(a) then return(b) else if one?(b) then return(a);
    if zero?(a) then return(0) else if zero?(b) then return(0);
    prods : List R :=  sort [inf(a)*inf(b),sup(a)*sup(b),
                             inf(a)*sup(b),sup(a)*inf(b)];
    qinterval(first prods, last prods);
  }

  (*)(a:Integer,b:%):% == {
    if (a > 0) then 
      qinterval(a*inf(b),a*sup(b));
    else if (a < 0) then
      qinterval(a*sup(b),a*inf(b));
    else
      0;
  }

  (*)(a:PositiveInteger,b:%):% == qinterval(a*inf(b),a*sup(b));

  (**)(a:%,n:PositiveInteger):% == {
    contains?(a,0) and zero?((n pretend Integer) rem 2) =>
      interval(0,max(inf(a)**n,sup(a)**n)); 
    interval(inf(a)**n,sup(a)**n);
  }

  (^) (a:%,n:PositiveInteger):% ==  {
    contains?(a,0) and zero?((n pretend Integer) rem 2) => 
      interval(0,max(inf(a)**n,sup(a)**n)); 
    interval(inf(a)**n,sup(a)**n);
  }

  (-)(a:%):% == exactInterval(-sup(a),-inf(a));

  (=)(a:%,b:%):Boolean == (inf(a)=inf(b)) and (sup(a)=sup(b));
  (~=)(a:%,b:%):Boolean == (inf(a)~=inf(b)) or (sup(a)~=sup(b));

  1:% == {one : R := normaliseFloat 1; per([one,one])};
  0:% == per([0,0]);

  recip(u:%):Union(value1:%,failed:'failed') == {
   contains?(u,0) => [failed];
   vals:List R := sort[1/inf(u),1/sup(u)];
   [qinterval(first vals, last vals)];
  }

  unit?(u:%):Boolean == contains?(u,0);

  exquo(u:%,v:%):Union(value1:%,failed:'failed') == {
   contains?(v,0) => [failed];
   one?(v) => [u];
   u=v => [1];
   u=-v => [-1];
   vals:List R := sort[inf(u)/inf(v),inf(u)/sup(v),sup(u)/inf(v),sup(u)/sup(v)];
   [qinterval(first vals, last vals)];
  }

  gcd(u:%,v:%):% == 1;

  coerce(u:Integer):% == {
    ur := normaliseFloat(u::R);
    exactInterval(ur,ur);
  }

  interval(u:Fraction Integer):% == {
    import { log2 : % -> %;
             coerce : Integer -> %;
             retractIfCan : % -> Union(value1:Integer,failed:'failed');}
    from Float;
    flt := u::R;

    -- Test if the representation in R is exact
    --den := denom(u)::Float;
    local bin : Union(value1:Integer,failed:'failed');
    bin := retractIfCan(log2(denom(u)::Float));
    bin case value1 and length(numer u)$Integer < (bits() pretend Integer) => {
      flt := normaliseFloat flt;
      exactInterval(flt,flt);
    }

    qinterval(flt,flt);
  }

  retractIfCan(u:%):Union(value1:Integer,failed:'failed') == {
    not zero? width(u) => [failed];
    retractIfCan inf u;
  }

  retract(u:%):Integer == {
    not zero? width(u) =>
      error "attempt to retract a non-Integer interval to an Integer";
    retract inf u;
  }

  coerce(u:%):OutputForm ==
    bracket([coerce inf(u), coerce sup(u)]$List(OutputForm));

  characteristic():NonNegativeInteger == 0;


  -- Explicit export from TranscendentalFunctionCategory
  pi():% == qinterval(pi(),pi());

  -- From ElementaryFunctionCategory
  log(u:%):% == {
    positive?(u) => qinterval(log inf u, log sup u);
    error "negative logs in interval";
  }

  exp(u:%):% == qinterval(exp inf u, exp sup u);

  (**)(u:%,v:%):% == {
    zero?(v) => if zero?(u) then error "0**0 is undefined" else 1;
    one?(u)  => 1;
    expts : List R :=  sort [inf(u)**inf(v),sup(u)**sup(v),
                             inf(u)**sup(v),sup(u)**inf(v)];
    qinterval(first expts, last expts);
  }

  -- From TrigonometricFunctionCategory

  -- This function checks whether an interval contains a value of the form
  -- `offset + 2 n pi'.
  local hasTwoPiMultiple(offset:R,Pi:R,i:%):Boolean == {
    import from Integer;
    next : Integer := retract ceiling( (inf(i) - offset)/(2*Pi) );
    contains?(i,offset+2*next*Pi);
  }

  -- This function checks whether an interval contains a value of the form
  -- `offset + n pi'.
  local hasPiMultiple(offset:R,Pi:R,i:%):Boolean == {
    import from Integer;
    next : Integer := retract ceiling( (inf(i) - offset)/Pi );
    contains?(i,offset+next*Pi);
  }

  sin(u:%):% == {
    import from Integer;
    Pi : R := pi();
    hasOne? : Boolean := hasTwoPiMultiple(Pi/(2::R),Pi,u);
    hasMinusOne? : Boolean := hasTwoPiMultiple(3*Pi/(2::R),Pi,u);

    if hasOne? and hasMinusOne? then 
      exactInterval(-1,1);
    else {
      vals : List R := sort [sin inf u, sin sup u];
      if hasOne? then
        exactSupInterval(first vals, 1);
      else if hasMinusOne? then
        exactInfInterval(-1,last vals);
      else
        qinterval(first vals, last vals);
    }
  }

  cos(u:%):% == {
    Pi : R := pi();
    hasOne? : Boolean := hasTwoPiMultiple(0,Pi,u);
    hasMinusOne? : Boolean := hasTwoPiMultiple(Pi,Pi,u);

    if hasOne? and hasMinusOne? then 
      exactInterval(-1,1);
    else {
      vals : List R := sort [cos inf u, cos sup u];
      if hasOne? then
        exactSupInterval(first vals, 1);
      else if hasMinusOne? then
        exactInfInterval(-1,last vals);
      else
        qinterval(first vals, last vals);
    }
  }

  tan(u:%):% == {
    Pi : R := pi();
    if width(u) > Pi then
      error "Interval contains a singularity"
    else {
      -- Since we know the interval is less than pi wide, monotonicity implies
      -- that there is no singularity.  If there is a singularity on a endpoint
      -- of the interval the user will see the error generated by R.
      lo : R := tan inf u; 
      hi : R := tan sup u;

      lo > hi => error "Interval contains a singularity";
      qinterval(lo,hi);
    }
  }

  csc(u:%):% == {
    Pi : R := pi();
    if width(u) > Pi then
      error "Interval contains a singularity"
    else {
      import from Integer;
      -- singularities are at multiples of Pi
      if hasPiMultiple(0,Pi,u) then error "Interval contains a singularity";
      vals : List R := sort [csc inf u, csc sup u];
      if hasTwoPiMultiple(Pi/(2::R),Pi,u) then 
        exactInfInterval(1,last vals);
      else if hasTwoPiMultiple(3*Pi/(2::R),Pi,u) then
        exactSupInterval(first vals,-1);
      else
        qinterval(first vals, last vals);
    }
  }

  sec(u:%):% == {
    Pi : R := pi();
    if width(u) > Pi then
      error "Interval contains a singularity"
    else {
      import from Integer;
      -- singularities are at Pi/2 + n Pi
      if hasPiMultiple(Pi/(2::R),Pi,u) then
        error "Interval contains a singularity";
      vals : List R := sort [sec inf u, sec sup u];
      if hasTwoPiMultiple(0,Pi,u) then 
        exactInfInterval(1,last vals);
      else if hasTwoPiMultiple(Pi,Pi,u) then
        exactSupInterval(first vals,-1);
      else
        qinterval(first vals, last vals);
    }
  }


  cot(u:%):% == {
    Pi : R := pi();
    if width(u) > Pi then
      error "Interval contains a singularity"
    else {
      -- Since we know the interval is less than pi wide, monotonicity implies
      -- that there is no singularity.  If there is a singularity on a endpoint
      -- of the interval the user will see the error generated by R.
      hi : R := cot inf u; 
      lo : R := cot sup u;

      lo > hi => error "Interval contains a singularity";
      qinterval(lo,hi);
    }
  }

  -- From ArcTrigonometricFunctionCategory

  asin(u:%):% == {
    lo : R := inf(u);
    hi : R := sup(u);
    if (lo < -1) or (hi > 1) then error "asin only defined on the region -1..1";
    qinterval(asin lo,asin hi);
  }

  acos(u:%):% == {
    lo : R := inf(u);
    hi : R := sup(u);
    if (lo < -1) or (hi > 1) then error "acos only defined on the region -1..1";
    qinterval(acos hi,acos lo);
  }

  atan(u:%):% == qinterval(atan inf u, atan sup u);

  acot(u:%):% == qinterval(acot sup u, acot inf u);

  acsc(u:%):% == {
    lo : R := inf(u);
    hi : R := sup(u);
    if ((lo <= -1) and (hi >= -1)) or ((lo <= 1) and (hi >= 1)) then
      error "acsc not defined on the region -1..1";
    qinterval(acsc hi, acsc lo);
  }

  asec(u:%):% == {
    lo : R := inf(u);
    hi : R := sup(u);
    if ((lo < -1) and (hi > -1)) or ((lo < 1) and (hi > 1)) then
      error "asec not defined on the region -1..1";
    qinterval(asec lo, asec hi);
  }

  -- From HyperbolicFunctionCategory

  tanh(u:%):% == qinterval(tanh inf u, tanh sup u);

  sinh(u:%):% == qinterval(sinh inf u, sinh sup u);

  sech(u:%):% == {
    negative? u => qinterval(sech inf u, sech sup u);
    positive? u => qinterval(sech sup u, sech inf u);
    vals : List R := sort [sech inf u, sech sup u];
    exactSupInterval(first vals,1);
  }

  cosh(u:%):% == {
    negative? u => qinterval(cosh sup u, cosh inf u);
    positive? u => qinterval(cosh inf u, cosh sup u);
    vals : List R := sort [cosh inf u, cosh sup u];
    exactInfInterval(1,last vals);
  }

  csch(u:%):% == {
    contains?(u,0) => error "csch: singularity at zero";
    qinterval(csch sup u, csch inf u);
  }

  coth(u:%):% == {
    contains?(u,0) => error "coth: singularity at zero";
    qinterval(coth sup u, coth inf u);
  }

  -- From ArcHyperbolicFunctionCategory

  acosh(u:%):% == {
    inf(u)<1 => error "invalid argument: acosh only defined on the region 1..";
    qinterval(acosh inf u, acosh sup u);
  }

  acoth(u:%):% == {
    lo : R := inf(u);
    hi : R := sup(u);
    if ((lo <= -1) and (hi >= -1)) or ((lo <= 1) and (hi >= 1)) then
      error "acoth not defined on the region -1..1";
    qinterval(acoth hi, acoth lo);
  }

  acsch(u:%):% == {
    contains?(u,0) => error "acsch: singularity at zero";
    qinterval(acsch sup u, acsch inf u);
  }

  asech(u:%):% == {
    lo : R := inf(u);
    hi : R := sup(u);
    if  (lo <= 0) or (hi > 1) then 
      error "asech only defined on the region 0 < x <= 1";
    qinterval(asech hi, asech lo);
  }

  asinh(u:%):% == qinterval(asinh inf u, asinh sup u);

  atanh(u:%):% == {
    lo : R := inf(u);
    hi : R := sup(u);
    if  (lo <= -1) or (hi >= 1) then 
      error "atanh only defined on the region -1 < x < 1";
    qinterval(atanh lo, atanh hi);
  }

  -- From RadicalCategory
  (**)(u:%,n:Fraction Integer):% == interval(inf(u)**n,sup(u)**n);
  
}
\end{aldor}

\begin{axiom}
x:=interval(1.1,2.2)$Interval2(Float)
sin(x)
\end{axiom}

\start
Date: Thu, 01 Sep 2005 18:56:46 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AldorForAxiom] 

See also the more complex examples:

- [RandomAlgebra]

- [FormalFraction]

- [Interval Arithmetic]

\start
Date: Thu, 1 Sep 2005 20:30:47 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package question - part 1

--- William Sit wrote:
>
> Dear C Y:
>
> This long-winded email started more than a week ago and school
> started got in the way. In addition, computer problems, mainly: 
> network and crashing OS without saving :-( , but also some hardware
> ones. 

Wee, fun ;-)

> I am glad to know that you are working on this project. I meant to 
> form the ideas below more thoroughly before posting them but I see 
> you have already started real work. 

That's probably too generous - I've started trying to become informed
enough to start real work, really.  Bill is probably going to flinch
when he sees my idea of basic pre-code (heck, it's really pure
background) documentation :-).

> So I hope these new suggestions, incomplete as they may be,
> perhaps should be made known to you and we can discuss this 
> and if I got time to revise them (probably during labor day 
> weekend), I'll do so. 

No hurry - you're still far ahead of me when it comes to thinking about
Units/Dimensions in Axiom.  Indeed, you've introduced a new idea I
really like which alters my thinking about basic term definitions that
need to be made and used (more on that later ;-).  I'll reply in parts,
since it's too long for me to have time to sit down and go through at
once.

> It seems that a thorough study of dimensions and units in 
> relation to symbolic computations is not available and your 
> work/paper would be very useful.

I hope so, although I suspect your ideas are far more useful than my
own - I'm just asking questions and swatting user level features around
in my head at this point.  The hard part (and interesting part) is
expressing them in relation to Axiom's mathematical rigor.

> I think we are in general agreement regarding how to implement 
> the UnitSystem domains. Your provoking questions led me to propose 
> modifications to the original scheme (and even that, is far from a 
> final design as I have been changing them constantly as I write). 

Reminds me of working on the Maxima package - I defined several
functions I only realized I would want after I began writing the basic
user documentation.  I think I might still be having conceptual
trainwreaks in my head because of the work on Maxima - some of my
comments below might be a result of this :-/.

> The new scheme hopefully will solve some of the design problems 
> we discussed. I hope before long the new proposal will
> approach a practical one. After waiting a short period of further
> discussions, a summary of the final design should be posted at 
> MathAction for others to comment on. 

Sounds good.  I apologize in advance for how basic some of my questions
below will be - I tried to review as much as possible of earlier
discussions, but I may have regressed some after a rather busy week at
work. 

> I actually prefer your use of ")set UnitSystem ..." to ")set unit
> ...". But note ")set UnitSystem" IS setting the session default for
> the user. Axiom allows a user to set his preferences in a file 
> called axiom.input (which is in the directory $AXIOM/input). 

Off topic, but shouldn't it be checking $HOME/.axiom or some such as
well?  Or is it assumed that a user has write access to $AXIOM?

> So by putting ")set UnitSystem MYUnitSystem" in that file, Axiom 
> will use MYUNitSystem as the default unit system when the 
> functions 'unitMass' etc (to be grouped into a new function
> 'setDim', see below) are called.  MYUnitSystem can be SI, CGS,
> or some modified version of the standard SI (but once modified, 
> it should be called something else). 

This isn't quite what I was thinking - I was thinking by default Axiom
could use a unit system called CurrentUnitSystem, which would be
somewhat different in definition from SI, CGS, etc.  Doing 

)set UnitSystem SI

would drop the user in a strict SI output only environment without the
possibility of local override, which I have no problem with.  (Might
even be a good idea to have available, really - call it a STATIC
UnitSystem definition.)  What i would like CurrentUnitSystem to do is
be a DYNAMIC UnitSystem, using either the system you have outlined
below or something similar.  It would start out as an instance of the
SI definitions by default, but allow local overrides dynamically (hence
a Dynamic UnitSystem definition).  Also useful would be a
SaveUnitSystem(<NewUnitSystemName>) for later use - essentially
allowing a user to load a precustomized Dynamic UnitSystem Definition
as the working UnitSystem.  With a Dynamic UnitSystem Definition we
could have a MapUnitSystem(<UnitSystem name>) command to allow the user
to restore all STATIC SI definitions (say) to the CurrentUnitSystem. 
Is that following what you had in mind?

> Of course, this needs some code or setup to modify the
> interpreter, but it can be done (Tim Daly or Bill Page 
> would no doubt know how and can assist you when that time 
> comes). Most likely, it is a matter of adding one or two 
> lines to a database.

Yes, that's certainly something we will want to do.  (I'm still
plotting to allow the user to gobble up all the unit names in the
default namespace at their option, and that will DEFINITELY need
interpreter work. 

> As for tools to do the dynamic modification from standard unit
> systems like SI, here are several changes to the previous setup 
> that will facilitate this and improve the organization of the 
> domains as well. 

Did you intend to use this setup for ALL UnitSystems or just what I've
termed Dynamic UnitSystems?  (Sorry if I should have caught this.)

[snip - need to ponder some.]

> [Comments: The ideas from now on are more or less well formed.
> However, I have not finished rearranging these in a more logical 
> sequence. So read it a few times! I might have made some obsolete 
> claims as I reorganized my thoughts without revising the claims.]

I'll try :-).

> FIRST: Consolidate all the unitXXX and setUnitXXX functions to::
>
> UnitSystemCategory(S: SetCategory):Category == Exports where
>
>  Dimension ==> Union("Mass", "Length", ...)
>  Unit ==> Union("kg", "m", ...)
>  Join(RetractableTo S,...) with 
>   
>    setDimUnit: (Dimension, Unit, S) -> %
>    setUnit: (Dimension, Unit) -> Null (?)
>    setUnitAll: (Dimension, Unit) -> Null (?)
>
> where 'setDimUnit(dim, unit, s)' is a LOCAL command affecting ONLY 
> s:S, and 'setUnit(dim, unit)' would be a GLOBAL command affecting
> ALL s:S (more on this later).  Null may be replaced with a new 
> state vector?

I don't quite understand s:S - can you give a specific example of this
difference?  Also, I'm not following why you would want to make any
local vs. global distinctions here - wouldn't it be neater just to have
the set commands work in the CurrentUnitSystem, and base things off of
Static UnitSystems for definitions unless a totally custom conversion
is being defined?  Working in a Static UnitSystem no set commands are
either possible or necessary (and thus shouldn't work) and in a Dynamic
UnitSystem (of which there will normally be only one - the working one)
the Static UnitSystems provide the information to use in the Dynamic
one?

I would have thought all you needed was a single command SetUnits()
command, which would take a minimum of one argument and a max of one
unit per available dimension, e.g.

SetUnits(nm,N,inches);

In the CurrentUnitSystem Dynamic UnitSystem (assuming things are in
default mode) the "state vectors" for the dimensions corresponding to
the units entered would be updated.  It's not clear to me why you would
need any other arguments, unless you wanted to make sure the user knows
the dimension of the unit they are inputing as a default.  Dimensions
may not always map uniquely to Units, but Units DO map uniquely to
dimensions.  Couldn't Axiom figure this out?  All it has to do is
determine the dimension of each argument, check that all dimensions are
unique, and set the defaults (the setunits command in Maxima works this
way.)  We ARE back to some parser being able to check all units for a
match to the input unit, I guess. Is that why you're adding the extra
arguments - to avoid Axiom needing to figure out that nm is a Length
defined in the SI UnitSystem?  Maybe I place too much emphasis on user
convenience but I as a user would prefer not to tell Axiom things it
already knows.  Maybe as a time saving alternative SetUnits could also
accept things of the form <UnitSystem>::Unit or some such, which would
limit the search space it would need to check?  Or even better, if
Axiom is up to it we might also be able to build a toplevel hash table
of all defined units in all unit systems at compile time which can
quickly match up a unit up with a UnitSystem and Dimension.  Since
Static UnitSystems wouldn't be changable in a normal session anyway (at
least without editing the source and reloading, which hopefully would
also mandate a rebuild of the hash tree) it would be a one time expense
and would enable considerable user convenience at many levels.  In the
SetUnits usage it doesn't even need to use up toplevel namespace, and
if a user DID want to populate the toplevel namespace it would be a big
speedup for the interperter to be able to hash a symbol to check if it
is a unit.

> Note that the way Dimension and Unit are defined (as Union("Mass",
> "Length",...) and Union("slug", "ft", ...)) is very close to making
> each dimension and unit a domain of its own, except that here each 
> domain consists of just its name(string). You may also consult the 
> way BasicOperators and CommonOperators are designed, but at least 
> for the moment, the simpler setup probably suffices.
>
> SECOND: To support the implementation for 'setUnit' (a dynamical 
> change of units), I propose to add a state vector for each unit 
> system domain: this state vector stores the current unit for each 
> dimension, which is updated by the 'setUnit' command. The
> 'setDimUnit' command can check this state vector before generating
> the Rep (see below). Some care has to be considered: we have to
> decide whether a 'setUnit(dim, unit)' command should affect the
> other derived units that depends on 'dim' or not, and also those 
> the variables whose dimensions were set before this 'setUnit' 
> command and invole 'dim'. I have added 'setUnitAll' for the case 
> every current variable will be updated.

I don't think I'm quite following - Derived Units are defined in terms
of the Base Units for their UnitSystem - just because we are now using
"cm" instead of "m" as our default length doesn't change the definition
of N, or how many Newtons we have.  If we want to report a Derived Unit
in terms of Base Units, then we would want to use cm instead of m, but
otherwise I'm afraid I'm missing something.

As for current variables, shouldn't they be updated automatically by
the global update?

\start
Date: Fri, 02 Sep 2005 02:26:32 -0500
From: MathAction (unknown)
To: MathAction
Subject: [Interval Arithmetic] 

Reason that it looks like interval.spad is that I rewrote interval.as
for the SPAD compiler, so that we are able to run Axiom without
Aldor. Juergen Weiss

\start
Date: Fri, 2 Sep 2005 10:16:52 +0200
From: Martin Rubey
To: Kai Kaminski
Subject: Re: axiomui graphics

Dear Kai,

 > The plots need some improvements, but I don't think that they look like
 > ASCII art, so presumably something's going wrong.

yes.

 > To find out what it is, please visit kaikaminski.gmxhome.de and look at the
 > files 1.png, 2.png and 3.png. They correspond to the three plot commands
 > from the README. If your output doesn't look like this, something is wrong.

indeed, something is wrong.
 > 
 > The files 1.svg, 2.svg and 3.svg contain the SVG output from AxiomUI that is
 > used to display the plots in your browser window. They were also used to
 > generate the three PNG files with ImageMagick (convert foo.svg
 > foo.png). Please download them and load them from your harddisk in your
 > browser (loading them directly off my web site might not work, because my
 > provider is too stupid to send the correct content type). If they don't
 > display correctly then there is probably a problem with your browser's SVG
 > support. All three files are valid SVG 1.1 according to the W3C validator
 > and ImageMagick, Safari and Firefox (Deer Park 2 for Linux) display them
 > correctly.

I only have Mozilla (Konqueror doesn't work at all, as I reported earlier on),
and rendering the svg files from your website results in something that looks
quite like your plots, just using ASCII art...

Don't know what to do, but I think I'll just wait until Konqueror is supported,
since I don't want to use Mozilla anyway. I was using

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
Adobe SVG Viewer plug-in version 3.01x88


\start
Date: Fri, 2 Sep 2005 10:26:54 +0200
From: Martin Rubey
To: Kai Kaminski
Subject: axiomui on Konqueror

I just tried the svg-graphics on konqueror: to my great surprise, they worked
without a problem... So maybe it's easier to fix Konqueror support :-)

The "only" thing which doesn't work is: when you press enter in the toplevel,
nothing happens...

\start
Date: Fri, 2 Sep 2005 12:11:26 +0200
From: Martin Rubey
To: list
Subject: Re: axiomui 
Cc: Kai Kaminski

Just another question:

is SVG capable of doing the things that the axiom viewer axiom2D and axiom3D
can do? 


Martin Rubey writes:
 > I just tried the svg-graphics on konqueror: to my great surprise, they worked
 > without a problem... So maybe it's easier to fix Konqueror support :-)
 > 
 > The "only" thing which doesn't work is: when you press enter in the toplevel,
 > nothing happens...

\start
Date: Fri, 02 Sep 2005 12:11:26 +0200
From: Kai Kaminski
To: Martin Rubey
Subject: re: axiomui graphics

Hi Martin!

Martin Rubey writes:

>  > The files 1.svg, 2.svg and 3.svg contain the SVG output from AxiomUI that is
>  > used to display the plots in your browser window. They were also used to
>  > generate the three PNG files with ImageMagick (convert foo.svg
>  > foo.png). Please download them and load them from your harddisk in your
>  > browser (loading them directly off my web site might not work, because my
>  > provider is too stupid to send the correct content type). If they don't
>  > display correctly then there is probably a problem with your browser's SVG
>  > support. All three files are valid SVG 1.1 according to the W3C validator
>  > and ImageMagick, Safari and Firefox (Deer Park 2 for Linux) display them
>  > correctly.
>
> I only have Mozilla (Konqueror doesn't work at all, as I reported earlier on),
> and rendering the svg files from your website results in something that looks
> quite like your plots, just using ASCII art...
So they look a very different from the PNG files, I suppose? Do you
like the PNG plots or don't you like them either. The reason I ask is
that it might be reasonably easy to send PNG to the browser instead or
provide that as an option at least. In fact PNG support would be nice
anyway, since then we could display Axiom plots in Emacs.

> Don't know what to do, but I think I'll just wait until Konqueror is supported,
> since I don't want to use Mozilla anyway. I was using
>
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
> Adobe SVG Viewer plug-in version 3.01x88
There are two potential problems I can think of. First of all SVG
support is still somewhat shaky in Mozilla and Firefox, so you might
have to use a development build. I wouldn't recommend this, though,
since Firefox 1.5 is due in a few days. The second problem is that
with some Mozilla/Firefox builds one has to enable SVG support
first. To do that, load about:config and look for an option like
svg_enabled and set it to true.

Thanks for your patience,

\start
Date: Fri, 2 Sep 2005 12:47:18 +0200
From: Martin Rubey
To: Kai Kaminski
Subject: re: axiomui graphics

Kai Kaminski writes:
 > Hi Martin!
 > 
 > > I only have Mozilla (Konqueror doesn't work at all, as I reported earlier
 > > on), and rendering the svg files from your website results in something
 > > that looks quite like your plots, just using ASCII art...

 > So they look a very different from the PNG files, I suppose? 

yes.

 > Do you like the PNG plots or don't you like them either.

The plots themselves are good. But in png I assume there is no panning,
zooming, rotating, ...

 > The reason I ask is that it might be reasonably easy to send PNG to the
 > browser instead or provide that as an option at least. In fact PNG support
 > would be nice anyway, since then we could display Axiom plots in Emacs.

yes.

 > > Don't know what to do, but I think I'll just wait until Konqueror is supported,
 > > since I don't want to use Mozilla anyway. I was using
 > >
 > > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
 > > Adobe SVG Viewer plug-in version 3.01x88

 > There are two potential problems I can think of. First of all SVG support is
 > still somewhat shaky in Mozilla and Firefox, so you might have to use a
 > development build. I wouldn't recommend this, though, since Firefox 1.5 is
 > due in a few days. The second problem is that with some Mozilla/Firefox
 > builds one has to enable SVG support first. To do that, load about:config
 > and look for an option like svg_enabled and set it to true.

There is no such option as svg_enabled in my about:config. I suppose that my
Mozilla is too old. Note however, that it does "work". Only the quality is
*very* low.

My Konqueror is 3.1.4.

\start
Date: Fri, 02 Sep 2005 15:49:09 +0100
From: Peter Broadbery
To: Bill Page
Subject: RE: aldor for axiom

On Mon, 2005-08-29 at 22:11 -0400, Bill Page wrote:
> > Also, I have javac 1.5.0_04. Can I assume you don't actually REQUIRE
> > javac 1.5.0_03?
> 
> Yes. In fact I am not 100% sure that it is Sun's JDK 1.5.x that is
> required but I have verified that it works. Peter never said exactly
> what java compiler he is using.
> 
> It would be nice if one could use the GNU gcj compiler. But my first
> attempt to do that failed so I assumed he was talking about Sun's java.
> 

I'm using java 1.4.2, and it should work with pretty much any java
supporting 1.3 or later.  

\start
Date: Fri, 02 Sep 2005 15:38:39 +0100
From: Peter Broadbery
To: Tim Daly
Subject: Re: patches

On Mon, 2005-08-29 at 22:16 -0400, root wrote:
> Peter,
> 
> I don't see any obvious reason why your patches can't be permanently
> applied to the axiom sources. Did I miss something that would break
> if aldor is not around?
> 

Patches should be fine, they're independent of the libaxiom.al build.

\start
Date: 02 Sep 2005 11:09:24 -0400
From: Camm Maguire
To: Tim Daly
Subject: Axiom sources for Debian release with 2.6.7

Greetings!  There are just a few probe-file -> truename patches
required.  Should I apply these to the April 2005 sources and make a
Debian release?  Or is there a later official savannah version coming?

\start
Date: Fri, 2 Sep 2005 11:46:24 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Axiom sources for Debian release with 2.6.7

On September 2, 2005 11:09 AM Camm Maguire wrote:
> 
> Greetings!  There are just a few probe-file -> truename patches
> required.  Should I apply these to the April 2005 sources and
> make a Debian release?  Or is there a later official savannah
> version coming?
> 

There are some patches emminent to support the Aldor integration.
With those in place the optional install of the Aldor binaries
would be much easier.

Wouldn't it be great to have Aldor on Debian?

I am very much in favor of Martin Rubey's suggestion that we
petition Stephen Watt to release Aldor as open source. Or perhaps
we might be able to convince him to let the Axiom Foundation
release Aldor.

What do you think?

\start
Date: Fri, 2 Sep 2005 12:44:57 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom sources for Debian release with 2.6.7

Camm,

I applied some probe-file -> truename patches already.
Should this conversion be universally applied?
If so I can just wander thru the sources and do it.

\start
Date: 02 Sep 2005 12:27:23 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Axiom sources for Debian release with 2.6.7

Greetings!

<Bill Page> writes:

> On September 2, 2005 11:09 AM Camm Maguire wrote:
> > 
> > Greetings!  There are just a few probe-file -> truename patches
> > required.  Should I apply these to the April 2005 sources and
> > make a Debian release?  Or is there a later official savannah
> > version coming?
> > 
> 
> There are some patches emminent to support the Aldor integration.
> With those in place the optional install of the Aldor binaries
> would be much easier.
> 
> Wouldn't it be great to have Aldor on Debian?
> 
> I am very much in favor of Martin Rubey's suggestion that we
> petition Stephen Watt to release Aldor as open source. Or perhaps
> we might be able to convince him to let the Axiom Foundation
> release Aldor.
> 
> What do you think?
> 

One other item -- Debian is migrating to gcc-4.0, which entails a
non-binary-compatible lbrary change.  Axiom as currently packaged is
now uninstallable in Debian unstable, so I'd like to resolve this
quickly.  I can either patch what I have (20050201, or use this
opportunity to upgrade the sources.  Suggestions?

\start
Date: Fri, 02 Sep 2005 12:28:00 -0400
From: William Sit
To: Tim Daly
Subject: Re: axiom in multiuser environment

C Y wrote (Unit package question - part 1)
> 
> --- William Sit wrote:
> > I actually prefer your use of ")set UnitSystem ..." to ")set unit
> > ...". But note ")set UnitSystem" IS setting the session default for
> > the user. Axiom allows a user to set his preferences in a file
> > called axiom.input (which is in the directory $AXIOM/input).
> 
> Off topic, but shouldn't it be checking $HOME/.axiom or some such as
> well?  Or is it assumed that a user has write access to $AXIOM?

Tim: that shouldn't be hard, right? (I know, there is no such thing as a simple
job).  Put some of the user-specific configuration file like axiom.input in the
user's home directory as a $HOME/.axiom file? Obviously such setup is not
portable, but possible and desirable if the PC is no longer "personal".

\start
Date: Fri, 2 Sep 2005 12:38:20 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom sources for Debian release with 2.6.7

Camm,

apply the changes, do a 
   diff -Naur original changed >changed.patch
and send me the patch files. I'll merge them into the
sources and test them before release.

I've applied Peter's changes as well as a few of my own and
I'm in the process of testing the --patch-45 release at the
moment. I expect it to go out real-soon-now.

\start
Date: 02 Sep 2005 12:25:59 -0400
From: Camm Maguire
To: Bill Page
Subject: Re: Axiom sources for Debian release with 2.6.7

Greetings!

<Bill Page> writes:

> On September 2, 2005 11:09 AM Camm Maguire wrote:
> > 
> > Greetings!  There are just a few probe-file -> truename patches
> > required.  Should I apply these to the April 2005 sources and
> > make a Debian release?  Or is there a later official savannah
> > version coming?
> > 
> 
> There are some patches emminent to support the Aldor integration.
> With those in place the optional install of the Aldor binaries
> would be much easier.
> 
> Wouldn't it be great to have Aldor on Debian?
> 
> I am very much in favor of Martin Rubey's suggestion that we
> petition Stephen Watt to release Aldor as open source. Or perhaps
> we might be able to convince him to let the Axiom Foundation
> release Aldor.
> 
> What do you think?
> 

Not being particularly familiar with Aldor and its capabilities, I can
infer from the comments I've heard here about it that it is well worth
releasing if possible.  I thought there were some licensing issues
outstanding.  If these can be resolved, I'd be most happy to package
for Debian and add to the effective gcl regression/application suite
of maxima,acl2 and axiom.  Does Aldor require axiom?

Am afraid I'm a bit short on time right now for corresondence, so it
would be most helpful if someone else could get release permission
commensurate with the DFSG.

\start
Date: Fri, 2 Sep 2005 12:41:38 -0400
From: Tim Daly
To: William Sit
Subject: Re: axiom in multiuser environment

I can add
 )set 
commands with defaults if desired. We just have to agree on the
reasons, the names, and the values.

There is a tree of variable initializations in src/interp/setvart

\start
Date: 02 Sep 2005 19:16:36 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Axiom sources for Debian release with 2.6.7
Cc: Allen Rouse

Greetings!

Tim Daly writes:

> Camm,
> 
> apply the changes, do a 
>    diff -Naur original changed >changed.patch
> and send me the patch files. I'll merge them into the
> sources and test them before release.
> 
> I've applied Peter's changes as well as a few of my own and
> I'm in the process of testing the --patch-45 release at the
> moment. I expect it to go out real-soon-now.
> 

Just had to make this vs the existing Debian package:
--- ./src/interp/daase.lisp.pamphlet.orig	2005-07-18 20:15:56.000000000 +0000
+++ ./src/interp/daase.lisp.pamphlet	2005-07-18 20:08:00.000000000 +0000
@@ -840,7 +840,7 @@
  (let (thisdir nrlibs asos asys libs object only dir key 
       (|$forceDatabaseUpdate| t) noexpose)
   (declare (special |$forceDatabaseUpdate|))
-  (setq thisdir (namestring (probe-file ".")))
+  (setq thisdir (namestring (truename ".")))
   (setq noexpose nil)
   (multiple-value-setq (only dir noexpose) (processOptions options))
      ;don't force exposure during database build
@@ -1106,12 +1106,12 @@
   (setq *compressvector* nil)
   (withSpecialConstructors)
   (localdatabase nil
-     (list (list '|dir| (namestring (probe-file "./")) ))
+     (list (list '|dir| (namestring (truename "./")) ))
      'make-database)
   (dolist (dir dirlist)
 	  (localdatabase nil 
 			 (list (list '|dir| 
-				     (namestring (probe-file 
+				     (namestring (truename 
 						  (format nil "./~a" 
 							  dir)))))
 			 'make-database))


No need to abandon probe-file if your just trying to see if a certain
*file* exists.  If you are trying to get a full path, that's what
truename is for.

If you want the other patches I currently have in the Debian package
vs 20050201 (previously posted to the list) again, please let me know.

Take care, and thanks for your work on Axiom!!!

BTW, is there an FC4 fix I can apply to the code, or does FC4 require
root disabling of certain randomization via

echo 0 > /proc/sys/kernel/randomize_va_space

?  

May need a small 2.6.7 errata for ia64 and arm in any case.

\start
Date: Fri, 2 Sep 2005 19:49:13 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom sources for Debian release with 2.6.7
Cc: Allen Rouse

re: patch. thx.

re: FC4 fix

not there yet. i'm build/debugging on several different paths at the
same time (FC4, FreeBSD, the Sept release, Windows) and I'm lagged.
I'll try the echo and let you know...

\start
Date: Fri, 02 Sep 2005 22:14:50 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Interval Arithmetic] Thanks

Juergen Weiss wrote:

>  I rewrote interval.as for the SPAD compiler

Oh yes, I am sorry that I forgot. I think your important contribution
should be so noted in the interval.spad.pamphlet file! Here's a
patch.
<pre>
$ diff -Nar interval.spad.pamphlet.orig interval.spad.pamphlet
5c5
< \author{Mike Dewar}
---
> \author{Juergen Weiss}
7a8,9
> This is a re-write of `interval.as' in SPAD to enable all of
> Axiom's library to be compiled without the Aldor compiler.
15c17
< +++ Author: Mike Dewar
---
> +++ Original Author: Mike Dewar
</pre>

\start
Date: Fri, 2 Sep 2005 23:02:35 -0400
From: Cliff Yapp
To: William Sit, Cliff Yapp
Subject: Re: Unit package question - Reply to 1st half

On Thursday 01 September 2005 07:33 am, William Sit wrote:

> SECOND: Extend the Rep in these domains to include units and conversion
> factors.
>
>    Rep:=Record(value:S, dim:Dimension, unit:Unit, factor:(Float, String),
>                absfactor:(Float, String))
>
> My original proposed Rep is simpler because I was not planning for dynamic
> changes to the unit system, so unit and factor (which would be 1 always)
> are "hard-wired". The more general record allows more flexibility. This is
> slightly less efficient in terms of storage, but not that bad, because no
> matter what, somewhere, the system has to store the conversion factors. The
> conversion factors can probably be implemented in a UnitConversion domain,
> which would be a lookup table (maybe tables), which drives the 'setDimUnit'
> and 'setUnit' commands. Axiom has a number of data structures with
> extensive tools to create lookup tables (see domains of category
> TableAggregate in table.spad).

That sounds good, I think - I would propose using this more general, flexible 
representation only in a single instance of a Dynamic UnitSystem - SI and CGS 
wouldn't need it, if I understand correctly.

> In the new Rep, besides the unit, two factors are included: One relative to
> the current system (to provide a relative factor to convert within this
> system when a user changes a unit, and one relative to SI (to provide an
> absolute factor to convert between systems: for SI derived unit system,
> just one factor would suffice; but we should aim for uniformity to simplify
> the code). 

Generality is good, but I'm afraid I'm not following - for any given Unit, 
wouldn't all you need to know be the description of that unit in terms of SI?  
Or are you proposing that all UnitSystems use this extended storage record?  
I would suggest using it only for the Dynamic UnitSystems, and then you have 
the flexibility to define new units in terms of SI which have no existing 
Static definition.

> Each factor has both a value (Float) and a name (String). The 
> value of the factor is when numerical output is needed, that is, when S is
> coerced to Float (via the "lift" mechanism). The name would be used in
> output for symbolic computations to indicate a conversion factor is needed,
> without spoiling the elegance of symbolic computation or more importantly,
> going outside the domain S. It is only a decoration in the output (so it
> can be used with even Float alone), but it serves two important roles as
> well: it can be used as an index key to the UnitConversion table(s) to look
> up the value of the factor, and it can also be used to provide an audit
> trail in numerical computations: typically, if the answer is simply in
> numeric form set to the user's unit, the user may not have any idea of how
> what factors are used in its computation; by delaying the use of numerical
> values for conversion factors, the user can track each conversion in
> symbolic form for numerical inputs to verify correctness and then compute
> when everything is ok (in case there are bugs, for example, this can be
> used for debugging too).
>
> The above setup would make the coercion to OutputForm quite straight
> forward and uniform (which should ignore the factors if they are (1.0,
> "1")).

This is definitely interesting, but I'm not sure we want such an ability to be 
the default - I would suggest hiding the conversion factors unless the user 
specifically specifies otherwise.  I like the idea of the ability to 
explicitly show them though :-).

> The following scenario will illustrate the potential problems and I'll put
> in some suggestions on how to solve some of these.
>
> Assuming the above extended Rep:  unit is initialialised to the standard
> one for the system, factor initialized to (1.0, "1"), absfactor initialized
> to (absfactorvalue, absfactorname).  Let's assume the default unit system
> is FPS (foot-pound-second, a non-scientific system still used in the US),
> see:
>
> http://medical-dictionary.thefreedictionary.com/foot-pound-second+system
>
> When a user runs the command:
>
> (1)   ulen: := setDim("Length", len)
>
> Axiom will return:
>
>       len [ft]
>
> but internally, the Rep is
>
>     [value = len, dim = "Length", unit = "ft", factor = (1.0,"1"),
>      absfactor = (0.3048, "ft2m")]
>
> Here the absfactor says 1 ft is 0.3048 m. The name can be constructed
> dynamically using string concatenation using the UnitConversion table.

In general, I like this (I would prefer to simplify the setDim("Length", len) 
syntax as mentioned in the previous email, but I don't know if anyone else 
agrees with me as to whether my proposal there makes any sense.)

> (By the way, you can find lots of conversion factors on line: for example
>  http://www.onlineconversion.com/
> Just learn a bit more! Let's just stay with English for this discussion.)

Heh :-).   We need some "official" source for the various standards and 
conversions, I think - NIST conveniently supplies the SI definitions, but 
beyond that I'm not sure where free, official online info would be.

> In a STATIC change environment (this is, at compile time), if the user
> prefers "in" GLOBALLY as the unit for length, the command
>
> (2) setUnit("Length", "in")
>
> Here is a design question: we can let setUnit("Length", "in") to modify
> ONLY the unit of the "Length" dimension and not any derived dimension that
> involves "Length". This would be the most flexible so that we can allow
> will change the state-vector to reflect all units that involve a "Length"
> dimension as component

Yes, I agree - don't update the derived dimensions.

> len ft2in [in]
>
> with the internal Rep now:
>
>    [value = len, dim = "Length", unit = "in", factor = (12, "ft2in"),
>     absfactor = (0.0254, "in2m")]
>
> where 0.0254 can be computed from 0.3048 by dividing by 12, some other
> means. The absfactor will faciliate converting FPS to SI, and hence to
> other system as well.

I'm not sure about the need for two factors, except perhaps as a matter of 
efficiency in avoiding common conversion lookups - is that the reason?

> If the user prefers "cm" as the unit for length in an otherwise FPS system,
> the command unitLength can be modified to produce:
>
> (3)   len ft2cm [cm]
>
> with the internal Rep now:
>
>    [value = len, dim = "Length", unit = "cm", factor = (30.48, "ft2cm"),
>     absfactor = (0.01, "cm2m")]
>
> This is all not difficult for STATIC changes, that is, changes that are
> effected at Axiom start time. Now consider DYNAMIC changes: suppose again
> the default is FPS system, and the user has already set the variable ulen
> as in (1).

Hmm.  Need to roll around in my head some more :-/.

> Now if the user later runs:
>
> (4)    setUnitLength("cm")
>
> What does this involve? You are now in a run-time environment, you cannot
> change the code for unitLength in the FPS domain, you can only change data.
> (Code modification is in theory possible if you know enough, but I don't
> think that is a good practice in Axiom).  To handle FUTURE assignments, we
> can design the code for unitLength to depend on a state vector for the
> domain: this state vector stores one unit for each dimension, and is
> updated by the setUnitLength and similar commands. The unitLength (and
> similar commands) can check this state vector before generating the Rep.

Sounds good, in broad.

> But what about those variables already defined, like ulen defined in (1)?
> If ulen is used in some computation requiring ulen to be an input
> parameter, then we can update it. For example, if the user now wants to
> compute the area for a square with side ulen using one of the following
> syntax:
>
>      uarea := ulen * ulen
>      uarea := unitArea(ulen, ulen)
>
> the routine * or unitArea can check the units of its arguments and update
> them before computation. However, if the user simply types
>
>      ulen
>
> the interpreter can only redisplay the output (1). The interpreter has no
> reason to call the FPS(S) domain to perform an update and change the unit
> of ulen and display the output (3). Perhaps the domain FPS(S) should
> provide a function update(ulen).

Does that mean an interpreter update is needed.?

> I made the factor:Union(Float, Symbol) to allow a delay of the computation
> when symbolic computation is more prevalent and also when S does not have
> RetractableTo(Float).  This still requires S to have RetractableTo(Symbol).
>  The exact meaning of factor needs some discussion: perhaps there should be
> two factors! One relative to the current system (to provide a relative
> factor to convert within this system when users changes a unit, and one
> relative to SI (to provide an absolute factor to convert between systems).

I think the latter is a matter of convenience - converting relative to the 
current system is also doable via input unit -> SI -> output unit - if I 
understand you what you are doing is precompressing this two step process 
into one for the default "output" system?

> > I think this is a weak spot in my understanding of dimensionality, so I
> > apologize if I'm being dense here.  If we take C=%pi*d where C is a
> > circumference, %pi is %pi, and d is diameter, and look at the
> > dimensions, we have:
> >
> >           degree
> > Length =  ------ Length
> >           radian
> >
> > Casually, this doesn't look at all balanced.
>
> Of course not. But that is exactly the point: a dimensionless constant
> takes on different dimensions in different conversions or equations. So
> even thought these have the same VALUE pi, the pi in C = pi*d and the pi in
> 180 deg = pi radians are different because their (hidden) dimensions are
> different. In each equation, only their values are the same.

OK - so how to we represent this in a  CAS?  Or more specifically, what about 
the fact that a dimensionless constant has dimension that cancels is useful 
for us to display, and how do we go about it?

> > Does it mean that when we
> > define the dimensionality of the variable C we need to define it as:
> >
> >  degree
> >  ------ Length
> >  radian
> >
> > rather than just Length?
>
> No, dimension of C is length and is not dependent on any equation it is in.
> This is a major difference between physical quantities and mathematical
> constants.

So we are going to have to distinguish between them somehow?  What do we want 
there?

> Perhaps we should start using the term "dimension" to mean the 
> one used in the definition, which may involve derived dimensions, and the
> term "reduced dimension" to mean a simplified form in terms of the basic
> dimensions. Then we can say the reduced dimensions of pi in both equations
> are the same, namely 1 (or dimensionless), but the dimensions are
> different. This terminology would work to say work and moment have the same
> reduced dimensions, but their dimensions are different (when vectors are
> used to indicate the direction of the distance with respect to the forces).
> How vectors may be expressed in dimensions is another thing to study.

YES!  This is an excellent suggestion, and might provide a way to address an 
issue that has been bothering me:

Let's say we work with both work and moment, in two different equations, and 
both calculations would simplify down to length if we cancel out units.  
Presumably those lengths have the same dimension, but they sprang from two 
different equations that would not be the same dimensionally if I were to use 
proper derived dimension simplification rules, despite their both winding up 
with a length falling out.  I think being able to say work and moment have 
the same reduced dimensions would allow us to perform calculations, simply 
noting that the length is a reduced length by virtue of being calculated from 
a quantity involving ambiguous substitution.

Hopefully that was clear enough to express my concerns.  I don't know if they 
would crop up or not in the "real world" - if this is too confusing I can try 
and construct an example (gulp).

> May be, or may be not. It depends on the physical meanings of the
> variables. If I have price at $5/m multiplied by 7 m, I should get $35. If
> I have 8 N divided by 2 m^2 for pressure, and N has dimension kg-m/s^2, is
> it ok to cancel one of the m? So a single rule of Length (m) is not
> applicable to all cases.

This will need to be handled, somehow.  Are there any good references that 
contain the applicable rules for us to implement?

> Actually, you scenarios are not narrow but general and right! There should
> be no difference between units as used by students and units as used by
> researchers. The idea of units is not limited to even SI. Currency
> conversions are conversions in monetary units. But we should be able to use
> Axiom's unit system for grocery as well (Back to my unfinished idea on
> different Dimension domains)! Dimension=Union("Orange", "120z-Coke", ...)
> is as useful as Dimension=Union("Mass", "Length", ...). (Yes, a supermarket
> manager using  Axiom, that'll be the day: not so far-fetched if you think of 
> the operation  research problems involved).

Heh - neat :-).  But it does raise some awkward questions, which came up 
briefly earlier but escaped my notice:

You mentioned $ interacting with meters, and in a previous email kilobits and 
kilobytes were also mentioned.  Unfortunately, neither money nor bits of 
information are covered by any combination of SI units I am aware of.  So 
perhaps our top level category should be not simply Dimensions but 
PhysicalDimensions, and we could perhaps implement some other Categories for 
Dimensions not covered by SI (like money and bits, both of which are Basic 
Units as far as I can tell).  Money might be defined in terms of other things 
in some sense, but that definition is as complex as society itself and ever 
changing.  Fascinating issues, but perhaps those should wait for later.  
Indeed, does it even make sense to include a concept like money in a system 
intending to stick to strict mathematics as much as possible?  I suppose yes 
since we can think of practical uses, but thinking about it is making my head 
hurt ;-).

Again, sorry William if my comments are not well informed/useless.  I think my 
two concrete suggestions worth considering might be to use a hash table of 
all units for mapping operations, and to allow two types of UnitSystem 
definitions - Static, for unchanging (or not normally changing) definitions 
like SI, and a Dynamic environment set up to use your records idea to be 
flexible and responsive to the user.  As a reminder, feel free to ignore me 
since you are clearly much further and better versed in this than I am.

\start
Date: Sat, 03 Sep 2005 02:04:21 -0400
From: Bill Page
To: Kai Kaminski
Subject: Re: Function definition crashes Axiom

Kai,

I tried to build AxiomUI from tla axiom--GUI--1 but I ran into
a problem.

After modifying the first two lines of the Makefile and
Makefile.pamphlet to correspond to the location of where
notangle was built by the Axiom build like this:

TANGLE=/home/wspage/axiom--main--1/mnt/fedora3/bin/lib/notangle -t8
WEAVE=/home/wspage/axiom--main--1/mnt/fedora3/bin/lib/NOWEave -delay

I then did

  make

The result was the following error:

...

;; Wrote file /home/wspage/axiom--GUI--1/src/web-gui/axiom-com.fas
WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL
#x000333BFB5D8>
         on #<CL-SOURCE-FILE "axiom-com" #x000333BF9570>.
;; Compiling file /home/wspage/axiom--GUI--1/src/web-gui/cl-svg.lisp ...
;; Wrote file /home/wspage/axiom--GUI--1/src/web-gui/cl-svg.fas
WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL
#x000333BFB508>
         on #<CL-SOURCE-FILE "cl-svg" #x000333BF9700>.
;;  Loading file /home/wspage/axiom--GUI--1/src/web-gui/axiom-
com.fas ...
;;  Loaded file /home/wspage/axiom--GUI--1/src/web-gui/axiom-com.fas
;;  Loading file /home/wspage/axiom--GUI--1/src/web-gui/cl-svg.fas ...
;;  Loaded file /home/wspage/axiom--GUI--1/src/web-gui/cl-svg.fas
;; Compiling file /home/wspage/axiom--GUI--1/src/web-gui/axiom-
plot.lisp ...
*** - SYSTEM::%FIND-PACKAGE: There is no package with name "AXCOM"
The following restarts are available:
USE-VALUE      :R1      You may input a value to be used instead.
RETRY          :R2      Retry performing #<ASDF:COMPILE-OP NIL
#x000333BFB508> on #<ASDF:CL-SOURCE-FILE "axiom-plot" #x000333BF9840>.
ACCEPT         :R3      Continue, treating #<ASDF:COMPILE-OP NIL
#x000333BFB508> on #<ASDF:CL-SOURCE-FILE "axiom-plot" #x000333BF9840> as
having been successful.
SKIP           :R4      skip this form and proceed
STOP           :R5      stop loading file
ABORT          :R6      ABORT
Break 1 [2]> 5~

--------

Can you let me know if I am doing something wrong or if you
missed something in the build?

\start
Date: Sat, 03 Sep 2005 13:50:38 +0200
From: Kai Kaminski
To: Bill Page
Subject: Re: Function definition crashes Axiom

Bill Page writes:

> After modifying the first two lines of the Makefile and
> Makefile.pamphlet to correspond to the location of where
> notangle was built by the Axiom build like this:
>
> TANGLE=/home/wspage/axiom--main--1/mnt/fedora3/bin/lib/notangle -t8
> WEAVE=/home/wspage/axiom--main--1/mnt/fedora3/bin/lib/NOWEave -delay
>
> I then did
>
>   make
>
> The result was the following error:
[non-existant package AXCOM]

Of course, I shouldn't have hard-coded the paths and I fixed that
now.

The problem with the AXCOM package happened, because when you called
'make', it tried to execute the following rule (the first rule of this
kind):

axiom-com.lisp: axiom-com.lisp.pamphlet
                @${TANGLE} axiom-com.lisp.pamphlet > axiom-com.lisp

This, of course, failed, because ${TANGLE} couldn't be found. But at
that time 'make' (the shell, in fact) had already created
axiom-com.lisp as an empty file. When you called 'make' again with the
paths fixed but without calling 'make clean' first, the package AXCOM
did indeed not exist, but the file axiom-com.lisp did, so it wasn't
rebuild. Hence the solution is to delete axiom-com.lisp (or call 'make
clean') and then call 'make all' again


\start
Date: Sun, 04 Sep 2005 00:19:17 -0400
From: William Sit
To: Tim Daly
Subject: Union

Tim:

If I am given

list:=["Yes","No"]

is there a way to construct Union("Yes","No") from list using some
Lisp or Axiom command?

\start
Date: Sun, 04 Sep 2005 01:22:34 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions (was Unit package question - Part 1)

Dear C.Y.:

Thanks for your comments. I have combined your two responses and rearranged the
order of your comments in the responses below to avoid as much duplication as
possible. However, to present a more or less logically ordered and
self-contained version for others not familiar (or confused) with our earlier
discussions, I have quoted some earlier email paragraphs as well.

---------- General discussion on documentation

C Y wrote:
> 
> --- William Sit wrote:
> > you have already started real work.
> =

> That's probably too generous - I've started trying to become informed
> enough to start real work, really.  Bill is probably going to flinch
> when he sees my idea of basic pre-code (heck, it's really pure
> background) documentation :-).

Tim will love you!
 =

> > It seems that a thorough study of dimensions and units in
> > relation to symbolic computations is not available and your
> > work/paper would be very useful.
> =

> I hope so, although I suspect your ideas are far more useful than my
> own - I'm just asking questions and swatting user level features around
> in my head at this point.  The hard part (and interesting part) is
> expressing them in relation to Axiom's mathematical rigor.

You are welcome to ignore or include in your work/paper any ideas I
presented on this forum.

The hardest part is knowing questions to ask, and second is figuring out the
answers; the easiest (though by no means trivial) is to code the solutions.

> > After waiting a short period of further
> > discussions, a summary of the final design should be posted at
> > MathAction for others to comment on.

> Sounds good.  I apologize in advance for how basic some of my questions
> below will be - I tried to review as much as possible of earlier
> discussions, but I may have regressed some after a rather busy week at
> work.

No need to apologize (though I sometimes do myself). I too have short
 (if any) memory. and tends to repeat myself -- what do you expect
 from an old guy :-)?

---------- Basics of the proposal: Representation of UnitSystem domains

William wrote: =


> >    Rep:=Record(value:S, dim:Dimension, unit:Unit, factor:(Float, String),
> >                absfactor:(Float, String))
> >  
> >My original proposed Rep is simpler because I was not planning for dynamic
> >changes to the unit system, so unit and factor (which would be 1 always) are
> >"hard-wired". The more general record allows more flexibility. This is slightly
> >less efficient in terms of storage, but not that bad, because no matter what,
> >somewhere, the system has to store the conversion factors. The conversion
> >factors can probably be implemented in a UnitConversion domain, which would be a
> >lookup table (maybe tables), which drives the 'setDimUnit' and 'setUnit'
> >commands. Axiom has a number of data structures with extensive tools to create
> >lookup tables (see domains of category TableAggregate in table.spad).

C Y wrote:

> That sounds good, I think - I would propose using this more general, flexible
> representation only in a single instance of a Dynamic UnitSystem - SI and CGS
> wouldn't need it, if I understand correctly.

This comment of yours is based on your breaking up UnitSystem into Static and
Dynamic Unit System. This is certainly possible, but see my comments in the
section on Static vs Dynamic user environment, which will list some pros and
cons on this break up.

> >In the new Rep, besides the unit, two factors are included: One relative to the
> >current system (to provide a relative factor to convert within this system when
> >a user changes a unit), and one relative to SI (to provide an absolute factor to
> >convert between systems: for SI derived unit system, just one factor would
> >suffice; but we should aim for uniformity to simplify the code). 

> I think the latter is a matter of convenience - converting relative to the
> current system is also doable via input unit -> SI -> output unit - if I
> understand you what you are doing is precompressing this two step process
> into one for the default "output" system?
> 

The relative factor can either be built-in for the UnitSystem domain, or via the
SI mechanism. But we have to remember that SI is not universal (supermarket
manager example). So a relative factor setup solves the general situation and is
also more efficient. The SI approach is mainly for scientific applications AND
conversion between two drastically different systems. Believe me, in less than
30 years, symbolic computations will be used by economists, if not already.
(Mathematica has an operations research package, sold separately).

> Generality is good, but I'm afraid I'm not following - for any given Unit,
> wouldn't all you need to know be the description of that unit in terms of SI?
> Or are you proposing that all UnitSystems use this extended storage record?
> I would suggest using it only for the Dynamic UnitSystems, and then you have
> the flexibility to define new units in terms of SI which have no existing
> Static definition.

Yes, I am more in favor of every UnitSystem domain being dynamic (again, see
that section). As to shortening the Rep, yes, in principle, for "scientific"
unit systems, it only needs a conversion factor relative to SI, and yes, for
static unit systems, the relative conversion factors are not needed either.
However, SI is not everything, so the relative factors will be needed in those
cases, and SI may be replaced by another standard unit system.

C Y previously wrote:
> Is that why you're adding the extra
> arguments - to avoid Axiom needing to figure out that nm is a Length
> defined in the SI UnitSystem?  

No, the extra arguments in the new Rep are for convenience of implementation and
efficiency in execution. Axiom still has to verify, on user input via the
setDimUnit commands, that the unit is a legitimate unit for the dimension
specified, even though, as you insist, we allow units outside of the current
unit system. This verification is faciliated by the UnitConversion domain=2E



> > I made the factor:(Float, String) [updated from Union(Float, Symbol)]

    [ added: and absfactor:(Float, String) ]

> > to allow a delay of the computation
> > when symbolic computation is more prevalent and also when S does not have
> > RetractableTo(Float).  

> >Each factor has
> >both a value (Float) and a name (String). The value of the factor is when
> >numerical output is needed, that is, when S is coerced to Float (via the "lift"
> >mechanism). The name would be used in output for symbolic computations to
> >indicate a conversion factor is needed, without spoiling the elegance of
> >symbolic computation or more importantly, going outside the domain S. It is only
> >a decoration in the output (so it can be used with even Float alone), but it
> >serves two important roles as well: it can be used as an index key to the
> >UnitConversion table(s) to look up the value of the factor, and it can also be
> >used to provide an audit trail in numerical computations: typically, if the
> >answer is simply in numeric form set to the user's unit, the user may not have
> >any idea of how what factors are used in its computation; by delaying the use of
> >numerical values for conversion factors, the user can track each conversion in
> >symbolic form for numerical inputs to verify correctness and then compute when
> >everything is ok (in case there are bugs, for example, this can be used for
> >debugging too).
> 
> >The above setup would make the coercion to OutputForm quite straight forward and
> >uniform (which should ignore the factors if they are (1.0, "1")).


C Y wrote:

> This is definitely interesting, but I'm not sure we want such an ability to be
> the default - I would suggest hiding the conversion factors unless the user
> specifically specifies otherwise.  I like the idea of the ability to
> explicitly show them though :-).

What you meant then is to have something like:

    setSymbolicConversion(): Boolean

as default True, which will include symbolic conversion factors. Setting this
False will use numerical values. However, if you meant that when I
setDimUnit("Length", "cm",x) and x was in "m" originally that it will output
only x [cm] instead of x m2cm [cm], then I don't agree.



------------ Basics of the Proposal: UnitSystem domain specifications 

The following addresses only the user interface specifications under discussion
and is not a complete specification for the category:

William Sit wrote:

> > FIRST: Consolidate all the unitXXX and setUnitXXX functions to::
> >
> > UnitSystemCategory(S: SetCategory):Category == Exports where
> >
> >  Dimension ==> Union("Mass", "Length", ...)
> >  Unit ==> Union("kg", "m", ...)
> >  Join(RetractableTo S,...) with
> >
> >      setDimUnit: (Dimension, Unit, S) -> %

[added from earlier mail:

         setDim(Dimension, S) -> %
         setDim(dim,s) == setDimUnit(dim, unit(dim), s)

 where unit: Dimension -> Unit
 looks up the unit in a UnitConversion domain corresponding to the dimension.]

> >      setUnit: (Dimension, Unit) -> Null (?)
> >      setUnitAll: (Dimension, Unit) -> Null (?)
> >
> > where 'setDimUnit(dim, unit, s)' is a LOCAL command affecting ONLY
> > s:S, and 'setUnit(dim, unit)' would be a GLOBAL command affecting
> > ALL s:S (more on this later).  Null may be replaced with a new
> > state vector?



C Y wrote:
 
> I don't quite understand s:S - can you give a specific example of this
> difference?  Also, I'm not following why you would want to make any
> local vs. global distinctions here - wouldn't it be neater just to have
> the set commands work in the CurrentUnitSystem, and base things off of
> Static UnitSystems for definitions unless a totally custom conversion
> is being defined? 

In the setDimUnit, 'setDimUnit' commands, an expression s:S is involved, where S
is a domain that usually contains symbols ("RetractableTo Symbol" in Axiom
jargon) and s:S means s is such an expression. Of course S can be just Float if
no symbols are involved, in which case, expressions and variables are simply
constants.  But the user assigns a dimension and unit to an expression, which
will change the way certain variables involved in the expression are inputted or
outputted. This setting is for a specific expressions s, so has "local" scope.
The other 'setUnit' is local for a specific dimension, but has a wider scope and
affects all expressions of that dimension. Finally, the 'setUnitAll' is global
in the sense that all derived dimensions involving that specific dimension and
all expressions in all those derived dimensions will be affected. The
implementation will be assisted by the UnitConversion domain and the Rep
remembers the conversion factors both relative to the current system and to the
SI system, when possible.

> > To support the implementation for 'setUnit' (a dynamical
> > change of units), I propose to add a state vector for each unit
> > system domain: this state vector stores the current unit for each
> > dimension, which is updated by the 'setUnit' command 
    [added: and 'setUnitAll' command]. 
> > The'setDimUnit' command can check this state vector before generating
> > the Rep (see below). Some care has to be considered: we have to
> > decide whether a 'setUnit(dim, unit)' command should affect the
> > other derived units that depends on 'dim' or not, and also those
> > the variables whose dimensions were set before this 'setUnit'
> > command and invole 'dim'. I have added 'setUnitAll' for the case
> > every current variable will be updated.
> 
> I don't think I'm quite following - Derived Units are defined in terms
> of the Base Units for their UnitSystem - just because we are now using
> "cm" instead of "m" as our default length doesn't change the definition
> of N, or how many Newtons we have.  If we want to report a Derived Unit
> in terms of Base Units, then we would want to use cm instead of m, but
> otherwise I'm afraid I'm missing something.

My proposal allows (but the decision is still open) changing the units for a
single expression s:S -- 'setDimUnit(dim,u,s)'. It also allows changing the unit
of a single dimension, say Length, in the current (loaded) unit system without
affecting other derived dimensions that involve Length -- 'setUnit(dim,u)'.
Finally it allows changing the unit of a single dimension, say Length, and any
other derived dimension that involves Length, such as Velocity --
'setUnitAll(dim, u)'. In your example above, changing the unit of Length from
"m" to "cm" will report the unit of Force (the dimension of "N") either still as
"N", if 'setUnit(Length,"cm")' is used in SI; or as kg-cm/s^2 (by changing the
value of any expression with dimension Force by a conversion factor m2cm), if
'setUnitAll(Length,"cm")' is used in SI; in which case, the new unit of "Force"
is "kg-cm/s^2" or "kilodyne", following SI prefix convention (basically changing
SI, which is MKS based, to CGS).

---------- Scenario Example

William Sit wrote:

> > The following scenario will illustrate the potential problems and I'll put
> > in some suggestions on how to solve some of these.
> >
> > Assuming the above extended Rep:  unit is initialialised to the standard
> > one for the system, factor initialized to (1.0, "1"), absfactor initialized
> > to (absfactorvalue, absfactorname).  Let's assume the default unit system
> > is FPS (foot-pound-second, a non-scientific system still used in the US),
> > see:
> >
> > http://medical-dictionary.thefreedictionary.com/foot-pound-second+system
> >
> > When a user runs the command:
> >
> > (1)   ulen: := setDim("Length", len)
> >
> > Axiom will return:
> >
> >       len [ft]
> >
> > but internally, the Rep is
> >
> >     [value = len, dim = "Length", unit = "ft", factor = (1.0,"1"),
> >      absfactor = (0.3048, "ft2m")]
> >
> > Here the absfactor says 1 ft is 0.3048 m. The name can be constructed
> > dynamically using string concatenation using the UnitConversion table=2E
> 
> In general, I like this (I would prefer to simplify the 'setDim("Length", len)'
> syntax as mentioned in the previous email, but I don't know if anyone else
> agrees with me as to whether my proposal there makes any sense.)

I assume you are referring to the 'setUnit(nm,N,inches)' suggestion. See section
on Updating variables and their units.

[Following quotes edited for more consistent reading]

> > In a STATIC change environment (this is, at compile time), if the user
> > prefers "in" GLOBALLY as the unit for length, the command
> >
> > (2) setUnit("Length", "in")
> >
> > will output: 

> >     len ft2in [in]
> >
> > with the internal Rep now:
> >
> >    [value = len, dim = "Length", unit = "in", factor = (12, "ft2in"),
> >     absfactor = (0.0254, "in2m")]
> >
> > where 0.0254 can be computed from 0.3048 by dividing by 12, some other
> > means. The absfactor will faciliate converting FPS to SI, and hence to
> > other system as well.

> > Here is a design question: we can let 'setUnit("Length", "in")' to modify
> > ONLY the unit of the "Length" dimension and not any derived dimension that
> > involves "Length". This would be the most flexible.
> 
> Yes, I agree - don't update the derived dimensions.
> 
> I'm not sure about the need for two factors, except perhaps as a matter of
> efficiency in avoiding common conversion lookups - is that the reason?

Yes, see also section below. Each expression requires one lookup at the time its
dimension and unit is set. All subsequent uses and display will avoid the lookup
again even if, in case of a variable, it is reassigned to a different value. All
necessary conversion is taken care of by the arithmetic operation in the
UnitSystem domain.

> > If the user prefers "cm" as the unit for length in an otherwise FPS system,
> > the command unitLength can be modified to produce:
> >
> > (3)   len ft2cm [cm]
> >
> > with the internal Rep now:
> >
> >    [value = len, dim = "Length", unit = "cm", factor = (30.48, "ft2cm"),
> >     absfactor = (0.01, "cm2m")]
> >
> > This is all not difficult for STATIC changes, that is, changes that are
> > effected at Axiom start time. Now consider DYNAMIC changes: suppose again
> > the default is FPS system, and the user has already set the variable ulen
> > as in (1).
> 
> Hmm.  Need to roll around in my head some more :-/.
> 
> > Now if the user later runs:
> >
> > (4)    setUnit("Length","cm")  [function name updated from unitLength]]
> >
> > What does this involve? You are now in a run-time environment, you cannot
> > change the code for 'setUnit' in the FPS domain, you can only change data.
> > (Code modification is in theory possible if you know enough, but I don't
> > think that is a good practice in Axiom).  To handle FUTURE assignments, we
> > can design the code for 'setUnit' to depend on a state vector for the
> > domain: this state vector stores one unit for each dimension, and is
> > updated by the 'setUnit' and 'setUnitAll' commands. The 'setUnit' (and
> > similar 'set' commands) can check this state vector before generating the Rep.
> 
> Sounds good, in broad.
> 
> > But what about those variables already defined, like ulen defined in (1)?
> > If ulen is used in some computation requiring ulen to be an input
> > parameter, then we can update it. For example, if the user now wants to
> > compute the area for a square with side ulen using one of the following
> > syntax:
> >
> >      uarea := ulen * ulen
> >      uarea := setDimUnit("Area", ulen, ulen) [function name updated from unitArea]
> >
> > the routine * or 'setDimUnit' can check the units of its arguments and update
> > them before computation. However, if the user simply types
> >
> >      ulen
> >
> > the interpreter can only redisplay the output (1). The interpreter has no
> > reason to call the FPS(S) domain to perform an update and change the unit
> > of ulen and display the output (3). Perhaps the domain FPS(S) should
> > provide a function 'update(ulen)'.
> 
> Does that mean an interpreter update is needed.?
>
I hope not! The 'update()' function can handle that. We should not modify the
Interpreter for this project unless it is absolutely necessary, which so far, I
don't see. It is possible for the 'setDimUnit' function in the UnitSystem domain
to record all calls to the 'setDimUnit' command to create and maintain a live
list of variables or expressions, say as part of the state vector. An update can
either be applied for just one variable in the domain, or all variables in this
live list.


---------- Implementation issues: Updating variables and their units

Some updating questions are raised and solutions suggested in the Scenario
Example section above.

> As for current variables, shouldn't they be updated automatically by
> the global update?

That is the idea. That is, a 'setUnitAll(dim, u)' command will change all output
and input variables/expressions that are of dimension dim to use unit u. In the
scenario Example section, we discussed the issues and some possible actions. The
basic design question to decide is: should this global command affect only newer
variables/expressions or should this retroactively set all existing
variables/expressions? The basic implementation question is: what data
structures will support these functionalities efficiently (bear in mind some
trade offs between memory and CPU time, as usual)? It seems the proposed
state-vector can support the implementation, whatever the decisions.

> I would have thought all you needed was a single command SetUnits()
> command, which would take a minimum of one argument and a max of one
> unit per available dimension, e.g.
> 
> SetUnits(nm,N,inches); 

[NB, Axiom convention:function names should start with lower case]

I do not quite follow. Your example has three arguments, all units of Length. I
think you are thinking of 'setUnitAll(dim, u)'? Maybe a simpler 'setAll(u)' and
let the system figure out the dimension of u? (But as explained below, this
reverse lookup from unit to dimension is not unique; in that case, we can make
'setAll(u)' return an error message with some choices (probably not all possible
choices). So you would still need the version 'setUnitAll(dim,u)' after the user
picks one of those choices.

Your line:

  SetUnits(nm,N,inches);

is, as far as I can follow, a global set. Surely, in this simple example, Axiom
can figure out that these (nm, N, inches) (aside: use "in" for "inches" -- SI
recommendations) are units for Length, but as explained, this is not possible in
general. My version 'setUnitAll(dim, u)" only does this for a particular
dimension dim and a particular unit u. I don't know why you set the Length
dimension to THREE different units. Are you imagining mixing units for the same
dimension in one session? How are you going to tell which variable/expression
will use any one of these three units? Are you saying that ALL three units
should be reported for ANY variable/expressions of dimension Length? (Note: even
if you are mixing units, the Rep will support it. I just want to know what your
line meant.)

> In the CurrentUnitSystem Dynamic UnitSystem (assuming things are in
> default mode) the "state vectors" for the dimensions corresponding to
> the units entered would be updated.  It's not clear to me why you would
> need any other arguments, unless you wanted to make sure the user knows
> the dimension of the unit they are inputing as a default.  

> Maybe I place too much emphasis on user
> convenience but I as a user would prefer not to tell Axiom things it
> already knows.

Fair enough. We can ALWAYS add defaults. The example I gave in my last message
(added above in Section on UnitSystem specification):

   setDim(dim: Dimension, s:S):% == setDimUnit: (dim, unit(dim), s)

performs a lookup for the default unit for a given dimension in the current
UnitSystem. The 'setAll(u)' above can handle cases where an automatic lookup
results in a unique dimension to set the dimension field in Rep. However we do
not want to look up repeatedly each time we use a variable, so the results are
memorized in Rep. 

And, yes, users should know the dimension of the unit they are inputting. One
danger with something like 'setAll(u)',  which left out the dimension for u, is
that a simple typo say from 'setAll(cm^2)' to 'setAll(cm^3)' would not be caught
and play havoc in subsequent computations. Forcing the user to give the intended
dimension provides a better chance that these errors will be caught.

> Maybe as a time saving alternative SetUnits could also
> accept things of the form <UnitSystem>::Unit or some such, which would
> limit the search space it would need to check?  

I don't follow the syntax of <UnitSystem>::Unit. Is :: coercion in Axiom? I have
not heard of coercing a domain into a category. Perhaps you are thinking of a
package call to a domain in UnitSystems? That would be setAll(u)$domain. But I
do not like this default setAll(u) for reasons above.

> Or even better, if
> Axiom is up to it we might also be able to build a toplevel hash table
> of all defined units in all unit systems at compile time which can
> quickly match up a unit up with a UnitSystem and Dimension.

The UnitConversion domain (perhaps category) is for this purpose. I am still
thinking about whether UnitConversion should be a category with many domains or
just one domain. The many-domain approach may provide better efficiency for more
localized conversion systems and flexibility future additions.

As we don't know all the expert areas now in existence, nor do we know what new
derived dimension or unit we may need (especially in 30 years' time), there is
no way we can have such a universal toplevel hash table. We CAN implement SI
(all the default and acceptable dimensions and units) or even more, but such a
domain will need to be revised to allow newer dimensions and units. The design
proposed will allow this of course (any design in fact), but I still subscribe
to the older Axiom philosophy that we do not modify existing libraries except
for bugs, and extend existing libraries through additional implementation=2E We
should allow arbitrary UnitSystems (as I also indicated in my last email,
supermarket manager will need a totally different, "non-scientific" unit system
with dimensions like "Coke", "DietCoke", etc.)


---------- Implementation Issues: Setting up Dimension and Unit domains

William Sit wrote:

> >[Comments: I have not decided whether there should be more than one category,
> >and also what to call them. Also there is a difficulty with dimensions(),
> >units() because they do not return a domain, to be used in the signatures. So
> >you may safely ignored the next paragraph for now. However, what I had in mind
> >was to allow many domains like Dimension = Union("Mass", etc) and corresponding
> >Unit = Union("slug", etc) for people (students ?) who don't need the full set,
> >as well as the ability to add new supersets later. Unfortunately, we cannot
> >have:
> > 
> >  Dimension(dims:List String) == Union(dims)
> > 
> >]
> > 
> >FIRST (alternative): On the category level:
> > 
> >There will be
> > 
> >(I) a UnitConversion category, whose details I have not investigated, but its
> >domains will contain tables for all dimensions for a particular expert field,
> >units, and conversion factors from SI. There will probably be one comprehensive
> >such domain to start the ball rolling, but we will surely miss some dimensions
> >and units in some not-so-common expert areas or new areas. The category will
> >provide guidelines to add these new areas.
> > 
> >UnitSystem(S, D, U):Category == Exports where
> >   S: SetCategory
> >   D: List String
> >   U: List String
> > 
> >   dimensions: ()->List String
> >   units: ()->List String
> >   convertFactor: String -> Float
> >
> > For example, dimensions() = ["Mass", "Length", ...] (which replaces Dimension > >Union("Mass", "Length", ...), making this local to a unit system rather than one
> >global list.
> >
> >(II) ??? Dimension(dims:List String) == Union(dims)
> 

C Y wrote:

> Dimensions
> may not always map uniquely to Units, but Units DO map uniquely to
> dimensions. 

Your last remark is wrong, unless there are already standard terminology such as
in the case of Work vs Moment: standard energy-units exist as Joule, erg, eV,
etc. and moment-units exist as N-m, etc. In other cases, you may have to create
new standard names first. However, the problem still is: given some unit in
reduced basic dimensions such as (mass-length/time^2).length, say kg.m^2/s^2, we
do not know if the dimension should be Energy (either Work or Kinetic Energy or
Potential Energy) or Moment. Vectorizing some of these dimensions may help: Work
is a force vector times a length vector, and so is moment, but the two length
vectors have different directions with respect to the direction of the forces.

> Couldn't Axiom figure this out?  All it has to do is
> determine the dimension of each argument, check that all dimensions are
> unique, and set the defaults (the setunits command in Maxima works this
> way.)  We ARE back to some parser being able to check all units for a
> match to the input unit, I guess. 


What you are describing is the "forward" direction, which is easy. The problem
to map units back to dimension is the "backward" direction, which has no clean
solution (yet?). You will need a parser if the Dimensions and Units are
represented by variables taking up namespace (as in Mathematica, and I assume,
in your Maxima implementation). My proposal avoids this modification to the
Axiom Interpreter. (see also Namespace issues below).



--------- User environment for Unit systems: Static vs Dynamic

[Quotes edited to bring function names up to date]

William Sit wrote:

> > Axiom allows a user to set his preferences in a file
> > called axiom.input (which is in the directory $AXIOM/input).
> > So by putting ")set UnitSystem MYUnitSystem" in that file, Axiom
> > will use MYUNitSystem as the default unit system when the
> > functions 'setDimUnit' etc. are called.  MYUnitSystem can be SI, CGS,
> > or some modified version of the standard SI (but once modified,
> > it should be called something else).

C Y wrote:
 
> This isn't quite what I was thinking - I was thinking by default Axiom
> could use a unit system called CurrentUnitSystem, which would be
> somewhat different in definition from SI, CGS, etc.  Doing
> 
> )set UnitSystem SI
> 
> would drop the user in a strict SI output only environment without the
> possibility of local override, which I have no problem with.  (Might
> even be a good idea to have available, really - call it a STATIC
> UnitSystem definition.) 

All Axiom variables are typed. So once a user started computating using a
UnitSystem domain, say A, all his computations will be in that unit system. If
he then change to SI, he would have to coerce them to SI, which may or may not
be possible, depending on what dimensions and units are in A. (So, the domain A,
and the UnitSystems category, may have to include functions like convertIfCan: %
-> SI).

> What i would like CurrentUnitSystem to do is
> be a DYNAMIC UnitSystem, using either the system you have outlined
> below or something similar.  It would start out as an instance of the
> SI definitions by default, but allow local overrides dynamically (hence
> a Dynamic UnitSystem definition).  Also useful would be a
> SaveUnitSystem(<NewUnitSystemName>) for later use - essentially
> allowing a user to load a precustomized Dynamic UnitSystem Definition
> as the working UnitSystem.  With a Dynamic UnitSystem Definition we
> could have a MapUnitSystem(<UnitSystem name>) command to allow the user
> to restore all STATIC SI definitions (say) to the CurrentUnitSystem.
> Is that following what you had in mind?

I think you want somehow to restrict some users (say students who are learning
about units and dimensions) not to allow them to "mess" with a UnitSystem domain
like SI. I don't see the necessity because most likely, such users will only
want to do their computations in whatever unit system is the default. Even if
they were to use 'setDimUnit', 'setUnit', and 'setUnitAll' (which would be a
good experience), these only affect the interpreter session and will not modify
the SI domain at all. The state-vector does not survive an axiom reload since no
modification to the compiled code is performed. Also a user can save the history
of all inputs, including all 'set' commands (and also ')set' commands) and put
them in axiom.input or a 'myunitmod.input' and read it in anytime. There is no
need, in this dynamic design, to modify ANY compiled domain in the UnitSystem
category. When a user wants to have modification compiled into a modSI domain,
he will have to edit the SI.spad.pamphlet and change it into modSI.spad.pamphlet
and compile it. However, I don't see the necessity. Your idea of
'SaveUnitSystem(<newUnitSystemName>) is difficult (but not impossible) to
implement and involves automatically editing say SI.spad.pamphlet to
modSI.spad.pamphlet and automatically compiling it. It is trivial for a user to
read in an input file instead.

I note that each of our positions on this user environment issue has turned 180
degrees from earlier communications :-).

The ')set unitsystem <UnitSystem name>' will only need to preload <UnitSystem
name>. Tim already said that this can be added. Once loaded, it becomes what you
called CurrentUnitSystem (but without the name). The <UnitSystem name> can be
either static or dynamic, depending on whether the three 'set' commands are
implemented or not in that domain. The SI system can be restored by simply
issuing another ')set unitsystem SI' command. In fact, another way to load any
unitsystem is simply to say ')library <UnitSystem name>', just like loading any
other library, so we don't even need to add the ')set unitsystem' command,
although the ')set unitsystem' command perhaps can avoid some package calls when
the 'set' commands are used.

A "dynamic" unit system domain becomes static if the user does not use any of
the 'set' commands from the domain or if they are not implemented in the domain.

> Working in a Static UnitSystem no set commands are
> either possible or necessary (and thus shouldn't work) and in a Dynamic
> UnitSystem (of which there will normally be only one - the working one)
> the Static UnitSystems provide the information to use in the Dynamic
> one?

Right, see previous comments. A StaticUnitSystem domain in your sense is nothing
but a table for pairing dimensions and units. So this is included in
UnitConversion domain (basically a database). It would be just a difference in
names. 



> Since
> Static UnitSystems wouldn't be changable in a normal session anyway (at
> least without editing the source and reloading, which hopefully would
> also mandate a rebuild of the hash tree) it would be a one time expense
> and would enable considerable user convenience at many levels.  

Of course, whatever has been compiled is static, but since we are to provide
(again, as you insist -- a good thing) dynamic changes to a loaded unit system,
there is really no need to "automatically" modify library code to change a
static unit system. I remember you were oppose to this when I was defending the
old proposal that you can compile as many UnitSystem domains as you like,
modifying standard ones as little or as much as you like. Since this automation
to modify library code to generate a new compilable spad source is difficult
(remind you that this should be a documented pamphlet file, requiring expertise
in using automatic editors), and may contribute to a proliferation of domains
only for personal use, I have moved to the dynamic model to satisfy user needs.
A user can easily set up the axiom.input file to load a bunch of interpreter
code, which includes setDimUnit, setUnit, setUnitAll lines before proceeding.
The user is in total control and no system level work (like automatic editing
spad files) is required.

Requiring rebuilding the hash tree is not a good idea because a domain is
supposedly stable once built. Plus, if someone adds a new UnitSystem domain, who
would be responsible to rebuild the single hash tree? If the new domain
introduces new dimensions and units, it should create a corresponding
UnitConversion domain (hash tree) and leave the standard hash table alone=2E



--------------- Name space issues

> (I'm still
> plotting to allow the user to gobble up all the unit names in the
> default namespace at their option, and that will DEFINITELY need
> interpreter work.

As you know, I am strongly against "gobbling up all the unit names in the
default namespace' even if it is 'at their option'.  If you are seriously
thinking about student use, you know the average students will exercise their
options without knowing or understanding what they are doing. There is no way to
consistently reserve SOME unit names in namespace, and not others. Any code to
implement this will have to know the reserved names a priori and that means ALL
the abbreviations in SI units at a minimum. You would have created a nightmare
in using the interpreter by requiring users to avoid any SI unit abbreviations
as user variables. No computer language ever has that many reserved words=2E Note:
Axiom function names are NOT reserved, but constructor (which may be category,
domain or package) names and their abbreviations are.

Modifying the interpreter because of a specific category or its domains is a bad
idea. Any modifications should be general purpose or fixing bugs.
 
> > As for tools to do the dynamic modification from standard unit
> > systems like SI, here are several changes to the previous setup
> > that will facilitate this and improve the organization of the
> > domains as well.
> 
> Did you intend to use this setup for ALL UnitSystems or just what I've
> termed Dynamic UnitSystems?  (Sorry if I should have caught this.)

Yes. I believe this would make it easy for UnitSystem domains to inherit the
default implementations by a few simple modifications. (In the end, only the
actual coding will tell if this is possible).  I do not distinguish between
static and dynamic. Every unitsystem domain is dynamic. But if you like, you can
have them separately specified. Then a StaticUnitSystem category would not have
the three 'set' functions exported and a DynamicUnitSystem category is a
StaticUnitSystem with the three 'set' functions (and perhaps others). The
problem with this dual approach is that if after computing with a
StaticUnitSystem domain, a user suddenly decides to change the unit of one of
the dimensions, he would have to either redo the computations, or to coerce
everything from the static domain to a CORRESPONDING dynamic domain. There is no
enforcable mechanism to guarantee that every static domain has a corresponding
dynamic domain, and if this latter guarantee holds, then we are duplicating all
unit systems for something not that useful. Most users will want to have more
flexibility. I think even for student use, if they want to experiment with
changing units (at run time), why should that be forbidden? (for that matter,
Axiom being open sourced, why should ANYTHING be forbidden?)

> In the
> SetUnits usage it doesn't even need to use up toplevel namespace, and
> if a user DID want to populate the toplevel namespace it would be a big
> speedup for the interperter to be able to hash a symbol to check if it
> is a unit.

My proposal uses up NO user namespace for the dimensions or units. It uses only
strings as fake domain names. Strings are data items, not a name. The more
familiar one is the "failed" (a "domain"!) in Union(..., "failed"). This is the
built-in magic implementation of Union. A lookup requires only the case statment
and presumably implemented efficiently already.

There is perhaps one way to use variables (instead of strings) for dimensions
and units, but they will be local to the domain (using domain namespace, rather
than user namespace) and they will not be assigned any value. The advantage over
strings is that they can be used to perform arithmetic operations of
multiplication and division as symbols. Then general conversion factors can be
computed by setting up a small number of conversion rules and by solving an
equation. 

Default relationship (tables) for conversion tables (which include both
dimensions and units) and the dependencies like state-vectors, can use hash
tables.

---------- Implementation Issue: Simplification of dimensions

C Y wrote:

> > > I think this is a weak spot in my understanding of dimensionality, so I
> > > apologize if I'm being dense here.  If we take C=%pi*d where C is a
> > > circumference, %pi is %pi, and d is diameter, and look at the
> > > dimensions, we have:
> > >
> > >           degree
> > > Length =  ------ Length
> > >           radian
> > >
> > > Casually, this doesn't look at all balanced.

William Sit wrote:

> > Of course not. But that is exactly the point: a dimensionless constant
> > takes on different dimensions in different conversions or equations. So
> > even thought these have the same VALUE pi, the pi in C = pi*d and the pi in
> > 180 deg = pi radians are different because their (hidden) dimensions are
> > different. In each equation, only their values are the same.

C Y recently wrote:

> OK - so how to we represent this in a  CAS?  Or more specifically, what about
> the fact that a dimensionless constant has dimension that cancels is useful
> for us to display, and how do we go about it?

We can do this:

  piInEqn1:= setDimUnit("Length/Length", "m/m", %pi)

or 

  piInEqn1:= setDimUnit("1", "1", %pi)

but 

  piInEqn2:= setDimUnit("Degree/Radian", "deg/rad", %pi)

Perhaps we can add a field to Rep that gives the reduced dimension as well? or
provide a function

  reduce: Dimension->Dimension

(which in any case, will be useful and necessary).
 
> > > Does it mean that when we
> > > define the dimensionality of the variable C we need to define it as:
> > >
> > >  degree
> > >  ------ Length
> > >  radian
> > >
> > > rather than just Length?
> >
> > No, dimension of C is length and is not dependent on any equation it is in.
> > This is a major difference between physical quantities and mathematical
> > constants.
> 
> So we are going to have to distinguish between them somehow?  What do we want
> there?

See comments to previous question. The function reduce("Length/Length") will
return "1" so that the variable C in C:= piInEqn1 * d will give C the dimension
of "Length".
 
> > Perhaps we should start using the term "dimension" to mean the
> > one used in the definition, which may involve derived dimensions, and the
> > term "reduced dimension" to mean a simplified form in terms of the basic
> > dimensions. Then we can say the reduced dimensions of pi in both equations
> > are the same, namely 1 (or dimensionless), but the dimensions are
> > different. This terminology would work to say work and moment have the same
> > reduced dimensions, but their dimensions are different (when vectors are
> > used to indicate the direction of the distance with respect to the forces).
> > How vectors may be expressed in dimensions is another thing to study.
> 
> YES!  This is an excellent suggestion, and might provide a way to address an
> issue that has been bothering me:
> 
> Let's say we work with both work and moment, in two different equations, and
> both calculations would simplify down to length if we cancel out units.
> Presumably those lengths have the same dimension, but they sprang from two
> different equations that would not be the same dimensionally if I were to use
> proper derived dimension simplification rules, despite their both winding up
> with a length falling out.  I think being able to say work and moment have
> the same reduced dimensions would allow us to perform calculations, simply
> noting that the length is a reduced length by virtue of being calculated from
> a quantity involving ambiguous substitution.
> 
> Hopefully that was clear enough to express my concerns.  I don't know if they
> would crop up or not in the "real world" - if this is too confusing I can try
> and construct an example (gulp).

Yes, unless given other examples, I think this is a way to get out of the
dilemma. Of course, the strong typing of Axiom already drove developers nuts,
and I'm afraid, surely, the strict setup to dimensions and units may likely do
so to scientists or economists. This is the price to pay for insisting on formal
correctness.

> > >Could unit and dimension cancelation be handled
> > >on a per dimension basis?

> > May be, or may be not. It depends on the physical meanings of the
> > variables. If I have price at $5/m multiplied by 7 m, I should get $35. If
> > I have 8 N divided by 2 m^2 for pressure, and N has dimension kg-m/s^2, is
> > it ok to cancel one of the m? So a single rule of Length (m) is not
> > applicable to all cases.
> 
> This will need to be handled, somehow.  Are there any good references that
> contain the applicable rules for us to implement?

I don't know, and I have not tried hard enough to google. This must be quite
thoroughly studied already. There is a 1941 paper on "theory of dimensions" in
Proc. Phys. Soc. by G. Brown, Vol 53, p. 418. 
http://www.iop.org/EJ/abstract/0959-5309/53/4/307

Don't know if it is useful. It reduces all dimensions to Length and Time, which
are related, said the author, via the speed of light. Does any one know more
about this article?

There is also a theory of dimensions for economic quantities, published in 1871!
(III.43):

http://www.econlib.org/library/YPDBooks/Jevons/jvnPE3.html

and historically, it seems Fourier introduced the theory of dimensions in 1822
(Th=E9orie de Chaleur, Article 160). The article below is worth reading:

http://www.memagazine.org/contents/current/webonly/wex80905.html

Fourier's notion of homogeneity should strike a resonance.

Whether any such references will help us develop the rules to simplify
dimensions, I don't know. From what we have discussed, it seems any rule will
need some expert knowledge (in the example I gave, the expert knowledge is
simply what pressure is). So I believe the best solution may be to "leave it to
the users", and let them create their own names and simplification rules. This
means that in a UnitSystem domain, there ought to be facilities to handle rules
of simplifications, where some common defaults can be implemented. Axiom has a
RewriteRule domain that can help. RewriteRule can also be used efficiently to
perform conversion. (I once wrote a UnitConversion.nb in Mathematica for a
course using this idea: all conversion factors between the two units for the
same dimension is then a simple Solve[unit1 = x unit2, x])


> > Actually, you scenarios are not narrow but general and right! There should
> > be no difference between units as used by students and units as used by
> > researchers. The idea of units is not limited to even SI. Currency
> > conversions are conversions in monetary units. But we should be able to use
> > Axiom's unit system for grocery as well (Back to my unfinished idea on
> > different Dimension domains)! Dimension=Union("Orange", "120z-Coke", ...)
> > is as useful as Dimension=Union("Mass", "Length", ...). (Yes, a supermarket
> > manager using  Axiom, that'll be the day: not so far-fetched if you think of
> > the operation  research problems involved).
> 
> Heh - neat :-).  But it does raise some awkward questions, which came up
> briefly earlier but escaped my notice:
> 
> You mentioned $ interacting with meters, and in a previous email kilobits and
> kilobytes were also mentioned.  Unfortunately, neither money nor bits of
> information are covered by any combination of SI units I am aware of.  So
> perhaps our top level category should be not simply Dimensions but
> PhysicalDimensions, and we could perhaps implement some other Categories for
> Dimensions not covered by SI (like money and bits, both of which are Basic
> Units as far as I can tell).  Money might be defined in terms of other things
> in some sense, but that definition is as complex as society itself and ever
> changing.  Fascinating issues, but perhaps those should wait for later.
> Indeed, does it even make sense to include a concept like money in a system
> intending to stick to strict mathematics as much as possible?  I suppose yes
> since we can think of practical uses, but thinking about it is making my head
> hurt ;-).
> 

"Now, you're thinking!" :-)

In my case, thinking about these things make me stare at the screen and then
fall asleep! But you got a point here, building unit systems should include, or
at least allow future inclusion, of systems outside of the usual scientific
sphere. So having an WallStreetDimensions, SupermarketDimensions,
FontsMetricDimensions systems would be fun but we don't have to implement them
right away.

\start
Date: Sun, 04 Sep 2005 01:44:12 -0400
From: Bill Page
To: Kai Kaminski
Subject: successfully built axiomUI on Fedora 3 x86-64

Kai,

Thanks for your lastest tla axiom-GUI--1--patch-2. Below I have
included an additional patch to use the $AXIOM variable instead
of hardcoding paths or depending on implicit paths. This is
consistent with the approach used in the current Axiom build.

I am obviously writing this email in a little more detail than you
require :) but I am also cc'ing to axiom-developer list in case
these notes help anyone elso try this.

With your tla patch-2 and this patch I successfully built axiomUI
web-gui on my Fedora Core 3 x86-64 system.

I also upgraded my Firefox browser to DeerPark Alpha 2 from here:

http://www.mozilla.org/projects/firefox

using the link 'Deer Park Alpha 2 for Linux (English)' which
downloads 'deerpark-alpha2.installer.tar.gz'. I untarred and
ran the installer and now I start it with the command:

  /usr/local/firefox/firefox&

This is what I noticed so far:

1) All intermediate and binary files are created in the
   'src/web-gui' directory. As a minimum, to be (more or less)
   compatible with the Axiom build intermediate files should
   go into directory 'int/web-gui' and the binaries/executables
   should go into 'mnt/bin'

2) run-axiom-ui.sh does not have executable flag. It needs

   chmod a+x run-axiom-ui.sh

3) Running

   ./run-axiom-ui.sh

   produces no initial startup message. Something re-assuring
   and informative like:

   "Waiting for browser http:/127.0.0.1:5050"

   would be nice :)

4) 'make doc' does not run because the current Axiom build does
   not put noweb.sty into the /usr/share/texmf tree. Instead the
   path is hard coded. You could use this convention, in which
   case the file should be named '${AXIOM}/bin/tex/noweb.sty'
   but perhaps better, the Axiom build should put a copy of
   noweb.sty someplace standard like this:

   mkdir /usr/share/texmf/tex/latex/noweb
   cp $AXIOM/bin/tex/noweb.sty /usr/share/texmf/tex/latex/noweb
   /usr/bin/texhash

5) How can I exit cleanly from the run-axiom-ui.sh process?
   Perhaps it should catch the ^C and kill signals and do
   something nice.

6) On linux at least maybe we should setup an inetd service to
   start run-axiom-ui.sh automatically on port 5050 so that this
   is transparent to the user? Can you think of any other way
   that we can make it unnecessary for the user to start two
   processes? Should run-axiom-ui start the browser session for
   the user?

7) Of course since this is 'alpha' version there are many easy
   to find problems with output. The graphics output seems
   especially fragile. The examples you give work fine but if
   one deviates slightly it is possible to produce a mess.
   E.g.

     draw(1/sin(x),x=0..2*%pi)

Perhaps I should set up some AxiomUI categories on IssueTracker to
help keep track of these problems?

Now that SOC is over, what is the best way for us to ensure that
the project development continues? Will you be able to continue to
be involved? If so, would to be willing to continue to take the
lead?

Regards,
Bill Page.

--------
Patch to use $AXIOM variable to locate notangle and noweave.

[wspage@localhost axiom--GUI--1]$ tla changes --diffs
* looking for arch@axiom-developer.org--axiom/axiom--GUI--1--patch-2 to
compare with
* comparing to arch@axiom-developer.org--axiom/axiom--GUI--1--patch-2
M  src/web-gui/Makefile
M  src/web-gui/Makefile.pamphlet

* modified files

--- orig/src/web-gui/Makefile
+++ mod/src/web-gui/Makefile
@@ -1,5 +1,5 @@
-TANGLE=/usr/bin/notangle -t8
-WEAVE=/usr/bin/noweave -delay
+TANGLE=${AXIOM}/bin/lib/notangle -t8
+WEAVE=${AXIOM}/bin/lib/noweave -delay
 LISP=clisp




--- orig/src/web-gui/Makefile.pamphlet
+++ mod/src/web-gui/Makefile.pamphlet
@@ -10,8 +10,8 @@
 \section{Makefile}

 <<*>>-TANGLE=notangle -t8
-WEAVE=noweave -delay
+TANGLE=${AXIOM}/bin/lib/notangle -t8
+WEAVE=${AXIOM}/bin/lib/noweave -delay
 LISP=clisp


@@ -209,4 +209,4 @@
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 @
-\end{document}
\ No newline at end of file
+\end{document}

\start
Date: Sun, 04 Sep 2005 06:50:47 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [#202 Axiom Tutorial PDF on Windows - Bitmap fonts used] (new) 

The Axiom Tutorial uses bitmap fonts, as LaTeX does by default when
exporting to PDF.

This means the PDF looks horrible on screen, and is probably larger
than it needs to be.

\start
Date: Sun, 4 Sep 2005 09:42:26 -0400
From: Tim Daly
To: Bill Page
Subject: Re: successfully built axiomUI on Fedora 3 x86-64

>4) 'make doc' does not run because the current Axiom build does
>    not put noweb.sty into the /usr/share/texmf tree. Instead the
>    path is hard coded. You could use this convention, in which
>    case the file should be named '${AXIOM}/bin/tex/noweb.sty'
>    but perhaps better, the Axiom build should put a copy of
>    noweb.sty someplace standard like this:
> 
>    mkdir /usr/share/texmf/tex/latex/noweb
>    cp $AXIOM/bin/tex/noweb.sty /usr/share/texmf/tex/latex/noweb
>    /usr/bin/texhash


good point. i'll fix this.

\start
Date: Sun, 4 Sep 2005 09:40:37 -0400
From: Tim Daly
To: Bill Page
Subject: Re: successfully built axiomUI on Fedora 3 x86-64

I'd leave this detail for me to solve...

>1) All intermediate and binary files are created in the
>   'src/web-gui' directory. As a minimum, to be (more or less)
>   compatible with the Axiom build intermediate files should
>   go into directory 'int/web-gui' and the binaries/executables
>   should go into 'mnt/bin'

I have the machinery to do this and it's a waste of Kai's time.
The details of final integration are extremely time consuming and
very tedious. 

\start
Date: Sun, 4 Sep 2005 12:20:58 -0400
From: Tim Daly
To: list
Subject: --patch-45

The rather-delayed september update...

I'll try to push this out to the savannah and sourceforge servers today.

Tim

Summary: merge aldor patches, fix C code
Keywords: daly, broadbery

20050831 tpd --patch-45
20050831 tpd src/interp/setvart.boot changed )set compile default to 'on'
20050831 tpd Makefile removed recursive clean into src
20050831 tpd src/graph/viewman/make3D.c initialize cMin, cMax, cNorm
20050831 tpd src/hyper/htadd.c cast fstats.st_mtime to int for fprintf
20050831 tpd src/hyper/htadd.c change 'long pos' to 'int pos'
20050831 tpd src/hyper/htadd.c initialize db_fp, temp_db_fp, ht_fp
20050831 tpd src/doc/Makefile.pamphet use $DOCUMENT on DeveloperNotes
20050831 tpd Makefile add WEAVE variable to ENV
20050831 tpd src/interp/setq.lisp added Heow Eide-Goodman
20050831 tpd src/interp/setq.lisp added Kai Kaminski
20050831 tpd README added Heow Eide-Goodman
20050831 tpd README added Kai Kaminski
20050829 pab src/interp/patches.lisp modify restart0 for Aldor
20050829 pab src/interp/i-syscmd.boot modify <<remove TRUENAME>> for Aldor
20050829 pab src/interp/foam_l.lisp modify PtrMagicEQ for Aldor
20050829 pab src/interp/daase.lisp modify create-initializers for Aldor
20050829 pab src/interp/ax.boot modify axFormatPred for Aldor

\start
Date: Mon, 5 Sep 2005 00:05:18 +0200
From: Pierre Doucy
To: William Sit
Subject: Re: axiom on Mac OSX

> Can someone point out how to "dummy" out these, I believe non-existing under
> MacOSX, files to force the compile to continue? or replacement files? (for a
> start, some version of localtime.c that wct.c would like.  MACOSX must have some
> equivalent time functions.
>

Hi all,

you should check this list's history. This has been discussed before
(look for "-I/usr/include/sys on MacOS X" as the thread title).

I used to try to compile Axiom on OSX, but unfortunately lack the time
to do it now. I can send you my modified source if you wish (although
it is from a 3 or 4 months old check out)


Hope that helps,

\start
Date: Tue, 06 Sep 2005 00:25:51 +0200
From: Kai Kaminski
To: Bill Page
Subject: Re: successfully built axiomUI on Fedora 3 x86-64

Bill Page writes:
> Thanks for your lastest tla axiom-GUI--1--patch-2. Below I have
> included an additional patch to use the $AXIOM variable instead
> of hardcoding paths or depending on implicit paths. This is
> consistent with the approach used in the current Axiom build.
>
> With your tla patch-2 and this patch I successfully built axiomUI
> web-gui on my Fedora Core 3 x86-64 system.
It's good to hear that.

> This is what I noticed so far:
>
> 1) All intermediate and binary files are created in the
>    'src/web-gui' directory. As a minimum, to be (more or less)
>    compatible with the Axiom build intermediate files should
>    go into directory 'int/web-gui' and the binaries/executables
>    should go into 'mnt/bin'
I know. I was hoping to do this better, but Make is a complicated
beast and I haven't used it in years. When I saw the deadline flying
past I just stopped working on it.

> 2) run-axiom-ui.sh does not have executable flag. It needs
>
>    chmod a+x run-axiom-ui.sh
I usually do not to set the executable flag for shell scripts of this
kind. Since the directory where run-axiom-ui.sh resides is not in my
path anyway, I'd have to use ./run-axiom-ui, which isn't better than
sh run-axiom-ui.sh. But I really don't mind, so I'll change it.

> 3) Running
>
>    ./run-axiom-ui.sh
>
>    produces no initial startup message. Something re-assuring
>    and informative like:
>
>    "Waiting for browser http:/127.0.0.1:5050"
>
>    would be nice :)
True, that was the evil deadline again. I'll fix that.

> 5) How can I exit cleanly from the run-axiom-ui.sh process?
>    Perhaps it should catch the ^C and kill signals and do
>    something nice.
Press Ctrl-C once (or maybe twice should drop you to the debugger. If
you just want to quit you can press Ctrl-D twice. I agree that this
isn't very user-friendly and I'll fix it.

> 6) On linux at least maybe we should setup an inetd service to
>    start run-axiom-ui.sh automatically on port 5050 so that this
>    is transparent to the user? Can you think of any other way
>    that we can make it unnecessary for the user to start two
>    processes? Should run-axiom-ui start the browser session for
>    the user?
I'm not sure what the best way is to do this. Maybe a shell script
that starts the web-gui as well as the browser is the way to go. So
far I didn't bother with this since the web-gui is not ready for
end-users anyway. And developers might actually hate it if
run-axiom-ui.sh always starts a browser automatically, since they
might want to start a different browser each time or use other tools
like netcat to connect to the web-gui. I'll add a second shell script,
so that there is one for developers and one for users.

> 7) Of course since this is 'alpha' version there are many easy
>    to find problems with output. The graphics output seems
>    especially fragile. The examples you give work fine but if
>    one deviates slightly it is possible to produce a mess.
>    E.g.
>
>      draw(1/sin(x),x=0..2*%pi)
The problem here is that Axiom prints denormalized (?) floats, which
leads to a floating point underflow on the Clisp side. The easy way to
fix this is to use Clisp's long floats (which allow a much greater
range than IEEE double float), but since in the future other GUIs in
other languages might get written, it's probably better to treat this
problem on the Axiom side. I'll look into this, but I'll need some
time. 

> Perhaps I should set up some AxiomUI categories on IssueTracker to
> help keep track of these problems?
I think it's a bit too early for that. Right now there are so many
problems that writing them all down wouldn't do much good. I don't
intend to abandon this project, so if there is a bug, just send me an
email.

> Now that SOC is over, what is the best way for us to ensure that
> the project development continues? Will you be able to continue to
> be involved? If so, would to be willing to continue to take the
> lead?
Yes, of course. I'm currently thinking about what the best way is to
proceed. There are quite a few things about the web-gui that I don't
like very much, which I did to meet the SoC deadline. Now that the SoC
is over, I hope to correct these problems.

There is only one real problem right now. As you know my own Linux box
died during the Summer of Code and I'll have to give the replacement
back at the end of this week. Then I'll have to leave town for a
week. After that I'll probably put some effort into the OS X port,
unless I manage to get my hands on another Linux box. We'll see.

Thanks for the patch,

\start
Date: Mon, 05 Sep 2005 17:30:55 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#202 Axiom Tutorial PDF on Windows - Bitmap fonts used] upgrade Acrobat Reader

There are several Axiom Tutorials. See

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

There is also the Axiom Tutorial that is distributed with the
Windows binary. See link under Start/Axiom

All of these look fine on my system. I am using Acrobat Reader
7. Download it from
http://www.adobe.com/products/acrobat/readstep2.html

Older versions of Acrobat did not display all fonts properly.

\start
Date: Mon, 5 Sep 2005 19:44:19 -0400
From: Tim Daly
To: list
Subject: savannah, sourceforge up to patch-45
Cc: Camm Maguire

*,

I've brought savannah (http://savannah.nongnu.org/projects/axiom)
and sourceforge (http://sourceforge.net/projects/axiom) sources up
to the latest level (--patch-45) which includes Peter's Aldor code
patches (although not the full aldor integration).

I'm now compiling the sources on various platforms to update the
binaries.

\start
Date: Mon, 5 Sep 2005 22:28:03 -0400
From: Tim Daly
To: Emil Volcheck
Subject: ACM/ISSAC Active Journal
Cc: Patrizia Gianni

Emil, et. al.

For the past two years I've been building the proceedings CD that gets
distributed at ISSAC. This has been interesting but not really breaking
any new ground. And the process starts at the last minute so there is
very little time to do anything but get the CD assembled.

This year I'd like to consider something more interesting and to do that
I need to start much earlier (now).

Consider the following idea:

  You are giving a talk about a new algorithm. During the talk you give
  out the URL which contains a copy of your paper. The paper is a literate
  program which contains latex plus the full source code.

  A person in the audience can put a special Live CD in their laptop (which
  boots linux but does not change their hard drive). They open a browser.
  They surf to the given URL. They "drag and drop" your paper onto their
  machine, it compiles, installs, and is set up to run.

  Now the person in the audience can actually execute your algorithm while
  you are giving your talk.

  This is the "Doyen" idea. It can be applied in all of the science
  conferences but ISSAC is a perfect test case.

For background some of you need to know that Carlo Traverso has been trying
to develop an "Active Journal" which would accept "Literate Programs" for
publication.

Literate programs (my definition) are papers that contain the complete,
runnable source code for the published algorithm as well as things like
proof of termination, order of the algorithm, etc. If these are published
in an Active Journal then people will be able to use the algorithms directly.
This has been a problem in the past (e.g. a new, faster Groebner basis
algorithm that does not have associated code). Given that we are doing
computational mathematics I claim that running code is as important as
a proof. Axiom has been rewritten to be all literate programs (that is,
all of the files are now documents and there is no lisp, boot, spac, C, or
Makefile files anymore).

Another effort is the Doyen Computational Science Platform CD project 
(http://sourceforge.net/projects/doyencd)
which has created a Live CD (that is, one that will boot linux on a
computer from the CD without changing your hard drive). The goal of
the Doyen project is to set up a Live CD that contains several computer
algebra systems, a web server, a browser, and a special Wiki, a website
user's can change. Thanks to Bill Page Axiom already has such a wiki
(http://page.axiom-developer.org) 

You should be able to "drag and drop" a literate program onto a Doyen
CD and have it automatically compile, install, latex, and set up to run
the program in the paper. Doyen is not quite there yet but that is the
goal.

If we can create a working demonstration of a Doyen CD for the next
ISSAC then we can encourage people to write algorithms that will work
on the CD software and publish the resulting literate programs in 
Carlo's Active Journal.

All of this technology exists in prototype form. ISSAC would be the 
perfect forum to demonstrate a working prototype and it would certainly
make the ISSAC CDs much more than just an electronic copy of a paper
journal. If this works then the ACM can spread the technology to the
other computational science areas.

Comments?

\start
Date: Mon, 5 Sep 2005 22:28:44 -0400
From: Tim Daly
To: Camm Maguire
Subject: Re: Axiom sources for Debian release with 2.6.7
Cc: Allen Rouse

Camm,

If I do 

echo 0 > /proc/sys/kernel/randomize_va_space

then Axiom builds on FC4

\start
Date: Mon, 05 Sep 2005 23:15:34 -0500
From: MathAction (Tim Daly)
To: MathAction
Subject: [#203 Using local database messages occur on some builds and not others.] (new) 

For some unknown reason the int/input/*.output files on 
--patch-45 contain the messages

Using local database

that do not occur on the --patch-44 build on Redhat 9.

\start
Date: Mon, 05 Sep 2005 23:16:59 -0500
From: MathAction (Tim Daly)
To: MathAction
Subject: [#204 Loading $AXIOM/algebra/MSYSCMD.o for package MoreSystemCommands] (new) 

For some unknown reason the int/input/*.output files on 
--patch-45 contain the messages

Loading $AXIOM/algebra/MSYSCMD.o for package MoreSystemCommands

that do not occur on the --patch-44 build on Redhat 9.

\start
Date: Tue, 6 Sep 2005 02:46:46 -0400
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

On Sunday 04 September 2005 01:22 am, William Sit wrote:

> ---------- General discussion on documentation
>
> C Y wrote:
> > --- William Sit wrote:
> > > you have already started real work.
> >
> > That's probably too generous - I've started trying to become informed
> > enough to start real work, really.  Bill is probably going to flinch
> > when he sees my idea of basic pre-code (heck, it's really pure
> > background) documentation :-).
>
> Tim will love you!

Well, we'll see - it's way more of a challenge that I thought it would be 
originally!  (Which I guess is what Axiom is all about, in a way :-).)

> > I hope so, although I suspect your ideas are far more useful than my
> > own - I'm just asking questions and swatting user level features around
> > in my head at this point.  The hard part (and interesting part) is
> > expressing them in relation to Axiom's mathematical rigor.
>
> You are welcome to ignore or include in your work/paper any ideas I
> presented on this forum.

Thanks!  (Of course, that presupposes I can work my head around them... ;-)

> The hardest part is knowing questions to ask, and second is figuring out
> the answers; the easiest (though by no means trivial) is to code the
> solutions.

Well, that's the sign of using the right method of problem solving, at least!

> ---------- Basics of the proposal: Representation of UnitSystem domains
>
> This comment of yours is based on your breaking up UnitSystem into Static
> and Dynamic Unit System. This is certainly possible, but see my comments in
> the section on Static vs Dynamic user environment, which will list some
> pros and cons on this break up.

OK, will discuss later.

> > I think the latter is a matter of convenience - converting relative to
> > the current system is also doable via input unit -> SI -> output unit -
> > if I understand you what you are doing is precompressing this two step
> > process into one for the default "output" system?
>
> The relative factor can either be built-in for the UnitSystem domain, or
> via the SI mechanism. But we have to remember that SI is not universal
> (supermarket manager example). So a relative factor setup solves the
> general situation and is also more efficient. The SI approach is mainly for
> scientific applications AND conversion between two drastically different
> systems. Believe me, in less than 30 years, symbolic computations will be
> used by economists, if not already. (Mathematica has an operations research
> package, sold separately).

Hmm.  OK, I'll go along with that.

> Yes, I am more in favor of every UnitSystem domain being dynamic (again,
> see that section). As to shortening the Rep, yes, in principle, for
> "scientific" unit systems, it only needs a conversion factor relative to
> SI, and yes, for static unit systems, the relative conversion factors are
> not needed either. However, SI is not everything, so the relative factors
> will be needed in those cases, and SI may be replaced by another standard
> unit system.

OK.  The concept of an "Information" dimension, (i.e. whatever underlies the 
concept of bytes as a unit) convinced me of that.  Neither SI nor the seven 
physical Basic Dimensions are sufficient.

> C Y wrote:
> > This is definitely interesting, but I'm not sure we want such an ability
> > to be the default - I would suggest hiding the conversion factors unless
> > the user specifically specifies otherwise.  I like the idea of the
> > ability to explicitly show them though :-).
>
> What you meant then is to have something like:
>
>     setSymbolicConversion(): Boolean
>
> as default True, which will include symbolic conversion factors. Setting
> this False will use numerical values. However, if you meant that when I
> setDimUnit("Length", "cm",x) and x was in "m" originally that it will
> output only x [cm] instead of x m2cm [cm], then I don't agree.

Oh, I think I get it - you're discussing the case where the user does the 
following:

a)  assign a variable (call it "x") not only a specific dimension but also a 
specific unit.  (I expect this to be somewhat unusual but it should be 
legal.)
b)  either the unit assigned was different from the current global, or the 
current global is changed.  Now when "x" is evaluated that unit must be 
converted.
c)  we want to show that conversion descriptively (or have the option to).  
Agree.

What I was thinking about was probably setDim("Length", x).  My mistake - you 
were thinking further ahead than I was.

> ------------ Basics of the Proposal: UnitSystem domain specifications
>
> The following addresses only the user interface specifications under
> discussion and is not a complete specification for the category:
>
> C Y wrote:
> > I don't quite understand s:S - can you give a specific example of this
> > difference?  Also, I'm not following why you would want to make any
> > local vs. global distinctions here - wouldn't it be neater just to have
> > the set commands work in the CurrentUnitSystem, and base things off of
> > Static UnitSystems for definitions unless a totally custom conversion
> > is being defined?
>
> In the setDimUnit, 'setDimUnit' commands, an expression s:S is involved,
> where S is a domain that usually contains symbols ("RetractableTo Symbol"
> in Axiom jargon) and s:S means s is such an expression. 

OK.  So in words, s is some specific symbol defined in the domain S.

> Of course S can be just Float if no symbols are involved, in which case,
> expressions and  variables are simply constants.  But the user assigns a
> dimension and unit  to an expression, which will change the way certain
> variables involved in  the expression are inputted or outputted. This
> setting is for a specific expressions s, so has "local" scope. 

OK (I think.)  

> The other 'setUnit' is local for a 
> specific dimension, but has a wider scope and affects all expressions of
> that dimension. Finally, the 'setUnitAll' is global in the sense that all
> derived dimensions involving that specific dimension and all expressions in
> all those derived dimensions will be affected. The implementation will be
> assisted by the UnitConversion domain and the Rep remembers the conversion
> factors both relative to the current system and to the SI system, when
> possible.

I think I've got it - so there are three levels:

a)  change properties within a single expression, don't change global settings
b)  change global settings for one dimension, but not for other dimensions 
building off of this one
c)  change global settings for ALL dimensions using this dimension - e.g. the 
default rendering for force would become kg*cm/s^2 if 
setUnitAll("Length","cm") were used. 

> My proposal allows (but the decision is still open) changing the units for
> a single expression s:S -- 'setDimUnit(dim,u,s)'. It also allows changing
> the unit of a single dimension, say Length, in the current (loaded) unit
> system without affecting other derived dimensions that involve Length --
> 'setUnit(dim,u)'. Finally it allows changing the unit of a single
> dimension, say Length, and any other derived dimension that involves
> Length, such as Velocity -- 'setUnitAll(dim, u)'. 
>
> In your example above, changing the unit of Length 
> from "m" to "cm" will report the unit of Force (the dimension of "N")
> either still as "N", if 'setUnit(Length,"cm")' is used in SI; or as
> kg-cm/s^2 (by changing the value of any expression with dimension Force by
> a conversion factor m2cm), if 'setUnitAll(Length,"cm")' is used in SI; in
> which case, the new unit of "Force" is "kg-cm/s^2" or "kilodyne", following
> SI prefix convention (basically changing SI, which is MKS based, to CGS).

So let's say I define some examples (sorry, I'm not up enough on Axiom syntax 
yet to use it for this) would this be roughly how things would work?:

a::Length
b::Length
c::Force
setDimUnit("Length","cm",a)
setUnit("Length","m")
setUnit("Force"", "N")

-> a
                     a  cm                [Length]
-> b
                     b  m                  [Length]
-> c
                     c  N                  [Force]

setUnitAll("Length","km")

-> a
                     a cm2km  km        [Length]  (or would this stay as cm?)
-> b
                     b m2km  km         [Length]
-> c
                     c m2km  kg km / s^2     [Force]  (with better formatting)

setUnitAll("Time", "millisecond")

-> c
              c m2km s2ms^-2  kg km / ms^2     [Force]

[snip]

> Each expression requires one lookup at the
> time its dimension and unit is set. All subsequent uses and display will
> avoid the lookup again even if, in case of a variable, it is reassigned to
> a different value. All necessary conversion is taken care of by the
> arithmetic operation in the UnitSystem domain.

OK, I think I like this.

> > Does that mean an interpreter update is needed.?
>
> I hope not! The 'update()' function can handle that. We should not modify
> the Interpreter for this project unless it is absolutely necessary, which
> so far, I don't see. It is possible for the 'setDimUnit' function in the
> UnitSystem domain to record all calls to the 'setDimUnit' command to create
> and maintain a live list of variables or expressions, say as part of the
> state vector. An update can either be applied for just one variable in the
> domain, or all variables in this live list.

OK - so long as these things can be handled automatically (I had to hack in a 
mechanism in Maxima to do autoconverting globally.)

> ---------- Implementation issues: Updating variables and their units
>
> Some updating questions are raised and solutions suggested in the Scenario
> Example section above.
>
> > As for current variables, shouldn't they be updated automatically by
> > the global update?
>
> That is the idea. That is, a 'setUnitAll(dim, u)' command will change all
> output and input variables/expressions that are of dimension dim to use
> unit u. In the scenario Example section, we discussed the issues and some
> possible actions. The basic design question to decide is: should this
> global command affect only newer variables/expressions or should this
> retroactively set all existing variables/expressions? The basic
> implementation question is: what data structures will support these
> functionalities efficiently (bear in mind some trade offs between memory
> and CPU time, as usual)? It seems the proposed state-vector can support the
> implementation, whatever the decisions.

I think I would vote for retroactively setting all non-derived unit using 
instances, with perhaps another command to make this change without updating 
previous instances.  (How about setUnit is retroactive and changeUnit is from 
this point forward?)

> > I would have thought all you needed was a single command SetUnits()
> > command, which would take a minimum of one argument and a max of one
> > unit per available dimension, e.g.
> >
> > SetUnits(nm,N,inches);
>
> [NB, Axiom convention:function names should start with lower case]
>
> I do not quite follow. Your example has three arguments, all units of
> Length.

Not quite - N is force.  That was a mistake on my part - I meant something 
like setUnits(g,N,inches).  The above should have (and does, in Maxima) 
return an error.

> I think you are thinking of 'setUnitAll(dim, u)'? Maybe a simpler 
> 'setAll(u)' and let the system figure out the dimension of u? (But as
> explained below, this reverse lookup from unit to dimension is not unique;
> in that case, we can make 'setAll(u)' return an error message with some
> choices (probably not all possible choices). So you would still need the
> version 'setUnitAll(dim,u)' after the user picks one of those choices.

Yes, I understand your scheme better now.

> Your line:
>
>   SetUnits(nm,N,inches);
>
> is, as far as I can follow, a global set. 

In Maxima, I think this works as a global setting (retroactive) of all 
non-derived instances of a dimension to a new length - essentially the same 
as doing 

setUnit("Mass","g")
setUnit("Force","N")
setUnit("Length","Inches")

but letting Axiom figure out that g is a unit of Mass, N is a unit of Force, 
and Inches is a unit of Length.

> Surely, in this simple example, 
> Axiom can figure out that these (nm, N, inches) (aside: use "in" for
> "inches" -- SI recommendations) are units for Length, but as explained,
> this is not possible in general. My version 'setUnitAll(dim, u)" only does
> this for a particular dimension dim and a particular unit u. I don't know
> why you set the Length dimension to THREE different units.

Typing error ;-).  I meant to set the unit of three different dimensions.

> Are you  imagining mixing units for the same dimension in one session? 
> How are you  going to tell which variable/expression will use any one of
> these three units? Are you saying that ALL three units should be reported
> for ANY variable/expressions of dimension Length? (Note: even if you are
> mixing  units, the Rep will support it. I just want to know what your line
> meant.) 

The line meant I was sleep deprived ;-)  Hopefully round two makes more sense.  
The potential to report a single quantity in a list of different units, one 
converted quantity to a list entry is interesting but not really what I was 
after.

> Fair enough. We can ALWAYS add defaults. The example I gave in my last
> message (added above in Section on UnitSystem specification):
>
>    setDim(dim: Dimension, s:S):% == setDimUnit: (dim, unit(dim), s)
>
> performs a lookup for the default unit for a given dimension in the current
> UnitSystem. The 'setAll(u)' above can handle cases where an automatic
> lookup results in a unique dimension to set the dimension field in Rep.
> However we do not want to look up repeatedly each time we use a variable,
> so the results are memorized in Rep.

OK, that should do it.

> And, yes, users should know the dimension of the unit they are inputting.
> One danger with something like 'setAll(u)',  which left out the dimension
> for u, is that a simple typo say from 'setAll(cm^2)' to 'setAll(cm^3)'
> would not be caught and play havoc in subsequent computations. Forcing the
> user to give the intended dimension provides a better chance that these
> errors will be caught.

I agree - I would like to have a "strict" mode available which compels the 
user to do this.  I fear making it the ONLY alternative will lose us users 
though.  

> > Maybe as a time saving alternative SetUnits could also
> > accept things of the form <UnitSystem>::Unit or some such, which would
> > limit the search space it would need to check?
>
> I don't follow the syntax of <UnitSystem>::Unit. Is :: coercion in Axiom? I
> have not heard of coercing a domain into a category. Perhaps you are
> thinking of a package call to a domain in UnitSystems? That would be
> setAll(u)$domain. But I do not like this default setAll(u) for reasons
> above.

Uh, nevermind.  I didn't understand your proposal as thoroughly as I needed 
to.  I meant to say one could say something like setUnit("SI/cm") or 
setUnit("SI->cm")  or whatever makes sense.

> > Or even better, if
> > Axiom is up to it we might also be able to build a toplevel hash table
> > of all defined units in all unit systems at compile time which can
> > quickly match up a unit up with a UnitSystem and Dimension.
>
> The UnitConversion domain (perhaps category) is for this purpose. I am
> still thinking about whether UnitConversion should be a category with many
> domains or just one domain. The many-domain approach may provide better
> efficiency for more localized conversion systems and flexibility future
> additions.

Yes, I think we might want to do something like that - it would allow (or 
would it?) the possibility of a UnitConversion category with domains for 
PhysicalUnits, ComputerUnits, EconomicUnits, etc.

> As we don't know all the expert areas now in existence, nor do we know what
> new derived dimension or unit we may need (especially in 30 years' time),
> there is no way we can have such a universal toplevel hash table. We CAN
> implement SI (all the default and acceptable dimensions and units) or even
> more, but such a domain will need to be revised to allow newer dimensions
> and units. The design proposed will allow this of course (any design in
> fact), but I still subscribe to the older Axiom philosophy that we do not
> modify existing libraries except for bugs, and extend existing libraries
> through additional implementation. We should allow arbitrary UnitSystems
> (as I also indicated in my last email, supermarket manager will need a
> totally different, "non-scientific" unit system with dimensions like
> "Coke", "DietCoke", etc.)

I agree.  I'm really curious to see if something like this ever gets used in 
such an application :-).

> ---------- Implementation Issues: Setting up Dimension and Unit domains
> C Y wrote:
> > Dimensions
> > may not always map uniquely to Units, but Units DO map uniquely to
> > dimensions.
>
> Your last remark is wrong, unless there are already standard terminology
> such as in the case of Work vs Moment: standard energy-units exist as
> Joule, erg, eV, etc. and moment-units exist as N-m, etc. 

Ah, point.  Darn.

> In other cases, 
> you may have to create new standard names first. 

How about we allow the mapping to go through when it IS unique, and return an 
error or ask a question if it isn't (something like provide a list of 
options, and ask the user to select one)?  (Maxima has the ability to ask 
questions of the user if it needs to - it makes some problems MUCH easier to 
solve.)  This is helpful and friendly to the user while still being fully 
correct.

> However, the problem still 
> is: given some unit in reduced basic dimensions such as
> (mass-length/time^2).length, say kg.m^2/s^2, we do not know if the
> dimension should be Energy (either Work or Kinetic Energy or Potential
> Energy) or Moment. Vectorizing some of these dimensions may help: Work is a
> force vector times a length vector, and so is moment, but the two length
> vectors have different directions with respect to the direction of the
> forces.

Woo boy.  That's going to be a challenge to report - direction of length 
vector as a factor in results.  Actually, that's an interesting question - 
two length vectors may have different components, but the same magnitude.  
Does the unit meter represent merely the magnitude, or the vector information 
as well?  How do we represent vector information if we want to preserve it 
through the process of reducing dimensions?  The Work vs. Moment example 
would seem to argue that vector information and Dimensions can't really be 
separated, but I don't really know if I'm interperting that right.

> --------- User environment for Unit systems: Static vs Dynamic

> All Axiom variables are typed. So once a user started computating using a
> UnitSystem domain, say A, all his computations will be in that unit system.
> If he then change to SI, he would have to coerce them to SI, which may or
> may not be possible, depending on what dimensions and units are in A. (So,
> the domain A, and the UnitSystems category, may have to include functions
> like convertIfCan: % -> SI).

Hmm, good point.

> I think you want somehow to restrict some users (say students who are
> learning about units and dimensions) not to allow them to "mess" with a
> UnitSystem domain like SI. I don't see the necessity because most likely,
> such users will only want to do their computations in whatever unit system
> is the default. Even if they were to use 'setDimUnit', 'setUnit', and
> 'setUnitAll' (which would be a good experience), these only affect the
> interpreter session and will not modify the SI domain at all. The
> state-vector does not survive an axiom reload since no modification to the
> compiled code is performed. 

Ah, OK.

> Also a user can save the history of all inputs, 
> including all 'set' commands (and also ')set' commands) and put them in
> axiom.input or a 'myunitmod.input' and read it in anytime. There is no
> need, in this dynamic design, to modify ANY compiled domain in the
> UnitSystem category. When a user wants to have modification compiled into a
> modSI domain, he will have to edit the SI.spad.pamphlet and change it into
> modSI.spad.pamphlet and compile it. However, I don't see the necessity.
> Your idea of
> 'SaveUnitSystem(<newUnitSystemName>) is difficult (but not impossible) to
> implement and involves automatically editing say SI.spad.pamphlet to
> modSI.spad.pamphlet and automatically compiling it. It is trivial for a
> user to read in an input file instead.

Actually, that was more my idea - have the saveUnitSystem command pick out all 
the most recent inputs that set the UnitSystem environment, and save them to 
a file.  The trouble is to pick out such commands, which was why I thought it 
might be simpler just to diff the "current" environment from the "default" 
environment and autogenerate the minimum set of commands to get from a to b.

> I note that each of our positions on this user environment issue has turned
> 180 degrees from earlier communications :-).

Hehe :-).

[snip]

> Requiring rebuilding the hash tree is not a good idea because a domain is
> supposedly stable once built. Plus, if someone adds a new UnitSystem
> domain, who would be responsible to rebuild the single hash tree? If the
> new domain introduces new dimensions and units, it should create a
> corresponding UnitConversion domain (hash tree) and leave the standard hash
> table alone.

Hmm.  Yes, a hash tree makes sense only when polluting the namespace.

> --------------- Name space issues
>
> > (I'm still
> > plotting to allow the user to gobble up all the unit names in the
> > default namespace at their option, and that will DEFINITELY need
> > interpreter work.
>
> As you know, I am strongly against "gobbling up all the unit names in the
> default namespace' even if it is 'at their option'.  If you are seriously
> thinking about student use, you know the average students will exercise
> their options without knowing or understanding what they are doing. There
> is no way to consistently reserve SOME unit names in namespace, and not
> others. Any code to implement this will have to know the reserved names a
> priori and that means ALL the abbreviations in SI units at a minimum.

Right.  Reserving some would be worse than none, because it would be 
inconsistent.

> You  would have created a nightmare in using the interpreter by requiring
> users  to avoid any SI unit abbreviations as user variables. No computer
> language  ever has that many reserved words. Note: Axiom function names 
> are NOT  reserved, but constructor (which may be category, domain or 
> package) names and their abbreviations are.

If we were talking about a normal computer language, I agree.  However, in 
normal scientific usage, proper definition and use of equations should NOT 
use SI abbreviations as variables.  Doing so creates far too much potential 
for misinterpreting said variables later on.  I grant that your proposed 
system has a far better chance than any I have ever seen or heard of of 
making this workable, by being able to separate out m the variable and m the 
unit in the output even if they look the same to the human eye - e.g.:

(1)-> 3*setUnit("Length","m","m")
       
                                          3m m
                                                                     [Length]

If this can actually function, then I am for it because it would be a 
virtually ideal solution, and it is more general in case other, non-physical 
unit cases need that generality.

> Modifying the interpreter because of a specific category or its domains is
> a bad idea. Any modifications should be general purpose or fixing bugs.

OK.  That I agree with.

> Most users
> will want to have more flexibility. I think even for student use, if they
> want to experiment with changing units (at run time), why should that be
> forbidden? (for that matter, Axiom being open sourced, why should ANYTHING
> be forbidden?)

Well, I might answer "encouraging correct and best practices" but that's only 
a good argument for defaults and utilities, not coding in limitations.

> There is perhaps one way to use variables (instead of strings) for
> dimensions and units, but they will be local to the domain (using domain
> namespace, rather than user namespace) and they will not be assigned any
> value. The advantage over strings is that they can be used to perform
> arithmetic operations of multiplication and division as symbols. Then
> general conversion factors can be computed by setting up a small number of
> conversion rules and by solving an equation.

I'm beginning to see how this might work - visually speaking though, it hinges 
on the robustness of Axiom's separating units and non-units in output.  I 
think Axiom might be able to do this in a way most other systems couldn't (at 
least not without a lot more work).

> Default relationship (tables) for conversion tables (which include both
> dimensions and units) and the dependencies like state-vectors, can use hash
> tables.

Or whatever is easiest/best.  I don't know offhand that hash tables are.

> ---------- Implementation Issue: Simplification of dimensions
> C Y recently wrote:
> > OK - so how to we represent this in a  CAS?  Or more specifically, what
> > about the fact that a dimensionless constant has dimension that cancels
> > is useful for us to display, and how do we go about it?
>
> We can do this:
>
>   piInEqn1:= setDimUnit("Length/Length", "m/m", %pi)
>
> or
>
>   piInEqn1:= setDimUnit("1", "1", %pi)
>
> but
>
>   piInEqn2:= setDimUnit("Degree/Radian", "deg/rad", %pi)
>
> Perhaps we can add a field to Rep that gives the reduced dimension as well?
> or provide a function
>
>   reduce: Dimension->Dimension
>
> (which in any case, will be useful and necessary).

Yes, I think so.  Is the concept of reduced dimension defined anywhere?

[snip]

> Yes, unless given other examples, I think this is a way to get out of the
> dilemma. Of course, the strong typing of Axiom already drove developers
> nuts, and I'm afraid, surely, the strict setup to dimensions and units may
> likely do so to scientists or economists. This is the price to pay for
> insisting on formal correctness.

Perhaps not as bad as I originally thought, but the documentation for use will 
be critically important.  Perhaps that is an argument to continue work on the 
much less correct but perhaps friendlier in the short term Maxima units 
package, which I see now is focused exclusively on Physical Units.

> > > >Could unit and dimension cancelation be handled
> > > >on a per dimension basis?
> > >
> > > May be, or may be not. It depends on the physical meanings of the
> > > variables. If I have price at $5/m multiplied by 7 m, I should get $35.
> > > If I have 8 N divided by 2 m^2 for pressure, and N has dimension
> > > kg-m/s^2, is it ok to cancel one of the m? So a single rule of Length
> > > (m) is not applicable to all cases.
> >
> > This will need to be handled, somehow.  Are there any good references
> > that contain the applicable rules for us to implement?

[snip interesting references]

> Whether any such references will help us develop the rules to simplify
> dimensions, I don't know. From what we have discussed, it seems any rule
> will need some expert knowledge (in the example I gave, the expert
> knowledge is simply what pressure is). So I believe the best solution may
> be to "leave it to the users", and let them create their own names and
> simplification rules. 

Sounds good. How about as good setups are created we merge them into Axiom?  
Perhaps Axiom will become the central repository for advanced unit 
interaction rules, as people build off of the (hopefully) sound foundation of 
Axiom?

> This means that in a UnitSystem domain, there ought 
> to be facilities to handle rules of simplifications, where some common
> defaults can be implemented. Axiom has a RewriteRule domain that can help.
> RewriteRule can also be used efficiently to perform conversion. (I once
> wrote a UnitConversion.nb in Mathematica for a course using this idea: all
> conversion factors between the two units for the same dimension is then a
> simple Solve[unit1 = x unit2, x])

Hmm.  Worth some thought.

> > You mentioned $ interacting with meters, and in a previous email kilobits
> > and kilobytes were also mentioned.  Unfortunately, neither money nor bits
> > of information are covered by any combination of SI units I am aware of. 
> > So perhaps our top level category should be not simply Dimensions but
> > PhysicalDimensions, and we could perhaps implement some other Categories
> > for Dimensions not covered by SI (like money and bits, both of which are
> > Basic Units as far as I can tell).  Money might be defined in terms of
> > other things in some sense, but that definition is as complex as society
> > itself and ever changing.  Fascinating issues, but perhaps those should
> > wait for later. Indeed, does it even make sense to include a concept like
> > money in a system intending to stick to strict mathematics as much as
> > possible?  I suppose yes since we can think of practical uses, but
> > thinking about it is making my head hurt ;-).
>
> "Now, you're thinking!" :-)
>
> In my case, thinking about these things make me stare at the screen and
> then fall asleep! But you got a point here, building unit systems should
> include, or at least allow future inclusion, of systems outside of the
> usual scientific sphere. So having an WallStreetDimensions,
> SupermarketDimensions, FontsMetricDimensions systems would be fun 
> but we don't have to implement them right away.

Without doubt scientific units will be the most useful in the short term.  
Building scientific symbolic computing on top of Axiom is going to require, 
as near as I can tell, three things:

a)  the concepts of Dimensions and Units (underway)
b)  Significant Digits, Uncertainty in Measurement, and Error propagation 
(hard, both in itself and also since potential errors due to the numerical 
calculations of the computer must also be considered in order to be rigorous)
c)  Domains of significance.  I don't know what else to call this, but as an 
illustration, we know that Newton's laws of motion break down near the speed 
of light.  Science generally gets on with life by neglecting Einstein type 
effects at velocities which are low compared to c, since any possible 
contribution due to those effects is washed out and below any significant 
level of measurement possible.  So, let's say we input the fully general 
equations into Axiom for motion, velocity, etc. since we like generality.  
However, for sufficiently small velocities (or more correctly, sufficiently 
imprecise) measurements, we want to use Newton's equations, even 
symbolically.  They should (and do) simplify in the limit, and we want Axiom 
to be able to understand or even figure out such things on request, since 
such information is very useful to practical work.  Plus, it would be an 
awesome way to build intuition on when things matter.  The problem is, there 
would need to be a definition given for sufficiently imprecise.  Either 
deduced from supplied measurement uncertainties (and it should deduce them if 
it can since the human probably can't be relied on for this) or supplied in 
purely symbolic situations.  I have no idea how  to express this idea in 
Axiom, if it can even be done, but it would provide an absolutely incredible 
and powerful tool for using the right  equation given the data.

OK, enough pie in the sky talk :-)  Night all, and thanks William as always 
for your patient, helpful and amazingly powerful ideas and thoughts.  I hope 
mine aren't being too tiresome - I think I'm finally beginning to see the 
light, although I'm afraid we might have a bit more than three set* commands 
when we get done.  (Derived Dimension simplification rules in SI will require 
a few more commands, based on my Maxima experience, and that didn't have 
anywhere near the flexibility this will have.)

\start
Date: Tue, 06 Sep 2005 07:35:56 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

I have snipped without indication, a lot of the paragraphs that we agreed on.

C Y wrote:
> 
> On Sunday 04 September 2005 01:22 am, William Sit wrote:
> > ------------ Basics of the Proposal: UnitSystem domain specifications

> > C Y wrote:
> > > I don't quite understand s:S 
> > In the setDimUnit, 'setDimUnit' commands, an expression s:S is involved,
> > where S is a domain that usually contains symbols ("RetractableTo Symbol"
> > in Axiom jargon) and s:S means s is such an expression.
> 
> OK.  So in words, s is some specific symbol defined in the domain S.

s does not have to be a symbol, it may be an expression involving several
symbols even though that maybe a bit "dangerous" and unusual. This allows the
user who knows what he is doing to use what is known as an aggregate variable.
Aggregate variables are used to simplify the number of variables in an equation
and often very useful to understanding the interdependencies of variables,
reducing the equation into a dimensionless form, or to a linear relationship
between two aggregate variables. However, not all aggregate variables are
dimensionless. The ideal gas law is such an (simple) example: PV/T = constant;
so PV/T is an aggregate variable. The ideal gas law can also be put into the
form PV = cT, where c is the constant. Using PV as an aggregate variable, it is
proportional to T (and how coincidental, of reduced dimension Force*Length again
and unit for example, liter-atm, and the constant c is not dimensionless.)


> I think I've got it - so there are three levels:
> 
> a)  change properties within a single expression, don't change global settings
> b)  change global settings for one dimension, but not for other dimensions
> building off of this one
> c)  change global settings for ALL dimensions using this dimension - e.g. the
> default rendering for force would become kg*cm/s^2 if
> setUnitAll("Length","cm") were used.

That is right.
 
 
> So let's say I define some examples (sorry, I'm not up enough on Axiom syntax
> yet to use it for this) would this be roughly how things would work?:

Your example below is basically the correct scenario. The syntax and output need
some changes, given next. I added sequence numbers.

> a::Length
> b::Length
> c::Force

Since Length, Force, etc are not domains in my proposed setup, you cannot use
the coercion symbol ::. Assuming you started with SI, you would have to replace
the above three lines by:

->(1) ua:=setDim("Length",a)

       a [m]

Note that the unit is output using a pair of brackets, to avoid confusing it
with a variable m, perhaps. Also, the type of ua is now SIUnitSystem(S), if the
type of a is S.
  
->(2) ub:= setDim("Length", b)

       b [m]

->(3) uc:= setDim("Force",c)

       c [kg-m/s^2]  or [N]

> (4) setDimUnit("Length","cm", a)

This would have the following output:

      a [cm]

Note that no conversion factor is used, since the expression a is entered
afresh. The two identifiers a and ua are of different types. This suggests that
we should add a new signature:

     setDimUnit:(Dimension, Unit, %) -> %

so that 

-> (4)' ua:=setDimUnit("Length","cm",ua)

        a m2cm [cm]

> (5) setUnit("Length","m")

This would set all declared expressions of dimension Length to use [m] as unit.
Whether this is done retroactively or not is a design issue. We can provide both
options with an added parameter.
   
> (6) setUnit("Force"", "N")

Same, all expression of dimension Force use N as unit.

> 
> -> (7) a
>                      a  cm                [Length]

No: The use of 'a' will only return 'a', not 'a' with a unit. To get the unit,
you have to use:

-> (7)' ua

Assuming the setUnit does not change expressions already declared when (5) is
run, then

       a m2cm [cm]  (same as (4)') assuming (4)' is run instead of (4).

Assuming the setUnit changes expressions retroactively when (5) is run, then

       a m2cm cm2m [m], or smarter: a [m] (again, if (4)' is run)

> -> (8)  b
>                      b  m                  [Length]

No: Same as (7): would return just b, without unit.

-> (8)' ub

                   b [m]

since (5) does not affect ub no matter what the design is.

> -> (9) c
>                      c  N                  [Force]

No: Same as (7), will return c without unit.

-> (9)' uc
                 c [N]

since (6) has no effect on uc.
 
> (10) setUnitAll("Length","km")

This will affect all dimensions involving Length as a component. Whether this
will apply to expressions retroactively or not is a design issue. We can provide
both options with an added parameter.
 
> -> (11) a
>                      a cm2km  km        [Length]  (or would this stay as cm?)

-> (11)' ua

The expression a was in [cm] or [m] depending on design (see (7)). Assuming you
meant ua instead of 'a' in (11), your output assumes that no retroactive update
in (5) but retroactive update in (10). There are four possibilities already.


> -> (12) b
>                      b m2km  km         [Length]

(12)' ub
                       b m2km [km]

Assume you meant (11)'. Your answer assumes the unit of b is retroactively
updated to [km] when (10) ran.
Otherwise, the Interpreter has no reason to call the unit system package.

> -> (13) c
>                      c m2km  kg km / s^2     [Force]  (with better formatting)

-> (13)' uc
                      c m2km [kg.km/s^2]

This also assumes the unit of c is retroactively updated in (10).

> 
> (14) setUnitAll("Time", "millisecond")
> 
> -> (15) c
>               c m2km s2ms^-2  kg km / ms^2     [Force]

-> (15)' uc
                c m2km s2ms^(-2)  [kg.km/ms^2]

Assuming (13)' and the unit of c is retroactively updated in (14).


> > ---------- Implementation issues: Updating variables and their units
> >
> > Some updating questions are raised and solutions suggested in the Scenario
> > Example section above.
> >
> > > As for current variables, shouldn't they be updated automatically by
> > > the global update?
> >
> > That is the idea. That is, a 'setUnitAll(dim, u)' command will change all
> > output and input variables/expressions that are of dimension dim to use
> > unit u. In the scenario Example section, we discussed the issues and some
> > possible actions. The basic design question to decide is: should this
> > global command affect only newer variables/expressions or should this
> > retroactively set all existing variables/expressions? The basic
> > implementation question is: what data structures will support these
> > functionalities efficiently (bear in mind some trade offs between memory
> > and CPU time, as usual)? It seems the proposed state-vector can support the
> > implementation, whatever the decisions.
> 
> I think I would vote for retroactively setting all non-derived unit using
> instances, with perhaps another command to make this change without updating
> previous instances.  (How about setUnit is retroactive and changeUnit is from
> this point forward?)

Trouble is, neither the word "change" nor "set" provides a definite meaning. So
I think it is better that setUnit or setUnitAll will change all instances
retroactively.  As I already warned, just like when the unit of a single
expression is changed (the setDimUnit, either version), the other alternative,
changing only future instances will give rise to mixed units and a subsequent
computation involving mixed units must be brought to a common unit system. What
would be the unit of the result? I suppose the only meaningful unit is to the
system's unit in the state vector. Thus, by making changes retroactively at the
time a setUnit or setUnitAll is run, we bring the system back to uniformity
earlier and hence subsequent computations are more efficient. Lazy evaluation
does not pay if there are lots of subsequent computations, requiring conversion
for each quantity involved, and with no place to hold the changes.

> Not quite - N is force.  That was a mistake on my part - I meant something
> like setUnits(g,N,inches).  The above should have (and does, in Maxima)
> return an error.
> In Maxima, I think this works as a global setting (retroactive) of all
> non-derived instances of a dimension to a new length - essentially the same
> as doing
> 
> setUnit("Mass","g")
> setUnit("Force","N")
> setUnit("Length","Inches")
> 
> but letting Axiom figure out that g is a unit of Mass, N is a unit of Force,
> and Inches is a unit of Length.

I see, you want to set the units for multiple dimensions in one statement. We
can do that easily by allowing:

    setUnits: (List Dimension, List Unit) -> Null (or state-vector)
 
> > And, yes, users should know the dimension of the unit they are inputting.
> > One danger with something like 'setAll(u)',  which left out the dimension
> > for u, is that a simple typo say from 'setAll(cm^2)' to 'setAll(cm^3)'
> > would not be caught and play havoc in subsequent computations. Forcing the
> > user to give the intended dimension provides a better chance that these
> > errors will be caught.
> 
> I agree - I would like to have a "strict" mode available which compels the
> user to do this.  I fear making it the ONLY alternative will lose us users
> though.

By "us" you meant "USA"? I always remind my students the probe crashed on Mars
was due to mixing up (or unaware of the mix up) units. I don't think user would
mind including the dimension when setting units. It does help prevent typos from
passing through.



> Yes, I think we might want to do something like that - it would allow (or
> would it?) the possibility of a UnitConversion category with domains for
> PhysicalUnits, ComputerUnits, EconomicUnits, etc.

That is the idea. However, there is some technical difficulty that I do not yet
know how to solve, but I think it is doable:

    UnitConversion(dim:List String, unit:List String):Category == ...

Trick is to convert dim and unit into arguments for the constructor Union so we
can form

    Dimension:=Union(dim)  -- right now, syntax error
    Unit:=Union(unit)

There must be a function in Axiom to do that. I just don't know. Here Union is
expecting a tuple of domains. In Union("Mass", ...), the strings are magically
turned into domains.
 
> > As we don't know all the expert areas now in existence, nor do we know what
> > new derived dimension or unit we may need (especially in 30 years' time),
> > there is no way we can have such a universal toplevel hash table. We CAN
> > implement SI (all the default and acceptable dimensions and units) or even
> > more, but such a domain will need to be revised to allow newer dimensions
> > and units. The design proposed will allow this of course (any design in
> > fact), but I still subscribe to the older Axiom philosophy that we do not
> > modify existing libraries except for bugs, and extend existing libraries
> > through additional implementation. We should allow arbitrary UnitSystems
> > (as I also indicated in my last email, supermarket manager will need a
> > totally different, "non-scientific" unit system with dimensions like
> > "Coke", "DietCoke", etc.)
> 
> I agree.  I'm really curious to see if something like this ever gets used in
> such an application :-).

As long as they are doing only number crunching, they won't need it. But if they
have to solve for the optimal re-stock inventory strategy to minimize cost or
maximize profits, they may need symbolic computation.

> > ---------- Implementation Issues: Setting up Dimension and Unit domains

> How about we allow the mapping to go through when it IS unique, and return an
> error or ask a question if it isn't (something like provide a list of
> options, and ask the user to select one)?  (Maxima has the ability to ask
> questions of the user if it needs to - it makes some problems MUCH easier to
> solve.)  This is helpful and friendly to the user while still being fully
> correct.

To a certain extent, that can be done. We discussed that already. However, Axiom
does not seem to have the ability to ask questions of the user as far as I know.
The graphics package allows mouse selection and controlling using the mouse, so
I suppose that is a form of asking user input. But the Interpreter interface
does not even support the mouse. (Anyone wants to pick up this challenge?)
 
> > However, the problem still
> > is: given some unit in reduced basic dimensions such as
> > (mass-length/time^2).length, say kg.m^2/s^2, we do not know if the
> > dimension should be Energy (either Work or Kinetic Energy or Potential
> > Energy) or Moment. Vectorizing some of these dimensions may help: Work is a
> > force vector times a length vector, and so is moment, but the two length
> > vectors have different directions with respect to the direction of the
> > forces.
> 
> Woo boy.  That's going to be a challenge to report - direction of length
> vector as a factor in results.  Actually, that's an interesting question -
> two length vectors may have different components, but the same magnitude.
> Does the unit meter represent merely the magnitude, or the vector information
> as well?  

The Length units are scalar units. Magnitudes are not necessarily length but
they are also scalars. Vectors are given by its scalar components. Directions
are given by unit vectors, usually in terms of directional cosines.
There are formulae in standard coordinate geometry texts to compute projections
of a vector in any direction (by using the dot product).

> How do we represent vector information if we want to preserve it
> through the process of reducing dimensions?  The Work vs. Moment example
> would seem to argue that vector information and Dimensions can't really be
> separated, but I don't really know if I'm interperting that right.

That is right. Well, like it or not, physicists use lots of vectors and a unit
system should really support vectors. This can be done componentwise, but the
system has to be aware of how to obtain derived units when vector calculus is
applied! With symbolic computation, we can talk about vector functions,
differentiation, integration, etc and all these computations change the units
and dimensions.

The proposal allows a UnitSystem to be parametrized by a set S, and this set S
can be a set of vectors or vector functions. So when coding say SI(S), for
arbitrary S, one has to do cases when S has Vector, etc. Hehe, may be you can
get a ph d for this project!

> 
> > --------- User environment for Unit systems: Static vs Dynamic
> 
> > Also a user can save the history of all inputs,
> > including all 'set' commands (and also ')set' commands) and put them in
> > axiom.input or a 'myunitmod.input' and read it in anytime. There is no
> > need, in this dynamic design, to modify ANY compiled domain in the
> > UnitSystem category. When a user wants to have modification compiled into a
> > modSI domain, he will have to edit the SI.spad.pamphlet and change it into
> > modSI.spad.pamphlet and compile it. However, I don't see the necessity.
> > Your idea of
> > 'SaveUnitSystem(<newUnitSystemName>) is difficult (but not impossible) to
> > implement and involves automatically editing say SI.spad.pamphlet to
> > modSI.spad.pamphlet and automatically compiling it. It is trivial for a
> > user to read in an input file instead.
> 
> Actually, that was more my idea - have the saveUnitSystem command pick out all
> the most recent inputs that set the UnitSystem environment, and save them to
> a file.  The trouble is to pick out such commands, which was why I thought it
> might be simpler just to diff the "current" environment from the "default"
> environment and autogenerate the minimum set of commands to get from a to b.

Well, the setUnit and setUnitAll commands can be tracked by the UnitSystem
domain, and hence all it takes is to report the state-vector at the end of the
session, or just to save the state-vector and reload it in the next session. Not
a big deal.

> > --------------- Name space issues
> >
> > > (I'm still
> > > plotting to allow the user to gobble up all the unit names in the
> > > default namespace at their option, and that will DEFINITELY need
> > > interpreter work.
> >
> > As you know, I am strongly against "gobbling up all the unit names in the
> > default namespace' even if it is 'at their option'.  If you are seriously
> > thinking about student use, you know the average students will exercise
> > their options without knowing or understanding what they are doing. There
> > is no way to consistently reserve SOME unit names in namespace, and not
> > others. Any code to implement this will have to know the reserved names a
> > priori and that means ALL the abbreviations in SI units at a minimum.
> 
> Right.  Reserving some would be worse than none, because it would be
> inconsistent.
> 
> > You  would have created a nightmare in using the interpreter by requiring
> > users  to avoid any SI unit abbreviations as user variables. No computer
> > language  ever has that many reserved words. Note: Axiom function names
> > are NOT  reserved, but constructor (which may be category, domain or
> > package) names and their abbreviations are.
> 
> If we were talking about a normal computer language, I agree.  However, in
> normal scientific usage, proper definition and use of equations should NOT
> use SI abbreviations as variables.  Doing so creates far too much potential
> for misinterpreting said variables later on.  

That is true, but we are talking about computing. In normal scientific use, most
symbolic derivations or equations do not use units. The symbols do carry units
occasionally, but equations never include units. An equation is always an
equality for values, and homogeneous in dimension (which is not stated
explicitly). So the chance of seeing something like m m (for m meter) is small.

> I grant that your proposed
> system has a far better chance than any I have ever seen or heard of of
> making this workable, by being able to separate out m the variable and m the
> unit in the output even if they look the same to the human eye - e.g.:
> 
> (1)-> 3*setUnit("Length","m","m")
> 
>                                           3m m
>                                                                      [Length]

This works, if you give the right syntax:

-> (1)'    3*setUnit("Length","m",m)

                  3m [m]
          
> If this can actually function, then I am for it because it would be a
> virtually ideal solution, and it is more general in case other, non-physical
> unit cases need that generality.

> > There is perhaps one way to use variables (instead of strings) for
> > dimensions and units, but they will be local to the domain (using domain
> > namespace, rather than user namespace) and they will not be assigned any
> > value. The advantage over strings is that they can be used to perform
> > arithmetic operations of multiplication and division as symbols. Then
> > general conversion factors can be computed by setting up a small number of
> > conversion rules and by solving an equation.
> 
> I'm beginning to see how this might work - visually speaking though, it hinges
> on the robustness of Axiom's separating units and non-units in output.  I
> think Axiom might be able to do this in a way most other systems couldn't (at
> least not without a lot more work).

Yes, that is probably much harder than providing arithmetic on strings. Besides,
we only need to provide multiplication and division. But I think it is doable in
Axiom. These local variables are not really visible to the Interpreter user
directly. The user may still have to use setDimUnit, setUnit, etc. The
separation is via the Rep already and the output can turn them into strings. The
problem is they are still symbols and so still restricts the namespace of the
domain, but that is much better than user namespace because the author for the
domain can avoid any potential conflict. The danger is in future updates of the
code;  the person updating may not be careful enough to avoid the reserved names
(like adding some units that turn out to be one of the local variables). Strings
avoid the problem altogether.

 
> > ---------- Implementation Issue: Simplification of dimensions

> > Perhaps we can add a field to Rep that gives the reduced dimension as well?
> > or provide a function
> >
> >   reduce: Dimension->Dimension
> >
> > (which in any case, will be useful and necessary).
> 
> Yes, I think so.  Is the concept of reduced dimension defined anywhere?

I am not a historian. This can't be a new concept, but may or may not have been
formalized. May be the book "Theory of Dimensions" had it.
 
> > Whether any such references will help us develop the rules to simplify
> > dimensions, I don't know. From what we have discussed, it seems any rule
> > will need some expert knowledge (in the example I gave, the expert
> > knowledge is simply what pressure is). So I believe the best solution may
> > be to "leave it to the users", and let them create their own names and
> > simplification rules.
> 
> Sounds good. How about as good setups are created we merge them into Axiom?
> Perhaps Axiom will become the central repository for advanced unit
> interaction rules, as people build off of the (hopefully) sound foundation of
> Axiom?

That will be goal.
 
> Without doubt scientific units will be the most useful in the short term.
> Building scientific symbolic computing on top of Axiom is going to require,
> as near as I can tell, three things:
> 
> a)  the concepts of Dimensions and Units (underway)

Good.

> b)  Significant Digits, Uncertainty in Measurement, and Error propagation
> (hard, both in itself and also since potential errors due to the numerical
> calculations of the computer must also be considered in order to be rigorous)

This is a totally different domain, involving interval arithmetic, for example.
I don't know what error analysis packages or numerical packages have been
implemented in Axiom. While they are important, I suspect most people are so
used to very high precision computations they ignore to the accuracy of the raw
data.

> c)  Domains of significance.  I don't know what else to call this, but as an
> illustration, we know that Newton's laws of motion break down near the speed
> of light.  Science generally gets on with life by neglecting Einstein type
> effects at velocities which are low compared to c, since any possible
> contribution due to those effects is washed out and below any significant
> level of measurement possible.  So, let's say we input the fully general
> equations into Axiom for motion, velocity, etc. since we like generality.
> However, for sufficiently small velocities (or more correctly, sufficiently
> imprecise) measurements, we want to use Newton's equations, even
> symbolically.  They should (and do) simplify in the limit, and we want Axiom
> to be able to understand or even figure out such things on request, since
> such information is very useful to practical work.  Plus, it would be an
> awesome way to build intuition on when things matter.  The problem is, there
> would need to be a definition given for sufficiently imprecise.  Either
> deduced from supplied measurement uncertainties (and it should deduce them if
> it can since the human probably can't be relied on for this) or supplied in
> purely symbolic situations.  I have no idea how  to express this idea in
> Axiom, if it can even be done, but it would provide an absolutely incredible
> and powerful tool for using the right  equation given the data.
> 
> OK, enough pie in the sky talk :-)  

That what I think it is! I guess such generality will only be useful to those
who work in the area of transition between Newtonian and Quantum (don't even
know if that make sense). Maybe you are dreaming of the grand unification theory
and implementing that in Axiom?

> Night all, and thanks William as always
> for your patient, helpful and amazingly powerful ideas and thoughts.  I hope
> mine aren't being too tiresome - I think I'm finally beginning to see the
> light, although I'm afraid we might have a bit more than three set* commands
> when we get done.  (Derived Dimension simplification rules in SI will require
> a few more commands, based on my Maxima experience, and that didn't have
> anywhere near the flexibility this will have.)
 
You are welcome. Yes, there will be way more functions specified in the
UnitSystem category. We have discussed the may functions, but there will be
support functions, which are not too hard to implement and can be added quite
naturally.

I look forward to seeing this becoming a reality. It has been quite an
interesting discussion.

\start
Date: Tue, 06 Sep 2005 06:32:49 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] Huge Axiom Package

The latest Axiom download package is HUGE to be downloaded over a slow
dial-up connection. I downloaded it over several days just to realize
that much of the material I downloaded was already with me.  The
download system could have been even more flexible such as that of the
cygwin package. The person who is downloading should have the choice
of what he can download instead of compelling him to download
everything. For eg, he can downlaod only bin, or bin+doc(dvi or pdf or
ps or html as per his requirement). It would have been even better if
the users could upgrade the previous versions instead of downloading
it afresh (through a system more convinient than the CVS) By the way
don't ignore the people who have MikTex installed on there systems.

\start
Date: Tue, 06 Sep 2005 09:11:21 -0500
From: MathAction (Tim Daly)
To: MathAction
Subject: [AxiomDownload] 

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

    The April release moves Axiom from GCL-2.6.6 to GCL-2.6.7, 

       2) tar -zxf axiom-Sept2005-src.tgz

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

         2) tar -zxf axiom-Sept2005-Redhat9-bin.tgz

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

         2) tar -zxf axiom-Sept2005-Redhat7.3-bin.tgz

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

       This is a binary tree for a Fedora Core 4 system. Unpack this tree in a directory such as /home::

         1) cd /home
         2) tar -zxf axiom-Sept2005-FC4-bin.tgz
         3) cd axiom
         4) export AXIOM=`pwd`/mnt/linux
         5) export PATH=\$AXIOM/bin:\$PATH
         6) axiom

\start
Date: Tue, 6 Sep 2005 10:46:25 -0400
From: Bill Page
To: Peter Broadbery
Subject: RE: aldor for axiom

On September 2, 2005 10:49 AM Peter Broadbery wrote:
> 
> On Mon, 2005-08-29 at 22:11 -0400, Bill Page wrote:
> > > Also, I have javac 1.5.0_04. Can I assume you don't actually
> > > REQUIRE javac 1.5.0_03?
> > 
> > Yes. In fact I am not 100% sure that it is Sun's JDK 1.5.x that
> > is required but I have verified that it works. Peter never said
> > exactly what java compiler he is using.
> > 
> > It would be nice if one could use the GNU gcj compiler. But my
> > first attempt to do that failed so I assumed he was talking
> > about Sun's java.
> > 
> 
> I'm using java 1.4.2, and it should work with pretty much any
> java supporting 1.3 or later.  
> 

It occurs to me that it might be quite appropriate to use
Aldor itself to write the dependency generation program.
Can you see any impediment to my doing this?

\start
Date: Wed, 7 Sep 2005 01:06:02 +0700 (NOVST)
From: Andrey G. Grozin
To: Tim Daly
Subject: trying to add a new output format

Hello *,

I am trying to add various things to axiom which are useful for
the TeXmacs interface, but can be also useful for other purposes
(interfaces with other external programs, for example).

But I have a lot of questions (naturally). First, when I edit some
.boot.pamphlet file(s) in src/interp and say
make
this file is compiled, but AXIOMsys is not re-generated. Is this
due to the .PRECIOUS line in the Makefile? How do I re-generate
AXIOMsys after editing a file in src/interp? Simply deleting
AXIOMsys does not help.

Second, I tried to introduce a new output format today. To make
things simpler, I started from introducing LatexFormat, which is
nearly identical to the TexFormat, but which can be tweaked to
produce modern LaTeX2e rather than plain TeX. Here are the steps
I did:

1. cp tex.spad.pamphlet latex.spad.pamphlet
and edited it to what I want. It introduces a domain LatexFormat
and a package LatexFormat1.

2. in src/algebra/Makefile.pamphlet, I added ${OUT}/LATEX1.o to
LAYER4 (because TEX1.o is there) and ${OUT}/LATEX.o to LAYER14
(because TEX.o is there), and added the line
latex.spad.pamphlet (LATEX)
to the list of completed spad files at layer 14. I inserted
${OUTSRC}latex.spad into SPADFILES and ${DOC}/latex.spad.dvi
into DOCFILES.

3. in src/algebra/exposed.lsp.pamphlet, I inserted the lines
  (|LatexFormat| . LATEX)
  (|LatexFormat1| . LATEX1)

4. in src/doc/axiom.bib.pamphlet, I inserted a subsection about
latex.spad.

5. in src/interp/setvars.boot.pamphlet, I inserted a new section
about LaTeX format, by copying the TeX format stuff and editing.

6. I copied setvars.boot.pamphlet into a separate directory,
notangle setvars.boot.pamphlet > setvars.boot
started depsys and said
(boottran::boottocl "setvars.boot")
(bye)
Then I copied the generated int/interp/setvars.clisp into
setvars.boot.pamphlet instead of the lisp piece in
<<setvars.clisp>>

7. in src/interp/setvart.boot.pamphlet, I inserted the line
latex       create output in LaTeX style             Off:CONSOLE 
in the table near the beginning, the line
<<outputlatex>>
in the code chunk <<output>>, and the subsection latex
obtained from tex by copying and editing.

Has I missed anything?

After all that, I said
make
It failed:

--------------------------------------------------------------------------------
2 building warm.data
5 invoking make in /home/grozin/cas/axiom--main--1--patch-45/src/interp with parms:
SYS= gentoo
LSP= /home/grozin/cas/axiom--main--1--patch-45/lsp
PART= cprogs
SPAD= /home/grozin/cas/axiom--main--1--patch-45/mnt/gentoo
SRC= /home/grozin/cas/axiom--main--1--patch-45/src
INT= /home/grozin/cas/axiom--main--1--patch-45/int
MID= /home/grozin/cas/axiom--main--1--patch-45/int/interp
OUT= /home/grozin/cas/axiom--main--1--patch-45/obj/gentoo/interp
OBJ= /home/grozin/cas/axiom--main--1--patch-45/obj
MNT= /home/grozin/cas/axiom--main--1--patch-45/mnt
O=o LISP=lsp BYE=bye

...

Loading /home/grozin/cas/axiom--main--1--patch-45/obj/gentoo/interp/patches.o
start address -T 0x86df940 Finished loading /home/grozin/cas/axiom--main--1--patch-45/obj/gentoo/interp/patches.o

Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LOAD.
Broken at APPLY.  Type :H for Help.
BOOT>>make[3]: *** [/home/grozin/cas/axiom--main--1--patch-45/obj/gentoo/bin/interpsys] Error 255
make[3]: Leaving directory `/home/grozin/cas/axiom--main--1--patch-45/src/interp'
make[2]: *** [interpdir] Error 2
make[2]: Leaving directory `/home/grozin/cas/axiom--main--1--patch-45/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/home/grozin/cas/axiom--main--1--patch-45'
make: *** [all] Error 2
--------------------------------------------------------------------------------

My next action was
make clean
make
(to be sure that there's no incompatibility with some file
from the normal axiom build). The result is the same.

What can I do next?

In the course of doing all this, I found and corrected a number
of typos in src/algebra/Makefile.pamphlet, src/interp/setvars.boot.pamphlet
and src/interp/setvart.boot.pamphlet . It seems that the stuff about
OpenMath was produced by copying the TeX stuff (just like I'm doing now!),
and was not edited carefully enough. These changes should be incorporated
into the mainline axiom:

--------------------------------------------------------------------------------
diff --recursive -U4 axiom--main--1--patch-45/src/algebra/Makefile.pamphlet axiom/src/algebra/Makefile.pamphlet
--- axiom--main--1--patch-45/src/algebra/Makefile.pamphlet	2005-09-05 16:34:27.000000000 +0200
+++ axiom/src/algebra/Makefile.pamphlet	2005-09-06 21:49:42.000000000 +0200
@@ -1131,18 +1132,18 @@
 \end{verbatim}
 
 \section{The Environment}
 \subsection{The working directories}
-We define 5 directories for this build. The{\bf IN} directory
+We define 5 directories for this build. The {\bf IN} directory
 contains the pamphlet files for the algebra. These are expanded
-into the{\bf MID} directory as either .spad or .as files. The
+into the {\bf MID} directory as either .spad or .as files. The
 .spad files are compiled by the native spad internal compiler.
 The .as files are compiled using the Aldor compiler. The output
 of the compilation has two purposes. Part of the information is
 used to build various database files (daase files). The other
 part is executable code which is placed in the {\bf OUT}
 directory. When invoked as ``make document'' we construct
-the .dvi files in the{\bf DOC} directory.
+the .dvi files in the {\bf DOC} directory.
 
 The [[OUTSRC=${MNT}/${SYS}/src/algebra]] subdirectory contains the 
 algebra source files extracted from the pamphlet files. These sources 
 allow the end user to change the algebra if needed.

diff --recursive -U4 axiom--main--1--patch-45/src/interp/setvars.boot.pamphlet axiom/src/interp/setvars.boot.pamphlet
--- axiom--main--1--patch-45/src/interp/setvars.boot.pamphlet	2005-09-05 16:29:47.000000000 +0200
+++ axiom/src/interp/setvars.boot.pamphlet	2005-09-06 22:42:20.000000000 +0200
@@ -1388,29 +1388,29 @@
 ------------------ The openmath Option ------------------------
 
  Description: create output in OpenMath style
 
- )set output tex is used to tell AXIOM to turn TeX-style output
+ )set output openmath is used to tell AXIOM to turn OpenMath-style output
 printing on and off, and where to place the output.  By default,
 the destination for the output is the screen but printing is 
 turned off.
 
-Syntax:   )set output tex <arg>
+Syntax:   )set output openmath <arg>
     where arg can be one of
-  on          turn TeX printing on
-  off         turn TeX printing off (default state)
-  console     send TeX output to screen (default state)
-  fp<.fe>     send TeX output to file with file prefix fp
+  on          turn OpenMath printing on
+  off         turn OpenMath printing off (default state)
+  console     send OpenMath output to screen (default state)
+  fp<.fe>     send OpenMath output to file with file prefix fp
               and file extension .fe. If not given, 
               .fe defaults to .som.
 
 If you wish to send the output to a file, you must issue 
 this command twice: once with on and once with the file name. 
-For example, to send TeX output to the file polymer.som, 
+For example, to send OpenMth output to the file polymer.som, 
 issue the two commands
 
-  )set output tex on
-  )set output tex polymer
+  )set output openmath on
+  )set output openmath polymer
 
 The output is placed in the directory from which you invoked 
 AXIOM or the one you set with the )cd system command.
 The current setting is:  Off:CONSOLE 

diff --recursive -U4 axiom--main--1--patch-45/src/interp/setvart.boot.pamphlet axiom/src/interp/setvart.boot.pamphlet
--- axiom--main--1--patch-45/src/interp/setvart.boot.pamphlet	2005-09-05 16:35:33.000000000 +0200
+++ axiom/src/interp/setvart.boot.pamphlet	2005-09-06 22:35:07.000000000 +0200
@@ -1906,25 +1908,25 @@
 ----------------------- The openmath Option ------------------------
 
  Description: create output in OpenMath style
 
- )set output tex is used to tell AXIOM to turn OpenMath output
+ )set output openmath is used to tell AXIOM to turn OpenMath output
 printing on and off, and where to place the output.  By default,
 the destination for the output is the screen but printing is 
 turned off.
 
-Syntax:   )set output tex <arg>
+Syntax:   )set output openmath <arg>
     where arg can be one of
   on          turn OpenMath printing on
   off         turn OpenMath printing off (default state)
   console     send OpenMath output to screen (default state)
   fp<.fe>     send OpenMath output to file with file prefix fp
               and file extension .fe. If not given, 
-              .fe defaults to .sopen.
+              .fe defaults to .som.
 
 If you wish to send the output to a file, you must issue 
 this command twice: once with on and once with the file name. 
-For example, to send OpenMath output to the file polymer.sopen, 
+For example, to send OpenMath output to the file polymer.som, 
 issue the two commands
 
   )set output openmath on
   )set output openmath polymer

\start
Date: Tue, 6 Sep 2005 14:22:12 -0400
From: Tim Daly
To: Andrey G. Grozin
Subject: Re: trying to add a new output format

> But I have a lot of questions (naturally). First, when I edit some
> .boot.pamphlet file(s) in src/interp and say
> make
> this file is compiled, but AXIOMsys is not re-generated. Is this
> due to the .PRECIOUS line in the Makefile? How do I re-generate
> AXIOMsys after editing a file in src/interp? Simply deleting
> AXIOMsys does not help.

Actually the files in the src/interp directory go into building
obj/bin/interpsys, not AXIOMsys. AXIOMsys is created as a final
copy operation and is not a precondition on any make stanzas 
(although I guess it should be. I'll make a note about it).


> steps you took...
> ....[snip].....
> Have I missed anything? 

Hard to say, really. So much depends on so much.

In your console log it is not clear what failed. Part of the startup
process is to initialize the various )set commands from setvart.boot
If one of these is wrong the process could blow up.

At best I can suggest that you do a diff -r --brief between the
original axiom--main--1--patch-45 sources and your sources so I 
can see what actually changed. That way I can try to reproduce it
here.

re: typos.

I'll apply the changes you sent. 

\start
Date: Tue, 06 Sep 2005 16:44:14 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] 

    This release moves Axiom from GCL-2.6.6 to GCL-2.6.7, 

\start
Date: Tue, 6 Sep 2005 17:46:03 -0400
From: Tim Daly
To: MathAction
Subject: Re: [AxiomDownload]

Bill,

Good catch. You think I'd have learned to read by now.

I've pushed the sept release out to savannah and sourceforge
including sources and binaries for Redhat7.3, Redhat9, and FC4.

\start
Date: Tue, 06 Sep 2005 16:49:04 -0500
From: MathAction (root)
To: MathAction
Subject: [AxiomDownload]

Bill,

Good catch. You think I'd have learned to read by now.

I've pushed the sept release out to savannah and sourceforge
including sources and binaries for Redhat7.3, Redhat9, and FC4.

\start
Date: Tue, 6 Sep 2005 23:22:15 -0400
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

On Tuesday 06 September 2005 07:35 am, William Sit wrote:
> I have snipped without indication, a lot of the paragraphs that we agreed
> on.

No problem - I'm guilty of that too.

> s does not have to be a symbol, it may be an expression involving several
> symbols even though that maybe a bit "dangerous" and unusual. This allows
> the user who knows what he is doing to use what is known as an aggregate
> variable. Aggregate variables are used to simplify the number of variables
> in an equation and often very useful to understanding the interdependencies
> of variables, reducing the equation into a dimensionless form, or to a
> linear relationship between two aggregate variables. However, not all
> aggregate variables are dimensionless. The ideal gas law is such an
> (simple) example: PV/T = constant; so PV/T is an aggregate variable. The
> ideal gas law can also be put into the form PV = cT, where c is the
> constant. Using PV as an aggregate variable, it is proportional to T (and
> how coincidental, of reduced dimension Force*Length again and unit for
> example, liter-atm, and the constant c is not dimensionless.)

OK.  That sounds very interesting and may have possibilities for dimensional 
analysis tools like finding dimensionless constants.  (I need to re-read 
Barton Willis's docs for his Maxima package to remember what features he 
added.

> > So let's say I define some examples (sorry, I'm not up enough on Axiom
> > syntax yet to use it for this) would this be roughly how things would
> > work?:
>
> Your example below is basically the correct scenario. The syntax and output
> need some changes, given next. I added sequence numbers.
>
> > a::Length
> > b::Length
> > c::Force
>
> Since Length, Force, etc are not domains in my proposed setup, you cannot
> use the coercion symbol ::. Assuming you started with SI, you would have to
> replace the above three lines by:
>
> ->(1) ua:=setDim("Length",a)
>
>        a [m]
>
> Note that the unit is output using a pair of brackets, to avoid confusing
> it with a variable m, perhaps. Also, the type of ua is now SIUnitSystem(S),
> if the type of a is S.

I'm afraid I don't quite understand this part.  Why is ua needed?  I wanted to 
assign a dimension of Length to a, such that typing in a results in the 
following:

->(1) setDim("Length",a)

           a [m]

->(2)  a

           a [m]

Is this not possible, or did I miss another subtle design issue? (probable)

> ->(2) ub:= setDim("Length", b)
>
>        b [m]
>
> ->(3) uc:= setDim("Force",c)
>
>        c [kg-m/s^2]  or [N]
>
> > (4) setDimUnit("Length","cm", a)
>
> This would have the following output:
>
>       a [cm]
>
> Note that no conversion factor is used, since the expression a is entered
> afresh. The two identifiers a and ua are of different types. This suggests
> that we should add a new signature:
>
>      setDimUnit:(Dimension, Unit, %) -> %
>
> so that
>
> -> (4)' ua:=setDimUnit("Length","cm",ua)
>
>         a m2cm [cm]

Makes sense, except again I don't follow the need for ua.  Intuitively I want 
to be working with a, and ua is unnecessary - what purpose is it serving?  I 
can see setDimUnit refusing to work on an actual number (e.g. setDimUnit 
("Length,"cm",4) ) without being assigned to a variable, but surely this 
restriction shouldn't apply in general?  

> > (5) setUnit("Length","m")
>
> This would set all declared expressions of dimension Length to use [m] as
> unit. Whether this is done retroactively or not is a design issue. We can
> provide both options with an added parameter.

I think your arguments for it being retroactive are compelling.

> > (6) setUnit("Force"", "N")
>
> Same, all expression of dimension Force use N as unit.
>
> > -> (7) a
> >                      a  cm                [Length]
>
> No: The use of 'a' will only return 'a', not 'a' with a unit. To get the
> unit, you have to use:
>
> -> (7)' ua

Same question as to why ua is needed.  Also, are you quoting ua, i.e.  ' ua?  
Or is that my mail client?

[snip]

> > -> (11) a
> >                      a cm2km  km        [Length]  (or would this stay as
> > cm?)
>
> -> (11)' ua
>
> The expression a was in [cm] or [m] depending on design (see (7)). Assuming
> you meant ua instead of 'a' in (11), your output assumes that no
> retroactive update in (5) but retroactive update in (10). There are four
> possibilities already.

Sorry if I got sloppy.  retroactive makes sense to me.

[snip]

> > > ---------- Implementation issues: Updating variables and their units
>
> Trouble is, neither the word "change" nor "set" provides a definite
> meaning. So I think it is better that setUnit or setUnitAll will change all
> instances retroactively.  As I already warned, just like when the unit of a
> single expression is changed (the setDimUnit, either version), the other
> alternative, changing only future instances will give rise to mixed units
> and a subsequent computation involving mixed units must be brought to a
> common unit system. What would be the unit of the result? I suppose the
> only meaningful unit is to the system's unit in the state vector. Thus, by
> making changes retroactively at the time a setUnit or setUnitAll is run, we
> bring the system back to uniformity earlier and hence subsequent
> computations are more efficient. Lazy evaluation does not pay if there are
> lots of subsequent computations, requiring conversion for each quantity
> involved, and with no place to hold the changes.

Agreed.

> I see, you want to set the units for multiple dimensions in one statement.
> We can do that easily by allowing:
>
>     setUnits: (List Dimension, List Unit) -> Null (or state-vector)

Sounds good.

> > I agree - I would like to have a "strict" mode available which compels
> > the user to do this.  I fear making it the ONLY alternative will lose us
> > users though.
>
> By "us" you meant "USA"? I always remind my students the probe crashed on
> Mars was due to mixing up (or unaware of the mix up) units. I don't think
> user would mind including the dimension when setting units. It does help
> prevent typos from passing through.

Well, my guess is they will mind, but I agree they should do it.  I just hope 
the decision to enforce this rule doesn't make people decide to use Maple or 
some other package (on such small things do decisions hang, sometimes :-/). 
So be it - we'll go for enforced dimension awareness.

> > Yes, I think we might want to do something like that - it would allow (or
> > would it?) the possibility of a UnitConversion category with domains for
> > PhysicalUnits, ComputerUnits, EconomicUnits, etc.
>
> That is the idea. However, there is some technical difficulty that I do not
> yet know how to solve, but I think it is doable:
>
>     UnitConversion(dim:List String, unit:List String):Category == ...
>
> Trick is to convert dim and unit into arguments for the constructor Union
> so we can form
>
>     Dimension:=Union(dim)  -- right now, syntax error
>     Unit:=Union(unit)
>
> There must be a function in Axiom to do that. I just don't know. Here Union
> is expecting a tuple of domains. In Union("Mass", ...), the strings are
> magically turned into domains.

Any Axiom gurus that can help us on the above point?

> As long as they are doing only number crunching, they won't need it. But if
> they have to solve for the optimal re-stock inventory strategy to minimize
> cost or maximize profits, they may need symbolic computation.

Sounds like something Walmart might be interested in.

> > > ---------- Implementation Issues: Setting up Dimension and Unit domains
> >
> > How about we allow the mapping to go through when it IS unique, and
> > return an error or ask a question if it isn't (something like provide a
> > list of options, and ask the user to select one)?  (Maxima has the
> > ability to ask questions of the user if it needs to - it makes some
> > problems MUCH easier to solve.)  This is helpful and friendly to the user
> > while still being fully correct.
>
> To a certain extent, that can be done. We discussed that already. However,
> Axiom does not seem to have the ability to ask questions of the user as far
> as I know. The graphics package allows mouse selection and controlling
> using the mouse, so I suppose that is a form of asking user input. But the
> Interpreter interface does not even support the mouse. (Anyone wants to
> pick up this challenge?)

Hmm.  I'll add my voice asking for this option/feature - it made Maxima many 
times easier to use on a variety of problems (in Maxima, for example, the 
integration routines would ask the user if things were positive, negative, or 
zero in order to limit the amount of work and provide a unique answer.  I  
wish I could remember the example that I wound up using in Solid State 
Physics once.)

> > > However, the problem still
> > > is: given some unit in reduced basic dimensions such as
> > > (mass-length/time^2).length, say kg.m^2/s^2, we do not know if the
> > > dimension should be Energy (either Work or Kinetic Energy or Potential
> > > Energy) or Moment. Vectorizing some of these dimensions may help: Work
> > > is a force vector times a length vector, and so is moment, but the two
> > > length vectors have different directions with respect to the direction
> > > of the forces.
> >
> > Woo boy.  That's going to be a challenge to report - direction of length
> > vector as a factor in results.  Actually, that's an interesting question
> > - two length vectors may have different components, but the same
> > magnitude. Does the unit meter represent merely the magnitude, or the
> > vector information as well?
>
> The Length units are scalar units. Magnitudes are not necessarily length
> but they are also scalars. Vectors are given by its scalar components.
> Directions are given by unit vectors, usually in terms of directional
> cosines. There are formulae in standard coordinate geometry texts to
> compute projections of a vector in any direction (by using the dot
> product).

OK.  So in theory, if we vectorize the Units/Derived Dimensions, we won't need 
the idea of Reduced Dimensions?

> > How do we represent vector information if we want to preserve it
> > through the process of reducing dimensions?  The Work vs. Moment example
> > would seem to argue that vector information and Dimensions can't really
> > be separated, but I don't really know if I'm interperting that right.
>
> That is right. Well, like it or not, physicists use lots of vectors and a
> unit system should really support vectors. This can be done componentwise,
> but the system has to be aware of how to obtain derived units when vector
> calculus is applied! With symbolic computation, we can talk about vector
> functions, differentiation, integration, etc and all these computations
> change the units and dimensions.

Ho boy.  This is going to be a loooong pamphlet file ;-).

> The proposal allows a UnitSystem to be parametrized by a set S, and this
> set S can be a set of vectors or vector functions. So when coding say
> SI(S), for arbitrary S, one has to do cases when S has Vector, etc. Hehe,
> may be you can get a ph d for this project!

Heh - that'd be cool, but for that I'd have to be enrolled somewhere and 
actually be a student again, and I doubt I'd ever get this across as a thesis 
topic :-).  Dunno where I'd get funding from :-/.  Sure would be interesting 
(and fun!) though.

> > > --------- User environment for Unit systems: Static vs Dynamic
> > Actually, that was more my idea - have the saveUnitSystem command pick
> > out all the most recent inputs that set the UnitSystem environment, and
> > save them to a file.  The trouble is to pick out such commands, which was
> > why I thought it might be simpler just to diff the "current" environment
> > from the "default" environment and autogenerate the minimum set of
> > commands to get from a to b.
>
> Well, the setUnit and setUnitAll commands can be tracked by the UnitSystem
> domain, and hence all it takes is to report the state-vector at the end of
> the session, or just to save the state-vector and reload it in the next
> session. Not a big deal.

Sounds good.

> > > --------------- Name space issues
> > >
> > > You  would have created a nightmare in using the interpreter by
> > > requiring users  to avoid any SI unit abbreviations as user variables.
> > > No computer language  ever has that many reserved words. Note: Axiom
> > > function names are NOT  reserved, but constructor (which may be
> > > category, domain or package) names and their abbreviations are.
> >
> > If we were talking about a normal computer language, I agree.  However,
> > in normal scientific usage, proper definition and use of equations should
> > NOT use SI abbreviations as variables.  Doing so creates far too much
> > potential for misinterpreting said variables later on.
>
> That is true, but we are talking about computing. In normal scientific use,
> most symbolic derivations or equations do not use units. The symbols do
> carry units occasionally, but equations never include units. An equation is
> always an equality for values, and homogeneous in dimension (which is not
> stated explicitly). So the chance of seeing something like m m (for m
> meter) is small.

I suppose - but I'm not sure what the use of this will be - scientific 
computing, or more traditional "working on problems in a notebook" style 
stuff.  I'd like to be able to do the latter as well as the former, and in 
the latter the convention would be to avoid using SI units for variables.  Oh 
well, I think it's pretty much covered.

> > I grant that your proposed
> > system has a far better chance than any I have ever seen or heard of of
> > making this workable, by being able to separate out m the variable and m
> > the unit in the output even if they look the same to the human eye -
> > e.g.:
> >
> > (1)-> 3*setUnit("Length","m","m")
> >
> >                                           3m m
> >                                                                     
> > [Length]
>
> This works, if you give the right syntax:
>
> -> (1)'    3*setUnit("Length","m",m)
>
>                   3m [m]

OK.

[snip]

> Yes, that is probably much harder than providing arithmetic on strings.
> Besides, we only need to provide multiplication and division. But I think
> it is doable in Axiom. These local variables are not really visible to the
> Interpreter user directly. The user may still have to use setDimUnit,
> setUnit, etc. The separation is via the Rep already and the output can turn
> them into strings. The problem is they are still symbols and so still
> restricts the namespace of the domain, but that is much better than user
> namespace because the author for the domain can avoid any potential
> conflict. The danger is in future updates of the code;  the person updating
> may not be careful enough to avoid the reserved names (like adding some
> units that turn out to be one of the local variables). Strings avoid the
> problem altogether.

OK.  Any introductory tutorial on units in Axiom will need to make it clear 
that units are not normal variables, and explain how things work, but I think 
it should be doable.

> > > ---------- Implementation Issue: Simplification of dimensions
> > >
> > > Perhaps we can add a field to Rep that gives the reduced dimension as
> > > well? or provide a function
> > >
> > >   reduce: Dimension->Dimension
> > >
> > > (which in any case, will be useful and necessary).
> >
> > Yes, I think so.  Is the concept of reduced dimension defined anywhere?
>
> I am not a historian. This can't be a new concept, but may or may not have
> been formalized. May be the book "Theory of Dimensions" had it.

Hmm.   OK, I'll have to do some digging.

> > Without doubt scientific units will be the most useful in the short term.
> > Building scientific symbolic computing on top of Axiom is going to
> > require, as near as I can tell, three things:
> >
> > a)  the concepts of Dimensions and Units (underway)
>
> Good.

Well, underway in design phase anyway - I'm still getting a handle on your 
design ideas, it seems :-/.  Hopefully my skull will prove to be of finite 
density, and ideas will filter in eventually.

> > b)  Significant Digits, Uncertainty in Measurement, and Error propagation
> > (hard, both in itself and also since potential errors due to the
> > numerical calculations of the computer must also be considered in order
> > to be rigorous)
>
> This is a totally different domain, involving interval arithmetic, for
> example. I don't know what error analysis packages or numerical packages
> have been implemented in Axiom. While they are important, I suspect most
> people are so used to very high precision computations they ignore to the
> accuracy of the raw data.

Not in proper scientific measurement and data analysis.  It is a totally 
different domain from units, but it is one of the foundations of experimental 
science and will be needed for any intelligent handling of results from 
experiments.  In introductory physics labs (at least the ones I helped teach) 
the two first concepts people are introduced to are units and errors (and I 
might add, they are the most common areas where points are lost in subsequent 
labs :-/).  Any definition of physical constants (which have to be measured, 
after all) will require incorporating information about the accuracy of the 
measurement of the constant, to preserve the full meaning and utility of the 
definition.

Error Analysis is something I have been told cannot be automated, and I accept 
that to a point, but only to a point.  Fundamentally, if it is a 
deterministic and reproducible process to find the real uncertainty on a 
calculation, given enough information about the system in question it has to 
be something that can be reduced to a set of routines.  It might mean that 
the user will need to supply more information about the system to the 
computer than they usually think about explicitly, but it's like being forced 
to define dimensions for all units - if the user doesn't know it, they don't 
know enough to be sure of using it properly, and correct application can (and 
often is, I suspect) a matter of not happening to violate assumptions being 
made unknowingly.

Since this is separate from Units it can come later, but I regard it as 
fundamental for establishing a truly robust basis for scientific computation 
in Axiom.  Indeed, in some sense Axiom might ultimately provide a bridge 
between pure mathematics and the physical sciences, making explicit the 
mathematical tools and assumptions used to "get the job done" in the 
mathematics of physics, chemistry, etc.  

> > c)  Domains of significance.  

 [snip] 

> > OK, enough pie in the sky talk :-)
>
> That what I think it is! I guess such generality will only be useful to
> those who work in the area of transition between Newtonian and Quantum
> (don't even know if that make sense). Maybe you are dreaming of the grand
> unification theory and implementing that in Axiom?

Not a bad idea, actually :-).  But, for instance, what IS the definition of 
the "transition region" between Newtonian and Einsteinian behavior in 
descriptions of velocity?  How do you know when you should be using one and 
not the other?  For some cases it is easy, but in the intermediate range it 
is not so simple.  There are borderline cases where uncertainty in 
measurement and relativistic effects are the same order of magnitude, 
although admittedly offhand I don't know how many experimental systems are in 
that range.  These are the types of questions I would sometimes ask myself in 
Physics classes - I would like to have a system that kept track of such 
issues automatically for me when I was doing "real work."  Not that I do much 
of that in physics these days, of course...

I would like to ultimately use a proper Units, Uncertainty, and Error Analysis 
system in Axiom to begin building scientific mathematics on top of it.  Maybe 
it wouldn't be very useful, I don't know.  But, for example, Feyncalc in 
Mathematica is widely used.  I can't help thinking that implementing it in 
Axiom, on top of a Units and Error system which would allow for things like 
plugging in the latest experimental particle accelerator results directly 
into theoretical HEP equations to see if things make sense and are 
significant would be a very exciting and useful tool.  Maybe not though - 
it's been a long time since I was in physics in any significant way.

> > Night all, and thanks William as always
> > for your patient, helpful and amazingly powerful ideas and thoughts.  I
> > hope mine aren't being too tiresome - I think I'm finally beginning to
> > see the light, although I'm afraid we might have a bit more than three
> > set* commands when we get done.  (Derived Dimension simplification rules
> > in SI will require a few more commands, based on my Maxima experience,
> > and that didn't have anywhere near the flexibility this will have.)
>
> You are welcome. Yes, there will be way more functions specified in the
> UnitSystem category. We have discussed the may functions, but there will be
> support functions, which are not too hard to implement and can be added
> quite naturally.

True.

> I look forward to seeing this becoming a reality. It has been quite an
> interesting discussion.

I'll try and begin structuring the emerging design into some kind of pamphlet 
file, although filling in the code will be a project in and of itself :-/.  
Oh well.  I'll see if some good can come out of all this by remembering all 
of my beginner questions and try to write the pamphlet in a way that 
addresses the reasons for doing things this way and not another, and defining 
concepts I had a hard time with.  If you're interested William I can send you 
a draft before dumping it on the list/wiki, since it is close to certain my 
first attempt will need a lot of tweaking, polishing, and rewriting.

\start
Date: Wed, 07 Sep 2005 02:15:41 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

C Y wrote:
On Tuesday 06 September 2005 07:35 am, William Sit wrote:
> > ->(1) ua:=setDim("Length",a)
> >
> >        a [m]
> >
> > Note that the unit is output using a pair of brackets, to avoid confusing
> > it with a variable m, perhaps. Also, the type of ua is now SIUnitSystem(S),
> > if the type of a is S.
> 
> I'm afraid I don't quite understand this part.  Why is ua needed?  I wanted to
> assign a dimension of Length to a, such that typing in a results in the
> following:
> 
> ->(1) setDim("Length",a)
> 
>            a [m]
> 
> ->(2)  a
> 
>            a [m]
> 
> Is this not possible, or did I miss another subtle design issue? (probable)

Axiom is a strongly typed language, which means that if you change the
representation of something, it will belong to a different type (or domain). The
two are distinct objects, even if in some sense, they are mathematically the
same. You cannot substitute one for the other without some sort of coercion, if
that is possible at all.

Thus SIUnitSystem(S) is not the same as S, because objects in S has no units
attached (purely mathematical objects, usually). Attaching a unit to an element
s in S immediately takes the result out of the domain S, into the new domain
SIUnitSystem(S). Sure, we can retract the result back to S, but then it will
lose its unit! So if you look at the signature of setDim:

     setDim: (Dimension, S) -> %

The % is SIUnitSystem(S) in our example, in general, it is any domain in
UnitSystem(S) category. Say if s is just a symbol, then the result of
setDim("Length",s) would be an object with Rep

    Record(value = s, dim="Length", unit="m", etc)

whereas the Rep of s in Symbol is simply s itself (probably just a string "s" as
name, or even some hash code). The display s [m] is the display for this new
object. If you do not assign the result to a new variable, say sWithUnit, then
this object is "lost" immediately (although Axiom has a way to recall results in
a session). So one has to assign it to use the new object again. The statment
setDim("Length",s) does not change s at all. It does not add a unit to s. It
creates a new object whose outputform is "s [m]". In fact, you can even assign s
to two different units in the same session, if s happens to just provide the
value for two quantities with different dimensions. So s as an element of S is
dimensionless, and only gain dimensionality via the setDim command. This is not
that uncommon in the real world. We had the example even with the mathematical
constant %pi, with two dimensions in two equations.

> I
> can see setDimUnit refusing to work on an actual number (e.g. setDimUnit
> ("Length,"cm",4) ) without being assigned to a variable, but surely this
> restriction shouldn't apply in general?

This has nothing to do with whether s is a number or a symbolic expression. The
"ua" is required because of types. Unfortunately, while you can retract "ua"
back to "a" because the value of "ua" is "a", you cannot coerce "a" into "ua".
(The quotes are just to separate it from the text, not to be meant as string
deliminators).

> 
> I think your arguments for it being retroactive are compelling.

So we agree on another design issue. Making progress.

> > -> (7)' ua
> 
> Same question as to why ua is needed.  Also, are you quoting ua, i.e.  ' ua?
> Or is that my mail client?

The single quote was really a prime; I was simply labeling the command as (7)';
may be I should have used (7').  A quote would have no space between the quote
and the symbol.

> > I see, you want to set the units for multiple dimensions in one statement.
> > We can do that easily by allowing:
> >
> >     setUnits: (List Dimension, List Unit) -> Null (or state-vector)
> 
> Sounds good.

In Mathematica, one can set the attribute of a function to be Listable. In
Axiom, one has to explicitly create a new function, but one can use the same
name.

> So be it - we'll go for enforced dimension awareness.

Good, we have fewer and fewer differences.

> > > Yes, I think we might want to do something like that - it would allow (or
> > > would it?) the possibility of a UnitConversion category with domains for
> > > PhysicalUnits, ComputerUnits, EconomicUnits, etc.
> >
> > That is the idea. However, there is some technical difficulty that I do not
> > yet know how to solve, but I think it is doable:
> >
> >     UnitConversion(dim:List String, unit:List String):Category == ...
> >
> > Trick is to convert dim and unit into arguments for the constructor Union
> > so we can form
> >
> >     Dimension:=Union(dim)  -- right now, syntax error
> >     Unit:=Union(unit)
> >
> > There must be a function in Axiom to do that. I just don't know. Here Union
> > is expecting a tuple of domains. In Union("Mass", ...), the strings are
> > magically turned into domains.
> 
> Any Axiom gurus that can help us on the above point?

I left the above in, just hoping someone will know how to do this. It is really
a very simple thing. The information (strings for the dimensions) is in a list.
Why can't we feed this to Union without the list wrapper? Axiom allows commands
in Lisp, and so someone who knows Lisp (Tim, Bill, Camm) should be able to
easily write a line to do that. In Mathematica, one can replace the "Head",
which is "List" for a list, by another function using "Apply", such as
Apply[Plus, {1,2,3}] would produce 1+2+3=6. Surely Axiom can do that too -- but
note Union is not a traditional function, but a domain constructor expecting
domains as arguments.

> > > > ---------- Implementation Issues: Setting up Dimension and Unit domains

> > Interpreter interface does not even support the mouse. (Anyone wants to
> > pick up this challenge?)
> 
> Hmm.  I'll add my voice asking for this option/feature - it made Maxima many
> times easier to use on a variety of problems (in Maxima, for example, the
> integration routines would ask the user if things were positive, negative, or
> zero in order to limit the amount of work and provide a unique answer.  I
> wish I could remember the example that I wound up using in Solid State
> Physics once.)

I think Axiom's design philosophy (one of these) is to have as few (none?)
interaction with the user as possible so that functions can be fed into other
functions for automatic execution. With functions requiring interaction, you
can't do that. Graphics is a big exception, but any graphics done by interactive
manipulation can be done in batch mode as well.
 
> OK.  So in theory, if we vectorize the Units/Derived Dimensions, we won't need
> the idea of Reduced Dimensions?

I don't think so. The newly discovered example that PV (Pressure times volume)
also has reduced dimension of energy shows that the problem occurs for scalar
quantities already. But the idea to handle vectors with dimension is still one
worth investigating.

> > > How do we represent vector information if we want to preserve it
> > > through the process of reducing dimensions?  The Work vs. Moment example
> > > would seem to argue that vector information and Dimensions can't really
> > > be separated, but I don't really know if I'm interperting that right.
> >
> > That is right. Well, like it or not, physicists use lots of vectors and a
> > unit system should really support vectors. This can be done componentwise,
> > but the system has to be aware of how to obtain derived units when vector
> > calculus is applied! With symbolic computation, we can talk about vector
> > functions, differentiation, integration, etc and all these computations
> > change the units and dimensions.
> 
> Ho boy.  This is going to be a loooong pamphlet file ;-).

Don't forget the dot product, cross product, gradient, curl !

Looks like the discussions will continue. Tim has the idea of a pamphlet book,
so don't worry about the length.
 
> > The proposal allows a UnitSystem to be parametrized by a set S, and this
> > set S can be a set of vectors or vector functions. So when coding say
> > SI(S), for arbitrary S, one has to do cases when S has Vector, etc. Hehe,
> > may be you can get a ph d for this project!
> 
> Heh - that'd be cool, but for that I'd have to be enrolled somewhere and
> actually be a student again, and I doubt I'd ever get this across as a thesis
> topic :-).  Dunno where I'd get funding from :-/.  Sure would be interesting
> (and fun!) though.

Funding is a real problem, and you're probably right, who would think unit
system is doctoral material? After all, it's just arithmetic!
 
> 
> > > > --------------- Name space issues

> > Yes, that is probably much harder than providing arithmetic on strings.
> > Besides, we only need to provide multiplication and division. But I think
> > it is doable in Axiom. These local variables are not really visible to the
> > Interpreter user directly. The user may still have to use setDimUnit,
> > setUnit, etc. The separation is via the Rep already and the output can turn
> > them into strings. The problem is they are still symbols and so still
> > restricts the namespace of the domain, but that is much better than user
> > namespace because the author for the domain can avoid any potential
> > conflict. The danger is in future updates of the code;  the person updating
> > may not be careful enough to avoid the reserved names (like adding some
> > units that turn out to be one of the local variables). Strings avoid the
> > problem altogether.
> 
> OK.  Any introductory tutorial on units in Axiom will need to make it clear
> that units are not normal variables, and explain how things work, but I think
> it should be doable.

Which do you mean? Using local (domain) variables, or using strings?

> > > > ---------- Implementation Issue: Simplification of dimensions
[snipped]
 
> > > b)  Significant Digits, Uncertainty in Measurement, and Error propagation
> > > (hard, both in itself and also since potential errors due to the
> > > numerical calculations of the computer must also be considered in order
> > > to be rigorous)

[snipped]

I agree totally with your view that scientist should know about uncertaintly in
measurement and be able to do error analysis of any computation they do . But
that is for "scientists" (in the sense of physcial sciences). A lot of
measurement are not of that nature, such as statistical measurements, or
processes that involve a lot of randomness such as economics, or weather, It
would be difficult to carry out every computation with an error range.
THe problem is not the computational error analysis, which can be automated
using techniques in automatic differentiation perhaps (applying chain rule to
propagate the error computations as differentials). The problem is in the
determining the accuracies of the input measurements.
 
> I'll try and begin structuring the emerging design into some kind of pamphlet
> file, although filling in the code will be a project in and of itself :-/.
> Oh well.  I'll see if some good can come out of all this by remembering all
> of my beginner questions and try to write the pamphlet in a way that
> addresses the reasons for doing things this way and not another, and defining
> concepts I had a hard time with.  If you're interested William I can send you
> a draft before dumping it on the list/wiki, since it is close to certain my
> first attempt will need a lot of tweaking, polishing, and rewriting.
> 
> Cheers,
> CY

No problem and I'll be glad to help out. In any case, if it is on wiki, it will
get modifiable by readers too!

\start
Date: Wed, 07 Sep 2005 07:08:00 +0100
From: Peter Broadbery
To: Bill Page
Subject: RE: aldor for axiom

On Tue, 2005-09-06 at 10:46 -0400, Bill Page wrote:
> On September 2, 2005 10:49 AM Peter Broadbery wrote:
> > 

> > 
> > I'm using java 1.4.2, and it should work with pretty much any
> > java supporting 1.3 or later.  
> > 
> 
> It occurs to me that it might be quite appropriate to use
> Aldor itself to write the dependency generation program.
> Can you see any impediment to my doing this?
> 

Nope; should be pretty simple - the choice of java was down to the fact
I'm more familiar with the java type library. 

If no one volunteers, then I might have a quick crack at it at some
point.

\start
Date: Wed, 7 Sep 2005 01:44:57 -0400
From: Emil Volcheck
To: ACM SIGSAM Officers List <SIGSAM_OFFICERS@LISTSERV.ACM.ORG>
Subject: Re: [SIGSAM_OFFICERS] ACM/ISSAC Active Journal
Cc: Patrizia Gianni

Tim,

I like both ideas: a potential journal as well as for the
ISSAC CD.  ACM has the wherewithal to launch a journal like
this, but we'd have to do prototypes like you suggest.
Possible starting points are the ISSAC Proceedings, or
a special issue of either Communications in Computer
Algebra or Transactions on Mathematical Software.

How would you propose to handle submissions that include
a Mathematica or Maple literate program?  Should we ask
commercial vendors to include trial versions?  Or perhaps
we could link this to Manuel Bronstein's idea of a SIGSAM
server running commercial and free computer algebra software
that members could connect to.

How do you think we should start this?  What's the first step?

The idea of a journal accepting software as well as articles
has been around for a while.  I remember when I was at
RISC-Linz over ten years ago, people were talking about getting
the JSC to accept and test programs to accompany articles.

--Emil

On Mon, Sep 05, 2005 at 10:28:03PM -0400, root wrote:
> Emil, et. al.
> 
> For the past two years I've been building the proceedings CD that gets
> distributed at ISSAC. This has been interesting but not really breaking
> any new ground. And the process starts at the last minute so there is
> very little time to do anything but get the CD assembled.
> 
> This year I'd like to consider something more interesting and to do that
> I need to start much earlier (now).
> 
> Consider the following idea:
> 
>   You are giving a talk about a new algorithm. During the talk you give
>   out the URL which contains a copy of your paper. The paper is a literate
>   program which contains latex plus the full source code.
> 
>   A person in the audience can put a special Live CD in their laptop (which
>   boots linux but does not change their hard drive). They open a browser.
>   They surf to the given URL. They "drag and drop" your paper onto their
>   machine, it compiles, installs, and is set up to run.
> 
>   Now the person in the audience can actually execute your algorithm while
>   you are giving your talk.
> 
>   This is the "Doyen" idea. It can be applied in all of the science
>   conferences but ISSAC is a perfect test case.
> 
> For background some of you need to know that Carlo Traverso has been trying
> to develop an "Active Journal" which would accept "Literate Programs" for
> publication.
> 
> Literate programs (my definition) are papers that contain the complete,
> runnable source code for the published algorithm as well as things like
> proof of termination, order of the algorithm, etc. If these are published
> in an Active Journal then people will be able to use the algorithms directly.
> This has been a problem in the past (e.g. a new, faster Groebner basis
> algorithm that does not have associated code). Given that we are doing
> computational mathematics I claim that running code is as important as
> a proof. Axiom has been rewritten to be all literate programs (that is,
> all of the files are now documents and there is no lisp, boot, spac, C, or
> Makefile files anymore).
> 
> Another effort is the Doyen Computational Science Platform CD project 
> (http://sourceforge.net/projects/doyencd)
> which has created a Live CD (that is, one that will boot linux on a
> computer from the CD without changing your hard drive). The goal of
> the Doyen project is to set up a Live CD that contains several computer
> algebra systems, a web server, a browser, and a special Wiki, a website
> user's can change. Thanks to Bill Page Axiom already has such a wiki
> (http://page.axiom-developer.org) 
> 
> You should be able to "drag and drop" a literate program onto a Doyen
> CD and have it automatically compile, install, latex, and set up to run
> the program in the paper. Doyen is not quite there yet but that is the
> goal.
> 
> If we can create a working demonstration of a Doyen CD for the next
> ISSAC then we can encourage people to write algorithms that will work
> on the CD software and publish the resulting literate programs in 
> Carlo's Active Journal.
> 
> All of this technology exists in prototype form. ISSAC would be the 
> perfect forum to demonstrate a working prototype and it would certainly
> make the ISSAC CDs much more than just an electronic copy of a paper
> journal. If this works then the ACM can spread the technology to the
> other computational science areas.

\start
Date: Wed, 07 Sep 2005 04:20:03 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomDownload] Re: Huge Axiom Package (on Windows)

The idea to have an interactive installation for Axiom (like Cygwin setup
or like "synaptic":http://www.nongnu.org/synaptic on Debian) is a good one
but implementation would be a lot of work! For one thing, such an installer
would have to know all of the dependencies within the Axiom library so
that one could "pick-and-choose" the mathematical packages (also categories
and domains) that one wishes to use and have the installer include all other
packages on which it depends automatically included.

It would be great to hear from anyone who has any specific ideas about how
to do this.

In the meantime, instead of downloading the binary distribution, perhaps
you might find it more convenient and interesting to build Axiom from
source. The detailed instructions are here: BuildAxiom.

\start
Date: Wed, 7 Sep 2005 09:20:39 -0400
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

On Wednesday 07 September 2005 02:15 am, William Sit wrote:
> C Y wrote:
> > I'm afraid I don't quite understand this part.  Why is ua needed?  I
> > wanted to assign a dimension of Length to a, such that typing in a
> > results in the following:
> >
> > ->(1) setDim("Length",a)
> >
> >            a [m]
> >
> > ->(2)  a
> >
> >            a [m]
> >
> > Is this not possible, or did I miss another subtle design issue?
> > (probable)
>
> Axiom is a strongly typed language, which means that if you change the
> representation of something, it will belong to a different type (or
> domain). The two are distinct objects, even if in some sense, they are
> mathematically the same. You cannot substitute one for the other without
> some sort of coercion, if that is possible at all.

OK, but shouldn't that be a separate issue from what is assumed by Axiom when  
a is input into the command line?

> Thus SIUnitSystem(S) is not the same as S, because objects in S has no
> units attached (purely mathematical objects, usually). Attaching a unit to
> an element s in S immediately takes the result out of the domain S, into
> the new domain SIUnitSystem(S). Sure, we can retract the result back to S,
> but then it will lose its unit! So if you look at the signature of setDim:
>
>      setDim: (Dimension, S) -> %
>
> The % is SIUnitSystem(S) in our example, in general, it is any domain in
> UnitSystem(S) category. Say if s is just a symbol, then the result of
> setDim("Length",s) would be an object with Rep
>
>     Record(value = s, dim="Length", unit="m", etc)
>
> whereas the Rep of s in Symbol is simply s itself (probably just a string
> "s" as name, or even some hash code). The display s [m] is the display for
> this new object. If you do not assign the result to a new variable, say
> sWithUnit, then this object is "lost" immediately (although Axiom has a way
> to recall results in a session). So one has to assign it to use the new
> object again. The statment setDim("Length",s) does not change s at all. It
> does not add a unit to s. It creates a new object whose outputform is "s
> [m]".

OK, but don't we want to take it one step further and have Axiom assume that 
after a setDim("Dimension",s) command is issued when we type s on the input 
line we are referring to the new object with outputform "s [m]" when s is any 
type of  Variable?  If s is a number this doesn't make sense, but intuitively 
when I do setDim("Length",x) I expect that from that point on, unless I do 
unsetDim("x") to explicitly undo the setDim command, when I say "x" I'm 
referring to the object that has both the variable x and the information 
about Dimension.  That's implicit in issuing the setDim command in the first 
place.  In a software design sense I would think that doing otherwise would 
violate the Principle of Least Surprise.  I would rather use some command 
like stripDim("x") to get at the object "x" that doesn't have a dimension 
associated with it if for some reason I want it, because once I so setDim 
command it's assumed (at least by me) that I don't WANT to have x work as an 
object without dimension anymore.  Obviously this doesn't work for 
setDim("Length",4), since 4 is not a variable, but in the case of x it should 
(at least IMHO) work.  Maybe we can flag this behavior so that if a hard core 
Axiom user prefers the behavior which is a consequence of strict interaction 
with a strong type system and doesn't want to special case variable behavior 
Axiom won't do the extra voodoo?

If this is not possible, we can probably document things to make them usable, 
but requiring using a second variable to assign dimension to another one is 
(at least based on my own expectations) going to be very, very non-intuitive.  
If x is given a Dimension of Length, x without dimension doesn't have any 
sensical meaning I can figure out.

> In fact, you can even assign s to two different units in the same 
> session, if s happens to just provide the value for two quantities with
> different dimensions. So s as an element of S is dimensionless, and only
> gain dimensionality via the setDim command. This is not that uncommon in
> the real world. We had the example even with the mathematical constant %pi,
> with two dimensions in two equations.

Right, but that's a constant, and %pi is one of those "dimensionless but not 
without dimension" scenarios, IIRC.  In general I agree - if s is providing 
the value for two quantities with different dimensions, the current setDim 
behavior is good.  But,  *in the specific case of variables*, I still think 
it is a better idea not to require a separate identifier for the x with 
dimension object, since any use of it other than as a variable with dimension 
isn't going to make sense in the context calculations using x and (IMHO) 
shouldn't be allowed.  I would MUCH rather, in that case, that we provide a 
stripDIM(x) command for the presumably much rarer case where you are actually 
looking for that.  Or perhaps an alternative suggestion below, which would 
require (maybe) less violation of Axiom's rules.

> > I can see setDimUnit refusing to work on an actual number (e.g. setDimUnit
> > ("Length,"cm",4) ) without being assigned to a variable, but surely this
> > restriction shouldn't apply in general?
>
> This has nothing to do with whether s is a number or a symbolic expression.
> The "ua" is required because of types. Unfortunately, while you can retract
> "ua" back to "a" because the value of "ua" is "a", you cannot coerce "a"
> into "ua". (The quotes are just to separate it from the text, not to be
> meant as string deliminators).

This seems a little odd to me - why can't you have a situation where the 
"toplevel" object a refers to a variable "a" and a dimension "dim", and just 
rely on a command to reach the inner variable in the rare case you would want 
to?  A limitation of Axiom?  If so this is very unfortunate, since I suspect 
this is not the only case out there where this kind of thing is going to play 
havoc with the intuitive expectations of users.  What if we internally use 
some symbol other than the one given in setDim("Length",a) and have a rule 
for displaying a variable with dimension that it shouldn't show the internal 
symbol but a instead.  Something like:

setDim("Length",a) -> creates some object containing [nondim_a,Length] and 
assigns this to the name a, just like a := <object> would.  Then we create 
some kind of display rule that rather that variables of the form nondim_* be 
displayed as * in output?  This would preserve the Axiom type behavior while 
hiding the messy details and avoiding violating user expection of variable 
interaction.  This could probably be turned off as well if a hardcore Axiom 
user wants normal behavior.

Maybe I'm making too much of this but I'm still not totally happy about 
enforcing the requirement to always specify a dimension with a unit (although 
I still agree it's the best solution available) - I'd rather avoid any more 
surprises for the user if possible.

> > So be it - we'll go for enforced dimension awareness.
>
> Good, we have fewer and fewer differences.

The user docs for this point are going to have to be verbose, elegant, and 
compelling, but this being Axiom I think we can get away with it :-).

> > Any Axiom gurus that can help us on the above point?
>
> I left the above in, just hoping someone will know how to do this. It is
> really a very simple thing. The information (strings for the dimensions) is
> in a list. Why can't we feed this to Union without the list wrapper? Axiom
> allows commands in Lisp, and so someone who knows Lisp (Tim, Bill, Camm)
> should be able to easily write a line to do that. In Mathematica, one can
> replace the "Head", which is "List" for a list, by another function using
> "Apply", such as Apply[Plus, {1,2,3}] would produce 1+2+3=6. Surely Axiom
> can do that too -- but note Union is not a traditional function, but a
> domain constructor expecting domains as arguments.

Hmm. OK, we can burn that bridge when we come to it if no one tosses up a 
solution first.

> > > > > ---------- Implementation Issues: Setting up Dimension and Unit
> > > > > domains
> > >
> > > Interpreter interface does not even support the mouse. (Anyone wants to
> > > pick up this challenge?)
> >
> > Hmm.  I'll add my voice asking for this option/feature - it made Maxima
> > many times easier to use on a variety of problems (in Maxima, for
> > example, the integration routines would ask the user if things were
> > positive, negative, or zero in order to limit the amount of work and
> > provide a unique answer.  I wish I could remember the example that I
> > wound up using in Solid State Physics once.)
>
> I think Axiom's design philosophy (one of these) is to have as few (none?)
> interaction with the user as possible so that functions can be fed into
> other functions for automatic execution. With functions requiring
> interaction, you can't do that. Graphics is a big exception, but any
> graphics done by interactive manipulation can be done in batch mode as
> well.

Surely this can be made optional?  Current behavior can be preserved, just add 
the ability to ask questions if allowed?

> > OK.  So in theory, if we vectorize the Units/Derived Dimensions, we won't
> > need the idea of Reduced Dimensions?
>
> I don't think so. The newly discovered example that PV (Pressure times
> volume) also has reduced dimension of energy shows that the problem occurs
> for scalar quantities already. But the idea to handle vectors with
> dimension is still one worth investigating.

Right.  Actually, for physics it's probably necessary.

> Don't forget the dot product, cross product, gradient, curl !
>
> Looks like the discussions will continue. Tim has the idea of a pamphlet
> book, so don't worry about the length.

I think those can be handled once the basic structure is in place.  At any 
rate, they'll have to be ;-).

> > > The proposal allows a UnitSystem to be parametrized by a set S, and
> > > this set S can be a set of vectors or vector functions. So when coding
> > > say SI(S), for arbitrary S, one has to do cases when S has Vector, etc.
> > > Hehe, may be you can get a ph d for this project!
> >
> > Heh - that'd be cool, but for that I'd have to be enrolled somewhere and
> > actually be a student again, and I doubt I'd ever get this across as a
> > thesis topic :-).  Dunno where I'd get funding from :-/.  Sure would be
> > interesting (and fun!) though.
>
> Funding is a real problem, and you're probably right, who would think unit
> system is doctoral material? After all, it's just arithmetic!

<snort>  So did I, when I started thinking about the original Maxima unit 
package a few years ago!  Opps.  Oh, well - maybe the chance to use it for a 
phd will come up if it's already done, and available to show anybody who 
still thinks that ;-).  Easier to fund if all the work's already finished - 
takes less time that way too.

> > > > > --------------- Name space issues
>>
> > OK.  Any introductory tutorial on units in Axiom will need to make it
> > clear that units are not normal variables, and explain how things work,
> > but I think it should be doable.
>
> Which do you mean? Using local (domain) variables, or using strings?

Anything that behaves at all differently from the normal way people use units 
in equations, or would expect things to behave.  Axiom is going to enforce a 
few things most people probably never think about and won't want to think 
about, so we need to coax users in carefully or they'll run screaming.  
(Well, the undergrads will anyway, but there's no help for that...)

> > > > > ---------- Implementation Issue: Simplification of dimensions
>
> > > > b)  Significant Digits, Uncertainty in Measurement, and Error
> > > > propagation (hard, both in itself and also since potential errors due
> > > > to the numerical calculations of the computer must also be considered
> > > > in order to be rigorous)
>
> I agree totally with your view that scientist should know about
> uncertaintly in measurement and be able to do error analysis of any
> computation they do . But that is for "scientists" (in the sense of
> physcial sciences). A lot of measurement are not of that nature, such as
> statistical measurements, or processes that involve a lot of randomness
> such as economics, or weather, It would be difficult to carry out every
> computation with an error range.

Correct.  However, the physical sciences are my primary interest, at this 
point - and they will need it.  Error analysis should be optional, but it is 
a necessary tool for many important kinds of work.

> THe problem is not the computational error 
> analysis, which can be automated using techniques in automatic
> differentiation perhaps (applying chain rule to propagate the error
> computations as differentials). The problem is in the determining the
> accuracies of the input measurements.

That's up to the scientist - garbage in equals garbage out, even in Axiom.  
However, given good measurements and sufficient information about the system, 
I'm thinking Axiom should be able to take it from there.

> No problem and I'll be glad to help out. In any case, if it is on wiki, it
> will get modifiable by readers too!

Well, I'm trying to avoid abject public humiliation, too ;-)  I'd rather have 
something at least semi-polished for the wiki.

\start
Date: Wed, 07 Sep 2005 10:19:44 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

Just a quick answer for now:

You can use

 s:=setDimUnit("Length", "cm",('s)::S)

if s is an unassigned symbol. The quote in the argument tells Axiom to use s as
a symbol temporarily, but then assign it to the domain SIUnitSystem(S) provided
S has RetractableTo(Symbol) such as POLY INT.

So for "variables" (symbols), that is not an issue. For expressions, you need
not assign it to a variable first:

  s:=setDimUnit("Length","cm", P*V)

is quite ok (assuming you want the aggregate variable PV).  In our discussion,
we did not use any specific expression and use "a" to stand for one, so I have
to use a new identifier "ua", assuming "a" is already bound.

I'll respond to other questions later tonight. Got to go to school.

William
--

C Y wrote:
> 
> On Wednesday 07 September 2005 02:15 am, William Sit wrote:
> > C Y wrote:
> > > I'm afraid I don't quite understand this part.  Why is ua needed?  I
> > > wanted to assign a dimension of Length to a, such that typing in a
> > > results in the following:
> > >
> > > ->(1) setDim("Length",a)
> > >
> > >            a [m]
> > >
> > > ->(2)  a
> > >
> > >            a [m]
> > >
> > > Is this not possible, or did I miss another subtle design issue?
> > > (probable)
> >
> > Axiom is a strongly typed language, which means that if you change the
> > representation of something, it will belong to a different type (or
> > domain). The two are distinct objects, even if in some sense, they are
> > mathematically the same. You cannot substitute one for the other without
> > some sort of coercion, if that is possible at all.
> 
> OK, but shouldn't that be a separate issue from what is assumed by Axiom when
> a is input into the command line?
> 
> > Thus SIUnitSystem(S) is not the same as S, because objects in S has no
> > units attached (purely mathematical objects, usually). Attaching a unit to
> > an element s in S immediately takes the result out of the domain S, into
> > the new domain SIUnitSystem(S). Sure, we can retract the result back to S,
> > but then it will lose its unit! So if you look at the signature of setDim:
> >
> >      setDim: (Dimension, S) -> %
> >
> > The % is SIUnitSystem(S) in our example, in general, it is any domain in
> > UnitSystem(S) category. Say if s is just a symbol, then the result of
> > setDim("Length",s) would be an object with Rep
> >
> >     Record(value = s, dim="Length", unit="m", etc)
> >
> > whereas the Rep of s in Symbol is simply s itself (probably just a string
> > "s" as name, or even some hash code). The display s [m] is the display for
> > this new object. If you do not assign the result to a new variable, say
> > sWithUnit, then this object is "lost" immediately (although Axiom has a way
> > to recall results in a session). So one has to assign it to use the new
> > object again. The statment setDim("Length",s) does not change s at all. It
> > does not add a unit to s. It creates a new object whose outputform is "s
> > [m]".
> 
> OK, but don't we want to take it one step further and have Axiom assume that
> after a setDim("Dimension",s) command is issued when we type s on the input
> line we are referring to the new object with outputform "s [m]" when s is any
> type of  Variable?  If s is a number this doesn't make sense, but intuitively
> when I do setDim("Length",x) I expect that from that point on, unless I do
> unsetDim("x") to explicitly undo the setDim command, when I say "x" I'm
> referring to the object that has both the variable x and the information
> about Dimension.  That's implicit in issuing the setDim command in the first
> place.  In a software design sense I would think that doing otherwise would
> violate the Principle of Least Surprise.  I would rather use some command
> like stripDim("x") to get at the object "x" that doesn't have a dimension
> associated with it if for some reason I want it, because once I so setDim
> command it's assumed (at least by me) that I don't WANT to have x work as an
> object without dimension anymore.  Obviously this doesn't work for
> setDim("Length",4), since 4 is not a variable, but in the case of x it should
> (at least IMHO) work.  Maybe we can flag this behavior so that if a hard core
> Axiom user prefers the behavior which is a consequence of strict interaction
> with a strong type system and doesn't want to special case variable behavior
> Axiom won't do the extra voodoo?
> 
> If this is not possible, we can probably document things to make them usable,
> but requiring using a second variable to assign dimension to another one is
> (at least based on my own expectations) going to be very, very non-intuitive.
> If x is given a Dimension of Length, x without dimension doesn't have any
> sensical meaning I can figure out.
> 
> > In fact, you can even assign s to two different units in the same
> > session, if s happens to just provide the value for two quantities with
> > different dimensions. So s as an element of S is dimensionless, and only
> > gain dimensionality via the setDim command. This is not that uncommon in
> > the real world. We had the example even with the mathematical constant %pi,
> > with two dimensions in two equations.
> 
> Right, but that's a constant, and %pi is one of those "dimensionless but not
> without dimension" scenarios, IIRC.  In general I agree - if s is providing
> the value for two quantities with different dimensions, the current setDim
> behavior is good.  But,  *in the specific case of variables*, I still think
> it is a better idea not to require a separate identifier for the x with
> dimension object, since any use of it other than as a variable with dimension
> isn't going to make sense in the context calculations using x and (IMHO)
> shouldn't be allowed.  I would MUCH rather, in that case, that we provide a
> stripDIM(x) command for the presumably much rarer case where you are actually
> looking for that.  Or perhaps an alternative suggestion below, which would
> require (maybe) less violation of Axiom's rules.
> 
> > > I can see setDimUnit refusing to work on an actual number (e.g. setDimUnit
> > > ("Length,"cm",4) ) without being assigned to a variable, but surely this
> > > restriction shouldn't apply in general?
> >
> > This has nothing to do with whether s is a number or a symbolic expression.
> > The "ua" is required because of types. Unfortunately, while you can retract
> > "ua" back to "a" because the value of "ua" is "a", you cannot coerce "a"
> > into "ua". (The quotes are just to separate it from the text, not to be
> > meant as string deliminators).
> 
> This seems a little odd to me - why can't you have a situation where the
> "toplevel" object a refers to a variable "a" and a dimension "dim", and just
> rely on a command to reach the inner variable in the rare case you would want
> to?  A limitation of Axiom?  If so this is very unfortunate, since I suspect
> this is not the only case out there where this kind of thing is going to play
> havoc with the intuitive expectations of users.  What if we internally use
> some symbol other than the one given in setDim("Length",a) and have a rule
> for displaying a variable with dimension that it shouldn't show the internal
> symbol but a instead.  Something like:
> 
> setDim("Length",a) -> creates some object containing [nondim_a,Length] and
> assigns this to the name a, just like a := <object> would.  Then we create
> some kind of display rule that rather that variables of the form nondim_* be
> displayed as * in output?  This would preserve the Axiom type behavior while
> hiding the messy details and avoiding violating user expection of variable
> interaction.  This could probably be turned off as well if a hardcore Axiom
> user wants normal behavior.
> 
> Maybe I'm making too much of this but I'm still not totally happy about
> enforcing the requirement to always specify a dimension with a unit (although
> I still agree it's the best solution available) - I'd rather avoid any more
> surprises for the user if possible.
> 
> > > So be it - we'll go for enforced dimension awareness.
> >
> > Good, we have fewer and fewer differences.
> 
> The user docs for this point are going to have to be verbose, elegant, and
> compelling, but this being Axiom I think we can get away with it :-).
> 
> > > Any Axiom gurus that can help us on the above point?
> >
> > I left the above in, just hoping someone will know how to do this. It is
> > really a very simple thing. The information (strings for the dimensions) is
> > in a list. Why can't we feed this to Union without the list wrapper? Axiom
> > allows commands in Lisp, and so someone who knows Lisp (Tim, Bill, Camm)
> > should be able to easily write a line to do that. In Mathematica, one can
> > replace the "Head", which is "List" for a list, by another function using
> > "Apply", such as Apply[Plus, {1,2,3}] would produce 1+2+3=6. Surely Axiom
> > can do that too -- but note Union is not a traditional function, but a
> > domain constructor expecting domains as arguments.
> 
> Hmm. OK, we can burn that bridge when we come to it if no one tosses up a
> solution first.
> 
> > > > > > ---------- Implementation Issues: Setting up Dimension and Unit
> > > > > > domains
> > > >
> > > > Interpreter interface does not even support the mouse. (Anyone wants to
> > > > pick up this challenge?)
> > >
> > > Hmm.  I'll add my voice asking for this option/feature - it made Maxima
> > > many times easier to use on a variety of problems (in Maxima, for
> > > example, the integration routines would ask the user if things were
> > > positive, negative, or zero in order to limit the amount of work and
> > > provide a unique answer.  I wish I could remember the example that I
> > > wound up using in Solid State Physics once.)
> >
> > I think Axiom's design philosophy (one of these) is to have as few (none?)
> > interaction with the user as possible so that functions can be fed into
> > other functions for automatic execution. With functions requiring
> > interaction, you can't do that. Graphics is a big exception, but any
> > graphics done by interactive manipulation can be done in batch mode as
> > well.
> 
> Surely this can be made optional?  Current behavior can be preserved, just add
> the ability to ask questions if allowed?
> 
> > > OK.  So in theory, if we vectorize the Units/Derived Dimensions, we won't
> > > need the idea of Reduced Dimensions?
> >
> > I don't think so. The newly discovered example that PV (Pressure times
> > volume) also has reduced dimension of energy shows that the problem occurs
> > for scalar quantities already. But the idea to handle vectors with
> > dimension is still one worth investigating.
> 
> Right.  Actually, for physics it's probably necessary.
> 
> > Don't forget the dot product, cross product, gradient, curl !
> >
> > Looks like the discussions will continue. Tim has the idea of a pamphlet
> > book, so don't worry about the length.
> 
> I think those can be handled once the basic structure is in place.  At any
> rate, they'll have to be ;-).
> 
> > > > The proposal allows a UnitSystem to be parametrized by a set S, and
> > > > this set S can be a set of vectors or vector functions. So when coding
> > > > say SI(S), for arbitrary S, one has to do cases when S has Vector, etc.
> > > > Hehe, may be you can get a ph d for this project!
> > >
> > > Heh - that'd be cool, but for that I'd have to be enrolled somewhere and
> > > actually be a student again, and I doubt I'd ever get this across as a
> > > thesis topic :-).  Dunno where I'd get funding from :-/.  Sure would be
> > > interesting (and fun!) though.
> >
> > Funding is a real problem, and you're probably right, who would think unit
> > system is doctoral material? After all, it's just arithmetic!
> 
> <snort>  So did I, when I started thinking about the original Maxima unit
> package a few years ago!  Opps.  Oh, well - maybe the chance to use it for a
> phd will come up if it's already done, and available to show anybody who
> still thinks that ;-).  Easier to fund if all the work's already finished -
> takes less time that way too.
> 
> > > > > > --------------- Name space issues
> >>
> > > OK.  Any introductory tutorial on units in Axiom will need to make it
> > > clear that units are not normal variables, and explain how things work,
> > > but I think it should be doable.
> >
> > Which do you mean? Using local (domain) variables, or using strings?
> 
> Anything that behaves at all differently from the normal way people use units
> in equations, or would expect things to behave.  Axiom is going to enforce a
> few things most people probably never think about and won't want to think
> about, so we need to coax users in carefully or they'll run screaming.
> (Well, the undergrads will anyway, but there's no help for that...)
> 
> > > > > > ---------- Implementation Issue: Simplification of dimensions
> >
> > > > > b)  Significant Digits, Uncertainty in Measurement, and Error
> > > > > propagation (hard, both in itself and also since potential errors due
> > > > > to the numerical calculations of the computer must also be considered
> > > > > in order to be rigorous)
> >
> > I agree totally with your view that scientist should know about
> > uncertaintly in measurement and be able to do error analysis of any
> > computation they do . But that is for "scientists" (in the sense of
> > physcial sciences). A lot of measurement are not of that nature, such as
> > statistical measurements, or processes that involve a lot of randomness
> > such as economics, or weather, It would be difficult to carry out every
> > computation with an error range.
> 
> Correct.  However, the physical sciences are my primary interest, at this
> point - and they will need it.  Error analysis should be optional, but it is
> a necessary tool for many important kinds of work.
> 
> > THe problem is not the computational error
> > analysis, which can be automated using techniques in automatic
> > differentiation perhaps (applying chain rule to propagate the error
> > computations as differentials). The problem is in the determining the
> > accuracies of the input measurements.
> 
> That's up to the scientist - garbage in equals garbage out, even in Axiom.
> However, given good measurements and sufficient information about the system,
> I'm thinking Axiom should be able to take it from there.
> 
> > No problem and I'll be glad to help out. In any case, if it is on wiki, it
> > will get modifiable by readers too!
> 
> Well, I'm trying to avoid abject public humiliation, too ;-)  I'd rather have
> something at least semi-polished for the wiki.

\start
Date: Wed, 7 Sep 2005 08:33:55 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

--- William Sit wrote:

> Just a quick answer for now:
> 
> You can use
> 
>  s:=setDimUnit("Length", "cm",('s)::S)
> 
> if s is an unassigned symbol. The quote in the argument tells Axiom
> to use s as a symbol temporarily, but then assign it to the domain
> SIUnitSystem(S) provided S has RetractableTo(Symbol) such as POLY
> INT.

Hmm.  OK.  As a design consideration I would prefer to hide this logic
within the definition of the set functions, but that's just a detail. 
The important thing is it's possible.

> So for "variables" (symbols), that is not an issue. For expressions,
> you need not assign it to a variable first:
> 
>   s:=setDimUnit("Length","cm", P*V)
> 
> is quite ok (assuming you want the aggregate variable PV).  

Right :-).  I think that use is much less common in practice than using
the same name for the nondim + dimension object and the nondim
variable, but it's good it can be done at need.  (Heck, I never
realized you COULD do something like that - I thought of x [m] as being
inseparable.)

> In our discussion, we did not use any specific expression and 
> use "a" to stand for one, so I have to use a new identifier "ua", 
> assuming "a" is already bound.

Ah :-).  Opps.  Should have used "t" from the x=x0+v0t+1/2at^2 and time
- that would have been a better example.  My bad.
 
> I'll respond to other questions later tonight. Got to go to school.

Sounds good!  I'll start going over the discussions and see if I can
distill it down over the next few days, which probably means a lot more
not-seeing-things-clearly questions :-/.  I've got to think about how
to structure this sucker first, since it is clear there will be
extensions to add for quite some time.

\start
Date: Wed, 07 Sep 2005 10:47:23 -0500
From: MathAction (kai Kaminski)
To: MathAction
Subject: [Axiom In Emacs] 

All of Axiom's source files are pamphlets now, which means they
are <a href="http://literateprogramming.com">literate programs</a> as
understood
by <a href="http://www.eecs.harvard.edu/~nr/noweb/">Noweb</a>. This is
a collection of Elisp code and tips to make editing pamphlets with
Emacs less painful.

The first step is to put <tt>noweb-mode.el</tt>, which is contained in
the Noweb distribution, into your <tt>load-path</tt>. Then add the
following to your <tt>.emacs</tt> to load <tt>noweb-mode</tt>:

(add-to-list 'auto-mode-alist
  '(".*\\.pamphlet" . noweb-mode))
</pre>

Noweb mode not only offers functions to deal with chunks, like killing
chunks, but also lets the user specify a major mode for the code and
documentation chunks. The standard documentation mode is LaTeX and the
standard code mode is Fundamental. While LaTeX is the right choice for
all files in Axiom so far, Fundamental is not a good choice as code
mode in general and there are several ways to change it.

First of all you can use the Emacs command <tt>noweb-set-code-mode</tt>, which
prompts you for a major mode.

You can also
use <a
href="http://www.gnu.org/software/emacs/manual/html_node/File-Variables.html">file
variables</a>. The easiest way to do this is to open the file in question, go to the beginning of the file and
call <tt>noweb-insert-mode-line</tt> (a misnomer). It will insert a
new line containing all the necessary incantations. The other option
is to insert the same text manually. A file with code chunks
containing lisp code, for example, should have the following first line:
<pre>
% -*- mode: Noweb; noweb-code-mode: lisp-mode -*-
</pre>

Unfortunately, most files in the Axiom distribution do not contain
file variables to set the code mode and it is unclear if that is
desirable in the first place, since not everyone is using
Emacs. Luckily, many of the pamphlet files have names of the form
<tt>foo.ext.pamphlet</tt>, where <tt>ext</tt> indicates the type of
the code chunks. For example, <tt>foo.lisp.pamphlet</tt> would contain Lisp
code and <tt>bar.spad.pamphlet</tt> would contain spad code. This allows for a
simple form of auto detection. Simply add the following to
your <tt>.emacs</tt>:
<pre>

</pre>
This code does not override file variables. It uses
the <tt>auto-mode-alist</tt>-mechanism to choose the code mode and
uses Fundamental mode, if that fails.

It should be mentioned that Emacs 22 will feature yet another way to
detect the right major mode for a file by examining the file's
content. Maybe this can be adapted to look at the content of the code
chunks instead.

Especially when dealing with Axiom's existing code base one often
finds oneself in a situation, where a pamphlet looks like this:
<pre>
\documentclass{article}
\usepackage{noweb}

\begin{document}
  \title{DWIM.BOOT.PAMPHLET}
  \author{John Doe}
  \maketitle

<<*>>source code
@
</pre>
The pamphlet doesn't contain any documentation and just one big code
  chunk. Usually that means that the original author didn't use
  literate programming and that the source code was just transformed
  to a pamphlet in the obvious - and useless - way. If you want to
  transform it into a true literate program you'll often want to take
  a consecutive region of code, replace it with a chunk marker,
  say <tt>&lt;&lt;foo&gt;&gt;</tt>, and add a new chunk containing
  the replaced code somewhere else in the file. This is made somewhat
  easier by the following two Elisp functions:

<pre>
(defun kai:noweb-extract-chunk (chunk-name start end)
  (interactive "sChunk name: \nr")
  (let* ((chunk (delete-and-extract-region start end)))
    (kill-new (concat "<<" chunk-name ">>=\n" chunk "\n@\n"))
    (save-excursion
      (goto-char start)
      (insert (concat "<<" chunk-name ">>\n"))))
  (noweb-update-chunk-vector))

(defun kai:noweb-yank (&rest args)
  (interactive "")
  (apply 'yank args)
  (noweb-update-chunk-vector))

(add-hook 'noweb-mode-hook
	  (lambda ()
	    (global-set-key [(control ?c) ?x] 'kai:noweb-extract-chunk)
	    (global-set-key [(control ?c) ?y] 'kai:noweb-yank)))
</pre>

To use them, just mark a region of code and press <tt>C-c
  x</tt>. You'll be prompted for a chunk name. Then go to the point
  where you want the new chunk to reside and press <tt>C-c y</tt>.

It would be nicer, if one could bind <tt>kai:noweb-yank</tt>
to <tt>C-y</tt> instead. Unfortunately that doesn't work. The problem
seems to be that whenever the Noweb mode changes major modes, because
you left/entered a chunk, the new major mode as well as the Noweb mode
reinstall their key bindings and restore the original binding
for <tt>C-y</tt>. I'm not sure if this explanation is accurate,
though.


<h3>Editing BOOT code</h3>

To simplify editing BOOT code
put <a href="boot-mode.el"><tt>boot-mode.el</tt></a> into
your <tt>load-path</tt> and add the following to
your <tt>.emacs</tt>:
<pre>

(add-to-list 'auto-mode-alist
  '(".*\\.boot" . boot-mode))

??changed:
-This code tries to automatically set the code mode in noweb, which only works for files with names of the form <tt>file.ext.pamphlet</tt>, where <tt>ext</tt> indicates the code mode. For example, <tt>sockio.lisp.pamphlet</tt> would have its code mode set to <tt>lisp-mode</tt> and <tt>nci.boot.pamphlet</tt> to <tt>boot-mode</tt>. If the auto-detection can't decide on a mode it uses <tt>fundamental-mode</tt>.
Currently this mode doesn't do anything beyond very rudimentary syntax
high-lighting and making <tt>comment-region</tt> work.

\start
Date: Thu, 08 Sep 2005 01:39:30 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

> C Y wrote:

> OK, but don't we want to take it one step further and have Axiom assume that
> after a setDim("Dimension",s) command is issued when we type s on the input
> line we are referring to the new object with outputform "s [m]" when s is any
> type of  Variable?  If s is a number this doesn't make sense, but intuitively
> when I do setDim("Length",x) I expect that from that point on, unless I do
> unsetDim("x") to explicitly undo the setDim command, when I say "x" I'm
> referring to the object that has both the variable x and the information
> about Dimension. 

As I show in my earlier reply, we can do setDim("dim",s) but we still need to
assign it to s when s is a Symbol. There is a catch: since there are many
domains that include symbols, it won't be clear where s belongs. In other words,
since there are many setDim functions, one for each domain in the UnitSystem
Category, and each PARAMETER S for UnitSystem, you have to do a package call to
explicitly say which S should contain the symbol. For example, you may want:

   s:=setDim("Length",('s)::S)

or  

   s:=setDim("Length",'s)$SIUnitSystem(S)

In such cases, there is no point in retracting s to S (which will give a symbol
s). In order to make s behave more like it were without units, let's see what
the following scenario will require (assume FPS system)

(1) ->  s:=setDim("Length",4)
              4 [ft]
(2) ->  s:= 7

In order that (2) gives the answer "7 [ft]", the package will have to include a
coercion function that is quite smart: it will need to first coerce 7 to
FPSUnitSystem(PositiveInteger) WITHOUT knowing its dimension, then coerce that
to FPSUnitSystem(S), without knowing the dimension --- which requires S to have
PositiveInteger as a subdomain, then assign whatever property s has (its
dimension and unit at the time) to 7, and finally assigning the fully formed
object (Rep for 7 [ft]) to the identifier s of type FPSUnitSystem(S). Now of
course, the more direct and intuitive way is simply to change the value field in
the Rep for s to 7. But HOW is the Interpreter to know that via a simple,
universally coded assignment?

So to help the Interpreter, or indeed, to avoid having to modify the interpreter
to make it smarter -- such modification will add so much inefficiency to
ordinary assignment that it is not advisable in any case---we can design
functions to do the more intuitive thing:

(2') ->   setValue(s, 7)

but of course this is not as intuitive for the user as (2)! However, it is
actually quite uniform and similar to setDim or setUnit.

The same means that a statement like:

(3) ->  s:= s + 7

would involve the same type of coercions as for (2). If instead,

(3') -> setValue(s, s+7)

then the function setValue *may* be taught to first retract the s in s+7 to S,
add 7 to it in the domain S, then put this in the value-field of Rep of s. I say
*may*, because the general situation would require a parser!

So there is still a big design problem to think about: how to make subsequent
computations intuitive without writing a parser for the package! The following
way perhaps works (effectively asking the user to do the parsing):

    setValue(s, retract(s)+7)

(any implementation, in Axiom, will require conditional implementation, testing
that S can do arithmetic with PositiveInteger or Integer), and if s is not just
a symbol, a retractIfCan(s) may be more appropriate.
 


> That's implicit in issuing the setDim command in the first
> place.  In a software design sense I would think that doing otherwise would
> violate the Principle of Least Surprise.  

You should know that Axiom is full of surprises because it is not easy to
understand the implications of a strongly typed language.

> I would rather use some command
> like stripDim("x") to get at the object "x" that doesn't have a dimension
> associated with it if for some reason I want it, because once I so setDim
> command it's assumed (at least by me) that I don't WANT to have x work as an
> object without dimension anymore.  Obviously this doesn't work for
> setDim("Length",4), since 4 is not a variable, but in the case of x it should
> (at least IMHO) work.

The problem is with subsequent arithmetic (not to mention the grander
vector calculus) that involves quantities whose dimensions or units
have not been defined, whether they be numbers or expressions. In some
sense, this is again forcing the user to know what he is doing, to
think of dimensions and units in every step of the computation. But
users used to the sloppy way will find this very frustrating.  In the
simple example above, s+7, the dimension and unit of 7 are not
given. Is it good idea to "help" the user and "guess" that 7 should
have the same dimension and unit as s? If so, wouldn't that allow a
sloppy user to add s [ft] to 7 [in] and get (s+7) [ft]?

I think we should not provide such automation: two reasons: simplifies
implementation, and forces the user to be specific on dimensions and
units. So a user MUST declare, using setDimUnit, EVERY quantity he
wants to compute using a unit system. If all inputs to an expression
are declared ahead of time, the arithmetic will take place in the unit
system domain and parsing done by the Interpreter, without the use of
setValue.

It would be desirable to allow:

    s:= setDimUnit("Length","in",'s)
    t:= s + 7 [ft]

to give a value of s+84 [in] for t. But this involves modifying the interpreter
and the language! ([ft] may be a list containing a variable ft). Here is an
argument for using variables for units, because there would have been created
conversion (rewrite) rule ft == 12 in, which would be applied automatically.

> Maybe we can flag this behavior so that if a hard core
> Axiom user prefers the behavior which is a consequence of strict interaction
> with a strong type system and doesn't want to special case variable behavior
> Axiom won't do the extra voodoo?

In general, I don't like (personal bias) a program to provide automatic help
(such as checking grammar or spelling or indentations in MS Word!). It is far
better to have fewer options and the system behaves consistently.


> What if we internally use
> some symbol other than the one given in setDim("Length",a) and have a rule
> for displaying a variable with dimension that it shouldn't show the internal
> symbol but a instead.  Something like:
>
> setDim("Length",a) -> creates some object containing [nondim_a,Length] and
> assigns this to the name a, just like a := <object> would.  Then we create
> some kind of display rule that rather that variables of the form nondim_* be
> displayed as * in output?  This would preserve the Axiom type behavior while
> hiding the messy details and avoiding violating user expection of variable
> interaction.  This could probably be turned off as well if a hardcore Axiom
> user wants normal behavior.

I suppose the above is obsolete now?

\start
Date: Thu, 08 Sep 2005 04:04:10 -0500
From: MathAction (kai Kaminski)
To: MathAction
Subject: [Axiom In Emacs] 

The first step is to put 'noweb-mode.el', which is contained in
the Noweb distribution, into your 'load-path'. Then add the
following to your '.emacs' to load 'noweb-mode'::

  ;; NOWEB-MODE
  (require 'noweb-mode)
  (add-to-list 'auto-mode-alist
    '(".*\\\\.pamphlet" . noweb-mode))


First of all you can use the Emacs command 'noweb-set-code-mode', which

call 'noweb-insert-mode-line' (a misnomer). It will insert a

containing lisp code, for example, should have the following first line::

  % -*- mode: Noweb; noweb-code-mode: lisp-mode -*-

'foo.ext.pamphlet', where 'ext' indicates the type of
the code chunks. For example, 'foo.lisp.pamphlet' would contain Lisp
code and 'bar.spad.pamphlet' would contain spad code. This allows for a

your '.emacs'::

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


the 'auto-mode-alist'-mechanism to choose the code mode and

finds oneself in a situation, where a pamphlet looks like this::

  \documentclass{article}
  \usepackage{noweb}
  
  \begin{document}
    \title{DWIM.BOOT.PAMPHLET}
    \author{John Doe}
    \maketitle
  
  <<*>>  source code
  @

The pamphlet doesn't contain any documentation and just one big
code chunk. Usually that means that the original author didn't
use literate programming and that the source code was just
transformed to a pamphlet in the obvious - and useless - way. If
you want to transform it into a true literate program you'll
often want to take a consecutive region of code, replace it with
a chunk marker, say '&lt;&lt;foo&gt;&gt;', and add a new chunk
containing the replaced code somewhere else in the file. This is
made somewhat easier by the following two Elisp functions::

  (defun kai:noweb-extract-chunk (chunk-name start end)
    (interactive "sChunk name: \nr")
    (let* ((chunk (delete-and-extract-region start end)))
      (kill-new (concat "<<" chunk-name ">>=\n" chunk "\n@\n"))
      (save-excursion
        (goto-char start)
        (insert (concat "<<" chunk-name ">>\n"))))
    (noweb-update-chunk-vector))
  
  (defun kai:noweb-yank (&rest args)
    (interactive "")
    (apply 'yank args)
    (noweb-update-chunk-vector))
  
  (add-hook 'noweb-mode-hook
            (lambda ()
              (global-set-key [(control ?c) ?x] 'kai:noweb-extract-chunk)
              (global-set-key [(control ?c) ?y] 'kai:noweb-yank)))

To use them, just mark a region of code and press 'C-c x'. You'll
be prompted for a chunk name. Then go to the point where you want
the new chunk to reside and press 'C-c y'.

It would be nicer, if one could bind 'kai:noweb-yank'
to 'C-y' instead. Unfortunately that doesn't work. The problem

for 'C-y'. I'm not sure if this explanation is accurate,

put <a href="boot-mode.el">'boot-mode.el'</a> into
your 'load-path' and add the following to
your '.emacs'::

  ;; BOOT-MODE
  (require 'boot-mode)
  (add-to-list 'auto-mode-alist
    '(".*\\\\.boot" . boot-mode))

high-lighting and making 'comment-region' work.

\start
Date: Thu, 8 Sep 2005 09:19:45 -0400
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

On Thursday 08 September 2005 01:39 am, William Sit wrote:
> > C Y wrote:
> >
> > OK, but don't we want to take it one step further and have Axiom assume
> > that after a setDim("Dimension",s) command is issued when we type s on
> > the input line we are referring to the new object with outputform "s [m]"
> > when s is any type of  Variable?  If s is a number this doesn't make
> > sense, but intuitively when I do setDim("Length",x) I expect that from
> > that point on, unless I do unsetDim("x") to explicitly undo the setDim
> > command, when I say "x" I'm referring to the object that has both the
> > variable x and the information about Dimension.
>
> As I show in my earlier reply, we can do setDim("dim",s) but we still need
> to assign it to s when s is a Symbol. There is a catch: since there are
> many domains that include symbols, it won't be clear where s belongs. 

I'm not following - are you thinking that we won't know what type "s" is  
inside the object containing both dimension and the nondimensional quantity?  
Well, what about if we had just typed "s" on the input line without saying 
anything about where it belongs? In my copy of Axiom this gives:

   (2)  s
                                                             Type: Variable s

I'm thinking we can assume whatever the "default" assumption would have been 
on the command line - just remember that, bump s temporarily to a symbol, and 
then return it to being a Variable (in this case.)  Or do you mean that s 
will need to wind up in a UnitSystem?  This isn't obvious to me - Dimension 
is more general than any one UnitSystem.  Maybe we need a domain for 
dimension-without-specific-unit objects?

> In other words, since there are many setDim functions, one for each domain 
> in the UnitSystem Category, and each PARAMETER S for UnitSystem, you have to
> do a package call to explicitly say which S should contain the symbol. For
> example, you may want:
>
>    s:=setDim("Length",('s)::S)
>
> or
>
>    s:=setDim("Length",'s)$SIUnitSystem(S)
>
> In such cases, there is no point in retracting s to S (which will give a
> symbol s). In order to make s behave more like it were without units, let's
> see what the following scenario will require (assume FPS system)
>
> (1) ->  s:=setDim("Length",4)
>               4 [ft]
> (2) ->  s:= 7
>
> In order that (2) gives the answer "7 [ft]", the package will have to
> include a coercion function that is quite smart: 

Wait - why do we want s:=7 to work in that case?  I would expect that to fail 
- 7 is a dimensionless number.  For this to work, wouldn't we want either:

s:=setDim("Length",7)    or   w:=setDim("Length",7)
                                             s:=w

> it will need to first 
> coerce 7 to FPSUnitSystem(PositiveInteger) WITHOUT knowing its dimension,
> then coerce that to FPSUnitSystem(S), without knowing the dimension ---
> which requires S to have PositiveInteger as a subdomain, then assign
> whatever property s has (its dimension and unit at the time) to 7, and
> finally assigning the fully formed object (Rep for 7 [ft]) to the
> identifier s of type FPSUnitSystem(S). Now of course, the more direct and
> intuitive way is simply to change the value field in the Rep for s to 7.
> But HOW is the Interpreter to know that via a simple, universally coded
> assignment?

I may have misstated the problem.  For the case of numbers, I do not expect 
the above "magical" intuition about a number.  I was referring to the case of 
variables specifically.  Here's the scenario:

I have the equation x(t) := x0+v0*t+1/2*a*t^2 which I want to define with 
dimensional information.  To do this, I need to assign dimensions to each of 
the components in this equation.  What I would LIKE to do is something 
similar to the following:

(1) -> setDim("Length",x0)
(2) -> setDim("Velocity",v0)
(3) -> setDim("Time",t)
(4) -> setDim("Acceleration",a)

Then, if I want to assign 7 meters to x0, I would do the following:

(5) -> x0 := setDimUnit("Length","m",7)

This would do the following:

1.  Create a temporary dimensional object using 7, m, and Length
2.  Verify that m and Length are a legal paring in the temporary object
3.  Check if x0 is associated with a dimension.   If not, proceed to assign it 
the full contents of the temporary dimensional object.  If it does, as in 
this case, check that the dimension of x0 matches the dimension of the 
temporary object.  If it does not, return an error.  If it does, assign the 
x0 dimensional object the specific unit and amount (7).  

Generating plots of dimensional quantities will be interesting, but that's a 
bit down the road at the moment.  Does the above make sense?

> So to help the Interpreter, or indeed, to avoid having to modify the
> interpreter to make it smarter -- such modification will add so much
> inefficiency to ordinary assignment that it is not advisable in any
> case---we can design functions to do the more intuitive thing:
>
> (2') ->   setValue(s, 7)
>
> but of course this is not as intuitive for the user as (2)! However, it is
> actually quite uniform and similar to setDim or setUnit.
>
> The same means that a statement like:
>
> (3) ->  s:= s + 7
>
> would involve the same type of coercions as for (2). If instead,
>
> (3') -> setValue(s, s+7)
>
> then the function setValue *may* be taught to first retract the s in s+7 to
> S, add 7 to it in the domain S, then put this in the value-field of Rep of
> s. I say *may*, because the general situation would require a parser!

I don't think we want the "value" part of a dimension+nondim object to be 
workable as an individual object at all.  Adding 7 to it shouldn't be legal.

> So there is still a big design problem to think about: how to make
> subsequent computations intuitive without writing a parser for the package!
> The following way perhaps works (effectively asking the user to do the
> parsing):
>
>     setValue(s, retract(s)+7)
>
> (any implementation, in Axiom, will require conditional implementation,
> testing that S can do arithmetic with PositiveInteger or Integer), and if s
> is not just a symbol, a retractIfCan(s) may be more appropriate.

I vote for just avoiding the whole situation by not dealing in anything but 
unit/dimensional quantities when dimensions are in play.  It's a bit sad to 
lose the convenience of being able to say s:=7*m but you finally convinced 
me.

> > That's implicit in issuing the setDim command in the first
> > place.  In a software design sense I would think that doing otherwise
> > would violate the Principle of Least Surprise.
>
> You should know that Axiom is full of surprises because it is not easy to
> understand the implications of a strongly typed language.

Oh, I know :-).  But we've got to try to meet our users at least part way or 
we won't have many users!  We need to stay correct, but what I'm trying to do 
is make things as convenient as possible while remaining correct.

> > I would rather use some command
> > like stripDim("x") to get at the object "x" that doesn't have a dimension
> > associated with it if for some reason I want it, because once I so setDim
> > command it's assumed (at least by me) that I don't WANT to have x work as
> > an object without dimension anymore.  Obviously this doesn't work for
> > setDim("Length",4), since 4 is not a variable, but in the case of x it
> > should (at least IMHO) work.
>
> The problem is with subsequent arithmetic (not to mention the grander
> vector calculus) that involves quantities whose dimensions or units have
> not been defined, whether they be numbers or expressions.

I don't think we want to combine dimension/unit quantities with quantities 
whose dimensions or units have not been defined - are there scenarios where 
this is needed?

> In some sense, 
> this is again forcing the user to know what he is doing, to think of
> dimensions and units in every step of the computation. But users used to
> the sloppy way will find this very frustrating.  In the simple example
> above, s+7, the dimension and unit of 7 are not given. Is it good idea to
> "help" the user and "guess" that 7 should have the same dimension and unit
> as s? If so, wouldn't that allow a sloppy user to add s [ft] to 7 [in] and
> get (s+7) [ft]?

No, we shouldn't do that.  That wasn't what I was advocating - sorry if I gave 
that impression.

> I think we should not provide such automation: two reasons: simplifies
> implementation, and forces the user to be specific on dimensions and units.
> So a user MUST declare, using setDimUnit, EVERY quantity he wants to
> compute using a unit system. If all inputs to an expression are declared
> ahead of time, the arithmetic will take place in the unit system domain and
> parsing done by the Interpreter, without the use of setValue.

Right.

> It would be desirable to allow:
>
>     s:= setDimUnit("Length","in",'s)
>     t:= s + 7 [ft]
>
> to give a value of s+84 [in] for t. But this involves modifying the
> interpreter and the language! ([ft] may be a list containing a variable
> ft). Here is an argument for using variables for units, because there would
> have been created conversion (rewrite) rule ft == 12 in, which would be
> applied automatically.

I figured this scenario wouldn't work as I began coming to grips with your 
design - I don't think the above is possible, sadly.  It would have to be 
done as follows, given the best setDimUnit definition I can see as being 
workable:

     s:= setDimUnit("Length","in",s)
     t:= s + setDimUnit("Length","ft",7)

This would be legal, but the units of t, unless previously set, would be 
determined in this case by what the global default is.  (Probably meters ;-)

> > Maybe we can flag this behavior so that if a hard core
> > Axiom user prefers the behavior which is a consequence of strict
> > interaction with a strong type system and doesn't want to special case
> > variable behavior Axiom won't do the extra voodoo?
>
> In general, I don't like (personal bias) a program to provide automatic
> help (such as checking grammar or spelling or indentations in MS Word!). It
> is far better to have fewer options and the system behaves consistently.

Well, I guess I'm in the middle - I like spell checking, but I don't like 
grammer checking (particularly since grammer checking can't be defined 
programatically, IIRC!).

> > What if we internally use
> > some symbol other than the one given in setDim("Length",a) and have a
> > rule for displaying a variable with dimension that it shouldn't show the
> > internal symbol but a instead.  Something like:
> >
> > setDim("Length",a) -> creates some object containing [nondim_a,Length]
> > and assigns this to the name a, just like a := <object> would.  Then we
> > create some kind of display rule that rather that variables of the form
> > nondim_* be displayed as * in output?  This would preserve the Axiom type
> > behavior while hiding the messy details and avoiding violating user
> > expection of variable interaction.  This could probably be turned off as
> > well if a hardcore Axiom user wants normal behavior.
>
> I suppose the above is obsolete now?

I think you addressed that problem in the previous email, but we'll see when 
we get to coding :-).


\start
Date: Thu, 08 Sep 2005 10:26:33 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

C Y wrote:
> 
> On Thursday 08 September 2005 01:39 am, William Sit wrote:

> > As I show in my earlier reply, we can do setDim("dim",s) but we still need
> > to assign it to s when s is a Symbol. There is a catch: since there are
> > many domains that include symbols, it won't be clear where s belongs.
> 
> I'm not following - are you thinking that we won't know what type "s" is
> inside the object containing both dimension and the nondimensional quantity?
> Well, what about if we had just typed "s" on the input line without saying
> anything about where it belongs? In my copy of Axiom this gives:
> 
>    (2)  s
>                                                              Type: Variable s
> 
> I'm thinking we can assume whatever the "default" assumption would have been
> on the command line - just remember that, bump s temporarily to a symbol, and
> then return it to being a Variable (in this case.)  Or do you mean that s
> will need to wind up in a UnitSystem?  This isn't obvious to me - Dimension
> is more general than any one UnitSystem.  Maybe we need a domain for
> dimension-without-specific-unit objects?

No, I don't think so. So far, everything works even though users will be forced
to declare dimension and unit for each quantity (as we agree below). However,
the above is not the same thing. If a user is comfortable with defaults, that
is, undefined identifiers are of type Symbol (techically, Variable(s) for Symbol
s), and any other operations will be promoted to a higher domain, usually POLY
INT, then that is fine. But if someone wants to work with say S := EXPR INT and
uses SIUNitSystem(S), then he will have to package call the setDimUnit for an
undefined identifier s.  In principle, we do NOT know the type of undefined
identifiers. The Interpreter assumes we are using Symbol. This won't be assumed
in the compiler.
 
[snipped]
> Wait - why do we want s:=7 to work in that case?  I would expect that to fail
> - 7 is a dimensionless number.  For this to work, wouldn't we want either:
> 
> s:=setDim("Length",7)    or   w:=setDim("Length",7)
[snipped]

> I have the equation x(t) := x0+v0*t+1/2*a*t^2 which I want to define with
> dimensional information.  To do this, I need to assign dimensions to each of
> the components in this equation.  What I would LIKE to do is something
> similar to the following:
> 
> (1) -> setDim("Length",x0)
> (2) -> setDim("Velocity",v0)
> (3) -> setDim("Time",t)
> (4) -> setDim("Acceleration",a)
> 
> Then, if I want to assign 7 meters to x0, I would do the following:
> 
> (5) -> x0 := setDimUnit("Length","m",7)
> 
> This would do the following:
> 
> 1.  Create a temporary dimensional object using 7, m, and Length
> 2.  Verify that m and Length are a legal paring in the temporary object
> 3.  Check if x0 is associated with a dimension.   If not, proceed to assign it
> the full contents of the temporary dimensional object.  If it does, as in
> this case, check that the dimension of x0 matches the dimension of the
> temporary object.  If it does not, return an error.  If it does, assign the
> x0 dimensional object the specific unit and amount (7).

Perfect scenario.
 
> Generating plots of dimensional quantities will be interesting, but that's a
> bit down the road at the moment.  Does the above make sense?

I may think a bit of the last action though: whether we allow an identifier to
change its dimension. Say, what if I decide to "recycle" an identifier? Note
that x0 in (5) has the same TYPE as the rhs BEFORE assignment. It should be
legal, perhaps with a warning message, if the target dimension and unit do not
match those of x0.
 
 
> I don't think we want the "value" part of a dimension+nondim object to be
> workable as an individual object at all.  Adding 7 to it shouldn't be legal.

Certainly, the setValue function is still needed, but you may not want to export
it. In the example, I was pushing the "convenience" feature you have been
advocating. I am glad you don't want to push that far!

> I vote for just avoiding the whole situation by not dealing in anything but
> unit/dimensional quantities when dimensions are in play.  It's a bit sad to
> lose the convenience of being able to say s:=7*m but you finally convinced
> me.

Great. May be a future project is to modify the interpreter to allow s:= 7 [ft]
as syntactic sugar, once the foundation is done, correctly.

> We need to stay correct, but what I'm trying to do
> is make things as convenient as possible while remaining correct.

A very good ideal.


> I don't think we want to combine dimension/unit quantities with quantities
> whose dimensions or units have not been defined - are there scenarios where
> this is needed?

Not really, except for sloppy users.
 
> > Is it good idea to
> > "help" the user and "guess" that 7 should have the same dimension and unit
> > as s? If so, wouldn't that allow a sloppy user to add s [ft] to 7 [in] and
> > get (s+7) [ft]?
> 
> No, we shouldn't do that.  That wasn't what I was advocating - sorry if I gave
> that impression.

You did lead me into thinking about such scenario :-). But I am all for what you
now decide.
 
> > I think we should not provide such automation: two reasons: simplifies
> > implementation, and forces the user to be specific on dimensions and units.
> > So a user MUST declare, using setDimUnit, EVERY quantity he wants to
> > compute using a unit system. If all inputs to an expression are declared
> > ahead of time, the arithmetic will take place in the unit system domain and
> > parsing done by the Interpreter, without the use of setValue.
> 
> Right.
 
> > It would be desirable to allow:
> >
> >     s:= setDimUnit("Length","in",'s)
> >     t:= s + 7 [ft]
> >
> > to give a value of s+84 [in] for t. But this involves modifying the
> > interpreter and the language! ([ft] may be a list containing a variable
> > ft). Here is an argument for using variables for units, because there would
> > have been created conversion (rewrite) rule ft == 12 in, which would be
> > applied automatically.
 
> I figured this scenario wouldn't work as I began coming to grips with your
> design - I don't think the above is possible, sadly.  

Yes, that would have made implementation much easier in the conversion part. (I
guess I have been "poisoned" by my Mathematica experience in implementing units
conversions).

> It would have to be
> done as follows, given the best setDimUnit definition I can see as being
> workable:
> 
>      s:= setDimUnit("Length","in",s)
>      t:= s + setDimUnit("Length","ft",7)
> 
> This would be legal, but the units of t, unless previously set, would be
> determined in this case by what the global default is.  (Probably meters ;-)

I think you have understood the design quite well.
 
> > > Maybe we can flag this behavior so that if a hard core
> > > Axiom user prefers the behavior which is a consequence of strict
> > > interaction with a strong type system and doesn't want to special case
> > > variable behavior Axiom won't do the extra voodoo?

[snipped] 

> > I suppose the above is obsolete now?
> 
> I think you addressed that problem in the previous email, but we'll see when
> we get to coding :-).
> 
Yes, everything depends on how to coding goes! (especially when it comes to the
compiler). 

\start
Date: Thu, 8 Sep 2005 08:57:03 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

--- William Sit wrote:
>
> No, I don't think so. So far, everything works even though users will
> be force to declare dimension and unit for each quantity (as we 
> agree below). However, the above is not the same thing. If a user is
> comfortable with defaults, that is, undefined identifiers are of 
> type Symbol (techically, Variable(s) for Symbol s), and any other 
> operations will be promoted to a higher domain, usually POLY
> INT, then that is fine. But if someone wants to work with say S :> EXPR INT and uses SIUNitSystem(S), then he will have to package 
> call the setDimUnit for an undefined identifier s.

Ho boy, this is where my limited understanding of strong typing rears
its ugly head.  I think we need to have sensible defaults for this (I'm
definitly opposed to forcing the user to think about such things unless
they choose to) but I agree we need to allow for more advanced uses. 
Ugh.  That will take some thought.
  
> In principle, we do NOT know the type of undefined
> identifiers. The Interpreter assumes we are using Symbol. This won't
> be assumed in the compiler.

OK, so we need to explicitly make some assumption in the definition of
the function I guess - so long as it doesn't make its way into require
default user syntax ;-).

> > Generating plots of dimensional quantities will be interesting, but
> > that's a bit down the road at the moment.  Does the above make 
> > sense?
> 
> I may think a bit of the last action though: whether we allow an
> identifier to change its dimension. Say, what if I decide to
> "recycle" an identifier? 

Maybe that's where my "unSetDim" idea can come in?  We need a way to
undo what we do, but I don't think we want it to be automatic.

> Note that x0 in (5) has the same TYPE as the rhs BEFORE assignment.
> It should be legal, perhaps with a warning message, if the target
> dimension and unit do not match those of x0.

I think I disagree, if I understand you here - one of the primary
benefits I see of having generic dimensions without units associated
with variables is to enforce matching dimensions between assignments
and variables being assigned (this is another check on correctness, and
a useful one IMHO).  For example, if someone solves for a Moment of
Force quantity and tries to assign it to a variable defined to have
dimension Work, on the grounds that they have the same reduced
dimensions, Axiom can (and should, IMHO) stop them cold.  Which also
raises the point that we need to add a way to define a variable such
that it will accept any dimension who's reduced dimensions match,
proceeding on with those reduced dimensions.  Would it be possible (or
rather, interesting and useful) to have the state vector preserve the
history of derived -> reduced conversions?  Sort of a pedigree of where
the given unit/dimension definition came from, conversion wise?
  
> Certainly, the setValue function is still needed, but you may not
> want to export it. In the example, I was pushing the "convenience" 
> feature you have been advocating. I am glad you don't want to push 
> that far!

Nope, I know there are limits to convenience :-).  Just want to do the
best I can to ensure this sucker gets used, but if I didn't think
correctness was priority #1 I wouldn't be interested in doing this in
Axiom ;-).  At the user level, setValue should not be an option -
you're right, such actions are needed for manipulation at low levels
INSIDE the package, now that I stop and think about it - but they do
need to be very strictly internal.

> Great. May be a future project is to modify the interpreter to allow
> s:= 7 [ft] as syntactic sugar, once the foundation is done, 
> correctly.

That's a very good idea, but definitely lower priority at the moment.
 
> > We need to stay correct, but what I'm trying to do
> > is make things as convenient as possible while remaining correct.
> 
> A very good ideal.

Well, I think the lesson of the commercial Axiom is that you need to
sell correctness and be as friendly as possible about it - otherwise
you starve from lack of users.  Axiom is open source now, of course, so
we don't have the financial problems, but we still need users to remain
(or become) a living, breathing project.  Be correct, but remember the
human side of the equation when possible, too.

> Yes, that would have made implementation much easier in the 
> conversion part. (I guess I have been "poisoned" by my 
> Mathematica experience in implementing units conversions).  

Well, Maxima did the same to me ;-).  I guess it's true what they say,
assume you'll have to try to implement something at least once before
you can properly define the problem.

> Yes, everything depends on how to coding goes! (especially when it 
> comes to the compiler). 

Ah, point.  So in general, it is not always useful to try something in
the interpreter as opposed to coding it and compiling it?  In Maxima,
generally speaking, it was all the same - I take it that's not the case
here?  Eeep.

\start
Date: 08 Sep 2005 23:07:44 -0400
From: Camm Maguire
To: Tim Daly
Subject: Re: Axiom sources for Debian release with 2.6.7
Cc: Allen Rouse

Greetings!

Tim Daly writes:

> Camm,
> 
> If I do 
> 
> echo 0 > /proc/sys/kernel/randomize_va_space
> 
> then Axiom builds on FC4
> 

Great!  But presumably this needs doing as root.  The earlier
randomized sbrk had a similar system-wide disabling shell command
using the /proc filesystem if I recall.  But there was also a
per-process user-level syscall, which was used in the 'setarch'
utility and incoporated directly into GCL's main routine, that
accomplished the same thing.  It would be great if we could follow
suit here as well.  The earlier call was a 'personality set'.  Do you
have any idea of an analogous syscall here?

\start
Date: Thu, 08 Sep 2005 22:21:57 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] compilation of axiom-Sept2005

I tried to build axiom-Sept2005 from sources on slackware-current but its compilation stops with an error:

make[3]: Entering directory `/usr/local/src/axiom/src/boot'
44 invoking make in /usr/local/src/axiom/src/boot with parms:
SYS= linux
LSP= /usr/local/src/axiom/lsp
PART= cprogs
SPAD= /usr/local/src/axiom/mnt/linux
SRC= /usr/local/src/axiom/src
INT= /usr/local/src/axiom/int
OBJ= /usr/local/src/axiom/obj
MNT= /usr/local/src/axiom/mnt
make[3]: *** [/usr/local/src/axiom/obj/linux/bin/bootsys] Error 255
make[3]: Leaving directory `/usr/local/src/axiom/src/boot'
make[2]: *** [bootdir] Error 2
make[2]: Leaving directory `/usr/local/src/axiom/src'
make[1]: *** [srcdir] Error 2
make[1]: Leaving directory `/usr/local/src/axiom'
make: *** [all] Error 2

\start
Date: Thu, 08 Sep 2005 23:23:14 -0500
From: MathAction (root)
To: MathAction
Subject: [AxiomDownload] compilation of axiom-Sept2005

bootsys is a lisp image.
can you start the bootsys image by hand?

/usr/local/src/axiom/obj/linux/bin/bootsys

\start
Date: Fri, 09 Sep 2005 03:34:02 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

C Y wrote:
> 
> --- William Sit wrote:

> > I may think a bit of the last action though: whether we allow an
> > identifier to change its dimension. Say, what if I decide to
> > "recycle" an identifier?
> 
> Maybe that's where my "unSetDim" idea can come in?  We need a way to
> undo what we do, but I don't think we want it to be automatic.

I'll leave that up to you. Enforcing a sticky dimension to an identifier is
similar to enforcing type to an identifier, so it is similating dimensions as
types.
 
> > Note that x0 in (5) has the same TYPE as the rhs BEFORE assignment.
> > It should be legal, perhaps with a warning message, if the target
> > dimension and unit do not match those of x0.
> 
> I think I disagree, if I understand you here - one of the primary
> benefits I see of having generic dimensions without units associated
> with variables is to enforce matching dimensions between assignments
> and variables being assigned (this is another check on correctness, and
> a useful one IMHO).  

Sure. The problem is not that critical in a line by line interpreter
environment. If an assignment is illegal as above but simply because the user
forgets to unSetDim, he gets an error message and he can easily correct that.
However, if the user is writing s script (.input file), and the running of the
script stops because of such an "error" (which is not an error to the user
because he thinks he is just recycling identifiers), it may cost him a lot of
recomputation time. On the other hand, a warning would alert the user, but
without aborting. (I really hate it when I back up a bunch of files, and one of
them was in use by the OS, and the OS stops; I have no way, except to check file
by file, how to restart or continue.) I think the decision of whether we should
stop or just warn must be weighted by whether our intended users are
knowledgeable experts or amateur beginners (like students). I would opt for
warning, because it helps the advanced users, and at the same time, to an
interactive line by line user, it makes no difference whether the message is
"this is illegal" or "warning: dimension error";  in both cases, he is stopped.

> For example, if someone solves for a Moment of
> Force quantity and tries to assign it to a variable defined to have
> dimension Work, on the grounds that they have the same reduced
> dimensions, Axiom can (and should, IMHO) stop them cold.  Which also
> raises the point that we need to add a way to define a variable such
> that it will accept any dimension who's reduced dimensions match,
> proceeding on with those reduced dimensions.

No matter how you try, there is no way to guarantee correct verification of
homogeneity of dimension in an equation or expression. The best we can do is the
guarantee that for reduced dimension because the only algorithm to do the
verification is to reduce all dimensions to the basic dimensions. I had
suggested earlier that the Rep include the reduced dimension to make such
checking more efficient. Then the dimension can be as fancy as the user wants. 

This brings another design issue into sight: Dimension should be a group
(mathematical term) generated by the basic dimensions, but allowing the user to
define arbitrarily any derived units. We need to allow this since a user may
want to call "Mass^2 Time/Length^3" by the name "foo". With the current concept
of the Dimension domain as a Union of Strings, the set of dimensions is fixed
and not extendable to include something not anticipated.

  foo:PhysicalDimension:= Mass^2*Time*Length^(-3)
  setDim(foo, s)

Making Dimension a free abelian group, written multiplicatively, based
on some basic dimensions as generators (these may differ depending on
expert area) may avoid the "Union" problem. We can now easily have a
DimensionCategory. A corresponding UnitsCategory will also be a
subcategory of the free abelian group category (FreeAbelianGroup is a
category in Axiom, this will save a lot of implementation work since
all the functions (equality, and reduction, for example) are built in
already! We can have a free abelian group on ANY set.

We need more discussion on this, on how this affects the functions.

>  Would it be possible (or
> rather, interesting and useful) to have the state vector preserve the
> history of derived -> reduced conversions?  Sort of a pedigree of where
> the given unit/dimension definition came from, conversion wise?

This can be done in the Rep of each quantity with a unit.
 
[snipped]

> > Yes, everything depends on how the coding goes! (especially when it
> > comes to the compiler).
> 
> Ah, point.  So in general, it is not always useful to try something in
> the interpreter as opposed to coding it and compiling it?  

Yes, code that work in the interpreter does not work (usually) in the compiler
because the interpreter is "intelligent". However, it is still a good idea to
first use interpreter code to test some implementation of functions. Most of the
problems are you have to tell the compiler where to find the functions
(coercion, package call). All abbreviations must also be defined for the
compiler.

\start
Date: Fri, 9 Sep 2005 06:12:47 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

Oh, while I remember - would it workable to adopt the following
notation for reduced dimensions?

Say we have a dimension Force, and when we reduce it we have
Mass*Length/Time^2  (I'd use the work example but I'm running late.) 
Say we want those to be reduced dimensions - can we use this notation
or are Axiom's output forms not that flexible:

Mass[r]*Length[r]/Time[r]^2

I don't know how we want to denote this on units - my thinking at the
moment is that reduced dimensions don't have reduced units, but that's
just off the cuff.

\start
Date: Fri, 9 Sep 2005 05:55:19 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

--- William Sit wrote:
> 
> 
> C Y wrote:
> > 
> > --- William Sit wrote:
> 
> > > I may think a bit of the last action though: whether we allow an
> > > identifier to change its dimension. Say, what if I decide to
> > > "recycle" an identifier?
> > 
> > Maybe that's where my "unSetDim" idea can come in?  We need a way
> > to undo what we do, but I don't think we want it to be automatic.
> 
> I'll leave that up to you. Enforcing a sticky dimension to an
> identifier is similar to enforcing type to an identifier, so it
> is similating dimensions as types.

Hmm - is that good or bad?

> > I think I disagree, if I understand you here - one of the primary
> > benefits I see of having generic dimensions without units
> > associated with variables is to enforce matching dimensions
> > between assignments and variables being assigned (this is another
> > check on correctness, and a useful one IMHO).  
> 
> Sure. The problem is not that critical in a line by line interpreter
> environment. If an assignment is illegal as above but simply because
> the user forgets to unSetDim, he gets an error message and he can
> easily correct that. However, if the user is writing s script 
> (.input file), and the running of the script stops because of such 
> an "error" (which is not an error to the user because he thinks he 
> is just recycling identifiers), it may cost him a lot of
> recomputation time. On the other hand, a warning would alert the
> user, but without aborting. 

A good point.

> (I really hate it when I back up a bunch of files, and one of them
> was in use by the OS, and the OS stops; I have no way, except to
> check file by file, how to restart or continue.) I think the 
> decision of whether we should stop or just warn must be weighted by 
> whether our intended users are knowledgeable experts or amateur 
> beginners (like students). I would opt for warning, because it 
> helps the advanced users, and at the same time, to an
> interactive line by line user, it makes no difference whether the
> message is "this is illegal" or "warning: dimension error";  
> in both cases, he is stopped.

Except in the case of a student, they might just ignore the warning,
accept the overwrite, and proceed with the calculation hoping they can
just ignore the problem and get an answer that "looks" right.

Hmm.  How about this - by default we require an explicit unSetDim, but
we provide a mechanism for advanced users whereby they can read in a
script with the error mechanism reduced to a warning.  An advanced user
will be able to find and use this, and by default we preserve Axiom's
tough-guy rep ;-).

> No matter how you try, there is no way to guarantee correct
> verification of homogeneity of dimension in an equation or 
> expression. The best we can do is the guarantee that for reduced
> dimension because the only algorithm to do the verification is to 
> reduce all dimensions to the basic dimensions.

I'm working on an idea or two about expanding that a bit, but basically
it looks like you're right once we substitute for any derived
dimensions.  I'm trying right now to straighten out the rules for such
things in my head via writing them down ;-).

> I had suggested earlier that the Rep include the reduced dimension
> to make such checking more efficient. Then the dimension can be as 
> fancy as the user wants. 

Agree wholeheartedly now :-).

> This brings another design issue into sight: Dimension should be a
> group (mathematical term) generated by the basic dimensions, but
> allowing the user to define arbitrarily any derived units. We need
> to allow this since a user may want to call "Mass^2 Time/Length^3" 
> by the name "foo". With the current conceptof the Dimension domain 
> as a Union of Strings, the set of dimensions is fixed
> and not extendable to include something not anticipated.
> 
>   foo:PhysicalDimension:= Mass^2*Time*Length^(-3)
>   setDim(foo, s)
> 
> Making Dimension a free abelian group, written multiplicatively,
> based on some basic dimensions as generators (these may differ 
> depending on expert area) may avoid the "Union" problem. We can now 
> easily have a DimensionCategory. A corresponding UnitsCategory will 
> also be a subcategory of the free abelian group category 
> (FreeAbelianGroup is a category in Axiom, this will save a lot of 
> implementation work since all the functions (equality, and 
> reduction, for example) are built in already! We can have a free 
> abelian group on ANY set. 

Well, I'll be able to comment better once I know what a free abelian
group is/means, but in general it sounds like it's a good solution.
 
> We need more discussion on this, on how this affects the functions.

OK - I'll try and qualify myself - where are the good docs on free
abelian groups?

> >  Would it be possible (or
> > rather, interesting and useful) to have the state vector preserve
> the
> > history of derived -> reduced conversions?  Sort of a pedigree of
> where
> > the given unit/dimension definition came from, conversion wise?
> 
> This can be done in the Rep of each quantity with a unit.

OK, I think this might be useful later on.  Once I get to writing up
the Axiom level represenation of quantities with dimensions/units I'll
try and think some more about this.

> > So in general, it is not always useful to try something in
> > the interpreter as opposed to coding it and compiling it?  
> 
> Yes, code that work in the interpreter does not work (usually) in 
> the compiler because the interpreter is "intelligent". However, it 
> is still a good idea to first use interpreter code to test some 
> implementation of functions. Most of the problems are you have to 
> tell the compiler where to find the functions (coercion, package
> call). All abbreviations must also be defined for the compiler.

\start
Date: Fri, 09 Sep 2005 09:42:20 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

C Y wrote:
> 
> --- William Sit wrote:
> > I'll leave that up to you. Enforcing a sticky dimension to an
> > identifier is similar to enforcing type to an identifier, so it
> > is similating dimensions as types.
> 
> Hmm - is that good or bad?

Good for naive users and maybe even for expert users. But just like types are
rigid, sticky dimension will also be rigid. There are users who prefer more
loose settings (that's one reason why Mathematica or Maple is popular).

[snipped]

> Except in the case of a student, they might just ignore the warning,
> accept the overwrite, and proceed with the calculation hoping they can
> just ignore the problem and get an answer that "looks" right.
> 
> Hmm.  How about this - by default we require an explicit unSetDim, but
> we provide a mechanism for advanced users whereby they can read in a
> script with the error mechanism reduced to a warning.  An advanced user
> will be able to find and use this, and by default we preserve Axiom's
> tough-guy rep ;-).

As long as you know how to do it. Axiom interpreter has three settings. See )set
user. That may provide the switch. I don't know how that works.

> > No matter how you try, there is no way to guarantee correct
> > verification of homogeneity of dimension in an equation or
> > expression. The best we can do is the guarantee that for reduced
> > dimension because the only algorithm to do the verification is to
> > reduce all dimensions to the basic dimensions.
> 
> I'm working on an idea or two about expanding that a bit, but basically
> it looks like you're right once we substitute for any derived
> dimensions.  I'm trying right now to straighten out the rules for such
> things in my head via writing them down ;-).

Speaking of "substitute", if Dimension is modeled by a free abelian group (maybe
not even free, since it can be factored by using derived dimension definitions
(relations); the more I toyed with this idea, the more promising that looks),
then units can be obtained by a substitution. We may be able to let the rules be
user add-ons. Again, need more thoughts on this. 

> > I had suggested earlier that the Rep include the reduced dimension
> > to make such checking more efficient. Then the dimension can be as
> > fancy as the user wants.
> 
> Agree wholeheartedly now :-).


The reduced dimension would be the default representation in Dimension if it is
modelled by a group. The only way to "recover" or retain the physical dimension
may be in the Rep of the UnitSystem domain itself, for each identifier.

So the group model will provide all the computation to get reduced dimension and
also equality of dimension. The Rep retains both dimension and reduced
dimension.



 
> > This brings another design issue into sight: Dimension should be a
> > group (mathematical term) generated by the basic dimensions, but
> > allowing the user to define arbitrarily any derived units. We need
> > to allow this since a user may want to call "Mass^2 Time/Length^3"
> > by the name "foo". With the current conceptof the Dimension domain
> > as a Union of Strings, the set of dimensions is fixed
> > and not extendable to include something not anticipated.
> >
> >   foo:PhysicalDimension:= Mass^2*Time*Length^(-3)
> >   setDim(foo, s)
> >
> > Making Dimension a free abelian group, written multiplicatively,
> > based on some basic dimensions as generators (these may differ
> > depending on expert area) may avoid the "Union" problem. We can now
> > easily have a DimensionCategory. A corresponding UnitsCategory will
> > also be a subcategory of the free abelian group category
> > (FreeAbelianGroup is a category in Axiom, this will save a lot of
> > implementation work since all the functions (equality, and
> > reduction, for example) are built in already! We can have a free
> > abelian group on ANY set.
> 
> Well, I'll be able to comment better once I know what a free abelian
> group is/means, but in general it sounds like it's a good solution.

Well actually, the Mass, etc on the foo definition probably should have been
quoted as strings, but they are NOT strings anymore, but are generators for the
group for the dimension domain.
 
> > We need more discussion on this, on how this affects the functions.
> 
> OK - I'll try and qualify myself - where are the good docs on free
> abelian groups?

An abelian group is simply a set with a commutative multiplicative (but usually
written additively) binary operation and every element has a multiplicative
inverse. It is free if there are no relations among the generators. As mentioned
earlier, maybe we should actually allow non-free abelian group to model
Dimension domains. We will need to construct quotient objects in the abelian
group category. Any introductory modern algebra book will have enough coverage
for this project. Or just google.
 
\start
Date: Fri, 09 Sep 2005 09:48:33 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

C Y wrote:
> 
> Oh, while I remember - would it workable to adopt the following
> notation for reduced dimensions?
> 
> Say we have a dimension Force, and when we reduce it we have
> Mass*Length/Time^2  (I'd use the work example but I'm running late.)
> Say we want those to be reduced dimensions - can we use this notation
> or are Axiom's output forms not that flexible:
> 
> Mass[r]*Length[r]/Time[r]^2
> 
> I don't know how we want to denote this on units - my thinking at the
> moment is that reduced dimensions don't have reduced units, but that's
> just off the cuff.
> 
No [IMHO]. This adds something unconventional and complicates things. There
should be no difference in the output form. It should be quite obvious that a
dimension or unit output is reduced or not. Plus, there are dimensions whose
reduced dimension is identical to the dimension. The user can also explicitly
ask for a reduced dimension through functions such as reduce(identifier).
Reduced dimension can have reduced units (why not)?

\start
Date: Fri, 09 Sep 2005 16:27:05 +0200
From: Gregory Vanuxem
To: William Sit
Subject: Re: Unit package proposals and questions

Hi,

Le vendredi 09 septembre 2005 =E0 09:42 -0400, William Sit a =E9crit :
>
> C Y wrote:
> >
> > --- William Sit wrote:
> > > I'll leave that up to you. Enforcing a sticky dimension to an
> > > identifier is similar to enforcing type to an identifier, so it
> > > is similating dimensions as types.
> >
> > Hmm - is that good or bad?
>
> Good for naive users and maybe even for expert users. But just like types are
> rigid, sticky dimension will also be rigid. There are users who prefer more
> loose settings (that's one reason why Mathematica or Maple is popular).
>
> [snipped]
>
> > Except in the case of a student, they might just ignore the warning,
> > accept the overwrite, and proceed with the calculation hoping they can
> > just ignore the problem and get an answer that "looks" right.
> >
> > Hmm.  How about this - by default we require an explicit unSetDim, but
> > we provide a mechanism for advanced users whereby they can read in a
> > script with the error mechanism reduced to a warning.  An advanced user
> > will be able to find and use this, and by default we preserve Axiom's
> > tough-guy rep ;-).
>
> As long as you know how to do it. Axiom interpreter has three settings. See )set
> user. That may provide the switch. I don't know how that works.
>
> > > No matter how you try, there is no way to guarantee correct
> > > verification of homogeneity of dimension in an equation or
> > > expression. The best we can do is the guarantee that for reduced
> > > dimension because the only algorithm to do the verification is to
> > > reduce all dimensions to the basic dimensions.
> >
> > I'm working on an idea or two about expanding that a bit, but basically
> > it looks like you're right once we substitute for any derived
> > dimensions.  I'm trying right now to straighten out the rules for such
> > things in my head via writing them down ;-).
>
> Speaking of "substitute", if Dimension is modeled by a free abelian group (maybe
> not even free, since it can be factored by using derived dimension definitions
> (relations); the more I toyed with this idea, the more promising that looks),
> then units can be obtained by a substitution. We may be able to let the rules be
> user add-ons. Again, need more thoughts on this.
>
> > > I had suggested earlier that the Rep include the reduced dimension
> > > to make such checking more efficient. Then the dimension can be as
> > > fancy as the user wants.
> >
> > Agree wholeheartedly now :-).
>
>
> The reduced dimension would be the default representation in Dimension if it is
> modelled by a group. The only way to "recover" or retain the physical dimension
> may be in the Rep of the UnitSystem domain itself, for each identifier.
>
> So the group model will provide all the computation to get reduced dimension and
> also equality of dimension. The Rep retains both dimension and reduced
> dimension.
>
>
>
> 
> > > This brings another design issue into sight: Dimension should be a
> > > group (mathematical term) generated by the basic dimensions, but
> > > allowing the user to define arbitrarily any derived units. We need
> > > to allow this since a user may want to call "Mass^2 Time/Length^3"
> > > by the name "foo". With the current conceptof the Dimension domain
> > > as a Union of Strings, the set of dimensions is fixed
> > > and not extendable to include something not anticipated.
> > >
> > >   foo:PhysicalDimension:= Mass^2*Time*Length^(-3)
> > >   setDim(foo, s)
> > >
> > > Making Dimension a free abelian group, written multiplicatively,
> > > based on some basic dimensions as generators (these may differ
> > > depending on expert area) may avoid the "Union" problem. We can now
> > > easily have a DimensionCategory. A corresponding UnitsCategory will
> > > also be a subcategory of the free abelian group category
> > > (FreeAbelianGroup is a category in Axiom, this will save a lot of
> > > implementation work since all the functions (equality, and
> > > reduction, for example) are built in already! We can have a free
> > > abelian group on ANY set.
> >
> > Well, I'll be able to comment better once I know what a free abelian
> > group is/means, but in general it sounds like it's a good solution.
>
> Well actually, the Mass, etc on the foo definition probably should have been
> quoted as strings, but they are NOT strings anymore, but are generators for the
> group for the dimension domain.
> 
> > > We need more discussion on this, on how this affects the functions.
> >
> > OK - I'll try and qualify myself - where are the good docs on free
> > abelian groups?
>
> An abelian group is simply a set with a commutative multiplicative (but usually
> written additively) binary operation and every element has a multiplicative
> inverse. It is free if there are no relations among the generators. As mentioned
> earlier, maybe we should actually allow non-free abelian group to model
> Dimension domains. We will need to construct quotient objects in the abelian
> group category. Any introductory modern algebra book will have enough coverage
> for this project. Or just google.

You can have some introductory materials
in "Elements of Abstract and Linear Algebra" from E.H. Connell

http://www.math.miami.edu/~ec/book/

or Wikipedia.

\start
Date: Fri, 9 Sep 2005 07:30:37 -0700 (PDT)
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

--- William Sit wrote:
>
> C Y wrote:
> >
> > Mass[r]*Length[r]/Time[r]^2
>  
> No [IMHO]. This adds something unconventional and complicates things.

True, but reduced dimension itself is somewhat unconventional.  We are
dealing with a level of strictness virtually never used in the real
world (at least in my experience) so I'm not surprised normal usage
conventions are breaking down somewhat.  This is actually one of the
things making this so interesting for me :-).  I like getting down to
the roots of things and making it really correct.

Hopefully this could be done with some conditional outputform tweak
based on the Rep, so maybe a system setting to enable or disable this
would be a good idea, assuming I can convince you it's a good idea -
)set ShowReducedDimensions true  or some such.

The reduced dimension flag tells us that these dimensions are the
result of a substitution for some derived dimension, but otherwise we
allow things to proceed as normal - the reduced dimensions of work and
moment of force are the same, even though the derived dimensions
themselves are not.  The implication is that a reduced dimension
differs from a normal dimension in its history, but not in any
functional way, which also implies that its history is somehow
"inherent" in the Rep.  (one of the reasons I am in favor of preserving
the dimensional history of a reduced dimension in its Rep).  Just by
making the distinction, we are stating that there is something about a
reduced dimension compared to a regular dimension that MIGHT matter -
there may be some incompatibility not expressed in the dimensional
representation as it currently exists, although we don't know what. 
Certainly, if I divide work by moment of force, this is a dimensionless
number in terms of reduced dimensions but not in terms of derived
dimensions, and I would be happier if the "dimensionless" number
remembers something about this.  I'll have more details later - I'm
still chewing on this issue.  I might be thinking of reduced dimension
a bit differently than how it was originally defined - I'll have to
look - I'm viewing it as the dimension itself remembering its history,
rather than it being the name for a basic dimension definition of a
derived dimension.  

Hmm, I might be having too much fun thinking about this. Uh oh.

> There should be no difference in the output form. It should be quite
> obvious that a dimension or unit output is reduced or not. Plus, 
> there are dimensions whose reduced dimension is identical to the 
> dimension. The user can also explicitly ask for a reduced dimension 
> through functions such as reduce(identifier).

It is obvious in the initial substitution, but what if the resulting
quantity goes on to be used elsewhere, where its history is not
immediately apparent from the environment?

A user can't always ask for a reduced dimension - what would that mean
in the case of basic dimensions?  reduced from where?  from which
derived dimension?  reduced(Length) wouldn't mean anything, but the
Length which is part of the reduced dimension definition of Force is a
reduced dimension.

I'm not sure I agree there are dimensions whose reduced dimension is
identical to the dimension, depending on which definition of reduce we
are using.  I view a reduced dimension as a normal dimension which
calculates as normal, but preserves information about its origins.

I'm working on the interaction rules between reduced, derived, and
normal dimensions, although again I suspect I've gone a tad overboard
with the reduced idea.  Maybe this weekend I'll get some more written
on these thoughts, and realize they make no sense ;-).

> Reduced dimension can have reduced units (why not)?

Because this information is already in the dimension.  A unit might
have either a reduced dimension or a regular dimension associated with
it, depending on its history, but I see no reason to impart that
information to the unit as well since the unit MUST be associated with
a dimension.

Hmm.  Time to regroup and state my ideas on the definitions of reduced.
 
\start
Date: Sat, 10 Sep 2005 14:13:22 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

C Y wrote:
> 
> --- William Sit wrote:
> >
> > C Y wrote:
> > >
> > > Mass[r]*Length[r]/Time[r]^2
> >
> > No [IMHO]. This adds something unconventional and complicates things.
> 
[snipped]

> Hopefully this could be done with some conditional outputform tweak
> based on the Rep, so maybe a system setting to enable or disable this
> would be a good idea, assuming I can convince you it's a good idea -
> )set ShowReducedDimensions true  or some such.

I think the global )set is the wrong place, since a lot of users are
not going to bother with units (or have no need to use units). If you
really like to use a different but optional notation in output for
reduced dimensions, then use a set command in the package (and even
include this in the category specificiation), remember this in the
state vector, and modify the outputform coercions to do it.  This is
different from the )set UnitSystem because one cannot include this
setting in a unit system domain without first choosing the domain,
whereas the reduced dimension flag may be unit-system dependent. (Even
for the )set UnitSystem case, I have also suggested a simpler )library
command to replace the )set command).

> The reduced dimension flag tells us that these dimensions are the
> result of a substitution for some derived dimension, but otherwise we
> allow things to proceed as normal - the reduced dimensions of work and
> moment of force are the same, even though the derived dimensions
> themselves are not.  The implication is that a reduced dimension
> differs from a normal dimension in its history, but not in any
> functional way, which also implies that its history is somehow
> "inherent" in the Rep.  (one of the reasons I am in favor of preserving
> the dimensional history of a reduced dimension in its Rep).  Just by
> making the distinction, we are stating that there is something about a
> reduced dimension compared to a regular dimension that MIGHT matter -

You have to define "normal dimension" for me.

It may not be easy to trace what you called "history". My use of reduced
dimension is strictly reducing a derived (or basic, which would be unchanged)
dimension to a product and quotient of basic dimensions (that is where the idea
of using a (free) abelian group written multiplicatively to model Dimension
comes from), where each basic dimension only appears ONCE to some power. 

Let's consider a hypothetical situation where electricity is used to
raise a big steel ball with mass m to a certain height h and then give
it a certain velocity v; assume that energy in the form of electricity
can be provided at a rate p for a period t, we want to compute the
excess electricity (as a margin of error) using the formula:

   E = p*t - m*g*h - 1/2* m*v^2

where p is power in [kw] and t is time in [hr], and the rest are potential
energy and kinetic energy imparted to the ball (neglecting all other loss of
energy due to friction, etc), resulting in an expression for excess electricity
capacity which the user wants to express in [kwh]. This may be accomplished
under the present proposal as:

  E := setDimUnit("Energy", "kwh", p*t - m*g*h - 1/2 * m * v^2)

assuming all the other quantities are assigned their correct
dimensions and units already. In reduced dimension, <Energy> =
<Length*Mass^2/Time^2> but for E (I am starting to use pointed
brackets to enclose dimensions IN DOCUMENTATION rather than the string
quote even though they may be represented internally as strings; what
do you think?), this basic dimension expression comes in three
different ways of expressing energy, in terms of derived dimensions
such as <Power>, <Acceleration>, <Velocity> and the basic dimensions
<Mass>, <Length>, <Time>. How would you capture the "history" of E in
its Rep? If the unit is to be automatically set, E may be assigned to
have unit [kg m^2/s^2] or [Joule], but probably not [kwh]. In this
case, the equation is homogeneous dimensionally and correct. However,
the user may want the unit to be associated with a derived dimension
[Power*Time]. There is currently no provision to specify a derived
dimension as a product. So we may need to create a new one, say called
<Electricity>. Otherwise, the user's desire can be accommodated by the
choice of unit such as [kwh].

The Rep of E in the example above would be, if it includes the reduced
dimension:

   Record[value=E, dim = "Energy", reducedDim = "Mass*Length^2/Time^2",
          unit = "kwh", etc.]
 

> there may be some incompatibility not expressed in the dimensional
> representation as it currently exists, although we don't know what.
> Certainly, if I divide work by moment of force, this is a dimensionless
> number in terms of reduced dimensions but not in terms of derived
> dimensions, and I would be happier if the "dimensionless" number
> remembers something about this.  

The dimensionless case is but one instance of the many-to-one (indeed,
many-to-many) mapping of units to dimensions. We can capture (partially) the
nature of a quantity with dimension <Work>/<Moment> with the following Rep:

   Record[value=work/moment, dim="Plane Angle", reducedDim="1", unit = "rad",
etc]

To understand this, think of the moment generated about the pivot when the end
of a lever, of distance ell from the pivot, is rotated through an angle theta
with a force of constant magnitude f, always perpendicular to the lever. The
ratio <Work>/<Moment> may be meaningful; the total moment is computed by the
(scalar) product of the magnitude of the force f, and the distance ell to the
pivot, but the work is computed via an integral of a dot product for vectors,
since the direction of the force is constantly changing along the tangent of an
arc. The force vector is a function of theta, and is given by

    F(theta) = (f sin(theta), f cos(theta))

and the infinitesimal change in position r through which this force acts to
produce work is the vector (where r is the position vector for the point of
application, relative to the pivot as the origin)

    d(r) = (ell sin(theta) d(theta), ell cos(theta) d(theta))

giving the infinitesimal work done as

    F(theta) . d(r) = f*ell d(theta)

so that the total work through an angle theta is

   work = integral(f*ell d(theta)) from 0 to theta
        = f*ell*theta

Hence work/moment = theta [rad]. (If my analysis above is correct,
this explains in some detail why the two are different.) Since the
derived dimension for <Plane Angle> is actually <Length>/<Length>, the
reduced dimension is just "1", but to say that <Work>/<Moment> is
dimensionless is not to recognize the physical difference between the
two. Note moreover, the derived dimension of <Plane Angle> does not
capture the full physical meaning either. A better unit may be
[N-m/N-m] (recall that [m/m] is [rad] too) and unless we create new
names for each of these many-to-many instances (for both dimension and
unit), it is hard to assign derived dimensions. So a more desirable
design would be to allow an expert user to add derived dimensions (and
units) on the fly, and using a Dimension domain constructor with
arbitrary set of dimensions may be the way to do that. By using the
idea of a quotient of a free abelian group divided by a subgroup
generated by these new derived dimensions in terms of basic
dimensions, Axiom can handle such generality. The analog would be the
idea of polynomial ideals (which captures relations among variables)
and the quotient ring constructed by dividing a polynomial ring by the
ideal. We can construct ideals on the fly and work with the quotient
ring.

> I'll have more details later - I'm
> still chewing on this issue.  I might be thinking of reduced dimension
> a bit differently than how it was originally defined - I'll have to
> look - I'm viewing it as the dimension itself remembering its history,
> rather than it being the name for a basic dimension definition of a
> derived dimension.

> > There should be no difference in the output form. It should be quite
> > obvious that a dimension or unit output is reduced or not. Plus,
> > there are dimensions whose reduced dimension is identical to the
> > dimension. The user can also explicitly ask for a reduced dimension
> > through functions such as reduce(identifier).
> 
> It is obvious in the initial substitution, but what if the resulting
> quantity goes on to be used elsewhere, where its history is not
> immediately apparent from the environment?

I think maintaining a full history may be done in a chain. However,
due to the many to many mapping for units to dimensions (and I am not
thinking of incompatible ones like <Work> and <Moment>, but just say
units for <Energy>), it will take a lot of new names to separately
capture history. I still think the units themselves are sufficient
indication of the relation between (derived) dimension and reduced
dimension as far as the user goes. In the system, to be able to
recognize, say [kwh], or more simply [watt-hour] (dropping the prefix
kilo) as a unit of <Energy> requires setting up such a relation. Any
intermediate steps, say how the power p is computed before E is
computed in the example is not something of interest to E, but only of
interest to p, and in the Rep of p, we have that information. So we
can keep the history in this chained fashion, but in each identifier,
the "history" is short and immediate.
 
> A user can't always ask for a reduced dimension - what would that mean
> in the case of basic dimensions?  reduced from where?  from which
> derived dimension?  reduced(Length) wouldn't mean anything, but the
> Length which is part of the reduced dimension definition of Force is a
> reduced dimension.
> 
> I'm not sure I agree there are dimensions whose reduced dimension is
> identical to the dimension, depending on which definition of reduce we
> are using.  I view a reduced dimension as a normal dimension which
> calculates as normal, but preserves information about its origins.

You have to be more precise than that! What is "normal"? "origin"?

In mathematics, we consider integers as a subset of fractions, and in reducing
all fractions to lowest terms, we also consider that reducing the integer 2 to
lowest terms as reducing the fraction 2/1 to lowest terms. This is so that the
procedure "reduce to lowest terms" is applicable to all fractions, whether the
"origin" of a fraction is actually an integer or not. I think this convention
applies through all subdomains in mathematics and in Axiom. So it should be
perfectly correct to speak of the reduced dimension of a basic dimension in the
sense that the set of basic dimensions is a subset of all derived dimensions.
 
> I'm working on the interaction rules between reduced, derived, and
> normal dimensions, although again I suspect I've gone a tad overboard
> with the reduced idea.  Maybe this weekend I'll get some more written
> on these thoughts, and realize they make no sense ;-).
> 
> > Reduced dimension can have reduced units (why not)?
> 
> Because this information is already in the dimension.  A unit might
> have either a reduced dimension or a regular dimension associated with
> it, depending on its history, but I see no reason to impart that
> information to the unit as well since the unit MUST be associated with
> a dimension.

Please do not keep adding new terms ("regular dimension") without defining it.

I don't follow the precise meaning of "the unit MUST be associated
with a dimension".  Do you mean "For each unit, we must specify a
[emphasized] dimension to which the unit belongs?" I have no quarrel
with that. If you meant "the REDUCED dimension of the unit MUST be
unique", I also agree (at least with MY definition of reduced
dimension). If you meant "a unit MUST be associated with a dimension,
but that dimension need not be unique", that would be ok also.
However, if you meant "a unit MUST be associated with a UNIQUE
dimension", that I don't agree. The mapping between dimensions and
units is many-to-many, unless you are determined to create new names
for dimensions and units to split the mapping to force it to be
many-to-one, one-to-many or one-to-one (I certainly don't recommend
that, and won't do that).

> Hmm.  Time to regroup and state my ideas on the definitions of reduced.

Precise definitions is the first step, always. Precise statements (even if
long-winded) is the next.

\start
Date: Sat, 10 Sep 2005 20:39:04 -0400
From: Tim Daly
To: Kai Kaminsky, Bill Page
Subject: doyen and kai-axiom

http://arstechnica.com/columns/linux/linux-20050907.ars

is an article explaining the details of extending firefox in a
cross-platform manner. it appears we can create our own protocol
specifier, instead of http:// or ftp:// we can create axiom://
which would allow us to handle things like drag-and-drop on a
web page.

it's an interesting read so far...

\start
Date: Sun, 11 Sep 2005 02:03:02 -0400
From: Bill Page
To: list
Subject: help with Aldor categories, graphs and finite graphs.

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

I am trying to define the category of graphs in Aldor.

When I try to use this category in the definition of the
domain of FiniteGraphs I get an unexpected error:

  There are no suitable meanings for the operator `GraphCategory'.

But if I simply include the exported function definitions in
the domain itself then it seems to compile ok.

Since I am really just learning Aldor, this is probably just
a simple error on my part. Can anyone help me understand the
error and how to use categories properly in this case?

\start
Date: Sun, 11 Sep 2005 09:53:15 -0400
From: Stephen Wilson
To: Bill Page
Subject: Re: help with Aldor categories, graphs and finite graphs.

Hi Bill!

I looked at the code, and the only problem I see is that Record wont
satisfy BasicType. IIRC, the primitive structured types in aldor do
not export equality operations, let alone play into the standard
category hierarchy,

You could either write a custom Edge domain satisfying BasicType, else
use a higher-level data type like List or PrimitiveArray.

However, I cant be 100% about this. I do not have aldor installed.

Cheers,
Steve


On Sun, Sep 11, 2005 at 02:03:02AM -0400, Bill Page wrote:
> In
> 
> http://www.axiom-developer.org/zope/mathaction/SandBoxCategoryOfGraphs
> 
> I am trying to define the category of graphs in Aldor.
> 
> When I try to use this category in the definition of the
> domain of FiniteGraphs I get an unexpected error:
> 
>   There are no suitable meanings for the operator `GraphCategory'.
> 
> But if I simply include the exported function definitions in
> the domain itself then it seems to compile ok.
> 
> Since I am really just learning Aldor, this is probably just
> a simple error on my part. Can anyone help me understand the
> error and how to use categories properly in this case?

\start
Date: Sun, 11 Sep 2005 16:52:16 +0100
From: Peter Broadbery
To: Bill Page
Subject: Re: help with Aldor categories, graphs and finite graphs.

On Sun, 2005-09-11 at 02:03 -0400, Bill Page
wrote:
> In
> 
> http://www.axiom-developer.org/zope/mathaction/SandBoxCategoryOfGraphs
> 
> I am trying to define the category of graphs in Aldor.
> 
> When I try to use this category in the definition of the
> domain of FiniteGraphs I get an unexpected error:
> 
>   There are no suitable meanings for the operator `GraphCategory'.
> 

In the second version, you haven't told the compiler where it can find
the definition of `GraphCategory', so you get an error.

In order to get the library included, you need to put

#library "graphcat.ao" GRAPHCAT;
import from GRAPHCAT;
inline from GRAPHCAT;

at the top of the file (actually, anywhere at top level will do, but it
makes most sense just after #include "axiom.as").

The first line defines a library object referring to your category
definition, the second imports from it.  The third says that the
generated code can depend on the definitions (and not just the
signatures) within GRAPHCAT - it's only required when you want compiled
code to go faster, at the expense of a tighter dependency between
compiled pieces of code.

Obviously, this will get out of hand when you depend on many .ao files.
For this reason you can use 'ar' to create a single library file from
the .ao's which can then be imported as one lump (in fact axiom.as does
just this with libaxiom.al).

\start
Date: Sun, 11 Sep 2005 23:33:14 +0200
From: Kai Kaminski
To: list
Subject: AxiomUI update

I checked in  a slightly updated version of AxiomUI, correcting most
of the problems that Bill mentioned. No new functionality, though.

I would like to take this opportunity to thank everyone who helped me
with this project during the Summer of Code.

\start
Date: Sun, 11 Sep 2005 18:19:27 -0400
From: Bill Page
To: Kai Kaminski
Subject: RE: AxiomUI update

Kai,

On September 11, 2005 5:33 PM you wrote:
> 
> I checked in  a slightly updated version of AxiomUI, correcting
> most of the problems that Bill mentioned. No new functionality,
> though.
> 

Did you get a chance to add the Hyperdoc pages and related programs
to the archive?

\start
Date: Sun, 11 Sep 2005 18:52:30 -0400
From: Bill Page
To: Peter Broadbery, Stephen Wilson
Subject: Re: help with Aldor categories,

On Sun, 2005-09-11 at 11:52 -0400, Peter Broadbery wrote:
> 
> In the second version, you haven't told the compiler where it can
> find the definition of `GraphCategory', so you get an error.
> 
> In order to get the library included, you need to put
> 
> #library "graphcat.ao" GRAPHCAT;
> import from GRAPHCAT;
> inline from GRAPHCAT;
> 

Great. I added:

#library GRAPHCAT "GRAPHCAT.ao";
import from GRAPHCAT;
inline from GRAPHCAT;

and now it finds the category. I also had to change BasicType to
Type for reasons Steve Wilson described on Sun Sep 11 2005 9:53 AM:

> 
> I looked at the code, and the only problem I see is that Record
> wont satisfy BasicType. IIRC, the primitive structured types in
> aldor do not export equality operations, let alone play into the
> standard category hierarchy,
> 
> You could either write a custom Edge domain satisfying BasicType,
> else use a higher-level data type like List or PrimitiveArray.

However now in

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

I get a different apparently more serious error:

  >> System error:
   AxiomXL file "GRAPHCAT" is missing!

This error occurs when trying to call new()$FiniteGraph(INT) in spite
of having already successfully defined g as a FiniteGraph.

Ideas? Is this a "system error" or just another "user error"?

\start
Date: Sun, 11 Sep 2005 21:13:09 -0400
From: Bill Page
To: William Sit
Subject: Re: help with Aldor categories,

William,

You wrote:

> Maybe if you don't use the same name "source" for two different
> things? (also "target"): you used it for a field in edges and
> also as an exported function.
> 

I don't think that this is a problem. The compiler is able to
easily distinguish the two uses of "source" because of strong
typing. In fact in this case they really are the same, i.e. the
field is the representation of the function so perhaps the usage
is justified.

This works in the spad version:

http://axiom-developer.org/SandBoxCategoryOfGraphsInSPAD

But the equivalent Aldor version of the code (with corrections
by Peter Broadbery and Steve Wilson, not with standing any
remaining errors on my part), gives a >>System error. See:

http://axiom-developer.org/SandBoxCategoryOfGraphs

\start
Date: Sun, 11 Sep 2005 23:22:05 -0400
From: Cliff Yapp
To: William Sit
Subject: Re: Unit package proposals and questions

On Saturday 10 September 2005 02:13 pm, William Sit wrote:
> C Y wrote:
> > --- William Sit wrote:
> > > C Y wrote:
> > > > Mass[r]*Length[r]/Time[r]^2
> > >
> > > No [IMHO]. This adds something unconventional and complicates things.
>
> [snipped]
>
> > Hopefully this could be done with some conditional outputform tweak
> > based on the Rep, so maybe a system setting to enable or disable this
> > would be a good idea, assuming I can convince you it's a good idea -
> > )set ShowReducedDimensions true  or some such.
>
> I think the global )set is the wrong place, since a lot of users are not
> going to bother with units (or have no need to use units). If you really
> like to use a different but optional notation in output for reduced
> dimensions, then use a set command in the package (and even include this in
> the category specificiation), remember this in the state vector, and modify
> the outputform coercions to do it.  

Sounds good.  There are a fair number of options worth tweaking in a units 
environment, so that mechanism is a good one to nail down early.

> This is different from the )set 
> UnitSystem because one cannot include this setting in a unit system domain
> without first choosing the domain, whereas the reduced dimension flag may
> be unit-system dependent. (Even for the )set UnitSystem case, I have also
> suggested a simpler )library command to replace the )set command).

Sounds good.  Whatever the best way is, so long as we document it ;-).

> > The reduced dimension flag tells us that these dimensions are the
> > result of a substitution for some derived dimension, but otherwise we
> > allow things to proceed as normal - the reduced dimensions of work and
> > moment of force are the same, even though the derived dimensions
> > themselves are not.  The implication is that a reduced dimension
> > differs from a normal dimension in its history, but not in any
> > functional way, which also implies that its history is somehow
> > "inherent" in the Rep.  (one of the reasons I am in favor of preserving
> > the dimensional history of a reduced dimension in its Rep).  Just by
> > making the distinction, we are stating that there is something about a
> > reduced dimension compared to a regular dimension that MIGHT matter -
>
> You have to define "normal dimension" for me.

Opps - sorry.  "normal dimension" would in this case be a "non-reduced 
dimension," which may not be much more informative.  More on this below.

> It may not be easy to trace what you called "history". My use of reduced
> dimension is strictly reducing a derived (or basic, which would be
> unchanged) dimension to a product and quotient of basic dimensions (that is
> where the idea of using a (free) abelian group written multiplicatively to
> model Dimension comes from), where each basic dimension only appears ONCE
> to some power.

Sounds good. (the abelian part).  

> Let's consider a hypothetical situation where electricity is used to raise
> a big steel ball with mass m to a certain height h and then give it a
> certain velocity v; assume that energy in the form of electricity can be
> provided at a rate p for a period t, we want to compute the excess
> electricity (as a margin of error) using the formula:
>
>    E = p*t - m*g*h - 1/2* m*v^2
>
> where p is power in [kw] and t is time in [hr], and the rest are potential
> energy and kinetic energy imparted to the ball (neglecting all other loss
> of energy due to friction, etc), resulting in an expression for excess
> electricity capacity which the user wants to express in [kwh]. This may be
> accomplished under the present proposal as:
>
>   E := setDimUnit("Energy", "kwh", p*t - m*g*h - 1/2 * m * v^2)
>
> assuming all the other quantities are assigned their correct dimensions and
> units already. In reduced dimension, <Energy> = <Length*Mass^2/Time^2> but
> for E
> (I am starting to use pointed brackets to enclose dimensions IN 
> DOCUMENTATION rather than the string quote even though they may be
> represented internally as strings; what do you think?), 

Hmm - not a bad idea, since interacting with them will be quite different from 
string interactions at the user level, in all likelyhood.

> this basic 
> dimension expression comes in three different ways of expressing energy, in
> terms of derived dimensions such as <Power>, <Acceleration>, <Velocity> and
> the basic dimensions <Mass>, <Length>, <Time>. How would you capture the
> "history" of E in its Rep?

I wouldn't capture it in E exactly, except maybe as a consequence of 
incorporating reduced dimensions.  I need to define my terms - I'll try to 
revisit this issue later - it's an excellent example and my point out flaws 
in my thinking to me.

> If the unit is to be automatically set, E may be 
> assigned to have unit [kg m^2/s^2] or [Joule], but probably not [kwh]. In
> this case, the equation is homogeneous dimensionally and correct. However,
> the user may want the unit to be associated with a derived dimension
> [Power*Time]. There is currently no provision to specify a derived
> dimension as a product. So we may need to create a new one, say called
> <Electricity>. Otherwise, the user's desire can be accommodated by the
> choice of unit such as [kwh].

OK (I think.)  Offhand I'm guessing products as derived dimensions aren't the 
best idea?

> The Rep of E in the example above would be, if it includes the reduced
> dimension:
>
>    Record[value=E, dim = "Energy", reducedDim = "Mass*Length^2/Time^2",
>           unit = "kwh", etc.]

OK, that looks good.

> > there may be some incompatibility not expressed in the dimensional
> > representation as it currently exists, although we don't know what.
> > Certainly, if I divide work by moment of force, this is a dimensionless
> > number in terms of reduced dimensions but not in terms of derived
> > dimensions, and I would be happier if the "dimensionless" number
> > remembers something about this.
>
> The dimensionless case is but one instance of the many-to-one (indeed,
> many-to-many) mapping of units to dimensions. We can capture (partially)
> the nature of a quantity with dimension <Work>/<Moment> with the following
> Rep:
>
>    Record[value=work/moment, dim="Plane Angle", reducedDim="1", unit > "rad", etc]
>
> To understand this, think of the moment generated about the pivot when the
> end of a lever, of distance ell from the pivot, is rotated through an angle
> theta with a force of constant magnitude f, always perpendicular to the
> lever. The ratio <Work>/<Moment> may be meaningful; the total moment is
> computed by the (scalar) product of the magnitude of the force f, and the
> distance ell to the pivot, but the work is computed via an integral of a
> dot product for vectors, since the direction of the force is constantly
> changing along the tangent of an arc. The force vector is a function of
> theta, and is given by
>
>     F(theta) = (f sin(theta), f cos(theta))
>
> and the infinitesimal change in position r through which this force acts to
> produce work is the vector (where r is the position vector for the point of
> application, relative to the pivot as the origin)
>
>     d(r) = (ell sin(theta) d(theta), ell cos(theta) d(theta))
>
> giving the infinitesimal work done as
>
>     F(theta) . d(r) = f*ell d(theta)
>
> so that the total work through an angle theta is
>
>    work = integral(f*ell d(theta)) from 0 to theta
>         = f*ell*theta
>
> Hence work/moment =  theta [rad]. (If my analysis above is correct, this
> explains in some detail why the two are different.)

I'll need to think about this one some more after getting some sleep ;-).

> Since the derived 
> dimension for <Plane Angle> is actually <Length>/<Length>, the reduced
> dimension is just "1", but to say that <Work>/<Moment> is dimensionless is
> not to recognize the physical difference between the two. Note moreover,
> the derived dimension of <Plane Angle> does not capture the full physical
> meaning either. A better unit may be [N-m/N-m] (recall that [m/m] is [rad]
> too) and unless we create new names for each of these many-to-many
> instances (for both dimension and unit), it is hard to assign derived
> dimensions. So a more desirable design would be to allow an expert user to
> add derived dimensions (and units) on the fly, and using a Dimension domain
> constructor with arbitrary set of dimensions may be the way to do that.

OK.

> By
> using the idea of a quotient of a free abelian group divided by a subgroup
> generated by these new derived dimensions in terms of basic dimensions,
> Axiom can handle such generality. The analog would be the idea of
> polynomial ideals (which captures relations among variables) and the
> quotient ring constructed by dividing a polynomial ring by the ideal. We
> can construct ideals on the fly and work with the quotient ring.

I'll re-read that last part after I get through the Group and Ring chapters in 
those notes ;-).

> > I'll have more details later - I'm
> > still chewing on this issue.  I might be thinking of reduced dimension
> > a bit differently than how it was originally defined - I'll have to
> > look - I'm viewing it as the dimension itself remembering its history,
> > rather than it being the name for a basic dimension definition of a
> > derived dimension.
> >
> > > There should be no difference in the output form. It should be quite
> > > obvious that a dimension or unit output is reduced or not. Plus,
> > > there are dimensions whose reduced dimension is identical to the
> > > dimension. The user can also explicitly ask for a reduced dimension
> > > through functions such as reduce(identifier).
> >
> > It is obvious in the initial substitution, but what if the resulting
> > quantity goes on to be used elsewhere, where its history is not
> > immediately apparent from the environment?
>
> I think maintaining a full history may be done in a chain. However, due to
> the many to many mapping for units to dimensions (and I am not thinking of
> incompatible ones like <Work> and <Moment>, but just say units for
> <Energy>), it will take a lot of new names to separately capture history. I
> still think the units themselves are sufficient indication of the relation
> between (derived) dimension and reduced dimension as far as the user goes.
> In the system, to be able to recognize, say [kwh], or more simply
> [watt-hour] (dropping the prefix kilo) as a unit of <Energy> requires
> setting up such a relation. Any intermediate steps, say how the power p is
> computed before E is computed in the example is not something of interest
> to E, but only of interest to p, and in the Rep of p, we have that
> information. So we can keep the history in this chained fashion, but in
> each identifier, the "history" is short and immediate.

Except E knows about a specific p, and so (in theory) the user could enquire 
about the history of p that E depends on, correct?  I'm not sure whether it's 
actually useful or not to preserve history - it might not be worth the 
effort.  I'll have to think about it some more, in light of your new 
examples.

> > A user can't always ask for a reduced dimension - what would that mean
> > in the case of basic dimensions?  reduced from where?  from which
> > derived dimension?  reduced(Length) wouldn't mean anything, but the
> > Length which is part of the reduced dimension definition of Force is a
> > reduced dimension.
> >
> > I'm not sure I agree there are dimensions whose reduced dimension is
> > identical to the dimension, depending on which definition of reduce we
> > are using.  I view a reduced dimension as a normal dimension which
> > calculates as normal, but preserves information about its origins.
>
> You have to be more precise than that! What is "normal"? "origin"?

Apologies.  Here is how I've been thinking about these terms:

"dimension" or "normal dimension" - a dimension with no historical 
information, which is not the product of a substitution used in calculations.  
Any unit input by the user is a "normal" dimension, as is an dimension which 
passes through calculations without being altered.

"reduced dimension"  - a dimension which is the result of a substitution for 
another dimension.  E.g. if we have <Force> and substitute in 
<Mass>*<Length>/<Time>^2, each of those three dimensions is a "reduced" 
dimension because it was substituted in for a higher order dimension.

Of course, in the Force example the mapping may be unique (don't know offhand) 
in the default SI  definitions, but who's to say a user won't define a custom 
derived dimension with SI base dimensions the same as those of force?  That's 
why I don't want to assume any case where reduced dimensions are identical to 
"normal" dimensions - e.g. their origins can be ignored.  It may be that we 
DO want to ignore their origins, as long as we prevent casual simplification 
from  base dimensions to derived dimensions without explicit user input/rule 
definitions.  In which case "reduced dimensions" would retain no history.  
Needs more thought.

> In mathematics, we consider integers as a subset of fractions, and in
> reducing all fractions to lowest terms, we also consider that reducing the
> integer 2 to lowest terms as reducing the fraction 2/1 to lowest terms.
> This is so that the procedure "reduce to lowest terms" is applicable to all
> fractions, whether the "origin" of a fraction is actually an integer or
> not. I think this convention applies through all subdomains in mathematics
> and in Axiom. So it should be perfectly correct to speak of the reduced
> dimension of a basic dimension in the sense that the set of basic
> dimensions is a subset of all derived dimensions.

OK, I'll agree with that.  

> > I'm working on the interaction rules between reduced, derived, and
> > normal dimensions, although again I suspect I've gone a tad overboard
> > with the reduced idea.  Maybe this weekend I'll get some more written
> > on these thoughts, and realize they make no sense ;-).
> >
> > > Reduced dimension can have reduced units (why not)?
> >
> > Because this information is already in the dimension.  A unit might
> > have either a reduced dimension or a regular dimension associated with
> > it, depending on its history, but I see no reason to impart that
> > information to the unit as well since the unit MUST be associated with
> > a dimension.
>
> Please do not keep adding new terms ("regular dimension") without defining
> it.

Sorry.  regular dimension = normal dimension or just plain "dimension".

> I don't follow the precise meaning of "the unit MUST be associated with a
> dimension".  Do you mean "For each unit, we must specify a [emphasized]
> dimension to which the unit belongs?" I have no quarrel with that. If you
> meant "the REDUCED dimension of the unit MUST be unique", I also agree (at
> least with MY definition of reduced dimension). If you meant "a unit MUST
> be associated with a dimension, but that dimension need not be unique",
> that would be ok also. However, if you meant "a unit MUST be associated
> with a UNIQUE dimension", that I don't agree. The mapping between
> dimensions and units is many-to-many, unless you are determined to create
> new names for dimensions and units to split the mapping to force it to be
> many-to-one, one-to-many or one-to-one (I certainly don't recommend that,
> and won't do that).

No, a unit doesn't need to be associated with a unique dimension.  Agree with 
that.  I just meant "a unit cannot be defined without an associated 
dimension."  Although strictly speaking, dimensionless things like radians 
might make that invalid.  Hmm...

> > Hmm.  Time to regroup and state my ideas on the definitions of reduced.
>
> Precise definitions is the first step, always. Precise statements (even if
> long-winded) is the next.

OK. :-).  I'm working on a (hopefully) precise writeup of my definitions 
(hopefully it will be the first sections of introductory material for the 
eventual units.spad.pamphlet) - once I'm reasonably sure it's ready to be 
shredded I'll post it ;-).  With any luck, once things are reasonably well 
defined we can proceed without too much more trouble to the design issues in 
terms of Axiom :-).

\start
Date: Mon, 12 Sep 2005 09:12:02 +0200
From: Kai Kaminski
To: Bill Page
Subject: Re: AxiomUI update

Bill Page writes:

>> I checked in  a slightly updated version of AxiomUI, correcting
>> most of the problems that Bill mentioned. No new functionality,
>> though.
>
> Did you get a chance to add the Hyperdoc pages and related programs
> to the archive?
Unfortunately not. There are still some problems with the pages and
since the whole package is a few megabytes in size, I didn't want to
check in a broken version. I'll work on them when I get back next
week.

\start
Date: Mon, 12 Sep 2005 12:23:22 +0200
From: Martin Rubey
To: list
Subject: status of Aldor and "release"

Dear all,

I was sick last week and it seems that I somehow missed part of the
discussion. Hence two questions:

* is it true, that we have permission to distribute the Aldor source now? (In
  fact, for my part, I don't even have the source...)

* I would like to "announce" Axiom 3 just before October. (without the beta, to
  make it look new) It seems that Tim has prepared binaries, have they been
  tested? In patch 45 or so HyperDoc failed on startup. (due to some strange
  and undocumented edits in util.ht.) Is axiomui in a usable state for the
  windows users?

\start
Date: Mon, 12 Sep 2005 14:39:14 +0200
From: Gregory Vanuxem
To: list
Subject: Mathematical interaction frontpage unavailable

Hi,

In a tentative to join Mathematical interaction frontpage,
i received:
Bad Gateway!
        The proxy server received an invalid response from an upstream
        server. 
        The proxy server could not handle the request <EM><A
        HREF="/zope/mathaction/FrontPage">GET&nbsp;/zope/mathaction/FrontPage</A></EM>.<P> Reason: <STRONG>Error reading from remote server</STRONG> 
        If you think this is a server error, please contact the
        webmaster
Error 502
        page.axiom-developer.org 
        Mon 12 Sep 2005 07:28:55 AM CDT 
        Apache/2.0.40 (Red Hat Linux)
        
\start
Date: Mon, 12 Sep 2005 11:09:43 -0400
From: Tim Daly
To: Bill Page
Subject: axiom-developer.org virtual machine

The axiom-developer.org virtual machine should be back up and running now.

It was running out of memory and killed or zombied 6k processes.
I upgraded the memory on the machine to 768k.

\start
Date: Mon, 12 Sep 2005 11:41:27 -0400
From: Bill Page
To: Tim Daly
Subject: RE: axiom-developer.org virtual machine

On September 12, 2005 11:10 AM Tim Daly wrote:
> 
> The axiom-developer.org virtual machine should be back up and 
> running now.
> 
> It was running out of memory and killed or zombied 6k processes.
> I upgraded the memory on the machine to 768k.
> 

Thanks Tim! It's working fine now.

One of these days it would be good to find low cost (no cost?)
dedicated home for axiom-developer. Some of the things we are
doing on this machine require a lot of horse power.

Also it sure would be nice if we could find someone willing
to host a mirror site.

\start
Date: Mon, 12 Sep 2005 11:55:37 -0400
From: Tim Daly
To: Bill Page
Subject: Re: axiom-developer.org virtual machine

you might consider making sure that your stuff is backed up.
they don't do backups.

\start
Date: Mon, 12 Sep 2005 12:37:20 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] Re: Huge download on Windows

Not only on Windows, is it not possible on Linux to download only the
packages required and to just build them?  Also, as a typical case,
several users use both Linux and Windows in parallel. If there could
be a way to download Linux and Windows specific sources separately
from the sources common to both and that the source common to both
could be used under both Linux and Windows, that would save lot of
download time and money.

\start
Date: Mon, 12 Sep 2005 13:42:21 -0400
From: Bill Page
To: Tim Daly
Subject: RE: help with Aldor categories,
Cc: Peter Broadbery

Tim,

On September 11, 2005 6:53 PM I wrote:
> 
> However now in
> 
> http://axiom-developer.org/SandBoxCategoryOfGraphs
>
> I get a different apparently more serious error:
>
>  >> System error:
>   AxiomXL file "GRAPHCAT" is missing!
> 
> This error occurs when trying to call new()$FiniteGraph(INT) in
> spite of having already successfully defined g as a FiniteGraph.
>
> Ideas? Is this a "system error" or just another "user error"?

Tracing the message "AxiomXL file ..." leads me to 

http://www.axiom-developer.org/repository/axiom--main--1/src/interp/daas
e.lisp.pamphlet

;; following 2 functions are called by file-exports and file-imports
macros
(defun foam::process-import-entry (entry)
  (let* ((asharpname (car entry))
	 (stringname (cadr entry))
	 (hcode (caddr entry))
	 (libname (cadddr entry))
	 (bootname (intern stringname 'boot)))
    (declare (ignore libname))
    (if (and (eq hcode 'foam-user::|initializer|) (not (boundp
asharpname)))
	(error (format nil "AxiomXL file ~s is missing!" stringname)))
    (unless (or (not (numberp hcode)) (zerop hcode) (boundp asharpname))
	  (when (|constructor?| bootname)
		(set asharpname
		     (if (getdatabase bootname 'niladic)
			 (|makeLazyOldAxiomDispatchDomain| (list
bootname))
		       (cons '|runOldAxiomFunctor|  bootname))))
	  (when (|attribute?| bootname)
		(set asharpname (|makeLazyOldAxiomDispatchDomain|
bootname))))))

-----------

The 'file-imports' macro is defined here

http://www.axiom-developer.org/repository/axiom--main--1/src/interp/foam
_l.lisp.pamphlet

but from this point on I get lost. It is not clear to me where
this macro is called nor why it is being called for "GRAPHCAT".

These files have your name and Stephen M. Watt listed as
authors. I don't suppose you remember what all this was
about 10+ years ago :) or do you?

Any suggestions as to where I should look?

Do we have any working examples of Aldor categories being
used in the old version of Axiom?

\start
Date: Mon, 12 Sep 2005 12:42:28 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] Graphics does not work under the TeXmacs 1.0.5 interface

Under linux with TeXmacs, the graphics doesn't appear at all. Just the
message indicating the type is shown.  I even followed the
instructions on the FAQ and changed the AXIOMsys to axiom and even
sman. But if I do that though HyperDoc appears, I have to press return
several times(may be upto 7 times) before the answer appears on the
texmacs interface. Just blank lines with the red axiom prompt keep on
appearing.

\start
Date: Mon, 12 Sep 2005 18:14:00 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AXIOMsys] 

sinCosProducts := rule
  sin(x)*sin(y) == (cos(x-y) - cos(x+y))/2
  cos(x)*cos(y) == (cos(x-y) + cos(x+y))/2
  sin(x)*cos(y) == (sin(x-y) + sin(x+y))/2
  sin(x)^2 == (1 - cos(2*x))/2
  sin(x)^3 == sin(x)*(1 - cos(2*x))/2

\start
Date: Mon, 12 Sep 2005 23:59:20 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Axiom in general

CY,

>Also - Tim, a question about Axiom in general - Do we have somewhere in Axiom 
>a thorough description on the mathematical principles it's based on?  
>(Groups, Rings, etc.?)  Do the pamphlet files cover all that?  I'm not sure 
>making Axiom into a huge self contained introduction and definition of all 
>mathematics is a workable or desirable goal, but it would be nice to define a 
>minimum education level needed to work with the system and recommend some 
>resources for various education levels to get them started.

Unfortunately Axiom does not contain a thorough description of the 
mathematical principles. It does not even contain a good explanation
of category theory or even of the algorithms that it uses. By design
this will change in the future provided people lend their expertise
to the problem. It's clearly a 30 year horizon goal.

\start
Date: Tue, 13 Sep 2005 02:51:20 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Unit package proposals and questions

C Y wrote:
> 
> On Saturday 10 September 2005 02:13 pm, William Sit wrote:

[snipped]

> > You have to define "normal dimension" for me.
> 
> Opps - sorry.  "normal dimension" would in this case be a "non-reduced
> dimension," which may not be much more informative.  More on this below.

OK, so (below) "dimension"="normal dimension" = "regular
dimension""non-reduced dimension". That's a lot of unnecessary
aliases. In documentation, it is important not to fall into using
colloquial English when precision is needed.
 

> > (I am starting to use pointed brackets to enclose dimensions IN
> > DOCUMENTATION rather than the string quote even though they may be
> > represented internally as strings; what do you think?),

> Hmm - not a bad idea, since interacting with them will be quite
> different from string interactions at the user level, in all
> likelyhood.

So may be we should adopt that. It would avoid confusion between unit and
dimension.

[snipped]

> OK (I think.)  Offhand I'm guessing products as derived dimensions aren't the
> best idea?

To me, a derived dimension is one which is obtained as a product
and/or quotient of other dimensions (which may be derived and/or
basic), but is given a name.  The name describes a term used in the
expert area. So <Pressure> is one since it is defined as
<Force>/<Area>. We should allow derived dimension to be defined this
way, but the point is, a derived dimension has an associated name
(like <Pressure>) and it is this name that is used for later
references. In some sense, a dimension is the name of some property of
one or more objects, and a unit in this dimension is a quantitative
measurement of the property. So <Pressure> is the name of the property
of fluid or gas when their molecules bombard on a surface and may be
measured in say, [Pascal] or [Atmosphere].
 
[snipped example discussions on <Energy> and on <Work>/<Moment>]

> > I think maintaining a full history may be done in a chain. 
[snipped]
> 
> Except E knows about a specific p, and so (in theory) the user could enquire
> about the history of p that E depends on, correct?  

That would be a quite a feat, if it were implemented (surely, it is
possible).  Whenever (in any language) an expression is computed, the
formula may or may not be retained, and often, it is not when
simplification occurs. This is especially true when there are
numerical computations. In the example I gave:

> >   E := setDimUnit("Energy", "kwh", p*t - m*g*h - 1/2 * m * v^2)

any of the identifiers may have symbolic or numerical values involved,
and there is no reason to expect that in the Rep for E, this
expression will look anything like the input expression. My comments
on "history" were limited to the "history" of the dim field in the Rep
of E and p. The only one who retains a knowledge of how E depends on p
is the user (through a trace of the inputs).

C Y wrote:
> > > A user can't always ask for a reduced dimension - what would that mean
> > > in the case of basic dimensions?  reduced from where?  from which
> > > derived dimension?  reduced(Length) wouldn't mean anything, but the
> > > Length which is part of the reduced dimension definition of Force is a
> > > reduced dimension.
> > >
> > > I'm not sure I agree there are dimensions whose reduced dimension is
> > > identical to the dimension, depending on which definition of reduce we
> > > are using.  I view a reduced dimension as a normal dimension which
> > > calculates as normal, but preserves information about its origins.
> >
> > You have to be more precise than that! What is "normal"? "origin"?
> 
> Apologies.  Here is how I've been thinking about these terms:
> 
> "dimension" or "normal dimension" - a dimension with no historical
> information, which is not the product of a substitution used in calculations.
> Any unit input by the user is a "normal" dimension, as is an dimension which
> passes through calculations without being altered.

This is still not clear to me. The word "product" means "result"? You
are confusing "unit" with "dimension"?  Can we give a (pseudo) grammar
for what is <dimension>? From what we have discussed, it seems there
are three aspects of any dimension: a name, a definition, and a
reduced form. The name may be optional, in which case, perhaps we
should use as default the reduced form (converted to String) as
name. Here is what I propose as a start, to accommodate the three
aspects: the three fields are tagged by name, definition, and reduced:

  <Basic> := <Mass> | <Length> | ...

  <Name> := "String" | <String> 

(here, String stands for any string, or perhaps identifier, and the two forms
using double-quote or pointed brackets, are considered as interchangeable; a
full grammar for such strings is omitted; <Mass> is an example.)

  <Basic-Dimension>:= (<Mass>, <Mass>, <Mass>) | 
                      (<Length>, <Length>, <Length>) |
                      ...

(this means, the name is <Mass>, and is defined in terms of <Mass> from <Basic>
and the reduced form is also <Mass>)

 
  <Reduced> := "1" | <Basic> | <Reduced>*<Basic> | <Reduced>/<Basic> 

(more precisely, products or quotients of <Basic> in lowest terms, whose
grammatical definition is omitted)

  <Definition> := <Dimension.name> | <Definition> * <Dimension.name>
          | <Definition>/<Dimension.name>

(this means a dimension's definition is formed using a product or quotient of
previously defined dimension names)

  <Dimension>:= (<Name>, <Definition>, <Reduced>)

(not included in the grammar above is the requirement that the reduced part
should be obtained by reducing the definition part to lowest terms; under this
production rule, <Basic-Dimension> is part of <Dimension>).

(If you prefer, you can read the above from bottom up, so that <Dimension> is
the sentence symbol of the grammar).

Note that <Derived-Dimension> is nothing but <Dimension> \ <Basic-Dimension>.

Examples would be

    (<Pressure>, <Force>/<Area>, <Mass>/(<Length>*<Time>^2))

    (<Force>, <Mass>*<Acceleration>, <Mass>*<Length>/<Time>^2)

    (<Area>, <Length>^2, <Length>^2)

In the same way, we can define the grammar for Unit, with an added tag:
abbreviation. (Details left as an exercise for the reader :-))

    

> "reduced dimension"  - a dimension which is the result of a substitution for
> another dimension.  E.g. if we have <Force> and substitute in
> <Mass>*<Length>/<Time>^2, each of those three dimensions is a "reduced"
> dimension because it was substituted in for a higher order dimension.

This is not what I would call "reduced dimension". I would say the ENTIRE
expression <Mass>*<Length>/<Time>^2 is ONE reduced dimension, namely, the
reduced form of <Force>. Each component is a BASIC-dimension. In the paragraph
below, you WERE using "reduced dimension" in MY sense.

> Of course, in the Force example the mapping may be unique (don't
> know offhand) in the default SI definitions, but who's to say a user
> won't define a custom derived dimension with SI base dimensions the
> same as those of force?  That's why I don't want to assume any case
> where reduced dimensions are identical to "normal" dimensions -
> e.g. their origins can be ignored.  It may be that we DO want to
> ignore their origins, as long as we prevent casual simplification
> from base dimensions to derived dimensions without explicit user
> input/rule definitions.  In which case "reduced dimensions" would
> retain no history.  Needs more thought.

Why do we have ANY (casual) simplification FROM base dimensions TO derived
dimensions? Need to clarify your thoughts -- after some sleep? :-).
 

> > > > Reduced dimension can have reduced units (why not)?
> > >
> > > Because this information is already in the dimension.  A unit might
> > > have either a reduced dimension or a regular dimension associated with
> > > it, depending on its history, but I see no reason to impart that
> > > information to the unit as well since the unit MUST be associated with
> > > a dimension.
> Sorry.  regular dimension = normal dimension or just plain "dimension".

But I want to keep the two (reduced and not-reduced) forms of a unit,
if they are different. So I may want to use both [Newton] and
[kg][m]/[s]^2 for the unit of <Force>. Another example, for the unit
of <Pressure>, I want to keep three aspects of it: name, definition,
and reduced (just like Dimension); and in addition, abbreviation.

    ([Pascal], [Newton]/[m]^2, [kg]/([m]*[s]^2), [Pa])

If such information is derived from information retained in
<Pressure>, we will only be able to use the default units, not perhaps
the user chosen units after using a setDimUnit command. Note that in
the above, I have not included the Dimension for the unit named
[Pascal]. This is because in case there is no name (or if the default
name is simply the definition or reduced tag value), then it would not
be clear what dimension the unit should belong to. If a Dimension MUST
be included, then it would be biased in the sense that the programmed
code may use that more often over other possibilities because of
convenience.
 
[snipped]

> No, a unit doesn't need to be associated with a unique dimension.  Agree with
> that.  I just meant "a unit cannot be defined without an associated
> dimension."  Although strictly speaking, dimensionless things like radians
> might make that invalid.  Hmm...

I take that to mean you want to force the user to associate a dimension with a
unit he uses. That's reasonable. However, for the system, a unit can be
standalone and not associated with a dimension until used. The representation
for a dimensionless unit like radian can be:

   ([Radian], [m]/[m], [1], [rad])

I think it would make more sense to require that a basic unit be
associated with a basic dimension, because the dimension would be
unique.

\start
Date: Tue, 13 Sep 2005 09:56:54 +0100
From: Peter Broadbery
To: Bill Page
Subject: RE: help with Aldor categories, graphs and finite graphs.

On Mon, 2005-09-12 at 13:42 -0400, Bill Page wrote:
> Tim,
> 
> On September 11, 2005 6:53 PM I wrote:
> > 
> > However now in
> > 
> > http://axiom-developer.org/SandBoxCategoryOfGraphs
> >
> > I get a different apparently more serious error:
> >
> >  >> System error:
> >   AxiomXL file "GRAPHCAT" is missing!
> > 
> > This error occurs when trying to call new()$FiniteGraph(INT) in
> > spite of having already successfully defined g as a FiniteGraph.



> -----------
> 
> The 'file-imports' macro is defined here
> 
> http://www.axiom-developer.org/repository/axiom--main--1/src/interp/foam
> _l.lisp.pamphlet
> 
> but from this point on I get lost. It is not clear to me where
> this macro is called nor why it is being called for "GRAPHCAT".
> 
> These files have your name and Stephen M. Watt listed as
> authors. I don't suppose you remember what all this was
> about 10+ years ago :) or do you?
> 
> Any suggestions as to where I should look?
> 

11 years ago.  Hmm, I absolutely shouldn't remember.  In any case, try
explicitly doing )lib graphcat before loading the second file.  The
file-imports macro should probably be smartened up to force an autoload,
but it hasn't been yet.

\start
Date: Tue, 13 Sep 2005 11:51:13 +0100
From: Nic Doye
To: Tim Daly
Subject: Re: Axiom in general
Cc: Cliff Yapp

On Mon, 2005-09-12 at 23:59 -0400, root wrote:
`
> Unfortunately Axiom does not contain a thorough description of the 
> mathematical principles. It does not even contain a good explanation
> of category theory or even of the algorithms that it uses. By design
> this will change in the future provided people lend their expertise
> to the problem. It's clearly a 30 year horizon goal.

I'm a bit rusty on all this, and my knowledge out of date. So caveat
blah-de-blah. For those that don't know remember my mini-intro some time
back, I was one of James Davenport's PhD students charged with finding a
mathematical foundation for coercion in Axiom.

http://worldofnic.org/research/phd.ps

Chapter 2 of my thesis gave some introduction to the mathematical
formulation of Categories in Axiom/Magma/OBJ.

Chapter 3 talks about Category Theory.
Chapter 4 talks about Order Sorted Algebra.
(Both these chapters put these definitions in Axiom terms at the end).

Chapter 9 talks about where I'd like Axiom to go.

Some of my "ideas" in my thesis are wrong and I no longer stand by them.
I was naive. Please ignore 9.7 and any assertions that Axiom should be
written in Axiom. ;-)

In some ways, it is far more useful to not think of Axiom in terms of
Category Theory. Functors etc. are useful sometimes when thinking
abstractly about Axiom, but Axiom's true roots are in Order Sorted
Algebra.

In axiom a Category is an Order Sorted Signature, but the order on the
sorts is never explicitly defined and there are some difficulties in the
definition of the operator symbols.

OBJ _is_ based on Order Sorted Algebra. It's main advantage over Axiom
as I see it, is that it defines Theories. A Theory is an Order Sorted
Signature with (and this is what Axiom misses) a set of equations. This
means that in Axiom we are free to say that MyDomain is in MyCategory,
but certain assertions that we as mathematicians know about all Domains
in MyCategory may not be true in MyDomain. Will literate programming
help? Maybe. Will it enforce? Nope.

Another fantastic advantage of OBJ is a view. In Axiom we can not say
that MyDomain forms a Group over the operator * and the operator +,
because the operator is hard-coded into the Group Category. This
sucks. :-( Changing this behaviour is left as an exercise to the reader
with time to rewrite almost all of Axiom. :-)

\start
Date: Mon, 12 Sep 2005 22:27:49 -0400
From: Cliff Yapp
To: list
Subject: Re: Unit package proposals and questions

Just a quick note - I sent my latest attempt at precise definitions of the 
ideas we need to William.  At this point I think we should hash out our 
definitions before we go too much further, since I'm starting to get tangled 
up ;-).

Also - Tim, a question about Axiom in general - Do we have somewhere in Axiom 
a thorough description on the mathematical principles it's based on?  
(Groups, Rings, etc.?)  Do the pamphlet files cover all that?  I'm not sure 
making Axiom into a huge self contained introduction and definition of all 
mathematics is a workable or desirable goal, but it would be nice to define a 
minimum education level needed to work with the system and recommend some 
resources for various education levels to get them started.

\start
Date: Tue, 13 Sep 2005 14:38:47 +0200
From: Martin Rubey
To: Bill Page
Subject: graphs and finite graphs.

Dear Bill,

I think that it is a great thing that you start experimenting with graphs. I
hope I can assist you when it comes to the theoretic framework.

Two (rather different) suggestions:

* you might want to look at how graphs are done in mupad and in
  Mathematica. For Mathematica, the relevant source is available at

  http://www.cs.sunysb.edu/~skiena/combinatorica/

  you will probable have to install MathReader from Wolfram. Mupads libraries
  are open source anyway, and the documentation is well done, too.

* more importantly, I urge you to *sketch* the interactions within the whole
  complex of graph-like structures on a piece of papers -- asking questions,
  where needed.

  I'd love to have (oriented) Matroids, (weighted) Graphs, (weighted) Digraphs,
  greedoids, etc. treated in a uniform fashion. Some thinking should go in the
  appropriate representation, probably. I think that your approach is good,
  though. It would certainly pay to collect the various common data structures
  and see which concepts match and which don't. Note, for example, that
  oriented matroids do *not* correspond to digraphs. Then, we'd have to see
  whether unweighted and weighted graphs should be together in one domain or
  should rather be two domains. It is pretty clear to me that digraphs and
  graphs should be two separate domains, maybe having a common ancestor.

  In fact, what is probably necessary is to find good common ancestors. Note
  that a domain may be of several different categories!



  Some examples for possible coercions:

  weighted Graph +-> weighted Digraph: 

    each edge becomes two arcs in opposite directions, each of the arcs having
    the same weight as the edge.

  Digraph +-> Graph: 

    take the underlying graph. But what happens with weights

  Graph +-> Matroid:
  
    take the cycle matroid of the graph

  Graph +-> Matroid:

    there are other constructions, too.


  3-connected Matroid <-> 3-connected Graph

    it is possible to reconstruct the stars of the graph here.


  etc, etc.

\start
Date: Tue, 13 Sep 2005 09:13:11 -0400
From: Bill Page
To: Peter Broadbery
Subject: RE: help with Aldor categories,

On September 13, 2005 4:57 AM Peter Broadbery wrote:
> > 
> > On September 11, 2005 6:53 PM I wrote:
> > > 
> > > However now in
> > > 
> > > http://axiom-developer.org/SandBoxCategoryOfGraphs
> > >
> > > I get a different apparently more serious error:
> > >
> > >  >> System error:
> > >   AxiomXL file "GRAPHCAT" is missing!
> > > 
> 
> > -----------
> > 
> > The 'file-imports' macro is defined here
> > 
> > http://axiom.axiom-developer.org/src/interp/foam_l.lisp.pamphlet
> 
> > but from this point on I get lost. It is not clear to me where
> > this macro is called nor why it is being called for "GRAPHCAT".
> >
> > These files have your name and Stephen M. Watt listed as
> > authors. I don't suppose you remember what all this was
> > about 10+ years ago :) or do you?
> 
> > Any suggestions as to where I should look?
>
> 11 years ago.  Hmm, I absolutely shouldn't remember.  In any case,
> try explicitly doing )lib graphcat before loading the second file.
> The file-imports macro should probably be smartened up to force an
> autoload, but it hasn't been yet.

I think I already tried what you suggest?

http://axiom-developer.org/SandBoxCategoryOfGraphs

The explicit )library GRAPHCAT command apparently succeeds but
later 'file-imports' still says:

   AxiomXL file "GRAPHCAT" is missing!

Since I can't find a call to 'file-imports' anywhere in the
Axiom src directories (did I miss it?), am I correct that
a call to this macro is contained lisp code generated by
Aldor?

\start
Date: Tue, 13 Sep 2005 09:49:37 -0400
From: Bill Page
To: Nic Doye
Subject: RE: Axiom in general
Cc: Cliff Yapp

On September 13, 2005 6:51 AM Nicolas Doye wrote:

> For those that don't know remember my mini-intro some time
> back, I was one of James Davenport's PhD students charged 
> with finding a mathematical foundation for coercion in Axiom.
> 
> http://worldofnic.org/research/phd.ps
> 
> Chapter 2 of my thesis gave some introduction to the mathematical
> formulation of Categories in Axiom/Magma/OBJ.

Nicolas, I am glad to see you here! I discovered your thesis just
a few weeks ago and put a pdf version here in the Axiom portal
reference section:

http://page.axiom-developer.org/zope/Plone/refs/articles/doye-aldor-phd.
pdf/view

This might be useful for people who are "ps-challenged". Please
let me know if this is acceptible re copyright etc.

> 
> Chapter 3 talks about Category Theory.
> Chapter 4 talks about Order Sorted Algebra.
> (Both these chapters put these definitions in Axiom terms at
> the end).
>

Excellent! I am very interested in putting more category theory
in Axiom.

> Chapter 9 talks about where I'd like Axiom to go.
> 
> Some of my "ideas" in my thesis are wrong and I no longer stand
> by them. I was naive. Please ignore 9.7 and any assertions that
> Axiom should be written in Axiom. ;-)

But perhaps Axiom could/should be written in Aldor?

> 
> In some ways, it is far more useful to not think of Axiom in
> terms of Category Theory. Functors etc. are useful sometimes
> when thinking abstractly about Axiom, but Axiom's true roots
> are in Order Sorted Algebra.

I think it would be great to see an application of Goguen's
"Hidden Algegra" for correctness proofs in Axiom/Aldor:

http://www.cse.ucsd.edu/users/goguen/projs/halg.html

> 
> In axiom a Category is an Order Sorted Signature, but the order
> on the sorts is never explicitly defined and there are some
> difficulties in the definition of the operator symbols.
> 
> OBJ _is_ based on Order Sorted Algebra. It's main advantage over
> Axiom as I see it, is that it defines Theories. A Theory is an
> Order Sorted Signature with (and this is what Axiom misses) a set
> of  equations. This means that in Axiom we are free to say that
> MyDomain is in MyCategory, but certain assertions that we as
> mathematicians know about all Domains in MyCategory may not be
> true in MyDomain. Will literate programming help? Maybe. Will it
> enforce? Nope.
>

It is clear that what Axiom calls a "category" is not a category
in the sense of category theory. I think your approach to
understanding just what is a "category" in Axiom has a lot of
merit.

But of course this is a different objective than *implementing*
category theory in Axiom. This is simply a matter of the design
of appropriate algebra library code. From my point of view a
category (in the sense of category theory) in Axiom must end up
as one or more domains within some Axiom "category" of categories.

This is unfortunate terminology. From the point of view of the
mathematics it might be preferrable to refer to Axiom's concept
of category as a "class" but then that also has terminological
problems.

> Another fantastic advantage of OBJ is a view. In Axiom we can
> not say that MyDomain forms a Group over the operator * and the
> operator +, because the operator is hard-coded into the Group
> Category. This sucks. :-( Changing this behaviour is left as an
> exercise to the reader with time to rewrite almost all of Axiom.
> :-)
> 

We have time here given Tim's "thirty year horizon" ... :)

Do you have any ideas about how we might begin to apply OBJ
to Axiom and Aldor?

\start
Date: Tue, 13 Sep 2005 11:34:32 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: graphs and finite graphs.

Martin,

On September 13, 2005 8:39 AM you wrote:
> 
> I think that it is a great thing that you start experimenting 
> with graphs. I hope I can assist you when it comes to the
> theoretic framework.

Excellent! Thanks.

> 
> Two (rather different) suggestions:
> 
> * you might want to look at how graphs are done in mupad and in
>   Mathematica. For Mathematica, the relevant source is available
>   at
> 
>   http://www.cs.sunysb.edu/~skiena/combinatorica/
> 
>   you will probable have to install MathReader from Wolfram. 
>   Mupads libraries are open source anyway, and the documentation
>   is well done, too.
>

I am reasonably familiar with graph theory from a computer
science perspective and from the point of view of category
theory. What I had in mind is an implementation of graphs in
Axiom more or less from first principles. Looking at Mathematica
and Mupad should be interesting as examples of applications
but I am sceptical (maybe I am wrong?) that they would provide
the kind of foundation that is needed in Axiom.

Do you have some specific suggestions for things to look for?
 
> * more importantly, I urge you to *sketch* the interactions 
> within the whole complex of graph-like structures on a piece
> of papers -- asking questions, where needed.

That is a good idea, but for other reasons I am motivated to
use MathAction SandBox and email rather than paper. :)

> 
>   I'd love to have (oriented) Matroids, (weighted) Graphs, 
> (weighted) Digraphs, greedoids, etc. treated in a uniform
> fashion.

Yes. One of the things I want graphs for in Axiom is that
(eventually) I also want categories. Being able to explore
matroids in Axiom is also very attractive. We (including
Bertfried Fauser) discussed matroids here long ago in connection
with general (possibly cyclical) dependency structures in
Axiom.

But more immediately, I think FiniteGraph would be very useful
for an implementation of the dependency computation in Peter
Broadbery's Aldor interface (to replace the Java code). To do
that it makes sense to implement this code in Aldor so that it
could be compiled stand alone. But trying this in Axiom lead me
to the distraction of an apparent problem in the way Aldor
categories are handled in Axiom.

Still, this can be done entirely in Axiom with SPAD for now
and we can worry about porting it to Aldor later.

> Some thinking should go in the appropriate representation,
> probably. I think that your approach is good, though. It would
> certainly pay to collect the various common data structures
> and see which concepts match and which don't.

I expect that one would need multiple representations depending
on the particular purpose. For example, from a formal point of
view I want both FiniteGraph with explicit added nodes and
edges, as well as the IntegerGraph with the < order relation to
be in GraphCategory. The issue here with respect to defining
GraphCategory seems to be as inclusive as possible in the
interface, i.e. the exported operations. In both the example
graph domains above I can ask

  edge?(n1,n2)

but I might not expect

  edgeList(G)

to be available for all domains in GraphCategory (although
perhaps in the case of IntegerGraph, it might return an iterator).

> Note, for example, that oriented matroids do *not* correspond
> to digraphs. Then, we'd have to see whether unweighted and
> weighted graphs should be together in one domain or should
> rather be two domains.

I would expect two domains but *maybe* in the same category.
Maybe GraphCategory can be defined from MatroidCategory?

> It is pretty clear to me that digraphs and graphs should be
> two separate domains, maybe having a common ancestor.
>

Undirected graphs (as an Axiom category) could be defined in
terms of directed graphs with an extra condition and then a
undirected graph might be represented as a pair of directed
edges, etc. But this might not be particularly efficient for
some graph algorithms. It is certainly an advantage in Axiom
that we can (usually) write polymorphic algorithms that can
be applied independent of the underlying representation. In
other cases the algorithms might need to take specific advantage
of a given representation. I think I understand how this can
be made to work in Axiom.

So for me the design issues concern mostly how we might choose
to encode the known mathematics of graphs (and related
combinatoric structures) in Axiom at a higher level, i.e. in
terms of Axiom categories.
 
>   In fact, what is probably necessary is to find good common 
> ancestors. Note that a domain may be of several different
> categories!
>

Yes, that is quite important. In Axiom we are not constrained
to simply define class hierarchies.
 
> 
>   Some examples for possible coercions:
> 
>   weighted Graph +-> weighted Digraph: 
>

Agreed.
 
>     each edge becomes two arcs in opposite directions, each 
> of the arcs having the same weight as the edge.
> 
>   Digraph +-> Graph: 
>
>     take the underlying graph. But what happens with weights

Probably we need to consider other functors in addition to
coercions? I would really like to have more "category theory"
here in Axiom to deal with things like this.

> 
>   Graph +-> Matroid:
>   
>     take the cycle matroid of the graph
> 
>   Graph +-> Matroid:
> 

I am interested in this. Could you elaborate a little?

>     there are other constructions, too.
> 
>   3-connected Matroid <-> 3-connected Graph
> 
>     it is possible to reconstruct the stars of the graph here.
> 
>   etc, etc.

Yes, I agree that being able to express these mathematical
concepts in Axiom is a very desirable goal!

\start
Date: Tue, 13 Sep 2005 22:36:30 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [the Axiom Community] 

"irc://irc.freenode.net/#axiom-developer":irc://irc.freenode.net/#axiom-developer

\start
Date: Tue, 13 Sep 2005 23:03:57 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [the Axiom Community] 

"Web Chat":http://webchat.xs4all.nl/cgi-bin/ircnet/irc.cgi

\start
Date: Tue, 13 Sep 2005 23:08:28 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [the Axiom Community] 

  There is an irc channel where developers can find other developers. It is:: 
  
      server: irc.freenode.net 
      channel:#axiom-developer

\start
Date: Wed, 14 Sep 2005 09:52:19 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: graphs and finite graphs.

Dear Bill,

Bill Page writes:

 > > * you might want to look at how graphs are done in mupad and in
 > >   Mathematica. 

 > Looking at Mathematica and Mupad should be interesting as examples of
 > applications but I am sceptical (maybe I am wrong?) that they would provide
 > the kind of foundation that is needed in Axiom.

Exactly.

 > Do you have some specific suggestions for things to look for?

not yet. One idea I had when I implemented my graphs-package for maxima (which
is not in a useable state, though) is to extensively use lazy evaluation, very
much like the way polymake works. In terms of graphs, a graph would be
represented by a list of properties, and when you ask for some property, like,
for example, connected?, the list is searched for the property itself, then for
other properties which might imply connectedness and if all fails, an algorithm
that computes the desired property is invoked. This idea works well, if the
amount of storage needed doesn't matter or else for properties that don't need
much, like the chromatic index or the Tutte polynomial. It is, of course,
nearly the same as caching previously computed values. (Nearly, because
sometimes a property has already been computed that implies the desired
property.)


 > > I'd love to have (oriented) Matroids, (weighted) Graphs, (weighted)
 > > Digraphs, greedoids, etc. treated in a uniform fashion.

I missed polytopes and simplicial complexes. Oh my god!

 > > Some thinking should go in the appropriate representation, probably. I
 > > think that your approach is good, though. It would certainly pay to
 > > collect the various common data structures and see which concepts match
 > > and which don't.
 > 
 > I expect that one would need multiple representations depending on the
 > particular purpose. For example, from a formal point of view I want both
 > FiniteGraph with explicit added nodes and edges, as well as the IntegerGraph
 > with the < order relation to be in GraphCategory. The issue here with
 > respect to defining GraphCategory seems to be as inclusive as possible in
 > the interface, i.e. the exported operations. In both the example graph
 > domains above I can ask
 > 
 >   edge?(n1,n2)
 > 
 > but I might not expect
 > 
 >   edgeList(G)
 > 
 > to be available for all domains in GraphCategory (although
 > perhaps in the case of IntegerGraph, it might return an iterator).

Yes, I very much like the idea to have a category of graphs and then domains
for finite and infinite graphs. (I think that there is not yet a package that
handles infinite graphs at all.)

 > > Then, we'd have to see whether unweighted and weighted graphs should be
 > > together in one domain or should rather be two domains.
 > 
 > I would expect two domains but *maybe* in the same category.

Exactly.

 > Maybe GraphCategory can be defined from MatroidCategory?

Hmm, maybe we shouldn't have categories for structures (like matroids, graphs,
digraphs, etc.) but rather for properties. In fact, this led to a definition of
matroid: a matroid is a collection I of sets (called independend sets) such
that

* \emptyset \in I

* I1\in I and I2\subseteq I1 => I2\in I

* the greedy algorithm works, i.e., it always finds a set I1 \in I achieving
  the maximum weight, regardless of the (nonnegative) weight function.

 > > It is pretty clear to me that digraphs and graphs should be two separate
 > > domains, maybe having a common ancestor.
 > 
 > Undirected graphs (as an Axiom category) could be defined in terms of
 > directed graphs with an extra condition and then a undirected graph might be
 > represented as a pair of directed edges, etc.

I'm afraid that this can lead to trouble. It can be done - and it might be even
the *right* way to do it, but it entails a lot of work. Many concepts used for
graphs and digraphs nearly match but not quite. One example, which does work is
the concept of degree: the degree in the graph is the indegree (which equals
the outdegree) in the corresponding digraph.

But as I noted before: what are we going to do with the weights. Usually, the
degree in a graph is the sum of the weights of the edges. This will be the same
as the sum of the weight of the incoming arcs in the corresponding digraph.

However: the total weight of the graph is (usually) the product of all its edge
weights. Hence the total weight of the corresponding digraph is the weight of
the graph squared. Thus we can have an operation weight in the category of all
graphs, but it means slightly different things in digraphs and in graphs.

 > > In fact, what is probably necessary is to find good common ancestors. Note
 > > that a domain may be of several different categories!
 > 
 > Yes, that is quite important. In Axiom we are not constrained to simply
 > define class hierarchies.

So, the first step possibly is to propose some categories. A different approach
is to concentrate on finite graphs first and write the categories later.

 > >   Digraph +-> Graph: 
 > >
 > >     take the underlying graph. But what happens with weights
 > 
 > Probably we need to consider other functors in addition to coercions? I
 > would really like to have more "category theory" here in Axiom to deal with
 > things like this.

I don't understand you here.

 > >   Graph +-> Matroid:
 > >   
 > >     take the cycle matroid of the graph
 > > 
 > >   Graph +-> Matroid:
 > 
 > I am interested in this. Could you elaborate a little?

Elaborate on what, other constructions?

 > >     there are other constructions, too.


\start
Date: Wed, 14 Sep 2005 12:14:42 -0700
From: Bob McElrath
To: list
Subject: Re: axiom--GUI--1

I wanted to play with axiomui, so I checked out this branch.

Just a couple of niggles:
    1) the Makefile.pamphlet contains default paths ${AXIOM}/bin/lib/
    for notangle and noweave.  This path is highly nonstandard...  For
    instance the debian package 'nowebm' puts these files in /usr/bin
    (and note this is also unrelated to ${AXIOM}).

    2) AXIOMsys needs to have a path from ${AXIOM}

    3) the server is actually listening on port 8080, not 5050 as the
    documentation states.

looks good!

Here is a patch for these changes:
--- orig/src/web-gui/Makefile.pamphlet
+++ mod/src/web-gui/Makefile.pamphlet
@@ -10,9 +10,10 @@
 \section{Makefile}
 
 <<*>>-TANGLE=${AXIOM}/bin/lib/notangle -t8
-WEAVE=${AXIOM}/bin/lib/noweave -delay
+TANGLE=/usr/bin/notangle -t8
+WEAVE=/usr/bin/noweave -delay
 LISP=clisp
+AXIOMSYS=${AXIOM}/bin/AXIOMsys
 
 
 DEP =  axiom-com.lisp \
@@ -55,7 +56,7 @@
 doc: $(DOCDEP)
 
 compile:
-       @echo ")compile uidraw.spad"|AXIOMsys
+       @echo ")compile uidraw.spad"|${AXIOMSYS}
        ${LISP} -norc -i make-image.lisp
        @echo "#!/bin/sh" > run-axiom-ui.sh
        @echo "clisp -M " `pwd`/axiom-ui.mem >> run-axiom-ui.sh

\start
Date: Wed, 14 Sep 2005 15:56:41 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: axiom--GUI--1

On Wednesday, September 14, 2005 3:15 PM Bob McElrath wrote:

> To: arch@axiom-developer.org

Who is "arch@axiom-developer.org"? Is this intended to queue
the patch for inclusion in the tla archive?

> I wanted to play with axiomui, so I checked out this branch.
>
> Just a couple of niggles:
>    1) the Makefile.pamphlet contains default paths ${AXIOM}/bin/lib/
>    for notangle and noweave.  This path is highly nonstandard...  For
>    instance the debian package 'nowebm' puts these files in /usr/bin
>    (and note this is also unrelated to ${AXIOM}).

I asked Kai to use this path for notangle and noweave since this
is the standard location for the versions of notangle and noweave
that are used with the Axiom build (except for Debian). The Debian
build for Axiom has not been integrated with the other linux
environments. It is maintained by Camm Maguire.

The standard Axiom build applies a simple patch to the notangle.
I am not sure how this is handled on Debian. Camm?

If we were to require notangle and noweave as dependencies on
non-Debian systems, satisfying the dependencies might not be
so straight forward on some systems. Also, since Axiom patches
notangle in a way that was not accepted by it's original author,
it does not seem like such a good thing for the Axiom to place
it's versions in /usr/bin ...

>    2) AXIOMsys needs to have a path from ${AXIOM}

I am not sure I understand what you mean here. Normally AXIOMsys
is accessible from the PATH if Axiom has been installed. Is this
not true on Debian?

>    3) the server is actually listening on port 8080, not 5050 as
>       the documentation states.
>
> looks good!

I think we need to make some plans as to were to go from here.

For instance, what we have right now is essentially a replacement
for "console-style" input but with nicely formatted math output
and in-line 2-d graphics. Kai has also implemented, but not yet
integrated with the current version, the hyperdoc Axiom documentation
browser.

I think what we really want (at least what I want :) is a
"worksheet-style" interface looks (more or less) like MathAction
but tailored for individual use (like tiddlywiki). Also of course
there is the question of how to handle 3-d graphics and how to
interact with the graphics in a manner similar to the existing
Axiom graphics package on linux.

One (perhaps longer term?) goal of this re-implementation of
features is to provide the same or equivalent features in a
platform independent implementation that will work the same
on both linux and windows. So far the current version does not
(quite) work on Windows due some non-portable clisp code.

Let's discuss this a little more...

Regards,
Bill Page.

--------

Here is a patch for these changes:
--- orig/src/web-gui/Makefile.pamphlet
+++ mod/src/web-gui/Makefile.pamphlet
@@ -10,9 +10,10 @@
 \section{Makefile}

 <<*>>-TANGLE=${AXIOM}/bin/lib/notangle -t8
-WEAVE=${AXIOM}/bin/lib/noweave -delay
+TANGLE=/usr/bin/notangle -t8
+WEAVE=/usr/bin/noweave -delay
 LISP=clisp
+AXIOMSYS=${AXIOM}/bin/AXIOMsys


 DEP =  axiom-com.lisp \
@@ -55,7 +56,7 @@
 doc: $(DOCDEP)

 compile:
-       @echo ")compile uidraw.spad"|AXIOMsys
+       @echo ")compile uidraw.spad"|${AXIOMSYS}
        ${LISP} -norc -i make-image.lisp
        @echo "#!/bin/sh" > run-axiom-ui.sh
        @echo "clisp -M " `pwd`/axiom-ui.mem >> run-axiom-ui.sh

\start
Date: Wed, 14 Sep 2005 15:59:29 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [AxiomDownload] 

    1 You must use the 3.1 (Sarge) version of Debian.

   "unstable":http://www.debian.org/releases/unstable/ distribution. E.g.:<pre>
deb http://http.us.debian.org/debian unstable main contrib non-free</pre>

\start
Date: Wed, 14 Sep 2005 15:56:35 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [AxiomDownload] 

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

\start
Date: Wed, 14 Sep 2005 14:01:39 -0700
From: Bob McElrath
To: list
Subject: download link doesn't work

The download link on this page:
    http://www.axiom-developer.org/zope/mathaction/AxiomDownload
doesn't work.  Specifically this link:
    http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Sept2005-src.tgz
doesn't work, and I can't find the tarball anywhere on
axiom.axiom-developer.org...

I fixed the links on that page for Debian, which is now in "unstable"
that Sarge has been released.

Also FYI I'm trying to get Kai's axiom--GUI-1 to work, and it seems that
it doesn't like axiom 3.4 from April.  After typing in a command it
quits with just "Bye".

\start
Date: Wed, 14 Sep 2005 17:52:14 -0400
From: Bill Page
To: Bob McElrath
Subject: download links and server names (was: axiom--GUI--1)

On Wednesday, September 14, 2005 3:15 PM Bob McElrath wrote:

> The download link on this page:
>    http://www.axiom-developer.org/zope/mathaction/AxiomDownload
> doesn't work.  Specifically this link:

http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Sept2005-
src.tgz
> doesn't work, and I can't find the tarball anywhere on
> axiom.axiom-developer.org...

Sorry, Bob, my mistake. I have been trying to rationalize things
on the various virtual server names that we use on axiom-developer
and I forgot about that download links. It should work now.

My goal is to setup some simple virtual server names and shorten
the urls as much as possible. Now by default

http://axiom.axiom-developer.org

will list the current Axiom source in the darcs repository for
axiom--main--1 on axiom-developer. This is the version of Axiom
that is currently running on this server and may lag slightly
the version in tla. My plan is that this souce will (eventually)
be searchable online and will be available for direct url
reference.

Just yesterday I finished setting up a new name for the Axiom
wiki.

http://wiki.axiom-developer.org

should now work to access MathAction with the shortest possible
urls. These are exactly the same pages addressed by:

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

and

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

and

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

For now these older names should continue to work. But eventually
when this is all done, I would like to retire those that are
clearly redundant.

I am also planning to implement

http://portal.axiom-developer.org

which will be identical to

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

If anyone has any comments about this re-organization, please
let me know.

> I fixed the links on that page for Debian, which is now in
> "unstable" that Sarge has been released.

Thanks!

> Also FYI I'm trying to get Kai's axiom--GUI-1 to work, and it
> seems that it doesn't like axiom 3.4 from April.  After typing
> in a command it quits with just "Bye".

Isn't that the version that Kai recommended in the docs?

In my case I tested axiom--GUI--1 with Axiom build with the
axiom--main--1--patch-45 sources.

\start
Date: Wed, 14 Sep 2005 15:16:06 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Bob McElrath
Subject: Re: download links and server names 

--- Bill Page wrote:
>
> I am also planning to implement
> 
> http://portal.axiom-developer.org
> 
> which will be identical to
> 
> http://page.axiom-developer.org/zope/Plone
> 
> If anyone has any comments about this re-organization, please
> let me know.

I suspect I missed a discussion from a while back, but I am a bit
surprised www.axiom-developer.org doesn't default to
http://page.axiom-developer.org/zope/Plone It seems to be a little
easier to follow to my eye, and has a clean, modern look that seems a
bit more professional than the current default.  With the relevant
content from the current Frontpage on it it would seem to be a good
first impression of Axiom.  (Please note this is just one guy's opinion
from a casual glance - I apologize if there are good reasons for the
current setup I'm not thinking of.)

\start
Date: Wed, 14 Sep 2005 17:07:08 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [AxiomDownload] 

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

\start
Date: Wed, 14 Sep 2005 15:04:11 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: download links and server names (was: axiom--GUI--1)

Page, Bill [Bill Page] wrote:
> 
> Just yesterday I finished setting up a new name for the Axiom
> wiki.
> 
> http://wiki.axiom-developer.org

Also this page contains "axiomicon.png" which doesn't exist, and causes
a reflow...

\start
Date: Wed, 14 Sep 2005 15:01:18 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: download links and server names (was: axiom--GUI--1)

Page, Bill [Bill Page] wrote:
> On Wednesday, September 14, 2005 3:15 PM Bob McElrath wrote:
> 
> > The download link on this page:
> >    http://www.axiom-developer.org/zope/mathaction/AxiomDownload
> > doesn't work.  Specifically this link:
>  
> http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Sept2005-
> src.tgz
> > doesn't work, and I can't find the tarball anywhere on
> > axiom.axiom-developer.org...
> 
> Sorry, Bob, my mistake. I have been trying to rationalize things
> on the various virtual server names that we use on axiom-developer
> and I forgot about that download links. It should work now.
> 
> My goal is to setup some simple virtual server names and shorten
> the urls as much as possible. Now by default


That's a very good idea.

> Just yesterday I finished setting up a new name for the Axiom
> wiki.
> 
> http://wiki.axiom-developer.org

On this page could you add explicit "width" and "height" attributes for
the img tags?  This page "reflows" several times during load, as it gets
each of the images and determines their size...

> For now these older names should continue to work. But eventually
> when this is all done, I would like to retire those that are
> clearly redundant.

I think they should be retired ASAP as the site organization has been
quite confusing.

> I am also planning to implement
> 
> http://portal.axiom-developer.org
> 
> which will be identical to
> 
> http://page.axiom-developer.org/zope/Plone
> 
> If anyone has any comments about this re-organization, please
> let me know.

I think we should decide on one or the other.  Having multiple sites
makes it very confusing.

> > Also FYI I'm trying to get Kai's axiom--GUI-1 to work, and it
> > seems that it doesn't like axiom 3.4 from April.  After typing
> > in a command it quits with just "Bye". 
> 
> Isn't that the version that Kai recommended in the docs?

Yes.  I'm building the savannah CVS tarball now.  If that doesn't work
then I have some other problem...

\start
Date: Wed, 14 Sep 2005 18:26:03 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: download links and server names (was: axiom--GUI--1)

On Wednesday, September 14, 2005 6:04 PM Bob McElrath wrote:
> ...
> >
> > http://wiki.axiom-developer.org
>
> Also this page contains "axiomicon.png" which doesn't exist,
> and causes a reflow...
>

Ok, fixed I think. Also the CAISS logo and I included height and
width for each image.

Better?

\start
Date: Wed, 14 Sep 2005 17:08:20 -0500
From: MathAction (anonymous)
To: MathAction
Subject: [AxiomDownload] 

sources":Mirrors?go=http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Sept2005-src.tgz&it=September+2005+Sources

\start
Date: Wed, 14 Sep 2005 18:04:05 -0500
From: MathAction (Bob McElrath)
To: MathAction
Subject: [build Axiom] The savannah tarball is a copy of the CVS tree, and thus, useless to most everyone.

  As of September 2005 the current release is Axiom 3.9.

  You can download the source as a tarball in AxiomDownload or
  download the source tree via CVS::

\start
Date: Wed, 14 Sep 2005 18:37:12 -0400
From: Bill Page
To: Bob McElrath
Subject: RE: download links and server names (was: axiom--GUI--1)

On Wednesday, September 14, 2005 6:01 PM Bob McElrath wrote:
> ...
> >
> > My goal is to setup some simple virtual server names and shorten
> > the urls as much as possible. Now by default
>
>
> That's a very good idea.
>
> > Just yesterday I finished setting up a new name for the Axiom
> > wiki.
> >
> > http://wiki.axiom-developer.org
>
> On this page could you add explicit "width" and "height" attributes
> for the img tags?  This page "reflows" several times during load,
> as it gets each of the images and determines their size...

Maybe you should use a smarter browser? ;) FireFox doesn't do
that to me.

Ok, I added the width and height. Is that better?

>
> > For now these older names should continue to work. But eventually
> > when this is all done, I would like to retire those that are
> > clearly redundant.
>
> I think they should be retired ASAP as the site organization has been
> quite confusing.

It's hard to make changes quickly when things have been around
for a while. I worry about broken links. But when everything is
working nicely, then it makes sense to me to advertize the
changes widely and then set a time limit like 1 month before
removing the old names.

>
> > I am also planning to implement
> >
> > http://portal.axiom-developer.org
> >
> > which will be identical to
> >
> > http://page.axiom-developer.org/zope/Plone
> >
> > If anyone has any comments about this re-organization, please
> > let me know.
>
> I think we should decide on one or the other.  Having multiple
> sites makes it very confusing.
>

Do you mean decide on "wiki" or "portal", i.e. Plone? I have also
had this discussion with Martin Rubey. I have argued that these
are two quite different web services. The wiki is open and public
while the portal has more controlled access for content creation.
It is possible to create both public and private wiki pages in Plone
and there are other features of the portal such as bibliography,
event notices, etc.

Of course the user interface for the wiki is much simpler than the
portal. So far the portal has not had much use although nearly 60
people have registered to use it. But then again, only a very few
people have even edited any wiki pages. So I guess that's how it
goes in the "collaborative web" :-(

\start
Date: Wed, 14 Sep 2005 18:24:34 -0500
From: MathAction (unknown)
To: MathAction
Subject: [AxiomDownload] compilation of axiom-Sept2005

>can you start the bootsys image by hand?

/usr/local/src/axiom/obj/linux/bin/bootsys

bash: /usr/local/src/axiom/obj/linux/bin/bootsys: No such file or directory


ls -l /usr/local/src/axiom/obj/linux/bin/

-rwxr-xr-x  1 root root 5173900 2005-09-09 14:12 lisp

\start
Date: Wed, 14 Sep 2005 16:19:31 -0700
From: Bob McElrath
To: Bill Page
Subject: Re: download links and server names (was: axiom--GUI--1)

Page, Bill [Bill Page] wrote:
> Maybe you should use a smarter browser? ;) FireFox doesn't do
> that to me.

It was the missing image that was causing the reflow.  (I am using
firefox ;)

> Do you mean decide on "wiki" or "portal", i.e. Plone? I have also
> had this discussion with Martin Rubey. I have argued that these
> are two quite different web services. The wiki is open and public
> while the portal has more controlled access for content creation.
> It is possible to create both public and private wiki pages in Plone
> and there are other features of the portal such as bibliography,
> event notices, etc.

If you really like plone, why not move all wiki pages into plone?

> Of course the user interface for the wiki is much simpler than the
> portal. So far the portal has not had much use although nearly 60
> people have registered to use it. But then again, only a very few
> people have even edited any wiki pages. So I guess that's how it
> goes in the "collaborative web" :-(

I like the improvements you've made on the wiki a lot.  I would add that
we should separate the "discussion" page from the wiki page itself.
(Just make a [Page Discussion] wiki page where emails and comments go)
ZWiki collects page clutter quickly since comments get added to the same
page, then everyone is afraid to delete them, and there is no automated
method to archive them.

If we all prefer the ZWiki interface though, then we need to add user
login.  This product looks good:
    http://www.zope.org/Members/levi/SessionUserFolder

\start
Date: Wed, 14 Sep 2005 18:50:15 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [the Axiom Community] 

  - "Web-based IRC Chat":http://www.polarhome.com/cgi-bin/chat/irc.cgi

\start
Date: Thu, 15 Sep 2005 08:01:57 +0100
From: Peter Broadbery
To: Bill Page
Subject: Re: help with Aldor categories, graphs and finite graphs.

On Sun, 2005-09-11 at 18:52 -0400, Bill Page wrote:
> On Sun, 2005-09-11 at 11:52 -0400, Peter Broadbery wrote:


> However now in
> 
> http://www.axiom-developer.org/zope/mathaction/SandBoxCategoryOfGraphs
> 
> I get a different apparently more serious error:
> 
>   >> System error:
>    AxiomXL file "GRAPHCAT" is missing!
> 
> This error occurs when trying to call new()$FiniteGraph(INT) in spite
> of having already successfully defined g as a FiniteGraph.
> 
> Ideas? Is this a "system error" or just another "user error"?

Found it - aldor is being picky about the case of file names; it
(effectively) requires that aldor file names should be all lower case. 

I'm not precisely sure what is doing the downcasing;  I suspect that the
function set-file-getter and other things in daase.lisp are involved,
but it needs a bit more tracing down.

\start
Date: Thu, 15 Sep 2005 04:08:42 -0400
From: Bill Page
To: Peter Broadbery
Subject: RE: help with Aldor categories, graphs and finite graphs.

On Thursday, September 15, 2005 3:02 AM Peter Broadbery wrote:
> >
> >   >> System error:
> >    AxiomXL file "GRAPHCAT" is missing!
> >
>
> Found it - aldor is being picky about the case of file names; it
> (effectively) requires that aldor file names should be all lower
> case.
>

Good work!

> I'm not precisely sure what is doing the downcasing;  I suspect
> that the function set-file-getter and other things in daase.lisp
> are involved, but it needs a bit more tracing down.
>

Since daase calls pathname-name all over the place could it be
related to this email exchange between Tim Daly and Camm Maquire?

[Gcl-devel] pathname-name behavior change

http://lists.gnu.org/archive/html/gcl-devel/2004-12/msg00001.html

\start
Date: Thu, 15 Sep 2005 03:52:51 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [LatexTemplate] 

\newenvironment{axiom}{\begin{verbatim}}{\end{verbatim}}

\start
Date: Thu, 15 Sep 2005 03:31:40 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [LatexTemplate] 

\newenvironment{axiom}{}{}
\newenvironment{aldor}{}{}
\newenvironment{spad}{}{}

\start
Date: Thu, 15 Sep 2005 04:08:26 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [LatexTemplate] 

\usepackage{verbatim}

\makeatletter
\newenvironment{axiom}
  {\verbatim}
  {\endverbatim}
\makeatother
\begin{document}
\Huge% will have no effect!
\begin{spsstab}[htb]{Table header}
  Another verbatim environment.
\end{spsstab}
\end{document}

\start
Date: Thu, 15 Sep 2005 05:22:00 -0400
From: Bill Page
To: Peter Broadbery
Subject: RE: help with Aldor categories, graphs and finite graphs.

Peter,

On Thursday, September 15, 2005 3:02 AM you wrote:
> >
> >   >> System error:
> >    AxiomXL file "GRAPHCAT" is missing!
> >
>
> Found it - aldor is being picky about the case of file names;
> it (effectively) requires that aldor file names should be all
> lower case.
>

Yes, I think you are right. I changed the short name (abbreviationfile name?) of my Aldor category from upper case to lower case and
now it **sometimes** works. See:

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

But often when I try to save this page I get:

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

And Axiom aborts near completion.

The problem seems to be intermittent. About 1 time out of 5 when
I save the page it succeeds as you see it above.  Odd that I
don't get the same result each time since it starts a new Axiom
session each time! This seems like it might be some interaction
between Axiom's requirements and GCL's memory allocation. Yuck.

\start
Date: Thu, 15 Sep 2005 05:57:49 -0400
From: Bill Page
To: Peter Broadbery
Subject: RE: help with Aldor categories, graphs and finite graphs.

On Thursday, September 15, 2005 5:22 AM I wrote:

> ...
> Yes, I think you are right. I changed the short name (abbreviation> file name?) of my Aldor category from upper case to lower case and
> now it **sometimes** works. See:
>
> http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs
>
> But often when I try to save this page I get:
>
>     >> System error:
>     Contiguous blocks exhausted.
>   Currently, 1354 pages are allocated.
>   Use ALLOCATE-CONTIGUOUS-PAGES to expand the space.
>

In several tests, it seems like the Axiom/lisp command:

  )lisp (si::allocate-contiguous-pages 3000 t)

might cure the problem. If this is a memory allocation problem,
then perhaps this can be specified as larger default when the
Axiom build build compiles GCL? Does anyone know the correct
build parameter to set?

\start
Date: Thu, 15 Sep 2005 05:09:46 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#205 Hyperdoc does not work in patch 44] 

                          AXIOM Computer Algebra System
                       Version: Axiom 3.9 (September 2005)
               Timestamp: Thursday September 1, 2005 at 14:41:01
  -----------------------------------------------------------------------------
     Issue )copyright to view copyright notices.
     Issue )summary for a summary of useful system   commands.
     Issue )quit to leave AXIOM and return to shell.
  -----------------------------------------------------------------------------

     Re-reading compress.daase   Re-reading interp.daase
     Re-reading operation.daase
     Re-reading category.daase
     Re-reading browse.daase
  (1) ->
  syntax error: expected a newcommand
  not a word
  (HyperDoc) While parsing RootPage on line 1
          in the file /home/rubey/axiom/mnt/linux/doc/hypertex/pages/rootpage.ht
  Trying to print the next ten tokens
  \{ up3d \} \} \par \newcommand \{ \MenuDotBitmap \} \{
  syntax error: expected a newcommand
  not a word
  (HyperDoc) While parsing ErrorPage on line 1
          in the file /home/rubey/axiom/mnt/linux/doc/hypertex/pages/util.ht
  Trying to print the next ten tokens
  \{ ProtectedQuitPage \} \} \newcommand \{ \UpButton \} \{ \upbutton

The error goes away if you replace '/axiom/mnt/linux/doc/hypertex/pages/util.ht' by a version preceding 'patch-44'.

\start
Date: Thu, 15 Sep 2005 13:56:58 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: help with Aldor categories, graphs and finite graphs.

Le jeudi 15 septembre 2005 =E0 05:57 -0400, Page, Bill a =E9crit :
> On Thursday, September 15, 2005 5:22 AM I wrote:
>
> > ...
> > Yes, I think you are right. I changed the short name (abbreviation> > file name?) of my Aldor category from upper case to lower case and
> > now it **sometimes** works. See:
> >
> > http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs
> >
> > But often when I try to save this page I get:
> >
> >     >> System error:
> >     Contiguous blocks exhausted.
> >   Currently, 1354 pages are allocated.
> >   Use ALLOCATE-CONTIGUOUS-PAGES to expand the space.
> >
>
> In several tests, it seems like the Axiom/lisp command:
>
>   )lisp (si::allocate-contiguous-pages 3000 t)
>
> might cure the problem. If this is a memory allocation problem,
> then perhaps this can be specified as larger default when the
> Axiom build build compiles GCL? Does anyone know the correct
> build parameter to set?

Change in Makefile.linux

GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
--enable-maxpage=128*1024"

to

GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
--enable-maxpage=256*1024"

\start
Date: Thu, 15 Sep 2005 08:20:54 -0500
From: MathAction (root)
To: MathAction
Subject: [#205 Hyperdoc does not work in patch 44]

odd. there have been no changes to util.ht as far as i'm aware.
the last change in the changelog is from december 2004.

i'll look into the history to see if anything changed.

\start
Date: Thu, 15 Sep 2005 09:58:07 -0400
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: help with Aldor categories, graphs and finite graphs.

Change in Makefile.linux 

> GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> --enable-maxpage=128*1024"
> 
> to 
> 
> GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> --enable-maxpage=256*1024"

I've changed that in patch-46 (which is not up yet).

\start
Date: Thu, 15 Sep 2005 12:06:56 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: help with Aldor categories, graphs and finite graphs.

On Thursday, September 15, 2005 7:57 AM Vanuxem Gr=E9gory wrote:
>
> Change in Makefile.linux
>
> GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> --enable-maxpage=128*1024"
>
> to
>
> GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> --enable-maxpage=256*1024"
>

Thanks! I guess that would be in the <<Makefile.linux>> section
of Makefile.pamphlet which in turn calls <<GCLOPTS>> which
eventually creates Makefile.linux, right? I am currently
rebuilding Axiom on MathAction right now with this increased
parameter.

\start
Date: Thu, 15 Sep 2005 18:32:21 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: help with Aldor categories, graphs and finite graphs.

Le jeudi 15 septembre 2005 =E0 12:27 -0400, Page, Bill a =E9crit :
> On Thursday, September 15, 2005 12:17 PM I wrote:
>
> >
> > Oops... the build just died with: NULL_OR_ON_C_STACK macro invalid
> >
> >...
> > Maybe the parameter needs to be a little smaller?
> >
>
> Hmmm... but if I try 192 instead of 128 or 256 then the GCL build stops
> with the message: "MAXPAGE is not a power of 2".
>
> I'm stumped. :(
>
> Are you sure that this is the option related to ALLOCATE-CONTIGUOUS-PAGES ?

I've encountered your problem and augmenting MAXPAGE resolve it.

\start
Date: Thu, 15 Sep 2005 12:27:55 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: help with Aldor categories, graphs and finite graphs.

On Thursday, September 15, 2005 12:17 PM I wrote:

>
> Oops... the build just died with: NULL_OR_ON_C_STACK macro invalid
>
>...
> Maybe the parameter needs to be a little smaller?
>

Hmmm... but if I try 192 instead of 128 or 256 then the GCL build stops
with the message: "MAXPAGE is not a power of 2".

I'm stumped. :(

Are you sure that this is the option related to ALLOCATE-CONTIGUOUS-PAGES ?

\start
Date: Thu, 15 Sep 2005 12:13:27 -0400
From: Tim Daly
To: Bill Page
Subject: Re: help with Aldor categories, graphs and finite graphs.

yes, that's where i changed it. --t

\start
Date: Thu, 15 Sep 2005 18:21:00 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: help with Aldor categories, graphs and finite graphs.

Hi,

> -----Message d'origine-----
> De : Page, Bill [mailto:Bill Page]
> Envoy=E9 : jeudi 15 septembre 2005 18:17
> =C0 : Vanuxem Gr=E9gory
> Cc : list; Bill Page
> Objet : RE: help with Aldor categories, graphs and
> finite graphs.
>
>
> On Thursday, September 15, 2005 12:07 PM I wrote:
> > > ...
> > > GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> > > --enable-maxpage=256*1024"
> > >
> >
> > Thanks! I guess that would be in the <<Makefile.linux>> section
> > of Makefile.pamphlet which in turn calls <<GCLOPTS>> which
> > eventually creates Makefile.linux, right? I am currently
> > rebuilding Axiom on MathAction right now with this increased
> > parameter.
> >
>
> Oops... the build just died with: NULL_OR_ON_C_STACK macro invalid
>
> ...
> echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")" >>foo
> /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/raw_pr
> e_gcl
> /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/
> -libdir /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/ < foo
> GCL (GNU Common Lisp)  April 1994  262144 pages
>
> Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
> make[4]: *** [saved_pre_gcl] Error 134
> rm raw_pre_gcl init_pre_gcl.lsp
> make[4]: Leaving directory
> `/home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport'
> make[3]: *** [unixport/saved_pre_gcl] Error 2
> make[3]: Leaving directory
> `/home/page/repository/axiom--main--1/lsp/gcl-2.6.7'
> /bin/sh: line 1: unixport/saved_gcl: No such file or directory
> make[2]: *** [gcldir] Error 127
> make[2]: Leaving directory `/home/page/repository/axiom--main--1/lsp'
> make[1]: *** [lspdir] Error 2
> make[1]: Leaving directory `/home/page/repository/axiom--main--1'
> make: *** [all] Error 2
> [page@axiom-developer axiom--main--1]$
>
> ------
>
> Maybe the parameter needs to be a little smaller?

That works for me.

\start
Date: Thu, 15 Sep 2005 12:17:05 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: help with Aldor categories, graphs and finite graphs.

On Thursday, September 15, 2005 12:07 PM I wrote:
> > ...
> > GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> > --enable-maxpage=256*1024"
> >
>
> Thanks! I guess that would be in the <<Makefile.linux>> section
> of Makefile.pamphlet which in turn calls <<GCLOPTS>> which
> eventually creates Makefile.linux, right? I am currently
> rebuilding Axiom on MathAction right now with this increased
> parameter.
>

Oops... the build just died with: NULL_OR_ON_C_STACK macro invalid

...
echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")" >>foo
/home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/raw_pre_gcl /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/ -libdir /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/ < foo
GCL (GNU Common Lisp)  April 1994  262144 pages

Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
make[4]: *** [saved_pre_gcl] Error 134
rm raw_pre_gcl init_pre_gcl.lsp
make[4]: Leaving directory `/home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport'
make[3]: *** [unixport/saved_pre_gcl] Error 2
make[3]: Leaving directory `/home/page/repository/axiom--main--1/lsp/gcl-2.6.7'
/bin/sh: line 1: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory `/home/page/repository/axiom--main--1/lsp'
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory `/home/page/repository/axiom--main--1'
make: *** [all] Error 2
[page@axiom-developer axiom--main--1]$

------

Maybe the parameter needs to be a little smaller?

\start
Date: Thu, 15 Sep 2005 12:37:08 -0400
From: Bill Page
To: Gregory Vanuxem
Subject: RE: help with Aldor categories, graphs and finite graphs.

On Thursday, September 15, 2005 12:21 PM Vanuxem Gr=E9gory wrote:
> >
> > On Thursday, September 15, 2005 12:07 PM I wrote:
> > > > ...
> > > > GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> > > > --enable-maxpage=256*1024"
> > > >
> > >
> >
> > Oops... the build just died with: NULL_OR_ON_C_STACK macro invalid
> >
>
> That works for me.
>

After editing Makefile.pamphlet and before running 'make' did you
delete 'lsp/gcldir' and 'lsp/gcl-2.6.7' ?

I presume that would be necessary to get Axiom to build a new
version of gcl, right?

\start
Date: Thu, 15 Sep 2005 18:44:35 +0200
From: Gregory Vanuxem
To: Bill Page
Subject: RE: help with Aldor categories, graphs and finite graphs.

Le jeudi 15 septembre 2005 =E0 12:37 -0400, Page, Bill a =E9crit :
> On Thursday, September 15, 2005 12:21 PM Vanuxem Gr=E9gory wrote:
> > >
> > > On Thursday, September 15, 2005 12:07 PM I wrote:
> > > > > ...
> > > > > GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> > > > > --enable-maxpage=256*1024"
> > > > >
> > > >
> > >
> > > Oops... the build just died with: NULL_OR_ON_C_STACK macro invalid
> > >
> >
> > That works for me.
> >
>
> After editing Makefile.pamphlet and before running 'make' did you
> delete 'lsp/gcldir' and 'lsp/gcl-2.6.7' ?
>
> I presume that would be necessary to get Axiom to build a new
> version of gcl, right?

Yes, gcl-2.6.7 and gcldir (my configuration uses MAXPAGE=512*1024).
May be a problem of RAM (i have 1GB).

\start
Date: Thu, 15 Sep 2005 12:27:17 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Questions

I suppose I should know better, but I have a couple "broad scope"
questions about Axiom:

a)  Given the ideal of theoretically backing the mathematics in Axiom
and perhaps even incorporating a proof system into the core design, how
do we handle/document/formalize the interface between "Axiom-level"
code and the underlying lisp functionality?  Ideally, a "provable"
system would be backed by proofs all the way down to the machine code
and chip design levels, but that's well beyond the scope of the Axiom
project.  I'm assuming the point we would want to start using proof
logic is the point where the actual "mathematics" beings, as opposed to
the computational tools and structures needed to support it - is this
correct?  Effectively treat the behavior of the underlying lisp as a
big set of "axioms" (in the mathematical sense) and build off of them?

b)  If we are interested in using Aldor as opposed to Spad for the
"standard" Axiom language, and are forced to re-implement an Aldor
environment due to licensing concerns, would that be the time to build
in proof systems and tools?  Or even if we don't have to redo the
environment - mightn't it still be the time?  Then as we convert things
over to Aldor, document them and prove relevant properties?

c)  I know it's somewhat impractical, but I like the idea of
implementing something once, correctly, documenting it fully, and then
never having to do it again.  Axiom gets closer to that ideal than
virtually any other system I have seen (well, except maybe TeX ;-) and
I think it's one of the great strengths of the program.  I don't know
if unit testing makes much sense for Axiom on the mathematical level
(although perhaps that's what things like CATS are, really) but I can't
help thinking we could benefit if we had some tests which checked for
expected (and depended upon) behaviors from the lisp, OS, windowing
system, or whatever we happen to be depending on.  Ideally, any system
which passed the low level unit tests could properly run Axiom,
although of course more work than that would be needed to rigorously
prove that all answers provided were correct.  Then, if we match those
requirements to things available in the ANSI standard (maybe Paul's
extensive ANSI test suite could provide some ideas for relevant tests
to make), we could claim that it's not our fault if a lisp doesn't
support Axiom ;-)

d)  Tim, assuming I'm not way off base, would it be possible to sort of
define the steps we want to take to get from where we are to the 30
years sytem - e.g. something like:

1) decide on proof system to use, if in fact that's the way we want to
go.
2) integrate proof system with Aldor language and environment
3) outline bootstrapping order in which to document and port systems to
Aldor+Proof Core.
4) As migration occurs, document mathematical theory of all levels and
requirements of Axiom in terms of support from the underlying lisp. 
After a while, with any luck new functionality will be transferred
entirely inside Axiom and the lisp requirements will be clear.

Of course, doing this robustly probably WOULD take 30 years, but then
we would never have to do it again ;-).  I know the more short term
goal is to get the beastie fully working at it's original levels, but
it would be fun to have some broad steps toward the "ideal" Axiom to
start poking around with :-).

\start
Date: Thu, 15 Sep 2005 17:12:08 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Questions

On Thursday, September 15, 2005 3:27 PM C Y wrote:
>
> I suppose I should know better, but I have a couple "broad
> scope" questions about Axiom:

I really like your questions! I would like to see more
discussions of this kind.

>
> a)  Given the ideal of theoretically backing the mathematics
> in Axiom and perhaps even incorporating a proof system into
> the core design, how do we handle/document/formalize the
> interface between "Axiom-level" code and the underlying lisp
> functionality?  Ideally, a "provable" system would be backed
> by proofs all the way down to the machine code and chip design
> levels, but that's well beyond the scope of the Axiom project.

Agreed.

> I'm assuming the point we would want to start using proof
> logic is the point where the actual "mathematics" beings, as
> opposed to the computational tools and structures needed to
> support it - is this correct?

Yes I think so. To me this means specifically the SPAD and/or
Aldor code from the Axiom algebra library.

> Effectively treat the behavior of the underlying lisp as a
> big set of "axioms" (in the mathematical sense) and build
> off of them?

>From my point of view lisp has very little to do with this
issue. Sorry. :) Consider the fact that the Aldor compiler can
output C code which then gets compiled into machine code by a
C compiler like gcc, just as easily as it can produce lisp code
that either gets interpreted or compiled in turn. To say this
with a positive spin: Lisp is too general and flexible a language
to be well suited to mathematical proofs. A "higher level", i.e.
more semantically constrained and focused language (in the sense
of having a smaller set of more complex primitive operations)
such as SPAD or Aldor, is better suited to expressing mathematical
algorithms nearer the conceptual level at which mathematics
itself is done. Of course this is not a claim that such is not
possible in lisp - it's just that the language (or maybe
sometimes just common practice) does not encourage such usage.

The point is that the "meaning" or semantics of SPAD and Aldor
programs can be specified quite independently of the actually
implementation. Most of this specification of meaning actually
involves known mathematics to a much larger extent then the
usual application of proof techniques to the correctness of
programs in general. I think a claim could be made that
proving that a particular algorithm written in SPAD correctly
implements some specific mathematical result or technique might
be considered formally less difficult (in principle) than
general program correctness because most of the proof can be
carried out at a higher level.

I think you are right that proving the correctness of the
compiler itself or the interpreter needs to be addressed at
a different level. Even within Axiom there are several
intermediate levels, e.g. BOOT code, that could be addressed
separately. Then all the way down to machine code and from
there (in principle) even to the physics. But for *mathematics*
I think (almost) all of the interesting stuff is at the
top of this hierarchy of languages.

>
> b)  If we are interested in using Aldor as opposed to Spad for
> the "standard" Axiom language, and are forced to re-implement
> an Aldor environment due to licensing concerns, would that be
> the time to build in proof systems and tools?

Personally I think that failure to include Aldor in with Axiom
because of licensing issues would be a minor disaster for both
Axiom and Aldor. I doubt very much that sufficient interested
resources exist anywhere at this point to take on a task like
re-implementing Aldor. Implementing a compiler for a language like
Aldor is already a very BIG job. And imagining adding a program
proof systems on top of that at the same time does not makes much
sense. Also keep in mind that there are a number of very active
projects in this area already such as Haskell, OCaml and OBJ
(to name just a few).

> Or even if we don't have to redo the environment - mightn't it
> still be the time?  Then as we convert things over to Aldor,
> document them and prove relevant properties?

Yes, I think that is the right approach! That is exactly where
Tim's ideas about literate program should be the most use.

>
> c)  I know it's somewhat impractical, but I like the idea of
> implementing something once, correctly, documenting it fully,
> and then never having to do it again.

I don't think that is just impractical I think it has been
demonstrated many times over that it is *impossible*! From my
point of view good programming practice these days amounts to
finding ways to do many of the same things over again, in fact
several times over, but to do it efficiently and with (much)
less pain. We need methods for fluently "re-factoring" programs
at a very high level - iteratively re-thinking, documenting and
re-implementing the basic internal design and the relationships
between the components. This is one of the essential tasks of
high level programming language design. I think one of the
fascinating aspects of programming languages like SPAD and Aldor
is that they do in fact seem to facilitate this process.

> Axiom gets closer to that ideal than virtually any other system
> I have seen (well, except maybe TeX ;-)

(: choke, cough :)

> and I think it's one of the great strengths of the program.
> I don't know if unit testing makes much sense for Axiom on the
> mathematical level (although perhaps that's what things like
> CATS are, really) but I can't help thinking we could benefit
> if we had some tests which checked for expected (and depended
> upon) behaviors from the lisp, OS, windowing system, or whatever
> we happen to be depending on.  Ideally, any system which passed
> the low level unit tests could properly run Axiom, although of
> course more work than that would be needed to rigorously
> prove that all answers provided were correct.

I think it is much easier to prove "conditional truths",
i.e. proving that the output of a particular algorithm written
in Aldor correctly implements some abstract mathematical
concept ... assuming that the compiler/interpreter and underlying
computer system perform according to spec. Of course this a
weaker result that what the end-user probably desires, but as
far as I can see human intellectual limitations making any
except a level-by-level approach practical.

As I see it "regression testing" is really what Tim's CATS
project can offer - proving that new versions of some package
or module do not produce newly incorrect results which formerly
were deemed to be correct. Or simply showing clearly where the
differences lie. I say "deemed to be correct" because in some
case the lack of formal proofs and the lack of clear and
unambiguous understanding of a problem means that what is
taken to be true at one time *might* change a little over time.

> Then, if we match those requirements to things available in
> the ANSI standard (maybe Paul's extensive ANSI test suite
> could provide some ideas for relevant tests to make), we
> could claim that it's not our fault if a lisp doesn't
> support Axiom ;-)

No, I don't think this is the correct view. It is because of
tools like lisp that we can even work at this higher level
at all. We should not be looking to "move the blame" but
rather thinking in terms of building an elaborate and ever
higher scaffolding - sometimes shoring it up underneath and
sometimes building it higher... (: How's that for imagery? :)

>
> d)  Tim, assuming I'm not way off base, would it be possible
> to sort of define the steps we want to take to get from
? where we are to the 30 years system - e.g. something like:
>
> 1) decide on proof system to use, if in fact that's the way
> we want to go.

I am very interested to see how Tim will respond to this since
very often we have different views although many of our goals
are the same. :) But I would say emphatically "no" to this. I
think Axiom needs to be open to the application of several
different proof methodologies. (notice my emphasis on the word
*open*).

> 2) integrate proof system with Aldor language and environment

Yes. In fact there has already been some published research
on exactly this topic. Check out some of the articles at
http://page.axiom-developer.org/zope/Plone/refs

> 3) outline bootstrapping order in which to document and port
> systems to Aldor+Proof Core.

impractical :(

> 4) As migration occurs, document mathematical theory of all levels
> and requirements of Axiom in terms of support from the underlying
> lisp.

Yes. This is very important. It simply must be done if Axiom's
future is to extend to the 30 year horizon.

> After a while, with any luck new functionality will be transferred
> entirely inside Axiom and the lisp requirements will be clear.

No. This does not make sense to me. As I said, lisp has very
little to do with this - except as an intermediate language that
is well-suited to bridging the gap between machine architecture
and high-level complex programming abstractions. It is well suited
primarily because it does not constrain the underlying computational
metaphor. It is like a very high level machine language. But it is
*not* a language that is well suited to expressing high-level
mathematical abstractions - that happens only several levels higher
up.

>
> Of course, doing this robustly probably WOULD take 30 years, but
> then we would never have to do it again ;-).

I simply do not believe this. If a computer sales person told me
this about some fantastic new computer system, then I think I
would very quickly show him or her the door. :(

> I know the more short term goal is to get the beastie fully
> working at it's original levels, but it would be fun to have
> some broad steps toward the "ideal" Axiom to start poking around
> with :-).

Finally.... yes indeed. I agree whole heartedly. I think your
project with units of measure and physical dimensions in Axiom
is a very good example. And I like to think of my interest in
category theory in Axiom in the same light.

\start
Date: Thu, 15 Sep 2005 16:52:24 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: Questions

--- Bill Page wrote:

> On Thursday, September 15, 2005 3:27 PM C Y wrote:
> > 
> > I suppose I should know better, but I have a couple "broad
> > scope" questions about Axiom:
> 
> I really like your questions! I would like to see more
> discussions of this kind.

Heh - thanks :-).  I remember my uncle saying once that the only way he
rebuilt a country farmhouse into a really nice family home was by not
knowing how much work it was going to be - I sort of wonder if that's
me looking Axiom over ;-).

> > a)  Given the ideal of theoretically backing the mathematics
> > in Axiom and perhaps even incorporating a proof system into
> > the core design, how do we handle/document/formalize the
> > interface between "Axiom-level" code and the underlying lisp
> > functionality?  Ideally, a "provable" system would be backed
> > by proofs all the way down to the machine code and chip design
> > levels, but that's well beyond the scope of the Axiom project.
> 
> Agreed.

Hopefully the Coyotos project will get somewhere, but they're still
busy designing a language that will work for what they want to do,
IIRC.  Oh, well - maybe in 30 years ;-).

> > I'm assuming the point we would want to start using proof
> > logic is the point where the actual "mathematics" beings, as 
> > opposed to the computational tools and structures needed to
> > support it - is this correct?
> 
> Yes I think so. To me this means specifically the SPAD and/or
> Aldor code from the Axiom algebra library.

Right.  Although I think it is important to try to understand
thoroughly how the basic tools used at the SPAD/Aldor level interact
with their "computer level" support structure.

> > Effectively treat the behavior of the underlying lisp as a
> > big set of "axioms" (in the mathematical sense) and build
> > off of them?
> 
> From my point of view lisp has very little to do with this
> issue. Sorry. :) 

No problem - I had assumed lisp was critical to Axiom.  Either way,
assume the "computer" behavior is as specified.

> Consider the fact that the Aldor compiler can
> output C code which then gets compiled into machine code by a
> C compiler like gcc, just as easily as it can produce lisp code
> that either gets interpreted or compiled in turn. To say this
> with a positive spin: Lisp is too general and flexible a language
> to be well suited to mathematical proofs.

Well, I'm not going to argue that lisp isn't extremely general ;-). 
It's a good point.

> A "higher level", i.e.
> more semantically constrained and focused language (in the sense
> of having a smaller set of more complex primitive operations)
> such as SPAD or Aldor, is better suited to expressing mathematical
> algorithms nearer the conceptual level at which mathematics
> itself is done. Of course this is not a claim that such is not
> possible in lisp - it's just that the language (or maybe
> sometimes just common practice) does not encourage such usage.

Right.  I think for this we want to stay as close to the math as
possible, so I'll agree with you there.

> The point is that the "meaning" or semantics of SPAD and Aldor
> programs can be specified quite independently of the actually
> implementation. Most of this specification of meaning actually
> involves known mathematics to a much larger extent then the
> usual application of proof techniques to the correctness of
> programs in general. I think a claim could be made that
> proving that a particular algorithm written in SPAD correctly
> implements some specific mathematical result or technique might
> be considered formally less difficult (in principle) than
> general program correctness because most of the proof can be
> carried out at a higher level.

Not sure about that one.  Sounds reasonable though.

> I think you are right that proving the correctness of the
> compiler itself or the interpreter needs to be addressed at
> a different level. Even within Axiom there are several
> intermediate levels, e.g. BOOT code, that could be addressed
> separately. Then all the way down to machine code and from
> there (in principle) even to the physics. But for *mathematics*
> I think (almost) all of the interesting stuff is at the
> top of this hierarchy of languages.

OK.  I think the intermediate levels should at least be thoroughly
documented though, so if someday it becomes possible to really apply
proof techniques to them too it's easier going for whoever tries it. 
Plus, we can probably find bugs more easily that way ;-).
 
> > b)  If we are interested in using Aldor as opposed to Spad for
> > the "standard" Axiom language, and are forced to re-implement
> > an Aldor environment due to licensing concerns, would that be
> > the time to build in proof systems and tools?
> 
> Personally I think that failure to include Aldor in with Axiom
> because of licensing issues would be a minor disaster for both
> Axiom and Aldor.

I don't disagree, but the Macsyma Inc. experience is sufficient warning
that depending on non-open and/or non-free code is not viable if one
wants to be sure of long term viability and potentially universal
usage.  That's the reason license issues always generate so much
discussion - people know how important they are in the long term.  I
think we should act fairly soon to clarify the Aldor situation, but I
don't know where the situation stands any more.  This
(http://aldor.org/license-rationale.html) was written some years ago,
and I don't see much recent activity on the Aldor list except from
Axiom folk.

> I doubt very much that sufficient interested
> resources exist anywhere at this point to take on a task like
> re-implementing Aldor. Implementing a compiler for a language like
> Aldor is already a very BIG job. And imagining adding a program
> proof systems on top of that at the same time does not makes much
> sense. 

Well, I was thinking the proof subsystem would need to be integrated
into the Aldor language itself, but perhaps not.  Anyway, I would be
very definitely against Axiom becoming dependant on non-free software,
whatever the potential gains might be.  

> Also keep in mind that there are a number of very active
> projects in this area already such as Haskell, OCaml and OBJ
> (to name just a few).

Would those be relevant to Axiom?

> > Or even if we don't have to redo the environment - mightn't it
> > still be the time?  Then as we convert things over to Aldor,
> > document them and prove relevant properties?
> 
> Yes, I think that is the right approach! That is exactly where
> Tim's ideas about literate program should be the most use.

:-).  That should be very interesting!

> > c)  I know it's somewhat impractical, but I like the idea of
> > implementing something once, correctly, documenting it fully,
> > and then never having to do it again.
> 
> I don't think that is just impractical I think it has been
> demonstrated many times over that it is *impossible*!

Well, I suppose it depends on how you look at it.  

> From my
> point of view good programming practice these days amounts to
> finding ways to do many of the same things over again, in fact
> several times over, but to do it efficiently and with (much)
> less pain. We need methods for fluently "re-factoring" programs
> at a very high level - iteratively re-thinking, documenting and
> re-implementing the basic internal design and the relationships
> between the components.

I was hoping being close to the mathematics would help keep things
organized in that regard - not to say a new, more efficient
proof/algorithm couldn't supercede an old one, but ideally the rest of
Axiom wouldn't have to worry HOW a particular piece was proven or a
particular algorithm was used.

> This is one of the essential tasks of
> high level programming language design. I think one of the
> fascinating aspects of programming languages like SPAD and Aldor
> is that they do in fact seem to facilitate this process.

I must confess I don't quite follow here.  Let's say we implement the
Risch algorithm for integration, and subject it to the relevant proofs.
 Won't we be able to work off of that implementation and not have to
create it again elsewhere?

> > Axiom gets closer to that ideal than virtually any other system
> > I have seen (well, except maybe TeX ;-)
> 
> (: choke, cough :)

Heh.  Of course, it could be that nobody dares to touch it, either...
;-)

> I think it is much easier to prove "conditional truths",
> i.e. proving that the output of a particular algorithm written
> in Aldor correctly implements some abstract mathematical
> concept ... assuming that the compiler/interpreter and underlying
> computer system perform according to spec.

That's where I think unit testing could be helpful.  I agree that's how
we need to approach it, but that doesn't preclude a) checking this
behavior experimentally and b) someday applying advanced programming
techniques to prove the implementation of the compiler et. al. work as
advertised.  

> Of course this a
> weaker result that what the end-user probably desires, but as
> far as I can see human intellectual limitations making any
> except a level-by-level approach practical.

Sure.  All we can worry about is the Axiom layer, but if we do it right
it will be able to take advantage of eventual other proven layers and
perhaps in time a system will be created that mathematicians will be
able to trust.

> As I see it "regression testing" is really what Tim's CATS
> project can offer - proving that new versions of some package
> or module do not produce newly incorrect results which formerly
> were deemed to be correct. Or simply showing clearly where the
> differences lie. I say "deemed to be correct" because in some
> case the lack of formal proofs and the lack of clear and
> unambiguous understanding of a problem means that what is
> taken to be true at one time *might* change a little over time.

Right.  CATS would effectively be a "top level" functionality test,
while unit testing would be much lower level.  CATS being the more
useful for checking that all the pieces work together as they are
supposed to, and unit testing checking that each piece works as it is
supposed to.

> No, I don't think this is the correct view. It is because of
> tools like lisp that we can even work at this higher level
> at all. We should not be looking to "move the blame" but
> rather thinking in terms of building an elaborate and ever
> higher scaffolding - sometimes shoring it up underneath and
> sometimes building it higher... (: How's that for imagery? :)

Nice :-).  But at least these testing setups will tell us what we need
to shore up.  Think of it as Dtrace for Axiom ;-).

> > d)  Tim, assuming I'm not way off base, would it be possible 
> > to sort of define the steps we want to take to get from
> ? where we are to the 30 years system - e.g. something like:
> > 
> > 1) decide on proof system to use, if in fact that's the way
> > we want to go.
> 
> I am very interested to see how Tim will respond to this since
> very often we have different views although many of our goals
> are the same. :) But I would say emphatically "no" to this. I
> think Axiom needs to be open to the application of several
> different proof methodologies. (notice my emphasis on the word
> *open*).

I think I saw a paper about adapting one proof to other proof systems -
IIRC it was surprisingly difficult.  I should see if I can dig that up
again.

> > 2) integrate proof system with Aldor language and environment
> 
> Yes. In fact there has already been some published research
> on exactly this topic. Check out some of the articles at
> http://page.axiom-developer.org/zope/Plone/refs

OK, will do.

> > 3) outline bootstrapping order in which to document and port 
> > systems to Aldor+Proof Core.
> 
> impractical :(

But isn't it essential?  A proven system will have to build itself out
of proven components, and so doesn't Axiom of necessity have to be
built much as the logic of mathematics itself is built?

> > 4) As migration occurs, document mathematical theory of all levels
> > and requirements of Axiom in terms of support from the underlying
> > lisp.
> 
> Yes. This is very important. It simply must be done if Axiom's
> future is to extend to the 30 year horizon.

Yep.  This is the part I would like to starting thinking about, because
even 30 years might turn out to be a short time given the scope of
mathematics.

> > After a while, with any luck new functionality will be transferred
> > entirely inside Axiom and the lisp requirements will be clear.
> 
> No. This does not make sense to me. As I said, lisp has very
> little to do with this - except as an intermediate language that
> is well-suited to bridging the gap between machine architecture
> and high-level complex programming abstractions.

OK, but there must be some separation between the mathematical logic of
Axiom, and the supporting OS/system libraries/compiler on which it
depends for basic computational functionality.  I would prefer that
that interface be as well understood as possible, and if the supporting
software ever reaches proven stage things could be plugged in rather
nicely - in essence, switched from "assumed" to "proven" :-).

> It is well suited
> primarily because it does not constrain the underlying computational
> metaphor. It is like a very high level machine language. But it is
> *not* a language that is well suited to expressing high-level
> mathematical abstractions - that happens only several levels higher
> up.

OK.  But since in the end all functionality of Axiom rests on those
lower layers functioning properly, wouldn't it be a good idea to at
least have some idea of what we are expecting of them?

> > Of course, doing this robustly probably WOULD take 30 years, but
> > then we would never have to do it again ;-).
>
> I simply do not believe this. If a computer sales person told me
> this about some fantastic new computer system, then I think I
> would very quickly show him or her the door. :(

How about if they presented you with a book of proofs about critical
system functionality and system security? ;-)  You might upgrade it
with better algorithms or cleaner proofs to make it more efficient, but
if the functionality is what you desire wouldn't the basic problem be
solved?

I agree it might not be practical, but darn it I hate the idea of
someone having to redo Axiom somewhere down the road.  Mathematics is
mathematics, after all.

> > I know the more short term goal is to get the beastie fully
> > working at it's original levels, but it would be fun to have
> > some broad steps toward the "ideal" Axiom to start poking around
> > with :-).
>
> Finally.... yes indeed. I agree whole heartedly. I think your
> project with units of measure and physical dimensions in Axiom
> is a very good example. And I like to think of my interest in
> category theory in Axiom in the same light.

I agree.  Units and dimensions is a bit more of a "practical" project
in the sense of wanting to use Axiom's abilities in the sciences, but I
will try my best to do it the "right way" and hopefully, if proof logic
comes to Axiom, it will be straightforward to port the units pamphlet
into the new world :-)  Category theory, on the other hand, is
fundamental to what Axiom is :-).  

\start
Date: Sun, 18 Sep 2005 15:37:53 -0500
From: MathAction (Francois Maltey)
To: MathAction
Subject: [Axiom-mail] How can I get every term of an expression ?

Hello, 

I start from a Polynomial Integer : (2*x+3*y)*(4*z+2*x)
     or better from an Expression : (2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))

And I want to get every term : 6 xy, 8 xz, 12 yz and 4 x^2 
                          or   6 %e^y log(x), etc. 
and get easily the integer 6, 8, 12 or 4.

With mupad I do 
 [op (normal ((2*x+3*y)*(4*z+2*x)))] ;
 map ([op (normal ((2*x+3*y)*(4*z+2*x)))], t-> [coeff(t), t/coeff(t)]) ;

The first give me the list  [6 x y, 8 x z, 12 y z, 4 x^2]
and the second              [[6, x y], [8, x z], [12, y z], [4, x ]]

Of corse the command t/coeff(t) isn't the faster way, 
but I don't find better.

How can I do this in an *.input axiom file ?

I look in the big book, I believe I must use DMP, not SUP, but I'm not sure.

Must I use leadingCoefficient, leadingCoefficient and reductum 
or can I use a List coerce ? but I don't find the command.

And I want to play with expression, not polynomial ; 
then what coerce must I do ?

Thanks a lot for any advice, and have a good day !

\start
Date: Sun, 18 Sep 2005 21:01:35 -0500
From: MathAction (root)
To: MathAction
Subject: [Axiom-mail] coefficients of a polynomial (or expr int)

So we create a Polynomial(Integer) thus:

m := 3*x^2 + 2*x +6

and we ask for the monomials:

p := monomials(m)

which returns a List(Polynomial(Integer))

We can ask for the length of the list using the # operator

#p

We can ask for an element of the list using the elt operator

elt(p,1)

or just use the notation p.1, p.2, etc

We can ask for the coefficient of a monomial with

coefficient(p.1,x,2) 

where x is the variable of interest (it might be multivariate)
and 2 is the power (we could have used the whole polynomial
directly as in

   coefficient(m,x,2)

We can generate a list with the notation

[ function for i in a..b]

So we can directly create a list of the coefficients in the
variable 'x' with

[coefficient(elt(p,i),x,#p-i) for i in 1..#p]

Of course, Axiom is strongly typed and cannot guarantee that the
expression #p-i will always be non-negative. It will complain about
this and "step thru" (interpret) the expression. You can cure this
by explicitly telling it that the expression is always a non-negative
integer (NNI) thus:

[coefficient(elt(p,i),x,(#p-i)::NNI) for i in 1..#p]

which will return a list of the coefficients of the monomials.

The same thing will work if you start with an Expression(Integer).


n:EXPR(INT) := 3*x^2 + 2*x +6
p:=monomials(n)

which returns a LIST(POLY(INT)) and you are back to the previous case

\start
Date: Mon, 19 Sep 2005 12:00:59 +0200
From: Ralf Hemmecke
To: list
Subject: Re: Pamplhet mode for emacs

There is also mmm-mode. That should be even better if several file types
are mixed withing a pamphlet file.

http://mmm-mode.sourceforge.net/

Ralf

David MENTRE wrote:
> Hello,
> 
> Martin Rubey writes:
> 
> 
>>An important thing would either be a fantastic pamphlet mode for emacs
>>or the possibility to retain a little of the documentation in the
>>source file.
> 
> 
> noweb (the tool behind Tim's pamphlets) provides an emacs mode
> (noweb-mode). It allows to use simultaneously two modes, latex-mode for
> the LaTeX part and another mode for the program part. With most emacs
> modes, font coloring and auto indentation is correct (except sometimes
> the first line of a code chunk). Maybe you were thinking at more
> elaborate things but this is a first start.
> 
> For what it's worth, I'm using following code in my .emacs:
> 
> ;; To have noweb mode automatically
> (setq auto-mode-alist
>       (append '(("\\.pamphlet$"  . noweb-mode)
>                 ) auto-mode-alist))
> 
> ;; many thanks to Hubert Canon <hcanon@alussinan.org> for this code
> (add-hook 'noweb-mode-hook 'my-noweb-set-mode-code)
> (defun my-noweb-set-mode-code ()
>   (let* ((filename (file-name-nondirectory buffer-file-name))
> 	 (mode (cond ((string-match "^Makefile" filename) 'makefile-mode)
> 		     ((string-match "\\.lisp\\.pamphlet$" filename) 'lisp-mode)
> 		     ((string-match "\\.lsp\\.pamphlet$" filename) 'lisp-mode)
> 		     ((string-match "\\.clisp\\.pamphlet$" filename) 'lisp-mode)
> 		     ((string-match "\\.c\\.pamphlet$" filename) 'c-mode)
> 		     ((string-match "\\.h\\.pamphlet$" filename) 'c-mode)
> 		     ((string-match "\\.ml\\.nw$" filename) 'caml-mode)
> 		     ((string-match "\\.mli\\.nw$" filename) 'caml-mode)
> 		     ((string-match "\\.cd\\.nw$" filename) 'caml-mode)
> 		     ((string-match "\\.c\\.nw$" filename) 'c-mode)
> 		     ((string-match "\\.h\\.nw$" filename) 'c-mode)
> 		     ((string-match "\\.xdr\\.nw$" filename) 'c-mode)
> 		     ((string-match "\\.dtd\\.nw$" filename) 'sgml-mode)
> 		     ((string-match "\\.ui\\.nw$" filename) 'nxml-mode)
> 		     (t 'fundamental-mode))))
>     (noweb-set-code-mode mode)))

\start
Date: Mon, 19 Sep 2005 13:25:01 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Axiom + Coq?

In the paper "On the way to certify Computer Algebra Systems" by S.
Boulm'e, T. Hardin, D. Hirschkoff, V. M'enissier-Morain, and R. Rioboo
the following description is made: 

"Within a previous project, we have tried to interface Axiom and the
Coq proof assistant, with the aim of proving some properties of Axiom
programs[1]. A prototype has been done, consisting firstly in
interfaces between libraries of Axiom (basic, sets, ordered sets, . . .
, groups) with the corresponding theories in Coq, and secondly, in a
compiler from Axiom functions to their specifications in Coq. The
emphasis has been put on the compilation of the hierarchy of categories
and domains; as far of the actual code is concerned, only the
imperative kernel was considered. The main outcome of this previous
work was that such a task should rather be attacked using a programming
language whose semantics is fully understood (and, possibly,
formalized). Indeed, for example, some diAEculties arose in modeling
multiple inheritance within Axiom programs, mostly because we could not
coin a precise semantics of this (quite intricate) programming
construct. Overall, it seems that in some sense the Axiom programmer
has too much freedom for his implementation task, and can hence design
programs that are quite diAEcult, if not impossible, to certify. In
particular, the management of definitions by default, as well as
definition overriding, seems diAEcult to handle when it comes to
guarantee a reasonable form of coherence within the "proof" part of a
development."

The reference is apparently to this:

1. Guillaume Alexandre. D'Axiom `a Zermelo. Th`ese de l'universit'e
Paris 6, February 1998. 

Does anyone know if this work is available anywhere?  (An English
translation would be even better :-) This sounds like it pursued almost
exactly what we need, and the results, if available, would be extremely
interesting to review or perhaps even build off of.

\start
Date: Mon, 19 Sep 2005 21:20:39 -0400
From: Bill Page
To: Francois Maltey
Subject: RE:  How can I get every term of an expression ?

On Sunday, September 18, 2005 4:23 PM Francois Maltey wrote:
>
> I start from ... an Expression :
> (2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))
>
> And I want to get every term : ... 6 %e^y log(x), etc.
> and get easily the integer 6, 8, 12 or 4.
>
> ...
> I want to play with expression, not polynomial ;
> then what coerce must I do ?
>

Tim Daly answered the part of Francois' question concerning the
case of polynomials (which I have omitted above) but in this case
the example expression is not a polynomial. It is assumed by Axiom
to be of type Expression Integer and cannot be converted to any
of the polynomial types except in a trivial manner, e.g.
DistributedMultivariatePolynomial([x,y,z],Expression Integer)

I have not been able to find any acceptible answer to Francois'
question.

How can I persuade Axiom to write out

(1) -> (2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))

as a "sum of products"? E.g.

(2) -> 8*log(x)*sin(z)+4*log(x)^2+12*exp(y)*sin(z)+6*exp(y)*log(x)

In Axiom, both of these expressions are rendered as

    (8log(x) + 12exp(y))sin(z) + 4log(x)  + 6exp(y)log(x)
                Type: Expression Integer

Why does Axiom choose this peculiar form instead of (1) or (2)?

Why can't Axiom factor and expand such expressions?

In the case of polynomials I can write:

(3) -> ((2*x+3*y)*(4*z+2*x))::DMP([x,y,z],INT)

          2
   (3)  4x  + 6x y + 8x z + 12y z
           Type: DistributedMultivariatePolynomial([x,y,z],Integer)

But there does not seem to be anything type equivalent to

           Type: DistributedExpression Integer

Why not?

Would it make sense to define Distributed as a generic domain
constructor similar to Complex?

Would it be possible to write

  Distributed MultivariatePolynomial([x.y.z],Integer)

and

  Distributed Expression Integer?

(Note the space between Distributed and MultivariatePolynomial.)

Would it be simple to "extend" Expression to a new domain were
expressions are represented (when possible) as sums of products?

\start
Date: Tue, 20 Sep 2005 01:35:58 -0400
From: Tim Daly
To: Bill Page
Subject: re: How can I get every term of an expression ?

Bill, Francois,

The output form of an expression is determined by the domain. 
The simple example is

m:= 1/2*x^2 + 1/3*x + 1/5

yields

    1  2   1     1
    - x  + - x + -
    2      3     5

             Type: Polynomial Fraction Integer


the type was chosen by the interpreter. The "simplest" expression
of this form (a polynomial with fractional coefficients) is printed.

However we can change the type (and thus the printed representation)
by coercion:

m::Fraction(Polynomial(Integer))

     2
  15x  + 10x + 6
  --------------
        30

which is now a fraction whose numerator is a polynomial with
integer coefficients and whose denominator is a polynomial
with integer coefficients.

It is, however, essentially the same expression (module zeros).



Bill writes:

> How can I persuade Axiom to write out
> 
> (1) -> (2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))
> 
> as a "sum of products"? E.g.
> 
> (2) -> 8*log(x)*sin(z)+4*log(x)^2+12*exp(y)*sin(z)+6*exp(y)*log(x)

so you're asking for a domain whose print representation is a "factored"
form, something like asking axiom:

n:= 345
       Type: PositiveInteger

Now Factored(Integer) has a print representation of:

n::Factored(Integer)

    3 5 23
       Type: Factored Integer


I'm unaware of any existing domain that has a print representation as
a "sum of products" although one could be written. 

Bill writes
> Why can't Axiom factor and expand such expressions?


Axiom can factor and expand such expressions. However when the results
get printed (in Expression(Integer)) they get printed in the form shown.

Instead of "Distributed" perhaps you wanted "Factored" such as

  Factored(Expression(Integer))

however factored currently does not know how to print anything in
factored from other than integers it seems. Since this is a valid
type clearly the print representation could be expanded to cover
the Expression(Integer) values.

\start
Date: Tue, 20 Sep 2005 02:45:28 -0400
From: Bill Page
To: Tim Daly
Subject: re: How can I get every term of an expression ?

On Tuesday, September 20, 2005 1:36 AM Tim Daly wrote:
> ...
> Bill writes:
>
> > How can I persuade Axiom to write out
> >
> > (1) -> (2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))
> >
> > as a "sum of products"? E.g.
> >
> > (2) -> 8*log(x)*sin(z)+4*log(x)^2+12*exp(y)*sin(z)+6*exp(y)*log(x)
>
> so you're asking for a domain whose print representation is a
> "factored" form, something like asking axiom:
>
> n:= 345
>        Type: PositiveInteger
>
> Now Factored(Integer) has a print representation of:
>
> n::Factored(Integer)
>
>     3 5 23
>        Type: Factored Integer
>

No, I don't see what this has to do with factoring integers
(except by analogy). The factored form of the Francois' example
polynomial is shown in Axiom output (2) below. That is not
the problem.

>
> I'm unaware of any existing domain that has a print representation
> as a "sum of products" although one could be written.

The polynomial domains that contain the word 'distributed' have
such a representation.

>
> Bill writes
> > Why can't Axiom factor and expand such expressions?
>
> Axiom can factor and expand such expressions. However when the
> results get printed (in Expression(Integer)) they get printed in
> the form shown.

No. So far as I can tell the "factored" form of Francois' Expression
and the original form are identical. See below.

>
> Instead of "Distributed" perhaps you wanted "Factored" such as
>
>   Factored(Expression(Integer))
>
> however factored currently does not know how to print anything in
> factored from other than integers it seems.

I would like *both* Factored and Distributed as valid types over
Expression Integer. This works for polynomial domains (see below)
except the way of forming the Distributed form is irregular.

(1) -> p1:=(2*x+3*y)*(4*z+2*x)

                               2
   (1)  (12y + 8x)z + 6x y + 4x
                                                     Type: Polynomial
Integer
(2) -> p1::Factored POLY INT

   (2)  2(3y + 2x)(2z + x)
                                            Type: Factored Polynomial
Integer
(3) -> p1::DMP([x,y,z],INT)

          2
   (3)  4x  + 6x y + 8x z + 12y z
                     Type:
DistributedMultivariatePolynomial([x,y,z],Integer)
(4) ->

> Since this is a valid type clearly the print representation could
> be expanded to cover the Expression(Integer) values.
>

Isn't there is more to the difference between for example
MP([x,y,z], INT) and DMP([x,y,z], INT) then just the print
representation?

For example, Francois' Expression is

(5) -> p2:=(2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))

                        y                 2      y
   (5)  (8log(x) + 12%e )sin(z) + 4log(x)  + 6%e log(x)
                 Type: Expression Integer

And the factored form of the polynomial example is:

(6) -> p1::Factored POLY INT::InputForm

   (6)
   (*  (nilFactor (:: 2 (Polynomial (Integer))) 1)

     (*  (primeFactor (:: (+ (* 3 y) (* 2 x)) (Polynomial (Integer))) 1)
      (primeFactor (:: (+ (* 2 z) x) (Polynomial (Integer))) 1))
     )
                 Type: InputForm

InputForm shows some detail of the internal representation.

On the other hand doing this with Expression Integer appaentely
does not produce a factored form at all.

(16) -> p2::Factored EXPR INT::InputForm

   (16)
   (+  (* (+ (* 8 (log x)) (* 12 (exp y))) (sin z))
    (+ (* 4 (** (log x) 2)) (* (* 6 (exp y)) (log x))))
                 Type: InputForm

\start
Date: Tue, 20 Sep 2005 10:00:07 +0200
From: Martin Rubey
To: Bill Page
Subject: re: How can I get every term of an expression ?

Page, Bill writes:

 > On the other hand doing this with Expression Integer appaentely
 > does not produce a factored form at all.
 > 
 > (16) -> p2::Factored EXPR INT::InputForm
 > 
 >    (16)
 >    (+  (* (+ (* 8 (log x)) (* 12 (exp y))) (sin z))
 >     (+ (* 4 (** (log x) 2)) (* (* 6 (exp y)) (log x))))
 >                  Type: InputForm
 > 

As far as I understand, Axiom does not know how to factor expressions:

(6) -> factor(x^2-1::EXPR INT)

         2
   (6)  x  - 1
                                            Type: Factored Expression Integer

And in fact, there is no way to factor an element of Expression INT in general,
since you cannot even test for zero.

So the way to go is to write domains that contain the class of functions you
are interested in, but still allow factorisation. Examples:

Integers

Polynomials

I guess: algebraic functions

I guess: D-finite functions (this would contain quite a bit of the
                             trigonometric stuff, but not all of it)

Maybe, but I doubt it: functions that satisfy an ADE (algebraic differential equation)

and so on. I would advise not to try to "fix" Expression Integer, but rather to
implement categories and domains that are computable.

There are certainly other interesting classes. For a start however, I'd vote
for the hierarchy above, since it is well known, there are many wonderfully
efficient algorithms and it occurs frequently in "real world" problems.

Note that all functions in the hierarchy above can be represented as certain
recurrence equations, so I suspect that *after* doing some maths, a simple (in
the sense of: OK, not perfect) implementation would be quite easy.

If anybody is interested, I can provide more information, and Ralf certainly
can do so, too.

Martin

PS: How are graphs going?

\start
Date: Tue, 20 Sep 2005 11:08:49 +0200
From: Francois Maltey
To: Bill Page
Subject: Re: How can I get every term of an expression ?

Bill Page writes:

> How can I persuade Axiom to write out
>
> (1) -> (2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))
>
> as a "sum of products"? E.g.
>
> (2) -> 8*log(x)*sin(z)+4*log(x)^2+12*exp(y)*sin(z)+6*exp(y)*log(x)
>
> In Axiom, both of these expressions are rendered as
>
>     (8log(x) + 12exp(y))sin(z) + 4log(x)  + 6exp(y)log(x)
>                 Type: Expression Integer
>
> Why does Axiom choose this peculiar form instead of (1) or (2)?
> Why can't Axiom factor and expand such expressions?


I use kernels to get the elementary functions.

Can I substitute theses elementary functions to new variables,
make transforms over polynoms, and substitute the variables back ?

Thanks a lot !

\start
Date: Tue, 20 Sep 2005 06:40:42 -0400
From: Bill Page
To: Francois Maltey
Subject: RE: How can I get every term of an expression ?

On Tuesday, September 20, 2005 5:09 AM Francois Maltey wrote:
> ...
> I use kernels to get the elementary functions.
>
> Can I substitute theses elementary functions to new variables,
> make transforms over polynoms, and substitute the variables back ?
>

Try this:

(1) -> p2:=(2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))

                       y                 2      y
   (1)  (8log(x) + 12%e )sin(z) + 4log(x)  + 6%e log(x)
                      Type: Expression Integer

(2) -> p3:=eval(monomials( _
             subst(p2,kernels p2,[x,y,z,w])::DMP([x,y,z,w],INT) _
           ),[x,y,z,w],kernels p2)

                           y              2    y
   (2)  [8log(x)sin(z),12%e sin(z),4log(x) ,6%e log(x)]
                      Type: List Expression Integer


\start
Date: Tue, 20 Sep 2005 14:19:42 +0200
From: Martin Rubey
To: Francois Maltey
Subject: re: How can I get every term of an expression ?

Francois Maltey writes:
 > Bill Page writes:
 > 
 > > How can I persuade Axiom to write out
 > >
 > > (1) -> (2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))
 > >
 > > as a "sum of products"? E.g.
 > >
 > > (2) -> 8*log(x)*sin(z)+4*log(x)^2+12*exp(y)*sin(z)+6*exp(y)*log(x)
 > >
 > > In Axiom, both of these expressions are rendered as
 > >
 > >     (8log(x) + 12exp(y))sin(z) + 4log(x)  + 6exp(y)log(x)
 > >                 Type: Expression Integer

For example:

(16) -> ex:=(2*log(x)+3*exp(y))*(4*sin(z)+2*log(x))

                        y                 2      y
   (16)  (8log(x) + 12%e )sin(z) + 4log(x)  + 6%e log(x)
                                                     Type: Expression Integer
(17) -> subst(ex, kernels ex, [x1,x2,x3])::DMP([x1,x2,x3], INT)

                               2
   (17)  8x1 x2 + 12x1 x3 + 4x2  + 6x2 x3
                  Type: DistributedMultivariatePolynomial([x1,x2,x3],Integer)


 > I use kernels to get the elementary functions.

please use the notion "kernel". The notion "elementary function" is already
taken by two other things ... ;-)

 > Can I substitute theses elementary functions to new variables, make
 > transforms over polynoms,

yes...

 > and substitute the variables back ?

Well, as soon as you go back, you'll loose the transformations you did...

The "deeper" reason why there is no domain DistributedExpression is probably
that DMP defined in gdpoly.spad asks for a List Symbol as variables. It
probably could be in fact any finite OrderedSet, but it would need some work to
get it done.

A simple workaround is 

out(p, kl, vl) == 
  if reductum p = 0 
  then (eval(leadingMonomial(p)::EXPR INT, vl, kl))::OUTFORM
  else (eval(leadingMonomial(p)::EXPR INT, vl, kl))::OUTFORM _
       + out(reductum p, kl, vl)

output ex == 
  kl := kernels ex
  vl := [subscript('x, [i::OutputForm]) for i in 1..#kl]
  out(subst(ex, kl, vl)::DMP(vl, INT), kl, vl)

Note that this returns an element of OUTFORM. This can be circumvented: highly
undebugged, undocumented and all the bad things :-)


)abb domain DEXPR DistributedExpression
DistributedExpression(R: Join(Ring, OrderedSet)): Exports == Implementation where

  EXPRR ==> Expression R

  Exports == FunctionSpace R

  Implementation == EXPRR add

      Rep := EXPRR

      out: (Polynomial R, List %, List %) -> OutputForm 
      out(p, kl, vl) == 
        ex := leadingMonomial(p)::%
        if reductum p = 0 
        then coerce(eval(ex, vl, kl))$Rep
        else coerce(eval(ex, vl, kl))$Rep _
             + out(reductum p, kl, vl)

      coerce(ex:%):OutputForm == 
        kl := kernels ex
        vl: List % := [subscript('x, [i::OutputForm])::Symbol::% for i in 1..#kl]
        ex1: % := subst(ex, kl, vl)$%
        kl1 := map(coerce(#1)$%, kl)$ListFunctions2(Kernel %, %)
        out(retract(ex1)@Polynomial(R), kl1, vl)

\start
Date: Tue, 20 Sep 2005 10:15:37 -0400
From: Bill Page
To: Martin Rubey, Francois Maltey
Subject: DistributedExpression (was: How can I get every term of an expression ?)

On Tuesday, September 20, 2005 8:20 AM Martin Rubey wrote:

> ...
> )abb domain DEXPR DistributedExpression
> DistributedExpression(R: Join(Ring, OrderedSet)): Exports => Implementation where
>
>   EXPRR ==> Expression R
>
>   Exports == FunctionSpace R
>
>   Implementation == EXPRR add
>
>       Rep := EXPRR
> ...

which provides a brilliant implementation of an extended Expression
domain that displays in distributed form. I think this wonderfully
demonstrates both the power of the Axiom language as well as
the power of collaborative development! :)

I have created a page on the Axiom wiki that demonstrates
Martin's idea.

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

I also provided a simple coercion from types of Expression
to DistributedExpression.

Comments, improvements and extensions to the code would be
greatly appreciated!

\start
Date: 20 Sep 2005 16:07:19 -0400
From: Camm Maguire
To: Tim Daly
Subject: Axiom reelased version names

Greetings!

Is the official release site

http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/ 

?

If so, may I please request sortable file or symbolic link names so
that Debian can automatically tell me when its package is out of date?

I.e. 

ln -s axiom-Sept2005-src.tgz axiom-20050901-src.tgz

?

Thanks to all for your wonderful work!

\start
Date: Tue, 20 Sep 2005 17:22:57 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: Axiom reelased version names

Camm,

On Tuesday, September 20, 2005 4:07 PM you wrote:
>
> Is the official release site
>
> http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/
>
> ?

About as official as anything :)

>
> If so, may I please request sortable file or symbolic link names
> so that Debian can automatically tell me when its package is out
> of date?
>
> I.e.
>
> ln -s axiom-Sept2005-src.tgz axiom-20050901-src.tgz
>

Ok the following link should now work:

http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-20050901-
src.tgz

also

http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-20050201-
src.tgz

> ?
>
> Thanks to all for your wonderful work!
> --

You too!

\start
Date: Wed, 21 Sep 2005 14:52:00 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: DistributedExpression (was: How can I get every term of an expression ?)


 > ... implementation of an extended Expression domain that displays in
 > distributed form. I think this wonderfully demonstrates both the power of
 > the Axiom language as well as the power of collaborative development! :)

Well, output is easily changed. You did notice that the *real* power of
different representations is speed. Thus, my domain is rather cosmetics,
however useful it may be. We do agree that cosmetics is useful, I guess.

\start
Date: Wed, 21 Sep 2005 11:25:40 +0200
From: Lionel Elie Mamane
To: list
Subject: Kudos

Hi,

Just wanted to send encouragements and thanks. I learned of axiom
through Timothy Daly's talk at the LSM Metz 2003. I never had the
occasion to use it until this week, and I found the "Basic Commands"
entry in the HyperDoc Top Level to be a *very* good idea. What I
wanted to do was listed up front there and in 2 minutes, I had already
closed Axiom, having gotten the result I wanted.

\start
Date: Wed, 21 Sep 2005 10:19:07 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Programming Axiom] 

Advance Topics

  [Rep and Per] --
     a discussion of "representation" in Axiom and Aldor domains

  [Category Theory and Axiom] --
     How does Axiom differ from category theory. How to implement
     category theory concepts in Axiom.

Axiom and Reduce. It would look something like this::

  !\begin{aldor}

  \end{aldor}

\start
Date: Wed, 21 Sep 2005 10:36:56 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Rep and Per] (new) 

Aldor programming philosophy from the point of view of it's
evolution from previous incarnations of the Axiom library
compiler, is described here:

http://www.aldor.org/docs/HTML/chap18.html

There is one construct in particular in Aldor that really
stands out - the concept of representation and it's opposite
(abstraction?). In Aldor these are formally denoted
by two very peculiar coercion operations: 'rep' and 'per'.

In older SPAD terms, rep and per can be written as the following
macros::

  macro {
        rep x == x @ % pretend Rep;
        per r == r @ Rep pretend %;
  )

The expression 'rep(x)' describes an object x of this domain but
treats it as belonging to a different domain 'Rep'.

The expression 'per(y)' describes an object y from the 'Rep' domain
which is to be treated as belonging to this domain. ('per' as in
the percent % symbol)

In looking through older SPAD code it is clear that these
combinations occur frequently and their encapsulation as 'rep'
and 'per' makes reading Aldor code much easier than SPAD.

Does anyone know of any formal programming language research
papers that describe the semantics of 'rep' and 'per' in a
general way? If this sort of mechanism is present in other
languages, what form does it take?

It seems to me that 'rep' and 'per' constitute the essence of the
peculiar object-oriented programming style pioneered by Axiom
and Aldor. But what are these constructs in formal (categorical)
terms?

Below is a first attempts to answer these questions -
comments, corrections and opinions would be most welcome!

<hr />

It seems appropriate to me to think of rep and per as forming
a pair of adjoint functors::

             rep
            ---->
   % domain       Rep domain
            <----
             per

'rep' is a "forgetful functor" that maps the abstract structure
(objects and operations) of this domain into it's internal
representation. It "forgets" about the abstract relationships.
The objects of the external domain however are viewed only in
terms of the relationships between objects. The image of this
domain under 'rep' in representation has its internal structure
exposed.

'per' on the other hand constructs abstract members of this
domain from the underlying representation. It encapsulates
the internal operations of the representation in terms of
the abstract structure of this domain.

domains must be thought of in terms of categories both in the
sense of category theory and in Axiom's sense of "category".
The appropriate categories usually have at least the structure
of a Cartesian closed category which they inherit from
Axiom's basic types constructors, record, union and mapping.
See discussion:
http://wiki.axiom-developer.org/TuplesProductsAndRecords

In terms of category theory there is a natural transformation,
called the 'unit', that partitions elements of the Rep domain
into classes (as an abstract quotient of the representation)::

  x --> rep(per(x))

and 'rep' is right adjoint of 'per'.

In category theoretic terms 'Rep' domain is some Cartesian closed
category, i.e. consisting of products (records), co-products
(unions) and exponentials (functions) over some basic set
of component domains. It's operations are formed freely from
the operations of it's components.

The implementation of the domain in terms of the representation
establishes a natural bi-jection between the operation of the
external domain and the operation of it's internal representation::

   x -> rep y    (representation)
  ------------
   per x -> y    (domain)

The book: "Basic Category Theory for Computer Scientists", by
Benjamin Pierce, MIT Press, 1991, is a good reference. See
especially section 2.4. Pierce gives an excellent example in
terms of definition of the 'List' constructor.

Also: "Categories, Types and Structures. An introduction to Category
Theory for the working computer scientist." by Andrea Asperti and
Giuseppe Longo, M.I.T. Press, 1991, which is downloadable from here:
http://www.di.ens.fr/users/longo/download.html

*(from an email to axiom-develper on Thursday, September 01, 2005 6:36 AM)*

\start
Date: Wed, 21 Sep 2005 12:08:34 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: DistributedExpression (was: How can I get every term of an expression ?)

On Wednesday, September 21, 2005 8:52 AM Martin Rubey wrote:
>...
> Well, output is easily changed.

Yes, you are right. As usual, I just wish we had more
documentation: both user documentation (how-to) and
conceptual documentation (why).

Axiom's approach to output as a coercion to the type OutputForm
is radically different than any other computer algebra system
that I know. There is an attempt also in Axiom to do the same
with input (InputForm and SExpressions etc.) This is a powerful
idea that depends centrally on the strong typing system.

Understanding how to use types and domains in Axiom is both
"90% of the problem" and "90% of the reasons why one might
want to use Axiom in the first place". We need to write more
about this ...

> You did notice that the *real* power of different
> representations is speed.

I wrote a short note about the concept of representation
in Aldor (which also applies to Axiom and SPAD)

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

I think that you are right that one of the main points
about different representations is the relative
computational efficiency of different implementations
for different purposes. But I think there is much more
to this concept and that the current Aldor and SPAD
syntax does not sufficiently highlight the important
place that it holds. The current syntax, i.e. 'rep'
and 'per' as macros and 'Rep' as a distinquished name
for a local domain, seems to treat representation on
a par with other programming constructs.

> Thus, my domain is rather cosmetics, however useful it
> may be. We do agree that cosmetics is useful, I guess.
>

I just spent a couple of hours trying to add a new operation
called 'terms' to the DistributedExpression domain. The
idea was that it should return a List of Expressions in
analogy with the 'monomials' operator of POLY, but I kept
getting hung up on vague SPAD compiler messages and picky
details for explicitly specifying domains... After all this
time I still do not feel fluent in SPAD/Aldor but for some
reason I continue to admire it greatly when I see something
that works! :)

Yes, I do agree that "cosmetics" is useful. In fact I have
been know to claim that "notation is (almost) everything"
in mathematics and I think that applies equally to computer
algebra systems.

\start
Date: Wed, 21 Sep 2005 10:30:16 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Martin Rubey
Subject: re: DistributedExpression (was: How can I get every term of an expression ?)

--- Bill Page wrote:

> On Wednesday, September 21, 2005 8:52 AM Martin Rubey wrote:
> >
> > Thus, my domain is rather cosmetics, however useful it
> > may be. We do agree that cosmetics is useful, I guess.
> 
> Yes, I do agree that "cosmetics" is useful. In fact I have
> been know to claim that "notation is (almost) everything"
> in mathematics and I think that applies equally to computer
> algebra systems.

I agree. User comprehension is not merely a superficial convenience of
a CAS - it's a fundamental necessity.  UI design and formatting of
output are two components of this, and cannot be overlooked.  I think
there is a tendency for mathematical people to think only in terms of
the mathematics itself - a critical thing to remember, once in a while
anyway, is that correct mathematics is completely useless if it cannot
be used and built on, and the harder it is to understand it the less
useful it is in those regards.  So the best possible presentation of
results is of paramount importance, as is an incremental approach to
using the full power (and attendant complexity) of Axiom.

That's why I like the idea of building "user friendly" environments for
users, which operate pretty much as expected, but set up those
environments by making assumptions which are implicit in normal
operation explicit via the implementation of the environment.  This
lets people function more or less normally, but as they have a need for
more generality they can make fewer assumptions in their default
environment, and incrementally bring online the new syntax and
increased care needed for real correctness.

\start
Date: Wed, 21 Sep 2005 15:11:26 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: DistributedExpression (was: How can I get every term of an expression ?)

On Wednesday, September 21, 2005 1:30 PM C Y wrote:
>
> I agree. User comprehension is not merely a superficial convenience
> of a CAS - it's a fundamental necessity.  UI design and formatting
> of output are two components of this, and cannot be overlooked.

Well, this is user interface and then there is output formatting
... these are not really the same thing. For example, requiring a
user to write

  x^2

and then seeing

  2
 x
            Type: Polynomial Integer

displayed on the screen is what I would call UI. Having Axiom
generate LaTeX output via

  )set output tex on

and getting

  $$
  x \sp 2
  \leqno(3)
  $$
             Type: Polynomial Integer

Aside: Wouldn't it make better sense if we got only LaTeX
formatted output when we set output tex on? Maybe the above
should be more like:

  \axiomtext{Loading C:/Program Files/axiom/mnt/windows/algebra/UNISEG.o
      for domain UniversalSegment}
  $$
  x \sp 2
  \leqno(3)
  $$
  \axiomtype{Polynomial Integer}

If Axiom did this it would be much easier to parse it's
output for applications like MathAction and TeXmacs.

-------

Having MathAction or TeXmacs display this graphically is
still UI.

On the other hand when you input

  (x+y)*(z+w)::Expression Integer

and Axiom replies

  (y + x)z + w y + w x
                       Type: Expression Integer

then the display of whatever internal representation is
used by Axiom for type 'Polynomial Integer' is controlled by
the implied coercion to the special type OutputForm. This is
really all that is different between the type Expression Integer
and Martin's new type DistributedExpression Integer. The
internal representation happens to be the same (but need not
be) but the function which provides coercion to OutputForm
has been replaced with one that causes Axiom to reply

  xz + xw + yz + yw
                       Type: DistributedExpression Integer

----------

The type OutputForm which doesn't actually show up here is
used internally when Axiom formats it's output for display.
Although this is certainly output formatting, I don't think
I want to call this a User Interface issue as such. The idea
that (y + x)z + w y + w x and  xz + xw + yz + yw can be both
be external representations of the same thing is more a matter
of mathematics than cosmetics.

> I think there is a tendency for mathematical people to think
> only in terms of the mathematics itself - a critical thing to
> remember, once in a while anyway, is that correct mathematics
> is completely useless if it cannot be used and built on, and
> the harder it is to understand it the less useful it is in
> those regards.

I would take a stronger stand and say that some mathematics
is essentially impossible unless you have the right notation.
For example perhaps one reason that the Romans did not spend
much time doing algebra was that it was too much of a pain to
learn the multiple (iiix) by (cxx). :)

> So the best possible presentation of results is of paramount
> importance, as is an incremental approach to using the full
> power (and attendant complexity) of Axiom.
>
> That's why I like the idea of building "user friendly"
> environments for users, which operate pretty much as expected,
> but set up those environments by making assumptions which are
> implicit in normal operation explicit via the implementation
> of the environment.

This is what Richard Fateman has called the "principle of
least surprize" applied to computer algebra systems. I think
that currently the Axiom interpreter fails rather badly on
this principle in quite a few situations. Very often is is
quite difficult to explain to a new user of Axiom why Axiom
produces the output that it does in certain cases because
the explanation necessarily involves some rather deep knowledge
of how Axiom operates. This is bad for new users and is one
of the things that makes Axiom better suited as a research
platform than for the casual weekend computer algebra user.

> This lets people function more or less normally, but as they
> have a need for more generality they can make fewer assumptions
> in their default environment, and incrementally bring online
> the new syntax and increased care needed for real correctness.
>

I think that this is an ideal that is very hard to achieve
(maybe impossible) but is certainly a goal to work towards.
One of the problems with computer algebra systems is that
they are trying to do something that (most) people already
find rather hard to do - not just multiplying 7*120. Often
they are learning the subject (mathematics) at the same time
as learning to use the computer system. That makes it at
least doubly hard.

\start
Date: Wed, 21 Sep 2005 15:47:07 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: DistributedExpression (was: How can I get every term of an expression ?)
Cc: list

On Wednesday, September 21, 2005 3:11 PM I wrote:
> ...
> On the other hand when you input
>
>   (x+y)*(z+w)::Expression Integer
>
> and Axiom replies
>
>   (y + x)z + w y + w x
>                        Type: Expression Integer
>
> then the display of whatever internal representation is
> used by Axiom for type 'Polynomial Integer' is controlled by
> the implied coercion to the special type OutputForm. This is
> really all that is different between the type Expression Integer
> and Martin's new type DistributedExpression Integer.

Of course I should have written:

        the display of whatever internal representation is
  used by Axiom for type 'Expression Integer' is controlled by
  the implied coercion to the special type OutputForm.

The same applies for all types (domains) in Axiom. Each of them
must supply at least one function named 'coerce' with signatue

  coerce: % -> OutputForm

This function is called by the Axiom interpreter. And it can
be used explicitly like this for example:

(4) -> (a+b)*(c+d)::OutputForm

   (4)  (b + a)(d + c)
                                      Type: OutputForm

Notice that the expression '(a+b)*(c+d)' has not been
interpreted by Axiom in any mathematical sense. OutputForm
is just a way of generating output that "looks like"
mathematics.

\start
Date: Thu, 22 Sep 2005 11:24:03 +0200
From: Martin Rubey
To: Bill Page
Subject: RE: DistributedExpression (was: How can I get every term of an expression ?)

Page, Bill writes:
 > On Wednesday, September 21, 2005 8:52 AM Martin Rubey wrote:
 > >... 
 > > Well, output is easily changed.
 > 
 > Yes, you are right. As usual, I just wish we had more
 > documentation: both user documentation (how-to) and
 > conceptual documentation (why).
 > 
 > Axiom's approach to output as a coercion to the type OutputForm is radically
 > different than any other computer algebra system that I know. 

Yes.

 > There is an attempt also in Axiom to do the same with input (InputForm and
 > SExpressions etc.) 

I think that this attempt is doomed to fail. Still it may be useful, at least
for debugging.


 > Understanding how to use types and domains in Axiom is both "90% of the
 > problem" and "90% of the reasons why one might want to use Axiom in the
 > first place". We need to write more about this ...

No. There is enough written about it (in the Aldor User Guide). A short
introductory text is in the Axiom book.

 > But I think there is much more to this concept and that the current Aldor
 > and SPAD syntax does not sufficiently highlight the important place that it
 > holds. The current syntax, i.e. 'rep' and 'per' as macros and 'Rep' as a
 > distinquished name for a local domain, seems to treat representation on a
 > par with other programming constructs.

And this is a good thing, it seems to me.

 > I just spent a couple of hours trying to add a new operation called 'terms'
 > to the DistributedExpression domain. The idea was that it should return a
 > List of Expressions in analogy with the 'monomials' operator of POLY, but I
 > kept getting hung up on vague SPAD compiler messages and picky details for
 > explicitly specifying domains... After all this time I still do not feel
 > fluent in SPAD/Aldor but for some reason I continue to admire it greatly
 > when I see something that works! :)

If you send me your code and the error message you got (the latter for
cross-checking), I'll try to help.

 > Yes, I do agree that "cosmetics" is useful. In fact I have been know to
 > claim that "notation is (almost) everything" in mathematics 
 > ...

NO, NO, NO. Good notation is important, and I'd agree if you'd say that
mathematics builds on good notation. But it's not nearly "almost everything".

What (good) notation provides is a means to make your ideas and proofs clear
and enable others to follow them. The idea comes before the notation. Often
even the proof comes before the notation.

\start
Date: Thu, 22 Sep 2005 09:48:19 -0400
From: Bill Page
To: Martin Rubey
Subject: RE: DistributedExpression (was: How can I get every term of an expression ?)

On September 22, 2005 5:24 AM Martin Rubey wrote:
> > ...
> > Axiom's approach to output as a coercion to the type 
> > OutputForm is radically different than any other computer
> > algebra system that I know. 
> 
> Yes.
> 
> > There is an attempt also in Axiom to do the same with 
> > input (InputForm and SExpressions etc.) 
> 
> I think that this attempt is doomed to fail. Still it may be 
> useful, at least for debugging.
>

Could you explain why you think this approach is "doomed
to fail"? To me it seems simply under developed in the
current version of Axiom. I don't see any conceptual problems
with extending the idea. So far I have found it quite
useful, for example in implementing the 'op()' operator
for manipulating parts of expressions. See

http://wiki.axiom-developer.org/ManipulatingExpressions
 
> 
> > Understanding how to use types and domains in Axiom is 
> > both "90% of the problem" and "90% of the reasons why
> > one might want to use Axiom in the first place". We need
> > to write more about this ...
> 
> No. There is enough written about it (in the Aldor User 
> Guide). A short introductory text is in the Axiom book.
>

?! I am rather shocked that you would make this claim! :(
I have read all of this material as well as all of the
papers and articles on this subject and still I think that
types and domains in Axiom are a big problem... and also
the main reason to use Axiom as I said above.

It seems to me that one of the reasons that Axiom is not
used as much and is not being developed as quick as Mathematica,
Maple and even Maxima is precisely because of the problem to
trying to understand and use strong typing in computer algebra
systems (the marketing and commercial reasons not withstanding).
In a sense, Axiom is/was an experiment in the application of
strongly typed programming languages in computer algebra and
to be quite honest and blunt, for the most part the experiment
seems to have failed. :(
 
> 
> > Yes, I do agree that "cosmetics" is useful. In fact I have 
> > been know to claim that "notation is (almost) everything"
> > in mathematics 
> > ...
> 
> NO, NO, NO. Good notation is important, and I'd agree if 
> you'd say that mathematics builds on good notation. But it's
> not nearly "almost everything".
> 
> What (good) notation provides is a means to make your ideas 
> and proofs clear and enable others to follow them. The idea
> comes before the notation. Often even the proof comes before
> the notation.
> 

My philosophical position is much more radical. I take the
strong "Whorfian" view

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

that language (in this case mathematical notation) largely
determines what and how we think about problems.

I doubt that "proof comes before notation" because I doubt
that rigoursly expressing a proof is even possible without
the proper notation. So you may "think" that you have a
proof until you try to write it down ... :)

\start
Date: Thu, 22 Sep 2005 16:20:03 +0200
From: Martin Rubey
To: Bill Page
Subject: Philosophy...

Bill Page writes:
 > On September 22, 2005 5:24 AM Martin Rubey wrote:

 > > > There is an attempt also in Axiom to do the same with input (InputForm
 > > > and SExpressions etc.)
 > > 
 > > I think that this attempt is doomed to fail. Still it may be useful, at
 > > least for debugging.
 > 
 > Could you explain why you think this approach is "doomed to fail"? To me it
 > seems simply under developed in the current version of Axiom. I don't see
 > any conceptual problems with extending the idea. 

Hm. Maybe you are right there. I was thinking at domains like Polytope, where
the representation is not really available to axiom, or at a future Graph
domain. But you are right, in both cases it is probably possible to write a 

coerce: % -> InputForm

 > > > Understanding how to use types and domains [...]  We need to write more
 > > > about this ...
 > > 
 > > No. There is enough written about it (in the Aldor User Guide). A short
 > > introductory text is in the Axiom book.
 > >
 > 
 > ?! I am rather shocked that you would make this claim! :(

 > [...] still I think that types and domains in Axiom are a big problem... and
 > also the main reason to use Axiom as I said above.

What exactly do you think is a problem? I do admit that improving the quality
of the explanations in the Axiom Book would be good, however difficult. Same
for the Aldor User Guide, which is more technical and more detailed. But I
wouldn't write *more* about it. It's too much quantity!

 > It seems to me that one of the reasons that Axiom is not used as much and is
 > not being developed as quick as Mathematica, Maple and even Maxima is
 > precisely because of the problem to trying to understand and use strong
 > typing in computer algebra systems (the marketing and commercial reasons not
 > withstanding).

Look at MuPad, which works well. It has (nearly exactly) the same type
hierarchy as axiom -- still it sells. The difference is mainly the language of
MuPad, which is not statically typed, in contrast to Aldor/Spad.

 > In a sense, Axiom is/was an experiment in the application of
 > strongly typed programming languages in computer algebra and
 > to be quite honest and blunt, for the most part the experiment
 > seems to have failed. :(

No, most of it has been transformed into MuPad. However, I dare say that Aldor
is superiour to MuPad's language.

 > > What (good) notation provides is a means to make your ideas and proofs
 > > clear and enable others to follow them. The idea comes before the
 > > notation. Often even the proof comes before the notation.

 > I doubt that "proof comes before notation" because I doubt that rigoursly
 > expressing a proof is even possible without the proper notation. 

I don't disagree, it's probably only a matter of the right wording :-)

I believe (and I think that I know from experience) that sometimes I have the
right idea (intuition), and then I gradually improve notation, sharpen the
idea, improve notation, the idea makes it into a proof, improve notation, the
proof becomes more readable...

I did not claim that "expressing" or "communicating" a proof is (always)
possible without the right notation. (sometimes, it may be, given the right
audience)

\start
Date: Thu, 22 Sep 2005 08:31:10 -0700 (PDT)
From: Cliff Yapp
To: Martin Rubey, Bill Page
Subject: Re: Philosophy...

--- Martin Rubey wrote:
>  > In a sense, Axiom is/was an experiment in the application of
>  > strongly typed programming languages in computer algebra and
>  > to be quite honest and blunt, for the most part the experiment
>  > seems to have failed. :(
> 
> No, most of it has been transformed into MuPad. However, I dare say
> that Aldor is superiour to MuPad's language.

I think the jury is still out on strongly typed issues - such systems
(including Axiom, in some ways) tend to be designed by experts for
experts, and thus it is not surprising that in terms of "market share"
they don't do as well.  I suspect core technical merit has little to do
with such issues, which is quite unfortunate.

I think it is becoming increasingly clear that the Axiom/Aldor issue
needs to be resolved soon.  If serious work with Aldor is to go forward
and not result in fragmenting the Axiom community, the licensing issues
need to be sorted out.  And it sounds from what I've been hearing that
we really, really should be using Aldor if at all possible.

If MuPad is using a lot of the ideas that went into Axiom, a) that's
good and b) we need to do some things significantly different/better
than MuPad to attract a userbase.  Personally, I think this means
trying seriously to merge computer algebra with proof systems, and
creating a computational environment were people can know and prove
that an answer given by the computer is correct.  Just as security is
now the great need in operating system and network design, I think
verifiable correctness and trustable answers and the great frontier for
CAS.  Feature sets have matured quite a bit over the years, so
competing on features isn't enough (IMHO).  If we do that, it's hard to
avoid becoming just another CAS, with a few advantages and a few
disadvantages compared to other systems.  The net result will be people
sticking with what they know. (Maple, Mathematica, what have you.)

There seem to have been a number of efforts to tie Axiom to proof
systems over the years.  I would like to learn more about those
efforts, why they did or didn't work, and why they weren't integrated
into mainstream Axiom. If the difficulties can be overcome, this seems
to me to be the way to make Axiom a) something new and different from
the user point of view and b) the logical choice for a major
theoretical mathematics journal to incorporate into it's system.  Past
archives could be converted to Axiom pamphlet files (when it makes
sense to do so) and we could see if Axiom is up to tracking
mathematical developments over a couple of decades.

Anyway, just some thoughts, for whatever they may be worth.

P.S.  Hey Tim, are there any folks at CMU that are into this kind of
stuff?  Sounds like something that might appeal to them.

\start
Date: Thu, 22 Sep 2005 19:57:52 +0200
From: Francois Maltey
To: Martin Rubey
Subject: Re: Philosophy...

Hello Bill, Martin and all others !

> Look at MuPad, which works well. It has (nearly exactly) the same type
> hierarchy as axiom -- still it sells. 

> The difference is mainly the language of MuPad, 
> which is not statically typed, in contrast to Aldor/Spad.

Can you write an example ?
what can I do with mupad and I can't do with axiom ?

\start
Date: Thu, 22 Sep 2005 20:40:45 -0700
From: Ed Borasky
To: list
Subject: Re: Philosophy...

C Y wrote:

>--- Martin Rubey wrote:
>  
>
>> > In a sense, Axiom is/was an experiment in the application of
>> > strongly typed programming languages in computer algebra and
>> > to be quite honest and blunt, for the most part the experiment
>> > seems to have failed. :(
>>
>>No, most of it has been transformed into MuPad. However, I dare say
>>that Aldor is superiour to MuPad's language.
>>    
>>
>
>I think the jury is still out on strongly typed issues - such systems
>(including Axiom, in some ways) tend to be designed by experts for
>experts, and thus it is not surprising that in terms of "market share"
>they don't do as well.  I suspect core technical merit has little to do
>with such issues, which is quite unfortunate.
>  
>
That battle is raging right now in the web development arena, and 
"strongly typed" and "static" languages are taking a beating by dynamic 
environments like Ruby, Python, Perl and PHP. Let's face it ... people 
who program for a living like dynamic languages and hate static ones. If 
the "industry" couldn't hire thousands of inexpensive C programmers, the 
language would have died out except as an "assembler" for dynamic 
language interpreters and the Linux kernel. :)

>If MuPad is using a lot of the ideas that went into Axiom, a) that's
>good and b) we need to do some things significantly different/better
>than MuPad to attract a userbase.  Personally, I think this means
>trying seriously to merge computer algebra with proof systems, and
>creating a computational environment were people can know and prove
>that an answer given by the computer is correct.  Just as security is
>now the great need in operating system and network design, I think
>verifiable correctness and trustable answers and the great frontier for
>CAS.  Feature sets have matured quite a bit over the years, so
>competing on features isn't enough (IMHO).  If we do that, it's hard to
>avoid becoming just another CAS, with a few advantages and a few
>disadvantages compared to other systems.  The net result will be people
>sticking with what they know. (Maple, Mathematica, what have you.)
>  
>
Well, in the for-profit world, I use Derive. It does everything I need 
at a fraction of the price of the others. MuPad isn't really "free" as 
in either freedom or beer. In the free world, I mostly use Maxima, and 
then only on Linux. Maxima is pretty much useless to me, though, unless 
I also have TeXmacs to typeset my math and mix in text with it.

As to verifiable correctness, a similar situation has occurred in the 
numerical world with such things as interval arithmetic and floating 
point computations based on provable properties of the arithmetic. What 
happens is that the computational cost and complexity of the 
implementation are significant and so it doesn't get done. "Cheap and 
good enough" trumps "expensive and perfect" unless there *isn't* a "good 
enough".

I think you may be seeing the same sort of thing trying to pair CAS with 
proof engines. In a way, your challenge may be worse than the challenge 
of getting verifiable numerical calculations adopted, because both CAS 
and theorem proving rapidly get into NP-Complete and NP-Hard problems, 
whereas the worst-case numerical algorithms in common use are N**4. 
They're both nice dreams for computationalists, though. :)

\start
Date: Fri, 23 Sep 2005 00:57:44 -0400
From: Bill Page
To: Martin Rubey
Subject: Mostly about MuPad (was: Philosophy... )

On September 22, 2005 10:20 AM Martin Rubey wrote:
> 
> Bill Page wrote: 
>> [...] still I think that types and domains in Axiom are a 
>> big problem... and also the main reason to use Axiom as I
>> said above.
> 
> What exactly do you think is a problem?

There are many problems most of which we have discussed to a
greater or lesser extent here over the last two years:

#1 Understanding how to apply the programming language concept
   of 'types' (as in Pascal) to mathematical 'domains' (as in
   Bourbaki and category theory). Are types and domains the
   same thing? When to define Axiom categories?

#2 Understanding how and when to use representations (Rep) and
   the role of primitive domains like record, union and mapping.
   How is this related to object-oriented programming concepts?

#3 Understanding the structure of Axiom's more than 1,000 existing
   domains and categories. Lack of adequate documentation. Difficulty
   of navigating and browsing such a large structure. Difficulty in
   relating design choices to contemporary mathematical concepts.
   In spite of it's already large size, only a relatively small part
   of mathematics is implemented.

#4 Dealing with unexpected and sometimes complex behaviour of the
   Axiom interpreter -- mainly it's heuristics relating to guessing
   types. Differences between the Axiom "interpreter language" and
   the Axiom "library language".

#5 Differences between the SPAD language and the Aldor language.

#6 ...

> I do admit that improving the quality of the explanations in the
> Axiom Book would be good, however difficult. Same for the Aldor
> User Guide, which is more technical and more detailed. But I
> wouldn't write *more* about it. It's too much quantity!

Actually I mostly agree with you about this. Quantity does not
substitute for quality and quality is more difficult. For example,
over the last few years the participants of axiom-developer list
here have probably exchanged a much greater quantity of text than
contained in the original 1,000+ page Axiom Book (from which we
have plans to create 4 or 5 new volumes). In general, as Axiom
documentation the quality and coverage of the resulting online
archive might be considered rather "low". But on MathAction we
have (gradually) collecting and re-writing some of the material
that might have some lasting relevance and quality. When I say
"write more", I am thinking mostly of improving the "quality"
in this way.

> 
> > It seems to me that one of the reasons that Axiom is not 
> > used as much and is not being developed as quick as
> > Mathematica, Maple and even Maxima is precisely because of
> > the problem to trying to understand and use strong typing
> > in computer algebra systems (the marketing and commercial
> > reasons not withstanding).
> 
> Look at MuPad, which works well. It has (nearly exactly) the
> same type hierarchy as axiom -- still it sells. The difference
> is mainly the language of MuPad, which is not statically typed,
> in contrast to Aldor/Spad.
>

Could you explain what you mean by "statically typed"? I don't
think Aldor and Spad could be said to be statically typed either.
I agree that in contrast to Aldor and Spad, Mupad is not "strongly
typed". And this is exactly my point. 

The "type hierarchy" in MuPad was more or less directly grafted on
to MuPad in version 2. Version 1 of MuPad looked almost identical
to Maple release 4 and had essentially no concept of type at all.
But the structure of these programming languages have diverged
greatly in MuPad versions 2 and 3 and Maple from versions 7, 8, 9
and 10. Maple by deliberate design has no concept of type at all
(the "assume" facility notwithstanding). Both MuPad and Maple
are taking very different paths towards a more complete "object-
orientation", and neither are really similar to Axiom.

Yes, MuPad does "sell" although considerably behind Mathematica
and Maple. Originally MuPad was open source but since version 2
the kernel software has a proprietary license. Like Maple, most
of the algebra source code is "open" and accessible to the end
user but licensing and copyright remains an issue. I think MuPad
would be doing much better now if it had remained entirely open
source. And if that had happened we might be discussing MuPad
instead of Axiom right here and now. :)

MuPad's implementation of Axiom's type hierarchy is described
here:

Axioms, Categories and Domains
Klaus Drescher
January 2002 Automath Technical Report No 1
http://research.mupad.de/doc/31/eng/domainref.pdf

Here are some highlights:

In the section "Categories":

http://research.mupad.de/doc/31/eng/domainref_se12.html#x14-230004

See especially "Figure 4: Graph of the Categories of the Integers".
This graph is nearly identical to part of the graph inside the
front cover of the Axiom Book.

Axiom is referenced explicitly in the section titled
"General Nonsense?":

http://research.mupad.de/doc/31/eng/domainref_se17.html#x20-310007

"Most of the concepts in the constructors are based on ideas in
AXIOM, see [7]. Many new algorithms have been implemented in
AXIOM for the first time because there the user has the algebraic
structures handy that he can use for his problem, independent of
their representation. All objects in AXIOM are strictly typed.
This is not possible in MuPAD because the MuPAD language is not
strictly typed.

A debatable feature of AXIOM is the automatic type conversion:
the system tries to determine the type of the user's input
on entry, i.e., to convert untyped expressions directly into
domain elements. In MuPAD the user currently has to explicitly
convert the type "by hand". It is, of course, in some cases
easier for the user not to have to give the type. On the other
hand, it is often difficult to determine the type of an
expression that the user has in mind. For this AXIOM uses
time-consuming and error-susceptible heuristics."

[7] R.D. Jenks, R.S. Sutor. AXIOM, The Scientific Computation
    System. Springer, 1992.

In "The Constructors of the MuPAD Library":

http://research.mupad.de/doc/31/eng/domainref_se18.html

Notice in particular even specific details of Axiom's category
structure are implemented:

Cat::Ring - the category of rings
http://research.mupad.de/doc/31/eng/Cat_Ring.html#Ring

Cat::Rng - the category of rings without unit
http://research.mupad.de/doc/31/eng/Cat_Rng.html#Rng 

>> In a sense, Axiom is/was an experiment in the application of
>> strongly typed programming languages in computer algebra and
>> to be quite honest and blunt, for the most part the experiment
>> seems to have failed. :(
> 
> No, most of it has been transformed into MuPad.

I disagree. In spite of what MuPad has borrowed from Axiom, it
seems to me that so far MuPad has implemented only a small part
of the original concept of the Axiom designers. I think that
this is probably intentional on the part of the MuPad developers
and is at least in part due to the perception that the "Axiom
Experiment" failed to demonstrate the utility of it's strong
type system.

The situation is similar with statically typed programming
languages in general. For example, hardly anyone writes in
Pascal any more. But there is still a lot of research going
on in strongly typed languages such as Haskell and Ocaml.

> However, I dare say that Aldor is superior to MuPad's
> language.

I agree. In many respects Spad and Aldor anticipated many of
the features implemented in Haskell and Ocaml. And they are
strongly motivated by abstract mathematical concepts. MuPad
(and Maple and Mathematica) on the other hand has not yet
shed it's origins as what Tim Daly referred to as the
"engineering approach to computer algebra".

\start
Date: Fri, 23 Sep 2005 01:37:48 -0400
From: Bill Page
To: Ed Borasky
Subject: Static versus Dynamically typed (was:	Philosophy... )

On September 22, 2005 11:41 PM Ed Borasky wrote:

> Bill Page worte: 
> > In a sense, Axiom is/was an experiment in the application of
> > strongly typed programming languages in computer algebra and
> > to be quite honest and blunt, for the most part the experiment
> > seems to have failed. :(

> Martin Rubey wrote:
> > No, most of it has been transformed into MuPad. However, I
> > dare say that Aldor is superiour to MuPad's language.
> 
> C Y wrote:
> > I think the jury is still out on strongly typed issues - such
> > systems (including Axiom, in some ways) tend to be designed
> > by experts for experts, and thus it is not surprising that in
> > terms of "market share" they don't do as well.  I suspect core
> > technical merit has little to do with such issues, which is
> > quite unfortunate.

Ed Borasky wrote:
>
> That battle is raging right now in the web development arena,
> and "strongly typed" and "static" languages are taking a beating 
> by dynamic environments like Ruby, Python, Perl and PHP. Let's
> face it ... people who program for a living like dynamic languages
> and hate static ones. If the "industry" couldn't hire thousands
> of inexpensive C programmers, the language would have died out
> except as an "assembler" for dynamic language interpreters and
> the Linux kernel. :)

We need to define carefully what we mean by "stongly typed"
programming language. I think this article does a good job:

http://en.wikipedia.org/wiki/Strongly-typed_programming_language

and http://en.wikipedia.org/wiki/Datatype

"Static typing as opposed to dynamic typing. In a static type
system, type annotations are associated with variable names
rather than values. It is thus possible for the compiler to
prove via static analysis that a program contains no type
errors."

"Strong guarantees about the run-time behavior of a program
before program execution, whether provided by static analysis
or another mechanism."

So one issue is really statically typed versus dynamically
typed.

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

The C language is statically typed but not strong. Haskell and
Ocaml are strongly static typed. I think SPAD and Aldor are also
strong static typed languages. (However I am not so sure about
the 'pretend' construct in these languages which looks something
like a type-cast in C.) Languages like Python, Lisp, Maple and
are dynamnically typed. I think that MuPad is also dynamically
typed.

\start
Date: Fri, 23 Sep 2005 01:59:36 -0400
From: Bill Page
To: Ed Borasky
Subject: RE: Static versus Dynamically typed (was: Philosophy... )

On September 23, 2005 1:38 AM I wrote:

> 
> The C language is statically typed but not strong. Haskell and
> Ocaml are strongly static typed. I think SPAD and Aldor are also
> strong static typed languages. (However I am not so sure about
> the 'pretend' construct in these languages which looks something
> like a type-cast in C.) Languages like Python, Lisp, Maple and
> are dynamnically typed. I think that MuPad is also dynamically
> typed.
> 

I should also mention that the issue of 'type' in languages (like
Spad and Aldor), where types are first-class objects (values), i.e.
can be computed dynamically and returned as results of functions,
considerably complicates the notion of "static" versus "dynamic".
However I think the adjective "strong" still clearly applies.

>From http://www.aldor.org

"From a technical point of perspective, Aldor is a type-complete,
strongly-typed, imperative programming language with a two-level
object model of categories and domains (similar to the concept of
interfaces and classes in Java). Types and functions are first
class entities allowing them to be constructed and manipulated
within Aldor programs just like any other value. Pervasive use of
dependent types allows static checking of dynamic objects and
provides object-oriented features such as parametric polymorphism."

\start
Date: Fri, 23 Sep 2005 07:35:30 -0400
From: William Sit
To: Bill Page
Subject: re: Static versus Dynamically typed (was:Philosophy... )

Bill Page wrote:
> >From http://www.aldor.org
> 
> "From a technical point of perspective, Aldor is a type-complete,
> strongly-typed, imperative programming language with a two-level
> object model of categories and domains (similar to the concept of
> interfaces and classes in Java). Types and functions are first
> class entities allowing them to be constructed and manipulated
> within Aldor programs just like any other value. Pervasive use of
> dependent types allows static checking of dynamic objects and
> provides object-oriented features such as parametric polymorphism."
> 
Can some Aldor expert expand on this? For example, can functions be created,
modified, and compiled and called all at run time? (People used to do code
modification on assembly languages and may still do, but the practice is I think
no longer promoted, if not outright banned.)

\start
Date: Fri, 23 Sep 2005 08:11:57 -0400
From: William Sit
To: Bill Page
Subject: Re: Failure of Axiom? (was: Static versus Dynamically typed) )

Bill Page wrote:
> 
> On September 22, 2005 11:41 PM Ed Borasky wrote:
> 
> > Bill Page worte:
> > > In a sense, Axiom is/was an experiment in the application of
> > > strongly typed programming languages in computer algebra and
> > > to be quite honest and blunt, for the most part the experiment
> > > seems to have failed. :(

Just to provide a better balance of these discussions, here are some quotations
taken from research papers involving Axiom published during 1999 to 2001. Note
that these authors had used other computer algebra systems for the SAME research
earlier. I am including three representatives from major research areas of
computer algebra:  abstract mathematics, applied computation, and comparison of
algorithms. For details, see the original articles.

(1) Ito calculus is a formalism to study continuous random
processes. Kendall [1] wrote:

"This article reports on progress in the implementation of Ito
calculus in the powerful and innovative computer algebra package
AXIOM, in the context of a decade of previous implementations and
applications.  It is shown how the elegant algebraic structure
underlying the expressive and effective formalism of \ito
calculus can be implemented directly in AXIOM using the package's
programmable facilities for 'strong typing' of computational
objects.  An application is given of the use of the implementation to
provide calculations for a new proof, based on stochastic
differentials, of the Mardia-Dryden distribution from statistical
shape theory."

And from the summary (the earlier implementations are in Reduce and
Mathematica):

"In this article we have described how the innovative features
of AXIOM can be used to exploit the elegant formalism of the
\ito calculus, producing an implementation (Kendall 1998a) of
Itovsn3 substantially improving on its predecessors (Kendall
1991a, b, 1993b)."


(2) When algorithms for computing three-loop (Feynman) diagrams in Heavy
Quark Effective Theory (HQET) using integration-by-parts recurrence
relations are implemented in both Reduce and Axiom, there is substantial
increase in speed in Axiom.  Grozin reported [2]:

"I also re-implemented it in Axiom
[25].  All expressions involved are linear combinations of basis
integrals with coefficients which are rational functions of $d$.  It
is convenient to use Axiom Vector domain, which has all the necessary
operations.  This makes intermediate expressions shorter than in the
case when multivariate rational functions are used for entire
expressions, because, typically, not all basis integrals are
accompanied by every possible denominator.  The amount of GCD
calculations is thus reduced.  This improvement can be, in principle,
back-propagated to the REDUCE implementation by using matrices.
However, working with matrices in REDUCE is awkward, because there are
no local matrix variables, and no easy way for a function to return a
matrix.  I made no systematic benchmarking; one test set of 9375
recurrence relations took 2019 seconds in REDUCE and 350 seconds in
Axiom."

(3) In choosing a system to compare different algorithms for computations with
triangular sets of polynomial equations using Gr\"obner basis (GB), Aubry and
Maza \cite[p.~137]{Aubry} selected Axiom for the following reasons:

"We thought that the AXIOM computer algebra system (Jenks and Sutor,
1992; Broadbery et al., 1994), with its strongly typed and
object-oriented language, is convenient to satisfy our first
requirement.  We defined categories corresponding to the different
properties of triangular sets, packages and domains for the common
data structures and sub-routines.  Furthermore, AXIOM (version 1.2) is
connected with GB, the very powerful Gr\"obner engine developed by
Faug\`ere (1994).  This allowed us to run the non-trivial Gr\"obner
basis computations that are required in order to satisfy our other two
requirements."

[1] Kendall WS, Symbolic Ito calculus in AXIOM: An ongoing story
STATISTICS AND COMPUTING 11 (1): 25-35 JAN 2001

[2] Grozin AG, Calculating three-loop diagrams in heavy quark effective theory
with integration-by-parts recurrence relations
JOURNAL OF HIGH ENERGY PHYSICS (3): Art. No. 013 MAR 2000

[3] Aubry P, Maza MM, Triangular sets for solving polynomial systems: a
comparative implementation of four methods
JOURNAL OF SYMBOLIC COMPUTATION 28 (1-2): 125-154 JUL-AUG 1999

You can make your own conclusion.

\start
Date: Fri, 23 Sep 2005 08:19:58 -0400
From: Cliff Yapp
To: list
Subject: Re: Philosophy...

On Thursday 22 September 2005 11:40 pm, Ed Borasky wrote:
>
> That battle is raging right now in the web development arena, and
> "strongly typed" and "static" languages are taking a beating by dynamic
> environments like Ruby, Python, Perl and PHP. Let's face it ... people
> who program for a living like dynamic languages and hate static ones. If
> the "industry" couldn't hire thousands of inexpensive C programmers, the
> language would have died out except as an "assembler" for dynamic
> language interpreters and the Linux kernel. :)

Well, to be fair, I think it's a question of what the programmer is trying to 
accomplish.  For quick prototyping and getting ones ideas into workable for 
as rapidly as possible, I agree dynamic languages are probably the tool of 
choice (e.g., Lisp.)  For doing something as correctly as possible, however, 
I'm not so sure.  I think the CAS field is a bit unique currently in being 
really interested in correctness.  (Or at least, some parts of it.)

> Well, in the for-profit world, I use Derive. It does everything I need
> at a fraction of the price of the others. MuPad isn't really "free" as
> in either freedom or beer. In the free world, I mostly use Maxima, and
> then only on Linux. Maxima is pretty much useless to me, though, unless
> I also have TeXmacs to typeset my math and mix in text with it.

Right - Axiom doesn't have enough mindshare right now to challenge even Maxima 
in "popularity."  I would argue that this isn't necessarily a bad thing - I 
would expect Axiom to be less of a "phenomenon" until it reaches a point 
where it is competitive, which will take longer when developing for 
correctness is the first concern.

> As to verifiable correctness, a similar situation has occurred in the
> numerical world with such things as interval arithmetic and floating
> point computations based on provable properties of the arithmetic. What
> happens is that the computational cost and complexity of the
> implementation are significant and so it doesn't get done. "Cheap and
> good enough" trumps "expensive and perfect" unless there *isn't* a "good
> enough".

I'm hoping open source will allow us to short circuit those economic 
limitations to some extent.  If we can create a really good system, perhaps 
we can move the "good enough" yardstick further out.

> I think you may be seeing the same sort of thing trying to pair CAS with
> proof engines. In a way, your challenge may be worse than the challenge
> of getting verifiable numerical calculations adopted, because both CAS
> and theorem proving rapidly get into NP-Complete and NP-Hard problems,
> whereas the worst-case numerical algorithms in common use are N**4.
> They're both nice dreams for computationalists, though. :)

Well, dreams are what great accomplishments start as :-).  I think both 
verifiable numerical computations and smart integration with proof systems 
could go a long way towards making Axiom not just another entry in the CAS 
market but a fundamentally new type of software - maybe even a "killer app" 
in relevant mathematical and scientific areas.  

Of course, I'm not really qualified to have dreams like this yet :-).  Maybe 
after a few years of studying up on the issue I'll know why it's not worth 
doing :-/.

\start
Date: Fri, 23 Sep 2005 14:52:23 +0200
From: Martin Rubey
To: William Sit
Subject: Re: Failure of Axiom? (was: Static versus

Dear William, *

although I know that Axioms approach has *not* failed I wouldn't qualify work
from 2001 as recent. A lot has changed since then, especially regarding MuPad.

Again, if I weren't convinced of Axiom, I wouldn't put that much of an effort
into it. However, A LOT OF WORK HAS TO BE DONE. 

\start
Date: Fri, 23 Sep 2005 15:25:16 +0200
From: Martin Rubey
To: Bill Page
Subject: Re: Mostly about MuPad (was: Philosophy... )

Dear Bill,

unfortunately, I have too little time to answer everything... Especially some
of #1 to #6 need more thinking before I answer.

Bill Page writes:

 > Could you explain what you mean by "statically typed"? I don't think Aldor
 > and Spad could be said to be statically typed either.  I agree that in
 > contrast to Aldor and Spad, Mupad is not "strongly typed". And this is
 > exactly my point.

Hm, I thought that static typing means that the type of a variable is known at
compile time, which is clearly the case in Aldor/Spad but not necessarily in
the Axiom interpreter. As far as I know, it is not the case at all in MuPad.

I don't really know what strongly typed would mean. According to wikipedia,
it's meaning depends on the person using it :-)

 > The "type hierarchy" in MuPad was more or less directly grafted on to MuPad
 > in version 2. Version 1 of MuPad looked almost identical to Maple release 4
 > and had essentially no concept of type at all.  But the structure of these
 > programming languages have diverged greatly in MuPad versions 2 and 3 and
 > Maple from versions 7, 8, 9 and 10. Maple by deliberate design has no
 > concept of type at all (the "assume" facility notwithstanding). Both MuPad
 > and Maple are taking very different paths towards a more complete "object-
 > orientation", and neither are really similar to Axiom.

I find current MuPad quite similar to Axiom. There are domains, categories and
similar stuff, but it seems that Axiom handles this things a lot stricter than
MuPad.

 > >> In a sense, Axiom is/was an experiment in the application of strongly
 > >> typed programming languages in computer algebra and to be quite honest
 > >> and blunt, for the most part the experiment seems to have failed. :(
 > > 
 > > No, most of it has been transformed into MuPad.
 > 
 > I disagree. In spite of what MuPad has borrowed from Axiom, it seems to me
 > that so far MuPad has implemented only a small part of the original concept
 > of the Axiom designers. 

Well, I admit that I don't know MuPad well enough to judge. In any case, I'm
only talking about the design, not the amount of stuff actually implemented...

\start
Date: Fri, 23 Sep 2005 10:29:35 -0400
From: Bill Page
To: Martin Rubey, William Sit
Subject: RE: Failure of Axiom? (was: Static versusDynamically typed) )

Bill Page wrote:
>
> In a sense, Axiom is/was an experiment in the application of
> strongly typed programming languages in computer algebra and
> to be quite honest and blunt, for the most part the experiment
> seems to have failed. :(
> 

On September 23, 2005 8:12 AM William Sit wrote:
>
> Just to provide a better balance of these discussions, here 
> are some quotations taken from research papers involving
> Axiom published during 1999 to 2001. Note that these authors
> had used other computer algebra systems for the SAME research
> earlier. I am including three representatives from major 
> research areas of computer algebra:  abstract mathematics,
> applied computation, and comparison of algorithms. For details,
> see the original articles.
> ...
> You can make your own conclusion.

On September 23, 2005 8:52 AM Martin Rubey wrote:
> 
> although I know that Axioms approach has *not* failed I 
> wouldn't qualify work from 2001 as recent. A lot has changed
> since then, especially regarding MuPad.
> 
> Again, if I weren't convinced of Axiom, I wouldn't put that 
> much of an effort into it. However, A LOT OF WORK HAS TO BE
> DONE. 
>

I think Martin Rubey's and William Sitt's contributions to
Axiom are outstanding! Their dedication and the work of
other people here clearly demonstrates that Axiom has not
"failed", yet... Although I said that I thought the Axiom
experiment was (for the most part) a failure, I should have
qualified that as applying most directly to the commercial
version of Axiom that was for a brief time a direct competitor
to Maple and Mathematica. About the current open source
effort: I agree completely with Martin's statement: "if
I weren't convinced of Axiom, I wouldn't put much effort
into it".

I think William Sitt's quotations are encouraging. Also we
should not forget the enormous effort that was put into the
implementation of the current Axiom library itself. This
library contains over 1,000 domains and categories that interact
in complex and apparently correct manner. This is a major
accomplishment and it's all written in SPAD. Although I said
earlier that Axiom's library covers only a small part of
mathematics, to be fair I should also point out that in scope,
if not always in depth, it covers much more mathematics than
either Maple, Mathematica or MuPad.

So in that respect the Axiom experiment in applying a strongly
typed programming language in computer algebra has not been
a failure. But there is the larger sense in which the medical
idiom: "The operation was a success but the patient died anyway
... " almost applies to Axiom. I think Axiom is in a critical
state. As open source software it can survive in this state
for a long time, but to advance in needs a lot more support.
It is quite disappointing to me that during that last two years
of fairly intense effort on our part, Axiom has not been
adopted by any major university program or research institute
and we are still struggling to find any kind of substantial
support. :(

\start
Date: Fri, 23 Sep 2005 16:01:05 +0200 (CEST)
From: Bertfried Fauser
To: Bill Page
Subject: RE: Failure of Axiom? (was: Static versusDynamically typed) )

Dear Bill and others,

	even if I was very quiet, due to an work overload with 'regular
busines', I might add to this philosophy discussion that I _do_ need a
strongly typed language! I had much discussion with the Marn le Valle
group about Mupad. Their argument is that there is already now to few
development power to come up with compeeting systems/packages (say in the
combinatorial/Hopf algebra world). And combinat for Mupad is quite
impressive, collecting algorithms from SYMMETRICA/SCHUR and other
packages.

To add types to Maple needs lots of (very slow and painstaking) code which
does not do any math for you. Furthermore its error prone.

I have no experience with Mupad, but it seems to have (some of) the same
deficiencies as has Maple. Only very clever data formats (keeping type
informations, as in the combinat package) may help, which poses the burden
of typing once more to the user.

My experience with any CAS (including the terrible but brilliantly fast
SCHUR) is that one needs a good start (local Guru). AXIOM has its problems
with the steep learning curve for the beginner. Thats what stoped some of
my more realistics approches to my problems, but will not stop me to try
to learn more AXIOM programming to do it.

I had some time ago a discussion with Maple protagonists in .de and they
assured, after being questioned, that Maple tries to pursue engineers,
studendts etc. Hence they try to approch large (in quantity) groups, since
there they can make a deal there. Scientific achievements or features
needed to implement them are not on the priority list. AXIOM users seem to
be of such a kind that they have problems which do not fit into the
Maple/Mathematica standard solution set. These are ambitious people PhD
students etc. So I think it will take more time unless these people become
multipliers and teach onw studentds AXIOM.

Meanwhile I will stop typing in philosophy `nonsense` and try to do some
more science and AXIOM programming... ;-))

\start
Date: Fri, 23 Sep 2005 12:17:59 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#206 Interpreter code generation failed for function returning a Type] 

Here is the same function in SPAD:
\begin{spad}
)abbrev package TT testtype
testtype(): exports == implementation where
  exports == with
    testt: (Integer) -> Type
  implementation == add
    testt(x) =      x=0 => Integer
      Float
\end{spad}

Calling this function like this::

 !\begin{axiom}
  testt(1)
  \end{axiom}

causes Axiom to crash::

  (1) -> testt(1)

   >> System error:
   Caught fatal error [memory may be damaged]

\start
Date: Fri, 23 Sep 2005 11:58:55 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#206 Interpreter code generation failed for function returning a Type] (new) 

This function should return a type that depends on a
parameter:
\begin{axiom}
tt:INT->Type
tt(x)== (x=0 => Integer; Float)
tt(1)
\end{axiom}

\start
Date: Fri, 23 Sep 2005 12:32:07 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#206 Interpreter code generation failed for function returning a Type] 

    tt1: (Integer) -> Type

  !\begin{axiom}
  tt1(1)

  (1) -> tt1(1)

But this works using Aldor! :-)
\begin{aldor}
#include "axiom.as";
testtype2(): with {
    tt2: (Integer) -> Type;
} == add {
    tt2(x:Integer):Type == {
      x=0 => Integer;
      Float;
      }
    }
\end{aldor}

\begin{axiom}
tt2(1)
tt2(0)
\end{axiom}

\start
Date: Fri, 23 Sep 2005 13:50:00 -0400
From: Bill Page
To: William Sit
Subject: re: Static versus Dynamically typed (was:Philosophy... )

On September 23, 2005 7:36 AM William Sit wrote:
> From www.aldor.org:
> > Types and functions are first class entities allowing them to be
> > constructed and manipulated within Aldor programs just like any
> > other value.
> > 
> Can some Aldor expert expand on this? For example, can functions be
> created, modified, and compiled and called all at run time? (People 
> used to do code modification on assembly languages and may still do,
> but the practice is I think no longer promoted, if not outright banned.)
> 

People certainly still do this, for example in lisp, Python and
Haskell.

I can't speak about Aldor specifically (yet) but I am sure that
it is possible.

In Axiom it is possible. See for example section 9.50 MakeFunction
in the Axiom book. There are numerous other examples of this in
Axiom.

\start
Date: Fri, 23 Sep 2005 14:07:13 -0400
From: Bill Page
To: William Sit
Subject: types as values

On September 23, 2005 7:36 AM William Sit wrote:
> From www.aldor.org:
> > Types and functions are first class entities allowing them to be
> > constructed and manipulated within Aldor programs just like any
> > other value.
> >
> Can some Aldor expert expand on this? For example, can functions be
> created, modified, and compiled and called all at run time? (People
> used to do code modification on assembly languages and may still do,
> but the practice is I think no longer promoted, if not outright
> banned.)

In

http://wiki.axiom-developer.org/206InterpreterCodeGenerationFailedForFunctio
nReturningAType

I find that in Aldor at least it is possible to treat types as
values and return them as the result of functions. Both the
Axiom interpret and SPAD fail to compile my simple example.

But having defined the function tt2 in Aldor like this:

#include "axiom.as";
testtype2(): with {
    tt2: (Integer) -> Type;
} == add {
    tt2(x:Integer):Type == {
      x=0 => Integer;
      Float;
      }
    }

How can I use it in Axiom in a useful manner? For example,
if I write:

  (1) -> n:tt2(0)

Axiom says:

  "Category, domain or package constructor tt2 is not available"

which is true of course because it is 'testtype2' which is
the name of a **domain**. But even if I this:

 (2) -> intx := tt2(0)

   (2)  Integer
                            Type: Type
 (3) -> a:intx

   intx is not a valid type.

---------

I get what seems to be a peculiarly inconsistent result.

Any ideas?

\start
Date: Fri, 23 Sep 2005 14:24:59 -0400
From: Bill Page
To: William Sit
Subject: RE: types as values

On September 23, 2005 2:07 PM I wrote:
> 
> I find that in Aldor at least it is possible to treat types as
> values and return them as the result of functions.
> ...
> How can I use it in Axiom in a useful manner?
> ...
> Any ideas?
> 

Perhaps here is a clue:

(2) -> I:=tt2(0)

   (2)  Integer
                                                                   Type:
Type
(3) -> x:I

   I is not a valid type.
(3) -> J:=Integer

   (3)  Integer
                                                                 Type:
Domain
(4) -> x:J
                                                                   Type:
Void
(5) -> x:=1

   (5)  1
                                                                Type:
Integer

-----------

So my tt2(0) function is returning something from the domain
'Type'. But in (3) above the type of the result is 'Domain'.

This makes my head spin a little! :)

How can a write a function that returns something of type
'Domain'?

Or am I really terribly confused about all this?

\start
Date: Fri, 23 Sep 2005 23:50:11 -0700
From: Ed Borasky
To: list
Subject: Re: Philosophy...

Cliff Yapp wrote:

>On Thursday 22 September 2005 11:40 pm, Ed Borasky wrote:
>  
>
>>That battle is raging right now in the web development arena, and
>>"strongly typed" and "static" languages are taking a beating by dynamic
>>environments like Ruby, Python, Perl and PHP. Let's face it ... people
>>who program for a living like dynamic languages and hate static ones. If
>>the "industry" couldn't hire thousands of inexpensive C programmers, the
>>language would have died out except as an "assembler" for dynamic
>>language interpreters and the Linux kernel. :)
>>    
>>
>
>Well, to be fair, I think it's a question of what the programmer is trying to 
>accomplish.  For quick prototyping and getting ones ideas into workable for 
>as rapidly as possible, I agree dynamic languages are probably the tool of 
>choice (e.g., Lisp.)  For doing something as correctly as possible, however, 
>I'm not so sure.  I think the CAS field is a bit unique currently in being 
>really interested in correctness.  (Or at least, some parts of it.)
>  
>
Here's a sample of the kind of things developers from the 
"agile"/"extreme programming" school of thought have to say on the 
subject of "static vs. dynamic":

http://www.artima.com/weblogs/viewpost.jsp?thread=4639

Of course, the "general programming/scripting language" world is very 
different from the mathematical rigor world where Axiom and other CAS 
and proof engines live. My belief  is that the purpose of programming is 
to deliver high-quality software as defined by the user. The user of a 
web application, like on-line banking, has a much different view of what 
high quality is than a user of a CAS or proof engine ... *and* both are 
much different than the definition of quality when the user is a 
*developer* of on-line banking software or the user is a *developer* of 
a numerical package, CAS or proof engine.

But ... well ... Axiom has a Lisp core. And the Lisp 
compiler/interpreter has a C core. So does the Gnu Compiler Collection. :)

I think it's important to automate as much as is possible of *every* 
knowledge worker's job. This is the computer as "intelligence 
amplifier". The job of a mathematician (leaving aside the important 
distinction between theoretical and applied!) is to get correct results. 
So as a sometimes applied mathematician, I think the combination of CAS 
and proof engine is a good idea, and the discipline of strong static 
typing and a complier that can catch lots of bugs in one project while 
I'm working on another project makes my job easier, not harder.

On the other hand, as a practicing performance engineer and capacity 
planner, there are times when I have to grind through gigabytes of 
performance data and do a queueing model. Then I want a programming 
environment that allows me to bang out a quick solution that executes 
efficiently and gives me visualizations that tells me what's going on. 
For that, I use Perl and R and, increasingly, relational databases. I 
could probably replace R with Axiom, but I'm guessing I'd still need the 
Perl component. 

I've done a little "number crunching" in Derive. It works surprisingly 
well, actually -- if my colleagues were mathematicians or physicists 
rather than managers and software engineers, I'd do all but the largest 
problems in a CAS, provided it had a good typesetting engine like 
TeXmacs. Derive isn't all that bad at typesetting, but it's nowhere near 
as "pretty" as TeXmacs with an Axiom or Maxima session.

>  
>
>>Well, in the for-profit world, I use Derive. It does everything I need
>>at a fraction of the price of the others. MuPad isn't really "free" as
>>in either freedom or beer. In the free world, I mostly use Maxima, and
>>then only on Linux. Maxima is pretty much useless to me, though, unless
>>I also have TeXmacs to typeset my math and mix in text with it.
>>    
>>
>
>Right - Axiom doesn't have enough mindshare right now to challenge even Maxima 
>in "popularity."  I would argue that this isn't necessarily a bad thing - I 
>would expect Axiom to be less of a "phenomenon" until it reaches a point 
>where it is competitive, which will take longer when developing for 
>correctness is the first concern.
>  
>
Well ... I don't know ... have you looked at the Maxima road map 
recently? They've been at 5.9.1 for what seems like ages, and what they 
want in 6.0 is huge! Axiom, Maxima and Reduce are the old war horse CAS. 
Derive was born on a TRS-80, grew into a strong adolescent on DOS and 
now runs on Windows. I don't know too much about Maple or Mathematica; I 
"almost" learned Maple but it was way too slow on a 25 MHz Motorola 
88100 with 32 MB of RAM for any practical use.

(Yes, Derive really was born on a TRS-80, a 64 kilobyte Z80 machine with 
a cassette I/O subsystem.) :)

>  
>
>>As to verifiable correctness, a similar situation has occurred in the
>>numerical world with such things as interval arithmetic and floating
>>point computations based on provable properties of the arithmetic. What
>>happens is that the computational cost and complexity of the
>>implementation are significant and so it doesn't get done. "Cheap and
>>good enough" trumps "expensive and perfect" unless there *isn't* a "good
>>enough".
>>    
>>
>
>I'm hoping open source will allow us to short circuit those economic 
>limitations to some extent.  If we can create a really good system, perhaps 
>we can move the "good enough" yardstick further out.
>  
>
Might I suggest heading over to this web site:

http://headrush.typepad.com/creating_passionate_users/

The MathAction / Axiom front page is exactly what you need to create 
passionate users!

>  
>
>>I think you may be seeing the same sort of thing trying to pair CAS with
>>proof engines. In a way, your challenge may be worse than the challenge
>>of getting verifiable numerical calculations adopted, because both CAS
>>and theorem proving rapidly get into NP-Complete and NP-Hard problems,
>>whereas the worst-case numerical algorithms in common use are N**4.
>>They're both nice dreams for computationalists, though. :)
>>    
>>
>
>Well, dreams are what great accomplishments start as :-).  I think both 
>verifiable numerical computations and smart integration with proof systems 
>could go a long way towards making Axiom not just another entry in the CAS 
>market but a fundamentally new type of software - maybe even a "killer app" 
>in relevant mathematical and scientific areas.
>  
>
Well ... if it's any consolation, the core of what Google does very well 
is a singular value decomposition. Somebody besides the 
military-industrial complex finally got rich with computational linear 
algebra. :) Spreadsheets ... been done. Word processing ... been done. 
Web 2.0 ... being done. Searching, the semantic web ... been done.

How about biotechnology, though?

>Of course, I'm not really qualified to have dreams like this yet :-).  Maybe 
>after a few years of studying up on the issue I'll know why it's not worth 
>doing :-/.
>  
>
Oh, it's worth doing ... my dreams when I got out of grad school (1974) 
were to own a computer capable of algorithmic composition and synthesis 
of music, and to have a computer prove the programs I wrote for a living 
were correct. One out of two ain't bad! :) It's worth doing ... so is 
solving the halting problem. :)

\start
Date: Sat, 24 Sep 2005 00:08:08 -0700
From: Ed Borasky
To: list
Subject: Re: Failure of Axiom? (was: Static versusDynamically typed) )

Bill Page wrote:

>I think William Sitt's quotations are encouraging. Also we
>should not forget the enormous effort that was put into the
>implementation of the current Axiom library itself. This
>library contains over 1,000 domains and categories that interact
>in complex and apparently correct manner. This is a major
>accomplishment and it's all written in SPAD. Although I said
>earlier that Axiom's library covers only a small part of
>mathematics, to be fair I should also point out that in scope,
>if not always in depth, it covers much more mathematics than
>either Maple, Mathematica or MuPad.
>
>So in that respect the Axiom experiment in applying a strongly
>typed programming language in computer algebra has not been
>a failure. But there is the larger sense in which the medical
>idiom: "The operation was a success but the patient died anyway
>... " almost applies to Axiom. I think Axiom is in a critical
>state. As open source software it can survive in this state
>for a long time, but to advance in needs a lot more support.
>It is quite disappointing to me that during that last two years
>of fairly intense effort on our part, Axiom has not been
>adopted by any major university program or research institute
>and we are still struggling to find any kind of substantial
>support. :(
>  
>
Ah, but how many people actually *need* a CAS, as opposed to "enjoy 
working with a CAS and have the money to afford Mathematica?" I don't 
think R has made a serious dent in the profits of the folks who sell 
S-Plus, despite the fact that the two environments are "fraternal 
twins". As I've noted before, I do number crunching for a living. I 
"enjoy working with a CAS and have the money to afford Derive." But if R 
and Perl weren't free, I wouldn't have them available.

Oh yeah ... does Axiom build and execute under CygWin?

\start
Date: Sat, 24 Sep 2005 11:19:24 -0400
From: William Sit
To: Martin Rubey
Subject: Re: Failure of Axiom? (was: Static versusDynamically typed) )

Dear Martin, Bill, Bertfield and *:

Martin Rubey wrote:

> although I know that Axioms approach has *not* failed I wouldn't
> qualify work from 2001 as recent. A lot has changed since then,
> especially regarding MuPad.

Agreed, the word "recent" was an editing omission when I gave the
years instead.  But the point is that with a system as complicated and
specialized as Axiom, there are people who still find it "better" than
the other systems (some perhaps equally complicated and specialized
and some not) for the same projects. So I think for those who are
(were?) willing to spent the effort in learning several CAS (including
Axiom), they found it better. Obviously, people who only casually use
any CAS may find some easier than others for the purpose they have in
mind and that is certainly enough reason for THEM to praise one and
condemn others based on that experience. But for these casual users (I
count myself as only a casual user of Axiom---a reason I only supplied
quotations from others---but a much more heavy user of Mathematica,
and not even a casual user of Maple), their comments should not be
regarded as in depth reviews.

> Again, if I weren't convinced of Axiom, I wouldn't put that much of
> an effort into it. However, A LOT OF WORK HAS TO BE DONE.  You are
> correct. I think Axiom failed commercially because not enough effort
> was put into organizing its users (the Friends of Axiom club never
> got to a critical mass state) and because there are only very few
> research mathematicians (only in the thousands worldwide) and even
> fewer who use CAS as a research tool in the 1990's when Axiom become
> commercialized. Even now, those who use a CAS for teaching and
> occasionally as a symbolic calculator for research far outnumber
> those who regularly uses a CAS as research tool, which in turn far
> outnumber those who develop packages for CAS.  I am not sure if it
> is possible to enlarge the Axiom user base to include the first two
> groups. Efforts have been made by Jenks and others to use Axiom for
> courses (such as linear algebra) but support was not there.

The Axiom community has an opportunity to have a fresh beginning. But if one
looks at the number of "bugs" in IssueTracker, it is clear that the highest
priority would be to fix these first, because these bugs are "unexpected", some
even to the developers. We are at a stage of discovering and identifying these
problems and very far from fixing most of these. Martin has put in a lot of
effort in this respect and I wish I had his skills to track the (algebra)
issues. We are also spending a lot of efforts to keep up with new upgrades in
support systems and operating systems. I think that type of effort would widen
the initial user base but need not necessarily be able to keep them for long
unless the "bugs" are fixed.

Axiom has always been a "learn on your own" system. There is only ONE
book on axiom, where as there are probably hundreds on the 3M's.  But
I don't see any of the former gurus wanting to write similar texts for
the more general audience, and the reason is a "catch 22": Axiom has
never been tried in the classroom (I could be wrong and would be very
happy to hear about counterexamples). So no one has such experience to
write about, and without textbook, no one would want to try.  (I made
a few attempts to teach a course using Axiom, but it did not
materialize because of low expected enrollment: who would want to
learn an "unheard of" CAS when everyone else is using the 3M's?) It
seems such a text need only involve a rudimentary portion of Axiom
commands, say, sufficient for a calculus course (so algebra, plotting,
calculus and maybe some ODEs, especially numerical solvers).  Perhaps
we can make a cooperative effort to write one chapter each. But first,
we should identify the scope of the text, carefully choose examples,
and even exercises, and organize the contents. In such a text, we
should avoid the computer jargons (such as category, domains, strong
types), perhaps only use the "Any" domain, or suppress the Type and
Autoload messages as defaults. The Wiki environment is a perfect
setting for such a cooperative effort, and thanks to the tremendous
dedicated effort by Bill Page, the Axiom community can easily use this
highly interactive web interface.

This effort can be done in parallel (if only we had enough time and manpower)
with efforts to fix the algebra bugs. Kai has done substantial work on GUI. So
by the time the new text gets published, Axiom may be in a form that is usable
in teaching.

The documentation of existing algebra library is, in some sense, of
lower priority (IMHO). By this I mean retroactively filling in the
missing parts in the pamphlet files. It may be done as bugs are fixed,
but a systematic effort would require a lot of people-years
("man-years" is probably an equivalent term!) It is one thing to give
just the syntax for "integrate" and quite another to explain how and
why the results are obtained. Mathematicians with sufficient knowledge
to do the job are top researchers who would be unlikely to spend time
on this (not to mention that there are only a handful of
them). Documentation also requires digging deep into the design
philosophy at the time these packages were developed, for which little
record exists. It belongs to CAS archaeology.

New research areas are probably the easiest to develop as those
developing these presumably can "learn on their own". Surprisingly, I
have developed several packages without getting into the
"bugs". Perhaps the compiler language is more precise and the strong
type enforces correct function calls (satisfying the unstated
assumptions of the calls). I recall vaguely that I did get into design
issues which could have made developing those packages easier, but
there were always ways to "get around" --- certainly I found such
"tricks' very unappealing, but most of the time, after I understood
things better, it was my lack of understanding in the first place that
caused the problems. Someone like Manuel would not have encountered
these problems at all, but then, Manuel was a full time employee on
the project in those days (plus he was extremely smart and fast). I am
sure that any new comer to Axiom as a developer would have to go
through similar pains (unless (s)he is of the same calibre as
Manuel). Only those willing to take the pains get the gains.

Bill Page wrote:
> As open source software it can survive in this state
> for a long time, but to advance in needs a lot more support.
> It is quite disappointing to me that during that last two years
> of fairly intense effort on our part, Axiom has not been
> adopted by any major university program or research institute
> and we are still struggling to find any kind of substantial
> support. :(

Axiom was "abandoned" twice, once by IBM and then by NAG. The second time was
especially devastating in that a working piece of software was taken apart and
some of its foundations removed. So it will take a few years to rebuild (like
New Orleans after Katrina and Rita). Until it can stand on its feet again, I
don't expect it can catch up with the 3M's in popularity. Another blow to Axiom
may be Aldor, which provides a more powerful language, so cutting edge
researchers moved to Aldor. But Aldor, like Axiom, will not enjoy the kind of
popularity as the 3M's, for the same reasons. It is our job to revive Axiom and
build on it, and if Aldor will never be open sourced, to compete with Aldor. So
far, even though Aldor provides a better language in terms of convenience of
programming, I am not yet convinced it is a more powerful or even more
expressive language (but of course, every computer is just as powerful as a
Turing machine ... and I am not saying convenience does not count).

But I should follow Bertfried Fauser: 

> stop typing in philosophy `nonsense` and try to do some
> more science and AXIOM programming... ;-)

which, for now, is finishing a joint paper on Enumeration of Rota-Baxter Words
with Li Guo from Rutgers University at Newark. The long-term plan is to develop
a more intrinsic algebra hierarchy in Axiom using operator algebras, which, as
vector spaces, have canonical basis related to Rota-Baxter Algebras.

\start
Date: Sat, 24 Sep 2005 12:07:20 -0400
From: William Sit
To: Bill Page
Subject: re: Types as values, and Re: Static versus Dynamically typed(was:Philosophy... )

Bill Page wrote:
> 
> On September 23, 2005 7:36 AM William Sit wrote:
> > From www.aldor.org:
> > > Types and functions are first class entities allowing them to be
> > > constructed and manipulated within Aldor programs just like any
> > > other value.
> > >
> > Can some Aldor expert expand on this? For example, can functions be
> > created, modified, and compiled and called all at run time? (People
> > used to do code modification on assembly languages and may still do,
> > but the practice is I think no longer promoted, if not outright banned.)
> >
> 
> People certainly still do this, for example in lisp, Python and
> Haskell.

Sure, hackers and virus authors, too. But I am asking the question on
an algebra code level.
 
> I can't speak about Aldor specifically (yet) but I am sure that
> it is possible.

Examples?

> In Axiom it is possible. See for example section 9.50 MakeFunction
> in the Axiom book. There are numerous other examples of this in
> Axiom.

Thanks, but MakeFunction only turns an expression into a function by
enabling evaluation. So in this sense, sure a new function is created,
much like defining a new function in the interpreter. What I meant
(sorry I wasn't clear) was to take an existing library function, say a
simple one like "inc" which adds 1 to the argument, modify the code
and create FROM THAT CODE a new function "incBy2" (or for that matter,
use the same function name "inc") that adds 2 to its argument (note,
not rewriting from scratch "incBy2", and not implementing "incBy2"
USING "inc" twice, but by modifying existing code, changing where "1"
is, to "2" in the code itself), have that function compiled, and
executed, all without leaving the interpreter or Axiom (or,
Aldor). The crucial thing I am asking is "code-modification" because
that is the real meaning, as I understand it, of "constructed and
manipulated [Types and functions] ... just like any other value".
Similarly, the "curry" type functions in Axiom do not "modify" code
and is a variant of MakeFunction. Can Aldor manipulate types and
functions much like Lisp (or Scheme) does? In principle, this is easy,
if the code is treated as a string, and if the format structure and
language syntax are known; so the question is not whether this is
"possible", but whether this is "available" as a feature of the Aldor
language, that the code string can be returned, manipulated, edited,
and sent back to the compiler to get a new or modified function. In
Axiom, I would imagine one has to go the relevant NRLIB, look at the
code.lsp, and create a new version of it, create the corresponding .o
file to make this "possible". I don't consider that as "available".

Thanks, Bill, for your input. (I see you are experimenting with Types as
values).

\start
Date: Sat, 24 Sep 2005 23:33:03 -0400
From: Tim Daly
To: Andrea Rizzi
Subject: KFormula and Axiom (resend)

Andrea,

I'm Tim Daly, lead developer on Axiom, a free, open source computer
algebra system.

I've recently discovered KFormula which I understand is a part of 
KOffice. I'm interested in the question of using KFormula as a front
end to our computer algebra system. Is there an API document?

Tim Daly

\start
Date: Sun, 25 Sep 2005 23:21:19 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: Units and Dimensions update

The digging continues, and to my surprise there is a considerable body
of research on these issues.  Just for openers, I've stumbled across
several lisp implementations of unit/dimensional concepts, a Phd thesis
on incorporating units/dimensions into programming, and a paper about
an attempt to teach the formal Z language about units!  Yikes.  Quite a
bit of homework to do, so I may fall off the radar screen a bit while I
try to adsorb at least some of this.  (Plus, my home internet will be
off for quite a while, so that won't help either.)  If nothing else,
I'll try to leave a good bibtex file behind to help someone more
competent than myself.  Never assume anything will be simple!

Dr. Sit has been very helpful with his comments, and I wish to thank
him for his generosity.  Definite progress has been made but clearly I
need to familiarize myself with the work out there on this subject
before I will be competent to make further revisions.

In the interests of full disclosure, I should point out the email
address "smustudent1" is actually no longer correct - I haven't been a
student at SMU for several years.  The choice was a rather unfortunate
one - I assumed the Yahoo address would not live beyond my
undergraduate years.  Oops.  I actually have a day job that has nothing
to do with CASs, so unlike most folks here I'm a hobbyist rather than
an academic.  I do have a B.S. in Physics, a B.A. in Mathematics, and a
Masters in Materials Science, but I'm not currently active in academia.
 While it would be fun to get into this from an academic standpoint I
doubt the funding would ever be available, or the interest from a
research standpoint.

Anyway, just wanted to let y'all know the effort continues!

\start
Date: Mon, 26 Sep 2005 13:30:36 +0200
From: Ralf Hemmecke
To: William Sit
Subject: re: Types as values, and Re: Static versus Dynamically typed(was:Philosophy... )

>>>>Types and functions are first class entities allowing them to be
>>>>constructed and manipulated within Aldor programs just like any
>>>>other value.

Interesting. If that were so easy, it would be possible to ask a type 
for the functions it implements.

Aldor allows something like

#include "aldor"
#include "aldorio"
Dom: with {
   foo: % -> Boolean;
} == add {
   foo(x: %): Boolean == true;
}

import from Dom;
if Dom has with {foo: % -> Boolean} then {
	stdout << "foo is there" << newline;
} else {
	stdout << "foo is missing" << newline;
}

However, I cannot, for example, write a function that returns a list of 
names of functions implemented in Dom. (That is the current knowledge I 
have.) And, of course, I see no way of morphing the result of "foo" to 
"false" without writing a new function. I am not aware of
a language construct that invokes the compiler during the runtime of a 
program. (The compiler might not even present on the target machine.)

\start
Date: Mon, 26 Sep 2005 16:30:49 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: types as values

> But having defined the function tt2 in Aldor like this:
> 
> #include "axiom.as";
> testtype2(): with {
>     tt2: (Integer) -> Type;
> } == add {
>     tt2(x:Integer):Type == {
>       x=0 => Integer;
>       Float;
>       }
>     }
> 
> How can I use it in Axiom in a useful manner?

tt2 returns a domain of type "Type". So in order to be useful it would 
be necessary to know which functions it exports. However, one cannot 
look into Type. Your function tt2 would perhaps be more interesting if 
its return type were a category with some neat functionality. For 
example, replace Type above by ArithmeticType. Now, at least you know 
what functions you could call on values of type tt2(0). Though you would 
probably still need functions to coerce a known value into tt2(0) and back.

> For example,
> if I write:
> 
>   (1) -> n:tt2(0)
> 
> Axiom says:
> 
>   "Category, domain or package constructor tt2 is not available"
> 
> which is true of course because it is 'testtype2' which is
> the name of a **domain**. But even if I this:
> 
>  (2) -> intx := tt2(0)
> 
>    (2)  Integer
>                             Type: Type
>  (3) -> a:intx
> 
>    intx is not a valid type.

I have the impression that the result of (2) is misleading. Axiom prints 
"Integer" and its type is correctly "Type". This is, of course, 
different from the real Integer domain whose type is

Integer: Join(IntegerNumberSystem, ConvertibleTo String, OpenMath) with
     random   : % -> %
       ++ random(n) returns a random integer from 0 to \spad{n-1}.
     canonical
       ++ mathematical equality is data structure equality.
     canonicalsClosed
       ++ two positives multiply to give positive.
     noetherian
       ++ ascending chain condition on ideals.
     infinite
       ++ nextItem never returns "failed".

The "Integer" from (2) is the same as MyInt in

MyInt: with == Integer;

it has no exports. I am not really sure whether

MyInt: Type == Integer;

should be allowed to compile. Who could tell just from the left side of 
the == sign whether MyInt is a domain or a category?

\start
Date: Mon, 26 Sep 2005 10:54:46 -0400
From: William Sit
To: Ralf Hemmecke
Subject: re: Types as values, and Re: Static versusDynamically typed(was:Philosophy... )

Ralf Hemmecke wrote:
> [from www.aldor.org:]
> >>>>Types and functions are first class entities allowing them to be
> >>>>constructed and manipulated within Aldor programs just like any
> >>>>other value.
> 
> Interesting. If that were so easy, it would be possible to ask a type
> for the functions it implements.

Exactly. It has been a long standing (but lost) request (I believe from me) that
Axiom constructors (that include category, domain and packages, but not the
developers :-)) allow query of their arguments. It is useful, for example, to be
able to distinguish whether a field is a quotient field of some integral domain
or just a field to make codes more efficient. The request was not acted upon
because at the time (around 1990 +/- 3 years?), effort was concentrated on
developing the Aldor (A#) compiler, which promised to solve such problems.

> Aldor allows something like
> 
> #include "aldor"
> #include "aldorio"
> Dom: with {
>    foo: % -> Boolean;
> } == add {
>    foo(x: %): Boolean == true;
> }
> 
> import from Dom;
> if Dom has with {foo: % -> Boolean} then {
>         stdout << "foo is there" << newline;
> } else {
>         stdout << "foo is missing" << newline;
> }
> 
> However, I cannot, for example, write a function that returns a list of
> names of functions implemented in Dom. (That is the current knowledge I
> have.) 

In other words, if I understand the example, you can't list unless you already
know?

Listing functions in a domain is not a simple question in
Axiom. Functions can be inherited from parent constructors or exported
as new. It also depends on in what form you want the list. Surely, by
doing a ")show Dom" (this is in the interpreter: I am not aware of any
compiler equivalent) you get that list. So are you simply asking to be
able to assign the output of ")show Dom" to a string variable? Tim may
be able to provide such a general assignment construct?

> And, of course, I see no way of morphing the result of "foo" to
> "false" without writing a new function. 

That is what I was asking: code modification. Like you, I also interpret "first
class object as data" that way (but that need not be the "official"
interpretation).

> I am not aware of
> a language construct that invokes the compiler during the runtime of a
> program. (The compiler might not even present on the target machine.)
> 

Thanks for this info. The interpreter of Axiom can invoke the compiler
of course. But the above meant calling the compiler from within a
compiled function at run time. Any comments from others?

\start
Date: Mon, 26 Sep 2005 10:35:44 -0400
From: William Sit
To: Cliff Yapp
Subject: Re: Units and Dimensions update

Dear Clifford:

C Y wrote:
> 
> The digging continues, and to my surprise there is a considerable body
> of research on these issues.  Just for openers, I've stumbled across
> several lisp implementations of unit/dimensional concepts, a Phd thesis
> on incorporating units/dimensions into programming, and a paper about
> an attempt to teach the formal Z language about units!  Yikes.  

That's in fact a very good development. After all, one always wants to
built upon prior art. Just even reading the first few paragraphs of
the thesis already points out some needed modification to the proposed
design: I have assumed that mostly unit conversions are proportional
(I used two fields that are "factors") so that linear conversion like
centigrade to fahrenheit is not immediately handled without a
translation first. And, of course, there are non-linearly scaled units
like decibels, or the Richter scale of earthquakes or the categories
of hurricanes.

> Quite a
> bit of homework to do, so I may fall off the radar screen a bit while I
> try to adsorb at least some of this.  (Plus, my home internet will be
> off for quite a while, so that won't help either.)  If nothing else,
> I'll try to leave a good bibtex file behind to help someone more
> competent than myself.  Never assume anything will be simple!

That's Tim's motto. Quietness before a storm?
 
> Dr. Sit has been very helpful with his comments, and I wish to thank
> him for his generosity.  

You are welcome, but please just call me "William". I wish to also thank you
since I have learnt quite a bit myself. 

> Definite progress has been made but clearly I
> need to familiarize myself with the work out there on this subject
> before I will be competent to make further revisions.

This is what research is all about and in my opinion, you are very
qualified for this project and your expertise will continue to grow.

Despite having taught unit conversion to some liberal arts students
(you can't expect too much from a text like those) I am also just
beginning to learn how to teach units conversion and to apply that
concept to teaching percentage problems---requiring pecentages carry
their reference values as units. So my point is, one only becomes
competent AFTERwards. It's so much easier (to me) to understand and do
the exercises in percentages, where the reference values keep
changing, which now all becomes unit-conversion problems! If I
remember, I'll tell you how this new method fairs after the semester
is over.

> In the interests of full disclosure, I should point out the email
> address "smustudent1" is actually no longer correct - I haven't been a
> student at SMU for several years.  The choice was a rather unfortunate
> one - I assumed the Yahoo address would not live beyond my
> undergraduate years.  Oops.  

Please, we are all "Friends of Axiom" (a defunct club that I think participants
from this discussion forum really belong. I would rather not call myself a
developer, since I have not written algebra code for quite a while and have
fallen behind). In this forum, we do not wear our hard hats. So everyone is
welcome as long as they are interested in Axiom (including critizing Axiom).

> I actually have a day job that has nothing
> to do with CASs, so unlike most folks here I'm a hobbyist rather than
> an academic.  I do have a B.S. in Physics, a B.A. in Mathematics, and a
> Masters in Materials Science, but I'm not currently active in academia.

Your background seems to have quite a bit in common with other active
developers.

>  While it would be fun to get into this from an academic standpoint I
> doubt the funding would ever be available, or the interest from a
> research standpoint.

Since you have a graduate degree and two undergraduate ones, you are an
academic. Like it or not :-). In the academic world, a lot of research is done
without funding.
 
> Anyway, just wanted to let y'all know the effort continues!

\start
Date: Mon, 26 Sep 2005 07:58:12 -0700 (PDT)
From: Cliff Yapp
To: list
Subject: BibTeX?

Perhaps this is already addressed somewhere, but is there a convention
about BibTeX files and Axiom pamphlet files?  I see in the archives
http://lists.gnu.org/archive/html/axiom-developer/2004-05/msg00041.html
that Tim has some kind of axiom.bib.pamphlet file - did this ever get
posted?  If not, I would appreciate it being added :-).  I also suggest
this might be a good time to set up some kind of system for this sort
of thing - if we want to do one universal bib file (good for avoiding
duplicates) we might want to establish some organization - for example,
I doubt any other part of Axiom would need to reference a discussion on
the meaning of the word "dimension," but it is a relevant reference to
the units/dimensions pamphlet.  If the bib file gets too big it will be
hard to find what one wants without some good tools/conventions - is
there some good solution for managing this type of thing?

\start
Date: Mon, 26 Sep 2005 17:39:37 +0200
From: Ralf Hemmecke
To: William Sit
Subject: re: Types as values, and Re: Static versusDynamically typed(was:Philosophy... )

William Sit wrote:
> Ralf Hemmecke wrote:
> 
>>[from www.aldor.org:]
>>
>>>>>>Types and functions are first class entities allowing them to be
>>>>>>constructed and manipulated within Aldor programs just like any
>>>>>>other value.
>>
>>Interesting. If that were so easy, it would be possible to ask a type
>>for the functions it implements.
 
> Exactly. It has been a long standing (but lost) request (I believe
> from me) that Axiom constructors (that include category, domain and
> packages, but not the developers :-)) allow query of their
> arguments. It is useful, for example, to be able to distinguish
> whether a field is a quotient field of some integral domain or just
> a field to make codes more efficient. The request was not acted upon
> because at the time (around 1990 +/- 3 years?), effort was
> concentrated on developing the Aldor (A#) compiler, which promised
> to solve such problems.

I am not so sure whether I would really need that kind of reflection. In 
some cases it would be useful, for example, for the implementation of 
something like JUnit for Aldor. However, I somehow do not think that 
being able to query the structure of a type is a good idea. You gave a 
good reason, but isn't there a better way to achieve efficiency?

>>Aldor allows something like
>>
>>#include "aldor"
>>#include "aldorio"
>>Dom: with {
>>   foo: % -> Boolean;
>>} == add {
>>   foo(x: %): Boolean == true;
>>}
>>
>>import from Dom;
>>if Dom has with {foo: % -> Boolean} then {
>>        stdout << "foo is there" << newline;
>>} else {
>>        stdout << "foo is missing" << newline;
>>}
>>
>>However, I cannot, for example, write a function that returns a list of
>>names of functions implemented in Dom. (That is the current knowledge I
>>have.) 

> In other words, if I understand the example, you can't list unless
> you already know?

Exactly. Well, returning the list of function names would certainly be 
do-able, but the next thing a programmer would ask for is: How can I 
call the function with name "foo"? What is the input type? ...

> Listing functions in a domain is not a simple question in
> Axiom. Functions can be inherited from parent constructors or
> exported as new. It also depends on in what form you want the
> list. Surely, by doing a ")show Dom" (this is in the interpreter: I
> am not aware of any compiler equivalent) you get that list.

Same in "aldor -gloop". By saying then

#include "aldor"
#include "aldorinterp"
Integer

one gets

%1 >> #include "aldor"
                                            Comp: 110 msec, Interp: 0 msec
%2 >> #include "aldorinterp"
                                            Comp: 30 msec, Interp: 0 msec
%3 >> Integer
   () @ Join(
PrimitiveType with
         coerce: BInt -> %
         coerce: % -> BInt
     ==  add ()
,
IntegerType with export to IntegerSegment(%)
     ==  add ()
)
                                            Comp: 10 msec, Interp: 0 msec

But again, that is the interpreter. I cannot do anything useful with 
that output in a stand-alone program.

>>And, of course, I see no way of morphing the result of "foo" to
>>"false" without writing a new function. 

> That is what I was asking: code modification. Like you, I also
> interpret "first class object as data" that way (but that need not
> be the "official" interpretation).

I think I am happy that the Aldor code itself is not modifyable (as in 
Maple).

\start
Date: Mon, 26 Sep 2005 12:21:37 -0400
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: types as values

If memory serves me Aldor made Types be first-class objects.
You could create, assign, and pass Type objects to functions.

\start
Date: Mon, 26 Sep 2005 13:07:02 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: BibTeX?

re: bibtex file.

This file has that intended purpose:

src/doc/axiom.bib.pamphlet

\start
Date: Mon, 26 Sep 2005 14:00:42 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: BibTeX?

On September 26, 2005 10:58 AM C Y wrote:
> ...
> If the bib file gets too big it will be hard to find what
> one wants without some good tools/conventions - is there
> some good solution for managing this type of thing?

There is an Axiom bibliograph here:

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

that can be searched and downloaded in bibtex format.

\start
Date: Mon, 26 Sep 2005 13:52:59 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: BibTeX?

i wouldn't expect anyone to find this in the source tree as i've
never documented the process for creating pamphlets in axiom (although
i will, at least according to my intention).

actually src/doc/axiom.bib.pamphlet is intended to have all of the
bibtex references so the pamphlet files only have to look at one
place for references. except for an example case i have not yet
spread the automation for bibtex references. there is a bibliography
section in every pamphlet file.

\start
Date: Mon, 26 Sep 2005 10:49:59 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: BibTeX?

Hehe - oops.  Note to self - do find on source tree before asking next
time.

OK, looking at this, I see it is intended to enable linking to the
pamphlet files themselves.  For external references, to books/journal
articles/what have you/, should the pamphlet file maintain its own bib
file?

--- Tim Daly wrote:

> re: bibtex file.
> 
> This file has that intended purpose:
> 
> src/doc/axiom.bib.pamphlet

\start
Date: Mon, 26 Sep 2005 13:57:01 -0400
From: William Sit
To: Ralf Hemmecke
Subject: re: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... )

Ralf Hemmecke wrote:
> 
> >William Sit wrote:
> >
> >[from www.aldor.org:]
> >
> >Types and functions are first class entities allowing them to be
> >constructed and manipulated within Aldor programs just like any
> >other value.
> 
> Interesting. If that were so easy, it would be possible to ask a type
> for the functions it implements.
 
> > Exactly. It has been a long standing (but lost) request (I believe
> > from me) that Axiom constructors (that include category, domain
> > and packages, but not the developers :-)) allow query of their
> > arguments. It is useful, for example, to be able to distinguish
> > whether a field is a quotient field of some integral domain or
> > just a field to make codes more efficient. The request was not
> > acted upon because at the time (around 1990 +/- 3 years?), effort
> > was concentrated on developing the Aldor (A#) compiler, which
> > promised to solve such problems.
 
> I am not so sure whether I would really need that kind of reflection. In
> some cases it would be useful, for example, for the implementation of
> something like JUnit for Aldor. However, I somehow do not think that
> being able to query the structure of a type is a good idea. You gave a
> good reason, but isn't there a better way to achieve efficiency?

Yes, but another reason, in the above example of field, is in allowing
generalizations to work, not just efficiency due to data
representation (reducing computation in the field to that in the
underlying integral domain, as in Grobner bases computation). For
example, if I have a constructor that requires an integral domain R as
a parameter, and I constructed in the package the quotient field of R,
as you may suggest as an explicit way to achieve efficiency, then the
package will FAIL if R is actually a field (you can consider this as a
bug if you like), even though a field IS an integral domain,
mathematically. If we COULD ask whether R is a quotient field (not
just a field) and if in case of affirmative answer also find out the
underlying integral domain S of R = FRAC S, we would be able to
replace R by S for the package. Of course, you may say a user should
then use S in the first place. But we should not expect that, which
limits the power of the system, and we are aiming for automation: the
requested integral domain R could be just something returned during
the course of a computation. So without such a feature, I doubt types
and domains can be considered as "first class" objects.

> >>Aldor allows something like
> >>
> >>#include "aldor"
> >>#include "aldorio"
> >>Dom: with {
> >>   foo: % -> Boolean;
> >>} == add {
> >>   foo(x: %): Boolean == true;
> >>}
> >>
> >>import from Dom;
> >>if Dom has with {foo: % -> Boolean} then {
> >>        stdout << "foo is there" << newline;
> >>} else {
> >>        stdout << "foo is missing" << newline;
> >>}
> >>
> >>However, I cannot, for example, write a function that returns a list of
> >>names of functions implemented in Dom. (That is the current knowledge I
> >>have.)
 
> > In other words, if I understand the example, you can't list unless
> > you already know?
 
> Exactly. Well, returning the list of function names would certainly be
> do-able, but the next thing a programmer would ask for is: How can I
> call the function with name "foo"? What is the input type? ...

Yes, this would be recursive, and certainly relates to the Crystal vision of
Tim.

[snipped]
 
> >>And, of course, I see no way of morphing the result of "foo" to
> >>"false" without writing a new function.

The "way" to do that would be to pass "true" or "false" as parameters to the
package Dom to avoid run-time code-modification. However, this is not "totally"
dynamic (modification is anticipated at compile time):

Dom(b:Boolean): with           {
   foo: % -> Boolean;              } 
  == add                       {
   foo(x: %): Boolean == b;        }

> > That is what I was asking: code modification. Like you, I also
> > interpret "first class object as data" that way (but that need not
> > be the "official" interpretation).
 
> I think I am happy that the Aldor code itself is not modifyable (as
> in Maple).  This is a balance (trade-off?) between power and
> responsibility. Don't most programmers want power and not
> responsibilities? :-) Much code-modification (at least for higher
> level languages) is obsoleted (that is probably a good thing) due to
> parametric polymorphism, but I am not ruling out applications (other
> than hacking) that require that type of programming power. Note that
> code-modification is "totally" dynamic since the modification is not
> anticipated. It is not reasonable to expect programmers to
> anticipate all possible modifications of code, and thus, parametric
> polymorphism is not sufficient, or equivalent, and not as powerful.

\start
Date: Mon, 26 Sep 2005 11:29:38 -0700 (PDT)
From: Cliff Yapp
To: Bill Page
Subject: RE: BibTeX?

--- Bill Page wrote:

> On September 26, 2005 10:58 AM C Y wrote:
> > ...
> > If the bib file gets too big it will be hard to find what
> > one wants without some good tools/conventions - is there
> > some good solution for managing this type of thing?
> 
> There is an Axiom bibliograph here:
> 
> http://page.axiom-developer.org/zope/Plone/refs
> 
> that can be searched and downloaded in bibtex format.

Nice!  I don't suppose we could make that a front end to the
src/doc/axiom.bib.pamphlet file when it becomes universal?

Cheers,
CY

P.S. - any opinions about shifting www.axiom-developer.org to point to
the Plone work by default?  Or is it a concern that that would result
in less activity on the wiki?

\start
Date: Mon, 26 Sep 2005 11:27:19 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: BibTeX?

--- Tim Daly wrote:

> i wouldn't expect anyone to find this in the source tree as i've
> never documented the process for creating pamphlets in axiom
> (although i will, at least according to my intention).
> 
> actually src/doc/axiom.bib.pamphlet is intended to have all of the
> bibtex references so the pamphlet files only have to look at one
> place for references. except for an example case i have not yet
> spread the automation for bibtex references. there is a bibliography
> section in every pamphlet file.

Right, but isn't the bibliography section in the pamphlet file
incompatible with bibtex?  Certainly the formatting is different. 
Doesn't a .bib file need to be separate?

If we want axoim.bib.pamphlet to be universal that will take some
management - we might wind up referencing a large subset of all
mathematical and scientific papers someday! :-)  (Well, one can hope
anyway...)

\start
Date: Mon, 26 Sep 2005 14:32:03 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: BibTeX?

yes, the bibliography section is intended to be replaced by bibtex
on a universal basis. it's on my todo list.

\start
Date: Mon, 26 Sep 2005 21:40:43 +0100
From: Peter Broadbery
To: list
Subject: Re: types as values, and type internals

As usual, should have done a bit more testing; use the attached
domain2.as - it makes map work a bit better.

a := map(theIntegerType(), theIntegerType())
lookup(theIntegerType(), "-", a);

works, but axiom will not display the object returned by lookup - it's
expecting an SExpression (ie a list of lispy values), and we're feeding
it a more complex structure.

Ho hum,

Peter.

-- 
Peter Broadbery

--=-KMso3GtvOyV7AW5zCnXK

I2luY2x1ZGUgImF4aW9tLmFzIgoKQWxkb3JEb21haW46IEJhc2ljVHlwZSB3aXRoIHsKIAltYWtl
OiAoVDogQmFzaWNUeXBlKSAtPiAlOwoKCXRoZUludGVnZXJUeXBlOiAoKSAtPiAlOwoJbWFwOiAo
JSwgJSkgLT4gJTsKCWludGVnZXJNb2Q6IFBvc2l0aXZlSW50ZWdlciAtPiAlOwoJCgljb2VyY2U6
ICUgLT4gT3V0cHV0Rm9ybTsKCgluYW1lOiAlIC0+IFNFeHByZXNzaW9uOwoKCWxvb2t1cDogKCUs
IFN0cmluZywgJSkgLT4gU0V4cHJlc3Npb247CgoJaGFzaENvZGU6ICUgLT4gSW50ZWdlcjsKCn0g
PT0gYWRkIHsKCWltcG9ydCB7CgkJQk9PVF86XzpETmFtZVRvU0V4cHI6IFNFeHByZXNzaW9uIC0+
IFNFeHByZXNzaW9uOwoJCUJPT1RfOl86aGFzaFN0cmluZzogU0V4cHJlc3Npb24gLT4gU0V4cHJl
c3Npb247Cgl9IGZyb20gRm9yZWlnbiBMaXNwOwoJCglSZXAgID09PiBUeXBlOwoJUmVwMiA9PT4g
UmVjb3JkKHY6IFJlY29yZChkb21UeXBlOiBTRXhwcmVzc2lvbiAtPiBTRXhwcmVzc2lvbiwgCgkJ
CQkgIGRvbU5hbWU6IFNFeHByZXNzaW9uIC0+IFNFeHByZXNzaW9uLAoJCQkJICBub3RVc2VkOiBT
RXhwcmVzc2lvbiAtPiBTRXhwcmVzc2lvbiwKCQkJCSAgbG9va3VwOiAgKFNFeHByZXNzaW9uLCBT
RXhwcmVzc2lvbiwgU0V4cHJlc3Npb24sIAoJCQkJCSAgICBTRXhwcmVzc2lvbiwgU0V4cHJlc3Np
b24sIFNFeHByZXNzaW9uLAoJCQkJCSAgICBTRXhwcmVzc2lvbikgLT4gU0V4cHJlc3Npb24sCgkJ
CQkgIGhhc2hDb2RlOiBTRXhwcmVzc2lvbiAtPiBTRXhwcmVzc2lvbiwKCQkJCSAgdW5rbm93bjog
U0V4cHJlc3Npb24gLT4gU0V4cHJlc3Npb24pLAoJCQlvOiBTRXhwcmVzc2lvbik7CgkKCWltcG9y
dCBmcm9tIFJlcDI7CgoJbWFrZShUOiBCYXNpY1R5cGUpOiAlID09IHBlciBUOwoJdGhlSW50ZWdl
clR5cGUoKTogJSA9PSBwZXIgSW50ZWdlcjsKCWludGVnZXJNb2QocDogUG9zaXRpdmVJbnRlZ2Vy
KTogJSA9PSBwZXIoSW50ZWdlck1vZCBwKTsKCgltYXAoYXJnOiAlLCByZXQ6ICUpOiAlID09IHsK
CQlwZXIoIChyZXAgYXJnKSAtPiAocmVwIHJldCkpOwoJfQoKCgkoYTogJSkgPSAoYjogJSk6IEJv
b2xlYW4gPT0gewoJCWltcG9ydCBmcm9tIEludGVnZXI7CgkJaGFzaENvZGUoYSkgPSBoYXNoQ29k
ZShiKQoJfQoKCgljb2VyY2UodDogJSk6IE91dHB1dEZvcm0gPT0gewoJCWltcG9ydCBmcm9tIFN0
cmluZzsKCQkiPFNvbWVUeXBlPiI6Ok91dHB1dEZvcm0KCX0KCgluYW1lKHQ6ICUpOiBTRXhwcmVz
c2lvbiA9PSB7CgkJZG9tIDo9IHQgcHJldGVuZCBSZXAyOwoJCWF4aW9tTmFtZSgoZG9tLnYuZG9t
TmFtZSkoZG9tLm8pKQoJfQoKCS0tIG5iOiBjZi4gaW50ZXJvcC5ib290LCBiYXNpY0xvb2t1cAoJ
bG9va3VwKHQ6ICUsIG5hbWU6IFN0cmluZywgdHlwZTogJSk6IFNFeHByZXNzaW9uID09IHsKCQkt
LSBsb29rdXAgdGFrZXMgdGhlIGZvbGxvd2luZyBhcmd1bWVudHM6CgkJLS0gZG9tYWluIHJlcCwg
ZG9tYWluLCBvcGVyYXRpb24sIGNvbnNwYWlyLCBmbGFnLCBsb29rdXBGbgoJCWltcG9ydCBmcm9t
IExpc3QgU0V4cHJlc3Npb247CgkJZG9tIDo9IHQgcHJldGVuZCBSZXAyOwoJCWJveDogU0V4cHJl
c3Npb24gOj0gY29udmVydCBbY29udmVydCAiIl07CgkJbG9va3VwRm4gOj0gIGRvbS52Lmxvb2t1
cDsKCQluaWwgOj0gY29udmVydCBbXTsKCQlsb29rdXBGbihkb20ubywgCgkJCSBkb20gcHJldGVu
ZCBTRXhwcmVzc2lvbiwgCgkJCSBoYXNoU3RyaW5nKGNvbnZlcnQgbmFtZSksIAoJCQkgY29udmVy
dCBoYXNoQ29kZSh0eXBlKSwKCQkJIGJveCwKCQkJIG5pbCwgbG9va3VwRm4gcHJldGVuZCBTRXhw
cmVzc2lvbik7Cgl9CgoJaGFzaENvZGUodDogJSk6IEludGVnZXIgPT0gewoJCWRvbSA6PSB0IHBy
ZXRlbmQgUmVwMjsKCQlpbnRlZ2VyKChkb20udi5oYXNoQ29kZSkoZG9tLm8pKQoJfQoKCWxvY2Fs
IGF4aW9tTmFtZShzOiBTRXhwcmVzc2lvbik6IFNFeHByZXNzaW9uID09IHsKCQlCT09UXzpfOkRO
YW1lVG9TRXhwcihzKTsKCX0KCglsb2NhbCBoYXNoU3RyaW5nKHM6IFNFeHByZXNzaW9uKTogU0V4
cHJlc3Npb24gPT0gewoJCUJPT1RfOl86aGFzaFN0cmluZyhzKTsKCX0KfQo

\start
Date: Mon, 26 Sep 2005 23:42:58 +0200
From: Jens Axel Segaard
To: list
Subject: Re: Units and Dimensions update

C Y wrote:
> The digging continues, and to my surprise there is a considerable body
> of research on these issues.  Just for openers, I've stumbled across
> several lisp implementations of unit/dimensional concepts, a Phd thesis
> on incorporating units/dimensions into programming, and a paper about
> an attempt to teach the formal Z language about units!  Yikes.  Quite a
> bit of homework to do, so I may fall off the radar screen a bit while I
> try to adsorb at least some of this.  (Plus, my home internet will be
> off for quite a while, so that won't help either.)  If nothing else,
> I'll try to leave a good bibtex file behind to help someone more
> competent than myself.  Never assume anything will be simple!

Just in case you haven't come across it, the language Frink has
focused on units and conversions between units:

     <http://futureboy.homeip.net/frinkdocs/>

The documentation is quite humourous and worth a read.

The language was presented at the Lightweight Languages 4
conference at MIT and a video from that presentation is available
along with the slides at:

     <http://futureboy.homeip.net/frinkdocs/LL4.html>

\start
Date: Tue, 27 Sep 2005 01:18:09 +0100
From: Peter Broadbery
To: list
Subject: [Fwd: Re: types as values, and type internals

Didn't check the To: list - here's a dose of axiom internals fun..

On Mon, 2005-09-26 at 12:21 -0400, root wrote:
> If memory serves me Aldor made Types be first-class objects.
> You could create, assign, and pass Type objects to functions.
> 
> t
> 
> 


Yep; they can be passed around as normal.

As people have discovered, you wind up confusing the interpreter when
used directly.  

You can still do some useful things with them by disguising the fact
that they are domains, so in aldor have a type

AldorDomain: with {
 	make: (T: BasicType) -> %
} == add {
	Rep ==> T;

	make(T: BasicType): % == per T;
}

and your aldor programs can return this to axiom.

Then make sure the interpreter can only see it.

Of course, it isn't really that useful as it is - there are no
operations on domains that are documented in aldor, so for example you
can't say 
	"if T = Integer then ..."
or
	"findOperation(T, add, (T, T) -> T)"

The second is handy if you want to write a specialised interpreter, by
the way.  In any case, you can write a domain like domain.as (see
below).  All it does is makes sure that axiom sees an object, while
aldor has a type to play with.  It can be extended to "know" about any
number of domains.

Even with these limitations, types and constructors as first class
objects are pretty powerful.  You can build domains on the fly,
construct functions, etc. To go further, you need a bit of reflection
(cf the java lang.reflect stuff for where this is going). People not
interested in axiom internals should switch off here.

Of course, the axiom interpreter must be able to do the "findOperation"
thing, and here we need to know how axiom (and aldor) represent domains.
This is where the less brave stop reading, and I should stop writing.

>From memory, and looking at interop.boot, we find that a domain is a
cons pair of two elements.  The first is a vector of functions (eg.
$oldAxiomDomainDispatch), and the second is used as an argument to
functions within the vector. 

The functions do the following:
1)	return the name of the domain, as a null terminated string
2)	unknown
3)	lookup an export by hashcode
4)	return the domain's hashcode
5) 	unknown (inheritance related).


Categories are similar, but have a different vector of functions.

Next step is to abuse this information and extend our aldor domain above
to include these operations.  Here aldor's "pretend" keyword and a
strong stomach are useful.

You wind up with something like domain2.as, below.

I've tested this as far as:
	lookup(theIntegerType(), "1", theIntegerType())
which extracts 1 from the Integer domain.

NB: This is very crash prone, and don't try to print the name of a
mapping - it won't work - not sure why.

There are other things that could be held in a domain object - eg a list
of exports, or a list of categories.  Adding this would be a bit of a
project though.

Anyway, hope this is interesting...


I2luY2x1ZGUgImF4aW9tLmFzIgoKQWxkb3JEb21haW46IEJhc2ljVHlwZSB3aXRoIHsKIAltYWtl
OiAoVDogQmFzaWNUeXBlKSAtPiAlOwoKCXRoZUludGVnZXJUeXBlOiAoKSAtPiAlOwoJbWFwOiAo
VHVwbGUgJSwgVHVwbGUgJSkgLT4gJTsKCQoJY29lcmNlOiAlIC0+IE91dHB1dEZvcm07CgoJbmFt
ZTogJSAtPiBTdHJpbmc7CgloYXNoQ29kZTogJSAtPiBJbnRlZ2VyOwp9ID09IGFkZCB7CglSZXAg
ID09PiBUeXBlOwoJUmVwMiA9PT4gUmVjb3JkKHY6IFJlY29yZChkb21UeXBlOiBTRXhwcmVzc2lv
biAtPiBTRXhwcmVzc2lvbiwgCgkJCQkgIGRvbU5hbWU6IFNFeHByZXNzaW9uIC0+IFNFeHByZXNz
aW9uLAoJCQkJICBub3RVc2VkOiBTRXhwcmVzc2lvbiAtPiBTRXhwcmVzc2lvbiwKCQkJCSAgbG9v
a3VwOiAgU0V4cHJlc3Npb24gLT4gU0V4cHJlc3Npb24sCgkJCQkgIGhhc2hDb2RlOiBTRXhwcmVz
c2lvbiAtPiBTRXhwcmVzc2lvbiwKCQkJCSAgdW5rbm93bjogU0V4cHJlc3Npb24gLT4gU0V4cHJl
c3Npb24pLAoJCQlvOiBTRXhwcmVzc2lvbik7CgoJaW1wb3J0IGZyb20gUmVwMjsKCgltYWtlKFQ6
IEJhc2ljVHlwZSk6ICUgPT0gcGVyIFQ7Cgl0aGVJbnRlZ2VyVHlwZSgpOiAlID09IHBlciBJbnRl
Z2VyOwoKCShhOiAlKSA9IChiOiAlKTogQm9vbGVhbiA9PSB7CgkJaW1wb3J0IGZyb20gQW55OwoJ
CShhIHByZXRlbmQgQW55KSA9IChiIHByZXRlbmQgQW55KTsKCX0KCgltYXAoYXJnczogVHVwbGUg
JSwgcmV0czogVHVwbGUgJSk6ICUgPT0gewoJCXBlciggKGFyZ3MgcHJldGVuZCBUdXBsZSBCYXNp
Y1R5cGUpIC0+IChyZXRzIHByZXRlbmQgVHVwbGUgQmFzaWNUeXBlKSkKCX0KCgljb2VyY2UodDog
JSk6IE91dHB1dEZvcm0gPT0gewoJCWltcG9ydCBmcm9tIFN0cmluZzsKCQkiPFNvbWVUeXBlPiI6
Ok91dHB1dEZvcm0KCX0KCgluYW1lKHQ6ICUpOiBTdHJpbmcgPT0gewoJCWRvbSA6PSB0IHByZXRl
bmQgUmVwMjsKCQlzdHJpbmcoKGRvbS52LmRvbU5hbWUpKGRvbS5vKSkKCX0KCgloYXNoQ29kZSh0
OiAlKTogSW50ZWdlciA9PSB7CgkJZG9tIDo9IHQgcHJldGVuZCBSZXAyOwoJCWludGVnZXIoKGRv
bS52Lmhhc2hDb2RlKShkb20ubykpCgl9Cn0K


--=-Y/vbkhq1AsQF+3nkWnMP

I2luY2x1ZGUgImF4aW9tLmFzIgoKQWxkb3JEb21haW46IEJhc2ljVHlwZSB3aXRoIHsKIAltYWtl
OiAoVDogQmFzaWNUeXBlKSAtPiAlOwoKCXRoZUludGVnZXJUeXBlOiAoKSAtPiAlOwoJbWFwOiAo
VHVwbGUgJSwgVHVwbGUgJSkgLT4gJTsKCWludGVnZXJNb2Q6IFBvc2l0aXZlSW50ZWdlciAtPiAl
OwoJCgljb2VyY2U6ICUgLT4gT3V0cHV0Rm9ybTsKCgluYW1lOiAlIC0+IFNFeHByZXNzaW9uOwoK
CWxvb2t1cDogKCUsIFN0cmluZywgJSkgLT4gU0V4cHJlc3Npb247CgoJaGFzaENvZGU6ICUgLT4g
SW50ZWdlcjsKCn0gPT0gYWRkIHsKCWltcG9ydCB7CgkJQk9PVF86XzpETmFtZVRvU0V4cHI6IFNF
eHByZXNzaW9uIC0+IFNFeHByZXNzaW9uOwoJCUJPT1RfOl86aGFzaFN0cmluZzogU0V4cHJlc3Np
b24gLT4gU0V4cHJlc3Npb247Cgl9IGZyb20gRm9yZWlnbiBMaXNwOwoJCglSZXAgID09PiBUeXBl
OwoJUmVwMiA9PT4gUmVjb3JkKHY6IFJlY29yZChkb21UeXBlOiBTRXhwcmVzc2lvbiAtPiBTRXhw
cmVzc2lvbiwgCgkJCQkgIGRvbU5hbWU6IFNFeHByZXNzaW9uIC0+IFNFeHByZXNzaW9uLAoJCQkJ
ICBub3RVc2VkOiBTRXhwcmVzc2lvbiAtPiBTRXhwcmVzc2lvbiwKCQkJCSAgbG9va3VwOiAgKFNF
eHByZXNzaW9uLCBTRXhwcmVzc2lvbiwgU0V4cHJlc3Npb24sIAoJCQkJCSAgICBTRXhwcmVzc2lv
biwgU0V4cHJlc3Npb24sIFNFeHByZXNzaW9uLAoJCQkJCSAgICBTRXhwcmVzc2lvbikgLT4gU0V4
cHJlc3Npb24sCgkJCQkgIGhhc2hDb2RlOiBTRXhwcmVzc2lvbiAtPiBTRXhwcmVzc2lvbiwKCQkJ
CSAgdW5rbm93bjogU0V4cHJlc3Npb24gLT4gU0V4cHJlc3Npb24pLAoJCQlvOiBTRXhwcmVzc2lv
bik7CgkKCWltcG9ydCBmcm9tIFJlcDI7CgoJbWFrZShUOiBCYXNpY1R5cGUpOiAlID09IHBlciBU
OwoJdGhlSW50ZWdlclR5cGUoKTogJSA9PSBwZXIgSW50ZWdlcjsKCWludGVnZXJNb2QocDogUG9z
aXRpdmVJbnRlZ2VyKTogJSA9PSBwZXIoSW50ZWdlck1vZCBwKTsKCgltYXAoYXJnczogVHVwbGUg
JSwgcmV0czogVHVwbGUgJSk6ICUgPT0gewoJCXBlciggKGFyZ3MgcHJldGVuZCBUdXBsZSBCYXNp
Y1R5cGUpIC0+IChyZXRzIHByZXRlbmQgVHVwbGUgQmFzaWNUeXBlKSkKCX0KCgoJKGE6ICUpID0g
KGI6ICUpOiBCb29sZWFuID09IHsKCQlpbXBvcnQgZnJvbSBJbnRlZ2VyOwoJCWhhc2hDb2RlKGEp
ID0gaGFzaENvZGUoYikKCX0KCgoJY29lcmNlKHQ6ICUpOiBPdXRwdXRGb3JtID09IHsKCQlpbXBv
cnQgZnJvbSBTdHJpbmc7CgkJIjxTb21lVHlwZT4iOjpPdXRwdXRGb3JtCgl9CgoJbmFtZSh0OiAl
KTogU0V4cHJlc3Npb24gPT0gewoJCWRvbSA6PSB0IHByZXRlbmQgUmVwMjsKCQlheGlvbU5hbWUo
KGRvbS52LmRvbU5hbWUpKGRvbS5vKSkKCX0KCgktLSBuYjogY2YuIGludGVyb3AuYm9vdCwgYmFz
aWNMb29rdXAKCWxvb2t1cCh0OiAlLCBuYW1lOiBTdHJpbmcsIHR5cGU6ICUpOiBTRXhwcmVzc2lv
biA9PSB7CgkJLS0gbG9va3VwIHRha2VzIHRoZSBmb2xsb3dpbmcgYXJndW1lbnRzOgoJCS0tIGRv
bWFpbiByZXAsIGRvbWFpbiwgb3BlcmF0aW9uLCBjb25zcGFpciwgZmxhZywgbG9va3VwRm4KCQlp
bXBvcnQgZnJvbSBMaXN0IFNFeHByZXNzaW9uOwoJCWRvbSA6PSB0IHByZXRlbmQgUmVwMjsKCQli
b3g6IFNFeHByZXNzaW9uIDo9IGNvbnZlcnQgW2NvbnZlcnQgIiJdOwoJCWxvb2t1cEZuIDo9ICBk
b20udi5sb29rdXA7CgkJbmlsIDo9IGNvbnZlcnQgW107CgkJbG9va3VwRm4oZG9tLm8sIAoJCQkg
ZG9tIHByZXRlbmQgU0V4cHJlc3Npb24sIAoJCQkgaGFzaFN0cmluZyhjb252ZXJ0IG5hbWUpLCAK
CQkJIGNvbnZlcnQgaGFzaENvZGUodHlwZSksCgkJCSBib3gsCgkJCSBjb252ZXJ0IFtdLCBsb29r
dXBGbiBwcmV0ZW5kIFNFeHByZXNzaW9uKTsKCX0KCgloYXNoQ29kZSh0OiAlKTogSW50ZWdlciA9
PSB7CgkJZG9tIDo9IHQgcHJldGVuZCBSZXAyOwoJCWludGVnZXIoKGRvbS52Lmhhc2hDb2RlKShk
b20ubykpCgl9CgoJbG9jYWwgYXhpb21OYW1lKHM6IFNFeHByZXNzaW9uKTogU0V4cHJlc3Npb24g
PT0gewoJCUJPT1RfOl86RE5hbWVUb1NFeHByKHMpOwoJfQoKCWxvY2FsIGhhc2hTdHJpbmcoczog
U0V4cHJlc3Npb24pOiBTRXhwcmVzc2lvbiA9PSB7CgkJQk9PVF86XzpoYXNoU3RyaW5nKHMpOwoJ
fQp9Cg=

--=-Y/vbkhq1AsQF+3nkWnMP--

\start
Date: Mon, 26 Sep 2005 23:03:47 -0400
From: Tim Daly
To: Alan Eliasen
Subject: Units

Alan,

Frink has developed software to work on units. One of the expressed
desires on the Frink webpage is to develop a version of the package
that would work on symbolic values.

On the Axiom mailing list we have been discussing this particular topic.
Axiom is a free, general purpose computer algebra system similar in
scope and power to Mathematica and Maple. It does not currently support
Units or Dimensions on input values but this is being discussed.
(see http://page.axiom-developer.org)

I've been looking at the Frink software and read the units.txt file
(a rather amusing document) in detail. It is clear we have much to
learn from your efforts. 

I see that the software is "free" but I couldn't find the source
anywhere. I was hoping to learn what you've already done so I could
have a better reference point than my own, uneducated opinion. Is
the source available for study?

\start
Date: Mon, 26 Sep 2005 19:47:30 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: CATS?

Hey Tim, is the CATS arch archive for Axiom available somewhere?  It
doesn't seem to be listed on the server.

\start
Date: Mon, 26 Sep 2005 23:10:40 -0400
From: Tim Daly
To: Cliff Yapp
Subject: Re: CATS?

CATS isn't uploaded at the moment.
I have the branch on my home machine.
If you'd like I can create the arch branch.

\start
Date: Mon, 26 Sep 2005 21:34:34 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly
Subject: Re: CATS?

No biggie - I was looking for interesting things to download and
examine during my "offline" period, and CATS sounds interesting.  But
since I might be offline tomorrow don't worry on my account.

--- Tim Daly wrote:

> CATS isn't uploaded at the moment.
> I have the branch on my home machine.
> If you'd like I can create the arch branch.

\start
Date: Tue, 27 Sep 2005 00:38:50 -0400
From: Bill Page
To: William Sit
Subject: RE: Types as values, and Re: Static versus Dynamically typed

On September 24, 2005 12:07 PM William Sit wrote:
> 
> Bill Page wrote:
> > 
> > On September 23, 2005 7:36 AM William Sit wrote:
> > > From www.aldor.org:
> > > > Types and functions are first class entities allowing
> > > > them to be constructed and manipulated within Aldor
> > > > programs just like any other value.
> > > >
> > > Can some Aldor expert expand on this? For example, can 
> > > functions be created, modified, and compiled and called
> > > all at run time? (People used to do code modification on
> > > assembly languages and may still do, but the practice is
> > > I think no longer promoted, if not outright banned.)
> > >
> > 
> 
> > In Axiom it is possible. See for example section 9.50
> > MakeFunction in the Axiom book. There are numerous other
> > examples of this in Axiom.
>
> Thanks, but MakeFunction only turns an expression into a 
> function by enabling evaluation. So in this sense, sure a new
> function is created, much like defining a new function in the
> interpreter. What I meant (sorry I wasn't clear) was to
> take an existing library function, say a simple one like 
> "inc" which adds 1 to the argument, modify the code and create
> FROM THAT CODE a new function "incBy2" (or for that matter,
> use the same function name "inc") that adds 2 to its argument
> (note, not rewriting from scratch "incBy2", and not
> implementing "incBy2" USING "inc" twice, but by modifying
> existing code, changing where "1" is, to "2" in the code
> itself), have that function compiled, and executed, all
> without leaving the interpreter or Axiom (or, Aldor). The 
> crucial thing I am asking is "code-modification" because
> that is the real meaning, as I understand it, of
> "constructed and manipulated [Types and functions] ... 
> just like any other value".

No I do not think that "code-modification" is the meaning
of "constructed and manipulated" in reference to Aldor.
What you are describing is equivalent for example to allowing
modifiable string *constants* -- something that used to be
possible in the C programming language, i.e. pass a pointer
to a string constant say "xxx" to a function that modifies
it's value to, say "123". Later in your program when you
have written what looks like "xxx" is now treated as "123".
I am also old enough to remember when it was possible for
a bug in Fortran to inadvertently modify the value of a
integer constant because these were passed by reference
to a location in memory that was initialized to the proper
value.

I agree that this practice is essentially "banned" - for
good reason!


> Similarly, the "curry" type functions in Axiom do not
> "modify" code and is a variant of MakeFunction. Can Aldor
> manipulate types and functions much like Lisp (or Scheme)
> does?

But I think that is exactly what is implied by construct
and manipulate in this context. Functions in lisp are
just lists of a certain kind and so yes of course they
can be manipulated as lists. Functions in Aldor (and most
other languages) are more complex things than lists but
still then can be constructed and manipulated like any
other *first class objects*. For example we can curry
them, we can compose them etc., to make new functions,
in the same way that we can create the integer 2 and we
can add 2 + 2 and get a new integer.

I supposed however that what you might be asking is whether
functions in Aldor are "mutable" in the same way that
lists are mutable in lisp (or arrays are mutable in other
languages). I think the answer is "no". In general constants
are not mutable in this way and functions are constants.
But Aldor does allow use to use names which are assigned
values which are functions and of course the values assigned
to such names can change during the course of a computation.

> In principle, this is easy, if the code is treated
> as a string, and if the format structure and language 
> syntax are known; so the question is not whether this
> is "possible", but whether this is "available" as a
> feature of the Aldor language, that the code string
> can be returned, manipulated, edited, and sent back to
> the compiler to get a new or modified function. In
> Axiom, I would imagine one has to go the relevant NRLIB,
> look at the code.lsp, and create a new version of it,
> create the corresponding .o file to make this "possible".
> I don't consider that as "available".
>

I am quite sure that by design this is not "available" in
Aldor and that it is not implied by the description of Aldor
quoted at the beginning of this messages.

In an interesting paper recently pointed out to me by Ralf
Hemmecke:

http://www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/discussion/define.pdf

A D Kennedy defines first class entities as follows:

"An object is first class if its value can be expressed as
an anonymous constant expression."

And gives the following examples:

  1@SingleInteger -- is an anonymous integer constant,

  (x: SingleInteger): SingleInteger +-> x * x
    -- is an anonymous function constant
    -- (a.k.a. a lambda expression)

  with {+: (%,%) -> %; inv: % -> %}
    -- is an anonymous category constant

  add {
    Rep == SingleInteger;
    import from Rep;
    (x: %) + (y: %): % == per((rep x) + (rep y));
    inv(x: %): % == per(1 / rep x)
  } -- is an anonymous domain constant

--------

So the fact that "types and functions are first class entities"
in Aldor specifically allows them to be constructed and
manipulated like anything else whose value is a constant.
This does not mean that we can change the *value* (i.e. the
meaning) of a function that adds 1 to its argument (referred
to as "inc" in your example above) so that later adds 2
instead of adding 1, any more than we can change 1 to mean 2.
But we can of course change what the name "inc" refers to so
that it might later refer to a function that adds 2. And
we can pass functions as arguments to other functions which
might apply them or use them to construct new functions which
are then returned as the value of the function etc.

However Aldor is still statically typed in the sense that
we cannot change an object which has been declared as being
of one type into another. But Aldor/Axiom types are quite
powerful since then can be constructed from union, record
and mapping, so we can write things like:

(1) ->   x:Union(Integer,Float,Integer->Integer)
                                        Type: Void
(2) ->   x:=1

   (2)  1
                            Type: Union(Integer,...)
(3) ->   x+x

   (3)  2
                               Type: PositiveInteger
(4) ->   x:=1.0

   (4)  1.0
                               Type: Union(Float,...)
(5) ->   sin(x)

   (5)  0.8414709848 0789650665
                                          Type: Float
(6) ->   x:=(w +-> w+1)

   (6)  theMap(Closure)
                 Type: Union((Integer -> Integer),...)
(7) ->   (x::(Integer->Integer))(1)

   (7)  2
                                 Type: PositiveInteger
(8) ->

and x would still be considered a statically typed first
class object.

\start
Date: Tue, 27 Sep 2005 03:11:48 -0400
From: William Sit
To: Bill Page
Subject: Re: Types as values, and Re: Static versus Dynamically typed

Dear Bill:

Thanks for taking the time to explain things to me.

Bill Page wrote:
> 
> > > From www.aldor.org:
> > >  Types and functions are first class entities allowing
> > >  them to be constructed and manipulated within Aldor
> > >  programs just like any other value.

[snipped]

William Sit wrote:
> > The
> > crucial thing I am asking is "code-modification" because
> > that is the real meaning, as I understand it, of
> > "constructed and manipulated [Types and functions] ...
> > just like any other value".
> 
> No I do not think that "code-modification" is the meaning
> of "constructed and manipulated" in reference to Aldor.

[snipped]

In light of your view (which is the correct view) that functions are constants,
I might have used the term "code-modification" wrongly. I was using it in the
sense that function code is data and data is being modified, so code is modified
in the process, but not in the sense of changing the function, which perhaps
should remain unaltered. So let me instead ask whether a copy of the data
representing the definition of the function may be modified to create another
function.
Constants should still be available to create new objects. So let me modify my
example. Suppose "inc" is a compiled function that increments 1 to its argument.
Then I can assign it to a variable:

variableFunction := inc

if you like,

variableFunction := copy(inc)

so I will not modify "inc" in any way. However, I want the definition for "inc"
to be available to me (perhaps as a lambda expression, perhaps its Axiom
equivalent) and that I can change this definition in my copy of "inc" (that is,
operating ON the function object) to create a new function that increments 2 to
its argument. This would be analogous to say how one modifies the entries of a
matrix via a copy. (Actually, we are allowed to directly change the entry of a
matrix for efficiency if the matrix has Mutable). But for this discussion, I am
no longer assuming functions are mutable (I probably was).
 
> > Similarly, the "curry" type functions in Axiom do not
> > "modify" code and is a variant of MakeFunction. Can Aldor
> > manipulate types and functions much like Lisp (or Scheme)
> > does?
> 
> But I think that is exactly what is implied by construct
> and manipulate in this context. Functions in lisp are
> just lists of a certain kind and so yes of course they
> can be manipulated as lists. Functions in Aldor (and most
> other languages) are more complex things than lists but
> still then can be constructed and manipulated like any
> other *first class objects*. For example we can curry
> them, we can compose them etc., to make new functions,
> in the same way that we can create the integer 2 and we
> can add 2 + 2 and get a new integer.

These are operations USING the function, not operations ON the functions. If
"constructed and manipulated" means only USING the functions, I don't see any
extra power in Aldor that is not already in Axiom.

 
> I supposed however that what you might be asking is whether
> functions in Aldor are "mutable" in the same way that
> lists are mutable in lisp (or arrays are mutable in other
> languages). I think the answer is "no". In general constants
> are not mutable in this way and functions are constants.

I will assume functions are not mutable, but I don't see a compelling reason to
enforce this if functions are indeed "first class" (here, meaning on equal
footing as data objects). If matrices and other structures can be mutable, why
should functions be different? (OK, in the hands of careless programmers, this
power will play havoc; but so would such programmers do damage to matrix
computations or other mutable objects).

> But Aldor does allow use to use names which are assigned
> values which are functions and of course the values assigned
> to such names can change during the course of a computation.

You mean I can do:

variableFunction:= inc1
variableFunction(5)

               6
 
variableFunction:= inc2
variableFunction(5)

               7
I don't see that as a powerful feature. In fact, its power is much like a TeX
macro. Convenient, yes.

> > the question is not whether this
> > is "possible", but whether this is "available" as a
> > feature of the Aldor language, that the code string
> > can be returned, manipulated, edited, and sent back to
> > the compiler to get a new or modified function. In
> > Axiom, I would imagine one has to go the relevant NRLIB,
> > look at the code.lsp, and create a new version of it,
> > create the corresponding .o file to make this "possible".
> > I don't consider that as "available".
> >
> 
> I am quite sure that by design this is not "available" in
> Aldor and that it is not implied by the description of Aldor
> quoted at the beginning of this messages.

The statement needs clarification. But shouldn't the definition of function (the
code, not just the signature) be available for manipulation even if the function
itself is kept constant?
 
> A D Kennedy defines first class entities as follows:
> 
> "An object is first class if its value can be expressed as
> an anonymous constant expression."
[snipped]
> So the fact that "types and functions are first class entities"
> in Aldor specifically allows them to be constructed and
> manipulated like anything else whose value is a constant.
> This does not mean that we can change the *value* (i.e. the
> meaning) of a function that adds 1 to its argument (referred
> to as "inc" in your example above) so that later adds 2
> instead of adding 1, any more than we can change 1 to mean 2.

OK, grant you that. There is still a difference in "types and functions as first
class entities" and usual domain objects as first class entities. For domains,
we are normally not exposed to the Rep, but if we like, we CAN provide that
functionality by means of functions exported for that domain. An example would
be PRODUCT or FRAC (where using "numerator" and "denominator" we can extra
fields in the Rep, modify them, and create a new fraction). For the "domain of
functions", the Rep of a function may be its anonymous function constant (lambda
expression), but it seems we are not allowed to provide functionality to read
this lambda expression and construct new objects from it. If indeed objects in
the "domain of functions" are first class objects, we should be able to query
its properties. The same thing for the "domain of Type" (probably an
ill-constructed term), we should be able to query the properties of domains and
categories.


> But we can of course change what the name "inc" refers to so
> that it might later refer to a function that adds 2. And
> we can pass functions as arguments to other functions which
> might apply them or use them to construct new functions which
> are then returned as the value of the function etc.

All that amounts to is just pointers or macros. As long as it is only USING the
functions rather than operating ON the functions, such features do not give
functions equal status as objects in domains (even if by definition, they are
both first class; perhaps they should be called weak first class).

> However Aldor is still statically typed in the sense that
> we cannot change an object which has been declared as being
> of one type into another. But Aldor/Axiom types are quite
> powerful since then can be constructed from union, record
> and mapping, so we can write things like:
> 
[example using Union to switch types: snipped]

> and x would still be considered a statically typed first
> class object.
 
Sure, because the type of x is actually Union(Integer, ...) throughout
all these computations. It is only because the interpreter understands
Union to apply automatically the "case" function and locate the other
function calls. I am not following the relevance to "first class
object".

Thanks again for your input.

\start
Date: Tue, 27 Sep 2005 11:33:34 +0200
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: types as values

root wrote:
> If memory serves me Aldor made Types be first-class objects.
> You could create, assign, and pass Type objects to functions.
> 
> t

Unfortunately, things are not so easy.

http://www.ph.ed.ac.uk/~bj/paraldor/WWW/docs/discussion/define.pdf

\start
Date: Tue, 27 Sep 2005 12:50:59 +0200
From: Ralf Hemmecke
To: William Sit
Subject: re: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... )

William Sit wrote:

>>>It is useful, for example, to be able to distinguish whether a
>>>field is a quotient field of some integral domain or just a field
>>>to make codes more efficient. The request was not acted upon
>>>because at the time (around 1990 +/- 3 years?), effort was
>>>concentrated on developing the Aldor (A#) compiler, which promised
>>>to solve such problems.

>>However, I somehow do not think that
>>being able to query the structure of a type is a good idea. You gave a
>>good reason, but isn't there a better way to achieve efficiency?

> Yes, but another reason, in the above example of field, is in
> allowing generalizations to work, not just efficiency due to data
> representation (reducing computation in the field to that in the
> underlying integral domain, as in Grobner bases computation). For
> example, if I have a constructor that requires an integral domain R
> as a parameter, and I constructed in the package the quotient field
> of R, as you may suggest as an explicit way to achieve efficiency,
> then the package will FAIL if R is actually a field (you can
> consider this as a bug if you like), even though a field IS an
> integral domain, mathematically. If we COULD ask whether R is a
> quotient field (not just a field) and if in case of affirmative
> answer also find out the underlying integral domain S of R = FRAC S,
> we would be able to replace R by S for the package.

Hmm, but one can also achieve what you want by adding a function to the 
Fraction constructor

Fraction(R: IntegralDomain): with {
   ...
   fractionField: Boolean;
   underlyingDomain: IntegralDomain;
   ...
} == add {
   fractionField: Boolean == true;
   underlyingDomain: IntegralDomain == R;
   ...
}

If one then gets a field K, one just has to ask

if K has with {fractionField: Boolean} then {
    Groebner(underlyingDomain K, coercedPolys);
} else {
   Groebner(K, polys);
}

\start
Date: Tue, 27 Sep 2005 06:40:26 -0500
From: MathAction (kratt6)
To: MathAction
Subject: [#207 certain limit failure] (nouveau) 

Consider the following two expressions:

\begin{axiom}
exa:=integrate(log(1/x)/x^a,x)
exb:=integrate(log(1/x)*x^b,x)
\end{axiom}
which are equivalent by setting $a=-b$.
However, the operation 'limit' doesn't like both equally well:
\begin{axiom}
limit(exa,x=0)
limit(exb,x=0)
\end{axiom}

\start
Date: Tue, 27 Sep 2005 14:03:11 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... )

Ralf Hemmecke writes:
 > William Sit wrote:
 > 
 > > For example, if I have a constructor that requires an integral domain R as
 > > a parameter, and I constructed in the package the quotient field of R, as
 > > you may suggest as an explicit way to achieve efficiency, then the package
 > > will FAIL if R is actually a field (you can consider this as a bug if you
 > > like), even though a field IS an integral domain, mathematically.

Why would it fail? I don't think it does, in fact. However, if you are going to
apply FRAC you can simply ask whether the domain is a Field.

On the other hand, given a Field to ask whether it is a QuotientField is a
question that I consider quite important. 

However, the desirable query

  if R has QuotientField S

thus defining S is, I think, quite difficult to implement sensibly. Throughout
Axiom, this effect is obtained by adding another parameter to the
Package/Domain signature like:

MyPackage(F: Field, S: IntegralDomain): ...

  if F is Fraction S then

\start
Date: Tue, 27 Sep 2005 16:36:58 +0200
From: Gregory Vanuxem
To: Ralf Hemmecke
Subject: re: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... )

> -----Message d'origine-----
> De : Ralf Hemmecke [mailto:Ralf Hemmecke]
> Envoy=E9 : mardi 27 septembre 2005 16:30
> =C0 : Vanuxem Gregory
> Cc : Martin Rubey; axiom-dev
> Objet : re: Types as values,and Re: Static
> versusDynamicallytyped(was:Philosophy... )
>
>
> [snip]
>
> >>However, the desirable query
> >>
> >>  if R has QuotientField S
> >>
> >>thus defining S is, I think, quite difficult to implement
> >>sensibly. Throughout
> >>Axiom, this effect is obtained by adding another parameter to the
> >>Package/Domain signature like:
> >>
> >>MyPackage(F: Field, S: IntegralDomain): ...
> >>
> >>  if F is Fraction S then
>
> Martin, do you really mean "is" instead of "has"? I don't think that
> your "if" expression works with Aldor.
>
> Anyway, if I were a compiler/interpreter, what would I do with something
> like
>
> if F is Fraction S then ...
>
> I would first evaluate the function "Fraction" obtaining a type T and
> then check whether F and T are the same thing. S would be lost. One
> could only achieve your wish by pattern matching, but Axiom doesn't work
> that way, does it?
>
>  > I think that works only in function definition but not in function
>  > decalaration.
>
> Greg, what do you mean by that?

I think in axiom the keyword 'is' works only where we define function
(and not in function declaration) in other words:

MyPackage(F: Field, S: IntegralDomain): ...
  myfunc(%):Type -> Type

  add
     if F is Fraction S then
        myfunc...
     else
        myfunc...

\start
Date: Tue, 27 Sep 2005 16:14:28 +0200
From: Gregory Vanuxem
To: Martin Rubey, Ralf Hemmecke
Subject: re: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... )

Hi,

> -----Message d'origine-----
> De : axiom-developer-bounces+g.vanuxem=wanadoo.fr@nongnu.org
> part de Martin Rubey
> Envoye : mardi 27 septembre 2005 14:03
> A : Ralf Hemmecke
> Cc : axiom-dev
> Objet : re: Types as values,and Re: Static
> versusDynamicallytyped(was:Philosophy... )
>
>
> Ralf Hemmecke writes:
>  > William Sit wrote:
>  >
>  > > For example, if I have a constructor that requires an
> integral domain R as
>  > > a parameter, and I constructed in the package the quotient
> field of R, as
>  > > you may suggest as an explicit way to achieve efficiency,
> then the package
>  > > will FAIL if R is actually a field (you can consider this as
> a bug if you
>  > > like), even though a field IS an integral domain, mathematically.
>
> Why would it fail? I don't think it does, in fact. However, if
> you are going to
> apply FRAC you can simply ask whether the domain is a Field.
>
> On the other hand, given a Field to ask whether it is a QuotientField is a
> question that I consider quite important.
>
> However, the desirable query
>
>   if R has QuotientField S
>
> thus defining S is, I think, quite difficult to implement
> sensibly. Throughout
> Axiom, this effect is obtained by adding another parameter to the
> Package/Domain signature like:
>
> MyPackage(F: Field, S: IntegralDomain): ...
>
>   if F is Fraction S then

I think that works only in function definition but not in function
decalaration.

\start
Date: Tue, 27 Sep 2005 16:30:26 +0200
From: Ralf Hemmecke
To: Gregory Vanuxem
Subject: re: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... )

[snip]

>>However, the desirable query
>>
>>  if R has QuotientField S
>>
>>thus defining S is, I think, quite difficult to implement
>>sensibly. Throughout
>>Axiom, this effect is obtained by adding another parameter to the
>>Package/Domain signature like:
>>
>>MyPackage(F: Field, S: IntegralDomain): ...
>>
>>  if F is Fraction S then

Martin, do you really mean "is" instead of "has"? I don't think that 
your "if" expression works with Aldor.

Anyway, if I were a compiler/interpreter, what would I do with something 
like

if F is Fraction S then ...

I would first evaluate the function "Fraction" obtaining a type T and 
then check whether F and T are the same thing. S would be lost. One 
could only achieve your wish by pattern matching, but Axiom doesn't work 
that way, does it?

 > I think that works only in function definition but not in function
 > decalaration.

Greg, what do you mean by that?

\start
Date: Tue, 27 Sep 2005 18:11:25 -0400
From: Bill Page
To: Camm Maguire
Subject: RE: FW: How to set default for	ALLOCATE-CONTIGUOUS-PAGES?

Camm,

On Tuesday, September 27, 2005 5:10 PM you wrote:
>
> Greetings, and please exsude the delay!
>

No problem! I exsude (sic) delay myself ;)

On Thursday, September 15, 2005 12:17 PM Bill Page wrote:
> >
> > On Thursday, September 15, 2005 12:07 PM I wrote:
> > > > ...
> > > > GCLOPTS="--enable-vssize=65536*2 --enable-statsysbfd
> > > > --enable-maxpage=256*1024"
> > > >
> >
> > Oops... the build just died with: NULL_OR_ON_C_STACK macro invalid
> >
> > ...
> > echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")"
> > >>foo
> >
>
/home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/raw_pre_gcl
> > /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/unixport/ -libdir
> > /home/page/repository/axiom--main--1/lsp/gcl-2.6.7/ < foo
> > GCL (GNU Common Lisp)  April 1994  262144 pages
> >
> > Unrecoverable error: NULL_OR_ON_C_STACK macro invalid.
>
> What kind of machine is this?

This is the axiom-developer server where we run MathAction. It
is a x686 shared virtual server running RedHat 9.  The error
occurs when trying to build Axiom patch-44 which includes
gcl-2.6.7. The build succeeds if I use the normal Axiom default
of --enable-maxpage=128*1024, but then I get the
ALLOCATE-CONTINUOUS-PAGES error. See below. That is why I was
trying to increase maxpage.

> The purpose of this macro is to distinguish the stack address
> space. Addresses of local variables should return true, and
> others false. GCL tests this on starup on a local variable, NIL,
> and core_end. One can see what the macro expands to by doing
> 'cpp -I../h main.c' in the o directory.  Most likely there was
> some problem in detecting CSTACK_ADDRESS in the configure stage.
> I recommend looking at the configure output for this.

Ok. Here is where CSTACK_ADDRESS is mentioned in the configure
output:

...
checking for randomized sbrk... no
checking finding DBEGIN... got 0x8000000
checking finding CSTACK_ADDRESS... got 1073738356
...

In config.log I see

...
configure:3780: checking for sbrk
configure:3798: gcc -o conftest      conftest.c  1>&5
configure:3814: checking for randomized sbrk
configure:3831: gcc -o conftest      conftest.c  1>&5
configure:3863: gcc -o conftest      conftest.c  1>&5
configure:3984: checking finding DBEGIN
configure:4028: gcc -o conftest     conftest.c  1>&5
configure:4051: checking finding CSTACK_ADDRESS
configure:4068: gcc -o conftest      conftest.c  1>&5
...

So I don't see a problem here. Do you?

On Thursday, September 15, 2005 5:58 AM Bill Page wrote:
> > >
> > > On Thursday, September 15, 2005 5:22 AM I wrote:
> > >
> > > > ...
> > > > Yes, I think you are right. I changed the short name
> > > > (abbreviation=file name?) of my Aldor category from
> > > > upper case to lower case and now it **sometimes** works.
> > > > See:
> > > >
> > > > http://wiki.axiom-developer.org/SandBoxCategoryOfGraphs
> > > >
> > > > But often when I try to save this page I get:
> > > >
> > > >     >> System error:
> > > >     Contiguous blocks exhausted.
> > > >   Currently, 1354 pages are allocated.
> > > >   Use ALLOCATE-CONTIGUOUS-PAGES to expand the space.
> > > >
>
> You can allocate page types explicitly with the #'allocate function
> (see the docs if needed),

I do not know what you mean by "allocate page types explicitly".
Is this a function like si::allocate-contiguous-pages that I used
in the Axiom )lisp command below? Or does this have something to
do with the gcl configuration?

> but this is not necessary, as you are totally out of memory here,
> and this will just forestall total failure.

As I mentioned in the previous email, all seems well if I call

  )lisp (si::allocate-contiguous-pages 3000 t)

inside Axiom before access the Aldor category. Why do you say
that I am "totally out of memory"?

> You need to configure with a greater --enable-maxpage.

That is what I tried to do but the build of gcl fails as
I mentioned above.

>
> Do I understand right that someone is layering aldor on top
> of axiom?

Aldor used to be available as an optional library compiler
for the commercial version of Axiom. The current open source
version of Axiom was released without Aldor because NAG had
previously and separately given the rights to the Aldor source
to "aldor.org" (aka. Stephen Watt). "aldor.org" makes binary
versions of Aldor available for free for non-commmercial use
but does not follow the current open source licensing model.

Recently Peter Broadbery was able to configure the open source
version of Axiom to use the Aldor binary on linux. So now
Axiom functions the way it used to in the commercial release
but the license status of Aldor is still uncertain. I have made
several requests to Stephen Watt to obtain a copy of the
source code license for Aldor but I have not yet heard from
him.

> Can we distribute such in Debian yet?

I presuemt that to distribute on Debian we would require
a GPL-compatible source license to Aldor, right?

> If so, I might be persuaded to package it, and thereby ensure
> that it works :-).

Wonderful. I think we should try hard to make this happen.
I would love to be able to just 'apt-get install aldor'! :)

\start
Date: Tue, 27 Sep 2005 18:57:28 -0400
From: Tim Daly
To: Stephen Watt
Subject: Aldor license

Stephen,

One of our developers (Camm Maquire) is also a Debian maintainer.
In the past he has packaged Axiom so that it is possible (in a debian
compatible distribution) to type 'apt get axiom' and have it installed
on your machine (across about 10 architectures). He'd like to do the
same for Aldor. The mail snippet is attached below. 

This would greatly increase the distribution base for Aldor and attract
more developers and users to both Aldor and Axiom.

Tim

=================================================================
mailing list conversation between Camm Maguire and Bill Page....
=================================================================
> Can we distribute such in Debian yet?

I presuemt that to distribute on Debian we would require
a GPL-compatible source license to Aldor, right?

> If so, I might be persuaded to package it, and thereby ensure
> that it works :-).

Wonderful. I think we should try hard to make this happen.
I would love to be able to just 'apt-get install aldor'! :)

\start
Date: Tue, 27 Sep 2005 17:11:19 -0700 (PDT)
From: Cliff Yapp
To: Bill Page, Camm Maguire
Subject: Aldor+Axiom

--- Bill Page wrote:
> >
> > Do I understand right that someone is layering aldor on top
> > of axiom?
>
> Recently Peter Broadbery was able to configure the open source
> version of Axiom to use the Aldor binary on linux. So now
> Axiom functions the way it used to in the commercial release
> but the license status of Aldor is still uncertain. I have made
> several requests to Stephen Watt to obtain a copy of the
> source code license for Aldor but I have not yet heard from
> him.

IIRC some years ago I saw a comment to the effect that the intent was
to develop Aldor commercially and thus an open source scenario wasn't
desirable, but I can no longer locate the reference and it may or may
not still be true.  I note in
http://www.aldor.org/license-rationale.html what seems to be the main
problem is the requirement that Aldor needs to be able to make
modifications available, e.g. "Parts of the existing code base in the
software package that this license is applied to require Aldor.org to
make any updates available to the initial contributors."  Is this
NAG/IBM?  If so, could this be dealt with the same way that issue was
handled with Axiom itself?

Alternately, if Steve Watt or whoever should be reached can't be
reached to discuss the issue, was NAG's release of Aldor to the
Aldor.org group exclusive?  Perhaps NAG could release the original
Aldor to Axiom also, just with a different name?
 
> > Can we distribute such in Debian yet?
> 
> I presuemt that to distribute on Debian we would require
> a GPL-compatible source license to Aldor, right?

I think it has to meet the Debian Free Software Guidlines to be
included in the "main" distribution, otherwise I think it could go in
non-free?

I must admit for myself I'm not at all motivated to look at Aldor
unless it can be a default part of the free Axiom.  Aldor might be
nicer than SPAD, but I just can't see putting time and work into a
non-open source scenario personally.

Cheers,
CY

(Note - I replied to both dev and legal lists, but for this part I
think axiom-legal is the appropriate place - no point clogging up the
developer list with license discussions when we have a special place to
talk about such issues. :-)

\start
Date: Wed, 28 Sep 2005 02:11:01 -0400
From: William Sit
To: Martin Rubey
Subject: re: Types as values,and Re: Static versusDynamicallytyped(was:Philosophy... )

Martin Rubey wrote:
> 
> Ralf Hemmecke writes:
>  > William Sit wrote:

>  > > For example, if I have a constructor that requires an integral
>  > > domain R as a parameter, and I constructed in the package the
>  > > quotient field of R, as you may suggest as an explicit way to
>  > > achieve efficiency, then the package will FAIL if R is actually
>  > > a field (you can consider this as a bug if you like), even
>  > > though a field IS an integral domain, mathematically.

> Why would it fail? I don't think it does, in fact. However, if you
> are going to apply FRAC you can simply ask whether the domain is a
> Field.

Mathematically speaking, it should not, but one is still creating only
an isomorphic copy (presumably with a less efficient data structure)
since the total quotient ring of a field is isomorphic to the field
itself. However, while FRAC FRAC INT in the interpreter seems to
return a valid domain, a: FRAC FRAC INT would return an error that the
type is invalid. The problem is the current algebra code for FRAC does
not anticipate a field as its argument because it was implemented as
the localization of the ring with respect to a multipicatively closed
set.
 
> On the other hand, given a Field to ask whether it is a QuotientField is a
> question that I consider quite important.
> 
> However, the desirable query
> 
>   if R has QuotientField S
> 
> thus defining S is, I think, quite difficult to implement sensibly. 

Not only that, such a use is limited because it requires the user to supply S
already.

> Throughout
> Axiom, this effect is obtained by adding another parameter to the
> Package/Domain signature like:
> 
> MyPackage(F: Field, S: IntegralDomain): ...
> 
>   if F is Fraction S then
> 
> Martin

This construction certainly is because Axiom does not support querying
the parameters of a constructor from a domain resulting from that
constructor. So if some function returns a domain (constructors are
such functions), the domain already hides its parameters unless the
author deliberately provides functions to return such information (as
suggested by Ralf).

Besides requiring a priori knowledge of S, the above "work around"
does not help with the constructor FRAC when its parameter is a field
(not to mention when it is FRAC S for some S). Ideally, FRAC F when F
is a field should simply return F, but then since F need not be of the
form FRAC R for an integral domain R (for example when F is a finite
field), it would be meaningless to export functions like numerator or
denominator. But this necessitates recursive inquiry if R may itself
be a field. To avoid all such problems, Axiom (probably just the
interpreter) forbids FRAC FRAC INT.  If it is possible to inquire
about the parameters or even the constructor of F (by this I mean, is
F has the form FRAC S, or FF(p, n), etc without having the user to
specify any S, p, or n), and to return info on the parameters, then
types and domains can be truly analogous to normal data objects: we
are able to look into the entries of a matrix, or the terms and
coefficients of a polynomial: what I called operations ON the objects,
not USING the objects. Only by having operations ON the objects can
one add operations USING the objects. This feature would facilitate
simplification of type construction such as FRAC FRAC INT to just FRAC
INT, making them valid as well as efficiently and trivially
implementable.

\start
Date: Wed, 28 Sep 2005 09:59:49 +0200
From: Martin Rubey
To: William Sit
Subject: re: Types as values,and Re: Static

William Sit writes:
 > 
 > 
 > Martin Rubey wrote:

 > > On the other hand, given a Field to ask whether it is a QuotientField is a
 > > question that I consider quite important.
 > > 
 > > However, the desirable query
 > > 
 > >   if R has QuotientField S
 > > 
 > > thus defining S is, I think, quite difficult to implement sensibly. 

 > Not only that, such a use is limited because it requires the user
 > to supply S already.

I meant the above in the sense of pattern matching -- whereas the following
sentence was meant to indicate that this is is not the way to go.
 
 > If it is possible to inquire about the parameters [...] of F [...]

Yes, maybe you remember that I was asking for exactly this a while ago.

\start
Date: Wed, 28 Sep 2005 12:01:47 +0200
From: Ralf Hemmecke
To: William Sit
Subject: re: Types as values, and Re: Static versusDynamicallytyped(was:Philosophy... )

William Sit wrote:

> Besides requiring a priori knowledge of S, the above "work around"
> does not help with the constructor FRAC when its parameter is a
> field (not to mention when it is FRAC S for some S). Ideally, FRAC F
> when F is a field should simply return F,

In fraction.spac the Fraction code starts with
Fraction(S: IntegralDomain): QuotientFieldCategory S with
   if S has IntegerNumberSystem and S has OpenMath then OpenMath
   if S has canonical and S has GcdDomain and S has canonicalUnitNormal
       then canonical
  == LocalAlgebra(S, S, S) add
   ...

Isn't it allowed to modify this to

  == if F has Field
       then F
       else LocalAlgebra(S, S, S) add ...

> but then since F need not be of the form FRAC R for an integral
> domain R (for example when F is a finite field), it would be
> meaningless to export functions like numerator or denominator. But
> this necessitates recursive inquiry if R may itself be a field. To
> avoid all such problems, Axiom (probably just the interpreter)
> forbids FRAC FRAC INT.

It seems that the interpreter knows more about algebra as I would like. 
If one does not like FRAC FRAC INT then is should clearly be specified 
somewhere and not hidden in the interpreter. IMHO, the interpreter 
should interpret, but not add "implicit knowledge" that is not in the 
SPAD code itself.

> If it is possible to inquire about the parameters or even the
> constructor of F (by this I mean, is F has the form FRAC S, or FF(p,
> n), etc without having the user to specify any S, p, or n), and to
> return info on the parameters, then types and domains can be truly
> analogous to normal data objects: we are able to look into the
> entries of a matrix, or the terms and coefficients of a polynomial

Yes, we are able to look inside a matrix and even to modify entries 
destructively, but this only works because the designer of the Matrix 
has given enough exports to do so. Otherwise Matrix would just be a 
black box which might have properties like, for example, Algebra(R). 
Good enough for some algorithms, but probably not what an ordinary 
person thinks about matrices.

That is why I think that an explicit export of a function that returns 
the parameter domain would be the better way to go. If Q = FRAC R and 
one wants to get out R from Q, it is basically the same as asking to get
1 out of x (where x was previously obtained by x := inc(1). Or was it
x:=lenght("a") and one wants to get "a"?

\start
Date: Wed, 28 Sep 2005 06:46:05 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#208 interpret(x::InputFor)=x is broken for functions and types] (new) 

The coersion to InputForm produces a lispy representation for
most types. E.g.
\begin{axiom}
p:POLY INT:=x^2+1
p::InputForm
interpret(p)
\end{axiom}

But this fails for functions
\begin{axiom}
f:INT->INT
f(x) == x^2+1
f::InputForm
\end{axiom}
So far so good, but
\begin{axiom}
interpret(f)
\end{axiom}

\start
Date: Wed, 28 Sep 2005 06:53:22 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#208 interpret(x::InputFor)=x is broken for functions and types] 

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

\begin{axiom}

interpret(%)

f(2)

interpret(%)

\start
Date: Wed, 28 Sep 2005 08:32:53 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#208 interpret(x::InputFor)=x is broken for functions and types] 

pSex:=p::InputForm
p1:=interpret(pSex)

-- force compile

fSex:=f::InputForm

f1:=interpret(fSex)

\start
Date: 28 Sep 2005 10:57:45 -0400
From: Camm Maguire
To: William Sit
Subject: Re: Unit package proposals and questions

Greetings!

William Sit writes:

> I left the above in, just hoping someone will know how to do
> this. It is really a very simple thing. The information (strings for
> the dimensions) is in a list.  Why can't we feed this to Union
> without the list wrapper? Axiom allows commands in Lisp, and so
> someone who knows Lisp (Tim, Bill, Camm) should be able to easily
> write a line to do that. In Mathematica, one can replace the "Head",

What exactly is the lisp needed here?

\start
Date: Wed, 28 Sep 2005 11:22:52 -0400
From: William Sit
To: Camm Maguire
Subject: Re: Unit package proposals and questions

Camm Maguire wrote:
> 
> Greetings!
> 
> William Sit writes:
 
> > I left the above in, just hoping someone will know how to do
> > this. It is really a very simple thing. The information (strings
> > for the dimensions) is in a list.  Why can't we feed this to Union
> > without the list wrapper? Axiom allows commands in Lisp, and so
> > someone who knows Lisp (Tim, Bill, Camm) should be able to easily
> > write a line to do that. In Mathematica, one can replace the
> > "Head",
 
> What exactly is the lisp needed here?

I suppose I thought Lisp is useful here because Union is a low level
construct and so lisp may be needed to convert a LIST STRING object as
a delisted tuple of STRING objects to Union, just like

 Union("Mass", "Length")

which works, instead of 
 
 Union(["Mass", "Length"])

which does not work as intended. I tried to do this within Axiom
interpreter/compiler and was not able to. Roughly, need a domain constructor:

Dimension(s: List String):SetCategory == Union(delisted s)

Thanks for your interest in this.

\start
Date: Wed, 28 Sep 2005 12:43:58 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#209 The function |Domain| is undefined] (new) 

\begin{axiom}
(Integer,Float)
\end{axiom}

\start
Date: Wed, 28 Sep 2005 13:32:29 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#209 The function |Domain| is undefined] 

This domain (renamed from AldorDomain) written in Aldor by Peter
Broadbery::

  ... can still do some useful things with them by disguising the fact
  that they are domains, so in aldor have a type

  AldorDomain: with {
        make: (T: BasicType) -> %
  } == add {
        Rep ==> T;

        make(T: BasicType): % == per T;
  }

  and your aldor programs can return this to axiom.

  Then make sure the interpreter can only see it.

  Of course, it isn't really that useful as it is - there are no
  operations on domains that are documented in aldor, so for example you
  can't say 
        "if T = Integer then ..."
  or
        "findOperation(T, add, (T, T) -> T)"

  The second is handy if you want to write a specialised interpreter, by
  the way.  In any case, you can write a domain like domain.as (see
  below).  All it does is makes sure that axiom sees an object, while
  aldor has a type to play with.  It can be extended to "know" about any
  number of domains.

  Even with these limitations, types and constructors as first class
  objects are pretty powerful.  You can build domains on the fly,
  construct functions, etc. To go further, you need a bit of reflection
  (cf the java lang.reflect stuff for where this is going). People not
  interested in axiom internals should switch off here.

Ref:

  http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00250.html

  http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00248.html

provides some of the missing functionality.

\begin{aldor}[aldordom]
#include "axiom.as"

Domain: BasicType with {
 	make: (T: BasicType) -> %;

	theIntegerType: () -> %;
	map: (%, %) -> %;
	integerMod: PositiveInteger -> %;
	
	coerce: % -> OutputForm;

	name: % -> SExpression;

	lookup: (%, String, %) -> SExpression;

	hashCode: % -> Integer;

} == add {
	import {
		BOOT_:_:DNameToSExpr: SExpression -> SExpression;
		BOOT_:_:hashString: SExpression -> SExpression;
	} from Foreign Lisp;
	
	Rep  ==> Type;
	Rep2 ==> Record(v: Record(domType: SExpression -> SExpression, 
				  domName: SExpression -> SExpression,
				  notUsed: SExpression -> SExpression,
				  lookup:  (SExpression, SExpression, SExpression, 
					    SExpression, SExpression, SExpression,
					    SExpression) -> SExpression,
				  hashCode: SExpression -> SExpression,
				  unknown: SExpression -> SExpression),
			o: SExpression);
	
	import from Rep2;

	make(T: BasicType): % == per T;
	theIntegerType(): % == per Integer;
	integerMod(p: PositiveInteger): % == per(IntegerMod p);

	map(arg: %, ret: %): % == {
		per( (rep arg) -> (rep ret));
	}


	(a: %) = (b: %): Boolean == {
		import from Integer;
		hashCode(a) = hashCode(b)
	}


	coerce(t: %): OutputForm == {
		import from String;
		"<SomeType>"::OutputForm
	}

	name(t: %): SExpression == {
		dom := t pretend Rep2;
		axiomName((dom.v.domName)(dom.o))
	}

	-- nb: cf. interop.boot, basicLookup
	lookup(t: %, name: String, type: %): SExpression == {
		-- lookup takes the following arguments:
		-- domain rep, domain, operation, conspair, flag, lookupFn
		import from List SExpression;
		dom := t pretend Rep2;
		box: SExpression := convert [convert ""];
		lookupFn :=  dom.v.lookup;
		nil := convert [];
		lookupFn(dom.o, 
			 dom pretend SExpression, 
			 hashString(convert name), 
			 convert hashCode(type),
			 box,
			 nil, lookupFn pretend SExpression);
	}

	hashCode(t: %): Integer == {
		dom := t pretend Rep2;
		integer((dom.v.hashCode)(dom.o))
	}

	local axiomName(s: SExpression): SExpression == {
		BOOT_:_:DNameToSExpr(s);
	}

	local hashString(s: SExpression): SExpression == {
		BOOT_:_:hashString(s);
	}
}
\end{aldor}

And it nearly solves the problem!
\begin{axiom}
(Integer,Float)
\end{axiom}

\start
Date: Wed, 28 Sep 2005 15:06:34 -0400
From: Bill Page
To: William Sit
Subject: RE: Types as values, and Re: Static versus Dynamically typed

On Tuesday, September 27, 2005 3:12 AM William Sit wrote:
> ...
> But shouldn't the definition of function (the code, not just
> the signature) be available for manipulation even if the
> function itself is kept constant?
>

This toy example

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

"... provides a function-like type that can be queried for
domain and co-domain."

Of course this is not same as being about to manipulate
the code part of a function. On the other hand in the
Axiom interpreter (which operates closer to lisp then to
Aldor) this is also nearly possible.

Try:

\begin{axiom}
f:Float->INT
f(x) == floor(x)
f(1.1)
f::InputForm
\end{axiom}

Unfortunately Axiom's 'interpret' function is not able to
interpret the InputForm generated for such functions. :( See
issue report:

 #208 interpret(x::InputFor)=x is broken for functions and types

http://wiki.axiom-developer.org/208InterpretXInputForXIsBrokenForFunctio
nsAndTypes

However, my opinion is better to rely on higher-order functions,
e.i. functions that manipulate and return functions in the
manner provided by Aldor and Spad rather than handling the
interpreter's functions in this lispy manner.

Formal results from the theory of programming languages and
category theory show that a language like Aldor that includes
sufficient structure to represent cartesian closed objects and
operations based on typed lambda calculus are equally powerful
to such lower level manipulations.

\start
Date: Wed, 28 Sep 2005 20:56:55 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Language] 

Axiom has both an interactive language or
"interpreter":AxiomInterpreter for user interactions and
a programming language "compiler":ProgrammingAxiom
for building library modules.

  Like Modula 2, PASCAL, FORTRAN, and Ada, the programming
language emphasizes strict type-checking. Unlike these
languages, types in Axiom are dynamic objects: they are
created at run-time in response to user commands.

  The Axiom interactive language is oriented towards
ease-of-use. The Axiom interpreter uses type-inferencing
to deduce the type of an object from user input. Type
declarations can generally be omitted for common types
in the interactive language.

  The Axiom compiler language (version 1 of the language
is called SPAD, version 2 of the language is called [Aldor])
on the other hand is based on strong static types that must
be explicitly specified by the programmer.

Type Inference in the Interpreter

Axiom is very strict with types (meaning: that it must be
completely unambiguous where each operation takes place).
The division of 1+2 by 3 takes place in Fraction Integer
(field of rational numbers) and that is where the answer will
be, even if it is 1. Most people would automatically "retract"
this to the integer 1. But in general, there is no natural
way to do so (why not retract 1 to a natural number, for
example?).  So Axiom provides the user a way to "coerce" an
answer to another type. You can coerce 1 to any of many,
many types, for example, as a polynomial, or even as a
matrix (or the unit element of any ring).

Types of Objects, Domains, and Categories

  In Axiom the concept of "Type" is universally applied at
all levels.

  From the Axiom Book: Appendix B Glossary

  - The type of any category is the unique symbol Category.

  - The type of a domain is any category to which the domain
    belongs.

  - The type of any other object is either the (unique) domain
    to which the object belongs or a subdomain of that domain.

  - The type of objects is in general not unique.

  From the Axiom Book: Technical Introduction

    Every Axiom object is an instance of some domain. That
domain is also called the type of the object. Thus the
typeOf -1 is inferred by the interpret to be Integer and
the typeOf the variable x:Integer is declared to be Integer.
Similarly the typeOf "daniel" is String. The type of an
object, however, is not unique. The type of integer 7 is
not only Integer but also NonNegativeInteger, PositiveInteger,
and possibly, in general, any other *subdomain* of the
domain Integer.

Domains are defined by Axiom by programs of the form::

  Name(Parameters): JoinCategorys
    with Exports == Extends
      add Rep == RepDomain
        Implementation 

The Name of each domain is used to refer to the collection
of its instances. For example, Integer denotes "the integers",
Float denotes "the floating point numbers" etc. For example::

  Fraction(S: IntegralDomain): QuotientFieldCategory S with
       if S has canonical and S has GcdDomain
         and S has canonicalUnitNormal
           then canonical
    == LocalAlgebra(S, S, S) add
      Rep:= Record(num:S, den:S)
      coerce(d:S):% == [d,1]
      zero?(x:%) == zero? x.num

Thus the type of Fraction Integer is 'QuotientFieldCategory
Integer with canonical'. The axiom 'canonical' means that
equal elements of the domain are in fact identical.

We also say that the domain Fraction(s) *extends* the domain
LocalAlgebera(S,S,S). Domains can extend each other in a
circular mutually recursive manner so in general the extends
relationship fors a directed graph with cycles.

Fractions are represented as the domain Record(num:S, den:S).

In Axiom domains and subdomains are themselves objects that
have types. The type of a domain or subdomain is called a
category. Categories are described by programs of the form::

   Name(...): Category == JoinCategorys
     with Exports
      add Imports
        Implementation 

The type of every category is the distinguished symbol
Category. The category Name is used to denote the collection
of domains of that type. For example, category Ring denotes
the class of all rings.

For example::

  QuotientFieldCategory(S: IntegralDomain): Category =    Join(Field, Algebra S, RetractableTo S, FullyEvalableOver S,
         DifferentialExtension S, FullyLinearlyExplicitRingOver S,
           Patternable S, FullyPatternMatchable S) with
      _/     : (S, S) -> %
         ++ d1 / d2 returns the fraction d1 divided by d2.
      numer  : % -> S
         ++ numer(x) returns the numerator of the fraction x.
      denom  : % -> S
      ...
      if S has PolynomialFactorizationExplicit then
        PolynomialFactorizationExplicit
   add
      import MatrixCommonDenominator(S, %)
      numerator(x) == numer(x)::%
      denominator(x) == denom(x) ::%
      ...

Categories say nothing about representation. Domains, which
are instances of category types, specify representations.

Categories form hierarchies (technically, directed-acyclic
graphs). A simplified hierarchical world of algebraic
categories is shown below. At the top of this world is
SetCategory, the class of algebraic sets. The notions of
parents, ancestors, and descendants is clear. Thus ordered
sets (domains of category OrderedSet) and rings are also
algebraic sets. Likewise, fields and integral domains are
rings and algebraic sets. However fields and integral
domains are not ordered sets::

  SetCategory +---- Ring ---- IntegralDomain ---- Field
              |
              +----  Finite    ---+
              |                    \
              +---- OrderedSet -----+ OrderedFinite

  Figure 1. A simplified category hierarchy.

\start
Date: Wed, 28 Sep 2005 21:50:32 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Language] Embedding Axiom categories in	Axiom domains.

In light of the above definitions of 'Type' in Axiom, it
would seem that the type of
\begin{axiom}
I:=Integer
\end{axiom}

which Axiom prints as 'Domain' is actually a 'Category'.
That certainly is confusing terminology... I guess we just
have to remember that whenever we see 'Type: Domain' what
Axiom really means is 'Type: SomeCategory(...)'.

Issue report #209 however shows that *perhaps* it would be
useful to **flatten** Axiom's two-level object model of
categories and domains by embedding Categories into the
domain called Domain. This would allow convenient things
like evaluating the expression::

  (Integer,Float)

as type Tuple(Domain).

As #209 reports, Axiom internally generates a call to the
function '|Domain|' and then fails with an undefined. That
seems peculiarly broken to me and I wonder if the last
commercial version of Axiom has this same behaviour or was
something lost in the porting to the open source gcl-based
version? I thorough search of the current Axiom sources did
not turn up any function, package or domain named 'Domain'.

\start
Date: Wed, 28 Sep 2005 23:59:27 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#209 The function |Domain| is undefined] correct bug in coercion to OutputForm

This domain (based on AldorDomain) written in Aldor by Peter

\begin{aldor}[domain]

Domain: SetCategory with {
        make: (T: BasicType) -> %;

        theIntegerType: () -> %;
        map: (%, %) -> %;
        integerMod: PositiveInteger -> %;

        coerce: % -> OutputForm;

        name: % -> SExpression;

        lookup: (%, String, %) -> SExpression;

        hashCode: % -> Integer;

        import {
                BOOT_:_:hashString: SExpression -> SExpression;
                BOOT_:_:devaluate: SExpression -> SExpression;
        } from Foreign Lisp;

        Rep  ==> Type;
        Rep2 ==> Record(v: Record(domType: SExpression -> SExpression,
                                  domName: SExpression -> SExpression,
                                  notUsed: SExpression -> SExpression,
                                  lookup:  (SExpression, SExpression, SExpression,
                                            SExpression, SExpression, SExpression,
                                            SExpression) -> SExpression,
                                  hashCode: SExpression -> SExpression,
                                  unknown: SExpression -> SExpression),
                        o: SExpression);

        import from Rep2;

        make(T: BasicType): % == per T;
        theIntegerType(): % == per Integer;
        integerMod(p: PositiveInteger): % == per(IntegerMod p);

        map(arg: %, ret: %): % == {
                per( (rep arg) -> (rep ret));
        }


        (a: %) = (b: %): Boolean == {
                import from Integer;
                hashCode(a) = hashCode(b)
        }


        coerce(t: %): OutputForm == {
                import from String;
                name(t)::OutputForm
        }

        name(t: %): SExpression == {
                dom := t pretend SExpression;
                devaluate(dom);
        }

        -- nb: cf. interop.boot, basicLookup
        lookup(t: %, name: String, type: %): SExpression == {
                -- lookup takes the following arguments:
                -- domain rep, domain, operation, conspair, flag, lookupFn
                import from List SExpression;
                dom := t pretend Rep2;
                box: SExpression := convert [convert ""];
                lookupFn :=  dom.v.lookup;
                nil := convert [];
                lookupFn(dom.o,
                         dom pretend SExpression,
                         hashString(convert name),
                         convert hashCode(type),
                         box,
                         nil, lookupFn pretend SExpression);
        }

        hashCode(t: %): Integer == {
                dom := t pretend Rep2;
                integer((dom.v.hashCode)(dom.o))
        }

        local devaluate(s: SExpression): SExpression == {
                BOOT_:_:devaluate(s);
        }

        local hashString(s: SExpression): SExpression == {
                BOOT_:_:hashString(s);
        }

\start
Date: Thu, 29 Sep 2005 03:36:45 -0400
From: Bill Page
To: Peter Broadbery
Subject: RE: types as values, and type internals

Peter,

I am quite interested in your ideas about providing
something equivalent to java.lang.reflect in Aldor and
Axoim. I think this might also be useful to solve the
problem with an undefined function |domain| which appears
when writing for example:

(1) ->  (Integer,Float)

in the Axiom interpreter. If I rename your AldorDomain to
just Domain then the patches below the Tuple of Domains
prints properly, although there are still other problems,
e.g. selection from the Tuple causes a seg fault.

I wonder if the the Rep == Type really makes sense?

On Monday, September 26, 2005 4:41 PM Peter Broadbery wrote:

>
> As usual, should have done a bit more testing; use the
> attached domain2.as - it makes map work a bit better.
>
> a := map(theIntegerType(), theIntegerType())
> lookup(theIntegerType(), "-", a);
>
> works, but axiom will not display the object returned by
> lookup - it's expecting an SExpression (ie a list of lispy
> values), and we're feeding it a more complex structure.
>

The stuff in interop.boot seems very obscure to me but
I am gradually absorbing a little.

Here's a simple patch that actually prints domain names by
calling devaluate() instead of manipulating the domain as
a record structure. There must also be something subtley
wrong with Rep2?

Patch follows:

--------

[page@axiom-developer page]$ diff -au domain2.as.orig domain2.as.new
--- domain2.as.orig     2005-09-29 02:02:13.000000000 -0500
+++ domain2.as.new      2005-09-29 02:02:34.000000000 -0500
@@ -1,6 +1,6 @@
 #include "axiom.as"

-AldorDomain: BasicType with {
+AldorDomain: SetCategory with {
        make: (T: BasicType) -> %;

        theIntegerType: () -> %;
@@ -17,8 +17,8 @@

 } == add {
        import {
-               BOOT_:_:DNameToSExpr: SExpression -> SExpression;
                BOOT_:_:hashString: SExpression -> SExpression;
+                BOOT_:_:devaluate: SExpression -> SExpression;
        } from Foreign Lisp;

        Rep  ==> Type;
@@ -51,12 +51,12 @@

        coerce(t: %): OutputForm == {
                import from String;
-               "<SomeType>"::OutputForm
+               name(t)::OutputForm
        }

        name(t: %): SExpression == {
-               dom := t pretend Rep2;
-               axiomName((dom.v.domName)(dom.o))
+                dom := t pretend SExpression;
+                devaluate(dom);
        }

        -- nb: cf. interop.boot, basicLookup
@@ -81,9 +81,9 @@
                integer((dom.v.hashCode)(dom.o))
        }

-       local axiomName(s: SExpression): SExpression == {
-               BOOT_:_:DNameToSExpr(s);
-       }
+        local devaluate(s: SExpression): SExpression == {
+                BOOT_:_:devaluate(s);
+        }

        local hashString(s: SExpression): SExpression == {
                BOOT_:_:hashString(s);

\start
Date: Thu, 29 Sep 2005 03:30:00 -0500
From: MathAction (unknown)
To: MathAction
Subject: [TeXmacs] Using TeXmacs

I've just compiled Axiom 3.9 (and texmacs 1.0.5.9) on a RH EL system. Both installed to non standard locations.
While command line axiom works, and texmacs presents an axiom session (and actually launches axiom), I did not manage to get axiom working from within texmacs (I get no line promt ->, and when I press the ENTER key nothing happens, no evaluation, nothing). 

Forgive my stupidity but ... any help??


brunelli@itc.it

\start
Date: Thu, 29 Sep 2005 03:30:06 -0600
From: Alan Eliasen
To: list
Subject: Re: [Frink] Units

Tim Daly wrote:
> On the Axiom mailing list we have been discussing this particular topic.
> Axiom is a free, general purpose computer algebra system similar in
> scope and power to Mathematica and Maple. It does not currently support
> Units or Dimensions on input values but this is being discussed.
> (see http://page.axiom-developer.org)
>
> I see that the software is "free" but I couldn't find the source
> anywhere. I was hoping to learn what you've already done so I could
> have a better reference point than my own, uneducated opinion. Is
> the source available for study?

   I'll post my initial response to both of the lists you referenced in
the original mail, as Frink users might be interested in how units are
implemented in Frink.  Follow-ups should probably be directed to one
list or another, or to me personally.

   The source for Frink is currently not available, but I think it's
more useful to talk about the high-level design decisions rather than
particulars of implementation, which may change.

   As you know, there are lots of different ways that units and
dimensions could be implemented, and a lot of tradeoffs in performance,
memory usage, complexity, reversibility, and flexibility.  I've seen
implementation

   As noted in your mailing lists, I described the implementation
somewhat in my talk at the Lightweight Languages 4 conference at MIT.
The slides and video are available at:
http://futureboy.us/frinkdocs/LL4.html

   Some design goals are:

   * Avoid hard-coding of any units of measure or dimensions.  The
number and base dimensions should be specified at run-time by a
configurable units file.

   * Try to make all operations constant-time.

   * Allow adding of base dimensions at runtime.  This is, in practice,
very rare and often ill-advised, (in fact, I've *never* had to do it,)
but may be a useful construct in some cases.

   * Allow for a variety of implementations.  In Java, this translates
to defining everything as an interface, and keeping each interface as
simple as possible.

   Some philosophies:

   * It makes absolutely no difference what your internal representation
 or base dimensions are.  That's just a display-time issue.  The user
should either 1.) ask for results in specific units (which provides an
important check that dimensions are what they expect) 2.) Set default
display units, see http://futureboy.us/frinkdocs/#SettingDisplayUnits
3.) define their own unit file with the dimensions they like to use, or
4.) accept what comes out.

   * Don't try to solve the case of non-linear units within your system.
  Fahrenheit, Celsius, decibel, stellar magnitude, etc., are examples of
non-linear units with nonsensical zero points.  Frink implements these
as functions which require the user to understand the difference between
these units and ordinary linear units.  Doing anything else requires
reading minds, which is destined to fail.

   There are lots of ways that units could be implemented.  My
implementation can be described succinctly.  Every unit is a combination
of a magnitude (as a multiple of some base dimensions) and a list of
dimensions and their exponents.

   The decision to immediately reduce all values to multiples of some
base dimensions was chosen for performance and simplicity of coding.  It
has the disadvantage of going through a potential longer chain of
multiplications than if you kept the relations in a graph.  If these
multiplications are irreversible, like with most floating-point
implementations, this can cause problems or precision loss.  Frink tries
to avoid this by maintaining exact rational numbers when possible.
(e.g. an inch is defined as exactly 254/100 cm.)

   The standard data file uses SI base units as the base dimensions.
This is, of course, configurable at run-time:
   http://futureboy.us/frinkdocs/LL4.html#slide17

The Unit interface:
   http://futureboy.us/frinkdocs/LL4.html#slide20

The DimensionList interface:
http://futureboy.us/frinkdocs/LL4.html#slide19

   The DimensionList interface tends to imply that you have an array of
integers which represent exponents.  This was done for simplicity and
performance, but it could be implemented alternately with a linked list
and a more complex enumerator and data structure returned, but this
would likely be slower.  This interface has one minor optimization in
it.  The getHighestIndex() method returns the highest index *used* for
that particular DimensionList, allowing quicker array operations,
especially if the most-used dimensions were defined first.  It also
allows you to add dimensions at runtime with no penalty.

   A class called DimensionManager keeps track of all of the base
dimensions (defined by a simplistic interface called Dimension) and
their names, base units, and index numbers.  As a concession to
efficiency, each fundamental dimension has an index associated with it.
 The first dimension added has a number of 0, and this increases by one
for each dimension added.  This number is guaranteed not to change over
the course of a run, but may change across runs.

   To allow implementations of some of these interfaces to be as minimal
as possible, without deriving from another class, math on Units and
DimensionLists are performed by other classes which use the methods
defined by these interfaces to perform all necessary operations.

   I know that this is a rather terse discussion, but hopefully it will
be helpful.  My primary recommendation is to not make your
implementation more complex than need be.  Implementing units really can
be quite simple.  Please let me know if you have more specific questions.

   Other references:
   * JSR-108, a Java Community Process proposal for implementing Units
in Java.  This was withdrawn by the leader in 2004.  In my opinion, it's
overly complex and hard-coded.  http://jsr-108.sourceforge.net/

-- 
  Alan Eliasen                 |  "It's amazing how much mature wisdom
  Alan Eliasen       |   resembles being too tired."
  http://futureboy.homeip.net/ |     -- Robert Heinlein

\start
Date: Thu, 29 Sep 2005 09:20:01 -0700 (PDT)
From: Cliff Yapp
To: Alan Eliasen
Subject: re: [Frink] Units

--- Alan Eliasen wrote:

> I'll post my initial response to both of the lists you referenced in
> the original mail, as Frink users might be interested in how units
> are implemented in Frink.  Follow-ups should probably be directed to 
> one list or another, or to me personally.
> 
>    The source for Frink is currently not available, but I think it's
> more useful to talk about the high-level design decisions rather than
> particulars of implementation, which may change.

Agreed.  An Axiom implementation of units and dimensions would have to
be done in Axiom anyway, so I'm not terribly worried about source code.

>    As you know, there are lots of different ways that units and
> dimensions could be implemented, and a lot of tradeoffs in
> performance, memory usage, complexity, reversibility, and 
> flexibility.

Indeed.

>    As noted in your mailing lists, I described the implementation
> somewhat in my talk at the Lightweight Languages 4 conference at MIT.
> The slides and video are available at:
> http://futureboy.us/frinkdocs/LL4.html
> 
>    Some design goals are:
> 
>    * Avoid hard-coding of any units of measure or dimensions.  The
> number and base dimensions should be specified at run-time by a
> configurable units file.

IIRC the current thought on that is to define tables in Axiom for
unitsystems with the required conversion factors, but that has not yet
been thoroughly discussed, and there is some thinking to do when it
comes to handling things like the Natural (Planck) UnitSystem, which
doesn't really seem to HAVE basic dimensions.

>    * Try to make all operations constant-time.

You mean in execution time?

>    * Allow adding of base dimensions at runtime.  This is, in
> practice, very rare and often ill-advised, (in fact, I've *never* 
> had to do it,) but may be a useful construct in some cases.

I have some thoughts about that, but it's down the road.

>    * Allow for a variety of implementations.  In Java, this
> translates to defining everything as an interface, and keeping each
> interface as simple as possible.

What do you mean by implementations?  Different unit and dimensional
systems?

>    Some philosophies:
> 
>    * It makes absolutely no difference what your internal
> representation or base dimensions are.  

Well, we want to define things in a way that makes interesting
operations simple, so to the extent internal representation impacts
that it can be important.

> * Don't try to solve the case of non-linear units within your
> system.   Fahrenheit, Celsius, decibel, stellar magnitude, etc., 
> are examples of non-linear units with nonsensical zero points.  
> Frink implements these as functions which require the user to 
> understand the difference between these units and ordinary linear 
> units.  Doing anything else requires reading minds, which is 
> destined to fail.

Not sure about this - how is reading minds required?  It's somewhat
fancier conversion logic, granted, but I'm not seeing how it's
fundamentally different except perhaps for the necessity of
establishing the illegality of temperatures below O deg K, -273 deg C,
etc.
 
>    There are lots of ways that units could be implemented.  My
> implementation can be described succinctly.  Every unit is a
> combination of a magnitude (as a multiple of some base dimensions) 
> and a list of dimensions and their exponents.
> 
>    The decision to immediately reduce all values to multiples of some
> base dimensions was chosen for performance and simplicity of coding. 

Yes, that's essentially the approach I take in my attempt at a Maxima
units package.

> It has the disadvantage of going through a potential longer chain of
> multiplications than if you kept the relations in a graph.  If these
> multiplications are irreversible, like with most floating-point
> implementations, this can cause problems or precision loss.  Frink
> tries to avoid this by maintaining exact rational numbers when
> possible. (e.g. an inch is defined as exactly 254/100 cm.)

How do you handle things like radians?  Work vs. Moment of Force, for
example?

> I know that this is a rather terse discussion, but hopefully it
> will be helpful.  My primary recommendation is to not make your
> implementation more complex than need be.  Implementing units really
> can be quite simple.  Please let me know if you have more specific
> questions.

Hehe - I'm in trouble.  My goal is to handle units and dimensions
"correctly." (I'm still learning what "correct" is.)  I agree that
unnecessary complexity is generally undesirable, but I have a feeling
Axiom is going to go a lot deeper into various issues than is "normal."

>    Other references:
>  * JSR-108, a Java Community Process proposal for implementing
> Units in Java.  This was withdrawn by the leader in 2004.  In my 
> opinion, it's overly complex and hard-coded.  
> http://jsr-108.sourceforge.net/

\start
Date: Thu, 29 Sep 2005 12:40:36 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Language] Embedding Axiom categories in	Axiom domains.

Confusion of Type and Domain

  The most basic category is 'Type'. It denotes the collection
of all domains and subdomains. Note carefully that 'Type' does
not denote the class of all types! The type of all categories
is 'Category'. The type of 'Type' itself is undefined. For
example: the domain List is able to build "lists of elements
from domain D" for arbitrary D simply by requiring that D
belong to category 'Type'.

Another example.  Enter the type 'Polynomial (Integer)' as an
expression to Axiom. This looks much like a function call
as well. It is! The result is stated to be of type 'Domain',
which denotes the collection of all domains.

\begin{axiom}
Polynomial(Integer)
\end{axiom}

But note well that 'Domain' is a domain but 'Type' is a
category. !!!?

Ref: Axoim Book "Chapter 2 Using Types and Modes".

\start
Date: Thu, 29 Sep 2005 12:57:22 -0500
From: MathAction (billpage)
To: MathAction
Subject: [FrontPage] 

Axiom also supports [Aldor] as the new library compiler</td></tr>

\start
Date: Thu, 29 Sep 2005 12:55:46 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Aldor] (new) 

Aldor is a computer programming language, like Scheme, Java or C#.

The site http://www.aldor.org provides information about the Aldor
programming language, its compiler and libraries, as well as downloads
for software and documentation.

>From a technical point of perspective, Aldor is a type-complete,
strongly-typed, imperative programming language with a two-level
object model of categories and domains (similar to the concept of
interfaces and classes in Java). Types and functions are first class
entities allowing them to be constructed and manipulated within
Aldor programs just like any other value. Pervasive use of dependent
types allows static checking of dynamic objects and provides
object-oriented features such as parametric polymorphism.  

What does this mean for a normal user? Aldor solves many difficulties
encountered with certain widely-used object-oriented programming
languages. It allows programs to use a natural style, combining the
more attractive and powerful properties of functional, object-oriented
and aspect-oriented styles.

Over View

The original motivation for Aldor was to provide an improved
extension language for the AXIOM computer algebra system: The
language had to be expressive enough to capture naturally the
high-level objects and relationships which arise in modern
mathematics. An implementation had to be efficient enough for
intense symbolic and numeric computing needs. And the language
had to be modular enough to allow large libraries of independently
developed facilities to be used together in any combination.

The formulation of the programming language has tried to balance
the mathematical desire for generality and uniformity, on one
hand, with the practical requirements of the most demanding
symbolic and numeric computation, on the other. For example,
types and functions are first class values, and dependent
types are fully supported, but the precise formulation of has
been carefully arranged to allow effective optimizaiton. Post
facto extensions allow libraries to be built in layers by
enriching existing objects, rather than introducing a
proliferation of variations. Both object-oriented and
functional programming styles are reconstructed naturally
form these basic semantic elements.

The Aldor compiler can be used to generate code which runs
within the Axiom system, separately, or linked into other
applications.

The compiler was available as part of the Axiom system from
1994 to 1999 and was then released as an independent language.

During its development at IBM Research, this programming
language was known internally as *A#* (A sharp) however that
name now refers to a version of Ada. The interim name "AXIOM-XL"
(Axiom Library Compiler) was used for a short period by NAG
before the legal trade name "Aldor" was established.

See also: [Aldor For Axiom]

\start
Date: Thu, 29 Sep 2005 14:13:04 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Language] The domain Domain?

There are numerous places in the Axiom BOOT code that seems to
treat this name in a special manner as if it might be "built-in".
Eg. ::

  interp/bootfuns.lisp.pamphlet:(def-boot-val |$Domain| '(|Domain|)        
  interp/br-con.boot.pamphlet:    is [[h,:.],:t] and MEMBER(h,'(Domain SubDomain))
  interp/clammed.boot.pamphlet:  form in '((Mode) (Domain) (SubDomain (Domain))) = 
  interp/g-cndata.boot.pamphlet:      domain in '((Mode) (Domain) (SubDomain (Doma
  interp/i-analy.boot.pamphlet:  if ( oo = "%" ) or ( oo = "Domain" ) or ( domainF
  interp/i-coerce.boot.pamphlet:    t1 in '((Mode)  (Domain) (SubDomain (Domain))) =>
  interp/i-funsel.boot.pamphlet:  MEMBER('(SubDomain (Domain)),types1) => NIL
  interp/i-output.boot.pamphlet:  categoryForm? domain or domain in '((Mode) (Domain) (SubDomain (Domain))) =>
  interp/i-spec1.boot.pamphlet:  saeTypeSynonymValue := objNew(sae,'(Domain))
  interp/i-spec1.boot.pamphlet:  objMode triple = '(Domain) => triple
  interp/i-spec1.boot.pamphlet:      objMode(val) in '((Domain) (SubDomain (Domain))) =>
  interp/i-spec2.boot.pamphlet:    else if categoryForm?(type) then '(SubDomain (Domain))
  interp/i-spec2.boot.pamphlet:  type in '((Mode) (Domain)) => '(SubDomain (Domain))
  interp/parse.boot.pamphlet:        and m in '((Mode) (Domain) (SubDomain (Domain))) => D
  interp/setq.lisp.pamphlet:  CAPSULE |Union| |Record| |SubDomain| |Mapping| |Enumeration| |Domain| |Mode|))
  interp/setq.lisp.pamphlet:(SETQ |$Domain| '(|Domain|))
  interp/sys-pkg.lisp.pamphlet:    BOOT::YIELD BOOT::|Polynomial| BOOT::|$Domain| BOOT::STRINGPAD
  interp/trace.boot.pamphlet:      (objMode value in '((Mode) (Domain) (SubDomain (Domain)))) =>

However in searching for use and meaning of the domain 'Domain',
in all the Axiom algebra library I can find only one place that
explicity uses this domain.

In 'algebra/forttyp.spad.pamphlet' in the domain 'TheSymbolTable'
it reads::

    Entry : Domain  := Record(symtab:SymbolTable, _
                              returnType:FSTU, _
                              argList:List Symbol)

For details see [SandBox Domains And Types].

So apparently at least in 1992, such a domain might have existed
in Axiom.

Oddly (or perhaps as we might expect :) compiling this code in
the current version of Axiom produces some error messages::

   Semantic Errors: 
      ![1]  Domain is not a known type
      ![2]  void is not a known type

yet the compile does apparently successfully complete. But
does it work?

\start
Date: Thu, 29 Sep 2005 20:21:26 +0100
From: Peter Broadbery
To: list
Subject: RE: types as values, and type internals

On Thu, 2005-09-29 at 03:36 -0400, Page, Bill wrote:
> Peter,
> 
> I am quite interested in your ideas about providing
> something equivalent to java.lang.reflect in Aldor and
> Axoim. I think this might also be useful to solve the
> problem with an undefined function |domain| which appears
> when writing for example:
> 
> (1) ->  (Integer,Float)
> 

It was written mostly to show that you could do some operations on
domains - effectively allowing one to write more of an interpreter in
the extension language.  I'm not 100% confident of what the definitions
of "Domain", "SubDomain", "Category" and "Type" should be, so was
avoiding them.

If we can find a way that these can fit together and allow axiom to deal
with them coherently it would definitely be a good thing, but I'm not
sure I'm qualified to decide exactly what the semantics should be. 

> I wonder if the the Rep == Type really makes sense?
> 

I think Rep ==> Type is more or less honest, given that a Type is an
object in the aldor world view. A  caveat is that it captures categories
(and "Type") as well as domains.  

> On Monday, September 26, 2005 4:41 PM Peter Broadbery wrote:
> 
> > 
> > As usual, should have done a bit more testing; use the
> > attached domain2.as - it makes map work a bit better.
> > 
> > a := map(theIntegerType(), theIntegerType())
> > lookup(theIntegerType(), "-", a);
> > 
> > works, but axiom will not display the object returned by
> > lookup - it's expecting an SExpression (ie a list of lispy
> > values), and we're feeding it a more complex structure.
> > 
> 
> The stuff in interop.boot seems very obscure to me but
> I am gradually absorbing a little.
> 

Yes - it is obscure.  Unfortunately it seemed to be the best solution at
the time, and then we hacked it about a little.  The trick is to try and
untangle it again.  There are (at least) two ways domains are treated -
one is as S-Expression, eg (|List| (|Integer|)) and the other is the
aldor "Rep2" object - in general axiom code handles both, while aldor
will only accept the latter.

> Here's a simple patch that actually prints domain names by
> calling devaluate() instead of manipulating the domain as
> a record structure. There must also be something subtley
> wrong with Rep2?
> 

Devaluate should be equivalent for all domains.  Ah, Mappings aren't
quite domains, since  'isDomain' fails for them.  Not sure what the
underlying bug is though. 

> Patch follows:
> 
> --------
> 
> [page@axiom-developer page]$ diff -au domain2.as.orig domain2.as.new
> --- domain2.as.orig     2005-09-29 02:02:13.000000000 -0500
> +++ domain2.as.new      2005-09-29 02:02:34.000000000 -0500
> @@ -1,6 +1,6 @@
>  #include "axiom.as"
> 
> -AldorDomain: BasicType with {
> +AldorDomain: SetCategory with {
>         make: (T: BasicType) -> %;
> 
>         theIntegerType: () -> %;
> @@ -17,8 +17,8 @@
> 
>  } == add {
>         import {
> -               BOOT_:_:DNameToSExpr: SExpression -> SExpression;
>                 BOOT_:_:hashString: SExpression -> SExpression;
> +                BOOT_:_:devaluate: SExpression -> SExpression;
>         } from Foreign Lisp;
> 
>         Rep  ==> Type;
> @@ -51,12 +51,12 @@
> 
>         coerce(t: %): OutputForm == {
>                 import from String;
> -               "<SomeType>"::OutputForm
> +               name(t)::OutputForm
>         }
> 
>         name(t: %): SExpression == {
> -               dom := t pretend Rep2;
> -               axiomName((dom.v.domName)(dom.o))
> +                dom := t pretend SExpression;
> +                devaluate(dom);
>         }
> 
>         -- nb: cf. interop.boot, basicLookup
> @@ -81,9 +81,9 @@
>                 integer((dom.v.hashCode)(dom.o))
>         }
> 
> -       local axiomName(s: SExpression): SExpression == {
> -               BOOT_:_:DNameToSExpr(s);
> -       }
> +        local devaluate(s: SExpression): SExpression == {
> +                BOOT_:_:devaluate(s);
> +        }
> 
>         local hashString(s: SExpression): SExpression == {
>                 BOOT_:_:hashString(s);
> 

\start
Date: Thu, 29 Sep 2005 14:46:28 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Language] The domain Domain?

'typeOf -1' is inferred by the interpret to be 'Integer' and
the 'typeOf' the variable 'x:Integer' is declared to be 'Integer'.
Similarly the 'typeOf "daniel"' is 'String'. The type of an
object, however, is not unique. The type of integer '7' is
not only 'Integer' but also 'NonNegativeInteger', 'PositiveInteger',

domain 'Integer'.

\start
Date: Thu, 29 Sep 2005 14:50:38 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Language] The domain Domain?

Categories say nothing about representation. Domains, which are
instances of category types, specify representations. See also
[Rep And Per].

\start
Date: Thu, 29 Sep 2005 14:54:29 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [Axiom Language] The domain Domain?

example: the domain 'List' is able to build "lists of elements

\start
Date: Thu, 29 Sep 2005 17:48:02 -0400
From: Bill Page
To: Peter Broadbery
Subject: RE: types as values, and type internals

On Thursday, September 29, 2005 3:21 PM Peter Broadbery wrote:
> ...
> It was written mostly to show that you could do some
> operations on domains - effectively allowing one to write
> more of an interpreter in the extension language.  I'm not
> 100% confident of what the definitions of "Domain",
> "SubDomain", "Category" and "Type" should be, so was
> avoiding them.

It seems that that might have been the prevailing approach
in the latter stages of Axiom's development - a pity
considering Axiom's otherwise quite noble objectives
concerning mathematical rigor. ;) Seriously, this issue
does give me a headache that I would like to releave.

>
> If we can find a way that these can fit together and allow
> axiom to deal with them coherently it would definitely be
> a good thing, but I'm not sure I'm qualified to decide
> exactly what the semantics should be.

I agree that it would be a very good thing, but if you are
not sure you are qualified, then I am not sure that I am
even qualified to have an opinion! :)

>
> > I wonder if the Rep == Type really makes sense?
> >
>
> I think Rep ==> Type is more or less honest, given that
> a Type is an object in the aldor world view. A caveat is
> that it captures  categories (and "Type") as well as domains.

Hmmm. Ok so when I am writing Aldor code in Axiom I (for
the most part) have this "aldor world view", right? So Type
is something native to Aldor?

In the Axiom interpret if I write:

  (1) -> Type

     (1)  Type
                                     Type: SubDomain Domain

It answers with a Type for Type that is hard for me to
understand ... especially considering that the Axiom Book
specifically says that the Type of Type is undefined. :(

Anyway, am I correct then to understand that

   Rep ==> Type

here means that we are going to 'pretend' about something
that is assumed to have a structure directly understood
by Aldor? Doesn't that mean that anything like:

          name(t: %): SExpression == {
  -               dom := t pretend Rep2;
  -               axiomName((dom.v.domName)(dom.o))
  +               dom := t pretend SExpression;
  +               devaluate(dom);

that just pretends that something passed from Axiom has
such a structure would be rather dangerous? Instead we
would have to ask Axiom to do some kind of explicit
conversion to the Rep2 structure, right? Perhaps that
explains why the original code for name above (-) failed?

Notice how many question marks I wrote in the above
paragraph? :) That's how certain I am about all this
so please forgive me if my writing seems overly pedantic.

Given that in the AldorDomain code you write:

   theIntegerType(): % == per Integer;

what is the difference in the interpreter when I write:

  (1) -> A:=Integer

     (1)  Integer
                                           Type: Domain
  (2) -> B:=theIntegerType()

     (2)  (Integer)
                                        Type: AldorDomain

Is there a difference in the internal representations?

BTW, do you know why the (parenthesis) appear the result?

> >
> > The stuff in interop.boot seems very obscure to me but
> > I am gradually absorbing a little.
> >
>
> Yes - it is obscure.  Unfortunately it seemed to be the
> best solution at the time, and then we hacked it about
> a little.  The trick is to try and untangle it again.

Yes.

> There are (at least) two ways domains are treated -
> one is as S-Expression, eg (|List| (|Integer|)) and the
> other is the aldor "Rep2" object - in general axiom code
> handles both, while aldor will only accept the latter.
>
> > Here's a simple patch that actually prints domain names
> > by calling devaluate() instead of manipulating the domain
> > as a record structure. There must also be something
> > subtly wrong with Rep2?
> >

Aha. See my question above about name function. So I guess
it is just a matter of knowing which sturcture to use
and when to convert, right?

>
> Devaluate should be equivalent for all domains.  Ah,
> Mappings aren't quite domains, since  'isDomain' fails
> for them. Not sure what the underlying bug is though.

If I write Domain instead of AldorDomain in your code and
compile it then I can write

  (1) -> (Integer, Float)

     (1)  [(Integer),(Float)]
                                        Type: Tuple Domain

  (2) -> ((Integer->Float),(Float->Integer))

     (2)  [(Mapping (Float) (Integer)),
                    (Mapping (Integer) (Float))]
                                        Type: Tuple Domain

it looks as if Mapping is understood by the interpreter but
the coerce to OutputForm from Tuple doesn't seem to be doing
such a good job.

\start
Date: Thu, 29 Sep 2005 18:43:39 -0600
From: Alan Eliasen
To: Cliff Yapp
Subject: re: [Frink] Units

   I'll try writing this again.  After composing this once, I had a mail
client crash.

C Y wrote:
> IIRC the current thought on that is to define tables in Axiom for
> unitsystems with the required conversion factors, but that has not yet
> been thoroughly discussed, and there is some thinking to do when it
> comes to handling things like the Natural (Planck) UnitSystem, which
> doesn't really seem to HAVE basic dimensions.

   The Planck unit system does indeed have orthogonal basic dimensions,
but this case raises an interesting point.  If you're going to use the
Planck system, you need to allow exponents of your dimensions to take on
rational values as well as integer values.  Frink doesn't allow this
currently, for performance reasons, but it may someday.  I've built unit
systems for other languages (see
http://cadswes.colorado.edu/PDF/RiverWare/WehrendPhd_Thesis2002.pdf )
and we found that our users had some units/constants defined in "square
root of length" and so on.

>>   * Try to make all operations constant-time.
> 
> You mean in execution time?

   Yes.  There are other ways of representing relations between units
(such as in a graph) that reduce floating-point error, but these will be
slower.

>>   * Allow for a variety of implementations.  In Java, this
>>translates to defining everything as an interface, and keeping each
>>interface as simple as possible.
> 
> What do you mean by implementations?  Different unit and dimensional
> systems?

   By this I mean different classes implementing the same interface.

>>   Some philosophies:
>>
>>   * It makes absolutely no difference what your internal
>>representation or base dimensions are.  
> 
> Well, we want to define things in a way that makes interesting
> operations simple, so to the extent internal representation impacts
> that it can be important.

   I see this as a model-view distinction.

>>* Don't try to solve the case of non-linear units within your
>>system.   Fahrenheit, Celsius, decibel, stellar magnitude, etc., 
>>are examples of non-linear units with nonsensical zero points.  
>>Frink implements these as functions which require the user to 
>>understand the difference between these units and ordinary linear 
>>units.  Doing anything else requires reading minds, which is 
>>destined to fail.
> 
> Not sure about this - how is reading minds required?  It's somewhat
> fancier conversion logic, granted, but I'm not seeing how it's
> fundamentally different except perhaps for the necessity of
> establishing the illegality of temperatures below O deg K, -273 deg C,
> etc.

   Let me illustrate the difference through an erroneous news report
that a friend sent to me:

-----begin quote ----------------
The extended hot spell has seen temperatures cross the 50 degrees
Celsius (122 Fahrenheit) mark. Media reports said the temperature hit
52.1 degrees Celsius (125.8 Fahrenheit) in the northern town of
Kottagudam on Monday.

The temperatures are about five to seven degrees Celsius (41 to 44.6
Fahrenheit) above normal.
------end quote -----------------

   What's wrong with those conversions?

   The difference is important, so I've decided, rather than guessing
what the user means, and often guessing wrong, to be a little pedantic,
and show them how their calculation may be ambiguous, and showing them
how to fix it.

   After all, if I help someone to learn something, and think and
communicate more clearly, I've done my job.  I don't try to read minds,
and guess drastically wrong sometimes like the Google calculator does.

   Case in point.  Try to guess in advance what the Google Calculator
will return for each the following:

   1 F + 1 C
   1 K + 1 F
   1 K + 1 F + 1 F
   1 K + 2 F
   1 F + 1 F
   1 F / 1 C
   1 K - 1 C
   1 K / 1 C

   I prefer unambiguity and a wee bit of pedantry over such
unpredictable behavior.  Better to teach a man to fish, than quietly
slip a squid in his pants...

   Also see:

http://futureboy.us/frinkdocs/faq.html#ParenthesesAroundRight

> How do you handle things like radians? 

   Radians are dimensionless numbers.  (I had a high-school teacher
repeat this three times in a row, and I realize he was talking to me.)
In the standard data file, radians are defined as 1.  However, if you
read the standard data file, you'll see how to easily make radians their
own base dimension.  I don't do this because it 1.) introduces
artificiality into calculations.  You end up multiplying and dividing by
radians in calculations just to make the units come out "right," when
they really were already right.  2.) Frink, by default, uses the base
dimensions defined by the SI.  The SI threw out radians and steradians
as base units in 1973 for similar reasons.

   That said, Frink is otherwise radians-correct.  If you change a
couple of lines in the standard data file, it enforces that arguments to
functions like sin[x] have angular dimensions, and functions like
arcsin[x] will return values with dimensions of radians.  All angular
measures will have dimensions of radians (or you can even make degrees
or gradians into the base angular type, and it'll all still work correctly.)

   Doing this properly affects the implementation of all trigonometric
functions, by the way.

   However, radians really are dimensionless numbers, and treating them
as if they're something different usually makes your calculations
unwieldy.  I allow it, and designed for it, but discourage its use.

> Work vs. Moment of Force, for
> example?

   Since these have the same units of measure, they're internally
identical.  The only time that the *name* comes into play is when Frink
prints out its "helpful" name for that combination of dimensions, or
when constraining a variable by dimensions:
http://futureboy.us/frinkdocs/#ConstrainingByDimensions

   The name is otherwise unimportant.  Right now it's a 1:1 mapping,
which I might change.

> Hehe - I'm in trouble.  My goal is to handle units and dimensions
> "correctly." (I'm still learning what "correct" is.)  I agree that
> unnecessary complexity is generally undesirable, but I have a feeling
> Axiom is going to go a lot deeper into various issues than is "normal."

   One of the most important suggestions that I can give you to help you
be "correct" is to follow the SI guidelines for reading *and* parsing
units of measure:

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

   These are largely unambiguous and machine-parseable.  Frink follows
these rules as its Prime Directives for "correct" usage, and the parsing
and default display routines were written appropriately.

   My tactic is "when in doubt, be pedantic."  Help your users to write
and read units of measure correctly, and you'll teach them something,
and make yourself and them look better.  If their input is ambiguous,
don't try to silently "do what I mean" and guess wrong.  Stop them and
make them write it "correctly."  Also, don't try to follow the Fortress
( http://lambda-the-ultimate.org/node/view/883 ) tactics of reinventing
the rules of mathematical precedence!

   I hope this is helpful.

-- 
  Alan Eliasen                 |  "It's amazing how much mature wisdom
  Alan Eliasen       |   resembles being too tired."
  http://futureboy.homeip.net/ |     -- Robert Heinlein

\start
Date: Thu, 29 Sep 2005 23:10:04 -0400
From: Camm Maguire
To: list
Subject: GCL 2.6.8pre
Cc: James Amundson, Matt Kaufmann

Greetings!  In the process of releasing new Debian packages of maxima,
acl2 and axiom against gcl 2.6.7 and gcc 4.0, it has come to my
attention that there are a few errata which are prompting me to work
toward a 2.6.8 cleanup release in the near future.

Here are the primary fixes:

1) fedora has changed their address randomization again.  2.6.8pre and
   later should build on fc4 and earlier out of the box.  Thanks to
   Juho Snellman for the critical info.

2) The compiler::link build mechanism used by machines without native
   object relocation yet implemented had sufferred a bit of bit rot,
   and is now made considerably more robust.  It had earlier rather
   primitively assumed that the source and object files were in the
   same directory and were not moved before invoking compiler::link.
   Now the init function name is read from the binary object file
   itself rather than deduced from the pathname.  This restores maxima
   acl2 and axiom on mips mipsel alpha ia64 and hppa.

   This list will shrink at least to just ia64 and hppa with 2.7.0.
   As this list can shrink and grow in the future as well, it would
   make sense to avoid having to change all 4 programs in each such
   instance.  Therefore I recommend that we conditionalize the build
   based on the #+-native-reloc feature which GCl sets as appropriate.

   maxima already has an --enable-gcl-alt-link configure option.  I
   recommend merging this with the traditional option and
   conditionalizing the two code sets with #-native-reloc and
   #+native-reloc respectively.

   acl2 already has the dlopen file Matt and I have worked on
   together.  The latest Debian package does something like this:

saved_acl2: debian/patches_applied $(DLOPEN_T)
	gcl -batch -eval "(bye #-native-reloc 1)" || \
		(gcl -batch -eval '(load "debian/dlopen.lisp")' &&  $(MAKE) do_saved)
	gcl -batch -eval "(bye #+native-reloc 1)" || $(MAKE) LISP=gcl
	mv *$@.gcl $@
 
   Perhaps the equivalent can be placed in acl2's own makefiles?

   axiom had a set up patches which were used by Debian only on the
   required platforms, and BSD everywhere for a while. (The
   compiler::link alternate build mechanism works and can be tested on
   all GCL platforms, but is only required where native object
   relocation is absent.)  Here is the patch I'm using in the latest
   debian upload:

============================================================================--- ./lsp/Makefile.pamphlet.~1.5.~	2005-09-05 18:50:31.000000000 +0000
+++ ./lsp/Makefile.pamphlet	2005-09-20 21:20:10.000000000 +0000
@@ -1012,14 +1012,7 @@
 	@echo 1 building ${LSP} ${GCLVERSION}
 
 gcldir: 
-	@echo 2 building ${GCLVERSION}
-	@tar -zxf ${ZIPS}/${GCLVERSION}.tgz
-<<gcl-2.6.7.socket.patch>>
-<<gcl-2.6.7.libspad.patch>>
-<<gcl-2.6.7.toploop.patch>>
-<<gcl-2.6.7.tail-recursive.patch>>
-<<gcl-2.6.7.collectfn.fix>>
-<<gclConfigureMake>>
+	echo '(compiler::link nil "${OUT}/lisp" (format nil "(progn (let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t))(when (fboundp (quote si::sgc-on)) (si::sgc-on t))#-native-reloc(setq compiler::*default-system-p* t))" si::*system-directory* (quote (list #+native-reloc".o" ".lsp"))) "${OBJ}/${SYS}/lib/cfuns-c.o ${OBJ}/${SYS}/lib/sockio-c.o ${OBJ}/${SYS}/lib/libspad.a")' | gcl
 	@echo 13 finished system build on `date` | tee >gcldir
 
 ccldir: ${LSP}/ccl/Makefile
--- ./src/algebra/Lattice.pamphlet.orig	2005-01-04 23:45:59.000000000 +0000
+++ ./src/algebra/Lattice.pamphlet	2005-02-14 18:45:10.000000000 +0000
@@ -39620,13 +39620,14 @@
 	@ cp -p ${SRC}/doc/gloss.text ${LIB}
 	@ cp -p ${SRC}/doc/topics.data ${MID}
 	@ echo rebuilding daase files
-	@ (cd ${MID} ; \
-	   echo ')set out le 200' >/tmp/tmp.input ; \
-	   echo ')fin' >>/tmp/tmp.input ; \
-	   echo '(make-databases "" (QUOTE ("unix")))' >>/tmp/tmp.input ; \
-	   echo '(bye)' >>/tmp/tmp.input ; \
-	   cat /tmp/tmp.input | ${INTERPSYS} ; \
-	   rm -f /tmp/tmp.input )
+	@ (cd ${MID} ; \
+	   echo ')set out le 200' >/tmp/tmp.input ; \
+	   echo ')fin' >>/tmp/tmp.input ; \
+	   echo "#+native-reloc(make-databases \"\" (QUOTE (\"unix\")))#-native-reloc(system \"cp ${SRC}/../debian/*.daase ${MID}\")" >>/tmp/tmp.input ; \
+	   echo '(bye)' >>/tmp/tmp.input ; \
+	   cat /tmp/tmp.input | ${INTERPSYS} ; \
+	   rm -f /tmp/tmp.input )
+#	@ (cp ${SRC}/../debian/*.daase ${MID})
 	@ echo If all went well, go-ahead Mike and do a db-install as well !
 
 db-install:
@@ -39758,7 +39759,8 @@
 	@ echo rebuilding databases...
 	@ cp ${SRC}/doc/gloss.text ${MID}
 	@ cp ${SRC}/doc/topics.data ${MID}
-	@ (cd ${MID} ; echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
+	@ (cd ${MID} ; echo ")lisp (progn #+native-reloc(make-databases \"\" nil)#-native-reloc(system \"cp ${SRC}/../debian/*.daase ${MID}\"))" | ${INTERPSYS} )
+#	@ (cp ${SRC}/../debian/*.daase ${MID})
 
 check:
 	@ echo Checking that INTERP.EXPOSED and NRLIBs are consistent
--- ./src/etc/Makefile.pamphlet.orig	2005-01-30 12:03:12.000000000 +0000
+++ ./src/etc/Makefile.pamphlet	2005-02-14 18:47:16.000000000 +0000
@@ -33,9 +33,10 @@
 	@ cp ${SRC}/doc/gloss.text ${INT}/algebra
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
 	@ cp ${SRC}/doc/topics.data ${INT}/algebra
-	@ (cd ${INT}/algebra ; \
-           echo ')lisp (make-databases "" nil)' | ${INTERPSYS} )
-	@ cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
+	@ (cd ${INT}/algebra ; \
+           echo ")lisp (progn #+native-reloc(progn (make-databases \"\" nil)(system \"cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra\"))#-native-reloc(system \"cp ${SRC}/../debian/*.daase ${MNT}/${SYS}/algebra\"))" | ${INTERPSYS} )
+#	@ cp ${INT}/algebra/*.daase ${MNT}/${SYS}/algebra
+#	@ (cp ${SRC}/../debian/*.daase ${MNT}/${SYS}/algebra)
 
 @
 \section{summary}
--- ./src/boot/Makefile.pamphlet.orig	2005-06-05 03:23:35.000000000 +0000
+++ ./src/boot/Makefile.pamphlet	2005-09-20 21:36:15.000000000 +0000
@@ -1173,7 +1173,8 @@
 
 Until this is fixed we need to continue to use the old scheme.
 <<environment>>= 
-CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}"))
+#CMD0=	(progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}"))
+CMD0=	(if (member :native-reloc *features*) (progn (mapcar (function (lambda (x) (load  x))) (quote (${OBJS1}))) (system::save-system "${SAVESYS}")) (compiler::link (quote (${OBJS1})) "${SAVESYS}" (format nil "(let ((*load-path* (cons ~S *load-path*))(si::*load-types* ~S)) (compiler::emit-fn t)) (when (fboundp (quote si::sgc-on)) (si::sgc-on t)) (setq compiler::*default-system-p* t)" si::*system-directory* (quote  (list ".lsp")))))
  
 @
 \subsection{boothdr.lisp \cite{1}}
--- ./src/interp/Makefile.pamphlet.orig	2005-09-20 21:48:56.000000000 +0000
+++ ./src/interp/Makefile.pamphlet	2005-09-20 21:49:14.000000000 +0000
@@ -576,7 +576,28 @@
 \begin{verbatim}
 <<save depsys image>> 	@ (cd ${MNT}/${SYS}/bin ; \
-	   echo '(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))' | ${LISPSYS})
+	   echo '#+native-reloc(progn (load "${OUT}/makedep.lisp") (spad-save "${DEPSYS}"))#-native-reloc(progn \
+			(setq si::*collect-binary-modules* t) \
+			(load "${OUT}/makedep.lisp") \
+			(compiler::link \
+				(remove-duplicates si::*binary-modules* :test (quote equal)) \
+				"$(DEPSYS)" \
+				(format nil "\
+					(setq si::*collect-binary-modules* t) \
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+	                                     (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					(load \"$(OUT)/makedep.lisp\")\
+					(gbc t)\
+					(when si::*binary-modules* \
+						(error si::*binary-modules*))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+				"" \
+				nil))' | ${LISPSYS})
 @
 \end{verbatim}
 
@@ -880,8 +901,36 @@
 	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (si::gbc-time 0)' >> ${OUT}/makeint.lisp
 	@ echo '#+:akcl (setq si::*system-directory* "${SPAD}/bin/")' >> ${OUT}/makeint.lisp
+#	@ (cd ${OBJ}/${SYS}/bin ; \
+#	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
 	@ (cd ${OBJ}/${SYS}/bin ; \
-	  echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) (user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+	  echo '#+native-reloc(progn (gbc t) (setq x si::*system-directory*)(load "${OUT}/makeint.lisp") (setq si::*system-directory* x) (unintern (quote x))(gbc t)(user::spad-save "${SAVESYS}"))#-native-reloc(progn \
+			(setq si::*collect-binary-modules* t)\
+			(setq x si::*system-directory*)\
+			(load "${OUT}/makeint.lisp")\
+			(setq si::*system-directory* x)\
+			(unintern (quote x))\
+			(compiler::link \
+				(remove-duplicates si::*binary-modules* :test (quote equal))\
+				"$(SAVESYS)" \
+				(format nil "\
+					(let ((si::*load-path* (cons ~S si::*load-path*))\
+                                             (si::*load-types* ~S))\
+						(compiler::emit-fn t))\
+					 (setq si::*collect-binary-modules* t)\
+					 (setq x si::*system-directory*)\
+					 (load \"$(OUT)/makeint.lisp\")\
+					 (setq si::*system-directory* x)\
+					 (unintern (quote x))\
+					 (when si::*binary-modules* \
+						(error si::*binary-modules*))\
+					(setq si::collect-binary-modules* nil si::*binary-modules* nil)\
+					(gbc t)\
+					(when (fboundp (quote si::sgc-on)) (si::sgc-on t))\
+					(setq compiler::*default-system-p* t)\
+				" si::*system-directory* (quote (list ".lsp")))\
+			"$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o $(OBJ)/$(SYS)/lib/libspad.a" \
+			nil))' | $(LISPSYS))
 	@ echo 6 ${SAVESYS} created
 	@ cp ${SAVESYS} ${AXIOMSYS}
 	@ echo 6a ${AXIOMSYS} created
============================================================================
       This can obviously be cleaned up , but it appears to be working
       again on all Debian machines.  Notably, it appears that in the
       last 6 months the interpsys binary is used to compile some
       objects which are later loaded and dumped into the final
       image.  Therefore  I had to set *default-system-p* to t in
       interpsys, and then at the very end, do

	echo ")lisp (progn (setq compiler::*default-system-p* nil)(si::save-system \"foo\"))" | AXIOM=$(CURDIR)/mnt/linux $(CURDIR)/mnt/linux/bin/AXIOMsys && mv foo mnt/linux/bin/AXIOMsys
 
	Perhaps we could try once again to merge this or equivalent
	into the source proper.

3)    one GC/regexp race bug is fixed

4)    binutils is upgraded to 2.16, and built locally in Debian by
      default.

5)    Certain improvements to optimization when using compile as
      opposed to compile-file have been made.  compile, unlike
      compile-file, must refer to any literal object mentioned in the
      source by address, i.e. must not copy it.  This was achieved by
      wrapping quoted literals by `(load-time-value (si::nani
      ,(si::address object))), and was confusing the optimizer when
      special symbols like 'eql were mentioned.  we now do not wrap
      external symbols of the lisp package as per spec.


One can try out the 2.6.8 pre-release by:

export CVS_RSH=ssh
export CVSROOT=:ext:subversions.gnu.org:/cvsroot/gcl
cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre gcl

This is essentially the same code as was uploaded into Debian with
package name 2.6.7-7 in case one is interested in following it there.

Anyway, I don't plan on working on this too much, as I'd like to
finalize 2.7.0 while it is still possible.

\start
Date: Fri, 30 Sep 2005 00:26:58 -0400
From: Bill Page
To: Peter Broadbery
Subject: RE: types as values, and type internals

Peter,

This is largely just notes to myself, but if you or any
one else have comments, I would really appreciate it.

On Thursday, September 29, 2005 5:48 PM I wrote:

> ...
> Given that in the AldorDomain code you write:
>
>    theIntegerType(): % == per Integer;
>
> what is the difference in the interpreter when I write:
>
>   (1) -> A:=Integer
>
>      (1)  Integer
>                                            Type: Domain
>   (2) -> B:=theIntegerType()
>
>      (2)  (Integer)
>                                         Type: AldorDomain
>
> Is there a difference in the internal representations?

I guess the answer must be "yes" since if I use the name
Domain instead of AldorDomain and re-compile the code, this
is the result that I get:

(5) -> x1:=(theIntegerType(),theIntegerType())

   (5)  [(Integer),(Integer)]
                                           Type: Tuple Domain
(6) -> x2:=(Integer,Integer)

   (6)  [(Integer),(Integer)]
                                            Type: Tuple Domain
(7) -> x3:=(1,2)

   (7)  [1,2]
                                    Type: Tuple PositiveInteger
(8) -> select(x3,1)
   Loading /usr/local/axiom/mnt/linux/algebra/TUPLE.o for domain Tuple

   (8)  2
                                           Type: PositiveInteger
(9) -> select(x1,1)

   (9)  Integer
                                                   Type: Domain
(10) -> select(x2,1)

   >> System error:
   Caught fatal error [memory may be damaged]

-------

Back to the drawing board ...

Actually come to think of it, I don't really understand why
just renaming your AldorDomain to Domain is otherwise working
so well for me. Obviously the interpreter is calling the
OutputForm coercion for Integer from 'Domain'. And that makes
the display of Tuple of Domain happy. The tuples x1 and x2
both display the same way, but why can I only select from
the one that was created in 'Domain' but not something that
was created inside Axiom?

Hmmm... you did said earlier I think that Categories and
Domains have a different internal structure?

I suppose then that properly speaking, x1 is a Tuple of Domain
but x2 is "really" a Tuple of the type of Integer, i.e. a
Tuple of SomeCategory(...). It seems that these kinds of
objects don't play nicely with domains. But when encapsulated
in a object from the category embedded in your kind of Domain,
they do.

I cannot write:

(10) -> x:theIntegerType()

   Category, domain or package constructor theIntegerType
      is not available.

because the type of theIntegerType() is the domain Domain,
not some category which is the type of Integer. The
interpreter of course should retract this to a category.

Instead of writing 'theIntegerType()', it would be nice to
use the function you defined: 'make(Integer)'. However this
runs into a similar kind of problem as above since Axiom
does not seem to allow domains to be passed as parameters
to functions even if Aldor specifies the type of the parameter
as a category, e.g. Type. In Axiom I think the only way to
accomplish this is to pass the domain as a parameter to another
domain as shown in the following patch:

-----------

diff -au domain2.as.orig domain2.as.new
--- domain2.as.orig     2005-09-29 20:37:51.000000000 -0500
+++ domain2.as.new      2005-09-29 20:38:13.000000000 -0500
@@ -1,7 +1,7 @@
 #include "axiom.as"

-AldorDomain: SetCategory with {
-       make: (T: BasicType) -> %;
+AldorDomain(T:Type): SetCategory with {
+       make: () -> %;

        theIntegerType: () -> %;
        map: (%, %) -> %;
@@ -34,7 +34,7 @@

        import from Rep2;

-       make(T: BasicType): % == per T;
+       make(): % == per T;
        theIntegerType(): % == per Integer;
        integerMod(p: PositiveInteger): % == per(IntegerMod p);

---------

(1) -> )abb dom AD AldorDomain
   AD abbreviates domain AldorDomain
(1) -> )lib domain2
   Reading /home/page/domain2.asy
   AldorDomain is now explicitly exposed in frame initial
   AldorDomain will be automatically loaded when needed from
      /home/page/domain2
(1) -> a:=make()$AD(INT)

   (1)  (Integer)
                                   Type: AldorDomain Integer
(2) -> b:=make()$AD(FLOAT)

   (2)  (Float)
                                     Type: AldorDomain Float
(3) -> c:Tuple Any:=(a,b)

   (3)  [(Integer),(Float)]
                                             Type: Tuple Any
(4) -> select(c,1)

   (4)  (Float)
                                     Type: AldorDomain Float

----------

See also revised web page:

http://wiki.axiom-developer.org/209TheFunctionDomainIsUndefined

\start
Date: Thu, 29 Sep 2005 23:18:02 -0500
From: MathAction (Bill Page)
To: MathAction
Subject: [#209 The function |Domain| is undefined] correct bug in coercion to OutputForm

This fails

\begin{axiom}
Tuple Type
\end{axiom}

But this works
\begin{axiom}
List Type
\end{axiom}

The following domain called 'Domain' provides some of the
missing functionality. It is based on 'AldorDomain' by Peter
Broadbery who writes::

  ![One] can still do some useful things with them by disguising
  the fact that they are domains, so in aldor have a type and
  your aldor programs can return this to axiom.

For example:
\begin{aldor}
#include "axiom.as"

AldorDomain(T:Type): with {
      make: () -> %;
      coerce: (%) -> OutputForm;
} == add {
      Rep ==> Type;

      make(): % == per T;

      coerce(t: %): OutputForm == {
              import from SExpression;
              devaluate(t pretend SExpression)::OutputForm
      };

      import {
              BOOT_:_:devaluate: SExpression -> SExpression;
      } from Foreign Lisp;

      local devaluate(s: SExpression): SExpression == {
              BOOT_:_:devaluate(s);
      }
}
\end{aldor}

\begin{axiom}
aInteger:=make()$AldorDomain(Integer)
\end{axiom}

Domain: SetCategory == add {

        (a: %) = (b: %): Boolean == {
                import from SExpression;
                a pretend SExpression = b pretend SExpression
        }

        coerce(t: %): OutputForm == {
                import from SExpression;
                devaluate(t pretend SExpression)::OutputForm
        };


a:=(Integer,Float)

Except::

  !\begin{axiom}
  select(a,1)
  \end{axiom}

causes Axiom to abort.

\start
Date: Fri, 30 Sep 2005 09:39:12 +0200
From: Michael Brickenstein
To: list
Subject: Openmath, Singular

Hello!

I am a member from the Singular team.
Singular is a computer algebra system for Algebraic Geometry/
Singularity Theory/Commutative Algebra.
It provides functionality with focus in the areas
Gr=F6bner bases (even standard bases), primary decomposition, free 
resolutions, syzygies, polynomial equations.

We are working on providing our functionality to other systems via 
the openmath standard.
We base our work at the moment on the polyd content dictionary.
How is the status for openmath in Axiom?
Are you interested in connecting with Singular?
Can I test your Openmath functionality (maybe some examples, since I 
don't know axiom)?

At the moment I have written a prototype implementation for Singular, 
which has the core functionality of openmath and in especial provides 
the possibility to calculate Groebner Bases.

I hope, that this proposal could be the basis of a future cooperation.

\start
Date: Fri, 30 Sep 2005 10:56:50 -0400
From: Bill Page
To: Michael Brickenstein
Subject: RE: Openmath, Singular

On September 30, 2005 3:39 AM Michael Brickenstein wrote:
>
> I am a member from the Singular team. Singular is a computer
> algebra system for Algebraic Geometry/Singularity Theory/Commutative
> Algebra. It provides functionality with focus in the areas
> Gr=F6bner bases (even standard bases), primary decomposition, free 
> resolutions, syzygies, polynomial equations.
>

Welcome to the Axiom developer list! :)

> We are working on providing our functionality to other systems
> via the openmath standard. We base our work at the moment on the
> polyd content dictionary.

Very interesting.

> How is the status for openmath in Axiom?

A great deal of work was done by NAG and associates a few years
ago prior to Axiom going open source. All of the hooks are
present in the current open source release and the OpenMath
modules are available but not integrated and tested with the
this release.

> Are you interested in connecting with Singular?

Yes, very interested!

As you probably already know, in addition to Axiom itself, we
also operate an online web interface to Axiom and Reduce
called MathAction, http://www.axiom-developer.org which
provides technical and user support services for the project.
MathAction is designed to be easily interfaced to other
packages and I think it would be great to include Singular.
OpenMath support should make this easier.

> Can I test your Openmath functionality (maybe some examples,
> since I don't know axiom)?

I would be glad to help. We seem to have been just waiting
for someone like you to come all to motivate us to complete
this part of the open source release. :)

>
> At the moment I have written a prototype implementation for
> Singular, which has the core functionality of openmath and in
> especial provides the possibility to calculate Groebner Bases.
>
> I hope, that this proposal could be the basis of a future
> cooperation.
>

\start
Date: Fri, 30 Sep 2005 08:09:04 -0700
From: Ed Borasky
To: Michael Brickenstein
Subject: Re: Openmath, Singular

Speaking of Singular, it has recently been added to the CygWin 
distribution! I update my CygWin installations every few days, and it is 
now working.

For the Axiom folks -- will Axiom build under CygWin?

Michael Brickenstein wrote:

> Hello!
>
> I am a member from the Singular team.
> Singular is a computer algebra system for Algebraic Geometry/ 
> Singularity Theory/Commutative Algebra.
> It provides functionality with focus in the areas
> Grbner bases (even standard bases), primary decomposition, free  
> resolutions, syzygies, polynomial equations.
>
> We are working on providing our functionality to other systems via  
> the openmath standard.
> We base our work at the moment on the polyd content dictionary.
> How is the status for openmath in Axiom?
> Are you interested in connecting with Singular?
> Can I test your Openmath functionality (maybe some examples, since I  
> don't know axiom)?
>
> At the moment I have written a prototype implementation for Singular,  
> which has the core functionality of openmath and in especial provides  
> the possibility to calculate Groebner Bases.
>
> I hope, that this proposal could be the basis of a future cooperation.

\start
Date: Fri, 30 Sep 2005 12:53:24 -0400
From: Bill Page
To: Ed Borasky
Subject: RE: Openmath, Singular

On September 30, 2005 11:09 AM Ed Borasky wrote:
> 
> Speaking of Singular, it has recently been added to the
> CygWin distribution! I update my CygWin installations every
> few days, and it is now working.
> 
> For the Axiom folks -- will Axiom build under CygWin?
> 

No, not yet. The current open source distribution of Axiom
is based on GCL and GCL only builds on MSYS/MinGW to a native
Windows app. Of course that is not a problem since you can
of course run native windows apps under cygwin. It is also
possible to install both cygwin and MSYS/MinGW.

The only limitation is that on window, even with cygwin
installed, you can not use the Xwindows-based parts of
Axiom, i.e. the hyperdoc browser and graphics.

It should be possible to build a native Windows version of
GCL-based Axiom using the gcc/mingw compiler under cygwin
but the Makefiles would require some tweaking.

In principle building a full cygwin-based version of Axiom
should not be difficult since Axiom has been built on a
large number of lisp platforms, some of which fully support
the cygwin Xwindows environment. If you would like to give
this a try, I would be glad to help.

\start
Date: Fri, 30 Sep 2005 19:42:18 +0100
From: Peter Broadbery
To: Bill Page
Subject: RE: types as values, and type internals

On Thu, 2005-09-29 at 17:48 -0400, Page, Bill wrote:
> On Thursday, September 29, 2005 3:21 PM Peter Broadbery wrote:
> > ... 
> > It was written mostly to show that you could do some
> > operations on domains - effectively allowing one to write
> > more of an interpreter in the extension language.  I'm not
> > 100% confident of what the definitions of "Domain",
> > "SubDomain", "Category" and "Type" should be, so was
> > avoiding them.
> 
> It seems that that might have been the prevailing approach
> in the latter stages of Axiom's development - a pity
> considering Axiom's otherwise quite noble objectives
> concerning mathematical rigor. ;) Seriously, this issue
> does give me a headache that I would like to releave.
> 

It has given me the odd headache too - worries about the upper levels of
the type hierarchies came up rarely, and there was often some more
pressing thing to worry about.

> > 
> > If we can find a way that these can fit together and allow 
> > axiom to deal with them coherently it would definitely be
> > a good thing, but I'm not sure I'm qualified to decide
> > exactly what the semantics should be.
> 
> I agree that it would be a very good thing, but if you are
> not sure you are qualified, then I am not sure that I am
> even qualified to have an opinion! :)
> 

I just wrote bits of the compiler - the type hierarchy conveniently goes
away when you're worrying about code generation.  Below is some
speculation - I have not verified it against any real documentation or
code.

Just as an idea, we could explain things this way:
The 'is a type of' (ie. a: A) operation in aldor is slightly overloaded
- in the context of a domain, 'A', it says that 'a' is represented as
specifed in the domain, and that when '%' appears in the signature of
one of the operations, then a can be used there.  In the context of a
category, it means that 'a' implements the operations exported by 'A'.

As an aside, one could consider writing a language which has separate
syntaxes for these.  You could also argue that java's 'implements'
keyword is the equivalent of : at category level, but that'll be another
argument. 

Anyway, from this point of view, the type of domains is 'domain',
implementing your favourite Domain-level functions (eg. name,
findExport), while Categories are objects which mostly list exports
(they also supply default operations, but I'll ignore that).  The
operations on a category object are different - findExport makes no
sense without an underlying domain implementing the operation.  So,
you're left with 'name'(*).

Now we could if we wanted to take this to a logical extreme, implement a
category of domains, and thus allow the user to have entirely different
representations for types in the same system, and all respecting the
category hierarchy.  Luckily, (although unfortunately for asprin
manufacturers), axiom hasn't quite done this.  Instead, we have the type
of "domains" - Domain, and the type of things that list operations
returned by getOperation (ie. Categories), which must be 'SubDomain'.

This may be close to the original intention - some older timers may want
to chime in here.  It doesn't really explain 'Type' particularly, and in
fact it may be that 'Domain' was an experiment which was at least
partially supplanted by the (initially simpler) idea of a two level type
hierarchy.

(*) In fact, categories implement name, and functions for reading the
parent categories, and also behave like domains (so you can instatiate
them to get defaults).

> > 
> > > I wonder if the Rep == Type really makes sense?
> > > 
> > 
> > I think Rep ==> Type is more or less honest, given that
> > a Type is an object in the aldor world view. A caveat is
> > that it captures  categories (and "Type") as well as domains.
> 
> Hmmm. Ok so when I am writing Aldor code in Axiom I (for
> the most part) have this "aldor world view", right? So Type
> is something native to Aldor?
> 
> In the Axiom interpret if I write:
> 
>   (1) -> Type
> 
>      (1)  Type
>                                      Type: SubDomain Domain
> 
> It answers with a Type for Type that is hard for me to
> understand ... especially considering that the Axiom Book
> specifically says that the Type of Type is undefined. :(
> 

Even if it is undefined, it has to have a value.  I'm guessing that
saying 'undefined' gives an opportunity to redesign and still be
correctly documented.

> Anyway, am I correct then to understand that
> 
>    Rep ==> Type
> 
> here means that we are going to 'pretend' about something
> that is assumed to have a structure directly understood
> by Aldor? Doesn't that mean that anything like:
> 
>           name(t: %): SExpression == {
>   -               dom := t pretend Rep2;
>   -               axiomName((dom.v.domName)(dom.o))
>   +               dom := t pretend SExpression;
>   +               devaluate(dom);
> 
> that just pretends that something passed from Axiom has
> such a structure would be rather dangerous? Instead we
> would have to ask Axiom to do some kind of explicit
> conversion to the Rep2 structure, right? Perhaps that
> explains why the original code for name above (-) failed?
> 

It's expecting an (aldor) domain, and it appears that mappings seem to
be represented differently.  I'd need to sit down with a debugger for a
while before answering further, I think.

> Notice how many question marks I wrote in the above
> paragraph? :) That's how certain I am about all this
> so please forgive me if my writing seems overly pedantic.
> 

I'm not 100% sure of anything, which is why I can't really be too
confident.

> Given that in the AldorDomain code you write:
> 
>    theIntegerType(): % == per Integer;
> 
> what is the difference in the interpreter when I write:
> 
>   (1) -> A:=Integer
> 
>      (1)  Integer
>                                            Type: Domain
>   (2) -> B:=theIntegerType()
> 
>      (2)  (Integer)
>                                         Type: AldorDomain
> 
> Is there a difference in the internal representations?
> 

I think they have the same representation - you can check by tracing
'recordAndPrint', or looking for where axiom stores its result history.
They have different types, so print differently, I think (cf. Integer
and RomanNumeral for a more obvious example).

> Aha. See my question above about name function. So I guess
> it is just a matter of knowing which sturcture to use
> and when to convert, right?
> 

Yes - though I think the older representation should not be leaking into
the aldor world, and this might be the bug.

> > 
> > Devaluate should be equivalent for all domains.  Ah,
> > Mappings aren't quite domains, since  'isDomain' fails
> > for them. Not sure what the underlying bug is though.
> 
> If I write Domain instead of AldorDomain in your code and
> compile it then I can write
> 
>   (1) -> (Integer, Float)
> 
>      (1)  [(Integer),(Float)]
>                                         Type: Tuple Domain
> 
>   (2) -> ((Integer->Float),(Float->Integer))
> 
>      (2)  [(Mapping (Float) (Integer)),
>                     (Mapping (Integer) (Float))]
>                                         Type: Tuple Domain
> 
> it looks as if Mapping is understood by the interpreter but
> the coerce to OutputForm from Tuple doesn't seem to be doing
> such a good job.
> 

The coerce in Tuple is fine - I think your expectations of devaluate
aren't right - what your seeing in AldorDomain's coerce is the axiom
representation of the type, which is not the same as its print
representation.

\start
Date: Fri, 30 Sep 2005 18:46:52 -0700
From: Ed Borasky
To: Bill Page
Subject: Re: Openmath, Singular

Clisp is in CygWin already ... will it build Axiom?

Bill Page wrote:

>On September 30, 2005 11:09 AM Ed Borasky wrote:
>  
>
>>Speaking of Singular, it has recently been added to the
>>CygWin distribution! I update my CygWin installations every
>>few days, and it is now working.
>>
>>For the Axiom folks -- will Axiom build under CygWin?
>>
>>    
>>
>
>No, not yet. The current open source distribution of Axiom
>is based on GCL and GCL only builds on MSYS/MinGW to a native
>Windows app. Of course that is not a problem since you can
>of course run native windows apps under cygwin. It is also
>possible to install both cygwin and MSYS/MinGW.
>
>The only limitation is that on window, even with cygwin
>installed, you can not use the Xwindows-based parts of
>Axiom, i.e. the hyperdoc browser and graphics.
>
>It should be possible to build a native Windows version of
>GCL-based Axiom using the gcc/mingw compiler under cygwin
>but the Makefiles would require some tweaking.
>
>In principle building a full cygwin-based version of Axiom
>should not be difficult since Axiom has been built on a
>large number of lisp platforms, some of which fully support
>the cygwin Xwindows environment. If you would like to give
>this a try, I would be glad to help.
\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
