MatPlus.Net

 Website founded by
Milan Velimirović
in 2006

10:34 UTC
ISC 2024
 
  Forum*
 
 
 
 

Username:

Password:

Remember me

 
Forgot your
password?
Click here!
SIGN IN
to create your account if you don't already have one.
CHESS
SOLVING

Tournaments
Rating lists
1-Jan-2024

B P C F





 
 
MatPlus.Net Forum Internet and Computing Another Popeye bug?
 
You can only view this page!
(1) Posted by Ian Shanahan [Saturday, Aug 2, 2008 03:16]

Another Popeye bug?


Recently I was testing a new 'orthodox' serieshelpstalemate in 11 with Popeye 4.41, using the two "options" Intelligent mode and MoveNumbers (which states the number of positions at each level in the analysis). So far so good. Later, after I had reflected the position left-to-right for cosmetic reasons, I ran the test again to 12 moves in order to discover any accurate 12-move tries. To my amazement, the MoveNumbers were all slightly different! Of course this should not occur: they ought to have been, in theory, identical. Alarmingly, this discrepancy suggests a bug in Intelligent mode and/or the MoveNumbers option. And the same anomaly occurred with some other serieshelpstalemates I tested as well. Have others encountered this phenomenon? Can anyone shed some light on it? Perhaps Thomas Maeder could ride to the rescue...
 
(Read Only)pid=2564
(2) Posted by Thomas Maeder [Saturday, Aug 2, 2008 13:05]

 QUOTE 
Another Popeye bug?

Another? Is there another one :-)

 QUOTE 
using the two "options" Intelligent mode and MoveNumbers

I consider these two as mutually exclusive.

Intelligent mode means that the same initial move is tried repeatedly, in an attempt to reach a different end position in each run. That doesn't go well with move numbers, nor with restarting at a particular number.

Accepting both options seems to be the bug here.
 
 
(Read Only)pid=2565
(3) Posted by Harry Fougiaxis [Saturday, Aug 2, 2008 16:25]

I am rather confused by the answer. I had the impression that the option MoveNumbers in intelligent mode merely displays the progress by listing the examined positions after each move. See, for instance, the computer checks in Kotesovec's site. Am I missing something here?
 
   
(Read Only)pid=2566
(4) Posted by Thomas Maeder [Sunday, Aug 3, 2008 11:16]

 QUOTE 
I am rather confused by the answer. I had the impression that the option MoveNumbers in intelligent mode merely displays the progress by listing the examined positions after each move. See, for instance, the computer checks in Kotesovec's site. Am I missing something here?

No, you are right, I had forgotten about that. Things are always tricky if the meaning of a word is interpreted as something different (and not necessarily in line with the word itself) in a different context.


As for the original question, which I think I now understand:
 QUOTE 
To my amazement, the MoveNumbers were all slightly different!

Ian: if castling is not the reason, could you please file a bug report from here:

http://sourceforge.net/tracker/?func=browse&group_id=200122&atid=972237

Use the "Submit new" link, then please indicate:
- a position, preferably of minimal length, where that phenomenon occurs
- Popeye's output for that position
- if you can tell: whether the phenomenon occurs on other Popeye releases
- any other information you may find helpful

Thanks!
 
   
(Read Only)pid=2568
(5) Posted by Ian Shanahan [Tuesday, Aug 5, 2008 02:15]

@Thomas,

No castling is involved. One question though: since I encountered this phenomenon while testing an original composition (a joint with Geoff Foster), would submitting it to SourceForge constitute publication according to the Codex? If so, then I'll submit something else instead. (At present, I'm testing another problem from an old FIDE Album to see whether this anomaly occurs with it...)
 
   
(Read Only)pid=2573
(6) Posted by Sarah Hornecker [Tuesday, Aug 5, 2008 07:41]

If it will be publically visible for everyone, it is considered publication. So: Yes, it's better to send something else instead.
 
 
(Read Only)pid=2574
(7) Posted by Thomas Maeder [Tuesday, Aug 5, 2008 17:44]

 QUOTE 
would submitting it to SourceForge constitute publication according to the Codex?

Yes, for the reason mentioned by Siegried.

For the same reason, I am currently withholding a bunch of example problems for a fairy condition recently added. Once they are published at the intended place, I'll be able to add them to the published examples collection.
 
   
(Read Only)pid=2576
(8) Posted by Ian Shanahan [Wednesday, Aug 6, 2008 05:24]; edited by Ian Shanahan [08-08-08]

@Thomas

I've just submitted a position (ser-h=10, by Valentin Lider) to the SourceForge tracker. Sorry it took me a few days: I don't have the internet at home!!! (Input and output details are in an attached file called test.txt) Please message me if there are any difficulties with my submission.
 
   
(Read Only)pid=2582
(9) Posted by Torsten Linß [Sunday, Aug 31, 2008 00:47]

as the programmer responsible I'll look into this, but don't expect an answer this week [or even this year...] - I'm aging and have a number of other responsibilities :-(
 
   
(Read Only)pid=2680
(10) Posted by Torsten Linß [Sunday, Oct 19, 2008 02:40]

OK. I spent a few hours on this tonight. I arrived at the conclusion that Ian's discovery does not qualify as a bug. There is nothing wrong in Popeye checking a few positions more for stale- or checkmate...

Clearly, when no castling [or circe...] is involved mirroring a position left to right makes no difference. This is obvious, but wrong: When one solves the problem it makes a difference. For example in a h#4 with bKd5 and wSg6 I would more likely look for a checkmate with wSe7 than with wSf4 [unless there is a block on c6 already...]

Something very similar happens in Popeye. The intelligent mode does not do a brute force check. Instead Popeye looks for possible checkmates. Then tries to play from the initial position to the checkmate. The possiblity of a checkmate is decided on by counting the moves required to move the pieces from the initial to the final position. This counting is not done after the final position has been set up [this would take too much time], but while the pieces are added
one after another when constructing the checkmate. The outcome of this counting can sometimes depend on the order in which the pieces are added.

When generating potential checkmates Popeye places pieces on the board in the order a1, b1, c1, etc. So, mirroring makes a difference. Also the way flight squares are determined and provided for (blocking, guarding, and pinning a blocking piece if required) differs when the position is mirrored. Therefore, the way a particular checkmate is generated can be very different after mirroring. With the above this explains why there are occasionally differences in the counts of potential check/stalemates.

Now, you may ask why Popeye is not smart enough to accept/reject a potential final position irrespective of the way it is generated? There are two reasons:
(a) Making smarter decisions in a code means considering and analysing more cases. This usually leads to more programming errors and real bugs. [Be intelligent enough not to trust your intelligence too much...]
(b) Execution speed. At a certain stage it is more efficient to start trying to get from the initial to the final position, rather than doing more tests whether this is feasable.

I hope these explanations have shed some light on Popeye's "intelligent mode" for (ser-)h=/# and why there are sometimes discrepencies in the counts of potential check/stalemates.

Torsten
 
   
(Read Only)pid=2847
(11) Posted by Ian Shanahan [Thursday, Oct 23, 2008 01:37]

Many thanks for this Torsten! Your detailed explanation certainly makes sense (even to a paranoid non-programmer like me). I do appreciate the time you spent answering this question. And I'm glad this 'enumerational asymmetry' is NOT a bug!!!
 
 
(Read Only)pid=2851
(12) Posted by Mario Richter [Thursday, Apr 16, 2009 12:23]

Torsten's explanations are quite interesting.

Just a small question:

popeye accepts the 'intelligent' option for stipulations like ser-h=n, even if some fairy conditions are specified.
But it seems as if these fairy conditions are not always taken into account, when the potential stalemating positions are generated.
Is there a list of fairy conditions which are allowed in combination with intelligent mode?

Regards,

mario
 
   
(Read Only)pid=3550
(13) Posted by Geoff Foster [Friday, Apr 17, 2009 05:54]

In my experience Popeye doesn't accept any fairy conditions with intelligent mode. Sometimes it seems to accept a fairy condition, but then finds no solution.
 
   
(Read Only)pid=3555
(14) Posted by Mario Richter [Friday, Apr 17, 2009 08:26]

 QUOTE 
In my experience Popeye doesn't accept any fairy conditions with intelligent mode.


I meant 'accept' in the sense that it doesn't reject it like in other situations.
Just an example:
Among the many chess tools I use, popeye is the only one that uses 'S' for Knight, all other tools use 'N'.
So a mistake, which I repeatedly make, is to present popeye a problem with the wrong letter for Knight, e.g.

forsyth rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR
stip dia 4.0

popeye's reaction (at least until version 4.47) is:

Popeye Windows-32Bit v4.47 (402520 KB)
Fairy pieces in proof games not allowed.

problem ignored
solution finished. Time = 0.000 s

(Interestingly, the CVS-version Popeye Windows-32Bit v4.48-20090228 (402644 KB) does not react in the same way).


So at least in principle two reactions of popeye are thinkable:

(a) Intelligent mode with fairy conditions not allowed - problem ignored

(b) Intelligent mode with fairy conditions not allowed - Intelligent Mode ignored

Both reactions would prevent popeye from producing an incorrect set of solutions.
(And the same approach would of course be good if popeye recognizes incompatible fairy conditions ...)

Best,

mario
 
   
(Read Only)pid=3556
(15) Posted by Thomas Maeder [Friday, Apr 17, 2009 18:30]

 QUOTE 
In my experience Popeye doesn't accept any fairy conditions with intelligent mode. Sometimes it seems to accept a fairy condition, but then finds no solution.


This isn't quite correct. Well, I don't want to argue with expercience, of course, but Popeye does in fact support intelligent mode for some fairy conditions.

Intelligent mode means that Popeye first generates possible (stale)mate positions and then tries to reach them one after the other; if a certain move reaches position that is too "distant" from the current target position, it is rejected.

Conditions that don't reduce the distance between any two positions (compared to orthodox chess) are therefore acceptable.

These include (examples to be found in the BEISPIEL and EXAMPLES files shipped with Popeye):
Forced squares
Holes
Maximummer
Minimummer

Note that some conditions increase that distance. This may mean that intelligent mode, while acceptable, may not be optimal.
 
 
(Read Only)pid=3558
(16) Posted by Thomas Maeder [Friday, Apr 17, 2009 23:41]

 QUOTE 
(Interestingly, the CVS-version Popeye Windows-32Bit v4.48-20090228 (402644 KB) does not react in the same way).


Please report Popeye bugs to the Popeye bug tracker; thanks!

http://sourceforge.net/tracker/?group_id=200122&atid=972237
 
   
(Read Only)pid=3559
(17) Posted by Geoff Foster [Saturday, Apr 18, 2009 05:49]

The "holes" condition gives no solution when used with intelligent mode. Consider the following Popeye input file:

begin
prot holes.txt
stip ser-h=2
pieces
white ke2
black kh1 bh2 pf2h3
option intelligent
endp

This gives the following output:

Popeye Windows-32Bit v4.45 (705304 KB)


+---a---b---c---d---e---f---g---h---+
| |
8 . . . . . . . . 8
| |
7 . . . . . . . . 7
| |
6 . . . . . . . . 6
| |
5 . . . . . . . . 5
| |
4 . . . . . . . . 4
| |
3 . . . . . . . -P 3
| |
2 . . . . K -P . -B 2
| |
1 . . . . . . . -K 1
| |
+---a---b---c---d---e---f---g---h---+
ser-h=2 1 + 4

1.Bh2-g1 2.h3-h2 Ke2-f1 =

solution finished. Time = 0.062 s

Now adding "condition hole a8b8c8d8e8f8g8h8" gives the following output, with no solution:

Popeye Windows-32Bit v4.45 (710420 KB)


+---a---b---c---d---e---f---g---h---+
| |
8 8
| |
7 . . . . . . . . 7
| |
6 . . . . . . . . 6
| |
5 . . . . . . . . 5
| |
4 . . . . . . . . 4
| |
3 . . . . . . . -P 3
| |
2 . . . . K -P . -B 2
| |
1 . . . . . . . -K 1
| |
+---a---b---c---d---e---f---g---h---+
ser-h=2 1 + 4


solution finished. Time = 0.031 s
 
   
(Read Only)pid=3561
(18) Posted by Torsten Linß [Wednesday, Apr 22, 2009 10:32]; edited by Torsten Linß [09-04-22]

Have to think about this...
 
 
(Read Only)pid=3571
(19) Posted by Thomas Maeder [Saturday, Apr 25, 2009 09:24]

 QUOTE 
Now adding "condition hole a8b8c8d8e8f8g8h8" gives the following output, with no solution:


Fixed for the next release.

Please in the future do post Popeye bugs to the Popeye bug tracker:
http://sourceforge.net/tracker/?group_id=200122&atid=972237
 
 
(Read Only)pid=3581

No more posts


MatPlus.Net Forum Internet and Computing Another Popeye bug?