Zugzwangs you detect by using double nullmove.
if that would mean simply to allow two nullmoves in a row, I will give it a try. Did I have understood you correctly?
Reinhard.
Winboard Forum
Discussions (not only) about Xboard/Winboard, Computer Chess and Chess Programming
null move with only a minor
Moderator: Andres Valverde
33 posts
• Page 2 of 2 • 1, 2
Re: null move with only a minor
by Reinhard Scharnagl » 28 Jun 2005, 11:42
Hallo Vincent,
if that would mean simply to allow two nullmoves in a row, I will give it a try. Did I have understood you correctly?
Reinhard.
if that would mean simply to allow two nullmoves in a row, I will give it a try. Did I have understood you correctly?
Reinhard.
- Reinhard Scharnagl
- Posts: 608
- Joined: 01 Oct 2004, 08:36
- Location: Klein-Gerau, Germany
Re: null move with only a minor
by diepeveen » 28 Jun 2005, 11:58
Double nullmove as i posted it over the years can be done in many forms. Basic principle is to disallow the third nullmove in a row.
If you have a rook and i do not then of course we want to nullmove, despite that in a few testset positions it might take us more plies to find it.
99.9999% of all positions we see with just 1 piece on the board and the other guy 0, is complete nonsense.
So consequent symmetric rules is what you need.
For example here is what i do in DIEP for qsearch nullmove :
Always nullmoving of course searches the smallest tree.
if( !(rb->allflag&vlagschaak) ) {
if( !rb->eval )
rb->eval = Evaluate(rb->side);
/*
* N U L L M O V E
*
* eerst last plies pruning met behulp van nullmove indien niet schaak */
if( rb->eval > rb->alfa /* dus niet direct beta cutoff geven in qsearch */
&& rb->beta < MATEVALUE-1000 // om matethreats te zien, dan dus uitzetten!
&& (rb->realply <= 2 // avoid referencing unallocated memory
|| !((plist-2)->zet&move_nullmoves)
|| !((plist-1)->zet&move_nullmoves)
)
&& !(rb->threats&Threat_Mate)
&& (OwnsPawn[rb->side]+2 <= PieceCnt[rb->side]
|| (OwnsPawn[rb->side]+1 == PieceCnt[rb->side]
&& (OwnsRook[rb->side] ||
(OwnsQueen[rb->side] && Centrum[PieceList[rb->side][0]])
)
)
) // moet ook voor xside. is inconsequent nu
&& !(EngineFlags&engine_bruteforce) // fullwidth flag
&& rb->ply <= (64+4) /* R=3 */ ) {
So the above code isn't even consequent and still always finds zugzwangs.
Of course if you have many zugzwangs in a row in a position X, it needs a huge search depth to find it. Yet in practical game play i have hardly ever seen such positions.
In all others you search plies deeper in far endgame.
If you have a rook and i do not then of course we want to nullmove, despite that in a few testset positions it might take us more plies to find it.
99.9999% of all positions we see with just 1 piece on the board and the other guy 0, is complete nonsense.
So consequent symmetric rules is what you need.
For example here is what i do in DIEP for qsearch nullmove :
Always nullmoving of course searches the smallest tree.
if( !(rb->allflag&vlagschaak) ) {
if( !rb->eval )
rb->eval = Evaluate(rb->side);
/*
* N U L L M O V E
*
* eerst last plies pruning met behulp van nullmove indien niet schaak */
if( rb->eval > rb->alfa /* dus niet direct beta cutoff geven in qsearch */
&& rb->beta < MATEVALUE-1000 // om matethreats te zien, dan dus uitzetten!
&& (rb->realply <= 2 // avoid referencing unallocated memory
|| !((plist-2)->zet&move_nullmoves)
|| !((plist-1)->zet&move_nullmoves)
)
&& !(rb->threats&Threat_Mate)
&& (OwnsPawn[rb->side]+2 <= PieceCnt[rb->side]
|| (OwnsPawn[rb->side]+1 == PieceCnt[rb->side]
&& (OwnsRook[rb->side] ||
(OwnsQueen[rb->side] && Centrum[PieceList[rb->side][0]])
)
)
) // moet ook voor xside. is inconsequent nu
&& !(EngineFlags&engine_bruteforce) // fullwidth flag
&& rb->ply <= (64+4) /* R=3 */ ) {
So the above code isn't even consequent and still always finds zugzwangs.
Of course if you have many zugzwangs in a row in a position X, it needs a huge search depth to find it. Yet in practical game play i have hardly ever seen such positions.
In all others you search plies deeper in far endgame.
- diepeveen
- Posts: 116
- Joined: 28 Jun 2005, 01:09
- Location: Netherlands
Re: null move with only a minor
by diepeveen » 28 Jun 2005, 12:13
Actually at non qsearch nodes the nullmove is more consequent. I see there too to my amazement i do not nullmove when we have both 1 bishop 
/* Toevoegen NULLMOVE aan zettenlijst */
if( !(rb->allflag&vlagschaak)
&& (rb->realply <= 2
|| !((plist-2)->zet&move_nullmoves)
|| !((plist-1)->zet&move_nullmoves)
)
&& (OwnsPawn[0]+2 <= PieceCnt[0]
|| OwnsPawn[1]+2 <= PieceCnt[1]
|| (OwnsRook[0]+OwnsQueen[0] && OwnsRook[1]+OwnsQueen[1]))
// !! moet ook voor xside voor correcte zugzwang
&& rb->ply >= (64+5) /* R=3 */
&& !(EngineFlags&engine_bruteforce) ) {
rb->zetend->score = 200000;
rb->zetend->zet = move_nullmoves;//|move_noprune;
rb->zetend++;
}
/* Toevoegen NULLMOVE aan zettenlijst */
if( !(rb->allflag&vlagschaak)
&& (rb->realply <= 2
|| !((plist-2)->zet&move_nullmoves)
|| !((plist-1)->zet&move_nullmoves)
)
&& (OwnsPawn[0]+2 <= PieceCnt[0]
|| OwnsPawn[1]+2 <= PieceCnt[1]
|| (OwnsRook[0]+OwnsQueen[0] && OwnsRook[1]+OwnsQueen[1]))
// !! moet ook voor xside voor correcte zugzwang
&& rb->ply >= (64+5) /* R=3 */
&& !(EngineFlags&engine_bruteforce) ) {
rb->zetend->score = 200000;
rb->zetend->zet = move_nullmoves;//|move_noprune;
rb->zetend++;
}
- diepeveen
- Posts: 116
- Joined: 28 Jun 2005, 01:09
- Location: Netherlands
Re: null move with only a minor
by Reinhard Scharnagl » 28 Jun 2005, 12:24
Vincent,
I still have no nullmove pruning in the deescalation search (replaces quiescence search in Smirf), because I have started completely without any nullmove pruning and still use it very restrictedly.
We will see how the nullmove pruning usage might grow in Smirf or not.
Reinhard.
I still have no nullmove pruning in the deescalation search (replaces quiescence search in Smirf), because I have started completely without any nullmove pruning and still use it very restrictedly.
We will see how the nullmove pruning usage might grow in Smirf or not.
Reinhard.
- Reinhard Scharnagl
- Posts: 608
- Joined: 01 Oct 2004, 08:36
- Location: Klein-Gerau, Germany
Re: null move with only a minor
by Reinhard Scharnagl » 28 Jun 2005, 16:20
Vincent,
I have tested double nullmove, and it changed nearly nothing. Obviously I have a working different criteria for avoiding Zugzwang situations.
[diag]8/7Q/6p1/7p/6qk/8/7K/8 w - - 0 1[/diag]
FEN: 8/7Q/6p1/7p/6qk/8/7K/8 w - - 0 1
In this example actual internal Smirf beta produces:
00:33.5 End of thinking (mate found)
00:33.3 (20.01=) +M~012 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf6 Kh7 7.Kg3 Kg8 8.Kh4 g5+
00:32.4 (20.01+) +11.15 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf8+ Kh7 7.Qf7+ Kh6 8.Kg3 h4+
00:22.6 (19.01=) +10.49 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf8+ Kh7 7.Kg2 h4 8.Qf7+ Kh6
00:16.3 (18.01=) +10.49 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf8+ Kh7 7.Kg2 h4 8.Qf7+ Kh6
00:11.6 (17.01=) +10.44 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf8+ Kh7 7.Kg2 g5 8.Qf7+ Kh6
00:03.0 (17.01+) +5.229 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qg3+ Kf5 6.Qf3+ Kg5 7.Qf2 h4
00:02.4 (16.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:01.0 (15.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.6 (14.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.3 (13.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.2 (12.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.1 (11.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.0 (10.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.0 (04.01+) -2.553 1.Qe7+ (=/=) Qg5 2.Qe1+ Kg4 3.Qg3+ Kf5
How does your program?
Regards, Reinhard.
I have tested double nullmove, and it changed nearly nothing. Obviously I have a working different criteria for avoiding Zugzwang situations.
[diag]8/7Q/6p1/7p/6qk/8/7K/8 w - - 0 1[/diag]
FEN: 8/7Q/6p1/7p/6qk/8/7K/8 w - - 0 1
In this example actual internal Smirf beta produces:
00:33.5 End of thinking (mate found)
00:33.3 (20.01=) +M~012 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf6 Kh7 7.Kg3 Kg8 8.Kh4 g5+
00:32.4 (20.01+) +11.15 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf8+ Kh7 7.Qf7+ Kh6 8.Kg3 h4+
00:22.6 (19.01=) +10.49 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf8+ Kh7 7.Kg2 h4 8.Qf7+ Kh6
00:16.3 (18.01=) +10.49 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf8+ Kh7 7.Kg2 h4 8.Qf7+ Kh6
00:11.6 (17.01=) +10.44 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qf3 Kh6 6.Qf8+ Kh7 7.Kg2 g5 8.Qf7+ Kh6
00:03.0 (17.01+) +5.229 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe3 Qh3+ 4.Qxh3+ Kg5 5.Qg3+ Kf5 6.Qf3+ Kg5 7.Qf2 h4
00:02.4 (16.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:01.0 (15.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.6 (14.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.3 (13.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.2 (12.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.1 (11.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.0 (10.01=) +0.000 1.Qe7+ (=/=) Qg5 2.Qe4+ Qg4 3.Qe7+ Qg5 4.Qe4+ Qg4 5.Qe7+ Qg5 6.Qe4+ Qg4 7.Qe7+ Qg5 8.Qe4+ Qg4
00:00.0 (04.01+) -2.553 1.Qe7+ (=/=) Qg5 2.Qe1+ Kg4 3.Qg3+ Kf5
How does your program?
Regards, Reinhard.
- Reinhard Scharnagl
- Posts: 608
- Joined: 01 Oct 2004, 08:36
- Location: Klein-Gerau, Germany
Re: null move with only a minor
by Richard Pijl » 28 Jun 2005, 16:34
Baron without EGTB's has no problem to see that black loses it's queen:
First output line:
10(25)& 0:00.44 292393 +7.13 Qh7-e7 Qg4-g5 Qe7-e4 Qg5-g4 Qe4-e3 Qg4-f3 Qe3xf3 Kh4-g5 Kh2-g3 Kg5-h6 Qf3-f8 Kh6-h7 Kg3-f4
It takes a while before it finds a mate.
With EGTB's it sees a mate in 2.5 seconds, but strangely enough it has a draw score just before.
I'm using double nullmove.
Richard.
First output line:
10(25)& 0:00.44 292393 +7.13 Qh7-e7 Qg4-g5 Qe7-e4 Qg5-g4 Qe4-e3 Qg4-f3 Qe3xf3 Kh4-g5 Kh2-g3 Kg5-h6 Qf3-f8 Kh6-h7 Kg3-f4
It takes a while before it finds a mate.
With EGTB's it sees a mate in 2.5 seconds, but strangely enough it has a draw score just before.
I'm using double nullmove.
Richard.
-
Richard Pijl - Posts: 105
- Joined: 26 Sep 2004, 21:09
- Location: Minderhout, Belgium
Re: null move with only a minor
by diepeveen » 28 Jun 2005, 16:51
Oh well,
this is a 6 men so that already solves it, so it is not so relevant position.
i hope you realize how important that is.
But i turned off ALL egtb's, otherwise it is too easy to get from 0 ply and onwards a score indicating it will go mated.
Additional i run a debug version of diep single cpu which i use to debug eval and search always. So you can see also when it extends singular.
Remember this is a minimum of 20 fold slower than what plays at world champs 2005, and that at this position which you will never get at the chessboard in a computerchess game:
00:00 2558 998 0 (1) 4 (0,3) 7.187 Qh7-e7 Qg4-g5 (67) Qe7-e4 (67) Qg5-g4 (66) Qe4-e3 (66) Qg4-h3 (65) Qe3xh3 (64) Kh4-g5 (63)
00:00 8980 3682 0 (1) 5 (0,4) 7.187 Qh7-e7 Qg4-g5 (68) Qe7-e4 (68) Qg5-g4 (67) Qe4-e3 (67) Qg4-h3 (66) Qe3xh3 (65) Kh4-g5 (64)
00:00 28546 13417 0 (1) 6 (0,5) 7.187 Qh7-e7 Qg4-g5 (69)s Qe7-e4 (69) Qg5-g4 (68) Qe4-e3 (68) Qg4-h3 (67) Qe3xh3 (66) Kh4-g5 (65)
00:00 53600 30016 0 (1) 7 (0,6) 7.502 Qh7-e7 Qg4-g5 (70)s Qe7-e4 (70) Qg5-g4 (69)s Qe4-e3 (69) Qg4-h3 (68) Qe3xh3 (67) Kh4-g5 (66) Qh3-e3 (66) Kg5-f6 (65)
00:00 78916 56031 0 (1) 8 (0,7) 7.582 Qh7-e7 Qg4-g5 (71)s Qe7-e4 (71) Qg5-g4 (70)s Qe4-e3 (70) Qg4-f3 (69) Qe3xf3 (68) Kh4-g5 (67) Qf3-d5 (66) Kg5-h6 (65)
00:01 113230 120024 0 (1) 9 (0,8) 7.747 Qh7-e7 Qg4-g5 (72)s Qe7-e4 (72) Qg5-g4 (71)s Qe4-e3 (71) Qg4-f3 (70) Qe3xf3 (69) Kh4-g5 (68) Kh2-h3 (67) Kg5-h6 (66) Qf3-f4 (65) Kh6-g7 (64)
00:01 139780 273969 0 (1) 10 (0,9) 9.054 Qh7-e7 Qg4-g5 (73)s Qe7-e4 (73) Qg5-g4 (72)s Qe4-e3 (72) Qg4-f3 (71) Qe3xf3 (70) Kh4-g5 (69) Kh2-g3 (68) h5-h4 (67) Kg3-h3 (66) Kg5-h6 (67) Kh3xh4 (66) Kh6-g7 (65)
00:03 151827 601237 0 (1) 11 (0,10) 9.279 Qh7-e7 Qg4-g5 (74)s Qe7-e4 (74) Qg5-g4 (73)s Qe4-e3 (73) Qg4-f3 (72) Qe3xf3 (71) Kh4-g5 (70) Qf3-f8 (69) h5-h4 (68) Kh2-h3 (67) Kg5-h5 (66) Qf8-h8 (65) Kh5-g5 (64) Qh8-e5 (31) Kg5-h6 (65) Kh3xh4 (31)
00:07 159464 1269335 0 (1) 12 (0,11) 9.604 Qh7-e7 Qg4-g5 (75)s Qe7-e4 (75) Qg5-g4 (74)s Qe4-e3 (74) Qg4-f3 (73) Qe3xf3 (72) Kh4-g5 (71) Kh2-h3 (70) h5-h4 (69) Qf3-d5 (68) Kg5-h6 (67) Kh3xh4 (67) Kh6-h7 (66) Kh4-g5 (65)
00:17 174408 3094010 0 (1) 13 (0,12) 38.601 Qh7-e7 Qg4-g5 (76)s Qe7-e4 (76) Qg5-g4 (75)s Qe4-e3 (75) Qg4-f3 (74) Qe3xf3 (73) Kh4-g5 (72) Kh2-g3 (71) h5-h4 (70) Kg3-h3 (69) Kg5-h6 (70) Qf3-f6 (69) Kh6-h7 (68) Kh3xh4 (67) Kh7-g8 (67) Qf6xg6 (66) Kg8-f8 (65)
02:00 213453 25648518 0 (1) 14 (0,13) 40.151 Qh7-e7 Qg4-g5 (77)s Qe7-e4 (77) Qg5-g4 (76)s Qe4-e3 (76) Qg4-e2 (75) Qe3xe2 (74)s Kh4-g5 (74) Qe2-e5 (73) Kg5-h6 (72) Kh2-g3 (72) Kh6-h7 (71) Kg3-h4 (70) Kh7-g8 (69) Qe5-f6 (68) g6-g5 (67) Kh4xh5 (66) g5-g4 (66) Kh5xg4 (65)
So basically diep shows soon a > 25.xx score which means the position is mate in XXX, it just doesn't know how many moves till mate.
This without EGTBs turned on and at factor 20 slower conditions than world champs 2005 will have.
Note i do not extend mate, it doesn't try to find exactly mate in how much.
Just the right move matters.
Now let's compare it with a fullwidth search, the same debug version of diep. Please note in fullwidth search diep is doing LESS singular researches/extensions than when using nullmove.
00:00 175 7 0 (1) 1 (0,0) -2.935 Qh7-g8
++ h7-e7 procnr=0 terug=-2640 org=[-2935;-2934] newwindow=[-2935;520000]
00:00 766 46 0 (1) 1 (0,0) 0.000 Qh7-e7 Qg4-g5 (64) Qe7-b4 (31) Qg5-g4 (31) Qb4-e7 (31)
00:00 1200 72 0 (1) 2 (0,1) 0.000 Qh7-e7 Qg4-g5 (65) Qe7-b4 (31) Qg5-g4 (31) Qb4-e7 (31)
00:00 3283 197 0 (1) 3 (0,2) 0.000 Qh7-e7 Qg4-g5 (66) Qe7-b4 (66) Qg5-g4 (65) Qb4-e7 (31)
00:00 14766 886 0 (1) 4 (0,3) 7.187 Qh7-e7 Qg4-g5 (67) Qe7-e4 (67) Qg5-g4 (66) Qe4-e3 (66) Qg4-h3 (65) Qe3xh3 (64) Kh4-g5 (63)
00:00 34987 2799 0 (1) 5 (0,4) 7.187 Qh7-e7 Qg4-g5 (68) Qe7-e4 (68) Qg5-g4 (67) Qe4-e3 (67) Qg4-h3 (66) Qe3xh3 (65) Kh4-g5 (64)
00:00 71558 12165 0 (1) 6 (0,5) 7.582 Qh7-e7 Qg4-g5 (69)s Qe7-e4 (69)s Qg5-g4 (69)s Qe4-e3 (69)s Qg4-f3 (69) Qe3xf3 (68) Kh4-g5 (67) Qf3-d5 (66) Kg5-h6 (65)
00:00 103834 72684 0 (1) 7 (0,6) 7.857 Qh7-e7 Qg4-g5 (70)s Qe7-e4 (70)s Qg5-g4 (70)s Qe4-e3 (70)s Qg4-e2 (70) Qe3xe2 (69)s Kh4-g5 (69) Qe2-e6 (68) Kg5-h6 (68) Kh2-g3 (67) Kh6-g7 (66) Qe6-d7 (65) Kg7-h6 (64)
00:03 118724 433343 0 (1) 8 (0,7) 9.054 Qh7-e7 Qg4-g5 (71)s Qe7-e4 (71)s Qg5-g4 (71)s Qe4-e3 (71)s Qg4-e2 (71) Qe3xe2 (70)s Kh4-g5 (70) Qe2-f3 (70) h5-h4 (69) Kh2-h3 (68) Kg5-h6 (67) Kh3xh4 (66) Kh6-g7 (65)
00:20 126605 2640999 0 (1) 9 (0,8) 9.274 Qh7-e7 Qg4-g5 (72)s Qe7-e4 (72)s Qg5-g4 (72)s Qe4-e3 (72)s Qg4-g2 (72) Kh2xg2 (71) Kh4-g4 (70) Qe3-e4 (69) Kg4-g5 (69) Qe4-e5 (69) Kg5-g4 (69) Qe5-e6 (69) Kg4-g5 (68) Kg2-h3 (68) h5-h4 (68) Qe6-e5 (67) Kg5-h6 (66) Kh3xh4 (68) Kh6-h7 (67) Kh4-g5 (66) Kh7-g8 (65)
02:00 136728 16427871 0 (1) 10 (0,9) 9.284 Qh7-e7 Qg4-g5 (73)s Qe7-e4 (73)s Qg5-g4 (73)s Qe4-e3 (73)s Qg4-g2 (73) Kh2xg2 (72) Kh4-g4 (71) Qe3-e6 (70) Kg4-g5 (69) Kg2-h3 (69) h5-h4 (70) Qe6-e5 (69) Kg5-h6 (68) Kh3xh4 (68) Kh6-h7 (67) Kh4-g5 (66) Kh7-g8 (65)
07:55 134653 63980435 0 (1) 11 (0,10) 30.151 Qh7-e7 Qg4-g5 (74)s Qe7-e4 (74)s Qg5-g4 (74)s Qe4-e3 (74)s Qg4-g2 (74) Kh2xg2 (73) Kh4-g4 (72) Qe3-e6 (71) Kg4-g5 (70) Kg2-h3 (70) h5-h4 (71) Qe6-e7 (70) Kg5-f5 (69) Qe7-f7 (69) Kf5-g5 (68) Qf7-d5 (69) Kg5-f6 (69) Kh3xh4 (69) Kf6-g7 (68) Qd5-c6 (67) Kg7-f7 (66) Qc6-b7 (65) Kf7-f6 (65) Qb7-a8 (66) Kf6-f5 (67) Qa8-b7 (66) g6-g5 (67) Kh4-g3 (66) g5-g4 (66) Qb7-a8 (65)
See the advantage of double nullmove?
475 seconds versus 17
Vincent
this is a 6 men so that already solves it, so it is not so relevant position.
i hope you realize how important that is.
But i turned off ALL egtb's, otherwise it is too easy to get from 0 ply and onwards a score indicating it will go mated.
Additional i run a debug version of diep single cpu which i use to debug eval and search always. So you can see also when it extends singular.
Remember this is a minimum of 20 fold slower than what plays at world champs 2005, and that at this position which you will never get at the chessboard in a computerchess game:
00:00 2558 998 0 (1) 4 (0,3) 7.187 Qh7-e7 Qg4-g5 (67) Qe7-e4 (67) Qg5-g4 (66) Qe4-e3 (66) Qg4-h3 (65) Qe3xh3 (64) Kh4-g5 (63)
00:00 8980 3682 0 (1) 5 (0,4) 7.187 Qh7-e7 Qg4-g5 (68) Qe7-e4 (68) Qg5-g4 (67) Qe4-e3 (67) Qg4-h3 (66) Qe3xh3 (65) Kh4-g5 (64)
00:00 28546 13417 0 (1) 6 (0,5) 7.187 Qh7-e7 Qg4-g5 (69)s Qe7-e4 (69) Qg5-g4 (68) Qe4-e3 (68) Qg4-h3 (67) Qe3xh3 (66) Kh4-g5 (65)
00:00 53600 30016 0 (1) 7 (0,6) 7.502 Qh7-e7 Qg4-g5 (70)s Qe7-e4 (70) Qg5-g4 (69)s Qe4-e3 (69) Qg4-h3 (68) Qe3xh3 (67) Kh4-g5 (66) Qh3-e3 (66) Kg5-f6 (65)
00:00 78916 56031 0 (1) 8 (0,7) 7.582 Qh7-e7 Qg4-g5 (71)s Qe7-e4 (71) Qg5-g4 (70)s Qe4-e3 (70) Qg4-f3 (69) Qe3xf3 (68) Kh4-g5 (67) Qf3-d5 (66) Kg5-h6 (65)
00:01 113230 120024 0 (1) 9 (0,8) 7.747 Qh7-e7 Qg4-g5 (72)s Qe7-e4 (72) Qg5-g4 (71)s Qe4-e3 (71) Qg4-f3 (70) Qe3xf3 (69) Kh4-g5 (68) Kh2-h3 (67) Kg5-h6 (66) Qf3-f4 (65) Kh6-g7 (64)
00:01 139780 273969 0 (1) 10 (0,9) 9.054 Qh7-e7 Qg4-g5 (73)s Qe7-e4 (73) Qg5-g4 (72)s Qe4-e3 (72) Qg4-f3 (71) Qe3xf3 (70) Kh4-g5 (69) Kh2-g3 (68) h5-h4 (67) Kg3-h3 (66) Kg5-h6 (67) Kh3xh4 (66) Kh6-g7 (65)
00:03 151827 601237 0 (1) 11 (0,10) 9.279 Qh7-e7 Qg4-g5 (74)s Qe7-e4 (74) Qg5-g4 (73)s Qe4-e3 (73) Qg4-f3 (72) Qe3xf3 (71) Kh4-g5 (70) Qf3-f8 (69) h5-h4 (68) Kh2-h3 (67) Kg5-h5 (66) Qf8-h8 (65) Kh5-g5 (64) Qh8-e5 (31) Kg5-h6 (65) Kh3xh4 (31)
00:07 159464 1269335 0 (1) 12 (0,11) 9.604 Qh7-e7 Qg4-g5 (75)s Qe7-e4 (75) Qg5-g4 (74)s Qe4-e3 (74) Qg4-f3 (73) Qe3xf3 (72) Kh4-g5 (71) Kh2-h3 (70) h5-h4 (69) Qf3-d5 (68) Kg5-h6 (67) Kh3xh4 (67) Kh6-h7 (66) Kh4-g5 (65)
00:17 174408 3094010 0 (1) 13 (0,12) 38.601 Qh7-e7 Qg4-g5 (76)s Qe7-e4 (76) Qg5-g4 (75)s Qe4-e3 (75) Qg4-f3 (74) Qe3xf3 (73) Kh4-g5 (72) Kh2-g3 (71) h5-h4 (70) Kg3-h3 (69) Kg5-h6 (70) Qf3-f6 (69) Kh6-h7 (68) Kh3xh4 (67) Kh7-g8 (67) Qf6xg6 (66) Kg8-f8 (65)
02:00 213453 25648518 0 (1) 14 (0,13) 40.151 Qh7-e7 Qg4-g5 (77)s Qe7-e4 (77) Qg5-g4 (76)s Qe4-e3 (76) Qg4-e2 (75) Qe3xe2 (74)s Kh4-g5 (74) Qe2-e5 (73) Kg5-h6 (72) Kh2-g3 (72) Kh6-h7 (71) Kg3-h4 (70) Kh7-g8 (69) Qe5-f6 (68) g6-g5 (67) Kh4xh5 (66) g5-g4 (66) Kh5xg4 (65)
So basically diep shows soon a > 25.xx score which means the position is mate in XXX, it just doesn't know how many moves till mate.
This without EGTBs turned on and at factor 20 slower conditions than world champs 2005 will have.
Note i do not extend mate, it doesn't try to find exactly mate in how much.
Just the right move matters.
Now let's compare it with a fullwidth search, the same debug version of diep. Please note in fullwidth search diep is doing LESS singular researches/extensions than when using nullmove.
00:00 175 7 0 (1) 1 (0,0) -2.935 Qh7-g8
++ h7-e7 procnr=0 terug=-2640 org=[-2935;-2934] newwindow=[-2935;520000]
00:00 766 46 0 (1) 1 (0,0) 0.000 Qh7-e7 Qg4-g5 (64) Qe7-b4 (31) Qg5-g4 (31) Qb4-e7 (31)
00:00 1200 72 0 (1) 2 (0,1) 0.000 Qh7-e7 Qg4-g5 (65) Qe7-b4 (31) Qg5-g4 (31) Qb4-e7 (31)
00:00 3283 197 0 (1) 3 (0,2) 0.000 Qh7-e7 Qg4-g5 (66) Qe7-b4 (66) Qg5-g4 (65) Qb4-e7 (31)
00:00 14766 886 0 (1) 4 (0,3) 7.187 Qh7-e7 Qg4-g5 (67) Qe7-e4 (67) Qg5-g4 (66) Qe4-e3 (66) Qg4-h3 (65) Qe3xh3 (64) Kh4-g5 (63)
00:00 34987 2799 0 (1) 5 (0,4) 7.187 Qh7-e7 Qg4-g5 (68) Qe7-e4 (68) Qg5-g4 (67) Qe4-e3 (67) Qg4-h3 (66) Qe3xh3 (65) Kh4-g5 (64)
00:00 71558 12165 0 (1) 6 (0,5) 7.582 Qh7-e7 Qg4-g5 (69)s Qe7-e4 (69)s Qg5-g4 (69)s Qe4-e3 (69)s Qg4-f3 (69) Qe3xf3 (68) Kh4-g5 (67) Qf3-d5 (66) Kg5-h6 (65)
00:00 103834 72684 0 (1) 7 (0,6) 7.857 Qh7-e7 Qg4-g5 (70)s Qe7-e4 (70)s Qg5-g4 (70)s Qe4-e3 (70)s Qg4-e2 (70) Qe3xe2 (69)s Kh4-g5 (69) Qe2-e6 (68) Kg5-h6 (68) Kh2-g3 (67) Kh6-g7 (66) Qe6-d7 (65) Kg7-h6 (64)
00:03 118724 433343 0 (1) 8 (0,7) 9.054 Qh7-e7 Qg4-g5 (71)s Qe7-e4 (71)s Qg5-g4 (71)s Qe4-e3 (71)s Qg4-e2 (71) Qe3xe2 (70)s Kh4-g5 (70) Qe2-f3 (70) h5-h4 (69) Kh2-h3 (68) Kg5-h6 (67) Kh3xh4 (66) Kh6-g7 (65)
00:20 126605 2640999 0 (1) 9 (0,8) 9.274 Qh7-e7 Qg4-g5 (72)s Qe7-e4 (72)s Qg5-g4 (72)s Qe4-e3 (72)s Qg4-g2 (72) Kh2xg2 (71) Kh4-g4 (70) Qe3-e4 (69) Kg4-g5 (69) Qe4-e5 (69) Kg5-g4 (69) Qe5-e6 (69) Kg4-g5 (68) Kg2-h3 (68) h5-h4 (68) Qe6-e5 (67) Kg5-h6 (66) Kh3xh4 (68) Kh6-h7 (67) Kh4-g5 (66) Kh7-g8 (65)
02:00 136728 16427871 0 (1) 10 (0,9) 9.284 Qh7-e7 Qg4-g5 (73)s Qe7-e4 (73)s Qg5-g4 (73)s Qe4-e3 (73)s Qg4-g2 (73) Kh2xg2 (72) Kh4-g4 (71) Qe3-e6 (70) Kg4-g5 (69) Kg2-h3 (69) h5-h4 (70) Qe6-e5 (69) Kg5-h6 (68) Kh3xh4 (68) Kh6-h7 (67) Kh4-g5 (66) Kh7-g8 (65)
07:55 134653 63980435 0 (1) 11 (0,10) 30.151 Qh7-e7 Qg4-g5 (74)s Qe7-e4 (74)s Qg5-g4 (74)s Qe4-e3 (74)s Qg4-g2 (74) Kh2xg2 (73) Kh4-g4 (72) Qe3-e6 (71) Kg4-g5 (70) Kg2-h3 (70) h5-h4 (71) Qe6-e7 (70) Kg5-f5 (69) Qe7-f7 (69) Kf5-g5 (68) Qf7-d5 (69) Kg5-f6 (69) Kh3xh4 (69) Kf6-g7 (68) Qd5-c6 (67) Kg7-f7 (66) Qc6-b7 (65) Kf7-f6 (65) Qb7-a8 (66) Kf6-f5 (67) Qa8-b7 (66) g6-g5 (67) Kh4-g3 (66) g5-g4 (66) Qb7-a8 (65)
See the advantage of double nullmove?
475 seconds versus 17
Vincent
- diepeveen
- Posts: 116
- Joined: 28 Jun 2005, 01:09
- Location: Netherlands
Re: null move with only a minor
by Reinhard Scharnagl » 28 Jun 2005, 17:20
Hi Vincent,
I have a different view. Smirf's engine is about 56K actually in total. No look-up knowledge - pure program.
So does Smirf. It simply estimates the depth by using cached values at the end, as it does to reconstruct the PV line.
I have not said, double nullmove would be useless. I simply stated, that Smirf does not need it. It changes up to 0.2% in tested positions. Smirf before never had permitted multiple nullmoves in a row.
Reinhard.
this is a 6 men so that already solves it, so it is not so relevant position.
I have a different view. Smirf's engine is about 56K actually in total. No look-up knowledge - pure program.
Note i do not extend mate, it doesn't try to find exactly mate in how much.
So does Smirf. It simply estimates the depth by using cached values at the end, as it does to reconstruct the PV line.
See the advantage of double nullmove?
I have not said, double nullmove would be useless. I simply stated, that Smirf does not need it. It changes up to 0.2% in tested positions. Smirf before never had permitted multiple nullmoves in a row.
Reinhard.
- Reinhard Scharnagl
- Posts: 608
- Joined: 01 Oct 2004, 08:36
- Location: Klein-Gerau, Germany
Re: null move with only a minor
by diepeveen » 28 Jun 2005, 17:38
It doesn't matter 0.2% for you.
You should write: "i was not capable to remove my 1000 bugs so i didn't get it to work yet".
Verstanden?
You should write: "i was not capable to remove my 1000 bugs so i didn't get it to work yet".
Verstanden?
- diepeveen
- Posts: 116
- Joined: 28 Jun 2005, 01:09
- Location: Netherlands
Re: null move with only a minor
by Reinhard Scharnagl » 28 Jun 2005, 17:55
It doesn't matter 0.2% for you.
You should write: "i was not capable to remove my 1000 bugs so i didn't get it to work yet".
Verstanden?
Please explain.
Reinhard.
- Reinhard Scharnagl
- Posts: 608
- Joined: 01 Oct 2004, 08:36
- Location: Klein-Gerau, Germany
Re: null move with only a minor
by diepeveen » 28 Jun 2005, 18:16
If you give me email adress i will show you output of diep how you statistical significant can test things using testsets.
Instead of claim within 2 seconds it's 0.2%
A single signficant testset test here can take 1 week!
A single run comparing algorithm A with B takes 3 months (1000 games 40 in 2 or so)
my email adress is diep@xs4all.nl
too bad i can't find email adresses here, Vincent
Instead of claim within 2 seconds it's 0.2%
A single signficant testset test here can take 1 week!
A single run comparing algorithm A with B takes 3 months (1000 games 40 in 2 or so)
my email adress is diep@xs4all.nl
too bad i can't find email adresses here, Vincent
- diepeveen
- Posts: 116
- Joined: 28 Jun 2005, 01:09
- Location: Netherlands
Re: null move with only a minor
by Volker Pittlik » 28 Jun 2005, 18:46
diepeveen wrote:...too bad i can't find email adresses here...
And the email harvesters also can't. If you would like to send email to another member of the forum simply press the
button.
Volker
BTW: Yes there is a Readme and a FAQ: http://wbforum.volker-pittlik.name/viewtopic.php?t=210
-
Volker Pittlik - Posts: 1031
- Joined: 24 Sep 2004, 10:14
- Location: Murten / Morat, Switzerland
Re: null move with only a minor
by diepeveen » 28 Jun 2005, 19:12
the email button doens't work. it doesn't give me an email adress,
it just means i can type in text at the forum.
I want to ship entire excel files and if i cc to myself in the email window i still do not see the email adress of the recipient in my own email box.
Vincent
it just means i can type in text at the forum.
I want to ship entire excel files and if i cc to myself in the email window i still do not see the email adress of the recipient in my own email box.
Vincent
- diepeveen
- Posts: 116
- Joined: 28 Jun 2005, 01:09
- Location: Netherlands
33 posts
• Page 2 of 2 • 1, 2
Return to Programming and Technical Discussions
Who is online
Users browsing this forum: No registered users and 34 guests