20
2
The beloved fish who swims through the code of ><> (an esoteric programming language) has been taken out of its natural environment. This change has rendered it incapable of moving around in the way it's used to: what used to be toroidal movement has been restricted to simple left-to-right movement. But ><> programs are still written as if the fish were capable of moving through them. It is your task, dear programmer, to write a program to linearize a ><> program. And do it in as few bytes as possible; fish don't have very large memories.
Movement in ><>
In ><>, movement is toroidal and one character at a time. This means that the fish (the pointer) can "wrap" around from the end of a line back to the beginning. In ><>, the fish also is capable of moving top-to-bottom, bottom-to-top, and right-to-left, in contrast to the way most pointers move. So this movement pattern would be valid:
>>>^ >>>v
>>>^ v
and it would end on an infinite loop (looping back to the top line once it gets past the bottom infinitely).
The fish moves in a grid of length equal to max(row length) and height equal to the number of rows.
How do you figure out which way the fish moves? These commands change the direction vector of movement (e.g. (-1,0)
means right-to-left):
Command | Direction Change
---------------------------
> | (1,0) (default)
< | (-1,0)
^ | (0,1)
v | (0,-1)
/ | (x,y) -> (y,x)
\ | (x,y) -> (-y,-x)
| | (x,y) -> (-x,y)
_ | (x,y) -> (x,-y)
# | (x,y) -> (-x,-y)
; | (0,0)
As noted, the fish starts moving left-to-right, i.e. with direction vector (1,0)
. The fish starts parsing commands starting with the first command it sees and changes its direction if a command matches one of the aforementioned direction changers.
The fish stops moving when it sees a ;
and terminates the program.
Input
Input will be a valid (e.g. not infinitely looping) program given through STDIN. You may also read a file if you wish. The lines of each program will not necessarily be of the same length.
Input is given as a string, with newlines separating each line in the program.
Programs will not loop, which also means they will always terminate with a ;
.
Output
Output will be the program linearized. That is, you should return all of the characters (including direction changers) that the fish would see if it ran the program "normally." This is all of the characters in its path to the ;
.
If the input is has lines of unequal length and the fish ends up moving along a line shorter than the length of the longest line, you should treat that as if the fish were moving over a space (see test cases).
Those familiar with ><> will know that direction changers are not the only way to do movement in it, but for simplicity's sake treat the input as if they are the only way to affect movement.
Rules
- Standard loopholes apply
- You may write either a full program or function
- Input is supplied through STDIN or a file as a string containing the program lines separated by newlines (
\n
)- You may take the input differently, within reason (feel free to ask me if you have a specific kind of input in mind). You may not pad the input with spaces so the line lengths match.
- Refer to this meta post regarding flexible input. As it stands of posting, general consensus is to be as flexible as possible within reason.
- Output is a single string through STDOUT or returned by the function (depending on what you choose to do, see Rule 2)
Test Cases
v >v
>abcv//;
gfed<^ih
v>abcv<defghi^//>v;
v >v
>abcv//;
gfed<^
v>abcv<defg ^//>v;
abcdef;
abcdef;
abcd|;
abcd|dcba;
abcd#;
abcd#dcba;
abcd\;
_
abcd\_\dcba;
^;
>abcde/
^jihg<
^ >abcde/ <ghij^a;
;
;
2Can we take the input as an array of strings? – Luke – 2017-03-26T12:00:45.297
2Can we assume that the first character (the top left one) won't be a semicolon? – user41805 – 2017-03-26T13:04:18.363
1@KritixiLithos good question, I'm going to say you can't assume that. I'll add a test case. – cole – 2017-03-26T16:14:18.203
1@Luke you may take the input as an array of strings if it is either very hard or impossible to operate on the input format (string with lines separated by newlines). See the now-added Rule 3. – cole – 2017-03-26T16:36:11.960
Is a leading space acceptable? – HyperNeutrino – 2017-03-28T13:08:59.167
@HyperNeutrino In the output or input? Actually, I think I'm gonna say no to both. – cole – 2017-03-28T15:06:52.583
Okay, alright. I originally wanted to have a leading space in the output, but that is stretching the rules quite a bit. – HyperNeutrino – 2017-03-28T16:56:08.160
Can we assume the input will not have null bytes in it? – MildlyMilquetoast – 2017-03-31T05:05:55.777
Will we have a case where momentum is down or up and we come across a
|
? What about left/right and we come across a_
? – Not that Charles – 2017-03-31T16:33:44.983@NotthatCharles The instructions explain what happens in those cases "| (x,y) -> (-x,y), _ (x,y) -> (x,-y)" – fəˈnɛtɪk – 2017-03-31T16:37:59.930
3
Obligatory upvote for absurd rationale
– Patrick Roberts – 2017-03-31T16:39:41.540@MistahFiggins I'll say you can assume that. I don't see why null bytes would be used in ><> (they would likely throw an error). For sake of tidying the comments section I'm deleting my previous comment. – cole – 2017-03-31T17:17:09.597
@fəˈnɛtɪk I wanted to make sure it was correct. – Not that Charles – 2017-03-31T20:51:36.033
@Cole It takes 13 chars (so 7%) to convert a newline-separated string to an array. Is that "very hard to operate on" the newline input? – Not that Charles – 2017-03-31T20:54:33.390
@NotthatCharles You may take input however you wish within reason, so long as you don't prepad with spaces. So yes, an array of strings (or 2D array of chars) is acceptable per the input spec. – cole – 2017-03-31T21:51:38.330
Ok, great, thanks. That changed before I posted my comment, but I had not refreshed the page.
– Not that Charles – 2017-04-03T19:00:01.487