Author: Tord Romstad
Date: 15:06:17 01/22/04
Go up one level in this thread
On January 22, 2004 at 13:05:57, Steven Edwards wrote:
>On January 22, 2004 at 11:52:47, Tord Romstad wrote:
>>On January 22, 2004 at 10:03:55, Steven Edwards wrote:
>>
>>>Here's some example code for the ChessLisp intepreter in my program Symbolic:
>>>
>>>;;;; emp.lsp: Enumerate movepaths
>>>
>>>(defun emp (theFEN theDepth)
>>> "Enumerate distinct movepaths from a FEN string to a depth"
>>> (cond
>>> ((not (string? theFEN))
>>> "Error: first argument must be a FEN string")
>>> ((not (and (integer? theDepth) (nonnegative? theDepth)))
>>> "Error: second argument must be a nonnegative integer")
>>> (t
>>> (let ((thePos (PosFromFEN theFEN)))
>>> (if (null? thePos)
>>> "Error: invalid position"
>>> (emp-aux thePos theDepth))))))
>>>
>>>(defun emp-aux (thePos theDepth)
>>> "Enumerate distinct movepaths from a position to a depth"
>>> (cond
>>> ((= theDepth 0) 1)
>>> ((= theDepth 1) (length (Generate thePos)))
>>> (t
>>> (let ((theSum 0) (theEnv nil) (theMove nil) (theML (Generate thePos)))
>>> (dolist (theMove theML)
>>> (Execute theMove thePos theEnv)
>>> (incf theSum (emp-aux thePos (1- theDepth)))
>>> (Retract theMove thePos theEnv))
>>> theSum))))
>>
>>From the code above, it looks like you generate moves into a list rather
>>than an array. Isn't this terribly slow? And another question: What
>>is the purpose of the (theMove nil) in the LET bindings of the EMP-AUX
>>function? Is this necessary because of some quirk in your Lisp dialect?
>
>1. Generating moves into a list is done by the C++ routines and is quite fast.
>Also, a list representation of moves enables writing a tail recursive verion of
>the abve routine if needed. I can always write a GenerateArray intrinsic if the
>need arises.
>
>I have not made any attempts to optimize the interpreter speed except for
>consing and garbage collecting (these it does quite quickly). Creating a new
>lexical closure at the present requires a call to the C++ new() routine, so this
>will be a target for optimization aftter I do more work on implementing the
>remainder of the function intrinsics.
Using dynamic memory for any of the central data structures in a chess program
seems inefficient and unnecessary to me, but I guess you have good reasons to
do so.
>2. Adding the binding for theMove (and also theEnv) in the let variable list is
>a stylism of mine and not strictly necessary.
But unless your Lisp dialect is very different from Common Lisp, the "theMove"
inside your DOLIST loop is not the same as the "theMove" in the LET form around
it. In your code, you just initialize a lexical variable named "theMove", and
never
use that variable for anything.
Consider this piece of Common Lisp code:
(let ((x 0))
(dolist (x '(1 2 3))
(print x))
x))
The return value is 0, not 1. The x in the DOLIST form is not the same as the x
in the LET form.
>>Otherwise, the code looks straighforward and clean. I personally detest
>>the convention of using question marks to denote predicates, but that's
>>of course a matter of taste.
>
>Most predicates in my ChessLisp come in -p and -? forms. The former are used
>when porting Common Lisp routines for testing and the latter are my preference
>for coding.
The main reason I don't like this use of question marks is that the question
mark
is so useful as a macro character.
>One of the planned features of the system is the ability to answer natural
>language questions about its chess environment much like Winograd's Blocks
>World. I have even included a speak intrinsic function for voice synthesis.
>The idea is that the program can explain, in real time, its search process. For
>even better debugging, a "movie" (QuickTime, perhaps) with text/voice and chess
>position diagrams can be be constructed during a search and then replayed
>afterwards.
Sounds really cool. Keep working! :-)
>There is still a long road to be travelled. In fact, the further I go on the
>road, the longer it seems to be!
Yeah, I know the feeling.
>It could be months before I get to the point
>of actually writing the highest level analysis and planning code. As to the
>strength of the final system, well, that remains to be seen. But one thing is
>sure: the result is not going to be a just another big tree a/b search program.
Good luck! I hope you succeed.
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.