More WBEC output examination... {LGPGNVER}

Archive of the old Parsimony forum. Some messages couldn't be restored. Limitations: Search for authors does not work, Parsimony specific formats do not work, threaded view does not work properly. Posting is disabled.

Re: More WBEC output examination... {LGPGNVER}

Postby Uri Blass » 24 Jun 2004, 20:50

Geschrieben von:/Posted by: Uri Blass at 24 June 2004 21:50:42:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dann Corbit at 24 June 2004 20:33:24:
This result means that engines may assume that games take no more than 1000 plies for every practical reason because if the game takes more moves then winboard is closed.
I am afraid that Movei of today may crush in analysis of games of almost 1000 moves because after 990 plies it may look in analysis at ply 1001 and get out of bounds.
Obviously a joke from you, but I will answer anyway.
1) It is a bug in WinBoard and in no case should anyone rely on it (hopefully it will be fixed in the future as a separate argument).
2) xboard-compatible engines should not assume that WinBoard is going to be the interface (hopefully a lot of xboard software does not have the same bug as WinBoard).
IMO engines are "allowed" to crash (like a player could faint during a tournament), but interfaces are not. It is the TD's decision what happens in this case (e.g. immediate loss).
I disagree. A crash is a sign of a serious software defect. In the case of an array bounds over-write, this is a software exploit that people can use to cause billions of dollars in damage and destroy your network.
There is no excuse for a crash. "I give up!" and exit is fine. Crash is not.
P.S.
The maximum legal game is less than 6000 full moves.
No.
The sides do not have to claim a draw and even if the program always claim a draw by repetition or by the 50 move rule then still programs are used for analysis and it needs to handle the case that a user may insert game of more than 12000 moves.
Uri
Uri Blass
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dann Corbit » 24 Jun 2004, 22:23

Geschrieben von:/Posted by: Dann Corbit at 24 June 2004 23:23:53:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Uri Blass at 24 June 2004 21:50:42:
This result means that engines may assume that games take no more than 1000 plies for every practical reason because if the game takes more moves then winboard is closed.
I am afraid that Movei of today may crush in analysis of games of almost 1000 moves because after 990 plies it may look in analysis at ply 1001 and get out of bounds.
Obviously a joke from you, but I will answer anyway.
1) It is a bug in WinBoard and in no case should anyone rely on it (hopefully it will be fixed in the future as a separate argument).
2) xboard-compatible engines should not assume that WinBoard is going to be the interface (hopefully a lot of xboard software does not have the same bug as WinBoard).
IMO engines are "allowed" to crash (like a player could faint during a tournament), but interfaces are not. It is the TD's decision what happens in this case (e.g. immediate loss).
I disagree. A crash is a sign of a serious software defect. In the case of an array bounds over-write, this is a software exploit that people can use to cause billions of dollars in damage and destroy your network.
There is no excuse for a crash. "I give up!" and exit is fine. Crash is not.
P.S.
The maximum legal game is less than 6000 full moves.
No.
The sides do not have to claim a draw and even if the program always claim a draw by repetition or by the 50 move rule then still programs are used for analysis and it needs to handle the case that a user may insert game of more than 12000 moves.
From this:
http://www.drpribut.com/sports/chessfaq.html
We have this:
"Subject: [24] Trivia
How long is the longest possible chess game?
The basic idea is a player may claim a draw if fifty moves elapse without a capture or a pawn advance. Ignoring the special cases where more than 50 moves are allowed by the rules, the answer is after Black's 5948th move, White is able to claim a draw. The simple calculation is (
Dann Corbit
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dann Corbit » 24 Jun 2004, 22:29

Geschrieben von:/Posted by: Dann Corbit at 24 June 2004 23:29:55:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dan Honeycutt at 24 June 2004 21:34:05:
The maximum legal game is less than 6000 full moves. So 12000 ply is enough.
I'm too tight-fisted with memory. No way I'm going to have something like game_history[12000] :)
Then call realloc(), used a linked list, or exit with an error.
To over-write and crash (or worse, enable virus attacks) is not acceptable.
BTW, 1 GB of the fastest available DDR memory is about $250
http://www.4allmemory.com/index.cfm?fus ... ry_desktop
Assuming integer storage for game history, and sizeof int == 4:
12000 * 4 = 48,000 bytes ram.
1 GB = 1073741824 bytes (shipped as power of 2)
1073741824/25000 pennies = 42949.67296 bytes per penny
So the array would consume about one penny worth of fast, expensive ram.
If for some reason a game history entry was 40 bytes, we are up to a dime.



my ftp site {remove http:// unless you like error messages}
Dann Corbit
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dieter Bürßner » 24 Jun 2004, 23:43

Geschrieben von:/Posted by: Dieter Bürßner at 25 June 2004 00:43:02:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Uri Blass at 24 June 2004 20:57:49:
I bet that most of the chess program can crash if you give them some illegal FEN.
I'd be very interested in positions, in which Yace crashes (legal or illegal ones). I just fixed some cases (which were still there because of some stupidness of me - actually the cases were checked since long, but somehow I let the engine ignore those checks).
Donald Knuth gave a little prize, to anybody who found a bug in TeX. He doubled the prize after each bug report. I'd like to do the same, but I fear, I have less money than Knuth ... Anyway, each crash report for Yace (even in the strangest circumstances) will be welcome. I might chose, to ignore some ... But I would probably try to fix most. Crashes are not acceptable. Even with stupid user input.
Under GUIs it might be considered a bit different. I think the engine can assume then, that the GUI works correctly. If not, the GUI should be to blame. OTOH, any GUI input can be done from console as well ...
Regards,
Dieter
Dieter Bürßner
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dieter Bürßner » 25 Jun 2004, 00:02

Geschrieben von:/Posted by: Dieter Bürßner at 25 June 2004 01:02:40:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dann Corbit at 24 June 2004 23:23:53:

That is true. I think (however) that a 12000 ply limit is reasonable, because that is the maximum length of a well played game of chess. I doubt if it will be overcome in practice. And so a limit of that size can be set. Then there are two choices. You can calle realloc() if it is exceeded (e.g. realloc for size * 2) or you can exit with an error message.
Actually, for an engine, that is aware of the draw rules, someting like 100 half moves could be enough. There is in principle no reason, to store move than the last 50 moves.
Unfortunately, this is not really correct. Engines are supposed to implement "undo". The WB GUI could force the engine to do several hundreds of moves, and then issue several hundreds of undos. An engine, that cannot remember all of the game history (perhaps thousands of moves) will fail eventually with the undos. I think, this can be considered a flaw of the protocol. It might be interesting to note, that UCI has no undo command.
Regards,
Dieter
Dieter Bürßner
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dan Honeycutt » 25 Jun 2004, 00:30

Geschrieben von:/Posted by: Dan Honeycutt at 25 June 2004 01:30:33:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dann Corbit at 24 June 2004 23:29:55:
The maximum legal game is less than 6000 full moves. So 12000 ply is enough.
I'm too tight-fisted with memory. No way I'm going to have something like game_history[12000] :)
Then call realloc(), used a linked list, or exit with an error.
To over-write and crash (or worse, enable virus attacks) is not acceptable.
BTW, 1 GB of the fastest available DDR memory is about $250
http://www.4allmemory.com/index.cfm?fus ... ry_desktop
Assuming integer storage for game history, and sizeof int == 4:
12000 * 4 = 48,000 bytes ram.
1 GB = 1073741824 bytes (shipped as power of 2)
1073741824/25000 pennies = 42949.67296 bytes per penny
So the array would consume about one penny worth of fast, expensive ram.
If for some reason a game history entry was 40 bytes, we are up to a dime.
I didn't say I overwrote and crashed. I can play a 6000 move game. My game history is 200 moves. As I approach that limit I simply discard the first 50 moves. I still have all I need to detect draws, I just can't back up to the beginning of the game.


You're right, memory is cheap. Now. My first computer was a TRS-80 Model I with 16k of RAM. That was the fancy model (Level 2 as I recall) the basic model had 4k. Program with one of those and you don't go dimensioning 12000 element arrays :)
Old habits die hard.
Dan H.
Dan Honeycutt
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dieter Bürßner » 25 Jun 2004, 00:40

Geschrieben von:/Posted by: Dieter Bürßner at 25 June 2004 01:40:29:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dan Honeycutt at 25 June 2004 01:30:33:
You're right, memory is cheap. Now. My first computer was a TRS-80 Model I with 16k of RAM.
That was the fancy model (Level 2 as I recall) the basic model had 4k. Program with one of those and you don't go dimensioning 12000 element arrays :)
Old habits die hard.
When was this? I started with some Commodore "PET". It had 4 kB of RAM and 4 kB of ROM Basic. Late 70ties. Soon later, we had already some Othello program, that was reasonably strong (too strong for me). And of course the famous "Lunar lander".
Right!
Cheers,
Dieter
Dieter Bürßner
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dan Honeycutt » 25 Jun 2004, 02:14

Geschrieben von:/Posted by: Dan Honeycutt at 25 June 2004 03:14:53:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dieter Bürßner at 25 June 2004 01:40:29:
You're right, memory is cheap. Now. My first computer was a TRS-80 Model I with 16k of RAM.
That was the fancy model (Level 2 as I recall) the basic model had 4k. Program with one of those and you don't go dimensioning 12000 element arrays :)
Old habits die hard.
When was this? I started with some Commodore "PET". It had 4 kB of RAM and 4 kB of ROM Basic. Late 70ties. Soon later, we had already some Othello program, that was reasonably strong (too strong for me). And of course the famous "Lunar lander".
Right!
Cheers,
Dieter
Around the same time, late 70's. Your Commodore had better graphics. The TRS-80 had a 64x16 memory mapped display and the character set had 2x3 blocks for each character giving a 128x48 "pixel" display - not too hot for games. I still thought it was great. You could type in your program (or load it from cassette tape which was only slightly faster than typing it in) run it and get results RIGHT THEN. Sure beat programming classes in school where you took your card deck to the desk and waited a few hours for it to be batch processed (turnaround was quicker in the middle of the night). I still remember the anxious waits as deadlines approached hoping the damn thing would work this time. First clue as the attendant brought it was the thickness of the printout - one sheet and you knew it didn't compile. A thick sheaf meant you had hung it in a loop. About the right thickness and there was hope.
Dan H.
Dan Honeycutt
 

Re: More WBEC output examination... {LGPGNVER}

Postby Uri Blass » 25 Jun 2004, 03:42

Geschrieben von:/Posted by: Uri Blass at 25 June 2004 04:42:32:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dieter Bürßner at 25 June 2004 00:43:02:
I bet that most of the chess program can crash if you give them some illegal FEN.
I'd be very interested in positions, in which Yace crashes (legal or illegal ones). I just fixed some cases (which were still there because of some stupidness of me - actually the cases were checked since long, but somehow I let the engine ignore those checks).
Donald Knuth gave a little prize, to anybody who found a bug in TeX. He doubled the prize after each bug report. I'd like to do the same, but I fear, I have less money than Knuth ... Anyway, each crash report for Yace (even in the strangest circumstances) will be welcome. I might chose, to ignore some ... But I would probably try to fix most. Crashes are not acceptable. Even with stupid user input.
The problem is that I am afraid that the law does not say that crashes are not acceptable and customers cannot get the money back if they get software that can crash after some stupid input.
It may be a good idea if there is going to be a rule that customers can ask companies to return the money that they payed in case that they find bugs that make the software crash.
Unfortunately I am afraid that in chess programming things may be hard
to do because if you care about speed you cannot take care about checking bounds when the programs is running and the fact that the program never crashed in debug mode does not give you 100% confidence that it cannot happen in games
because it is possible that some bug happens only in some rare positions that happen only in 1 out of 100000 games.
Uri
Uri Blass
 

Re: More WBEC output examination... {LGPGNVER}

Postby Uri Blass » 25 Jun 2004, 03:45

Geschrieben von:/Posted by: Uri Blass at 25 June 2004 04:45:39:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Uri Blass at 25 June 2004 04:42:32:
I bet that most of the chess program can crash if you give them some illegal FEN.
I'd be very interested in positions, in which Yace crashes (legal or illegal ones). I just fixed some cases (which were still there because of some stupidness of me - actually the cases were checked since long, but somehow I let the engine ignore those checks).
Donald Knuth gave a little prize, to anybody who found a bug in TeX. He doubled the prize after each bug report. I'd like to do the same, but I fear, I have less money than Knuth ... Anyway, each crash report for Yace (even in the strangest circumstances) will be welcome. I might chose, to ignore some ... But I would probably try to fix most. Crashes are not acceptable. Even with stupid user input.
The problem is that I am afraid that the law does not say that crashes are not acceptable and customers cannot get the money back if they get software that can crash after some stupid input.
It may be a good idea if there is going to be a rule that customers can ask companies to return the money that they payed in case that they find bugs that make the software crash.
Unfortunately I am afraid that in chess programming things may be hard
to do because if you care about speed you cannot take care about checking bounds when the programs is running and the fact that the program never crashed in debug mode does not give you 100% confidence that it cannot happen in games
because it is possible that some bug happens only in some rare positions that happen only in 1 out of 100000 games.
Uri
To be more correct I mean rare positions that happans only in the search tree of 1 out of 100000 games and the rare position do not need to happen in the game in order to cause the crash.
Uri
Uri Blass
 

Re: More WBEC output examination... {LGPGNVER}

Postby David Dahlem » 25 Jun 2004, 14:47

Geschrieben von:/Posted by: David Dahlem at 25 June 2004 15:47:19:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Lyapko George at 24 June 2004 08:04:04:
By far, the majority of exceptions returned by lgpgnver wbec.pgn wbec.out 999 were {no draw found}.

I do a lot of adjucating games to save time in cases of obvious outcomes. And lgpgnver doesn't recognize draw games adjucated by humans. In my case, i get "lots" of (no draw found) messages, and would like to see this glitch addressed in a future update. :-)
Regards
Dave
Please download new version(1.14) from my site.
In case of adjudicating a game all what you need is to write in the comment for the game result something like
{...adjudi...} or {...award...}
and you'll get grom lgpgnver
Warning level :2
Analyze result:1/2-1/2 {awarded(adjudicated)??}
To get rid of printing such games, type
LGPGNVER xxx.pgn xxx.res 2
and you'll get messages only for games with warning level higher than 2.
Best regards,
LG
I have been unable to get this to work, using version 1.14. All user adjucated games are output as {no draw found}. Here is an example adjudicated game. Could you show how to alter such a game in order that it is ignored by lgpgnver?
[Event "Test"]
[Site "?"]
[Date "????.??.??"]
[Round "1"]
[White "engine1"]
[Black "engine2"]
[Result "1/2-1/2"]
1. d4 Nf6 2. c4 e6 3. Nc3 Bb4 4. Qc2 O-O {User Adjudication} 1/2-1/2
I'm using this command format:
lgpgnver game.pgn output.txt 2
Thanks
Dave
David Dahlem
 

Re: More WBEC output examination... {LGPGNVER}

Postby Lyapko George » 25 Jun 2004, 15:08

Geschrieben von:/Posted by: Lyapko George at 25 June 2004 16:08:11:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: David Dahlem at 25 June 2004 15:47:19:
By far, the majority of exceptions returned by lgpgnver wbec.pgn wbec.out 999 were {no draw found}.

I do a lot of adjucating games to save time in cases of obvious outcomes. And lgpgnver doesn't recognize draw games adjucated by humans. In my case, i get "lots" of (no draw found) messages, and would like to see this glitch addressed in a future update. :-)
Regards
Dave
Please download new version(1.14) from my site.
In case of adjudicating a game all what you need is to write in the comment for the game result something like
{...adjudi...} or {...award...}
and you'll get grom lgpgnver
Warning level :2
Analyze result:1/2-1/2 {awarded(adjudicated)??}
To get rid of printing such games, type
LGPGNVER xxx.pgn xxx.res 2
and you'll get messages only for games with warning level higher than 2.
Best regards,
LG
I have been unable to get this to work, using version 1.14. All user adjucated games are output as {no draw found}. Here is an example adjudicated game. Could you show how to alter such a game in order that it is ignored by lgpgnver?
[Event "Test"]
[Site "?"]
[Date "????.??.??"]
[Round "1"]
[White "engine1"]
[Black "engine2"]
[Result "1/2-1/2"]
1. d4 Nf6 2. c4 e6 3. Nc3 Bb4 4. Qc2 O-O {User Adjudication} 1/2-1/2
I'm using this command format:
lgpgnver game.pgn output.txt 2
Thanks
Dave
LGPGNVER in this case is case sensitive and it looks for "adjudi" and not for "Adjudi".Will be fixed in next version.
Best regards,
LG
Lyapko George
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dann Corbit » 25 Jun 2004, 21:10

Geschrieben von:/Posted by: Dann Corbit at 25 June 2004 22:10:03:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dieter Bürßner at 25 June 2004 00:43:02:
I bet that most of the chess program can crash if you give them some illegal FEN.
I'd be very interested in positions, in which Yace crashes (legal or illegal ones). I just fixed some cases (which were still there because of some stupidness of me - actually the cases were checked since long, but somehow I let the engine ignore those checks).
Donald Knuth gave a little prize, to anybody who found a bug in TeX. He doubled the prize after each bug report. I'd like to do the same, but I fear, I have less money than Knuth ... Anyway, each crash report for Yace (even in the strangest circumstances) will be welcome. I might chose, to ignore some ... But I would probably try to fix most. Crashes are not acceptable. Even with stupid user input.
Under GUIs it might be considered a bit different. I think the engine can assume then, that the GUI works correctly. If not, the GUI should be to blame. OTOH, any GUI input can be done from console as well ...
Regards,
Dieter
One of my prized possessions is a framed check from Donald Knuth for $2.88 for finding bugs in TAOCP. Of course, I would never cash it.



my ftp site {remove http:// unless you like error messages}
Dann Corbit
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dann Corbit » 25 Jun 2004, 21:37

Geschrieben von:/Posted by: Dann Corbit at 25 June 2004 22:37:45:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Uri Blass at 25 June 2004 04:45:39:
I bet that most of the chess program can crash if you give them some illegal FEN.
I'd be very interested in positions, in which Yace crashes (legal or illegal ones). I just fixed some cases (which were still there because of some stupidness of me - actually the cases were checked since long, but somehow I let the engine ignore those checks).
Donald Knuth gave a little prize, to anybody who found a bug in TeX. He doubled the prize after each bug report. I'd like to do the same, but I fear, I have less money than Knuth ... Anyway, each crash report for Yace (even in the strangest circumstances) will be welcome. I might chose, to ignore some ... But I would probably try to fix most. Crashes are not acceptable. Even with stupid user input.
The problem is that I am afraid that the law does not say that crashes are not acceptable and customers cannot get the money back if they get software that can crash after some stupid input.
It may be a good idea if there is going to be a rule that customers can ask companies to return the money that they payed in case that they find bugs that make the software crash.
Unfortunately I am afraid that in chess programming things may be hard
to do because if you care about speed you cannot take care about checking bounds when the programs is running and the fact that the program never crashed in debug mode does not give you 100% confidence that it cannot happen in games
because it is possible that some bug happens only in some rare positions that happen only in 1 out of 100000 games.
Uri
To be more correct I mean rare positions that happans only in the search tree of 1 out of 100000 games and the rare position do not need to happen in the game in order to cause the crash.
"I will always get correct data from the user." is an intentional oversight. So (for instance) if you are expecting a FEN position, and you get one megabyte of binary data instead, your program does bad things. The reason I call it an intentional oversight is that it is not reasonable to assume perfect input.
There are also unintentional oversights. For instance, you may assume that no board position has more than 255 distinct moves possible. After all, the maximum ever discovered is 218. But the reasonable assumption may be incorrect. Perhaps there is some strange position with 257 moves possible.
Asserts can help you to locate both kinds of oversight, but they do not correct them. An if() test and an abort() or other exit strategy will cause the program to halt, if needed.
So defensive programming is needed. Some ideas to keep in mind:
1. Never use gets() or scanf() with "%s" because this allows unrestricted information to stream into the input buffer. Far better is fgets() which has a size limit. Or here is a function that does not require a file as input:
http://home.att.net/~jackklein/ctips01.html#safe_gets
2. For any array where the end limit is unknown, make safeguards. At least, you should use an assert.
E.g., this one is perfectly safe and you don't have to worry about it:
int i;
char board[64];
for (i = 0; i < 64; i++)
board[i] = 0;
but this is not safe:
int clobber(char *p, size_t count)
{
size_t c;
for (c = 0; c < count; c++)
p[c] = 0;
}
so if you use a function like that at any time, you should be darn sure that the inputs are acceptable. Examples of commonly used functions like this are memset(), memcpy(), strcpy(), etc.
3. Run lint and other static error detection tools at your disposal against every piece of code that you write.
4. Use bounds checkers, use memory leak checkers and other run-time tools.
5. Always set your compiler to the highest warning level possible.
IMO-YMMV.
Reading the C FAQ is a good idea. The newsgroup news:comp.lang.c is full of people who can teach you about C. But lurk a bit first, they are not terribly tolerant of breaches in netiquette.



my ftp site {remove http:// unless you like error messages}
Dann Corbit
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dieter Bürßner » 25 Jun 2004, 22:05

Geschrieben von:/Posted by: Dieter Bürßner at 25 June 2004 23:05:54:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dann Corbit at 25 June 2004 22:37:45:

I agree with your suggestions. One minor point later
"I will always get correct data from the user." is an intentional oversight. So (for instance) if you are expecting a FEN position, and you get one megabyte of binary data instead, your program does bad things. The reason I call it an intentional oversight is that it is not reasonable to assume perfect input.
There are also unintentional oversights. For instance, you may assume that no board position has more than 255 distinct moves possible. After all, the maximum ever discovered is 218. But the reasonable assumption may be incorrect. Perhaps there is some strange position with 257 moves possible.
5. Always set your compiler to the highest warning level possible.
323 moves will be enough for legal chess positions. 9 Q, 2 R, 2 B, 2 N, 1 K
9*27+2*14+2*13+2*8+10 (including 2 castling moves).
It is clear, that the actual maximum will be quite a bit lower, but I see no (easy) way, to calculate it.
I find it a PITA, with for example MSVC.

&#71;&#58;&#92;&#115;&#114;&#99;&#92;&#121;&#97;&#99;&#101;&#62;&#99;&#97;&#116;&#32;&#109;&#46;&#99;
&#101;&#120;&#116;&#101;&#114;&#110;&#32;&#118;&#111;&#105;&#100;&#32;&#102;&#111;&#111;&#40;&#118;&#111;&#105;&#100;&#41;&#59;
&#101;&#120;&#116;&#101;&#114;&#110;&#32;&#118;&#111;&#105;&#100;&#32;&#98;&#97;&#114;&#40;&#118;&#111;&#105;&#100;&#41;&#59;

&#35;&#100;&#101;&#102;&#105;&#110;&#101;&#32;&#114;&#111;&#98;&#117;&#115;&#116;&#95;&#109;&#97;&#99;&#114;&#111;&#40;&#41;&#32;&#100;&#111;&#32;&#123;&#32;&#102;&#111;&#111;&#40;&#41;&#59;&#32;&#98;&#97;&#114;&#40;&#41;&#59;&#32;&#125;&#32;&#119;&#104;&#105;&#108;&#101;&#32;&#40;&#48;&#41;
&#35;&#100;&#101;&#102;&#105;&#110;&#101;&#32;&#102;&#114;&#97;&#103;&#105;&#108;&#101;&#95;&#109;&#97;&#99;&#114;&#111;&#40;&#41;&#32;&#123;&#102;&#111;&#111;&#40;&#41;&#59;&#32;&#98;&#97;&#114;&#40;&#41;&#59;&#32;&#125;
&#118;&#111;&#105;&#100;&#32;&#100;&#117;&#109;&#109;&#121;&#40;&#105;&#110;&#116;&#32;&#105;&#41;
&#123;
&nbsp;&nbsp;&#105;&#102;&#32;&#40;&#105;&#60;&#48;&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&#114;&#111;&#98;&#117;&#115;&#116;&#95;&#109;&#97;&#99;&#114;&#111;&#40;&#41;&#59;&#32;&#47;&#42;&#32;&#119;&#111;&#110;&#39;&#116;&#32;&#119;&#111;&#114;&#107;&#32;&#119;&#105;&#116;&#104;&#32;&#102;&#114;&#97;&#103;&#105;&#108;&#101;&#32;&#109;&#97;&#99;&#114;&#111;&#44;&#32;&#98;&#117;&#116;&#32;&#119;&#97;&#114;&#110;&#105;&#110;&#103;&#32;&#42;&#47;
&nbsp;&nbsp;&#101;&#108;&#115;&#101;
&nbsp;&nbsp;&nbsp;&nbsp;&#98;&#97;&#114;&#40;&#41;&#59;
&nbsp;&nbsp;&#102;&#114;&#97;&#103;&#105;&#108;&#101;&#95;&#109;&#97;&#99;&#114;&#111;&#40;&#41;&#59;&#32;&#47;&#42;&#32;&#78;&#111;&#32;&#119;&#97;&#114;&#110;&#105;&#110;&#103;&#32;&#42;&#47;
&#125;

&#71;&#58;&#92;&#115;&#114;&#99;&#92;&#121;&#97;&#99;&#101;&#62;&#99;&#108;&#32;&#45;&#87;&#52;&#32;&#45;&#99;&#32;&#109;&#46;&#99;
&#79;&#112;&#116;&#105;&#109;&#105;&#101;&#114;&#101;&#110;&#100;&#101;&#114;&#32;&#77;&#105;&#99;&#114;&#111;&#115;&#111;&#102;&#116;&#32;&#40;&#82;&#41;&#32;&#51;&#50;&#45;&#66;&#105;&#116;&#32;&#67;&#47;&#67;&#43;&#43;&#45;&#67;&#111;&#109;&#112;&#105;&#108;&#101;&#114;&#44;&#32;&#86;&#101;&#114;&#115;&#105;&#111;&#110;&#32;&#49;&#50;&#46;&#48;&#48;&#46;&#56;&#49;&#54;&#56;&#44;&#32;&#102;&#117;&#101;&#114;&#32;&#120;&#56;&#54;
&#67;&#111;&#112;&#121;&#114;&#105;&#103;&#104;&#116;&#32;&#40;&#67;&#41;&#32;&#77;&#105;&#99;&#114;&#111;&#115;&#111;&#102;&#116;&#32;&#67;&#111;&#114;&#112;&#32;&#49;&#57;&#56;&#52;&#45;&#49;&#57;&#57;&#56;&#46;&#32;&#65;&#108;&#108;&#101;&#32;&#82;&#101;&#99;&#104;&#116;&#101;&#32;&#118;&#111;&#114;&#98;&#101;&#104;&#97;&#108;&#116;&#101;&#110;&#46;
&#109;&#46;&#99;
&#109;&#46;&#99;&#40;&#49;&#49;&#41;&#32;&#58;&#32;&#119;&#97;&#114;&#110;&#105;&#110;&#103;&#32;&#67;&#52;&#49;&#50;&#55;&#58;&#32;&#66;&#101;&#100;&#105;&#110;&#103;&#116;&#101;&#114;&#32;&#65;&#117;&#115;&#100;&#114;&#117;&#99;&#107;&#32;&#105;&#115;&#116;&#32;&#107;&#111;&#110;&#115;&#116;&#97;&#110;&#116;
&#40;&#67;&#111;&#110;&#100;&#105;&#116;&#105;&#111;&#110;&#97;&#108;&#32;&#101;&#120;&#112;&#114;&#101;&#115;&#115;&#105;&#111;&#110;&#32;&#105;&#115;&#32;&#99;&#111;&#110;&#115;&#116;&#97;&#110;&#116;&#41;

My code gets many such warnings. With -W4 too many, to make it useful. The serious warnings will be easily overseen. I don't think it would be nice, to clutter the source code with many pragmas to disable specific warnings.
I have seen other examples about warnings, which go away with a cast, that is really unneeded, and that may easily break the code, when the type of the var is changed, but one forgets to change the cast.
Such warnings may make you write worse code.
Regards,
Dieter
Dieter Bürßner
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dann Corbit » 25 Jun 2004, 22:15

Geschrieben von:/Posted by: Dann Corbit at 25 June 2004 23:15:55:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dieter Bürßner at 25 June 2004 23:05:54:

[snip]
G:\src\yace>cl -W4 -c m.c
Optimierender Microsoft (R) 32-Bit C/C++-Compiler, Version 12.00.8168, fuer x86
Copyright (C) Microsoft Corp 1984-1998. Alle Rechte vorbehalten.
m.c
m.c(11) : warning C4127: Bedingter Ausdruck ist konstant
(Conditional expression is constant)

My code gets many such warnings. With -W4 too many, to make it useful. The serious warnings will be easily overseen. I don't think it would be nice, to clutter the source code with many pragmas to disable specific warnings.
I have seen other examples about warnings, which go away with a cast, that is really unneeded, and that may easily break the code, when the type of the var is changed, but one forgets to change the cast.
Such warnings may make you write worse code.
I just learn which warnings are nonsense. You must also do this for Lint and Splint. Also, ignore most warnings in the system headers unless you know it is something that must be broken like "wrong levels of indirection" etc.



my ftp site {remove http:// unless you like error messages}
Dann Corbit
 

Re: More WBEC output examination... {LGPGNVER}

Postby Uri Blass » 25 Jun 2004, 23:07

Geschrieben von:/Posted by: Uri Blass at 26 June 2004 00:07:19:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dieter Bürßner at 25 June 2004 23:05:54:
I agree with your suggestions. One minor point later
"I will always get correct data from the user." is an intentional oversight. So (for instance) if you are expecting a FEN position, and you get one megabyte of binary data instead, your program does bad things. The reason I call it an intentional oversight is that it is not reasonable to assume perfect input.
There are also unintentional oversights. For instance, you may assume that no board position has more than 255 distinct moves possible. After all, the maximum ever discovered is 218. But the reasonable assumption may be incorrect. Perhaps there is some strange position with 257 moves possible.
323 moves will be enough for legal chess positions. 9 Q, 2 R, 2 B, 2 N, 1 K
9*27+2*14+2*13+2*8+10 (including 2 castling moves).
castling move are moves of the king and if the king can castle then by definition it have not more than 7 moves so you can replace 10 by 8.
If you are intersted in the maximal number of legal moves of 9 queens then you can try to solve by a program the maximal number of n queens for smaller n by trying all possibilities.
It is clear even without a program that 2 queens cannot contol 54 squares because if both of them are in the middle of the board they even do not get 50 squares together and queen not in the middle of the board can see at most
25 squares.
It means that you can easily replace 27*9 by 27+25*8(I believe that it is easy to prove that you it is not the best but I courld prove easily that you have not more than 305 moves.
I believe that not more than 300 moves is easy to calculate.
We need first table for maximal number of moves that n queens can goto.
1 queen 27 moves
2 queens 52 moves(d5 e3)
3 queens 77 moves(d5 e3 f6)
4 queens probably 100 moves(c4 e3 d6 f5)
1 queen in the centre d5 allow only 2 queens that do not prevent another queen to move in c3,e3,f4,f6 and queen not at the centre 4*4 board can see at most 23 squares so it does not help.

Interesting problem but I have no time to think about it now.
Maybe some mathematician can prove a general theorom about it(Tord?)
Uri
Uri Blass
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dann Corbit » 25 Jun 2004, 23:32

Geschrieben von:/Posted by: Dann Corbit at 26 June 2004 00:32:43:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Uri Blass at 26 June 2004 00:07:19:
I agree with your suggestions. One minor point later
"I will always get correct data from the user." is an intentional oversight. So (for instance) if you are expecting a FEN position, and you get one megabyte of binary data instead, your program does bad things. The reason I call it an intentional oversight is that it is not reasonable to assume perfect input.
There are also unintentional oversights. For instance, you may assume that no board position has more than 255 distinct moves possible. After all, the maximum ever discovered is 218. But the reasonable assumption may be incorrect. Perhaps there is some strange position with 257 moves possible.
323 moves will be enough for legal chess positions. 9 Q, 2 R, 2 B, 2 N, 1 K
9*27+2*14+2*13+2*8+10 (including 2 castling moves).
castling move are moves of the king and if the king can castle then by definition it have not more than 7 moves so you can replace 10 by 8.
If you are intersted in the maximal number of legal moves of 9 queens then you can try to solve by a program the maximal number of n queens for smaller n by trying all possibilities.
It is clear even without a program that 2 queens cannot contol 54 squares because if both of them are in the middle of the board they even do not get 50 squares together and queen not in the middle of the board can see at most
25 squares.
It means that you can easily replace 27*9 by 27+25*8(I believe that it is easy to prove that you it is not the best but I courld prove easily that you have not more than 305 moves.
I believe that not more than 300 moves is easy to calculate.
We need first table for maximal number of moves that n queens can goto.
1 queen 27 moves
2 queens 52 moves(d5 e3)
3 queens 77 moves(d5 e3 f6)
4 queens probably 100 moves(c4 e3 d6 f5)
1 queen in the centre d5 allow only 2 queens that do not prevent another queen to move in c3,e3,f4,f6 and queen not at the centre 4*4 board can see at most 23 squares so it does not help.

Interesting problem but I have no time to think about it now.
Maybe some mathematician can prove a general theorom about it(Tord?)
These are the 92 solutions to the n-queens problem for an 8x8 board:
1Q6/3Q4/5Q2/7Q/2Q5/Q7/6Q1/4Q3 - -
1Q6/4Q3/6Q1/3Q4/Q7/7Q/5Q2/2Q5 - -
1Q6/4Q3/6Q1/Q7/2Q5/7Q/5Q2/3Q4 - -
1Q6/5Q2/7Q/2Q5/Q7/3Q4/6Q1/4Q3 - -
1Q6/5Q2/Q7/6Q1/3Q4/7Q/2Q5/4Q3 - -
1Q6/6Q1/2Q5/5Q2/7Q/4Q3/Q7/3Q4 - -
1Q6/6Q1/4Q3/7Q/Q7/3Q4/5Q2/2Q5 - -
1Q6/7Q/5Q2/Q7/2Q5/4Q3/6Q1/3Q4 - -
2Q5/4Q3/1Q6/7Q/5Q2/3Q4/6Q1/Q7 - -
2Q5/4Q3/1Q6/7Q/Q7/6Q1/3Q4/5Q2 - -
2Q5/4Q3/6Q1/Q7/3Q4/1Q6/7Q/5Q2 - -
2Q5/4Q3/7Q/3Q4/Q7/6Q1/1Q6/5Q2 - -
2Q5/5Q2/1Q6/4Q3/7Q/Q7/6Q1/3Q4 - -
2Q5/5Q2/1Q6/6Q1/4Q3/Q7/7Q/3Q4 - -
2Q5/5Q2/1Q6/6Q1/Q7/3Q4/7Q/4Q3 - -
2Q5/5Q2/3Q4/1Q6/7Q/4Q3/6Q1/Q7 - -
2Q5/5Q2/3Q4/Q7/7Q/4Q3/6Q1/1Q6 - -
2Q5/5Q2/7Q/1Q6/3Q4/Q7/6Q1/4Q3 - -
2Q5/5Q2/7Q/Q7/3Q4/6Q1/4Q3/1Q6 - -
2Q5/5Q2/7Q/Q7/4Q3/6Q1/1Q6/3Q4 - -
2Q5/6Q1/1Q6/7Q/4Q3/Q7/3Q4/5Q2 - -
2Q5/6Q1/1Q6/7Q/5Q2/3Q4/Q7/4Q3 - -
2Q5/7Q/3Q4/6Q1/Q7/5Q2/1Q6/4Q3 - -
2Q5/Q7/6Q1/4Q3/7Q/1Q6/3Q4/5Q2 - -
3Q4/1Q6/4Q3/7Q/5Q2/Q7/2Q5/6Q1 - -
3Q4/1Q6/6Q1/2Q5/5Q2/7Q/4Q3/Q7 - -
3Q4/1Q6/6Q1/2Q5/5Q2/7Q/Q7/4Q3 - -
3Q4/1Q6/6Q1/4Q3/Q7/7Q/5Q2/2Q5 - -
3Q4/1Q6/7Q/4Q3/6Q1/Q7/2Q5/5Q2 - -
3Q4/1Q6/7Q/5Q2/Q7/2Q5/4Q3/6Q1 - -
3Q4/5Q2/7Q/1Q6/6Q1/Q7/2Q5/4Q3 - -
3Q4/5Q2/7Q/2Q5/Q7/6Q1/4Q3/1Q6 - -
3Q4/5Q2/Q7/4Q3/1Q6/7Q/2Q5/6Q1 - -
3Q4/6Q1/2Q5/7Q/1Q6/4Q3/Q7/5Q2 - -
3Q4/6Q1/4Q3/1Q6/5Q2/Q7/2Q5/7Q - -
3Q4/6Q1/4Q3/2Q5/Q7/5Q2/7Q/1Q6 - -
3Q4/6Q1/Q7/7Q/4Q3/1Q6/5Q2/2Q5 - -
3Q4/7Q/4Q3/2Q5/Q7/6Q1/1Q6/5Q2 - -
3Q4/7Q/Q7/2Q5/5Q2/1Q6/6Q1/4Q3 - -
3Q4/7Q/Q7/4Q3/6Q1/1Q6/5Q2/2Q5 - -
3Q4/Q7/4Q3/7Q/1Q6/6Q1/2Q5/5Q2 - -
3Q4/Q7/4Q3/7Q/5Q2/2Q5/6Q1/1Q6 - -
4Q3/1Q6/3Q4/5Q2/7Q/2Q5/Q7/6Q1 - -
4Q3/1Q6/3Q4/6Q1/2Q5/7Q/5Q2/Q7 - -
4Q3/1Q6/5Q2/Q7/6Q1/3Q4/7Q/2Q5 - -
4Q3/1Q6/7Q/Q7/3Q4/6Q1/2Q5/5Q2 - -
4Q3/2Q5/7Q/3Q4/6Q1/Q7/5Q2/1Q6 - -
4Q3/2Q5/Q7/5Q2/7Q/1Q6/3Q4/6Q1 - -
4Q3/2Q5/Q7/6Q1/1Q6/7Q/5Q2/3Q4 - -
4Q3/6Q1/1Q6/3Q4/7Q/Q7/2Q5/5Q2 - -
4Q3/6Q1/1Q6/5Q2/2Q5/Q7/3Q4/7Q - -
4Q3/6Q1/1Q6/5Q2/2Q5/Q7/7Q/3Q4 - -
4Q3/6Q1/3Q4/Q7/2Q5/7Q/5Q2/1Q6 - -
4Q3/6Q1/Q7/2Q5/7Q/5Q2/3Q4/1Q6 - -
4Q3/6Q1/Q7/3Q4/1Q6/7Q/5Q2/2Q5 - -
4Q3/7Q/3Q4/Q7/2Q5/5Q2/1Q6/6Q1 - -
4Q3/7Q/3Q4/Q7/6Q1/1Q6/5Q2/2Q5 - -
4Q3/Q7/3Q4/5Q2/7Q/1Q6/6Q1/2Q5 - -
4Q3/Q7/7Q/3Q4/1Q6/6Q1/2Q5/5Q2 - -
4Q3/Q7/7Q/5Q2/2Q5/6Q1/1Q6/3Q4 - -
5Q2/1Q6/6Q1/Q7/2Q5/4Q3/7Q/3Q4 - -
5Q2/1Q6/6Q1/Q7/3Q4/7Q/4Q3/2Q5 - -
5Q2/2Q5/4Q3/6Q1/Q7/3Q4/1Q6/7Q - -
5Q2/2Q5/4Q3/7Q/Q7/3Q4/1Q6/6Q1 - -
5Q2/2Q5/6Q1/1Q6/3Q4/7Q/Q7/4Q3 - -
5Q2/2Q5/6Q1/1Q6/7Q/4Q3/Q7/3Q4 - -
5Q2/2Q5/6Q1/3Q4/Q7/7Q/1Q6/4Q3 - -
5Q2/2Q5/Q7/6Q1/4Q3/7Q/1Q6/3Q4 - -
5Q2/2Q5/Q7/7Q/3Q4/1Q6/6Q1/4Q3 - -
5Q2/2Q5/Q7/7Q/4Q3/1Q6/3Q4/6Q1 - -
5Q2/3Q4/1Q6/7Q/4Q3/6Q1/Q7/2Q5 - -
5Q2/3Q4/6Q1/Q7/2Q5/4Q3/1Q6/7Q - -
5Q2/3Q4/6Q1/Q7/7Q/1Q6/4Q3/2Q5 - -
5Q2/3Q4/Q7/4Q3/7Q/1Q6/6Q1/2Q5 - -
5Q2/7Q/1Q6/3Q4/Q7/6Q1/4Q3/2Q5 - -
5Q2/Q7/4Q3/1Q6/7Q/2Q5/6Q1/3Q4 - -
6Q1/1Q6/3Q4/Q7/7Q/4Q3/2Q5/5Q2 - -
6Q1/1Q6/5Q2/2Q5/Q7/3Q4/7Q/4Q3 - -
6Q1/2Q5/7Q/1Q6/4Q3/Q7/5Q2/3Q4 - -
6Q1/2Q5/Q7/5Q2/7Q/4Q3/1Q6/3Q4 - -
6Q1/3Q4/1Q6/4Q3/7Q/Q7/2Q5/5Q2 - -
6Q1/3Q4/1Q6/7Q/5Q2/Q7/2Q5/4Q3 - -
6Q1/4Q3/2Q5/Q7/5Q2/7Q/1Q6/3Q4 - -
6Q1/Q7/2Q5/7Q/5Q2/3Q4/1Q6/4Q3 - -
7Q/1Q6/3Q4/Q7/6Q1/4Q3/2Q5/5Q2 - -
7Q/1Q6/4Q3/2Q5/Q7/6Q1/3Q4/5Q2 - -
7Q/2Q5/Q7/5Q2/1Q6/4Q3/6Q1/3Q4 - -
7Q/3Q4/Q7/2Q5/5Q2/1Q6/6Q1/4Q3 - -
Q7/4Q3/7Q/5Q2/2Q5/6Q1/1Q6/3Q4 - -
Q7/5Q2/7Q/2Q5/6Q1/3Q4/1Q6/4Q3 - -
Q7/6Q1/3Q4/5Q2/7Q/1Q6/4Q3/2Q5 - -
Q7/6Q1/4Q3/7Q/1Q6/3Q4/5Q2/2Q5 - -
Maybe it is helpful to work out a solution because adding two kings will reduce possible moves, I think.



my ftp site {remove http:// unless you like error messages}
Dann Corbit
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dieter Bürßner » 25 Jun 2004, 23:37

Geschrieben von:/Posted by: Dieter Bürßner at 26 June 2004 00:37:29:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Uri Blass at 26 June 2004 00:07:19:
323 moves will be enough for legal chess positions. 9 Q, 2 R, 2 B, 2 N, 1 K
9*27+2*14+2*13+2*8+10 (including 2 castling moves).
castling move are moves of the king and if the king can castle then by definition it have not more than 7 moves so you can replace 10 by 8.
If you are intersted in the maximal number of legal moves of 9 queens then you can try to solve by a program the maximal number of n queens for smaller n by trying all possibilities.
Yes, thanks for pointing it out. Additionally, at least one of those two rooks could not have more then 10 moves.
I thought the same. There are "only" 64!/(55!*9!) = 27,540,584,512 different positions with 9 queens. A program should be easily able to test 1e6 positions per second -> less than 8 hours (probably much less). A prove would need a bit more. Perhaps one of those queens happens to have less than 8 moves, and a 3rd knight would be better (but I doubt it).
This actually would be a nice programming excersize. One should be able to program it from scratch in a few hours.
Regards,
Dieter
Dieter Bürßner
 

Re: More WBEC output examination... {LGPGNVER}

Postby Dann Corbit » 25 Jun 2004, 23:47

Geschrieben von:/Posted by: Dann Corbit at 26 June 2004 00:47:25:
Als Antwort auf:/In reply to: Re: More WBEC output examination... {LGPGNVER} geschrieben von:/posted by: Dann Corbit at 26 June 2004 00:32:43:
I agree with your suggestions. One minor point later
"I will always get correct data from the user." is an intentional oversight. So (for instance) if you are expecting a FEN position, and you get one megabyte of binary data instead, your program does bad things. The reason I call it an intentional oversight is that it is not reasonable to assume perfect input.
There are also unintentional oversights. For instance, you may assume that no board position has more than 255 distinct moves possible. After all, the maximum ever discovered is 218. But the reasonable assumption may be incorrect. Perhaps there is some strange position with 257 moves possible.
323 moves will be enough for legal chess positions. 9 Q, 2 R, 2 B, 2 N, 1 K
9*27+2*14+2*13+2*8+10 (including 2 castling moves).
castling move are moves of the king and if the king can castle then by definition it have not more than 7 moves so you can replace 10 by 8.
If you are intersted in the maximal number of legal moves of 9 queens then you can try to solve by a program the maximal number of n queens for smaller n by trying all possibilities.
It is clear even without a program that 2 queens cannot contol 54 squares because if both of them are in the middle of the board they even do not get 50 squares together and queen not in the middle of the board can see at most
25 squares.
It means that you can easily replace 27*9 by 27+25*8(I believe that it is easy to prove that you it is not the best but I courld prove easily that you have not more than 305 moves.
I believe that not more than 300 moves is easy to calculate.
We need first table for maximal number of moves that n queens can goto.
1 queen 27 moves
2 queens 52 moves(d5 e3)
3 queens 77 moves(d5 e3 f6)
4 queens probably 100 moves(c4 e3 d6 f5)
1 queen in the centre d5 allow only 2 queens that do not prevent another queen to move in c3,e3,f4,f6 and queen not at the centre 4*4 board can see at most 23 squares so it does not help.

Interesting problem but I have no time to think about it now.
Maybe some mathematician can prove a general theorom about it(Tord?)
These are the 92 solutions to the n-queens problem for an 8x8 board:
1Q6/3Q4/5Q2/7Q/2Q5/Q7/6Q1/4Q3 - -
1Q6/4Q3/6Q1/3Q4/Q7/7Q/5Q2/2Q5 - -
1Q6/4Q3/6Q1/Q7/2Q5/7Q/5Q2/3Q4 - -
1Q6/5Q2/7Q/2Q5/Q7/3Q4/6Q1/4Q3 - -
1Q6/5Q2/Q7/6Q1/3Q4/7Q/2Q5/4Q3 - -
1Q6/6Q1/2Q5/5Q2/7Q/4Q3/Q7/3Q4 - -
1Q6/6Q1/4Q3/7Q/Q7/3Q4/5Q2/2Q5 - -
1Q6/7Q/5Q2/Q7/2Q5/4Q3/6Q1/3Q4 - -
2Q5/4Q3/1Q6/7Q/5Q2/3Q4/6Q1/Q7 - -
2Q5/4Q3/1Q6/7Q/Q7/6Q1/3Q4/5Q2 - -
2Q5/4Q3/6Q1/Q7/3Q4/1Q6/7Q/5Q2 - -
2Q5/4Q3/7Q/3Q4/Q7/6Q1/1Q6/5Q2 - -
2Q5/5Q2/1Q6/4Q3/7Q/Q7/6Q1/3Q4 - -
2Q5/5Q2/1Q6/6Q1/4Q3/Q7/7Q/3Q4 - -
2Q5/5Q2/1Q6/6Q1/Q7/3Q4/7Q/4Q3 - -
2Q5/5Q2/3Q4/1Q6/7Q/4Q3/6Q1/Q7 - -
2Q5/5Q2/3Q4/Q7/7Q/4Q3/6Q1/1Q6 - -
2Q5/5Q2/7Q/1Q6/3Q4/Q7/6Q1/4Q3 - -
2Q5/5Q2/7Q/Q7/3Q4/6Q1/4Q3/1Q6 - -
2Q5/5Q2/7Q/Q7/4Q3/6Q1/1Q6/3Q4 - -
2Q5/6Q1/1Q6/7Q/4Q3/Q7/3Q4/5Q2 - -
2Q5/6Q1/1Q6/7Q/5Q2/3Q4/Q7/4Q3 - -
2Q5/7Q/3Q4/6Q1/Q7/5Q2/1Q6/4Q3 - -
2Q5/Q7/6Q1/4Q3/7Q/1Q6/3Q4/5Q2 - -
3Q4/1Q6/4Q3/7Q/5Q2/Q7/2Q5/6Q1 - -
3Q4/1Q6/6Q1/2Q5/5Q2/7Q/4Q3/Q7 - -
3Q4/1Q6/6Q1/2Q5/5Q2/7Q/Q7/4Q3 - -
3Q4/1Q6/6Q1/4Q3/Q7/7Q/5Q2/2Q5 - -
3Q4/1Q6/7Q/4Q3/6Q1/Q7/2Q5/5Q2 - -
3Q4/1Q6/7Q/5Q2/Q7/2Q5/4Q3/6Q1 - -
3Q4/5Q2/7Q/1Q6/6Q1/Q7/2Q5/4Q3 - -
3Q4/5Q2/7Q/2Q5/Q7/6Q1/4Q3/1Q6 - -
3Q4/5Q2/Q7/4Q3/1Q6/7Q/2Q5/6Q1 - -
3Q4/6Q1/2Q5/7Q/1Q6/4Q3/Q7/5Q2 - -
3Q4/6Q1/4Q3/1Q6/5Q2/Q7/2Q5/7Q - -
3Q4/6Q1/4Q3/2Q5/Q7/5Q2/7Q/1Q6 - -
3Q4/6Q1/Q7/7Q/4Q3/1Q6/5Q2/2Q5 - -
3Q4/7Q/4Q3/2Q5/Q7/6Q1/1Q6/5Q2 - -
3Q4/7Q/Q7/2Q5/5Q2/1Q6/6Q1/4Q3 - -
3Q4/7Q/Q7/4Q3/6Q1/1Q6/5Q2/2Q5 - -
3Q4/Q7/4Q3/7Q/1Q6/6Q1/2Q5/5Q2 - -
3Q4/Q7/4Q3/7Q/5Q2/2Q5/6Q1/1Q6 - -
4Q3/1Q6/3Q4/5Q2/7Q/2Q5/Q7/6Q1 - -
4Q3/1Q6/3Q4/6Q1/2Q5/7Q/5Q2/Q7 - -
4Q3/1Q6/5Q2/Q7/6Q1/3Q4/7Q/2Q5 - -
4Q3/1Q6/7Q/Q7/3Q4/6Q1/2Q5/5Q2 - -
4Q3/2Q5/7Q/3Q4/6Q1/Q7/5Q2/1Q6 - -
4Q3/2Q5/Q7/5Q2/7Q/1Q6/3Q4/6Q1 - -
4Q3/2Q5/Q7/6Q1/1Q6/7Q/5Q2/3Q4 - -
4Q3/6Q1/1Q6/3Q4/7Q/Q7/2Q5/5Q2 - -
4Q3/6Q1/1Q6/5Q2/2Q5/Q7/3Q4/7Q - -
4Q3/6Q1/1Q6/5Q2/2Q5/Q7/7Q/3Q4 - -
4Q3/6Q1/3Q4/Q7/2Q5/7Q/5Q2/1Q6 - -
4Q3/6Q1/Q7/2Q5/7Q/5Q2/3Q4/1Q6 - -
4Q3/6Q1/Q7/3Q4/1Q6/7Q/5Q2/2Q5 - -
4Q3/7Q/3Q4/Q7/2Q5/5Q2/1Q6/6Q1 - -
4Q3/7Q/3Q4/Q7/6Q1/1Q6/5Q2/2Q5 - -
4Q3/Q7/3Q4/5Q2/7Q/1Q6/6Q1/2Q5 - -
4Q3/Q7/7Q/3Q4/1Q6/6Q1/2Q5/5Q2 - -
4Q3/Q7/7Q/5Q2/2Q5/6Q1/1Q6/3Q4 - -
5Q2/1Q6/6Q1/Q7/2Q5/4Q3/7Q/3Q4 - -
5Q2/1Q6/6Q1/Q7/3Q4/7Q/4Q3/2Q5 - -
5Q2/2Q5/4Q3/6Q1/Q7/3Q4/1Q6/7Q - -
5Q2/2Q5/4Q3/7Q/Q7/3Q4/1Q6/6Q1 - -
5Q2/2Q5/6Q1/1Q6/3Q4/7Q/Q7/4Q3 - -
5Q2/2Q5/6Q1/1Q6/7Q/4Q3/Q7/3Q4 - -
5Q2/2Q5/6Q1/3Q4/Q7/7Q/1Q6/4Q3 - -
5Q2/2Q5/Q7/6Q1/4Q3/7Q/1Q6/3Q4 - -
5Q2/2Q5/Q7/7Q/3Q4/1Q6/6Q1/4Q3 - -
5Q2/2Q5/Q7/7Q/4Q3/1Q6/3Q4/6Q1 - -
5Q2/3Q4/1Q6/7Q/4Q3/6Q1/Q7/2Q5 - -
5Q2/3Q4/6Q1/Q7/2Q5/4Q3/1Q6/7Q - -
5Q2/3Q4/6Q1/Q7/7Q/1Q6/4Q3/2Q5 - -
5Q2/3Q4/Q7/4Q3/7Q/1Q6/6Q1/2Q5 - -
5Q2/7Q/1Q6/3Q4/Q7/6Q1/4Q3/2Q5 - -
5Q2/Q7/4Q3/1Q6/7Q/2Q5/6Q1/3Q4 - -
6Q1/1Q6/3Q4/Q7/7Q/4Q3/2Q5/5Q2 - -
6Q1/1Q6/5Q2/2Q5/Q7/3Q4/7Q/4Q3 - -
6Q1/2Q5/7Q/1Q6/4Q3/Q7/5Q2/3Q4 - -
6Q1/2Q5/Q7/5Q2/7Q/4Q3/1Q6/3Q4 - -
6Q1/3Q4/1Q6/4Q3/7Q/Q7/2Q5/5Q2 - -
6Q1/3Q4/1Q6/7Q/5Q2/Q7/2Q5/4Q3 - -
6Q1/4Q3/2Q5/Q7/5Q2/7Q/1Q6/3Q4 - -
6Q1/Q7/2Q5/7Q/5Q2/3Q4/1Q6/4Q3 - -
7Q/1Q6/3Q4/Q7/6Q1/4Q3/2Q5/5Q2 - -
7Q/1Q6/4Q3/2Q5/Q7/6Q1/3Q4/5Q2 - -
7Q/2Q5/Q7/5Q2/1Q6/4Q3/6Q1/3Q4 - -
7Q/3Q4/Q7/2Q5/5Q2/1Q6/6Q1/4Q3 - -
Q7/4Q3/7Q/5Q2/2Q5/6Q1/1Q6/3Q4 - -
Q7/5Q2/7Q/2Q5/6Q1/3Q4/1Q6/4Q3 - -
Q7/6Q1/3Q4/5Q2/7Q/1Q6/4Q3/2Q5 - -
Q7/6Q1/4Q3/7Q/1Q6/3Q4/5Q2/2Q5 - -
Maybe it is helpful to work out a solution because adding two kings will reduce possible moves, I think.
This one has 170 possible:
White(1): setboard QB1k4/6Q1/3KQ3/7Q/1Q6/3Q4/5Q2/2Q5 w - -
White(1): perft 1
total moves=170 time=0.00
Construction of a position with a huge number of moves seems quite difficult.



my ftp site {remove http:// unless you like error messages}
Dann Corbit
 

PreviousNext

Return to Archive (Old Parsimony Forum)

Who is online

Users browsing this forum: No registered users and 28 guests