Stockfish 1.5.1

[mcostalba]

And of course, the 64-bit and 32-bit versions still have the different behavior question. BTW, this is so for all Stockfish versions. The question/problem does not exist with the Glaurung versions.

I have started testing with using std::stable_sort() instead of std::sort() for move ordering, this would make behavior identical on any platform.

If performance penalty is accepable we coul use std_stable_sort() in the next version.

Anyhow was not possible to do it now because we wanted to keep 100% functionality unchanged between 1.5.1 and 1.5 to avoid hassles to the testers that had already started with 1.5

[Alexander Schmidt]

My early results show that 1.51 is substantially weaker than 1.50.

My results of testing a beta shows that StockFish 1.5.1 is much weaker than StockFish 1.5.1:

1: StockFish 1.5.1 36,0/60
2: StockFish 1.5.1 24,0/60

But maybe my tests only show that 60 games don't say anything about the strength, the 2 versions where absolut identical

[mcostalba]

My early results show that 1.51 is substantially weaker than 1.50.

My results of testing a beta shows that StockFish 1.5.1 is much weaker than StockFish 1.5.1:

1: StockFish 1.5.1 36,0/60
2: StockFish 1.5.1 24,0/60

But maybe my tests only show that 60 games don't say anything about the strength, the 2 versions where absolut identical

What time control have you used ?

[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

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

[mcostalba]

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

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

I probably know the reason if you are trying to access from China....I am surprised your gmail account works, because also gmail has problems in China "for some reasons", at least when I was there I cannot access my account.

I will send you the sources and binaries as per your requets.

[Tord Romstad]

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.

[Tord Romstad]

My early results show that 1.51 is substantially weaker than 1.50.

My results of testing a beta shows that StockFish 1.5.1 is much weaker than StockFish 1.5.1:

1: StockFish 1.5.1 36,0/60
2: StockFish 1.5.1 24,0/60

But maybe my tests only show that 60 games don't say anything about the strength, the 2 versions where absolut identical

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.

[Uri Blass]

based on my understanding overflow is a case when you have some array like int a[100] and later try to change a[x] fpr x>=100 or for x<0 and it may change other variables and cause the program to crash.

Maybe it is not the problem of stockfish but Joona Kiiski did not gave a clear explanation to describe the problem that caused stockfish to lose on time.

Overflow can cause a crash.

This is the code

1.5 version

Code: Select all

void TranspositionTable::extract_pv(const Position& pos, Move pv[]) {

  int ply;
  Position p(pos);
  StateInfo st[100];

  for (ply = 0; pv[ply] != MOVE_NONE; ply++)
      p.do_move(pv[ply], st[ply]);

  bool stop;
  const TTEntry* tte;
  for (stop = false, tte = retrieve(p.get_key());
       tte && tte->move() != MOVE_NONE && !stop;
       tte = retrieve(p.get_key()), ply++)
  {
      if (!move_is_legal(p, tte->move()))
          break;
      pv[ply] = tte->move();
      p.do_move(pv[ply], st[ply]);
      for &#40;int j = 0; j < ply; j++)
          if &#40;st&#91;j&#93;.key == p.get_key&#40;)) stop = true;
  &#125;
  pv&#91;ply&#93; = MOVE_NONE;
&#125;

and this is 1.5.1 version

Code: Select all

void TranspositionTable::extract_pv(const Position& pos, Move pv[], int pvSize) {
 
  const TTEntry* tte;
  StateInfo st;
  Position p(pos);
  int ply = 0;

  // Update position to the end of current PV
  while (pv[ply] != MOVE_NONE)
      p.do_move(pv[ply++], st);

  // Try to add moves from TT until possible
  while (   (tte = retrieve(p.get_key())) != NULL
         && tte->move() != MOVE_NONE
         && move_is_legal(p, tte->move())
         && (!p.is_draw&#40;) || ply < 2&#41;
         && ply < pvSize&#41;
  &#123;
      pv&#91;ply&#93; = tte->move&#40;);
      p.do_move&#40;pv&#91;ply++&#93;, st&#41;;
  &#125;
  pv&#91;ply&#93; = MOVE_NONE;
&#125;

Now thanks to the condition

Code: Select all

&& ply < pvSize

you are guaranteed against overflow in

Code: Select all

pv[ply] = tte->move(); 

Hope it is clear.

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

[mcostalba]

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

[Uri Blass]

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

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];