Getting ready for Thermopylae

[hgm]

Do you distinguish between pawns that cannot be blocked at all and pawns that are not currently blocked?

I only award Pawns that cannot be blocked. 'Not currently blocked' can be changed with one move, so it is not really a strategic property of the position. I do give a bonus for a Hoplite attacking a Pawn, though, which then at the same time blocks it. With an empty square between them (e.g. Pe4, He6) it is more like a stand-off, as now neither the Pawn nor the Hoplite can move without being capturable by the other. So the disadvantage of being actually blocked is sort of compensated by dominating the Hoplite.

The Burmese Chess is a bit weird. A Ferz is only worth 1.5 FIDE Pawn,in a Chess context. But a large fraction of the value of the FIDE Pawn comes from the fact that it promotes decisively, so Pawns promoting to Ferz are worth only 50-66 cP, making a Ferz worth 2-3 Pawns in such games. (Of course Pawns can make a contribution to King Safety as well.)

The matter of pair bonuses still haas to be investigated. This is one of the tasks I have in mind for Spartacus. Fairy-Max is not very suitable for this, as it does not have pair bonuses in its evaluation, and thus does notprotects its pairs well enough to reap the maximum effect. Chess with Different Armies has some interesting color-bound piece types, in the Colorbound Clobberers army, and it would be interesting to see howpair bonuses of multiple different piece types interact..

[Daniel Shawul]

I have uploaded the working version now. http://sites.google.com/site/dshawul/Ne ... edirects=0
I was working on a complex passer detector but that is not included as I didn't want any more trouble on the tourney. Sorry for the delays.

[hgm]

OK, got it. I set it running now against Oberon, facing time odds of a factor 10. The old version (16:12:16) , which was playing with that same odds, was leading by 16.5-8.5 against ChessV. It seems 10 would be a good time-odds factor for Spartacus and Nebiyu. I have not tried how that would scale to longer TC (I will probably do the tournament at 40 moves/30 min), but, if anything, I would expect longer TC to be favorable for the engine facing time odds (because of diminishing returns).

[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. I'll test that exact version and let you know.

Preliminary results suggest that this is indeed the case. No piece drops so far, while the broken version drops a piece every other game at least. So Sjaak is good to go.

I'll keep making improvements to it locally, of course. It'll be interesting to do another tournament in a couple of months or a year.

[Daniel Shawul]

I don't know if I will get back to adding a lot of eval terms as it seems the major ones are difficult to implement, and I want to keep things as simple as possible. King safety, passed pawns are huge. Of course the biggest one is material evaluation which I haven't gotten round to, which i will when I devised a way to do some statistics. It can't be tuning to grand master games as there is isn't any games. HG I think you have experience on this.
A simple heavy centralization using pcsq, which btw seems to work in every game I implemented so far, could do wonders. But expecting that kind of eval terms for all games is unrealistic.

Also mobility may be important but probably too costly in mailbox board representation. Endgame knowledge too. My engine couldn't win a warlord vs rook with one king each. I think it is a win based on the material values I use which are taken from the spartanchess website. Generation of egbbs on the fly sounds ideal. Storing on disk or implementing specific endgame knowledge is tiresome if you want to support many alien games.
Btw do you guys collect an epd suite to test eval or anything else. I do and use it to catch some mistakes in eval and other placess. May be we can share some of those too.

[Daniel Shawul]

Ok that is good , now we can have some additional excitement. I will be forced to improve the eval too. Btw can you send me the that version 16:xx . I want to see what it is doing right dshawul at yahoo.com

[hgm]

Warlord-Rook is a draw. Queen against two Kings (KQKK) as well (if the Kings protect each other).

My only experience is with determining piece values (which I shared with you). Another tuning method I use is watching games, to spot things that seem obviosly wrong froma strategicpoint of view. (Like advancing passers too early, so they are lost.)

[Evert]

Also mobility may be important but probably too costly in mailbox board representation.

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.

Endgame knowledge too. My engine couldn't win a warlord vs rook with one king each. I think it is a win based on the material values I use which are taken from the spartanchess website.

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.

Generation of egbbs on the fly sounds ideal. Storing on disk or implementing specific endgame knowledge is tiresome if you want to support many alien games.

More so if you don't want to hard-code anything
The main gap for Sjaak is mating potential; it doesn't know it can't mate with a single bishop or knight. I know how to add that knowledge (it's not very hard, just try to make a position where a lone king is mated and if you can't, then that piece can't force mate on its own, so we store that information in case we need it in the evaluation later) but haven't done it yet.
I did add in the knowledge that a lone king needs to be driven to the edge of the board, and in the case of a colour-bound piece, to a corner of that colour. So it can actually do KNBK. The reason I implemented this is that I saw the ending come up at least twice in test matches (Spartan) and it annoyed me that it waited around aimlessly for the 50 move rule to kick in (at which point it sacrificed one of the pieces to reset the counter). Oddly enough, I don't think I've seen this ending ever in test matches from my normal chess engine, so I wonder if somehow it's more likely to occur in Spartan than in regular chess.

Btw do you guys collect an epd suite to test eval or anything else. I do and use it to catch some mistakes in eval and other placess. May be we can share some of those too.

I don't, but I should. The problem is of course that there aren't any available for Spartan and it takes a while to compose proper ones. When using test positions, I normally just use normal chess ones, in the hope that what works well there somehow carries over to other variants.
That, and ultra-fast games, which should be ok for testing evaluation changes.

[Evert]

My only experience is with determining piece values (which I shared with you). Another tuning method I use is watching games, to spot things that seem obviosly wrong froma strategicpoint of view. (Like advancing passers too early, so they are lost.)

I currently use h:100/C:300/L:310/K:475/G:725/W:825 vs P:100/N:320/B:325/R:500/Q:975, which I think is roughly what you estimated. Is that right?
I think there's a .25 discrepancy there, which (for Sjaak anyway) is compensated by the mobility bonus that the Spartans get in the initial position.

[PK]

Playing Spartan Chess, Oberon is using pcsq tables different than for normal chess (it does not evaluate passed pawns, but pawns and hoplites are simply encouraged to go forward), some basic pawn/hoplite shield code and mobility for weaker pieces. Normal chess version gained on mobility despite the slowdown, so I assume it should be the same for other variants. Chess version does some King tropism as well. Actually, eval uses the same generic routine for all the pieces (get mobility if applicable... get king tropism if applicable) and then there are some basic patterns on top of it.