7-men Syzygy attempt

[syzygy]

I have it working now.

It produces this game:
[pgn][FEN "k7/2QR4/8/8/8/4N3/2r4Q/1K6 b - - 0 1"]
[Annotator "syzygy-tables.info"]

{ DTZ -62 } 1... Rc1+ 2. Ka2 Rc2+ 3. Ka3 Rc3+ 4. Ka4 Rc4+ 5. Ka5 Rc5+ 6. Kb6 Rb5+ 7. Kc6 Rc5+ 8. Kd6 Rd5+ 9. Ke6 Re5+ 10. Kf6 Rf5+ 11. Kg6 Rf6+ 12. Kg5 Rg6+ 13. Kf4 Rg4+ 14. Kf3 Rg3+ 15. Kf2 Rf3+ 16. Kg1 Rf1+ 17. Kg2 Rg1+ 18. Kf2 Rf1+ 19. Kg3 Rf3+ 20. Kh4 Rh3+ 21. Kg5 Rg3+ 22. Kf6 Rg6+ 23. Kf7 Rg7+ 24. Ke6 Rg6+ 25. Kd5 Rd6+ 26. Ke4 Rd4+ 27. Kf3 Rf4+ 28. Kg2 Rf2+ 29. Kh3 Rf3+ 30. Qcg3 Rf4 31. Ra7+ Kb8 32. Qxf4+ { KQQRNvK with DTZ -2 } 32... Kc8 33. Qb8# { Checkmate } 1-0[/pgn]

[koedem]

I have it working now.

It produces this game:
[pgn][FEN "k7/2QR4/8/8/8/4N3/2r4Q/1K6 b - - 0 1"]
[Annotator "syzygy-tables.info"]

{ DTZ -62 } 1... Rc1+ 2. Ka2 Rc2+ 3. Ka3 Rc3+ 4. Ka4 Rc4+ 5. Ka5 Rc5+ 6. Kb6 Rb5+ 7. Kc6 Rc5+ 8. Kd6 Rd5+ 9. Ke6 Re5+ 10. Kf6 Rf5+ 11. Kg6 Rf6+ 12. Kg5 Rg6+ 13. Kf4 Rg4+ 14. Kf3 Rg3+ 15. Kf2 Rf3+ 16. Kg1 Rf1+ 17. Kg2 Rg1+ 18. Kf2 Rf1+ 19. Kg3 Rf3+ 20. Kh4 Rh3+ 21. Kg5 Rg3+ 22. Kf6 Rg6+ 23. Kf7 Rg7+ 24. Ke6 Rg6+ 25. Kd5 Rd6+ 26. Ke4 Rd4+ 27. Kf3 Rf4+ 28. Kg2 Rf2+ 29. Kh3 Rf3+ 30. Qcg3 Rf4 31. Ra7+ Kb8 32. Qxf4+ { KQQRNvK with DTZ -2 } 32... Kc8 33. Qb8# { Checkmate } 1-0[/pgn]

Yes, this is roughly what I got from manual going through moves and spamming d too. Kind of curious dance of the king.

I've started collecting interesting positions in a lichess study. The first chapter e.g. isn't very deep but still a nice way to win.
https://lichess.org/study/58OZVKJb

Excited that this is actually happening now. Already the completely pointless tables have interesting positions.

Shout out to Bojun Guo for stepping up and making this happen.

[syzygy]

Rxh2 indeed prolongs the game nicely

[noobpwnftw]

One of my two machines only have 1TB memory, so now I let it build pawnful ones to avoid using the -d option. Expectation is that they will finish 5+2 pawnless and 6+1 pawnful in about the same time. Then I may move on to 4+3 pawnless and 5+2 pawnful. Eventually one can work on 4(p)+3 and the other on 4+3(p).

Is it sound to arrange tasks like this? I think they will not require each other's ongoing sets to proceed their own work.

[jwes]

They already have in production a 100 TB SSD that draws 14 watts at full tilt.
https://www.cinema5d.com/nimbus-data-10 ... rgest-ssd/

Since it is already possible to make it, the density is feasible. And I guess that it costs little more to make it than to make a 10 TB SSD.

The fact that somebody put together a 100TB SSD is not really that significant. SSDs are just a bunch of NAND flash dies packaged together and connected through a controller. The dies are the important parts, and only a few companies make them. The largest NAND dies in real products right now are 96GB afaik, but in terms of physical size, they're tiny. Size of a fingernail. So to make a 100TB SSD, just buy 1000 of those, glue them together and make a controller to talk to them all. But 1000 dies is just expensive as fuck. They're getting 20-30% cheaper every year on average, which is nice, but 20x cheaper SSDs is not even on the horizon,

20x cheaper takes ~13 years at 20%/yr or ~8.4 years at 30%/yr.

[jjoshua2]

Thanks! I made my own 7 piece cfish compile that finds all the variations of the files on disk, and has 7 piece set in ucioption.c and tbcore.h, and I raised the values
`
#define TBMAX_PIECE 254
#define TBMAX_PAWN 256
#define HSHMAX 5
`
to the values in the tb file.
#define TBMAX_PIECE 650
#define TBMAX_PAWN 861
#define HSHMAX 12
`

I verified it was successfully accessing 7 piece files with procmon and played a game successfully, but the 2nd game segfaulted every few moves in the endgame. It's actually surprising how often the "non usable" 7 piece like KQQPPPvK are used.

I came on here to see if you had ideas and saw your source. Looks like you have slightly different values here, but I wouldn't think that would cause segfault. Maybe you can merge it into the official cfish so it gets kept up with patches please! EDIT: I see you have a fork, so I'll try that.

Thanks!

[syzygy]

I came on here to see if you had ideas and saw your source. Looks like you have slightly different values here, but I wouldn't think that would cause segfault. Maybe you can merge it into the official cfish so it gets kept up with patches please! EDIT: I see you have a fork, so I'll try that.

It should be fixed in the fork. The problem is that the factor[] values may become too big for 32 bits.

[Dann Corbit]

I came on here to see if you had ideas and saw your source. Looks like you have slightly different values here, but I wouldn't think that would cause segfault. Maybe you can merge it into the official cfish so it gets kept up with patches please! EDIT: I see you have a fork, so I'll try that.

It should be fixed in the fork. The problem is that the factor[] values may become too big for 32 bits.

What it the location for the fork?

[syzygy]

What it the location for the fork?

https://github.com/syzygy1/Cfish/tree/7men

[syzygy]

One of my two machines only have 1TB memory, so now I let it build pawnful ones to avoid using the -d option. Expectation is that they will finish 5+2 pawnless and 6+1 pawnful in about the same time. Then I may move on to 4+3 pawnless and 5+2 pawnful. Eventually one can work on 4(p)+3 and the other on 4+3(p).

Is it sound to arrange tasks like this? I think they will not require each other's ongoing sets to proceed their own work.

Yes, 6+1, 5+2 and 4+3 can be built independently.

I'm working on fixing DTZ generation for the few tables with very high DTZ.

Then I'll look into making the generator more efficient for tables with multiple pieces of the same type and colour. But that won't be trivial.