Sunday, March 4, 2012

My New Guru

I'm a skeptic. But even in my materialistic world view, sometimes I recognize a kind of Moses climbing down Mt Sinai with some nice ideas. Perhaps the simile is a bit forced, but I had a sort of epiphany watching Bret Victor's "Inventing on Principle"talk



Bret helps deconstruct the stereotyping of us computer geeks as shallow types. He has a vision, he has a mission, and, best of all, he can show you how computer programming should really be done! As with any bona fide guru, he also has a huge following. His ideas are catching on, as evidenced by Chris Granger live game editor in Clojurescript. To get your own epiphany, watch the talk, and then visit Brett's WorryDream.com page, which is a marvel by itself.

Monday, February 20, 2012

Damien Hirst's Spot Paintings

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).

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:
  1. Just draw a single curve by clicking and dragging with left button.
  2. 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) ...
   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:

  // 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.