Thankfully the tests don't test for "sample", which is good because the behavior of the function when text is in the array isn't specified anyways, so assuming they are truthy is the only sane way to go.

Because that doesn't do what the problem requires.

Weeeee

-0 is 0. Do you know what the word "bug" means? It means when actual behavior fails to match expected behavior, which is not the case here.

-0 is 0

Anything can be exploited, that's why we have multiple tests. Kata translations can have their own way of testing for solutions to work but if you haven't done at least what the original is testing for then you haven't translated a kata, you've just written your own and should had posted it as your own.

Your random tests in your test case only asserts that random indices match your expected indices, it doesn't check for segments to hold the fibonacci sequences property: c(n) + c(n+1) == c(n+2).

When writing real code, clarity is the most important rule in practice, beyond doing smart tricks. You do NOT need to use bitwise operations in non-bitwise-based logic. We only did it because we're used to code golfing.

I am not sure how to handle drastic changes like these. Do you think this is a necessary change to sustain the integrity of the kata?

Thank you! :)

your test cases only call the function once and do not seem to test if the function behaves properly with multiple instances, while also not having the same test cases as the original tests (skipping ahead to random indices and checking that random segments behave like fibonacci sequences). can you check if the test cases will test properly when multiple instances of the same stream is invoked?

what are you trying to say?

uh, clearly you know about how haskell works, which is good, but you've made weird assumptions about what JS does. Of course it depends between which engine we're on, but since nodejs powers most of the web (as well as is what codewars uses), new arrays are only allocated as needed if the engine decides it can't butterfly the previous array for the correct shallow references that don't get dirty (which is extremely easy to do when it receives the Boolean function, which is pure and doesn't pollute elements being passed through). What actually ends up happening is that most of javascript, unlike java, isn't executed on pure logic that is defined by its exact behaviour and has faster implementations compiled JIT (just in time) on the runtime so that it looks like new arrays need to be properly created where as in reality (happening behind the curtains) it's just the same heap being frankensteined into an efficient array-like item until the array prototype is used and forces the array to actually be constructed.