1
2
This is the longest mate ever in 524 moves. can any engine find that???
8/1r6/8/6n1/5k2/1b6/3K3N/7Q b - - 0 0
I doubt it very very very much.
Perhaps 6men tablebases help on this one.
ya
its from 6 men table base. correctly says mate in 524.
its from 6 men table base. correctly says mate in 524.
> its from 6 men table base.
I see 7men.
sorry Its from 7 men TBS
:-)
:-)
I do not see 7 men
The queen at h1 is a female so she is not a man.
The queen at h1 is a female so she is not a man.
According to the following site the longest win found using a 7 piece table base is 517.
http://www.gothicchess.com/javascript_8x8_chess_endings.html
It has the 517 win on the site.
Brish
http://www.gothicchess.com/javascript_8x8_chess_endings.html
It has the 517 win on the site.
Brish
> 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.
Not sure about current theory, but back in the early to mid 90's, someone published an insanely long mate. Forget if it was over 300 moves, or over 500 moves, but in any event, the mate was actually solved in reverse. The progammer took a known mate position, then used retro analysis to find out the what position on the board could occur, in which it would take the most number of moves to solve the known mate.
I heard rumours that KBNK on a 10x10 board would take over 10,000 moves to win. Haven't checked it myself, though.
Er, isn't that exactly how all tablebase mates are solved?
The question should be how much time do engine need to find the draw.
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.
Uri
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.
Uri
ya. u are correct.
You may be surprised to find the tablebases going against the 50 move rule and proclaiming mate in 72 without any pawn on board or material capture. I witnessed this in one of the engine matches at playchess.com about a week ago. I later checked with my own tablebases (5-men complete) and it declare the same mate in 72.
I am not surprised and I know that tablebases are wrong.
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)
Uri
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)
Uri
From what I understand, tablebases are pretty much just a hash of data in which every known position of a particular endgame has been predetermined. As far as I know, its the engine that has to take that information and use it according to the rules of chess.
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."
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 :-)
http://www.youtube.com/watch?v=wxIaMcO2amE
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)
Oh my good big war in the table i long time im not see this end game....:)
Thx for post
Thx for post
you r too late to answer.
you mean nobody is allowed to find bad mistakes in "old" posts (especially yours...)?
without tablebases it would be at least 20 yrs before an engine could see this through mate at that position which would mean literally processor speeds 1000x faster than they are now or about 10 Thz.
How you can be sure then it position isn't draw?!
I have decided to verify that and I have found a longer mate (well, it was rather hard calculation - it took almost 12 hours).
In DTM metrics, my checkmate is 545 moves (513 moves before conversion).
Here it is.
Moves are in attached file.
In DTM metrics, my checkmate is 545 moves (513 moves before conversion).
Here it is.
QN4n1/8/3k4/8/b1K5/8/8/6r1 b - -
Moves are in attached file.
Attachment: 04.09.2009_kqnkrnb.txt - The longest mate - kqnkrnb (6k)
Attachment: blog.aqs - Visualisation (241k)
Cooooooooooool
Thanks!!!!
Thanks!!!!
Many thanks for this!
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?
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?
I think you were confused by Generated by Aquarium phrase. Only the nice output was produced by Aquarium, but the endgame was generated by special software.
I understand - the special software like used in SETI project. It will be good to join people from the forum and with 1000 computers we will have all 7-piece endgames in a month. In a year or two - 8-piece endgames will be available so.
it's NOT the longest mate because there are many instances where White could have won a lot faster!
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
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
Yes, you are right, Black's moves are incorrect in several cases. It's a mistake when producing the line, I will fix and recalculate it - maybe in a couple of days. Thank you for the report.
But the initial value seems to be right - 545 moves until checkmate.
But the initial value seems to be right - 545 moves until checkmate.
Some engines stop its search immediately the moment it finds mate without bothering to look further for shorter variation. I believe 545 is the machines initial finding. Maybe if allowed to think longer it will produce different result with much shorter variation.
It's position from endgame database and therefore it's the exact result. No longer thinking is needed: there are no variations left.
Here is a new line (I have fixed the output).
There was the problem that output procedure ignored conversions to minor endgames.
There was the problem that output procedure ignored conversions to minor endgames.
The start position is symmetrical to the previous position.
Thanks again! With the exclamations it is much better.
What is the exact meaning of !
1) The only move to win
or
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).
What is the exact meaning of !
1) The only move to win
or
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).
Currently, the exclamation means the only move to win.
I think that most of White's moves are the only moves for the shortest mate. It would be too many exclamations.
Good point. I will remove unneeded exclamations. Thanks.
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.
Some words about 7-men tables which I am generating.
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.
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.
Are your tables in Nalimov format? If no are they larger than Nalimov ones? And what's the size of table with 545 moves mate? Thank you!
The tables are not in Nalimov format.
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).
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?
The tables are quite accessible in a packed format, but they may be slower than Nalimov tables (due to higher compression rate).
All 6-men tables takes ~1.2 Tb. What you mean kqnkrbn 1.2Tb???
It is 7-men tablebase
(kqnkrbn is
king+queen+knight play against king+rook+bishop+knight).
1.2 TB = 600GB positions (2 bytes per position). Everything is quite logical.
(kqnkrbn is
king+queen+knight play against king+rook+bishop+knight).
1.2 TB = 600GB positions (2 bytes per position). Everything is quite logical.
Number of positions for 7-men table is
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
so on..
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.
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
so on..
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.
what Tb is king + rock + pawn +pawn vs king + rock + pawn?
1
2
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill