[Date Index] [Thread Index] [Author Index]

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