So I consider the Problem/Issue essentially resolved: The author has considered this input, and he indicates he's taking his own fresh approach in Rybka 3.0.
I like that! I feel that my concern has been heard and I'm happy with the overall process of discussion here and there.
Thanks everyone!
Rick
Rybka is made out of People! (serious problem exposed)
Moderator: Ras
-
Ross Boyd
- Posts: 114
- Joined: Wed Mar 08, 2006 9:52 pm
- Location: Wollongong, Australia
Re: Rybka is made out of People! (serious problem exposed)
Well, after reading the (mostly) negative reactions to Rick's original post I'm glad to see that Vas has responded in the Rybka forum and has agreed to revisit the way Rybka 3 counts nodes.
IMHO Rick was a little 'over the top' in some ways - and yes it is old news to most.... however, nobody had documented the _exact_ mechanism that Rybka was using for node counts. But, I guess, knowing these details for 2 years and 'sitting on your hands' must have led to a certain uncorking when he decided to 'reveal all'. It was definitely interesting reading from a chess programmer's POV. Thanks Rick for posting your findings.
On another 'deciphering Rybka' topic, when Rybka first came out I had the subjective opinion that she employed a multi-level search with special extensions for passed pawn conditions. Through observing her games I felt Rybka's passed pawn eval was more sophisticated than most, and seemed to strongly encourage the coordination of supporting pieces to build a well-protected path to promotion.
When Strelka's code was released I had the opportunity to see how this was accomplished. I'm amazed at how fiendishly simple and elegant Rybka's approach was.... just a simple attacker/defender count of the passed pawn's remaining steps to promotion.
All this bears out something Vas said a few years ago that he was mostly interested in in discovering which eval terms are actually important to a chess engine's strength. There are many terms that are either counter productive or just too costly and this too was confirmed by Fruit's success with a simple eval.
Oh, one other story.... in my engine TRACE... for years I had wanted to evaluate piece constellations or material imbalances as it is called in order to avoid bad simplifications and for pruning. I could never work out a good way to implement it... until one night lying in bed I had a 'Eureka' moment and came up with a simple and obvious array indexed by all the piece counts. Voila! It was a little cache unfriendly but with the right weightings had great potential. I was very excited and coded this into TRACE 2.
Unbelievably, Strelka code was released maybe 6 or more months later and what do I see? The EXACT SAME material imbalance lookup..... the main difference was that Strelka/Rybka had the actual evaluation weightings and it all worked.
I guess that's because Vas is a genius and I'm, well, I'm just an Australian.
Ross
IMHO Rick was a little 'over the top' in some ways - and yes it is old news to most.... however, nobody had documented the _exact_ mechanism that Rybka was using for node counts. But, I guess, knowing these details for 2 years and 'sitting on your hands' must have led to a certain uncorking when he decided to 'reveal all'. It was definitely interesting reading from a chess programmer's POV. Thanks Rick for posting your findings.
On another 'deciphering Rybka' topic, when Rybka first came out I had the subjective opinion that she employed a multi-level search with special extensions for passed pawn conditions. Through observing her games I felt Rybka's passed pawn eval was more sophisticated than most, and seemed to strongly encourage the coordination of supporting pieces to build a well-protected path to promotion.
When Strelka's code was released I had the opportunity to see how this was accomplished. I'm amazed at how fiendishly simple and elegant Rybka's approach was.... just a simple attacker/defender count of the passed pawn's remaining steps to promotion.
All this bears out something Vas said a few years ago that he was mostly interested in in discovering which eval terms are actually important to a chess engine's strength. There are many terms that are either counter productive or just too costly and this too was confirmed by Fruit's success with a simple eval.
Oh, one other story.... in my engine TRACE... for years I had wanted to evaluate piece constellations or material imbalances as it is called in order to avoid bad simplifications and for pruning. I could never work out a good way to implement it... until one night lying in bed I had a 'Eureka' moment and came up with a simple and obvious array indexed by all the piece counts. Voila! It was a little cache unfriendly but with the right weightings had great potential. I was very excited and coded this into TRACE 2.
Unbelievably, Strelka code was released maybe 6 or more months later and what do I see? The EXACT SAME material imbalance lookup..... the main difference was that Strelka/Rybka had the actual evaluation weightings and it all worked.
I guess that's because Vas is a genius and I'm, well, I'm just an Australian.
Ross