Cornered Rook in bicolour castling

[WalterL-wL]

The execution of a "real" bicolour castling (make&take) in PopEye seems to forget (or delay) the move of the cornered rook towards infield.

[thomas-maeder]

Please post a minimal (length, fairy elements) problem with the solution that you expect and the solution that you expect.

[WalterL-wL]

Unfortunately I cannot find a "simpler" presentation of the problem as with make&take+AntipodenCirceRI (see also my e-mail of June 5, 2020, and my article in feenschach # 242 "Auffälligkeiten, ...Schema G"). Basically, after a bicolour castling (Laue, make&take) the involved rook moves to the SAME position as in regular castling. The following "twin" seems to prove that PopEye correctly handles the general situation, but doesn't "know" the rook should be there (f8), as follows (in German notation):

in a) PopEye correctly finds the mate h#1, because after 1.f7-f6, and the following capture on e7 by a white bicolour castling move (resulting in legal rebirth of the sK on the FREE square a3), the then required Antipoden re-rebirth squares for the sK (e7, e6, f6) are all occupied, so no free rebirth square after the following second capture means mate. There is nothing the sK or any other black stone can do to prevent the following final capture with white's next move (by wBb3 or wTc1 under make&take) due to all occupied re-rebirth squares.

in b) an ADDITIONAL sHf5 (Heuschrecke) can move instead of the sK and "clear" the re-rebirth square (e7) for rebirth of the sK with the move 2.Hf5-g7×Se7-d7[-], so the following second capture of the sKa3 by wBb3 is no longer a problem, the Antipoden re-rebirth square e7 is now empty! PopEye correctly shows there is NO solution for h#1
(for a different move like 2.Hf5-d6×Se7-d7[-] see following).

in c) replacing sHf5 with sHe4 SHOULD completely change the whole situation! As square e6 is occupied by a sB, the H could - theoretically - only remove the wS with a move 2.sHe4-c5,d6×Se7-f8[-]. PopEye seems to WRONGLY execute this move and shows the same "no solution" as in b), BUT this move is impossible. So, there SHOULD be the same solution like in a), because f8 is actually occupied by the black rook, so the re-rebirth square e7 CANNOT be cleared by the H with this move at all!.

Supposedly PopEye does not respect the shifting of the sT[h8] in a bicolour castling, and executes the indicated 1.f7-f6 Se8×e7[+sKa3]# rather like 1.f7-f6 Se8-g8×e7[+sKa3]#, and NOT like 1.f7-f6 0-0×e7[+sKa3]# (with the involvement of the black rook)...???

--> input was:
anfa
bedi Make&TakeSchach AntipodenCirce RexInklusive
ford H#1
Stei Weis Ke1 Tc1 Se8 Ba4 Bb3 Bb4 Schw Ke7 Th8 Be6 Bf7
Opti vari
Zwilling hinzufuegen schwarz Hf5
Zwilling hinzufuegen schwarz He4
Ende

--> output was:
...diagram...
h#1 6 + 4
Circe Antipoden RexInklusive
Make&TakeSchach

a)

1.f7-f6 Se8*e7[+sKa3] #

b) +sHf5

c) +sHe4

Loesung beendet. Zeit = 0.250 s

[WalterL-wL]

sorry, my mistake in notation: all 3 times I wrote "1..." you should read as "2." - CORRECTED!

[thomas-maeder]

Thanks for elaborating!

I have tried to simplify the example, but "unfortunately", Popeye's behavior looks correct:

begin
pieces white se8 black kh6 rh8
stipulation x1
condition make&take circe antipodes rexincl
option nowk
twin move h6 e7
end

gives:

a)
1.Se8h6[+bKe8] + x !
1.0-0h6[+bKe8] + x !

b) bKh6-->e7
1.0-0*e7[+bKe8] + x !

Popeye does consider castling with the capturing knight and the rook.

BUT: it no longer does if we add a white king to the position (on any square, not just e1)!!

Move the black king to e7 and replace the twinning by

twin add white ke5

and you get

a)
1.0-0*e7[+sKa3] x !

b) +wKe5
1.Se8*e7[+sKa3] x !

[WalterL-wL]

Thanks! I tried "your" code, and yes, there are two different(!) solutions in "your" a), and "your" b) shows a correct ...0-0...-notation of the solution. But WHY?...So, I modified as you suggested "my" original code as follows:

Popeye Windows-64Bit v4.85 (1733 MB)
anfa
bedi Make&TakeSchach AntipodenCirce RexInklusive
ford H#1
Stei Weis Tc1 Se8 Ba4 Bb3 Bb4 Schw Ke7 Th8 Be6 Bf7
Opti OhneWk
Zwilling hinzufuegen weiss Ke5
Ende

and the OUTPUT for the "twins" was unitary, but formally incorrect (as expected):

h#1 (5 + 4)
Circe Antipoden RexInklusive
Make&TakeSchach

a)

1.f7-f6 Se8*e7[+sKa3] #

b) +wKe5

1.f7-f6 Se8*e7[+sKa3] #

Loesung beendet. Zeit = 0.234 s

As you can see there again is NO indication of castling (...0-0...). And actually I have no idea which influence the "absence" of wK should have to the solution??? Sorry, but I am unsure if your answer is a "confirmation" of my problem, or if it's your opinion that PopEye behaves correctly?

Basically, your simplification of the code seems to have little to do with the original problem, arising from the "RE-rebirth" of the bK (yes/no - depending on the "potential" moves of the "additionally" introduced Locust). And it still seems a fact that PopEye definitely shows the WRONG solution in "my" twin c), because the capture of the bK there is final (rebirth yes, but directly into the mate, with no escape from it by subsequent re-rebirth!). And the only logical explanation (to me) seems the missing shifting of the cornered bR - what ever might be the reason for that in the given situation... Do you agree? Thanks!

[WalterL-wL]

Maybe an explanation for the difference with "option nowk" could be that castling (i.e. synchronous move of K and R) generally can only "happen" in the SAME colour, and only "against" a K of DIFFERENT colour. In contrast, here a bicolour castling involves the R of the OWN colour against his OWN K! Maybe the existing program code cannot handle this situation and "refuses" the castling for the ENSUING setup of the stones in the diagram (but NOT for "calculating" the castling in the moment it happens)?

[thomas-maeder]

I have found the reason. It's a bit tricky to remember which takes are possible due to a castling make. It worked for all the examples that I had used for testing so far, but not for your combination of fairy elements.

[thomas-maeder]

Fixed for 4.87