It is about two orders of magnitude worse when a state spills over between moves. And the so-called spill-over you make such a fuss about is a one-in-a-couple-of-billion-games event, because it is dependent on a hash collision (in itself astronomically unlikely if you use sufficient key length) altering the behavior of the search enough to make a sought event disappear.Ras wrote: ↑Sat Jan 23, 2021 2:42 pmWhat I dislike here is that I won't be able to reproduce the problem from that game alone if state spills over between games. Especially when using different key schemes, that will cause the hash table entries to be overwritten in different ways, and that may well have an effect upon move sorting. It should be equivalent in terms of Elo, but still different.
The other thing doesn't seem to be true: XORing the index with a constant just swaps the location of buckets in memory. And if you properly age the existing entries they would be ignored in replacement decisions.
One sec per game should not be a problem at all, with centi-second resolution.I can test at one second per game, depending on what I want to test.
But you would of course compensate for that. You know how much time was spent for each test run of I don't-know-how-many thousand games. And can adapt the node budget for that (based on a course measurement of the nps), or correct a little difference from the know dependence of Elo on thinking time (e.g. subtract 3 Elo if it had used 3% more time).No really because that skews the metrics. If you have two identical engines, but one has only half the NPS, then you would get something like 50 Elo difference at time based controls, but none at node based ones.
Well, that could then be a problem when you read the specs in a peculiar way...If I knew that a GUI doesn't stick to the UCI spec as I read it, and that this is actually the underlying reason and not something else in my engine, I would shrug it off and say "don't use this GUI for such fast games".