complete opening tree stats
Jeffrey A. Young
I've compiled some statistics on the size of a complete
opening tree, and I'm wondering if anyone else has more
information or can point me to published information like
this. I'm talking about making every legal move at
each ply without pruning and without eliminating
transpositions.
1st ply: size 20
2nd ply: size 400 (growth 20)
3rd ply: size 8902 (growth 22.26), including 12 checks
4th ply: size 197281 (growth 22.16), including 8 mates
5th ply: size 4865609 (growth 24.66), including 347 mates,
of which 281 are just extensions of 4th-ply mates
(for the opposite color of course) (= 66 new mates).
Jeff
Robert Hyatt
Jeffrey A. Young <jyo...@ultra0.rdrc.rpi.edu> wrote:
: I've compiled some statistics on the size of a complete
: Jeff
Crafty will compute this for you, *if* you have a lot of time. set up
the position you want (in this case, take no action.
type "perft 1" (one ply enumeration) and you get
total moves=20
perft 2
total moves=420
perft 3
total moves=9322
perft 4
total moves=206603
perft 5
total moves=5,072,212
these get slow after this point...
--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
Alexander Nitschke
Is this a bug in Crafty or why does it get 420 moves on 2 ply? Me seems
that there should be only 400 moves like Jeffrey wrote above. The other
numbers of Crafty are also higher, but I think the numbers of Jeffrey
are more credible.
--
Alexander
Andreas Stabel
In article <6bd9uv$9ev$1...@juniper.cis.uab.edu>, hy...@cis.uab.edu says...
I also used this to test my program. I've a lot of other positions too which
I generate all the possible moves from to check my move generation.
Here is my statistics from the opening position:
Ply| Number of nodes | Total # nodes | # Nodes / Prev. # Nodes
---+-----------------+---------------+------------------------
0 | 1 | 1 |
1 | 20 | 21 | 20.000
2 | 400 | 421 | 20.000
3 | 8902 | 9323 | 22.255
4 | 197281 | 206604 | 22.161
5 | 4865609 | 5072213 | 24.663
6 | 119060324 | 124132537 | 24.470
7 | 3195901860 | 3320034397 | 26.843
Note that the total number of nodes is one more than Mr. Hyatt gets
because he doesn't count the initial position.
Regards
Andreas Stabel
Here are some lines to satisfy my news server:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Simon Read
Alexander Nitschke <alexander...@ww.tu-berlin.de> wrote:
>Robert Hyatt wrote:
>> 20
>> 420
>> 9322
>> Jeffrey A. Young <jyo...@ultra0.rdrc.rpi.edu> wrote:
>>
>> : 1st ply: size 20
>> : 2nd ply: size 400 (growth 20)
>> : 3rd ply: size 8902 (growth 22.26), including 12 checks
Alexander wrote:
>Is this a bug in Crafty or why does it get 420 moves on 2 ply? Me seems
>that there should be only 400 moves like Jeffrey wrote above.
One of them is cumulative, i.e. 420 = 400 + 20,
9322 = 8902 + 400 + 20, etc.
Regards
Simon
Robert Hyatt
Alexander Nitschke <alexander...@ww.tu-berlin.de> wrote:
: Is this a bug in Crafty or why does it get 420 moves on 2 ply? Me seems
: that there should be only 400 moves like Jeffrey wrote above. The other
: numbers of Crafty are also higher, but I think the numbers of Jeffrey
: are more credible.
Crafty's numbers are exactly correct. when you do perft 2, it does
a complete 2-ply search, no pruning, and gives the total. Which means
perft 2 gives the total positions at ply=1 *and* ply=2...
Komputer Korner
This is a tower of Babel exercise with 12,498 steps. Assuming a 20 legal
move average the final number is 12,498^20 =8.6x10^81 which is more than the
total number of atoms in the universe. So Mr. Young, you will be old
before your time by the time you finish the exercise.
--
- -
Komputer Korner
The inkompetent komputer
If you see a 1 in my email address, take it out before replying.
Please do not email both me and the r.g.c.c. at the same time. I read all
the postings on r.g.c.c.
Also every statement of mine should be taken with a grain of salt. Read at
your own risk and
assume that it is only this humble komputer's opinion.
Jeffrey A. Young wrote in message <6bd1k1$n...@ultra0.rdrc.rpi.edu>...
>I've compiled some statistics on the size of a complete
>opening tree, and I'm wondering if anyone else has more
>information or can point me to published information like
>this. I'm talking about making every legal move at
>each ply without pruning and without eliminating
>transpositions.
>
>1st ply: size 20
>2nd ply: size 400 (growth 20)
>3rd ply: size 8902 (growth 22.26), including 12 checks
Jeffrey A. Young
In article <6bfvcl$n2v$1...@tor-nn1.netcom.ca>,
Komputer Korner <kor...@netcom.ca> wrote:
>This is a tower of Babel exercise with 12,498 steps. Assuming a 20 legal
>move average the final number is 12,498^20 =8.6x10^81 which is more than the
>total number of atoms in the universe. So Mr. Young, you will be old
>before your time by the time you finish the exercise.
By "complete" I certainly did not mean "to the end of the game",
only "without pruning". The idea is to find interesting (unforced)
mates in very few moves, as well as other statistics like size.
I have also done some transposition elimination now. In case
anyone is interested or can verify these:
3rd ply -- 5362 unique positions (out of 8902 unique move sequences)
4th ply -- 71852 unique positions (out of 197281 sequences)
For the 5th ply, I'll need to distinguish castling-breakers
for accurate stats, since e.g. (Nf3 xxx Rg1 yyy Rh1) is not the
same position as (Nf3 xxx Ng5 yyy Nf3) even though all pieces
are in the same places. Right now it's moot since I don't
seem to have the computer resources to do the 5th ply.
Komputer Korner
How do you figure out the number of transpositions?
--
- -
Komputer Korner
The inkompetent komputer
If you see a 1 in my email address, take it out before replying.
Please do not email both me and the r.g.c.c. at the same time. I read all
the postings on r.g.c.c.
Also every statement of mine should be taken with a grain of salt. Read at
your own risk and
assume that it is only this humble komputer's opinion.
Jeffrey A. Young wrote in message <6bg2dj$7...@ultra1.rdrc.rpi.edu>...
Jim Caccamise
I assume that when processing the moves all positions reached are
recorded and a transposition is detected when a move results in a
previously recorded position. (Of course, "castling status" and
"en-passant status" must be stored as part of the position for accurate
transposition detection. When analyzing from the starting position,
"en-passant status" isn't needed until ply 4, and "castling status" isn't
needed until ply 9. Technically, "position repetition count" and "50-move
rule count" should also be stored for each position to detect exact
position equivalence for transpositions. Practically, status related to
draw claims are frequently ignored when detecting transpositions.) Once
a transposition is detected, further moves in that branch need not be
counted for transposition, in fact these moves don't need to be traced at
all since they will be identical to those from the source transposed
position.
There are several nuances to consider in detecting position repetitions
and transpositions. One I struggled with involves a position created by
a pawn move that would allow en-passant capture except that the move
discovers check, preventing the en-passant from legally being executed.
The rules of chess are ambiguous regarding how this would be counted for
purposes of three time repetition. I think if this position re-occurs it
should be considered a repetition, since the same exact future moves are
possible? (The first occurrence differs only in the sense that en-passant
would have been possible if the King weren't in check.) With this
interpretation, care must be taken in flagging a pawns en-passant status
only when en-passant is a legal move. (Another example is where
capturing en-passant isn't legal because it would expose the King to
discovered check.)
A similar situation involving castling occurs when a King which still
has castling privileges is in check and the only legal move to escape
check involves giving up a castling privilege. (i.e. moving the King or
capturing the checking piece with the Rook.) So, depending on the
repetition of position interpretation, care may be needed to flag the
castling privilege only when it isn't forcibly given up by all legal
moves available.
How do you think these situations should be handled? Does anyone know
if there are any official interpretation of position repetition rules for
the above situations? Any comments on how repetition and draw count
status should be handled in identifying transpositions?
--
Jim Caccamise
(Remove X from e-mail address, anti-spam)
Komputer Korner <kor...@netcom.ca> wrote in article
<6bg4dg$r6l$1...@tor-nn1.netcom.ca>...
Komputer Korner
The rule book makes it clear. See below for the exact wording of the FIDE
rules.
"Positions as in (a) and (b) are considered the same, if the same player has
the move, pieces of the same kind and colour occupy the same squares, and
the possible moves of all the pieces of both players are the same. Positions
are not the same if a pawn could have been captured en passant or if the
right to castle immediately or in the future has been changed."
The only perhaps confusing part to this is that one could change one of
either the knights or rooks and it would be still considered the same
position. Ex: The 2 knights could change places but it would still be
considered the same position. Not the rooks if it is the first move of the
rooks because of the loss of castling but the rooks could be switched after
that and it would be the same position.
--
- -
Komputer Korner
The inkompetent komputer
If you see a 1 in my email address, take it out before replying.
Please do not email both me and the r.g.c.c. at the same time. I read all
the postings on r.g.c.c.
Also every statement of mine should be taken with a grain of salt. Read at
your own risk and
assume that it is only this humble komputer's opinion.
Jim Caccamise wrote in message <01bd34ab$ddd4ba80$afca06d0@jimc>...
Anders Thulin
In article <01bd34ab$ddd4ba80$afca06d0@jimc>,
Jim Caccamise <Xc...@magicnet.net> wrote:
> There are several nuances to consider in detecting position repetitions
>and transpositions. One I struggled with involves a position created by
>a pawn move that would allow en-passant capture except that the move
>discovers check, preventing the en-passant from legally being executed.
>The rules of chess are ambiguous regarding how this would be counted for
>purposes of three time repetition.
Can you pinpoint the ambiguity? As I read the rules, there's
nothing ambiguous about them at all.
Checking en-passant status is not necessary in this example: pawn
moves are irreversible, so the same position cannot be repeated. Once
a pawn has moved, the old record of positions can be thrown away, as
they cannot apply anymore.
Perhaps you are thinking of handling transpositions and applying
previous score evaluations at several places in the search tree?
>I think if this position re-occurs it
>should be considered a repetition, since the same exact future moves are
>possible?
Not really. If the position occurs again the rules of chess have
been violated. If you are writing a chess program, I suggest you write
that program so that it doesn't accept or generates illegal moves.
> A similar situation involving castling occurs when a King which still
>has castling privileges is in check and the only legal move to escape
>check involves giving up a castling privilege. (i.e. moving the King or
>capturing the checking piece with the Rook.) So, depending on the
>repetition of position interpretation, care may be needed to flag the
>castling privilege only when it isn't forcibly given up by all legal
>moves available.
I'm not certain I understand that. What does the check has to do
with detecting three-fold repetion? None, as far as I can see.
As any king move loses castling rights, no matter for what reasons,
I don't understand why you think the special case when the king is in
check is important?
--
Anders Thulin Anders...@lejonet.se 013 - 23 55 32
Telia ProSoft AB, Teknikringen 6, S-583 30 Linkoping, Sweden
Simon Read
"Komputer Korner" <kor...@netcom.ca> wrote:
>This is a tower of Babel exercise with 12,498 steps. Assuming a 20 legal
>move average the final number is 12,498^20 =8.6x10^81
Nice try, KK.
20 legal moves, 12,498 ply, we get 20^12,498 which is
10^(1.30103*12,498)
which is 10^16,260.27289
which is 1.874 x 10^16,260
which is unbelievably bigger than 8.6x10^81.
You were just giving him the smaller number, to
sucker him into trying, weren't you?
Shame on you, KK.
Jim Caccamise
Anders Thulin <a...@nala.devnet.lejonet.se> wrote in article
<6bmb61$r...@nala.devnet.lejonet.se>...
> In article <01bd34ab$ddd4ba80$afca06d0@jimc>,
> Jim Caccamise <Xc...@magicnet.net> wrote:
>
> > There are several nuances to consider in detecting position
repetitions
> >and transpositions. One I struggled with involves a position created
by
> >a pawn move that would allow en-passant capture except that the move
> >discovers check, preventing the en-passant from legally being
executed.
> >The rules of chess are ambiguous regarding how this would be counted
for
> >purposes of three time repetition.
>
> Can you pinpoint the ambiguity? As I read the rules, there's
> nothing ambiguous about them at all.
>
> Checking en-passant status is not necessary in this example: pawn
> moves are irreversible, so the same position cannot be repeated. Once
> a pawn has moved, the old record of positions can be thrown away, as
> they cannot apply anymore.
Yes but what I am referring to is the position after the pawn has
moved and possible repetitions with the same piece placement, where the
first position en-passant is a move option except that it isn't possible
because of the requirements of getting out of check. The repeated
position piece placement is identical but en-passant wouldn't be an
option regardless of the status of the King being in check. Do we agree
that these are to be considered the same position, because the en-passant
move isn't legal in the first position.
>
> Perhaps you are thinking of handling transpositions and applying
> previous score evaluations at several places in the search tree?
>
> >I think if this position re-occurs it
> >should be considered a repetition, since the same exact future moves
are
> >possible?
>
> Not really. If the position occurs again the rules of chess have
> been violated. If you are writing a chess program, I suggest you write
> that program so that it doesn't accept or generates illegal moves.
I'm talking about the "position" occurring again with the same exact
piece placements, this is certainly possible and doesn't require illegal
moves. Although the first occurrence differs in the respect that
en-passant would be allowed if the King weren't in check, but the
obligation to get out of check makes capturing en-passant illegal. So,
the positions have exactly the same move possibilities and the same
future game tree.
>
> > A similar situation involving castling occurs when a King which
still
> >has castling privileges is in check and the only legal move to escape
> >check involves giving up a castling privilege. (i.e. moving the King
or
> >capturing the checking piece with the Rook.) So, depending on the
> >repetition of position interpretation, care may be needed to flag the
> >castling privilege only when it isn't forcibly given up by all legal
> >moves available.
>
> I'm not certain I understand that. What does the check has to do
> with detecting three-fold repetion? None, as far as I can see.
>
Again I am talking about the position when the King is in check being
repeated, but the first time the King still had the right to castle but
the obligation to get out of check removes the Kings right to castle.
The later occurrence of the position obviously wouldn't have the right to
castle because it was forcibly given up by the move in the first
occurrence. I assume you agree with me that the positions count as a
repetition, since in the first position the King although still having
the right to castle is unable to do so because of the obligation to get
out of check, and the position requires a move that gives up the right to
castle. So, once again, the two positions have the same move
possibilities and the exact same future game tree. (The fact that the
first position still had the right to castle if it was legal is a moot
point since a move is forced that gives up the right to castle.)
> As any king move loses castling rights, no matter for what reasons,
> I don't understand why you think the special case when the king is in
> check is important?
> --
See above. Do you now understand my question regarding the equivalence
of positions for en-passant and castling where these possibilities would
exist on the first position occurrence if they weren't prohibited by the
requirement to escape check, or the prohibition of placing the King in
check in the other en-passant example I mentioned in my first post?
(Sorry that sentence was so long.) If I can explain this concept
clearly, I expect some argument regarding whether these are repetitions.
If my interpretation is correct, I assume many chess programs will not
detect these repetitions correctly because the will have different
en-passant or castling status flags set for these positions.
Jeffrey A. Young
In article <6bg4dg$r6l$1...@tor-nn1.netcom.ca>,
From reading here, it seems the "standard" way is to use hash
tables to store a representation of the position.
I store and search a tree of string representations of the
positions. I do include en passant information, which first
becomes important at ply 4 to distiguish for example
1 e4 g5 2 e5 f5 from 1 e4 f5 2 e5 g5
I am not yet including castle-breaking information which
will first be important at ply 5 to distinguish for example
1 e3 xxx 2 Ke2 yyy 3 Ke1 from 1 e3 xxx 2 Be2 yyy 3 Bf1
Although perhaps these two should not be considered different,
since all pieces are in the same positions and exactly the
same set of legal moves are available (see related posts).
Jeff
Jeffrey A. Young
In article <6bmb2v$qnn$1...@tor-nn1.netcom.ca>,
Komputer Korner <kor...@netcom.ca> wrote:
>The rule book makes it clear. See below for the exact wording of the FIDE
>rules.
>
>"Positions as in (a) and (b) are considered the same, if the same player has
>the move, pieces of the same kind and colour occupy the same squares, and
>the possible moves of all the pieces of both players are the same. Positions
>are not the same if a pawn could have been captured en passant or if the
>right to castle immediately or in the future has been changed."
That is fairly clear, but if that is the correct wording, then
"or in the future" means that the following two starting sequences
in fact give different positions and that castling status becomes
a factor first in the 5th ply, not the 9th:
1 e3 xxx 2 Ke2 yyy 3 Ke1
1 e3 xxx 2 Be2 yyy 3 Bf1
Jeff
Jeffrey A. Young
In article <01bd3570$f19c3f00$afca06d0@jimc>,
How about an example to clarify this. Here is the shortest one
I can think of on the spur of the moment:
1 e4 e5 2 d4 ed 3 e5 Qe7 4 Qd3 d5
1 e4 e5 2 d4 ed 3 e5 Qe7 4 Qd2 d6 5 Qd3 d5
Same piece positions, same legal moves available, different en-passant
status. Same position? The FIDE wording seems to indicate that they
are NOT for purposes of repetition, although there is no way to repeat
the availability of an en-passant capture on the same square anyway.
And for purposes of position evaluation, all that is important is
that all current and future legal moves are exactly the same, so for
that purpose, the two above are the same position.
The question of castling status is different, but that is handled
more clearly by the FIDE wording (any difference in castling status
is a different position, which makes sense for position evaluation).
Jeff
Robert Hyatt
It doesn't matter. EP is not legal in *either* position. The rule says
"same moves are possible". IF an EP capture leaves you in check, it is
not possible...
Robert Hyatt
: Komputer Korner <kor...@netcom.ca> wrote:
:>How do you figure out the number of transpositions?
: From reading here, it seems the "standard" way is to use hash
: tables to store a representation of the position.
: I store and search a tree of string representations of the
: positions. I do include en passant information, which first
: becomes important at ply 4 to distiguish for example
: 1 e4 g5 2 e5 f5 from 1 e4 f5 2 e5 g5
: I am not yet including castle-breaking information which
: will first be important at ply 5 to distinguish for example
: 1 e3 xxx 2 Ke2 yyy 3 Ke1 from 1 e3 xxx 2 Be2 yyy 3 Bf1
: Although perhaps these two should not be considered different,
: since all pieces are in the same positions and exactly the
: same set of legal moves are available (see related posts).
There are a couple of good ways to store openings. I've used both.
(1) store hashed positions as I do now. Easy to catch transpositions
with no extra work.
(2) store each move as an 8 bit value, which is an index into the output
of a move generator that enumerates every legal move in any position, and
which has a reproducible move order. This makes it harder to catch
transpositions, but gives a very compact "tree". Here transpositions require
a lot of work to "find" where in (1) they don't. Also this tends to be stored
as a linked list since a move by itself is meaningless...
: Jeff
--
Jeffrey A. Young
In article <6bnlhh$cr$2...@juniper.cis.uab.edu>,
Robert Hyatt <hy...@cis.uab.edu> wrote:
>There are a couple of good ways to store openings. I've used both.
>
>(1) store hashed positions as I do now. Easy to catch transpositions
>with no extra work.
>
>(2) store each move as an 8 bit value, which is an index into the output
>of a move generator that enumerates every legal move in any position, and
>which has a reproducible move order. This makes it harder to catch
>transpositions, but gives a very compact "tree". Here transpositions require
>a lot of work to "find" where in (1) they don't. Also this tends to be stored
>as a linked list since a move by itself is meaningless...
Interesting; I hadn't thought of that (#2). It seems an ideal method
of compacting a large opening-book database, but also leaving it
vulnerable to obsolescence by any change to the move generator. It
also seems that it would be really slow, having to enumerate a bunch
of extra moves when generating a board. For an extra 4 bits per move
you could store the from- and to- squares and be independent of the
move generator. Fast board generation too...
Jeff
Robert Hyatt
Jeffrey A. Young <jyo...@ultra0.rdrc.rpi.edu> wrote:
: How about an example to clarify this. Here is the shortest one
: I can think of on the spur of the moment:
: 1 e4 e5 2 d4 ed 3 e5 Qe7 4 Qd3 d5
: 1 e4 e5 2 d4 ed 3 e5 Qe7 4 Qd2 d6 5 Qd3 d5
: Same piece positions, same legal moves available, different en-passant
: status. Same position? The FIDE wording seems to indicate that they
: are NOT for purposes of repetition, although there is no way to repeat
: the availability of an en-passant capture on the same square anyway.
: And for purposes of position evaluation, all that is important is
: that all current and future legal moves are exactly the same, so for
: that purpose, the two above are the same position.
the two positions are identical, because the enpassant move is not legal
in either one. Leaving your king in check is strictly forbidden, so the
EP rule never comes into play...
: The question of castling status is different, but that is handled
: more clearly by the FIDE wording (any difference in castling status
: is a different position, which makes sense for position evaluation).
because castling status is not attached to the previous move like the
EP rule is. Castling status is of longer duration than a single move,
unless it is lost forever...
Robert Hyatt
: Jeff
first, I'd probably use a table-driven move generator so computation time
would be minimal. And it is doubtful I'd ever change the tables or move
generator once this was working. IE I haven't changed Crafty's move generator
in a couple of years, at least...
12 bits would be ok, although 1.5X bigger.
I assume that those using #2 are worried about disk space...
Jeffrey A. Young
>recorded and a transposition is detected when a move results in a
>previously recorded position. (Of course, "castling status" and
>"en-passant status" must be stored as part of the position for accurate
>transposition detection. When analyzing from the starting position,
>"en-passant status" isn't needed until ply 4, and "castling status" isn't
>needed until ply 9.
For transposition alone, castling differences may not show up until
ply 9 (actually I get 11), but if the transposition analysis is to be
useful for any position evaluation, castling status needs to be used
to distinguish positions starting at ply 5, since that's where move
futures will start diverging. For example the following two positions
should not get the same evaluation score:
1 e3 xxx 2 Ke2 yyy 3 Ke1
1 e3 xxx 2 Be2 yyy 3 Bf1
because the lookahead tree for the first one will not contain e.g.
3 ... zzz 4 Bc4 www 5 Nf3 vvv 6 O-O
Jeff
Komputer Korner
Whoops, it must have been another late night when I wrote that. Of course
you are right.
--
- -
Komputer Korner
The inkompetent komputer
If you see a 1 in my email address, take it out before replying.
Please do not email both me and the r.g.c.c. at the same time. I read all
the postings on r.g.c.c.
Also every statement of mine should be taken with a grain of salt. Read at
your own risk and
assume that it is only this humble komputer's opinion.
Simon Read wrote in message <34df0...@news.cranfield.ac.uk>...
Ilias Kastanas
In article <6bmb61$r...@nala.devnet.lejonet.se>,
Anders Thulin <a...@nala.devnet.lejonet.se> wrote:
>In article <01bd34ab$ddd4ba80$afca06d0@jimc>,
>Jim Caccamise <Xc...@magicnet.net> wrote:
>
>>and transpositions. One I struggled with involves a position created by
>>a pawn move that would allow en-passant capture except that the move
>>discovers check, preventing the en-passant from legally being executed.
>>The rules of chess are ambiguous regarding how this would be counted for
>>purposes of three time repetition.
>
> Can you pinpoint the ambiguity? As I read the rules, there's
>nothing ambiguous about them at all.
>
>moves are irreversible, so the same position cannot be repeated. Once
>a pawn has moved, the old record of positions can be thrown away, as
>they cannot apply anymore.
>
>previous score evaluations at several places in the search tree?
>
>>I think if this position re-occurs it
>>should be considered a repetition, since the same exact future moves are
>>possible?
>
> Not really. If the position occurs again the rules of chess have
>been violated. If you are writing a chess program, I suggest you write
>that program so that it doesn't accept or generates illegal moves.
>
>>has castling privileges is in check and the only legal move to escape
>>check involves giving up a castling privilege. (i.e. moving the King or
>>capturing the checking piece with the Rook.) So, depending on the
>>repetition of position interpretation, care may be needed to flag the
>>castling privilege only when it isn't forcibly given up by all legal
>>moves available.
>
> I'm not certain I understand that. What does the check has to do
>with detecting three-fold repetion? None, as far as I can see.
>
>I don't understand why you think the special case when the king is in
>check is important?
In Kh4, Pd5; Qd8, Pe7 after 1.. e5+ 2. Kh5, Qe8+ 3. Kh4, Qd8+
is this the 2nd occurrence of the position, or the 1st? It seems logical
to say "2nd", the possibilities being the same.
Likewise in Ra1; Ke8, Rh8 (castling possible), after 1. Re1+ -
d1+ - e1+; as 1... 0-0 was illegal.
But this logic might lead to the following: Ke1, Ba1, Pb4, c3,
d2, e6, f2, g6, h5; Ke8, Rh8, Bf8, Bb3, Pb5, c4, d3, e2, e7, f3, g7, h6
(castling possible). There is no legal sequence of moves that can bring
about ... 0-0. Black can retain the "theoretical" right to castle,
by Bb3-c2-b3. If now 1. Bb2, Kd8 2. Ba1, Ke8 is this a "2nd"? It is
uncomfortable to say "yes"...
For simplicity and uniformity, I would suggest avoiding this line
of thought and making mere presence of castling right count as a difference;
and even though the e.p. case is not problematical, maybe it should be
included too... making all answers above "1st".
Ilias
Jim Caccamise
Jeffrey A. Young <jyo...@ultra0.rdrc.rpi.edu> wrote in article
<6bnkkr$1...@ultra0.rdrc.rpi.edu>...
> In article <6bmb2v$qnn$1...@tor-nn1.netcom.ca>,
> Komputer Korner <kor...@netcom.ca> wrote:
> >The rule book makes it clear. See below for the exact wording of the
FIDE
> >rules.
> >
> >"Positions as in (a) and (b) are considered the same, if the same
player has
> >the move, pieces of the same kind and colour occupy the same squares,
and
> >the possible moves of all the pieces of both players are the same.
Positions
> >are not the same if a pawn could have been captured en passant or if
the
> >right to castle immediately or in the future has been changed."
>
> That is fairly clear, but if that is the correct wording, then
> "or in the future" means that the following two starting sequences
> in fact give different positions and that castling status becomes
> a factor first in the 5th ply, not the 9th:
> 1 e3 xxx 2 Be2 yyy 3 Bf1
>
>
Yes, of course, you are right. ( But, xxx must be a Knight move, and
yyy must be a return by the Knight to it's original square.) For some
bizarre reason I was off in left field and calculated this completely
incorrectly.
Simon Read
"Komputer Korner" <kor...@netcom.ca> wrote:
>Whoops, it must have been another late night when I wrote that. Of course
>you are right.
Of course, you would never ever ever EVER hear me admit that
I have made the same mistake upon occasion.
Regards
Simon
Komputer Korner
Will the program actually produce a count of all possible transpositions
like the original poster wanted?. Of what value this would be, I couldn't
possibly guess.
--
- -
Komputer Korner
The inkompetent komputer
If you see a 1 in my email address, take it out before replying.
Please do not email both me and the r.g.c.c. at the same time. I read all
the postings on r.g.c.c.
Also every statement of mine should be taken with a grain of salt. Read at
your own risk and
assume that it is only this humble komputer's opinion.
Robert Hyatt wrote in message <6bnlhh$cr$2...@juniper.cis.uab.edu>...
>There are a couple of good ways to store openings. I've used both.
>
>(1) store hashed positions as I do now. Easy to catch transpositions
>with no extra work.
>
>(2) store each move as an 8 bit value, which is an index into the output
>of a move generator that enumerates every legal move in any position, and
>which has a reproducible move order. This makes it harder to catch
>transpositions, but gives a very compact "tree". Here transpositions
require
>a lot of work to "find" where in (1) they don't. Also this tends to be
stored
>as a linked list since a move by itself is meaningless...
>
>
>
>: Jeff
Jeffrey A. Young
In article <01bd35d6$44e3dfa0$a7ca06d0@jimc>,
Jim Caccamise <Xc...@magicnet.net> wrote:
>Jeffrey A. Young <jyo...@ultra0.rdrc.rpi.edu> wrote in article
><6bnkkr$1...@ultra0.rdrc.rpi.edu>...
>> In article <6bmb2v$qnn$1...@tor-nn1.netcom.ca>,
>> Komputer Korner <kor...@netcom.ca> wrote:
>> >The rule book makes it clear. See below for the exact wording of the
>FIDE
>> >rules.
>> >
>> >"Positions as in (a) and (b) are considered the same, if the same
>player has
>> >the move, pieces of the same kind and colour occupy the same squares,
>and
>> >the possible moves of all the pieces of both players are the same.
>Positions
>> >are not the same if a pawn could have been captured en passant or if
>the
>> >right to castle immediately or in the future has been changed."
>>
>> That is fairly clear, but if that is the correct wording, then
>> "or in the future" means that the following two starting sequences
>> in fact give different positions and that castling status becomes
>> a factor first in the 5th ply, not the 9th:
>> 1 e3 xxx 2 Ke2 yyy 3 Ke1
>> 1 e3 xxx 2 Be2 yyy 3 Bf1
>
>yyy must be a return by the Knight to it's original square.)
Why do you think that? xxx and yyy represent any 2 legal moves by black.
Jeff