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 <wdjoy...@gmail.com> 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 <rocky.bernst...@gmail.com>
> wrote:
>
>>
>>
>> On Mon, Aug 31, 2020 at 1:00 PM E. Madison Bray <erik.m.b...@gmail.com>
>> wrote:
>>
>>> On Tue, Jul 14, 2020 at 12:12 AM Rocky Bernstein
>>> <rocky.bernst...@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.
>>
>
>
>
>>
>>
>>> 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 <fate...@gmail.com> 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
>>> .
>>>
>>> --
>>> 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/CAOTD34YgEMj%2Bim%2BAE7AHekQ-R7rpP6-Cek2owAX8%2BJt_jcOceQ%40mail.gmail.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/CANCp2gbv4qJLSpUgu-ie2gaPaU_etJTCG_JbMSTXtvJnV2fphA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/sage-devel/CANCp2gbv4qJLSpUgu-ie2gaPaU_etJTCG_JbMSTXtvJnV2fphA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/CAEQuuAVtYh-FFhsuU%2BsFQAKRVCb0m6UKcjHTLCnNH1TZ6ps3EQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/sage-devel/CAEQuuAVtYh-FFhsuU%2BsFQAKRVCb0m6UKcjHTLCnNH1TZ6ps3EQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CANCp2gYaURYkdJeGeAfLkhWhHQO4KD2Xh3Bt6z8drik9%2Bg_1qA%40mail.gmail.com.
