/* Steinar */
Queen is certainly a female so by definition 6-man or 7-man tablebases cannot include KQP vs KQP positions.
But man (also chess-man) means piece not only male human being. It is used to for draughts and backgammon too
Ancient quotes in the OED:
c1460 (?c1400) Tale of Beryn 1821 Comyth nere! Ye shul se..How he shall be matid with what man me list
1474 CAXTON Chesse I. iii, The table of the chesse borde and the chesse meyne.]
I suppose we should say 6 or 7-men not man
> why 6-man or 7-man and not 6-piece or 7-piece?
> Queen is certainly a female so by definition 6-man or 7-man tablebases cannot include KQP vs KQP positions.
Oh Master Blass you are killing me now :-D LOL
Sometimes political correctness goes over the top and gets it wrong!
> Queen is certainly a female
not sure...."she" has never gone through an DNA gender test
Also note that they would require huge hard disks with several terrabytes.
Why double r in terrabytes? This used to be a joke about computer amateurs in Berlin magazine "TIP" or maybe just part of Latin memory!?
Terabytes of disk space are quite cheap nowadays - so if they existed ... ??
I guess noone here has several 100 TB disk space
But maybe not. Imagine a person with 32-man tables playing someone with 31-man tables. The whole strategy for the former would be to avoid a capture that could lead directly to a draw or loss. That would be quite a trick--there probably is not such a move!
One would imagine that if seven-piece tablebases did indeed become a reality, it would hopefully be in a format where you wouldn't have to load indexes for days first :-)
Honestly I'm a bit surprised nobody has really started defining a format for 7-man bitbases yet and tried pushing it public, but perhaps the gain is simply too small. When did the last 6-man bases become public? 2003?
/* Steinar */
/* Steinar */
> adding a piece using an nth degree polynomial equation.
I think you need to look up http://en.wikipedia.org/wiki/Generating_polynomial
just add the pieces to the the tablebase array using the above function for each added piece and in this example, a rook. difficult much?
Those is simply no connection between the 6-man tablebases and 7-man tablebases and there is no possibility of generating one from the other.
Remember also that the 3-4-5-man bases occupy about 6 GB (I can't remember the exact figure) and the complete 6-man bases are over 1 TB - the 7-man bases going to take a lot of generating and they are not going to be small! The generation process is quite simple and it has been described in many articles - it is just very very slow, even on a very fast machine.
Also remember that if you want the tablebase KPPP v KPP you first need the tablebases in which all the pawns have all possible promotions, for example you require KQQR v KBN etc. You also need all the 6-man tablebases, since a single capture results in a 6-man ending!
The first one I'd get is the KQQKQQ, because it was used in the Deep Blue/Kasparov match in the 90's. LOL. Not sure, but that might have been the only 6 man tablebase used in the match. Dunno why, other than the programmers wanted to make sure that if it came up, the machine wouldn't blunder.
Nowadays, chess engines are much more elegent, and don't need to rely on brute force so much. Of course, using more processors/cores would add to its overall strength.
> Only because they don't have 5-1 tablebases out, in which case I would urge you to get KQQQQK.
LOL Even Rybka might be able to win that endgame without tablebase assistance
/* Steinar */
> (In other words, you would never, even if you wanted to, put one of the queens unprotected and next to the enemy king.)
Stalemate is always possible (or you'll start getting impossible positions --- I mean, positions where you can't even reconstruct the last pair of moves).
Or positions where the last move is a promotion-mate. I suppose that would make it impossible to draw. :)
It is true that an experienced person can write a 7-men tablebase generator in one-two days. The only problem with such a program is that it either will work for ages (using disk all the time) or will need about 3 TB RAM (and then it will be several times quicker). 3 TB RAM is 1000 times more than a modern PC has. Fortunately, it is possible to implement slicing, i.e. splitting the tables to the parts that do not much depend on each other.
The major tricks in 7m generation are connected with optimizations in speed, RAM and final table size on the disk. There are trivial optimizations like considering symmetries, there are average optimizations like compression, slicing tables in the limited RAM, and there are huge optimizations for significant reducing number of operations and dimensions. These significant optimizations are the key for the solution of the problem in reasonable time.
Usually different optimization targets contradict each other. For example for reducing dimensions it is logical to exclude impossible positions. So the program will need less memory and disk size. It is easy to discover that two kings can’t be in touch with each other. But it is not easy to exclude the positions where on the white move the white queen attacks the black king. Discovering king capturing and proper indexing slows down the program several times and adds years to the final date.
So developers frequently have not-pretty choice between reducing dimensions and raising calculation time. I believe that there were many developers who started their own generation project (the initial idea of how to generate is quite simple). But most of them quickly understood that there is no universal trick to avoid huge complexity of chess endings for modern computers.
We should not forget that sizes invoke major technical problems with debugging (imagine program failure after a month of calculations), hardware stability, verification, backups and so on. The developer should devote significant part of his life for the solution of the Problem. For my estimation, Nalimov worked 15 years for his 5 and then 6-men tables. Not everyone is ready to make such big efforts for such a long period.
And surely a cost of hardware is significant. So the entering fee is expensive.
Some known large-dimension problems were solved using distributed calculations. Unfortunately 7-men generation process can’t use the technique of distributed calculations with many networked computers. Having some 7-men position you may need to know evaluation of any position in the current ending (and in the minor endings). The theoretical number of 7-piece positions with the pawns is about 2,500,000,000,000 ( = 64*63*62*61*60*59*48). So you need 5TB to manage them. Now you can understand that the programmers need think thoroughly about every decision they make in their program.
BTW, Nalimov opened his code for operating with 6-men tablebases. But he didn’t make public the generation program. For my opinion there was a lot of different tricks in his code. And these tricks were not the best part of the code. Possibly he even didn’t have universal program but generated special programs for different classes of endings. (Sorry, this is just some thoughts, not the facts.)
So after reading of all this you may understand why the progress of 7-men generation is not well visible. Only one brave and successful group is well-known: Yakov Konoval and Mark Bourzutschky. But there is no reliable information what progress is achieved and what is estimated time for finish. The only thing that is clear from announced generation time that their algorithm is better than Nalimov’s one.
And finally let’s imagine that 7-men tablebases has been generated. The lower estimation for their size in compressed form is 100 TB. I believe that one useful ending like KRPPKRP will demand hundreds of gigabytes on disk. Is anybody ready to download such data and to keep this on the disks? Only a few persons in the world may have hardware that will allow them to use 7-men in engine search. So the only way of using the tables is on-line access via web-services.
It is too early to wait 7-men tables for everyday life. It is too early even to speak about standards for TB7-access and to ask about engine support of them.
/* Steinar */
1. In this modern era there is massively parallel computing! The data could be retrieved/"mined" and stored on "web-service".
2. The data could be massively indexed (and perhaps put into only small (<5MB) files).
3. People with broadband connections speed, when get close enough into endgames (eg. within 1-2 material of Endgame (probably preferably Bit) Bases), could then query for evaluations or send for the solutions files themselves in the background and store only temporarily on users drive. In games with long enough time controls this might work!
Parallel Computing links interest:
note: quasi-computing/large-scale distributed computing/"embarassingly" parellel computing: http://en.wikipedia.org/wiki/Supercomputer
Theoretically at least, these could solve ALL your logistical problems (wrt Hardware and Time)!!
2) I am afraid that this will not work for endgames. Dimensions essential for endgame analysis are very high.
> 2) I am afraid that this will not work for endgames. Dimensions essential for endgame analysis are very high.
Supposedly is known what likelihood of winning is for that material and could be reported to engine from far horizon for positional evaluation from knowning known endgame on Quasi-"Super"Computer and information could be then transferred with very low dimensions. Perhaps. (Obviously a big project.)
Perhaps option in Aquarium (and could perhaps try to team-up with Chessbase as well) to allow background work on Endgame Tablebases. I have "655 GB free of 931 GB" on my own Harddisk. I may install some games later, but you could use eg. upto 200GB (that's 1/5th of Terabyte right there! ) (if I wasn't installing games, I might have let you use 500GB!! 0.5TB ) of mine I suppose toward your hardware requirements on solving Endgame Tablebases. JUST when using engine, we get cpu @ 100% for analysis when playing/analyzing for our own positions. Background = for @ night or just leaving computer running. With enough participants, I suppose high-end tablebases could be done very quickly. Maybe participants get premium membership @ playchess.com or something?!
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill