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/a2877aca-96f6-457f-8e4e-1172c82e9463n%40googlegroups.com.
