On Sunday, January 24, 2021 at 9:17:14 PM UTC rjf wrote:
> Just a note to point out that infix like a+b*c in a conventional > programming language > is not helpful if a,b,c are symbolic expressions.. Writing it as add(a, > mul(b,c)) is not > a big deal, nor is writing it in lisp (add a (mul b c)). Of course you > need to write programs > add and mul, but you have to do that regardless. Languages that are > primarily oriented > to provide arithmetic on fixed-length integers or double-float numbers, > mostly have to be > covered over by macros etc to do computer algebra. Languages like > FORTRAN, Algol, C. > > You could look at RLISP used for Reduce, if you want to see a version of > lisp with "syntactic sugar" > to look "infix" ish. And that is used for a computer algebra system, > Reduce. > > There is something of a tradition, to hand to someone, perhaps someone > who prefers infix, a project to "Write a scanner/parser/code generator > for an infix language > of your design [ or pick one, say Pascal]" in Lisp. > I've done this with programming language/compiler > undergraduate classes at Berkeley for decades, with probably thousands of > students. > It takes 10 weeks, assuming you know no lisp, nothing about lexical > analysis, > nothing about parsing, nothing about intermediate code generation. and > maybe > nothing about Pascal. > > At the completion of the project, most students prefer Lisp's > parenthesized prefix. > They also understand Pascal better, having written an interpreter and > compiler for it. > Mind you, the initial versions of an alive and kicking computational group theory system GAP was mostly written by maths students in RWTH Aachen 25-30 years ago. One could ask why human-years of relatively good quality LISP coders coding time were wasted doing the same lab projects, and not something more creative, like impoving Maxima code. :P LISP enthousiasts, including many US academics, have mostly themselves to blame for the present sorry state of computer algebra in LISP... > > Often they choose to use Lisp for other projects, given a choice. > > Most criticisms of Lisp come from people who have never used it, and it > shows. > Complaints about too many parentheses. No, there are just exactly enough, > and > your editor helps. Or indentation (hi Pythonistas). Editors indent for > you, exactly right. > Not webby enough (see cl-http or other packages). > Too slow (uh, faster than Python, some excellent optimizing compilers for > Lisp). > Too hard to learn. Think about how much time you spent in learning your > current > favorite language on the precedence of operators. Or what the operators > meant. > Or what happens when integers "overflow". > > Consider learning Lisp. > > > > Parts of Macsyma/Maxima are more like 60 years old. Almost as old as Lisp > (circa 1959). > James Slagle's 1961 PhD on symbolic integration (SAI'NT) includes a > substantial section explaining Lisp, > which was quite new at the time . > > > On Friday, January 22, 2021 at 11:36:06 AM UTC-8 parisse wrote: > >> 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/851ed249-0d77-4fb9-bf28-e785683b2787n%40googlegroups.com.
