NON-RANDOM PLATE ASSIGNMENTS?!?!?!

FIRST General Forum
1

I’ve been working on scripts to extract game data from the Blue Alliance API. One of the fields I’m able to import is the game data from the field (plate assignments). Out of curiosity, I put the four plate configurations in a pie chart and uncovered an unsettling pattern.


Config	Count	Frequency
LRL	10110	23.75%
LLL	9090 	21.36%
RLR	13788	32.39%
RRR	9576 	22.50%
------------------------
Sum	42564	100.00%

Of course, these are randomly assigned, so one would expect some variance from a consistent 25% across the board. Nevertheless, a simple 2-proportion z test shows that this is an irregularity indeed. The z- value of such a deviation is 23.8, so improbable that my calculator doesn’t even try to pretend it isn’t zero.

So what’s more likely? That this deviation occurred by chance? Or is FIRST conspiring to give a leg up to teams that start on the left side of the field, have a scale auto, climb on the left side of the rung, and have very maneuverable drivetrains?

You tell me.

2
3

You might want to discuss this here

4

Never attribute to malice that which can be adequately explained by bugs.

5

Humans are TERRIBLE at generating random samples because we see something like this and say it isn’t random enough.

6

Exactly,

Just because it doesn’t look random, doesn’t mean it’s not random.

A uniform distribution of switch/scale assignments means that these results have a lower probability of being seen after this many matches, not that it’s impossible

7

Except in this case it’s not the humans saying it’s not random; it’s the math…

Statistics tell us that if we’re seeing deviation greater than ~0.4%, it’s 95%+ likely that the assignment is not random.

8

Given that there have been a little over 7000 matches this year, I am confused about your methodology. How did you get 42564 matches?

9

There is also no such thing as a truely random number generator in code. And yes, based off the results it looks like they used one of the less random options. Its random enough for me. If you want better start having the FTA roll dice every match.

10

We are talking something like p < 10^-41. 1 in 10^-41 chance that a random distribution where P(RLR)=0.25 would produce a frequency of RLR = 0.32 over 7000 trials. Please see the other thread linked above in the first and second replies.

I don’t know about you but considering it’s more likely to draw seven royal flushes in a row, I have an inkling that it’s not that it “doesn’t look random”, but that there is EXTREMELY significant statistical evidence that P(RLR) =/= 0.25.

Just because it’s not equally distributed doesn’t mean it’s necessarily gamebreaking; however, I think it was implied that each configuration would be equally likely. If that was the intent, they need to find a new RNG

11

Shot in the dark - do practice matches count?

12

If they were, it wouldn’t get you anywhere near 42564 matches. May be something else.

13

Looks like a multiple of 6 to me. Why does that number seem familiar…

14

You are correct; but the problem with most software-based random number generators is that they produce sequential patterns in the long run (in formal terms, they are “periodic” and “deterministic”), not that they fail to produce roughly equal results. Based on the data presented above, it would seem that there is an unintended fault in whatever the FMS is using to generate the assignment (assuming FIRST did not deliberately seek to favor some outcomes over others).

As far as whether this is “random enough,” we have to differentiate between statistical and practical significance.

To borrow pkrishna3082’s example, if this is statistically “random enough,” then means then drawing 7 royal flushes in a row would be “random enough.”

From a practical standpoint, I suppose we can agree to disagree.

In any case, a value for p < 10^-41.1 is evidence beyond any reasonable doubt that the FMS’s assignment is not statistically random. There are plenty of software based random number generators that could provide much more acceptable levels of P.

I’m inclined to believe there’s a glitch somewhere in the system. Again, the practical significance of which is up for debate.

15

Practical significance:

  • Line your robot up on the left for scale auto
  • Line your robot up on the right for switch auto
16

This is all a conspiracy!! Or is it just the fault of sudo random numbers? ¯_(ツ)_/¯

17

sudo random_number; // generates a weighted random number with super user privileges

18

I was going to say:

sudo random number: Random number declared by the super user.

19

I think we need a couple sanity checks on this data. Is this all from the perspective of the red alliance or all from the perspective of the blue alliance?

If, as someone mentioned earlier, we are looking at the combined perspectives of all the robots (both red and blue), the data looks absurd. For each robot experiencing an RLR plate assignment, there is a robot on the other side experiencing an LRL plate assignment. Therefore, the LRL and RLR percentages should be exactly the same.

20

Try again. Think very carefully about what you’re saying.

Because it doesn’t matter which of the 4 assignments are used, it looks exactly the same to the red alliance and to the blue alliance with respect to which side the one they need to go to.

LRL is not the opposite view of RLR; it is the inverse.