Allow unbounded scores

[niemela]

Closes #218

• Explicitly allows max_score to be null, meaning that the score is unbounded.

I think we will add some limits on this in the scoreboard algorithm PR me and @deboer-tim have been working on (basically #150).

[deboer-tim]

I'm not sure if the implication of this is 'client scoreboards are now expected to calculate the current max_score to shade scoreboard cells accordingly' and if so whether it's worth effectively just moving this to the client-side?

It always felt to me like there were two differing opinions on how scoring contests should work and we didn't quite get the balance right - or maybe there should just be two.

[niemela]

I'm not sure if the implication of this is 'client scoreboards are now expected to calculate the current max_score to shade scoreboard cells accordingly' and if so whether it's worth effectively just moving this to the client-side?

I don't understand your options here?

The semantics for problems with a max score didn't change, and problems without were not allowed before, so I don't see the "now expected", the expectations didn't change for anything (but some new thing are now allowed).

It always felt to me like there were two differing opinions on how scoring contests should work and we didn't quite get the balance right - or maybe there should just be two.

There are definitely more than one kind of scoring contest. I would not call that "differing opinions on how scoring contests should work", because that sounds as if there is disagreement on how a specific kind of contest should work, but it's actually more of a "there exist different kinds of contests".

The specific kind we're adding support for here is the one where there is not max score for a problem.

[deboer-tim]

I'm not sure if the implication of this is 'client scoreboards are now expected to calculate the current max_score to shade scoreboard cells accordingly' and if so whether it's worth effectively just moving this to the client-side?

I don't understand your options here?

The semantics for problems with a max score didn't change, and problems without were not allowed before, so I don't see the "now expected", the expectations didn't change for anything (but some new thing are now allowed).

I disagree (also with the 'allow' in the PR title). The current spec generally doesn't say what can and can't change, and we have notifications to tell you about changes. In discussions we explicitly said the max_score could be updated. Maybe not expected, but clearly this was allowed before.

The issue is the 'Typically used to determine scoreboard cell color'. When we discussed making this optional in the past the expectation was still that scoreboard clients should shade cells from 0 to the maximum score, and hence must iterate over the scoreboard each time to calculate it. Or if you're a client showing a judge queue, you now have to grab the scoreboard (or all judgements) in order to calculate it.

It always felt to me like there were two differing opinions on how scoring contests should work and we didn't quite get the balance right - or maybe there should just be two.

There are definitely more than one kind of scoring contest. I would not call that "differing opinions on how scoring contests should work", because that sounds as if there is disagreement on how a specific kind of contest should work, but it's actually more of a "there exist different kinds of contests".

The specific kind we're adding support for here is the one where there is not max score for a problem.

Sorry, fair enough. That is what I meant - not in how, but what kind of contests we support. But, as per above, we're not actually changing that, we're effectively just saying the max_score is unknown and it's now the client's requirement to determine the current value. This is just a tradeoff in where the 'work' is done.

TBH I'm not terribly comfortable pre- or post- this change, because there are a lot of assumptions in either case about how scoring contests are supposed to work and what is expected on each side. Maybe making the bigger change would help give a place to explain some of this.

[niemela]

The current spec generally doesn't say what can and can't change, and we have notifications to tell you about changes. In discussions we explicitly said the max_score could be updated. Maybe not expected, but clearly this was allowed before.

I don't remember this discussion, but you are clearly technically correct. (The best kind of correct).

The issue is the 'Typically used to determine scoreboard cell color'.

Why is that an issue? It is definitely and clearly true.

When we discussed making this optional in the past the expectation was still that scoreboard clients should shade cells from 0 to the maximum score, and hence must iterate over the scoreboard each time to calculate it. Or if you're a client showing a judge queue, you now have to grab the scoreboard (or all judgements) in order to calculate it.

Yes, you would indeed have to do that.

It sounds to me that you are suggesting that max_score should always be required, and that the value should be the maximum possible score if on exists, or the maximum score achieved so far if not. Is that correct?

I don't dislike this.

Maybe making the bigger change would help give a place to explain some of this.

Yes, I strongly agree (as I alluded to in the PR comment). My original thought would be that e.g. the "normal IOI rules" (which should have a better name, but you know what I mean) would disallow unbounded max scores. So, the limitation that we (in some sense) remove here, would be added back there.

[niemela]

Discussed on our meeting today. The consensus was that adding the (dynamic) max score to scoreboard/ while keeping max_score in problem/ static (and null when unbounded) was a better approach.

Will update this PR.

[deboer-tim]

Why not just make this required when contest:scoreboard_type is score? It would be identical, but seems more consistent and one less step for clients.

[niemela]

So,

Required iff contest:scoreboard_type is score. Must be equal to problem:max_score for the problem if it is not null.

?

I'm a little bit torn. Like you say, it's probably easier for readers of the JSON, and it's not harder for writers. OTOH, it's unnecessary.

[eldering]

I agree with @deboer-tim here.

[johnbrvc]

What @deboer-tim described above sounds good to me.

[niemela]

Ok. I will do that change.