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.
