1
2
Date 2008-08-25 23:17
It is nice to know you have these bugs fixed - will you be letting your customers have these fixes or do they have to pay for them next year in Rybka 4?
They aren't fixed yet, I just expect some fixes before the Milov match. As far as I know there won't be another Rybka release until R4; so far none of the bugs reported is of the magnitude that clearly calls for a bugfix version (for example the bug in Deep Fritz 10 that made it useless on a quad, which was fixed by 10.1).
ok nice to know. But if it does not do what it says on the can aren't you obliged to fix them?
Any decision about a bugfix version would be up to Vas, not to me, but what specific claim is made that you find untrue? The bugs I know about are of an intermittent nature, for example the bishops-of-opposite color bug seems to affect some such positions but not others, similarly with the MP bug in certain endings.
see Vytron's reply. Basically I get annoyed when I see you saying the match will be played with a bug fixed version when people have paid expecting a bug free version.
![[de]](/mwf/v12/flags/de.png "Germany")
+1
I am sure that it will still not be bug-free. I just expect the bugs that are easy to fix and directly relevant to playing strength to be fixed, mainly the bishops of opposite color one.
> I am sure that it will still not be bug-free. I just expect the bugs that are easy to fix and directly relevant to playing strength to be fixed, mainly the bishops of opposite color one.
Some of Rybka's customers dont attend the "church of the holy ELO" :) :)
I would like to have a reliable analysis engine. especially for endgames. I dont consider Rybka 3 reliable in that aspect. I must agree with Harvey on this point ..
"Basically I get annoyed when I see you saying the match will be played with a bug fixed version when people have paid expecting a bug free version"
Convekta is very active in fixing Aquarium.
ChessBase is making progress on some of the bugs with the new GUI. I have a fix from Mathias Feist that addresses my issues reported here :
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=96525;hl=
The Rybka team would be wise to address their own software problems before Rybka 4 is released IMHO :)
And to those who claim that EGTB's only offer a few, if any, ELO points, I would ask how you can be confident in that judgement until you fix the MP EGTB bug ? How confident are you in the so called "sporadic nature" of this bug ?
I was talking about fixing bugs for the Milov match, which pretty much means only those bugs that are important for Elo points. I don't know why people would expect to get a bug free version of Rybka, has that ever happened so far? Of course they might expect to get a version free of major bugs, so as always it comes down to what is a major bug. Regarding EGTB MP bug, we seem to get larger rating gains on MP than on SP relative to Rybka 2.32a, so it doesn't exactly appear to be crippling. Basically Vas is convinced that EGTB only rarely affect the outcome of games. Anyway it doesn't matter too much whether it's a 1 Elo bug or a 10 Elo bug; I expect Vas will fix it soon unless the fix has bad side effects. I have nothing to do with decisions about whether or not to release a bug-fix version; it's certainly fine with me to do so, but I don't know what any contracts might say on the matter or whether there are other considerations I'm not aware of.
> Regarding EGTB MP bug, we seem to get larger rating gains on MP than on SP relative to Rybka 2.32a,
The EGTB MP bug also exists in Rybka 2.3.2a. You are comparing versions with the same flaw. I think that Rybka 3 and the two associated GUI's were all rushed into production without sufficient testing. I own all three so that is my personal experience, of course YMMV. Convekta and even Chessbase are providing bug fixes. Until the MP EGTB problem is fixed , I will view any statement by the Rybka team concerning ELO and EGTB's with a healthy amount of scepticism.
Yes, and we don't want to forget the persistent hash issues. That's my personal most important fix requiremnet.
![[mx]](/mwf/v12/flags/mx.png "Mexico")
And the excuse was "It's minor because Rybka is meant to be used for analysis" :(
Actually since I just read your messing-up-hash-post, I think that the whole PH approach has to be reconsidered. Right now we should probably build a fence around it with a message: "Danger! Biohazard!" Or something similar... ;-)
![[hr]](/mwf/v12/flags/hr.png "Croatia")
Such a fence should probably also be built around Sampled Search, mp tablebase use, and some bishop endgame analysis. :-)
I'm just sittin' on a fence
You can say I got no sense
Trying to make up my mind
Really is too hard to find
So I'm sittin on a fence
(c) The Rolling Stones, 1967
You can say I got no sense
Trying to make up my mind
Really is too hard to find
So I'm sittin on a fence
(c) The Rolling Stones, 1967
![[us]](/mwf/v12/flags/us.png "United States")
1. The EGTB bug is HUGE when doing endgame analysis with Rybka.
2. You say it's up to Vas not you. But Vas is refusing to comment on this issue and you could always talk to him and ask him to respond.
Most of the other issues don't matter but the EGTB bug is huge.
And no. It's not about ELO. It's about endgame analysis. I cannot.. I repeat *simply CAN NOT* do endgame analysis with Rybka. Not the type of reliable endgame analysis that I can do with other top engines.
And Vas still refuses to respond on this issue. Why?
For the price we pay we more than deserve this fix. He definitely DOES owe it to us. That is why he doesn't respond.
2. You say it's up to Vas not you. But Vas is refusing to comment on this issue and you could always talk to him and ask him to respond.
Most of the other issues don't matter but the EGTB bug is huge.
And no. It's not about ELO. It's about endgame analysis. I cannot.. I repeat *simply CAN NOT* do endgame analysis with Rybka. Not the type of reliable endgame analysis that I can do with other top engines.
And Vas still refuses to respond on this issue. Why?
For the price we pay we more than deserve this fix. He definitely DOES owe it to us. That is why he doesn't respond.
I imagine Vas will reply once he's found out what is the cause of the problem. I know he is very backlogged now, he just moved from Hungary to Poland. My suggestion to you and others who use Rybka for endgame analysis is to simply switch to the single core version; the bug seems to be specific to MP, and Rybka 3 SP is still a stronger program than any other program using up to four cores. So you do have a version that CAN do endgame analysis by your own criteria. I agree that it would be much better to have a fix, but until we know what the cause and possible cure would be there's nothing to talk about. Who knows, it might turn out that there is some fundamental inconsistency between Rybka's MP search and EGTB, and maybe you just have to choose one or the other. I hope this is not the case though.
Sorry I wasn't precise. I do use the SP version of Rybka 3 for Endgame analysis. I just wish to use the MP version.
My problem is that I only use computer aid for endgame analysis. Therefore this makes having a quad core a waste of money for me.
My problem is that I only use computer aid for endgame analysis. Therefore this makes having a quad core a waste of money for me.
![[pl]](/mwf/v12/flags/pl.png "Poland")
I will address all of this as soon as I can. An important bug still showed up today (PH exclude moves). Please be patient :)
Vas
Vas
He Vas, no tremor! NO UPDATE FOR RYBKA 3!
It´s a point of honor! :-)
It´s a point of honor! :-)
![[ch]](/mwf/v12/flags/ch.png "Switzerland")
Dont say that !
I suspect Vasik has decided to make an update, he's just not going to say it because the board would get filled with "Is the update ready yet? Is the update ready yet?" messages.
Also, he deserves a well earned vacation ;)
Also, he deserves a well earned vacation ;)
Yes, he deserves vacations.
I am not in a hurry to receive the "fix".
Just want it minimum 10 months before Rybka 4.
regards
I am not in a hurry to receive the "fix".
Just want it minimum 10 months before Rybka 4.
regards
![[ee]](/mwf/v12/flags/ee.png "Estonia")
That is no problem, because it is always possible to postpone Rybka 4 :-)
Ok so lets say within the next 2 months
Well, end of September or early October would be fine. Maybe another one pops up till then anyway. Hey Vytron, stopped hunting or are you cooking up more evil stuff? ;-)
> Hey Vytron, stopped hunting or are you cooking up more evil stuff? ;-)
Like a formal post revealing how Persistent Hash becomes useless after a certain point because the depth needed to update the right score in a previous position would need unreasonable time to be reached? Or how only saving the main line makes Multi-PV really slow because Rybka remembers the main line but has 0 information about the side lines so the other lines have to be searched from scratch? Or how Rybka is unable to see that after a series of forced moves one learning could link to another making it a lot faster, but the user has to force the moves himself and a user that doesn't know this fact is going to sit at the root and lost a lot of resources? Or how Rybka can learn a long line of moves that lead to some score, yet when the move order is different Rybka won't notice it transposes until you force the moves yourself?
No, I'm not reporting anything else, these annoyance give me an advantage against the competition ;)
But seriously, Shredder's learning seems a lot better than persistent hash (in principle), too bad the engine is much weaker and the learning is limited.
Vytron,
just ignore posts like this.
just ignore posts like this.
Why?
I must have missread something. Never mind.
Thera are not any programs without the bugs. There are programs with undiscovered bugs, only. :-)
It is old trueth.
Rgds
Hetman
It is old trueth.
Rgds
Hetman
Where's the bug in:
main() {printf("Hello World!");getche();}
?
main() {printf("Hello World!");getche();}
?
![[au]](/mwf/v12/flags/au.png "Australia")
>Where's the bug in:
>main() {printf("Hello World!");getche();}
It depends on what the specification claims that
main is supposed to do... :-P [See "No specification => No bug ... but useless"].
I wasn't asked for a useful program, I was asked for one without bugs :) (he said "Ther[e] are not any programs without [.] bugs", which is false.)
'?' is the bug :-), it is interesting if compilation will finish without error ?
if it will not finish it is not the program ;-)
if it will not finish it is not the program ;-)
![[fi]](/mwf/v12/flags/fi.png "Finland")
It doesn't compile - most compilers won't accept K&R C at default settings. :)
And it doesn't return a value. I'm not sure, but the exit code will probably be non-zero.
And it doesn't return a value. I'm not sure, but the exit code will probably be non-zero.
I was going to mention similar things, but I figured the whole thing was pseudo-code (masquerading as real code) in the first place, and thus "it compiles" is the wrong specification to apply. :-P
But there's a bug that basically makes Persistent Hash useless for play. The endgame bugs makes people not use Rybka to analyze endgames and the Sampled Search bug scares people away from using it.
It's fine if you don't patch the bugs, I'm just asking for the reason of not fixing them.
It's fine if you don't patch the bugs, I'm just asking for the reason of not fixing them.
Persistent hash is intended mainly for analysis I think, although it would be nice if it also worked during play. I don't yet know how easy it will be to fix all the endgame problems. I didn't hear about the sampled search bug, could you point me to the relevant posting? As for the reason for not releasing a bugfix version, I don't get involved with the business aspects, I don't know for example whether this would cause problems for ChessBase and/or Convekta. I guess someone just has to make a judgment call on whether the bugs are serious enough to justify a special version.
I call it a bug because it was unexpected behavior to Vas. Sampled Search was meant to just let the user know more information about the position, in those times between one iteration and the next. However, with Sampled Search, the tree is built differently.
The change is dramatic and it's as if you were running a different engine altogether. Sometimes it finds the best moves much faster, sometimes much slower, the depth reached is very different, etc. People don't know if this affects performance and by how much, and they are waiting for a GUI update that lets the user switch it off because they're considering not using Sampled Search at all:
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=99464
The change is dramatic and it's as if you were running a different engine altogether. Sometimes it finds the best moves much faster, sometimes much slower, the depth reached is very different, etc. People don't know if this affects performance and by how much, and they are waiting for a GUI update that lets the user switch it off because they're considering not using Sampled Search at all:
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=99464
I know from experience that any tiny thing can drastically change Rybka's search. I would not suspect from this fact alone that sampled search has any measurable impact on mean playing strength.
Why do you insist on thinking that all we care about is playing strength?
Using Rybka as a reliable analysis tool is much more important to a lot of users. I don't know if that would pertain to MOST users. But it wouldn't surprise me if it did.
Lots of people can afford Rybka. Not many can afford the hardware required to use Rybka in the sense of only caring about ELO.
Using Rybka as a reliable analysis tool is much more important to a lot of users. I don't know if that would pertain to MOST users. But it wouldn't surprise me if it did.
Lots of people can afford Rybka. Not many can afford the hardware required to use Rybka in the sense of only caring about ELO.
Sorry, I don't see your point here. The complaint was that sampled search somehow hurt Rybka's play. If it changes the search but does not weaken the program, then there is also no reason to believe it hurts for analysis. In general better play and higher quality analysis go together. It's only when tradeoffs are involved (like speed for quality) that this might not be so, but surely that does not apply to this situation.
Larry and Vas,
I think that your understanding of what the severity of "bugs" (faulty software) are, is not quite on the mark,
especially from a customer perspective. There are 5 bug (fault) types: P1 = Fatal fault, P2 = Serious fault,
P3 = annoying fault, P4 = Cosmetic fault, P5 = Missing requirement or Non-working requirement.
Now granted, associating these fault types with actual faulty software is a matter of interpretation and
usually depends on who is making the judgement. A P5 bug (missing or faulty requirement implementation),
is either a P1 or P2 fault by software industry standards. I developed software for many years and found
that usually, the software developer becomes very defensive when asked to properly classify "bugs" by
themselves. Thats why in our organization, the authors of software were not allowed to classify the bugs
themselves, there were just asked to fix them in priority order of severity (P1, P2, P3 and P4, (P5=P1 or P2) by our
customer support org :) Since I suspect you don't have a customer support org (or You and Vas are), you should let
your customers (within reason) make the "bug: severity associations with faults in Rybka 3. All the bugs I have
heard about so far are P2 (Serious) bugs. Vas should do a service pack update for Rybka 3 with all P1, P2 and P3
bugs fixed in 1 to 3 months after the original release date (August 11 in my case). This is just good business practise.
I think that your understanding of what the severity of "bugs" (faulty software) are, is not quite on the mark,
especially from a customer perspective. There are 5 bug (fault) types: P1 = Fatal fault, P2 = Serious fault,
P3 = annoying fault, P4 = Cosmetic fault, P5 = Missing requirement or Non-working requirement.
Now granted, associating these fault types with actual faulty software is a matter of interpretation and
usually depends on who is making the judgement. A P5 bug (missing or faulty requirement implementation),
is either a P1 or P2 fault by software industry standards. I developed software for many years and found
that usually, the software developer becomes very defensive when asked to properly classify "bugs" by
themselves. Thats why in our organization, the authors of software were not allowed to classify the bugs
themselves, there were just asked to fix them in priority order of severity (P1, P2, P3 and P4, (P5=P1 or P2) by our
customer support org :) Since I suspect you don't have a customer support org (or You and Vas are), you should let
your customers (within reason) make the "bug: severity associations with faults in Rybka 3. All the bugs I have
heard about so far are P2 (Serious) bugs. Vas should do a service pack update for Rybka 3 with all P1, P2 and P3
bugs fixed in 1 to 3 months after the original release date (August 11 in my case). This is just good business practise.
Sounds reasonable to me.
I don't think of the bugs reported so far as "serious", but they are certainly annoying. Anyway I personally have no objection to a bug fix update.
![[ae]](/mwf/v12/flags/ae.png "United Arab Emirates")
As Larry has pointed out many of these questions can only be answered by Vas.
So, Vas, any possibility to get a direct answer? The endgame bug on MP has been reported many times before on this forum and I'm yet to see a definitive answer on this problem from the Rybka team.
Masterubu
So, Vas, any possibility to get a direct answer? The endgame bug on MP has been reported many times before on this forum and I'm yet to see a definitive answer on this problem from the Rybka team.
Masterubu
![[no]](/mwf/v12/flags/no.png "Norway")
I disagree strongly. I use Rybka for analysis and to only see the first move with no PV almost all the time is not just anoying, but almost spoils Rybka as an analysis tool. I assume that Rybka is intended to be used for analysis, espesially since a lot of effort has been made to implement many analysis functions.
Regards
anst
Regards
anst
If the PV doesn't appear is because Rybka doesn't have a PV at all to show. I'd suggest playing the moves and building a main line yourself. This must be better than getting a full PV from some other engine in where these moves are a lot weaker than Rybka's.
1
2
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill