BigLion and fine 70

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 09 December 2002 14:09:37:

Here is a little test I just ran
8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - bm Kb1
30 second analysis (~13 MB hash/A1000):

Ruffian 1.0.0: Depth=42 Score=8.15 - solved at ply 18 (13 MB)
Yace 0.99.56: Depth=40 Score=6.26 - solved at ply 19 (14 MB)
Quark 1.50: Depth=36 Score=6.70 - solved at ply 18 (16 MB)
Crafty_DC 19.1: Depth=34 Score=4.49 - solved at ply 26 ( 5 MB!?)
BigLion latest: Depth=25 Score=3.01 - solved at ply 22 (18 MB)
Beowulf 1.9: Depth=26 Score=0.00 - solved at ply 22 (16 MB)
Frenzee 138b: Depth=19 Score=0.83 - not solved (13 MB)

Notes:
Yace was given 13 MB and used 14 MB
Quark was given 13 MB and used 16 MB
BigLion was given 13 MB and used 18 MB
Beowulf had no setting of 13, had to be 8 or 16 MB
Crafty doesn't even output an ini-file?
No pv from Crafty until depth 26, so might have solved it sooner,
the low hash cripples the TT of course.

I'm not pleased with frenzee here!
I seem to have a bug in the TT
-S.

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 09 December 2002 14:17:19:
Als Antwort auf: / In reply to: BigLion and fine 70 geschrieben von: / posted by: Sune Fischer at 09 December 2002 14:09:37:

Here is a little test I just ran
8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - bm Kb1
30 second analysis (~13 MB hash/A1000):

Ruffian 1.0.0: Depth=42 Score=8.15 - solved at ply 18 (13 MB)
Yace 0.99.56: Depth=40 Score=6.26 - solved at ply 19 (14 MB)
Quark 1.50: Depth=36 Score=6.70 - solved at ply 18 (16 MB)
Crafty_DC 19.1: Depth=34 Score=4.49 - solved at ply 26 ( 5 MB!?)
BigLion latest: Depth=25 Score=3.01 - solved at ply 22 (18 MB)
Beowulf 1.9: Depth=26 Score=0.00 - solved at ply 22 (16 MB)
Frenzee 138b: Depth=19 Score=0.83 - not solved (13 MB)

Notes:
Yace was given 13 MB and used 14 MB
Quark was given 13 MB and used 16 MB
BigLion was given 13 MB and used 18 MB
Beowulf had no setting of 13, had to be 8 or 16 MB
Crafty doesn't even output an ini-file?
No pv from Crafty until depth 26, so might have solved it sooner,
the low hash cripples the TT of course.

I'm not pleased with frenzee here!
I seem to have a bug in the TT
-S.

Movei also does not solve it but I did not expect it to solve it because I still did not implement hash tables for exact scores.
Is it the first time that you test with this position?
This position is known to be one of the tests for hash tables so I expect most programmers who use hash for exact scores to use it.
I am surprised that you did not do it.
Uri

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 09 December 2002 14:28:38:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Uri Blass at 09 December 2002 14:17:19:

Movei also does not solve it but I did not expect it to solve it because I still did not implement hash tables for exact scores.
Is it the first time that you test with this position?
This position is known to be one of the tests for hash tables so I expect most programmers who use hash for exact scores to use it.
I am surprised that you did not do it.
Uri

Yes I knew Movei wouldn't look good in this test, so saw no reason to test it.
Strange though, how one position can say it all
Sure, go ahead, rub it in
Really strange I think, but hey when I fix it - it will play _better_!
-S.

[Matthias Gemuh]

Geschrieben von: / Posted by: Matthias Gemuh at 09 December 2002 15:26:41:
Als Antwort auf: / In reply to: BigLion and fine 70 geschrieben von: / posted by: Sune Fischer at 09 December 2002 14:09:37:

Here is a little test I just ran
8/k7/3p4/p2P1p2/P2P1P2/8/8/K7 w - - bm Kb1
30 second analysis (~13 MB hash/A1000):

Ruffian 1.0.0: Depth=42 Score=8.15 - solved at ply 18 (13 MB)
Yace 0.99.56: Depth=40 Score=6.26 - solved at ply 19 (14 MB)
Quark 1.50: Depth=36 Score=6.70 - solved at ply 18 (16 MB)
Crafty_DC 19.1: Depth=34 Score=4.49 - solved at ply 26 ( 5 MB!?)
BigLion latest: Depth=25 Score=3.01 - solved at ply 22 (18 MB)
Beowulf 1.9: Depth=26 Score=0.00 - solved at ply 22 (16 MB)
Frenzee 138b: Depth=19 Score=0.83 - not solved (13 MB)

Notes:
Yace was given 13 MB and used 14 MB
Quark was given 13 MB and used 16 MB
BigLion was given 13 MB and used 18 MB
Beowulf had no setting of 13, had to be 8 or 16 MB
Crafty doesn't even output an ini-file?
No pv from Crafty until depth 26, so might have solved it sooner,
the low hash cripples the TT of course.

I'm not pleased with frenzee here!
I seem to have a bug in the TT
-S.

Hi Sune,
this is strange ! I think BigLion solves it because of bugs -> WAC 255/300, 1.4GHz, 5 sec/pos.
Taking into account the fact that BigLion hashes move lists, that was really small hash you assigned. I shall check whether book and internal data really consume so much extra mem.
Frenzee 135 has output sign problems under Fritz7 GUI, with both options in ini-file. Your fast program searches 2 to 3 plys deeper than slow BigLion !!!
Regards,
Matthias.

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 09 December 2002 16:46:47:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Matthias Gemuh at 09 December 2002 15:26:41:

Hi Sune,
this is strange ! I think BigLion solves it because of bugs -> WAC 255/300, 1.4GHz, 5 sec/pos.
Taking into account the fact that BigLion hashes move lists, that was really small hash you assigned. I shall check whether book and internal data really consume so much extra mem.
Frenzee 135 has output sign problems under Fritz7 GUI, with both options in ini-file.
Your fast program searches 2 to 3 plys deeper than slow BigLion !!!
Regards,
Matthias.

Bugs, I don't think so, BitLion is doing great
I really must figure out what's going on in frenzee, it's like there is no TT at all!
Also these positions:
3k4/8/8/3p4/3P4/8/8/3K4 w - - 0 1
k7/2K5/8/P7/8/8/8/8 w - - 0 1
It used to go really deep in those, I remember I had a problem with what to when it hit ply 60 (which is the internal limit).
Fritz7 GUI, how do you do that, it's not UCI?
I only tested in WB.
Oh, heehee
I'm slowing it down now, thought more knowledge and less speed is the way to go
After I saw it play the no-no move cxd5 in this position against Chezzz
2r3k1/qprbbppp/p7/P2np3/2Pp4/1P1P4/2NBBPPP/RQ3RK1 w - -
I realized speed is nothing without decent evaluation
Okay, it actually had a bug in the double pawn detection which probably resulted in this insane move, but none the less..
Heck it's not all bad, maybe I can lower my safty margins on pruning now
-S.

[Gian-Carlo Pascutto]

Geschrieben von: / Posted by: Gian-Carlo Pascutto at 09 December 2002 17:50:00:
Als Antwort auf: / In reply to: BigLion and fine 70 geschrieben von: / posted by: Sune Fischer at 09 December 2002 14:09:37:

Frenzee 138b: Depth=19 Score=0.83 - not solved (13 MB)

I'm not pleased with frenzee here!
I seem to have a bug in the TT
-S.

IIRC the solution is 23 ply. It is possible to find it faster
if you have bad move ordering.
--
GCP

[Matthias Gemuh]

Geschrieben von: / Posted by: Matthias Gemuh at 09 December 2002 18:04:08:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Sune Fischer at 09 December 2002 16:46:47:

Hi Sune,
this is strange ! I think BigLion solves it because of bugs -> WAC 255/300, 1.4GHz, 5 sec/pos.

Frenzee 135 has output sign problems under Fritz7 GUI, with both options in ini-file.

Bugs, I don't think so, BitLion is doing great
Fritz7 GUI, how do you do that, it's not UCI?
I only tested in WB.

[ENGINE]
Name=Frenzee
Author=Sune Fischer
Filename=Wb2Uci.exe
[OPTIONS]
Program=Frenzee.exe
OwnBook=true
Edit=edit
LevelExtend=failsafe
Visible=Logfile,OwnBook

Frenzee 135 (not earlier) plays very well with these WB2UCI settings.
Only the sign of output is sometimes wrong, causing GUI to record wrong final results or "resign" the wrong engine.
/Matthias.

[Uri Blass]

Geschrieben von: / Posted by: Uri Blass at 09 December 2002 18:09:38:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Gian-Carlo Pascutto at 09 December 2002 17:50:00:

Frenzee 138b: Depth=19 Score=0.83 - not solved (13 MB)

I'm not pleased with frenzee here!
I seem to have a bug in the TT
-S.

IIRC the solution is 23 ply. It is possible to find it faster
if you have bad move ordering.
--
GCP

1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-d7 6.Kd2-c3 Kd7-c7 7.Kc3-d3 Kc7-b7 8.Kd3-e2 Kb7-c7 9.Ke2-f3 Kc7-d7 10.Kf3-g3 Kd7-e7 11.Kg3-h4 Ke7-f6 12.Kh4-h5 Kf6-f7 13.Kh5-g5 Line

Uri

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 09 December 2002 18:10:39:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Gian-Carlo Pascutto at 09 December 2002 17:50:00:

Frenzee 138b: Depth=19 Score=0.83 - not solved (13 MB)

I'm not pleased with frenzee here!
I seem to have a bug in the TT
-S.

IIRC the solution is 23 ply. It is possible to find it faster
if you have bad move ordering.
--
GCP

It is possible, but what worries me is the very low depth it reaches in this high TT position.
I tried going back, and found that one of the very old versions (v.117) solved it at ply 22 and reached 30 plies in 30 seconds. I would call that a proof it was working, must have scrooed it up somehow but it's apparently been broken for a long time..
-S.

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 09 December 2002 18:12:56:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Matthias Gemuh at 09 December 2002 18:04:08:

Hi Sune,
this is strange ! I think BigLion solves it because of bugs -> WAC 255/300, 1.4GHz, 5 sec/pos.

Frenzee 135 has output sign problems under Fritz7 GUI, with both options in ini-file.

Bugs, I don't think so, BitLion is doing great
Fritz7 GUI, how do you do that, it's not UCI?
I only tested in WB.

[ENGINE]
Name=Frenzee
Author=Sune Fischer
Filename=Wb2Uci.exe
[OPTIONS]
Program=Frenzee.exe
OwnBook=true
Edit=edit
LevelExtend=failsafe
Visible=Logfile,OwnBook
Frenzee 135 (not earlier) plays very well with these WB2UCI settings.
Only the sign of output is sometimes wrong, causing GUI to record wrong final results or "resign" the wrong engine.
/Matthias.

Thats strange, I think the only difference in communication is the ping command which wasn't supported until v.135.
-S.

[Matthias Gemuh]

Geschrieben von: / Posted by: Matthias Gemuh at 09 December 2002 18:15:22:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Gian-Carlo Pascutto at 09 December 2002 17:50:00:

Frenzee 138b: Depth=19 Score=0.83 - not solved (13 MB)

I'm not pleased with frenzee here!
I seem to have a bug in the TT
-S.

IIRC the solution is 23 ply. It is possible to find it faster
if you have bad move ordering.
--
GCP

"It is possible to find it faster if you have bad move ordering."
Sune, the move ordering of BigLion is a mess. However, I will not tweak it now, as the result could be that he solves the problem even faster .
Thanks, GCP.
/Matthias.

[Dieter Bürßner]

Geschrieben von: / Posted by: Dieter Bürßner at 09 December 2002 18:27:27:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Gian-Carlo Pascutto at 09 December 2002 17:50:00:

IIRC the solution is 23 ply. It is possible to find it faster
if you have bad move ordering.

I heard this argument from Robert Hyatt, too. I don't believe it. The argument goes a bit like: only with bad move ordering, you will luckily hash postions with good score, in which you then can transpose later (after a longer path) and save some depth.
I actually think, good move ordering together with fail soft search will make you find it faster. In alpha-beta search, you will need to try bad moves anyway, which will get refuted by the next half-move. If you try the best refutatation first, and use fail-solft alpha-beta, the stored hash position may be good enough, to cause a cutoff later due to the hash. Also, you are certainly aware of the fact, that often many moves are able to refute a previous move. Something, that is not measured by typical move order statistics.
Regards,
Dieter

[Dieter Bürßner]

Geschrieben von: / Posted by: Dieter Bürßner at 09 December 2002 18:44:25:
Als Antwort auf: / In reply to: BigLion and fine 70 geschrieben von: / posted by: Sune Fischer at 09 December 2002 14:09:37:

Yace was given 13 MB and used 14 MB

It used most probably almost exactly 13e6 bytes for hash table memory. (Few more bytes are needed by the C runtime library to administrate the allocated pointers). The 1 MB you see, it uses more is probably due to code and other data structures (of which many will not be accessed during normal play, and can be swapped out without problem - for example all the book building code/data).
There is also already some overhead for tables of the TB-acess code, which will be needed to startup the engine, even when no TB-access is configured. Again, in tight memory situations, this will be swapped out without any problem.
I guess, the situation is similar with the other engines.
Regards,
Dieter

[Gian-Carlo Pascutto]

Geschrieben von: / Posted by: Gian-Carlo Pascutto at 09 December 2002 19:44:10:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Uri Blass at 09 December 2002 18:09:38:

1.Ka1-b1 Ka7-b7 2.Kb1-c1 Kb7-c7 3.Kc1-d1 Kc7-d7 4.Kd1-c2 Kd7-c8 5.Kc2-d2 Kc8-
d7 6.Kd2-c3 Kd7-c7 7.Kc3-d3 Kc7-b7 8.Kd3-e2 Kb7-c7 9.Ke2-f3 Kc7-d7 10.Kf3-g3
Kd7-e7 11.Kg3-h4 Ke7-f6 12.Kh4-h5 Kf6-f7 13.Kh5-g5 Line

Thanks. Deep Sjeng solves it at ply 26, and I was wondering if it had
bad luck with pruning or something
I guess everything is in order.
--
GCP

[Gian-Carlo Pascutto]

Geschrieben von: / Posted by: Gian-Carlo Pascutto at 09 December 2002 19:49:07:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Dieter Bürßner at 09 December 2002 18:27:27:

IIRC the solution is 23 ply. It is possible to find it faster
if you have bad move ordering.

I heard this argument from Robert Hyatt, too. I don't believe it. The argument
goes a bit like: only with bad move ordering, you will luckily hash postions
with good score, in which you then can transpose later (after a longer path)
and save some depth.
I actually think, good move ordering together with fail soft search will make
you find it faster. In alpha-beta search, you will need to try bad moves
anyway, which will get refuted by the next half-move. If you try the best
refutatation first, and use fail-solft alpha-beta, the stored hash position
may be good enough, to cause a cutoff later due to the hash. Also, you are
certainly aware of the fact, that often many moves are able to refute a
previous move. Something, that is not measured by typical move order
statistics.

I have not given much thought to whether Roberts argument is correct
(I was effectively quoting him in the first post because I believed
it to be correct) or not because I have observed in my program that
it will almost always solve this position faster if I make it more
stupid (be it with search, move ordering, or eval)
Since practise seems to support his claim, and disprove yours, I
would guess there is more going on here than we understand.
--
GCP

[Dieter Bürßner]

Geschrieben von: / Posted by: Dieter Bürßner at 09 December 2002 21:00:35:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Gian-Carlo Pascutto at 09 December 2002 19:49:07:

I have not given much thought to whether Roberts argument is correct
(I was effectively quoting him in the first post because I believed
it to be correct) or not because I have observed in my program that
it will almost always solve this position faster if I make it more
stupid (be it with search, move ordering, or eval)
Since practise seems to support his claim, and disprove yours, I
would guess there is more going on here than we understand.

I agree. Some other points are, the intrinsically wrong handling of repetitions by HTs. And of course other "HT-luck" issues (Is the right entry accidently available, or was it luckily overwritten, and by this will not show the repetition problem).
My results - to not complicate things by eval issues with material only search. Normal move ordering: Kb1 at depth 22 with score of +2 pawns. Random move ordering: Kb1 at depth 26 with score +2 pawns. (Kb1 was found earlier, but that is uninteresting for the sake of this argument, because the pawn win was not seen).
BTW. Even random move ordering is no big problem here, and the search depth is reached fast (TTs help a lot).
Regards,
Dieter

[Miguel A. Ballicora]

Geschrieben von: / Posted by: Miguel A. Ballicora at 09 December 2002 21:10:34:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Dieter Bürßner at 09 December 2002 18:27:27:

IIRC the solution is 23 ply. It is possible to find it faster
if you have bad move ordering.

I heard this argument from Robert Hyatt, too. I don't believe it. The argument goes a bit like: only with bad move ordering, you will luckily hash postions with good score, in which you then can transpose later (after a longer path) and save some depth.
I actually think, good move ordering together with fail soft search will make you find it faster. In alpha-beta search, you will need to try bad moves anyway, which will get refuted by the next half-move. If you try the best refutatation first, and use fail-solft alpha-beta, the stored hash position may be good enough, to cause a cutoff later due to the hash. Also, you are certainly aware of the fact, that often many moves are able to refute a previous move. Something, that is not measured by typical move order statistics.
Regards,
Dieter

For this particular discussion, I think that we have to define "faster".
I have seen that sometimes you can get the solution at smaller depths but it takes much more nodes (and time, of course).
Regards,
Miguel

[Dieter Bürßner]

Geschrieben von: / Posted by: Dieter Bürßner at 09 December 2002 22:29:30:
Als Antwort auf: / In reply to: BigLion and fine 70 geschrieben von: / posted by: Sune Fischer at 09 December 2002 14:09:37:

the low hash cripples the TT of course.
I'm not pleased with frenzee here!
I seem to have a bug in the TT

For Yace thousand entries in the hash table are enough, to solve it fast.
Without hash it would probably need many hours (but seems possible. It needed about 10 minutes 5 ply inside the PV, and the branching factor was before the fail low around 2).
Yes. From some observations of Yace, even very bad moveordering does not hurt very much (the depth rises very fast, and depth 30 is no problem).
So, it seems you handle some cutoffs wrong (perhaps while storing, or while retrieving). If your code isn't too complicated yet, you should be able to find it rather fast - good luck.
One other idea (when you reach the depth faster). By *disabling* repetition detection, I get more consistent results. It might be a good idea for debugging/testing (because in this position, it should decrease the luck factor - see my argument in the other post).
Also, doing a material only evaluation might help testing here. And disabling any pruning/search extensions. With TTs, none of this should be needed to find the solution fast on current computer.
Regards,
Dieter

[Sune Fischer]

Geschrieben von: / Posted by: Sune Fischer at 10 December 2002 00:30:02:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Dieter Bürßner at 09 December 2002 22:29:30:

the low hash cripples the TT of course.
I'm not pleased with frenzee here!
I seem to have a bug in the TT

For Yace thousand entries in the hash table are enough, to solve it fast.
Without hash it would probably need many hours (but seems possible. It needed about 10 minutes 5 ply inside the PV, and the branching factor was before the fail low around 2).
Yes. From some observations of Yace, even very bad moveordering does not hurt very much (the depth rises very fast, and depth 30 is no problem).
So, it seems you handle some cutoffs wrong (perhaps while storing, or while retrieving). If your code isn't too complicated yet, you should be able to find it rather fast - good luck.
One other idea (when you reach the depth faster). By *disabling* repetition detection, I get more consistent results. It might be a good idea for debugging/testing (because in this position, it should decrease the luck factor - see my argument in the other post).
Also, doing a material only evaluation might help testing here. And disabling any pruning/search extensions. With TTs, none of this should be needed to find the solution fast on current computer.
Regards,
Dieter

Yes, it is very clearly a hashing problem, it should scream past ply 22 if everything was working.
Thanks, I found it
I had a hunch that it might be the replacement scheme, I never really did bother to test it properly.
I conducted a quick test by simply making it a "always-replace" scheme, it worked like a charm. Now Kb1 is found at ply 18 and a winning score shown at ply 22.
I get ply 29 in no time, even with only 13 MB mem. However ply 30 takes very much longer, then ply 31 is really fast again:

18 83 15 34831 1.Kb2 Ka8 2.Kc2 Kb7
18 83 15 36294 1.Kb1
19 83 18 54666 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd8 4.Kc2 Kd8
20 83 20 66815 1.Kb1 Ka8 2.Kb2 Kb8
21 83 22 79565 1.Kb1 Ka8 2.Kb2 Kb8 3.Kc2 Kb7 4.Kc3 Ka7 5.Kd2 Kb7 6.Ke2 Kc7 7.Kf2 Kd7 8.Kg3 Ke7 9.Kh4 Kf6 10.Kh5 Kg7 11.Kg5
22 113 25 100981 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Ke8 5.Kd3 Kf7 6.Kc4 Kg6 7.Kb5 Kh5 8.Kc6 Kg4 9.Kxd6 Kxf4 10.Kc5 Ke3 11.d6 Kf2
23 153 36 174968 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Ke8 5.Kd3 Kf7 6.Kc4 Kg6 7.Kb5 Kh5 8.Kc6 Kg4 9.Kxd6 Kxf4 10.Kc5 Ke3 11.d6 Kf2 12.d7
24 218 47 248760 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Kc7 5.Kd3 Kb7 6.Ke2 Kc7 7.Kf2 Kd7 8.Kg3 Ke8 9.Kh4 Kf7 10.Kg5 Kg7 11.Kxf5 Kf7
25 238 56 316924 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Kc7 5.Kd3 Kb7 6.Ke2 Kb8 7.Kf2 Kb7 8.Kg3 Kc7 9.Kh4 Kd7 10.Kg5 Ke8 11.Kxf5 Kf7 12.Kg5 Kg8 13.f5
26 223 79 476914 1.Kb1 Ka8 2.Kb2 Kb8 3.Kc2 Kc8 4.Kd2 Kd8 5.Kc3 Kc7 6.Kd3 Kb7 7.Ke2 Kb8 8.Kf3 Kc7 9.Kg3 Kb8 10.Kh4 Ka7 11.Kg5 Kb7 12.Kh5 Ka8
27 248 100 620356 1.Kb1 Ka8 2.Kb2 Kb8 3.Kc2 Ka7 4.Kd2 Kb8
28 248 129 832013 1.Kb1 Ka8 2.Kb2 Kb8 3.Kc2 Ka7 4.Kd2 Kb8 5.Ke2 Ka7 6.Kf2 Kb8
29 253 313 2038406 1.Kb1 Ka8 2.Kb2 Kb8 3.Kc2 Kb7 4.Kc3 Kc7 5.Kd3 Kb7 6.Ke2 Kc7 7.Kf2 Kd7 8.Kg3 Ke8 9.Kh4 Kf7 10.Kg5 Kg7 11.Kxf5 Kf7 12.Kg5 Kg7 13.f5 Kf7
30 253 9719 56126815 1.Kb1 Ka8 2.Kb2 Kb8 3.Kc2 Ka7 4.Kd3
31 253 9806 56738851 1.Kb1 Ka8 2.Kb2 Kb8 3.Kc2 Ka7 4.Kd3 Kb6 5.Ke2 Kc7 6.Kf2 Kd7 7.Kg3 Ke8 8.Kh4 Kf8 9.Kh5 Kf7 10.Kg5 Kg7 11.Kxf5 Kf7

Would you say this is acceptable?
It sort of runs into the wall on the 30th ply, time is almost 1 min 37 secs where ply 29 was only 3.13 secs - that is a very large branch factor if I'm not mistaken.
It's having trouble getting the score higher, too stupid to know about passed pawns and no push pawn extension enabled here so the score is flat for some plies.
I tried 130 MB, makes things go a little faster:

30 248 247 1522191 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Kd8 5.Kc3
31 248 335 2086536 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Kd8 5.Kc3 Kc7 6.Kd3 Kb6 7.Kd3
32 248 1054 6224547 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Kd8 5.Kc3 Kc7 6.Kd3 Kb7
33 253 1232 7319563 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Kd8 5.Kc3 Kc7 6.Kd3 Kb7 7.Ke2 Kc7 8.Kf2 Kd7 9.Kg3 Ke8 10.Kh4 Kf7 11.Kg5 Kg7 12.Kxf5 Kf7 13.Kg5 Kg7 14.f5 Kf7 15.f6 Kf8 16.Kg4 Kg8 17.Kf4
34 253 1553 9172580 1.Kb1 Kb7 2.Kc1 Kc7 3.Kd1 Kd7 4.Kc2 Kd8 5.Kc3 Kc7 6.Kd3 Kb7 7.Ke2 Kc8 8.Kf3 Kd8 9.Kg3 Ke8 10.Kh4 Kf7 11.Kg5 Kg7 12.Kxf5 Kf7 13.Kg5 Kg7 14.f5 Kf7 15.f6 Kf8 16.Kg6 Kg8 17.f7+
35 293 6909 39705322 1.Kb1 Kb7 2.Kc1 Kb8 3.Kc2 Kb7 4.Kc3 Ka7 5.Kd2 Kb8 6.Ke2 Kc8 7.Kf2 Kd8 8.Kg3 Ke7 9.Kh4 Kf6 10.Kh5 Kf7 11.Kg5

Ah, I thought of doing something similar though less dramatic, namely not storing repetition draws at all. Just like we have a special "range" for mate scores, it is possible to make a range for repetition draws.
To make them work in the natural framework of alpha-beta they have to be approximately 0. I've given it the first 1 bit of the score (I use milipawn scoring so I have a few more bits). If I get a score where score&1 then I do not hash that score because it's a repetition draw. Of course normal scores must have be of the form ~1&eval()
Didn't seem to have any measurable effect at all, so I guess this is not causing instability.
Yeah, "the drill", debugging is the only downside to chess programming
-S.

[Dieter Bürßner]

Geschrieben von: / Posted by: Dieter Bürßner at 10 December 2002 01:28:38:
Als Antwort auf: / In reply to: Re: BigLion and fine 70 geschrieben von: / posted by: Sune Fischer at 10 December 2002 00:30:02:

I had a hunch that it might be the replacement scheme, I never really did bother to test it properly.
I conducted a quick test by simply making it a "always-replace" scheme, it worked like a charm. Now Kb1 is found at ply 18 and a winning score shown at ply 22.
I get ply 29 in no time, even with only 13 MB mem. However ply 30 takes very much longer, then ply 31 is really fast again:
Would you say this is acceptable?

I think, a simple "replace allways" scheme is not bad. Replacing dependent on depth sounds much more sophisticated, but can show severe disadvantages, too. When I try to think about all the details, I can easily get a headache ...

Perhaps, no real problem. At this depth, you may see Qs on the board in "important" lines, and this will hurt (of course) the branching factor very much.
No doubt, it is orders of magnitude better, than using 30 seconds for reaching depth 19 (which really looked suspisious). Congratulations, for finding this so fast.
BTW. In this (and in many other positions) Yace could "hang" for a very long time at one depth (seeing the Q(s) on the board). When I changed from failing high with an open window at INFSCORE, to some scheme where the window is opened gradually, this went away. However, I am not sure at all, if this will help in practical play.
Cheers,
Dieter