PATH and 10 Print Interpretation

From Maze

(Difference between revisions)
Jump to: navigation, search
(added illustration)
(Michael reimplemented 10 print in PATH)
Line 4:Line 4:
Exploring these approaches touches on many topics -- the definition of a maze, reimplementation, quines, visual interpretation, general computation.
Exploring these approaches touches on many topics -- the definition of a maze, reimplementation, quines, visual interpretation, general computation.
−
 
−
 
−
== Notes from the listserv ==
 
−
 
−
<blockquote>Jeremy: [W]hile the output of Nick's one-liner *visually* specifies a kind of open maze, it was not immediately intuitive to me that the information contained in the character array contains a maze. I initially imagined that data to specify a maze should requiring empty hall and full wall (low bit/high bit) which is a very different thing from this wall of slashes that might as well be ps and qs. Such an encoding strategy can't be generated with any coherency by a random function -- if you use *s and spaces with such a simple algorith, you just get static. When I thought about it, however, I realized that the twisting passages visually implied by the slashes only require a very few rules to be specified / made executable. These rules are already implemented in the esoteric language Path -- just add a $ start-point to a random location in the output, and the Path programming language will happily execute a path that navigates through the structure of / and \ characters much as we would visually or physically, ending either trapped in a loop or falling off the edge of the space. '''This moment where the output of one programming language becomes (even unintentionally) a new program in another language is also something I'd love to explore in the book.'''</blockquote>
 
Line 44:Line 39:
> If current memory is not 0, turn right.
> If current memory is not 0, turn right.
v If current memory is not 0, turn down.
v If current memory is not 0, turn down.
 +
 +
 +
== 10 Print output as PATH ==
 +
 +
<blockquote>'''Jeremy:'''
 +
[W]hile the output of Nick's one-liner *visually* specifies a kind of open maze, it was not immediately intuitive to me that the information contained in the character array contains a maze. I initially imagined that data to specify a maze should requiring empty hall and full wall (low bit/high bit) which is a very different thing from this wall of slashes that might as well be ps and qs. Such an encoding strategy can't be generated with any coherency by a random function -- if you use *s and spaces with such a simple algorith, you just get static. When I thought about it, however, I realized that the twisting passages visually implied by the slashes only require a very few rules to be specified / made executable. These rules are already implemented in the esoteric language Path -- just add a $ start-point to a random location in the output, and the Path programming language will happily execute a path that navigates through the structure of / and \ characters much as we would visually or physically, ending either trapped in a loop or falling off the edge of the space. '''This moment where the output of one programming language becomes (even unintentionally) a new program in another language is also something I'd love to explore in the book.'''</blockquote>
 +
 +
 +
== 10 Print reimplemented in PATH ==
 +
 +
<blockquote>'''Michael:'''
 +
...I have perversely implemented 10 print in path. I've attached the path source in both uncommented and commented form. There's no cool ascii art double coding in my program - it's unvarnished path code. The file maze.txt contains generated output. Some observations:
 +
 +
1) In the same way that Ian argued 10 print is more native in basic than in assembly, I think I've conclusively shown it is also not a native path program.
 +
 +
2) My path program generates labyrinths by endlessly walking a labyrinth (perhaps countering the first point).
 +
 +
3) Looking at 10 print in 6502 assembly still masks the complexity of 10 print, particularly the random number generator - compare the 5 instruction 6502 implementation of the 8 bit LFSR with the path implementation. Working in a turing minimalist language with unary arithmetic highlights the tower of abstraction on top of which a von Neumann architecture sits.
 +
 +
4) Staring at the LFSR code in path (and even assembly) fills me with wonder as to how that chunk of code successfully stands in for "making an aesthetic decision."
 +
</blockquote>

Revision as of 12:36, 29 June 2010

View this revision of PATH and 10 Print Interpretation.

Personal tools