I'm very confused. How can you solve

 _ 
|_ 
|_|
   
  |
  |

As c1? If you switch c1 wouldn't it be invalid in both cases? Are you changing it on both or one number? I see how c1 is the only commonality between both, but is that the reason? I don't understand.

Also, in this case, how can you know for sure the last number will be 4 and not 9?

     _   _ 
  |  _|  _|
  | |_   _|
     _   _ 
|_| |_  |_ 
  |  _| |_|
 _   _     
  | |_| |_|
  | |_|  _|

I don't think this is a spoiler because it doesn't help solve the kata.

In case anyone else needs the interpreter code for local testing:

from collections import namedtuple as _namedtuple
from random import randrange as _randrange
import re as _re

Result = _namedtuple('Result', ('steps', 'out_of_mem', 'pointer', 'value', 'cells'))

class InvalidBfError(ValueError):
    pass

def interpreter(code, values=4096, num_cells=8, timeout=30000):
    def parse_loops(code):
        marks = {}
        start = []
        for i, c in enumerate(code):
            if c == '[':
                start.append(i+1)
            elif c == ']':
                try: s = start.pop()
                except IndexError: raise InvalidBfError("unbalanced ']'")
                marks[s] = i+1
                marks[i+1] = s
        if start: raise InvalidBfError("unbalanced '['")
        return marks
    
    code = _re.findall(r'<|>|\[|\]|\++|-+|[,.]', code)
    loops = parse_loops(code)
    cells = [0] * num_cells
    start = _randrange(values)
    cells[0] = start
    p = i = t = 0
    while i < len(code) and t <= timeout:
        c = code[i]
        c, l = c[0], len(c)
        i += 1
        t += 1
        match c:
            case '+':
                cells[p] = (cells[p] + l) % values
            case '-':
                cells[p] = (cells[p] - l) % values
            case '>':
                p += 1
                if p >= num_cells: break
            case '<':
                p -= 1
                if p < 0: break
            case '[':
                if cells[p] == 0: i = loops[i]
            case ']':
                if cells[p] != 0: i = loops[i]
            case ','|'.':
                raise InvalidBfError(f'I/O command not supported: {c!r}')
    incr = (cells[0] - start) % values
    return Result(t if t <= timeout else -1, p<0, p, incr, cells[1:])

I am slightly confused, how come 41 equals 1111? Shouldn't it be 41 -> 1111 -> 11 -> 1 or am I missing something?

I'm sorry, but the second and third examples don't make much sense.
|
|
and
_
|_
|_|

are both valid and clear numbers that both utilize the 'c' segment in their display, yet the 'c' segment is declared dead.
The same goes for:
_
_|
_|

(blank)

_
|
|

These are all valid and clear displays that don't utilize the 'f' segment yet the 'f' is declared dead.
In neither of these examples is the dead segment evident. Might I suggest that you either use different numbers or displays that clearly show a segment as dead or write the numbers that are supposed to be displayed to highlight what the actual issue is.
(If there is something obvious that I am missing, please point it out.)

IMHO surely a PB in this kata, if both ..... <= 1e-3; and .... < 0.001 passes in valid solutions !!!

It is entirely unclear when should a boundary be |/- instead of +. e.g:

+--------+
|        |
| +---++ |
|     || |
+---+ || +--+
|     ||    |
+-----++----+

I'm even seeing these in the random tests:

       +-+-++-+
       | + ++ +-+
       |        |
      ++        ++
      |       ++ |
      |       ++++
      ++        |
     +-+       ++
   +-+          ++
 +-+             |
++               |

Why is the left side

 ++
+-+

instead of

 ++
+++

when the right side has

++ |
++++
  |

instead of

++ |
+-++
  |

?

106 ... my head is breaking. Third evening I try to get find another version.
72 or 56 ... thats amazing. I hope it's possible without bytecode conversion ...

I solved other 6kyu Katas much faster. How about rating this one higher i.e. 5?

Input

• word [string] - A non-empty string

Why non-empty? Empty inputs would be perfectly valid, reasonable and legal, have a defined expected value, and do not require any special-casing if your solution is correct.

Focussing on big inputs need not mean neglecting the base case.

errr...but in that case... I'm honestly tempted to open this as an issue: how the user is supposed to debug his code since the two kind of borders aren't differentiable by sight. Meaning your kata feels undebugable as it is right now.
The raw message won't change a thing... :/

=> ?

oh, btw. A common problem to your examples (common to the 3 versions) is that you show the inputs as points, but you don't give the equivalent picture to the user. That would be a very good addition to your 3 kata.

cheers

Hi,

:) I guess you expected me about the description? x)

I didn't read it completely so far but 2 notes about it:

• the image in the beginning is useless if you don't explain what is exactly in there. Especially since you have colours. For this one, I'm not sure the use of colours is a good idea since the output is a simple string
• second image of "border drawing" section: it seems to me you forgot a third line in this one (using the image at the very top)

...Errrr... I'm surely missing something, but considering you want the user to return a single input with all the drawings, I actually don't see the reason for all those rules (but surely I'd realize it once coding.... But that's not for today ;o )

I forgot one part...

It took me an unreasonnable amount of time to figure out that the points of one shape are covering the whole inner area, and aren't just the points on the borders... (yeah, it's written, but you lost me at some point).

That would be clearer by adding another example at the beginning, with a 3x3 shape, and giving the sets of points for each shape and putting a specific note about the point "in the middle" for the 3x3 shape.

Clojure Translation ready for review.

consider changing the kata to pass in a variable epsilon as a parameter instead of a having it be a constant