Several fields have been added since the last draft version was posted in early May, mostly to accomodate events that are also FIDE rated events.
I hope to have some discussion of this draft version at the workshops at the US Open. If there are no sigificant issues raised regarding this draft of the format, I will finalize it by the end of August so that the developers of the pairing programs can begin to implement it and so that I can make the changes to the TD/Affiliate Support Area to start accepting reports using this format. (The current format will continue to be acceptable.)
While this is shown as a dBase file format, primarily because the current reporting format is in dBase format, the initial implementation is likely to be in some other file format.
I lean towards tab delimited, because it is easier to parse than CSV or XML.
H_COUNTRY – Doesn’t FIDE use the Olympic 3-letter codes? I seem to recall that there isn’t (quite) a one-to-one mapping between those and the 2-letter codes.
H_OTHER_TD – Since this is the last field, it could be a repeating field like S_F_RNDnn, rather than have them all in one. Not that it should really matter.
S_TIMECTL – How about adding the delay or increment? Example: “Game/90+30” for a single time control starting with 90 minutes, with a 30 second increment. Example: “30/90d10,Game/60d10” for someone using a 10 second delay in a game with 2 time controls, etc. The PGNish way, but converting starting time to minutes rather than seconds, would be “90+30” and “30/90d10,60d10” for these two examples (in other words, the “Game/” is not really needed, the lack of a “/” indicates it’s a SD time control).
3 character ISO country codes is a good idea and saves some space, too.
I’m less sure about having separate fields for each assistant TD, unless there’s another field somewhere to indicate the total for control purposes, as there is for the number of rounds and the round dates.
There is certainly space in a 40 character field to describe the increment/delay portion of the time control.
I could also see having a standard coding for time controls, but there is so much variability out there would anyone understand how to code them?
Moreover, what do you do about events where the time control in some rounds are different from those used in other rounds? (This is especially important for FIDE rated events, as it can affect whether some rounds are FIDE ratable or not, or whether norms can be earned.)
Currently our recommendation for USCF rated events is to use the slowest time control from any round, providing that you don’t mix time controls that are quick-ratable only (ie game/29 or faster) with ones that are dual or regular ratable.
The ratings committee’s rule of thumb on this is that games that are G/29 or faster can NEVER be regular rated, and games that are slower than G/60 or not primary sudden death can NEVER be quick (or dual) rated. However, if there are games that are dual ratable mixed in with games that are regular ratable only, then treat all of those games as regular ratable only.
What’s the most complex set of time controls you’ve seen for a single section? I admit my experience is limited.
For different time controls in different rounds, you need some way to encode the round numbers each applies to. The only tournaments I’ve ever seen that do this are swiss events where the first round is at a faster time control, then all subsequent rounds are at the “normal” time control. For a 5 round swiss with the first round at Game/60, and the rest at 30/90, then Game/60, both with a 5 second delay for each period, it would be something like
(1)60d5:(2-5)30/90d5,60d5
That’s still readable by humans who know the format, but reasonably compact. In a 40 character field, it looks like there would be room for 2-4 time controls. I would think that would cover the vast majority of cases. Perhaps a flag character could be used for rounds that couldn’t be adequately represented for some reason.
The World Open had a 7-day schedule, a 5-day schedule, and 3-day schedule. The 7-day was 40/2, SD/1. 5-day: rds 1-2 G/75. 3-day: rds 1-5 G/45. Admittedly this is an extreme case.
I don’t quite see the point of including the time delay. Since not everyone uses a delay clock, it doesn’t really give you any useful information about the games.
I don’t quite see the point of including the time delay. Since not
everyone uses a delay clock, it doesn’t really give you any useful
information about the games.
For 5 seconds, it presumably doesn’t really matter. Since a 5 second delay is the USCF “standard”, it could even be omitted to save some space, perhaps putting a “d0” for rounds that explicitly don’t have a delay.
It’s more important for increments: “90+30” seems reasonably different to me from, say, “110”, which is the 40-move equivalent time. Even in my little neck of the woods I’ve seen some of these pop up.
Since it’s a database format, why not include the info?
The World Open apparently had 3 time controls, but different games in the same round could have different time controls. Are these reported in a single section? If so, that would seem to put a damper on this whole thing, unless Mike thinks it’s worth the space to include a single-char identifier for the time control in each game result (which points to one of the time controls in the time control string).
All the schedules eventually merge and are reported as single sections. The TD has to keep track of which games in the top section were played at a time control not eligible for FIDE rating, however.
I agree that tournaments using the more extreme delay/increment settings probably provide clocks. However, most tournaments do not. Flagging an event as “d/5” doesn’t tell you how many games were really played with a 5-second delay. (Typically 40-60%, but who knows?)
Including time delay information in the time control field may have some value for FIDE rated events, John, because that could affect the ratability or possibility of norms from the event.
However, in multiple schedule events I don’t know that reporting the time control used for a given round under each schedule helps much, because in order to use that information (for determining which games were FIDE ratable, for example) we would also need a way to identify which games were part of which schedule.
(I got the impression at the FIDE Technical Commission meeting that they are thinking about expanding their reporting format to cover situations in which some games or rounds are at different time controls than others, though for the most part multiple schedules are an Americanism which they detest in Europe. They detest our practice of permitting half point byes on request, too.)
Some time back someone contacted me about the possibility of holding an event where round 1 was game/15, round 2 was game/30, round 3 was game/45, round 4 was game 60 and round 5 was game/75.
Is it the schedule or the time control they need to know? Both?
The potential solution I alluded to would start by listing all time controls used, along with a tag, in the S_TIMECTL field:
(a)60 (b)75 (c)40/120d10,60d10
would show three time controls: game/60, game/75, and 40 moves in 120 minutes, then game in 60 (with a constant 10 second delay), with a,b,c tags respectively.
Then in the tournament detail file, the D_RNDnn fields would contain this info, as in
D1002Wc
This would seem to necessitate expanding the D_RNDnn fields to 8 characters, unless the “*” would no longer be necessary with the expanded time control info (but I assume there are other reasons a game might not be FIDE rateable).
They want to know the dates on which all the rounds were played, so that they can check to see if any players claim to be playing in more than one event on the same date. (Apparently this is becoming a bit of a problem for FIDE.)
They want to know the time controls in effect, both to make sure the event is FIDE ratable and in case there are norms involved. (Some events are FIDE ratable but norms cannot be earmed from them.)
If some rounds or games are not FIDE ratable but others are, there needs to be a way to notate and exclude the nonratable rounds or games.
I’m not sure exactly why they want to know color, I never got an answer to that which made any sense to me.
Even if color is never used (at any future time) to help calculate ratings or norm eligibility, it is still historically valuable and interesting information. “Oh look, X beat Y with the black pieces, then lost to Z with white.” “Oh, NOW I see why the computer did pairings the way it did – it made the colors work better.”
At the very least, it should liven up some of those “Wouldn’t this pairing have been better than that one” threads that appear periodically on these forums – threads that are WAY more interesting than all the political stuff.
Similar reasons – history and interest – may also dictate including increment and/or delay in the time control descriptions.
