Author: David Hanley
Date: 14:46:25 12/11/01
Go up one level in this thread
Ok, here's an example you'll probably like better.
The way i have the oopening book setup is it's a tree of book nodes:
(defstruct book-node
score
mac)
Since structures in lisp all have a textual representation, loading it is easy.
(defun load-book()
(setf *book*
(with-open-file (bookfile "book.dat")
(read bookfile))))
That works by itself. Writing is just was easy; change the read to a print.
needless to say writing the above wasn't a whole lot of work.
Now, that works even if there's cycles in the opening book(graph). That can
happen, because the opening book adds moves the player plays before move 20 so
it can learn. Throw a few backup moves (drawish threefold repitition) in there
and you have a cycle. That's not a flukey situation; there's a repitition draw
in the ruy lopez that a few people have used to draw karpov, for example.
The cycles issue is also interesting from the memory management perspective,
because if i'm editing the book and i snip out a cycle, you pretty much need a
GC to handle that.
I'm trying to say that you assertion that
"Using the STL, one can achieve very short and
easy-to-maintain programs rivaling those of the languages you mention, but
already outperforming them in speed. Then later, if the need arises, the
performance-intensive parts can be rewritten. In other words, prototyping can as
easily be done in C++ as it can in, say, SML."
I'd like to see your code that does what the above snippet from my chess program
does with similar prototyping ease ( about 2 minutes ) that's as simple and
clear.
dave
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.