Practicing some Haskell. 3% of my time on this problem was spent working out the calculation, and 97% of it was spent figuring out how to round a double (!) to two decimal places.

Fantastic

This is so elegant!

That should be made explicit in the description, then. All of the example test cases use a space separator.

I'm not familiar with the way CodeWars works; the issues I reported weren't meant to be rude or aggressive. Nevertheless, they are real issues, and should (I think) be cleaned up before the kata is published out of Beta.

I had a working solution for the example test cases (which, contrary to what you claim, do not include uppercase input chars), but failed on two private test cases I couldn't reverse engineer. I read through the (frankly, poorly written and inconsistent) ruleset and wasn't able to figure out why the program was failing. I'm a professional software developer, and have a degree in philosophy. I'm used to working through difficult texts to understand them. In this case, your text is difficult not because it is complicated, but because it is misleading and inconsistent. If someone wrote a program spec using this kind of language, it'd be roundly rejected in the design phase.

A concrete example: "If 'b' contains the char in lower case, you have to switch it to upper case (do it for all the same chars found in 'b')." What does 'it' refer to in this case? A char in 'a'? It's ambiguous.

Another example: "For each char in 'a' you have to switch the same char inside 'b' to upper case, if it exists in 'b' (clear) and if it is in lower case." But this sentence is partly negated later in the ruleset, which says that the casing of characters must be switched from upper case to lower case based on the number of occurrences in the transforming string. This introduces ambiguity. The first sentence should be rewritten so that there's no partial negation.

That's just two examples. There are many, many more. For one, you mention that "A char of 'a' is in 'b' regardless if it's in upper or lower case.", but you never say that this property goes both ways (that a char of 'b' is in 'a' regardless of case). The reader can only assume.

Your response here, that the text is fine and implying that I'm just too stupid to understand it, is very disappointing. If you aren't willing to clean up your text, hopefully someone else will before this kata gets published (if it ever does).

The ruleset is difficult to understand. Specifically, the handling of uppercase input chars is unclear, and none of the public test cases involve uppercase input chars.