General question about chess engines.

[Fguy64]

OK, continuing with the discussion about using one of the two standard GUI - Engine interfaces...

I am looking at a document that describes the UCI protocol, and struggling a little with the syntax. I'm trying to decide what the string actually looks like. here is an example, first the relevant command reference for a GUI to engine command...


* position [fen <fenstring> | startpos ] moves <move1> .... <movei>
set up the position described in fenstring on the internal board and play the moves on the internal chess board.
if the game was played from the start position the string "startpos" will be sent
Note: no "new" command is needed. However, if this position is from a different game than
the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.


if I wanted to give the engine the move in a simple king and pawn endgame I would send the following, including the asterisk, exactly as typed. The fen would be the position to start from.

* position [ fen 3k4/8/3K4/8/3P4/8/8/8 w - - 0 1 | startpos ] \n

if I sent this instead

* position [ fen 3k4/8/3K4/8/3P4/8/8/8 w - - 0 1 | startpos ] moves d4d5 \n

it would essentially be the same as if I had sent this...

* position [ fen 3k4/8/3K4/3P4/8/8/8/8 b - - 0 1 | startpos ] \n

in the second case the fen is the position after the move d4d5 has been made.

Do I have this right?

thanks.

[Teemu Pudas]

position fen 3k4/8/3K4/8/3P4/8/8/8 w - - 0 1\n
position fen 3k4/8/3K4/8/3P4/8/8/8 w - - 0 1 moves d4d5\n

[a|b] = a OR b.

[Fguy64]

Thanks Teemu. in my post I gave three examples. aside from the syntax, do you agree that #2 and #3 are essentially the same, that they both result in the engine having the move with the pawn on d5?

[hgm]

I suppose if I want to implement a simplifed UCI (or Winboard) protocol with just my own Java engine and GUI, will it be enough that they can ( if they can) communicate via stdin/stdout, or does the engine (if Windows based) have to be an exe file as the UCI document from shredderchess.com suggests.

Indeed, aything that communicates through stdin and stdout is good enough. It must not buffer stdin or stdout, though, because then you very quickly gat into a deadlock, GUI and engine waiting for each other, while the command that is supposed to put one of them to work is waiting in a buffer somewhere until there is more to send.

The example that you give are indeed essentially the same, because the move is irreversible. If it had been reversible, the difference is in the recognition of 3-fold repetitions.

[Fguy64]

thanks hg for a helpful reply. that answers both questions. on we go

[Fguy64]

hmm I can see that writing a routine to parse UCI commands is going to be tougher than it was to parse a fen string. with fen a simple string tokenizer with spaces as separators and you are off and running, but with UCI you have subcommands and arguments, and you can have to identify whther a sequence of substrings contains subcommands or is just a series of arguments. Not to mention single arguments such as fen strings that themselves contain spaces.

It would be nice if the main components of a command string were separated by something other than spaces, but no such luck I guess.

[hgm]

Haha! Told you that WB protocol would be simpler!

[Fguy64]

heh heh. Well, I guess I shall take a look at WB then, save this one for late

[Fguy64]

This seems to be a good thread to group together basic questions

I've been reading up on Hash tables, I'll just summarize my understanding, let me know if I'm wrong.

A Hash table is the same thing as a transposition table.

The purpose of a hash table is more or less to store positions and their evaluations, so that you don't have to evaluate the same position twice.

It follows from the previous definition that if your evaluation of a position is very simple and quick, then there is not a lot of value to be gained from a hash table.

What actually gets stored in a hash table can vary widely. A zobrist key is one example, a fen string might be another, some object oriented positional representation is another. Obviously some representations are better than others.

The decision on what to store is based on performance. Assuming it works, speed is everything.

One thing that is not clear to me, is why a zobrist key might be that much better than a simple fen string, or how much better. I guess that will come when I get a better handle on the algorithms.

It strikes me that if one were to blindly follow the mantra of the OOP disciples, you could really make some bad decisions here.

My understanding is that something called NegaMax, which is another word for MiniMax, is an appropriate starting point to get into advanced algorithms.

[hgm]

A FEN string is longer than a Zobrist key. It is not easy to generate a table address from FEN positions that is homogeneously distributed over the tabe (and thus does not cluster in a small part of the table, leaving the rest unused). For Zobist keys, this is trivial: just take the N lowest bits of the key. It is far more difficult (= time consuming) to convert a position into FEN than nto a Zobrist key.

MiniMax alternates maximizing and minimizing the score on subsequent tree levels. NegaMax does the same thing at every tree level (maximizing the score), by inserting a clever sign flip of the score between levels.