My first impression of Bill’s double RR idea is positive, I need to check some of the other modules to see if that would break anything.
Does anyone actually hold triple or quadruple RRs?
Match results are another thing that could stand some refinement or redefinition.
I think the current format reports them by giving the total score.
I think reporting it as N rounds with round-by-round results is
less confusing.
Another issue is trying to figure out when something is a match, as opposed to just a section with 2 players in it. This comes into play when trying to enforce match rules.
Some TDs have been submitting what appears to be matches as two player multi-round swisses. I don’t know if that’s to get around the restrictions on match players or if that’s just the easiest way to do them in one or the other of the pairing programs.
I say, throw 'em both in. Lots of times there are several players with the same name, but only one from any given state.
Rating helps too. The ICA membership list once included three Tony Brown’s, but nobody was sure whether this was really two people or three.
Even if the USCF software doesn’t use these fields directly, I would think it could help USCF staff considerably, in their efforts to track down ambiguities by hand.
And more likely to discouraging cheating, if the person submitting the match has to give details. Individual results are more interesting historically, as well.
I notice your proposed format has a field S_TRN_TYPE which is M for matches and S for tournaments. This should help.
Again, your new format should help out here. A TD who wishes to be dishonest, submitting a match as though it were a tournament, would have to be a little more blatant about it (for example, sneaking an S instead of an M into that field before his conscience caught up with him).
Maybe you could flag tournaments which “look” like matches for manual intervention. Some criteria could be: Were there other sections in this tournament? Did this event have a Chess Life TLA? Does this match (if that’s what it is) meet the requirements for a match? Etc.
That’s slightly disturbing. I would think that, since each record contains a pairing number anyway, it wouldn’t matter if there were omissions. For that matter, the order shouldn’t matter, either.
Conversely, if each player’s pairing number were determined simply by his position in the file, then the pairing number field shouldn’t be necessary at all.
It renumbers them anyway, doesn’t it, when it returns the crosstable to the organizer in order of final rank?
Currently it uses a comparison of the relative record number with the pairing number as a check that the data is complete. Gaps in the pairing numbers are not permitted, even if it’s because of no-shows. If the pairing program wants to re-number everyone before preparing the file, great. Once I have the data I have to assume that EVERY pairing number could contain a ratable game, either in the originally uploaded data or after editing.
Checks for missing or improperly formatted data are likely to be very important when we start accepting tab-delimited data, because those are likely to come from sources other than the major pairing programs, and that usually means they’re more likely to be flawed implementations of the standard.
I actually have mixed emotions about renumbering the post-rating crosstable, I know that’s one area where the old ratings program had shortcomings that led to corrupted data. And with re-rating, I could have to re-number the section several times.
I just thought of another field that could profitably be added to the tournament detail file.
Color.
As with some others, this doesn’t affect the ratings, but may be of interest historically.
Maybe the best way to include color would be to make the D_RNDnn fields 6 characters each instead of 5. The color could be optional – if it is omitted, the final crosstable could look the way it does today. If the color is included, the final crosstable could look something like this:
12345678 Nolan, Mike 1550 NE W15b L6w D10w W13b 2.5
Or this:
12345678 Nolan, Mike 1550 NE W15 L6 D10 W13 bwwb 2.5
For that matter, I’d like to see Swis-Sys and WinTD add this feature to their one-line crosstables, too. Presently only the multi-line (wallchart) crosstable shows the colors.
For double (or more) round-robins, which we were talking about before, only the color of the first game need be listed, since colors presumably alternate after that.
Why? If you want a list of results, with colors, in standings order, play with the sort parameters in the wallchart view. The standings view provides a nice, simple list of who played who, which is sometimes all you want to know. Too much information on a page can be as bad as too little.
True, but adding a single “color history” column just before the score column would not clutter things up at all. For a 5-round tournament, a player’s entry in this column might, for example, be “wbwwb”. If there was a bye in round 3, it might look like “wb-wb” or “wbxwb”.
I would prefer not to have to use the paper- and space-consuming multi-line wallchart format in order to see the colors.
Then reduce the font size. If the programmers want to add what you’re suggesting as an option with a toggle, like the ID and State fields, fine, but (in SwissSys a least; I rarely use WinTD) I like the view options the way they are.
On the multi-line wallchart format, I assume you mean. That’s not a great solution, because the font size would have to be reduced to 1/2 or 1/3 of its present size in order to fit on the same number of pages as the single-line format. And that would make it extremely difficult to read.
In SwissSys (though not, as I recall, in WinTD), you can set the point size for each field independently. I spent some time on this, since I want the name, rating, result and opponent number on my wallcharts in different point sizes, but it’s true most people just scale the whole thing up or down.
Why continue to support a K value of quick? Full and half should be the options as I don’t believe that the quick has any meaning other than system and K of quick was used to identify quick rated games.
I can’t remember except that it was discussed, but did the delegates or the ratings committee do away with half K ratings?
As you are now adding suffixes from the name field in the supplement files, is the name length sufficient? I would like to see the name field in the supplement extended also. Check some of the Indian names and you run out of room for the surname before the first name can appear.
Are you satisfied with the tournament name length? What considerations led to the draft value?
Why make the programmers change what they’re already doing? What other value would you prefer be substituted. (Blank is a value, after all.)
No change has been made in half-K that I’m aware of. The Ratings Committee had voted to change the bonus value from 10 to 16 (making bonuses smaller) effective 1/1/2003, but that change didn’t get made by the USCF office, and the committee has since decided that the value should remain at 10.
The name field in the rating supplement files has fewer characters in it than in the USCF’s records (or in the new rating report format), resulting in truncations of the first name in 5-10% of the cases as I recall.
However, increasing the field size in the supplement files gets a bit expensive (download bandwidth), especially when looking at a Gold Master file with 600K records in it.
Also, at least one of the major pairing programs will not accept a larger size name field in the supplement file, it would consider that an invalid file.
Another problem with the bi-monthly supplements is that they only include those players whose rating changed, not necessarily all new or renewing members. That means if you update your computer from a supplement it doesn’t really have all current members in it.
The solution will probably be a new format for supplement files that combines what’s in the bi-monthly file with what’s in the Gold Master file, so that we can issue updates that include unrated players and rated players whose rating has not changed but whose membership status has changed. The old format will still be available for those on older software or those for whom downloading a much larger file is a problem.
I don’t believe I changed that value from the current dBase format.
The purpose of the event and section name fields should be to give sufficient information to identify the event, not to give absolutely every detail about it, relevant or not.
In case it hasn’t been clear from the posts here, the draft standard has already been updated several times, with the most recent changes having been made on January 24th.
I’d like to propose that the present system of three separate files be changed to having one file per tournament. This makes a lot of housekeeping simpler, and cuts down on errors.
The most obvious way to accomplish this is to concatenate the proposed three DBF files into one file. A header with offsets of the three parts could be added, if necessary.
Such a file would be no harder to produce, and would require minimal programming at the receiving end to separate.
It is likely the dBase standard (which is available online) allows for different record types in the same file, and this would be an alternate solution.
As I understand the dBase format, it does NOT support multiple record types within a single file.
It would be possible to do this using a different file type, such as a tab-delimited file, with the first field indicating which record type it is.
Several people have suggested using XML, but I’m not sure that the extra work to define, create and parse XML really provides any additional functionality.
Using a dBase file was a reasonable choice on the old ratings system, which was written in Clipper and thus used dBase files.
The new ratings system is part of our PostgreSQL database. While it is possible to import dBase files into PostgreSQL, what we actually do when you click on the ‘upload’ button is transfer the dBase files to our ISP where we read them using the dBase module in PHP and convert them into SQL statements to do inserts into the internal database.
Thus, we’re not really tied to dBase anymore, except that it’s the format that the pairing programs currently write, so it is the one we HAVE to support now and the logical one to do first.
Since it will take YEARS for all the TDs to upgrade to a newer pairing program once it supports some other format, we’re kind of stuck with supporting dBase for the forseeable future anyway, though we could support another format just as readily once it’s defined. It’s just a case of writing the code to parse the other file structure and turn it into SQL statements.
(Of course, that work isn’t likely to be done until there’s actually some pairing program or TD preparing tab-delimited files for uploading.)
A simpler solution would be to write an applet to zip the the three files at output, and assign the zipfile a (long) file name unique to the tournament. At the time the current system was designed (on a DOS-based 386), everything was limited to the old 8+3 standard.
PostgreSQL supports csv files for direct loads into the database. I haven’t done this personally but the documentation says so (I have done it with Oracle so I would suppose the process is similar). Anyway, the tab-delimited files could easily be converted to csv by replacing the with <“,”> and adding a leading and trailing ". You could eliminate the conversion to SQL statements.
Also, I think it would be a little cleaner if there were one file for each section in the tournament. So, a tournament having an Open, U1800, U1500 and Unrated sections would submit four distinct files. The sections would get tied to a tournament by the tournament ID.