Chess Databases Software surverying for limits • page 3/3 • General Chess Discussion • lichess.org

chess_pos_db_gui
https://github.com/Sopel97/chess_pos_db_gui

TODO: write post here about that..

other piece if the loose puzzle of finding out the current "offer" on big databases in chess, for single user exploration first. that one is about efficient space and time of the position database front, given a games database (PGN) as input.. It does a human legible format dump (EPD) as intermediate output.. but has many binary formats.. minial Gui. Basic documentation at GUI level. and github repository for the C++ code. 3 years old. 7 GB PGN giving 10GB EPD (with 100 plies games depth cutoff assumed as default). took something like an hour on my temperature controlled laptop (the software does not time itself at GUI level).

TODO: and more experiement on the binary side.. (need to figure out what "smeared" addd to already documented binary formats, and the type of errors that minimal variant binary encoding might mean.. not urgent).

Thread relationship
That is another "data point" is my coarse view of the current state of such single user possible software.. Motto, is do not reinvent wheels for which you can find it in yourself to build transmissions around.... I would like to have before i dive, some sense of the sparsity and connectivity (even even not yet implemented) between many chess toolds dealing with databases).

I have the PGN, EPD, OCGDB/SQL, and now scid for compact games,, and this for compact positions.. the SQL for the still human reasdable content being put in relational DB, i could have my big position AND games non-black box version of part of the lichess opening explorer. end the naming could be made without transposition compromise on opening names, or multiple origin opening discoveries (and other opening name or addressing collisions).

hence the limit in my title.. this includes limits of the buildings blocks with respect to each others and the data analysis (and chess discovery for me) goals. I like a coarse to fine spiralling inward approach it seems. in the end might be less work on the repetitive and neck-pain front.

chess_pos_db_gui https://github.com/Sopel97/chess_pos_db_gui TODO: write post here about that.. other piece if the loose puzzle of finding out the current "offer" on big databases in chess, for single user exploration first. that one is about efficient space and time of the position database front, given a games database (PGN) as input.. It does a human legible format dump (EPD) as intermediate output.. but has many binary formats.. minial Gui. Basic documentation at GUI level. and github repository for the C++ code. 3 years old. 7 GB PGN giving 10GB EPD (with 100 plies games depth cutoff assumed as default). took something like an hour on my temperature controlled laptop (the software does not time itself at GUI level). TODO: and more experiement on the binary side.. (need to figure out what "smeared" addd to already documented binary formats, and the type of errors that minimal variant binary encoding might mean.. not urgent). Thread relationship That is another "data point" is my coarse view of the current state of such single user possible software.. Motto, is do not reinvent wheels for which you can find it in yourself to build transmissions around.... I would like to have before i dive, some sense of the sparsity and connectivity (even even not yet implemented) between many chess toolds dealing with databases). I have the PGN, EPD, OCGDB/SQL, and now scid for compact games,, and this for compact positions.. the SQL for the still human reasdable content being put in relational DB, i could have my big position AND games non-black box version of part of the lichess opening explorer. end the naming could be made without transposition compromise on opening names, or multiple origin opening discoveries (and other opening name or addressing collisions). hence the limit in my title.. this includes limits of the buildings blocks with respect to each others and the data analysis (and chess discovery for me) goals. I like a coarse to fine spiralling inward approach it seems. in the end might be less work on the repetitive and neck-pain front.