Thermopylay Marathon 2011 (live!)

[Daniel Shawul]

I just did it. What I did was to add (rand() % 100) i.e +-100 score to _all_ root moves at iteration 0. I do a qsearch for initial root move ordering. From then on the root moves are sorted with nodes count and I seem to get very variable games. From the start I got 5 different moves in my 6 tries... and it also seems plays well since only the 0th iteration move order is changed.

Edit : randomizing version uploaded!

[Evert]

Sjaak has exactly the same bug as Catalyst. It also does not count the forced moves.

Can you fix that, Evert?


Or would it be better if we just abandon the idea of playing from a different position in the second cycle? Most engines randomize, I think.

At the moment I don't have a clue where to start looking for the problem. All that happens in force mode is that the computer doesn't start thinking. It still increments the move counter as they're played.
I'll look at it, but I won't really have time to do so until this evening (which is 6-7 hours away in my local timezone); I also won't have acces to a Windows machine until then.
Sjaak should understand setboard, if that's any help.

[Evert]

I don'tknow about Sjaak, but if Nebiyu randomizes tcould at worst be the only non-randomizing engine, and that would be no problem.

Sjaak randomises its initial move order at the root (in the same way as Nebiyu apparently).

[hgm]

OK, I will download the new Nebiyu then, and start from the standard position. It dawned on me that another way to solve this problem would be to play incremental or sudden-death TC. But that can have its problems too.

Anyway, I hope that Catalyst and Saak can be fixed on the somewhat longer term. It should not be that hard to determine the problem: just look at the code that determines how long you are going to search. What time and movestogo parameters go in there, and are these updated properly (e.g. print their value every move,so it shows up in the debug file).

[Richard Allbert]

You should read until the end of the line!

Catalyst has the infamous WinBoard bug: it fails to count the forced moves. I had an opening line of 8 ply, so when Catalyst gets anothe minute added to its clock on move 40 (I was doing 40/1), it uses it all upon move 41-44. Then, when it has to do 40 more moves in 0.9 sec, because it does not get the 1 min it counted on, it forfeits because of the illegal move 'unknown'.

Can you fix that, Richard?

Done and uploaded. I forgot to add

Code: Select all

if(XbOpt->movespersession) {
	       timer->movestogo[p->side^1]--;
	       if(timer->movestogo[p->side]==0) timer->movestogo[p->side^1] = XbOpt->moves;
  }

into the parseUserMove() function!

... I think you've found a bug in Jabba as well

[Evert]

Anyway, I hope that Catalyst and Saak can be fixed on the somewhat longer term. It should not be that hard to determine the problem: just look at the code that determines how long you are going to search. What time and movestogo parameters go in there, and are these updated properly (e.g. print their value every move,so it shows up in the debug file).

Oh, I'll certainly look into it (if Sjaak has this problem, chances are Jazz has this problem too, since the time management code is identical and the XBoard interface is almost identical). As I said, I'm not sure where to start looking, since the only difference between force mode and normal mode is that the computer doesn't do a search. Everything else (in terms of making moves, updating data structures etc.) is the same.
If by any chance you have a sequence of xboard commands that immediately show the problem (maybe from a log file) that could be very helpful.

[hgm]

The problem shows only up at the beginning at the second session, after the engine has played most moves of the first session. That is never very quick. (If you take 2 moves per session or so, the effect is not very pronounced.)

If the engine would print the number of moves still left in the current session, as used in calculaton of the move time,however, you could see it immediately: just types

level 40 5 0
new
force
e2e4
e7e5
go


The engine should then print 39. If it prints 40, that would be wrong.

[Evert]

The problem shows only up at the beginning at the second session, after the engine has played most moves of the first session. That is never very quick. (If you take 2 moves per session or so, the effect is not very pronounced.)

If the engine would print the number of moves still left in the current session, as used in calculaton of the move time,however, you could see it immediately: just types

level 40 5 0
new
force
e2e4
e7e5
go


The engine should then print 39. If it prints 40, that would be wrong.

Ok, I think I've fixed it in revision 104 (along with another minor tweak to reduce the risk of timelosses).
The interface was originally designed for UCI rather than XBoard, and UCI always tells you how many moves you have left until the time control, so the part where the moves to go is calculated wasn't well tested. In fact, whenever "moves to go" reached 0, Sjaak would assume that it had to play 20 moves in the time remaining. That would only affect timing after the first time control, and probably doesn't lead to obviously bad time management, but still...

[Richard Allbert]

Please download again. It should be ok now...

Thanks

Richard

[Richard Allbert]

Is the new catalyst now playing? It seems to have won some games