isn't O(n^2)? use ramdom accessible data structure might be better.

I can't wait to solve further complex problems, great kata, keep it up and going, many compliments.

Nevermind, the comparison was, in fact, terrible. Rewriting it fixed the issue

Tried using bubble sort, timed out. The description is a bit misleading, I thought there was 1 100 character test (the description uses word "test", not "tests"), there were multiple. Do you think the problem lies in some component of my solution? Should I, perhaps, switch to counting sort? I think my implementation of comparisons is inefficient, but don't think it's that bad.

The specification isn't super clear on its definition of valid identifiers. In one part, it says to use the rules of C-style identifiers, but the BNF's for both Kotlin and Java say <valid java identifier>.

As of Java 9, a single underscore _ is not a valid identifier, but the tests expect it to be valid.

Very imaginative problem! Interestingly, as long as the array doesn't contain zeros, a similiar idea works if f gives products rather than sums.

I found the answer in the linked kata. The subarrays should be contiguous, so the answer for the above example is {{2}, {2}, {2}, {2}, {3}, {2,2,2}, {2,2,2}, {2,2,2,3}, {2,3}} and the result is 9.

I should read the description more thoroughly. :)

Could someone help me understand the requirements? Given an input {2,2,2,2,3} will the correct answer be the "8"? Because, the result range is {{2}, {2}, {2}, {2}, {3}, {2,3}, {2,2,2}, {2,2,2,3}}? Or the {2} sub-array should appeare only odd number of times and the answr will be "7"?

If my logic is incorrect i'd be glad to see the example for the input above.) thank you in advance.

What you quoted does not describe nameOrNumber. It's only the first bullet point for the three types of expressions, which also includes numbers.

We have three kinds of basic expressions:

• names, like abc, ABC, run, a1, beginning with _/letters and followed by _/letters/numbers
• numbers, like 123, 02333, 66666 (may have leading zeroes)
• lambda expressions, like { a -> a }, { a, b -> a b }(source), (a){a;}, (a,b){a;b;}(target)

Additionally, the BNF for both source and target do not specify nameOrNumber, and per the grammar described, something like {3,x->y} is a valid lambda function as it matches the following pattern: "{" <nameOrNumber> "," <nameOrNumber> "->" <nameOrNumber> "}"

And as another point, the description specifically states that lambda expression parameters are names/numbers:

Lambda expressions consist of two parts:

• parameters, they're just names/numbers
• statements, a list of names/numbers, seperated by whitespaces in source language, by ; in target language.

nameOrNumber is specified as follows:

names, like abc, ABC, run, a1, beginning with _/letters and followed by _/letters/numbers

So your assumption seems incorrect to me.

In the process of adding random tests to Haskell (fork here), I found that there are two types of valid inputs that aren't covered by the existing tests:

• Lambda expressions with numbers as parameters (such as "{3->a}()")
  • Intuitively, I wouldn't expect numbers to be valid lambda parameters, but that's how it's described in the grammar for both the source and target languages
• Expressions that do not invoke a function call (such as "fun", "34", or "{a->a}")

These cases are included in this new fork. The author's solution had to be updated to pass these tests, and it's likely that many other solutions will be invalidated as well.

The published Haskell translation has this as an edge case.

I know it's been a while since this was published, but could you please check the latest issue about this? :P

It would be good to have in the description the boundaries for the input. For instance, knowing whether the maximum number of bytes ever exceeds 255 would change my approach to the problem.

Also, I personally believe that "Mention, don't care about" isn't very clear. I'm not sure whether those cases are present in the input and I have to disconsider them or if they aren't present at all.