Inventor's paradox

From Wikipedia, the free encyclopedia
Jump to: navigation, search

The inventor's paradox is a phenomenon that occurs in seeking a solution to a given problem. Instead of solving a specific type of problem, which would seem intuitively easier, it can be easier to solve a more general problem, which covers the specifics of the sought after solution. The inventor's paradox has been used to describe phenomena in mathematics, programming, and logic, as well as other areas that involve critical thinking.

History[edit]

In the book How to Solve It, George Pólya introduces what he defines as the inventor's paradox:

The more ambitious plan may have more chances of success...provided it is not based on a mere pretension but on some vision of the things beyond those immediately present.

or, in other words, to solve what you desire, you may have to solve more than what you actually want to in order to get a properly working flow of information.[2]

When solving a problem, the natural inclination typically is to remove as much excessive variability and produce limitations on the subject at hand. Doing this can create unforeseen and intrinsically awkward parameters.[3] The goal is to find elegant and relatively simple solutions to broader problems, allowing for the ability to focus on the specific portion you were initially concerned with.[4]

There lies the inventor's paradox, that it is often significantly easier to find a general solution than a more specific one, which may naturally have a simpler algorithm and cleaner design, and typically can take less time to solve in comparison with a particular problem.[3]

Examples[edit]

Mathematics[edit]

The sum of numbers sequentially from 1-99:

1 + 2 + 3 + ... + 97 + 98 + 99\,

This process, although not impossible to do in your head, can prove to be difficult for most. However, the ability to generalize the problem exists, in this case by reordering the sequence to:

(1 + 99) + (2 + 98) + (3 + 97) + ... + (48 + 52) + (49 + 51) + (50) \,

In this form, the example can be solved by most without the use of a calculator.[3]

Although appearing in several applications, it can be easiest to explain through inspection of a relatively simple mathematical sequence.[5]

1 + 3 = 4\,
1 + 3 + 5 = 9\,

and further along in the sequence:

1 + 3 + 5 + 7 + 9 = 25\,

In allowing the sequence to expand to a point where the sum cannot be found quickly, we can simplify by finding that the sum of consecutive odd numbers follows:[2]

\sum_{k=1}^{n}\mathbf(2k-1) = n^2.

Programming[edit]

As an example in applying the same logic, it may be harder to solve a 25-case problem than it would be to solve an n-case problem, and then apply it to the case where n=25.[6]

Applications[edit]

This paradox has applications in writing efficient programs. It is intuitive to write programs that are specialized, but in practice it can become easier to develop more generalized procedures.[7] According to Bruce Tate, some of the most successful frameworks are simple generalizations of complex problems, and he says that Visual Basic, the Internet, and Apache web servers plug-ins are primary examples of such practice.[4] In the investigation of the semantics of language, many logicians find themselves facing this paradox. An example of application can be seen in the inherent concern of logicians with the conditions of truth within a sentence, and not, in fact, with the conditions under which a sentence can be truly asserted.[2] Additionally, the paradox has been shown to have applications in industry.[3]

Citations[edit]

  1. ^ Pólya, p. 121.
  2. ^ a b c Barwise p. 41.
  3. ^ a b c d Tate, et al., p. 110
  4. ^ a b Tate, et al., p. 111.
  5. ^ Barwise p. 40.
  6. ^ Bentley (2000), p. 29.
  7. ^ Bentley (1982), p. 79.

Sources[edit]

  • Barwise, Jon (1989). "Situations in language and logic". The situation in logic. Center for the Study of Language (CSLI). p. 327. ISBN 0-937073-33-4. 
  • Bentley, Jon Louis (1982). Writing efficient programs. Prentice-Hall. p. 170. ISBN 0-13-970251-2. 
  • Bentley, Jon Louis (2000). Programming Pearls. Addison-Wesley. p. 239. ISBN 0-201-10331-1. 
  • Pólya, Gyorgy (1957). How to solve it: a new aspect of mathematic method. Doubleday. p. 253. ISBN 0-691-08097-6. 
  • Tate, Bruce; Gehtland, Justin (2004). "Allow for Extension". Better, faster, lighter Java. O'Reilly Media, Inc. p. 243. ISBN 0-596-00676-4. 
  • Welborn, Ralph; Kasten, Vincent A. (2003). "Collaborative DNA: Exploring the Dynamics". The Jericho principle: how companies use strategic collaboration to find new sources of value. John Wiley and Sons. p. 276. ISBN 0-471-32772-7. 

See also[edit]