Ed Gilbert wrote:Hi Gerard,
Yes, I understand and I think your idea fits nicely with mtd search. My point was that for smaller dbs I thought you got about a 25% reduction in size (compared to mine) by not storing draws, but for the 4x4 and 5x3 subsets it looks like the difference is much smaller, ~5%.
-- Ed
The main explanation is certainly the fact that I count twice the db 0044, 1133, 2222, 3333, 4444. By removing this doublon I can gain 20,2Gb => total size = 326Gb.
In addition I give up some optimisations I made because it was not a good compromise between the size of the db and the number of access to the db. It will be clear with an example:
Let's take the 2132db with the following counters win=1 949 052 171, draw=59 850 673 173, loss=84 285 824 514
With my previous implementation and in order to optimize the size of the db I would here have build one db for the winning positions and one db for a draw positions => 1 949 052 171 + 59 850 673 173 positions stored in the db
The drawback is the following : if I reach a position in this db with an mtd-f test value = -100 I need two db access if the position is a losing position.
To avoid this I decided to not optimise the disk size in order to assure in all cases only one access disk. To achieve this the two db I really built in that case are the following :
1) the winning positions = 1 949 052 171 stored
2) the non-losing positions = 1 949 052 171 + 59 850 673 173 stored
With these two db you can see that I store twice the 1 949 052 171 winning positions but I am sure to have only one access disk to satisfy the need of the mtd-f algorithm
I am now quite happy with the result because
1)I can really reduce the size of the db to 326db
2)I always assure only one access disk to satisfy the mtd-f algorithm need
3)I certainly can quite double the number of positions stored in memory by storing only the relevant information
