[Retros] rights & ocassions /answering Andrew

Guus Rol grol33 at gmail.com
Tue May 20 13:32:00 EDT 2014


Hi Kevin,

On the Circe Parrain. I do not know much about this fairy type, though I
have seen it in passing. The way it looks to me I'd go for the "statics"
again. The static element here seems to be: "which if any rebirth is on its
way? - including the destination square" This becomes an independent
positiional property irrespective of whether it is executable or not.
Though the situation is a bit more complex, the basic issue looks the same
as when an e.p. move cannot be executed due to a pin.Whatever the answer is
there, is also the answer to the "rebirth awaiting" question - in your
first example. Also required is the defaulting convention - in this fairy
type - that no rebirth awaits in any starting diagram unless provable.
Generally, every fairy type may need additional conventions. Which and how
many depends on the clarification or replacement of other conventions or
the connection to retro logics. E.g. in standard Circe, the 50M rule should
be modified to read: The 50M progress counter will increment by 1 at every
move that leaves the amount and form of all units on the board unchanged;
at 50 (or 100) it draws. Captures and locations of Pawns are no game
changers in standard Circe.

What the examples in fairy and orthodox types teach us is that all
inclinations towards dynamic right interpretations produce never ending
complexities. If the purpose of the 3R and 50M admin rules is to direct us
to stop wasting time and move on, then it achieves the opposite when it
forces us (and players) into analyzing obscure future paths. I would
suggest these meta-principles in this area to achieve more clarity:

1. All rights are determined by prior conditions, not by future developments
2. All rules and conventions (orthodox and fairy) support the feasibility
of the above
3. All admin rules (like 3R and 50M) are transparent to one another
4. A default condition is defined for every possible retro-active attribite
in a starting diagram - (in the context of the orthodox or fairy type
involved)
5. The applicable retro-logic must be identifiable in some unambiguous way.

Point 5 is easily missed since there is no clear recognition on how logics
are affected by the admin rules (3R and 50M). Take some of Plaksins
problems as an example. Whenever there is a competition between a castling
right and a 50M series - even before the collision - there is the option to
split into 2 maximized retro-variants, e.g.

a. 49 moves into 50M plus castling right
b. 1 move into 50M plus no castling right

This is absolutely valid and can deliver very attractive solutions. As an
example this solution scheme:

a. 1. 0-0 is a try since black will reply with care and claim a 50M draw
a. 1. "capturing move" "black reply" 2. 0-0 and win (first partial solution)
b. 1. 0-0? is illegal
b. 1. "the best move, no capture" "black reply" 2. 0-0? still illegal.
b. 1. "the best move, no capture" "black reply" 2. "the winning move"
(second partial solution)

This scheme is feasible when you consider that "a capturing move" is a
minus compared to "the best move" and "0-0" is a plus compared to "the next
best move". This is the success formula for 2 distinct solutions.

It also show how the use of retro logics as an independent dimension expand
the domain for retro-active compositions!

Best wishes, Guus Rol


On Fri, May 16, 2014 at 2:02 AM, Kevin Begley <kevinjbegley at gmail.com>wrote:

>  >"In most fairy genres (including the fairy genre 'orthodox'), if the
> king loses castling rights, the rook rights are completely useless. Only in
> genres in which the right can be regained, the 6-bit representation should
> be used."
>
> Do not establish a rule which has no universal application.
> Our first priority is not to a singular fairy genre (this is textbook
> "orthodocentrism").
>
> We can establish a universal rule, which covers all conditions.
>
> Furthermore, allow me to explain why it is necessary to reiterate my call
> for a definition of the intended resolution(s).
>
> Consider the following position, in Parrain Circe (captured units are
> reborn the same distance and direction from the capture square, as the move
> following capture)...
> white: Kb1 Sh1
> black: Kg2 Rh2 Ra7
>
> There are no castling rights (4-bits, 6-bits, or otherwise).
> There are no en passant rights.
> Black is on the move (an important consideration of position, which I
> failed to previously mention).
> There was no unit captured on the previous move (thus none awaits
> rebirth).
>
> The final point is very important -- the position in some Circe forms will
> depend upon previous moves (where units are awaiting rebirth).
>
> Now, suppose the game continues as follows:
>
> 1... Kxh1 2.Kc1 (no rebirth -- because the rebirth square is offboard --
> at i1, if you will)
> 2... Kg2 3.Kb1
> 3... Kh1.
>
> Question #1:  has a repetition occurred here?
> Note: the final diagram seems identical to the diagram seen after
> completion of black's first move.
>
> I would argue that no repetition has occurred, because the information
> necessary to describe the position has never been identical (btw: this is
> the default rule that most everyone -- including the vast majority of
> programmers -- would presume to hold for orthodox chess, too: is all
> positional information identical?).
>
> In Circe Parrain, the information needed to store the position, following
> black's first move, must also contain a rebirth (even though that rebirth
> might not -- and might never -- be possible).
> There is no rebirth information contained in the final position, and
> therefore, it can not be considered identical.
>
> Apparently, a few refuse to accept this;  but, I will now demonstrate that
> these holdouts can be split into two groups, according to how they answer
> the following question:
>
> Question #2: If there were no black Rook on a7, and the game score remains
> unchanged, has a repetition occurred.
>
> Note the difference: now, black does have the possibility of rebirth (2.
> Ka1 would cause a rebirth of the white Knight, on to g1), but does not
> elect to make use of it.
>
> This is why it is necessary to ask the holdouts to provide a definition
> for their intended rule modification -- the onus is on them to present a
> clear suggestion (it is not the burden of others to pry an intelligent
> definition from them).
>
> And, to those who would assert that the possibility of legal rebirth
> changes the position, I have a message...
>
> You are clearly unaware of the folly of your pursuit: you are using future
> legality (can black King move to a1), to determine the present state of a
> position;  and, the future legality depends upon the present state of a
> position, therefore, you are using cyclical logic (and a cyclical failure
> is inevitable).
>
> That is folly, in the extreme -- and I know, because I've investigated
> numerous examples of this cyclical failure, in the Rex Multiplex condition.
> Unfortunately, I can't begin to demonstrate the extreme folly of this
> pursuit, until somebody provides us all with a clear definition.
>
>
>
> On Thu, May 15, 2014 at 12:34 PM, Retros Probleemblad <
> retro at probleemblad.nl> wrote:
>
>> On 05/15/2014 08:37 PM, Kevin Begley wrote:
>>
>>> In the interest of simplification of fairy chess rules, I would argue
>>> that the 6-bit representation should be preferred.
>>>
>>
>> In most fairy genres (including the fairy genre 'orthodox'), if the king
>> loses castling rights, the rook rights are completely useless. Only in
>> genres in which the right can be regained, the 6-bit representation should
>> be used.
>>
>>
>> Joost
>> _______________________________________________
>> Retros mailing list
>> Retros at janko.at
>> http://www.pairlist.net/mailman/listinfo/retros
>>
>
>
> _______________________________________________
> Retros mailing list
> Retros at janko.at
> http://www.pairlist.net/mailman/listinfo/retros
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://one.pairlist.net/pipermail/retros/attachments/20140520/40f14a28/attachment.html>


More information about the Retros mailing list