\start
Date: Mon, 1 Sep 2014 01:43:53 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] developer videos

I've given up on my plan to live forever.

Instead I'm creating a series of videos that show how to
maintain and modify Axiom. The first of the series, which
\begin{verbatim}details how to add algebra, is complete and should be on 
the website soon. I'll give details once the conversion and 
upload complete.

My video and audio skills rival my singing skills for 
painful performances and for that I apologize in advance.

Tim

\start
Date: Mon, 01 Sep 2014 11:05:21 -0700
From: Arthur Ralfs <arthur@mathbrane.ca>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] developer videos

On 08/31/2014 11:43 PM, daly@axiom-developer.org wrote:
> I've given up on my plan to live forever.
>
> Instead I'm creating a series of videos that show how to
> maintain and modify Axiom. The first of the series, which
> details how to add algebra, is complete and should be on
> the website soon. I'll give details once the conversion and
> upload complete.
>
> My video and audio skills rival my singing skills for
> painful performances and for that I apologize in advance.
>
> Tim
>
> _______________________________________________
> Axiom-developer mailing list
> Axiom-developer@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/axiom-developer
>
Tim,

I eagerly await your acting debut.

Arthur

\start
Date: Mon, 01 Sep 2014 19:27:26 -0400
From: u1204 <daly@axiom-developer.org>
To: Arthur Ralfs <arthur@mathbrane.ca>
Subject: Re: [Axiom-developer] developer videos

> I eagerly await your acting debut.

Well, the wait is finally over. Methinks "eagerly" might be overthought.
Feedback (at low gain and overdamped) is welcome.

The new videos are up. One details how to add algebra and one details
how to modify the website. The style is sorta-pair-programming or
shoulder-surfing. Further videos will follow. Topics on request.

http://axiom-developer.org/axiom-website/videos.html

Browser supporting HTML5 should be able to see the mp4 links with no
problem. Full screen is recommended due to the normal working size of
my text.

I need some overview videos to introduce the documentation structure as
well as many more detail videos to cover the day-to-day routine of
maintaining and modifying this beast.

Tim

\start
Date: Wed, 3 Sep 2014 03:49:06 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Cylindrical Algebraic Decomposition added

Cylindrical Algebraic Decomposition has been added to Axiom.

Tim

\start
Date: Wed, 3 Sep 2014 03:52:33 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Building Test Cases video added

There is a new video which details how to create and deploy
regression test cases at
http://axiom-developer.org/axiom-website/videos.html

Tim

\start
Date: Wed, 03 Sep 2014 14:02:05 +0200
From: Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Cylindrical Algebraic Decomposition added

Dear axiom gurus,

Thank you Tim.

Please remembrer that this is a very old work of mine but I hope that I w=
ill still be
able to answer questions and correct bugs or add features to the package.

All the best.

Renaud Rioboo

\start
Date: Wed, 3 Sep 2014 12:50:48 -0500
From: daly@axiom-developer.org
To: Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
Subject: Re: [Axiom-developer] Cylindrical Algebraic Decomposition added

Renaud,

I did not have a working email address for you.
I'm glad you replied.

Thank you for the package.

Axiom code, since it computes mathematical objects, is timeless.
That's what makes it worthwhile to write and maintain.

I've had your code for a few years along with other people's algebra
yet to be added. I'm sorry it took so long to add your work. I'm just
so lagged (as you can see) that the queue is rather long.

Is there a paper related to the code or other documentation I should
reference? If so, I'd like your permission to quote parts of it as
part of Axiom's documentation.

Tim

>Dear axiom gurus,
>Thank you Tim.
>
>Please remember that this is very old work of mine but I hope that
>I will still be able to answer questions and correct bugs or add
> features to the package. All the best. -- Renaud Rioboo

\start
Date: Thu, 04 Sep 2014 12:30:52 -0400
From: Camm Maguire <camm@maguirefamily.org>
To: daly@axiom-developer.org
Subject: [Axiom-developer] sockio-c patches

Greetings!  Just wondering if you had a chance to look at the patches I
submitted, and might consider committing them.  They appear solid under
the Debian autobuilders.

David Billinghurst is helping me support a broken XP, and once that's
in, I will release 2.6.11.  It would be great if this was the gcl
version you include in zips.  This said, the patches I submitted also
support building with an external gcl as designated by the GCL
environment variable.

Take care,
-- 
Camm Maguire			     		    camm@maguirefamily.org

\start
Date: Fri, 5 Sep 2014 01:22:35 -0500
From: daly@axiom-developer.org
To: Raoul <raoulb@bluewin.ch>
Subject: [Axiom-developer] lattice

Raoul,

re: http://axiom-developer.org/axiom-website/lattice.html

The orange text are books or papers which I've already scanned for
references. An underlined text points to an online source for the
document (not hosted by me). There are roughly 800 references so
far. I re-worked the page so it is automatically generated from a
bibtex-like format, letting mouse-over show the citation.

The idea is to form the closure of the references, so to speak.
Some sources have most of their references already on the page.
Others have an almost disjoint set. In fact, it seems that there
are two distinct clades, one European and one American. A few
researchers, like Davenport, seem to cover both.

Since the goal of the effort is to collect algorithms I am reviewing
books and papers that contain algorithms. I'm also implementing at
least some of them in Spad in an as-yet unpublished Volume 14. One
glitch I've found is algebraic. For instance, I have a Maple 
algorithm over the Integers that uses division, making it more
of a challenge to implement in Axiom since Integer does not support
division. Another algorithm (coset enumeration, Sims) doesn't seem
to fit easily anywhere.

Another struggle along the way is to get some sense of the history of
an algorithm, e.g. Ritt -> Risch -> Rothstein -> Trager -> Bronstein ...
with a lot of side complications about Norman, Davenport, Moses, ... 

There needs to be an ordering by area, by algorithm, and by
improvements (with citations) as well as by researcher. And since
this is algebra, ordered by domain (Ring, Commutative Ring, Integral
domain, Unique Factorization domain, Euclidean domain, Field) and
finite variations, etc. I am unsure what is a reasonable taxonomy.

I see more web pages and more struggles about how to display
these relationships.

This has the character of a jigsaw puzzle with multiple solutions.

Where is Knuth when we need him?

Tim

\start
Date: Fri, 5 Sep 2014 19:37:31 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Doron Zeilberger's backward compatibility rant

I've long held the view that backward compatibility is vital.
What used to work should continue to work. No piece of software
is perfect and there is always room for "improvement" but we
need to distinguish between bug fixes (which might change results)
and cosmetic fixes (which change non-vital things like syntax).
Not everyone shares this view.

I recently tripped across Doron Zeilberger's home page of rants
which makes for fascinating reading. This one is on the topic
of backward compatibility and open algorithms. See
http://www.math.rutgers.edu/~zeilberg

This is the relevant quote from his "Opinion 47" article

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

About ten years ago, after short flirtations with Macsyma and
Mathematica, I fell in love with Maple. It was such a neat system, so
open and versatile. For example, Mike Monagan told me how to view the
source-code of most of the available procedures by setting:
"interface(verboseproc=2);" and then, e.g., typing "print(gcd);", to
see how the gcd function was programmed.

This is still the love of my professional life, and it is still far
better than anything else. Even though in the meantime it got a little
Wolframized. First, it is not possible to view the built-in functions,
in whatever (I guess C) language they are written in, but more
seriously, and almost scandalously, IT IS NOT UPWARD COMPATIBLE!

One of the diseases of our current commercial software industry is the
Gatesian sin of making things obsolete on purpose, by making minor
changes. This forces the customers to keep pouring money into the
pockets of the Gateses and other sleazy moguls. By not making it
upward compatible, it forces people to buy the latest (and often
worse) version.

In the case of Maple, however, the REAL reason is not to make more
money, but to genuinely ``improve'' the system. Frankly, it worked
just fine for me until now. If it ain't broke, don't fix it. But if
you do want to improve, PLEASE KEEP IT UPWARD COMPATIBLE!

Maple, that was, and still largely is, a grass roots endeavor, started
in Academia, by such pioneers as Geddes, Gonnet and Char, and
continued by Monagan, Leong, Watt and others, should be sensitive to
to the mathematical wish to be immortal. Because Maple is meant to be
DOING mathematics, and Used by mathematicians to do NEW
Mathematics. In my own work with Shalosh, I write many Maple programs
that Prove things. It is a great nuisance having to adapt the programs
(i.e. the proofs), every time a new version comes out.

Also, if one uses Maple to prove theorems, it is important that ALL
THE CODE, and even the compiler, be out-in-the-open, for anyone to
see. Testing a procedure as a black box is merely empirical
verification.

So let's hope that Maple will start to be upward-compatible, and that
it will be completely openly viewable. But, until then, may I
recommend that YOU DO NOT RUSH TO BUY the latest version, unless you
have to, because it is not necessarily any better, and sometimes, in
some respect, it is worse. But if you do buy the latest version, don't
delete the previous versions! Nowadays disk-space is cheap, and there
is plenty of room for past versions. For example, on our system, we
have three commands: mapleV3, mapleV4, and mapleV5. This way, Maple
programs written in the past would be usable in the future.

Perhaps it is time for a new "Maple" altogether, that will start from
scratch, will be completely public-domain And freely available (like
Dave Bayer and Mike Stillman's excellent Macaulay system for Groebner
bases), and upward-compatible.

\start
Date: Fri, 5 Sep 2014 19:44:23 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Doron Zeilberger's Buchberger rant

Full disclosure: I know Bruno Buchberger and we briefly worked on
a problem in Infinite Group Theory at City College of New York.

That said, I do think that his work ought to bring him much
wider fame and praise than it has. Doron seems to agree. I'm
not sure I'd have aimed specifically at the Austrian Academy
but Doron's opinions are what they are.

See http://www.math.rutgers.edu/~zeilberg, Opinion 47

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

But the MOST significant contribution by 20th-Century human
mathematicians and computer scientists was the creation of COMPUTER
ALGEBRA. It is still in a very preliminary stage, but is already
revolutionizing the way we DO and THINK about mathematics. Even
computer foes often `cheat' and use Maple or Mathematica on the
side. It is a scandal that, so far, the pioneers of computer algebra
did not get their due recognition by the mathematical
establishment. One glaring oversight, reminiscent of Godel only
becoming a professor at the age of 47, is that Bruno BUCHBERGER, the
great pioneer of computer algebra, whose algorithm revolutionized all
the spectrum of mathematics, from robotics to very abstract algebraic
geometry, does not get a tiny fraction of the recognition granted to
the Atiyahs and the Botts. He is not even a member of the Academy of
Science of his native Austria! But one should not fault this or that
specific Academy. After all, at least today, national academies
consist of members of that narrow-minded, short-sighted species called
humans. Bruno Buchberger's heritage, and his Groebner Bases will
survive long after most of the current members of the Austrian Academy
of Science will be forgotten.

\start
Date: Fri, 5 Sep 2014 19:46:14 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Doron Zeilberger's backward compatibility rant

This is a bug fix to that post :-)

The quote is from Opinion 26, not Opinion 47. Sigh.

\start
Date: Sat, 06 Sep 2014 21:33:04 -0400
From: Camm Maguire <camm@maguirefamily.org>
To: daly@axiom-developer.org,axiom-developer@nongnu.org
Subject: [Axiom-developer] GCL 2.6.11 is released

Greetings!  No problem, Tim!  I've just cut the release.  I'm convinced
2.6.11 should serve axiom well in any configuration, so whenever you
feel ready to give the patches a go, great!  Please keep me posted if
you do so.

Take care,

daly@axiom-developer.org writes:

> Camm,
>
> I started looking at that patch. Unfortunately applying the patch
> and running a new release cycle (which takes 3-4 days) is beyond
> the time I have available right now. I agree with the idea but
> it would require me to build and test on many different systems
> (sequentially due to local hardware limitations), each taking
> many hours to set up, regression test, and package.
>


-- 
Camm Maguire			     		    camm@maguirefamily.org

\start
Date: Sun, 7 Sep 2014 22:36:53 -0500
From: daly@axiom-developer.org
To: "Waldek Hebisch" <hebisch@math.uni.wroc.pl>
Subject: [Axiom-developer] CAD package from Renaud Rioboo

Waldek,

Here is Renaud's CAD package for your new release.

Tim

=======================================================================
)ab pack CADU CylindricalAlgebraicDecompositionUtilities

CylindricalAlgebraicDecompositionUtilities(R,P) : PUB == PRIV where

-- Tese are some standard tools which are needed to compute with univariate
-- polynomials. 
--
-- A gcd basis for a set of polynomials is a set of pairwise relatively prime 
-- polynomials which all divide the original set and whose product is the
-- same than the product of the original set.
--
-- A square free basis for a list of polynomials is just a list
-- of square free polynomials which are pairwise relatively primes and have
-- the same roots than the original polynomials.

  R : GcdDomain
  P : UnivariatePolynomialCategory(R)

  PUB == with
      squareFreeBasis : List(P) -> List(P)
        ++ 
      gcdBasis : List(P) -> List(P)
        ++ decompose a list of polynomials into pairwise relatively 
        ++ prime polynomials
      gcdBasisAdd : (P,List(P)) -> List(P)
        ++ add one polynomial to list of pairwise relatively prime polynomials

  PRIV == add

     squareFreeBasis(lpols) ==
       lpols = [] => []
       pol := first(lpols)
       sqpol := unitCanonical(squareFreePart(pol))
       gcdBasis(cons(sqpol,squareFreeBasis(rest(lpols))))
         
     gcdBasisAdd(p,lpols) ==
       (degree(p) = 0) => lpols
       null lpols => [unitCanonical p]
       p1 := first(lpols)
       g := gcd(p,p1)
       (degree(g) = 0) => cons(p1,gcdBasisAdd(p,rest lpols))
       p := (p exquo g)::P
       p1 := (p1 exquo g)::P
       basis := gcdBasisAdd(p,rest(lpols))
       if degree(p1) > 0 then basis := cons(p1,basis)
       gcdBasisAdd(g,basis)
       

     gcdBasis(lpols) ==
       (#lpols <= 1) => lpols
       basis := gcdBasis(rest lpols)
       gcdBasisAdd(first(lpols),basis)

)ab domain SCELL SimpleCell

-- This domain is made to work with one-dimensional semi-algebraic cells
-- ie either an algebraic point, either an interval. The point is specified as 
-- specification of an algebraic value.

SimpleCell(TheField,ThePols) : PUB == PRIV where
  TheField : RealClosedField
  ThePols : UnivariatePolynomialCategory(TheField)
  O           ==> OutputForm
  B           ==> Boolean
  Z           ==> Integer
  N           ==> NonNegativeInteger

--  VARS ==> VariationsPackage(TheField,ThePols)
  VARS ==> RealPolynomialUtilitiesPackage(TheField,ThePols)
  LF ==> List(TheField)

  PUB == CoercibleTo(O) with

     allSimpleCells : (ThePols,Symbol) -> List %
     allSimpleCells : (List(ThePols),Symbol) -> List %
     hasDimension? : % -> B
     samplePoint : % -> TheField
     stablePol : % -> ThePols
     variableOf : % -> Symbol
     separe : (LF,TheField,TheField) -> LF
     pointToCell : (TheField,B,Symbol) -> %

  PRIV == add

     Rep := Record(samplePoint:TheField,
                   hasDim:B,
                   varOf:Symbol)

     samplePoint(c) == c.samplePoint

     stablePol(c) == error "Prout"

     hasDimension?(c) == c.hasDim

     variableOf(c) == c.varOf

     coerce(c:%):O ==
       o : O := ((c.varOf)::O) = ((c.samplePoint)::O)
       brace [o,(c.hasDim)::O]

     separe(liste,gauche,droite) ==
       milieu : TheField := (gauche + droite) / (2::TheField)
       liste = [] => [milieu]
       #liste = 1 => [gauche,first(liste),droite]
       nbe := first(liste)
       lg :List(TheField) := []
       ld :List(TheField) := rest(liste)
       sg := sign(milieu-nbe)
       while sg > 0 repeat
         lg := cons(nbe,lg)
         ld = [] => return(separe(reverse(lg),gauche,milieu))
         nbe := first(ld)
         sg := sign(milieu-nbe)
         ld := rest(ld)
       sg < 0 =>
         append(separe(reverse(lg),gauche,milieu),
                rest(separe(cons(nbe,ld),milieu,droite)))
       newDroite := (gauche+milieu)/(2::TheField)
       null lg =>
           newGauche := (milieu+droite)/(2::TheField)
           while newGauche >= first(ld) repeat
             newGauche := (milieu+newGauche)/(2::TheField)
           append([gauche,milieu],separe(ld,newGauche,droite))
       while newDroite <= first(lg) repeat
         newDroite := (newDroite+milieu)/(2::TheField)
       newGauche := (milieu+droite)/(2::TheField)
       null ld => append(separe(reverse(lg),gauche,newDroite),[milieu,droite])
       while newGauche >= first(ld) repeat
         newGauche := (milieu+newGauche)/(2::TheField)
       append(separe(reverse(lg),gauche,newDroite),
              cons(milieu,separe(ld,newGauche,droite)))

     pointToCell(sp,hasDim?,varName) ==
       [sp,hasDim?,varName]$Rep

     allSimpleCells(p:ThePols,var:Symbol) ==
       allSimpleCells([p],var)

     PACK ==> CylindricalAlgebraicDecompositionUtilities(TheField,ThePols)
     allSimpleCells(lp:List(ThePols),var:Symbol) ==
       lp1 := gcdBasis(lp)$PACK
       null(lp1) => [pointToCell(0,true,var)]
       b := ("max" / [ boundOfCauchy(p)$VARS for p in lp1 ])::TheField
       l := "append" / [allRootsOf(makeSUP(unitCanonical(p))) for p in lp1]
       l := sort(l)
       l1 := separe(l,-b,b)
       res : List(%) := [pointToCell(first(l1),true,var)]
       l1 := rest(l1)
       while not(null(l1)) repeat
         res := cons(pointToCell(first(l1),false,var),res)
         l1 := rest(l1)
         l1 = [] => return(error "Liste vide")
         res := cons(pointToCell(first(l1),true,var),res)
         l1 := rest(l1)
       reverse! res

)ab domain CELL Cell

Cell(TheField) : PUB == PRIV where
  TheField : RealClosedField

  ThePols ==> Polynomial(TheField)

  O           ==> OutputForm
  B           ==> Boolean
  Z           ==> Integer
  N           ==> NonNegativeInteger
  BUP         ==> SparseUnivariatePolynomial(TheField)
  SCELL       ==> SimpleCell(TheField,BUP)


  PUB == CoercibleTo(O) with

     samplePoint : % -> List(TheField)
     dimension : % -> N
     hasDimension? :  (%,Symbol) -> B
     makeCell : List(SCELL) -> %
     makeCell : (SCELL,%) -> %
     mainVariableOf : % -> Symbol
     variablesOf : % -> List Symbol
     projection : % -> Union(%,"failed")
     


  PRIV == add

    Rep := List(SCELL)

    coerce(c:%):O == 
      paren [sc::O for sc in c]

    projection(cell) ==
      null cell => error "projection: should not appear"
      r := rest(cell)
      null r => "failed"
      r

    makeCell(l:List(SCELL)) == l

    makeCell(scell,toAdd) == cons(scell,toAdd)

    mainVariableOf(cell) == 
      null(cell) => 
        error "Should not appear"
      variableOf(first(cell))

    variablesOf(cell) ==
      null(cell) => []
      cons(mainVariableOf(cell),variablesOf(rest(cell)::%))

    dimension(cell) ==
      null(cell) => 0
      hasDimension?(first(cell)) => 1+dimension(rest(cell))
      dimension(rest(cell))

    hasDimension?(cell,var) ==
      null(cell) => 
        error "Should not appear"
      sc : SCELL := first(cell)
      v := variableOf(sc)
      v = var => hasDimension?(sc)
      v < var => false
      v > var => true
      error "Caca Prout"

    samplePoint(cell) ==
      null(cell) => []
      cons(samplePoint(first(cell)),samplePoint(rest(cell)))

)ab pack CAD CylindricalAlgebraicDecompositionPackage

CylindricalAlgebraicDecompositionPackage(TheField) : PUB == PRIV where

  TheField : RealClosedField

  ThePols ==> Polynomial(TheField)
  P ==> ThePols
  BUP ==> SparseUnivariatePolynomial(TheField)
  RUP ==> SparseUnivariatePolynomial(ThePols)

  Z           ==> Integer
  N           ==> NonNegativeInteger

  CELL ==> Cell(TheField)
  SCELL ==> SimpleCell(TheField,BUP)

  PUB == with

      cylindricalDecomposition: List P ->        List CELL
      cylindricalDecomposition: (List(P),List(Symbol)) ->        List CELL
      projectionSet: (List RUP)                ->    List P
      coefficientSet: RUP                ->    List P
      discriminantSet : List RUP -> List(P)
      resultantSet :  List RUP -> List P 
      principalSubResultantSet : (RUP,RUP) -> List P
      specialise : (List(ThePols),CELL) -> List(BUP)

  PRIV == add

     cylindricalDecomposition(lpols) ==
       lv : List(Symbol) := []
       for pol in lpols repeat
         ground?(pol) => "next pol"
         lv := removeDuplicates(append(variables(pol),lv))
       lv := reverse(sort(lv))
       cylindricalDecomposition(lpols,lv)

     cylindricalDecomposition(lpols,lvars) ==
       lvars = [] => error("CAD: cylindricalDecomposition: empty list of vars")
       mv := first(lvars)
       lv := rest(lvars)
       lv = [] =>
         lp1 := [ univariate(pol) for pol in lpols ]
         scells := allSimpleCells(lp1,mv)$SCELL
         [ makeCell([scell]) for scell in scells ]
       lpols1 := projectionSet [univariate(pol,mv) for pol in lpols]
       previousCad := cylindricalDecomposition(lpols1,lv)
       res : List(CELL) := []
       for cell in previousCad repeat
         lspec := specialise(lpols,cell)
         scells := allSimpleCells(lspec,mv)
         res := append(res,[makeCell(scell,cell) for scell in scells])
       res


     PACK1 ==> CylindricalAlgebraicDecompositionUtilities(ThePols,RUP)
     PACK2 ==> CylindricalAlgebraicDecompositionUtilities(TheField,BUP)

     specialise(lpols,cell) ==
       lpols = [] => error("CAD: specialise: empty list of pols")
       sp := samplePoint(cell)
       vl := variablesOf(cell)
       res : List(BUP) := []
       for pol in lpols repeat
         p1 := univariate(eval(pol,vl,sp))
         degree(p1) = 0 => "next pol"
         res := cons(p1,res)
       res


     coefficientSet(pol) ==
       res : List(ThePols) := []
       for c in coefficients(pol) repeat
         ground?(c) => return(res)
         res := cons(c,res)
       res

     SUBRES ==> SubResultantPackage(ThePols,RUP)
     discriminantSet(lpols) ==
       res : List(ThePols) := []
       for p in lpols repeat
         v := subresultantVector(p,differentiate(p))$SUBRES
         not(zero?(degree(v.0))) => return(error "Bad discriminant")
         d : ThePols :=  leadingCoefficient(v.0)
         zero?(d) => return(error "Non Square Free polynomial")
         if not(ground? d) then res := cons(d,res)
       res

     principalSubResultantSet(p,q) ==
        if degree(p) < degree(q)
        then (p,q) := (q,p)
        if degree(p) = degree(q)
        then (p,q) := (q,pseudoRemainder(p, q))
        v := subresultantVector(p,q)$SUBRES
        [coefficient(v.i,i) for i in 0..(((#v)-2)::N)]

     resultantSet(lpols) ==
       res : List(ThePols) := []
       laux := lpols
       for p in lpols repeat
         laux := rest(laux)
         for q in laux repeat
           r : ThePols :=  first(principalSubResultantSet(p,q))
           zero?(r) => return(error "Non relatively prime polynomials")
           if not(ground? r) then res := cons(r,res)
       res

     projectionSet(lpols) ==
       res : List(ThePols) := []
       for p in lpols repeat
         c := content(p)
         ground?(c) => "next p"
         res := cons(c,res)
       lp1 := [primitivePart p for p in lpols]
       f : ((RUP,RUP) -> Boolean) := (degree(#1) <= degree(#2))
       lp1 := sort(f,lp1)
       lsqfrb := squareFreeBasis(lp1)$PACK1
       lsqfrb := sort(f,lsqfrb)
       for p in lp1 repeat
         res := append(res,coefficientSet(p))
       res := append(res,discriminantSet(lsqfrb))
       append(res,resultantSet(lsqfrb))


\start
From: daly@axiom-developer.org
Date: Sun, 7 Sep 2014 22:39:27 -0500
To: "Waldek Hebisch" <hebisch@math.uni.wroc.pl>
Subject: [Axiom-developer] CAD test cases

Waldek, 

Here are some CAD test cases with results.

Tim

========================================================================
\documentclass{article}
\usepackage{axiom}
\setlength{\textwidth}{400pt}
\begin{document}
\title{\$SPAD/src/input cad.input}
\author{Renaud Rioboo}
\maketitle
\begin{abstract}
\end{abstract}
\eject
\tableofcontents
\eject
\begin{chunk}{*}
)set break resume
)spool cad.output
)set message test on
)set message auto off
)clear all
 
--S 1 of 12
Ran := RECLOS(FRAC INT)
--R 
--R
--R   (1)  RealClosure(Fraction(Integer))
--R                                                                 Type: Domain
--E 1

--S 2 of 12
Cad := CAD(Ran)
--R 
--R
--R   (2)
--R   CylindricalAlgebraicDecompositionPackage(RealClosure(Fraction(Integer)))
--R                                                                 Type: Domain
--E 2

--S 3 of 12
p1 : POLY(Ran) := x^2+y^2-1
--R 
--R
--R         2    2
--R   (3)  y  + x  - 1
--R                             Type: Polynomial(RealClosure(Fraction(Integer)))
--E 3

--S 4 of 12
p2 : POLY(Ran) := y-x^2
--R 
--R
--R             2
--R   (4)  y - x
--R                             Type: Polynomial(RealClosure(Fraction(Integer)))
--E 4

--S 5 of 12
lpols : List(POLY(Ran)) := [p1,p2]
--R 
--R
--R          2    2          2
--R   (5)  [y  + x  - 1,y - x ]
--R                       Type: List(Polynomial(RealClosure(Fraction(Integer))))
--E 5

--S 6 of 12
cad := cylindricalDecomposition(lpols)$Cad;
--R 
--R
--R                             Type: List(Cell(RealClosure(Fraction(Integer))))
--E 6

--S 7 of 12
precision(30)
--R 
--R
--R   (7)  68
--R                                                        Type: PositiveInteger
--E 7

--S 8 of 12
ls := [ samplePoint cell for cell in cad]
--R 
--R
--R   (8)
--R                                                      1
--R   [[- 5,- 2], [4,- 2], [5,- 2], [- 2,- 1], [0,- 1], [-,- 1], [1,- 1], [2,- 1],
--R                                                      2
--R       113   7          7        7          7    339   7    49   7    113   7
--R    [- ---,- -], [%A5,- -], [0,- -], [%A6,- -], [---,- -], [--,- -], [---,- -],
--R        64   8          8        8          8    512   8    64   8    128   8
--R          2                 2                    2           2
--R    [- %A1  - 1,%A1], [- %A1 ,%A1], [0,%A1], [%A1 ,%A1], [%A1  + 1,%A1],
--R                         1             1                           2
--R    [- 2,0], [%A7,0], [- -,0], [0,0], [-,0], [%A8,0], [2,0], [- %A2  - 1,%A2],
--R                         2             2
--R          2                    2           2              113 7        7
--R    [- %A2 ,%A2], [0,%A2], [%A2 ,%A2], [%A2  + 1,%A2], [- ---,-], [%A9,-],
--R                                                           64 8        8
--R       7         7    339 7    49 7    113 7                    1
--R    [0,-], [%A10,-], [---,-], [--,-], [---,-], [- 2,1], [0,1], [-,1], [1,1],
--R       8         8    512 8    64 8    128 8                    2
--R    [2,1], [- 5,2], [4,2], [5,2]]
--R                             Type: List(List(RealClosure(Fraction(Integer))))
--E 8

--S 9 of 12
lf := [ [relativeApprox(coord,2^(-precision()))::Float for coord in point] for point in ls]
--R 
--R
--R   (9)
--R   [[- 5.0,- 2.0], [4.0,- 2.0], [5.0,- 2.0], [- 2.0,- 1.0], [0.0,- 1.0],
--R    [0.5,- 1.0], [1.0,- 1.0], [2.0,- 1.0], [- 1.765625,- 0.875],
--R    [- 0.48412292,- 0.875], [0.0,- 0.875], [0.48412292,- 0.875],
--R    [0.66210938,- 0.875], [0.765625,- 0.875], [0.8828125,- 0.875],
--R    [- 1.618034,- 0.78615138], [- 0.61803399,- 0.78615138], [0.0,- 0.78615138],
--R    [0.61803399,- 0.78615138], [1.618034,- 0.78615138], [- 2.0,0.0],
--R    [- 1.0,0.0], [- 0.5,0.0], [0.0,0.0], [0.5,0.0], [1.0,0.0], [2.0,0.0],
--R    [- 1.618034,0.78615138], [- 0.61803399,0.78615138], [0.0,0.78615138],
--R    [0.61803399,0.78615138], [1.618034,0.78615138], [- 1.765625,0.875],
--R    [- 0.48412292,0.875], [0.0,0.875], [0.48412292,0.875], [0.66210938,0.875],
--R    [0.765625,0.875], [0.8828125,0.875], [- 2.0,1.0], [0.0,1.0], [0.5,1.0],
--R    [1.0,1.0], [2.0,1.0], [- 5.0,2.0], [4.0,2.0], [5.0,2.0]]
--R                                                      Type: List(List(Float))
--E 9

--S 10 of 12
lp := [ point(term::List(DoubleFloat))$Point(DoubleFloat) for term in lf ]
--R 
--R
--R   (10)
--R   [[- 5.,- 2.], [4.,- 2.], [5.,- 2.], [- 2.,- 1.], [0.,- 1.], [0.5,- 1.],
--R    [1.,- 1.], [2.,- 1.], [- 1.765625,- 0.875],
--R    [- 0.48412291845306754,- 0.875], [0.,- 0.875],
--R    [0.48412291845306754,- 0.875], [0.662109375,- 0.875], [0.765625,- 0.875],
--R    [0.8828125,- 0.875], [- 1.6180339884012938,- 0.78615137748420238],
--R    [- 0.61803398933261633,- 0.78615137748420238], [0.,- 0.78615137748420238],
--R    [0.61803398933261633,- 0.78615137748420238],
--R    [1.6180339884012938,- 0.78615137748420238], [- 2.,0.], [- 1.,0.],
--R    [- 0.5,0.], [0.,0.], [0.5,0.], [1.,0.], [2.,0.],
--R    [- 1.6180339884012938,0.78615137748420238],
--R    [- 0.61803398933261633,0.78615137748420238], [0.,0.78615137748420238],
--R    [0.61803398933261633,0.78615137748420238],
--R    [1.6180339884012938,0.78615137748420238], [- 1.765625,0.875],
--R    [- 0.48412291845306754,0.875], [0.,0.875], [0.48412291845306754,0.875],
--R    [0.662109375,0.875], [0.765625,0.875], [0.8828125,0.875], [- 2.,1.],
--R    [0.,1.], [0.5,1.], [1.,1.], [2.,1.], [- 5.,2.], [4.,2.], [5.,2.]]
--R                                               Type: List(Point(DoubleFloat))
--E 10

--S 11 of 12
[ sign(eval(p1,variables(p1),samplePoint(cell))::Ran) for cell in cad ]
--R 
--R
--R   (11)
--R   [1, 1, 1, 1, 0, 1, 1, 1, 1, 0, - 1, 0, 1, 1, 1, 1, 0, - 1, 0, 1, 1, 0, - 1,
--R    - 1, - 1, 0, 1, 1, 0, - 1, 0, 1, 1, 0, - 1, 0, 1, 1, 1, 1, 0, 1, 1, 1, 1,
--R    1, 1]
--R                                                          Type: List(Integer)
--E 11

--S 12 of 12
[ sign(eval(p2,variables(p2),samplePoint(cell))::Ran) for cell in cad ]
--R 
--R
--R   (12)
--R   [- 1, 0, 1, - 1, - 1, - 1, 0, 1, - 1, - 1, - 1, - 1, - 1, 0, 1, - 1, - 1,
--R    - 1, 0, 1, - 1, - 1, - 1, 0, 1, 1, 1, - 1, - 1, - 1, 0, 1, - 1, - 1, - 1,
--R    - 1, - 1, 0, 1, - 1, - 1, - 1, 0, 1, - 1, 0, 1]
--R                                                          Type: List(Integer)
--E 12

)spool 
)lisp (bye)
 
\end{chunk}
\eject
\begin{thebibliography}{99}
\bibitem{1} nothing
\end{thebibliography}
\end{document}

\start
Date: Mon, 08 Sep 2014 08:06:42 +0200
From: Ralf Hemmecke <ralf@hemmecke.org>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] CAD package from Renaud Rioboo

On 09/08/2014 05:36 AM, daly@axiom-developer.org wrote:
> Waldek,
> 
> Here is Renaud's CAD package for your new release.
> 
> Tim

Thank you, Tim. Now you can no longer claim that you don't care for
FriCAS. ;-)

Anyway, I was already considering to prepare a patch for CAD.
Waldek, if you don't beat me with the integration, I can take over the
details of preparing a proper patch to get CAD into FriCAS. I'm just not
exactly sure where and how I have to add the testcases.

Ralf

PS: Because of family constraints it might take me longer than just one
evening.

\start
Date: Mon, 8 Sep 2014 02:03:09 -0500
From: daly@axiom-developer.org
To: Ralf Hemmecke <ralf@hemmecke.org>
Subject: Re: [Axiom-developer] CAD package from Renaud Rioboo

>On 09/08/2014 05:36 AM, daly@axiom-developer.org wrote:
>> Waldek,
>> 
>> Here is Renaud's CAD package for your new release.

Thank Renaud. He wrote it. 

See Renaud's Ph.D. thesis (I don't have a link for this)

Brown, Christopher W
"Solution Formula Construction for Truth Invariant CADs"
Ph.D. Thesis, Univ. Delaware (1999)
http://www.usna.edu/Users/cs/wcbrown/research/thesis.ps.gz

Brown, Christopher W.
"QEPCAD B -- A program for computing with semi-algebraic sets using CADs"


>> 
>> Tim
>
>Thank you, Tim. Now you can no longer claim that you don't care for
>FriCAS. ;-)

Ralf,

I have had only two lasting frustrations with FriCAS.

My first frustration was the confusion over names.  This seems to be
mostly resolved (modulo still using the AXIOM shell variable, which
causes conflicts).

My second frustration is the lack of documentation.  But that is a
fundamental philosophical difference and I don't see it ever getting
resolved. But then I'm something of a fanatic about it so maybe it's
my problem. :-)

Other than that, I'm all in favor of more and better algebra available
to everyone. Axiom isn't "mine" in any reasonable sense of the word. I
am just the guy leading the parade this week. So it seems only reasonable
to make sure the algebra is spread to FriCAS.

Renaud's CAD package is clean, easy to install, and should be widely
available, which is why I sent it. I would ask that any improvements
be returned in kind.

Tim

\start
Date: Mon, 08 Sep 2014 10:17:08 +0200
From: Ralf Hemmecke <ralf@hemmecke.org>
To: daly@axiom-developer.org
Subject: Re: [Axiom-developer] CAD package from Renaud Rioboo

Hi Tim,

> Thank Renaud. He wrote it. 

I know. And of course, credit also goes to him, but you are going
through the email archive and dig out important things so that they are
not forgotten. At least *I* appreciate that.

> I have had only two lasting frustrations with FriCAS.
> 
> My first frustration was the confusion over names.  This seems to be
> mostly resolved (modulo still using the AXIOM shell variable, which
> causes conflicts).

I'm somewhat surprised. Yes, FriCAS still uses the AXIOM environment
variable. And you probably know that this is deeply hardcoded inside the
code. But for FriCAS that is an internal detail that you shouldn't have
to care about unless you start AXIOMsys directly. (Yes, in FriCAS it's
still called AXIOMsys.) The reason is that FriCAS does not require to
set AXIOM before you call "fricas" on the command line. In fact, the
shell script "fricas" explicitly sets AXIOM, so it is restricted to this
invocation and shouldn't have any effect on anything outside FriCAS. Not
even should it have any effect if you set AXIOM to anything before
calling "fricas".

> My second frustration is the lack of documentation.

Right so. As you know, I'm working on http://fricas.github.io/ . That's
not literate, but at least makes the API more visible on the web. More
to come.

> Other than that, I'm all in favor of more and better algebra available
> to everyone.

Yes, that's good. The difference in philosophy perhaps is that FriCAS
tries more to attract people through the power of the system whereas you
want to do this with good literate documentation. Well, both directions
are needed. I think that the most important thing is to get more people
interested in the code whether that will work with your "literate"
approach or in the way that FriCAS does it, is yet to be seen. Anyway,
the more people start looking into the code/documentation, the higher
the chances that it improves faster.

> Renaud's CAD package is clean, easy to install, and should be widely
> available, which is why I sent it. I would ask that any improvements
> be returned in kind.

Of course. In fact, I've recently subscribed to
https://github.com/daly.atom in order to follow, what you are doing. You
are probably doing the same with https://github.com/fricas.atom . I'm
all in favour of helping each other even though we have differing
opinions about the future direction of the project.

Ralf

\start
Date: Mon, 8 Sep 2014 11:11:06 +0200
From: Raoul <raoulb@bluewin.ch>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] CAD package from Renaud Rioboo

Hi,


> > Here is Renaud's CAD package for your new release.

Great to see that the CAD code got some attention
not only in Axiom. It seems I'm too late but anyway
wanted to point out:

  https://github.com/raoulb/fricas_code/tree/master/cad


-- Raoul

\start
Date: Mon, 08 Sep 2014 14:38:32 +0200
From: Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] Cylindrical Algebraic Decomposition added

Dear Axiom gurus,

> Is there a paper related to the code or other documentation I should
> reference? If so, I'd like your permission to quote parts of it as
> part of Axiom's documentation.

I mailed Tim the dvi for my thesiis but this is a very old document
which does not really explain the package and it is written in French.

The main results of my thesis were about symbolic integration and real
algebraic numbers. There is no new algorithm in my CAD implementation
though in my thesis I mention a Lazard projection which Daniel published
but was later proved to be wrong.

All the best

\start
Date: Mon, 08 Sep 2014 14:50:04 +0200
From: Ralf Hemmecke <ralf@hemmecke.org>
To: Renaud Rioboo <Renaud.Rioboo@ensiie.fr>, 
	axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] Cylindrical Algebraic Decomposition added

On 09/08/2014 02:38 PM, Renaud Rioboo wrote:
> I mailed Tim the dvi for my thesiis but this is a very old document
> which does not really explain the package and it is written in French.
> 
> The main results of my thesis were about symbolic integration and real
> algebraic numbers. There is no new algorithm in my CAD implementation
> though in my thesis I mention a Lazard projection which Daniel published
> but was later proved to be wrong.

Well, since Tim (and actually me too) want to see the description of the
algorithm, it would be rather interesting if you could point out which
paper(s) you used when you implemented CAD in AXIOM.

Nowadays, it's certainly not hard to find a good description about CAD,
but what is most interesting, is what paper(s) *you* followed when
implementing it. That would make this particular implementation easier
to understand/maintain.

Thank you
Ralf

\start
Date: Mon, 8 Sep 2014 11:07:37 +0200
From: someone <somebody@bluewin.ch>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] CAD package from Renaud Rioboo

Hi,


> > Here is Renaud's CAD package for your new release.

It seems I'm too late. Great to see that the CAD
code got some attention here.

Just wanted to point out:

  https://github.com/raoulb/fricas_code/tree/master/cad

\start
Date: Tue, 9 Sep 2014 16:03:43 +0200 (CEST)
From: Waldek Hebisch <hebisch@math.uni.wroc.pl>
To: daly@axiom-developer.org
Subject: Re: [Axiom-developer] CAD package from Renaud Rioboo

> 
> Waldek,
> 
> Here is Renaud's CAD package for your new release.

Thanks.  However, I have a compilable version for FriCAS.
I have waited to have clear copyright situation.  Currently
FriCAS is BSD licenced while IIRC the CAD pacakge is GPL.
Including it in FriCAS would effectively change FriCAS
licence to GPL.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

\start
Date: Tue, 09 Sep 2014 16:57:12 +0200
From: Ralf Hemmecke <ralf@hemmecke.org>
To: fricas-devel@googlegroups.com, axiom-dev <axiom-developer@nongnu.org>, 
	Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
Subject: Re: [Axiom-developer] [fricas-devel] Re: CAD package from Renaud
	Rioboo

On 09/09/2014 04:03 PM, Waldek Hebisch wrote:
> Thanks.  However, I have a compilable version for FriCAS.

Huh? Where?

> I have waited to have clear copyright situation.  Currently FriCAS is
> BSD licenced while IIRC the CAD pacakge is GPL.

GPL? What are your sources for this claim?

Axiom is BSD licensed. And Renaud Rioboo writes in

http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00125.html

==========================
Recently Martin Rubey thought it could be a good idea to release them and I
have of course no objection on that point nor on sharing these sources with
the community. If there is some interest on it you may include it into the
Axiom distribution with the same permissions than the rest of the software.

While I wait for my lab to give me the necessary permissions to be able
to use
Axiom and export this software you may find it's sources at the unlisted url


http://rioboo.free.fr/CadPub/
==========================

That sounds as if that is licensing the source code under BSD. I don't
exactly understand what is meant by "permission to be able to use Axiom
and export this software". Maybe he meant the commercial version of Axiom.

> Including it in FriCAS would effectively change FriCAS licence to
> GPL.

In fact, I'd love FriCAS under GPL.

But no, if FriCAS includes a SPAD source package under GPL that doesn't
change the license of FriCAS to GPL. It changes the license of a
*binary* distribution to GPL, so that such a binary distribution must be
accompanied with sources and the whole thing must be GPL.

You would then still be allowed to distribute the FriCAS sources under
BSD with one (or several) source files under GPL. Since there is no
linking in the source-only distribution, nothing in the GPL 3.0 license
text says that a mere packaging of BSD and GPL files would automatically
make the BSD files be licensed under GPL. IANAL, but I'm pretty sure
that the FSF argues in the same way.

Ralf

\start
Date: Tue, 9 Sep 2014 23:42:36 +0200 (CEST)
From: Waldek Hebisch <hebisch@math.uni.wroc.pl>
To: fricas-devel@googlegroups.com
Subject: Re: [Axiom-developer] [fricas-devel] Re: CAD package from Renaud
	Rioboo

> 
> On 09/09/2014 04:03 PM, Waldek Hebisch wrote:
> > Thanks.  However, I have a compilable version for FriCAS.
> 
> Huh? Where?

In my machine.

> > I have waited to have clear copyright situation.  Currently FriCAS is
> > BSD licenced while IIRC the CAD pacakge is GPL.
> 
> GPL? What are your sources for this claim?
> 
> Axiom is BSD licensed. And Renaud Rioboo writes in
> 
> http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00125.html
> 
> ==========================
> Recently Martin Rubey thought it could be a good idea to release them and I
> have of course no objection on that point nor on sharing these sources with
> the community. If there is some interest on it you may include it into the
> Axiom distribution with the same permissions than the rest of the software.
> 
> While I wait for my lab to give me the necessary permissions to be able
> to use
> Axiom and export this software you may find it's sources at the unlisted url
> 
> 
> http://rioboo.free.fr/CadPub/
> ==========================
> 
> That sounds as if that is licensing the source code under BSD. I don't
> exactly understand what is meant by "permission to be able to use Axiom
> and export this software". Maybe he meant the commercial version of Axiom.

AFAICS the above does not really give us any rights: my understanding
is Renaud Rioboo can not give us such right without permission
of his institution.

There was recent message (which I can not fing ATM) that he
got permission to distribute it under GPL.  Gaby asked about
BSD to fit Axiom licence, but AFAICS up to now there is no
definite answer.

> > Including it in FriCAS would effectively change FriCAS licence to
> > GPL.
> 
> In fact, I'd love FriCAS under GPL.
> 
> But no, if FriCAS includes a SPAD source package under GPL that doesn't
> change the license of FriCAS to GPL. It changes the license of a
> *binary* distribution to GPL, so that such a binary distribution must be
> accompanied with sources and the whole thing must be GPL.
> 
> You would then still be allowed to distribute the FriCAS sources under
> BSD with one (or several) source files under GPL. Since there is no
> linking in the source-only distribution, nothing in the GPL 3.0 license
> text says that a mere packaging of BSD and GPL files would automatically
> make the BSD files be licensed under GPL. IANAL, but I'm pretty sure
> that the FSF argues in the same way.

If it is "mere aggregation", then why bother, we can put updated
version for example in the wiki.  OTOH, if build system is
adjusted so that files get included into binary, then FSF
claims that GPL affects also sources (read their "success
story" about Objective C (needs gcc) and clisp (needs readline)).

Of course since we distribute sources, anybody wanting pure BSD
can remove GPL-ed parts as long as the rest does not depend on
them.  But if we keep such part indpendent, then there is little
benefit compared to distributing package separately.  OTOH
if other parts of FriCAS start depending on it, then GPL
affects all FriCAS sources.

Currently almost all files in FriCAS use BSD type licence.
Exceptions (for example configure or axiom.sty)
may be considerd inessential from licence point of view.
Putting  into repository normal source file under different
licence means that we (and anybody caring about licence) would
have to track licence on file-by-file basis.  If there is a
strong reason such tracking is doable, but IMO benefits
do not justify this.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

\start
Date: Tue, 9 Sep 2014 17:45:43 -0500
From: daly@axiom-developer.org
To: Waldek Hebisch <hebisch@math.uni.wroc.pl>
Subject: [Axiom-developer] license

Axiom contains a subdirectory "/license" which contains copies of the
license found in the various source files, for instance, the noweb
license in license/license.noweb.

I notice that FriCAS doesn't have those files anymore, which is odd.

Tim

\start
Date: Tue, 9 Sep 2014 17:54:39 -0500
From: daly@axiom-developer.org
To: Renaud.Rioboo@ensiie.fr (Renaud Rioboo)
Subject: [Axiom-developer] license

Renaud,

Since the subject came up, is there a license associated with CAD?
I am working on the assumption that since you provided sources
there is the assumed permission to use and redistribute them.
If you object, please let me know.

I have exchanged emails with Richard Stallman and he has stated 
that the BSD license and the GPL3 license are compatible. Since
Axiom follows the four freedoms anyway there is no issue about
distributing sources or sending improvements back to the original
project. Returning improvements to the project that provided 
the original sources is the only ethical thing to do anyway.

Tim

\start
Date: Wed, 10 Sep 2014 08:35:46 +0200
From: Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] Cylindrical Algebraic Decomposition added

Hi,

> Well, since Tim (and actually me too) want to see the description of th=
e
> algorithm, it would be rather interesting if you could point out which
> paper(s) you used when you implemented CAD in AXIOM.
>=20
> Nowadays, it's certainly not hard to find a good description about CAD,
> but what is most interesting, is what paper(s) *you* followed when
> implementing it. That would make this particular implementation easier
> to understand/maintain.

Well, that is a hard question since it's been almost 25 years... As far
as I remember I had the papers of Arnon, Collins and Mc Callum, the book
by Davenport, Siret and Tournier, the book by Buchberger, Collins and
Loos. There was no web by the time.

Furthermore I had a colleague working with the SAC2 implementation of
quantifier elimination and benefited from numerous discussions with
Michel Coste, Marie Fran=E7oise Roy and Jean Jacques Risler.

But I am not sure I ever understood CAD, the package produces lists of
cells :-)

All the best

\start
Date: Wed, 10 Sep 2014 08:48:31 +0200
From: Renaud Rioboo <Renaud.Rioboo@ensiie.fr>
To: axiom-dev <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] [fricas-devel] Re: CAD package from Renaud
	Rioboo

Dear Axiom Gurus,

> Axiom is BSD licensed. And Renaud Rioboo writes in
> 
> http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00125.html
> 
> ==========================
> Recently Martin Rubey thought it could be a good idea to release them and I
> have of course no objection on that point nor on sharing these sources with
> the community. If there is some interest on it you may include it into the
> Axiom distribution with the same permissions than the rest of the software.
> 
> While I wait for my lab to give me the necessary permissions to be able
> to use
> Axiom and export this software you may find it's sources at the unlisted url
> 
> 
> http://rioboo.free.fr/CadPub/
> ==========================

You can put any kind of free license on my code.

When I was at UPMC there were concerns about software licenses in
particular for the real closure package which was inside NAG's Axiom.
Things have much evolved now and we may distribute software with free
license.

All the best

\start
Date: Thu, 11 Sep 2014 03:27:18 +0200 (CEST)
From: Waldek Hebisch <hebisch@math.uni.wroc.pl>
To: Renaud.Rioboo@ensiie.fr (Renaud Rioboo)
Subject: Re: [Axiom-developer] [fricas-devel] Re: CAD package from Renaud

Renaud Rioboo wrote:
> 
> Dear Axiom Gurus,
> 
> > Axiom is BSD licensed. And Renaud Rioboo writes in
> > 
> > http://lists.gnu.org/archive/html/axiom-developer/2005-10/msg00125.html
> > 
> > ==========================
> > Recently Martin Rubey thought it could be a good idea to release them and I
> > have of course no objection on that point nor on sharing these sources with
> > the community. If there is some interest on it you may include it into the
> > Axiom distribution with the same permissions than the rest of the software.
> > 
> > While I wait for my lab to give me the necessary permissions to be able
> > to use
> > Axiom and export this software you may find it's sources at the unlisted url
> > 
> > 
> > http://rioboo.free.fr/CadPub/
> > ==========================
> 
> You can put any kind of free license on my code.
> 
> When I was at UPMC there were concerns about software licenses in
> particular for the real closure package which was inside NAG's Axiom.
> Things have much evolved now and we may distribute software with free
> license.
> 

Thank you, now situatiobn is clear.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

\start
Date: Sat, 13 Sep 2014 23:50:06 +0400
From: Aleksej Saushev <asau@inbox.ru>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] solaris

u1204 <daly@axiom-developer.org> writes:

>>Greetings!  Are solaris and or Windows (mingw and cygwin) targets of
>>interest?  If so, what AXIOM setting works here?
>
> Solaris? Does that still exist? I don't have access to a Solaris box
> anymore. I thought it sat in the corner with Multics and MVS. I would
> have no idea how to set up the environment for it. Has anyone ported
> texlive?

Not only Solaris does exist, it perceives a revival.
The only problem is that neither GCL nor Axiom are useful there.
ECL and FriCAS/OpenAxiom are.


-- 
HE CE3OH...

\start
Date: Sat, 13 Sep 2014 15:51:52 -0500
From: daly@axiom-developer.org
To: Aleksej Saushev <asau@inbox.ru>
Subject: [Axiom-developer] solaris

>>>Greetings!  Are solaris and or Windows (mingw and cygwin) targets of
>>>interest?  If so, what AXIOM setting works here?
>>
>> Solaris? Does that still exist? I don't have access to a Solaris box
>> anymore. I thought it sat in the corner with Multics and MVS. I would
>> have no idea how to set up the environment for it. Has anyone ported
>> texlive?
>
>Not only Solaris does exist, it perceives a revival.
>The only problem is that neither GCL nor Axiom are useful there.
>ECL and FriCAS/OpenAxiom are.

I'm not sure what point you are trying to make. 

Axiom has been run on Lisp/VM, Symbolics, Gold Hill, AIX, and DOS.
It isn't difficult to make it run anywhere but such porting efforts
take time away from the primary project goals.

Axiom's primary goal is to be well documented, easily maintained, and
easily modified.  Axiom is a research effort aimed at teaching and new
development.

If you need it to run on Solaris or Windows, there is no advantage in
using a native port. Axiom runs in Oracle's Virtualbox and in VMWare.
It is trivial to install VirtualBox for free.
http://www.virtualbox.org

If you install the xming server for Windows you can run Axiom
in the virtualbox and use x11 windows on the Windows desktop.
http://sourceforge.net/projects/xming

Given these tools it seems you can run Axiom without much effort.
You get the added benefit that GCL is optimized for running Axiom
so it runs faster in VirtualBox on GCL than on native ECL.

Tim

\start
Date: Sun, 14 Sep 2014 01:41:03 +0400
From: Aleksej Saushev <asau@inbox.ru>
To: daly@axiom-developer.org
Subject: Re: [Axiom-developer] solaris

daly@axiom-developer.org writes:

>>>>Greetings!  Are solaris and or Windows (mingw and cygwin) targets of
>>>>interest?  If so, what AXIOM setting works here?
>>>
>>> Solaris? Does that still exist? I don't have access to a Solaris box
>>> anymore. I thought it sat in the corner with Multics and MVS. I would
>>> have no idea how to set up the environment for it. Has anyone ported
>>> texlive?
>>
>>Not only Solaris does exist, it perceives a revival.
>>The only problem is that neither GCL nor Axiom are useful there.
>>ECL and FriCAS/OpenAxiom are.
>
> I'm not sure what point you are trying to make. 
>
> Axiom has been run on Lisp/VM, Symbolics, Gold Hill, AIX, and DOS.
> It isn't difficult to make it run anywhere but such porting efforts
> take time away from the primary project goals.

Probably, but I'm speaking about platforms that are actively used and
developed today rather than something that went off the scene two decades ago.
There's no practical use for software than ran on Symbolics
if it doesn't run on up-to-date system.

> Axiom's primary goal is to be well documented, easily maintained, and
> easily modified.  Axiom is a research effort aimed at teaching and new
> development.
>
> If you need it to run on Solaris or Windows, there is no advantage in
> using a native port. Axiom runs in Oracle's Virtualbox and in VMWare.

At this point almost any reasonable person would say that Axiom is
more of a failure as software project:
 - there exist well maintained and more maintainable forks;
 - they work at least equally well, if not better.

Not to mention that one cannot even build (original) Axiom easily
due to somewhat trashy build system even by standards of decade ago.

Making claims that one can use Parallels, VMWare, VirtualBox, or QEMU
doesn't change anything. Using native port is always an advantage.
It sounds as if you have never actively used software that requires VM.

> Given these tools it seems you can run Axiom without much effort.
> You get the added benefit that GCL is optimized for running Axiom
> so it runs faster in VirtualBox on GCL than on native ECL.

Dubious until proven. Even if it is so, with FriCAS and OpenAxiom
I can use better CL implementation than anything of KCL family.

My main point is that instead of wasting time into supporting one of the
worst maintained CL implementations (substandard, dormant for a decade
or two, very limited number of supported platforms, one man effort)
you'd rather have invested time into integrating build system improvements
Gabriel and/or Waldek did before leaving the project. One of advantages
of open-source software that is easy to build by anyone rather than only
by single developer is that it is easier for other people to become
involved into development. In particular, using autoconf brings you
closer to your goal of maintainability and modifiability than supporting
selected number of platforms (subset of those supported by GCL)
and recommending others to use Parallels or WMware.


-- 
HE CE3OH...

\start
Date: Sat, 13 Sep 2014 18:30:34 -0500
From: daly@axiom-developer.org
To: Aleksej Saushev <asau@inbox.ru>
Subject: Re: [Axiom-developer] solaris

>>>>>Greetings!  Are solaris and or Windows (mingw and cygwin) targets of
>>>>>interest?  If so, what AXIOM setting works here?
>>>>
>>>> Solaris? Does that still exist? I don't have access to a Solaris box
>>>> anymore. I thought it sat in the corner with Multics and MVS. I would
>>>> have no idea how to set up the environment for it. Has anyone ported
>>>> texlive?
>>>
>>>Not only Solaris does exist, it perceives a revival.
>>>The only problem is that neither GCL nor Axiom are useful there.
>>>ECL and FriCAS/OpenAxiom are.
>>
>> I'm not sure what point you are trying to make. 
>>
>> Axiom has been run on Lisp/VM, Symbolics, Gold Hill, AIX, and DOS.
>> It isn't difficult to make it run anywhere but such porting efforts
>> take time away from the primary project goals.
>
>Probably, but I'm speaking about platforms that are actively used and
>developed today rather than something that went off the scene two decades ago.
>There's no practical use for software than ran on Symbolics
>if it doesn't run on up-to-date system.

Axiom does run on 'up-to-date' systems, just not ones you want to use.

Hmmm. Let me explain something to you which you seem to misunderstand.

*YOU* want Axiom to run on Solaris. You have access to Solaris.
You have the Axiom source code. You have the need. You have the time.

*I* want Axiom well documented so the code lives after I die.
I don't have access to Solaris (although I could if I made the effort).
I post source code and changes on an almost daily basis for your use.
I work on Axiom approximately 60 hours a week and have done so for the
last 14 years. I have a list of current tasks I estimate will take 7
years to complete. Time is one thing *I* don't have.

I spent a lot of time making Axiom ports over the years. Indeed, I'm
the person who rewrote it from Maclisp/LispVM to Common Lisp. So I
am well aware that I could easily make it run on ECL/SBCL/etc. and
on Solaris/Windows/OSX. I don't have the need. I don't have the time.

It seems to me that if you want to create a Solaris port you can do it.
And, if you want to maintain Axiom on Solaris, you can submit the port
or self-host it and regularly update it.





>> Axiom's primary goal is to be well documented, easily maintained, and
>> easily modified.  Axiom is a research effort aimed at teaching and new
>> development.
>>
>> If you need it to run on Solaris or Windows, there is no advantage in
>> using a native port. Axiom runs in Oracle's Virtualbox and in VMWare.
>
>At this point almost any reasonable person would say that Axiom is
>more of a failure as software project:
> - there exist well maintained and more maintainable forks;
> - they work at least equally well, if not better.

So, according to your metrics, Axiom is a failure.  And, according to
your reasoning by hasty generalization, 'everyone' considers Axiom a
failure. You see no value at all in Axiom. So why are you posting here?




>Not to mention that one cannot even build (original) Axiom easily
>due to somewhat trashy build system even by standards of decade ago.

Typing 'make' doesn't qualify as 'easily'? Sigh.

Of course, I authored that "somewhat trashy build system" and it was
over 3 decades ago. But you shouldn't worry as eventually the whole
build system will be in lisp, making it a new trashy build system
based on technology from 1960!




>Making claims that one can use Parallels, VMWare, VirtualBox, or QEMU
>doesn't change anything. Using native port is always an advantage.
>It sounds as if you have never actively used software that requires VM.

I was a systems programmer on IBM/370 VM in 1978. I wrote portions of
the memory management system for a high-performance improvement.
I know a bit more about VM technology than you give me credit for.





>> Given these tools it seems you can run Axiom without much effort.
>> You get the added benefit that GCL is optimized for running Axiom
>> so it runs faster in VirtualBox on GCL than on native ECL.
>
>Dubious until proven. Even if it is so, with FriCAS and OpenAxiom
>I can use better CL implementation than anything of KCL family.

So use them. Axiom isn't in a competition. Axiom obviously addresses a
need you don't have. 

GCL was originally AKCL which was written by Bill Schelter under
contract with IBM specifically to support Scratchpad (now Axiom).
I'm also a minor co-author having worked on the garbage collector
and tail recursion. Bill Schelter shared my office on occasion.
We worked to make AKCL run Axiom very efficiently and much better
than existing Common Lisp implementations. 




>My main point is that instead of wasting time into supporting one of the
>worst maintained CL implementations (substandard, dormant for a decade
>or two, very limited number of supported platforms, one man effort)
>you'd rather have invested time into integrating build system improvements
>Gabriel and/or Waldek did before leaving the project. One of advantages
>of open-source software that is easy to build by anyone rather than only
>by single developer is that it is easier for other people to become
>involved into development. 

You'd like Axiom to be rewritten to build using Autoconf, which involves
more machinery and a dependence on specific autoconf versions (check
the mailing list for discussions). Oh, and Autoconf uses that trashy
build machinery called 'make' and an obscure macro language 'm4'.
But, hey, it's "modern and up-to-date" so it's better, right?

Axiom is removing external dependencies. Eventually Axiom will no
longer need 'make' at all. Indeed, the build system will be pure lisp.






>                              In particular, using autoconf brings you
>closer to your goal of maintainability and modifiability than supporting
>selected number of platforms (subset of those supported by GCL)
>and recommending others to use Parallels or WMware.

You missed the point of 'maintainability and modifiability'. The build
system isn't what needs to be maintained. Do you understand the type
hierarchy and the underlying mathematics?  Do you know how to add a
Category to Axiom? Do you understand the type lattice?  Can you modify
the Axiom interpreter? If ncAlist throws an error at level 73 in the
call stack can you debug it?  Do you know how to maintain the Axiom
compiler?  Do you know how to build test cases or add to the computer
algebra test suite?

The build system is a wart on the back of this hugely complex piece
of software. There are tens of thousands of projects in sourceforge
and github that used autoconf and are dead because nobody knows what
they do or how to maintain and modify the main software. Only the
lead developer knew and he documented nothing. That way lies death.




As for 'wasting time'... it does seem to be my time to waste, right?

I see you make a lot of assertions, snide remarks, and biased remarks
against Axiom and GCL. What I don't see are contributions. Port Axiom
to native Solaris. Merge the Autoconf changes you want. Use ECL. 
Package it and post a link. That's how open source works.

Axiom isn't a product, it is a research effort. 

Tim

\start
Date: Sun, 14 Sep 2014 15:17:18 +0400
From: Aleksej Saushev <asau@inbox.ru>
To: daly@axiom-developer.org
Subject: Re: [Axiom-developer] solaris

daly@axiom-developer.org writes:

>>>>>>Greetings!  Are solaris and or Windows (mingw and cygwin) targets of
>>>>>>interest?  If so, what AXIOM setting works here?
>>>>>
>>>>> Solaris? Does that still exist? I don't have access to a Solaris box
>>>>> anymore. I thought it sat in the corner with Multics and MVS. I would
>>>>> have no idea how to set up the environment for it. Has anyone ported
>>>>> texlive?
>>>>
>>>>Not only Solaris does exist, it perceives a revival.
>>>>The only problem is that neither GCL nor Axiom are useful there.
>>>>ECL and FriCAS/OpenAxiom are.
>>>
>>> I'm not sure what point you are trying to make. 
>>>
>>> Axiom has been run on Lisp/VM, Symbolics, Gold Hill, AIX, and DOS.
>>> It isn't difficult to make it run anywhere but such porting efforts
>>> take time away from the primary project goals.
>>
>>Probably, but I'm speaking about platforms that are actively used and
>>developed today rather than something that went off the scene two decades ago.
>>There's no practical use for software than ran on Symbolics
>>if it doesn't run on up-to-date system.
>
> Axiom does run on 'up-to-date' systems, just not ones you want to use.
>
> Hmmm. Let me explain something to you which you seem to misunderstand.
>
> *YOU* want Axiom to run on Solaris. You have access to Solaris.
> You have the Axiom source code. You have the need. You have the time.
>
> *I* want Axiom well documented so the code lives after I die.
> I don't have access to Solaris (although I could if I made the effort).
> I post source code and changes on an almost daily basis for your use.
> I work on Axiom approximately 60 hours a week and have done so for the
> last 14 years. I have a list of current tasks I estimate will take 7
> years to complete. Time is one thing *I* don't have.
>
> I spent a lot of time making Axiom ports over the years. Indeed, I'm
> the person who rewrote it from Maclisp/LispVM to Common Lisp. So I
> am well aware that I could easily make it run on ECL/SBCL/etc. and
> on Solaris/Windows/OSX. I don't have the need. I don't have the time.
>
> It seems to me that if you want to create a Solaris port you can do it.
> And, if you want to maintain Axiom on Solaris, you can submit the port
> or self-host it and regularly update it.

Sorry, but as of today I have no guarantee that my work is not wasted.
This work has been done at least once long ago, but you haven't merged it.
Thus, what you say effectively, is that I can create my own fork,
do the same work once again and hope that you merge it. Given the past
of your project I'm more inclined to think that this hope is in vain.

You don't need to tell me about how little time you have.
I observed your project for a long time, and what I see is that you had
collaborators who made Axiom work on ECL, SBCL, and some other
implementations. Instead of making use of their work you wasted it,
so they left.

>>Not to mention that one cannot even build (original) Axiom easily
>>due to somewhat trashy build system even by standards of decade ago.
>
> Typing 'make' doesn't qualify as 'easily'? Sigh.

Yes, it doesn't qualify as "easily" since it doesn't work.
In order to make it work one has to invest a lot of effort.
So it isn't "easily".

> Of course, I authored that "somewhat trashy build system" and it was
> over 3 decades ago. But you shouldn't worry as eventually the whole
> build system will be in lisp, making it a new trashy build system
> based on technology from 1960!

Meanwhile you're going to work effectively alone.

>>Making claims that one can use Parallels, VMWare, VirtualBox, or QEMU
>>doesn't change anything. Using native port is always an advantage.
>>It sounds as if you have never actively used software that requires VM.
>
> I was a systems programmer on IBM/370 VM in 1978. I wrote portions of
> the memory management system for a high-performance improvement.
> I know a bit more about VM technology than you give me credit for.

Sorry, but how does that experience apply here? Programmers have
absolutely no knowledge of related problems unless they worked closely
with the first line of technical support.

>>> Given these tools it seems you can run Axiom without much effort.
>>> You get the added benefit that GCL is optimized for running Axiom
>>> so it runs faster in VirtualBox on GCL than on native ECL.
>>
>>Dubious until proven. Even if it is so, with FriCAS and OpenAxiom
>>I can use better CL implementation than anything of KCL family.
>
> GCL was originally AKCL which was written by Bill Schelter under
> contract with IBM specifically to support Scratchpad (now Axiom).
> I'm also a minor co-author having worked on the garbage collector
> and tail recursion. Bill Schelter shared my office on occasion.
> We worked to make AKCL run Axiom very efficiently and much better
> than existing Common Lisp implementations. 

How does this supports the claim?

>>My main point is that instead of wasting time into supporting one of the
>>worst maintained CL implementations (substandard, dormant for a decade
>>or two, very limited number of supported platforms, one man effort)
>>you'd rather have invested time into integrating build system improvements
>>Gabriel and/or Waldek did before leaving the project. One of advantages
>>of open-source software that is easy to build by anyone rather than only
>>by single developer is that it is easier for other people to become
>>involved into development. 
>
> You'd like Axiom to be rewritten to build using Autoconf, which involves
> more machinery and a dependence on specific autoconf versions (check
> the mailing list for discussions). Oh, and Autoconf uses that trashy
> build machinery called 'make' and an obscure macro language 'm4'.
> But, hey, it's "modern and up-to-date" so it's better, right?
>
> Axiom is removing external dependencies. Eventually Axiom will no
> longer need 'make' at all. Indeed, the build system will be pure lisp.

No. So far all I can see is that you miss the point totally.

Autoconf does the job for many people. Your make machinery does the job
only for you and, perhaps, for very few lucky ones.
Whether you're going to make Axiom CL-only eventually or not,
that doesn't matter at all. What matters is the collaboration.
You may have little time to work on autoconf, fine. Others did that.
All you need is to merge their work. Autoconf is a clear improvement
over what you have, and it doesn't stop elimination of dependencies or
rewriting everything in CL.

>>                              In particular, using autoconf brings you
>>closer to your goal of maintainability and modifiability than supporting
>>selected number of platforms (subset of those supported by GCL)
>>and recommending others to use Parallels or WMware.
>
> You missed the point of 'maintainability and modifiability'. The build
> system isn't what needs to be maintained. Do you understand the type
> hierarchy and the underlying mathematics?  Do you know how to add a
> Category to Axiom? Do you understand the type lattice?  Can you modify
> the Axiom interpreter? If ncAlist throws an error at level 73 in the
> call stack can you debug it?  Do you know how to maintain the Axiom
> compiler?  Do you know how to build test cases or add to the computer
> algebra test suite?
>
> The build system is a wart on the back of this hugely complex piece
> of software. There are tens of thousands of projects in sourceforge
> and github that used autoconf and are dead because nobody knows what
> they do or how to maintain and modify the main software. Only the
> lead developer knew and he documented nothing. That way lies death.

Nobody can do any serious work on a system one cannot even build.
This is especially true for working on core features like the
interpreter or adding test cases so that they work.

> As for 'wasting time'... it does seem to be my time to waste, right?
>
> I see you make a lot of assertions, snide remarks, and biased remarks
> against Axiom and GCL. What I don't see are contributions. Port Axiom
> to native Solaris. Merge the Autoconf changes you want. Use ECL. 
> Package it and post a link. That's how open source works.
>
> Axiom isn't a product, it is a research effort. 

That's because I'm not interested in fixing GCL. There're better CL
implementations around. The reason why you don't see my contributions
is that they all went to FriCAS and OpenAxiom. I don't have time to see
what happens to research effort that isn't a product.

"Package it and post a link" is not the way open source works. At least
successful projects don't work this way. Somehow they try to merge
contributions faster and manage to have more developers.

As for "snide remarks"... Well... Check the archive of your own list.
You can see noticable decline in population since 2007. The list has
degraded to a monologue with occasional cross-postings from FriCAS list.
You have alienated nearly all your original contributors.
I don't understand how you want to overcome the problem of "only the
lead developer knows..." in such conditions. Even if you manage to
finish your magnum opus, there's no guarantee for it to be continued
or even maintained.

And last, when you claim that it's only your time that is wasted,
remember not to complain all over the Internet how nobody helps you
or understands your ideas. Perhaps, they find that your ideas nice
but reject the way you implement them.


-- 
HE CE3OH...

\start
Date: Sun, 14 Sep 2014 06:29:12 -0500
From: daly@axiom-developer.org
To: Aleksej Saushev <asau@inbox.ru>
Subject: [Axiom-developer] solaris

I'm unable to help you. 
I'm sorry if that offends you as that was never my intention.
In any case, I feel no need to continue this discussion.

Tim

\start
Date: Sun, 14 Sep 2014 11:47:43 -0400
From: Camm Maguire <camm@maguirefamily.org>
To: Aleksej Saushev <asau@inbox.ru>
Subject: Re: [Axiom-developer] solaris

Greetings!  GCL 2.6.11 fully supports solaris.

Take care,

Aleksej Saushev <asau@inbox.ru> writes:

> u1204 <daly@axiom-developer.org> writes:
>
>>>Greetings!  Are solaris and or Windows (mingw and cygwin) targets of
>>>interest?  If so, what AXIOM setting works here?
>>
>> Solaris? Does that still exist? I don't have access to a Solaris box
>> anymore. I thought it sat in the corner with Multics and MVS. I would
>> have no idea how to set up the environment for it. Has anyone ported
>> texlive?
>
> Not only Solaris does exist, it perceives a revival.
> The only problem is that neither GCL nor Axiom are useful there.
> ECL and FriCAS/OpenAxiom are.

-- 
Camm Maguire			     		    camm@maguirefamily.org

\start
Date: Sun, 14 Sep 2014 21:49:01 -0500
From: daly@axiom-developer.org
To: Camm Maguire <camm@maguirefamily.org>
Subject: [Axiom-developer] solaris

Camm,

GCL is not the problem with a solaris port.

Solaris does not include texlive support (for free anyway).  So Axiom
would have to be adjusted to build without using TeX.  While that is
technically possible it goes against the project goals. 

Tim

\start
Date: Sun, 14 Sep 2014 20:26:59 -0700
From: C Y <smustudent1@yahoo.com>
To: "daly@axiom-developer.org" <daly@axiom-developer.org>,
	Camm Maguire <camm@maguirefamily.org>
Subject: Re: [Axiom-developer] solaris

> On Sunday, September 14, 2014 10:49 PM, "daly@axiom-developer.org" <daly@axiom-developer.org> wrote:

> > Camm,
> 
> GCL is not the problem with a solaris port.
> 
> Solaris does not include texlive support (for free anyway).  So Axiom
> would have to be adjusted to build without using TeX.  While that is
> technically possible it goes against the project goals. 

For what it's worth...

I took a stab at taking texlive and trying to boil out a "minimalist" or "modular" subset that would be easier to understand and support - I got as far as producing a basic TeX executable, but (from what I remember) I stalled out (hopefully temporarily) when I realized a lot of shell scripts needed to be converted to something more portable (probably C++ - one of the goals is to be able to just build and run on Windows...).  The goals of that effort are a bit different from Axiom's in terms of portability (CMake is used quite a bit) but perhaps the work there might be helpful as a starting point for making some kind of "portable, minimalist TeX" to support Axiom's needs...

What has been done so far is at https://github.com/starseeker/ModTeX if it's of any help/interest.  Of course, if the goal is to have the whole system in lisp cl-typesetting might be a more logical starting point, although it looks the "current" code for that on their website was last updated in 2006...  I suppose the purest way to go would be to implement the necessary TeX pieces in Lisp directly, but at that level of effort it starts to make sense to just require texlive and focus on more important things.

Cheers,
CY

\start
Date: Sun, 14 Sep 2014 20:34:21 -0700
From: C Y <smustudent1@yahoo.com>
To: "daly@axiom-developer.org" <daly@axiom-developer.org>,
	Camm Maguire <camm@maguirefamily.org>
Subject: Re: [Axiom-developer] solaris

> On Sunday, September 14, 2014 11:26 PM, C Y <smustudent1@yahoo.com> wrote:
> > 
> 
> 
>>  On Sunday, September 14, 2014 10:49 PM, 
> "daly@axiom-developer.org" <daly@axiom-developer.org> wrote:
> 
>>  > Camm,
>> 
>>  GCL is not the problem with a solaris port.
>> 
>>  Solaris does not include texlive support (for free anyway).  So Axiom
>>  would have to be adjusted to build without using TeX.  While that is
>>  technically possible it goes against the project goals. 
> 
> For what it's worth...
> 
> I took a stab at taking texlive and trying to boil out a "minimalist" 
> or "modular" subset that would be easier to understand and support - I 
> got as far as producing a basic TeX executable, but (from what I remember) I 
> stalled out (hopefully temporarily) when I realized a lot of shell scripts 
> needed to be converted to something more portable (probably C++ - one of the 
> goals is to be able to just build and run on Windows...).  The goals of that 
> effort are a bit different from Axiom's in terms of portability (CMake is 
> used quite a bit) but perhaps the work there might be helpful as a starting 
> point for making some kind of "portable, minimalist TeX" to support 
> Axiom's needs...
> 
> What has been done so far is at https://github.com/starseeker/ModTeX if it's 
> of any help/interest.  Of course, if the goal is to have the whole system in 
> lisp cl-typesetting might be a more logical starting point, although it looks 
> the "current" code for that on their website was last updated in 
> 2006...  I suppose the purest way to go would be to implement the necessary TeX 
> pieces in Lisp directly, but at that level of effort it starts to make sense to 
> just require texlive and focus on more important things.
> 
> Cheers,
> CY

Ah, correction - looks like cl-typesetting (and cl-pdf) ended up living on github:

https://github.com/mbattyani/cl-typesetting
https://github.com/mbattyani/cl-pdf

Even better, he's switched to a 2-clause BSD license (no advertising requirement).

Hmm.  Now I have a dilemma.  That license is excellent, and it's all in Lisp... wonder what it would take to get it to support TeX/LaTeX.

CY

\start
Date: Mon, 15 Sep 2014 00:43:17 -0500
From: daly@axiom-developer.org
To: C Y <smustudent1@yahoo.com>
Subject: [Axiom-developer] solaris

Cliff, 

I'm not sure what you mean by a "minimalist TeX executable". Are
you thinking of producing a TeX in lisp? That would be amazing!

What shell scripts are you having trouble with? I don't recall
writing shell scripts for anything but I write a lot of code so
it wouldn't surprise me. We can certainly eliminate existing ones.

Latex runs on Windows, or used to centuries ago. It was called MikTeX
http://miktex.org

GCL also runs on Windows. 

I don't recall using anything fancy in 'make' that would not work
everywhere but I haven't tried a cygwin build in years so I don't know
if it works. 

I have Xming installed and it runs X11 windows on Windows. I use
VirtualBox to run Axiom and Xming when I want something native (really
rare). See
http://sourceforge.net/projects/xming

Axiom used to run on Windows. The instructions are on 
http://axiom-developer.org/axiom-website/download.html
The last time I tried to make a native version I spent a week
uncovering a bug in the MinGW compiler. Compiler bugs are painful.

VirtualBox is by far the easiest and fastest way to get something
portable running. In fact, we could probably make a Docker image
that would just drop in place.

Axiom does, and will always, depend on TeX/LaTeX. As I learn more I
add features, both in axiom.sty (where I added a command today to add
axiom-like signatures to lisp code) and in the bibliography document
where, at Ralf's prodding, I am actively rewriting to use bibtex as we
speak.

The 'make' machinery will go away at some point. Axiom doesn't
really need any of the features. We need to create a build
function in lisp that knows how to build Axiom. Small portions
are already in books/tangle.lisp to automatically extract the
help files and the input files.

Camm has done work to make Axiom run without including GCL. Once
I get some time I will insert his changes. After that, we need a
lisp (build) function to replace 'make'. It is really trivial to
create since all it does is the same sequence make currently uses
(which is printed on the console). At that point, 'make' machinery
is gone. This might happen before the next release but I wouldn't
count on it.

X11 replacement is under development to be replaced by a browser (see
Volume 11). This involves moving hyperdoc and moving the graphics.

The browser front end currently allows Axiom notebook-like interaction
(you type an expression and see the result) as well as hyperdoc-style
browsing (only some of the pages have been converted so far).

The graphics port to the browser will require using a canvas.  (Scott
Morrison's command of graphics has me cracking open my Foley and Van
Dam book.)  I've done some canvas programming with javascript to test
examples.  I'd like to use the new websocket interface so the canvas
can do interactive commands back to axiom (my attempt to use it
failed, probably due to a misconfiguration somewhere).

I've also been working on a Neural Net package. I recently added
graphviz support to enable drawing the network defined by the
equations and weights. The ultimate goal is to show the images
learned at each layer as it learns so the deep learning people
can use Axiom to play with the underlying equations.

Now that noweb is gone, GCL is becoming external, make will disappear,
the console, hyperdoc, and graphics will be in a web browser. 

Axiom will eventually only depend on a C compiler, latex, and lisp,
assuming your browser is up to date.

It is all "in motion"... it just takes time....

Tim

\start
Date: Mon, 15 Sep 2014 00:57:28 -0500
From: daly@axiom-developer.org
To: C Y <smustudent1@yahoo.com>
Subject: [Axiom-developer] cl-typesetting

cl-typesetting is cool. I like what he's doing.

I don't think it can replace latex if only for the simple
reason that every time I need to do something there are
thousands of web pages of help and hundreds of packages.

Tim

\start
Date: Mon, 15 Sep 2014 05:12:05 -0700
From: C Y <smustudent1@yahoo.com>
To: "daly@axiom-developer.org" <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] cl-typesetting

> On Monday, September 15, 2014 1:57 AM, "daly@axiom-developer.org" <daly@axiom-developer.org> wrote:
> > cl-typesetting is cool. I like what he's doing.
> 
> I don't think it can replace latex if only for the simple
> reason that every time I need to do something there are
> thousands of web pages of help and hundreds of packages.

Heh.  My thinking/hope there was that if the TeX "core" algorithms could be reproduced on top of cl-typesetting, past a certain point the LaTeX packages would start to work "as-is" on top of the new core the same way they currently work with TeX/TeXlive.  I don't know enough to know if that's how things would shake out - it needs investigation, one of the things I was hoping to learn in the ModTeX effort, actually - but the other side of that coin is that any one application (like, say Axiom) is only going to use a subset of the universe of TeX packages.  TeXlive in lisp isn't necessary per say...

CY

\start
Date: Mon, 15 Sep 2014 05:12:25 -0700
From: C Y <smustudent1@yahoo.com>
To: "daly@axiom-developer.org" <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] solaris

> On Monday, September 15, 2014 1:43 AM, "daly@axiom-developer.org" <daly@axiom-developer.org> wrote:

> > Cliff, 
> 
> I'm not sure what you mean by a "minimalist TeX executable". Are
> you thinking of producing a TeX in lisp? That would be amazing!

That wasn't my thought with ModTeX - there, I just wanted to get a handle on what made up TeXlive and whether it was possible to (say) build a version with a lot fewer libraries and packages if all you wanted to do was convert basic TeX with no fancy packages into DVI files, old-school Knuth style.  The idea was to be able to "bootstrap" a complete literate programming environment portably from nothing but a C/C++ compiler.

I wasn't actually targeting ModTeX at Axiom per say - I was just looking into what would be involved with making a "pre-packaged" literate programming environment that could easily be incorporated into and bootstrapped by projects as part of their standard build, in order to minimize the additional system infrastructure that has to be installed for the paradigm to work.

I've been tempted in the past to dig into cl-typesetting to try and create a Lisp TeX front-end for it, but the advertising-clause license and total lack of documentation ended up as blockers.  (Oddly, enough, cl-bibtex already exists so that's one piece already handled...)  Now with the license change it's probably worth digging into it for real, if CAD weren't eating up 110% of my available coding time these days...

> What shell scripts are you having trouble with? I don't recall
> writing shell scripts for anything but I write a lot of code so
> it wouldn't surprise me. We can certainly eliminate existing ones.

The shell scripts are part of TeXlive, not Axiom.

> The 'make' machinery will go away at some point. Axiom doesn't
> really need any of the features. We need to create a build
> function in lisp that knows how to build Axiom. Small portions
> are already in books/tangle.lisp to automatically extract the
> help files and the input files.

Long ago, Stephen Wilson and I did some experiments with ASDF to make it pamphlet aware:

http://brlcad.org/~starseeker/asdf-literate.lisp.pamphlet
brlcad.org/~starseeker/asdf-literate.pdf

My recollection is that this actually ended up working reasonably well, although obviously for Axiom's new pamphlet set up it would need some rework.

> Camm has done work to make Axiom run without including GCL. Once
> I get some time I will insert his changes. After that, we need a
> lisp (build) function to replace 'make'. It is really trivial to
> create since all it does is the same sequence make currently uses
> (which is printed on the console). At that point, 'make' machinery
> is gone. This might happen before the next release but I wouldn't
> count on it.

OK, so ASDF is probably overkill then.

> Axiom will eventually only depend on a C compiler, latex, and lisp,
> assuming your browser is up to date.

*Very* nice.

> It is all "in motion"... it just takes time....

Amen.

CY

\start
Date: Mon, 15 Sep 2014 05:24:32 -0700
From: C Y <smustudent1@yahoo.com>
To: "daly@axiom-developer.org" <daly@axiom-developer.org>
Subject: Re: [Axiom-developer] solaris

> On Monday, September 15, 2014 1:43 AM, "daly@axiom-developer.org" <daly@axiom-developer.org> wrote:

> The browser front end currently allows Axiom notebook-like interaction
> (you type an expression and see the result) as well as hyperdoc-style
> browsing (only some of the pages have been converted so far).
> 
> The graphics port to the browser will require using a canvas.  (Scott
> Morrison's command of graphics has me cracking open my Foley and Van
> Dam book.)  I've done some canvas programming with javascript to test
> examples.  I'd like to use the new websocket interface so the canvas
> can do interactive commands back to axiom (my attempt to use it
> failed, probably due to a misconfiguration somewhere).

Out of curiosity, does the WebGL work have any implications for the browser-as-interface paradigm, either for 3D plotting or possibly as a complete "generic canvas" solution?  I confess I hadn't really thought too deeply about it since I'm one of those old fogies who vastly prefers a purpose-built interface for most things as opposed to browser-as-interface, but as I consider interfaces like that of Blender and the push towards WebGL it occurs to me that a pure OpenGL interface (probably excepting key bindings and events, as usual) might be able to do lots of really cool things on all sorts of devices...

CY

\start
From: daly@axiom-developer.org
Date: Mon, 15 Sep 2014 08:00:51 -0500
To: C Y <smustudent1@yahoo.com>
Subject: [Axiom-developer] 3D solid models

>> The browser front end currently allows Axiom notebook-like interaction
>> (you type an expression and see the result) as well as hyperdoc-style
>> browsing (only some of the pages have been converted so far).
>> 
>> The graphics port to the browser will require using a canvas.  (Scott
>> Morrison's command of graphics has me cracking open my Foley and Van
>> Dam book.)  I've done some canvas programming with javascript to test
>> examples.  I'd like to use the new websocket interface so the canvas
>> can do interactive commands back to axiom (my attempt to use it
>> failed, probably due to a misconfiguration somewhere).

>Out of curiosity, does the WebGL work have any implications for the
>browser-as-interface paradigm, either for 3D plotting or possibly as
>a complete "generic canvas" solution?  I confess I hadn't really
>thought too deeply about it since I'm one of those old fogies who
>vastly prefers a purpose-built interface for most things as opposed
>to browser-as-interface, but as I consider interfaces like that of
>Blender and the push towards WebGL it occurs to me that a pure OpenGL
>interface (probably excepting key bindings and events, as usual)
>might be able to do lots of really cool things on all sorts of
>devices...

>CY

I'm reading up on the pipeline and have done some minor attempts
at using patches on 3D objects (image on a cube). 3D solid models
in Axiom would be most amazing but I'd be happy to reproduce the
current graphics. I was involved with 3D solid models in my 
robotics work at IBM on the BOXER project. We had a locally built
tool that worked like CATIA.

Tim

\start
Date: Mon, 15 Sep 2014 09:21:07 -0500
From: daly@axiom-developer.org
To: "William Sit" <wyscc@sci.ccny.cuny.edu>
Subject: Re: [Axiom-developer] 3D solid models

Actually, what I would like to do is hook Axiom up to Pontiflex
which is a bridge building program.

Axiom could attach a DHMatrix (4x4 matrix) at each end of every
beam to model the forces at each connection. Then we could
mathematically compose the forces, apply stress/strain curves
for the chosen material (e.g. steel), and predict when and where
the bridge would fail. 

There could be a BEAM class with property functions (e.g. 
strain(matrix,matrix) -> elongation
with domains implementing the functions for different materials.

In Pontiflex one can impose loads on the bridge to see it fail.
Axiom could try to predict the failures.

It would make a great game, educational without the pain.

ah, if I only had the time...

\start
Date: Mon, 15 Sep 2014 18:29:17 -0500
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] katex looks very interesting

KaTeX looks very interesting...
http://khan.github.io/KaTeX

Tim

\start
Date: Wed, 17 Sep 2014 04:26:47 -0500
From: daly@axiom-developer.org
To: Geeth Munasinghe <geethmks@gmail.com>
Subject: Re: [Axiom-developer] Server goes OOM when

Geeth,

This is the mailing list for a computer algebra program:
http://axiom-developer.org

not the financial program.

Tim Daly
Axiom Lead Developer

\start
Date: Thu, 25 Sep 2014 07:24:07 -0500
\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}

From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] [off topic but read this] well, this is bad

try the following line on any machine you have (BASH bug)
env 'x=() { :;}; echo vulnerable' bash -c echo 'test'

if you get the string 'vulnerable' (and you will because it fails in
all versions of bash on osx and linux) then anyone anywhere can make
your machine do anything remotely.

essentially, the bug is that after defining a function bash in an
environment string will continue to execute the rest of the line which
could be anything.

for details see:
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html

Tim



\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
