当前位置 : 首页 » 互动问答 » 正文

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

分类 : 互动问答 | 发布时间 : 2018-04-27 16:11:41 | 评论 : 4 | 浏览 : 70 | 喜欢 : 1

我在使用Java的Netbeans上使用CPLEX解算器进行项目。我们有几个优化问题需要解决,我已经通过在Java中编写所有约束,目标和变量来解决其中的一个问题,而不使用AMPL。但是,我的团队中有些人想使用AMPL。
因此,由于我不想阅读所有的AMPL书籍来找到答案,是否有一个显而易见的理由宁愿使用AMPL而不是“手动”编码所有约束?而且,AMPL可以整合到Netbeans中吗?我没有找到任何有关这方面的文件。 当约束条件需要“灵活”时,AMPL是否有用(我的意思是,我们不能提前预测约束的确切数量,它取决于用户固定的参数,模块化是一个高度重要的因素......) notranslate>我真的好奇,很快听到!

感谢您的帮助

Thanks for help

回答(4)

  • 1楼
  • 您刚刚编写了一个优化模型,以优化您公司的小部件生产。您的公司在$ SOLVER1上获得了非常好的交易,所以这就是您正在使用的。

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

    贵公司的原始许可协议已过期,制造商的$ SOLVER1大幅增加了许可费用,所以你现在每年要花费数十万美元的许可费用。同时,竞争对手公司的棺材刚刚发布了新版本的$ SOLVER2。它有一些新奇的算法可以解决小部件优化问题,速度提高20%,找到比$ SOLVER1更好的解决方案。它不超过$ SOLVER1,性能更好。同时,开源社区已经发布了$ FREESOLVER。它可能没有顶级商业选择那么强大,但它和十年前的$ SOLVER1一样好,如果你没有支付10万美元/年的授权费用,你可以租用很多服务器时间来弥补因此,你是否在一个平台上编写了优化模型,让你切换到一个新的求解器,并利用这些机会而不必放弃十年的代码?

    能够快速轻松地切换解算器的巨大优势。我知道有一家公司为他们的工作使用三种不同的求解器:他们尝试了两种不同的开源求解器,都在云中运行,如果这两种解决方案都找不到合适的解决方案,算法。开源解决者可以解决他们90%的问题,因此他们只需要使用商业解决方案的最后10%,这使他们可以大幅节省许可成本。

    我们在我的讨论过的一个选项工作就是使用商业求解器进行关键任务工作,而开源替代品则适用于培训或小规模原型设计等应用,而我们没有相同的要求。这样,我们可以最大限度地减少我们需要为商业解决方案获得许可的并发用户数量。

    (是的,仍然存在锁定平台的问题,但像AMPL这样的平台比

    便宜一个高端商业解决方案。)then显着

    One option we've discussed at my work is to use a commercial solver for mission-critical work, and open-source alternatives for applications like training or small-scale prototyping where we don't have the same requirements. That way we can minimise the number of concurrent users we need to license for the commercial solver.

    (And, yes, there is still an issue of lock-in with the platform, but platforms like AMPL are significantly cheaper than a high-end commercial solver.)

  • 2楼
  • AMPL是一种代数建模语言,并从该链接引用:

    AMPL的一个优点是其语法与   优化问题的数学表示法

    例如,这可以让您定义多组约束,而无需事先知道模型的维数。而且,也许你可以更快地对模型做出重大改变。 (你将不得不考虑你实际做到这一点的频率。)然而,有人可能会争辩说,AMPL的“明显优势”是它支持数十种不同的求解器。您可以创建模型并使用CPLEX解决它,但是然后决定使用不同的求解器(例如Gurobi,Xpress等)。在AMPL

    网页上,他们有以下建议:Solvers我们建议您测试替代求解器以确定哪个   为您的需求提供最佳的价格和性能平衡

    网页上说有一个Java API,因此应该允许您将它包含在Netbeans项目中,但我没有这方面的经验。

    The AMPL API At一天结束的时候,你也可以争辩说,这些“优点”是品味的问题。正如您已经完成的那样直接使用CPLEX Java API,如果它符合您的要求,它当然是一个有效的解决方案。它可能允许您更高效地构建模型,使用AMPL可能不支持的求解器特定/高级功能,并对模型制定具有更精细的控制。

    At the end of the day, you could also argue that these "advantages" are a matter of taste. Using the CPLEX Java API directly, as you have already done, is certainly a valid solution if it meets your requirements. It may allow you to build the model more efficiently, use solver-specific/advanced features that might not be supported by AMPL, and to have more fine-grained control over the model formulation.

  • 3楼
  • 完全同意罗克什所说的一切。另外请注意,不应以硬编码问题规模等细节的方式编写模型,无论您是使用代数建模语言还是通过更直接的API之一编写代码。

    此外,使用建模语言可以为您提供额外的抽象层次/层次,这可以提供帮助,特别是在与其他人分享或向别人解释模型时,与一系列标准问题类型等进行比较,但我更喜欢更坚果对'更直接的API'感觉',并且几乎不需要(或者有时间和预算)来深刻地重新构建我的模型。

  • 4楼
    • 即使GPL意味着“普遍”,但更新,更新的GPL即将诞生,因此给定的GPL对于某些任务而言比其他更“普遍”...... :-)理论上,为Pascal或Perl编写最有效的编译器无关紧要,所以实际上你可以用任何你想要的语言来编写,但是你不应该失去表达能力或者效率(例如,对于现在和Java相同的C#而言,MS编写比开源等效的编译器更好的编译器)。
    • 专业化 - 这就是为什么我们已经得到这么多:-)。在实现将业务问题转换为数学模型(又称建模)的特定任务时,没什么不同。有一个给定的建模层的整个想法是
      • 一种。你对这个特定的任务(又名数学建模)有最大的表现力。它强制实施一些最佳实践来模拟GPL中你没有被“强制”做的事情(1.你可以自由地做2.它向你推销=灵活性)。例如。 AMPL,GAMS,其他人正在混合声明性代码(又名模型代码)和程序代码(又名流程控制),这不是一种好的做法。另一方面,例如分离数据和一个抽象模型正在得到所有的建模语言,但有趣的是非常缓慢......
      • C。通过否.A可以更高效地维护代码(与API建模相反 - 我有客户说他们转向建模语言,因为API建模是快速模型改造的一个负担)
      • D。理论上你可以解决独立问题。
      • 如果你看看所有的建模语言都试图保持no.C除了OPL(这是历史原因)。但即使在OPL的情况下,你也可以得到约束编程和基于约束的调度(除了数学编程),AMPL / GAMS你不需要,但是它们是独立的...
    • $ Solver1和$ Solver2 + $ Freesolver比较有点损坏有四个原因
    • 一种。当涉及到大型/复杂问题(可能是LP正在例外)时,opensolvers在性能方面仍然非常遥远 - 我有客户 - 我记忆中有史以来最快的销售 - 当他们测试商业解决方案后“搭便车”。
      • B中。虽然与Solver1和Solver2相关的场景看起来似乎是合理的(Solver1,随着时间的推移,现任公司变得越来越昂贵),但我们可以看到$ Solver2(一个新来的人)实际上增加了定价的另一种方式4年7倍,有时甚至翻倍,而Solver1(现任)没有变化。
      • C。混合建模功能和求解器是一个错误。整个想法是,有人在API中编写模型是通过建模语言来坚持求解器的方式。至少,正如匈牙利人所说的那样,“你在习惯上获得的东西就会在渡船上失去它”,换句话说,“自由(即灵活性)与负责任地使用它相关联”。拥有解决方案的开发并不昂贵,即公司可以维护大量的求解器(对于少于10k $的公司可以有4个解算器用于开发)来测试对于任何给定模型哪个是最快的,然后选择最适合部署。另外,求解器只是拼图的一部分。例如。我有一个客户有不同的数据源,需要8个小时才能创建一个模型,4个小时来解决这个问题。这个客户会欢迎一个更高效的数据处理套件吗?还是会坚持求解器应该更快?在大多数情况下,建模者与业务隔离太多,虽然在他们看来,给定的模型是完美的,但数据如何填充是次要的,但是却造成或打破了良好的表现。我见证了API建模师正在转向建模语言,而不是其他方式,因为各种原因......但是正如有人在上面写道的那样,游戏中有很多“口味”,所以最终如果你对某种方法感觉更舒适,那么没有人会责怪你选择如此...... :-)毕竟比较/另一种方法是非常困难的,因为它几乎从不存在于某个特定情况下......所以最终重要的是从业务问题到速度快速解决的模型给定的应用程序上下文: - )
      • 唷,它很长......但我给了我所有的镜头... :-)
      • D. owning a solver for development is NOT expensive at all, i.e. a company can maintain large # of solvers (for less than 10k$ a company could have +4 solvers for development) to test which is the fastest for any given model and then choose the best suited for deployment.
    • in addition, solver is just one piece of the puzzle. E.g. I have a client who has disparate data sources and it takes 8hours to create a model and 4hours to solve it. Would this client welcome a more efficient data handling suite or would it insist that the solver should be faster? Modelers are too isolated from the business in most cases and while in their mind a given model is perfect, how it is populated by data is secondary, yet it makes or breaks a good performance.
    • I witness that API modelers are moving to modeling languages, not the other way around for various reasons...
    • but as somebody wrote above, there are lots of "tastes in the game", so eventually if you feel more confortable with a given approach then nobody can blame you to choose so... :-) after all it is very difficult to compare the/an other approach since it's almost never there on a given case... so eventually what counts is speed from business problem to a model which solve fast in the given application context :-)

    phew, it was long... but I gave all my shots... :-)

相关阅读: