Author: Dave Gomboc
Date: 02:26:03 05/16/99
Go up one level in this thread
On May 16, 1999 at 02:57:06, KarinsDad wrote:
>On May 15, 1999 at 15:28:56, Dave Gomboc wrote:
>
>[snip]
>>before draw" rule... it took them about 61 moves. So anyway, yes, please allow
>>every legal position.
>
>Dave,
>
>You sound like one of the purists I mentioned before. Tell me it isn't so. :)
Like (I think) most computer programmers, I like stuff that doesn't break in
weird freaky cases that I have to hunt down at considerable pain and expense.
Does that make me a purist?
>In order to require all bits in the 25 bytes, the schema that Eugene and I
>discussed would require that all pawns are off of the board, that there is 12
>promoted pieces on the board, that all of the original pieces are still on the
>board and that all pieces are on row 2 through 7. This means that there are 28
>pieces with no pawn protection within the 48 squares of the middle of the board.
>It seems a little much, doesn't it.
25 bytes is really annoying. It might as well be 32 bytes. 24 bytes would be
much better. (in-memory alignment issue for array of struct)
>Instead, it would seem more reasonable to use a 22 byte or 23 byte
>representation knowing that super bizarre positions are not really feasible
>(possible by lunatics, but not feasible in normal chess play).
>
>In fact, I was thinking that you could use whichever representation seems best
>for the situation. For endgames where there are fewer pawns and pieces, you can
>be assured that 22 bytes will be sufficient (and the 50-move rule would be
>required). The same applies to openings (I think that the original position will
>require 14 bytes).
>
>The minimum number of ply to get beyond a 22 byte structure (and this is with
>really bizzare play) is 33. For example, e4 e5, d4 d5, Nf3 Nc6, Nc3 Nf6, Bb5
>Bb4, Bf5 Bf4, Qd3 Qd6, Ke2 Ke7, Rad1 Rad8, Rd2 Rd7, h4 h5, Rh2 g5, hg Rh7, g6
>b6, g7 a5, g8(Q) a4, Qg7.
>
>If you are creating an opening book, I doubt you would go to the trouble of
>entering in such garbage.
>
>From this example, you can realize how really bizarre the play must be.
>
>Would you really want such a thing in your database?
Weird stuff happens. Did you think I ever expected to hear about the position I
mentioned in my last post in a real game? I might not enter in such garbage,
but you never know what an automated too might try to do.
>> This is also why I would prefer to include the adjustment
>>for the 50-move rule. (100-ply rule! Keep that in mind!) It would be better
>>to have something that you can use for lots of stuff, not just a particular
>>application (opening book).
>
>Agreed. Hence, 22 bytes with 50-move rule, 21 bytes without. If someone is just
>using the schema for an opening book, it couldn't hurt for them to disable the
>50-move rule (and that would be their choice).
>
>> Maybe a specialization here is worth a bit or two,
>>but I think that hardly justifies it overall because the lost information may be
>>of some slight important for some endings that are reached by opening theory.
>
>I doubt that dropping the 50-move rule out of an opening book would make much
>difference here.
What are you saving by not including repetition and 50-move rule information?
If the answer is "quite a lot", then you have a reasonable argument. If the
answer is "not much", then why bother?
Incidentally, the most efficient way to preserve this information may be to
store the position reached by the last pawn push or capture, and all subsequent
moves made from that position. Of course, each move can be represented by
ranking legal moves in a predefined move generation order.
Indeed, this technique could just be used from the start position too. It would
beat 24 bytes for short games, but be worse for long ones:
ridiculous though ballpark assumption: every position reached has 30 moves.
(so we need 30^ply <= 2^bits)
game length in ply bits required (bytes)
10 50 6 2/8
20 99 12 3/8
30 148 18 4/8
40 197 24 5/8
higher is no good, of course.
BUT, if your needs are for entire games, you get to divide the cost of this by
each position, so since a 40 ply game has 41 positions, we are encoding a
position in well under 1 byte per position. ;-)
Now, if we want to consider only "reasonable moves" -- i.e. "you wouldn't want
to enter THAT into your database, would you? <grin>" then we can use a branching
factor arbitrarily lower, let's choose 8 (so we can only represent eight
candidate moves from a position -- the 8 are probably the best 8 scoring after
some deep search by a predefined chess engine :-). Such an assumption, if it
were actually able to hold, would absolutely destroy the bit-packing example,
but of course it isn't going to work in reality, where people blunder.
>>You might consider if it is worth supporting chess variants that do not
>>introduce extra pieces as well. !?
>
>Heck, I cannot even seem to get a consensus on the schema for normal chess.
>
>>
>>BTW, if you keep a notepad and pencil/pen by your bed, then you can scribble
>>down ideas even when you are on the verge of falling asleep. :-)
>
>What and wake KarinsMom with a nightlight? Not in this lifetime! I enjoy my life
>as it is, thank you (a loving wife and a daughter who turns off my computer in
>the middle of CCC postings).
I can type on my keyboard in the dark (even in full-screen dos mode :-), so
writing in the dark should be a cinch. ;-)
>>
>>Dave
>
>KarinsDad :)
>
>PS. The bizarre position you mentioned would fit into 18 bytes (and down to 15
>bytes if all of the castling possibilities were still there).
Happy bit-flipping! :)
Dave
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.