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/CAAWYfq1b7MX6rjbTnLNwJWSM0ymi9Nb6p-1r1_kq0QSy_e%2BcSw%40mail.gmail.com.
