[Retros] rights & ocassions /answering Andrew

[Guus Rol]

Hi Kevin,

I agree, the "static" metarule should apply to all rights evaluations,
including e.p., castling and all the attributes we don't know about yet in
the fairy types that are yet to be invented.

3R is the most complex of retro-active properties in the Orthodox field,
since an enormous amount of information bits may be required to record all
the possible diagrams + plus their counters which may be relevant
for future play. 50M is much easier, one counter tells all there is to know.

Fortunately, this is where the retro-logics come into play. The
(chosen) logic allows us to make simplified assumptions about the "real
world" (an imagined real world) . Nobody uses the "consequent
retro-variants" from one of my previous posts since handling all histories
is practically undoable..In fact, almost all diagrams have a history where
the diagram position is an  automatic draw. Zero options left to reach a
goal. There is however nothing wrong with the basic path splitter
of prA-logic - only maximized combinations of preferred retro-active
conditions - when solving retro-problems. With regard to 50M and 3R it
means we preferably assume the last move was a capture or Pawn move. Thus
we do not run the risk of colliding into these rules by surprise. If such
an assumptions is not legal we minimize as close to this assumption as
possible.

For the 3R case things can remain complicated as one or more full diagrams
may still need to be included in the "positional information". In actual
retro-problems the situation simplifies further since we can eliminate all
but one past(s) for which the problem solution is the same. Only when a
particular past collides with a particular solution, one is required to
generate a second branch and a second solution. This is how we arrive at
the partial retro-variants. You can e.g. see how this works in my own
problem R309 in Probleemblad (I think 2007). Though it is not to be solved
by retro-vartiants, the solution shows how and why this could have been a
prA-type diagram with relevant 3R attributes. The reason I object to prA is
not for its principles but because prA in de Codex was reduced to
handling cases instead of giving it status as a generic logic.

Justification. Why is it justified to reduce the history tree a priori in
prA/retro-variant type problems? Well, mainly because it is in line with
basic convention pholosiophy. By allowing you a license to castle, it says
you need not solve the diagram history without castling rights. So why
require it without necessity when 2 or more retro-active attributes are
involved? The second point is the concept that retro-variants are not
merely created to reflect different histories, but to demonstrate different
forward solutions. Every solution corresponds with a whole class of diagram
histories, there is no point in listing them individually. In some cases
the sharing of solutions between different histories will be considered a
defect but such judgement is on a higher level than discussed here.

Best wishes, Guus Rol.


On Wed, May 21, 2014 at 1:54 AM, Kevin Begley <kevinjbegley at gmail.com>wrote:

> Thanks Guus,
>
> I agree that units awaiting rebirth should be treated as a "static" and
> independent feature of the position (read: as bits of information necessary
> to characterize a position), regardless whether those rebirths can be
> executed.
> But, the same should be said of castling rights (or licenses) --
> regardless whether castling can be executed.
>
> I also agree that you can derive the minimal set of information (required
> to characterize any position) from a simulated branching analysis of all
> possible games, but once established, no part of that independent "static"
> information can be excluded from the comparison, in establishing 3R.
> You can not do branch-analysis on the fly, from any diagram position, to
> create a new minimal set of information criteria (the minimal set of
> information must be capable of describing every possible position).
>
>  In this informational approach, repetition implies nothing more than an
> exact match, spanning every single bit of information, from this minimal
> set necessary to describe any position.
>
>
> Best,
>  Kevin.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://one.pairlist.net/pipermail/retros/attachments/20140521/6abd7011/attachment.html>