Breakthrough Draughts

[BertTuyt]

3x11 also confirmed.

Bert

Code: Select all

Verify:3x11 Start, P = 19.514.811.840
4878.1 3x11, P = 19.514.811.840, NCW = 1.227.707.632, E = 0

[TAILLE]

3x11 also confirmed.

Bert

Code: Select all

Verify:3x11 Start, P = 19.514.811.840
4878.1 3x11, P = 19.514.811.840, NCW = 1.227.707.632, E = 0

Last weekend I corrected another bug but since the beginning of the week I have regenerated various db and this time my verification test detected no errors. In addition,
seeing you found the same figures as mine I can conclude my program is now quite sound.
As a consequence I have just begun to work on multithread generation.
I will keep you inform of my progress.

[BertTuyt]

Im now checking the BT DBs for errors.
I think I use the same approach as many others (strong verify), but Im not 100% sure.
So for every position in the DB, I generate the successors and determine the DB value.
This can become quite time consuming with captures, where I need to load a 4KByte block from another DB.

So a more simplified approach would be (weak verify), to test only the positions with no captures.
As the BT DBs with many man contain mostly capture moves, this would really reduce the test process, especially due to lower SSD or HD access.

The disadvantage it is not a full test (like the strong verify).
So my question to the community, which verify in general do you chose, the strong verify or the weak verify?

Most likely there is also a clever method to execute the strong verify with less IO traffic, but I need to think about that....

Bert

[BertTuyt]

It took quite some time (14.6 hours), see previous post, but the 4x10 also verified, and same results as Gerard.

Bert

Code: Select all

Verify:4x10 Start, P = 56.923.426.846
52562.3 4x10, P = 56.923.426.846, NCW = 3.283.778.890, E = 0

[TAILLE]

Im now checking the BT DBs for errors.
I think I use the same approach as many others (strong verify), but Im not 100% sure.
So for every position in the DB, I generate the successors and determine the DB value.
This can become quite time consuming with captures, where I need to load a 4KByte block from another DB.

So a more simplified approach would be (weak verify), to test only the positions with no captures.
As the BT DBs with many man contain mostly capture moves, this would really reduce the test process, especially due to lower SSD or HD access.

The disadvantage it is not a full test (like the strong verify).
So my question to the community, which verify in general do you chose, the strong verify or the weak verify?

Most likely there is also a clever method to execute the strong verify with less IO traffic, but I need to think about that....

Bert

Hi Bert,

The purpose of the verification is clearly to test all your db.
In my implementation a capture position is not in the db and testing such position as no impact on the reliability of the db.
Of course my approach have also drawbacks:
For every position in the DB (a non capture position) I generate the successors. If a successor is a non capture position I read the db but, if the successor is a capture position I have to generate the capture and continue until a definitive value can be assigned to the position. In order to save time I always begin by exploring all successor positions without capture.

Because you store in the db the capture position I fully understand your wording "strong" or "weak".
In my implementation this wording do not make sense: nothing can be concluded if I find that a capture position leads to a win or to a loss.

[BertTuyt]

After 14.6 hours of Verification, 4x10 also ok.

Bert

Code: Select all

Verify:4x10 Start, P = 56.923.426.846
52582.5 4x10, P = 56.923.426.846, NCW = 3.283.778.890, E = 0

[TAILLE]

Hi Bert,

My multithread db generation program work now quite well.
I regenerated all the 2-13p db with exactly the same results.
FYI the the last db generated, ie. the 7x6db, took 2h15'.
Of course I will continue with the 14p db.

[BertTuyt]

Gerard, after several days I still did not get a result for 5x9.
The task manager indicated 1% for CPU and 100% for Disk Access.
So not sure what went wrong.

Restarted with a weak verify, which only covers the non-capture positions (these are the only relevant ones for comparison with you).
The 4x10 was indeed much faster, with the same result.
So hope that i will get any results for 5x9 and beyond in the next days.

Bert

Code: Select all

Verify:4x10 Start, P = 56.923.426.846
8409.4 4x10, P = 56.923.426.846, NCW = 3.283.778.890, E = 0

[TAILLE]

Gerard, after several days I still did not get a result for 5x9.
The task manager indicated 1% for CPU and 100% for Disk Access.
So not sure what went wrong.

Restarted with a weak verify, which only covers the non-capture positions (these are the only relevant ones for comparison with you).
The 4x10 was indeed much faster, with the same result.
So hope that i will get any results for 5x9 and beyond in the next days.

Bert

Code: Select all

Verify:4x10 Start, P = 56.923.426.846
8409.4 4x10, P = 56.923.426.846, NCW = 3.283.778.890, E = 0

Hi Bert,

The complete 14p db
12x2 NCW1= 302 705 258 NCL1= 1 008 172 770 NCW2= 1 484 410 911 NCL2= 3 938 613
11x3 NCW1= 1 227 707 632 NCL1= 2 320 901 210 NCW2= 3 990 227 861 NCL2= 17 199 718
10x4 NCW1= 3 283 778 890 NCL1= 3 909 798 894 NCW2= 7 861 805 321 NCL2= 58 604 100
9x5 NCW1= 6 517 270 884 NCL1= 5 063 957 332 NCW2= 12 149 534 525 NCL2= 194 627 036
8x6 NCW1= 10 280 586 402 NCL1= 5 034 127 495 NCW2= 15 077 388 839 NCL2= 722 143 907
7x7 NCW1= 14 036 633 965 NCL1= 2 910 252 528 NCW2= NCL2=

[BertTuyt]

Gerard I have now results (weak verify) for the 5x9 DB.
But it took extremely long (13.1 hours).
I guess it must be something not optimal in the DB Cache (which becomes apparent as I have a HD instead of SSD , and less memory on this computer).
But anyway, for now the most important is that is works, and that the result is (and good news) that count equals yours

Bert

Code: Select all

Verify:5x9 Start, P = 118.679.869.176
47241.7 5x9, P = 118.679.869.176, NCW = 6.517.270.884, E = 0

[BertTuyt]

Gerard, also 6x8 is ok.

Bert

Code: Select all

Verify:6x8 Start, P = 182.479.296.120
80433.0 6x8, P = 182.479.296.120, NCW = 10.280.586.402, E = 0

[TAILLE]

3x11 also confirmed.

Bert

Code: Select all

Verify:3x11 Start, P = 19.514.811.840
4878.1 3x11, P = 19.514.811.840, NCW = 1.227.707.632, E = 0

Last weekend I corrected another bug but since the beginning of the week I have regenerated various db and this time my verification test detected no errors. In addition,
seeing you found the same figures as mine I can conclude my program is now quite sound.
As a consequence I have just begun to work on multithread generation.
I will keep you inform of my progress.

Hi Bert,

Two weeks without new bug discovered. Seeing in addition your results my confidence is increasing.

15p db results:
12x3 NCW1= 1 369 045 548 NCL1= 2 816 203 880 NCW2= 4 802 122 598 NCL2= 13 716 550
11x4 NCW1= 3 952 646 546 NCL1= 5 159 925 700 NCW2= 10 185 702 843 NCL2= 47 571 785
10x5 NCW1= 8 445 055 798 NCL1= 7 309 939 040 NCW2= 16 951 444 161 NCL2= 157 918 417
9x6 NCW1= 14 252 548 459 NCL1= 8 159 580 776 NCW2= 22 946 771 022 NCL2= 567 814 711
8x7 NCW1= 20 115 443 029 NCL1= 6 679 591 801 NCW2= 24 852 206 669 NCL2= 2 364 699 914

2-15p db : 84,63 Gb

Good news for the starting position : after 2h Damy confirms that 22-18 is a winning move.
On the other hand, following the last bug I corrected two weeks ago, Damy proves now that 22-17 is a losing move!
After 3h20' Damy proves that 22-18 is the only winning move.

Are you able to confirm this fact?

I think Damy will be able to build the 16p db but I have also to improve my search algorithm for a better parallelism.
I will use the nights to continue the generation and the day time to work on my search algorithm!

[BertTuyt]

Gerard, thanks for your results.

In Holland (2 weeks ago) I also evaluated 22-17 on my computer and it was indeed losing.
But I did not report this difference as I first wanted to verify the 14P DBs.

So yes I have seen this result before.
But I cant confirm yet that 22-18 is the only wining move.

Bert

[BertTuyt]

To all involved, ...
BT 8x8 seems (more or less) a confirmed win for white (22-18), to be proven if this is the only move.
Is there already an expectation or assumption regarding the BT 10x10 outcome, white win or black win?
Solving weak BT 10x10 is, I'm afraid, still a bridge to far.

Bert

[BertTuyt]

Gerard, quite soon we can skip BT 8x8 (or never introduce) from the Computer Olympics, because we find the winning move (or all moves losing) within 20 seconds (which is average time for a 20 min game)

So here after up to 10x10...

Bert