Problem position using Scorpio Egbbs

Discussion of chess software programming and technical issues.

Moderators: Harvey Williamson, bob, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
User avatar
Ross Boyd
Posts: 114
Joined: Wed Mar 08, 2006 8:52 pm
Location: Wollongong, Australia
Contact:
Contact Ross Boyd

Re: Problem position using Scorpio Egbbs

Post by Ross Boyd » Mon Mar 12, 2018 10:31 am

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! :roll:

I can't believe how far the top engines have progressed over the last decade. Incredible.
Top
Ferdy
Posts: 4295
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Problem position using Scorpio Egbbs

Post by Ferdy » Mon Mar 12, 2018 10:53 am

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
Top
User avatar
Ross Boyd
Posts: 114
Joined: Wed Mar 08, 2006 8:52 pm
Location: Wollongong, Australia
Contact:
Contact Ross Boyd

Re: Problem position using Scorpio Egbbs

Post by Ross Boyd » Mon Mar 12, 2018 11:12 am

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;
Top
Ferdy
Posts: 4295
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Problem position using Scorpio Egbbs

Post by Ferdy » Mon Mar 12, 2018 11:33 am

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;

Code: Select all

c0 "0-1_1/2-1/2";
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.
Top
Daniel Shawul
Posts: 4051
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:
Contact Daniel Shawul

Re: Problem position using Scorpio Egbbs

Post by Daniel Shawul » Mon Mar 12, 2018 3:08 pm

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
Top
Daniel Shawul
Posts: 4051
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:
Contact Daniel Shawul

Re: Problem position using Scorpio Egbbs

Post by Daniel Shawul » Wed Mar 14, 2018 4:28 pm

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
Top
User avatar
Ross Boyd
Posts: 114
Joined: Wed Mar 08, 2006 8:52 pm
Location: Wollongong, Australia
Contact:
Contact Ross Boyd

Re: Problem position using Scorpio Egbbs

Post by Ross Boyd » Thu Mar 15, 2018 6:59 am

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? :D

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
Top
Ferdy
Posts: 4295
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Problem position using Scorpio Egbbs

Post by Ferdy » Sat Mar 17, 2018 4:22 am

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? :D

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;
Top
User avatar
Ross Boyd
Posts: 114
Joined: Wed Mar 08, 2006 8:52 pm
Location: Wollongong, Australia
Contact:
Contact Ross Boyd

Re: Problem position using Scorpio Egbbs

Post by Ross Boyd » Sat Mar 17, 2018 8:39 am

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? :D

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
Top
Ferdy
Posts: 4295
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Problem position using Scorpio Egbbs

Post by Ferdy » Sat Mar 17, 2018 8:46 am

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? :D

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.
Top
Post Reply

Return to “Computer Chess Club: Programming and Technical Discussions”