This is what I was commenting on. If I remember correctly, in the old system it would pull up the name based on the ID. I erroneously used the same ID for two players and it used the name I submitted, not the name associated with the ID. Had it pulled in the name associated with the ID, I would have caught that one kid was listed twice. Now, somewhere in there there may have been an error message about a name not matching the ID. But I had around 125 kids and I had about 125 alerts. I read the first 20 or so and they were all “not in expected state” although they were in fact all in the expected state. So I did not make it through the whole list. It will help when they can eliminate the false positives.
The ID is still considered the most accurate, largely because with 1.3 million records in the database we have a LOT of similar if not identical names.
My favorite example is always Kevin Wang. Last time I looked I think there were around 76 of them.
I know for a fact that two of them live within 3 blocks of each other in California and have similar ratings, but I don’t think they’ve ever played each other.
I just realized another problem. Maybe it’s handled by a rerating.
His opponent was also in two sections.
Both calculations were done from 1465. Wouldn’t the first result feed the other?
1 Like
It should. I believe this is an error in the programming that is being worked on. A rerate should fix this.
Rewriting (building new) the rating system on that budget is fine on the range, but the decision of rewriting in my IT development career 80% always come from “Developers do not understand the legacy code, and easier to rewrite for their own comfort zones”. Having “GO” to write “CHESS” is mind boggling specially when they want to REWRITE.
The project is already on the way more than 70%, they just need to finish what they say what will be done w/o draining more budget and high cost maintenance.
We have weekly Blitz events where there are almost always multiple sections with most of the players participating in multiple sections of Blitz. These would be good to check after the fix and re-rate are in to make sure they follow the spec’s order with the same start/end date. Much tougher to find the edge cases with different start end dates.
yes, I suck at blitz – most of my losses were flags in + or = positions. I can’t convince the kids to play with a d5 or +5 where I think I might not flag as much.
Having written the legacy code, it was in serious need of a rewrite anyway, and the data structure was also in need of some work, because it mostly pre-dated the ratings system I wrote.
The rate process should not only handle players in multiple sections within a tournament, but also the same player may be in a section more than once (re-entry in multi-schedule event).
I hope this is reviewed.
tom
When a player has more than one pairing number, the games from multiple pairing numbers are aggregated and rated as a single block of games. I’m pretty sure that part is working because we tested nearly every reratable event in static testing and that include quite a few events that would have had players with multiple pairing numbers.
I think what it may not be doing is showing the same pre and post rating data for both pairing numbers. That’s something to report.
1 Like
Mike, I really appreciate all of your knowledge and your participation in the forum. Your help is invaluable!