Visual cortex fail

October 5th, 2008

Ever have the experience of waking up and checking your email, and then wondering for a moment why you don't seem to be able to read English any more until you realize that your only email is spam written in Cyrillic?

The mouth filter

October 4th, 2008

Sometimes I'll start to say something and then realize that it wasn't very interesting and shut up. This frequently annoys the people around me who will say things like "What? What were you going to say?" I'll say the thing that I was going to say and they will generally comment on the inanity of it. This seems rather unfair - if I didn't think it was inane I would have said it in the first place. You can have the filtered or unfiltered version of my comments but don't expect the unfiltered comments to be up to the standards of quality of the filtered ones.

The mosquito loop

October 3rd, 2008

Ever notice how, if you get a mosquito in your bedroom, it will sometimes buzz right by your ear? I suspect this is an evolved survival mechanism to check if you are asleep. If you're awake and they start sucking your blood, you'll probably notice and squish them. If you're not asleep it's almost impossible to avoid reacting when they buzz past your ear. So, as you're trying to fall asleep they will buzz past your ear every once in a while and only start to go for your ankles if you don't react.

Trouble is, some people (like me) are light sleepers and get woken up by these fly-pasts. This causes a loop as I start to drift off to sleep, get buzzed awake, swat the mosquito away and repeat. No meal for the mosquito, but no sleep for me either. Last time I got a mosquito in the bedroom I went through a few cycles of this and then tried to find it for a while and but eventually gave up and had to go to sleep in another room. The next day I found it on a wall and squished it.

Recurring dream

October 2nd, 2008

When I was a child I used to have this recurring dream. Actually it wasn't exactly a dream because I sometimes experienced it while awake as well. It was more like a feeling of fear and of "wrongness". Part of this feeling was centered around my fingers - they seemed to be too large to be able to do the things I wanted to do with them, but simultaneously too small to have an effect on the world. I wonder if this was part of my brain's getting used to the new sizes of my fingers as I grew. Another part of it was being chased downhill by a rolling boulder (and being unable to stop it because my fingers were too small, and simultaneously being unable to pick it up because fingers were too large and crude) only the entire scene was in 2D. It was very strange and even more surreal than a normal dream. Unlike most dreams, I can vividly remember how it made me feel even though I haven't had the dream for many years.

Stupid image resizing

October 1st, 2008

It greatly annoys me when web pages don't resize images properly. In particular, one thing that there seems to be an epidemic of at the moment is web pages that embed images at one resolution and then use styles like "max-width: 100%" in a column narrower than the image. This makes the images look horrible because most browsers (at least IE7 and Firefox 2) resize the images by just dropping columns, causing diagonal lines and curves to be all wavy. At least Firefox 3 gets this right and resamples the image but it's still a waste of bandwidth.

Along similar lines, here is an interesting article about the interactions between gamma correction and image scaling. I hadn't thought about that before (my own image resizing routines always just assumed a linear brightness scale) but this has definitely opened my eyes.

Escher metric

September 30th, 2008

When I learned about General Relativity at university I sometimes used to wonder if there was a metric in which this object could exist:

Penrose triangle

And be what it appears to be, i.e. the straight lines are (lightlike) geodesics and the corners are (locally) right-angles.

Initially, I imagined that such a metric might be possible without any sort of topological defect. In particular, while the triangle would look like the picture above when viewed "face on" it would appear to curve as you moved around it and examined it from different angles. While lightlike geodesics always look straight when you look along them from a point on the geodesic, they can still look curved when viewed externally. The photon sphere around a black hole is an example of a set of such geodesics thought to occur in our universe.

Thinking about it some more, I suspect something strange is going to have to happen in the middle of the triangle - if you try to shrink the triangle to a point, what happens?

Imagine being in this universe and travelling all the way around the triangle. I think that upon doing so, one would find that one had actually only turned through 270 degrees instead of the full 360 (and would also have rotated about the axis of travel). I suspect that this means that such a metric would have to have a topological defect (a cosmic string) passing through the center of the triangle. This would cause a discontinuity when viewing the triangle, so one would not be able to see the entire illusion in all its glory as it is shown above.

How to fix Microsoft

September 29th, 2008

My post yesterday kind of devolved a bit into ranting about how Microsoft's processes have the unindented consequence of causing the code to increase in complexity in the long term. This begs the question "how could Microsoft change to avoid this?"

Back in the 90s, Microsoft was generally considered to be an excellent place to work (much as Google is now). They still are to some extent but today that "excellent" means more "sensible" than "exciting". In the 90s, Microsoft was often described at having a culture that resembled a collection of many small startup companies rather than one large corporation. I think that was pretty much gone by the time I started working there in 2001 - by then it was very corporate (sometimes embarrasingly so). Meanwhile, startup companies are doing the kinds of development that Microsoft can only dream about, on tiny budgets.

Reading Paul Graham's essays about startups has given me some hints about how these startups can be so effective in the way that Microsoft can't, as well as why the ones that fail do.

There is a whole spectrum of corporate cultures, from two or three guys in an apartment at one end (let's call it the left end for the sake of argument) to Microsoft at the other (the right end). The left (when successful) is great at motivating their employees to do great things, rapidly prototyping and turning over problems quickly. The right is great at (eventually) producing very large, complicated, highly polished pieces of software, being consistent and avoiding risk.

To really be successful you need to work at both ends of the spectrum (and everywhere in between). The ecosystem of people founding startups, writing some great software and then getting bought by Microsoft (or Yahoo, Google, whoever) has done some pretty great things. But does Microsoft need all those startups to exist externally to itself in order to do the startup-y things? Perhaps not, if it can return to the culture it had in the 90s.

Startups need only a couple of things to exist - talented people and money. Both of these Microsoft has in spades. But they also need these people to be very motivated. Microsoft isn't a great motivator of people anymore - the difference in rewards between those who are putting in a reasonable minimum effort and those who are going all out is (in the grand scheme of things) small and it takes a long time of working very consistently hard to rise above the crowd. The average employee knows that it is very unlikely that they will ever be able to make a big difference to anything. Certain philosophical positions adopted by Microsoft mean that they are no longer highly regarded by the geeks that they need the most.

One thing Microsoft can do to revitalize itself would be to incubate startups inside itself. Allow employees to form small teams to solve some specific problem. If they succeed, they are rewarded with lots of money. Even if this approaches the amount that they might get from a successful startup this would probably be much cheaper for Microsoft than buying the equivalent startup, assuming a reasonably high success rate. These internal startups could even compete (especially if there are multiple approaches that seem promising).

These startups should be autonomous for the most part - they should be able to choose the software and programming languages that makes the most sense for them. They should not have to coordinate with other teams who might be doing similar things, or worry about treading on the toes of others. They should be allowed to concentrate on writing great software. Unlike startups in the real world, they won't have to worry about getting funding (just getting a first version working in the agreed upon time). They can have office space on campus or work in somebody's apartment if they prefer. If Paul Graham is to be believed, these factors will cause the success rates of these internal startups to be much greater than those of startups in the real world.

While the resulting software might not meet Microsoft's standards for security, localization etc., these things are probably better done at the more corporate end of the spectrum, by those employees who prefer the stability and "sensible"ness that you get with that corporate culture. The left will quickly produce imaginative, highly competitive software and the right will polish it to corporate standards - the best of both worlds.

The downside for Microsoft of this approach would be the drain of talent from the "classic" product units, and possibly also from the company altogether (if successful "startup" employees were rewarded with what Neil Stephenson describes as something rhyming with "luck you money"). But if that drain is happening already, maybe there's nothing to lose.

The search for simplicity

September 28th, 2008

There are several ways in which computer programming and physics are very similar. Possibly the most important is that both disciplines are, fundamentally, a search for simplicity.

In physics, we have a big pile of experimental results and we want to find the simplest theory that satisfies them all. Just listing all the experiments and their results gives you a theory of physics, but not a particularly useful one since it's not very simple and doesn't predict the results of future experiments (only the past ones). Rather than just listing the results, we would like to find a general theory, an equation, a straight line through the points of data which allows for interpolation and extrapolation. This is a much more difficult thing to do as it requires insight and imagination.

In computer programming, we generally have a big pile of specifications about what a program should do - maybe a list of possible interactions with the user (what they input and what they should expect to see as output). These might be encapsulated as testcases. To write a program that satisfies all the testcases, we could just go through them all one by one, write code to detect that particular testcase and hard-code the output for that particular input. That wouldn't be very useful though, as the program would fail as soon as the user tried to do something that wasn't exactly one of the scenarios that the designers had anticipated. Instead we want to write programs for the general case - programs that do the right thing no matter what the input is. When the "right thing" isn't precisely specified, we get to choose the output that makes the most sense according to our internal model of how the program should act.

I think a number of software companies in recent years (Microsoft in particular but others as well) have started to fall into the trap of writing software that concentrates too much on what the behavior of the software should be for particular (sometimes quite specific) scenarios, at the expense of doing the right thing in the most general case. Windows is chock full of "special case" code ("epicycles" if you will) to work around particular problems when the right thing to do would have been to fix the general problem, or sometimes even to explain that this is how we should expect it to work. Here is one example of this kind of band-aiding. I discovered another the other day - I was running some older Windows software in Vista and accessed the "Help" functionality, which was implemented an old-style .hlp file. Vista told me that it no longer includes the .hlp viewer by default (I guess it was a piece of the OS that doesn't get a lot of use these days, and they had just dropped it from the default distribution to avoid having to bring it up to the latest coding standards). I was pointed to the download location (where I had to install an ActiveX control to verify that my copy of Windows was genuine before I was allowed to download the viewer).

Part of the problem is that (at Microsoft at least) it's very difficult to make big changes. Rewriting some core piece of functionality, even if the programming itself is easy, would involve months of planning, scheduling, designing, specification writing, testcase writing, test-plan reviewing, management sign off meetings, threat modelling, localization planning, documentation planning, API reviewing, performance testing, static analysis, political correctness checking, code reviewing and integrating. And of course everyone whose code might possibly be affected by the change needs to sign off on it and put in their two cents about the correct design. And it must comply with the coding standards du jour, which change every year or two (so delay too long and you'll probably have to start all over again.) When you come to understand all this, the long gap between XP and Vista becomes less surprising (in fact, it's quite a surprise to me that it only took a little over 5 years, considering how many pieces were completely rewritten). All this process exists for a reason (mostly the politician's fallacy) but is rigorously justified and widely accepted.

Because it's difficult to make big changes, people tend to make little changes instead ("hey, we can work around this by just doing x in case y - it's just one extra line of code") - these don't require much process (usually just a code review - most of the rest of the processes for such small changes is automated). All these small changes add up to a great deal of extra code complexity which makes it very difficult for newcomers to understand the code, and even more difficult to rewrite it in the future because people will have come to depend on these edge cases.

Ray tracing in GR

September 27th, 2008

Following on from this post, a natural generalization is that to non-Euclidean spaces. This is important for simulating gravity, for example rendering a scientifically accurate trip through a wormhole (something I have long wanted to do but never got to work). The main difference is that ones rays are curved in general, which makes the equations much more difficult (really they need to be numerically integrated, making it orders of magnitude slower than normal ray-tracing). One complication of this is that generally the rays will also curve between the eye point and the screen. But the rays between your screen and your eye in real life do not curve, so it would look wrong!

I think the way out of this is to make the virtual screen very small and close to the eye. This doesn't affect the rendering in flat space (since only the directions of the rays matter) and effectively eliminates the need to take into account curvature between the screen and the eye (essentially it makes the observer into a locally Euclidean reference frame).

Another complications of simulated relativity is the inability to simulate time dilation. Well, you can simulate it perfectly well if you're the only observer in the simulated universe but this would be a big problem for anyone who wanted to make a relativistically-accurate multiplayer game - as soon as the players are moving fast enough with respect to each other to have different reference frames, they will disagree about their expected relative time dilations.

Lost camera

September 26th, 2008

I am having a wonderful holiday here on the Olympic peninsula. I will write more about it another time but I wanted to put this post up now for reasons that will become clear.

One thing has marred this holiday a little, though - we somehow managed to lose my camera on Wednesday. I think I left it on the table at the restaurant in Neah Bay, but when we went back to look for it a few minutes later there was no sign of it and the waitresses hadn't seen it. It's possible it was stolen (either from there or from our car) or that we left it somewhere else (maybe at the trailhead for Cape Flattery). I'm not too bothered about the camera itself (it was more than 6.5 years old and quite obsolete, it's battery low sensor was becoming confused and I was going to replace it after this trip anyway). We bought a disposable camera to document the rest of our trip but the most annoying part is the 2 days worth of photos (about 144 of them I think) that we've lost.

I'm posting this on the remote chance that someone finds the camera, looks through the photos and decides to try to locate the owner (i.e. me) by Googling keywords from the photos. The camera was an 3.3 megapixel Olympus C3000Z with a 128Mb SmartMedia memory card, a lenscap attached by a cord and a battery compartment with bits of tin foil and electrical tape to replace corroded contacts. On the memory card were pictures of a 1000 year old giant Spruce tree, another big tree (a dead Cedar with other trees growing out of its remains), various pretty pieces of scenery taken from rural Washington roads, vampire merchandise and vampire-related signs in Forks, driftwood at Ruby Beach and the beach at La Push, and lots taken at Cape Flattery (a woodland trail and some impressive seascapes and islands). The three of us (an adorable toddler, a man with dark hair and glasses and a woman with long dark hair) are visible in some of the photos - the toddler is riding in a green backpack carrier in the Cape Flattery ones.

I've subscribed to the Found Cameras and Orphan Pictures RSS feed in case they turn up there too.