Stockfish 1.5.1

[mcostalba]

This is Stockfish 1.5.1

You can download the sources from:
http://www.mediafire.com/?5jx12zdyygw

This is a maintenance release that fixes following bugs:

- Chess960 is now fully functional

- Fix of a rare crash that could occur at long time controls, but also at shorter ones if you are very unlucky.

- Less prone to lose on time especially at very fast games.


It is important to say that functionality and speed is 100% the same of 1.5, IOW there is no change in strength, so if you have already started to test you don't need to start again.


Please Jim, would you be so kind to build the pgo binaries. Thanks in advance. Also we would like to thank all the people that in public or privately helped reporting bug and testing the fixes in these few but intense days.


Best wishes,
Tord Romstad, Marco Costalba, Joona Kiiski

[Uri Blass]

I think that only not losing on time with no more changes is a playing strength improvement.

The question is also if the bug that leads to losing on time cannot lead to inferior moves without losing on time in other cases.

Uri

[mcostalba]

The question is also if the bug that leads to losing on time cannot lead to inferior moves without losing on time in other cases.

Node count when searching at fixed depth is the same for any position and for any depth. The two versions are 100% identical in the moves that they play.

Regarding losing on time it depends, on offical tests like CEGT the time control used is so big 40/20 or 40/4 that you should not experience losing on time. And if you avoid also some GUI that seems to introduce latency accounted on the engine's time you very rarely lose on time also with fast controls.

But 1.5.1 should now be resistant also to the most difficult GUI out there.

[rainhaus]

hello,
you are faster in fixing a bug than I can post my report about it! Ok, into the trash with it and all we have to do is waiting for Jim Ablett. I had three time forfeits by hang-ups within 32 games and I was about to test several promising counter measures.., but of course I have to be happy when it is purged by now
regards

[Jim Ablett]

Stockfish 1.5.1 Windows x64 & win32 builds

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

Jim.

[Norm Pollock]

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

[Uri Blass]

The question is also if the bug that leads to losing on time cannot lead to inferior moves without losing on time in other cases.

Node count when searching at fixed depth is the same for any position and for any depth. The two versions are 100% identical in the moves that they play.

Regarding losing on time it depends, on offical tests like CEGT the time control used is so big 40/20 or 40/4 that you should not experience losing on time. And if you avoid also some GUI that seems to introduce latency accounted on the engine's time you very rarely lose on time also with fast controls.

But 1.5.1 should now be resistant also to the most difficult GUI out there.

I read the following in the subject about 1.5

Joona Kiiski:

"Thank you very much for your report!!

I've tracked down the problem and it is indeed not at all related to time management. It results from overflow issue which was already fixed in devel-branch few days ago. The fix will be included in maintenance release 1.5.1 which will hopefully be released soon "

The question is if overflow cannot cause other problems that are not losing on time.

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.

Uri

[Hart]

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?

[ernest]

Node count when searching at fixed depth is the same for any position and for any depth. The two versions are 100% identical in the moves that they play.

Infinite analysis from start_position is identical in 1.5 and 1.5.1
The 1.5.1 version does seem 1% slower

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.

[mcostalba]

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.