Addendum 3  Rating and Crosstable Module

 

The major functions of this module are to rate tournaments on a section basis,  update the membership file's rating fields, game and TD accumulator fields, last 5 events fields, and the Life Achievement accumulator fields. Additionally, it checks and updates the rating floor field. It then appends the records to the crosstable files. Finally it creates the crosstable print file.

 

It is important to remember that we actually have two identical rating systems, Regular and Quick. The ratings are calculated using the same algorithm but are saved in separate fields in the membership records. It is important to note that our new UA membership, sales, and accounting package does not currently support several of the necessary fields for much of the current data. The pairing program may need to keep this data and just update the minimal set of fields available

 

There are several changes to the old system that need to be implemented. First, a new rating algorithm has been established. A copy of new rating algorithm can be found on-line at http://math.bu.edu/people/mg/ratings.html and is also included in appendix A to this addendum. A new Life Achievement Title system has been approved and needs to be added. This is described in Addendum 3, Appendix B. Please note that when the new Life Achievement Title system is implemented, the initial values of each of the registers will need to be set based on the data stored in the old files. A conversion/calculation program will be necessary.

 

The recommendations by the programmers are requested in how to handle storage of the various items of information now kept in accumulator fields. These fields include the items such as total games, last 5 events, and TD information. The current membership and VIP files should be examined for the specific items kept.  These fields are very subject to error primarily due to manual corrections and current program exclusion decisions and are also almost impossible to verify. One example of their purpose is to allow checking the TD experience requirements for upgrading the members tournament director certification level to Senior. This requires that the applicant have served as a Chief Director for at least 6 events of 4 or more rounds with at least 50 players. This information is currently kept in a set of fields and those fields are incremented each time a rate occurs. As later corrections are made on a purely manual method, this data can rapidly become  inaccurate, especially if the person doing corrections forgets to delete or update fields . The alternative method is to accumulator fields is to a query and search the crosstables every time the record is opened. This is a time consuming method. A possible compromise is to maintain the accumulator registers but provide a method of running a query to recalculate and update the fields when specified by the user. This could be allowed on an individual or range basis. The requirements for the various TD levels can be found on-line at www.uschess.org or in the handout in Addendum 3, Appendix C, Tournament Director Certification Standards.

 

 

The following discusses potential problems and decisions needed to actually implement the rating algorithm.

 

 

Duplicate ID #s in a section  -  It is important to understand the following.

 

A player may have more then one entry in a section. One reason is called a re-entry and is normal. The new rating algorithm will not be able to deal with duplicate ID #s in a section.  The following procedure should be used to calculate ratings for any section that has duplicate ID #s in it.

 

1.       Check section to verify no duplicate ID #s. If none are found rate as normal.

2.       If one or more duplicate ID #s are found, combine the results for each duplicate ID into the lowest pairing number and delete the higher number. Renumber the pairing numbers for the deleted # as needed. Rate the event. Recreate the original crosstable and give each duplicate ID number the same pre- and post-event rating.

 

The following is an example of what the input and output  should look like

 

Input from edit file

 

1.    11111111  L6, U,  U,  U

2.    22222222  W3, L4, W5, W6

3.    33333333  L2, B,  W6, L4

4.    11111111  L5, W2, B,  W3

5.    55555555  W4, L6, L2, B

6.    66666666  W1, W5, L3, L2

 

After merging duplicate ID so ratings can be calculated

 

1. 11111111  L6, U,  U,  U, L5, W2, B, W3

2. 22222222  W3, L1, W5, W6

3. 33333333  L2, B,  W6, L1

5. 55555555  W1, L6, L2, B

6. 66666666  W1, W5, L3, L2

 

Output to crosstable file

 

1. 11111111  1493  1498  L6, U,  U,  U

2. 22222222  1678  1599  W3, L4, W5, W6

3. 33333333  1218  1227  L2, B,  W6, L4

4. 11111111  1493  1498  L5, W2, B,  W3

5. 55555555  1500  1501  W4, L6, L2, B

6. 66666666  1345  1354  W1, W5, L3, L2

 

 

 

The crosstable file - This file system is very important as it is our historical record of our events, players results and ratings, and TD activity. The current system creates a separate set of 2 files for each year. This method appears to work well but the programmer is free to recommend and implement the most efficient modern methods to retain this data.

 

The primary uses for these files are the following

 

1.       Print formatted crosstable reports on demand.

2.       Provide our rating committee with the ability to check our rating system and analyze the results by checking results on a game by game basis.

3.       Track the changing rating of a player on a section by section basis. It also permits us to calculate and check the accuracy of the various accumulator registers for a players activity count.

4.       Provide a player with a report of what events he has played in, who he played, and what the result was.

5.       Some of our invitational events require us to base the invitation based on peak rating.

6.       Provides us with the method to verify accumulator registers and report on TD activity.

 

When crosstable print files are created, the output for each section should be sorted first by descending final score and then by descending post-event rating. Samples of crosstable output is located in appendix D to the CFRATSYS description.

 

Conversion of old crosstable files and additional fields being added - The new system will have additional fields to store data that may be optional. The old crosstable files will need to be converted so the new system can read and store the data.

 

Additional fields - The following fields should be added to the new system.

 

Time controls on a section basis - each section in an event may have different time controls. There also may be up to 3 controls specified for each section. They are primary, secondary, and tertiary. The controls will be one of two types, Sudden death or non sudden death. A sudden death control will be specified in the format of G/60 where "G" indicates that the entire or remaining portion of the game must be finished in a specified amount of time. The amount of time is indicated by the number following the "/". In the example above, 60 minutes is the specified amount of time. A non-sudden death control will be indicated by a number of moves preceding the "/ time". For example, if a player is required to complete 40 moves in 90 minutes, the time control would be reported as 40/90. A typical event using two controls would be 40/90, G/60, A three control event might have 50/120, 20/60, G/30. An exception that is becoming rare is the unlimited event that allows a game to continue until a result is reached regardless of how long it may take. A reported control of 50/120, 20/60 with no sudden death control would indicate that there can be as many subsequent controls of 20/60 played as needed to allow the game to finish.

 

The inputting of time control information will be optional and should be displayed on the data entry screen and crosstable reports. This data also allows a crosscheck to insure that a section is rated in the proper system.

 

Player color by game - This information has been requested by the USCF Rating Committee for analysis purposes. The majority of screens and reports will not allow entry or display this data but provision should be made to store color history in the results field. This data will normally be entered only by reports submitted electronically. Entering the color information from reports provided on paper will not normally occur. For this reason, the data entry screens should not normally display or permit hand entry of color information. Provision should be allowed for the operator to specify being able to view and edit or enter this data but the default should always be not to display or edit color information. This information will normally only be provided with reports submitted that have electronic input.

 

Post-event rating (before floor is applied) - The new Life Achievement Title (LATS) system uses the post event rating for calculating and updating the accumulator registers for the new LATS. Credit for each of the rating classes is based on the post-event rating before any floor is applied. It is inevitable that our members will have questions concerning which events were credited. In order for a later report to produce the necessary data, either the pre-floor post-event rating must be stored or the rating for each section must be recalculated when the report is generated. I recommend that an additional field be added to the crosstable file that stores the actual post-event rating before any floor is applied. This data would not be visible in crosstables or most display screens or reports. Only screens and reports for the LATS would display it. For events now existing in the 1991 to 1999 crosstable files, we will not bother to rerate these events to recover the pre floor data. Therefore, the conversion program should set the pre-floor field [PEPF] equal to the post-event field. Once the data is in the new format, a standard check/update program can be used to initialize the LAT accumulator registers.

 

 

Actual rating process

 

The description of the new rating system is quite comprehensive and I will not try to provide more then an overview of the process that occurs as part of the ratings calculation. Please note I am not trying to specify the procedure to be used. This is, as stated ,an overview and the programmer is allowed to use good database practices to accomplish the necessary details and in what order.

 

The rating process occurs on a section basis working from the oldest to the newest event. As each section is rated the following process occurs.

 

The current USCF ratings, # of games, and rating floors from both rating systems are retrieved for each player in the section. If no USCF rating exists, the players FIDE or CFC rating will be retrieved.

Post-event ratings are calculated for every player in the section using the rating algorithm. Note that initial pre-event ratings for FIDE and CFC rated individuals have to be identified and entered into the members record prior to the actual rating process. If a player is USCF unrated but does have both CFC and FIDE ratings, the FIDE rating will be used to initialize their rating in accordance with the rating algorithm.

The LAT registers are incremented for each player based on the information provided in appendix B.

The post-event rating is copied to the PEPF field.

A temporary floor is calculated using the following procedure.

1st, the procedure specified on page 6 under the Rating Floors is used if post-event game count is => 25. The current record process does not keep track of total game count and a total game count field needs to be established. This should be initialized through the search/update accumulator registers in the crosstable files.

2nd, the LAT 2200 register is checked and if => 300, check the "do not set OLM floor" flag. If the flag is true, set the temporary  floor to 2200.

3rd, compare the retrieved floor to the temporary floor and set the temporary floor to the greater value of the two.

The post-event rating is compared to the temporary floor and the higher of the two values is used for the final post-event rating.

Each players current rating is copied to the previous rating, and the post-event value is copied to their current rating. Floors and other necessary data is updated in the membership record.

Any necessary dates and flags are set or cleared and the next section is selected and the procedure repeated.

 

Original Life Master Title – This title now exists and is the basis for the design of the new LATS. Anyone who achieves this title is automatically assigned a 2200 floor.  This will continue under the new LATS and is the only rating range affected by the floor requirement. After the post event rating is calculated, if the OLM game count is => 300, the floor is set to 2200. The current implementation has a flaw. An OLM holder can request that they not receive a floor. Unfortunately, the current system does not allow us to disable the automatic setting of the floor on an individual basis. This means our only method to set a floor below 2200 is to manually reduce the game count. This has the unfortunate effect of removing that member when lists of the OLM are produced. The new system needs a field that can be manually set to exclude assignment of the floor for the players with 300 or more games. The default is to set the flag to Y to allow a 2200 floor.