Komodo 10.4 released

Discussion of anything and everything relating to chess playing software and machines.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Ron Langeveld
Posts: 138
Joined: Tue Jan 05, 2010 7:02 pm

Re: Komodo 10.4 released

Post by Ron Langeveld » Sat Mar 18, 2017 12:03 am

cma6 wrote:
Ron Langeveld wrote: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
Posts: 4324
Joined: Sun Jan 10, 2010 5:15 am
Location: Maryland USA
Contact:

Re: Komodo 10.4 released

Post by lkaufman » Sat Mar 18, 2017 4:34 am

cdani wrote:
lkaufman wrote:
cdani wrote: 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?
Komodo rules!

User avatar
cdani
Posts: 2173
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Komodo 10.4 released

Post by cdani » Sat Mar 18, 2017 7:35 am

lkaufman wrote: 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.

User avatar
cdani
Posts: 2173
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Komodo 10.4 released

Post by cdani » Sat Mar 18, 2017 8:20 am

cdani wrote: 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
Posts: 582
Joined: Sat Aug 20, 2011 7:43 am
Contact:

Re: Komodo 10.4 released

Post by Jesse Gersenson » Sat Mar 18, 2017 12:20 pm

cdani wrote: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
Posts: 1454
Joined: Thu Mar 30, 2006 12:08 pm
Contact:

Re: Komodo 10.4 released

Post by mjlef » Sat Mar 18, 2017 1:06 pm

Jesse Gersenson wrote:
cdani wrote: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! :-)

User avatar
Ozymandias
Posts: 1214
Joined: Sun Oct 25, 2009 12:30 am

Re: Komodo 10.4 released

Post by Ozymandias » Sat Mar 18, 2017 1:12 pm

mjlef wrote: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?

User avatar
cdani
Posts: 2173
Joined: Sat Jan 18, 2014 9:24 am
Location: Andorra
Contact:

Re: Komodo 10.4 released

Post by cdani » Sat Mar 18, 2017 1:19 pm

Jesse Gersenson wrote:
cdani wrote: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.

User avatar
Nordlandia
Posts: 2649
Joined: Fri Sep 25, 2015 7:38 pm
Location: Sortland, Norway

Re: Komodo 10.4 released

Post by Nordlandia » Sat Mar 18, 2017 1:26 pm

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
Posts: 4324
Joined: Sun Jan 10, 2010 5:15 am
Location: Maryland USA
Contact:

Re: Komodo 10.4 released

Post by lkaufman » Sat Mar 18, 2017 3:31 pm

cdani wrote:
lkaufman wrote: 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.
Komodo rules!

Post Reply