Misleading example in instructions for OCR Numbers

Exercism Building Exercism
, ,
1

This is the example in instructions:

      _  _     _  _  _  _  _  _  #
    | _| _||_||_ |_   ||_||_|| | # Decimal numbers.
    ||_  _|  | _||_|  ||_| _||_| #
                                 # The fourth line is always blank,

This is what a test in Zig track actually work with:

    const input = [_][]const u8{
        "    _  _     _  _  _  _  _  _ ", //
        "  | _| _||_||_ |_   ||_||_|| |", //
        "  ||_  _|  | _||_|  ||_| _||_|", //
        "                              ", //
    };

The way I read the example is # means end of string and the space before it is included in the string. The test does not include the space after the last digit.

Digit 1 in the example is 5 characters wide or it is preceded by 2 spaces. The test does not have these 2 extra spaces.

All these spaces make 3x4 grid shifted. But no test addresses it. Do I need to recognize the number if it is preceded with 2 spaces or do I need to signal an error? Unclear. Do I need to ignore trailing spaces or do I need to signal an error?

The tests require me to return an error if the input is not a valid size. But the example is of the valid size (input[0].len % 3 == 0) just by what seem to be an accident. If the input only had 2 extra spaces before the digits and no extra space after the digits, the size would be invalid.

Here is my attempt to show the 3 offending spaces:

"    | _| _||_||_ |_   ||_||_|| | "# Decimal numbers.
 ↑↑                              ↑
  "  | _| _||_||_ |_   ||_||_|| |", //

I would like to see the example match the test or the test match the example.

Another thing that is unclear is if the lines are allowed to be of different length. Should this test pass or fail?

test "different length" {
    var buffer: [16]u8 = undefined;
    const expected: []const u8 = "1,23";
    const input: []const []const u8 = &.{
        "   ",
        "  |", // one digit per line
        "  |",
        "   ",
        " _  _ ",
        " _| _|", // two digits per line
        "|_  _|",
        "      ",
    };
    try std.testing.expectEqualStrings(expected, try convert(&buffer, input));
}

I would like to see both instructions and tests pay attention to this edge case.

My current solution assumes these changes to Instructions:

Examples

The following input (without the comments) is converted to "1234567890".

    _  _     _  _  _  _  _  _ #
  | _| _||_||_ |_   ||_||_|| |# Decimal numbers.
  ||_  _|  | _||_|  ||_| _||_|#
                              # The fourth line is always blank,

The following input is converted to "1,23,456,7890".

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

The following input is converted to "??" because it is shifted by 2 spaces.

   _  
   _| 
  |_

I guess I should put this in the same category as Rewrite instructions for OCR Numbers - #18 by IsaacG

2

Indeed, the leading spaces in the example are misleading. As far as I know there is no requirement to accept different lengths of lines, so that’s not an issue to me.

As a long term programmer, a space separating a comment from the line end is “not a meaningful space” but “part of the comment”. To me, that’s how it has to be done. So I am not supporting glueing the comments directly to the line content. The rules are described correctly (line length divisible by 3), the example adds a comment for clarification and so cannot be “a 100% valid input”.

3

… is exactly why I had trouble understanding the instructions.

Flower Field exercise represents spaces in the example with '·' character. We can do it here, too:

····_··_·····_··_··_··_··_··_·
··|·_|·_||_||_·|_···||_||_||·|
··||_··_|··|·_||_|··||_|·_||_|
······························

Using # for comments do not make sense on Zig track. Zig only have // comments. The example should be language-agnostic, if I understand correctly. I do not think we even need the comment inside the example as multi-line example do not have any:

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

The fourth line is always blank,

Let us at the very least remove the two spaces at the beginning of every line then:

    _  _     _  _  _  _  _  _  #
  | _| _||_||_ |_   ||_||_|| | # Decimal numbers.
  ||_  _|  | _||_|  ||_| _||_| #
                               # The fourth line is always blank,