Beautiful kata, thanks!

The trivial solution that's spoilered in the example tests will fail on the real tests:

  prop "returns the correct result for small numbers" $ 
    \(Positive (Small x)) (Positive (Small y)) (Positive (Small a)) (Positive (Small b)) ->
      (x, y) `comparePowers` (a, b) `shouldBe` (fromIntegral x ^ y) `compare` (fromIntegral a ^ b :: Integer)
 -- trivial comparison, actually computes both ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You can approve the translation without any problems ^^".

As someone fairly new, I'm not sure this is appropriate as a '7th kyu' kata. I managed the first step of writing code to pass the initial tests but couldn't figure out or even understand how to compare the massive exponents. Maybe this should be reclassified?

The trick is solving it in another way, so that it won't either time out or come up to Infinity vs Infinity.

The random tests for Javascript are so large that they return as Infinity so even if one number is larger than the other, Infinity compared to Infinity will always return as equal. Example: [ 3704, 8110 ], [ 8893, 5636 ]

I don't get it: what fails with large numbers? I assume the translation is ok, so what I need to know before approving it?

All fixed, sorry for the inconvenience!

Fixed, try now!

Fixed, thanks for your feed and see if anything else happens again :)

Try now, it should be fixed :)

Fixed, thanks!

The test case for [1,7], [1,8] in the Javascript kata is wrong. It is expecting 1 when it should expect 0.

Ahh ok, I thought it might be, but I was unsure which numbers were being tested, I guess i'll come back to it, ta!

I believe this is actually an issue with the test cases themselves, as some people have pointed out already.
The test case in question uses the parameters [1, 7] and [1, 8], which should return 0 but the test case wrongly expects 1.

See below. This has been reported twice already ^^".