Addendum 4 Event Correction module

It is an unfortunate fact of life that errors in data occur. In rating reports there are several different errors that can occur that require corrections to the crosstable files as well as to the members rating data. The typical errors that occur and the necessary actions are listed below. It is very important that this process be automated. Our current method is almost entirely manual, very labor intensive and therefore expensive.

Correcting a given crosstable is relatively simple. The difficulty comes in updating the members records, especially the accumulator type fields and then dealing with the ripple effect. Note that the re-rating of events to calculate ratings in chronological order can easily be considered as an error correction also. It is also interesting to note that a problem is self correcting and the discrepancy becomes less and less as the player plays more games, especially for established middle age players whose actual ability is stable. If there was an error in an event and their rating is made lower then it should be, in their next several events they will gain more or lose fewer rating points then if the rating had been correct.

The difficulty in keeping accumulator fields accurate are self-evident and the programmer should be able to deal with this problem without further discussion. The ripple effect is the very difficult problem that needs attention. Assume that player 11111111 has played in the following events:

10/1, 10/18, 11/5

After the 11/5 event was rated, we find out that there was an error in the 10/1 event. After you correct the 10/1 event, you now have a discontinuity between the 10/1 post-event rating for the player and the 10/18 pre-event rating. After you fix the 10/18 event, you may find a discrepancy in the 10/18 to 11/5 event. There are also other players in the first event whose post-event rating will change due to the change for player 1111111. Their membership records and follow-up events in the crosstable files must also be identified and corrected.

As you can see, this single correction may result in a changing a large number of records and crosstables.

Typical problems that require correction are:

A score or opponent was incorrectly reported or entered. This will effect at least 2 players and probably more. This is probably the easiest as often the rating change is small and effects fewer players and subsequent events.

The wrong ID number was used. This means that one player has to be removed and another player needs to be added and both require correction. This frequently affects many players especially if there was a large difference in the rating for incorrect and correct player. A subset of this problem is that the actual player may have been correctly identified but they had two ID numbers. This is also a frequent problem. To solve this, the correct ID# has to be used in all the events where the incorrect ID was used, the ratings recalculated, and finally in a separate process, the other ID has to be deleted from the system.

An event is rated in the wrong system (quick instead of regular or vice versa). This effects every player in the event. First the rating change in the incorrectly used system has to be removed, and the ratings and following crosstables recalculated, then the entire event has to be correctly rated in the right system and following events corrected.

An event is accidentally rated twice. One of the duplicate crosstables has to be removed and then all ratings recalculated.

An event is received long after the ending date. This is also a too frequent occurrence and has important consequences upon our members. For this reason it should also be handled as a correction. The cutoff date for determining if an event should be handled as a normal rating report or handled by the corrections module is probably 6 months. If the received date is more then 180 days after the ending date, the report should be passed from the edit module to the corrections module for rating rather than being rated in the normal weekly rate. Note that this should be handled in the data entry module. Once an event in this class is entered and validated, it should be passed to the RCM rather then the weekly rate.

The basic process I envision is as follows:

Select events to be corrected and make corrections as required.

Identify subsequent events effected by ripple.

Move all selected events to the weekly rate files and rate during weekly rate.

In order to make a correction to an event, the operator enters the correction module and is given two choices, merge duplicate IDs, or select an event for correction.

If the "merge duplicate IDs" function is selected, a screen with room for 5 ID numbers, each with a check box is displayed. All the IDs for a given individual ( 2-5) are entered and a single box is checked to designate which is the ID to use to replace all other IDs. We have never managed to give an individual more then 3 IDs so room for 5 should be sufficient. The crosstable file is then searched to identify all sections with the non-checked ID #s. The program automatically replaces the incorrect ID#s with the correct ID number and the events are moved to the ripple calculation module (RCM). Time saving measures such is examining the date the memberships were created to eliminate unnecessary searching the crosstable files of inappropriate years is encouraged for this as well as other corrections.

If "select event' is chosen, a screen with a field for the event ID opens and appropriate check boxes appears. The operator enters the event ID and then selects either edit, delete, or change system. If "edit" is selected, the crosstable is converted back to the file structure used in the enter/edit module and the operator is allowed to edit the entire section or event. If only changes that do not affect ratings are made such as affiliate ID or CTD ID, the changes are made and converted back to the crosstable file. If changes that will effect ratings are made, after the editing is done, the event is passed to the ripple calculation module. If delete or change system is selected, the appropriate screen appears and the selected sections are moved to the RCM.

Ripple Selection module. [RCM]

The purpose of the RCM is to identify which events need to be re-rated due to changes in specified events. I am not sure how to accomplish this task by the most efficient means. If the rating program is very quick, it might be most efficient to just identify every downstream event and then re-rate it in date order. If the runtime for the ratings module is significant, pre-selection by calculating the ratings for each event and then only following up on ratings that changed might be the best method. This is something the programmers need to evaluate. It this is a really difficult problem the ripple can be reduced by pre-selection, comparing the post-event rating to the following pre-event rating and if the difference is 3 or less, just set the post-event rating equal to the subsequent pre-event rating.

The runtime of the RCM also should be evaluated to determine if it should occur every time a correction is made or if it should be a batch process where every so often the operator runs the module.

When a crosstable is changed, the date modified should be updated. Care should be taken to identify which sections were selected but not changed so that the date is not unnecessarily changed.

Rate corrected events

As discussed earlier, I do not know if the decision will be made to just select everything that might be effected and re-rate it or to rate one event at a time and evaluate the changes in rating for subsequent events. This description is based on the re-rate everything method but I am not showing a preference. The ideas discussed here can also be implemented as part of the RCM.

I also did not make a decision how to handle the crosstable files after an event is selected for correction. The selected event could immediately be deleted from the crosstable files and later have the corrected crosstable inserted or it could be left there and replaced or deleted only when corrected crosstable is ready to be inserted. Which ever method is decided upon, the various membership accumulator registers will have to have appropriate corrections made for both game counts and TD activity. If the accumulator recalculation and update function works quickly, the entire process can be avoided and this module run at the end of every rate. Another method is to just take average care and do a correction every 2-3 months. This is also a decision for the programmers.