You could use an “intelligent” selection tool to select the background and delete it, but you’ll probably be left with some remains of the background stuck to the outside of the icon. You could use a “colour to alpha” tool, but if there’s any of the background colour in the icon iteself then you’ll end up with a semi-transparent icon. If you’re smart, you could combine these tools and be pretty much there. But…

If you’re lucky enough, as I was, to have access the same icon appearing in a two of places against different backgrounds, you can use that to your advantage. After all, the background is simply whatever differ between each occurence.

In GIMP, I created the icon thus:

I cut out each occurence of the icon (background and all) to the smallest size possible without chopping any edges off, and pasted them both into the same image as layers. At this point the icons lined up with each other nicely.

The background is whatever differs between the two occurences, so I set the layer mode for the top layer to “difference”. Then I copied the resulting image to the clipboard and pasted it back as a new layer (on top).

The top layer now has straight black where the icon is, and some rather middling colours where the background is. I wanted to create a version of this layer to be applied as a mask to one of the original occurences. But that means I need straight white there the icon is, straight black where the background is, and shades of grey around the edges.

So I invert the colours. Now I have my white where the icon is.

Next I used curves to bring the background down to as dark as possible. I just dragged the bottom left of the line to the right, to the darkest point where data exists.

Ok the mask is ready. I copied it to the clipboard, and applied it as a layer mask to one of the layers holding the original occurences of the icon (it is converted to greyscal in the process). I made all other layers invisible, and made sure all layer modes were back on “normal”.

The final icon

The fix was pretty mind-bending: working with mysql locks, thinking about race conditions etc. I remember thinking I shouldn’t be struggling so much with this, and I should have this stuff down-pat by this stage in my programming career. Anyway, 3.5 hours later I had the fix.

Then today, I got a text from Facebook telling me a friend confirmed my request. And a split second later I got the same text. And a split second later, again, I got the same text. Then finally, one more split second later, the same text.

So it looks like the folks at Facebook are struggling even more than me! It’s nice to know that qBox does better than Facebook when it comes to accidental repeated texts!

What would be cool is a script that could recurse through a directory and include all the class files, in the right order so as to satisfy class dependencies – i.e., never include a class which extends a superclass, or implements an interface, unless that superclass or interface has already been included. Such a script would more or less obviate autoloading.

Luckily for me, I always keep my class file structure tidy:

• strictly one class per file
• class files are stored in subdirectories to match their namespace
• class files don’t do any actual work on being included, save to possibly initialise static variables

So I gave it a crack, and the result is a loadclasses.php, a file you can auto prepend (php -d “auto_prepend_file=loadclasses.php” -a) for a working interactive shell with all your classes loaded!

loadclasses.php:

function acin($name,$namespace) {
	if ( substr($name,0,1) == "\" )
		return $name;
	return "$namespace\$name";
}

function loadClassesInDir($dir) {
	$files = explode("n", shell_exec("find '$dir' -name '*.php'") );
	for ( $i=0; $i<count($files); $i++ ) {
		$file = $files[$i];
		if ( !$file ) continue;

		//echo $file;

		$namespace = str_replace("/","\",dirname(substr($file,strlen($dir))));

		$contents = file_get_contents($file);
		$interface = $clazz = null;
		if ( preg_match("/s+implementss+([\\A-Za-z_0-9]*)/",$contents,$groups) ) {
			$interface = acin($groups[1],$namespace);
			//echo " dependent interface:$interface";
		}
		if ( preg_match("/s+extendss+([\\A-Za-z_0-9]*)/",$contents,$groups) ) {
			$clazz = acin($groups[1],$namespace);
			//echo " dependent class:$clazz";
		}
		if ( $clazz && !class_exists($clazz) || $interface && !interface_exists($interface) ) {
			//echo " skip";
			$files[] = $file;
		} else {
			//echo " include";
			include $file;
		}
		//echo "n";
	}

}

loadClassesInDir("/path/to/classes");

Change the last line to point to the directory where your classes are stored. Repeat this line multiple times if needed, to cover all the directories where classes live.

Some caveats:

• You will have to get the calls to loadClassesInDir in the right order if one set of classes depends on another
• Hasn’t been completed for multiple interface implementations
• I’m using the find command – should still work on windows but you’ll gnu find or similar installed, or you could write the pure php version with opendir();

select mytable.*, case
  when birthdate + interval year(current_date) - year(birthdate) year > current_date
    then birthdate + interval year(current_date) - year(birthdate) year
  else birthdate + interval year(current_date) - year(birthdate) + 1 year
  end as next_birthday
  from mytable;

(bold text means field and table names to be replaced)

Today I thought I’d fire off a query to get customers next birthday, to send them a birthday reminder if it’s coming up. I quickly became aware of some caveats.

Most obviously, you can’t simply compare the birthdate timestamp with the current timestamp because every customer’s birthdate is in the past. You have to somehow ignore the years.

Use of MySQL functions to extract the day and month from the birthdate would have to be used with caution if the end of the month was approaching (among other assorted boundary issues). Any use of the day of the year function is also tricky because on a leap year the days are all out by one after March 1st. I didn’t want people born on February 29th to get an email every four years!

But after some tests, I found that if I found the correct number of years (n) to step forward from the actual birthdate, then birthdate + interval n year always gave the correct result. If a customer’s birthday is February 29th, you would get result like 2011-02-28 or 2012-02-29. The value of n is, or course, the current year minus the year of the birthdate, or that plus one if their birthday has already been this year (see above).

if (a > 0 && b > 0 && a + b < 0)
      throw new ImpossibleException();

In other words, what two positive integers add to a negative number? Of course, there is no such pair.

Unless you ask C#, where a = 2147483647 and b = 1 will trigger the ImpossibleException (no ArithmeticOverflowException or similar) . And the sum of a and b is apparently -2147483648.

Among many implications is the fact that in C#, this loop:

for ( int i = 2147483647; i <= 2147483647; i++ )
{
    …
}

is the same as this loop:

while (true)
{
    …
}

This extends to the rest of .NET, plus Java, PHP, C++ - like the recent Java and PHP Bug which causes a crash when converting the number 2.2250738585072012e-308.


What a laugh!

The basic approach is, instead of going the normal route and striving for a program which is highly configurable and flexible, I write a program which is totally inflexible. There are no installation options or preferences pages, no complex user database, and usually a just a basic user interface. The program does what it does and that’s it, unless I change the actual code of the program.

Obviously, this saves time because there is less code to write, but it goes even further than that. What I’ve come to realise is that the features of the program need to be very well defined before you can give them good configuration options. OK, sometimes it’s obvious: a feature that calculates GST would need a configuration option for the GST rate. But when it comes to a feature that calculates the PAYE for overseas employees, it’s not so immediately obvious what the right configuration options would be.

Also, the features can’t be too likely to change in the near future or all the work that went into making them configurable will have to be thrown away. Clarifying and finalising requirements is a big job, but as long as I’m happy with a completely unconfigurable program, I can skip this job too.

And without exception, when I start coding, I don’t have a crystal clear picture of where I want the software to end up. Personally, I like it this way. Having loosely defined requirements simply means I’m not ready to commit to something until I can see it working and be sure it’s the right fit. Changing my requirements often means I can always have that new feature, and get a competitive edge over people stuck on rigid software. Two big advantages, and development is sped up to boot!

So I asked myself, why couldn’t I pass these advantages onto my customers?

In other words, what if the programmer created a very inflexible program for a client, for a very reasonable price, but make his/herself available to change it whenever necessary? You could call it “Programmer-Available Software Development” (PASD), because the programmer gets involved on a fairly regular basis. Would PASD really work for the customer?

The first obvious problem is that whenever the program needed even the slightest change, including such trivial things as a change in the tax rate, the programmer would have to be called in. This could get costly for the customer and it would probably turn out that a configurable program would have been more economical overall.

Another problem is that realistically the software could only be given to one customer, and limited to single instance. If multiple copies of the software were set up, they might each evolve in different ways. If there were four instances of the software, each with its own special way of calculating tax, then that’s four different sets of source code. This creates a maintenance problem which would need to be handled carefully by the programmer, and could waste a lot of time.

But there are some circumstances where PASD is perfect for the customer. Namely, it’s when requirements are unclear, and far from finalised.

If the behavior of the program is changing faster than the mere parameters, then you might as well stick with a totally unconfigurable program and have the programmer change the parameters as part of development, since they’ll be working on the software anyway. Why go to the hassle of setting up a preferences page for the tax rate, when tomorrow the software might be automatically looking this value up on the internet or to getting it from another program? It just doesn’t make sense to go to the expense of creating a highly configurable, flexible program when the requirements are in flux.

So when should you clarify and finalise the requirements? The answer is above: when you start wanting to configure the software often, or you want to deploy multiple copies. And one of the great thing about PASD is that it gives you a demonstration of the software in action before this time comes, which should give you the confidence to provide clear and finalised requirements and be sure they will work for your business.

Of course, if you don’t need to configure the software that often, and you’re happy with a single instance, then you could stay on PASD indefinitely.

PASD software can be put to work from a very early stage. In fact, my advice is to make the software live and start using it as soon as possible so you and your staff can start to benefit from it, as well as thinking about additional requirements for the software. There’s nothing like using the live software for identifying those special cases which require a special behavior, or thinking of new features that could save you time in your daily routine.

You could characterise PASD as an even more extreme incarnation of agile software development. Whereas agile development might see programmers and customers have scheduled weekly meetings, PASD puts the programmer on call to respond to the customers request the very next day, or even on the same day. Whereas agile development might see the customer testing software in a test environment, PASD makes the software live so the customer can use it on real data. And whereas agile development says nothing about the flexibility of software, PASD dictates that the software stay very concrete, either indefinitely, or until the customer is ready to give clear and more-or-less final requirements.

Mid 2004
Created the original BASIC version. Points were defined in three arrays (point_xs, point_ys, point_zs) holding coordinates, and lines in two (line_froms, line_tos) holding the indicies of points to link. Rotation was done by passing in two coordinates at a time to a rotate function. E.g., pass in the x and z coordinates to rotate around the y axis. No concept of a camera; everything was rendered around the origin (offset to the centre of the screen).

The rendering was very simple: just render the points based on their x and y coordinates, and ignore the z coordinate. I thought about adding perspective by pulling points with higher z values closer to the origin, but never got to it. Rendering the lines was equally simple: just use the line function to draw a straight line between the final computed coordinates of the points in question.

Original spinning heart output

One very interesting bug I got in the original version had the spinning objects crumpling in on themselves. My spinning heart, for example, would start spinning fine for maybe 1/4 of a revolution, then some of the points would start to twitch, getting a little closer to the origin each time. Then all of a sudden, all the points and lines would head straight for the origin and the entire shape become a singularity at the centre of the screen.

The problem was (if you haven’t guessed) that I was allowing computation errors in the rotation to compound. I should have kept the original set of points around in memory, stepped forward from 0 to 360 degrees, and rotated a clone of the points by that amount each time. But instead, I was simply looping without a counter and rotating the master copy of the points by a degree each time. Each time the object was rotated, the x and y values came back a little low, so eventually all x and y values hit zero.

Late 2006
Ported the code to Java, my favourite language of the time. The code remains Java-based to this day.

November 2008
Added support for polygons. In the same spirit as the line support of the original version, I just called Java’s Graphics.drawPoly() method on all the connected points (which I renamed to Nodes).

Invented a “camera”, with position plus yaw, pitch, roll. Basically this just offers an object to store information about what offsets and rotations should be performed before rendering; the first step to rendering a frame is to bring the focus to the origin and rotate the space so we’re looking straight at it.

I also created a file format for the “spaces” being rendered. A simple text format to define nodes, lines, and polygons. Lines and polygons now require RGB values to define their colour. To future-proof, I also allow definitions of lights including position, colour and intensity, which remains unused for now.

Rendering remains the same, but with perspective added based on a perspective factor. Perspective is added by multiplying the x and y values by the perspective factor raised to zero minus the z value. A perspective factor of about 1.004 seemed to be the most agreeable, at least with the sizes of object I was working with with a width of about 100 units (pixels).

To create some sort of lighting effect, I dimmed polygons by the sine of their angle with the camera. This way a solid green cube rotating randomly did not just look like a square morphing into a octagon, but gave the illusion of a shaded cube.

Demo of the polygon support and lighting effect.

I got some weird results when certain assumptions were violated. My code never checked that all nodes in a polygon were in a plane. So, just for fun, I decided to define a polygon with nodes that weren’t in a plane. First I defined two parallel polygons in the shape of a 2D heart, about 100 units wide and separated by about 20 units. I confirmed that they rendered okay. The first had nodes “a, b, c, …” and the second “a2, b2, c2, …”. Then I made them a single polygon, which broke my assumption, by simple using all the nodes from both polygons: “a, b, c, …, a2, b2, c2, …”.

I watched the shape rotate, and the result was an optical illusion. When the angle was near enough to straight on, it looked like ribbon in a heart shape. But when rotated around you thought you might see the full width of the ribbon, suddenly you’re looking between two 2D heart-shaped polygons. Then, just as suddenly it seems to go back to the ribbon.

Parallel hearts optical illusion

This got me thinking about how the brain resolves unexpected light and shadows. Nothing on the screen was changing suddenly, yet my interpretation was changing very suddenly as the object rotated. Even while in one interpretation, you could see evidence that something was not quite right with the object, but it was small enough to ignore. That is, until the small flaws took over and my interpretation shifted again. It also got me thinking that, while the usual aim of graphic design is to present veridical, realistic graphics, it could also be used to present stimuli that could not possibly be created by objects in the real world.

December 2008
Started on real ray tracing. At this point I did not know what the term “ray tracing” meant, but since the beginning of the whole process (2004) I thought it would be a great idea to try to render a scene by bouncing virtual photons off my virtual objects. Up until this point I was doing what I call “direct” rendering, that is, figuring out how to transform the nodes in a scene to change the angle and simply drawing lines or polygons between those points. Bouncing virtual photons around would be a whole different approach: the link between the internal model of the scene and the final rendered image would be less explicit and more natural, with the final image being less of a representation of the model and more like and “impression” of the scene on a virtual film.

These ideas had been incubating for a number of years by now. For example, I thought that if I used virtual photons, then perspective would take care of itself; distant object would appear smaller because the photons they reflected would hit my virtual lens at angles closer to parallel. I knew from high school science class that most objects diffuse light, so I knew I would have to assign each object such a “scatter factor”. A mirror would have a scatter factor close to zero, and a matte object like a piece of paper would have a high scatter factor. Similarly I’d need to give my objects absorption and transparency factors too. I expected to see cool lighting effects and even to encounter depth-of-focus effects associated with real lenses.

My plan was to take a lead from the real world (or at least my understanding of it). I’d put lights in the scene (represented by a vector for position and an intensity) , as well as a lens (represented by a vector position for the center, a vector normal for its direction, and a radius) and a film (a plane parallel to the lens and set back by a given distance). I’d create some necessary geometry utility functions to find things like the intersection of a line and plane, or to tell if a point on a polygon’s plane was actually inside the boundary of the polygon or not. I’d set up a loop where each light fired off a photon at a time, and it was bounced around the scene until it hit the lens or disappeared into the blue yonder (which was actually rendered black).

I started coding, reading articles on the web, writing unit tests for my geometry functions, watching debug output in both text format and as pixels on the screen. I wanted to get something up and running as soon as possible. Finally I had completed all the elements of my basic plan…but it still did not work at all how I’d hoped. The pixels were garbled. I was able to see some evidence that I was on the right track, but I was at a loss as to how turn a lot of noisy pixel into a pristine image. Here’s one of the better looking images I saw, of three 2D cards side by side right in front of the camera.

Left: Garbled output from an early attempt at ray tracing. Right: the same scene rendered with the original system.

Some things to notice from these images: Firstly the ray-traced image is inverted compared to the directly rendered image, which proves the virtual lens is working at least somewhat. Even around the center of the cards there are some missing pixels, which is what you’d expect since I had (as yet) no system to ensure every pixel got a hit. The pixels are more concentrated around the center of the cards, which is promising but at this stage I wasn’t sure if I was seeing a lighting effect, a lack of focus, a bug in my maths, or a combination of all three. The edges of the cards blend into each other, which suggests faulty maths or a lack of focus, but I was sure I’d positioned the film the right distance back from the lens to achieve sharp focus so that only left faulty maths. Sure enough, that’s what I’d eventually find to be the case.

September 2010
Had a 20-hour hackathon where I tracked down and corrected most of the faulty maths in the system. With my wife away at an executive retreat, I finally had the time focus required to review each part of the system and really make sure it was doing the right thing under all conditions. Previously I always felt like I only have a limited amount of time to fix it, which prevented me from going down paths of investigation that really needed to be explored.

As well as going over every part of the system, I also threw away some parts. I had the brilliant idea (which I should have had from the start) of using a simple pinhole camera approach rather than a complex lens-based system. By now I was well aware that, to guarantee each pixel gets a hit, conventional ray-tracing is done from the camera to object to light rather than the more natural light to object to camera. So, I switched to this approach.

I rapidly found and fixed bugs, edging forward by turning messed up images into cleaner ones. Here’s two shots of three cards again, this time viewed from an angle.

The first image shows a bug in the function that checked if two points were on the same or opposite sides of a line. After I fixed the bug, I got the second image. Other things to note here: I only rendered every fourth pixel (to save time) so you do still get missing pixels in the output, the gaps are just uniform.
The mixing of the colours in the first image was seemingly random, which I really didn’t expect. Even faulty maths, I thought, would result in pretty well defined errors, not random mixing like this. But I guess that’s just one of the properties of bugs: they can do anything.

Also, the perspective is very apparent, which proves my hunch that perspective would take care of itself. In fact, the perspective was way too extreme, but I quickly figured out what settings to change to control this (namely that the camera needs to be further away from the object, and the film set back more from the pinhole). Finally, you can’t tell by looking, but these images were a lot quicker to render than the previous ones. This is because of the backwards tracing (from camera instead of from the light source). I no longer had to wait and hope for each pixel to get hit, I could guarantee it because I looped over each pixel and tried to get a hit.

In this one I rendered a blue cube with the camera inside it, and I move the light source from one side to the other to watch the lighting effects. The whole movie took about half an hour to render.

You’ll note some that some of the objects appear to have “belly buttons”. That’s a residual bug that I’m actually still working on. It has to do with a shortcut I took on calculating the directness with which a photon hits a surface. More to come on that…

I also added some more code to handle spheres. This turned out to be surprisingly simple in the context of ray tracing. Until now the only thing that could be rendered was a Polygon. So, I looked at how the renderer was interacting with polygons and wrote an interface, called “Thing”, to describe it. I managed to distill it down to three main functions: Polygon.getPointsOfIntersection(line), Polygon.getReflectionPlane(point) and p.getColor(). Then I changed the rendering code to work only with “Things”, and removed all mentions of the Polygon class from the rendering code and confirmed it still worked as before (which it did).

Now that I had the Thing interface, I could render any 3D shape just by implementing its getPointsOfIntersection and getReflectionPlane methods (and getColor of course, but that’s easy). For the sphere it was very simple.

Here are some demos of the spheres.

Again, the spheres have navels, and some are worse than others. Also, there are some obvious edge effects here: black dots appear at the joins of the walls when the camera is facing straight on. The spheres fade to black way to harshly – just shows that it’s not about all hard maths, it’s also about fine tuning settings to make something look acceptable to the human eye. (Ignore the jpeg and mpeg effects, they’re not really in the rendered images).

Here’s a really crazy bug I saw. This has to do with maxing out the brightness of colours when using Java’s hue, saturation, brightness (hsb) colour functions. I had code to adjust the brightness of colours by converting rgb colours to hsb, changing the brightness, then converting back to rgb. Brightness is expressed from 0~1 with 1 being the brightest, and my code was attempting to set the brightness to much higher numbers like 0~1000. I knew full well my code had this fault, but I was too excited to think about how to normalise the brightness values so I figured I’d just run it let the brightness saturate. But rather than saturation I got this:

I’m just guessing, but it looks like Java’s colour function wraps around at brightness 1, so instead of a really bright image, I got layered gradients. Doesn’t explain the presence of other colours in the middle of the walls though…

Really hippy output resulting from a brightness bug

Well, that’s all I have for this post. My next posts on this will be a lot shorter and will probably have more images that look similar to each other as I expect to post about particular points and concepts, and subtle differences between different techniques. Keep watching!

Input filtering, as I see it, is about the quick (and possibly dirty) extraction of information from incoming data. It’s about turning the rapid flow of data into a comparative trickle of high-quality information, which itself becomes a data stream for higher-level subsystems.¹

Filtering input is not about simply ignoring data; if we wanted to do this we could simply use fewer sensors. Consider an agent connected to a high resolution digital camera. It is true that, to reduce the current of the incoming data stream, the agent could discard or ignore the values of certain pixels. For example, it could ignore the outer edge of the frame and consider only the center, or ignore every second pixel to achieve a full but lower-resolution view. But, discarding input is equivalent to simply using poorer sensors, so does not gain the agent any advantage over simply being fitted with these poorer sensors in the first place.²

What filtering input is about is taking what information we want from some data, and then discarding that data. With the data goes a lot of other information which we could have extracted, but which we can do without. To return to a vision example, consider my old 640×480 webcam, which provides 307,200 pixels per frame. Each pixels requires 16 bits to encode, and the camera can serve 15 frames per second. That means my camera provides 70.3Mb of data per second, which is a lot.

Now imagine this camera connected to a hypothetical AI security system for detecting intruders, the Securicam5000. Inside the Securicam5000 is a subsystem which detects the degree of change from one frame to the next. For every frame, this subsystem provides a 4b message to whichever other subsystems need it, to say how much the frame differs from the previous one on a scale of 0 to 15. (Let’s assume for now that the designers have established that the degree of change from frame to frame is relevant to the overall goal of detecting intruders.)

What our subsystem achieves here is to filter the input. If the Securicam5000 was fitted with a whole array of similar input filtering subsystems, then the actual incoming data (all 70.3Mb per second of it) could be discarded once the relevant information had been extracted. Even if there were one hundred input filtering subsystems in the Securicam5000, each contributing on average, say, 10b per frame, that’s still only gives a 14.6Kb/s trickle of information to be passed to the higher-level subsystems. That’s a rate of almost 5000 times less than the raw input stream, which is much more manageable for a processor of limited speed.

As Sherlock Holmes gathers data about a case, he often gets to a point where he has all but solved the case and starts looking for the final evidence against his number one suspect. Meanwhile, Dr. Watson (and the reader) has no idea how Holmes can be so sure he has found the best lead. To the non-detective, ruling out some of the other suspects seems foolish and dangerous. But it is Holmes’ power to identify and discard irrelevant information that frees up his mind to deduce who did it.

For example, say Holmes’ client said he saw the servant admiring the painting late one night, but Holmes observed that the servant lacked the intelligence to successfully sell the painting. Holmes can throw away the possibility that servant stole the painting and even remove from his consciousness the distracting anecdote about the servant’s suspicious activity. Meanwhile, Watson grows more confused with every new piece of information, and suffers from information overload.

I believe that the visual system and other systems in the brain must do something similar to what Holmes does in his detective work, but subconsciously. To cope with a stream of data even greater that that of my old webcam, or any modern digital camera for that matter, the raw video data must be converted into a slower stream of simple information: presence of a curve here, presence of some lines there, lots of blank space. This data is more manageable by the later stages of the visual system, which in turn can produce a simple internal model of what exists in the world: a hot cup of tea to my right, and a pen and paper in front of me, and blue skies above.

In turn, my highest-level subsystems can take this model and play with it, and forget about the raw visual data from which it was extracted. I reach for the teacup because my internal model tells me it is there, not because I have consciously and painfully processed screeds of visual data and deduced that a teacup must be there – no system on earth could actually process so much data so quickly.

As I said previously, filtering input is not about simply ignoring data. To blank-out every second pixel on a camera, or in the human case every second rod or cone on our retina, would be as foolish as Watson trying to combat information overload by ignoring every second fact of the case. Firstly, this would be harmful to Watson’s ability to solve the case. And furthermore, this butchering of the input only achieves a data reduction of 50 percent, where the kind of reduction needed is likely to be far greater than that. We cannot throw away data indiscriminately and expect to be better off.

The question arises then, how do we know what information to keep and what to throw away. The answer will, of course, depend on the particular problem you are trying to solve. In the domain of triaging patients complaining of chest pain, Lee Goldman was able drill down to to exactly four pieces of relevant information: whether the patients ECG is normal, whether the pain is unstable angina, whether there is fluid in the patients lungs, and whether the patients systolic blood pressure is below 100. He achieved this by applying statical methods to years worth of patient records.

In the case of human vision, one might argue that it is evolution which has equipped the visual system with knowledge of what information is relevant and what is not. In the hypothetical example of the Securicam5000, the designers decided, using their expert knowledge, that how much the input changes from one frame to the next is among the information relevant to the problem of detecting intruders. Judging which information is relevant is a matter of carefully thinking about and experimenting with the problem you are trying to solve.

¹ It may appear I am equating data with information, but this is not exactly my intention. I am using the data/information distinction like a north/south distinction. Anywhere you stand, north is on one side of you and south on the other. For any AI subsystem you look at, data comes from one side and information goes out the other; so one subsystem’s information is another subsystem’s data.

² However, one could imagine an optimization process where a high resolution device was used in a series of tests, ignoring different input in each test in order to find the minimal set of sensors needed for a particular agent in a particular environment to achieve a particular task.

This is a book about the first moments of any encounter. It explains the amazing ability of the subconscious mind to infer a wealth of information from even the thinest slice of experience. Experts can spot a fake statue within seconds of seeing it, predict the success of a marriage by watching a couple chat, or identify a bird after a sighting of only a few seconds at great distance. We can all tell if we like someone in the first few minutes of talking with them, and we can tell what a person is thinking by looking at their face.

Gladwell explains that our snap judgments are very powerful and surprisingly accurate – often more accurate than a reasoned decision. He then gets into they ways our subconscious can get it wrong, and the danger of acting on snap judgments of the wrong kind.

This was a very satisfying read. A lot of research has gone into the book, and it is presented in a compelling way which interweaves talk about different studies to get the point across most effectively. Whatever profession you’re in, this book has the potential to change your way of thinking about your work, and to get you using a better combination of reason and instinct.

This book relates very directly to my AI research. I believe that any AI system operating in a complex environment, being that it would have limited computing power, would need a subsystem which filtered the incoming sensations (data), essentially blanking out certain information. Only in this way could the system keep up with processing the data as it came in. I have wondered if the loss of such information would be damning to the systems ability to make good decisions. But I feel the conclusions put forward in this book give hope to the possibility that it would not.

This book also made me think about the vast difference, and occasional similarities, between conscious and subconscious thought. Currently the most successful AI tackles problems which humans would apply conscious thought to, like diagnosing a disease or playing chess. AI has had less success with problems humans use subconscious thought to solve, like identifying an object or walking across a room. The gap between the two areas is vast, with chess AI performing at super-human level and the most expensive mars explorer having less intelligence than an insect. But, though vastly different, the two areas also seem to have something in common.

In the book, Gladwell talks about an algorithm devised by a doctor for triaging patients complaining of chest pain. Just as I thought he was about to conclude that no simple algorithm could take the place of a subjective examination by a nurse, he concluded the exact opposite: that the algorithm could outperform the nurses even though it took only a handful of factors into account. It turns out that the intuition of the nurses was not required, and that (by analysing years’ of data) their entire decision making process could be distilled into a simple algorithm that takes four true or false inputs and produces an output of “high-risk”, “medium-risk” or “low-risk”.

We usually think of instinctive activities like walking and seeing as involving a very fast flow of incoming data (compared with conscious thoughts which deals with a few elements at a time). But I think the story about this algorithm reiterates that we don’t need most of this data and that we are best to carefully throw away the irrelevant information and let only the relevant information reach the “decision making machine”. This makes subconscious tasks seem a lot more like conscious ones.