need suggestion for callable Chess engine

[rreagan]

You can write a program to communicate with chess engines using either the UCI or Winboard protocol. The significant majority of free chess engines support one of those two protocols (or both).

UCI protocol:
http://www.horizonchess.com/FAQ/Winboar ... y2005.html

Winboard protocol:
http://www.tim-mann.org/xboard/engine-intf.html

You could adjust the level of play in a few ways. The protocols have options to limit the search depth (ex. "only look 4 moves ahead"), or limit the amount of time to search (ex. "only think for 5 seconds").

[mlevin77]

Almost any chess program can play against any other (or another self copy) chess program without human assistance.
IMHO game go is better for current state of AI experiments.

Thanks for the info everyone!! With respect to "Go", same question: can someone provide a link for an API or callable engine for this game?

Mike

[mlevin77]

You can write a program to communicate with chess engines using either the UCI or Winboard protocol. The significant majority of free chess engines support one of those two protocols (or both).

UCI protocol:
http://www.horizonchess.com/FAQ/Winboar ... y2005.html

Winboard protocol:
http://www.tim-mann.org/xboard/engine-intf.html

You could adjust the level of play in a few ways. The protocols have options to limit the search depth (ex. "only look 4 moves ahead"), or limit the amount of time to search (ex. "only think for 5 seconds").

are these deterministic? that is, if two programs play against each other, will they always play the same game or is there an element of pseudorandom choice somewhere in the algorithm?

Mike

[mlevin77]

It depends a lot on which degree of control you want to have over the move quality. Most existing engines only allow quality adjustment through setting the time or limiting the search depth (where 'search depth' might have a meaning that differs from engine to engine).
If that is enough, you could call any WinBoard or UCI engine as an external process, communicating with it through a pipe.
If you want to control details of how the search or evaluation works, you are almost forced to include the engine as a subroutine in your code, and be intimately familiar with its inner workings. That would be very hard, especially if you want to use several different engines.
My own engine micro-Max could be used for this purpose: it consists of only a single subroutine of about 100 lines of C-code, which you can call after setting the nominal number of nodes to search in a global variable (determining the move quality), and copying the position it has to move from to the global board array. It will then find the move it prefers, and perform it on the board, before returning.
The search time (or nr of nodes) is a rather course way to tune the move quality, though: uMax, like most engines, deepens the search iteratively in steps of 1 ply, and once it decides starting an iteration, it does finish it completely. But even if you would alter it to abort an iteration, it would mean it almost always returns the move of the previous iteration. Chess programs only change the preferred move rarely, as search time progresses. Most of the time even the next iteration produces the same move. A more continuous way to lower the move quality would be to add a random value of adjustable magnitude to the score of each root move, before picking the best.

am I wrong in thinking that before picking a move, the program makes a list of several moves and ranks them according to how good they are? If so, isn't this the idea place to control quality - make it sometimes pick a move that isn't at the top of the list?

Mike

[rreagan]

are these deterministic? that is, if two programs play against each other, will they always play the same game or is there an element of pseudorandom choice somewhere in the algorithm?

Mike

It will be different for each program. Simple programs should produce the same results for the same search depth, but the more complex programs may not. Some programs do some form of learning over time, and programs supporting multiple processors are not guaranteed to produce the same output. Usually, programs will give more or less the same output, but if you are needing to prove that a program is deterministic (ex. for academic research), then you may be stuck with a handful of simpler programs (TSCP, and similar open source programs).

I believe there is a similar protocol for Go (Go Text Protocol, maybe?), but I have never used it.

[hgm]

am I wrong in thinking that before picking a move, the program makes a list of several moves and ranks them according to how good they are? If so, isn't this the idea place to control quality - make it sometimes pick a move that isn't at the top of the list?

Normally a Chess program only worries about findingthe strongest move, and only tries to prove for the other moves thatthey are wrong. In this proces the ordering of theother moves gets lost, i.e. the program has no idea what the second best move is.

But the same effect which you describe can be realized by adding a random value to the score of each move, and then apply the usual procedure for finding the best one including this random value. The one that comes out as best then does not necessarily have to be the best on its own merit, it might just have been lucky to draw a large positive random bonus.

The larger the random values, the larger the difference in score between a move that can still be chosen and the best move (or at least what the program thinks is the best move). So this is a very good way to continuously tune the move quality (as I already mentioned), and it adds randomness at the same time. In the limit of extremely large random values, the true score is no longer significant, and the program simply becomes a random mover.

This is not a standard feature in most engines, though. (Or in fact of any engine I am aware of.) But it is easy to implement.

[Gerd Isenberg]

Welcome back Russell!
Still bitboarding?

Cheers,
Gerd

[rreagan]

Welcome back Russell!
Still bitboarding?

Cheers,
Gerd

Hey Gerd, yes, still bitboarding I've had to catch up on all of the magic bitboard developments. Interesting stuff. It seems like that has become the popular approach now.

[Gerd Isenberg]

Hey Gerd, yes, still bitboarding I've had to catch up on all of the magic bitboard developments. Interesting stuff. It seems like that has become the popular approach now.

Yes, without bitboard bit-twiddling chess programming would be so boring
I still rely on SSE2 kogge-stone fill-stuff with vectors of four bitboards (quad-bitboards). Actually I even flip the color each make/unmake to have always white to move. I'll hope earlier or later it pays off with 128-bit SSE2 alus. Hopefully amd will overcome the current K10 (barcelona) quarrels. The announced SSE5 looks promising thought.