Designing an analysis friendly Stockfish?

[fruity]

Final result: +13169 -12852 =33979 (+2 Elo)

[Uly]

I would be happy if fruity's improvements were used on the official Stockfish, since they don't seem to hurt and they make analysis (where unlike games, it's important to revisit positions and transpositions over and over) better.

[mcostalba]

I would be happy if fruity's improvements were used on the official Stockfish, since they don't seem to hurt and they make analysis (where unlike games, it's important to revisit positions and transpositions over and over) better.

Using of TT also in PV nodes will be used on the official Stockfish. This feature allows a better analyzing experience for the user. Probably we will remain on the first posted version. The fruity's extension to qsearch() seems to have no measurable effect apart from super fast TC so I'd try to avoid code that has no effect. Actually there is an ongoing effort to remove useless - harmless code in SF with the aim to leave in only code that really has an impact.

[Uly]

Thanks Marco, did you see the behavior report at this post?

http://www.open-chess.org/viewtopic.php ... &start=184

One would like Stockfish to behave like in the bottom (Stockfish_201_PA_GTBf.7z) instead like in the top (back-ported code), the time saved does accumulate and has an impact on analysis, another option would be to have an UCI option for analysis, if you don't want some behavior on games (or it turns out to lose 2 elo or something, that means nothing for analysis as more time is saved the more interaction and positions analyzed that one does).

[fruity]

I would be happy if fruity's improvements were used on the official Stockfish, since they don't seem to hurt and they make analysis (where unlike games, it's important to revisit positions and transpositions over and over) better.

Using of TT also in PV nodes will be used on the official Stockfish. This feature allows a better analyzing experience for the user. Probably we will remain on the first posted version. The fruity's extension to qsearch() seems to have no measurable effect apart from super fast TC so I'd try to avoid code that has no effect. Actually there is an ongoing effort to remove useless - harmless code in SF with the aim to leave in only code that really has an impact.

What's the Elo gain on probing at PV nodes with your first given version vs SF default?

[mcostalba]

What's the Elo gain on probing at PV nodes with your first given version vs SF default?

After 5811 games Mod- Orig: 1037 - 902 - 3872 +8 ELO (+- 3.6) LOS 97%

[fruity]

What's the Elo gain on probing at PV nodes with your first given version vs SF default?

After 5811 games Mod- Orig: 1037 - 902 - 3872 +8 ELO (+- 3.6) LOS 97%

Ok thanks. I will retest my modification against SF default, TC 20''+0.1, 4 threads.
Or did you use other TC/threads usage parameters for this test?

[fruity]

Thanks Marco, did you see the behavior report at this post?

http://www.open-chess.org/viewtopic.php ... &start=184

One would like Stockfish to behave like in the bottom (Stockfish_201_PA_GTBf.7z) instead like in the top (back-ported code), the time saved does accumulate and has an impact on analysis, another option would be to have an UCI option for analysis, if you don't want some behavior on games (or it turns out to lose 2 elo or something, that means nothing for analysis as more time is saved the more interaction and positions analyzed that one does).

There is no Elo loss. Bob Hyatt was right. Pruning on apropriate TT hits in PV case gains a few Elo points. Without this thread the SF programmers probably would not have tried to use TT pruning at PV nodes, at least not so soon. SF 2.1 or whatever it will be called would be about 8 Elo weaker without your genius thread! So let me thank you.

[mcostalba]

Ok thanks. I will retest my modification against SF default, TC 20''+0.1, 4 threads.
Or did you use other TC/threads usage parameters for this test?

No, I used the same setup.

[Peter C]

New builds for anyone who likes. It's essentially the MC + Peter C additions + Fruity code + GTB support. TBs now display the full main line (up to MAX_PLY, which means you'll get maximum 101 moves for the PV). This might be a good time to determine if smooth scaling does anything useful...

Enjoy!
jb

As far as I can tell, smooth scaling makes it weaker (sometimes significantly), but has a habit of suggesting interesting analysis moves. I put it in there mostly just because I could and it can be handy for analysis, but it for sure has a negative Elo value (which is why it's off by default). The parameters for it could be tuned a bit, maybe we can get something useful from it.

Peter