Lisp chess

[smcracraft]

Hi Steven and all,

Just a fast survey to see how chess in Lisp
is doing... e.g. strengthwise.

Any rating results to show for Lisp chess
programs on the standard IQ test or
other chess tests would be great.

Also, if any sample codes are available
to full Lisp chess programs, that would
be of interest (to me and others.)

We promise not to sell it.



Stuart

[sje]

Gosh, I haven't touched the old Chess In Lisp source in years. Actually, it may be that the only copy I have is from some Linux distribution.

CIL really wasn't much more than a test project to see how much I squeeze onto my old 1986 Macintosh Plus using the outrageously expensive Franz Lisp package.

[smcracraft]

Do you believe it is feasible (or perhaps you already
did this) to design a reasonably strong (>=2200 ELO)
chess program entirely in Lisp? Was that CIL?

[sje]

Since Lisp can emulate just about any other programing language and the emulation cost is usually under a factor of ten measured in time requirements, then it's obvious that Lisp can be used to build a strong player with reasonable hardware and a traditional algorithm.

But that's not the point. The idea is to use techniques that are better implemented in Lisp than in any other programming language. Wilkins did this nearly thirty years ago with his Paradise problem solver. I'm working on Symbolic's Lisp search today. Few, if any, others have worked on this mostly because of the lack of decent Lisp instruction and tools along with a need for quick gratification better supplied by C++ and the like.

[smcracraft]

What did your alpha-beta searcher look like in Lisp?

Anything unusual about your program as compared to
any equivalent non-Lisp program in terms of
data structures or higher-level functions (planning,
explaining itself, etc.)?

More importantly, was your program competitive
(and how did it do on standard problem suites
and against known opponents?)

Stuart

[sje]

Symbolic's cognitive search is not an AB search.

More details will have to wait until further progress is made.

[smcracraft]

No problem.

I wonder how much one gives up in speed
for the simple fact of it being a Lisp interpretation.

It never struck me as the most efficient language.

Although Winston and Horn deny this, I am not
too sure that on the same hardware, a simple C
program wouldn't trounce the equivalent algorithm
implement in Lisp, despite whatever that algorithm
might be..... chess, cryptography, anything similarly
compute intensive.

Stuart

[sje]

I wonder how much one gives up in speed
for the simple fact of it being a C interpretation.

It never struck me as the most efficient language.

Although Brian Kernighan and Dennis Ritchie deny this, I am not
too sure that on the same hardware, a simple assembly language
program wouldn't trounce the equivalent algorithm
implemented in C, despite whatever that algorithm
might be..... chess, cryptography, anything similarly
compute intensive.

[Dann Corbit]

I wonder how much one gives up in speed
for the simple fact of it being a C interpretation.

It never struck me as the most efficient language.

Although Brian Kernighan and Dennis Ritchie deny this, I am not
too sure that on the same hardware, a simple assembly language
program wouldn't trounce the equivalent algorithm
implemented in C, despite whatever that algorithm
might be..... chess, cryptography, anything similarly
compute intensive.

I guess that for 999 out of 1000 assembly programmers, the C compiler does a better job of optimizing the algorithm instructions into assembly than the assembly programmer would. Take some simple algorithm like some bitboard operations or an insertion sort loop and compile it at the highest optimization settings with assembly generation. You will be amazed at the clever things that optimizing compilers will do now to generate excellent assembly language.

C is close enough to the hardware that for the most part, it is just a portable assembler anyway. And the real benefit of C is that when the instruction set changes, the algorithm will instantly be translated into the new instruction set. I think it is a big mistake to code an entire chess program in assembly (though little bits of it are fine). I have written plenty of assembly and most of it is useless now, because registers are no longer 16 bits wide (I wrote most of my assembly in the early 1980's).

MOV AX,[BP+08]

would now be:

MOV EAX,[EBP+08]

and soon we would be doing stuff like:

MOV RAX,1122334455667788H

So what would become of our megabytes of old assembly code?
Even having said all that, there is clearly a time and a place to slap in a little assembly here and there. For those few little hot spots that need a touch of grease.