Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Math Programming

Visualizing Algorithms 50

An anonymous reader writes "Many people reading this site probably have a functional understanding of how algorithms work. But whether you know algorithms down to highly mathematical abstractions or simple as a fuzzy series of steps that transform input into output, it can be helpful to visualize what's going on under the hood. That's what Mike Bostock has done in a new article. He walks through algorithms for sampling, shuffling, and maze generation, using beautiful and fascinating visualizations to show how each algorithm works and how it differs from other options.

He says, "I find watching algorithms endlessly fascinating, even mesmerizing. Particularly so when randomness is involved. ... Being able to see what your code is doing can boost productivity. Visualization does not supplant the need for tests, but tests are useful primarily for detecting failure and not explaining it. Visualization can also discover unexpected behavior in your implementation, even when the output looks correct. ...Even if you just want to learn for yourself, visualization can be a great way to gain deep understanding. Teaching is one of the most effective ways of learning, and implementing a visualization is like teaching yourself."
This discussion has been archived. No new comments can be posted.

Visualizing Algorithms

Comments Filter:
  • Wonderful stuff. Reminded me of this site: http://www.informationisbeauti... [] (beautiful ways to view typically boring stuff).

  • The cycles of global warming

  • I'm sure this is fun cool stuff to play with but... I'm pretty sure my imagination is still better than what a computer screen can show me. "Playing computer" is one of the first practices most new programmers learn, and if you're good at it, it is one of the most powerful tools in your arsenal.

    Here's hoping "kids these days" don't skip out on the importance of programmer's imagination over these new fangled tools.

    • by sribe ( 304414 )

      Here's hoping "kids these days" don't skip out on the importance of programmer's imagination over these new fangled tools.

      Here's hoping they do. Us old farts need all the advantages we can get.

      • by ebyrob ( 165903 )

        Actually, after reading the article, I'd call what he's doing extremely good basic engineering and model design/view. It's very cool for the problems he presents, but looks like a ton of work. To be generally useful, it seems he'd have to come up with rules of thumb and generalizations for what it is typically important to see/understand in a given algorithm and a way to identify *what* to model/visualize that isn't completely subjective.

        He appears to make some great subjective decisions on what/how to do

        • I think the overall point he's making is that visualizing an algorithm's behavior can offer us better insight, faster, vs. just looking at our code and our error logs. I'm sure there are ubermensch programmers out there that never have their programs exhibit unexpected behavior, and always understand exactly why a test fails, but I'm not one of them.

          I encountered this firsthand when I spent a couple of days trying to write a simple algorithm to detect clipping on an oscilloscope output. We had a secondary
          • by ebyrob ( 165903 )

            > Once you get familiar with the tools to make these kinds of visualizations, it can become very straightforward to develop one for your specific use case.

            That's the thing, we need a Visualization for Understanding 101 class in comp-sci or something similar.

            I guess I had scientific modeling in physics as part of EE but over half the focus was on how to gather/deal with the physicalities of real-world data, which isn't so important when you're modeling something which lives inside a computer to begin with

            • Note: I thought it was obvious reading digital output as analog (or merely hooking together input to output on two sensitive instruments) is always going to cause a lot of artifacts and distortion. You don't chain 2 microscopes together and expect to get twice the magnification with no problems...

              Maybe my description wasn't clear. These were two oscilloscopes, reading from the same source in parallel. One scope was looking at a high resolution, set to trigger on anything above noise, but with something like a 1V maximum amplitude (hence clipping at 1V). The second was set to trigger at anything over 1V, and had a much larger view window, so there was no data lost to clipping.

              The motivation here was to get detail data while simultaneously making sure to capture the full amplitude of big signals. N

  • by Bengie ( 1121981 ) on Friday June 27, 2014 @09:54AM (#47332271)
    I've always visualized what's going on, this is how I do everything. Doesn't everyone program this way? Think about something for a while, building up the model in your head, then visualize the interactions among the parts. If the problem is too complex to visualize, then I simplify and add abstractions until I can visualize it. This iteration naturally creates simplified abstract layers in my code.

    I debug most of my code this way also. When I'm internally visualizing stuff, I lose track of what's going on around me. I wouldn't be surprised if a brainscan would show activity in my visual cortex.
    • by sribe ( 304414 )

      Doesn't everyone program this way?

      No, actually ;-)

      There seem to be at least a couple of distinct ways of "sensing" the code you're working on. (And I'm not even counting the poor schmucks who are never really able to understand what they're doing.)

    • by ebyrob ( 165903 )

      I can't speak for anyone else, but I'm definitely this way. When I get to work in the morning I return to the massive subjective machano-city in my head where the repository lives and plug it in to the objective reality that is Mercurial. Much of bug-fixing is ferreting out the differences between the two. Reading code is removing the fog of the unknown in my head and writing is creating new streets, buildings, and even neighborhoods. (Well... You could hardly call it something so terrestrial, more like

      • by Bengie ( 1121981 )
        I'm not surprised, but it's interesting how you describe your visualization doesn't quite match how I "see" them. I would think it to be a cool topic to categorize different types of visualizations and finding correlations with who knows what.

        Assuming I'm taking this the correct way, I find there to also be a "fog" of the sort when I work with stuff. I would describe my visualization as a "living" yet static picture. Different "parts" of the picture interact with other near-by parts, yet nothing actually
        • Holy crap, you just described in perfect detail the way my brain works. I've never really been able to describe it, but you just did it perfectly... even right down to your past experiences in school. I particularly likes how you describe it as a living, yet static picture. The best I've always been able to describe it is; "I have a lot of RAM, but a slow CPU." Someone should make a myers-briggs-like classification specifically for engineers (predominately INTP/INTJ types?) . There are clearly some common t
        • I identify with your school experiences, although maybe not in as extreme a way; I could generally muddle through rote memorization to a certain degree, but my retention was terrible. The understanding was left behind when the specifics faded away...

          Anyhow, for me, the "picture" exists, but it's more tactile than visual. There are visual aspects, but it's not how I process most of the information. Loops are spinning wheels when they don't have a clear exit condition, and feel like unrolled spirals when the
    • Well, yes, but ...

      when the animations end, the resulting mazes are difficult to distinguish from each other. The animations are useful for showing how the algorithm works, but fail to reveal the resulting tree structure.

      Sure, I visualise how algorithms work, otherwise I can't code them. But the difference in maze generators struck me. Because, as quoted, they're difficult to distinguish from each other.

      Other things, such as sorting algorithms, are fairly obvious though... but still nice to see, again.

    • That's not what the article is about. It's about generating graphical visualizations of what your code is doing on a computer screen, not generating internal visualizations of what you think your code is doing in your head. In fact, I'd guess that most of the value of the former comes from noticing the ways in which it's different from the latter.
  • Many people reading this site probably have a functional understanding of how algorithms work.


  • by Anonymous Coward

  • by nullchar ( 446050 ) on Friday June 27, 2014 @10:25AM (#47332499)

    I'm not affiliated with the author in any way, but I did buy the book (though you can get it for free).

    This is an amazing resource for someone new to D3.js []'s declarative javascript and helps you put it all together: []

    After using D3.js, I've come to the conclusion Mike Bostock is awesome! But it doesn't stop there, people have expanded it like Crossfilter [] and dc.js [].

    Tech that allows a javascript n00b like myself to build a simple race results visualization [].

  • by account_deleted ( 4530225 ) on Friday June 27, 2014 @10:37AM (#47332611)
    Comment removed based on user account deletion
  • in explaining how things really are.

    Light is a continuous signal. It must be sampled at an interval to be determined and interpreted. It actually flows like a river. Amazing.

    • Like many things in physics, it's really a discrete signal at a rate so high as to be continuous for all practical purposes. If you could get your sampling rate ridiculous enough, you'll start to detect individual photons.

  • This is interesting work, and very well presented no doubt. But it shows why your PhD guru is making you spend seemingly unreasonable time doing literature surveys. At first glance this work seems to be very close to solution adaptive meshing techniques used in computational physics.

    Using a bunch of sample points to represent a function is fundamental to computational physics. Stress Analysis, Colorful oops Computational Fluid Dynamics, Computational Electro Magnetics etc etc. Solution adaptive meshing is

    • by Anonymous Coward

      There's no claim to novelty for any of the algorithms. If you scroll down you'll also see imagery of quicksort: stop the presses, this was invented in 1960. The point is the graphical presentation of existing algorithms. This is all made very clear in the prose, and in the summary, and in the title. So well done Captain Blowhard, top marks for your knowledge of a somewhat related domain (although what you're talking about really has fuck all to do with Poisson-disc distributions) but minus several milli

  • by Lorens ( 597774 ) on Friday June 27, 2014 @12:58PM (#47334123) Journal

    Visualization is also great for evaluating randomness; remember the images of broken RNG implementations a few years ago? []

Remember to say hello to your bank teller.