I wouldn't mind to browse this data.
Ideally, we would discard:
1) Games settled by disconnect
2) Games settled by failure in a 4-man ending
3) Games between weaker programs
Vas
Ideally, we would discard:
1) Games settled by disconnect
2) Games settled by failure in a 4-man ending
3) Games between weaker programs
Vas
Give me a couple of days and I'll send you some eye-opening stuff.
Case 2 would be well represented for Rybka 2.3.2a since it includes the most basic blind bishop endgames. In any event, I would think the test should be done at the point where the number of pieces first becomes six. This should be representative of the GUI implementation and would not include additional gains possible by use of TBs in the search.
Regards,
Alan
Regards,
Alan
why 0.5 ? can't it cause to lose a full point?
Correct, but blown endgames mean -0.5 about 97% of the time.
> Will a Linux release be made in the near future?
>
>Probably not. We will consider ports of all types in the next few months, but Rybka does already run under Linux using emulators, so this one is not a top priority.
Oh dear, did I kill the native port? :-)
/* Steinar */
>
>Probably not. We will consider ports of all types in the next few months, but Rybka does already run under Linux using emulators, so this one is not a top priority.
Oh dear, did I kill the native port? :-)
/* Steinar */
Nooooo :)
Admit it, that was your plan all along! :)
Vas
Vas
Actually, the question is what the heck I was thinking. I must have been very bored :-)
/* Steinar */
/* Steinar */
Vas:
Rybka 3 - Rybka 3 Human - Rybka 3 Dynamic: I assume the default Rybka 3 is intended to give the strongest play and analysis overall: Can the developers give us some insight as to why and in what situations we might want to use these alternatives? What is the logic behind creating these separate "personalities"? Is it worth it to analyze a position with Rybka, and also look at it with Rybka Dynamic, or would it be better to just let Rybka think longer?
What are "static" and "dynamic" factors, and how does Rybka classify them (so I can better understand the difference between them?) I would love to have more information on this. Thanks.
Rybka 3 - Rybka 3 Human - Rybka 3 Dynamic: I assume the default Rybka 3 is intended to give the strongest play and analysis overall: Can the developers give us some insight as to why and in what situations we might want to use these alternatives? What is the logic behind creating these separate "personalities"? Is it worth it to analyze a position with Rybka, and also look at it with Rybka Dynamic, or would it be better to just let Rybka think longer?
What are "static" and "dynamic" factors, and how does Rybka classify them (so I can better understand the difference between them?) I would love to have more information on this. Thanks.
You will find what you want if you search this forum messages that contain the words "dynamic" or "human" or "difference" from the poster: "lkaufman"
Thanks, here are some comments of his that I found might be useful to others:
"Actually, the Dynamic version is slightly misnamed, it should really be "Dynamic Human" version. They are both supposed to be more like humans, just very different humans (think Karpov and Tal). I might even try a different version for each of the first three games."
"Dynamic has some of this supposedly worthless knowledge too. Human and Dynamic mainly differ in terms of whether they emphasize static or dynamic advantages."
"Rybka 3 is supposed to be the best, but tests so far show that all three are so close in strength that we really don't know yet, especially if the question is which is best at longer time controls or analysis. Rybka 3 is definitely the strongest at hyperspeed (game in one second or faster!), and probably the strongest at blitz, but the other two versions, though a bit slower, do have extra knowledge and in my opinion more reasonable relative piece values, so the jury is still out."
Would be great to get more info about this codified into the FAQ.
"Actually, the Dynamic version is slightly misnamed, it should really be "Dynamic Human" version. They are both supposed to be more like humans, just very different humans (think Karpov and Tal). I might even try a different version for each of the first three games."
"Dynamic has some of this supposedly worthless knowledge too. Human and Dynamic mainly differ in terms of whether they emphasize static or dynamic advantages."
"Rybka 3 is supposed to be the best, but tests so far show that all three are so close in strength that we really don't know yet, especially if the question is which is best at longer time controls or analysis. Rybka 3 is definitely the strongest at hyperspeed (game in one second or faster!), and probably the strongest at blitz, but the other two versions, though a bit slower, do have extra knowledge and in my opinion more reasonable relative piece values, so the jury is still out."
Would be great to get more info about this codified into the FAQ.
Ok, thanks. I'll expand a bit on "static" vs "dynamic".
We don't know yet the strength of these three versions. Once data exists, we'll add that as well.
Vas
We don't know yet the strength of these three versions. Once data exists, we'll add that as well.
Vas
Static features are ones that are unlikely to change quickly. Examples include material advantage, better pawn structure, advanced passed pawns, and better combination of pieces on the board (such as bishop pair). Dynamic features are ones that can change very quickly, such as lead in development, better mobility, and more pieces attacking the enemy king. These definitions are in various chess books. Some features are in between, and it is a matter of opinion as to which class they should be put into.
Maybe your answer to the "Engine XY must be modified" is not correct. This message should usually pop up in the Fritz GUIs when you have changed the default parameters during install process. If you want to finish the install process thenm, you can't beause you first must change (modify) the engine name in the window, or more exactly add something to it, like "Rybka 3 big contempt"...
Aha, thanks.
Vas
Vas
Is there a way to prevent the persistent hash from getting filled up with late middlegame and endgame positions? This might be ok for analysis, but for game play it would be better to restrict storage to opening and middle game positions...
Regards,
Alan
Regards,
Alan
Right now using Persistent Hash for games isn't recommended.
Maybe not, but persistent hash was the primary reason that I purchased R3, so I will use it, recommended or not. And maybe when Vas fixes whatever the current bug is, he can figure out a way to help keep the PH from getting filled with high depth endgame positions.
Alan
Alan
You could always increase the size of the file. As far as I understand it the stored information doesn't take much space, so if you set the size to 500 Megs or so you should be fine for a long time. But meanwhile I do suspect that perhaps even with the bug fixed it might be better to use PH only with deep analysis. Unless perhaps it has some kind of "self repair mechanism" in case of having stored a bad move...
> You could always increase the size of the file.
Resizing works erratically.
Does it? What's the problem?
Most of the time, it fails. Sometimes it's resized to 832 MB (=FUBAR).
Do you think a 3.1 will be released due to these bugs? (including the MP bugs) or, er...
Will we have Persistent Hash working properly on play, until 2009?
Will we have Persistent Hash working properly on play, until 2009?
[gelöscht]
You could always increase the size of the file.
I made it as large as possible to start with so this isn't an option. In any event, it doesn't address the issue of time to depth being much shorter in the endgame, resulting in greater depths for positions that will end up in PH and then never be seen again.
As far as I understand it the stored information doesn't take much space, so if you set the size to 500 Megs or so you should be fine for a long time.
Each entry is 8 bytes according to a previous VR post. But are you familiar with the birthday problem? If you had a 365 element hash table, the median number of entries before the first collision would be 23. This is compounded by Vas' decision to not incorporate set associative behavior, and the realization that there is a good chance that a position with a greater depth will never reoccur.
Unless perhaps it has some kind of "self repair mechanism" in case of having stored a bad move...
Apparently from Vas' response above, self repair is going to the bad position in analysis mode (or farther into the game), and backing up until the position is evaluated at a greater depth than in PH with a more accurate eval. I can live with this. I don't have great confidence in magical "self repair mechanisms" (or the tooth fairy).
Regards,
Alan
I made it as large as possible to start with so this isn't an option. In any event, it doesn't address the issue of time to depth being much shorter in the endgame, resulting in greater depths for positions that will end up in PH and then never be seen again.
As far as I understand it the stored information doesn't take much space, so if you set the size to 500 Megs or so you should be fine for a long time.
Each entry is 8 bytes according to a previous VR post. But are you familiar with the birthday problem? If you had a 365 element hash table, the median number of entries before the first collision would be 23. This is compounded by Vas' decision to not incorporate set associative behavior, and the realization that there is a good chance that a position with a greater depth will never reoccur.
Unless perhaps it has some kind of "self repair mechanism" in case of having stored a bad move...
Apparently from Vas' response above, self repair is going to the bad position in analysis mode (or farther into the game), and backing up until the position is evaluated at a greater depth than in PH with a more accurate eval. I can live with this. I don't have great confidence in magical "self repair mechanisms" (or the tooth fairy).
Regards,
Alan
Apparently from Vas' response above, self repair is going to the bad position in analysis mode (of farther into the game), and backing up until the position is evaluated at a greater depth than in PH with a more accurate eval. I can live with this. I don't have great confidence in magical "self repair mechanisms" (or the tooth fairy).
Actually I meant something like that with "self repair mechanism". So I could live with it, too.
Actually I meant something like that with "self repair mechanism". So I could live with it, too.
Obviously, there is a cost from having imbalanced depths going from middlegame to endgame. This will be relatively less of a problem during the initial analysis, where the only issue is that more endgame positions will be above the "Write Depth" and get stored. It will be relatively more of a problem during file merges, which are prioritized by depth.
Indeed, self-repair is for Rybka 6. That's a hard problem.
Vas
> Apparently from Vas' response above, self repair is going to the bad position in analysis mode (or farther into the game), and backing up until the position is evaluated at a greater depth than in PH with a more accurate eval. I can live with this. I don't have great confidence in magical "self repair mechanisms" (or the tooth fairy).
Indeed, self-repair is for Rybka 6. That's a hard problem.
Vas
...persistent hash was the primary reason that I purchased R3...
I was thinking I'm the only one who give this much priority to persistant hash.
But as far as I understood (I didn't buy R3 and use persistant hash yet), the feature isn't like as we expected it to be.
I can't tell you the best way, but I know that to make good use of a feature, one must understand it well. And new persistant
hash feature doesn't seem simple enough for me to use well.
I was expecting that when I would close my computer after hours of search, I would click a button of GUI and Rybka would save the hash to hard disc.
And tomorrow, when I start my computer, I would load the hash back and Rybka will continue to search from the point she was stopped yesterday. This way, I would be able to reach to depths never seen before.
Maybe this persistant hash approach of Vas is better than my expectation. Maybe I need some time to orientate :)
I was thinking I'm the only one who give this much priority to persistant hash.
But as far as I understood (I didn't buy R3 and use persistant hash yet), the feature isn't like as we expected it to be.
I can't tell you the best way, but I know that to make good use of a feature, one must understand it well. And new persistant
hash feature doesn't seem simple enough for me to use well.
I was expecting that when I would close my computer after hours of search, I would click a button of GUI and Rybka would save the hash to hard disc.
And tomorrow, when I start my computer, I would load the hash back and Rybka will continue to search from the point she was stopped yesterday. This way, I would be able to reach to depths never seen before.
Maybe this persistant hash approach of Vas is better than my expectation. Maybe I need some time to orientate :)
I always knew it's never gonna quite work. It's like holy grail of computer chess. I don't use it at all.
There are two things, saving hash and persistent hash. The first one is meant to work like you described.
Vas has differentiated between saving a hash image (which is what you are talking about doing), included as "save/load hash", and saving high depth entries for reuse later, called persistent hash. They both work pretty much as expected. The fact that they aren't perfect in their initial implementation is expected and doesn't bother me at all since I still think they can be devastating for use in preparing for freestyle and correspondence games.
Regards,
Alan
Regards,
Alan
To buy Rybka3, I'm waiting for my quad to be ready.
> Is there a way to prevent the persistent hash from getting filled up with late middlegame and endgame positions? This might be ok for analysis, but for game play it would be better to restrict storage to opening and middle game positions...
Good point. The problem is that depth X in the middlegame is typically a much higher level of quality than depth X in the endgame.
This issue also comes up when you play fixed-depth games during Monte-Carlo simulations. The endgame is played at a much lower quality in the middlegame.
The eventual solution to this will be to redefine what a depth means so that depth = X for a middlegame is comparable to depth = X for an endgame. This can probably be done via some sort of constant depth offset. I'll look into this at some point, hopefully before Rybka 4.
For now, we just have to live with these inequalities.
Vas
As Dr. Mueller pointed out a while back, what you really want to store are evaluations that save you the most time in the search. This should be some combination of evaluation quality and probability that you will see the position again. As you point out, depth is a rather crude approximation for evaluation quality, since it is highly dependent on game stage.
For now, we just have to live with these inequalities.
I think the persistent hash is already an incredibly powerful tool. I think this will become obvious at the next freestyle when people show up with incredibly well prepared novelties that would not have been possible back when you had to store each line manually. Tools like IDeA which allow the tree to be expanded in an automated fashion will be very useful here too. I see this as being even more significant for analysis than the raw improvement in playing strength!
For engine-engine games, persistent hash also solves a problem with the CB GUI, which refuses to play a move that repeats a position. This was probably a design choice, but a number of people have been using this to get black to play sub-optimal moves, rather than force white to either accept a draw by repetition, or choose a suboptimal move.
Regards,
Alan
For now, we just have to live with these inequalities.
I think the persistent hash is already an incredibly powerful tool. I think this will become obvious at the next freestyle when people show up with incredibly well prepared novelties that would not have been possible back when you had to store each line manually. Tools like IDeA which allow the tree to be expanded in an automated fashion will be very useful here too. I see this as being even more significant for analysis than the raw improvement in playing strength!
For engine-engine games, persistent hash also solves a problem with the CB GUI, which refuses to play a move that repeats a position. This was probably a design choice, but a number of people have been using this to get black to play sub-optimal moves, rather than force white to either accept a draw by repetition, or choose a suboptimal move.
Regards,
Alan
> For engine-engine games, persistent hash also solves a problem with the CB GUI, which refuses to play a move that repeats a position.
I am not aware of this problem. Is it a general GUI problem (which version?), or Rybka related only (which version)?
This is a CB GUI issue and is true for all engines. It is a problem in GUI7, GUI8, and GUI9. I don't have GUI10 or GUI11, but its probably there too. As I mentioned, this was probably a design decision from the CB GUI development team, designed to prevent book draws by repetition. What they neglected to consider is that sometimes a book draw by repetition is not a bad thing and it may be far and away the best choice in some cases.
Regards,
Alan
Regards,
Alan
> As Dr. Mueller pointed out a while back, what you really want to store are evaluations that save you the most time in the search. This should be some combination of evaluation quality and probability that you will see the position again. As you point out, depth is a rather crude approximation for evaluation quality, since it is highly dependent on game stage.
Yes, and this brings up one other point.
Currently, we use age as an approximation for the likelihood that we will see the position again. This also isn't perfect. For persistent hash entries, we're far more likely to see an opening position again than an endgame position. This issue is probably significant enough to deserve an engine parameter.
Basically, the endgame is currently overemphasized for two completely different reasons.
> I think the persistent hash is already an incredibly powerful tool.
The one thing I'm afraid of here is that persistent hash for Rybka 3 will go the way of the randomizer for Rybka 2, ie. too hard for normal users to use without special interface support.
Vas
>> I think the persistent hash is already an incredibly powerful tool.
> The one thing I'm afraid of here is that persistent hash for Rybka 3 will go the way of the randomizer for Rybka 2, ie. too hard for normal users to use without special interface support.
>
> Vas
Persistent hash is 1 more step to solve the chess game !
Is there plan to build an internet repository where users can send there PH (with at least some depth) ?
This area will growth and become more and more accurate with time ;)
Basically, the endgame is currently overemphasized for two completely different reasons.
How about a simplistic filter that only writes data to persistent hash when there the number of pieces on the board is greater or equal to N?
The one thing I'm afraid of here is that persistent hash for Rybka 3 will go the way of the randomizer for Rybka 2, ie. too hard for normal users to use without special interface support.
That would really be a shame, especially with the default being off anyway. I am currently using this feature to play repeated games from problematic positions at good depth against other engines, and with careful setup it provides a large increase in playing strength. Later, when I go over the games in analysis mode, it saves a lot of time by remembering the evaluation and depth information. Given a choice between R2.3.2a with this new functionality and R3 without it, I would pick the former. I think this will catch on with time and there is a lot of low hanging fruit that will allow you to make significant improvements without investing a lot of time.
Regards,
Alan
How about a simplistic filter that only writes data to persistent hash when there the number of pieces on the board is greater or equal to N?
The one thing I'm afraid of here is that persistent hash for Rybka 3 will go the way of the randomizer for Rybka 2, ie. too hard for normal users to use without special interface support.
That would really be a shame, especially with the default being off anyway. I am currently using this feature to play repeated games from problematic positions at good depth against other engines, and with careful setup it provides a large increase in playing strength. Later, when I go over the games in analysis mode, it saves a lot of time by remembering the evaluation and depth information. Given a choice between R2.3.2a with this new functionality and R3 without it, I would pick the former. I think this will catch on with time and there is a lot of low hanging fruit that will allow you to make significant improvements without investing a lot of time.
Regards,
Alan
> How about a simplistic filter that only writes data to persistent hash when there the number of pieces on the board is greater or equal to N?
Something like this makes sense. All of this will be revisited before Rybka 4.
> That would really be a shame, especially with the default being off anyway. I am currently using this feature to play repeated games from problematic positions at good depth against other engines, and with careful setup it provides a large increase in playing strength. Later, when I go over the games in analysis mode, it saves a lot of time by remembering the evaluation and depth information. Given a choice between R2.3.2a with this new functionality and R3 without it, I would pick the former. I think this will catch on with time and there is a lot of low hanging fruit that will allow you to make significant improvements without investing a lot of time.
Ok, that's good to hear. For Rybka 4, I'll think about better interface support. Persistent hash is off by default because it needs a filename. Setting this up is conceptually a job for the interface.
Vas
>How does Rybka's contempt work?
>In Rybka 2.3.2a, it only affects immediate draw decisions, like whether to repeat position or allow fifty move rule draw. In Rybka 3, it is very important. It affects many aspects of play, such as whether to seek or avoid even trades, whether to open or close the position, whether to seek or avoid pawn symmetry, etc.
I'm very curious about the following 2 things about contempt:
•1)If Rybka with NO contempt has on a position a +0.60 evaluation at let's say 15 ply, then setting contempt to 100, will this make her to have an evaluation on the same position on the same ply, of:
-Around +1.60
-Exactly +1.60
-Nothing from the above and it depends from other things. If this is the correct answer then from what it depends?
•2)Setting contempt to 80 means that:
If you are behind with a 0.50 score that a zero-contempt Rybka gives, then Rybka with non-zero-contempt thinks she is better with 0.8-0.5 = 0.30 so it avoids playing drawishly. Right?
Right i guess, but this is not the question. The question is:
If there is an almost sure draw then what evaluations she would have? +0.80 or 0.00 ?
Or to revert it: If it reports 0.00, does this mean she thinks position is draw and the position is indeed a draw or she thinks it's a draw but the position is actually -0.80(due to the contempt)?
> 1)If Rybka with NO contempt has on a position a +0.60 evaluation at let's say 15 ply, then setting contempt to 100, will this make her to have an evaluation on the same position on the same ply, of:
Somewhere between +0.60 and +1.60.
> If there is an almost sure draw then what evaluations she would have? +0.80 or 0.00 ?
0.00 (to the extent that the mechanism works properly).
Essentially, the score Rybka displays should reflect her confidence in winning the game.
Vas
ps. I'll add these questions to the FAQ.
Has Rybka been slowed down to prevent decompilation?
No. We have a much better way to deal with this issue - just wait a bit and you'll see
What EXACTLY this means?! Packed, hashed or maybe something else? Why such a conspiracy and WHAT we will see?
No. We have a much better way to deal with this issue - just wait a bit and you'll see
What EXACTLY this means?! Packed, hashed or maybe something else? Why such a conspiracy and WHAT we will see?
you will see :)
Allways enigmatic response ... i'm very curious too :-)
we could add this to the FAQ :
What will I see?
You will see.
What will I see?
You will see.
When will I see it?
You'll see it soooon.
You'll see it soooon.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill