On Wed, Jan 20, 2021 at 7:13 PM parisse <bernard.pari...@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+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.
