Getting ready for Thermopylae

[Daniel Shawul]

It looks like we need opening positions badly. I have seen games being replayed until one of the engines make a slightly different move. My random numbers are generated with a different seed each time so that helps I guess.

[Evert]

It looks like we need opening positions badly. I have seen games being replayed until one of the engines make a slightly different move. My random numbers are generated with a different seed each time so that helps I guess.

Problem is, I don't think we have a good sense of what makes for a good balanced opening position at this point.
What I do at the moment is randomise the initial ordering of moves for the first 10 or so moves of the game. That means the program will randomly choose from more-or-less similar moves.

[Daniel Shawul]

Is it? I don't actually know, but it is used there, right?
I think mobility may well be the easiest way to make a general engine, if done properly. The reason I think so is that OliThink is reasonably strong using (mainly) mobility for normal chess. I don't see why a general engine couldn't have a comparable strength if the evaluation is based on the same philosophy.

Yes mobility is a good knowledge and I use it for reversi & amazons. There I have no other options as it is very important . If you use bitboards it is cheep so no doubt of improvement there.

I'm not so sure. I don't have a good intuition for what I would expect here. It might be a win, but it could be very difficult. I've seen one or two endgames from Sjaak of warlord vs. rook that were won by driving the defending king to the corner and mating it (a warlord can do that on its own). If the position isn't such that it's easy to do that, I don't know whether it's easily won or not. I suspect general vs rook is also difficult to win and probably a draw. No statistics though.

I now remeber HG mentioned it before in winboard forum a few years ago.
Warlord vs rook is a draw. Maybe implementing such trivial draw heuristic for KBK , KNK , KWKR ,KQKK using interior node recognizers will be fruitful. Still hard-coding though.

[Daniel Shawul]

Yes that may require years of work. Even gambit openings compensate the material for some other positional term tempo,mobility etc. But just to avoid repeating games, we can use something that will not leave one of the engines in a really bad shape with respect to material only. Anyway both engines will get the position playing as white and black, so whatever deficiency we have in there will not be unfair to one of the engines.

[hgm]

In the latest version of Spartacus I built some randomization: In the first 5 moves I add a random of 0-15 cP to each move in the root, for all later moves 0-7 cP, This should cause more randomization. Fairy-Max does randomize its first 4 moves quite heavily. ChessV has a very small opening book now, but I forgot to install that until the last few runs I did with it.

I do want to play multiple games with the same colors between the engines. So perhaps we should start each cycle of the tourney from a different initial position, which we take from some of the games that have been played between Spartacus and Nebiyu. We then can do two games per pairing each cycle, so that each position is played with both colors.

On-the-fly building of end-game tables would be a good solution for determining mating potential of single pieces or simple piece combinations. Mating potential or winning advantage is difficult to derive from piece values. E.g. KNNK is draw with a very large advantage, (despite the fact that there checkmate positions do exist), more than KQKR or KRK, which are both won. My EGTB generator can do fairy pieces, and I have run KW-KR and KC-KR (draws) and KW-KB, KW-KN, KG-KB and KG-KN (all won). Even KW-KBN is often won (but there are fortress draws).

I am not sure if in general checkmates with a colorbound piece + one other need to take place in the corner square of the color of that color-bound piece. For KBNK this might be because the Bishop is the slider, and can most easily make the switch from covering c8 (for trapping the bare King to drive it in the corner) to coverng a8 to mate it. I will check tomorrow how Ferz + Nightrider would do it.

[Evert]

On-the-fly building of end-game tables would be a good solution for determining mating potential of single pieces or simple piece combinations. Mating potential or winning advantage is difficult to derive from piece values. E.g. KNNK is draw with a very large advantage, (despite the fact that there checkmate positions do exist), more than KQKR or KRK, which are both won. My EGTB generator can do fairy pieces, and I have run KW-KR and KC-KR (draws) and KW-KB, KW-KN, KG-KB and KG-KN (all won). Even KW-KBN is often won (but there are fortress draws).

I am not sure if in general checkmates with a colorbound piece + one other need to take place in the corner square of the color of that color-bound piece. For KBNK this might be because the Bishop is the slider, and can most easily make the switch from covering c8 (for trapping the bare King to drive it in the corner) to coverng a8 to mate it. I will check tomorrow how Ferz + Nightrider would do it.

My assumption was that it wouldn't hurt to make that assumption: it's either needed, or it doesn't matter, in which case we might as well. That need not be true, of course.
There's some data on http://www.chessvariants.org/misc.dir/endgames.html, but no mention of whether you need to give mate in the corner of the colour-bound piece or not. It does mention fortress draws, which I'm not sure I understand even with the explanation given.

[Evert]

In other news, the version of Sjaak I sent to you earlier may be fine. I still haven't found the problem, but testing older revisions shows that the problems I have now have been introduced either shortly before or after the revision I sent you.

Ok, and now I have finally found the problem: I made a change to the way I record whether the current player is in check or not, and somehow that corrupted things in such a way that the program assumed that one side was in check even when they were not - so it would give away a piece under the assumption that the other side had to get their king out of check first. Obvious with hindsight given that the predicted moves were often random king moves, but quite hard to find. That bug certainly isn't in the last version I sent you.

[hgm]

It does mention fortress draws, which I'm not sure I understand even with the explanation given.

Fortress draws are simply cases where the strong side can make no progress, without an obvious reason, such as being perpetually checked or losing a piece. I guess the name comes from before the computer era, when it was only possible to prove such cases if the weak side, in the course of refuting attempts to subdue it, could stay in a quite limited number of constellations with its own pieces ('the fortress'). E.g.

[d]k7/1b6/8/3n4/8/8/8/3QK3 w - - 0 1

depicts a fortress draw in KQKBN, where black shuttles its King between a8, b8, a7, and its Bishop occasionally to a8. White can make no progress, because he cannot approach with his King to attack the Bishop. This fortress holds out even against an Amazon (Q+N).

The classificaion is a bit arbitrary, because it assumes an order of priority in the way the strong side would admit to the draw. For instance, the weak side could have a perpetual chase on a piece of the strong side, so that the latter would have the choice to either abandon the piece (converting to a drawn end-game), or repeat moves. The study at the link you gave seems to consider this a fortress draw, because the conversion cannot be forced. But neither can the repeat, if the strong side prefers to allow the conversion. So it should really be classified as 'mixed' fortress/conversion, and 'fortress draw' does not seem a proper name for that. ('Perpetual chase' would be better, but is a classification not used here).

[Evert]

Fortress draws are simply cases where the strong side can make no progress, without an obvious reason, such as being perpetually checked or losing a piece.

I know. What I meant was, I dnn't understand how the described fortress draw for king vs. king with nightrider and ferz works. Probably trying it out on the board instead of trying to "see it" in my head would help.

[Daniel Shawul]

The fortress draws remind me that maybe monte carlo would be an easy solution. It is used for detecting fortress draws even in middle games with many pieces. For this case also we just do many random games (ok may be a little biased to avoid throwing piceces away) and see if we have progressed at the terminal nodes i.e if we made a capture along the way, pushed a pawn etc... The playouts don't have to be made to the real end of the game. This sounds like a good way to avoid all the endgame hassle for the different games and a good opportunity to experiment