MSA crosstable oddity

I would argue that after 8 the next number would be 12 in the sequence.

v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
v
1 has 1 e
3 has 2 es
5 has 1 e
7 has 2 es
8,9 &10 all just have 1 es
11 has three es
12 has 2 es
so 1,3,5,7,12

I said alphabetically by height and I meant the numbers alphabetically.
EIght
ELeven
FIve
FOur
Nine
One
SEven
SIx
TEn
THree
TWo
Zero (if it is 5’0" instead of 5’ then it moves from the beginning of the line to the end)

I think fails is the wrong word. It does what a tie-break calculation does and works fine. It isn’t intended to denote prizes or actual order of finish, any more than alphabetical order is. You may feel it provides an unintended result; I think you’re making an assumption that it implies a result.

Thank you yogi Yogi!

Any purported tiebreak information that isn’t IDENTICAL to the tiebreaks computed at the tournament is going to create problems, which is why the only system that works is where the organizer/TD is responsible for reporting the final standings AS DETERMINED AT THE EVENT.

If the tiebreaks or standings for an event change after the fact for any reason, it would be the organizer’s or TD’s responsibility to decide if US Chess data should be updated.

A separate issue that would arise if we try to show detailed prize information is that the prizes one was eligible for cannot be reliably determined from crosstables in their current form.

I don’t see it that way. If SEVERAL sorts are offered, including an “Organizer Reported Prize Sort,” then US Chess doesn’t seem to have any issue at all. It’s just another sort. And if someone clicks on that radio button and it hasn’t been reported, just report “Information not available.” We can even note that prior to date X, this information is not generally available, and may be only sporadically available for later dates.

OK, then instead of $5000 it might cost $25,000. Where’s that coming from, what value does that expense bring to the Federation? Are there more than a small handful of zealots who give a d***?

I’m not arguing that we should be spending money on that at the current time. There are definitely higher priorities.

I’m simply saying that IF an effort were made to add other SORTS, then there’s really not a downside to also adding tie-break sorts.

Well, there we’re going to just have to disagree, and it’ll be interesting to see whose viewpoint prevails over time. I don’t see the plusses, certainly not enough to justify a significant expenditure on. And I have 15 years of experience with complaints from members to give me plenty of minuses.

As I see it, approximately 4 new fields would need to be added to the upload format: 1st tiebreak, 2nd tiebreak, 3rd tiebreak, and 4th tiebreak. An organizer who wants tied players to be listed in the tiebreak order suggested in rule 34E need only tell his pairing software to fill these fields with Modified Median, Solkoff, Cumulative, and Cumulative of Opposition respectively. I’m betting WinTD and SwissSys can already do this.

OK, so 5 new fields. The 5th would be the ratings actually used to make pairings, as in my suggestion D.

These “actual ratings” could differ from the published pre-event ratings for a whole bunch of reasons, including some of those pointed out by Jeff. Or, the organizer might just want to use a rating more recent than the one in the latest supplement that “should” have been used, especially if the player might otherwise be unrated.

Of course, pairing software would have to be upgraded as well. An organizer who uses older versions of pairing software would still have my options A, C, and E available, i.e. the viewer could still choose from among:

  • (A) by score, and within score by rating
  • (C) by rating, without regard to score
  • (E) in alphabetical order, without regard to score or rating

– but could not choose:

  • (B) by score, and within score in the order specified by the organizer
  • (D) by score, and within score by the rating used at the tournament for pairing purposes

– and these options would be grayed out.

Ugh. I would hope that my options B and D would satisfy the other side. If not, at least the viewer would still have option A, even though it might no longer be the default.

Bill Smythe

You also need to know the score group for prize purposes, since that can vary from the score group that the rating data would produce. (But this can probably be generated from the other data fields listed below.)

You might need to go beyond 3 tiebreak methods, I’ve seen it take 5.

And if you don’t show the pairings and results that were used to compute those tiebreaks, which might involve players or games moved to other sections or to extra games sections for ratings purposes, you’ll get complaints that the tiebreaks are wrong. (We see that now.)

And none of this answers the fundamental question: How will having this information benefit the organization to the point of being worth its cost to develop and maintain?

When the results used to calculate the tie-breaks are different from the results used to rate the event then adding the tie-breaks will generate unnecessary complaints to the office. If it reaches the level of formal complaints where a $50 good faith fee is paid then they would have a decent chance of being ruled frivolous with the good faith fee retained instead of being returned.
The order used to award prizes is more reasonable, but does require generating and uploading the rating report before making any corrections and then going into the uploaded data to make the corrections. Such a manual correction would also be needed when a play-off was used to determine a prize and the result was different from what tie-breaks would give. That also takes care of post-tournament notifications of results that need to be changed. I wouldn’t have a problem with a big, flashing red header saying “MAY NOT BE IN PRIZE ORDER” for any sequence other than the provided order sequence, and for a radio button to be required on submission to activate that sequence.

There are also anti-sandbagging measures that can cause different ratings to be used. Some of those would be the CCA list, conversions from other rating systems and tournaments that use the highest rating over the six months prior to the event.

And note that a wall chart might not be in rating order. It is rarer nowadays but it used to be that late entrants were added to the end of the paper wallchart regardless of their rating.

I’ve seen more than five used with a still-tied result having to be resolved by a coin flip.

First, I don’t see why the above is needed if an organizer tie-break is an option.

The benefit isn’t to US Chess as an entity per se. It’s to the members and organizers. If that needs a slight fee change to monetize the benefit and recover costs, in the current debt rate environment that shouldn’t be a huge deal.

Do we care what rating was use so long as we know the actual number used?

Nope.

Wasn’t disputing Bill’s idea, just expanding on why the ratings may be different and why (as Bill said) the month’s official supplement rating might not be the one used for pairings and that is why the actually used one would be useful to provide.

Forgot to add that the early-in-the-month National Scholastics will use the previous month’s supplement instead of the current month’s supplement.

I think the USATE has often used December ratings for a February event, because it gives people time to form teams meeting the combined ratings limits.

Knowing what rating was used for pairing or prize purposes (they might not be the same) will lead to questions as to WHY that rating was used. (And the answer might be “That’s what rating I saw online at 7PM on Thursday”.)

Doesn’t mean it isn’t a good idea, though a ‘kitchen sink’ approach will complicate data collection and could make it difficult to display all that information cleanly.

And all that increases development and other costs.

Perhaps link to affiliate contact information more directly than currently and direct questions there.

They are also the numbers of the months of the year that have 31 days. :smiley:

Bob

Maybe that’s the real reason wzim argued that 12 should be next (he forgot about 10). :slight_smile:

Bill Smythe