Page 30 of 59

Re: 7-men Syzygy attempt

Posted: Sat May 12, 2018 2:10 pm
by syzygy
I cannot find a problem as easily with tables that do not need the 16-bit compression code (max DTZ < 580 plies).

I also cannot find a problem as easily with KRBNvKQN, which was generated earlier.

So for the moment I am guessing that the problem lies in the NUMA adaptations of the 16-bit compression code (which should have had almost no effect on that part of the code). Alternatively, it is the parallel compressed I/O code.

If someone finds an inconsistency in some other table, please let me know.

Re: 7-men Syzygy attempt

Posted: Sat May 12, 2018 3:06 pm
by noobpwnftw
Ok, this is what I will do, I will regenerate this table with the non-NUMA generator, hopefully it only affects 16-bit ones.

Re: 7-men Syzygy attempt

Posted: Sat May 12, 2018 3:45 pm
by syzygy
noobpwnftw wrote:
Sat May 12, 2018 3:06 pm
Ok, this is what I will do, I will regenerate this table with the non-NUMA generator, hopefully it only affects 16-bit ones.
That will tell us if the problem was introduced by one of the recent changes.

KQNNvKQN does not need 16-bit compression and seems OK.
KQBNvKQB does need 16-bit compression and has a problem already for the position with max DTZ:
https://lichess.org/analysis/standard/1 ... 6/8/B1K5_b_-_-

Re: 7-men Syzygy attempt

Posted: Sun May 13, 2018 1:15 am
by syzygy
syzygy wrote:
Sat May 12, 2018 3:45 pm
noobpwnftw wrote:
Sat May 12, 2018 3:06 pm
Ok, this is what I will do, I will regenerate this table with the non-NUMA generator, hopefully it only affects 16-bit ones.
That will tell us if the problem was introduced by one of the recent changes.
I have found the problem. It only affects the .rtbz tables with max DTZ >= 580 ply that were generated with the NUMA-aware generator. I am testing a fix now.

The affected tables seem to be:
- KQBNvKQB (660 ply)
- KRRNvKRR (581 ply)
- KQBNvKQN (633 ply)

The KRBNvKQN table that was generated earlier cannot have been affected by this problem.

If you have already regenerated one of these tables with the pre-NUMA generator (or with current master), then it is correct.

Re: 7-men Syzygy attempt

Posted: Sun May 13, 2018 1:16 am
by noobpwnftw
syzygy wrote:
Sat May 12, 2018 3:45 pm
noobpwnftw wrote:
Sat May 12, 2018 3:06 pm
Ok, this is what I will do, I will regenerate this table with the non-NUMA generator, hopefully it only affects 16-bit ones.
That will tell us if the problem was introduced by one of the recent changes.

KQNNvKQN does not need 16-bit compression and seems OK.
KQBNvKQB does need 16-bit compression and has a problem already for the position with max DTZ:
https://lichess.org/analysis/standard/1 ... 6/8/B1K5_b_-_-
Master branch(with parallel compression) seems to produce correct results.
I'm uploading regenerated KQBNvKQB now.

Re: 7-men Syzygy attempt

Posted: Sun May 13, 2018 1:31 am
by syzygy
noobpwnftw wrote:
Sun May 13, 2018 1:16 am
syzygy wrote:
Sat May 12, 2018 3:45 pm
noobpwnftw wrote:
Sat May 12, 2018 3:06 pm
Ok, this is what I will do, I will regenerate this table with the non-NUMA generator, hopefully it only affects 16-bit ones.
That will tell us if the problem was introduced by one of the recent changes.

KQNNvKQN does not need 16-bit compression and seems OK.
KQBNvKQB does need 16-bit compression and has a problem already for the position with max DTZ:
https://lichess.org/analysis/standard/1 ... 6/8/B1K5_b_-_-
Master branch(with parallel compression) seems to produce correct results.
I'm uploading regenerated KQBNvKQB now.
Yes, it should.
I have fixed the numa branch now. I have tested it by forcing 16-bit compression of KRBvKNN (incorrect before the fix, correct now). Unfortunately the problem did not occur for 5-piece tables (just too small, it seems), which is why it slipped through.

Re: 7-men Syzygy attempt

Posted: Sun May 13, 2018 2:28 am
by noobpwnftw
syzygy wrote:
Sun May 13, 2018 1:31 am
noobpwnftw wrote:
Sun May 13, 2018 1:16 am
syzygy wrote:
Sat May 12, 2018 3:45 pm

That will tell us if the problem was introduced by one of the recent changes.

KQNNvKQN does not need 16-bit compression and seems OK.
KQBNvKQB does need 16-bit compression and has a problem already for the position with max DTZ:
https://lichess.org/analysis/standard/1 ... 6/8/B1K5_b_-_-
Master branch(with parallel compression) seems to produce correct results.
I'm uploading regenerated KQBNvKQB now.
Yes, it should.
I have fixed the numa branch now. I have tested it by forcing 16-bit compression of KRBvKNN (incorrect before the fix, correct now). Unfortunately the problem did not occur for 5-piece tables (just too small, it seems), which is why it slipped through.
I'm regenerating affected tables(KQBNvKQN,KRRNvKRR) with fixed NUMA generator.

Re: 7-men Syzygy attempt

Posted: Sun May 13, 2018 8:35 am
by Sesse
syzygy wrote:
Sun May 13, 2018 1:15 am
The affected tables seem to be:
- KQBNvKQB (660 ply)
- KRRNvKRR (581 ply)
- KQBNvKQN (633 ply)
I've removed these from my mirror, and evidently, so has Lichess.

Re: 7-men Syzygy attempt

Posted: Sun May 13, 2018 9:15 am
by noobpwnftw
Sesse wrote:
Sun May 13, 2018 8:35 am
syzygy wrote:
Sun May 13, 2018 1:15 am
The affected tables seem to be:
- KQBNvKQB (660 ply)
- KRRNvKRR (581 ply)
- KQBNvKQN (633 ply)
I've removed these from my mirror, and evidently, so has Lichess.
I have also removed those, and some regenerated files has been uploaded, please re-check and make sure they are correct now.

Re: 7-men Syzygy attempt

Posted: Sun May 13, 2018 7:36 pm
by syzygy
noobpwnftw wrote:
Sun May 13, 2018 9:15 am
Sesse wrote:
Sun May 13, 2018 8:35 am
syzygy wrote:
Sun May 13, 2018 1:15 am
The affected tables seem to be:
- KQBNvKQB (660 ply)
- KRRNvKRR (581 ply)
- KQBNvKQN (633 ply)
I've removed these from my mirror, and evidently, so has Lichess.
I have also removed those, and some regenerated files has been uploaded, please re-check and make sure they are correct now.
As expected, the new KQBNvKQN.rtbz solves the problems I noticed.