Perhaps Rybka 4 IS proving itself.

[M ANSARI]

Well can someone give their theory why R4 performs better at LTC and ponder ON than it should? Or why it performs better at FRC than it should?

[Uri Blass]

Well can someone give their theory why R4 performs better at LTC and ponder ON than it should? Or why it performs better at FRC than it should?

I think that it performs better in FRC thanks to knowledge about the early opening and I saw no proof that it performs better at LTC (the rating difference between Rybka4 and Rybka3 at 40/40 and 40/4 is almost the same in CCRL or CEGT lists).

[Milos]

Well can someone give their theory why R4 performs better at LTC and ponder ON than it should? Or why it performs better at FRC than it should?

Regarding FRC, difference between R4 i SF1.8 in normal chess is 64 elo (20 elo are error margins).
In FRC difference is only 46 elo (error margins are more than 20 elo).
So R4 is weaker in FRC than in normal chess compared to SF (even though not conclusively). So what the hell are you talking about???

Regarding R4 that performs better at LTC and ponder on, this is simply not factual (it's actually fictional).

[Uri Blass]

Well can someone give their theory why R4 performs better at LTC and ponder ON than it should? Or why it performs better at FRC than it should?

Regarding FRC, difference between R4 i SF1.8 in normal chess is 64 elo (20 elo are error margins).
In FRC difference is only 46 elo (error margins are more than 20 elo).
So R4 is weaker in FRC than in normal chess compared to SF (even though not conclusively). So what the hell are you talking about???

Regarding R4 that performs better at LTC and ponder on, this is simply not factual (it's actually fictional).

For the question what the hell are you talking about:

I compared Rybka4 with Rybka3 and not with stockfish.
I believe that the difference between Rybka4 and Rybka3 is bigger in FRC because of better opening knowledge of Rybka4(relative to rybka3).

[M ANSARI]

When we were initially testing R4 to try to set the optimal time control parameters we got some very strange results. Let us say in a 3_0 match we were trying to improve scores against engine X. What we had to do was force R4 to play very quickly, actually so quickly that it would end up with CPU utilization way below what it should be. So R4, when forced to play fast would end up using only about 50% of possible time, but would still perform much better than the default R4 which was using close to 100% of available CPU time. Obviously the ideal situation would have been for R4 to play fast and then to use the time gained in part of the game where it could use it. This can only mean that at this particular time control, R4 time management was not good, or at least can be dramatically improved on. I think a TC module is a very good idea and I see Stockfish is doing that and hopefully that will bring this subject more interest.There are bound to be certain conditions in chess that can be identified to let the engine better know when there is a critical move, and how to allocate CPU time effectively.

However the default setup seemed to do well at FRC, I would guess that was due to the fact that without a book, the engine is on its own right off the bat and thus using a lot of the allocated time used in the opening pays good dividends. It is possible that the default setup TC parameters of the FRC version can be improved upon, honestly I don't know if anyone tested that.

[De Vos W]

Rybka 4 is probably the most underrated engine out. During beta testing it was obvious that this engine could play one hell of a mean chess game. But it was hampered with an incredibly terrible time control mechanism. We tried very hard to sort that out in the limited time, but I think it was a band aid on a very large wound. Rybka 4 probably has one of the worst time management algo's out there, and if that would be improved it would dramatically improve in the ELO rating scheme. At long time controls, the weakness of time management is somewhat covered over (although not eliminated) and I saw that during beta testing. Hopefully this issue and a few other issues will be included in the bug fix everyone has been waiting for. My guess for the poor time management is that it is pulled off directly from the cluster version. That was designed to incorporate latencies to allow for remote play and Slave-Master LAN communication, where time is really not so critical. Move that system to a normal PC setup at fast time controls and those latencies will just kill you.

Just one question Sir, do you know how to dissasemble?