论部分进展的重要性
论部分进展的重要性
[最初于 2012 年 7 月 17 日发布在 Google+ 上。-T]
数学问题解决的一个秘诀是,人们需要高度重视部分进展,将其视为完全解决问题的关键垫脚石。这可能与人们在更”现实世界”情境(如商业、体育、工程或政治)中常见的思维方式截然不同,在这些情境中,实际的成功或失败往往比从部分成功中能够挽回的东西重要得多。我认为其基本原因是,在纯粹的理论数学世界中,采用一个部分解决问题的论证,然后将其与其他想法结合以形成完整解决方案,基本上没有成本;但在现实世界中,重用或回收任何(或被感知为)哪怕是部分失败的东西可能都很困难、成本高昂或在社交上不可接受。软件工程是这一普遍规则的少数例外之一,因为重用软件代码几乎和重用数学论证一样容易。
对于尚未采用部分进展思维方式的数学初学者来说,常见的情况是尝试一种技术来解决问题,发现它”失败”了,然后得出结论认为需要尝试完全不同的技术(或者完全放弃这个问题)。但实际上,经常发生的情况是,一个人的第一次解决方案尝试能够解决问题的某些部分,然后需要将该论证与能够解决互补部分问题的技术结合起来,以达到最终解决方案。
例如,最近一位研究生带着一个他试图估计的实直线上的积分来找我。他尝试了分部积分法,发现由此产生的积分项在实直线的一侧表现良好,但在另一侧发散。初学者可能此时就会放弃这种方法;但由于已经有了一些数学经验,他意识到这是一个部分成功,并将实直线分成两部分,使用分部积分法控制一部分上的积分,并使用不同的技术(被积函数的泰勒展开)控制另一部分积分。不幸的是,当他将估计值相加时,他发现无论将实直线如何分成两部分,总估计值仍然达不到他想要的结果,这时他来找我寻求帮助。但实际上,这次失败实际上是进一步的部分进展;他发现了一种方法(分部积分法)可以处理积分参数较大正值时的积分,另一种方法(泰勒展开)可以处理较大负值时的积分,剩下的只是添加第三种技术(在这种情况下,是通过将所有内容替换为其绝对值进行粗略估计)来处理前两种技术无法很好处理的中间值。因此,前两次”失败”实际上是解决完整问题所需的关键进展,它们至少解决了问题中存在的一些困难,并将注意力集中在需要解决的剩余问题上。
部分进展思维方式的一个推论是,即使你事先知道一种技术不可能完全解决问题,尝试该技术也常常是有益的。(例如,该技术可能无法区分实际问题 和一个看起来相似但答案已知为否定的问题 。或者该技术可能已经被许多专家所知,他们多年来一直尝试解决 ,这提供了强有力的经验证据表明该技术不足以解决该问题。或者,该技术没有机会解决完整问题 ,但只能希望解决问题的”玩具”或”模型”实例 ,其中一些(但关键不是全部)困难已被移除。)关键是,即使该技术注定会失败,它在论证中失败的确切点可能非常有启发性,因为它可以描绘出问题的哪些部分可以通过此类论证处理(至少在原则上),并突出了需要进一步工具解决的问题的关键组成部分,然后可以将注意力集中于此。
On the importance of partial progress
[Initially posted on Google+ on July 17, 2012. -T]
One of the secrets to mathematical problem solving is that one needs to place a high value on partial progress, as being a crucial stepping stone to fully solving the problem. This can be a rather different mindset than what one commonly sees in more “real world” situations such as business, sports, engineering, or politics, where actual success or failure often matters much more than what one can salvage from a partial success. I think the basic reason for this is that in the purely theoretical world of mathematics, there is basically a zero cost in taking an argument that partially solves a problem, and then combining it with other ideas to make a complete solution; but in the real world, it can be difficult, costly, or socially unacceptable to reuse or recycle anything that is (or is perceived to be) even a partial failure. Software engineering is one of the few exceptions to this general rule, as it is almost as easy to reuse software code as it is to reuse a mathematical argument.
For beginning maths students, who have not yet adopted the partial progress mindset, it is common to try a technique to solve a problem, find out that it “fails”, and conclude that one needs to try a completely different technique (or to give up on the problem altogether). But in practice, what often happens is that one’s first solution attempt is able to solve some portion of the problem, and one needs to then look to combine that argument with techniques that can solve complementary portions of the problem in order to reach the final solution.
For instance, recently a graduate student came to me with an integral on the real line he was trying to estimate. He had tried integration by parts, and found that the resulting terms from that integration behaved well on one side of the real line, but diverged on the other. A beginner might have given up on this method at this point; but having already had some mathematical experience, he realised that this was a partial success, and split the real line into two pieces, using integration by parts to control the integral on one piece, and a different technique (Taylor expansion of the integrand) to control the other integral. Unfortunately, when he added up the estimates, he found that no matter how where he divided the real line into two, the total estimate still fell short of what he wanted, at which point he came to me for help. But actually, this failure was in fact further partial progress; he had discovered one method (integration by parts) that handled the integral for large positive values of the integration parameter, and another (Taylor expansion) that handled large negative values, and all that remained was to add a third technique (which, in this case, was crude estimation by replacing everything by its absolute value) to treat the intermediate values which were not well handled by the previous two techniques. Thus the first two “failures” were in fact crucial advances that were needed to solve the full problem, by resolving at least some of the difficulties present of the problem, and in focusing attention on the remaining issues that needed resolution.
One corollary of the partial progress mindset is that it can often be profitable to try a technique on a problem even if you know in advance that it cannot possibly solve the problem completely. (For instance, the technique may be unable to distinguish between the actual problem , and a similar-looking problem for which the answer is already known to be negative. Or the technique may already be known to many experts who have tried for many years to solve , which gives strong empirical evidence that this technique is insufficient for the problem. Or, the technique has no chance to solve the full problem , but can only hope to solve “toy” or “model” instances of the problem in which some (but crucially, not all) of the difficulties have been removed.) The point is that even if the technique is doomed to fail, the precise point in the argument at which it fails can be very instructive, as it can delineate what portion of the problem can be handled (in principle, at least) by such arguments, and it highlights the key component of the problem which needs a further tool to resolve, and to which one can then focus attention on.