And if the computer lost on time, fine.
But clearly, particularly for closely matched engines, the operator has a significant input.
Jonny is still playing at 160 moves. I think whoever dies first loses. LOL
Exactly. It's the drawn ending plus the other human using a cheapo to get a point which makes it unjust.
noobpwnftw wrote: ↑Mon Jul 16, 2018 4:54 pmThe thing is that the rules were clearly stated and not biased against any participants. In fact the very reason for the high expectations for Leela is it gives more freedom on the hardware.JJJ wrote: ↑Mon Jul 16, 2018 3:39 pmI m very surprised the Komodo team refused a draw. To me it is very unfair. Leela is not the favorite here, and even if it was, it would have been unfair.
Now if Komodo win, who's gonna be happy for the team ? Few people and most won't. Game is a draw. First time Leela play, and they refuse draw because the human ( not the program after all , he can insta move ) is low on time. Not fair ! Even if it is not against the rule.
It is interesting that engines don't fight over a cable but teams meet in person and play on a real chessboard, which is part of the spirit.
There can be human errors like misplacing a piece or even unable to participate due to various reasons, which is also a part of the drama.
If people can't accept the fact that shit happened and not in their favor, then it's no better than withdrawing into a moral victory.
EDIT: Wrong quote, sorry. See below.
We can always keep our own scoresheet. The only thing to consider is that maybe playoffs, if they will be needed, will be played by different engines than our scoresheets show. Two remarks as of now: many draws in general and Leela draws too against strong engines on strong multi-CPUs. I guess Komodo was running on 48-core machine, as in previous editions, right? It seems the opponents haven't considered anti-Leela books. Even I could have prepared one in 2-3 days, as Leela is abysmal on tactical puzzles.Guenther wrote: ↑Mon Jul 16, 2018 11:59 amThanks for confirming what I guessed in my post, which I was writing at the same time, George.George Tsavdaris wrote: ↑Mon Jul 16, 2018 11:53 am
It was this position, a dead draw one:
8/8/8/KR6/p3k3/P7/2b5/8 w - - 0 1
Leela's operator was having problems with time and he was running out of time, so he offered a draw 2 moves before the end i think, but Komodo's operator didn't accept(!! really very bad Chess sportsmanship) and he couldn't keep up with executing the moves so he run out of time so 0-1.
So this loss for Leela was because her operator wasn't good enough by playing the moves on a "dead draw" position. This is not Chess of course. They should have accepted the draw in this kind of dead position but it's ok since it's inside the rules of course.
Even if it is covered by the rules you won't make friends, if you refuse a draw after >130 moves and being on
the weaker side of a dead drawn 6men endgame! Very bad sportsmanship...
In your views, if the quite opposite happened, are "most people" willing to give up the win instead? I don't think so, because if they have every right to keep the win, why would they think it is "stolen"?
From ICGA:Laskos wrote: ↑Mon Jul 16, 2018 5:16 pmTwo remarks as of now: many draws in general and Leela draws too against strong engines on strong multi-CPUs. I guess Komodo was running on 48-core machine, as in previous editions, right? It seems the opponents haven't considered anti-Leela books. Even I could have prepared one in 2-3 days, as Leela is abysmal on tactical puzzles.
It seems that Leela's operator tried to get by with just five seconds operator time (by setting the increment to just five seconds less than the stated one), which was clearly too small given all the circumstances. If he had set it to a more reasonable ten seconds operator time, it would have been a different game. Personally I would prefer not to have operator time count, but I don't make the rules. Erdo, our operator, feels obliged to do his best for Komodo within the rules, just as others have done in the past. In fact in this very tournament, in the Blitz, Komodo disconnected and lost a couple minutes of clock time resetting. No one offered to restore the time, and Komodo was left with just one minute, but still we got a draw in the end.Albert Silver wrote: ↑Mon Jul 16, 2018 1:56 pmMore than a little perplexing. Leela and operator lost on time through their own setup. There was no power outage, no dizzy spell by the operator, in other words, no mitigating circumstances other than failing to be prepared. The clock is a part of the game. Take ownership of mistakes made, and don't blame the opponent for benefiting from them.
You had bishop and wrong colour rook pawn.mjlef wrote: ↑Mon Jul 16, 2018 6:09 pmI posted a reply earlier but it seems gone now. So I will try to repeat it. Some more info below.Albert Silver wrote: ↑Mon Jul 16, 2018 1:56 pmMore than a little perplexing. Leela and operator lost on time through their own setup. There was no power outage, no dizzy spell by the operator, in other words, no mitigating circumstances other than failing to be prepared. The clock is a part of the game. Take ownership of mistakes made, and don't blame the opponent for benefiting from them.
The lc0 operator was using some simplified GUI they wrote. Well, it was not graphical but it has things like "wp" for a white pawn (very much what I did when I started chess programming). I told him the writer of the UCI spec was in the tournament and they should write a UCI version and try out some of the many good chess GUIs (this was during the game).
There was no opening book for lc0, so it started thinking on the first move.
I spoke with him after the game and suggested he reduce his increment. Someone else had already suggested this. He had set his increment to, I believe, 10 seconds per move for the first game. For the second game he had already set it to 5 seconds, because 10 seconds (with the actual 15 sec increment in the time control) only allows 5 seconds per move. I also believe moves were entered as e2e4<Return> in the unique GUI, which takes more time than a single or double click in a standard GUI. These things all took up more time. Note he did not seem upset by the time loss.
You might ask why we played on once Komodo reached the 6 piece Syzygy draw. Our experience with MTCS nn engines is they do not play the endgame as well as traditional programs. We also discussed Syzygy with the lc0 operator and he said they had not implement them yet. If they had them, we would have proposed a draw ourselves long before since why play on when we know the result? When you know little about a new opponent, the safest thing to do is play on. If it was say Shredder, then game would have ended a lot sooner.
About two moves before the end of the game game I reminded the lc0 operator that he could alwys request a draw. I was not looking at the clock when I said this. He proposed it, and I went over to our operator to start discussing if we should accept. The clock fell and it lost on time.
Earlier in the game I saw lco was taking a lot less time than Komodo, so I did not keep track of its time. And I did not know he had such a large increment which only allowed 5 seconds (on average) to enter a move. I am also not sure if he tried adjusting the time. Operating a chess engine in a tournament srequire a lot of scanning of everything to make sure all is good.
I spoke with Larry later in the day and he agreed with what we had done. I think nearly all chess programmers learn a lot from the first tournament. I sure did. Preparation and practice is important. I will try to follow the time better and suggest people adjust time if it is getting off.