That is indeed a bug. I can't think off the top of my head where that code occurs though, and without that context it's hard to say what the correct fix might be (I haven't looked at your source archive yet).
Off the top of my head, only bitboards should be shifted by an arbitrary large amount, and they should know their size and assert on that.
At the end of evaluate.h I left a debug code for you (#if 0 for now) so that you can trace the problem.
But probably that's not necessary - best would be to put an assert in bitboard.h.
Indeed.
(the "fixes" in bitboard.h are marked with comments and FIXMEs)
I'm not sure if/how this would affect performance and/or variants that use 128-bit bitboards...
Well, "test movegen" tests (some) variants that use 128 bit bitboards, so if that passes it should be ok...
Evert wrote:Well, "test movegen" tests (some) variants that use 128 bit bitboards, so if that passes it should be ok...
test movegen passes.
So I played a couple of variants in Winboard and Sjaak seemed fine (except that in Gothic it was outsearched by Fairy-max, not sure if this is ok).
In Seirawan game, Fairy-max (4.8S) played an illegal move
I think it's because it expected having put hawk/elephant but Winboard somehow didn't notice it. Maybe I'm using outdated Winboard (4.7.2).
Anyway I guess hgm can grab the compiles (each under 1M and both compress to 800kb using zip).
mar wrote:In Seirawan game, Fairy-max (4.8S) played an illegal move
This problem has been solved in later versions (4.8V is included with the latest WinBoard install). It was due to a bug in printing the promotion character, (which does double duty as indicating the gated piece in the WB protocol move notation), so that WinBoard would not recognize it as part of the move, and consider the move as a non-gating. Later moves with the gated piece would then be rejected as illegal.
The problem with mini-Shogi is that the knowledge might not exist. The game was invented only in recent times, and was never played by millions of people, or by professional (min-Shogi) players.
They have not published the games yet, so I have no idea why Shokidoki lost to 1/128 Rigan in the 8th UEC Cup. (Beating it was the only thing required to win the cup.) On several occations it did beat 1/128 Rigan, which got it the gold medal in the 2013 Computer Olympiad. So it is not impossible to win with very little knowledge. (Of course it does have terms like piece values, PST and King safety, but they are all my own guesses.)
Problem is the CPU instruction on x64 does masking by 63 and obviously gcc in 32-bit mode too.
However Microsoft CRT does no masking in 32-bit emulation and hence the "problem".
(this is why I advocate compiling with different compilers at different platforms, because sometimes it can help to catch bugs)
At the end of evaluate.h I left a debug code for you (#if 0 for now) so that you can trace the problem.
But probably that's not necessary - best would be to put an assert in bitboard.h.
(the "fixes" in bitboard.h are marked with comments and FIXMEs)
I'm not sure if/how this would affect performance and/or variants that use 128-bit bitboards...
I'm going through the changes now to pull them into my repository (with some minor changes, mostly formatting).
inline void set(int bit) {
+ // not sure at all if the following "fix" holds for 128-bit bitboards
+ bit &= sizeof(kind)*8-1;
//printf("%d\n", bit);
bb |= (((kind)1) << bit);
}
inline void reset(int bit) {
+ // FIXME: a value of 125 made it as bit for 64-bit bitboard
+ // not sure at all if the following "fix" holds for 128-bit bitboards
+ bit &= sizeof(kind)*8-1;
bb &= ~(((kind)1) << bit);
}
bool test(int bit) const {
- return bb & (((kind)1) << bit);
+ // not sure at all if the following "fix" holds for 128-bit bitboards
+ bit &= sizeof(kind)*8-1;
+ return (bb & (((kind)1) << bit)) != 0;
}
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.
#if defined _MSC_VER
#else
# include <sys/time.h>
#endif
However, as far as I can see that file should only ever be included if the "elif defined _MSC_VER" does not trigger, so the following should do the exact same thing:
hgm wrote:The problem with mini-Shogi is that the knowledge might not exist. The game was invented only in recent times, and was never played by millions of people, or by professional (min-Shogi) players.
They have not published the games yet, so I have no idea why Shokidoki lost to 1/128 Rigan in the 8th UEC Cup. (Beating it was the only thing required to win the cup.) On several occations it did beat 1/128 Rigan, which got it the gold medal in the 2013 Computer Olympiad. So it is not impossible to win with very little knowledge. (Of course it does have terms like piece values, PST and King safety, but they are all my own guesses.)
I was rather pleased with where SjaakII ended up in the ranking - especially since it managed to beat both 1/128 Rigan and Shokidoki.
SjaakII probably has less knowledge than Shokidoki does, certainly knowledge that is specific to mini-Shogi. However, the game may be sufficiently tactical that it doesn't matter so much...
