mar*_*n56 6 modeling mixed-integer-programming
我有一个 Gurobi 许可证，我追求的是一个好的 MILP/LP 建模语言，这应该是
免费/开源
直观，即看起来像的东西（取自 MiniZinc）
无功整数：x；约束 x >= 0.5; 求解最小化 x；
快速：构建模型并将其发送到 Gurobi 的时间应该与最好的模型（AMPL GAMS 等）相似
灵活/强大（能够处理 3D+ 阵列、轻松激活/停用约束、为求解器提供初始解决方案等）
当然，如果我错了，请纠正我，AMPL GAMS 在 1) 处失败，Python 和 R 在 2)（也许在 3）处失败？）。
GLPK、Minizinc、ZIMPL 等怎么样？它们满足 1) 和 2)，但是 3) 和 4) 呢？在这方面，他们和 AMPL 一样好吗？如果没有，是否有满足 1-4 的建模语言？
我将 AMPL 与 Gurobi 一起用于中型 MIP（~ 100k-1m 变量？），并使用 MiniZinc（主要与 Gecode 一起使用）来解决较小的组合问题。我见过一些使用 R 和 Python 完成的 Gurobi 工作，但我自己还没有这样使用过。
我对其他选项不太熟悉。我的理解是 GAMS 与 AMPL 非常相似，我关于 AMPL 的大部分内容可能也适用于 GAMS，但我不能保证这一点。
当然，如果我错了，请纠正我，AMPL GAMS 在 1) 处失败，
是的，一般来说。有一个例外，它可能对您的特定要求没有帮助，但可能对其他人有用：您可以通过使用NEOS Web 服务免费使用 AMPL、Gurobi 和许多其他优化产品。这仅限于学术非商业目的，您必须授予 NEOS 与您发送的问题相关的某些权利；在使用之前一定要阅读这些服务条款。它还需要等待可用的服务器，因此如果速度是重中之重，那么这可能不适合您。
Python 和 R 在 2) 处失败（也许在 3）处失败？）。
以我有限的经验，对于（2）是肯定的。AMPL、GAMS 和 MiniZinc 是专门为定义优化问题而设计的，因此它们的语法比 Python 和 R 等语言更加用户友好也就不足为奇了。
另一方面是，如果您想做除了使用这些语言（Python/R/等）定义优化问题之外的任何事情。对于这个目的来说可能会更好。
关于速度：对于我通常处理的问题，AMPL 可能需要几秒钟的时间来构建和预求解 MIP 模型，而 Gurobi 则需要几分钟才能解决。显然，这会因硬件和问题细节而有所不同，但总的来说，与正在讨论的任何解决方案的解决时间相比，我预计构建时间会很短。即使有像 Gurobi 这样的优秀求解器，大型 MIP 也很难。我遇到的许多认真的优化程序员都使用 Python，所以我认为性能方面已经足够好了。
然而，这并不意味着语言/平台的选择与速度无关。AMPL（以及 GAMS）的一个很好的功能是预求解，它尝试在将问题发送到求解器之前减小问题的大小。我的标准问题有很多多余的变量和约束；AMPL 识别并消除了其中的许多问题，将问题规模减少了约 80%，并显着缩短了求解器时间（与我关闭预求解的运行相比，我有时会出于调试相关原因而这样做）。如果您预计会有大量冗余，这可能是一个考虑因素。
灵活/强大（能够处理 3D+ 数组、轻松激活/停用约束、为求解器提供初始解决方案等）
MiniZinc 最多可处理 6D 阵列，这可能足够也可能不够，具体取决于您的应用程序。
它在某些方面比 AMPL 更灵活，但在其他方面则较差。AMPL 有很多基于集合的功能，我觉得很有用（例如，我可以定义一个变量，其索引集类似于“相距不超过 500 公里的一对不同的城市”），而 MiniZinc 没有这个功能。OTOH，MiniZinc 似乎比 AMPL 更适合解算器跳跃，例如，如果我编写一个具有“all different”之类的组合约束的 MZ 模型，但然后尝试在无法识别此类约束的解算器上运行它，MZ 会翻译它转化为求解器可以处理的东西。
除了将它们注释掉之外，我还没有尝试过停用 MZ 中的约束，所以我无法在那里提供帮助，并且类似地提供初始解决方案。
总的来说，MiniZinc 是一个值得考虑的不错选择。相对于 AMPL 来说有一些优点和缺点（“免费”是一大优点！），但它填补了类似的空白。