Transpiling from Mathematica syntax to sage backends

[Rocky Bernstein]

(I posted a much longer and more detailed version of this the other day, but I don't see it posted. So here is a shorter version)

I'm curious of any consideration has been giving for transpiling from one CAS syntax to another instead of or right before sage.repl.preparse(). 

In particular, I was thinking about using Mathematica syntax. 

If this gets through and there's interest, I can fill in more details.

[kcrisman]

I'm curious of any consideration has been giving for transpiling from one CAS syntax to another instead of or right before sage.repl.preparse(). 

I think that long ago some of that was suggested, but the problem is that there are very nontrivial differences - it's not just a matter of changing lowercase to uppercase or something, as you know.   Here is one decade-old discussion: https://groups.google.com/forum/#!topic/sage-devel/JLg-fJ4dJns

Even translating a given Sage object to another program is nontrivial; a recent example is https://trac.sagemath.org/ticket/12074 where we don't even have close to the same name as Mathematica for the same (essentially) proposed function.  And that doesn't take into account things like actual programming syntax.  (Even trying to use Numpy or Sympy and Sage together may lead to namespace clashes, or at least at some point in the past did.)

That doesn't mean it isn't somehow feasible, but it does mean it's not likely that other developers will be signing up to do it from scratch. See https://groups.google.com/forum/#!searchin/sage-devel/mathematica$20syntax%7Csort:date/sage-devel/cjrsZfGkc-w/IoDiv9ZwNxoJ for a different discussion about https://mathics.github.io which apparently now uses Sympy as a backend.  Anyway, if you have a proof of concept already available, that would be very different, and I don't see why we wouldn't be open to having this as some sort of preparsing option.  Good luck!

[Rocky Bernstein]

I am sorry that what I posted originally somehow didn't go through. It took me a while to write and touches on a number of things mentioned in the discussion.  So let me try again. 

I have a limited simple-minded brain for all of the various syntaxes and dialects. So one goal as briefly mentioned was to be able to write/use a common language for expressing CAS. The characteristics of this common language should be:

• there a number of examples, tutorials, blogs, and books in that language
• it is fairly complete in what it expresses,
• it is popular and ergonomic,
• i is well defined and documented

One may quibble about the well-defined-ness of the Mathematica/Wolfram language. But overall I think that language fits the above criteria pretty well. 

I should say at the start, I have a bit of familiarity and experience with compilers. And no, I don't think this will be either easy, quick, or complete. And as with my other compiler related projects, I am not counting on and don't expect to receive much help from others. (Of course, help is greatly welcome).

In the lost post, I wrote about the problems of language drift in a programming language. This came up in the Python decompilers I've written and I have a handle on how to deal with the 20 or so different Python dialects of bytecode (if not Python language specifications). Although WRI is free to change its language specification at any time (and has), and do so even in an incompatible way, in practice, when a programming language is in widespread use, you can't really change it that quickly even if you want to. Think about how long Python 2 has been around long after Guido Rossum and Pythonistas have declared it dead. The same is true with Mathematica syntax. 

One thing that has changed since that decade-old discussion is the level of specification for Mathematica and tools for parsing Mathematics. Robert Jacobson wrote FoxySheep, and there is the Wolfram Language Specification Tools. 

Looking at that discussion there was a bit about parsing technology, so let me address that. 

I intend to use the last two links above as a guide and cull from them. As for the specific parser and parsing technology, I intend to use this very general J Earley parser that allows one use ambiguous grammars as input. I use it in my Python decompilers and know it well. Although there is much that could be improved in that parser (especially in its input format), it has some features that I am not aware of exist in other parser systems.

But of course this is not just about parsing. I imagine that for each backend there will probably need to be a compatibility library for each backend (sage, Axiom/FriCAS, Macsyma, ...)

And there can be an impedance mismatch in concepts between front-end language input and backend. 

But I have found that just because a problem is very difficult if not close to impossible to do well, that doesn't mean one shouldn't start and try. And along the way you'll understand the problem better if not also how better to deal with it.

A program can be extremely useful even if it is flawed. That is definitely true with my Python decompilers. Another example I like to give here google translate. Sometimes you'll get a translation that is not just wrong but so funny that it can be and has been the subject of jokes. (And part of the problem can be the ambiguity of the language: you can't hang a man with a wooden leg - you have to use a rope)

But overall, google translate is useful enough in everyday life that it continues to exist, be used and improved.

All this said, I have no idea whether I'll undertake this or if I do how far I'll get. 

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d4b01e0b-8e7b-42f8-bfbb-f05f6e894b1fo%40googlegroups.com.

[Nils Bruin]

On Saturday, July 4, 2020 at 9:10:33 AM UTC-7, Rocky Bernstein wrote:

 So one goal as briefly mentioned was to be able to write/use a common language for expressing CAS.

This goal (or perhaps a little more broadly, a common language for expressing mathematical objects) has been around for a long time and has proven rather difficult. You should probably look into efforts that went into OpenMath (https://www.openmath.org/) and evaluate what works and does not work there.

One of the early design goals of Sage was actually exactly to be a compatibility/translation layer between different CA systems and libraries. That's where the "expect" interfaces come from and several of those interfaces (libmaxima, libgap) since then were better integrated to allow translation of information on a binary level rather than just via character streams.

The overarching language was not particularly modelled on Mathematica, but rather on Magma, which matches Python fairly well.

I'd expect that you'll run into the same kind of issues that Sage has run into if you try to replicate its efforts on a Mathematica-modelled platform.

[rjf]

There are at least two rather complete parsers for the "Wolfram Language"  which

render stuff like

foo[x_]:= Sin[x]+Log[x]

  into trees / intermediate forms/   Lisp s-expressions.

(compare to Wolfram's  "FullForm"  which is essentially lisp with [] instead of (), and moving parens... x+y becomes Plus[x,y]  or in lisp, (Plus x y). )

I wrote (and posted) a lisp language parser for Mathematica's language,

years ago.

A top-down recursive descent parser. 

At that time, (maybe still?) the

language did not have a context-free grammar, much less one that was

written down.

I'm not sure what you are aiming to do.

But to make any non-trivial use of Mathematica language ( i.e. other than algebraic expressions like a*b+c)

you need to have semantics for pattern matching, language features , conditionals, iteration,

numerics (bizarre bigfloat), and routines like Integrate[], Solve[] etc.

You cannot map these 1:1 to anything currently in Sage, though I suppose Sage could

gobble up a version of Mathics. or you could look at the lisp/Maxima code.

I think openmath has lost out to mathml, but they are both, IMO really terribly

unreadable, and for no good reason.  There is at least one front end for

Maxima that (I think) uses MathML.  As long as no human has to read it,

it might be OK except for being about 25X more verbose than needed.

If all you care about is algebraic expressions with standard operators, + * / - ^

then the task is a simple homework assignment for an undergrad

course in programming languages/ compiling.

RJF

[Dima Pasechnik]

On Sun, Jul 5, 2020 at 12:40 AM rjf <fat...@gmail.com> wrote:
>
> There are at least two rather complete parsers for the "Wolfram Language" which
> render stuff like
> foo[x_]:= Sin[x]+Log[x]
> into trees / intermediate forms/ Lisp s-expressions.
> (compare to Wolfram's "FullForm" which is essentially lisp with [] instead of (), and moving parens... x+y becomes Plus[x,y] or in lisp, (Plus x y). )
>
> I wrote (and posted) a lisp language parser for Mathematica's language,
> years ago.
>
> A top-down recursive descent parser.
> At that time, (maybe still?) the
> language did not have a context-free grammar, much less one that was
> written down.
>
> I'm not sure what you are aiming to do.
> But to make any non-trivial use of Mathematica language ( i.e. other than algebraic expressions like a*b+c)
> you need to have semantics for pattern matching, language features , conditionals, iteration,
> numerics (bizarre bigfloat), and routines like Integrate[], Solve[] etc.
>
> You cannot map these 1:1 to anything currently in Sage, though I suppose Sage could
> gobble up a version of Mathics. or you could look at the lisp/Maxima code.
>
> I think openmath has lost out to mathml, but they are both, IMO really terribly
> unreadable, and for no good reason. There is at least one front end for
> Maxima that (I think) uses MathML. As long as no human has to read it,
> it might be OK except for being about 25X more verbose than needed.

there has been recent work done on OpenMath, so it's not clear who lost.
https://www.openmath.org/software/
lists support by Python, GAP, Axiom, Mathematica, Maple

Also, https://uniformal.github.io/ uses OpenMath and OpenMath Doc.

>
> If all you care about is algebraic expressions with standard operators, + * / - ^
> then the task is a simple homework assignment for an undergrad
> course in programming languages/ compiling.
>
>
> RJF
>
>
>
> On Saturday, July 4, 2020 at 12:29:27 PM UTC-7, Nils Bruin wrote:
>>
>> On Saturday, July 4, 2020 at 9:10:33 AM UTC-7, Rocky Bernstein wrote:
>>>
>>>
>>> So one goal as briefly mentioned was to be able to write/use a common language for expressing CAS.
>>
>>
>> This goal (or perhaps a little more broadly, a common language for expressing mathematical objects) has been around for a long time and has proven rather difficult. You should probably look into efforts that went into OpenMath (https://www.openmath.org/) and evaluate what works and does not work there.
>>
>> One of the early design goals of Sage was actually exactly to be a compatibility/translation layer between different CA systems and libraries. That's where the "expect" interfaces come from and several of those interfaces (libmaxima, libgap) since then were better integrated to allow translation of information on a binary level rather than just via character streams.
>>
>> The overarching language was not particularly modelled on Mathematica, but rather on Magma, which matches Python fairly well.
>>
>> I'd expect that you'll run into the same kind of issues that Sage has run into if you try to replicate its efforts on a Mathematica-modelled platform.
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b7e13235-6acd-48c4-8d1f-d1c82c563e89o%40googlegroups.com.

[Rocky Bernstein]

On Sat, Jul 4, 2020 at 7:40 PM rjf <fat...@gmail.com> wrote:

There are at least two rather complete parsers for the "Wolfram Language"  which

render stuff like

foo[x_]:= Sin[x]+Log[x]

  into trees / intermediate forms/   Lisp s-expressions.

(compare to Wolfram's  "FullForm"  which is essentially lisp with [] instead of (), and moving parens... x+y becomes Plus[x,y]  or in lisp, (Plus x y). )

Well, I mentioned one of them: FoxyParser. It  works off of an ANTLR grammar. However my understanding from Robert Jacobson is that ditching the LALR grammar and using something more flexible and expressive (his current thought is a Pratt parser, but in discussions with him a J Earley parser would probably work about as well) would extend its capabilities and make maintenance and tracking changes easier. 

 

I wrote (and posted) a lisp language parser for Mathematica's language,

years ago.

Yes, I have heard about it. I believe it was mentioned in the prior-discussion thread of several years back.

And if you are the person who wrote  A Review of Mathematica, I found that very interesting, well thought out, and interesting. It reminded me of why I dislike Mathematica and have been avoiding buying Mathematica. So thanks for these! (And for Macsyma and Franz Lisp). 

A top-down recursive descent parser. 

While recursive descent parsers are easier and straightforward to write, understand, and debug initially, it would require too much work to maintain them. 

As a stark example, in my Python decompiler, I have grammars for 26 versions of Python bytecode which spans the range of Python from 1.0 to 3.9 (however many distinct "languages" one wants to call this). Yes, this is a bit of an extreme case, but there definitely has been language drift in Mathematica since the time you wrote that recursive-descent parser. 

Since I understand how to deal with the language drift problem without too much difficulty, I am tempted to support a little of that - legacy Mathematica code and examples are a reality. I certainly don't want to preclude using these. Therefore working off of a grammar (or DSL) is preferable, at least given my experience. 

At that time, (maybe still?) the

language did not have a context-free grammar, much less one that was

written down.

 

That was then, and this is now. As I said, FoxyParser has grammar. It may be in need of improvement but I imagine it is serviceable right now for more than I imagine that I  need.

And there are docs on the language such as this one. Formally, a language is defined as a set of strings it recognizes, and there are numerous examples of strings in Mathematica that one can find. Given this, the lack of a standards-approved language grammar (which as you yourself I think have indicated may not be unintentional) while not ideal, is also not an obstacle for now. 

I'm not sure what you are aiming to do.

Ah. I am sorry this wasn't clear. I think the lost first post was a little more explicit and I didn't want to replicate the effort to repeat everything I wrote,  since I wasn't sure if the 2nd post would be lost as well. 

Overall I would like to reduce the tower of Babel for CAS systems. But that is a bit too broad and general so I would like to focus on a specific sub-goal. 

I'd like to be able to run the numerous simple examples and tutorials involving CAS for which are available for Mathematica, and be able run them and get reasonable results in sage-jupyter. 

"Reasonable results" doesn't mean exactly the same answer that Mathematica gives, but something that a reasonable person/mathematician would say represents a valid answer in the CAS framework that was given. If that system can't give an answer, there are several possibilities: 

• live with it,
• change the request,
• fix up the system which might involve coding a compatibility routine, or improving the transpiling system, or 
• switch to a different CAS backend (and possibly fixing  as above ...)

 

But to make any non-trivial use of Mathematica language ( i.e. other than algebraic expressions like a*b+c)

you need to have semantics for pattern matching, language features , conditionals, iteration,

numerics (bizarre bigfloat), and routines like Integrate[], Solve[] etc.

Yes, I am aware of that. I am sorry that wasn't made clear initially. 

 

You cannot map these 1:1 to anything currently in Sage, though I suppose Sage could

gobble up a version of Mathics. or you could look at the lisp/Maxima code.

Right. By "Sage" I wasn't thinking of "sage", the  back-end part called that was historically "sage", but the part that claims not to reinvent the wheel but to provide a car. 

Perhaps I should have written "sage-jupyter" or something like that to make this more clear. I am thinking of something that would replace or hook into sage.repl.preparse. This "sage" already supports Maxima, Sympy  and fricas as a sage package or (spkg).

 

I think openmath has lost out to mathml, but they are both, IMO really terribly

unreadable, and for no good reason.  There is at least one front end for

Maxima that (I think) uses MathML.  As long as no human has to read it,

it might be OK except for being about 25X more verbose than needed.

If all you care about is algebraic expressions with standard operators, + * / - ^

then the task is a simple homework assignment for an undergrad

course in programming languages/ compiling.

Yes, I have one of these as a demo program for the J Earley parser I use and work on.  What I am not aware of is something a little more sophisticated like sage.repl.preparse that understands the underlying semantics a little bit better. 

In the lost post, I closed by positing that in the far future something like this would be able to recognize which backends (of the ones installed) have features which would support the given request.  And going further in the hand-wavy far future one might imagine running the request on multiple or different backends and stitching together answers.

But just showing a translation from one CAS language to another would ease the Tower-of-Babel problem and is a by-product of this kind of effort.

RJF

On Saturday, July 4, 2020 at 12:29:27 PM UTC-7, Nils Bruin wrote:

On Saturday, July 4, 2020 at 9:10:33 AM UTC-7, Rocky Bernstein wrote:

 So one goal as briefly mentioned was to be able to write/use a common language for expressing CAS.

This goal (or perhaps a little more broadly, a common language for expressing mathematical objects) has been around for a long time and has proven rather difficult. You should probably look into efforts that went into OpenMath (https://www.openmath.org/) and evaluate what works and does not work there.

One of the early design goals of Sage was actually exactly to be a compatibility/translation layer between different CA systems and libraries. That's where the "expect" interfaces come from and several of those interfaces (libmaxima, libgap) since then were better integrated to allow translation of information on a binary level rather than just via character streams.

The overarching language was not particularly modelled on Mathematica, but rather on Magma, which matches Python fairly well.

I'd expect that you'll run into the same kind of issues that Sage has run into if you try to replicate its efforts on a Mathematica-modelled platform.

--

You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b7e13235-6acd-48c4-8d1f-d1c82c563e89o%40googlegroups.com.

[Rocky Bernstein]

On Sat, Jul 4, 2020 at 3:29 PM Nils Bruin <nbr...@sfu.ca> wrote:

On Saturday, July 4, 2020 at 9:10:33 AM UTC-7, Rocky Bernstein wrote:

 So one goal as briefly mentioned was to be able to write/use a common language for expressing CAS.

This goal (or perhaps a little more broadly, a common language for expressing mathematical objects) has been around for a long time and has proven rather difficult.

Not surprising. And the same thing has been tried for Human Language with similar results. 

So I should have been more clear about not wanting to invent a language but pick one, and one that I can easily understand ;-)  Also, one that many others and computers already understand. 

You should probably look into efforts that went into OpenMath (https://www.openmath.org/) and evaluate what works and does not work there.

I briefly looked at that. Again, here is the criteria I posted for evaluating a language (this time numbered):

 

1. there are a number of examples, tutorials, blogs, and books in that language

1. it is fairly complete in what it expresses,
2. it is popular and ergonomic,

1. it is well defined and documented

Right now, openmath appears to fail on 1 and 3.

One of the early design goals of Sage was actually exactly to be a compatibility/translation layer between different CA systems and libraries. That's where the "expect" interfaces come from and several of those interfaces (libmaxima, libgap) since then were better integrated to allow translation of information on a binary level rather than just via character streams.

I am not sure I understand what this means other than perhaps a superficial level. A compiler or transpiler may start out with some representation, but what makes these things useful is that they understand the request or source input at a deeper level. Whether "binary level" meets that level of understanding, I don't know. It depends on what that "binary level" expresses.

 I should have been more clear that I was not contemplating the typical compiler holy grail problem: solve n languages to m backends problem by coming up with a universal intermediate language so this is a n + m problem. At best this would be a 1 to m problem with a smaller m than is supported by sage for quite while. In fact initially m here is 1 or 2.

The overarching language was not particularly modelled on Mathematica, but rather on Magma, which matches Python fairly well.

I'd expect that you'll run into the same kind of issues that Sage has run into if you try to replicate its efforts on a Mathematica-modelled platform.

Is there some place that concisely documents what the issues are and how they were resolved (if resolved)? 

Although I think we are thinking about this slightly differently, as I wrote before: just because something is hard and not doable in the general sense, that doesn't mean that one shouldn't start to undertake doing it; also that flawed result can sometimes be very helpful and expedient. My example again is google translate. 

That said, I want to avoid the tar pits and sinkholes that others have fallen into. So understanding what to avoid, or what was learned is definitely useful.  Thanks! 

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c9e83147-87a4-4acb-b748-e8ff17a9c190o%40googlegroups.com.

[rjf]

You could take a look at what Albert Rich has done for testing Rubi in different systems.

Also, the theorem proving people using Coq want to match up with CAS.

Also, the history of formalizing mathematics  (Frege, Russell, etc) may

influence your thinking. Maybe discourage you; see the history of tarpits.

My view is colored by the fact that different CAS do not even agree

on the semantics of sin(x)  or Sin[x],  e.g. how it simplifies.

MathML does not care, I suspect. OpenMath used to say something

like "the usual sine(x)" which is a cop-out. What is sin(2*x)?

If you really want to make them all talk to each other, I think

you have to pick one CAS, preferably the most full-featured

one available (maybe insist on it being free?)  and then

translate everything to it.  To compare an expression in

Maple and Mathematica,  convert them both to the same

CAS.  e.g. one , or the other,  or both to (say) Maxima.

Even this is tough ... to translate maple sin(x) to Maxima, you

need to invent maple_sin_in_maxima(x).

etc

I don't think openmath will suffice.

[Rocky Bernstein]

On Sun, Jul 5, 2020 at 3:14 PM rjf <fat...@gmail.com> wrote:

You could take a look at what Albert Rich has done for testing Rubi in different systems.

Also, the theorem proving people using Coq want to match up with CAS.

Also, the history of formalizing mathematics  (Frege, Russell, etc) may

influence your thinking. Maybe discourage you; see the history of tarpits.

I looked at these, but I am not seeing much in the way how  this is relevant.  I probably didn't make it clear that I wasn't looking for absolute truth....

My view is colored by the fact that different CAS do not even agree

on the semantics of sin(x)  or Sin[x],  e.g. how it simplifies.

MathML does not care, I suspect. OpenMath used to say something

like "the usual sine(x)" which is a cop-out. What is sin(2*x)?

doesn't seem all that relevant either. When I go to a CAS or a computer to seek answers I have some real question or problem that I want to understand, and hope that the computer will give me an answer that helps me understand whatever it is I am trying to accomplish and/or gives me some insight towards that problem. 

The answer doesn't have to be absolute or exact in some abstract sense, but rather an answer that is the best effort given the limitations of the systems in use

I also care about transparency: how what I wrote was interpreted, and which system was used to produce the answer, and maybe why it gave that answer. It is assumed I will know or can look up that system's strengths and weaknesses, and how it interprets things. For a large number of the cases that come up, many systems will agree and, if not,  give an answer that makes sense and more importantly addresses the underlying question I had. And if not, I am prepared to iterate over the question as long as I understand the process and reasoning used. 

If you really want to make them all talk to each other, I think

Although I said that was a hand-wavy goal. This is throwing too much of a monkey wrench into things. To paraphrase a lesser-known line from an illiterate stage actor to the kid he's mentoring from Sholem Alechiem's Wandering Stars:

I dictate; you (the computer) write down; I sign. 

Or in other words I express something (without having to understand too much of the syntax details of each CAS),  the computer translates that using a transparent scheme (to its best effort which may be approximate or flawed), I look over the results, and sign off on. 

you have to pick one CAS, preferably the most full-featured

one available (maybe insist on it being free?)  and then

translate everything to it.  To compare an expression in

Maple and Mathematica,  convert them both to the same

CAS.  e.g. one , or the other,  or both to (say) Maxima.

Even this is tough ... to translate maple sin(x) to Maxima, you

need to invent maple_sin_in_maxima(x).

etc

I don't think openmath will suffice.

On Friday, July 3, 2020 at 6:42:42 PM UTC-7, Rocky Bernstein wrote:

(I posted a much longer and more detailed version of this the other day, but I don't see it posted. So here is a shorter version)

I'm curious of any consideration has been giving for transpiling from one CAS syntax to another instead of or right before sage.repl.preparse(). 

In particular, I was thinking about using Mathematica syntax. 

If this gets through and there's interest, I can fill in more details.

--

You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9ce8d876-62b7-4beb-a6dd-71ea20d4ff37o%40googlegroups.com.

[William]

Hi Rocky,

I haven't followed every detail of this thread, but just wanted to encourage you. The official and original mission statement of SageMath is to "Create a viable free open source alternative to Magma, Maple, Mathematica and Matlab."  Clearly, adding the ability to parse some Mathematica code fits well into that goal.  If nothing else, it could be a helpful step in converting existing Mathematica user code so that it can work in Sage, and that's part of being a viable alternative.    In my day job lately, I often use https://decaffeinate-project.org/ to convert CoffeeScript code to bad Javascript, which I then make a lot nicer -- it would be very hard to do that same conversion without at least having something that does the job badly.  Also, many years ago, I wrote some small crappy code for transforming Magma code to Sage code, which was very helpful even when imperfect.

So thanks!

 -- William  (that guy who started SageMath 16 years ago...)

To unsubscribe from this group and all its topics, send an email to sage-devel+unsubscribe@googlegroups.com.

[Rocky Bernstein]

Thanks for the kind words and encouragement. 

To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9ce8d876-62b7-4beb-a6dd-71ea20d4ff37o%40googlegroups.com.

--

You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe.

To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/e1a8646f-7b8f-4ada-aa82-6df389996550o%40googlegroups.com.

[kcrisman]

  Clearly, adding the ability to parse some Mathematica code fits well into that goal.  If nothing else, it could be a helpful step in converting existing Mathematica user code so that it can work in Sage, and that's part of being a viable alternative.    

This is an important point that I am sorry we did not mention earlier; thanks, William.  I have definitely had many requests for such an automated tool in the past from colleagues with a lot of Mma stuff.

[Rocky Bernstein]

Ok. This is on my back-burner list of things to get to. 

It is something I would like to do, and think I could do reasonably well, but I never know if I'll have the free time. 

And if someone else wants to take the lead, I'll be happy to share what I know on the compiler/transpiler end and contribute.

Also, if there is funding for this effort, then it will most likely get done. 

On Fri, Jul 10, 2020 at 10:52 AM kcrisman <kcri...@gmail.com> wrote:

  Clearly, adding the ability to parse some Mathematica code fits well into that goal.  If nothing else, it could be a helpful step in converting existing Mathematica user code so that it can work in Sage, and that's part of being a viable alternative.    

This is an important point that I am sorry we did not mention earlier; thanks, William.  I have definitely had many requests for such an automated tool in the past from colleagues with a lot of Mma stuff.

--

You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe.

To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/8dd1a617-6bcc-40e3-a1c7-89efb2927597o%40googlegroups.com.

[Fredrik Johansson]

I will just mention http://fungrim.org/grim/ which is somewhat related to the present discussion.

This is an attempt to design a symbolic formula language that is easy to parse and has well-defined semantics. Key points:

* Can be used within Python (and other languages) without special syntax
* Expressly designed to describe mathematical objects and not for reflection (manipulation of symbolic expressions is meant to be done in the environment, e.g. Python, not from within the symbolic expression language)
* Expressions are inert by default (there is no automatically-enforced pseudo-canonical form, and any form of evaluation or rewriting must be invoked explicitly by the user)
* Evaluation and simplification is subject to a rigorous assumptions system
* There is an explicit distinction between symbolic variables and polynomial indeterminates
* Real numbers are mathematical real numbers
* Functions are mathematical functions, with well-defined and consistent behavior at "exceptional points"

The specification is still far from complete and the implementation still has a long way to go, but I'm working on it :-)

I'm using it with some success to build http://fungrim.org/. Thanks to the strong semantics, it is possible to do automated randomized testing of the formulas and their assumptions. To illustrate:

>>> formula = Equal(Gamma(x+1), x*Gamma(x))
>>> formula.test(variables=[x], assumptions=Element(x, CC))
{x: -3}    ...  True
{x: 8}    ...  True
{x: 0}    ...  False
Traceback (most recent call last):
  ...
ValueError

(Gamma(0+1) = 0*Gamma(0) is not a true identity.) With correct assumptions, excluding the poles:

>>> formula.test(variables=[x], assumptions=Element(x, SetMinus(CC, ZZLessEqual(0))))
{x: Sqrt(2)}    ...  Unknown
{x: Mul(Mul(2, Pi), ConstI)}    ...  Unknown
{x: Div(Mul(3, Pi), 2)}    ...  Unknown
{x: Neg(Div(1, 2))}    ...  True
{x: Div(1, 2)}    ...  True
{x: Add(Sqrt(2), 1)}    ...  Unknown
{x: Add(1, ConstI)}    ...  Unknown
...
{x: Sub(Pi, ConstI)}    ...  Unknown
{x: Sub(Sqrt(2), 1)}    ...  Unknown
{x: 64}    ...  True
{x: 255}    ...  Unknown
{x: 7}    ...  True
Passed 100 instances (25 True, 75 Unknown, 0 False)
{'True': 25, 'Unknown': 75, 'False': 0, 'Total': 100}

Fredrik

[Rocky Bernstein]

Ok. Something to consider is rendering to Mathematica output. (And then doing the same thing for Sage.)

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/050a44ed-e31b-4ddb-8687-fc9dcd53e3c1n%40googlegroups.com.

[rjf]

You of course realize that in expressing good intentions, you are not alone, and certainly

not first.

The devil is in the details.  Parsing Mathematica expressions into an intermediate

form (like a Lisp symbolic expression) is the easy part.

Here's a detail that came up in another mailing list.

What is Infinity  or Inf in Mma?

Is it the same as in your favorite other CAS? Or in your

favorite text?

Mma  says 1/Inf = 0.   It also says -1/Inf =0.   From which

we might conclude that 1=-1.  Do we have to get around

this?  If so, how?  If you have a system that has a

more nuanced version of infinity, what do you do?

There are other similar issues.

Another point -- that if two CAS come up with the "same"

answer, it must be right, is wishful thinking. In certain

simple domains I would treat equal results as strongly confirmatory.

There used to be a list of system-independent bugs --

caused by common simplistic thinking, where

mathematics taught in high school is used as

the basis for manipulating more sophisticated

ideas.  

Sorry to provide a bit more rain on your parade.

Have fun with the easy parts and see how far you

can get with the hard parts!

RJF

To unsubscribe from this group and all its topics, send an email to sage-...@googlegroups.com.

[Rocky Bernstein]

On Fri, Jul 10, 2020 at 8:41 PM rjf <fat...@gmail.com> wrote:

You of course realize that in expressing good intentions, you are not alone, and certainly

not first.

The devil is in the details.  Parsing Mathematica expressions into an intermediate

form (like a Lisp symbolic expression) is the easy part.

Here's a detail that came up in another mailing list.

What is Infinity  or Inf in Mma?

Is it the same as in your favorite other CAS? Or in your

favorite text? 

User choice by option: If you want loose compatibility, then Inf in Mma. If you want strict compatibility there is a strict compatibility library and you can define SageInf in Mma.

 

Mma  says 1/Inf = 0.   It also says -1/Inf =0.   From which

we might conclude that 1=-1.  Do we have to get around

this?  If so, how?  If you have a system that has a

more nuanced version of infinity, what do you do?

There are other similar issues.

Another point -- that if two CAS come up with the "same"

answer, it must be right, is wishful thinking. In certain

simple domains I would treat equal results as strongly confirmatory.

There used to be a list of system-independent bugs --

caused by common simplistic thinking, where

mathematics taught in high school is used as

the basis for manipulating more sophisticated

ideas.  

Sorry to provide a bit more rain on your parade.

I don't think you get the idea that flaky can sometimes be okay.  I know this is going to sound a broken record, but you keep coming back to the same thing. Do you use google translate? If so, have you ever found its answers to be wrong? If you haven't used google translate, let me suggest that enough people use it that google still supports that project and it continues to fund and improve it. Spoiler alert: it still makes a lot of mistakes.

If we insisted that rational numbers on computers be the correct rational as it is in mathematics, then floating point would have never been invented. Even more basic, if we had insisted that integers on computers be the same as integers in mathematics and not that silly modulo arithmetic, it would have taken computers a lot longer to get started. 

I am sure there are some or many that feel that this was the wrong thing to do. Personally, I, as apparently many others, understand and accept that the limitations and live with flakiness. 

When MMa fist came out, I recall at IBM there were a lot of people who were put off by it because it did a lot of computation by discrete approximation which was pervasively considered (at IBM) worse than the richness of Scratchpad2's more symbolic and more thorough handling.

Looking back though, it is hard to argue that it should have come initially with something that was better and that improved the existing art on symbolic terms. And in the meantime, MMa has continued to improve to the point where it is used far more than those better systems like ScratchPad2. 

 

Have fun with the easy parts and see how far you

can get with the hard parts!

Will do!  In the short term, this is strictly for my own education and amusement and meager needs. I don't envision that anything I will do in the short term that will care about whether 1/Inf = 0. But when I do encounter it and it bothers me, I know about and have written compatibility libraries. (In fact I ran into something similar in Python. The details are here: Converting Python complex string output like (-0-0j) into an equivalent complex string. I solved it as I indicated here: I wrote my own routine that does what is needed. 

 

RJF

I don't think you get the idea that flaky is sometimes okay if you declare it flakey.

Sorry to rain on your parade. 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/7ad837b4-fa7e-4d5c-a008-6d11e03df84bo%40googlegroups.com.

[rjf]

the problem I see here is the recipe

requiring "user choice"  and somehow specifying "inf in Mma"

Most users will not want to specify, but probably would go along with

"the mathematically consistent choice according to experts who have

studied the matter."

Certainly saying, as one choice, "inf in Mma" is inadequate since

the user, other people, other CAS, cannot make use of this with

any certainty.  Even "inf in Mma version 12.1" while specific,

is not so useful outside of Mma version 12.1.  There is no

axiomatic specification for "inf in Mma". Also the code

supporting it is secret.

Being approximately right in mathematics is different from

providing an answer which is right within some defined

level of approximation  (e.g.  numerical precision,  number

of terms in a series, approximation by polynomial, ...)

If you consider a robotic automated vehicle, being

approximately right might means it will only rarely crash

into a tree.  Being right approximately means that it

will (always) drive to its destination, give-or-take a short displacement.

RJF

On Friday, July 10, 2020 at 6:51:15 PM UTC-7, Rocky Bernstein wrote:

User choice by option: If you want loose compatibility, then Inf in Mma. If you want strict compatibility there is a strict compatibility library and you can define SageInf in Mma.

 

I rarely use Google Translate.  I often use voice recognition (Alexa) which is remarkable but

prone to errors in recognition as well as information retrieval. Maybe you should build your

system for math voice parsing?  Alexa responds to

"Alexa, how much is 2+3?"

with "2+3 is 5".

You can see some background on this here:

https://people.eecs.berkeley.edu/~fateman/papers/speakmath.pdf

Maybe you should consider reviving "how to speak mathematics"

using newer technology.   (vs. 2003 or so.)

 

[Rocky Bernstein]

I think we've beat this to death. So let's agree to disagree.

This kind of thing is not intended for someone like you, but rather, someone like me who is just getting started in Sage and CAS and wants to go through a number of simple Mma tutorials and see roughly corresponding results translated to another system. If that works out, I am happy, and may try more ambitious things.

The specific examples showing how the various systems are hopelessly incompatible or where there are subtleties and vagueness are interesting. However I suspect none of this is going to matter. At least not in the short term, if ever. This is for casual, non-mission-critical, and educational use.  After I have something that isn't vaporware (if I get to that stage), you can pop up again and warn people of the dangers. I hear you, and you have some valid points. Now please go away. 

There were the hacks one used to do with calculators where you'd divide a number of times by a number and then multiply it back and get something slightly off. Using that, Homer Simpson was able to disprove Fermat's Theorem by finding a solution to the equation  a**12 + b**12 = c**12 in TI calculator math. Somehow though, calculators and mathematics were both able to survive this ordeal. 

--

You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/z3XBhQOCh9E/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/e0924dda-7720-4485-94e3-50d444f6d89co%40googlegroups.com.

[E. Madison Bray]

On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
<rocky.b...@gmail.com> wrote:
>
> I think we've beat this to death. So let's agree to disagree.
>
> This kind of thing is not intended for someone like you, but rather, someone like me who is just getting started in Sage and CAS and wants to go through a number of simple Mma tutorials and see roughly corresponding results translated to another system. If that works out, I am happy, and may try more ambitious things.
>
> The specific examples showing how the various systems are hopelessly incompatible or where there are subtleties and vagueness are interesting. However I suspect none of this is going to matter. At least not in the short term, if ever. This is for casual, non-mission-critical, and educational use. After I have something that isn't vaporware (if I get to that stage), you can pop up again and warn people of the dangers. I hear you, and you have some valid points. Now please go away.
>
> There were the hacks one used to do with calculators where you'd divide a number of times by a number and then multiply it back and get something slightly off. Using that, Homer Simpson was able to disprove Fermat's Theorem by finding a solution to the equation a**12 + b**12 = c**12 in TI calculator math. Somehow though, calculators and mathematics were both able to survive this ordeal.

I think this is a laudable goal, and while RJF's admonitions are
valid, I don't think it should discourage you from trying to get
something working. I think even if you can get some simple cases
working it would be very impressive and useful.

As a technical note I don't think it would be worth trying to
implement this directly in the sage preparser, at least not yet. That
would be a can of worms. Just stick to a stand-alone transpiler
program that can parse Mathematica code and spit out some roughly
equivalent Python/Sage code. This would make the transpilation result
more transparent, and give you (or anyone else using it) opportunity
to review the transpiled code and modify it. Burying it in the sage
preparser would get too hairy and distract from the primary mission,
and would also make it more obscured.

> You received this message because you are subscribed to the Google Groups "sage-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CANCp2gaZh2_WnzhVsvM%3DcmEJdg6wKF22ooH%2Ba%3Dx0HfABXzagJA%40mail.gmail.com.

[Rocky Bernstein]

On Mon, Aug 31, 2020 at 1:00 PM E. Madison Bray <erik....@gmail.com> wrote:

On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
<rocky.b...@gmail.com> wrote:
>
> I think we've beat this to death. So let's agree to disagree.
>
> This kind of thing is not intended for someone like you, but rather, someone like me who is just getting started in Sage and CAS and wants to go through a number of simple Mma tutorials and see roughly corresponding results translated to another system. If that works out, I am happy, and may try more ambitious things.
>
> The specific examples showing how the various systems are hopelessly incompatible or where there are subtleties and vagueness are interesting. However I suspect none of this is going to matter. At least not in the short term, if ever. This is for casual, non-mission-critical, and educational use.  After I have something that isn't vaporware (if I get to that stage), you can pop up again and warn people of the dangers. I hear you, and you have some valid points. Now please go away.
>
> There were the hacks one used to do with calculators where you'd divide a number of times by a number and then multiply it back and get something slightly off. Using that, Homer Simpson was able to disprove Fermat's Theorem by finding a solution to the equation  a**12 + b**12 = c**12 in TI calculator math. Somehow though, calculators and mathematics were both able to survive this ordeal.

I think this is a laudable goal, and while RJF's admonitions are
valid, I don't think it should discourage you from trying to get
something working.

Actually, it's had the opposite effect. 

 

  I think even if you can get some simple cases
working it would be very impressive and useful.

What can be handled now is in  https://github.com/rocky/FoxySheep2/tree/master/pytest/parse_expressions, And installing should be pretty is as easy as: pip install FoxySheep

The main limiting factor is having time, need, or desire to work on it. It feels like there is a great deal that can be done and there is a lot of low-hanging fruit for anyone who wants to work on. 

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAOTD34YgEMj%2Bim%2BAE7AHekQ-R7rpP6-Cek2owAX8%2BJt_jcOceQ%40mail.gmail.com.

[David Joyner]

FYI, related to this thread, it looks like Rocky and a few colleagues are giving an upcoming talk (2020-10-30) on Mathics at SD110:

https://researchseminars.org/seminar/SageDays110

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CANCp2gbv4qJLSpUgu-ie2gaPaU_etJTCG_JbMSTXtvJnV2fphA%40mail.gmail.com.

[Rocky Bernstein]

Thanks for the kind words. 

I just posted a general announcement of the recent release candidate. See https://groups.google.com/g/sage-devel/c/676IgptcB7I

Something I personally am interested in is interoperability between the various systems and backends. 

One thing that comes to mind is taking WL code and producing Python code for it. There are a couple of ways this can go.

The easiest is something like this:

#!/usr/bin/env python

from mathics import evaluate 

evaluate("""

(* put your WL code here for example: *)

Range[3, 5]

""")

At the next level is using Mathics Expression which uses Python syntax but WL function as strings: 

#!/usr/bin/env python

from mathics import Expression

Expression("Range", 3, 5))

The next level might be calling the Mathics functions (like "Range") more directly. I won't give an example here. 

And finally more along the line of what I had mentioned earlier where even where simple and reliable cases get translated automatically into Python or sympy equivalents: 

#!/usr/bin/env python

range(3,5)

Within a translation there could be mixtures of all of these, some things done as strings, some things done as calls to functions, and some things (probably more of a glue-like nature like range(),  done as translations to Python and sympy.  

The overall idea is not that all of this is automatic and flawless, but that it could aid translation of WL into some other system of your choosing. 

All of this is a bit ambitious (== vaporware). 

However, I'd love to hear other ideas and thoughts as to how to bridge or bring the various communities together.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAEQuuAVtYh-FFhsuU%2BsFQAKRVCb0m6UKcjHTLCnNH1TZ6ps3EQ%40mail.gmail.com.