1) He is more knowledgeable than anyone else when it comes to what the keys are to making the highest Elo chess engine, and
2) He is a very hard worker.
His primary weakness is that he is not the type of person who produces a polished product. Instead he turns out products that are 98% done. This isn't uncommon, but it leaves him open to having people hack his programs, include the last 2%, and re-release them as improved products. This was the fate of R3, and as things stand now, I am 100% sure this will also be the fate of R4.
After this occurs, instead of fixing the problems, Team Rybka will concentrate on the symptoms of the problem, and will make a completely futile attempt to keep people from hearing about the polished alternatives by not allowing their names to be mentioned, and by convincing the major test groups not to test them.
As far as endgames go, Vas hasn't spent a large percentage of his time working on endgames because there isn't a large enough associated Elo gain to justify the time. People who don't agree with this tend to be more interested in analysis than engine-engine play. Higher Elo engines are generally better sellers, so there is a business case for this as well.
> 1) He is more knowledgeable than anyone else when it comes to what the keys are to making the highest Elo chess engine, and
> 2) He is a very hard worker.
Not so sure I agree with #2. If he was, he'd have patched both R3 and R4. I think all he did for R4 was reprogram R3 cluster.
As far as the child, I'm sure he is capable of taking care of both!
> Instead he turns out products that are 98% done.
Probably because in the development phase he jumps from Alpha to release, or well, only having 6 hours of beta testing... (that's more or less what the final compile got)
The sad thing is, that even if we had a more decent beta testing stage (say, a version is only released if it has no issues for two weeks), the MultiPV, show stopping bug would have been in anyway, as it was discarded as "normal" behavior early on. It seems getting a small pool of REAL users into a beta testing stage (that should last more than 6 hours...) would have been necessary.
By the way, the delays I see in single PV mode when I'm analyzing backward and forward only occur when I'm using large pages. I find this very strange because I use large pages with all of my chess engines (except R3) and never had any issues.
I'm astonished that only 6 hours of beta testing is sufficient.
As said Larry in previous posts, using all the computing power of the huge hardware of the cluster, can make the tester play thousands and thousands of games in a limited time, which in deed will ensure ELO increase. But concerning quality of play, playing style, some bugs related to misevaluation of certain positions etc. need an eye check of the games.
My technique concerning developing settings for engines, relies at first on some changes in piece or evaluation parameters that is based on analysis of positions from games played by the default or developed setting. Then i analyse again the games to see if my changes are good or not (concerning what i look for: positional play, tactical play ..) Naturally if the setting looses much rating it's clear that my changes are not good. May be not all the changes (just a small part that needs to be fixed) And so on. So i rely on the fact that independent checking of the games (especially those games that are lost, then short draws, then very long draws ...) and on the board analysis under different circomstances: infinite pondering, incremental time control etc. is necessary to release a good product, with less hidden bugs, but also this evaluation could help the programmer to focus on such or such direction according to suggestions of the beta testers involved in this process. The role of such guys are in my opinion at least as important as the hardware guy, and the book master......
After all, the Rybka SW development is practically a one man show. It is not exactly that some business analyst analyses the market and gives input to a system analyst who produces detailed specifications to Vas about what to implement Or that some project leader is making sure that he does what he should with the right prioritizations... .
I also think that he sometimes has shown some of the bad sides of the "agile programmer" attitudes which is very popular nowadays; just do what you like and don't care to much about quality or the customers, that will just automatically be fine. The (often unrealistic) idea that you don't need to do systematic testing or that you can deliver in very short time is also typical. Or that theoretical modelling is useless and any kind of prediction/planning is not possible.
But lets give him a chance, I think "cloud Rybka" is a very interesting concept, even if a problem may be that people aren't as "rational" as you would expect. And I think one of his advantages vs. the competitors has been that he understands the non-pure programming aspects of SW development much better.
I think that it'll be a draw, because white cannot move his passed pawns and promote.
What do you think about?
Rybka evaluates it as winning for White. But it's hard to find the win!?
I think black got good chances to draw this ending.
I guess I'll keep an eye opened and post cases I find on this thread.
I don't understand with all the knowledge of nowadays engines and all the powerful computers we have, how does the top engines are sometimes unable to play endgames efficiently. This is for me an important issue, because it geopardize the use of these engines as analysis tools etc.
Hopefully, i can also rely on my chess skills (i'm almost 2200 rated) with a good endgame knowledge. May be 5 or 6 pieces endgame tables are helpful (for sure), i will feel more confortable with the engines that doesn't use these tablebases because they are implemented with sufficient knowledge to solve these endgames alone.
> I don't understand with all the knowledge of nowadays engines
For Rybka, the knowledge was removed to speed up the engine.
I still believe that such knowledge should be set on or off in the setting (it's worth to see the difference in performance between the two engines in Blitz time control games), but also even if it is set in Off during the game, there is still a possibility that the engine uses this additional knowledge in endgame. May be, if we have a quad, Vas could think about a child process were Rybka uses 3 processors with the engine without this additional knowledge sothat the overall speed of the engine is preserved, and use a thread with the additional knowledge (let say starting from 16 pieces on the board) to see if there is a significant difference in the evaluation of the position. In such a case, i will certainly rely on this additional knowledge for a more accurate analysis. But this complicated issue must be beta tested energetically.
I don't know how Vas works, if he tends to give his team a new beta engine each hour, this plan seems difficult. But in an hour i don't see a dramatic change in the engine (a part from fixing bugs) and this team must be focused on testing for 1-2 weeks thourougly this feature.
A revolution in chess endgame studying !!
This feature could be only a feature of Cloud Rybka !!!
I think it is just a matter of some refactoring and domain analysis, which Vas' does not prioritize while it doesn't add significantly to the ELO.
> I find it hard to believe that adding endgame knowledge in the right way would cost any significant performance.
Significant enough for Vas to remove it, otherwise he wouldn't have bothered as removing the knowledge is more work that just leaving it there.
But a problem is that it is typically non-trivial to prove it.
Actually I thought that as R+4 vs R+3 can give reasonable practical chances that with the doubled pawns white might have a theoretical win. But as someone else pointed out (possibly in a different thread) the doubled pawns can be helpdful for holding 4 vs 3. As I started to analyse I began to realise how hard it was for white to make progress.
Anyway, Kramnik is probably the best in the world at these types of positions, so I think we can say he made the right choice. It would be interesting to know Kramnik's view on whether it is a win with best play without Nxf6 and whether the rook ending gave any real chances at all.
But I think this is the most clear cut case in this thread for R4 going wrong in the endgame. I am sure that mis-evlauation will quite often (but not always) lead to mis-play, its just that we have not seen that demonstrated very often.
big plus for white - but easy draw.
White plans: Exchange one of the g or f pawns with Black then let Black push his pawn till a2. His king will have no serious place to hide from perpetual check and if he hides, he will be far away from defending the a2 pawn. The Black rook is busy defending this pawn. It'll be a hard fought draw i think. Clearly, white got a stable plus in this position, but playing good chess could give white the possibility to manage for a draw.
Try to let the top engines analyse. They all will give at least +0,7 or more in Black's favour.
A few days away from computer.
I need help on how to evaluate this position, using various engines, but also naturally usin Rybka
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill