Next Handicap Match

[lkaufman]

The next Komodo handicap match is now scheduled for 11 a.m. Wednesday, Sept. 2, against FM John Meyer, FIDE 2270, who defeated Rybka at knight odds over 7 years ago by 4 wins to zero, no draws. John is now 70 years old but still plays regularly in League matches and maintains his USCF rating above his 2200 "floor", so although his FIDE rating is unrealistic, he is probably close in strength to FM Bolzoni who recently scored four wins, one draw, and one loss at knight odds against Komodo.
Since it seems unlikely in view of this that Komodo can win or draw a match at knight odds (even with draw odds in each game) with an FM, we decided to try knight for pawn odds this time, but with no draw odds for Komodo. It will be a four game match at our standard 45' + 15" time control. White (Komodo) plays without his b1 knight, while Black removes the c7 pawn in one game, d7 in another, e7 in a third, and f7 in a fourth game. The d7 game should be the most favorable for Black, as he already has great mobility for queen and bishop at the start, while f7 should be the most difficult as the slightly weakened Black king rules out some defenses. But Black won't have the same opening problems as in a pure f7 handicap game, because the missing White knight makes both the French defense and 1.e4 d6 2.d4 Nf6 quite okay for Black.
In the opening a knight is worth at least four pawns, so knight for pawn is a much larger handicap than the two pawn handicaps given to grandmasters in the last two matches, especially since Black will benefit from increased mobility in three of the four games. I suppose this increased handicap roughly offsets the estimated 300 elo difference in strength between John and the average of the two GMs who played at two pawns, but it's just a guess. Since the two GM matches produced a combined score of 50% in the eleven games played at two pawn handicap, this seems pretty fair to me. But it's hard to say.
There may also be a couple of games this Monday at knight odds against a 2100 FIDE player, but I don't know yet if this will be broadcast or not. If not I'll plan to post the games afterward.
I'll post broadcast info on the Meyer match when available. One week later will be the match with GM Movsesian.

[duncan]

The next Komodo handicap match is now scheduled for 11 a.m. Wednesday, Sept. 2, against FM John Meyer, FIDE 2270, who defeated Rybka at knight odds over 7 years ago by 4 wins to zero, no draws. John is now 70 years old but still plays regularly in League matches and maintains his USCF rating above his 2200 "floor", so although his FIDE rating is unrealistic, he is probably close in strength to FM Bolzoni who recently scored four wins, one draw, and one loss at knight odds against Komodo.
Since it seems unlikely in view of this that Komodo can win or draw a match at knight odds (even with draw odds in each game) with an FM, we decided to try knight for pawn odds this time, but with no draw odds for Komodo. It will be a four game match at our standard 45' + 15" time control. White (Komodo) plays without his b1 knight, while Black removes the c7 pawn in one game, d7 in another, e7 in a third, and f7 in a fourth game. The d7 game should be the most favorable for Black, as he already has great mobility for queen and bishop at the start, while f7 should be the most difficult as the slightly weakened Black king rules out some defenses. But Black won't have the same opening problems as in a pure f7 handicap game, because the missing White knight makes both the French defense and 1.e4 d6 2.d4 Nf6 quite okay for Black.
In the opening a knight is worth at least four pawns, so knight for pawn is a much larger handicap than the two pawn handicaps given to grandmasters in the last two matches, especially since Black will benefit from increased mobility in three of the four games. I suppose this increased handicap roughly offsets the estimated 300 elo difference in strength between John and the average of the two GMs who played at two pawns, but it's just a guess. Since the two GM matches produced a combined score of 50% in the eleven games played at two pawn handicap, this seems pretty fair to me. But it's hard to say.
There may also be a couple of games this Monday at knight odds against a 2100 FIDE player, but I don't know yet if this will be broadcast or not. If not I'll plan to post the games afterward.
I'll post broadcast info on the Meyer match when available. One week later will be the match with GM Movsesian.

great experiments you are doing. keep up the good work!

[Laskos]

Not wanting to open a new thread and being related to the topic (testing these handicaps), I got something messed up with Komodo 9.2. It seems that Komodo is as random on 1 core as it is on 2 or 4 cores. I used Adam Hair modification of Don's similarity tester, where Adam set the tool to send "ucinewgame" and "Clear Hash" before each position is sent. The self-similarity with these settings went very high on one core on all engines I tested previously, not many of them though (Stockfish, Houdini, Critter, and some other). Komodo behaves differently, if I am not doing something wrong, or Komodo doesn't understand "ucinewgame". Here are the self-similarity for given time per move and cores for Komodo and the typical (for strong engines) Stockfish:

Code: Select all

Komodo 9.2:

1 core   20ms : 58.69%    100ms : 61.56%  
2 core   20ms : 60.82%
4 core   20ms : 61.80%



Stockfish 20082015:

1 core   20ms : 99.53%    100ms : 98.83%
2 core   20ms : 67.75%
4 core   20ms : 64.81%

If this result holds, then one can safely test Komodo on 1 core without opening books in these odds matches in order to test. It will somehow speedup the testing if time control is not the most relevant part. But I still don't understand the high randomness of 1 core Komodo, what the heck is it doing, do you have a a randomizer somewhere there in the search or move generator?

[mjlef]

Not wanting to open a new thread and being related to the topic (testing these handicaps), I got something messed up with Komodo 9.2. It seems that Komodo is as random on 1 core as it is on 2 or 4 cores. I used Adam Hair modification of Don's similarity tester, where Adam set the tool to send "ucinewgame" and "Clear Hash" before each position is sent. The self-similarity with these settings went very high on one core on all engines I tested previously, not many of them though (Stockfish, Houdini, Critter, and some other). Komodo behaves differently, if I am not doing something wrong, or Komodo doesn't understand "ucinewgame". Here are the self-similarity for given time per move and cores for Komodo and the typical (for strong engines) Stockfish:

Code: Select all

Komodo 9.2:

1 core   20ms : 58.69%    100ms : 61.56%  
2 core   20ms : 60.82%
4 core   20ms : 61.80%



Stockfish 20082015:

1 core   20ms : 99.53%    100ms : 98.83%
2 core   20ms : 67.75%
4 core   20ms : 64.81%

If this result holds, then one can safely test Komodo on 1 core without opening books in these odds matches in order to test. It will somehow speedup the testing if time control is not the most relevant part. But I still don't understand the high randomness of 1 core Komodo, what the heck is it doing, do you have a a randomizer somewhere there in the search or move generator?

This is most likely due to Komodo not clearing the history/move ordering tables it uses when sent a ucinewgame. It is useful to have the engine slightly random a little in testing. If you want to get rid of randomness, just reload the engine between games since it will zero out the move ordering tables on a restart. If thee is a big demand for it playing identical games after a ucinewgame, I could add an option for that.

[Lanzo]

Not wanting to open a new thread and being related to the topic (testing these handicaps), I got something messed up with Komodo 9.2. It seems that Komodo is as random on 1 core as it is on 2 or 4 cores. I used Adam Hair modification of Don's similarity tester, where Adam set the tool to send "ucinewgame" and "Clear Hash" before each position is sent. The self-similarity with these settings went very high on one core on all engines I tested previously, not many of them though (Stockfish, Houdini, Critter, and some other). Komodo behaves differently, if I am not doing something wrong, or Komodo doesn't understand "ucinewgame". Here are the self-similarity for given time per move and cores for Komodo and the typical (for strong engines) Stockfish:

Code: Select all

Komodo 9.2:

1 core   20ms : 58.69%    100ms : 61.56%  
2 core   20ms : 60.82%
4 core   20ms : 61.80%



Stockfish 20082015:

1 core   20ms : 99.53%    100ms : 98.83%
2 core   20ms : 67.75%
4 core   20ms : 64.81%

If this result holds, then one can safely test Komodo on 1 core without opening books in these odds matches in order to test. It will somehow speedup the testing if time control is not the most relevant part. But I still don't understand the high randomness of 1 core Komodo, what the heck is it doing, do you have a a randomizer somewhere there in the search or move generator?

This is most likely due to Komodo not clearing the history/move ordering tables it uses when sent a ucinewgame. It is useful to have the engine slightly random a little in testing. If you want to get rid of randomness, just reload the engine between games since it will zero out the move ordering tables on a restart. If thee is a big demand for it playing identical games after a ucinewgame, I could add an option for that.

There's a huge demand among various communities for a 32bit binary (with and without POPCNT) that'll run on Linux, and you haven't done anything about it. That's why we have ceased to sum up any demands, we say to ourselves "If that Lefler won't bother, why should we bother?"

[mjlef]

Not wanting to open a new thread and being related to the topic (testing these handicaps), I got something messed up with Komodo 9.2. It seems that Komodo is as random on 1 core as it is on 2 or 4 cores. I used Adam Hair modification of Don's similarity tester, where Adam set the tool to send "ucinewgame" and "Clear Hash" before each position is sent. The self-similarity with these settings went very high on one core on all engines I tested previously, not many of them though (Stockfish, Houdini, Critter, and some other). Komodo behaves differently, if I am not doing something wrong, or Komodo doesn't understand "ucinewgame". Here are the self-similarity for given time per move and cores for Komodo and the typical (for strong engines) Stockfish:

Code: Select all

Komodo 9.2:

1 core   20ms : 58.69%    100ms : 61.56%  
2 core   20ms : 60.82%
4 core   20ms : 61.80%



Stockfish 20082015:

1 core   20ms : 99.53%    100ms : 98.83%
2 core   20ms : 67.75%
4 core   20ms : 64.81%

If this result holds, then one can safely test Komodo on 1 core without opening books in these odds matches in order to test. It will somehow speedup the testing if time control is not the most relevant part. But I still don't understand the high randomness of 1 core Komodo, what the heck is it doing, do you have a a randomizer somewhere there in the search or move generator?

This is most likely due to Komodo not clearing the history/move ordering tables it uses when sent a ucinewgame. It is useful to have the engine slightly random a little in testing. If you want to get rid of randomness, just reload the engine between games since it will zero out the move ordering tables on a restart. If thee is a big demand for it playing identical games after a ucinewgame, I could add an option for that.

There's a huge demand among various communities for a 32bit binary (with and without POPCNT) that'll run on Linux, and you haven't done anything about it. That's why we have ceased to sum up any demands, we say to ourselves "If that Lefler won't bother, why should we bother?"

Huh? You seem very upset. I do not remember getting a single request for a 32 linux version from anyone. You can readily reach me via the email on komodochess.com. Although I do not have time to make compiles for every possible combination of OS and memory model, I am quite happy to do another if I can get interest from more than a handful of people. So far you are the only person who has expressed interest.

When you say "That's why we have ceased to sum up any demands" it implies you are speaking for many other people. Are you? who?

[Guenther]

There's a huge demand among various communities for a 32bit binary (with and without POPCNT) that'll run on Linux, and you haven't done anything about it. That's why we have ceased to sum up any demands, we say to ourselves "If that Lefler won't bother, why should we bother?"

Huh? You seem very upset. I do not remember getting a single request for a 32 linux version from anyone. You can readily reach me via the email on komodochess.com. Although I do not have time to make compiles for every possible combination of OS and memory model, I am quite happy to do another if I can get interest from more than a handful of people. So far you are the only person who has expressed interest.

When you say "That's why we have ceased to sum up any demands" it implies you are speaking for many other people. Are you? who?

If not banned for some time, that's his usual style.
Just look up his history... ;-)

[Laskos]

Not wanting to open a new thread and being related to the topic (testing these handicaps), I got something messed up with Komodo 9.2. It seems that Komodo is as random on 1 core as it is on 2 or 4 cores. I used Adam Hair modification of Don's similarity tester, where Adam set the tool to send "ucinewgame" and "Clear Hash" before each position is sent. The self-similarity with these settings went very high on one core on all engines I tested previously, not many of them though (Stockfish, Houdini, Critter, and some other). Komodo behaves differently, if I am not doing something wrong, or Komodo doesn't understand "ucinewgame". Here are the self-similarity for given time per move and cores for Komodo and the typical (for strong engines) Stockfish:

Code: Select all

Komodo 9.2:

1 core   20ms : 58.69%    100ms : 61.56%  
2 core   20ms : 60.82%
4 core   20ms : 61.80%



Stockfish 20082015:

1 core   20ms : 99.53%    100ms : 98.83%
2 core   20ms : 67.75%
4 core   20ms : 64.81%

If this result holds, then one can safely test Komodo on 1 core without opening books in these odds matches in order to test. It will somehow speedup the testing if time control is not the most relevant part. But I still don't understand the high randomness of 1 core Komodo, what the heck is it doing, do you have a a randomizer somewhere there in the search or move generator?

This is most likely due to Komodo not clearing the history/move ordering tables it uses when sent a ucinewgame. It is useful to have the engine slightly random a little in testing. If you want to get rid of randomness, just reload the engine between games since it will zero out the move ordering tables on a restart. If thee is a big demand for it playing identical games after a ucinewgame, I could add an option for that.

Thanks, I was wondering what happens. For my part, this feature is very good for testing non-standard chess like odds matches for which no books are available. I am surprised of the magnitude of randomness not clearing that, it's the main source of randomness even on multicore. Basically, Komodo's games starting from the same position will diverge after few several plies even on one core and even at longer time control (self-similarity will increase very slightly with time control).

[lkaufman]

Looks like we'll also have a short knight odds match the day before (Tuesday) with a British player rated about FIDE 2100. Details when available.