Komodo 10.4 released

[Ron Langeveld]

Preliminary results I got are:
About 12.000 kN/s in start position with a Ryzen 1800X (HT)
versus 9.5000 kN/s with a 5960X Intel 8-core desktop (no-HT)

Ron:
Assuming you got these numbers from your GUI, after how many seconds did you take the readings?

Also, when will we see you in the Finals of ICCF WC?

Since a few seconds is not enough to get a stable nps I let it run at least a few minutes.

No ICCF WC Final for me in the near future but I will be playing in a strong tournament later this year.

[lkaufman]

I think that sometimes one changes the value of a parameter and its a win, not because the evaluation merits it, but because it differentiates a set of positions that get found quicker, so this helps move order.

Yes, that is quite plausible, although the difference in depth reached comparing SF to a modified Komodo with SF-like search is larger than I would expect from your explanation. Any idea what part of the SF eval is especially suited for efficient pruning?

In chess there are many moves that lose, many than draw, and just a few that win.

Stockfish seems specially efficient at not losing, so it discards fast losing moves. This points to threat stuff and of course king safety. But is also required to put well the pieces, on contrary one generates a lot of losing possibilities. So other positional stuff is also key. Yes, I know I'm being little specific But I cannot be very specific, as is the combined effect that gives the result, obviously.

Stockfish is quickly satisfied with some not losing or narrowly losing move, discarding other stuff. For me this points somehow to the efficiency of having fewer eval parameters. I mean that other engines with more ellaborated eval can doubt between various non losing moves, thus losing unnecesarily time. This Stockfish effect is good for not losing, but not for generating winning possibilities. The second in Stockfish is more given with the increased depth.

Komodo, like many other engines, uses millipawn evaluation but rounds to centipawns. So I would expect that it would generally behave more or less like an engine that only used centipawn eval (like Ippolit). Is there perhaps some flaw in using precise eval but rounding to reduce the tree?

[cdani]

Komodo, like many other engines, uses millipawn evaluation but rounds to centipawns. So I would expect that it would generally behave more or less like an engine that only used centipawn eval (like Ippolit). Is there perhaps some flaw in using precise eval but rounding to reduce the tree?

Ah! Why not! "Eval instability" Sincerely I doubt that this can affect a lot.

Maybe you can try to, instead of maintaining centipawn for all the search stuff, divide the eval value by something like 4 to maintain better precission but be able to store this value in tt, and only use cp for presentation. It would probably be quite a work, though.

[cdani]

Maybe you can try to, instead of maintaining centipawn for all the search stuff, divide the eval value by something like 4 to maintain better precission but be able to store this value in tt, and only use cp for presentation. It would probably be quite a work, though.

Or maybe you have two spare bits in tt, and you can store full millipawn evaluation.

[Jesse Gersenson]

Or maybe you have two spare bits in tt, and you can store full millipawn evaluation.

Or save a few bits and just store eval in decipawns.

[mjlef]

Or maybe you have two spare bits in tt, and you can store full millipawn evaluation.

Or save a few bits and just store eval in decipawns.

Technically you only need 2 bits to store a position. Win, loss or draw!

[Ozymandias]

Technically you only need 2 bits to store a position. Win, loss or draw!

Actually, you only need one; if you're lost, what does it matter what you play?

[cdani]

Or maybe you have two spare bits in tt, and you can store full millipawn evaluation.

Or save a few bits and just store eval in decipawns.

I'm not sure if was understood what I meant, but for if is not the case, I meant 16 bits + 2 bits should be enough to save the millipawn evaluation in tt.

[Nordlandia]

Komodo 10.4 detected 31. Kh2 in the famous Short - Timman 1991 game.

Komodo 10.4 also add more insight into the famous Spassky v Fischer endgame.

[pgn][Event ""]
[White "New game"]
[Black ""]
[Site ""]
[Round ""]
[Annotator ""]
[Result "*"]
[Date ""]
[PlyCount "25"]
[Setup "1"]
[FEN "5k2/pp4pp/4pp2/1P6/8/P2KP1P1/5P1b/2B5 b - - 0 1"]

1... h5 2. Ke2 h4 3. Kf3 h3 4. Kg4 Bg1 5. Kxh3 Bxf2 6. Bd2 Ke7 7. Kg2 Bxe3 (7... Bxg3 8. Kxg3 e5 $4 (8... Kd6 $1 9. Bb4+ Kd5 )9. Bb4+ Ke6 10. e4 g6 11. a4 a6 12. b6 Kd7 13. a5 f5 14. exf5 gxf5 15. Kh4 Kc8 16. Kg5 Kb8 17. Kxf5 Ka8 18. Kxe5 )8. Bxe3 a6 9. b6 Kd6 10. Kf3 Kd5 11. Kf4 g6 12. a4 e5+ 13. Kf3 f5 *

[/pgn]

http://www.viewchess.com/cbreader/2017/ ... 81109.html

[lkaufman]

Komodo, like many other engines, uses millipawn evaluation but rounds to centipawns. So I would expect that it would generally behave more or less like an engine that only used centipawn eval (like Ippolit). Is there perhaps some flaw in using precise eval but rounding to reduce the tree?

Ah! Why not! "Eval instability" Sincerely I doubt that this can affect a lot.

Maybe you can try to, instead of maintaining centipawn for all the search stuff, divide the eval value by something like 4 to maintain better precission but be able to store this value in tt, and only use cp for presentation. It would probably be quite a work, though.

We had the same idea, we may try it, but this will surely not reduce the "depth gap" from Stockfish, although it may help elo a bit. It won't address the issue under discussion. Stockfish used to round off too.