One of the annoying things about Twitter is that sometimes I want to tweet something, but I don’t want to actually read anything from my feed (because I’ll surely get distracted). So I wrote this trivial, minimal piece of python code to tweet from the command line.

This continues the set of notes I started on the previous post.

At this point, VisWeek 2012 is just about halfway done, and there’s tons to write about, but I’ll try to keep these short by sticking to one day at a time. VisWeek now runs four parallel tracks for the best part of a week, so there’s no way I can tell you about everything that is happening out here in (today, surprisingly sunny!) Seattle. But I will tell you about what I think is cool. The usual caveats follow: omissions and mischaracterizations are all my fault.

This series of posts is a tour of the design space of graph visualization. I’ve written about graphs and their properties, and how the encoding of data into a visual representation is crucial. In this post, I will use those ideas to justify the choices behind a classic algorithm for laying out directed, mostly-acyclic graphs.

Here’s a Javascript-specific software engineering problem I’m considering within Facet. I’m trying to decide how (or even whether) to approach type-checking in the API, and I’m looking for input.

Marc Khoury, Yifan Hu, Shankar Krishnan, Carlos Scheidegger. Eurovis 2012, to appear.

Optimizing a stress model is a natural technique for drawing graphs: one seeks an embedding into $R^d$ which best preserves the induced graph metric. Current approaches to solving the stress model for a graph with $|V|$ nodes and $|E|$ edges require the full all-pairs shortest paths (APSP) matrix, which takes $O(|V|^2 \log|E| + |V||E|)$ time and $O(|V|^2)$ space. We propose a novel algorithm based on a low-rank approximation to the required matrices. The crux of our technique is an observation that it is possible to approximate the full APSP matrix, even when only a small subset of its entries are known. Our algorithm takes time $O(k |V| + |V| \log |V| + |E|)$ per iteration with a preprocessing time of $O(k^3+k(|E|+|V|\log|V|)+k^2 |V|)$ and memory usage of $O(k|V|)$, where a user-defined parameter $k$ trades off quality of approximation with running time and space. We give experimental results which show, to the best of our knowledge, the largest (albeit approximate) full stress model based layouts to date.

This series of posts is a thorough examination of the design space of graph visualization (Intro, part 1). In the previous post, we talked about graphs and their properties. We will now talk about constraints arising from the process of transforming our data into a visualization.

I’ve been playing around with the HCL color space. HCL, if you’ve never heard of it before, is a color space that tries to combine the advantages of perceptual uniformity of Luv, and the simplicity of specification of HSV and HSL. HCL is an improvement over HSV and HSL, but it is not exactly ideal: there is a nasty discontinuity at some bits of the transformation! I have been trying to find a way around this, but I’m stumped. Let me explain, and maybe you can help me.

This series of posts is a tour through of the design space of graph visualization. As I promised, I will do my best to objectively justify as many visualization decisions as I can. This means we will have to go slow; I won’t even draw anything today! In this post, I will only take the very first step: all we will do is think about graphs, and what might be interesting about them.