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

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,

[sage-devel] [ANN] FoxySheep 1.2.1 released

I have to put this project on hold for a little bit, but since what's there is cool already I thought I'd mention it here. "FoxySheep" is the Python portion of Robert Jacobson's Mathematica parser, with a crude translator to Python. It also include translation from InputForm to FullForm and

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

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

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

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

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

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

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

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

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

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

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

(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

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

nstalled) have features which would support the given request. And going further in the hand-wavy far future one might imagine running the request on multiple or different backends and stitching together answers. But just showing a translation from one CAS language to another would ease the Tower-

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

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

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

; 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

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

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

[sage-devel] Mathics 1.1.0 released

... and just when you thought we'd never get around to it. This is now available from PyPI. It might be a simple as: $ pip install Mathics3 Note the "3" at the end. Without that you get the pre 1.1.0 code. Or you can run from the recently updated

[sage-devel] Mathics 1.1.0 Released

.. and just when you thought we'd never get around to it. This is now available from PyPI. It might be a simple as: $ pip install Mathics Or you can run from the recently updated dockerhub image : $ docker

[sage-devel] Mathics 1.1rc1 released

Hey all - After a gap of 4 years, we've have a new pre-release for Mathics: Mathics 1.1rc1. In brief, there are over 50 new built-in functions, and we've updated the code so that it now works current releases of the software it uses: Python, sympy, Django, etc. Details of the release can be

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

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

[sage-devel] Re: Running MathicsSession inside Sage

I asked about this in the mpmath group and the solution there I think is good and only requires a change (or rather simplification) to the Mathics code. So as far as I am concerned no changes are needed to sage or mpmath. See https://groups.google.com/g/mpmath/c/qzA5gs57Qm8/m/_eg4GHisAAAJ On

[sage-devel] Re: Running MathicsSession inside Sage

I spent some time looking over the links in the ticket cited. I am trying to understand why mpmath decided to do something special for sage and whether that is relevant still. I will ask on mpmath... On Thursday, March 25, 2021 at 12:19:59 PM UTC-4 Matthias Koeppe wrote: > Sounds like

[sage-devel] Why does mpath special case for the sage backend?

Recently this has been an issue in that sage doesn't expose the mpf class. See https://groups.google.com/g/sage-devel/c/hUJeK4r34k8 What is the history around having a special sage back end? If this is about Pythoin Pickle differences between Python2 and Python3, I support for Python2 were

Re: [sage-devel] Why does mpath special case for the sage backend?

806532433 for the full details. I've opened a ticket to update: https://trac.sagemath.org/ticket/31564 > > On Thu, Mar 25, 2021 at 11:59 PM Rocky Bernstein > wrote: > > > > Recently this has been an issue in that sage doesn't expose the mpf > class. > > > > See https:/

Re: [sage-devel] Re: Interface to Mathics

since it's really good. > > -- William > > On Thu, Sep 9, 2021 at 4:17 AM Rocky Bernstein > wrote: > > > > In the past year we have: > > > > Upgraded all packages and libraries that Mathics depends on > > Broken up what was one single repository into se