Inventor's paradox

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.

In the book How to Solve It, Hungarian mathematician 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.^[1]

Or, in other words, to solve what one desires to solve, one may have to solve more than that 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 as possible. 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 that was originally of concern.^[4] There lies the inventor's paradox, that it is often significantly easier to find a general solution than a more specific one, since the general solution may naturally have a simpler algorithm and cleaner design, and typically can take less time to solve in comparison with a particular problem.^[3]

The sum of numbers sequentially from 1-99:

${\displaystyle 1+2+3+\cdots +97+98+99\,}$

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

${\displaystyle (1+99)+(2+98)+(3+97)+\cdots +(48+52)+(49+51)+(50)\,}$

In this form, the example can be solved by most without the use of a calculator.^[3] If one notices the problem's lowest and highest numbers (1 + 99) sum to 100, and that the next pair of lowest and highest numbers (2 + 98) also sum to 100, they'll also realize that all 49 numbers are matching pairs that each sum to 100, except for the single number in the middle, 50. The inventive mathematician will reformulate the problem in their mind as (49 * 100) + 50. Since 49 * 100 is easy to calculate by adding 2 zeros to the digit places of 49, they think: 4900 + 50. This is easy to add, because 50's maximum ordinal placement of the most significant digit (number 5 in the 2nd position "10s" place) is less than the minimum ordinal position of 4900's smallest significant digit (number 9 in the 3rd position "100s" place). So the solver simply replaces the last two 0s in 4900 with 50 to add them together, yielding the answer 4950. While the text description of this process seems complicated, each of the steps performed in the mind is simple and fast.

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

${\displaystyle 1+3=4\,}$

${\displaystyle 1+3+5=9\,}$

and further along in the sequence:

${\displaystyle 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]

${\displaystyle \sum _{k=1}^{n}\mathbf {(} 2k-1)=n^{2}.}$

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][further explanation needed]}

This paradox has applications in writing efficient computer 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]

• Abstraction
• Generalization
• Architecture astronaut, related to the converse problem where abstraction is taken too far.

• 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. pp. 170. ISBN 0-13-970251-2.
• Bentley, Jon Louis (2000). Programming Pearls. Addison-Wesley. pp. 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. pp. 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. pp. 276. ISBN 0-471-32772-7.