LMR questions

[Evert]

it seems to work fine at blitz time control, and has a time stamp in October 2011.

Ok. That's good to know.

are these two separate versions with code evolving differently ? I would have assumed, it was just a question of #ifdef's and different compiles

Not exactly.
Jazz (and Sjaak, for that matter) are designed as libraries with functions that can be used to play chess. To actually create a working program out of that, I have a program that acts as a bridge between the user and the library, either as an XBoard engine, a UCI engine, a perft-counter, a native GUI or a program that loads and analyses EPD files.
All chess-playing code is in the library (which could even by a dynamic library, although the causes problems when play-testing different versions against eachother) and all interface code is in the program, so in principle any bugfixes and enhancements to the library end up in the programs that link to it.
Of course, that doesn't mean there can't be bugs in the interface code, or in the interaction with the library code. The oldest interface code is the UCI code (because the UCI protocol is less daunting at first than the XBoard protocol) but I haven't used, tested or updated it extensively for a while, unlike the XBoard interface. For instance, one of the last log messages for the UCI interface is

Code: Select all

r432 | eglebbk | 2011-02-27 05:11:55 +0100 (Sun, 27 Feb 2011) | 2 lines

Add pondering to the UCI interface (untested).

It should work, because the code is in the library and I know it works through the XBoard interface because I tested that, but it isn't tested for UCI.

The reason the XBoard code is now better tested than the UCI code is twofold: the interface I use is XBoard (I know, I can and have used polyglot, but it's a bit more hassle) and the XBoard protocol is a better match to how Jazz works internally (UCI basially assumes that the program will treat every move indepenently, but Jazz doesn't. For every new move, I have to clear the move list I already have and reset the board, set up the initial position and replay the game. I'd destroy the old game and create a new one except I want to hang on to the transposition table).

Anyway, long story short, if the UCI interface is working fine, great. If there are problems with it, you may want to try the XBoard version. Either way, let me know and I'll try to fix it.

[Evert]

OK my test is finished, and once again Robert was right:
* bad checks (SEE < 0, non discovered checks) should -not only- not be extended, but in fact they should be reduced !

I think I can confirm this for Sjaak as well.*
The test is not quite done yet, but the error bar on the rating is smaller than the rating difference between versions. Of course, for Sjaak a "proper" test uses different variants, I've only done regular chess so far. I don't expect this to be very different for other variants, but I'll check to make sure.

* Sortof. I actually reduce captures with SEE>0 by 2 ply if the side to move is in check (which means the last move by the opponent was a checking move with SEE<0). The first ply undoes the check extension (which is awarded at the top of the search) and the second actually reduces the move. That means I don't reduce normal evasions after a checking move with SEE < 0, but that's probably ok, since the capture is tried first and the evasions don't get tested unless the capture actually fails low (in which case it would also be re-searched to unreduced depth).

[lkaufman]

OK my test is finished, and once again Robert was right:
* bad checks (SEE < 0, non discovered checks) should -not only- not be extended, but in fact they should be reduced !

I think I can confirm this for Sjaak as well.*
The test is not quite done yet, but the error bar on the rating is smaller than the rating difference between versions. Of course, for Sjaak a "proper" test uses different variants, I've only done regular chess so far. I don't expect this to be very different for other variants, but I'll check to make sure.

* Sortof. I actually reduce captures with SEE>0 by 2 ply if the side to move is in check (which means the last move by the opponent was a checking move with SEE<0). The first ply undoes the check extension (which is awarded at the top of the search) and the second actually reduces the move. That means I don't reduce normal evasions after a checking move with SEE < 0, but that's probably ok, since the capture is tried first and the evasions don't get tested unless the capture actually fails low (in which case it would also be re-searched to unreduced depth).

What is the advantage of doing this versus reducing the bad check itself? I see why it might not hurt, but is there a benefit?

[Evert]

What is the advantage of doing this versus reducing the bad check itself? I see why it might not hurt, but is there a benefit?

I have no way to test whether the move gives check short of making it on the board and testing whether the king is under attack - which I will do anyway for moves that I make on the board and would like to avoid for moves that end up being pruned.
I could possibly add a function to Jazz that detects whether a move delivers check (in fact, I think I may have such a function, but I don't claim it's efficient), but Sjaak is also a general variant engine that has to deal with arbitrary user-defined pieces and adding a function like that will not only be a lot of work, it'll also be rather slow.

In short, the benefit for me is ease of implementation, which is very engine-specific. There may be some benefit to not reducing evasions if the supposedly good capture doesn't fail high as expected, but I don't know (and can't test easily).

In fact, thinking about it now, because I don't know whether a move is a checking move before I make it on the board, losing captures are likely to be reduced already. The in-check extension then undoes that, and my new test then undoes the check extension and reduces the move again. So effectively I reduce checks with SEE<0 by 2 ply rather than one as I intended. It still seems to be better, but I guess I'll have to rerun the test for 1 ply as well.

[lucasart]

it seems to work fine at blitz time control, and has a time stamp in October 2011.

Ok. That's good to know.

are these two separate versions with code evolving differently ? I would have assumed, it was just a question of #ifdef's and different compiles

Not exactly.
Jazz (and Sjaak, for that matter) are designed as libraries with functions that can be used to play chess. To actually create a working program out of that, I have a program that acts as a bridge between the user and the library, either as an XBoard engine, a UCI engine, a perft-counter, a native GUI or a program that loads and analyses EPD files.
All chess-playing code is in the library (which could even by a dynamic library, although the causes problems when play-testing different versions against eachother) and all interface code is in the program, so in principle any bugfixes and enhancements to the library end up in the programs that link to it.
Of course, that doesn't mean there can't be bugs in the interface code, or in the interaction with the library code. The oldest interface code is the UCI code (because the UCI protocol is less daunting at first than the XBoard protocol) but I haven't used, tested or updated it extensively for a while, unlike the XBoard interface. For instance, one of the last log messages for the UCI interface is

Code: Select all

r432 | eglebbk | 2011-02-27 05:11:55 +0100 (Sun, 27 Feb 2011) | 2 lines

Add pondering to the UCI interface (untested).

It should work, because the code is in the library and I know it works through the XBoard interface because I tested that, but it isn't tested for UCI.

The reason the XBoard code is now better tested than the UCI code is twofold: the interface I use is XBoard (I know, I can and have used polyglot, but it's a bit more hassle) and the XBoard protocol is a better match to how Jazz works internally (UCI basially assumes that the program will treat every move indepenently, but Jazz doesn't. For every new move, I have to clear the move list I already have and reset the board, set up the initial position and replay the game. I'd destroy the old game and create a new one except I want to hang on to the transposition table).

Anyway, long story short, if the UCI interface is working fine, great. If there are problems with it, you may want to try the XBoard version. Either way, let me know and I'll try to fix it.

OK I see. Both (UCI and XBoard) work fine in cutechess-cli, so it makes no difference (so long as it doesnt crash and the chess code is the same).
My little tournament is finished, and Jazz beat DoubleCheck by 50 elo after 300 games. So it's encouraging, and DoubleCheck didn't look ridiculous as I expected. Overall I estimate that fixing this little "finesses" of which moves to reduce and which to extend, gave DC about 75 elo. And that's from an LMR, which I thought was efficient as it used conditions quite similar to the ones in Fruit.