as a haskell noob I wonder, how is this possible?

You need to achieve O(log(n))

I have the same problem in Racket.
I can't even see in what test it is failing, it only returns "timedout" without further explanation.

nooooo I thought that memoization was going to be enough..... I guess I have to come up with something sneaky instead

For "expected null but was 163" the input was not the one you give. It is a "Sample Tests:" so you can read it.

Hard time figuring out why this should return null and not 163?

t: 163
k: 3
ls: [50, 55, 56, 57, 58]

"expected null but was 163"

50 + 56 + 57 = 163 so why is it expecting null as the answer?

neither lmao

.

.

['2', 101].sort() resulted in ['2', 101] here

You sure about that? Doesn't sound right to me, and this doesn't support your claim:

function orderWeight(strng) {
    console.log(['2', 101].sort())
}

Log
[ 101, '2' ]

from mdn (which I linked to above):

If compareFunction is not supplied, all non-undefined array elements are sorted by converting them to strings and comparing strings in UTF-16 code units order.

which means 101 should come first, and it seems to do so here. it would be surprising if it didn't. and it is insane (actually it's not so crazy for mixed types, but you'd get the same result for [2, 101]).

My guess is that you are sorting twice and that the non-stable sort is what gets you?

You might be relying on Array.prototype.sort to be stable but that isn't necessarily true for slightly older versions.

but when I run the same program on repl.it or locally everything works

that's only meaningful if you're running the exact same tests. people keep saying something to that effect and it turns out they did something else and that the difference wasn't from the change of environment

not sure what exactly you're asking. make sure that whatever you're relying on is defined behaviour I guess? and javascript is really really uh.. special, when it comes to comparing things

> [7, 8, 9, 10].sort()
[ 10, 7, 8, 9 ]

such a great language :')