The random tests in Python have several issues:

• Lower bound of rows/columns of 2 instead of 10 per the description.
• Reference solution throws an error if no elements of the contour are within the range $[a,b]$, which is not a guaranteed property of the generated matrices.

Following that rule, all remaining moves would be skipped if the player's row was empty, because there are no valid moves.

In sungka, when you're out of marbles in your row, you will keep on skipping turns until a marble reaches in one of your holes in your row.

The reference solution in Python does not follow this rule, which can lead to unexpected failures in the random tests for solutions that do follow the rule.

Here's one such input:

moves:
  [4, 5, 7, 3, 2, 1, 7, 6, 2, 3, 3, 1, 6, 1, 3, 7, 3, 4, 7, 6, 6, 5, 7, 7, 5, 4, 7, 3, 7, 7, 1, 2, 6, 7, 2, 6, 6, 6, 4, 4, 4, 2, 7, 1, 2, 2, 4, 3, 6, 2, 2, 3, 2, 1, 1, 4, 5, 6, 4, 1, 1, 5, 4, 4, 7, 1, 5, 3, 5, 2, 2, 1, 4, 2, 2, 4, 6, 5, 1, 5, 1, 6, 6, 2, 3, 7, 3, 7, 3, 4, 7, 4, 2, 2, 4, 1]
reference solution:
  [[0, 0, 0, 0, 0, 0, 0, 60], [0, 0, 2, 2, 1, 1, 3, 29], 1]
actual solution:
  [[0, 0, 0, 0, 0, 0, 0, 63], [0, 0, 0, 0, 1, 2, 0, 32], 1]

It seems that the performance version has looser performance requirements than I expected, because my refsol only performs a single optimization to trim the search space for common subsequences instead of the full DP implementation.

I've forked my fork, reverting the reference solution.

I've made a fork that addresses all of these along with updating the reference solution to be much more efficient.

Random tests in Haskell could use some work:

• Almost every pair of random strings contains a longest common subsequence of length 0 or 1, which allows for solutions like this.
• The error messages for random inputs aren't very helpful:
  • The random strings use characters from the entire range of Char, leading to pairs of strings like "G8\1100651\95058\SUB\\A\b" and "\n\n"
  • When the returned value is shorter than the expected value, the error message will be something like expected: 0 but got: 3, with no indication of what the numbers indicate.
  • When the returned value is not a common subsequence, the error message is expected: True but got: False, which again does not tell the solver what the actual problem is.

Not a bad idea! Forked with the suggested description changes.

Haskell fork

• Test suite updated to use approximate equality instead of exact equality to a truncated result (addressing this issue)
• Console logging removed from random tests

Haskell translation

I'm 100% in agreement with your logic, and the description should definitely be updated with some clarification. Here's how I would describe the circuit.

• The circuit has an internal state that is determined by the sequences of button inputs. This state is either OFF, RED, or BLUE.
• When the circuit changes into either the RED or BLUE state from a previous, different state, the corresponding red or blue LED will blink once.
• When no buttons are currently being pressed, the circuit is in the OFF state (the initial state of the circuit).
• When a single button is being pressed, the circuit is in the state that matches the color of the button.
• When the circuit is in the OFF state and both buttons are then pressed, the circuit switches to the RED state.
• When the circuit is in either the RED or BLUE state and the matching button is held down, the circuit will remain in its current state.

Naive solution.

Let $m$ be the number of distinct elements of $a$ and $n$ be the length of $a$.

Time complexity: $\mathcal{O}(m \cdot n)$

Space complexity: $\mathcal{O}(m)$

Fork that updates the random tests.

No problem. I've forked my translation here incorporating the changes.

There wasn't too much of a performance hit with the previous constraints, but it is definitely more common to work with 64 bit signed integers (Int) vs. unbounded integers (Integer).

Haskell translation

Haskell translation