本頁面由 Cloud Translation API 翻譯而成。

或工具版本資訊

本頁列出 OR-工具相關變更，包括新功能、錯誤修正，以及程式碼和安裝程序的改善項目。

如果您無法順利安裝 OR-Tools，請查看 OR-Tools 安裝操作說明中的「疑難排解」一節。如果其中未列出您的問題，請參閱 GitHub 上的問題。您也可以隨時建立新的問題，我們很樂意為您提供相關協助。

以下為 OR-Tools 的版本資訊，從最新版本開始。

2024 年 3 月

宣布推出 OR-Tools v9.9 版

我們已發布 OR-Tools 9.9 版，如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

您可以在 GitHub 找到版本資訊

2024 年 2 月

宣布推出 OR-Tools v9.8

我們已發布 OR-Tools 9.8 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

新增 Python 3.12。
新增對 Ubuntu 23.10 的支援

線性求解工具

將通訊埠 ModelBuilder 設為 .Net。
將 LogCallback 重新命名為 MbLogCallback，以避免與 SAT LogCallback 發生衝突。
擴充 ModelBuilder API：
- 新增指標限制。
- 新增提示支援。
- 新增模型複製功能。

數學最佳化

重新努力。

路線

新增「ROUTING_OPTIMAL」狀態。
將「RoutingModel」設為不可複製或可移動。
修正本地搜尋運算子的部分無限迴圈。
新增 PickupDeliveryPosition 內部結構。
新增 IsPickup() 和 IsDelivery() 方法。

SAT

減少大型模型的記憶體用量。
改善排程搜尋。
新增 Packing_precedences_lns。
並修正可行性提升
最佳化線性 pResolve 以及更好的 pResolve 記錄。
改善 int_abs、int_mod、int_prod 和 lin_max 的解析問題。
改善 Panda 支援
修正較少的錯誤。

GitHub 變更記錄

2023 年 8 月

宣布推出 OR-Tools v9.7 版

我們已發布 OR-Tools 9.7 版，如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

Drop Centos-8 (EOL)。
推送 Debian 10。
Drop Fedora [33, 36] (EOL)。
捨棄 Ubuntu 18.04 LTS (EOL)。
捨棄 Python 3.7 (EOL)。
停用 CMake (EOL) 中的 netcore3.1 支援。

模型建構工具 Python

允許使用 Pandas DataFrames 和系列建立變數。
- 查看作業
- 請參閱「bin_packing」
完成輸入資訊

PDLP

各種更新

CP-SAT

提升效能(feasibility_jump、lin_max)
改善剪接管理
新的 goal_shaving_search 工作站，專門用於改善目標的下限 (需要最小化時)
輸入 python cp_model.py 的註解
cp_model.py 中的 pandas 實驗性部分支援
- 查看作業
- 請參閱「bin_packing」
實驗性本地搜尋違規工作站：
- 已啟用，參數：num_violation_ls:xxx
- 針對線性模型 (linear、bool_or、bool_and、at_most_one、exactly_one) 完成最佳化
- 可與 lin_max、產品、部門搭配使用
- 支援 no_overlap、累計、迴路、路徑
- 停用 (沒有「no_overlap_2d」)
- 建議的 ls 工作站數量：num_workers -> num_violation_ls：(8, 1), (16, 2) (24, 3), (32, 4)

GitHub 變更記錄

2023 年 3 月

宣布推出 OR-Tools v9.6

我們已發布 OR-Tools 9.6 版，如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

新增 Fedora 37 和 38 支援。
捨棄 Python 3.6 (protobuf 不支援)。
在 macOS 上放置 Python 3.7 (scipy 不支援)。
在 CMake 中新增 net7.0 支援 (使用 -DUSE_DOTNET_7=ON)
將 netcore3.1 拖放到 nuget .org 套件中

依附元件

SCIP v801 -> v803 (注意：現在 SCIP 使用與 OSI 相容的授權)
絕對值 20220623.1 -> 20230105.0
Protobuf v21.5 -> v21.12
SWIG 4.1.1
Java JNA 5.11.0 -> 5.12.1

Bazel

新增 pybind11 支援。
新增 Java 包裝函式支援。

解題工具

PDLP：dd Python 包裝函式。
CP-SAT：提升效能
GLOP：調整解析度。
ModelBuilder：Python：改善 numpy 支援。
轉送：提升效能 (本地搜尋)

已知問題：

CP-SAT：忽略 pseudo_costs subsolver 會傳回無效參數 (請參閱 #3706)。

2022 年 11 月

宣布推出 OR-Tools v9.5

我們已發布 OR-Tools 9.5 版，如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

新增 Debian Sid 支援。
新增 Fedora 35 和 36 支援。
新增 Ubuntu 22.10 支援。
在 macOS 上放置 Python 3.6。
新增 Python 3.11 支援。

依附元件更新

Protobuf v19.4 -> v21.5。
SCIP 求解器 v800 -> v801。

CP-SAT

解析改善項目：max(陣列)、布林限制、線性限制。
交錯搜尋必須同時具確定性。
線性剪接：清除正方形和 int_prod 剪接次數；重新編寫切割管線。
指紋輸入模型和解決方案 (顯示於記錄中)。
改善排程功能。
常見的大量錯誤修正 (解決期間當機、在剪輯作業中當機、無法執行的解決方案、LNS 中的模型無法執行)。

國際化

透過重新編寫線性代數和透視選取規則來加快速度。

線性求解工具

新增 knapsack_interface.cc。
將 model_builder API 移至 Linear_solver 目錄下 (標頭和範例)。
新增 Gurobi 10 支援。

路線

為各種轉送驗證問題釋放少量剖析器。

2022 年 8 月

宣布推出 OR-Tools v9.4

我們已發布 OR-Tools 9.4 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台

新增 Debian-10 支援 (請參閱 #3029)。
新增 Ubuntu 22.04 LTS 支援 (請參閱 #3276)。附註：將不支援 .Net 3.1 (請參閱 dotnet/core#7038)。
移除 Ubuntu 21.10 支援。

其他

依語言分割封存檔，並將 CMake 設定新增至 C++ 設定 (#3200)。

圖表

將 ortools.graph.pywrapgraph 分割成：

ortools.graph.python.linear_sum_assignment.
ortools.graph.python.max_flow.
ortools.graph.python.min_cost_flow.

如此一來，您就能使用 numpy 加快問題的設定速度。

CP-SAT

改善項目：

安排 (傳播、剪接、下限值)。
MaxSAT (解析，核心式啟發式經驗法則)。
MIP 效能 (解析、剪接)。

2022 年 3 月

宣布推出 OR-Tools v9.3 版

我們已發布 OR-Tools 9.3 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

推送 Debian-10 支援。
將支援 Ubuntu-16.04。
捨棄 .NET Framework 4.5.2。

依附元件更新

新增 Eigen 3.4.0。
新增 Google re2 2021-11-01。
Protobuf 3.19.1 -> 3.19.4。
SCIP 7.0.1 -> v800。

Python

新增 pybind11。

功能

將 PDLP 新增為實驗功能。
新增 MathOpt 為實驗性質。

CP-SAT

重新命名幾個 API 以確保一致性，例如：LinearExpr.ScalProd. -> LinearExpr.WeightedSum.。
新增 AddAtLeastOne/AddAtMostOne 個方法 (共 AddExactlyOne 個)。
新增所有語言的AddMultiplicationConstraint(z, x, y)。
新增所有語言的AddMultipleCircuit()。

C++

顯性 ctor IntVar(BoolVar)。
移除了 LinearExpr::Add*，並替換為運算子，例如 LinearExpr +=。
在線性運算式中加入算術運算子。
已移除 LinearExpr::BooleanSum/BooleanScalProd，請使用 Sum/WeightedSum。
新增 CpModelBuilder::FixVariable()，將變數網域覆寫為單一值。

Java

重新編寫 LinearExpr，新增漸進式建構工具類別：LinearExpr.newBuilder().add(x).addSum(<array of variables>).build()。
遵循 C++ API：Circuit、MultipleCircuit、Cumulative、Reservoir、AllowedAssignment 和 ForbiddenAssignment 現在會傳回含有漸進式 API 的特殊類別，用來新增變數、字詞、需求...

C

記錄所有方法。
遵循 C++ API：Circuit、MultipleCircuit、Cumulative、Reservoir、AllowedAssignment 和 ForbiddenAssignment 現在會傳回含有漸進式 API 的特殊類別，用來新增變數、字詞、需求...
新增 LinearExprBuilder 類別，以漸進方式建構運算式。

建構系統

CMake

最低 CMake 須為 3.18 以上。

廠牌

現在請在內部使用以 CMake 為基礎的版本。

2021 年 12 月

宣布推出 OR-Tools v9.2 版

我們已發布 OR-Tools 9.2 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

新增對 Ubuntu 21:10 (上次滾動式) 的支援。

依附元件更新

.Net TFM update net5.0 -> net6.0 (需要 .Net SDK 6.0 LTS 和 .Net SDK 3.1 LTS)。
abseil-cpp 20210324.2 -> 20211102.0。
Protobuf 3.18.0 -> 3.19.1。
Googletest 1.10.0 -> 1.11.0。
Python：加上 numpy >= 1.13.3。
在 MacOS 中，在 -O1 中編譯 Coin-OR，以免在執行器中當機。

路線

改善篩選器。
改善第一個解決方案經驗法則。
改善廣告插播時間點的位置。

CP-SAT

破壞性變更

基礎通訊協定緩衝區與先前的版本不相容。所有已儲存的通訊協定緩衝區都必須使用新版建構工具 API (在 C++、Python、Java 和 .NET) 重新產生
具體來說，隨著我們移除舊欄位 (開始、大小和結束)，並重新命名新欄位 (使用 _view) 以使用已移除欄位的名稱，間隔 protobuf 已清除。

新功能

all_different、reservoir、modulo、multiplication 和 division 限制可在需要整數變數的所有位置接受正負運算式 (a * var + b)。
目標接受浮點係數 (請參閱 C++/Java/.NET 中的 DoubleLinearExpr 類別。請參閱 Python 中的 knapsack_2d_sat.py 範例)。
no_overlap_2d 限制支援選用間隔。
C++ API 會實作 + 和 * 運算子來建構運算式。

改善項目

改善解析程式碼。
校準模型檢查工具。
重做水庫限制。
為 no_overlap_2d 限制新增能夠活力四射的剪接。
改善編碼限制的線性放寬 (literal implies var == value)。

已淘汰和已移除的方法

已淘汰 C++ BooleanSum 和 BooleanScalProd。只要使用 Sum 和 ScalProd。
已移除 C++ AddLinMinEquality 和 AddLinMaxEquality。只要使用 AddMinEquality 和 AddMaxEquality。

日後不相容的問題

日後，我們會重新編寫 Java 模型層，使其更接近 C++ 層。
在 C++ 模型層中，我們會明確設定 IntVar(BoolVar var) ctor。
我們嘗試讓 Python API PEP 8 符合規範 (使用 snake_case 名稱)。發生這種情形時，我們會提供用來移植程式碼的 sed 檔案。

建構系統

Bazel

修正 Windows 版本。

CMake

新增 FETCH_PYTHON_DEPS 選項 (預設為 ON)。
新增選用的 GPLK 解題工具支援 (預設為 -DUSE_GLPK=OFF)。

Python

在大部分的 CP-SAT API 中支援 numpy 整數。
修正缺少__version__的問題。

2021 年 9 月

宣布推出 OR-Tools v9.1

我們已發布 OR-Tools 9.1 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

Python：使用 manylinux2014 映像檔 (請參閱 PEP 599)。
Python：使用 manylinux2014_aarch64 映像檔新增 aarch64 linux 的支援。
.Net：新增 .Net 5.0 支援。

依附元件更新

abseil-cpp 20210324.1 -> 20210324.2。
Protobuf 3.15.8 -> 3.18.0。
SCIP 7.0.1 -> 主要執行個體。
Googletest 1.8.0 -> 1.10.0。
Python：在 cp_model.py 中使用 warning (請參閱 #2530)。
python：absl-py 0.11 -> 0.13。

CMake

最低版本需求為 3.14 至 3.15 (請參閱 #2528)。
Python：串場廣告最低需求版本為 3.14 -> 3.18 (請參閱 #2774)。

廠牌

Make-based 建構作業已淘汰，請遷移至 CMake 或 Bazel，以便從原始碼進行建構。

Java

改善原生資料庫載入器的穩定性 (請參閱 #2742)。
修正在轉送模型或限制解析器時，JVM Garbage Collector 異常終止的問題 (請參閱 #2091) (請參閱 #2466)。
修正使用多個工作站時的 CP-SAT 記錄回呼異常終止問題 (請參閱 #2775)。

CP-SAT

改善 LNS 程式碼的穩定性 (請參閱 #2525)。
改善排程程式碼：打造新的工廠方法，可建立固定大小間隔、新的搜尋經驗法則、改善解析和新的線性切割。
改善路由程式碼：全新的專屬 LNS。
改善模型檢查工具。目前情況更加精簡，特別是 w.r.t. 潛在的溢位。
改善 MIP 程式碼：改善 MIP 和 CP 模型的線性放鬆以及改善多個解析能力。
提升搜尋多樣性。如果使用超過 12 個工作站，請新增工作站，專門用於改善目標的下限。
變更平行處理程式碼：根據預設，解題工具現在會使用所有可用的核心。使用 num_search_parameters 指定平行處理量。
淘汰 SearchAllSolutions 和 SolveWithSolutionCallback。
Python API：在 model.Add() 呼叫之外使用 var == ... 或 var != ... 時，使用較多的踏板檢查。

2021 年 4 月

宣布推出 OR-Tools v9.0

我們已發布 OR-Tools 9.0 版，如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

依附元件更新

Abseil-cpp 20200923.3 已更新為 20210324.1 LTS。
Protobuf 3.15.3 已更新至 3.15.8。
Java：jna-platform 5.5.0 已更新至 5.8.0

Java

OR-Tools 現已在 Maven Central 提供 (詳情請參閱 com.google.ortools:ortools-java)。

修正錯誤

改善使用 CP-SAT 解題工具時的多執行緒作業 (請參閱 #1588)。
修正 std::vector&ltstd::string&gt 的 Python 包裝函式支援 (請參閱 #2453)。
修復 CPLEX 支援 (請參閱 #2470)。

已知的破壞性變更

在 Python、Java 和 .Net 中新增記錄器存取權 (請參閱 #2245)。
以 cstdint 中提供的自訂 Google 類型取代所有自訂 Google 類型。

CP-SAT

SearchForAllSolutions()、SearchAllSolutions() 和 SolveWithSolutionCallback() 方法已淘汰。請改用 Solve()。
改善 Python 標準運算子支援。這可能會導致「不正確」的程式碼。

2021 年 3 月

宣布推出 OR-Tools 8.2 版

我們已發布 OR-Tools 8.2 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

依附元件更新

Abseil-cpp 20200923.2 已更新為 20200923.3 LTS。
Protobuf 3.14.0 已更新至 3.15.3。

路線

新增 RoutingModel.RegisterTransitMatrix() 和 RoutingModel.RegisterUnaryTransitVector()。
將 RoutingModel.AddVectorDimension() 和 RoutingModel.AddMatrixDimension() 的傳回值改為 std::pair&ltint, bool&gt，其 int 為大眾運輸評估工具 ID。

2020 年 12 月

宣布推出 OR-Tools v8.1

我們已發布 OR-Tools 8.1 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

依附元件更新

Abseil-cpp 20200923 已更新為 20200923.2 LTS。
Protobuf 3.13.0 已更新至 3.14。
新增對 Gurobi 9.1.0 的支援
捨棄 GLog 依附元件 (已由自訂實作取代，視 abseil-cpp 標記而定)
放置 GFlag 依附元件 (已由 abseil-cpp 旗標元件取代)

修正錯誤

修正 Gurobi 浮動授權的雙重計數 (請參閱 #2227)。
修正 Windows 版本 (請參閱 #2200)。

2020 年 10 月

宣布推出 OR-Tools 8.0 版

我們已發布 OR-Tools 8.0 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

新增了對 Python 3.9 的支援 (#2187)
停止支援 Python 3.5 (#2186)  的支援
停止支援 Ubuntu 16.04 LTS (#2188)
停止支援 Ubuntu 19.10 (#2188)

依附元件更新

Abseil-cpp 20200225.2 已更新為 20200923 LTS。
Protobuf 3.12.2 已更新為 3.13.0。

已知的破壞性變更

現在，轉送和 CP-SAT 原始碼會使用部分 C++17 功能。警告：如果您提供自己的 abseil-cpp 版本，請確認也是根據 C++17 建構版本。
MPSolver::CreateSolver 簽名已變更。模型名稱引數已遭捨棄。

CMake

修正使用 -DUSE_SCIP=OFF 時停用 SCIP 支援的問題 (請參閱 #2129)。
將範例和範例整合至 CMake 建構系統。注意：您可以使用 -DBUILD_SAMPLES=OFF 和 -DBUILD_EXAMPLES=OFF 停用此功能。附註：您可以使用 -DBUILD_<LANG>_SAMPLES=OFF 或 -DBUILD_<LANG>_EXAMPLES=OFF 針對特定語言停用此功能。
- 在以下位置使用 <LANG>：
- CXX,
- PYTHON,
- 「JAVA」和
- DOTNET.

廠牌

需要 Make >= 4.3 (使用 Make eval 函式)。
需要 CMake >= 3.14 (使用 CMake --verbose 選項)。
新增使用 -DUSE_SCIP=OFF 停用 SCIP 支援的選項 (請參閱 #2134)。
新增使用 -DUSE_COINOR=OFF 停用 CLP 和 CBC 支援的選項。

Java

OR-Tools 現在會產生 Maven 套件 (請參閱 #202)。

修正錯誤

修正 FreeBSD 上的 C++ 和 Python 版本 (請參閱 #2126)。
修正 Windows 中的偵錯版本 (請參閱 #2077)。
修正 Windows 上 CP-SAT 同時持續停止運作的問題 (請參閱 #2001、#2019)。

2020 年 7 月

宣布推出 OR-Tools v7.8

我們已發布 OR-Tools 7.8 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

依附元件更新

Gurobi 9.0.2 現已預先整合到預先建構的二進位檔中。這會在 MAC OS X 和 Windows 中 Gurobi 安裝程式的預設安裝路徑或 GUROBI_HOME 目錄中搜尋 gurobi 90 共用資料庫。
SCIP 7.0.1 現已整合至預先建構的二進位檔。請務必先遵循 SCIP 授權規定，再使用。
新增了選用的 Xpress 求解器 8.9.0 支援。

線性求解工具

新增靜態 LinearSolver::CreateSolver() 方法，簡化整合線性解題器後端的檢查程序。且支援所有語言。

修正錯誤

已修正以 FreeBSD 為基礎的 CMake 版本。
已修正累積剪接產生的 CP-SAT 排序。
修正 .Net 包裝函式中的線性解題工具記憶體流失問題。

2020 年 6 月

宣布推出 OR-Tools v7.7

我們已發布 OR-Tools 7.7 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

依附元件更新

Abseil-cpp b832dce 已更新為 c51510d (LTS 20200225.2)。
Protobuf 3.11.4 已更新至 3.12.2。

新功能和改善項目

CP-SAT 解題器現在會在滿意度模型 (即無目標) 中傳回 Optimal，而不是 Feasible。
新增了 MIP 社群的可行泵系統經驗法則。

修正錯誤

已修正 CP-SAT 多執行緒當機問題 (請參閱 #2005)。

2020 年 4 月

宣布推出 OR-Tools v7.6

我們已發布 OR-Tools 7.6 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

CP-SAT 新功能

我們在 CP-SAT 解題工具中新增了下列功能：

改善到達網頁上的切割機管理程序。
偵錯工具。

依附元件更新

Abseil-cpp 8ba96a8 已更新為 b832dce (LTS 20200225)。

修正錯誤

已修正解析中的 CP-SAT UNSAT 錯誤 (請參閱 #1908)。
已修正 swigwin.exe 網址。
修正了 Java 和 .Net 的 SWIG 類型對應管理。

2020 年 1 月

宣布推出 OR-Tools 7.5 版

我們已推出 OR-Tools 7.5 版，如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

新增了對 Python 3.8 的支援 (#1719)
已捨棄從 Visual Studio 2017 來源的編譯支援 (#1852)。
將支援從 Centos 7 更新為 Centos 8。(#1827)。

依附元件更新

protobuf v3.10.0 已更新至 3.11.2 版 (#1829)。

修正錯誤

下列問題已在 OR-Tools v7.5 版中修正 (如需完整清單，請參閱里程碑 7.5)。

請特別注意以下幾點：

修正組裝載入問題。請參閱 #1421。
公開 RouteIndexManager 的 GetStartIndex() 和 GetEndIndex() 方法 (#1843)。
修正 SWIG 以移除毀損的方法 (#1838、#1276)。

2019 年 10 月

宣布推出 OR-Tools v7.4

我們已發布 OR-Tools 7.4 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

新功能和改善項目

CP-SAT 解題工具現在會檢查不支援強制執行文字的限制。如果這類限制具有強制執行常值，模型檢查工具會在解決問題之前傳回錯誤。
更快速且更快速地搜尋路線庫。
線性解題工具現在支援第三方軟體 Xpress-MP。您必須從來源重新建立 OR-工具，才能使用該工具。
NuGet 套件的架構已完全重新編寫。特別要注意的是，此 API 現在在 Windows 平台上支援 .NET Framework 4.5.2 以上版本。

已淘汰的平台

如 2019 年 7 月版本資訊的公告所述，OR-Tools 不再支援 Python 2.7。

依附元件更新

Protobuf 3.9.0 已更新為 3.10.0。

2019 年 8 月

宣布推出 OR-Tools v7.3 版

我們已推出 OR-Tools 7.3 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

已淘汰的平台

為配合 Google 遷移至 Python 3，我們現已停止支援 Python 2.7。這會是支援 Python 2.7 的 OR-Tools 最後一個版本。

依附元件更新

Protobuf 3.8.0 已更新為 3.9.0。

修正錯誤

OR-Tools v7.3 版中已修正下列問題。(如需完整清單，請參閱 Kanban 7.3 版)。

請特別注意以下幾點：

修正 Java 上的 init/int64 投放問題 (#1448)。
修正處理空白累計限制時的解析檢查。

2019 年 7 月

宣布推出 OR-Tools v7.2 版

我們已推出 OR-Tools 7.2 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

平台異動

為配合 Google 遷移至 Python 3，我們現已停止支援 Python 2.7。最多將會有一個支援 Python 2.7 的 OR-Tools 版本。
Ubuntu 18.10 已更新至 Ubuntu 19.04。
開始支援從 Visual Studio 2019 中的來源編譯。
Windows 已不再支援 Python 3.5；請使用 Python 3.6 以上版本。

依附元件更新

我們現在指定 CBC 2.10.3。
我們現在指定 Protobuf 3.8.0。

CP-SAT

我們針對搜尋、平行處理和線性放鬆進行多項改善，
已在 Python 中新增 LinearExpr.Sum() 和 LinearExpr.ScalProd() API。
淘汰 C# 中的 IntVar[].Sum() 和 IntVar[].ScalProd() API。
C++：移除了 SolveWithModel()，因為它與 SolveCpModel() 重複。
在 Java API 中新增 CpModel.addGreaterThan() 和 CpModel.addLessThan() 方法。

線性解題工具

已為 Python、Java 和 C# 新增 MPSolver.SetHint() (受 SCIP 和 Gurobi 支援)。
已為 Python、Java 和 C# 新增 MPSolver.SetNumThreads() (由 CBC、Gurobi 和 SCIP 支援)。
已重新編寫對 SCIP 6.0.1 的支援。

參考說明文件

我們為所有語言和所有工具 (演算法、路由、圖表、Linear_solver 和 CP-SAT) 新增了 Doxygen 與 pdoc3 參考手冊。請參閱 OR 工具參考手冊。
C++ (所有產品) 和 CP-SAT (C++、Python、Java) 的參考說明文件是完整的。
我們正在將所有 C++ 說明文件匯出至 Python 和 Java。
缺乏 .NET 說明文件，我們未來也沒有辦法改善這一點。我們保留了它，因為這個物件仍會顯示可用的 API。

2019 年 5 月

宣布推出 OR-Tools v7.1

我們已發布 OR-Tools 7.1 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

必要依附元件的變更

OR-Tools v7.1 含有下列全新和更新後的依附元件：

glog v0.3.5 已更新為 v0.4.0
protobuf v3.6.1 已更新至 3.7.1 版
Cbc 2.9.9 已更新為 2.10.1
Cgl 0.59.10 已更新至 0.60.1
Clp 1.16.11 已更新為 1.77.1
Osi 0.107.9 已更新為 0.108.1
CoinUtils 2.10.14 已更新為 2.11.1

CP-SAT API 變更

以下各節說明 OR-Tools 7.1 中 CP-SAT API 的異動說明。

使用網域建立變數。
在線性運算式中使用網域。
使用線性運算式輔助程式。

使用網域建立變數

以下範例說明如何建立含有非連續網域的整數變數。這會取代已移除的方法 NewEnumeratedIntVar()。其中，變數 x 可以是 1、3、4 或 6 的任一個：

Python

model.NewIntVarFromDomain(cp_model.Domain.FromValues([1, 3, 4, 6]), 'x')

C++

model.NewIntVar(Domain::FromValues({1, 3, 4, 6}));

Java

model.newIntVarFromDomain(Domain.fromValues(new long[] {1, 3, 4, 6}), "x");

C#

model.NewIntVarFromDomain(Domain.FromValues(new long[] {1, 3, 4, 6}), "x");

您也可以使用間隔清單建立變數。下方變數 x 的限制為 1、2、4、5 或 6：

Python

model.NewIntVarFromDomain(cp_model.Domain.FromIntervals([[1, 2], [4, 6]]), 'x')

C++

model.NewIntVar(Domain::FromIntervals({ {1, 2}, {4, 6} }));

Java

model.newIntVarFromDomain(Domain.fromIntervals(new long[][] { {1, 2}, {4, 6} }), "x");

C#

model.NewIntVarFromDomain(Domain.FromIntervals(new long[][] { new long[] {1, 2}, new long[] {4, 6} }), "x");

在線性運算式中使用網域

以下範例說明如何限制非連續網域的線性運算式。以下為線性運算式 Linear_expr，定義於 5、6、8、9 和 10：

Python

model.AddLinearExpressionInDomain(linear_expr, cp_model.Domain.FromIntervals([(5, 6), (8, 10)]))

C++

model.AddLinearConstraint(linear_expr, Domain::FromIntervals({ {5, 6}, {8, 10} }))

Java

model.addLinearExpressionInDomain(linear_expr, Domain.fromIntervals(new long[][] { {5, 6}, {8, 10} }))

.Net

model.AddLinearExpressionInDomain(linear_expr, Domain.FromIntervals(new long[][] {new long[] {5, 6}, new long[] {8, 10} }));

使用線性運算式輔助程式

以下範例說明如何使用輔助方法建立加總和純量產品。以下是我們希望 x + y == 20 和 4 * x + 2 * y = 56：

Python

model.Add(x + y == 20)
model.Add(4 * x + 2 * y == 56)

C++

cp_model.AddEquality(LinearExpr::Sum({x, y}), 20);
cp_model.AddEquality(LinearExpr::ScalProd({x, y}, {4, 2}), 56);

Java

model.addEquality(LinearExpr.sum(new IntVar[] {x, y}), 20);
model.addEquality(LinearExpr.scalProd(new IntVar[] {x, y}, new long[] {4, 2}), 56);

.Net

model.Add(x + y == 20);
model.Add(4 * x + 2 * y == 56);

2019 年 3 月

宣布推出 OR-Tools 7.0 版

我們已推出 OR-Tools 7.0 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

支援平台異動

OR-Tools v7.0 版不再支援以下平台：

Visual C++ 2015
Ubuntu 14.04
Linux 上的 Python 3.4

如果您使用上述其中一個平台，仍可安裝 OR-Tools 6.10 版。

必要依附元件的變更

OR-Tools v7.0 含有下列全新和更新後的依附元件：

新推出：Abseil-cpp
gflags 2.2.1 已更新至 2.2.2

以下各節說明 OR-Tools 7.0 的新功能和改善項目。

轉送程式的全新索引管理員
支援提供取貨和送貨服務的 VRP
支援 Java 和 C#中的 lambda 函式

為轉送程式新增索引管理員

在 OR-Tools v7.0 中，車輛路線程式必須使用新的 RoutingIndexManager。這可確保位置的標準索引與解題工具使用的內部索引一致，並有助於避免程式碼中出現錯誤。

新的 RoutingIndexManager 需要稍微變更轉送程式，詳情請參閱以下各節：

在 C++ 和 Java 中納入或匯入 RoutingIndexManager。
宣告 RoutingIndexManager
將 RoutingIndexManager 新增至維度回呼。
使用 RoutingIndexManager 列印解決方案。

納入/匯入`RoutingIndexManager`

在 OR-Tools 7.0 中，C++ 和 Java 中的轉送程式必須包含或匯入 RoutingIndexManager，如以下範例所示：

C++

#include "ortools/constraint_solver/routing_index_manager.h"

Java

import com.google.ortools.constraintsolver.RoutingIndexManager;

Python 和 C# 匯入項目維持不變。

宣告 `RoutingIndexManager`

在 OR-Tools v7.0 中，路由程式必須宣告 RoutingIndexManager 並建立轉送模型，如以下範例所示：

Python

manager = pywrapcp.RoutingIndexManager(num_locations, num_vehicles, depot)
routing = pywrapcp.RoutingModel(manager)

C++

RoutingIndexManager manager(num_locations, num_vehicles, depot);
RoutingModel routing(manager);

Java

RoutingIndexManager manager = new RoutingIndexManager(numLocations, numVehicles, depot);
RoutingModel routing = new RoutingModel(manager);

.Net

RoutingIndexManager manager = new RoutingIndexManager(numLocations, numVehicles, depot);
RoutingModel routing = new RoutingModel(manager);

RoutingIndexManager 的引數如下：

商家地點數量
車輛數量
車庫的索引 (所有車輛的起點和終點)

回呼

在 OR-Tools v7.0 中，您需要使用 RoutingIndexManager 建立回呼 (例如距離回呼)，然後再傳遞至解題工具。以下範例說明如何建立距離回呼。

Python

    def distance_callback(from_index, to_index):
        """Returns the distance between the two nodes."""
        # Convert from routing variable Index to distance matrix NodeIndex.
        from_node = manager.IndexToNode(from_index)
        to_node = manager.IndexToNode(to_index)
        return data["distance_matrix"][from_node][to_node]

    transit_callback_index = routing.RegisterTransitCallback(distance_callback)
    routing.SetArcCostEvaluatorOfAllVehicles(transit_callback_index)

C++

  const int transit_callback_index = routing.RegisterTransitCallback(
      [&data, &manager](const int64_t from_index,
                        const int64_t to_index) -> int64_t {
        // Convert from routing variable Index to distance matrix NodeIndex.
        const int from_node = manager.IndexToNode(from_index).value();
        const int to_node = manager.IndexToNode(to_index).value();
        return data.distance_matrix[from_node][to_node];
      });
  routing.SetArcCostEvaluatorOfAllVehicles(transit_callback_index);

Java

    final int transitCallbackIndex =
        routing.registerTransitCallback((long fromIndex, long toIndex) -> {
          // Convert from routing variable Index to user NodeIndex.
          int fromNode = manager.indexToNode(fromIndex);
          int toNode = manager.indexToNode(toIndex);
          return data.distanceMatrix[fromNode][toNode];
        });
    routing.setArcCostEvaluatorOfAllVehicles(transitCallbackIndex);

.Net

        int transitCallbackIndex = routing.RegisterTransitCallback((long fromIndex, long toIndex) =>
                                                                   {
                                                                       // Convert from routing variable Index to
                                                                       // distance matrix NodeIndex.
                                                                       var fromNode = manager.IndexToNode(fromIndex);
                                                                       var toNode = manager.IndexToNode(toIndex);
                                                                       return data.DistanceMatrix[fromNode, toNode];
                                                                   });
        routing.SetArcCostEvaluatorOfAllVehicles(transitCallbackIndex);

方法 IndexToNode 會將溶液使用的內部位置索引轉換為距離矩陣的標準索引。

在 v7.0 中，您不必將回呼直接傳遞給解題工具，請在 7.0 版中先建立 transit callback index，參照回呼，然後將該回呼傳遞至解題工具 (在本例中為 SetArcCostEvaluatorOfAllVehicles)。

尺寸

以下範例說明如何根據需求和容量建立維度，以解決「載客車輛路線」問題。

Python

    def demand_callback(from_index):
        """Returns the demand of the node."""
        # Convert from routing variable Index to demands NodeIndex.
        from_node = manager.IndexToNode(from_index)
        return data["demands"][from_node]

    demand_callback_index = routing.RegisterUnaryTransitCallback(demand_callback)
    routing.AddDimensionWithVehicleCapacity(
        demand_callback_index,
        0,  # null capacity slack
        data["vehicle_capacities"],  # vehicle maximum capacities
        True,  # start cumul to zero
        "Capacity",
    )

C++

  const int demand_callback_index = routing.RegisterUnaryTransitCallback(
      [&data, &manager](const int64_t from_index) -> int64_t {
        // Convert from routing variable Index to demand NodeIndex.
        const int from_node = manager.IndexToNode(from_index).value();
        return data.demands[from_node];
      });
  routing.AddDimensionWithVehicleCapacity(
      demand_callback_index,    // transit callback index
      int64_t{0},               // null capacity slack
      data.vehicle_capacities,  // vehicle maximum capacities
      true,                     // start cumul to zero
      "Capacity");

Java

    final int demandCallbackIndex = routing.registerUnaryTransitCallback((long fromIndex) -> {
      // Convert from routing variable Index to user NodeIndex.
      int fromNode = manager.indexToNode(fromIndex);
      return data.demands[fromNode];
    });
    routing.addDimensionWithVehicleCapacity(demandCallbackIndex, 0, // null capacity slack
        data.vehicleCapacities, // vehicle maximum capacities
        true, // start cumul to zero
        "Capacity");

.Net

        int demandCallbackIndex = routing.RegisterUnaryTransitCallback((long fromIndex) =>
                                                                       {
                                                                           // Convert from routing variable Index to
                                                                           // demand NodeIndex.
                                                                           var fromNode =
                                                                               manager.IndexToNode(fromIndex);
                                                                           return data.Demands[fromNode];
                                                                       });
        routing.AddDimensionWithVehicleCapacity(demandCallbackIndex, 0, // null capacity slack
                                                data.VehicleCapacities, // vehicle maximum capacities
                                                true,                   // start cumul to zero
                                                "Capacity");

列印解決方案

在 OR-Tools 7.0 版中，您必須使用 RoutingIndexManager 來顯示解決方案中的車輛路線。以下範例說明如何以所有支援的語言列印解決方案。

Python

def print_solution(manager, routing, solution):
    """Prints solution on console."""
    print(f"Objective: {solution.ObjectiveValue()}")
    index = routing.Start(0)
    plan_output = "Route for vehicle 0:\n"
    route_distance = 0
    while not routing.IsEnd(index):
        plan_output += f" {manager.IndexToNode(index)} ->"
        previous_index = index
        index = solution.Value(routing.NextVar(index))
        route_distance += routing.GetArcCostForVehicle(previous_index, index, 0)
    plan_output += f" {manager.IndexToNode(index)}\n"
    plan_output += f"Distance of the route: {route_distance}m\n"
    print(plan_output)

C++

//! @brief Print the solution
//! @param[in] manager Index manager used.
//! @param[in] routing Routing solver used.
//! @param[in] solution Solution found by the solver.
void PrintSolution(const RoutingIndexManager& manager,
                   const RoutingModel& routing, const Assignment& solution) {
  LOG(INFO) << "Objective: " << solution.ObjectiveValue();
  // Inspect solution.
  int64_t index = routing.Start(0);
  LOG(INFO) << "Route for Vehicle 0:";
  int64_t distance{0};
  std::stringstream route;
  while (!routing.IsEnd(index)) {
    route << manager.IndexToNode(index).value() << " -> ";
    const int64_t previous_index = index;
    index = solution.Value(routing.NextVar(index));
    distance += routing.GetArcCostForVehicle(previous_index, index, int64_t{0});
  }
  LOG(INFO) << route.str() << manager.IndexToNode(index).value();
  LOG(INFO) << "Distance of the route: " << distance << "m";
  LOG(INFO) << "";
  LOG(INFO) << "Advanced usage:";
  LOG(INFO) << "Problem solved in " << routing.solver()->wall_time() << "ms";
}

Java

  /// @brief Print the solution.
  static void printSolution(
      DataModel data, RoutingModel routing, RoutingIndexManager manager, Assignment solution) {
    // Solution cost.
    logger.info("Objective : " + solution.objectiveValue());
    // Inspect solution.
    logger.info("Route for Vehicle 0:");
    long routeDistance = 0;
    String route = "";
    long index = routing.start(0);
    while (!routing.isEnd(index)) {
      route += manager.indexToNode(index) + " -> ";
      long previousIndex = index;
      index = solution.value(routing.nextVar(index));
      routeDistance += routing.getArcCostForVehicle(previousIndex, index, 0);
    }
    route += manager.indexToNode(routing.end(0));
    logger.info(route);
    logger.info("Distance of the route: " + routeDistance + "m");
  }

.Net

    /// <summary>
    ///   Print the solution.
    /// </summary>
    static void PrintSolution(in RoutingModel routing, in RoutingIndexManager manager, in Assignment solution)
    {
        Console.WriteLine("Objective: {0}", solution.ObjectiveValue());
        // Inspect solution.
        Console.WriteLine("Route for Vehicle 0:");
        long routeDistance = 0;
        var index = routing.Start(0);
        while (routing.IsEnd(index) == false)
        {
            Console.Write("{0} -> ", manager.IndexToNode((int)index));
            var previousIndex = index;
            index = solution.Value(routing.NextVar(index));
            routeDistance += routing.GetArcCostForVehicle(previousIndex, index, 0);
        }
        Console.WriteLine("{0}", manager.IndexToNode((int)index));
        Console.WriteLine("Distance of the route: {0}m", routeDistance);
    }

支援提供自取和外送服務的 VRP

OR-Tools v7.0 支援解決車輛路線問題 (VRP) 問題，以便解決車輛路線問題 (VRP)，目的是為車輛在各地接送貨物尋找最短路線。設定問題的方式與標準 VRP 類似，但除此之外，您還需要為每個項目指定一組 (i, j)，其中是上車地點，j 是上車地點。路線規劃解析工具會傳回車輛路線，因此每組 (i, j)、i 和 j 都位於同一條路線，而車輛會在 j 之前造訪 i。

如需可解決這類問題的範例，請參閱「運用取貨和配送服務安排車輛轉送」一文。

支援 lambda 函式

OR-Tools v7.0 現在支援在 C# 和 Java 中使用 lambda 函式 (除了已支援的 C++ 和 Python 之外)。Lambda 函式可讓您輕鬆定義路線程式中的回呼。但是，如果您想讓程式碼更容易閱讀，可以使用標準函式定義回呼。

上方的 C# 和 Java 回呼範例說明如何使用 lambda 函式定義回呼。

2018 年 11 月

宣布推出 6.10 版

我們已推出 OR-Tools 6.10 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

以下各節說明 6.10 版的新功能和改善項目。

簡化用於建構及執行程式的指令

在 6.10 版中，您可以輸入下列指令來建構及執行程式：

make run SOURCE=relative/path/to/program.cc

其中 <var>relative/path/to</var> 是包含程式的目錄路徑。

如要在不執行程式的情況下建構程式，請輸入：

make build SOURCE=relative/path/to/program.cc

如需依語言執行程式的特定操作說明，請參閱「開始使用 OR-Tools」。

支援 SCIP 6.0.0

OR-Tools 現已支援 SCIP 6.0.0。

二進位檔

二進位發布內容使用 Java JDK 8 (Ubuntu 14.04 專用 JDK 7) 建構而成。

CP-SAT 解析工具

更新 API

新增 C++ CP-SAT CpModelBuilder API。

示例

部分範例已移至他處。

將社群範例移至 examples/contrib。
將部分範例移至 ortools/<var>component</var>/samples (例如 ortools/linear_solver/samples/simple_program.java)

2018 年 9 月

宣布推出 6.9 版

我們已發布 OR-Tools 6.9 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

已更新依附元件

Protobuf 3.5.1 -> 3.6.1。
SCIP 4.0 -> 6.0。

CP-SAT 解析工具

API 的破壞性變更 - 完整詳細資料這裡：
在 Python 中將 SolveWithSolutionObserver 重新命名為 SolveWithSolutionCallback。

在 Python 中，將 CpSolverSolutionCallback 類別中的 NewSolution 重新命名為 OnSolutionCallback。以下範例顯示在 Python 中建立解決方案回呼的新方式。

class MySolutionCallback(cp_model.CpSolverSolutionCallback):
def init(self):
cpmodel.CpSolverSolutionCallback.init(self)
self._solution_count = 0

def OnSolutionCallback(self):
print('Solution {}, time = {}s, objective = {}, makespan = {}'.format(
  self.solution_count,
  self.WallTime(),
  self.ObjectiveValue(),
  self.Value(makespan)))
self.solution_count += 1

在 Python、Java 和 C# 的解決方案回呼上公開 StopSearch。如需說明文件，請按這裡。
使用 Python、Java 和 C# 公開 ModelStats 和 CpSolverResponseStats。
改善 Python docstring 說明文件。如需說明文件，請按這裡。
解析工具介面和食譜集的 Java 實作項目更新。
實作模數。
變更 reservoir 的實作：新增含有布林值的 API，以指定選用的排除/填入事件。

線性求解工具

在 Java 和 C# 中公開 InterruptSolve。

CP 求解器

在 C# 中公開 SolutionCollector 董事。

Python

新增對 Python 3.7 的支援。
從來源編譯時：偵測 Python 時，建議優先使用 python3 而非 python2。

.NET

完成 .NET 層重新編寫作業。
提供與執行階段 IDentifier win-x64、linux-x64 和 osx-x64 相容的 Google.OrTools NetStandard 2.0 Nuget 套件。
提供 Google.OrTools.FSharp Nuget 套件。
新增所有 .NET 範例的專案檔案。
將所有 F# 指令碼範例 (.fsx) 更新為一般 F# 專案 (.fs)。
在這裡新增 .NET 套件建構版本的說明文件。

扁平

新增對扁平化集合的支援 (使用 nosets.mzn)。

貢獻

新增對繫結機制的支援。感謝 Kevin Mader。
在 Java 繫結中將 DecisionVisitor 設為 Director 類型。非常感謝 Jeremy Apthorp。

2018 年 7 月

宣布推出 6.8 版

我們已發布 OR-Tools 6.8 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

CP-SAT 解題工具隆重登場

CP-SAT 解題器是限製程式設計的全新解題工具。CP-SAT 解題工具比原始 CP-SAT 解題器更快，因此建議用於 CP 問題。

如需使用 CP-SAT 解題工具的範例，請前往 GitHub 的範例目錄，找出名稱中含有 _sat 的檔案。

原始 CP 解題器將繼續保留一段時間，以支援現有的程式碼，但已淘汰。

CP-SAT 解題工具的新選項

這個版本新增了下列 CP-SAT 解題工具選項：

當地社區搜尋 (LNS)：使用 SatParameters.use_lns 選項啟用 LNS。
平行搜尋：使用 SatParameters.num_search_workers 選項，即可在搜尋時啟用多個執行緒。每個執行緒可包含不同的參數和不同的隨機種子。這個做法會盡量提高多元性，而且至少有一個執行緒找到解決方案的機率。

提升解題工具的效能

我們改善了 CP-SAT 和 Glop 解題工具的效能。

2018 年 3 月

宣布推出 6.7 版

我們已發布 OR-Tools 6.7 版。如要更新版本，請參閱「OR-Tools 安裝」的適當章節。

更新至必要的依附元件

Protobuf 3.5.0 -> 3.5.1。

其他

重構基礎以準備 abseil-cpp 整合。
使用 Travis CI 和 Appveyor 持續整合 (CI) 服務。

SAT

效能提升。
改善 Python API。
新增 C# API (又稱 CpSolver.cs (實驗)。)

玻璃

程式碼重構。
效能提升。

CMake 支援 (實驗功能)

新增 C++ OR-Tools CMake 支援。
可將 OR-Tools 建構為獨立的 CMake 專案。
可將 OR-Tools 整合到現有 CMake 專案中。
新增以 Python OR-Tools 為基礎的 CMake 版本。
使用 CMake 產生 Python 套件 (齒輪)。

貢獻

修正 Windows 的 Winsock2.h 重新定義。非常感謝 Florent Tollin de Rivarol。
新增 F# 支援 (實驗功能)。非常感謝 Matthew Moore。注意：僅適用於 Makefile 建構工具。
新增 .NET Standard 支援 (實驗功能)。非常感謝 Ziad El Malki。注意：僅適用於 Makefile 建構工具。

2017 年 11 月

宣布推出 6.6 版

我們已發布 OR-Tools 6.6 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

必要依附元件更新

Protobuf 至 3.3.0 -> 3.5.0。
將 gflags 設為 2.2.0 -> 2.2.1。
CBC 2.9.8 -> 2.9.9.
新增 Python 模組六 (1.10) 做為 Python 的必要依附元件。

修正錯誤

提取要求 #494 名稱重構。在部分編輯器中為 IntelliSense 新增註解。非常感謝 Matthew Moore。
提取要求 #516 獨立二進位檔的提取要求# 516。非常感謝 Matthew Moore。
提高 Glop 中的精確度。

SAT 解題工具

改善內部 SAT 解題工具、修正各種錯誤。
將 VRP 限制條件新增至 SAT 解題工具，並連結至 LP 解題器。
變更 SAT 解析器中的解決方案觀測器，以便使用 CpSolverResponse 做為參數。
改善 SAT 求解器中的 Glop 用法。
加快 SAT-LP 連線速度。
將 Reservoir 限制新增至 SAT cp_model protobuf 格式。

SAT/Python

Python 中的 SAT API 簡介。
ortools/sat/python/cp_model.py 中的程式碼。
在 examples/python/ 中新增範例：
assignment_sat.py
assignment_with_constraints_sat.py
code_samples_sat.py
cp_is_fun_sat.py
gate_scheduling_sat.py
hidato_sat.py
jobshop_ft06_sat.py
nqueens_sat.py
nurses_sat.py
rcpsp_sat.py
steel_mill_slab_sat.py
worker_schedule_sat.py
新增對 IPython 筆記本的支援。
Python 範例會匯出至筆記本，您可以在 examples/notebook 取得。

示例

重新編寫 rcpsp_parser，以使用 ProtoBuf 格式儲存問題。
改善 RCPSP 剖析器。

2017 年 10 月

宣布推出 6.5 版

我們已推出 OR-Tools 6.5 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

平台變動

pypi 模組 py3-ortools 已合併至 ortools 模組中。目前只有一個模組「ortools」。
這些 Python 模組的主要格式為滾輪檔案。如要從 pypi 安裝 Python 適用的 OR-Tools，只要執行 pip install ortools 即可。您需要安裝最新版本的 pip (>= 9.0.1)。這應會提取最新的版本 (v6.5)。

錯誤已修正

protobuf jar 檔案現在可以使用編譯過的類別正確建構。

新範例

我們已提供更多 F# 範例至範例/fsharp 目錄 (再次感謝 Matthew Moore)。
其中也提供了 Java MIP 範例 (謝謝 Darian)。

2017 年 9 月

宣布推出 6.4 版

我們已發布 OR-Tools 6.4 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

平台變動

Linux 平台上的 Pypi 模組現在會使用 Manylinux1 標記以滾輪檔案的形式提供。感謝 Federico Ficarelli。透過這項變更，我們已回溯追蹤 2017 年 7 月版本引入的每 Linux 模組。

新功能

改善 GLOP 中的縮放方法。
修正 C# 轉送程式庫中的評估器包裝。感謝 DevNamedZed。
改善大型模型扁平化探測器的效能。
預設使用扁平化的 SAT。
改善 Sat 求解器採用 Core 為基礎的方法效能。
修正線性指派演算法中未正確發生錯誤的錯誤。
在 ortools/examples/fsharp 中新增 F# 範例。
移除路由庫中的陽性懲處。

2017 年 8 月

宣布推出 v6.3 版

我們已推出 OR-Tools 6.3 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

新下載檔案

您現在可以在 OR-Tools 版本頁面下載 Linux 適用的 Python 輪轉檔案，以及所有下載的最新版本。

微型解題工具

這個版本包含針對 Minzinc 2017 挑戰提供的最終 Sat 和 Flatzinc 程式碼。

2017 年 7 月

宣布推出 6.2 版

我們已推出 OR-Tools 6.2 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

平台變動

我們現在支援多種 Linux 二進位檔發行版本 (Ubuntu 14.04、16.04、17.04、CentOS 7、Debian 9)。
Linux 平台上的 Pypi 模組現在會包含描述發行內容的標記 (ubuntu-14.04、ubuntu-16.04、ubuntu-17.04、centos-7、debian-9)。

新功能

我們開始支援 Docker 建構 Linux 構件。請前往 or-tools/tools/docker 並查看 Makefile 以查看可能的目標 (make archive、make pypi 和 make pypi3)。

這些指令會建立 export 子目錄，並在其中新增二進位檔構件。

2017 年 6 月

宣布推出 6.1 版

我們已發布 OR-Tools 6.1 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

平台變動

支援 Visual Studio 2017；系統不再支援 Visual Studio 2013。
支援 macOS 10.9 以上版本。

新功能

我們為 CP-SAT 解題工具新增了 protobuf 格式。請參閱 ortools/sat/cp_model.proto 來定義模型，以及參閱 ortools/sat/cp_model_solver.h 來解決問題。

修正錯誤

問題 #420：已修正所有平台上的 Python Pypi 模組上缺少的 __version__ 屬性。

2017 年 5 月

宣布推出 6.0 版

我們已推出 OR-Tools 6.0 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

C++ 中的新目錄結構

我們變更了使用 C++ 時的 OR-Tools 來源/包含結構，目標是提供更完善的 C++ 內含檔案封裝。另一個好處是調整 C++ 和 Python 目錄結構。

src/ 已重新命名為 ortools/。
C++ 檔案中的所有 #include 指令現已新增前置字串 ortools。#include "constraint/constraint_solver.h" 現在是 #include "ortools/constraint/constraint_solver.h"。

新功能

Bazel 支援。您現在可以使用 Google 的建構工具 bazel 建構 OR-工具。可以在 Linux 和 Mac OS X 上執行。下載 Bazel 0.4.5 以上版本之後，請將目錄變更為 ortools，並建構範例：bazel build examples/cpp/...。

路線

我們在路線庫中導入了休息時間 (例如駕駛午餐時車輛停機) 的支援功能。此功能如 cvrptw_with_breaks.cc 範例所示。

SCIP 支援

線性解題工具包裝函式現在支援 SCIP 4.0。您現在需要先建構 SCIP 然後指示或工具將要使用 SCIP。如需操作說明，請參閱這裡。

GLPK 支援

我們也透過 GLPK 改變了建構方式。詳情請參閱這篇文章。

清除

我們已移除 C++ 程式碼集內 hash_map 和 hash_set 的所有使用，因為這些功能已淘汰。它們已由 STL 的 unordered_map 和 unordered_set 取代。
C# makefile，由 Michael Powell 提供。

2017 年 1 月

宣布推出 5.1 版

我們已發布 OR-Tools 5.1 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

新功能

安裝中

針對透過二進位檔發布或從原始碼安裝 OR-工具，提供更簡便的程序。詳情請參閱「從二進位檔安裝 OR-工具」或「從來源安裝 OR-工具」。

路線

執行演算法來計算對稱旅遊業務員問題的 Held-Karp 下限範圍。如此一來，您就能計算出非最佳解決方案的成本與最佳解決方案成本之間的差距。

為車輛路線庫新增方法 RoutingModel::SetBreakIntervalsOfVehicle，可讓您新增「中斷」break間隔，也就是車輛無法執行任何任務 (例如旅行或造訪節點) 的時間範圍。如需使用這個選項的範例，請參閱 cvrptw_with_breaks.cc

排程

開始在專案排程程式庫的剖析器中支援更多資料格式。

週六解題工具

SAT 解題器的累積限制現在接受使用 NewOptionalInterval 方法建立的選用間隔。如需範例，請參閱 https://github.com/google/or-tools/blob/master/examples/cpp/rcpsp_sat.cc。
您現在可以將目標指定為常值加權總和，藉此解決 Max-SAT (最高滿意度_問題)。不再需要建立中繼整數變數。

提升執行效能

SAT 解題工具 - 改善 Sat 解題工具的效能，尤其是累計限制。
Glop 解題工具 - 改善 Glop 解題工具的數字穩定性，現在可更準確地解決硬數問題。
扁平解謎工具
大幅提升 Sat 後端對扁平口譯功能的效能。
簡化 C# Flatzinc 介面。如需新介面的範例，請參閱 https://github.com/google/or-tools/blob/master/examples/csharp/csfz.cs。

修正錯誤

如果在具有單一車輛和側邊限制的路徑模型使用 PathCheapestArc 經驗法則，有時可能會導致解析器長時間執行。只要能妥善考量副限制，即可解決這個問題。
在 Java 中，在解決車輛路線問題時，路由解題工具有時可能會當機。此問題已在最新版本中修正。

2016 年 11 月

宣布推出 5.0 版

已推出 OR-Tools 5.0 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

執行範例

推出適用於特定語言的目標，方便您更輕鬆地編譯及執行程式，以及 OR-Tools 隨附的範例。

六

開始支援限製程式設計。
實作差異、累計、電路和子路限制。
實作超載檢查工具，以找出離散累計限制的最大能源篩選演算法為基礎。
實作所有不同的繫結一致性傳播器，可針對 AllDifferent 限制實作更佳的傳播。

FlatZinc

針對 FlatZinc 問題實作 SAT 解題工具。

限制解題工具

實作了下列限制：
atMost：設定等於指定值的變數計數上限。
MakePathPrecedenceConstraint 和 MakePathTransitPrecedenceConstraint：為一組配對實作優先順序限制。

路線

實作 AddAtSolutionCallback，這是每次搜尋中發現解決方案時呼叫的回呼。
已移除 RoutingModel 無阻斷建構函式。現在，您必須在轉送模型中至少指定一個 Depot。

2016 年 9 月

宣布推出 v4.4 版

已推出 OR-Tools 4.4 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

六

已擴充排程 API 和修改過的範例 (weighted_tardiness_sat 和 jobshop_sat) 使用。

圖表

在 Graph 類別中新增疊代器特徵。

OR-工具發行

系統再次支援 Nuget 套件。

2016 年 8 月

宣布推出 v4.3 版

已推出 OR-Tools 4.3 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

限制解題工具

實作 NotBetween 方法，將變數限制在特定時間間隔之外。

匯款

新增了模型剖析，以便檢查現有的 NotMember 限制條件 (如範例所示)，並用於本機搜尋篩選器。
新增本機搜尋剖析。
修正本機移動。

線性解題工具

已修正 SCIP 狀態回報功能。

六

實作 SolveWithPresolve 方法，簡化 SAT pResolver 的使用。
重新分組於 src/sat/util.h|cc 中的搜尋公用程式。
實作 SMT (Lazy Clause Generation) 排程限制：請參閱 jobshop_sat.cc 和 weighted_tardiness_sat.cc。

玻璃

在更多運算階段中利用稀疏程度，藉此提升效能。

扁平

修正小挑戰發現的錯誤。

Lp_data

繼續簡化疊代器中的範本。

OR-工具發行

C# 組合現在預設具有強式命名。
已升級至 Protobuf3.0.0。
新增 Python 指令碼，用於檢查 OR-Tools 封存依附元件。

2016 年 7 月

宣布推出 v4.2 版

已推出 OR-Tools 4.2 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

限制解題工具 (轉送)

您現在可以使用基數定義取捨，這個基數是這個取捨後可運作的節點數量上限。舉例來說，如果您新增的假定訊息包含 n 個節點且基數為 k，則 n 個節點之間有 k 個節點設為有效。您可以使用新的 AddDisjunction 定義執行這項作業。
開始支援每個節點的多個取捨。舉例來說，您現在可以在許多取景 (D1..Dm) 中新增節點 N1。這麼做有助於提高對這些社群處於活躍狀態的機會。針對捨棄時間範圍相關問題，推出更快速的轉送搜尋演算法。
新增限制解題工具參數，以便將模型參數和 log_search 轉送來轉送搜尋參數。
本地搜尋演算法可加快解決時間範圍以外的問題。詳情請參閱 cvrp_disjoint_tw.cc 範例。

Glop (線性最佳化)

推出更快的 Simplex 演算法。

OR-工具發行

每個平台都有一個封存，而不是每個 C++、Java 和 .Net 的個別封存。Python 封存內容仍由 pypi 代管。
在 pypi 上，我們已改用 Mac OS X 和 Windows 的滾輪 (.whl) 模組。引入 MAJOR.MINOR 編號結構定義。這些編號會使用封存名稱、儲存在 Mac OS X 共用程式庫中的版本、Python 模組和 .NET 組件。我們要發布的第一個版本就是使用這個結構定義的 v4.2。

2016 年 6 月

公告 v2016-06 版本

我們已經推出 OR-Tools v2016-06 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

限制解題工具

已從 CP 程式庫中移除大部分回呼執行個體 (src/base/callback.h)。
新增了 NotMemberCt (變數不能屬於一組間隔)。

轉送程式庫

內部變化：如要在 AddDimensionWithVehicleCapacity 中指定車輛容量，您現在必須傳遞陣列 (C++ 中的向量)，而不是回呼。

國際化

變更稀疏矩陣的內部表示法。
提升效能

圖表

重新編寫 Dijkstra 和 Bellman-Ford 演算法，以 std::function (C++) 取代回呼。
逐一處理弧形和節點時，變更不同圖形實作的 API。

六

移除未使用的核心方法 (解決節點)。
新增拖曳寫入器，以檢查不符性的問題。
新增預先處理器。

咆勃爵士

新增社區。

示例

c++：刪除範例中的 filelineReader。
資料：新增單一機器排程問題。

說明文件

請參閱新的說明文件。

2016 年 4 月

公告 v2016-04 版本

我們已經推出 OR-Tools v2016-04 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

已更新依附元件

使用 protobufs，而非限製程式設計和轉送程式庫中的標記。詳情請參閱 http://or-tools.blogspot.fr/2016/02/heads-up-upcoming-incompatibility-in.html。

2015 年 12 月

宣布推出 v2015-12 版

我們已經推出 OR-Tools v2015-12 版。如要更新版本，請參閱 OR-Tools 安裝的適當部分。

限制解題工具

在 CP 解題工具中對大型社區搜尋的相容性 (如需新 API 的說明，請參閱 examples/cpp/ls_api.cc、examples/python/pyls_api.py、examples/csharp/csls_api.cs 和 examples/com/google/ortools/sample/LsApi.java)。
清除了 Python 包裝。支援 CP 解題工具中的自訂決策 (請參閱 examples/test/test_cp_api.py，瞭解 API 的實際應用情形)。
推出多項改善措施，並修正多個錯誤。