Shogi

[hgm]

I just noticed that Lima has an engine-defined option "Ponder". What is the idea of that? It doesn't seem to be enabled by default, and Lima doesn't seem to ponder in ponder-on games.

[hgm]

I guess a more efficient history implementation for drops would be to just keep those with the best history scores (say some 20 in regular Shogi) in a sorted linked list. So that you only have to run through that list in order to generate the drops. (Which follows in a straightforward way from the pieces you have in hand, and whether the target square is empty.) The remaining drops could be in a conventional history table, linked in an unsorted way. Each time a cutoff increases the history value over that of the last element in the sorted list, you can clip off the last element (and append it to the unsorted list), and sort the new one in between. (This comes in the place of sorting the moves in each node, and only has to done rarely, when you have a cutoff by a drop that makes the top-20.)

[Ferdy]

I just noticed that Lima has an engine-defined option "Ponder". What is the idea of that? It doesn't seem to be enabled by default, and Lima doesn't seem to ponder in ponder-on games.

That option was not tested so far, so by default it is not enabled. There is indeed a problem when it is enabled. I will try to fix it, if not I will remove that option. I will be sending my last engine update within 11/21.

[Ferdy]

BTW, I just sent a WinBoard package to Takeshi Ito, with the latest Lima (I used the 64-bit popcount version; I assume they will use modern computers) and Shokidoki. It still includes the old TJshogi5x5 and Nebiyu. I don't know if Daniel has registered for the tourney.

Thanks, may I know what version of winboard is in the package?

[Evert]

It is hard to make an eval that spontaneously builds a decent castle. Against other engines it is also not very helpful, as the strong ones are based on tons of knowledge. So if you build a proper castle, they will know very well how to dismantle it. If it looks more like a pile of rubble, however, they don't know what to make of it either. They evaluate your position as very bad, but cannot really exploit that.

That's very interesting. It means that their evaluation doesn't actually "understand" the essential aspects of what makes a position good, and it doesn't really understand what steps help to dismantle a castle. It just has a library of patterns that it matches against.

I guess orthochess programs used to have such hard-coded patterns also, back in the day. It makes sense if search is not very deep, and you have to rely more on human knowledge and understanding. Pattern matching is of course what human brains do well.

Shokidoki scores some 20-25% against SPEAR in regular Shogi, and in all games SPEAR's score quickly rises to +8, just because of the difference in caste quality it percieves. But then it can still lose. I got the impression that SPEAR's superiority is more because it has a good 'tsume solver' which sometimes sees very deep mates, that that its positional eval really helps.

I certainly have the impression that mate-threats and mate-searches help a lot more in Shogi than they do in orthochess. I've seen the score tip very quickly from +20 or so to -mate-in-two a couple of times (of course the mate gets picked up sooner than that, since the program starts spite-drop-checking pieces well before the mate score gets backed up to the root).

[hgm]

BTW, I just sent a WinBoard package to Takeshi Ito, with the latest Lima (I used the 64-bit popcount version; I assume they will use modern computers) and Shokidoki. It still includes the old TJshogi5x5 and Nebiyu. I don't know if Daniel has registered for the tourney.

Thanks, may I know what version of winboard is in the package?

WinBoard 7.3.2. I did not bother to replace the winboard.exe in last year's package.

[Ferdy]

BTW, I just sent a WinBoard package to Takeshi Ito, with the latest Lima (I used the 64-bit popcount version; I assume they will use modern computers) and Shokidoki. It still includes the old TJshogi5x5 and Nebiyu. I don't know if Daniel has registered for the tourney.

Thanks, may I know what version of winboard is in the package?

WinBoard 7.3.2. I did not bother to replace the winboard.exe in last year's package.

I have done the debugging on Winboard 4.7.2c. Ponder is fixed now, just doing some more testing, should be ready by tomorrow.

I got weird behaviour during debugging, with this winboard version, it will send new without force command after engine restart because the user pressed file->new game in the gui.

Code: Select all

[...]
8756 >first : quit
shuffleOpenings = 0
StartChildProcess (dir=".") Lima_v1-38-x64-popcnt.exe
[...]
9272 >first : new
[...]
9272 <first &#58; feature done=0
9272 >first &#58; accepted done
9272 <first &#58; feature ping=1 time=1 setboard=1 name=1 colors=1 debug=1, nps=0
9272 >first &#58; accepted ping
9272 >first &#58; accepted time
9272 >first &#58; accepted setboard
9272 >first &#58; accepted name
9272 >first &#58; accepted colors
9272 >first &#58; accepted debug
9272 >first &#58; accepted nps
9272 <first &#58; feature draw=0 sigint=0 sigterm=0 reuse=0 analyze=1 ics=1
9272 >first &#58; accepted draw
&#91;...&#93;
10804 >first &#58; d1c2
10804 >first &#58; go
&#40;extra&#41;
&#91;...&#93;

Since there is no force command and it received a move, and it also received a new command before, now it will start to think or look for book moves. After sending its reply, the engine now will go to ponder mode, but it received a go command so it will exit ponder mode and now will search for a move that is not his turn to move, so Lima is out of sync now.

I initially solved this by noting how many go command I received. It worked.
Later when I disabled most of my printf("# ...\n"); debugging stuffs, I no longer received a go command.

[hgm]

This is indeed a bad WinBoard bug that had to do something with the implementation of the GUI book, that it thinks it has to activate the engine with a 'go' when getting out of book, but that this is not true if it is already out of book on the first move. But I remember having fixed that. I checked it again to make sure, and it seams I included WinBoard 4.7.3a in the package I sent to Takeshi Ito. (The installer said 4.7.2, but I probably did forget to update it there when I forged it ino the UEC7 installer script, but did replace the winboard.exe. The Help-About in the UEC8 package says 4.7.3a, and I tested all engines would run in it under tournament conditions.)

[Ferdy]

This is indeed a bad WinBoard bug that had to do something with the implementation of the GUI book, that it thinks it has to activate the engine with a 'go' when getting out of book, but that this is not true if it is already out of book on the first move. But I remember having fixed that. I checked it again to make sure, and it seams I included WinBoard 4.7.3a in the package I sent to Takeshi Ito. (The installer said 4.7.2, but I probably did forget to update it there when I forged it ino the UEC7 installer script, but did replace the winboard.exe. The Help-About in the UEC8 package says 4.7.3a, and I tested all engines would run in it under tournament conditions.)

Tested 4.7.3a and it send new then force, so go after a move is not a problem anymore. I have to use this gui for testing.

[hgm]

Well, in any case you should not use 4.7.2 (probably this bug was the reason to release 4.7.3 as a fix). But why not use 4.8.0, which is the latest?