Method: mathopt.solveMathOptModel

入力モデルを解いて結果を一度に返します。コールバックやインクリメンタリティが不要で、解決の進捗状況を追跡する必要がない場合に使用します。

HTTP リクエスト

POST https://optimization.googleapis.com/v1/mathopt:solveMathOptModel

この URL は gRPC Transcoding 構文を使用します。

リクエストの本文

リクエストの本文には、次の構造のデータが含まれます。

JSON 表現 
{
  "solverType": enum (SolverTypeProto),
  "model": {
    object (ModelProto)
  },
  "parameters": {
    object (SolveParametersProto)
  },
  "modelParameters": {
    object (ModelSolveParametersProto)
  }
}
フィールド
solverType

enum (SolverTypeProto)

省略可。問題を数値的に解く解法タイプ。ソルバーがモデルの特定の特徴をサポートしていない場合、最適化手順は成功しないことに注意してください。
model

object (ModelProto)

必須。解く最適化問題の数学的表現。
parameters

object (SolveParametersProto)

省略可。単一のソルバーを制御するパラメータ。enableOutput パラメータは特別に処理されます。メッセージ コールバックをサポートするソルバーの場合、true に設定すると、サーバーはメッセージ コールバックを登録します。結果のメッセージは SolveMathOptModelResponse.messages に返されます。他のソルバーでは、enableOutput を true に設定するとエラーが発生します。
modelParameters

object (ModelSolveParametersProto)

省略可。入力モデルに固有の単一のソルバーを制御するパラメータ（モデル非依存パラメータについては、SolveParametersProto をご覧ください）。

レスポンスの本文

MathOpt での単項遠隔解法のレスポンス。

成功した場合、レスポンスの本文には次の構造のデータが含まれます。

JSON 表現 
{
  "result": {
    object (SolveResultProto)
  },
  "messages": [
    string
  ]
}
フィールド
result

object (SolveResultProto)

リクエスト内のモデルを解く際の出力の説明。
messages[]

string

SolveParametersProto.enable_output が使用されている場合、メッセージ コールバックをサポートするソルバーのログ メッセージが格納されます。

SolverTypeProto

MathOpt でサポートされている解法。

列挙型
SOLVER_TYPE_UNSPECIFIED
SOLVER_TYPE_GSCIP

Solving Constraint Integer Programs（SCIP）ソルバー（サードパーティ）。

LP、MIP、非凸整数の二次問題をサポートします。ただし、LP の二重データは返されません。LP には GLOP を優先する。
SOLVER_TYPE_GUROBI

Gurobi ソルバー（サードパーティ）。

LP、MIP、非凸整数の二次問題をサポートします。通常は最も速いオプションですが、特別なライセンスがあります。
SOLVER_TYPE_GLOP

Google の Glop ソルバーです。

プライマルおよびデュアル シンプレックス方式の LP をサポートします。
SOLVER_TYPE_CP_SAT

Google の CP-SAT ソルバーです。

すべての変数が整数で制限あり（または presolve の後にあると暗示される）である問題をサポートします。連続変数を使用して問題を再スケーリングして離散化するための試験運用版のサポート。
SOLVER_TYPE_PDLP

Google の PDLP ソルバーです。

LP と凸対角の 2 次目標をサポートします。シンプレックスではなく 1 次メソッドを使用します。非常に大きな問題を解決できます。
SOLVER_TYPE_GLPK

GNU Linear Programming Kit（GLPK）（サードパーティ）。

MIP と LP をサポート。

スレッドセーフ: GLPK はメモリ割り当てにスレッド ローカル ストレージを使用します。そのため、Solver インスタンスは、作成時と同じスレッドで破棄する必要があります。そうしないと、GLPK がクラッシュします。Solver::Solve() を、Solver の作成に使用したスレッドとは別のスレッドから呼び出すのは問題ありませんが、GLPK では文書化されていないため、使用を避ける必要があります。

プレゾルバを使用して LP を解くと、最適な解が見つかった場合にのみ解（およびバインドされていない光線）が返されます。それ以外の場合は、何も返されません。詳細は、glpk-5.0.tar.gz から入手できる glpk-5.0/doc/glpk.pdf の #40 ページを参照してください。
SOLVER_TYPE_OSQP

Operator Splitting Quadratic Program（OSQP）ソルバー（サードパーティ）。

線形制約と、線形または凸二次目標を使用した連続問題をサポートします。一次メソッドを使用します。
SOLVER_TYPE_ECOS

組み込み円錐ソルバー（ECOS）（サードパーティ）。

LP と SOCP の問題をサポート。内部ポイント方式（バリア）を使用します。
SOLVER_TYPE_SCS

分割円錐ソルバー（SCS）（サードパーティ）。

LP と SOCP の問題をサポート。一次メソッドを使用します。
SOLVER_TYPE_HIGHS

HiGHS ソルバー（サードパーティ）。

LP と MIP の問題をサポートします（コンベックス QP は実装されていません）。
SOLVER_TYPE_SANTORINI

MIP ソルバーの MathOpt のリファレンス実装。

動作が遅いため、本番環境での使用はおすすめしません。LP ソルバーではない（二重情報は返されない）。

ModelProto

最適化の問題。MathOpt は以下をサポートしています。 - 連続する決定変数と整数の決定変数（オプションで有限境界も指定可能）。- 線形目標と二次目標（単一または複数の目標）。最小化または最大化。- 次のような制約のタイプ: * 線形制約 * 二次制約 * 2 次円錐制約 * 論理制約 >SOS1 および SOS2 制約 >インジケーターの制約

デフォルトでは、制約は「id-to-data」使用できます。ただし、線形制約はより効率的な「配列の構造体」で表現します。使用できます。

JSON 表現 
{
  "name": string,
  "variables": {
    object (VariablesProto)
  },
  "objective": {
    object (ObjectiveProto)
  },
  "auxiliaryObjectives": {
    string: {
      object (ObjectiveProto)
    },
    ...
  },
  "linearConstraints": {
    object (LinearConstraintsProto)
  },
  "linearConstraintMatrix": {
    object (SparseDoubleMatrixProto)
  },
  "quadraticConstraints": {
    string: {
      object (QuadraticConstraintProto)
    },
    ...
  },
  "secondOrderConeConstraints": {
    string: {
      object (SecondOrderConeConstraintProto)
    },
    ...
  },
  "sos1Constraints": {
    string: {
      object (SosConstraintProto)
    },
    ...
  },
  "sos2Constraints": {
    string: {
      object (SosConstraintProto)
    },
    ...
  },
  "indicatorConstraints": {
    string: {
      object (IndicatorConstraintProto)
    },
    ...
  }
}
フィールド
name

string
variables

object (VariablesProto)
objective

object (ObjectiveProto)

モデルの主要な目標。
auxiliaryObjectives

map (key: string (int64 format), value: object (ObjectiveProto))

多目的モデルで使用するための補助目標。

マップキー ID は [0, max(int64)) にする必要があります。それぞれの優先度と空でない名前は一意である必要があり、プライマリ objective と異なる必要があります。

"key": value ペアのリストを含むオブジェクト。例: { "name": "wrench", "mass": "1.3kg", "count": "3" }
linearConstraints

object (LinearConstraintsProto)
linearConstraintMatrix

object (SparseDoubleMatrixProto)

線形制約の可変係数。

この制約に関係する変数が削除された場合、0 に設定されたものとして扱われます。

要件: * linearConstraintMatrix.row_ids は linearConstraints.ids の要素です。* linearConstraintMatrix.column_ids は variables.ids の要素です。* 指定されていない行列エントリはゼロです。* linearConstraintMatrix.values はすべて有限である必要があります。
quadraticConstraints

map (key: string (int64 format), value: object (QuadraticConstraintProto))

モデル内の二次制約。

"key": value ペアのリストを含むオブジェクト。例: { "name": "wrench", "mass": "1.3kg", "count": "3" }
secondOrderConeConstraints

map (key: string (int64 format), value: object (SecondOrderConeConstraintProto))

モデル内の 2 次円錐制約。

"key": value ペアのリストを含むオブジェクト。例: { "name": "wrench", "mass": "1.3kg", "count": "3" }
sos1Constraints

map (key: string (int64 format), value: object (SosConstraintProto))

モデル内の SOS1 制約。ゼロ以外の値にできる expression が最大 1 つに制限されます。オプションの weights エントリは、（うまくいけば）より速く収束するためにソルバーが使用する実装の詳細です。より具体的には、「バランス」を生み出す分岐の決定を選択するために、ソルバーがこれらの重みを使用することも、使用することもできません。子ノードを指定します。

"key": value ペアのリストを含むオブジェクト。例: { "name": "wrench", "mass": "1.3kg", "count": "3" }
sos2Constraints

map (key: string (int64 format), value: object (SosConstraintProto))

モデル内の SOS2 制約。expression にゼロ以外の値を設定できるエントリを 2 つまでに制限し、その順序は隣接する必要があります。weights が指定されていない場合、この順序は expressions リスト内の直線的な順序になります。weights が指定されている場合、これらの値に関して昇順が適用されます。

"key": value ペアのリストを含むオブジェクト。例: { "name": "wrench", "mass": "1.3kg", "count": "3" }
indicatorConstraints

map (key: string (int64 format), value: object (IndicatorConstraintProto))

モデル内のインジケーターの制約。これは、バイナリの「インジケーター変数」が「暗黙の制約」が 1 に設定され、保持する必要があります。

"key": value ペアのリストを含むオブジェクト。例: { "name": "wrench", "mass": "1.3kg", "count": "3" }

VariablesProto

以下で使用する「#variables」は、= size(VariablesProto.ids) です。

JSON 表現 
{
  "ids": [
    string
  ],
  "lowerBounds": [
    number
  ],
  "upperBounds": [
    number
  ],
  "integers": [
    boolean
  ],
  "names": [
    string
  ]
}
フィールド
ids[]

string (int64 format)

負の値でなく、厳密に増加する必要があります。max(int64) 値は使用できません。
lowerBounds[]

number

長さは #variables に等しく、[-inf, inf) の値にする必要があります。
upperBounds[]

number

長さは #variables に等しく、(-inf, inf] の値)
integers[]

boolean

長さは #variables と同じにする必要があります。連続変数の値は false、整数変数の場合は true です。
names[]

string

設定しない場合、すべて空の文字列とみなされます。それ以外の場合は、長さを #variables に等しくする必要があります。

空でない名前はすべて一意である必要があります。

ObjectiveProto

JSON 表現 
{
  "maximize": boolean,
  "offset": number,
  "linearCoefficients": {
    object (SparseDoubleVectorProto)
  },
  "quadraticCoefficients": {
    object (SparseDoubleMatrixProto)
  },
  "name": string,
  "priority": string
}
フィールド
maximize

boolean

false は最小、true は最大
offset

number

有限で、NaN は使用できません。
linearCoefficients

object (SparseDoubleVectorProto)

決定変数内で線形な ObjectiveProto 用語。

要件: * linearCoegresss.ids は VariablesProto.ids の要素です。* 指定されていない VariablesProto はゼロに対応します。* linearCoprocessings.values はすべて有限である必要があります。* linearCoprocessings.values は 0 にすることもできますが、これは単にスペースを浪費するだけです。
quadraticCoefficients

object (SparseDoubleMatrixProto)

決定変数内の二次的である客観的な用語。

SparseDoubleMatrixProto メッセージに関する要件に加えて、次の要件があります。* quadraticCoprocessings.row_ids の各要素と quadraticCoprocessings.column_ids の各要素は、VariablesProto.ids の要素である必要があります。* 行列は上三角形でなければなりません。つまり、各 i について、quadraticCo Types.row_ids[i] <= quadraticCo Types.column_ids[i] を指定します。

注: * 明示的に格納されていない用語は係数が 0 です。* quadraticCoprocessings.co を特定する要素 を 0 にすることもできますが、これは単にスペースを浪費するだけです。
name

string

このフィールドでは、親メッセージの一意性の要件がある場合があります。たとえば、ModelProto.objectives および AuxiliaryObjectivesUpdatesProto.new_objectives をご覧ください。
priority

string (int64 format)

多目的の問題の場合、他の目標に対するその目標の優先度（低いほど重要）。この値は負でない値にしてください。さらに、モデル内の各目標優先度は、解決時に異なる必要があります。この条件は proto レベルで検証されないため、モデルに同じ優先度の目標が一時的に設定されることがあります。

SparseDoubleVectorProto

倍精度ベクトルのスパース表現。

JSON 表現 
{
  "ids": [
    string
  ],
  "values": [
    number
  ]
}
フィールド
ids[]

string (int64 format)

すべての要素を異なるように（昇順に）並べ替える必要があります。
values[]

number

ID と同じ長さにする必要があります。NaN を含めることはできません。

SparseDoubleMatrixProto

倍精度行列のスパース表現。

行列は、行 ID、列 ID、係数のトリプルとして保存されます。これら 3 つのベクトルの長さは同じである必要があります。すべての i で、タプル (rowIds[i], columnIds[i]) は一意である必要があります。エントリは行メジャーの順に並べる必要があります。

JSON 表現 
{
  "rowIds": [
    string
  ],
  "columnIds": [
    string
  ],
  "coefficients": [
    number
  ]
}
フィールド
rowIds[]

string (int64 format)
columnIds[]

string (int64 format)
coefficients[]

number

NaN を含めることはできません。

LinearConstraintsProto

以下で使用するように、「#線形制約」を定義します。= size(LinearConstraintsProto.ids)。

JSON 表現 
{
  "ids": [
    string
  ],
  "lowerBounds": [
    number
  ],
  "upperBounds": [
    number
  ],
  "names": [
    string
  ]
}
フィールド
ids[]

string (int64 format)

負の値でなく、厳密に増加する必要があります。max(int64) 値は使用できません。
lowerBounds[]

number

#linear 制約、[-inf, inf) の値に等しい長さにする必要があります。
upperBounds[]

number

長さは #linear 制約、(-inf, inf] の値に等しい必要があります。
names[]

string

設定しない場合、すべて空の文字列とみなされます。それ以外の場合は、#linear 制約と同じ長さにする必要があります。

空でない名前はすべて一意である必要があります。

QuadraticConstraintProto

次の形式の 1 つの二次制約: lb <= sum{linearTerms} + sum{quadraticTerms} <= ub。

この制約に関係する変数が削除された場合、0 に設定されたものとして扱われます。

JSON 表現 
{
  "linearTerms": {
    object (SparseDoubleVectorProto)
  },
  "quadraticTerms": {
    object (SparseDoubleMatrixProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string
}
フィールド
linearTerms

object (SparseDoubleVectorProto)

決定変数において線形な項。

SparseDoubleVectorProto メッセージの要件に加えて、以下が必要です。* linearTerms.ids は VariablesProto.ids の要素です。* linearTerms.values はすべて有限で、NaN は使用できません。

注: * 省略された変数 ID には対応する係数が 0 になります。* linearTerms.values は 0 にすることもできますが、これは単にスペースを浪費するだけです。
quadraticTerms

object (SparseDoubleMatrixProto)

決定変数における二次方程式。

SparseDoubleMatrixProto メッセージの要件に加えて、以下が求められます。 * quadraticTerms.row_ids の各要素と quadraticTerms.column_ids の各要素は、VariablesProto.ids の要素にする必要があります。* 行列は上三角形でなければなりません。つまり、各 i について、quadraticTerms.row_ids[i] <= quadraticTerms.column_ids[i] です。

注: * 明示的に格納されていない用語は係数が 0 です。* quadraticTerms.co コードの要素数はゼロにできますが、これは単にスペースを浪費するだけです。
lowerBound

number

[-inf, inf] の値を持ち、upperBound 以下の値にする必要があります。
upperBound

number

(-inf, inf] の範囲で、lowerBound 以上の値を指定する必要があります。
name

string

このフィールドでは、親メッセージの一意性の要件がある場合があります。たとえば、ModelProto.quadratic_constraints と QuadraticConstraintUpdatesProto.new_constraints をご覧ください。

SecondOrderConeConstraintProto

次の形式の 1 つの 2 次円錐制約:

||argumentsToNorm||_2 <= upperBound、

ここで、upperBound と argumentsToNorm の各要素は一次式です。

この制約に関係する変数が削除された場合、0 に設定されたものとして扱われます。

JSON 表現 
{
  "upperBound": {
    object (LinearExpressionProto)
  },
  "argumentsToNorm": [
    {
      object (LinearExpressionProto)
    }
  ],
  "name": string
}
フィールド
upperBound

object (LinearExpressionProto)
argumentsToNorm[]

object (LinearExpressionProto)
name

string

このフィールドでは、親メッセージの一意性の要件がある場合があります。たとえば、ModelProto.second_order_cone_constraints と SecondOrderConeConstraintUpdatesProto.new_constraints をご覧ください。

LinearExpressionProto

線形式のスパース表現（変数の加重合計に定数のオフセットを加えたもの）。

JSON 表現 
{
  "ids": [
    string
  ],
  "coefficients": [
    number
  ],
  "offset": number
}
フィールド
ids[]

string (int64 format)

変数の ID。すべての要素を異なるように（昇順に）並べ替える必要があります。
coefficients[]

number

ID と同じ長さにする必要があります。値は有限で、NaN にすることはできません。
offset

number

有限で、NaN にすることはできません。

SosConstraintProto

単一の SOS1 制約または SOS2 制約を表すデータ。

この制約に関係する変数が削除された場合、0 に設定されたものとして扱われます。

JSON 表現 
{
  "expressions": [
    {
      object (LinearExpressionProto)
    }
  ],
  "weights": [
    number
  ],
  "name": string
}
フィールド
expressions[]

object (LinearExpressionProto)

SOS 制約を適用する式： * SOS1: 最大 1 つの要素がゼロ以外の値を取ります。* SOS2：最大 2 つの要素がゼロ以外の値を取り、反復順序付けで隣接している必要があります。
weights[]

number

空、または式と同じ長さ。空の場合、デフォルトの重みは 1、2、... です。存在する場合、エントリは一意である必要があります。
name

string

このフィールドでは、親メッセージの一意性の要件がある場合があります。たとえば、ModelProto.sos1_constraints と SosConstraintUpdatesProto.new_constraints をご覧ください。

IndicatorConstraintProto

次の形式の単一のインジケーター制約を表すデータ： Variable(indicatorId) = (activateOnZero ?0 : 1) ⇒ belowBound <= 式 <= upperBound。

この制約に関係する変数（インジケーターまたは expression に表示される変数）が削除されると、その変数はゼロに設定されたものとして扱われます。特に、インジケーター変数を削除すると、activateOnZero が false の場合はインジケーター制約が空白になり、activateOnZero が true の場合は線形制約と同等になります。

JSON 表現 
{
  "activateOnZero": boolean,
  "expression": {
    object (SparseDoubleVectorProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string,
  "indicatorId": string
}
フィールド
activateOnZero

boolean

true の場合、インジケーター変数が値 0 を取る場合、暗黙の制約は満たされる必要があります。それ以外の場合、インジケーター変数が値 1 を取る場合、暗黙の制約は満たされる必要があります。
expression

object (SparseDoubleVectorProto)

含まれるモデルに関する有効な線形式である必要があります。* SparseDoubleVectorProto のすべての指定条件。* expression.values のすべての要素は有限である必要があります。* expression.ids は VariablesProto.ids のサブセットです。
lowerBound

number

[-inf, inf); の値を持つ必要があります。NaN にすることはできません。
upperBound

number

値は (-inf, inf] の範囲内になければなりません。NaN にはできません。
name

string

このフィールドでは、親メッセージの一意性の要件がある場合があります。たとえば、ModelProto.indicator_constraints と IndicatorConstraintUpdatesProto.new_constraints をご覧ください。
indicatorId

string (int64 format)

バイナリ変数に対応する ID、または未設定。設定しない場合、インジケーターの制約は無視されます。設定する場合は、次の条件を満たす必要があります。* VariablesProto.integers[indicatorId] = true, * VariablesProto.lower_bounds[indicatorId] >= 0, * VariablesProto.upper_bounds[indicatorId] <= 1.これらの条件は MathOpt では検証されませんが、満たされない場合は解法の際にエラーが返されます。

SolveParametersProto

単一のソルバーを制御するパラメータ。

すべてのソルバーに共通する両方のパラメータを含む（例:timeLimit、特定のソルバーのパラメータ（例:gscip。値が共通フィールドとソルバー固有フィールドの両方で設定されている場合は、ソルバー固有の設定が使用されます。

オプションかつ未設定の共通パラメータ、または値が指定されていない列挙型は、ソルバーのデフォルトが使用されていることを示します。

使用されているソルバー以外のソルバーのソルバー固有のパラメータは無視されます。

モデルに依存するパラメータ（変数ごとに分岐優先度が設定されているなど）は ModelSolveParametersProto に渡されます。

JSON 表現 
{
  "timeLimit": string,
  "enableOutput": boolean,
  "lpAlgorithm": enum (LPAlgorithmProto),
  "presolve": enum (EmphasisProto),
  "cuts": enum (EmphasisProto),
  "heuristics": enum (EmphasisProto),
  "scaling": enum (EmphasisProto),
  "iterationLimit": string,
  "nodeLimit": string,
  "cutoffLimit": number,
  "objectiveLimit": number,
  "bestBoundLimit": number,
  "solutionLimit": integer,
  "threads": integer,
  "randomSeed": integer,
  "absoluteGapTolerance": number,
  "relativeGapTolerance": number,
  "solutionPoolSize": integer
}
フィールド
timeLimit

string (Duration format)

解法が問題に費やす最大時間（設定されていない場合は無限）。

この値はハードリミットではなく、解決時間がこの値をわずかに超える場合があります。このパラメータは常に基になるソルバーに渡されます。ソルバーのデフォルトは使用されません。

s で終わる小数 9 桁までの秒単位の期間。例: "3.5s"。
enableOutput

boolean

ソルバー実装トレースを出力できるようにします。これらのトレースの場所は、ソルバーによって異なります。SCIP と Gurobi では、標準出力ストリームになります。Glop と CP-SAT では LOG(INFO) となります。

ソルバーがメッセージ コールバックをサポートしており、ユーザーがそのコールバックを登録した場合、このパラメータ値は無視され、トレースは出力されません。
lpAlgorithm

enum (LPAlgorithmProto)

線形計画を解くアルゴリズム。LP_ALGORITHM_UNSPECIFIED の場合は、ソルバーのデフォルト アルゴリズムを使用します。

線形計画ではないが、線形計画がサブルーチンである問題の場合、ソルバーはこの値を使用できます。例:MIP ソルバーは通常、これをルート LP ソルバーにのみ使用し、それ以外の場合はデュアル シンプレックスを使用します。
presolve

enum (EmphasisProto)

メイン アルゴリズムを開始する前に問題を単純化するための努力、またはソルバーのデフォルトの作業レベル（PC が "UNSPECIFIED" の場合）を単純化する努力。
cuts

enum (EmphasisProto)

より強力な LP 緩和（MIP のみ）、またはソルバーのデフォルトの作業レベル（PC が Chrome で指定されていないものの場合）を取得するための取り組み。

注: カットを無効にすると、コールバックで MIP_NODE でカットを追加できなくなる場合があります。この動作はソルバーによって異なります。
heuristics

enum (EmphasisProto)

完全な検索手順（MIP のみ）、またはソルバーのデフォルトの作業レベル（PC が "UNSPECIFIED" の場合）で見られたもの以外の実行可能な解を求める努力。
scaling

enum (EmphasisProto)

数値の安定性、またはソルバーのデフォルトの作業レベル（PC が "UNSPECIFIED" の場合）を改善するために問題を再スケーリングする努力。
iterationLimit

string (int64 format)

基礎となるアルゴリズムの反復回数の上限（シンプレックス ピボットなど）。具体的な動作は使用するソルバーとアルゴリズムによって異なりますが、多くの場合、決定論的な解決制限になる可能性があります（1 つのスレッドなど、さらなる構成が必要になる場合があります）。

通常、LP、QP、MIP ソルバーでサポートされていますが、MIP ソルバーの場合は nodeLimit も参照してください。
nodeLimit

string (int64 format)

列挙探索で解けるサブ問題の数の制限（分岐や境界など）。多くのソルバーでは、これを使用して計算を確定的に制限できます（1 つのスレッドなど、さらなる構成が必要になる場合があります）。

通常、MIP ソルバーの場合は、iterationLimit もご覧ください。
cutoffLimit

number

少なくともカットオフと同じくらい優れた解がないことが証明できる場合、ソルバーは早期に停止します。

早期停止の場合、ソルバーは終了理由 NO_SOLUTION_FOUND と上限 CUTOFF を返します。したがって、追加の解答情報を提供する必要はありません。早期停止がない場合、戻り値には影響しません。

目的がカットオフと完全に等しいソリューションを返す場合は、許容範囲を使用することをおすすめします。

詳細および BestBoundLimit との比較については、ユーザーガイドをご覧ください。
objectiveLimit

number

ソルバーは、少なくともこれくらい良い解を見つけるとすぐに停止します。終了理由は FEASIBLE で、OBJECTIVE は制限します。
bestBoundLimit

number

解法は、最適な境界が少なくともこれほど良好であることを証明するとすぐに停止します。終了理由は FEASIBLE または NO_SOLUTION_FOUND、制限は OBJECTIVE です。

詳細と、cutoffLimit との比較については、ユーザーガイドをご覧ください。
solutionLimit

integer

これほど多くの実現可能な解が見つかると、ソルバーは早期に停止します。終了理由は「FEASIBLE（実行可能）」で、解決策は限られています。設定する場合は 0 より大きくする必要があります。最初に見つかった実行可能な解でソルバーを停止するときによく使用されます。返される解答の目標値が保証されるわけではありません。

解法は通常、解の制限を超える解を返しませんが、これは MathOpt では適用されません。b/214041169 も参照してください。

現在、Gurobi と SCIP、値が 1 の CP-SAT のみがサポートされています。
threads

integer

設定する場合は 1 以上にする必要があります。
randomSeed

integer

基になるソルバーの擬似乱数ジェネレータのシード。すべてのソルバーは、LP アルゴリズムでの摂動、タイブレイクアップ ルール、ヒューリスティック修正などのために、擬似乱数を使用します。この値を変えると、ソルバーの動作に顕著な影響を与える可能性があります。

すべてのソルバーにはシードの概念がありますが、有効な値は実際のソルバーによって異なります。- Gurobi: [0:GRB_MAXINT]（Gurobi 9.0 では 2x10^9）- GSCIP: [0:2147483647]（MAX_INT、kint32max、または 2^31-1）- GLOP: [0:2147483647]（上記と同じ）すべての場合で、ソルバーは MAX(0, MIN(MAX_VALID_VALUE_FOR_SOLVER, randomSeed)) に等しい値を受け取ります。
absoluteGapTolerance

number

MIP ソルバーの（主に）絶対的最適度の許容度。

絶対ギャップは、次の差の絶対値です。 * 見つかった最も実行可能な解の客観的値、 * 検索によって生成された二重境界。ソルバーは、絶対 GAP が exactGapTolerance 以下（設定されている場合）以下になると停止し、TERMINATION_REASON_OPTIMAL を返します。

設定する場合は 0 以上にする必要があります。

「relativeGapTolerance」もご覧ください。
relativeGapTolerance

number

MIP ソルバーの（主に）相対的な最適度の許容度。

相対 GAP は絶対 GAP を正規化したバージョン（この値は absorlers で定義）、正規化はソルバーに依存します（例:GAP の絶対値を、見つかった最適解の客観的値で割った値。

相対 GAP が相対 GapTolerance（設定されている場合）以下になると、ソルバーを停止して、TERMINATION_REASON_OPTIMAL を返すことができます。

設定する場合は 0 以上にする必要があります。

「completeGapTolerance」もご覧ください。
solutionPoolSize

integer

検索中に最大 solutionPoolSize 個のソリューションを維持できます。解答プールには通常、次の 2 つの関数があります。（1）複数の解答を返すことができる解法の場合、返される解の数には制限があります。（2）一部のソルバーでは、解答プールの解を使用してヒューリスティックを実行する場合があるため、この値を変更すると、アルゴリズムのパスに影響する場合があります。ソルバーを強制的にソリューション プールいっぱいにするには（例:追加のソルバー固有の構成が必要です。

LPAlgorithmProto

線形計画を解くアルゴリズムを選択します。

列挙型
LP_ALGORITHM_UNSPECIFIED
LP_ALGORITHM_PRIMAL_SIMPLEX （基本的な）シンプレックス メソッド。通常、原理と二重の解、原理/デュアルの無限の問題に対する原理/デュアル光線、および基盤を提供できます。
LP_ALGORITHM_DUAL_SIMPLEX デュアル シンプレックス方式。通常、原理と二重の解、原理/デュアルの無限の問題に対する原理/デュアル光線、および基盤を提供できます。
LP_ALGORITHM_BARRIER バリア方式は、一般に内部ポイント方式（IPM）とも呼ばれます。通常は、基本的なソリューションとデュアル ソリューションの両方を提供できます。一部の実装では、制限なし/実行不可能な問題でも光線が発生します。基になる解法が「クロスオーバー」しない限り、根拠は示されないで終わります。
LP_ALGORITHM_FIRST_ORDER 1 次の方法に基づくアルゴリズム。これらは通常、一次的な解決策と二重の解決策の両方を生成し、潜在的には一次的および/または二重実現可能性の証明書も生成します。一次的な方法は通常、精度の低い解を提供するため、ユーザーは注意して解の品質パラメータ（公差など）を設定し、解を検証するように注意する必要があります。

EmphasisProto

解決中にオプションのタスクに適用される労力レベル（使用方法については SolveParametersProto をご覧ください）。

強調は、ソルバー機能を次のように構成する際に使用します。* ソルバーがこの機能をサポートしていない場合、常に UNSPECIFIED のみが有効になり、その他の設定は通常、無効な引数エラーになります（一部のソルバーは OFF を受け入れる場合もあります）。* ソルバーがこの機能をサポートしている場合: - UNSPECIFIED に設定すると、基になるデフォルトが使用されます。- この機能をオフにできない場合、OFF にするとエラーが返されます。- この機能がデフォルトで有効になっている場合、通常、ソルバーのデフォルトは「中」にマッピングされます。- この機能がサポートされている場合、LOW、MEDIUM、HIGH、VERY HIGH はエラーとならず、最も一致する組み合わせにマッピングされます。

列挙型
EMPHASIS_UNSPECIFIED
EMPHASIS_OFF
EMPHASIS_LOW
EMPHASIS_MEDIUM
EMPHASIS_HIGH
EMPHASIS_VERY_HIGH

ModelSolveParametersProto

JSON 表現 
{
  "variableValuesFilter": {
    object (SparseVectorFilterProto)
  },
  "dualValuesFilter": {
    object (SparseVectorFilterProto)
  },
  "reducedCostsFilter": {
    object (SparseVectorFilterProto)
  },
  "initialBasis": {
    object (BasisProto)
  },
  "solutionHints": [
    {
      object (SolutionHintProto)
    }
  ],
  "branchingPriorities": {
    object (SparseInt32VectorProto)
  }
}
フィールド
variableValuesFilter

object (SparseVectorFilterProto)

PrimalSolutionProto.variable_values, PrimalRayProto.variable_values の変数がキーとして設定されている、返されるすべてのスパース コンテナに適用されるフィルタ。

要件: * filterIds は VariablesProto.ids の要素です。
dualValuesFilter

object (SparseVectorFilterProto)

DualSolutionProto と DualRay の線形制約をキーとする、返されたすべてのスパース コンテナに適用されるフィルタ（DualSolutionProto.dual_values、DualRay.dual_values）。

要件: * filterIds は LinearConstraints.ids の要素であること。
reducedCostsFilter

object (SparseVectorFilterProto)

DualSolutionProto と DualRay の変数をキーとする、返されたすべてのスパース コンテナに適用されるフィルタ（DualSolutionProto.reduced_costs、DualRay.reduced_costs）。

要件: * filterIds は VariablesProto.ids の要素です。
initialBasis

object (BasisProto)

シンプレックス LP ソルバーのウォーム スタート時に使用する初期ベース（省略可）。設定すると、現在の ModelSummary について validators/solution_validator.h の ValidateBasis に従って有効であると期待されます。
solutionHints[]

object (SolutionHintProto)

解答のヒント（省略可）。基になるソルバーが 1 つのヒントしか受け入れない場合は、最初のヒントが使用されます。
branchingPriorities

object (SparseInt32VectorProto)

オプションの分岐優先度。値が大きい変数から先に分岐されます。優先度が設定されていない変数には、ソルバーのデフォルトの優先度（通常は 0）が適用されます。

要件: * branchingPriorities.values は有限である必要があります。* branchingPriorities.ids は VariablesProto.ids の要素にする必要があります。

SparseVectorFilterProto

このメッセージにより、SparseXxxxVector の特定の部分のクエリ/設定が可能になります。デフォルトの動作では、何も除外されません。一般的な使い方は、解の一部（ゼロ以外の値、または手動で選択した変数値のセットのみ）のみをクエリすることです。

JSON 表現 
{
  "skipZeroValues": boolean,
  "filterByIds": boolean,
  "filteredIds": [
    string
  ]
}
フィールド
skipZeroValues

boolean

SparseBoolVectorProto "zero" の場合false です。
filterByIds

boolean

true の場合、filteredIds にリストされている ID に対応する値のみを返します。
filteredIds[]

string (int64 format)

filterByIds が true の場合に使用する ID のリスト。filterByIds が false の場合は空にする必要があります。注: このフィールドが空で、filterByIds が true の場合、結果に情報が含まれないことになります。

BasisProto

線形プログラムの解の組み合わせ的特徴付け。

線形計画を解くシンプレックス法は常に「基本的な実行可能解」を返す組み合わせて説明できます。ベースは、すべての変数と線形制約に BasisStatusProto を割り当てます。

例:「min c * x s.t.」という標準的な形式の LP を考えてみましょう。A * x = b x >= 0 で、制約よりも変数が多く、行ランク A です。

n を変数の数、m を線形制約の数とします。この問題の有効な基礎は次のように構築できます。* すべての制約の基本ステータスは「FIXED」です。* A の列が線形独立するように m 個の変数を選び、ステータス BASIC を割り当てる。* 残りの n ～ m 個の変数にステータス AT_LOWER を割り当てます。

この根拠の基本的な解は、ステータス AT_LOWER のすべての変数を下限（すべてゼロ）に固定した、A * x = b という独自の解です。結果として得られる解は、x >= 0 も満たせば、基本実現可能解と呼ばれます。

JSON 表現 
{
  "constraintStatus": {
    object (SparseBasisStatusVector)
  },
  "variableStatus": {
    object (SparseBasisStatusVector)
  },
  "basicDualFeasibility": enum (SolutionStatusProto)
}
フィールド
constraintStatus

object (SparseBasisStatusVector)

制約ベースのステータス。

要件: * constraintStatus.ids が LinearConstraints.ids と等しい。
variableStatus

object (SparseBasisStatusVector)

変数ベースのステータス。

要件: * constraintStatus.ids が VariablesProto.ids と等しい。
basicDualFeasibility

enum (SolutionStatusProto)

これは、次善の LP ソリューションの実現可能性を評価するために MathOpt が使用する高度な機能です（最適なソリューションは常に SOLUTION_STATUS_FEASIBLE ステータスになります）。

一方の LP の場合は、関連付けられた二重のソリューションの実現可能性ステータスと同じにする。両面 LP では、一部のエッジケース（例: 単元素法による不完全な解決）で異なる場合があります。

ModelSolveParametersProto.initial_basis で開始条件を指定する場合、この値は無視されます。SolutionProto.basis によって返されるベースにのみ関係します。

SparseBasisStatusVector

基本ステータスのベクトルのスパース表現。

JSON 表現 
{
  "ids": [
    string
  ],
  "values": [
    enum (BasisStatusProto)
  ]
}
フィールド
ids[]

string (int64 format)

すべての要素を異なるように（昇順に）並べ替える必要があります。
values[]

enum (BasisStatusProto)

ID と同じ長さにする必要があります。

BasisStatusProto

LP ベースでの変数/制約のステータス。

列挙型
BASIS_STATUS_UNSPECIFIED ステータスなしを表すガード値。
BASIS_STATUS_FREE 変数/制約は自由である（有限の境界はない）。
BASIS_STATUS_AT_LOWER_BOUND 変数/制約が下限にある（有限である必要があります）。
BASIS_STATUS_AT_UPPER_BOUND 変数/制約が上限にある（有限である必要がある）。
BASIS_STATUS_FIXED_VALUE 変数/制約に同一の有限の下限と上限があります。
BASIS_STATUS_BASIC 変数/制約は基本的なものです。

SolutionStatusProto

解法が主張する一次解または二次解の実現可能性。

列挙型
SOLUTION_STATUS_UNSPECIFIED ステータスなしを表すガード値。
SOLUTION_STATUS_UNDETERMINED ソルバーが実現可能性のステータスを主張していない。
SOLUTION_STATUS_FEASIBLE 解法は、その解は実現可能であると主張する。
SOLUTION_STATUS_INFEASIBLE ソルバーは、その解は実現不可能であると主張する。

SolutionHintProto

ソルバーの推奨開始ソリューション。

MIP ソルバーは通常、素情報（variableValues）のみを必要とし、LP ソルバは素情報および二重情報（dualValues）の両方を必要とします。

多くの MIP ソルバーは、（1）すべての変数を指定しない部分的な解、または（2）実行不可能な解を扱うことができます。このような場合、ソルバーは通常、サブ MIP を解決してヒントを完成させます。

ヒントがソルバーで使用される方法は、解法、問題のタイプ、使用するアルゴリズムに大きく依存します。ヒントの効果を確認する最も確実な方法は、ヒントがある場合とない場合で、基になるソルバーのログを読み取ることです。

シンプレックス ベースの LP ソルバーでは、通常、解のヒントよりも初期の基礎が好まれます（ヒントを実用可能な基本的な解に変換するためにクロスオーバーする必要があります）。

JSON 表現 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "dualValues": {
    object (SparseDoubleVectorProto)
  }
}
フィールド
variableValues

object (SparseDoubleVectorProto)

問題の主変数に値を部分的に代入している可能性がある。このサブメッセージのソルバーに依存しない要件は次のとおりです。* variableValues.ids は VariablesProto.ids の要素です。* variableValues.values はすべて有限である必要があります。
dualValues

object (SparseDoubleVectorProto)

問題の線形制約に対する値の割り当て（部分的である場合もあります）。

要件: * doubleValues.ids は LinearConstraintsProto.ids の要素です。* doubleValues.values はすべて有限である必要があります。

SparseInt32VectorProto

整数のベクトルのスパース表現。

JSON 表現 
{
  "ids": [
    string
  ],
  "values": [
    integer
  ]
}
フィールド
ids[]

string (int64 format)

すべての要素を異なるように（昇順に）並べ替える必要があります。
values[]

integer

ID と同じ長さにする必要があります。

SolveResultProto

プライマル/デュアル ソリューション/レイが複雑な場合のコントラクトは、詳しい説明については termination_reasons.md をご覧ください。

正確な契約が最終決定されるまでは、解除理由に頼るのではなく、解決策/Ray が存在するかどうかを単純に確認するのが最も安全です。

JSON 表現 
{
  "termination": {
    object (TerminationProto)
  },
  "solutions": [
    {
      object (SolutionProto)
    }
  ],
  "primalRays": [
    {
      object (PrimalRayProto)
    }
  ],
  "dualRays": [
    {
      object (DualRayProto)
    }
  ],
  "solveStats": {
    object (SolveStatsProto)
  }
}
フィールド
termination

object (TerminationProto)

ソルバーが停止した理由。
solutions[]

object (SolutionProto)

将来のソルバーが実装するソリューションの順序についての一般的な契約では、次の順序で順序付けします。1.主要な実現可能な解を含む解を、最適な主要な目的から順に並べます。2. 実行可能な二重の解答がある解答。最適な二重の目的（不明な二重の目標は最悪）の順に並べます。3.残りの解答はすべて、任意の順序で返すことができます。
primalRays[]

object (PrimalRayProto)

無限の主要な改善の方向性、または同等の二重の実現可能性証明書。通常は、TerminationReasonProtos UNBOUNDED と DUAL_INFEASIBLE に提供されます
dualRays[]

object (DualRayProto)

制限のない二重改善の指示、または同等の主要な実現可能性証明書。通常、TerminationReasonProto INFEASIBLE に対して提供されます。
solveStats

object (SolveStatsProto)

解決プロセスに関する統計情報。例:実行時間、反復処理です

TerminationProto

Solve() の呼び出しが終了した理由に関するすべての情報。

JSON 表現 
{
  "reason": enum (TerminationReasonProto),
  "limit": enum (LimitProto),
  "detail": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "objectiveBounds": {
    object (ObjectiveBoundsProto)
  }
}
フィールド
reason

enum (TerminationReasonProto)

値が TERMINATION_REASON_FEASIBLE または TERMINATION_REASON_NO_SOLUTION_FOUND の場合の limit の追加情報。詳しくは、limit をご覧ください。
limit

enum (LimitProto)

理由が TERMINATION_REASON_FEASIBLE または TERMINATION_REASON_NO_SOLUTION_FOUND である場合を除き、LIMIT_UNSPECIFIED になります。すべてのソルバーが、終了の原因となった制限を常に特定できるわけではありません。原因を特定できない場合、LIMIT_UNDETERMINED が使用されます。
detail

string

終了に関する、通常ソルバー固有の追加情報。
problemStatus

object (ProblemStatusProto)

主要な問題と二重の問題の実現可能性ステータス。2023 年 7 月 18 日時点では、このメッセージが表示されない可能性があります。欠落している場合、problemStatus は SolveResultProto.solve_stats にあります。
objectiveBounds

object (ObjectiveBoundsProto)

最適な目標値の境界。2023 年 7 月 18 日時点では、このメッセージが表示されない可能性があります。見当たらない場合、Objective-Bounds.primal_bound は SolveResultProto.solve.stats.best_primal_bound にあります。Objective-Bounds.dual_bound は SolveResultProto.solve.stats.best_dual_bound にあります

TerminationReasonProto

Solve() の呼び出しが終了した理由。

列挙型
TERMINATION_REASON_UNSPECIFIED
TERMINATION_REASON_OPTIMAL （数値の許容範囲内で）証明可能な最適な解が見つかりました。
TERMINATION_REASON_INFEASIBLE この主な問題には、実行可能な解決策がありません。
TERMINATION_REASON_UNBOUNDED 主な問題は実現可能であり、原始光線に沿って任意に適切な解決策を見つけることができます。
TERMINATION_REASON_INFEASIBLE_OR_UNBOUNDED 主な問題は、実現不可能か無限かのどちらかです。問題のステータスの詳細については、resolveStats.problem_status で確認できます。Gurobi の制限なしステータスがここにマッピングされる場合があるので注意してください。
TERMINATION_REASON_IMPRECISE

問題は上記の基準（Optimal、Infeasible、Unbounded、InfeasibleOrUnbounded）のいずれかで解決されましたが、1 つ以上の許容範囲が満たされていませんでした。原始解/二次解が存在しますが、それらはわずかに実現不可能であるか、（問題が最適に近い場合）最適解の目標と目標の最適解との間のギャップである可能性があります。

ユーザーは引き続き一次解/二次解/解および解統計をクエリできますが、数値の不精度に対処する責任はユーザーにあります。
TERMINATION_REASON_FEASIBLE オプティマイザーがなんらかの制限に達したため、実現可能な基本的な解決策が返されます。到達した制限の種類の詳細については、SolveResultProto.limit_detail をご覧ください。
TERMINATION_REASON_NO_SOLUTION_FOUND オプティマイザーがなんらかの制限に達したが、実現可能な基本的な解決策を見つけることができませんでした。到達した制限の種類の詳細については、SolveResultProto.limit_detail をご覧ください。
TERMINATION_REASON_NUMERICAL_ERROR 回復不能な数値エラーが発生したため、アルゴリズムが停止しました。ソリューション情報はありません。
TERMINATION_REASON_OTHER_ERROR 上記で定義されたステータスのいずれにも該当しないエラーのため、アルゴリズムが停止しました。ソリューション情報はありません。

LimitProto

Solve() が TerminationReasonProto FEASIBLE または NO_SOLUTION_FOUND で早期に停止すると、ヒットした特定の制限になります。

列挙型
LIMIT_UNSPECIFIED 制限以外で終了した場合に null 値として使用されます（TERMINATION_REASON_OPTIMAL など）。
LIMIT_UNDETERMINED 基になるソルバーでは、どの制限に達したかは明らかになりません。
LIMIT_ITERATION 反復処理が最大回数に達した後に、反復アルゴリズムが停止した（例: シンプレックスまたはバリアの反復）。
LIMIT_TIME ユーザーが指定した計算時間の経過後にアルゴリズムが停止した。
LIMIT_NODE 分岐バインドのツリーで最大数のノードが探索されたため、分岐バインドのアルゴリズムが停止しました。
LIMIT_SOLUTION 必要な数の解が見つかったため、アルゴリズムが停止しました。MIP では、最初に実現可能な解を解法で返すために、MIP でよく使用されます。
LIMIT_MEMORY メモリ不足のため、アルゴリズムが停止しました。
LIMIT_CUTOFF ソルバーは、目標にカットオフを設定して実行しました（例: SolveParameters.cutoff_limit を設定した）。つまり、ユーザーはカットオフより悪い解は望まないことを示し、ソルバーは少なくともカットオフと同じくらい良い解はないと結論付けました。通常、追加の解決策情報は提供されません。
LIMIT_OBJECTIVE ユーザーが設定した制限よりも優れた解または境界を見つけたため、アルゴリズムが停止しました（SolveParameters.objective_limit と SolveParameters.best_bound_limit をご覧ください）。
LIMIT_NORM 反復処理のノルムが大きすぎるため、アルゴリズムが停止しました。
LIMIT_INTERRUPTED 割り込み信号またはユーザー割り込み要求により、アルゴリズムが停止しました。
LIMIT_SLOW_PROGRESS 解決策に向けて進歩し続けることができなかったため、アルゴリズムが停止しました。
LIMIT_OTHER

上記のいずれにも含まれない制限により、アルゴリズムが停止しました。LIMIT_UNDETERMINED は理由がわからない場合に使用します。LIMIT_OTHER は理由がわかっているものの上記のいずれの方法にも当てはまらない場合に使用します。

TerminationProto.detail には、制限に関する追加情報が含まれている場合があります。

ProblemStatusProto

解法が主張する主問題とその二重（または連続緩和の二重）の実現可能性。解法は、主張について証明書を返す必要はありません（例: 解法は、原理の実行可能な解を返さずに原理の実現可能性を主張する場合がある）。この組み合わせのステータスは、解決された問題の実現可能性と制限なしに関する解法の主張を包括的に説明するものです。次に例を示します。

  • 原理と二重の問題が実現可能なステータスは、原点が実現可能で制限があり、最適な解がある可能性が高いことを示します（非線形な制約のない問題に対して保証されます）。
  • 「まずは実現可能」と「実行不可能」が 2 つある状態は、その主な問題が無限の領域（すなわち、任意に適切な解決策がある）であることを示します。

二重の実行不可能なステータス自体（つまり、不確定なプライマル ステータスを伴う）は、両方の問題が実現不可能な可能性があるため、主な問題が無限であることを意味するわけではありません。また、原理と 2 つの実行可能という状況は、最適解が存在することを示唆する場合がありますが、解法が実際にそのような最適解を実際に見つけたことを保証するものではありません。

JSON 表現 
{
  "primalStatus": enum (FeasibilityStatusProto),
  "dualStatus": enum (FeasibilityStatusProto),
  "primalOrDualInfeasible": boolean
}
フィールド
primalStatus

enum (FeasibilityStatusProto)

主要な問題のステータス。
dualStatus

enum (FeasibilityStatusProto)

二重問題（または連続緩和の二重の問題）のステータス。
primalOrDualInfeasible

boolean

true の場合、解法は主問題または二重問題は実現不可能であると主張しますが、どちらが実現可能かはわかりません（または両方が実現可能かどうか）。primal_problem_status = dual_problem_status = kUndefined の場合にのみ true になります。この追加情報は、問題に対する最適な解決策がないことが前処理によって判断された場合（ただし、それが実現不可能か、制限なし、またはその両方によるものか）を判断できない場合によく必要になります。

FeasibilityStatusProto

ソルバーが主張している問題の実現可能性ステータス（ソルバーは主張に対して証明書を返す必要はありません）。

列挙型
FEASIBILITY_STATUS_UNSPECIFIED ステータスなしを表すガード値。
FEASIBILITY_STATUS_UNDETERMINED ソルバーはステータスを主張しません。
FEASIBILITY_STATUS_FEASIBLE 解法は、問題が実現可能であると主張する。
FEASIBILITY_STATUS_INFEASIBLE ソルバーは、この問題は実現不可能であると主張する。

ObjectiveBoundsProto

最適な目標値の境界。

JSON 表現 
{
  "primalBound": number,
  "dualBound": number
}
フィールド
primalBound

number

ソルバーは、ソルバーの primal 実現可能性許容度まで primalBound と同等かそれ以上（最小化では小さく、最大化では大きい）であると主張します（以下の警告を参照）。* primalBound は自明（最小化では +inf、最大化では -inf 最大化）は、ソルバーがそのような境界を持たないと主張している場合。* primalBound は、実現可能な最良の初期解の目標よりも最適値により近くなる場合があります。特に、primalBound は、主要な実現可能な解が返されない場合でも重要である可能性があります。警告: 厳密に言えば、* は数値的に実現可能（つまり、解法の許容範囲まで可能）であり、* は客観的値 primalBound を持つという原始解が存在するということです。この数値的に実現可能な解は、やや実現不可能なこともあります。その場合は、primalBound が最適値よりも厳密に優れている可能性があります。主要な実現可能性の許容範囲を primalBound の許容範囲に変換することは容易ではありません。特に、実現可能性の許容範囲が比較的大きい場合（PDLP を使用して解決する場合など）は容易ではありません。
dualBound

number

ソルバーは、ソルバーの二重実現可能性許容度（dualBound up）よりも最適値が同等か（最小化の場合は大きく、最大化の場合は小さい）と主張します（以下の警告を参照）。* doubleBound は自明（最小化の場合は -inf、最大化の場合は +inf 最大化）であり、ソルバーがそのような境界を持たないと主張している場合、primalBound と同様に、これは一部のソルバーでは、最適な値を返した場合でも発生することがあります。MIP ソルバーは通常、精度が低い場合でも境界を報告します。* 連続問題の場合、dualBound は、実現可能な最良のデュアル ソリューションの目標よりも最適な値に近くなる可能性があります。MIP の場合、dualBound の最初の重要な値の 1 つは、多くの場合、MIP の LP 緩和の最適な値です。* doubleBound は、ソルバーの許容範囲（下記の警告を参照）まで primalBound よりも優れている必要があります（最小化では小さく、最大化では大きく）。警告: * 連続問題の場合、正確に言えば、* は数値的に実現可能（つまり、解法の許容範囲まで可能）であり、* は目的値 doubleBound とする、2 つの解が存在するということです。この数値的に実現可能な解はわずかに実行不可能な可能性があります。その場合、dualBound は最適値と primalBound よりも厳密に劣る場合があります。基本のケースと同様に、2 つの実現可能性の許容範囲を doubleBound の許容範囲に変換することは容易ではありません。特に、実現可能性の許容範囲が比較的大きい場合は困難です。ただし、一部のソルバーでは、数値的により安全な修正版 doubleBound が用意されています。この修正済みバージョンは、ソルバー固有の出力（PDLP の場合は pdlp_output.convergence_information.Corrected_dual_objective など）からアクセスできます。* MIP ソルバーの場合、dualBound は、連続する緩和（LP 緩和など）のために 2 つの解に関連付けられることがありますが、多くの場合、ソルバー実行の複雑な結果であり、通常は LP ソルバーによって報告される境界よりも不正確です。

SolutionProto

ソリューションに何が含まれるかは、問題の種類と解法によって異なります。現在の一般的なパターンは 1 です。MIP ソルバーは基本的な解のみを返します。2. シンプレックスの LP ソルバーは、多くの場合、基礎と、その基礎に関連する主力と二つの解を返します。3. 他の連続解法は、多くの場合、解法に依存する形式で接続された原理と二つの解を返します。

要件: * 少なくとも 1 つのフィールドを設定する必要があります。ソリューションを入力してください。

JSON 表現 
{
  "primalSolution": {
    object (PrimalSolutionProto)
  },
  "dualSolution": {
    object (DualSolutionProto)
  },
  "basis": {
    object (BasisProto)
  }
}
フィールド
primalSolution

object (PrimalSolutionProto)
dualSolution

object (DualSolutionProto)
basis

object (BasisProto)

PrimalSolutionProto

最適化の問題の解決策。

例:たとえば、min c * x s.t という簡単な線形プログラムを考えてみましょう。A * x >= b x >= 0。主な解決策は、x に値を代入することです。上から、A * x >= b、x >= 0 を満たせば実現できます。以下のメッセージ PrimalSolutionProto では、variableValues は x、目的値は c * x です。

JSON 表現 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "objectiveValue": number,
  "auxiliaryObjectiveValues": {
    string: number,
    ...
  },
  "feasibilityStatus": enum (SolutionStatusProto)
}
フィールド
variableValues

object (SparseDoubleVectorProto)

要件: * variableValues.ids は VariablesProto.ids の要素です。* variableValues.values はすべて有限である必要があります。
objectiveValue

number

基になるソルバーによって計算された目標値。無限大または NaN にはできません。
auxiliaryObjectiveValues

map (key: string (int64 format), value: number)

基になるソルバーによって計算される補助的な目的値。キーは有効な補助目標 ID である必要があります。値を無限大または NaN にすることはできません。

"key": value ペアのリストを含むオブジェクト。例: { "name": "wrench", "mass": "1.3kg", "count": "3" }
feasibilityStatus

enum (SolutionStatusProto)

基礎となるソルバーに基づくソリューションの実現可能性ステータス。

DualSolutionProto

最適化の問題の二重の解決策。

例:次の一対の一対の線形プログラム対を考えてみます。A * x >= b s.t.y * A + r = c x >= 0 y、r >= 0 です。二重解は (y, r) のペアです。上記の（Dual）の制約を満たしていれば問題ありません。

以下のメッセージでは、y は doubleValues、r は reduceCosts、b * y は客観的値です。

JSON 表現 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  },
  "feasibilityStatus": enum (SolutionStatusProto),
  "objectiveValue": number
}
フィールド
dualValues

object (SparseDoubleVectorProto)

要件: * doubleValues.ids は LinearConstraints.ids の要素です。* doubleValues.values はすべて有限である必要があります。
reducedCosts

object (SparseDoubleVectorProto)

要件: * reduceCosts.ids は VariablesProto.ids の要素です* lowCosts.values はすべて有限である必要があります。
feasibilityStatus

enum (SolutionStatusProto)

基礎となるソルバーに基づくソリューションの実現可能性ステータス。
objectiveValue

number

PrimalRayProto

最適化の問題を無限に改善する方向性2 つの最適化問題の実現可能性の証明と同等です。

例:たとえば、min c * x s.t という簡単な線形プログラムを考えてみましょう。A * x >= b x >= 0 である原始光線とは、c * x < を満たす x のことです。0 A * x >= 0 x >= 0 実行可能な解が与えられた場合、原点光線の正の倍数とその解の正の倍数は依然として実行可能であり、より優れた客観的値が得られることを確認します。primal ray は、二重最適化の問題が実現不可能であることを証明します。

以下のメッセージ PrimalRay では、variableValues は x です。

JSON 表現 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  }
}
フィールド
variableValues

object (SparseDoubleVectorProto)

要件: * variableValues.ids は VariablesProto.ids の要素です。* variableValues.values はすべて有限である必要があります。

DualRayProto

最適化である問題に対する無限の改善の方向性これと同等のものになります

例:次の一対の一対の線形プログラム対を考えてみます。A * x >= b s.t.y * A + r = c x >= 0 y、r >= 0 です。二重光線は (y, r) のペアで、 b * y > を満たす0 y * A + r = 0 y, r >= 0 2 重の実行可能解に (y, r) の正の倍数を加えると、二重の実現可能性が維持され、目的が改善されることがわかります（二重が無限であることを証明する）。このデュアルレイは、この根本的な問題が実現不可能であることを証明します。

以下の DualRay メッセージでは、y は doubleValues、r は reduceCosts です。

JSON 表現 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  }
}
フィールド
dualValues

object (SparseDoubleVectorProto)

要件: * doubleValues.ids は LinearConstraints.ids の要素です。* doubleValues.values はすべて有限である必要があります。
reducedCosts

object (SparseDoubleVectorProto)

要件: * reduceCosts.ids は VariablesProto.ids の要素です* lowCosts.values はすべて有限である必要があります。

SolveStatsProto

JSON 表現 
{
  "solveTime": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "simplexIterations": string,
  "barrierIterations": string,
  "firstOrderIterations": string,
  "nodeCount": string
}
フィールド
solveTime

string (Duration format)

math_opt で測定される経過時間の実経過時間。おおむね Solver::Solve() 内の時間と同じです。注: モデルの構築が完了した作業は含まれません。

s で終わる小数 9 桁までの秒単位の期間。例: "3.5s"。
problemStatus

object (ProblemStatusProto)

主要な問題と二重の問題の実現可能性ステータス。
simplexIterations

string (int64 format)
barrierIterations

string (int64 format)
firstOrderIterations

string (int64 format)
nodeCount

string (int64 format)