Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-02-17 Thread Dima Pasechnik 


On Sunday, January 24, 2021 at 9:17:14 PM UTC rjf wrote:

> Just a note to point out that infix  like a+b*c  in a conventional 
> programming language
> is not helpful if a,b,c  are symbolic expressions..  Writing it as  add(a, 
> mul(b,c)) is not
> a big deal,  nor is writing it in lisp  (add a (mul b c)).  Of course you 
> need to write programs
> add and mul,  but you have to do that regardless.  Languages that are 
> primarily oriented
> to provide arithmetic on fixed-length integers or double-float numbers, 
> mostly have to be
> covered over by macros etc to do computer algebra.  Languages like 
> FORTRAN, Algol, C.
>
> You could look at RLISP used for Reduce, if you want to see a version of 
> lisp with "syntactic sugar"
> to look "infix" ish. And that is used for a computer algebra system, 
> Reduce.
>
>  There is something of a tradition, to hand to someone, perhaps someone
> who prefers infix, a project to "Write a scanner/parser/code generator  
> for an infix language
> of your design [ or pick one, say Pascal]" in Lisp.
>  I've done this with programming language/compiler
> undergraduate classes at Berkeley for decades, with probably thousands of 
> students.
> It takes 10 weeks, assuming you know no lisp, nothing about lexical 
> analysis,
> nothing about parsing, nothing about intermediate code generation. and 
> maybe
> nothing about Pascal.
>
> At the completion of the project, most students prefer Lisp's 
> parenthesized prefix.
> They also understand Pascal better, having written an interpreter and 
> compiler for it.
>

Mind you, the initial versions of an alive and kicking computational group 
theory system GAP was mostly written by maths
students in RWTH Aachen 25-30 years ago. 

One could ask why human-years of relatively good quality LISP coders coding 
time were wasted doing the same
lab projects, and not something more creative, like impoving Maxima code. :P

LISP enthousiasts, including many US academics, have mostly themselves to 
blame for  the present sorry state of 
computer algebra in LISP...
 

>
> Often they choose to use Lisp for other projects, given a choice.
>
> Most criticisms of Lisp come from people who have never used it, and it 
> shows.
> Complaints about too many parentheses. No, there are just exactly enough, 
> and
> your editor helps.  Or indentation (hi Pythonistas). Editors indent for 
> you, exactly right.
> Not webby enough (see cl-http or other packages).
> Too slow (uh, faster than Python, some excellent optimizing compilers for 
> Lisp).
> Too hard to learn.   Think about how much time you spent in learning your 
> current
> favorite language on the precedence of operators. Or what the operators 
> meant.
> Or what happens when integers "overflow".
>
> Consider learning Lisp.
>
>
>
> Parts of Macsyma/Maxima are more like 60 years old. Almost as old as Lisp 
> (circa 1959).
> James Slagle's 1961 PhD on symbolic integration (SAI'NT) includes a 
> substantial section explaining Lisp,
> which was quite new at the time .
>
>
> On Friday, January 22, 2021 at 11:36:06 AM UTC-8 parisse wrote:
>
>> I (almost) do not code C++ myself, probably 99% of my code is C-style, 
>> but I'm using a C++ compiler, that way I can link to the C++ standard 
>> template library and benefit of features like operator overload. Doing so, 
>> I do not have screens of error messages.
>>
>> Le vendredi 22 janvier 2021 à 15:07:51 UTC+1, dim...@gmail.com a écrit :
>>
>>> On Thu, Jan 21, 2021 at 8:04 PM parisse  
>>> wrote: 
>>> > 
>>> > Well, searching for "lisp infix notation" is not very convincing 
>>> (unless I missed something?), compared to built-in infix support. You might 
>>> prefer Lisp to C/C++, it's your choice, but I don't see any objective 
>>> reason that one should stay away from C/C++. And Giac is a proof that one 
>>> can actually write a CAS in C/C++, that compares very well with the 
>>> Lisp-based CAS Maxima. 
>>>
>>> Maxima is ~40 years old with a bit of work done since then, but the 
>>> core is that old, as far as I know: 
>>> https://en.wikipedia.org/wiki/Macsyma 
>>>
>>> As for staying away from C++, most people who might be trying to do 
>>> something with supposedly state of the art library like boost, 
>>> would run away screaming, closely followed by 100 screens of error 
>>> messages :-) 
>>> Or, now mostly gone (?), iterator_traits (my closest encounter with 
>>> C++, contributing to CGAL, 20 years ago, where these had to be 
>>> generated by a script for some classes, otherwise compilers kept 
>>> crashing...) 
>>>
>>>
>>>
>>>
>>>
>>> > Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit : 
>>> >> 
>>> >> On Wed, Jan 20, 2021 at 7:13 PM parisse  
>>> wrote: 
>>> >> > 
>>> >> > As the author of a CAS, I can state that you need much more than 2 
>>> weeks to learn a programming language to make a CAS, and much much more if 
>>> you want to be fast. Life is short, therefore choose your programming 
>>> language carefully! I don't regret m

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-25 Thread Michael Orlitzky 
On Mon, 2021-01-25 at 12:08 +0100, Vincent Delecroix wrote:
> Shouldn't it be
> 
> (- (* a d) (* b c))
> 
> and
> 
> (- (* b b) (* 4 a c)))
> 
> 

The unary "negate" operation and the binary "subtract" operation are
usually distinguished by context, i.e. by whether prefix or infix
notation is used. Unless you do some tricks (like calling one "sub"),
the above would likely be parsed as an attempt to call "negate" with
two arguments, which is a syntax error.


-- 
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/79339bbcd3b813d1ab6ebc7cc1fd2b32f03463e5.camel%40orlitzky.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-25 Thread Vincent Delecroix 

Shouldn't it be

(- (* a d) (* b c))

and

(- (* b b) (* 4 a c)))

Le 25/01/2021 à 07:53, parisse a écrit :

rjf, I wonder why you say that " infix  like a+b*c  in a conventional
programming language is not helpful if a,b,c  are symbolic expressions". Of
course it is, otherwise CAS would not use infix notation in their user
interfaces. Parts of my source code are much easier to write and read with
infix notations than with prefix notation. This is perhaps not true in
other application areas, but CAS is about programming math algorithms. It's
not a question of parentheses match, of course a programming editor will
help you match them. But what do you prefer to read/write:
* det=a*d-b*c
* store(det,sub(mul(a,d),mul(b,c)))
Or
* delta=b*b-4*a*c
* store(delta,sub(mul(b,b),mul(4,mul(a,c)


Le dimanche 24 janvier 2021 à 22:17:14 UTC+1, rjf a écrit :


Just a note to point out that infix  like a+b*c  in a conventional
programming language
is not helpful if a,b,c  are symbolic expressions..  Writing it as  add(a,
mul(b,c)) is not
a big deal,  nor is writing it in lisp  (add a (mul b c)).  Of course you
need to write programs
add and mul,  but you have to do that regardless.  Languages that are
primarily oriented
to provide arithmetic on fixed-length integers or double-float numbers,
mostly have to be
covered over by macros etc to do computer algebra.  Languages like
FORTRAN, Algol, C.

You could look at RLISP used for Reduce, if you want to see a version of
lisp with "syntactic sugar"
to look "infix" ish. And that is used for a computer algebra system,
Reduce.

  There is something of a tradition, to hand to someone, perhaps someone
who prefers infix, a project to "Write a scanner/parser/code generator
for an infix language
of your design [ or pick one, say Pascal]" in Lisp.
  I've done this with programming language/compiler
undergraduate classes at Berkeley for decades, with probably thousands of
students.
It takes 10 weeks, assuming you know no lisp, nothing about lexical
analysis,
nothing about parsing, nothing about intermediate code generation. and
maybe
nothing about Pascal.

At the completion of the project, most students prefer Lisp's
parenthesized prefix.
They also understand Pascal better, having written an interpreter and
compiler for it.

Often they choose to use Lisp for other projects, given a choice.

Most criticisms of Lisp come from people who have never used it, and it
shows.
Complaints about too many parentheses. No, there are just exactly enough,
and
your editor helps.  Or indentation (hi Pythonistas). Editors indent for
you, exactly right.
Not webby enough (see cl-http or other packages).
Too slow (uh, faster than Python, some excellent optimizing compilers for
Lisp).
Too hard to learn.   Think about how much time you spent in learning your
current
favorite language on the precedence of operators. Or what the operators
meant.
Or what happens when integers "overflow".

Consider learning Lisp.



Parts of Macsyma/Maxima are more like 60 years old. Almost as old as Lisp
(circa 1959).
James Slagle's 1961 PhD on symbolic integration (SAI'NT) includes a
substantial section explaining Lisp,
which was quite new at the time .


On Friday, January 22, 2021 at 11:36:06 AM UTC-8 parisse wrote:


I (almost) do not code C++ myself, probably 99% of my code is C-style,
but I'm using a C++ compiler, that way I can link to the C++ standard
template library and benefit of features like operator overload. Doing so,
I do not have screens of error messages.

Le vendredi 22 janvier 2021 à 15:07:51 UTC+1, dim...@gmail.com a écrit :


On Thu, Jan 21, 2021 at 8:04 PM parisse 
wrote:


Well, searching for "lisp infix notation" is not very convincing

(unless I missed something?), compared to built-in infix support. You might
prefer Lisp to C/C++, it's your choice, but I don't see any objective
reason that one should stay away from C/C++. And Giac is a proof that one
can actually write a CAS in C/C++, that compares very well with the
Lisp-based CAS Maxima.

Maxima is ~40 years old with a bit of work done since then, but the
core is that old, as far as I know:
https://en.wikipedia.org/wiki/Macsyma

As for staying away from C++, most people who might be trying to do
something with supposedly state of the art library like boost,
would run away screaming, closely followed by 100 screens of error
messages :-)
Or, now mostly gone (?), iterator_traits (my closest encounter with
C++, contributing to CGAL, 20 years ago, where these had to be
generated by a script for some classes, otherwise compilers kept
crashing...)






Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit :


On Wed, Jan 20, 2021 at 7:13 PM parisse 

wrote:


As the author of a CAS, I can state that you need much more than 2

weeks to learn a programming language to make a CAS, and much much more if
you want to be fast. Life is short, therefore choose your programming
language carefully! I don't regret my choice for C (+ C++ STL and operat

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-24 Thread parisse 
rjf, I wonder why you say that " infix  like a+b*c  in a conventional 
programming language is not helpful if a,b,c  are symbolic expressions". Of 
course it is, otherwise CAS would not use infix notation in their user 
interfaces. Parts of my source code are much easier to write and read with 
infix notations than with prefix notation. This is perhaps not true in 
other application areas, but CAS is about programming math algorithms. It's 
not a question of parentheses match, of course a programming editor will 
help you match them. But what do you prefer to read/write:
* det=a*d-b*c 
* store(det,sub(mul(a,d),mul(b,c)))
Or 
* delta=b*b-4*a*c
* store(delta,sub(mul(b,b),mul(4,mul(a,c)


Le dimanche 24 janvier 2021 à 22:17:14 UTC+1, rjf a écrit :

> Just a note to point out that infix  like a+b*c  in a conventional 
> programming language
> is not helpful if a,b,c  are symbolic expressions..  Writing it as  add(a, 
> mul(b,c)) is not
> a big deal,  nor is writing it in lisp  (add a (mul b c)).  Of course you 
> need to write programs
> add and mul,  but you have to do that regardless.  Languages that are 
> primarily oriented
> to provide arithmetic on fixed-length integers or double-float numbers, 
> mostly have to be
> covered over by macros etc to do computer algebra.  Languages like 
> FORTRAN, Algol, C.
>
> You could look at RLISP used for Reduce, if you want to see a version of 
> lisp with "syntactic sugar"
> to look "infix" ish. And that is used for a computer algebra system, 
> Reduce.
>
>  There is something of a tradition, to hand to someone, perhaps someone
> who prefers infix, a project to "Write a scanner/parser/code generator  
> for an infix language
> of your design [ or pick one, say Pascal]" in Lisp.
>  I've done this with programming language/compiler
> undergraduate classes at Berkeley for decades, with probably thousands of 
> students.
> It takes 10 weeks, assuming you know no lisp, nothing about lexical 
> analysis,
> nothing about parsing, nothing about intermediate code generation. and 
> maybe
> nothing about Pascal.
>
> At the completion of the project, most students prefer Lisp's 
> parenthesized prefix.
> They also understand Pascal better, having written an interpreter and 
> compiler for it.
>
> Often they choose to use Lisp for other projects, given a choice.
>
> Most criticisms of Lisp come from people who have never used it, and it 
> shows.
> Complaints about too many parentheses. No, there are just exactly enough, 
> and
> your editor helps.  Or indentation (hi Pythonistas). Editors indent for 
> you, exactly right.
> Not webby enough (see cl-http or other packages).
> Too slow (uh, faster than Python, some excellent optimizing compilers for 
> Lisp).
> Too hard to learn.   Think about how much time you spent in learning your 
> current
> favorite language on the precedence of operators. Or what the operators 
> meant.
> Or what happens when integers "overflow".
>
> Consider learning Lisp.
>
>
>
> Parts of Macsyma/Maxima are more like 60 years old. Almost as old as Lisp 
> (circa 1959).
> James Slagle's 1961 PhD on symbolic integration (SAI'NT) includes a 
> substantial section explaining Lisp,
> which was quite new at the time .
>
>
> On Friday, January 22, 2021 at 11:36:06 AM UTC-8 parisse wrote:
>
>> I (almost) do not code C++ myself, probably 99% of my code is C-style, 
>> but I'm using a C++ compiler, that way I can link to the C++ standard 
>> template library and benefit of features like operator overload. Doing so, 
>> I do not have screens of error messages.
>>
>> Le vendredi 22 janvier 2021 à 15:07:51 UTC+1, dim...@gmail.com a écrit :
>>
>>> On Thu, Jan 21, 2021 at 8:04 PM parisse  
>>> wrote: 
>>> > 
>>> > Well, searching for "lisp infix notation" is not very convincing 
>>> (unless I missed something?), compared to built-in infix support. You might 
>>> prefer Lisp to C/C++, it's your choice, but I don't see any objective 
>>> reason that one should stay away from C/C++. And Giac is a proof that one 
>>> can actually write a CAS in C/C++, that compares very well with the 
>>> Lisp-based CAS Maxima. 
>>>
>>> Maxima is ~40 years old with a bit of work done since then, but the 
>>> core is that old, as far as I know: 
>>> https://en.wikipedia.org/wiki/Macsyma 
>>>
>>> As for staying away from C++, most people who might be trying to do 
>>> something with supposedly state of the art library like boost, 
>>> would run away screaming, closely followed by 100 screens of error 
>>> messages :-) 
>>> Or, now mostly gone (?), iterator_traits (my closest encounter with 
>>> C++, contributing to CGAL, 20 years ago, where these had to be 
>>> generated by a script for some classes, otherwise compilers kept 
>>> crashing...) 
>>>
>>>
>>>
>>>
>>>
>>> > Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit : 
>>> >> 
>>> >> On Wed, Jan 20, 2021 at 7:13 PM parisse  
>>> wrote: 
>>> >> > 
>>> >> > As the author of a CAS, I can state that you need much more tha

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-24 Thread rjf 
Just a note to point out that infix  like a+b*c  in a conventional 
programming language
is not helpful if a,b,c  are symbolic expressions..  Writing it as  add(a, 
mul(b,c)) is not
a big deal,  nor is writing it in lisp  (add a (mul b c)).  Of course you 
need to write programs
add and mul,  but you have to do that regardless.  Languages that are 
primarily oriented
to provide arithmetic on fixed-length integers or double-float numbers, 
mostly have to be
covered over by macros etc to do computer algebra.  Languages like FORTRAN, 
Algol, C.

You could look at RLISP used for Reduce, if you want to see a version of 
lisp with "syntactic sugar"
to look "infix" ish. And that is used for a computer algebra system, Reduce.

 There is something of a tradition, to hand to someone, perhaps someone
who prefers infix, a project to "Write a scanner/parser/code generator  for 
an infix language
of your design [ or pick one, say Pascal]" in Lisp.
 I've done this with programming language/compiler
undergraduate classes at Berkeley for decades, with probably thousands of 
students.
It takes 10 weeks, assuming you know no lisp, nothing about lexical 
analysis,
nothing about parsing, nothing about intermediate code generation. and maybe
nothing about Pascal.

At the completion of the project, most students prefer Lisp's parenthesized 
prefix.
They also understand Pascal better, having written an interpreter and 
compiler for it.

Often they choose to use Lisp for other projects, given a choice.

Most criticisms of Lisp come from people who have never used it, and it 
shows.
Complaints about too many parentheses. No, there are just exactly enough, 
and
your editor helps.  Or indentation (hi Pythonistas). Editors indent for 
you, exactly right.
Not webby enough (see cl-http or other packages).
Too slow (uh, faster than Python, some excellent optimizing compilers for 
Lisp).
Too hard to learn.   Think about how much time you spent in learning your 
current
favorite language on the precedence of operators. Or what the operators 
meant.
Or what happens when integers "overflow".

Consider learning Lisp.



Parts of Macsyma/Maxima are more like 60 years old. Almost as old as Lisp 
(circa 1959).
James Slagle's 1961 PhD on symbolic integration (SAI'NT) includes a 
substantial section explaining Lisp,
which was quite new at the time .


On Friday, January 22, 2021 at 11:36:06 AM UTC-8 parisse wrote:

> I (almost) do not code C++ myself, probably 99% of my code is C-style, but 
> I'm using a C++ compiler, that way I can link to the C++ standard template 
> library and benefit of features like operator overload. Doing so, I do not 
> have screens of error messages.
>
> Le vendredi 22 janvier 2021 à 15:07:51 UTC+1, dim...@gmail.com a écrit :
>
>> On Thu, Jan 21, 2021 at 8:04 PM parisse  
>> wrote: 
>> > 
>> > Well, searching for "lisp infix notation" is not very convincing 
>> (unless I missed something?), compared to built-in infix support. You might 
>> prefer Lisp to C/C++, it's your choice, but I don't see any objective 
>> reason that one should stay away from C/C++. And Giac is a proof that one 
>> can actually write a CAS in C/C++, that compares very well with the 
>> Lisp-based CAS Maxima. 
>>
>> Maxima is ~40 years old with a bit of work done since then, but the 
>> core is that old, as far as I know: 
>> https://en.wikipedia.org/wiki/Macsyma 
>>
>> As for staying away from C++, most people who might be trying to do 
>> something with supposedly state of the art library like boost, 
>> would run away screaming, closely followed by 100 screens of error 
>> messages :-) 
>> Or, now mostly gone (?), iterator_traits (my closest encounter with 
>> C++, contributing to CGAL, 20 years ago, where these had to be 
>> generated by a script for some classes, otherwise compilers kept 
>> crashing...) 
>>
>>
>>
>>
>>
>> > Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit : 
>> >> 
>> >> On Wed, Jan 20, 2021 at 7:13 PM parisse  
>> wrote: 
>> >> > 
>> >> > As the author of a CAS, I can state that you need much more than 2 
>> weeks to learn a programming language to make a CAS, and much much more if 
>> you want to be fast. Life is short, therefore choose your programming 
>> language carefully! I don't regret my choice for C (+ C++ STL and operator 
>> redefinition) made 20 years ago, because C can interact with a lot of 
>> languages (including compilation to Javascript). If I had to choose today, 
>> I would perhaps choose Julia. Not Python, it's much too slow. I don't know 
>> for Lisp speed, but it's not a language I would choose anyway, I like to 
>> write e.g. a+b*c when I do algebraic computations in my source code. 
>> >> 
>> >> There are macro packages for infix maths in Common Lisp, so this by no 
>> >> means should be a deal-breaker for anyone. 
>> >> 
>> >> Needless to say, C++ has its own can of worms, which anyone who tried 
>> >> to used it might easily produce, as a reason to stay 
>> >> away from it. 
>>

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-22 Thread parisse 
I (almost) do not code C++ myself, probably 99% of my code is C-style, but 
I'm using a C++ compiler, that way I can link to the C++ standard template 
library and benefit of features like operator overload. Doing so, I do not 
have screens of error messages.

Le vendredi 22 janvier 2021 à 15:07:51 UTC+1, dim...@gmail.com a écrit :

> On Thu, Jan 21, 2021 at 8:04 PM parisse  
> wrote:
> >
> > Well, searching for "lisp infix notation" is not very convincing (unless 
> I missed something?), compared to built-in infix support. You might prefer 
> Lisp to C/C++, it's your choice, but I don't see any objective reason that 
> one should stay away from C/C++. And Giac is a proof that one can actually 
> write a CAS in C/C++, that compares very well with the Lisp-based CAS 
> Maxima.
>
> Maxima is ~40 years old with a bit of work done since then, but the
> core is that old, as far as I know:
> https://en.wikipedia.org/wiki/Macsyma
>
> As for staying away from C++, most people who might be trying to do
> something with supposedly state of the art library like boost,
> would run away screaming, closely followed by 100 screens of error 
> messages :-)
> Or, now mostly gone (?), iterator_traits (my closest encounter with
> C++, contributing to CGAL, 20 years ago, where these had to be
> generated by a script for some classes, otherwise compilers kept
> crashing...)
>
>
>
>
>
> > Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit :
> >>
> >> On Wed, Jan 20, 2021 at 7:13 PM parisse  
> wrote:
> >> >
> >> > As the author of a CAS, I can state that you need much more than 2 
> weeks to learn a programming language to make a CAS, and much much more if 
> you want to be fast. Life is short, therefore choose your programming 
> language carefully! I don't regret my choice for C (+ C++ STL and operator 
> redefinition) made 20 years ago, because C can interact with a lot of 
> languages (including compilation to Javascript). If I had to choose today, 
> I would perhaps choose Julia. Not Python, it's much too slow. I don't know 
> for Lisp speed, but it's not a language I would choose anyway, I like to 
> write e.g. a+b*c when I do algebraic computations in my source code.
> >>
> >> There are macro packages for infix maths in Common Lisp, so this by no
> >> means should be a deal-breaker for anyone.
> >>
> >> Needless to say, C++ has its own can of worms, which anyone who tried
> >> to used it might easily produce, as a reason to stay
> >> away from it.
> >>
> >> >
> >> > Le mercredi 20 janvier 2021 à 19:47:01 UTC+1, rjf a écrit :
> >> >>
> >> >> I think you have to figure that there is a difference in 
> productivity of people who just learned Python in high school and would 
> really like to write a computer algebra system
> >> >> versus people who know more mathematics, are comfortable spending 2 
> weeks learning lisp, spending ?? (weeks? months?) studying the state of the 
> art in
> >> >> computer algebra systems as evolved over 60 years, and want to 
> contribute to advancing the art (rather than re-programming the easy stuff).
> >> >> I am under the impression that learning python is a reasonable 
> stepping stone to learning lisp.
> >> >>
> >> >> As far as checking results for various systems, there is a category 
> of CAS bugs that are syistem independent.
> >> >> That is, they occur in many systems! Sometimes they depend on 
> secretly dividing by zero, or doing something
> >> >> that is invalid at a singularity. So "Maple and Mathematica and ... 
> all agree" does not mean they are right!
> >> >>
> >> >> I think my essential point previously is that rewriting easy stuff 
> (in a different language) typically fails to push the frontier.
> >> >>
> >> >>
> >> >>
> >> >> On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:
> >> 
> >> 
> >>  As to the question of replacing backends, there is already a 
> ticket (which I cannot find right now, my apologies) which started the 
> process of seeing what doctests would fail if we went to Sympy as default. 
> Presumably something similar could be done with this engine (I don't know 
> if it is more for low-level symbolics or also things like integration).
> >> >>>
> >> >>>
> >> >>> In particular, the (very minimal) documentation (really an API is 
> all) makes it seems more a replacement for things like Ginac (already in 
> C++), not Maxima et al. I don't know if that would provide a noticeable 
> speedup per se, though the SageManifolds ticket mentioned parallelization 
> so perhaps it is better suited for that?
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send an email to sage-devel+...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/879dd941-95a0-4f2f-b5ac-96f60439f80dn%40googlegroups.com
> .
> >
> > --
> > You recei

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-22 Thread Thierry Dumont 
There was a message from B. Paisse some days ago, about C (++) and Julia 
for CAS.


May be this https://arxiv.org/pdf/1705.06134v1.pdf
is interesting.

t.d.

Le 22/01/2021 à 15:07, Dima Pasechnik a écrit :

On Thu, Jan 21, 2021 at 8:04 PM parisse  wrote:


Well, searching for "lisp infix notation" is not very convincing (unless I 
missed something?), compared to built-in infix support. You might prefer Lisp to C/C++, 
it's your choice, but I don't see any objective reason that one should stay away from 
C/C++. And Giac is a proof that one can actually write a CAS in C/C++, that compares very 
well with the Lisp-based CAS Maxima.


Maxima is ~40 years old with a bit of work done since then, but the
core is that old, as far as I know:
https://en.wikipedia.org/wiki/Macsyma

As for staying away from C++,  most people who might be trying to do
something with supposedly state of the art library like boost,
would run away screaming, closely followed by 100 screens of error messages :-)
Or, now mostly gone (?), iterator_traits (my closest encounter with
C++, contributing to CGAL, 20 years ago, where these had to be
generated by a script for some classes, otherwise compilers kept
crashing...)






Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit :


On Wed, Jan 20, 2021 at 7:13 PM parisse  wrote:


As the author of a CAS, I can state that you need much more than 2 weeks to 
learn a programming language to make a CAS, and much much more if you want to 
be fast. Life is short, therefore choose your programming language carefully! I 
don't regret my choice for C (+ C++ STL and operator redefinition) made 20 
years ago, because C can interact with a lot of languages (including 
compilation to Javascript). If I had to choose today, I would perhaps choose 
Julia. Not Python, it's much too slow. I don't know for Lisp speed, but it's 
not a language I would choose anyway, I like to write e.g. a+b*c when I do 
algebraic computations in my source code.


There are macro packages for infix maths in Common Lisp, so this by no
means should be a deal-breaker for anyone.

Needless to say, C++ has its own can of worms, which anyone who tried
to used it might easily produce, as a reason to stay
away from it.



Le mercredi 20 janvier 2021 à 19:47:01 UTC+1, rjf a écrit :


I think you have to figure that there is a difference in productivity of people 
who just learned Python in high school and would really like to write a 
computer algebra system
versus people who know more mathematics, are comfortable spending 2 weeks 
learning lisp, spending ?? (weeks? months?) studying the state of the art in
computer algebra systems as evolved over 60 years, and want to contribute to 
advancing the art (rather than re-programming the easy stuff).
I am under the impression that learning python is a reasonable stepping stone 
to learning lisp.

As far as checking results for various systems, there is a category of CAS bugs 
that are syistem independent.
That is, they occur in many systems! Sometimes they depend on secretly dividing 
by zero, or doing something
that is invalid at a singularity. So "Maple and Mathematica and ... all agree" 
does not mean they are right!

I think my essential point previously is that rewriting easy stuff (in a 
different language) typically fails to push the frontier.



On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:



As to the question of replacing backends, there is already a ticket (which I 
cannot find right now, my apologies) which started the process of seeing what 
doctests would fail if we went to Sympy as default. Presumably something 
similar could be done with this engine (I don't know if it is more for 
low-level symbolics or also things like integration).



In particular, the (very minimal) documentation (really an API is all) makes it 
seems more a replacement for things like Ginac (already in C++), not Maxima et 
al. I don't know if that would provide a noticeable speedup per se, though the 
SageManifolds ticket mentioned parallelization so perhaps it is better suited 
for that?


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/879dd941-95a0-4f2f-b5ac-96f60439f80dn%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/53e6e905-27ec-4545-a2ef-bca1eb01029cn%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

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-22 Thread Dima Pasechnik 
On Thu, Jan 21, 2021 at 8:04 PM parisse  wrote:
>
> Well, searching for "lisp infix notation" is not very convincing (unless I 
> missed something?), compared to built-in infix support. You might prefer Lisp 
> to C/C++, it's your choice, but I don't see any objective reason that one 
> should stay away from C/C++. And Giac is a proof that one can actually write 
> a CAS in C/C++, that compares very well with the Lisp-based CAS Maxima.

Maxima is ~40 years old with a bit of work done since then, but the
core is that old, as far as I know:
https://en.wikipedia.org/wiki/Macsyma

As for staying away from C++,  most people who might be trying to do
something with supposedly state of the art library like boost,
would run away screaming, closely followed by 100 screens of error messages :-)
Or, now mostly gone (?), iterator_traits (my closest encounter with
C++, contributing to CGAL, 20 years ago, where these had to be
generated by a script for some classes, otherwise compilers kept
crashing...)





> Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit :
>>
>> On Wed, Jan 20, 2021 at 7:13 PM parisse  wrote:
>> >
>> > As the author of a CAS, I can state that you need much more than 2 weeks 
>> > to learn a programming language to make a CAS, and much much more if you 
>> > want to be fast. Life is short, therefore choose your programming language 
>> > carefully! I don't regret my choice for C (+ C++ STL and operator 
>> > redefinition) made 20 years ago, because C can interact with a lot of 
>> > languages (including compilation to Javascript). If I had to choose today, 
>> > I would perhaps choose Julia. Not Python, it's much too slow. I don't know 
>> > for Lisp speed, but it's not a language I would choose anyway, I like to 
>> > write e.g. a+b*c when I do algebraic computations in my source code.
>>
>> There are macro packages for infix maths in Common Lisp, so this by no
>> means should be a deal-breaker for anyone.
>>
>> Needless to say, C++ has its own can of worms, which anyone who tried
>> to used it might easily produce, as a reason to stay
>> away from it.
>>
>> >
>> > Le mercredi 20 janvier 2021 à 19:47:01 UTC+1, rjf a écrit :
>> >>
>> >> I think you have to figure that there is a difference in productivity of 
>> >> people who just learned Python in high school and would really like to 
>> >> write a computer algebra system
>> >> versus people who know more mathematics, are comfortable spending 2 weeks 
>> >> learning lisp, spending ?? (weeks? months?) studying the state of the art 
>> >> in
>> >> computer algebra systems as evolved over 60 years, and want to contribute 
>> >> to advancing the art (rather than re-programming the easy stuff).
>> >> I am under the impression that learning python is a reasonable stepping 
>> >> stone to learning lisp.
>> >>
>> >> As far as checking results for various systems, there is a category of 
>> >> CAS bugs that are syistem independent.
>> >> That is, they occur in many systems! Sometimes they depend on secretly 
>> >> dividing by zero, or doing something
>> >> that is invalid at a singularity. So "Maple and Mathematica and ... all 
>> >> agree" does not mean they are right!
>> >>
>> >> I think my essential point previously is that rewriting easy stuff (in a 
>> >> different language) typically fails to push the frontier.
>> >>
>> >>
>> >>
>> >> On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:
>> 
>> 
>>  As to the question of replacing backends, there is already a ticket 
>>  (which I cannot find right now, my apologies) which started the process 
>>  of seeing what doctests would fail if we went to Sympy as default. 
>>  Presumably something similar could be done with this engine (I don't 
>>  know if it is more for low-level symbolics or also things like 
>>  integration).
>> >>>
>> >>>
>> >>> In particular, the (very minimal) documentation (really an API is all) 
>> >>> makes it seems more a replacement for things like Ginac (already in 
>> >>> C++), not Maxima et al. I don't know if that would provide a noticeable 
>> >>> speedup per se, though the SageManifolds ticket mentioned 
>> >>> parallelization so perhaps it is better suited for that?
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups 
>> > "sage-devel" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an 
>> > email to sage-devel+...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/sage-devel/879dd941-95a0-4f2f-b5ac-96f60439f80dn%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/53e6e905-27ec-4545-a2ef-bca1eb01029c

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-21 Thread parisse 
Well, searching for "lisp infix notation" is not very convincing (unless I 
missed something?), compared to built-in infix support. You might prefer 
Lisp to C/C++, it's your choice, but I don't see any objective reason that 
one should stay away from C/C++. And Giac is a proof that one can actually 
write a CAS in C/C++, that compares very well with the Lisp-based CAS 
Maxima. 
Le jeudi 21 janvier 2021 à 18:07:14 UTC+1, dim...@gmail.com a écrit :

> On Wed, Jan 20, 2021 at 7:13 PM parisse  
> wrote:
> >
> > As the author of a CAS, I can state that you need much more than 2 weeks 
> to learn a programming language to make a CAS, and much much more if you 
> want to be fast. Life is short, therefore choose your programming language 
> carefully! I don't regret my choice for C (+ C++ STL and operator 
> redefinition) made 20 years ago, because C can interact with a lot of 
> languages (including compilation to Javascript). If I had to choose today, 
> I would perhaps choose Julia. Not Python, it's much too slow. I don't know 
> for Lisp speed, but it's not a language I would choose anyway, I like to 
> write e.g. a+b*c when I do algebraic computations in my source code.
>
> There are macro packages for infix maths in Common Lisp, so this by no
> means should be a deal-breaker for anyone.
>
> Needless to say, C++ has its own can of worms, which anyone who tried
> to used it might easily produce, as a reason to stay
> away from it.
>
> >
> > Le mercredi 20 janvier 2021 à 19:47:01 UTC+1, rjf a écrit :
> >>
> >> I think you have to figure that there is a difference in productivity 
> of people who just learned Python in high school and would really like to 
> write a computer algebra system
> >> versus people who know more mathematics, are comfortable spending 2 
> weeks learning lisp, spending ?? (weeks? months?) studying the state of the 
> art in
> >> computer algebra systems as evolved over 60 years, and want to 
> contribute to advancing the art (rather than re-programming the easy stuff).
> >> I am under the impression that learning python is a reasonable stepping 
> stone to learning lisp.
> >>
> >> As far as checking results for various systems, there is a category of 
> CAS bugs that are syistem independent.
> >> That is, they occur in many systems! Sometimes they depend on secretly 
> dividing by zero, or doing something
> >> that is invalid at a singularity. So "Maple and Mathematica and ... all 
> agree" does not mean they are right!
> >>
> >> I think my essential point previously is that rewriting easy stuff (in 
> a different language) typically fails to push the frontier.
> >>
> >>
> >>
> >> On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:
> 
> 
>  As to the question of replacing backends, there is already a ticket 
> (which I cannot find right now, my apologies) which started the process of 
> seeing what doctests would fail if we went to Sympy as default. Presumably 
> something similar could be done with this engine (I don't know if it is 
> more for low-level symbolics or also things like integration).
> >>>
> >>>
> >>> In particular, the (very minimal) documentation (really an API is all) 
> makes it seems more a replacement for things like Ginac (already in C++), 
> not Maxima et al. I don't know if that would provide a noticeable speedup 
> per se, though the SageManifolds ticket mentioned parallelization so 
> perhaps it is better suited for that?
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/879dd941-95a0-4f2f-b5ac-96f60439f80dn%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/53e6e905-27ec-4545-a2ef-bca1eb01029cn%40googlegroups.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-21 Thread Dima Pasechnik 
On Wed, Jan 20, 2021 at 7:13 PM parisse  wrote:
>
> As the author of a CAS, I can state that you need much more than 2 weeks to 
> learn a programming language to make a CAS, and much much more if you want to 
> be fast. Life is short, therefore choose your programming language carefully! 
> I don't regret my choice for C (+ C++ STL and operator redefinition) made 20 
> years ago, because C can interact with a lot of languages (including 
> compilation to Javascript). If I had to choose today, I would perhaps choose 
> Julia. Not Python, it's much too slow. I don't know for Lisp speed, but it's 
> not a language I would choose anyway, I like to write e.g. a+b*c when I do 
> algebraic computations in my source code.

There are macro packages for infix maths in Common Lisp, so this by no
means should be a deal-breaker for anyone.

Needless to say, C++ has its own can of worms, which anyone who tried
to used it might easily produce, as a reason to stay
away from it.

>
> Le mercredi 20 janvier 2021 à 19:47:01 UTC+1, rjf a écrit :
>>
>> I think you have to figure that there is a difference in productivity of 
>> people who just learned Python in high school and would really like to write 
>> a computer algebra system
>> versus people who know more mathematics, are comfortable spending 2 weeks 
>> learning lisp, spending ?? (weeks? months?) studying the state of the art in
>> computer algebra systems as evolved over 60 years, and want to contribute to 
>> advancing the art (rather than re-programming the easy stuff).
>>  I am under the impression that learning python is a reasonable stepping 
>> stone to learning lisp.
>>
>> As far as checking results for various systems,  there is a category of CAS 
>> bugs that are syistem independent.
>> That is, they occur in many systems!  Sometimes they depend on secretly 
>> dividing by zero, or doing something
>> that is invalid at a singularity.  So "Maple and Mathematica and ...  all 
>> agree" does not mean they are right!
>>
>> I think my essential point previously is that rewriting easy stuff (in a 
>> different language) typically fails to push the frontier.
>>
>>
>>
>> On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:


 As to the question of replacing backends, there is already a ticket (which 
 I cannot find right now, my apologies) which started the process of seeing 
 what doctests would fail if we went to Sympy as default.  Presumably 
 something similar could be done with this engine (I don't know if it is 
 more for low-level symbolics or also things like integration).
>>>
>>>
>>> In particular, the (very minimal) documentation (really an API is all) 
>>> makes it seems more a replacement for things like Ginac (already in C++), 
>>> not Maxima et al.  I don't know if that would provide a noticeable speedup 
>>> per se, though the SageManifolds ticket mentioned parallelization so 
>>> perhaps it is better suited for that?
>
> --
> 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/879dd941-95a0-4f2f-b5ac-96f60439f80dn%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/CAAWYfq1yVs_ieJj10Ym6%2B6hfpo1LC_xpSXH93aNaw%2BtYkGA2qA%40mail.gmail.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-21 Thread kcrisman 


> I think you have to figure that there is a difference in productivity of 
> people who just learned Python in high school and would really like to 
> write a computer algebra system


I'm not referring to that, obviously.

-- 
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/9925ef06-6f7c-457e-952e-db7d2aef6a5en%40googlegroups.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-20 Thread parisse 
As the author of a CAS, I can state that you need much more than 2 weeks to 
learn a programming language to make a CAS, and much much more if you want 
to be fast. Life is short, therefore choose your programming language 
carefully! I don't regret my choice for C (+ C++ STL and operator 
redefinition) made 20 years ago, because C can interact with a lot of 
languages (including compilation to Javascript). If I had to choose today, 
I would perhaps choose Julia. Not Python, it's much too slow. I don't know 
for Lisp speed, but it's not a language I would choose anyway, I like to 
write e.g. a+b*c when I do algebraic computations in my source code.

Le mercredi 20 janvier 2021 à 19:47:01 UTC+1, rjf a écrit :

> I think you have to figure that there is a difference in productivity of 
> people who just learned Python in high school and would really like to 
> write a computer algebra system
> versus people who know more mathematics, are comfortable spending 2 weeks 
> learning lisp, spending ?? (weeks? months?) studying the state of the art in
> computer algebra systems as evolved over 60 years, and want to contribute 
> to advancing the art (rather than re-programming the easy stuff). 
>  I am under the impression that learning python is a reasonable stepping 
> stone to learning lisp.
>
> As far as checking results for various systems,  there is a category of 
> CAS bugs that are syistem independent.
> That is, they occur in many systems!  Sometimes they depend on secretly 
> dividing by zero, or doing something
> that is invalid at a singularity.  So "Maple and Mathematica and ...  all 
> agree" does not mean they are right!
>
> I think my essential point previously is that rewriting easy stuff (in a 
> different language) typically fails to push the frontier.
>
>
>
> On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:
>
>>
>>> As to the question of replacing backends, there is already a ticket 
>>> (which I cannot find right now, my apologies) which started the process of 
>>> seeing what doctests would fail if we went to Sympy as default.  Presumably 
>>> something similar could be done with this engine (I don't know if it is 
>>> more for low-level symbolics or also things like integration).  
>>>
>>
>> In particular, the (very minimal) documentation (really an API is all) 
>> makes it seems more a replacement for things like Ginac (already in C++), 
>> not Maxima et al.  I don't know if that would provide a noticeable speedup 
>> per se, though the SageManifolds ticket mentioned parallelization so 
>> perhaps it is better suited for that?
>>
>

-- 
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/879dd941-95a0-4f2f-b5ac-96f60439f80dn%40googlegroups.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-20 Thread rjf 
I think you have to figure that there is a difference in productivity of 
people who just learned Python in high school and would really like to 
write a computer algebra system
versus people who know more mathematics, are comfortable spending 2 weeks 
learning lisp, spending ?? (weeks? months?) studying the state of the art in
computer algebra systems as evolved over 60 years, and want to contribute 
to advancing the art (rather than re-programming the easy stuff). 
 I am under the impression that learning python is a reasonable stepping 
stone to learning lisp.

As far as checking results for various systems,  there is a category of CAS 
bugs that are syistem independent.
That is, they occur in many systems!  Sometimes they depend on secretly 
dividing by zero, or doing something
that is invalid at a singularity.  So "Maple and Mathematica and ...  all 
agree" does not mean they are right!

I think my essential point previously is that rewriting easy stuff (in a 
different language) typically fails to push the frontier.



On Wednesday, January 20, 2021 at 5:54:51 AM UTC-8 kcrisman wrote:

>
>> As to the question of replacing backends, there is already a ticket 
>> (which I cannot find right now, my apologies) which started the process of 
>> seeing what doctests would fail if we went to Sympy as default.  Presumably 
>> something similar could be done with this engine (I don't know if it is 
>> more for low-level symbolics or also things like integration).  
>>
>
> In particular, the (very minimal) documentation (really an API is all) 
> makes it seems more a replacement for things like Ginac (already in C++), 
> not Maxima et al.  I don't know if that would provide a noticeable speedup 
> per se, though the SageManifolds ticket mentioned parallelization so 
> perhaps it is better suited for that?
>

-- 
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/e326838b-4599-4a1f-b16c-67b37e2442f0n%40googlegroups.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-20 Thread kcrisman 


>
> As to the question of replacing backends, there is already a ticket (which 
> I cannot find right now, my apologies) which started the process of seeing 
> what doctests would fail if we went to Sympy as default.  Presumably 
> something similar could be done with this engine (I don't know if it is 
> more for low-level symbolics or also things like integration).  
>

In particular, the (very minimal) documentation (really an API is all) 
makes it seems more a replacement for things like Ginac (already in C++), 
not Maxima et al.  I don't know if that would provide a noticeable speedup 
per se, though the SageManifolds ticket mentioned parallelization so 
perhaps it is better suited for that?

-- 
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/9fcfa938-687b-41dd-8db9-96acad2e9141n%40googlegroups.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-20 Thread kcrisman 


> Just a suggestion:  if you want to improve the speed of symbolic 
>> mathematics as done by Maxima, and you are no longer insisting on the use 
>> of Python, why not write in Lisp, and make Maxima faster?
>
>
> oh well - anyway,  it is fun to watch C/C++ programmers discovering the 
> wrath of 
> https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule
>
>>
>>
More seriously perhaps, "Python wrappers allow easy usage from Python and 
integration with SymPy  and Sage 
 (the symengine.py 
 repository)" which probably is 
not the case even with our use of Maxima as library.

As for the substance of Richard's remark, the truth is that at least to 
some extent one has to go with supply, not just demand:

https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/

and while I'm not sure that "HTML/CSS" is Turing-complete, at any rate if 
this graphic is even remotely accurate there simply aren't enough people 
who know Lisp (or even Scheme or Clojure or ...) well to focus on it within 
a scientific ecosystem already dominated by things like Python and R.  That 
is too bad, because if we had had that competence early in the project, I 
could have imagined a lot of energy on improving Maxima; but time 
considerations have to be part of it too, not just technical considerations 
of which language is "best". 

As to the question of replacing backends, there is already a ticket (which 
I cannot find right now, my apologies) which started the process of seeing 
what doctests would fail if we went to Sympy as default.  Presumably 
something similar could be done with this engine (I don't know if it is 
more for low-level symbolics or also things like integration).  However, 
one of the strengths of Sage is that one can check computations using 
several backends at a time, including with optional things like fricas 
(still?), and likely Maxima will still prove to be better at certain kinds 
of computations, so improving Maxima will still help Sage's capabilities no 
matter what happens.

-- 
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/948f5e87-8de2-4003-b85b-baf0f33c4439n%40googlegroups.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-20 Thread Dima Pasechnik 
On Wed, 20 Jan 2021, 01:06 rjf,  wrote:

> Just a suggestion:  if you want to improve the speed of symbolic
> mathematics as done by Maxima, and you are no longer insisting on the use
> of Python, why not write in Lisp, and make Maxima faster?


oh well - anyway,  it is fun to watch C/C++ programmers discovering the
wrath of
https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule


>
> On Monday, January 18, 2021 at 6:58:10 AM UTC-8 dim...@gmail.com wrote:
>
>>
>>
>> On Mon, 18 Jan 2021, 14:56 Siddharth Bhat,  wrote:
>>
>>> @vincent:  I'm very new to sage-devel. As best as I can tell, the patch
>>> has stalled? Can/should someone else pick it up?
>>>
>>
>> a patch to arb needed there has stalled
>> for some reason.
>>
>>
>>>
>>>
>>> On Mon, 18 Jan 2021, 20:24 Dima Pasechnik,  wrote:
>>>
 Interesting! Is there documentation about its capabilities?

 On Mon, 18 Jan 2021, 13:40 Siddharth Bhat,  wrote:

> The SymPy project has another project called SymEngine
> , which aims to be a fast
> symbolic manipulation library. Perhaps we should move to use SymEngine as
> well, since it should be faster as it is native C++ code.
>
>
> This discussion came up during a discussion on improving the
> performance of SageManifolds
> .
>
> --
> You received this message because you are subscribed to the Google
> Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/88614da3-02a0-4b24-8876-cd3908c6018cn%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+...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/sage-devel/CAAWYfq0mN6GqSCFSQXOkLxC0XhkbJM9X7fgPHR_p0CGayDYrqw%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+...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sage-devel/CAPipc%3D0tKndG4QBNywLknEmMHOSJOAuZPHVXwgwPCopZ%3D989jg%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/2a0eecfb-2f95-43ae-80c6-623396c340bfn%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/CAAWYfq1Y_sZCZd7AKR6SkHJRvJvdhdSRVHV1Zghi_UuqU4m8Sg%40mail.gmail.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-19 Thread rjf 
Just a suggestion:  if you want to improve the speed of symbolic 
mathematics as done by Maxima, and you are no longer insisting on the use 
of Python, why not write in Lisp, and make Maxima faster?


On Monday, January 18, 2021 at 6:58:10 AM UTC-8 dim...@gmail.com wrote:

>
>
> On Mon, 18 Jan 2021, 14:56 Siddharth Bhat,  wrote:
>
>> @vincent:  I'm very new to sage-devel. As best as I can tell, the patch 
>> has stalled? Can/should someone else pick it up? 
>>
>
> a patch to arb needed there has stalled
> for some reason.
>
>
>>
>>
>> On Mon, 18 Jan 2021, 20:24 Dima Pasechnik,  wrote:
>>
>>> Interesting! Is there documentation about its capabilities?
>>>
>>> On Mon, 18 Jan 2021, 13:40 Siddharth Bhat,  wrote:
>>>
 The SymPy project has another project called SymEngine 
 , which aims to be a fast 
 symbolic manipulation library. Perhaps we should move to use SymEngine as 
 well, since it should be faster as it is native C++ code.


 This discussion came up during a discussion on improving the 
 performance of SageManifolds 
 . 

 -- 
 You received this message because you are subscribed to the Google 
 Groups "sage-devel" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to sage-devel+...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/88614da3-02a0-4b24-8876-cd3908c6018cn%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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/CAAWYfq0mN6GqSCFSQXOkLxC0XhkbJM9X7fgPHR_p0CGayDYrqw%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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/CAPipc%3D0tKndG4QBNywLknEmMHOSJOAuZPHVXwgwPCopZ%3D989jg%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/2a0eecfb-2f95-43ae-80c6-623396c340bfn%40googlegroups.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-18 Thread Dima Pasechnik 
On Mon, 18 Jan 2021, 14:56 Siddharth Bhat,  wrote:

> @vincent:  I'm very new to sage-devel. As best as I can tell, the patch
> has stalled? Can/should someone else pick it up?
>

a patch to arb needed there has stalled
for some reason.


>
>
> On Mon, 18 Jan 2021, 20:24 Dima Pasechnik,  wrote:
>
>> Interesting! Is there documentation about its capabilities?
>>
>> On Mon, 18 Jan 2021, 13:40 Siddharth Bhat,  wrote:
>>
>>> The SymPy project has another project called SymEngine
>>> , which aims to be a fast
>>> symbolic manipulation library. Perhaps we should move to use SymEngine as
>>> well, since it should be faster as it is native C++ code.
>>>
>>>
>>> This discussion came up during a discussion on improving the
>>> performance of SageManifolds
>>> .
>>>
>>> --
>>> 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/88614da3-02a0-4b24-8876-cd3908c6018cn%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/CAAWYfq0mN6GqSCFSQXOkLxC0XhkbJM9X7fgPHR_p0CGayDYrqw%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/CAPipc%3D0tKndG4QBNywLknEmMHOSJOAuZPHVXwgwPCopZ%3D989jg%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/CAAWYfq0GEhJVYB%2BVDVbYUaKNj_R43Tm-dUvFk3-2noTzR%3D_TiA%40mail.gmail.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-18 Thread Siddharth Bhat 
@vincent:  I'm very new to sage-devel. As best as I can tell, the patch has
stalled? Can/should someone else pick it up?



On Mon, 18 Jan 2021, 20:24 Dima Pasechnik,  wrote:

> Interesting! Is there documentation about its capabilities?
>
> On Mon, 18 Jan 2021, 13:40 Siddharth Bhat,  wrote:
>
>> The SymPy project has another project called SymEngine
>> , which aims to be a fast
>> symbolic manipulation library. Perhaps we should move to use SymEngine as
>> well, since it should be faster as it is native C++ code.
>>
>>
>> This discussion came up during a discussion on improving the performance
>> of SageManifolds .
>>
>> --
>> 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/88614da3-02a0-4b24-8876-cd3908c6018cn%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/CAAWYfq0mN6GqSCFSQXOkLxC0XhkbJM9X7fgPHR_p0CGayDYrqw%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/CAPipc%3D0tKndG4QBNywLknEmMHOSJOAuZPHVXwgwPCopZ%3D989jg%40mail.gmail.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-18 Thread Dima Pasechnik 
Interesting! Is there documentation about its capabilities?

On Mon, 18 Jan 2021, 13:40 Siddharth Bhat,  wrote:

> The SymPy project has another project called SymEngine
> , which aims to be a fast
> symbolic manipulation library. Perhaps we should move to use SymEngine as
> well, since it should be faster as it is native C++ code.
>
>
> This discussion came up during a discussion on improving the performance
> of SageManifolds .
>
> --
> 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/88614da3-02a0-4b24-8876-cd3908c6018cn%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/CAAWYfq0mN6GqSCFSQXOkLxC0XhkbJM9X7fgPHR_p0CGayDYrqw%40mail.gmail.com.

Re: [sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-18 Thread Vincent Delecroix 

See https://trac.sagemath.org/ticket/29497

Le 18/01/2021 à 14:40, Siddharth Bhat a écrit :

The SymPy project has another project called SymEngine
, which aims to be a fast symbolic
manipulation library. Perhaps we should move to use SymEngine as well,
since it should be faster as it is native C++ code.


This discussion came up during a discussion on improving the performance
of SageManifolds .



--
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/da6165b8-fdc6-9477-123a-d8401dc9036c%40gmail.com.

[sage-devel] Use SymEngine as a symbolic mathematics backend for SAGE

2021-01-18 Thread Siddharth Bhat 
The SymPy project has another project called SymEngine 
, which aims to be a fast symbolic 
manipulation library. Perhaps we should move to use SymEngine as well, 
since it should be faster as it is native C++ code.


This discussion came up during a discussion on improving the performance 
of SageManifolds . 

-- 
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/88614da3-02a0-4b24-8876-cd3908c6018cn%40googlegroups.com.