[Retros] rights & ocassions /answering Andrew

[Kevin Begley]

Show me a definition (including a motivation --- one that explains how the
hopelessness of a King's casting differs from that of a Pawn which never
promotes/captures/sacrifices,...), plus one good reason, and I will be
willing to consider this a serious topic.
Until then, it remains, at best, a diversion.


On Tue, May 6, 2014 at 9:10 AM, Kevin Begley <kevinjbegley at gmail.com> wrote:


> Your 5 good reasons are all quite sound; but insignificant, I'm afraid,

> when you're up against a logic that is willing to forsake a definition.

>

> It's a ram thing -- it has zero to do with chess.

>

>

>

> On Tue, May 6, 2014 at 8:55 AM, Andrew Buchanan <andrew at anselan.com>wrote:

>

>> Dear Roberto,

>>

>> This issue is not *quite* as academic as angel sex - it does affect the

>> soundness of certain chess compositions. :o)

>>

>> The chess programming position, which seems to pass there without

>> controversy, is given at:

>> http://chessprogramming.wikispaces.com/Repetitions

>>

>> Now, a SPOILER ALERT :o) for those enjoyably busy reading through the

>> matplus discussion of this issue, located at:

>> http://matplus.net/start.php?px=1399373473&app=forum&act=posts&tid=1235

>> The climactic denouement of the thread is when I quoted senior FIDE

>> arbiter

>> Stewart Reuben in May 2013 [my annotations added in square brackets here]:

>>

>> "Geurt Gijssen and I differ over the repetition rule and castling. His

>> view

>> will continue to hold sway for the new version [of the Laws] (probably now

>> no change [in that draft version] until 1 July 2013 [when it will be

>> ratified, going live in 1 July 2014]).

>> Position Qa4 Ka1. ke8, rh8. The laws state that the right is not lost to

>> castle until the king moves. Thus 1...kf7 2 Qf4 ke8 2 Qa4 is a new

>> position.

>> I think that is wrong. We can look into the future and know black will

>> never

>> castle.

>> But Rh2 Pg2 Kf1. ka2 pf4. 1 g4+ Kh3 2 Rh3+ Ka2 3 Rh2+ is the same

>> position.

>> Black could never capture en passant.

>> To my mind this is illogical. The two possibilities [i.e. castling & en

>> passant] should be the same.

>> But it is the law and I have no idea whether it has ever arisen. So I do

>> not

>> care too much."

>>

>> So Stewart is unhappy the fact that castling and en passant approach

>> things

>> differently. I think the position that castling *rights* are what counts

>> will survive until 2017. However, then those "troublemakers" :o) who want

>> to

>> change the criterion for castling may have a champion in Stewart Reuben.

>> Stewart is a very nice guy, but is focused on the game, and I don't think

>> he

>> feels any particular duty to problemists.

>>

>> OK, so why should castling rights rather than opportunity be the driver?

>> (1) It's the status quo. Why change such a tiny thing, which will force

>> programmers to alter their core code, if they want to continue to capture

>> the exact rules of chess (as many will)? (And some problemists may be

>> inconvenienced as well.)

>> (2) It's simplest. Castling rights are just 4 bits of information, 4

>> characters in FEN, which change only when a king or rook moves for the

>> first

>> time. Easy to compute; easy to consult.

>> (3) According to Guus Rol, there was a FIDE ruling at the time of Fischer.

>> (It would be nice to see that.)

>> (4) Guus also points out that dynamic interpretations may lead to

>> undecidable positions. Although he invokes retro strategy and proof games,

>> remember that we are talking about games of chess, where none of these

>> retro

>> concepts are available. So his argument is even stronger.

>> (5a) An interesting question is: why can't we just use the FEN notation to

>> represent the state for en passant? Recall: FEN records the en passant

>> target square in algebraic notation. If there's no en passant target

>> square,

>> this is "-". If a pawn has just made a two-square move, this is the

>> position

>> "behind" the pawn. This is recorded regardless of whether there is a pawn

>> in

>> position to make an en passant capture. (Clearly the rank number, 3 or 6,

>> is

>> redundant.) But it would be absurd to use the FEN square as an indicator

>> of

>> en passant capability - there may be no neighbouring pawn to make the

>> capture. But once we've opened the door to that concern, then why stop

>> there? One king may be in check, or there may be direct or indirect pins.

>> So

>> rather than invent some halfway house, where SOME but not ALL necessary

>> criteria are checked, the approach taken is that whether a position is

>> different or not depends on whether the pawn can capture legally.

>> (5b) So to revert to castling: if we feel that there is need for

>> "consistency" between castling convention and en passant approach, and the

>> en passant approach is hard to modify, then why not change the castling

>> approach? Well, *which* castling approach? We could either look at whether

>> the rooks can castle right now, or whether they could castle some time in

>> the future? This question doesn't come up in en passant, which is

>> now-or-never.

>>

>> So that's 5 good reasons to leave the current rule well alone.

>>

>> I have just seen a new tomelike email from Guus arrive in my inbox, so I

>> think I will send this one.

>>

>> Thanks,

>> Andrew.

>>

>> -----Original Message-----

>> From: retros-bounces at janko.at [mailto:retros-bounces at janko.at] On Behalf

>> Of

>> raosorio at fibertel.com.ar

>> Sent: 06 May 2014 06:10

>> To: retros at janko.at

>> Subject: [Retros] rights & ocassions /answering Andrew

>>

>> Hi Andrew,

>>

>> Long time without these "sex of the angels" discussions.

>>

>>

>> I hope you find the MatPlus discussion useful. To my mind, it was

>> conclusive, and filled the key hole in the following strategy

>> *********************************************************************

>> I find it useful indeed. I'm afraid I did not read it carefully enough to

>> realyze that conclusive side.

>>

>>

>> For example the chess programming community have converged on a

>> standard set of rules to judge any engine, and this community agrees with

>> the arbiters as to how to work castling and en passant in the context of

>> 50M

>>

>> & 3Rep.

>> *********************************************************************

>> this is really new for me. Could you please indicate where to find this

>> standard

>> set of rules? All of the present discussion should start from there.

>>

>>

>> There is a Golden Principle in this, that conventions *only* come in to

>> remove areas of ambiguity where we cannot deduce using information in the

>> stipulation and logic what must have happened. Any convention which does

>> not

>>

>> respect the Golden Principle is worded in too strong a way, and must be

>> toned down because it's taking us into Fairy Chess.

>> *********************************************************************

>> Simple and common sense.

>>

>> I think the codex writers had a better lunch, with more wine, than the

>> laws writers.

>> ********************************************************************

>> Yes, but I suspect it was at the same restaurant.

>>

>> Best wishes,

>> Roberto

>>

>> Hi Roberto,

>>

>> I hope you find the MatPlus discussion useful. To my mind, it was

>> conclusive, and filled the key hole in the following strategy.

>>

>> There may be always fun ways to interpret wordings of rules. But there is

>> surely a vanilla set of rules which is how they are intended to be. This

>> intention is not so difficult to discern, because the rules of chess are

>> so

>> simple. For example the chess programming community have converged on a

>> standard set of rules to judge any engine, and this community agrees with

>> the arbiters as to how to work castling and en passant in the context of

>> 50M

>>

>> & 3Rep. I agree with this general interpretation. This allows us to play

>> chess unambiguously. This programming interpretation incidentally bounds

>> the

>>

>> scope of chess: it excludes touch move, the clock, responses to errors

>> etc.

>> Basic robust vanilla chess.

>>

>> Now, and only now, do problemists come into the discussion. There is a

>> minimal set of conventions which is then needed to make the transfer from

>> vanilla game to problem. These fall into two areas:

>> (1) history. Just looking at a diagram is not sufficient to see what moves

>> may be legal, due to who's move, castling, ep, number of times position

>> has

>> repeated, number of moves since last . We have now reasonably

>> comprehensive

>> understanding of how conventions will work in this area.

>> (2) decision-making. what can players do? stipulation type (#, h#, s#...)

>> gives a lot of information, but also decisions about whether draws of

>> various kinds would be proposed or rejected.

>> There is a Golden Principle in this, that conventions *only* come in to

>> remove areas of ambiguity where we cannot deduce using information in the

>> stipulation and logic what must have happened. Any convention which does

>> not

>>

>> respect the Golden Principle is worded in too strong a way, and must be

>> toned down because it's taking us into Fairy Chess.

>>

>> A few random remarks to finish...

>> - I remember encountering Sergio Orce in the old days in

>> france-echecs.com.

>> I hope he is well, wherever he is.

>> - I think the codex writers had a better lunch, with more wine, than the

>> laws writers.

>> - Actually, it's not a problem with the writing, but the subsequent

>> editing.

>>

>> Nobel Laureate Ernest Hemingway said: "The first draft of anything is

>> s**t."

>>

>>

>> Thanks & all the best,

>> Andrew.

>> _______________________________________________

>> 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://www.pairlist.net/pipermail/retros/attachments/20140506/aa15ef73/attachment.htm>