We’re still fleshing out the details, but it looks like the policy for events with time controls that differ depending on the schedule or round will be something like this:
ALL GAMES IN ALL ROUNDS of a section must be held under time controls acceptable for regular rated events for that section to be rated using the regular rating system.
ALL GAMES IN ALL ROUNDS of an section must held under time controls acceptable for quick rated events for that section to be rated using the quick rating system.
This is the least permissive policy that the USCF could have adopted, and it will mean that TDs who design events that don’t meet the above requirements will have to split them into multiple sections for rating purposes.
This gets just a little bit technical, but here are some details about when I uploaded the crosstable. I asked SwissSys to write the wallchart view to a text file. The output is a little ugly because there aren’t dividers between the columns and rows and many of the columns don’t line up because of variable tab stop locations. When I read the text file in Windows Notepad, I noticed some columns out of synch from SwissSys’ output, so I inserted some tabs to make them line up. While this may be good for humans trying to read the wallchart in Notepad, it occurred to me that if you’re using some sort of parser or a program that views the data in tab-delimited columns, I may have just knocked the columns off kilter. Mike, did I do a bad thing by trying to edit SwissSys’ crosstable text file? Does lining up the columns matter?
The reason for requiring a crosstable with an uploaded event is so that the office can print it out if they need to check something on it. As long as it’ll print reasonably well, that should be sufficient.
If, in the long run, it turns out the office never needs to print out the crosstable, then we’ll stop requiring you upload one. (Events entered using the online form don’t have a crosstable text file.)
That may be un-permissive, but I think it is best. Certainly any attempt to rate G/15 as regular-rated should be disallowed.
The above means that, for an event to be dual-rated, the time control must be in the range G/30 through G/60 for all games in all rounds. That’s good too.
If an event is G/45 in round 1 and G/90 thereafter, and the organizer wants the first round to be dual-rated, all he needs to do is divide it into two events, a 1-round event and an N-1 round event.
What is the latest? I think the USCF was planning on running the last “rate” for the February Supplement this week. Was that done already? Are you still planning on implementing the new system in which tournaments will be rated right away right after this “rate”? Are we starting next week?
The transition is going to be a bit tricky. We want to clear out as many of the events submitted on paper and diskette (especially paper) before switching over so that we don’t have to convert the files or re-enter them.
I think Nancy was running a rate today just to get those events out of the queue, which has been known to lose events if it gets too large. I don’t know if she still plans to run the final rate on Saturday (Jan 8th) or if she wants to wait another day or two.
The USCF office has been short-handed for several weeks, a few more days would give her another couple of days of data entry, but the supplement needs to be to the printer by about the 15th in order for TDs to get it by the 1st of the month.
Events that ended in 2005, including ones submitted online, will be held until after the February ratings list is prepared. (That’s also consistent with past policy on ratings supplements, they usually had have an end-of-the-month cutoff.)
The ratings program itself is just about ready, I’ve been testing it against recently rated events all week, but it’s only one small part of a group of programs. nearly all of which have to work in order to switch over to the new software. (Tthere are about 15,000 lines of code in that group of programs, the ratings algorithm itself probably only accounts for about 500 lines of code.)
Mike,
So, where do we stand with the new ratings system? I see that the
Feb. supplement was closed out last week. When do the 2005 results start to get rated?
Thanks,
Miike
We’re making progress on the input/edit routines for the staff to use.
The overall selection/re-rating design works quite well, and based on my tests the actual rating process itself appears to be a bit faster than I had expected.
The crosstable output programs are ready and will probably be added to the TD/A menu tomorrow.
I still need to convert all of the pending events from the old files to the new database structure.
Some of the other administrative programs (like the one that does overrides for events that almost pass validation and for events that are waiting for checks to arrive) still need to be tested.
So, I’m not quite ready to rate events, but I’m also still waiting on some advice from the Ratings Committee regarding some differences between ehat old programming and the new programming get for provisionally rated players. (We found a difference in how and when roundoffs were being done that resolved a similar problem for players with established ratings, but the provisional formula offers many more opportunities for rounding up or down.)
I think all of the pieces other than the formula itself will be in place by the end of the week.
We’ve been validating events submitted online all along, so there’s a queue of events that are ready to rate, and I started testing some events received on diskette today. (There really isn’t much difference between how the office will process events received on diskette and how TDs do them online, this is mostly a check that the internal programming does the same things as the web site, except in the places where it needs to be different.)
They just finished all of the work on the February Supplement on Monday, so under the schedule the Ratings Department has been on for the past year or two they generally wouldn’t start entering and validating new events until next week anyway, so we’re probably right about on schedule.
At a tournament I ran this weekend, one of the sections was a match between two GMs. I’ve been trying to fixa all the errors to get this submitted, but I don’t see a way to clear the error that says something like “Error: This section appears to be a match, but is coded as a Swiss.” Is there anything that I can do to get it submitted?
There may have been a similar problem with a tournament I ran in December which was (for four sections) a knockout. The other two sections were qualifiers for the knockout. This was, of course, played as a series of matches, but the last two have not been rated. Perhaps the reason that the other two that got rated got rated (apologies, I know this is confusing) was because there were more than two players in the sections. Anyway, there were no errors reported with that tournament, and this was on 24 December, but the other two sections have not been rated.
What do I need to do to get these tournaments rated?
Matches have additional conditions associated with rating them, such as both players having established ratings no more than 400 points apart and limits on the number of points that someone can gain or lose via matches.
Those conditions and limitations are not yet in the new ratings program, so matches cannot be rated yet.
I realize those conditions are not likely to apply to your GM match, but it’s kind of an all-or-nothing situation with regards to rating matches.
BTW, a match is considered to be any section with just two players and 3 or more ratable games, regardless of whether it’s coded as a match or as a swiss. (In fact, in the new system we will probably REQUIRE it be entered as a swiss, so that you have to report round-by-round results rather than just a total score.)
I doubt I’ll get a chance to work on that logic until next week, but I hope to get it working before we finalize the April supplement.
It won’t make any difference if you submit it online or through the mail, the ratings program cannot yet rate matches. That’s why the validate check program currently shows it as having an error, because we cannot have any matches get into the queue of events ready to be rated until the program can handle matches.
If it is only two games, you should be able to treat it as a two player non-scholastic swiss section instead of a match. (3 games would make it a match under USCF rules and thus subject to match limitations.)
During my last tournament, did have 3 members have this error. After the first round, did a validation to check for ‘overrides’ or errors needing to be corrected by the USCF member. Since the online tournament report can have a validation of the first round, it would be best to check for bad ID’s or expired membership that could have been over looked during registeration. The reason for the validation of the first round, its’ so simple to track the member down when the player is at the tournament then after the tournament.
Did have a number of warnings: C, H, P, S, T. Have checked and understand the warnings, and understand the need to ‘override’ the warning for out of state members. When the warning is over code Z (Z - 3 digit zip code) do not understand. What is the reason for the zip code warning. As 2 out of 3 code Z warnings, were the players from the other states. Could you clear up this code Z warning?
The 3 digit zip code check factor was put in to deal with large metro areas, where the state factor may not offer sufficient granularity.
Consider a scholastic event in Chicago, for example, where all of the participants are in zip codes that start with 606. Someone with a zip code that starts with 610 is from NW Illinois, and that could be an incorrect ID.
I need to go back and work on refining those factors at some point. For example, if there is already a ‘state’ factor present, then the 3 digit zip factor is probably irrelevant and shouldn’t add to the score.
In general, I’d rather it identify a few too many potentially bad IDs than not enough.
Now understand the code Z, and do not change it. When filling out the zip code field, could make an error of the zip code site. As its’ 49519 for the tournament site, if making an error could place it as 59519, or any error on the first 3 digits. When doing a validation with the wrong zip code (first 3 digits), all the players should have a code Z error. If all the players have a code Z error, it would show up as an error of the zip code site.
If for some reason place the state of Alaska in the tournament report, and a Alaska zip code in the tournament report. When a validation is done of the players, would the code S error and code Z error happen on all the players because of the incorrect data entry of the tournament report?
Im just thinking how the error is designed. If 19 players are from Michigan and one is from Ohio, is that the reason why the error happens? If 19 players are in the zip code with 495 and one is from 496, is this the reason why the error happens?
If there was a error warning, so if the director place the wrong state or the wrong first three digits of the zip code. That could save the director from posting the Chicago Open in the state of New York. In my case if I made an error of the state, it could be placed in the state of Wyoming. As the city site is the city of Wyoming not the state of Wyoming.