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
Stockfish 1.5.1
Moderators: hgm, Rebel, chrisw
-
- Posts: 10281
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: Stockfish 1.5.1
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
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
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: Stockfish 1.5.1
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.Uri Blass wrote: 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.
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.
-
- Posts: 185
- Joined: Sun Feb 01, 2009 7:26 pm
- Location: Germany
- Full name: Rainer Neuhäusler
Re: Stockfish 1.5.1
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
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
-
- Posts: 1383
- Joined: Fri Jul 14, 2006 7:56 am
- Location: London, England
- Full name: Jim Ablett
-
- Posts: 1056
- Joined: Thu Mar 09, 2006 4:15 pm
- Location: Long Island, NY, USA
Re: Stockfish 1.5.1
My early results show that 1.51 is substantially weaker than 1.50.
-
- Posts: 10281
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: Stockfish 1.5.1
I read the following in the subject about 1.5mcostalba wrote: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.Uri Blass wrote: 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.
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.
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
Re: Stockfish 1.5.1
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?
-
- Posts: 2041
- Joined: Wed Mar 08, 2006 8:30 pm
Re: Stockfish 1.5.1
Infinite analysis from start_position is identical in 1.5 and 1.5.1mcostalba wrote: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.
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.
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: Stockfish 1.5.1
Overflow can cause a crash.Uri Blass wrote:
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.
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 (int j = 0; j < ply; j++)
if (st[j].key == p.get_key()) stop = true;
}
pv[ply] = MOVE_NONE;
}
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() || ply < 2)
&& ply < pvSize)
{
pv[ply] = tte->move();
p.do_move(pv[ply++], st);
}
pv[ply] = MOVE_NONE;
}
Code: Select all
&& ply < pvSize
Code: Select all
pv[ply] = tte->move();