If this "no PV" problem happens more frequently with Rybka 3, it has to be addressed because I think it is correct what Anst means in his posting above, about analysis and PV display. It is a normal state of the art feature. As is a correct node rate display and a correct depth display. Any average Joe engine is capable of doing it. An exception may be made for experimental or very minimalistic engines, not for major commercial products.
(Don't tell me an engine would be weaker just because infos are correctly displayed.)
It gets annoying that Rybka, just because her superiour strength, seems to cause the computer chess community to start abandoning self-evident quality requirements. As long as several top engines were within a 50 Elo range, nobody would have tolerated such nonsense. Let's not "throw overboard" fundamental quality aspects please.
This is not correct to assume that it is obvious that the true PV must always exist internally.
As a programmer I know that it is simply not correct.
Uri
In most cases rybka shows pv and there are cases when
Rybka probably has no pv except the first move so she cannot show something that she does not have.
Here is an example under Fritz8 gui
There are cases when Rybka shows single move but it does not happen most of the time
and even when it happens if you wait enough time you can see pv of more than one move.
If you cannot wait more time you probably can generate some pv by making the move and give rybka to analyze again.
Analysis by Rybka 3 1-cpu 32-bit :
1.Qd2
= (-0.14) Depth: 2 00:00:00
1.Qd2
= (-0.11) Depth: 3 00:00:00
1.Qd2
= (-0.17) Depth: 4 00:00:00
1.Qd2 Qh5
= (-0.17) Depth: 5 00:00:00
1.Qd4
= (0.03) Depth: 6 00:00:00 14kN
1.Qd4
= (0.23) Depth: 6 00:00:00 15kN
1.Qd4 Nd3 2.Bxd3
= (0.16) Depth: 6 00:00:01 19kN
1.Qd4 Nd3 2.Bxd3 cxd3 3.Rxd3 h5
³ (-0.35) Depth: 7 00:00:01 34kN
1.Qd4 Nd3 2.Nxh6 Nxb2 3.Qxb2 Qd7 4.Ng4 Rae8 5.Rf3 Qc7
³ (-0.32) Depth: 8 00:00:03 71kN
1.Nxh6
= (-0.12) Depth: 9 00:00:07 165kN
1.Nxh6 c3 2.Nf7+
= (0.00) Depth: 9 00:00:07 172kN
1.Nxh6 c3 2.Nf7+ Qxf7 3.Ng5 Rxe1+
³ (-0.38) Depth: 10 00:00:17 452kN
1.Nxh6
= (-0.18) Depth: 11 00:00:22 560kN
1.Nxh6 c3 2.Nf7+ Qxf7 3.Ng5 Rxe1+ 4.Qxe1 Qe7 5.Qd1 Nf4 6.Rg4 Kg8 7.Bh7+ Kh8 8.Bb1 Kg8 9.Bh7+ Kh8 10.Bb1 Kg8 11.Bh7+ Kh8 12.Bb1 Kg8 13.Bh7+ Kh8 14.Bb1 Kg8 15.Bh7+ Kh8 16.Bb1
= (0.00) Depth: 11 00:00:29 686kN
1.Nxh6 c3 2.Nf7+ Qxf7 3.Ng5 Rxe1+ 4.Qxe1 Qe7 5.Qd1 Nf4 6.Rg4 Kg8 7.Bh7+ Kh8 8.Bb1 Kg8 9.Bh7+ Kh8 10.Bb1 Kg8 11.Bh7+ Kh8 12.Bb1 Kg8 13.Bh7+ Kh8 14.Bb1 Kg8 15.Bh7+ Kh8 16.Bb1
= (0.00) Depth: 12 00:00:37 902kN
1.Nxh6 c3 2.Nf7+ Qxf7 3.Ng5 Rxe1+ 4.Qxe1 Qe7 5.Qd1 Nf4 6.Rg4 Kg8 7.Bh7+ Kh8 8.Bb1 Kg8 9.Bh7+ Kh8 10.Bb1 Kg8 11.Bh7+ Kh8 12.Bb1 Kg8 13.Bh7+ Kh8 14.Bb1 Kg8 15.Bh7+ Kh8 16.Bb1
= (0.00) Depth: 13 00:01:11 1621kN
1.Nxh6 c3 2.Nf7+ Qxf7 3.Ng5 Rxe1+ 4.Qxe1 Qe7 5.Qd1 Nf4 6.Rg4 Kg8 7.Bh7+ Kh8 8.Bb1 Kg8 9.Bh7+ Kh8 10.Bb1 Kg8 11.Bh7+ Kh8 12.Bb1 Kg8 13.Bh7+ Kh8 14.Bb1 Kg8 15.Bh7+ Kh8 16.Bb1
= (0.00) Depth: 14 00:02:31 3288kN
1.Nxh6 c3 2.Nf7+ Qxf7 3.Ng5 Rxe1+ 4.Qxe1 Qe8 5.Qxe8 Rxe8 6.Nf7+ Kg8 7.Nh6+ Kh8 8.Nf7+ Kg8 9.Nh6+ Kh8 10.Nf7+ Kg8 11.Nh6+ Kh8 12.Nf7+ Kg8 13.Nh6+ Kh8 14.Nf7+ Kg8 15.Nh6+ Kh8 16.Nf7+
= (0.00) Depth: 15 00:05:25 7414kN
1.Nxh6 c3 2.Nf7+ Qxf7 3.Ng5 Rxe1+ 4.Qxe1 Qe8 5.Qxe8 Rxe8 6.Nf7+ Kg8 7.Nh6+ Kh8 8.Nf7+ Kg8 9.Nh6+ Kh8 10.Nf7+ Kg8 11.Nh6+ Kh8 12.Nf7+ Kg8 13.Nh6+ Kh8 14.Nf7+ Kg8 15.Nh6+ Kh8 16.Nf7+
= (0.00) Depth: 16 00:11:35 14815kN
1.Nxh6
= (0.20) Depth: 17 00:29:05 36302kN
1.Nxh6
² (0.40) Depth: 17 00:41:45 46592kN
1.Nxh6 c3 2.Kh2 Rxh6 3.Nxc3 Qh5 4.Qd4 Qf7 5.Ne4 Nc6 6.Ng5 Qg8 7.Qd2 Ne5 8.Ba2 Rc8 9.Rd1 Rh4 10.Bxd5 Bxd5 11.Qxd5 Qxd5 12.Rxd5 Rxa4 13.Bd4
² (0.68) Depth: 17 00:53:53 61654kN
1.Nxh6
± (0.88) Depth: 18 01:42:31 125280kN
1.Nxh6
± (1.08) Depth: 18 02:29:09 182429kN
1.Nxh6
+- (1.48) Depth: 18 03:42:01 274329kN
1.Nxh6
+- (2.28) Depth: 18 06:32:18 531613kN
1.Nxh6 Rxh6 2.Nxd6
+- (2.20) Depth: 18 09:31:41 825301kN
1.Nxh6 Rxh6 2.Nxd6 Qh5 3.Rg5 Qxd1 4.Nf7+ Kg8 5.Nxh6+ Kh8 6.Rxd1 c3 7.Nf7+ Kg8 8.Bg6 Nf4 9.Bxc3 Nbd5 10.Rb1 Bc6 11.Bd2 Nxg6 12.Rxg6 Ne7 13.Nh6+ Kh7 14.Rxc6 Nxc6 15.Nf7 Kg6 16.Ng5
+- (2.29) Depth: 19 11:28:04 1021640kN
1.Nxh6 Rxh6 2.Nxd6 Qh5 3.Rg5 Qxd1 4.Nf7+ Kg8 5.Nxh6+ Kh8 6.Rxd1 c3 7.Nf7+ Kg8 8.Bg6 Nf4 9.Bxc3 Nbd5 10.Rb1 Bc6 11.Bd2 Nxg6 12.Rxg6 Ne7 13.Nh6+ Kh7 14.Rxc6 Nxc6 15.Nf7 Kg6 16.Ng5
+- (2.29) Depth: 20 15:31:04 1416780kN
(Uri, MyTown 21.08.2008)
Uri
There are cases though where Rybka should display a longer PV than she does.
Vas
Small pv in this case is ok but I prefer at least a pv of 2 or 3 plies.
Uri
You could for example use the PV (or fail-high) move from lower depths, but the problem is that this is exactly the move we have just refuted.
Vas
Regards,
Alan
Vas
I can't see one single reason why there shouldn't be one.
Anyway, every bug that affects analysis should be taken seriously, especially if Rybka is considered as an analysing programme.
Bugs that reduce e.g. the Rybka Elo by two points are in my view less important. I would rather consider them as weaknesses of Rybka instead of bugs (e.g. bugs related to endgames).
The point is, in my opinion the PH bug should have highest priority among the known Rybka bugs.
The other problem is that people may not publish and merge persistent hash files because any malicious person can create damaged hashes to mess with people that will merge with them.
I would not merge any files of unknown origin and quality into my data.
Anyway, let's hope, that the bug will be fixed on Rybkas 4 edition!
> Analyse Moves ... is more useful than Ignore Moves ..
They're the same thing by definition...
>Let's hope it will be fixed in Rybka 4.
Let's hope it will be fixed in Rybka 3.01 ;)
> If you ignore best moves, then you can not get the best result.
The point is to get an exact score for another move. If a score for the best move has already been established, Multi-PV is needlessly inefficient.
All those problems are still only annoying bugs (class P3), nothing serious. I hope Rybka 4 will work exactly as you are expecting.
> For this purpose the Analyse Moves... is good enough.
See my reply to your other post.
>PH is not necessary for this task.
Define "this task". All analysis, for me.
>> See my reply to your other post.
>
Do you mean this: "They're the same thing by definition... "? Under Shredder GUI there are two options, include a move for analysis or exlude a move. Of course you can achieve similar results if excluding all moves except those you need to include, or on the contrary, if including all moves except those you need to exclude. But usually it is much easier to select some moves for analysis than exclude all legal moves that are obviously not perspective.
This task= to get an exact score for another move
In my opinion the persistent hash bug is a serious bug, because it affects analysis, too. It is common that one chooses critical positions for the engine to play them out (Rybka vs Rybka). Now with the PH bug, one has to disable PH during the engine match with the effect that Rybka will not remember its "thoughts" from the engine match later in analysis mode.
If the best engine is more than 100 elo better than the opponents then it is the best for analysis
even if it shows only a single move in the pv all the time.
Analyzing is about finding the best moves and the most important thing is to have correct moves.
Not having pv is something that can be corrected by analyzing more positions but I see no way to correct not seeing the right moves.
Uri
It is true that Rybka team always has said that no updates would be available until R4, but IMHO, although none of the bugs and issues reported could be considered as major bugs or fatal errors, some of these bugs may have easy solutions even they can be fixed in a short period of time (say september when the GM match is performed).
I am not claiming for a FREE update buggy free, but I am convinced that customers (who have PAID, by the way) deserve an update whitout some of the annoying issues already found, specially if they can be fixed in a short period.
Best regards
Uri
chess program, but it is not living up to its "high" expectations from a software quality standpoint. It has "serious"
defects as I described above. Vas and Larry are in the software business. This is no longer a hobby. That ended
when they made an agreement with Chessbase to distribute their software. It has to perform as asvertised "period",
or customers can and will go elsewhere. I also stated in a much earlier post they will not be on top forever. Look
at history. As soon as the next top program comes along, lets see how many people visit this site or buy Rybka.
is not valid when talking about quality software. R3 does not meet its expectations from a software quality and
advertized features point of view. Customers (including myself) paid for what the software was advertized to do
and it does not, no matter how strong it is. I even bought the separate book (which is ridiculous) believing I was
getting the best product for my money. But thats not the issue. The issue is that the authors of this program Rybka
are saying that they dont care that they just sold you a product with serious defects/faults/"bugs" and missing
functionality and will not do anything about it until R4 (a full year or more from now) which is absolutely ridiculous.
I dont care if Rybka 4 makes 4000 ELO, I wont buy it if there is no customer support and if promised features
and "bugs" are not fixed after release.
Maybe I have missed something but what was the promised feature that does not function at all?
Anyway, I suggest Vas to revise pricing policy for release 4, if customers are not satisfied with the price/performance ratio of R3. I think Rybka 3 has very good price/performance ratio from customers viewpoint. Too good! From developers viewpoint it is clearly underpriced product.
Of course you are free to buy what you want and if Rybka does not meet your needs, you are free to choose another product. I wonder, what product it might be.
Let's say you bought a brand new Lambourgini sports car. You are elated because your new Lambourgini
can reach 60 MPH in 3.4 seconds! It gets to 60 MPH faster than any other car you can buy. But then,
when you are driving your "little baby" on the Auto-Bann, as fast as you can, you discover that the
air conditioning doesn't work. You paid $350,000 dollars for this magnificent machine. (:
Well now, are you a happy camper? While your fast car is smothering you to death while you roast
in your most fast car? :) LOL, You can have your fast car but the price does not justify it's "serious"
defects (Bugs/faults/P1,P2,P3,P4,P5's) :)
> And another thing: during these discussions over the last few days people complaining about
> the bugs, demanding a bix fix were often told "Why do you complain? You got an engine that
> is 200 ELO stronger than everything else." This is not a valid argument. If I buy a fast sports
> car and the AC does not work, I do not want to hear "What do you complain about? You got
> a car that is much faster than all others." I just expect them to fix the AC.
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=93790;hl=
In this case, I wouldn't buy either of them.
I read a very brief response from Vas today about being "patient". I'm not sure how I should interpret
that. Does that mean he is going to make a "bug fix" release or not? I think he is definately thinking
about it, but dowsn't want to commit to in spite of all the clamour from his customers about getting a
"BUG FIX" Relases.
> 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
I strongly disagree! Persistant hash is one of the key features of R3. It does not work in play mode. EGTB interaction is very important for me, it does not work. If Vas does not issue a bugix for at least these two bugs, I will not buy R4.
> Regarding the EGTB/MP interaction bug, it is my understanding that it was present in 2.3.2a mp, and that nobody reported it for the entire year between then and R3. Please correct me if I am wrong. If this is true, it hardly qualifies as a bug that clearly needs to be fixed, although I agree that it should be fixed if there is a bugfix version.
Please refer to this post from July 2007 entitled "Still problems with 2.3.2a mp version and tablebases"
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=20369;hl=tablebase
Relevant quote from the OP :
"Unfortunately, with the multiprocessor version, things look rather strange "
Relevant quote from Vas:
"Thanks. It's strange, I will have a look."
Analysis from my system :
Rybka 3 mp with 6 man EGTBs
1.Kf4 h6 2.Ke5 h5 3.gxh5 gxh5 4.Kf5 Kd6 5.Kg5 Ke6 6.f4 a6 7.f5+ Kf7 8.Kxh5 Kf6 9.Kg4 a5 10.a4
+- (3.20) Depth: 21 00:00:05 276kN, tb=94
1.Kf4 h6 2.Ke5 h5 3.gxh5 gxh5 4.Kf5 Kd6 5.Kg5 Ke6 6.f4 a6 7.f5+ Kf7 8.Kxh5 Kf6 9.Kg4 a5 10.a4
+- (3.20) Depth: 22 00:00:06 334kN, tb=119
1.Kf4 h6 2.Ke5 h5 3.gxh5 gxh5 4.Kf5 Kd6 5.Kg5 Ke6 6.f4 a6 7.f5+ Kf7 8.Kxh5 Kf6 9.Kg4 a5 10.a4
+- (3.20) Depth: 23 00:00:08 396kN, tb=157
Rybka 3 sp (max CPUS=1) with 6 man EGTBs
1.Kf4 h6 2.Ke5 h5 3.Kf4 h4 4.g5 Kd6 5.Kg4 Ke5 6.f4+ Ke4 7.f5 h3 8.fxg6 h2 9.g7 h1Q 10.g8Q Qf3+ 11.Kh4 Qh1+ 12.Kg3 Qf3+ 13.Kh4 Qh1+ 14.Kg3 Qf3+ 15.Kh4 Qh1+ 16.Kg3
= (0.00) Depth: 19 00:00:14 453kN, tb=1618
1.Kf4 h6 2.Ke5 h5 3.Kf4 h4 4.g5 Kd6 5.Kg4 Ke5 6.f4+ Ke4 7.f5 h3 8.fxg6 h2 9.g7 h1Q 10.g8Q Qf3+ 11.Kh4 Qh1+ 12.Kg3 Qf3+ 13.Kh4 Qh1+ 14.Kg3 Qf3+ 15.Kh4 Qh1+ 16.Kg3
= (0.00) Depth: 20 00:00:20 607kN, tb=2663
1.Kf4 h6 2.Ke5 h5 3.Kf4 h4 4.g5 Kd6 5.Kg4 Ke5 6.f4+ Ke4 7.f5 h3 8.fxg6 h2 9.g7 h1Q 10.g8Q Qf3+ 11.Kh4 Qh1+ 12.Kg3 Qf3+ 13.Kh4 Qh1+ 14.Kg3 Qf3+ 15.Kh4 Qh1+ 16.Kg3
= (0.00) Depth: 21 00:00:29 880kN, tb=4074
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill