Werewolf wrote: ↑Wed Sep 11, 2024 10:37 amI'm then claiming that two identical engines - pure brute force in terms of search with nothing else, no pruning or QS - but one doing (say) a 3 ply search and the other doing (say) a 9 ply search would typically result in a victory to the 9 ply one. Do you agree with that point?
Not before I see it demonstrated. Because it is not obvious at all that it should be so. For all I know the 9-ply search might just be more creative in finding ways to throw away material. Of course the 9-ply search would be better in seeing checkmate earlier, which would give it some advantage. But that would not help much if it would shed its non-royal material faster than the opponent; then the only checkmates to be seen are where it gets checkmated, and sooner or later one would occur that cannot be avoided before the opponent sees it too.
It has been shown in an abstract example that a sufficiently erratic evaluation can prevent a search result to become on average more reliable with depth, in minimax.
Also, even plies might work better than odd plies, because the side to move won't make the last move, and won't see any imagined gains in the last ply for which it would be worth to sacrifice something in the first ply. So I could imagine that 4 or 6 ply plays better than 9.
OK I'll test this if I can get the engine working.
I do find this reasoning difficult to accept though for two reasons:
1) Most positions would resolve with depth. For example below
[d]5rqk/3n3p/8/1P1p4/8/8/8/2B4K w - - 0 1
I can imagine after 1.Bb2+ a 3-ply searcher might try to limit material loss with 1...d4 2.Bd4+ Ne5 3.Be5 Rf6 4.Bf6+ Qg7 5.Bg7+ Kg7 and white wins. But a 9-ply searcher would not (and a higher number search certainly wouldn't).
2) In Nibbler one has the ability to control nodes searched. Using both SF and Lc0 and limiting them to one node of search they both play decent chess. I fully accept the EF is very different to the one I described above, but it is remarkable how tactically alert they are. Of course, this assumes Nibbler really does control the nodes search and limits it at one.
That is fishy. Especially Stockfish should not be able to play with a single node at all. It would need to at least search every move in the root for one ply to get an evaluation after the move, and thus score each move differently. Otherwise it would just have a list of (pseudo?-)legal moves, without any clue which is better than another. So how would it decide which move it will play???
LC0 is different. It has a 'policy network', which recommends moves through a static algorithm (a very extended neural net). This net has a pretty good insight in tactics; it will recognize hanging pieces, and advise to gobble those up, while it would advise against taking lower-valued protected pieces. So even at 1 node it judges all the moves, including the effect of the obvious continuation of tactics in progress. LC0 searches by MCTS, which does not have a Quiesence Search, so its evaluation net has been trained to also understand non-quiet positions. (The price is of course that evaluating that single node requires much more computing effort than a typical alpha-beta QS with material evaluation would.)
You cannot say that of the evaluation you are using.
Like I said, the quality of the evaluation determines whether minimax will converge with depth. The evaluation of LC0 is very good in all positions it is likely to encounter in a game, so one should not expect any problems there. A current-material-only evaluation, designed to only make sense in quiet positions is very poor, though. As Chess is a very tactical game, and the tree is full of non-quiet positions. So the convergence of minimax is a serious worry there.
Constructing a single (very contrived!) position where a 9-ply search would do better than a 3-ply search doesn't mean anything. For one, you pick a position with few pieces, where there in general is little to capture, so that QS is not very important. Who says the 9-ply searcher would survive the opening and middle-game well enough to ever get in such a position? And if the 3-ply searcher played black and had such an advantage, the probability that it would expose itself to a forced loss of the Queen against this measly Bishop are minute.
hgm wrote: ↑Wed Sep 11, 2024 4:26 pm
LC0 is different. It has a 'policy network', which recommends moves through a static algorithm (a very extended neural net). This net has a pretty good insight in tactics; it will recognize hanging pieces, and advise to gobble those up, while it would advise against taking lower-valued protected pieces. So even at 1 node it judges all the moves, including the effect of the obvious continuation of tactics in progress. LC0 searches by MCTS, which does not have a Quiesence Search, so its evaluation net has been trained to also understand non-quiet positions. (The price is of course that evaluating that single node requires much more computing effort than a typical alpha-beta QS with material evaluation would.)
Could you have a smaller NN of the type Lc0 uses (presumably this means holding it on the GPU) but then doing a brute force search instead of MCTS? I'd use a smaller net to get higher nps in order to get to ply 3-5.
Werewolf wrote: ↑Wed Sep 11, 2024 10:37 amI'm then claiming that two identical engines - pure brute force in terms of search with nothing else, no pruning or QS - but one doing (say) a 3 ply search and the other doing (say) a 9 ply search would typically result in a victory to the 9 ply one. Do you agree with that point?
Not before I see it demonstrated. Because it is not obvious at all that it should be so. For all I know the 9-ply search might just be more creative in finding ways to throw away material. Of course the 9-ply search would be better in seeing checkmate earlier, which would give it some advantage. But that would not help much if it would shed its non-royal material faster than the opponent; then the only checkmates to be seen are where it gets checkmated, and sooner or later one would occur that cannot be avoided before the opponent sees it too.
It has been shown in an abstract example that a sufficiently erratic evaluation can prevent a search result to become on average more reliable with depth, in minimax.
Also, even plies might work better than odd plies, because the side to move won't make the last move, and won't see any imagined gains in the last ply for which it would be worth to sacrifice something in the first ply. So I could imagine that 4 or 6 ply plays better than 9.
I do not see a reason that even ply is better.
With even plies you have the same problem with imagined gains of the opponent.
With 4 plies you may miss a simple capture that win material for you because the opponent has a bad trick to win more material in 3 plies and the fact that you capture back even more in the next ply is too deep for you to see.
Werewolf wrote: ↑Fri Sep 06, 2024 11:13 am
Is there any chess engine that does a pure brute force search without any extensions etc etc on top?
If you are looking for pure mini-max, I recall that there were engines that did that, but there is no advantage over alpha-beta. They arrive at exactly the same answers and alpha-beta is ludicrously faster. There are no unsound extensions in a pure alpha-beta searcher. One might also argue that pvs with zero window searches is also harmless.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
Werewolf wrote: ↑Fri Sep 06, 2024 11:13 am
Is there any chess engine that does a pure brute force search without any extensions etc etc on top?
If you are looking for pure mini-max, I recall that there were engines that did that, but there is no advantage over alpha-beta. They arrive at exactly the same answers and alpha-beta is ludicrously faster. There are no unsound extensions in a pure alpha-beta searcher. One might also argue that pvs with zero window searches is also harmless.
Yes I agree from a chess-playing point of view. However, I am trying to write an engine from scratch and to do that I want to start really simple - no alpha beta (yet), just pure brute force. At the moment I'm actually writing a Connect 4 program because it's simpler and have got it working on 64 threads with no EF and no AB. It hits around 300 million nps. Soon I'll add AB.
