Author: Tord Romstad
Date: 03:38:39 04/17/03
Go up one level in this thread
On April 15, 2003 at 21:33:07, Russell Reagan wrote: >On April 15, 2003 at 19:55:59, William H Rogers wrote: > >>I remember reading about one written in Lisp a few years ago, but I can not >>point to any reference. It was noted that it was not really suited to the >>task. >>Bill > >Tord Romstad is a professional LISP programmer and computer chess hobbyist, and >has posted to r.g.c.* and CCC in the past. I am still here occasionally. :-) >He had said that he wanted to write a chess program in LISP a while back, and I >wondered if he ever did, so I emailed him. He said that he hadn't, Not yet, but I still hope to do it. I have a bit more time on my hands now than during the last couple of years, and there is some hope that I will find the time to produce a moderately strong Lisp program some time later this year. >and he shared this opinion that LISP probably isn't the language of choice if >you're looking to create a strong program. That was not quite what I intended to say. For a non-bitboard program, I think (Common) Lisp would be an excellent development tool, especially in the initial phases of development. Developing a working prototype of your engine would require a lot less work than developing a similar C engine, and experimenting with different algorithms and data structures would be much less painful than in C. One of the really convenient features of Lisp is the interactive nature of the language, and the fact that you have the compiler available at runtime. There is no need to invoke the tedious edit-compile-run-debug cycle typical of C development. Instead, you can recompile individual functions in the program *while the program is running*, and all changes you make will have instant effect on the running engine. If/when I make a serious attempt to design a Lisp chess program, I will keep numerous Lisp editor and listener windows open beside the chess GUI all the time, and use the editor and listener to interactively recompile parts of the engine source and inspect of modify the values of different variables. Such an environment would be extremely useful when tuning, debugging and experimenting with your engine. The problem when using Lisp is that it is considerably more difficult to make a very fast program. That Lisp is inherently slow is a myth. Highly optimized Lisp code can often run at speeds comparable to C programs. However, optimizing Lisp code is not easy, and requires lots of skill, experience and familiarity with the particular Lisp implementation you are using. Writing *portable*, optimized Lisp code is even harder. For chess programming (and implementation of various cryptographic algorithms) there is also another problem: Most Lisp implementations do not have any built-in high-levels support for 32-bit integers. The fixnum type in a Lisp running on a 32-bit platform typically has only 29--31 bits. This makes it virtually impossible to write an efficient bitboard program in Lisp without writing parts of the program in inline assembly language (which in my experience is easier to do in Lisp than in C, by the way). Despite the problems with optimization, I don't think Lisp is a bad choice for a beginning chess programmer (assuming, of course, that the programmer already knows Lisp. Lisp is a rather big and complicated language which takes time to learn). Premature optimization is a danger to all programmers, and I think chess programmers (at least beginners) tend to make this mistake especially often. It is not a bad idea to have a complete, bug-free, stable and well-tuned prototype of your program before you try to micro-optimize it (which could involve rewriting the entire program in a low-level language like C). If I were serious about chess programming, I would probably do most of my development in Lisp, but produce optimized C versions of my program before important competitions. Tord
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.