Worldcubeassociation.org: Cutoff in Multi-Blind is not strictly greater than.

[Jambrose777]

Describe the bug
For this competition: https://www.worldcubeassociation.org/competitions/KievSuperBlind2019#general-info

The multi-blind cutoff is "1 Attempt > 2 points"

And then for this person's results:

We have this error:

Which is incorrect.

[AlbertoPdRF]

I've added this to https://github.com/thewca/worldcubeassociation.org/projects/4 too.

[jfly]

Somewhat related, see Cutoff in the WCIF documentation

And the relevant code: https://github.com/jfly/worldcubeassociation.org/blob/fd5a534f7b118cb192225d911aae4fcd98122969/WcaOnRails/lib/competition_results_validator.rb#L473. We should definitely add a test for this when we fix it.

[viroulep]

I was about to report the same bug.
This is actually not an issue with the validator, but with the way we create the attempt_result in the edit events UI.

WC2017 has a couple of (wrong) validation errors due to that, so I'm gonna take some of the results as examples.

# Kit's 9/9
irb(main):017:0> res1.wca_value
=> 900334100
# Tomoya's 14/17
irb(main):016:0> res2.wca_value
=> 880334403
# SolveTime's behavior:
irb(main):019:0> SolveTime.points_to_multibld_attempt(9)
=> 900099900

In that case Kit's result doesn't meet the cutoff.
But now if you take a look at the Round's attempt_result, computed by https://github.com/thewca/worldcubeassociation.org/blob/a61264e5e713f84985397f036f3b8cd161407ed0/WcaOnRails/app/javascript/edit-events/modals/utils.js#L47-L53

irb(main):018:0> round.cutoff.attempt_result
=> 909999900

Then Kit's result meets the cutoff.
So mbPointsToAttemptResult is not strictly ported from the ruby function, but most importantly none of them gives us a value we can reliably use as a cutoff for n points!
(In the case reported by Jacob, I think the result wrongly meets the cutoff using both functions)

I see two alternatives to fix the issue:

• make both "points to attempt result" return the "perfect" 9 points in 0 seconds (that would work as a cutoff because it literally means you have to do 10 points, and the function is basically used just for that!)
• make the edit round UI store a n+1 points in 99999 seconds, which effectively means that anyone doing n+1 points would meet it (and therefore pass the n points cutoff)

While both would be valid cutoff, I must admit I'm strongly in favor of the first point because we can directly get the cutoff value in points from the attempt result.
Anyone has an argument in favor of going for the second alternative?

In any case we would have to go over existing cutoff for multiblind to update the attempt result to the appropriate value (there should not be much so I could look into it).

[viroulep]

The good news is: it's relevant to only 3 competitions :)

irb(main):001:0> Round.includes(:competition_event).where(:"competition_events.event_id" => "333mbf").select(&:cutoff).map(&:competition).map(&:name)
=> ["World Rubik's Cube Championship 2017", "Nordic Championship 2018", "Kiev Super Blind 2019"]

[viroulep]

Unless someone has some points in favor of the second option, I'll merge the PR fixing this issue, and fix the 3 relevant competitions tomorrow!

[viroulep]

I've also fixed the 3 relevant competitions by editing the 333mbf round.

[jfly]

So mbPointsToAttemptResult is not strictly ported from the ruby function, but most importantly none of them gives us a value we can reliably use as a cutoff for n points!

Just to be clear, the problem here was that the Javascript code was (correctly) converting 99999 seconds to centiseconds, but the Ruby code was incorrectly treating 99999 as a number of centiseconds?

[viroulep]

Not really: actually as long as there was a time encoded in the value returned by mbPointsToAttemptResult we would have had an issue.

Like if we want to put a cutoff at 2 points and the value is 980099900, then any 2 points done in less than 999 seconds would meet the cutoff (whereas it doesn't actually meet the cutoff).
Therefore the only ways to make this work is to have the cutoff be:

• 980000000 (no one can do 2 points in 0 second, so in practice you need to do any 3 points to be below that)
• 979999999 (literally all 3 points will be below that, which is another way to express the same cutoff)

I liked the first way better because from the value you directly know the cutoff is 2 points.

[jfly]

That makes sense! Specifically, the reason why ruby and javascript were behaving differently (even though neither of them was doing what we want :p) was a centiseconds versus seconds mixup though?

[viroulep]

Yes absolutely :)