Banksia GUI released

[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.

[AdminX]

Feature request:

This GUI already provides alot, so I don't know if it is possible to ask for more. How difficult would it be to implement a personal "Engine Cloud" type of feature whereby one could use their more powerful system running Banksia and have it communicate with Banksia running on a weaker machine from a remote location? Chessbase does this as a service via the "Cloud", however I doubt that the cloud may even be needed for this to work.

[hgm]

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.

I really have no idea. These days I hardly bother with Chess engines at all, I am doing almost exclusively variants.

My policy is "never try to correct engine defects in the GUI". In the long run this will just be detrimental for everyone. It perpetuates faults, erodes standards. If one GUI accepts crap from the engine, engine authors will think they have the right to make a mess of it, and will start to complain against developers of other GUIs that their crap doesn't work there too. Before you kno it there will be an avelanche of crap. I consider it immoral to encourage that.

If engines do not print the standard mate score, just show what they print, and let the user do the calculation. If it annoys the user, let him complain to the engine developer.

[Ras]

If engines do not print the standard mate score, just show what they print, and let the user do the calculation. If it annoys the user, let him complain to the engine developer.

That's not how a good UI works. The only effect would be that users avoid CECP engines. Also, your idea doesn't work, or else the problem would have been long gone.