Fixed

Fixed

Using test.expect in real tests is unacceptable as it provides no feedback besides "nou".

Testing for len(string) instead of string itself is also a bad practice. For anything that doesn't have a length the test assertion code will throw an error instead.

Starting from a 3x3 character canvas

This edge case is not tested.

Needs random tests.

Sample tests and initial code uses completely different encoding (and I'm not sure what the real tests use). So which one is expected?

you found that the code 'PLLUU' should generate:

   │ 
 ──┘

...Wut? AFAIK L and R means left and right if U and D means up and down. There isn't reason to flip the directions along only one axis besides to confuse people.

There was a bug and its cause is unclear.
I fixed it by rewriting the tests.

Same issue found. I think you are right. Invalid test case it is.

I'm stuck exactly at this test case... any pointer would be appreciated. To be honest, I don't really understand how the alogrithm works when x is a float. To me it would make sense to round x**n but this is not what the author wants. Pretty lost here.

stated it explicitly in description now

Hello, when trying to pass the Katakana tests, I have an error on the fourth or fith test.
However, the output of my code is ドモアリガトゴザイマス (which looks valid) and the expected string is ドモアリガトゴザイマ��� which seems invalid to me. Am I missing something?

Great kata, it took me a while to figure the best algorithm to do it. Thanks for this brain teaser :)
Couple of suggestions though: I think the sample tests are too easy to pass, so they don't give you enough feedback on the quality of your code. The sample tests should also take a longer time to compute using an optimize brute force algorithm, this way you can give a metric to people on how likely their function will pass the final test. Let me know if this makes any sense.

Great work, seriously!

I would definitively specify that the sum of the output should be the value.

I really like it otherwise, short but pleasant.