Here is a near-ideal, overly complex, ECMA6 solution to #217. This solution is less than ideal in 3 ways:
- There are 2 instances when the input is looped over entirely due to the separation of parsing logic and the logic that builds the initial index. This could be fixed, but shouldn't really since the concerns are wholly separate. Theoretically this also allows for pluggable inputs (who knows, maybe in one you don't need to loop to parse the input). I don't consider the parsing in the complexity for my solution.
- My solution does not follow l->r t->b insertion order, except at the very beginning. To fix this there could be a binary search for an insertion position within the index the node is moving to, creating some sort of meta order to the index contents. (I may fix this if I get bored). This is potentially weird because once pile size parity is reached the increase pattern is always going to be the same, so some weird optimizations become possible (esp. since we know the insertion number in advance).
- It's so long, ~120 lines. OO programming is annoying. Jeez. (And no browser can even run it without transpiling.)
Also I could probably refactor it to just use one array (or even just the indexes). But really that stuff is only used in the toString
logic, and there is very little reason to do it. (And it is nice to be able to simply .join
to build the string)