Development of WinBoard 4.3.15

[H.G.Muller]

Now that WinBoad 4.3.14 is ready for release, I have already started on version 4.3.15. Compred to 4.3.14, I changed the following:

1) Super-Chess is added as a new variant ("-variant super")
2) It is now possible to do claim verification without Detect Mates being switched on
3) Wins of a bare King for whatever reason are corrected to draws if Verify Claims is on.
4) The position index and game index can be made to auto-increment in match mode, by specifying it as a hegative number. A value of -1 increments every game, a value of -2 every 2 games (so that each position is played with both colors)

All the above already works (or, at least, is supposed to...) Other things I plan to add:

5) Rewinding of the position or game index after a specified number of positions/games, under control of a new option '-rewindIndex N'.
6) Replace the promotion popup menu by something else, perhaps optionally.
7) Implement the "Machine Both" mode, which is already in the menu.
8) Add the Amazon and Centaur as pieces WinBoard knows about.
9) Add multi-session time controls. (The clock-management for this feature already works, but the info is not sent to the engines yet.)
10) Add the standard options for engine configuring, for memory size, EGT path and opening book path. The UCI menu already allows the user to enter these parameters into WinBoard, so it should be easy to relay them to the engineif the latter so requests.
11) Add an option to configure the number of cores an engine may use.

[H.G.Muller]

Another idea for a feature to add is an option that allows WinBoard to be used under PSWBTM for multi-game matches, re-using the engines. Especially for ultra-fast games this could be a big time saver. The existing matchMode is less suitable for this, as it alternates the color each engine gets. This not only conuses PSWBTM (which could be fixed), but seems less logical, as it would subvert the control you have when using PSWBTM over which engine plays which color (through the PSWBTM tick box "Two Games").

So I want to add an option that suppresses the alternation of colors in Match Mode. First I was thinking of something like "-noColorAlternate true". But perhaps the option could be used to set the desired number of games at the same time, overruling what was specified in -matchGames. Something like "-sameColorGames N", with default N=0, and not saved in the winboard.ini. When set to another value, it would overrule the -matchGames parameter, and suppress the color alternation.

This could then be used to play, for instance 100-game matches of 40 moves per sec games, by setting PSWBTM for 40 moves per 1 minute, and adding to the winboard.ini file the options

/sameColorGames=100
/firstTimeOdds=60
/secondTimeOdds=60
/timeOddsMode=0
/matchPause=300

The time odds would reduce the minutes to seconds, and for each game you ask PSWBTM to play, in fact 100 would be played. The engines would be reused by default. The games would last about 3 sec on average each, after which a 0.3 sec pause would follow to allow the engine to recover at game end. (To finish the move they were thinking about, if the opponent resigns, for instance.) So after 5-6 min, when the match terminates, PSWBTM would receive a batch of 100 new results.

[Roger Brown]

Another idea for a feature to add is an option that allows WinBoard to be used under PSWBTM for multi-game matches, re-using the engines. Especially for ultra-fast games this could be a big time saver. The existing matchMode is less suitable for this, as it alternates the color each engine gets. This not only conuses PSWBTM (which could be fixed), but seems less logical, as it would subvert the control you have when using PSWBTM over which engine plays which color (through the PSWBTM tick box "Two Games").

Hello H.G.

As a user of both pieces of software I just wanted to understand what is being propsed here. Normally Winboard does the switching of colours so for a given position 1, Engine A would play white versus Engine B then Engine A would play black with that same position versus Engine B next.

This is a function which the WBTM should be taking care of with the ticking of 2 in the game box.

You are now proposing that Winboard alter the colour alternation behaviour, correct?

So I want to add an option that suppresses the alternation of colors in Match Mode. First I was thinking of something like "-noColorAlternate true". But perhaps the option could be used to set the desired number of games at the same time, overruling what was specified in -matchGames. Something like "-sameColorGames N", with default N=0, and not saved in the winboard.ini. When set to another value, it would overrule the -matchGames parameter, and suppress the color alternation.

So continuing the example above, with the setting, Engine A would play white with position 1 versus Engine B then Engine B would play white with position 2 then Engine A would play white position 3 etc., correct?

OR

Engine A would play white with position 1 versus Engine B then Engine A would play white with position 2 then Engine A would play white position 3 etc. Which one is it?

This could then be used to play, for instance 100-game matches of 40 moves per sec games, by setting PSWBTM for 40 moves per 1 minute, and adding to the winboard.ini file the options

/sameColorGames=100
/firstTimeOdds=60
/secondTimeOdds=60
/timeOddsMode=0
/matchPause=300

The time odds would reduce the minutes to seconds, and for each game you ask PSWBTM to play, in fact 100 would be played.

I am a little confused here but that happens often to me these days. Continuing my example with the three positions, what would happen given the settings above?

(a) 100 games in total
(b) 300 games in total
(c) 900 games in total


Further, if dividing by 60 reduces minutes to seconds, what does dividing by 6,000 do? Is there a theoretical limit to the time scaling? In other words, how fast is fast given today's computers? I have no interest in actually playing games at that speed but I would like to know anyway.

The engines would be reused by default. The games would last about 3 sec on average each, after which a 0.3 sec pause would follow to allow the engine to recover at game end. (To finish the move they were thinking about, if the opponent resigns, for instance.) So after 5-6 min, when the match terminates, PSWBTM would receive a batch of 100 new results.

Would PSWBTM be running the tournament? I ask because there are a couple of tools I use with PSWBTM which assist with the killing of engines at the end of a game, essentially reusing the engine in question each time.

This prevents the possibility of an engine hanging around in memory and messing things up.

Thanks in advance for any light you may shed.

Thanks too for your work on Winboard.

Later.

[H.G.Muller]

As a user of both pieces of software I just wanted to understand what is being propsed here. Normally Winboard does the switching of colours so for a given position 1, Engine A would play white versus Engine B then Engine A would play black with that same position versus Engine B next.

This is a function which the WBTM should be taking care of with the ticking of 2 in the game box.

You are now proposing that Winboard alter the colour alternation behaviour, correct?

Normally the PSWBTM calls a new WinBoard for each individual game. So alternating the colors is something WinBoard never gets to. The TM controls which engine has white by passing the engine names as first or second engine to WinBoard.

So continuing the example above, with the setting, Engine A would play white with position 1 versus Engine B then Engine B would play white with position 2 then Engine A would play white position 3 etc., correct?

OR

Engine A would play white with position 1 versus Engine B then Engine A would play white with position 2 then Engine A would play white position 3 etc. Which one is it?

Currently PSWBTM always alternates the colors if you ask for more games per pairing. The "Two Games" checkbox only controls if the next position from the list (Position File or Game File) is taken after one or two games. The auto-increment mode I now added, when the relevant Index is set to -1 or -2 allows the same two things to happen now in WinBoard match mode without the aid of any TM.

I am a little confused here but that happens often to me these days. Continuing my example with the three positions, what would happen given the settings above?

(a) 100 games in total
(b) 300 games in total
(c) 900 games in total

The number of games would be 100 times larger than PSWBTM would have played in the absence of the /sameColorGames option. I am not sure how the 300 enters thisdiscussion. Pehaps you misread the last option, whitch is not /matchGames, but /matchPause, to set the pause between the games to 300msec in stead of 10 sec.

The idea is that specifying /sameColorGames=N simply replaces every game of A vs B where A had white by a match of N games between A and B, where A has white in all N games.

Further, if dividing by 60 reduces minutes to seconds, what does dividing by 6,000 do? Is there a theoretical limit to the time scaling? In other words, how fast is fast given today's computers? I have no interest in actually playing games at that speed but I would like to know anyway.

The time is passed to the engine in centi-seconds, and the system clock the engine likely uses to determine if it should stop searching ticks only 60 times per second on most computers. So one should not overdo it, and 40 moves per sec is probably the limit to what still would work with a 60-Hz clock. But in combination with node-count-based time controls, you would not be dependent on any real clock. (But you would not really need the timeOdds in that case, you could just specify a very ow number of NPS, and specify many 'seconds'.)

But there is no limit to the time-odds factor per se: if you specify /firstTimeOdds=3600 in a 40/60 game, the thus handicapped engine would still have 1 sec for 40 moves. You might want to do that because the opponent has no time odds at all. (In the "Knightmate Challenge" I had to handicap JokerKM by a factor 144 to reduce it to a similar level as Dabbaba and MSCKP, and the nominal TC was 40/12', so Joker only got 40/5". It still beat them, but not by a guaranteed 100% anymore, so the tournament got a lot more interesting)

Would PSWBTM be running the tournament? I ask because there are a couple of tools I use with PSWBTM which assist with the killing of engines at the end of a game, essentially reusing the engine in question each time.

This prevents the possibility of an engine hanging around in memory and messing things up.

You mean the opposite of reusing: with PSWBTM you would restart the engine for every game. You can also do that in WinBoard MatchMode by asking for -xreuse or --reuse. (But no calling of external commands to help you killing rogue engine processes in that case.) The problem this whole device is supposed to relieve is that restarting the engine might take a few seconds, which becomes a large fraction of the time when you want to do sub-minute games

[Roger Brown]

The number of games would be 100 times larger than PSWBTM would have played in the absence of the /sameColorGames option. I am not sure how the 300 enters thisdiscussion. Pehaps you misread the last option, whitch is not /matchGames, but /matchPause, to set the pause between the games to 300msec in stead of 10 sec.

The idea is that specifying /sameColorGames=N simply replaces every game of A vs B where A had white by a match of N games between A and B, where A has white in all N games.

Hello H.G.

Thanks as usual for your in depth responses.

No. I was not confused - not any more than normal anyways.

The example is this:

I have three positions in a file and two engines. Should I use the settings as set out below to set up a match how many games would it generate? That is my question.

I was unclear if it would be 100 games - in which case the engines would have played an uneven number of games as white and black per position.

My math tells me that three positions at two games (alternating colours) each is 6 games which means that 100 games would leave an odd number of games with alternating colours.

300 games would be 50 matches of 6 games each and 600 games would be 100 matches of 6 games each.

I just wanted to know which of these would result if I entered the sameColorGames parameter as described below.

I hope that this was clearer.

/sameColorGames=100
/firstTimeOdds=60
/secondTimeOdds=60
/timeOddsMode=0
/matchPause=300

Ps. Is this very valuable stuff going into the helpfile? Should you need any assistance with the documentation please just let me know. Winboard is indeed very smart!

Later.

[H.G.Muller]

If you have 3 positions in the file, you must ask PSWBTM to play them all. Although WinBoard can step through positions now in match mode, by giving /lpi=-1 pr /lpi=-2, it will never do so under PSWBTM, for the simple reason that PSWBTM tells it not to. (It invokes WB with the option -lpi=N, N>0, which would overrule anything you would write in the winboard.ini file.)

You can ask PSWBTM to play all the positions by asking for 3 games per pairing, or ticking "Two Games", and asking for 6 games. With the options menttioned above in the winboard.ini file, this would result in 300 and 600 games, respectively. If you would not have ticked two games, engine A would have 100 time white in poition 1, 100 time black in position 2, and then again 100 times white in position 3, because that is how PSWBTM does it.

It might be useful to have some way to overrule the position choice PSWBTM makes, so that WinBoard itself could step through the position file. So that you could for instance do a Nunn match by setting /sameColorGames=10. Perhaps I could make this a side-effect of the option /rewindIndex=N, as this option only makes sense if the index actually steps. So an N>1 in that option would automatically reset the -lpi and -lgi option values to -1, no matter what was actually given. That would also save you work in passing options.

And yes, this should all go into the help. But only in the description of the /sameColorGames and /rewindIndex option, with perhaps a cross-reference in the /lpi and /lgi options. (But, more likely, described immediately after it, in the hope people using one option would notice the other.) This is the problem with the help file: it is not a tutorial, more a reference manual, and it is really unhelpful if you don't know what you want to do in the first place. And of course PSWBTM is not mentioned at all. There really should be a PSWBTM tutorial...

[Alex Guerrero]

Hi H. Muller.

Would you like test this miniprogram?

http://www.orbitfiles.com/download/id3224139640.html

I might do additions easily...

[H.G.Muller]

Well, quite frankly and bluntly: no, sorry. I already have too little time to test the modifictions I make to WinBoard properly, and am largely dependent on other testers to spot bugs.

I am sure you will be able to find other people here willing to test it. And if you need special features in WinBoard to make it work better, you can request them here. Then I will see what I can do, and if I succeed in adding what you need, you can download the latest WinBoard alpha version and test it yourself (and complain if it doesn't). That seems a more sensible distribution of workload.