Complex numbers are a superset of the real numbers, and the final tests use doubles as arguments to the constructor. I'd be interested to know why your initial attempt used ints, which might indicate the underlying issue with the description.

Approved!

Looks ok to me, but shouldn't the initial setup class declaration include the colon?

Approved!

Updated the description with code samples.

I've brought the sample tests over to the full suite. The property function is used to define parametrized tests that the framework can call with random values and reduce to a minimal case when it finds a failure, if that can help understanding them.

I've also taken the approach of requiring that Fraction be registered as a numeric type (instance Num Fraction where ...) as that is the only way of overloading the (+) operator in haskell. An alternative would be to require some add function instead, which would have the simplicity of not leaving a bunch of functions undefined but wouldn't allow arithmetic expressions.

Fixed once more. Seems obvious in retrospect that the check need to compare the absolute values. Hopefully I won't have to deal with floating point arithmetic precision issues anytime soon.

I've created a haskell translation.

I managed to put together less stringent equality tests, but I'm not exactly sure where to set the threshold. Would you care to try it out again and see how it goes?

Good catch, I've published a fix for it.

Didn't know that, and it's been bugging me for a while now haha. I'll keep that in mind in the future :)

Good catch, must have missed those while I was copy-pasting test cases. Fixed now.

I initially thought about it, but decided against it since I wanted to leave the kata as simple as possible (I have another complex number kata brewing that'll much more thorough).

Making Complex generic is very interesting, but it's not as flexible as one might think. The Num typeclass expects the law abs x * signum x == x, which for any reasonable implementation of complex numbers means that abs x is the magnitude of x and signum x is a unit complex number with the same phase as x.

This effectively strongly limits which types lead to valid Num instances for Complex a: instead of Num a => Num (Complex a) you'd have something similar to Floating a => Num (Complex a). That's still doable, but not that interesting as it limits you to Complex Float and Complex Double.

Added a Haskell translation.