TalkChess.com

https://github.com/michiguel/Ordoprep/releases/tag/v0.8

It includes the new features added to Ordo lately (see the link for a list of switches). With this, PGN files can be combined, aliases can be used (synonyms), and subset of games from specific engines could be selected. This pre-selection of games is not only useful to use Ordo later, but also to use other rating programs.

Miguel
EDIT: main page
https://github.com/michiguel/Ordoprep

michiguel wrote:https://github.com/michiguel/Ordoprep/releases/tag/v0.8

It includes the new features added to Ordo lately (see the link for a list of switches). With this, PGN files can be combined, aliases can be used (synonyms), and subset of games from specific engines could be selected. This pre-selection of games is not only useful to use Ordo later, but also to use other rating programs.

Miguel
EDIT: main page
https://github.com/michiguel/Ordoprep

I got carried away and have another release (v0.9), adding long options in the command line (-h is the same as --help, for instance or -Y the same as --aliases). Sometimes long options make things more readable in scripts.

ordoprep -p a.pgn -o b.pgn

is the same as

ordoprep --pgn a.pgn --output b.pgn

https://github.com/michiguel/Ordoprep/releases

I guess that ordoprep is reasonably complete. If no bugs, typos, etc. are detected, after a little while I will bump this version to v1.0

Miguel

The Ordoprep source don't compile cleanly. The plyrs.c and associated files were not included in the Makefile. I wonder how you produced the executables by omitting these files.

drj4759 wrote:The Ordoprep source don't compile cleanly. The plyrs.c and associated files were not included in the Makefile. I wonder how you produced the executables by omitting these files.

I missed plyrs.c by mistake, but it is only needed for the debug version (which I compiled it differently). That is why I could compile it cleanly. Anyway, I fixed the Makefile. There are few other clean ups in the code too.

https://github.com/michiguel/Ordoprep/releases

Let me know how it compiles now.

Miguel

I really should get used to using Ordo and Ordoprep.
Thank you for your continuous efforts.

The latest Ordoprep 0.9.3 compiles fine now.

By gut feel, it is lightning fast compared to my custom Python script to extract a subset of games from a big file containing millions of PGN games.

However it chokes when it can't match from the include file and produce an error message 'Errors in file "<subsetFile>" (not matching games)'. Finding the culprit is like looking a needle in a haystack in an include file with 500 entries. It is better to list all the offending files and let the processing continue, disregarding the errors. I have already my own include files with different subsets which is in the same format with Ordoprep and these contained many file entries which are orphaned due to the always changing chess engines list. It may also have typographical errors but I don't let it stop the processing especially when pressed for "deadline" to publish. Such errors could be spotted later and corrected in the next iteration.

The -i and -x options produced only one output which is specified in the -o option. It would be better to output the excluded files in the -i option and included files in the -x option. These residue files will serve as audit to determine whether the two included and excluded files will equal with the original file when concatenated together. Also, the residue files could be used to produce a separate rating list for their group. It can also be the basis to extract some more subsets which will be faster than getting it from the big original file.

I have not used the latest features of Ordo and Ordoprep but will take a look at them when I will produce my next Combined Rating Lists.

Good work. Just do it!

drj4759 wrote:The latest Ordoprep 0.9.3 compiles fine now.

By gut feel, it is lightning fast compared to my custom Python script to extract a subset of games from a big file containing millions of PGN games.

However it chokes when it can't match from the include file and produce an error message 'Errors in file "<subsetFile>" (not matching games)'. Finding the culprit is like looking a needle in a haystack in an include file with 500 entries. It is better to list all the offending files and let the processing continue, disregarding the errors. I have already my own include files with different subsets which is in the same format with Ordoprep and these contained many file entries which are orphaned due to the always changing chess engines list. It may also have typographical errors but I don't let it stop the processing especially when pressed for "deadline" to publish. Such errors could be spotted later and corrected in the next iteration.

The -i and -x options produced only one output which is specified in the -o option. It would be better to output the excluded files in the -i option and included files in the -x option. These residue files will serve as audit to determine whether the two included and excluded files will equal with the original file when concatenated together. Also, the residue files could be used to produce a separate rating list for their group. It can also be the basis to extract some more subsets which will be faster than getting it from the big original file.

I have not used the latest features of Ordo and Ordoprep but will take a look at them when I will produce my next Combined Rating Lists.

Good work. Just do it!

Good points.

Miguel

drj4759 wrote:The latest Ordoprep 0.9.3 compiles fine now.

By gut feel, it is lightning fast compared to my custom Python script to extract a subset of games from a big file containing millions of PGN games.

However it chokes when it can't match from the include file and produce an error message 'Errors in file "<subsetFile>" (not matching games)'. Finding the culprit is like looking a needle in a haystack in an include file with 500 entries. It is better to list all the offending files and let the processing continue, disregarding the errors. I have already my own include files with different subsets which is in the same format with Ordoprep and these contained many file entries which are orphaned due to the always changing chess engines list. It may also have typographical errors but I don't let it stop the processing especially when pressed for "deadline" to publish. Such errors could be spotted later and corrected in the next iteration.

The -i and -x options produced only one output which is specified in the -o option. It would be better to output the excluded files in the -i option and included files in the -x option. These residue files will serve as audit to determine whether the two included and excluded files will equal with the original file when concatenated together. Also, the residue files could be used to produce a separate rating list for their group. It can also be the basis to extract some more subsets which will be faster than getting it from the big original file.

I have not used the latest features of Ordo and Ordoprep but will take a look at them when I will produce my next Combined Rating Lists.

Good work. Just do it!

Implemented
https://github.com/michiguel/Ordoprep/releases

Now, it issues a warning and continues.

New switches
--no-warnings
--remaining <file>

Miguel

Very good! My concerns are addressed. Ordoprep is really fast and errors in the include/exclude files are emitted for quick fix. Surely, the patch would also apply in Ordo.

This is for Ordo:
1. When using the -b option to format the output, the headers in the right side of the CFS(next) caption when the header length is reduced becomes misaligned. One ugly solution is to put the CFS caption at the farthest column so that the header alignment will not be disturbed. This is not what users will agree with. The better solution will be to not have special treatment with the CFS(next) header in the algorithm which have a special function to format it - only the CFS(next) caption is centered aligned but the rest are right justified. Make it shorter (say CFS) and let it be part of the group in the IF/ELSE statement.

2. If the -N option is used with 2 or greater decimals, all the fields data are shifted right starting at the RATING header. This is very ugly and will discourage users to use the -N option. I use 2 decimals in my Rating Lists, so my adhoc solution is simply change the code directly to align the header and fields, then recompile. You have a better solution for the good of all the prospective users.

God bless and more power!

drj

drj4759 wrote:Very good! My concerns are addressed. Ordoprep is really fast and errors in the include/exclude files are emitted for quick fix. Surely, the patch would also apply in Ordo.

This is for Ordo:
1. When using the -b option to format the output, the headers in the right side of the CFS(next) caption when the header length is reduced becomes misaligned. One ugly solution is to put the CFS caption at the farthest column so that the header alignment will not be disturbed. This is not what users will agree with. The better solution will be to not have special treatment with the CFS(next) header in the algorithm which have a special function to format it - only the CFS(next) caption is centered aligned but the rest are right justified. Make it shorter (say CFS) and let it be part of the group in the IF/ELSE statement.

2. If the -N option is used with 2 or greater decimals, all the fields data are shifted right starting at the RATING header. This is very ugly and will discourage users to use the -N option. I use 2 decimals in my Rating Lists, so my adhoc solution is simply change the code directly to align the header and fields, then recompile. You have a better solution for the good of all the prospective users.

God bless and more power!

drj

I think this version will address all that
https://github.com/michiguel/Ordo/releases/tag/1.1.6

Columns adjust automatically if the width is too narrow.

Miguel