On Tue, Oct 14, 2008 at 2:44 PM, Gabriel Dos Reis wrote:
> On Tue, Oct 14, 2008 at 1:07 PM, Bill Page wrote:
>> On Tue, Oct 14, 2008 at 12:19 PM, Gabriel Dos Reis wrote:
>>>
>>> I want
>>>
>>> '(x + y)
>>>
>>> to be InputForm, not an OutputForm -- and I already has a patch
>>> for that. But, that is only a tiny part of the story.
>>>
>>
>> Of course since there is a simple conversion from OutputForm to
>> InputForm you can also write:
>>
>> (1) -> '(x+y)::OutputForm::InputForm
>>
>> (1) (+ x y)
>> Type: InputForm
>>
>> if you wish.
>
> Again, I did not say "impossible". If one has to write the above
> to get '(+ x y) into the system, then the something is wrong with
> the interface.
>
Before one can say "something is wrong" I think it is first necessary
to state what are the design intentions of a particular feature - How
is it supposed to work? Of course this is often very difficult in the
original Axiom where so little of these design decisions were
documented.
So far as I can see it was not the intention of the design to make it
easy to enter commands in the OutputForm notation of the domain
InputForm. Instead its seems that it was expected that most InputForm
values in the interpreter would be generated either by conversion from
other values or by parsing an input string. E.g.
(1) -> parseString("x+y")$InputForm
(1) (+ x y)
Type: InputForm
I am not convinced that the "cut-and-paste" application suggested by
Stephen where OpenAxiom output is to be "pasted back" as input is
sufficiently well-defined. The problem is that neither the OutputForm
nor even the InputForm (as generated by most current domains) contains
sufficient semantics to reliably recreate a given value from either
the external form alone. It is essential to also know the type.
(2) -> exp1:Expression Integer := x+y
(2) y + x
Type: Expression Integer
(3) -> interpret(exp1::InputForm)
(3) y + x
Type: Polynomial Integer
(4) -> interpret(exp1::InputForm)$InputFormFunctions1(Expression Integer)
(4) y + x
Type: Expression Integer
---------
Although it is displayed as "Polynomial Integer", the actual type of
result (3) is "Any". This kind of "duck typing" is necessary because
every function in OpenAxiom must return a value of a fixed type. This
issue is avoided in (4) by the use of a package call.
Exactly these same issues arise in the current Axiom interface in
Sage. Since Sage objects are strongly typed it is desirable to be able
to convert the result of Axiom computations to Sage objects of the
appropriate type. Of course I would like the solution of these
problems to be easily portable among the Axiomata and I would also
like it to be easy for Sage users to choose the variant of Axiom they
want simply by installing the appropriate external package. As I
mentioned earlier, I have been thinking about this problem and
discussed it on the FriCAS list in the context of the extensions to
the existing Axiom interface in Sage.
In principle it is possible to combine both value and type information
into a single InputForm value. For example, this is the output
generated by a patch that I have proposed for FriCAS:
(1) -> sqrt(2)::InputForm
(1) (:: (** 2 (/ 1 2)) (AlgebraicNumber))
Type: InputForm
Here the desired type of the value is given by the final conversion.
The problem is that I am not convinced that this is really such a good
idea. I think a better approach is probably to ensure that all domains
export some reliable value constructor, following the model given by
the domain Float:
(2) -> 3.141592::InputForm
(2) (float 231808574432053350722 - 66 2)
Type: InputForm
So for the case of AlgebraicNumber I think a better result would be:
(algebraicNumber (** 2 (/ 1 2)) )
The trouble with this is that this will require a change to almost all
domains. I have proposed a solution to this problem on the FriCAS list
by relating InputForm values to the Rep of the domain. In principle
this would allow us to easily define a default constructor function
for each domain, but the objection has been raised that this at least
partially exposes the particular choice of Rep for a domain and
therefore violates information hiding.
I would be very interested in your opinions on this and I would very
much like to discuss this further with other interested parties.
Regards,
Bill Page.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
