Evert wrote:
More to the point, however: none of these functions should ever be called on out-of-board squares. I'll put in place asserts instead and see if I can trigger them locally.
Found it (I think): when I re-wrote the move encoding, I forgot to correctly update the query functions for the capture piece and capture (victim) square. This causes illegal square numbers to be extracted. However, these functions are only used by SEE and to test whether a move left the king in check (was an illegal evasion) so the problem doesn't show up when testing the move generator.
Ah, the bench test just triggered another assert. Guess I'm not done yet...
Yes of course. I think sys_time_wrapper is just leftover than can be easily removed (I didn't clean up properly so there may be more things like that).
Evert wrote:The expected behaviour for out-of-bound bits (which automatically means an off-the-board square) is for set() and reset() to do nothing and for test() to always return false (or be undefined, see below), however that's not what the code here does: it will instead manipulate a random bit on the board.
More to the point, however: none of these functions should ever be called on out-of-board squares. I'll put in place asserts instead and see if I can trigger them locally.
This is not the case on x86/x64 where the CPU masks the amout by num_bits-1 first, that's why I had to add masking to get the same behavior
(Microsoft CRT behaves in emulation mode as you said, which is different from what the CPU does).
Anyway this was just a hack. Best would be to fix it so that you don't get out of bounds bits (I see you're on the right track from your other post).
Evert wrote:The expected behaviour for out-of-bound bits (which automatically means an off-the-board square) is for set() and reset() to do nothing and for test() to always return false (or be undefined, see below), however that's not what the code here does: it will instead manipulate a random bit on the board.
More to the point, however: none of these functions should ever be called on out-of-board squares. I'll put in place asserts instead and see if I can trigger them locally.
This is not the case on x86/x64 where the CPU masks the amout by num_bits-1 first, that's why I had to add masking to get the same behavior
(Microsoft CRT behaves in emulation mode as you said, which is different from what the CPU does).
To be clear: I didn't mean that I think that that is correct behaviour (although shifting a bit outside the acceptable range returning zero might be reasonable, I can imagine why leaving it undefined makes things easier on the hardware level), but rather that the functions that call the bitboard routines expect bitboards to be "clean" in the sense that no spurious bits are set or cleared. Of course, the original assumption is that any squares that are passed around are actually valid, which is not the case here.
Still having some issues with discovered checks by en-passant capture not being handled correctly, but I'll figure it out (fortunately this doesn't lead to any real problems in played games).
Ok, fixed now. The funny thing is that this bug should really have broken SEE quite badly in the last release. I should probably do a quick regression test to see what the impact of fixing this is on playing strength.
I'll upload the fixed source tomorrow.
EDIT: a quick test with a handful of games suggests that this bug cost quite a bit of elo. At the very least it's not one of those annoying bugs that end up gaining elo (or rather, fixing it loses elo because everything is tuned around it)...
If you have time, could you (Martin) verify that I haven't broken anything and this still compiles correctly? I've included your project files in the archive so it should hopefully be a matter of hitting "compile" (keeping them up-to-date in the future may be more tricky though).
One final question: is it possible to define the pre-processor symbol SVNVERSION so that it sets the correct version number in the executable?
If this all works correctly, I'll probably release this as either beta6 or as 1.0RC1. It seems (in self-testing) that the "invalid squares bug" lost more than 100 elo.
If you have time, could you (Martin) verify that I haven't broken anything and this still compiles correctly? I've included your project files in the archive so it should hopefully be a matter of hitting "compile" (keeping them up-to-date in the future may be more tricky though).
One final question: is it possible to define the pre-processor symbol SVNVERSION so that it sets the correct version number in the executable?
If this all works correctly, I'll probably release this as either beta6 or as 1.0RC1. It seems (in self-testing) that the "invalid squares bug" lost more than 100 elo.
Congrats Evert, 100 elo, really? Incredible...
Ok I will gladly recompile and add the version so that hgm can use this one, but somehow the link you posted doesn't work... a typo maybe?
The bug basically sabotages the QS search and breaks distinction between winning and losing captures. It's over 100 elo in a self-test with few (<100) games, but the fixed version scores ~83% against beta 5, and the points it loses are mainly draws.
Note that it's not a simple gain of 100+ elo, since this bug is something I introduced between beta4 and beta5. I re-wrote the move format to accommodate gating moves in Seirawan chess. Since this isn't a "functional" change, I didn't regression-test it. However, I should have done a test to verify that the bench result was unchanged. Not sure what went wrong there...
done, I've reuploaded everything (links are still the same).
seems fine so far, I've fixed the vcxproj and made one last change to compilerdef.h (btw. your solution with one header is much more elegant - this is again in sjaakII_changes.zip.
so, that's it for beta6_r180 good luck with it.
benchmark is 16160856 nodes.
