hgm wrote:Well, actually 'open source' does mean access to the source code. It seems some people are now trying to hijack that terminology for there own purposes. Best ignore them...
Oxford American Dictionaries hasn't ignored them:
open-source
adjective
[Computing] denoting software for which the original source code is made freely available and may be redistributed with or without modification.
jdart wrote:I reported recently that Winboard protocol support is broken in TSCP, when running matches, and I haven't had an answer (so far).
FYI the gist of the problem is this:
TSCP (1.81) can send an extra move after game end, which causes Winboard to pop up an error dialog and abort the next game. This occurs if the other side has resigned or if Winboard has adjudicated the game (in case of being checkmated or stalemated, TSCP has no moves so it won't send one).
The root cause of this appears to be that TSCP doesn't monitor input while searching, or before sending a move, but only afterwards.
Arasan now starts an input polling thread and this runs asynchronously with the search. When the search is running, commands such as "quit" or "result" get pushed onto a stack and the terminate flag is set. When the search completes, it first looks into the stack to see if a game ending command is present, and if so it does not send the move. Then it executes the pending commands in the stack before reading any new ones.
This is not actually much code and if implemented would have the side benefit of enabling TSCP to easily support ponder, which it doesn't, currently.
Jim has done a modification to address probably the problem you mentioned. It is in tscp-181e-ja (tscp-181d). I have tested this version for some matches and looks fine. I use the winboard 4.6.beta 120408.
if (side == computer_side) {
if (x <= -9998) { // small fix to stop engine from continuing to
computer_side = EMPTY; // search after lost game has ended - JA
continue;
}
think(post);
if (!pv[0][0].u) {
computer_side = EMPTY;
continue;
}
printf("move %s\n", move_str(pv[0][0].b));
makemove(pv[0][0].b);
ply = 0;
gen();
print_result();
continue;
}
if (side == computer_side) {
if (x <= -9998) { // small fix to stop engine from continuing to
computer_side = EMPTY; // search after lost game has ended - JA
continue;
}
think(post);
if (!pv[0][0].u) {
computer_side = EMPTY;
continue;
}
printf("move %s\n", move_str(pv[0][0].b));
makemove(pv[0][0].b);
ply = 0;
gen();
print_result();
continue;
}
I'm afraid that "working" on eval is not a trivial task.
There are costs (-elo) implementing ideas and then they should bring some +elo too.
Even with many engines exposing eval parameters,
not many people come with better parameters,testing is such a chore.Which also makes uci parameters a lot less interesting than they seem
With a certain nimzo version there was even a whole programming language to rewrite its eval,ofcouse all "experts" were invisible...
gleperlier wrote:
I'm afraid that "working" on eval is not a trivial task.
There are costs (-elo) implementing ideas and then they should bring some +elo too.
Even with many engines exposing eval parameters,
not many people come with better parameters,testing is such a chore.Which also makes uci parameters a lot less interesting than they seem
With a certain nimzo version there was even a whole programming language to rewrite its eval,ofcouse all "experts" were invisible...
Yes I can see it. This is kind of "just for fun" idea.