Haskell fork with the following changes:

• Minor tweaks to the test suites
  • Qualified imports from solution module to avoid inadvertent name clashing
  • Replaced choose with chooseInt
  • Improved the generation of random lists of powers
  • Removed unused code from sample tests
• Updated sample tests to use proper ranges, resolving this issue
  • The full tests already used the proper ranges
• Added test in full tests to weed out solutions that use a fixed result for field multiplication, resolving this issue

Test cases are unacceptable for a 3 kyu: this solution should not be able to pass

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.

Prolog translation

Okay, I'm very confused. I thought the idea was that we put a first string into the first (encoding) program, which then produced a second string and a number. And then, if we fed the second string and the number into the second (decoding) program, we would end up getting the first string back again. This would seem to be a self-testing pair of programs. If A produces B, but then B gives us C, it's not working correctly. So I run the first few tests, and all go well. Then I run the humongous set of tests, and I'm told that in between two and four cases, I'm getting the "wrong" result out of the encoding program. But if I feed what they provide into my encoding program and them put it back through to be decoded, it all seems to work. I haven't a clue as to how to begin to troubleshoot these few "wrong" answers that seem to be right, according to the results I get. I even tried my encoding/decoding programs with a string that was hundreds of characters long, and it still seemed to work. Ideas? Suggestions?

Rust translation.

Anyone know if applicative parsers are possible to do in Ocaml? (I know monadic ones can be done). I made an attempt at a translation, but Ocaml complains

Error: This kind of expression is not allowed as right-hand side of `let rec'

when I try to actually use the mutually recursive functions I wrote in my Haskell version (exprP, binP, etc). I'm not sure if I'm doing something wrong or if this is a limitation of the language, I would appreciate it if anyone can take a look at my translation.

Kotlin translation ready for review and approval.

I passed basic test but my solution is not valid with random tests. So guys would you like to share more longer test cases in order to see where I am miscoding somethings ?

Currently working my way through this (C#) and noticed a few things that irk me:

• Sample tests aren't unit tests; for example Foldr requires both Repeat and Take to be implemented. If I'm working my way from top to bottom, then I will not have implemented Take yet, and will receive a slightly confusing NotImplementedError for the Foldr test.
• Sample tests don't properly test the streams: I successfully passed all sample tests, then got an immediate Stack Overflow when I hit "attempt"; turns out a few of my methods were returning (headS, s) instead of (headS, tailS), i.e. recursively running on the same unmodified stream instead of on the tail of the input stream.
• The interface of LazyStream is not specified and only discoverable by chance by reading through the sample tests. Otherwise, I could never have known that LazyStream stores the Stream in its .Value property, and I wouldn't be able to implement anything.

I know that there are different ways to build the Huffman tree but I would like to know if it is possible to use the module "networkx" in python. Thanks :)

Very nice kata but small complaint:

(Haskell)

• Sample tests very often only check the second value of a stream. It would be a lot easier to identify mistakes if it checked at least two or three
• Error messages in main tests are very hard to understand. For example when checking PrimeS I got the error {getSmall = 2}} expected [2,2] but got [2,3].

The obvious definition of primeS would be with filterS and an isPrime predicate, while this sounds simple, it is not the most efficient solution (since it has to brute-force all numbers up to the given number). Figure out a way to reduce the amount of numbers to test in every step!

Apparently, filterS and isPrime is enough to pass the tests, so what is the point of this message?

Hint: Make sure to handle negative values

How?

Clojure Translation ready for review.