ashort wrote: ↑Thu Sep 17, 2020 11:58 pm
thank you. well, it seems to me that based on his code, the 2nd call to VSetPv is useless (and harmless, except for an extremely minor slow-down), as there is no way a search that failed high or failed low could have come up with a new PV. At least that is my understanding.
Well, in all three circumstances the PV will contain at least the first ply 1 move, so it tells the search to play that first.
In two if the three cases it will contain the second ply 2 move too, so it tells search to play that at ply 2.
Then, either search is on other move ordering heuristics, or, if the prior PV exists going deeper, then it can play down that.
I don't have a hash table and never will. It's a 16-bit imaginary machine with no XOR support in the language, and a tiny heap size
VSetPv looks at the root board state, because in that root board state is the fully backed up PV collected during a search. So VSetPv takes that pv collection and splits it up, one move at a time, among all the board states, by ply, so that the ensuing search can use the PV move for move ordering.
So my point is if a search failed low or failed high, it's not possible for the root state to suddenly have a new backed up PV. Hence the 2nd call to VSetPv does nothing... Unless I'm wrong?
ashort wrote: ↑Fri Sep 18, 2020 12:22 am
I don't have a hash table and never will. It's a 16-bit imaginary machine with no XOR support in the language, and a tiny heap size
VSetPv looks at the root board state, because in that root board state is the fully backed up PV collected during a search. So VSetPv takes that pv collection and splits it up, one move at a time, among all the board states, by ply, so that the ensuing search can use the PV move for move ordering.
So my point is if a search failed low or failed high, it's not possible for the root state to suddenly have a new backed up PV. Hence the 2nd call to VSetPv does nothing... Unless I'm wrong?
Quote from earlier: “From general principles, I’m not commenting his specific implementation“.
From general principles there’s no reason why (case fails) a partial PV can’t exist. Nor why the prior PV can’t exist.
ashort wrote: ↑Thu Sep 17, 2020 11:58 pm
thank you. well, it seems to me that based on his code, the 2nd call to VSetPv is useless (and harmless, except for an extremely minor slow-down), as there is no way a search that failed high or failed low could have come up with a new PV. At least that is my understanding.
[I am writing for a 16-bit imaginary machine in a language that does not support XOR, so I am not using hash tables at all, nor am I using bitboards. I'm using 0x88. The language is from a course I took on how to write a compiler, and it's a simple but strong object oriented language, but does not support XOR because the point was to keep the language simple. It has AND, OR, and NOT, but not XOR. Also the heap size of the imaginary machine is too small for a reasonable hash table anyway).
So you're writing machine language to implement chess engine in? If so - that's very cool and I'd love to see the source code of both(language itself and chess engine implementation). Btw regarding this like challenge I think it might be interesting to write chess programs for micro computers like Arduino, those that have LOTS of limitations e.g. CPU performance, shortened machine commands and only kilobytes of RAM. That is something HGM is fond of (well at least he was a couple of years ago)
I figured it out. When in iteration X, you want to use the PV line from iteration X -1, but during the search, you want to make sure you use the PV line only once, so his code zeros out the pv moves as he sorts them. But if the search fails low or high, then when he re-searches with an infinite window, he copies the stored PV line _again_ to make sure the re-search uses the PV line again. Makes sense.
So alas, I did not find a bug in Bruce Moreland's code...
