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 we

Re: [sage-devel] Error in Trac reports

[Dave Morris]

Report "{93} Active tickets I participated in (by time) (copy) 
" does not include the closed tickets 
(for me, at least).  I found this in the "Available Reports" link on trac.

On Sunday, July 5, 2020 at 4:47:40 PM UTC-6, Dima Pasechnik wrote:
>
>
>
> On Sun, 5 Jul 2020, 23:42 Paul Masson, > 
> wrote:
>
>> Report 51 (Active tickets I participated in / by time) includes closed 
>> tickets. Since these are available in report 54 (Tickets I've participated 
>> in, including closed / by time) the former should be adjusted to exclude 
>> them. Who has access to fix this? Thanks.
>>
>
> I have access, but no idea what happened, even less how to fix it. It 
> seems as if semantics of queries has changed after an update.
> Try making a custom query and see if you get meaningful results.
> Cc Erik, who used to be fixing trac.
>
> Dima
>
>> -- 
>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/390924b6-26d9-42f6-a57f-9ea4b8914694o%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/0b338ce2-f1ab-4bce-b2e9-b43e3a251981o%40googlegroups.com.

Re: [sage-devel] Error in Trac reports

[Dima Pasechnik]

On Sun, 5 Jul 2020, 23:42 Paul Masson,  wrote:

> Report 51 (Active tickets I participated in / by time) includes closed
> tickets. Since these are available in report 54 (Tickets I've participated
> in, including closed / by time) the former should be adjusted to exclude
> them. Who has access to fix this? Thanks.
>

I have access, but no idea what happened, even less how to fix it. It seems
as if semantics of queries has changed after an update.
Try making a custom query and see if you get meaningful results.
Cc Erik, who used to be fixing trac.

Dima

> --
> 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/390924b6-26d9-42f6-a57f-9ea4b8914694o%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/CAAWYfq14hEt81jPEn1v%2BuBYkW%3Dc9QoCFU41c8viqr2LTo7pQ8Q%40mail.gmail.com.

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.

[sage-devel] Error in Trac reports

[Paul Masson]

Report 51 (Active tickets I participated in / by time) includes closed 
tickets. Since these are available in report 54 (Tickets I've participated 
in, including closed / by time) the former should be adjusted to exclude 
them. Who has access to fix this? Thanks.

-- 
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/390924b6-26d9-42f6-a57f-9ea4b8914694o%40googlegroups.com.

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

[rjf]

You could take a look at what Albert Rich has done for testing Rubi in 
different systems.
Also, the theorem proving people using Coq want to match up with CAS.
Also, the history of formalizing mathematics  (Frege, Russell, etc) may
influence your thinking. Maybe discourage you; see the history of tarpits.

My view is colored by the fact that different CAS do not even agree
on the semantics of sin(x)  or Sin[x],  e.g. how it simplifies.
MathML does not care, I suspect. OpenMath used to say something
like "the usual sine(x)" which is a cop-out. What is sin(2*x)?

If you really want to make them all talk to each other, I think
you have to pick one CAS, preferably the most full-featured
one available (maybe insist on it being free?)  and then
translate everything to it.  To compare an expression in
Maple and Mathematica,  convert them both to the same
CAS.  e.g. one , or the other,  or both to (say) Maxima.
Even this is tough ... to translate maple sin(x) to Maxima, you
need to invent maple_sin_in_maxima(x).
etc

I don't think openmath will suffice.


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 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/9ce8d876-62b7-4beb-a6dd-71ea20d4ff37o%40googlegroups.com.

[sage-devel] Re: 2 issues with 9.2.beta3

[Matthias Koeppe]

On Sunday, July 5, 2020 at 2:33:40 AM UTC-7, David Coudert wrote:
>
>
> 2) With this working 9.2.beta3, I found 2 doctests errors in 
> sage/graphs/connectivity.pyx (see below).
> I can reproduce the errors inside the sage console.
>
> Then I realized that I forgot to "source .homebrew-build-env" before "make 
> build".
> So I "source .homebrew-build-env" and now all tests pass (without extra 
> "make build").
>
>  
Yes, we should make the variables set by "source .homebrew-build-env" at 
configure time persist for future "make" invocations. This is covered by 
https://trac.sagemath.org/ticket/29507 ("precious variables")

-- 
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/cda9bbfd-f413-499b-834f-a706532a1eaao%40googlegroups.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 "sage

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] Unable to build sage

[Dima Pasechnik]

On Sun, Jul 5, 2020 at 10:30 AM  wrote:
>
> On Sat, Jul 04, 2020 at 06:44:59PM -0700, Daniel Bump wrote:
> >
> >
> > On Saturday, July 4, 2020 at 3:12:36 PM UTC-7, Dima Pasechnik wrote:
> > >
> > > I guess this is due to gfortran 10.
> > > We still do not support gcc 10, I think.
> > > Can you downgrade it to gfortran 9?
> > >
> >
> > I had gfortran10 which came with gcc. In installed gfortran (with Homebrew)
> > which gave me gfortran 8.2. I was then able to build sage.
>
> Your config.log says you're using gfortran 10.
> Most probably it causes the failure to build scipy.
>
> I see what happened:
> https://formulae.brew.sh/cask/gfortran
> says it's version 8.2, and that it conflicts with
> Homebrew's gcc package, which is gcc10, which also gives you
> gfortran10.
>
> So you have a number of ways to proceed:
> 1) remove gcc package (you don't need it for Sage, as
> We don't build Sage with "real" gcc on macOS for years. Xcode has gcc
> which is actually clang, the default macOS C/C++ compiler, and this
> might cause the confusion.  One does need a fortran compiler, and we
> support gfortran, which happens to be a part of gcc, so an extra
> potential confusion here)
> and re-install gfortran package (which should give you gfortran 8.2,
> which works with Sage).
> This is probably the quckest way to get a working Sage
>
> 2) Stay on gcc10, and merge https://trac.sagemath.org/ticket/29766
> (currently marked as "needs work", due to some warning messages causing
> some tests fail, nothing serious)
> Cross your fingers, perhaps it will work.

An advantage of gcc10 that with it you can also use Homebrew's openblas, gsl,
perhaps R. Given that Homebrew's scipy package is built with gcc10,
this looks promising.

>
>
> HTH
> Dima
>
>

-- 
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/CAAWYfq3sO09HM96x1fswH093802dpFg_F28FkmMcBMCJgmsDSA%40mail.gmail.com.

Re: [sage-devel] 2 issues with 9.2.beta3

[Dima Pasechnik]

On Sun, Jul 5, 2020 at 10:33 AM David Coudert  wrote:
>
> Hello,
>
> 1) To be able to compile the documentation of 9.2.beta2, I had to "export 
> LANG=C.UTF-8 "
> See discussion here 
> https://groups.google.com/forum/#!topic/sage-release/7wBxNRbJaaU
>
> But after "git pull" on develop branch to get 9.2.beta3, "make" fails quickly.
> It indicates that language related variables were not properly sets.
> So I started a new shell without  "export LANG=C.UTF-8 " and was able to 
> complete "make build".
> However, I'm unable to compile documentation. To compile it, I certainly need 
> to "export LANG=C.UTF-8" as for 9.2.beta2.
>
> I don't know how to get something consistent here.

we have https://trac.sagemath.org/ticket/30002 - positively reviewed,
but not yet in beta, I suppose.
I suppose that with it in it will all work.

>
>
> 2) With this working 9.2.beta3, I found 2 doctests errors in 
> sage/graphs/connectivity.pyx (see below).
> I can reproduce the errors inside the sage console.
>
> Then I realized that I forgot to "source .homebrew-build-env" before "make 
> build".
> So I "source .homebrew-build-env" and now all tests pass (without extra "make 
> build").
>
>
> Let's hope we can fix these issues in a forthcoming release.
>
> Best,
> David.
>
>
> sage -t src/sage/graphs/connectivity.pyx
>
> **
>
> File "src/sage/graphs/connectivity.pyx", line 2671, in 
> sage.graphs.connectivity._Component.__init__
>
> Failed example:
>
> cython(os.linesep.join(cython_code))
>
> Exception raised:
>
> Traceback (most recent call last):
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/unixccompiler.py",
>  line 118, in _compile
>
> extra_postargs)
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/ccompiler.py",
>  line 910, in spawn
>
> spawn(cmd, dry_run=self.dry_run)
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/spawn.py",
>  line 36, in spawn
>
> _spawn_posix(cmd, search_path, dry_run=dry_run)
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/spawn.py",
>  line 159, in _spawn_posix
>
> % (cmd, exit_status))
>
> distutils.errors.DistutilsExecError: command 'gcc' failed with exit 
> status 1
>
>
> During handling of the above exception, another exception occurred:
>
>
> Traceback (most recent call last):
>
>   File 
> "/Users/dcoudert/sage/local/lib/python3.7/site-packages/sage/misc/cython.py", 
> line 371, in cython
>
> dist.run_command("build")
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/dist.py",
>  line 985, in run_command
>
> cmd_obj.run()
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build.py",
>  line 135, in run
>
> self.run_command(cmd_name)
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/cmd.py",
>  line 313, in run_command
>
> self.distribution.run_command(command)
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/dist.py",
>  line 985, in run_command
>
> cmd_obj.run()
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build_ext.py",
>  line 340, in run
>
> self.build_extensions()
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build_ext.py",
>  line 449, in build_extensions
>
> self._build_extensions_serial()
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build_ext.py",
>  line 474, in _build_extensions_serial
>
> self.build_extension(ext)
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build_ext.py",
>  line 534, in build_extension
>
> depends=ext.depends)
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/ccompiler.py",
>  line 574, in compile
>
> self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
>
>   File 
> "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/unixccompiler.py",
>  line 120, in _compile
>
> raise CompileError(msg)
>
> distutils.errors.CompileError: command 'gcc' failed with exit status 1
>
>
> During handling of the above exception, another exception occurred:
>
>
> Traceback (most recent call last):
>
>   File

[sage-devel] 2 issues with 9.2.beta3

[David Coudert]

Hello,

1) To be able to compile the documentation of 9.2.beta2, I had to "export 
LANG=C.UTF-8 "
See discussion here 
https://groups.google.com/forum/#!topic/sage-release/7wBxNRbJaaU 

But after "git pull" on develop branch to get 9.2.beta3, "make" fails 
quickly.
It indicates that language related variables were not properly sets.
So I started a new shell without  "export LANG=C.UTF-8 " and was able to 
complete "make build".
However, I'm unable to compile documentation. To compile it, I certainly 
need to "export LANG=C.UTF-8" as for 9.2.beta2.

I don't know how to get something consistent here.


2) With this working 9.2.beta3, I found 2 doctests errors in 
sage/graphs/connectivity.pyx (see below).
I can reproduce the errors inside the sage console.

Then I realized that I forgot to "source .homebrew-build-env" before "make 
build".
So I "source .homebrew-build-env" and now all tests pass (without extra 
"make build").


Let's hope we can fix these issues in a forthcoming release.

Best,
David.


sage -t src/sage/graphs/connectivity.pyx

**

File "src/sage/graphs/connectivity.pyx", line 2671, in 
sage.graphs.connectivity._Component.__init__

Failed example:

cython(os.linesep.join(cython_code))

Exception raised:

Traceback (most recent call last):

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/unixccompiler.py",
 
line 118, in _compile

extra_postargs)

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/ccompiler.py",
 
line 910, in spawn

spawn(cmd, dry_run=self.dry_run)

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/spawn.py",
 
line 36, in spawn

_spawn_posix(cmd, search_path, dry_run=dry_run)

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/spawn.py",
 
line 159, in _spawn_posix

% (cmd, exit_status))

distutils.errors.DistutilsExecError: command 'gcc' failed with exit 
status 1


During handling of the above exception, another exception occurred:


Traceback (most recent call last):

  File 
"/Users/dcoudert/sage/local/lib/python3.7/site-packages/sage/misc/cython.py", 
line 371, in cython

dist.run_command("build")

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/dist.py",
 
line 985, in run_command

cmd_obj.run()

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build.py",
 
line 135, in run

self.run_command(cmd_name)

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/cmd.py",
 
line 313, in run_command

self.distribution.run_command(command)

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/dist.py",
 
line 985, in run_command

cmd_obj.run()

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build_ext.py",
 
line 340, in run

self.build_extensions()

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build_ext.py",
 
line 449, in build_extensions

self._build_extensions_serial()

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build_ext.py",
 
line 474, in _build_extensions_serial

self.build_extension(ext)

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/command/build_ext.py",
 
line 534, in build_extension

depends=ext.depends)

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/ccompiler.py",
 
line 574, in compile

self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)

  File 
"/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/unixccompiler.py",
 
line 120, in _compile

raise CompileError(msg)

distutils.errors.CompileError: command 'gcc' failed with exit status 1


During handling of the above exception, another exception occurred:


Traceback (most recent call last):

  File 
"/Users/dcoudert/sage/local/lib/python3.7/site-packages/sage/doctest/forker.py",
 
line 707, in _run

self.compile_and_execute(example, compiler, test.globs)

  File 
"/Users/dcoudert/sage/local/lib/python3.7/site-packages/sage/doctest/forker.py",
 
line 1131, in compile_and_execute

exec(compiled, globs)

  File "", 
line 1, in 

cython(os.linesep.join(cython_code))

  File "sage/misc/lazy_import.pyx

Re: [sage-devel] Unable to build sage

[dimpase]

On Sat, Jul 04, 2020 at 06:44:59PM -0700, Daniel Bump wrote:
> 
> 
> On Saturday, July 4, 2020 at 3:12:36 PM UTC-7, Dima Pasechnik wrote:
> >
> > I guess this is due to gfortran 10.
> > We still do not support gcc 10, I think.
> > Can you downgrade it to gfortran 9?
> >
> 
> I had gfortran10 which came with gcc. In installed gfortran (with Homebrew)
> which gave me gfortran 8.2. I was then able to build sage.

Your config.log says you're using gfortran 10.
Most probably it causes the failure to build scipy.

I see what happened:
https://formulae.brew.sh/cask/gfortran
says it's version 8.2, and that it conflicts with
Homebrew's gcc package, which is gcc10, which also gives you 
gfortran10.

So you have a number of ways to proceed: 
1) remove gcc package (you don't need it for Sage, as
We don't build Sage with "real" gcc on macOS for years. Xcode has gcc
which is actually clang, the default macOS C/C++ compiler, and this
might cause the confusion.  One does need a fortran compiler, and we
support gfortran, which happens to be a part of gcc, so an extra
potential confusion here)
and re-install gfortran package (which should give you gfortran 8.2,
which works with Sage).
This is probably the quckest way to get a working Sage

2) Stay on gcc10, and merge https://trac.sagemath.org/ticket/29766
(currently marked as "needs work", due to some warning messages causing
some tests fail, nothing serious)
Cross your fingers, perhaps it will work.


HTH
Dima


-- 
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/20200705093013.GA7410%40hilbert.lan.

Re: [sage-devel] Unable to build sage

[Dima Pasechnik]

On Sun, Jul 5, 2020 at 2:45 AM Daniel Bump  wrote:
>
>
>
> On Saturday, July 4, 2020 at 3:12:36 PM UTC-7, Dima Pasechnik wrote:
>>
>> I guess this is due to gfortran 10.
>> We still do not support gcc 10, I think.
>> Can you downgrade it to gfortran 9?
>
>
> I had gfortran10 which came with gcc. In installed gfortran (with Homebrew)
> which gave me gfortran 8.2. I was then able to build sage.
>
> Thanks!
> Dan
>
>
> --
> 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/1f6c7908-af7a-4438-b2da-4d8994d7ba25o%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/CAAWYfq350DOgpQCeKbxC4XeQk5yLBzFXE1HdBP%2BJHYW-Wv-DNg%40mail.gmail.com.