Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Anthony Cozzie speak !
1 2 3 4 5 6 Previous Next  
Parent - - By Banned for Life (Gold) Date 2008-02-05 13:53 Edited 2008-02-05 14:10

I have collected hundreds of games in the CB engine room between fast quads playing Zappa Mexico (not II) and Rybka 2.3.2a at 16-0. Your statement that you don't get a big divergence (I use > 50 cp near 0) between evaluations in most games is correct, but these games are not by any means rare. I'm guessing they happen about 25% of the time.

Of course when these cases do happen, you have to make sure it was really the eval and not one engine out-searching the other.

One very early game example that comes to mind is the Benko gambit, which Rybka seems to understand very well while Zappa just thinks its down a pawn.

Parent - - By Uri Blass (*****) Date 2008-02-05 14:07
I do not claim that these games are rare but only that you cannot know which evaluation is better based on minority of the games.
Better evaluation is not only clear cases when one evaluate wrong and one evaluate right but other situations when the difference between evaluations of programs is less than 0.1 pawns.

Even if one program is better in majority of the cases when there is a big disagreement it does not mean that it has better evaluation because the second program may be better in evaluating situations when there is a small disagreement.

If program A and B has the same tree but A evaluates move X as 0.01 pawns better than Y and B evaluates move Y as 0.01 pawns better than move X then the choice of X or Y can give different results.

Parent - By Banned for Life (Gold) Date 2008-02-05 14:21
Yes, the important thing is how the evaluation affects the selected move, rather than the evaluation itself. Unfortunately this is much less visible than large differences in evaluation. Fortunately, the two are reasonably well correlated, i.e. if the evaluation is way off, the probability of picking near optimal moves is also degraded.

I agree with your assessment that small differences in evaluation may be just as important, or even more so, but I can't see any way to pick these out so I didn't focus on them.

Parent - - By BB (****) Date 2008-02-05 15:09 Edited 2008-02-05 16:08

> If we talk about evaluation then my opinion is that in the majority of the game you cannot know if rybka has better evaluation or Zappa has better evaluation.

There are (at least in theory) theoretical techniques for determining (or at least bounding) the quality of an evaluation function. For instance, in backgammon, the evaluation of a position "should" be the weighted average of the evaluations of its 21 direct descendants, which are in turn the evaluations of its descendants, etc. One measure of an evaluator is thus its level of self-consistency. A chess analogy could be the extent to which a score/PV remains stable when depth is increased. A chess-based paper not unrelated to this scheme could be Tuning evaluation functions by maximizing concordance of Gomboc, Buro, and Marsland, though it takes a different tack: it compares evaluations with Informator guesstimates, whereas I might propose an evaluation/search-with-eval comparison.
Parent - - By Banned for Life (Gold) Date 2008-02-05 15:18
It's not obvious that stable score/PV with increased depth is a suitable stand-in for self-consistency. Rybka is certainly more stable with increased depth than other engines, but it seems likely that this is due, in large part, to focusing more of the search on the PV (with many other developers surprised by the degree that this is possible in the Strelka code). I suspect that this increased focus on the PV would result in a higher probability of a near optimal move, but maybe a lower probability of finding the optimal move.

Parent - By BB (****) Date 2008-02-05 16:01

> It's not obvious that stable score/PV with increased depth is a suitable stand-in for self-consistency.

It is in theory (that is, as depth goes to infinity). :) [In practise, I tend to agree with you - indeed, short-term self-consistency is not necessarily a great metric in backgammon, especially with back games]. Perhaps a better method would be to compare self-consistency (in a probabilistic sense) of 0ply searches to 1ply searches (allowing qsearch, I guess, as it's almost part of the eval in some thinkings) - this should be superior to comparing (say) 15ply to 16ply, where search stability/methodology should be of more importance.

> I suspect that this increased focus on the PV would result in a higher probability of a near optimal move, but maybe a lower probability of finding the optimal move.

This could also have to do with a somewhat different metric for evaluators, namely precision (or effective granularity). In the GBM paper, they put evaluations into 7 bins (white is won, white has a clear advantage, white has a slight advantage, equal, etc.). If you attempt a typical PV search in chess with only 7 possible results from your evaluator, the "hill" you need to climb in order to change the PV should become rather steep, which should lead to more stable PVs. If an engine were to demand that a non-PV move [anywhere in the tree] beat the corresponding PV move by more than the minimal increment, say 0.1 rather than 0.01, then the concern of granularity might not be purely academic. [I don't know if any engines do this to any real extent, though one can detect a similar notion in various types of pruning].
Parent - - By Sesse (****) Date 2008-02-05 13:40
Just a thought: Are search and evaluation as independent as people would sometimes have them to be? If you took one program's search and one program's evaluation, would you get a reasonable result, or are they interdependent somehow, leading to one influencing the development of the other?

Of course, instead of babbling about it I should just try it with two free engines, but then again, talk is cheap :-)

/* Steinar */
Parent - By Uri Blass (*****) Date 2008-02-05 14:08
In theory they are dependent.
I am not sure what happens in practice.

Parent - - By BB (****) Date 2008-02-05 14:15

>Are search and evaluation as independent as people would sometimes have them to be?

Some developers try to separate the two - others would rather have them be more related. For instance, if you evaluate at each node, you can then take the info you obtain (such as king safety and/or static threats) and use it to decide whether to reduce, or whether/how to use null move, or whatever. As an example, Schröder gives cases of this in his description of Rebel (see Search Techniques in REBEL).

Historically, there was also the question of data structures (particularly bitboards), though this has more to do with the interplay between move generation and evaluation than search/evaluation.
Examples would be: can one easily derive desired eval info from (say) bitboards as opposed to a different board representation? Which things should be computed incrementally in move generation (typically PieceSquareValues and Material) rather than being considered in eval? In a few years, a similar [though affecting eval almost exclusively] question might come about: when a fast POPCNT instruction becomes mainstream, will this lead the authors of engines to give consideration to different eval terms that were previously thought to be too costly to compute? [Actually, other than some calculations with mobility, I can't see fast POPCNT being a panacea, but others might be more clever than I].
Parent - By Uri Blass (*****) Date 2008-02-05 14:47
I use evaluation for pruning decisions but in my reply I thought about different type of dependency.
I thought about dependency that make the same better evaluation to be worse in another program.

In thoeory it is certainly possible and if we talk about practice I do not know.

In practics all the evaluations are dependent on search.
What I meant that I do not know is if we can say if evaluation A is better than B or cannot do it.
The only way to check it is to change program A and give her the evaluation of B and to do the same for B and give her the evaluation of A when the prize is 0(we can make one program artificially slower or play at unequal time control to emulate this situation).

What I do not know is if we are going to find that one program has better evaluation or not.
If we find that evaluation of program B make A better when we ignore the time factor than B has better evaluation than A.
If we find that evaluation of program A make B better than A has better evaluation than B.

If we find no this and no that then  it may be unclear which program has better evaluation.

Parent - By Vasik Rajlich (Silver) Date 2008-02-08 09:44
FWIW - if I had to make a wild guess, 80% of eval feedback is based on objective reasons and 20% is due to search artifacts.

Parent - By Vasik Rajlich (Silver) Date 2008-02-08 09:41
FWIW, re. search vs eval - I think that they're roughly equally important.

In Rybka, we tend to go through phases.

In late 2005, I went through a big eval phase. I think that this was the strongest point of Rybka 1.0 - although Larry seems to disagree with me about it :)

Throughout 2006, I basically just worked on search. This culminated with Rybka 2.2n2 and WinFinder.

When Larry joined me in 2007, we went back and worked on the eval again, under a completely different philosophy. The Rybka 2.3.X versions were a sort of early prototype of this method. I was quite happy with these steps and now they've been taken much further, to the point that Rybka is nearly unrecognizable.

Parent - By BB (****) Date 2008-02-05 13:44

>"Finally, Rybka is better than Crafty because Vas has implemented something new and interesting that I have not yet discovered. Nothing more, nothing less."  ----Robert Hyatt

Minimally, I would append an additional, indeed quite important, codicil: "... that I have not yet discovered and implemented." :)
[Maybe RH is espousing the Socratic notion - knowledge is virtue (or: once we know virtue, we will be virtuous) - while I propose the Aristotelian modification].
Parent - By turbojuice1122 (Gold) Date 2008-02-06 20:59
I guess that without this, instead of being 400 points stronger than Crafty, Rykba would only be 300 or so stronger... :-)
Parent - - By Vasik Rajlich (Silver) Date 2008-02-08 09:26
Sorry, this is just nonsense.

In fact, I've never even profiled Rybka and spend zero time on optimization. This should be quite obvious from the sources - there are no unrolled loops or other arcane constructions, assembly sequences which don't map to C, etc.

It just doesn't seem like a productive area, especially long-term.

A few comments for any bitboard fanatics who might be browsing here:

1) I typically put elegance and simplicity before speed. Don't look for too much meaning at the low level. Someone like Gerd Isenberg could probably speed Rybka up by 10-15% without crossing over into any really hard-core optimization.

2) I've always just used plain Crafty-style rotated bitboards, and haven't yet managed to try anything else. My intuition is that the magic number approach (which wasn't around when I started) would be a little bit better. This may be doubly true for Rybka, as I suspect that she pollutes the cache more than most engines. If I started today, this is probably what I'd go with.

Parent - By Uri Blass (*****) Date 2008-02-08 19:36
I think that the speed does not come from optimization to assembler but from good algorithm and good choice of data structure.
Of course 10% that you may get from optimization is not important.

Parent - - By Anthony C (*) Date 2008-02-08 23:03
Wow.  It has been a long time since someone treated me like a complete
idiot.  It's such a rare experience for me that I'm not even angry,
just amazed.  Somehow, without ever caring about execution speed, you
have written an engine that searches more nodes per second than *any
other commercial engine*, including Fritz, the engine written by the
man you claim is an assembler god.  A casual observer might be quite
confused by this, but someone who read Strelka's source code somewhat
less so, because it contains hundreds of examples of ugly code chosen
because it runs damn fast.  Some easy ones:

Strelka's search contains completely separate routines for PV and
non-PV nodes, which requires writing most search code twice, but saves
a few brances and cycles.  This could be done by #including C files,
but this is also ugly.

Strelka's noncapture move generator scores each move from the history
table, as opposed to having a separate loop, which is what everyone
else does.  This is faster, since there are probably free slots in the
pipeline during move generation, but it is extremely ugly, since any
change to history code must be done in 15 different places, once for
each piece type.

Strelka's static exchange evaluator doesn't compute the actual score,
but only whether or not the capture is losing or not.  Of course, it
is lightning fast since there are millions of early termination cases.
But compare it to Crafty's swap() function and then talk to me about
elegance and simplicity.

I could go on all day, but I think I've made my point.  Against this
mountain of empirical evidence, we have your claim that "you don't
program in assembly, and therefore you do no optimization".  Either
you are using a different set of definitions from the rest of the
world, or you are so desparate to maintain the reputation of Rybka as
a high-knowledge program that you first obfuscated its output and now
are attempting to maintain that illusion despite the previously
mentioned mountain of evidence to the contrary.  Mr Rajlich, if that
is your real name, let me remind you of an old quote: You can fool
some people all the time, and some people all of the time, but you
can't fool everyone all the time.  The jig is up, and while your
pitiful efforts to maintain the facade may convince people who don't
read C++, those of us who do are only lowering our opinion of your
integrity even further.


P.S. I have never understood why it's important that Rybka is a high
knowledge program anyway.  If it works, who cares?
Parent - - By NATIONAL12 (Gold) Date 2008-02-08 23:44
i am utterly amazed  by your post, i can only assume that you have had a great night out and something has upset you. i have spoken up for you many times on this site and you wish to destroy your good reputation by one very insulting post.
Parent - By Anthony C (*) Date 2008-02-09 00:18
Look, in Mr. Rajlich's post he claimed "spends zero time on optimization" and then went on to detail the many ways in which Rybka was horribly inefficient  There is just no way this is the truth.  Every byte of the Strelka source code screams out against it.  I didn't write 5 paragraphs of ad hominems.  I wrote 5 paragraphs of concrete examples of how the Strelka source code is extremely heavily optimized and how Rybka is amazingly fast. (OK, 4 paragraphs.  I admit the last paragraph was a little insulting, but I had a lot of fun coming up with it).

So I consider my reputation, for honesty at least, to be safe.

Parent - - By Carl Bicknell (*****) Date 2008-02-08 23:44
Vas needs to answer this - no one else can.

From a non-programmer point of view though there is just one thing I don't understand: If Rybka is a high-speed, low-knowledge program then what is Larry doing?? Surely he'd practically be redundant...
Parent - - By Anthony C (*) Date 2008-02-09 00:22
Let me add one other thing: I'm talking about Rybka 1.0 Beta, that engine that took the chess world by storm and crushed everything that opposed it.

It is highly likely, in fact almost certain, that whatever is on Mr. Rajlich's computer now is very different.

Parent - By NATIONAL12 (Gold) Date 2008-02-09 00:27
in that case i completely misunderstood your post as i imagine a number of other people will.
Parent - By BB (****) Date 2008-02-09 03:35

> whatever is on Mr. Rajlich's computer now is very different.

This is one "human" reason which makes the VR story reasonable (he mentioned it in passing himself) - optimisation is something that is typically done at an endpoint [having run out of new ideas to try, for instance], not in the mid-stages of development. Of course, Rybka 1.0 might have been an "endpoint" just as much as a "starting point" from what we can tell.
Parent - - By Uri Blass (*****) Date 2008-02-09 04:20
I can answer it because I can think that Larry also could work on strelka so I will reply for strelka.

high speed does not mean low knowledge and I do not consider strelkato be a low knowledge program.

Strelka is using more than an hundred of constants in the evaluation even without the material table and Larry explained that part of his job is to find better values for the numbers.

Note that strelka code has a lot of magic numbers and I corrected names to significant variables in my private version of code

In eval.c after modification
I can easily count 7 constant names for pawn structure and 2 array of 8 variables for candidate pawns in the part that is going to pawn hash

It gives practically 7+2*6=19 constants for Larry to modify.

2)7 arrays for passed pawns scoring in the opening and the endgame give 42 values to tune
3)6 constants for king attack 8 constants for mobility
4)11 constants for different tasks
5)16 variables for king attack weight

6)The following 16 constants are part of the code of strelka and are used to calculate the piece square table

const __int16 PawnFileOpening = 181;
const __int16 PawnFileEndgame = -97;
const __int16 KnightCentrOpening = 347;
const __int16 KnightCentrEndgame = 56;
const __int16 KnightRankOpening = 358;
const __int16 KnightTrapped = 3200;
const __int16 BishopCentrOpening = 147;
const __int16 BishopCentrEndgame = 49;
const __int16 BishopBackRankOpening = 251;
const __int16 BishopDiagonalOpening = 378;
const __int16 RookFileOpening = 104;
const __int16 QueenCentrOpening = 98;
const __int16 QueenCentrEndgame = 108;
const __int16 QueenBackRankOpening = 201;
const __int16 KingFileOpening = 469;
const __int16 KingCentrEndgame = 401;

There are more constants and I already counted more than 100 constants in this post.
The job of finding the best values for the numbers is not an easy job and I believe that nobody can find the best values when even larry
cannot do it and the best that he can do is finding better values than the existing values.

Do not believe people who tell you about low knowledge programs and all the top chess programs have a lot of knowledge in their evaluation.

Strelka may have less knowledge relative to other programs (I am not sure about it because I did not see the code of Fritz Junior or Hiarcs) but it does not mean that strelka is a low knowledge program.

If you are interested in low knowledge programs then I suggest that you use only 10 numbers in your program to calculate the evaluation
(it is possible to do it and only material evaluation use only 5 numbers for the value of the pieces).

Note that even in the hypotethical case of 10 numbers it is not trivial to find the best values but this case does not happen and practically we have 2 type of programs:

1)high knowledge programs
2)very high knowledge programs.

The evaluation of the programs of type 2 is not always better than type 1 because if for example you have 100,000 constants to optimize then it is easier to get wrong values for the constants.

Parent - - By BB (****) Date 2008-02-11 00:29

> Larry explained that part of his job is to find better values for the numbers.

I think another part of LK's job is to find new things to measure, and I would say that this is probably of more importance. Diddling with numbers can be done to some extent via (say) learning techniques [albeit with slow convergence in many examples], but finding new "positional features" (to borrow a word from neural nets) is more likely to require human input. It is also not clear to me that simply the number of constants (quantity as opposed to quality) is a useful metric for judging knowledge.
Parent - - By lkaufman (*****) Date 2008-02-11 01:52
Yes, everything you say here is exactly right, I think. We add new terms to the eval almost daily (maybe 75% from me, 25% from Vas), but many of them are partly redundant with others, so the number of terms does not tell very much. Some are worth very little if anything, but some are really big (like one added today!).
Parent - - By Debaser (***) Date 2008-02-11 09:53
Hi Mr Kaufman

From time to time you have made post like this, that adding a particular term to the evaluation resulted in a big impact.

Is it possible, if you have time, to post a pair of positions in which this had happened, with the evaluation by the new and the old rybkas?

Or if it is top secret right now, when the release date arrives will you do it? Something similar to this
Parent - - By Eelco de Groot (***) Date 2008-02-11 10:30
Yes it would also be interesting to know if maybe discussions or suggestions in this thread or elsewhere contributed, to this new term in particular? I suppose coming up with new terms is usually an independent process, inspired by chessgames that Larry plays maybe, or is it mainly based on the games you see from Rybka?

Regards, Eelco
Parent - By Vasik Rajlich (Silver) Date 2008-02-15 16:33
This work is very technical / tedious, discussion wouldn't really help.

We'll do our best to describe everything in general terms before Rybka 3 is released.

Parent - - By lkaufman (*****) Date 2008-02-11 16:25
When a new term gives a big boost to Rybka, it is of course top secret, and will remain so after release. This term, like many others, is something that good players know and that can be found in chess books, and is most likely already in at least some other programs. But knowing which terms are important is useful for our competitors, because they would then spend time refining the corresponding term (if any) in their own programs. There are hundreds of little rules ("knights on the rim are dim" for example) that can be found in chess books, and probably 90% of them are valid to some degree and worthy of inclusion in a chess program, but knowing which ones are important is vital information.
Parent - - By Roland Rösler (****) Date 2008-02-11 19:20 Edited 2008-02-11 19:26
When a new term gives a big boost to Rybka, ...
Ok Larry, all is top secret, but please give us some hints:
1. What is a big boost for a new term in your mind?
2. Hwo do you verify the boost? By a number of positions prepared for the new term or by 36,000 games with 1" per game or by other means?
3. How many terms do you have in Rybka now approximately?
4. Did you ever delete terms in the past, because they didn´t work or trust you always in the future for better values?
Parent - - By lkaufman (*****) Date 2008-02-11 23:45
1. Somewhere around 10 Elo in my test, which probably means about 5 real Elo in a CCR/CEGT type test.
2. Mostly by something like your 36,000 1" games, but we also make sure that the gains are still there at slow speeds (like maybe 5" per game!). Of course it is possible that something may help at those speeds but not at game/5' or slower, but this rarely if ever seems to happen. Only the Elo gain may be less.
3. Somewhere in the ballpark of a thousand, though some of those are not currently treated as independent terms so one could also say just a few hundred.
4. Often Vas gives me a version with new terms I request or he proposes, but if I can't prove their value after several tries at setting values he will not include them in the real Rybka program. They usually remain in my versions for a long time in case I want to try again.
Parent - - By Roland Rösler (****) Date 2008-02-12 01:01
Many thanks for your frankness! Some remarks from my side to the points:
1. Wow!! This is really a boost! I´m not so convinced about your cutback (CCRL/CEGT) I have seen already earlier in your post. That´s not only enthusiasm from my side. We will see ..
2. I think, eval helps more on long distance. Not all eval terms can be covered by search!
3. Have you a clue about interdependences of your (independent) terms? I believe, it´s a main claim to restrain terms from each other! If you aren´t alert, you wouldn´t know, what you are testing. Maybe less is more!
4. I only asked this because of point 3. If you have hundred of terms, can you say me, which term is decisive for eval of rook on line 7? Only one term, or three, or maybe 8? And you know the interdependences?
Oh I see, it´s a hard business!
Parent - - By Patricio (***) Date 2008-02-12 02:44
It seems that Larry has a tough, difficult and very very important task here.

Just one comment. I propose a better word than interdependences. I think it would be better to call correlation.

If some terms are correlated among themselves the engine could end up over/under estimating a position. Because some weights are redundant on more than one term.

Just an opinion.

Parent - - By Roland Rösler (****) Date 2008-02-12 03:07
You are right here. Correlation is much better than interdependence, because it´s the scientific (statistical) approach I want to support. And Larry can give me the coefficient of correlation for terms of one issue (always only one number) and I´m satisfied.
Parent - By Banned for Life (Gold) Date 2008-02-12 04:22
What you are looking for is the covariance matrix for the terms. You could calculate this covariance matrix by looking at the average of the outer product of the terms over a huge number of positions. If you were so inclined, there are techniques that could be used to get rid of the inter-term correlations. Removing these off-diagonal terms might make the calculations a little easier, but the terms would no longer be meaningful to Larry so this probably isn't practical.

Parent - - By lkaufman (*****) Date 2008-02-12 04:49
You are right that many (but not all) eval terms are more important in deeper searches. However, the Elo gain may still be less with depth just due to the increased percentage of draws. Also there is the issue that rating gains of Rybka vs. Rybka may be somewhat less when we're talking about ratings vs. other engines. As for interdependence or correlation of terms, we haven't tried to measure this. It is obvious to me that many terms have a very high correlation and others are pretty much on their own. When terms are heavily correlated, setting their values is extremely difficult, but on the other hand errors in setting these values are less serious. Just to give one common example, rook on open file and rook vertical mobility are obviously highly correlated, but yet different. A rook can move to an open "d" file with a knight sitting in front of it on d2, so zero forward mobility. The move is both good and bad then, good for the long range potential that the blocking knight may move, bad for immediate use. Setting these values is partly a matter of judgement and experience, but I must also go by results. The more correlated terms are, the more I must depend on my own judgement. For independent terms, results are everything. For me the most frustrating part of my work is that sometimes I cannot get good results for a term or terms that I really believe in, for example a term to prevent Nc3 with pawns on c2 and d4. Probably correlation with some other terms is the problem, but sometimes it is just too hard to solve.
Parent - - By Vasik Rajlich (Silver) Date 2008-02-15 16:40
Just one other comment here --

What we currently do is very primitive and very human-based. Larry manages by hand tons of interrelated and "dirty" chess terms, using his own chess intuitions, which were learned the hard way.

We do have some ideas for automating some of these processes and making them more scientific. This is for Rybka 4 and beyond. In theory, some general techniques could be developed which could then be applied to other games which are 'similar to chess'.

As usual, the future is a lot more exciting than the reality :)

Parent - By turbojuice1122 (Gold) Date 2008-02-15 20:21
Hmmm...this sounds potentially like automatic learning in the form of automatic parameter changes and such...?
Parent - By SillyFunction (**) Date 2008-02-16 08:15
Life is great with yearly new discoveries!!
Parent - Date 2008-03-01 05:44
Parent - - By turbojuice1122 (Gold) Date 2008-02-12 01:14
You mention leaving some in the program in case you want to use them again--do these provide anything of a noticeable slowdown?  For example, if you left in 100 neutral terms, would anyone be the wiser due to a noticeable slowdown in nps?
Parent - By lkaufman (*****) Date 2008-02-12 04:55
Yes they do slow down my testing version noticeably, but if they do not remain in the "real" Rybka program it doesn't matter to anybody but me.
Parent - - By Debaser (***) Date 2008-02-12 00:09
OK ;)

But can you say us what books do you consider specially useful? For example for endgames:

Dvoretsky's Endgame Manual and Muller and Lamprecht Fundamental Chess Endings?

Anyhow, something like the fritz 9 engine information page should not harm rybka secrets.  Positions from some historical games, where the new rybka evaluation is better.  When you release her, should be some nice publicity.
Parent - By Roland Rösler (****) Date 2008-02-12 01:15
Books are useful for humans, but not for engines :-). And if you haven´t read Dvoreckijs endgame book, it´s a pity.
Parent - - By lkaufman (*****) Date 2008-02-12 01:42
I have read Dvoretsky's manual, and other endgame books, but I mainly rely on my total chess knowledge, not some particular book. Most of our endgame work is still general, we haven't had the time to work on many very specific endgame situations yet.
Parent - - By Roland Rösler (****) Date 2008-02-12 02:07
Ok, endgame is hard stuff! But when I see Rybka 3 (without TBs) with problems in K vs. KBP where B is "wrong" and P is edge, I punish myself. I don´t buy her!
Parent - By lkaufman (*****) Date 2008-02-12 05:03
For very specific endgames, like your example, it's just a question of when Vas has time to cover them. I can only address more general issues. I believe the endgame in Rybka 3 will be much better than in Rybka 2.3.2, although there will still be specific endings that Rybka will misplay (especially without tablebases) due to lack of some exact piece of knowledge. Rybka now has a much better idea of which types of endings to head for, and a better sense of where to place the king, just to give two examples of improvement.
Parent - - By Uly (Gold) Date 2008-02-12 07:30

> But knowing which terms are important is useful for our competitors, because they would then spend time refining the corresponding term (if any) in their own programs.

And what's bad about it? You could get a stronger opposition to show how good Rybka really is (and I think that would be good for computer chess in general.)
Parent - - By lkaufman (*****) Date 2008-02-12 16:23
I think that with the information about Rybka that has already been made public by the clones we have already (if unintentionally) done more than one could ask to help our competitors and push the field forward. If Rybka should lose her standing as the top program (other than briefly) it might not be possible for Vas to continue to work full time on this (and for me roughly 3/4 full time).
Up Topic Rybka Support & Discussion / Rybka Discussion / Anthony Cozzie speak !
1 2 3 4 5 6 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill