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.
Pretty challenging to figure out, it takes a while.
Why did you mark it as a issue? It should be suggestion not issue
replaced with
basic
(not sure what base would mean here: a lame base sorting method...)Fixed now.
Did I forget the sample tests?
Sample tests should use
strictEqual
.This might increase difficulty to the point where the current average voted rank is no longer accurate.
10 000
is not enough. My original JS solution now fails, but if I rewrite it in fat arrow notation it intermittently still passes. The description says it shouldn't.Optimising or memoising makes it pass within a second, so there's margin to bump the tests to maybe
20 000
or so; that should be enough to time out naive solutions.I've implemented @JohanWiltink's updated version for this one and I've increased the bound to 10000 to make up for the optimized test cases.
As for Haskell, I know little about the language, but it seems that the difficulty level without any changes to the test suite is roughly similar to the updated JS version. But it might be worthwhile to just check once more to ensure consistency.
I have implemented the update and have also increased the maximum bound for JS to 10000 (the lower bound is still 1000). This does increase the difficulty of the kata very slightly for JS, failing some less optimized solutions.
On another note, I've left the Haskell tests as is (still 1000 to 7500) since increasing the bound does fail the sample solution; what will the necessary optimizations be in order to ensure that the tests are consistent across the two languages, or will it be better to keep the Haskell version as is?
If you document what you change about the JS tests, I can change that for Haskell; I'm still here ( though note I won't get notifications for this thread ). But Haskell tests are already much more optimised than the ( pre-above-update ) JS tests ( and do not crash on
null
like JS ).JS Update
describe
, not anit
.check
was actually anti-optimisedanticheat
would crash onnull
assert.equal
would not dinstinguish betweennull
andundefined
This update messes with performance requirements, because the test suite itself takes less time ( by quite a bit ). But I think it's worth it. You may want to boost the
7 500
a bit. Even without the unspeakable optimisation, memoisation will make solutions breeze through numbers up to35 000
( numbers between35 000
and40 000
may result in stack overflows though! ).10 000
should be doable with just the ordering optimisation. Or you can just do some testing with the top-voted solution I guess.some languages do, some dont. re-raising here with a list of affected languages
Those are just some names I gave in the description to describe the requirement in words; they are not code fragments so language conventions don't apply.
I'm pretty sure this is not a good thing to do. This will make the description not lang-agnostic. This can cause a very messy description markdown just for handling formatting for different langs. Messy description is hard to maintain.
Loading more items...