fixed

it turns out that the reference solution in C++ was incorrect when the input was odd only or even only. This did not get caught because there were no fixed tests for it and the random tests have a low chance of generating such input. Fixed the refsol + added fixed tests there.

i still get tied cases i.e. [3,3] etc

140-6; 9-21; 64(56)-66; 146-1; 2-48; 37-14

[140, 21, 66, 146, 48, 37]

Fuzzy comparison done for Ruby in this fork, Python and JS still missing it.

Fixed.

description updated. we apologise for the delay.

Added in this fork

fixed

.

Thank you for a suggestion. I have updated it.

OP solved it, closing

It was certainly my intention that the pile should only be burned when it is full. (This reflects the fact that in reality, I do not interrupt my raking to burn a partial pile.) I will amend the description to reflect this fact.

I made some changes to the description. Is it more clear now?

So many users have solved this kata and noone has the courtesy of pointing out how the specification should be interpreted .. this so called mid-endian format follows a zig-zag path:

• start with a source in big endian order, and a target as empty string
• prepend a null byte to the source if the parity is odd
• as long there are bytes left in source, pop (shift) the next byte from the left of the source:
  • toggle between append / prepend that byte as hex in target