If I'm planning to run a program that I think will take a "long" time, I try to get it running as quickly as possible, and only then *think about it*. Since it's going to run a long time, I'll have plenty of time to think once the program is running, but I want to be able to overlap my thinking with the running of the "dumb" program. However, many times I can think of a better/more efficient way, and have the opportunity to quit the running program to test out the better idea. The definition of "long" is flexible -- the longer the program takes, the more time I have to think about it and optimize it. ("Necessity is the mother of invention".) Perhaps I'm forever scarred from my keypunch-and-submit-card-deck days. At 06:59 AM 1/7/2016, Veit Elser wrote:
Jim's article reminds me of another strategy for being on the right side of wrong.
Cornell physicist Peter Lepage, who develops Markov chain Monte Carlo methods for computing properties of hadrons from "lattice gauge theory", had heard about the MH controversy and decided he would simulate it with a computer program. After he'd written the program and stared at it a while the winning strategy was obvious. He never actually ran the program.