The good news is that I got a contract to write an article in which to discuss content-aware resizing (or rather, I got a contract for an article on performance tuning; I'll use the resizing algorithm as the sample).

The bad news is that the profiler I'll be discussing is native-code only, so it looks like I'll be writing my program in C++.

I would still like to do a managed-code version and I'll write my C++ with an eye towards portability, but unless I can figure out a simple seam-generation algorithm, I doubt that I'll have the time. Right now, I think Boykov-Veksler-Zabih graph-cutting is the answer as far as runtime efficiency, but it's not a trivial algorithm to implement. I spent last evening noodling around with other approaches that might not be as effective, but with which I'm more familiar; unfortunately, I didn't see anything to convince me they would work. 

Regular readers will not be surprised to hear that I spent the morning working on an implementation of this.

Figuring out the "next" seam is simple enough, but coming up with an optimal sequence is going to take more time. Stay tuned...

Now, would you be most interested in seeing this implemented in:

I just glanced over at my RSS aggregator and was surprised to see a full-page Web ad for something I obviously wouldn't be interested in. I clicked the "back" button and saw the normal newspaper layout and a nondescript blogpost that had a Feedburner-supplied ad at the bottom.

Which, in dastardly fashion, uses JavaScript to trigger a redirect / refresh.

Several people have let me know that comments often fail to post / validate. I'm planning on updating to the latest das Blog in a few weeks, after I do some traveling. Until then, I cannot afford to turn off CAPTCHA and I know that not every comment fails. My suggestion (irritating, I know) is to Ctl-A, Ctl-C your comment, try to post it and if it fails, at least you can just Ctl-V it.

This video of an image manipulation algorithm shown at SIGGRAPH is jaw-dropping. They calculate paths through an image that have low entropy and either delete or interpolate them, creating images that shrink or grow while not distorting the "interesting" elements. (via John Lam)

Here's the paper from the conference.

I used to frequently attend, talk at, and help organize software development conferences. As a former magazine editor, I couldn't help but compare the "information bandwidth" (if not the ultimate efficacy) of lectures with magazine articles and books. I concluded that successful one-hour lectures provided about the information of an 1,800-word technical article (which is about 1.5x the length I believe is most effective for a technical article). Attempts to provide more information in an hour-long lecture forced skipping important details, attempts to provide much less information made the lecture too fluffy (this observation was validated by attendee ratings. Not that attendee ratings are primarily correlated to information delivered, but that's the topic of another post.)

This enforces the not-as-common-as-it-should-be wisdom that lectures are the least valuable aspect of professional conferences. Not that lectures are unimportant; you should attend conferences with great lectures, and even go out of your way to be in the hall as the lecture begins and ends, but you ought not to be terribly concerned about actually attending hour-long lectures.

Many conferences today are moving towards much shorter lectures: 15, 20, and 30 minutes. I think this dramatically increases value to the attendee (while making things significantly harder for the presenters and vastly harder for the organizers).

Phillip Greenspun, in a post on improving undergraduate CS  quality that holds for professional training as well, concludes:

• Lecturing has been found to be extremely ineffective by all researchers.  The FAA limits lectures to 20 minutes or so in U.S. flight schools.
• Lab and project work are where students learn the most.  The school that adopted lab/projects as the core of their approach quickly zoomed to the first position among American undergrad schools of engineering (www.olin.edu).
• Engineers learn by doing progressively larger projects, not by doing what they’re told in one-week homework assignments or doing small pieces of a big project
• Everything that is part of a bachelor’s in CS can be taught as part of a project that has all phases of the engineering cycle, e.g., teach physics and calculus by assigning students to build a flight simulator
• It makes a lot of sense to separate teaching/coaching from grading and, in the Internet age, it is trivial to do so.  Define the standard, but let others decide whether or not your students have met the standard.
• A student who graduates with a portfolio of 10 systems, each of which he or she understands completely and can show off the documentation as well as the function (on the Web or on the student’s laptop), is a student who will get a software development job.

Congratulations to my friends (and employers) at BZ Media, which has made the cut for Inc. Magazine's "5,000 list," ranking the fastest-growing private companies in the US.

The working groups of the C++0x committee are working hard to complete a major new standard for C++ (there's a big meeting here in Kona in October). If you're not intimate with C++, you may be surprised that such an important language has not had a standard threading model and that such a model is a major part of the C++0x version. This is actually part-and-parcel of the design philosophy that made C and C++ so important: the number of libraries dictated by the standard for C and C++ is much smaller than the BCL or Java's SE libraries. This allows standard C and C++ to be available for hundreds of processors.

I recently read the public C++0x papers on threading (links below). The proposed threading model is non-radical and is based on Boost.Thread. The reasonable perspective is that this is a conservative decision thoroughly in keeping with C/C++'s long tradition of minimal hardware/OS assumptions.

The emotional perspective is that they've let slip by a golden opportunity to incorporate the best thinking about memory models. "Multi-threading and locking" is, I would argue, demonstrably broken for business programming. It just doesn't work in a world of systems built from a combination of libraries and user-code; while you can create large applications based on this model, large multithreaded applications based on locking require not just care, but sophistication, at every level of coding. By standardizing an established systems-level model, C++0x foregoes an opportunity for leadership, albeit radical.

One of the real thought leaders when it comes to more sophisticated concurrency semantics is Herb Sutter. His Concur model (here's a talk on Concur from PDC '05) is, I think, a substantial step forward and I've really hoped to see it influence language design. Is Sutter, though, just an academic with flighty thoughts and little understanding of the difficulties of implementation? It seems unlikely, given that he's the Chair of the ISO C++ standards committee. So you can see why there might have been an opportunity.

Multithreading proposals for C++0x:

• http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2320.html
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2334.htm
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2381.html
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2382.html

I don't really follow the discussion about social networking (I guess I'm either a little too old or a little too antisocial to "get" it), but it seems to me that FOAF + OpenID is "ob hack." It seems to me that all that has to happen is that someone writes a local / smart client editor with the kind of nit-picky details that you have to deal with for a blog editor (FTP upload, WordPress plugin, etc.) and Bob's your uncle.

Looks like the only programming tools for Tilera's 64-Core CPU is a C compiler, but the day is fast approaching when we're going to start seeing more and more of these types of tools in the mainstream.

(HOTEL_BLOCK_RESERVATION(HOTEL_ID (IATA_NODE MDW) (PHONE_NUMBER 708 563 0200) (HOTEL_NAME Courtyard by Marriot)) (DAY_BLOCK (DATE_NODE 08 31 07) (FLIGHT_BLOCK (PAIRING_NODE (PAIRI... etc...

"VisitorTests.parsesTheWholeThing(): Lex & Parse: 2765 ms. ReservationCountWalker 282 ms. to find 27327 reservations"

Man, if I could just get my clients to fund it, I could make that Silverlight "air travel" demo look like a joke...

Bill de hÓra makes an intriguing pitch that programming will be impacted by increasing data volumes more than by the transition to multi-/many-core. His basis is anecdotal -- we don't have the same metaphysical certainty that all of us will be dealing with much-larger datasets as we have the certainty that we will all be dealing with multiple and then many cores -- but is logical. The speed of a single stream of in-cache instructions is blazing: short of chaotic functions, it's hard to imagine perceptibly-slow scenarios that don't involve large amounts of data.

What I find especially thought-provoking about this argument is that it stands in opposition to another post I was going to make about YAGNI infrastructure. Not long ago, Alan Zeichick ranked databases and Ian Griffiths questioned whether he took price-performance into account. Even allowing that there are costs for OSS (training, tools, administration, etc.), I've noticed that few real-world CEOs understand where their companies stand in relationship to scaling. In my experience, they often over-buy software- and hardware- capacity and under-buy contingency capacity.

It seems to me that nowadays we work more and more with data streams and not data sets. On a transaction-to-transaction basis, I think it's an uncommon application that uses more data than can fit into several gigabytes of RAM (obvious exception: multimedia data). Never mind multi-node Map-Reduce; I'm saying that it seems to me that many "real" business systems could have a single-node non-relational data access layer.

It seems that what I'm saying is in direct contrast to what de hÓra is describing, and yet points to the same "maybe we ought not to start from the assumption of a relational DB" heresy. No conclusion... food for thought ...

Reflection: I think I let my attention wander -- the world de hÓra is describing is that high-performance computing and I wandered into general business-computing. The two intersect, of course, but are not generally the same. So the thought then becomes that powerful relational databases are being squeezed from both the low-end ("eh, just put in memory") and the high-end ("ok, so this is our distributed tuple-space...").

Dustin Campbell does a good job explaining the mechanics of currying in C#, although I'm afraid he stops before truly explaining why currying is considered an essential building block of functional programming. He promises to get to that in "the next post" so I won't offer my own take. As with recursion, simple examples often seem pointlessly complex ("Why would I want to calculate a factorial with recursion? Why would I want to add numbers with a curried function?"), so you're not likely to get the actual "art" of currying until he does his follow-up. (via .NET Languages Weblog)

Antonia Vargas sent me some links to some new "demos" (very small programs from which complex graphics and music emerge):

http://winden.wordpress.com/2007/08/05/a-little-bit-of-assembly-2007/
http://www.pouet.net/party.php?which=7&when=2007

Purdue researchers have applied the idea of an ionic breeze to cooling computer chips. This seems like a slam-dunk to me: more flexibility than a fan in terms of structure, the ability to generate the wind without a dead layer near the surface, and thereby more efficient. Presumably much quieter, since there would be no ball bearings and increased efficiency means less total air displacement. Couple years to commercialize they say...

In the past 96 hours, I've been exposed to:

• meteors,
• an earthquake,
• a hurricane,
• a tsunami watch,
• annoying frogs (which, while not exactly toads, are still amphibians), and
• annoying crickets (which, while not exactly locusts, are still Orthopterids).

I feel like I should return that tiki to the cave...

We stayed over Tom & Lana Plum's house last night, hoping to take advantage of their very dark skies to see the Perseids. Slept on the porch on thin mattresses, beautiful milky way / Sagittarius / Scorpio in the evening hours. Saw a couple nice earth-skimmers around midnight, and then dozed fitfully until 4AM for the "big show." Unfortunately, large portions of the sky were overcast so that only 1st magnitude stars shone through, and there was only a keyhole near Orion that gave a glimpse of a few meteors.

 Drove home early to talk to our wall construction guys and I now see that Hurricane Flossie is projected to remain a Category 3 as it passes by and if it's north of the projected track at all, it will hit the Big Island. We should get significant protection from Mauna Loa and Hualalai mountains as long as the eye stays south of us and we're hit by the East-to-West portion. If the eye tracks north and we get West-to-East, that could potentially suck.

 Jon Skeet wonders:

I've been looking at C# 3 in a fair amount of detail recently, and likewise going over the features of C# 2....I feel sorry for someone wanting to learn C# 3 from scratch. It's becoming quite a big language....It's often been said in the newsgroups (usually when someone has been moving from another language to C#) that C# itself only takes a few days to learn....I suspect it would be hard to do it any sort of justice in less than about 700 pages, which is a pretty off-putting size (at least for me).

You can't learn C# in days unless you have a background in either C++ or Java. JavaScript won't do it, because you have to learn about static typing, value and reference types, different inheritance model, different model for function objects / delegates / events. My book on C# 1.0 was over 900 pages and, although based on about the most successful structure for teaching Java, was inadequate for a true newcomer. That was before generics, which would take many pages to explain to the point of people "knowing" the idioms, much less lambdas and LINQ, which would be at least another 200.

To compile an object-oriented "Hello, World" in C# (1, much less 3) has a huge conceptual load: namespaces, classes, references, the difference between static and instance methods and variables (which, to really understand, requires a digression into the this pointer and v-tables, which opens a can of worms about how the CLR differs from the underlying memory model).... think about how many concepts you have to understand to understand public static void main(string[] args)

That so many of us learned C# after knowing Java after knowing C++ after knowing C has perpetuated the myth that any of those languages are "learnable in days." It's just not so. I used to teach a hugely successful 5-day course on Java which worked great... as long as they weren't COBOL programmers. I imagine I would face the exact same problems trying to teach newcomers coming from, say, ColdFusion or Flash. Of course some people would "get" it, but I guarantee that those people would be those who had primed themselves on C-derived syntax and object orientation.

Harry Pierson wonders "Where Have All the SOA Mashups Gone?" Well, this one went well. I'm not sure if it counts as a "mashup" in that all the data I was working with was XML and the interdiction / mashup was programmed in Ruby.

For weeks, I've been chewing over this post by Raymond Chen, in which he says:

[T]he real cost of compatibility is not in the hacks. The hacks are small potatoes. Most hacks are just a few lines of code (sometimes as few as zero), so the impact on performance is fairly low.

The idea of a non-backward compatible version of Windows is something that I've mused about (as has Alan Zeichick). I'm not going to pick an argument with Chen, of course, but I wonder if he's not being a little disingenuous. Even a few lines of code in a core routine can have an effect if it affects cache behavior; okay, that's niggling... But still, to say that a non-compatible version wouldn't be much faster but to go on to say:

[T]he real cost of compatibility is in the design.

If you're going to design a feature that enhances the window manager in some way, you have to think about how existing programs are going to react to your feature. These are programs that predate your feature and naturally know nothing about it. Does your feature alter the message order? Does it introduce a new point of re-entrancy? Does it cause a function to begin dispatching messages that previously did not? You may be forced to design your feature differently in order to accommodate these concerns. These issues aren't things you can "take out"; they are inherently part of the feature design.

Well, yeah. But isn't that kind of like saying "the real cost of compatibility is not how fast you can type in the code, it's in the work."?

Surely (well, not surely, but surely "likely") a version of Windows where backwards compatibility was negotiable would have more flexibility for the type of redesign / refactoring which Windows will need for the manycore era? If nothing else, surely intuitively one would think that the very concept of the Windows message-loop (much less message ordering) would become highly problematic when trying to figure out how to exploit many cores.

The Piss-Screen is a pressure-sensitive inlay for urinals, to play a game with your pee. The game is displayed on a screen above the urinal. Link

The game development industry is the most miserable sector in the software development industry: lower pay, more bozos, worse management. And within that sector, marketing-driven games are the worst sub-sector. I'm trying to imagine the karma that one must accrue in order to program a marketing-driven urine-controlled videogame.