Op solved it, closing

Thank you! This should really be in the description, especially since the example tests don't cover colors with digits A-F in them.

OMG thank you!

good explanation, thanks for clarifying. There's a typo in your [0, 4] example. You've got the 0th and 5th bits.

Very clear explanation, thank you.

thank you sir

I'm not a native speaker either but how I understood it:

You changed the line

var result = simpleVariable + variableInLoop + variableInFunction;

You aren't supposed to change that line. To tamper with something is to change or touch it in an unwanted or bad way. In that line you are adding (+) some things to each other. So what the message is saying is: "You have made a change somewhere where change was not allowed. This forbidden change was made somewhere where things are being added together."

Tempering I think is some strange process that involves steel? idk

It looks like the length of the array is 37, not 30. You must include all elements of the array, as explained.

return the index such that the sum of the elements to the right of that index equals the sum of the elements to the left of that index.

Is this Rust-specific, or would you say this applies to JS as well?

I'd say it should be a default assumption for allocating memory dynamically in general in any language. I don't know much about memory allocators; obviously, it's extra work to do at each iteration, but I'd guess that with reference counting it's probably the same block of memory each time because it's freed by the next iteration, but with garbage collection it has to find a new free block every time and then collect all that garbage.

@JohanWiltink:

the tests seem limited to m = 4 so that's practically a constant.

The description was misleading, I clarified it. The intention of "Tests use large m," was to test high values in m, not a large set size.

I specifically included large values in m, because they can cause overflow problems. My first naive Rust solution panicked on large m values.

Testing large m set size does not seem necessary.

I think requiring such extreme performance is overdoing it just a little - that seems to come with 3 kyu and "implement advanced requirements in a scalable fashion".

My intention is to allow any O(n) solution, and deny the naive solution which repeatedly scans further and further back into the sequence. Balancing the correct amount of tests to achieve this can be difficult, especially when execution time varies based on server load and language version.

allocating memory in a loop isn't the best idea in general

Is this Rust-specific, or would you say this applies to JS as well?

I don't really see the problem, its scope is explicitly limited to the current iteration of the loop, and it would be entirely possible to allocate the memory once, outside of the loop, and reuse it on every iteration, but I'd actually consider that a worse idea than what it's doing now.

I guess it's up to the author... The first JS solution runs in less than 6 s in Rust, even though allocating memory in a loop isn't the best idea in general, so it might be reasonable to decrease the number of big number tests in JS. (Same for the Ruby translation too, it's even slower than JS.)

I left my first attempt in, so you can see the differences.

It's all just in the constant factor of O(Cn). Therefore, I think my first attempt could have passed, because constant factors should not be prohibitive for big-O performance. Mine was about 2 times too slow; allow for a bit more leeway in C, also, as mentioned, if O(n) performance is desired instead of O(mn), test with bigger values of m but smaller values of n. The description hints at this, but doesn't follow up with tests.

It really comes down to the intent of the kata. Which may be a deeper question than author initially asked himself ( I've been there - there's no shame in that ). But it's out there now.

Given its 4 kyu ranking, I think requiring such extreme performance is overdoing it just a little - that seems to come with 3 kyu and "implement advanced requirements in a scalable fashion". For 4, required performance could be on the correct order of magnitude, but not necessarily the correct absolute magnitude. But I'm reading quite a lot into the ranking explanations here, I'm aware of that.

@JohanWiltink IDK what the intent is, but what is the solution that you think should pass? JS tests are the same as in Rust; my optimized solution in JS is about 25% slower than in Rust (approx. 5500 ms vs 4500 ms), but I just translated an existing solution, so I'm not sure what intermediate stages could be when solving it in JS.

I think the JS tests may be just a little over the top ( and I really mean just a little ).

My first attempt was 2 times too slow. Not any order of magnitude, though it was O(mn) and not O(n), but the tests seem limited to m = 4 so that's practically a constant.

If that's the intent of the kata, fine. But if the intent of the kata is just to require O(mn) performance, consider scaling back the tests just the above-mentioned little. Also, if not just O(mn) is required but actually O(n), consider scaling up the tests with some longer ms.

This comment is probably directed as much at the original author as at the translator; author guidance may apply to other languages as well.