In DBN, the canvas for our artistic output is a virtual square sheet of paper, 101 points wide, with the lower bottom point having coordinates [0 0] and the top right point having coordinates [100 100]. The DBN command
line X1 Y2 X2 Y2draws a straight line from endpoint [X1 Y1] to endpoint [X2 Y2]. For example, if X1 = X2 then the line is vertical, whereas if Y1 = Y2 then the line is horizontal.
Let us suppose we are within a square tunnel, facing straight into its unfathomable end. To provide a sense of perspective, we’d like to draw the joints where tunnel segments meet. Click on the canvas to see what I mean.
How do we translate this vision into line commands for DBN to draw it for us? There are various ways to do it, depending on the line segments we choose in the picture, and finding the best way is not always trivial. In this case, the simplest way is to draw two diagonals across the canvas and then two squares.
The diagonals are drawn with two line commands. To explain what they do, I’ll add some comments, which are bits of text that help humans understand how a program works. Computers don’t need such help when executing programs and hence resolutely ignore comments. In the particular case of DBN, a comment starts with // and goes until the end of the line.
line 0 0 100 100 // left bottom corner to right top corner line 0 100 100 0 // left top corner to right bottom corner
Note that in DBN, each command must be written on its own separate line of the program. For example, you can’t write
line 0 0 100 100
or
line 0 0 100 100 line 0 100 100 0
Both cases will lead to error messages. Having one command per text line makes it easy for humans to read the programs and for the DBN environment to execute them, sequentially from the first to the last line of code.
As for drawing a square, if we know the coordinates [left bottom] and [right top] of its two diagonally opposing vertices, then drawing the four sides of a square amounts to writing:
line left bottom right bottom // bottom side line right bottom right top // right side line right top left top // top side line left top left bottom // left side
The four sides can of course be drawn in any other order. All that remains is to find out the required coordinates. Since both vertices are on the main diagonal, we necessarily have left = bottom and right = top. On the other hand, since the square is centred on the canvas, the distance from the left side to the centre (coordinates [50 50]) must be the same as the distance from the centre to the right side. For example, if left = 20, then the distance is 30 and hence right = 50 + 30 = 80.
We are now ready to write the whole program, just by choosing the left side coordinates for the near and the far squares. I have chosen 20 and 40, respectively. (Note that both left sides have to be to the left of the centre and hence must have coordinates smaller than 50.)
// the tunnel // version 1, 30 Oct 2008, Michel Wermelinger // line command uses concrete coordinates line 0 0 100 100 // left bottom corner to right top corner line 0 100 100 0 // left top corner to right bottom corner // near square line 20 20 80 20 // left bottom to right bottom line 80 20 80 80 // right bottom to right top line 80 80 20 80 // right top to left top line 20 80 20 20 // left top to left bottom // far square line 40 40 60 40 // bottom side line 60 40 60 60 // right side line 60 60 40 60 // top side line 40 60 40 40 // right side
Although the program does its job of producing the intended picture, shown earlier, it’s somewhat unsatisfactory, because the reasoning process that led to its construction has been lost. Anyone reading the program (including ourselves after a while!) will not understand how the coordinates for the line commands were obtained. The comments help, of course, but the generic reasoning that enables to draw any centred square has been lost.
Possibly the most exciting thing about programming is that our reasoning can be conveyed to the computer, so that the computer can apply our ingenuity over and over again to different instances of the problem. In other words: we do the creative designing part, we teach it to the computer, and then we let it do the tedious repetitive stuff at high speed – that’s what computers are good for.
In the next post we will see how to precisely and succinctly convey our reasoning steps to the DBN system, in order to turn our concrete two squares into the abstraction of a square centred on the canvas.