Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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.


On Wed, Oct 28, 2020 at 8:17 AM David Joyner  wrote:

>
> 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
>
>
>
> On Mon, Aug 31, 2020 at 1:44 PM Rocky Bernstein 
> wrote:
>
>>
>>
>> On Mon, Aug 31, 2020 at 1:00 PM E. Madison Bray 
>> wrote:
>>
>>> On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
>>>  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.
>>
>
>
>
>>
>>
>>> 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.
>>>
>>>
>>>
>>> > On Mon, Jul 13, 2020 at 4:25 PM rjf  wrote:
>>> >>
>>> >> the problem I see here is the recipe
>>> >>
>>> >> requiring "user choice"  and somehow specifying "inf in Mma"
>>> >>
>>> >> Most users will not want to 

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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



On Mon, Aug 31, 2020 at 1:44 PM Rocky Bernstein 
wrote:

>
>
> On Mon, Aug 31, 2020 at 1:00 PM E. Madison Bray 
> wrote:
>
>> On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
>>  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.
>



>
>
>> 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.
>>
>>
>>
>> > On Mon, Jul 13, 2020 at 4:25 PM rjf  wrote:
>> >>
>> >> 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 

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[Rocky Bernstein]

On Mon, Aug 31, 2020 at 1:00 PM E. Madison Bray 
wrote:

> On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
>  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.


> 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.
>
>
>
> > On Mon, Jul 13, 2020 at 4:25 PM rjf  wrote:
> >>
> >> 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.)
> >>
> >>
> >>
> >> --
> >> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> >> To 

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[E. Madison Bray]

On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
 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.



> On Mon, Jul 13, 2020 at 4:25 PM rjf  wrote:
>>
>> 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.)
>>
>>
>>
>> --
>> 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+unsubscr...@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.
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this 

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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.

On Mon, Jul 13, 2020 at 4:25 PM rjf  wrote:

> 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.)
>
>
>
> --
> 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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@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.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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.)

 

-- 
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+unsubscr...@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.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[Rocky Bernstein]

On Fri, Jul 10, 2020 at 8:41 PM rjf  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.


>
> On Friday, July 10, 2020 at 11:30:51 AM UTC-7, Rocky Bernstein wrote:
>>
>> Ok. Something to consider is rendering to Mathematica output. (And then
>> doing the same thing for Sage.)
>>
>> On Fri, Jul 10, 2020 at 1:37 PM Fredrik Johansson 
>> wrote:
>>
>>> 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 

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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

On Friday, July 10, 2020 at 11:30:51 AM UTC-7, Rocky Bernstein wrote:
>
> Ok. Something to consider is rendering to Mathematica output. (And then 
> doing the same thing for Sage.)
>
> On Fri, Jul 10, 2020 at 1:37 PM Fredrik Johansson  > wrote:
>
>> 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
>>
>> On Friday, July 10, 2020 at 5:21:07 PM UTC+2 rocky.b...@gmail.com wrote:
>>
>>> 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  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 

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[Rocky Bernstein]

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

On Fri, Jul 10, 2020 at 1:37 PM Fredrik Johansson <
fredrik.johans...@gmail.com> wrote:

> 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
>
> On Friday, July 10, 2020 at 5:21:07 PM UTC+2 rocky.b...@gmail.com wrote:
>
>> 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  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
>>> 
>>> .
>>>
>> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/050a44ed-e31b-4ddb-8687-fc9dcd53e3c1n%40googlegroups.com
> 
> .
>

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

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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

On Friday, July 10, 2020 at 5:21:07 PM UTC+2 rocky.b...@gmail.com wrote:

> 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  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
>>  
>> 
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/050a44ed-e31b-4ddb-8687-fc9dcd53e3c1n%40googlegroups.com.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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  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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CANCp2gZj6mR_kTPcm0Zr-fWR09ZCD%3D9Mg0T-%3DAWCokmJ53vSMw%40mail.gmail.com.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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.

-- 
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+unsubscr...@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.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[Rocky Bernstein]

Thanks for the kind words and encouragement.

On Mon, Jul 6, 2020 at 1:05 AM William  wrote:

> 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...)
>
>
>
> On Sunday, July 5, 2020 at 3:44:17 PM UTC-7, Rocky Bernstein wrote:
>>
>>
>>
>> On Sun, Jul 5, 2020 at 3:14 PM rjf  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
>>> 

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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...)


 
On Sunday, July 5, 2020 at 3:44:17 PM UTC-7, Rocky Bernstein wrote:
>
>
>
> On Sun, Jul 5, 2020 at 3:14 PM rjf  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+unsubscr...@googlegroups.com.
>> To view this discussion on the 

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[Rocky Bernstein]

On Sun, Jul 5, 2020 at 3:14 PM rjf  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+unsubscr...@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 the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CANCp2gbCfZYHKqV64UDuvVKnY%2BygPwg4f5oyP0rMtD308bW%2Bqw%40mail.gmail.com.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[Rocky Bernstein]

On Sat, Jul 4, 2020 at 3:29 PM 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.
>

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
   2. it is fairly complete in what it expresses,
   3. it is popular and ergonomic,
   4. 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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CANCp2gb65apSPt9hm%2BRJ-ir9Sxhy6B30CKVDPQT2DJy4y7g9Cg%40mail.gmail.com.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[Rocky Bernstein]

On Sat, Jul 4, 2020 at 7:40 PM rjf  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 

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[Dima Pasechnik]

On Sun, Jul 5, 2020 at 12:40 AM rjf  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+unsubscr...@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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1tE_NkDEaJJkSHew7Bd6a6cvzR7SgBUeQzdhFcPVZukA%40mail.gmail.com.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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



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+unsubscr...@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.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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. 

-- 
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+unsubscr...@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.

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

[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.







On Sat, Jul 4, 2020 at 9:44 AM kcrisman  wrote:

>
>
>
>> 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