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

[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 <bernard...@ujf-grenoble.fr>
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 <bernard...@ujf-grenoble.fr>

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+...@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 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/1e812878-459c-b36b-a954-e7c1c3a429a9%40gmail.com.