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 <bernard.pari...@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+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 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/0ade5c79-7f0c-05d0-63de-4f142dd81a2a%40math.univ-lyon1.fr.
