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: <email@example.com> <firstname.lastname@example.org> <email@example.com>
In article <iae7hp$7h0$1 at smc.vnet.net>, Helen Read <readhpr at gmail.com>
> 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
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.
Prev by Date:
Re: Manually nested Tables faster than builtin
Next by Date:
Re: Assertions in Mathematica?
Previous by thread:
Re: Determining the root of the characteristic equation
Next by thread:
Puzzled by a puzzle