2016 Ratings Program Changes Plus Some NWSRS History

Based on an email from Kirk Winges to Jeff Dobbins, March 2016:

The rating system was originally created back in the early 1990s by Ollie LaFrienere (the "Godfather" of scholastic chess in Washington for so many years), and was just the Washington Scholastic Rating System, or WSRS. In those days Ollie limited it to just 9000 players, and while there were a few Oregon and BC players, most were Washington. His numbering system was simple, just 1000 to 9999 (leading zeros cause problems, so nothing below 1000). He assigned numbers by hand.

When he died at the age of 67 in 2002, there were no formal "inheritance" plans for the rating system. A couple of years before his death, Ollie had to go into the hospital for surgery and he was concerned that if he didn't come out of the hospital, the rating system would die. He invited me over to watch him rate so that I could see how the system worked. I was fortunate enough to be one of the few that had ever seen the inner workings of the rating system. I don't attribute it to any special relationship Ollie and I had, rather I was just the guy at the moment that he felt he could trust. I was frankly appalled at how manual the system was, and offered to write code to make his life easier. Ollie didn't like change so he resisted my efforts to help him.

When Ollie died a few years later, a number of us in the chess community were invited to his condo by his family (he was never married and had no children, so it was a brother and a sister as I recall). I talked to the others there and offered to take over the rating system, since I had a lot of programming experience and had actual knowledge of how it worked. Nobody said yes or no, I just did it. The family actually gave me his computer, but other than getting the latest rating file off it, it was worthless. He had no source code for his rating program — it was written by someone else that had long since left the chess community. The program hadn't been updated in years and was using an antiquated version of the USCF ratings algorithm.

So I started from scratch and wrote an entirely new ratings program, not based on his original at all. We were still limited to 9000 unique IDs. Chess was growing in popularity in Washington, so even then I knew keeping the numbers down was going to be a problem. So like Ollie, I instituted a program of culling the system every year. That involved removing players who had become inactive and re-cycling their numbers. In those days the database had between 6,000 and 8,000 entries.

A couple of years later I was running pairings at a Washington State Elementary tournament and the members voted to eliminate non-Washington residents from the state championship. To be fair to the somewhat parochial attitude of the folks who voted that way (I didn't vote, since I was busy running the tournament and had no time for meetings), the event was getting too large for most available venues in the state, so I could see the desire to limit the numbers. At that same tournament I was approach by a couple of women from Oregon [N.B. likely OSCF founders Kate Taylor and Amy Coughlin — JCD], who said they were big fans of the WSRS and want to make an Oregon system, presumably, the OSRS. They asked for my help. Instead I proposed a combined system with Washington, Oregon and perhaps Idaho and BC all in the mix. The NWSRS was born at that point. Amy became the Oregon coordinator and was a great working partner for the years we worked together. The system was immediately going to be too big to handle the 9000 unique IDs, so we modified it to make the first character alpha-numeric. That expanded it initially to 35,000, which seemed enormous at the time. We quickly eliminated alpha codes with "O" since they were constantly confused with zero, so it was actually only 34,000 unique IDs. We set aside 20,000 for Washington, 11,000 for Oregon, 1,000 for BC, 1,000 for Idaho and 1,000 for "other". Later BC got too big, so the "other" category is now "BC or Other".

Initially I continued with my practice of culling the system, just to keep the numbers down, but several times we had problems with some kid who played 5 games in one year, and then did not play for another 5 years, got culled out. Then he shows up at a Chess4Life event (they have complete records going back to 2002), and they pull his old ID out and enter him. When it hits the rating system, I see I have two kids with the same ID. I didn't see a big problem with just assigning the returning player a new ID, but Chess4Life had a problem with it, since they have software that makes plots and such using the ID number as a reference. They argued, correctly, that USCF does not recycle ID numbers, and thought I should do the same. I agreed to their request and about 5 years ago, I stopped culling the system and it has grown by a couple of thousand players every year. We have over 27,000 entries in the system now. I knew the limit was 34,000 IDs, so I knew we were getting close, but thought I could hold out until the summer to make the big change. What I had forgotten was the limit of 20,000 for Washington players. We hit that number in 2016, and it didn't crash the system or give me any warning (blame the programmer for that…wait, that's me!). It just started assigning IDs of 0 to some players. It got called to my attention when a school coordinator noticed that one of her players had qualified for our state tournament the previous weekend, but wasn't on the qualifier's list. She also mentioned he had a zero ID. That player was a special case since he was also a duplicate ID and was already rated under the last name DEJESUS but was registered as an unrated in the recent event as DE JESUS so the duplicate wasn't caught. I solved his problem easily by just changing the result to the established ID, and eliminating the one with the zero ID. But then I looked and saw it was not just him, but 30 others also had zero IDs. I quickly figured out what had happened, but then had to fix it.

I made the decision, based on a suggestion from Lane Van Weerdhuizen at Chess4Life that I change the last character to alpha. The reason for doing the last character instead of say the second character is that we already have a problem with too many characters in a row leading to the possibility of "inappropriate" words getting into the IDs. Consider a player from a school with an name like Ashgrove Middle School, and the innocent school code of ASH (no such code exists — this is just an example). If you had an 8th grader there the first 4 characters would be ASHI and if we allowed the fifth character to be a "T", we gotta a problem. So I have to guard against things like that, and with an extra character in the series being alpha, the problem becomes overwhelming. Lane's suggestion that we use the last character avoids those extra problems.

I manually added IDs for the 30 kids who didn't have them, then went back and manually edited the results of the 7 tournaments that had no IDs. Then I went about modifying the programs to take the expanded ID system. That was harder than it seemed at first, because I had always used a system where each time it encountered a new player and needed an ID, it would sort through the 34,000 theoretical IDs to find those that were available, then randomly assign one in the applicable state range. It didn't take too long for the program to find the right ID, but there was a delay of maybe 20-30 seconds at the end of the program run depending on how many unrated kids there were. With the expansion to 116,000 IDs that process became several minutes and was not workable if you are rating a large number of events. So, I switched to a different system where I have external files with available IDs for each state that are already sorted in random order. So at the start of a run, the program reads in the current lists of available IDs, and when a new ID is needed it picks one off the bottom, and reduces the number of available IDs by one. At the end of the run, it writes out the modified available ID lists. It works like a charm and is much faster, but the one problem is if I have to re-rate an event for some reason, I no longer have the list of available IDs as it existed at the time the ratings run was initially made for the event that needs to be re-rated. So I have adopted the new practice of saving a copy of the available ID files in each event directory. It's an extra step, but only takes a few seconds, provided I remember to do it.

Kirk Winges, 2016