• Okay, I really hate you guys.

  • .

  • Thank you for this. Sometimes (apparently) crack just doesn't cut it as a breakfast food for me...;-)

  • Take a look at the test example and its diagram. There are a total of 6 columns and 8 rows. Each column represents the space between the vertical rails. This means there are a total of 7 rails and 7 elements (the numbers 0 through 6 at the top, one for each rail) whose positions start in ascending order.

    The first row is 001001, which means there will be two horizontal crossbeams at this row; one between the vertical rails 2 and 3 and another between vertical rails 5 and 6. This means that the elements positioned at these connected vertical rails will swap vertical rails and proceed to move down.

    Each time there is a horizontal crossbeam, the elements going down the connected vertical rails will swap rails. In the diagram, the grey markers on the left indicate the position of each row.

    If this doesn't clarify, then perhaps the linked Wikipedia article in the Description may help.

  • This comment is hidden because it contains spoiler information about the solution

  • Hate to say it, and it looks damn interesting, but I don't get it. I've read and re-read the instructions.

  • Thanks for the answer, I found the problem. And sorry for marking it as issue.

  • Take a look at the examples anyway. And types.

  • 0xFFFF - input (input types specified by function signature).
    "FFFF" - output (4 bytes);
    0x7F - input (input types specified by function signature).
    "7F" - output (2 bytes);

    Read in the table statements like "HEX ASCII".
    And pay attention to quotes sign
    e.g: "0000"..."FFFF"
    Or statement like "HEX"
    And 0..FF, no quotes sign, therefore it's 1 byte number.

  • This comment is hidden because it contains spoiler information about the solution

  • The state should always be 2 bytes. Yes, if value consist of a single digit it should be padded with zero. "00"..."7F" therefore even if passed state is zero, you should write "00" to packet.
    In the examples in the second test case it is padded, it's just hard to see.

    "\x02""FFFF 7F FFFFFFFFFFFF 999999 FFFF\x03\xD7"

    "\x02""0000 00 000000000000 000000 00FF\x03\x24"

  • So I got my stuff working, except that 'state' in the packet is 2 bytes long, and the 'state' passed into the function is only 1 byte long. Thus, I placed the state into the packet, and padded the higher byte with a zero (0). Is this not the correct method? But in the example packet, no zero is padded, and the packet has only a 1 byte state.

  • Well, then try it out on your own computer.
    You can use strings from basic tests to compare your output, CRC value visible there.

  • Testing code doesnt modify data located at the 'packet' pointer.
    But still you output should have correct length, like in the specification.
    Most likely "cutting down" is result of two cases either too long output or incorrect overlaying pointers.

    No terminating zero character is needed.
    Count bytes and correct pointers.

    The "Issue" category is assigned for issues regarding Kata implementation(e.g. solution testing code, description).
    If you have issues with solving you should post in regular discourse category.

  • Loading more items...