Getting ready for Thermopylae

[Daniel Shawul]

Nebiyu is searching like 5 plies less than it should.Then I tested my compile on my laptop and got the same very slow thing. Even the perft number are wrong. I think there is really really something wrong with my compile. Why it works on one computer and not in the other ?? uninitialized variable or pointer... I don't know at this time but more later.

[hgm]

Well, Spartacus is also stll plagued by the mysterous crashes. (Always with black.) I have a position now where it crashes reproduciby, though. So I must be able to debug it now. But it is slow going.

[Daniel Shawul]

Oops the perft numbers are the same but I am getting weird behaviour now. It displays different behaviour from compile to compile, not from run to run. At first I thought it was the use of 'unsigned int' for move which was the problem, because I changed it to use all the 32 bits to accomode jetan. But no, it breaks again when I recompile the same code!! Random number are generated from each time but that is not the problem. Because its behaviour remains the same until I recompile. Note that the same thing happens also in debug mode where all optimization is turned off.
I can send you a better version that is produced when I got lucky during the build. Why would a compiler change behaviour from compile to compile ?

[Evert]

I have tested all engines we have now to my satisfaction, so I wanted to start the official Spartan Chess tournament (Thermopylae 2011) soon.

What's the timescale for "soon"?
It seems that some of the participants are in need of some debugging. That may include Sjaak, which for some reason is now randomly dropping pieces in test games (of regular chess, but presumably the same things happen in other variants), but not when I feed the same position into the search again.
At least I have a log file now that includes the iteration data, should hopefully help clear things up...

[hgm]

I had hoped to start this weekend, because it seemed most engines were stable. But if I know people are working on fixes, we can wait.

I did not look at the games, but the last version of Sjaak did not seem to do much worse than earlier versions.

I renamed the Spartan11.pgn file on the server to Spartan11a.pgn, as it was getting so big that the cross-table generator crashed on it. So if you want to look at old games, you can tpe an 'a' bhind the name used when you click the PGN download link in the viewer page.

[Evert]

I did not look at the games, but the last version of Sjaak did not seem to do much worse than earlier versions.

No, I didn't have the impression it was doing too badly at Spartan either, but that impression was based on playing an earlier version of the same program.
Two days ago I ran two normal chess test matches, first against micro-max and then against TSCP, with rather disasterous results (~50% against micro-max, arguably not completely aweful for a generic engine, but much worse against TSCP). Looking at those games, the pattern is "nice positive score"/"hang a piece or make a losing capture"/"hopeless position"/"lose game". I don't have a clue at the moment (debugging session planned for tonight), but if it's affecting normal chess, then it should be affecting Spartan in the same way because it's using the same search and evaluation functions for both.
I know it's not an issue with running out of time since I've seen it happen at move 25 with plenty of time on the clock (at longer time controls).

Hopefully it's something I can fix quickly. I'll let you know. If it turns out that this is a quirk that somehow only affects regular chess but not Spartan, there should be no problem running the program in the tournament, of course.

[Daniel Shawul]

Finally found it! And it explains every weird behaviour.
My history move ordering was

Code: Select all

    score = history_func() - MAX_HISTORY;

The problem was history_func() returns a pointer not a value. I made it like that to handle many versions of history for the different games, and to allow both read and write. So it was decrementing from _address_ of the pointer rather than the history data , which was causing all sorts of problems. That was why I was getting different behavior when I recompiled, when I take it to a different computer, when I turn my face away from the screen Smile .
When the address is less than the MAX_HISTORY everything will be alright including lmr which does reductions on moves with negative value. And when I got unlucky and the address was larger, you get that slow engine. On a different machine, the address will be different which could cause the unlucky behavior again, so it was no guarantee at all it worked on my machine. This must be the weirdest bug I ever tracked down. Now that my history data kicks in, lets see how Spartacus handles it... wait... I should be humble until it wins at least a game Wink I will upload a new version later probably with some other "improvements".
Edit: I can't resist my self to say
This unforeseen event also proved a point that reductions are important but history isn't

[hgm]

Well, I got it too! Turns out white also had two Kings in Spartan Chess, as far as non-capture generation was concerned. Except that the second King was supposed to be always captured. But it wasn't, as it turned out I had mapped the piece count for each color onto the position of the second King (which in normal Chess was an unused piece-list entry). So the second King became un-captured,but usually it had a position outside the board, where it had no moves, as the unused part of the board sfilled with border guards. But on promotion the piece count is incremented, and this made the ghost King move. With several promotions in one line it would move close enough to the board so that it now could step onto it, and moves like i3h2 would appear in the move list. And when these moves were finally done, it caused a crash.

[Daniel Shawul]

well it looks like the Persians are envious of the two spartan kings
This reminds of something I wanted to ask you. I think rewarding a check of one of the spartan kings is not a good idea. It seems it is too easy to give a check (spartans having two kings and persians with many long-rangers) and yet too worthless because of the check immunity! Currently I have only a condition to not do reductions, which I think can be removed completely or only do it when that immunity is gone. I think the asymmetry should be reflected in the search as well. Generally I find this game more strategic than chess. But in that aspect I give Go the trophy. That game is so strategic one piece of knowledge is hard to counter by search. Pattern matchers are beating my engine again and again on a go server , and I can't get past 1400 elos . Even though I made my engine search 14 so so plies , situations like life and death of groups ,cut/connect groups is very difficult to evaluate and strategic engines with such knowledge are difficult to beat unless you have that knowledge too. Montecarlo is such a time saver in this aspect.

[Evert]

well it looks like the Persians are envious of the two spartan kings
This reminds of something I wanted to ask you. I think rewarding a check of one of the spartan kings is not a good idea. It seems it is too easy to give a check (spartans having two kings and persians with many long-rangers) and yet too worthless because of the check immunity! Currently I have only a condition to not do reductions, which I think can be removed completely or only do it when that immunity is gone.

What I do is this: I always extend all checks by one ply. A side is considered to be in check iff all of its royal pieces are under attack. That seemed to be the easiest way to implement the Spartan rules and it seems to work well in practice. One of the side attacks is that attacks on a Spartan king are treated like any other type of attack.
The only deviation from this is in SEE, where I always sort the royal piece to the end of the list, which may not be correct for the Spartans but makes the code simpler. I don't think it makes a big difference in practice.