hgm wrote:Well, 7-men tablebases are not that hard to calculate, and certainly calculating one locally would be much faster than any attempt to download it. It just requires a dedicated 1TB disk, 3GB of memory, and a few days of CPU time (per end-game).
It is just that it is not clear what you should do with it after you calculated one. It would require way too much storage to go on calculating more, and collect them all. On-line consulting of tablebases as a sort of cloud-computing project is pretty useless for letting an engine use them in search; it is way too slow.
Maybe language problem, but can you translate what you mean in something up to the point and intelligible?
hgm wrote:It is just that it is not clear what you should do with it after you calculated one. It would require way too much storage to go on calculating more, and collect them all. On-line consulting of tablebases as a sort of cloud-computing project is pretty useless for letting an engine use them in search; it is way too slow.
I mostly agree, but it might be possible to compress the win/draw/loss results into 10 TB or less, which would fit on 2 or 3 hard drives. That's almost manageable. If those are accessed during the search, it would be fine to access the DTM results online. (Or even better, generate them in DTZ, throw away redundant information and they'll fit in about 10 TB as well.)
hgm wrote:Well, 7-men tablebases are not that hard to calculate, and certainly calculating one locally would be much faster than any attempt to download it. It just requires a dedicated 1TB disk, 3GB of memory, and a few days of CPU time (per end-game).
It is just that it is not clear what you should do with it after you calculated one. It would require way too much storage to go on calculating more, and collect them all. On-line consulting of tablebases as a sort of cloud-computing project is pretty useless for letting an engine use them in search; it is way too slow.
Another problem is that in order to calculate something like KPPP vs. KPP you would first need to calculate every other 4+3 combination possible.
"Tactics are the bricks and sticks that make up a game, but positional play is the architectural blueprint."
Why not take out all draw positions and just store wins/loses? This should dramatically reduce the size. If the position not found in TB...then its draw.
That is not how EGTs work. They always contain every position with the same number of bits. If they didn't you would not know where to find the info about a given position. Unless you would store information from which the position could be recognized, which usually requires ~10 times as many bits as just storing the result.
Albert Silver wrote:Another problem is that in order to calculate something like KPPP vs. KPP you would first need to calculate every other 4+3 combination possible.
That is not really true. Typically KQPPKPP and KPPPKQP would be enough to decide >99% of all KPPPKPP positions. The number of positions that are only winnable by going through KQQQKQQ will be astronomically small. And most of them would be completely non-sensical positions, i.e. positions that are not reachable except by grossly stupid play from both sides. Positions with a large number of simultaneous promotions can only be expected from positions with all Pawns on the forelast rank. The Pawns could not all have reached that rank in the same move, meaning that both side would have had to intentionally decline promotion to advance another Pawn from 6th to 7th, while the opponent was already on 2nd with one of his Pawns. It is very hard to believe this could ever be optimal play. Normally you promote to Q at the first opportunity you get, and then start to worry about advancing your other Pawns.
@ hgm. I was referring to reducing the size of TB and not calculating them.
Let's say I download the entire 7 piece TB somehow. I remove all the entries that are considered draw. Then I compress just the win/loss on to disc(s)...so an engine looks up a position that has 7 pieces...if it can't find the position, then it implies that its a draw.
So there should be no reason to store the draw positions...
voyagerOne wrote:@ hgm. I was referring to reducing the size of TB and not calculating them.
Let's say I download the entire 7 piece TB somehow. I remove all the entries that are considered draw. Then I compress just the win/loss on to disc(s)...so an engine looks up a position that has 7 pieces...if it can't find the position, then it implies that its a draw.
So there should be no reason to store the draw positions...
It's not only about knowing if it's draw, but to know how to get it too. But your idea could be another efficient way to use TBs that could fit some needs.
voyagerOne wrote:Why not take out all draw positions and just store wins/loses? This should dramatically reduce the size. If the position not found in TB...then its draw.
So, how are you going to encode that a particular position is "not" in the TB?
A TB is just a long long long sequence of numbers, one number for each position. An index function determines how a position is mapped to a number in this long long long sequence. You can't just take out numbers, because that will completely screw up the indexing.
In general, you can't remove non-redundant information without losing it.
A TB is not a text file with on each line a fen string. This is probably how you think of it, but it is not how it works. It would terribly inefficient to store a TB that way.
Albert Silver wrote:Another problem is that in order to calculate something like KPPP vs. KPP you would first need to calculate every other 4+3 combination possible.
That is not really true. Typically KQPPKPP and KPPPKQP would be enough to decide >99% of all KPPPKPP positions. The number of positions that are only winnable by going through KQQQKQQ will be astronomically small. And most of them would be completely non-sensical positions, i.e. positions that are not reachable except by grossly stupid play from both sides. Positions with a large number of simultaneous promotions can only be expected from positions with all Pawns on the forelast rank. The Pawns could not all have reached that rank in the same move, meaning that both side would have had to intentionally decline promotion to advance another Pawn from 6th to 7th, while the opponent was already on 2nd with one of his Pawns. It is very hard to believe this could ever be optimal play. Normally you promote to Q at the first opportunity you get, and then start to worry about advancing your other Pawns.
I don't understand your post. You are saying you would not have any TB entries for KPPPKPP?
"Tactics are the bricks and sticks that make up a game, but positional play is the architectural blueprint."
