pre-announcement: 10x8 tourney

[Evert]

Off topic but I'd like to know how many computer programs are able to play spartan chess? I will probably create one, I guess the play is interesting. Any reference for the rules? Thanks.

See here: http://spartanchessonline.com/index.html
As for programs that can play, there should be at least six or so. Certainly Fairy-Max, Nebiyu, Spartacus, Sjaak and ChessV can do it, but I'm not sure which of those are easily available for download.

[Ferdy]

Off topic but I'd like to know how many computer programs are able to play spartan chess? I will probably create one, I guess the play is interesting. Any reference for the rules? Thanks.

See here: http://spartanchessonline.com/index.html
As for programs that can play, there should be at least six or so. Certainly Fairy-Max, Nebiyu, Spartacus, Sjaak and ChessV can do it, but I'm not sure which of those are easily available for download.

Thanks, this could be my next project

[hgm]

Off topic but I'd like to know how many computer programs are able to play spartan chess? ...

As for programs that can play, there should be at least six or so. Certainly Fairy-Max, Nebiyu, Spartacus, Sjaak and ChessV can do it, but I'm not sure which of those are easily available for download.

There are two others: Oberon and Catalyst. The download situation might be a bit bleak, though. The last official release of ChessV does not support it yet, I obtained the version that implements it privately. Spartacus is also not public yet, although I intend to release it when it is finished. I am not even sure I haven't broken Spartan Chess in the latest version. But I am always willing to make the old version that won the Spartan Tournament available privately to engine authors.

[Evert]

Does the latest release of FairyMax support Spartan?
The version I have doesn't, but it may not be the latest.

The version of Sjaak that played in Thermopylae is of course available and I'll probably release a new version soonish, when I get Capablanca working at least somewhat decently.
I'm currently working on rewriting the king-safety evaluation, which is a bit of a hack right now. I have a few ideas to play with.

[hgm]

Yes, the 4.8R (and also 4.8Q) so support Spartan as independent variant. (And 4.8R also Cambodian Ouk and Falcon Chess!)

[Evert]

Hopefully I'll find some time over the weekend to release the current version of Sjaak, with support for Capablanca. I should probably run a couple of test matches in 32 bit mode to make sure it's all working properly there (what sort of hardware will be available for the 10x8 tournament, by the way?)

I'm currently running the tuning matches for the king safety evaluation model, which will hopefully scale well to other than the default piece set (ie, it gives more weight to king safety in Capablanca and also slightly more in Spartan compared to normal chess).
The main thing that is currently missing is some sort of passed pawn evaluation. I watched a Spartan test game that ended with rook+bishop+4 pawns vs lieutenant+captain, which should be an easy win for white, but it took a long time for white to advance its pawns. For Berolina pawns it probably makes little sense to do a "passed pawn" evaluation, since their mobility is so much higher. It might make sense when they reach the fifth rank. Even for normal pawns against Berolina pawns it may not make much sense as a concept...

[hgm]

As things look now, the tourney will be on a 32 bit system (Core 2 Duo, E6600, single CPU).

What helped very much in micro-Max (which cannot recognize passers) is increase the Pawn push bonus if the game-state progresses. In a Fruit-like system this would mean you would uses an opening Pawn PST with a low vertical gradient, (Fruit, in fact, has zero gradient), and an end-game PST with a much higher gradient. That, together with hefty bonuses for 6th and 7th-rank Pawns leads to quite natural Pawn play.

[Evert]

As things look now, the tourney will be on a 32 bit system (Core 2 Duo, E6600, single CPU).

That should be able to run 64 bit.
But 32 bit should be fine, although Sjaak will suffer for it (being a bitboard program). Having said that, it currently compiles fine but segfaults when I run the code in 32 bit mode. Annoyingly enough, it works correctly when I run it under valgrind and gdb isn't helpful either. I'm hoping it's an issue with Apple's outdated C compiler, but I'll know for sure when I can test on my Linux box at home later tonight.

What helped very much in micro-Max (which cannot recognize passers) is increase the Pawn push bonus if the game-state progresses. In a Fruit-like system this would mean you would uses an opening Pawn PST with a low vertical gradient, (Fruit, in fact, has zero gradient), and an end-game PST with a much higher gradient. That, together with hefty bonuses for 6th and 7th-rank Pawns leads to quite natural Pawn play.

I have something like that, but for me it only works so-so. Helps in some cases, but causes hopelessly optimistic pawn pushes in others. I don't think I have a scaling with game-phase for this though (I don't have it for any piece square tables, except for the king) and that may be why.
I think I can fairly easily test whether a pawn has an unobstructed (by enemy pawns) path to its promotion zone, either from where it is now or from where it can get in one move. I think that's general enough to award a bonus for both normal pawns and Berolina pawns if I include a mobility term for pawns as well. We'll see.

[hgm]

That should be able to run 64 bit.

Indeed. But the Vista OS that came with it won't. And the drivers for the on-board video were only available in 32-bit mode, at the time I bought it, so it was not possible to run a 64-bit Vista on it...

I have something like that, but for me it only works so-so. Helps in some cases, but causes hopelessly optimistic pawn pushes in others. I don't think I have a scaling with game-phase for this though (I don't have it for any piece square tables, except for the king) and that may be why.

Indeed, that made the difference. Awarding pushes in the opening leads it to wreck its Pawn structure, and by the time you have it acceptable for the opening it becomes too reluctant to push in the end-game.

I think I can fairly easily test whether a pawn has an unobstructed (by enemy pawns) path to its promotion zone, either from where it is now or from where it can get in one move. I think that's general enough to award a bonus for both normal pawns and Berolina pawns if I include a mobility term for pawns as well. We'll see.

That sounds reasonable, but beware that 'unobstructed' is a dynamic concept here: with Hoplites and FIDE Pawns moving at cross angles, the requirement is that the Pawn cannot be intercepted. So a FIDE Pawn on e4 will not be a passer if there are Hoplites in the triangle e5-h8-b8. (In Spartacus I had a table to mark such a board sector as function of the Pawn-Hoplite vector.) For Hoplites it was just too complex, and I did not make an effort; they are almost always passers. I only penalize them for being blocked where they are standing.

[Evert]

Indeed. But the Vista OS that came with it won't. And the drivers for the on-board video were only available in 32-bit mode, at the time I bought it, so it was not possible to run a 64-bit Vista on it...

Fair enough!
I had an inspired thought over lunch and just did a quick check to confirm it (I guess I'll be using some of my evening to do work instead now): the reason I was getting crashes from the 32 bit version of Sjaak was that it was trying to use SSE instructions on memory that was not aligned to a 64-bit boundary. Easily fixed, and it works properly now.
In perft on a large board, Sjaak takes a 100% speed penalty from running in 32 bits rather than 64 bits (in other words, it takes twice as long to reach the same depth). There should be room for optimisation there, so hopefully I can bring this down a bit.

I have something like that, but for me it only works so-so. Helps in some cases, but causes hopelessly optimistic pawn pushes in others. I don't think I have a scaling with game-phase for this though (I don't have it for any piece square tables, except for the king) and that may be why.

Indeed, that made the difference. Awarding pushes in the opening leads it to wreck its Pawn structure, and by the time you have it acceptable for the opening it becomes too reluctant to push in the end-game.

This is exactly the problem. Ok, maybe I could try that first.

That sounds reasonable, but beware that 'unobstructed' is a dynamic concept here: with Hoplites and FIDE Pawns moving at cross angles, the requirement is that the Pawn cannot be intercepted. So a FIDE Pawn on e4 will not be a passer if there are Hoplites in the triangle e5-h8-b8. (In Spartacus I had a table to mark such a board sector as function of the Pawn-Hoplite vector.) For Hoplites it was just too complex, and I did not make an effort; they are almost always passers. I only penalize them for being blocked where they are standing.

All true: this would not be a true "passed pawn" evaluation, it would be an evaluation term that decides whether it would be good to push a particular pawn forward or not. This would include true passers as well as candidates, but I expect the bonus would be (a lot) smaller than it should be for either of those specifically. It should still help, hopefully.
It's true that a simple check fails to recognise that a hoplite can intercept the pawn before it promotes, but then again: the fact that a pawn has no pawns in front of it doesn't mean that its path cannot be obstructed by other pieces. Of course, those pieces are then bound to blocking the path of the pawn, which is why it's still an advantage to have a passed pawn. How much of an advantage depends on the blocking piece, and in the case of a hoplite, the advantage would be almost zero (in the limiting case of a blocking enemy pawn, the advantage is of course exactly 0, since the pawn is no longer passed in that case).
Of course, this could all turn out to be unnecessarily complicated, but I'm having fun trying to come up with ways of doing it, so it's not time wasted.