Fairy-Stockfish 10.3 released

[hgm]

I will look into it tomorrow.

[hgm]

OK, I made an attempt. I could not reproduce the case where Windows actually informs me through a popup that WinBoard had crashed. But when I tried to load Fairy-Stockfish 10.3, WinBoard was just hanging waiting for the engine to be loaded. It was still sensitive to a 'quit' signal, though. When I tried it with -debug, a winboard.debug file was created. This showed the 'feature variants="..."' command, but not the 'feature done=1' that unconditionally should have been sent after it, before it logged the 'quit'. Running UCI2WB from the command-line, though, does print the done=1.

So it seems that the long variants feature upsetted WinBoard enough to ignore any further input from the engine. If I modified UCI2WB to clip the variants list at 200 char, everything works normally. (Except that of course many variants cannot be played.)

So I recompiled WinBoard with the standard text-buffer size set to 1024 instead of 512. Then Fairy-Stockfish 10.3 started normal too. I expect this to also solve the crash problem. I put the winboard.exe and UCI2WB.exe with the enlarged buffers in a new package at http://hgm.nubati.net/WinBoard-AA.zip . Let me know if there are still problems.

[George Tsavdaris]

OK, I made an attempt. I could not reproduce the case where Windows actually informs me through a popup that WinBoard had crashed. But when I tried to load Fairy-Stockfish 10.3, WinBoard was just hanging waiting for the engine to be loaded. It was still sensitive to a 'quit' signal, though. When I tried it with -debug, a winboard.debug file was created. This showed the 'feature variants="..."' command, but not the 'feature done=1' that unconditionally should have been sent after it, before it logged the 'quit'. Running UCI2WB from the command-line, though, does print the done=1.

So it seems that the long variants feature upsetted WinBoard enough to ignore any further input from the engine. If I modified UCI2WB to clip the variants list at 200 char, everything works normally. (Except that of course many variants cannot be played.)

So I recompiled WinBoard with the standard text-buffer size set to 1024 instead of 512. Then Fairy-Stockfish 10.3 started normal too. I expect this to also solve the crash problem. I put the winboard.exe and UCI2WB.exe with the enlarged buffers in a new package at http://hgm.nubati.net/WinBoard-AA.zip . Let me know if there are still problems.

Wow that was quick.
Yes now it works perfectly as of now with Fairy-SF largeboard 10.3.
Many thanks once again!!

[George Tsavdaris]

......

Fairy Stockfish largeboard 10.3 works now on Winboard with HGM's modification but there is another problem now.

Fairy Stockfish largeboard 10.3 lost on time in a 5'+3"(5 minutes+3 seconds/move) game. In fact it didn't obey the time control at all!
It was a Capablanca random Chess game with a predefined Gothic Chess position and a small 5 moves opening, with Fairy Stockfish largeboard 10.3, 8 cores versus older Fairy Stockfish largeboard 10.2, 8 cores.

Unfortunately 10.2 proved stronger and won with black(i will play later the reverse) but the main issue was that 10.3 lost on time. Game continued though and 10.3 seemed to not care about time control.
Probably a bug with time management?
10.2 played well inside time control and handled the time control nicely as always anyway since i had played much more games with it in the past and never had time issues!

Here is the game where you can see the issue:
https://www.youtube.com/watch?v=hk8R8jk4-jk

[Fabian Fichter]

......

Fairy Stockfish largeboard 10.3 works now on Winboard with HGM's modification but there is another problem now.

Fairy Stockfish largeboard 10.3 lost on time in a 5'+3"(5 minutes+3 seconds/move) game. In fact it didn't obey the time control at all!
It was a Capablanca random Chess game with a predefined Gothic Chess position and a small 5 moves opening, with Fairy Stockfish largeboard 10.3, 8 cores versus older Fairy Stockfish largeboard 10.2, 8 cores.

Unfortunately 10.2 proved stronger and won with black(i will play later the reverse) but the main issue was that 10.3 lost on time. Game continued though and 10.3 seemed to not care about time control.
Probably a bug with time management?
10.2 played well inside time control and handled the time control nicely as always anyway since i had played much more games with it in the past and never had time issues!

Here is the game where you can see the issue:
https://www.youtube.com/watch?v=hk8R8jk4-jk

I doubt that there is a problem with time management, since the time management did not change between 10.2 and 10.3. Furthermore, on variantfishtest and locally I can let it play thousands of games in dozens of variants (including capablanca) with cutechess GUI and CLI without any time losses.

Do you use the same settings for both versions? If you encounter time losses, you can try to increase the move overhead (on Windows better set it to at least 1000 to be safe). However, this is more related to the OS and is nothing that is specific version 10.3.

Drawing conclusions about playing strength from one game is not better than a coin toss. Compared to the around 50,000 games I used in total for regression testing of the 10.3 release it sounds a bit premature (or shall I say ridiculous) to claim a regression after one game... However, I only did limited testing for capablanca chess specifically (in-depth testing of all ~60 variants would just be way too much), so I can not exclude that it still might be slightly weaker than the older version in a few variants.

[hgm]

This is not a move-overhead issue. The video shows that it overruns its time by dozens of minutes.

Please try again with the extra WinBoard option -debug, and post the winboard.debug file this will create here. (Or the part of it around the point where it forfeits, if it is too big to post it all.)

[George Tsavdaris]

I doubt that there is a problem with time management, since the time management did not change between 10.2 and 10.3. Furthermore, on variantfishtest and locally I can let it play thousands of games in dozens of variants (including capablanca) with cutechess GUI and CLI without any time losses.

That is very strange then.
I have played some 80-100 games with older versions. First time this(a time loss) had happened so since it's a new version i had to conclude that should be 10.3 specific.

Do you use the same settings for both versions? If you encounter time losses, you can try to increase the move overhead (on Windows better set it to at least 1000 to be safe). However, this is more related to the OS and is nothing that is specific version 10.3.

Yes same settings.
I will play more games and see if this will occur again.

Drawing conclusions about playing strength from one game is not better than a coin toss. Compared to the around 50,000 games I used in total for regression testing of the 10.3 release it sounds a bit premature (or shall I say ridiculous) to claim a regression after one game...

I did not do anything of the above. I just wanted newer to win I'm extremely very well aware of the small sample size.
EDIT: Hmm i see i used the words "proved stronger". Well i did not meant it that way. I meant for the specific game.

[George Tsavdaris]

2nd game went more normal even though Fairy Stockfish largeboard 10.3 was spending much more time than 10.2 but it didn't lose on time this time.
I don't know if it would lose and was saved by the draw.

Game was SF Fairy 10.2 8 cores versus SF Fairy 10.3 8 cores(the reverse of 1st game with the time loss) in the same as before Gothic Chess position with fixed opening line by me.
That was an interesting game in the end where SF 10.3 sacrificed a Bishop, a Rook and it's Archbishop to obtain a draw!!

https://www.youtube.com/watch?v=h4oQyGTddbo

[George Tsavdaris]

OK, I made an attempt. I could not reproduce the case where Windows actually informs me through a popup that WinBoard had crashed. But when I tried to load Fairy-Stockfish 10.3, WinBoard was just hanging waiting for the engine to be loaded. It was still sensitive to a 'quit' signal, though. When I tried it with -debug, a winboard.debug file was created. This showed the 'feature variants="..."' command, but not the 'feature done=1' that unconditionally should have been sent after it, before it logged the 'quit'. Running UCI2WB from the command-line, though, does print the done=1.

So it seems that the long variants feature upsetted WinBoard enough to ignore any further input from the engine. If I modified UCI2WB to clip the variants list at 200 char, everything works normally. (Except that of course many variants cannot be played.)

So I recompiled WinBoard with the standard text-buffer size set to 1024 instead of 512. Then Fairy-Stockfish 10.3 started normal too. I expect this to also solve the crash problem. I put the winboard.exe and UCI2WB.exe with the enlarged buffers in a new package at http://hgm.nubati.net/WinBoard-AA.zip . Let me know if there are still problems.

In this new Winboard there must be something broken with the edit position command.
While in edit position mode in the new Winboard when i right click i get nothing(a note message) while in the old i got the drop down menu.

[hgm]

Well, what is broken is that the notice window doesn't adapt to the size of the message, like it does in XBoard. Otherwise this was an intentional change to a method of setting up positions that works better across all variants. The notice was supposed to explain how that worked:

Code: Select all

		DisplayNote(  _("To edit the position you can:\n"
				"* Move pieces around with left mouse button\n"
				"* Copy pieces by moving with Ctrl key pressed\n"
				"   OR by starting the move with a double-click\n"
				"* Click a K, R or P a second time to toggle its rights\n"
				"* 'Lift' a piece with right-click for multi-dropping\n"
				"* Drop a piece of the lifted type by left-click on empty\n"
				"* Right-click on empty to finish dropping\n"
				"* Adjust the type of a dropped piece by clicking it again\n"
				"* Click the active clock (repeatedly) to clear the board\n"
				"* Click the inactive clock to change the side to move"));

The idea is that you first click the blackened clock twice to obtain a 'palette board', which contains every piece type exactly once. (First click would show a board with only Kings.) This is intended to be the pictorial equivalent of the piece menu. You can select the piece type you want to drop by right-clicking it, and then cleft-click all squares where you want to put it.

You can also simply drag the pieces to their intended squares (or off board when you don't need that type). If you need several copies you keep Ctrl pressed during the move to copy rather than move.