\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: Wed, 01 Feb 2006 03:42:45 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [#261 Strange matrix addition] (new) 

Adding two square matrices of different dimension should result in an error. Axiom returns something that looks more like a tensor product.

The implementation of + for SquareMatrix is inherited from Matrix (src/algebra/matrix.spad.pamphlet). Matrix inherits + from the default implementation in MatrixCategory (src/algebra/matcat.spad.pamphlet).
There it says
     "+": (%,%) -> %
       ++ \spad{x + y} is the sum of the matrices x and y.
       ++ Error: if the dimensions are incompatible.
and is implemented by default through:
     x + y ==
       ((r := nrows x) ^= nrows y) or ((c := ncols x) ^= ncols y) =>
         error "can't add matrices of different dimensions"
       ans := new(r,c,0)
       for i in minr(x)..maxr(x) repeat
         for j in minc(x)..maxc(x) repeat
           qsetelt_!(ans,i,j,qelt(x,i,j) + qelt(y,i,j))
       ans

I have no idea why the following code returns something of type
SquareMatrix(2,SquareMatrix(3,Integer)).

\begin{axiom}
S d ==> SquareMatrix(d,Integer)
a2: S(2) := 1
a3: S(3) := 1
a2 + a3
\end{axiom}

\start
Date: Wed, 01 Feb 2006 11:19:56 -0600
From: MathAction (anonymous)
To: MathAction
Subject: [#262 Local variables in output] (new) 

In some cases Axiom's output contains temporary names such
as '%x0' standing for subexpressions that are not properly
substituted into the final result. For example:
\begin{axiom}
eq:=-cos(12*x)+x^2+x^2
zerosOf(eq,x)
\end{axiom}

\start
Date: Wed, 01 Feb 2006 13:49:47 -0600
From: MathAction (unknown)
To: MathAction
Subject: [FreeAldor] 

Juan Gea Rosat

\start
Date: Wed, 01 Feb 2006 06:52:10 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#261 Strange matrix addition] 

\begin{axiom}
)set message bottomup on
\end{axiom}

\start
Date: Wed, 01 Feb 2006 06:53:56 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#261 Strange matrix addition] Axiom interpret	trys really hard

It seems the Axiom interpreter is trying really hard to figure out
what you might mean by this sum! The 'bottomup' output shows the "mode
selection" that it eventually arrives at.

\start
Date: Wed, 1 Feb 2006 11:05:07 -0800 (PST)
From: Cliff Yapp
To: Robert Dodier
Subject: Fwd: unevaluated boolean and conditional expressions in Axiom

Got this email from Robert Dodier, who is currently behind the wheel on
the Maxima project.  I don't know much about conditional stuff in
Axiom, so with his permission I'm passing it on to the list.  (Remember
to CC Robert since he's not on this list.)

--- Robert Dodier wrote:

> Date: Wed, 1 Feb 2006 10:29:24 -0700
> From: Robert Dodier
> To: Cliff Yapp
> Subject: unevaluated boolean and conditional expressions in Axiom
> 
> Hi Cliff,
> 
> I wonder if you can answer this question for me.
> 
> How does Axiom handle boolean expressions which don't evaluate to
> true or false?
> Likewise, what happens to if -- then -- else when the condition is a
> boolean expression
> which doesn't evaluate to true or false.
> 
> Here are some examples. I'll try to use a "package agnostic"
> notation.
> 
> Let A = 100. What does "(A > 0) and (B > A) or (C > A)" evaluate to?
> Maybe "(B > 100) or (C > 100)" ? Something else?
> 
> Let X = 100. What does "if (X != 0) then (if (Y != 0) then X/Y else
> Y/X)
> else FOO" evaluate to?
> Maybe "if (Y != 0) then 100/Y else Y/100" ? Something else?
> 
> I'm working on beefing up Maxima's handling of boolean and
> conditional
> expressions, and just for a point of reference I'm taking a look at
> what
> other packages do. If you have some links or references to the Axiom
> documentation that would be very helpful.

\start
Date: Wed, 01 Feb 2006 11:27:33 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#262 Local variables in output] 

eq:=-cos(12*x)+x^2+x^3

\start
Date: Wed, 1 Feb 2006 19:15:51 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Fwd: unevaluated boolean and conditionalexpressions in Axiom
Cc: Robert Dodier

Robert,

I hope this example is of some help:

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

The general answer is that at present Axiom does not attempt
to implement unevaluated conditions and Boolean expressions.
I think it would be great of some Axiom developer was motivated
to correct this omission...

Please feel free to experiment at the above web site and to
post questions and commments if you like.

> -----Original Message-----
> From:
>
> Got this email from Robert Dodier, who is currently behind
> the wheel on the Maxima project.  I don't know much about
> conditional stuff in Axiom, so with his permission I'm passing
> it on to the list.  (Remember to CC Robert since he's not on
> this list.)
>
> --- Robert Dodier wrote:
>
> > Date: Wed, 1 Feb 2006 10:29:24 -0700
> > From: Robert Dodier
> > To: Cliff Yapp
> > Subject: unevaluated boolean and conditional expressions in Axiom
> >
> > Hi Cliff,
> >
> > I wonder if you can answer this question for me.
> >
> > How does Axiom handle boolean expressions which don't evaluate to
> > true or false?
> > Likewise, what happens to if -- then -- else when the condition
> > is a boolean expression which doesn't evaluate to true or false.
> >
> > Here are some examples. I'll try to use a "package agnostic"
> > notation.
> >
> > Let A = 100. What does "(A > 0) and (B > A) or (C > A)" evaluate =
to?
> > Maybe "(B > 100) or (C > 100)" ? Something else?
> >
> > Let X = 100. What does "if (X != 0) then (if (Y != 0) then X/Y =
else
> > Y/X)
> > else FOO" evaluate to?
> > Maybe "if (Y != 0) then 100/Y else Y/100" ? Something else?
> >
> > I'm working on beefing up Maxima's handling of boolean and
> > conditional  expressions, and just for a point of reference I'm
> > taking a look at what other packages do. If you have some links
> > or references to the Axiom documentation that would be very helpful.

\start
Date: Wed, 01 Feb 2006 20:55:44 -0500
From: Raymond Rogers
To: list
Subject: Solve()?

Hello,

Is anybody maintaining solve()?  I think there might be a shortcoming in
the implementation; maybe not.  Short script available.

\start
Date: Wed, 1 Feb 2006 21:22:56 -0500
From: Bill Page
To: Raymond Rogers
Subject: RE: Solve()?

Ray,

That's a good question. :)

Please post you example script here:

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

Click 'edit' create a new link such as

  [SandBox Shortcoming] -- Implementation of solve

Click 'Save' and then click on the blue ? to create
the page. On the page enter

\begin{axiom}
  your script here
\end{axiom}

Then we can discuss it.  Thanks.

> -----Original Message-----
>
> Hello,
>
> Is anybody maintaining solve()?  I think there might be a
> shortcoming in the implementation; maybe not.  Short script
> available.

\start
Date: Wed, 1 Feb 2006 22:16:36 -0500
From: Tim Daly
To: Raymond Rogers
Subject: Re: Solve()?

there are no people with special assigned areas.
we welcome all input to all areas that might need work.
what problem did you encounter?

\start
Date: Wed, 1 Feb 2006 21:57:48 -0500
From: Bill Page
To: list
Subject: FW: Fwd: unevaluated boolean and conditionalexpressions in Axiom

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

-----Original Message-----

Hi Bill, thanks for your reply.

I've made a comment on the Axiom wiki to which you pointed me.

I'll let you know if I come up with something workable for Maxima.

\start
Date: Wed, 01 Feb 2006 21:28:12 -0600
From: MathAction (rrogers)
To: MathAction
Subject: [[SandBox Shortcoming] -- Implementation of solve] (new) Solve failure

list:=[p,Vr,Vt,e]
eq1a:=((-Vr^3+Vr^2)*Vt+Vr^3-Vr^2)
eq1:=((-Vr^3+Vr^2)*Vt+Vr^3-Vr^2)*R*p
eq2:=-Vr*Vt^3+Vr*Vt^2-Vr*Vt+Vr*p
eq3:=(R*Vr*Vt+R*Vr)*e+((R-1)*Vr+1)*Vt-R*Vr
eq4:=-r^2+(Vt^2)+(Vr^2)
Eqlista:=[eq1a,eq2,eq3,eq4]
Eqlist:=[eq1,eq2,eq3,eq4]

\start
Date: Thu, 02 Feb 2006 00:53:20 -0600
From: MathAction (unknown)
To: MathAction
Subject: [FreeAldor] 

Igor Durdanovic

\start
Date: Thu, 02 Feb 2006 04:41:39 -0600
From: MathAction (unknown)
To: MathAction
Subject: [FreeAldor] 

Alvaro Tejero Cantero

\start
Date: Thu, 02 Feb 2006 04:00:30 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [#261 Strange matrix addition] Bug or Feature

I don't know whether I should consider that 
behaviour of Axiom as a bug or a feature.

If one puts
<pre>
macro S d == SquareMatrix(d,Integer)
abc(): OutputForm ==
	a2: S(2) := 1
	a3: S(3) := 1
	(a2 + a3)::OutputForm
</pre>
into a file aaa.input and then says
<pre>
)read aaa
abc()
</pre>

one gets exactly the same result of type
SquareMatrix(2,SquareMatrix(3,Integer)) as above.  Clearly, the same
code, when put into aaa.spad does not even compile via

<pre>
)co aaa
</pre>

The danger is the following (which is maybe not clearly demonstrated
by the code above): If somebody writes some prototype of a function
into an .input file and later wants to transform the code into a .spad
form, s/he cannot expect that the result is the same. If the code does
compile the semantics is still different since for the .input part the
interpreter might add some knowledge.

That problem is certainly known to people who have used Axiom extensively, but it will come as a surprise if one is relatively new to Axiom.

\start
Date: Thu, 02 Feb 2006 09:50:57 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#262 Local variables in output] not really temporary

These names are not really temporary:

\begin{axiom}
definingPolynomial %x0
\end{axiom}

(However, I think they should be...)

\start
Date: Thu, 02 Feb 2006 11:39:37 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#263 ContinuedFraction returns incorrect types] 

There seems to be a problem with Axiom's ContinuedFractions domain.

\start
Date: Thu, 02 Feb 2006 11:33:04 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#263 ContinuedFraction returns incorrect types]

There seems to be a problem with Axiom's ContinuedFraction domain.
The type of the result is shown as 'Fraction Float' but this is
nonesense.

Something similar happens if the argument is Fraction Integer
\begin{axiom}
nume(a) == cons(1,[((a-i)*i) for i in 1..]);
dene(a,x) == [(x+2*i+1-a) for i in 0..];
cfe(a,x) == continuedFraction(0,nume(a),dene(a,x));
ccfe(a,x) == convergents cfe(a,x);
ccfe(0,2::Float)
ccfe(0,2::Fraction Integer)
\end{axiom}

'Fraction Fraction Integer' is also nonesense.

\begin{axiom}
ff1:Fraction Float
ff2:Fraction Fraction Integer
\end{axiom}


\start
Date: Thu, 02 Feb 2006 09:55:42 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#262 Local variables in output] 

Note that the expression (3) surfaces another bug in the solver: the variable 'x' should not appear in the defining polynomial of '%x0'...

Martin

\start
Date: Thu, 02 Feb 2006 14:23:57 -0600
From: MathAction (unknown)
To: MathAction
Subject: [WesterProblemSet] document still unavailable

The exact links I'm pointed to are
http://wiki.axiom-developer.org/images/WesterProblemSet.pdf
http://wiki.axiom-developer.org/images/WesterProblemSet.dvi
and so forth

\start
Date: Thu, 02 Feb 2006 15:20:23 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [WesterProblemSet] confusion ... re: document still unavailable.

I don't know exactly what's happening here. When I tried
the links just now, they failed as you said. But I am sure
that I did a 'refresh' (see bottom right corner of page)
and tested this yesterday. 'refresh' recreates the files.

So I did a 'refresh' again. And now they work again.

Please try again. If the links don't work. Hit 'refresh'
and see if that helps.

\start
Date: Thu, 02 Feb 2006 19:31:17 -0600
From: MathAction (Tim Daly)
To: MathAction
Subject: [Summer of Code] 

<p> Develop an automated generate-and-test program. Axiom allows
  you to select domains and use these to build up types. A systematic
  way of constructing types and elements of the types is needed.
  Input could be from the databases which contain signature information
  for all types and functions. Additionally it would be useful if the
  test program parsed the expressions and kept all of the generated
  tests in a tree so we could decide issues like coverage. The tree
  should be searchable for both function and domain information.

\start
Date: Fri, 03 Feb 2006 03:00:54 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#261 Strange matrix addition] Bug or feature

It is true that Axioms interpreter and compiler apply (slightly)
different semantics. However, it seems to me that if code compiles
with spad, then it should return the same result when interpreted.

I'm quite sure that this problem is inevitable given that we want the
interpreter to guess types...

Martin

\start
Date: Fri, 03 Feb 2006 03:36:45 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [Summer of Code] 

  There is already software that is very close:
<a href="http://www.risc.uni-linz.ac.at/software/aldor/aldorunit">AldorUnit</a>

  As an example, it is used for testing with 
  <a href="http://www.hemmecke.de/aldor">ALLPROSE</a>.

\start
Date: Fri, 03 Feb 2006 03:25:50 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#263 ContinuedFraction returns incorrect types] 

(note that there is no output...)

\start
Date: Fri, 03 Feb 2006 03:24:30 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#263 ContinuedFraction returns incorrect types] 

Well, this is a general problem: when a constructor takes a parameter
'R', it is often natural to return something of type 'Fraction R'. I
see two possible solutions:

- 'Fraction R' returns 'R' when 'R' is a field

- an operation that wants to return 'Fraction R' has to check whether
  'R' is a field.

In the case above I see another problem:

\begin{axiom}
n := nume(0.2)
d := dene(0.2,x)
continuedFraction(0, n, d)
\end{axiom}

\start
Date: Fri, 03 Feb 2006 04:17:01 -0600
From: MathAction (unknown)
To: MathAction
Subject: [FreeAldor] 

It would be a great shame if Aldor were to fade into obscurity. It
still has much to offer to the education and research communities, but
the clock is ticking and unless it is adopted soon it will be
superceded by something with similar functionality but quite possibly
a weaker fundamental design.

Tom Ashby

\start
Date: Fri, 03 Feb 2006 06:09:44 -0600
From: MathAction (PeterBroadbery)
To: MathAction
Subject: [FreeAldor] 

source would help greatly, and especially under a non-restrictive licence.

Peter Broadbery

\start
Date: Fri, 03 Feb 2006 10:25:57 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#263 ContinuedFraction returns incorrect types] Re: Fraction R returns R when R is a field

This makes very good sense to me. Is Field the right type or
something more general?

But is this possible in Axiom? How would I modify [Fraction]
to make this happen?

\start
Date: Fri, 03 Feb 2006 09:45:29 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#261 Strange matrix addition] Axiom interpret is different from SPAD by design

I agree with Martin that we should expect that (most) SPAD functions
will work when written as function definitions in the Axiom interpreter
but usually not the other way around. Although the distinction between
interpreter and compiler is a bit ambiguous because functions are usually
also compiled to lisp in the Axiom interpret, where possible. The Axiom
interpreter however makes assumptions about types, performs "mode matching"
and does automatic coercions in an attempt to releave the user of having
to specify such details. This is not part of SPAD or Aldor semantics.

This "mode matching" mechanism in the Axiom interpreter is what gives
the perhaps unexpected result above. I think it goes something like
this: In trying to resolve the meaning of the '+' operator, mode
matching searches for coercions of the operands such that the signature
of some known (exposed) function matches the resulting signatures of
the operands and the type of the desired result (if specified). It
then applies the coercions and function of the first match it finds.

I think this behaviour is fundamental to the design of the Axiom
interpreter and cannot/should not be changed. However in a sense it
is/was only an experiment. There does not seem to be any sound and
complete theory of how it should work in practice. (I think there
is a paper about the theory of automatic coercions in the AxiomPortal
reference library.) In particular, it is difficult to predict in
advance the affect for providing the interpret with certain coersion
paths since the mode matching search can become quite complex -
as the example above illustrates. But it is also essential for basic
use of the interpreter such as:

\begin{axiom}
x+1
\end{axiom}

where we see the interpreter does behave in a simple and expected
manner.

So in short: I think we need a theory, and then we need to review
and edit Axiom's current system of coercions to try to ensure that
the Axiom interpreter's behaviour is more intuitive for new users.

As an interim measure, it might be nice if we had a more user-friendly
way to display the results of the mode matching than the obscure
result of ')set output bottomup on'.

\start
Date: Fri, 03 Feb 2006 10:33:35 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Fraction] (new) 

Description -- Fraction takes an IntegralDomain S and produces
the domain of Fractions with numerators and denominators from S.
If S is also a GcdDomain, then gcd's between numerator and
denominator will be cancelled during all operations.

\begin{spad}
)abbrev domain FRAC Fraction
++ Author:
++ Date Created:
++ Date Last Updated: 12 February 1992
++ Basic Functions: Field, numer, denom
++ Related Constructors:
++ Also See:
++ AMS Classifications:
++ Keywords: fraction, localization
++ References:
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
            ++ \spad{canonical} means that equal elements are in fact identical.
  == LocalAlgebra(S, S, S) add
    Rep:= Record(num:S, den:S)
    coerce(d:S):% == [d,1]
    zero?(x:%) == zero? x.num


    if S has GcdDomain and S has canonicalUnitNormal then
      retract(x:%):S ==
--        one?(x.den) => x.num
        ((x.den) = 1) => x.num
        error "Denominator not equal to 1"

      retractIfCan(x:%):Union(S, "failed") ==
--        one?(x.den) => x.num
        ((x.den) = 1) => x.num
        "failed"
    else
      retract(x:%):S ==
        (a:= x.num exquo x.den) case "failed" =>
           error "Denominator not equal to 1"
        a
      retractIfCan(x:%):Union(S,"failed") == x.num exquo x.den

    if S has EuclideanDomain then
      wholePart x ==
--        one?(x.den) => x.num
        ((x.den) = 1) => x.num
        x.num quo x.den

    if S has IntegerNumberSystem then

      floor x ==
--        one?(x.den) => x.num
        ((x.den) = 1) => x.num
        x < 0 => -ceiling(-x)
        wholePart x

      ceiling x ==
--        one?(x.den) => x.num
        ((x.den) = 1) => x.num
        x < 0 => -floor(-x)
        1 + wholePart x

      if S has OpenMath then
        -- TODO: somwhere this file does something which redefines the division
        -- operator. Doh!

        writeOMFrac(dev: OpenMathDevice, x: %): Void ==
          OMputApp(dev)
          OMputSymbol(dev, "nums1", "rational")
          OMwrite(dev, x.num, false)
          OMwrite(dev, x.den, false)
          OMputEndApp(dev)

        OMwrite(x: %): String ==
          s: String := ""
          sp := OM_-STRINGTOSTRINGPTR(s)$Lisp
          dev: OpenMathDevice := _
                        OMopenString(sp pretend String, OMencodingXML)
          OMputObject(dev)
          writeOMFrac(dev, x)
          OMputEndObject(dev)
          OMclose(dev)
          s := OM_-STRINGPTRTOSTRING(sp)$Lisp pretend String
          s

        OMwrite(x: %, wholeObj: Boolean): String ==
          s: String := ""
          sp := OM_-STRINGTOSTRINGPTR(s)$Lisp
          dev: OpenMathDevice := _
                        OMopenString(sp pretend String, OMencodingXML)
          if wholeObj then
            OMputObject(dev)
          writeOMFrac(dev, x)
          if wholeObj then
            OMputEndObject(dev)
          OMclose(dev)
          s := OM_-STRINGPTRTOSTRING(sp)$Lisp pretend String
          s

        OMwrite(dev: OpenMathDevice, x: %): Void ==
          OMputObject(dev)
          writeOMFrac(dev, x)
          OMputEndObject(dev)

        OMwrite(dev: OpenMathDevice, x: %, wholeObj: Boolean): Void ==
          if wholeObj then
            OMputObject(dev)
          writeOMFrac(dev, x)
          if wholeObj then
            OMputEndObject(dev)

    if S has GcdDomain then
      cancelGcd: % -> S
      normalize: % -> %

      normalize x ==
        zero?(x.num) => 0
--        one?(x.den) => x
        ((x.den) = 1) => x
        uca := unitNormal(x.den)
        zero?(x.den := uca.canonical) => error "division by zero"
        x.num := x.num * uca.associate
        x

      recip x ==
        zero?(x.num) => "failed"
        normalize [x.den, x.num]

      cancelGcd x ==
--        one?(x.den) => x.den
        ((x.den) = 1) => x.den
        d := gcd(x.num, x.den)
        xn := x.num exquo d
        xn case "failed" =>
          error "gcd not gcd in QF cancelGcd (numerator)"
        xd := x.den exquo d
        xd case "failed" =>
          error "gcd not gcd in QF cancelGcd (denominator)"
        x.num := xn :: S
        x.den := xd :: S
        d

      nn:S / dd:S ==
        zero? dd => error "division by zero"
        cancelGcd(z := [nn, dd])
        normalize z

      x + y  ==
        zero? y => x
        zero? x => y
        z := [x.den,y.den]
        d := cancelGcd z
        g := [z.den * x.num + z.num * y.num, d]
        cancelGcd g
        g.den := g.den * z.num * z.den
        normalize g

      -- We can not rely on the defaulting mechanism
      -- to supply a definition for -, even though this
      -- definition would do, for thefollowing reasons:
      --  1) The user could have defined a subtraction
      --     in Localize, which would not work for
      --     QuotientField;
      --  2) even if he doesn't, the system currently
      --     places a default definition in Localize,
      --     which uses Localize's +, which does not
      --     cancel gcds
      x - y  ==
        zero? y => x
        z := [x.den, y.den]
        d := cancelGcd z
        g := [z.den * x.num - z.num * y.num, d]
        cancelGcd g
        g.den := g.den * z.num * z.den
        normalize g

      x:% * y:%  ==
        zero? x or zero? y => 0
--        one? x => y
        (x = 1) => y
--        one? y => x
        (y = 1) => x
        (x, y) := ([x.num, y.den], [y.num, x.den])
        cancelGcd x; cancelGcd y;
        normalize [x.num * y.num, x.den * y.den]

      n:Integer * x:% ==
        y := [n::S, x.den]
        cancelGcd y
        normalize [x.num * y.num, y.den]

      nn:S * x:% ==
        y := [nn, x.den]
        cancelGcd y
        normalize [x.num * y.num, y.den]

      differentiate(x:%, deriv:S -> S) ==
        y := [deriv(x.den), x.den]
        d := cancelGcd(y)
        y.num := deriv(x.num) * y.den - x.num * y.num
        (d, y.den) := (y.den, d)
        cancelGcd y
        y.den := y.den * d * d
        normalize y

      if S has canonicalUnitNormal then
        x = y == (x.num = y.num) and (x.den = y.den)
    --x / dd == (cancelGcd (z:=[x.num,dd*x.den]); normalize z)

--        one? x == one? (x.num) and one? (x.den)
        one? x == ((x.num) = 1) and ((x.den) = 1)
                  -- again assuming canonical nature of representation

    else
      nn:S/dd:S == if zero? dd then error "division by zero" else [nn,dd]

      recip x ==
        zero?(x.num) => "failed"
        [x.den, x.num]

    if (S has RetractableTo Fraction Integer) then
      retract(x:%):Fraction(Integer) == retract(retract(x)@S)

      retractIfCan(x:%):Union(Fraction Integer, "failed") ==
        (u := retractIfCan(x)@Union(S, "failed")) case "failed" => "failed"
        retractIfCan(u::S)

    else if (S has RetractableTo Integer) then
      retract(x:%):Fraction(Integer) ==
        retract(numer x) / retract(denom x)

      retractIfCan(x:%):Union(Fraction Integer, "failed") ==
        (n := retractIfCan numer x) case "failed" => "failed"
        (d := retractIfCan denom x) case "failed" => "failed"
        (n::Integer) / (d::Integer)

    QFP ==> SparseUnivariatePolynomial %
    DP ==> SparseUnivariatePolynomial S
    import UnivariatePolynomialCategoryFunctions2(%,QFP,S,DP)
    import UnivariatePolynomialCategoryFunctions2(S,DP,%,QFP)

    if S has GcdDomain then
       gcdPolynomial(pp,qq) ==
          zero? pp => qq
          zero? qq => pp
          zero? degree pp or zero? degree qq => 1
          denpp:="lcm"/[denom u for u in coefficients pp]
          ppD:DP:=map(retract(#1*denpp),pp)
          denqq:="lcm"/[denom u for u in coefficients qq]
          qqD:DP:=map(retract(#1*denqq),qq)
          g:=gcdPolynomial(ppD,qqD)
          zero? degree g => 1
--          one? (lc:=leadingCoefficient g) => map(#1::%,g)
          ((lc:=leadingCoefficient g) = 1) => map(#1::%,g)
          map(#1 / lc,g)

    if (S has PolynomialFactorizationExplicit) then
       -- we'll let the solveLinearPolynomialEquations operator
       -- default from Field
       pp,qq: QFP
       lpp: List QFP
       import Factored SparseUnivariatePolynomial %
       if S has CharacteristicNonZero then
          if S has canonicalUnitNormal and S has GcdDomain then
             charthRoot x ==
               n:= charthRoot x.num
               n case "failed" => "failed"
               d:=charthRoot x.den
               d case "failed" => "failed"
               n/d
          else
             charthRoot x ==
               -- to find x = p-th root of n/d
               -- observe that xd is p-th root of n*d**(p-1)
               ans:=charthRoot(x.num *
                      (x.den)**(characteristic()$%-1)::NonNegativeInteger)
               ans case "failed" => "failed"
               ans / x.den
          clear: List % -> List S
          clear l ==
             d:="lcm"/[x.den for x in l]
             [ x.num * (d exquo x.den)::S for x in l]
          mat: Matrix %
          conditionP mat ==
            matD: Matrix S
            matD:= matrix [ clear l for l in listOfLists mat ]
            ansD := conditionP matD
            ansD case "failed" => "failed"
            ansDD:=ansD :: Vector(S)
            [ ansDD(i)::% for i in 1..#ansDD]$Vector(%)

       factorPolynomial(pp) ==
          zero? pp => 0
          denpp:="lcm"/[denom u for u in coefficients pp]
          ppD:DP:=map(retract(#1*denpp),pp)
          ff:=factorPolynomial ppD
          den1:%:=denpp::%
          lfact:List Record(flg:Union("nil", "sqfr", "irred", "prime"),
                             fctr:QFP, xpnt:Integer)
          lfact:= [[w.flg,
                    if leadingCoefficient w.fctr =1 then map(#1::%,w.fctr)
                    else (lc:=(leadingCoefficient w.fctr)::%;
                           den1:=den1/lc**w.xpnt;
                            map(#1::%/lc,w.fctr)),
                   w.xpnt] for w in factorList ff]
          makeFR(map(#1::%/den1,unit(ff)),lfact)
       factorSquareFreePolynomial(pp) ==
          zero? pp => 0
          degree pp = 0 => makeFR(pp,empty())
          lcpp:=leadingCoefficient pp
          pp:=pp/lcpp
          denpp:="lcm"/[denom u for u in coefficients pp]
          ppD:DP:=map(retract(#1*denpp),pp)
          ff:=factorSquareFreePolynomial ppD
          den1:%:=denpp::%/lcpp
          lfact:List Record(flg:Union("nil", "sqfr", "irred", "prime"),
                             fctr:QFP, xpnt:Integer)
          lfact:= [[w.flg,
                    if leadingCoefficient w.fctr =1 then map(#1::%,w.fctr)
                    else (lc:=(leadingCoefficient w.fctr)::%;
                           den1:=den1/lc**w.xpnt;
                            map(#1::%/lc,w.fctr)),
                   w.xpnt] for w in factorList ff]
          makeFR(map(#1::%/den1,unit(ff)),lfact)
\end{spad}

\start
Date: Fri, 03 Feb 2006 13:27:55 -0600
From: MathAction (rrogers)
To: MathAction
Subject: [#33 GCL fails to compile on Fedora Core 3] Fedora 3 fc3 Remedy??

Not exactly a fix, but....
Nothing worked with kernel (2.6.12-1.1381_FC3); 0 >echo ... , setarch...
But a fresh compile rm, tar, worked for kernel (2.6.11-1.35_FC3)
The result does not run with 2.6.12, so I changed the default boot to 2.6.11
Which gets me to what a want, a full axiom on linux.

Ray (rrogers)

\start
Date: Fri, 03 Feb 2006 13:46:36 -0600
From: MathAction (rrogers)
To: MathAction
Subject: [#127 Building axiom from source fails on my Fedora Core 3] Resolution fedora fc3

As I mentioned elsewhere
Kerenl 2.6.12 ...  would not build even with echo... or setarch
Kernel 2.6.11-1.35_FC3  allowed a build without any fixes

\start
Date: Fri, 03 Feb 2006 17:25:17 -0600
From: MathAction (root)
To: MathAction
Subject: [#127 Building axiom from source fails on my Fedora Core 3]

Roy,

Can you post the console trace of the failing axiom build
from the 'make' until the failure?

I can't imagine why there is a kernel issue except that
perhaps one has SELinux enabled by default and the other
does not.

\start
Date: Fri, 03 Feb 2006 17:31:41 -0600
From: MathAction (rrogers)
To: MathAction
Subject: [#127 Building axiom from source fails on my Fedora Core 3] Building axiom from source fails on my	

Sure I will do it tomorrow, but it's the old sbrk thing that wouldn't
cler with the other kernel.

Ray

\start
Date: Fri, 03 Feb 2006 21:09:58 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#264 tangle not working in Doyen CD pamphlets]

Using ehe 'tangle' button in pamphlet files on the Doyen CD to
retrieve a code chunk results in the message "Sorry, the requested
resource does not exist."

The reason for this failure is that an external Python script
named 'tangle.py' is missing from the Extensions directory.

\start
Date: Sat, 04 Feb 2006 16:33:47 -0600
From: MathAction (rrogers)
To: MathAction
Subject: [#127 Building axiom from source fails on my Fedora Core 3] Building axiom fc3 etc... compile listings.

Tim,
You will the make outputs at http://www.plaidheron.com/ray/temp
together with the batch file used to generate them.
BTW: My browser crashes on some searchs, and the listing indicates some errors together with missing NAG files.  Should I try to fix the errors?

\start
Date: Sat, 04 Feb 2006 06:23:19 -0600
From: MathAction (unknown)
To: MathAction
Subject: [WesterProblemSet] Even more confusion!

When I click on any of those buttons, the same page indicating the non-existence of the document under consideration appears.
But on hitting refresh, and then clicking on the button seem to work for me.

What's refresh anyway? And what does tangle button, which makes it appearance on the rhs of the greyish download strip, does?

\start
Date: Sat, 04 Feb 2006 13:46:11 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [WesterProblemSet] bug fixed

I think I found what was causing the 'pdf' and related files to be
deleted. It turned out that the LaTeX output generation in another
part of AxiomWiki (actually part of LatexWiki - latexWrapper.py) was
being too agressive about cleaning up what it assumed were just unneeded
temporary files. The result was that if someone clicked 'Save' on some
other page that contained some new LaTeX or Axiom code, then as a
side-effect of generating the required png images, it also deleted
files that it should not have.

Please let me know if the problem of disappearing files happens again.

\start
Date: Sat, 04 Feb 2006 11:02:30 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [WesterProblemSet] something seems remove the files

Must be some subtle coding error I guess, but something seems
cause these files to disappear after some period of time. Right
now I do not have any idea of the possible cause.

The 'refresh' button causes the entire contents of the page to
be re-generated from the underlying source (i.e. the source is
what you see whey you click 'edit') and is the same as the contents
of the 'src' link - it is the pamphlet source file itself. 'refresh'
runs 'weave' on the pamphlet file to generate the LaTeX ('tex')
file and then runs latex to generate the 'dvi', and dvips to
generate the 'ps' file and ps2pdf to generate the 'pdf' and
finally dvipng to display the graphic image of the first page.

Pamphlet files are intended to be used for *both* documentation
and the program code itself.

'tangle' is used to extract the code chunks (programs) from the
pamphlet file. In the case of the Wester problem set, this
pamphlet file does not contain any separately identified code
chunks (but it should!).

For more information about pamphlet files see [Literate Programming].

\start
Date: Sat, 4 Feb 2006 17:43:35 -0800 (PST)
From: Cliff Yapp
To: list
Subject: No go TLA on windows

Followed the instructions on http://wiki.axiom-developer.org/BuildAxiom
precisely this time and hit the same problem:


********************************
NO CHECKSUMS FOUND FOR REVISION
 (unsigned archive, continuing anyway)

  archive: arch@axiom-developer.org--axiom
  revision axiom--main--1--base-0

********************************

* from import revision:
arch@axiom-developer.org--axiom/axiom--main--1--base-0
* patching for revision:
arch@axiom-developer.org--axiom/axiom--main--1--patch-1
* patching for revision:
arch@axiom-developer.org--axiom/axiom--main--1--patch-2
* patching for revision:
arch@axiom-developer.org--axiom/axiom--main--1--patch-3
* patching for revision:
arch@axiom-developer.org--axiom/axiom--main--1--patch-4
tar.real.exe:
axiom--main--1--patch-4.patches/new-files-archive/{arch}/axiom/axiom--main/axiom--main--1/arch@axiom-developer.org--axiom/patch-log:
Could not create directory: No such process
tar.real.exe: Error exit delayed from previous errors
PANIC: arch_get_patch: tar exitted with non-0 status

I'm trying the hard way - getting base-0, doing get-changeset on the
sets, and applying them.  Maybe that will provide more insight.

\start
Date: Sat, 04 Feb 2006 23:16:19 -0600
From: MathAction (root)
To: MathAction
Subject: [#127 Building axiom from source fails on my Fedora Core 3]

Ray,

If you can find the cause of the hyperdoc crashes that would be most 
useful.

\start
Date: Sat, 4 Feb 2006 22:12:16 -0800
From: Antoine Hersen
To: list
Subject: Preferred SCM

Hello,

I am getting a bit confused, which is the preferred source code
management for developing axiom ?

Darcs, TLA, CVS ?
All the above ?

\start
Date: Sat, 4 Feb 2006 22:37:06 -0800
From: Antoine Hersen
To: list
Subject: Documentation

Hello,

I think the good documentation is a great asset of Axiom.

But I am a bit confuse by it's location, I got the Vol1 from Lulu(
since a couple of day, I should have finish to read it by tomorrow
more comment later).

I know it is in the src/doc/ directory.

But what about the other volumes ?

I found one in src/interp vol5

Is src/doc/ComputerTutorial.pamphlet suppose to be one of the volume ?
It is not mentioned in the Makefile.

\start
Date: Sun, 5 Feb 2006 02:21:35 -0500
From: Tim Daly
To: Antoine Hersen
Subject: Re: Preferred SCM

The primary sources are maintained under arch due to the availability
of "changesets".

The secondary sources (at sourceforge and savannah) are under CVS
because that's the available system.

The wiki sources are maintained under darcs.

The reasons are historical. There was a bit of debate about using
changesets instead of CVS. SVN was not available at the time. Arch
was the front-runner and had some of the features of bitkeeper.
We considered using bitkeeper but that's a commercial product.

It still is not clear to me which system is optimal. Arch is powerful
but we only use the changeset feature. Darcs is easy but not as powerful
as Arch. CVS is universal but lacks changesets. SVN combines some of
these features. ... and then there is 'git' which I've recently 
experimented with. 


Generally the axiom sources are posted in arch, savannah, and sourceforge
within 24 hours of each other so they should be identical. Thus you can
use either arch or cvs.

\start
Date: Sun, 5 Feb 2006 03:08:59 -0500
From: Tim Daly
To: Antoine Hersen
Subject: Re: Documentation

The other volumes are still being written or are in the proposal stages.

Do 
  tla get axiom--book--1
and you can see volumes 1-4 (the volume 1 up there has been rewritten
so the volume 1 is out of date).

\start
Date: Sun, 05 Feb 2006 12:07:56 -0600
From: MathAction (unknown)
To: MathAction
Subject: [FreeAldor] 

Varun

\start
Date: Sun, 05 Feb 2006 12:35:51 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#127 Building axiom from source fails on my Fedora Core 3] previous hyperdoc bug reports

See #153 #168 #236

Note in particular solution to the libdb.text problem in #153

\start
Date: Sun, 05 Feb 2006 13:49:56 -0600
From: MathAction (rrogers)
To: MathAction
Subject: [#127 Building axiom from source fails on my Fedora Core 3] Building axiom fc3 -- Browser

This is fun?

I found solution #153 on my own (should have looked here first).

BTW: you have several old libdb.text floating around that don't get
undated; and confuse the issue.

int/algebra   has the right time stamp

Strangness: after I did the copy, browse barfed on the libdb.text
lines having dInteger

For instance Brose-> Integer->Documentation

Looking around I did cut and pastes for those lines (which is how I
reached the conclusion)

Upon pasting the lines back they seemed to work??  

and of course there is another problem...

Sometimes hyperdoc (?) complains and dies    "NIL is not of type STREAM."

For instance: Browse -> Integer -> Operations

Ah well, I looked through the FAQ but found nothing.  Perhaps I will
poke around some more.
 
\start
Date: Mon, 6 Feb 2006 02:18:54 -0800
From: Antoine Hersen
To: list
Subject: Impression Axiom book vol 1

Hello,

I got my axiom book from Lulu. I have read to page 180 so far.

Here my comments :
My point of view ; a CS student with very good experience in ML, a
strong math background and which want to implement some useful
addition to axiom for is master thesis.

First it is an incredible job which as been done here and a very good
opportunity for axiom.
I feel kind of bad about giving critics not having contributed to it.

Physical appearance :

The binding is glued but seem strong enough so far.
The margin are way to wide especially at the bottom, and also on the
side even if you take in account note taking.
The typography is clear for me, look like any tex document coming out
of a good laser printer

General remark :
Chapter 3 should be spitted right after ( somewhere ).
It will be nice if the loop chapter had sub chapter that show in the indexes.

Having more of those boxy resume stuff will be very nice especially
for use as reference later.

I am still a bit confused over Domain and Category but once I will
have figured it out I will try to create some visual output that can
help other.

It will also be nice to have a set of exercise, I think it is the best
way to learn. I know easy to say difficult to make.


Presentation :
My biggest annoyance is the output format of the interactive prompt.
Seem to be a huge space waste, look at page 24,25 for example.
I'll try to experiment to see if I can find a more pleasing
solution(maybe smaller space line or smaller font for the Type output)

Also when a long "program" example is given like p85 its repetition in
the interactive loop output is a waste of space, maybe a \cdots will
save some space

Detail grief :
p28 ch 3.2.4:
What is the difference between Symbol and Variable ?

p35 ch 3.3.2
The example for truncate and round are not very instructive. The same
number should be used.
round(3.7)
truncate(3.7)
round(-3.7)
truncate(-3.7)

p36 ch 3.3.3
The function are trivial just one example and a table will be more
useful and more space savvy.

p43 ch 3.4.3
about radix, when number are displayed in a base above 10 what is the
convention to display them( I know for hexa but how is the convention
extend)

p43 ch 3.4.3
I found the output for continued fraction weird.


p48 ch 3.5.2
Accessing earlier result has been aborded more lengthy previously in
ch 3.2.2, so it is redundant.

p48 ch 3.5.3
Similarly for splitting line, seen in chapter 3.2.8 Long lines, common
example but the latest version is more lengthy  with an extra example

p48 ch 3.5.4
Again for comments similar to 3.2.9

p72 ch 3.7.2
It is not clearly indicated that the value of a block if not escaped
by => is the last expression of the block.
a:= (a:=3,b:=5;a*b)

p79 ch 3.7.4
In the last example
if h > 3.1 then
=091.0
  else
=09Z:= cos(h)
=09max(X,05)

I suppose that the it should be max(Z,0.5),
any way why max( xy, 10) return xy ?

p84 ch 3.7.5
in the example program for while loop involving matrix
the "-- Don't look any further" comment should be for the previous expressi=
on
because the meaning of "break" is clear but by setting "r:= lastrow"
we do prevent the loop to look any further and it is less obvious.

p86 ch 3.7.5
When discussing the "such that" clause of for loop
the prototype given is
=09for var --- BoolExpr in seg repeat loopBody

but the use is
=09for i in 1..10 | prime?(i) repeat ...

so should a prototype more like
=09for var in seg | BoolExpr repeat loopBody
more accurate ? Or is there reason for it ?

p90 ch 3.8
The ONLY typo I have found "you have to Pmap factor onto the numerator"
I guess it should be "you have to map factor onto the numerator"

p103 ch 3.9
the function howMany increase the result found in the table, I thing
it will be more elegant if it only returned the current value and for
the loop to do the increasing

howMany(k) == (n:=search(k,t), n case "failed" => 0; n)

for p in prime(2,10000) repeat (m:= p rem 5; t.m :=  1 + howMany(m)); t

p103 ch 3.9
at the very end on the example for union
=09dog:= 21
should be added to
=09dog:="Whisper"
as an example of union

p114 ch 3.13
In the first example, I do not know what is csc and csch, they are not
in the index.
Also for compleLimit it is not precised how to denote complex
infinity, just infinity ?

p117 ch 3.14
The series f is defined twice identically without reason.

p178 ch 5.2.2
On where to put parentheses and when not, I got really confused out of that=
.
I knew before but not after.
I do not thing such chapter is necessary it add a lot of complexity
for no reason.

p179 ch 5.2.4
It explain what is a modes but no idea what is it for ???

p180 ch 5.2.5
The examples for abbreviation are a bit too numerous, I am sure
everybody understand what is it.

END

Very general remark( the one that are vague and easy to make but
difficult to implement) :

It will be nice to have an extended chapter 1. That is more longer
examples of "useful" stuff you can do.
What I found lacked the most is an impression of what you can do. It
is the first Volume so the first one which is going to be read so it
need to make the best impression if we do not want it to be the only.

Personally I found it very exciting to see the "strong mathematical
typing" and I am appealed by the possibility.

But if that was my first exposition to a CAS it will feel short. It
lack a sense of  "practical" mathematical capability. If I had a
mathematical problem to solve I will not be any more advanced. It will
give me no idea of what is implemented in Axiom to help me.

Maybe it is not what this volume in intended to be but the name
Tutorial is kind of miss leading. The web site should be more clear
about what to expect from it.

Again I am not at all disappointed but if someone with mathematical
problems to solve and not so much experience with CAS got the book he
might be.
( The 30 Year Horizon subtitle is great when you have some CAS history
background and co, but for newbie it can be very scary, do it mean I
need 30 years to be able to correctly use it, do it mean it will work
correctly in 30 years ? )

Sure critic is easy,

Thanks a lot for publishing the book, very nice and usefull work.


\start
Date: Mon, 06 Feb 2006 05:43:23 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [FreeAldor] ...

Aldor is a great language.

Making the sources of the compiler available would greatly help in
order to attract more developers and to make the compiler more robust.

Ralf Hemmecke

\start
Date: Mon, 6 Feb 2006 07:56:30 -0500
From: Tim Daly
To: Antoine Hersen
Subject: Re: Impression Axiom book vol 1

Antoine,

Thanks for the feedback.

The actual text is in src/doc/bookvol1.pamphlet.

Feel free to modify it and then do:

diff -Naur original new >new.patch

and send me the patch files. If you're interested enough and want
to write a longer chapter 1 or shorten the whitespace or improve
the indexing I'm happy for the help. Given enough input you could
end up with your name on the book.

\start
Date: Mon, 06 Feb 2006 06:14:24 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [Fraction] 

Maybe this text should go into another place (where?), but the above code shows some danger.
It says (look at the representation):

\begin{spad}
Fraction(S: IntegralDomain): QuotientFieldCategory S with 
     ...
   == LocalAlgebra(S, S, S) add
    Rep:= Record(num:S, den:S)
    ...
\end{spad}
and in LocalAlgebra one can read
\begin{spad}
LocalAlgebra(A: Algebra R,
             R: CommutativeRing,
             S: SubsetCategory(Monoid, R)): Algebra R with
        ...
  == Localize(A, R, S) add
        ...
\end{spad}
where
\begin{spad}
Localize(M:Module R,
         R:CommutativeRing,
         S:SubsetCategory(Monoid, R)): Module R with
    ...
 ==
  add
      Rep:= Record(num:M,den:S)
      ...
\end{spad}

If someone is going to change the Rep of Localize say
\begin{spad}
Rep := Record(somedata: SomeType, num: M, den: S)
\end{spad}
then I suspect the code of Fraction will not work anymore.
The implementation of LocalAlgebra is fine, since it does not introduce a Rep,
but in Fraction there should also be no appearance of Rep.

The implementation of Fraction should completely do without Rep
(information hiding) since it should not know about the concrete
representation of elements in the domain LocalAlgebra.

In fact, the Category for Localize(M, R, S) is not rich enough. It
already exports two functions

\begin{spad}
      numer: % -> M
         ++ numer x returns the numerator of x.
      denom: % -> S
         ++ denom x returns the denominator of x.
\end{spad}
but obviously its use in Fraction call for destructive functions
\begin{spad}
set!: (%, 'num', M) -> M
set!: (%, 'den', S) -> S
\end{spad}

\start
Date: Mon, 06 Feb 2006 13:35:14 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Preferred SCM

I hope Axiom stays with GNU arch. In particular, in the future we could 
more and more exploit the "multiple archives" feature and the "star-merge".

I am relatively new to Arch, but after reading about it and about 
Subversion. I think GNU Arch is more powerful even if it lacks nice 
GUIs. (BTW there is xtla for emacs http://wiki.gnuarch.org/xtla -- 
unfortunately I haven't had time to install it properly.)

I particular "star-merge" sounded quite nice to me. (And that is missing 
in SVN.)

In fact development could work like that:
Tim is maintaining the "official" Axiom sources and only he has write 
access to it (but anyone can read it).

Everyone could open up his own archive, ie just branch from the latest
official (axiom--main--1) version (for example axiom--myfeature--1.0)
and develop into that archive until some feature has been
completed. If in the meantime, axiom--main--1 got another patch, it
would be easy to integrate that into axiom--myfeature--1.0.

Finally send a mail to Tim and tell him the place of the archive. Tim
(or maybe in the future any other group of reviewers) could check the
new feature and integrate that into axiom--main--1 by just calling
star-merge, see

http://regexps.srparish.net/tutorial-tla/development-branches.html

Ralf

PS: If time permits, I'll add some section into volume 4 "Developer's 
Guide".


On 02/05/2006 08:21 AM, root wrote:
> The primary sources are maintained under arch due to the availability
> of "changesets".
> 
> The secondary sources (at sourceforge and savannah) are under CVS
> because that's the available system.
> 
> The wiki sources are maintained under darcs.
> 
> The reasons are historical. There was a bit of debate about using
> changesets instead of CVS. SVN was not available at the time. Arch
> was the front-runner and had some of the features of bitkeeper.
> We considered using bitkeeper but that's a commercial product.
> 
> It still is not clear to me which system is optimal. Arch is powerful
> but we only use the changeset feature. Darcs is easy but not as powerful
> as Arch. CVS is universal but lacks changesets. SVN combines some of
> these features. ... and then there is 'git' which I've recently 
> experimented with. 
> 
> 
> Generally the axiom sources are posted in arch, savannah, and sourceforge
> within 24 hours of each other so they should be identical. Thus you can
> use either arch or cvs.

\start
Date: Mon, 06 Feb 2006 08:01:15 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#263 ContinuedFraction returns incorrect types] Re: Fraction R returns R when R is a field

Thinking about it, I realized that this is not the proper solution,
since 'Fraction R' provides some operations, for example 'denominator'
which 'R' does not necessarily have and I think it would be wrong to
equip every 'Field' with this operation, which would then be
necessary. Thus, either

- Axiom's interpreter should not complain about types like 'Fraction
   Float'. In this case, 'denominator' will always return '1', of
   course. Note that you can perfectly well calculate with objects of
   type 'Stream Fraction Fraction Integer', no problem occurs. Or

- operations that want to return Fraction R have to check whether R is a field.

The code that excludes constructions like 'FRAC FRAC' and 'FRAC R'
when 'R' is a field is in 'clammed.boot.pamphlet', lines 108-112.

Possibly we want to allow 'Fraction Field' but disallow 'Fraction Fraction'?

Martin

\start
Date: Mon, 06 Feb 2006 08:07:20 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [Fraction] 

I think that you are both right with the place where you put your
comment and with your comment itself. Only: I suggest that you don't
use !\begin{axiom} and \end{axiom} to comment code, it get's all
compiled :-) Although it looks very nice...

\start
Date: Mon, 06 Feb 2006 10:08:25 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [#263 ContinuedFraction returns incorrect types] FRAC FRAC ID

Since "add { ... }" is a value in Aldor/Axiom, [Fraction] should/could
be implemented as follows:

\begin{spad}
Fraction(S: IntegralDomain): QuotientFieldCategory S with ...
 == if S has Field
      then S add 
         -- additional functions like "denom" etc.
      else ...
         add 
           -- old code goes here
\end{spad}

Well, that means the representation of 'FRAC S' depends on whether S
is already a field or not.

\start
Date: Mon, 06 Feb 2006 17:15:59 +0100
From: Ralf Hemmecke
To: list
Subject: Re: [Fraction]

Hello,

On 02/06/2006 03:07 PM, kratt6 wrote:

> I think that you are both right with the place where you put your
> comment and with your comment itself. Only: I suggest that you don't
> use !\begin{axiom} and \end{axiom} to comment code, it get's all
> compiled :-) Although it looks very nice...

Well, I won't put code into \begin{spad} ... \end{spad}, but nobody has 
told me how I should quote code.

Should I use

<pre>
CODE GOES HERE
</pre>

or should I use \begin{verbatim} .. \end{verbatim} or what?

\start
Date: Mon, 06 Feb 2006 10:14:16 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Fraction] using begin{spad} ... to comment code

I don't see any problem using !\begin{spad}...\end{spad}. I think
it looks good, although as Martin says, Axiom Wiki does try to
compile the code. On most browsers the compile errors will be
hidden by the '+' folding. However the normal way to quote code
is by using '::' at the end of the line, leave a blank line and
then indent the code, like this::

  set!: (%, 'num', M) -> M
  set!: (%, 'den', S) -> S

If you want to also highlight the text with color you can use
HTML coding such as::

  <pre style="background-color:pink">
    set!: (%, 'num', M) -> M
    set!: (%, 'den', S) -> S
  </pre>

<pre style="background-color:pink">
  set!: (%, 'num', M) -> M
  set!: (%, 'den', S) -> S
</pre>

\start
Date: Mon, 06 Feb 2006 10:24:10 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Fraction] information hiding

Ralf Hemmecke wrote:

> Fraction should completely do without Rep ...

I think your conclusion is right. I worry that there may be
numerous places in the Axiom library where this type of violation
of the "object-oriented" paradigm occurs, for example we discussed
recently similar problems in the OutputForm domain. I think we
need to first document these cases - as you have done here and
in the actual source distribution pamphlet files - and then
correct these problems.

\start
Date: Mon, 06 Feb 2006 10:38:15 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#263 ContinuedFraction returns incorrect types] static types

Ralf, do you think you could provide some example code that
does this and actually works? I remain a little sceptical.

I think Axiom's two-level type system is going to get in
the way. Although it is true that types in Axiom are "first
order objects" in the sense that we can assign them to variables
etc., the kind of things that we can actually do with them is
very limited. For example, I see no way in Axiom, SPAD or Aldor
to have::

  FRAC FRAC INT = FRAC INT

since 'FRAC INT' is  static type and 'FRAC FRAC INT' is another
static type. In Axiom there is no way to write a function which
returns different types depending on it's parameters::

  fType(x) ==
     x=0 ==> Integer
     Float

  t:fType(1):=1.0

because types like 'Integer' and 'Float' are not members of some
domain in the same since in which '1' and '-1' are members of
'Integer'. And further there is no equality defined over types.

Or do I not understand something quite fundamental here?

Perhaps what you are suggesting amounts to ensuring that, as
types these two are at least functionally equivalent?

\start
Date: Mon, 6 Feb 2006 20:24:25 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: [Fraction]

Ralf,

On Monday, February 06, 2006 11:16 AM you wrote:
> ...
> Well, I won't put code into \begin{spad} ... \end{spad},
> but nobody has told me how I should quote code.

Using \begin{spad} ... \end{spad} does not do any harm.

The entry labelled "verbatim::" in the point-and-click menu
under the Text column is an attempt to help you remember the
right way to do this. Click on the word "verbatim" and it
will insert the necessary text.

>
> Should I use
>
> <pre>
> CODE GOES HERE
> </pre>

That would be ok.

>
> or should I use \begin{verbatim} .. \end{verbatim}

Although this will work, I do not recommend it. {verbatim} will
be interpreted by LaTeX in the same way as \begin{equation} and
rendered on the Axiom Wiki as an image. You might not like the
appearance of the result.

> or what?

The standard way according the the Structured Text conventions
is to use '::' like this::

  Should I use::

    CODE GOES HERE

Note that blank line and the indentation of the CODE.

\start
Date: 07 Feb 2006 02:54:54 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Preferred SCM

Ralf Hemmecke writes:

| I hope Axiom stays with GNU arch. In particular, in the future we
| could more and more exploit the "multiple archives" feature and the
| "star-merge".
| 
| I am relatively new to Arch, but after reading about it and about Subversion. I think GNU Arch is more powerful even if it lacks nice GUIs. (BTW there is xtla for emacs http://wiki.gnuarch.org/xtla -- 
| unfortunately I haven't had time to install it properly.)
| 
| I particular "star-merge" sounded quite nice to me. (And that is
| missing in SVN.)

Similar debate had popped recently for GCC -- which used to use CVS
since at least EGCS days.  We finally decided to move to SVN.  It was
painful for some of us -- especially due to specific demands of GCC (a
special SVN 1.3 release candidate had been made available).

After a while, the dust set down.  I operate most of the time remotely
behind a terminal -- so no gui fancy things.  With other projects, I
continue to use CVS.  I think if Axiom decided to move to SVN, that
will be a good move.  For me, arch is a "curiosity", in the sense that
Axiom is the only project that "requires"  me ("require" is not the right
term, as I also have the CVS tree right here) to use it.

\start
Date: Mon, 6 Feb 2006 21:55:22 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Preferred SCM

Gaby,

I keep the savannah and sourceforge CVS sites up to date and in sync
with the arch site so there is no requirement to use arch. i suppose
if we grow to the size of the linux development environment we'd have
to standardize on something but I suspect the archival tool would be
the least of our concerns.

\start
Date: Mon, 06 Feb 2006 22:29:17 -0500
From: William Sit
To: list
Subject: Numerical package and GotoBLAS

For any one interested in adding numerical packages to Axiom, you probably
already know about Linpack, BLAS, and even GotoBLAS. I just came across this:

http://www.utexas.edu/features/2006/goto/index.html

\start
Date: Tue, 7 Feb 2006 09:18:05 +0100
From: David Mentre
To: Tim Daly
Subject: Re: Preferred SCM

Hello,

2006/2/7, Tim Daly:
> I keep the savannah and sourceforge CVS sites up to date and in sync
> with the arch site so there is no requirement to use arch. i suppose
> if we grow to the size of the linux development environment we'd have
> to standardize on something but I suspect the archival tool would be
> the least of our concerns.

As Tim, I don't think that the choice of a Source Code Management
system is that important, as long as the SCM of choice is available as
free software and is not to complicated to install (I know, subjective
criterion ;-).

Regarding Arch, Tom Lord, its official maintainer, has officially
stopped to develop it. Arch forks, Bazaar and Bazaar-ng, do not seem
to be ready for real use. As I'm using Arch for my own project for
more that two years now, I'm also considering switching to a new SCM
(Arch is quite irritating sometimes).

I think I have the same requirements as Axiom (efficiency, Windows
availability, decentralized if possible) and my short list is
Mercurial, Subversion and SVK. Interestingly, SVK seems to be a good
compromise between Subversion and Arch: it works in a decentralized
manner as Arch (with apparently the same merge algorithms) but it is
compatible with de-facto standard Subversion and can works daily with
svn repositories. For interested people, see relevant thread:
  http://thread.gmane.org/gmane.politics.organizations.demexp.devel/785

It might become of topic for this list but I would be interested about
real SCM experiments. I already know about Subversion (I'm using it at
work, under Windows) and Arch.

PS for Tim: Tim, regarding synchronization of your CVS repositories
with you Arch tree, you should take a look at Tailor which is designed
exactly for that:
  http://www.darcs.net/DarcsWiki/Tailor
"""
Tailor is a tool to migrate changesets between ArX, Bazaar, Bazaar-NG,
CVS, Codeville, Darcs, Git, Mercurial, Monotone, Subversion and Tla
repositories.
"""
\start
Date: Tue, 07 Feb 2006 02:23:28 +0100
From: Ralf Hemmecke
To: list
Subject: Re: [#263 ContinuedFraction returns incorrect types] static types

On 02/06/2006 05:38 PM, Bill Page wrote:
> Changes http://wiki.axiom-developer.org/263ContinuedFractionReturnsIncorrectTypes/diff
> --
> Ralf, do you think you could provide some example code that
> does this and actually works? I remain a little sceptical.
> --
> forwarded from http://wiki.axiom-developer.org/263ContinuedFractionReturnsIncorrectTypes#msg20060206103814-0600@wiki.axiom-developer.org

Maybe I should put that code somewhere on the AxiomWike (where?) so that
is is not forgotten inside the archive.

I did not bother to try to write it in SPAD. With Aldor it seemed so
much easier to me.

Bill, I hope you like it.

 > I think Axiom's two-level type system is going to get in
 > the way. Although it is true that types in Axiom are "first
 > order objects" in the sense that we can assign them to variables
 > etc., the kind of things that we can actually do with them is
 > very limited. For example, I see no way in Axiom, SPAD or Aldor
 > to have::
 >
 >   FRAC FRAC INT = FRAC INT
 >
 > since 'FRAC INT' is  static type and 'FRAC FRAC INT' is another
 > static type.

Well the reason for not having equality is not that FRAC INT and
FRAC FRAC INT are different, but just the lac of a function "=" of the 
right type that does the right thing.

For frac.as below, one would need a function:

=: (Field, Field) -> Boolean

Note that Field is a category and not a domain.
The problem is that I have no idea how to implement such a function.
I even guess that at the moment the runtime system does not provide 
anything nice that could be used to check whether two domains are, in 
fact, the same. (Maybe Peter Broadbery knows a bit more about the 
internals.) In principle, however, I think that should be doable just by 
comparing two appropriate pointers.

 > In Axiom there is no way to write a function which
 > returns different types depending on it's parameters::
 >
 >   fType(x) ==
 >      x=0 ==> Integer
 >      Float
 >
 >   t:fType(1):=1.0
 >
 > because types like 'Integer' and 'Float' are not members of some
 > domain in the same since in which '1' and '-1' are members of
 > 'Integer'. And further there is no equality defined over types.

Clearly, a compiler would have to know
a) what is the type of x, and
b) what is the return type of fType.

The return type in that case could be figured out by the intersection of 
the signatures of the type of Integer (ie, its category Integer belongs 
to) and the type of Float.

But let's make things more concrete. Add the following definition
IDom(b: Boolean): IntegralDomain == {
	if b then MyInteger else MyRational
}
to the code below and also add

	j0: IDom false  := 1;
	j1: IDom true   := 1;
	
	stdout << "IDom false: " << j0 + j0 << newline;
	stdout << "IDom true : " << j1 + j1 << newline;

into the function "main". Then compile and run again.

You will see the output:

IDom false: (2)/(1)
IDom true : 2

But, of course, IDom(true) and IDom(false) have the same type, namely 
IntegralDomain. So, true, Axiom/Spad/Aldor does not let you return you 
something of different types. Well, there are dependent types... but 
that is another story.

The line

 >   t:fType(1):=1.0

cannot work since fType(1) and Float are not the same. A compiler has to 
figure out a common return type for the function fType. And clearly, 
that will not be the same as the category of Float.

Even if one writes

MyInt: with {1: %} == Integer

MyInt and Integer are not the same since they belong to different 
categories. For example, there is no addition in MyInt.

--------- FILE frac.as ---------------------------------------
-- Compile with
--   aldor -mno-mactext -fx -laldor frac.as
-- results in

--: "frac.as", line 51: Fraction(R: IntegralDomain): FractionField R == {
--:                     .........^
--: [L51 C10] #1 (Warning) Function returns a domain that might not be
constant (which may cause problems if it is used in a dependent type).

-- Ignore this warning.

-- Then running the program gives

--: Integer:   2
--: Rational:  (2)/(1)
--: Rational1: (2)/(1)
--: Rational2: ((2)/(1))/((1)/(1))

-- which shows that the domain constructor "Fraction" does not construct
-- another representation in case its argument is already a field.

#include "aldor"

define IntegralDomain: Category == OutputType with {
	0: %;
	1: %;
	+: (%, %) -> %;
	-: % -> %;
	*: (%, %) -> %;
}

define Field: Category == with {
	IntegralDomain;
	inv: % -> %;
}

define FractionField(R: IntegralDomain): Category == with {
	Field;
	numerator: % -> R;
	denominator: % -> R;
}

Fraction0(R: IntegralDomain): FractionField R == add {
	Rep == Record(num: R, den: R);
	import from Rep;
	0: % == per [0, 1];
	1: % == per [1, 1];
	numerator(x: %): R == rep(x).num;
	denominator(x: %): R == rep(x).den;
	-(x: %): % == per [- numerator x, denominator x];
	inv(x: %): % == per [denominator x, numerator x];
	(x: %) + (y: %): % == {
		n := numerator x * denominator y + denominator x * numerator y;
		d := denominator x * denominator y;
		per [n, d];
	}
	(x: %) * (y: %): % == {
		n := numerator x * numerator y;
		d := denominator x * denominator y;
		per [n, d];
	}
	(tw: TextWriter) << (x: %): TextWriter == {
		import from String;
		tw << "(" << numerator x << ")/(" << denominator x << ")";
	}
}
Fraction1(F: Field): FractionField F == F add {
	numerator(x: %): F == x pretend F;
	denominator(x: %): F == 1$F;
}

Fraction(R: IntegralDomain): FractionField R == {
	if R has Field then Fraction1(R pretend Field) else Fraction0 R;
}

MyInteger:   IntegralDomain == Integer add;
MyRational:  FractionField MyInteger  == Fraction  MyInteger;
MyRational1: FractionField MyRational == Fraction  MyRational;
MyRational2: FractionField MyRational == Fraction0 MyRational;

main(): () == {
	import from TextWriter, String, Character;
	i: MyInteger    := 1;
	r0: MyRational  := 1;
	r1: MyRational1 := 1;
	r2: MyRational2 := 1;
	stdout << "Integer:   " << i  + i  << newline;
	stdout << "Rational:  " << r0 + r0 << newline;
	stdout << "Rational1: " << r1 + r1 << newline;
	stdout << "Rational2: " << r2 + r2 << newline;
}

main();

\start
Date: Tue, 07 Feb 2006 02:53:22 +0100
From: Ralf Hemmecke
To: Antoine Hersen
Subject: Re: Impression Axiom book vol 1

Hello,

> p86 ch 3.7.5
> When discussing the "such that" clause of for loop
> the prototype given is
> 	for var --- BoolExpr in seg repeat loopBody
> 
> but the use is
> 	for i in 1..10 | prime?(i) repeat ...
> 
> so should a prototype more like
> 	for var in seg | BoolExpr repeat loopBody
> more accurate ? Or is there reason for it ?

Compare also with the Aldor User Guide page 53:
There is a concept of "Generator" in Aldor that I haven't yet found in 
Axiom.

\start
Date: Tue, 7 Feb 2006 04:10:05 -0500
From: Bill Page
To: David Mentre
Subject: RE: Preferred SCM

On Tuesday, February 07, 2006 3:18 AM David Mentre wrote:

> ...
> For interested people, see relevant thread:
>  
> http://thread.gmane.org/gmane.politics.organizations.demexp.devel/785
>
> It might become of topic for this list but I would be
> interested about real SCM experiments. I already know about
> Subversion (I'm using it atwork, under Windows) and Arch.

In the referenced thread you wrote:

  darcs: I don't like its commutable patch theory

What is not to like about this theory? Could you explain?

In practice it seems to work very well. I have used darcs on
Windows, linux with Axiom and on Solaris in another project.
My experience is that the merging of patches in darcs is
superior to cvs and tla (arch), resulting in fewer conflicts
to resolve.

I do not know of any limitations of darcs that would prevent
it from being used in the same way that tla is now used in
Axiom.

\start
Date: Tue, 7 Feb 2006 10:45:28 +0100
From: David Mentre
To: Bill Page
Subject: Re: Preferred SCM

Hello Bill,

2006/2/7, Page, Bill Bill Page:
>   darcs: I don't like its commutable patch theory
>
> What is not to like about this theory? Could you explain?

I found it seducing at first but I fear that DARCS patch commutation
would make the understanding of merge failure difficult. In general in
computer science, I don't like things which are not predictable.

I've also read once a post from somebody who said that DARCS failed on
his big project and was not scalable.

> In practice it seems to work very well. I have used darcs on
> Windows, linux with Axiom and on Solaris in another project.
> My experience is that the merging of patches in darcs is
> superior to cvs and tla (arch), resulting in fewer conflicts
> to resolve.

You practice contradicts my own readings. I've never said that my
words were the One Truth(tm). ;-)

> I do not know of any limitations of darcs that would prevent
> it from being used in the same way that tla is now used in
> Axiom.

The main issue with those SCM choice is that the only real test is to
apply an SCM on your project and see if it works or not.

For example, I find Arch irritating because it is slow, it imposes
specific naming of branches, it lacks documentation, its command line
is difficult to remember and making a new branch is not that easy.
Without a day to day use for two years, I would not have said that.
:-)

\start
Date: Tue, 07 Feb 2006 03:53:28 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Fraction] attempt to modify Fraction

\begin{spad}
)abbrev domain FRAC Fraction
++ Try to prevent Fraction from returning Fraction Fraction Integer
++ based on a suggestiong by Ralf Hammecke
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
  ==  if S has QuotientFieldCategory Integer then S add
           coerce(d:S):% == d
           zero?(x:%) == zero? x
      else LocalAlgebra(S, S, S) add
           Rep:= Record(num:S, den:S)
           coerce(d:S):% == [d,1]
           zero?(x:%) == zero? x.num
\end{spad}

But SPAD apparently cannot compile this. :(

\start
Date: Tue, 07 Feb 2006 04:24:03 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Fraction] SubsetCategory ?

'SubsetCategory' seems to be a specific to SPAD. It is defined here:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/CompilerBoot

\begin{boot}
compSubsetCategory(["SubsetCategory",cat,R],m,e) ==
  --1. put "Subsets" property on R to allow directly coercion to subset;
  --   allow automatic coercion from subset to R but not vice versa
  e:= put(R,"Subsets",[[$lhsOfColon,"isFalse"]],e)
  --2. give the subset domain modemaps of cat plus 3 new functions
  comp(["Join",cat,C'],m,e) where
    C'() ==
      substitute($lhsOfColon,"$",C'') where
        C''() ==
          ["CATEGORY","domain",["SIGNATURE","coerce",[R,"$"]],["SIGNATURE",
            "lift",[R,"$"]],["SIGNATURE","reduce",["$",R]]]
\end{boot}

But this constructor does not seem to be available to the
Axiom interpreter:
\begin{axiom}
xl:=Localize(Integer,Integer,PositiveInteger)
SubInt:=SubsetCategory(Monoid,Integer)
\end{axiom}

\start
Date: Tue, 07 Feb 2006 06:27:45 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [Fraction] A suggestion for MyFraction in Aldor (draft)

Here is the code that demonstrates how to use conditional representations in Aldor for the domain constructor [Fraction]. I prepended the constructors by "My" in order to avoid naming conflicts with existing names in Axiom.

Doing it in that way, 'MyFraction MyFraction Integer' behaves as efficiently as just 'MyFraction Integer'.
\begin{aldor}
---- frac.as ----
-- Compile with 
--   aldor -mno-mactext -fx -laldor frac.as
-- results in

--: "frac.as", line 51: MyFraction(R: MyIntegralDomain): MyFractionField R == {
--:                       .........^
--: [L51 C10] #1 (Warning) Function returns a domain that might not be constant (which may cause problems if it is used in a dependent type).

-- Ignore this warning.

-- Then running the program gives

--: Integer:   2
--: Rational:  (2)/(1)
--: Rational1: (2)/(1)
--: Rational2: ((2)/(1))/((1)/(1))

-- which shows that the domain constructor "MyFraction" does not construct 
-- another representation in case its argument is already a field.

#if Axiom
#include "axiom"
#else
#include "aldor"
#endif

define MyIntegralDomain: Category == 
#if Axiom
CoercibleTo OutputForm
#else
OutputType
#endif
with {
	0: %;
	1: %;
	+: (%, %) -> %;
	-: % -> %;
	*: (%, %) -> %;
}

define MyField: Category == with {
	MyIntegralDomain;
	inv: % -> %;
}

define MyFractionField(R: MyIntegralDomain): Category == with {
	MyField;
	numerator: % -> R;
	denominator: % -> R;
}

MyFraction0(R: MyIntegralDomain): MyFractionField R == add {
	Rep == Record(num: R, den: R);
	import from Rep;
	0: % == per [0, 1];
	1: % == per [1, 1];
	numerator(x: %): R == rep(x).num;
	denominator(x: %): R == rep(x).den;
	-(x: %): % == per [- numerator x, denominator x];
	inv(x: %): % == per [denominator x, numerator x];
	(x: %) + (y: %): % == {
		n := numerator x * denominator y + denominator x * numerator y;
		d := denominator x * denominator y;
		per [n, d];
	}
	(x: %) * (y: %): % == {
		n := numerator x * numerator y;
		d := denominator x * denominator y;
		per [n, d];
	}
#if Axiom
        coerce(x: %): OutputForm == {
                (numerator(x)::OutputForm) / (denominator(x)::OutputForm)
        }
#else
	(tw: TextWriter) << (x: %): TextWriter == {
		import from String;
		tw << "(" << numerator x << ")/(" << denominator x << ")";
	}
#endif
}
MyFraction1(F: MyField): MyFractionField F == F add {
	numerator(x: %): F == x pretend F;
	denominator(x: %): F == 1$F;
}

MyFraction(R: MyIntegralDomain): MyFractionField R == {
	if R has MyField then MyFraction1(R pretend MyField) else MyFraction0 R;
}

MyInteger:   MyIntegralDomain == Integer add;
MyRational:  MyFractionField MyInteger  == MyFraction  MyInteger;
MyRational1: MyFractionField MyRational == MyFraction  MyRational;
MyRational2: MyFractionField MyRational == MyFraction0 MyRational;

#if Axiom
#else
main(): () == {
	import from TextWriter, String, Character;
	i: MyInteger    := 1;
	r0: MyRational  := 1;
	r1: MyRational1 := 1;
	r2: MyRational2 := 1;
	stdout << "Integer:   " << i  + i  << newline;
	stdout << "Rational:  " << r0 + r0 << newline;
	stdout << "Rational1: " << r1 + r1 << newline;
	stdout << "Rational2: " << r2 + r2 << newline;
}

main();
#endif
\end{aldor}

Does anybody know why the following doesn't work? 
As can be seen from above the code works with just using Aldor and the libaldor library.
\begin{axiom}
i : MyInteger   := 1
r0: MyRational  := 1
r1: MyRational1 := 1
r2: MyRational2 := 1
\end{axiom}

\start
Date: Tue, 07 Feb 2006 06:51:14 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [Fraction] A suggestion for MyFraction in Aldor (draft)

++ based on a suggestion by Ralf Hemmecke

Comment from Ralf Hemmecke to the above code: 
How can a compiler find out which function to call if one says something like::

           zero?(x:%) == zero? x

To me this looks like a recursive definition :-( Fortunately, the Aldor compiler will complain at
such ambiguous definitions.

If the compiler can figure out which function 'zero?' it should put into the second place, fine.
But then the argument type for that function is wrong. There must be an implicit (hidden) conversion from % to S.

As a human I would have a very hard time to understand the code if I haven't heard about the convention that
functions that end in a question mark return [Boolean]. Maybe 'zero?(x)' returns 1 for 'x=0' and zero otherwise.

It somehow doesn't fit together, writing pamphlets and ambiguous code. Always put the type information into the code!
Adding a bit of redundancy is certainly appreciated by other developers.

\start
Date: Tue, 07 Feb 2006 07:00:23 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [Fraction] 

i : MyInteger   := 1$MyInteger
)sh MyRational
r0: MyRational  := 1$MyRational
r1: MyRational1 := 1$MyRational1
r2: MyRational2 := 1$MyRational2

\start
Date: 07 Feb 2006 15:32:25 +0100
From: Gabriel Dos Reis
To: David Mentre
Subject: Re: Preferred SCM

David MENTRE David Mentre writes:

[...]

| I think I have the same requirements as Axiom (efficiency, Windows
| availability, decentralized if possible) and my short list is
| Mercurial, Subversion and SVK. Interestingly, SVK seems to be a good
| compromise between Subversion and Arch: it works in a decentralized
| manner as Arch (with apparently the same merge algorithms) but it is
| compatible with de-facto standard Subversion and can works daily with
| svn repositories. For interested people, see relevant thread:
|   http://thread.gmane.org/gmane.politics.organizations.demexp.devel/785
| 
| It might become of topic for this list but I would be interested about
| real SCM experiments. I already know about Subversion (I'm using it at
| work, under Windows) and Arch.

SVN is the official SCM for GCC; but I (and many other GCC developers)
use SVK.  The reason I use SVK is that it seems to have a better
filesystem to minimize disk space consumption, and it has been
improved recently to be "fast" as well.  If you're going to crete lot
of branches for experimentations then SVK is probably a good choice.
The only irritating I find about it is its inability to use
traditional diff (yes, you have to configure it to use external diff
and all that.)
There is a tool to convert CVS repository to SVN, if one ever wanted
to keep the CVS history around.

\start
Date: Tue, 7 Feb 2006 15:34:31 +0100
From: David Mentre
To: Gabriel Dos Reis
Subject: Re: Preferred SCM

Gaby,

07 Feb 2006 15:32:25 +0100, Gabriel Dos Reis=
:
> The only irritating I find about it is its inability to use
> traditional diff (yes, you have to configure it to use external diff
> and all that.)

Is this configuration step documented somewhere? Any pointer?

\start
Date: Tue, 7 Feb 2006 15:43:21 +0100
From: David Mentre
To: Gabriel Dos Reis
Subject: Re: Preferred SCM

2006/2/7, David MENTRE David Mentre:
> Is this configuration step documented somewhere? Any pointer?

Oops, sorry, I found it by myself. Should have googled before asking.

  http://gcc.gnu.org/wiki/SvnSetup       (at the bottom of the page)

\start
Date: Tue, 7 Feb 2006 07:13:43 -0800
From: Scott Morrison
To: list
Subject: Re: Preferred SCM

The preferred SCM?  I always thought it was me.

-- Scott C Morrison

P.S.  As an Axiom developer, I was always known as SCM.  If you look in the
source code for comments from me, you can see things like this:

   -- The following is experimental.  SCM 10/11/90

Ah, now that's some well documented code.

\start
Date: Tue, 7 Feb 2006 07:24:24 -0800 (PST)
From: Cliff Yapp
To: list
Subject: JET source code up in the Axiom portal

Werner M. Seiler's JET - An AXIOM Environment for Geometric
Computations with Differential Equations - is now available under
Modified BSD.  Code only, but the paper can be read online: 
http://www.ubka.uni-karlsruhe.de/cgi-bin/psview?document=/1997/Ettlingen/110&search=/1997/Ettlingen/110
 Other links are also available in the axiom portal:
http://portal.axiom-developer.org/search?SearchableText=JET

The code can be downloaded from here: 
http://portal.axiom-developer.org/Members/starseeker/Jet-June1995.tar.gz
 I'm not sure if this will work without being logged in to the Axiom
portal.

I wish to thank Werner Seiler for digging up this code and granting
permission to use it, and apologize for not announcing this sooner - it
was actually online back in late December.

\start
Date: Tue, 7 Feb 2006 12:58:33 -0500
From: Bill Page
To: David Mentre
Subject: RE: Preferred SCM

On Tuesday, February 07, 2006 4:45 AM David Mentre wrote:
>
> > >  darcs: I don't like its commutable patch theory
> >
> 2006/2/7, Bill Page:
>
> > What is not to like about this theory? Could you explain?
>
> I found it seducing at first but I fear that DARCS patch
> commutation would make the understanding of merge failure
> difficult.

I have not seen any examples of this.

> In general in computer science, I don't like things which are
> not predictable.

As I understand it, the darcs "theory of patches" is motivated
by the mathematics of quantum operators -- patches are operators
on the source code tree. The properties of patches are defined
algebraically.  So, mathematically speaking I think what darcs
does is completely predictable. See:

http://www.darcs.net/manual/node8.html

In the context of the Axiom project, I like the association of
a mathematical "theory of patches" with Axiom's source code
management. Moreover, darcs is written in Haskell - a language
in the same family as Axiom's SPAD and Aldor. In principle one
could even implement darcs in Aldor.  So for me, this is mentally
a very good match.

>
> I've also read once a post from somebody who said that DARCS
> failed on his big project and was not scalable.
>

Such information is at best anecdotal. I've done some pretty
stupid things with both CVS and arch (tla) as well. :) But I
know of no documented cases where darcs has failed when properly
applied.

I would consider Axiom at least a "medium-sized" project. So far
I have not seen any performance problems or failures on either
Unix or Windows. darcs 1.0.5 has some performance improvements -
especially on windows. Older versions on Windows required setting
a larger heap size because the Axiom source distribution includes
some rather large binary files.

Of course, as Tim Daly might have said: Source code management
is now almost a religious subject - right up there beside the
old "language wars" ;) so I don't suppose that this discussion
can have much impact on the Axiom project as a whole.

\start
Date: Tue, 7 Feb 2006 11:31:05 -0800 (PST)
From: Cliff Yapp
To: Bill Page, David Mentre
Subject: RE: Preferred SCM

--- Bill Page wrote:

> Of course, as Tim Daly might have said: Source code management
> is now almost a religious subject - right up there beside the
> old "language wars" ;) so I don't suppose that this discussion
> can have much impact on the Axiom project as a whole.

For what it's worth, I've notices darcs usage cropping up in the Lisp
World quite a bit - a number of common-lisp.net projects use it, and
CLX also uses it.

\start
Date: Tue, 7 Feb 2006 19:07:17 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: JET source code up in the Axiom portal

Wow! This is a **very** extensive work! There is a lot of very
interesting and useful looking work here.

I have begun the process of installing this package on
the Axiom Wiki. You can see some of the code here:

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

On Tuesday, February 07, 2006 10:24 AM C Y wrote:

>
> Werner M. Seiler's JET - An AXIOM Environment for Geometric
> Computations with Differential Equations - is now available under
> Modified BSD.  Code only, but the paper can be read online:

http://www.ubka.uni-karlsruhe.de/cgi-bin/psview?document=/1997  \
/Ettlingen/110&search=/1997/Ettlingen/110

I had some problems reading the pdf version of the file above.
It seems to have very small top margin that cuts off some of
the text. I was able to print it successfully using ghostview
on the postscript version and then convert it to a useable pdf
with the ghostview 'convert' option.

>  Other links are also available in the axiom portal:
> http://portal.axiom-developer.org/search?SearchableText=JET
>
> The code can be downloaded from here:
http://portal.axiom-developer.org/Members/starseeker/Jet-June1995.tar.gz

> I'm not sure if this will work without being logged in to the Axiom
> portal.

It downloads just fine.

As I mentioned above, I am trying to get this to compile on
the Axiom Wiki.

One problem is to find the dependencies and a feasible order in which
to compile the sources.

A second problem is that some of the code does not compile as is
using SPAD. In these cases, I was forced to break the code down
into smaller pieces with only one domain/category per section/file.
I think this strategy is going to work.

A third problem is that there are apparently some Aldor versions
of some of the domains/categories. I tried to compile one of
these, but got an unexpected error message. Right now I am
assuming that it will be possible to compile the entire system
using just the Spad code.

>
> I wish to thank Werner Seiler for digging up this code and
> granting permission to use it, and apologize for not announcing
> this sooner - it was actually online back in late December.
>

Thank you very much Werner Seiler! This is a marvelous contribution
to the mathematical abilities of Axiom.

Thanks also Cliff, for getting around to post this message. :)

\start
Date: 08 Feb 2006 10:09:53 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: JET source code up in the Axiom portal

This is truly great! As far as I know JET was continued in MuPAD, so this is
not a dead end!

To maintain the overall structure of the MathAction Wiki, the apropriate place
to put a link would be a subpage of AxiomContributions.

Thank you Werner Seiler, thank you CY, thank you Bill!

\start
Date: Wed, 8 Feb 2006 11:30:24 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Aldor download?

Anybody else having trouble downloading the linux version of Aldor?

\start
Date: Wed, 8 Feb 2006 06:15:14 -0800 (PST)
From: Cliff Yapp
To: Martin Rubey, Bill Page
Subject: Re: JET source code up in the Axiom portal

> This is truly great! As far as I know JET was continued in 
> MuPAD, so this is not a dead end!

Right - Mupad developments are apparently quite advanced from this
work, so if we proceed to develop this further Mupad's implementation
and research are logical starting points for information.

My current thought on this is that, since we can't incorporate the JET
documentation as such, the thing to do is begin a general survey of
both JET related work and packages with similar abilities and try to
write up and create a "best of breed", using the JET code for a big
head start.  That's of course the hard way, which I've noticed is
usually also the best way as a first approximation :-/.

\start
Date: Wed, 08 Feb 2006 14:05:35 -0600
From: MathAction (anonymous)
To: MathAction
Subject: [#265 Axiom binary for Fedora Core 4 does not start properly] (new) 

I have installed axiom-Sept2005-FC4-bin.tgz on Fedora Core 5 (in
/usr/local), following the instructions in the download page, but
execution of axiom does not produce any proper output. Ie it produces
a pair of blank lines and closes again, returning the prompt to the
console. On the other hand, axiom -h works.

Some variations occur, eg with option noclef it closes without blank
lines, and with iw it opens an X term for a second and then it closes.
And here some other ones:

=========
[root@localhost bin]# axiom -nogo
Would now start the processes.
exec /usr/local/axiom/mnt/linux/bin/sman -ws /usr/local/axiom/mnt/linux/bin/AXIOMsys
[root@localhost bin]# ps aux | axiom
clef trying to get the initial terminal settings: Invalid argument


root@localhost bin]# axiom -list
AXIOM workspaces in $AXIOM/bin = /usr/local/axiom/mnt/linux/bin:
-rwxr-xr-x  1 root root 13650944 Sep  5 23:20 AXIOMsys

Would now start the processes.
exec /usr/local/axiom/mnt/linux/bin/sman -ws /usr/local/axiom/mnt/linux/bin/AXIOMsys

==========

What is the problem?

Regards, Alejandro Jakubi

\start
Date: Wed, 08 Feb 2006 14:21:48 -0600
From: MathAction (Alejandro Jakubi)
To: MathAction
Subject: [#266 Axiom binary for Fedora Core 4 does not start properly] 

Correction: 
I have installed axiom-Sept2005-FC4-bin.tgz on Fedora Core 4

\start
Date: Wed, 08 Feb 2006 14:39:53 -0600
From: MathAction (Alejandro Jakubi)
To: MathAction
Subject: [#266 Axiom binary for Fedora Core 4 does not start properly] 

I have installed axiom-Sept2005-FC4-bin.tgz on Fedora Core 4 (in /usr/local), following the instructions in the download page, but execution of axiom does not produce any proper output. Ie it produces a pair of blank lines and closes again, returning the prompt to the console. On the other hand, axiom -h works.

\start
Date: Wed, 08 Feb 2006 19:08:44 -0600
From: MathAction (root)
To: MathAction
Subject: [#266 Axiom binary for Fedora Core 4 does not start properly]
	not	start properly] (new)

My best guess is that you have SELinux enabled. As root try:

echo 0 >/proc/sys/kernel/randomize_va_space

and see if that fixes the problem

Tim

\start
Date: Wed, 08 Feb 2006 23:24:31 -0600
From: MathAction (Alejandro Jakubi)
To: MathAction
Subject: [#266 Axiom binary for Fedora Core 4 does not start properly] 

Yes, SELinux was enabled and enforced. This command did not solved the
problem. Then I have disabled SELinux, booted, axiom did not work yet,
executed the command and axiom began working. Then I have set SELinux
to enabled again, booted with relabelling, and after execution of the
command axiom does work, even with enforcing.

Apparently I should call axiom from a script including this command.

\start
Date: Wed, 08 Feb 2006 23:45:16 -0600
From: MathAction (root)
To: MathAction
Subject: [#266 Axiom binary for Fedora Core 4 does not start properly]

> Yes, SELinux was enabled and enforced. This command did not solved the
> problem. Then I have disabled SELinux, booted, axiom did not work yet,
> executed the command and axiom began working. Then I have set SELinux
> to enabled again, booted with relabelling, and after execution of the
> command axiom does work, even with enforcing.

Apparently I should call axiom from a script including this command.
i've asked someone who knows the SELinux people to suggest that they
use Lisp as a test case. the people who implemented the SELinux routines
don't seem to understand the way lisp systems work. every time they
release a "new" SELinux update they've broken yet another thing in Lisp.

at least it solved your problem.

\start
Date: Thu, 09 Feb 2006 09:02:06 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Aldor download?
Cc: Stephen Watt, Laurentiu Dragan

Yes, me. It seems, there is something wrong with the website.

Ralf

On 02/08/2006 08:30 PM, C Y wrote:
> Anybody else having trouble downloading the linux version of Aldor?
> 

\start
Date: Thu, 09 Feb 2006 09:48:47 -0600
From: MathAction (Alejandro Jakubi)
To: MathAction
Subject: [#266 Axiom binary for Fedora Core 4 does not start properly] 

In fact it is enough to execute the magic command once in the shell. Afterwards, axiom opens fine every time. So, I think, I should add this command to /etc/rc.d/rc.local.

\start
Date: Thu, 9 Feb 2006 17:34:24 -0500
From: Bill Page
To: list
Subject: Help with JET

Dear SPAD Gurus;

I have been working with Werner Seiler's JET package at:

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

but on the first example I a stopped by the error message:

  Internal Error
  Unexpected error in call to system function evalSlotDomain

in:

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

Apparently this is related to a warning in the compile of:

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

Does anyone know what this message means?

Warnings:
      [1] generate: not known that (Ring) is of mode (CATEGORY domain
(SIGNATURE order ((NonNegativeInteger) $)) (SIGNATURE coerce =
((OutputForm)
$)) (SIGNATURE printSys ((OutputForm) (List D))) (SIGNATURE display =
((Void)
$)) (SIGNATURE copy ($ $)) (SIGNATURE retract ((List D) $)) (SIGNATURE
jacobiMatrix ((List (SparseEchelonMatrix JB D)) $)) (SIGNATURE generate =
($
(List D))) (SIGNATURE join ($ $ $)) (SIGNATURE insert ($ (List D) $))
(SIGNATURE dimension ((NonNegativeInteger) $ (NonNegativeInteger)))
(SIGNATURE setSimpMode ((NonNegativeInteger) (NonNegativeInteger)))
(SIGNATURE simplify ((Record (: SDe $) (: IC (List D))) $)) (SIGNATURE
extractSymbol ((SparseEchelonMatrix JB D) $ (Boolean))) (SIGNATURE
analyseSymbol ((Record (: Rank (NonNegativeInteger)) (: NumMultVar
(NonNegativeInteger)) (: Betas (List (NonNegativeInteger))))
(SparseEchelonMatrix JB D))) (SIGNATURE prolongSymbol =
((SparseEchelonMatrix
JB D) (SparseEchelonMatrix JB D))) (SIGNATURE prolongMV ((Record (: Rank
(NonNegativeInteger)) (: NumMultVar (NonNegativeInteger)) (: Betas (List
(NonNegativeInteger)))) (Record (: Rank (NonNegativeInteger)) (: =
NumMultVar
(NonNegativeInteger)) (: Betas (List (NonNegativeInteger)))))) =
(SIGNATURE
project ($ $ (NonNegativeInteger))) (SIGNATURE prolong ((Record (: SDe =
$) (:
IC (List D))) $)) (SIGNATURE prolong ((Record (: SDe $) (: IC (List D))) =
$
(NonNegativeInteger))) (SIGNATURE tableau ((SparseEchelonMatrix JB D)
(SparseEchelonMatrix JB D) (Differential JB D))) (SIGNATURE tableau
((SparseEchelonMatrix JB D) (SparseEchelonMatrix JB D) (List =
(Differential
JB D)))))

-----------

Any help and/or suggestions would be greatly appreciated.

\start
Date: Fri, 10 Feb 2006 01:00:03 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: Re: Help with JET

Hi,

Le jeudi 09 f=E9vrier 2006 =E0 17:34 -0500, Bill Page a =E9crit :
> Dear SPAD Gurus;
>
> I have been working with Werner Seiler's JET package at:
>
> http://wiki.axiom-developer.org/SandBoxJet
>
> but on the first example I a stopped by the error message:
>
>   Internal Error
>   Unexpected error in call to system function evalSlotDomain
>
> in:
>
> http://wiki.axiom-developer.org/SandBoxJetFigure4
>
> Apparently this is related to a warning in the compile of:
>
> http://wiki.axiom-developer.org/SandBoxDifferentialEquation
>
> Does anyone know what this message means?
>
> Warnings:
>       [1] generate: not known that (Ring) is of mode (CATEGORY domain
> (SIGNATURE order ((NonNegativeInteger) $)) (SIGNATURE coerce ((OutputFo=
rm)
> $)) (SIGNATURE printSys ((OutputForm) (List D))) (SIGNATURE display ((V=
oid)
> $)) (SIGNATURE copy ($ $)) (SIGNATURE retract ((List D) $)) (SIGNATURE
> jacobiMatrix ((List (SparseEchelonMatrix JB D)) $)) (SIGNATURE generate=
 ($
> (List D))) (SIGNATURE join ($ $ $)) (SIGNATURE insert ($ (List D) $))
> (SIGNATURE dimension ((NonNegativeInteger) $ (NonNegativeInteger)))
> (SIGNATURE setSimpMode ((NonNegativeInteger) (NonNegativeInteger)))
> (SIGNATURE simplify ((Record (: SDe $) (: IC (List D))) $)) (SIGNATURE
> extractSymbol ((SparseEchelonMatrix JB D) $ (Boolean))) (SIGNATURE
> analyseSymbol ((Record (: Rank (NonNegativeInteger)) (: NumMultVar
> (NonNegativeInteger)) (: Betas (List (NonNegativeInteger))))
> (SparseEchelonMatrix JB D))) (SIGNATURE prolongSymbol ((SparseEchelonMa=
trix
> JB D) (SparseEchelonMatrix JB D))) (SIGNATURE prolongMV ((Record (: Ran=
k
> (NonNegativeInteger)) (: NumMultVar (NonNegativeInteger)) (: Betas (Lis=
t
> (NonNegativeInteger)))) (Record (: Rank (NonNegativeInteger)) (: NumMul=
tVar
> (NonNegativeInteger)) (: Betas (List (NonNegativeInteger)))))) (SIGNATU=
RE
> project ($ $ (NonNegativeInteger))) (SIGNATURE prolong ((Record (: SDe =
$) (:
> IC (List D))) $)) (SIGNATURE prolong ((Record (: SDe $) (: IC (List D))=
) $
> (NonNegativeInteger))) (SIGNATURE tableau ((SparseEchelonMatrix JB D)
> (SparseEchelonMatrix JB D) (Differential JB D))) (SIGNATURE tableau
> ((SparseEchelonMatrix JB D) (SparseEchelonMatrix JB D) (List (Different=
ial
> JB D)))))

printSys doesn't use 'generate' and stop with the same error.

If you trace DE (DifferentialEquation) you'll see that these functions
are never called. May be a too complicated type for the actual axiom.

\start
Date: Thu, 9 Feb 2006 20:28:49 -0500
From: Tim Daly
To: Bill Page
Subject: Re: Help with JET

The compiler is looking for something that is defined as 
Ring with order(NonNegativeInteger) -> % , coerce(OutputForm) -> %, ...

If it gets a bare 'Ring' it can't find these functions in the export list.

It helps if you format it:

      [1] generate: 

  not known that (Ring) is of mode 
   
  (CATEGORY domain

    (SIGNATURE order 
      ((NonNegativeInteger) $))

    (SIGNATURE coerce 
      ((OutputForm) $))

    (SIGNATURE printSys 
      ((OutputForm) (List D)))

    (SIGNATURE display 
      ((Void) $))

    (SIGNATURE copy 
      ($ $))

    (SIGNATURE retract 
      ((List D) $))

    (SIGNATURE jacobiMatrix 
      ((List (SparseEchelonMatrix JB D)) $))

    (SIGNATURE generate 
      ($ (List D)))

    (SIGNATURE join 
      ($ $ $))

    (SIGNATURE insert 
      ($ (List D) $))

    (SIGNATURE dimension 
      ((NonNegativeInteger) $ (NonNegativeInteger)))

    (SIGNATURE setSimpMode 
      ((NonNegativeInteger) (NonNegativeInteger)))

    (SIGNATURE simplify 
      ((Record (: SDe $) (: IC (List D))) $))

    (SIGNATURE extractSymbol 
      ((SparseEchelonMatrix JB D) $ (Boolean)))

    (SIGNATURE analyseSymbol 
      ((Record (: Rank (NonNegativeInteger))
               (: NumMultVar (NonNegativeInteger))
               (: Betas (List (NonNegativeInteger))))
       (SparseEchelonMatrix JB D)))

    (SIGNATURE prolongSymbol
       ((SparseEchelonMatrix JB D)
        (SparseEchelonMatrix JB D)))

    (SIGNATURE prolongMV 
      ((Record (: Rank (NonNegativeInteger))
               (: NumMultVar (NonNegativeInteger))
               (: Betas (List (NonNegativeInteger))))
       (Record (: Rank (NonNegativeInteger))
               (: NumMultVar (NonNegativeInteger))
               (: Betas (List (NonNegativeInteger))))))

    (SIGNATURE project 
       ($ $ (NonNegativeInteger)))

    (SIGNATURE prolong 
       ((Record (: SDe $) (: IC (List D)))
      $))

    (SIGNATURE prolong 
       ((Record (: SDe $) (: IC (List D)))
        $
        (NonNegativeInteger)))

    (SIGNATURE tableau 
       ((SparseEchelonMatrix JB D)
        (SparseEchelonMatrix JB D)
        (Differential JB D)))

    (SIGNATURE tableau 
       ((SparseEchelonMatrix JB D)
        (SparseEchelonMatrix JB D)
        (List (Differential JB D)))))


it appears that somewhere someone is trying to use a Ring as
an argument but the compiler can't figure out if Ring has those
elements in its signature (which it clearly does not).

1) Try to figure out what domain has the functions like 
     "tableau", "prolong", "project", etc in its list of exports

2) Call that domain 'D'

3) Look for the use of Ring where a thing of type 'D' is needed.

4) replace Ring with a thing of type 'D'.


It might be the case that there is not a direct use of 'Ring'
but of something that derives from 'Ring', say 'Foo'.

If the compiler is trying to use 'Foo' which extends 'Bar' which
extends 'Ring' and 'Bar' is missing then the compiler thinks that
'Ring' should have the exports of 'Bar'. So it tries to compile
'Foo', can't find "tableau" in Foo, so it looks in the parent
signature (should be Bar which is missing and moved up to Ring)
which does not have "tableau".

This could be caused by not having a file loaded while compiling.
It could be caused by not "exposing" the 'Bar' domain so it can't
be found (unlikely since you probably don't play with expose).

Or it could just be a bug.

\start
Date: Thu, 9 Feb 2006 22:56:34 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Help with JET

Tim,

Thanks for the explanation and hints. So far I still can not
see the reason for this error message by as Gregory showed,
this is probably not the issue that causes the failure.

I did a trace at the point of failure and I see:

)trace evalSlotDomain
   Function traced: evalSlotDomain
janet:de := generate [eq1,eq2]
1<enter evalSlotDomain : (|JetBundle| (|x| |y| |z|) (|u|))\#<vector
08ecfb98>
 2<enter evalSlotDomain : (|x| |y| |z|)\#<vector 08ecfb98>
  3<enter evalSlotDomain : |y|\#<vector 08ecfb98>
   Internal Error
   Unexpected error in call to system function evalSlotDomain

and the same error occurs here in a very different context:

setOutMode(14)$ck
1<enter evalSlotDomain : (|JetBundle| (|x| |y| |z|) (|u|))\#<vector
08ecf850>
 2<enter evalSlotDomain : (|x| |y| |z|)\#<vector 08ecf850>
  3<enter evalSlotDomain : |y|\#<vector 08ecf850>
   Internal Error
   Unexpected error in call to system function evalSlotDomain

-----------

Apparently it has something to do with evaluating JetBundle -
something fairly deep down and fundamental to this package.

In the compiler output for JetBundle I see yet another weird
warning, this time perhaps more serious:

      [5] unknown Functor code (CATCH (QUOTE G1433) (REPEAT (STEP i 2 1
(QREFELT $ 9)) (call (ELT $ 19) (QREFELT $ 15) i (call (ELT $ 18) DVar =
i))))
      [6] unknown Functor code (CATCH (QUOTE G1432) (REPEAT (STEP i 2 1
(QREFELT $ 8)) (call (ELT $ 19) (QREFELT $ 14) i (call (ELT $ 18) IVar =
i))))

JetBundle is a domain

  JetBundle(IVar:L Sy, DVar:L Sy)

that in the example is called like this:

  jb:=JB(['x,'y,'z],['u])

Now, the code in JetBundle that apparently generates the warning
is right at the top of the definition of this domain:

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

V    ==> Vector
Sy   ==> Symbol

...

    nn:NNI := #IVar
    mm:NNI := #DVar
    nameX:V Sy := new(nn, first IVar)
    nameU:V Sy := new(mm, first DVar)
    for i in 2..nn repeat
      qsetelt!(nameX,i,qelt(IVar,i))
    for i in 2..mm repeat
      qsetelt!(nameU,i,qelt(DVar,i))

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

which is apparently copying the List into a Vector for each
parameter. I wonder why not just write?

  nameX:=Ivar::V Sy

What's the point of calling 'new' here?

Anyway it seems significant to me that the Internal Error above
occurs during the call to evalSlotDomain for 2nd element of the
first parameter list 'y.

Can you give me some idea for what "unknown Functor code" might
mean in this warning?

\start
Date: Thu, 9 Feb 2006 23:33:29 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Help with JET

On February 9, 2006 10:57 PM I wrote:
> ... 
> Now, the code in JetBundle that apparently generates the warning
> is right at the top of the definition of this domain:
> 
> http://wiki.axiom-developer.org/SandBoxJetBundle
> 
> V    ==> Vector
> Sy   ==> Symbol
> 
> ...
> 
>     nn:NNI := #IVar
>     mm:NNI := #DVar
>     nameX:V Sy := new(nn, first IVar)
>     nameU:V Sy := new(mm, first DVar)
>     for i in 2..nn repeat
>       qsetelt!(nameX,i,qelt(IVar,i))
>     for i in 2..mm repeat
>       qsetelt!(nameU,i,qelt(DVar,i))
> 
> ------------
> 
> which is apparently copying the List into a Vector for each
> parameter. I wonder why not just write?
> 
>   nameX:=Ivar::V Sy
> 
> What's the point of calling 'new' here?

Well I changed the code of JetBundle as follow:

--    nameX:V Sy := new(nn, first IVar)
--    nameU:V Sy := new(mm, first DVar)
--    for i in 2..nn repeat
--      qsetelt!(nameX,i,qelt(IVar,i))
--    for i in 2..mm repeat
--      qsetelt!(nameU,i,qelt(DVar,i))

    nameX := construct(IVar)$V(Sy)
    nameU := construct(DVar)$V(Sy)

and the weird compiler warning message goes away, but the
Internal Error message:

)trace evalSlotDomain
   Function traced: evalSlotDomain 
janet:de := generate [eq1,eq2]
1<enter evalSlotDomain : (|JetBundle| (|x| |y| |z|) (|u|))\#<vector
08ed29d8>
 2<enter evalSlotDomain : (|x| |y| |z|)\#<vector 08ed29d8>
  3<enter evalSlotDomain : |y|\#<vector 08ed29d8>
   Internal Error
   Unexpected error in call to system function evalSlotDomain

--------

still remains :(

I looked quickly at the code for 'evalSlotDomain' in:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/InteropBoot

and the recursion seems to occur near the end of 'evalSlotDomain'

  u is [op,:argl] => APPLY(op,[evalSlotDomain(x,dollar) for x in argl])

i.e. the list '(|x| |y| |z|)' seems to be confused with a lisp
Sexpression but I am way beyond of my level of incompetence here
...

Ideas?

\start
Date: Fri, 10 Feb 2006 09:23:36 -0500
From: Bill Page
To: Tim Daly
Subject: non extending category

Tim,

In http://wiki.axiom-developer.org/SandBoxJetBundleExpression

I see another strange SPAD message:

--------------non extending category----------------------
.. JetBundleExpression #1 of cat

(|Join| (|JetBundleFunctionCategory| |#1|) (|FunctionSpace| (|Integer|))
(|AlgebraicallyClosedFunctionSpace| (|Integer|))
(|TranscendentalFunctionCategory|) (|CombinatorialOpsCategory|)
(|LiouvillianFunctionCategory|) (|SpecialFunctionCategory|) (CATEGORY
|domain| (SIGNATURE |coerce| ($ (|Expression| (|Integer|)))) (SIGNATURE
|coerce| ((|Expression| (|Integer|)) $)) (SIGNATURE |coerce| ($
(|SparseMultivariatePolynomial| (|Integer|) (|Kernel| $)))) (SIGNATURE
|coerce| ($ (|SparseMultivariatePolynomial| (|Expression| (|Integer|))
|#1|))) (SIGNATURE |numerJP| ((|SparseMultivariatePolynomial| =
(|Expression|
(|Integer|)) |#1|) $)) (SIGNATURE |reduce| ($ $)) (SIGNATURE |function| =
($
(|Symbol|) (|List| $) (|NonNegativeInteger|)))))   has no

(IF (|has| (|Integer|) (|IntegralDomain|)) (PROGN (ATTRIBUTE
(|AlgebraicallyClosedFunctionSpace| (|Integer|))) (ATTRIBUTE
(|TranscendentalFunctionCategory|)) (ATTRIBUTE =
(|CombinatorialOpsCategory|))
(ATTRIBUTE (|LiouvillianFunctionCategory|)) (ATTRIBUTE
(|SpecialFunctionCategory|)) (SIGNATURE |reduce| ($ $)) (SIGNATURE =
|number?|
((|Boolean|) $)) (SIGNATURE |simplifyPower| ($ $ (|Integer|)))

(IF (|has| (|Integer|) (|GcdDomain|)) (PROGN (SIGNATURE =
|factorPolynomial|
((|Factored| (|SparseUnivariatePolynomial| $)) =
(|SparseUnivariatePolynomial|
$))) (SIGNATURE |squareFreePolynomial| ((|Factored|
(|SparseUnivariatePolynomial| $)) (|SparseUnivariatePolynomial| $))))
|noBranch|)

(IF (|has| (|Integer|) (|RetractableTo| (|Integer|))) (ATTRIBUTE
(|RetractableTo| (|AlgebraicNumber|))) |noBranch|)) |noBranch|)

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

Any idea what this means? What is a "non extending category"?

Is it trying to say that JetBundleExpression is missing some
function definitions?

\start
Date: Fri, 10 Feb 2006 07:28:52 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: Re: non extending category

--- Bill Page wrote:
> 
> Any idea what this means? What is a "non extending category"?
> 
> Is it trying to say that JetBundleExpression is missing some
> function definitions?

That might be possible - this JET code was from the only available
archive the author had and he didn't know how complete it was.  I
figured since the dates matched up with the papers fairly well it would
be close, but I might have been wrong.  Sorry, I should have mentioned
that in the release email <turns red>.

\start
Date: Fri, 10 Feb 2006 11:32:55 -0500
From: Tim Daly
To: Bill Page
Subject: Re: non extending category

.. JetBundleExpression #1 of cat 

(|Join| 
 (|JetBundleFunctionCategory| |#1|)
 (|FunctionSpace| (|Integer|))
 (|AlgebraicallyClosedFunctionSpace| (|Integer|))
 (|TranscendentalFunctionCategory|)
 (|CombinatorialOpsCategory|)
 (|LiouvillianFunctionCategory|)
 (|SpecialFunctionCategory|)

 (CATEGORY |domain| 
   (SIGNATURE |coerce| 
     ($ (|Expression| (|Integer|))))
   (SIGNATURE |coerce| 
     ((|Expression| (|Integer|)) $))
   (SIGNATURE |coerce| 
     ($ (|SparseMultivariatePolynomial| (|Integer|) (|Kernel| $))))
   (SIGNATURE |coerce| 
     ($ (|SparseMultivariatePolynomial| (|Expression| (|Integer|)) |#1|)))
   (SIGNATURE |numerJP| 
     ((|SparseMultivariatePolynomial| (|Expression| (|Integer|)) |#1|) $))
   (SIGNATURE |reduce| 
     ($ $))
   (SIGNATURE |function| 
     ($ (|Symbol|) (|List| $) (|NonNegativeInteger|)))))

(IF (|has| (|Integer|) (|IntegralDomain|))
  (PROGN 
    (ATTRIBUTE (|AlgebraicallyClosedFunctionSpace| (|Integer|)))
    (ATTRIBUTE (|TranscendentalFunctionCategory|))
    (ATTRIBUTE (|CombinatorialOpsCategory|))
    (ATTRIBUTE (|LiouvillianFunctionCategory|))
    (ATTRIBUTE (|SpecialFunctionCategory|))
    (SIGNATURE |reduce| 
      ($ $))
    (SIGNATURE |number?|
      ((|Boolean|) $))
    (SIGNATURE |simplifyPower| ($ $ (|Integer|)))

    (IF (|has| (|Integer|) (|GcdDomain|))
       (PROGN
         (SIGNATURE |factorPolynomial|
           ((|Factored| (|SparseUnivariatePolynomial| $))
            (|SparseUnivariatePolynomial| $)))
         (SIGNATURE |squareFreePolynomial|
           ((|Factored| (|SparseUnivariatePolynomial| $)) 
                        (|SparseUnivariatePolynomial| $))))
       |noBranch|)

    (IF (|has| (|Integer|) (|RetractableTo| (|Integer|)))
      (ATTRIBUTE (|RetractableTo| (|AlgebraicNumber|)))
      |noBranch|))
 
 |noBranch|)



join is trying to create a new type that has all of the parents


 (|JetBundleFunctionCategory| |#1|)
 (|FunctionSpace| (|Integer|))
 (|AlgebraicallyClosedFunctionSpace| (|Integer|))
 (|TranscendentalFunctionCategory|)
 (|CombinatorialOpsCategory|)
 (|LiouvillianFunctionCategory|)
 (|SpecialFunctionCategory|)

with this new domain (represented by its signature list).

in addition if the new type HAS certain attributes (the "HAS" conditions)
then the new type will have these additional signatures.

so, simplifying, we are trying to combine types A, B, and C
with a new type D. Type D is represented by its signature list.

if the new type D HAS certain properties (such as being a GCDDomain
then we can add certain additional signatures (like 'factorPolynomial'.

thus if we can do GCDs of the new type
then we can factor polynomials of the new type.

i don't see any error message on the wiki page about 'non-extending
category'

\start
Date: Fri, 10 Feb 2006 10:54:43 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: non extending category

Cliff,

On February 10, 2006 10:29 AM you wrote:
> 
> --- Bill Page wrote:
> > 
> > Any idea what this means? What is a "non extending category"?
> > 
> > Is it trying to say that JetBundleExpression is missing some
> > function definitions?
> 
> That might be possible - this JET code was from the only available
> archive the author had and he didn't know how complete it was.  I
> figured since the dates matched up with the papers fairly well it
> would be close, but I might have been wrong.  Sorry, I should have
> mentioned that in the release email <turns red>.
> 

No problem. It is good to have this code to play with anyway ... :)
At the very least the LUDecomposition function works great and it
is something that I have needed for a long time.

The dates on the SPAD code seem to be about 1993 - pretty ancient.
I can see from some of the coding style that this must have been
written before or during the transition to a newer version of the
SPAD language. Still, it should be possible to compile this without
runtime errors like we are seeing. :(

The Aldor code is newer - dated 1997. Unfortunately even Aldor has
moved on since then (we are using Aldor version 1.2 on the Axiom
Wiki). The two Aldor files provided with the JET archive do not
compile without errors :(, although I think in this case the
problems might be easier to fix. If I can't see where to go from
here with the SPAD code, I will probably try the replacement Aldor
code...

Anyone else want to help with this? :) See:

http://wiki.axiom-developer.org/SandBoxAldorJetBundle
http://wiki.axiom-developer.org/SandBoxAldorSparse

I am not sure whether this is an Aldor issue as such or just an
Aldor/Axiom interface issue but one odd thing I see is the Aldor
compiler complaining about the rather trivial macro:

  Sy ==> Symbol

I don't understand this yet.

It seems suspicious to me that the part of JET that we are having
trouble with is one part that was apparently re-written in Aldor -
maybe there is a history of problems here...

One thing that seems to confirm this is on page 18 of the paper
where the author writes: "It was originally planned to provide
a special domain for polynomial equations, but there have been
very bizarre problems with AXIOM. For this reason JBE takes
currently the place of such a domain."

\start
Date: Fri, 10 Feb 2006 09:51:20 -0600
From: MathAction (unknown)
To: MathAction
Subject: [GraphViz] test

\begin{latex}
  \digraph[Options]{Name}{Specification}
  \end{latex}

\start
Date: Fri, 10 Feb 2006 11:06:37 -0500
From: Bill Page
To: Tim Daly
Subject: RE: non extending category

Tim,

You wrote:

> 
> i don't see any error message on the wiki page about 'non-extending
> category'
> 

I agree that there is no explicitly marked error message - maybe just
"informative" output from the compiler, but the phrase:

  xxx ... has no
  yyy

makes is seem like this might be an error.

See:

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

Scroll down until you see the first grey-shaded "+spad" on the
right hand side. Click on the + to expand the compiler output.
Scroll down some more until you see "non extending category".
There you see a very long line of compiler output. User vertical
scroll to see " ... has no ..." right near the end of the line
which continues on to the next line.

\start
Date: Fri, 10 Feb 2006 18:35:30 +0100
From: Gregory Vanuxem
To: list
Subject: Re: Help with JET

Hi,

For information, JET works cleany under Windows.
I think we will find the problem in the near future :)

\start
Date: Fri, 10 Feb 2006 23:55:57 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: non extending category

> Anyone else want to help with this? :) See:
> 
> http://wiki.axiom-developer.org/SandBoxAldorJetBundle
> http://wiki.axiom-developer.org/SandBoxAldorSparse

> I am not sure whether this is an Aldor issue as such or just an
> Aldor/Axiom interface issue but one odd thing I see is the Aldor
> compiler complaining about the rather trivial macro:
> 
>   Sy ==> Symbol

> I don't understand this yet.

Try the additional compiler switch
   -m no-mactext
and you will probably see a better source for the error.

With the original JetBundle.as (why are you removing the empty lines???)

I get an error message

aldor -mno-mactext -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete
-DAxiom -Y $AXIOM/algebra -I ~/OTHER/Axiom JetBundle.as
#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
"JetBundle.as", line 254:         qsetelt!(mi, i, qelt(mi,i)+1)
                           .............................^
[L254 C30] #2 (Error) Argument 1 of `qelt' did not match any possible
parameter type.
     The rejected type is List(NonNegativeInteger).
     Expected one of:
       -- Vector(NonNegativeInteger)
       -- List(PositiveInteger)

But in the code
     r2m(ri:L PI):L NNI ==
       mi:L NNI := new(numIndVar()::NNI,0$NNI)
       for i in ri repeat
         i>nn => error errmsg1
         qsetelt!(mi, i, qelt(mi,i)+1)
       mi
it is anyway bad that mi is a list. That is linear access time for each
element of ri. I guess, it's better to construct a vector, set the
elements and then turn the vector into a list. (I suspect that a vector
would be a better structure anyway for the purpose that the returned
value is used in other places of the code, but the code is too
unreadable for my taste.)

I have tried, to replace "mi:L NNI" by "mi:V NNI", but that results in

"JetBundle.as", line 254:         qsetelt!(mi, i, qelt(mi,i)+1)
                           .............................^
[L254 C30] #2 (Error) Argument 1 of `qelt' did not match any possible
parameter type.
     The rejected type is Vector(NonNegativeInteger).
     Expected one of:
       -- List(NonNegativeInteger)
       -- List(PositiveInteger)

That's interesting!!!

The reason is that qelt$List(NNI) wants to have an Integer as the second
argument, but gets a PositiveInteger. Unfortunately, I don't know so
much of Axiom to know how to convert.

I haven't found a definition for the "SubDomain" constructor that
appears in src/algebra/integer.spad. :-(


Bill, why do you translated something like the original

macro Const    == "Const"::Sy

into a recursive definition

macro Const    == Const

There are also some other places where you transformed "1"::Sy into just
1.

There are two problems here:
1) The literal 1 is most probably not of type Symbol and thus Aldor will 
return an error.
2) You have not documented that you modified Seiler's original code. So 
the history is lost.

It would be much better to split this huge code chunk into several 
pieces and for each part explain why you have changed what. Do this even 
if you just want to make the code compile properly.

It would be even better to relate the code to the paper but that is 
probably too much for the beginning.

\start
Date: Fri, 10 Feb 2006 21:51:23 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: non extending category

Ralf,

On February 10, 2006 5:56 PM you wrote:
> 
> > Anyone else want to help with this? :) See:
> > 
> > http://wiki.axiom-developer.org/SandBoxAldorJetBundle
> > http://wiki.axiom-developer.org/SandBoxAldorSparse
> 
> > I am not sure whether this is an Aldor issue as such or just an
> > Aldor/Axiom interface issue but one odd thing I see is the Aldor
> > compiler complaining about the rather trivial macro:
> > 
> >   Sy ==> Symbol
> 
> > I don't understand this yet.
> 
> Try the additional compiler switch
>    -m no-mactext
> and you will probably see a better source for the error.
> 

How can I set an Aldor compiler switch when compiling Aldor code
in Axiom?

> With the original JetBundle.as (why are you removing the empty
> lines???)
> 

I am not removing any lines. As you can see if you click 'edit'
the difference is only apparent. It is an artifact of the formatting
of the source that blank lines are removed. When adding the compiler
features (both SPAD and Aldor) to Axiom Wiki, I had to struggle with
the behaviour of the rest of the ZWiki/LatexWiki software that insists
on applying Wiki-style structured text formatting rules to the SPAD
and Aldor source code. I have been able to prevent most of this from
happening but not all. So you can consider this a bug in the MathAction
Axiom extensions of LatexWiki.

> I get an error message
> 
> aldor -mno-mactext -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete
> -DAxiom -Y $AXIOM/algebra -I ~/OTHER/Axiom JetBundle.as
> #1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
> "JetBundle.as", line 254:         qsetelt!(mi, i, qelt(mi,i)+1)
>                            .............................^
> [L254 C30] #2 (Error) Argument 1 of `qelt' did not match any possible
> parameter type.
>      The rejected type is List(NonNegativeInteger).
>      Expected one of:
>        -- Vector(NonNegativeInteger)
>        -- List(PositiveInteger)
>

I guess you are running Aldor stand alone? How then do you integrate
the compiler output with Axiom?
 
> But in the code
>      r2m(ri:L PI):L NNI ==
>        mi:L NNI := new(numIndVar()::NNI,0$NNI)
>        for i in ri repeat
>          i>nn => error errmsg1
>          qsetelt!(mi, i, qelt(mi,i)+1)
>        mi
> it is anyway bad that mi is a list. That is linear access time for
> each element of ri. I guess, it's better to construct a vector, set
> the elements and then turn the vector into a list. (I suspect that
> a vector would be a better structure anyway for the purpose that
> the returned value is used in other places of the code, but the
> code is too unreadable for my taste.)

Perhaps the difference in performance is not significant given the
size of 'ri'? But I agree in general with your suggested change.

> 
> I have tried, to replace "mi:L NNI" by "mi:V NNI", but that results
> in
> 
> "JetBundle.as", line 254:         qsetelt!(mi, i, qelt(mi,i)+1)
>                            .............................^
> [L254 C30] #2 (Error) Argument 1 of `qelt' did not match any possible
> parameter type.
>      The rejected type is Vector(NonNegativeInteger).
>      Expected one of:
>        -- List(NonNegativeInteger)
>        -- List(PositiveInteger)
> 
> That's interesting!!!
> 
> The reason is that qelt$List(NNI) wants to have an Integer as 
> the second argument, but gets a PositiveInteger. Unfortunately,
> I don't know so much of Axiom to know how to convert.

It is no problem in both Axiom and Aldor, I think, to coerce a PI
to an INT like this:

  qsetelt!(mi::Integer, i, qelt(mi,i)+1)

> 
> I haven't found a definition for the "SubDomain" constructor that
> appears in src/algebra/integer.spad. :-(
>

Like SubsetCategory, SubDomain is apparently a compiler primative.
It is not defined in the "algebra" as such. I remarked on this
recently in an email in another context:

http://lists.nongnu.org/archive/html/axiom-developer/2006-02/msg00076.html

See 'coerceSubset' in:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/CompilerBoot

In the case of both SubsetCategory and SubDomain, the usage is very
restricted in the Algebra library - they appear almost to be invented
for this one purpose alone.

But I presume that this sort of design has more or less carried over
to Aldor, no? How does one define a sub-domain in Aldor?

> 
> Bill, why do you translated something like the original
> 
> macro Const    == "Const"::Sy
> 
> into a recursive definition
> 
> macro Const    == Const
> 
> There are also some other places where you transformed 
> "1"::Sy into just 1.

No, this is similar to the case of the blank lines above. It is
an artifact of the formatting. ZWiki insists on treating text of
the form "xxx":yyy as a link with xxx being the part of the link
that is displayed and yyy being the url. I would like to get rid
of this display problem but it will require some serious changes
to the ZWiki/LatexWiki coding.

Again, if you look at the actual source by clicking 'edit' you
will see that there is no translation. The source is the same as
in the original code.

> 
> There are two problems here:
> 1) The literal 1 is most probably not of type Symbol and thus 
> Aldor will return an error.
> 2) You have not documented that you modified Seiler's 
> original code. So the history is lost.
> 

No I did not modify Seiler's original code. It just looks like
it if you only look at the web page and not the source code
underneath.

> It would be much better to split this huge code chunk into
> several pieces and for each part explain why you have changed
> what.

Again, please note that I have not changed anything in the original
code.

> Do this even if you just want to make the code compile properly.

Yes I agree that splitting it up is a good idea. This is what
I did with the SPAD code.

> 
> It would be even better to relate the code to the paper but that
> is probably too much for the beginning.
> 

Yes, I think this would be a great idea. If/when we get this code
to compile, I think it would make a very good example of a literate
program as a paper. I wonder if we can get the original LaTeX code
for the paper from the author?

\start
Date: Sat, 11 Feb 2006 18:30:59 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Help with JET

Hi,

Le samedi 11 f=E9vrier 2006 =E0 12:10 -0500, Bill Page a =E9crit :
> On February 11, 2006 11:31 AM Vanuxem Gr=E9gory wrote:
> >
> > I have tested JET with the December release of Axiom (downloaded the
> > 01/25/06 at savannah) on Linux and that works correctly.
> >
>
> Could you please provide detailed instructions as to what
> you compiled and in what order you compiled the modules?

Compiled in this order:

-- JetBundle.spad (two times because of an error:
        "|JetBundleCategory|   is not of type SEQUENCE"
        (probably a conflict between abbreviation and macro)
-- Sparse.spad
-- JetFunCat.spad
-- JetFun.spad
-- JetGeo.spad
-- DiffEq.spad
-- CarKur.spad

I haven't compiled the other files (some of them doesn't compile).


>
> Are you using just the SPAD code or the Aldor code?

I'm using only the spad code.

>
> After everything is compiled, does it run the first example
> properly?

Yes, it's the only sample that i've tested
(the result is correct).

>
> >
> > But i have found, may be, a little mistake in the file
> > foam_l.lisp.pamphlet
> >
> > The diff from Peter Broadbery is :
> >
> > ------------------------------------------------------------
> > --- orig/src/interp/foam_l.lisp.pamphlet
> > +++ mod/src/interp/foam_l.lisp.pamphlet
> > @@ -884,8 +884,8 @@
> >   (cond ( (or (NULL u) (NULL v)) nil)
> >         ( (and (ATOM u) (ATOM v)) (eql u v))
> >         ( (or (ATOM u) (ATOM v)) nil)
> > -       ( (equal (length u) (length v)) (|magicEq1| u v))
> > -       nil ))
> > +;;       ( (equal (length u) (length v)) (|magicEq1| u v))
> > +       (t (eq u v))))
> > 
> >  (defun |magicEq1| (u v)
> >   (cond ( (and (atom u) (atom v)) (|politicallySound| u v))
> > ------------------------------------------------------------
> >
> >
> > and the content of foam_l.lisp.pamphlet is:
> >
> >
> > ------------------------------------------------------------
> >  (cond ( (or (NULL u) (NULL v)) nil)
> >        ( (and (ATOM u) (ATOM v)) (eql u v))
> >        ( (or (ATOM u) (ATOM v)) nil)
> > ;; removed for Aldor integration
> > ;;       ( (equal (length u) (length v)) (|magicEq1| u v))
> >        nil ))
> >
> > (defun |magicEq1| (u v)
> >  (cond ( (and (atom u) (atom v)) (|politicallySound| u v))
> > ------------------------------------------------------------
> >
> >
> > There is a replacement of 'nil' by 't (eq u v))'.
> >
>
> I presume that this would only affect Aldor code when run
> inside Axiom, right?

right.

>
> What is the error that makes you think Peter's code is
> incorrect?

\start
Date: Sat, 11 Feb 2006 12:10:01 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Help with JET

On February 11, 2006 11:31 AM Vanuxem Gr=E9gory wrote:
>
> I have tested JET with the December release of Axiom (downloaded the
> 01/25/06 at savannah) on Linux and that works correctly.
>

Could you please provide detailed instructions as to what
you compiled and in what order you compiled the modules?

Are you using just the SPAD code or the Aldor code?

After everything is compiled, does it run the first example
properly?

>
> But i have found, may be, a little mistake in the file
> foam_l.lisp.pamphlet
>
> The diff from Peter Broadbery is :
>
> ------------------------------------------------------------
> --- orig/src/interp/foam_l.lisp.pamphlet
> +++ mod/src/interp/foam_l.lisp.pamphlet
> @@ -884,8 +884,8 @@
>   (cond ( (or (NULL u) (NULL v)) nil)
>         ( (and (ATOM u) (ATOM v)) (eql u v))
>         ( (or (ATOM u) (ATOM v)) nil)
> -       ( (equal (length u) (length v)) (|magicEq1| u v))
> -       nil ))
> +;;       ( (equal (length u) (length v)) (|magicEq1| u v))
> +       (t (eq u v))))
> 
>  (defun |magicEq1| (u v)
>   (cond ( (and (atom u) (atom v)) (|politicallySound| u v))
> ------------------------------------------------------------
>
>
> and the content of foam_l.lisp.pamphlet is:
>
>
> ------------------------------------------------------------
>  (cond ( (or (NULL u) (NULL v)) nil)
>        ( (and (ATOM u) (ATOM v)) (eql u v))
>        ( (or (ATOM u) (ATOM v)) nil)
> ;; removed for Aldor integration
> ;;       ( (equal (length u) (length v)) (|magicEq1| u v))
>        nil ))
>
> (defun |magicEq1| (u v)
>  (cond ( (and (atom u) (atom v)) (|politicallySound| u v))
> ------------------------------------------------------------
>
>
> There is a replacement of 'nil' by 't (eq u v))'.
>

I presume that this would only affect Aldor code when run
inside Axiom, right?

What is the error that makes you think Peter's code is
incorrect?

\start
Date: Sat, 11 Feb 2006 12:20:29 -0600
From: MathAction (rrogers)
To: MathAction
Subject: [#33 GCL fails to compile on Fedora Core 3] Fedora 3 fc3 Remedy??

Tim 
 You asked me for the two compiles, I put them in www.plaidheron.com/ray/temp
I thought I had posted this here but it doesn't seem to be here.
sorry for the repeat, if it exists in ... land.
I do want to take it down in a couple of days.

\start
Date: Sat, 11 Feb 2006 17:30:47 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Help with JET

I have tested JET with the December release of Axiom (downloaded the
01/25/06 at savannah) on Linux and that works correctly.


But i have found, may be, a little mistake in the file
foam_l.lisp.pamphlet

The diff from Peter Broadbery is :

------------------------------------------------------------
--- orig/src/interp/foam_l.lisp.pamphlet
+++ mod/src/interp/foam_l.lisp.pamphlet
@@ -884,8 +884,8 @@
  (cond ( (or (NULL u) (NULL v)) nil)
        ( (and (ATOM u) (ATOM v)) (eql u v))
        ( (or (ATOM u) (ATOM v)) nil)
-       ( (equal (length u) (length v)) (|magicEq1| u v)) 
-       nil ))
+;;       ( (equal (length u) (length v)) (|magicEq1| u v))
+       (t (eq u v))))
 
 (defun |magicEq1| (u v)
  (cond ( (and (atom u) (atom v)) (|politicallySound| u v))
------------------------------------------------------------


and the content of foam_l.lisp.pamphlet is:


------------------------------------------------------------
 (cond ( (or (NULL u) (NULL v)) nil)
       ( (and (ATOM u) (ATOM v)) (eql u v))
       ( (or (ATOM u) (ATOM v)) nil)
;; removed for Aldor integration
;;       ( (equal (length u) (length v)) (|magicEq1| u v)) 
       nil ))

(defun |magicEq1| (u v)
 (cond ( (and (atom u) (atom v)) (|politicallySound| u v))
------------------------------------------------------------


There is a replacement of 'nil' by 't (eq u v))'.

\start
Date: Sat, 11 Feb 2006 14:12:35 -0500
From: Tim Daly
To: Gregory Vanuxem
Subject: Re: Help with JET

fixed in the next release


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


> 
> > 
> > But i have found, may be, a little mistake in the file
> > foam_l.lisp.pamphlet
> > 
> > The diff from Peter Broadbery is :
> > 
> > ------------------------------------------------------------
> > --- orig/src/interp/foam_l.lisp.pamphlet
> > +++ mod/src/interp/foam_l.lisp.pamphlet
> > @@ -884,8 +884,8 @@
> >   (cond ( (or (NULL u) (NULL v)) nil)
> >         ( (and (ATOM u) (ATOM v)) (eql u v))
> >         ( (or (ATOM u) (ATOM v)) nil)
> > -       ( (equal (length u) (length v)) (|magicEq1| u v)) 
> > -       nil ))
> > +;;       ( (equal (length u) (length v)) (|magicEq1| u v))
> > +       (t (eq u v))))
> >  
> >  (defun |magicEq1| (u v)
> >   (cond ( (and (atom u) (atom v)) (|politicallySound| u v))
> > ------------------------------------------------------------
> > 
> > 
> > and the content of foam_l.lisp.pamphlet is:
> > 
> > 
> > ------------------------------------------------------------
> >  (cond ( (or (NULL u) (NULL v)) nil)
> >        ( (and (ATOM u) (ATOM v)) (eql u v))
> >        ( (or (ATOM u) (ATOM v)) nil)
> > ;; removed for Aldor integration
> > ;;       ( (equal (length u) (length v)) (|magicEq1| u v)) 
> >        nil ))
> > 
> > (defun |magicEq1| (u v)
> >  (cond ( (and (atom u) (atom v)) (|politicallySound| u v))
> > ------------------------------------------------------------
> > 
> > 
> > There is a replacement of 'nil' by 't (eq u v))'.
> > 
> 
> I presume that this would only affect Aldor code when run
> inside Axiom, right?

\start
Date: Sun, 12 Feb 2006 00:10:32 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Help with JET

Hi,

My apologies, JET does not really work on Windows nor on Linux.
The test was just a fresh compilation of JET in the order mentioned
in a previous email. That worked because, i think, the procedure (of
compilation) loads the library in a special order (thanks Bill for your
question).

For example the janet sample from Seiler works with

)lib JBC JBFC JBC- JBFC- BFC BFC- JB JBX   JBLF  DE SEM  DIFF JBE CK

Another order trigger the evalSlotDomain bug or 

   >> System error:
   The index, 3, is too large.

\start
Date: Sat, 11 Feb 2006 17:36:19 -0600
From: MathAction (root)
To: MathAction
Subject: [#33 GCL fails to compile on Fedora Core 3]

got them. thanks. --t

\start
Date: Sun, 12 Feb 2006 00:56:30 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Help with JET

Hi,

> Hi,
>
> My apologies, JET does not really work on Windows nor on Linux.
> The test was just a fresh compilation of JET in the order mentioned
> in a previous email. That worked because, i think, the procedure (of
> compilation) loads the library in a special order (thanks Bill for your
> question).

I mean exposed in a special order of course.

Cheers,

Greg

> For example the janet sample from Seiler works with
>
> )lib JBC JBFC JBC- JBFC- BFC BFC- JB JBX   JBLF  DE SEM  DIFF JBE CK
>
> Another order trigger the evalSlotDomain bug or
>
>    >> System error:
>    The index, 3, is too large.

\start
Date: Sat, 11 Feb 2006 22:01:54 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Help with JET

Excellent! Thank you very much for finding this solution.

I was not aware that the order in which the pre-compiled modules
are listed could affect how they behave. Of course, for initial
compilation from source only certain orders are possible based
on the intermodule dependencies (at least there are no circular
dependencies here! :). But it seems like either a bug or a serious
design flaw in the way Axiom processes the )lib command that the
order here seems to matter. Do you agree that we should document
this "lib order dependency" as a bug/issue?

I wonder if this bug might also bite us if/when we try to add the
JET code into the main Axiom library?

Cheers,
Bill Page.

On February 11, 2006 6:11 PM Vanuxem Gr=E9gory wrote:
>
> My apologies, JET does not really work on Windows nor on Linux.
> The test was just a fresh compilation of JET in the order mentioned
> in a previous email. That worked because, i think, the procedure
> (of compilation) loads the library in a special order (thanks
> Bill for your question).
>
> For example the janet sample from Seiler works with
>
> )lib JBC JBFC JBC- JBFC- BFC BFC- JB JBX   JBLF  DE SEM  DIFF JBE CK
>
> Another order trigger the evalSlotDomain bug or
>
>    >> System error:
>    The index, 3, is too large.
>

\start
Date: Sun, 12 Feb 2006 01:25:10 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: non extending category

> How can I set an Aldor compiler switch when compiling Aldor code
> in Axiom?

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

(all on one line, of course)

>> With the original JetBundle.as (why are you removing the empty
>> lines???)

> I am not removing any lines.

Sorry, Bill. I didn't want to offend. I didn't press the EDIT button and 
just cut'n'pasted from the green area. So that's my fault. Please, 
forgive me.

> I guess you are running Aldor stand alone?

Right. I did not see a reason to start Axiom just to check whether the 
Aldor compile step works.

 > How then do you integrate the compiler output with Axiom?

That was not my main concern. I just tried to compile the code. But for 
including the results with Axiom... I think Martin Rubey knows and it 
should be written on the AxiomWiki -- maybe AldorForAxiom or so.

>> I haven't found a definition for the "SubDomain" constructor that
>> appears in src/algebra/integer.spad. :-(

> Like SubsetCategory, SubDomain is apparently a compiler primative.

Hmm, that cannot be true. If I compile just with the Aldor compiler, 
then the SPAD compiler is not involved. So if the Aldor compiler does 
not complain, it must find "SubDomain" in libaxiom.al. I am pretty sure 
that the Aldor compiler does NOT know of "SubDomain" by itself.

> In the case of both SubsetCategory and SubDomain, the usage is very
> restricted in the Algebra library - they appear almost to be invented
> for this one purpose alone.

Yes, and that might be a reason why you will not find "SubDomain" in the 
libalgebra.al and libaldor.al that is distributed with Aldor.

woodpecker:~/scratch/FRAC>aldor -gloop
%1 >> #include "algebra"
                                            Comp: 1760 msec, Interp: 10 msec
%2 >> SubDomain
       ^
[L2 C1] #1 (Error) No meaning for identifier `SubDomain'.

> But I presume that this sort of design has more or less carried over
> to Aldor, no? How does one define a sub-domain in Aldor?

There is neither something like PI nor NNI in the Aldor libraries. And 
till now I did not have any need for them.

But I think you could simply say

NonNegativeInteger: SomeCategoryForNNI == add {
   Rep == Integer;
   ...
   -- implement the signatures from SomeCategoryForNNI
   ...
}

In integer.spad it says

NonNegativeInteger: ...
   == SubDomain(Integer, #1 >= 0) add ...

So, if I remember correctly, "#1 >=0" is an old way of declaring an 
anonymous function (without giving the types!!!)

(x: Integer): Boolean +-> x >=0

But what does SubDomain return? And a much more interesting question: 
how does this work?

If I see Integer, than that is a blackbox for me. I only know the 
interface, ie, its type or its category.

Now what should SubDomain do? It takes, for example, the implementation 
of a function *: (%, %) -> % from Integer and returns another 
implementation that checks whether the input arguments are non-negative 
and the result is non-negative. If that were not a compiler primitive, I 
had no idea how that should work on a library level. I think, I would be 
unable to write the constructor "SubDomain" in a proper .as file. I 
cannot even guess what its input/output types would be.

I don't like "SubDomain".

Oh, something interesting... After the definition of NNI in integer.spad 
it reads

   {\bf NNI} depends on itself.

That is not at all obvious for my eyes. If Integer would be implemented 
without referring to NNI (and that can be done), then NNI could be 
implemented on top of Integer. So why is there a need for a cycle here?

>> It would be even better to relate the code to the paper but that
>> is probably too much for the beginning.

> Yes, I think this would be a great idea. If/when we get this code
> to compile, I think it would make a very good example of a literate
> program as a paper. I wonder if we can get the original LaTeX code
> for the paper from the author?

I guess it would be hard to convince Werner Seiler to help with writing 
this literate program? If someone other than him does it then probably 
still he will get all the fame. I fear that this thought also applies to 
other pieces of code in Axiom.

\start
Date: Sun, 12 Feb 2006 14:54:49 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: non extending category

> >> It would be even better to relate the code to the paper but that
> >> is probably too much for the beginning.
> 
> > Yes, I think this would be a great idea. If/when we get this code
> > to compile, I think it would make a very good example of a literate
> > program as a paper. I wonder if we can get the original LaTeX code
> > for the paper from the author?
> 
> I guess it would be hard to convince Werner Seiler to help with writing 
> this literate program? If someone other than him does it then probably 
> still he will get all the fame. I fear that this thought also applies to 
> other pieces of code in Axiom.

I'd like someone (I'll do it if anyone knows Seiler's email) to ask
Werner if we could quote his technical paper as part of the documentation.
I have works in progress based on Trager's PhD thesis and Bronstein's
PhD thesis. Both of them gave permission to use the works. Clearly their
names belong on the literate programs. It is also clear that the thesis
is not structured to be a literate program and it contains material
that is not related to the domains being documented. Thus the thesis
material has to be rewritten or edited and there have to be words written
to connect the work to the code. Plus there is additional wording needed
to explain the design choices actually made in the code. These do not
appear in the thesis but are original words. So the literate program
author also gets listed.

For example, in the dhmatrix.spad.pamphlet literate program, the majority
of the words come from Richard Paul's PhD thesis but the rest of it
comes from my effort. Thus the 'credit' line reads: Richard Paul and
Timothy Daly.

If you work on a literate program you should put your name in the list
of credits. 

Credit is easy to share and the official Axiom policy is that we give
credit if a contribution is made. If there are more than 5 people listed
as "authors" or the actual author is unknown then we use "the axiom team".

I originally credited everything to 'Bourbaki' but was told that this
is a trademark of a group of french mathematicians.

Werner should certainly appear first in the list of credits on any of
the literate program files that result from this work. We need to 
document these programs and his words are the best source. But there
is still a significant amount of effort to make these files into
literate programs and the persons making that effort should share the
credit.

\start
Date: Sun, 12 Feb 2006 14:31:40 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: non extending category

On February 11, 2006 7:25 PM Ralf Hemmecke wrote:
> 
> > How can I set an Aldor compiler switch when compiling Aldor code
> > in Axiom?
> 
> )set compiler args "-O -Fasy -Fao -Flsp -laxiom 
> -Mno-AXL_W_WillObsolete 
> -DAxiom -Y $AXIOM/algebra -mno-mactext"
> 
> (all on one line, of course)
> 

Ok, great. I will try this.

> >> With the original JetBundle.as (why are you removing the empty
> >> lines???)
> 
> > I am not removing any lines.
> 
> Sorry, Bill. I didn't want to offend. I didn't press the EDIT 
> button and just cut'n'pasted from the green area. So that's my
> fault. Please, forgive me.

No problem! Just so long as we are clear. :)

> 
> > I guess you are running Aldor stand alone?
> 
> Right. I did not see a reason to start Axiom just to check 
> whether the Aldor compile step works.

I suppose that it is good to try it separately just to check
the Aldor compile but of course this code is designed to run
from within Axiom.

> 
>  > How then do you integrate the compiler output with Axiom?
> 
> That was not my main concern. I just tried to compile the code.
> But for including the results with Axiom... I think Martin Rubey
> knows and it should be written on the AxiomWiki -- maybe
> AldorForAxiom or so.

Yes, that is it exactly. That has also been implemented on the
LatexWiki/MathAction extension that runs Axiom Wiki so this is
possible from within a web page.

> 
> >> I haven't found a definition for the "SubDomain" constructor
> >> that appears in src/algebra/integer.spad. :-(
> 
> > Like SubsetCategory, SubDomain is apparently a compiler primative.
> 
> Hmm, that cannot be true.

??? But this is true. src/algebra/integer.spad is written in SPAD.
Did you check the references in the interp/compiler.boot code that
I sent you?

> If I compile just with the Aldor compiler, then the SPAD compiler
> is not involved.

But src/algebra/integer.spad is involved indirectly through
the Axiom library interface, I think.

> So if the Aldor compiler does not complain, it must find
> "SubDomain" in libaxiom.al. I am pretty sure that the Aldor
> compiler does NOT know of "SubDomain" by itself.

Perhaps it is true that stand alone Aldor does implement
something like SubDomain in the algebra. Aldor, in a sense,
is a more "primitive" compiler than SPAD, i.e. with fewer
things built-in and more of "SPAD" actually coded in Aldor.
Actually this makes Aldor more powerful and flexible than
SPAD. But in Axiom itself, the SPAD compile seems to
implement some of these things as primitives.

> 
> > In the case of both SubsetCategory and SubDomain, the usage
> > is very restricted in the Algebra library - they appear almost
> > to be invented for this one purpose alone.
> 
> Yes, and that might be a reason why you will not find 
> "SubDomain" in the libalgebra.al and libaldor.al that is
> distributed with Aldor.

I am not sure I follow you but maybe you mean the same thing
as I said above - that SubDomain is needed to compile
src/algebra/integer.spad and with Axiom, Aldor must interface
with this routine?

> 
> woodpecker:~/scratch/FRAC>aldor -gloop
> %1 >> #include "algebra"
>                                             Comp: 1760 msec, 
> Interp: 10 msec
> %2 >> SubDomain
>        ^
> [L2 C1] #1 (Error) No meaning for identifier `SubDomain'.
> 
> > But I presume that this sort of design has more or less carried over
> > to Aldor, no? How does one define a sub-domain in Aldor?
> 
> There is neither something like PI nor NNI in the Aldor 
> libraries. And till now I did not have any need for them.

Hmmm.... that's interesting.

> 
> But I think you could simply say
> 
> NonNegativeInteger: SomeCategoryForNNI == add {
>    Rep == Integer;
>    ...
>    -- implement the signatures from SomeCategoryForNNI
>    ...
> }
> 
> In integer.spad it says
> 
> NonNegativeInteger: ...
>    == SubDomain(Integer, #1 >= 0) add ...
> 
> So, if I remember correctly, "#1 >=0" is an old way of declaring an 
> anonymous function (without giving the types!!!)
> 
> (x: Integer): Boolean +-> x >=0
> 

No. The expression '#1 >= 0' is a boolean expression which is
saying something like "you can coerce an Integer to an NNI
provided that the integer value is greater than or equal to
zero".

> But what does SubDomain return?

SubDomain is an expression that defines a new domain.

> And a much more interesting question: how does this work?

For that you must consult the undocumented interp/compiler.boot
source code. :(

> 
> If I see Integer, than that is a blackbox for me. I only
> know the interface, ie, its type or its category.
> 
> Now what should SubDomain do? It takes, for example, the 
> implementation of a function *: (%, %) -> % from Integer
> and returns another implementation that checks whether the
> input arguments are non-negative and the result is non-negative.

No. I think it simply lifts all operations from Integer to NNI.

> If that were not a compiler primitive, I had no idea how that
> should work on a library level. I think, I would be unable to
> write the constructor "SubDomain" in a proper .as file. I 
> cannot even guess what its input/output types would be.
> 
> I don't like "SubDomain".

I agree that this concept does not seem to be clearly explained
anywhere. There is a little more about this concept in the glossary
of the Axiom book. I would love to see some of the original Axiom
design documentation/papers/notes about this. 

> 
> Oh, something interesting... After the definition of NNI in 
> integer.spad it reads
> 
>    {\bf NNI} depends on itself.
> 
> That is not at all obvious for my eyes. If Integer would be 
> implemented without referring to NNI (and that can be done),
> then NNI could be implemented on top of Integer. So why is there
> a need for a cycle here?
> 

I also do not understand this comment in the code.

\start
Date: Sun, 12 Feb 2006 21:12:57 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#267 tex.spad does not implement ALTSUPERSUB]

In http://wiki.axiom-developer.org/axiom--test--1/src/algebra/OutformSpad
supersub(a,[sub1,super1,sub2,super2,...]) is defined as::

  creates a form with each subscript aligned
  under each superscript.

but it is not implemented as one of the specialOps in
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/TexSpad
see for example::

  op = "SUPERSUB" =>
    ...

As a result these sub/super-scripted symbols are not displayed
properly in LaTeX form:

\begin{axiom}
)set output algebra on
)set expose add constructor OutputForm
\end{axiom}

\begin{axiom}
supersub(message "M", [q, paren(s)])
\end{axiom}

\start
Date: Mon, 13 Feb 2006 01:05:08 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: non extending category

On 02/12/2006 08:31 PM, Bill Page wrote:
>>>> I haven't found a definition for the "SubDomain" constructor
>>>> that appears in src/algebra/integer.spad. :-(
>>> Like SubsetCategory, SubDomain is apparently a compiler primative.
>> Hmm, that cannot be true.
> 
> ??? But this is true. src/algebra/integer.spad is written in SPAD.
> Did you check the references in the interp/compiler.boot code that
> I sent you?

No I did not check. I don't speak "BOOT".
Now I checked and I know as much as I knew before. That code is not 
understandable to me. Although I tend to say that in

coerceSubset([x,m,e],m') ==
   isSubset(m,m',e) or m="Rep" and m'="$" => [x,m',e]
   m is ['SubDomain,=m',:.] => [x,m',e]
   (pred:= LASSOC(opOf m',get(opOf m,'SubDomain,e))) and INTEGERP x and
      -- obviously this is temporary
     eval substitute(x,"#1",pred) => [x,m',e]
   (pred:= isSubset(m',maxSuperType(m,e),e)) and INTEGERP x -- again 
temporary
     and eval substitute(x,"*",pred) =>
       [x,m',e]
   nil

(which is the only place where "SubDomain" appears) that does not look 
like a DEFINITION of "SubDomain", more like USE.

>> If I compile just with the Aldor compiler, then the SPAD compiler
>> is not involved.

> But src/algebra/integer.spad is involved indirectly through
> the Axiom library interface, I think.

That should certainly be true, but that code does not contain a 
definition of SubDomain. It must be defined somewhere else and that code 
must live in libaxiom.al since that is the only data that Aldor sees 
from Axiom.

>> So if the Aldor compiler does not complain, it must find
>> "SubDomain" in libaxiom.al. I am pretty sure that the Aldor
>> compiler does NOT know of "SubDomain" by itself.

> Perhaps it is true that stand alone Aldor does implement
> something like SubDomain in the algebra.

There are three relevant libraries around
1) libaldor.al (aldor.org)
2) libalgebra.al (aldor.org)
3) libaxiom.al (AXIOM)

Since I have access to the sources of the first two libraries, I can 
assure you that there is no definition of "SubDomain" there.

> Aldor, in a sense,
> is a more "primitive" compiler than SPAD, i.e. with fewer
> things built-in and more of "SPAD" actually coded in Aldor.

Right. That is the reason why it is actually easy to learn Aldor. There 
are only a few language constructs that you have to remember.
It is much harder to learn what is available through libraries.
Unfortunately, there are several libraries around and except that 
libalgebra.al builds upon libaldor.al, there are many incompatibilities 
between libaxiom and libalgebra.

To make things even more complicated... there is also a library 
libaxllib.al and basicmath.al. I haven't seen the latter one, but Marc 
Moreno Maza (who wrote most of it -- I believe) ported much code to 
libalgebra.al.

>> In integer.spad it says
>>
>> NonNegativeInteger: ...
>>    == SubDomain(Integer, #1 >= 0) add ...
>>
>> So, if I remember correctly, "#1 >=0" is an old way of declaring an 
>> anonymous function (without giving the types!!!)
>>
>> (x: Integer): Boolean +-> x >=0
>>
> 
> No. The expression '#1 >= 0' is a boolean expression which is
> saying something like "you can coerce an Integer to an NNI
> provided that the integer value is greater than or equal to
> zero".

OK. '#1 >= 0' is depending on the first argument of SubDomain. 
Otherwise, nobody could find out what the symbol '0' actually stands 
for. So I guess then an Aldor definition would look like

SubDomain: (T: Type, isElement?: T -> Boolean): ??? == { ... }

where ??? is some category that is quite hard to guess.
And the second entry of SubDomain is a Boolean valued function
(ie. '#1 >= 0' is a function).

>> But what does SubDomain return?

> SubDomain is an expression that defines a new domain.

That is a good guess. ;-)

>> And a much more interesting question: how does this work?

> For that you must consult the undocumented interp/compiler.boot
> source code. :(

Since SubDomain is not clearly defined, nobody will be able to use it 
properly except those few people who know about its semantics. For all 
the others it is guesswork and that totally contradicts the goal of 
Axiom to support a clear type hierarchy.

>> If I see Integer, than that is a blackbox for me. I only
>> know the interface, ie, its type or its category.
>>
>> Now what should SubDomain do? It takes, for example, the 
>> implementation of a function *: (%, %) -> % from Integer
>> and returns another implementation that checks whether the
>> input arguments are non-negative and the result is non-negative.
> 
> No. I think it simply lifts all operations from Integer to NNI.

That is what I feared. It is like a hidden "pretend" somewhere.

In Aldor one could write it like

NNI: SomeCategory == Integer add {
   Rep == Integer;
   -- remaining functions
}

NNI then inherits anything from Integer that it does not explicitly 
override. So for example, if SomeCategory contains

-: (%, %) -> %

and NNI does not explicitly override it, then it is the - from Integer.
But that would clearly not be the intend of the programmer, since 3-4 is 
not a NNI. So one has to override it.

(a: %) - (b: %): % == {
   c: Rep := rep a - rep b;
   if c < 0 then throw NoNonNegativeIntegerException;
   per c;
}

I guess, what SubDomain does, is to add to each function that returns 
"%" (i.e. a NNI) a check that is given through the second argument of 
SubDomain.

That looks inefficient, given that there is no need for a check for the 
addition function. :-(

>> Oh, something interesting... After the definition of NNI in 
>> integer.spad it reads
>>
>>    {\bf NNI} depends on itself.
>>
>> That is not at all obvious for my eyes. If Integer would be 
>> implemented without referring to NNI (and that can be done),
>> then NNI could be implemented on top of Integer. So why is there
>> a need for a cycle here?
>>
> 
> I also do not understand this comment in the code.

Well, maybe it is a little like in the libraries of Aldor. In libaldor 
Integer is defined. But the concept of an AbelianMonoid is not yet 
there. Later, (in libalgebra) the category AbelianMonoid is introduced 
which contains the signature

	*: (Integer, %) -> %;

Again, later Integer is extended to belong o the category AbelianMonoid.
That looks like a circular definition for Integer, but by means of 
Aldor's "extend" keyword, that causes no problem at all.

\start
Date: Mon, 13 Feb 2006 16:31:24 +0100
From: Gregory Vanuxem
To: Bill Page
Subject: RE: Help with JET

> I was not aware that the order in which the pre-compiled modules
> are listed could affect how they behave. Of course, for initial
> compilation from source only certain orders are possible based
> on the intermodule dependencies (at least there are no circular
> dependencies here! :). But it seems like either a bug or a serious
> design flaw in the way Axiom processes the )lib command that the
> order here seems to matter. Do you agree that we should document
> this "lib order dependency" as a bug/issue?

I don't know, it could be due to initialisation code
(see for example JetBundle.spad lines 565-573).

\start
Date: Mon, 13 Feb 2006 11:30:36 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: What is SubDomain (was: non extending category)

On February 12, 2006 7:05 PM Ralf Hemmecke wrote:
> ...
> No I did not check. I don't speak "BOOT".

I don't speak "BOOT" either but I am slowly learning to read it a
little. :) I agree that in the absence of any documentation, this
is quite obscure. This is the kind of "source code archaeology"
that Tim Daly has referred to in the past. Tim has proposed re-
writing this in Lisp, but I am convinced this would only make
things worse.

I think the main missing information is the specific details
about the internal representation of domains and the mechanics
of how this all works. Some of this can be deduced from another
very important module written in BOOT:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/InteropBoot

Would you prefer perhaps to read this coding in Lisp? Not me.

I learned a little about this from Peter Broadbery. See

http://wiki.axiom-developer.org/209TheFunctionDomainIsUndefined

also

http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00250.htm=
l

> Now I checked and I know as much as I knew before. That code is not
> understandable to me. Although I tend to say that in
>
> coerceSubset([x,m,e],m') ==
>    isSubset(m,m',e) or m="Rep" and m'="$" => [x,m',e]
>    m is ['SubDomain,=m',:.] => [x,m',e]
>    (pred:= LASSOC(opOf m',get(opOf m,'SubDomain,e))) and
> INTEGERP x and
>       -- obviously this is temporary
>      eval substitute(x,"#1",pred) => [x,m',e]
>    (pred:= isSubset(m',maxSuperType(m,e),e)) and INTEGERP x -- again =

> temporary
>      and eval substitute(x,"*",pred) =>
>        [x,m',e]
>    nil
>
> (which is the only place where "SubDomain" appears) that does
> not look like a DEFINITION of "SubDomain", more like USE.

Actually the "definition" of 'SubDomain' appears to be spread over
several modules. The search:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/FrontPage/searc=
hwi
ki?expr=subdomain

show that it occurs in 33 modules in the interp source code, but
I think not all of these are relevant because there are actually
two different versions of the SPAD compiler (or at least part of two)
in the source distribution and only one is actually used. But it
still seems like an amazing amount of code for something that it
really only used once in the Axiom algebra. Some of this code has
dates going back to 1986... so at least initially it must have been
anticipated that the concept of SubDomain was going to be important.

For example:

http://wiki.axiom-developer.org/axiom--test--1/src/interp/BuildomBoot

contains the comment:

-- This file contains the constructors for the domains that cannot
-- be written in ScratchpadII yet. They are not cached because they
-- are very cheap to instantiate.
-- SMW and SCM July 86
SETANDFILEQ($noCategoryDomains, '(Domain Mode SubDomain))
SETANDFILEQ($nonLisplibDomains,
APPEND($Primitives,$noCategoryDomains))

-----------

SCM: Do you happen to remember what you wrote 20 years ago? :)

>
> >> If I compile just with the Aldor compiler, then the SPAD
> >> compiler is not involved.
>
> > But src/algebra/integer.spad is involved indirectly through
> > the Axiom library interface, I think.
>
> That should certainly be true, but that code does not contain
> a definition of SubDomain. It must be defined somewhere else
> and that code must live in libaxiom.al since that is the only
> data that Aldor sees from Axiom.

'libaxiom.al' is a binary file so I can't see easily what is in
that file but I don't think there is any explicit code for
SubDomain here. Rather, it seems to me that the SPAD compiler
internally implements whatever it needs to compile this primitive
construct directly to Lisp. As far as I understand it 'libaxiom.al'
provides the interface to the Axiom modules written in SPAD, so
Aldor never has to worry about the implementation of SubDomain
as such.

>
> >> So if the Aldor compiler does not complain, it must find
> >> "SubDomain" in libaxiom.al. I am pretty sure that the Aldor
> >> compiler does NOT know of "SubDomain" by itself.
>
> > Perhaps it is true that stand alone Aldor does implement
> > something like SubDomain in the algebra.
>
> There are three relevant libraries around
> 1) libaldor.al (aldor.org)
> 2) libalgebra.al (aldor.org)
> 3) libaxiom.al (AXIOM)
>
> Since I have access to the sources of the first two libraries,
> I can assure you that there is no definition of "SubDomain"
> there.

The third one is built by Peter Broadbery's make script as part
of the Axiom/Aldor interface. I guess we would have to dig into
that code to see exactly what is in this library.

>
> > Aldor, in a sense, is a more "primitive" compiler than SPAD,
> > i.e. with fewer things built-in and more of "SPAD" actually
> > coded in Aldor.
>
> Right. That is the reason why it is actually easy to learn
> Aldor. There are only a few language constructs that you have
> to remember. It is much harder to learn what is available
> through libraries. Unfortunately, there are several libraries
> around and except that libalgebra.al builds upon libaldor.al,
> there are many incompatibilities between libaxiom and
> libalgebra.

In Axiom I think we only get to use libaxiom. Using the Aldor
native library would be very complicated because of differing
internal implementations. Right?

> ...
> >> In integer.spad it says
> >>
> >> NonNegativeInteger: ...
> >>    == SubDomain(Integer, #1 >= 0) add ...
> >>
> ...
> OK. '#1 >= 0' is depending on the first argument of SubDomain.
> Otherwise, nobody could find out what the symbol '0' actually
> stands for. So I guess then an Aldor definition would look like
>
> SubDomain: (T: Type, isElement?: T -> Boolean): ??? == { ... }
>
> where ??? is some category that is quite hard to guess.
> And the second entry of SubDomain is a Boolean valued
> function (ie. '#1 >= 0' is a function).
>
> >> But what does SubDomain return?
>
> > SubDomain is an expression that defines a new domain.
>
> That is a good guess. ;-)
>
> >> And a much more interesting question: how does this work?
>
> > For that you must consult the undocumented interp/compiler.boot
> > source code. :(
>
> Since SubDomain is not clearly defined, nobody will be able to
> use it properly except those few people who know about its
> semantics. For all the others it is guesswork and that totally
> contradicts the goal of Axiom to support a clear type hierarchy.

I agree. This seems to be something that should be corrected.
Perhaps, because it is actually so little used, it could even
discarded all together. Maybe this was the strategy taken when
Aldor was designed?

I think it should be possible to implement NNI (NonNegative
Integer) and PI (Positive Integer) without the use of SubDomain.
Maybe just an import of Integer would do? I do not know of any
specific case where the knowledge that NNI and PI are "subdomains"
of Integer is actually used.

>
> >> If I see Integer, than that is a blackbox for me. I only
> >> know the interface, ie, its type or its category.
> >>
> >> Now what should SubDomain do? It takes, for example, the
> >> implementation of a function *: (%, %) -> % from Integer
> >> and returns another implementation that checks whether the
> >> input arguments are non-negative and the result is non-negative.
> >
> > No. I think it simply lifts all operations from Integer to NNI.
>
> That is what I feared. It is like a hidden "pretend" somewhere.
>
> In Aldor one could write it like
>
> NNI: SomeCategory == Integer add {
>    Rep == Integer;
>    -- remaining functions
> }
>
> NNI then inherits anything from Integer that it does not explicitly
> override. So for example, if SomeCategory contains
>
> -: (%, %) -> %
>
> and NNI does not explicitly override it, then it is the -
> from Integer. But that would clearly not be the intend of the
> programmer, since 3-4 is not a NNI. So one has to override it.
>
> (a: %) - (b: %): % == {
>    c: Rep := rep a - rep b;
>    if c < 0 then throw NoNonNegativeIntegerException;
>    per c;
> }
>

You are right that it is not that simple. In the Axiom interpreter
the commands:

  )sh NNI
  )sh PI

show that '-' is not defined in either domain. But I believe that
is because of the categories used in the definition of these
domains and not a consequence of the SubDomain specification.
See

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

> I guess, what SubDomain does, is to add to each function that returns
> "%" (i.e. a NNI) a check that is given through the second argument of
> SubDomain.
>
> That looks inefficient, given that there is no need for a
> check for the addition function. :-(

No, this does not happen. But NNI does add a new function named
subtractIfCan that returns 'Union(%, "Failed")'.

> ...

\start
Date: Mon, 13 Feb 2006 11:55:24 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Help with JET

Greg,

On February 13, 2006 10:31 AM you wrote:
>
> Bill Page wrote: 
> > I was not aware that the order in which the pre-compiled modules
> > are listed could affect how they behave. Of course, for initial
> > compilation from source only certain orders are possible based
> > on the intermodule dependencies (at least there are no circular
> > dependencies here! :). But it seems like either a bug or a serious
> > design flaw in the way Axiom processes the )lib command that the
> > order here seems to matter. Do you agree that we should document
> > this "lib order dependency" as a bug/issue?
> 
> I don't know, it could be due to initialisation code
> (see for example JetBundle.spad lines 565-573):

    -- some global constants
    nn:NNI := #IVar
    mm:NNI := #DVar
    nameX:V Sy := new(nn, first IVar)
    nameU:V Sy := new(mm, first DVar)
    for i in 2..nn repeat
      qsetelt!(nameX,i,qelt(IVar,i))
    for i in 2..mm repeat
      qsetelt!(nameU,i,qelt(DVar,i))

I think this code is ok. The purpose, I think is that the variables
'nameX' and 'nameU' become part of the representation (private data)
of each instance (member) of the JetBundle domain. Although the way
this is written seems a little awkward to me - I would have used
'construct' from 'Vector Symbol'.

I don't think this should be affected by the order in which the
library modules are listed.

\start
Date: Mon, 13 Feb 2006 18:52:06 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: What is SubDomain

Bill Page wrote:
> I don't speak "BOOT" either but I am slowly learning to read it a
> little. :) I agree that in the absence of any documentation, this
> is quite obscure. This is the kind of "source code archaeology"
> that Tim Daly has referred to in the past. Tim has proposed re-
> writing this in Lisp, but I am convinced this would only make
> things worse.

To me it doesn't matter whether the code is in BOOT or LISP. BOOT is not 
well documented and LISP is too low-level for my taste. Why cannot all 
this be written in Aldor? And without tricks, please. And, of course, 
well documented in pamphlets.

The problem is that the Aldor compiler is still not open source. :-(
But it already comes with a primitive FOAM-interpreter. I have no idea 
how difficult it would be to write a new interpreter from scratch in 
Aldor compared to clean the old interpreter/spad-compiler code.

> I think the main missing information is the specific details
> about the internal representation of domains and the mechanics
> of how this all works. Some of this can be deduced from another
> very important module written in BOOT:
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/interp/InteropBoot

I give up on this.

> Would you prefer perhaps to read this coding in Lisp? Not me.
> 
> I learned a little about this from Peter Broadbery. See
> 
> http://wiki.axiom-developer.org/209TheFunctionDomainIsUndefined
> 
> also
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00250.html

The latter is really interesting.

>>>>If I compile just with the Aldor compiler, then the SPAD
>>>>compiler is not involved.
>>
>>>But src/algebra/integer.spad is involved indirectly through
>>>the Axiom library interface, I think.
>>
>>That should certainly be true, but that code does not contain
>>a definition of SubDomain. It must be defined somewhere else 
>>and that code must live in libaxiom.al since that is the only
>>data that Aldor sees from Axiom.

> 'libaxiom.al' is a binary file so I can't see easily what is in
> that file but I don't think there is any explicit code for
> SubDomain here.

Oh. I also don't know how to read this. Does someone speak FOAM?

> Rather, it seems to me that the SPAD compiler
> internally implements whatever it needs to compile this primitive
> construct directly to Lisp. As far as I understand it 'libaxiom.al'
> provides the interface to the Axiom modules written in SPAD, so
> Aldor never has to worry about the implementation of SubDomain
> as such.

Oh, now I either don't understand or I am beginning to understand.

One thing is that Aldor NEVER sees SubDomain. I tried tried to write a 
domain similar to NNI, but using just Aldor and libaxiom.al on the 
command line. That doesn't work, because Aldor complains about not 
knowing anything about SubDomain.

So I guess, libaxiom.al, contains NNI as a fully built domain, but does 
not contain SubDomain. Is there someone who knows?

>>>Aldor, in a sense, is a more "primitive" compiler than SPAD,
>>>i.e. with fewer things built-in and more of "SPAD" actually
>>>coded in Aldor.
>>
>>Right. That is the reason why it is actually easy to learn 
>>Aldor. There are only a few language constructs that you have
>>to remember. It is much harder to learn what is available
>>through libraries. Unfortunately, there are several libraries
>>around and except that libalgebra.al builds upon libaldor.al,
>>there are many incompatibilities between libaxiom and
>>libalgebra.

> In Axiom I think we only get to use libaxiom. Using the Aldor
> native library would be very complicated because of differing
> internal implementations. Right?

The Axiom algebra code must be put into proper pamphlets anyway. It 
should be translated into Aldor. So way not taking the libalgebra 
sources of Aldor? That spares some rewriting of the code. Don't believe 
that it is so simple to translate SPAD into Aldor. I somehow think it 
would be cleaner to start building from existing Aldor libraries.
Having for a while two branches while adding code from Axiom to the 
Aldor libraries. That is a lot of work, but I would feel better 
concerning the foundations of the domains and categories in Axiom.

What I really don't like is that in Axiom sometimes information is added 
by the compiler/interpreter which does not exist in the .spad file 
itself. Type information that is guessed by the compiler is just an example.

>>Since SubDomain is not clearly defined, nobody will be able to
>>use it properly except those few people who know about its 
>>semantics. For all the others it is guesswork and that totally
>>contradicts the goal of Axiom to support a clear type hierarchy.

> I agree. This seems to be something that should be corrected.
> Perhaps, because it is actually so little used, it could even
> discarded all together. Maybe this was the strategy taken when
> Aldor was designed?

Well, I was not a designer of Aldor, but I appreciate that SubDomain is 
not built into the compiler.


> I think it should be possible to implement NNI (NonNegative
> Integer) and PI (Positive Integer) without the use of SubDomain.
> Maybe just an import of Integer would do? I do not know of any
> specific case where the knowledge that NNI and PI are "subdomains"
> of Integer is actually used.

Oh, that is a good suggestion. But maybe some code relies on elements 
being NNI or PI. To find this out, one can only go by hand through all 
the tons of code lines. :-( So it cannot be discarded immediately.

But when transferring to Aldor, one has to decide anyway what to do.

Anyway, I don't see need for a constructor SubDomain. What could be 
achieved by the SubDomain constructor, can easily be done using ordinary 
Aldor syntax.

\start
Date: Mon, 13 Feb 2006 11:42:20 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke,
Subject: Aldor and Axiom (was Re: What is SubDomain)


--- Ralf Hemmecke wrote:

> To me it doesn't matter whether the code is in BOOT or LISP. BOOT is
> not well documented and LISP is too low-level for my taste. Why 
> cannot all this be written in Aldor? And without tricks, please. 
> And, of course, well documented in pamphlets.

I'm beginning to agree that everything that can be in Aldor should be,
for two reasons:

a)  It's more self contained - e.g. the parts that involve being
compatible with anything except Axiom/Aldor are minimized.

b)  It will minimize the "communicating between multiple languages" and
"neeed to learn multiple languages" problems

That said, if Tim has already redone a given part in Literate Lisp,
it's not worth redoing his work in Aldor for the forseeable future -
work of that quality can't be easily duplicated and for certain aspects
of Axiom Lisp is in fact a good match.

> The problem is that the Aldor compiler is still not open source. :-(
> But it already comes with a primitive FOAM-interpreter. I have no
> idea how difficult it would be to write a new interpreter from 
> scratch in  Aldor compared to clean the old interpreter/spad-
> compiler code.

I can't help wondering if the material in the Reference section of the
Aldor Users Guide might be enough for us to define at least a basic
Aldor compiler in Lisp, and build on that.  If I'm understanding
correctly, most of what we would like to use from Aldor actually is
available in source code form, with the BSD+extra rights for Aldor.org
license?  And the most critical, libaldor and libalgebra, are Manual
Bronstein's work and might be releasable under plain Modified BSD
without having to unravel the Aldor.org knot?

If this is the case, it might be workable to implement a minimal Aldor
compiler in Lisp, building off of the knowledge already existing in the
code for SPAD compilation and the Reference section in the Aldor User
Guide.  Call it A# to avoid confusion, at least once we have a working
version.  I imagine we might want to develop Aldor a bit, and if
Aldor.org doesn't follow our changes it would be better not to confuse
the two.  That resolves two things:  a)  Both our existing Lisp code
and other useful Lisp code can still be easily handled and integrated
into Axiom, since the foundation language will still be Lisp and b)
will let us get down to business ordering, documenting, designing, and
making robust the Aldor level algebra of Axiom.  


> >>Right. That is the reason why it is actually easy to learn 
> >>Aldor. There are only a few language constructs that you have
> >>to remember. It is much harder to learn what is available
> >>through libraries. Unfortunately, there are several libraries
> >>around and except that libalgebra.al builds upon libaldor.al,
> >>there are many incompatibilities between libaxiom and
> >>libalgebra.

Would it be a forlorn hope that, if Aldor is easier to learn because
there are only a few language constructs, its compiler might also be
easier to define?

> > In Axiom I think we only get to use libaxiom. Using the Aldor
> > native library would be very complicated because of differing
> > internal implementations. Right?
> 
> The Axiom algebra code must be put into proper pamphlets anyway. It 
> should be translated into Aldor. So way not taking the libalgebra 
> sources of Aldor? That spares some rewriting of the code. Don't
> believe that it is so simple to translate SPAD into Aldor. I 
> somehow think it would be cleaner to start building from existing
> Aldor libraries.

I'm beginning to agree.  They would still need to be audited to make
sure they are up to Axiom's standards as Literate Documents, but if
they are cleaner and more robust while building on the same basic ideas
as Axiom's algebra it would make many things simpler.

> Having for a while two branches while adding code from Axiom to the 
> Aldor libraries. That is a lot of work, but I would feel better 
> concerning the foundations of the domains and categories in Axiom.

I think a more robust foundation will save work down the road.  The
grunt work of converting source code into literate papers documenting
the ideas will be the same regardless.

> What I really don't like is that in Axiom sometimes information is
> added by the compiler/interpreter which does not exist in the .spad
> file  itself. Type information that is guessed by the compiler is
> just an example.

Hmm.  But aren't there some cases where you want this, like (say)
knowing that 4 is a real integer without having to explicitly say that?
 (Sorry that's probably a dumb question).

> > I think it should be possible to implement NNI (NonNegative
> > Integer) and PI (Positive Integer) without the use of SubDomain.
> > Maybe just an import of Integer would do? I do not know of any
> > specific case where the knowledge that NNI and PI are "subdomains"
> > of Integer is actually used.
> 
> Oh, that is a good suggestion. But maybe some code relies on
> elements being NNI or PI. To find this out, one can only go by hand
> through all the tons of code lines. :-( So it cannot be discarded
> immediately.
> 
> But when transferring to Aldor, one has to decide anyway what to do.

I think a tutorial on moving SPAD code to Axiom will eventually be a
must.
 
\start
Date: Mon, 13 Feb 2006 15:21:23 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Aldor and Axiom (was Re: What is SubDomain)

On February 13, 2006 2:42 PM C Y wrote:
> 
> That said, if Tim has already redone a given part in Literate
> Lisp, it's not worth redoing his work in Aldor for the foreseeable
> future - work of that quality can't be easily duplicated and for
> certain aspects of Axiom Lisp is in fact a good match.

I am quite sure Tim has not touched this part (i.e. the SPAD
compiler's implementation of SubDomain) yet. Tim? Converting
this stuff to working Lisp (other than just keeping the Boot
generated Lisp), would be a **major** task with little obvious
benefit.

> .. 
> I can't help wondering if the material in the Reference section
> of the Aldor Users Guide might be enough for us to define at
> least a basic Aldor compiler in Lisp, and build on that.

This suggestion has been made a few times so I think it's time
I said that I think it is utterly ridiculous. There is **zero**
change that we could find experienced Lisp resources to implement
this idea. I think that someone could only make this suggestion
if they have **zero** experience with implementing a compiler.
Repeating this suggestion seems to me to be almost bordering
on the "irresponsible". (Sorry Cliff, I don't mean to sound
too harsh but we have so few resources working on Axiom that I
worry that such unrealistic ideas can only serve to divert our
attention from what we can actually accomplish.)


> If I'm understanding correctly, most of what we would like to
> use from Aldor actually is available in source code form, with
> the BSD+extra rights for Aldor.org license?  And the most critical,
> libaldor and libalgebra, are Manual Bronstein's work and might be
> releasable under plain Modified BSD without having to unravel the
> Aldor.org knot?

No, I think this is the wrong way to think about the problem.
The problem of licensing and Aldor.org is minor compared to re-
implementing the Axiom library from the ground up.

> ... 
> Would it be a forlorn hope that, if Aldor is easier to learn
> because there are only a few language constructs, its compiler
> might also be easier to define?

Have you looked at any of the statistics about the existing Aldor
compiler? Number of lines of code? Time and number of people it
took to do the initial implementation?

> ...
> Ralf wrote: 
> > Having for a while two branches while adding code from Axiom to
> > the Aldor libraries. That is a lot of work, but I would feel
> > better concerning the foundations of the domains and categories
> > in Axiom.
>

Axiom vs. Aldor libraries is only half the problem and the Aldor
libraries are currently maybe only about 10% of the solution.
The other half of the problem is the Axiom interpreter which
encodes a great deal of knowledge about the Axiom library itself.
Right now they are tightly couple and one could not throw away
the Axiom library without also throwing away the interpreter.
 
> ... 
> > What I really don't like is that in Axiom sometimes information
> > is added by the compiler/interpreter which does not exist in the
> > .spad file itself.

The Axiom interpret does this by design.

> > Type information that is guessed by the compiler is just an
> > example.

Could you give an example where type information is "guessed" by
the SPAD compiler?

> 
> Hmm.  But aren't there some cases where you want this, like
> (say) knowing that 4 is a real integer without having to
> explicitly say that? (Sorry that's probably a dumb question).

The phrase "real integer" is kind of dumb ... :) What other kinds
of integers are there? But the symbol 4 can certainly stand for
other things besides the integer 4. But in the user interface,
such as implemented by the Axiom interpreter, it is quite natural
that unless stated otherwise, this symbol could be assumed to
represent the element of the positive integers. On the other hand,
in the SPAD and Aldor compilers, there should be no "guessing"
of this kind.

> 
> I think a tutorial on moving SPAD code to Axiom will eventually
> be a must.
>  

There already is such a tutorial as part of the Aldor documentation.
Converting SPAD to Aldor is usually very simple. There are just a
few subtle cases such as the SubDomain construct that we have been
discussing.

\start
Date: Mon, 13 Feb 2006 15:50:08 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: What is SubDomain

Ralf,

I think perhaps we can view SubDomain as the first steps towards computing
with provisos (i.e. "provided that ...  clauses") and it is closely related
to the concept of "indefinite types" as explained by Tim Daly:

http://lists.gnu.org/archive/html/axiom-developer/2005-05/msg00205.html

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

As Tim has pointed out, the Axiom algebra library does already contain a
domain called "SuchThat" that was among his first experiments in this
direction.

I think the the concept of NonNegativeInteger and PositiveInteger as
SubDomains of Integer are not so different from this. In a sense a
subdomain is just a domain with a proviso.

\start
Date: Mon, 13 Feb 2006 13:22:15 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: Aldor and Axiom

--- Bill Page wrote:
> > .. 
> > I can't help wondering if the material in the Reference section
> > of the Aldor Users Guide might be enough for us to define at
> > least a basic Aldor compiler in Lisp, and build on that.
> 
> This suggestion has been made a few times so I think it's time
> I said that I think it is utterly ridiculous. There is **zero**
> change that we could find experienced Lisp resources to implement
> this idea. I think that someone could only make this suggestion
> if they have **zero** experience with implementing a compiler.
> Repeating this suggestion seems to me to be almost bordering
> on the "irresponsible". (Sorry Cliff, I don't mean to sound
> too harsh but we have so few resources working on Axiom that I
> worry that such unrealistic ideas can only serve to divert our
> attention from what we can actually accomplish.)

No problem - I definitely don't have experience with implementing
compilers, and I have no desire at all to be "irresponsible".  But from
my perspective (which may or may not be accurate) we are being hindered
by the uncertainty surrounding SPAD vs. Aldor.  If we can't implement
our own Aldor compiler, that's OK, but we can't wait forever for the
one that does exist to be released - projects can die from uncertainty
and lack of momentum.  If some resolution isn't found fairly soon I
would recommend we pick a direction and go, even if it's cleaning up
SPAD and not worrying about Aldor except maybe for a design idea or
two.  I'm more concerned that we get SOME definite direction we can
head in, although perhaps we already do have one and I'm just not
grasping it properly. 
 
> > If I'm understanding correctly, most of what we would like to
> > use from Aldor actually is available in source code form, with
> > the BSD+extra rights for Aldor.org license?  And the most critical,
> > libaldor and libalgebra, are Manual Bronstein's work and might be
> > releasable under plain Modified BSD without having to unravel the
> > Aldor.org knot?
> 
> No, I think this is the wrong way to think about the problem.
> The problem of licensing and Aldor.org is minor compared to re-
> implementing the Axiom library from the ground up.

I guess I had been under the impression that the work of making the
Axiom library files into true literate documents was going to be little
short of a rewrite no matter what direction was taken - perhaps that is
a mistake on my part.

> > Would it be a forlorn hope that, if Aldor is easier to learn
> > because there are only a few language constructs, its compiler
> > might also be easier to define?
> 
> Have you looked at any of the statistics about the existing Aldor
> compiler? Number of lines of code? Time and number of people it
> took to do the initial implementation?

A very good point.  My thought was that following an existing design
would require less effort than the orgininal development, but that's a
most uninformed thought so I concede the point.

> > Ralf wrote: 
> > > Having for a while two branches while adding code from Axiom to
> > > the Aldor libraries. That is a lot of work, but I would feel
> > > better concerning the foundations of the domains and categories
> > > in Axiom.
> 
> Axiom vs. Aldor libraries is only half the problem and the Aldor
> libraries are currently maybe only about 10% of the solution.
> The other half of the problem is the Axiom interpreter which
> encodes a great deal of knowledge about the Axiom library itself.
> Right now they are tightly couple and one could not throw away
> the Axiom library without also throwing away the interpreter.

Ah.

> > Hmm.  But aren't there some cases where you want this, like
> > (say) knowing that 4 is a real integer without having to
> > explicitly say that? (Sorry that's probably a dumb question).
> 
> The phrase "real integer" is kind of dumb ... :) What other kinds
> of integers are there?

Heh.  None that I know of, but that's not saying much.  I thought units
and dimensions were simple too ;-)

> But the symbol 4 can certainly stand for
> other things besides the integer 4. But in the user interface,
> such as implemented by the Axiom interpreter, it is quite natural
> that unless stated otherwise, this symbol could be assumed to
> represent the element of the positive integers. On the other hand,
> in the SPAD and Aldor compilers, there should be no "guessing"
> of this kind.

OK.

> > I think a tutorial on moving SPAD code to Axiom will eventually
> > be a must.
> >  
> 
> There already is such a tutorial as part of the Aldor documentation.
> Converting SPAD to Aldor is usually very simple. There are just a
> few subtle cases such as the SubDomain construct that we have been
> discussing.

OK.  I guess my confusion comes in with what our actual plan is.  Are
we going to use Aldor.org to work with our existing code base, making a
few tweaks and updates to take advantage of Aldor's features but
keeping the rest as SPAD?  Are we going to try and completely retune
the Axiom codebase to center on the Aldor language?  How do we resolve
things like Aldor's libalgebra vs. Axiom's libraries?  Are we planning
to completely document and update the SPAD compiler?  Are we intending
to link the discussion and definitions of SPAD/Aldor to the core set
theory, category theory, and other foundational mathematical principles
that Axiom is built on?

I realize I'm almost useless for this kind of work, but since it seems
to be the biggest need of Axiom right now I would like to help if I
can, even if it's only something like creating a literate document
introducing basic set theory or category theory (e.g. something I might
be able to grasp in time, but also useful to documenting the core Axiom
system all other work must rely on.)  I guess what I'd most like to see
is a stage-by-stage kind of plan for the Algebra subproject.  Sort of
a:

a)  Document SPAD compiler, foundations in mathematical theory, core
structures of Axiom algebra
b)  Identify and document "core" functionality, which is to say
functionality which a large part of the Axiom system depends on.  Debug
code and concepts, possibly implement unit test framework.
c)  Work our way up the ladder, so to speak.  Higher level
functionality documented as the underpinnings become well documented
and well defined.

type of list.  Maybe this isn't workable with something as involved as
Axiom, but right now it's almost overwhelming - where should one look
first for the job of building a rock solid core on which the subsequent
tuning, debugging, and development can depend?    

\start
Date: Mon, 13 Feb 2006 16:57:30 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Aldor and Axiom

On February 13, 2006 4:22 PM C Y wrote:
> 
> --- Bill Page wrote:
> > ... (Sorry Cliff, I don't mean to sound
> > too harsh but we have so few resources working on Axiom that I
> > worry that such unrealistic ideas can only serve to divert our
> > attention from what we can actually accomplish.)
> 
> No problem - I definitely don't have experience with implementing
> compilers, and I have no desire at all to be "irresponsible". 

Ok, good. Communicating by email is always a danger since it is so
hard to "smile while you say something that sounds critical". Just
sometimes I feel so strongly about something that I can resist. :)

> But from my perspective (which may or may not be accurate) we are 
> being hindered by the uncertainty surrounding SPAD vs. Aldor.

I that the Axiom is being hindered by the fact the Aldor is not yet
available as open source.

> If we can't implement our own Aldor compiler, that's OK, but we
> can't wait forever for the one that does exist to be released -
> projects can die from uncertainty and lack of momentum.

True.

> If some resolution isn't found fairly soon I would recommend we
> pick a direction and go, even if it's cleaning up SPAD and not
> worrying about Aldor except maybe for a design idea or two.
> ...

I still firmly believe that Aldor is the best way forward. Given
that everyone who has posted to the:

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

petition (including Steven Watt!) has been positive about the
idea of making Aldor open source, I think we should just proceed
based on that idea. At this point I think we could even safely
start distributing the Aldor source code as an (optional?) part
of the Axiom source code distribution. We could state clearly
up front that the eventual license conditions are not yet
finalized but cover simply all bases by provisionally choosing
the most restrictive open source licensing - GPL for now. Later
this could be opened up to the BSD-style license that covers
most of the rest of Axiom, provided the interested parties all
agree.

>  
> ... 
> OK.  I guess my confusion comes in with what our actual plan is.
> Are we going to use Aldor.org to work with our existing code 
> base, making a few tweaks and updates to take advantage of Aldor's
> features but keeping the rest as SPAD?

No. I would propose that we proceed according to the original
plan at IBM - to convert all (or as much as possible) of Axiom's
library code from SPAD to Aldor.

> Are we going to try and completely retune the Axiom codebase to
> center on the Aldor language?

Yes.

> How do we resolve things like Aldor's libalgebra vs. Axiom's
> libraries?

I would propose that we forget about Aldor's native libraries for
now (as nice, though limited, as they are).

> Are we planning to completely document and update the SPAD compiler?

I would choose "no", although if time or experienced people became
available this might be interesting for historical reasons.

> Are we intending to link the discussion and definitions of SPAD/Aldor
> to the core set theory, category theory, and other foundational
> mathematical principles that Axiom is built on?

Yes! At least, where and when possible. I think this will necessarily
be an ongoing task.

> 
> I realize I'm almost useless for this kind of work, but since it
> seems to be the biggest need of Axiom right now I would like to
> help if I can,

I think your questions and suggestions are very useful. Someone
has to raise the level of discussion somehow! :)

> even if it's only something like creating a literate document
> introducing basic set theory or category theory (e.g. something
> I might be able to grasp in time, but also useful to documenting
> the core Axiom system all other work must rely on.)  I guess what
> I'd most like to see is a stage-by-stage kind of plan for the
> Algebra subproject.  Sort of a:
> 
> a)  Document SPAD compiler, foundations in mathematical theory,
> core structures of Axiom algebra
> b)  Identify and document "core" functionality, which is to say
> functionality which a large part of the Axiom system depends 
> on.  Debug code and concepts, possibly implement unit test
> framework.
> c)  Work our way up the ladder, so to speak.  Higher level
> functionality documented as the underpinnings become well
> documented and well defined.
> 
> type of list.

I would replace a) with conversion of the Axiom library to
Aldor, but the rest seems great to me.

> Maybe this isn't workable with something as involved as
> Axiom, but right now it's almost overwhelming - where should
> one look first for the job of building a rock solid core on
> which the subsequent tuning, debugging, and development can
> depend?    
> 

I think you have the right idea. :)

\start
Date: Mon, 13 Feb 2006 15:13:36 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: Aldor and Axiom

--- Bill Page wrote:

> On February 13, 2006 4:22 PM C Y wrote:
> > 
> > --- Bill Page wrote:
> > > ... (Sorry Cliff, I don't mean to sound
> > > too harsh but we have so few resources working on Axiom that I
> > > worry that such unrealistic ideas can only serve to divert our
> > > attention from what we can actually accomplish.)
> > 
> > No problem - I definitely don't have experience with implementing
> > compilers, and I have no desire at all to be "irresponsible". 
> 
> Ok, good. Communicating by email is always a danger since it is so
> hard to "smile while you say something that sounds critical". Just
> sometimes I feel so strongly about something that I can resist. :)

Heh.  No worries - I have a very bad habit of voicing opinions on
things I'm not really qualified to discuss, so I invite the occasional
strong response ;-).
 
> > But from my perspective (which may or may not be accurate) we are 
> > being hindered by the uncertainty surrounding SPAD vs. Aldor.
> 
> I that the Axiom is being hindered by the fact the Aldor is not yet
> available as open source.

Certainly true.  However, based on your comments below, I would suggest
the following steps might be immediately useful:

a)  Post the downloads for aldor on the Axiom site (I still can't get
through to aldor.org :-( and the site is slower now) - I think this is
allowed under the license no problem.

b)  Let's incorporate aldor into the main Axiom now - if it is firm we
will be using Aldor (and based on my recollection everyone is in
agreement Aldor is the way forward over SPAD) lets not wait for the
legal stuff to finalize - that could take many more months.  We could
at least do the following:

  i)  Work out how the Aldor compiler and the lisp structure of Axiom 
      should work together, and make that the default setup.  I know
      the BOOT vs. Lisp vs. Aldor debate could go on, and may yet, but
      for now let's go with Tim's Lisp work and the current Aldor.org
      compiler.  I don't (think) those issues will depend on having the
      compiler source code - am I wrong?  I think I recall it being
      said that the interperter needed to be educated about Aldor, for
      example?
  ii) Start retargeting the more important Axiom libraries to Aldor. 
      Absolute worst case scenario we retarget to SPAD again, and I
      doubt we will face worst case in the long run.  So let's assume
      Aldor until proven otherwise, and start to retarget code now.

Does that make sense, or is it too risky?  I think that's more or less
what's been going on of late anyway, but it might help to make it an
"official" project goal so people can be confident they aren't working
at cross-purposes with the main Axiom project.

> > If we can't implement our own Aldor compiler, that's OK, but we
> > can't wait forever for the one that does exist to be released -
> > projects can die from uncertainty and lack of momentum.
> 
> True.
> 
> > If some resolution isn't found fairly soon I would recommend we
> > pick a direction and go, even if it's cleaning up SPAD and not
> > worrying about Aldor except maybe for a design idea or two.
> > ...
> 
> I still firmly believe that Aldor is the best way forward. Given
> that everyone who has posted to the:
> 
>   http://wiki.axiom-developer.org/FreeAldor
> 
> petition (including Steven Watt!) has been positive about the
> idea of making Aldor open source, I think we should just proceed
> based on that idea.

OK.  On that basis, do my earlier suggestions make sense?

> At this point I think we could even safely
> start distributing the Aldor source code as an (optional?) part
> of the Axiom source code distribution. We could state clearly
> up front that the eventual license conditions are not yet
> finalized but cover simply all bases by provisionally choosing
> the most restrictive open source licensing - GPL for now. Later
> this could be opened up to the BSD-style license that covers
> most of the rest of Axiom, provided the interested parties all
> agree.

No, GPL won't quite work - Aldor.org requires complete rights to
derivative works, IIRC.  I think we can just stick the Aldor license
with the Aldor compiler and leave it at that, for now.  At a guess that
clause in the Aldor license was included to handle some of the same
issues I remember being mentioned for Axiom back in the
pre-code-release days, but that was when I was more into Maxima so I
confess it's a bit hazy.  

Out of curosity, does anybody know what the language of the Aldor
compiler is?  IIRC it can target a couple different languages for
compiler output(?) but I don't recall what language it's actually
written in.

> > OK.  I guess my confusion comes in with what our actual plan is.
> > Are we going to use Aldor.org to work with our existing code 
> > base, making a few tweaks and updates to take advantage of Aldor's
> > features but keeping the rest as SPAD?
> 
> No. I would propose that we proceed according to the original
> plan at IBM - to convert all (or as much as possible) of Axiom's
> library code from SPAD to Aldor.

OK.

> > How do we resolve things like Aldor's libalgebra vs. Axiom's
> > libraries?
> 
> I would propose that we forget about Aldor's native libraries for
> now (as nice, though limited, as they are).

Hmm.  OK, so you suggest we first get Axiom as it stands over to Aldor
and then proceed with any low level design changes, if any are
warranted?
 
> > Are we intending to link the discussion and definitions of
> > SPAD/Aldor to the core set theory, category theory, and other
> > foundational mathematical principles that Axiom is built on?
> 
> Yes! At least, where and when possible. I think this will necessarily
> be an ongoing task.

OK.  I know Axiom is supposed to be founded on category theory and/or
set theory, but does anybody know where the real "core" of that logic
resides?  I always figured that was the most fundamental mathematical
part of the code, but maybe I'm wrong.  I was kinda hoping Axiom could
serve as a modern, computerized Principia Mathematica++. 
(Interestingly, if a first edition is available, might it be out of
copyright?  Perhaps we could incorporate the Principica Mathematica
itself, or a variation, as a literate document!)

I think there are really two levels of mathematical "CAS" usage, if you
define "CAS" broadly enough:

a)  People working on proofs of new principles, formalizing mathematics
(proof systems like COQ, metamath, etc.)

b)  People who USE the mathematics in specific cases of the general
cases, for practical purposes (everything from solving a particular
symbolic integral to physics and engineering applications).  These
users benefit from the rigor sought and implemented by a) but do not
require the proof of the validity of their particular answer if the
system as a whole can be trusted.  (Maple, Mathematica, Maxima, etc.)

Axiom is in a bit of a unique position - it functions more at the level
of b), but some of its design properties hint that it could straddle
both a) and b) to the benefit of both.  Clearly there have already been
a few efforts in that direction - I wonder if Aldor's compiler could
target proof-engine languages as well as Lisp and C.  If a CAS user
wanted a formal proof of a statement, they could issue an Axiom level
command to generate a proof of a statement - Aldor could then compile
the top level statement to a form that a theorem prover could digest,
call the theorem prover, and have it digest it - then return the proof.
 Maybe it could even provide an interaction environment for interactive
proof systems.  Of course, that would require creating proof-engine
libraries of all of Axiom's built-in libraries, which should validate
both Axiom's correctness and the robustness of its type system, in
theory.

The nice part is that this can be done gradually, after the fact - it
is not a "do this before implementing anything" situation.  If that
ability is added to Aldor, it will become a tool to improve the
quality, correctness, and confidence in the libraries, but it is not
absolutely needed.

For Aldor gurus, am I correct that Aldor can target Lisp and C as
outputs of its compiled Aldor code?

> > I realize I'm almost useless for this kind of work, but since it
> > seems to be the biggest need of Axiom right now I would like to
> > help if I can,
> 
> I think your questions and suggestions are very useful. Someone
> has to raise the level of discussion somehow! :)

:-).  Thanks.

> > even if it's only something like creating a literate document
> > introducing basic set theory or category theory (e.g. something
> > I might be able to grasp in time, but also useful to documenting
> > the core Axiom system all other work must rely on.)  I guess what
> > I'd most like to see is a stage-by-stage kind of plan for the
> > Algebra subproject.  Sort of a:
> > 
> > a)  Document SPAD compiler, foundations in mathematical theory,
> > core structures of Axiom algebra
> > b)  Identify and document "core" functionality, which is to say
> > functionality which a large part of the Axiom system depends 
> > on.  Debug code and concepts, possibly implement unit test
> > framework.
> > c)  Work our way up the ladder, so to speak.  Higher level
> > functionality documented as the underpinnings become well
> > documented and well defined.
> > 
> > type of list.
> 
> I would replace a) with conversion of the Axiom library to
> Aldor, but the rest seems great to me.

OK.  I take it the compiler itself doesn't contain the definitions of
any of the algebraic types or constructs?

> > Maybe this isn't workable with something as involved as
> > Axiom, but right now it's almost overwhelming - where should
> > one look first for the job of building a rock solid core on
> > which the subsequent tuning, debugging, and development can
> > depend?    
> > 
> 
> I think you have the right idea. :)

Cool :-).  Then I vote for full steam ahead with Aldor - the legal
issues will take time, but there seems to be some confidence that they
can eventually be sorted out.  Let's bundle the sucker and start some
algebra tuning!

\start
Date: Mon, 13 Feb 2006 22:19:42 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Aldor and Axiom

On February 13, 2006 6:14 PM C Y wrote:
>...
> However, based on your comments below, I would suggest
> the following steps might be immediately useful:
> 
> a)  Post the downloads for aldor on the Axiom site (I still can't
> get through to aldor.org :-( and the site is slower now) - I think
> this is allowed under the license no problem.

I don't know what is happening with the aldor.org server. Some days
I can access it and other days not. Is this a good omen or a bad one?
Is it further motivation to proceed with distributing Aldor as part
of Axiom?

I think you can still get an older (v1.0.1) Windows version of Aldor
here:

http://www.orcca.on.ca/~ldragan/aldor/Windows_versions_of_Aldor.html

Here is the version of Aldor we are running the axiom-developer.org
server:

http://wiki.axiom-developer.org/public/aldor-linux-i386-v1.0.2.bin

There is also a version compiled specifically for x86-64 bit (AMD)
hardware that I run on Fedora Core 3:

http://wiki.axiom-developer.org/public/aldor-linux-x86_64-v1.0.2.bin

Note that the license conditions that are part of the installation
are the same as those on the Aldor.org site.

http://www.orcca.on.ca/~ldragan/aldor

refers to a new version v1.0.3rc1 (release candidate 1) of Aldor but
the link is incorrect. The correct link is:

http://www.orcca.on.ca/~ldragan/aldor/aldor-linux-v3-1.0.3rc1.tar.gz

The dates on the files are 2004-10-30. I have not tried this version
yet.

If you need help with the installation, just let me know.

> 
> b)  Let's incorporate aldor into the main Axiom now - if it is firm
> we will be using Aldor (and based on my recollection everyone is in
> agreement Aldor is the way forward over SPAD) lets not wait for the
> legal stuff to finalize - that could take many more months.  We
> could at least do the following:
> 
>   i)  Work out how the Aldor compiler and the lisp structure of
>       Axiom should work together, and make that the default setup.

This was done long ago at IBM. Peter Broadbery has provided patches
for the open source version of Axiom to support Aldor. Tim has
incorporated all of these patches into the more recent version of
the Axiom distribution except the actual build script that creates
the libaldor library. This is available from the Axiom Wiki website:

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

>       I know the BOOT vs. Lisp vs. Aldor debate could go on, and
>       may yet, but for now let's go with Tim's Lisp work and the
>       current Aldor.org compiler.  I don't (think) those issues
>       will depend on having the compiler source code - am I wrong?

Hmmm... well it's not open source if we don't distribute the source
code, is it? :)

But we could at least distribute Axiom with a fully functioning
build option to integrate with a previously installed binary
version of Aldor.

>       I think I recall it being said that the interpreter needed to
>       be educated about Aldor, for example?

No, this works now.

>   ii) Start retargeting the more important Axiom libraries to Aldor. 
>       Absolute worst case scenario we retarget to SPAD again, and I
>       doubt we will face worst case in the long run.  So let's assume
>       Aldor until proven otherwise, and start to retarget code now.
> 
> Does that make sense, or is it too risky?  I think that's more or
> less what's been going on of late anyway, but it might help to make
> it an "official" project goal so people can be confident they aren't
> working at cross-purposes with the main Axiom project.

I don't think it is risky but I doubt we will convince many people
until they see downloadable Aldor source code.

> ... 
> OK.  On that basis, do my earlier suggestions make sense?
>

I think we can complete the integration of the Aldor interface
build into the Axiom distribution. One sticky point is that
currently this requires the installation of the Sun Java
development system. Not everyone might want to do this just to
install Axiom + Aldor. But I rather think we should go ahead
with it anyway for now and just make sure that Java is only
required if the user chooses to build the Aldor interface.
 
> Bill Page wrote:
> > At this point I think we could even safely
> > start distributing the Aldor source code as an (optional?)
> > part of the Axiom source code distribution. We could state
> > clearly up front that the eventual license conditions are not
> > yet finalized but cover simply all bases by provisionally
> > choosing the most restrictive open source licensing - GPL
> > for now. Later this could be opened up to the BSD-style
> > license that covers most of the rest of Axiom, provided the
> > interested parties all agree.
> 
> No, GPL won't quite work - Aldor.org requires complete rights
> to derivative works, IIRC.

No where does it say that Aldor.org reserves *exclusive* rights.
GPL guarantees these rights to everyone, so it certainly
satisfies the original intent of at least the binary/library
source license distributed by Aldor.org.

> I think we can just stick the Aldor license with the Aldor
> compiler and leave it at that, for now.  At a guess that
> clause in the Aldor license was included to handle some of
> the same issues I remember being mentioned for Axiom back
> in the pre-code-release days, but that was when I was more
> into Maxima so I confess it's a bit hazy.  

The issue might eventually be who can incorporate Aldor into
non-open source software. At present the Axiom BSD-style license
allows this for Axiom itself but it is not clear to me whether
this is also the intent of Aldor.org. Choosing GPL as an interim
license would allow this to be decided at a later date.

> 
> Out of curiosity, does anybody know what the language of the
> Aldor compiler is?

Aldor is written in "C" and Aldor.

> IIRC it can target a couple different languages for compiler
> output(?) but I don't recall what language it's actually
> written in.

Aldor can generate code that runs with a stand alone run time
environment written in "C" or it can generate Lisp. When Aldor
is used within Axiom it generates Lisp that is compiled by GCL
the same way that the output of the SPAD compiler is compiled.

> ...
> > 
> > I would propose that we forget about Aldor's native libraries
> > for now (as nice, though limited, as they are).
> 
> Hmm.  OK, so you suggest we first get Axiom as it stands over to
> Aldor and then proceed with any low level design changes, if any
> are warranted?

Yes. Initially only the Axiom library code written in SPAD would
be converted to Aldor. The rest of Axiom would remain the same.

> ... 
> I know Axiom is supposed to be founded on category theory and/or
> set theory, but does anybody know where the real "core" of that
> logic resides?

That is related to discussion in the earlier thread about the
nature of the SubDomain construction. At least some of this
"logic" resides in the SPAD compiler itself. That could
potentially be a problem in the effort to convert the Axiom
library to Aldor since Aldor does not implement this "logic"
in the same way.

BTW, I do not think that it would be correct to say that Axiom
is founded on category theory as such. The use of the word
category in Axiom is quite different. But still in many ways
Axiom is compatible with many of the ideas of modern category
theory.

It is more correct to say that Axiom is founded on set theory
but only is a rather loose way.

> I always figured that was the most fundamental mathematical
> part of the code, but maybe I'm wrong.

Maybe we could agree that it is a kind of exaggeration? :)

> I was kinda hoping Axiom could serve as a modern, computerized
> Principia Mathematica++. (Interestingly, if a first edition is
> available, might it be out of copyright?  Perhaps we could
> incorporate the Principica Mathematica itself, or a variation,
> as a literate document!)

Sometimes your suggestions are quite "nuts" - do you know that? ;)
> ... 
> For Aldor gurus, am I correct that Aldor can target Lisp and C
> as outputs of its compiled Aldor code?

Yes.

> > > 
> > > a)  Document SPAD compiler, foundations in mathematical theory,
> > > core structures of Axiom algebra
> > > b)  Identify and document "core" functionality, which is to say
> > > functionality which a large part of the Axiom system depends 
> > > on.  Debug code and concepts, possibly implement unit test
> > > framework.
> > > c)  Work our way up the ladder, so to speak.  Higher level
> > > functionality documented as the underpinnings become well
> > > documented and well defined.
> > > 
> > > type of list.
> > 
> > I would replace a) with conversion of the Axiom library to
> > Aldor, but the rest seems great to me.
> 
> OK.  I take it the compiler itself doesn't contain the definitions
> of any of the algebraic types or constructs?

You mean the SPAD compiler? Yes there are some but all of the hard
work has already been done in the design of Aldor. There are some
constructs that don't translate. But (maybe) these are not important
to the goal of converting (most of) the existing Axiom library to
Aldor. (See related thread op cit.)

> ...
> Then I vote for full steam ahead with Aldor - the legal issues
> will take time, but there seems to be some confidence that they
> can eventually be sorted out.  Let's bundle the sucker and start
> some algebra tuning!
> 

I am also in favour of pushing the availability of Aldor as open
source by "jumping the gun" (to use an Olympics-style analogy :)
and releasing Aldor source now with the Axiom distribution. But
I think we have to consider this strategy carefully - particularly
the licensing issues. Unfortunately this is unavoidable. That is
why I would propose to choose a provisional open source license
for the Aldor part of the distribution that would not preclude a
more open license at a later date. Even then, there is a possibility
that this strategy might irritate some people that we really do
not want to irritate. The question is: what is the greater risk
for the Axiom project?

If we continue this discussion of licensing issues, I propose that
we move it to the axiom-legal list.

\start
Date: Mon, 13 Feb 2006 19:55:15 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: Aldor and Axiom

<legal issue responses moved to axiom-legal>

--- Bill Page wrote:

> On February 13, 2006 6:14 PM C Y wrote:
> >...
> > However, based on your comments below, I would suggest
> > the following steps might be immediately useful:
> > 
> > a)  Post the downloads for aldor on the Axiom site (I still can't
> > get through to aldor.org :-( and the site is slower now) - I think
> > this is allowed under the license no problem.
> 
> I don't know what is happening with the aldor.org server. Some days
> I can access it and other days not. Is this a good omen or a bad one?
> Is it further motivation to proceed with distributing Aldor as part
> of Axiom?

Well, at least a mirror would be good - it's a bit hard to test
Aldor+Axiom without downloading Aldor ;-).

> I think you can still get an older (v1.0.1) Windows version of Aldor
> here:
> 
> http://www.orcca.on.ca/~ldragan/aldor/Windows_versions_of_Aldor.html

Ah, Windows hadn't occured to me.  Ugh.

> Here is the version of Aldor we are running the axiom-developer.org
> server:
> 
> http://wiki.axiom-developer.org/public/aldor-linux-i386-v1.0.2.bin

Great!  Thanks!
 
> http://www.orcca.on.ca/~ldragan/aldor
> 
> refers to a new version v1.0.3rc1 (release candidate 1) of Aldor but
> the link is incorrect. The correct link is:
> 
> http://www.orcca.on.ca/~ldragan/aldor/aldor-linux-v3-1.0.3rc1.tar.gz
> 
> The dates on the files are 2004-10-30. I have not tried this version
> yet.

Hmm.  Do we know what was being fixed/updated?

> If you need help with the installation, just let me know.

I'll give the instructions a read and see how I do - I have patch47 on
my home machine now so I'll be doing a general Axiom upgrade pretty
quick - the main question is probably whether my jdk is new enough.  

> > b)  Let's incorporate aldor into the main Axiom now - if it is firm
> > we will be using Aldor (and based on my recollection everyone is in
> > agreement Aldor is the way forward over SPAD) lets not wait for the
> > legal stuff to finalize - that could take many more months.  We
> > could at least do the following:
> > 
> >   i)  Work out how the Aldor compiler and the lisp structure of
> >       Axiom should work together, and make that the default setup.
> 
> This was done long ago at IBM. Peter Broadbery has provided patches
> for the open source version of Axiom to support Aldor. Tim has
> incorporated all of these patches into the more recent version of
> the Axiom distribution except the actual build script that creates
> the libaldor library. This is available from the Axiom Wiki website:
> 
> http://wiki.axiom-developer.org/AldorForAxiom

Ah!  OK, I didn't pick up on the fact things were so far along.  Cool!

> >       I know the BOOT vs. Lisp vs. Aldor debate could go on, and
> >       may yet, but for now let's go with Tim's Lisp work and the
> >       current Aldor.org compiler.  I don't (think) those issues
> >       will depend on having the compiler source code - am I wrong?
> 
> Hmmm... well it's not open source if we don't distribute the source
> code, is it? :)

Very true.  And me being the open source fanatic too ;-).

> But we could at least distribute Axiom with a fully functioning
> build option to integrate with a previously installed binary
> version of Aldor.

That makes more sense.

> >       I think I recall it being said that the interpreter needed to
> >       be educated about Aldor, for example?
> 
> No, this works now.

Wow!  Nice.

> > Does that make sense, or is it too risky?  I think that's more or
> > less what's been going on of late anyway, but it might help to make
> > it an "official" project goal so people can be confident they
> > aren't working at cross-purposes with the main Axiom project.
> 
> I don't think it is risky but I doubt we will convince many people
> until they see downloadable Aldor source code.

True.  I wouldn't be convinced either, ordinarily.  But since it is
pretty clear nothing significant is going to happen with SPAD unless we
have no alternative, I figure we might as well make some progress on
the areas we do have current access to.

> > ... 
> > OK.  On that basis, do my earlier suggestions make sense?
> 
> I think we can complete the integration of the Aldor interface
> build into the Axiom distribution. One sticky point is that
> currently this requires the installation of the Sun Java
> development system.

Hmm.  OK.  I suppose GCJ isn't up to the job yet?

> Not everyone might want to do this just to
> install Axiom + Aldor. But I rather think we should go ahead
> with it anyway for now and just make sure that Java is only
> required if the user chooses to build the Aldor interface.

Makes sense.

> > Out of curiosity, does anybody know what the language of the
> > Aldor compiler is?
> 
> Aldor is written in "C" and Aldor.

OK.  Is it like Axiom was, needing a running Aldor to compile a new
Aldor?
 
> > IIRC it can target a couple different languages for compiler
> > output(?) but I don't recall what language it's actually
> > written in.
> 
> Aldor can generate code that runs with a stand alone run time
> environment written in "C" or it can generate Lisp. When Aldor
> is used within Axiom it generates Lisp that is compiled by GCL
> the same way that the output of the SPAD compiler is compiled.

Nice.

> > Hmm.  OK, so you suggest we first get Axiom as it stands over to
> > Aldor and then proceed with any low level design changes, if any
> > are warranted?
> 
> Yes. Initially only the Axiom library code written in SPAD would
> be converted to Aldor. The rest of Axiom would remain the same.

Makes sense.  The Linus Torvalds approach - incremental change.
 
> > ... 
> > I know Axiom is supposed to be founded on category theory and/or
> > set theory, but does anybody know where the real "core" of that
> > logic resides?
> 
> That is related to discussion in the earlier thread about the
> nature of the SubDomain construction. At least some of this
> "logic" resides in the SPAD compiler itself. That could
> potentially be a problem in the effort to convert the Axiom
> library to Aldor since Aldor does not implement this "logic"
> in the same way.

OK.

> BTW, I do not think that it would be correct to say that Axiom
> is founded on category theory as such. The use of the word
> category in Axiom is quite different. But still in many ways
> Axiom is compatible with many of the ideas of modern category
> theory.
>
> It is more correct to say that Axiom is founded on set theory
> but only is a rather loose way.

Hmm.  That could make for some challenging documentation work.
 
> > I always figured that was the most fundamental mathematical
> > part of the code, but maybe I'm wrong.
> 
> Maybe we could agree that it is a kind of exaggeration? :)

Well, darn ;-).  

> > I was kinda hoping Axiom could serve as a modern, computerized
> > Principia Mathematica++. (Interestingly, if a first edition is
> > available, might it be out of copyright?  Perhaps we could
> > incorporate the Principica Mathematica itself, or a variation,
> > as a literate document!)
> 
> Sometimes your suggestions are quite "nuts" - do you know that? ;)

But of course!  But then, my vision of Axiom always was rather
grandiose.  I think things like the QED manifesto sound like good
ideas, so I probably am a bit nuts ;-)  

> > OK.  I take it the compiler itself doesn't contain the definitions
> > of any of the algebraic types or constructs?
>
> You mean the SPAD compiler? Yes there are some but all of the hard
> work has already been done in the design of Aldor. There are some
> constructs that don't translate. But (maybe) these are not important
> to the goal of converting (most of) the existing Axiom library to
> Aldor. (See related thread op cit.)

\start
Date: Tue, 14 Feb 2006 12:03:12 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Aldor and Axiom (was Re: What is SubDomain)

> I can't help wondering if the material in the Reference section of the
> Aldor Users Guide might be enough for us to define at least a basic
> Aldor compiler in Lisp, and build on that.

I am strongly against writing a new compiler. That is too much effort. 
And the compiler also falls under the APL1.0 (as a binary). So in some 
sense it is free. And we need not worry about using it.

The biggest problem is that we cannot fix compiler bugs ourselves. For 
that aldor.org must be asked at the moment. Unfortunately, as far as I 
know, there is nobody currently working on compiler fixes. That is a 
very big minus!

\start
Date: Tue, 14 Feb 2006 14:35:20 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: The symbol 4 (was Re: Aldor and Axiom)

>> Hmm.  But aren't there some cases where you want this, like
>> (say) knowing that 4 is a real integer without having to
>> explicitly say that? (Sorry that's probably a dumb question).
> 
> The phrase "real integer" is kind of dumb ... :) What other kinds
> of integers are there? But the symbol 4 can certainly stand for
> other things besides the integer 4. 

Right. 4 is just a symbol consisting of three strokes. If one doesn't 
bring it into a context its meaning would be totally unclear. Well, 
nowadays humans tend to interpret this always as an integer, but I think 
several thousand years ago that was not so clear.

> But in the user interface,
> such as implemented by the Axiom interpreter, it is quite natural
> that unless stated otherwise, this symbol could be assumed to
> represent the element of the positive integers. On the other hand,
> in the SPAD and Aldor compilers, there should be no "guessing"
> of this kind.

Oh, why should 4 be considered to be a PI and not NNI or INT?

To avoid all this guessing, the Aldor compiler start with (nearly) zero 
knowledge. Similar to Axiom's "expose" one has to teach Aldor.

Look at the following

woodpecker:~/scratch/FRAC>aldor -gloop
      AA  L      DDDD      OOO    RRRR
     A A  L      D   D    O   O   R   R
    A  A  L      D    D  O     O  R   R
   AAAAA  L      D    D  O     O  RRRR
  A    A  L      D   D    O   O   R  R
A     A  LLLLL  DDDD      OOO    R   R

(c) Numerical Algorithms Group Ltd 1995-2001
Release: Aldor(C) version 1.0.3 for LINUX(glibc2.3) (debug version)
Type "#int help" for more details.
%1 >> #include "aldor"
                                            Comp: 190 msec, Interp: 40 msec
%2 >> #include "aldorinterp"
                                            Comp: 90 msec, Interp: 0 msec
%3 >> 4
       ^
[L3 C1] #1 (Error) No meaning for integer-style literal `4'.

%4 >> import from Integer
                                            Comp: 30 msec, Interp: 0 msec
%5 >> 4
4 @ AldorInteger
                                            Comp: 0 msec, Interp: 280 msec
%6 >> import from MachineInteger
                                            Comp: 30 msec, Interp: 0 msec
%7 >> 4
       ^
[L7 C1] #1 (Error) Have determined 2 possible types for the expression.
         Meaning 1: MachineInteger
         Meaning 2: AldorInteger

You see, 4 is not known to Aldor, initially.

After importing from Integer, the Aldor FOAM interpreter knows every 
export of Integer (yes Integer is a macro that expands to AldorInteger).
Before FOAM code can be executed, it has to be compiled from Aldor 
source to FOAM (First Order Abstract Machine), so the compiler is 
involved here and there are not two languages as in Axiom.

After line %6, Aldor also sees the exports from MachineInteger (32-bit 
integers). Line %7 clearly tells you that the symbol 4 is ambiguous.

So what can you do?

Either you say
%8 >> 4@Integer
4 @ AldorInteger

or

%9 >> x: MachineInteger := 4
4 @ MachineInteger

You see, the compiler forces you to be clear. That can be nasty when you 
start with Aldor, but you will love it once you are used to it. It 
prevents stupid type errors and that is what all these types are made for.

OK, how does that work?
There is a bit of syntactic sugar involved here. In fact, if the aldor 
compiler sees something that looks like an integer, it tries to find a 
function
   integer: Literal -> %
that is currently in scope and executes it with the Literal that it 
finds. Well, clearly, if it finds tow such functions, for example,
   integer: Literal -> Integer
   integer: Literal -> MachineInteger
it does not know which one to apply if the result type cannot be 
inferred from the context (as in lines %8 and %9 above).

And to make you happy, one can easily write his own domain that behaves 
quite differently from what you would expect when you read the source 
code not carefully enough.

---file crazy.as--
#include "aldor"
CrazyInteger: IntegerType with {string: Literal -> %} == Integer add {
	Rep == Integer;
	import from Rep;
	integer(l: Literal): % == per(integer(l)$Integer + 1);
	string(l: Literal): % == per 42;
}

main(): () == {
	import from TextWriter, Character;
	import from CrazyInteger;
	stdout << "This is crazy :" << space << 1 << newline;
	stdout << "This is crazy :" << space << 2 << newline;
	stdout << "Fourtytwo" + 4 << newline;
}

main();
---end crazy.as

For me it says.
 >aldor -grun -laldor crazy.as
42 1
42 3
47

I hope you expected that. ;-)

Explanation:
Like for integers there are functions
string: Literal -> % and float: Literal -> % which are used for 
string-like ("I am a string") and float-like (1.24e3) literals.

The first line of output is correct, since the compiler sees the integer 
style literal 1 and finds that "1: %" is an export of the category so 
that is clear. Since 1 is not implemented in % directly, it is inherited 
from "Integer" (the thing that comes before the "add").

For the second line the function string: Literal -> CrazyInteger is 
invoked for "This is crazy :" and integer: Literal -> CrazyInteger for 
the symbol 2 resulting in the output shown above.

You may notice that different from other programming languages, Aldor 
does not simplify seemingly constant expressions like 1+2 to 3 since
either that is wrong (given the idea of Literals) or there is some 
danger of an infinite computation at compile time. Evaluating 1+2 means 
calling the function +. Now imagine I would have implemented it in that way:
(x:%)+(y:%):% == {while true repeat {}; x;}

So it means that the convertion from Literals to actual elements of the 
corresponding type happens at runtime.

\start
Date: Tue, 14 Feb 2006 13:35:20 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Aldor and Axiom (was Re: What is SubDomain)

>> If I'm understanding correctly, most of what we would like to
>> use from Aldor actually is available in source code form, with
>> the BSD+extra rights for Aldor.org license?

I am not so sure about, the libalgebra sources. Though I have access to 
them, I have never seen them distributed from aldor.org. Does anyone 
have differen experience here?

The sources of libaldor are open. They are distributed in source in the 
1.0.2 release.

>> And the most critical, libaldor and libalgebra, are Manual
>> Bronstein's work and might be releasable under plain Modified BSD
>> without having to unravel the Aldor.org knot?

I guess, that is mostly true for libaldor, but I also added/corrected 
some tiny pieces of code.

A bit of history here... (please correct if you find errors here)
Aldor started with just the library libaxllib (when Aldor was still 
called AxiomXL). Then in the EU-project FRISCO a library basicmath has 
been developed (mostly by NAG, I guess).

Manuel Bronstein was not happy with axllib and started his own library 
salli (Standard Aldor Library).

At some point everything was put together. Salli basically became 
libaldor and many things from basicmath have been rewritten to work with 
libaldor.

Axllib is still in the CVS tree of Aldor, but I wonder who is still 
using it. Maybe Marc Moreno Maza, because I heard rumours that basicmath 
is still in existence an builds on axllib. (I have never really seen 
basicmath, though.)

So libalgebra is probabley mostly the work of Marc Moreno Maza and others.

Anyway, libaldor and libalgebra fall under the APL and there is no other 
license around.

> Axiom vs. Aldor libraries is only half the problem and the Aldor
> libraries are currently maybe only about 10% of the solution.

But that 10% would be a good and quick start in my opinion.

> The other half of the problem is the Axiom interpreter which
> encodes a great deal of knowledge about the Axiom library itself.
> Right now they are tightly couple and one could not throw away
> the Axiom library without also throwing away the interpreter.

Right. I would really like to see the interpreter decoupled from the 
library code. The interpreter should just interpret the code, i.e. 
manage information and not add information. Every little detail must be 
deducible from the library code (even by a humam (with some spare 
time)). Structuring things into digestible pieces is always a good idea.

It would be much better to design a clear interface between the library 
and the interpreter. That would probably mean add a "reflection" 
interface similar to reflections in JAVA. That interface would live very 
low in the domain hierarchy and might not even be of any use to the 
ordinary Aldor programmer, but it would be vital for an Aldor interpreter.

>>> What I really don't like is that in Axiom sometimes information
>>> is added by the compiler/interpreter which does not exist in the
>>> .spad file itself.
> 
> The Axiom interpret does this by design.

Well, of course, there is a little guess work done with the interpreter. 
But perhaps it would be cleaner to really work out how to implement 
BNatural.

>>> Type information that is guessed by the compiler is just an
>>> example.

> Could you give an example where type information is "guessed" by
> the SPAD compiler?

OK, I have to try a bit... But in the meantime you can look at this bug.

--- file mytype.spad
)abb domain MT MyType
MyType: Cat == Impl where
  Cat ==> with
   coerce: PositiveInteger -> %
   coerce: % -> Integer
  Impl ==> add
   Rep:=PositiveInteger
   coerce(n) == n
--- end file mytype.spad

(1) -> )co mytype.spad
(1) -> m:MT := 1
    Loading /home/hemmecke/scratch/FRAC/MT.NRLIB/code for domain MyType
    Loading /home/hemmecke/software/Axiom/mnt/linux/algebra/PI.o for
       domain PositiveInteger

  LISP output:
1
                                                                  Type: 
MyType
(2) -> i:INT := m
    Internal Error
    The function coerce with signature hashcode is missing from domain
       MyType

How can this be missing? ;-) That is what I meant by the line after the 
Rep. I actually meant both things by that line
   coerce(n) == n
and obviously the compiler understood what I had in mind otherwise it 
would have complained. But unfortunately, the resulting code is not 
correct in the sense I wanted it.

So, whether you see this as a bug of the spad compiler (which it clearly 
is, because it should have told me that my implementation does not 
satisfy the category) or whether this is an instance of the spad 
compiler adding type information does not matter. SPAD allows to write 
ambiguous code and that should clearly be forbidden.

If Axiom wants to be a system that is strongly typed, then there is no 
way out: eventually SPAD has to be left behind.

My suggestion would be even to switch off the SPAD compiler after the 
Axiom library has been built. An ordinary Axiom user should never be 
given the chance to compile SPAD code. He/she should immediately learn 
and use Aldor exclusively. With such a decision the Axiom Team clearly 
says where its future lies.
(I hope I don't get beaten by that suggestion.)

\start
Date: Tue, 14 Feb 2006 13:13:48 +0100
From: Ralf Hemmecke
To: list
Subject: Documentation bug?

Can someone explain that ...

(2) -> )abbr domain XYZ
    domain must be followed by an alternating list of abbreviation(s)
       and name(s). Issue )abbrev? for more information.
(2) -> )abbrev?
    Your argument list is not valid.

Very helpful! ;-)

\start
Date: 14 Feb 2006 15:09:09 +0100
From: Martin Rubey
To: Cliff Yapp
Subject: re: Aldor and Axiom

Cliff Yapp writes:

> > > Hmm.  But aren't there some cases where you want this, like
> > > (say) knowing that 4 is a real integer without having to
> > > explicitly say that? (Sorry that's probably a dumb question).
> > 
> > The phrase "real integer" is kind of dumb ... :) What other kinds
> > of integers are there?
> 
> Heh.  None that I know of, but that's not saying much.  

Gaussian Integers?

\start
Date: Tue, 14 Feb 2006 14:59:15 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Aldor and Axiom

>> How do we resolve things like Aldor's libalgebra vs. Axiom's
>> libraries?

> I would propose that we forget about Aldor's native libraries for
> now (as nice, though limited, as they are).

If I knew where to hook libaldor into Axiom, I would already have done 
so. But libaldor basically starts from zero and for Axiom the whole 
construction of the domains and categories is still mystical to me.

In any case if SPAD should be translated to Aldor one has to start with 
some domain or category. There should be a clear cut. Something that the 
compiler knows and something that is added through libraries. If that 
interface is clear than we can talk again about whether we use the Aldor 
libraries or not.

>> Are we planning to completely document and update the SPAD compiler?

> I would choose "no", although if time or experienced people became
> available this might be interesting for historical reasons.

I would also choose "no".

It seems that we will somehow start in the middle. Introduce a cutpoint 
and work up the ladder to build the Algebra. And maybe work down in 
order to also write the basic code in Aldor until the bootstrapping 
problem is shifted to bootstrapping the aldor compiler.


>> a)  Document SPAD compiler, foundations in mathematical theory,
>> core structures of Axiom algebra
>> b)  Identify and document "core" functionality, which is to say
>> functionality which a large part of the Axiom system depends 
>> on.  Debug code and concepts, possibly implement unit test
>> framework.
>> c)  Work our way up the ladder, so to speak.  Higher level
>> functionality documented as the underpinnings become well
>> documented and well defined.
> 
> I would replace a) with conversion of the Axiom library to
> Aldor, but the rest seems great to me.

Yes, Cliff, that's it. Axiom needs a kind of future plan. And 
translating SPAD to Aldor is a clear task in my eyes. That will probably 
take several years anyway, since documentation should be added at the 
same time.

\start
Date: Tue, 14 Feb 2006 15:06:42 +0100
From: Ralf Hemmecke
To: list
Subject: Re: Aldor and Axiom
Cc: Laurentiu Dragan, Stephen Watt

Hello Laurentiu, hi Stephen,

www.aldor.org is down again also cvs access does not work.

Ralf

On 02/14/2006 12:13 AM, C Y wrote:
> --- Bill Page wrote:
>>> But from my perspective (which may or may not be accurate) we are 
>>> being hindered by the uncertainty surrounding SPAD vs. Aldor.
>> I that the Axiom is being hindered by the fact the Aldor is not yet
>> available as open source.
> 
> Certainly true.  However, based on your comments below, I would suggest
> the following steps might be immediately useful:
> 
> a)  Post the downloads for aldor on the Axiom site (I still can't get
> through to aldor.org :-( and the site is slower now) - I think this is
> allowed under the license no problem.
>
> b)  Let's incorporate aldor into the main Axiom now - if it is firm we
> will be using Aldor (and based on my recollection everyone is in
> agreement Aldor is the way forward over SPAD) lets not wait for the
> legal stuff to finalize - that could take many more months. 

\start
Date: Tue, 14 Feb 2006 06:22:25 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke,
Subject: Re: Aldor and Axiom

--- Ralf Hemmecke wrote:

> >> How do we resolve things like Aldor's libalgebra vs. Axiom's
> >> libraries?
> 
> > I would propose that we forget about Aldor's native libraries for
> > now (as nice, though limited, as they are).
> 
> If I knew where to hook libaldor into Axiom, I would already have
> done  so. But libaldor basically starts from zero and for Axiom the
> whole construction of the domains and categories is still mystical
> to me.

Me too, particularly if Axiom's use of cagetories is different from
mathematical category and set theory - so much for the starting point I
had been intending to use ;-).  Darn it, that would have made it so
nice - I could have read up on the research on set and category theory,
and (tried to) make a literate document containing both the human level
algebra foundations and the computer level algebra foundations.

Perhaps "understand Axiom's domain and category construction" should be
item #1 (or maybe 0) on our "conversion to Aldor" roadmap.  Any attempt
that doesn't involve a firm understanding of that is probably going to
result in Massive Confusion, at best.

> In any case if SPAD should be translated to Aldor one has to start
> with some domain or category. There should be a clear cut. Something
> that the compiler knows and something that is added through 
> libraries. If that interface is clear than we can talk again about
> whether we use the Aldor libraries or not.

Agreed.

> >> Are we planning to completely document and update the SPAD
> compiler?
> 
> > I would choose "no", although if time or experienced people became
> > available this might be interesting for historical reasons.
> 
> I would also choose "no".

OK.  If we're going with Aldor for sure that of course becomes much
less interesting.

> It seems that we will somehow start in the middle. Introduce a
> cutpoint and work up the ladder to build the Algebra. And maybe work
> down in order to also write the basic code in Aldor until the
> bootstrapping problem is shifted to bootstrapping the aldor compiler.

Makes sense to me.  I thought the logical cutpoint would be where the
"core" algebra logical framework was defined, but it sounds like that
might be sort of mixed up between knowledge in the SPAD compiler and
the algebra files?  If I've understood that correctly I would say
that's the problem we need to attack first.

> >> a)  Document SPAD compiler, foundations in mathematical theory,
> >> core structures of Axiom algebra
> >> b)  Identify and document "core" functionality, which is to say
> >> functionality which a large part of the Axiom system depends 
> >> on.  Debug code and concepts, possibly implement unit test
> >> framework.
> >> c)  Work our way up the ladder, so to speak.  Higher level
> >> functionality documented as the underpinnings become well
> >> documented and well defined.
> > 
> > I would replace a) with conversion of the Axiom library to
> > Aldor, but the rest seems great to me.
> 
> Yes, Cliff, that's it. Axiom needs a kind of future plan. And 
> translating SPAD to Aldor is a clear task in my eyes. That will
> probably take several years anyway, since documentation should be
> added at the same time.

Agreed.  Am I correct that the logical starting point is to identify
where the compiler ends and the math begins (whether it is set/category
theory or Axiom's domain and cagetory implementation or whatever) and
get the core parts documented and working on top of Aldor?

\start
Date: Tue, 14 Feb 2006 15:46:41 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: Re: Aldor and Axiom

Hi Cliff,

> Agreed.  Am I correct that the logical starting point is to identify
> where the compiler ends and the math begins (whether it is set/category
> theory or Axiom's domain and cagetory implementation or whatever) and
> get the core parts documented and working on top of Aldor?

Yes, I think that is a starting point, but it is not that simple.
The logical reason why there are two libraries in Aldor (libaldor and 
libalgebra) is that the first one just provides basic functionality. 
libaldor is a kind of low-level library.

Manuel Bronstein once explained to me that libaldor is just a 
non-mathematical library. Every mathematics comes in libalgebra.
In libaldor's design, speed was one issue. For example, Array indexing 
starts at zero and thus maps without overhead to C-arrays. That causes a 
little confusion at first, but if one works with Matrix from libalgebra, 
the minimal index is 1.

There is not need to use Array except to use it as a datastructure to 
store objects. If one needs a mathematical object than one should say 
so, for example choose Vector (which has minimal index 1).

I'd happy to translate libaldor into pamphlets. (Of course, help is 
appreciated.)

\start
Date: Tue, 14 Feb 2006 07:28:41 -0800
From: Scott Morrison
To: lsit
Subject: Re: What is SubDomain (was: non extending category)

>> SCM: Do you happen to remember what you wrote 20 years ago? :)

Well, not really.

I do remember that I never liked SubDomain.  We had all kinds of
special-case code to deal with it, and it was only used for
NonNegativeInteger and PositiveInteger.  I believe the original motivation
for sub-domains was to share implementations, but not categories.  So
PositiveInteger could share the all the implementation code from Integer,
but not the categories of Integer, since they don't form a Group under
addition, for example.  In the end it caused a lot more mork than it saved.

The concept of sub-domain never made it into Aldor, as far as I know, and
that's a good thing.

\start
Date: Tue, 14 Feb 2006 08:30:14 -0800 (PST)
From: Cliff Yapp
To: Ralf Hemmecke
Subject: Re: Aldor and Axiom

--- Ralf Hemmecke wrote:

> Hi Cliff,
> 
> > Agreed.  Am I correct that the logical starting point is to
> > identify where the compiler ends and the math begins (whether
> > it is set/category theory or Axiom's domain and cagetory
> > implementation or whatever) and get the core parts documented
> > and working on top of Aldor?
> 
> Yes, I think that is a starting point, but it is not that simple.

Figures.

> The logical reason why there are two libraries in Aldor (libaldor
> and libalgebra) is that the first one just provides basic 
> functionality.  libaldor is a kind of low-level library.

So we actually want to retarget Axiom to Aldor+libaldor, rather than
just the Aldor compiler itself?

> Manuel Bronstein once explained to me that libaldor is just a 
> non-mathematical library. Every mathematics comes in libalgebra.

OK.  So Aldor+libaldor should contain all the non-mathematical tools we
will need to begin defining mathematical structure?

> In libaldor's design, speed was one issue. For example, Array
> indexing starts at zero and thus maps without overhead to C-arrays.
> That causes a little confusion at first, but if one works with
> Matrix from libalgebra, the minimal index is 1.

Hmm.  OK.  If we document the conventions I doubt that will be a major
problem.

> There is not need to use Array except to use it as a datastructure
> to store objects. If one needs a mathematical object than one should
> say so, for example choose Vector (which has minimal index 1).

Right.  So you would only use Array when defining something like
Vector.  I would recommend that the convention be established that
nothing in libaldor be directly accessible by any math code, just as
Vector is created instead of using Array.  Even if by chance the math
behavior should be identical to a behavior in libaldor, we should
maintain the coding convention of separation.

> I'd happy to translate libaldor into pamphlets. (Of course, help is 
> appreciated.)

Sounds good.  How much of what kind of skills are needed to usefully
translate/document various parts of libaldor?

Cheers,
CY

P.S.  So is this a reasonable first approximation of a todo list? 
(Feel free to change, reorder, alter, or mock it - I just want to try
and get some kind of sequential tasklist set up)

1)  Covert libaldor to pamphlets, understand functionality provided by
libaldor and compiler.
2)  Identify core mathematical logic in Axiom, whether in the SPAD
system or elsewhere, and structure it to build off of the
non-mathematical compiler+libaldor tools.  If libaldor does not provide
sufficient functionality, expand it as needed to maintain the clean
separation of mathematical and non-mathematical code.  If necessary,
create higher level non-mathematical libraries but maintain the clear
distinction.  The goal is to have a clean, well defined and literate
environment in which to begin defining mathematical abilities.
3)  Create a list of mathematical abilities in Axiom to move to move to
the new core framework built on libaldor, starting with the most
"fundamental" abilities and building to higher level ones.  Move them
over piece by piece, converting the SPAD code to Aldor code and making
"real" literate documents (e.g. code and text) out of each one before
moving on to the next.
4)  At some point in 3, when enough abilities have been ported and
defined, consider B-natural and the best way to handle createing a
"friendly" interaction layer on top of the rigorously specified code.

Does that seem to make sense, at least as a short answer to the various
"what comes next" questions?

\start
Date: Tue, 14 Feb 2006 13:14:27 -0500
From: Tim Daly
To: list
Subject: [Scott Kirkwood: Re: [Frink] Interval Arithmetic in Practice]

I've long believed (and even did thesis work) that interval arithmetic
is the best way to implement provisos. For purely arithmetic results
it can generate interesting results. For symbolic results the answers
are even more interesting.


Frink played with interval arithmetic and got some interesting results:


------- Start of forwarded message -------
To: frink@yahoogroups.com
From: Scott Kirkwood
Date: Tue, 14 Feb 2006 14:11:04 -0300
Subject: Re: [Frink] Interval Arithmetic in Practice


Alan,
Thought you might be interested in this link about Interval Arithmetic
 http://research.sun.com/minds/2004-0527/

Scott

On 9/6/05, Alan Eliasen wrote:
>
>
>    I've finally finished implementing the two-argument version of
> arctan[x,y] in Frink to work with interval arithmetic.  This is an
> interesting, subtle, and quite complex function when applied to intervals.
>
>    To inaugurate this function, I decided to test it against real-world
> problems--in this case, a geocaching problem.  If you're not familiar
> with geocaching, it's a growing hobby in which you find hidden sites
> using a GPS receiver.  See http://www.geocaching.com/ .
>
>    I've been trying to solve geocaching puzzles purely geometricallly
> using Frink and spherical geometry.  In this case, I attacked the "Ball
> Bearing" cache:
>
>    http://tinyurl.com/b2thv
>
>    This puzzle asks you to triangulate from two points over a distance
> of several miles to find the solution.  However, the bearings were only
> given to the closest decimal degree, and I wanted to see how much
> uncertainty this gave in the answer.  I had already written a Frink
> program to do the calculations:
>
> http://futureboy.us/fsp/colorize.fsp?fileName=BallBearing.frink
>
> which uses my extensive sun/moon/navigation library:
>
> http://futureboy.us/fsp/colorize.fsp?fileName=sun.frink
>
>    Note that not a single calculation was ever written with intervals in
> mind.  The equations were spherical geometry equations, taken directly
> from texts, containing nests of trigonometric functions.  (It gets even
> worse when you take into account the fact that the earth is an oblate
> spheroid.)  Performing traditional error analysis on these equations
> would be quite painful.
>
>    However, using the magnificient tools of interval arithmetic, it's
> trivial.  In my Frink program, all I did was change lines like:
>
> b7 = 334 degrees
>   to
> b7 = new interval[333.5, 334, 334.5] degrees
>
>    to reflect the fact that the bearing was only known to the closest
> degree.  Run the program again, and Frink automagically tracks these
> error bounds through *all* of those calculations, and produces a
> worst-case figure for the uncertainty in the target!  It literally
> couldn't be easier.
>
>    I could readily see, given the uncertainties, that the target could
> lie in a square (or ellipse) about 0.14 miles on a side.
>
>    It's this sort of amazing, effortless power that interval arithmetic
> gives you that makes it so compelling.  Using Frink's near-transparent
> interval arithmetic makes it easy to apply this sort of analysis to
> nests of formerly intractable equations.  Try it.
>
>    Some geocaching tools powered by Frink:
> http://futureboy.us/fsp/geocaching.fsp

\start
Date: Tue, 14 Feb 2006 15:05:59 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Documentation bug?

)abbrev domain MYINT MyInteger

                     ^^^^^^ domain name
               ^^^^ abbreviation

see any pamphlet file in src/algebra

\start
Date: Tue, 14 Feb 2006 14:27:11 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Documentation bug?

On Tuesday, February 14, 2006 7:14 AM Ralf Hemmecke wrote:
>
> Can someone explain that ...
>
> (2) -> )abbr domain XYZ
>     domain must be followed by an alternating list of abbreviation(s)
>        and name(s). Issue )abbrev? for more information.
> (2) -> )abbrev?
>     Your argument list is not valid.
>
> Very helpful! ;-)
>

If you look in the Axiom source you will see, for example:

  )abbrev domain PRIMARR PrimitiveArray

  )abbrev package REALSOLV RealSolvePackage

  )abbrev category AGG Aggregate

This assigns the abbreviation PRIMARR to the domain named
PrimitiveArray, etc.

I suppose the error message implies that as a shortcut you can
assign more than one abbreviation in the same command, e.g.

  )abbrev domain NIPROB NumericalIntegrationProblem PRIMARR
PrimitiveArray

although I do not know of any case in the Axiom source where
this extended syntax is actually used.

Sometimes in SPAD source files you see several )abbrev commands
clustered near the beginning of the source and then the actual
source code for each module coming later in the file. As a style
I consider this rather poor practice and I prefer to see the
)abbrev command as the first source statement just preceeding
the source of the module. I think this convention is useful
because the SPAD syntax has no distinquishing keyword such as
'define' prior to the module name, e.g.

)abbrev domain DLIST DataList
++ This domain provides some nice functions on lists
DataList(S:OrderedSet) : Exports == Implementation where
  Exports == ListAggregate(S) with

\start
Date: Tue, 14 Feb 2006 15:24:42 -0500
From: Tim Daly
To: Cliff Yapp
Subject: re: Aldor and Axiom

> Agreed.  Am I correct that the logical starting point is to identify
> where the compiler ends and the math begins (whether it is set/category
> theory or Axiom's domain and cagetory implementation or whatever) and
> get the core parts documented and working on top of Aldor?

The logical starting point might be to try to encode your units work
in Axiom using Aldor. Since you don't depend on anything there cannot
be an issue. And it will provide a learning experience for us all since
you'll be the first person to combine Axiom, Literate Programming, and
Aldor. If you document the steps properly it can become a whole chapter
in the Axiom developer book (vol 4). For reference look at the documentation
I wrote for developing polynomials using the Aldor compiler.

\start
Date: Tue, 14 Feb 2006 12:38:24 -0800 (PST)
From: Cliff Yapp
To: Tim Daly
Subject: re: Aldor and Axiom

--- Tim Daly wrote:

> > Agreed.  Am I correct that the logical starting point is to
> > identify where the compiler ends and the math begins (whether it
> > is set/category theory or Axiom's domain and cagetory 
> > implementation or whatever) and get the core parts documented
> > and working on top of Aldor?
> 
> The logical starting point might be to try to encode your units work
> in Axiom using Aldor. Since you don't depend on anything there cannot
> be an issue.

Hmm.  I hadn't thought of that but you're right, at least for the basic
stuff.  Well, it's been a few months so I guess I'm ready for a look at
it with fresh eyes.

> And it will provide a learning experience for us all since
> you'll be the first person to combine Axiom, Literate Programming,
> and Aldor. If you document the steps properly it can become a whole
> chapter in the Axiom developer book (vol 4). For reference look at
> the documentation I wrote for developing polynomials using the Aldor
> compiler.

OK.  Here's a link for the lazy (me in a few hours ;-) : 
http://www.aldor.org/docs/HTML/chap21.html  

\start
Date: Tue, 14 Feb 2006 07:05:23 -0500
From: Gianluca Gregori
To: list
Subject: axiom did not compile on sparc solaris

Hello,

I am trying to compile axiom on a sparc solaris machine but
having lots of trouble (not to experienced as well).
I was able to compile gcl-2.6.7 with the --enable-custreloc
option (bfd did not compile). However, still axiom does not
compile properly.
Any help is appreciated. --Thanks, Gianluca



The error that I get follows here:

[...]
5 invoking make in /export/home/gregori1/Xcodes/axiom/src/interp
with parms:
SYS= solaris9
LSP= /export/home/gregori1/Xcodes/axiom/lsp
PART= cprogs
SPAD= /export/home/gregori1/Xcodes/axiom/mnt/solaris9
SRC= /export/home/gregori1/Xcodes/axiom/src
INT= /export/home/gregori1/Xcodes/axiom/int
MID= /export/home/gregori1/Xcodes/axiom/int/interp
OUT= /export/home/gregori1/Xcodes/axiom/obj/solaris9/interp
OBJ= /export/home/gregori1/Xcodes/axiom/obj
MNT= /export/home/gregori1/Xcodes/axiom/mnt
O=o LISP=lsp BYE=bye

>
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/makeint.lisp
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/sys-pkg.lsp
Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/sys-pkg.lsp
Loading
/export/home/gregori1/Xcodes/axiom/src/interp/interp-proclaims.lisp
Finished loading
/export/home/gregori1/Xcodes/axiom/src/interp/interp-proclaims.lisp
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nocompil.lsp
Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nocompil.lsp
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/util.o
start address -T 562000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/util.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/vmlisp.o
start address -T 540000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/vmlisp.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/hash.o
start address -T 56f670 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/hash.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/bootfuns.lsp
Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/bootfuns.lsp
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/macros.o
start address -T 5527c0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/macros.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/unlisp.o
start address -T 591bf0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/unlisp.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/setq.lsp
Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/setq.lsp
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/astr.o
start address -T 5a7998 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/astr.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/bits.o
start address -T 560db8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/bits.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/alql.o
start address -T 3102e0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/alql.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/buildom.o
start address -T 59b980 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/buildom.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cattable.o
start address -T 59fcc0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cattable.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cformat.o
start address -T 5520d8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cformat.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cfuns.o
symbol "directoryp" is not in base imagesymbol "writeablep" is
not in base imagesymbol "findString" is not in base
image[unknown global sym MYHASH][unknown global sym
MYCOMBINE]start address -T 561738 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cfuns.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/clam.o
start address -T 57c000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/clam.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/clammed.o
start address -T 5823b0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/clammed.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/comp.o
start address -T 58d868 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/comp.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/compat.o
start address -T 591098 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/compat.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/compress.o
start address -T 5a5d18 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/compress.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cparse.o
start address -T 622000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cparse.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cstream.o
start address -T 5a66d0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/cstream.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/database.o
start address -T 5857e0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/database.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/debug.o
start address -T 63c000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/debug.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/dq.o
start address -T 551e18 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/dq.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/fname.o
start address -T 631328 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/fname.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/format.o
start address -T 649c98 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/format.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-boot.o
start address -T 654498 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-boot.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-cndata.o
start address -T 61aba0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-cndata.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-error.o
start address -T 61e3b8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-error.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-opt.o
start address -T 67dcc0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-opt.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-timer.o
start address -T 62c278 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-timer.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-util.o
start address -T 676ce8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/g-util.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/ggreater.o
start address -T 61d2c0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/ggreater.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/hypertex.o
start address -T 550c10 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/hypertex.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-analy.o
start address -T 66cff0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-analy.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-code.o
start address -T 6829d0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-code.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-coerce.o
start address -T 6b6000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-coerce.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-coerfn.o
start address -T 6ca000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-coerfn.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-eval.o
start address -T 6dc3f8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-eval.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-funsel.o
start address -T 720000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-funsel.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-hist.o
start address -T 6a0000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-hist.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-intern.o
start address -T 6e14d8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-intern.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-map.o
start address -T 702620 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-map.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-output.o
start address -T 73e000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-output.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-resolv.o
start address -T 760000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-resolv.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-spec1.o
start address -T 6ec000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-spec1.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-spec2.o
start address -T 784970 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-spec2.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-syscmd.o
start address -T 790a78 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-syscmd.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-toplev.o
start address -T 6fe270 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-toplev.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-util.o
start address -T 6c46e8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/i-util.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/incl.o
start address -T 767790 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/incl.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/int-top.o
start address -T 76e548 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/int-top.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/intfile.o
start address -T 683cd8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/intfile.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/lisplib.o
start address -T 772910 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/lisplib.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/macex.o
start address -T 6f92f0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/macex.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/match.o
start address -T 6fb6c8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/match.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/monitor.o
start address -T 7c8000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/monitor.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/msg.o
start address -T 7cdde0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/msg.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/msgdb.o
start address -T 7dd2a8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/msgdb.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nci.o
start address -T 658da0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nci.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/newaux.o
start address -T 7a5770 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/newaux.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/newfort.o
start address -T 7ec370 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/newfort.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nlib.o
start address -T 7d4200 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nlib.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nrunfast.o
start address -T 85d568 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nrunfast.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nrungo.o
start address -T 7f68b0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nrungo.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nrunopt.o
start address -T 84c000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nrunopt.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nruntime.o
start address -T 67d380 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/nruntime.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/osyscmd.o
start address -T 864a08 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/osyscmd.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/packtran.o
start address -T 62e518 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/packtran.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/pathname.o
start address -T 70f438 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/pathname.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/pf2sex.o
start address -T 82e740 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/pf2sex.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/pile.o
start address -T 7d3160 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/pile.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/posit.o
start address -T 8388c8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/posit.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/property.lsp
Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/property.lsp
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/ptrees.o
start address -T 820000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/ptrees.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/ptrop.o
start address -T 618000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/ptrop.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/record.o
start address -T 7d9b20 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/record.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/rulesets.o
start address -T 75b9a0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/rulesets.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/scan.o
start address -T 826030 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/scan.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/serror.o
start address -T 85be00 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/serror.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/server.o
start address -T 6695a8 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/server.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/setvars.o
start address -T 8bc000 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/setvars.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/sfsfun-l.o
start address -T 649268 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/sfsfun-l.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/sfsfun.o
start address -T 884770 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/sfsfun.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/simpbool.o
start address -T 62ea28 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/simpbool.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/slam.o
start address -T 82aea0 Finished loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/slam.o
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/sockio.o
symbol "open_server" is not in base imagesymbol "sock_get_int"
is not in base imagesymbol "sock_send_int" is not in base
imagesymbol "sock_get_string_buf" is not in base imagesymbol
"sock_send_string_len" is not in base imagesymbol
"sock_get_float" is not in base imagesymbol "sock_send_float" is
not in base imagesymbol "sock_send_wakeup" is not in base
imagesymbol "server_switch" is not in base imagesymbol
"flush_stdout" is not in base imagesymbol "sock_send_signal" is
not in base imagesymbol "print_line" is not in base imagesymbol
"plus_infinity" is not in base imagesymbol "minus_infinity" is
not in base imagesymbol "NANQ" is not in base image
Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by SETQ.
Broken at NANQ.  Type :H for Help.
BOOT>>gmake[3]: ***
[/export/home/gregori1/Xcodes/axiom/obj/solaris9/bin/interpsys]
Error 255
gmake[3]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/src/interp'
gmake[2]: *** [interpdir] Error 2
gmake[2]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/src'
gmake[1]: *** [srcdir] Error 2
gmake[1]: Leaving directory `/export/home/gregori1/Xcodes/axiom'
gmake: *** [all] Error 2

\start
Date: Tue, 14 Feb 2006 17:40:31 -0500
From: Tim Daly
To: Gianluca Gregori
Subject: Re: Axiom-developer post from Gianluca Gregori	requires approval

The missing symbols, like "open_server" and "sock_get_int"
are in C code that is part of the axiom distribution. "sock_get_int"
lives in src/lib/sockio-c.c.pamphlet

If you look at src/lib/Makefile you'll see that the goal is to create
the library libspad.a

This library is linked with the GCL image. The linking occurs because
patches are applied when GCL is built. Look at lsp/Makefile and search
for libspad.a

Apparently GCL was not built properly during the axiom build.
The first thing to try is to do:

  rm -rf int obj mnt noweb lsp/gcl* 

or refetch the source tree and try the build again.

Your console trace starts after the error would have occurred
since the GCL build/link happens first.

Tim

\start
Date: Tue, 14 Feb 2006 21:19:12 -0500
From: Raymond Rogers
To: list
Subject: groebsol.spad compile etc...

Martin
	Thank you for your responses.  I am simply nosing around seeing if I
can understand and solve the problem that I stated earlier in:
SandBox Shortcoming
(Which is totally a wrong title.)
	I have no idea whether whether the problem would be solved in time.  I
did let it run for some period of time: 10's of minutes.  I was just
trying to look inside the solver to see what was going on.  With your
suggestions I have greater hope of progressing.  I don't have good
control yet, since I get strange answers from time to time.  Ignorance
of Axiom together with only a superficial knowledge of Algebraic
Geometry makes the going slow.
	Although the Axiom failure has motivated my company to get me Maple for
the problem, I would like to help free software along.  I personally
think that the availability of good free software is the only way for
deprived people to gain equity in some future civilization.

\start
Date: Tue, 14 Feb 2006 21:52:33 -0500
From: Bill Page
To: Gianluca Gregori
Subject: RE: axiom did not compile on sparc solaris

On Tuesday, February 14, 2006 7:05 AM Gianluca Gregori wrote:
>
> I am trying to compile axiom on a sparc solaris machine but
> having lots of trouble (not to experienced as well).
> I was able to compile gcl-2.6.7 with the --enable-custreloc
> option (bfd did not compile). However, still axiom does not
> compile properly.
> Any help is appreciated. --Thanks, Gianluca
>

What release of Axiom are you trying to build and on
what version of solaris? Why did you choose to use
--enable-custreloc?

I am also trying to build Axiom from the September 2005 tarball:

http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Sept2005-
src.tgz

on Solaris 8 sparc (280R dual cpu) system. If I simply follow
the instructions of:

  ./configure

You must set your AXIOM and PATH variables. Type:

To build the rest of the system type:

export AXIOM=/export/disk0/dmprod/axiom/mnt/solaris9
export PATH=$AXIOM/bin:$PATH
make AWK=gawk TAR=gtar PATCH=gpatch

---------

The Axiom ./configure uses 'solaris9' even though my system
is actually Solaris 8. I don't think this a problem.

Although I have installed the complete GNU toolset, I did not
have any 'gtar' on my Solaris system. So in created a symbolic
link in /usr/bin to /usr/local/bin/tar.

In 'Makefile.solaris' it is clear that Axiom builds GCL with
the option --enable-locbfd.

But the build of GCL stops with the error:

...
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3 =
-fomit-frame-pointer
-I/export/disk0/dmprod/axiom/lsp/gcl-2.6.7/o -I../h -I../gcl-tk
run_process.c
run_process.c: In function `open_connection':
run_process.c:380: `SIOCSPGRP' undeclared (first use in this function)
run_process.c:380: (Each undeclared identifier is reported only once
run_process.c:380: for each function it appears in.)
make[4]: *** [run_process.o] Error 1
make[4]: Leaving directory `/export/disk0/dmprod/axiom/lsp/gcl-2.6.7/o'
make[3]: *** [unixport/saved_pre_gcl] Error 2
make[3]: Leaving directory `/export/disk0/dmprod/axiom/lsp/gcl-2.6.7'
/bin/sh: unixport/saved_gcl: No such file or directory
make[2]: *** [gcldir] Error 127
make[2]: Leaving directory `/export/disk0/dmprod/axiom/lsp'
make[1]: *** [lspdir] Error 2
make[1]: Leaving directory `/export/disk0/dmprod/axiom'
make: *** [all] Error 2
bash-2.05$

-------

I see from the following message that this is a known error:

http://lists.gnu.org/archive/html/gcl-devel/2005-09/msg00002.html
http://lists.gnu.org/archive/html/gcl-devel/2005-04/msg00001.html

From: 	Raymond Toy
Subject: 	[Gcl-devel] Building on solaris, and maxima
Date: 	Sat, 02 Apr 2005 07:43:40 -0500

I tried building gcl cvs again on solaris yesterday. Everything went
smoothly, except run_process.c uses SIOCSPGRP. On Solaris, this isn't
defined unless you include sys/sockio.h I just added that to
run_process.c and it compiles up nicely.

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

Perhaps you are also seeing this problem?

\start
Date: Tue, 14 Feb 2006 23:12:08 -0600
From: Jay Belanger
To: Bill Page
Subject: re: Aldor and Axiom

Bill Page writes:
...
>> Hmm.  But aren't there some cases where you want this, like
>> (say) knowing that 4 is a real integer without having to
>> explicitly say that? (Sorry that's probably a dumb question).
>
> The phrase "real integer" is kind of dumb ... :) What other kinds
> of integers are there?

Complex (Gaussian) integers?

> I still firmly believe that Aldor is the best way forward. Given
> that everyone who has posted to the:
>
>   http://wiki.axiom-developer.org/FreeAldor
>
> petition (including Steven Watt!) has been positive about the
> idea of making Aldor open source, I think we should just proceed
> based on that idea.

Is it that clear that it will become open source?
It may be that it just takes a while, but is it possible that it's
taking a while because there are roadblocks that we aren't aware of? 

\start
Date: 15 Feb 2006 06:14:32 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: axiom did not compile on sparc solaris
Cc: Gianluca Gregori

Bill Page writes:

| On Tuesday, February 14, 2006 7:05 AM Gianluca Gregori wrote:
| > 
| > I am trying to compile axiom on a sparc solaris machine but
| > having lots of trouble (not to experienced as well).
| > I was able to compile gcl-2.6.7 with the --enable-custreloc
| > option (bfd did not compile). However, still axiom does not
| > compile properly.
| > Any help is appreciated. --Thanks, Gianluca
| >
| 
| What release of Axiom are you trying to build and on
| what version of solaris? Why did you choose to use
| --enable-custreloc?
| 
| I am also trying to build Axiom from the September 2005 tarball:
| 
| http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom-Sept2005-
| src.tgz
| 
| on Solaris 8 sparc (280R dual cpu) system. If I simply follow
| the instructions of:
| 
|   ./configure
| 
| You must set your AXIOM and PATH variables. Type:
| 
| To build the rest of the system type:
| 
| export AXIOM=/export/disk0/dmprod/axiom/mnt/solaris9
| export PATH=$AXIOM/bin:$PATH
| make AWK=gawk TAR=gtar PATCH=gpatch

We should aim to mechanize those steps instead of requiring user
intervention. 

| The Axiom ./configure uses 'solaris9' even though my system
| is actually Solaris 8. I don't think this a problem.

I haven't looked to configure yet, but if we're going to use configure
at all, then we should use the standard scripts that compute and use
the canonical system triplet.
I no longer have access to sparc or solaris boxes at home.  At work I
do have access to solaris boxes, but any development that require
"unusual" toolsets setting is basically unlikely to happen :-(

\start
Date: Wed, 15 Feb 2006 00:25:03 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: axiom did not compile on sparc solaris

On Wednesday, February 15, 2006 12:15 AM Gabriel Dos Reis wrote:

> Bill Page writes:
> |
> |   ./configure
> |
> | You must set your AXIOM and PATH variables. Type:
> |
> | To build the rest of the system type:
> |
> | export AXIOM=/export/disk0/dmprod/axiom/mnt/solaris9
> | export PATH=$AXIOM/bin:$PATH
> | make AWK=gawk TAR=gtar PATCH=gpatch
>
> We should aim to mechanize those steps instead of requiring user
> intervention.

I agree completely. The way the Axiom build works right now
is quite non-standard and largely unsatisfactory.

>
> | The Axiom ./configure uses 'solaris9' even though my system
> | is actually Solaris 8. I don't think this a problem.
>
> I haven't looked to configure yet, but if we're going to use
> configure at all, then we should use the standard scripts that
> compute and use the canonical system triplet.

Actually, Axiom's ./configure is not the standard autoconf
type of script. It is just something quickly cobbled together
that really does very little.

If you have some experience with using autoconf then your
help creating a proper ./configure for Axiom would be greatly
appreciated. :)

\start
Date: Wed, 15 Feb 2006 01:03:21 -0500
From: Bill Page
To: Jay Belanger
Subject: re: Aldor and Axiom

On Wednesday, February 15, 2006 12:12 AM Jay Belanger wrote:
>
> Bill Page writes:
> ...
> >> Hmm.  But aren't there some cases where you want this, like
> >> (say) knowing that 4 is a real integer without having to
> >> explicitly say that? (Sorry that's probably a dumb question).
> >
> > The phrase "real integer" is kind of dumb ... :) What other kinds
> > of integers are there?
>
> Complex (Gaussian) integers?

Isn't that sort of like saying "complex reals" (sic) are a
kind of real number. ;)

And you forgot "Omnific Integers" ... :)

http://mathworld.wolfram.com/OmnificInteger.html

But I am inclined to agree with Leopold Kronecker:

http://www-groups.dcs.st-and.ac.uk/~history/Mathematicians/Kronecker.htm
l

"... he believed in the reduction of all mathematics to
arguments involving only the integers and a finite number
of steps. Kronecker is well known for his remark:-

    God created the integers, all else is the work of man.

Kronecker believed that mathematics should deal only with finite
numbers and with a finite number of operations. He was the first
to doubt the significance of non-constructive existence proofs."

(With that attitude, surely Kronecker should be counted among
the fathers of modern computer algebra. ;)

So therefore I prefer to think that there is really only one
kind of Integer.

>
> > I still firmly believe that Aldor is the best way forward.
> > Given that everyone who has posted to the:
> >
> >   http://wiki.axiom-developer.org/FreeAldor
> >
> > petition (including Steven Watt!) has been positive about the
> > idea of making Aldor open source, I think we should just
> > proceed based on that idea.
>
> Is it that clear that it will become open source?

I am willing to bet on it. In fact I am seriously considering
how we could make the source immediately available under a
provisional license. See the thread on the axiom-legal list.

> It may be that it just takes a while, but is it possible that
> it's taking a while because there are roadblocks that we aren't
> aware of?
>

Really, Aldor is "nearly" open source already. All you have to
do to get access to the source code is to ask at aldor.org.
Practically speaking, this means obtaining the approval of
Steven Watt. So far as I know, no one who has asked has ever
been denied access.

\start
Date: Wed, 15 Feb 2006 02:26:26 -0500
From: Bill Page
To: Gianluca Gregori
Subject: RE: axiom did not compile on sparc solaris

On Tuesday, February 14, 2006 9:53 PM I wrote:

>
> I am also trying to build Axiom from the September 2005 tarball:
>
> http://axiom.axiom-developer.org/axiom-website/DOWNLOADS/axiom
> -Sept2005-src.tgz
>
> on Solaris 8 sparc (280R dual cpu) system. If I simply follow
> the instructions of:
>
>   ./configure
>
> ...

And it I make the following sys/sockio.h patch to run_process.c
during the Axiom build:

>
> http://lists.gnu.org/archive/html/gcl-devel/2005-09/msg00002.html
> http://lists.gnu.org/archive/html/gcl-devel/2005-04/msg00001.html
>
> On Sat, 02 Apr 2005 07:43:40 -0500 Raymond Toy
>
> I tried building gcl cvs again on solaris yesterday. Everything
> went smoothly, except run_process.c uses SIOCSPGRP. On Solaris,
> this isn't defined unless you include sys/sockio.h I just added
> that to run_process.c and it compiles up nicely.
> 

then GCL builds just fine, but the Axiom build now fails at
the following point (with no prior errors):

...
/export/disk0/dmprod/axiom/obj/solaris9/interp/cattable.o Loading
/export/disk0/dmprod/axiom/obj/solaris9/interp/cformat.o
start address -T 4e21e8 Finished loading
/export/disk0/dmprod/axiom/obj/solaris9/interp/cformat.o Loading
/export/disk0/dmprod/axiom/obj/solaris9/interp/cfuns.o directoryp is
undefined

Error: Cannot get relocated section contents

Fast links are on: do (si::use-fast-links nil)
for debugging Error signalled by LOAD.  Broken at
BUILD-INTERPSYS.  Type :H for Help.  BOOT>>make[3]: ***
[/export/disk0/dmprod/axiom/obj/solaris9/bin/interpsys] Error 255
make[3]: Leaving directory `/export/disk0/dmprod/axiom/src/interp'
make[2]: *** [interpdir] Error 2 make[2]: Leaving directory
`/export/disk0/dmprod/axiom/src' make[1]: *** [srcdir] Error 2 make[1]:
Leaving directory `/export/disk0/dmprod/axiom' make: *** [all] Error 2
bash-2.05$

----------

Has anyone every built Axiom successfully on Solaris?

\start
Date: 15 Feb 2006 10:25:59 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: The symbol 4 (was Re: Aldor and Axiom)

Ralf Hemmecke writes:

> > What other kinds of integers are there? But the symbol 4 can certainly
> > stand for other things besides the integer 4.
> 
> Right. 4 is just a symbol consisting of three strokes. If one doesn't bring it
> into a context its meaning would be totally unclear. Well, nowadays humans tend
> to interpret this always as an integer, but I think several thousand years ago
> that was not so clear.

Gaussian Integers was a joke, of course. (of course, I'm speaking only for my
response and not for Jay's)

However, the "guessing" of types in Axiom is tremendously useful and without
it, I probably would stop using it. Note that MuPAD does no type guessing, and
thus leaves people in fact with the expression domain by default.

Of course (!!!), type guessing may only be done by the interpreter. As far as I
know, the compiler does no guessing - at least not intentionally. (It uses the
types currently in scope, which may be dangerous at times, too, but that's a
different matter)

I repeat, because I think it's important:

* Type guessing should by done by the interpreter and only by the interpreter.*

The strategy is of course, to take the most "natural" type. I think the Axiom
book somewhere says, the most narrow possible type. This explains the
preference of PI over NNI over INT. Of course it does not explain why it would
not chose PF 5, so I tend to think that it is necessarily hard-coded
information, possibly in a database.

Still, as a mathematician I must say that I wouldn't want to live without
it. In fact, I even struggled to write my guessing package in a way so that the
package parameters can be guessed by the interpreter, which means that one only
has to type the list of numbers which one wants to guess and not the 10
parameters of the package call. Of course, once in a 100 times one may want to
override the defaults, but this is not a problem.

And in most cases, the problem "Oh, Axiom chose a different type than I had in
mind" does not occur, because the interpreter gives quite a lot of feedback.

I do know that there are constructions where type guessing may produce
different results, but I tend to believe that these situations are rare, can be
avoided with a well done library and do not justify giving up this help
altogether.

\start
Date: 15 Feb 2006 10:39:46 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Aldor and Axiom

Ralf Hemmecke writes:

> >> How do we resolve things like Aldor's libalgebra vs. Axiom's libraries?
> 
> > I would propose that we forget about Aldor's native libraries for now (as
> > nice, though limited, as they are).
> 
> If I knew where to hook libaldor into Axiom, I would already have done
> so. But libaldor basically starts from zero and for Axiom the whole
> construction of the domains and categories is still mystical to me.
> 
> In any case if SPAD should be translated to Aldor one has to start with some
> domain or category.

Yes. But what exactly is mystical to you? Everything starts in catdef.spad, and
in fact the code is very easy to read, I find.

The polynomial hierarchy should probably be taken from Aldor, I believe it is
superior.

-------------------------------------------------------------------------------
So, the real effort would be to design a sound hierarchy and then translate the
bits one at a time, using new algorithms as we go along. (For example,
replacing the huge algorithm for calculating the limit of an expression by the
simple mrv algorithm also used by MuPAD)
-------------------------------------------------------------------------------

Maybe it is even possible to mix libraries in an intermediate step, so that we
don't have to do the transition all at once.

Some time ago I proposed to Antoine to implement a hierarchy of function
domains (i.e., polynomials, rational functions, algebraic functions, holonomic
functions, etc.), since this is currently missing, resp., not well solved in
Axiom. This would also be in a sense quite independent of the implementation of
other classes, so I suppose it should be done in Aldor.

\start
Date: Wed, 15 Feb 2006 05:13:10 -0500
From: Bill Page
To: Scott Morrison
Subject: RE: What is SubDomain (was: non extending category)

Scott,

Thank you for your comments about SubDomain. I think your
knowledge and experience as one of the original designers
of Axiom is invaluable to us. I am very happy that you are
willing to contribute to the discussion here.

On Tuesday, February 14, 2006 10:29 AM you wrote:

> Bill Page wrote:
>> ..
>> SCM: Do you happen to remember what you wrote 20 years ago? :)
>
> Well, not really.
>

It seems you remember than I do about the things I was doing
20 years ago... :)
=09
> I do remember that I never liked SubDomain.  We had all kinds
> of special-case code to deal with it, and it was only used for
> NonNegativeInteger and PositiveInteger.  I believe the original
> motivation for sub-domains was to share implementations, but
> not categories.  So PositiveInteger could share the all the
> implementation code from Integer, but not the categories of
> Integer, since they don't form a Group under addition, for
> example.  In the end it caused a lot more work than it saved.
>

In http://wiki.axiom-developer.org/SandBoxNNI

I have experimented with replacing:

  == SubDomain(Integer,#1 >= 0) add
  ...

in the code for NNI by just:

  == Integer add
  ...

plus an explicit coercion from NNI to Integer and conversion
vice versa.

I think this experiment confirms your claim that the SubDomain
construct is not of much value.

> The concept of sub-domain never made it into Aldor, as far as
> I know, and that's a good thing.

If the automatic definitions of the two functions
'coerce:NNI->Integer' and 'convert:Integer->NNI' are the only
consequences of the SubDomain clause, then I guess I would
have to agree.

\start
Date: Wed, 15 Feb 2006 11:19:51 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Documentation bug?

Hi Bill,

Maybe I should have been a bit more precise. I actually already knew 
what )abbrev is for. I just forgot the syntax.

As you see the first message tells me:

   Issue )abbrev? for more information.

And if I do that I get a not so helpful message. That was the bug I was 
referring to.

Anyway, is there somebody who thinks that the abbreviation is vital to 
Axiom? (Well it is, because the generated NRLIB will be created under 
that name.) However, I somehow think that is a constraint of old where 
filenames could not be arbitrary long. Further, one then has 2 
identifiers in Axiom that refer to the same thing.

I believe such abbreviations could be achieved on a per user basis. 
Simply put appropriate macro definitions in your .axiom.input file.
Aldor does not understand ")abbrev" anyway.

Ralf


On 02/14/2006 08:27 PM, Page, Bill wrote:
> On Tuesday, February 14, 2006 7:14 AM Ralf Hemmecke wrote:
>> Can someone explain that ...
>>
>> (2) -> )abbr domain XYZ
>>     domain must be followed by an alternating list of abbreviation(s)
>>        and name(s). Issue )abbrev? for more information.
>> (2) -> )abbrev?
>>     Your argument list is not valid.
>>
>> Very helpful! ;-)

\start
Date: Wed, 15 Feb 2006 11:33:12 +0100
From: Ralf Hemmecke
To: Cliff Yapp
Subject: re: Aldor and Axiom

On 02/14/2006 09:38 PM, C Y wrote:
> OK.  Here's a link for the lazy (me in a few hours ;-) : 
> http://www.aldor.org/docs/HTML/chap21.html  

Be careful, the code there will probably not work.
print: TextWriter
<<: (TextWriter, SOMETYPE) -> TextWriter

Unfortunately, "print" is not in libaldor but in the old axllib. You 
should instead say

   import from TextWriter;
   stdout << "SOME Object";

SingleInteger is MachineInteger in libaldor.

There is no BasicType anymore. I think the closest would be

define BasicType: Category == with {
	PrimitiveType;
	OutputType;
	HashType;
}

The signature
   sample: %
has been removed, since it is not always easy to provide an element at 
creation time of the domain.

\start
Date: Wed, 15 Feb 2006 05:48:16 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Documentation bug?

Ralf,

On Wednesday, February 15, 2006 5:20 AM you wrote:
>
> Maybe I should have been a bit more precise. I actually
> already knew what )abbrev is for. I just forgot the syntax.

No problem.

>
> As you see the first message tells me:
>
>    Issue )abbrev? for more information.
>
> And if I do that I get a not so helpful message. That was the
> bug I was referring to.

I agree. I think is would be good to record such deficiencies
as issue reports in the IssueTracker on the Axiom wiki.

>
> Anyway, is there somebody who thinks that the abbreviation is
> vital to Axiom? (Well it is, because the generated NRLIB will
> be created under that name.)

Yes I do think they are essential to the way Axiom works at
the present time. See more below.

> However, I somehow think that is a constraint of old where
> filenames could not be arbitrary long. Further, one then has
> 2 identifiers in Axiom that refer to the same thing.

I agree that the limitation on the length of the abbreviation
itself was constrained by the old file names. But there are
many cases where standard short name is quite convenient -
especially for use by expert users in the Axiom interpreter.
For example I often write: 'POLY INT' instead of
'Polynomial Integer' (and I am sure I could think of more
extreme cases where the abbreviations are useful).

>
> I believe such abbreviations could be achieved on a per
> user basis. Simply put appropriate macro definitions in
> your .axiom.input file.

Although this might be convenient for local and personal
use, I worry that it might confuse or slow communications
between more experienced users. For example if you defined
the macros

  P ==> Polynomial
  I ==> Integer

insist on writing 'P I' I would probably be confused until
you explained your conventions.

> Aldor does not understand ")abbrev" anyway.

Well, I think the situation of using Aldor in Axiom is a
little different than using Aldor stand alone. When a domain
is compiled using Aldor inside Axiom the domain will still
have an abbreviation. You can see this by issuing the ')show'
command for the new domain. For example:

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

In this case the abbreviation 'FINITEG' was assigned internally,
probably by the Axiom/Aldor interface.

Besides being a shortcut, one reason that Axiom needs abbreviations
is in order to construct the internal (lisp) mangled name of the
functions exported by the domain. See for example the lisp code
in the following example:

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

I think this name mangling is essential to the way Axiom performs
function selection and calling.

\start
Date: Wed, 15 Feb 2006 12:00:44 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: The symbol 4 (was Re: Aldor and Axiom)

On 02/15/2006 10:25 AM, Martin Rubey wrote:
> Ralf Hemmecke writes:
> 
>>> What other kinds of integers are there? But the symbol 4 can certainly
>>> stand for other things besides the integer 4.
>> Right. 4 is just a symbol consisting of three strokes. If one doesn't bring it
>> into a context its meaning would be totally unclear. Well, nowadays humans tend
>> to interpret this always as an integer, but I think several thousand years ago
>> that was not so clear.

> However, the "guessing" of types in Axiom is tremendously useful and without
> it, I probably would stop using it. Note that MuPAD does no type guessing, and
> thus leaves people in fact with the expression domain by default.
> 
> Of course (!!!), type guessing may only be done by the interpreter.

I was never saying anything else. Guessing should be done only by an 
interpreter or maybe implemented via BNatural.

However, I wanted to stress the point that the compiler should be picky 
and reject everything it does not clearly understand from the context. 
No ambiguities allowed.

So for writing libraries the programmer is forced to state explicitly 
what he/she wants.

The user interface is another thing. Clearly there should be a shell 
around all this complicated type stuff which helps the user to solve the 
problem. It should, however, be transparent how the interpreter choses 
appropriate types or in other words. There should be a well documented 
algorithm how the interpreter extends the scope so that it can find 
appropriate functions. Maybe one needs a whole lot of (automatic) 
coercion theory.

Further, maybe, that affects also how libraries have to be written. For 
example, if you have 4 domains A, B, C, D and the following coercion 
functions,

    A ----> B
    |       |
    v       v
    C ----> D

and you type in d(a) in the interpreter where d: D->D and a:A then it is 
vital for the correctness that the above diagram is commutative 
otherwise it would depend on the choice the interpreter makes. Well, 
that says programmers should make sure that any such diagram commutes. 
Maybe that should become a big convention for coercion functions in Axiom.

\start
Date: Wed, 15 Feb 2006 05:07:20 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [#268 )abbrev? with too little detail] (new) 

(2) -> )abbr domain XYZ
    domain must be followed by an alternating list of abbreviation(s)
       and name(s). Issue )abbrev? for more information.
(2) -> )abbrev?
    Your argument list is not valid.

\start
Date: Wed, 15 Feb 2006 12:25:15 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Documentation bug?

> I agree that the limitation on the length of the abbreviation
> itself was constrained by the old file names. But there are
> many cases where standard short name is quite convenient -
> especially for use by expert users in the Axiom interpreter.
> For example I often write: 'POLY INT' instead of
> 'Polynomial Integer' (and I am sure I could think of more
> extreme cases where the abbreviations are useful).

Well, I agree that some standard is not that bad. However, I mostly 
prefer to use no abbreviation. And if I do in my code I (probably) also 
provide the explicit macros I use.

Well, I don't yet have a very good argument against abbreviations, 
except that on a mailing list not all people immediately understand what 
for example, FAXF or FEXPR stand for.

> Besides being a shortcut, one reason that Axiom needs abbreviations
> is in order to construct the internal (lisp) mangled name of the
> functions exported by the domain. See for example the lisp code
> in the following example:
> 
> http://wiki.axiom-developer.org/SandBoxNNI
> 
> I think this name mangling is essential to the way Axiom performs
> function selection and calling.

Do you mean

; (DEFUN |NNI2;shift;$I$;2| ...) is being compiled.

I don't care much about internal names that I will never see, but I 
guess the name could also be generated as 
|NonNegativeInteger2;shift;$I$;2| without any further trouble as long as 
any compilation follows the "full-name-priciple".

I'll be quiet about )abbrev. It's not my main concern for now.

\start
Date: Wed, 15 Feb 2006 12:43:32 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Aldor and Axiom

Hi Martin,

>> If I knew where to hook libaldor into Axiom, I would already have done
>> so. But libaldor basically starts from zero and for Axiom the whole
>> construction of the domains and categories is still mystical to me.

>> In any case if SPAD should be translated to Aldor one has to start with some
>> domain or category.

> Yes. But what exactly is mystical to you? Everything starts in catdef.spad, and
> in fact the code is very easy to read, I find.

Let me quote the first few lines... (documentation stripped)

AbelianGroup(): Category == CancellationAbelianMonoid with
       "-": % -> %
       "-": (%,%) -> %
       "*": (Integer,%) -> %
     add
       (x:% - y:%):% == x+(-y)
       subtractIfCan(x:%,y:%):Union(%,"failed")==(x-y)::Union(%,"failed")
       n:NonNegativeInteger * x:% == (n::Integer) * x
       import RepeatedDoubling(%)
       if not (% has Ring) then
         n:Integer * x:% ==
           zero? n => 0
           n>0 => double(n pretend PositiveInteger,x)
           double((-n) pretend PositiveInteger,-x)

Since there is no definition of "Integer" in that file, the compiler 
must know about that thing or it must look into integer.spad to find 
what Integer stands for. Yes, yes, I know, here the whole business of 
circular dependencies begins. I guess, finally, Integer will be an 
abelian group itself. ;-)

So you see, I still find it mystical. I simply don't know what is built 
into the compiler.

Let us suppose the following scenario. I remove any file from 
src/algebra/ and any corresponding Makefile entry. Then I start 
compiling Axiom. Would I end up with an Axiom framework that has no 
mathematical knowledge.

Probably not. The interpreter needs something like OutputForm in order 
to print something reasonable on the screen. Is this type builtin?

Does somebody know of a cutpoint between SPAD compiler and the actual 
libraries?

\start
Date: 15 Feb 2006 14:50:39 +0100
From: Francois Maltey
To: list
Subject: My second compile command.

Hello, 

I begin to test the manip.spad file (because I want to expand cos (2*x).)

So I copy the manip.spad file in a local directory, add the silly lines
in TRMANIP package 

ess : F -> F  -- in the declaration area
ess x == 1+x  -- in the implantation area

The first compilation seems right, 
I get an error at the second and next compilations.
Must I erase all files but manip.spad in the local directory.
Then how can I test my new package ?

   Loading /usr/local/axiom/mnt/linux/autoload/br-prof.
   Loading /usr/local/axiom/mnt/linux/autoload/br-saturn.
   finalizing NRLIB FACTFUNC 
   Processing FactoredFunctions for Browser database:
--------(nthRoot ((Record (: exponent N) (: coef M) (: radicand (List M))) (Factored M) N))---------
--------(log ((List (Record (: coef N) (: logand M))) (Factored M)))---------
--------constructor---------
 
   >> System error:
   Cannot rename the file #p"FACTFUNC.erlib" to #p"FACTFUNC.NRLIB".

\start
Date: Wed, 15 Feb 2006 09:39:45 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Documentation bug?

> Maybe I should have been a bit more precise. I actually already knew 
> what )abbrev is for. I just forgot the syntax.
> 
> As you see the first message tells me:
> 
>    Issue )abbrev? for more information.
> 
> And if I do that I get a not so helpful message. That was the bug I was 
> referring to.

visit src/doc/msgs/s2-us.msgs

this file contains most (not all, unfortunately) of the messages 
issued by axiom. i wrote it so that we could "internationalize"
the messages (e.g. write german equivalent text) hence the "us" in 
name.

you could rewrite the message to make it clearer and send a patch.

most of the message from axiom, as you'd expect from a piece of
research software, are nearly "debugging" messages intended for
people who know what they are doing. we could make a beginner 
or expert set of meesage.

if you're feeling ambitious you could translate the messages into
your native language and we could make the system use the native
language version. i'm not sure if the mechanism fully works as
i'm unable to speak other languagees so it's never been fully tested.

there are several messages that deal with "abbreviations"

S2IL0006
S2IL0009
S2IL0010
S2IL0019
S2IL0021
S2IM0003
S2IS0028
S2IZ0001

S2IZ0002 <-- your offending message

S2IZ0003
S2IZ0004
S2IZ0005
S2IZ0006
S2IZ0009
S2IZ0010
S2IZ0043
S2IZ0056
S2IZ0057



\start
Date: 15 Feb 2006 14:22:04 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Aldor and Axiom

Ralf Hemmecke writes:

> > Yes. But what exactly is mystical to you? Everything starts in catdef.spad,
> > and in fact the code is very easy to read, I find.
> 
> Let me quote the first few lines... (documentation stripped)
> 
> AbelianGroup(): Category == CancellationAbelianMonoid with
>        "-": % -> %
>        "-": (%,%) -> %
>        "*": (Integer,%) -> %
>      add
>        (x:% - y:%):% == x+(-y)
>        subtractIfCan(x:%,y:%):Union(%,"failed")==(x-y)::Union(%,"failed")
>        n:NonNegativeInteger * x:% == (n::Integer) * x
>        import RepeatedDoubling(%)
>        if not (% has Ring) then
>          n:Integer * x:% ==
>            zero? n => 0
>            n>0 => double(n pretend PositiveInteger,x)
>            double((-n) pretend PositiveInteger,-x)
> 
> Since there is no definition of "Integer" in that file, the compiler must
> know about that thing or it must look into integer.spad to find what Integer
> stands for. Yes, yes, I know, here the whole business of circular
> dependencies begins. I guess, finally, Integer will be an abelian group
> itself. ;-)

But as far as I know, for Aldor this situation was abstracted and there is now
a keyword for dealing with it, I believe it is "extend".

> Let us suppose the following scenario. I remove any file from src/algebra/
> and any corresponding Makefile entry. Then I start compiling Axiom. Would I
> end up with an Axiom framework that has no mathematical knowledge.
> 
> Probably not.

Well, I do think so, at least roughly. In fact, as far as I know, debugsys does
something similar.

Furthermore, Tim Daly analysed the circular dependencies to know in which
"layer" any given domain is. You can see this in the file lattice.pamphlet on
MathAction or in src/algebre/Makefile.

> The interpreter needs something like OutputForm in order to print something
> reasonable on the screen. Is this type builtin?

No, it is defined in outform.spad. And, as long as you don't have a coercion
function to OUTFORM, you don't need it anyway :-)

Without OUTFORM, you can print using the Lisp function "print".

\start
Date: Wed, 15 Feb 2006 14:58:19 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: Aldor and Axiom

>>Since there is no definition of "Integer" in that file, the compiler must
>>know about that thing or it must look into integer.spad to find what Integer
>>stands for. Yes, yes, I know, here the whole business of circular
>>dependencies begins. I guess, finally, Integer will be an abelian group
>>itself. ;-)

> But as far as I know, for Aldor this situation was abstracted and there is now
> a keyword for dealing with it, I believe it is "extend".

Right. If you look at the sources of libaldor it starts with 
lib/aldor/src/lang/sal_lang.as and then lib/aldor/src/base/sal_base.as.

Interestingly, in the latter file there is some interdependency.

define PrimitiveType: Category == with {
	=: (%, %) -> Boolean;
	~=: (%, %) -> Boolean;
	default { (a:%) ~= (b:%):Boolean == ~(a = b); }
}

Boolean: PrimitiveType with {
	~: % -> %;
	coerce: Bool -> %;
	coerce: % -> Bool;
	false:%;
	true:%;
} == add {
	Rep == Bool;
	coerce(b:%):Bool	== rep b;
	coerce(b:Bool):%	== per b;
	false:%			== false@Bool :: %;
	true:%			== true@Bool :: %;
	~(x:%):%		== (~(x::Bool))::%;
	(a:%) = (b:%):%		== (rep a = rep b)::%;
	(a:%) ~= (b:%):%	== (rep a ~= rep b)::%;
}

But obviously, the Aldor compiler can handle this.

>>Let us suppose the following scenario. I remove any file from src/algebra/
>>and any corresponding Makefile entry. Then I start compiling Axiom. Would I
>>end up with an Axiom framework that has no mathematical knowledge.
>>
>>Probably not.
> 
> 
> Well, I do think so, at least roughly. In fact, as far as I know, debugsys does
> something similar.

Should I know debugsys?

> Furthermore, Tim Daly analysed the circular dependencies to know in which
> "layer" any given domain is. You can see this in the file lattice.pamphlet on
> MathAction or in src/algebre/Makefile.

Thanks. I'll take a look.

>>The interpreter needs something like OutputForm in order to print something
>>reasonable on the screen. Is this type builtin?
> 
> 
> No, it is defined in outform.spad. And, as long as you don't have a coercion
> function to OUTFORM, you don't need it anyway :-)
> 
> Without OUTFORM, you can print using the Lisp function "print".

But how does the Interpreter show the result? Doesn't it rely on the 
fact that a domain satisfies CoercibleTo(OutputForm)?

For example, if you write a file

---MyInt.spad
)abbr domain MYI MyInt
MyInt: with
   x: %
  == Integer add
   x: % == 1
---END

Then
)co MyInt.spad
x:MyInt

it prints just Type: Void but no other output.

So in order to have a reasonable input/output behaviour on the Axiom 
command line, I should meet certain criteria. Is that written somewhere?

\start
Date: Wed, 15 Feb 2006 09:55:35 -0500
From: Gianluca Gregori
To: Bill Page
Subject: re: axiom did not compile on sparc solaris

Thanks for reply.

I am still not able to compile. My answers are interleaved. Bear
in mind I am not an expert programmer, but I would like to use
axiom to do science. 

> on Solaris 8 sparc (280R dual cpu) system. If I simply follow
> the instructions of:
> 
>   ./configure
> 
> You must set your AXIOM and PATH variables. Type:
> 
> To build the rest of the system type:
> 
> export AXIOM=/export/disk0/dmprod/axiom/mnt/solaris9
> export PATH=$AXIOM/bin:$PATH
> make AWK=gawk TAR=gtar PATCH=gpatch

I did that. But I also added --enable-emacsdir=no in the
lsp/Makefile (to the ./configure line) as, for some reasons, gcl
./configure would stop otherwise.


> 
> What release of Axiom are you trying to build and on
> what version of solaris? Why did you choose to use
> --enable-custreloc?

I am using solaris 9 on a sun sparc machine (a tadpole laptop).
I downloaded the Sept 05 tarball. These are the problems I
found:

The first error I encounters is on alloc.c:

[...]
ranlib .libs/libgmp.a
creating libgmp.la
(cd .libs && rm -f libgmp.la && ln -s ../libgmp.la libgmp.la)
gmake[7]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7/gmp3'
gmake[6]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7/gmp3'
gmake[5]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7/gmp3'
touch gmp_all
gmake[4]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7'
rm -f o/cmpinclude.h ; cp h/cmpinclude.h o
(cd o; gmake all)
gmake[4]: Entering directory
`/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7/o'
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3
-fomit-frame-pointer 
-I/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7/o -I../h
-I../gcl-tk main.c  
In file included from ../h/include.h:37,
                 from main.c:49:
../h/config.h:1:1: warning: "__ELF__" redefined
<built-in>:1:1: warning: this is the location of the previous
definition
main.c: In function 'main':
main.c:181: warning: format '%d' expects type 'int', but
argument 4 has type 'pid_t'
gcc -c -Wall -DVOL=volatile -fsigned-char -pipe -O3
-fomit-frame-pointer 
-I/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7/o -I../h
-I../gcl-tk alloc.c  
In file included from ../h/include.h:37,
                 from alloc.c:31:
../h/config.h:1:1: warning: "__ELF__" redefined
<built-in>:1:1: warning: this is the location of the previous
definition
alloc.c:1663: error: static declaration of 'memalign' follows
non-static declaration
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/include/stdlib.h:207:
error: previous declaration of 'memalign' was here
gmake[4]: *** [alloc.o] Error 1
gmake[4]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7/o'
gmake[3]: *** [unixport/saved_pre_gcl] Error 2
gmake[3]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7'
/bin/sh: unixport/saved_gcl: not found
gmake[2]: *** [gcldir] Error 1
gmake[2]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp'
gmake[1]: *** [lspdir] Error 2
gmake[1]: Leaving directory `/export/home/gregori1/Xcodes/axiom'
gmake: *** [all] Error 2


What I did was to comment out the memalign function in alloc.c.
I also needed to add <sys/sockio.h> in run_process.c.

If I do this, the compilation goes on further but I get an error
at:

[...]
ar: creating libpre_gcl.a
cp ../o/gcllib.a libgclp.a
ranlib libgclp.a
cp init_pre_gcl.lsp.in init_pre_gcl.lsp.tmp
touch raw_pre_gcl_map
gcc -o raw_pre_gcl  \
	-L.    -lpre_gcl -lm  -lsocket -lnsl -lc -lgclp
/export/home/gregori1/Xcodes/axiom/obj/solaris9/lib/libspad.a  
Undefined			first referenced
 symbol  			    in file
libintl_dgettext                   
./libpre_gcl.a(binutils_bfd_bfd.o)
ld: fatal: Symbol referencing errors. No output written to
raw_pre_gcl
collect2: ld returned 1 exit status
gmake[4]: *** [raw_pre_gcl_map] Error 1
gmake[4]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7/unixport'
gmake[3]: *** [unixport/saved_pre_gcl] Error 2
gmake[3]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp/gcl-2.6.7'
/bin/sh: unixport/saved_gcl: not found
gmake[2]: *** [gcldir] Error 1
gmake[2]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/lsp'
gmake[1]: *** [lspdir] Error 2
gmake[1]: Leaving directory `/export/home/gregori1/Xcodes/axiom'
gmake: *** [all] Error 2

To avoid bfd linking, I then tried to switch to
--enable-custreloc in the gcl compilation. GCL than compiles
(tested out independently), but get another error at

[...]
Loading
/export/home/gregori1/Xcodes/axiom/obj/solaris9/interp/sockio.o
symbol "open_server" is not in base imagesymbol "sock_get_int"
is not in base imagesymbol "sock_send_int" is not in base
imagesymbol "sock_get_string_buf" is not in base imagesymbol
"sock_send_string_len" is not in base imagesymbol
"sock_get_float" is not in base imagesymbol "sock_send_float" is
not in base imagesymbol "sock_send_wakeup" is not in base
imagesymbol "server_switch" is not in base imagesymbol
"flush_stdout" is not in base imagesymbol "sock_send_signal" is
not in base imagesymbol "print_line" is not in base imagesymbol
"plus_infinity" is not in base imagesymbol "minus_infinity" is
not in base imagesymbol "NANQ" is not in base image
Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by SETQ.
Broken at NANQ.  Type :H for Help.
BOOT>>gmake[3]: ***
[/export/home/gregori1/Xcodes/axiom/obj/solaris9/bin/interpsys]
Error 255
gmake[3]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/src/interp'
gmake[2]: *** [interpdir] Error 2
gmake[2]: Leaving directory
`/export/home/gregori1/Xcodes/axiom/src'
gmake[1]: *** [srcdir] Error 2
gmake[1]: Leaving directory `/export/home/gregori1/Xcodes/axiom'
gmake: *** [all] Error 2

In practise, not able to build it. Any suggestions?
Thanks in advance.
--GG

\start
Date: 15 Feb 2006 16:01:21 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: re: Aldor and Axiom

Ralf Hemmecke writes:

> > But as far as I know, for Aldor this situation was abstracted and
> > there is now a keyword for dealing with it, I believe it is
> > "extend".
 
> Right. If you look at the sources of libaldor it starts with
> lib/aldor/src/lang/sal_lang.as and then lib/aldor/src/base/sal_base.as.
> 
> Interestingly, in the latter file there is some interdependency.

> [...] 

> But obviously, the Aldor compiler can handle this.

great!

> Should I know debugsys?

no. It is (scarcly..) described in "developernotes", I think.

> > Without OUTFORM, you can print using the Lisp function "print".
 
> But how does the Interpreter show the result? Doesn't it rely on the
> fact that a domain satisfies CoercibleTo(OutputForm)?

yes.

> For example, if you write a file
> 
> ---MyInt.spad
> )abbr domain MYI MyInt
> MyInt: with
>    x: %
>   == Integer add
>    x: % == 1
> ---END
> 
> Then
> )co MyInt.spad
> x:MyInt
> 
> it prints just Type: Void but no other output.

yes, this is what I'd expect. Well, not quite. I'd expect Type:MyInt...

> So in order to have a reasonable input/output behaviour on the Axiom command
> line, I should meet certain criteria. 

Look at outform.spad and out.spad. (I think the latter answers your question)

\start
Date: 15 Feb 2006 17:03:45 +0100
From: Gabriel Dos Reis
To: list
Subject: Re: axiom did not compile on sparc solaris

Bill Page writes:

| If you have some experience with using autoconf

I do.  
At the moment, I'm bit overloaded but I'm very interested to take on
the build machinery. 

\start
Date: Wed, 15 Feb 2006 17:48:34 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Documentation bug?

On 02/15/2006 03:39 PM, root wrote:
>> Maybe I should have been a bit more precise. I actually already knew 
>> what )abbrev is for. I just forgot the syntax.
>>
>> As you see the first message tells me:
>>
>>    Issue )abbrev? for more information.
>>
>> And if I do that I get a not so helpful message. That was the bug I was 
>> referring to.
> 
> visit src/doc/msgs/s2-us.msgs
> 
> this file contains most (not all, unfortunately) of the messages 
> issued by axiom. i wrote it so that we could "internationalize"
> the messages (e.g. write german equivalent text) hence the "us" in 
> name.

Localization of software is not so easy. If I just take the above 
mentioned file and translate it into German, I am sure that I will hate 
the German error message when I see one. The reason is simple. In that 
file there is not enough information to come up with a reasonable 
translation (at least not for all messages).

For example:

S2IP0004
  %1 macro %2b .

I have no idea how this would look like if I replace "macro" by "Makro".
Maybe this would sound completely stupid when I read the actual error 
message. And worse still, that message might be not interpretable 
anymore and totally useless for the one who is reading it.

Maybe you haven't seen programs that open up dialogs saying "Do you want 
to quit?" and at the same time they offer buttons "JA" and "NEIN". (Or 
the other way with german text and english buttons.) That is so ugly!

And I was actually complaining about

(2) -> )abbrev?
     Your argument list is not valid.

which might correspond to
S2IV0005
  Your argument list is not valid.

 > you could rewrite the message to make it clearer and send a patch.

Now to what do you expect me to change that? I don't even know whether 
it is used in several other places.

> most of the message from axiom, as you'd expect from a piece of
> research software, are nearly "debugging" messages intended for
> people who know what they are doing. we could make a beginner 
> or expert set of meesage.

Yes, but only experts can write such messages. Unfortunately, I am not 
one of those.

\start
Date: 15 Feb 2006 18:02:12 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Documentation bug?

Ralf Hemmecke writes:

> > I agree that the limitation on the length of the abbreviation
> > itself was constrained by the old file names. But there are
> > many cases where standard short name is quite convenient -
> > especially for use by expert users in the Axiom interpreter.
> > For example I often write: 'POLY INT' instead of
> > 'Polynomial Integer' (and I am sure I could think of more
> > extreme cases where the abbreviations are useful).
> 
> Well, I agree that some standard is not that bad. However, I mostly prefer to
> use no abbreviation. And if I do in my code I (probably) also provide the
> explicit macros I use.

Note that the abbrevations are inaccessible in spad code. There are only for
the interpreter, and I think that this is a good thing.

\start
Date: Wed, 15 Feb 2006 18:12:55 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: Documentation bug?

On 02/15/2006 06:02 PM, Martin Rubey wrote:
> Ralf Hemmecke writes:
> 
>>> I agree that the limitation on the length of the abbreviation
>>> itself was constrained by the old file names. But there are
>>> many cases where standard short name is quite convenient -
>>> especially for use by expert users in the Axiom interpreter.
>>> For example I often write: 'POLY INT' instead of
>>> 'Polynomial Integer' (and I am sure I could think of more
>>> extreme cases where the abbreviations are useful).
>> Well, I agree that some standard is not that bad. However, I mostly prefer to
>> use no abbreviation. And if I do in my code I (probably) also provide the
>> explicit macros I use.
> 
> Note that the abbrevations are inaccessible in spad code. There are only for
> the interpreter, and I think that this is a good thing.

Aha! That sounds like they are really more or less like macro definitions.

\start
Date: Wed, 15 Feb 2006 13:08:38 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: Documentation bug?

> Localization of software is not so easy. If I just take the above 
> mentioned file and translate it into German, I am sure that I will hate 
> the German error message when I see one. The reason is simple. In that 
> file there is not enough information to come up with a reasonable 
> translation (at least not for all messages).

each message has a key (the S2IV0005)
this key is used in the source code to issue the message
so you can search for the key and find out where it is used.
once you know that then you can figure out what the routine is
trying to do, and given the message text (which follows the
key) you can either write a longer, more informative message
or consider what might be a good translation.

> Now to what do you expect me to change that? I don't even know whether 
> it is used in several other places.

you complained about the message. clearly you expected something else.
rewrite the message to say what you expected. you can find all of the
places that use this message by using grep to find the key. if i recall
correctly there are very few places where a message is used more than
once.

> Yes, but only experts can write such messages. Unfortunately, I am not 
> one of those.

there are no experts. RUDAP... read, understand, document, and patch.

in fact, being an "expert" is a bad thing when trying to write clear,
informative error messages.

\start
Date: Wed, 15 Feb 2006 13:29:50 -0500
From: Tim Daly
To: Francois Maltey
Subject: Re: My second compile command.

>  
>    >> System error:
>    Cannot rename the file #p"FACTFUNC.erlib" to #p"FACTFUNC.NRLIB".

axiom creates a temp directory FACTFUNC.erlib and builds the code there.
if the build succeeds then it renames the directory to FACTFUNC.NRLIB.
if the build fails the FACTFUNC.erlib remains.

do you have write permisson on the FACTFUNC.erlib file?

\start
Date: Wed, 15 Feb 2006 14:08:02 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: re: Aldor and Axiom

>>Let us suppose the following scenario. I remove any file from src/algebra/
>>and any corresponding Makefile entry. Then I start compiling Axiom. Would I
>>end up with an Axiom framework that has no mathematical knowledge.

actually, it's pretty close. if you do
  )set mes auto on
you'll see that even typing 1+1 causes algebra loading.

\start
Date: Wed, 15 Feb 2006 14:10:31 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: re: Aldor and Axiom

> Should I know debugsys?

debugsys is an image i create for deep debugging in the axiom interpreter.
it loads the lisp code rather than the compiled lisp code so i can get
better backtrace information about a failure and i can single-step functions.
it's the same as AXIOMsys only it's interpreted. it's not really intended
for anything useful.

\start
Date: Wed, 15 Feb 2006 14:14:52 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: re: Aldor and Axiom

> So in order to have a reasonable input/output behaviour on the Axiom 
> command line, I should meet certain criteria. Is that written somewhere?
> References?

each domain defines its own print representation.
this is why you get different output if you do

(16) -> (1/2)*x^2+(2/3)*x+3

         1  2   2
   (16)  - x  + - x + 3
         2      3
                                            Type: Polynomial Fraction Integer
(17) -> %::FRAC(POLY(INT))

           2
         3x  + 4x + 18
   (17)  -------------
               6
                                            Type: Fraction Polynomial Integer

even though the underlying information is the same.

\start
Date: 15 Feb 2006 20:01:52 +0100
From: Francois Maltey
To: list
Subject: Re: My second compile command.

Thanks a lot (Ralf and Tim) for your so quickly advice !


1/ I describe rights on theses file bellow.
2/ When I erase rm -r *.NRLIB the compilation is right again.

3/ And now, how can I load my new package ?
4/ Is there in axiom a lot of exemples in order to test if my change
break nothing ?

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

After the first )co manip.spad command I have theses files :

ALGMANIP.NRLIB  FACTFUNC.NRLIB  manip.spad      SIMPAN.NRLIB
FACTFUNC.erlib  libdb.text      POLYROOT.NRLIB  TRMANIP.NRLIB

directories are my own and rwx, and there are 6 files inside.
all files are rw.
And I get no errors :

--------constructor---------
Compiling TRMANIP.NRLIB/TRMANIP.lsp.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=
=3
Finished compiling TRMANIP.NRLIB/TRMANIP.lsp.
------------------------------------------------------------------------
   TranscendentalManipulations is now explicitly exposed in frame
      frame0
   TranscendentalManipulations will be automatically loaded when needed
      from /home/fmy/Atelier/axiom/TRMANIP.NRLIB/code

At the second compilation
> do you have write permisson on the FACTFUNC.erlib file?
Yes this DIRECTORY is rw for me.



\start
Date: Wed, 15 Feb 2006 15:03:54 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: axiom did not compile on sparc solaris

Gaby,

On Wednesday, February 15, 2006 11:04 AM you wrote:
> Bill Page writes:
>
> | If you have some experience with using autoconf
>
> I do.

Excellent! We definitely need your help... :)

> At the moment, I'm bit overloaded but I'm very interested
> to take on the build machinery.
>

I would be glad to work with you and to try to help where I can
provided that you can take the lead and get things started...
of course, whenever you are able.

\start
Date: Wed, 15 Feb 2006 18:40:21 +0100
From: Ralf Hemmecke
To: Francois Maltey
Subject: Re: My second compile command.

>    >> System error:
>    Cannot rename the file #p"FACTFUNC.erlib" to #p"FACTFUNC.NRLIB".

I had a similar error yesterday.
Just quit Axiom and remove the files FACTFUNC.erlib and FACTFUCT.NRLI.
Then restart axiom and compile again.

\start
Date: 16 Feb 2006 09:44:37 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: My second compile command.

Tim Daly writes:

> >  
> >    >> System error:
> >    Cannot rename the file #p"FACTFUNC.erlib" to #p"FACTFUNC.NRLIB".

Since I modify spad code quite a lot, I know this message well. I didn't get
round to write a bug report, though.

It happens always when a compile succeeds and you want to compile a second time
(since you modified the source code, for example)

It did not occur in earlier releases. February 2005 works, for example.

\start
Date: 16 Feb 2006 09:53:01 +0100
From: Martin Rubey
To: Francois Maltey
Subject: Re: My second compile command.

Francois Maltey writes:

> 3/ And now, how can I load my new package ?

)lib TRMANIP

but beware! you have to start axiom in the directory where the newly created
directory TRMANIP.NRLIB resides or, within axiom, change to that directory
using )cd

I often happen to wonder why my wonderful patches don't produce any effect
until I realise that )lib TRMANIP is loading the original package, because I'm
in the wrong directory. :-)

> 4/ Is there in axiom a lot of exemples in order to test if my change break
> nothing ?

Not really. There is a bunch of .input files in the distribution and you could
check whether you find any examples that apply. However, there is --
unfortunately -- no automatic regression testing yet. Big minus for Axiom.

In any case: 

* please write down a few one-line examples which can be integrated in the
  pamphlet files

* write down the formula which you use and give maybe a reference for it

if you need help on "how to write a pamphlet file", just send me the patch and
I'll return a template pamphlet which you will be able to adapt.

Thanks a million times for your effort!

\start
Date: 16 Feb 2006 10:01:04 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: Documentation bug?

Tim Daly writes:

> > Maybe I should have been a bit more precise. I actually already knew 
> > what )abbrev is for. I just forgot the syntax.
> > 
> > As you see the first message tells me:
> > 
> >    Issue )abbrev? for more information.
> > 
> > And if I do that I get a not so helpful message. That was the bug I was 
> > referring to.
> 
> visit src/doc/msgs/s2-us.msgs
> 
> this file contains most (not all, unfortunately) of the messages issued by
> axiom.

The problem is not with the error message issued, but with the routine that
issues it: 

)xx

will give

Your argument list is not valid.

for any nonsensical value of xx. Except if xx is an ambiguous abbrevation, for
example

)c

returns 

   Your command is ambiguous. The following are abbreviated by c :
      cd 
      clear 
      close 
      compiler 
      copyright 
      credits 

or if parameters are missing (:-(

)abb
   If the system command or synonym abbreviations exists, help 
      information is not available for it. Issue )what commands or 
      )what synonyms to determine is abbreviations is a valid name.


\start
Date: 16 Feb 2006 12:42:10 +0100
From: Francois Maltey
To: list
Subject: Re: print or output in packages.

Hello everybody !

I learn a lot with all your mails.

I use to add a lot of spy-print in mysterious functions.
So I add print or output lines as bellow in a test, but I can't compile.

In an *.input file I have no problem with output.

I try the easiest print, with or without coerce ::, with or without $.

      output ("a string"::OutputForm)$OutputPackage
      output (1::OutputForm)$OutputPackage
-- or     print ("num::OutputForm"::OutputForm)$PrintPackage
--      print ("num::OutputForm")$PrintPackage
--      output "den::OutPutForm"


In the manip.spad file there are num and den that I try to print
(in kerexpand about line 790)

      num := numer arg
      den := denom arg

They are perhaps of type : SparseMultivariatePolynomial(R, Kernel $)

1/ How can I print theses variables ?
2/ What function must I use : print or output ?
   What is the difference between.


Now I get error as :

$x:= (output (:: (One) (OutputForm)))
$m:= NoValueMode
$f:=
((((|den| #) (|num| #) (#:G227562 #) (#:G227561 #) ...) ((|simplifyLog1| #)=
 (|logArgs| #)) ((|logArgs| #) (|#| # #) (< # # #) (<= # # #) ...)))

   >> Apparent user error:
   NoValueMode
    is an unknown mode

\start
Date: Thu, 16 Feb 2006 07:40:34 -0500
From: Raymond Rogers
To: list
Subject: groebner?

Could someone tell me if this is wrong; or if it's right why?

-------------------------
list:=[p,Vr,Vt,e]
eq1H:=((-Vr^3+Vr^2)*Vt+Vr^3-Vr^2)*p :: HDMP(list,POLY INT)

Excerpt from an axiom session:

(24) -> eq1H
(24) ->
               3     2        3     2
   (24)  ((- Vr  + Vr )Vt + Vr  - Vr )p
Type:
HomogeneousDistributedMultivariatePolynomial([p,Vr,Vt,e],Polynomial Integer)
(25) -> groebner [eq1H]
(25) ->
   (25)  [p]
Type: List
HomogeneousDistributedMultivariatePolynomial([p,Vr,Vt,e],Polynomial Integer)
-----------------------------

\start
Date: Thu, 16 Feb 2006 10:20:09 -0500
From: Tim Daly
To: Martin Rubey
Subject: Re: Documentation bug?

> > > Maybe I should have been a bit more precise. I actually already knew 
> > > what )abbrev is for. I just forgot the syntax.
> > > 
> > > As you see the first message tells me:
> > > 
> > >    Issue )abbrev? for more information.
> > > 
> > > And if I do that I get a not so helpful message. That was the bug I was 
> > > referring to.
> > 
> > visit src/doc/msgs/s2-us.msgs
> > 
> > this file contains most (not all, unfortunately) of the messages issued by
> > axiom.
> 
> The problem is not with the error message issued, but with the routine that
> issues it: 
> 
> )xx
> 
> will give
> 
> Your argument list is not valid.
> 
> for any nonsensical value of xx. Except if xx is an ambiguous abbrevation, for
> example
> 
> )c
> 
> returns 
> 
>    Your command is ambiguous. The following are abbreviated by c :
>       cd 
>       clear 
>       close 
>       compiler 
>       copyright 
>       credits 
> 
> or if parameters are missing (:-(
> 
> )abb
>    If the system command or synonym abbreviations exists, help 
>       information is not available for it. Issue )what commands or 
>       )what synonyms to determine is abbreviations is a valid name.

ok. i'll try again. perhaps my message was ambiguous or unclear. :-)

this is open source. complaints are interesting but change only happens
if someone writes the change. i'm unlikely to do it for three reasons.
first, i'm pursuing a couple multi-month efforts so i don't have the time.
second, i don't find the error message a problem and
third, some of the errors don't happen to me.

> Since I modify spad code quite a lot, I know this message well.

great, what is the cause? it doesn't happen to me so i can't fix it.

if it doesn't need a fix then it needs documentation. where is the
patch to the axiom documentation volumes?

> Not really. There is a bunch of .input files in the distribution and you could
> check whether you find any examples that apply. However, there is --
> unfortunately -- no automatic regression testing yet. Big minus for Axiom.

great, where is the patch? there is a mechanism that will help with
regression testing. use

   )set message testing on

and when an error occurs you'll get the string:

 "Daly Bug"

in the output (turn it on, type 1+, and watch the output). axiom used
to have regression testing but it died when NAG took over the code. it
is on my list to bring it back but there are other things that also 
need work. (it has my name in the message because i needed a unique
string that would not occur in algebra output and i was the one in
charge of regression testing while it was at IBM, so being lazy i
hardcoded my name).

all of you can program and you have the source. so RUDAP....
read, understand, document, and patch. and then harass me to make
sure it gets added.

a well documented, carefully thought out patch that can be applied
against the latest version of the arch code is much more likely to
effect change.

i'm willing to help but YOU have to code changes YOU care about.

(torvolds wrote a similar message to the linux mailing list and i
thought he was being arrogant at the time but now i realize he was
just very busy)

\start
Date: Thu, 16 Feb 2006 09:50:11 -0500
From: Tim Daly
To: Martin Rubey
Subject: Re: My second compile command.

> >  
> >    >> System error:
> >    Cannot rename the file #p"FACTFUNC.erlib" to #p"FACTFUNC.NRLIB".

> Since I modify spad code quite a lot, I know this message well. I
> didn't get round to write a bug report, though.
 
> It happens always when a compile succeeds and you want to compile a
> second time (since you modified the source code, for example)
 
> It did not occur in earlier releases. February 2005 works, for example.

I compile frequently and have never seen this message.

\start
Date: Thu, 16 Feb 2006 09:04:36 -0600
From: MathAction (Ralf Hemmecke)
To: MathAction
Subject: [FAQ] 

1. **How can I contribute code to Axiom?**

  Look at AxiomDevelopment.

\start
Date: Thu, 16 Feb 2006 16:23:42 +0100
From: Gregory Vanuxem
To: Ralf Hemmecke
Subject: Re: My second compile command.

Hi,

Le mercredi 15 f=E9vrier 2006 =E0 18:40 +0100, Ralf Hemmecke a =E9crit :
> Hi,
>
> >    >> System error:
> >    Cannot rename the file #p"FACTFUNC.erlib" to #p"FACTFUNC.NRLIB".
>
> I had a similar error yesterday.
> Just quit Axiom and remove the files FACTFUNC.erlib and FACTFUCT.NRLI.
> Then restart axiom and compile again.

You don't have to quit and restart axiom, just remove
FACTFUNC.NRLIB

Cheers,

Greg

PS : It's really annoying

\start
Date: Thu, 16 Feb 2006 11:53:37 -0500
From: Bill Page
To: Martin Rubey, Tim Daly
Subject: RE: My second compile command.

On February 16, 2006 3:45 AM Martin Rubey wrote:
> 
> Tim Daly writes:
> 
> > >    >> System error:
> > >    Cannot rename the file #p"FACTFUNC.erlib" to 
> #p"FACTFUNC.NRLIB".
> 
> Since I modify spad code quite a lot, I know this message 
> well. I didn't get round to write a bug report, though.

Now would be a good time to submit one ... :)

  http://wiki.axiom-developer.org/IssueTracker#addissue

> 
> It happens always when a compile succeeds and you want to 
> compile a second time (since you modified the source code,
> for example)
> 
> It did not occur in earlier releases. February 2005 works, 
> for example.
> 

This might be due to a change in the underlying lisp semantics
for PROBE-FILE and TRUENAME that were part of GCL 2.6.7. See:

http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00045.html

This might be another case that was not caught.

\start
Date: 16 Feb 2006 18:46:29 +0100
From: Martin Rubey
To: Francois Maltey
Subject: Re: print or output in packages.

Francois Maltey writes:

> Hello everybody !
> 
> I learn a lot with all your mails.
> 
> I use to add a lot of spy-print in mysterious functions. 
> So I add print or output lines as bellow in a test, but I can't compile.
> 
> In an *.input file I have no problem with output.
> 
> I try the easiest print, with or without coerce ::, with or without $.
> 
>       output ("a string"::OutputForm)$OutputPackage
>       output (1::OutputForm)$OutputPackage
> -- or     print ("num::OutputForm"::OutputForm)$PrintPackage
> --      print ("num::OutputForm")$PrintPackage
> --      output "den::OutPutForm" 

the compiler is picky about spaces between command and argument. Try

        output("a string"::OutputForm)$OutputPackage

instead. In some cases, using trace extensively helps to save you some
work. See HyperDoc or

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

(A hint: if you want to trace local functions, simply move their signatures,
for example

    kerexpand : K -> F

on line 564 of manip.spad

to the set of exported functions, i.e., to line number 551 or so.

Then )tr TRMANIP )ma will catch calls to kerexpand too.

Of course, adding statements like output(bla:OutputForm)$OutputPackage can be
more effective if you already know roughly what should be happening.

\start
Date: Thu, 16 Feb 2006 13:46:49 -0500
From: Tim Daly
To: Francois Maltey
Subject: Re: print or output in packages.

in the top of the algebra files after the initial signature
you'll usually see macros defined. add the line:

 OF ==> OutputForm

then, in the function add:

          print(outputForm("tpdhere")@OF)$OF

and you will see the output printed when the function is called.

\start
Date: Thu, 16 Feb 2006 13:53:53 -0500
From: Bill Page
To: Raymond Rogers
Subject: RE: groebner?

Ray,

On February 16, 2006 7:41 AM

> 
> Could someone tell me if this is wrong; or if it's right why?
> 
> -------------------------
> list:=[p,Vr,Vt,e]
> eq1H:=((-Vr^3+Vr^2)*Vt+Vr^3-Vr^2)*p :: HDMP(list,POLY INT)
> 
> Excerpt from an axiom session:
> 
> (24) -> eq1H
>                3     2        3     2
>    (24)  ((- Vr  + Vr )Vt + Vr  - Vr )p
> Type:
> HomogeneousDistributedMultivariatePolynomial([p,Vr,Vt,e],Polyn
> omial Integer)
> (25) -> groebner [eq1H]
> (25) ->
>    (25)  [p]
> Type: List
> HomogeneousDistributedMultivariatePolynomial([p,Vr,Vt,e],Polyn
> omial Integer)

It might help if you explained what you thought was wrong ... :)
But perhaps this result is what you have in mind?

(5) -> groebnerFactorize [eq1H]

   (5)  [[p],[Vr - 1],[Vr],[Vt - 1]]

Type: List List HomogeneousDistributedMultivariatePolynomial([p,Vr,Vt,e],
Integer)

-----------

Have you read section 9.31 GroebnerFactorizationPackage, page 569,
of the Axiom book? Axiom has several different Groebner packages
optimized for different purposes - all, unfortunately, rather
poorly documented. Some times you can find some useful clues and
comments in the source code:

http://wiki.axiom-developer.org/axiom--test--1/src/algebra/GbSpad
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/GroebfSpad
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/GroebsolSpad
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/LingrobSpad
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/PgrobnerSpad

\start
Date: Thu, 16 Feb 2006 20:16:24 +0100
From: Vanuxem =?ISO-8859-1?Q?Gr=E9gory?= Gregory Vanuxem
To: Francois Maltey
Subject: Re: print or output in packages.

Hi,

I use

 print("I am here")$Lisp
and
 num := numer arg
 print (num::OutputForm)
 den := denom arg
 print (den::OutputForm)


For the error 1 is a function and it's difficult (i  don't know how)
to coerce it (I have previously spoken of this with Bill Page and I
don't really understand why).

> Hello everybody !
>
> I learn a lot with all your mails.
>
> I use to add a lot of spy-print in mysterious functions.
> So I add print or output lines as bellow in a test, but I can't compile=
.
>
> In an *.input file I have no problem with output.
>
> I try the easiest print, with or without coerce ::, with or without $.
>
>       output ("a string"::OutputForm)$OutputPackage
>       output (1::OutputForm)$OutputPackage
> -- or     print ("num::OutputForm"::OutputForm)$PrintPackage
> --      print ("num::OutputForm")$PrintPackage
> --      output "den::OutPutForm"
>
>
> In the manip.spad file there are num and den that I try to print
> (in kerexpand about line 790)
>
>       num := numer arg
>       den := denom arg
>
> They are perhaps of type : SparseMultivariatePolynomial(R, Kernel $)
>
> 1/ How can I print theses variables ?
> 2/ What function must I use : print or output ?
>    What is the difference between.
>
>
> Now I get error as :
>
> $x:= (output (:: (One) (OutputForm)))
> $m:= NoValueMode
> $f:=
> ((((|den| #) (|num| #) (#:G227562 #) (#:G227561 #) ...) ((|simplifyLog1=
| #) (|logArgs| #)) ((|logArgs| #) (|#| # #) (< # # #) (<= # # #) ...))=
)
> 
>    >> Apparent user error:
>    NoValueMode
>     is an unknown mode

\start
Date: 16 Feb 2006 20:24:34 +0100
From: Martin Rubey
To: Raymond Rogers
Subject: Re: groebner?

Raymond Rogers writes:

> Could someone tell me if this is wrong; or if it's right why?

It's wrong, I guess.
 
> list:=[p,Vr,Vt,e]
> eq1H:=((-Vr^3+Vr^2)*Vt+Vr^3-Vr^2)*p :: HDMP(list,POLY INT)

                                                   ^^^^^^^^
                                                   ||||||||

you are saying that the coefficients of your polynomial are polynomials. That's
probably confusing. 
 
> (24) -> eq1H
>                3     2        3     2
>    (24)  ((- Vr  + Vr )Vt + Vr  - Vr )p

>From this output you can deduce that ((-Vr^3+Vr^2)*Vt+Vr^3-Vr^2) is
interpreted as coefficient and p as variable...

Thus the output of

> (25) -> groebner [eq1H]
> (25) ->
>    (25)  [p]

Is correct, in some sense. Although I agree that it is confusing. Try

eq1H := (((-Vr^3+Vr^2)*Vt+Vr^3-Vr^2)*p) :: HDMP(list,INT)

instead. You need the parentheses, because otherwise Axiom will coerce
only p to a HDMP, and eq1H will be of type POLY INT

\start
Date: Thu, 16 Feb 2006 11:26:53 -0800
From: Antoine Hersen
To: list
Subject: Hyper doc search error

Hello,

With a clean install from arch I run into some mirror pb while trying to us=
e
the search facility in Hyperdoc.

mnt/linux/bin/htsearch does not have the exuctable bit set.
mnt/linux/lib/presea does not have the exuctable bit set too.

And presea shabang is #!/bin/awk but on Debian it should be #!/usr/bin/awk

Does the probleme come from some config files ?
Where should I look to fix the problem for future install ?

Thanks
Antoine Hersen

\start
Date: Thu, 16 Feb 2006 14:56:44 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: print or output in packages.

On February 16, 2006 6:42 AM Francois Maltey wrote:
> 
> I use to add a lot of spy-print in mysterious functions. 
> So I add print or output lines as bellow in a test, but I 
> can't compile.
> 
> In an *.input file I have no problem with output.
> 
> I try the easiest print, with or without coerce ::, with or without $.
> 
>       output ("a string"::OutputForm)$OutputPackage
>       output (1::OutputForm)$OutputPackage

You can use this:

output(outputForm("abc")$OutputForm)$OutputPackage
output(outputForm(1)$OutputForm)$OutputPackage

> -- or     print ("num::OutputForm"::OutputForm)$PrintPackage
> --      print ("num::OutputForm")$PrintPackage
> --      output "den::OutPutForm" 
> 
> 
> In the manip.spad file there are num and den that I try to print 
> (in kerexpand about line 790)
> 
>       num := numer arg
>       den := denom arg
> 
> They are perhaps of type : SparseMultivariatePolynomial(R, Kernel $)
> 
> 1/ How can I print theses variables ?
> 2/ What function must I use : print or output ?
>    What is the difference between.
> 

First import OutputForm and OutputPackage near the start of the
file, like this:

  Implementation ==> add

-- for debugging only
    import OutputForm
    import OutputPackage
-- end debugging
    import FactoredFunctions(P)

Now later in the program you can write:

-- for debugging output
      num := numer arg
      den := denom arg
      output(message "num:")
      output(num::OutputForm)
      output(message "den:")
      output(den::OutputForm)
-- end debugging

See for example:

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

\start
Date: 16 Feb 2006 21:33:45 +0100
From: Francois Maltey
To: list
Subject: about Expression Integer

Hello, 

Thanks for previous help, 
now I can compile a package and add spy-print inside !

I play whith expressions and I have theses questions :

1/ Can I (or cannot) remain Expressions as 

x+1/(y+1)             
y+1/(x+1)             

and do not have a single denominator.

2/ Can I go back from (xy+x+1)/(y+1) to x+1/(y+1) ?
Other cas have normal or partfrac fuction, or remain fraction as.

3/ When I expand a trig formula I cut x+1/(y+1) in x and 1/(y+1) 
not in xy/(y+1) and x/(y+1) and 1/(y+1). 

But perhaps my ideas aren't right ?

4/ I'm not sure that the results (xy+x+1)/(y+1) and ((x+1)y+1)/(x+1) 
are fine :

First the order of the variable is important, 
and the user (almost) can't force it, if he uses "n" and "x" variables.

Second the result is longer if the denominator is big.

5/ Of corse there is no problem in expand (cos (4*x+5y)),
but small problems appear with     expand (cos (4*x+5*y/2)) 
and a lot with                     expand (cos (4*x+5*y/(2+t+t^2+t^3))).

What is the better expand in the 3 cases.
Perhaps cos^4 x ... cos^5 y ... 
        cos^4 x ... cos^5 (y/2) ... 
        cos^4 x ... cos^5 (y/(2+t+t^2+t^3)) ... but I'm not sure.


I will be very happy if you can give me your advice, and tell me if
one or an other way of computation is impossible/not natural/too complex 
with axiom. 

\start
Date: Thu, 16 Feb 2006 22:52:40 +0100
From: Ralf Hemmecke
To: Raymond Rogers
Subject: Re: groebner?

Hi Ray,

I think that is correct.
However, I guess, you are asking AXIOM to do the wrong thing.

HDMP(X, R) represents the polynomial ring R[X]. In your case R is
"Polynomial Integer". If you look up "Polynomial" in Hyperdoc, you will
find that this is a domain that allows any symbol as a variable and
Integers as coefficients. Roughly speaking, it is Z[Y] (where Y is a
infinitely set of variables).

If the groebner routine is given something of the form Z[Y][X] where
Z[Y] is the coefficient domain then the result has to be interpreted in
Z(Y)[X] (the fraction field of the coefficients ajoint with the
variables from the set X).

Unfortunately, in the way you coerce your polynomials X is a subset of
Y. In other words the polynomial eq1H lies in the ring of coefficients
and is therefore a constant.

Well, computing a Gr=F6bner basis of a non-zero constant always gives the=

ideal generated by 1. So I would have expected [1] as an output. But [p] =

is also correct, since p is an element of Z(Y) and, therefore,
invertible. p generates the same ideal as 1 and that is equal to the
whole ring Z(Y)[X].

You see, be careful with Polynomial(Integer). The interpreter is not as
smart as you may wish in this case. However, you could help by adding
the right types.

list: List(Symbol) :=[p,Vr,Vt,e]
eq: HDMP(vars, INT) := ((-Vr^3+Vr^2)*Vt+Vr^3-Vr^2)*p
groebner [eq]

The result is the same as [eq] which is to be expected if you just give
one polynomial.

Ralf

On 02/16/2006 01:40 PM, Raymond E. Rogers wrote:
> Could someone tell me if this is wrong; or if it's right why?
>
> -------------------------
> list:=[p,Vr,Vt,e]
> eq1H:=((-Vr^3+Vr^2)*Vt+Vr^3-Vr^2)*p :: HDMP(list,POLY INT)
>
> Excerpt from an axiom session:
>
> (24) -> eq1H
> (24) ->
>                3     2        3     2
>    (24)  ((- Vr  + Vr )Vt + Vr  - Vr )p
> Type:
> HomogeneousDistributedMultivariatePolynomial([p,Vr,Vt,e],Polynomial Int=
eger)
> (25) -> groebner [eq1H]
> (25) ->
>    (25)  [p]
> Type: List
> HomogeneousDistributedMultivariatePolynomial([p,Vr,Vt,e],Polynomial Int=
eger)
> -----------------------------

\start
Date: Thu, 16 Feb 2006 18:04:57 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

\begin{axiom}
integrate((%e -2x)sin  3x, x)
\end{axiom}

\start
Date: Fri, 17 Feb 2006 00:09:09 -0500
From: Tim Daly
To: Antoine Hersen
Subject: Re: Hyper doc search error

> mnt/linux/bin/htsearch does not have the exuctable bit set.
> mnt/linux/lib/presea does not have the exuctable bit set too.

these two problems will be fixed in the next release.


> And presea shabang is #!/bin/awk but on Debian it should be #!/usr/bin/awk
> 
> Does the probleme come from some config files ?
> Where should I look to fix the problem for future install ?

it's not clear how to fix this problem because axiom has no control 
over where awk lives. 

i'm open to suggestions about how to fix this.

\start
Date: 17 Feb 2006 09:35:53 +0100
From: Martin Rubey
To: Francois Maltey
Subject: Re: about Expression Integer

Part of this email will become part of MathAction in a minute...

> 1/ Can I (or cannot) remain Expressions as
> 
> x+1/(y+1)
> y+1/(x+1)
> 
> and do not have a single denominator.

Well, I need to explain several things here:

* How can I affect the way Axiom displays its results?

Whenever Axiom needs to write an element of a domain, i.e., an expression from
Expression Integer, a number from PrimeField 5, a factored polynomial from
Factored Polynomial Fraction Integer, etc., to the screen, it calls the
operation with the signature 'coerce: % -> OutputForm' from that domain.

For example, to output a polynomial in factored form, the "real" way to do it
is to coerce it into the domain Factored Polynomial Integer:

                                                                Type: Boolean
(6) -> x^2-y^2

           2    2
   (6)  - y  + x
                                                     Type: Polynomial Integer
(7) -> (x^2-y^2)::Factored Polynomial Integer

   (7)  - (y - x)(y + x)
                                            Type: Factored Polynomial Integer

Thus, philosophically, the way things are output depends only on the domain,
and if we want to implement a different way, we need to implement a new
domain. This is very easy, see SandBoxDistributedExpression.

* How does this work in Polynomial Integer, Expression Integer?

The domain EXPR INT contains expressions in the form p/q where p and q are
polynomials -- with the variables being the "kernels" -- and the polynomials
are displayed in the same form as in POLY INT, which is unfortunately slightly
confusing. Roughly: "larger" variables are factored out:

(29) -> z*x+x

   (29)  x z + x
                                                     Type: Polynomial Integer
(30) -> z*x+z

   (30)  (x + 1)z
                                                     Type: Polynomial Integer

since "z" is "larger" than "x". Of course, "larger" is simply a rather
arbitrary, but fortunately fixed internal order of the variables. For
Expressions, this order is not even fixed, I think, but I might be wrong here.
In fact, this ordering is the thing about axiom that I hate most, I don't
really want it to say:

(4) -> tan x > sin x

   (4)  true
                                                                Type: Boolean
(5) -> tan x > sin y

   (5)  true
                                                                Type: Boolean

although I got used to it...

* Can I go back from (xy+x+1)/(y+1) to x+1/(y+1) ?  Other cas have normal or
  partfrac fuction, or remain fraction as.

As follows from the above, this currently cannot be done within the domain EXPR
INT. I think that there are several possibilities, which I will explain on an
old example, the problem of displaying expressions in "fully expanded" form:

* one can write a domain which only overrides the output functionality, and
  applies the simplifications every time the element is written on the
  screen. That's what I have done for DistributedExpression. This is the quick
  and dirty way.

* one writes a new domain with a new representation. For
  'DistributedExpression' I failed to do so, since the proper representation
  would be 'DMP', but this only accepts a 'List Symbol' as variables, for
  expressions I need to allow an arbitrary 'OrderedSet' however.

* one abstracts the form and writes a new functor, as for example
  'Factored'. I'm not quite sure, but it may be that a functor 'Distributed'
  would be the best solution. I would have to look why the original developers
  chose to implement 'DistributedMultivariatePolynomials' instead.

So, the conclusion is that you might want to write a function first that takes
- for example - an expression and returns a list of expressions. It would be
easy to make this into a new domain "MyExpression". I vaguely recall that
Maxima has such a function.

> 3/ When I expand a trig formula I cut x+1/(y+1) in x and 1/(y+1)
> not in xy/(y+1) and x/(y+1) and 1/(y+1).
> 
> But perhaps my ideas aren't right ?
> 
> 4/ I'm not sure that the results (xy+x+1)/(y+1) and ((x+1)y+1)/(x+1)
> are fine :
 
> First the order of the variable is important, and the user (almost) can't
> force it, if he uses "n" and "x" variables.  Second the result is longer if
> the denominator is big.

yes, I also think that the way POLY INT works is unsatisfactory. However, there
is DMP, which remedies the situation.

> 5/ Of corse there is no problem in expand (cos (4*x+5y)),
> but small problems appear with     expand (cos (4*x+5*y/2))
> and a lot with                     expand (cos (4*x+5*y/(2+t+t^2+t^3))).
> 
> What is the better expand in the 3 cases.
> Perhaps cos^4 x ... cos^5 y ...
>         cos^4 x ... cos^5 (y/2) ...
>         cos^4 x ... cos^5 (y/(2+t+t^2+t^3)) ... but I'm not sure.

I believe that usually, it is difficult to decide what's "better". I'd rather
have various operations or domains which all have a clear effect. So, maybe you
just write one operation that fully expands, another one that does something
else, and so on.

The very best thing would be, in my opinion, if you'd devise a domain which
is specially suited for trigonometric functions. I think that devising a really
good expression domain is very complex. Although I must say that I like MuPAD's
very much.

\start
Date: Fri, 17 Feb 2006 02:35:07 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [AxiomOutputFormatting] 

In this particular case you have to say

Here are some more detailed explanations:

How can I affect the way Axiom displays its results?

    Whenever Axiom needs to write an element of a domain, i.e., an expression from
'Expression Integer', a number from 'PrimeField 5', a factored polynomial from
'Factored Polynomial Fraction Integer', etc., to the screen, it calls the
operation with the signature 'coerce: % -> OutputForm' from that domain.

For example, to output a polynomial in factored form, the "real" way to do it
is to coerce it into the domain Factored Polynomial Integer:

\begin{axiom}
x^2-y^2
(x^2-y^2)::Factored Polynomial Integer
\end{axiom}

Thus, philosophically, the way things are output depends only on the domain,
and if we want to implement a different way, we need to implement a new
domain. This is very easy, see SandBoxDistributedExpression.

How does this work in 'Polynomial Integer', 'Expression Integer'?

    The domain 'EXPR INT' contains expressions in the form p/q where p and q are
polynomials -- with the variables being the "kernels" -- and the polynomials
are displayed in the same form as in 'POLY INT', which is unfortunately slightly
confusing. Roughly: "larger" variables are factored out:

\begin{axiom}
z*a+a
z*a+z
\end{axiom}

since "z" is "larger" than "a". Of course, "larger" is simply a rather
arbitrary, but fortunately fixed internal order of the variables. For
Expressions, this order is not even fixed, I think, but I might be wrong here.
In fact, this ordering is the thing about axiom that I hate most, I don't
really want it to say:

\begin{axiom}
tan x > sin x
tan x > sin y
\end{axiom}

although I got used to it...

Can I make Axiom display $(xy+x+1)/(y+1)$ as $x+1/(y+1)$?

    As follows from the above, this currently cannot be done within the domain 'EXPR INT'. I think that there are several possibilities, which I will explain on an
old example, the problem of displaying expressions in "fully expanded" form:

* one can write a domain which only overrides the output functionality, and
  applies the simplifications every time the element is written on the
  screen. That's what I have done for DistributedExpression. This is the quick
  and dirty way.

* one writes a new domain with a new representation. For
  'DistributedExpression' I failed to do so, since the proper representation
  would be 'DMP', but this only accepts a 'List Symbol' as variables, for
  expressions I need to allow an arbitrary 'OrderedSet' however.

* one abstracts the form and writes a new functor, as for example
  'Factored'. I'm not quite sure, but it may be that a functor 'Distributed'
  would be the best solution. I would have to look why the original developers
  chose to implement 'DistributedMultivariatePolynomials' instead.

So, the conclusion is that you might want to write a function first that takes
- for example - an expression and returns a list of expressions. It would be
easy to make this into a new domain "MyExpression". I vaguely recall that
Maxima has such a function.

\start
Date: Fri, 17 Feb 2006 04:35:41 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#269 some issues with the 'Factored' domain]

Consider the following:
\begin{axiom}
q:FR POLY INT := (x-1)*(x^2+1)
p:FR POLY INT := (x-1)*(2*x)
p+q
)tr MULTFACT )ma
factor(p+q)
\end{axiom}

The documentation says:

Others, like addition require somewhat more work, and unless the argument domain provides a factor function, the result may not be completely factored.

which is not true, as shown by the result of $p+q$ above.

Furthermore, applying 'factor' to $p+q$ should probably not first expand the expression and then factor it again. It should rather map over the already known factors.

I'm not sure whether 'FR' should always try to factor the result of an addition, at least, I don't think that this was the intention of the original author.

Another issue is raised by the documentation to 'expand: % -> R':

'expand(f)' multiplies the unit and factors together, yielding an "unfactored" object. Note: this is purposely not called 'coerce' which would cause the interpreter to do this automatically.

I tested this and found it not to be true. Note that the domain was written already in 1985, so it might well be that the interpreters behaviour has changed in this respect.

Martin

\start
Date: Fri, 17 Feb 2006 04:41:20 -0600
From: MathAction (kratt6)
To: MathAction
Subject: [#269 some issues with the 'Factored' domain] 

The documentation says::

  Others, like addition require somewhat more work, and unless 
  the argument domain provides a factor function, the result 
  may not be completely factored.

Another issue is raised by the documentation to 'expand: % -> R' ::

  expand(f) multiplies the unit and factors together, yielding an
  "unfactored" object. Note: this is purposely not called 'coerce' which would
  cause the interpreter to do this automatically.

\start
Date: Fri, 17 Feb 2006 11:15:02 +0100
From: David Mentre
To: Tim Daly
Subject: Re: Hyper doc search error

Hello Tim,

2006/2/17, Tim Daly:
[ about the correct path to awk binary ]
> i'm open to suggestions about how to fix this.

A suggestion: use a ./configure that look for those binaries and write
the Makefile.

Suggestion for the one who would like to tackle this issue: you'll
find in http://www.linux-france.org/~dmentre/demexp/latest-src/demexp--dev-=
-0.7.tar.gz
a configure script written from scratch. It is under GPL license but,
as the unique author of that code, I give permission to any coder of
Axiom project to reuse it under Axiom's BSD-like license.

----searchpath shell script (don't know where it comes from)------
#!/bin/sh
# Find a program in the path

IFS=':'
for dir in $PATH; do
  if test -z "$dir"; then dir=.; fi
  if test -f $dir/$1; then exit 0; fi
done
exit 1
-----------------------

It could be used like this:

# do we have ocaml?
echo -n "Looking for ocamlc... "
if sh ./searchpath ocamlc; then
    echo "found";
else
    echo "not found";
    echo "*** OCaml compiler is required for compilation";
    echo "*** Please install the package or compile following
instructions found";
    echo "*** in README. Source archive available at";
    echo "***   http://caml.inria.fr/ocaml/distrib.html";
    exit 2;
fi

It would be better if searchpath would return the found path. Here is
a modified searchpath that does this :

#!/bin/sh
# Find a program in the path and prints its location if found

IFS=':'
for dir in $PATH; do
  if test -z "$dir"; then dir=.; fi
  if test -f $dir/$1; then echo $dir/$1; exit 0; fi
done
exit 1


It should be used like this:

#!/bin/sh

# do we have awk?
echo -n "Looking for awk... "
awk_path=`./searchpath awk`
if [ $? == 0 ]; then
    echo "found: $awk_path";
else
    echo "not found";
    echo "*** Awk is required for compilation";
    echo "*** Please install it";
    exit 2;
fi


\start
Date: Fri, 17 Feb 2006 14:19:44 +0100
From: Ralf Hemmecke
To: Tim Daly
Subject: Re: Hyper doc search error

Tim,

at compilation time it should be known whether one uses awk, gawk, or 
nawk and in which directory they live. My suggestion would be to 
generate a link (for example, ln -s /bin/awk $AXIOM/bin). Then use

#!./awk

in the first line of the file.

Or remove #!/bin/awk -f from presea and name the resulting file presea.awk

At compile time you generate a file "presea" with the following content:

#!/bin/sh
exec /path/to/[gn]?awk -f presea.awk


Oh, now I am just a bit curious. With all these paths it sounds like 
Axiom isn't running natively on Windows. Does one always need MinGW? 
(I'm not using it anyway, but just for curiosity...)


On 02/17/2006 06:09 AM, root wrote:
>> mnt/linux/bin/htsearch does not have the exuctable bit set.
>> mnt/linux/lib/presea does not have the exuctable bit set too.
> 
> these two problems will be fixed in the next release.
> 
> 
>> And presea shabang is #!/bin/awk but on Debian it should be #!/usr/bin/awk
>>
>> Does the probleme come from some config files ?
>> Where should I look to fix the problem for future install ?
> 
> it's not clear how to fix this problem because axiom has no control 
> over where awk lives. 
> 
> i'm open to suggestions about how to fix this.
> 

\start
Date: Fri, 17 Feb 2006 09:52:56 -0500
From: Bill Page
To: Tim Daly
Subject: RE: Hyper doc search error

On February 17, 2006 12:09 AM Tim Daly (root) wrote:
> ... 
> Antoine Hersen wrote:
> > And presea shabang is #!/bin/awk but on Debian it should be 
> #!/usr/bin/awk
> > 
> > Does the probleme come from some config files ?
> > Where should I look to fix the problem for future install ?
> 
> it's not clear how to fix this problem because axiom has no
> control over where awk lives. 
> 
> i'm open to suggestions about how to fix this.
> 

I think the proper way to fix this (and most other configuration
problems) would be to develop a standard autoconf script for
Axiom, then ./configure would take of these details.

Gaby said recently that he was interested in working on this.

\start
Date: Fri, 17 Feb 2006 18:25:51 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: about Expression Integer

On February 16, 2006 3:34 PM Francois Maltey wrote:
> ... 
> I play with expressions and I have theses questions :
>

In contrast to most other computer algebra systems, in Axiom
the concept of an 'expression' is not a fundamental idea.
Rather the concept of 'domain' comes first. I think some of
your questions are related to this different point of view.
 
> 1/ Can I (or cannot) remain Expressions as 
> 
> x+1/(y+1)             
> y+1/(x+1)             
> 
> and do not have a single denominator.
>

It is possible to do this in several ways. If you do not tell
Axiom anything else, it will interpret your expression as
a member of the domain 'Fraction Polynomial Integer'. That
is why it appears like this:

(1) -> (x+1/(y+1))

        x y + x + 1
   (1)  -----------
           y + 1
   Type: Fraction Polynomial Integer

This is the first domain that the interpreter finds in which
it can accurately represent your expression, so the expression
is converted to this domain and the result is displayed as you
see above. But notice that your original expression is not a
member of this domain.

There are however more complex domains which do include
expressions of the same form as you wrote above. The interpreter
is not able to find these automatically, but you can help by
specifying more exactly what you want. In the compiler you must
always provide this additional information. For example:

(2) -> (x+1/(y+1))$DMP([x,y],EXPR INT)

              1
   (2)  x + -----
            y + 1
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

(3) -> (y+1/(x+1))$DMP([x,y],EXPR INT)

              1
   (3)  y + -----
            x + 1
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

DMP is the abbreviation for DistributedMultivariatePolynomial. EXPR
is the abbreviation for Expression and of course INT is the abbreviation
for Integer.

In this case your expression is a member of the specified domain and
no conversion is necessary, but notice that the 2nd term is a monomial
of degree 0 since this domain has coefficients that can be expressions.
You might consider this result ambiguous since the entire expression
could be consider a term degree 0, but apparently the domain DMP
attempts construct a polynomial of highest degree? To know for sure
we would probably have to consult the source code for DMP.

I am not sure if this is exactly what you want or what you need as I
will explain below. 
 
> 2/ Can I go back from (xy+x+1)/(y+1) to x+1/(y+1) ?
> Other cas have normal or partfrac fuction, or remain fraction as.
>

Yes. For example:

(4) -> (%%(1)::EXPR INT)::DMP([x,y],EXPR INT)

               1
   (4)  x + -----
             y + 1
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
 
> 3/ When I expand a trig formula I cut x+1/(y+1) in x and 1/(y+1) 
> not in xy/(y+1) and x/(y+1) and 1/(y+1). 
> 
> But perhaps my ideas aren't right ?

I am not sure I understand your use of English. Perhaps you mean
you would like to write:

   sin(%%(2))

but unfortunately there is not domain in Axiom right now of which
this expression would be a member. The command ')di op sin' shows
that 'sin' is only defined over domains in the category TRIGCAT.

But this does not mean that you cannot write a function which
performs this expansion. E.g.

(5) -> monomials((%%(1)::EXPR INT)::DMP([x,y],EXPR INT))

              1
   (5)  [x,-----]
            y + 1
   Type: List DistributedMultivariatePolynomial([x,y],Expression Integer)

> 
> 4/ I'm not sure that the results (xy+x+1)/(y+1) and
> ((x+1)y+1)/(x+1) are fine :
> 
> First the order of the variable is important, and the user
> (almost) can't force it, if he uses "n" and "x" variables.
> 
> Second the result is longer if the denominator is big.
>

Obviously these results are "fine" in the sense that the expressions
belong to the domain 'Fraction Polynomial Integer' which is the
domain that the Axiom interpreter chooses by default. Other results
are possible, as I showed above.
 
> 5/ Of course there is no problem in expand (cos (4*x+5y)),
> but small problems appear with     expand (cos (4*x+5*y/2)) 
> and a lot with                     expand (cos 
> (4*x+5*y/(2+t+t^2+t^3))).
> 
> What is the better expand in the 3 cases.
> Perhaps cos^4 x ... cos^5 y ... 
>         cos^4 x ... cos^5 (y/2) ... 
>         cos^4 x ... cos^5 (y/(2+t+t^2+t^3)) ... but I'm not sure.
> 

Yes, I agree with this.

> 
> I will be very happy if you can give me your advice, and tell
> me if one or an other way of computation is impossible/not
> natural/too complex with axiom. 
> 

I certainly don't think it is too complicated for axiom. To
understand how to use and especially how to program in Axiom
it is necessary to take a quite different view than in most
other computer algebra systems.

Fundamentally, Axiom is "object-oriented". This means that we
must think not about the objects (expressions) themselves but
rather about to what domain they belong. The domain determines
what operations can be performed on it's members. So if you
just write:

  x+1/(y+1)

you do not yet have something on which you can operate because
you have not said to which domain it belongs.

One of the important operations defined for almost all domains
is the coercion from that domain to the special domain called
OutputForm. This is the operation that determines how the members
of the domain will appear as output. But keep in mind that how
something appears in output does not directly relate to how it
is represented internally.

Conversions and coercions are very important in Axiom because
they allow you to find equivalent members of other domains that
may include operations of the type that you wish to perform.

To make these operations more "natural" in Axiom it is sometimes
necessary to create new domains. Martin Rubey's reply presents
this idea in more detail.

I hope this is some help.

\start
Date: 18 Feb 2006 10:27:42 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: about Expression Integer

Bill Page writes:

> There are however more complex domains which do include expressions of the
> same form as you wrote above. The interpreter is not able to find these
> automatically, but you can help by specifying more exactly what you want. In
> the compiler you must always provide this additional information. For
> example:
> 
> (2) -> (x+1/(y+1))$DMP([x,y],EXPR INT)
> 
>               1
>    (2)  x + -----
>             y + 1
>    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)


This is very dangerous!

> 
> (3) -> (y+1/(x+1))$DMP([x,y],EXPR INT)
> 
>               1
>    (3)  y + -----
>             x + 1
>    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

DON'T!

> but notice that the 2nd term is a monomial of degree 0 since this domain has
> coefficients that can be expressions.  You might consider this result
> ambiguous since the entire expression could be consider a term degree 0, but
> apparently the domain DMP attempts construct a polynomial of highest degree?

This has been thourougly discussed, see 

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

and the threads mentioned therein.

The main problem you will encounter with the expression above is that you are
really introducing two *different* variables x, so, some time later you may
have Axiom saying x <> x.

The construction above somehow works if you can make sure that your sets of
variables are separated, i.e., when the coefficients contain variables
a,b,c,... and the variables of the polynomial are x,y,z. This is clearly not
the case above.

\start
Date: Sat, 18 Feb 2006 06:56:34 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#270 integrating UTS] (new) integrating UTS

Update of bug #10350 (project axiom):

                  Status:                    None => transferred            
Example of code trigerring the bug: integrate((1/x)::UTS(FRAC POLY INT, x,
0),x)
integrate((1/y)::UTS(FRAC POLY INT, x, 0),z) => integrate((1/x)::UTS(FRAC
POLY INT, x, 0),x)
integrate((1/y)::UTS(FRAC POLY INT, x, 0),z)

\start
Date: Sat, 18 Feb 2006 09:06:06 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: about Expression Integer

On February 18, 2006 4:28 AM Martin Rubey wrote:
> 
> Bill Page writes:
> 
> > There are however more complex domains which do include 
> > expressions of the same form as you wrote above. The
> > interpreter is not able to find these automatically, but
> > you can help by specifying more exactly what you want. In
> > the compiler you must always provide this additional
> > information. For example:
> > 
> > (2) -> (x+1/(y+1))$DMP([x,y],EXPR INT)
> > 
> >               1
> >    (2)  x + -----
> >             y + 1
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> 
> This is very dangerous!
>

No. I think you are confusing a "bug" with a "feature" here. You can
see this "danger" more clearly in the following simple example:

(1) -> ex1:=(x+1/x)$DMP([x,y],EXPR INT)

            1
   (1)  x + -
            x
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

(2) -> ex2:=ex1*x

         2   1
   (2)  x  + - x
             x
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

The second term in (2) is obviously unexpected. The reason is that
Axiom interprets the 'x' in '1/x' that occurs in the coefficient as
a different 'x' than the 'x' that occurs as a variable of the
polynomial. Axiom is continuing to make the distinction between the
use of variables that is allowed in this domain. This is a perfectly
reasonable expression as it stands - it is just not as simple as we
might expect.

But when we ask Axiom to consider this expression as a member of
the 'Expression Integer' domain, we get the simple result that we
probably expected:

(3) -> ex2::EXPR INT

         2
   (3)  x  + 1
   Type: Expression Integer

So this is not really "dangerous" in the way I think you meant
above.

> > 
> > (3) -> (y+1/(x+1))$DMP([x,y],EXPR INT)
> > 
> >               1
> >    (3)  y + -----
> >             x + 1
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> DON'T!
>

Do you mean do not do this in order to avoid unexpected results?
Or do you mean never. If the latter, than I disagree strongly.
 
> > but notice that the 2nd term is a monomial of degree 0 
> > since this domain has coefficients that can be expressions.
> > You might consider this result ambiguous since the entire
> > expression could be consider a term degree 0, but apparently
> > the domain DMP attempts construct a polynomial of highest
> > degree?
> 
> This has been thoroughly discussed, see 
> 
> http://wiki.axiom-developer.org/WhereDoVariablesBelong
> 
> and the threads mentioned therein.
>

I have reviewed the discussion again, and I think the conclusions
might be wrong. I am not convinced that this is a bug in the way
Axiom works or design flaw even though the behaviour is radically
different than most other computer algebra systems. In Axiom you
have to be very careful about when and where you test for the
equality of two things.
 
> The main problem you will encounter with the expression above 
> is that you are really introducing two *different* variables
> x, so, some time later you may have Axiom saying x <> x.

No that is not true as expression (3) above illustrates.

> 
> The construction above somehow works if you can make sure 
> that your sets of variables are separated, i.e., when the
> coefficients contain variables a,b,c,... and the variables
> of the polynomial are x,y,z. This is clearly not the case
> above.
> 

No it is not necessary that the variables be separated, but it
is necessary to remain focused on the domain to which a given
expression belongs. This is one of the features that distinguishes
Axiom from more "primitive" computer algebra systems.

\start
Date: Sat, 18 Feb 2006 10:23:41 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Where do variables belong?] 

I think that this is calling for trouble, see issue #270. There are
two ways to fix this:

\start
Date: Sat, 18 Feb 2006 10:35:26 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#270 integrating UTS] (new) integrating UTS

Originally Savannah bug 10350.

Example of code trigerring the bug:
\begin{axiom}
integrate((1/x)::UTS(FRAC POLY INT, x,0),x)
\end{axiom}
Result::

  Cannot find a definition or applicable library operation named
  integrate with argument type(s)
  UnivariateTaylorSeries(Fraction Polynomial Integer,x,0)
  Variable z

The first bug is an indication that '1/x' should not be of type
'UTS(x, FRAC POLY INT)', 'UP(x, FRAC POLY INT)' and so on. The
second is an indication that QFCAT should have a function
'variables: % -> List Symbol'.

**Sat 10/02/04 at 08:09, comment #2:**

I disagree with the previous comment; x should be captured and
not allowed in the FRAC POLY INT. (I agree that the second example
in the original report is not a bug.)

But surely we can all agree that
'integrate((1/x)::ULS(FRAC POLY INT, x, 0),x)'
is a bug? The problem is the same: the '1/x' is being treated in
the coefficient domain. Note that
'integrate(1/(x::ULS(FRAC POLY INT, x, 0)),x)'
produces a correct result.

Dylan (dpt@math.harvard.edu)

**Sat 10/02/04 at 04:33, comment #1:**

Neither of these is a bug. In the first one, Axiom coerced
'1/x' into 'FRAC POLY INT' correctly: the only / operation
available in UTS is one induced from the coefficient domain,
which requires the denominator to be in the coefficient domain,
and the division is done termwise to the coefficients of the
series. So '1/x' ends up in 'FRAC POLY INT'. Note that to
obtain a Taylor series at 'x = 0' is mathematically is wrong,
since '1/x' is not defined at 'x=0'. Also the way to obtain a
Taylor series is 'taylor(func, x=a)'. If you do
'integrate(taylor(1/x,x=1),x)', that would cause no problems.

Note that the domain of this command is 'UTS(EXPR INT, x,1)',
so such towers are valid and necessary in Axiom. Note also
there are only two 'exported[coerce]' in UTS and they do NOT
apply to '1/x'. The 'x' in UTS is like the 'x' in UP and is
different from the 'x' in 'FRAC POLY INT'. The representation
is 'Stream Coef' (no variable specified because it is univariate).

For the same reason, in the second command, '1/y' is correctly
coerced into 'FRAC POLY INT'. However, in 'UTS(*,x,*)', the only
integrations allowed are with respect to 'x'. If you want to do
integration in 'FRAC POLY INT', then you should do so without
coercing '1/y' into UTS.

So your examples do not illustrate the problem about mixed up
variables. In fact, it supports use of towers like
'UTS(EXPR INT, x, a)'.

\start
Date: Sat, 18 Feb 2006 11:10:38 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [#270 integrating UTS] not a bug

The result is a series:
\begin{axiom}
integrate((1/x)::ULS(FRAC POLY INT, x, 0),x)
\end{axiom}
It is finite so we can represent it as a polynomial:
\begin{axiom}
univariatePolynomial(%,1)
\end{axiom}
This domain distinquishes between 'x' as a monomial and '1/x' as
a coefficient, but in a simpler domain they will cancel:
\begin{axiom}
%::FRAC POLY INT
\end{axiom}

\start
Date: Sat, 18 Feb 2006 20:37:02 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

>> 1/ Can I (or cannot) remain Expressions as 
>>
>> x+1/(y+1)             
>> y+1/(x+1)             
>>
>> and do not have a single denominator.

Unfortunately, I have no idea, how to do this. :-(

But, I'd like to warn you. Don't follow Bill's suggestion.

> There are however more complex domains which do include
> expressions of the same form as you wrote above. The interpreter
> is not able to find these automatically, but you can help by
> specifying more exactly what you want. In the compiler you must
> always provide this additional information. For example:
> 
> (2) -> (x+1/(y+1))$DMP([x,y],EXPR INT)
> 
>               1
>    (2)  x + -----
>             y + 1
>    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

> In this case your expression is a member of the specified domain and
> no conversion is necessary, but notice that the 2nd term is a monomial
> of degree 0 since this domain has coefficients that can be expressions.
> You might consider this result ambiguous since the entire expression
> could be consider a term degree 0, but apparently the domain DMP
> attempts construct a polynomial of highest degree? To know for sure
> we would probably have to consult the source code for DMP.

Right. In order to know what will happen, a user would have to consult
the source code. That's completely unsatisfactory.

Even more, I think the interpreter should forbid to construct things
like DistributedMultivariatePolynomial([x,y],Expression Integer).

Take, for example (axiom--main--1--patch-47)

P := DistributedMultivariatePolynomial([x,y],Expression Integer)
a: P := x
degree a

Are you sure that you expected

[1,0]
       Type: DirectProduct(2,NonNegativeInteger)

as output, given the fact that x is an element of the coefficient domain?

Now, it is totally clear that

degree(a/x)

also gives

[1,0]
       Type: DirectProduct(2,NonNegativeInteger)

since

a/x

         1
    (5)  - x
         x
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

yields also a completely correct output. ;-) However, I guess, most
people find this confusing.

\start
Date: Sat, 18 Feb 2006 20:36:35 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

> Conversions and coercions are very important in Axiom because
> they allow you to find equivalent members of other domains that
> may include operations of the type that you wish to perform.

Is there a big difference between "conversion" and "coercion"?

\start
Date: 19 Feb 2006 17:31:25 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Hyper doc search error

Bill Page writes:

| On February 17, 2006 12:09 AM Tim Daly (root) wrote:
| > ... 
| > Antoine Hersen wrote:
| > > And presea shabang is #!/bin/awk but on Debian it should be 
| > #!/usr/bin/awk
| > > 
| > > Does the probleme come from some config files ?
| > > Where should I look to fix the problem for future install ?
| > 
| > it's not clear how to fix this problem because axiom has no
| > control over where awk lives. 
| > 
| > i'm open to suggestions about how to fix this.
| > 
| 
| I think the proper way to fix this (and most other configuration
| problems) would be to develop a standard autoconf script for
| Axiom, then ./configure would take of these details.

Agreed.

| Gaby said recently that he was interested in working on this.

yup.  I'm currently on road with my parents-in-law so I can't do as
much as I would want right now.  I looked at the toplevel configure
and build machinery last night and we can definitely improve things 
here :-)  

I'm curiious of why gmake, gtar and gpatch are required on solaris
boxes.  

I'm also curious as to what extent the autoconf/automake machinery
will blend with Axiom's pamplet style.

\start
Date: Sun, 19 Feb 2006 12:36:40 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: Hyper doc search error

> I'm also curious as to what extent the autoconf/automake machinery
> will blend with Axiom's pamplet style.

likely not at all.

i tried to use the tools but found that they are very, very C specific.
we could probably steal the platform recognition routines and possibly
find a way to solve the awk/gawk/nawk issue but i'd be amazed if there
was a way to handle axiom (or any large lisp project) using automake.

my long term plan is to push almost everything into ansi common lisp
and use asdf.

that said, i admit that the configure shell script is complete trash.
i'm not familiar with the 99 ways of recognizing platforms or finding
awk/gawk/nawk, etc. and it NEEDS fixing. any effort on this would be
a big win.

\start
Date: Sun, 19 Feb 2006 12:09:18 -0500
From: Bill Page
To: Tim Daly, Gabriel Dos Reis
Subject: RE: Hyper doc search error

On February 19, 2006 12:37 PM Tim Daly (root) wrote:
> 
> Gaby wrote: 
> > I'm also curious as to what extent the autoconf/automake machinery
> > will blend with Axiom's pamplet style.
> 
> likely not at all.
> 

I disagree.

> i tried to use the tools but found that they are very, very C 
> specific. we could probably steal the platform recognition routines

Yes, that is the essential part.

> and possibly find a way to solve the awk/gawk/nawk issue but i'd be
> amazed if there was a way to handle axiom (or any large lisp project)
> using automake.

I don't think there is any problem here.

> 
> my long term plan is to push almost everything into ansi common lisp
> and use asdf.

You already know that I think that would be a MAJOR mistake.

> 
> that said, i admit that the configure shell script is complete
> trash. i'm not familiar with the 99 ways of recognizing platforms or
> finding awk/gawk/nawk, etc. and it NEEDS fixing. any effort on this
> would be a big win.
> 

\start
Date: Sun, 19 Feb 2006 12:06:05 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: about Expression Integer

On February 18, 2006 2:37 PM Ralf Hemmecke wrote:
> 
> >> 1/ Can I (or cannot) remain Expressions as 
> >>
> >> x+1/(y+1)             
> >> y+1/(x+1)             
> >>
> >> and do not have a single denominator.
> 
> Unfortunately, I have no idea, how to do this. :-(
>

It is obvious, isn't it, that to do this is Axiom you *must*
find a domain of which this expression can be a member?
 
> But, I'd like to warn you. Don't follow Bill's suggestion.
>

I think it is strange how confident both of us are in the
opposite opinion. :)

I don't think you have shown any flaw in my suggestion. It seems
to me to be very reasonable solution to the problem originally
posed by Francois. In fact this same approach is used on other
parts of Axiom.

Perhaps your concern arises because you have not worked out
completely how Axiom uses the concept of domain. I know that
you understand this idea in some depth because of your background
with Aldor. As a programmer and a long term user of Maple, I
had, perhaps, a similar background, but it has taken me more
than two year of working with Axiom to really understand (at
least I think I now understand :) how it is applied to mathematics.

> > There are however more complex domains which do include
> > expressions of the same form as you wrote above. The interpreter
> > is not able to find these automatically, but you can help by
> > specifying more exactly what you want. In the compiler you must
> > always provide this additional information. For example:
> > 
> > (2) -> (x+1/(y+1))$DMP([x,y],EXPR INT)
> > 
> >               1
> >    (2)  x + -----
> >             y + 1
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> > In this case your expression is a member of the specified domain
> > and no conversion is necessary, but notice that the 2nd term is 
> > a monomial of degree 0 since this domain has coefficients that
> > can be expressions. You might consider this result ambiguous
> > since the entire expression could be consider a term degree 0,
> > but apparently the domain DMP attempts construct a polynomial of
> > highest degree? To know for sure we would probably have to consult
> > the source code for DMP.
> 
> Right. In order to know what will happen, a user would have to
> consult the source code. That's completely unsatisfactory.
>

The solution is *not* to abandon something that is central to
the design of Axiom but rather to write proper, correct and
complete documentation. In particular it is important to realize
that the object that is called a DMP in Axiom is almost, but
not quite that same thing as what a mathematician would call a
polynomial. It is actually something a little more general. It
makes a explicit distinction between the underlying coefficient
domain and the polynomial domain itself. This is something that
one would not (normally) do in mathematics.

There is no problem with this when you think in terms of
programming, but it does sometimes cause some cognitive
dissonance when thinking in terms of the mathematics. In fact
this is quite normal when using other computer algebra systems
as well as Axiom and I think Axiom represents a better
compromise between programming and mathematics than most.

> Even more, I think the interpreter should forbid to construct
> things like DistributedMultivariatePolynomial([x,y],
> Expression Integer).

No! I think this would be very much against the overall design
of Axiom. We must be able to construct domains in this manner.
That is where a great deal of power lies in Axiom that is not
available in other computer algebra systems.

> 
> Take, for example (axiom--main--1--patch-47)
> 
> P := DistributedMultivariatePolynomial([x,y],Expression Integer)
> a: P := x
> degree a
> 
> Are you sure that you expected
> 
> [1,0]
>        Type: DirectProduct(2,NonNegativeInteger)
> 
> as output, given the fact that x is an element of the coefficient
> domain?

Yes. This makes perfectly good sense to me. 'x' is also a polynomial
variable. Since DMP is the highest level domain constructor, I would
expect it to interpret 'x' as being in the polynomial domain first
and only if forced treat is as being in the underlying coefficient
domain.

What about? (Notice that Axiom makes you work harder to say something
like this.)

  b := monomial(x,[0,0]::DirectProduct(2,NNI))$P

Can you explain this result?

(23) -> degree b

   (23)  [0,0]
   Type: DirectProduct(2,NonNegativeInteger)

(24) -> b+x

   (24)  x + x
    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

> 
> Now, it is totally clear that
> 
> degree(a/x)
> 
> also gives
> 
> [1,0]
>        Type: DirectProduct(2,NonNegativeInteger)
> 
> since
> 
> a/x
> 
>          1
>     (5)  - x
>          x
>    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> yields also a completely correct output. ;-) However, I guess, most
> people find this confusing.
> 

I think this is only confusing if you try to think of this
expression out of context, that is, without thinking about the
structure of the domain to which is belongs. Everything that
Axiom is doing here is well-defined and can be useful in the right
context (such as the expansion of trigonometric functions in
Francois' original problem).

It seems to me that Axiom's documentation is deficient because it
does not sufficiently emphasis in what way Axiom differs from other
computer algebra systems. And it does not say nearly enough about
how the fundamental ideas in Axiom such as 'domain' related to the
mathematics that it intends to represent. But I think this is
understandable because what Axiom does in some ways is quite
radical. To really appreciate it takes some time and a lot of work.

The developers of Axiom where quite well aware of this, I think.
That is the reason for the proposal for B# (B natural). Axiom's
current interpreter exposes to much of these details to the first
time user. They need a more gentle introduction to these ideas.
But eventually in order to program in Axiom, it is essential that
they gain a full appreciation of the object-oriented design
philosophy.

\start
Date: Sun, 19 Feb 2006 13:22:33 -0500
From: Tim Daly
To: Ralf Hemmecke
Subject: Re: about Expression Integer

coercions are automatically applied.
conversions are not.

\start
Date: 19 Feb 2006 19:40:42 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: about Expression Integer

Bill Page writes:

> Since DMP is the highest level domain constructor, I would expect it to
> interpret 'x' as being in the polynomial domain first and only if forced
> treat is as being in the underlying coefficient domain.

I believe that this is not always the case, although I don't have an example at
hand.

However, I would like to restate what William Sit and I were able to agree
upon, when we discussed these matters:

  Axiom is able to deal (more or less) properly with variables bearing the same
  name but having different meanings.

We did not agree on whether we should allow this to happen or not...

In other words, consider the following example:

>   b := monomial(x,[0,0]::DirectProduct(2,NNI))$P
> 
> Can you explain this result?
> 
> (23) -> degree b
> 
>    (23)  [0,0]
>    Type: DirectProduct(2,NonNegativeInteger)
> 
> (24) -> b+x
> 
>    (24)  x + x
>     Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

Here, we have two *different* "variables", the only happen to bear the same
name.

What I consider very problematic is, that

 (b+x)::EXPR INT

gives 2x. I believe that this can lead to very "surprising" results.

In any case, I think it is better not to use such types. Currently, this is not
always possible, it would be necessary to introduce a parametrized Expression
domain, that takes variables as parameters -- this is on the WishList, by the
way. I don't think it would be too much work.

\start
Date: 19 Feb 2006 20:01:29 +0100
From: Francois Maltey
To: Francois Maltey,  list
Subject: Re: about Expression Integer

Hello !

So I try :

> P := DistributedMultivariatePolynomial([x,y],Expression Integer)
> a: P := x
> a/x

> However, I guess, most people find this confusing.
Indeed...

Why axiom doesn't see the denominator as a DMP ([x,y], Expr Int) ?
The numerator is a DMP ([x,y], Expr Int).

Numerator and denominator of any fraction are in the same ring, 
and have the same type.

The x variable can't be a variable of the Expression Integer Ring, 
because this a is one of the polynomial.

// 1 //
I was waiting that axiom read a/x as (a::P)/(x::P) because I wait
the same calculus from my students on a sheet of paper.

Is it too difficult ?

// 2 //
I also wait a fail result for the command :
b := monomial(x,[0,0]::DirectProduct(2,NNI))$P

I understand wat is R[X], (R[X])[Y], (R[Y])[X], R[X,Y] and R[Y,X].

I don't understand what is (R[X])[X], so axiom might forget it.

And I don't understand why it's not interessing to add this patch :
.....
However for our purposes something rather primitive is sufficient: 
All domains that contain variables need to export a function 
variables2: % -> List Symbol. Then we can say in 'QFCAT':

 if S has variables2: S -> List Symbol then
   variables2: % -> List Symbol
   variables2 f ==
      merge(variables2(numer(f)), variables2(denom(f)))

and add the following to UP and 'MPOLY':

 if R has variables2: R -> List Symbol then
   coerce(r:R):% ==
     if member?(x, variables2(r)) then
       error "coefficient contains variable"
     else coerce(r)$Rep
......

// 3 // 
Why DMP doesn't accept OrderedSet but only List Symbol ?

* one writes a new domain with a new representation. For
  'DistributedExpression' I failed to do so, since the proper representation
  would be 'DMP', but this only accepts a 'List Symbol' as variables, for
  expressions I need to allow an arbitrary 'OrderedSet' however.

If I'm right Expression are built over POLY which accept OrderedSet 
or <<kernel>> as sin x and so.

\start
Date: Sun, 19 Feb 2006 13:05:06 -0600
From: MathAction (unknown)
To: MathAction
Subject: [FreeAldor] 

Nikolay Ivanov

\start
Date: Sun, 19 Feb 2006 16:11:02 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: about Expression Integer

Martin,

On February 19, 2006 1:41 PM you wrote:
> 
> Bill Page writes:
> 
> > Since DMP is the highest level domain constructor, I would 
> > expect it to interpret 'x' as being in the polynomial domain
> > first and only if forced treat is as being in the underlying
> > coefficient domain.
> 
> I believe that this is not always the case, although I don't 
> have an example at hand.

That is why we need some proper and detailed documentation.
Failing that, we can always read and analyze the source code.
(Actually, it order to write such documentation we have to
do this anyway.)

> 
> However, I would like to restate what William Sit and I were 
> able to agree upon, when we discussed these matters:
> 
>   Axiom is able to deal (more or less) properly with 
>   variables bearing the same name but having different
>   meanings.

Yes! I agree, except I having looked at a lot of source code
I would no longer feel the need to "hedge my bets" by adding
"more or less". I think it can always deal properly with this
situation. If we find some situation where it does not, then
we should treat this as a bug and correct it.

> 
> We did not agree on whether we should allow this to happen
> or not...
>

There may be some situations, such as in the Axiom interpreter
where you might wish to warn the user about the sometimes
unexpected consequences of domains that allow this. But I
completely disagree with the suggestion that is should not
be allowed.
 
> In other words, consider the following example:
> 
> >   b := monomial(x,[0,0]::DirectProduct(2,NNI))$P
> > 
> > Can you explain this result?
> > 
> > (23) -> degree b
> > 
> >    (23)  [0,0]
> >    Type: DirectProduct(2,NonNegativeInteger)
> > 
> > (24) -> b+x
> > 
> >    (24)  x + x
> >     Type: 
> DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> Here, we have two *different* "variables", the only happen to 
> bear the same name.

No. That is the wrong analysis. Axiom does not have any concept
of "variable" that would allow you to make this statement without
first giving the context of the domain. By definition the members
of two different domains are *different* by the very nature of
belonging to two different domains. But in the right context
(right domain) we can see in fact that the two 'x' above are in
fact the same symbol but used to two different contexts. The DMP
domain explicitly makes the distinction between polynomial
variables and coefficients. It thus provides the context where
the two uses of 'x' can be distinguished when the coefficient
domain includes expressions containing the symbol 'x'.

> 
> What I consider very problematic is, that
> 
>  (b+x)::EXPR INT
> 
> gives 2x. I believe that this can lead to very "surprising"
> results.
>

This is only surprising if one does not understand the meaning
of expression 'x+x' in (24). Part of the reason for the confusion,
I think, is because the common OutputForm for polynomials does
not typographically identify polynomial variables versus
coefficients. But if, say the polynomial variables were always
printed in bold face roman type but the coefficients were
printed in italic, it might be more clear what is going on.
 
> In any case, I think it is better not to use such types.

I think it would be better to document clear how and when
such types should be used.

> Currently, this is not always possible, it would be necessary
> to introduce a parametrized Expression domain, that takes
> variables as parameters -- this is on the WishList, by the
> way. I don't think it would be too much work.
> 

This might be interesting, but I am not completely convinced. In
fact, I sometimes wonder whether it makes sense to distinquish
the coefficient domain in the case of Expressions.

\start
Date: 19 Feb 2006 22:45:03 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: about Expression Integer

Bill Page writes:

>  
> > In other words, consider the following example:
> > 
> > >   b := monomial(x,[0,0]::DirectProduct(2,NNI))$P
> > > 
> > > Can you explain this result?
> > > 
> > > (23) -> degree b
> > > 
> > >    (23)  [0,0]
> > >    Type: DirectProduct(2,NonNegativeInteger)
> > > 
> > > (24) -> b+x
> > > 
> > >    (24)  x + x
> > >     Type: 
> > DistributedMultivariatePolynomial([x,y],Expression Integer)
> > 
> > Here, we have two *different* "variables", the only happen to 
> > bear the same name.
> 
> No. That is the wrong analysis. Axiom does not have any concept of "variable"
> that would allow you to make this statement without first giving the context
> of the domain.

We agree, only I did not express myself clearly enough -- obviously, the
quotation marks did not suffice. I should have written: ... two different
"things" ...

> > What I consider very problematic is, that
> > 
> >  (b+x)::EXPR INT
> > 
> > gives 2x. I believe that this can lead to very "surprising"
> > results.
> >
 
> This is only surprising if one does not understand the meaning of expression
> 'x+x' in (24).

Don't worry, I don't find it surprising. In fact, I wrote that it could *lead*
to "surprising" results. I.e., I could imagine that some innocent looking
computation would not be correct in the situation above. For example,

differentiate(b+x,x)

gives one, but 

differentiate(b+x,x)@EXPR INT 

gives two. Note that I did not even need to ask to coerce b+x to EXPR INT... Of
course, as we are discussing this now, this does not come as a surprise. But I
bet that even for quite an experienced axiom user, who did not follow this
thread for some reason, it will be difficult to spot the mistake. Especially if
he doesn't realize that she wanted to compute something else...

> Part of the reason for the confusion, I think, is because the common
> OutputForm for polynomials does not typographically identify polynomial
> variables versus coefficients. But if, say the polynomial variables were
> always printed in bold face roman type but the coefficients were printed in
> italic, it might be more clear what is going on.

I think that this is a very nice idee. I guess this could be even realized on
text terminals, couldn't it?
  
\start
Date: Sun, 19 Feb 2006 22:37:24 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: about Expression Integer

Francois,

On February 19, 2006 2:01 PM you wrote:
> 
> So I try :
> 
> > P := DistributedMultivariatePolynomial([x,y],Expression Integer)
> > a: P := x
> > a/x

Axiom replies:

(3) -> a/x

        1
   (3)  - x
        x
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

> 
> > However, I guess, most people find this confusing.
> > Indeed...

But really it is very simple and easy to predict. The problem
is that most people focus is on the wrong thing. This is especially
natural if they have previous experience with other computer algebra
systems.

In Axiom it is necessary to first understand the meaning of the
domain:

DistributedMultivariatePolynomial([x,y],Expression Integer)

What kind of operations does it export? You can ask Axiom:

)sh DistributedMultivariatePolynomial([x,y],Expression Integer)

After that one can consider if and how the expression a/x might
be a member of this domain.

> 
> Why axiom doesn't see the denominator as a DMP([x,y], Expr Int) ?
> The numerator is a DMP([x,y], Expr Int).

Already your question tells me that you are not thinking about
the domain first. An expression which has both a numerator and
a denominator can not be member of the domain DMP(...)

> 
> Numerator and denominator of any fraction are in the same ring, 
> and have the same type.

But the expression 'a/x' is not a fraction. It is a binary
operation that involves 'a' and 'x'. Axiom needs to know what the
'/' represents. To do this it has to match the types of it's
arguments to the signature of a known function. The type of 'a'
is known, Axiom starts by assuming that x is of type Variable
and looks for an operation '/' in DMP with arguments DMP and
Variable, but there is none. Then it looks for the same operation
in Variable and finds none. So next it considers the operation
'/' with signature

  / : (%, Expression Integer) -> %

in DMP. (Note that % means "this domain".) The Axiom interpreter
discovers that it can first coerce the 'x' of type Variable to an
'x' of type Expression Integer, then it can apply the above operation
from DMP. The result is still something in DMP which happens to have
'x' as both the polynomial variable and '1/x' as it's coefficient.
The implementation of DMP is such that it does not attempt to
simply this result - the polynomial variables and the coefficient
domain remain separate.

> 
> The x variable can't be a variable of the Expression Integer Ring, 
> because this a is one of the polynomial.

There are two separate uses of the variable x: once as a polynomial
variable in DMP and once in the '1/x' which is in the domain
Expression Integer. These are the *same* variable, but used in
two different ways (i.e. in two different domains).

> 
> // 1 //
> I was waiting that axiom read a/x as (a::P)/(x::P) because I wait
> the same calculus from my students on a sheet of paper.

This result is easy to obtain and if I was a teacher of computer
algebra, I would probably leave it as an exercise for my students.
:) But this is not a classroom. The answer is almost given in the
way you wrote the question. Try this:

(4) -> b: FRAC P :=x

   (4)  x
   Type: Fraction DistributedMultivariatePolynomial([x,y],Expression
Integer)

(5) -> b/x

   (5)  1
   Type: Fraction DistributedMultivariatePolynomial([x,y],Expression
Integer)

> 
> Is it too difficult ?

I think it is very simple, but my explanation is too long. :)

> 
> // 2 //
> I also wait a fail result for the command :
> b := monomial(x,[0,0]::DirectProduct(2,NNI))$P
> 
> I understand what is R[X], (R[X])[Y], (R[Y])[X], R[X,Y] and R[Y,X].
> 
> I don't understand what is (R[X])[X], so axiom might forget it.
>

Axiom understands (because of the implementation of DMP) the
distinction between the use of 'x' as a polynomial variable and
the use of 'x' as a coefficient. Perhaps it is true that such a
distinction is not commonly made in mathematics, but the
implementation of DMP keeps these uses distinctly separate.
Axiom is not able to "forget it".
 
> And I don't understand why it's not interessing to add this patch :
> .....
> However for our purposes something rather primitive is sufficient: 
> All domains that contain variables need to export a function 
> variables2: % -> List Symbol. Then we can say in 'QFCAT':
> 
>  if S has variables2: S -> List Symbol then
>    variables2: % -> List Symbol
>    variables2 f ==
>       merge(variables2(numer(f)), variables2(denom(f)))
> 
> and add the following to UP and 'MPOLY':
> 
>  if R has variables2: R -> List Symbol then
>    coerce(r:R):% ==
>      if member?(x, variables2(r)) then
>        error "coefficient contains variable"
>      else coerce(r)$Rep
> ......
>

The patch is not interesting because this situation does not
represent an error. It is a situation that Axiom was designed
to handle correctly. The facilities already exist in Axiom to
simplify the polynomial

 1
 - x
 x

(where '1/x' is a coefficient and the right hand 'x' is the
polynomial variable), if it is desirable.

> // 3 // 
> Why DMP doesn't accept OrderedSet but only List Symbol ?
>

I think this difference is only a historical accident and the
fact that the work on different polynomial domains was done at
different times by different people.
 
> * one writes a new domain with a new representation. For
>   'DistributedExpression' I failed to do so, since the proper 
> representation would be 'DMP', but this only accepts a 'List Symbol'
> as variables, for expressions I need to allow an arbitrary
> 'OrderedSet' however.

Perhaps you can send a copy of your source code. I think what
you are trying to do is possible but it might turn out to be
rather complicated. You can however quite easily convert between
an OrderedSet of variables and a list of variables.

> 
> If I'm right Expression are built over POLY which accept
> OrderedSet or <<kernel>> as sin x and so.
> 

I am afraid that Expression is much more complicated. :( In
fact it is one of the most complex domains in Axiom. I agree,
however with you and Martin Rubey, that we need to re-consider
this domain and possibly extend it in various ways.

I hope that in spite this email is too long, perhaps it is
some use to you.

\start
Date: 20 Feb 2006 10:52:31 +0100
From: Francois Maltey
To: list
Subject: Re: about Expression Integer

Bill Page propose :

((***))
> There may be some situations, such as in the Axiom interpreter
> where you might wish to warn the user about the sometimes
> unexpected consequences of domains that allow this.

I agree with this,

For students and I a lot of problems are about :
<< You think that 2 objects are identical if their writing are identical. >>

The 2 way to read the x is logical when we think as axiom,
but is a trap for students who use computer algebra for solving
a mathematical exercice.

> But really it is very simple and easy to predict. The problem
> is that most people focus is on the wrong thing. This is especially
> natural if they have previous experience with other computer algebra
> systems.

But almost all my student use derive or maple or a TI-9? for little
computation, and during their mathematical studies they don't learn
object programming. So it's impossible to say :
<< learn axiom from the emptyset. >>

I like mupad because easy computation was easy to type,
but difficult idea can be done with clever idea about Domains.
I hope that axiom should have the same point of view.

I don't like maple which have very often wrong results because it's impossi=
ble
to have type : In maple the fact that 0.0 = 0 gives very surprising resul=
t.
So I prefer explain mupad that axiom to my student, because if I don't
have this error I can do a more difficult exercice.

> I could imagine that some innocent looking
> computation would not be correct in the situation above.

As Martin I already imagine this error :

P := DMP ([x,y], EXPR INT)
a :P := x
b := a/x

differentiate(b,x)                    -- 1/x
differentiate(b+x,x)@EXPR INT         -- 0

I find it's a wonderful idea ((***)) to have an error or a warning during
b := a/x. It's really possible ?

Bill, I don't want to change all the axiom language ;-)
it's the _only_ trap I see in the interpeter.

The other computation are logical for students in mathematics. ;-)
And if a student can understand the coefficient function, he can understand
why it's a silly computation to type monomial (x, [0,0]...)
Bill you think it's must remain possible, why not.

\start
Date: Mon, 20 Feb 2006 12:28:42 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

On 02/19/2006 06:06 PM, Bill Page wrote:
> On February 18, 2006 2:37 PM Ralf Hemmecke wrote:
>>>> 1/ Can I (or cannot) remain Expressions as 
>>>>
>>>> x+1/(y+1)             
>>>> y+1/(x+1)             
>>>>
>>>> and do not have a single denominator.
>> Unfortunately, I have no idea, how to do this. :-(

> It is obvious, isn't it, that to do this is Axiom you *must*
> find a domain of which this expression can be a member?

Of course, you are right. I was just saying that I don't know of a 
domain which behaves as one would expect. So the next thing I would do 
is to write another domain which behaves (and inherits) most things from 
Expression Integer but does not group expressions together so that they 
are over one denominator.

Maybe one very simple idea would be to write a domain constructor

ExpressionSum(R:OrderedSet): Exports == Implementation where
   Exports ==> -- Same as for Expression(R)
   Implementation ==> List Expression R
   Rep := List Expression R
   (x: %) + (y: %): % == per append(rep x, rep y) -- concat lists
   -- The other functions have to be implemented accordingly.
   -- That will be a lot of work.
   coerce(x: %): OutputForm == map(+, [e::OutputForm for e in rep x])
     -- Maybe some parens should be added if the expression has
     -- a minus sign

I am not sure, however, whether this is the best idea. Unfortunately, I 
don't know all the domains of Axiom so well. So maybe my sugestion is 
completely irrelevant since something like that is already existing in 
Axiom.

>> But, I'd like to warn you. Don't follow Bill's suggestion.

> I think it is strange how confident both of us are in the
> opposite opinion. :)

> I don't think you have shown any flaw in my suggestion. It seems
> to me to be very reasonable solution to the problem originally
> posed by Francois. In fact this same approach is used on other
> parts of Axiom.

Your suggestion does not work if you want to do the following:

x+1/(y+1)  + y+1/(x+1)

since

(x+1/(y+1)  + y+1/(x+1))$DMP([x,y],EXPR INT)

shows as

                     y + x + 2
    (4)  x + y + ----------------
                 (x + 1)y + x + 1
    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

Of course, ad hoc solutions are not bad as long as one knows what one is 
doing, but I somehow don't like the ad hoc method. Either there is a 
clever program that guesses correctly what the user wants, or, if this 
is not possible, the user should think a bit more and perhaps add more 
knowledge to the system. Otherwise Axiom ends up in being like all the 
other untyped CAS.

> Perhaps your concern arises because you have not worked out
> completely how Axiom uses the concept of domain. I know that
> you understand this idea in some depth because of your background
> with Aldor. As a programmer and a long term user of Maple, I
> had, perhaps, a similar background, but it has taken me more
> than two year of working with Axiom to really understand (at
> least I think I now understand :) how it is applied to mathematics.

Well, I agree, that you are probably better in applying Axiom to real 
world problems, but I hope you agree that if Axiom is not able to do the 
things that Francois wants in a clear way, then it would be better (at 
least for the future) to add a nice feature to the system instead of 
being satisfied that the wish can be fulfilled by an ad-hoc-misuse of 
existing domains.

> In particular it is important to realize
> that the object that is called a DMP in Axiom is almost, but
> not quite that same thing as what a mathematician would call a
> polynomial. It is actually something a little more general. It
> makes a explicit distinction between the underlying coefficient
> domain and the polynomial domain itself. This is something that
> one would not (normally) do in mathematics.

Well, a polynomial in n variables with coefficients in a ring R is an 
element of

   \Oplus_{e \in N^n} R

where N is the non-negative integers.

If you like, you can attach variable names somewhere. Yes, I also know 
that some people define polynomials differently.

And by the way, 1 is a perfect member of DMP([x,y],Integer) also in 
Axiom. I know you know that.

(1) -> a: DMP([x,y],Integer) := 1

    (1)  1
         Type: DistributedMultivariatePolynomial([x,y],Integer)

> What about? (Notice that Axiom makes you work harder to say something
> like this.)
> 
>   b := monomial(x,[0,0]::DirectProduct(2,NNI))$P
> 
> Can you explain this result?
> 
> (23) -> degree b
> 
>    (23)  [0,0]
>    Type: DirectProduct(2,NonNegativeInteger)
> 
> (24) -> b+x
> 
>    (24)  x + x
>     Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

So, let me interpret a polynomial as above as a function (with finite 
support) from the domain of exponents to the domain of coefficients.

(24) clearly has support { [1,0], [0,0] } an is therefore by no means 
equal to the polynomial 2x which has support { [1,0] }.

I am not really saying that Axiom is doing something wrong, I am just 
warning that the use of DMP([x,y], Expression Integer) can be misleading 
for people that don't know how Axiom works internally. Those people 
would probably treat (24) as 2x and that interpretation would be wrong.

>> Now, it is totally clear that
>>
>> degree(a/x)
>>
>> also gives
>>
>> [1,0]
>>        Type: DirectProduct(2,NonNegativeInteger)
>>
>> since
>>
>> a/x
>>
>>          1
>>     (5)  - x
>>          x
>>    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
>>
>> yields also a completely correct output. ;-) However, I guess, most
>> people find this confusing.
>>
> 
> I think this is only confusing if you try to think of this
> expression out of context, that is, without thinking about the
> structure of the domain to which is belongs.

The context is clearly given. It's the type of (5). Right, I could even 
predict, that Axiom should give back that expression. (How could I 
otherwise have constructed it?) But the two x's one sees, have different 
origins and are therefore not equal.

By the way, you can achieve similar confusing things with Maple.

f:=proc() local x; x end;
a:=f(): b:=f():
evalb(a=b);

That behaviour had once cost me several days to trace down a bug. 
Clearly, a looks like x and b looks like x. But they are not equal. I 
haven't found this to be documented.

> But eventually in order to program in Axiom, it is essential that
> they gain a full appreciation of the object-oriented design
> philosophy.

I would not really like to call Axiom (or Aldor) object-oriented.
We don't write

a.add(b)

in order to add two numbers.

the function "add" is not attached to the object a. It is rather that a 
and b are on equal footing.

Try to program a simple thing as a n-ary polynomial ring in a purely 
object-oriented programming language (like for example JAVA even with 
generics), then it becomes clear that Axiom has more to offer that the 
current trend in programming.

\start
Date: Mon, 20 Feb 2006 17:12:22 +0100
From: Ralf Hemmecke
To: Martin Rubey
Subject: DMP([x], DMP([x],

>> Part of the reason for the confusion, I think, is because the common
>> OutputForm for polynomials does not typographically identify polynomial
>> variables versus coefficients. But if, say the polynomial variables were
>> always printed in bold face roman type but the coefficients were printed in
>> italic, it might be more clear what is going on.
> 
> I think that this is a very nice idee. I guess this could be even realized on
> text terminals, couldn't it?

I hope nobody is constructing something like

DMP([x], DMP([x], DMP([x], Integer)))

What are the possible typefaces of x?

Ufff... what's that???

P := DMP([x], DMP([x], Integer))
a:P := x
    DistributedMultivariatePolynomial([x],
       DistributedMultivariatePolynomial([x],Integer)) is not a valid
       type.

Why would Axiom forbid P and allow
Q := DMP([x], Polynomial Integer)
b:Q := x
    (6)  x
      Type: DistributedMultivariatePolynomial([x],Polynomial Integer)

???

And why is that???

(15) -> R := Polynomial Polynomial Integer

    (15)  Polynomial Polynomial Integer
                                                                  Type:
Domain
(16) -> c: R := x

    Polynomial Polynomial Integer is not a valid type.

Yes, now I do my homework and look into the sources of DMP.
Well, my understanding of SPAD is a bit limited, but DMP builds on
GeneralDistributedMultivariatePolynomial (GDMP) and I cannot find
anything that looks like aborting the domain instantiation.

So let's do the following...
Copy the code from DistributedMultivariatePolynomial and just rename the
domain.

--begin aaa.spad
)abbrev domain RHX RHXPolynomial

RHXPolynomial(vl,R): public == private where
   vl : List Symbol
   R  : Ring
   E   ==> DirectProduct(#vl,NonNegativeInteger)
   OV  ==> OrderedVariableList(vl)
   public == PolynomialCategory(R,E,OV) with
       reorder: (%,List Integer) -> %
   private ==
     GeneralDistributedMultivariatePolynomial(vl,R,E)
--end aaa.spad

Then say
)compile aaa.spad
P := RHX([x], RHX([x], Integer))
a:P := x

    (2)  x
         Type: RHXPolynomial([x],RHXPolynomial([x],Integer))

Hmm, just by renaming of DMP to RHX I get a different behaviour?
This tells me that I don't have to look into the Algebra sources to find
why DMP([x], DMP([x], Integer)) is not a valid type. :-(

I hope at some point you agree with me that the interpreter or whoever
forbids to construct DMP([x], DMP([x], Integer)) ) should NOT add
knowledge that is not derivable from the SPAD code in Algebra.

\start
Date: Mon, 20 Feb 2006 12:26:25 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: about Expression Integer

On February 20, 2006 4:53 AM Francois Maltey wrote:

> ... 
> For students and I a lot of problems are about :
> << You think that 2 objects are identical if their writing 
> are identical. >>
> 
> The 2 way to read the x is logical when we think as axiom, 
> but is a trap for students who use computer algebra for
> solving a mathematical exercise.

I agree that Axiom could be improved by using a more rich
output format for complex constructions. Of course when Axiom
was originally designed the computer output devices where not
so advanced - it was exciting then just to print an integral
sign on an ASCII terminal, however bad it looked. Now we can
produce much richer output directly from LaTeX on the computer
screen that would be less ambiguous and easier to read.

But really I do not expect a complicated domain such:

  DMP([x,y],EXPR INT)

to be of much use to beginning students. Usually either 'POLY INT'
or 'EXPR INT' are enough. I proposed it to you because you were
interested in re-programming the package TRMANIP to perform
better trigonometric expansions. In that case it would be used
only internally in the coding of these expansions.

> Bill Page propose :
> > But really it is very simple and easy to predict. The problem
> > is that most people focus is on the wrong thing. This is
> > especially natural if they have previous experience with
> > other computer algebra systems.
> 
> But almost all my student use derive or maple or a TI-9? for
> little computation, and during their mathematical studies they
> don't learn object programming. So it's impossible to say : 
> << learn axiom from the emptyset. >>
>

I don't think it is necessary to learn object-oriented
programming in order to *use* Axiom - at least, I agree that
it should not be necessary. Axiom was designed and implemented
most of the ideas about categories and domains before computer
science even considered the concept. Axiom actually implemented
some fairly common abstract mathematical ideas about "domains"
which you still see in the formal definitions of mathematical
objects like moniods, groups etc. And it extended these ideas in
a logical way that in the end is similar (not identical) to
modern ideas about object-oriented programming. But now perhaps,
the computer science student has an earlier introduction to
these sort of abstractions than the mathematics student.

A side comment: It often seems to me that both theoretical
physics and computer science take mathematics "more seriously"
than the mathematicians themselves. You can see this to the
extent to which so called "pure mathematics" is actually
*applied* in these subjects. In promoting computer algebra to
mathematicians we are sometimes in the odd situation of trying
to sell these "mathematical" ideas back to their originators. :)
 
> I like mupad because easy computation was easy to type, 
> but difficult idea can be done with clever idea about Domains.
> I hope that axiom should have the same point of view. 
>

Unfortunately, I have to agree that Axiom does not do a good
job of this. The designers of Axiom were aware of this problem
and that is one reason why there was a proposed to develop a
new interpreter for Axiom called B# (B natural) which would
provide an initially much more intuitive user interface for
new users. Unfortunately the research funding for Axiom ran
out, before these ideas could be realized. I think it would
be great if someday the open source Axiom project could
resurrect this work.
 
> Martin Rubey wrote: 
> > I could imagine that some innocent looking computation
> > would not be correct in the situation above. 
> 
> As Martin I already imagine this error :
> 
> P := DMP([x,y], EXPR INT) 
> a :P := x 
> b := a/x 
> 
> differentiate(b,x)                    -- 1/x

(4) -> differentiate(b,x)

        1
   (4)  -
        x
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

I think this result should be classed a bug. The 'differentiate'
operation apparently makes some incorrect assumptions about the
coefficient domain. I think the result should be the same as:

(5) -> differentiate(b::EXPR INT,x)::P

   (5)  0
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

So we should create a bug report in

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


> differentiate(b+x,x)@EXPR INT         -- 0
>

For this I get:

(6) -> differentiate(b+x,x)@EXPR INT

   (6)  1
   Type: Expression Integer
 
which seems correct to me.

> I find it's a wonderful idea ((***)) to have an error or a 
> warning during b := a/x. It's really possible ?
> 

Yes. I think Martin's proposed code could be easily changed
to give a warning, but in some cases (e.g. in the case of
using this type of construction inside the TRMANIP package)
I think this warning could cause some confusion. So I think
it would be better do in the Axiom interpret code rather than
in the definition of the domain itself.
 
> Bill, I don't want to change all the axiom language ;-)
> it's the _only_ trap I see in the interpreter.
>

I am sure that there are other traps... ;-) I am not against
changing the "axiom language", for example I mentioned B# above,
but do I think we have to be very careful when we consider changes
to Axiom's mathematical library. The library is large, complex,
poorly documented, and based on some theories that are barely more
than research ideas. Even small changes might have large unexpected
consequences. But still, I would claim that Axiom is superior to
most other computer algebra systems in this regard - that is how
bad the situation is with some of these other systems!
 
> The other computation are logical for students in mathematics. ;-)
> And if a student can understand the coefficient function, he 
> can understand why it's a silly computation to type
> monomial(x, [0,0]...)
> Bill you think it's must remain possible, why not. 
> 

What might seem silly in some situations might be sensible
in other situations.

\start
Date: 20 Feb 2006 18:15:39 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: about Expression Integer

Ralf Hemmecke writes:

[...]

| > But eventually in order to program in Axiom, it is essential that
| > they gain a full appreciation of the object-oriented design
| > philosophy.
| 
| I would not really like to call Axiom (or Aldor) object-oriented.
| We don't write
| 
| a.add(b)
| 
| in order to add two numbers.

There is more to object-orientation than "dot notation".  To my eyes
and mind, Aldor and Axiom are object-oriented, and they haven't yet
escaped that land :-(

| the function "add" is not attached to the object a. It is rather that
| a and b are on equal footing.

"equal footing" is not contradictory to object orientation.

| Try to program a simple thing as a n-ary polynomial ring in a purely
| object-oriented programming language (like for example JAVA even with
| generics), 

Why Java instead of CLOS?

| then it becomes clear that Axiom has more to offer that the
| current trend in programming.

The current trend in programming is some heavy or displcaed emphasis
on generic programming. 

\start
Date: Mon, 20 Feb 2006 13:04:15 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Hyper doc search error

On February 19, 2006 11:31 AM Gaby wrote:

> ...
> Bill Page wrote: 
> | Gaby said recently that he was interested in working on this.
> 
> yup.  I'm currently on road with my parents-in-law so I can't do as
> much as I would want right now.  I looked at the toplevel configure
> and build machinery last night and we can definitely improve things 
> here :-)  
>

Agreed.
 
> I'm curiious of why gmake, gtar and gpatch are required on solaris
> boxes.  
>

I think this was just a misguided attempt to deal with the fact that
it is common on Solaris sytems to have two different toolchains
installed: the Sun-provided C compiler and Unix utilities; as well as
the GNU compiler and GNU tools. ./configure should be able to handle
this in a better way.
 
> I'm also curious as to what extent the autoconf/automake machinery
> will blend with Axiom's pamplet style.
> 

I don't see a problem but it might be desirable for example to
test for notangle (and build noweb if necessary) during ./configure
so that one can use notangle to extract the Makefile.in templates
etc. from the distribution pamphlet files.

\start
Date: Mon, 20 Feb 2006 14:02:25 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: about Expression Integer

On February 20, 2006 12:57 PM Ralf Hemmecke wrote:
> 
> On 02/20/2006 06:15 PM, Gabriel Dos Reis wrote:
> > Ralf Hemmecke writes:
> > 
> > [...]
> > | Bill Page wrote:
> > | > But eventually in order to program in Axiom, it is 
> > | > essential that they gain a full appreciation of the
> > | > object-oriented design philosophy.
> > | 
> > | I would not really like to call Axiom (or Aldor) object-oriented.
> > | We don't write
> > | 
> > | a.add(b)
> > | 
> > | in order to add two numbers.
> > 
> > There is more to object-orientation than "dot notation".  To my
> > eyes and mind, Aldor and Axiom are object-oriented, and they
> > haven't yet escaped that land :-(
>

I am curious why you wrote :-( ? Are you implying that you wish
that Aldor and Axiom did use a paradigm more advanced than object
orientation?

> Hmm, do you call the following object-oriented?

Before discussing whether something is "object-oriented" or not
I think we need to agree on a definition. For example, I think
the following definition is quite good:

http://www.webopedia.com/TERM/O/object_oriented_programming_OOP.html

object-oriented programming

  A type of programming in which programmers define not only the
  data type of a data structure, but also the types of operations
  (functions) that can be applied to the data structure. In this way,
  the data structure becomes an object that includes both data and
  functions. In addition, programmers can create relationships
  between one object and another. For example, objects can inherit
  characteristics from other objects.

  One of the principal advantages of object-oriented programming
  techniques over procedural programming techniques is that they
  enable programmers to create modules that do not need to be
  changed when a new type of object is added. A programmer can
  simply create a new object that inherits many of its features
  from existing objects. This makes object-oriented programs easier
  to modify.

This definition seems to apply directly to Axiom and Aldor.

BTW, I think the wikipedia definition on the other hand is
terrible!

http://en.wikipedia.org/wiki/Object-oriented_programming

> 
> (This code appears in libalgebra distributed with Aldor and 
> it basically provides a generic function that given a function
> "f: R -> S" returns a function "map(f)" of type "RX -> SX" that
> applies "f" on the coefficients of a univariate polynomial.)
> 
> UnivariateFreeRing2(
>      R : Join(ArithmeticType, ExpressionType),
>      RX: UnivariateFreeRing R,
>      S : Join(ArithmeticType, ExpressionType),
>      SX: UnivariateFreeRing S
> ): with {
> 	map: (R -> S) -> RX -> SX;
> } == add {
> 	map(f:R -> S)(p:RX):SX == {
> 		q:SX := 0;
> 		for term in p repeat {
> 			(c, n) := term;
> 			q := add!(q, f c, n);
> 		}
> 		q;
> 	}
> }
> 
> What is the class and what are the methods?
>

Clearly 'UnivariateFreeRing2' is the class and 'map' is a method.
No?

In Axiom terminology this would be called a "package" since it
does not involve any representation object (Rep) and so does
not have any instances (members).

Axiom and Aldor actually implement a two-level class structure
so 'UnivariateFreeRing2' itself is an instance of the class
(category) 'with { map: (R -> S) -> RX -> SX; }'.

Just curious: The syntax:

  map(f:R -> S)(p:RX):SX == {...

looks strangely abbreviated to me. Why not write:

  map(f:R -> S):RX->SX ==

   (p:RX):SX +-> { ...
 
Is this equivalent?

> Can you write that in JAVA or CLOS? I would be happy to see it.

Ignoring for now the details of the Aldor library, why would you
expect this to be difficult? Java supports functions that return
functions anc CLOS is just common lisp done a certain way, so
surely there is no question. Am I missing something?

> 
> > | the function "add" is not attached to the object a. It is 
> > | rather that a and b are on equal footing.
> > 
> > "equal footing" is not contradictory to object orientation.
> 
> Well, you may be right. But when I read about implementation 
> of complex numbers in C++ and saw that a.add(b) construct,
> I really did not like it (at least not in the context of mathematics).
> It is saying: sent the message "add" with parameter "b" to the
> object "a". And it means that "a" has to do the work since "a"
> knows how to add something to itself. It is like saying. The
> integer 1 knows how another integer can be added to it. I don't
> consider that thinking to be quite natural in the context of
> mathematics. I agree, object-orientation be appropriate for other 
> contexts.

What you describe should probably called a "message passing"
paradigm as opposed to object-oriented, as such. Because SmallTalk
was one of the first well known object-oriented languages and
it also implemented the message passing paradigm, I think these
two programming methodologies are sometimes confused.

I Axiom if I write;

  a:Complex Integer := 1
  a + 2

the operation '+' is taken from the domain of 'a'. Both 'a' and
'2' an instances of the class (domain) 'Complex Integer'.

> 
> > | then it becomes clear that Axiom has more to offer that the
> > | current trend in programming.
> 
> > The current trend in programming is some heavy or displaced
> > emphasis on generic programming. 
> 
> Sorry that I don't know CLOS, but I have looked a bit into JAVA's 
> generics. And that is a lot weaker than what was already available
> in Aldor several years ago.
>

I think that is true and these ideas originated in Axiom itself,
which very considerably pre-dates "current trends in programming".
I think it is a pity that Axiom was/is not better known among
programming language designers.
 
> BTW, I don't say that Aldor hasn't some kind of object-orientation,
> but it is in my opinion not a pure object-oriented language.
> 

Define 'pure' ... ;)

\start
Date: Mon, 20 Feb 2006 18:57:09 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: about Expression Integer

Hallo Gaby,

On 02/20/2006 06:15 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> [...]
> 
> | > But eventually in order to program in Axiom, it is essential that
> | > they gain a full appreciation of the object-oriented design
> | > philosophy.
> | 
> | I would not really like to call Axiom (or Aldor) object-oriented.
> | We don't write
> | 
> | a.add(b)
> | 
> | in order to add two numbers.
> 
> There is more to object-orientation than "dot notation".  To my eyes
> and mind, Aldor and Axiom are object-oriented, and they haven't yet
> escaped that land :-(

Hmm, do you call the following object-oriented?

(That code appears in libalgebra distributed with Aldor and it basically 
provides a generic function that given a function "f: R -> S" returns a 
function "map(f)" of type "RX -> SX" that applies "f" on the 
coefficients of a univariate polynomial.)

UnivariateFreeRing2(
     R : Join(ArithmeticType, ExpressionType),
     RX: UnivariateFreeRing R,
     S : Join(ArithmeticType, ExpressionType),
     SX: UnivariateFreeRing S
): with {
	map: (R -> S) -> RX -> SX;
} == add {
	map(f:R -> S)(p:RX):SX == {
		q:SX := 0;
		for term in p repeat {
			(c, n) := term;
			q := add!(q, f c, n);
		}
		q;
	}
}

What is the class and what are the methods?

Can you write that in JAVA or CLOS? I would be happy to see it.

> | the function "add" is not attached to the object a. It is rather that
> | a and b are on equal footing.
> 
> "equal footing" is not contradictory to object orientation.

Well, you may be right. But when I read about implementation of complex 
numbers in C++ and saw that a.add(b) construct, I really did not like it 
(at least not in the context of mathematics). It is saying: sent the 
message "add" with parameter "b" to the object "a". And it means that 
"a" has to do the work since "a" knows how to add something to itself.
It is like saying. The integer 1 knows how another integer can be added 
to it. I don't consider that thinking to be quite natural in the context 
of mathematics. I agree, object-orientation be appropriate for other 
contexts.

> | then it becomes clear that Axiom has more to offer that the
> | current trend in programming.

> The current trend in programming is some heavy or displcaed emphasis
> on generic programming. 

Sorry that I don't know CLOS, but I have looked a bit into JAVA's 
generics. And that is a lot weaker than what was already available in 
Aldor several years ago.

BTW, I don't say that Aldor hasn't some kind of object-orientation, but 
it is in my opinion not a pure object-oriented language.

\start
Date: Mon, 20 Feb 2006 20:48:45 +0100
From: David Mentre
To: Tim Daly
Subject: Re: Hyper doc search error

Hello Tim,

Tim Daly writes:

> my long term plan is to push almost everything into ansi common lisp
> and use asdf.

What is asdf? This asdf: http://www.cliki.net/asdf ?

\start
Date: Mon, 20 Feb 2006 15:01:13 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: about Expression Integer

On February 20, 2006 6:29 AM Ralf Hemmecke wrote:
> 
> On 02/19/2006 06:06 PM, Bill Page wrote:
> > On February 18, 2006 2:37 PM Ralf Hemmecke wrote:
> >>>> 1/ Can I (or cannot) remain Expressions as 
> >>>>
> >>>> x+1/(y+1)             
> >>>> y+1/(x+1)             
> >>>>
> >>>> and do not have a single denominator.
> >> Unfortunately, I have no idea, how to do this. :-(
> 
> > It is obvious, isn't it, that to do this is Axiom you *must*
> > find a domain of which this expression can be a member?
> 
> Of course, you are right. I was just saying that I don't know of
> a domain which behaves as one would expect. So the next thing I 
> would do is to write another domain which behaves (and inherits)
> most things from Expression Integer but does not group expressions
> together so that they are over one denominator.
>

Yes, that is a good idea if you desire to solve the general
problem of defining a domain in which contains all possible
expressions as members. Perhaps this is the kind of "userdomain"
that Jenks and Trager had in mind in the design of BNatural.

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

How would this differ from Aldor's ExpressionTree domain?
 
> ... 
> >> But, I'd like to warn you. Don't follow Bill's suggestion.
> 
> > I think it is strange how confident both of us are in the
> > opposite opinion. :)
> 
> > I don't think you have shown any flaw in my suggestion. It seems
> > to me to be very reasonable solution to the problem originally
> > posed by Francois. In fact this same approach is used on other
> > parts of Axiom.
> 
> Your suggestion does not work if you want to do the following:
> 
> x+1/(y+1)  + y+1/(x+1)
> 
> since
> 
> (x+1/(y+1)  + y+1/(x+1))$DMP([x,y],EXPR INT)
> 
> shows as
> 
>                      y + x + 2
>     (4)  x + y + ----------------
>                  (x + 1)y + x + 1
>     Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
>

You are right that this might quite not produce the type of trigonometric
expansion that Francois has in mind. On the other hand, the result
is still well defined in the sense that the parts of the expression
that are representable as a distributed polynomial remain and
everything else is in the coefficient domain. I think it would be
better than what Axiom currently produces for:

  expand sin((x+1/(y+1)  + y+1/(x+1)))
 
> Of course, ad hoc solutions are not bad as long as one knows 
> what one is doing, but I somehow don't like the ad hoc method.

I don't think this solution should be classed as "ad hoc". It
seems to me to be consistent with other operations of this
kind already done by Axiom. But I do agree that it is not a
fully general solution.

> Either there is a clever program that guesses correctly what
> the user wants, or, if this is not possible, the user should
> think a bit more and perhaps add more knowledge to the system.
> Otherwise Axiom ends up in being like all the other untyped CAS.

I agree.

> ... I hope you agree that if Axiom is not able to do the things
> that Francois wants in a clear way, then it would be better
> (at least for the future) to add a nice feature to the system
> instead of being satisfied that the wish can be fulfilled by an
> ad-hoc-misuse of existing domains.

I agree (except I do not class my proposed solution as an
ad-hoc-misuse :).

> 
> > In particular it is important to realize
> > that the object that is called a DMP in Axiom is almost, but
> > not quite that same thing as what a mathematician would call a
> > polynomial. It is actually something a little more general. It
> > makes a explicit distinction between the underlying coefficient
> > domain and the polynomial domain itself. This is something that
> > one would not (normally) do in mathematics.
> 
> Well, a polynomial in n variables with coefficients in a ring R is
> an element of
> 
>    \Oplus_{e \in N^n} R
> 
> where N is the non-negative integers.
> 
> If you like, you can attach variable names somewhere. Yes, I 
> also know that some people define polynomials differently.
> 

This is good enough for me and apparently to the designers of DMP.
They do attach the polynomial variables names, but on the other hand
they also provide the 'vectorize' operator.

> ... 
> > 
> >    (24)  x + x
> >     Type: 
> DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> So, let me interpret a polynomial as above as a function (with
> finite support) from the domain of exponents to the domain of
> coefficients.
> 
> (24) clearly has support { [1,0], [0,0] } an is therefore by no
> means equal to the polynomial 2x which has support { [1,0] }.

Ok.

> 
> I am not really saying that Axiom is doing something wrong, I am
> just warning that the use of DMP([x,y], Expression Integer) can
> be misleading for people that don't know how Axiom works internally.

To write your interpretation above you did not need to know how
Axiom works internally. If people where equipped with your explanation
I don't think the result would be misleading. This is the type of
documentation that I think we need to have for Axiom's library.

> Those people would probably treat (24) as 2x and that interpretation
> would be wrong.

It is only wrong in the context of DMP([x,y], Expression Integer).
In domain 'Expression Integer' it is correct. That is why I say
that Axiom demands that one first state clearly the domain and
only then consider the expression.

> >>
> >>          1
> >>     (5)  - x
> >>          x
> >>    Type: 
> >>      DistributedMultivariatePolynomial([x,y],Expression Integer)
> >>
> > ... 
> > I think this is only confusing if you try to think of this
> > expression out of context, that is, without thinking about the
> > structure of the domain to which is belongs.
> 
> The context is clearly given. It's the type of (5). Right, I 
> could even predict, that Axiom should give back that expression.
> (How could I otherwise have constructed it?) But the two x's one
> sees, have different origins and are therefore not equal.

It is only in the context of this domain that they are not equal.
If I coerce this result to the domain 'Expression Integer' they
will be treated as equal.

> 
> By the way, you can achieve similar confusing things with Maple.
> 
> f:=proc() local x; x end;
> a:=f(): b:=f():
> evalb(a=b);
> 
> That behaviour had once cost me several days to trace down a bug. 
> Clearly, a looks like x and b looks like x. But they are not equal.
> I haven't found this to be documented.
>

In Maple terminology this is known as an "escaped local variable".
I think this situation is completely different than in Axiom. It is
reasonable to conclude that this odd behaviour in Maple occurs
because Maple does not have any concept of domain, so it cannot
(at least not easily) specify a situation (domain) in which the
equality 'a=b' can be properly evaluated. Notice that in Axiom
'=' is also an operator and we need to know the domain which
provides this operation.
 
\start
Date: Mon, 20 Feb 2006 15:16:14 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: about Expression Integer

On February 19, 2006 4:45 PM Martin Rubey wrote:
> 
> Bill Page writes:
> 
> >  
> > > In other words, consider the following example:
> > > >   P := DistributedMultivariatePolynomial([x,y],Expression Integer)
> > > >   b := monomial(x,[0,0]::DirectProduct(2,NNI))$P
> > > > 

> ...
> I wrote that it could *lead* to "surprising" results. I.e.,
> I could imagine that some innocent looking computation would
> not be correct in the situation above. For example,
> 
> differentiate(b+x,x)
> 
> gives one, but 
> 
> differentiate(b+x,x)@EXPR INT 
> 
> gives two.

(1) -> P := DistributedMultivariatePolynomial([x,y],Expression Integer)

   (1)  DistributedMultivariatePolynomial([x,y],Expression Integer)
   Type: Domain

(2) -> b := monomial(x,[0,0]::DirectProduct(2,NNI))$P

   (2)  x
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

(3) -> differentiate(b+x,x)

   (3)  1
   Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

(4) -> differentiate(b+x,x)@EXPR INT

   (4)  2
   Type: Expression Integer

> Note that I did not even need to ask to coerce b+x to EXPR INT...
> Of course, as we are discussing this now, this does not come as 
> a surprise. But I bet that even for quite an experienced axiom
> user, who did not follow this thread for some reason, it will be
> difficult to spot the mistake. Especially if he doesn't realize
> that she wanted to compute something else...

I would call the result in (3) a bug. It seems to me that perhaps
'differentiate$DMP' is making a unwarranted assumption that the
coefficients of DMP are constant. I cannot imagine a properp
mathematical definition of 'differentiate' that depended on the
distinction of polynomial coefficients versus variables.

> 
> > Part of the reason for the confusion, I think, is because the
> > common OutputForm for polynomials does not typographically 
> > identify polynomial variables versus coefficients. But if, say
> > the polynomial variables were always printed in bold face roman
> > type but the coefficients were printed in italic, it might be
> > more clear what is going on.
> 
> I think that this is a very nice idee. I guess this could be 
> even realized on text terminals, couldn't it?
>   

To do this in LaTeX output is obviously quite straight forward.
To do it on text terminals I think would require support of
'curses' or a similar library. I am not sure that Axiom text
output (really a function of the underlying lisp - GCL, I guess)
supports 'curses'. Do you think suport for these conventions in
text output are really that important?

\start
Date: Mon, 20 Feb 2006 16:07:34 -0500
From: Tim Daly
To: David Mentre
Subject: Re: Hyper doc search error

> > my long term plan is to push almost everything into ansi common lisp
> > and use asdf.
> 
> What is asdf? This asdf: http://www.cliki.net/asdf ?

yes. asdf is the direction all of the lisp systems are adopting.

asdf is a tool that allows you to build lisp systems from a tree
of requirements. it has the advantage of giving you the full power
of the language to specify your requirements.

the autoconf/automake facilities are fine if you write C code
but fail when you try to use lisp code. centuries ago axiom was
moving toward a mk-defsystem but never got there. 

asdf will also allow us to import tools from the web rather than
package them with the distribution.

if you look at
http://www.cl-user.net/asp/082x1/sdataQG5inxSTzxS5DM==/sdataQo5Y-1Mh9urk
you'll see that the common lisp world is coming together to form 
proper libraries and tools.

if you look at
http://www.cl-user.net/asp/282x1/sdataQG5inxSTzxS5DQjr-br28xqk8yBX8yBX8oQ5Ss9v-ujg$Np5/sdataQu3F$sSHnB==
you'll see axiom listed.

this is all being managed by the lisp gardener's group.

\start
Date: Mon, 20 Feb 2006 21:47:15 +0100
From: David Mentre
To: Tim Daly
Subject: ASDF and ./configure (was: Re: Hyper doc search error)

Tim,

Tim Daly writes:

>> What is asdf? This asdf: http://www.cliki.net/asdf ?
>
> yes. asdf is the direction all of the lisp systems are adopting.
>
> asdf is a tool that allows you to build lisp systems from a tree
> of requirements. it has the advantage of giving you the full power
> of the language to specify your requirements.

Ok, thank you for the pointers.

> the autoconf/automake facilities are fine if you write C code
> but fail when you try to use lisp code. centuries ago axiom was
> moving toward a mk-defsystem but never got there. 
>
> asdf will also allow us to import tools from the web rather than
> package them with the distribution.

Would you accept (or at least not be opposed to ;) a hand-written
./configure shell script? It would find the basic tools (awk, noweb,
...) and setup the main Makefile file, in order to launch all the CL
machinery. 

If you agree I'll take the job.

\start
Date: 20 Feb 2006 22:02:01 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: about Expression Integer

Ralf Hemmecke writes:

| Hallo Gaby,
| 
| On 02/20/2006 06:15 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > [...]
| > | > But eventually in order to program in Axiom, it is essential that
| > | > they gain a full appreciation of the object-oriented design
| > | > philosophy.
| > | | I would not really like to call Axiom (or Aldor) object-oriented.
| > | We don't write
| > | | a.add(b)
| > | | in order to add two numbers.
| > There is more to object-orientation than "dot notation".  To my eyes
| > and mind, Aldor and Axiom are object-oriented, and they haven't yet
| > escaped that land :-(
| 
| Hmm, do you call the following object-oriented?

Yes.

| (That code appears in libalgebra distributed with Aldor and it
| basically provides a generic function that given a function "f: R ->
| S" returns a function "map(f)" of type "RX -> SX" that applies "f" on
| the coefficients of a univariate polynomial.)
| 
| UnivariateFreeRing2(
|      R : Join(ArithmeticType, ExpressionType),
|      RX: UnivariateFreeRing R,
|      S : Join(ArithmeticType, ExpressionType),
|      SX: UnivariateFreeRing S
| ): with {
| 	map: (R -> S) -> RX -> SX;
| } == add {
| 	map(f:R -> S)(p:RX):SX == {
| 		q:SX := 0;
| 		for term in p repeat {
| 			(c, n) := term;
| 			q := add!(q, f c, n);
| 		}
| 		q;
| 	}
| }
| 
| What is the class and what are the methods?

The class is the collection of "things" that you can "pretend" to be
univariate polynomials.
The methods are the necessary supporting functions you need to collect the
coefficients into something you "pretend" is a univariate polynomial.
For example here, add! is one of those methods.

| Can you write that in JAVA or CLOS? I would be happy to see it.
| 
| > | the function "add" is not attached to the object a. It is rather that
| > | a and b are on equal footing.
| > "equal footing" is not contradictory to object orientation.
| 
| Well, you may be right. But when I read about implementation of
| complex numbers in C++ and saw that a.add(b) construct, I really did
| not like it (at least not in the context of mathematics).

The (standard) complex number implementations of C++ I know of do not
have "a.add(b)", and surely the implementations I'm familiar with do
not claim "object orientation", quite the contrary.

| It is
| saying: sent the message "add" with parameter "b" to the object
| "a". And it means that "a" has to do the work since "a" knows how to
| add something to itself.

In the C++ implementations I'm familiar with, it is written "a + b".

| It is like saying. The integer 1 knows how another integer can be
| added to it. I don't consider that thinking to be quite natural in the
| context of mathematics. I agree, object-orientation be appropriate for
| other contexts.
| 
| > | then it becomes clear that Axiom has more to offer that the
| > | current trend in programming.
| 
| > The current trend in programming is some heavy or displcaed emphasis
| > on generic programming.
| 
| Sorry that I don't know CLOS,

The reason why I mention CLOS is that it is close to Lisp (given the
general topic of this mailing list :-), it has an object system, and
given the _topic_,it has *multi-methods* (though I don't particularly
like their ambiguity resolution.) 

| but I have looked a bit into JAVA's
| generics. And that is a lot weaker than what was already available in
| Aldor several years ago.

I believe you.  But again, I'm skeptical that we are going to make
Axiom lead if we insist on comparing with Java.  More advanced systems
are around (e.g. Haskell). 

| BTW, I don't say that Aldor hasn't some kind of object-orientation,
| but it is in my opinion not a pure object-oriented language.

My view is that debates of "pure" <your-favorite-buzzword> are
meaningless as far as productive system building is concerned.  
So, I will stop here.

\start
Date: Mon, 20 Feb 2006 15:02:07 -0600
From: MathAction (DavidMentre)
To: MathAction
Subject: [build Axiom] new method to download from CVS works

>From DavidMentre: it works (the "export" is probably not
 needed). Should I modify the top of the page?

\start
Date: Mon, 20 Feb 2006 16:16:12 -0500
From: Doug Stewart
To: Ralf Hemmecke
Subject: Re: about Expression Integer

<snip>
Wow!!!  I have been watching and learning Axiom for the last two months, 
and this thread has really help me.
What I have found is that I can pick up Axiom in a simple way quite 
quickly but then I hit a wall that I could not seem to get past.

This thread has brought to light what the wall is and has help me muchly.
Could someone in the know take some material from this thread and use it 
in the manual?
I know that just reading this has opened my eyes.

\start
Date: 20 Feb 2006 22:22:27 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: about Expression Integer

Bill Page writes:

| On February 20, 2006 12:57 PM Ralf Hemmecke wrote:
| > 
| > On 02/20/2006 06:15 PM, Gabriel Dos Reis wrote:
| > > Ralf Hemmecke writes:
| > > 
| > > [...]
| > > | Bill Page wrote:
| > > | > But eventually in order to program in Axiom, it is 
| > > | > essential that they gain a full appreciation of the
| > > | > object-oriented design philosophy.
| > > | 
| > > | I would not really like to call Axiom (or Aldor) object-oriented.
| > > | We don't write
| > > | 
| > > | a.add(b)
| > > | 
| > > | in order to add two numbers.
| > > 
| > > There is more to object-orientation than "dot notation".  To my
| > > eyes and mind, Aldor and Axiom are object-oriented, and they
| > > haven't yet escaped that land :-(
| >
| 
| I am curious why you wrote :-( ? Are you implying that you wish
| that Aldor and Axiom did use a paradigm more advanced than object
| orientation?

yes, more or less.

Many linguistic constructs one finds in Aldor and Axiom have been the
"lead" at the time (at least two decades ago, though neither Aldor nor
Axiom were called that way at the time) -- blending object orientation
(in the style of categories and domains) and imperative higher order
programming was rather powerful and "unique".  However, I'm kind of
"disappointed" to see that virtual no progress has been  since then.
On the other hand, qualified type systems have emerged leading more
"natural" expression of ideas (though posing more difficult
challenges), and I'm sorry to say it, and we are here comparing Axiom
to Java :-( 

| > Hmm, do you call the following object-oriented?
| 
| Before discussing whether something is "object-oriented" or not
| I think we need to agree on a definition. For example, I think
| the following definition is quite good:
| 
| http://www.webopedia.com/TERM/O/object_oriented_programming_OOP.html

I agree that it captures many points of what I would consider "object
oriented". 

[...]

| I Axiom if I write;
| 
|   a:Complex Integer := 1
|   a + 2
| 
| the operation '+' is taken from the domain of 'a'. Both 'a' and
| '2' an instances of the class (domain) 'Complex Integer'.

Exactly!  If you look at "type classes", you'll see that is exactly
what is happening.  In mundain terms, the operation is extracted from
the "vtable", which is guaranteed by the fact that:
  
  * the category says the operation exists (<-> abstract classes or
    interfaces). 

  * the domain says it implements the operation.

[...]

| I think that is true and these ideas originated in Axiom itself,
| which very considerably pre-dates "current trends in programming".
| I think it is a pity that Axiom was/is not better known among
| programming language designers.

That was part my point.  The other part is that it is pity Axiom
designers did not keep the lead on that front.

In April 2004, there was a workshop organized at Adobe (San Jose) to
talk about "concepts for C++".  I deliberately chosed to present two
"main" type systems:  (1) type classes, and (2) "categories and
domains" in Aldor.  That was also an opportunity for me to foster a
deeper understand of the ideas work in both world (and later build
an excuse of why I did not push for them :-).

The linguistic construct I found the most useful in Aldor is "post
facto extension".

\start
Date: Mon, 20 Feb 2006 18:46:24 -0500
From: Tim Daly
To: David Mentre
Subject: Re: ASDF and ./configure (was: Re: Hyper doc search error)

> Would you accept (or at least not be opposed to ;) a hand-written
> ./configure shell script? It would find the basic tools (awk, noweb,
> ...) and setup the main Makefile file, in order to launch all the CL
> machinery. 

The issue, as i understand it, is not that the configure script
doesn't work on the systems where it was tested. The issue is that
the configure script is not robust. Certain problems have to be
decided.

Given a particular system you need to output a symbol (e.g linux)
which will be used selector for the inital Makefile. 

   * this appears to be a huge case statement based on a lot of
     factors that are hard to decide. the "linux" symbol will build
     a system on FC3 if SELinux is not enabled but fails otherwise.

     thus configure needs to have a large number of tests to 
     decide on a unique symbol. for each unique symbol the 
     Makefile.pamphlet contains all the necessary knowledge (and
     associated explanations) for building axiom on that system
     combination.

The initial Makefile extracts and configure the main Makefile that
is customized for the target system. so 

  configure --> "linux" (or "solaris", "FC4", etc)
 
  Makefile + "linux" + Makefile.pamphlet -> Makefile.linux


 
In addition there are some other issues that arise. The noweb tool
seems to want to use one of 'awk', 'gawk', or 'nawk'. Given that
noweb is vital to the early processing we need to find which of
the three is available on the current system and customize the
main Makefile to use it. This is done on the command line:

   make -f Makefile.linux AWK=nawk



Some systems use differen tool names (e.g. gtar) and those have to
be able to be overriden also. However, given that it is a lot of
effort to make sure axiom works on each new system all of this
knowledge is embedded in the Makefile.pamphlet and selected by
the system symbol ("solaris" ==> gtar).



Another issue has arisen. It appears that some of the shell
scripts aren't portable because they use #! paths to execute them.

Perhaps the configure program can help with the initial value
selections but it would take some careful thought. It's probably
better and more robust to rewrite the shell scripts not to use #!



> If you agree I'll take the job.

Ummm, that's reversing the approval path methinks. If your solution
works and is not disruptive then it's likely to get accepted. But
a "rewrite the world" solution is likely to get a lot of pushback.
Propose something and we can all comment on it. 



I just had a long phone discussion about this whole issue debating
the merits of the autoconf vs asdf vs the current situation. After
reviewing the pros and cons it seems that the end result is that
axiom is a large and complex enough system that (a) none of the
standard tools work well and (b) it can support its own non-standard
build process. I won't go into the details of 3 hours of talking but
for every example there appears to be a counter-example and for every
rule there is an exception.

\start
Date: Mon, 20 Feb 2006 15:39:01 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Time for another crazy idea...

I know my understanding of categories and domains is massively
imperfect, so perhaps this idea is not worth much, but since it might
be one of those cases where an explanation of why its a bad idea might
be helpful, here we go...

My understanding of Axiom's concept of categories and domains is that
it is similar to and at least somewhat compatible with category and/or
set theory, but it was not explicitly designed to implement and rely
these theories as a foundation.  If that's true, I was wondering what
sort of effort would be involved in tuning Axiom's use of categories to
be in line with category theory mathematics, along the lines of things
like Categories for the Working Mathematician.  If Axiom is already
close to this anyway, perhaps the next step could be taken and Axiom
could relate its category structure directly to research in category
theory, and turn its own core implementation of mathematical
fundamentals into a literate document summarizing the research in those
areas and how it is applied.

Is that a) an insane amount of work and I just don't realize it yet b)
a non-practical idea in terms of having an actual working CAS or c) all
of the above?  I always thought the best way to lead off the Algebra
volumes of Axiom was with a discussion of the fundamental theories of
mathematics encoded in Axiom and the research they are based off of,
but perhaps that's not a good approach for Axiom?

I'm going to finish a unit and dimension implementation before I even
think about tackling something that crazy, but I figured if it's a
really Nutty idea I should find out now ;-)

\start
Date: Mon, 20 Feb 2006 15:48:05 -0800 (PST)
From: Cliff Yapp
To: list
Subject: 3D animation in PDF?

Does anybody know if there is a way to accomplish this type of effect
in a pdf document without really elaborate 3rd party software?  This
would be a really neat feature to have available in mathematical
notebook exports some day:

ftp://ftp2.bentley.com/dist/collateral/Web/composing3d.pdf

(examples start on page 3)

There are other examples here:
http://www.bentley.com/en-US/Products/MicroStation/Interactive+3D+PDF.htm

\start
Date: Mon, 20 Feb 2006 16:14:09 -0800 (PST)
From: Cliff Yapp
To: list
Subject: 3D pdf in latex

Well, to answer (partially) my own question, this looks interesting:

http://www.tug.org/tex-archive/macros/latex/contrib/movie15/doc/movie15.pdf

\start
Date: Mon, 20 Feb 2006 20:26:08 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

integrate((e^ -2x)sin  3x, x)

\start
Date: Mon, 20 Feb 2006 20:26:09 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

integrate((e^ -2x)sin  3x, x)

\start
Date: Mon, 20 Feb 2006 20:26:11 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

integrate((e^ -2x)sin  3x, x)

\start
Date: Mon, 20 Feb 2006 20:26:31 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

\begin{axiom}
integrate((e^ -2x)sin 3x, x)
\end{axiom}

\start
Date: Mon, 20 Feb 2006 20:27:33 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

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

\start
Date: Mon, 20 Feb 2006 20:28:01 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

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

\start
Date: Mon, 20 Feb 2006 20:28:05 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

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

\start
Date: Mon, 20 Feb 2006 20:28:21 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

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

\start
Date: Mon, 20 Feb 2006 20:29:17 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

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

\start
Date: Mon, 20 Feb 2006 20:29:49 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomInterface] 

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

\start
Date: Mon, 20 Feb 2006 22:05:31 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [build Axiom] Yes, please update this page

David Mentre wrote:

> it works (the "export" is probably not needed). Should I modify
> the top of the page?

Yes, please go ahead and update the contents of this page with
the most recent information. If you have the time and motivation,
please re-organize it so this information is easier to find.

\start
Date: Tue, 21 Feb 2006 08:53:38 +0100
From: David Mentre
To: Tim Daly
Subject: Re: ASDF and ./configure (was: Re: Hyper doc search error)

Tim (and al.),

Thank you for the comments and summary of the build process. I'll keep
it in mind.

2006/2/21, Tim Daly:
> > If you agree I'll take the job.
>
> Ummm, that's reversing the approval path methinks. If your solution
> works and is not disruptive then it's likely to get accepted.

Obviously! I know how Free Software works. I just wanted you to
confirm me that I have at least have a chance to have my patch
considered for inclusion. If you have told me that you don't want
*any* shell script or home made ./configure, I would have not bothered
trying to make one.

> But a "rewrite the world" solution is likely to get a lot of pushback.
> Propose something and we can all comment on it.

Sure, I'm reading Bill's posts. ;-) I think a hand-written ./configure
is the way to go, contrary to Bill's idea of using autoconf. I'll make
my own proposal and then the Axiom Community will decide.

And I should underline that I believe more in consensus than
everything else. So the final build system will probably be a mix
between Bill's ideas, mines and yours. :-)

\start
Date: Tue, 21 Feb 2006 04:56:30 -0600
From: MathAction (hemmecke)
To: MathAction
Subject: [DistributedMultivariatePolynomial] (new) 

The use of
\begin{axiom}
R := Expression Integer
\end{axiom}
as the coefficient domain in
\begin{axiom}
P := DistributedMultivariatePolynomial([x,y], R)
\end{axiom}
might lead to unexpected results due to the fact that the domain $R$ can contain arbitrary expressions (including the variable $x$).
Take for example.
\begin{axiom}
a: P := x
b: P := a/x
\end{axiom}
Although it might seem strange that the result is not equal to 1,
Axiom behaved perfectly the way you told it to.

If the interperter sees $a/x$, it knows the type of $a$ but not yet for $x$. So it looks for a function it can apply.
It finds that if x is coerced to $R$ (Expression Integer) than there is a function in $P$, namely::

       if R has Field then
        (p : %) / (r : R) == inv(r) * p

By the way, in Axiom Expression Integer is considered to be a Field.
\begin{axiom}
R has Field
\end{axiom}

Thus $x$ is inverted (and now lies in $R$) and then multiplied with $a$.
There is no further simplification done.

The problematic thing is if the above expression ($a/x$) is not treated carefully enough.
For example, by construction it should by now be clear that it has degree 1.
\begin{axiom}
degree b
\end{axiom}

And it should also be clear that the following two expressions result in different output.
They are even stored differently in the internal structure of $P$.
\begin{axiom}
x*b
(x::R)*b
\end{axiom}
For the first expression, $x$ is converted to the indeterminate $x$ of the polynomial ring $P$.
The interpreter finds an appropriate function::

  *: (%, %) -> %

and applies it.

In the second case, it is explicitly said that $x$ has to be considered as an element of $R$.
The interpreter finds the function with a more appropriate signature, namely::

  *: (R, %) -> %


Be careful with something like that.
\begin{axiom}
d: P := x + (x::R)*1
\end{axiom}
>From the above discussion it should be clear that this expression is that what Axiom was told to do.

Now, a polynomial in $n$ variables is a function (with finite support) 
from the domain of exponents $E=N^n$ (where $N$ is the non-negative integers) to the domain $R$ of coefficients.

\begin{equation}
P = \bigoplus_{e \in E} R
\end{equation}

With such an interpretation, $d$ has support 
(i.e. the set of elements $e \in E$ for which the coefficient of $d$ corresponding to $e$ is non-zero)
\begin{equation}
\{ (1,0), (0,0) \}
\end{equation}
and is therefore **not** equal to the polynomial $2x$ which has support
\begin{equation}
\{ (1,0) \}.
\end{equation}

I Axiom is asked to convert $d$ to an arbitrary expression (Expression Integer),
it will convert both summands of $d$ to $R$ and as such they are, of course, equal.
\begin{axiom}
d::R
\end{axiom}

\start
Date: Tue, 21 Feb 2006 12:33:54 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

>> UnivariateFreeRing2(
>>      R : Join(ArithmeticType, ExpressionType),
>>      RX: UnivariateFreeRing R,
>>      S : Join(ArithmeticType, ExpressionType),
>>      SX: UnivariateFreeRing S
>> ): with {
>> 	map: (R -> S) -> RX -> SX;
>> } == add {
>> 	map(f:R -> S)(p:RX):SX == {
>> 		q:SX := 0;
>> 		for term in p repeat {
>> 			(c, n) := term;
>> 			q := add!(q, f c, n);
>> 		}
>> 		q;
>> 	}
>> }

>> Can you write that in JAVA or CLOS? I would be happy to see it.

> Ignoring for now the details of the Aldor library, why would you
> expect this to be difficult? Java supports functions that return
> functions ...

I'm not so fluent in JAVA, but take for example a semigroup.
Can you do such simple thing as giving an interface for it in JAVA.

define Monoid: Category == with {
   1: %
   *: (%, %) -> %
}

The problem is the "1: %" as a constant (not a nullary function).
An abstract class is no solution since, we might need multiple 
inheritance from various interfaces (imagine to build a Ring afterwards).

Maybe it works to translate UnivariateFreeRing2 to JAVA, but I guess the 
code will look terribly complicated if it incorporates the conditions on 
R and RX, S and SX. Yes, JAVA generics are allowed.
(Well, I shut up, that is not a mailing list about JAVA.)

\start
Date: Tue, 21 Feb 2006 10:26:29 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

>> Martin Rubey wrote: 
>>> I could imagine that some innocent looking computation
>>> would not be correct in the situation above. 
>> As Martin I already imagine this error :
>>
>> P := DMP([x,y], EXPR INT) 
>> a :P := x 
>> b := a/x 
>>
>> differentiate(b,x)                    -- 1/x
> 
> (4) -> differentiate(b,x)
> 
>         1
>    (4)  -
>         x
>    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> I think this result should be classed a bug. The 'differentiate'
> operation apparently makes some incorrect assumptions about the
> coefficient domain. I think the result should be the same as:
> 
> (5) -> differentiate(b::EXPR INT,x)::P
> 
>    (5)  0
>    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

Well, Bill, imagine you had to programm DistributedMultivariatePolynomial.
In gdpoly.spad we see

       differentiate(p: %,v: OV) ==
             multivariate(differentiate(univariate(p,v)),v)

where univariate just converts p to an element of
SparseUnivariatePolynomial(%). (BTW, that's already a trick!)
However, it seems the most obvious thing to do.

Now you suggest to do that differently, since the coefficients of that 
univariate polynomial might also contain the variable x. Well, would be 
possible, but obviously the designer of DMP (or rather GDMP) did not 
think of such a strange thing like having the same variable as the 
indeterminate of the polynomial and at the same time in the domain of 
coefficients.

Still, it's a bug, because that behaviour should at least be very vell 
documented. It is, however, not so clear where to do this. I suggest 
there should be a note in DMP rather than the category 
PartialDifferentialRing (where the signature comes from).

\start
Date: Tue, 21 Feb 2006 12:05:11 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: about Expression Integer

On 02/20/2006 10:02 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> | Hmm, do you call the following object-oriented?
> 
> Yes.
> 
> | (That code appears in libalgebra distributed with Aldor and it
> | basically provides a generic function that given a function "f: R ->
> | S" returns a function "map(f)" of type "RX -> SX" that applies "f" on
> | the coefficients of a univariate polynomial.)
> | 
> | UnivariateFreeRing2(
> |      R : Join(ArithmeticType, ExpressionType),
> |      RX: UnivariateFreeRing R,
> |      S : Join(ArithmeticType, ExpressionType),
> |      SX: UnivariateFreeRing S
> | ): with {
> | 	map: (R -> S) -> RX -> SX;
> | } == add {
> | 	map(f:R -> S)(p:RX):SX == {
> | 		q:SX := 0;
> | 		for term in p repeat {
> | 			(c, n) := term;
> | 			q := add!(q, f c, n);
> | 		}
> | 		q;
> | 	}
> | }
> | 
> | What is the class and what are the methods?
> 
> The class is the collection of "things" that you can "pretend" to be
> univariate polynomials.

Oh, I think that is wrong. The "univariate polynomials" come as a 
parameter and have nothing to do with UnivariateFreeRing2.
As Bill mentioned, if that is considered to be a class, then it has no 
instantiations. It's a package in "Axiom" terms.

> | Sorry that I don't know CLOS,
> 
> The reason why I mention CLOS is that it is close to Lisp (given the
> general topic of this mailing list :-),

Oh, if LISP is the general topic of this mailing list, then I should be 
quiet. ;-)

> | BTW, I don't say that Aldor hasn't some kind of object-orientation,
> | but it is in my opinion not a pure object-oriented language.
> 
> My view is that debates of "pure" <your-favorite-buzzword> are
> meaningless as far as productive system building is concerned.  
> So, I will stop here.

Right. I'll also stop.

\start
Date: 21 Feb 2006 12:53:35 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: about Expression Integer

Ralf Hemmecke writes:

| The problem is the "1: %" as a constant (not a nullary function).

The distinction is largely syntactic, not fundamental.

\start
Date: Tue, 21 Feb 2006 12:21:39 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

> Just curious: The syntax:
> 
>   map(f:R -> S)(p:RX):SX == {...
> 
> looks strangely abbreviated to me. Why not write:
> 
>   map(f:R -> S):RX->SX ==
> 
>    (p:RX):SX +-> { ... 
>  
> Is this equivalent?

Yes.

And to make it even clearer...

In Aldor "==" defines a constant. And the constant here is "map". So it 
should actually be written as

map: (R -> S) -> RX -> SX == {
   (f: R -> S): (RX -> SX) +-> { (p: RX): SX +-> {...} }
}

We all know that functions are first class citizens.

http://www.aldor.org/docs/HTML/chap6.html#5

You probably agree that it is somehow a good thing that the Aldor 
compiler adds a bit of syntactic sugar for such constructions.

\start
Date: Tue, 21 Feb 2006 10:54:03 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

Hello Bill,

> Yes, that is a good idea if you desire to solve the general
> problem of defining a domain in which contains all possible
> expressions as members. Perhaps this is the kind of "userdomain"
> that Jenks and Trager had in mind in the design of BNatural.
> 
> http://wiki.axiom-developer.org/BNatural
> 
> How would this differ from Aldor's ExpressionTree domain?

Ehm...

If I were to program BNatural, I would certainly consider to take 
ExpressionTree from libalgebra. Well that domain is not yet rich enough, 
but it is in some way an approach to forget about types. In libalgebra 
most domains are of type ExpressionType and Parsable.

define ExpressionType: Category == Join(OutputType, PrimitiveType) with {
   extree: % -> ExpressionTree;
   ...
}

define Parsable: Category == InputType with {
	eval:	TREE -> Partial %;
	eval:	LEAF -> Partial %;
	eval:	(MachineInteger, List TREE) -> Partial %;
}

where TREE==>ExpressionTree, LEAF==>ExpressionTreeLeaf.

So one basically has a coercion from and to ExpressionTree.

But I am not so sure whether one should extend ExpressionTree properly 
with any operation you could imagine or rather use some syntax parsing 
code of the Aldor compiler itself. Look at the output of
aldor -fasy foo.as
for some arbitrary program foo.as. One basically has to extract 
"mathematical" expressions and do something reasonable with them. Yes, 
maybe wrap them with something like ExpressionTree.

To be honest, I haven't really thought about that, because I am lacking 
some expertise here.

\start
Date: 21 Feb 2006 13:11:44 +0100
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Time for another crazy idea...
Cc: list

Cliff Yapp writes:

| I know my understanding of categories and domains is massively
| imperfect, so perhaps this idea is not worth much, but since it might
| be one of those cases where an explanation of why its a bad idea might
| be helpful, here we go...
| 
| My understanding of Axiom's concept of categories and domains is that
| it is similar to and at least somewhat compatible with category and/or
| set theory, but it was not explicitly designed to implement and rely
| these theories as a foundation.

An operational view, and I would say actually close to the practice,
is that Axiom/Aldor categories are abstract classes or interfaces, and
Axiom/Aldor domains are implementation classes.  A key distinction
from most OO systems is you can (to some extent) manipulate them as
first class citizens.

|  If that's true, I was wondering what
| sort of effort would be involved in tuning Axiom's use of categories to
| be in line with category theory mathematics, along the lines of things
| like Categories for the Working Mathematician.

I think it would require to turn Axiom/Adlor into a macro system.
I believe Axiom's terminology is very confusing, even if the analogy
with "Category Theory" can be catchy.  Axiom does not rely on
"structures", it relies on OO tagging.  

|  If Axiom is already
| close to this anyway, perhaps the next step could be taken and Axiom
| could relate its category structure directly to research in category
| theory, and turn its own core implementation of mathematical
| fundamentals into a literate document summarizing the research in those
| areas and how it is applied.

I don't know how many students will be attracted that way and how many
researchers will join the movement :-)
I believe the emptyset theory, or in mundain terms Category Theory, is
a good language to talk about structures one *already* understands.
It requires lots of "background" knowledge and examples.  I'm deeply
skeptical about it being well-suited for introducing Computer Algebra.

| Is that a) an insane amount of work and I just don't realize it yet b)
| a non-practical idea in terms of having an actual working CAS or c) all
| of the above?  I always thought the best way to lead off the Algebra
| volumes of Axiom was with a discussion of the fundamental theories of
| mathematics encoded in Axiom and the research they are based off of,
| but perhaps that's not a good approach for Axiom?

You can have a look at Generic Haskell and PolyP for how and what it
takes to get a first approximation of categorical datatypes in a
programming language.

\start
Date: 21 Feb 2006 12:57:12 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: about Expression Integer

Ralf Hemmecke writes:

| On 02/20/2006 10:02 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > | Hmm, do you call the following object-oriented?
| > Yes.
| > | (That code appears in libalgebra distributed with Aldor and it
| > | basically provides a generic function that given a function "f: R ->
| > | S" returns a function "map(f)" of type "RX -> SX" that applies "f" on
| > | the coefficients of a univariate polynomial.)
| > | | UnivariateFreeRing2(
| > |      R : Join(ArithmeticType, ExpressionType),
| > |      RX: UnivariateFreeRing R,
| > |      S : Join(ArithmeticType, ExpressionType),
| > |      SX: UnivariateFreeRing S
| > | ): with {
| > | 	map: (R -> S) -> RX -> SX;
| > | } == add {
| > | 	map(f:R -> S)(p:RX):SX == {
| > | 		q:SX := 0;
| > | 		for term in p repeat {
| > | 			(c, n) := term;
| > | 			q := add!(q, f c, n);
| > | 		}
| > | 		q;
| > | 	}
| > | }
| > | | What is the class and what are the methods?
| > The class is the collection of "things" that you can "pretend" to be
| > univariate polynomials.
| 
| Oh, I think that is wrong.

I don't think so.

| The "univariate polynomials" come as a
| parameter and have nothing to do with UnivariateFreeRing2.

Not quite.  "Univariate polynomial" is a bundle of methods, whether it
is a parameter database or a global database is largely irrelevant.
What is relevant is the structure it exposes both interface and
overridable functions.

\start
Date: Tue, 21 Feb 2006 10:59:09 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

Hello Bill,

> This is good enough for me and apparently to the designers of DMP.
> They do attach the polynomial variables names, but on the other hand
> they also provide the 'vectorize' operator.

I haven't found "vectorize". Which function do you mean?

\start
Date: Tue, 21 Feb 2006 10:16:26 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#268 )abbrev? with too little detail] )help ?	does not work, but )abbreviations ? does!

\begin{axiom}
)abbr domain XYZ
\end{axiom}

\begin{axiom}
)abbrev?
\end{axiom}

The error on the above is the missing space.
However, as shown below, ')abbrev ?' seems really not to have documentation, but ')help ?' had, and is not working in this version of Axiom.

\begin{axiom}
)what commands
)help abbreviations
)abbreviations ?
)help help
)help ?
\end{axiom}

Comparing this with the NAG version, ')what commands', ')help
abbreviations', and ')abbreviations ?' behave the same, but ')help
help' and ')help ?' both print out about three pages of information,
including two Sections A.12. )help, and A.1. Introduction from the
"on-line version of the book". So there probably wasn't any
documentation on ')abbreviations' to begin with.  But ')help ?' should
have worked.

\start
Date: Tue, 21 Feb 2006 13:01:53 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: 1: %

> | The problem is the "1: %" as a constant (not a nullary function).
> 
> The distinction is largely syntactic, not fundamental.

I was once told that in Aldor the difference between
   a: %
and
   b: () -> %
is that
b() will run a program which might side-effect other things or even 
return something different each time.

\start
Date: Tue, 21 Feb 2006 06:02:36 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Time for another crazy idea...

--- Gabriel Dos Reis wrote:

> |  If that's true, I was wondering what
> | sort of effort would be involved in tuning Axiom's use of
> categories to
> | be in line with category theory mathematics, along the lines of
> things
> | like Categories for the Working Mathematician.
> 
> I think it would require to turn Axiom/Adlor into a macro system.
> I believe Axiom's terminology is very confusing, even if the analogy
> with "Category Theory" can be catchy.  Axiom does not rely on
> "structures", it relies on OO tagging.  

Hmm.  macro in the sense of lisp macros or in the sense of a
"metamathematics" system?

> |  If Axiom is already
> | close to this anyway, perhaps the next step could be taken and
> Axiom
> | could relate its category structure directly to research in
> category
> | theory, and turn its own core implementation of mathematical
> | fundamentals into a literate document summarizing the research in
> those
> | areas and how it is applied.
> 
> I don't know how many students will be attracted that way and how
> many researchers will join the movement :-)

Heh.  Maybe we could get some of the CMU guys interested - I think
they've got some folks who are into that kind of stuff.

> I believe the emptyset theory, or in mundain terms Category Theory,
> is a good language to talk about structures one *already* 
> understands. It requires lots of "background" knowledge and
> examples.  I'm deeply skeptical about it being well-suited for
> introducing Computer Algebra.

Do you mean introducing Computer Algebra to students or starting out
the Algebra volumes?  Most subjects are taught "top down" - we start
out with integers in mathematics, and action-reaction in physics, but
both are actually small pieces resting on more complex foundations.  I
think when implementing a powerful CAS system, the logical approach is
bottom up - build your foundations, then build on top of them.  Insofar
as Category Theory or Set Theory respresent foundations on which all of
mathematics can be built, they seem like a logical foundational layer
for the mathematics in Axiom, which strives to be as close to the math
as possible.  B-natural will be the layer that hides the complexity and
provides the normal "CAS" environment, but under the hood would be as
much fundamental mathematical research and power as possible, ready for
use by experts and hard core mathematical researchers.

> | Is that a) an insane amount of work and I just don't realize it yet
> b)
> | a non-practical idea in terms of having an actual working CAS or c)
> all
> | of the above?  I always thought the best way to lead off the
> Algebra
> | volumes of Axiom was with a discussion of the fundamental theories
> of
> | mathematics encoded in Axiom and the research they are based off
> of,
> | but perhaps that's not a good approach for Axiom?
> 
> You can have a look at Generic Haskell and PolyP for how and what it
> takes to get a first approximation of categorical datatypes in a
> programming language.

OK, I'll take a look.  Thanks!  Do you mean an implementation of
categorical datatypes on top of a language or the datatypes as part of
the language definition?

\start
Date: Tue, 21 Feb 2006 12:08:42 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

Hello Bill,

This is about the "x + x" output...

>> I am not really saying that Axiom is doing something wrong, I am
>> just warning that the use of DMP([x,y], Expression Integer) can
>> be misleading for people that don't know how Axiom works internally.
> 
> To write your interpretation above you did not need to know how
> Axiom works internally. If people where equipped with your explanation
> I don't think the result would be misleading. This is the type of
> documentation that I think we need to have for Axiom's library.

See
http://wiki.axiom-developer.org/DistributedMultivariatePolynomial
;-)

\start
Date: Tue, 21 Feb 2006 16:13:01 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

>>        differentiate(p: %,v: OV) ==
>>              multivariate(differentiate(univariate(p,v)),v)
>>
>> where univariate just converts p to an element of
>> SparseUnivariatePolynomial(%). (BTW, that's already a trick!)

> Alternatively, if we are going to allow constructions in which
> the coefficient domain of SUP might contain the polynomial
> variable, then the implementation of 'differentiate' in SUP
> should be corrected.

Look more closely. SUP does not even know of a variable name. So how 
should it do something else than differentiate with respect to the only 
(unamed) variable it has? It's a univariate polynomial in the sense of 
being a function with finite support from the natural numbers to the 
coefficient ring.

\start
Date: Tue, 21 Feb 2006 07:47:16 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Interesting possibility for Axiom+graphviz

http://common-lisp.net/project/cl-graphviz/

\start
Date: 21 Feb 2006 16:34:46 +0100
From: Martin Rubey
To: list
Subject: [ANN] Workshop 2006


                                    _
                                   (_)
                          __ ___  ___  ___  _ __ ___
                         / _` \ \/ / |/ _ \| '_ ` _ \
                        | (_| |>  <| | (_) | | | | | |
                         \__,_/_/\_\_|\___/|_| |_| |_|
                                    _
                                   (_)

         __          ______  _____  _  __ _____ _    _  ____  _____
         \ \        / / __ \|  __ \| |/ // ____| |  | |/ __ \|  __ \
          \ \  /\  / / |  | | |__) | ' /| (___ | |__| | |  | | |__) |
           \ \/  \/ /| |  | |  _  /|  <  \___ \|  __  | |  | |  ___/
            \  /\  / | |__| | | \ \| . \ ____) | |  | | |__| | |
             \/  \/   \____/|_|  \_\_|\_\_____/|_|  |_|\____/|_|

                            ___   ___   ___    __
                           |__ \ / _ \ / _ \  / /
                              ) | | | | | | |/ /_
                             / /| | | | | | | '_ \
                            / /_| |_| | |_| | (_) |
                           |____|\___/ \___/ \___/



                Domain Specific Packages and their Mathematics


with a special focus on


                             Discrete Mathematics


will take place at the RISC institute near Linz from Thursday, May 4 to
Saturday, May 6.

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

Axiom is a Computer Algebra System with a long tradition. It recently became
free software. See http://www.axiom-developer.org.


The workshop aims at a cooperation of Axiom developers with developers of
packages written for other Computer Algebra Systems.


If you would like to attend the workshop, please let us know until Friday,
March 31 at the very latest.


There will be time for a limited number of contributed talks. If you would =
like
to give a talk, please send us title and a short abstract as soon as possib=
le.


There is no conference fee, but it is expected that participants pay
accommodation and meals themselves.  There is a limited number of rooms
available in Hagenberg for approximately 26 EUR/night.

---------------------------------------------------------------------------=

Apart from a crash-course in Axiom/Aldor, the following talks are planned:


Ewgenij Gawrilow

         polymake - experimenting with discrete geometric structures

Nicolas M. Thiery

         Implementing Algebraic Combinatorics -

         some experiences with MuPAD-Combinat

Martin Rubey

         Guessing formulas for sequences

Carsten Schneider

         Sigma - A package for multi-summation


---------------------------------------------------------------------------=

Organisers: Ralf Hemmecke
            Martin Rubey


Email: Martin Rubey

\start
Date: Tue, 21 Feb 2006 08:36:01 -0500
From: Bill Page
To: Doug Stewart
Subject: RE: about Expression Integer

On February 20, 2006 4:16 PM Doug Stewart wrote:
> 
> <snip>
> Wow!!!  I have been watching and learning Axiom for the last 
> two months, and this thread has really help me.

I am glad that this dialogue was helpful to you. :)

> What I have found is that I can pick up Axiom in a simple way
> quite quickly but then I hit a wall that I could not seem to
> get past.

I think your experience is common among new users of Axiom.

> 
> This thread has brought to light what the wall is and has 
> help me muchly.

What is this "wall"? Could you explain it in your own words?

> Could someone in the know take some material from this thread 
> and use it in the manual?

This comment deserves the reaction that you will find in
almost all open source projects: *You* are now the person
"in the know" about what potential Axiom users like you don't
know. So *you* are the best person to extract and reformat
the material from this thread that *you* think would be of
some benefit to new users.

The people who are working up close with the internals of
Axiom often do not appreciate what it is that the new people
don't understand. As a result, the documentation that they
might find time to write is often focused on the wrong issues.
And very often these people are not particularly good at writing
technical prose. Usually these people will interpret suggestions
such as yours in a rather negative manner: You are suggesting
even more work for them and they are already very busy!

And ... we have this wonder tool called a "wiki" that allows
everyone - anyone anywhere in the world - to contribute new
documentation and to update web pages online, in real time.
The hope is that sooner or later the seeds of email exchanges
such as these will fall on some intellectually fertile and
motivated individual who is willing to contribute to the Axiom
project by writing documentation, users' guides and tutorials.
A lot of the content already on the Axiom Wiki

  http://wiki.axiom-developer.org

originated for such emails.

The Axiom Wiki makes it possible for almost anyone to create
documentation. It is easy to create a new page, edit the
contents of exiting pages, give online examples of Axiom
calculations, and even directly edit over-the-web, the contents
of the Axiom source distribution which are written as literate
programming documents.

Almost all open source projects are starving for people with
writing talents and or even people who may not be such good
writers but who do have sufficient motivation to at least make
some kind of contribution. Of the potentially millions of people
around the world who might eventually visit the open source
project web site, there is always the hope that a few of these
people might step forward to help.

> I know that just reading this has opened my eyes.
> 

Reading and replying to email in a long and detailed dialogue
is one thing (quite easy really), but writing good documentation
is another. In fact, in the three year history of the Axiom
open source project we have generated a huge searchable on-line
resource of this sort of dialogue in the axiom-developer archive:

  http://mail.nongnu.org/archive/html/axiom-developer

It is just waiting to be mined by someone devoted to the task
of making more and better documentation available to other Axiom
users.

The open source movement has been called a "gift culture", i.e.
one where one's social standing is at least in part determined
by what one offers freely to others. This is in contrast to
some other forms of cooperation between individuals such as
embodied in commercial proprietary software, where one expects
to get paid for a product or for services rendered.

I think one gift that a lot of us working on Axiom would hope
to receive some day is the contributions of new people who are
willing and able to work on the Axiom documentation.

\start
Date: Tue, 21 Feb 2006 07:45:58 -0800 (PST)
From: Cliff Yapp
To: Bill Page
Subject: RE: Time for another crazy idea...

--- Bill Page wrote:

> So at the very least, Axiom shares this culture and language but
> unfortunately and largely only for historical reasons, Axiom's
> terminology is not well matched to category theory. For example,
> Axiom's categories are not mathematical categories and Axiom's
> objects are not categorical objects. The word functor is used
> in some Axiom literature, but it is not formally defined in the
> same way as a functor in category theory.

Hmm.  That might be worth some consideration when we start thinking
about the Aldor conversion - one of the hardest things for me to do (as
I think the unit discussions in the archives will show) was to actually
define my terms properly (I probably am not all the way there even now)
and it was one of the most important things to do to be able to
communicate effectively.  I think we should try to either use names
that are (at least moderately) common in mathematical and other
research as they are commonly used, or in the worst case clearly define
what we are and are not using the word for in the context of Axiom.  It
will make it FAR easier for researchers to read and use Axiom if they
don't have to re-adjust their understand of common terms (IMHO anyway).
 
> Some researchers have claimed that Axiom can be better formally
> described in terms of the implementation of a many-sorted algebra.
> 
> Loosely speaking, Axiom's domains are a lot like mathematical
> "categories". For example, 'Set' and 'Integer' can both be
> described very accurately as mathematical categories. Domain
> constructors that take domains as arguments such as 'Complex x'
> where 'x' might be 'Integer', are a lot like mathematical
> "functors".

OK, that makes sense.

> I have argued that the concept of 'natural transformation'
> is useful in the definition of the semantics of the 'rep' and
> 'per' construction that is fundamental to the way that Axiom
> and Aldor implement domains.
> 
> http://wiki.axiom-developer.org/RepAndPer
> 
> But with all that said, it is still my opinion that Axiom is
> more that just "somewhat compatible with category theory". I
> think large parts of Axiom and specifically the semantics of
> Axiom's programming language can be formally and accurately
> described using category theory.

That would be awesome, and I suspect might appeal to hard core
mathematical researchers.

> I don't think this is a crazy idea. In fact, this was one of
> my own motivations for becoming deeply involved in Axiom. Other
> people have also expressed similar ideas about Axiom and Aldor.
> See for example:
> 
> http://physics.bu.edu/~youssef/aldor/aldor.html
> 
> and also look for "category theory" mentioned in the axiom-developer
> archives.

Interesting!  Will do.

> > Is that a) an insane amount of work and I just don't realize it yet
> 
> I think completing this programme (of reformulating Axiom on a sound
> category theory basis) would be a lot of work. But I think there
> are a lot of useful things would can do with category theory in
> the context of Axiom without going this far.

:-)

> > b) a non-practical idea in terms of having an actual working CAS 
> > or
> 
> I think it is very practical and I would be quite willing to
> help in any efforts along this line.
> 
> > c) all of the above?  I always thought the best way to lead off
> > the Algebra volumes of Axiom was with a discussion of the
> > fundamental theories of mathematics encoded in Axiom and the
> > research they are based off of, but perhaps that's not a good
> > approach for Axiom?
> 
> Category theory at least provides a uniform language in which
> to express most of the mathematics implemented in Axiom. 

I think that sentence is probably the best summary I have seen or heard
which tells me that Axiom based on category theory is a good idea. 
Axiom would be much more easily understood in whole and part with that
unifying language as a common theme, at least IMHO.

> But documentation exclusively and formally based on category might
> not be to everyone's taste, even though it is widely used in
> mathematics and increasingly in computer science. Probably we
> need to be more flexible and suit the kind of documentation to
> the subject according to current fashion.

Right.  My thinking on the subject was that, beyond the core
implementation of category theory and categories, mathematics done
within that framework (e.g. most of the work) wouldn't need to be
explicitly based on category theory.  It would need to fit within the
framework of course, but one of the main attractions of category theory
as a tool is that it can fit so much within its framework.

> > I'm going to finish a unit and dimension implementation before
> > I even think about tackling something that crazy, but I figured
> > if it's a really Nutty idea I should find out now ;-)
> 
> I also look forward to your completion of the work on units and
> dimensions in Axiom, but it doesn't hurt to *think* about other
> subjects. :)

Actually, I guess the units package is kind of at fault for this train
of thought, not just for the language definition issues but for making
me read up on groups. ;-)

\start
Date: Tue, 21 Feb 2006 09:59:44 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: about Expression Integer

On February 21, 2006 4:26 AM Ralf Hemmecke
> >> ...
> >> P := DMP([x,y], EXPR INT) 
> >> a :P := x 
> >> b := a/x 
> >>
> >> differentiate(b,x)                    -- 1/x
> > 
> > (4) -> differentiate(b,x)
> > 
> >         1
> >    (4)  -
> >         x
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> > 
> > I think this result should be classed a bug. The 'differentiate'
> > operation apparently makes some incorrect assumptions about the
> > coefficient domain. I think the result should be the same as:
> > 
> > (5) -> differentiate(b::EXPR INT,x)::P
> > 
> >    (5)  0
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> Well, Bill, imagine you had to programm
> DistributedMultivariatePolynomial.
> In gdpoly.spad we see
> 
>        differentiate(p: %,v: OV) ==
>              multivariate(differentiate(univariate(p,v)),v)
> 
> where univariate just converts p to an element of
> SparseUnivariatePolynomial(%). (BTW, that's already a trick!)
> However, it seems the most obvious thing to do.
> 
> Now you suggest to do that differently, since the 
> coefficients of that univariate polynomial might also
> contain the variable x.

I haven't looked any more deeply in the source code than this
but if it was already well documented that SUP requires that no
variables occur in the coefficient domian, then I think I would
prefer that the conversion to SUP take account of the fact that
the polynomial coefficients might contain variables in the same
way that the coercion to EXPR INT in the example (5) above does.

Alternatively, if we are going to allow constructions in which
the coefficient domain of SUP might contain the polynomial
variable, then the implementation of 'differentiate' in SUP
should be corrected.

> Well, would be possible, but obviously the designer of DMP
> (or rather GDMP) did not think of such a strange thing like
> having the same variable as the indeterminate of the polynomial
> and at the same time in the domain of coefficients.
>

I agree that the usage is obscure but it still seems to me to
be an error in the implementation of either 'univariate' in the
code you quoted above or 'differentiate' in SUP.
 
> Still, it's a bug, because that behaviour should at least be 
> very vell documented. It is, however, not so clear where to do
> this. I suggest there should be a note in DMP rather than the
> category PartialDifferentialRing (where the signature comes from).
> 

I agree.

\start
Date: Tue, 21 Feb 2006 12:01:21 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: about Expression Integer

Ralf,

On February 21, 2006 10:13 AM you wrote:
> 
> 
> >>        differentiate(p: %,v: OV) ==
> >>              multivariate(differentiate(univariate(p,v)),v)
> >>
> >> where univariate just converts p to an element of
> >> SparseUnivariatePolynomial(%). (BTW, that's already a trick!)
> 
> > Alternatively, if we are going to allow constructions in which
> > the coefficient domain of SUP might contain the polynomial
> > variable, then the implementation of 'differentiate' in SUP
> > should be corrected.
> 
> Look more closely. SUP does not even know of a variable name.
> So how should it do something else than differentiate with respect 
> to the only (unamed) variable it has? It's a univariate polynomial
> in the sense of being a function with finite support from the
> natural numbers to the coefficient ring.
> 

I am looking at:

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

and

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

but I am confused by this result:

(1) -> S:=SUP EXPR INT

   (1)  SparseUnivariatePolynomial Expression Integer
   Type: Domain

(2) -> ex1:=(x^2+1)$S

         2
   (2)  x  + 1
   Type: SparseUnivariatePolynomial Expression Integer

(3) -> differentiate(ex1)$S

   (3)  0
   Type: SparseUnivariatePolynomial Expression Integer

Ok, so 'differentiate$SUP' treated 'x^2+1' as being in the
coefficient domain, right? But:

(4) -> differentiate(ex1,x)$S

   (4)  2x
   Type: SparseUnivariatePolynomial Expression Integer

')set message bottomup on' shows that 'differentiate' with
signature '(SUP EXPR INT,SYMBOL) -> SUP EXPR INT' is called
from SUP.

(4) -> differentiate(ex1,x)$S

 Function Selection for differentiate
      Arguments: (SUP EXPR INT,VARIABLE x)
      Target type: SUP EXPR INT
      From:      SUP EXPR INT
   -> no appropriate x found in Expression Integer
   -> no appropriate x found in Integer
   -> no appropriate x found in Expression Integer
   -> no appropriate x found in Integer

 [1]  signature:   (SUP EXPR INT,SYMBOL) -> SUP EXPR INT
      implemented: slot $$(Symbol) from SUP EXPR INT

This function seems to come from 'DifferentialExtension' in

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

and this seems correct to me. So I am confused as to why
'differentiate(univariate(p,v))' does not seem to yield this
same result. Can you help?

It seems to me that the interrelationship between all of these
polynomial categories, domains and packages is remarkably
convoluted. I am not saying necessarily that it does not have
to be this complicated, but certainly we would all benefit
greatly if this could be clearly and completely documented.

\start
Date: 21 Feb 2006 18:11:38 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: 1: %

Ralf Hemmecke writes:

| > | The problem is the "1: %" as a constant (not a nullary function).
| > The distinction is largely syntactic, not fundamental.
| 
| I was once told that in Aldor the difference between
|    a: %
| and
|    b: () -> %
| is that
| b() will run a program which might side-effect other things or even
| return something different each time.

yes, if the body of b() is defined so.  But not all b() are affected
by that artifact.  But it is not a fundamental or intrinsic
distinction that would have to cary to other languages.

\start
Date: Tue, 21 Feb 2006 09:30:01 -0500
From: William Sit
To: Francois Maltey
Subject: Re: about Expression Integer

Francois Maltey wrote:
> 
> Hello,
> 
> Thanks for previous help,
> now I can compile a package and add spy-print inside !
> 
> I play whith expressions and I have theses questions :
> 
> 1/ Can I (or cannot) remain Expressions as
> 
> x+1/(y+1)
> y+1/(x+1)
> 
> and do not have a single denominator.

Please see SandBoxPartialFraction.

\start
Date: Tue, 21 Feb 2006 11:25:15 -0500
From: Bill Page
To: David Mentre, Tim Daly
Subject: RE: ASDF and ./configure (was: Re: Hyper doc search error)

On February 21, 2006 2:54 AM David Mentre wrote:

> ...
> I think a hand-written ./configure is the way to go, contrary
> to Bill's idea of using autoconf. I'll make my own proposal
> and then the Axiom Community will decide.

Actually, the subject came up most recently in reply to Gaby,
so I think I would prefer to call it "Gaby's idea" :)

I am not against the use of a hand-written ./configure although
this is exactly what we are already using. So in this case your
proposal amounts to making (possibly major) improvements to the
approach that we are already using.

The autoconf tools, however provide lot of standardized and
often tested ways to properly detect the environment. These
same tools can even be used on Windows. I think that it would
be a pity to have to re-invent all of this just to make the
installation of Axiom more flexible and less error prone.

The main complication is that the Axiom source distribution
consists (almost) exclusively of pamphlet files. Before these
can be processed by any other utility, they must first be
processed with noweb tangle to extract the relevant parts.
I think this means that any ./configure has to have at least
some initial part that depends on a handwritten script.

> 
> And I should underline that I believe more in consensus than
> everything else. So the final build system will probably be a
> mix between Bill's ideas, mines and yours. :-)
> 

I am also not that against using something like ASDF for the
lisp parts of Axiom. But I am strongly against twisting the
rest of Axiom to make it fit into this tool. It seems to me
that the configuration of the lisp part of Axiom is much less
of a problem than the other parts - most of which are in "C"
anyway. And GCL already uses autoconf to configure the build
of lisp that is embedded in the standard (non-Debian) Axiom
distribution.

\start
Date: 21 Feb 2006 18:06:57 +0100
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Time for another crazy idea...

Cliff Yapp writes:

| > |  If that's true, I was wondering what
| > | sort of effort would be involved in tuning Axiom's use of
| > categories to
| > | be in line with category theory mathematics, along the lines of
| > things
| > | like Categories for the Working Mathematician.
| > 
| > I think it would require to turn Axiom/Adlor into a macro system.
| > I believe Axiom's terminology is very confusing, even if the analogy
| > with "Category Theory" can be catchy.  Axiom does not rely on
| > "structures", it relies on OO tagging.  
| 
| Hmm.  macro in the sense of lisp macros or in the sense of a
| "metamathematics" system?

I would say between lisp macros and C macros. 

[...]

| Do you mean introducing Computer Algebra to students or starting out
| the Algebra volumes?


[...]

| > You can have a look at Generic Haskell and PolyP for how and what it
| > takes to get a first approximation of categorical datatypes in a
| > programming language.
| 
| OK, I'll take a look.  Thanks!  Do you mean an implementation of
| categorical datatypes on top of a language or the datatypes as part of
| the language definition?

the latter.

\start
Date: Tue, 21 Feb 2006 12:21:53 -0500
From: Bill Page
To: Bill Page,
Subject: RE: about Expression Integer

On February 21, 2006 12:01 PM I wrote:

On February 21, 2006 10:13 AM you wrote:
> 
> 
> >>        differentiate(p: %,v: OV) ==
> >>              multivariate(differentiate(univariate(p,v)),v)
> >>
>
> ... 
> I am looking at:
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/PolySpad
> 
> and
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/PolycatSpad
> 
> but I am confused by this result:
> 
> (1) -> S:=SUP EXPR INT
> 
>    (1)  SparseUnivariatePolynomial Expression Integer
>    Type: Domain
> 
> (2) -> ex1:=(x^2+1)$S
> 
>          2
>    (2)  x  + 1
>    Type: SparseUnivariatePolynomial Expression Integer
> 
> (3) -> differentiate(ex1)$S
> 
>    (3)  0
>    Type: SparseUnivariatePolynomial Expression Integer
> 
> Ok, so 'differentiate$SUP' treated 'x^2+1' as being in the
> coefficient domain, right? But:
> 
> (4) -> differentiate(ex1,x)$S
> 
>    (4)  2x
>    Type: SparseUnivariatePolynomial Expression Integer
> 
> ')set message bottomup on' shows that 'differentiate' with
> signature '(SUP EXPR INT,SYMBOL) -> SUP EXPR INT' is called
> from SUP.
> 
> (4) -> differentiate(ex1,x)$S
> 
>  Function Selection for differentiate
>       Arguments: (SUP EXPR INT,VARIABLE x)
>       Target type: SUP EXPR INT
>       From:      SUP EXPR INT
>    -> no appropriate x found in Expression Integer
>    -> no appropriate x found in Integer
>    -> no appropriate x found in Expression Integer
>    -> no appropriate x found in Integer
> 
>  [1]  signature:   (SUP EXPR INT,SYMBOL) -> SUP EXPR INT
>       implemented: slot $$(Symbol) from SUP EXPR INT
> 
> This function seems to come from 'DifferentialExtension' in
> 
> http://wiki.axiom-developer.org/axiom--test--1/src/algebra/CatdefSpad
> 
> and this seems correct to me. So I am confused as to why
> 'differentiate(univariate(p,v))' does not seem to yield this
> same result. Can you help?
> 

Oh! Re-reading this I just noticed something.

Shouldn't this differentiation be written
'differentiate(univariate(p,v),v)' in SUP:

        differentiate(p: %,v: OV) ==
              multivariate(differentiate(univariate(p,v),v),v)

-------

That should allow the differentiation of any expressions occuring
in the underlying Ring.

\start
Date: Tue, 21 Feb 2006 11:04:03 -0800 (PST)
From: Cliff Yapp
To: David Mentre
Subject: Re: ASDF and ./configure

FWIW, the Maxima setup uses a combination of autoconf and defsystem.  I
have found that this works pretty well, personally.

\start
Date: Tue, 21 Feb 2006 09:35:12 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: about Expression Integer

On February 21, 2006 4:59 AM Ralf Hemmecke asked:
> 
> > This is good enough for me and apparently to the designers of DMP.
> > They do attach the polynomial variables names, but on the other hand
> > they also provide the 'vectorize' operator.
> 
> I haven't found "vectorize". Which function do you mean?
> 

I am sorry. I should have written 'vectorise'. See within:

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

\start
Date: Tue, 21 Feb 2006 09:36:44 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: about Expression Integer

Ralf,

On February 21, 2006 6:09 AM you wrote:
> ... 
> See
> http://wiki.axiom-developer.org/DistributedMultivariatePolynomial
> ;-)
> 

Thanks! I think your description is excellent.

\start
Date: Tue, 21 Feb 2006 09:27:41 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Time for another crazy idea...

On February 20, 2006 6:39 PM C Y wrote:
> ... 
> My understanding of Axiom's concept of categories and domains is
> that it is similar to and at least somewhat compatible with category
> and/or set theory, but it was not explicitly designed to implement
> and rely these theories as a foundation.

I think a more accurate characterization might be that Axiom was
developed by people who were very much aware of the abstract
foundations of mathematics in which set theory is one of the
main historical pillars. But Axiom was also developed at a time
that a lot of these historical foundations were being re-considered
by category theorists. In the mean time other people have become
interested in formal foundations for computer science and programming
languages and it has turned out that category is also very useful
for here. And in principle category theory is a good match with
computer algebra systems because in most respects category theory
is essential algebraic.

So at the very least, Axiom shares this culture and language but
unfortunately and largely only for historical reasons, Axiom's
terminology is not well matched to category theory. For example,
Axiom's categories are not mathematical categories and Axiom's
objects are not categorical objects. The word functor is used
in some Axiom literature, but it is not formally defined in the
same way as a functor in category theory.

Some researchers have claimed that Axiom can be better formally
described in terms of the implementation of a many-sorted algebra.

Loosely speaking, Axiom's domains are a lot like mathematical
"categories". For example, 'Set' and 'Integer' can both be
described very accurately as mathematical categories. Domain
constructors that take domains as arguments such as 'Complex x'
where 'x' might be 'Integer', are a lot like mathematical
"functors".

I have argued that the concept of 'natural transformation'
is useful in the definition of the semantics of the 'rep' and
'per' construction that is fundamental to the way that Axiom
and Aldor implement domains.

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

But with all that said, it is still my opinion that Axiom is
more that just "somewhat compatible with category theory". I
think large parts of Axiom and specifically the semantics of
Axiom's programming language can be formally and accurately
described using category theory.

> If that's true, I was wondering what sort of effort would be
> involved in tuning Axiom's use of categories to be in line with
> category theory mathematics, along the lines of things like
> Categories for the Working Mathematician.  If Axiom is already
> close to this anyway, perhaps the next step could be taken and Axiom
> could relate its category structure directly to research in category
> theory, and turn its own core implementation of mathematical
> fundamentals into a literate document summarizing the research
> in those areas and how it is applied.

I don't think this is a crazy idea. In fact, this was one of
my own motivations for becoming deeply involved in Axiom. Other
people have also expressed similar ideas about Axiom and Aldor.
See for example:

http://physics.bu.edu/~youssef/aldor/aldor.html

and also look for "category theory" mentioned in the axiom-developer
archives.

The Saunders Mac Lane book "Categories for the Working Mathematician"

http://www.amazon.com/gp/product/0387984038

is now a little "dated" in it's approach although still widely
regarded as having established the foundations for the whole
subject. From the point of view of applications of category theory
in computer science, I think there are several better books for
the beginner, e.g.

 Basic Category Theory for Computer Scientists
 by Benjamin C. Pierce
 http://www.amazon.com/gp/product/0262660717

> 
> Is that a) an insane amount of work and I just don't realize it yet

I think completing this programme (of reformulating Axiom on a sound
category theory basis) would be a lot of work. But I think there
are a lot of useful things would can do with category theory in
the context of Axiom without going this far.

> b) a non-practical idea in terms of having an actual working CAS 
> or

I think it is very practical and I would be quite willing to
help in any efforts along this line.

> c) all of the above?  I always thought the best way to lead off
> the Algebra volumes of Axiom was with a discussion of the
> fundamental theories of mathematics encoded in Axiom and the
> research they are based off of, but perhaps that's not a good
> approach for Axiom?

Category theory at least provides a uniform language in which
to express most of the mathematics implemented in Axiom. But
documentation exclusively and formally based on category might
not be to everyone's taste, even though it is widely used in
mathematics and increasingly in computer science. Probably we
need to be more flexible and suit the kind of documentation to
the subject according to current fashion.

> 
> I'm going to finish a unit and dimension implementation before
> I even think about tackling something that crazy, but I figured
> if it's a really Nutty idea I should find out now ;-)
> 

I also look forward to your completion of the work on units and
dimensions in Axiom, but it doesn't hurt to *think* about other
subjects. :)

\start
Date: 21 Feb 2006 20:59:21 +0100
From: Gabriel Dos Reis
To: David Mentre
Subject: Re: ASDF and ./configure (was: Re: Hyper doc search error)

David Mentre writes:

[...]

| > But a "rewrite the world" solution is likely to get a lot of pushback.
| > Propose something and we can all comment on it.
| 
| Sure, I'm reading Bill's posts. ;-) I think a hand-written ./configure
| is the way to go, contrary to Bill's idea of using autoconf.

I share Bill's idea.  Having a configure script generated from autoconf
does not mean we can't have our own say -- one can include custom
variations in configure.ac or aclocal.m4.  My guess is that a hand written
configure will try to approximate standard, widely-tested, Autoconf
functionalities with the burden of maintainance on Axiom instead of
the porting community which is already doing the work.  That does not
sound right ot me.  I have a good experience with Autoconf and large
systems, I appreciate the pecularities of Axiom but I don't think
Autoconf is antagonistic to Axiom requirements.  Furtheremore, I don't
believe Autoconf is a C-only solution -- but hey, it is true that I've
developped more with C-family languages than lisp :-)

| I'll make
| my own proposal and then the Axiom Community will decide.

\start
Date: Tue, 21 Feb 2006 16:04:05 -0600
From: MathAction (hemmecke)
To: MathAction
Subject: [ExpressionInteger] (new) 

Similar to the warning given for arguments of
DistributedMultivariatePolynomial, here is another warning about the
use of Expression Integer.

Disclaimer: The page has been created to be helpful.  But it might
contain explanations that are based on misunderstandings by the
author.  In any case the best source of information is the source code
itself, but since the Expression domain is quite complex, any attempt
to document it well is welcome.


Expression Integer is a domain that is (like Polynomial Integer)
mainly useful at the Axiom command line.  Roughly, any mathematical
expression in Axiom can be converted to Expression Integer.  Thus,
although, Axiom currently does not forbid to construct other domains
that use Expression Integer as a parameter, such constructions should
be done with utmost care since they might result in unexpected
behaviour.

Take, for example, the domain constructor SparseUnivariatePolynomial.
According to its definition in src/algebra/poly.spad, it takes a ring
$R$ as argument and constructs a univariate polynomial ring $P$ over
$R$. In other words, if

\begin{axiom}
R := Expression Integer
P := SparseUnivariatePolynomial R
\end{axiom}

then

\begin{equation}
P = \bigoplus_{n\in N} R
\end{equation}

where $N$ is the set of non-negative integers.  In particular, $P$
does not have any concept of a named indeterminate.  Axiom shows this
by printing a question mark as the name of that indeterminate.

\begin{axiom}
z: P := monomial(1, 1)
\end{axiom}

The following should come as no surprise.
\begin{axiom}
a: P := x::P
b: Boolean := a=z
degree a
degree z
\end{axiom}

Let us analyze the assignment of $a$.  The interpreter has to
determine what to do with the letter $x$.  Obviously, the interpreter
has no way to figure out that $x$ should be treated as the
indeterminate of $P$.  It is clearly impossible, since the
indeterminate of $P$ has no name.  The best thing the interpreter can
to is to coerce $x$ to an element of $R$.  That is possible, since
basically every mathematical expression is of type Expression Integer.
Now, coercing $x$ as an element of $R$ to $P$ is simple, since $R$ is
the coefficient domain of $P$.  That explains also why the degree of
$a$ is zero.

Since the $a$ is of degree zero, the following is also understandable.
\begin{axiom}
differentiate a
differentiate z
\end{axiom}

Differentiation is done with respect to the only variable $P$ knows
(namely the unnamed one).  That is the reason why differentiate does
not need a second argument.

Now let us consider the following.
\begin{axiom}
differentiate(a,x)
differentiate(z,x)
differentiate(z,y)
\end{axiom}

Each time we get 1 as a result. That is strange. It would be more
appropriate if the first gives 1 and the other two give 0.  So let try
to make it more obvious what happens.

\begin{axiom}
differentiate(a^2,x)
differentiate(a^2,y)
differentiate(z^2,x)
differentiate(z^2,y)
\end{axiom}

Interestingly, the result tells us that in the first two cases
differentiation is basically done in $R$ and the result is as we
expect it to be.  In the second two cases, the differentiation is
basically equivalent to differentiation with respect to the unnamed
indeterminate.

\begin{axiom}
differentiate(z^2)
\end{axiom}
If this is not considered a bug, then it is at least an inconsistency with
\begin{axiom}
b: Boolean := (x::P) = (y::P)
\end{axiom}

Then the following is also clear, but maybe not really as expected.
\begin{axiom}
differentiate(z^2*a^3,x)
differentiate(z^2*a^3,y)
\end{axiom}

\start
Date: Tue, 21 Feb 2006 22:53:02 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

> (4) -> differentiate(ex1,x)$S

> This function seems to come from 'DifferentialExtension'

No. I rather think it comes from 'PartialDifferentialRing(Symbol)'.
Look at Hyperdoc. Browse SUP and view Operations->Origins (Filter 
"differentiate").

> So I am confused as to why
> 'differentiate(univariate(p,v))' does not seem to yield this
> same result. Can you help?

Not really. I think there is a bug here, since x is sometimes treated as 
the indeterminate of SUP and sometimes not.

> It seems to me that the interrelationship between all of these
> polynomial categories, domains and packages is remarkably
> convoluted.

I don't really think so. The problematic thing is to take
"Expression Integer" as an argument in the construction of SUP.

Could you explain in which sense SUP(Expression Integer) should be 
semantically different from Expression(Integer)?

Isn't an element of SUP(Expression Integer) also an expression?
It is obvious that Axiom can construct SUP(Expression Integer), but does 
this make sense?

I do not fully understand the "Expression" constructor, but I somehow 
consider it as a domain that contains every expression. Therefore, I 
think constructing higher domains that are built on Expression should 
not yield a bigger class than Expression itself.

What would be the relation between
SUP(Expression Integer) and Expression(Integer) on a semantic level?
Equality, subset, superset?

\start
Date: 22 Feb 2006 00:21:37 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: 1: %

Ralf Hemmecke writes:

| > | The problem is the "1: %" as a constant (not a nullary function).
| > The distinction is largely syntactic, not fundamental.
| 
| I was once told that in Aldor the difference between
|    a: %
| and
|    b: () -> %
| is that
| b() will run a program which might side-effect other things or even
| return something different each time.

expanding on my preivous answer, have a look at the section 5.2 os the
Aldor user guide on literal forming -- you can define your own function
to interpret a string literal as a constant.

\start
Date: Tue, 21 Feb 2006 18:41:37 -0500
From: Bill Page
To:  Ralf Hemmecke
Subject: RE: about Expression Integer

On February 21, 2006 4:53 PM Ralf Hemmecke wrote:
> ...
> > (4) -> differentiate(ex1,x)$S
>
> > This function seems to come from 'DifferentialExtension'
>
> No. I rather think it comes from 'PartialDifferentialRing(Symbol)'.
> Look at Hyperdoc. Browse SUP and view Operations->Origins (Filter
> "differentiate").

I think Hyperdoc is confused.

>From http://wiki.axiom-developer.org/axiom--test--1/src/algebra/PolySpad

SparseUnivariatePolynomial(R:Ring): UnivariatePolynomialCategory(R) with =
...

>From =
http://wiki.axiom-developer.org/axiom--test--1/src/algebra/PolycatSpad

UnivariatePolynomialCategory(R:Ring): Category ==
 Join(PolynomialCategory(R, NonNegativeInteger, SingletonAsOrderedSet),
      Eltable(R, R), Eltable(%, %), DifferentialRing,
      DifferentialExtension R) with ...

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

DifferentialExtension(R:Ring): Category == Ring with ...
    if R has PartialDifferentialRing(Symbol) then
             PartialDifferentialRing(Symbol)
  add ...

    if R has PartialDifferentialRing Symbol then
      differentiate(x:%, v:Symbol):% ==
        differentiate(x, differentiate(#1, v)$R)

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

>
> > So I am confused as to why
> > 'differentiate(univariate(p,v))' does not seem to yield this
> > same result. Can you help?
>

I think what we need really is:

  differentiate(univariate(p),v)

but I am having a disagreement with SPAD about how to write this.
See:

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

> Not really. I think there is a bug here, since x is sometimes
> treated as the indeterminate of SUP and sometimes not.

This makes sense to me:

  'x' is an indeterminante (kernel?) of 'SUP(R:Ring)' if 'x' is
  an indeterminante of R,

i.e. by extension in the same sense in which differentiation
is extended to SUP, see ')sh SUP':

  differentiate : (%,Symbol) -> % if R has PDRING SYMBOL

But the list of indeterminantes of 'SUP' can be larger than the
list of variables (fixed at 1 and denoted '?' for 'SUP').

Maybe that is a bit confusing compared to common usage. :(

>
> > It seems to me that the interrelationship between all of these
> > polynomial categories, domains and packages is remarkably
> > convoluted.
>
> I don't really think so. The problematic thing is to take
> "Expression Integer" as an argument in the construction of SUP.
>
> Could you explain in which sense SUP(Expression Integer) should be
> semantically different from Expression(Integer)?

SUP(Expression Integer) has an extra (but unspecified) variable:
the "polynomial variable".

>
> Isn't an element of SUP(Expression Integer) also an expression?

No, only the members of 'SUP(EXPR INT)' of degree 0. For example:

   monomial(x,1)$SUP EXPR INT

cannot be converted to 'EXPR INT'.

> It is obvious that Axiom can construct SUP(Expression Integer),
> but does this make sense?

Yes, I think so.

>
> I do not fully understand the "Expression" constructor, but
> I somehow consider it as a domain that contains every expression.

No. The 'Rep' of 'Expression x' is 'FRAC MPOLY x'. It cannot
possibly contain every expression.

> Therefore, I think constructing higher domains that are built on
> Expression should not yield a bigger class than Expression itself.
>

Unfortunately 'Expression' is not a "GeneralExpression" or even
Aldor's 'ExpressionTree'. But I agree that really Axiom needs a
'GeneralExpression' of this kind.

> What would be the relation between SUP(Expression Integer) and
> Expression(Integer) on a semantic level? Equality, subset, superset?
>

There is a sense in which 'EXPR INT' is a SubDomain of 'SUP EXPR INT'
in so much as it is always possible to coerce a member of 'EXPR INT'
to 'SUP EXPR INT' but the reverse conversion is only possible for
members of 'SUP EXPR INT' of degree 0.

\start
Date: 22 Feb 2006 04:54:39 +0100
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Time for another crazy idea...
Cc: list

Cliff Yapp writes:

[...]

|                           I think we should try to either use names
| that are (at least moderately) common in mathematical and other
| research as they are commonly used, or in the worst case clearly define
| what we are and are not using the word for in the context of Axiom.  It
| will make it FAR easier for researchers to read and use Axiom if they
| don't have to re-adjust their understand of common terms (IMHO anyway).

Indeed.  That speaks for NOT using 'category' and 'object' when, in
fact, we are talking of things that are different from 'category' and
'object' as used in the math litterature.

\start
Date: 22 Feb 2006 09:54:21 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: about Expression Integer

Dear Bill, Ralf, *

I'm currently out of time. But I'm a little afraid of the direction the
discussion takes currently.

I believe that the intension of a constructor like DMP is to cover
*polynomials*.

If we allow (2*x+1/x)::DMP([x], EXPR INT), i.e., allowing 1/x as a coefficient,
then it must be clear that the "x" in 1/x is something different than the "x"
in 2*x. Otherwise we don't get a polynomial, obviously.

So, I think that

> > P := DMP([x,y], EXPR INT) 
> > a :P := x 
> > b := a/x 
> > 
> > differentiate(b,x)                    -- 1/x
> 
> (4) -> differentiate(b,x)
> 
>         1
>    (4)  -
>         x
>    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> 
> I think this result should be classed a bug. The 'differentiate'
> operation apparently makes some incorrect assumptions about the
> coefficient domain. I think the result should be the same as:

is not a bug. If you want to have axiom output 0, then I imagine that you will
get into trouble with writing packages, variable capture might well occur.

I'd rather say that b::EXPR INT giving one is troublesome. I wouldn't really
classify it as a bug though, given the nature of EXPR INT. Note that b::UP([x],
INT) or b::POLY INT give errors!

PLEASE don't change the behaviour of DMP and company. What should be documented
(and I think Ralf did, but I hadn't time) is that domains like POLY EXPR INT
and friends can lead to "surprising" results. This should go into the section
"types" of the axiom book.

\start
Date: Wed, 22 Feb 2006 11:57:10 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: 1: %

On 02/22/2006 12:21 AM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> | > | The problem is the "1: %" as a constant (not a nullary function).
> | > The distinction is largely syntactic, not fundamental.
> | 
> | I was once told that in Aldor the difference between
> |    a: %
> | and
> |    b: () -> %
> | is that
> | b() will run a program which might side-effect other things or even
> | return something different each time.
> 
> expanding on my preivous answer, have a look at the section 5.2 os the
> Aldor user guide on literal forming -- you can define your own function
> to interpret a string literal as a constant.

I knew about this Literal stuff before...

http://lists.gnu.org/archive/html/axiom-developer/2006-02/msg00154.html

But as you see, if you write a domain that has a function
string: Literal -> %,
it is a function and that means that "1" and "1" need not give identical 
values.

The following program prints 11 and 12.

-- aldor -laldor -grun domaintest.as
--BEGIN domaintest.as
#include "aldor"
DomainTest: with {
   integer: Literal -> %;
   coerce: % -> Integer;
} == add {
   Rep == Integer;
   local n: Integer := 0;
   integer(l: Literal): % == {
     i: Integer := integer(l)$Integer;
     free n := n + 1;
     per (i + n);
   }
   coerce(x: %): Integer == rep x;
}
main(): () == {
   import from TextWriter, Character, Integer;
   a: DomainTest := 10;
   b: DomainTest := 10;
   stdout << (a::Integer) << newline;
   stdout << (b::Integer) << newline;
}
main();



\start
Date: 22 Feb 2006 16:06:50 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Time for another crazy idea...

Bill Page writes:

[...]

| is now a little "dated" in it's approach although still widely
| regarded as having established the foundations for the whole
| subject. From the point of view of applications of category theory
| in computer science, I think there are several better books for
| the beginner, e.g.
| 
|  Basic Category Theory for Computer Scientists
|  by Benjamin C. Pierce
|  http://www.amazon.com/gp/product/0262660717

I usually recommend Barr and Wells' to students.

\start
Date: Wed, 22 Feb 2006 17:01:42 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: 1: %

Dear Gaby,

On 02/22/2006 04:00 PM, Gabriel Dos Reis wrote:
> Ralf Hemmecke writes:
> 
> | On 02/22/2006 12:21 AM, Gabriel Dos Reis wrote:
> | > Ralf Hemmecke writes:
> | > | > | The problem is the "1: %" as a constant (not a nullary
> | > function).
> | > | > The distinction is largely syntactic, not fundamental.
> | > | | I was once told that in Aldor the difference between
> | > |    a: %
> | > | and
> | > |    b: () -> %
> | > | is that
> | > | b() will run a program which might side-effect other things or even
> | > | return something different each time.
> | > expanding on my preivous answer, have a look at the section 5.2 os
> | > the
> | > Aldor user guide on literal forming -- you can define your own function
> | > to interpret a string literal as a constant.
> | 
> | I knew about this Literal stuff before...
> 
> I have no doubt about that :-)
> 
> | http://lists.gnu.org/archive/html/axiom-developer/2006-02/msg00154.html
> | 
> | But as you see, if you write a domain that has a function
> | string: Literal -> %,
> | it is a function and that means that "1" and "1" need not give
> | identical values.
> 
> yes, that is precisely why I said in an earlier message that the
> distinction is largely syntactic.  it is not something fundamental in
> the context of your discussion about axiom and o stuff.
> Underneath, everything is a function in Aldor!

Well, it might depend on which level you look at it. If the generated C 
code is concerned, I have no idea about that.

But if it were really just syntactic, then the output given below is 
strange.

However, this behaviour is exactly, the difference between a constant 
and a nullary function in Aldor.

Aldor computes the value for x at the time the domain is instantiated. 
So it is constant over the lifetime of the domain (unless some dirty 
tricks change that value). For y it is different. That is a function 
constant. But a constant of type ()->% not of type %. Now, of course, if 
you say "y()", you get something of type %. But each time you call y() 
you might get a differen element of %.

I guess, you know all this stuff.

Ralf

aldor -laldor -grun domaintest.as
172443481
172443481
1911439442
1127848893

---domaintest.as
#include "aldor"
DomA: with {
	x: %;
	y: () -> %;
	coerce: % -> Integer;
} == add {
	Rep == Integer;
	import from Rep;
	x  : % == per random();
	y(): % == per random();
	coerce(x: %): Integer == rep x;
}
main(): () == {
   import from TextWriter, Character, Integer;
   a: DomA := x;   stdout << (a::Integer) << newline;
   b: DomA := x;   stdout << (b::Integer) << newline;
   a: DomA := y(); stdout << (a::Integer) << newline;
   b: DomA := y(); stdout << (b::Integer) << newline;
}
main();



\start
Date: Wed, 22 Feb 2006 18:04:14 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: 1: %

> if we were to consider implementation details, then descending to the
> foam level would suffice :-)
> 
> However, I was really thinking of the abstract model -- no
> implementation involved yet.

I think you are more of an expert in this business. I am just a poor 
mathematician with some programming knowledge. ;-)


> | However, this behaviour is exactly, the difference between a constant
> | and a nullary function in Aldor.

> The difference is not that between a constant and a nullary function
> -- btw, anything defined with "==" is a constant in Aldor :-)

Yes. As I said. "y" is constant "y()" is not.

> if your nullary function y evaluates to the *same* value for same
> argument each time, then  it would do just fine.

I agree, but it does not evaluate to the same thing. And Aldor allows 
this. I understand that mathematically a constant and a nullary function 
is not much of a difference. I would also conceptually agree if we speak 
about functional languages where there are no side effects. But Aldor 
allows side-effects.

 > You won't see any difference.

Except, maybe for the running time if the compiler is not smart enough 
to remove
the function call and just replace it with the value.

>  The real difference in your program is that of *binding time*.

Of course, I agree, that "x" and "y()" can be treated as constants if 
"y" where a function in the mathematical sense (returning the same value 
for the same input). In that case it is just different "binding time".

But in the example I gave in my previous mail. "y" is not a function 
that returns the same value in each invocation. And you don't think that 
is a difference?

> | Aldor computes the value for x at the time the domain is
> | instantiated. So it is constant over the lifetime of the domain
> | (unless some dirty tricks change that value). For y it is
> | different. That is a function constant. But a constant of type ()->%
> | not of type %. Now, of course, if you say "y()", you get something of
> | type %. But each time you call y() you might get a differen element of
> | %.
> | 
> | I guess, you know all this stuff.
> 
> yes, thanks.   I'm still puzzled as to why you're collapsing binding time
> distinction with constant vs. nullary function.

Maybe, I don't have enough knowledge here. If you could enlighten me, 
would be nice...

\start
Date: Wed, 22 Feb 2006 07:35:19 -0800 (PST)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Time for another crazy idea...


--- Gabriel Dos Reis wrote:

> Cliff Yapp writes:
> 
> [...]
> 
> > I think we should try to either use names that are (at least
> > moderately) common in mathematical and other research as they
> > are commonly used, or in the worst case clearly define what we are
> > and are not using the word for in the context of Axiom.  It
> > will make it FAR easier for researchers to read and use Axiom if
> > they don't have to re-adjust their understand of common terms
> > (IMHO anyway).
> 
> Indeed.  That speaks for NOT using 'category' and 'object' when, in
> fact, we are talking of things that are different from 'category' and
> 'object' as used in the math litterature.

That would be my preference.  I know there are often problems with
multiple uses of terms, but in this case I think we might want to give
the matter some consideration, at least when we start to do the large
scale Algebra translation.

\start
Date: 22 Feb 2006 19:11:12 +0100
From: Francois Maltey
To: list
Subject: Re: about Expression Integer

"Bill Page" writes :

> > > Could you please define in what sense "Otherwise we don't 
> > > get a polynomial, obviously."? To me this is not obvious -
> > > it is wrong.
> > 
> > Why should this be wrong?
> > 
> > Here's a definition for polynomial from wikipedia:
> > 
> >   In mathematics, a polynomial is an expression in which constants
> >   and variables are combined using (only) addition, subtraction,
> >   and multiplication. Thus, 7x^2+4x-5 is a polynomial; 2/x is not.

I have the same point of view than Martin, 
everything is done in DMP in order to have a polynomial ring, 
DMP isn't only a << collect >> command which factorise x and so.

> I think this definition is less general it needs to be and
> difficult to apply in the context of Axiom. 

If we change DMP assumption, it's no more ring. 

> We need to know what are "constants" and what are "variables" 

So the same variable is forbiden in the constant ring.
I find it's a bug to allow DMP ([X,Z], DMP ([X,Y], INT))

> > I recall that in the Algebra course I attended, the polynomial
> > ring was defined as a ring (of coefficients) together with a
> > variable which is to be transcendent over that ring. 
> 
> That definition is much better. In the case we are discusing
> the ring of coefficients is the domain 'EXPR INT' which
> includes expressions of the form '1/x' and so it is correct
> to say that '2/x' is not in itself a polynomial but it can
> be a coefficient in a polynomial. 

I don't think so, 
a polynomial ring has variables which are not in the initial ring.
The DMP error (for derivative) isn't in the derivative function but
in the fact that axiom accepts 1/x has variable in DMP[x].

And 1/x isn't transcendent over that rign because y=1/x is solution of
xy-1=0 in this field.

Either we say to the user he _must_ be carreful with this, 
   (only in the EXPR INTEGER field?)
Either monomial command of DMP reject 1/x coefficient if x is a variable.

In France we say we can be << jesuite >> :
The real axiom accepts coefficients as 1/x in DMP ([x], EXPR INT) 
because axiom EXPR INT isn't perfect, but it souldn't.
But I'm sure it's a mistake to change derivative.

> How would you use such a domain to solve the problem originally
> posed by Francois about expansion of trigonometric expressions
> that started this thread? 

When we expand a trigonometric expression, 
the question is a << linear one >> not a polynomial one.

We expand more often sin (4*x+5*y) than sin (x^2+x) ; 
for sin (x^2+x) we use series.

\start
Date: Wed, 22 Feb 2006 20:58:47 +0100
From: David Mentre
To: Tim Daly
Subject: Re: ASDF and ./configure

--=-=-=

Hello Tim,

I looked at the ./configure script so I can reply more specifically
now. 

Tim Daly writes:

> The issue, as i understand it, is not that the configure script
> doesn't work on the systems where it was tested. The issue is that
> the configure script is not robust. Certain problems have to be
> decided.

I understand, this is the issue faced by all ./configure scripts.

You have two options to make it more robust:

 1. use the ./configure generated by autoconf tools. There is a lot of
    knowledge in them, but most of this knowledge is not needed for
    Axiom:

    - who needs to build Axiom on outdated systems like Ultrix?

    - most of autoconf knowledge is related to C issues, while most
      Axiom issues are Lisp ones (once GCL is built, and GCL is using
      autoconf),

    - when the generated configure script fails, it is a nightmare to
      understand *what* is going wrong;

 2. continue with the current hand-written script. It seems to me the
    most manageable way to *understand* what is happening and to solve
    portability issues.


> Given a particular system you need to output a symbol (e.g linux)
> which will be used selector for the inital Makefile. 
[...]
> In addition there are some other issues that arise. The noweb tool
> seems to want to use one of 'awk', 'gawk', or 'nawk'. Given that
> noweb is vital to the early processing we need to find which of
> the three is available on the current system and customize the
> main Makefile to use it. This is done on the command line:
>
>    make -f Makefile.linux AWK=nawk

This is currently done by the current configure script, right?

> Some systems use differen tool names (e.g. gtar) and those have to
> be able to be overriden also. However, given that it is a lot of
> effort to make sure axiom works on each new system all of this
> knowledge is embedded in the Makefile.pamphlet and selected by
> the system symbol ("solaris" ==> gtar).

This approach seems perfectly right to me.

> Another issue has arisen. It appears that some of the shell
> scripts aren't portable because they use #! paths to execute them.

However, this sentence is *very* surprising! #! has its origins to the
first Unix. On which system did #! failed? Any specific keyword so I can
google it (I already tried but found nothing)?

> Perhaps the configure program can help with the initial value
> selections but it would take some careful thought. It's probably
> better and more robust to rewrite the shell scripts not to use #!

I don't think so. Even autoconf's generated ./configure is using 
"#! /bin/sh".


After reading the current ./configure script, it seems relatively well
written and portable to me. I noticed a few things however:

 - better write:
fun () 
{

   instead of:
fun () {

 - use "exit 1" on error: 0 is ok return code for shells;

 - the "!" is said to be non portable and should not be used[1];

 - the equality of strings is "==", not "=" (as far as I know);

 - the handle the several tests, one could use a "case" shell
   construct. It would probably be cleaner. ("fix" not included in
   following patch)

Here is a patch that intend to fix those issues. Anybody willing to test
it on non Debian Linux system?


--=-=-=

--- GOLD/axiom/configure	2005-06-05 05:59:28.000000000 +0200
+++ config/axiom/configure	2006-02-22 20:36:57.439491928 +0100
@@ -1,3 +1,5 @@
+#! /bin/sh
+
 # The sysname function uses uname -s to try to decode what kind of
 # system to build. Currently the return value of uname is mapped as
 #       Linux          --> linux
@@ -8,7 +10,8 @@
 #
 # The solaris platform needs patch->gpatch, awk->gawk, tar->gtar
 
-sysname () {
+sysname () 
+{
 if [ -f /etc/redhat-release ] ;
  then 
   SYSNAME=`cat /etc/redhat-release` 
@@ -21,16 +24,16 @@
  then
    SYSNAME=`uname -s`
    echo $SYSNAME 
-   if [ "$SYSNAME" = "Linux" ] ; then SYSNAME=linux
-   elif  [ "$SYSNAME" = "MINGW32_NT-5.1" ] ; then SYSNAME=windows
-   elif  [ "$SYSNAME" = "SunOS" ] ; then SYSNAME=solaris9
-   elif  [ "$SYSNAME" = "freebsd" ] ; then SYSNAME=freebsd
+   if [ "$SYSNAME" == "Linux" ] ; then SYSNAME=linux
+   elif  [ "$SYSNAME" == "MINGW32_NT-5.1" ] ; then SYSNAME=windows
+   elif  [ "$SYSNAME" == "SunOS" ] ; then SYSNAME=solaris9
+   elif  [ "$SYSNAME" == "freebsd" ] ; then SYSNAME=freebsd
    else
      echo Your system name is $SYSNAME
      echo We do not know how to build for this kind of system
      echo Send a note to list about it
      echo
-     exit 0
+     exit 1
    fi
 fi
 
@@ -39,7 +42,8 @@
 # This function checks for the gawk command. 
 # If it exists then AWKNAME is the complete pathname
 
-checkgawk() {
+checkgawk() 
+{
 AWKNAME=`which gawk 2>>trace`
 if [ -n "$AWKNAME" ] ; then
  if [ -x $AWKNAME ] ; then 
@@ -51,7 +55,8 @@
 # This function checks for the nawk command. 
 # If it exists then AWKNAME is the complete pathname
 
-checknawk() {
+checknawk() 
+{
 AWKNAME=`which nawk 2>>trace`
 if [ -n "$AWKNAME" ] ; then
  if [ -x $AWKNAME ] ; then 
@@ -63,7 +68,8 @@
 # This function checks for the awk command. 
 # If it exists then AWKNAME is the complete pathname
 
-checkawk() {
+checkawk() 
+{
 AWKNAME=`which awk 2>>trace`
 if [ -n "$AWKNAME" ] ; then
  if [ -x $AWKNAME ] ; then 
@@ -84,7 +90,7 @@
     checkawk
     if [ -z "$AWKNAME" ] ; then
       echo We need the commands gawk, nawk, or awk
-      exit 0
+      exit 1
     fi
   fi
 fi
@@ -101,7 +107,8 @@
 
 # We generate the appropriate command line that the user should use.
 
-mustSet() {
+mustSet() 
+{
 echo
 echo ===================================================
 echo You must set your AXIOM and PATH variables. Type:
@@ -110,16 +117,16 @@
 echo
 echo export AXIOM=`pwd`/mnt/$SYSNAME
 echo 'export PATH=$AXIOM/bin:$PATH'
-if [ "$SYSNAME" = "freebsd" ] ; then
+if [ "$SYSNAME" == "freebsd" ] ; then
   echo Note that freebsd usually has noweb available
   echo If you wish to use the standard version you must type
   echo touch noweb 
   echo If you wish to use a pre-installed GCL you must type
   echo make GCLVERSION=gcl-system
 fi
-if [ "$SYSNAME" = "solaris9" ] ; 
+if [ "$SYSNAME" == "solaris9" ] ; 
  then echo make AWK=gawk TAR=gtar PATCH=gpatch
-elif [ "`basename $AWKNAME`" = "gawk"  ] ; 
+elif [ "`basename $AWKNAME`" == "gawk"  ] ; 
  then echo make
  else echo make AWK=$AWKNAME
 fi
@@ -146,10 +153,10 @@
 sysname
 needAwk
 
-if [ "x$AXIOM" = "x" ] ;
+if [ "x$AXIOM" == "x" ] ;
  then mustSet
  else 
-  if [ ! "`dirname $AXIOM`" = "`pwd`/mnt" ]
+  if [ "`dirname $AXIOM`" != "`pwd`/mnt" ]
     then mustSet
     else 
      echo Configure complete. Now type

--=-=-=




Regarding the current unsatisfying approach where the user need to type
export commands, I propose following solution (not included in above
patch):

 - ./configure generates a "Makefile.config" file. This makefile
   contains the needed variable definition;

 - file "Makefile.config" is included by main Makefile with an "include"
   directive. The main Makefile in turn generates Makefile.linux and
   calls it as usual.

What do you think of it? From my readings, the "include" make directive
is portable[2].


Best wishes,
d.

Footnotes: 
[1]  http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_10.html#SEC122
<<<
 !

    You can't use !; you'll have to rewrite your code.
>>>

[2]  Autoconf manual, section 10. Portable Shell Programming
     http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/autoconf_10.html#SEC114

-- 
David MENTRE David Mentre -- http://wiki.axiom-developer.org/FrontPage

\start
Date: Wed, 22 Feb 2006 19:58:59 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Streams] Re: Clarifications

unknown wrote:

> It seems that the example:
>
>  [p for p in smallPrimes for i in 1..11]
>
> depends on multiple for clauses being interpreted in parallel
> instead of all their combinations.

Yes, that is correct. The index 'i' is present for no other
purpose then to ensure exactly 11 elements are generated. It
is not directly evident in the generated output, but the
resulting stream does have only 11 elements. We can see this
by asking Axiom to count them:
\begin{axiom}
# entries %%(5)
\end{axiom}

'%%(5)' refers to the result from calculation (5).

> What does this syntax mean:
>
>  thesePrimes:=entries complete %

'%' refers to the immediately previous result.
'complete' means to compute all the members of the stream
(only possible if the stream in finite).
'entries' means to convert the stream to a list.

So this command means to assign to the variable 'thesePrimes'
the list consisting of all the members of the stream in
the previous result.

> Does the conversion depend on the while p < 1200 used
> above instead of | p < 1200?

There is no "conversion" going on here, as such. It is just
the evaluation of streams. No, this evaluation does not require
the 'while' syntax. In this example the 'while' clause and the
| notation (which is read: such that) are equivalent. But in
more general situations however there may a difference. The
failure of the 'while' condition causes the list to terminate
but the failure of the | condition simply skips that entry.

\start
Date: Wed, 22 Feb 2006 12:13:36 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: about Expression Integer

Martin,

On February 22, 2006 8:55 AM you wrote:
> ...
> Please bear with me.

No problem. Respond as and when you get time... :)

> > Martin wrote: 
> > > If we allow (2*x+1/x)::DMP([x], EXPR INT), i.e., allowing 1/x
> > > as a coefficient, then it must be clear that the "x" in 1/x
> > > is something different than the "x" in 2*x. Otherwise we don't
> > > get a polynomial, obviously.
> >
> Bill Page wrote: 
> > I think this is wrong. In fact, it is clear from the 
> > implementation of Axiom that whether the 'x' in these two
> > cases is the same or not depends on which domain to which
> > they belong.

Perhaps I should have said this differently. Yes, I do agree that
the 'x' in '1/x' and '2*x' are different. But they are not
different in the sense in which 'x' and 'y' are different, i.e.
they are not different variables - they are the same variable
used in two different ways. In particular the 'x' in '1/x' is
a member of the coefficient domain just like '2', while the 'x'
in '2*x' is a member of the polynomial domain. Furthermore the
symbol '*' denotes an operation defined in the polynomial
domain, while the symbol '/' denotes an operation in the
coefficient domain.

> > 
> > Could you please define in what sense "Otherwise we don't 
> > get a polynomial, obviously."? To me this is not obvious -
> > it is wrong.
> 
> Why should this be wrong?
> 
> Here's a definition for polynomial from wikipedia:
> 
>   In mathematics, a polynomial is an expression in which constants
>   and variables are combined using (only) addition, subtraction,
>   and multiplication. Thus, 7x^2+4x-5 is a polynomial; 2/x is not.
>

I think this definition is less general it needs to be and
difficult to apply in the context of Axiom. We need to know
what are "constants" and what are "variables" and where
"addition", "subtraction" and "multiplication" are defined.
 
> I recall that in the Algebra course I attended, the polynomial
> ring was defined as a ring (of coefficients) together with a
> variable which is to be transcendent over that ring. 

That definition is much better. In the case we are discusing
the ring of coefficients is the domain 'EXPR INT' which
includes expressions of the form '1/x' and so it is correct
to say that '2/x' is not in itself a polynomial but it can
be a coefficient in a polynomial. And if the degree of the
term in which such a coefficient appears is 0, then by
convention we will write this polynomial in a way that looks
the same as '2/x'.

> 
> I guess you know that, so there is probably a misunderstanding
> somewhere. Just to be clear:
> 
> sin x + y*cos x + y^2* tan x 
> 
> is perfectly allright a polynomial in y.

I agree, but it is also a perfectly good polynomial in x
provided that it can appear as a member of the coefficient
domain:

(1) -> (sin x + y*cos x + y^2* tan x)$UP(x,EXPR INT)

         2
   (1)  y tan(x) + sin(x) + y cos(x)
   Type: UnivariatePolynomial(x,Expression Integer)

(2) -> degree %

   (2)  0
   Type: NonNegativeInteger

> 
> > Documentation is a good thing. But why should we retain 
> behaviour in Axiom
> > that is mathematically incorrect? What advantage does this 
> odd behaviour of
> > 'differentiate' have over a mathematically correct implementation?
> 
> I think that 'differentiate' does not exhibit odd behaviour. 
> Why do you think it's odd?
> 
> Of course, if you claim that x+1/sin(x) is a polynomial, than 
> I'm out of luck.

Indeed, I think you are out of luck. :(

(3) -> ex1:=(x+1/sin(x))$UP(x,EXPR INT)

               1
   (3)  x + ------
            sin(x)
   Type: UnivariatePolynomial(x,Expression Integer)

(4) -> degree ex1

   (4)  1
   Type: PositiveInteger

(5) -> differentiate(ex1,x)

              2
        sin(x)  - cos(x)
   (5)  ----------------
                   2
             sin(x)
   Type: UnivariatePolynomial(x,Expression Integer)

(6) -> ex2:=(x+1/sin(x))$DMP([x],EXPR INT)

               1
   (6)  x + ------
            sin(x)
   Type: DistributedMultivariatePolynomial([x],Expression Integer)

(7) -> degree ex2

   (7)  [1]
   Type: DirectProduct(1,NonNegativeInteger)

(8) -> differentiate(ex2,x)

   (8)  1
   Type: DistributedMultivariatePolynomial([x],Expression Integer)

The results for (5) and (8) should be identical... QED.

> ...
> In fact I cannot see a single reason to consider a domain
> DMP(vars, EXPR INT) at all, except for the fact that we do 
> not have a domain EXPR(vars, coefficients) yet.

How would you use such a domain to solve the problem originally
posed by Francois about expansion of trigonometric expressions
that started this thread? At the very least we would need
'DEXPR(vars, coefficients)',i.e. the "distributed" version.
But I have no objection to this suggestion. It is the other
things that we discovered about complicated nested types
along the way that concerns me now.

> 
> > > Note that b::UP([x], INT) or b::POLY INT give errors!
> > 
> > Obviouse 'b' has no representation in these domains. 
> 
> Yes it has: 1 is a UP([x], INT).
> 

No! 'b' for example in:

(9) ->   P := UP(x, EXPR INT)

   (9)  UnivariatePolynomial(x,Expression Integer)
   Type: Domain

(10) ->   a :P := x

   (10)  x
   Type: UnivariatePolynomial(x,Expression Integer)

(11) ->   b := a/x

         1
   (11)  - x
         x
   Type: UnivariatePolynomial(x,Expression Integer)

is not the same a '1$P'

\start
Date: Wed, 22 Feb 2006 06:53:16 -0600
From: MathAction (unknown)
To: MathAction
Subject: [AxiomCommunity] A axiom package, itovsn3

Thanks for professor W.Kendall, Warwick Univ,U.K. kindly allow us to
include his effort, itovsn3 (in Axiom) in our LiveTeXmacs. itovsn3
supports many functions for computing stochastic integrals, solving
stochastic differential equations and others. Also itovsn3 gives
several examples. With the such powerful tool for studying Stochastic
process, I also make a lecture file about stochastic process in
TeXmacs format ( more than 100 pages but not completed yet).  In the
future, I will add a part how to use Axiom+itovsn3 to solve
SDE. Welcome all interesting readers to use.

\start
Date: 22 Feb 2006 17:48:46 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: 1: %

Ralf Hemmecke writes:

| Dear Gaby,
| 
| On 02/22/2006 04:00 PM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > | On 02/22/2006 12:21 AM, Gabriel Dos Reis wrote:
| > | > Ralf Hemmecke writes:
| > | > | > | The problem is the "1: %" as a constant (not a nullary
| > | > function).
| > | > | > The distinction is largely syntactic, not fundamental.
| > | > | | I was once told that in Aldor the difference between
| > | > |    a: %
| > | > | and
| > | > |    b: () -> %
| > | > | is that
| > | > | b() will run a program which might side-effect other things or even
| > | > | return something different each time.
| > | > expanding on my preivous answer, have a look at the section 5.2 os
| > | > the
| > | > Aldor user guide on literal forming -- you can define your own function
| > | > to interpret a string literal as a constant.
| > | | I knew about this Literal stuff before...
| > I have no doubt about that :-)
| > |
| > http://lists.gnu.org/archive/html/axiom-developer/2006-02/msg00154.html
| > | | But as you see, if you write a domain that has a function
| > | string: Literal -> %,
| > | it is a function and that means that "1" and "1" need not give
| > | identical values.
| > yes, that is precisely why I said in an earlier message that the
| > distinction is largely syntactic.  it is not something fundamental in
| > the context of your discussion about axiom and o stuff.
| > Underneath, everything is a function in Aldor!
| 
| Well, it might depend on which level you look at it. If the generated
| C code is concerned, I have no idea about that.

if we were to consider implementation details, then descending to the
foam level would suffice :-)

However, I was really thinking of the abstract model -- no
implementation involved yet.

| But if it were really just syntactic, then the output given below is
| strange.
| 
| However, this behaviour is exactly, the difference between a constant
| and a nullary function in Aldor.

The difference is not that between a constant and a nullary function
-- btw, anything defined with "==" is a constant in Aldor :-)

if your nullary function y evaluates to the *same* value for same
argument each time, then  it would do just fine.  You won't see any
difference.   The real difference in your program is that of *binding
time*. 

| Aldor computes the value for x at the time the domain is
| instantiated. So it is constant over the lifetime of the domain
| (unless some dirty tricks change that value). For y it is
| different. That is a function constant. But a constant of type ()->%
| not of type %. Now, of course, if you say "y()", you get something of
| type %. But each time you call y() you might get a differen element of
| %.
| 
| I guess, you know all this stuff.

yes, thanks.   I'm still puzzled as to why you're collapsing binding time
distinction with constant vs. nullary function.

\start
Date: Wed, 22 Feb 2006 11:18:29 -0500
From: Bill Page
To: Cliff Yapp
Subject: RE: Time for another crazy idea...

On February 22, 2006 10:35 AM C Y wrote:
> > ...
> > > I think we should try to either use names that are (at least
> > > moderately) common in mathematical and other research as they
> > > are commonly used, or in the worst case clearly define what
> > > we are and are not using the word for in the context of Axiom.
> > > It will make it FAR easier for researchers to read and use
> > > Axiom if they don't have to re-adjust their understand of
> > > common terms (IMHO anyway).
> > 
> > Gabriel Dos Reis wrote:
> > Indeed.  That speaks for NOT using 'category' and 'object'
> > when, in fact, we are talking of things that are different
> > from 'category' and 'object' as used in the math litterature.
> 
> That would be my preference.  I know there are often problems with
> multiple uses of terms, but in this case I think we might want to
> give the matter some consideration, at least when we start to do
> the large scale Algebra translation.
> 

I think that unfortunately this idea is impractical. Give all the
existing literature about Axiom and Aldor and the fact that other
systems (such as MuPad) have already borrowed and adopted these
terms, I think it would be very difficult and even more confusing
to write about Axiom using a whole new set of terms - even if
they happen to correspond to correct current usage. Instead I
think we need to be "up front" about this problem and to provide
the reader earlier-on with a clear defintion of terms and a
comparison to the terms used in other systems.

Since Java is very widely known and rather similar to Axiom/Aldor
in at least it's object-oriented aspects, we might start with a
table something like this (first draft):

  Java        Axiom           Mathematics
 ------------------------------------------------------------
  Interface   Category        Many-sorted algebra (signature)
  Class       Domain          Category
  Instance    Member          object

But I am sure that even getting everyone agree on this kind
of translation of terms is likely to be difficult. Plus Axiom
uses several other terms such as 'object' (meaning roughly
Domain in context of Categories, or Members in the context
of Domains) and 'type' (meaning Domain in the context of
Member and Category in the context of Domain), etc. It is
hard to describe this accurately in a few words but I think
we need it to be as short as possible since we can everyone
who meets Axiom to at least read this.

\start
Date: 22 Feb 2006 16:00:44 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: 1: %

Ralf Hemmecke writes:

| On 02/22/2006 12:21 AM, Gabriel Dos Reis wrote:
| > Ralf Hemmecke writes:
| > | > | The problem is the "1: %" as a constant (not a nullary
| > function).
| > | > The distinction is largely syntactic, not fundamental.
| > | | I was once told that in Aldor the difference between
| > |    a: %
| > | and
| > |    b: () -> %
| > | is that
| > | b() will run a program which might side-effect other things or even
| > | return something different each time.
| > expanding on my preivous answer, have a look at the section 5.2 os
| > the
| > Aldor user guide on literal forming -- you can define your own function
| > to interpret a string literal as a constant.
| 
| I knew about this Literal stuff before...

I have no doubt about that :-)

| http://lists.gnu.org/archive/html/axiom-developer/2006-02/msg00154.html
| 
| But as you see, if you write a domain that has a function
| string: Literal -> %,
| it is a function and that means that "1" and "1" need not give
| identical values.

yes, that is precisely why I said in an earlier message that the
distinction is largely syntactic.  it is not something fundamental in
the context of your discussion about axiom and o stuff.
Underneath, everything is a function in Aldor!

\start
Date: 22 Feb 2006 14:54:55 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: about Expression Integer

Bill Page writes:

> Martin,
> 
> On February 22, 2006 3:54 AM you wrote:
> > 
> > I'm currently out of time. But I'm a little afraid of the 
> > direction the discussion takes currently.
> 
> I on the other hand am very happy that this discussion
> seems to accurately reflect the concept of type in Axiom.

well, I'd be happier if I could defend my point of view. Just, I can't,
currently. Still I'll try to (partially) respond to this message... Please bear
with me.

> > I believe that the intension of a constructor like DMP is to cover
> > *polynomials*.
> 
> I agree. "cover" is the operative word. This does not preclude that the type
> DMP in Axiom might be a little more general than what is called a polynomial
> in some mathematical uses (but perhaps not others).

> > If we allow (2*x+1/x)::DMP([x], EXPR INT), i.e., allowing 1/x as a
> > coefficient, then it must be clear that the "x" in 1/x is something
> > different than the "x" in 2*x. Otherwise we don't get a polynomial,
> > obviously.
> 
> I think this is wrong. In fact, it is clear from the implementation of Axiom
> that whether the 'x' in these two cases is the same or not depends on which
> domain to which they belong.
> 
> Could you please define in what sense "Otherwise we don't get a polynomial,
> obviously."? To me this is not obvious - it is wrong.

Why should this be wrong?

Here's a definition for polynomial from wikipedia:

  In mathematics, a polynomial is an expression in which constants and
  variables are combined using (only) addition, subtraction, and
  multiplication. Thus, 7x^2+4x-5 is a polynomial; 2/x is not.

I recall that in the Algebra course I attended, the polynomial ring was defined
as a ring (of coefficients) together with a variable which is to be
transcendent over that ring. 

I guess you know that, so there is probably a misunderstanding somewhere. Just
to be clear:

sin x + y*cos x + y^2* tan x 

is perfectly allright a polynomial in y.

> Documentation is a good thing. But why should we retain behaviour in Axiom
> that is mathematically incorrect? What advantage does this odd behaviour of
> 'differentiate' have over a mathematically correct implementation?

I think that 'differentiate' does not exhibit odd behaviour. Why do you think
it's odd?

Of course, if you claim that x+1/sin(x) is a polynomial, than I'm out of luck.

You said, given

> > > > P := DMP([x,y], EXPR INT) 
> > > > a :P := x 
> > > > b := a/x 
> > > > 
> > > > differentiate(b,x)                    -- 1/x
> > > 
> > > (4) -> differentiate(b,x)
> > > 
> > >         1
> > >    (4)  -
> > >         x
> > >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)

> On the other hand a 'differentiate' operator that returns 1/x in (4) above
> would violate the mathematical definition of derivative, so I think it cannot
> possibly be right.

I wouldn't say that this violates the "mathematical definition of
derivative". The derivative of a univariate polynomial is defined by sending
x^n to n*x^(n-1) and linear extension. There is no such thing as 1/x in the
polynomial world. If you want a domain that contains x and 1/x, consider using
Laurent polynomials. In fact I cannot see a single reason to consider a domain
DMP(vars, EXPR INT) at all, except for the fact that we do not have a domain
EXPR(vars, coefficients) yet.

> > Note that b::UP([x], INT) or b::POLY INT give errors!
> 
> Obviouse 'b' has no representation in these domains. 

Yes it has: 1 is a UP([x], INT).

\start
Date: Wed, 22 Feb 2006 10:47:37 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Time for another crazy idea...

On February 22, 2006 10:07 AM Gaby wrote:
> 
> Bill Page writes:
> 
> | ... From the point of view of applications of category theory
> | in computer science, I think there are several better books for
> | the beginner, e.g.
> | 
> |  Basic Category Theory for Computer Scientists
> |  by Benjamin C. Pierce
> |  http://www.amazon.com/gp/product/0262660717
> 
> I usually recommend Barr and Wells' to students.
> 

http://crm.umontreal.ca/pub/Ventes/desc/PM023.html
http://www.cwru.edu/artsci/math/wells/pub/ctcs.html
http://www.amazon.com/gp/product/0131204866

Certainly! I was a student of Michael Barr at McGill in the 1980's.
But this book is a little hard to get and I think these days it
makes a better "2nd book" on category theory for computer science,
rather than a beginner's book.

Pierce's book can take you are far as cartesian closed categories
and their equivalence to typed lambda calculus and thus relevance
to programming language semantics. Since Axiom implements 'Record'
(products), 'Union' (sums) and 'Mapping' (typed functions with
evaluation), it's characterization in these terms is quite
straight forward.

But the Barr and Wells book ends up at Topos Theory (algebraic
set theory) and I do believe that is where we want to be in a
computer algebra system like Axiom.

\start
Date: Wed, 22 Feb 2006 20:32:46 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [AxiomCommunity] itovsn3 and LiveTeXmacs links

itovsn3 (author: Wilfrid S. Kendall) --
http://www2.warwick.ac.uk/fac/sci/statistics/staff/academic/kendall/personal/ca/

LiveTeXmacs (author: chu-ching huang) --
ftp://math.cgu.edu.tw/pub/KNOPPIX
ftp://math.cgu.edu.tw/pub/KNOPPIX/StocCal216.iso

\start
Date: Thu, 23 Feb 2006 02:37:28 -0600
From: MathAction (unknown)
To: MathAction
Subject: [Streams] 

Thanks for your reply! As a follow-up, I'd like to know how AXIOM can
find out when 'complete' has computed all members of the stream if
there isn't a finite 'for' or 'while' there somewhere. I would think
that's undecidable in some weird cases.

\start
Date: Wed, 22 Feb 2006 20:48:41 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [Symbolic Ito Calculus] (new) 

itovsn3 (author: Wilfrid S. Kendall)

  http://www2.warwick.ac.uk/fac/sci/statistics/staff/academic/kendall/personal/ca

Symbolic Itô Calculus is the name for my implementation of Itô
calculus (stochastic calculus for continuous semimartingales)in
various computer algebra packages. See below for various Warwick
Statistics Department preprints describing aspects of the work. If you
want to get hold of the software then there are various possibilities
depending on what is your favourite computer algebra package.

...

AXIOM: I have produced an AXIOM implementation of symbolic Itô
calculus (see "preprint
327":http://www2.warwick.ac.uk/fac/sci/statistics/staff/academic/kendall/personal/abstracts/#327)
and "Preprint
328":http://www2.warwick.ac.uk/fac/sci/statistics/staff/academic/kendall/personal/abstracts/#328
below describes the implementation, including AXIOM listings using the
NuWeb implementation of literate programming. Alternatively you can
download the AXIOM source in the following "gzipped
tarfile":http://www2.warwick.ac.uk/fac/sci/statistics/staff/academic/kendall/personal/ca/itovsn3-axiom.tgz
. This work was funded by EPSRC grant GR/K71677: the summary of the
final report for this grant is to be found
"here":http://www2.warwick.ac.uk/fac/sci/statistics/staff/academic/kendall/personal/ca/k71677

\start
Date: Wed, 22 Feb 2006 07:13:57 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: about Expression Integer

Martin,

On February 22, 2006 3:54 AM you wrote:
> 
> I'm currently out of time. But I'm a little afraid of the 
> direction the discussion takes currently.

I on the other hand am very happy that this discussion
seems to accurately reflect the concept of type in Axiom.

> 
> I believe that the intension of a constructor like DMP is
> to cover *polynomials*.

I agree. "cover" is the operative word. This does not
preclude that the type DMP in Axiom might be a little more
general than what is called a polynomial in some mathematical
uses (but perhaps not others).

> 
> If we allow (2*x+1/x)::DMP([x], EXPR INT), i.e., allowing 1/x 
> as a coefficient, then it must be clear that the "x" in 1/x
> is something different than the "x" in 2*x. Otherwise we don't
> get a polynomial, obviously.

I think this is wrong. In fact, it is clear from the
implementation of Axiom that whether the 'x' in these two
cases is the same or not depends on which domain to which
they belong.

Could you please define in what sense "Otherwise we don't get
a polynomial, obviously."? To me this is not obvious - it is
wrong.

> 
> So, I think that
> 
> > > P := DMP([x,y], EXPR INT) 
> > > a :P := x 
> > > b := a/x 
> > > 
> > > differentiate(b,x)                    -- 1/x
> > 
> > (4) -> differentiate(b,x)
> > 
> >         1
> >    (4)  -
> >         x
> >    Type: DistributedMultivariatePolynomial([x,y],Expression Integer)
> > 
> > I think this result should be classed a bug. The 'differentiate'
> > operation apparently makes some incorrect assumptions about the
> > coefficient domain. I think the result should be the same as:
> 
> is not a bug. If you want to have axiom output 0, then I 
> imagine that you will get into trouble with writing packages,
> variable capture might well occur.

If by "variable capture" you mean the same thing as "escaped
local variables", then I would claim that this can not occur in
Axiom, by nature of it's internal design.

On the other hand a 'differentiate' operator that returns 1/x
in (4) above would violate the mathematical definition of
derivative, so I think it cannot possibly be right.

> 
> I'd rather say that b::EXPR INT giving one is troublesome. I 
> wouldn't really classify it as a bug though, given the nature
> of EXPR INT. 

No! EXPR INT is a domain in which we can ask with the two
uses of 'x' represent the same 'x' and we correctly discover
that in this context they are the same.

> Note that b::UP([x], INT) or b::POLY INT give errors!

Obviouse 'b' has no representation in these domains. This
result is correct. On the other hand one might expect that
'b::FRAC POLY INT' would work, but in this case I think it is
just a limitation of the conversion algorithm.

> 
> PLEASE don't change the behaviour of DMP and company. What 
> should be documented (and I think Ralf did, but I hadn't time)
> is that domains like POLY EXPR INT and friends can lead to
> "surprising" results. This should go into the section "types"
> of the axiom book.
> 

Documentation is a good thing. But why should we retain behaviour
in Axiom that is mathematically incorrect? What advantage does
this odd behaviour of 'differentiate' have over a mathematically
correct implementation?

\start
Date: Thu, 23 Feb 2006 11:05:03 -0500
From: Bill Page
To: Martin Rubey
Subject: RE: about Expression Integer

Martin,

On February 23, 2006 6:01 AM you wrote:
> ...
> Bill Page wrote:
> > (1) -> (sin x + y*cos x + y^2* tan x)$UP(x,EXPR INT)
> > 
> >          2
> >    (1)  y tan(x) + sin(x) + y cos(x)
> >    Type: UnivariatePolynomial(x,Expression Integer)
> > 
> > (2) -> degree %
> > 
> >    (2)  0
> >    Type: NonNegativeInteger
> 
> Yes, but the x of UP(x, EXPR INT) is a different x than the
> x in sin(x). They only happen to have the same name.

This is the core of our disagreement. I think you are wrong.
In Axiom it does not make sense to say they are "different but
have the same name". (This is possible in some other computer
algegra systems such as Maple and maybe MuPad.) In AxioM 'x'
is a symbol - at the deepest level it is still just a symbol
in Lisp. It can not have a different "name". This symbol can
be used in different ways but in the end, it is the **same**
symbol.

If you want, we could look at the Axiom source code itself to
verify that there is only one 'x' involved. You would see for
example that there is no call to Lisp to create any new
symbols. That might take some time.

But consider this example:

(1) -> P:=(x+1/x)$DMP([x],EXPR INT)

            1
   (1)  x + -
            x
   Type: DistributedMultivariatePolynomial([x],Expression Integer)

(2) -> (variables(P)::List Symbol=variables(coefficient(P,0)))::Boolean

   (2)  true
   Type: Boolean

--------

How else could you explain this result? 'variables(P)' is the
list of polynomial variables. 'variables(coefficient(P,0))' is
the list of variables occurring in the term with degree 0.

\start
Date: Thu, 23 Feb 2006 01:08:00 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#270 integrating UTS] 1/x x = 1 is a bug!

I think recently this issue of using the same 'identifier' 'x' to
stand for two different 'variables' in two different domains (either
accidentally or on purpose) has been thoroughly discussed, but not
quite. Note that I distinguish 'identifier' from 'variable'. We have
two variables, usually one internally denoted by the 'Symbol' 'x' and
another unspecified as ? (as in 'UP(x,INT)') where ? does NOT exist
but can either be printed as ? or any identifier the user prefers,
such as 'x'. As any one who does programming should know, the same
'identifier' should never be used to denote two different objects (at
least not within the same scope). By the way, this design is in some
sense ingenious, and necessary, to allow extending a polynomial ring
that already has all the symbols as variables; such extension is
useful in testing radical ideal membership of polynomial rings, and
intersections of polynomial ideals, for example.

In creating 'integrate((1/x)::ULS(FRAC POLY INT, x, 0),x)', the user
erred by combining two operations into one and thus allowing, actually
forcing, Axiom's Interpreter to firstly misidentify the first 'x'
encountered during scan as belonging to 'FRAC POLY INT' when the user
meant it to be in 'ULS(FRAC POLY INT, x, 0)' and then secondly it is
forced to coerce the result '1/x' to be a coefficient in 'ULS(FRAC
POLY INT,x,0)' by the user. Once satisfied that the result is in
'ULS(FRAC POLY INT, x, 0)', there is no need to do anything further
but to start processing the 'integrate' command.

Instead, the user should have separated the two operations:

\begin{axiom}
f:ULS(FRAC POLY INT, x,0):=1/x
integrate(f,x)
\end{axiom}

Three things should be noted here: (a) 'x' is first encountered in
'ULS(FRAC POLY INT, x,0)' which creates an 'identifier' 'x' for the
main variable ? in the 'ULS' domain. (b) In the first line, having
bound 'x' to the main variable, '1/x' is now treated as a Laurent
series (not as a coefficient living in 'FRAC POLY INT'), but it is not
apparent to the inexperienced user in the output (but it is different,
as seen below).  (c) In the second line, Axiom fails (correctly)
because the integral, which is 'log(x)', which is not given by a
Laurent series about 'x=0'. A better example is:

\begin{axiom}
g:ULS(FRAC POLY INT, x,0):=1/(x-1)
integrate(g,x)
\end{axiom}

Here Axiom actually expands '1/(x-1)' in a series in powers of
'x'. Compared this with:

\begin{axiom}
h:=(1/(x-1))::ULS(FRAC POLY INT, x,0)
integrate(h,x)
\end{axiom}

Now Axiom having been forced to output the same identifier for two
different variables, the first 'x' bound to a variable in 'FRAC POLY
INT', and the second 'x' bound to the main variable of 'ULS', should
NOT then simplify the expression '1/x x' of (3) to '1'. This is
unfortunately a consequence of the design goal to permit elements of
'UP(x,R)' to be coercible to 'POLY R' where the main variable is
coerced into the variable using the identifier 'x'. In our case,
'ULS(R,x,0)' was first truncated to 'UP(x,R)' (using
'univariatePolynoimial') by identifying the main variable of 'ULS'
with the main variable of 'UP(x,R)'. Here 'R' IS 'FRAC POLY INT', and
'UP(x, FRAC POLY INT)' is first coerced into 'FRAC UP(x, POLY INT)'
and then further to 'FRAC POLY INT' via 'UP(x, POLY INT)' to 'POLY
INT' (from 'map' from 'FRAC2(UP(x, POLY INT),POLY INT)' and the
Interpreter probably simplified 'POLY POLY INT' to 'POLY INT'). In
other words, we have '((1/x ?)::(?/x)::(x/x)=1'.  The 'bug' there!
fore probably lies in the identification of 'POLY POLY INT' with 'POLY
INT' where the outer ? (or 'x') is identified with 'x' of the inner
'POLY'.

Conclusion: (i) Any simplification of towers which makes sense in
mathematics probably would not make sense in computer algebra (due to
scope problems for one). Other examples could be 'FRAC FRAC INT' to
'FRAC INT' and 'EXPR EXPR INT' to 'EXPR INT'. (ii) Users should be
alert to the order in which an input is scanned and the consequences,
and break a long input into simpler steps. (iii) Users should not use
the same identifier for two different objects.

\start
Date: 23 Feb 2006 12:00:57 +0100
From: Martin Rubey
To: Bill Page
Subject: Re: about Expression Integer

Bill Page writes:

> > Here's a definition for polynomial from wikipedia:
> > 
> >   In mathematics, a polynomial is an expression in which constants
> >   and variables are combined using (only) addition, subtraction,
> >   and multiplication. Thus, 7x^2+4x-5 is a polynomial; 2/x is not.

> I think this definition is less general it needs to be and difficult to apply
> in the context of Axiom. We need to know what are "constants" and what are
> "variables" and where "addition", "subtraction" and "multiplication" are
> defined.
 
> > I recall that in the Algebra course I attended, the polynomial
> > ring was defined as a ring (of coefficients) together with a
> > variable which is to be transcendent over that ring. 
> 
> That definition is much better. In the case we are discusing the ring of
> coefficients is the domain 'EXPR INT' which includes expressions of the form
> '1/x' and so it is correct to say that '2/x' is not in itself a polynomial
> but it can be a coefficient in a polynomial.

Yes, but the variable of the polynomial needs to be transcendent over the
coefficient domain. So we have to have two different x here.

> > sin x + y*cos x + y^2* tan x 
> > 
> > is perfectly allright a polynomial in y.
> 
> I agree, but it is also a perfectly good polynomial in x provided that it can
> appear as a member of the coefficient domain:

NO! It is not a polynomial in x.

> (1) -> (sin x + y*cos x + y^2* tan x)$UP(x,EXPR INT)
> 
>          2
>    (1)  y tan(x) + sin(x) + y cos(x)
>    Type: UnivariatePolynomial(x,Expression Integer)
> 
> (2) -> degree %
> 
>    (2)  0
>    Type: NonNegativeInteger

Yes, but the x of UP(x, EXPR INT) is a different x than the x in sin(x). They
only happen to have the same name.

> > Of course, if you claim that x+1/sin(x) is a polynomial, than I'm out of
> > luck.
> 
> Indeed, I think you are out of luck. :(

Why? Are you really saying that x+1/sin(x) is a polynomial in x? Once more: the
polynomial variable needs to be transcendent over the coefficient domain. The
reason is simple: otherwise you lose all the interesting features of
polynomials, for example, that you can easily test for equality, given a test
for equality in the coefficient domain.

> (3) -> ex1:=(x+1/sin(x))$UP(x,EXPR INT)
> 
>                1
>    (3)  x + ------
>             sin(x)
>    Type: UnivariatePolynomial(x,Expression Integer)
> 
> (4) -> degree ex1
> 
>    (4)  1
>    Type: PositiveInteger
> 
> (5) -> differentiate(ex1,x)
> 
>               2
>         sin(x)  - cos(x)
>    (5)  ----------------
>                    2
>              sin(x)
>    Type: UnivariatePolynomial(x,Expression Integer)
> 
> (6) -> ex2:=(x+1/sin(x))$DMP([x],EXPR INT)
> 
>                1
>    (6)  x + ------
>             sin(x)
>    Type: DistributedMultivariatePolynomial([x],Expression Integer)
> 
> (7) -> degree ex2
> 
>    (7)  [1]
>    Type: DirectProduct(1,NonNegativeInteger)
> 
> (8) -> differentiate(ex2,x)
> 
>    (8)  1
>    Type: DistributedMultivariatePolynomial([x],Expression Integer)
> 
> The results for (5) and (8) should be identical... QED.

(What are you proving here?)

Yes, they should be identical, and I vote for (8). Well, in fact I vote for not
using a construction like DMP([x], EXPR INT). What I would find nice though
would be a way to say: have a polynomial in x with coefficients beeing
arbitrary expressions which do not contain the variable x. (In this case, the
result of (5) would indeed be 1.)

There are several problems with the UP domain, for example, try

(27) -> ex3:=(y+1/sin(x))$UP(y,EXPR INT); differentiate(ex3, x)

               2
         sin(x)  - cos(x)
   (27)  ----------------
                    2
              sin(x)
                             Type: UnivariatePolynomial(y,Expression Integer)


> At the very least we would need 'DEXPR(vars, coefficients)',i.e. the
> "distributed" version.  But I have no objection to this suggestion.

Great.

> It is the other things that we discovered about complicated nested types
> along the way that concerns me now.

\start
Date: Thu, 23 Feb 2006 18:38:46 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: about Expression Integer

On Wednesday, February 22, 2006 1:11 PM Francois Maltey wrote:
>
> "Bill Page" writes :
>
> > > > Could you please define in what sense "Otherwise we don't
> > > > get a polynomial, obviously."? To me this is not obvious -
> > > > it is wrong.
> > >
> > > Why should this be wrong?
> > >
> > > Here's a definition for polynomial from wikipedia:
> > >
> > >   In mathematics, a polynomial is an expression in which
> > >   constants and variables are combined using (only) addition,
> > >   subtraction, and multiplication. Thus, 7x^2+4x-5 is a
> > >   polynomial; 2/x is not.
>
> I have the same point of view than Martin, everything is done
> in DMP in order to have a polynomial ring, DMP isn't only a
> << collect >> command which factorise x and so.

I agree with you that DMP must be a polynomial ring.

In Axiom, when we define a polynomial we must say over what
ring the polynomial is defined. The first parameter of DMP
is a list of variables, the second parameter is the name of
a ring - any ring. It is usual to define, for example:

  DMP([x,y],Integer)

where 'Integer' is the underlying ring. This means that we
will allow polynomials with variables 'x' and 'y' and where
the coefficients are integers.

And 'DMP([x,y],Integer)' itself is a ring.

'Expression Integer' is also a ring. 'Expression Integer'
includes expressions such as '1/x'.

So it makes sense to write:

'DMP([x,y],Expression Integer)' where now the coefficients
come from the ring 'Expression Integer'.

'DMP([x,y],Expression Integer)' is still a ring. Axiom will
not confuse the '1/x' which can occur as a coefficient, with
the 'x' or 'y' that appears as a polynomial variable.

Everything works as it should, no?

>
> > I think this definition is less general than it needs to
> > be and difficult to apply in the context of Axiom.
>
> If we change DMP assumption, it's no more ring.

I do *not* propose to change the way DMP is implemented.
I think it is correct except for the way 'differentiate' is
defined.

>
> > We need to know what are "constants" and what are "variables"
>
> So the same variable is forbidden in the constant ring.
> I find it's a bug to allow DMP([X,Z], DMP([X,Y], INT))

It is not a bug. I hope that you agree that 'DMP([X,Y], INT)'
is a ring. That is all that is required for 'DMP([X,Z], ... )'
to be a polynomial. Axiom will keep [X,Z] that appears in
the polynomial separate from the [X,Y] that appear in the
coefficients of this polynomial.

That is why I said the definition of polynomial above is not
good for Axiom. Axiom does not implement the idea of "variable"
and a "constant" in this way.

>
> > > I recall that in the Algebra course I attended, the
> > > polynomial ring was defined as a ring (of coefficients)
> > > together with a variable which is to be transcendent over
> > > that ring.
> >
> > That definition is much better. In the case we are discussing
> > the ring of coefficients is the domain 'EXPR INT' which
> > includes expressions of the form '1/x' and so it is correct
> > to say that '2/x' is not in itself a polynomial but it can
> > be a coefficient in a polynomial.
>
> I don't think so, a polynomial ring has variables which are
> not in the initial ring.

The polynomial ring is a different domain than the initial
ring. So I agree that the 'x' that appears as the polynomial
variable is different than the 'x' that appears in the
coefficient '1/x'. I do not like to say "variable" because
Axiom does not have any concept of variable outside of the
context of some domain. To speak in the most accurate way
possible, we must say that the same *symbol* 'x' is used in
two different ways.

> The DMP error (for derivative) isn't in the derivative
> function but in the fact that axiom accepts 1/x has
> variable in DMP[x].

First you must agree that '1/x' is a member of the ring
'Expression Integer'. Yes?

In 'Expression Integer', the result of 'differentiate(1/x,x)'
is '-1/x^2'. Of course.

If DMP is defined over the ring 'Expression Integer' then
'1/x' can be a coefficient of the polynomial. Yes?

Comparing DMP (DistributedMultivariatePolynomial) to UP
(Univariate Polynomial), we see in the source code for UP it
states that if the ring over which a polynomial is defined is
itself a polynomial ring, then 'differentiate' in DMP is defined
as the 'DifferentialExtension' of 'differentiate' in the
underlying ring. This works correctly in the case of the
domain 'UnivariatePolynomial' but fails in the case of DMP
defined over only one variable even though these two domains
should be functionally equivalent. In the latter case DMP
treats '1/x' as if it was a constant.

>
> And 1/x isn't transcendent over that ring because y=1/x is
> solution of xy-1=0 in this field.

No, that is not true because

  1
  - x
  x

is not 1 in DMP([x,y],EXPR INT) if '1/x' is the coefficient
and the 'x' on the right is the polynomial variable!

Perhaps that is what seems strange to you. The problem is that
you are not taking account of the *domain* in which these
expressions are defined.

>
> Either we say to the user he _must_ be careful with this,
>    (only in the EXPR INTEGER field?)
> Either monomial command of DMP reject 1/x coefficient if x is
> a variable.
>

I think we must say to the user that he _must_ be careful because
Axiom strictly implements the concept of 'domain' (which is just
another way of saying that Axiom is strongly typed) but often in
mathematics this notion is used only informally, if at all.

The concept of domain allows us to be more precise when we
encounter expressions such as:

  1
  - x
  x

Whether this expression is identical to 1 or not depends on the
domain. This distinction is very similar to whether we treat
'x * y * x' as equivalent to 'x^2*y'. This depends on whether
or not in this domain the operation '*' is commutative.

> In France we say we can be << jesuite >> :
> The real axiom accepts coefficients as 1/x in DMP ([x], EXPR INT)
> because axiom EXPR INT isn't perfect, but it shouldn't.
> But I'm sure it's a mistake to change derivative.
>

I do not propose to change the derivative. I expect that DMP
should treat the derivative of the polynomial as an extension
of the derivative of the underlying ring in the same way that
UP does this.

> > How would you use such a domain to solve the problem originally
> > posed by Francois about expansion of trigonometric expressions
> > that started this thread?
>
> When we expand a trigonometric expression,
> the question is a << linear one >> not a polynomial one.
>
> We expand more often sin (4*x+5*y) than sin (x^2+x) ;
> for sin (x^2+x) we use series.
>

Sure, but Axiom already defines the trigonometric expansion of
'sin(x^2+x)' in the same way as other systems such as Maple and
Mupad:

(1) -> expand sin(x^2+x)

                   2         2
   (1)  cos(x)sin(x ) + cos(x )sin(x)
   Type: Expression Integer

Your question was about the proper treatment of expressions
involving terms like '1/x'. My point is that the Axiom domain
'DMP([x,y],EXPR INT)' treats '1/x' in the way that you need
for this expansion.

Regards,
Bill Page.



\start
Date: Wed, 22 Feb 2006 09:31:10 -0600
From: MathAction (unknown)
To: MathAction
Subject: [Streams] Clarifications

It seems that the example [p for p in smallPrimes for i in 1..11] depends on multiple for clauses being interpreted in parallel instead of all their combinations.

What does this syntax mean: thesePrimes:=entries complete %

Does the conversion depend on the while p < 1200 used above instead of | p < 1200?

\start
Date: Fri, 24 Feb 2006 08:06:54 -0500
From: William Sit
To: Martin Rubey
Subject: Re: about Expression Integer

Bill Page writes:

> If we allow (2*x+1/x)::DMP([x], EXPR INT), i.e., allowing 1/x as a
> coefficient, then it must be clear that the "x" in 1/x is something
> different than the "x" in 2*x. Otherwise we don't get a polynomial,
> obviously.
> 
> Martin,
> On February 22, 2006 3:54 AM you wrote:
> > I think this is wrong. In fact, it is clear from the implementation of Axiom
> > that whether the 'x' in these two cases is the same or not depends on which
> > domain to which they belong.

Any scientific literate person, when (s)he wrote down:

   2*x + 1/x

would mean that there is only ONE x, the x means the same thing throughout the
expression. So

(1) -> (2*x+1/x)::DMP([x], EXPR INT)

          2
        2x  + 1
   (1)  -------
           x
              Type: DistributedMultivariatePolynomial([x],Expression Integer)
(2) -> degree(%)

   (6)  [0]

is perfectly correctly interpreted by Axiom. The entire expression is a
coefficient, in EXPR INT. If you )set mess bot on, you'll see that Axiom
actually computes all this in FRAC POLY INT! 

However, I think Axiom is wrong in allowing that, since x, being an
indeterminate over EXPR INT, should not be in EXPR INT. The coercion should
simply fail, or end up in FRAC DMP([x], EXPR INT).

Note that even if the following is used, Axiom continues to "retract" the x from
1/x to EXPR INT. This is simply wrong.

x:DMP([x], EXPR INT):=x
2*x + 1/x
degree(%)
          [1]

On the other hand, the following is correct, and should be the case no matter
what the coefficient domain is.

y:DMP([y], INT):=y
2*y+1/y

           2
         2y  + 1
         -------
            y
                Type: Fraction DistributedMultivariatePolynomial([y],Integer)

The two cases should not be handled differently.

If a user wants to push the result down to the coefficient domain, it should be
done with a substitution map, explicitly, and the user should not use x in EXPR
INT.

\start
Date: Fri, 24 Feb 2006 08:12:16 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: about Expression Integer

Ralf,

On Friday, February 24, 2006 5:12 AM you wrote:
> ...
> Let us take again the view that a polynomial ring "R[x]" (it's
> in quotes since I haven't defined that notation yet) is the
> ring
>
>    P = \bigoplus_{e \in N} R
>
> where N are the non-negative integers.
> Elements in P (the polynomials) are just functions with finite
> support from N to R. So the are nothing else than (infinite)
> sequences of numbers from R where only a finite non-zeros appear.
>

Ignoring for now the details of multivariate polynomials, in
Axiom we would write:

  P:=POLY R

where R is some Ring (such as INT).

> Now, let x \in P be such that x(1)=1 and x(e)=0 for e \in
> N\setminus\{1\}.
>
> If you like, you can consider this x to be the "indeterminate"
> or "variable" of P.
>

No, this is not quite complete. There is a function 'coerce'
such that 'coerce(x::Symbol)$P' \in P. Axiom displays both
this polynomial and the symbol in the same way except the
Type is different.

> It is also clear that by construction this x is different
> from anything that lives in R.

Yes, I agree with this. Except you say "numbers from R" which
could be miss-leading if R itself is a polynomial ring or a more
general ring (such as Axiom's EXPR INT).

> ...
> **What is differentiation in P?**
>
> (That is a bit informal here.)
> Given that elements in P have finite support, we can represent
> them as finite tuples.
> Let a := (a_0, a_1, ..., a_n) \in P, then the (formal)
> derivative of a is
>
>    a' = (a_1, 2 a_2, 3 a_3, ..., n a_n)
>
> (Note that a_0 is missing.)
>
> If you write a as a formal sum, using the x introduced above,
> you get.
>
> a = \sum_{e=0}^n a_e x^e
> a' = \sum_{e=0}^{n-1} a_{e+1} x^e
>
> just as expected.

The defintion of differentiation that concerns me is specified
with respect to some symbol, e.g.

  differentiate:(POLY R, Symbol) -> POLY R

If R is a Ring (such as another polynomial ring) which also
allows for example 'coerce(x::Symbol)$R' (in Axiom we would
write 'R has PDRING Symbol') then it makes good sense, I think
to define this differentiaton as an extension of the
differentiation in R (DifferentialExtension). This is what
is done in some Axiom polynomial domains and not others.

> ...
> I think that the current implementation of polynomials in
> Axiom more closely follow the formal approach. If somebody
> wants polynomials to behave differently, then there should
> be a clear documentation and an **additional** domain that
> support these ideas. But, please don't modify the existing
> polynomials in Axiom.
>

I agree. But we not talking about changing the way polynomials
behave, we are trying to define how polynomials behave now
in Axiom. My claim is that they do not (at least not quite)
behave that way that some people here have described. So I
am trying to change their description. :)

> >> I guess you know that, so there is probably a
> >> misunderstanding somewhere. Just to be clear:
> >>
> >> sin x + y*cos x + y^2* tan x
> >>
> >> is perfectly allright as a polynomial in y.
> >
> > I agree, but it is also a perfectly good polynomial in x
> > provided that it can appear as a member of the coefficient
> > domain:
>
> Bill, if this is your terminology, I strongly disagree with
> you. If I say something is "polynomial in x" then I mean if
> the expression is written as an expression tree then in the
> path from every x to the root I should at most see "^", "*",
> "+" (and "-").

You are right. My terminology was poor. But Axiom does not
have any domain consisting of an expression tree such as
you describe. This would be a much more restricted that the
current polynomial domains in Axiom.

What I should have written was perhaps:

"it is also a perfectly good polynomial over a ring that
allows such such expressions"

My point is that this is well-defined even if the same
symbol 'x' appears in both the underlying ring (i.e. in a
coefficient, and as the polynomial variable.

>
> > (1) -> (sin x + y*cos x + y^2* tan x)$UP(x,EXPR INT)
> >
> >          2
> >    (1)  y tan(x) + sin(x) + y cos(x)
> >    Type: UnivariatePolynomial(x,Expression Integer)
> >
> > (2) -> degree %
> >
> >    (2)  0
> >    Type: NonNegativeInteger
>
> Yes, Axiom is correct _and_ confusing!

The confusion is relative to the presumptions that one has
about how Axiom works... ;)

> If a user want to construct something like UP(x,EXPR INT),
> then he should know what he is doing. Unfortunately, beginners
> probably don't know what they do when they type in
> UP(x,EXPR INT). And they will be surprise by the strange
> results.

Perhaps, but I do not see any reason for beginners to use
such complicated domains.

> And I very much think that they will turn their back to
> Axiom, because it is so confusing. (Which would be a pity.)

But that *is* how Axiom was designed. You are suggesting
that we should change or at least suppress this part of
the design. I instead am trying to find some way to describe
the what Axiom does now in a way that is comprehesible to
as many Axiom users as possible.

I object in principle to the idea of "dumbing down" the
fundamental design of Axiom so that it only behaves in the
way na=EFve users expect. On the other hand, I would be
happy to see a new user interface for new Axiom users that
would focus on implementing the "principle of least surprize".

> ...
> Hey, if coerce: SOMETHING -> UP(x, INT) is a total function,
> then what does that mean?
> ...
> Does someone believe that "coerce" always has to be an
> inclusion function?
>
> > ...
> >          1
> >    (11)  - x
> >          x
> >    Type: UnivariatePolynomial(x,Expression Integer)
> >
> > is not the same a '1$P'
>
> What does that matter? If we have two domains A and B, two
> elements a \in A, b \in B, a function coerce: A->B, and
> coerce(a) = b. The whole relation between a and b is clear.
> But where is it written, that coerce in Axiom has to be
> a homomorphism? (BTW, a homomorphism of which type?
> Homomorphism of rings, of groups, of sets?)
>

'coerce' is a conversion that is intended to be automatically
applied by the interpreter presumably without the risk of
encuring any mathematical errors. So I think that at the
very least a coercion must be a morphism from A to B
that preserves the structure of A (i.e. a functor). B can
have however additional structure that is not in A. Perhaps
this is also true of other conversions (invoked by ::) when
we consider the algebraic properties of the possible result
"failed".

For example we can coerce INT -> FLOAT but we can only
convert FLOAT -> INT.

(1) -> X:INT:=1

   (1)  1
   Type: Integer

(2) -> Y:=X+1.1

   (2)  2.1          <---- this is a coercion of INT to Float
   Type: Float

(3) -> Y + 1         <---- Float is not coerced to INT

   (3)  3.1
   Type: Float

(4) -> Y::INT

   Cannot convert from type Float to Integer for value
   2.1

(4) -> Z:Float:=1

   (4)  1.0
   Type: Float

(5) -> Z::INT        <---- this is a conversion of Float to INT

   (5)  1
   Type: Integer

Regards,
Bill Page.



\start
Date: Fri, 24 Feb 2006 11:12:18 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer
Cc: list

> Perhaps I should have said this differently. Yes, I do agree that
> the 'x' in '1/x' and '2*x' are different. But they are not
> different in the sense in which 'x' and 'y' are different, i.e.
> they are not different variables - they are the same variable
> used in two different ways.

What is a variable anyway? Roughly speaking, it is something that has 
just a name. Some people like variables to behave transcendentally.

Let us take again the view that a polynomial ring "R[x]" (it's in quotes 
since I haven't defined that notation yet) is the ring

   P = \bigoplus_{e \in N} R

where N are the non-negative integers.
Elements in P (the polynomials) are just functions with finite support 
from N to R. So the are nothing else than (infinite) sequences of 
numbers from R where only a finite non-zeros appear.

Now, let x \in P be such that x(1)=1 and x(e)=0 for e \in N\setminus\{1\}.

If you like, you can consider this x to be the "indeterminate" or 
"variable" of P.

It is also clear that by construction this x is different from anything 
that lives in R.

Further, if you take a ring R and a monoid M then there is the monoid 
ring  RM which consists of all (finite) R-linear combinations of 
elements of M. (Well, R and M have to subsets of some common (bigger) 
ring S such that this construction makes sense.)
Note that it is nowhere said that M must contain an element that is not 
in R. But, of course, with the above construction RR = R.

If [x] with the x from above is the free (abelian) monoid generated by 
x, then R[x] is a polynomial ring.


**What is differentiation in P?**

(That is a bit informal here.)
Given that elements in P have finite support, we can represent them as 
finite tuples. Let a := (a_0, a_1, ..., a_n) \in P, then the (formal) 
derivative of a is

   a' = (a_1, 2 a_2, 3 a_3, ..., n a_n)

(Note that a_0 is missing.)

If you write a as a formal sum, using the x introduced above, you get.

a = \sum_{e=0}^n a_e x^e

a' = \sum_{e=0}^{n-1} a_{e+1} x^e

just as expected.


I very much have the impression that Bill likes to treat polynomials as 
functions in contrast to formal objects.

For example, let F be the Galois field with two elements. As polynomials
p(x) = x + 1 and q(x) = x^2 + 1 are clearly different since they have 
different support. But as polynomial functions from F to F, they are equal.

p(0) = 1 = q(0), p(1) = 0 = q(1)



If we were to treat polynomials in R[x_1,...,x_n] as functions from R^n 
to R, then I think it would be reasonable to differentiate also in the 
coefficient domain (but first define exactly what differentiation is, 
before such a domain is implemented).

I think that the current implementation of polynomials in Axiom more 
closely follow the formal approach. If somebody wants polynomials to 
behave differently, then there should be a clear documentation and an 
**additional** domain that support these ideas. But, please don't modify 
the existing polynomials in Axiom.

>> I guess you know that, so there is probably a misunderstanding
>> somewhere. Just to be clear:
>>
>> sin x + y*cos x + y^2* tan x 
>>
>> is perfectly allright a polynomial in y.
> 
> I agree, but it is also a perfectly good polynomial in x
> provided that it can appear as a member of the coefficient
> domain:

Bill, if this is your terminology, I strongly disagree with you.
If I say something is "polynomial in x" then I mean if the expression is 
written as an expression tree then in the path from every x to the root 
I should at most see "^", "*", "+" (and "-").

> (1) -> (sin x + y*cos x + y^2* tan x)$UP(x,EXPR INT)
> 
>          2
>    (1)  y tan(x) + sin(x) + y cos(x)
>    Type: UnivariatePolynomial(x,Expression Integer)
> 
> (2) -> degree %
> 
>    (2)  0
>    Type: NonNegativeInteger

Yes, Axiom is correct _and_ confusing! If a user want to construct 
something like UP(x,EXPR INT), then he should know what he is doing. 
Unfortunately, beginners probably don't know what they do when they type 
in UP(x,EXPR INT). And they will be surprise by the strange results. And 
I very much think that they will turn their back to Axiom, because it is 
so confusing. (Which would be a pity.)

>> Of course, if you claim that x+1/sin(x) is a polynomial, than 
>> I'm out of luck.
> 
> Indeed, I think you are out of luck. :(
> 
> (3) -> ex1:=(x+1/sin(x))$UP(x,EXPR INT)
> 
>                1
>    (3)  x + ------
>             sin(x)
>    Type: UnivariatePolynomial(x,Expression Integer)

Just for fun... who else on the list votes for x+1/sin(x) to be a 
"polynomial in x"? (Don't consider (3) when you vote.)
For me it's not a "polynomial in x". ;-)

>>>> Note that b::UP([x], INT) or b::POLY INT give errors!

Hey, if coerce: SOMETHING -> UP(x, INT) is a total function, then what 
does that mean?

 >>> Obviouse 'b' has no representation in these domains.

Does someone believe that "coerce" always has to be an inclusion function?

>> Yes it has: 1 is a UP([x], INT).

> No! 'b' for example in:
> 
> (9) ->   P := UP(x, EXPR INT)
> 
>    (9)  UnivariatePolynomial(x,Expression Integer)
>    Type: Domain
> 
> (10) ->   a :P := x
> 
>    (10)  x
>    Type: UnivariatePolynomial(x,Expression Integer)
> 
> (11) ->   b := a/x
> 
>          1
>    (11)  - x
>          x
>    Type: UnivariatePolynomial(x,Expression Integer)
> 
> is not the same a '1$P'

What does that matter? If we have two domains A and B, two elements
a \in A, b \in B, a function coerce: A->B, and coerce(a) = b.
The whole relation between a and b is clear.
But where is it written, that coerce in Axiom has to be a homomorphism? 
(BTW, a homomorphism of which type? Homomorphism of rings, of groups, of 
sets?)

\start
Date: 24 Feb 2006 10:50:29 +0100
From: Gabriel Dos Reis
To: David Mentre
Subject: re: ASDF and ./configure

David Mentre writes:

| Hello Gaby,
| 
| 24 Feb 2006 07:54:40 +0100, Gabriel Dos Reis:
| > The value of using Autoconf for Axiom is not in building it on or for
| > Ultrix, but in reusing packaged knowledge about various regular systems,
| > taken care of by system packagers.  Axiom really should be developing
| > its own idea of config.guess or system triplet.
| 
| Ok. However, I had the impression that Autoconf triplets are not what
| is needed for Axiom (e.g. is t possible to recognize a Fedora Core 3?

I don't understand why computing the triplet is not needed for Axiom.
The triplet is needed each time it is necessary to install and run
binaries that are not platform-independent.  Think about people
running in multi-arch environments for example (which is not
uncommon).  The binaries and other triplet dependent components will
be installed in places with standard names derived from the triplet.
To a very large extent, it is less important to recognize Fedora Core 3
(yes, that is what the current ./configure script does, but that is
wrong).  It is far more important to recognize *available*
functionalities, whether they come from Fedora Core 3 or SuSE Linux 9.3
Professional.  
If at some point in the future, we wanted Axiom easily distributed and
packaged with standard linux distros, it is in our interest to make
the integration seamless.

| Could we integrate different Lisps as part of the system triplet?).

The triplet identifies the cpu/machine/os.  That is a standard
classification, the least thing we want is to hijack it.  If we want
to test for specific flavors of lisp, we should use the Autoconf macro 
AC_CHECK_PROG, and if needed augmented with specific tests.

| But you obviously think that using some m4 macros this is not an
| issue.

essentially, we can write Autoconf macros to generate Lisp programs,
and run them.

| > ahem, in which shell?
| 
| Bash. But you're perfectly right that I did not read the manual with
| enough attention:
| man bash
| [...]
|        string1 == string2
|               True if the strings are equal.  = may be used in place of == for
|               strict POSIX compliance.
| 
| Bourne sh is using '=' as string equality.
| 
| Gaby: 1 - David: 0 (well, rather -infinity on this one ;-)

I notice the emoticon, but please let's nto get into that.  My main
interest in this is to have a proper build system, not to count point
or argue. 

| > Autoconf has been widely test in more wild
| > environment than anything variation you'll come up here.  I would
| > suggest that we avoid NIH and reuse the wisdom of the Autoconf guys
| > who have faced and experienced wild shell variation issues.
| 
| Ok, I'll look at Autoconf. If I should criticize it, at least should I
| do it on sound grounds. :-) I'll try to make a first prototype, but as
| I need to learn Autoconf first, don't hold your breath.

I'm was just relieved of one big "task", the other one is to get C++
standard papers written by tonight or tomorrow morning at the latest,
then make a pre-release for GCC-3.4.6; and after than I should be in
position to send a preiminary simple version of toplevel configure.ac
that we can start with.  Sorry it takes to long, but my TODO list
seems bottomless and evergrowing priority "car"s.  Babies and families
usually change priorities (as you all now)...

\start
Date: Fri, 24 Feb 2006 12:54:17 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: ASDF and ./configure
Cc: list, David Mentre

>   Autoconf is a set of *extensible* macros.  Not just because it does
> not contain macro to test a particular "new" feature means it should
> be thrown away altogether with other useful functionalities.  SELinux is
> not just a Fedora Core thingy, it applies as well to SuSE Linux and
> any other linux distribution that comply to SELinux.  I hope to take
> on the configure issue as soon as my immediate horizon is cleared, so
> that we can conduct the discussion in less abstract terms.

Yes, I know that it can be extended. Unfortunately my use of M4 macros
is even more limited (sendmail hacking) than my shell scripting skills
which, as you can judge from the current configure script, are sorely
lacking.

I studied the GNU tools book for autoconf/automake and then tried to
use it but found it did not address anything useful. Your experience
may be otherwise.

I thought of trying to use the M4 macros for determining system
information but eventually gave up. There are many other areas of
Axiom where I can do useful work. Shell scripting isn't one of them.

\start
Date: Fri, 24 Feb 2006 14:43:43 -0500
From: Bill Page
To: "Mike Thomas" <mjt@mijt.net>
Subject: RE: [Gcl-devel] Windows test installers CVS HEAD and 2.6.8pre

Mike,

Thanks for the link!

Have you successfully built Axiom with GCL 2.7.0 on Windows?

Regards,
Bill Page.

On Thursday, February 23, 2006 12:27 AM you wrote:
>
> I've put Windows test installers for GCL CVS HEAD (aka 2.7.0) and GCL
> 2.6.8pre here:
>
>   http://www.mijt.net/freesoftware.html
>



\start
Date: Fri, 24 Feb 2006 10:04:38 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: ASDF and ./configure
Cc: list, David Mentre

> To a very large extent, it is less important to recognize Fedora Core 3
> (yes, that is what the current ./configure script does, but that is
> wrong).  It is far more important to recognize *available*

Actually, the Axiom build scripts work on the platforms where it has
already been successfully ported with one major exception. The issue
that arises is SELinux which breaks the GCL builds.

So we need the configure script to recognize the SELinux configuration
on FC3, FC4, and FC5 and then output appropriate "instructions" to 
adapt to the situation.

I have not seen anything in autoconf that checks these conditions.

\start
Date: 24 Feb 2006 16:41:34 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: ASDF and ./configure
Cc: David Mentre

Tim Daly writes:

| > To a very large extent, it is less important to recognize Fedora Core 3
| > (yes, that is what the current ./configure script does, but that is
| > wrong).  It is far more important to recognize *available*
| 
| Actually, the Axiom build scripts work on the platforms where it has
| already been successfully ported with one major exception. The issue
| that arises is SELinux which breaks the GCL builds.
| 
| So we need the configure script to recognize the SELinux configuration
| on FC3, FC4, and FC5 and then output appropriate "instructions" to 
| adapt to the situation.
| 
| I have not seen anything in autoconf that checks these conditions.

Hello Tim,

  Autoconf is a set of *extensible* macros.  Not just because it does
not contain macro to test a particular "new" feature means it should
be thrown away altogether with other useful functionalities.  SELinux is
not just a Fedora Core thingy, it applies as well to SuSE Linux and
any other linux distribution that comply to SELinux.  I hope to take
on the configure issue as soon as my immediate horizon is cleared, so
that we can conduct the discussion in less abstract terms.

\start
Date: Fri, 24 Feb 2006 14:39:45 -0500
From: Bill Page
To: William Sit
Subject: RE: about Expression Integer

William

On Friday, February 24, 2006 8:07 AM you wrote:
>
> Any scientific literate person, when (s)he wrote down:
>
>    2*x + 1/x
>
> would mean that there is only ONE x, the x means the same
> thing throughout the expression.

Yes.

> So
>
> (1) -> (2*x+1/x)::DMP([x], EXPR INT)
>
>           2
>         2x  + 1
>    (1)  -------
>            x
>               Type:
> DistributedMultivariatePolynomial([x],Expression Integer)
> (2) -> degree(%)
>
>    (6)  [0]
>
> is perfectly correctly interpreted by Axiom. The entire
> expression is a coefficient, in EXPR INT.

It is a correct interpretation, but it is not the only
possible interpretation. The reason it is interpreted as
entirely with 'EXPR INT' is because you used a conversion
'::' instead of a package call $. Axiom processes what is
inside the parenthesis first. Since there is no package
specification there, the interpreter assumes we are talking
about 'EXPR INT'. Then it applies the coercion from 'EXPR INT'
to 'DMP([x], EXPR INT)' which simply embeds the expression
as a term of degree 0.

Try this instead:

(1) -> (2*x+1/x)$DMP([x], EXPR INT)

             1
   (1)  2x + -
             x
   Type: DistributedMultivariatePolynomial([x],Expression Integer)

(2) -> monomials(%% 1)

            1
   (2)  [2x,-]
            x
   Type: List DistributedMultivariatePolynomial([x],Expression Integer)

In this case we told Axiom to use only operations from the
domain 'DMP([x], EXPR INT)'. It sees '2*x' and selects the
'*' with signature '?*? : (Integer,%) -> %'. The result is
a term of degree 1. Then it looks at '1/x' and selects
'?/? : (%,Expression Integer) -> %'. The result is a term
of degree 0.

This also is correctly interpreted by Axiom. But these two
expressions are not equivalent in this domain.

>
> However, I think Axiom is wrong in allowing that, since x,
> being an indeterminate over EXPR INT, should not be in
> EXPR INT.

I suppose what you are saying is that the ring over which
DMP is defined should not be 'EXPR INT' but rather
'SubDomain(EXPR INT, not member?(x::Symbol,variables(#1))'.
This is a possible definition but it seems unnecessarily
complicated. Further it would explicitly prevent the kind
of coercion that Axiom was apparently carefully designed
to do (see below).

There is no danger that Axiom will confuse the two uses of
'x' and to the user this result looks perfectly reasonable -
it looks like just a different way of formatting the
expression - but of course as "advanced users" we know the
difference is more subtle than that.

>The coercion should simply fail, or end up in
> FRAC DMP([x], EXPR INT).

I do not see how it could possibly end of in
'FRAC DMP([x], EXPR INT)' in either version of (1) above.

>
> Note that even if the following is used, Axiom continues to
> "retract" the x from 1/x to EXPR INT. This is simply wrong.
>
> x:DMP([x], EXPR INT):=x
> 2*x + 1/x
> degree(%)
>           [1]
>

It is not wrong. I agree that it might be unexpected if
one does not keep in mind the domains from which Axiom will
select functions. One might (incorrectly) thought that the
1/x must be evaluated in 'FRAC DMP([x],EXPR INT)' but once
again Axiom first considers the '/' function defined in
domain that it already knows: 'DMP([x],EXPR INT)' before it
attempts anything more complex. It discovers that it can
evaluate 1 in 'DMP([x],EXPR INT)' and that since 'x' is a
variable of type 'DMP([x],EXPR INT)', it knows that it can
always coerce such polynomials into 'EXPR INT'. This allows
it to apply the operator '/' from 'DMP([x],EXPR INT)'.

> On the other hand, the following is correct, and should
> be the case no matter what the coefficient domain is.
>
> y:DMP([y], INT):=y
> 2*y+1/y
>
>            2
>          2y  + 1
>          -------
>             y
>                 Type: Fraction
> DistributedMultivariatePolynomial([y],Integer)
>
> The two cases should not be handled differently.

I agree that this result is correct but I disagree that
these two cases can be handled the same way (i.e. by
selecting the '/' operation in 'DMP([y], INT)'. This is
not possible because Axiom cannot coerce polynomials of
type 'DMP([y], INT)' into 'INT'.

>
> If a user wants to push the result down to the coefficient
> domain, it should be done with a substitution map,
> explicitly, and the user should not use x in EXPR INT.
>

This sort of coercion is only possible when the coefficient
domain has 'PDRING Symbol' or at least 'PDRING OVAR vl'
where 'vl' is polynomial variable list. Apparently Axiom
attempts to use it during the function selection process.

\start
Date: Fri, 24 Feb 2006 00:58:19 -0500
From: Bill Page
To: William Sit
Subject: Re: 1/x x = 1 is a bug!

William,

This thread seems to go on forever ... but I feel compelled
to continue it because: 1) I think understanding how this
works is critical to understanding and using Axiom, 2) I don't
think we have a simple explanation yet of something that really
should be simple in principle, if not in it's application in
certain cases.

As a long term user of Axiom, I really appreciate you input
on this subject. But I think I must take exception to your
conclusion as stated in the subject line. :)

On Thu, 23 Feb 2006 01:07:56 -0600 at

http://wiki.axiom-developer.org/270IntegratingUTS#bottom

You wrote:

> Now Axiom having been forced to output the same identifier
> for two different variables, the first x bound to a variable
> in FRAC POLY INT, and the second x bound to the main variable
> of ULS, should NOT then simplify the expression 1/x x of (3)
> to 1.

First, I would prefer that we try not to introduce new words
like "identifier" since Axiom already calls these by the name
Symbol. Second, I worry that you are using the word "bound"
in a manner that does not really apply to Axiom. And third,
I think the use of the word "variable" in Axiom has to be
applied with some care.

When you say "x bound to a variable in FRAC POLY INT" I
think you mean only that the symbol 'x' is used as a
polynomial variable in this domain. Exactly what a
"polynomial variable" is, is defined by the specific
implementation of 'FRAC POLY INT', but we know for sure
that it will appear in the List of Symbols that is returned
by the function 'variables' when applied to any member of
this domain. And these symbols also play a role in many
other functions exported by this domain.

If I write things below that are completely obvious to you,
please bear with me and consider it just a short review. Of
course also correct me if I get it wrong. I am assuming that
there are other readers who need might this sort of review.

As you know, Symbols themselves form a domain in Axiom:

  )sh Symbol

I think there is a lot of unnecessary confusion between
symbols and variables.

By definition Symbols are constants and can not be assigned
values. Operations like

  = : (Symbol,Symbol) -> Boolean

compare one symbol to another. There are other operations that
construct new symbols possibly with sub/super-scripts etc. It
might be surprising how sophisticated Axiom's Symbol domain is
and how much of it is coded in SPAD:

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

But of course ultimately all Symbols are represented and
manipulated by Lisp, e.g.:

    coerce(s:String):%     == VALUES(INTERN(s)$Lisp)$Lisp
    x = y                  == EQUAL(x,y)$Lisp

Variables also form a domain in Axiom:

  )sh Variable

Variables are constructed from Symbols, but not all symbols
are necessarily used for this purpose. Members of the Variable
domain in turn can be assigned values and have associated
types.

It may seem strange but Variables are **not** used to form
polynomials in Axiom.

----------

Let's consider the following somewhat simplified example
where Axiom will coerce '1/x x' to 1:

(1) -> (1/x)$UP(x,FRAC POLY INT)*x

        1
   (1)  - x
        x
   Type: UnivariatePolynomial(x,Fraction Polynomial Integer)

Here '1/x' is a coefficient and polynomial variable 'x' is
written to the right of the coefficient. Both uses of 'x'
represent the same Symbol and neither of these are from the
domain Variable.

There is no operation within the domain 'UP(x,FRAC POLY INT)'
which would allow us to conclude that '1/x x' is identical
to 1 even though these are both members of this domain. We
know intuitively however that this expression should be 1
in some other domain, but showing this formally apparently
involves some rather deep knowledge about "fractional ideals"
that is beyond me.

(2) -> )set message bottomup on
(2) -> )set message autoload on
(2) -> %::FRAC UP(x,POLY INT)

 Function Selection for map by coercion facility (map)
      Arguments: ((POLY INT -> UP(x,POLY INT)),FRAC POLY INT)
      Target type: FRAC UP(x,POLY INT)
   -> no appropriate map found in Fraction Polynomial Integer
   -> no appropriate map found in
        Fraction UnivariatePolynomial(x,Polynomial Integer)
   -> no appropriate map found in
        UnivariatePolynomial(x,Polynomial Integer)
   -> no appropriate map found in Polynomial Integer
   -> no appropriate map found in
        UnivariatePolynomial(x,Polynomial Integer)

 Modemaps from Associated Packages
   [1] ((D7 -> D11),FractionalIdeal(D7,D8,D9,D10)) ->
         FractionalIdeal(D11,D1,D2,D3)
            from FractionalIdealFunctions2(D7,D8,D9,D10,D11,D1,D2,D3)
            if D7 has EUCDOM and D8 has QFCAT D7 and D9 has UPOLYC D8
            and D10 has Join(FramedAlgebra(D8,D9),RetractableTo D8) and
            D11 has EUCDOM and D1 has QFCAT D11 and D2 has UPOLYC D1
            and D3 has Join(FramedAlgebra(D1,D2),RetractableTo D1)
   [2] ((D4 -> D5),Fraction D4) ->
        Fraction D5 from FractionFunctions2(D4,D5)
            if D4 has INTDOM and D5 has INTDOM

 [1]  signature:   ((POLY INT -> UP(x,POLY INT)),FRAC POLY INT) ->
                   FRAC UP(x,POLY INT)
      implemented: slot (Fraction (UnivariatePolynomial x (Polynomial
(Integer))
))(Mapping (UnivariatePolynomial x (Polynomial (Integer))) (Polynomial
(Integer)
))(Fraction (Polynomial (Integer))) from FRAC2(POLY INT,UP(x,POLY INT))

   Loading C:/Program Files/axiom/mnt/windows/algebra/FRAC2.o for
      package FractionFunctions2
   Loading C:/Program Files/axiom/mnt/windows/algebra/QFCAT2.o for
      package QuotientFieldCategoryFunctions2
   Loading C:/Program Files/axiom/mnt/windows/algebra/PGCD.o for
      package PolynomialGcdPackage

   (2)  1
   Type: Fraction UnivariatePolynomial(x,Polynomial Integer)

-----------

William Sit continued:

> This is unfortunately a consequence of the design goal to
> permit elements of UP(x,R) to be coercible to POLY R where
> the main variable is coerced into the variable using the
> identifier x. ...

I don't think that this is the case since we can obtain the
same result above using:

  (1/x)$MPOLY([x],FRAC POLY INT)*x
  %::FRAC MPOLY([x],POLY INT)

> Here R IS FRAC POLY INT, and UP(x, FRAC POLY INT) is first
> coerced into FRAC UP(x, POLY INT) and then further to
> FRAC POLY INT via UP(x, POLY INT) to POLY INT (from map
> from FRAC2(UP(x, POLY INT),POLY INT)

Apparently on the first coercion is sufficient. Moving the
fraction from the coefficient domain to become a fraction
of polynomials:

  UP(x, FRAC POLY INT) +-> FRAC UP(x, POLY INT)

provides a domain in which the two uses of x can cancel.

In fact we can see this same coercion in operation in the
case of going from:

  POLY FRAC INT +-> FRAC POLY INT

(1) -> (1/2*x)$UP(x, FRAC INT)

        1
   (1)  - x
        2
   Type: UnivariatePolynomial(x,Fraction Integer)

(2) -> )set message bottom on
(2) -> %::FRAC UP(x,INT)

 Function Selection for map by coercion facility (map)
      Arguments: ((INT -> UP(x,INT)),FRAC INT)
      Target type: FRAC UP(x,INT)
   -> no appropriate map found in Fraction Integer
   -> no appropriate map found in
        Fraction UnivariatePolynomial(x,Integer)
   -> no appropriate map found in
        UnivariatePolynomial(x,Integer)
   -> no appropriate map found in Integer
   -> no appropriate map found in
        UnivariatePolynomial(x,Integer)

 Modemaps from Associated Packages
   [1] ((D7 -> D11),FractionalIdeal(D7,D8,D9,D10)) ->
                    FractionalIdeal(D11,D1,D2,D3)
            from FractionalIdealFunctions2(D7,D8,D9,D10,D11,D1,D2,D3)
            if D7 has EUCDOM and D8 has QFCAT D7 and D9 has UPOLYC D8
            and D10 has Join(FramedAlgebra(D8,D9),RetractableTo D8) and
            D11 has EUCDOM and D1 has QFCAT D11 and D2 has UPOLYC D1
            and D3 has Join(FramedAlgebra(D1,D2),RetractableTo D1)
   [2] ((D4 -> D5),Fraction D4) -> Fraction D5 from
        FractionFunctions2(D4,D5)
            if D4 has INTDOM and D5 has INTDOM

 [1]  signature:   ((INT -> UP(x,INT)),FRAC INT) -> FRAC UP(x,INT)
      implemented: slot (Fraction (UnivariatePolynomial x
(Integer)))(Mapping (U
nivariatePolynomial x (Integer)) (Integer))(Fraction (Integer)) from
FRAC2(INT,U
P(x,INT))

   Loading C:/Program Files/axiom/mnt/windows/algebra/FRAC2.o for
      package FractionFunctions2
   Loading C:/Program Files/axiom/mnt/windows/algebra/QFCAT2.o for
      package QuotientFieldCategoryFunctions2
   Loading C:/Program Files/axiom/mnt/windows/algebra/HEUGCD.o for
      package HeuGcd
   Loading C:/Program Files/axiom/mnt/windows/algebra/INMODGCD.o for
      package InnerModularGcd
   Loading C:/Program Files/axiom/mnt/windows/algebra/EMR.o for domain
      EuclideanModularRing
   Loading C:/Program Files/axiom/mnt/windows/algebra/MDDFACT.o for
      package ModularDistinctDegreeFactorizer
   Loading C:/Program Files/axiom/mnt/windows/algebra/MODRING.o for
      domain ModularRing

        x
   (2)  -
        2
   Type: Fraction UnivariatePolynomial(x,Integer)

> and the Interpreter probably simplified POLY POLY INT to
> POLY INT). In other words, we have ((1/x ?)::(?/x)::(x/x)=1.
> The bug therefore probably lies in the identification of
> POLY POLY INT with POLY INT where the outer ? (or x) is
> identified with x of the inner POLY.

I don't see this happening anywhere above. On the contrary this
calculation seems to me to demonstrate the extraordinary power
of the generic algorithms that are part of the Axiom library.

> Conclusion: (i) Any simplification of towers which makes
> sense in mathematics probably would not make sense in
> computer algebra (due to scope problems for one). Other
> examples could be FRAC FRAC INT to FRAC INT and EXPR EXPR
> INT to EXPR INT.

I don't understand this comment. What do you mean by
"scope problems"?

> (ii) Users should be alert to the order in which an input is
> scanned and the consequences, and break a long input into
> simpler steps.

I agree that simple steps are easier to analyze. I also
think it is a mistake to write something like:

  (x+1)::POLY INT

or

  x+1::POLY INT

when

  (x+1)$POLY INT

will do. In the first two cases the interpreter will do
some extra computation by default before it applies the
coercion operation and the result of coercion is harder
to analyze than the simple package call.

> (iii) Users should not use the same identifier for two
> different objects.

I think that this is simply not possible in Axiom.

\start
Date: 24 Feb 2006 07:54:40 +0100
From: Gabriel Dos Reis
To: David Mentre
Subject: re: ASDF and ./configure

David Mentre writes:

| Hello Tim,
| 
| I looked at the ./configure script so I can reply more specifically
| now. 
| 
| Tim Daly writes:
| 
| > The issue, as i understand it, is not that the configure script
| > doesn't work on the systems where it was tested. The issue is that
| > the configure script is not robust. Certain problems have to be
| > decided.
| 
| I understand, this is the issue faced by all ./configure scripts.
| 
| You have two options to make it more robust:
| 
|  1. use the ./configure generated by autoconf tools. There is a lot of
|     knowledge in them, but most of this knowledge is not needed for
|     Axiom:
| 
|     - who needs to build Axiom on outdated systems like Ultrix?

The value of using Autoconf for Axiom is not in building it on or for
Ultrix, but in reusing packaged knowledge about various regular systems,
taken care of by system packagers.  Axiom really should be developing
its own idea of config.guess or system triplet.  The last thing I
would hate Axiom to exhibit is the the NIH symptom as far as the build
and packaging mechanism is concerned.

|     - most of autoconf knowledge is related to C issues, while most
|       Axiom issues are Lisp ones (once GCL is built, and GCL is using
|       autoconf),

this is true, as long as, one ignores that a configure script
generated from Autoconf can contains *custom* variation either
directly in configure.ac or in the macro aclocal.m4.  I contend that
if you can write the configure script by hand, then you should
take advantage of Autoconf by letting it generate configure
automatically and customizing the generation through aclocal.m4.  I
also claim that is you write configure by hand, then you will end up
reinventing Autoconf functionalities with more bugs -- put in here
usual wisdom about lisp functionalities and programs written in other
programming languages.  

|     - when the generated configure script fails, it is a nightmare to
|       understand *what* is going wrong;

I have used, build, and maintained "large" systems with Autoconf and
the above matches the opposite of my experience.  Quite often, I've
found that when the build, installation fails or is brittle, it is
because someone has tried to avoid Autconf and ended up with
reinventing the wheel with more bugs.

[...]

|  - the equality of strings is "==", not "=" (as far as I know);

ahem, in which shell?  Even configure generated by Autoconf
exclusively uses "=".  Autoconf has been widely test in more wild
environment than anything variation you'll come up here.  I would
suggest that we avoid NIH and reuse the wisdom of the Autoconf guys
who have faced and experienced wild shell variation issues.

-- Gaby



\start
Date: 24 Feb 2006 18:28:07 +0100
From: Gabriel Dos Reis
To: Tim Daly
Subject: re: ASDF and ./configure
Cc: David Mentre

Tim Daly writes:

[...]

| I thought of trying to use the M4 macros for determining system
| information but eventually gave up. There are many other areas of
| Axiom where I can do useful work.

I can definitely understand and appreciate that.  Nevertheless, I
believe we can "divide" the work; if you give a good and essentially
complete description of the system information you'd want to extract,
I or any other person familiar with Autoconf may help implement the
specification. 

\start
Date: Fri, 24 Feb 2006 02:59:31 -0600
From: MathAction (billpage)
To: MathAction
Subject: [Streams] infinite streams

unknown asked:

> how AXIOM can find out when complete has computed all
> members of the stream

That's a good question and it shows I answered your last
question a little too quickly!

I understand that you mean we can write for example
\begin{axiom}
p1:=[p for p in smallPrimes while p < 1200]
p2:=[p for p in smallPrimes | p < 1200]
\end{axiom}

And we can compute:
\begin{axiom}
# entries complete p1
\end{axiom}

But the following command will not complete::

  # entries complete p2

because Axiom does not try to prove even the simple fact
that '| p < 1200' can never be satisfied for some p > 1200.

So I withdraw my statement:

> In this example the while clause and the | notation
> (which is read: such that) are equivalent.

Clearly they are not equivalent. :(

\start
Date: Fri, 24 Feb 2006 14:36:49 +0100
From: Ralf Hemmecke
To: William Sit
Subject: natural isomorphisms (was: Re: 1/x x = 1 is a bug!)

On 02/24/2006 01:14 PM, William Sit wrote:
> A big big question in computer algebra should be how to handle "canonically
> isomorphic" mathematical objects. Mathematicians assume these identifications
> without a thought in most cases, but there are occasions where distinction is
> important. For example, they would rarely identify two vastly differently
> defined finite sets just because they have the same cardinality.

I very much agree that computer algebra is harder than mathematics in 
the sense that one cannot simply identify certain objects. One must give 
the corresponding map explicitly.

As William said, in some context one wants to identify and in some other 
context it would be better to treat the objects as different things. 
That basically says, in order to do mathematics with a computer there 
should not be a program (like the interpreter) that automatically 
identifies objects for the user. Well, for beginners it would be nice to 
have such a tool, but when one wants to do serious mathematics and 
automatic coercion would forbid to express certain mathematical 
constructions.

William. recently, I have posted a little program

http://wiki.axiom-developer.org/Fraction#msg20060207062741-0600@wiki.axiom-developer.org

That shows how to implement in Aldor that FRAC R has the same 
representation as R if R is a field.

Now, I don't believe that it is a good idea to do this in general. I 
rather think that it would be better to open up a new wiki page, for example

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

and list such design issues as William gave in his mail. That would be a 
common denominator that all Axiom developers should agree on.

\start
Date: Fri, 24 Feb 2006 16:39:58 -0600
From: MathAction (root)
To: MathAction
Subject: [#270 integrating UTS] [#270 integrating UTS] 1/x x = 1 is a bug!

>  Users should not use the same identifier for two different objects.

consider that this is COMPUTATIONAL mathematics. the user has to know
what the scope of a variable is. the 'bug' is actually a user error.
the behavior of the system is well defined and the result can be
predicted. failure to correctly scope variables is a standard programmer
error.

removing simplification of type towers would significantly reduce the
usefulness of axiom.

\start
Date: Fri, 24 Feb 2006 15:14:49 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: Re: about Expression Integer

Hi Bill,

> (4) -> Z:Float:=1
> 
>    (4)  1.0
>    Type: Float
> 
> (5) -> Z::INT        <---- this is a conversion of Float to INT
> 
>    (5)  1
>    Type: Integer

Now, I learned something new. And maybe Axiom behaves here different 
from Aldor.

In Aldor "Z::Integer" is just syntactic sugar for writing
"coerce(Z)@Integer" (which looks for a function

coerce: Float -> Integer

currently in scope and applies it).

In Aldor there is (almost) never a coercion (type cast) done 
automatically. Of course you can write something like

aldor -gloop
#include "aldor"
#include "aldorinterp"
Z:SingleFloat := 1;

But there is no coercion involved. Since SingleFloat is of type 
ArtithmeticType.

%10 >> SingleFloat has ArithmeticType
T @ Boolean
%11 >> ArithmeticType
  @ Category == AdditiveType with
         1: %
         *: (%, %) -> %
         ^: (%, MachineInteger) -> %
         commutative?: Boolean
         one?: % -> Boolean
         times!: (%, %) -> %
         default
                 local copy?: Boolean == % has CopyableType
                 one?(a: %): Boolean == ..
                 times!(a: %, b: %): % == ..

The 1 is simply interpreted as the constant 1 in SingleFloat.

Now the following is also clear.

%14 >> Z := 2
        .....^
[L14 C6] #1 (Error) No meaning for integer-style literal `2'.
%15 >> Z:=2.0
2 @ SingleFloat
%16 >> import from Integer
%17 >> Z := 2
        .....^
[L17 C6] #1 (Error) There is no suitable interpretation for the expression 2
   The context requires an expression of type SingleFloat.
      The possible types of the right hand side (`2') are:
           -- AldorInteger

I like that Aldor does nothing automatically.

Ralf

PS: To be correct there is one case that comes to my mind where the 
Aldor compiler is a bit more relaxed.
See "Curtesy conversions" at
http://www.aldor.org/docs/HTML/chap7.html#6



\start
Date: Fri, 24 Feb 2006 07:14:24 -0500
From: William Sit
To: Bill Page
Subject: Re: 1/x x = 1 is a bug!
Cc: list

Bill:

> This thread seems to go on forever ... but I feel compelled
> to continue it because: 1) I think understanding how this
> works is critical to understanding and using Axiom, 2) I don't
> think we have a simple explanation yet of something that really
> should be simple in principle, if not in it's application in
> certain cases.

There never is anything simple in Axiom. By its nature every function is
parametrized and categorical. Clearly, this issue will recur as new users
stumbles onto these constructions.

As you know, a polynomial ring R over a ring S in the indeterminates x1, ...,
xn, means that x1, ..., xn are algebraically independent over S; in particular,
they are NOT elements of S. If you really want 1/x x to mean 1, the two x must
live in the same domain. Either you put 1/x in the coefficient domain S and then
err on using the same identifier for a transcendental over S, or you should
simply use the x from S in forming 1/x x in FRAC S (assuming S has INTDOM).

When you write UP(x, FRAC POLY INT), you specifically told Axiom that x (more
precisely, the indeterminate ? with an identifier x) is transcendental over FRAC
POLY INT. So you should NOT use x in FRAC POLY INT. The fact that Axiom cannot
disallow you to do that is not a license to violate this mathematical
definition! In any computer language, there are always unforseen constructions
that a compiler cannot diagnose and sometimes, such 'abuse' may be used for
tricky programming, but they are 'abuse' none the less. For old FORTRAN
programmers, this is similar to core to core I/O where you can turn an integer
into a real with the same binary representation. FORTRAN allows this, but you
can't possibly say mathematically the two are the same! When a programmer
deliberately violates the rules of construction that cannot be caught by the
compiler, it is a bug of the compiler.

However, no matter how buggy a computer algebra system is, we are using it to do
MATHEMATICS and so NO mathematical rules should be violated in the computations.

As to your quibble to my separating 'identifier', let me emphasize:
'identifiers' are external strings what a user in the interpreter use to refer
to objects that are internal to Axiom. Symbol and Variable are domains in Axiom
and their objects are internal. The fact that we use the same identifier string
as the representation string for a Symbol object is only a convenience. As you
pointed out, a symbol object need NOT be a simple string and can be adorned with
all sorts of scripts. You would not want to keep inputting a symbol adorned in a
complicated way in its full detail (note the linear form to enter such a symbol
is a function, not the representation). So if I say:

(1) -> y:=x[1,2,3,4]

 Function Selection for x
      Arguments: LIST PI
   -> no function x found for arguments LIST PI

 Function Selection for elt
      Arguments: (VARIABLE x,LIST PI)

 [1]  signature:   (SYMBOL,LIST OUTFORM) -> SYMBOL
      implemented: slot $$(List (OutputForm)) from SYMBOL


 Function Selection for elt
      Arguments: (VARIABLE x,LIST PI)

 [1]  signature:   (SYMBOL,LIST OUTFORM) -> SYMBOL
      implemented: slot $$(List (OutputForm)) from SYMBOL


 Function Selection for map by coercion facility (map)
      Arguments: ((PI -> OUTFORM),LIST PI)
      Target type: LIST OUTFORM

 [1]  signature:   ((PI -> OUTFORM),LIST PI) -> LIST OUTFORM
      implemented: slot (List (OutputForm))(Mapping (OutputForm) (PositiveIntege
r))(List (PositiveInteger)) from LIST2(PI,OUTFORM)


   (1)  x
         1,2,3,4
                                                                 Type: Symbol

then 
   y is the identifier I use (y is NOT the symbol), 
   x[1,2,3,4] the linear function with signature 
     elt: (VARIABLE x, LIST PI)->SYMBOL, and 
   the symbol is x with 1,2,3,4 as subscripts
   x itself is a Symbol and is different (as far as Axiom goes) from 
   the x in the domain 'Variable(x)' 
Just to emphasize the fine distinctions, the output you see, is an element of
OUTPUTFORM! (another string representing some internal object of the domain
Symbol).

> William Sit continued:
> 
> > This is unfortunately a consequence of the design goal to
> > permit elements of UP(x,R) to be coercible to POLY R where
> > the main variable is coerced into the variable using the
> > identifier x. ...
> 
> I don't think that this is the case since we can obtain the
> same result above using:
> 
>   (1/x)$MPOLY([x],FRAC POLY INT)*x
>   %::FRAC MPOLY([x],POLY INT)
> 
I am trying to explain the coercion using UP(x,R) as a generic representative.
Sure, you can violate the rule of construction using any of the polynomial
domains in Axiom. The short answer is, any indeterminate you use in the
construction of a polynomial domain is transcendental over the coefficient
domain and should NOT be coercible to the coefficient domain! I am saying, the
above design goal is flawed in illegal constructions like these, but makes sense
in the legal construction 

  coerce: UP(x,R) -> POLY R

when R does not contain x (and it shouldn't contain x, and if it does, wrongly,
in concept, then x should not be instantiated there).

> > Here R IS FRAC POLY INT, and UP(x, FRAC POLY INT) is first
> > coerced into FRAC UP(x, POLY INT) and then further to
> > FRAC POLY INT via UP(x, POLY INT) to POLY INT (from map
> > from FRAC2(UP(x, POLY INT),POLY INT)
> 
> Apparently on the first coercion is sufficient. Moving the
> fraction from the coefficient domain to become a fraction
> of polynomials:
> 
>   UP(x, FRAC POLY INT) +-> FRAC UP(x, POLY INT)
> 
> provides a domain in which the two uses of x can cancel.
 
You are missing the point.
I don't care how the Interpreter performs the illegal coercion (except that I
was trying to explain the design goal that leads to the illegal coercion). The
coercion is simply WRONG. Period. It is an error built on a user error. (Don't
we know that compilers are famous for that when reporting error messages?) In
such cases, a user is supposed to remove the original error, not argue about the
validity or invalidity of subsequent errors.

> In fact we can see this same coercion in operation in the
> case of going from:
> 
>   POLY FRAC INT +-> FRAC POLY INT
> 
> (1) -> (1/2*x)$UP(x, FRAC INT)
> 
>         1
>    (1)  - x
>         2
>    Type: UnivariatePolynomial(x,Fraction Integer)
> 
> (2) -> )set message bottom on
> (2) -> %::FRAC UP(x,INT)
> 
[additonal output snipped]

These are legal coercions since mathematically, POLY FRAC INT is a subring of
FRAC POLY INT and similarly, UP(x, FRAC INT) is a subring of FRAC UP(x, INT).
The design goal I mentioned above is NOT involved. If you had taken x/2 in FRAC
POLY INT or in POLY FRAC INT and coerce this to UP(x, FRAC INT), then the design
goal is applied and the Interpreter (not the compiler) will oblige by
identifying the 
the variable x of POLY FRAC INT with the main variable ? of UP(x, FRAC INT)
because the user used the identifier x for ?.  This feat is accomplished only
with the help of UP2(x,POLY FRAC INT,x,FRAC INT), which explicitly maps the x in
POLY FRAC INT to the x (or ?) of UP(x, FRAC INT). It is equivalent to a
substitution map. There is no general coercion from POLY FRAC INT to UP(x, FRAC
INT).

> > Conclusion: (i) Any simplification of towers which makes
> > sense in mathematics probably would not make sense in
> > computer algebra (due to scope problems for one). Other
> > examples could be FRAC FRAC INT to FRAC INT and EXPR EXPR
> > INT to EXPR INT.
> 
> I don't understand this comment. What do you mean by
> "scope problems"?

When one constructs POLY POLY INT, one tells Axiom to use Symbol as the variable
set over POLY INT. Thus the Symbol in the outer construction should be in a
different lexicon scope so that this COPY of Symbol can be a family of
algebraically independent elements over POLY INT.  I don't want to go into the
details of how domains are constructed (I probably don't know anyway), but IF we
modify whatever will be used as symbols in POLY INT by attaching a context
prefix, say POLYINT-x for what we normally use x, then we can distinguish
another symbol x in this COPY for the external POLY construction by using
POLYPOLYINT-x. Apparently, the Interpreter allows a substitution of
POLYPOLYINT-x by POLYINT-x, giving the user the impression that the two are
identified, and this is the flaw I was discussing. The Interpreter should not do
that with coercion. A substitution should be explicitly requested by the user. A
coercion should not involve a hidden substitution.

Let me repeat this mathematically. Let $R$ be a ring, $S$ a set and $X =
{x_s}_{s \in S}$ be a family of algebraic indeterminates over $R$. Then we can
construct the polynomial ring R[X]. If we like, we can let $Y = {y_s}_{s \in S}$
be another family of algebraic indeterminates over $R[X]$ and construct
$R[X][Y]$.  We can make substitution maps $y_s \mapsto x_s$, but we should NEVER
identify $y_s$ with $x_s$ and say $R[X][Y] = R[X]$ simply because $X$ and $Y$
are indexed by the same set $S$.
No one would argue that $x_s + y_s = 2x_s$ is correct, or the derivative of $x_s
+ y_s $ with respect to $x_s$ is 2 and not 1. 

You can substitute R by Integer and S by Symbol. The problem with the computer
algebra case is that Symbol is like the set of all symbols in concept, and a
priori prevents construction of any other symbol outside Symbol. This is a very
bad restriction. We want to be able to talk about unknowns over EXPR INT, say in
differential equations. In reality, only finitely many symbols are instantiated
and hence we can solve the problem using context-prefix (scope separation). So
while this all encompassing concept may be convenient, it should be taken with a
grain of salt. Mathematica for example uses context-prefixes in their packages.

The construction of FRAC FRAC INT is similar, except that in this case, there is
no argument that if R is an integral domain, and Q(R) its quotient field, then
Q(Q(R)) is isomorphic to Q(R). But it is precisely that the sets Q(Q(R)) and
Q(R) are NOT the same set, but just isomorphic (even canonically), that requires
the implelmentation of the isomorphism in computer algebra. One simply cannot
"identify" the two sets in computer algebra because they do have different data
representations. In order to implement the isomorphism, one must be able to
distinguish when $x \in R$ is regarded as $x/1 \in Q(R)$ or $(x/1)/(1/1) \in
Q(Q(R))$. One way would be to use context-prefix. To the naive users, this seems
really much ado about nothing, Axiom relies on users not to construct (or
explicitly disallows in the Interpreter) such towers.  However, this is only ok
up to a point. When one can write routines that return domains, this naive
design forces a case by case examination of the returned domains to screen out
"trivial" (I would prefer the adjective "boundary") cases (for example, if I
want to construct FRAC R where R is a run-time computed domain, then I need to
use something like "if R has FIELD then R" in FRAC R construction).
Unfortunately, the pedantic (isomorphism) way is very inefficient so a
compromise was taken.

A big big question in computer algebra should be how to handle "canonically
isomorphic" mathematical objects. Mathematicians assume these identifications
without a thought in most cases, but there are occasions where distinction is
important. For example, they would rarely identify two vastly differently
defined finite sets just because they have the same cardinality.

> > (ii) Users should be alert to the order in which an input is
> > scanned and the consequences, and break a long input into
> > simpler steps.
> 
> I agree that simple steps are easier to analyze. I also
> think it is a mistake to write something like:
> 
>   (x+1)::POLY INT
> 
> or
> 
>   x+1::POLY INT
> 
> when
> 
>   (x+1)$POLY INT
> 
> will do. In the first two cases the interpreter will do
> some extra computation by default before it applies the
> coercion operation and the result of coercion is harder
> to analyze than the simple package call.

Agreed.

>  (iii) Users should not use the same identifier for two
> > different objects.
> 
> I think that this is simply not possible in Axiom.
> 
I am not talking about spad code, where there are multiple scopes. In the
interpreter, unless you use a different frame, all identifiers the user uses are
in one scope. If you use x for UP(x, POLY INT), then you should not use x in
POLY INT. May be you can give me an example where you MUST use (or at least it
is desirable to use) the same identifier for two different objects in an
Interpreter session?

\start
Date: 25 Feb 2006 07:14:03 +0100
From: Gabriel Dos Reis
To: David Mentre
Subject: re: ASDF and ./configure

David Mentre writes:

| [1] The Makefile.pamphlet says "Fedora Core 3 needs special GCL
| options for local bfd." but it does not say *why* the local bfd is
| necessary. 

Tim --

   Could you enlighten us on this?

\start
Date: Sat, 25 Feb 2006 13:43:28 +0100
From: David Mentre
To: Gabriel Dos Reis
Subject: re: ASDF and ./configure

Gabriel Dos Reis writes:

> Nevertheless, I
> believe we can "divide" the work; if you give a good and essentially
> complete description of the system information you'd want to extract,
> I or any other person familiar with Autoconf may help implement the
> specification. 

Or any person willing to be familiar with Autoconf. ;)

\start
Date: Sat, 25 Feb 2006 12:53:36 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: re: ASDF and ./configure
Cc: list, David Mentre

actually, no. i don't remember (thus, proving that documentation is
vital) why the locbfd was chosen. there was an issue that arose about
building GCL on FC3 which went on between Camm and I but I no longer
have the emails. it may be somewhere in the mailing list archives.
at this point it falls to superstition ("because it works").

\start
Date: Sat, 25 Feb 2006 16:04:34 -0500
From: William Sit
To: Bill Page, list
Subject: delayed distribution of mail

Dear Bill:

Recently, there seems to be delays of over a day for distribution of updates on
the Wiki pages and maybe also emails to/from axiom-developers. Below is the mail
header for one I sent and received back from axiom. It used to be much faster
(within minutes) for the round-trip.

The changes to the page was recorded at around
1/x x = 1 is a bug! --wyscc, Thu, 23 Feb 2006 01:07:56 -0600 reply

and apparently sent out at that time. 
Thu, 23 Feb 2006 01:08:00 -0600

It then took about 14 hours 
Thu, 23 Feb 2006 15:39:01 -0500

to leave lists.gnu.org and another 25 hours additional to reach my email box
Fri, 24 Feb 2006 17:20:11 -0500

(and some more delay on my part to read it).

May be this indicates some problem or may be it is just network traffic? I just
want to report this to see if others on the board experience the same thing.

The problem that such delay causes is that someone, like you, can respond by
logging onto the Wiki pages directly, way before any subscribers can see the
email. Indeed, I received your response (because you sent it directly to me) and
responded way before anyone else may have seen this.

\start
Date: Thu, 23 Feb 2006 01:08:00 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#270 integrating UTS] 1/x x = 1 is a bug!

I think recently this issue of using the same 'identifier' 'x' to
stand for two different 'variables' in two different domains (either
accidentally or on purpose) has been thoroughly discussed, but not
quite. Note that I distinguish 'identifier' from 'variable'. We have
two variables, usually one internally denoted by the 'Symbol' 'x' and
another unspecified as ? (as in 'UP(x,INT)') where ? does NOT exist
but can either be printed as ? or any identifier the user prefers,
such as 'x'. As any one who does programming should know, the same
'identifier' should never be used to denote two different objects (at
least not within the same scope). By the way, this design is in some
sense ingenious, and necessary, to allow extending a polynomial ring
that already has all the symbols as variables; such extension is
useful in testing radical ideal membership of polynomial rings, and
intersections of polynomial ideals, for example.

\start
Date: 25 Feb 2006 23:02:40 +0100
From: Gabriel Dos Reis
To: William Sit
Subject: Re: delayed distribution of mail
Cc: Bill Page

William Sit writes:


[...]

| May be this indicates some problem or may be it is just network traffic? I just
| want to report this to see if others on the board experience the same thing.
| 

yes, I have been experiencing that, and I did not know whether it was
just me...

\start
Date: Sat, 25 Feb 2006 16:56:28 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#270 integrating UTS] 1/x x = 1 is a feature(?)

> Now Axiom having been forced to output the same identifier for two
  different variables, the first x bound to a variable in FRAC POLY
  INT, and the second x bound to the main variable of ULS, should NOT
  then simplify the expression 1/x x of (3) to 1.

I have examined this simplification more closely. As discussed in
another email, this is actually done by invoking a substitution map:
briefly, the x in ULS is being substituted by the x in FRAC POLY
INT. I think this is unwarranted "smartness" by the Interpreter (this
is a "lesser crime" than a "bug"). Of course, as Tim said above, this
is secondary error due to an error by the user. It would be a
legitimate substitution if a user initiated it. I believe the
automatic substitution would not be done in the compiler (that is, the
coercion would be flagged).

The Axiom compiler, as far as I can tell, scoped the two x's
correctly. It is the automatic substitution by the Interpreter due to
a request to coerce that yields the answer 1. Whether you call this a
feature or a bug is up to you. Users beware.

William

>From email referred to above: (edited for Wiki) ::

  Date: Fri, 24 Feb 2006 07:14:24 -0500
  From: William Sit
  To: Bill Page


Bill::

  > This thread seems to go on forever ... but I feel compelled
  > to continue it because: 1) I think understanding how this
  > works is critical to understanding and using Axiom, 2) I don't
  > think we have a simple explanation yet of something that really
  > should be simple in principle, if not in it's application in
  > certain cases.

There never is anything simple in Axiom. By its nature every function is
parametrized and categorical. Clearly, this issue will recur as new users
stumbles onto these constructions.

As you know, a polynomial ring $R$ over a ring $S$ in the indeterminates $x$<sub>1</sub>, ...,
$x$<sub>n</sub>, means that $x$<sub>1</sub>, ..., $x$<sub>n</sub> are algebraically independent over $S$; in particular,
they are *not* elements of $S$. If you really want $\frac{1}{x}x$ to mean 1, the two $x$'s must
live in the same domain. Either you put $\frac{1}{x}$ in the coefficient domain $S$ and then
err on using the same identifier for a transcendental over $S$, or you should
simply use the $x$ from $S$ in forming $\frac{1}{x}x$ in the quotient field of $S$ (assuming $S$ is an integral domain).

When you write 'UP(x, FRAC POLY INT)', you specifically told Axiom that 'x' (more
precisely, the indeterminate ? with an identifier 'x') is transcendental over 'FRAC
POLY INT'. So you should *not* use 'x' in 'FRAC POLY INT'. The fact that Axiom cannot
disallow you to do that is not a license to violate this mathematical
definition! In any computer language, there are always unforseen constructions
that a compiler cannot diagnose and sometimes, such *abuse* may be used for
tricky programming, but they are *abuse* nonetheless. For old FORTRAN
programmers, this is similar to core to core I/O where you can turn an integer
into a real with the same binary representation. FORTRAN allows this, but you
can't possibly say mathematically the two are the same! When a programmer
deliberately violates the rules of construction that cannot be caught by the
compiler, it is a bug of the compiler.

However, no matter how buggy a computer algebra system is, we are using it to do
**mathematics** and so *no* mathematical rules should be violated in the computations.

As to your quibble to my separating "identifier", let me emphasize:
identifiers are external strings what a user in the interpreter use to refer
to objects that are internal to Axiom. 'Symbol' and 'Variable' are domains in Axiom
and their objects are internal. The fact that we use the same identifier string
as the representation string for a 'Symbol' object is only a convenience. As you
pointed out, a 'Symbol' object need *not* be a simple string and can be adorned with
all sorts of scripts. You would not want to keep inputting a symbol adorned in a
complicated way in its full detail (note the linear form to enter such a symbol
is a function, not the representation). So if I say

\begin{axiom}
)set mess bot on
y:=x[1,2,3,4]
\end{axiom}

then::

   y is the identifier I use (y is NOT the symbol),
   x[1,2,3,4] the linear function with signature
      elt: (VARIABLE x, LIST PI)->SYMBOL, and
   the symbol is x with [1,2,3,4] as subscript
   x itself is a Symbol and is different (as far as Axiom goes) from
   the x in the domain Variable(x)

Just to emphasize the fine distinctions, the output you see, is an element of
'OUTPUTFORM'! (another string representing some internal object of the domain
'Symbol').

Bill Page wrote::

  > William Sit continued:
  >
  > > This is unfortunately a consequence of the design goal to
  > > permit elements of UP(x,R) to be coercible to POLY R where
  > > the main variable is coerced into the variable using the
  > > identifier x. ...
  >
  > I don't think that this is the case since we can obtain the
  > same result above using:
  >
  >   (1/x)$MPOLY([x],FRAC POLY INT)*x
  >   %::FRAC MPOLY([x],POLY INT)

I am trying to explain the coercion using 'UP(x,R)' as a generic representative.
Sure, you can violate the rule of construction using any of the polynomial
domains in Axiom. The short answer is, any indeterminate you use in the
construction of a polynomial domain is transcendental over the coefficient
domain and should NOT be coercible to the coefficient domain! I am saying, the
above design goal is flawed in illegal constructions like these, but makes sense
in the legal construction::

  coerce: UP(x,R) -> POLY R

when 'R' does not contain 'x' (and it shouldn't contain 'x', and if it does, wrongly,
in concept, then 'x' should not be instantiated there). 
<pre>
  > > Here R IS FRAC POLY INT, and UP(x, FRAC POLY INT) is first
  > > coerced into FRAC UP(x, POLY INT) and then further to
  > > FRAC POLY INT via UP(x, POLY INT) to POLY INT (from map
  > > from FRAC2(UP(x, POLY INT),POLY INT)
  >
  > Apparently on the first coercion is sufficient. Moving the
  > fraction from the coefficient domain to become a fraction
  > of polynomials:
  >
  >   UP(x, FRAC POLY INT) +-> FRAC UP(x, POLY INT)
  >
  > provides a domain in which the two uses of x can cancel.
</pre>
You are missing the point.

I don't care how the Interpreter performs the illegal coercion (except that I
was trying to explain the design goal that leads to the illegal coercion). The
coercion is simply WRONG. Period. It is an error built on a user error. (Don't
we know that compilers are famous for that when reporting error messages?) In
such cases, a user is supposed to remove the original error, not argue about the
validity or invalidity of subsequent errors. 
<pre>
  > In fact we can see this same coercion in operation in the
  > case of going from:
  >
  >   POLY FRAC INT +-> FRAC POLY INT
  >
  > (1) -> (1/2*x)$UP(x, FRAC INT)
  >
  >         1
  >    (1)  - x
  >         2
  >    Type: UnivariatePolynomial(x,Fraction Integer)
  >
  > (2) -> )set message bottom on
  > (2) -> %::FRAC UP(x,INT)
  [additonal output snipped]
</pre>
These are legal coercions since mathematically, 'POLY FRAC INT' is a subring of
'FRAC POLY INT' and similarly, 'UP(x, FRAC INT)' is a subring of 'FRAC UP(x, INT)'.
The design goal I mentioned above is *not* involved. If you had taken 'x/2' in 'FRAC
POLY INT' or in 'POLY FRAC INT' and coerce this to 'UP(x, FRAC INT)', then the design
goal is applied and the Interpreter (not the compiler) will oblige by
identifying the
the variable 'x' of 'POLY FRAC INT' with the main variable ? of 'UP(x, FRAC INT)'
because the user used the identifier 'x' for ?.  This feat is accomplished only
with the help of 'UP2(x,POLY FRAC INT,x,FRAC INT)', which explicitly maps the 'x' in
'POLY FRAC INT' to the 'x' (or ?) of 'UP(x, FRAC INT)'. It is equivalent to a
*substitution* map. There is *no* general coercion from 'POLY FRAC INT' to 'UP(x, FRAC
INT)'. 
<pre>
  > > Conclusion: (i) Any simplification of towers which makes
  > > sense in mathematics probably would not make sense in
  > > computer algebra (due to scope problems for one). Other
  > > examples could be FRAC FRAC INT to FRAC INT and EXPR EXPR
  > > INT to EXPR INT.
  >
  > I don't understand this comment. What do you mean by
  > "scope problems"?
</pre>
When one constructs 'POLY POLY INT', one tells Axiom to use 'Symbol' as the variable
set over 'POLY INT'. Thus the 'Symbol' in the outer construction should be in a
different lexicon scope so that this *copy* of 'Symbol' can be a family of
algebraically independent elements over 'POLY INT'.  I don't want to go into the
details of how domains are constructed (I probably don't know anyway), but *if* we
modify whatever will be used as symbols in 'POLY INT' by attaching a context
prefix, say 'POLYINT-x' for what we normally use 'x', then we can distinguish
another symbol 'x' in this *copy* for the external 'POLY' construction by using
'POLYPOLYINT-x'. Apparently, the Interpreter allows a *substitution* of
'POLYPOLYINT-x' by 'POLYINT-x', giving the user the *impression* that the two are
identified, and this is the flaw I was discussing. The Interpreter should not do
that with coercion. A substitution should be *explicitly* requested by the user. A
coercion should not involve a hidden substitution.

Let me repeat this mathematically. Let $R$ be a ring, $S$ a set and $$X =
\{x_s\}_{s \in S}$$ be a family of algebraic indeterminates over $R$. Then we can
construct the polynomial ring $R[X]$. If we like, we can let $$Y = \{y_s\}_{s \in S}$$
be another family of algebraic indeterminates over $R[X]$ and construct
$R[X][Y]$.  We can make substitution maps $y_s \mapsto x_s$, but we should NEVER
identify $y_s$ with $x_s$ and say $R[X][Y] = R[X]$ simply because $X$ and $Y$
are indexed by the same set $S$.
No one would argue that $x_s + y_s = 2x_s$ is correct, or the derivative of 
$x_s + y_s$ with respect to $x_s$ is 2 and not 1.

You can substitute $R$ by 'Integer' and $S$ by 'Symbol'. The problem with the computer
algebra case is that 'Symbol' is like the set of *all* symbols **in concept**, and *a
priori* prevents construction of any other symbol outside 'Symbol'. This is a very
bad restriction. We want to be able to talk about unknowns over 'EXPR INT', say in
differential equations. In reality, only finitely many symbols are instantiated
and hence we can solve the problem using context-prefix (scope separation). So
while this all encompassing concept may be convenient, it should be taken with a
grain of salt. Mathematica for example uses context-prefixes in their packages.

The construction of 'FRAC FRAC INT' is similar, except that in this case, there is
no argument that if $R$ is an integral domain, and $Q(R)$ its quotient field, then
$Q(Q(R))$ is isomorphic to $Q(R)$. But it is precisely that the *sets* $Q(Q(R))$ and
$Q(R)$ are *not* the same set, but just isomorphic (even canonically), that requires
the implelmentation of the isomorphism in computer algebra. One simply cannot
"identify" the two sets in computer algebra because they do have different data
representations. In order to implement the isomorphism, one must be able to
distinguish when $x \in R$ is regarded as $x/1 \in Q(R)$ or 
$(x/1)/(1/1) \in Q(Q(R))$. One way would be to use context-prefix. To the naive users, this seems
really much ado about nothing: Axiom relies on users not to construct (or
explicitly disallows in the Interpreter) such towers.  However, this is only ok
up to a point. When one can write routines that return domains, this naive
design forces a case by case examination of the returned domains to screen out
"trivial" (I would prefer the adjective "boundary") cases (for example, if I
want to construct 'FRAC R' where 'R' is a run-time computed domain, then I need to
use something like 'if R has FIELD then R' in 'FRAC R' construction).
Unfortunately, the pedantic (isomorphism) way is very inefficient so a
compromise was taken.

A big big question in computer algebra should be how to handle "canonically
isomorphic" mathematical objects. Mathematicians assume these identifications
without a thought in most cases, but there are occasions where distinction is
important. For example, they would rarely identify two vastly differently
defined finite sets just because they have the same cardinality.
<pre>
  > > (ii) Users should be alert to the order in which an input is
  > > scanned and the consequences, and break a long input into
  > > simpler steps.
  >
  > I agree that simple steps are easier to analyze. I also
  > think it is a mistake to write something like:
  >
  >   (x+1)::POLY INT
  >
  > or
  >
  >   x+1::POLY INT
  >
  > when
  >
  >   (x+1)$POLY INT
  >
  > will do. In the first two cases the interpreter will do
  > some extra computation by default before it applies the
  > coercion operation and the result of coercion is harder
  > to analyze than the simple package call.

Agreed.
<pre>
  >  (iii) Users should not use the same identifier for two
  > > different objects.
  >
  > I think that this is simply not possible in Axiom.
</pre>
I am not talking about spad code, where there are multiple scopes. In the
interpreter, unless you use a different frame, all *identifiers* the user uses are
in one scope. If you use 'x' for 'UP(x, POLY INT)', then you should not use 'x' in
'POLY INT'. May be you can give me an example where you MUST use (or at least it
is desirable to use) the same identifier for two different objects in an
Interpreter session?

William

<hr>

The following is verbatim quote from Email by Bill Page:
<pre>
-------- Original Message --------
Subject: Re: 1/x x = 1 is a bug!
Date: Fri, 24 Feb 2006 00:58:19 -0500
From: Bill Page
To: William Sit
CC: <list>, Bill Page,Martin Rubey,Ralf Hemmecke, Francois Maltey

William,

This thread seems to go on forever ... but I feel compelled
to continue it because: 1) I think understanding how this
works is critical to understanding and using Axiom, 2) I don't
think we have a simple explanation yet of something that really
should be simple in principle, if not in it's application in
certain cases.

As a long term user of Axiom, I really appreciate you input
on this subject. But I think I must take exception to your
conclusion as stated in the subject line. :)

On Thu, 23 Feb 2006 01:07:56 -0600 at

http://wiki.axiom-developer.org/270IntegratingUTS#bottom

You wrote:

> Now Axiom having been forced to output the same identifier
> for two different variables, the first x bound to a variable
> in FRAC POLY INT, and the second x bound to the main variable
> of ULS, should NOT then simplify the expression 1/x x of (3)
> to 1.

First, I would prefer that we try not to introduce new words
like "identifier" since Axiom already calls these by the name
Symbol. Second, I worry that you are using the word "bound"
in a manner that does not really apply to Axiom. And third,
I think the use of the word "variable" in Axiom has to be
applied with some care.

When you say "x bound to a variable in FRAC POLY INT" I
think you mean only that the symbol 'x' is used as a
polynomial variable in this domain. Exactly what a
"polynomial variable" is, is defined by the specific
implementation of 'FRAC POLY INT', but we know for sure
that it will appear in the List of Symbols that is returned
by the function 'variables' when applied to any member of
this domain. And these symbols also play a role in many
other functions exported by this domain.

If I write things below that are completely obvious to you,
please bear with me and consider it just a short review. Of
course also correct me if I get it wrong. I am assuming that
there are other readers who need might this sort of review.

As you know, Symbols themselves form a domain in Axiom:

  )sh Symbol

I think there is a lot of unnecessary confusion between
symbols and variables.

By definition Symbols are constants and can not be assigned
values. Operations like

  = : (Symbol,Symbol) -> Boolean

compare one symbol to another. There are other operations that
construct new symbols possibly with sub/super-scripts etc. It
might be surprising how sophisticated Axiom's Symbol domain is
and how much of it is coded in SPAD:

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

But of course ultimately all Symbols are represented and
manipulated by Lisp, e.g.:

    coerce(s:String):%     == VALUES(INTERN(s)$Lisp)$Lisp
    x = y                  == EQUAL(x,y)$Lisp

Variables also form a domain in Axiom:

  )sh Variable

Variables are constructed from Symbols, but not all symbols
are necessarily used for this purpose. Members of the Variable
domain in turn can be assigned values and have associated
types.

It may seem strange but Variables are **not** used to form
polynomials in Axiom.

----------

Let's consider the following somewhat simplified example
where Axiom will coerce '1/x x' to 1:

(1) -> (1/x)$UP(x,FRAC POLY INT)*x

        1
   (1)  - x
        x
   Type: UnivariatePolynomial(x,Fraction Polynomial Integer)

Here '1/x' is a coefficient and polynomial variable 'x' is
written to the right of the coefficient. Both uses of 'x'
represent the same Symbol and neither of these are from the
domain Variable.

There is no operation within the domain 'UP(x,FRAC POLY INT)'
which would allow us to conclude that '1/x x' is identical
to 1 even though these are both members of this domain. We
know intuitively however that this expression should be 1
in some other domain, but showing this formally apparently
involves some rather deep knowledge about "fractional ideals"
that is beyond me.

(2) -> )set message bottomup on
(2) -> )set message autoload on
(2) -> %::FRAC UP(x,POLY INT)

 Function Selection for map by coercion facility (map)
      Arguments: ((POLY INT -> UP(x,POLY INT)),FRAC POLY INT)
      Target type: FRAC UP(x,POLY INT)
   -> no appropriate map found in Fraction Polynomial Integer
   -> no appropriate map found in
        Fraction UnivariatePolynomial(x,Polynomial Integer)
   -> no appropriate map found in
        UnivariatePolynomial(x,Polynomial Integer)
   -> no appropriate map found in Polynomial Integer
   -> no appropriate map found in
        UnivariatePolynomial(x,Polynomial Integer)

 Modemaps from Associated Packages
   [1] ((D7 -> D11),FractionalIdeal(D7,D8,D9,D10)) ->
         FractionalIdeal(D11,D1,D2,D3)
            from FractionalIdealFunctions2(D7,D8,D9,D10,D11,D1,D2,D3)
            if D7 has EUCDOM and D8 has QFCAT D7 and D9 has UPOLYC D8
            and D10 has Join(FramedAlgebra(D8,D9),RetractableTo D8) and
            D11 has EUCDOM and D1 has QFCAT D11 and D2 has UPOLYC D1
            and D3 has Join(FramedAlgebra(D1,D2),RetractableTo D1)
   [2] ((D4 -> D5),Fraction D4) ->
        Fraction D5 from FractionFunctions2(D4,D5)
            if D4 has INTDOM and D5 has INTDOM

 [1]  signature:   ((POLY INT -> UP(x,POLY INT)),FRAC POLY INT) ->
                   FRAC UP(x,POLY INT)
      implemented: slot (Fraction (UnivariatePolynomial x (Polynomial
(Integer))
))(Mapping (UnivariatePolynomial x (Polynomial (Integer))) (Polynomial
(Integer)
))(Fraction (Polynomial (Integer))) from FRAC2(POLY INT,UP(x,POLY INT))

   Loading C:/Program Files/axiom/mnt/windows/algebra/FRAC2.o for
      package FractionFunctions2
   Loading C:/Program Files/axiom/mnt/windows/algebra/QFCAT2.o for
      package QuotientFieldCategoryFunctions2
   Loading C:/Program Files/axiom/mnt/windows/algebra/PGCD.o for
      package PolynomialGcdPackage

   (2)  1
   Type: Fraction UnivariatePolynomial(x,Polynomial Integer)

-----------

William Sit continued:

> This is unfortunately a consequence of the design goal to
> permit elements of UP(x,R) to be coercible to POLY R where
> the main variable is coerced into the variable using the
> identifier x. ...

I don't think that this is the case since we can obtain the
same result above using:

  (1/x)$MPOLY([x],FRAC POLY INT)*x
  %::FRAC MPOLY([x],POLY INT)

> Here R IS FRAC POLY INT, and UP(x, FRAC POLY INT) is first
> coerced into FRAC UP(x, POLY INT) and then further to
> FRAC POLY INT via UP(x, POLY INT) to POLY INT (from map
> from FRAC2(UP(x, POLY INT),POLY INT)

Apparently on the first coercion is sufficient. Moving the
fraction from the coefficient domain to become a fraction
of polynomials:

  UP(x, FRAC POLY INT) +-> FRAC UP(x, POLY INT)

provides a domain in which the two uses of x can cancel.

In fact we can see this same coercion in operation in the
case of going from:

  POLY FRAC INT +-> FRAC POLY INT

(1) -> (1/2*x)$UP(x, FRAC INT)

        1
   (1)  - x
        2
   Type: UnivariatePolynomial(x,Fraction Integer)

(2) -> )set message bottom on
(2) -> %::FRAC UP(x,INT)

 Function Selection for map by coercion facility (map)
      Arguments: ((INT -> UP(x,INT)),FRAC INT)
      Target type: FRAC UP(x,INT)
   -> no appropriate map found in Fraction Integer
   -> no appropriate map found in
        Fraction UnivariatePolynomial(x,Integer)
   -> no appropriate map found in
        UnivariatePolynomial(x,Integer)
   -> no appropriate map found in Integer
   -> no appropriate map found in
        UnivariatePolynomial(x,Integer)

 Modemaps from Associated Packages
   [1] ((D7 -> D11),FractionalIdeal(D7,D8,D9,D10)) ->
                    FractionalIdeal(D11,D1,D2,D3)
            from FractionalIdealFunctions2(D7,D8,D9,D10,D11,D1,D2,D3)
            if D7 has EUCDOM and D8 has QFCAT D7 and D9 has UPOLYC D8
            and D10 has Join(FramedAlgebra(D8,D9),RetractableTo D8) and
            D11 has EUCDOM and D1 has QFCAT D11 and D2 has UPOLYC D1
            and D3 has Join(FramedAlgebra(D1,D2),RetractableTo D1)
   [2] ((D4 -> D5),Fraction D4) -> Fraction D5 from
        FractionFunctions2(D4,D5)
            if D4 has INTDOM and D5 has INTDOM

 [1]  signature:   ((INT -> UP(x,INT)),FRAC INT) -> FRAC UP(x,INT)
      implemented: slot (Fraction (UnivariatePolynomial x
(Integer)))(Mapping (U
nivariatePolynomial x (Integer)) (Integer))(Fraction (Integer)) from
FRAC2(INT,U
P(x,INT))

   Loading C:/Program Files/axiom/mnt/windows/algebra/FRAC2.o for
      package FractionFunctions2
   Loading C:/Program Files/axiom/mnt/windows/algebra/QFCAT2.o for
      package QuotientFieldCategoryFunctions2
   Loading C:/Program Files/axiom/mnt/windows/algebra/HEUGCD.o for
      package HeuGcd
   Loading C:/Program Files/axiom/mnt/windows/algebra/INMODGCD.o for
      package InnerModularGcd
   Loading C:/Program Files/axiom/mnt/windows/algebra/EMR.o for domain
      EuclideanModularRing
   Loading C:/Program Files/axiom/mnt/windows/algebra/MDDFACT.o for
      package ModularDistinctDegreeFactorizer
   Loading C:/Program Files/axiom/mnt/windows/algebra/MODRING.o for
      domain ModularRing

        x
   (2)  -
        2
   Type: Fraction UnivariatePolynomial(x,Integer)

> and the Interpreter probably simplified POLY POLY INT to
> POLY INT). In other words, we have ((1/x ?)::(?/x)::(x/x)=1.
> The bug therefore probably lies in the identification of
> POLY POLY INT with POLY INT where the outer ? (or x) is
> identified with x of the inner POLY.

I don't see this happening anywhere above. On the contrary this
calculation seems to me to demonstrate the extraordinary power
of the generic algorithms that are part of the Axiom library.

> Conclusion: (i) Any simplification of towers which makes
> sense in mathematics probably would not make sense in
> computer algebra (due to scope problems for one). Other
> examples could be FRAC FRAC INT to FRAC INT and EXPR EXPR
> INT to EXPR INT.

I don't understand this comment. What do you mean by
"scope problems"?

> (ii) Users should be alert to the order in which an input is
> scanned and the consequences, and break a long input into
> simpler steps.

I agree that simple steps are easier to analyze. I also
think it is a mistake to write something like:

  (x+1)::POLY INT

or

  x+1::POLY INT

when

  (x+1)$POLY INT

will do. In the first two cases the interpreter will do
some extra computation by default before it applies the
coercion operation and the result of coercion is harder
to analyze than the simple package call.

> (iii) Users should not use the same identifier for two
> different objects.

I think that this is simply not possible in Axiom.

\start
Date: Sat, 25 Feb 2006 18:59:37 -0500
From: Bill Page
To: William Sit
Subject: RE: delayed distribution of mail

On February 25, 2006 4:05 PM William Sit wrote:
> 
> Recently, there seems to be delays of over a day for 
> distribution of updates on the Wiki pages and maybe
> also emails to/from axiom-developers. Below is the mail
> header for one I sent and received back from axiom. It
> used to be much faster(within minutes) for the round-
> trip.
> 

Yes, I have also noticed this delay over the last few days. So
far as I can tell, this does not have anything to do with the
Axiom Wiki and axiom-developer.org server. Notices of changes
to web pages are sent to the axiom-developer email list in
the same way as any other email sent to the email list (the
Axiom Wiki appears as just another subscriber to this list).

>From the email headers that I looked at, it would appear that
there is/was some problem that caused on a serious backlog
on the gnu.org (Savannah) servers. This is confirmed at the
Savannah web site:

http://savannah.nongnu.orglists.gnu.org

 delays
 posted by Beuc, Sat 02/25/06 at 17:33 - 0 replies

lists.gnu.org is being redone from scratch. The Savannah
Hackers are not involved in that process. Work is focused on
the new system rather than the current one. ETA is fall of
March. We'll post additional information here if available.

-----------

( I suppose they mean the end of March, 2006? :)

If this problem doesn't go away, I suppose we could investigate
the possibility of moving the mailing lists to another server.
It would be possible for us to run a list like this on
axiom-developer.org if we really wanted to.

It is also possible to subscribe directly to web pages on the
Axiom Wiki. In that case the change notifications would be
sent directly to you by the Wiki software.

Regards,
Bill Page.





\start
Date: Sat, 25 Feb 2006 23:36:58 -0500
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: delayed distribution of mail
Cc: Bill Page

the axiom mailing list is hosted at the free software foundation
savannah server. there must be a problem there.

\start
Date: 26 Feb 2006 06:30:45 +0100
From: Gabriel Dos Reis
To: list
Subject: Curiosities with Axiom mathematical structures

  The recent discussions about Axiom/Aldor being object-oriented or
not, whether Axiom could be made to be "truly categorial" or not
reminded be of a curiosity I found in Axiom's hierarchy for
mathematical structures.

  In the impressive diagram titled "Basic Agebra Hierarchy" displayed
in the Axiom Book (I only have a copy of the edition copyrighted 1992,
NAG), AbelianSemiGroup is not "derived" from SemiGroup, and similarly
AbelianMonoid is not "derived" from Monoid.  I find that curious as it
goes counter the mathematical fact that an AbelianMonoid *is* a
Monoid, with an additional algebraic law (commutation).  


  Does anyone know the reason of those curiosities?

  (A year or so ago, in a discussion with a friend I attributed those
anomalies to object-orientation artifacts.  I would be glad to see
that disproved...)

Thanks,

-- Gaby
PS: libalgebra has similar curiosities

\start
Date: Sun, 26 Feb 2006 01:32:22 -0500
From: William Sit
To: Bill Page
Subject: Re: about Expression Integer (with Quizzes)

"Page, Bill" wrote:
> 
> William
> 
> On Friday, February 24, 2006 8:07 AM you wrote:
> >
> > Any scientific literate person, when (s)he wrote down:
> >
> >    2*x + 1/x
> >
> > would mean that there is only ONE x, the x means the same
> > thing throughout the expression.
> 
> Yes.

I'm glad you agreed. So how can you keep arguing that one x lives in one domain,
and the other x in another?

> > So
> >
> > (1) -> (2*x+1/x)::DMP([x], EXPR INT)
> >
> >           2
> >         2x  + 1
> >    (1)  -------
> >            x
> >               Type:
> > DistributedMultivariatePolynomial([x],Expression Integer)
> > (2) -> degree(%)
> >
> >    (6)  [0]
> >
> > is perfectly correctly interpreted by Axiom. The entire
> > expression is a coefficient, in EXPR INT.
> 
> It is a correct interpretation, but it is not the only
> possible interpretation. The reason it is interpreted as
> entirely with 'EXPR INT' is because you used a conversion
> '::' instead of a package call $. Axiom processes what is
> inside the parenthesis first. Since there is no package
> specification there, the interpreter assumes we are talking
> about 'EXPR INT'. Then it applies the coercion from 'EXPR INT'
> to 'DMP([x], EXPR INT)' which simply embeds the expression
> as a term of degree 0.

I kind of agree with your explanation when using a package call (though the
expression goes through FRAC POLY INT before reaching EXPR INT). But
unfortunately, package call is no guarantee and the above is incomplete
explanation (Hint: do the quizzes at bottom).

Aside: Hyperdoc reports that DMP([x], EXPR INT) is an invalid type. (Type the
domain in the search box, click Constructors, then click operations). Yet
another inconsistency in the system.
 
> Try this instead:
> 
> (1) -> (2*x+1/x)$DMP([x], EXPR INT)
> 
>              1
>    (1)  2x + -
>              x
>    Type: DistributedMultivariatePolynomial([x],Expression Integer)
> 
> (2) -> monomials(%% 1)
> 
>             1
>    (2)  [2x,-]
>             x
>    Type: List DistributedMultivariatePolynomial([x],Expression Integer)
> 
> In this case we told Axiom to use only operations from the
> domain 'DMP([x], EXPR INT)'. It sees '2*x' and selects the
> '*' with signature '?*? : (Integer,%) -> %'. The result is
> a term of degree 1. Then it looks at '1/x' and selects
> '?/? : (%,Expression Integer) -> %'. The result is a term
> of degree 0.
> 
> This also is correctly interpreted by Axiom. But these two
> expressions are not equivalent in this domain.

No, Axiom erred in performing a "coercion" from DMP([x], R) into R when
mathematically, it is clear that x does not belong to R. It should only coerce
from DMP([x],R) into POLY R or EXPR R.  You already agreed that the x should
mean the same mathematical object in the expression. Now look at this (I used UP
instead of DMP, but DMP would show almost the same except b would be in List
OVAR [x], and (7) would return 'false' (this is better, but in both the UP and
DMP cases, (6) and (7) should end in error. More of this later.)

(1) -> a:= (2*x+1/x)$UP(x, EXPR INT)

             1
   (1)  2x + -
             x
                             Type: UnivariatePolynomial(x,Expression Integer)
(2) -> b:=variables a

   (2)  ["?"]
                                             Type: List SingletonAsOrderedSet

   
(3) -> c:=coefficient(a, b, [0])


        1
   (3)  -
        x
                             Type: UnivariatePolynomial(x,Expression Integer)

(4) -> d:=retract(c)@(EXPR INT)


         1
   (4)   -
         x
                                                     Type: Expression Integer
(5) -> e:=variables d


   (5)  [x]
                                                            Type: List Symbol

So the two instances of 'x' are not treated as the same mathematical object or
even the same computer object or variable.  Indeed, in Axiom, they live in two
different domains! So Axiom did not interpret the two x's consistently.

Warning, do not let

(6) -> t:Boolean:=(b.1=e.1)
   (6)  true
                                                                Type: Boolean

deceive you into thinking the two variables are the same. The Interpreter
actually tried very hard to please you (too bad, it shouldn't, and should have
complained that there is no = function that is applicable; we are testing
equality, and the Interpreter should not perform ANY coercion in equality tests
because then equality test in the Interpreter are no longer predictable without
a deep understanding of how the Interpreter works). Just )set mess bot on before
(6) to see (its too long to reproduce here). Moreover, this may or may not
surprise you:

(7) -> s:Boolean:=(b.1=(y::Symbol))


   (7)  true
                                                                Type: Boolean

This is not a surprise at all. You see, b.1 is simply a place holder ? and it
can match ANY symbol. The type of b indicates NOTHING about x. The Interpreter
went through the same set of coercions as for (6) to say, "Ah-ha, I found a
common domain where they can be equal. I don't care what the user meant!" (BTW,
the domain is UP(y, INT)).  As mentioned, the case for DMP is better handled, in
which case the type of b, List OVAR [x], does indicate x. Would you have guessed
from what common domain is the equality test function taken?

> >
> > However, I think Axiom is wrong in allowing that, since x,
> > being an indeterminate over EXPR INT, should not be in
> > EXPR INT.
> 
> I suppose what you are saying is that the ring over which
> DMP is defined should not be 'EXPR INT' but rather
> 'SubDomain(EXPR INT, not member?(x::Symbol,variables(#1))'.

No, that is not the same. The above still accepts that the two x are the same
and this is mathematically incorrect. You can have a different x in EXPR INT,
and you can substitute DMP-x for EXPR-x, but they are different. DMP-x is
transcendental over EXPR INT whereas EXPR-x is in the field.

> This is a possible definition but it seems unnecessarily
> complicated. Further it would explicitly prevent the kind
> of coercion that Axiom was apparently carefully designed
> to do (see below).

Quite the contrary. There ARE legitimate use of these construction and they ARE
used in the Axiom library. Just to give you an example, SUP in idecomp.spad

IdealDecompositionPackage(vl,nv) : C == T -- take away nv, now doesn't
                                          -- compile if it isn't there
 where
   vl      :  List Symbol
   nv      :  NonNegativeInteger
   Z      ==>  Integer  -- substitute with PFE cat
   Q      ==>  Fraction Z
   F      ==>  Fraction P
   P      ==>  Polynomial Z
   UP     ==>  SparseUnivariatePolynomial P
   Expon  ==>  DirectProduct(nv,NNI)
   OV     ==>  OrderedVariableList(vl)
   SE     ==>  Symbol
   SUP    ==>  SparseUnivariatePolynomial(DPoly)

   DPoly1 ==>  DistributedMultivariatePolynomial(vl,Q)
   DPoly  ==>  DistributedMultivariatePolynomial(vl,F)

Axiom actually allows other ways to add new indeterminates to a domain that
already uses Symbol as the set of indeterminates, by using a direct product of
say
NNI to the existing EXPON, for example (see definition of POLYCAT and
gbintern.spad for such use). These towers are needed and as far as I can tell,
the Axiom compiler handles them perfectly. Any confusion is caused by "features"
in the Interpreter. The Interpreter is, unfortunately, a main reason why the
learning curve for Axiom is so steep.

I don't think to understand that indeterminates are transcendentals is too
complicated, or an x in one expression must mean the same mathematical object
throughout. These are the only two principles I used.

> There is no danger that Axiom will confuse the two uses of
> 'x' and to the user this result looks perfectly reasonable -
> it looks like just a different way of formatting the
> expression - but of course as "advanced users" we know the
> difference is more subtle than that.

Axiom does confuse the users by performing a substitution for one x and not the
other, thus splitting one x into two. If you goal is to reformat the expression,
then reformat it entirely within EXPR INT (that is, create a "reformat" command
that does that by walking a parse tree for the expression, or create extraction
functions similar to univariatePolynomial in UPS that extracts only monomial
terms from a sum of terms).
 
> >The coercion should simply fail, or end up in
> > FRAC DMP([x], EXPR INT).
> 
> I do not see how it could possibly end of in
> 'FRAC DMP([x], EXPR INT)' in either version of (1) above.

If x is to be the variable in DMP, then 1/x needs to be in FRAC DMP. x is a
transcendental over EXPR INT and should not and cannot be interpreted as ALSO in
EXPR INT. The design to allow Symbol as the set of variables in POLY or EXPR is
ingenious in concept and gives Axiom its power to program categorically without
hardcoding any predefined finite set of symbols. Users should not equate this to
mean no other indeterminates can be constructed over POLY INT or EXPR INT. In
fact, EXPR was constructed over as the quotient field of a polynomial ring where
indeterminates are kernels.

> > Note that even if the following is used, Axiom continues to
> > "retract" the x from 1/x to EXPR INT. This is simply wrong.
> >
> > x:DMP([x], EXPR INT):=x
> > 2*x + 1/x
> > degree(%)
> >           [1]
> >
> 
> It is not wrong. 

No, you are wrong. The Interpreter performs a mathematically unwarranted
coercion (via a substitution). If the Interpreter is allowed to reinterpret an
identifier that I explicitly declared and defined, and coerce an element into a
ring that the element should not belong to in the mathematical sense, how can I
predict what subsequent computations will be? If a user does not declare the
type, yes, the Interpreter would be given the freedom to coerce; otherwise, it
should coerce only with specific directives from the user, or when it is
mathematically correct to do so.

> I agree that it might be unexpected if
> one does not keep in mind the domains from which Axiom will
> select functions. One might (incorrectly) thought that the
> 1/x must be evaluated in 'FRAC DMP([x],EXPR INT)' 

Expecting that 1/x must be evaluated in FRAC DMP is the ONLY mathematically
reasonable expectation when x is the indeterminate in DMP and therefore NOT a
member of its coefficient domain.

> but once
> again Axiom first considers the '/' function defined in
> domain that it already knows: 'DMP([x],EXPR INT)' before it
> attempts anything more complex. 

The error is not in using '/' from DMP but in making an unwarranted and wrong
*substitution*. Indeed, the sequence to parse the expression 2*x + 1/x, as you
noted, is (skipping some obvious ones):

   2*x is in DMP
   1, don't know yet
   x, is in DMP
   / is a function to be looked up
   Ok, I can coerce 1 to be in DMP as its unit
   Ooops, I can't find a / in DMP with signature (%,%)->%
   But there is a / in DMP([x], EXPR INT) with signature (%, EXPR INT)->EXPR
INT     (because EXPR INT has FIELD)
   Ah ha, I'll coerce the denominator into EXPR INT -- wrong step!

As explained in my previous email, this coercion is a *substitution* and is
wrong because there should not be a *coercion* from DMP([x], EXPR INT) to EXPR
INT; there is only a *retractIfCan*.  I repeat: 'x' is transcendental over EXPR
INT and should not and cannot be in EXPR INT. This total disregard of what x is,
is a bug, and demonstrates inconsistency in the Interpreter. In the above setup,
(1/x)*x is not 1 so the denominator x is coerced to EXPR INT, but the other x is
not.  This can cause other problems:

\begin{axiom}
)clear all
y:=DMP([x], EXPR INT):=x
z:=1/y
w:=1/z
t:Boolean:=w=y
\end{axiom}

If you consider this is not a bug, I  don't know what is. Of course, I know how
this came about. If z had been computed in FRAC DMP([x], EXPR INT), as it
should, this problem would not be there.


  
> It discovers that it can
> evaluate 1 in 'DMP([x],EXPR INT)' and that since 'x' is a
> variable of type 'DMP([x],EXPR INT)', it knows that it can
> always coerce such polynomials into 'EXPR INT'. This allows
> it to apply the operator '/' from 'DMP([x],EXPR INT)'.

This is not the whole story as indicated above. The 'x' is a polynomial, but in
this case, it is mathematically incorrect to "coerce" it into the coefficient
domain, even if it happens to be EXPR INT. Moreover, selective substitution is
another evil here (substituting one x and not the other).


> > On the other hand, the following is correct, and should
> > be the case no matter what the coefficient domain is.
> >
> > y:DMP([y], INT):=y
> > 2*y+1/y
> >
> >            2
> >          2y  + 1
> >          -------
> >             y
> >                 Type: Fraction
> > DistributedMultivariatePolynomial([y],Integer)
> >
> > The two cases should not be handled differently.
> 
> I agree that this result is correct but I disagree that
> these two cases can be handled the same way (i.e. by
> selecting the '/' operation in 'DMP([y], INT)'. This is
> not possible because Axiom cannot coerce polynomials of
> type 'DMP([y], INT)' into 'INT'.

Neither should Axiom coerce polynomials of type DMP([y], R) into R for ANY R.

Bill, Axiom is to model mathematics, *categorically*.
It is allowed that a different algorithm is used by tapping into the properties
of the coefficient domain, IF THEY PRODUCE THE SAME RESULT (consistency). The
alternative algorithm should not be allowed when it produces a different answer.
Mathematically, if y is an element of an integral domain, then 1/y is its
reciprocal in the quotient field and 1/(1/y) has to be y itself. The Axiom
interpreter (not Axiom) fails in these examples to uphold a mathematical result.
That is WRONG (even though it originates from user input error: expecting 1/x to
be in DMP([x], EXPR INT) where x is not in EXPR INT).



> > If a user wants to push the result down to the coefficient
> > domain, it should be done with a substitution map,
> > explicitly, and the user should not use x in EXPR INT.
> >
> 
> This sort of coercion is only possible when the coefficient
> domain has 'PDRING Symbol' or at least 'PDRING OVAR vl'
> where 'vl' is polynomial variable list. Apparently Axiom
> attempts to use it during the function selection process.

The Interpreter is designed to coerce polynomials over a ground ring R into EXPR
over the SAME ground ring, and it is an oversight that it actually coerce
polynomials over a ring R into R itself when R is EXPR INT. Had the Interpreter
coerced 1/x into EXPR EXPR INT, in the example where x is in DMP([x], EXPR INT),
that would be correct. But the Interpreter, unfortunately, does not allow EXPR
EXPR INT.

I failed to see why PDRING has anything to do with it. All you are saying is
that if the coefficient domain does NOT have PDRING Symbol, etc, then the
Interpreter will not produce the incorrect coercion, but it does -- see Quizzes.
It should not matter whether the coefficient domain has millions of other
properties or not. The Interpreter should not perform a *partial substitution*
behind my back and call it *coercion*, and worse, by doing so it produces
inconsistent results on a categorical level and is mathematically wrong.

By the way, I don't think it is easy to fix this bug because it involves how
deeply the Interpreter should try to coerce. My suggestion to users is: ignore
these examples, don't use towers involving polynomial rings, and if you really
need these tower constructions, don't do this in the Interpreter since you won't
know what the consequence will be without wasting a lot of time (and we might
still get it wrong).

Here are some quizzes if you have read so far (it does not matter if you agree
with me or not). 

Instructions: What is the output for each of the following?
Do the problems only one at a time. You should write down your answer, its type,
and with explanations and any expected error messages. Then check it (using )set
mess bot off), revise your explanation if necessary, or explain Axiom's output.
Finally, use )set mess bot on to see exactly what the Interpreter did. Then and
only then, advance to the next problem.

Just in case: the function 'variables' returns a list of the variables occurring
in the argument.

)set mess bot off  -- no cheating
(1) variables (2*x+1/x)$DMP([x], EXPR INT)

(Got you, right? It got me too. To understand this, repeat with )set mess bot
on. You must understand what the Interpreter was doing before starting quiz (2))

)set mess bot off
(2) variables (2*y+1/y)$DMP([y], INT)

(Got me again! Repeat with )set mess bot on, read carefully, and compare with
that from (1)). 

)set mess bot off
(3) a:=(2*x + 1/x)$DMP([x], EXPR INT); 
    variables a 

)set mess bot off
(4) b:=(2*y+1/y)$DMP([y], INT);
    variables b

)set mess bot off
(5) x:DMP([x], EXPR INT); 
    variables (2*x+1/x)

)set mess bot off
(6) y:DMP([y], INT);
    variables (2*y+1/y)

For your convenience, the quizzes have been set up at SandBox Polynomials.
Solutions are at SandBoxPolynomialQuiz and you can enter your insights at
SandBoxPolynomialQuizExplained.

Have fun. If you got all 6 perfectly, you are a "guru", congratulations, and let
us know (so we know whom to ask questions next time :-) (Actually, I do have a
few related to these quizzes, but rather than scratching my head again, I'll
wait for the "guru"s to tell me.)

William



\start
Date: Sun, 26 Feb 2006 04:09:27 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [DistributedMultivariatePolynomial] These examples are wrong and due to user and Interpreter errors.

The fact that one can "explain" what the Axiom's Interpreter does to
an input does not make its operation legitimate.  Even though 'EXPR
INT' (and similarly 'POLY INT') is designed to include 'Symbol' (that
means *all* symbols corresponding to all legal identifiers, including
those decorated with subscripts or superscripts), it is never the
intention that no other symbols can be used *outside* of 'EXPR INT' or
'POLY INT'.  That is why it is legal to construct 'DMP([x,y], EXPR
INT)' in the above examples. However, in mathematics, a polynomial
ring $P$ over a coefficient domain $R$ in the variables $[x,y]$, say,
means that $x,y$ are indeterminates and therefore are algebraically
independent over $R$. In particular, $x,y$ **cannot** be elements of
$R$.

The above examples, such as $x+x$, where the two $x$'s have to be
differentiated as belonging to two different domains is nonsense. Any
scientific literate user who writes $x+x$ intend the expression to
simplify to $2x$ because the $x$ **MUST** represent the *same*
mathematical quantity. Axiom's Interpreter, in producing $x+x$ in the
examples, violates this universally accepted convention and the
definition of indeterminates. These violations are **not acceptable**.

In short, the error occurs because the Interpreter, unaware of the
definition of indeterminates, "coerces" $x$ from $P$ to $R$, but there
is *no* 'coerce' function with signature 'P -> R' even when 'R' is
'EXPR INT' or 'POLY INT'. The situation for 'EXPR INT' is harder to
investigate since 'EXPR INT' is implemented as the quotient field of a
polynomial ring. So rational functions are easily coerced into 'EXPR
INT' and the Interpreter will not spit out information on how it does
this even with ')set mess bot on'. For the 'POLY INT' case, a careful
examination (see http://wiki.axiom-developer.org/270IntegratingUTS)
shows that it actually invokes a *substitution* of $x$ in $P$ (I'll
label this $x_P$) by replacing it with another $x$ in $R$ (I'll label
this $x_R$). Substitutions are perfectly legal operations, but the
Interpreter should not substitute for one $x_P$ and not another. This
happened in the computation of 'b' above. The division 'a/x' is taken
with signature '/:(P,R)!  ->P' because 'R' is a field, but in doing
so, the Interpreter selectively *substitute* (under the mask of
*coerce*) the denominator $x_P$ (actually, here, it is probably an 'x'
in 'POLY INT' coerced into $x_R$ because 'x' has not been defined
except as a 'Symbol', but I will assume that 'x' has been defined as
in 'x:P:=x' so that the denominator in 'b=a/x' is undoubtedly $x_P$)
but not the numerator 'a'. So the two $x$'s in 'a/x' are treated as
different (first violation) and then one $x_P$' is allowed to be
pushed down into the coefficient domain 'R' even though it is
transcendental over 'R' (second violation).

Unfortunately, these bugs are difficult to correct. The Interpreter
was designed to faciliate conversions among any two polynomial rings
and their quotient fields. Had the above 'coerce' been from
'DMP([x,y], R)' to 'FRAC DMP([x,y], R)' (the correct coercion) or even
'EXPR R', things would have been ok. But the designers wrongly
disallowed construction of 'EXPR EXPR INT' and similar towers. The
correct fix should therefore be coercion to 'FRAC DMP([x,y], R' no
matter what 'R' is. This is consistent with mathematics, since if $a
\in P$ when $P$ is an integral domain, then $1/a$ should be in the
quotient field of $P$. The examples below illustrate these incorrect
and correct approaches.

\begin{axiom}
S:=FRAC POLY INT
Q:=DMP([x], S)
a:Q:=x
)set mess bot on
b:Q:=a/a
\end{axiom}


The last output from the ')set mess bot on' output::

 [1]  signature:   ((DMP([x],POLY INT) -> POLY INT),FRAC DMP([x],POLY INT)) -> FRAC POLY INT
      implemented: slot (Fraction (Polynomial (Integer)))(Mapping (Polynomial (Integer))      
      (DistributedMultivariatePolynomial (x) (Polynomial (Integer))))
      (Fraction (DistributedMultivariatePolynomial (x) (Polynomial (Integer)))) 
      from FRAC2(DMP([x],POLY INT),POLY INT)

shows clearly (this is a much simplified version of what actually is
done, which involves 4 "coercions") that the coercion from 'DMP([x],
FRAC POLY INT)' to "FRAC POLY INT' for the denominator 'a' is really a
substitution, implemented using the 'map' function from 'FRAC2'
package, taking $1/x_Q$ to $1/x_S$ via the substitution $x_Q$ to
$x_S$.  If we replace 'S' by 'POLY INT', the coercion would be
simpler, but then 'S' is not a field.

\begin{axiom}
)clear all
S:=POLY INT
Q:=DMP([x], S)
a:Q:=x
)set mess bot on
b:Q:=a/a
\end{axiom}

Surprise! The difference in the value of 'b' just because the
coefficient ring was changed is not acceptable, but at least in this
case, the answer and indeed the coercions are correct. Had the other
cases used the same coercion into the quotient field of 'P' (or 'Q'),
they would be correct too. Now have fun with the quizzes in
SandBoxPolynomials.

\start
Date: Sun, 26 Feb 2006 04:53:57 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [#270 integrating UTS] typos

(c) In the second line, Axiom fails (correctly) because the integral, which is 'log(x)', is not given by a Laurent series about 'x=0'. A better example is:

\start
Date: Sat, 25 Feb 2006 22:22:23 +0100
From: Ralf Hemmecke
To: axiom-dev <list>
Subject: Bug in Tuple

Can someone explain that?

Ralf

(6) -> Tuple(Integer) has coerce: Tuple(Integer)->PrimitiveArrayInteger

    (6)  false
                                                                 Type: 
Boolean
(7) -> )sh Tuple(Integer)
  Tuple Integer is a domain constructor.
  Abbreviation for Tuple is TUPLE
  This constructor is not exposed in this frame.
  Issue )edit 
/home/hemmecke/software/Axiom/mnt/linux/../../src/algebra/TUPLE.spad to 
see algebra source code for TUPLE

------------------------------- Operations --------------------------------

  ?=? : (%,%) -> Boolean                coerce : % -> OutputForm
  hash : % -> SingleInteger             latex : % -> String
  length : % -> NonNegativeInteger      ?~=? : (%,%) -> Boolean
  coerce : % -> PrimitiveArray Integer
  coerce : PrimitiveArray Integer -> %
  select : (%,NonNegativeInteger) -> Integer




\start
Date: Sat, 25 Feb 2006 22:23:08 +0100
From: Ralf Hemmecke
To: Francois Maltey
Subject: Re: [Axiom-math] Very simple calculus on matrix and vector.
Cc: axiom-dev <list>, axiom-math@nongnu.org

Hello Francois

> But can I concat 3 or 4 or more vectors with only ONE command ?
> 
> I don't know if I can define in axiom a function 
> with 1 or 2 or 3 or 4 ... arguments.
> Sequences of maple or mupad allow this.
> With axiom must I define a function with a list of arguments ?

Well, I don't know whether I should call this a trick or not, but you
could achieve this easily in Aldor. There is something similar in Aldor.

In Aldor and Axiom you can write.

(4) -> (a, b) := (3, 5)

    (4)  5
         Type: PositiveInteger

Interestingly the type is shown as PositiveInteger.

In Aldor you would get

aldor -gloop
#include "aldor"
#include "aldorinterp"
import from Integer
(a, b) := (3, 5)
   () @ AldorInteger, AldorInteger

which (interestingly) omits the parens around the type
   AldorInteger, AldorInteger

(Note that in Aldor we have Integer==>AldorInteger.)

What you have seen is a "parallel assignment". And it also works in Axiom.

(5) -> a

    (5)  3
         Type: PositiveInteger
(6) -> b

    (6)  5

It is interesting to analyse the type. It is something of the form
(X, X). That looks like a tuple. And in fact "Tuple" would be one
solution to your problem. Of course you can write a function that takes
a List as input as you suggested above.

However, if Axiom/Aldor sees an expression of the form

   f x

it tries to find "f" and "x" with appropriate types. Now if x is of the
form (r,s,t) or (u,v) where all of the r,s,t,u,v are of the same type X.
Then the type for f must be "(X, X, X) -> Y" or "(X, X) -> Y".
But that is not all. What about "Tuple X -> Y"?
(r,s,t) and (u,v) are perfect elements of "Tuple X".

Basically, that says, instead of writing a function that takes arbitrary
elements, we are going to write a function that takes just one element.
However, the elements are (mathematically) elements of

   \bigcup_{n\in N}X^n ((the union of any power of X))

Here is an example in Aldor... (compile it on the command line, no Axiom
is needed)
---- mysumaldor.as -------
-- aldor -grun -laldor mysumaldor.as
--empty sum  = 0
--sum(2)     = 2
--sum(2,3)   = 5
--sum(2,3,5) = 10
#include "aldor"

macro {
   Z == Integer;
   P == PrimitiveArray Z;
}
MySum: with {
   mysum: Tuple Z -> Z;
} == add {
   mysum(t: Tuple Z): Z == {
     import from MachineInteger;
     local n: Z := 0;
     for i in 1..(length t) repeat n := n + element(t, i);
     n;
   }
}

main(): () == {
   import from MySum, Z, TextWriter, String, Character;
   stdout << "empty sum  = " << mysum()      << newline;
   stdout << "sum(2)     = " << mysum(2)     << newline;
   stdout << "sum(2,3)   = " << mysum(2,3)   << newline;
   stdout << "sum(2,3,5) = " << mysum(2,3,5) << newline;
}

main();
------ end mysumaldor.as


For Axiom the domain constructor "Tuple" has different exports. :-(
And there is a bug somewhere.

------ mysumaxiom.as
#include "axiom"

macro {
   Z == Integer;
   P == PrimitiveArray Z;
   T == Tuple Z;
}
MySum: with {
   mysum: T -> Z;
} == add {
   mysum(t: T): Z == {
     import from Z;
     local n: Z := 0;
-- cannot use "select" because it is an Aldor keyword.
--  for i in 1..length t repeat n := n + select(t, n);
--  p: P := (coerce$T)(t)@P; -- strange that `t::P' does not work

-- Thirty trick due to a bug of Axiom/Aldor not finding "coerce".
-- Take representation of Tuple from src/algebra/array1.spad
     R ==> Record(len: NonNegativeInteger, elts: P);
     import from R;
     p: P := (t pretend R).elts;
     for i in 1..(length t)::Integer repeat n := n + p.i;
     n;
   }
}
----- end mysumaxiom.as

Well, it does not quite work in Axiom, but that seems only because I am
missing some "runtime.o". That is strange, because I have a runtime.lsp
in that directory and that should be enough for Axiom, shouldn't it?

Can someone explain the error message for mysumaxiom.as?

--(2) -> )co mysumaxiom.as
--(2) -> mysum()
--
--   >> System error:
--   Cannot open the file
--   /home/hemmecke/software/Axiom/mnt/linux/aldor/lib/runtime.o.
--
--(2) -> mysum(2)
--
--   >> System error:
--   Cannot open the file
--   /home/hemmecke/software/Axiom/mnt/linux/aldor/lib/runtime.o.

It is certainly easier if you write a function that works on List.
Anyway, if the compiler sees a "mysum(3,4,5)" in your code it will
internally create an array [3,4,5] and then hide this array by claiming
it to be a Tuple. But it means that the compiler has to use some extra
memory in order to store the tuple/array.

I hope, that helps. I'm sure you can translate the above code into
something that concatenates vectors.

\start
Date: Sun, 26 Feb 2006 07:39:19 -0600
From: MathAction (wyscc)
To: MathAction
Subject: [FreeAldor] 

Axiom basically stayed stagnant for many years and it took a
tremendous effort (due to Tim Daly, Bill Page, Camm Maquire and
others) to bring it back to life. If Aldor does not become free, it
may suffer the same fate. Both Axiom and Aldor have their own
strengths and weaknesses. Combined, they can become a most powerful
system. There are so few experts in Aldor and Axiom. It is high time
to involve a younger generation before it is too late.

\start
Date: Sun, 26 Feb 2006 09:10:59 -0500
From: William Sit
To: Gabriel Dos Reis
Subject: Re: Curiosities with Axiom mathematical structures

Gabriel Dos Reis wrote:
>   In the impressive diagram titled "Basic Agebra Hierarchy" displayed
> in the Axiom Book (I only have a copy of the edition copyrighted 1992,
> NAG), AbelianSemiGroup is not "derived" from SemiGroup, and similarly
> AbelianMonoid is not "derived" from Monoid.  I find that curious as it
> goes counter the mathematical fact that an AbelianMonoid *is* a
> Monoid, with an additional algebraic law (commutation).
> 
>   Does anyone know the reason of those curiosities?

One probable reason may be the convention in mathematics to use +
instead of * when a semigroup, monoid, or group is abelian. Another is
the independence allows for the category of rings without having to
overload the * operation for both the underlying abelian group and the
multiplicative monoid, which would have been very confusing! A third
one is because addition is an ubiquitous operation in many algebraic
objects (vector space, modules, rings, algebras, etc.) with richer
structures.

The second is the most compelling. It can be generalized to a
principle for setting up new basic categories: every time a set is
equipped with a new (usually binary) operation with some axioms to
satisfy, a new category that encapsulates the operation with a new
notation is necessary in order to allow for simultaneous operations on
the same set, providing a rich algebraic structure. An example would
be Lie algebras which have at least an addition, a multiplication, and
the Lie bracket. Square matrices of a fixed size form a Lie algebra.

William

\start
Date: Sun, 26 Feb 2006 17:35:52 +0100
From: Ralf Hemmecke
To: William Sit
Subject: precedence.as

Hi William,

> )set mess bot off  -- no cheating
> (1) variables (2*x+1/x)$DMP([x], EXPR INT)

> )set mess bot off
> (3) a:=(2*x + 1/x)$DMP([x], EXPR INT); 
>     variables a 

That are nice ones. One has to understand that for (1)
foo(arg)$DOM should be considered as syntactic sugar for
(foo$DOM)(arg). A space between foo and (arg) does not help to get a 
different binding. It would even be disastrous if "foo(arg)" would be 
different from "foo (arg)". Maybe that is the reason why function 
application has one of the highest precedences in Aldor/Axiom.

Ralf

PS: Would you have guessed that the output of the following program is... ?
aldor -grun -laldor precedence.as
(foo bar id)(1)     = 6
(foo(bar)(id))(1)   = 35
(foo (bar) (id))(1) = 35
(foo (bar) id)(1)   = 35
(foo bar (id))(1)   = 6

---precedence.as
#include "aldor"
#include "aldorio"

Z ==> Integer;
Dom: with {
	id: Z -> Z;

	bar: (Z -> Z) -> (Z -> Z);
	foo: (Z -> Z) -> (Z -> Z);

	bar: Z -> Z;
	foo: (Z -> Z) -> ((Z -> Z) -> (Z -> Z));

} == add {
	id(z: Z): Z == z;

	bar(f: Z -> Z)(z: Z): Z == 2*f(z);
	foo(f: Z -> Z)(z: Z): Z == 3*f(z);

	bar(z: Z): Z == 5*z;
	foo(f: Z -> Z)(g: Z -> Z)(z: Z): Z == 7*f(g(z));
}

main(): () == {
	import from Z, Dom;
	f: Z -> Z := foo bar id;
	stdout << "(foo bar id)(1)     = " << f(1) << newline;
	g: Z -> Z := foo(bar)(id);
	stdout << "(foo(bar)(id))(1)   = " << g(1) << newline;
	h: Z -> Z := foo (bar) (id);
	stdout << "(foo (bar) (id))(1) = " << h(1) << newline;
	i: Z -> Z := foo (bar) id;
	stdout << "(foo (bar) id)(1)   = " << i(1) << newline;
	j: Z -> Z := foo bar (id);
	stdout << "(foo bar (id))(1)   = " << j(1) << newline;
}

main();

\start
Date: 26 Feb 2006 17:42:40 +0100
From: Gabriel Dos Reis
To: William Sit
Subject: Re: Curiosities with Axiom mathematical structures

Hello Willian,

thanks for the quick reply.

William Sit writes:

| Gabriel Dos Reis wrote:
| >   In the impressive diagram titled "Basic Agebra Hierarchy" displayed
| > in the Axiom Book (I only have a copy of the edition copyrighted 1992,
| > NAG), AbelianSemiGroup is not "derived" from SemiGroup, and similarly
| > AbelianMonoid is not "derived" from Monoid.  I find that curious as it
| > goes counter the mathematical fact that an AbelianMonoid *is* a
| > Monoid, with an additional algebraic law (commutation).
| > 
| >   Does anyone know the reason of those curiosities?
| 
| One probable reason may be the convention in mathematics to use +
| instead of * when a semigroup, monoid, or group is abelian.

I find that argument very unconvincing for several reasons:

   1.  "+" or "*" are *syntax*, not algebraic properties.  Whether a
       monoid is Abelian or not does stop it from being a monoid.  The
       mathematical definition of an Abelian monoid is that it is a
       monoid, whose operation *additionally* is commutative.
    
   2.  The set of natural numbers, NN, has *many* Abelian structures on it,
       for examples:
          a. (NN, +, 0) -- the usual addition
          b. (NN, *, 1) -- the usual multiplication, commutative!
          c. (NN, max, 0) -- "max" is the usual maximum function

        Such a counterexample can be multiplied.
  
>From mathematical point of view, a structure is a *tuple* where every
slot has some property.  I find Axiom's realization a bit disturbing,
if not handicapping for teaching students "hands on" classes on Algebra.

An algorithm working on Monoid should work with AbelianMonoid

| Another is the independence allows for the category of rings without
| having to overload the * operation for both the underlying abelian
| group and the multiplicative monoid, which would have been very
| confusing! 

I agree that independent concepts should be developed independently,
and combining them should be possible.  However, that is hardly a
reason for not deriving an AbelianMonoid from a Monoid.  Furthermore,
the "*" for rings is *syntax*, not something important.  It is like
saying that if my ring is called G, instead of R, it would not be a
ring!  

The very coexistence of several structures within a richer structure
should indicate that the "object oriented" approach -- where a given
name is singled out and hoped to be overridden in derived structures
to be a particular thing -- will fail to be adequate tool for modeling
mathematical structures.  This is far from being a theoretical issue.

| A third one is because addition is an ubiquitous 
| operation in many algebraic objects (vector space, modules, rings, algebras,
| etc.) with richer structures.

probably but not every Abelian monoid has "+" has its monoid operation
-- see examples above.  The defect here as I see it is that a
particular name (pure syntax) has been singled out to characterize an
Algebraic structure (tuple).

| The second is the most compelling. 

well, in fact no. :-(

| It can be generalized to a principle for
| setting up new basic categories: every time a set is equipped with a new
| (usually binary) operation with some axioms to satisfy, a new category that
| encapsulates the operation with a new notation is necessary in order to allow
| for simultaneous operations on the same set, providing a rich algebraic
| structure.

what you say here is very different from what the "second reason" says.
Furthermore, what you say here is that the name chosen in the
implementation of a algebraic structure should be *immaterial*, just
like when defining a function, the name of the parameter should be
immaterial.   The ability to combine different algebraic structures
with same underlying set dictate that the names used to model the
operations (necessarily variable) in individual algebraic
structures are immaterial.

| An example would be Lie algebras which have at least an addition, a
| multiplication, and the Lie bracket. Square matrices of a fixed size
| form a Lie algebra.

or, simply, the set of natural numbers with as many monoidal
structures as there are communitatuve functions f : NN x NN -> NN and
neutral elements e : NN :-)

\start
Date: Sun, 26 Feb 2006 17:45:22 +0100
From: Gregory Vanuxem
To: axiom-developer <list>
Subject: Compiler coercion and DoubleFloat

Is it possible to avoid this compiler coercion ?

The code is:
        R ==> DoubleFloat
        two4: R := 24.0
        fourty: R := 40.0::R
        exp40: R := 235385266837019985.41::R


The compiler output is:
(SEQ | << |
     (LET (|:| |two4| (|DoubleFloat|))
       ((|elt| (|Float|) |float|) 24 0 10))
     | >> |
     (LET (|:| |fourty| (|DoubleFloat|))
       (|::| ((|elt| (|Float|) |float|) 40 0 10) (|DoubleFloat|)))
     (LET (|:| |exp40| (|DoubleFloat|))
       (|::| ((|elt| (|Float|) |float|) 23538526683701998541 -2 10)
             (|DoubleFloat|)))


It seems that the compiler coerces all floating
point numbers to the Float domain, here (for example):

((|elt| (|Float|) |float|) 24 0 10).

It's not possible to use  two4: R := 24.0, i have to coerce
this Float to DoubleFloat (two4: R := 24.0::R)

But i want to obtain something like 
((|elt| (|DoubleFloat|) |doublefloat|) 24.0)
Is it possible ?

Another question, where can i find (in src/interp) the code
responsible of this coercion ? Tim any idea ?

\start
Date: Sun, 26 Feb 2006 12:19:06 -0600
From: MathAction (anonymous)
To: MathAction
Subject: [#271 )show Expression Boolean gives a list]

As I was looking for boolean simplification, I type )sh Expression Boolean.
I get the list of the real expressions. So I type 

\begin{axiom}
sin (A::Expression Boolean) or true.
\end{axiom}

Axiom disapproves

>> System error:
Caught fatal error [memory may be damaged]...

And the axiom process died the command-line after.

\start
Date: Sun, 26 Feb 2006 19:53:54 +0600 (NOVT)
From: Andrey G. Grozin
To: Gabriel Dos Reis
Subject: Re: Curiosities with Axiom mathematical structures

On Sun, 26 Feb 2006, Gabriel Dos Reis wrote:
>  In the impressive diagram titled "Basic Agebra Hierarchy" displayed
> in the Axiom Book (I only have a copy of the edition copyrighted 1992,
> NAG), AbelianSemiGroup is not "derived" from SemiGroup, and similarly
> AbelianMonoid is not "derived" from Monoid.  I find that curious as it
> goes counter the mathematical fact that an AbelianMonoid *is* a
> Monoid, with an additional algebraic law (commutation).
As far as I know, the reason is simple and purely notational. SemiGroup 
has the binary operation *, and AbelianSemiGroup has +. Therefore, it 
cannot be derived from SemiGroup. But some other categories can be derived 
from both of them, inheriting * (maybe non-commutative) from SemiGroup and 
+ (always commutative) from AbelianSemiGroup.

My copy of the Axiom book is in my office, and I am writing from home, so, 
details may be wrong.

\start
Date: Sun, 26 Feb 2006 11:04:47 -0800 (PST)
From: Cliff Yapp
To: Tim Daly, Gabriel Dos Reis
Subject: re: ASDF and ./configure
Cc: list, David Mentre

If it's anything like the GCL+localbfd issues I ran into, I think it
went something like this:

1)  GCL relies on specific binutils versions, since binary incompatible
changes are a requent event in the binutils world.
2)  A number of linux distributions (the problem is especially
noticable on something like Gentoo) will incorporate changes in bfd
faster than GCL keeps up with them.
3)  The safe answer on such systems is to build a copy of bfd that GCL
knows how to deal with, specifically for GCL.  This results in more
overhead for GCL installs but I think disk space and CPU time are
cheaper than programmer time, in this particular case.

This email deals with a similar GCL problem (I don't think I was trying
to build Axiom at that time):
http://lists.gnu.org/archive/html/gcl-devel/2002-10/msg00147.html

There is also a discussion of the binutils problem on the debian lists:
http://lists.gnu.org/archive/html/gcl-devel/2004-08/msg00033.html

Cheers,
CY

--- Tim Daly wrote:

> actually, no. i don't remember (thus, proving that documentation is
> vital) why the locbfd was chosen. there was an issue that arose about
> building GCL on FC3 which went on between Camm and I but I no longer
> have the emails. it may be somewhere in the mailing list archives.
> at this point it falls to superstition ("because it works").

\start
Date: Sun, 26 Feb 2006 11:18:42 -0800 (PST)
From: Cliff Yapp
To: list
Subject: Re:  A axiom package, itovsn3

Neat!  Does anybody know the license status for this project?  Could we
include the paper and code as a literate document?

--- unknown <MathAction> wrote:

> Changes http://wiki.axiom-developer.org/AxiomCommunity/diff
> --
> Thanks for professor W.Kendall, Warwick Univ,U.K. kindly allow us to
> include his effort, itovsn3 (in Axiom) in our LiveTeXmacs. itovsn3
> supports many functions for computing stochastic integrals, solving
> stochastic differential equations and others. Also itovsn3 gives
> several examples. With the such powerful tool for studying Stochastic
> process, I also make a lecture file about stochastic process in
> TeXmacs format ( more than 100 pages but not completed yet).  In the
> future, I will add a part how to use Axiom+itovsn3 to solve SDE.
> Welcome all interesting readers to use. 
> 

\start
Date: 26 Feb 2006 20:41:38 +0100
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: re: ASDF and ./configure
Cc: list, David Mentre

That helps me a lot.  Thanks!

\start
Date: Sun, 26 Feb 2006 15:53:31 -0500
From: Bill Page
To: William Sit
Subject: RE: about Expression Integer (with Quizzes)

On February 26, 2006 1:32 AM William Sit wrote:
> > 
> > William
> > 
> > On Friday, February 24, 2006 8:07 AM you wrote:
> > >
> > > Any scientific literate person, when (s)he wrote down:
> > >
> > >    2*x + 1/x
> > >
> > > would mean that there is only ONE x, the x means the same
> > > thing throughout the expression.
> > 
> > Yes.
> 
> I'm glad you agreed. So how can you keep arguing that one x 
> lives in one domain, and the other x in another?

I did not make that claim. It is incorrect to think in terms
of 'x' belonging to one domain or another. It is the same 'x'
used in different ways. 'x' lives in only one domain - Symbol.

There is a lot more I want to reply to below but let me skip
that for now (I'll get back to it later) and get to the fun
part. :)

> ... 
> Here are some quizzes if you have read so far (it does not 
> matter if you agree with me or not). 
> 
> Instructions: What is the output for each of the following?
> Do the problems only one at a time. You should write down 
> your answer, its type, and with explanations and any expected
> error messages. Then check it (using )set mess bot off),
> revise your explanation if necessary, or explain Axiom's
> output. Finally, use )set mess bot on to see exactly what
> the Interpreter did. Then and only then, advance to the next
> problem.
> 
> Just in case: the function 'variables' returns a list of the 
> variables occurring in the argument.

It is slightly more accurate to say that it returns a list
of Symbols that are used as variables. But I suppose that is
a quibble.

> 
> )set mess bot off  -- no cheating
> (1) variables (2*x+1/x)$DMP([x], EXPR INT)
> 
> (Got you, right? It got me too.

Yes. It took me a minute to realize that the interpreter parses
this as:

   (variables$DMP([x], EXPR INT))(2*x+1/x)

> To understand this, repeat with ')set mess bot on'. You must
> understand what the Interpreter was doing before starting
> quiz (2))

Ok, that was pretty easy. :)

> 
> )set mess bot off
> (2) variables (2*y+1/y)$DMP([y], INT)
> 
> (Got me again! Repeat with )set mess bot on, read carefully, 
> and compare with that from (1)). 

This one is obvious. The only operation '/' in this domain is
'?/? : (%,Integer) -> %' and 'y' is not an 'Integer'.

> 
> )set mess bot off
> (3) a:=(2*x + 1/x)$DMP([x], EXPR INT); 
>     variables a

Obvious result: [x]
What is hard about that?

> 
> )set mess bot off
> (4) b:=(2*y+1/y)$DMP([y], INT);
>     variables b
>

Same error as in (2). But 'b' is interpreted as a Variable
which can be coerced to EXPR INT so result is [b]

> )set mess bot off
> (5) x:DMP([x], EXPR INT); 
>     variables (2*x+1/x)
>

Obvious. Result: [x]. Essentially the same as (3)
 
> )set mess bot off
> (6) y:DMP([y], INT);
>     variables (2*y+1/y)
>

I wrote: "Error same as in (2)". So I have to admit I got this
one wrong but I should not have. The explanation is simple. This
is not a package call as it was in (2), so the interpreter is
free to apply the usual coercion to 'FRAC DMP([y], INT)' in order
to obtain a selection for '/'.
 
> For your convenience, the quizzes have been set up at SandBox 
> Polynomials. Solutions are at SandBoxPolynomialQuiz and you
> can enter your insights at SandBoxPolynomialQuizExplained.
>

Ok, I'll do that.
 
> Have fun.

Thanks, I did.

> If you got all 6 perfectly, you are a "guru", congratulations,
> and let us know (so we know whom to ask questions next time :-)

I missed that last one on purpose. ;)

> (Actually, I do have a few related to these quizzes, but rather
> than scratching my head again, I'll wait for the "guru"s to tell
> me.)

\start
Date: Sun, 26 Feb 2006 17:06:15 -0500
From: Tim Daly
To: list
Subject: Axiom Tutorial translation

If you speak a language other than english and would like to 
publish a book I'd encourage you to spend the time to translate
the Axiom Tutorial book into your native language. You have my
permission to replace my name on the front cover with your own.

If, in the process, you find things about the tutorial that need
to be rewritten I'd encourage you to feed the changes back to the
original work.

Currently I publish the tutorial on lulu.com and all of the proceeds
from the sale of the book will be given to the axiom foundation. it
is up to you what you decide to do with any profit you might make.

\start
Date: Sun, 26 Feb 2006 20:50:21 -0500
From: Bill Page
To: Gregory Vanuxem
Subject: RE: Compiler coercion and DoubleFloat

On February 26, 2006 11:45 AM Vanuxem Gr=E9gory wrote:
>
> Is it possible to avoid this compiler coercion ?
>
> The code is:
>         R ==> DoubleFloat
>         two4: R := 24.0
>         fourty: R := 40.0::R
>         exp40: R := 235385266837019985.41::R
>

It is not necessary to write this as a coercion. Try

  float(23538526683701998541,-2,10)$DoubleFloat

'float' is the function defined in the domain DoubleFloat
that is analogous to the one in Float.

\start
Date: Sun, 26 Feb 2006 21:24:10 -0500
From: Bill Page
To: Gabriel Dos Reis
Subject: RE: Curiosities with Axiom mathematical structures

On February 26, 2006 11:43 AM Gabriel Dos Reis wrote:
> | Gabriel Dos Reis wrote:
> | >   In the impressive diagram titled "Basic Agebra 
> | > Hierarchy" displayed in the Axiom Book (I only have
> | > a copy of the edition copyrighted 1992, NAG),
> | > AbelianSemiGroup is not "derived" from SemiGroup, 
> | > and similarly AbelianMonoid is not "derived" from
> | > Monoid.  I find that curious as it goes counter the
> | > mathematical fact that an AbelianMonoid *is* a
> | > Monoid, with an additional algebraic law (commutation).
> | > 
> | >   Does anyone know the reason of those curiosities?
> | 
> 
> William Sit writes:
> | One probable reason may be the convention in mathematics to
> | use + instead of * when a semigroup, monoid, or group is
> | abelian.
> 
> I find that argument very unconvincing for several reasons:
> 
>    1.  "+" or "*" are *syntax*, not algebraic properties.
>        Whether a monoid is Abelian or not does stop it from
>        being a monoid.  The mathematical definition of an
>        Abelian monoid is that it is a monoid, whose operation
>        *additionally* is commutative.

I don't think there is any essential reason why SemiGroup and
Monoid could not be implemented in the way you suggest. For
example:

)abbrev category SGROUP SemiGroup
SemiGroup(m:Symbol): Category == SetCategory with
      m: (%,%) -> %    ++ returns the product of x and y.
      associative(m)

)abbrev category ABELSQ AbelianSemiGroup
AbelianSemiGroup(m:Symbol): Category == SemiGroup(m) with
      abelian(m)

------

The symbol for product can be passed as a parameter.

)show SemiGroup(*)

I think the reasons are only historical. The changes to the
Axiom library to implement this would be quite extensive.

One thing to remember about Axiom is that it does not actually
implement "axioms" in a constructive manner. The properties
'associative' and 'abelian' are simply declarative. It is up
to the SPAD programmer to include appropriate code such as

  if D has associate("*"::Symbol) then ...

\start
Date: 27 Feb 2006 05:08:42 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Curiosities with Axiom mathematical structures

Bill Page writes:

[...]

| >    1.  "+" or "*" are *syntax*, not algebraic properties.
| >        Whether a monoid is Abelian or not does stop it from
| >        being a monoid.  The mathematical definition of an
| >        Abelian monoid is that it is a monoid, whose operation
| >        *additionally* is commutative.
| 
| I don't think there is any essential reason why SemiGroup and
| Monoid could not be implemented in the way you suggest. For
| example:
| 
| )abbrev category SGROUP SemiGroup
| SemiGroup(m:Symbol): Category == SetCategory with
|       m: (%,%) -> %    ++ returns the product of x and y.
|       associative(m)
| 
| )abbrev category ABELSQ AbelianSemiGroup
| AbelianSemiGroup(m:Symbol): Category == SemiGroup(m) with
|       abelian(m)
| 
| ------
| 
| The symbol for product can be passed as a parameter.

Indeed.
The reason I asked is that that design was carried over in the more
"modern" version of libalgebra.

| )show SemiGroup(*)
| 
| I think the reasons are only historical. The changes to the
| Axiom library to implement this would be quite extensive.

I can understand the extent of the change, but I believe that to some
extent it is essential.

| One thing to remember about Axiom is that it does not actually
| implement "axioms" in a constructive manner.

that is understood.

| The properties
| 'associative' and 'abelian' are simply declarative.

yes, most computer algebra systems I know work that way -- just
define some tag and have system understand it and have people agree on
it. 

| It is up
| to the SPAD programmer to include appropriate code such as
| 
|   if D has associate("*"::Symbol) then ...
| 


\start
Date: 27 Feb 2006 10:24:52 +0100
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: about Expression Integer (with Quizzes)

Bill Page writes:

[...]

| > )set mess bot off
| > (6) y:DMP([y], INT);
| >     variables (2*y+1/y)
| >
| 
| I wrote: "Error same as in (2)". So I have to admit I got this
| one wrong but I should not have. The explanation is simple. This
| is not a package call as it was in (2), so the interpreter is
| free to apply the usual coercion to 'FRAC DMP([y], INT)' in order
| to obtain a selection for '/'.

When it takes so many Axiom experts to get those things wrong -- no
matter how obvious they might seem with hindsight -- I believe
the "free hands" given to the interperter may be questioned :-)

What I retain from this fascinating thread is that the implemented
underlying mechanim for interpreting polynomials is, hmmm, far from
"obvious" and "intuitive".

\start
Date: Mon, 27 Feb 2006 11:38:40 +0100
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Curiosities with Axiom mathematical structures

On 02/26/2006 05:42 PM, Gabriel Dos Reis wrote:
> Hello Willian,
> 
> thanks for the quick reply.
> 
> William Sit writes:
> 
> | Gabriel Dos Reis wrote:
> | >   In the impressive diagram titled "Basic Agebra Hierarchy" displayed
> | > in the Axiom Book (I only have a copy of the edition copyrighted 1992,
> | > NAG), AbelianSemiGroup is not "derived" from SemiGroup, and similarly
> | > AbelianMonoid is not "derived" from Monoid.  I find that curious as it
> | > goes counter the mathematical fact that an AbelianMonoid *is* a
> | > Monoid, with an additional algebraic law (commutation).
> | > 
> | >   Does anyone know the reason of those curiosities?
> | 
> | One probable reason may be the convention in mathematics to use +
> | instead of * when a semigroup, monoid, or group is abelian.
> 
> I find that argument very unconvincing for several reasons:
> 
>    1.  "+" or "*" are *syntax*, not algebraic properties.  Whether a
>        monoid is Abelian or not does stop it from being a monoid.  The
>        mathematical definition of an Abelian monoid is that it is a
>        monoid, whose operation *additionally* is commutative.
>     
>    2.  The set of natural numbers, NN, has *many* Abelian structures on it,
>        for examples:
>           a. (NN, +, 0) -- the usual addition
>           b. (NN, *, 1) -- the usual multiplication, commutative!
>           c. (NN, max, 0) -- "max" is the usual maximum function
> 
>         Such a counterexample can be multiplied.

One reason for having Monoid and AbelianMoniod (one with "*" and the 
other with "+") is that neither SPAD nor Aldor allows to rename 
functions during inheritance.

Note that one would have to say something like

define Monoid(
   *: (%, %) -> %;
   1: %
): Category == ...

define Group(
   *: (%, %) -> %,
   inv: % -> %,
   1: %
): Category == ...

define Ring(.....): Category == with {
   Monoid(*, 1);
   Group(+, -, 0);
}

OK, that is not well thought of...

Anyway, there is not way to do this in Aldor, yet. At least nobody has 
told me so far.

If such renaming could be implemented into the Aldor language that would 
make it even better suited for mathematics. However, then there is need 
that someone implements these ideas into the compiler. Who?

\start
Date: Mon, 27 Feb 2006 10:37:14 -0500
From: Tim Daly
To: Bill Page
Subject: Re: about Expression Integer (with Quizzes)

ok, time for me to weigh in on this subject....
but i will do it at a meta-level.

i think it is important to distinguish between mathematics and
computational mathematics. 

my experience is that written mathematics notation is very ambiguous.
we don't normally notice this because we view each equation in the
context of a given subject and, usually, in the context of a few
paragraphs that contain the semantics.

axiom attempts to capture the semantics and carry it in the type.
if the sematics of the type fits your understanding of the equation
then axiom works "correctly". if not, it appears to be a bug.
(axiom is hardly bug-free but i'm focused on the DMP issue here)

so what is the semantics of 2*x + 1/x? well, it's ambiguous.
each of you have successfully argued your understanding of the semantics.
and, in the context you've established, you are correct.

but axiom has to assign a meaning that might not match your understanding.
this is where the ambiguity becomes apparent. it is also where mathematics
and computational mathematics part company.

the 'solution' to this problem is to develop the computational idea of
a 'semantic context'. essentially what is needed is the ability to say
(at least in computer science terms):

"i want 'x' to be globally scoped" or "i want 'x' to be locally scoped"

but that isn't the best long-term approach. 'semantic context' is really
an 'extented type' idea. that is, you want to be able to tell axiom what
area of mathematics you are working in and have the type system adapt
its meaning to that area. 

this is the section of the textbook where the author say things like:
"i'm carefully distinguishing the Ring of coefficients from the 
variables in the polynomial" vs "this book explores polynomial
arithmetic".

the compiler will let you keep the two domains separate and will
force you to merge the domains when you want that behavior. the
interpreter is just guessing and you have to be careful to understand
how and why it guesses. (which means we have to construct a model of
the interpreter so we can formally state the coercion/conversion graph).

in my world view a semantic context is another facet in the crystal.
(but that's still long-term fantasy so we won't talk about it here).

anyway, i don't see that it is possible to resolve this debate.
you are all arguing from different semantic contexts. until you
agree to use the same assumptions there is no resolution.

\start
Date: 27 Feb 2006 17:08:27 +0100
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Curiosities with Axiom mathematical structures

Ralf Hemmecke writes:

| On 02/26/2006 05:42 PM, Gabriel Dos Reis wrote:
| > Hello Willian,
| > thanks for the quick reply.
| > William Sit writes:
| > | Gabriel Dos Reis wrote:
| > | >   In the impressive diagram titled "Basic Agebra Hierarchy" displayed
| > | > in the Axiom Book (I only have a copy of the edition copyrighted 1992,
| > | > NAG), AbelianSemiGroup is not "derived" from SemiGroup, and similarly
| > | > AbelianMonoid is not "derived" from Monoid.  I find that curious as it
| > | > goes counter the mathematical fact that an AbelianMonoid *is* a
| > | > Monoid, with an additional algebraic law (commutation).
| > | > | >   Does anyone know the reason of those curiosities?
| > | | One probable reason may be the convention in mathematics to use +
| > | instead of * when a semigroup, monoid, or group is abelian.
| > I find that argument very unconvincing for several reasons:
| >    1.  "+" or "*" are *syntax*, not algebraic properties.  Whether a
| >        monoid is Abelian or not does stop it from being a monoid.  The
| >        mathematical definition of an Abelian monoid is that it is a
| >        monoid, whose operation *additionally* is commutative.
| >        2.  The set of natural numbers, NN, has *many* Abelian
| > structures on it,
| >        for examples:
| >           a. (NN, +, 0) -- the usual addition
| >           b. (NN, *, 1) -- the usual multiplication, commutative!
| >           c. (NN, max, 0) -- "max" is the usual maximum function
| >         Such a counterexample can be multiplied.
| 
| One reason for having Monoid and AbelianMoniod (one with "*" and the
| other with "+") is that neither SPAD nor Aldor allows to rename
| functions during inheritance.

yes, that is true for many (all?) object-oriented languages.  I can
understand the language limitation, but that is hardly an excuse for
chosing in advance that "+" is for Abelian monoid and "*" for
non-Abelian ones.

| Note that one would have to say something like
| 
| define Monoid(
|    *: (%, %) -> %;
|    1: %
| ): Category == ...
| 
| define Group(
|    *: (%, %) -> %,
|    inv: % -> %,
|    1: %
| ): Category == ...
| 
| define Ring(.....): Category == with {
|    Monoid(*, 1);
|    Group(+, -, 0);
| }

Ring should be both Monoid and Group, whether they shoud be categories,
I don't really know.

| 
| OK, that is not well thought of...
| 
| Anyway, there is not way to do this in Aldor, yet. At least nobody has
| told me so far.
| 
| If such renaming could be implemented into the Aldor language that
| would make it even better suited for mathematics. However, then there
| is need that someone implements these ideas into the compiler. Who?

I'm not sure renaming is a good solution, at least if I was going to
solve this issue I would not go there.  However, I do believe that
expressing mathematical structures in a way that reflect mathematical
properties and understanding is essential.

I believe this is something solvable -- at least, that can be
approximated to a good extent -- in a type system based on predicate
system directly available at the programming level.  We've been
developing such an idea to build a type system for C++ template
arguments, see

   http://public.research.att.com/~bs/popl06.pdf

presented at POPL this year.

Notice that the "post facto extenstion" of Aldor is a starting point,
but it still does not help solving that issue..

The make the approach practical for large libraries in Axiom/Aldor I
believe some form of deduction of category/domain argument deduction
would needed.  However, Axiom/Aldor types being dependent, that be
challenging.   Anyway, I have searched the literature for the
descirption of Axiom/Adlor type system as implemented, I have found
nothing that could assist me.

\start
Date: Mon, 27 Feb 2006 13:03:18 -0600
From: MathAction (Bill Page)
To: MathAction
Subject: [DistributedMultivariatePolynomial] no surprise

The evaluation of '1/x x' in
'DistributedMultivariatePolynomial([x]?,Polynomial Integer)'
is equivalent '1' but it is not equivalent to '1' in
'DistributedMultivariatePolynomial([x]?,Fraction Polynomial Integer)'.
It is precisely because the coefficient ring is different. This
is completely acceptable to me.

\start
Date: Tue, 28 Feb 2006 23:26:56 -0500
From: Bill Page
To: Gabriel Dos Reis, Ralf Hemmecke
Subject: RE: Curiosities with Axiom mathematical structures

On February 27, 2006 11:08 AM Gabriel Dos Reis wrote:

>...
>  
> Ralf Hemmecke writes:
> ... 
> | One reason for having Monoid and AbelianMoniod (one with "*" and
> | the other with "+") is that neither SPAD nor Aldor allows to
> | rename functions during inheritance.
> 
> yes, that is true for many (all?) object-oriented languages.  I can
> understand the language limitation, but that is hardly an excuse for
> chosing in advance that "+" is for Abelian monoid and "*" for
> non-Abelian ones.
>

I don't see why renaming is necessary.
 
> | Note that one would have to say something like
> | 
> | define Monoid(
> |    *: (%, %) -> %;
> |    1: %
> | ): Category == ...
> | 
> | define Group(
> |    *: (%, %) -> %,
> |    inv: % -> %,
> |    1: %
> | ): Category == ...
> | 
> | define Ring(.....): Category == with {
> |    Monoid(*, 1);
> |    Group(+, -, 0);
> | }
> 
> Ring should be both Monoid and Group, whether they shoud be 
> categories, I don't really know.
>

In Axiom (SPAD) we can write:

Monoid(m:Symbol,u:Symbol): Category == with
       m: (%,%) -> %       ++ returns the product of x and y
       u: () -> %          ++ unit
       associative(m)      ++ m(a,m(b,c)) = m(m(a,b),c)
       identity(u)         ++ m(a,u) = m(u,a) = a

Group(m:Symbol,inv:Symbol,u:Symbol): Category == Monoid(m,u) with
       inv: % -> %         ++ inverse
       inverse(m,inv)      ++ m(inv(a),a) = m(a,inv(a)) = u

AbelianGroup(m:Symbol,inv:Symbol,u:Symbol): Category
   == Group(m,inv,u) with
      commutative(m)       ++ m(a,b) = m(b,a)

Ring(s:Symbol,inv:Symbol,z:Symbol, m:Symbol,u:Symbol): Category
   == Join(AbelianGroup(s,inv,z),Monoid(m,u)) with
      distributes(m,s)     ++ m(a,s(b,c)) = s(m(a,b),m(a,c))
                           ++ m(s(a,b),c) = s(m(a,c),m(b,c))

Then we can write:

  )sh Ring(+,-,"0"::Symbol,*,"1"::Symbol)
  Ring(+,-,"0"::Symbol,*,"1"::Symbol) has commutative(+)

See the example at http://wiki.axiom-developer.org/SandBoxMonoid

> | 
> | OK, that is not well thought of...
> | 
> | Anyway, there is not way to do this in Aldor, yet. At least 
> | nobody has told me so far.

It is possible to write the above definitions in Aldor.

> | 
> | If such renaming could be implemented into the Aldor language
> | that would make it even better suited for mathematics. However, 
> | then there is need that someone implements these ideas into the
> | compiler. Who?

Could you explain what you mean by "renaming" and how it might
be used to express mathematics?

> 
> I'm not sure renaming is a good solution, at least if I was going
> to solve this issue I would not go there. However, I do believe
> that expressing mathematical structures in a way that reflect
> mathematical properties and understanding is essential.

I agree.

> 
> I believe this is something solvable -- at least, that can be
> approximated to a good extent -- in a type system based on
> predicate system directly available at the programming level.
> We've been developing such an idea to build a type system for
> C++ template arguments, see
> 
>    http://public.research.att.com/~bs/popl06.pdf
> 
> presented at POPL this year.

I think the predicates here are what Axiom calls "axioms" such as:

       associative(m)      ++ m(a,m(b,c)) = m(m(a,b),c)
       identity(u)         ++ m(a,u) = m(u,a) = a
       inverse(m,inv)      ++ m(inv(a),a) = m(a,inv(a)) = u
       commutative(m)      ++ m(a,b) = m(b,a)
       distributes(m,s)    ++ m(a,s(b,c)) = s(m(a,b),m(a,c))
                           ++ m(s(a,b),c) = s(m(a,c),m(b,c))

In Axiom right now the only thing we can do with axioms is to
test them, e.g.

  R:=Ring(+,-,"0"::Symbol,*,"1"::Symbol)
  ...
  if R has commutative(+) then

but one could easily imagine adding more complex predicates
which could still be evaluated at compile time. (Remember that
Axiom and Aldor are intended to be statically typed languages.)

> 
> Notice that the "post facto extenstion" of Aldor is a starting
> point, but it still does not help solving that issue..

As I understand it, post facto extension allows for the
iterative definition of a type, i.e. adding and/or refining
new functions. I am not sure how this might apply in the
example of the Ring above, but I think there are more
interesting types that must be defined by mutual recursion
and in that case post facto extension seems very natural.
Could you give some examples of how else you think this can
be used?

> 
> The make the approach practical for large libraries in
> Axiom/Aldor I believe some form of deduction of category/domain
> argument deduction would needed.  However, Axiom/Aldor types
> being dependent, that be challenging.   Anyway, I have searched
> the literature for the descirption of Axiom/Adlor type system
> as implemented, I have found nothing that could assist me.
> 

Have you looked at the papers by Erik Poll and Simon Thompson
such as:

Adding the axioms to Axiom - Towards a system of automated reasoning
in Aldor

Abstract:
A number of combinations of theorem proving and computer algebra
systems have been proposed; in this paper we describe another
namely a way to incorporate a logic in the computer algebra system
Axiom. We examine the type system of Aldor - the Axiom Library
Compiler - and show that with some modifications we can use the
dependent types of the system to model a logic using the Curry-Howard
isomorphism. We give a number of example applications of the logic
we construct.

http://portal.axiom-developer.org/refs/articles/axiom-content.pdf/view

Logic and Dependent Types in the Aldor Computer Algebra System

Abstract:
We show how the Aldor type system can represent propositions of
first-order logic, by means of the `propositions as types'
correspondence. The representation relies on type casts (using
pretend) but can be viewed as a prototype implementation of a
modified type system with type evaluation reported elsewhere [9].
The logic is used to provide an axiomatisation of a number of
familiar Aldor categories as well as a type of vectors.

http://portal.axiom-developer.org/refs/articles/aldor-calc2000.pdf/view

Integrating Computer Algebra and Reasoning through the Type System of Aldor

Abstract:
A number of combinations of reasoning and computer algebra systems
have been proposed; in this paper we describe another, namely a way
to incorporate a logic in the computer algebra system Axiom. We examine
the type system of Aldor - the Axiom Library Compiler - and show that
with some modifications we can use the dependent types of the system
to model a logic, under the Curry-Howard isomorphism. We give a number
of example applications of the logic we construct and explain a prototype
implementation of a modified type-checking system written in Haskell. 

http://portal.axiom-developer.org/refs/articles/frocos2000.pdf/view

---------

Regards,
Bill Page.





\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
