I added an assertion on expected length right before deep equality check. This takes away much of the performance issues on incorrect solutions, including [[1]].
It checks against a reference solution. These arrays can get huge. Deep equality checks can be slow, and the reference solution also takes time to execute. Why it takes so much time on an empty array, did surprise me too! It's a Chai implementation artifact though. Let me check if I can bypass deep equality checks if length of nested tuples does not match.
It only times out on slow solutions and the empty array. Correct solutions still pass fast. I'll improve test feedback to immediately fail on empty arrays.
Nice!
I added an assertion on
expected length
right beforedeep equality
check. This takes away much of the performance issues on incorrect solutions, including[[1]]
.It checks against a reference solution. These arrays can get huge. Deep equality checks can be slow, and the reference solution also takes time to execute. Why it takes so much time on an empty array, did surprise me too! It's a Chai implementation artifact though. Let me check if I can bypass deep equality checks if length of nested tuples does not match.
timeout issue fixed on empty array
It only times out on slow solutions and the empty array. Correct solutions still pass fast. I'll improve test feedback to immediately fail on empty arrays.
yes
I do think it's a bug
in JS in random tests first line sometimes lacks one last space so it is wrongly padded. Is it intended ?
Looks like a bug for me
Hi, thanks. Looks good to me. Submit it here (so that you get the credit) and I'll accept it
should no longer be possible
It is different for different languages.
encode
input up to10^6
for Haskell and10^7
for JS.decode
uses the same range asencode
.