# How to determine the length of a Piet program?

I noticed that Piet is not mentioned in the How to count bytes FAQ. How should we determine the length of a piet program?

• Please don't post multiple answers unless you actually agree with them. This is Q&A, not a poll.
– user45941
Dec 20 '16 at 19:44
• Sorry, I will keep that in mind in the future. Dec 20 '16 at 19:45

# Number of bytes in the image file

We should stop making up new scoring schemes for programming languages, which only serves to make things more difficult. Code golf contests are scored in bytes, so that's what matters. Everything else is artifical and prone to not take all details into account.

For example, scoring Piet submissions just by the number of codels doesn't take the shape into account; it considers 4x1, 2x2, and 1x4 images with the same codels the same program, which obviously isn't true.

• I worry that this will cause people to do things outside of just programming to reduce the filesize. Choosing a smaller codel size is fine, but changing image formats to reduce the size does not seem to be in the spirit of code golf (in my opinion). This also begs the question of what image formats are valid, or what even is an image? Can I create my own image format just for code golf? Dec 20 '16 at 20:19
• If there's a Piet interpreter that understands your image format, sure. It just has to predate the challenge. Dec 20 '16 at 20:23
• @MikeBufardeci I'm not entirely sure that "changing image formats to reduce the size does not seem to be in the spirit of code golf". If you're golfing in a programming language whose sources are image based, it makes sense to try to compress the input image. If you prefer only having to worry about codels, there is nothing stopping people from inventing a Piet dialect that reads ASCII input, with text characters in place of colours. (At that point it'll be obvious, that you at least need to count something to define the exact shape of the rectangle.) Dec 20 '16 at 21:50
• @MartinEnder I just think that code golf should score you based on the code you're writing and not other things, like your ability to define a new image format. Clearly I am the only person who feels this way. Dec 21 '16 at 14:33
• @MikeBufardeci Golfing in "regular" languages isn't that different. Using a different character encoding or a laxer compiler can have a tremendous impact on the score. Dec 21 '16 at 14:36
• Fair enough. I guess I will stick to golfing languages then. shrug Dec 21 '16 at 15:09
• I think this is a really bad idea. I'm sure it's hard enough to write code in this language normally, and forcing people to consider how well it's going to be compressed would make it a lot less fun (which IS the entire point of code golf, really). Also, your example of 4x1 and 2x2 images being considered the same also applies to normal text-based code, especially for 2D languages like befunge. Oct 11 '17 at 23:38
• @12Me21 Also, your example of 4x1 and 2x2 images being considered the same also applies to normal text-based code, especially for 2D languages like befunge. That's not true. The positions of the newlines (which contribute to the byte count) determine the layout of the code. Oct 11 '17 at 23:43
• Perhaps Area + Height - 1 would be a better scoring system then. Piet programs could be treated as if they were written as lines of text separated by line break characters (like befunge), and could even be easily converted to and from this format. Oct 12 '17 at 0:05
• @12Me21 Sure, that would work. But do we really need to count all the "linebreaks" in rectangular program if one would suffice to determine the shape? Or do we not require the program to be rectangular? Sure, it's possible to (more or less arbitrarily) pick a scoring method that works for a given language. We can either do that for every single language in existence, or simply count the bytes of actual files we use. Oct 12 '17 at 0:15
• I think it's worth the trouble. How many times would this need to be done? Is it really acceptable to have to worry about code compressability? Imagine if you needed to to this for other languages, such as writing x=x|1 instead of x|=1 because it compresses better. It might be fun to do for a specific challenge that requires it, but having to think about this every time would just be an unnecessary complexity for the programmer. I understand why you'd want to measure the size of the actual program file, but at least compression should not be allowed. Oct 12 '17 at 0:28
• This was a disheartening answer to find. It basically kills Piet as a golfing language, or at least moves the golfing aspect to fiddling with an image encoder instead of actually clever coding, or some monstrous hybrid thereof. It might actually actively work against golfing as the activity of the programmer, since very large values can just be stored as big blobs, being confident that the PNG (or whathaveyou) encoder will compress it well anyway. Nov 15 '19 at 5:16

# Number of codels in the image

All codels in the image will be counted. This includes codels that are never visited, and black and white codels.

• Devil's advocate: Hexagony requires its programs to be certain lengths and automatically pads anything that's too short with nops, and we generally don't consider those as part of the program when determining length. Codels that are never visited and only present to ensure that the image is rectangular seem analogous, the only difference being that in Hexagony the interpreter will automatically pad the code whereas in Piet the programmer is required to do it herself. Feb 19 '17 at 21:59
• @JackBrounstein I had suggesting counting all "functional" codels, but it was very quickly shot down and has been deleted. I think the real way to solve this problem is to make a Piet interpreter for golfing with this functionality, a golf-friendly image format with one byte per codel (or less than one byte per codel), a more golf-friendly way to terminate programs, etc. Feb 21 '17 at 15:25

# Here's an encoding for Piet programs

I've published an encoding (with a translator program) that represents a Piet program as a series of ASCII characters. It encodes each codel as one character, and therefore:

## We can now count Piet programs by codels

There are 20 different colors of codels, so each color can be encoded in five bits. I've used the sixth bit of each character as a flag to indicate end-of-line, meaning that the size of the image doesn't need to be encoded separately. So any Piet program with N codels can be encoded as an N-byte text file. Since we count code by the number of bytes in the file, this means Piet can officially be counted by codels.

### ... Although some programs can be encoded in fewer bytes

Since end-of-line is specified for each line separately, it is possible to have uneven lines. The translator right-pads shorter lines to the length of the longest line using black codels. Therefore, black codels at the ends of lines can be omitted in the encoding. For example, this program has 18 codels, and it can be ASCII-encoded in 18 bytes:

lldd @lldddTllddtF


However, since the two black codels are at the end of a line, they can also be omitted, resulting in a 16-byte ASCII version:

lldDlldddTllddtF


It is up to the golfer whether they want to take advantage of this feature. It's always possible to score your program in codels, since there is always an ASCII representation with the claimed bytecount. If you want to take advantage of the black codel omission, I would suggest reporting both the number of codels and the number of bytes (and perhaps linking to the encoding as well).