\start
Date: Tue, 2 Jun 2009 21:30:45 -0500
From: Tim Daly
To: list
Subject: Axiom on savannah.nongnu.org has moved to git

There was a hard disk failure on the savannah.nongnu.org server.
As a result the Axiom CVS sources were lost.

The latest git version has been posted at 
http://savannah.nongnu.org/projects/axiom

I have been debating the wisdom of maintaining CVS and SVN versions of
Axiom. At this point, the debate is closed. I see no value in
maintaining CVS and SVN versions so they will be dropped everywhere
and moved to git.

The distributed version control model used by git means that every
copy of the repository (including your own) IS the master repository.
There is no need for a central server although these will still be 
maintained for git.

Axiom release sources are available with git using:

git clone git://github.com/daly/axiom.git  (github)
git clone git://git.sv.gnu.org/axiom.git   (savannah)




If you do need a CVS checkout you can use:

cvs -d:pserver:anonymous@pserver.git.sv.gnu.org:/autoconf.git co -d autoconf master

Detailed instructions are at:

http://savannah.gnu.org/maintenance/UsingGit

\start
Date: Thu, 04 Jun 2009 15:13:37 -0400
From: Tim Daly
To: Gabriel Dos Reis
Subject: Re: InputForm
Cc: Martin Rubey

Gabriel Dos Reis wrote:
> Tim Daly writes:
>
> | I've been reading this thread. It seems to me that what people are seeking
> | is a symbolic algebra rather than a computer algebra system. The distinction
> | is that a symbolic system manipulates input as parse trees in
> | syntactic form.
> | A computer algebra system manipulates input as semantic forms. It appears
> | that you want to recover the syntax from the semantics, a very hard problem.
>
> OpenAxiom has the Syntax domain for matters that are purely syntactic,
>
> OpenAxiom's intended  of InputForm is that of expressions the semantics
> of which yield computer representation of mathematical object.  In
> particular, you can think of Syntax objects are pre-InputForm objects --
> syntactic objects that have not yet been type checked.  So a Syntax object
> is really a member of an initial algebra -- unlike InputForm or
> SExpression objects. 
>
> | This discussion came up before. At the time I wrote the beginnings of a
> | symbolic front end to Axiom based on Joel Cohen's work. Joel has given
> | me permission to use his books as part of the effort.
>
> I'm familiar with his work (and his two books).  I would think that
> there already exist a domain constructor, Expression, that is most
> suited for the work presented in the two volumes.  The fundamental
> building block is the Kernel domain constructor.  I know some people
> have expressed profound dislikes of the Expression domain constructor.
> But, I suspect that they would have a deeper appreciation of it after
> reading Cohen's work.
>
> The need for InputForm is not just for 'symbolic mathematics'.  A proper
> support for the compilation model of the Spad language requires that any
> constructor argument be coercible to InputForm.  A fact that is not --
> at the moment -- enforced, but that is deeply relied upon.  See what the
> devaluate functions do and the unspolem assumptions behind.
>
> It is on my TODO list that OpenAxiom-1.3.x and up will enforce those
> assumptions. 
>
> -- Gaby
>
>   
So you propose that there are two reasons for this discussion of InputForm,
one of which is to support a computational model of the spad language
and the other is to support symbolic manipulation?

It is unclear what to expect from InputForm.
Under the assumption of a computational model it seems that x+y^2 == y^2+x
Under the assumption of a cohen symbolic model they are not equivalent.
(assuming that plus is associative in both cases)

Given that there was a comment that the input form was not properly 
reproduced
I assumed the discussion involved symbolic issues. Perhaps I misread it.

I do not see how InputForm can be made to support both models.

\start
Date: Thu, 04 Jun 2009 14:04:03 -0400
From: Tim Daly
To: Ralf Hemmecke, Gabriel Dos Reis, Martin Rubey, Bill Page,
Subject: Re: InputForm

I've been reading this thread. It seems to me that what people are seeking
is a symbolic algebra rather than a computer algebra system. The distinction
is that a symbolic system manipulates input as parse trees in syntactic 
form.
A computer algebra system manipulates input as semantic forms. It appears
that you want to recover the syntax from the semantics, a very hard problem.

This discussion came up before. At the time I wrote the beginnings of a
symbolic front end to Axiom based on Joel Cohen's work. Joel has given
me permission to use his books as part of the effort.

Joel describes a symbolic, expression tree based system for doing
computational mathematics. I call this a "Cohen Algebra". Using these
expression trees allows us to carefully craft and manipulate the expressions
in ways that Axiom would not normally permit because they are not
semantically valid. As long as the forms are never coerced to Axiom
domains until they are semantically valid, it is possible to do many
"badly formed" intermediate manipulations, some of which are very
useful for teaching purposes.

We can get the Cohen algebra into Axiom using categories, domains, and
packages that support expression tree I/O and coercions to and from
Axiom domains, e.g.
   cohenPolynomial(cohenInteger) <-> Polynomial(Integer)

This enables us to address several issues that have been outstanding
in the field for a while, including those mentioned at the last conference:

  *) It would be possible to do "step-by-step" output (Watt?)
          That is, you could show the steps of solving 3*x=6
           by showing the step of dividing both sides by 3
              3       6
              -  x =  -
              3       3
         and preserve the 3 on both sides

   *) It would be possible to do "step-by-step* explanations (Watt?)
          Algorithms in the Cohen domains could easily have
          explanations attached to the operations so that it could
          automatically print:
               "divide each side by 3"

     *) It would be possible to modify the output if the result
          turned into "wallpaper" (as mentioned by Davenport).
          So you could simply print the condensed output of a
          groebner basis computation.

      *) It would be much easier to input and output forms for
          other systems (e.g. supporting OpenMath output)
          (Davenport)

I plan to do more work on Cohen domains because all of the
above features would be useful. My simple test example domains
are attached.

In my opinion, the idea of using InputForm beyond its intended
interpreter connections is not a viable effort. It would be much
easier and more profitable to construct something like the Cohen
domains to support the goal.

Tim

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

)abbrev category CCAT CohenCategory

+++ Author: Timothy Daly
+++ Date Created: 7 April 2007
+++ Description: Joel Cohen's Computer Algebra and Symbolic Computation
CohenCategory(): Category == SetCategory with

  kind:(CExpr)->Boolean
    ++ kind(CExpr)
  operand:(CExpr,Integer)->CExpr
    ++ operand:(CExpr,Integer)
  numberOfOperand:(CExpr)->Integer
    ++ numberOfOperand:(CExpr)->Integer
  construct:(CExpr,CExpr)->CExpr
    ++ construct:(CExpr,CExpr)->CExpr

-------------------------------------------------------------------
)abbrev domain CTERM CohenTerm

+++ Author: Timothy Daly
+++ Date Created: 7 April 2007
+++ Description: Joel Cohen's Computer Algebra and Symbolic Computation
CohenTerm(): Exports == Implementation where
  OUT     ==> OutputForm
  ATTRIBS ==> Record(attrib: String, value: String)
  UNION   ==> Union(Symbol,String,Integer)
  TAGS    ==> Record(name:UNION, tags:List ATTRIBS)

  Exports ==> CohenCategory with
    term: () -> %
    term: Symbol -> %
    term: String -> %
    term: Integer -> %
    name: % -> String
    tags: % -> List ATTRIBS
    coerce: Symbol -> %
    coerce: String -> %
    coerce: Integer -> %
    coerce: % -> OUT
    _=: (%,%) -> Boolean

  Implementation ==> add

    Rep := TAGS

    tagPair(atype:String,thetype:String):ATTRIBS ==
      attr:ATTRIBS:=[atype,thetype]

    name(t0:%):String ==
      t1:=t0.name
      t1 case Symbol  => string t1
      t1 case String  => t1
      t1 case Integer => string t1
      "failed"

    tags(t0:%):List ATTRIBS == t0.tags

    term():% ==
      attr:List ATTRIBS:= list tagPair("type","String")
      aname:=""::UNION
      result:TAGS:=[aname,attr]
      result

    term(s:Symbol):%  == [s,[tagPair("type","Symbol")]]
    coerce(s:Symbol):%  == [s,[tagPair("type","Symbol")]]

    term(s:String):%  == [s,[tagPair("type","String")]]
    coerce(s:String):%  == [s,[tagPair("type","String")]]

    term(s:Integer):% == [s,[tagPair("type","Integer")]]
    coerce(s:Integer):% == [s,[tagPair("type","Integer")]]

    coerce(arg:%):OUT ==
      t0:=arg.name
      t1:=arg.tags
      t2:=
        t0 case Symbol  => outputForm t0
        t0 case String  => outputForm t0
        t0 case Integer => outputForm t0
        "failed"
      --bracket [ t2, t1.1 ]
      t2
 
    a = b ==
      a.name = b.name


-------------------------------------------------------------------
)abbrev domain CTREE CohenTree

+++ Author: Timothy Daly
+++ Date Created: 7 April 2007
+++ Description: Joel Cohen's Computer Algebra and Symbolic Computation
CohenTree(S: CohenCategory): Exports == Implementation where
  Exports == BinaryTreeCategory(S) with
   cohenTree: S -> %
    ++ cohenTree(v) is an non-empty cohen tree
    ++ with value v, and left and right empty.
    ++
    ++X t1:=cohenTree([1,2,3])
   
   cohenTree: (%,S,%) -> %   
    ++ cohenTree(l,v,r) creates a cohen tree with
    ++ value v with left subtree l and right subtree r.
    ++
    ++X t1:=cohenTree([1,2,3])
    ++X t2:=cohenTree([4,5,6])
    ++X cohenTree(t1,[7,8,9],t2)

   cohenTree: (%,S) -> %
    ++ cohenTree(v,r) creates a cohen tree with
    ++ value v with right subtree r.

   cohenTree: (S,%) -> %
    ++ cohenTree(l,v) creates a cohen tree with
    ++ value v with left subtree l

   empty: () -> %
    ++ empty()
   empty?: % -> Boolean
    ++ empty?(a)
   leaf?: % -> Boolean
    ++ leaf?(a)
   left: % -> %
    ++ left(a)
   node: (%,S,%) -> %
    ++ node(a,b,c)
   right: % -> %
    ++ right(a)
   setleft_!: (%,%) -> %
    ++ setleft!(a,b)
   setright_!: (%,%) -> %
    ++ setright!(a,b)
   setvalue_!: (%,S) -> S
    ++ setvalue!(a,b)
   value: % -> S
    ++ value(a)
   
  Implementation == add
   Rep := List Tree S

   cohenTree(v:S) == node(empty(),v,empty())
   cohenTree(l:%,v:S,r:%):% == node(l,v,r)
   cohenTree(l:%,v:S):% == node(l,v,empty())
   cohenTree(v:S,r:%):% == node(empty(),v,r)
   empty()== [] pretend %
   empty? t == empty?(t)$Rep
   leaf? t  == empty? t or empty? left t and empty? right t
   left t ==
     empty? t => error "cohenTree:no left"
     children first t
   node(l,v,r) == cons(tree(v,l:Rep),r:Rep)
   right t ==
     empty? t => error "cohenTree:no right"
     rest t
   setleft_!(t1,t2) ==
     empty? t1 => error "cohenTree:no left to set"
     setchildren_!(first(t1:Rep),t2:Rep)
     t1
   setright_!(t1,t2) ==
     empty? t1 => error "cohenTree:no right to set"
     setrest_!(t1:List Tree S,t2)
   setvalue_!(t,nd) ==
     empty? t => error "cohenTree:no value to set"
     setvalue_!(first(t:Rep),nd)
     nd
   value t ==
     empty? t => error "cohenTree:no value"
     value first t
   t1 = t2 == (t1::Rep) =$Rep (t2::Rep)


-------------------------------------------------------------------
--  a:=a::CTERM
--  b:=b::CTERM
--  c:=a+b
--  left(c)
--  right(c)
--  d:=3::CTERM
--  e:=d*c
--  left(e)
--  right(e)
-- 
--  -- Figure 3.4 p88
--  )clear all
-- 
--  c:=c::CTERM
--  d:=d::CTERM
--  x:=x::CTERM
--  two:=2::CTERM
--  e:=c+d*x^2
-- 
--  -- Figure 3.5a p89
--  )clear all
--  a:=a::CTERM
--  b:=b::CTERM
--  c:=c::CTERM
--  d:=a*b+c
--  e:=-d

-------------------------------------------------------------------
)abbrev package CMATH CohenMath

+++ Author: Timothy Daly
+++ Date Created: 7 April 2007
+++ Description: Joel Cohen's Computer Algebra and Symbolic Computation
CohenMath: Exports == Implementation where
  TERM ==> CohenTerm
  TREE ==> CohenTree(TERM)
 
  Exports ==> with
   _-: (TERM) -> TREE
    ++ -a
   _-: (TREE) -> TREE
    ++ -a

--   "!": (TERM) -> TREE
--    ++ a!
--   "!": (TREE) -> TREE
--    ++ a!

   _-: (TERM,TERM) -> TREE
    ++ a-b
   _-: (TERM,TREE) -> TREE
    ++ a-b
   _-: (TREE,TERM) -> TREE
    ++ a-b
   _-: (TREE,TREE) -> TREE
    ++ a-b

   _+: (TERM,TERM) -> TREE
    ++ a+b
   _+: (TERM,TREE) -> TREE
    ++ a+b
   _+: (TREE,TERM) -> TREE
    ++ a+b
   _+: (TREE,TREE) -> TREE
    ++ a+b

   _*: (TERM,TERM) -> TREE
    ++ a*b
   _*: (TERM,TREE) -> TREE
    ++ a*b
   _*: (TREE,TERM) -> TREE
    ++ a*b
   _*: (TREE,TREE) -> TREE
    ++ a*b

   _^: (TERM,TERM) -> TREE
    ++ a*b
   _^: (TERM,TREE) -> TREE
    ++ a*b
   _^: (TREE,TERM) -> TREE
    ++ a*b
   _^: (TREE,TREE) -> TREE
    ++ a*b

  Implementation ==> add

   --- handle unary prefix terms

   prefixTerm(op:TERM,b:TERM):TREE  == cohenTree(op,cohenTree(b))
   prefixTree(op:TERM,b:TREE):TREE  == cohenTree(op,b)

   --- handle unary postfix terms

   postfixTerm(a:TERM,op:TERM):TREE == cohenTree(cohenTree(a),op)
   postfixTree(a:TREE,op:TERM):TREE == cohenTree(a,op)

   --- handle binary terms

   termOpTerm(a:TERM,op:TERM,b:TERM):TREE ==
      cohenTree(cohenTree(a),op,cohenTree(b))

   termOpTree(a:TERM,op:TERM,b:TREE):TREE ==
      cohenTree(cohenTree(a),op,b)

   treeOpTerm(a:TREE,op:TERM,b:TERM):TREE ==
      cohenTree(a,op,cohenTree(b))

   treeOpTree(a:TREE,op:TERM,b:TREE):TREE ==
      cohenTree(a,op,b)

   _-(b:TERM):TREE         == prefixTerm(term("-")$TERM,b)
   _-(c:TREE):TREE         == prefixTree(term("-")$TERM,c)

--   "!"(a:TERM):TREE         == postfixTerm(a,term("!")$TERM)
--   "!"(a:TREE):TREE         == postfixTree(a,term("!")$TERM)

   _-(a:TERM, b:TERM):TREE == termOpTerm(a,term("-")$TERM,b)
   _-(a:TERM, b:TREE):TREE == termOpTree(a,term("-")$TERM,b)
   _-(a:TREE, b:TERM):TREE == treeOpTerm(a,term("-")$TERM,b)
   _-(a:TREE, b:TREE):TREE == treeOpTree(a,term("-")$TERM,b)

   _+(a:TERM, b:TERM):TREE == termOpTerm(a,term("+")$TERM,b)
   _+(a:TERM, b:TREE):TREE == termOpTree(a,term("+")$TERM,b)
   _+(a:TREE, b:TERM):TREE == treeOpTerm(a,term("+")$TERM,b)
   _+(a:TREE, b:TREE):TREE == treeOpTree(a,term("+")$TERM,b)

   _*(a:TERM, b:TERM):TREE == termOpTerm(a,term("*")$TERM,b)
   _*(a:TERM, b:TREE):TREE == termOpTree(a,term("*")$TERM,b)
   _*(a:TREE, b:TERM):TREE == treeOpTerm(a,term("*")$TERM,b)
   _*(a:TREE, b:TREE):TREE == treeOpTree(a,term("*")$TERM,b)

   _^(a:TERM, b:TERM):TREE == termOpTerm(a,term("^")$TERM,b)
   _^(a:TERM, b:TREE):TREE == termOpTree(a,term("^")$TERM,b)
   _^(a:TREE, b:TERM):TREE == treeOpTerm(a,term("^")$TERM,b)
   _^(a:TREE, b:TREE):TREE == treeOpTree(a,term("^")$TERM,b)


-------------------------------------------------------------------
)abbrev domain COHEN CohenAlgebra

+++ Author: Timothy Daly (based on Joel Cohen's books)
+++ Date Created: 7 April 2007
+++ Description:
+++ This type represents symbolic algebra as detailed in Joel Cohen's
+++ books "Computer Algebra and Symbolic Computation"
+++ A.K. Peters, Ltd. ISBN 1-56881-159-4
+++
+++ Elements of this domain are purely symbolic expressions represented
+++ in a tree structure.

CohenAlgebra(X : CohenCategory) : CohenCategory with

  _+: (X,X) -> %
   ++ x + y is the formal sum of the input arguments

  _/: (X,X) -> %
   ++ x / y is the formal fraction of the input arguments

  numer : % -> X
   ++ numer(x) is the numerator of the formal fraction

  denom : % -> X
   ++ denom(x) is the denominator of the formal fraction

  if X has IntegralDomain then
 
    coerce : % -> Fraction(X)
     ++ coerce(x) from here to Fraction(there)

    coerce : Fraction(X) -> %
     ++ coerce(x) from Fraction(there) to here

  if X has Field then
   
    coerce : % -> X
     ++ coerce from here to Field(there)

 == add

  import Record(num : X, den : X)
 
  Rep := Record(num : X, den : X)  -- representation

-- (a::CTERM + b::CTERM)$COHEN(CTERM)
-- c:CTERM:=d
-- e:CTERM:=f
-- (c+e)$COHEN(CTERM)

  (n:X + d:X):% == [n,d]
 
-- (a::CTERM / b::CTERM)$COHEN(CTERM)
-- c:CTERM:=d
-- e:CTERM:=f
-- (c/e)$COHEN(CTERM)

  (n:X / d:X):% == [n,d]
 
-- g:=(c/e)$COHEN(CTERM)
-- h:=(c/e)$COHEN(CTERM)
-- (g=h)
-- (g=h)::Boolean
-- i:=(a::CTERM / b::CTERM)$COHEN(CTERM)
-- j:=(a::CTERM / b::CTERM)$COHEN(CTERM)
-- (i=j)::Boolean
-- (g=i)
-- (g=i)::Boolean

  _=(x:%, y:%):Boolean == (x.num = y.num) and (x.den = y.den)

-- numer g
-- numer i

  numer(r:%):X == r.num

--denom g
--denom i

  denom(r:%):X == r.den

  coerce(r:%):OutputForm == (r.num :: OutputForm) / (r.den :: OutputForm)



-- COMPLEX(INT) has FIELD
-- COMPLEX(INT) has IntegralDomain
-- p:COMPLEX(INT):=2
-- p::FRAC(COMPLEX(INT))::COHEN(COMPLEX(INT))

  if X has IntegralDomain then
 
    coerce(r : %) : Fraction(X)
      ==  (r.num / r.den) @ Fraction(X)

    coerce(x : Fraction(X)) : % == x pretend % 

-- FRAC(POLY(INT)) has FIELD
-- m:=(x^2)@FRAC(POLY(INT))
-- m::COHEN(POLY(INT))

  if X has Field then
    coerce(r : %) : X
      == (r.num / r.den) @ X

\start
Date: Thu, 04 Jun 2009 15:43:12 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: InputForm
Cc: Martin Rubey

Tim Daly writes:

| Gabriel Dos Reis wrote:
| > Tim Daly writes:
| >
| > | I've been reading this thread. It seems to me that what people are seeking
| > | is a symbolic algebra rather than a computer algebra system. The distinction
| > | is that a symbolic system manipulates input as parse trees in
| > | syntactic form.
| > | A computer algebra system manipulates input as semantic forms. It appears
| > | that you want to recover the syntax from the semantics, a very hard problem.
| >
| > OpenAxiom has the Syntax domain for matters that are purely syntactic,
| >
| > OpenAxiom's intended  of InputForm is that of expressions the semantics
| > of which yield computer representation of mathematical object.  In
| > particular, you can think of Syntax objects are pre-InputForm objects --
| > syntactic objects that have not yet been type checked.  So a Syntax object
| > is really a member of an initial algebra -- unlike InputForm or
| > SExpression objects. 
| >
| > | This discussion came up before. At the time I wrote the beginnings of a
| > | symbolic front end to Axiom based on Joel Cohen's work. Joel has given
| > | me permission to use his books as part of the effort.
| >
| > I'm familiar with his work (and his two books).  I would think that
| > there already exist a domain constructor, Expression, that is most
| > suited for the work presented in the two volumes.  The fundamental
| > building block is the Kernel domain constructor.  I know some people
| > have expressed profound dislikes of the Expression domain constructor.
| > But, I suspect that they would have a deeper appreciation of it after
| > reading Cohen's work.
| >
| > The need for InputForm is not just for 'symbolic mathematics'.  A proper
| > support for the compilation model of the Spad language requires that any
| > constructor argument be coercible to InputForm.  A fact that is not --
| > at the moment -- enforced, but that is deeply relied upon.  See what the
| > devaluate functions do and the unspolem assumptions behind.
| >
| > It is on my TODO list that OpenAxiom-1.3.x and up will enforce those
| > assumptions. 
| >
| > -- Gaby
| >
| >   
| So you propose that there are two reasons for this discussion of InputForm,
| one of which is to support a computational model of the spad language
| and the other is to support symbolic manipulation?

No -- I did not mean to give an exhaustive list of reasons to have
InputForm or not.   However, I do recognize instances of situations
where the notion of InputForm os relevant and that is what I was trying
to say.  Futhermore, I do not think the world has to be divided in terms
of algebraic computation versus symbolic computation.  Rather, my belief
is that symbolic mathematics (cross of algebraic computation and
symbolic computation) are going to be more and more prevalent.

| It is unclear what to expect from InputForm.

I think an operational definition of InputForm may be that of syntactic
normal forms of mathematical objects.  This is required for handling
categories and domains properly (or any form of dependent types).

| Under the assumption of a computational model it seems that x+y^2 == y^2+x

Note that the linear display of the InputForm x + y^2 as y^2 + x
reflects the semantics of the polynomial object denoted by that form.
As such, I do not think this is a mater of algebraic versus symbolic
computation. 

| Under the assumption of a cohen symbolic model they are not equivalent.
| (assuming that plus is associative in both cases)

Cohen assumes that + is associative -- because he primarily works with
polynomials over commutative rings.

| Given that there was a comment that the input form was not properly
| reproduced
| I assumed the discussion involved symbolic issues. Perhaps I misread it.
| 
| I do not see how InputForm can be made to support both models.

Indeed.  I would reserve the use of InputForm for syntatic canonical
forms of mathematical objects.

\start
Date: Thu, 04 Jun 2009 13:43:17 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: [fricas-devel] Re: [Axiom-mail] InputForm
Cc: Martin Rubey

Tim Daly writes:

| I've been reading this thread. It seems to me that what people are seeking
| is a symbolic algebra rather than a computer algebra system. The distinction
| is that a symbolic system manipulates input as parse trees in
| syntactic form.
| A computer algebra system manipulates input as semantic forms. It appears
| that you want to recover the syntax from the semantics, a very hard problem.

OpenAxiom has the Syntax domain for matters that are purely syntactic,

OpenAxiom's intended  of InputForm is that of expressions the semantics
of which yield computer representation of mathematical object.  In
particular, you can think of Syntax objects are pre-InputForm objects --
syntactic objects that have not yet been type checked.  So a Syntax object
is really a member of an initial algebra -- unlike InputForm or
SExpression objects. 

| This discussion came up before. At the time I wrote the beginnings of a
| symbolic front end to Axiom based on Joel Cohen's work. Joel has given
| me permission to use his books as part of the effort.

I'm familiar with his work (and his two books).  I would think that
there already exist a domain constructor, Expression, that is most
suited for the work presented in the two volumes.  The fundamental
building block is the Kernel domain constructor.  I know some people
have expressed profound dislikes of the Expression domain constructor.
But, I suspect that they would have a deeper appreciation of it after
reading Cohen's work.

The need for InputForm is not just for 'symbolic mathematics'.  A proper
support for the compilation model of the Spad language requires that any
constructor argument be coercible to InputForm.  A fact that is not --
at the moment -- enforced, but that is deeply relied upon.  See what the
devaluate functions do and the unspolem assumptions behind.

It is on my TODO list that OpenAxiom-1.3.x and up will enforce those
assumptions. 

\start
Date: Thu, 4 Jun 2009 21:17:53 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: InputForm
Cc: Martin Rubey

On Thu, Jun 4, 2009 at 4:43 PM, Gabriel Dos Reis wrote:
> ...
> I would reserve the use of InputForm for syntatic canonical
> forms of mathematical objects.
>

Currently InputForm values can arise both from parsing of input
strings and from coercion of values from other domains. Only the
latter are in some sense "cononical". But even these are only
cononical to the degree that the domain from which they are derived
has such properties.  So it is not clear to me how one can hope to
reserve InputForm for only this use.

\start
Date: Thu, 04 Jun 2009 20:48:15 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: InputForm
Cc: Martin Rubey

Bill Page writes:

| On Thu, Jun 4, 2009 at 4:43 PM, Gabriel Dos Reis wrote:
| > ...
| > I would reserve the use of InputForm for syntatic canonical
| > forms of mathematical objects.
| >
| 
| Currently InputForm values can arise both from parsing of input
| strings and 

That is the job of Syntax domain in OpenAxiom.

| from coercion of values from other domains. Only the
| latter are in some sense "cononical". But even these are only
| cononical to the degree that the domain from which they are derived
| has such properties.

Obviously.  For OpenAxiom, a domain that can see its values used as
constructor arguments should satisfy both SetCategory and 
CoercibleTo InputForm.  If a domain cannot satisfy those too
constraints, there is little point in trying to use its value as
constructor arguments.

| So it is not clear to me how one can hope to reserve InputForm for
| only this use. 

It is a design choice.  However, I fully appreciate there are many
choices to make and people are likely to make different choices.

\start
Date: Thu, 4 Jun 2009 22:34:06 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: InputForm
Cc: Martin Rubey

> | On Thu, Jun 4, 2009 at 4:43 PM, Gabriel Dos Reis wrote:
> | > ...
> | > I would reserve the use of InputForm for syntatic canonical
> | > forms of mathematical objects.
> | >
> | Bill Page wrote:
> | Currently InputForm values can arise both from parsing of input
> | strings and
>

On Thu, Jun 4, 2009 at 9:48 PM, Gabriel Dos Reis wrote:
>
> That is the job of Syntax domain in OpenAxiom.
>

Although it sounds logical and desirable, I suppose that direct
conversion of values in the Syntax domain to "canonical" values in
InputForm is a rather hard problem. No?

I am tempted to argue in fact that the primary purpose of most of the
rest of panAxiom is to do just this sort of conversion - through the
algebraic "back door" so-to-speak ...

\start
Date: Thu, 04 Jun 2009 21:47:02 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: InputForm
Cc: Martin Rubey

Bill Page writes:

| > | On Thu, Jun 4, 2009 at 4:43 PM, Gabriel Dos Reis wrote:
| > | > ...
| > | > I would reserve the use of InputForm for syntatic canonical
| > | > forms of mathematical objects.
| > | >
| > | Bill Page wrote:
| > | Currently InputForm values can arise both from parsing of input
| > | strings and
| >
| 
| On Thu, Jun 4, 2009 at 9:48 PM, Gabriel Dos Reis wrote:
| >
| > That is the job of Syntax domain in OpenAxiom.
| >
| 
| Although it sounds logical and desirable, I suppose that direct
| conversion of values in the Syntax domain to "canonical" values in
| InputForm is a rather hard problem. No?

The Syntax domain's primary purpose is as vehicle for terms.  Terms are
semanticalled analyzed (e.g. type checked, resolved), and evaluated.
The evaluation produces a computer representation of a mathematical
object, specified by a domain.  That domain provides -a- canonical
internal repsentation (e.g. dense vs. sparse, factored vs. fully expanded).
To get from internal to external representation, OpenAxiom uses
InputForm, which in displayed form is a linear notation for the
canonical internal representation.  So, I do not know you understand by
'direct conversion'.  A Syntax domain object does not necessarily makes
sense (e.g. may NOT type check), whereas an InputForm is supposed to
have a meaning.

| I am tempted to argue in fact that the primary purpose of most of the
| rest of panAxiom is to do just this sort of conversion - through the
| algebraic "back door" so-to-speak ...

I see OpenAxiom as aiming at computational mathematics as opposed to
just being specialized for algebraic computations only.

\start
Date: Thu, 4 Jun 2009 23:15:22 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: InputForm
Cc: Martin Rubey

On Thu, Jun 4, 2009 at 10:47 PM, Gabriel Dos Reis  wrote:
> ...
> I see OpenAxiom as aiming at computational mathematics as opposed
> to just being specialized for algebraic computations only.
>

+1 I am in full agreement with your general goals and methods.

\start
Date: Fri, 05 Jun 2009 01:42:42 -0400
From: Tim Daly
To: list
Subject: Axiom on Sourceforge moved to git

The Axiom repository on Sourceforge has been moved to git.
The CVS and SVN repositories are no longer maintained and
have been withdrawn.

You can get the latest sources by doing:

git clone git://axiom.git.sourceforge.net/gitroot/axiom (sourceforge)
git clone git://git.sv.gnu.org/axiom.git (savannah)
git clone git://github.com/daly/axiom.git (github)

These will all be maintained at the latest levels as soon as the
update process completes.

\start
Date: Fri, 05 Jun 2009 09:04:52 -0400
From: Tim Daly
To: Ralf Hemmecke, Gabriel Dos Reis, Martin Rubey, Bill Page, Waldek Hebisch
Subject: mapleok

Martin,

The "lot of bogus expressions" in mapleok seem only to occur in the
fricas version. They have long since been fixed in Axiom. If you know
of more errors please let me know.

There are two integral test suites, one based on Bondarenko's
published Maple failures and the other based on Schaums outline.

The Bondarenko test suite was a measure of how well Axiom
handles known Maple failures. More "comparative test suites"
are "in process" against Mathematica, Maple and Maxima.

Tim Lahey is using the Schaums test suite.
The Schaums test suite is part of the CATS (Computer
Algebra Test Suite) which is intended to validate Axiom's results
against known-good, published results. Note that Axiom found
2 errors in the published Schaums results and one error caused by
a bad patch to the integration routines. More "published results"
test suites are "in process" for series.

\start
Date: Sun, 7 Jun 2009 11:01:52 -0500
From: Tim Daly
To: list
Subject: 20090607.03.tpd.patch (tpiezas.input CATS algebraic identities)

T. Piezas has published a book of algebraic identities.
This is the first in a set of CATS tests to exercise Axiom with
those identities.

========================================================================
diff --git a/changelog b/changelog
index 5c96725..0826802 100644
--- a/changelog
+++ b/changelog
@@ -1,7 +1,10 @@
-20090606 tpd src/axiom-website/patches.html 20090607.02.tpd.patch
-20090606 tpd books/bookvol10.4 MAPPKG2 +-> conversion
-20090606 tpd src/axiom-website/patches.html 20090607.01.tpd.patch
-20090606 tpd books/bookvol10.4 MAPPGK1 +-> conversion
+20090607 tpd src/axiom-website/patches.html 20090607.03.tpd.patch
+20090607 tpd src/input/Makefile add tpiezas.input algebraic identities
+20090607 tpd src/input/tpiezas.input CATS tests of algebraic identities
+20090607 tpd src/axiom-website/patches.html 20090607.02.tpd.patch
+20090607 tpd books/bookvol10.4 MAPPKG2 +-> conversion
+20090607 tpd src/axiom-website/patches.html 20090607.01.tpd.patch
+20090607 tpd books/bookvol10.4 MAPPGK1 +-> conversion
 20090606 tpd src/axiom-website/patches.html 20090606.07.tpd.patch
 20090606 tpd books/bookvol10.4 MKUCFUNC +-> conversion
 20090606 tpd src/axiom-website/patches.html 20090606.06.tpd.patch
diff --git a/src/axiom-website/patches.html b/src/axiom-website/patches.html
index 9c71f66..8ec5f5d 100644
--- a/src/axiom-website/patches.html
+++ b/src/axiom-website/patches.html
@@ -1481,5 +1481,7 @@ bookvol10.4 MKUCFUNC +-> conversion<br/>
 bookvol10.4 MAPPGK1 +-> conversion<br/>
 <a href="patches/20090607.02.tpd.patch">20090607.02.tpd.patch</a>
 bookvol10.4 MAPPGK2 +-> conversion<br/>
+<a href="patches/20090607.03.tpd.patch">20090607.03.tpd.patch</a>
+tpieazas.input CATS tests of algebraic identites<br/>
  </body>
 </html>
diff --git a/src/input/Makefile.pamphlet b/src/input/Makefile.pamphlet
index 536385f..f92241d 100644
--- a/src/input/Makefile.pamphlet
+++ b/src/input/Makefile.pamphlet
@@ -384,6 +384,7 @@ REGRES= algaggr.regress algbrbf.regress  algfacob.regress alist.regress  \
     symbol.regress    t111293.regress  table.regress    tancot.regress \
     tanhcoth.regress  tanatan.regress  tbagg.regress    test.regress \
     textfile.regress  torus.regress \
+    tpiezas.regress \
     triglim.regress   tsetcatvermeer.regress            tutchap1.regress \
     typetower.regress void.regress      uniseg.regress \
     unittest1.regress unittest2.regress unittest3.regress unittest4.regress
@@ -692,6 +693,7 @@ FILES= ${OUT}/algaggr.input  ${OUT}/algbrbf.input    ${OUT}/algfacob.input \
        ${OUT}/table.input    ${OUT}/tancot.input     ${OUT}/tanhcoth.input \
        ${OUT}/tanatan.input  ${OUT}/tbagg.input      ${OUT}/test.input \
        ${OUT}/tetra.input    ${OUT}/textfile.input   ${OUT}/tknot.input \
+       ${OUT}/tpiezas.input \
        ${OUT}/tree.input \
        ${OUT}/triglim.input  ${OUT}/tschirn.input ${OUT}/tsetcatbutcher.input \
        ${OUT}/tsetcatchemical.input ${OUT}/tsetcatvermeer.input \
@@ -1049,7 +1051,9 @@ DOCFILES= \
   ${DOC}/tbagg.input.dvi       \
   ${DOC}/test.input.dvi        ${DOC}/tetra.input.dvi      \
   ${DOC}/textfile.input.dvi    ${DOC}/tknot.input.dvi      \
-  ${DOC}/torus.input.dvi       ${DOC}/tree.input.dvi       \
+  ${DOC}/torus.input.dvi \
+  ${DOC}/tpiezas.input.dvi \
+  ${DOC}/tree.input.dvi       \
   ${DOC}/triglim.input.dvi     ${DOC}/tschirn.input.dvi    \
   ${DOC}/tsetcatbutcher.input.dvi    \
   ${DOC}/tsetcatchemical.input.dvi   \
diff --git a/src/input/tpiezas.input.pamphlet b/src/input/tpiezas.input.pamphlet
new file mode 100644
index 0000000..f60ad7e
--- /dev/null
+++ b/src/input/tpiezas.input.pamphlet
@@ -0,0 +1,829 @@
+\documentclass{article}
+\usepackage{axiom}
+\begin{document}
+\title{\$SPAD/src/input tpiezas.input}
+\author{Timothy Daly}
+\maketitle
+\begin{abstract}
+This is from ``A Collection of Algebraic Identities'' by T. Piezas III\cite{1}
+\end{abstract}
+\eject
+\tableofcontents
+\eject
+\section{Part 1. Assorted Identities}
+\begin{chunk}{*}
+)set break resume
+)spool tpiezas.output
+)set message test on
+)set message auto off
+)clear all
+\end{chunk}
+
+\subsection{E. Maillet}
+\[(a+b)^3+(a+c)^3+(a+d)^3+(a-b)^3+(a-c)^3+(a-d)^3 = 6a(a^2+b^2+c^2+d^2)\]
+\begin{chunk}{*} 
+--S 1 of 63
+t1a:=(a+b)^3 + (a+c)^3 + (a+d)^3 + (a-b)^3 + (a-c)^3 + (a-d)^3
+--R 
+--R
+--R            2       2       2     3
+--R   (1)  6a d  + 6a c  + 6a b  + 6a
+--R                                                     Type: Polynomial Integer
+--E 1
+
+--S 2 of 63
+t1b:=6*a*(a^2+b^2+c^2+d^2)
+--R 
+--R
+--R            2       2       2     3
+--R   (2)  6a d  + 6a c  + 6a b  + 6a
+--R                                                     Type: Polynomial Integer
+--E 2
+
+--S 3 of 63
+t1a-t1b
+--R 
+--R
+--R   (3)  0
+--R                                                     Type: Polynomial Integer
+--E 3
+\end{chunk}
+
+\subsection{E. Lucas-Liouville}
+\[\begin{array}{ll}
+(a+b)^k+(a+c)^k+(a+d)^k+(b+c)^k+(b+d)^k+(c+d)^k+\\
+(a-b)^k+(a-c)^k+(a-d)^k+(b-c)^k+(b-d)^k+(c-d)^k
+\end{array}\]
+\[=6(a^2+b^2+c^2+d^2)^{k/2}\quad {\rm\ for\ }k=2,4\]
+\begin{chunk}{*} 
+--S 4 of 63
+t2a(k)==(a+b)^k + (a+c)^k + (a+d)^k + (b+c)^k + (b+d)^k + (c+d)^k +_
+        (a-b)^k + (a-c)^k + (a-d)^k + (b-c)^k + (b-d)^k + (c-d)^k 
+--R 
+--R                                                                   Type: Void
+--E 4
+
+--S 5 of 63
+t2b(k)==6*(a^2+b^2+c^2+d^2)^(k/2)
+--R 
+--R                                                                   Type: Void
+--E 5
+
+--S 6 of 63
+t2a(k)
+--R 
+--R   Compiling function t2a with type Variable k -> Expression Integer 
+--R
+--R   (6)
+--R            k          k          k          k          k          k
+--R     (d + c)  + (d + b)  + (d + a)  + (c + b)  + (c + a)  + (b + a)
+--R   + 
+--R            k            k            k            k            k            k
+--R   (- b + a)  + (- c + b)  + (- c + a)  + (- d + c)  + (- d + b)  + (- d + a)
+--R                                                     Type: Expression Integer
+--E 6
+
+--S 7 of 63
+t2b(k)
+--R 
+--R   Compiling function t2b with type Variable k -> Expression Integer 
+--R
+--R                            k
+--R                            -
+--R           2    2    2    2 2
+--R   (7)  6(d  + c  + b  + a )
+--R                                                     Type: Expression Integer
+--E 7
+
+--S 8 of 63
+t2a(2)
+--R 
+--R   Compiling function t2a with type PositiveInteger -> Polynomial 
+--R      Integer 
+--R
+--R          2     2     2     2
+--R   (8)  6d  + 6c  + 6b  + 6a
+--R                                                     Type: Polynomial Integer
+--E 8
+
+--S 9 of 63
+t2b(2)
+--R 
+--R   Compiling function t2b with type PositiveInteger -> Expression 
+--R      Integer 
+--R
+--R          2     2     2     2
+--R   (9)  6d  + 6c  + 6b  + 6a
+--R                                                     Type: Expression Integer
+--E 9
+
+--S 10 of 63
+t2a(2)-t2b(2)
+--R 
+--R
+--R   (10)  0
+--R                                                     Type: Expression Integer
+--E 10
+
+--S 11 of 63
+t2a(4)
+--R 
+--R
+--R   (11)
+--R     4       2      2      2  2     4       2      2  2     4      2 2     4
+--R   6d  + (12c  + 12b  + 12a )d  + 6c  + (12b  + 12a )c  + 6b  + 12a b  + 6a
+--R                                                     Type: Polynomial Integer
+--E 11
+
+--S 12 of 63
+t2b(4)
+--R 
+--R
+--R   (12)
+--R     4       2      2      2  2     4       2      2  2     4      2 2     4
+--R   6d  + (12c  + 12b  + 12a )d  + 6c  + (12b  + 12a )c  + 6b  + 12a b  + 6a
+--R                                                     Type: Expression Integer
+--E 12
+
+--S 13 of 63
+t2a(4)-t2b(4)
+--R 
+--R
+--R   (13)  0
+--R                                                     Type: Expression Integer
+--E 13
+\end{chunk}
+
+\subsection{Boutin's Identity}
+\[S\pm(x_1\pm x_2\pm \ldots \pm x_k)^k = k!\: 2^{k-1} x_1 x_2 \ldots x_k\]
+where the exterior sign is the product of the interior signs so
+the term is negative if there is an odd number of negative interior signs,
+otherwise positive
+\begin{chunk}{*} 
+
+--S 14 of 63
+t3a1 := (a+b)^2 - (a-b)^2
+--R 
+--R
+--R   (14)  4a b
+--R                                                     Type: Polynomial Integer
+--E 14
+
+--S 15 of 63
+t3b1 := 4*a*b
+--R 
+--R
+--R   (15)  4a b
+--R                                                     Type: Polynomial Integer
+--E 15
+
+--S 16 of 63
+t3a1-t3b1
+--R 
+--R
+--R   (16)  0
+--R                                                     Type: Polynomial Integer
+--E 16
+
+--S 17 of 63
+t3a2 := (a+b+c)^3 - (a-b+c)^3 - (a+b-c)^3 + (a-b-c)^3
+--R 
+--R
+--R   (17)  24a b c
+--R                                                     Type: Polynomial Integer
+--E 17
+
+--S 18 of 63
+t3b2 := 24*a*b*c
+--R 
+--R
+--R   (18)  24a b c
+--R                                                     Type: Polynomial Integer
+--E 18
+
+--S 19 of 63
+t3a2-t3b2
+--R 
+--R
+--R   (19)  0
+--R                                                     Type: Polynomial Integer
+--E 19
+
+--S 20 of 63
+t3a3 := (a+b+c+d)^4 - (a-b+c+d)^4 - (a+b-c+d)^4 - (a+b+c-d)^4 
+      + (a-b-c+d)^4 + (a-b+c-d)^4 + (a+b-c-d)^4 - (a-b-c-d)^4
+--R 
+--R
+--R   (20)  192a b c d
+--R                                                     Type: Polynomial Integer
+--E 20
+
+--S 21 of 63
+t3b3 := 192*a*b*c*d
+--R 
+--R
+--R   (21)  192a b c d
+--R                                                     Type: Polynomial Integer
+--E 21
+
+--S 22 of 63
+t3a3-t3b3
+--R 
+--R
+--R   (22)  0
+--R                                                     Type: Polynomial Integer
+--E 22
+
+\end{chunk}
+We can create the general case using some functions.
+
+The ``bitlist'' function creates a list of the sign changes needed
+to form each term. If a term is 4 variables long we need all possible
+combinations of 3 signs. In order to generate this we create a list
+of all possible bit combinations of the numbers from 0 to $2^{n-1}-1$,
+which for the case of 4 would be from 0 to 7:
+\begin{verbatim}
+   [[0,0,0],[0,0,1],[0,1,0],[0,1,1],[1,0,0],[1,0,1],[1,1,0],[1,1,1]]
+\end{verbatim}
+We do this using an outer loop to generate the correct number of lists
+and an inner loop to create each list.
+\begin{chunk}{*}
+--S 23 of 63
+bitlist(size:Integer):List List INT ==
+  result:List List INT:=[]
+  size <= 1 => result
+  bound:PI:=size-1
+  bitlength:INT:=2^bound
+  for i in (bitlength-1)::PI..0 by -1 repeat
+    t1:=[1::INT for k in 1..bound]
+    for j in 0..(#t1-1) repeat 
+      if not bit?(i,j) then t1(bound-j):=0
+    result:=cons(t1,result)
+  result
+--R 
+--R   Function declaration bitlist : Integer -> List List Integer has been
+--R      added to workspace.
+--R                                                                   Type: Void
+--E 23
+
+\end{chunk}
+These are the test cases.
+\begin{chunk}{*}
+--S 24 of 63
+bitlist(1)
+--R 
+--R   Compiling function bitlist with type Integer -> List List Integer 
+--R
+--R   (24)  []
+--R                                                      Type: List List Integer
+--E 24
+
+--S 25 of 63
+bitlist(2)
+--R 
+--I   Compiling function G7153 with type Integer -> Boolean 
+--I   Compiling function G7332 with type NonNegativeInteger -> Boolean 
+--R
+--R   (25)  [[0],[1]]
+--R                                                      Type: List List Integer
+--E 25
+
+--S 26 of 63
+bitlist(3)
+--R 
+--R
+--R   (26)  [[0,0],[0,1],[1,0],[1,1]]
+--R                                                      Type: List List Integer
+--E 26
+
+--S 27 of 63
+bitlist(4)
+--R 
+--R
+--R   (27)  [[0,0,0],[0,0,1],[0,1,0],[0,1,1],[1,0,0],[1,0,1],[1,1,0],[1,1,1]]
+--R                                                      Type: List List Integer
+--E 27
+
+\end{chunk}
+
+Now we need a function to generate a list of subscripted symbols
+\begin{chunk}{*}
+--S 28 of 63
+symgen(var:Symbol,size:PI):List Symbol == [var.[i] for i in size..1 by -1]
+--R 
+--R   Function declaration symgen : (Symbol,PositiveInteger) -> List 
+--R      Symbol has been added to workspace.
+--R                                                                   Type: Void
+--E 28
+
+--S 29 of 63
+symgen('a,4)
+--R 
+--R   Compiling function symgen with type (Symbol,PositiveInteger) -> List
+--R      Symbol 
+--R
+--R   (29)  [a ,a ,a ,a ]
+--R           4  3  2  1
+--R                                                            Type: List Symbol
+--E 29
+
+\end{chunk}
+
+This is a function to generate the terms for Boutin's Identity.
+Each term is of the form:
+\[sign * (x_n\pm x_{n-1}\\pm \ldots \pm x_1)^n\]
+where the sign is negative if the number of minus signs in the term is odd
+\begin{chunk}{*}
+--S 30 of 63
+term(size:PI,signs:List INT):Polynomial Integer ==
+  syms:=symgen('x,size)
+  t1:POLY(INT):=first syms
+  sign:INT:=if odd? size then 1 else -1
+  for i in 1..#signs repeat
+    if (signs.i = 0)
+      then t1:=t1-syms.(i+1)
+       else ( t1:=t1+syms.(i+1) ; sign:=sign*-1 )
+  sign*(t1^size)
+--R 
+--R   Function declaration term : (PositiveInteger,List Integer) -> 
+--R      Polynomial Integer has been added to workspace.
+--R                                                                   Type: Void
+--E 30
+\end{chunk}
+Now we test it by hand for the case $n=4$
+\begin{chunk}{*}
+
+--S 31 of 63
+factor term(4,[0,0,0])
+--R 
+--R   Compiling function term with type (PositiveInteger,List Integer) -> 
+--R      Polynomial Integer 
+--R
+--R                              4
+--R   (31)  - (x  - x  - x  - x )
+--R             4    3    2    1
+--R                                            Type: Factored Polynomial Integer
+--E 31
+
+--S 32 of 63
+factor term(4,[0,0,1])
+--R 
+--R
+--R                            4
+--R   (32)  (x  - x  - x  + x )
+--R           4    3    2    1
+--R                                            Type: Factored Polynomial Integer
+--E 32
+
+--S 33 of 63
+factor term(4,[0,1,0])
+--R 
+--R
+--R                            4
+--R   (33)  (x  - x  + x  - x )
+--R           4    3    2    1
+--R                                            Type: Factored Polynomial Integer
+--E 33
+
+--S 34 of 63
+factor term(4,[0,1,1])
+--R 
+--R
+--R                              4
+--R   (34)  - (x  - x  + x  + x )
+--R             4    3    2    1
+--R                                            Type: Factored Polynomial Integer
+--E 34
+
+--S 35 of 63
+factor term(4,[1,0,0])
+--R 
+--R
+--R                            4
+--R   (35)  (x  + x  - x  - x )
+--R           4    3    2    1
+--R                                            Type: Factored Polynomial Integer
+--E 35
+
+--S 36 of 63
+factor term(4,[1,0,1])
+--R 
+--R
+--R                              4
+--R   (36)  - (x  + x  - x  + x )
+--R             4    3    2    1
+--R                                            Type: Factored Polynomial Integer
+--E 36
+
+--S 37 of 63
+factor term(4,[1,1,0])
+--R 
+--R
+--R                              4
+--R   (37)  - (x  + x  + x  - x )
+--R             4    3    2    1
+--R                                            Type: Factored Polynomial Integer
+--E 37
+
+--S 38 of 63
+factor term(4,[1,1,1])
+--R 
+--R
+--R                            4
+--R   (38)  (x  + x  + x  + x )
+--R           4    3    2    1
+--R                                            Type: Factored Polynomial Integer
+--E 38
+
+\end{chunk}
+And we test combining the terms using the bitlist function call.
+\begin{chunk}{*}
+--S 39 of 63
+map(x+->factor(term(1,x)),bitlist(1))
+--R 
+--R
+--R   (39)  []
+--R                                       Type: List Factored Polynomial Integer
+--E 39
+
+--S 40 of 63
+map(x+->factor(term(2,x)),bitlist(2))
+--R 
+--R
+--R                     2          2
+--R   (40)  [- (x  - x ) ,(x  + x ) ]
+--R              2    1     2    1
+--R                                       Type: List Factored Polynomial Integer
+--E 40
+
+--S 41 of 63
+map(x+->factor(term(3,x)),bitlist(3))
+--R 
+--R
+--R                        3                 3                 3               3
+--R   (41)  [(x  - x  - x ) ,- (x  - x  + x ) ,- (x  + x  - x ) ,(x  + x  + x ) ]
+--R            3    2    1       3    2    1       3    2    1     3    2    1
+--R                                       Type: List Factored Polynomial Integer
+--E 41
+
+--S 42 of 63
+map(x+->factor(term(4,x)),bitlist(4))
+--R 
+--R
+--R   (42)
+--R                         4                     4                     4
+--R   [- (x  - x  - x  - x ) , (x  - x  - x  + x ) , (x  - x  + x  - x ) ,
+--R        4    3    2    1      4    3    2    1      4    3    2    1
+--R                         4                     4                       4
+--R    - (x  - x  + x  + x ) , (x  + x  - x  - x ) , - (x  + x  - x  + x ) ,
+--R        4    3    2    1      4    3    2    1        4    3    2    1
+--R                         4                     4
+--R    - (x  + x  + x  - x ) , (x  + x  + x  + x ) ]
+--R        4    3    2    1      4    3    2    1
+--R                                       Type: List Factored Polynomial Integer
+--E 42
+
+\end{chunk}
+Next we have two functions, one to create a generic left hand side
+of Boutin's Identity:
+\begin{chunk}{*}
+--S 43 of 63
+lhs(size:PI):POLY(INT) ==
+  size = 1 => 0::POLY(INT)
+  reduce(+,map(x+->term(size,x),bitlist(size)))
+--R 
+--R   Function declaration lhs : PositiveInteger -> Polynomial Integer has
+--R      been added to workspace.
+--R                                                                   Type: Void
+--E 43
+
+\end{chunk}
+and one to create a generic right hand side of Boutin's Identity:
+\begin{chunk}{*}
+--S 44 of 63
+rhs(size:PI):POLY(INT) == 
+ size = 1 => 0
+ bound:PI:=(size-1)
+ factorial(size)*2^bound*reduce(*,symgen('x,size))@POLY(INT)
+--R 
+--R   Function declaration rhs : PositiveInteger -> Polynomial Integer has
+--R      been added to workspace.
+--R                                                                   Type: Void
+--E 44
+
+\end{chunk}
+Now we look at the case where $n=2$, showing the factors, the left
+hand side, the right hand side, and the fact that they are equal
+by subtraction
+\begin{chunk}{*}
+--S 45 of 63
+map(x+->factor term(2,x),bitlist(2))
+--R 
+--R
+--R                     2          2
+--R   (45)  [- (x  - x ) ,(x  + x ) ]
+--R              2    1     2    1
+--R                                       Type: List Factored Polynomial Integer
+--E 45
+
+--S 46 of 63
+lhs(2)
+--R 
+--R   Compiling function lhs with type PositiveInteger -> Polynomial 
+--R      Integer 
+--R
+--R   (46)  4x x
+--R           1 2
+--R                                                     Type: Polynomial Integer
+--E 46
+
+--S 47 of 63
+rhs(2)
+--R 
+--R   Compiling function rhs with type PositiveInteger -> Polynomial 
+--R      Integer 
+--R
+--R   (47)  4x x
+--R           1 2
+--R                                                     Type: Polynomial Integer
+--E 47
+
+--S 48 of 63
+lhs(2)-rhs(2)
+--R 
+--R
+--R   (48)  0
+--R                                                     Type: Polynomial Integer
+--E 48
+
+\end{chunk}
+Now we look at the case where $n=3$, showing the factors, the left
+hand side, the right hand side, and the fact that they are equal
+by subtraction
+\begin{chunk}{*}
+--S 49 of 63
+map(x+->factor term(3,x),bitlist(3))
+--R 
+--R
+--R                        3                 3                 3               3
+--R   (49)  [(x  - x  - x ) ,- (x  - x  + x ) ,- (x  + x  - x ) ,(x  + x  + x ) ]
+--R            3    2    1       3    2    1       3    2    1     3    2    1
+--R                                       Type: List Factored Polynomial Integer
+--E 49
+
+--S 50 of 63
+lhs(3)
+--R 
+--R
+--R   (50)  24x x x
+--R            1 2 3
+--R                                                     Type: Polynomial Integer
+--E 50
+
+--S 51 of 63
+rhs(3)
+--R 
+--R
+--R   (51)  24x x x
+--R            1 2 3
+--R                                                     Type: Polynomial Integer
+--E 51
+
+--S 52 of 63
+lhs(3)-rhs(3)
+--R 
+--R
+--R   (52)  0
+--R                                                     Type: Polynomial Integer
+--E 52
+
+\end{chunk}
+Now we look at the case where $n=4$, showing the factors, the left
+hand side, the right hand side, and the fact that they are equal
+by subtraction
+\begin{chunk}{*}
+--S 53 of 63
+map(x+->factor term(4,x),bitlist(4))
+--R 
+--R
+--R   (53)
+--R                         4                     4                     4
+--R   [- (x  - x  - x  - x ) , (x  - x  - x  + x ) , (x  - x  + x  - x ) ,
+--R        4    3    2    1      4    3    2    1      4    3    2    1
+--R                         4                     4                       4
+--R    - (x  - x  + x  + x ) , (x  + x  - x  - x ) , - (x  + x  - x  + x ) ,
+--R        4    3    2    1      4    3    2    1        4    3    2    1
+--R                         4                     4
+--R    - (x  + x  + x  - x ) , (x  + x  + x  + x ) ]
+--R        4    3    2    1      4    3    2    1
+--R                                       Type: List Factored Polynomial Integer
+--E 53
+
+--S 54 of 63
+lhs(4)
+--R 
+--R
+--R   (54)  192x x x x
+--R             1 2 3 4
+--R                                                     Type: Polynomial Integer
+--E 54
+
+--S 55 of 63
+rhs(4)
+--R 
+--R
+--R   (55)  192x x x x
+--R             1 2 3 4
+--R                                                     Type: Polynomial Integer
+--E 55
+
+--S 56 of 63
+lhs(4)-rhs(4)
+--R 
+--R
+--R   (56)  0
+--R                                                     Type: Polynomial Integer
+--E 56
+
+\end{chunk}
+\subsection{Lagrange's Identity}
+\[\left(\sum a_k^2\right) \left(\sum b_k^2\right) =
+\left(\sum a_k b_k\right)^2 + \sum \left(a_k b_j - a_j b_k\right)^2\]
+
+We need two symbol generation functions. First, we need to generate
+the units for the term
+\[\left(\sum a_k b_k\right)^2\]
+so that \verb|symgen2('a,'b,4)| results in
+\begin{verbatim}
+ [a b ,a b ,a b ,a b ]
+   4 4  3 3  2 2  1 1
+\end{verbatim}
+\begin{chunk}{*}
+--S 57 of 63
+symgen2(var1:Symbol,var2:Symbol,size:PI):List POLY INT ==
+  [(var1.[i]*var2.[i]) for i in size..1 by -1]
+--R 
+--R   Function declaration symgen2 : (Symbol,Symbol,PositiveInteger) -> 
+--R      List Polynomial Integer has been added to workspace.
+--R                                                                   Type: Void
+--E 57
+
+--S 58 of 63
+symgen2('a,'b,4)
+--R 
+--R   Compiling function symgen2 with type (Symbol,Symbol,PositiveInteger)
+--R       -> List Polynomial Integer 
+--R
+--R   (58)  [a b ,a b ,a b ,a b ]
+--R           4 4  3 3  2 2  1 1
+--R                                                Type: List Polynomial Integer
+--E 58
+
+\end{chunk}
+Next we need to generate the units for the term
+\[\sum \left(a_k b_j - a_j b_k\right)^2\]
+so that \verb|symgen3('a,'b,4)| results in
+\begin{verbatim}
+   [0, a b  - a b , a b  - a b , a b  - a b , 0, a b  - a b , a b  - a b , 0,
+        3 4    4 3   2 4    4 2   1 4    4 1      2 3    3 2   1 3    3 1
+    a b  - a b , 0]
+     1 2    2 1
+\end{verbatim}
+\begin{chunk}{*}
+--S 59 of 63
+symgen3(var1:Symbol,var2:Symbol,size:PI):LIST POLY INT == 
+  result:LIST(POLY(INT)):=[]
+  for j in 1..size repeat
+    for k in 1..j repeat
+      p:POLY(INT):=var1.[k]*var2.[j]-var1.[j]*var2.[k]
+      result:=cons(p,result)
+  result
+--R 
+--R   Function declaration symgen3 : (Symbol,Symbol,PositiveInteger) -> 
+--R      List Polynomial Integer has been added to workspace.
+--R                                                                   Type: Void
+--E 59
+
+--S 60 of 63
+symgen3('a,'b,4)
+--R 
+--R   Compiling function symgen3 with type (Symbol,Symbol,PositiveInteger)
+--R       -> List Polynomial Integer 
+--R
+--R   (60)
+--R   [0, a b  - a b , a b  - a b , a b  - a b , 0, a b  - a b , a b  - a b , 0,
+--R        3 4    4 3   2 4    4 2   1 4    4 1      2 3    3 2   1 3    3 1
+--R    a b  - a b , 0]
+--R     1 2    2 1
+--R                                                Type: List Polynomial Integer
+--E 60
+
+\end{chunk}
+Now we are ready to generate and test the Lagrange Identities.
+This function will take a given size and print all of the intermediate
+working results. It eventually creates the left hand side (lhs) and
+the right hand side (rhs) and subtracts them to show that they are equal.
+\begin{chunk}{*}
+--S 61 of 63
+lagrange(size:PI):POLY(INT) ==
+  t1:=factor reduce(+,map(x+->x^2,symgen('a,size)))
+  print ["t1=",t1]
+  t2:=factor reduce(+,map(x+->x^2,symgen('b,size)))
+  print ["t2=",t2]
+  t3:=factor reduce(+,symgen2('a,'b,size))^2
+  print ["t3=",t3]
+  t4:=factor reduce(+,map(x+->x^2,symgen3('a,'b,size)))
+  print ["t4=",t4]
+  lhs:=t1*t2
+  print ["lhs=",lhs]
+  rhs:=t3+t4
+  print ["rhs=",rhs]
+  lhs-rhs
+--R 
+--R   Function declaration lagrange : PositiveInteger -> Polynomial 
+--R      Integer has been added to workspace.
+--R                                                                   Type: Void
+--E 61
+
+\end{chunk}
+Now we test it for the case $n=2$
+\begin{chunk}{*}
+--S 62 of 63
+lagrange(2)
+--R 
+--R   Function definition for lhs is being overwritten.
+--R   Function definition for rhs is being overwritten.
+--R   Compiling function lagrange with type PositiveInteger -> Polynomial 
+--R      Integer 
+--R            2     2
+--R   ["t1=",a   + a  ]
+--R           2     1
+--R            2     2
+--R   ["t2=",b   + b  ]
+--R           2     1
+--R                       2
+--R   ["t3=",(a b  + a b ) ]
+--R            2 2    1 1
+--R                       2
+--R   ["t4=",(a b  - a b ) ]
+--R            1 2    2 1
+--R              2     2    2     2
+--R   ["lhs=",(a   + a  )(b   + b  )]
+--R             2     1    2     1
+--R              2     2   2      2     2   2
+--R   ["rhs=",(a   + a  )b   + (a   + a  )b  ]
+--R             2     1   2      2     1   1
+--R
+--R   (62)  0
+--R                                                     Type: Polynomial Integer
+--E 62
+
+\end{chunk}
+Now we test it for the case $n=3$
+\begin{chunk}{*}
+--S 63 of 63
+lagrange(3)
+--R 
+--R            2     2     2
+--R   ["t1=",a   + a   + a  ]
+--R           3     2     1
+--R            2     2     2
+--R   ["t2=",b   + b   + b  ]
+--R           3     2     1
+--R                              2
+--R   ["t3=",(a b  + a b  + a b ) ]
+--R            3 3    2 2    1 1
+--R   ["t4=",
+--R
+--R          2     2   2                                2     2   2
+--R       (a   + a  )b   + (- 2a a b  - 2a a b )b  + (a   + a  )b   - 2a a b b
+--R         2     1   3         2 3 2     1 3 1  3     3     1   2      1 2 1 2
+--R     + 
+--R          2     2   2
+--R       (a   + a  )b
+--R         3     2   1
+--R     ]
+--R              2     2     2    2     2     2
+--R   ["lhs=",(a   + a   + a  )(b   + b   + b  )]
+--R             3     2     1    3     2     1
+--R              2     2     2   2      2     2     2   2      2     2     2   2
+--R   ["rhs=",(a   + a   + a  )b   + (a   + a   + a  )b   + (a   + a   + a  )b  ]
+--R             3     2     1   3      3     2     1   2      3     2     1   1
+--R
+--R   (63)  0
+--R                                                     Type: Polynomial Integer
+--E 63
+
+)spool 
+)lisp (bye)
+ 
+\end{chunk}
+\eject
+\begin{thebibliography}{99}
+\bibitem{1} T. Piezas, ``A Collection of Algebraic Identities''\\
+{\bf http://sites.google.com/site/tpiezas/001}
+\end{thebibliography}
+\end{document}

\start
Date: Sun, 7 Jun 2009 11:41:40 -0700 (PDT)
From: Tim Daly
To: Titus Piezas
Subject: Re: A Collection of Algebraic Identities

On Jun 4, 12:35=A0pm, tpie...@gmail.com wrote:
> Hello all,
>
> Here's a nice identity:
>
> (p+q)^4 + (r-s)^4 = (p-q)^4 + (r+s)^4
>
> where {p,q,r,s} = {a^7+a^5-2a^3+a, 3a^2, a^6-2a^4+a^2+1, 3a^5}
>
> For similar stuff, you may be interested in "A Collection of Algebraic
> Identities":
>
> http://sites.google.com/site/tpiezas/Home
>
> It's a 200+ page book I wrote and made available there. =A0It starts
> with the basics with 2nd powers and goes up to 8th and higher powers.
> Enjoy.
>
> - Titus

I cannot verify the identity on page 001, Form 4, by S.Realis
Is it correct as printed?

\start
Date: Sun, 7 Jun 2009 17:41:53 -0700 (PDT)
From: Tim Daly
To: Titus Piezas
Subject: Re: A Collection of Algebraic Identities

On Jun 4, 12:35=A0pm, tpie...@gmail.com wrote:
> Hello all,
>
> Here's a nice identity:
>
> (p+q)^4 + (r-s)^4 = (p-q)^4 + (r+s)^4
>
> where {p,q,r,s} = {a^7+a^5-2a^3+a, 3a^2, a^6-2a^4+a^2+1, 3a^5}
>
> For similar stuff, you may be interested in "A Collection of Algebraic
> Identities":
>
> http://sites.google.com/site/tpiezas/Home
>
> It's a 200+ page book I wrote and made available there. =A0It starts
> with the basics with 2nd powers and goes up to 8th and higher powers.
> Enjoy.
>
> - Titus

on page http://sites.google.com/site/tpiezas/002 you state:

[55,48,73}, {45,28,43}, ....

as pythagorean triples

but it should read

{55,48,73}, {45,28,53} ....

Tim Daly

\start
Date: Sun, 7 Jun 2009 19:20:03 -0700 (PDT)
From: Tim Daly
To: Titus Piezas
Subject: Re: A Collection of Algebraic Identities

On Jun 4, 12:35=A0pm, tpie...@gmail.com wrote:
> Hello all,
>
> Here's a nice identity:
>
> (p+q)^4 + (r-s)^4 = (p-q)^4 + (r+s)^4
>
> where {p,q,r,s} = {a^7+a^5-2a^3+a, 3a^2, a^6-2a^4+a^2+1, 3a^5}
>
> For similar stuff, you may be interested in "A Collection of Algebraic
> Identities":
>
> http://sites.google.com/site/tpiezas/Home
>
> It's a 200+ page book I wrote and made available there. =A0It starts
> with the basics with 2nd powers and goes up to 8th and higher powers.
> Enjoy.
>
> - Titus

on page http://sites.google.com/site/tpiezas/002

In the section on Euler you state:

(x+1/x)^2 + (y+1/y)^2 = z^2

but you never give a value for z

\start
Date: Sun, 7 Jun 2009 19:59:45 -0700 (PDT)
From: Tim Daly
To: Titus Piezas
Subject: Re: A Collection of Algebraic Identities

On Jun 4, 12:35=A0pm, tpie...@gmail.com wrote:
> Hello all,
>
> Here's a nice identity:
>
> (p+q)^4 + (r-s)^4 = (p-q)^4 + (r+s)^4
>
> where {p,q,r,s} = {a^7+a^5-2a^3+a, 3a^2, a^6-2a^4+a^2+1, 3a^5}
>
> For similar stuff, you may be interested in "A Collection of Algebraic
> Identities":
>
> http://sites.google.com/site/tpiezas/Home
>
> It's a 200+ page book I wrote and made available there. =A0It starts
> with the basics with 2nd powers and goes up to 8th and higher powers.
> Enjoy.
>
> - Titus

On the page http://sites.google.com/site/tpiezas/002

Theorem: If p^2 + (p+1)^2 = r^2, then q^2 + (q+1)^2 = (p+q+r+1)^2
where q = 3p+2r+1

q:=3p+2r+1
r:=sqrt(p^2 + (p+1)^2)
q^2 + (q+1)^2 - (p+q+r+1)^2 == (-4r -8p -4)sqrt(2p^2+2p+1)+4r^2+(8p+4)
r

which is clearly not zero. What am I missing?

Tim Daly

\start
Date: Tue, 9 Jun 2009 05:26:13 -0600
From: Titus Piezas
To: Tim Daly
Subject: Re: A Collection of Algebraic Identities

Hello Tim,

Thank you for the interest.  I just moved to Canada and I am still sorting
out all my stuff.  I will get back to your questions in a few days.  :-)

-Tito

On Sun, Jun 7, 2009 at 8:59 PM, Tim Daly wrote:

> On Jun 4, 12:35 pm, tpie...@gmail.com wrote:
> > Hello all,
> >
> > Here's a nice identity:
> >
> > (p+q)^4 + (r-s)^4 = (p-q)^4 + (r+s)^4
> >
> > where {p,q,r,s} = {a^7+a^5-2a^3+a, 3a^2, a^6-2a^4+a^2+1, 3a^5}
> >
> > For similar stuff, you may be interested in "A Collection of Algebraic
> > Identities":
> >
> > http://sites.google.com/site/tpiezas/Home
> >
> > It's a 200+ page book I wrote and made available there.  It starts
> > with the basics with 2nd powers and goes up to 8th and higher powers.
> > Enjoy.
> >
> > - Titus
>
> On the page http://sites.google.com/site/tpiezas/002
>
> Theorem: If p^2 + (p+1)^2 = r^2, then q^2 + (q+1)^2 = (p+q+r+1)^2
> where q = 3p+2r+1
>
> q:=3p+2r+1
> r:=sqrt(p^2 + (p+1)^2)
> q^2 + (q+1)^2 - (p+q+r+1)^2 == (-4r -8p -4)sqrt(2p^2+2p+1)+4r^2+(8p+4)
> r
>
> which is clearly not zero. What am I missing?
>
> Tim Daly

\start
Date: Sat, 13 Jun 2009 21:38:15 -0400
From: Tim Daly
To: list
Subject: PostDoc Position

Research team: Tools for Proofs, MSR-INRIA Joint Centre

The Microsoft Research-INRIA Joint Centre is offering a 2-year
position for a post-doctoral researcher to work on a proof development
environment for TLA+ in the Tools for Proofs project-team (see
http://www.msr-inria.inria.fr).

Research Context

TLA+ is a language for formal specifications and proofs designed by
Leslie Lamport.  It is based on first-order logic, set theory,
temporal logic, and a module system.  While the specification part of
TLA+ has existed for over ten years, the proof language is more
recent, and we are developing tools for writing and checking proofs.

The main program of our development environment is called the Proof
Manager (PM).  The PM translates TLA+ source files to low-level proofs
that are checked by Isabelle.  To this end, the PM calls the Zenon
automatic theorem prover to fill in the "trivial" details omitted from
proofs at the source level.  Within the Isabelle framework we have an
axiomatization of TLA+ (Isabelle/TLA+).  Isabelle provides high
assurance by checking all the proofs provided by the user or by Zenon.
The PM also has an interface to SMT solvers, which provides a stronger
automatic prover, but with lower assurance of correctness.

The current version of the PM handles only the "action" part of TLA+:
first-order formulas with primed and unprimed variables. Because
Isabelle considers a variable to be unrelated to its primed version,
the PM can translate first-order formulas to first-order formulas,
without the overhead associated with an encoding of temporal logic
into first-order logic.  This part of TLA+ is already useful for
proving safety properties.

Description of the activity of the post-doc

The task devoted to the post-doc will be to extend the proof manager
to deal with the temporal part of TLA+.  To this end, he or she will
have to define and implement a new translation into Isabelle to handle
the temporal operators in a way that enables the use of TLA+ proof
rules whose hypotheses include both temporal-logic formulas and
non-temporal theorems proved with the simple translation.

Skills and profile of the candidate

We are looking for a candidate with skills in some or all of the
following subjects: parsing and compilation, logic and set theory,
Isabelle, OCaml, Eclipse and Java.  Moreover, the applicant must have
a good command of the English language.

Location

The Microsoft Research-INRIA Joint Centre is located on the Campus of
INRIA Futurs, in South part of Paris, near the Le-Guichet RER
station. The Tools for Proofs project-team is composed of Damien
Doligez, Leslie Lamport and Stephan Merz.

Ideally, the candidate will start working in september or october, but
we can accomodate a later date.

Contact

Candidates should send a resume and the name and e-mail address of one
or two references to Damien Doligez <damien.doligez@inria.fr>.

\start
Date: Tue, 16 Jun 2009 06:19:33 -0400
From: Tim Daly
To: Arnold Doray
Subject: Re: [Axiom-mail] Coersion error

Arnold Doray wrote:
> I'm trying to create a set of orthogonal polynomials using the
> Gram-Schmidt process, but I hit a problem:
>
> dot(f,g) == integrate(f*g*x^2,x=-1..1)
> proj(f,g) == dot(f,g)*f/dot(f,f)
>
> p0 := 1
> p1 := x - proj(p0,x)
> p2 := x^2 - proj(p0,x^2) - proj(p1,x^2)
>
> p0 and p1 evaluate correctly, but p2 hits this error:
>
> ; (DEFUN |*2;dot;5;frame1394| ...) is being compiled.
> ;; The variable |*2;dot;5;frame1394;MV| is undefined.
> ;; The compiler will assume this variable is a global.
>    Internal Error
>    The function coerce with signature OrderedCompletion Integer ->
>       Expression OrderedCompletion Integer is missing from domain
>       Expression(OrderedCompletion (Integer))
>
> I've also tried to define p(n) as a recursive function like so:
>
> p(0) == 1
> p(n | n > 0) == x^n - sum(proj(p(k),x^n),k=0..n-1)
>
> But get a stack overflow: (eg, evaluating p(1))
>
>    OpenAxiom will attempt to step through and interpret the code.
>    Cannot compile map: proj
>    We will attempt to interpret the code.
>    Cannot compile map: p
>    We will attempt to interpret the code.
>
>    >> System error:
>    Bind stack overflow.
>
> I would appreciate any pointers where I am going wrong. I'm an Axiom
> newbie. These calculations were done using open-axiom 1.2.1
>

You are not doing anything wrong. The error message says that there is
a missing function (coerce) from one domain to another. I will look at
the problem and get back to you.

\start
Date: Tue, 16 Jun 2009 17:40:51 -0400
From: Tim Daly
To: Arnold Doray
Subject: Re: [Axiom-mail] Re: Coersion error

Your initial report showed the problem from Open-Axiom which is not
the Axiom project. What command line did you use to start Open-Axiom?

Your problem is also in Axiom so it is listed as a valid bug report.
It has been assigned bug number 7198.

Tim

Arnold Doray wrote:
> This problem persists in "original" Axiom compiled from the latest
> "Gold" source. My apologies for the confusion -AD
>
>
> On Tue, 2009-06-16 at 16:20 +0800, Arnold Doray wrote:
>   
>> I'm trying to create a set of orthogonal polynomials using the
>> Gram-Schmidt process, but I hit a problem:
>>
>> dot(f,g) == integrate(f*g*x^2,x=-1..1)
>> proj(f,g) == dot(f,g)*f/dot(f,f)
>>
>> p0 := 1
>> p1 := x - proj(p0,x)
>> p2 := x^2 - proj(p0,x^2) - proj(p1,x^2)
>>
>> p0 and p1 evaluate correctly, but p2 hits this error:
>>
>> ; (DEFUN |*2;dot;5;frame1394| ...) is being compiled.
>> ;; The variable |*2;dot;5;frame1394;MV| is undefined.
>> ;; The compiler will assume this variable is a global.
>>    Internal Error
>>    The function coerce with signature OrderedCompletion Integer ->
>>       Expression OrderedCompletion Integer is missing from domain
>>       Expression(OrderedCompletion (Integer))

\start
Date: Tue, 16 Jun 2009 17:45:40 -0400
From: Tim Daly
To: Arnold Doray
Subject: Re: [Axiom-mail] Problem with real/imag/conjugate

This one is queued as bug number 7199.

When you say the latest "Gold" sources can you tell me the
result of the "Version" and "Timestamp" lines from the Axiom banner?
Where did you get the sources?

Arnold Doray wrote:
> I get the wrong answer for real/imag for some forms of complex numbers.
> For example:
>
> a := (-1*%i)^(1/2) 
>
> b := (%i)^(3/2)
>
> are both equivalent, but imag/real gives complex (and incorrect) answers
> for "a" (ie, real(a) and imag(a) are both complex), but I get the right
> answers for "b". Also "conjugate" fails on both with an error message.
>
> Am I missing something here? 
>
> I am using Axiom compiled from the latest "Gold" source. 

\start
Date: Thu, 18 Jun 2009 01:08:24 -0400
From: Bill Page
To: list
Subject: re: [Axiom-mail] Problem with real/imag/conjugate
Cc: Arnold Doray

Tim,

I think the following patch fixes this problem but I have not yet done
very extensive testing. It might well have some impact on results in
the regression tests.

The patch is against open-axiom sources so you might have to apply it
manually but I do not think this code has changed much in other
versions.

See also comments here:

https://sourceforge.net/tracker/?func=detail&atid=984524&aid=2806053&group_id3172

----

wspage@debian:~$ svn diff ~/open-axiom-src/src/algebra > itrigmnp.patch
wspage@debian:~$ cat itrigmnp.patch

Index: /home/wspage/open-axiom-src/src/algebra/efstruc.spad.pamphlet
===================================================================
--- /home/wspage/open-axiom-src/src/algebra/efstruc.spad.pamphlet	(revision
1216)
+++ /home/wspage/open-axiom-src/src/algebra/efstruc.spad.pamphlet	(working copy)
@@ -545,6 +545,7 @@
     macro NTHR == 'nthRoot
     ker2explogs: (KG, List KG, List SY) -> FG
     smp2explogs: (PG, List KG, List SY) -> FG
+    nthroot:     (GF,GF) -> GF
     supexp     : (UP, GF, GF, Z) -> GF
     GR2GF      : GR -> GF
     GR2F       : GR -> F
@@ -626,13 +627,23 @@
       map(explogs2trigs(#1::FG),GR2GF, p)$PolynomialCategoryLifting(
                                     IndexedExponents KG, KG, GR, PG, GF)

-    explogs2trigs f ==
-      (m := mainKernel f) case "failed" =>
+    nthroot(a:GF,n:GF):GF ==
+      r := nthRoot(sqrt(norm(a)),retract(n)@Z)
+      e := exp(complex(0, 1)*argument(a)/n)
+      r*e
+
+    explogs2trigs(f:FG):GF ==
+      m := mainKernel f
+      m case "failed" =>
         GR2GF(retract(numer f)@GR) / GR2GF(retract(denom f)@GR)
-      op  := operator(operator(k := m::KG))$F
+      k := m::KG
+      op  := operator(operator(k))$F
       arg := [explogs2trigs x for x in argument k]
       num := univariate(numer f, k)
       den := univariate(denom f, k)
+      is?(op,'nthRoot) =>
+        h := nthroot(first arg, second arg)
+        supexp(num,h,0,0)/supexp(den,h,0,0)
       is?(op,'exp) =>
         e  := exp real first arg
         y  := imag first arg

wspage@debian:~$

----

Regards,
Bill Page.

On Tue, Jun 16, 2009 at 5:45 PM, Tim DalyTim Daly wrote:
> This one is queued as bug number 7199.
>
> When you say the latest "Gold" sources can you tell me the
> result of the "Version" and "Timestamp" lines from the Axiom banner?
> Where did you get the sources?
>
> Tim
>
>
> Arnold Doray wrote:
>>
>> I get the wrong answer for real/imag for some forms of complex numbers.
>> For example:
>>
>> a := (-1*%i)^(1/2)
>> b := (%i)^(3/2)
>>
>> are both equivalent, but imag/real gives complex (and incorrect) answers
>> for "a" (ie, real(a) and imag(a) are both complex), but I get the right
>> answers for "b". Also "conjugate" fails on both with an error message.
>>
>> Am I missing something here?
>> I am using Axiom compiled from the latest "Gold" source.
>> Thanks,
>> Arnold
>>

--000e0cd4879cb7fe45046c98654e

SW5kZXg6IC9ob21lL3dzcGFnZS9vcGVuLWF4aW9tLXNyYy9zcmMvYWxnZWJyYS9lZnN0cnVjLnNw
YWQucGFtcGhsZXQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PQotLS0gL2hvbWUvd3NwYWdlL29wZW4tYXhpb20tc3JjL3Ny
Yy9hbGdlYnJhL2Vmc3RydWMuc3BhZC5wYW1waGxldAkocmV2aXNpb24gMTIxNikKKysrIC9ob21l
L3dzcGFnZS9vcGVuLWF4aW9tLXNyYy9zcmMvYWxnZWJyYS9lZnN0cnVjLnNwYWQucGFtcGhsZXQJ
KHdvcmtpbmcgY29weSkKQEAgLTU0NSw2ICs1NDUsNyBAQAogICAgIG1hY3JvIE5USFIgPT0gJ250
aFJvb3QKICAgICBrZXIyZXhwbG9nczogKEtHLCBMaXN0IEtHLCBMaXN0IFNZKSAtPiBGRwogICAg
IHNtcDJleHBsb2dzOiAoUEcsIExpc3QgS0csIExpc3QgU1kpIC0+IEZHCisgICAgbnRocm9vdDog
ICAgIChHRixHRikgLT4gR0YKICAgICBzdXBleHAgICAgIDogKFVQLCBHRiwgR0YsIFopIC0+IEdG
CiAgICAgR1IyR0YgICAgICA6IEdSIC0+IEdGCiAgICAgR1IyRiAgICAgICA6IEdSIC0+IEYKQEAg
LTYyNiwxMyArNjI3LDIzIEBACiAgICAgICBtYXAoZXhwbG9nczJ0cmlncygjMTo6RkcpLEdSMkdG
LCBwKSRQb2x5bm9taWFsQ2F0ZWdvcnlMaWZ0aW5nKAogICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgSW5kZXhlZEV4cG9uZW50cyBLRywgS0csIEdSLCBQRywgR0YpCiAKLSAgICBl
eHBsb2dzMnRyaWdzIGYgPT0KLSAgICAgIChtIDo9IG1haW5LZXJuZWwgZikgY2FzZSAiZmFpbGVk
IiA9PgorICAgIG50aHJvb3QoYTpHRixuOkdGKTpHRiA9PQorICAgICAgciA6PSBudGhSb290KHNx
cnQobm9ybShhKSkscmV0cmFjdChuKUBaKQorICAgICAgZSA6PSBleHAoY29tcGxleCgwLCAxKSph
cmd1bWVudChhKS9uKQorICAgICAgciplCisKKyAgICBleHBsb2dzMnRyaWdzKGY6RkcpOkdGID09
CisgICAgICBtIDo9IG1haW5LZXJuZWwgZgorICAgICAgbSBjYXNlICJmYWlsZWQiID0+CiAgICAg
ICAgIEdSMkdGKHJldHJhY3QobnVtZXIgZilAR1IpIC8gR1IyR0YocmV0cmFjdChkZW5vbSBmKUBH
UikKLSAgICAgIG9wICA6PSBvcGVyYXRvcihvcGVyYXRvcihrIDo9IG06OktHKSkkRgorICAgICAg
ayA6PSBtOjpLRworICAgICAgb3AgIDo9IG9wZXJhdG9yKG9wZXJhdG9yKGspKSRGCiAgICAgICBh
cmcgOj0gW2V4cGxvZ3MydHJpZ3MgeCBmb3IgeCBpbiBhcmd1bWVudCBrXQogICAgICAgbnVtIDo9
IHVuaXZhcmlhdGUobnVtZXIgZiwgaykKICAgICAgIGRlbiA6PSB1bml2YXJpYXRlKGRlbm9tIGYs
IGspCisgICAgICBpcz8ob3AsJ250aFJvb3QpID0+CisgICAgICAgIGggOj0gbnRocm9vdChmaXJz
dCBhcmcsIHNlY29uZCBhcmcpCisgICAgICAgIHN1cGV4cChudW0saCwwLDApL3N1cGV4cChkZW4s
aCwwLDApCiAgICAgICBpcz8ob3AsJ2V4cCkgPT4KICAgICAgICAgZSAgOj0gZXhwIHJlYWwgZmly
c3QgYXJnCiAgICAgICAgIHkgIDo9IGltYWcgZmlyc3QgYXJnCg==
--000e0cd4879cb7fe45046c98654e--

\start
Date: Thu, 18 Jun 2009 07:01:57 -0400
From: Tim Daly
To: Bill Page
Subject: re: [Axiom-mail] Problem with real/imag/conjugate
Cc: Arnold Doray

Bill Page wrote:
> Tim,
>
> I think the following patch fixes this problem but I have not yet done
> very extensive testing. It might well have some impact on results in
> the regression tests.
>
> The patch is against open-axiom sources so you might have to apply it
> manually but I do not think this code has changed much in other
> versions.
>
> See also comments here:
>
> https://sourceforge.net/tracker/?func=detail&atid=984524&aid=2806053&group_id3172
>
> ----
>
> wspage@debian:~$ svn diff ~/open-axiom-src/src/algebra > itrigmnp.patch
> wspage@debian:~$ cat itrigmnp.patch
>
> Index: /home/wspage/open-axiom-src/src/algebra/efstruc.spad.pamphlet
> ===================================================================
> --- /home/wspage/open-axiom-src/src/algebra/efstruc.spad.pamphlet	(revision
> 1216)
> +++ /home/wspage/open-axiom-src/src/algebra/efstruc.spad.pamphlet	(working copy)
> @@ -545,6 +545,7 @@
>      macro NTHR == 'nthRoot
>      ker2explogs: (KG, List KG, List SY) -> FG
>      smp2explogs: (PG, List KG, List SY) -> FG
> +    nthroot:     (GF,GF) -> GF
>      supexp     : (UP, GF, GF, Z) -> GF
>      GR2GF      : GR -> GF
>      GR2F       : GR -> F
> @@ -626,13 +627,23 @@
>        map(explogs2trigs(#1::FG),GR2GF, p)$PolynomialCategoryLifting(
>                                      IndexedExponents KG, KG, GR, PG, GF)
>
> -    explogs2trigs f ==
> -      (m := mainKernel f) case "failed" =>
> +    nthroot(a:GF,n:GF):GF ==
> +      r := nthRoot(sqrt(norm(a)),retract(n)@Z)
> +      e := exp(complex(0, 1)*argument(a)/n)
> +      r*e
> +
> +    explogs2trigs(f:FG):GF ==
> +      m := mainKernel f
> +      m case "failed" =>
>          GR2GF(retract(numer f)@GR) / GR2GF(retract(denom f)@GR)
> -      op  := operator(operator(k := m::KG))$F
> +      k := m::KG
> +      op  := operator(operator(k))$F
>        arg := [explogs2trigs x for x in argument k]
>        num := univariate(numer f, k)
>        den := univariate(denom f, k)
> +      is?(op,'nthRoot) =>
> +        h := nthroot(first arg, second arg)
> +        supexp(num,h,0,0)/supexp(den,h,0,0)
>        is?(op,'exp) =>
>          e  := exp real first arg
>          y  := imag first arg
>
> wspage@debian:~$
>
> ----
>
> Regards,
> Bill Page.
>
> On Tue, Jun 16, 2009 at 5:45 PM, Tim DalyTim Daly wrote:
>   
>> This one is queued as bug number 7199.
>>
>> When you say the latest "Gold" sources can you tell me the
>> result of the "Version" and "Timestamp" lines from the Axiom banner?
>> Where did you get the sources?
>>
>> Tim
>>
>>
>> Arnold Doray wrote:
>>     
>>> I get the wrong answer for real/imag for some forms of complex numbers.
>>> For example:
>>>
>>> a := (-1*%i)^(1/2)
>>> b := (%i)^(3/2)
>>>
>>> are both equivalent, but imag/real gives complex (and incorrect) answers
>>> for "a" (ie, real(a) and imag(a) are both complex), but I get the right
>>> answers for "b". Also "conjugate" fails on both with an error message.
>>>
>>> Am I missing something here?
>>> I am using Axiom compiled from the latest "Gold" source.
>>> Thanks,
>>> Arnold

Excellent. I will try to apply the patch and test it. --Tim

\start
Date: Thu, 18 Jun 2009 22:02:35 -0400
From: Bill Page
To: list
Subject: Re: symbolic (exact) trig expressions versus numeric results
Cc: Arnold Doray

In a recent report Arnold Doray observed that conjugate sometimes
seems to fail when operating on complicated exact complex numbers:

http://lists.gnu.org/archive/html/axiom-mail/2009-06/msg00027.html

To resolve this problem, the following cumulative patch against FriCAS
adds 'conjugate' and 'norm' for symbolic complex expressions to the to
the patch I sent earlier today.

wspage@debian:~$ svn diff
~/fricas-src/src/algebra/efstruc.spad.pamphlet > ctrigmnp.patch
wspage@debian:~$ cat ctrigmnp.patchIndex:
/home/wspage/fricas-src/src/algebra/efstruc.spad.pamphlet
===================================================================
--- /home/wspage/fricas-src/src/algebra/efstruc.spad.pamphlet	(revision 627)
+++ /home/wspage/fricas-src/src/algebra/efstruc.spad.pamphlet	(working copy)
@@ -767,6 +767,7 @@
   Implementation ==> add
     ker2explogs: (KG, List KG, List SY) -> FG
     smp2explogs: (PG, List KG, List SY) -> FG
+    nthroot:     (GF,GF) -> GF
     supexp     : (UP, GF, GF, Z) -> GF
     GR2GF      : GR -> GF
     GR2F       : GR -> F
@@ -847,13 +848,24 @@
       map(x +-> explogs2trigs(x::FG), GR2GF, p)$PolynomialCategoryLifting(
                                     IndexedExponents KG, KG, GR, PG, GF)

-    explogs2trigs f ==
-      (m := mainKernel f) case "failed" =>
+    -- De Moivre's theorem
+    nthroot(a:GF,n:GF):GF ==
+      r := nthRoot(sqrt(norm(a)),retract(n)@Z)
+      e := exp(complex(0, 1)*argument(a)/n)
+      r*e
+
+    explogs2trigs(f:FG):GF ==
+      m := mainKernel f
+      m case "failed" =>
         GR2GF(retract(numer f)@GR) / GR2GF(retract(denom f)@GR)
-      op  := operator(operator(k := m::KG))$F
+      k := m::KG
+      op  := operator(operator(k))$F
       arg := [explogs2trigs x for x in argument k]
       num := univariate(numer f, k)
       den := univariate(denom f, k)
+      is?(op,'nthRoot) =>
+        h := nthroot(first arg, second arg)
+        supexp(num,h,0,0)/supexp(den,h,0,0)
       is?(op, 'exp) =>
         e  := exp real first arg
         y  := imag first arg
@@ -926,6 +938,10 @@
     imag   : F -> F
       ++ imag(f) returns the imaginary part of \spad{f} where \spad{f}
       ++ is a complex function.
+    conjugate:F-> F
+      ++ conjugate(x+%i*y) returns x-%i*y
+    norm   : F -> F
+      ++ norm(f) returns f*conjugate(f)
     real?  : F -> Boolean
       ++ real?(f) returns \spad{true} if \spad{f = real f}.
     complexForm: F -> Complex F
@@ -952,6 +968,8 @@
     real? f          == empty?(complexKernels(f).ker)
     real f           == real complexForm f
     imag f           == imag complexForm f
+    conjugate f      == real(f) - sqrt(-1) * imag(f)
+    norm f           == f * conjugate(f)

 -- returns [[k1,...,kn], [v1,...,vn]] such that ki should be replaced by vi
     complexKernels f ==
@@ -1067,6 +1085,10 @@
     imag   : F -> FR
       ++ imag(f) returns the imaginary part of \spad{f} where \spad{f}
       ++ is a complex function.
+    conjugate:F-> F
+      ++ conjugate(x+%i*y) returns x-%i*y
+    norm   : F -> FR
+      ++ norm(f) returns f*conjugate(f)
     real?  : F -> Boolean
       ++ real?(f) returns \spad{true} if \spad{f = real f}.
     trigs  : F -> F
@@ -1087,6 +1109,8 @@

     real f        == real complexForm f
     imag f        == imag complexForm f
+    conjugate f      == F2FG real(f) - complex(0,1) * F2FG imag(f)
+    norm f           == FG2F(f * conjugate f)
     rreal? r      == zero? imag r
     kreal? k      == every?(real?, argument k)$List(F)
     complexForm f == explogs2trigs f
wspage@debian:~$

---

Note: These functions treat symbols appearing in values of type
'Expression Complex R' as variables of type R.

(1) -> conjugate(x+%i*y)

   (1)  - %i y + x
                                           Type: Expression(Complex(Integer))
(2) -> norm(x+%i*y)

         2    2
   (2)  y  + x
                                                    Type: Expression(Integer)
(3) -> conjugate(sqrt(x))

         +-+
   (3)  \|x
                                                    Type: Expression(Integer)
(4) -> conjugate(sqrt(x*%i))

          +--+         +--+
          | 2         4| 2
        (\|x   - %i x)\|x
   (4)  -------------------
                  +--+
              +-+ | 2
             \|2 \|x
                                           Type: Expression(Complex(Integer))
(5) ->

Further testing is encouraged.

Regards,
Bill Page.

--0015175745880f50c3046ca9eb50

SW5kZXg6IC9ob21lL3dzcGFnZS9mcmljYXMtc3JjL3NyYy9hbGdlYnJhL2Vmc3RydWMuc3BhZC5w
YW1waGxldAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09Ci0tLSAvaG9tZS93c3BhZ2UvZnJpY2FzLXNyYy9zcmMvYWxnZWJy
YS9lZnN0cnVjLnNwYWQucGFtcGhsZXQJKHJldmlzaW9uIDYyNykKKysrIC9ob21lL3dzcGFnZS9m
cmljYXMtc3JjL3NyYy9hbGdlYnJhL2Vmc3RydWMuc3BhZC5wYW1waGxldAkod29ya2luZyBjb3B5
KQpAQCAtNzY3LDYgKzc2Nyw3IEBACiAgIEltcGxlbWVudGF0aW9uID09PiBhZGQKICAgICBrZXIy
ZXhwbG9nczogKEtHLCBMaXN0IEtHLCBMaXN0IFNZKSAtPiBGRwogICAgIHNtcDJleHBsb2dzOiAo
UEcsIExpc3QgS0csIExpc3QgU1kpIC0+IEZHCisgICAgbnRocm9vdDogICAgIChHRixHRikgLT4g
R0YKICAgICBzdXBleHAgICAgIDogKFVQLCBHRiwgR0YsIFopIC0+IEdGCiAgICAgR1IyR0YgICAg
ICA6IEdSIC0+IEdGCiAgICAgR1IyRiAgICAgICA6IEdSIC0+IEYKQEAgLTg0NywxMyArODQ4LDI0
IEBACiAgICAgICBtYXAoeCArLT4gZXhwbG9nczJ0cmlncyh4OjpGRyksIEdSMkdGLCBwKSRQb2x5
bm9taWFsQ2F0ZWdvcnlMaWZ0aW5nKAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgSW5kZXhlZEV4cG9uZW50cyBLRywgS0csIEdSLCBQRywgR0YpCiAKLSAgICBleHBsb2dzMnRy
aWdzIGYgPT0KLSAgICAgIChtIDo9IG1haW5LZXJuZWwgZikgY2FzZSAiZmFpbGVkIiA9PgorICAg
IC0tIERlIE1vaXZyZSdzIHRoZW9yZW0KKyAgICBudGhyb290KGE6R0YsbjpHRik6R0YgPT0KKyAg
ICAgIHIgOj0gbnRoUm9vdChzcXJ0KG5vcm0oYSkpLHJldHJhY3QobilAWikKKyAgICAgIGUgOj0g
ZXhwKGNvbXBsZXgoMCwgMSkqYXJndW1lbnQoYSkvbikKKyAgICAgIHIqZQorCisgICAgZXhwbG9n
czJ0cmlncyhmOkZHKTpHRiA9PQorICAgICAgbSA6PSBtYWluS2VybmVsIGYKKyAgICAgIG0gY2Fz
ZSAiZmFpbGVkIiA9PgogICAgICAgICBHUjJHRihyZXRyYWN0KG51bWVyIGYpQEdSKSAvIEdSMkdG
KHJldHJhY3QoZGVub20gZilAR1IpCi0gICAgICBvcCAgOj0gb3BlcmF0b3Iob3BlcmF0b3IoayA6
PSBtOjpLRykpJEYKKyAgICAgIGsgOj0gbTo6S0cKKyAgICAgIG9wICA6PSBvcGVyYXRvcihvcGVy
YXRvcihrKSkkRgogICAgICAgYXJnIDo9IFtleHBsb2dzMnRyaWdzIHggZm9yIHggaW4gYXJndW1l
bnQga10KICAgICAgIG51bSA6PSB1bml2YXJpYXRlKG51bWVyIGYsIGspCiAgICAgICBkZW4gOj0g
dW5pdmFyaWF0ZShkZW5vbSBmLCBrKQorICAgICAgaXM/KG9wLCdudGhSb290KSA9PgorICAgICAg
ICBoIDo9IG50aHJvb3QoZmlyc3QgYXJnLCBzZWNvbmQgYXJnKQorICAgICAgICBzdXBleHAobnVt
LGgsMCwwKS9zdXBleHAoZGVuLGgsMCwwKQogICAgICAgaXM/KG9wLCAnZXhwKSA9PgogICAgICAg
ICBlICA6PSBleHAgcmVhbCBmaXJzdCBhcmcKICAgICAgICAgeSAgOj0gaW1hZyBmaXJzdCBhcmcK
QEAgLTkyNiw2ICs5MzgsMTAgQEAKICAgICBpbWFnICAgOiBGIC0+IEYKICAgICAgICsrIGltYWco
ZikgcmV0dXJucyB0aGUgaW1hZ2luYXJ5IHBhcnQgb2YgXHNwYWR7Zn0gd2hlcmUgXHNwYWR7Zn0K
ICAgICAgICsrIGlzIGEgY29tcGxleCBmdW5jdGlvbi4KKyAgICBjb25qdWdhdGU6Ri0+IEYKKyAg
ICAgICsrIGNvbmp1Z2F0ZSh4KyVpKnkpIHJldHVybnMgeC0laSp5CisgICAgbm9ybSAgIDogRiAt
PiBGCisgICAgICArKyBub3JtKGYpIHJldHVybnMgZipjb25qdWdhdGUoZikKICAgICByZWFsPyAg
OiBGIC0+IEJvb2xlYW4KICAgICAgICsrIHJlYWw/KGYpIHJldHVybnMgXHNwYWR7dHJ1ZX0gaWYg
XHNwYWR7ZiA9IHJlYWwgZn0uCiAgICAgY29tcGxleEZvcm06IEYgLT4gQ29tcGxleCBGCkBAIC05
NTIsNiArOTY4LDggQEAKICAgICByZWFsPyBmICAgICAgICAgID09IGVtcHR5Pyhjb21wbGV4S2Vy
bmVscyhmKS5rZXIpCiAgICAgcmVhbCBmICAgICAgICAgICA9PSByZWFsIGNvbXBsZXhGb3JtIGYK
ICAgICBpbWFnIGYgICAgICAgICAgID09IGltYWcgY29tcGxleEZvcm0gZgorICAgIGNvbmp1Z2F0
ZSBmICAgICAgPT0gcmVhbChmKSAtIHNxcnQoLTEpICogaW1hZyhmKQorICAgIG5vcm0gZiAgICAg
ICAgICAgPT0gZiAqIGNvbmp1Z2F0ZShmKQogCiAtLSByZXR1cm5zIFtbazEsLi4uLGtuXSwgW3Yx
LC4uLix2bl1dIHN1Y2ggdGhhdCBraSBzaG91bGQgYmUgcmVwbGFjZWQgYnkgdmkKICAgICBjb21w
bGV4S2VybmVscyBmID09CkBAIC0xMDY3LDYgKzEwODUsMTAgQEAKICAgICBpbWFnICAgOiBGIC0+
IEZSCiAgICAgICArKyBpbWFnKGYpIHJldHVybnMgdGhlIGltYWdpbmFyeSBwYXJ0IG9mIFxzcGFk
e2Z9IHdoZXJlIFxzcGFke2Z9CiAgICAgICArKyBpcyBhIGNvbXBsZXggZnVuY3Rpb24uCisgICAg
Y29uanVnYXRlOkYtPiBGCisgICAgICArKyBjb25qdWdhdGUoeCslaSp5KSByZXR1cm5zIHgtJWkq
eQorICAgIG5vcm0gICA6IEYgLT4gRlIKKyAgICAgICsrIG5vcm0oZikgcmV0dXJucyBmKmNvbmp1
Z2F0ZShmKQogICAgIHJlYWw/ICA6IEYgLT4gQm9vbGVhbgogICAgICAgKysgcmVhbD8oZikgcmV0
dXJucyBcc3BhZHt0cnVlfSBpZiBcc3BhZHtmID0gcmVhbCBmfS4KICAgICB0cmlncyAgOiBGIC0+
IEYKQEAgLTEwODcsNiArMTEwOSw4IEBACiAKICAgICByZWFsIGYgICAgICAgID09IHJlYWwgY29t
cGxleEZvcm0gZgogICAgIGltYWcgZiAgICAgICAgPT0gaW1hZyBjb21wbGV4Rm9ybSBmCisgICAg
Y29uanVnYXRlIGYgICAgICA9PSBGMkZHIHJlYWwoZikgLSBjb21wbGV4KDAsMSkgKiBGMkZHIGlt
YWcoZikKKyAgICBub3JtIGYgICAgICAgICAgID09IEZHMkYoZiAqIGNvbmp1Z2F0ZSBmKQogICAg
IHJyZWFsPyByICAgICAgPT0gemVybz8gaW1hZyByCiAgICAga3JlYWw/IGsgICAgICA9PSBldmVy
eT8ocmVhbD8sIGFyZ3VtZW50IGspJExpc3QoRikKICAgICBjb21wbGV4Rm9ybSBmID09IGV4cGxv
Z3MydHJpZ3MgZgo=
--0015175745880f50c3046ca9eb50--

\start
Date: Fri, 19 Jun 2009 06:14:46 -0400
From: Tim Daly
To: Bill Page
Subject: re: symbolic (exact) trig expressions versus numeric results
Cc: Arnold Doray

Bill,

Do you have an input file of test cases?

Tim


Bill Page wrote:
> In a recent report Arnold Doray observed that conjugate sometimes
> seems to fail when operating on complicated exact complex numbers:
>
> http://lists.gnu.org/archive/html/axiom-mail/2009-06/msg00027.html
>
> To resolve this problem, the following cumulative patch against FriCAS
> adds 'conjugate' and 'norm' for symbolic complex expressions to the to
> the patch I sent earlier today.
>
> wspage@debian:~$ svn diff
> ~/fricas-src/src/algebra/efstruc.spad.pamphlet > ctrigmnp.patch
> wspage@debian:~$ cat ctrigmnp.patchIndex:
> /home/wspage/fricas-src/src/algebra/efstruc.spad.pamphlet
> ===================================================================
> --- /home/wspage/fricas-src/src/algebra/efstruc.spad.pamphlet	(revision 627)
> +++ /home/wspage/fricas-src/src/algebra/efstruc.spad.pamphlet	(working copy)
> @@ -767,6 +767,7 @@
>    Implementation ==> add
>      ker2explogs: (KG, List KG, List SY) -> FG
>      smp2explogs: (PG, List KG, List SY) -> FG
> +    nthroot:     (GF,GF) -> GF
>      supexp     : (UP, GF, GF, Z) -> GF
>      GR2GF      : GR -> GF
>      GR2F       : GR -> F
> @@ -847,13 +848,24 @@
>        map(x +-> explogs2trigs(x::FG), GR2GF, p)$PolynomialCategoryLifting(
>                                      IndexedExponents KG, KG, GR, PG, GF)
>
> -    explogs2trigs f ==
> -      (m := mainKernel f) case "failed" =>
> +    -- De Moivre's theorem
> +    nthroot(a:GF,n:GF):GF ==
> +      r := nthRoot(sqrt(norm(a)),retract(n)@Z)
> +      e := exp(complex(0, 1)*argument(a)/n)
> +      r*e
> +
> +    explogs2trigs(f:FG):GF ==
> +      m := mainKernel f
> +      m case "failed" =>
>          GR2GF(retract(numer f)@GR) / GR2GF(retract(denom f)@GR)
> -      op  := operator(operator(k := m::KG))$F
> +      k := m::KG
> +      op  := operator(operator(k))$F
>        arg := [explogs2trigs x for x in argument k]
>        num := univariate(numer f, k)
>        den := univariate(denom f, k)
> +      is?(op,'nthRoot) =>
> +        h := nthroot(first arg, second arg)
> +        supexp(num,h,0,0)/supexp(den,h,0,0)
>        is?(op, 'exp) =>
>          e  := exp real first arg
>          y  := imag first arg
> @@ -926,6 +938,10 @@
>      imag   : F -> F
>        ++ imag(f) returns the imaginary part of \spad{f} where \spad{f}
>        ++ is a complex function.
> +    conjugate:F-> F
> +      ++ conjugate(x+%i*y) returns x-%i*y
> +    norm   : F -> F
> +      ++ norm(f) returns f*conjugate(f)
>      real?  : F -> Boolean
>        ++ real?(f) returns \spad{true} if \spad{f = real f}.
>      complexForm: F -> Complex F
> @@ -952,6 +968,8 @@
>      real? f          == empty?(complexKernels(f).ker)
>      real f           == real complexForm f
>      imag f           == imag complexForm f
> +    conjugate f      == real(f) - sqrt(-1) * imag(f)
> +    norm f           == f * conjugate(f)
>
>  -- returns [[k1,...,kn], [v1,...,vn]] such that ki should be replaced by vi
>      complexKernels f ==
> @@ -1067,6 +1085,10 @@
>      imag   : F -> FR
>        ++ imag(f) returns the imaginary part of \spad{f} where \spad{f}
>        ++ is a complex function.
> +    conjugate:F-> F
> +      ++ conjugate(x+%i*y) returns x-%i*y
> +    norm   : F -> FR
> +      ++ norm(f) returns f*conjugate(f)
>      real?  : F -> Boolean
>        ++ real?(f) returns \spad{true} if \spad{f = real f}.
>      trigs  : F -> F
> @@ -1087,6 +1109,8 @@
>
>      real f        == real complexForm f
>      imag f        == imag complexForm f
> +    conjugate f      == F2FG real(f) - complex(0,1) * F2FG imag(f)
> +    norm f           == FG2F(f * conjugate f)
>      rreal? r      == zero? imag r
>      kreal? k      == every?(real?, argument k)$List(F)
>      complexForm f == explogs2trigs f
> wspage@debian:~$
>
> ---
>
> Note: These functions treat symbols appearing in values of type
> 'Expression Complex R' as variables of type R.
>
> (1) -> conjugate(x+%i*y)
>
>    (1)  - %i y + x
>                                            Type: Expression(Complex(Integer))
> (2) -> norm(x+%i*y)
>
>          2    2
>    (2)  y  + x
>                                                     Type: Expression(Integer)
> (3) -> conjugate(sqrt(x))
>
>          +-+
>    (3)  \|x
>                                                     Type: Expression(Integer)
> (4) -> conjugate(sqrt(x*%i))
>
>           +--+         +--+
>           | 2         4| 2
>         (\|x   - %i x)\|x
>    (4)  -------------------
>                   +--+
>               +-+ | 2
>              \|2 \|x
>                                            Type: Expression(Complex(Integer))
> (5) ->
>
> Further testing is encouraged.

\start
Date: Wed, 17 Jun 2009 09:40:51 +0800
From: Arnold Doray
To: Tim Daly
Subject: Re: [Axiom-mail] Problem with real/imag/conjugate

Version: Axiom (July 2008)

Source downloaded from:
http://axiom.axiom-developer.org/axiom-website/downloads/axiom-july2008-src.tgz

Just realized that the latest source is actually Nov 2008. I will try
again with the Nov 2008 version. 

Arnold

On Tue, 2009-06-16 at 17:45 -0400, Tim Daly wrote:
> This one is queued as bug number 7199.
> 
> When you say the latest "Gold" sources can you tell me the
> result of the "Version" and "Timestamp" lines from the Axiom banner?
> Where did you get the sources?

\start
Date: Wed, 17 Jun 2009 09:34:19 +0800
From: Arnold Doray
To: Tim Daly
Subject: Re: [Axiom-mail] Re: Coersion error

The command I used was "open-axiom" to start Open Axiom. I had compiled
this from their latest stable source too, but did not run the checks.
-AD


On Tue, 2009-06-16 at 17:40 -0400, Tim Daly wrote:
> Your initial report showed the problem from Open-Axiom
> which is not the Axiom project. What command line did you use
> to start Open-Axiom?
> 
> Your problem is also in Axiom so it is listed as a valid bug report.
> It has been assigned bug number 7198.

\start
Date: Sun, 21 Jun 2009 09:46:32 -0400
From: Tim Daly
To: <ekhaya.lindsay@gmail.com>
Subject: Mandriva axiom install

I was unaware that there was a Mandriva rpm of Axiom anywhere.

All working versions of Axiom are available at:
http://axiom-developer.org/axiom-website/download.html
One of the fedora versions is likely to work fine, especially
since Mandriva is a derivative of the RedHat line.

I will build a Mandriva machine and an Axiom build.

Tim


URL:
  <http://savannah.nongnu.org/support/?106905>

                 Summary: cannot get axiom to work
                 Project: Axiom Computer Algebra System
            Submitted by: None
            Submitted on: Sun 21 Jun 2009 02:28:50 AM UTC
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: ekhaya.lindsay@gmail.com
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

I am running Mandriva Spring 2009, on a Gnome desktop.
I first installed axiom from the Mandriva rpm installer. 
At the console, absolutely nothing happened when I typed axiom. It simply
returned to my directory. 

I then downloaded and installed the binary file "redhat9" and followed all
the instructions. 
This time an error message of a missing shared library is generated. 
The library referred to is:
libreadline.so.4

I have checked, and note that I have libreadline.so.6

I presume some line in the code has to change. 
How do I do this, so there is a correct reference to libreadline version 6?

Otherwise, I have to give up on trying to use axiom

\start
Date: Mon, 22 Jun 2009 00:31:41 +0200
From: Michael Becker
To: list
Subject: axiom-may2009 release :  regression test failure

    Hi,
   
    the may-2009 release compiles without problems, but some regression tests
    failed.


.....
.....
.....
45 Makefile.linux called
46 Environment : PLF=LINUXplatform CCF=-O2 -fno-strength-reduce =
-Wall -D_GNU_SOU
RCE -DLINUXplatform -I/usr/X11/include LDF= -L/usr/lib =
/usr/lib/libXpm.a  CC=gcc
 AWK=gawk RANLIB=ranlib TOUCH=touch TAR=tar =
AXIOMXLROOT=/home/michael/Builds/axi
om/mnt/opensuse/compiler O=o BYE=bye LISP=lsp =
DAASE=/home/michael/Builds/axiom/s
rc/share XLIB=/usr/lib GCLOPTS=--enable-vssize=65536*2 =
--enable-locbfd --disable
-dynsysbfd --disable-statsysbfd --enable-maxpage=512*1024 =
--disable-xgcl --disab
le-tkconfig SRCDIRS=bootdir interpdir sharedir algebradir etcdir =
clefdir docdir
graphdir smandir hyperdir browserdir inputdir PATCH=patch
int/input/DoubleFloat.regress:regression result FAILED 2 of 10 stanzas =
file Doub
leFloat
int/input/FileName.regress:regression result FAILED 2 of 18 stanzas file =
FileNam
e
int/input/TextFile.regress:regression result FAILED 2 of 10 stanzas file =
TextFil
e
int/input/constant.regress:regression result FAILED 1 of 37 stanzas file =
constan
t
int/input/dfloat.regress:regression result FAILED 2 of 10 stanzas file =
dfloat
int/input/e1.regress:regression result FAILED 4 of 7 stanzas file e1
int/input/easter.regress:regression result FAILED 1 of 200 stanzas file =
easter
int/input/ei.regress:regression result FAILED 10 of 20 stanzas file ei
int/input/elemnum.regress:regression result FAILED 16 of 50 stanzas file =
elemnum
int/input/en.regress:regression result FAILED 6 of 7 stanzas file en
int/input/fname.regress:regression result FAILED 1 of 9 stanzas file =
fname
int/input/fname1.regress:regression result FAILED 2 of 18 stanzas file =
fname1
int/input/gamma.regress:regression result FAILED 4 of 12 stanzas file =
gamma
int/input/grpthry.regress:regression result FAILED 3 of 68 stanzas file =
grpthry
int/input/gstbl.regress:regression result FAILED 1 of 1 stanzas file =
gstbl
int/input/ico.regress:regression result FAILED 11 of 65 stanzas file ico
int/input/repa6.regress:regression result FAILED 4 of 33 stanzas file =
repa6
int/input/textfile.regress:regression result FAILED 2 of 10 stanzas file =
textfil
e
int/input/unittest2.regress:regression result FAILED 1 of 236 stanzas file unitt
est2

\start
Date: Mon, 22 Jun 2009 02:51:21 -0400
From: Tim Daly
To: <ekhaya.lindsay@gmail.com>
Subject: Re: Mandriva axiom install

Please visit the Axiom download webpage at:
http://axiom-developer.org/axiom-website/download.html

In the download table you can download the binary for a
Mandriva 2009 Spring version of Axiom

Tim


Tim Daly wrote:
> I was unaware that there was a Mandriva rpm of Axiom anywhere.
>
> All working versions of Axiom are available at:
> http://axiom-developer.org/axiom-website/download.html
> One of the fedora versions is likely to work fine, especially
> since Mandriva is a derivative of the RedHat line.
>
> I will build a Mandriva machine and an Axiom build.
>
> Tim
>
>
> URL:
>  <http://savannah.nongnu.org/support/?106905>
>
>                 Summary: cannot get axiom to work
>                 Project: Axiom Computer Algebra System
>            Submitted by: None
>            Submitted on: Sun 21 Jun 2009 02:28:50 AM UTC
>                Category: None
>                Priority: 5 - Normal
>                Severity: 3 - Normal
>                  Status: None
>                 Privacy: Public
>             Assigned to: None
>        Originator Email: ekhaya.lindsay@gmail.com
>             Open/Closed: Open
>         Discussion Lock: Any
>        Operating System: GNU/Linux
>
>    _______________________________________________________
>
> Details:
>
> I am running Mandriva Spring 2009, on a Gnome desktop.
> I first installed axiom from the Mandriva rpm installer. At the 
> console, absolutely nothing happened when I typed axiom. It simply
> returned to my directory.
> I then downloaded and installed the binary file "redhat9" and followed 
> all
> the instructions. This time an error message of a missing shared 
> library is generated. The library referred to is:
> libreadline.so.4
>
> I have checked, and note that I have libreadline.so.6
>
> I presume some line in the code has to change. How do I do this, so 
> there is a correct reference to libreadline version 6?
>
> Otherwise, I have to give up on trying to use axiom
>
>
>
>
>    _______________________________________________________
>
> Reply to this item at:
>
>  <http://savannah.nongnu.org/support/?106905>
>
> _______________________________________________
>  Message sent via/by Savannah
>  http://savannah.nongnu.org/
>




