Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
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
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.
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 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.
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.
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 inC
, also, as mentioned, ifO(n)
performance is desired instead ofO(mn)
, test with bigger values ofm
but smaller values ofn
. 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 with3
kyu and "implement advanced requirements in a scalable fashion". For4
, 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 notO(n)
, but the tests seem limited tom = 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 justO(mn)
is required but actuallyO(n)
, consider scaling up the tests with some longerm
s.This comment is probably directed as much at the original author as at the translator; author guidance may apply to other languages as well.
Loading more items...