For me, a draw score is not worth much without knowing why the position is drawn. "I looked this position up in a multi-gigabyte file, and it says it's a draw" isn't a very useful explanation. I haven't looked at Timman's study, but because it's composed by a human, I suppose it is possible for a human player without the help of a computer to find the solution. If my program fails to solve such a problem, and I understood the solution, I would try to identify what knowledge my program is missing and add it to my search or evaluation function. This is harder work than simply adding tablebases, but also much more valuable: I may end up dicsovering principles and evaluation rules which can be applied to a wider range of positions with a bigger number of pieces, and I may improve my own chess knowledge at the same time.
For the engine which is about to lose the endgame,knowing about draw score is as good as a win.
Endgame studies are focused on deriving rules that are useful for _humans_ to improve their endgame
play. If you insist on knowing how the WDL is arrived , you should use DTM tablebases.
You can't program most of what is found by some KD technique from tabelbases to benefit the engine,
especially _not so in the evaluation function_, as you seem to suggest. The eval already has a good enough
predictor for the final result, so to improve it you need to do more than weights or whatever.
Most of the moves involve maneuvers (tactical) that just can't be programmed there.
Ok may be you can for some endgames with 5 or less pieces, but it is impossible for most 5 piece and
above endgames without using some sort of search. Most of what is stored in bitbases are _exceptions_, the
rest are really compressed well. Those difficult positions are for humans to discover and enjoy themselves
with. My point being, the tbs are large because they have to. That ofcourse depends on what kind of information
you want from it.
I may end up discovering principles and evaluation rules which can be applied to a wider range of positions with a bigger number of pieces,
and I may improve my own chess knowledge at the same time.
Yes you may, but not something that would be useful for your engine.
For instance how do you program the KBBKN mate in 78 to your engine
so that it would benefit from it. Even for the much simpler KBNK we have to use some table along with _search_ to drive the king to corners. Even with that my engine used to fail mating kbnk! Most of these involve manuevers which are caught with search , and if you have to do search you loose the whole point of having bitbases.
I think just blindly using tablebases as giant lookup tables during the search is quite ugly and stuipd, and likely to be counter-productive in the long run. The right way to use them is probably as a testbed for high-level evaluation routines, or even for generating new high-level endgame heuristics programmatically. Using genetic programming to develop endgame evaluators using tablebase positions as a test suite would be a very interesting project, for instance.
GAs use weighing factors to give you an approximate eval. So again they will have difficulties to catch tactical issues. Most of what is found by a GA is stored compressed really well. I tried Knowledge discovery to derive rules for endgame to no avail. I then added 1 or 2 ply search on top of it, to get better improvements on 4 men, but it barely improved the 5 men size. The knighdreamer guys have also got the same results. IMHO, trying to predict the score without doing search is just worthless.
About the significance of bitbases, I believe they are important. A 200MB 5 men bitbase on RAM surely brings some improvement immeasurable or not.
