1
2
> king + rock + pawn
Do you mean rock + paper + scissors?
Can paper and scissors mate a king?
No, the rock crushes the king, the king subjugates the pawn, and the pawn mines the rock.
Even with rock it is krppkrp.
BTW, endings with pawns are much more dificult to generate because of all promotions should be considered, i.e. adequite tablebases should be generated.
BTW, endings with pawns are much more dificult to generate because of all promotions should be considered, i.e. adequite tablebases should be generated.
Thanks for the math!
Think about economy.
As I understand you need 64 bits (2bytes *32bits) for every position. But you need not store draw positions. Send positions with mate in 1 to the first file, with mate in 2 - to the second and so on. You need not store draw positions. So you will need 2 times less space (even more for some endings).
With modern 64-bit computers you may save one position even in 1 byte. So 2 times less space for 64-bit computers.
Think about economy.
As I understand you need 64 bits (2bytes *32bits) for every position. But you need not store draw positions. Send positions with mate in 1 to the first file, with mate in 2 - to the second and so on. You need not store draw positions. So you will need 2 times less space (even more for some endings).
With modern 64-bit computers you may save one position even in 1 byte. So 2 times less space for 64-bit computers.
1. It's obvious you have no idea what you're talking about (or you're trolling).
2. byte = 8 bits.
Only the results are stored, not the positions.
2. byte = 8 bits.
> You need not store draw positions.
Only the results are stored, not the positions.
Great post, Andy! 8)
But forget about about your math and 64-bit computers. Most modern now are quantum computers. One quantum bit is much larger than usual bit :). As well you may use some space between quantum bits :).
Wait for some time. When these computers will be commercilally available 7-men tablebases should be quickly calculated.
But forget about about your math and 64-bit computers. Most modern now are quantum computers. One quantum bit is much larger than usual bit :). As well you may use some space between quantum bits :).
Wait for some time. When these computers will be commercilally available 7-men tablebases should be quickly calculated.
Due to disk space problems, I am now thinking about porting the code to Turing machine, there is enough space to store everything. :)
Searching a position value in such storage would be terrific problem.
It's more efficient to store a table of values than a table of positions.
Does 1 Terabyte HDD double its capacity when we put it from 32-bit computer into a 64-bit one? :)
It's more efficient to store a table of values than a table of positions.
Does 1 Terabyte HDD double its capacity when we put it from 32-bit computer into a 64-bit one? :)
Terrific!!!
1TB is for one ending. It is $100. So it will be $100 000 for all endings. Now I understand your problems with disk space. Looks like we need 10 years more to have 7-piece endings available for own analysis. Sorry, I was very naive at my first posts.
1TB is for one ending. It is $100. So it will be $100 000 for all endings. Now I understand your problems with disk space. Looks like we need 10 years more to have 7-piece endings available for own analysis. Sorry, I was very naive at my first posts.
Storage is an issue for 7-men TBs, but currently expected figures are not so bad.
Firstly, krbnkqn is 1.2 TB unpacked. With proper compression algorithms, its size should drop to 200-300 GB at most.
Secondly, this tablebase has been generated in Distance to Mate (DTM) format. DTM is the best metric for most practical purposes but also the greediest in space storage. There are other formats available : Distance to conversion (DTC), Distance to zeroing (DTZ / DTZ50) for endings with pawns, and win-draw-lose (WDL) tables sometimes referred as “bitbases”. Approximate size expectations for a full set of 7-men TBs (all 4 vs 3 and 5 vs 2, for a total of 875) are (compressed) : 160 TB in DTM, 60 TB in DTZ, 12 TB in WDL. Still a big deal, but more manageable especially if thought in terms of progressive work, focused first on lightest metrics, partial sets (ex : pawnless 4 vs 3 first) and most interesting endings.
Getting a full DTM krbnkqn in 12 hours only is impressive performance.
Firstly, krbnkqn is 1.2 TB unpacked. With proper compression algorithms, its size should drop to 200-300 GB at most.
Secondly, this tablebase has been generated in Distance to Mate (DTM) format. DTM is the best metric for most practical purposes but also the greediest in space storage. There are other formats available : Distance to conversion (DTC), Distance to zeroing (DTZ / DTZ50) for endings with pawns, and win-draw-lose (WDL) tables sometimes referred as “bitbases”. Approximate size expectations for a full set of 7-men TBs (all 4 vs 3 and 5 vs 2, for a total of 875) are (compressed) : 160 TB in DTM, 60 TB in DTZ, 12 TB in WDL. Still a big deal, but more manageable especially if thought in terms of progressive work, focused first on lightest metrics, partial sets (ex : pawnless 4 vs 3 first) and most interesting endings.
Getting a full DTM krbnkqn in 12 hours only is impressive performance.
> Getting a full DTM krbnkqn in 12 hours only is impressive performance.
Thank you.
And what were your expectations of the time? :)
Expectations from mark&yakov's work back in 2006 were several days or even weeks rather than several hours for a single TB such as krbnkqn on a standard high-end computer (which may be not your case). Your results are more than 10x improvement. This is very good news as it makes mass 7-men generation possible, congrats !
Incredible!! Do you have a link to what is known (longest mates, longest conversion) for various 7 piece endgames?
I have checked the position suggested by Mark & Yakov.
And I have found out that there also exists mate in 545 moves, but DTC in my line is shorter than in Mark's (514 and 517). So both sides are right.
And I have found out that there also exists mate in 545 moves, but DTC in my line is shorter than in Mark's (514 and 517). So both sides are right.
Well, I decided to check other endings of Yakov&Mark. This night it was krrnkrr. The work was not so hard as previous time.
(2.5 hours for krrnkrr ending plus about hour for minor endings that were not generated before).
My program confirmed that in Yakov&Mark position
mate is given in 296 moves.
But it offered another way to mate with DTC=285 instead of Yakov&Mark DTC=290. That is logical. I don't search the largest DTC.
As well a new position with longer mate was found with mate in 304 (DTC=288)!
This is logical too. 6 moves to mate after the conversion for the Yakov&Mark position is evidently too short. For longest DTM Black should try to transform to the postion with longest 6-men mate (may be with slightly less 7-men DTC). For my position White needs 17 moves to mate after the conversion.
It is funny that final mate is in the center of the board.
PGN files are attached (krrnkrr_dtm296.pgn, krrnkrr_dtm304.pgn). Let me know if visualization on the board is essential, so I will attach it too.
Next endings will be
1) KQBN-KQB
1k6/1b5q/N7/8/8/1Q6/8/B1K5 b - -
Yakov&Mark claim 330 moves DTC
2) KQBN-KQN
Nqn3k1/8/8/Q7/8/8/8/1K2B3 w - -
Yakov&Mark claim 317 moves DTC
Then I will need a pause to solve the problems with disk space. If the disk space problem will be solved I start systematic generation.
(2.5 hours for krrnkrr ending plus about hour for minor endings that were not generated before).
My program confirmed that in Yakov&Mark position
r7/5r1N/8/8/8/6R1/6R1/3K1k2 w - -
mate is given in 296 moves.
But it offered another way to mate with DTC=285 instead of Yakov&Mark DTC=290. That is logical. I don't search the largest DTC.
As well a new position with longer mate was found with mate in 304 (DTC=288)!
r5R1/5r1N/8/8/8/8/6R1/3K2k1 b - -
This is logical too. 6 moves to mate after the conversion for the Yakov&Mark position is evidently too short. For longest DTM Black should try to transform to the postion with longest 6-men mate (may be with slightly less 7-men DTC). For my position White needs 17 moves to mate after the conversion.
It is funny that final mate is in the center of the board.
PGN files are attached (krrnkrr_dtm296.pgn, krrnkrr_dtm304.pgn). Let me know if visualization on the board is essential, so I will attach it too.
Next endings will be
1) KQBN-KQB
1k6/1b5q/N7/8/8/1Q6/8/B1K5 b - -
Yakov&Mark claim 330 moves DTC
2) KQBN-KQN
Nqn3k1/8/8/Q7/8/8/8/1K2B3 w - -
Yakov&Mark claim 317 moves DTC
Then I will need a pause to solve the problems with disk space. If the disk space problem will be solved I start systematic generation.
Attachment: krrnkrr_DTM304.pgn (5k)
Attachment: krrnkrr_dtm296.pgn (5k)
Are you 100 % sure then white win in these positions? What is DTC??
DTC = Distance to conversion.
There is reasonable level of confidence that these results are valid.
First of all they fully coincide with previous results received by Yakov and Mark for DTC metrics.
Second the algorithm may test itself in a lot of situations. A bug at some iteration will lead to the program crash at the next iterations. So if the program is ended and displayed a valid line there is 99,9% probability that everything is ok.
First of all they fully coincide with previous results received by Yakov and Mark for DTC metrics.
Second the algorithm may test itself in a lot of situations. A bug at some iteration will lead to the program crash at the next iterations. So if the program is ended and displayed a valid line there is 99,9% probability that everything is ok.
Thanks very much for posting these positions. These long mates are truly amazing! Any predictions as to when the full set of 7-man tablebases will be complete?
I can't predict time. May be it is possible to finish the project in 2 years - may be it will take more time. With hard efforts it can be done earlier. All this depends of a lot of factors - having disks, having interest to this and so on. Program may still have bugs in it and debugging may take a lot of time. Although the principal problems seem to be resolved there are known issues for improvements.
It is very hard project and it will demand much energy.
It is very hard project and it will demand much energy.
Thanks. Two years is much faster than I would have expected. I imagine that because of the storage requirements, it will be 10 years or so before they are in common use.
I agree, we can't expect that in nearest years 7-men tables will be in common use. The only reasonable way may be on-line access to some server.
When you made 7 MEN tablebase? 2010?
I doubt about posibility to finish in 2010. As for 2011 - may be. But problems on the way may seriously delay this date.
So only 2012-2015 may be promissed with good probability.
So only 2012-2015 may be promissed with good probability.
Take it easy. How you made it? With 1 computer or with 1 program? How I can find mate for ex. in this position
What program work this?
3K4/8/5k2/N4pp1/4b3/8/8/6R1 b - - 0 2
??What program work this?
I don't know any program that can solve this for now.
I hope I will be able to solve the position some time later. But it will require generating of ~16 pawnless 7-men endgames. Currently I cannot start generating them because I have no space to store them.
I hope I will be able to solve the position some time later. But it will require generating of ~16 pawnless 7-men endgames. Currently I cannot start generating them because I have no space to store them.
> It is very hard project and it will demand much energy.
If it can be of some help to you, please know that a year ago in ccrl tablebase forum in this thread http://kirill-kryukov.com/chess/discussion-board/viewtopic.php?f=6&t=3748 there were extensive discussions about what a mass 7-men generation strategy should be. Some key topics were : computing times, expected sizes of finished TBs in different metrics, gradual approach / partial sets strategies within constrained CPU power and disk space, pros/cons of different metrics for different types of users... . Being aware of this before proceeding to mass TB generation might be valuable especially if disk space is not suitable for housing full 7-men TB in DTM/Nalimov format (expected to be 150-200 TB). Note that disk space issue made DTM not the recommended metric, but there are also ideas about how to proceed with DTM if it is what is wanted.
Very interesting link, thank you very much.
Sorry, under time preassure I published the line that is not full for the first position. It was ended with conversion to 4 piece ending. Really mate in this line is only one halfmove less than in the second position and may be considered as mate in 304 white moves too.
I added moves and re-attached the pgn-file.
I added moves and re-attached the pgn-file.
Nice work.
do you chekmate rybka 3 in this positon in 304 steps?
I think it would be much faster than 304 moves.
I cannot verify it right now, though.
I cannot verify it right now, though.
Generation of kqbnkqb took more than 8 hours.
Mate in 345
The results coincide with Yakov and Mark. My program has offered another position, but agreed that Yakov&Mark's leads to the longest mate too. I am not sure how many moves until checkmate there are in their line.
1k6/1b5q/N7/8/8/1Q6/8/B1K5 b - -
Mate in 345
The results coincide with Yakov and Mark. My program has offered another position, but agreed that Yakov&Mark's leads to the longest mate too. I am not sure how many moves until checkmate there are in their line.
Attachment: kqbnkqb_dtm345.pgn - PGN (5k)
I don't believe in this. This is j@ck
kqbnkqn endings demanded more research than I expected.
The line offered by Yakov&Mark is mate in 350 by DTC. (see kqbnkqn_Yakov.pgn attached)
I was able to get only mate in 335 moves by DTM (see kqbnkqn_dtm335b.pgn attached).
I didn't like the fact that DTC line is longer, so I decided to consider lines more carefully.
First of all I made modifications to allow generation of DTC tables. This was quite easy. Then I ran generation of DTC kqbnkqn tablebase. It was more than 2 times faster than DTM (possibly with optimizations even more speed up may be achieved).
It was quite pretty to see that my DTC-generation program exactly confirmed every move in Yakov&Mark's line, i.e. every move in line was optimal by DTC.
So I checked positions in DTC line with DTM table. And I found a lot of positions in this ending where the best move by DTC is not optimal by DTM.
For example in this position in Yakov's DTC line (before 313.Qd3)
DTC gives "9 half-moves to conversion" and then mate in 33 moves (65 halfmoves) by 6-men tablebases. Totally 74 halfmoves.
DTM gives "15 half-moves to mate" (all 7 pieces remain on the board). It is very short mate and may be checked by Rybka even without 7-men tablebases.
(See visualization kqbnkqn.aqs)
So both tables look ok. And I think that due a lot of mate posibilities this ending is very good for finding diferences between DTM and DTC tables.
For now I've finished comparison of DTC and DTM long mates. After number of tests I am more or less sure that the program works Ok.
As result interesting comparison of different endings with DTM and DTC metrics was received. For some endings lines are very similar, for some endings they are different.
For now I will take a break before October when I am going to start more systematic generation.
Nqn3k1/8/8/Q7/8/8/8/1K2B3 w - -
The line offered by Yakov&Mark is mate in 350 by DTC. (see kqbnkqn_Yakov.pgn attached)
I was able to get only mate in 335 moves by DTM (see kqbnkqn_dtm335b.pgn attached).
I didn't like the fact that DTC line is longer, so I decided to consider lines more carefully.
First of all I made modifications to allow generation of DTC tables. This was quite easy. Then I ran generation of DTC kqbnkqn tablebase. It was more than 2 times faster than DTM (possibly with optimizations even more speed up may be achieved).
It was quite pretty to see that my DTC-generation program exactly confirmed every move in Yakov&Mark's line, i.e. every move in line was optimal by DTC.
So I checked positions in DTC line with DTM table. And I found a lot of positions in this ending where the best move by DTC is not optimal by DTM.
For example in this position in Yakov's DTC line (before 313.Qd3)
8/K3B3/8/1QN5/8/2k5/2n3q1/8 w - -
DTC gives "9 half-moves to conversion" and then mate in 33 moves (65 halfmoves) by 6-men tablebases. Totally 74 halfmoves.
DTM gives "15 half-moves to mate" (all 7 pieces remain on the board). It is very short mate and may be checked by Rybka even without 7-men tablebases.
(See visualization kqbnkqn.aqs)
So both tables look ok. And I think that due a lot of mate posibilities this ending is very good for finding diferences between DTM and DTC tables.
For now I've finished comparison of DTC and DTM long mates. After number of tests I am more or less sure that the program works Ok.
As result interesting comparison of different endings with DTM and DTC metrics was received. For some endings lines are very similar, for some endings they are different.
For now I will take a break before October when I am going to start more systematic generation.
Attachment: kqbnkqn_Yakov.pgn (4k)
Attachment: kqbnkqn_dtm335b.pgn (6k)
Attachment: kqbnkqn-1.aqs (94k)
Thanks. It has been fascinating to follow your progress. I look forward to seeing you continue this work.
Thanks! Very interesting research!!!
Sorry me for invalid bit counting. I considered that progress from 8-bit computers to 64-bit is not only in speed of calculation.
Don't you consider to calculate DTC-tables instead of DTM-tables? You will reach the success twice faster. For sure we will see silly but successful lines in the tables like one you just pointed. But nothing wrong with this. Then you may calculate perfect DTM-tables.
Sorry me for invalid bit counting. I considered that progress from 8-bit computers to 64-bit is not only in speed of calculation.
Don't you consider to calculate DTC-tables instead of DTM-tables? You will reach the success twice faster. For sure we will see silly but successful lines in the tables like one you just pointed. But nothing wrong with this. Then you may calculate perfect DTM-tables.
Thanks for this.
I am happy my post guided u towards this.
Regards
Om
I am happy my post guided u towards this.
Regards
Om
so great. this geniality with the computer. this helps us. now i think it should by modificated the fifty moves low. it shows it is possible to win the other positions longer tnan in fifty moves no pawn moves and no piece changes not only without position with two knight vs. one pawn, which is special, in 100 moves. it will be interesting ni chess lows. maybe in world norm using new temp of playing (for example in master of world championship) is ,or will be, used computers to detect way to win and modify conventional laws. i enjoy it, future.
Once I get more storage I am looking at exploring deep mating postions to see how the theory compares with brute force.
I need spectacular amounts of storage for 7 pieces, 50 of those new 2TB disks is barely enough.
http://contract-developer.tk
I need spectacular amounts of storage for 7 pieces, 50 of those new 2TB disks is barely enough.
http://contract-developer.tk
1
2
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill