Alexander Wagner wrote: > > Joost 't Hart wrote: > > Hi! > > > Hm, sorry for not having read the contribution of Dhanish > > more carefully, because he certainly touches the spot: > > Scid simply does not recognize that the move exd6 is > > illegal. If it did, it would not have put it into the > > tree. There are actually two different positions: One > > which has the right of taking ep (in case ...d5 would have > > been the last move played) and mine. Scid sees them as one > > and the same. > > I think you want Scid to apply some "chess knowledge" > here. > > What is the tree? Nothing more than another view of the > database. (Ok, that's pretty much.) It takes the _position_ > on the board, not the way it is reached, and then runs a > position search against the database. If you run a position > search from any position you set up, exactly the piece > positions are searched, nothing more, and this does not > include the move history, as you'd need it if you want to > drop the e.p. move you suggest. > > In this regards, the tree search does only the same as the > position search you've in Scid all the time, where you've > surely the same problem. If you set up a position, run > "search" you'll get all games that reach this position and > there are some games that take the pawn e.p. while in the > position you have in mind this is illegal. I'd even guess > that the tree window is just using the usual position > search, and if one considers this broken if it's fixed there > it is also fixed in the tree. > > On the other hand I'm not sure if this is really a bug here.
I guess we can not classify some behavior as 'buggy' until the specification is understood and shared :-). With that in mind I have been trying to capture the/my goal of the tree. Discussing such is not easy in a community (separating the "what and why" from the "how"), let alone reaching a conclusion. Beware, this is no criticism to anyone, rather just an observation. And I am fully aware that each feature has its "price" (in terms of effort and sometimes even performance of other features). The good thing is that we "found" the rationale behind the behavior that I noticed. In that sense it is no longer "awkward". Next step is to decide whether we stay where we are (and document a limitation if this is thought useful) or go ahead into discussions like the paragraphs below... Thanks for coming this far. Cheers! Joost. > > > Dunno if scid stores such info (and e.g. info wrt the > > right of castling) regarding "positions" but if not, this > > should be documented indeed. > > Surely, Scid stores information about the right to castle > and the e.p. etc. IF it stores a game. If you run a > positional search it actutally does not. It also stores this > information if you use "setup start board", that is if you > create a starting FEN. Here you've also to specify > castelings and e.p. possibilities. > > In this regard you're right that there is some sort of > inconsistency. It seems, that a positional search is indeed > only searching for a "restricted" FEN. > > > A next (and different) step would be to list all moves > > leading to some position which is already in the database, > > introduced by games that did not follow a track via > > current position. > > I think, that a first step for this is acutally done with > the mask feature. What you suggest sounds to me very similar > to the inversion of "fill mask with base", and as far as I > got Pascal he's working on that issue. This part is surely > not trivial. > > -- > > Kind regards, / War is Peace. > | Freedom is Slavery. > Alexander Wagner | Ignorance is Strength. > | > | Theory : G. Orwell, "1984" > / In practice: USA, since 2001 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
