its from 6 men table base. correctly says mate in 524.
> its from 6 men table base.
I see 7men.
The queen at h1 is a female so she is not a man.
It has the 517 win on the site.
> According to the following site the longest win found using a 7 piece table base is 517.
With "win" defined as either mate or a winning conversion. Black isn't mated in the final position of that one.
mate in 524 is equivalent to draw thanks to the 50 move rule and if you search 100 plies forward then you find the draw.
The question was not about tablebases but about engines so you should not give engines tablebases and maybe the engines can see the draw if they search 100 plies forward with no pruning(but I suggest not to wait for it to happen)
I'd think in a properly coded engine, it would indeed (in this case), correctly identify a mate in 72, but when the 50th move is actually made, thats when the 50 rule move would actually kick in.
Engines make a move, then go through a checklist to see if the move causes a known "flag" in programming parley in which the game would end: draw by lack of material, draw by repetition, draw from 50 move rule, checkmate, stalemate, clock flag down (for either or both sides), etc.
You also have to understand that tablebases mearly report the longest possible mate given perfect play from a given position. Engines aren't written to assume best play: in fact, after each move they pretty much look at the board as if it was new. Sure they have deep thinking, and can keep thousands of individual lines in a hash table (ram) in order to cut down on searching, but once they move or the opponent moves, its like they never really played that last move. They look at the hash table and say something to the effect "OMG look at all these cool lines I don't have to recalculate.. sweet.. I'll just start searching lines not in the hash table."
> This is the longest mate ever in 524 moves
Where did you see that? It's simply wrong!
I just looked at that again.
Actually Marc Bourzutschky et Yakov Konoval only say that there is a win on the 517th White move(by capture of the the Black rook - using the DTC metric: distance to conversion to a simpler ending, here 6-man EGTB).
Nobody has found the shortest mate (using the DTM metric: distance to mate)
In YouTube somebody showed a "Mate in 524", with a nice dramatic music :-)
but the last 8 moves (after the capture on move 518) to reach mate are being helped by Black sub-optimal moves.
With black optimal moves (and the corresponding 6-man EGTB), the mate only occurs 10 moves after the capture, on move 526!
But this is just the shortest mate after the QxR capture.
It does not mean there can't be a shorter mate, directly (although maybe, not very likely)
Thx for post
In DTM metrics, my checkmate is 545 moves (513 moves before conversion).
Here it is.
Moves are in attached file.
It is hard to beleive that there is some logic to apply for finding such a sequence of moves for the mating.
And sorry, I am a new user.
I don't see endgame generation function in my Aquarium Basic. Did I miss something? Or I need another version of Aquarium?
For example at moves:
142 NxR! could have ended the game in far fewer moves.
230 Qxd3!+ surely wont reach 545 moves and
232 Qxd3!+ also is fast
But the initial value seems to be right - 545 moves until checkmate.
There was the problem that output procedure ignored conversions to minor endgames.
What is the exact meaning of !
1) The only move to win
2) The only move for the shortest mate
I would like to suggest
! - The only move for the shortest mate
!! - The only move to win
There is no need in exclamation if only one move exists in the position (like 157.Kg3! in your line).
I think that most of White's moves are the only moves for the shortest mate. It would be too many exclamations.
> There is no need in exclamation if only one move exists in the position (like 157.Kg3! in your line).
Good point. I will remove unneeded exclamations. Thanks.
At the moment, all 3-4-5-men endgame tables has been generated and verified. Some test 6-men tables with pawns has been also generated, but not verified yet (the main purpose was to ensure that 7-men tablebases can be generated).
The main current problem is insufficient disk space.
If anybody is interested in a pawnless 7-men position, let me know - I will calculate it.
They a smaller: all 5-men tables takes 4.8 GB (packed).
The unpacked size of kqnkrnb table is 1.2 TB.
> They a smaller: all 5-men tables takes 4.8 GB (packed).
That is very impressive compared to the 7+ GB for the Nalimov.
Is the packed format just for storing them, or can they be accessed by your program in packed format?
king+queen+knight play against king+rook+bishop+knight).
1.2 TB = 600GB positions (2 bytes per position). Everything is quite logical.
64*63*62*61*60*59*58 /8 *2 = 800 000 000 000 = 800 GB
64 squares for 1st piece
63 squares for 2nd piece and
we may divide 8 due symetry
and we must multiply 2 due side to move
If programmer can exclude impossible positions (like two kings together) he can operate with less number. So 600 GB positions (1.2TB unpacked data) is quite logical.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill