Re: [fricas-devel] Re: [Axiom-mail] InputForm

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

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

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

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

Tim