Hello,
-- Introducing myself --
I'm new on this site, so I want to shortly introduce myself. and my opinions about computer chess.
I'm a pure amateur chess player following more or less closely the development of computer chess, engine competitions and specific engine problems relating to chess since 1984. My main source of references is the german CCS (I joined in 1984-85 with interuptions) and my personal insight of working methods of chess engines. I'm not a coder, but i'm only concentrating on the results a chess engine may output. About these results, my opinion is: yes, it's interesting to make engines compete with each other, but I think they are all strong enough already to make this a significant endeavor. It would be more lucrative for the developers, instead of trying to gain some additional +50 ELO with a new version, to implement some really useful features for game analysis for the human chess player. The strongest top 50 engines have very little useful features in this regard. The exceptions are Deep Shredder (user-interactive learning positions can be stored to tell the program that a position is weak/strong/drawish); Rybka (Monte Carlo analysis); and that's it ! Simply keeping the hashtables will not get the job done for a serious analysis, because all (stupid) variations must be played to fill the hash and get the picture to the engine. I think the time of a serious human player can be better spent. So, for the developers there's still A LOT to do, not having anything to do with the pure chess strenght in ELO (for a good analysis tool, I don't care if it's top 10 rated or top 100: It's about carrying out a good analysis, or being able to work TOGETHER with the human player. The sum of the forces will be stronger than the single parts.)
-- end of introduction --
Currently I'm interested to find out how EGTBs influence the engine^s work. What is the balance as for loss of performance in the algorithm and knowledge won by the engines because of using 4-5-6-men EGTBs? How can engines handle incomplete EGTBs? How can EGTBs be modified to give the human player a useful basis for analysis? This last point is important because I'm not interested to know that a kqpknnp can win in exactly 74 moves, but I'm rather interested in a tree showing me a win in 140 moves, but outlining me a clear procedure!
Sorry for this long diatribe. Now my questions. I'm using Nalimov's version 4.00 x64 generator for 4-5-6-men, and the datacomp.exe for compressing / decompressing EGTBs. I know how to use these tools. I have a modest Intel Core i5 (4 cores) with 8GB RAM and have already built 4-men and the most important combinations for 5-men. Now, what are the memory requirements in RAM and disk space for starting the generation of a single 6-man? Is my computer system far behind the requirements (I have 673 GB of Hard Disk left) ?
Thanks very much for your patience in reading and for your feedbacks!
XenonS
Newbie question about building single 6-men
-
h.g.muller
- Posts: 223
- Joined: Mon Feb 19, 2007 8:24 am
- Sign-up code: 0
- Location: Amsterdam
- Contact:
Re: Newbie question about building single 6-men
I see no one has reacted to your posting for months. I can't help you with the Nalimovs; I never used those.
You raise an interesting point about end-game tables: the information they contain is not very helpful to humans. There is little logic in the shortest lines of play they imply, and if there is, there isn't any automated way to extract that knowledge from them. Even the statistics is very misleading. It is for instance very hard to see if an end-game has fortress draws. It is also very hard to translate the EGT into an algorithm for playing the end-game such as a decision tree.
When humans learn an end-game they tend to think in terms of sub-goals. The only analog to that which is in common use in EGTs is the 'sub-goal' of capturing a piece, or zeroing the 50-move counter (DTC or DTZ), often with ridiculous play as a consequence.
Like you mention, to find the fastest path to mate is not really of practical interest to the human Chess player. Who cares if I need 20 moves to win KQK, while it could have been done in 8? In bullet games doing it in 20 moves without the need to think is preferable to wasting time on trying 'to be clever'.
Many end-games have 'bottle necks', i.e. a manageably small set of positions through which you have to pass in order to reach the goal. The lines suggested by the EGT are so complex because the EGT tries to exploit all positions in the bottle neck to find the fastest path to the goal, depending on which of them is nearer to the current position, and how far the goal is away from it. As a human you would be better off just singling out one of the bottle-neck positions, and always first go there (or step directly on a path from it to the goal), even if that means a detour compared to some quirky short-cut through one of the other positions in the bottle neck.
Building an EGT that uses a metric based on such 'milestones' should certainly be possible, but it is difficult to extract suitable milestones.
You raise an interesting point about end-game tables: the information they contain is not very helpful to humans. There is little logic in the shortest lines of play they imply, and if there is, there isn't any automated way to extract that knowledge from them. Even the statistics is very misleading. It is for instance very hard to see if an end-game has fortress draws. It is also very hard to translate the EGT into an algorithm for playing the end-game such as a decision tree.
When humans learn an end-game they tend to think in terms of sub-goals. The only analog to that which is in common use in EGTs is the 'sub-goal' of capturing a piece, or zeroing the 50-move counter (DTC or DTZ), often with ridiculous play as a consequence.
Like you mention, to find the fastest path to mate is not really of practical interest to the human Chess player. Who cares if I need 20 moves to win KQK, while it could have been done in 8? In bullet games doing it in 20 moves without the need to think is preferable to wasting time on trying 'to be clever'.
Many end-games have 'bottle necks', i.e. a manageably small set of positions through which you have to pass in order to reach the goal. The lines suggested by the EGT are so complex because the EGT tries to exploit all positions in the bottle neck to find the fastest path to the goal, depending on which of them is nearer to the current position, and how far the goal is away from it. As a human you would be better off just singling out one of the bottle-neck positions, and always first go there (or step directly on a path from it to the goal), even if that means a detour compared to some quirky short-cut through one of the other positions in the bottle neck.
Building an EGT that uses a metric based on such 'milestones' should certainly be possible, but it is difficult to extract suitable milestones.