gcramer wrote:At first a note about the polyglot chess book. The standard is defined for 8x8 chess with normal pieces, and this standard shouldn't be affected by any extension. This means that bigger board sizes, and/or fairy pieces, requires a separate (this means: non-affecting) hash key computation. (In my opinion a 128 bit hash key is needed when bigger board sizes will be handled.) Scidb's hash key computation for chess variants is not affecting at all the computation for standard chess.
Neither is the current XBoard implementation affecting it...
Furthermore a standard shouldn't be influenced by any technical issue, nobody will accept such a standard.
Not sure what you are trying to say here. Is it that when a standard is perfect, except for the mere technical issue that it cannot be implemented due to unrealistic demands on available hardware, everyone would prefer to (not) use that standard, rather than adopt one that is realistic?
This is a technical issue, and must be solved in a technical way.
Well, adding a variant key to the position hash seems a nice technical solution to me...
The start key is unnecessary, hence complicated. (I'm speaking about Crazyhouse, Antichess, and so on, on 8x8 boards, I'm not speaking about other board sizes or fairy chess.) Technical issues cannot influence a standard.
Even the variants you mention would not be able to use each others books, as the same positions will totally differ in what the acceptable moves from that position are. For multi-variant books the variant key is necessary, and especially so for positions that only contain orthodox pieces on 8x8, as these are the positions that can be confused otherwise. (For Xiangqi, for instance, there never is any collision, as it uses another piece type for the always-present King.)
In my philosophy standards are there for no other reason than to solve technical problems, but ensuring that everybody uses the same way where there when arbitrary choices have to be made. Meaning that it better do a good job at solving them to be accepted by a meaningful number of people. I would never accept a standard that prevents me to do things that would technically be possible by violating that standard.
Specifying the variant in a header is part of the standard just as much as specifying the start key, so you seem to have no point. In any case, I want a standard that allows multi-variant books for XBoard, because I want to make such books. This is non-negociable. If you want to define your own, inferior standard for scidb, that is up to you. I won't ever use such a standard in XBoard, that is for sure. So discussing this serves no purpose.
The zobrist key computation is using xoring, because xoring has unpredictable results, this is the principle of chaos. The additive operation in a non-prime seeded modulo ring (2 isn't prime) results in general in relatively short cycles, this is not chaos. Using the additive operation seems to be mathematically improper.
You think 2 isn't prime? I guess then we are also done discussing math...
Ok, but nevertheless this not the (usual) way how the key will be computed.
Well, it is for me... But it seems pretty irrelevant what is usual, and what not. I only care about quality. Even if the whole world does something in an inferior way, it wouldn't be a reason for me to slavishly copy their mistakes. 'Usual' carries zero weight with me.
If this is the case, then of course it's better to use predefined keys. But my test with 1.291.522 Crazyhouse games, generating 57.490.796 different positions, hasn't detected any collision with Scidb's method.
Well, with so few positions even a lousy 64-bit key wouldn't give any collisions, of course. 57M ~ 2^26, so you have 2^51 pairs. With an optimal 64-bit key the chance for a collission is thus only 1/2^13. The collision rate could be a thousand times higher than for a good key, and you still would not see it.
Anyway, I only said the shifting method was suspect, based on actual measurements of collision rates (rather than just observing that there were no collissions under conditions where you would not expect any no matter what). In fact the addition and the rotation methods for holdings keys are barely different, as multiplying a key by 2 or 4 is equivalent to shifting 1 or two bits (which again is the same as rotating when the most-significant bits happened to be zero). So only the case of 3 identical pieces in hand would be different. (And for Pawns when you have 5-7 in hand. Ever seen that in a real game?)
It seems to me you are seeing ghosts here, and that the only justification for doing it different as XBoard does is just to be incompatible.
Crazyhouse/Bughouse
The computation for normal chess pieces shouldn't be influenced by fairy chess computations, I think the latter will be done with a specialized computation for fairy chess.
Well, Crazyhouse is fairy Chess, and in fact so is the FIDE game. The only difference is that they are played by a different group of fairies.
Another issue with Crazyhouse/Bughouse, which is overseen in XBoard, and what I have forgotten in Scidb's first implementation. It is unavoidable to hash promoted pieces. If a promoted piece will be captured, for example a promoted Queen, not the Queen but a Pawn will be added to the holding. So capturing a promoted Queen is not the same as capturing a regular Queen. This must be regarded, because subsequent moves may depend on this fact.
Well, XBoard fully takes account of that, right? Because the promoted Pawns are other piece types (displayed as modified pictograms) than the usual Chess piecs. So a Pawn promoted to Queen would use a different Zobrist key from the from a true Queen on the same square. Namely the key for the corresponding fairy piece.
The encoding of the number of checks is a must, a position cannot be equal if the number of checks is not equal in this variant. It's like the castle rights, a position cannot be equal if the castle rights are not equal, but in case of Three-check Chess the thing with the number of checks is even more necessary than the thing with the castle rights.
Yes, I understand all that. It just means that ThreeChecks isn't a 'fully supported' variant in XBoard, but only has 'partial support', and that one must rely on engine or ICS. In this case that would interfere not only with legality checking, but also with the use of a GUI book. (At least, in so far the book must contain positions where one of the sides has been checked, which seems about as useful to me as putting positions in an opening book where one side is a full minor ahead.) Note that before I started working on XBoard, it did not even keep track of castling rights in normal Chess. I just didn't consider ThreeChecks of sufficient importance to spend any time on its support at all.
+1+0 means; White has given one check to Black, Black has not given any check. Now consider the FEN
Code: Select all
r1bq1b1r/pppp1kpp/2n2n2/4p3/4P3/2N5/PPPP1PPP/R1BQK1NR w KQ - 0 5 +0+0
I don't like this FEN notation much; I greatly prefer the half-move and full-move counters should be the last two fields in the FEN. (Because often you are not interested in them, and then they can be easily omitted or ignored.) Where does it say that FENs for ThreeChecks should be encoded this way?
It also seems a bad idea to count the number of checks given rather than the number of checks left. It would mean that in the variant FourChecks the game-theoretically equivalent position in ThreeChecks would be encoded by a different FEN (and hence, that the meaning of a FEN cannot be deduced without knowing whether it is for ThreeChecks or for FourChecks. Counting the number of checks left would not have that problem. I also don't like the use of two + signs. One of those is redundant. A field 2+2 in the FEN would already unambiguously specify both sides can still survive two checks (and would thus lose on the third). The idea of FENs is that they should be compact. The format you use here seems ill-thought, and would not qualify for use in XBoard.
I agree, a variant-independent way is too problematic. The value 5 for the king is the canonical value in Antichess.
Canonical? Do you have a reference for that? Or does 'canonical' here merely mean 'the value that you like best'? (Sorry that I am such a skeptic, but this discussion so far makes me fear for the worst...)
It is not too late to redefine the book format XBoard uses for shady variants like ThreeChecks or Suicide; I don't believe there already exist any XBoard books for it. And the move field (unlike the hash key) can be easily adapted in existing books anyway. But I
certainly would not consider any change in the wrong direction, which would decrease the capabilities compared to the current format (such as making multi-variant books) in any way. In fact I would not even consider change just for the sake of change, without there being a
compelling reason. And '5 is the canonical value' or 'this is the usual way' do not sound very compelling to me. There must be a clearly identifiable thing that can be done after the change, and could not be done before it.
