Adjustments look good. I'd approve if I could. I thought I had the power.

I think I was trying to agree with you that the large test would do well to discourage innefficient solutions. :-)

Thanks for the feedback. Please see below:

• Not sure if you mean that the value should be higher than 1000 for it to have a genuine impact on performance. I do however want to discourage innefficient solutions.
• I have dropped the square brackets from the test names and made some other minor adjustments.
• To avoid confusion I have changed the sample test to also use strings. With that test I'm just trying to re-enforce that the element type is irrelevant.

Overall, great submission! I have a few observations:

• Large/1000 x 1000 test executes in 50ms. I wonder if this will be a time or memory hiderence for inefficient solutions.
• Random test names would read cleaner without [][]; The number of dimensions are already found in the size 3 x 3.
• In comparing the sample test name 3 x 3 - Chars vs random test name string[][]/3 x 3.
  • Sample test has a matrix of char where the random test produces a matrix of String.

Nice to see a Stream.unfold/2 solution!

I wonder if directly using Enum.count/1 to avoid allocating a list would reduce memory usage significatly.

Did you know there is a built-in Integer.is_even/1?

Use Kernel.div/2 for integer division to avoid rounding.

Look into Stream.unfold/2 and compare how that would change the implementation.