Wattenberg’s code is the most compact of the three and he focuses our attention on that part of it that “daws the picture,” just 16 lines. There is something strange in the way he has made the code presentable by formatting it in HTML with color-coding, and then included in the code’s comments notations about the display of the code that is achieved outside of it. A programmer is perhaps nervous that code is impenetrable and he needs to help the viewer to see what is important. Still, most any casual viewer would be baffled even by these few lines:
synchronized void updatePicture() {
for (int i=0; i<5000; i++) {
int x=(int)(w*Math.random());
int y=(int)(h*Math.random());
long a1=f(p[0],p[1],x,y),
a2=f(p[1],p[2],x,y),
a3=f(p[2],p[0],x,y);
picture.setColor(
(int)(a1*a2*a3)>0 ? a1*a2>0 && a2*a3>0 ?
Color.white : Color.gray : Color.black);
picture.drawLine(x,y,x,y);
}
}
long f(Point p1, Point p2, int x, int y) {
return ((p1.x-x)*(p2.y-y)-(p1.y-y)*(p2.x-x))/13;
}
In any case, there might be enough English cognates to imagine something: synchronized void update picture for math random long set color white grey black. If the viewer expected a random black white and grey picture they would not be far off
Someone familiar with programming would be able to parse more. Connect the dots, like the other two pieces discussed here, is written in java, an OOP language, But Wattenberg makes little use of the OO structure and emphasizes instead the procedural simplicity of his code. In the updatePicture object he highlights, a loop iterates a stochastic algorithm 5000 times. The value of a mathematical function at each random point in the picture is evaluated and compared to determine what color it will be. The mathematical function relates the given random point to the three others, which we know from the rest of the code, are changed based on the user’s mouse movements. The behavior of the mathematical function is difficult to predict, but a mathematician might be able to venture a guess. The changes will fade in gradually and randomly point-by-point after each time the mouse moves.
Looking at the running applet, I see a pattern emerge in random dots. A white triangle is surrounded by alternating grey and black forms. Clicking on the screen causes a new pattern to fade in with the same kind of random dot fill. Clicking and dragging repeatedly I begin to recognize the structures of the visual system that the piece creates. There are clearly many variations ( a function of the number of pixels in the applet, about 250,000 to the 3rd power or about 1.5x1016) but they all conform to a pattern: a central triangle is inscribed by black and white curved bands which hug the triangle’s borders; grey and black contour lines radiate out from the central triangle. The fades between patterns create complicated moiré effects where the new and old patterns overlap. Playing with the mouse I can create various textural effects and ghostly superimpositions. I have a sense of accomplishment in having figured out how the thing works, and becoming a master of its effects. I am delighted by the way I can predict the effects of my actions. But now that I get the game, and the surprise of its variations are exhausted, I lose interest in play. I click away retaining a sense of amusement and wonder in the system that I had become part of for a few moments.
The path of a user’s experience follows a narrative trajectory: confusion > discovery > understanding > exhaustion. The pleasures of this passage involve the sensual, empathetic experience of the algorithms of the software. The phenomenological description of the applet is not that different in character from the conjectures based on a reading of the code. In fact, it is more complete because it is embodied and engaged as well as being conceptual. Moreover, it is not dependent on a reading of the code. There is a way in which the basic programmatic logic of the work is more clearly evident in its visual presentation than it is even in the highlighted form of the code. For the programmer, and perhaps for the uninitiated as well, there is a certain awe of the way that the code actually produces the visual display. There is also an appreciation of Wattenberg’s economy and elegance. But even for a programmer, it is unlikely that one would take the time to carefully parse the code in the way described above before looking at the piece. Most people would be interested in the code afterwards (if at all), in order to see how it works, how it achieves its effects–or as a confirmation of one’s intuitions of the program’s logic. In the other artists’ comments on the piece, Snibbe suggests that he did try to guess the behavior of the code and its equation before watching it run; so that kind of perverse game might appeal to some.
Connect the Dots works in a way that foregrounds the abstraction of the assignment. The three controlling points of the software are any points in the field; they are variables. The piece does not connect three specific points, but rather any three points at the user’s whim. And as the resultant instantiation of the system comes into view, the user is reminded of that arbitrariness again through the method of the fill. At a given point in time, any random pixel is being colored. Wattenberg models a specific mathematical/algorithmic system that has no real world referent, but it does have specific properties. The user is invited to experience and explore them by entering the system as an index of its parameterizations. The outcome of a users manipulations are manifest over time and dot by dot in such a way that the user comes to experience the time of the algorithm: iterative time. In an algorithm, commands are executed sequentially over time (machine time, at the speed of the machine’s clock) and their repetitions accumulate effects, which develop into its outcome. The user is inserted into to that loop and experiences the piece in that time.