So that if your off-by-one bug is confirmed it means that in the very unfortunate case we go overflow we end up assigning
SearchStack.currentMove = MOVE_NONE;
This is an unwanted side effect of calling extract_pv(), of course very rare but possible, but should be harmless because we don't use currentMove after calling extract_pv().
Anyhow I think you _could_ be right, a fix IMHO is not necessary because as I said currentMove is not used there, but for sure a patch in the new development version would be needed.
Han Chengye wrote:for some reasons, i can't download anything from www.mediafire.com
anyone would send me a copy of Stockfish 1.5.1 with source code?
my email is hanchengye@gmail.com
THX
Tord Romstad wrote:...
They really should be 100% identical, except for stability, Chess960 and time management when there is less than 5 seconds left on the clock. I'll do some verification myself, just to be sure.
I don't find a difference in strength here on my Linux box. 1.5 and 1.5.1 are at the same level as Rybka 2.2.n2 at 15+5 and 3+3.
Hart wrote:Thanks for the update. Quick question: if I wanted to create the most vicious and aggressive personality for SF........, what would you suggest ..................
Hart wrote:Thanks for the update. Quick question: if I wanted to create the most vicious and aggressive personality for SF, not necessarily the strongest, what would you suggest aside from just setting "Aggressiveness" to 200?
You could try cranking up "Mobility (Middle Game)" and "Space" as well. If this is not enough, try to also increase "King Safety Coefficient", "King Safety Max Slope" and "King Safety Max Value". Just keep in mind that if you go too far with this, it won't look aggressive, but just plain silly.
I would start experimenting with only "Aggressiveness", "Mobility (Middle Game)" and "Space", and increase the other parameters mentioned slowly if the program still doesn't play as aggressively as you would like.
Han Chengye wrote:i'm reading the source code of Stockfish 1.4 now.
here is my plan :
the main differences between chess and chinese chess are 9*10 board and some piece types. so the first thing is to modify those parts of the
source.
i want to use rotated bitboard looking like this:
Rotated bitboards are no longer very popular in computer chess, but are probably more appropriate in xiangqi, where the bigger board makes magic multiplication and similar techniques unfeasible. It also helps that there are no diagonal sliders in xiangqi, which eliminates the need for 45-degree rotated bitboards.
class Bitboard{
public:
uint_32 data[4];
operator and, or,etc
}
class Bitboard_R90{
public:
uint_32 data[3];
operator and, or,etc
}
A couple of (probably related) questions:
How are the ranks and the files of the board distributed over the entries of the data[] arrays? I guess that not splitting a file/rank across two array entries makes looking up in the rotated bitboard attack arrays a little simpler, but on the other hand it seems to make shifting operations trickier to implement.
What's the reason for using data[4] in Bitboard, and data[3] in Bitboard_R90? I thought data[4] was better even if less than 16 bytes were actually used, because array lookups (in arrays of bitboards) were significantly faster when the array entries have size equal to a power of 2. Is this no longer true on modern computers?
Uri Blass wrote:
I do not understand how you are quaranteed against overflow
suppose
ply=pvSize-1
I think that you can get a problem with
p.do_move(pv[ply++], st); because this function is using pv[pvSize] and the maximal value that you are allowed is pvSize-1
Uri
Ok, apart that in pv[ply++] ply is post-incremented so that you are using pv[pvSize-1], you could have problem in the trailing assignement just before to exit the function:
But nevermind one good point your obseravtion has anyway and is that pvSize is a bad name, should be better plyMax.....so I will change that. Thanks
You have a good eye, you should be a good code reviewer....
One stress test that should always be run is to decrease the value of the arrrays that hold PVs etc (PVSIZE) to 8 or something like that, and ran a match. The engine should never crash even in those conditions. A golden rule to catch bugs is to increase the chances for them to show up during testing.