FormatMathematica

[Ralf Hemmecke]

I sometimes want to compare FriCAS output with that what Mathematica
returns and also wanted to be able to cut&paste FriCAS expressions to
Mathematica without always having the need to change the syntax
manually. I therefore modified Format1D in such a way that it shows
Mathematica syntax.

Of course, that cannot be perfect, because OutputForm is an output
format and does not contain enough information. Nevertheless, the
attached file produces Mathematica expressions for many common cases.

Please try your favourite expression(s) and let me know where I should
adapt something.

Use as follows:

)compile fmtmma.spad
strmma x ==>
first(lines(format(format(x::OutputForm)$Formatter(FormatMathematica))))
dispmma x ==> display(x::OutputForm::Formatter(FormatMathematica))

strmma(sin(x)^(a+tan(x^(-1))))
dispmma(sin(x)^(a+tan(x^(-1))))
dispmma(sum(sin(k*x),k=1..n))

===============================
%%% (33) -> strmma(sin(x)^(a+tan(x^(-1))))

(33) "Sin[x]^(Tan[1/x]+a)"
Type: String
%%% (34) -> dispmma(sin(x)^(a+tan(x^(-1))))
Sin[x]^(Tan[1/x]+a)
Type: Void
%%% (35) -> dispmma(sum(sin(k*x),k=1..n))
[OUTPUTFORM = k = 1, SEXPRESSION = (= k 1)]
Sum[Sin[k*x], {k, 1, n}]
Type: Void

Ralf

[Kurt Pagani]

Hi Ralf

Das ist "cool". Da ich das Gegenstück dazu habe

https://github.com/nilqed/spadlib/tree/master/mmaparse

können die "MMA Fans" (ich bin keiner ;-) FriCAS auch benutzen :)

Ich wollte den Parser einmal für Rubi->Fricas benutzen, aber das war
mir dann doch zuviel Arbeit, um all die MMA Funktionen zu übersetzen.
Vielleicht versuche ich es nochmals, falls mir langweilig wird,

Beste Grüsse
Kurt

> --
> 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 fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/81040453-ba21-463d-aa48-7b871ee676ef%40hemmecke.org.

[Dima Pasechnik]

On 14 March 2025 10:24:03 GMT-05:00, Kurt Pagani <nil...@gmail.com> wrote:
>Hi Ralf
>
>Das ist "cool". Da ich das Gegenstück dazu habe
>
>https://github.com/nilqed/spadlib/tree/master/mmaparse
>
>können die "MMA Fans" (ich bin keiner ;-) FriCAS auch benutzen :)
>
>Ich wollte den Parser einmal für Rubi->Fricas benutzen, aber das war
>mir dann doch zuviel Arbeit, um all die MMA Funktionen zu übersetzen.
>Vielleicht versuche ich es nochmals, falls mir langweilig wird,

There is also a way to interface Fricas with MMAs via SageMath, which has interfaces to Maple, Matlab, Magma, and Mathematica.

Just in case,
Dima

[Ralf Hemmecke]

Hi Dima,

On 3/14/25 17:34, Dima Pasechnik wrote:
> There is also a way to interface Fricas with MMAs via SageMath,
> which has interfaces to Maple, Matlab, Magma, and Mathematica.

Yes, I heard, but had no reason to use it up to

1) Do you have some examples for a back and forth work between FriCAS
and MMA via Sage? A URL to the respective docs would be fine.

2) How is the FriCAS connection. And as far as I remember the connection
to FriCAS does not cover everything.

Ralf

[Kurt Pagani]

Ouch, sorry for writing in German ... was not my intention to answer@all :(

>> There is also a way to interface Fricas with MMAs via SageMath, which has interfaces to Maple, Matlab, Magma, and Mathematica.

Yes, I know and that's why it wasn't worthwhile to follow up this Rubi affair. I thought once it might be easy (though conversion to CL is) to translate, however, there are too many side conditions in the rules ...

[Dima Pasechnik]

On Fri, Mar 14, 2025 at 11:45 AM 'Ralf Hemmecke' via FriCAS - computer
algebra system <fricas...@googlegroups.com> wrote:
>
> Hi Dima,
>
> On 3/14/25 17:34, Dima Pasechnik wrote:
> > There is also a way to interface Fricas with MMAs via SageMath,
> > which has interfaces to Maple, Matlab, Magma, and Mathematica.
> Yes, I heard, but had no reason to use it up to
>
> 1) Do you have some examples for a back and forth work between FriCAS
> and MMA via Sage? A URL to the respective docs would be fine.

Basically, it's always system_foo->Sage->system_bar.
Not directly system_foo->system_bar.
Which is a meaningful design, as there are too many systems, and
having one interface
for each of them, as opposed to one for each pair of them, is cheaper.


sage: with hold: # to prevent Sage from evaluating i
....: i=integral(sin(x),x)
....: m=mathematica(i)
....: f=fricas(m)
....:
sage: i,m,f
(integrate(sin(x), x), -Cos[x], - cos(x))
sage: list(map(type,(i,m,f)))
[<class 'sage.symbolic.expression.Expression'>,
<class 'sage.interfaces.mathematica.MathematicaElement'>,
<class 'sage.interfaces.fricas.FriCASElement'>]
sage:

By the way, here it's actually wolframscript, not "real" MMA. I
installed wolframscript
and made a symbolic link called "math" pointing to wolframscript.

>
> 2) How is the FriCAS connection. And as far as I remember the connection
> to FriCAS does not cover everything.

it doesn't at the moment, in particular, IIRC, rootsum stuff is not implemented.

Dima

>
> Ralf
>
> --
> 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 fricas-devel...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/fb965b59-622e-4db5-aa97-cb72a64d7f12%40hemmecke.org.

[Dima Pasechnik]

By the way, if you have a student (undergrad or postgrad) who's
eligible for GSoC, and is willing to work on improving FriCAS
interface with Sage/Python, please urge them to apply for GSoC with
Sage.
We were thinking about e.g. building a loadable, into Python, or C,
FriCAS module, based on libsbcl, as one project we'd
be interested in having.

https://summerofcode.withgoogle.com/organizations/sagemath/profile

Dima

[Qian Yun]

Hi Dima,

About the FriCAS-SageMath interface, and about making
FriCAS a standard package in SageMath, could you open
a meta bug in GitHub to track the progress?

I guess a better interface (C-based or socket-based,
more robust and performant than current text-based)
is needed. And SageMath needs to support "RootSum",
or the interface needs another way to translate
the "%%A1" algebraic numbers.


Hi Waldek,

One of the FriCAS development goals is:
"make it easier for external programs to interface with FriCAS"

Do you think communication via socket is a good idea,
or "SBCL as a shared library" is better,
or is there a third way?

- Best,
- Qian

[Waldek Hebisch]

On Sat, Mar 15, 2025 at 08:32:08PM +0800, Qian Yun wrote:
>
> One of the FriCAS development goals is:
> "make it easier for external programs to interface with FriCAS"
>
> Do you think communication via socket is a good idea,
> or "SBCL as a shared library" is better,
> or is there a third way?

I did not look deeply at what SBCL offers in its shared library
offer. There seem to be some advantage, namely part of needed
work is done by sbcl code. However both sockets and library
need some way to transmit complex data structures, so part
of coding will be similar.

Sorry, for lack of detail, but ATM I work on several different
things and do not want to start new one before finishing other
things.

--
Waldek Hebisch

[Dima Pasechnik]

On 15 March 2025 07:32:08 GMT-05:00, Qian Yun <oldk...@gmail.com> wrote:
>Hi Dima,
>
>About the FriCAS-SageMath interface, and about making
>FriCAS a standard package in SageMath, could you open
>a meta bug in GitHub to track the progress?
>
>I guess a better interface (C-based or socket-based,
>more robust and performant than current text-based)
>is needed. And SageMath needs to support "RootSum",
>or the interface needs another way to translate
>the "%%A1" algebraic numbers.
>
>
>Hi Waldek,
>
>One of the FriCAS development goals is:
>"make it easier for external programs to interface with FriCAS"
>
>Do you think communication via socket is a good idea,

Currently SageMath communicates with FriCAS via a socket interface (pexpect).
No files are written or read.
Perhaps it would be nice to redo this interface using SymPy, which is
much lighter
than Sage, but has more or less all what FriCAS needs.

Just in case,
Dima

[Waldek Hebisch]

On Sat, Mar 15, 2025 at 12:33:40PM -0500, Dima Pasechnik wrote:
> On 15 March 2025 07:32:08 GMT-05:00, Qian Yun <oldk...@gmail.com> wrote:
> >Hi Dima,
> >
> >About the FriCAS-SageMath interface, and about making
> >FriCAS a standard package in SageMath, could you open
> >a meta bug in GitHub to track the progress?
> >
> >I guess a better interface (C-based or socket-based,
> >more robust and performant than current text-based)
> >is needed. And SageMath needs to support "RootSum",
> >or the interface needs another way to translate
> >the "%%A1" algebraic numbers.
> >
> >
> >Hi Waldek,
> >
> >One of the FriCAS development goals is:
> >"make it easier for external programs to interface with FriCAS"
> >
> >Do you think communication via socket is a good idea,
>
> Currently SageMath communicates with FriCAS via a socket interface (pexpect).
> No files are written or read.

The big deal is about converting representations. Parsing/unparsing
takes time and is tricky in many cases. Machine oriented representation
should be much faster to transmit/convert.

When taking about speed one aspect is latency. Socket communication
involves system calls and unfortunately few years ago due to spectre
fixes effective latency of system call got significantly higher.
Function calls within the same process are much cheaper, but calls
between significantly different languages tends to be much more
expensive than calls within a single language. Another aspect
is throughput, that is speed of transmitting data. Here cost is
mainly due to volume and needed transformations. In particular
translation to textual forms tend to be more expensive.

IIUC pexpect works at tty level, which is different from sockets.
Tty handling may significantly increase cost compared to files
(I do not know if this is significant factor in FriCAS interface).

--
Waldek Hebisch

[Dima Pasechnik]

zeromq might be a faster option than pexpect.

That's what Jupyter is using for communication between the backend and the frontend.

[Grégory Vanuxem]

Hello Ralf,

I have not seen this discussion, but I you have Mathamatica or a WolframKernel jlFricas can easily do this using of course Julia and the MathLink.jl package:

In the Julia promp:
]
add MathLink

Your Mathematica installation will be used, see https://github.com/JuliaInterop/MathLink.jl

(1) -> aa:=jWSExpr aa;xx:=jWSExpr xx

   (1)  xx
                                                         Type: JLWSExpression
(2) -> expr:=sin(xx)^(aa+tan(xx^(-1)))

   (2)

          aa + tan(1/xx)
   sin(xx)
                                                         Type: JLWSExpression
(3) -> expr2:=sin(x)^(a+tan(x^(-1)))

                  1
              tan(-) + a
                  x
   (3)  sin(x)
                                                    Type: Expression(Integer)
(4) -> toString jlApply("InputForm",expr)

   (4)  "Sin[xx]^(aa + Tan[xx^(-1)])"
                                                                 Type: String
(5) -> toString(expr/7,"InputForm")

   (5)  "Sin[xx]^(aa + Tan[xx^(-1)])/7"
                                                                 Type: String
(6) -> jWSExpr toString(expr/7,"InputForm") -- evaluate directly the string in Mathematica

   (6)

          aa + tan(1/xx)
   sin(xx)
   ---------------------
             7
                                                         Type: JLWSExpression
(7) -> %^7

   (7)

          7 aa + 7 tan(1/xx)
   sin(xx)
   -------------------------
            823543
                                                         Type: JLWSExpression

Here, small support to return the EXPR(INT) version, but beware, this is interpreted in a new environment the Waldek's function 'interpret_in_new_env':

    strToExprInt(s : String) : Union(Expression(Integer), "failed") ==

      str := concat("0$Expression(Integer)+", s)

      af := parse(str)$InputForm

      av := interpret_in_new_env(af)$InputForm

      retractIfCan(av)$AnyFunctions1(Expression(Integer))

    strToExprFloat(s : String) : Union(Expression(Float), "failed") ==

      str := concat("0$Expression(Float)+", s)

      af := parse(str)$InputForm

      av := interpret_in_new_env(af)$InputForm

      retractIfCan(av)$AnyFunctions1(Expression(Float))

 I use it only to do some comparisons. I do not use the returned value; its behavior is undefined for me.

(8) -> %::EXPR INT

                      1
               7 tan(--) + 7 aa
                     xx
        sin(xx)
   (8)  -----------------------
                 823543
                                                    Type: Expression(Integer)


But here, you have direct access to Mathematica inside FriCAS using Wolfram Symbolic Transport Protocol.

So no need to start Mathematica if you want console-based Mathematica work. Here is another example with jWSExpr, it should accept all console compatible Mathematica expression:

(10) -> integrate(1/(x^3 - 1), x)

                                                                     +-+

            +-+     2               +-+                    (2 x + 1)\|3

         - \|3 log(x  + x + 1) + 2 \|3 log(x - 1) - 6 atan(-------------)

                                                                 3

   (10)  ----------------------------------------------------------------

                                         +-+

                                      6 \|3

                                         Type: Union(Expression(Integer),...)

(11) -> jWSExpr "Integrate[1/(x^3 - 1), x]"

   (11)

            1 + 2 x

     atan(-------)                              2

            sqrt(3)     log(1 - x)   log(1 + x + x )

   -(---------------) + ---------- - ---------------

         sqrt(3)            3               6

                                                         Type: JLWSExpression

(12) -> factor %

   (12)

                     1 + 2 x                                2

   -2 sqrt(3) atan(-------) + 2 log(1 - x) - log(1 + x + x )

                     sqrt(3)

   -----------------------------------------------------------

                                6

                                                         Type: JLWSExpression

(13) -> simplify(%%(11))

   (13)

                     1 + 2 x                                2

   -2 sqrt(3) atan(-------) + 2 log(1 - x) - log(1 + x + x )

                     sqrt(3)

   -----------------------------------------------------------

                                6

                                                         Type: JLWSExpression

The jlFriCAS built with Clozure CL is relatively stable with this package. With SBCL jlFriCAS can be unstable and falls in the debugger...

- Greg

--
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 fricas-devel...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/81040453-ba21-463d-aa48-7b871ee676ef%40hemmecke.org.

[Grégory Vanuxem]

And falls sometimes in the debugger. Sorry. 

Greg

Ps: maybe I can allocate memory in a different memory area. The architecture is already done. 

[Grégory Vanuxem]

Hi,

They are working on this. On your side. sympy -> Mathlink.

Le sam. 15 mars 2025 à 18:33, Dima Pasechnik <dim...@gmail.com> a écrit :
>
> On 15 March 2025 07:32:08 GMT-05:00, Qian Yun <oldk...@gmail.com> wrote:
> >Hi Dima,
> >
> >About the FriCAS-SageMath interface, and about making
> >FriCAS a standard package in SageMath, could you open
> >a meta bug in GitHub to track the progress?
> >
> >I guess a better interface (C-based or socket-based,
> >more robust and performant than current text-based)
> >is needed. And SageMath needs to support "RootSum",
> >or the interface needs another way to translate
> >the "%%A1" algebraic numbers.

Yes!!!

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq1B9fBDbmk%3DztvFr_tsy5ieDgsyJPca-RcsRLyL9MZWzg%40mail.gmail.com.

[Dima Pasechnik]

On Mon, Jun 30, 2025 at 1:34 PM Grégory Vanuxem <g.va...@gmail.com> wrote:
>
> Hi,
>
> They are working on this. On your side. sympy -> Mathlink.

Could you provide more details on this? I can't seem to find much on
this. Thanks.

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dZ60pHuGDY26%2BfPtyyU4ziaAnuTmuTirR_9Ubfoy%2BhRkg%40mail.gmail.com.

[Grégory Vanuxem]

hello,

Le mar. 1 juil. 2025 à 04:17, Dima Pasechnik <dim...@gmail.com> a écrit :
>
> On Mon, Jun 30, 2025 at 1:34 PM Grégory Vanuxem <g.va...@gmail.com> wrote:
> >
> > Hi,
> >
> > They are working on this. On your side. sympy -> Mathlink.
>
> Could you provide more details on this? I can't seem to find much on
> this. Thanks.

Oh, sorry, you're right, I don't stop to be confused by SymPy
(https://www.sympy.org/en/index.html),
Symbolics.jl (https://github.com/JuliaSymbolics/Symbolics.jl) and
SymPy.jl (https://github.com/JuliaPy/SymPy.jl). My mistake (big).

Sorry again,

- Greg

PS:
https://github.com/JuliaInterop/MathLink.jl?tab=readme-ov-file#relation-to-other-packages
https://github.com/eswagel/SymbolicsMathLink.jl

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq2pjip1xLb8dvwtK22n569MXTAwmtBLpUec6dBtEHmDUg%40mail.gmail.com.

[Dima Pasechnik]

On Mon, Jun 30, 2025 at 1:34 PM Grégory Vanuxem <g.va...@gmail.com> wrote:
>

> Hi,
>
> They are working on this. On your side. sympy -> Mathlink.
>
>
>
>
> Le sam. 15 mars 2025 à 18:33, Dima Pasechnik <dim...@gmail.com> a écrit :
> >
> > On 15 March 2025 07:32:08 GMT-05:00, Qian Yun <oldk...@gmail.com> wrote:
> > >Hi Dima,
> > >
> > >About the FriCAS-SageMath interface, and about making
> > >FriCAS a standard package in SageMath, could you open
> > >a meta bug in GitHub to track the progress?
> > >
> > >I guess a better interface (C-based or socket-based,
> > >more robust and performant than current text-based)
> > >is needed. And SageMath needs to support "RootSum",
> > >or the interface needs another way to translate
> > >the "%%A1" algebraic numbers.
>
> Yes!!!

I've opened
https://github.com/sagemath/sage/issues/40356

to address this. Please feel free to comment there.

Best

Dima

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dZ60pHuGDY26%2BfPtyyU4ziaAnuTmuTirR_9Ubfoy%2BhRkg%40mail.gmail.com.