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