Opening positions for WB F usage

[Gábor Szots]

Please someone help me.

I have created a PGN file with 200 12-game long games, the end positions to be used as starting position for an engine match.

Now how can I make two engines to play a match using that file as an opening book? I tried but WB told me the file contains no positions (of course as it only contains games).

[Matthias Gemuh]

Please someone help me.

I have created a PGN file with 200 12-game long games, the end positions to be used as starting position for an engine match.

Now how can I make two engines to play a match using that file as an opening book? I tried but WB told me the file contains no positions (of course as it only contains games).

Does ChessGUI run fine with the pgn start positions ? Just curious

Matthias.

[Gábor Szots]

Please someone help me.

I have created a PGN file with 200 12-game long games, the end positions to be used as starting position for an engine match.

Now how can I make two engines to play a match using that file as an opening book? I tried but WB told me the file contains no positions (of course as it only contains games).

Does ChessGUI run fine with the pgn start positions ? Just curious

Matthias.

I haven't tried that. ChessGUI has its remis book so there I don't need tricks.

Best,

[H.G.Muller]

WinBoard distnguish files with positions (FEN/EPD) and files with games (PGN). The fact that you get this error message suggests that you have asked WinBoard to read positions, while in stead it finds games.

The options you need are

winboard -loadGameFile="xxx.pgn" -mg=200

But I don't think WinBoard automaticaly steps the game number in a match. (I have never tried it.) There is an option "-loadGameIndex N" that tells you which game in a game file is to be used (and similarly "-loadPositionIndex N" for positions). Perhaps I should make it such that when you use N=-1, it will automatically increment each game, while -2 would mean it automatically increments every 2 games (so that each game/position is played with white and black).

I always do this kind of stuff using PSWBTM to invoke WinBoard. That is much more flexible (since you can also make gauntlets agains several opponents, rather than just one), and user friendly. You can ask for any number of positions from the file, make it rewind after a given number of ositions is played, and play each position once or twice. Also here you have the option to play from a game file or a position file. So as far as I am concerned, WinBoad match mode is an obsolete feature.

[Gábor Szots]

WinBoard distnguish files with positions (FEN/EPD) and files with games (PGN). The fact that you get this error message suggests that you have asked WinBoard to read positions, while in stead it finds games.

The options you need are

winboard -loadGameFile="xxx.pgn" -mg=200

(snip)
as far as I am concerned, WinBoad match mode is an obsolete feature.

Thank you for the reply. I was not aware there is a -loadgamefile command available so I tried to use your previous suggestion -loadpositionsfile, and of course that did not work. I could have figured it out but I was a bit tired to think.

As for PSWBTM and other managers:

I used to use WB in the past when I started each game manually. No problem when you play game in 60 minutes. Now that I run blitz tournaments for CCRL that is no more a viable option. Many (some free) very good GUI's provide features like built-in tournament managers and general opening books, the latter is what I tried to simulate with WB.

I would gladly use WB for matches if I could use an opening position file which is incremented as you described (I like both methods). Until then, A... is best (sorry, Roger!).

Best regards,

[Gábor Szots]

But I don't think WinBoard automaticaly steps the game number in a match. (I have never tried it.)

It doesn't (just tried).

[H.G.Muller]

OK, it seems I posted a bad alpha.tst, where I had forgotten to recompile parser.c when I had changed a header file file. As a result it could no longer parse PGN. Apparently you have been using that one.

I corrected this, and even implemented the autoincrementing index. If you use -lpi or -lgi=-1, it starts with position or game 1, and takes the next one each new game. If you take -lpi or -lgi=-2, it plays each position in pairs. Other negative values have undefined meaning, and are reserved for future expansion. There is no auto-rewind yet, it is up to the user to make sure there are enough games or positions in the file to last the entire match.

The new alpha.tst (4.3.15c) already contains these modifications.

[Marc Lacrosse]

So as far as I am concerned, WinBoad match mode is an obsolete feature.

Hi HG

This statement of yours is probably the one with which I most strongly disagree after all these years where i often appreciated the majority of your comments.

I have two PCs performing tournaments or analysis 24/7 here and more than 50% of my automated tournaments are performed using winboard match mode through a simple preprocessor utility that I wrote myself (see http://users.skynet.be/mlcc/chessbazaar/news.html for an older version).

I am strongly convinced that a large number of ultrafast games is often a better first-line approach than a smaller number of slower ones for comparing two different versions of the same program.

Using Pradu's excellent interface you simply cannot organise tournaments with a shorter-than-one-minute one game cycle.

With a few tricks the fastest I could go with my little utility is a little more than four complete games per minute with an acceptably low rate of errors. This is not far from ten times more games per time unit than any interface can offer by now.

What i miss the most is "X moves in Y time" with Y smaller than one minute and also Fischer timings with initial time capital in seconds (in the present state this is limited to 1 minute minimum) and subsecond increments.

Marc

[H.G.Muller]

I urged Pradu to implement sub-min time controls, but so far he did not yield to my pressure. Especially when I will have implemented multi-session time controls, it will be essential that the the /TC parameter is passed as an arbitrary string, not as a number.

But WinBoard 4.3.13+ offers a very easy work-around for PSWBTM's lack of support for sub-minute TC: play both engines with a time-odds factor of 60, in -timeOddsMode 0, and the number given in PSWBTM is interpreted as seconds, rather than minutes. You could put the required commands simply in the winboard.ini file.

I agree that for extremely fast games, like sub-10sec, match mode while re-using the engines might offer a speed advantage. But it is exactly the reusing of engines that causes me most trouble in match mode. If one of the engines hangs, the whole match is dead, and that engine will just suffer one time-forfeit after another. Engines that support 'ping' only solve that to the extent that the match hangs after their first forfeit (which is even more detrimental if you automatically play a batch of engines.

Perhaps I should add a time-out on 'ping', that if an engine does not respond within a given time, it is killed and restarted even when -reuse is in effect. But the problem is that killing under Windows does not seem very reliable. So in this approach the number of hanging engine processes might abound, corrupting the remainder of the match by overloading the CPU. This problem also occurs when using PSWBTM, but there you can at least use a kill list to kill engines known to be buggy after each game.

In fact PSWBTM also uses WB in match mode, with "-mg 1". (I guess this only serves to automatically terminate it.) I did request Pradu to also supply a variable number of games, so that you could play every position, say, 10 times in a row even under PWBTM, and save on engine startup time. Then you would have the best of both worlds: the engines would be reused a number of times, but if they hung you would recover within a reasonable number of games. Actually there are tricks to force WB to use a larger number of games even when running under PSWBTM, by hiding the -mg command in all engine installs, as the engine options overrule even the command-line options. But I am not sure how PSWBTM would handle the PGN. I think it edits the tags, and it would likely only edit the tags of every first game of the match only.

Anyway, I put the auto-increment in. Automatic rewinding through new command-line options will be supported in the next official release.

[Pradu]

I urged Pradu to implement sub-min time controls, but so far he did not yield to my pressure. Especially when I will have implemented multi-session time controls, it will be essential that the the /TC parameter is passed as an arbitrary string, not as a number.

Ok, I will have it done this weekend. I personally didn't think very short games would be a representative benchmark for time controls used in computer chess tournaments, but I guess many think otherwise. I will have seconds implemented into PSWBTM this weekend and release it this weekend as well.

What I have done in Buzz for extremely short time controls (which I tried to use for automated tuning for piece material values which didn't work too well for me...) is implement a "Winboard" in Buzz itself. It's not really Winboard protocaly implementation but two copies of Buzz playing it self with different configurations at very fast speeds within the same executable. This has an advantage over Winboard in terms of speed because you have additional overhead passing messages through Winboard to another copy of the engine for extremely short games and this overhead can be significant depending on how short of a game you want it to be.

I agree that for extremely fast games, like sub-10sec, match mode while re-using the engines might offer a speed advantage.

This takes quite a bit more effort to accomplish so I'll wait a while to see if it's really a necessary feature...

In fact PSWBTM also uses WB in match mode, with "-mg 1". (I guess this only serves to automatically terminate it.) I did request Pradu to also supply a variable number of games, so that you could play every position, say, 10 times in a row even under PWBTM, and save on engine startup time. Then you would have the best of both worlds: the engines would be reused a number of times, but if they hung you would recover within a reasonable number of games. Actually there are tricks to force WB to use a larger number of games even when running under PSWBTM, by hiding the -mg command in all engine installs, as the engine options overrule even the command-line options. But I am not sure how PSWBTM would handle the PGN. I think it edits the tags, and it would likely only edit the tags of every first game of the match only.

Yes it does indeed edit the tags but I'm not sure which PGNS at the moment because I never tried running it with mg more than one (or even planned on it) and can't remember because I haven't looked at or modified that code in a while either.

[H.G.Muller]

Ok, I will have it done this weekend. I personally didn't think very short games would be a representative benchmark for time controls used in computer chess tournaments, but I guess many think otherwise. I will have seconds implemented into PSWBTM this weekend and release it this weekend as well.

Be sure then that it is not only strings of the format "0:30" you allow, but also things like "60+20/15+5+1". Just anything that is typed there should be passed to WinBoard in the "-tc STRING" argument.

What I have done in Buzz for extremely short time controls (which I tried to use for automated tuning for piece material values which didn't work too well for me...) is implement a "Winboard" in Buzz itself. It's not really Winboard protocaly implementation but two copies of Buzz playing it self with different configurations at very fast speeds within the same executable. This has an advantage over Winboard in terms of speed because you have additional overhead passing messages through Winboard to another copy of the engine for extremely short games and this overhead can be significant depending on how short of a game you want it to be.

Yes, that is how I did it in micro-Max too, before it was WB compatible.

Yes it does indeed edit the tags but I'm not sure which PGNS at the moment because I never tried running it with mg more than one (or even planned on it) and can't remember because I haven't looked at or modified that code in a while either.

Well, I guess it only edits the tags for game number, and engine names. So if you install engines in the PSWBTM engine manager with exactly the same name as WinBoard would think they have (from the execuatble name, or the name feature if the engine implements it), the editing of the names is in fact a no-op. And the game number is not really important. So even if the later games would not be edited, the PGN would be useful. The score displayed by PSWBTM would probably be based on the first game of each match only, but with hgtbl or BayesElo you could extract the total result from the PGN directly. If the engine names give you trouble, you can always edit those later by hand, with a global replacement.

The only thing you would have to do is to install the gauntlet engine with the option "WBopt /mg=10", and it might work. (In a Round-robin you would have to install every engine with this argument.)

[Gábor Szots]

OK, it seems I posted a bad alpha.tst, where I had forgotten to recompile parser.c when I had changed a header file file. As a result it could no longer parse PGN. Apparently you have been using that one.

I corrected this, and even implemented the autoincrementing index. If you use -lpi or -lgi=-1, it starts with position or game 1, and takes the next one each new game. If you take -lpi or -lgi=-2, it plays each position in pairs. Other negative values have undefined meaning, and are reserved for future expansion. There is no auto-rewind yet, it is up to the user to make sure there are enough games or positions in the file to last the entire match.

The new alpha.tst (4.3.15c) already contains these modifications.

Thanks, HG. I have already run a test match with the command line '-loadGameFile 64.pgn - lgi=-1 -mg 64' and all went well.

Best regards,

[H.G.Muller]

Any ideas to improve WinBoard are always welcome!

[H.G.Muller]

OK, I experimented somewhat with PSWBTM. When I use the "WBopt" tick to force a larger number of match games, all games appear in the PGN. Only the first game of every match gets a "Number" tag, inserted directly after all other tags.

All the "Black" and "White" tags get edited to the names under which the engines were installed in the engine manager. Only problem is that PSWBTM does not realize that WinBoard alternates black and white for the engines on each game. Rather than asking Pradu to alter that, I think I should supply an argument to WinBoard that suppresses this color alternation in match mode ("-alternateColors false"?). After all, it is the task of PSWBTM to determine the colors in the pairing. PSWBTM even is aware of all the games played, in its "Standings" overview: apparently it reads those back from the entire PGN. (I already noticed before that if you play two engines with the same name, their results get added.)

I have one request for Pradu, though:
Currently you are using the option "-mg 1" to put WinBoard in match mode. Could you use "-mm" in stead? (Or "-matchMode true", which is equivalent.) These are options that imply each other: the default for -mg is 0, but if WinBoard finds that matchMode is set with 0 games it changes matchGames to 1. While if it finds that matchGames is non-zero, it automatically sets matchMode.

If you would use "-mm" in stead of "-mg 1", the user could put the actual number of match games as an option in the winboard.ini file, if he wants this to be different from 1. Then the kludge of hiding the "-mg N" option in one or more of the engine command lines would no longer be necessary.

[H.G.Muller]

Does this -reuse stuff actually work? Form looking at the WinBoard code it seems to me it should be the default. But if I look in my task manager, the engine processes disappear after each match game, and WinBoard sais it is re-starting them...

[PulsarMike]

i wasn't even aware there was another way to run matches other than winboard match mode. I can see the point that if an engine fails the match is off, if your running someone elses engines and dont want to waist games. But for me as a developer knowing it can play 50 games in a row without hanging is part of the debugging process and good to be able to test with winboard match mode.

Mike

[H.G.Muller]

Usually the results of a match against a single opponent is not a very reliable measure of strength. So typically I test by playing against 24 different opponents, and then each opponent with 10 different initial positions times 2 colors. Normal WinBoard match mode was completely useless for that, and even with the auto-increment of the position index I now added, it still could do only one opponent. So I would need a tournament manager anyway, and when I use one, I might as well have it handle the games from different positions as well.