Mostly HarmlessJohn Alderson's Blog |
|
Thursday Jul 19, 2007
printf() - the immortal debugger
Caramba! Gone are the nights of "clubbin'" and the days of backchat and nose-powdering. In between hiding webcams in Project Central and stealing Ursula's entire library of O'Reillys Donna has succeeded in booting the SFW1000+8i! She is the first non-Sumover Futures employee to attain this level of magery. The engineers at Sumover wanted to send her a wee plaque in recognition but a "suit" intervened. The more credible this product looks the more snappy dressers with visitor's badges haunt the corridors. True, she hasn't managed to entangle all 8 Superposition Engines for more than a picosecond yet but seems unperturbed by this and only smiles coyly when people inquire about her progress. In any case, even one working engine has Risto salivating. He limbered up with a couple of Travelling Salesman problems involving 100 cities and then launched into a project of his own. No-one knows what this is. Risto doesn't do "coy", he leans more towards the blunt end of things, with statements like "If I explained it to you you wouldn't understand anyway." We have encountered new and fantastical difficulties when debugging quantum programs. Traditional debugging with breakpoints just won't work. There is an obvious and a less-obvious reason for this: The obvious reason is that as soon as it hits a breakpoint the running program displays this fact on your terminal so that you can decide what to do next. This is equivalent to getting an eyeful of Schroedinger's Cat. The program will have gone irretrievably classical so there is no meaningful way it can be resumed. So, you might say, at least we can do a post-mortem on the breakpointed program? Not necessarily... This brings us to the less-obvious problem: A breakpoint may sit on one of several code-paths and be missed by the others. In a classical program a breakpoint which is not visited has no effect on the execution of the program - but in a quantum program the mere possibility of visiting the breakpoint influences program execution even if the breakpoint is not visited. In QM terms the breakpoint is a potential "observation". It's effect on a system even when the observation is not made is sometimes termed "counterfactual". I believe the idea of something which only might have happened influencing something that did was one of the paradoxes first raised by Einstein, Podolsky and Rosen in a thought experiment involving bomb fuses which could be triggered by a single photon. So, anyway, trad breakpoints are a no-no. We've gone back to using printf() - but to a tiny qRAM filesystem which runs entangled with the program image. It's funny to think that messages may be written (sort of) to that filesystem which are no longer there when the burly programmer finally gets to look at the file. Still - our output is now coherent, even if not complete ;-) We automated the initialisaton of the qRAM-FS:
/*
* Hello world - "Q-safe"
*/
#include <qstdio.h>
main()
{
fprintf(qstdout, "Hello, World!");
}
[NB: For anyone who feels in danger of losing the thread of Lake Guillemont a handy list of episodes is provided on the side-bar (most recent first)] Posted at 04:11PM Jul 19, 2007 by John Alderson in Lake Guillemont | Comments[1] |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Posted by Lewis on July 19, 2007 at 10:50 PM BST #