That's awesome, thanks!

This appears to only be an issue with the sample tests (the full tests have gen15 = choose (0, 15)). My recently published fork fixes this in the sample tests.

!-)

Seems to be the oldest thread here from ten years ago, but I don't see it resolved in the code.

Please correct me if I'm mistaken:

The maximum degree of our polynoms will be smaller than 16.

In the Haskell property test suite though there is gen15 = choose (0, 16) which generates polynoms x^16 as the range of choose is inclusive.

I like it :)

It's not a performance kata ( though qbsort is definitely a performance algorithm! ), so the solution is valid. But it should not be upvoted, at least not for Best Practice. :]

I agree. It feels strange to talk about n log n complexity in the context of BogoSort, but as we are assuming a quantum computation runtime environment, your criticism makes sense. :) Unfortunately I can't revert the solution.

Sorting the list in O(n log n) to check if it is sorted, which can be done in O(n), is not a Best Practice.

( People, please stop upvoting such solutions. )

Random Perl tests produce strings with less than two characters.

Thanks, Johan, I'll try!

I think ++ is killing you ( it's O(n²) if recursed into left-associatively ).

Could you express the result sequence entirely and directly in terms of itself only, like fibonacci = 0 : 1 : zipWith (+) fibonacci (tail fibonacci) ?

Very cool kata, thanks! My Haskell solution seems to work correctly, but times out with the big test set. Generating 10k entries takes 2-7 seconds on my machine, which is not very satisfying. Currently I have no idea what to improve. :/

You don't like it?

ok but why