They are all over the world. I mean Damien Hirst's Spot Paintings. Just recently they were at Larry Gagosian's Gallery on 21st Street, New York. They are, well, they are paintings of spots. The Daily Mail has reported that Damien Hirst has only painted a five of them himself. This has prompted some people to make some disparaging comments about his "artistry". I offer my own hommage to his genius below with my interpretations of his work (click to show a new one).
Monday, February 20, 2012
Tuesday, February 14, 2012
Embedding Processing.js in blogger
I spent the day trying to get a Processing.js sketch to show in Blogger. The problem is that the sketch as exported by the Processing IDE is composed of several files, which cannot reside inside Blogger itself. The solution I adopted here is to host the sketch in another computer and embed it here as an "iframe". The result is shown below. The sketch itself builds an animated symmetric Mandala based on a curve drawn by the user.
Usage:
Usage:
- Just draw a single curve by clicking and dragging with left button.
- Clicking the with right button changes the drawing according
to where on the screen the mouse is:
- Top Right : changes colors randomly.
- Top Left : next symmetry mode
- Bottom Right: increases number of copies (symmetry number)
- Bottom Left: decreases number of copies.
Polymorphism and Overloading in Processing/Java
I was trying to do something that I thought was really straightforward, textbook example, really. It was this: I wanted to create an array of objects of type (class) Shape. Something like:
Shape s[] = new Shape[0];
Class Shape should have methods such as draw(), size(), etc. The idea is that I would derive classes such as Square, Circle, etc from shape and be able to call these methods polymorphically. For instance:
for (int i=0; i < s.length; i++) {
s[i].draw();
}
This is what the Shape class in Processing looked like:
class Shape {
float x, y; // Center
float r; // radius
color c; // fill color
// Constructor
Shape (float x, float y, float r, color c) {
this.x = x; this.y = y; this.r = r; this.c = c;
}
// Draws the shape
void draw () {
}
}
Classes Circle and Square followed the same pattern, and the draw() method worked as expected. So far, so good. Problems started when I tried to add a method for shape intersection. It would have a signature such as:
// Returns true if and only if this shape intersects other
boolean intersects (Shape other) {
...
}
Notice that the method implements an operation between two shapes. It stands to reason that it would be possible to write methods in all derived classes implementing the particular intersection algorithm. For instance, Circle would have a method called
boolean intersects (Square other) ...
Thus, if s[i] is a circle and s[j] is a square, then the proper method would be automatically be called for s[i].intersects(s[j]), right? Well, it doesn't work that way. Class inheritance cannot be overloaded!
I then tried writing all variants explicitly in the base class, i.e.:
class Shape {
...
boolean intersects (Square other) ...
// Returns true if and only if this shape intersects other
boolean intersects (Shape other) {
if (other instanceof Square) {
// Code for circle/square intersection
} else if (other instanceof Circle) {
// Code for circle/circle intersection
}
...
}
If I was writing a similar code in Python or Ruby, this is what I would have done from the start. This just goes to show how awkward and complicated language mechanisms based on explicitly declared types can get to no avail.
Shape s[] = new Shape[0];
Class Shape should have methods such as draw(), size(), etc. The idea is that I would derive classes such as Square, Circle, etc from shape and be able to call these methods polymorphically. For instance:
for (int i=0; i < s.length; i++) {
s[i].draw();
}
This is what the Shape class in Processing looked like:
class Shape {
float x, y; // Center
float r; // radius
color c; // fill color
// Constructor
Shape (float x, float y, float r, color c) {
this.x = x; this.y = y; this.r = r; this.c = c;
}
// Draws the shape
void draw () {
}
}
Classes Circle and Square followed the same pattern, and the draw() method worked as expected. So far, so good. Problems started when I tried to add a method for shape intersection. It would have a signature such as:
// Returns true if and only if this shape intersects other
boolean intersects (Shape other) {
...
}
Notice that the method implements an operation between two shapes. It stands to reason that it would be possible to write methods in all derived classes implementing the particular intersection algorithm. For instance, Circle would have a method called
boolean intersects (Square other) ...
Thus, if s[i] is a circle and s[j] is a square, then the proper method would be automatically be called for s[i].intersects(s[j]), right? Well, it doesn't work that way. Class inheritance cannot be overloaded!
I then tried writing all variants explicitly in the base class, i.e.:
class Shape {
...
boolean intersects (Square other) ...
boolean intersects (Circle other) ...
...
}
Sorry. That doesn't work either. Late binding, which is the ability to select the proper method at run time does not work for selecting the proper method based on the argument signature. So, what's the solution? Answer: you have to test for the argument type yourself. Thus, method intersects for class Circle looks like:
}
Sorry. That doesn't work either. Late binding, which is the ability to select the proper method at run time does not work for selecting the proper method based on the argument signature. So, what's the solution? Answer: you have to test for the argument type yourself. Thus, method intersects for class Circle looks like:
// Returns true if and only if this shape intersects other
boolean intersects (Shape other) {
if (other instanceof Square) {
// Code for circle/square intersection
} else if (other instanceof Circle) {
// Code for circle/circle intersection
}
...
}
If I was writing a similar code in Python or Ruby, this is what I would have done from the start. This just goes to show how awkward and complicated language mechanisms based on explicitly declared types can get to no avail.
Subscribe to:
Posts (Atom)