Banksia GUI released

[AdminX]

Version 0.25 beta released

* Fixed bugs: almost all known bugs, such as database converter missing scores, French language not working
* Some small improvements/adjustments: such as being changeable toolbar background color, changeable threshold for score indicator
* New features:

• Lichess bot back to work

• Embedded chess SVG pieces

• Opening book converter

• Support developers: 1) understanding UCI position command (position starts/fen moves) when pasting; 2) easily run benchmarks or frequently commands (Fig)

Fig. Run benchmark or any commands in an easy way

Excellent news! Thank you very much for this update. Testing it on Lichess now with my NeuralAbyss bot account.

[AdminX]

LiChess Bug Report:

Last move not being relayed to LiChess. I had two games that ended in Draws on LiChess because the Mating move was not relayed to LiChess yet it was displayed in the Banksia Gui.

[Ras]

I didn't follow up whether that's already implemented, but here's an idea to work around a common problem with CECP engines: that neither the sign of the evaluation nor the mate scores are defined on protocol layer so that each CECP engine can do something different.

When loading a new CECP engine for the first time, the GUI could transfer a mate-in-2 position. The position should have enough pieces to avoid EGTBs kicking in, and the mate should be super straight-forward so that no pruning will miss it. The solution move should be the only reasonable move so that no confusion can arise.

Let the engine determine the best move plus score. Make the move that the engine suggests, make the opponent's answer move so that it's mate-in-1, and let the engine give the best move (also only one reasonable option) plus score.

Then repeat the whole position with reversed colours.

That would allow to determine both the sign and the mate scores automatically. Then this should be stored (per engine of course) because there are engines that need to be restarted for a new game.

Here's an example position:

[d]6k1/ppqn1rpp/1np4b/3Q4/2BP4/1P1N4/P3rPPP/6K1 w - -

And with reversed colours:

[d]6k1/p3Rppp/1p1n4/2bp4/3q4/1NP4B/PPQN1RPP/6K1 b - -

[hgm]

Note that CECP actually does define a standard mate score:

Mate scores should be indicated as 100000 + N for "mate in N moves", and -100000 - N for "mated in N moves".

But of course older engines do not comply with this. What you propose IMO goes way to far in the direction of allowing engines to remain non-compliant.

[Ras]

What you propose IMO goes way to far in the direction of allowing engines to remain non-compliant.

The CECP ecosystem is FUBAR anyway so that it's just about damage control.

[phhnguyen]

LiChess Bug Report:

Last move not being relayed to LiChess. I had two games that ended in Draws on LiChess because the Mating move was not relayed to LiChess yet it was displayed in the Banksia Gui.

Thanks a lot for the report. I have been working on that

[phhnguyen]

I didn't follow up whether that's already implemented, but here's an idea to work around a common problem with CECP engines: that neither the sign of the evaluation nor the mate scores are defined on protocol layer so that each CECP engine can do something different.

When loading a new CECP engine for the first time, the GUI could transfer a mate-in-2 position. The position should have enough pieces to avoid EGTBs kicking in, and the mate should be super straight-forward so that no pruning will miss it. The solution move should be the only reasonable move so that no confusion can arise.

Let the engine determine the best move plus score. Make the move that the engine suggests, make the opponent's answer move so that it's mate-in-1, and let the engine give the best move (also only one reasonable option) plus score.

Then repeat the whole position with reversed colours.

That would allow to determine both the sign and the mate scores automatically. Then this should be stored (per engine of course) because there are engines that need to be restarted for a new game.

Here's an example position:

[d]6k1/ppqn1rpp/1np4b/3Q4/2BP4/1P1N4/P3rPPP/6K1 w - -

And with reversed colours:

[d]6k1/p3Rppp/1p1n4/2bp4/3q4/1NP4B/PPQN1RPP/6K1 b - -

It is a very clever idea!!! Thanks a lot!

You are right, BSG has some difficult to detect mate scores for Winboard engines. I will test/implement it.

[phhnguyen]

Note that CECP actually does define a standard mate score:

Mate scores should be indicated as 100000 + N for "mate in N moves", and -100000 - N for "mated in N moves".

Interesting, I missed that info. Just curious:
- why not smaller ranges, say 10000 or 32000 (2 bytes score): look like many engines use smaller ranges
- why not 100000 - N and -100000 + N: they are easier to compare

But of course older engines do not comply with this. What you propose IMO goes way to far in the direction of allowing engines to remain non-compliant.

Don't worry, recently new CECP engines are so few, we can ask them to comply one by one

PS: I found that mate-score standard on GNU page only, your page (http://hgm.nubati.net/CECP.html) as well as some other pages are not updated, that is why I have totally missed it

[hgm]

Good point. I really should update that page. The idea was that eventually it should replace the old specs document, but somehow this development got stalled.

As to your questions:

The score was intentionally chosen outside the 16-bit range, because many old engines already fully use that range, and their scores could then be wrongly interpreted as mate scores.

100000+N directly shows the DTM, because even GUIs that do not implement this standard would show something like 1000.12 for a mate in 12. (GUIs that do know the standard would probably want to print something like #12 or M12.) With 100000-N the user would have to subtract, which I at least have always found very annoying. It is of course not the intention that engines would use these scores internally, anymore than that UCI engines should use a string variable for their scores in order to handle the "score mate 12" in their output. They are expected to use whatever numerical mate score they like in their search (usually in the 16-bit range), and when they send the PV to the GUI compute the DTM from that, and then print it in the format prescribed by the protocol.

[phhnguyen]

Good point. I really should update that page. The idea was that eventually it should replace the old specs document, but somehow this development got stalled.

As to your questions:

The score was intentionally chosen outside the 16-bit range, because many old engines already fully use that range, and their scores could then be wrongly interpreted as mate scores.

100000+N directly shows the DTM, because even GUIs that do not implement this standard would show something like 1000.12 for a mate in 12. (GUIs that do know the standard would probably want to print something like #12 or M12.) With 100000-N the user would have to subtract, which I at least have always found very annoying. It is of course not the intention that engines would use these scores internally, anymore than that UCI engines should use a string variable for their scores in order to handle the "score mate 12" in their output. They are expected to use whatever numerical mate score they like in their search (usually in the 16-bit range), and when they send the PV to the GUI compute the DTM from that, and then print it in the format prescribed by the protocol.

Do you know the percentage (roughly) of CECP engines supported (correctly) that standard of mate scores? If they are the major, all are almost done. I prefer the easy way. Otherwise, we still need to apply some clever methods (such as one proposed by Ras) to detect mate score ranges for individual engines.