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.

well, from the docs (https://kotlinlang.org/docs/native-objc-interop.html#initializers) ..

because Kotlin has no concept of extension constructors.

so what is this kata about

any further hints? I got rid of the division by modular inverse but still too slow for random test

This kata was decided to stay.

Good Kata! Thanks to author!!!

To answer the question, not quite. If you had two eggs and 14 tries, and observed the first egg break on the Nth try, you then have one egg and 14-N tries remaining. In other words, the tries are cumulative. Notice therefore that increasing n beyond m has no effect, since you can use up at most m eggs no matter your strategy.

Good kata, I learned something new today.