Website founded by
Milan Velimirović
in 2006
22:38 UTC
| |
MatPlus.Net  Forum Fairies Take&Make helpmate |
| |
|
|
|
|
You can only view this page!
| | Page: [Previous] [Next] 1 2 3 4 | | (41) Posted by Jacques Rotenberg [Wednesday, May 16, 2012 09:21]; edited by Jacques Rotenberg [12-05-16] |
@ seetharaman kalyan
it seems that we don't agree on this peculiar point, it seems to me that the Winchloe point of vue is very understandable.
| | | (42) Posted by Alex Levit [Wednesday, May 16, 2012 19:10]; edited by Alex Levit [12-05-16] |
I think it's interesting to compose twins using two approach to Take&Make+Circe conditions.
Just trivial example:
 (= 2+2 )
Ser-#2
a)Take&Make+PWC
b)PWC+Take&Make
a)1.Rh8 2.Rxc8-h8#
b)1.Rb7 2.Rb8#
Upd. And one more trivial:
 (= 2+2 )
H#1.5
a)Take&Make+PWC
b)PWC+Take&Make
a)1...Rh8 2.Ka8 Rxd8-h8#
b)1...Ra7 2.Qc7 Ra8#
| | | (43) Posted by Geoff Foster [Thursday, May 17, 2012 00:10] |
I very much like the b) mate in the first example!
| | | (44) Posted by Alex Levit [Friday, May 18, 2012 03:10] |
Yet another example with four men only:
 (= 2+2 )
Ser-H#3
a)Take&Make+PWC
b)PWC+Take&Make
a)1.b1=Q 2.Qe1 3.Qxb4-b1[+wRe1] Rxb1-e1#
b)1.b1=B 2.Bd3 3.Bb5 Rb1#
| | | (45) Posted by Nikola Predrag [Friday, May 18, 2012 09:48] |
The latest 'example' looks more like an original. I'm not a fairy expert but I see here more content than in many originals published in various magazines.
| | | (46) Posted by Alex Levit [Friday, May 18, 2012 15:26] |
@Nikola I'm agree. The latest position is "real" chess problem, very simple of course.
I think this is interesting and may be new type of twins.
BTW what about Take&Make+maximummer/minimummer? Can WinCloe solve this:
 (= 2+2 )
#1 Take&Make WhiteMinimummer
C+ Popeye
| | | (47) Posted by Geoff Foster [Saturday, May 19, 2012 00:29] |
WinChloe gives no solution.
| | | (48) Posted by Nikola Predrag [Saturday, May 19, 2012 02:00] |
Then I'm no better than WinChloe, unless it is h#1.
| | | (49) Posted by Alex Levit [Saturday, May 19, 2012 02:35] |
1.Rxb1-h1# - zero length move. So again Maximummer+Take&Make not equal Take&Make+Maximummer.
| | | (50) Posted by seetharaman kalyan [Saturday, May 19, 2012 08:40] |
(Even assuming that the capture of the rook at b1 is possible, which is impossible considering that rook cannot move so far - Since it is a minimummer, is it really mate? :) Rh1 can now move only one square at a time, so no check ! :)
| | | (51) Posted by Nikola Predrag [Saturday, May 19, 2012 11:40] |
Hm, admittedly I did not consider a zero-lenght move but still, going there and back does not look like zero-path. It is clearly take-path + make-path (would not be possible if there was some interfering piece between b1 and h1), wR must go to b1 and back to h1. But the accepted conventions are stronger in human-given rules than any logic. Is there some official rule about the lenght of a move? What is the lenght of some Anticirce capture?
In an ordinary maximalist, King is in check even if the opponent can play longer moves, I expect the analogy in a minimalist.
| | | (52) Posted by Bojan Basic [Saturday, May 19, 2012 14:59] |
Actually, your interpretation (take-path + make-path) is, I believe, the third possibility (neither Popeye's, nor WinChloe's). Could somebody with WinChloe check whether it solves this?
 (= 2+2 )
#1 Take&Make + WhiteMaximummer
I predict that it finds the solution 1.Rxa3-a1 #, which is not consistent with Nikola’s interpretation (since, by that interpretation 1.Rxa3-a8 is a longer move).
| | | (53) Posted by Geoff Foster [Sunday, May 20, 2012 00:55] |
Yes, WinChloe finds 1.Txa3-a1!
| | | (54) Posted by Kevin Begley [Sunday, May 20, 2012 01:29]; edited by Kevin Begley [12-05-20] |
The conditions Maximummer/Minimummer are defined for moves (not for rebirths -- there is no reason to presume that rebirths must require maxi/mini constraints).
Remember: Take&Make is an anti-circe form (the capturing unit is reborn).
Regardless of a few additional special case constraints (which violate acirce precedent) -- such as prevention pawns on the 1st, castling w/ reborn units, etc -- this invention makes use of a well establish anti-circe idea.
The significant difference is, "Anti-Circe T&M" uses the standard moves of the captured units (regardless of constraints/conditions/legality upon those units), as a "modality" to determine rebirth.
The maxi-condition does NOT apply to "Anti-Super Circe" (nor should it apply here).
Much of the confusion about T&M is due to its unfortunate name (which fails to recognize that T&M is part of the acirce family -- the acirce family deserved proper credit).
At any rate, T&M has strictly defined rebirths, which are non-adaptable (by inclusion of other conditions).
If you want maxi/mini on rebirth, you need a new condition (something like: "Acirce Take&-Maxi/Mini-Make").
If you want additional constraints to apply to T&M, I wish you luck with that implementation (expect bugs galore in resolving conflicting constraints)!!
Popeye has the bug.
Composers should think twice before making T&M problems which employ 3 or 4 additional conditions.
The resulting output is non-reliable... to call such a problem C+ would constitute only a convenient, self-serving denial.
I know there are people who say a problem must stipulate which computer-rules it employs...
This is a completely misguided view -- for a number of reasons.
First, they don't really stipulate this info w/ their problem -- I am yet to see: "b) T&M type popeye v4.55" ...
Second, when there's no denying that popeye's implementation is incorrect (as is the case here), it is offensive to incorrectly apply the universal name (that's how you undermine any hope for universal fairy rules).
Composers should instead admit these bugs, and apply whatever additional constraints may be necessary (that's how you properly stipulate a problem)!
It pains me to say this (because it offers so much, for free!), but popeye is something of a hack.
It is not entirely the fault of the developers.
The responsibility to clarify these matters rests with all of us fairy enthusiasts (especially the inventors).
We need to convince the delegates to create a committee (including programmers, fairy enthusiasts, variant gamers, etc), which would have the authority to recommend sanctioning only clearly defined (and properly formed) fairy elements.
The delegates (or a sub-delegation of fairy enthusiasts) needs to vote on these matters (I would suggest 75% approval, as a cutoff).
Their approvals would then establish a universal fairy codex.
But, before you start voting thumbs up or down on the T&M condition (or whatever else you may personally like), you have to establish a clear set of fundamental requirements.
Start by defining the conditional families (circe family, acirce family, madrasi family, idle-mover family, etc).
Any sub-condition in this family should adhere not only to a standardized naming convention, but it should also adhere to the established fundamental rules of that family (otherwise, the deviation must be stipulated).
| | | (55) Posted by Ian Shanahan [Sunday, May 20, 2012 08:50]; edited by Ian Shanahan [12-05-20] |
This is where a Fairy Codex would indeed be useful. Here we have an example where the order in which Fairy conditions are given is important. (Another example is Monochrome and Circe.)
Personally, I think the convention should be that each condition takes precedence over those that follow it. Of course, this would be a nightmare for programmers: Popeye and WinChloe would need to be rewritten from scratch.
PS: Alex et al. Don't forget UltraMaxi and UltraMini! The latter might prove efficacious with your recent examples.
| | | (56) Posted by Jacques Rotenberg [Sunday, May 20, 2012 10:29]; edited by Jacques Rotenberg [12-05-20] |
@ Kevin
Take & Make is a very interesting condition by itself.
There is no need to describe it as an "anti-Circe form".
There is no need to see the "make" part as a rebirth.
This is just one of the ways T&M might be seen.
Till now, we could 3 see different grasps of T&M :
1 - the whole T&M move is a "normal" move as any other move.
This seems to be how the programmers of Popeye saw it.
2 - The "take" part is the move, the "make" part being just a consequence
- 2a the "make" part is a move-like displacement
- 2b the "make" part is a re-birth "anti-Circe" like.
This last one seems to be how C. Poisson saw it for WinChloe.
(3 - You may imagine a 4th way where the "make" part is the move, the "take" part being just a prelude)
I can't see any serious reason to discard one of these ways of understanding.
About maximum :
when a move concerns 3 square a -> b -> c you may calculate the distance in some different ways
a) <ab> + <bc>
b) <ac>
c) <ab> only
(you may imagine also d) <bc> only)
a) & b) could be coherent with popeye
b) & c) could be coherent with Winchloe - in fact, only c) is present for T&M
(...and d) could be coherent with 3)
| | | (57) Posted by Kevin Begley [Sunday, May 20, 2012 23:04]; edited by Kevin Begley [12-05-21] |
@ Jacques,
As usual, in reply, I wrote a whole book... but, I think I can edit it all down to this:
A rose by another other name is still a rose; and, though we don't need to call it a rose, it is in our best interest to do so -- for consistency, for precedent, for universality, and to intelligently define (and categorize) its essence.
If T&M is completely equivalent to a new "modality" within the Anticirce Family, then it should recognized as such.
>Take & Make is a very interesting condition by itself.
Agree 100% -- very good invention; already yielded a number of outstanding problems.
>There is no need to describe it as an "anti-Circe form".
>There is no need to see the "make" part as a rebirth.
>This is just one of the ways T&M might be seen."
Not a question of need -- it is beneficial to recognize precedent & properly identify it within the Acirce family.
There is a strong precedent for the Anti-Circe Family: it calls for a "rebirth" of the capturing unit, based upon a variety of "modalities"/rules.
If this is not the essence of Take&Make, the inventor has yet to explicitly elaborate a single, significant difference.
Can you claim an alternative "view" of the T&M mechanism -- as a non-rebirthing displacement?
Let's consider precedent...
There was no "need" to identify PWC (aka Platzwechsel Circe / Circe Exchange) as a member of the Circe-Family.
The inventor of this condition was adamantly opposed to the word "Circe" appearing in his invention -- he didn't "view" this to be a part of the Circe Family.
Maybe he didn't "view" the mechanism of his invention as a rebirth -- perhaps he saw this as an additional displacement of the captured unit, onto the vacated square.
The truth is, it doesn't matter how he viewed this -- the idea functioned in a manner completely equivalent to a member of the Circe Family, and therefore, this invention was not only anticipated by the Circe Family, it also belonged in a category with its siblings. Today, the problem community considers this (almost universally) to be a full member of the Circe Family.
This is a good thing -- nobody wants to remember the crazy names for 100 different Circe conditions (they want to look them up, under the Circe Family).
It's time some other conditions were renamed too (for example, black must check, ultraschachzwang, madcap zigzag, black prefers to check, etc etc etc -- these all belong within a single family).
ASIDE:
And, to really identify the PWC condition correctly, we should have gone a step further, and added the constraint "dummy pawns reborn onto 1st rank" (to whatever problems require this deviation, from the default Circe rule).
I'm presuming a standard rule for pawns reborn onto the 1st -- but, until delegates rewrite the FIDE rulebook (see 3.7a) to resolve this issue, that's my understanding.
There is no question that Take&Make borrows from Anti-Circe precedent -- same as PWC borrowed from circe!
FWIW: The Circe form of T&M has already been proposed -- I'm told some people are working on this...
But, some want to call it Anti-T&M -- this is backwards (it is T&M itself, which is the Anti-Form of the Circe Family)!
Already, some problems have ignored the inventor's intended rules (e.g., Nicolas Dupont won a well deserved 1st Prize for a T&M-PG20.0, which showed 8 pawns reborn onto the 1st rank -- a favorite theme of my own! -- but, the explicit rules of T&M forbid such a rebirth).
I would argue that experienced composers understood that T&M is essentially an Anti-Circe form, and they expected it to follow the standard rules of its proper family.
ASIDE:
To accommodate this problem, Win Chloe added a new condition (T&M Pawns authorized on their first rank).
Personally, I think it would have been better to call this "Anticirce T&M" (and provide an independent condition which prohibits pawn from being reborn onto the 1st rank -- let this define T&M).
You don't want a fairy condition which authorizes the default rule -- you want the reverse: that way, it can be independently and universally applied to other circe forms (maybe you want to prohibit pawns on the 1st in PWC).
It's easier to learn one consistent set of rules, which governs the entire family (inter-families, when possible, too); and, additional constraints should only be used to describe deviations.
Why would anyone want to avoid such a clear & easy categorization?
Inventors often prefer their own interpretation (even at the cost of ignoring precedent & consistency issues).
Sometimes they have good reason -- but, more commonly, it is purely a subjective favoritism, which erodes universality.
There is a misconception about the "economic penalty" associated with using additional constraint-options (note: additional conditions are another matter!), and this provides some unfortunate incentive for inventors to conglomerate (and conceal) additional constraints into one single fairy entity (giving rise to mega-conditions, and ill formed stipulations/aims).
To undo this damage, we need to provide inventors with an incentive to do what's right -- put the problem community's interests first, and provide clarity!
Additional constraints born out of interpretations (e.g., 1st rank pawn behavior) should not be considered a liability -- the goal is a clear & easy problem expression, without pretending that the "base form" is somehow more economical (that is not true).
That's why we see many cases where a single fairy condition has multiple interpretations -- nobody wants to accept that their preferred interpretation should require an additional constraint.
Everybody wants to cheat some poor judge's misguided penalty; and, since problems today are composed for awards, nobody cares to provide a fictional solver with a universal set of rules).
>Till now, we could 3 see different grasps of T&M :
>1 - the whole T&M move is a "normal" move as any other move.
>This seems to be how the programmers of Popeye saw it.
You have no evidence that the popeye programmers foresaw any of this -- more likely, they were unaware of the ambiguity.
If they had, why didn't they state the assumption in the popeye documentation?
Why didn't they notify the inventor, and problemists interested in this condition?
Face it, this was yet another popeye hack, which will backfire into yet another condition fracturing.
There are numerous examples of how this practice has resulted in an erosion of universal fairy elements.
The major bug in popeye is a failure to define their fairy elements.
It is not popeye's responsibility to define these things -- that belongs to fairy enthusiasts, and especially fairy inventors!
I guess some people expect the popeye team will do this for them; so, they pretend that popeye's implementation constitutes a definition -- albeit, one without words (it is what it is)!
This practice puts an unfair burden on the popeye team -- given all that the popeye team has provided us (for free!), you'd think more problemists would do their part to help them identify these issues... ha!
How can we do our part?
Many of us may disagree on what the base-class rules should be (for any number of issues) -- but, there is nearly a universal consensus that we need a fairy codex, which provides a clear & consistent set of rules.
Furthermore, almost everybody accepts that only the delegates have the legitimate authority to provide some sanction for a universal set of properly formed conditions.
But, not all delegates are cut-out to write these rules (especially those w/ no interest in fairies).
We really need to form a group, which will collaborate on the fairy rules (the same way the retro-sections of the codex were rewritten for the delegtes).
On controversial issues, we need to present the delegates (or some arbitrator faction they've approved) with a set of options (list the pros & cons), and allow them to vote.
There is so much disagreement, this would have to be done incrementally -- starting from the most fundamental definitions, axiomatically building toward a full fairy codex.
>2 - The "take" part is the move, the "make" part being just a consequence
>- 2a the "make" part is a move-like displacement
>- 2b the "make" part is a re-birth "anti-Circe" like.
>This last one seems to be how C. Poisson saw it for WinChloe.
I would wager that the heart of T&M lies in Christian's rebirth algorithm.
And, unless popeye is a complete hack, I would bet they did the same.
If programmers were provided a universal, axiomatic fairy codex, you would see almost no disagreement in problem solving tools -- and, when you did, you would know which one had the bug!
If you attempt to view the "make portion" (of a capturing unit's rebirth) as a move-displacement, then you immediately open a pandora's box of legal ramifications (for example, if a reborn pawn is actually seen as "move-displaced" two-squares forward, then we may immediately encounter a number of en passant opportunities, which were never expressly intended by the inventor).
You can't have your cake and eat it too.
The inventor is responsible to fully express the intent -- if this was the intent, where was it expressed?
Had he given credit to the Anti-Circe family (from which, there is no doubt, his idea was born), there would be no need for this discussion -- the matter would already be resolved (by a very familiar, consistent precedent).
If this was intended to be anything other than a new acirce modality, the inventor was obligated to fully express the differences (if it is the equivalent, then it belongs within its proper family -- just like PWC does).
>(3 - You may imagine a 4th way where the "make" part is the move, the "take" part being just a prelude)
I can imagine lots of alternative rules and interpretations; but, the inventor is responsible to state their intent.
If T&M was intended to function in any way unlike a member of the Anticirce Family (other than a few subjectively favored constraints, which were absorbed into one title), the inventor was obliged to explicitly state the paramount differences.
In its current form (many ambiguities, doesn't deal with base-class precedent issues, disagreement about implementations), there is no way a delegate could vote to sanction T&M.
Despite it being a very interesting (and promising) condition -- there are a number of issues which must be addressed.
>I can't see any serious reason to discard one of these ways of understanding.
Let's be clear: I have not discarded a single one of the alternative interpretations you described.
I would, however, discard the practice of allowing all of these interpretations to operate under a single name (T&M)!
Furthermore, if T&M is intended to function in every way equivalent to an Anti-Circe modality, I would require that it be properly identified (by name) as a member of this Family.
>About maximum :
>when a move concerns 3 square a -> b -> c you may calculate the distance in some different ways
>a) <ab> + <bc>
>b) <ac>
>c) <ab> only
>(you may imagine also d) <bc> only)
I don't care which one you chose -- but it's in our best interest to chose one, consistent, universal definition of "Maximummer," which in some way accommodates all multi-square moving units (e.g., double-grasshoppers, etc).
What should happen if an alternative interpretation is employed in a problem?
- it should identify itself (by name) as an alternative condition, under the Maximummer family,
- it should economically express the fundamental difference (e.g., not "type Kim Poser" -- instead use a description/mnemonic).
- it should be fundamental -- no additional conditions/constraints (those should always be expressed independently).
- it should not be a redundant form.
etc.
Assume we develop a very basic fairy codex, which eventually sanctions the Maximummer condition, and somebody proposes to sanction some multi-moving units.
So, you have some waiting period -- where TTs and discussions are encouraged -- to consider the impact upon any previously sanctioned elements (and upon any additional proposals).
Naturally, inventors would seek the delegates sanction (and put their ideas to the test in TTs).
This process encourages everyone to help discover ambiguities, precedent, deviations from standard form, etc.
The sooner these issues are identified, the better for everybody (perhaps especially the popeye team).
If the issues are not adequately addressed prior to the delegate vote (secret vote is best, to avoid rampant favoritism), you can still address the rules, and resubmit the proposal at a later meeting.
This is not a thumbs up/down regarding whether you happen to like an invention.
The idea is to establish/maintain a universal, and consistent fairy codex.
Eventually, maybe Maximummer is no longer just a fairy constraint -- it may become the parent class for a number of alternative, mult-move maxi sub-conditions...
In the interest of consistency, these sub-conditions might also apply to Minimummer -- and perhaps other conditions... (which, can be easily identified, if they are seen as members in a larger Family of conditions).
I rather doubt Maxi will blossom the way the Circe & Acirce families have, but this is the model for how you want to categorize these things.
| | | (58) Posted by Hauke Reddmann [Monday, May 21, 2012 16:45] |
It gets worse, Kevin. If you ever programmed one single program yourself,
you know: Even if an official definition is agreed upon all problemists,
and the Popeye (WinChloe, Alybadix, whatever) makers *wanted* to have
programmed it 1:1, that is not necessarily identical to what they
*did* program, de facto. ;-) Iron Rule of Programming: Bugs>0.
Hauke
| | | (59) Posted by Frank Richter [Monday, May 21, 2012 17:13] |
Well, regarding t&m all readers may refer to the "official" introduction by Hartmut Laue:
http://www.dieschwalbe.de/schwalbe229.htm#tnm
There is also a special statement to Circe.
| | | (60) Posted by Jacques Rotenberg [Tuesday, May 22, 2012 01:09] |
@ Franck
What do you mean ?
| |
Read more... | Page: [Previous] [Next] 1 2 3 4
MatPlus.Net Forum Fairies Take&Make helpmate |
|
|
|
ISC 2024
