16
4
This challenge consists in coding an interpreter for a Mondrian painting description language (MPDL).
Language definition
The language operates on a stack of rectangles.
A rectangle is defined by its upper left coordinate and lower right coordinate. Coordinates must be integers.
The stack is initialized with a single rectangle with attributes (1,1,254,254)
Each command has the following format:
<character><integer>
There are three commands:
v<integer>
: perform a vertical split on the latest rectangle in the stack, at the position indicated by the parameter (as percentage). The source rectangle is removed from the stack and replaced with the two new rectangles that result of the split. The left rectangle is pushed on the stack, then the right rectangle. As rectangle coordinates are integers, fractions should be rounded to biggest smaller integer.
h<integer>
: horizontal split. The top rectangle is pushed on the stack, then the bottom rectangle.
c<integer>
: removes the latest rectangle from the stack and paints it to the color given as parameter. 1 = white, 2 = red, 3 = blue, 4 = yellow
Challenge
Write a program that takes as parameter a painting description and creates a 256x256 bitmap representation of the painted rectangles. The rectangles must be separated with a 3 pixel black line. A one or two pixel rectangle should have his non-black pixels hidden by the border black pixels.
The input can be read as a parameter or as a file, up to you. The commands should be separated by a space. You can assume that the input file has correct syntax and does not have trailing or leading spaces, tabs, etc. The output can be directly displayed on the screen, or saved to a file, up to you.
The shortest code wins.
Test
The following source:
v25 h71 v93 h50 c4 c1 c1 c2 h71 c3 h44 c1 c1
Should produce the Composition II in Red, Blue and Yellow:
3
Really hoping someone writes a solution in Piet!
– Skyler – 2015-10-19T14:46:55.3531The language isn't great.
v
andh
arguments should be in pixels – John Dvorak – 2014-10-31T04:58:15.097Also, I'm not sure what's the point of rotating the stack instead of popping. – John Dvorak – 2014-10-31T04:59:58.227
Using percentages allows you to choose whatever size for the output bitmap - the result will be same (only it will be scaled) – Arnaud – 2014-10-31T05:00:22.617
But... why would you modify them later rather than immediately? – John Dvorak – 2014-10-31T05:01:44.377
What are the allowed output formats? Any image format or displaying on screen are all OK? – John Dvorak – 2014-10-31T05:17:40.470
What are the allowed input formats? Are we required to be able to handle newlines, or we may choose? – John Dvorak – 2014-10-31T05:37:08.940
@Jan I update the question to add precisions on output/input formats. Basically : they are free. – Arnaud – 2014-10-31T06:53:01.917
I think a language definition using
[hv]<n>
followed by description of the first rectangle then the second and explicit end of particular branch (either though [c] or a new directive) would make the challenge more interesting allowing for more diverse implementation. This version basically mandates implementing the stack as in the problem definition. – nutki – 2014-10-31T07:46:49.683@nutki You are right. We could have a functional notation as
v30(h50(c1,c5),h70(v50(c1,c3),c2))
. I choose the language above because I though parsing would be simpler. – Arnaud – 2014-10-31T07:50:28.7131Yeah something like that, but note you can still do without extra syntax elements as all operators have constant number of parameters. So the above can be still parsed when represented as
v30 v50 c1 c5 h70 v50 c1 c3 c2
. – nutki – 2014-10-31T08:12:29.187@nutki Agree with you. I hesitate modifying the question, as it has already go through sandbox validation and some may have started coding it? – Arnaud – 2014-10-31T08:19:40.760
The example would be
v25 h71 v44 c1 c1 c3 h71 c2 v93 h50 c1 c4
– nutki – 2014-10-31T08:23:51.060@SuperChafouin I know, it's up to you. You could always allow both formats of the input. – nutki – 2014-10-31T08:26:02.810
@SuperChafouin Also adopting between solutions is not that hard as the only difference to the description is that
c
now pops the stack and there is nor
operation. But the stack operation ofh
andv
would stay as in the original. – nutki – 2014-10-31T08:28:57.407@SuperChafouin "Sandbox validation" isn't anything sacred :P It's your challenge and it's brand new with no answers. Its hardly a risk to add in good ideas. – Calvin's Hobbies – 2014-10-31T08:49:24.827
Why 'to be painted' flag in the new version? Am I missing something why you wouldn't be able to paint it straight away like it the original description? – nutki – 2014-10-31T09:04:48.543
@Martin I prefer using percentages as they also carry semantics about the painting : e.g. split the rectangle at two thirds and paint it yellow. Don't think Mondrian was thinking in pixels :-) Also, no antialiasing because numbers are always rounded. – Arnaud – 2014-10-31T11:46:41.067
Last point, I'd like the description language to be universal and work for any picture size, even if in this specific golf, a fixed bitmap size is given. – Arnaud – 2014-10-31T11:53:42.203