ERROR in take&make with Circe Equipollents

[WalterL-wL]

PopEye handles take&make-moves as an "inseparable" combination of two part-moves. When this is combined with Circe Equipollents then PopEye 4.87 seems to imply that the capture square is located at the end of the make(!)-move. But any capture takes place at the end of the take(!)-move and only this take-move establishes the vector for the Equipollents move of the captured unit from the very square at the end of the take-move (this seems Laue's requirement, see e.g. f-223 and Schwalbe #229)! This issue is irrespective of PopEye's priority interpretation of make-move first, only then any Circe-move... A representation of this possible misinterpretation can be seen at JF No. 1687 . The source code is:

Popeye Windows-64Bit v4.87 (1631 MB) anfa ford SER-h#8 bedi Take&MakeSchach EquipollentsCirce Stei Weis Ke1 Sh6 Lf8 Bc4 Bd4 Schw Kh8 Bh7 Bc5 Bf3 Opti vari zugn Ende

PopEye seems to specify all the wrong rebirth squares with the wrong consequences for the solution!

[WalterL-wL]

July 18, 2022: I expanded my check of PopEye's respective treatment to Locust and the en passant capture (abbreviations in German notation, H=Locust, L=Bishop, B=Pawn).

a) At first I used "bedi Take&MakeSchach AntipodenCirce" in order to verify the general treatment of 4 variants; PopEye presents the following results: 1.wLa8×Sb7-a5,c5,d6,d8[+Sf3], correct: uniform capture square from take-move is b7-->f3; from b7 the capturer locates the make-move 1.wHa8×Sb7-a5,b4,d4,e5,e7,d8,b8,a7[+Sf3], correct: capture square for the captured S uniformly is b7-->f3; for the capturer (Locust!) the capture square (end of take-move) is c6(!) from where the capturer locates the make-move 1.d7-d6(!) c5×d6-d5[+Bh2], correct: (uniform) capture square for the captured Pawn is d6-->h2 (d6 also for the capturer, and equally the end square of the take-move!) 1.d7-d5(!) c5×d5[+Bh1=...], e.p. correct: (uniform) capture square for the captured Pawn is d5(!)-->h1 (in PopEye d5 also for the capturer!) - AND(!) for the capturer the end square of the take-move (according to Laue) is d6(!), from where the make-move is located!

--> PopEye handles AntipodenCirce in all these situations CORRECTLY! But what I noticed: There is a different results presentation by PopEye when e.p.-capture "1.d7-d5 c5×d5[...]" (here the make-move seems formally "integrated" into " c5×d5", actually it would be ... c5×d6(e.p.)-d5[...]) versus notation of a regular capture "1.d7-d6 c5×d6-d5[...] (here the make-move is "openly" presented)...!?!?!?

b) Now the same 4 situations with "bedi Take&MakeSchach EquipollentsCirce": In EquipollentsCirce the VECTOR is defined by departure square of "capturer" to capture square (Märchenschachlexikon: "...wenn man den Zugvektor des schlagenden Steins an das Schlagfeld legt"; BCPS: "the length and direction of the capture move is the same as the length and direction from the capture square to the rebirth square"; strategems: "the square which is the same distance and direction from the square of its capture, as was that square from the square upon which its captor commenced its move"; phénix: "la pièce capturée renaît sur la case symétrique de la case de départ de la pièce prenante, par rapport à la case où s’effectue la prise"; problemesis "la case telle que le mouvement de la pièce capturée est équipollent au coup joué par la pièce capturante"), ... thus, it's always defined as the end of the capture activity of the composite move (special treatments for Locusts and en passant capture!) - but it is NOT defined by the composite move (incl. make-move) itself to any(!) resulting end square of the make-move! But PopEye presents the following deviant results: 1.wLa8×Sb7-a5[+Sb4],c5[+Sd4],d6[+Se5],d8[+Se7], ERROR: the capture square still is b7, so the rebirth square should uniformly be [+Sc6] 1.wHa8×Sb7-a5[+Sb4],b4[+Sc3],d4[+Se3],e5[+Sf4], ,e7[+Sf6],d8[+Se7],b8[+Sc7],a7[+Sb6], ERROR: capture square for the captured S uniformly is b7, so the rebirth square should uniformly be [+Sd5] because the vector of the capturing move of the H is 2 diagonal squares a8-c6 --> b7-d5; for the capturer (H!) the capture square (as well as the end of the take-move) is c6-->... 1.d7-d6(!) c5×d6-d5[+Be6], ERROR: capture square for the captured Pawn is d6, so the rebirth square should actually be [+Be7] 1.d7-d5(!) c5×d5[+Be5], ERROR: capture square for the captured Pawn is d5, so the rebirth square should be [+Be6]!

--> Deduction: PopEye handles EquipollentsCirce in take&make wrongly!

[WalterL-wL]

On further probing this issue the problem seems to be of a different kind as first assumed. At first here it looked like the rebirth square vector from the take-move was attached to the end of the make-move. Now I rather think the whole of the compound move (take AND make) produces the vector here, and such it is attached to the capture square in order to find the rebirth square, once the make-move has been finished. If so, I'd like to figure out if this is the agreed upon conception, even though it seems to conflict with some definitions of Circe Equipollents where only a "capture" move (= equivalent to the take move "only") seems to define the vector?

And further, following H. Laue's own idea of Circe-take&make, where after the take-move primarily the Circe rebirth takes place, even before the make-move happened (although PopEye seems to not provide this variant). Would this not contradict the idea of a vector resulting out of the whole compound move from take AND make?

[dturevski]

@WalterL-wL

it seems to conflict with some definitions of Circe Equipollents where only a "capture" move (= equivalent to the take move "only") seems to define the vector?

Could you please provide these definitions and source references, as it seems to be the root of the problem here?

[WalterL-wL]

Could you please provide these definitions and source references, as it seems to be the root of the problem here?

thanks for your reaction, that's a helpful question. Unfortunately the answer is not that straightforward, I'll try as follows:

1. the important wording in the definitons (including a reference to main sources; also the Encyclopedia of Chess Problems by M. Velimirovic-K.Valtonen could be named) was already quoted in my second post here, in b) as part of the definition of the VECTOR, which is the core element insofar. In German "des schlagenden Steins", in English "the capture move" also "from the square upon which its captor", in French "départ de la pièce prenante" also "coup joué par la pièce capturante". All of those refer in one way or the other to "capture" as the central element. But, agreed, the French word "le coup" can be translated as capture move OR as simple move. So you have to go deeper into the background in order to assure the (supposed) intention of the inventor of Circe Equipollents.

2. Circe Equipollents was introduced by Roméo Bédoni in 1978 (source: https://echekk.fr/?Circe-equipollents). In contrast, H. Laue introduced take&make only around 2005 (source: Die Schwalbe, Heft 229, Februar 2008). It is impossible that the inventor of Circe Equipollents could have considered such compound moves as take&make, he only knew of "simple" capture moves, which should be the pattern to be followed by the vector! The same must be true for all even more current inventions since (make&take, anti-take&make, and all capture moves of a hopper with an "additional" non-capturing movement of the hurdle like Mulehopper, Bulgarian/Dobrich hopper, etc - definitions see Märchenschachlexikon of Schwalbe at https://www.dieschwalbe.de/lexikon.htm).

3. PopEye seems to only offer a variant where the make-move has priority over the Circe rebirth. At the end of such a compound take&make move you "know" already both part-moves. Just an interposed question: how would you map a move of Mulehopper or Bulgarian /Dobrich hopper to the vector? But this is not the only existing variant. H. Laue himself (later) qualified this variant as take&make-Circe, and introduced in contrast Circe-take&make, where the Circe rebirth has priority over the make-move! Here you would not even know what the make-move later "will be" when you already have to execute the Circe rebirth. It would actually be an impossibility, you only know the take-move so far!

I feel these are more than enough arguments against a representation of the whole compound move of take&make in the vector of Circe Equipollents. The inventor's "capture move" would thus be equivalent to the take-move only, here (the same for make&take)! And all (technical) problems are solved!

You might also counter with Circe Parrain, because there's also a vector. But there are fundamental differences. This vector is always applied on the NEXT "move" as an additional rebirth event, based necessarily on a capture (of any kind of move) in the previous move, in order to give rebirth to the captured stone from before. The current "move" defines the vector, even if the current move is a castling. All definitions (see the same sources as above) only specify it more or less as "on completion of the move following the capture move", also "un trajet équipollent à la pièce qui joue... (... an exact copy of that next move...)". Of course, the current move need not be a capture! If it's a take&make compound move you would have to map it as such to the vector, here it would not be consistent, may be not even possible to restrict it to the take-move only (may be there is no capture at all)...! But I still would not be able (yet) to clarify the Parrain vector when the current move is a move of a Mulehopper or Bulgarian /Dobrich hopper..., should you "omit" the part-move of the hurdle in the vector, as it's two different stones that move?

[dturevski]

How about this line of reasoning?

There are three squares in question: D = departure square, A = arrival square, C = square of the captured unit. We want to know if the inventor of the Circe Equipollents intended the DA vector or the DC vector. Of course, they couldn't have known about the Take&Make, but they surely have known of the other cases when A is not equal to C - the en passant capture (and locusts). The link you quote (https://echekk.fr/?Circe-equipollents, diagram D) shows that the intention was clearly DA, not DC, and thus popeye combines Equipollents/T&M consistently with the intention.

Of course one may have a variant of the Circe Equipollents where the rebirth square is determined by the DC vector, so it can be combined with T&M variants where rebirth precedes the make part.

And I don't really see what is the issue with the mulehoppers - it's still the DA vector, the hurdle displacement is irrelevant (this is consistent with how the castling is treated as a king move in eg maximummer).

[WalterL-wL]

How about this line of reasoning?

I did NOT say at all that it has to be DC, of course with en passant and Locust it is DA. I confirmed this opinion already CLEARLY in my second post here! But this does NOT prove at all that the make-move as part of a compound move has to be mapped in the vector - it's a completely different issue! And the fact that PopEye implemented only one variant of Circe interaction with take&make does NEITHER prove that this is the only one allowed logically, and with the other variant (priority to Circe) your view even results in an impossibility!

But I'd agree with your view on Mulehopper (etc): the move part of the hurdle should have nothing to do with the vector, because it's the move of a different stone. So, what happens with anti-take&make then? - it's also two different stones??? And when you quote castling with Maximummer (invented around 1913!?) you should also quote castling with the more current Circe Parrain, where it DOES have an impact.

Sorry, but I would see none of your comments as counter arguments...

PS: I don't know specific details about Maximummer. Yes, castling is a King's move. So, does only the move of the King have a length count from castling? I do not know. When it comes to counting the length of a move, then 0-0 counts length 4 and 0-0-0 counts length 5 (see: http://echekk.fr/?Longueur-des-coups, Roques: On fait la somme des longueurs des déplacements du Roi et de la Tour qui le jouent".

[dturevski]

Haha, yes I got the Maximummer part wrong, thanks! I'm not trying to prove anything, I'm just trying to understand if that is really an error in Popeye or just a possible interpretation (even though not the only one and may be even not the best one). You want locusts and T&M treated differently, popeye treats them uniformly, all clear.

[WalterL-wL]

You want locusts and T&M treated differently, popeye treats them uniformly, all clear.

Yes, of course! Even though PopEye might have programmed it in the same way (possibly: Locust captures like a Q in a take-move and then adds 1 square like in a make-move), these are two completely different issues with absolutely no common bedrock! The Locust is actually a simple one-mover and take&make is a compound-mover of two separate parts - with possible "interim" consequences (like Circe, or paralysis...)... I don't think this is a matter of interpretation only. THANKS!