This works fine when the walk length is exactly 10 (which I appreciate is the length given in the instructions). However, it would be risky for future updates if (for example) the walk length were to be increased.

You could take a .Distinct() of row, column, and 3x3 square to make sure you have 9 distinct values. This would also allow you to verify each number is within the 1-9 boundaries.

@Kartoffelsalat Could you explain what is happening here?

Many people say the code is clever, but it is just wrong. Be careful my friends.

nice kata!

There is a typo (one paranthesis too much) in the example in the description:

It should be: {"A": [1, 3], "B": [2]}

Не надо так много думать))

so clean

Hmm. My solution is very similar, but I found that for

`n = 0`

it returns`[NaN: NaN]`

. So I added an extra check for zero`n`

.But now I discovered that such a solution is successfully passing the tests. It's interesting.

And it looks like it is not a test case problem. It's a problem with the

`Test.assertDeepEquals()`

function.smart use of sort and destructure of function parameter, i have a very similar solution

This works fine when the walk length is exactly 10 (which I appreciate is the length given in the instructions). However, it would be risky for future updates if (for example) the walk length were to be increased.

Because "product" is a multiplication operation, and it must start with 1

great solution, in the product part why is there a 1 at the end?

i have my solution! My message is, that this solution here is a Fail.

You could take a .Distinct() of row, column, and 3x3 square to make sure you have 9 distinct values. This would also allow you to verify each number is within the 1-9 boundaries.

this Soltion lags with the following (only fifth, or 9,9,9,9,2,2,2,2,1)

Unnecessary linq. Too greedy for this simple task.

## Loading more items...