Re: Sneaky white space (binary search)
- To: mathgroup at smc.vnet.net
- Subject: [mg113483] Re: Sneaky white space (binary search)
- From: Joseph Gwinn <joegwinn at comcast.net>
- Date: Sat, 30 Oct 2010 04:39:17 -0400 (EDT)
- References: <ia8qin$1m3$1@smc.vnet.net> <iabc32$5gb$1@smc.vnet.net> <iae7hp$7h0$1@smc.vnet.net>
In article <iae7hp$7h0$1 at smc.vnet.net>, Helen Read <readhpr at gmail.com> wrote: > On 10/28/2010 4:26 AM, David Bailey wrote: > > > > I think the lesson to learn from that - which I find useful from time to > > time - is that if a piece of input seems to generate spurious syntax > > errors, or responds in some very peculiar way, it is worth trying > > re-typing it, possibly by cutting and pasting the text in question to a > > text editor and back again! > > > > This happens with my students occasionally, and if trying the usual > Clear["`*"] and re-evaluate doesn't fix the issue, I will have them > retype in a new input cell, without copying/pasting what they had > before. It fixes those hidden problems every time. That has been my experience too. A related problem is when the weird behaviour isn't obviously localized. I most often encounter the problem in MS Office products, which are prone to accidental damage to document file structure in heavily edited documents, but the problem is general, as is the following solution. I actually invented (or reinvented) this process back in the 1970s, when I was a programmer, and the root cause was often a compiler bug of some kind. This is an application of binary search to bugfinding, and will terminate in O[log2(N)] steps. To take a recent example, I had a 70-page MS Word document that displayed and edited on the screen correctly, but could not be printed. Once I had determined that the problem was with the document itself, versus setup problems et al, the solution was to make a working copy, and proceed as follows. The document is arbitrarily split into two roughly equal halves, and printing is attempted on each of these two halves. Typically, one will print and the other will not. Split the non-printing half into halves, yielding two quarter files, and again attempt to print. Typically, one will print and the other will not. Repeat. Eventually, one will have isolated the problem to a small amount of text. Stare at it; fix anything odd. If nothing seems odd, manually retype. Sometimes, both child files will print, even though their parent will not. This means that the problem is at or very close to the split point. Retype the five or ten line neighborhood of the split point. Although I typically never do figure out what the real problem was, this procedure has never failed me. Joe Gwinn