Martin,
Maybe this is already clear to you but I think it is important to get
one's mind around the fact that the Sage interface treats things in
FriCAS like objects whose methods are implemented by FriCAS. So for
example
sage: x=fricas('x')
sage: y=fricas('y')
sage: z=x+y
sage: type(z)
<class 'sage.interfaces.fricas.FriCASElement'>
even though the third line above makes no mention of FriCAS explicitly. Then
sage: zs = z.sage()
sage: type(zs)
<type
'sage.rings.polynomial.multi_polynomial_libsingular.MPolynomial_libsingular'>
And
sage: zf=fricas(zs)
sage: type(zf)
<class 'sage.interfaces.fricas.FriCASElement'>
Things like 'fricas.eval()' are low-level functions which operate on
strings and not normally used explicitly when using FriCAS through the
Sage interface.
On 12 August 2016 at 09:38, 'Martin R' via FriCAS - computer algebra
system <[email protected]> wrote:
>>
>> Except for the use of ioHook that sounds almost like what the
>> interface does now.
>
>
> Yes, it's quite close. It's mainly an idea for organising the code. Note
> that, for example, fricas(1/2).sage() is currently not working.
>
> I have already written a little. Currently I'm trying to find out whether
> fricas.eval is supposed to return a string - I'd like it to return my
> tuple...
>
fricas.eval() is supposed to return a string. That is fairly
fundamental to the external interface design in Sage.
Bill Page.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
