On Tue, Nov 25, 2008 at 11:16 PM, Martin Rubey
<[EMAIL PROTECTED]> wrote:
>
> "Tim Lahey" <[EMAIL PROTECTED]>:
>
> a hint: the simplification facilities in FriCAS are not extremely powerful
> (because they try to be correct - in vain).  The closest thing to "simplify" 
> in
> Maxima, Maple, Mathematica etc., is probably "normalize".
>
> "William Stein" <[EMAIL PROTECTED]> writes:
>
>> Half true -- yes it is in text form, but do not think that means you can't
>> really do much with it.  When you do
>>
>>     sage: f.integrate()
>>
>> in Sage right now, f gets turned into text form, evaluated by Maxima,
>> integrated, the result gets returned in text form... and we *do* do a lot
>> to it -- we implement a complete parser that turns Maxima expressions
>> back into native Sage expressions.   It's a page or 2 of code in
>> calculus.py.  There's nothing that stops us from doing the same
>> with FriCAS; in fact, it's inevitable that will happen.
>
> Actually, a huge part of this has already been done.  In FriCAS, there is a
> domain "InputForm", that does the following ("::" is the FriCAS-coercion
> operator):
>
> (1) -> f := (x^2-1)/x + 1/(x+exp x)
>
>          2       x    3
>        (x  - 1)%e  + x
>   (1)  ----------------
>               x    2
>           x %e  + x
>                                                    Type: Expression(Integer)
> (2) -> g := D(exp(f)/exp(x),x)
>
>                           2       x    3
>                         (x  - 1)%e  + x
>                         ----------------
>                                x    2
>           x    2           x %e  + x
>        (%e  - x  + 2x)%e
>   (2)  ---------------------------------
>               2   x 2     3  x    4
>              x (%e )  + 2x %e  + x
>                                                    Type: Expression(Integer)
> (3) -> integrate(g, x)
>
>            2       x    3
>          (x  - 1)%e  + x
>          ----------------
>                 x    2
>             x %e  + x
>        %e
>   (3)  ------------------
>                  x
>                %e
>                                         Type: Union(Expression(Integer),...)
> (4) -> integrate(g, x)::INFORM
>
>   (4)
>   (/
>
>     (exp
>      (/ (+ (* (+ (** x 2) - 1) (exp x)) (** x 3)) (+ (* x (exp x)) (** x 2))))
>
>    (exp x))
>                                                              Type: InputForm
>
>
> Now, (4) is (intended) to be the precise equivalent of (3).  We are currently
> thinking about making it *more* precise, i.e., providing package call
> annotation ("$" is the FriCAS package-call operator):
>
> (5) -> s := (1..5)$Segment Fraction Integer
>
>   (5)  1..5
>                                             Type: Segment(Fraction(Integer))
> (6) -> s::INFORM
>
>   (6)  (($elt (Segment (Fraction (Integer))) SEGMENT) 1 5)
>                                                              Type: InputForm
> atom? (op := first l) => op is the operation, rest are the arguments
>
>                 else => first op  is $elt,
>                         second op is the package or domain
>                         third op  is the operation.
>
> So, in the above, op = ($elt (Segment (Integer)) SEGMENT) It's not an atom, so
> the package/domain is "Segment Integer", the operation is "SEGMENT".  Indeed:
>
> (7) -> SEGMENT(1,5)$Segment (Fraction (Integer))
>
>   (7)  1..5
>                                             Type: Segment(Fraction(Integer))
>
> while, without specifying the domain we would get something else:
>
> (8) -> SEGMENT(1,5)
>
>   (8)  1..5
>                                               Type: Segment(PositiveInteger)
>
>
> It should be relatively straightforward to write a domain "SageForm" that
> returns a string that Sage can understand.  It's unclear to me whether it 
> would
> be better to do it in Sage or in FriCAS, both has it's merits.  In both cases,
> synchronising of names will be necessary.

It's probably best to do a little of both.  That's what I'm doing with the
Sage/Magma interface -- the interface has extensive code written in
Magma and code written in Python.   For converting back from Magma to
Sage, a lot of the interesting code is (or will be) written in Magma
itself; that's
just the most natural thing to do.

With the Sage/Maxima interface we ended up not writing any of the code
in Maxima, since the 1-d maxima print format is actually already incredibly
easy to parse.  This is not at all the case for Magma, whose default
output format
is nearly useless for parsing.

>
> For cooperation: is there an equivalent of "InputForm" in Sage?  I.e., given 
> an
> object ("output"), is there a way to have Sage output a string ("input"), 
> which
> fed back into Sage gives "output"?  (Should be something like a textform of
> "dumps")

No.  Carl Witty did write something that was meant to
accomplish this, and it is in Sage, but it requires that tons of code be
written all over Sage to implement it, and this has not happened (and
currently isn't happening, as far as I know).   But this is for *arbitrary*
Sage objects.   For all of the symbolic calculus expressions, we do have
code that creates a corresponding version of said calculus for output
to Maxima (everything works), Mathematica, Maple, Fricas (?), etc.

William

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to