I guess it makes sense that if you don't sort quiet moves, then not doing LMR helps you (so the third test is less of a regression than the first but more than the second). What worries me about these results though is that the draw rate is very different for the second run. I have seen that when that happens, it often means that there is something wrong with the test (not always though, but often enough that I worry when I see it). Usually the elo difference between test versions is much smaller of course, so that may be why.
Evert wrote: What worries me about these results though is that the draw rate is very different for the second run. I have seen that when that happens, it often means that there is something wrong with the test (not always though, but often enough that I worry when I see it). Usually the elo difference between test versions is much smaller of course, so that may be why.
What is your normal draw-rate in testing?
The draw rate is smaller in the examples where the elo differences are bigger, because the stronger engine smashes the other version.
So draw rate is higer in the second test because the elo difference is "only" 53+53 elo.
Evert wrote:
I guess it makes sense that if you don't sort quiet moves, then not doing LMR helps you (so the third test is less of a regression than the first but more than the second).
Sorry, I don't understand. Not doing LMR when there is quiet move ordering loses 53+53 elo. Not doing LMR where ther is not quiet move ordeding loses 120+120 elo.
I second that. An engine can play legal chess and even play good moves most of the time, and still have serious bugs. In particular it is very important that all evaluation code do what you intend it to do. I just recently found a sign error in my eval function where it was applying a bonus where it should have a penalty. That code wasn't being triggered often, but still, you don't want that kind of thing. An easy test that catches some problems is to eval a position twice, once with the board flipped and side to move changed. You should get the same value (Crafty did this, ages ago, I learned this trick from it).
I second that. An engine can play legal chess and even play good moves most of the time, and still have serious bugs. In particular it is very important that all evaluation code do what you intend it to do. I just recently found a sign error in my eval function where it was applying a bonus where it should have a penalty. That code wasn't being triggered often, but still, you don't want that kind of thing. An easy test that catches some problems is to eval a position twice, once with the board flipped and side to move changed. You should get the same value (Crafty did this, ages ago, I learned this trick from it).
cdani wrote:I have done some basic tests to try to verify the relation between LMR and move ordering. I used different versions of Andscacs:
* andscacs081019.exe, is like 10 elo stronger than the last published version
* andscacs081019nolmr.exe, the same without lmr.
* andscacs081019noqmo.exe, the same without quiet move ordering.
* andscacs081019noqmo_nolmr.exe, the same without quiet move ordering and also without lmr.
Nice test method. I may try this later in my engine.
I have a question on noqmo, an example if cap has move order score of 1000 (further classified into winning, equal ...), killer1 ... = 900, others = 500 and Quiet Moves move order score = 0. So something like you set it to zero. Is that what you mean in noqmo?
Ferdy wrote:
I have a question on noqmo, an example if cap has move order score of 1000 (further classified into winning, equal ...), killer1 ... = 900, others = 500 and Quiet Moves move order score = 0. So something like you set it to zero. Is that what you mean in noqmo?
noqmo = no quiet move ordering. In quiet move ordering I include, so I removed in this version:
* value of history.
* penalizations for piece going back.
* killers, countermoves, and the like.
* other minor optimizations for quiets.
So after good captures, all the quiets are processed only by the inherent ordering of move generation.
Ferdy wrote:
I have a question on noqmo, an example if cap has move order score of 1000 (further classified into winning, equal ...), killer1 ... = 900, others = 500 and Quiet Moves move order score = 0. So something like you set it to zero. Is that what you mean in noqmo?
noqmo = no quiet move ordering. In quiet move ordering I include, so I removed in this version:
* value of history.
* penalizations for piece going back.
* killers, countermoves, and the like.
* other minor optimizations for quiets.
So after good captures, all the quiets are processed only by the inherent ordering of move generation.
isPinned() is a function defined in board.h. It is used to test whether a move would cause discovered check if executed, or in other words, if the piece being moved is pinned and cannot move to the specified destination square. That part of the unit test just verifies that this function works as expected: finds pins where they exist and doesn't fail in certain cases such as moves in the direction of the pin.
jdart wrote:isPinned() is a function defined in board.h. It is used to test whether a move would cause discovered check if executed, or in other words, if the piece being moved is pinned and cannot move to the specified destination square. That part of the unit test just verifies that this function works as expected: finds pins where they exist and doesn't fail in certain cases such as moves in the direction of the pin.
