{"id":203,"date":"2006-11-03T15:22:06","date_gmt":"2006-11-03T15:22:06","guid":{"rendered":"http:\/\/scientopia.org\/blogs\/goodmath\/2006\/11\/03\/programming-in-color-fixed\/"},"modified":"2006-11-03T15:22:06","modified_gmt":"2006-11-03T15:22:06","slug":"programming-in-color-fixed","status":"publish","type":"post","link":"http:\/\/www.goodmath.org\/blog\/2006\/11\/03\/programming-in-color-fixed\/","title":{"rendered":"Programming in Color (fixed)"},"content":{"rendered":"

Todays programming pathology is programs as art.
\nStart with a really simple stack based language, add in a crazy way of encoding instructions using color, and you end up with a masterpiece of beautiful insanity. It’s not too exciting from a purely computational point of view, but the programs are really great to look at. Yes, it’s a pathological language with truly beautiful source code!
\n*(The original version of this post had some trouble because I linked to the original images in-place,
\nwhich the owner of the Piet webpage had blocked. I didn’t realize he didn’t want links. I’ve since downloaded
\nthe images, coverted them to jpegs, and posted them here. I initially thought that the problem with the images was formats, which is what I originally said in this explanation. It’s not the image format, but the linking; but converting the files to jpeg and uploading them removed the links that caused the problem.)*<\/p>\n


\nHere’s the complete list of
\ninstructions (without control flow):
\n1. **Push**: Push a value onto the stack.
\n2. **Pop**: discard the top value from the stack.
\n3. **Add**: Take the top two values off of the stack, add them, and push the result.
\n4. **Subtract**: like add, but subtract the values.
\n5. **Multiply**: like add, but multiply.
\n6. **Divide**: like add, but divide.
\n7. **Mod**: like add, by modulo.
\n8. **Not**: pop the top value off the stack; if it’s 0, push 1, otherwise push 0.
\n9. **Greater**: pop the top two values off the stack, push 1 if the second value on the
\nstack is greater than the top, otherwise, push 0.
\n10. **Roll**: pop the top two values of the stack. Call the top one “count”, and the second
\none “depth”. Now, take the top “depth” set of values on the stack, and rotate them by taking
\nthe value on top, and putting it on the bottom. Do the rotation count times.
\n11. **In**: read a value from input and push it on the stack.
\n12. **Out**: pop a value from the stack and print it.
\nSo far, seems pretty trivial, right? Standard stack based language, nothing unusual.
\nOk. So, now let’s start getting weird. We’re looking at a two dimensional language, so the control flow operators are all based on *direction*. There are two things that control the flow of the program: the direction of motion, and the direction of selection. The direction of motion describes where the pointer goes on a step; the direction of selection determines where it looks if it needs more information than it has under the instruction pointer. So the control flow operations are:
\n1. **Switch**: pop the top stack value *n*, and switch the selection direction *n* times.
\n2. **Rotate**: pop the top stack value *n*, and rotate the motion direction 90 degrees clockwise
\n*n* times.
\nOk, getting a bit weird now… But still, overall, pretty mundane. This isn’t a particularly
\ninteresting model of computation, nothing exciting about it. Certainly nothing do beat, say,
\nSnusp for the beauty of 2d programming.
\nNow… Here’s where it gets *really* interesting. How are instructions encoded? By *color*. The program source is a PNG image!
\nYes, todays language is called “[Piet][piet]”, in honor of Piet Mondrian, a modern abstract artist, because programs are intended to look as much like a painting by Mondrian as possible. There are twenty colors in Piet that have semantic significance, given in the table below:<\/p>\n\n\n\n\n\n
#FFC0C0
light red<\/td>\n		#FFFFC0
light yellow<\/td>\n		#C0FFC0
light green<\/td>\n		#C0FFFF
light cyan<\/td>\n		#C0C0FF
light blue<\/td>\n		#FFC0FF
light magenta<\/td>\n<\/tr>\n
#FF0000
red<\/td>\n		#FFFF00
yellow<\/td>\n		#00FF00
green<\/td>\n		#00FFFF
cyan<\/td>\n		#0000FF
blue<\/td>\n		#FF00FF
magenta<\/td>\n<\/tr>\n
#C00000
dark red<\/td>\n		#C0C000
dark yellow<\/td>\n		#00C000
dark green<\/td>\n		#00C0C0
dark cyan<\/td>\n		#0000C0
dark blue<\/td>\n		#C000C0
dark magenta<\/td>\n<\/tr>\n
#FFFFFF white<\/td>\n#000000 black<\/font><\/td>\n<\/tr>\n<\/table>\n

Most commands are given by the color transition between the pixel under the instruction pointer, and the pixel next to it in the selection direction. You’ll definitely need to keep that table handy to see how the instructions work.
\nSo, let’s look at how we encode instructions. We take the current pixel, and the pixel next to it in the selection direction, and consider their *difference* in the two dimensions given in the color table: hue, and darkness:
\n* **Add**: +1 hue; no change in lightness.
\n* **Divide**: +2 hue; no change in lightness.
\n* **Greater**: +3 hue; no change in lightness.
\n* **Dup**: +4 hue; no change in lightness.
\n* **In** (input character): +5 hue; no change in lightness.
\n* **Push**: No change in hue, +1 darkness.
\n* **Subtract**: +1 hue, +1 darkness.
\n* **Mod**: +2 hue, +1 darkness.
\n* **Rotate**: +3 hue, +1 darkness.
\n* **Roll**: +4 hue, +1 darkness.
\n* **Out** (output number): +5 hue, +1 darkness.
\n* **Pop**: No change in hue, +2 darkness.
\n* **Multiply**: +1 hue, +2 darkness.
\n* **Not**: +2 hue, +2 darkness.
\n* **Switch**: +3 hue, +2 darkness.
\n* **In** (input number): +4 hue, +2 darkness.
\n* **Out** (output character): +5 hue, +2 darkness.
\nNumbers in Piet come from the *size* of the color blocks. The number of pixels in the block correspond to a number. So, for example, a block of 6 light yellow pixels followed by a yellow pixel will push the number 6 onto a stack.
\nBlack and white are special colors – white is a separator; white pixels are just skipped over as if they weren’t there. Black pixels are blocks; if the program hits a black pixel, it will try switching the selection directions (ignoring white pixels); if that is also black, it will try rotating the motion direction +90 degrees. If it can’t find any non-black pixels using an sequence of alternating SWITCH\/ROTATE instructions, the program will halt.
\nSo now, finally, you can look at a few nifty examples of [Piet programs][programs]. To make them easier to read, the Piet programs are scaled up, so the pixels are actually represented by largish squares. As usual, we’ll start with “Hello World”:
\n\"Piet_hello_big.jpg\"
\nThat *is* hello world. Each of the large color blocks is one of the characters; the narrow lines are stack manipulations and output statements; and the little black arrowhead toward the top left captures the pointer and forces the program to halt.
\nMoving on, here’s a much fancier “Hello world”:
\n\"hw3-5.jpg\"
\nOne that really meets the goal of looking like a Mondrian painting, this program prints
\nout “Piet”:
\n\"Piet-4.jpg\"
\nMy personal favorite Piet program; this one prints out the alphabet; and the author provided
\nan [annotated version][annote] of it to help you understand how it works! Here’s the program:
\n\"alpha_filled_big.jpg\"
\nOne last brilliant Piet program, which even the guy who *designed* Piet can’t figure out… It’s the towers of Hanoi in Piet!
\n\"hanoibig.jpg\"
\n[annote]: http:\/\/www.dangermouse.net\/esoteric\/piet\/alpha_filled_trace.png
\n[programs]: http:\/\/www.dangermouse.net\/esoteric\/piet\/samples.html
\n[piet]: http:\/\/www.dangermouse.net\/esoteric\/piet.html<\/p>\n","protected":false},"excerpt":{"rendered":"

Todays programming pathology is programs as art. Start with a really simple stack based language, add in a crazy way of encoding instructions using color, and you end up with a masterpiece of beautiful insanity. It’s not too exciting from a purely computational point of view, but the programs are really great to look at. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[92],"tags":[],"class_list":["post-203","post","type-post","status-publish","format-standard","hentry","category-pathological-programming"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4lzZS-3h","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/comments?post=203"}],"version-history":[{"count":0,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/203\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/media?parent=203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/categories?post=203"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/tags?post=203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}