July 2011 Archives

Available from iTunes or the BBC website or the British Museum website.

Originally broadcast on BBC radio, A History of the World in 100 Objects is an epic series attempting to describe all human history via the stories of a 100 carefully selected objects from the British Museum. The complete list of objects is available here. There are 100 episodes (one per object), each around 14 minutes long and 6.5 MB in audio only MP3 format. They are all produced to an exceptionally high standard. More information on each object is available online at either the BBC or British Museum websites and many can be seen on display at the museum.

Each episode is presented by Neil MacGregor (the Director of the British Museum) and introduces the object before proceeding to it's historical context. Sometimes this is the method of its creation or it's usage or it's passage through time. For instance, episode 90 details a jade Bi originally crafted in the bronze age, but now with a poem carved into it by the Chinese Qianlong Emperor around 1790AD, is used to illustrate "Exploration, Exploitation and Enlightenment" in the 18th century. Sometimes there is also a discussion of the object's meaning to modern viewers, like the homosexual scenes displayed on the Warren Cup in episode 36. The objects are from across the world and time although cultures that left objects of a more durable nature and written histories feature more regularly. Hence most of the objects are from Europe and Asia. while there is a single object from Australia. The cliche may be that the victors' write history, but this series suggests history is written by those who actually manage to write it at all - especially if written in stone or metal.

Despite most human-made objects being created in the last century or so, the chosen objects are distributed reasonably evenly over time. It takes 35 objects to reach 1 AD and another 21 objects to reach 1000AD. The object's are presented in chronological order, but organised into a groups of 5 by a theme describing the broad brush stroke of history at that point in time. The first theme is "Making Us Human" (2,000,000 to 9000BC) and the last "The World of Our Making" (from 1914 to present). Inbetween there are topics like "The Beginning of Science & Literature" (1500 - 700 BC), "The Rise of World Faiths" (200 - 600 AD) and "The First Global Economy" (1450 - 1600 AD). It would take a particularly indifferent listener not to find a couple of interesting stories among the series.

There are far too many objects to discuss them all, but here are some I found noteworthy. Object #15 is an early writing tablet detailing beer rations for workers. It seems writing is likely to have started for the utilitarian purpose of accounting, only later being used for fiction. A jade axe made in Italy but found in Britain (object #14) and a Minoan bronze (object #18) made with materials from the Middle East, demonstrate that long distance trade routes existed over 3000 years ago. Then there are the cultures previously unknown to me, like the Moche (object #48) and the Huastec (object #69). This was even the case within Europe with the Kingdom of Lotharingia (object #53), precariously squeezed between early France and Germany (and soon swallowed by them). There are also pottery shards from Kilwa, Tanzania (object #60), evidence of medieval cities and trading posts along the east African coast. The series ends with a credit card (object #99) and a solar powered lamp & mobile phone charger (object #100) - a good choice for the current world and an optimistic look towards the future respectively.

After honours I was offered a government scholarship to study for a PhD. This was the standard way of financing postgrad study, all the other PhD students in the UWA CS department had the same scholarship. I started the PhD in January 1996, but by September 1997 I had deferred the scholarship, started looking for a job and unofficially quit my studies. The official end came 6 months later when the scholarship was rescinded and a letter arrived saying "don't ever come back" (I paraphrase). I don't regret that year and a half. I learnt a great deal about logic, a little bit about programming and substantially more about the world outside of computer science - all paid for by the Australian taxpayer (thanks guys!).

Joel Spolsky has often blogged his opinions on Software Architects. Those people who design whole software environments and their tendency to become astronauts (that is divorced from the realities on the ground). I have a great deal of empathy with his view. Grounded architects may have some use in large companies to set a general technical direction and aid communication among independently working teams. In smaller groups there is no need for them, yet they often appear. Recently I have worked on small teams of 5-10 developers with 10-20 tasks that need to be done immediately. At these workplaces there has been a focus on getting things done and we have all handled our own design, relying on professionalism to keep us all moving in the same direction. So luckily I have avoided Software Architects for many years, but my luck is running out - I have just encountered people ready for take-off.

I have some empathy for the architect - just a little. I used to have designs on being an architect. I wanted to do things the "right way" (in quotes because it is always a matter of opinion, with many caveats). For a technical person it seems like the place where you can have the most influence. It is also part of the informal software development career path, on which I was once travelling. However, as I enjoy programming I would help code my solutions. Thus I encountered the problems that occur when abstract perfection meets messy reality. Solving the problem has to come first - to paraphrase Jeff Atwood the architecture should be framed in the context of the problem.

Now I think the first priority should be solving the clients' problem. For the last 6 years or so I have chosen workplaces that emphasise "getting things done", especially since timescales are always tight. One can make the argument that it takes time to do things right and we should take that time. That is true, and if that is hugely important you should probably work someplace else. Where I currently work, our original project was to create a complete European government bond trading platform in around 3 months. The market opportunity was fading fast and costs were increasing. If an extra year was taken to produce a technically beautiful solution the result would be useless as the investment wouldn't be recouped in a reasonable timeperiod. Corners had to be cut and they were, but we delivered on time. Now when time allows we can refactor the system into a better state.

The current architect wannabees I have encountered are ranting that the reason they can't get their job done is that our environment is crap (despite being part of the team that created that environment). It needs to be ripped up and started again the "right way". They produce eloquent arguments for beautiful service-oriented architectures. While I agree that their vision is better than our reality, it in no way reflects our reality. Worse, they are not very good coders, and they use our "wrong" but working environment as their excuse for their messy, buggy code. When given the chance to rework something from scratch without dependencies on other components they still produce buggy, messy, unreliable code that no one wants to use and took 4 times as long as the original working version. This has happened not once, but twice! As a result, we are further from the right way as we have to cover the other person's unfinished work and fight their new code, leaving us less time for refactoring. Yet still they continue, it will all be better if we just do everything their way. Personally, I'd rather just solve the problem at hand - which at the moment includes them!

Just had to get that off my chest.

The worst question you can ask a PhD student is "tell me about your thesis". Or at least, that was the joke among the postgrad students at the UWA CS department in the mid 1990's. I took this seriously and prepared an explanation of my thesis that I thought most people could understand (assuming some small knowledge of logic). I only ever used this explanation once many years ago (at a job interview for Rio Tinto R&TD). So it is about time I explained it again before I forget it all. For reference I did not complete my PhD, dropping out after 18 months.

The provisional title of my thesis was "Using Nonmonotonic Logic to extend Inductive Logic Programming", and the research proposal is here. The idea was to have computers learn logical rules in a more natural manner than the existing systems. First some background on each of the two terms in the title.

First-order Logic is what most people mean when talking about logic. It involves formulas like flies(X) <- bird(X) (all birds fly), which if you also have bird(Tweety) (Tweety is a bird) implies flies(Tweety) (Tweety can fly). One issue with First-order Logic is that it assumes perfect knowledge. That is, it assumes that everything is known and correct. Thus it is monotonic - it is not possible for any future information to invalidate any previous implications. It can't handle the situation where in addition to the knowledge above, we later learn that Tweety is a penguin and that penguins don't fly. This new information invalidates our old implication that Tweety flys and is not allowed. Instead you have to know from that start that birds fly unless they are penguins. However, Ostriches don't fly, nor do dead birds or birds with broken wings. With a little bit of thought many more exceptions to the rule "birds fly" can be imagined, and the rule becomes unwieldly.

In real-world problems there can be many exceptions or inconsistent data (noise), so First-order Logic can be problematic for machine learning. There are ways around this though. Often it is used in self-contained well-understood domain with few exceptions. However, many systems instead use Non-monotonic Logic, which allows new knowledge to contradict old beliefs. Many Non-monotonic Logic constructs seem so intuitive it is hard to imagine thinking without them. The Closed-world Assumption says that if something is not known it must be false. When reading a train timetable with a train at 8am and the next specified train at 9am, you are using the CWA when you assume there is no train at 8:20am. Similar is Negation As Failure (indeed it has been proven they are logically the same) where if something can't be proven true then it must be false - sounds like a few university researchers I knew. If you have used Prolog, then you should be familiar with NAF. The logic I was mainly working on was Default Logic, which allows rules to be true by default assuming there is some justification. This allows exceptions in a compact and natural rule system.

Given the rules resulting from the learning system would be in a Non-monotonic Logic, the next step is to describe how those rules are learnt. The example above where it was implied that Tweety could fly is an example of Deductive Reasoning. Deduction is the process of using some rules and some background facts to imply new facts. Inductive Reasoning is the reverse, deriving rules from facts. So if you know Tweety is a bird and that Tweety flies, then you might derive the rule that all birds fly. Inductive Logic Programming is just the term for computer programs that perform this process with the resulting rules as logic system. They take a set of background knowledge and sets of positive and negative examples and try to create rules that cover as many of the positive examples as possible while covering as few of the negative examples as possible. This is a computationally expensive process, computers only got powerful enough to do this for non-trivial datasets in the late 80's, so when I studied in the mid 90's the field was just getting started and becoming known.

My thesis attempted to marry the two concepts. There had been a few attempts at this before, but the best known ILP systems at the time didn't handle exceptions or noise very well. Thus part 1 of my work was to construct an ILP learning system that output a Non-monotonic logic. This was about as far as I got, implementing some theoretical results from another researcher (with minor improvements). Part 2 was handling exceptions and noise better by flipping rules. That is, if the evidence against a rule became too strong the system should flip it to the reverse rule. I also looked at weakening the "strength" of a rule over time. All rules have the same applicability in non-probalistic logics. By "strength" I mean how long I keep a rule in my output theory before modifying or flipping it in the presence of negative examples, or even ignoring exceptions/noise if the rule is particularly "strong". I didn't come up with anything meaningful here, I just thought it might be useful. Although I have been told this became a hot research topic in the years after I quit (under the term "forgetting", I think).

This may sound like it was mainly a coding project, maybe because that was where my interests lie. Most of my time should have been spent doing maths to prove my work was correct as it was a very theoretical field.