When can I expect dinner?

Imagine that I am driving from my in-laws house in Ashburton to my own house in Christchurch and that afternoon is waning closer and closer to dinner time. (Recently, this really happened to me.) I start to wonder: how much time do I expect between now and dinner? At first glance, this is an innocent question that can be mentally approximated with enough accuracy to be useful. I can formalise the process happen in my head by expressing the expected time until dinner as the sum of the delays caused by events that may occur between now and dinner (Eq. 1):$$t = \sum_{e \in E} p(e)d(e)$$where \(t\) is the time until dinner, \(E\) is the set of all possible events between now and dinner, \(p(e)\) is the probability that event \(e\) will occur and \(d(e)\) is the additional delay caused by event \(e\). The probability of each event depends on my own choices so I can use Eq. 1 to run 'what if' scenarios in my head. If I choose to stop my car by the side of the road, then I expect dinner to be later than if I continue driving at the speed limit until I reach home. On the other hand, if I stop at a cafe along the way, then I am likely get tea sooner. In general, I only need approximations that are accurate enough for making decisions in life, and I need not worry about the precise philosophy of mathematics that stands behind the approximation. But there are hidden catches in Eq. 1.

Suppose a drunk driver going south swerves onto the wrong side of the road and kills me in a head-on collision. (Keeping to one's side of the road is a life-and-death argument for multi-agent coordination!) This event has non-zero probability of occurring before my dinner time. But for the purposes of  Eq. 1, how long would the event of my death delay my dinner? Because I never get dinner, arguably the delay \(d(\textrm{my death})\) is infinite. But even one infinite delay paired with any non-zero probability means that the expected time until my dinner is also infinite. If I claim that the 'real answer' is always infinity, then I lose the ability to make judgements based on my calculations; the expected time until dinner is the same if I drive home at 10 kilometers per hour over the speed limit or if I stop to take a nap in a nearby paddock.

Instead of assigning \(d(\textrm{my death}) = \infty\) maybe I could say that dinner is delayed only up until the point of my death; that would mean that I am effectively computing the expected time until dinner or my death, whichever comes first. That seems like a reasonable way to resolve the problem of an infinity in the equation and it will produce finite answers because I am sure to die eventually, notwithstanding events that could prevent my death, such as the return of Christ (The Bible, Matthew 24:31) or a technology singularity. However, the technology singularity is another thing to ponder in conjunction with the mathematical difficulties surrounding infinity and the probability of Christ's return before dinner or before my otherwise certain death is theologically guaranteed to be uncomputable: 'concerning that day and hour no one knows' (Matthew 24:36, ESV).

Alternatively, consider another situation that is slightly less unfortunate: I doze off behind the wheel and crash my car into a power pole on the side of the road, but I survive. I might miss dinner entirely while the doctors put my bones back in their original places but get fed breakfast in hospital the next day. Does that \(d(\textrm{I miss dinner that day})\) count as infinity if I get dinner, or say breakfast, the next day? Do I actually mean to compute the expected time until my next meal? If I keep the original question, should I count until dinner the next day as the 'time until dinner' or should I count situations like that as also being an infinite time until tonight's dinner? Perhaps a better way to resolve these dilemmas is to use Bayes' theorem and ask a more restricted question: 'Assuming that I will eat dinner tonight, when do I expect to eat dinner?' Again, this will avoid the infinities, but the question has been changed.

I could look at my question in other ways, too. Perhaps the informal use of the word 'expect' should actually be interpreted as referring to the mode of the distribution of times that I might wait until I get dinner. Or maybe the median. Maybe I should exclude all outliers that have \(p(e) < \phi\) for some arbitrary, small event probability \(\phi\), replacing the original question with 'How long until dinner, assuming nothing too unexpected happens?' Because \(\phi\) can take any value, I now have an infinite number of possibilities. Before I can start computing an answer, I face the difficult problem of how to refine the question.

While this discussion may seem excessively philosophical, in fact this kind of problem must be solved every day by professional computer programmers. A program's requirements may state a subroutine computes the 'time until my dinner.' How does one deal with unusual cases? Many programmers will simply ignore their existence out of laziness or error. Others will write code that explicitly identifies odd cases but still fails to function in a meaningful way. Maybe the limitations of floating point numbers and finite sets in a computer will shine serendipitously on the problem, but maybe not. Maybe the rest of the program has no way of considering the possibility of my death and therefore the subroutine will not encounter that case, but maybe that is a flaw in the rest of the program. How does one meaningfully substitute answerable questions for unanswerable ones? Is that even possible in general?

New open source projects

My research has generated two new open source projects recently:
Wavechild 670 (GPL license)
A wave digital filter-based emulation of a famous stereo tube limiter from the 1950's.

Turn-taking measurement tools (BSD-style license)
Tools for measuring the quantity of turn-taking present in the behaviour of a group of agents.

The links also give the references for the associate research. Part of the idea is that academic research, open source and Wikipedia are all on a massive collision course for Knowledge 2.0. Or maybe more accurately, Knowledge N+1, because open source and Wikipedia are constantly changing. Soon the academic topics will be as open and fluid as say, the Linux kernel. Some smart person will probably be the spearhead of each topic, but there will be many contributors and the development of ideas will be out in the open.

Peter

There's something wrong with my toes

Imagine this scenario:

You go to the doctor and he says "I'm sorry, there's no reasonable cure for your condition. It'll be with you the rest of your life, and you just have to ignore it. I'm sorry. However, some people find that a daily dose of snake oil helps. You can give it a try if you want."

So you go home, with a heavy heart, but you know that you're an engineer / salesperson / mechanic / person on extended involuntary holiday (possibly seeking employment) / whatever and that he's a doctor. He knows best. So you go and buy some snake oil and start taking your daily supplement with your cornflakes in the morning.

Then one day you think, "Gosh, this snake oil is rather expensive stuff. I wonder how it works." So you open up Google and to your horror you read that snake oil does nothing, except for rare causes of earlobe inflammation in pregnant women on extended submarine voyages. Furthermore, you read that 81% of doctors admit to prescribing placebo medications and that the preferred method is to advise people to take snake oil. But you also read the the placebo effect can make a big improvement to people in a surprisingly large number of cases. But now you know that it's just a placebo and you think it won't work and you can't bear to buy useless things. You can understand the doctor's perspective, but you're kinda annoyed that he lied to you, after all the confidence you put in him.

So what do you do?

Don't do the Google search in the first place.

Peter

OSC Monitor program

Today's project was to write an Open Sound Control (OSC) monitor program.

You can download an OSX application, or the original Python source code at:

http://code.google.com/p/oscmonitor/

This is my first Tkinter GUI with Python.

Peter

Sharing stuff

I've come to a new level of belief in sharing stuff. As in practically, loaning things out to people. I don't use half the stuff I have all the time.

Maybe what I should really do is sell some of the stuff I don't really use at all.

But about the stuff that I use occasionally, I think I'd like to make more of a policy of loaning stuff out.

Does anyone want to borrow anything?

Peter