Tag Archive for 'javascript'

News from the JavaScript InfoVis Toolkit 2.0 World

We’re not that far. Not at all. I was actually going to write some completion percentage, but I think I’ll just leave that as a mystery and surprise you when the time comes. But until then… some videos from the 2.0 world!

Animated TreeMaps

In order to show some of the new features I’ve been writing a simple example with TreeMap animations. TreeMap animations are integrated into the built-in classes of the Toolkit, but you can also create your own animations by altering either built-in Node/Edge params, or also canvas specific styles like shadows.

Here’s a short video of an Animated TreeMap, it also has animations when switching layouts. I think it’s better seen in fullscreen.

Zooming and Panning

The new Event system allows many customizations, such as Dragging and Dropping nodes, (right)clicking native Canvas nodes, etc. This will be the subject of a longer post, since there is a lot of machinery involving Native Canvas, SVG and HTML events, event delegation, etc. I’ve also been working in making a modular Canvas class enabling canvas background extensions.

Some of these changes had some desirable effects, such as enabling Panning and Zooming in a generic way, across all visualizations, as can be seen in this video:

A Force Directed Example

These features can be combined into useful and interesting examples. This Force Directed example uses the new Event system, zooming, panning and animations to make a complete graph editing tool. These are some of the graph interactions that can be made with the JavaScript InfoVis Toolkit (also better seen in fullscreen):

I hope you liked it. I know I’m having a great time working in this project.

I’ll be back with more updates.

JavaScript Animations

JavaScript animations are a key aspect of dynamic Web Sites and Application development. Moreover, most JavaScript Frameworks or Libraries provide APIs for dealing with at least three main things:

  • Advanced DOM manipulation
  • Ajax
  • Animations

When developing Web Sites most JavaScript effects involve rendered DOM Elements, but sometimes JavaScript animations are used in other contexts, like when using the Canvas. In the JavaScript InfoVis Toolkit the main target of my animations are Graphs, and in the next version also Nodes and Edges as separate entities.

Today I’d like to describe how to create a generic animation class that can be used or extended for any purpose. I’ll try to be minimalistic and to present only the needed code for making animations. Then you might find useful to add some code to perform specific animation tasks targeting for example specific style properties of a DOM Element.

Defining an Animation Class

Before creating an Animation class we might want to consider what to expose as options to the user. The options I thought of are:

  • The duration of the animation (in milliseconds)
  • The frames per second of the animation

Additionally we’d like to add a couple of controllers, one when a step of the animation is executed and one when the animation has completed:

var options = {
  duration: 1000,
  fps: 40,
  onStep: function(delta) {},
  onComplete: function() {}
};

delta gives us an idea of the progress of the animation. When the animation starts delta will be equal to zero. When the animation ends it’ll be equal to one.

We will also need a start method to trigger the animation and a step method that will compute delta at each step.

Now that we defined our options we can start thinking about our implementation.

Implementing the Animation class

Our Animation class will be a class constructor that sets all the options and properties that we defined before and a prototype with the methods start and step. The class could be used like this:

var fx = new Effect({
  duration: 1000,
  fps: 40,
  onStep: function(delta) {
    /* do stuff */
  },
  onComplete: function() {
    alert('done!');
  }
});
//start the animation
fx.start();

Here’s the code I came up with, inspired by the MooTools Framework:

//define the class constructor
function Effect(opt) {
  this.opt = {
    duration: opt.duration || 1000,
    fps: opt.fps || 40,
    onStep: opt.onStep || function(){},
    onComplete: opt.onComplete || function(){}
  };
}

Effect.prototype = {
  //define how the animation starts
  start: function() {
    //return if we're currently performing an animation
    if(this.timer) return;
    //trigger the animation
    var that = this, fps = this.opt.fps;
    this.time = +new Date;
    this.timer = setInterval(function() { that.step(); },
                             Math.round(1000/fps));
  },
  //triggered at each interval step
  step: function() {
    var currentTime = +new Date, time = this.time, opt = this.opt;
   //check if the time interval already exceeds the duration
   if(currentTime < time + opt.duration) {
     //if not, calculate our animation progress
      var delta = (currentTime - time) / opt.duration;
      opt.onStep(delta);
    } else {
      //we already exceeded the duration, stop the effect
      //and call the onComplete callback
      this.timer = clearInterval(this.timer);
      opt.onStep(1);
      opt.onComplete();
    }
  }
};

One very common operation to do with delta is to change the interval [0, 1] of delta to our desired from and to values that we want to compute for our element. A clever thing to do would be to declare this method as a class method for Effect. We'll call it compute:

Effect.compute = function(from, to, delta) {
  return from + (to - from) * delta;
};

Now If we wanted for example to animate an element's width style from 0 to 10px we could do:

var elem = document.getElementById("myElementId"),
    style = elem.style;
var fx = new Effect({
  duration: 500,
  onStep: function(delta) {
    style.width = Effect.compute(0, 10, delta) + 'px';
  }
});
fx.start();

Extending the Effect class

The animation code defined above could be extended in different ways. For example, this class could be slightly modified to accept a DOM element in its constructor and modify style properties of that element when performing an animation. The code could look like this:

var elem = document.getElementById("myElementId");
var fx = new Effect({
  element: elem,
  duration: 1000
});
fx.start({
  'width': [0, 20, 'px'],
  'height': [0, 5, 'em']
});

The code would now look more or less like this:

//define the class constructor
function Effect(opt) {
  this.opt = {
    element: opt.element,
    duration: opt.duration || 1000,
    fps: opt.fps || 40,
    onComplete: opt.onComplete || function(){}
  };
}

Effect.prototype = {
  //props contains a hash with style properties
  start: function(props) {
    if(this.timer) return;
    var that = this, fps = this.opt.fps;
    this.time = +new Date;
    this.timer = setInterval(function() { that.step(props); },
                             Math.round(1000/fps));
  },
  //triggered at each interval step
  step: function(props) {
     var currentTime = +new Date, time = this.time, opt = this.opt;
     if(currentTime < time + opt.duration) {
      var delta = (currentTime - time) / opt.duration;
     //set the element style properties
     this.setProps(opt.element, props, delta);
    } else {
      this.timer = clearInterval(this.timer);
      this.setProps(opt.element, props, 1);
      opt.onComplete();
    }
  },
  //set style properties. Properties must be
  //in camelcase format.
  setProps: function(elem, props, delta) {
    var style = elem.style;
    for(var prop in props) {
      var values = props[prop];
      style[prop] = Effect.compute(values[0], values[1], delta)
        + (values[2] || '');
    }
  }
};

Other extensions might involve normalizing style keywords, adding effect transitions, adding pause resume methods, and/or using more OO JS idioms when coding these classes.

I hope you got to know a little bit more about animation internals and please if you have any advice on this code, which as I told before is just for demonstration, I'll be pleased to hear you!

ECMA Harmony and the Future of JavaScript

I like to see language implementors (or creators in this case) talk about the design challenges or choices they’re facing with in the next version of their languages.

In this video Brendan Eich, the creator of JavaScript, talks about the ES 3.1/4/5 thingy and also explains what features will be added to JavaScript in some near future (at least for the ECMA standard).

I’ll add a couple of comments about the JS features I liked below the video.

New stuff I liked about the language

Most of the things I liked about the new features of the language are related to Meta-Programming. These new features describe new behaviors in object properties, like getters and setters, but they are also related to object and property mutability, configuration, visibility, etc.

Getters and Setters

Getters and Setters were implemented by B.E. more than nine years ago at mozilla, but a new syntax is introduced in the standard by adding a static function to the Object class.

Object.defineProperty(obj, "length", {
  get: function() {
    return this.computeLength();
  },
  set: function(value) {
    this.changeLength(value);
  }
});

In this example the defineProperty static method of the Object class adds the length property to the obj object. The get and set methods will be called when accessing or modifying the length property.
Object.getOwnPropertyDescriptor retrieves the property descriptor of the defined property.

Defining Methods and Richer Property Descriptors
The Object.defineProperty method can also be used to define instance methods:

Object.defineProperty(Array.prototype, "inject", {
  value: function(memo, iterator, context) {
    iterator = iterator.bind(context);
    this.each(function(value, index) {
      memo = iterator(memo, value, index);
    });
    return memo;
  },

  configurable: false,
  enumerable: false,
  writable: false
});

The method does something similar as inject_into or reduce methods do in other languages:

[ 1, 2, 3 ].inject(0, function(a, b) { return a+b; }); //6

If configurable=true, the property will be enabled for deletion or to be changed in other ways.

You can set a property to be non-enumerable by setting enumerable=false, and it won’t be detected in a for in loop (or in any other “prop” in obj expression). This means that for example we could augment Object.prototype with methods without having to iterate through them in a for in loop.

The writable property if setted to false won’t allow you to change the value of that property.

Object.create

Still no support is added for classical inheritance patterns (which makes me happy I must confess).
Instead, the differential inheritance pattern gets a function that had (somewhat) been implemented by frameworks like Closure, MooTools and others with the inherits and $merge functions.
Object.create can be used for implementing prototypical inheritance: you can create a new class A that inherits from B by cloning an object and augmenting it with a Properties object. For example:

var Person = function() {};
Person.prototype.eat = function() {
  alert("eating");
};
//Ninja extends Person
var Ninja = function() {};
Ninja.prototype = Object.create(Person.prototype, {
  doKungFu: function() {
    alert("wootoo");
  }
});

var n = new Ninja();
n.eat(); //eating
n.doKungFu(); //wootoo

However, don’t forget to instantiate the superclass in your subclass constructor:

var Point = function(x, y) {
  this.x = x;
  this.y = y;
};

Point.prototype.distanceToOrigin = function() {
  return Math.sqrt(this.x * this.x + this.y * this.y);
};
//Complex extends Point
var Complex = function(x, y) {
  Point.call(this, x, y); //call the superclass
};

Complex.prototype = Object.create(Point.prototype, {
  add: function(complex) {
    this.x += complex.x;
    this.y += complex.y;
  }
});

Object.preventExtensions, Object.seal, Object.freeze

Mutability is nice but sometimes we need to make our objects immutable for design reasons, for security reasons. These methods change the mutability level of an object.

  • Object.preventExtensions prevents an object from extending (i.e adding new properties to it). Still the properties it has can be deleted and their value can be changed.
  • Object.seal does everything Object.preventExtensions does and also sets configurable=false for its properties, so they can’t be deleted. The Object properties can be changed though.
  • Object.freeze makes the object completely immutable. Object.freeze does the same Object.preventExtensions and Object.seal do but also sets writable=false for all object properties.

I hope this was useful to you. There are a lot more interesting language features to come, so you can read the ECMA draft if you’re interested in knowing more about this new version.

Sunburst Visualization

In a previous post I showed the ForceDirected visualization I’m working on for version 1.2 of the JavaScript InfoVis Toolkit, today I’d like to talk about another visualization I’ve been working on, the Sunburst Visualization.

What’s the Sunburst Visualization?

I guess an example could help here:

A Sunburst visualization is a radial space-filling visualization technique for displaying tree like structures. There are other space-filling visualization methods that use other visual encodings for describing hierarchies. For example, the Treemap is a space-filling visualization that uses “containment” to show “parent-child” relationships.

There are a couple of subtle changes that can improve the way the information is communicated by this visualization.

  • The “classic” Sunburst visualization uses horizontal labels for node names. One problem with this is that as I mentioned in a previous post labels can be occluded. One solution for this is to rotate labels in a way that they’re not occluded.
  • A simple yet important thing to do when rotating labels is to rotate the labels in a way that they’re always facing up.

    In this example some labels are upside-down:

    A simple check could make labels more readable:

  • Another interesting thing that can be used with the Canvas Text API is the maxWidth parameter. This is an optional parameter that can be used to try to force the text to fit some width. I use this parameter when plotting the Sunburst visualization:

Node Styling and Behavior

The visualization also implements events for hovering and clicking nodes. You can also provide any number of styles to be smoothly updated when hovering and clicking nodes. There’s also onClick and onHover callbacks that are called when a node is clicked or hovered respectively.
For example, this is the configuration I used in the previous example:

        NodeStyles: {
          attachToDOM: false,
          attachToCanvas: true,
          stylesHover: {
            'color': '#d33'
          },
          stylesClick: {
            'color': '#3dd'
          },
          onClick: function(node) {
            //build right column relations list
            buildRightColumnRelationsList(node);

            //hide tip
            sb.tips.tip.style.display = 'none';

            //rotate
            sb.rotate(node, 'animate', {
              'duration': 1500,
              'transition': Trans.Quart.easeInOut
            });
          }
        },

You can also add tool-tips as I did in the example. The configuration I used was:

        Tips: {
          allow: true,
          attachToDOM: false,
          attachToCanvas: true,
          onShow: function(tip, node, elem) {
            tip.innerHTML = node.name;
          }
        },

Node styling and tool-tips can be attached to DOM elements (like HTML or SVG labels) or they can also be attached to the Canvas. The latter method uses an internal MouseEventManager to calculate the position of the mouse event and determine which node of the graph is being hovered or clicked.

Collapsing and Expanding Subtrees

I’ve been also implementing animations for collpasing/expanding subtrees:

The collapsing process reduces the angle span occupied by a parent node and sets its children alpha value to zero. There’s also a visual mark set for collapsed nodes.

I hope you like this visualization. There’s still much work to do, mostly regarding browser compatibility. I’ll keep you up to date with the progress of this visualization and the next visualization I’ll be implementing in the next post :)

Force Directed Layouts

I’m currently working on three new visualizations for the JavaScript InfoVis Toolkit that will be added in version 1.2.

I started the development of these new visualizations a couple of weeks ago, and while trying to incorporate these new visualizations harmoniously into the Toolkit I’ve found myself considering new design and code abstractions I haven’t thought about before. That’s good for the Toolkit, and also good for my brain :)

One of the visualizations I’ll be incorporating in the next major release is a Force-Directed visualization. I first want to thank Marcus Cobden for donating a lot of code related to this algorithm that you can find here.

My code is based in his donation and also in a nice overview of Force-Directed layout algorithms that I’ve found here.

So what are Force-Directed Layout Algorithms?

Force-Directed Layout algorithms are graph drawing algorithms based only on information contained within the structure of the graph itself rather than relying on contextual information. The most straightforward Force-Directed algorithm uses repulsive forces between nodes and attractive forces between adjacent nodes. This physical model produces some local minima in which the graph, well, gets to a stable configuration and is drawn in an aesthetically pleasing way.

The main algorithm consists on a main loop that simulates the system for some iterations and then plots the graph. The system will consist on repulsive forces between all graph nodes and attractive forces between adjacent nodes. The force models considered correspond to Hooke’s law and Coulomb’s law.

Here’s an example with some JSON data I also use for other examples at the demos page:

Force Directed Image

There are lots of refinements and different methods for making Force-Directed Layouts. Some are just based on the model I described before, others are based on what’s called Graph Theoretic Distances: If for two adjacent nodes their ideal distance is set as d, then for nodes with shortest path distance of n their ideal layout distance should be n * d. Attractive and repulsive forces are used to make a graph system with random nodes positions get to a local minima based on these rules.

I implemented the first model I described. For each iteration the computePositionStep method is called to update all nodes positions based on attractive and repulsive forces. The formal parameters passed to the method are property which is an array of node properties which contain positions to be updated and opt which is an object containing layout options like generic repulsive and attractive force functions. $C creates a new Complex Number.

  computePositionStep: function(property, opt) {
    var graph = this.graph, GUtil = Graph.Util;
    var min = Math.min, max = Math.max;
    var dpos = $C(0, 0);
    //calculate repulsive forces
    GUtil.eachNode(graph, function(v) {
      //initialize disp
      $each(property, function(p) {
        v.disp[p].x = 0; v.disp[p].y = 0;
      });
      GUtil.eachNode(graph, function(u) {
        if(u.id != v.id) {
          $each(property, function(p) {
            var vp = v.getPos(p), up = u.getPos(p);
            dpos.x = vp.x - up.x;
            dpos.y = vp.y - up.y;
            var norm = dpos.norm() || 1;
            v.disp[p].$add(dpos
                .$scale(opt.nodef(norm) / norm));
          });
        }
      });
    });
    //calculate attractive forces
    var T = !!graph.getNode(this.root).visited;
    GUtil.eachNode(graph, function(node) {
      GUtil.eachAdjacency(node, function(adj) {
        var nodeTo = adj.nodeTo;
        if(!!nodeTo.visited === T) {
          $each(property, function(p) {
            var vp = node.getPos(p), up = nodeTo.getPos(p);
            dpos.x = vp.x - up.x;
            dpos.y = vp.y - up.y;
            var norm = dpos.norm() || 1;
            node.disp[p].$add(dpos.$scale(-opt.edgef(norm) / norm));
            nodeTo.disp[p].$add(dpos.$scale(-1));
          });
        }
      });
      node.visited = !T;
    });
    //arrange positions to fit the canvas
    var t = opt.t, w2 = opt.width / 2, h2 = opt.height / 2;
    GUtil.eachNode(graph, function(u) {
      $each(property, function(p) {
        var disp = u.disp[p];
        var norm = disp.norm() || 1;
        var p = u.getPos(p);
        p.$add($C(disp.x * min(Math.abs(disp.x), t) / norm,
            disp.y * min(Math.abs(disp.y), t) / norm));
        p.x = min(w2, max(-w2, p.x));
        p.y = min(h2, max(-h2, p.y));
      });
    });
  }

You can find more information about this algorithm in this overview of Force-Directed algorithms.
This method is called multiple times to provide a final layout, for example like this:

      for(var i=0; i < times; i++) {
        opt.t = opt.tstart * (1 - i/(times -1));
        this.computePositionStep(property, opt);
      }

Where times corresponds to the number of iterations of the simulation, and is generally > 50 and t can be thought as the global temperature of a system that gets cooler with each iteration.

Performance

Although there are a couple of methods to reduce the complexity of this algorithm, this implementation runs like O(V^3), which can be considered as really bad performance.

This is not desirable for real-time interactive visualizations, in which everlasting computation algorithms can lead to blocking browser popups like “This Script is Taking too long…” or things like that.

One way you can avoid these popups is by making incremental computations. This can be done by splitting the main algorithm that has for example 100 iterations into smaller pieces of 20 iterations each. The main iteration loop could then be changed into something like this:

  computePositions: function(property, opt, incremental) {
    var times = this.config.iterations, i = 0, that = this;
    if(incremental) {
      (function iter() {
        for(var total=incremental.iter, j=0; j<total; j++) {
          opt.t = opt.tstart * (1 - i++/(times -1));
          that.computePositionStep(property, opt);
          if(i >= times) {
            incremental.onComplete();
            return;
          }
        }
        incremental.onStep(Math.round(i / (times -1) * 100));
        setTimeout(iter, 1);
      })();
    } else {
      for(; i < times; i++) {
        opt.t = opt.tstart * (1 - i/(times -1));
        this.computePositionStep(property, opt);
      }
    }
  }

This method could be called for example like this:

    //compute positions incrementally and animate.
    fd.computePositions(property, opt, {
      iter: 20,
      onStep: function(perc) {
        Log.write(perc + '% loaded...');
      },
      onComplete: function() {
        Log.write('done');
       fd.animate();
      }
    });

And the main computation would be split into smaller parts calling on each step of the computation the onStep callback.

Graph Operations

For graph operations (Adding/Removing nodes and edges, Graph Sum and Graph Morphing) I make all iterations in the first layout and then only apply 20 iterations after some operation has been completed. Here's a video:

When (*not*) to use Force-Directed Layouts

Force-Directed Layouts can be a good choice when you're drawing general graphs and you don't have domain specific (or any other topological) information about them.
Tree structures however are a special case of graphs: this means that tree structures have more constrains and therefore there's more contextual information for drawing a Tree than for drawing a general graph.
Also, Trees are easier to grasp for the human eye than "general graphs". There's that intrinsic notion of hierarchy that can be used to draw aesthetically pleasing graph layouts. Think about the "general graph" layouts that start with the drawing of a spanning tree and then add the "extra edges" to complete the graph structure (for example here and here). The Multitrees method I mentioned a couple of posts ago was also developed to try to extract more contextual information about a graph and draw it based on a notion of partial hierarchy.

Because of this, in my opinion, it wouldn't be wise to plot Trees that have many nodes with this Force-Directed algorithm: this extra-information about trees isn't used in this layout. However, if you're planning on drawing general graphs and you don't have any other information about them, then this algorithm can detect interesting symmetries and make aesthetically pleasing drawings.

I'll keep you updated with the other visualizations I'm working on in the next posts.

MultiTrees (Part 1)

I found this CHI 94′ visualization paper on MultiTrees in the internet and I’ve been trying to see what type of applications and ideas I could “borrow” for the JavaScript InfoVis Toolkit.

What are MultiTrees?

A MultiTree is a type of directed acyclic graph (DAG) where each node has a tree both as parent structure and as descendants.

For example, a MultiTree can be created by overlapping different tree structures on a set of nodes, as shown in the picture below:

As you can see MultiTrees can have cycles if they’re not directed.

Laying and Navigating MultiTrees

What’s interesting about this structure is that if we take two nodes x and y such that x <= y and the path connecting them, then we can form a topological tree by adding all descendants and ancestors of each node belonging to that path in the new graph.

Implementation

I recently pushed support for a small subset of MultiTrees: those where x = y.
This is just a centered node and its tree of descendants and ancestors.

The tree navigation is the same as the SpaceTree:

I also implemented a way of changing the current focused node, so that when the clicked node is centered a centrifugal view from that node is adopted.
This way the current selected node is set as root of the visualization.
Hopefully you’ll understand the difference between this navigation and the previous one.

Anyway, as soon as I get this feature fully functional I’ll make another post explaining how to use this stuff in the JavaScript InfoVis Toolkit.

V8-GL Update

I’ve been quite busy these days.

I’ve been answering questions at the JavaScript InfoVis Toolkit Google Group, fixing a couple of bugs for the JIT and putting a lot of effort in V8-GL.

Oh right, I was almost forgetting that I have a day job also :S

Anyway, V8-GL kind of took another direction. I’ve been working on OpenGL ES 2.0 and OpenGL 2.1 bindings.

OpenGL ES 2.0 bindings are almost complete. Other bindings (like OpenGL 2.1, GLUT and GLU) need some extra work, but they are functional.

Dean helped a lot also. He just translated Vlad’s metatunnel example to work with the new OpenGL ES 2.0 bindings. The result’s pretty impressive:

You can find some videos of “Metatunnel” implemented in Processing or Canvas3D at Youtube.

The good thing about the V8-GL example is that’s a Desktop app coded in JavaScript using V8.

More about the JavaScript InfoVis Toolkit 1.1

I’ve been putting a lot of effort in the upcoming version of the JavaScript InfoVis Toolkit lately, and I though it would be a good idea to show some of the new features I came up with.

The new version isn’t finished yet, but I’ve come pretty far and wanted to make a sort of checkpoint for the things I’ve done, the things I’ll be doing and the things I’m thinking about doing.

So what have I been working on?

  • A new project page design.
  • A complete documentation. I made an API documentation that is also mixed with some narrative documentation for each Class, so you can learn how the visualizations are implemented and how to use them.
  • Packaging All visualizations will be packaged in the same file, and you’ll be able to make your own build based on what you’re going to use (Treemaps, Hypertrees, RGraphs, Spacetrees or any combination of those). This is a cool aspect of making modular code.
    The other good thing about modular code is that the size of the full package will drop in ~30% compared to version 1.0.8a
  • Examples I’ve been coding some new visualization examples that will be packaged with the library. Some of them are very similar to the ones found in 1.0.8a, but adapted for version 1.1. Other examples show some of the new features of the library, and others try to expose some features of version 1.0.8a that were not properly documented.

Library features

I’ve been building this library with four things in mind:

  • Extensibility The library has multiple access points where it can be extended in different ways. For example, all main Classes are mutable objects, so you can extend or implement any method of any class in-place, like for example re-implement the nodes coloring method in the Squarified treemap:

       //TM.Strip, TM.SliceAndDice also work
       TM.Squarified.implement({
         'setColor': function(json) {
           return json.data.$color;
         }
       });
    

    …or adding new node/edge plotting methods in the Hypertree, ST or RGraph:

    Hypertree.Plot.NodeTypes.implement({
      'my-node-rendering-method': function(node, canvas) {
        //implement node rendering here
      }
    });
    

    etc.

  • Customization The library provides many ways for customizing the visualizations. There are controller methods that determine the behavior of the visualization, and configuration parameters like node and edge types, color and dimensions. Node shapes can be square, rectangle, circle, ellipse, etc. and edge shapes: line, hyperline and arrow. I also added transition effects like Quart, Bounce, Elastic, Back, etc. for the animations.
  • Modularity As explained above, the code has been divided into modules, providing a way for making custom builds of the library. Modularity also takes care of namespacing: I only add Classes that are meant to be accessed by the user and I don’t pollute the window object with unnecessary global objects.
  • Composition A major improvement in this version is that all visualizations can co-exist in the same namespace. That means that multiple instances of different visualizations can be used and composed to make new visualizations. I haven’t explored this feature of the library yet, but this would mean that for example I can make a Treemap that has Hypertrees rendered as leaves, or a Spacetree that has Treemaps as nodes, or… well, any other combination of things.

Examples

As you might know, I don’t have the most suited computer for making screencasts, so sorry if you see some performance problems.

This is a short video I made of a RGraph example.

The main idea behind this example is Customization.
That can be seen for example in the different node types, edge types and colors used, as well as in the Elastic transition effect for the animation.

This is just an example to expose as much features as I can in one visualization, so don’t take this as a “useful” visualization example please.

Here is another short video: it illustrates how Graph Operations can be made with the Hypertree visualization.

You’ll see 4 consecutive operations:

  1. Removing a subtree The bottom right subtree will be removed with an animation.
  2. Removing edges Edges from the top left subtree will be removed with an animation.
  3. Adding a graph A graph will be added with an animation
  4. Morphing The graph will transform into another graph -with an animation

Enjoy.

Sharp Variables

I was looking for some way to easily create, read, manipulate and print cyclic or recursive data structures in some programming languages, and got to the cool concept of sharp variables.

Manipulating Recursive Structures in Python

A straightforward way of defining a recursive structure is to first assign a base (non-recursive) structure to a variable, and then alter or extend that variable with a recursive expression. For example, in Python you can write:

my_rec_var = [1, 2, 3]
my_rec_var.append(my_rec_var)

That code will create a recursive data structure: [1, 2, 3, [1, 2, 3, [...]]],
or a = [1, 2, 3, a].

Actually, Python’s print function lets you print a representation of a recursive structure without recursing indefinitely:

>>> print my_rec_var
[1, 2, 3, [...]]

Python’s pickle module lets you dump a recursive data structure into a file. You can also read that serialized structure from the file:

import pickle

#dump it to file
output = open("out.pkl", "wb")
pickle.dump(my_rec_var, output)

However, there’s no literal way of creating, reading or modifying that structure:

>>> my_rec_var = [1, 2, 3, [...]]
 ERROR

Manipulating Recursive Structures in Lisp

For manipulating/printing recursive data structures in Common Lisp we first assign T to the global variable *print-circle*

(setq *print-circle* T)

We can define a recursive structure just as we did with Python, by defining some base structure and then modifying the structure to be recursive:

(defvar *my-rec-var* (list 1 2 3 _))
;Replace the underscore placeholder with a self-reference
(setf (fourth *my-rec-var*) *my-rec-var*)

The final structure is represented with sharp variables:

>>> (print *my-rec-var*)
#1=(1 2 3 #1#)

This is just as the “Mathematical” definition we gave above:
a = [1, 2, 3, a].

What’s interesting about this “serialization format” is that expressions involving sharp variables are truly expressions: these “objects” can be read and manipulated just like any other structure:

>>> (defvar *another-rec-var* ‘#1=(1 2 3 #1#))
#1=(1 2 3 #1#)

>>> (fourth ‘#1=(1 2 3 #1#))
#1=(1 2 3 #1#)

>>> (cons 5 ‘#1=(1 2 3 #1#))
(5 . #1=(1 2 3 #1#))

Sharp variables seem like an excellent solution for creating, reading and manipulating cyclic data structures.

Sharp Variables in JavaScript

Mozilla’s JavaScript implementation has Sharp Variables. They’ve been introduced by Brendan Eich and they are inspired by Common Lisp’s syntax.
Sharp Variables can be pretty useful in JavaScript, since most of the time we’re manipulating object references and Firefox’s toSource() method is pretty useful for debugging (among other things).

var myArray = [1, 2, 3];
myArray.push(myArray);
myArray.toSource();

Try running that in your Firefox console, it should return “#1=[1, 2, 3, #1#]“.

Oh, and did I mention that you can also explicitly manipulate cyclic structures in JavaScript?

//Assign a literal recursive data structure
var anotherArray = #1=[1, 2, 3, #1#];

console.log(anotherArray.toSource());
//"#1=[1, 2, 3, #1#]"

console.log(anotherArray[0]);
//1

console.log(anotherArray[3].toSource());
//"#1=[1, 2, 3, #1#]"

I was happy to find such an interesting Lisp feature in JavaScript.

Generic Functions and JavaScript

In my last post I mentioned Operator Overloading, and why I think it would be interesting to see this as a proposal for the ECMAScript 4 specification (the new JavaScript specification).
I’ve been following the ECMA discussion list and the ES 4 wiki, and I was surprised to see that I feel the same way as some people in the ECMA group do about operator overloading.
The Operator Overloading proposal has been made a couple of times before, but it was disregarded as beeing too weak to be considered.

However, this proposal has been superseeded by some other (very interesting) proposal: generic functions (a.k.a multimethods).

What are generic functions?

The first time I discovered generic functions was while playing with Common Lisp’s Object System (CLOS).
In fact, early Lisp systems worked as Smalltalk did, by implementing a send function:


(send object :foo)

instead of just doing:


(foo object)

They finally came with the solution of creating generic functions that could be implemented by methods. This design is far more expressive that the classic OO design, implemented in languages such as Java.
Since this design is far from classical OO ones, explaining by example turns out to be quite difficult: the wikipedia examples aren’t very enlightening (see the article’s discussions).

So here I go.

Java has function overloading: that means that several methods with the same name can be defined in the same class, provided that the type (or number of arguments) defined in each method is not the same.

So, for example, lets define a Java class Person with two eat methods:

  class Person {
    public void eat (Food f) { println ("eating food"); }
    public void eat(Pasta p) { println ("eating pasta"); }
  }

(Pasta extends Food)

We have succesfully overloaded the eat method. However, the overloading happens at compile time, and there’s no dynamic dispatch. So, for example this code:

  Food food = new Pasta();
  somePerson.eat(food);

Will answer “eating food”, which isn’t exactly what we want.

Now lets consider this code:

class John extends Person {
    public void eat(Food f) { println ("mmm...."); }
    public void eat(Pasta p) { println ("Yummy!"); }
  }

  Person me = new John();
  Food pasta   = new Pasta();
  me.eat(pasta);

This code will answer “mmm…”. But there’s one important thing: we’ve called a method from John’s class, instead of some eat method from Person.

This had to be decided at run time, since me is of type Person, but we assigned a John to it…

Now lets define, in pseudo-code, an abstraction of these eat methods, that could be thought as decoupled from the John and Person classes. For example, we could re-write John and Person eat methods as four independent functions:

public void function eat(John john, Food f) { ... }
public void function eat(John john, Pasta p) { ... }

public void function eat(Person person, Food f) { ... }
public void function eat(Person person, Pasta p) { ... }

What we know about these methods is that Java checks its first argument type at runtime, but all other arguments are checked at compile-time.
So, as far as dynamic dispatch concerns, Java has single dispatch, and function overloading only refers to compile-time checked types, which in general doesn’t yield the expected result. (This problem beeing solved by the visitor pattern in most cases).

A generic function can be seen as a family of functions that provide multiple dispatch, that means that all arguments of the function are checked at runtime (on invocation). Not only the first argument, but all.
Compared to Java, this approach would, in most cases, yield the expected answers without having to implement some patterns like the visitor pattern.

The four methods defined above could be redefined in CLOS as:

(defmethod eat ((john John) (f Food)) ... )
(defmethod eat ((john John) (p Pasta)) ... )

(defmethod eat ((person Person) (f Food)) ... )
(defmethod eat ((person Person) (p Pasta)) ... )

Generic Functions in JavaScript

The Generic Functions JavaScript proposal aims to solve all weaknesses existing in the Operator Overloading proposal, but it also provides a more generic way of defining and manipulating functions.
Operator Overloading should be seen as a particular case of what can be done with generic functions in JavaScript.

In JavaScript, a generic function could be defined as:


generic function f(x, y);

Since a generic function defines a family of functions, there’s no function body in it.
A generic function can also be defined with type annotations:


generic function f(x: Numeric, y: Object): MyClass;

A method is then defined over an existing generic function, using specializers:


 generic function f(x:int, y:boolean): string {
      if (y)
          return string(x);
      else
          return "37";
  }

Eventually, built-in generic functions could be defined for common operators, providing a way of overloading operators:


generic function +(a:Complex, b:Complex) {
   return new Complex(a.x + b.x, a.y + b.y);
}

For a JavaScript canvas developer, this would be wonderful, since we mess with Complex, Polar, Matrix classes all the time, and a simple interpolation expression of two complex numbers could be transformed from this:

(to.$add(from.scale(-1))).$scale(delta).$add(from)

into this:


from + (to - from) * delta