The tablebase is showing the wrong order. The correct order should be winning, drawing, losing.

[akaKarthick]

The tablebase is showing the wrong order because it is using the distance-to-zero (DTZ) metric. The DTZ metric is a measure of how many moves it takes for a side to win or draw a game. A lower DTZ value means that it takes fewer moves to win or draw.

However, the tablebase is showing the losing position first, followed by the drawing position, and then the winning position. This is the wrong order, because the winning position should always be shown first.

However, the DTZ metric does not take into account the fact that some positions are easier to win than others. For example, a position where White has a checkmate in two moves is much easier to win than a position where White has a drawing position.

I mean winning in 2 moves is better then losing in 1 move or drawing imediatly.

In order to correctly show the order of the positions, the tablebase should use a different metric that takes into account the difficulty of winning or drawing a position.

Just like Chess.com

[czbar]

The order of win/draw/loss was incorrectly inverted when Black was on move. I have just fixed that.

As for the bigger picture:

• within the win/draw/loss parts of the table, ChessForge just reports the results from lichess API, in the order that lichess puts them in.
• lichess orders the solutions by DTM (moves to mate), not DTZ, first. Note that DTZ is not "a measure of how many moves it takes for a side to win or draw a game" but rather moves to zeroing i.e. capture, pawn move, mate, stalemate.
• chess.com does things really strangely (incorrectly, in my opinion). In my test position it says at the top "DTZ 1" which is irrelevant (DTZ is moves to capture here) and does not show DTM which is what the user cares about. Their ordering seems wrong too (it is not by DTM).

Test position:

lichess (and therefore ChessForge)

Chess.com

As for "a different metric that takes into account the difficulty of winning or drawing a position." I see 2 issues here:

• what would that metric be?
• and more importantly, is that really what the user wants? To my mind, tablebases are there to offer the "absolute truth" hence should be presented "mathematically", so to speak, with no regard for how difficult the solutions are.

What do you think?

[akaKarthick]

I apologize for my comment. I misunderstood your points about tablebases and the DTM and DTZ metrics.

I apologize for the confusion. I am still under development, and I am always learning. I appreciate you taking the time to correct me. I will be more careful in the future to make sure that I understand the points you are making before I raise new issue.

I also agree with your point about the "absolute truth" of tablebases. They are a mathematical representation of the game of chess, and they should be presented as such.

"The order of win/draw/loss was incorrectly inverted when Black was on move. I have just fixed that." This is what i intented to convey. 🙂

[czbar]

Oh, no need to apologize at all! Your comments are super helpful, and I enjoy replying to them whether I agree with them or not. Don't hesitate to send comments/issues even if you are not sure if they are correct. At the very least they make me review the logic, and in most cases the issues you are raising absolutely do need fixing.

[akaKarthick]

Here is one more. But dont know how to describe this issue.

https://youtu.be/F3da4-G1KMA

[czbar]

Good find! I was able to reproduce, and the fix is trivial. The program crashed internally (it is protected from actually crashing) due to a rogue line of code that shouldn't be there. Fixed in the next version :)

[akaKarthick]

Kb2 is losing move for black in quick way right? Ka2 is losing in few more moves extra.

so Ka2 should be in first. right?

I think something wrong with engine in excercise. see https://youtu.be/rA1xvv3qxXQ

or am i missing anything?

Chessforge:1.1.3.0 Stockfish 16, 16-Dev

[akaKarthick]

This is the initial position of excercise. Black to move. All four possible moves tells white is winning in force.

Black played one of the losing move (long). But Still white have force mate.

But engine suggest the losing move for white. In this position Two possible move for White. One is winning in 37 move(forced). Another one is losing in 17(forced).

[czbar]

Had some trouble reproducing but I finally managed to do it in a slightly different position (I guess the behaviors here depend on the processors of our PCs). And yes, the behavior of Leela forced me to implement engine line sorting in Chess Forge (rather than relying on the engine's output order as I did when I only worked with Stockfish) and I haven't got that ordering quite right yet.

[akaKarthick]

https://drive.google.com/file/d/1i5JhvP2xnzbu4nr5ZslRCxMfDw_RZaal/view?usp=sharing excercise no 32.

my pc have 6 core, 12 logical processor.

it is fixable issue right?

[akaKarthick]

if we have discussion btn like this i can clarify my doubts here.

[czbar]

It is certainly fixable. I had trouble reproducing because Stockfish on my laptop does not calculate to the checkmate in some of those positions. And currently, I am on a 6-month around-the-world trip and only have a laptop to work on :)

As for "Discussions", sure, we can try using that too.

[akaKarthick]

Nice

[czbar]

Ok, I think I have fixed this now. But please re-test when I publish the next version (1.1.4).

As usual, I'll make a comment in one of the issues when I publish the new version so that you know.