In theory, the complexity of this is worse than the optimal O(n). However... since this is JavaScript and it can only be correct to up to 15 digits... I guess it's practically acceptable.

Indeed, 33, 35, and 42 are struck-through, so they are not being taken into account.

ok, thanks for pointing that out

Use spoiler flag next time please.

If n was type of number, spread operator would not work with it (would throw error). Spread operators only work with arrays and string.

BTW, your solution was clever and simple

Dont you understand that it is your responsibility to write decent tests?

Ehm, honestly - on some points, it looks better.

But with the new testing, you have to pass all the tests, no more 5 wildcards. I am not dumb enough to keep hitting Submit until my solution passes that. I get somewhere between three and ten fails usually - it would be a matter of time. Note that there is only one solution left ( though with two different precisions. some people are apparently more willing to endlessly submit ).

Apart from that, rounding is not a good idea in general. Better to compare with a margin for error. Because when, say, expecting 5, 5.0000001 will round right, but 4.9999999 will fail. Both are equally good answers in my book. round, floor or ceiling doesn't matter; you just shift the expected value where things will break. Test has assertApproxEquals especially for this situation ( acceptable relative error is fixed at 1e-9 though, which may be too little here ). This has been endlessly raised and debated in existing kata; you may be able to find it in comments somewhere of a kata that deals with floating point values. I don't know if it made it into the Wiki docs yet.

But the anti-cheat is better and I appreciate the availability of pi. ( I put that back in Preloaded; it seemed to have fallen out. )

Don't worry too much about cheaters. If people do it on purpore, you have no moral obligation to cater to them ( by nixing reallyExit ). You don't do that by mistake - cheaters gonna cheat. But if you forbid Math, nix that, otherwise people will complain that you didn't. Slightly unrelated, modifying arguments is done by mistake. That's generally one I do catch ( and, if I'm in a good mood, fail solvers for, because it's a bad bad bad habit to get into ). That's not applicable to this kata, just nice to know.

I have too many cehats. Have fun invalidating me

LOL https://www.codewars.com/kata/reviews/5d7913aba4b23f0001b6f0d5/groups/5d7a3d3001af06000140942b

yep. it's entertaining cheating.

https://www.codewars.com/kata/reviews/5d7913aba4b23f0001b6f0d5/groups/5d7a3bd014c1b90001938aa6

my old solution (almost) comes to life: https://www.codewars.com/kata/reviews/5d7913aba4b23f0001b6f0d5/groups/5d7a3b4176056a000176b5bc

I think this will be about the last cheat to fix. I just tried to make another cheat but failed.
EDIT: your 'fix' to this cheat caused another easy cheat >_<
I tell you that banning things can be tricky

I've done describe and it headers for JS testing, so there can never be discussion what the input was.

"Any number of steps" includes zero.

You may be referring to these tests:

[12, 24, 22, 27, 29, 0, 4]
[2, 3, 4, 4, 6, 6, -8, -10, 0, 1]

They correctly expect false.

If you modify your inputs, you deserve everything you get. Note that array.sort() silently modifies its this - this is what is apparently happening, because there are no tests with the inputs you quote.

Test inputs are being reused, so if you modified an input in one test, a later test would expect a wrong answer. This vulnerability should now be fixed. ( You should still NOT be modifying inputs! It's a bad, bad, bad habit. Be ever weary of .sort. )