Edsel Apostol wrote:Hi Les,
Maybe Rybka is using piece lists combined with bitboard. As what Bob has said, it is true that when you flip a position, the move ordering will also change, resulting to varying time to find the solution, that is if it is a bitboard only engine.
There is also a possibility that the eval value will change even if you have no bugs in your program. This results from the SEE routine, if it uses lastOne() only for both sides, applicable only for bitboards. (I'm using SEE in my eval ). Some positions have the same rooks for example to capture on a square, but when you flipped it the other rook will be tried first in the capture sequence that might result to a different value. It is also possible that in this kind of positions the SEE is inaccurate.
I even wrote a bitboard SEE that will overcome this issue but I'm wondering if the added accuracy can compensate for the little speed loss. This kind of positions are somewhat rare, maybe one in a hundred thousand positions in my guess. I have not tested that SEE much though and on my testing, there is no significant change that I noticed.
I don't have this problem in my SEE. I always pick the least valuable attacking piece first when playing out the captures, regardless of where that particular piece stands on the board.
Evaluations should not change in Crafty either, as I take great pains to make sure that is true for each new version as it represents a significant bug if it happens.
But for move generation, I'm going to run into this every last time.
My SEE is somewhat similar to the SEE used in latest open source Crafty so if you had not changed that in your latest versions then the problem is there. The problem I mentioned is in positions where there are two or more same pieces as least valuable attacker.
In the position that I find in my debugging, this involves two rooks that can recapture on the SEE square, one of this rooks has a hidden attacker behind that is that of the enemy. So when you flip the position, and used only the LSB() function instead of using the MSB() for flipped positions, the sequence of capture will change. For example, instead of the rook without the hidden attacker behind is tried first, in the flipped position, the one with the hidden attacker behind will be tried first. This will result into different SEE values for flipped positions.
In my program, it uses something similar to the idea in Fruit where SEE was used to determine if a pawn is a Free Passer. This is where I discovered these positions where it failed in my Eval Symmetry test.
Another thing, in these positions, it is possible that this kind of SEE is inaccurate. It never determines which sequence of captures to consider as the best. In these positions where there are two or more Least Valuable Attackers to the SEE square, it only tried the one that was found by LSB routine first. There are cases that trying out the other Least Valuable Attackers first instead of sorting it out by the LSB only, will produce a more accurate value for the SEE.
I will try to post the positions next time as I will look it up on my debug files. I will also post the SEE trace for that position and the trace of the new SEE routine i wrote myself.
If anyone is interested, I will post the source code of the two SEE routines here.
Edsel Apostol (Twisted Logic)