Does not accept transpositions - this is not required for the explore mode, but should work in the play mode IMO. i.e. after a 3x3 invasion of the 4x4 point, black’s answer is equally valid on either side.
Yeah. I think Josekipedia gets out of this by saying “don’t do that”.
But I agree with you it would be better to recognise them, and there are other reasons for recognising same board positions too. Don’t hold your breath though!
Mmh Kogo’s Joseki Dictionary has about 89000 individual moves. I don’t know how you’re storing variations currently, but if you saved all ‘individual’ positions, just take that into consideration with respect to space/performance of the prospective final product. (How are you doing it?)
(Not sure which of the 2 topics this post/discussion fits in best, move if you like)
Yeah - they are saved individually, in a Neo4j graph database at the moment.
If it’s phenomenally successful and gets that much input, it can always be migrated to some more efficient back end.
That will fit in with anoek’s observation “I’ve never been in a successful project that didn’t have 2-3 rewrites”
Or just throw horsepower at it
Neo4j appears speced out for millions and billions of nodes at the Enterprise level. How well that scales to a community version on “whatever platform OGS has” remains to be seen, but it is not on the face of it doomed from the start.
I haven’t had my second cup of coffee yet, so there’s probably a smarter way of storing things, however back of the napkin calculations say if you take a board state and transpose / rotate it, that’s 361*8 positions, each position being in one of three states (empty, black, white). If you were to make 8 strings representing those rotated / transposed states, then sort them lexographically, then concatenate them in order and use that “giant” string as your node key - that should take care of dealing with isomorphic board states naively pretty easily no? If you just encoded them simple like with the characters 0,1,2 then your key size would be 2888 bytes, if you wanted to encode them with 4 spaces per character that’d be 722 bytes. At 89,000 moves that’s 257M / 64M respectively, pretty much no big deal. I’m quite sure you could get the encoding down even more if you cared (a simple RLE would probably result in a >99% reduction since it’s almost all empty), but we’re dealing with a relatively small data set, might not even be worth it. Even if we say we’re going to build some big database by analyzing pro / lz games, at at 10M moves, the 722 byte encoding would still only be using 7.2G in keys, still hardly worth fretting about. If we’re talking 100M or more, or if we are just feeling like it, RLE.
Small variation on your idea - you generate the 8 transposed states, sort them, and only keep the first. This still ensures that all 8 transposed states will have the same key, without having to increase the key size.
