Website founded by
Milan Velimirović
in 2006
0:01 UTC
| |
MatPlus.Net  Forum Internet and Computing Discrepancy in rules of SuperCirce Rebirth? |
| |
|
|
|
|
You can only view this page!
| | | (1) Posted by Kevin Begley [Wednesday, May 18, 2011 07:50]; edited by Kevin Begley [11-05-18] | Discrepancy in rules of SuperCirce Rebirth?
I discovered a SuperCirce discrepancy between popeye and Win Chloe, which *might* impact the computer validation of some problems -- especially problems which employ Locust type pieces, or pair this condition with various forms of AntiCirce.
The question is whether super-rebirth options should be assessed prior to (or following) removal of the captured unit.
Note: this is not merely a question of which fairy condition has "priority" -- the two programs function differently with no other fairy elements present:
Scheme:
 (= 3+2 )
h#1 SuperCirce 1.1 or 2.1?
Popeye shows the following two solutions (which I expected to be legal), whereas Win Chloe only shows the former solution:
1.b7-b6 a5*b6 [+bPb5] #
1.b7-b5 a5*b6 ep. [+bPb5] #
I find it difficult to believe that Win Chloe can be correct here, given that the white player may push b5 to b6, prior to capture.
However, confusion is so pervasive in problem chess (where even basic terms can not be agreed upon), one can never be certain of anything!
If anyone can quote the specific rules (originally laid out by the inventor) to govern this special case, please post here.
If this possibility was not treated, perhaps there's some good joke problems to be had here.
If we don't laugh at our own failures, our rules don't succeed.
| | | (2) Posted by Juraj Lörinc [Wednesday, May 18, 2011 09:05] |
For me that's just another example of ambiguities appearing in the combination of conditions from wide Circe family and fairy pieces of Locust family.
Well known is a question of rebirth square for a fairy piece captured by locust in Circe. Should it be reborn on the file where it has been placed before the capure? Or according to the arrival square of locust making the capturing move?
Popeye and WinChloe used to differ in this case, but something in my mind whispers that at least one of programs has already added option to choose (maybe these whispers are just trying to fool me...).
Personally I do not prefer any of possibilities, just use any of them as appropriate and then I state the convention I have used. Of course, this happens only rarely. That is why the definite resolution of Kevin's new ambiguity is not necessary in my view.
| | | (3) Posted by Kevin Begley [Wednesday, May 18, 2011 11:39]; edited by Kevin Begley [11-05-18] |
Juraj,
>For me that's just another example of ambiguities appearing in the combination of conditions ...
Nope -- as stated above, the discrepancy occurs with SuperCirce alone (no combination necessary).
>Well known is a question of rebirth square for a fairy piece captured by locust in Circe....
Yes, that too is an interesting special case, but it is entirely unrelated to this issue (which stems from whether the captured unit is removed before/after rebirth options are considered, in SuperCirce).
>Personally I ... just use [whichever possibility is] appropriate and then I state the convention I have used.
Funny -- how would you stipulate your convention, if you were unaware of any discrepancy?
Even if you were blessed with the ability to uncover ambiguities on the fly (but never needed to use your gift), when a program agrees with your expectations (and reports C+), how will you overcome the assumption that its bug is the official rule?
How will you determine when it is time to explain your "alternative rules," in the absence of any "default rules?"
Do you imagine vast space will be provided, beneath the diagram, for this endeavor (given the intricacies of some special cases)?
>Of course, this happens only rarely.
It may happen rarely, but then who bothers to test C+ problems with another solving tool?
Not all of us can afford the luxury of another tool.
And, who -- other than these programs -- would bother to notice?
I notice, because I actively search for ambiguities in the rules.
>That is why the definite resolution of Kevin's new ambiguity is not necessary in my view.
You offer as a solution that we should ignore entirely a clear ambiguity in the rules, but at the same time, you pretend you'll also fix this ambiguity, on the fly (without ever needing to bother making yourself aware of it)!
I have friends in politics who would not have the courage to offer, so boldly, a plan to "do nothing" (about a real problem, with a simple solution).
The point is, imagine the benefits if we had an intelligent process to discover our ambiguous rules, and "officially" clarify them.
| | | (4) Posted by Juraj Lörinc [Wednesday, May 18, 2011 14:29] |
Kevin, while you have deftly uncovered quite a few logical inconsistencies in my previous post (good), you have also tried to negate the key message I had tried to give (not so good). I'll try to give it and explain now as clearly as possible.
When I do test a problem with any software (I am using especially WinChloe and Popeye), I try to conform to the program's specificities. If the one chosen by me does solve the problem one way, I do construct it in its fashion. I do not care about the other. And if later any ambiguity is uncovered, it is just time to check whether it is due to program error or program interpretation. If error, I have to redo the problem. If interpretations can differ within the definitions, I just say "hey, I have used Popeye for testing it, it is ok, look at that point, it is ambigous..." So I do not stipulate consciously any specific resolution of ambiguity at the time of composing, rather ex post when the need arises.
To list more cases... there are imitator treatment differencies, Madrasi treatment differencies, Patrol chess treatment differences, the list can much longer. And in my view it is impossible to resolve any conflict beforehand, often not even by sticking to one general set of meta-rules for fairy elements interactions. There is no simple general solution, only simple, but unnecessary solutions for specific cases. You may prove me wrong, good luck with that mission.
| | | (5) Posted by Kevin Begley [Wednesday, May 18, 2011 18:33]; edited by Kevin Begley [11-05-18] |
Juraj,
I did have some luck.
Christian says it should be legal (to rebirth onto the vacated square), and it will be fixed in the next update of Win Chloe.
Cheers,
Kevin
| | | (6) Posted by Juraj Lörinc [Wednesday, May 18, 2011 21:45] |
Well... ok. :)
| | | (7) Posted by Joost de Heer [Sunday, May 22, 2011 10:14] |
QUOTE
Popeye and WinChloe used to differ in this case, but something in my mind whispers that at least one of programs has already added option to choose (maybe these whispers are just trying to fool me...).
WinChloe has a 'Rebirth relative to arrival square' condition (sorry, can't remember the exact French condition at the moment, it was something like 'Renaissance relative...')
| | | (8) Posted by Kevin Begley [Thursday, Aug 11, 2011 01:22] |
Update: Win Chloe v3.07 now shows two (not one) solution for the above scheme (in agreement with popeye).
| | | (9) Posted by Kevin Begley [Tuesday, Aug 16, 2011 13:23]; edited by Kevin Begley [11-08-16] |
I found more discrepancies between popeye & Win Chloe, in super-circe... but, only with questions of conditional precedent (no bugs).
| |
No more posts |
MatPlus.Net Forum Internet and Computing Discrepancy in rules of SuperCirce Rebirth? |
|
|
|
ISC 2024
