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!
Thermopylay Marathon 2011 (live!)
Moderators: hgm, Rebel, chrisw
-
- Posts: 4185
- Joined: Tue Mar 14, 2006 11:34 am
- Location: Ethiopia
Re: Thermopylay Marathon 2011 (live!)
Last edited by Daniel Shawul on Tue Feb 08, 2011 5:47 pm, edited 1 time in total.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Thermopylay Marathon 2011 (live!)
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.hgm wrote: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.
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.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Thermopylay Marathon 2011 (live!)
Sjaak randomises its initial move order at the root (in the same way as Nebiyu apparently).hgm wrote:I don'tknow about Sjaak, but if Nebiyu randomizes tcould at worst be the only non-randomizing engine, and that would be no problem.
-
- Posts: 27795
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Thermopylay Marathon 2011 (live!)
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).
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).
-
- Posts: 792
- Joined: Wed Jul 19, 2006 9:58 am
Re: Thermopylay Marathon 2011 (live!)
Done and uploaded. I forgot to addhgm wrote: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?
Code: Select all
if(XbOpt->movespersession) {
timer->movestogo[p->side^1]--;
if(timer->movestogo[p->side]==0) timer->movestogo[p->side^1] = XbOpt->moves;
}
... I think you've found a bug in Jabba as well
Last edited by Richard Allbert on Tue Feb 08, 2011 7:27 pm, edited 1 time in total.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Thermopylay Marathon 2011 (live!)
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.hgm wrote: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).
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.
-
- Posts: 27795
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Thermopylay Marathon 2011 (live!)
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.
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.
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Thermopylay Marathon 2011 (live!)
Ok, I think I've fixed it in revision 104 (along with another minor tweak to reduce the risk of timelosses).hgm wrote: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.
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...
-
- Posts: 792
- Joined: Wed Jul 19, 2006 9:58 am
Re: Thermopylay Marathon 2011 (live!)
Please download again. It should be ok now...
Thanks
Richard
Thanks
Richard
-
- Posts: 792
- Joined: Wed Jul 19, 2006 9:58 am
Re: Thermopylay Marathon 2011 (live!)
Is the new catalyst now playing? It seems to have won some games