1
2

Summary of the Rybka EGTB mp bug

--------------------------------------------------

1. The bug consists of inaccurate evaluations, seemingly ignoring some EGTB positions

2. It exists in Rybka 3 mp and Rybka 2.3.2a mp during the search of endgame positions with access to EGTB's

3. It does not affect Rybka sp or Rybka mp with maxCPUs set to 1

4. In the examples listed below, there always seems to be an

an

5. Changing the Nalimov usage parameter to "frequently" or "normally" did not help

6. Workarounds :

a. Use maxCPUs=1

b. Don't use EGTB's

c. Use another engine. I ran an endgame tournament months ago that was won by Zappa Mexico.

http://www.talkchess.com/forum/viewtopic.php?t=20906&highlight=

Quote from Vas ....

"Ok, it seems that there is some sort of sporadic bug in the interaction between the tablebase probing, hash table and multi-processor implementation. In some cases, a normal Rybka eval + search seems to be used instead. I'll dig into it when I have a chance."

http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=85730

My system is a quad QX6700, Vista Ultimate x64, 4g Ram, Nalimov Usage rarely, 1gb hash

With 5 man EGTB's ...

1.Re5 Ra6 2.e4 Ra1 3.Rf5+ Ke6 4.Kc4 Ra4+ 5.Kd3 Ra3+ 6.Ke2 Ra4 7.Kf3 Ra1 8.Rc5

+- (2.61) Depth: 22 00:00:17 3033kN, tb=5269

1.Re5 Rc6 2.e4 Rc1

+- (2.61) Depth: 23 00:00:22 4051kN, tb=7855

Re5 throws away the win since 1. Re5 Rxe5 2. fxe5+ Kxe5 is a simple draw

1.Rd3 Kf5 2.Kc4 Re4+ 3.Kc3 Kg4 4.Kd2 Kf3 5.f5 Re5 6.f6 Rf5 7.Rd6 Ke4 8.Re6+ Kd5 9.Ra6 Ke4 10.Rb6 Rf2+

+- (1.84) Depth: 22 00:00:42 2825kN, tb=20208

1.Rd3 Kf5 2.Kc4 Re4+ 3.Kc3 Kg4 4.Kd2 Kf3 5.f5 Re5 6.f6 Rf5 7.Rd6 Ke4 8.Re6+ Kd5 9.Ra6 Ke4 10.Rb6 Rf2+

+- (1.84) Depth: 23 00:00:53 3619kN, tb=29236

With 6 man EGTB's including KRp v KRp ...

1.Rg4 Rxg4 2.fxg4 Kf7 3.Ke4 Kxg7 4.Kxe5 Kg6 5.Kf4 Kf6 6.g5+ Kg7 7.Kf5 Kf7 8.Kg4 Kg6

+- (2.93) Depth: 30 00:00:31 3185kN, tb=3007

1.Rg4 Rxg4 2.fxg4 Kf7 3.Ke4 Kxg7 4.Kxe5 Kg6 5.Kf4 Kf6 6.g5+ Kg7 7.Kf5 Kf7 8.Kg4 Kg6

+- (2.93) Depth: 31 00:00:42 4436kN, tb=4428

Rg4 leads to a draw after 1.Rg4 Rxg4 2.fxg4 Kf7

1.Ke4 Re2+ 2.Kd3 Rg2 3.Ra6+ Kf5 4.Ra7 Kf6

= (0.00) Depth: 25 00:00:45 5564kN, tb=15794

1.Ke4 Re2+ 2.Kd3 Rg2 3.Ra6+ Kf5 4.Ra7 Kf6

= (0.00) Depth: 26 00:00:55 6731kN, tb=21230

With 6 man EGTB's ...

1.Rd7+ Rxd7 2.e6+ Ke8 3.exd7+ Kxd7 4.Kf6 Ke8 5.Kg7 h5 6.h4 Ke7 7.Kg6 Kf8 8.Kxh5 Kg7 9.Kg5 Kh7 10.h5 Kg7 11.Kg4 Kh6 12.Kh4 Kh7 13.Kg3 Kg7 14.Kf3 Kh6 15.Kg4 Kh7 16.Kh3

+- (2.68) Depth: 28 00:00:19 1295kN, tb=811

1.Rd7+ Rxd7 2.e6+ Ke8 3.exd7+ Kxd7 4.Kf6 Ke8 5.Kg7 h5 6.h4 Ke7 7.Kg6 Kf8 8.Kxh5 Kg7 9.Kg5 Kh7 10.h5 Kg7 11.Kg4 Kh6 12.Kh4 Kh7 13.Kg3 Kg7 14.Kf3 Kh6 15.Kg4 Kh7 16.Kh3

+- (2.68) Depth: 29 00:00:19 1295kN, tb=811

After 1.Rd7+ Rxd7 2.e6+ Ke8 3.exd7+ Kxd7 is a dead draw

1.Rd8 Kg7 2.h4 h5 3.Rb8 Rc7 4.Rb6 Rc3 5.Rb7+ Kh6 6.e6 Rf3+ 7.Ke4 Rf2 8.Rb8 Re2+ 9.Kf5 Kg7 10.Rb7+ Kh6 11.Kf6

+- (2.07) Depth: 19 00:00:15 1102kN, tb=6428

1.Rd8 Kg7 2.h4 h5 3.Rb8 Rc7 4.Rb6 Rc3 5.Rb7+ Kh6 6.e6 Rf3+ 7.Ke4 Rf2 8.Rb8 Re2+ 9.Kf5 Kg7 10.Rd8 Re3 11.Rc8 Re1 12.Rc7+ Kf8 13.Kf6

+- (2.07) Depth: 20 00:00:20 1409kN, tb=9371

With 6 man EGTB's including KR v Kppp

1.Qd7 Kh2 2.Qd6+ Kh1 3.Qd5 Kh2 4.Qe5+ Kh1 5.Qe4 Kh2 6.Qe2 Kh1 7.Qg4 Kh2

+- (4.44) Depth: 18 00:00:20 6828kN, tb=213

1.Qd7

+- (4.64) Depth: 19 00:00:22 7171kN, tb=265

Qd7 may still lead to a win but after Qc1+ or Qd1+ or Qe1+ white can let the black pawn promote and then exchange queens with a tablebase win.

1.Qe1+

+- (#48) Depth: 17 00:00:28 6666kN, tb=425

1.Qe1+

+- (#48) Depth: 18 00:00:38 9215kN, tb=706

--------------------------------------------------

1. The bug consists of inaccurate evaluations, seemingly ignoring some EGTB positions

2. It exists in Rybka 3 mp and Rybka 2.3.2a mp during the search of endgame positions with access to EGTB's

3. It does not affect Rybka sp or Rybka mp with maxCPUs set to 1

4. In the examples listed below, there always seems to be an

*exchange of material*in the search oran

*exchange of material*in what should be a clear winning or drawn variation, leading to an EGTB position.5. Changing the Nalimov usage parameter to "frequently" or "normally" did not help

6. Workarounds :

a. Use maxCPUs=1

b. Don't use EGTB's

c. Use another engine. I ran an endgame tournament months ago that was won by Zappa Mexico.

http://www.talkchess.com/forum/viewtopic.php?t=20906&highlight=

Quote from Vas ....

"Ok, it seems that there is some sort of sporadic bug in the interaction between the tablebase probing, hash table and multi-processor implementation. In some cases, a normal Rybka eval + search seems to be used instead. I'll dig into it when I have a chance."

http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=85730

My system is a quad QX6700, Vista Ultimate x64, 4g Ram, Nalimov Usage rarely, 1gb hash

**Example 1**8/8/4rk2/3R4/5P2/1K2P3/8/8 w - -

With 5 man EGTB's ...

*Rybka 3 bad analysis :*1.Re5 Ra6 2.e4 Ra1 3.Rf5+ Ke6 4.Kc4 Ra4+ 5.Kd3 Ra3+ 6.Ke2 Ra4 7.Kf3 Ra1 8.Rc5

+- (2.61) Depth: 22 00:00:17 3033kN, tb=5269

1.Re5 Rc6 2.e4 Rc1

+- (2.61) Depth: 23 00:00:22 4051kN, tb=7855

Re5 throws away the win since 1. Re5 Rxe5 2. fxe5+ Kxe5 is a simple draw

*Rybka 3 with maxCPUs set to 1 :*1.Rd3 Kf5 2.Kc4 Re4+ 3.Kc3 Kg4 4.Kd2 Kf3 5.f5 Re5 6.f6 Rf5 7.Rd6 Ke4 8.Re6+ Kd5 9.Ra6 Ke4 10.Rb6 Rf2+

+- (1.84) Depth: 22 00:00:42 2825kN, tb=20208

1.Rd3 Kf5 2.Kc4 Re4+ 3.Kc3 Kg4 4.Kd2 Kf3 5.f5 Re5 6.f6 Rf5 7.Rd6 Ke4 8.Re6+ Kd5 9.Ra6 Ke4 10.Rb6 Rf2+

+- (1.84) Depth: 23 00:00:53 3619kN, tb=29236

**Example 2**8/6P1/4k3/4p3/R7/4KP2/6r1/8 w - -

With 6 man EGTB's including KRp v KRp ...

*Rybka 3 bad analysis :*1.Rg4 Rxg4 2.fxg4 Kf7 3.Ke4 Kxg7 4.Kxe5 Kg6 5.Kf4 Kf6 6.g5+ Kg7 7.Kf5 Kf7 8.Kg4 Kg6

+- (2.93) Depth: 30 00:00:31 3185kN, tb=3007

1.Rg4 Rxg4 2.fxg4 Kf7 3.Ke4 Kxg7 4.Kxe5 Kg6 5.Kf4 Kf6 6.g5+ Kg7 7.Kf5 Kf7 8.Kg4 Kg6

+- (2.93) Depth: 31 00:00:42 4436kN, tb=4428

Rg4 leads to a draw after 1.Rg4 Rxg4 2.fxg4 Kf7

*Rybka 3 with maxCPUs set to 1 :*1.Ke4 Re2+ 2.Kd3 Rg2 3.Ra6+ Kf5 4.Ra7 Kf6

= (0.00) Depth: 25 00:00:45 5564kN, tb=15794

1.Ke4 Re2+ 2.Kd3 Rg2 3.Ra6+ Kf5 4.Ra7 Kf6

= (0.00) Depth: 26 00:00:55 6731kN, tb=21230

**Example 3**8/r4k1p/8/4PK2/8/3R3P/8/8 w - -

With 6 man EGTB's ...

*Rybka 3 bad analysis :*1.Rd7+ Rxd7 2.e6+ Ke8 3.exd7+ Kxd7 4.Kf6 Ke8 5.Kg7 h5 6.h4 Ke7 7.Kg6 Kf8 8.Kxh5 Kg7 9.Kg5 Kh7 10.h5 Kg7 11.Kg4 Kh6 12.Kh4 Kh7 13.Kg3 Kg7 14.Kf3 Kh6 15.Kg4 Kh7 16.Kh3

+- (2.68) Depth: 28 00:00:19 1295kN, tb=811

1.Rd7+ Rxd7 2.e6+ Ke8 3.exd7+ Kxd7 4.Kf6 Ke8 5.Kg7 h5 6.h4 Ke7 7.Kg6 Kf8 8.Kxh5 Kg7 9.Kg5 Kh7 10.h5 Kg7 11.Kg4 Kh6 12.Kh4 Kh7 13.Kg3 Kg7 14.Kf3 Kh6 15.Kg4 Kh7 16.Kh3

+- (2.68) Depth: 29 00:00:19 1295kN, tb=811

After 1.Rd7+ Rxd7 2.e6+ Ke8 3.exd7+ Kxd7 is a dead draw

*Rybka 3 with maxCPUs set to 1 :*1.Rd8 Kg7 2.h4 h5 3.Rb8 Rc7 4.Rb6 Rc3 5.Rb7+ Kh6 6.e6 Rf3+ 7.Ke4 Rf2 8.Rb8 Re2+ 9.Kf5 Kg7 10.Rb7+ Kh6 11.Kf6

+- (2.07) Depth: 19 00:00:15 1102kN, tb=6428

1.Rd8 Kg7 2.h4 h5 3.Rb8 Rc7 4.Rb6 Rc3 5.Rb7+ Kh6 6.e6 Rf3+ 7.Ke4 Rf2 8.Rb8 Re2+ 9.Kf5 Kg7 10.Rd8 Re3 11.Rc8 Re1 12.Rc7+ Kf8 13.Kf6

+- (2.07) Depth: 20 00:00:20 1409kN, tb=9371

**Example 4**8/8/8/1P6/8/P6r/1KPQ2p1/7k w - -

With 6 man EGTB's including KR v Kppp

*Rybka 3 bad analysis :*1.Qd7 Kh2 2.Qd6+ Kh1 3.Qd5 Kh2 4.Qe5+ Kh1 5.Qe4 Kh2 6.Qe2 Kh1 7.Qg4 Kh2

+- (4.44) Depth: 18 00:00:20 6828kN, tb=213

1.Qd7

+- (4.64) Depth: 19 00:00:22 7171kN, tb=265

Qd7 may still lead to a win but after Qc1+ or Qd1+ or Qe1+ white can let the black pawn promote and then exchange queens with a tablebase win.

*Rybka 3 with maxCPUs set to 1 :*1.Qe1+

+- (#48) Depth: 17 00:00:28 6666kN, tb=425

1.Qe1+

+- (#48) Depth: 18 00:00:38 9215kN, tb=706

*1. The bug consists of inaccurate evaluations, seemingly ignoring some EGTB positions*

You can see it in your analysis. Single core has much more tbs hits than mp version in the same time (+- (2.61) Depth: 23 00:00:22 4051kN,

**tb=7855**).

*6. Workarounds :*

a. Use maxCPUs=1

b. Don't use EGTB's

a. Use maxCPUs=1

b. Don't use EGTB's

My Workaround:

a. Use maxCPUs=2048

b. Use only 3-4 EGTB's

Remarks: If you don´t use EGTB´s, Rybka 3 plays all the bad moves like Re5, Rg4, Rd7 in example 1-3. I tested your examples and all was fine with my workaround; no bad moves :-). Okay, in example 4 she don´t find Qe1 (only Qd5 with +5).

>

6. Workarounds :

> a. Use maxCPUs=1

> b. Don't use EGTB's

>

> My Workaround:

> a. Use maxCPUs=2048

> b. Use only 3-4 EGTB's

>

Those suggestions were made "tongue in cheek" . As someone who has a quad core and 160gb of 6 man EGTB's, I will not use workaround a) or b) or those you suggested . :) :)

Zappa II Mexico, Deep Sjeng, Hiarcs are not too bad for endgames

Thanks to those posting in this thread - I was keen to read a summary of this issue.

If I've understood correctly, I now intend to run R3 MP using all 4 cores but only using 3&4 man EGTBs. This should give reliable analysis (in terms of avoiding issues), but obviously compromises the EGTBs available to R3. I'm guessing the increased reliability outweighs the small drop in strength due to less EGTBs.

If I've understood correctly, I now intend to run R3 MP using all 4 cores but only using 3&4 man EGTBs. This should give reliable analysis (in terms of avoiding issues), but obviously compromises the EGTBs available to R3. I'm guessing the increased reliability outweighs the small drop in strength due to less EGTBs.

Okay, you have the choice. :-)

Select 50 endgame positions and then make 100 game matches with

R3 x64 4CPU 3-4 tbs vs. Zappa x64 4CPU 3-4-5-6 tbs or

R3 x64 4CPU 3-4 tbs vs. R3 x64 4CPU 3-4-5-6 tbs

to see who is best.

My bet is on R3 with 3-4 tbs! :-)

Select 50 endgame positions and then make 100 game matches with

R3 x64 4CPU 3-4 tbs vs. Zappa x64 4CPU 3-4-5-6 tbs or

R3 x64 4CPU 3-4 tbs vs. R3 x64 4CPU 3-4-5-6 tbs

to see who is best.

My bet is on R3 with 3-4 tbs! :-)

What's good with 6-men base when you can't use mp version with it?

What's good with mp version when you can't use 6 men base with it?

What's good with mp version when you can't use 6 men base with it?

>What's good with 6-men base when you can't use mp version with it?

>What's good with mp version when you can't use 6 men base with it?

Is the mechanism of this bug known yet? Has it been properly distinguished from hash-table collisions, for instance? I'll try to reproduce it this evening.

On top of the lack of wrong-color-RP and other previously-included endgame knowledge, plus some bugs with persistent hash which I'm not sure can be averted for analysis, this is very disappointing for my intent to gear up with Rybka 3 + persistent hash + 6-piece EGTs and finally finish my huge Kramnik-Grischuk analysis.

Your "workaround" about 3-4 EGTB's is not correct.

> My Workaround:

> a. Use maxCPUs=2048

> b. Use only 3-4 EGTB's

Some explanation, please! :-)

Show me the example, where 3-4 EGTB´s on 2-4-8-16 cores failed like Rybka with no EGTB´s.

Show me the example, where 3-4 EGTB´s on 2-4-8-16 cores failed like Rybka with no EGTB´s.

Did you try it with the positions shown by the topic starter? I did and it didn't "solve" the problem. The nature of the problem isn't solved by using only 3-4 piece Nalimov.

But then again I know you like to provoke. http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=79350

But then again I know you like to provoke. http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=79350

Provoking is fine but not here; it´s a sincere problem!

I wrote it in a post above. I tested all 4 positions with 3-4 EGTB on my 2CPU notebook more than 10 minutes. And all was fine. Tb count in analysis was also fine (in comparison to sp version). One or two days ago I think I have to write down here the problem of the EGTB bug in Rybka. But I was to lazy. And then bnc does it in a very good way. When I looked to his analysis, I see immediately the problem. Sp version has much more tb hits than mp version. This is decisive (please have a look to the origin post of bnc and his engine analysis)! When I recognized it, I was sure. After more than an hour of own testing with 3-4 EGTB´s I had the proof (for me!). Vas mentioned it in a post. With 5 or 6 EGTB´s Rybka mp plays after some time without tbs. But I was sure, with 3-4 EGTB´s this can´t happen. And most basic for Rybka mp; she can´t play without 3-4 EGTB´s.

So, my configuration is very poor. I wish, that anyone with 8 core machines test my hypothesis. He/she can test it on the four positions (here I´m sure), then he can make own positions and very last he has to make matches to see the significance! My favourite tester would be Kullberg. Rybka 3 mp in tournament configuration (with 3-4-5-6 EGTB on 64 (128?) GB fastest SSD drives (0.1 ms access time) vs 3-4 EGTB on hard drive (~ 200 games).

If 3-4 EGTB configuration wins, I´m right. If not I´m asking for a match with no EGTB vs 3-4 EGTB. If here isn´t a gap from more than 30 Elo, I lost totally. But I can´t imagine. :-)

I wrote it in a post above. I tested all 4 positions with 3-4 EGTB on my 2CPU notebook more than 10 minutes. And all was fine. Tb count in analysis was also fine (in comparison to sp version). One or two days ago I think I have to write down here the problem of the EGTB bug in Rybka. But I was to lazy. And then bnc does it in a very good way. When I looked to his analysis, I see immediately the problem. Sp version has much more tb hits than mp version. This is decisive (please have a look to the origin post of bnc and his engine analysis)! When I recognized it, I was sure. After more than an hour of own testing with 3-4 EGTB´s I had the proof (for me!). Vas mentioned it in a post. With 5 or 6 EGTB´s Rybka mp plays after some time without tbs. But I was sure, with 3-4 EGTB´s this can´t happen. And most basic for Rybka mp; she can´t play without 3-4 EGTB´s.

So, my configuration is very poor. I wish, that anyone with 8 core machines test my hypothesis. He/she can test it on the four positions (here I´m sure), then he can make own positions and very last he has to make matches to see the significance! My favourite tester would be Kullberg. Rybka 3 mp in tournament configuration (with 3-4-5-6 EGTB on 64 (128?) GB fastest SSD drives (0.1 ms access time) vs 3-4 EGTB on hard drive (~ 200 games).

If 3-4 EGTB configuration wins, I´m right. If not I´m asking for a match with no EGTB vs 3-4 EGTB. If here isn´t a gap from more than 30 Elo, I lost totally. But I can´t imagine. :-)

This bug is there in every gui but one.

When I played the position (5 man position) in Aquarium the bug was gone. Rybka 3 played the correct move.

Mark Y.

When I played the position (5 man position) in Aquarium the bug was gone. Rybka 3 played the correct move.

Mark Y.

Wow :)

So, there is some another workaround present :)

Of course, this needs further investigation since Aquarium doesn't do any magic tricks to Rybka.

So, there is some another workaround present :)

Of course, this needs further investigation since Aquarium doesn't do any magic tricks to Rybka.

>Of course, this needs further investigation since Aquarium doesn't do any magic tricks to Rybka.

With the exception of sampled search. :)

That's right. I'm not very good at chess engine writing, so I wonder whether sampled search can affect the MP EGTB access issue?..

It shouldn't (and I can't imagine how it could). But then again, it shouldn't change the tree, either. :)

Aquarium maybe not - but IDeA at times does... ;-)

I´m sure Aquarium will solve the blind bishop problem too. :-)

Hm.... Maybe they could do something with the hash bug? :-)

No problem! Aquarium solves every problem you have. :-)

Make a list and send it to Zruty.

Make a list and send it to Zruty.

Yes, but send the list by regular mail. And put something in the envelope for me to smile at.

Euros for preference, in our unstable world :)

Euros for preference, in our unstable world :)

> This bug is there in every gui but one.

>

> When I played the position (5 man position) in Aquarium the bug was gone. Rybka 3 played the correct move.

>

> Mark Y.

Hello Mark,

I observed the same things.

When using many 6 men TB's, infinite analysis does not start (Aquarium bug) but if you stop (after TB initialization) and run analysis again, MP analysis with Tablebases is correct

Best regards,

Sylvain

In addition to this endgame bug, we shouldn't forget the blind bishop endgame knowledge which is completely missing from Rybka 3

You know ... I have tried very hard to see what is behind this issue and if there is a work around. It is obviously a problem between MP Rybka (and I mean all Rybkas ... not only R3 MP) and how EGTB information is accessed. I am actually quite surprised that we did not identify this issue as an MP EGTB bug for Rybka since this seems to have been a problem since initial Rybka MP. This problem does not exist in any of the Rybka's on single core. That is why I think the problem is much more complex than we think and will not be so easy to fix ... and probably will take a long time. It could be some obscure way that the Nalimov EGTB's work that R3 MP has a problem with ... so if you think that this is a simple bug that can be fixed in a day or so I think you are mistaken. That is the bad news ... the good news though is that R3 will probably be quite a bit stronger once this is sorted out ... especially against the stronger engines where they don't get crushed in the opening or middle game and thus Rybka goes into the endgame with a big + that has to be nursed to get the win. I believe in a match against the top engines ... R3 MP could probably gain around 20 ELO against the top engines ... against the weaker engines ... the gain would probably be minimal. For now the only workaround I can think of is to have around 300 GB of EGTB's ... that in my case seems to solve the problem for 90% of the cases ... or ofcourse if you are using analysis of a position ... then it would be a good idea to do a quick check with Rybka 3 1-cpu when you feel such a position has come about (R3 SP is maybe 60 or 70 ELO weaker than R3 MP but still much stronger than all other engines). I know it is not an elegant solution ... but until Vas figures out this bug I think that is the best way to proceed.

By the way ... in these type of positions ... say if you have 4 cores or more ... where Rybka sticks to its famous "+5.09" non changing evaluation ... this would be a situation where one core could be sacrificed to do a quick Monte Carlo analysis of the position. I would put the trigger to run 1 core of analysis when the evaluation seems to be "stuck" at say depth of 20 or 30 ... this would immediately solve all these problems because 1 core already deals with these situations well ... and Monte Carlo on 1 core would immediately choose the correct path very quickly. I think an even more sophisticated way would be to somehow incorporate 7 piece bitbases (they have a relatively small footprint) along with Monte Carlo ... this would create by far the strongest endgame playing engine on earth. Some ideas for R4 maybe :)

By the way ... in these type of positions ... say if you have 4 cores or more ... where Rybka sticks to its famous "+5.09" non changing evaluation ... this would be a situation where one core could be sacrificed to do a quick Monte Carlo analysis of the position. I would put the trigger to run 1 core of analysis when the evaluation seems to be "stuck" at say depth of 20 or 30 ... this would immediately solve all these problems because 1 core already deals with these situations well ... and Monte Carlo on 1 core would immediately choose the correct path very quickly. I think an even more sophisticated way would be to somehow incorporate 7 piece bitbases (they have a relatively small footprint) along with Monte Carlo ... this would create by far the strongest endgame playing engine on earth. Some ideas for R4 maybe :)

I think the problem is due to preoccupation with the 'huge' elo gains, so there's a tendency to gloss over things that only contribute to 1 or 2 elo.

Hi Ansari-Ok, so you are saying that this is a problem with only MP Rybka and not Rybka 3-1 cpu. In that case I give here two sample positions where issues exist with blind bishop endgame knowledge. I've not analysed these positions with Rybka 3 sp so, can you please post your analysis with R3 sp. These posiitons are a complete draw and other engines easily see it but not Rybka 3.

However, if you analyse these positions with Rybka 2.1 mp , it sees the draw in both these positions easily(as does any other engine for that matter) So then how can this be an issue with only MP Rybka can you please explain. Its quite surprising and I hope you will too agree that a 3200 elo engine doesn't know this basic knowledge which even a 1600 elo player has.Apart from these positions what about QK(White) Vs KP(Black) endgames where on certain positions its a draw depending upon the placement of the queening pawn like on f2,g2,h2 etc?

8/8/p1b5/5k2/8/2K5/P5P1/8 w - - 0 44

8/6k1/8/4K3/7P/1B6/7P/8 b - - 0 56

However, if you analyse these positions with Rybka 2.1 mp , it sees the draw in both these positions easily(as does any other engine for that matter) So then how can this be an issue with only MP Rybka can you please explain. Its quite surprising and I hope you will too agree that a 3200 elo engine doesn't know this basic knowledge which even a 1600 elo player has.Apart from these positions what about QK(White) Vs KP(Black) endgames where on certain positions its a draw depending upon the placement of the queening pawn like on f2,g2,h2 etc?

First of all ... please install 5 piece EGTB's. If you want an engine to be able to solve positions without EGTB's ... I can understand that ... but you would be talking about a totally different thing. As I have mentioned before, the 5 piece EGTB's are available for free download and use up about 7 GB of space ... in a day where the smallest capacity HDD is 320 GB, 7 GB seems like a tiny amount to sacrifice. If you don't have that spare capacity ... then for $23 you can buy an 8GB USB drive and install it there. Now if you don't want to do either ... then stick to an older version that has this knowledge. Knowledge in an engine will slow it down ... and thus make it play weaker in general. Vas has made it clear that his priorities are to make the most gain possible in ELO strength in his engine ... and that is why is has removed some knowledge where he thinks 5 piece EGTB's cover it. You may not agree with that philosophy ... but frankly it is up to the engine author to decide what is best. Now back to the subject ... in first position ... although R3 SP does not give a 0.00 evaluation ... it will play moves that draw and will get the draw. It "knows" that it can play a4 or g4 and that the loss of the pawn is an immediate EGTB draw ... something that R3 MP does not "know" or cannot see. That is the problem. Now in position 2 ... it is a simple 5 piece EGTB that even the MP version "sees".

By the way ... you mentioned that R 2.1mp does not have a problem with position 1 ... I tried it on 2.1d3 (I don't have the 2.1 only) and this is its output. So obviously this also existed with the 2.1 version

New game, Blitz:4'+2"

Analysis by Rybka 2.1d3 mp:

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1

= (0.00) Depth: 2 00:00:00

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1

= (0.00) Depth: 3 00:00:00

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1

= (0.00) Depth: 4 00:00:00

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1

= (0.00) Depth: 5 00:00:00

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2

= (0.00) Depth: 6 00:00:00 0kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2

= (0.00) Depth: 10 00:00:00 7kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2

= (0.00) Depth: 10 00:00:00 7kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2

= (0.00) Depth: 10 00:00:00 7kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1

= (0.00) Depth: 10 00:00:00 22kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4

= (0.00) Depth: 11 00:00:00 43kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4 5.Ka2 Kf3

= (0.00) Depth: 13 00:00:00 113kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4 5.Ka2 Kf3

= (0.00) Depth: 13 00:00:00 113kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4 5.Ka2 Kf3 6.Ka1

= (0.00) Depth: 14 00:00:00 191kN

1.Kb2 Bxg2 2.Kb1 Ke4 3.Kc2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3

= (-0.13) Depth: 15 00:00:00 447kN

1.Kb2 Bxg2 2.Kc3 Ke4 3.Kc4 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 16 00:00:00 1182kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 17 00:00:01 1656kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 18 00:00:01 2073kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 19 00:00:02 2758kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 20 00:00:02 3434kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 21 00:00:02 4256kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 22 00:00:03 5255kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 23 00:00:05 7714kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 24 00:00:06 9874kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 25 00:00:07 11930kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 26 00:00:09 15521kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 27 00:00:12 19437kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 28 00:00:16 28035kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 29 00:00:29 49683kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.a4 Kf3 4.a5 Ke3 5.Kc2 Bc6 6.Kb2 Be4 7.Ka2 Kd4

= (-0.16) Depth: 30 00:00:36 62212kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.a4 Kf3 4.a5 Ke3 5.Kc2 Bc6 6.Kb2 Be4 7.Ka2 Kd4

= (-0.16) Depth: 31 00:00:43 76169kN

1.Kb2 Bxg2 2.Kc3 Ke4 3.a4 Kd5 4.Kb4 Kd4 5.Ka5 Bb7 6.Kb4 Bd5 7.Ka5 Bc4

-+ (-3.59) Depth: 32 00:00:59 104mN

(, 15.08.2008)

By the way ... you mentioned that R 2.1mp does not have a problem with position 1 ... I tried it on 2.1d3 (I don't have the 2.1 only) and this is its output. So obviously this also existed with the 2.1 version

New game, Blitz:4'+2"

8/8/p1b5/5k2/8/2K5/P5P1/8 w - - 0 1

Analysis by Rybka 2.1d3 mp:

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1

= (0.00) Depth: 2 00:00:00

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1

= (0.00) Depth: 3 00:00:00

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1

= (0.00) Depth: 4 00:00:00

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1

= (0.00) Depth: 5 00:00:00

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2

= (0.00) Depth: 6 00:00:00 0kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2

= (0.00) Depth: 10 00:00:00 7kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2

= (0.00) Depth: 10 00:00:00 7kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2

= (0.00) Depth: 10 00:00:00 7kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1

= (0.00) Depth: 10 00:00:00 22kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4

= (0.00) Depth: 11 00:00:00 43kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4 5.Ka2 Kf3

= (0.00) Depth: 13 00:00:00 113kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4 5.Ka2 Kf3

= (0.00) Depth: 13 00:00:00 113kN

1.Kb2 Bxg2 2.a3 Bf1 3.Ka1 Be2 4.Kb1 Ke4 5.Ka2 Kf3 6.Ka1

= (0.00) Depth: 14 00:00:00 191kN

1.Kb2 Bxg2 2.Kb1 Ke4 3.Kc2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3

= (-0.13) Depth: 15 00:00:00 447kN

1.Kb2 Bxg2 2.Kc3 Ke4 3.Kc4 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 16 00:00:00 1182kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 17 00:00:01 1656kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 18 00:00:01 2073kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 19 00:00:02 2758kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 20 00:00:02 3434kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.a4 Be4+

= (-0.16) Depth: 21 00:00:02 4256kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 22 00:00:03 5255kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 23 00:00:05 7714kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 24 00:00:06 9874kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 25 00:00:07 11930kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 26 00:00:09 15521kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 27 00:00:12 19437kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 28 00:00:16 28035kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.Kb2 Ke3 4.Kc3 Bd5 5.Kb2 Kd2 6.Kb1 Kc3 7.Ka1 Kc2

= (-0.16) Depth: 29 00:00:29 49683kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.a4 Kf3 4.a5 Ke3 5.Kc2 Bc6 6.Kb2 Be4 7.Ka2 Kd4

= (-0.16) Depth: 30 00:00:36 62212kN

1.Kb2 Bxg2 2.Kc3 Kf4 3.a4 Kf3 4.a5 Ke3 5.Kc2 Bc6 6.Kb2 Be4 7.Ka2 Kd4

= (-0.16) Depth: 31 00:00:43 76169kN

1.Kb2 Bxg2 2.Kc3 Ke4 3.a4 Kd5 4.Kb4 Kd4 5.Ka5 Bb7 6.Kb4 Bd5 7.Ka5 Bc4

-+ (-3.59) Depth: 32 00:00:59 104mN

(, 15.08.2008)

Well Ansari- Even your Rybka 2.1 d3 mp displays a draw eval doesn't it? Its only at depth 32 that it displays a negative eval of -3.59(dont know from where that comes!).

1.Kb2 Bxg2 2.Kc3 Ke4 3.a4 Kd5 4.Kb4 Kd4 5.Ka5 Bb7 6.Kb4 Bd5 7.Ka5 Bc4

-+ (-3.59) Depth: 32 00:00:59 104mN

Well here's the analysis by Rybka 2.1c mp running in infinite analysis mode at depth=41. It still is able to see the draw here.

Analysis by Rybka 2.1c mp 32-bit:

1. = (0.00): 1.Kb2 Bxg2 2.a4 a5 3.Ka1 Bd5 4.Kb2 Bf3 5.Ka1 Bd5 6.Kb2 Bf3 7.Ka1 Bd5

2. = (0.00): 1.g4+ Kxg4 2.Kb2 a5 3.a4 Bxa4 4.Ka1 Bd1 5.Kb2 Bf3 6.Ka1 Bd5 7.Kb2 Bf3

3. = (0.00): 1.g3 Bd5 2.Kb2 a5 3.a4 Bf3 4.Kb1 Bd5 5.Ka1 Bf3 6.Kb2 Bd5 7.Ka1 Bf3

( Personal 15.08.2008)

So in this case I dont think this existed in the Rybka 2.1c mp vesion at least.Please correct me if I'm wrong.

1.Kb2 Bxg2 2.Kc3 Ke4 3.a4 Kd5 4.Kb4 Kd4 5.Ka5 Bb7 6.Kb4 Bd5 7.Ka5 Bc4

-+ (-3.59) Depth: 32 00:00:59 104mN

8/8/p1b5/5k2/8/2K5/P5P1/8 w - - 0 1

Well here's the analysis by Rybka 2.1c mp running in infinite analysis mode at depth=41. It still is able to see the draw here.

Analysis by Rybka 2.1c mp 32-bit:

1. = (0.00): 1.Kb2 Bxg2 2.a4 a5 3.Ka1 Bd5 4.Kb2 Bf3 5.Ka1 Bd5 6.Kb2 Bf3 7.Ka1 Bd5

2. = (0.00): 1.g4+ Kxg4 2.Kb2 a5 3.a4 Bxa4 4.Ka1 Bd1 5.Kb2 Bf3 6.Ka1 Bd5 7.Kb2 Bf3

3. = (0.00): 1.g3 Bd5 2.Kb2 a5 3.a4 Bf3 4.Kb1 Bd5 5.Ka1 Bf3 6.Kb2 Bd5 7.Ka1 Bf3

( Personal 15.08.2008)

So in this case I dont think this existed in the Rybka 2.1c mp vesion at least.Please correct me if I'm wrong.

Try it withought MPV output and clear hash first. It could be that d3 is differnt that c ... but I don't think so.

Howdy, I would like to add my two cents worth on these positions. I have a 8 core @ 2.8 ghz, 4 gig ram, hash set to 1024, 3,4,5 tb's, Fritz8 GUI. I get the following result:

#1) Rd3, 2.18 instant, I stopped at depth 33.

#2) Ke4 .33 instant, I stopped at depth 31

#3) Rd8 2.20 @ depth 23 switches Rd6 3.50 @ depth 23 I stopped @ depth 28.

#4) Qd5 +5.36 @ depth 16 I stopped it there. I dont know if it is gonna find the mate with my tb's but I did not have the patience to find out.

It seems as though my 8 core comp with 3,4,5 tb's gave appropriate answers. What You think ?

Wayne

#1) Rd3, 2.18 instant, I stopped at depth 33.

#2) Ke4 .33 instant, I stopped at depth 31

#3) Rd8 2.20 @ depth 23 switches Rd6 3.50 @ depth 23 I stopped @ depth 28.

#4) Qd5 +5.36 @ depth 16 I stopped it there. I dont know if it is gonna find the mate with my tb's but I did not have the patience to find out.

It seems as though my 8 core comp with 3,4,5 tb's gave appropriate answers. What You think ?

Wayne

Hi wayne, the point is that Zappa Mexico, Fritz 11 in position 4 finds the mate in 47 almost at once ...

Analysis by Zappa Mexico II:

1.Qe1+ g1Q 2.Qxg1+ Kxg1

+- (#47) Depth: 19/55 00:00:12 96107kN, tb=8429

New game

Analysis by Fritz 11:

1.Qe1+ g1Q 2.Qxg1+ Kxg1

+- (#47) Depth: 18/33 00:00:05 23320kN, tb=6667

I did notice that at least Rybka 3 Human is looking at the correct move

New game

Analysis by Rybka 3 Human:

1.Qe1+ g1Q

+- (6.72) Depth: 12 00:00:17 15048kN, tb=17

Regards

Analysis by Zappa Mexico II:

1.Qe1+ g1Q 2.Qxg1+ Kxg1

+- (#47) Depth: 19/55 00:00:12 96107kN, tb=8429

New game

8/8/8/1P6/8/P6r/1KPQ2p1/7k w - - 0 1

Analysis by Fritz 11:

1.Qe1+ g1Q 2.Qxg1+ Kxg1

+- (#47) Depth: 18/33 00:00:05 23320kN, tb=6667

I did notice that at least Rybka 3 Human is looking at the correct move

New game

8/8/8/1P6/8/P6r/1KPQ2p1/7k w - - 0 1

Analysis by Rybka 3 Human:

1.Qe1+ g1Q

+- (6.72) Depth: 12 00:00:17 15048kN, tb=17

Regards

Yes that is exactly the point. With brute force ... given enough time Rybka 3 MP will eventually figure it out ... but why should brute force be used when EGTB's have the solution in milli seconds ... and which R3 MP sees immediately one move later. Obviously there is a problem with communication between EGTB's and the MP generated hash ... I would tend to think that there might be more situations where we do not see where R3 MP will play a non optimal move because of this lack of communication. Again I think that it makes a lot of difference against engines who are already very strong ... such as R2.3.2a (even though it suffers from similar bug), Zappa II, Hiarcs, D Shredder and D Fritz. I would tend to think that this bug is not so critical against weaker opponents since they are lost in the early part of the game.

I guess the point I was trying to convey, was R3 found the correct move for the first three position in 8 processor mode instantly. So it seems to me not as bad TB probelm that is being discussed.

The post topic as I unsterstood was that only R3 one cpu only solved the three positions. I am just pointing out that is not my experience.

Wayne

The post topic as I unsterstood was that only R3 one cpu only solved the three positions. I am just pointing out that is not my experience.

Wayne

He Wayne, you are the first, who claimed there is no bug at all with EGTB (5-6 man). Please show us your analyse lines (like bnc) for each position. I want to see your tbs hits. And please check your engine parameter (all standard?) and your EGTB (all 5 man; 7.1 GB?). If you can´t reproduce the EGTB fault, we have a very big problem. Then we know nothing! At last you should try it with 4 and/or 2 cores.

But first, give us the complete analysis!

PS: I can´t imagine, that you are right!

But first, give us the complete analysis!

PS: I can´t imagine, that you are right!

Okey Dokey, hang on will take a bit to load the position

Wayne

Wayne

Hi Roland you mention that I am using 5-6 man tb's. I said I was using 3,4,5 man tb's. Do you want my engine outputs still. ?

I will be most happy to provide Roland.

Wayne

I will be most happy to provide Roland.

Wayne

For me, there is no difference in 5 man vs 6 man EGTB in Rybka mp, considering the EGTB bug.

Your engine outputs are welcome! :-)

Your engine outputs are welcome! :-)

Depth 10, tb=1 1.Rd3,Kf5 2.Kc4, Rc6+ 3.Kb5,Re6 4.Kc5

+/- 1.41 Depth 10, 00:00:00 8kN tb=1

Depth 29, tb= 26653 1.Rd3,Kf5 2.Kc4,Re4+ 3.Kc3,Kg4 4.Kd2,Kf3 5.f5,Re5 6.f6,Rf5 7. Rd6, Ke4 8.Re6+,Kd5 9.Rb6,Ke5 10.Kd3,Rf1 11.Ra6,Rf3

+/- 1.87 Depth 29, 00:01:36 32142kN tb=26653

This is position #1 I took time to eat my dinner :) does this help ? Do you wish to see the other engine outputs.

Wayne

+/- 1.41 Depth 10, 00:00:00 8kN tb=1

Depth 29, tb= 26653 1.Rd3,Kf5 2.Kc4,Re4+ 3.Kc3,Kg4 4.Kd2,Kf3 5.f5,Re5 6.f6,Rf5 7. Rd6, Ke4 8.Re6+,Kd5 9.Rb6,Ke5 10.Kd3,Rf1 11.Ra6,Rf3

+/- 1.87 Depth 29, 00:01:36 32142kN tb=26653

This is position #1 I took time to eat my dinner :) does this help ? Do you wish to see the other engine outputs.

Wayne

For info, My Fritz benchmark for this comp is: 8 processor, Relative speed= 127.25.. Kilo nodes per second= 13078.

Just thought I would throw that in

Wayne

Just thought I would throw that in

Wayne

Well ... it could be possible that an 8 core would have less of a chance of hitting this bug ... simply because with 8 core you have 2x as many cores as a Quad ... and 4x as many cores as a Dual ... so the non determenistic nature of MP implementation would mean that you would have less chance of hitting the bug. But the bug is there ... and I have seen it on my Octa system. I have my Octa's now doing a LTC tourney but I might give it a shot today ... or maybe you could do the output of say 30 seconds per position and then clip analysis. Also do you have any 6 piece EGTB's loaded?

No I do not

Thank you

Wayne

Thank you

Wayne

well why would he install 5 man EGTB? they don't work.

the blind bishop problem might not even matter or it would matter far less if 5 mans were working.

the blind bishop problem might not even matter or it would matter far less if 5 mans were working.

> ... the good news though is that R3 will probably be quite a bit stronger once this is sorted out ...

It is a pity indeed that we didn't detect it earlier. However, when I did, I felt that I had to post it so i could be discussed and I feel that Rybka would definitely benefit when this is sorted out. I want to see a Rybka which I can trust troughout the game, especially when analyzing.

I definetely did detect it and informed Vas ... at the time I was not sure what the bug was ... if it was a bug ... if it was somehow related to the still very beta GUI or that somehow in the beta version the EGTB's were still not working or did not have the code activated yet. It is very hard if not impossible to quickly figure where the problem was. I think it was only once I messaged LK that he pointed out that this could be a problem with only the MP version ... and sure enough that turned out to be correct. I had never thought of testing the SP version in those positions and automatically assumed that the MP version was simply an MP version that would do more calculations of the SP version. The thing is that this does not seem to be a R3 bug ... but rather a bug in MP implementation of EGTB's that was carried over from previous MP versions.

Can we conclude that in Rybka mp we should use "Never" for tablebase access until the problem is fixed?

Thanks for the summary. I haven't had a chance to dig through the code for this yet but will do so soon.

In the meantime we'll add this to the FAQ.

Vas

In the meantime we'll add this to the FAQ.

Vas

He Vas, there is no hurry! But it would be fine, if you can say us in a month or two, what we can do to minimize the effect (a workaround).

In the meantime, we should have own results from testing about the bigness of the effect. But the endgame analyzers are really shocked and unsettled now! We all guess, something is wrong here, but nobody saw the bug.

PS: It´s fine, that we speak about endgames, when we speak about Rybka! :-)

In the meantime, we should have own results from testing about the bigness of the effect. But the endgame analyzers are really shocked and unsettled now! We all guess, something is wrong here, but nobody saw the bug.

PS: It´s fine, that we speak about endgames, when we speak about Rybka! :-)

Hi,

I tend to run into this problem daily with Rybka seemingly with a big plus just to swap off into a draw. When I get the time I tend to try and fix it by what I call hard-wireing the problem in the book. I normally end up with zappa mex 2 analysing the position and working to find the position even Rybka cannot mess up lol :) (fingers crossed)

Regards

I tend to run into this problem daily with Rybka seemingly with a big plus just to swap off into a draw. When I get the time I tend to try and fix it by what I call hard-wireing the problem in the book. I normally end up with zappa mex 2 analysing the position and working to find the position even Rybka cannot mess up lol :) (fingers crossed)

Regards

"

If I want to analyze a game that was not resolved in the middle game, I mean all the other way around, a game which its main component is the endgame:

would be logical/useful to use Rybka 3 to analyze endgame moves?

Or in this case would be better to use R3 to analyze opening and middlegame phase and for the endgame one should use DShredder 11, DSjeng 3, or Zappa Mx2?

Best regards,

Patricio.

*But the endgame analyzers are really shocked and unsettled now!*"If I want to analyze a game that was not resolved in the middle game, I mean all the other way around, a game which its main component is the endgame:

would be logical/useful to use Rybka 3 to analyze endgame moves?

Or in this case would be better to use R3 to analyze opening and middlegame phase and for the endgame one should use DShredder 11, DSjeng 3, or Zappa Mx2?

Best regards,

Patricio.

1
2

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill