[tools] Discrepancy between bestmove and nextmove during data generation. (not a bug)

[Sopel97]

The move saved during data generation is the first move from PV, but the chosen move is sometimes random (how random depends on the settings). This can harm the compression of the generated data. It's not clear whether this should be touched though, as the impact might be minor. There are 2 things that should be investigated before:

• how much is the compression impacted for various (popular) settings, especially multipv
• how much is the training impacted, as we determine positions 'quietness' based on the stored bestmove

[vondele]

With the new arch, probably tools needs an update, and maybe even for the binpack 2.0 format ? Maybe you can post the link here to the design document, if it is still active?

[Sopel97]

The spec draft for "binpack 2.0" can be found here: https://docs.google.com/document/d/14KuSaQbL_9Ym5IVzIDHBwGWSrGvaajc-eki8ZJ7h1Qs/edit#heading=h.wz1dp9fb5q66

It is active but no ETA. It's fairly complex to incorporate this into the current codebase in a nice way, given how many additional options there will be. We might end up having to pretty much duplicate the generation/transform code to get the most out of it. I haven't yet started implementing it.