syzygy wrote:In particular if two engines are playing each other on the same machine, it is not correct for one engine to continuously wake up while the other engine is searching.
In my implementation, there is one thread blocking on stdin, and another thread (which would search if it were the engine's turn) polling on an internal queue, waking up every 10 ms. The Windows task manager shows "00" (in percent) for CPU usage, which is why I didn't bother to use OS specific proper blocking.
Proper blocking is easy to achieve. For each search thread i, use CreateEevent() to create a thread->startEvent and a thread->stopEvent HANDLE.
// it's our turn, so start the search threads
for (i = 0; i < num_threads; i++)
SetEvent(thread[i]->startEvent);
// let the main thread search or just wait for input or time running out
// now wait until the search threads have stopped searching
for (i = 0; i < num_threads; i++)
WaitForSingleObject(thread[i]->stopEvent, INFINITE);
// output best move
Carlos777 wrote:It seems the new update is weaker than the 0.92 version, at least under TCEC conditions. Only 0.5 out of 5 games, keeping in mind that in the previous stage Andy remained unbeaten.
Carlos777 wrote:It seems the new update is weaker than the 0.92 version, at least under TCEC conditions. Only 0.5 out of 5 games, keeping in mind that in the previous stage Andy remained unbeaten.
Not so bad in the end, was it?
Maybe I was too quick to affirm that. Andscacs 0.92 finished 4th in the previous stage and 0.921 tied with Booot in the last position in stage 2. I guess this result is normal because few games were played and these engines are close in strenght.
My apologies to Daniel if he took it the wrong way, I was just concerned and dissapointed about Andscacs' bad start. Good luck in next season.
Carlos777 wrote:It seems the new update is weaker than the 0.92 version, at least under TCEC conditions. Only 0.5 out of 5 games, keeping in mind that in the previous stage Andy remained unbeaten.
Not so bad in the end, was it?
Maybe I was too quick to affirm that. Andscacs 0.92 finished 4th in the previous stage and 0.921 tied with Booot in the last position in stage 2. I guess this result is normal because few games were played and these engines are close in strenght.
My apologies to Daniel if he took it the wrong way, I was just concerned and dissapointed about Andscacs' bad start. Good luck in next season.
No problem!! As always, few games are not much significant. Also if Andscacs had not lost the game for the illegal move, it had finished a bit higher, so more similar to what happened in stage 1.
Looks to me Andscacs is playing too many draws. Intention should be to destroy your opponent completely otherwise better not play chess. Better lose than going for a draw.
Henk wrote:Looks to me Andscacs is playing too many draws. Intention should be to destroy your opponent completely otherwise better not play chess. Better lose than going for a draw.
Henk wrote:Looks to me Andscacs is playing too many draws. Intention should be to destroy your opponent completely otherwise better not play chess. Better lose than going for a draw.
That's a matter of opinion.
I am still able to think about something more friendly than capturing a king. Or what do you mean. Is it about Andscacs playing not too many draws or the intention of playing chess.
cdani wrote:As the bug happened in only one move situation,
...
If this is indeed what happened, then the solution is to reset the various thread-specific data structures in the main thread before starting the actual search.
Bravo, Ron !
Seems the craziest bugs can be corrected through logical thinking...
Thank you!! The source code release makes Andscacs eligible for participation in the next season of FOSCEC. Moreover, CCRL should change the engine name color from green to orange!