Call Windows Support

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Sunday, 1 July 2012

a stopped clock is never right

Posted on 07:42 by Unknown
A quarter past six? Or is it?
There's a saying that
Even a stopped clock is right twice a day.
This is used to mean: even something completely unreliable can (accidentally) sometimes be right.  The saying is sometimes cast as a paradox
A stopped clock is better than a clock an hour slow, because a stopped clock is right twice a day, yet a clock an hour slow is never right!
I want to explain how, in fact, a stopped clock is never right, and a clock an hour slow is always right.  This requires us to think of a clock as a simple computer, computing the current time, and ask ourselves, how can we tell the current time from the output of its computation?

A computation has three steps
  1. initialisation: set up the computer to perform the task of interest
  2. operation: the computer does its thing
  3. finalisation: read off the answer from the computer
(Don't blame me for the step names; I didn't invent them!  For those of you who are interested, this terminology comes from computational refinement theory.)  For a clock, these steps are instantiated as:
  1. initialisation: set the clock to the current time
  2. operation: the clock does its thing, marking off the passing moments
  3. finalisation: read off the (now later) current time from the clock
It's nearly ten past ten. Or is it?
Notice how the finalisation step is non-trivial.  The clock doesn't output "the time": it displays an output that requires some effort to be interpreted as the time.  To read the time from my analogue wristwatch (yes, I still use a wristwatch, and yes, it has an analogue display), I have to convert the positions of the hands, relative to a standard vertical (12 o'clock!) position, into a time.  This takes a (small amount of) skill: I can remember being taught how to "tell the time", that is, read an analogue clock face, by my aunt when I was about five. Even to read the time from a digital face requires some processing: to convert the displayed pattern of LED segments, or of pixels, into characters (ie, to read the  displayed pattern as characters), and interpret those characters ("12:30", say) as a time ("half past twelve").

This finalisation step is not the only one that can be applied, however.  This is the key step in the argument.  I realised this when I was attending a conference in Toulouse in 1999, and my watch was "broken".  It hadn't stopped, but I couldn't change the time (I couldn't reinitialise it), so it was an hour slow (stuck on UK time). That is, when I interpreted its output using the conventional finalisation, the time I got was off by one hour.  Given we started with "a clock an hour slow is never right", I could nevertheless use my watch to tell the correct time.  How?  (The answer will be obvious to anyone who has used a sundial during daylight savings time.)  By applying a different finalisation, one appropriate to its actual initialisation.  Here's the setup:
  1. initialisation: set my watch to the current UK time, so an hour behind the current French time
  2. operation: the watch does its thing, ticking off the passing moments
  3. finalisation: read off the (now later) time displayed by my watch, and add one hour
Voila! My watch was computing the correct French time, provided I finalised it correctly, that is, provided I correctly interpreted its output.  Well, you might say, but how did you know to add the hour?  Because I was the one who initialised it: I was the one who set up the computation. Other people looking at my watch would be confused, because they would be applying a different finalisation: the conventional one.  But it is merely a convention (established to make it convenient to use clocks other than ones that you have set yourself). In truth, you cannot tell the time looking at a clock unless you have some extra information: what finalisation you need to apply to interpret its display as a time. In practice, applying the conventional finalisation works, most of the time.

By using even more powerful finalisations, we can compute the time using even more faulty watches. For example, if I have a watch that loses a minute every hour, I can still use it, by adding the correct number of minutes back on when I read the time.  It is the combination of operation and finalisation that gives the resulting computation.

So how about the stopped clock?  Can you use it by applying an even more powerful finalisation? No. There is no finalisation that allows you to read off the correct time. The clock is performing no operation, it is not marking the passing time, so in order to get the desired computation from it, all the work would have to be done in finalisation alone, which would require using another clock!  The stopped clock is never right, because there is no finalisation: no way to interpret the display.  Your fortuitously looking at it when its display shows the current time does not make it right, not even coincidentally, because you have no way of interpreting its output.

However, there is something that a stopped clock has computed: the time at which it stopped (subject to applying the correct finalisation to its display, the one that would have been used when it was working).  This computation is the staple of many a TV cop show to tell the time of death of the newly discovered corpse with a conveniently smashed wristwatch (and the conventional finalisation being the wrong one is a cunning red herring in several detective novels).
Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in algorithm, computer | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • hyperbolic hyperbole
    What's with hyperbolic discounting? It's everywhere ! I first consciously noticed the term at a workshop about six weeks ago, and n...
  • better use seaweed
    As Neils Bohr is alleged to have said , “prediction is very difficult, especially about the future”. My smartphone has a weather app on it t...
  • "Windows support" -- not
    Just had another scam phone call -- someone with a strong Indian accent claiming to be calling from "Windows Technical Support" (o...
  • national stereotypes
    I've just got back from a very productive three day meeting in Paris. Just around the corner from where I was working, there was a marv...
  • retrospective holiday diary day 1: travelling north
    We went to the Lake District last “summer” ; this “summer” it was time for touring the other side of the country: Northumbria. The holiday s...
  • retrospective holiday diary day 5: trains
    Monday 24 September, and the long-threatened rain finally arrived. So this was the ideal day for the planned Carlisle-Settle rail trip . Bu...
  • oh dear
    We have a garden pond to help encourage frogs and other amphibians. Hedgehogs may suffer, however. :-(
  • funfair mirror trees
    One of the trees in our garden has died.  It died last summer in the drought, but we gave it a year to prove to us it really was dead.  It i...
  • retrospective holiday diary day 3: Lindisfarne
    Saturday 22 September, and the weather was still fine, sunny holiday weather so we decided to take advantage of the sunshine, and do Lindisf...
  • more scammers
    So not long after the scam phone call , the phone rings again. It's British Gas -- they get to call me because I'm actually a custo...

Categories

  • 3D printer
  • algorithm
  • astronomy
  • birds
  • Bonnie Tyler
  • books
  • cognition
  • computer
  • conference
  • Doctor Who
  • driving
  • ducks
  • duodecimal
  • education
  • electricity
  • estimation
  • Evernote
  • evolution
  • font
  • food
  • fractals
  • game
  • garden
  • graphics
  • grimoire
  • history
  • holiday
  • humour
  • language
  • LaTeX
  • lego
  • lol
  • mathematics
  • medicine
  • money
  • music
  • obituary
  • pedantry
  • politics
  • probability
  • psychology
  • publishing
  • python
  • quotations
  • research
  • robots
  • science
  • science fiction
  • space flight
  • statistics
  • TPS
  • trains
  • tree
  • TV
  • weather
  • web

Blog Archive

  • ►  2013 (119)
    • ►  December (1)
    • ►  November (17)
    • ►  October (12)
    • ►  September (10)
    • ►  August (9)
    • ►  July (8)
    • ►  June (10)
    • ►  May (19)
    • ►  April (10)
    • ►  March (9)
    • ►  February (4)
    • ►  January (10)
  • ▼  2012 (103)
    • ►  December (16)
    • ►  November (8)
    • ►  October (14)
    • ►  September (6)
    • ►  August (13)
    • ▼  July (8)
      • what's wrong with "and"?
      • Sally Ride, 1951 - 2012
      • sunshine on my garden makes it purple
      • road signs of desire
      • all ropes cut
      • narrating complexity
      • Middle Earth today
      • a stopped clock is never right
    • ►  June (6)
    • ►  May (9)
    • ►  April (10)
    • ►  March (7)
    • ►  February (5)
    • ►  January (1)
  • ►  2011 (79)
    • ►  December (7)
    • ►  November (5)
    • ►  October (10)
    • ►  September (7)
    • ►  August (6)
    • ►  July (5)
    • ►  June (6)
    • ►  May (6)
    • ►  April (9)
    • ►  March (9)
    • ►  February (3)
    • ►  January (6)
Powered by Blogger.

About Me

Unknown
View my complete profile