[Retros] rights & ocassions /answering Andrew

Fri May 23 14:30:32 EDT 2014

Thanks Guus,

I certainly look forward to that publication, and continued reading, here.

Best Regards,
 Kevin

On Thu, May 22, 2014 at 3:15 AM, Guus Rol <grol33 at gmail.com> wrote:

> Hi Kevin,
>
> Thank you for your kind words!
>
> Actually these posts are preparations for writing the book I conceived
> years ago. I am a bit lazy and posting is a good way to build up content
> bit by bit. Also gives me the opportunity to correct all the nasty little
> errors in my posts. The aim of my book will not be to dramatically
> change current pratices but to generalize the case based conventions and
> logics enabling expansion into new areas and fairy types. There are still
> retroists who believe that retro-strategy just means "mutually exclusive
> castling rights".
>
> My original intent was to write a book on "a posteriori" logic, the
> fuzziest of logical species, but I soon found there is no point writing
> about the mountain top while there is no route to climb it. Now I do hope
> to deliver all the required equipment, including a Sherpa guide - if not on
> strike.
>
> I'd still appreciate some more critical comments from the community
> though. There is always choice in basic premises and there are lots of
> outposts yet unvisited. One of the nicest challenges is not to apply
> retro-theory to existing fairy types but to invent new fairy types fertile
> for retro composition (I know of one created for this purpose but forgot
> its name). These types need not deviate much from orthodox chess, small
> changes to castling or e.p. rules already open up new vistas. Andrew has
> shown what can be done with the inclusion of DR (dead reckoning) which is
> still orthodox. Nobody noticed, but one of my prize winning retros
> (involving 3R) is incorrect under the DR directive. Roberto's MDR (minimum
> deviation of the rules) is in need of updates after the last amendments in
> FIDE laws, but it can also profit immensely by the application of the
> standard retro-strategy and retro-variant logics - instead of its internal
> substitutes. And then there is the interesting task of rewriting Turnbulls
> "abominable problems" article into a 21st century version with workable
> conventions and logics. The author sins against his own conventions which
> is always a sign that something is not straight there. These are just a few
> examples of things to investigate and discuss and I predict this will
> generate intriguing new issues. Hopefully one day we can leave the
> returning discussions on "castling rights" and "repetitions" behind us
> (fascinating as they are).
>
> Best wishes, Guus Rol.
>
> On Wed, May 21, 2014 at 11:41 PM, Kevin Begley <kevinjbegley at gmail.com>wrote:
>
>> Guus,
>>
>> Thank you very much for a fascinating read!
>> I certainly did not appreciate the complexity of the matter, and I really
>> appreciate your taking the time to detail these issues.
>>
>> I hope this is not a dumb question, but I'll ask anyway:
>> Have you ever written a book on Retros?  Because, I think I'd really love
>> to read it -- especially if you help lead readers through the more complex
>> issues.
>>
>> Best,
>>  Kevin.
>>
>>
>>  On Wed, May 21, 2014 at 4:00 AM, Guus Rol <grol33 at gmail.com> wrote:
>>
>>>  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.
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20140523/71c24582/attachment.html>