problem is that (2) does not quite do very satisfactorily. at least from what I see in SF, it misses an awful lot of good moves, just because it orders them very low or does not consider at all; once the move is shown to the engine, it understands it value immediately, so its eval is sufficient in this case.Evert wrote:What you have to remember is that most move sequences considered by engines are blunders. When they hang a queen, you want to capture it immediately. That's why you have to sort captures (especially winning captures) first.Lyudmil Tsvetkov wrote:I guess a major flaw of standard move-ordering techniques as found in engines, is that they rely too much on previous performance of a move (history tables, etc.), and too little of the objective quality of the move in the new setting at a bigger depth. relying on previous performance means relying on eval scores throughout different depths, which migth not be the perfect approach taken into account engines' far from perfect eval.
as I see it currently, modern top engines use too few flags to order their moves, and there are, of course, much much more important patterns than whether a move is a capture, winning capture, simply quiet move, etc. for example, it matters very much if the move is close to the enemy king or far from it, whether it creates some threat, though not executing it, etc., etc. Top engines seem to not quite take this into account, at least that is what I see from SF's choice of moves.
Once you're past that, you need some way to sort moves that are not obviously good (because they win you a queen). There are two approaches:
1. Hard code all patterns that you can think of. This requires a lot of work, and a lot of testing for special cases (I mean the code needs to do a lot of tests, not that it needs to be heavily tuned, though that is also true).
2. Use general guidelines and allow the code to figure out what works and what doesn't during search.
The first approach is like you suggest. This is not scalable and a maintenance nightmare. It's also slow because it needs to do a lot of work. The second is what most (all?) programs do, using things like killer tables and history. Good programs are good not in spite of doing (2) instead of (1), but because they don't waste time doing (1) when (2) will do.
Now, you probably could write a neural network that aims to do (1). I think Giraffe might have that? The issue is setting up and training said network.
I suppose all engines do use some kind of neural network, though most of those networks are quite primitive. Once you manage to create a sufficiently ample network and tune its parameters appropriately, the engine should play at a quite acceptable level.
one thing I noticed about eval in the recent months while playing some engine matches, and that should certainlt be also true of move ordering, is that even as few as 3cps matter. I have always known this, but while watching engine games and see how a factor worth just 3 cps really makes a distinction and decides the game further on, is really striking.
so, I suppose, that the old assumption that, maybe, many best moves are just a matter of style, there migth be couple of first moves with almost equal scores, is a pure illusion. There seems to always be one single best move, significantly better than the rest, and this one best move could only be found by very refined eval, including very refined move ordering, otherwise you are more or less searching not entirely beneficial nodes.