[Retros] Actualization of Retro-active states

Kevin Begley kevinjbegley at gmail.com
Tue Jul 8 15:50:21 EDT 2014


Very good chapter, Guus.



On Tue, Jul 8, 2014 at 11:31 AM, Guus Rol <grol33 at gmail.com> wrote:

> Dear retro friends,
>
> The most important aspect of the retro-active field - from the viewpoint
> of composer and solver - is the manifestation or actualization of
> retro-active states. At such a time an uncenrtainty regarding a
> retro-active state converts to a certainty. Example, the uncertainty of
> having "no castling rights" converts to the certainty of "having no
> castling rights". If you read the Codex plus its explications you would get
> the idea there is only one way in which a retro-active condition becomes an
> actual state in play and that is by executing the corresponding action
> move, i.e. castling or en passant. On closer inspection this appears quite
> a long way from the truth on actualizations.
>
> The Codex has a small vocubulary to support its view which centers around
> "permissions". The term "permission" is highly suitable to describe the
> basic conventions, like the "permission to castle" or "no permission to
> play e.p.", or even "no permission to draw on 3R unless proven". In
> their native forms, these "permissions" or "no permissions" take on a
> permanent and untouchable status in relation to certain isolated events on
> a chess board. The Codex has attempted to extend that idea of permanence in
> "permissions" to the "Retro Logics" but such hides the true nature of
> retro-active states once they become entangled. And so the Codex reads on
> mutually exclusive castling in RS (retro-strategy) "*whichever castling
> is executed first is deemed to be permissible". *So I ask you, what was,
> according to the Codex, the *state* of the "castling variable" before the
> castling move was executed? Its authors would probably answer: such doesn't
> matter a bit until the question of the castling action is raised. That is
> like saying: the law on gravity doen't matter until you drop a stone in a
> gravity field! There is and always was an enormous emphasis in the Codex on
> the *visible actions* and little attention for the invisible *states*,
> either "rights" or "no rights" alike. Not zero attention since even with
> the current Codex some state analysis is required for pRA variants.
>
> As I have argued in a previous chapter, the true nature of retro-active
> states is that they are variable, uncertain or even "superpositioned". The
> latter term is taken from quantum mechanics where several possible states
> are often considered to exist simultaneously. The state we experience only
> "actualizes" once measured and may be destroyed when measured directly. And
> therefore rather than going by the Codex term *"permissions"* which
> radiates an aura of permanence, I introduced the term *"license"* as an
> uncertain right revokable at any time of measurement. The license is a
> "state descriptor" which says (1) that a state is uncertain (2) what will
> happen to the state when one attempts to measure it directly. Example.
> where there is a license to castle then the state of the "castling
> variable" can go either way but will for an instance change to "castling
> right" when one attempts to castle.
>
> The focus on states and low visibility brings many more options for
> actualization in view than existing in the current Codex, even in or near
> Orthodox chess. Some of my favorite actualizations come from AP-logic.
> Rather than going with the move-oriented approach of the Codex - e.p. move
> justified by castling move - one can go one level up to the state oriented
> approach - e.p. actualization justified by castling actualization. Did you
> know one can construct this even in orthodox chess without ever playing an
> e.p. move or playing a castling move? Or you can mix them up in 4 different
> combinations of moves and indirect state changes. That result is only to be
> expected. Would not the law of gravity be more powerful than the action of
> a stone falling through it? Examples will be given when AP-logic is treated
> later.
>
> In the common RS field there are also pretty obvious examples of state
> actualizations with a low profile. Andrew at one time stated that one need
> not care about the state of an e.p. move since it could not be executed
> anyway (unless 100% certain). However in a reflex mate problem, not playing
> e.p. on the first move (which would have mated) results in a certainty of
> the state of "no e.p. right". The state actualization of "no e.p. right"
> may lead in turn to a further state actualization of an entangled "no
> castling right" which affects the remaining part of the solution. Another
> example is "temporary e.p. rights elevation" (better term than "rights
> promotion" which I used previously). If denying all e.p. rights in a
> diagram would result in "no proof game", then at least one e.p. move must
> be allowed. Actually, for lack of preference rules, all possible e.p. moves
> must be permitted at that point. An example on castling actualization
> without castling move:is by twice repeating a position with King and Rook
> on home squares, e.g. Ke1-e2,x,Ke1,-x,Ke2,x,Ke1,-x. Even though a castling
> right is destroyed, this sequence also proves a former state of "castling
> right". By  inference another castling right may have been lost with impact
> on the solution.
>
> These are not all the examples in orthodox chess and certainly not in
> fairy chess. The intent of this message is to indicate that there is a more
> generic way of strategically employing state actualizations than suggested
> by the "move permission" angle of the Codex. This will pave the way for
> understanding the Retro-logics in the fairy domain which could not never be
> captured by superficial case (by case) laws.
>
> Best wishes, Guus Rol.
>
> _______________________________________________
> 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/20140708/5323ee09/attachment-0001.html>


More information about the Retros mailing list