# 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. – Mego Dec 20 '16 at 19:44
• Sorry, I will keep that in mind in the future. – Mike Bufardeci 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? – Mike Bufardeci 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. – Dennis 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.) – Martin Ender 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. – Mike Bufardeci 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. – Dennis Dec 21 '16 at 14:36
• Fair enough. I guess I will stick to golfing languages then. shrug – Mike Bufardeci 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. – 12Me21 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. – Dennis 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. – 12Me21 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. – Dennis 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. – 12Me21 Oct 12 '17 at 0:28

# 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. – Jack Brounstein 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. – Mike Bufardeci Feb 21 '17 at 15:25