Page 2 of 3
Re: Problem position using Scorpio Egbbs
Posted: Mon Mar 12, 2018 11:31 am
by Ross Boyd
Hey Graham, long time. Good to see you're still enjoying CC.
Yes, things move slowly round these parts... would you believe I have a (32bit only) compiled Basic program called Carnage.
It plays worse than TRACE. A 1 sec/move tournament now after 55 games so far puts it 150 Elo behind TRACE. So much for progress!
I can't believe how far the top engines have progressed over the last decade. Incredible.
Re: Problem position using Scorpio Egbbs
Posted: Mon Mar 12, 2018 11:53 am
by Ferdy
I tried Dirty in the first 2 pos and the results are the same as mine.
Code: Select all
C:\chess\engines\nobook\Dirty30APR2017>Dirty-apr-30-2017 -degbb C:\chess\egtb\egbb5N -egbb5men
Dirty Apr 30 2017
Copyright (C) 2008 Pradyumna Kannan, Andres Valverde & Fonzy Bluemers
Dirty is provided "as-is" without any express or implied warranty. In no event
will the authors be held liable for any damages arising from the use
of Dirty.
max cores 1
EgbbProbe 4.1 by Daniel Shawul
180 egbbs loaded !
setboard 8/8/8/4k3/7p/4K2P/6P1/8 w - -
d
White to Move
┌───┬───┬───┬───┬───┬───┬───┬───┐
8 │ │ │ │ │ │ │ │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
7 │ │ │ │ │ │ │ │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
6 │ │ │ │ │ │ │ │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
5 │ │ │ │ │ k │ │ │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
4 │ │ │ │ │ │ │ │ p │
├───┼───┼───┼───┼───┼───┼───┼───┤
3 │ │ │ │ │ K │ │ │ P │
├───┼───┼───┼───┼───┼───┼───┼───┤
2 │ │ │ │ │ │ │ P │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
1 │ │ │ │ │ │ │ │ │
└───┴───┴───┴───┴───┴───┴───┴───┘
a b c d e f g h
sd 5
go
1 0 0 2 g4
1 5068 0 5 Kd2
1 5089 0 7 Ke2
1 5105 0 9 Kf2
1 5112 0 12 Kf3
1 5112 0 12 Kf3
2 5010 0 20 Kf3 Kf5
2 5010 0 33 Kf3 Kf5
3 5087 0 68 Kf3 Kf5 Kf2
3 5087 1 96 Kf3 Kf5 Kf2
4 4998 1 174 Kf3 Kf5 Kf2 Kf4
4 4998 1 206 Kf3 Kf5 Kf2 Kf4
move Kf3
new
setboard 8/8/8/8/2p1P1k1/8/1P5K/8 b - -
sd 5
d
Black to Move
┌───┬───┬───┬───┬───┬───┬───┬───┐
8 │ │ │ │ │ │ │ │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
7 │ │ │ │ │ │ │ │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
6 │ │ │ │ │ │ │ │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
5 │ │ │ │ │ │ │ │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
4 │ │ │ p │ │ P │ │ k │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
3 │ │ │ │ │ │ │ │ │
├───┼───┼───┼───┼───┼───┼───┼───┤
2 │ │ P │ │ │ │ │ │ K │
├───┼───┼───┼───┼───┼───┼───┼───┤
1 │ │ │ │ │ │ │ │ │
└───┴───┴───┴───┴───┴───┴───┴───┘
a b c d e f g h
go
1 0 0 2 c3
2 0 0 15 c3 bxc3
2 0 0 28 c3 bxc3
3 0 0 48 c3 bxc3 Kf4
3 0 0 78 c3 bxc3 Kf4
4 0 0 117 c3 bxc3 Kf4 e5
4 0 0 172 c3 bxc3 Kf4 e5
move c3
Re: Problem position using Scorpio Egbbs
Posted: Mon Mar 12, 2018 12:12 pm
by Ross Boyd
Ferdy wrote:pedrox wrote:I have tested the position with DanaSah and with different distributions of egbb (egbb6men, egbb5men, egbb4men).
All with dll version 4.1 32-bit
The result is a win for Black.
Gaviota Tablebases indicates draw.
With dll 3.1 and egbb4men danasah has draw.
I took some games from Frank's page, extract some 5-men (around 12k pos) run 5-men sy egtb and add c0 op code in epd based on sy. Here are the resulting epd where 5-men egbb is different.
Could you verify it also?
Ferdinand, I get PRECISELY the same results as you posted...
Code: Select all
1. 8/8/8/4k3/7p/4K2P/6P1/8 w - - c0 "1/2-1/2"; fmvn 92; hmvc 0; egbb 4977; egbb-rb 4977;
2. 8/8/8/8/2p1P1k1/8/1P5K/8 b - - c0 "0-1"; fmvn 76; hmvc 0; egbb 0; egbb-rb 0;
3. 8/8/8/1k6/p7/P3K3/1P6/8 b - - c0 "1/2-1/2"; fmvn 154; hmvc 0; egbb -5051; egbb-rb -5051;
4. 8/8/8/B2B4/5kn1/7K/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 134; hmvc 0; egbb -5121; egbb-rb -5121;
5. 8/1B6/6k1/8/1n3B2/7K/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 73; hmvc 0; egbb -5139; egbb-rb -5139;
6. 8/2P4b/7k/8/1K5b/8/8/8 w - - c0 "1-0_1/2-1/2"; fmvn 92; hmvc 0; egbb 4866; egbb-rb 4866;
7. 6k1/5p2/6p1/6P1/8/8/5K2/8 b - - c0 "1/2-1/2"; fmvn 80; hmvc 0; egbb 4968; egbb-rb 4968;
8. 8/7p/1Pk5/4K1P1/8/8/8/8 b - - c0 "1-0"; fmvn 69; hmvc 0; egbb 0; egbb-rb 0;
9. 8/8/8/1k5p/5N2/2N2K2/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 49; hmvc 0; egbb -5267; egbb-rb -5267;
10. 8/5p2/1k4p1/6P1/2K5/8/8/8 w - - c0 "1/2-1/2"; fmvn 61; hmvc 0; egbb -5022; egbb-rb -5022;
11. 8/1p6/p3k3/P1K5/8/8/8/8 b - - c0 "1/2-1/2"; fmvn 111; hmvc 0; egbb 4864; egbb-rb 4864;
12. 8/8/8/4k2K/6p1/8/5P1P/8 b - - c0 "1/2-1/2"; fmvn 70; hmvc 0; egbb -5057; egbb-rb -5057;
13. 8/3k4/3n3B/8/1K6/3B4/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 102; hmvc 0; egbb -5139; egbb-rb -5139;
14. 6k1/5p2/8/3pPK2/8/8/8/8 b - - c0 "1/2-1/2"; fmvn 87; hmvc 0; egbb 4911; egbb-rb 4911;
15. 8/5k2/8/6K1/4B3/2B1n3/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 77; hmvc 0; egbb -5151; egbb-rb -5151;
16. 8/3kp3/5p2/3K1P2/8/8/8/8 b - - c0 "1/2-1/2"; fmvn 119; hmvc 0; egbb 4933; egbb-rb 4933;
17. 8/8/8/8/K5p1/5kP1/7P/8 b - - c0 "0-1"; fmvn 57; hmvc 0; egbb 0; egbb-rb 0;
18. 8/3k4/8/8/1n6/1n3P2/5K2/8 w - - c0 "0-1_1/2-1/2"; fmvn 106; hmvc 0; egbb -5191; egbb-rb -5191;
19. 8/8/1B3n2/4k3/8/8/3K4/3B4 b - - c0 "1-0_1/2-1/2"; fmvn 109; hmvc 0; egbb -5119; egbb-rb -5119;
20. 2k3B1/8/8/8/3B4/2K5/6q1/8 w - - c0 "0-1_1/2-1/2"; fmvn 105; hmvc 0; egbb -5125; egbb-rb -5125;
21. 8/1p6/p5k1/P7/3K4/8/8/8 b - - c0 "1/2-1/2"; fmvn 68; hmvc 0; egbb 4779; egbb-rb 4779;
22. 8/1K6/2n5/8/8/2k1B3/8/5B2 b - - c0 "1-0_1/2-1/2"; fmvn 69; hmvc 0; egbb -5127; egbb-rb -5127;
23. 8/8/6B1/3n4/3k2K1/8/3B4/8 b - - c0 "1-0_1/2-1/2"; fmvn 85; hmvc 0; egbb -5119; egbb-rb -5119;
Re: Problem position using Scorpio Egbbs
Posted: Mon Mar 12, 2018 12:33 pm
by Ferdy
Ross Boyd wrote:Ferdy wrote:pedrox wrote:I have tested the position with DanaSah and with different distributions of egbb (egbb6men, egbb5men, egbb4men).
All with dll version 4.1 32-bit
The result is a win for Black.
Gaviota Tablebases indicates draw.
With dll 3.1 and egbb4men danasah has draw.
I took some games from Frank's page, extract some 5-men (around 12k pos) run 5-men sy egtb and add c0 op code in epd based on sy. Here are the resulting epd where 5-men egbb is different.
Could you verify it also?
Ferdinand, I get PRECISELY the same results as you posted...
Code: Select all
1. 8/8/8/4k3/7p/4K2P/6P1/8 w - - c0 "1/2-1/2"; fmvn 92; hmvc 0; egbb 4977; egbb-rb 4977;
2. 8/8/8/8/2p1P1k1/8/1P5K/8 b - - c0 "0-1"; fmvn 76; hmvc 0; egbb 0; egbb-rb 0;
3. 8/8/8/1k6/p7/P3K3/1P6/8 b - - c0 "1/2-1/2"; fmvn 154; hmvc 0; egbb -5051; egbb-rb -5051;
4. 8/8/8/B2B4/5kn1/7K/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 134; hmvc 0; egbb -5121; egbb-rb -5121;
5. 8/1B6/6k1/8/1n3B2/7K/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 73; hmvc 0; egbb -5139; egbb-rb -5139;
6. 8/2P4b/7k/8/1K5b/8/8/8 w - - c0 "1-0_1/2-1/2"; fmvn 92; hmvc 0; egbb 4866; egbb-rb 4866;
7. 6k1/5p2/6p1/6P1/8/8/5K2/8 b - - c0 "1/2-1/2"; fmvn 80; hmvc 0; egbb 4968; egbb-rb 4968;
8. 8/7p/1Pk5/4K1P1/8/8/8/8 b - - c0 "1-0"; fmvn 69; hmvc 0; egbb 0; egbb-rb 0;
9. 8/8/8/1k5p/5N2/2N2K2/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 49; hmvc 0; egbb -5267; egbb-rb -5267;
10. 8/5p2/1k4p1/6P1/2K5/8/8/8 w - - c0 "1/2-1/2"; fmvn 61; hmvc 0; egbb -5022; egbb-rb -5022;
11. 8/1p6/p3k3/P1K5/8/8/8/8 b - - c0 "1/2-1/2"; fmvn 111; hmvc 0; egbb 4864; egbb-rb 4864;
12. 8/8/8/4k2K/6p1/8/5P1P/8 b - - c0 "1/2-1/2"; fmvn 70; hmvc 0; egbb -5057; egbb-rb -5057;
13. 8/3k4/3n3B/8/1K6/3B4/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 102; hmvc 0; egbb -5139; egbb-rb -5139;
14. 6k1/5p2/8/3pPK2/8/8/8/8 b - - c0 "1/2-1/2"; fmvn 87; hmvc 0; egbb 4911; egbb-rb 4911;
15. 8/5k2/8/6K1/4B3/2B1n3/8/8 b - - c0 "1-0_1/2-1/2"; fmvn 77; hmvc 0; egbb -5151; egbb-rb -5151;
16. 8/3kp3/5p2/3K1P2/8/8/8/8 b - - c0 "1/2-1/2"; fmvn 119; hmvc 0; egbb 4933; egbb-rb 4933;
17. 8/8/8/8/K5p1/5kP1/7P/8 b - - c0 "0-1"; fmvn 57; hmvc 0; egbb 0; egbb-rb 0;
18. 8/3k4/8/8/1n6/1n3P2/5K2/8 w - - c0 "0-1_1/2-1/2"; fmvn 106; hmvc 0; egbb -5191; egbb-rb -5191;
19. 8/8/1B3n2/4k3/8/8/3K4/3B4 b - - c0 "1-0_1/2-1/2"; fmvn 109; hmvc 0; egbb -5119; egbb-rb -5119;
20. 2k3B1/8/8/8/3B4/2K5/6q1/8 w - - c0 "0-1_1/2-1/2"; fmvn 105; hmvc 0; egbb -5125; egbb-rb -5125;
21. 8/1p6/p5k1/P7/3K4/8/8/8 b - - c0 "1/2-1/2"; fmvn 68; hmvc 0; egbb 4779; egbb-rb 4779;
22. 8/1K6/2n5/8/8/2k1B3/8/5B2 b - - c0 "1-0_1/2-1/2"; fmvn 69; hmvc 0; egbb -5127; egbb-rb -5127;
23. 8/8/6B1/3n4/3k2K1/8/3B4/8 b - - c0 "1-0_1/2-1/2"; fmvn 85; hmvc 0; egbb -5119; egbb-rb -5119;
Ahh OK thank you. You get the epd before my first edit.
Explanation of this typical c0 opcode value
18. 8/3k4/8/8/1n6/1n3P2/5K2/8 w - - c0 "0-1_1/2-1/2"; fmvn 106; hmvc 0; egbb -5191; egbb-rb -5191;
The 0-1 is a win for black but 1/2-1/2 under 50 move draw rule. In this specific case, egbb is right that black would win, but not under the 50 move draw rule.
Re: Problem position using Scorpio Egbbs
Posted: Mon Mar 12, 2018 4:08 pm
by Daniel Shawul
Hi Ross, Ferdinand
Thanks for reporting the issues.
It looks like these positions are cases where enpassant captures are involved in KPPkp bitbases. I belive i took care of those correctly but something maybe amiss when converting to the new format. I will take a closer look.
regards,
Daniel
Re: Problem position using Scorpio Egbbs
Posted: Wed Mar 14, 2018 5:28 pm
by Daniel Shawul
This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel
Re: Problem position using Scorpio Egbbs
Posted: Thu Mar 15, 2018 7:59 am
by Ross Boyd
Daniel Shawul wrote:This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel
No issue here with ignoring castling rights - I mean, how many games exist where 6 men are left and one side decides its time to castle?
OTOH, ep is not so rare. I suppose a workaround for now is to avoid probing when a pawn remains on its home sq with enemy pawn(s) ahead on the adjacent columns.
Does this mean all the bit bases will need to be regenerated - or just the tables that are KP?KP? ?
Ross
Re: Problem position using Scorpio Egbbs
Posted: Sat Mar 17, 2018 5:22 am
by Ferdy
Ross Boyd wrote:Daniel Shawul wrote:This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel
No issue here with ignoring castling rights - I mean, how many games exist where 6 men are left and one side decides its time to castle?
OTOH, ep is not so rare. I suppose a workaround for now is to avoid probing when a pawn remains on its home sq with enemy pawn(s) ahead on the adjacent columns.
After further searches on kp endings, encountered a position where possibility of e.p capture is none, that is after a 2-step pawn push.
[d]8/6p1/4k3/6p1/8/8/5PK1/8 w - - c0 "0-1"; fmvn 70; hmvc 0; Egbb 0;
Re: Problem position using Scorpio Egbbs
Posted: Sat Mar 17, 2018 9:39 am
by Ross Boyd
Ferdy wrote:Ross Boyd wrote:Daniel Shawul wrote:This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel
No issue here with ignoring castling rights - I mean, how many games exist where 6 men are left and one side decides its time to castle?
OTOH, ep is not so rare. I suppose a workaround for now is to avoid probing when a pawn remains on its home sq with enemy pawn(s) ahead on the adjacent columns.
After further searches on kp endings, encountered a position where possibility of e.p capture is none, that is after a 2-step pawn push.
[d]8/6p1/4k3/6p1/8/8/5PK1/8 w - - c0 "0-1"; fmvn 70; hmvc 0; Egbb 0;
But the potential remains for an ep to occur in later moves. That's what I meant by pawn on home square and enemy pawns ahead on adjacent columns - which is how it is in the above position...
Ross
Re: Problem position using Scorpio Egbbs
Posted: Sat Mar 17, 2018 9:46 am
by Ferdy
Ross Boyd wrote:Ferdy wrote:Ross Boyd wrote:Daniel Shawul wrote:This turns out to be a feature than a bug in the new bitbases
Enpassant, like castling, is not accounted for during generation of the bitbases. The older ones may have had enpassant though (my memory is blurred on this) since i had a different generator; it was not a retrograde generator like the one i have now.
Daniel
No issue here with ignoring castling rights - I mean, how many games exist where 6 men are left and one side decides its time to castle?
OTOH, ep is not so rare. I suppose a workaround for now is to avoid probing when a pawn remains on its home sq with enemy pawn(s) ahead on the adjacent columns.
After further searches on kp endings, encountered a position where possibility of e.p capture is none, that is after a 2-step pawn push.
[d]8/6p1/4k3/6p1/8/8/5PK1/8 w - - c0 "0-1"; fmvn 70; hmvc 0; Egbb 0;
But the potential remains for an ep to occur in later moves. That's what I meant by pawn on home square and enemy pawns ahead on adjacent columns - which is how it is in the above position...
Ross
Yes I understand it, what I am actually trying to address (my mistake) is that of all the positions that I found, this is the first time that e.p capture is not possible after a 2-step pawn push.