探索计算机科学的数学

Question

我在软件行业工作了两年。令我困惑的一些事情如下：

1. 目前的软件行业缺乏数学应用。

   例如：当机械工程师设计电线杆时，他通过使用应力分析技术（读取数学方程式）来计算基础上的应力，以确定应该使用什么类型和什么等级的钢材，但是当软件开发人员使用时部署一个Web服务器应用程序，他只是猜测他服务器上的估计负载，剩下的就是运气和上帝，没有什么可以用来模拟数学来回答他的问题（我的观察）。

2. 伟大的软件（风洞模拟器等）和计算程序（如matlab等）可以模拟现实世界的问题（因为它们有数学方程）但我们在软件行业仍然无法了解实际资源的数量在实际部署我们的服务器端应用程序时，需要内存，计算资源，时钟速度，RAM等。我们只是继续猜测解决方案并通过或多或少的“命中和试验”解决这个问题（我的观察）。

3. 编程是在API上进行的，无论是在c，C＃，java等中。我们永远无法准确地检查代码的复杂性，从而无法检查效率，因为我们正在使用其他人编写的抽象来源代码我们要么没有，要么我们没有时间检查它。

   e.g。如果我用C＃或java编写一个简单的客户端服务器应用程序，我永远无法事先计算出这个代码的效率和复杂程度，或整个客户端服务器应用程序需要的最小值（我的观察）

4. 负载均衡和可扩展性分析过于模糊，仅在服务器上的请求增加时添加更多节点才能解决（我的观察）。

请发布以上任何令人费解的观察结果的答案。 请发布相关参考资料。

如果有人证明我错了并且表明正确的方式，我会很高兴。

提前致谢

与Ashish

Answer 1

我认为这有几个原因。一个是，在许多情况下，简单地完成工作比使其尽可能好地完成更重要。我编写的很多软件只会在小数据集上运行，或者性能影响非常小的东西（它是一个对每个元素进行固定计算的循环，所以它通常是O（n） ）。对于大多数软件而言，花时间详细分析运行时间是愚蠢的。

另一个原因是软件以后很容易更改。一旦你构建了一个桥梁，任何修复都会非常昂贵，所以在你做之前确定你的设计是件好事。在软件中，除非你早期做出了糟糕的架构选择，否则一旦你掌握了一些关于它的表现的更真实的数据，你通常可以找到并优化性能热点。为了避免那些可怕的架构选择，您通常可以进行近似的，包络后的计算（确保您不在大型数据集上使用O（2 ^ n）算法，并在一个因子内进行估计10个左右你需要多少资源来满足你预期的最重负荷。这些确实需要进行一些分析，但通常它可以非常快速地脱离袖口。

然而在某些情况下，您确实需要从系统中挤出最终性能。在这种情况下，人们经常会坐下来，计算出他们正在使用的系统的性能特征，并进行非常详细的分析。例如，见Ulrich Drepper非常令人印象深刻的论文What Every Programmer Should Know About Memory (pdf)。

Answer 2

考虑一下工程科学，他们都有非常明确的法律适用于设计，物理项目的建设，重力，材料的强度等等。而在计算机科学中，没有很多明确的定义建立申请时的法律。

我可以想出许多不同的方法来编写一个满足要求的简单的hello world程序。但是，如果我必须建造一根电线杆，我受到物理世界以及极点要求的严重限制。

Answer 3

逐点

1. 电线杆必须承受天气，负载，腐蚀等，这些都可以量化和建模。我无法量化我的网站发布成功，或者我的数据库将如何增长。

2. 过早优化？确实足够好，在需要时修复它。如果您是供应商，您不知道在现实生活中运行代码的方式或配置方式。你无法量化它。

3. 过早优化

4. 参见第1点。我可以根据需要添加。

继续...甚至工程师bollix。倒塌的桥梁，停电，汽车安全召回，“错误的雪”等等。我们是否应该将问题改为“工程师为何不使用更多的经验观察？”

Answer 4

对大多数这些问题的答案是，为了在实际工程中进行有意义的测量（以及公认的公式，限制，公差等），您首先需要一种衡量您正在观察的内容的方法。

大多数这些事情根本无法轻易衡量 - 软件复杂性是一种经典，什么是“复杂”？您如何看待源代码并确定它是否复杂？ McCabe的Cyclomatic Complexity是我们最接近的标准，但它基本上只是计算方法中的分支指令。

Answer 5

软件程序中的数学很少，因为程序本身就是等式。在实际运行之前无法计算出等式。工程师使用简单（和非常复杂）的程序来模拟现实世界中发生的事情。模拟模拟器非常困难。此外，计算机科学中的许多问题甚至没有数学上的答案：见旅行推销员。

大部分数学也包含在语言和图书馆中。如果使用哈希表来存储数据，则无论哈希表中有多少个元素，您都知道可以在常量时间O（1）中找到任何元素。如果将它存储在二叉树中，则需要更长的时间，具体取决于元素的数量[0（n ^ 2），如果我没记错的话]。

Answer 6

问题在于软件与人类编写的其他软件进行对话。您描述的工程示例处理的物理现象是不变的。如果我开发一个电子模拟器，世界上每个人都可以使用它。如果我为我的服务器开发协议X模拟器，它将对我有所帮助，但可能不值得这样做。

没有人可以从头开始设计系统，编写半公共库的人通常会有大量的增强和扩展，而不是为他们的库编写模拟器。

如果您想要一个网络流量模拟器，您可以找到一个，但它会告诉您很少有关您的服务器负载，因为流量将不会使用您的服务器理解的协议。每台服务器都会看到完全不同的流量集。

Answer 7

  

目前的软件行业缺乏数学应用。

     例如：当机械工程师设计电线杆时，他通过使用应力分析技术（读取数学方程式）来计算基础上的应力，以确定应该使用什么类型和什么等级的钢材，但是当软件开发人员使用时部署一个他只是猜测服务器估计负载的Web服务器应用程序，剩下的就是运气和上帝，没有什么可以用来模拟数学来回答他的问题（我的观察）。

我不会说运气或上帝总是负荷估算的基础。通常可以获得真实的数据。

没有数学技巧可以回答这个问题。运筹学和排队论可以很好地应用。

真正的问题是机械工程是基于物理定律和数千年经验和科学研究的基础。计算机科学只和我一样古老。当你的孩子和孙子们应用当时的最佳实践时，计算机科学将会更进一步。

Answer 8

1）大多数业务逻辑通常分解为决策树。这是应该用单元测试证明的“等式”。如果你输入x那么你应该得到y，我没有看到任何问题。

2,3）分析可以提供关于性能问题所在的一些见解。在大多数情况下，您不能说软件会占用x个周期，因为它会随着时间的推移而变化（即数据库变大，操作系统开始变得时髦等）。例如，桥梁需要不断的维护，你不能把它打起来，并期望它可以持续50年而不花费时间和金钱。使用库就像不想在每次想要找到圆周长时找出pi。它已经被证明（并且具有成本效益），因此无需重新发明轮子。

4）大多数情况下，Web应用程序可以横向扩展（多台机器）。垂直（多线程/多进程）扩展往往要复杂得多。添加机器通常相对容易且具有成本效益，并避免一些容易受到限制的瓶颈（磁盘I / O）。负载平衡也可以消除一台机器成为中心故障点的可能性。

这并不完全是火箭科学，因为你永远不知道会有多少消费者来到服务线。一般来说，有太多的容量然后有错误，最好是顾客和某人（通常是你的老板）咀嚼你的隐藏。

Answer 9

MIT EE grad不会有这个问题;）

Answer 10

我的想法：

1. 有些人确实应用数学来估算服务器负载。对于许多应用来说，方程式非常复杂，许多人采用经验法则，猜测和调整或类似的策略。一些应用（对故障进行高额惩罚的实时应用......武器系统，动力装置控制应用，航空电子设备）仔细计算所需的资源并确保它们在运行时可用。

2. 与1相同。

3. 工程师还使用其他人提供的组件，并使用已发布的界面。想想电气工程。您通常不关心晶体管的内部，只是它的接口和操作规范。如果你想检查你使用的所有组件的复杂性，那么你将被限制在一个人可以完成的任务中。

4. 我编写了相当复杂的算法，根据内存消耗，CPU负载和IO等各种因素确定要扩展的内容。但是，有效的解决方案有时需要进行测量和调整。如果应用程序很复杂并且随着时间的推移而发展，则尤其如此。投入数学建模应用程序（并随着时间的推移更新该模型）所付出的努力可能不仅仅是通过尝试和正确方法损失效率的成本。最终，我可以设想更好地理解代码与其执行的环境之间的关联可能会导致系统提前预测资源使用情况。由于我们今天没有，许多组织在各种条件下加载测试代码，以便凭经验收集这些信息。

Answer 11

软件工程与典型的工程领域截然不同。如果“正常”工程受到我们物理世界的背景以及我们已经确定的规律的约束，那么软件界就没有这样的界限。

制作软件通常是试图将现实世界的一部分镜像到虚拟现实中。在这里，我们自己定义法律，只选择我们需要的法律，并使它们尽可能复杂。由于这种根本区别，您需要从不同的角度来看问题解决。我们尝试进行抽象，使复杂的部分不那么复杂，就像我们教孩子们黄色+蓝色=绿色一样，当它真正反射在纸张上反射的光的波长时。

偶尔我们受到不同法律的约束。像Big-O，测试覆盖，复杂度测量，UI测量等等都是数学定律的模型。如果你研究数字信号处理，实时编程和函数编程，你会经常发现程序员使用方程来找出他们想要的方法。 - 但这些技术并非（在某种程度上）对创建虚拟域有用，可以解决复杂的逻辑，分支和与用户交互。

Answer 12

在工程领域需要风洞，模拟等等的原因是，构建缩小的原型比制造完整的东西然后测试它要便宜得多。此外，对全尺寸桥接器的测试失败是破坏性的 - 您必须为每个测试构建一个新测试。

在软件中，一旦你有一个通过要求的原型，你就拥有了全面的解决方案。没有必要构建完整版本。您应该在使用它们之前对服务器应用程序运行负载模拟，但由于负载是可变的并且通常是不可预测的，因此您最好通过添加更多硬件来构建应用程序以扩展到任何大小，而不是针对特定目标。加载。桥构建器具有需要处理的给定目标负载。如果他们在任何特定时间预计使用10辆汽车，那么一年之后，这座桥的人气每天飙升至1,000,000辆汽车，如果失败，没有人会感到惊讶。但是对于Web应用程序，这就是必须进行的扩展。