IWB wrote:
Time was very close for Rybka and it might have lost on time...
Of course not, not with a 15 second increment.
I am less confindent in that. If this would be a WC where we are talking about money and prestige I might have tested it with black.
The problem is the coordinating of the cluster. There is a chance that this takes to much time or that it comes back with suboptimal moves ...
The game was won on the board, and would have been won if it had been left to go to checkmate. An engine at that level does NOT lose on time with a mate in 15 announcement or whatever it was, and 15 seconds per move increment. Remember, the cluster has also been a blitz champion.
It is almost as if the game was deliberately adjudicated in order to then be able to cast doubt on Rybka's victory.
Rybka has not done well in this encounter, but in this particular game it's victory was beyond doubt and richly deserved.
There would have to be a pretty horrendous lag to not have enough time to play moves if mate score was already found. With both computers in Germany, the internet lag there is not a factor and 15 seconds per move is more than enough time to overcome the cluster network overhead. If this was no increment then this could be a problem but I think the cluster already has time management code to circumvent that.
Modern Times wrote:The game was won on the board, and would have been won if it had been left to go to checkmate. An engine at that level does NOT lose on time with a mate in 15 announcement or whatever it was, and 15 seconds per move increment. Remember, the cluster has also been a blitz champion.
It is almost as if the game was deliberately adjudicated in order to then be able to cast doubt on Rybka's victory.
Rybka has not done well in this encounter, but in this particular game it's victory was beyond doubt and richly deserved.
I actually expected the win to be adjudicated much earlier. But when the game was played on, I thought OK, they are going to let it go to mate. But then they adjudicated when the game probably had less then 5 minutes left to run, which was a surprise to me.
Modern Times wrote:An engine at that level does NOT lose on time with a mate in 15 announcement
Absolutely agree Ray, with mate score the chance of blundering is zero. There is of course hashtable, the only thing that could happen is that it would play a longer line. In this particular match RC literally destroyed clueless Houdini, in fact what I saw was anti-chess from white.
Obviously a thing you cant make right as an organizer.
If we adjucate 15s before the end it was wrong as it either might be a loss or because we adjucated at all that short before the end to "let it look like ..."
If we woud not have adjucated the game and it would have lost it would be foul play as the cluster had a disadvantage.
In conrtrary to you I am less sure that the shown mate would be correctly executed. And actually I would be a bit interested to see if it would in time but decided that this woud destroy the nice game of Rybka before.
Starting move 88 it shows a mate in
18, 16, 17, 16, 15, 15, Eval:-77.98, 13, 13, 12, 11, 11, 10, 13 - so the Cluster was going up and down ... and the correct mate at move 98 is a #15. When Rybka is Showing a mate in 10 it is a mate in 13. Most moves in between the the first 6pc and the last move were not optimal!
Then the times per move in seconds starting at 88 (the first mate score):
351, 171, 23, 182, 0, 83, 75, 1, 61, 55, 135, 94, 108, 69.
All this with 15s left on the clock at the end (and you can calculate how much was left prior to the last 2 moves for example.
Let your prejudges about why this games was adjucated aside, the technical question if the cluster can handle such a time problem and still win (or just draw or even lose) without the right 6pc tbs is interesting. Unfortunately to answer this question it would have destroyed the very nice strangualting before ...
So we are coming back to: "Whatever we do it is wrong!"
Actually now I wish we haven't seen the problem and just would have let it run until the (bitter) end.
michiguel wrote:
Absolutely correct. That was a Houdini positional blunder (quite ugly, but it was not mentioned). From that point on, it was a slippery slope.
Miguel
IMO Houdini tried there to go for tactics lines but in the end nothing did come out of it.
I guess this has to do with the style of Houdini that privileges dynamicity; I suppose that this behavior pays in the majority of cases (as it is obviously seen in the strength of Houdini) but there are some circumstances where a more quiet and either passive approach would be better.
This is one of those cases, where it would have been much better to consolidate instead of going for risky lines. The problem is: how can you discern when it's better one approach in confront to another with a search/evaluation? I suppose it's very difficult and one will always have to privilege one or the other approach.
IWB wrote:the technical question if the cluster can handle such a time problem and still win (or just draw or even lose) without the right 6pc tbs is interesting.
It has done so before in blitz tournaments. And how is an engine in time trouble with a 15 second per move increment when there are only about 15 moves left ?
IWB wrote:
Actually now I wish we haven't seen the problem and just would have let it run until the (bitter) end.
There was no problem, and yes you should have let it run to the end, it was almost there anyway