TalkChess.com

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.

Ok, this is what I will do, I will regenerate this table with the non-NUMA generator, hopefully it only affects 16-bit ones.

noobpwnftw wrote: ↑Sat May 12, 2018 5: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_-_-

syzygy wrote: ↑Sat May 12, 2018 5:45 pm

noobpwnftw wrote: ↑Sat May 12, 2018 5: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.

syzygy wrote: ↑Sat May 12, 2018 5:45 pm

noobpwnftw wrote: ↑Sat May 12, 2018 5: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.

noobpwnftw wrote: ↑Sun May 13, 2018 3:16 am

syzygy wrote: ↑Sat May 12, 2018 5:45 pm

noobpwnftw wrote: ↑Sat May 12, 2018 5: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.

syzygy wrote: ↑Sun May 13, 2018 3:31 am

noobpwnftw wrote: ↑Sun May 13, 2018 3:16 am

syzygy wrote: ↑Sat May 12, 2018 5: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.

syzygy wrote: ↑Sun May 13, 2018 3: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.

Sesse wrote: ↑Sun May 13, 2018 10:35 am

syzygy wrote: ↑Sun May 13, 2018 3: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.

noobpwnftw wrote: ↑Sun May 13, 2018 11:15 am

Sesse wrote: ↑Sun May 13, 2018 10:35 am

syzygy wrote: ↑Sun May 13, 2018 3: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.