Stockfish 1.5.1

[mcostalba]

I am not sure that the size of pv is PLY_MAX_PLUS_2

if the pv is from the SearchStack then
I can see the following code as part of stockfish in search.h.

struct SearchStack {
Move pv[PLY_MAX];

Hmmmm....

SearchStack definition is:

Code: Select all

struct SearchStack {
  Move pv[PLY_MAX];
  Move currentMove;
  Move mateKiller;
  Move threatMove;
  Move killers[KILLER_MAX];
  Depth reduction;

  void init(int ply);
  void initKillers();
};

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.

Thanks again !

[Han Chengye]

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

If you wait a few hours, source code and binaries will be available from http://www.glaurungchess.com.

i try to translate it to chinese chess, a immposible mission, maybe

It's a difficult, but very interesting project. I would be glad to give you some help and advice on the way.

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:

class Bitboard{
public:
uint_32 data[4];
operator and, or,etc
}

class Bitboard_R90{
public:
uint_32 data[3];
operator and, or,etc
}

then use precaculated bitarray for rook, cannon, and horse move generation.

yes, i may talk this in another thread. or email if you please.

i've got the source from Marco

thanks a lot

[Volker Pittlik]

...
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.

vp

[Alexander Schmidt]

What time control have you used ?

10s/game+0,5s/move

[Sylwy]

Thanks for the update. Quick question: if I wanted to create the most vicious and aggressive personality for SF........, what would you suggest ..................

Let it tipple please !




PS: have a nice weekend !

[F.Huber]

Stockfish 1.5.1 Windows x64 & win32 builds

http://www.mediafire.com/?mhztmwj5tmq

Many thanks Jim,

you are one of the very rare programmers who still support Win98 users!

Although also your normal (non-Win98) compile is working in Win98, but it runs more than 10-times slower!

Regards,
Franz

[Tord Romstad]

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.

[Tord Romstad]

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.

Code: Select all

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?

[schlucke]

Optimized (Intel PGO) builds for Mac OS X 10.6 (32 and 64 Bit Intel): http://www.leakyheap.de/cf/Stockfish-1.5.1-mac.zip

[michiguel]

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:

Code: Select all

pv[ply] = MOVE_NONE; 

But it is not because if you see the definition of pv is:

Code: Select all

Move pv[PLY_MAX_PLUS_2];

And the calling site is:

Code: Select all

TT.extract_pv(pos, ss[0].pv, PLY_MAX);

So actually size of pv is 2 more then pvSize.


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.

Miguel