The fixed one has a call to round on line 87 of the test cases, but for some reason the one I see when I click Show Test Cases is still the old non-fixed one. Do you know if you could check to see if you know how to get the fixed one used? Otherwise, I could try resubmitting it.

I wasn't sure if I should require a lazy solution like the haskell one so I did

If you don't think this is a good idea, I can remove the requirement

I think the description of the sorting should explicitly say that the sorting happens on the entire string with the 1/2/E/= prefix, not just the repeated letters. The current wording doesn't specify this and can easily be interpreted as just applying to the repeated letters.

Looks good, though personally I would have preferred leaving the argument labels in (since it's very hard to tell what's what in areaOfPolygonInsideCircle(3, 3), but it's obvious in areaOfPolygonInsideCircle(radius: 3, sides: 3)), but changing that now would break existing solutions so oh well.

Swift infers the types of literals based on what you're using them in. This means that you don't need 2.0 (just use 2), and you don't need Double(1000) (just use 1000).

Alright, I forked my old test case with a new one. I don't know how to actually switch to it, though. The issue was a double rounding issue, since doubles are great.

This one includes a large numbers test in the example tests so users aren't confused if running their function on Int.max crashes the program.

The biggest number given in the swift test is Int.max, so if your solution happens to attempt to make a number higher than the input using normal Swift math operations, it will crash with an integer overflow error. It would be nice if the Swift test system printed the error that caused the crash, like it does in Xcode, but it doesn't.

By the way, the current random test only tests resistors from 10 ohms to 99M ohms (no 100-990M ohm resistors), since it seems most resistor color code sites don't seem to consider the >99M ohm resistors to be a thing. Do you think I should leave it this way or change it to include 100-990M resistors?

You're welcome

It would be hard to change it now, but I think you should have allowed jumping over blank spaces vertically (as long as they weren't on an edge, of course). It would have made sense, and also made the challenge slightly harder.

This website is in English only at the moment (I don't see any buttons to change the language, at least), so it makes sense that a kata would be English focused if it isn't specifically targeting some other language.

Also, English's silly ordinal number system makes the kata more challenging. Returning century + "世紀" is considerably easier than what you currently have to do.

Your random tests use the user's encode function to make the encoded versions of the random strings. This has a number of issues:

• All of your encoding test cases compare the user's encode function output to itself, making them always succeed (and completely useless), and giving users the illusion that their encoder code works, even if it doesn't.
• All of your decoding test cases use the output of the user's encoder as their input. If the encoder doesn't work properly (even though the encoder test cases succeed due to the previous issue), the decoder will be given bad strings as its input and will make people think your test cases are broken (which you can see examples of in the comments).
• Your random tests, which are supposed to stop hardcoding, can now be easily bypassed. My latest solution highlights this.

An easy solution to this is to include your own encoder in the test cases and use that to generate the answer key instead of the user's encoder.

I did.

Just wondering, what's preventing Objective-C from being executable?