Bill Page wrote:
>
> On Mon, Sep 15, 2008 at 2:52 PM, Martin Rubey wrote:
> > ...
> > Bill Page wrote:
> >> The only other alternative for _sage_ in axiom.py that I can see would be
> >> to write something that interprets the S-expression output of InputForm
> >> directly.
> >
> > This may be necessary anyway. I think the plan should be as follows: as
> > you said already, we would like to have interpret(x::INFORM) equal to the
> > result of evaluating x (in a fresh environment). I believe, to make this
> > work
> > properly, x::INFORM should be fully type-decorated. It seems that this is
> > also the current strategy, some examples below.
> >
>
> Ok, comments on examples below. After reviewing this, I am not sure
> what "fully type-decorated" should mean.
>
> > Then, we can implement a package SagePackage analogous to OutputPackage,
> > that exports a single function sage: INFORM -> String. Actually, maybe it's
> > better to implement this in sage, because it should be possible to pass
> > INFORM objects as python nested lists of symbols, without going to strings?
> >
>
> > (4) -> (factor(x^2-1))::INFORM
> >
> > (4)
> > (* (primeFactor (:: (+ x - 1) (Polynomial (Integer))) 1)
> > (primeFactor (:: (+ x 1) (Polynomial (Integer))) 1))
> > Type: InputForm
>
> If we wanted this to be "fully decorated" why not this?
>
> (* (primeFactor (:: (+ (:: x Symbol) - (:: 1 Integer)) (Polynomial
> (Integer))) (:: 1 Integer))
> (primeFactor (:: (+ (:: x Symbol) (:: 1 Integer)) (Polynomial
> (Integer))) (::1 Integer)))
>
> How much can/should be assumed about the library, e.g. the existence
> and signature of 'primeFactor' and the coercions that will be
> automatically applied by the interpreter?
>
Conversion to InputForm _is_ part of the library -- for example
convert in Boolean knows that 'true' and 'false' exist in Boolean.
For simple cases we may assume that intepreter will do right things.
But in general we probably need constructs like:
(1$Integer)@Integer
That is: make sure argument are of correct type, package call the
operation and use @ to be really sure that correct signature is
selected.
> > (10) -> (1::COMPLEX INT)::INFORM
> >
> > (10) (complex 1 0)
> > Type: InputForm
> >
>
> Here we do not see any type decorations. Do we say this is ok since
> the signature of 'complex' is known? But 'complex' comes from
> Complex(R) for some parameter R that is given here only implicitly.
>
We have:
(6) -> (1::(COMPLEX POLY INT))::INFORM
(6) (complex 1 0)
Type: InputForm
Which looks wrong: we will get Complex Integer instead of Complex
Polynomial Integer.
> > I think for aggregates we can have a general rule, but we need a way to
> > specify
> > package calls
> >
> > (15) -> construct([1,2,3])$PRIMARR INT::INFORM
> > Internal Error
> > The function convert with signature hashcode is missing from domain
> > PrimitiveArray(Integer)
> >
The above is because convertion to InputForm is unimplemented for
PrimitiveArray, but PrimitiveArray Integer has ConvertibleTo InputForm.
In fact, in Collection(S) we have
....
if S has ConvertibleTo InputForm then ConvertibleTo InputForm
which does not look right: AFAIK our streams also are collections and
are represented by functions. Since we have no way to convert
functions to input forms, there is no way to convert streams
to InputForm.
For finite collections we probably can give reasonable implementation
using members (and package calls).
BTW, to get better convertion to InputForm (and more generally for
use in Sage interface) we need a way to convert types to
InputForm. The following is a first approximation of such
functionality:
)abbrev package GETTYNM GetTypeName
GetTypeName(T : Type) : with
getTypeName : () -> InputForm
== add
getTypeName() == (devaluate(T)$Lisp) pretend InputForm
I say that this is first approximation because it does not handle
correctly types which have ordinary values as parameters -- we
should convert such parameters to InputForm, but we do not
do this (packageCall has the same problem)
BTW2: I found the following (stolen form fortpak.spad) usefull
when experimenting with InputForm:
parse(s:String):InputForm ==
ncParseFromString(s)$Lisp::InputForm
Note that documentation of unparse says that it should work on
output of parse, so that parse(unparse(parse(s))) should
give the same result as parse(s). However, unparse in not
guaranteed to handle more general forms.
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
