Do other engines reproduce this blunder?

[ernest]

The Gaviota EGTB probing code is quite clear and self-explanatory.

Robert, any idea when the bug can be corrected in Houdini?

[Houdini]

The Gaviota EGTB probing code is quite clear and self-explanatory.

Robert, any idea when the bug can be corrected in Houdini?

The bug was corrected the day Miguel reported the issue on this forum, but I didn't think it was sufficiently important for a new release of Houdini.

The problem can only occur in the KPKPP ending, if you're worried about it you could remove the kppkp.gtb.cp4 file from your Gaviota directory, it will not have the slightest impact on the playing strength of Houdini.

Robert

[michiguel]

The Gaviota EGTB probing code is quite clear and self-explanatory.

Robert, any idea when the bug can be corrected in Houdini?

The bug was corrected the day Miguel reported the issue on this forum, but I didn't think it was sufficiently important for a new release of Houdini.

The problem can only occur in the KPKPP ending, if you're worried about it you could remove the kppkp.gtb.cp4 file from your Gaviota directory, it will not have the slightest impact on the playing strength of Houdini.

Robert

That is actually a very safe [temporary] solution. The probing code will specifically detect KPPKP is not there, and it won't even bother to try to probe a second time. Since no other file depends on KPPKP (which is at the top of the "food chain"), there is no downside effect.

The only problem is if you have, of course, other engines using the gaviota tbs. The ugly workaround is to use two different directories, one with all the TBs, and the other with KPPKP.

Miguel

[marcelk]

It's not so amusing if you know anything about programming (do you?).

No, I don't.

[Mike S.]

This gives a nice example of "less is more" (sometimes)...

[d]8/7p/6p1/6P1/5K1k/8/8/8 b - - 0 1

Houdini 1.5a:
4/6 00:00 122 0 -2,58 1. ... Kh5 2.Ke4 Kxg5 3.Ke5 h5
(...)
22/31- 00:00 78.393 298.000 -18,82 1. ... Kh5
22/31 00:00 78.406 293.000 -M17 1. ... Kh5 2.Kg3 Kxg5 3.Kh3 h5 4.Kg3 h4+ 5.Kh3 Kf4 6.Kxh4 g5+ 7.Kh3 Kf3 8.Kh2 g4 9.Kg1 Kg3 10.Kf1 Kh2 11.Kf2 g3+ 12.Ke3 g2 13.Kf3 g1Q 14.Ke4 Qg2+ 15.Kd4 Qg4+ 16.Ke5
(...)
99/33 00:00 214.534 257.000 -M17 1. ... Kh5 2.Kg3 Kxg5 3.Kh3 h5 4.Kg3 h4+ 5.Kh3 Kf4 6.Kxh4 g5+ 7.Kh3 Kf3 8.Kh2 g4 9.Kg1 Kg3 10.Kf1 Kh2 11.Kf2 g3+ 12.Ke3 g2 13.Kf3 g1Q 14.Ke4 Qg2+ 15.Kd4 Qg4+ 16.Ke5

How come? I am using 3p+4p Gaviotas only.

(If it's not reproduceable: I have adjusted hard_probe to 16 and soft_probe to 10, having stored the G.tables on a USB memory stick.)