Rybka Chess Community Forum
Is there any other OS ???
Rybka seems to be simply better :
Your lines are no good proof :-)! Difference in eval is lower than 0.02 at equal depth. And the shown line is equal for d=19 and d=14 (time: 2:02 vs 0:07).
well, of course we could look what happens if I go to high depth (maybe I'll test it today) but the point is that Rybka doesn't want to play Rd1 at the first plies, so she is "better" in that position, even if she doesn't see a big difference between those two moves. Rd1 is nr. 10 in the move list when using single variation mode... I guess there was an eval. change.
However, it takes still some time when you enter Rd1 till the score is really dropping:
I recall it was -2 straight away, as soon as I had entered the move :-)
congratulations for Rybka Team.
It will be not 'post factum' verification', fortunately ;-) .
Does anyone (ie. Nelson :)) know where 15 ... Bxf3? came from in Diep-HIARCS? It looks like it was played from book but I can't find a reference for it. Possibly private/home cooking? Most books I looked in shouted 15 .. Qc7, in fact the Fritz11.ctg has a nice line for black in this (with green/red moves).
15... Bxf3 was played by Hiarcs, but not out of book. So it was 'over the board inspiration'.
Ah ok! Rybka starts out with Bxf3 but switches to Qc7 at depth 15, thanks Jeroen .. and congratulations to you and the Rybka team for another fine tournament victory, simple awesome.
Thanks Nick! We had a lot of endings this time, as Rybka wanted to say: 'I can win these endings too, you know' :-)
More like: "I'm bad in endings, but for you it's enough" :)
Anyway, compared with other programs Rybka should be also the best in endings I would think.
The incredible thing is, that we had 4(!) tablebase wins: against Sjeng, Diep, The King and Joker. Never experienced this before :-)
Would Rybka have won these without tablebases?
I have no idea :-). No possibility to find that out, as there is no chance of simulating these positions under the tournament conditions we had.
I also have no idea :-). But big praise for Lukas and his fast 128 GB 6-men tbs (I can remember a time, where there was a big accusal against him and the installed tbs :-)). And for the future: You can be sure, that you will see endgames battles more often in your tournaments. Opening battles were yesterday! (It´s obvious, sinca a Italian guy makes best book within a week :-))
OK, but Vas will still swear that TBs are only good for AT MOST 2 Elo! :-)
And endgame skills are good for at most 10 Elos :-). I know that all and therefore I praised Lukas :-).
I´m not a great fan of tbs (only for decent analysis). But: Better than nothing!
If "swear" is defined as "demonstrate with data", then yeah :)
You know ... I always read that EGTB's only add a very few ELO's and some people also say that it actually weakens the main engine ... but I really doubt it. I can think of several games in previous matches where if Rybka had 6 piece EGTB's games could have been won. So it most definetely helps and much more than people are told to believe. I do think that having the main EGTB's on SSD's does a lot in reducing the performance hit of having EGTB's ... but really not to have the full EGTB's would be crazy.
It seems pretty obvious to me too, especially given the not infrequent reliance on TBs in tournaments. For some reason, Vas must feel that it either slows down or detracts from the search enough to cancel out the obvious benefits.
The slowdown from TB's is even less significant than the gains :)
Seriously, I'm not against TB's at all. They obviously help. Who cares about some tiny % slowdown? It's just that in the big scheme of things they don't help that much - the critical moments are typically earlier.
Yeah, I was mentioning on the Hiarcs Forum that I thought black's position looked pretty bad right out of the opening, and was certainly lost by move 25 and possibly before. It looks to me like white is at least +/- right out of book, though the reasons for this are beyond the horizon of any engine.
IMO Hiarcs was playing on the wrong side of the board. With pawns on a5 and b4 you should try to move them forward. Apparently Hiarcs thought the weakening of the white king position was enough to start an attack on the other wing. Vincent had the feeling that black's play was OK, but in my opinion black should never give up his great bishop on b7. In the course of the game the black attack never was threatening and the white centre started to move, winning the game.
According to my database...
The move was first played in Kallisto 1.83-Junior 4, 1997, 1-0. (Kallisto was sporting a 486 processor running at 66 MHz; Junior had a Pentium running at 100 MHz.)
First played by humans in Kelly (2423)-Cobb (2275), 1999, 1-0.
First correspondence game by Kristensen-Lylloff, 2001, 0-1.
First played by Nick Carlin in DONETSK-Flyingfatman, 2007, 1/2-1/2. A bit late to the party, Nick!
Thanks Nelson ..
> First played by Nick Carlin in DONETSK-Flyingfatman, 2007, 1/2-1/2.
Doh! I told you I don't put drawn games into my books :) Too funny.
1) The position is not drawn
2) If black stays with his king at g7 then white should not push the pawn at a7 (which Rybka does not understand)
R7/6k1/P7/8/8/8/6K1/r7 w - -
this position is drawn but only on with the King on certain squares. They key is that black wants to put the Rook to f6
Either way the evaluations of Rybka are not correct
It is true that a7 is not the best try, to put it mildly. But it has been shown long time ago, that these positions are generally drawn anyway, even with 3 against 3 on the kingside. It typically goes roughly like this: Black keeps the white king on the first rank as long as possible. At the same time, he pushes his kingside pawns. White eventually will have to sacrifice at least one kingside pawn to activate his king - notice that because of the position of the white pawn on a6, the rook can afford to temporarily leave the a file. At some point, when the white king has managed to support his a pawn, black will have to sacrifice his rook for the pawn. But in the meantime, black has made sufficient progress on the kingside to force a draw with his pawn(s) and king against white's rook, because white's king is too far away.
I am far from being an endgame expert, so I might well miss some subtlety here - although the position looks pretty much standard to me. But I guess you'd have to say a 'bit' more to back up your thesis 1).
By the way, for a real rook endgame expert, Vas could contact Krasenkow - he is really impressive.
This defense mechanism breaks if white has a pawn on g5. For example, the following position is winning:
R7/6k1/P5p1/6Pp/7P/8/r7/5K2 b - - 0 0
White just plays Kg1-f1-e1-d1, and if 1. Kf1 Ra4 2. Ke2 Rxh4, white wins with 3. Ra7+ Kg8 4. Rb7 Ra4 5. a7.
The following position is still winning.
R7/6k1/P5p1/6P1/8/8/r7/6K1 w - - 0 1
ie. 1. Kf1 Ra5 2. Ra7+! Kg8 3. Ke2 Rxg5 4. Rb7 etc.
Black can prevent a white pawn from reaching g5, but then he must weaken his kingside and other white ideas become possible.
For what it's worth, Rybka would have badly misplayed this endgame had black defended better. I won't even terrify you with the details :)
Hi Vas, this reminds me of http://www.rybkachess.com/docs/freestylers_version_2.htm
from a year or so ago:
Nick Carlin: 60-40 is my guess, I suspect that the centaur advantage will come especially in the end game, where human assistance can avoid losses and win games that engines might draw. An example is in some rook endings where the engine will push a pawn to the seventh rank and obtain a draw in a won position. The missed win is coming through leaving the pawn on the sixth rank and bringing the King up to support its coronation.
Good luck for the victory in Leiden!
Yes, this particular issue seems to come up quite a bit. Humans are relatively stronger in endgames in general. I'll sometimes analyze an endgame without any engine assistance at all. In a middlegame, this would be absurd.
I totally agree ... although I don't think engines cannot be made much stronger than humans in endgames. It is just that so far engine development has concentrated on other things. Eventually endgame modules will be a must for a successful engine ... even the best human follows a certain quite simple logic when analyzing endgames. I personally think that strong hardware will eventually show that engines can really perform miracles in endgames. It is just that endgame code today is too much of a burden on normal chess engines and will make it play overall much weaker. As more and more cores are added to CPU's ... the possibility of sacrificing a few cores to independently analyze a position will become possible ... thus the value of endgame modules. Also inclusion of bitbases is something that would also help ... as of now bitbases can very efficiently handle up to 6 pieces and maybe even 7 pieces .... only problem is that they don't have the correct line all the way to the win draw or loss. If the information of bitbases can be incorporated into an endgame module where it would take that information to be more selective in the lines it would search and using on the fly checking of the bitbases then you have a very very powerful combination that will far outpace any human abilities. If 5 game EGTB's can be compressed to around 150 mb ... then maybe 6 pieces would be 22 GB ... and so seven and maybe even 8 pieces become a possibility. Whatever it is ... the handling of endgames by chess engines has a lot that can be improved upon ... it is just a matter of someone placing some effort into it. This will probably happen when improvements in evaluation and search hit a wall and thus the hunt for ELO's will have to be found elsewhere ... as of now it seems that there are still quite a few ELO's to be gained from simply improving search and evaluation and MP efficiency.
"It is just that endgame code today is too much of a burden on normal chess engines and will make it play overall much weaker."
Perhaps my knowledge of programming is too basic, but couldn't you just make endgame code that only activates after the queens come off, for instance? For example, have a material count variable which activates the endgame evaluation function and deactivates the middlegame evaluation (when enough material comes off to warrent it). This way you could even have different evaluation functions depending on the type of ending.
I think that when the time comes, it would possibly be best for engines not to use tablebases of any sort, or perhaps have the code modified so that "draw hits" are not taken into account--engines should play so that they go into positions that maximize the probability that the opponent will make a mistake, something that we can do as humans fairly well, but which computers accessing tablebases would not be able to do at all.
An insightful set of observations; I think you're right. I'll tell you what is daunting, though. Today's chess engines all stand on the shoulders of past engines, which year upon year and decade upon decade emerged with new ideas for both search and evaluation. Rybka is at the cutting edge of these developments, but there can be no question that everyone on the team owes much to those who worked on the chess problem before. Conversely something that could play endgames with fantastic skill would require a cluster of breakthrough ideas with very little prospect of financial gain unless it were bolted on to an existing engine. If you look at it from Vas's perspective, you're almost asking him to abandon his work to date and start nearly from scratch in a whole new field. Endgames are a favorite area of academicians more than your standard chess engine programmer. It gets really theoretical really quickly.
I'm not so sure that it will be possible to overcome the GM advantage in endgame play in the near future. Certainly any advance in TBs will be useful (nobody can argue with perfection). Aside from this, the endgame allows GMs to take maximum advantage of their pattern recognition skills. Each of the patterns that a GM recognizes instantly may translate into a fair amount of code, and there are many, many patterns. I suspect this will not be addressed until more progress is made in non alpha-beta based search techniques that are more suited to pattern recognition. This is still an area where there is a lot of theory to sort through, and chess is not leading the way.
If you want to do research, you need a research grant and the freedom to fail and maybe write about that failure as a learning experience. If you want to release products, you absolutely need an incremental path, and I don't see what that would be right now for directly addressing these endgame play issues.
In addition to this, endgame play is simply less important in chess than middlegame play. Endgame play is comparable to special teams in football - or penalty kicks in soccer, for the less enlightened :)
Of course, we will have gradual improvements in endgame play via better heuristics and deeper search, but I don't see any revolution just around the corner.
In addition to this, endgame play is simply less important in chess than middlegame play. Endgame play is comparable to special teams in football - or penalty kicks in soccer, for the less enlightened :-)
Hmmm, this is a strange comment to be coming from you. The Redskins under George Allen elevated special teams play to an art, but this was before your time.
If you want to do research, you need a research grant and the freedom to fail and maybe write about that failure as a learning experience.
Research grants have always amazed me. My experience is that the grants are generally fairly small (my sister earned tenure at Cornell by bringing in a $1M grant), there is generally a lot of overhead, and dealing with university rules and IP rights can be daunting. As you point out, one of the reasons that it is possible to do any research, is that failure is always an option as long as you follow up by writing a nice paper.
Pattern recognition is a useful technique in a lot of areas with a lot of development money, so I suspect that the tools necessary for chess will be available by the time you are ready to address this less important aspect of the game. I'm betting that better heuristics used with alpha-beta search will continue to have problems in positions with more than a handful of pieces where a GM can quickly identify the winning or drawing plan.
If you want to release products, you absolutely need an incremental path, and I don't see what that would be right now for directly addressing these endgame play issues.
Well, I'm nothing if not a capitalist. There is not a single Che Guevara tee shirt in my closet! (and a Milton Friedman tee shirt wouldn't have quite the same effect) :-) Anyway, this doesn't concern me too much, because as you well know, Americans don't play endgames.
>Research grants ... there is generally a lot of overhead
Usually the university negotiates this with the funding agency. Numbers around 40% are typical with the NSF (US National Science Foundation).
40% to whom?(sorry to interfere): to university, or to people working in the project?
The 40% that BB refers to is a tax on the grant. Where it goes, nobody knows, but it certainly doesn't go for work on the project.
I was in doubt, because here the percent is the reverse :(
Thank for claryfying, Alan
I have seen 50%, which strikes me as highway robbery, but never higher. It is very difficult to run a business with this kind of overhead cost and I am surprised universities can win grants this way.
Even more, they are the researchers that look around for contracts...
>The 40% that BB refers to is a tax on the grant.
If I were at a US (or possibly Canadian) university, and got a "$1M maths grant" from the NSF [well, the university formally gets the grant from some standpoints], my university has already pre-negotiated some percentage that will go to the university, the college of science, the math department, etc. So the government could really be giving (say) $1.5 million to the university, who would confiscate a cool half million for its own use. My own knowledge here was largely instigated from Dan Bernstein's What it's like to work at UIC
There is also the 5% of the NSF budget that goes to administrative costs involved in running the NSF, but that's a minor matter.
That's interesting, but it doesn't always work that way. My sister got a $1M grant (I think it was from NIH) and it was portable. This had a lot to do with her getting tenure at Cornell. Next time I talk with her I'll find out how much Cornell grabbed. The 33% in your example sounds on the high end of reasonable, whereas 40% sounds like the low end of outrageous, but maybe this is the way things work in university land.
>This had a lot to do with her getting tenure at Cornell.
This is a general rule at many places. When I was at a Big Ten school, having a suitable grant was seen in practise to be equivalent to getting tenure in the maths department.
>Next time I talk with her I'll find out how much Cornell grabbed.
In some places, the "indirect cost rate" on institutional grants is actually considered to be proprietary information. My impression is that 25% is the minimum, and numbers in the forties have been known to occur. From Bernstein
:Extra payments to the university for no reason at all
NSF's grant CCR-9983950 to UIC has a 55.3% overhead rate [this would be 35.6% in your accounting], as specified by a university agreement with the government. In April 2004, after a huge amount of effort, I finally managed to get my hands on some account statements. I added up the direct payments, subtracted tuition remission (which isn't charged overhead), subtracted the amounts labelled by the university as capital equipment (never mind the amounts incorrectly labelled non-capital), and multiplied by 55.3%. The resulting number was hundreds of dollars smaller than the actual overhead payments taken by the university.
You would think they would have an excel spreadsheet where you pop your grant value in with a few additional variables and it spits out how much you get to keep. Why the cloak and dagger?
>Why the cloak and dagger?
Universities have been known to keep (at least) two sets of books... :-P [as Bernstein attempts to document]
I was thinking more 80s Redskins (you know, the 3-time Superbowl champions), with Ali-Haji Sheikh among others. The extra point (and there were many of them) was no longer time for a toilet break.
> Pattern recognition is a useful technique in a lot of areas with a lot of development money, so I suspect that the tools necessary for chess will be available by the time you are ready to address this less important aspect of the game.
I'm sure that a lot of interesting stuff already exists, but it's always going to be a big step to apply any of it to chess.
> I'm betting that better heuristics used with alpha-beta search will continue to have problems in positions with more than a handful of pieces where a GM can quickly identify the winning or drawing plan.
Probably so, but we'll see. I remember some ancient writings from 30 years ago from people who were sure that alpha-beta could never play master-level chess. Monte-Carlo might also help here.
>I remember some ancient writings from 30 years ago from people who were sure that alpha-beta could never play master-level chess.
Yes, Botvinnik had some influence in this regard, if I recall.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill