On Friday, November 28, 2014 9:25:01 PM UTC-8, Joachim Durchholz wrote: > > Am 29.11.2014 um 02:44 schrieb Richard Fateman: > > > > > > On Thursday, November 27, 2014 10:35:34 PM UTC-8, Joachim Durchholz > wrote: > >> > >> Awesome. > >>> The papers I've read have been almost exclusively from the theorem > >> proving > >>> world. > >> > >> I think you should be mostly fine working off these. > > > > I disagree, unless you are able to find much better papers than I have > seen. > > Well, maybe not "just fine", but simply picking up Lisp code isn't going > to work *that* well (and would be quite pointless), so what alternatives > would be there? > > >> Essentially it's all tree matching of some kind. Things will start to > >> diverge as soon as domain specifics start to matter; it would be nice > to > >> have a not too domain-specific basic building block and add the various > >> strategies on top of that. > > > > I think the "various strategies" are very important, and not just > add-ons. > > Of course they are important. > It would still be nice to be able to use different strategies, depending > on what the particular algorithm tries to do, and on experiences with > speed and maintainability of Python code. > > > There is a pattern matching program in Peter Norvig's book on Artificial > > Intelligence Programming ; this book will also teach you Lisp. > > I agree that learning Lisp is a good idea. I'd recommend complementing > that with Haskell (e.g. "The Haskell School of Expression", though it's > a bit superficial), and http://www.info.ucl.ac.be/~pvr/book.html to see > what else is out there. > > However, that's about learning programming. Which is a good thing to do > in general, but it does not really help with designing Python classes > for SymPy. >
Sorry to be argumentative, but Norvig's book is teaching about how one can go about solving certain problems common in "symbolic" artificial intelligence, and that is relevant in any language. The book probably shows you how some of these ideas are more neatly encapsulated in Lisp than some other languages, but Python should not be so far off in terms of complexity of code and expressiveness. (Exceptions -- I don't know -- maybe the occasional use of first-class functions, or the tiny use of macros for essentially abbreviating code segments. ) > > For that, firstly, you'd need to understand what exactly each design > decision in Peter's (or anybody else's) code was intended to achieve. I think the book is pretty clear about that. > > For that, merely learning Lisp is not enough, you need to have mastered > it - which is a few years of experience away for most of us (except for > you, I assume, and maybe the odd one or two lurkers on this list). > You do not need to master Lisp at the expense of years. I have taught undergrad classes where students get up to the level of Lisp in Norvig's book after 3 assignments (writing pieces of a compiler for a language like Java-- ). > > Second, you need to understand all about how to design the equivalents > in Python, dropping those design patterns that don't work in Python, and > replacing them with something that works as well. This is unconvincing to me. Norvig has written a cheat sheet for Lisp <--> Python. > (For example, > everything macro would have to be replaced or redone; is there anything > relevant left if you take out macros in the useful Lisp work?) This is a boogie-man often thrown up as a barrier to understanding Lisp. It isn't. 1. Macros are generally rare and easy to understand. 2. If they are not, it is probably a crappy unnecessary use of macros, written by a naive programmer. 3. Look at Norvig's book and see how often he uses macros. Rarely. And see how long they are. (2 lines?) > So you > need to be a Python master as well. Given your record I doubt that you > are, I certainly am not, and those people around here that I'd consider > Python masters, I doubt that any of them is also a Lisp master. > I am definitely not a Python master. > > Third, the resulting code needs to be maintainable by people who do not > know anything about Lisp, and barely enough of Python to become a GSoC > student. > This is a real problem. If you have unskilled and unknowledgeable personnel "maintaining" a code base, that's a tragedy in the works. It means that someone who is skilled and knowledgeable will have to go over the code and fix it. > I have serious doubts that Lisp style is going to work for that, at all, > even if you let a Lisp And Python Master do the translation. > I think that Lisp style is highly variable, and that someone used to writing in Python, writes Python-Lisp, etc etc. Can someone take Lisp and rewrite in Python "automatically"? I think it depends on the proclivities of the original programmer. You (and others) seem to think that Lisp programmers always use macros and so it can't be done. But you are wrong in that belief. I suppose I could write programs that are challenging to understand and to translate; I understand Python is lacking functional objects with more than one argument; I could write stuff relying on multiprocessing which presumably would differ. But that's not run-of-the-mill. > So right now, my point of view is that trying to get that (doubtlessly > very valuable) Lisp experience into SymPy, while it could do all kinds > of good, is probably not practically possible. > All I can say is, try to read Norvig's book. My sincere belief is that even if you never write a single line of Lisp, it will improve your programming in Python, because you will think about problems (like pattern matching) more clearly. > Unless somebody can delineate a clear path to overcame the various > obstacles I just enumerated. > > > I highly recommend it. In fact, I would go further than that, and say > > that I would expect you to re-invent much of what he writes out, > > or alternatively, have a severely deficient program. > > Sure, but if his book makes you learn Lisp, the presentation is heavily > biased towards Lisp, and much of what he writes won't be transferrable. > Totally disagree. > > My recommendation would be to reinvent first (and discover how the > Python patterns for that particular field work), then read the Lisp > equivalents, then transfuse the ideas. > The point being that once enough experience with the Python patterns is > available, it's easier to see what to transfer and what to better leave > untransferred. > > There is an old saying, 2 weeks in the computer lab can save 1 hour in the library. RJF > YMMV :-) > > Regards, > Jo > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/d27db8e2-fdfc-48bc-bfdd-5cabf161942f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
