使用AMPL的明显优势是什么？

Question

我在Netbeans with Java上使用CPLEX解算器做一个项目。我们有几个要解决的优化问题，我已经通过在Java中编码所有约束，目标和变量来解决其中一个问题，而不使用AMPL。但是，我团队中的某些人想要使用AMPL 因此，由于我不想阅读所有AMPL书籍以找到答案，是否有明显的理由宁可使用AMPL而不是“手动”编码所有约束？此外，AMPL可以集成到Netbeans中吗？我没有找到任何关于这方面的文件。 当约束需要“灵活”时，AMPL是否有用（我的意思是，我们不能提前猜测约束的确切数量，它取决于用户修复的参数，模块化是一个高重要性因素......）< / p>

我很想知道很快就会听到这个消息！

感谢您的帮助

Answer 1

AMPL是一种代数建模语言，引用该链接：

  

AMPL的一个优点是它的语法相似   优化问题的数学符号。

例如，这可以允许您在不事先知道模型尺寸的情况下定义约束组。或许，您可以更快地对模型进行重大更改。 （你必须考虑你实际上会这样做的频率。）

然而，有人可能会说AMPL的“明显优势”是支持数十种不同的求解器。您可以创建模型并使用CPLEX解决它，但随后决定要使用其他解算器（例如，Gurobi，Xpress等）。在AMPL Solvers网页上，他们有以下建议：

  

我们建议您测试替代解算器以确定哪个   为您的需求提供最佳的价格和性能折衷。

AMPL API网页说有一个Java API，所以应该允许你将它包含在Netbeans项目中，但我对此没有经验。

在一天结束时，您还可以争辩说这些“优势”是品味问题。正如您已经完成的那样，直接使用CPLEX Java API，如果满足您的要求，肯定是一种有效的解决方案。它可以让您更有效地构建模型，使用AMPL可能不支持的解算器特定/高级功能，并对模型公式进行更细粒度的控制。

Answer 2

您刚刚编写了一个优化模型，以优化您公司的小部件制作。您的公司在$ SOLVER1上获得了非常好的交易，因此您正在使用它。

在接下来的十年中，当您的老板向您提出新的要求时，您会改进并扩展该模型。到那时为止，您可能拥有数万行优化代码作为系统的一部分，到目前为止，这对您公司的运营至关重要。

贵公司的原始许可协议已经过期，$ SOLVER1的制造商大幅增加了许可费用，因此您现在每年要支付数十万美元的许可费用。

与此同时，竞争对手公司的boffins刚刚发布了新版本的SOLVER2。它有一些花哨的新算法可以解决小部件优化问题，速度提高20％，并找到比$ SOLVER1给你更好的解决方案。它的成本不超过$ SOLVER1，性能更好。

与此同时，开源社区发布了$ FREESOLVER。它可能不如顶级商业选项那么强大，但它与十年前的$ SOLVER1一样好，如果你不是每年支付10万美元的许可，你可以租得很多服务器的时间来弥补它。

...所以，你是否在一个平台上编写了优化模型，让你切换到一个新的求解器，并利用这些机会，而不必放弃十年＆＃39;值得代码？

能够快速轻松地切换求解器具有巨大的优势。我知道有一家公司为他们的工作使用了三种不同的解算器：他们尝试在云中运行两种不同的开源解算器，如果这些解决方案都找不到适当的解决方案那么他们会把它扔到具有更智能算法的昂贵解算器。开源求解器可以处理90％的问题，因此他们只需要使用商业解算器，最后10％，这样他们就可以大大节省许可成本。

我们在工作中讨论的一个选项是使用商业解算器进行关键任务工作，以及开源替代方案，用于培训或小规模原型制作等应用程序，我们也不会这样做要求。这样我们就可以最大限度地减少商业解算器许可所需的并发用户数量。

（并且，是的，仍然存在与平台锁定的问题，但像AMPL这样的平台显着比高端商业解决方案便宜。）

Answer 3

完全同意rkersh所说的一切。另请注意，无论是使用代数建模语言还是通过其中一个更直接的API编写，都不应该以难以编码问题大小等细节的方式编写模型。

此外，使用建模语言为您提供了额外的抽象级别/层次，这可以提供帮助，特别是在与其他人共享或解释您的模型时，与一系列标准问题类型等进行比较，但我更喜欢坚果 - 并且感觉＆＃39;感觉＆＃39;使用更直接的API，几乎从不需要（或有时间和预算）重新制定我的模型。

Answer 4

• 即使GPL意味着＆＃34;一般＆＃34;然而，新的和更新的GPL正在栩栩如生，所以给定的GPL是更普遍的＆＃34;某些任务比其他人...... :-)理论上，为Pascal或Perl编写最有效的编译器应该无关紧要，所以实际上你可以用你想要的任何语言编写，但你不应该失去表达能力或效率（例如C＃现在和Java在同一个联盟中，MS写的编译器比开源的等价物好。
• 人类专注 - 这就是为什么我们已经走到这一步:-)。在实现将业务问题转换为数学模型（也称为建模）的特定任务时没有什么不同。拥有给定建模层的整个想法就是这样
  • 甲。你对该特定任务（即数学建模）具有最高的表现力
  • B中。它强制执行一些最佳实践来模拟GPL中你不是什么＆＃34;强迫＆＃34;要做的事情（1.你可以自由做2.它是以这种方式销售给你的=灵活性）。例如。 AMPL，GAMS，其他人正在混合声明性代码（又名模型代码）和程序代码（又名流控制），这不是一个好习惯。另一方面，例如分离数据和抽象模型正在使用所有建模语言，但有趣的是非常慢......
  • ℃。通过no.A你可以比其他方式更有效地维护代码（与API建模相反 - 我有客户说他们转向建模语言，因为API建模是快速模型改造的责任）
  • d。从理论上讲，你可以独立解决。
• 如果你环顾四周，所有建模语言都试图维持no.C，除了OPL（由于历史原因）。但是即使在OPL的情况下，你也可以得到约束编程和基于约束的调度（除了数学编程），你不会使用AMPL / GAMS，但是它们是独立的...
• $ Solver1和$ Solver2 + $ Freesolver比较有点因为4个原因而被打破
  • 甲。当涉及到大型/复杂问题时，openolvers在性能方面仍然远离商业解决方案（可能LP正在成为例外） - 我有客户 - 我记忆中有史以来最快的销售 - 当他们测试商业解决方案后＆＃34;搭便车＆＃34;
  • B中。事实上，与$ Solver1和$ Solver2相关的场景似乎是合理的（$ Solver1，现任者随着时间的推移变得越来越贵），我们可以看到另一种方式，$ Solver2（一个新来者）实际上增加了定价7年内4倍，有时甚至翻了一番，而$ Solver1（现任者）没有变化。
  • ℃。混淆建模功能和求解器是一个错误。整个想法是，有人在API中编写模型是比通过建模语言更多地坚持求解器的方法。至少，正如匈牙利人所说的那样，你在定制上获得的东西会在渡轮上失去它，换句话说，＃34;自由（即灵活性）伴随着负责任地使用＃34; < / LI>
  • d。拥有一个解决方案进行开发并不昂贵，即一家公司可以维持大量的求解器（少于1万美元的公司可以有+4个求解器用于开发）来测试哪个是任何给定型号的最快，然后选择最适合部署。
• 此外，解算器只是拼图的一部分。例如。我有一个拥有不同数据源的客户，创建模型需要8小时，解决它需要4小时。这个客户是否会欢迎更高效的数据处理套件，还是会坚持解决方案应该更快？在大多数情况下，建模者与业务过于孤立，而在他们的心目中，给定的模型是完美的，如何通过数据来填充数据是次要的，但它会成就或破坏良好的性能。
• 我见证了API建模师正在转向建模语言，而不是出于各种原因......
• 但正如上面有人写的那样，游戏中有很多口味，所以最终如果你对某种方法感觉更加舒适，那么没有人可以责怪你选择...... :-)毕竟很难比较/另一种方法，因为它几乎从来没有在给定的情况下......所以最终重要的是从业务问题到在给定应用程序环境中快速解决的模型的速度： - ）

p p，这很长......但是我把所有镜头都给了......： - ）

Answer 5

为了简短说明使用AMPL的优缺点，只需使用Java（AMPL）而不是汇编语言（CPLEX）进行比较。