입력 모델을 풀고 결과를 한 번에 반환합니다. 콜백, 성과 증분이 필요하지 않고 해결 진행 상황을 추적할 필요가 없는 경우에 사용합니다.
HTTP 요청
POST https://optimization.googleapis.com/v1/mathopt:solveMathOptModel
URL은 gRPC 트랜스코딩 구문을 사용합니다.
요청 본문
요청 본문에는 다음과 같은 구조의 데이터가 포함됩니다.
JSON 표현 |
---|
{ "solverType": enum ( |
필드 | |
---|---|
solverType |
선택사항입니다. Solver 유형으로 문제를 숫자로 푸세요. 솔버가 모델의 특정 특성을 지원하지 않으면 최적화 절차를 완료할 수 없습니다. |
model |
필수 항목입니다. 해결해야 할 최적화 문제의 수학적 표현입니다. |
parameters |
선택사항입니다. 단일 솔브를 제어하는 매개변수입니다. enableOutput 매개변수는 구체적으로 처리됩니다. 메시지 콜백을 지원하는 솔버의 경우 이를 true로 설정하면 서버에서 메시지 콜백을 등록합니다. 결과 메시지는 SolveMathOptModelResponse.messages에 반환됩니다. 다른 솔버의 경우 enableOutput을 true로 설정하면 오류가 발생합니다. |
modelParameters |
선택사항입니다. 입력 모델에 특정한 단일 솔트를 제어하기 위한 매개변수입니다 (모델 독립 매개변수는 SolveParametersProto 참고). |
응답 본문
MathOpt의 단항 원격 해결에 대한 응답입니다.
성공할 경우 응답 본문에 다음 구조의 데이터가 포함됩니다.
JSON 표현 |
---|
{
"result": {
object ( |
필드 | |
---|---|
result |
요청의 모델 풀 출력에 대한 설명입니다. |
messages[] |
SolveParametersProto.enable_output이 사용된 경우 메시지 콜백을 지원하는 솔버의 로그 메시지가 포함됩니다. |
SolverTypeProto
MathOpt에서 지원하는 문제 해결사입니다.
열거형 | |
---|---|
SOLVER_TYPE_UNSPECIFIED |
|
SOLVER_TYPE_GSCIP |
제약 조건 정수 프로그램 해결 (SCIP) 솔버 (서드 파티) LP, MIP, 비볼록 정수 2차 문제를 지원합니다. 하지만 LP의 이중 데이터는 반환되지 않습니다. LP는 GLOP를 선호합니다. |
SOLVER_TYPE_GUROBI |
Gurobi 솔버 (서드 파티) LP, MIP, 비볼록 정수 2차 문제를 지원합니다. 일반적으로 가장 빠른 옵션이지만 특별한 라이선스가 있습니다. |
SOLVER_TYPE_GLOP |
바로 Google의 Glop 솔버입니다. 기본 및 이중 심플렉스 메서드로 LP를 지원합니다. |
SOLVER_TYPE_CP_SAT |
Google의 CP-SAT 솔버 모든 변수가 정수이고 제한된 (또는 미리 결정된 후에 암시적으로 나타남) 문제를 지원합니다. 연속 변수로 문제를 재조정하고 분리하기 위한 실험용 지원 |
SOLVER_TYPE_PDLP |
Google의 PDLP 솔버로 사용됩니다. LP 및 볼록 대각선 2차 목표를 지원합니다. 심플렉스 대신 1차 메서드를 사용합니다. 매우 큰 문제를 해결할 수 있습니다. |
SOLVER_TYPE_GLPK |
GNU 선형 프로그래밍 키트 (GLPK) (서드 파티). MIP 및 LP 지원 스레드 안전: GLPK는 메모리 할당에 스레드 로컬 저장소를 사용합니다. 결과적으로 Solver 인스턴스는 생성된 것과 동일한 스레드에서 제거되어야 합니다. 그렇지 않으면 GLPK가 다운됩니다. Solver를 만드는 데 사용된 스레드가 아닌 다른 스레드에서 Solver::Solve()를 호출해도 괜찮아 보이지만 GLPK에 문서화되지 않으므로 피해야 합니다. presolver로 LP를 해결할 때, 해결책 (및 결합되지 않은 광선)은 최적의 해답을 찾은 경우에만 반환됩니다. 그렇지 않으면 아무것도 반환되지 않습니다. 자세한 내용은 glpk-5.0.tar.gz에서 제공되는 glpk-5.0/doc/glpk.pdf 40페이지 페이지를 참조하세요. |
SOLVER_TYPE_OSQP |
OSQP (Operator Splitting Quadratic Program) 솔버 (서드 파티)입니다. 선형 제약 조건 및 선형 또는 볼록 이차법칙이 있는 연속 문제를 지원합니다. 1차 방법을 사용합니다. |
SOLVER_TYPE_ECOS |
Embedded Conic Solver (ECOS) (서드 파티). LP 및 SOCP 문제를 지원합니다. 내부 점 메서드 (배리어)를 사용합니다. |
SOLVER_TYPE_SCS |
분할 원뿔 솔버 (SCS) (서드 파티) LP 및 SOCP 문제를 지원합니다. 1차 방법을 사용합니다. |
SOLVER_TYPE_HIGHS |
HiGHS Solver (서드 파티) LP 및 MIP 문제를 지원합니다 (볼록 QP는 구현되지 않음). |
SOLVER_TYPE_SANTORINI |
MIP 솔버의 MathOpt 참조 구현입니다. 속도가 느리거나 프로덕션에 권장되지 않습니다. LP 문제 해결사가 아닙니다 (이중 정보가 반환되지 않음). |
ModelProto
최적화 문제입니다. MathOpt 지원: - 선택적인 유한 경계가 있는 연속 및 정수 결정 변수 - 선형 및 이차 목표 (단일 또는 다중 목표)는 최소화되거나 최대화됩니다. - 다음을 비롯한 다양한 제약 조건 유형: * 선형 제약 조건 * 이차 제약 조건 * 2차 원뿔 제약 조건 * 논리 제약 조건 > SOS1 및 SOS2 제약 > 표시기 제약조건
기본적으로 제약 조건은 'id-to-data'로 표시됩니다. 있습니다. 그러나 보다 효율적인 '배열 구조'에서는 선형 제약 조건을 표현합니다. 형식으로 입력합니다.
JSON 표현 |
---|
{ "name": string, "variables": { object ( |
필드 | |
---|---|
name |
|
variables |
|
objective |
모델의 기본 목표입니다. |
auxiliaryObjectives |
다중 목표 모델에서 사용할 보조 목표입니다. 맵 키 ID는 [0, max(int64))에 있어야 합니다. 각 우선순위와 비어 있지 않은 각 이름은 고유해야 하며 기본
|
linearConstraints |
|
linearConstraintMatrix |
선형 제약 조건의 변수 계수입니다. 이 제약조건과 관련된 변수가 삭제되면 0으로 설정된 것처럼 처리됩니다. 요구사항: * linearConstraintMatrix.row_ids는 linearConstraints.ids의 요소입니다. * linearConstraintMatrix.column_ids는 variables.id의 요소입니다. * 지정되지 않은 행렬 항목은 0입니다. * linearConstraintMatrix.values는 모두 유한해야 합니다. |
quadraticConstraints |
모델의 이차 제약 조건입니다.
|
secondOrderConeConstraints |
모델의 2차 원뿔 제약 조건입니다.
|
sos1Constraints |
모델의 SOS1 제약 조건으로, 최대 1개의
|
sos2Constraints |
모델의 SOS2 제약 조건으로, 최대 2개의
|
indicatorConstraints |
모델의 표시기 제약 조건은 바이너리 '표시자 변수'가 를 1로 설정하면 '암시적 제약 조건'이 유지되어야 합니다.
|
VariablesProto
아래와 같이 '#variables'를 정의합니다. = size(VariablesProto.ids).
JSON 표현 |
---|
{ "ids": [ string ], "lowerBounds": [ number ], "upperBounds": [ number ], "integers": [ boolean ], "names": [ string ] } |
필드 | |
---|---|
ids[] |
음수가 아니고 엄격하게 증가해야 합니다. max(int64) 값을 사용할 수 없습니다. |
lowerBounds[] |
길이는 #variables, [-inf, inf) 값과 같아야 합니다. |
upperBounds[] |
길이는 #variables, (-inf, inf]) 값과 같아야 합니다. |
integers[] |
길이는 #variables와 같아야 합니다. 연속 변수의 값은 false이고 정수 변수의 경우 true입니다. |
names[] |
설정하지 않으면 모두 빈 문자열로 간주됩니다. 그렇지 않은 경우 길이가 #variables와 같아야 합니다. 비어 있지 않은 모든 이름은 고유해야 합니다. |
ObjectiveProto
JSON 표현 |
---|
{ "maximize": boolean, "offset": number, "linearCoefficients": { object ( |
필드 | |
---|---|
maximize |
false는 최소화, true는 최대화 |
offset |
유한해야 하며 NaN이 아니어야 합니다. |
linearCoefficients |
결정 변수에서 선형인 ObjectiveProto 용어입니다. 요구사항: * linearCoefficiencys.ids는 VariablesProto.ids의 요소입니다. * 지정되지 않은 VariablesProto는 0에 해당합니다. * linearCoefficiencys.values는 모두 유한해야 합니다. * linearCoefficiencys.values는 0일 수 있지만 공간만 낭비됩니다. |
quadraticCoefficients |
결정 변수에서 이차성인 객관적 항입니다. SparseDoubleMatrixProto 메시지에 대한 요구사항 외 요구사항: * 이차 quadraticCoefficiencys.row_ids의 각 요소 및 quadraticCoefficiencys.column_ids의 각 요소는 VariablesProto.ids의 요소여야 합니다. * 행렬은 위쪽 삼각형이어야 합니다. 즉, 각 i에 대해 quadraticCoefficiencys.row_ids[i] <= quadraticCoefficiencys.column_ids[i]를 사용합니다. 참고: * 명시적으로 저장되지 않은 용어는 계수가 0입니다. * 이차코데오스.코데오의 요소는 0일 수 있지만 이는 공간을 낭비하게 됩니다. |
name |
상위 메시지에는 이 필드에 대한 고유성 요구사항이 있을 수 있습니다. 예를 들어 ModelProto.objectives 및 AuxiliaryObjectivesUpdatesProto.new_objectives를 참조하세요. |
priority |
다중 목표 문제에서는 다른 목표 대비 이 목표의 우선순위가 낮습니다 (낮을수록 중요함). 이 값은 음수가 아니어야 합니다. 또한 모델의 각 목표 우선순위는 해결 시점에 고유해야 합니다. 이 조건은 proto 수준에서 검증되지 않으므로, 모델에 일시적으로 우선순위가 같은 목표가 있을 수 있습니다. |
SparseDoubleVectorProto
double의 벡터의 희소 표현입니다.
JSON 표현 |
---|
{ "ids": [ string ], "values": [ number ] } |
필드 | |
---|---|
ids[] |
모든 요소를 구별하여 오름차순으로 정렬해야 합니다. |
values[] |
ID와 길이가 같아야 합니다. NaN은 포함하지 않을 수 있습니다. |
SparseDoubleMatrixProto
실수 행렬의 희소 표현입니다.
행렬은 행 ID, 열 ID, 계수의 3배로 저장됩니다. 이 세 벡터는 길이가 같아야 합니다. 모든 i에서 튜플 (rowIds[i], columnIds[i])은 고유해야 합니다. 항목은 행의 주요 순서대로 입력해야 합니다.
JSON 표현 |
---|
{ "rowIds": [ string ], "columnIds": [ string ], "coefficients": [ number ] } |
필드 | |
---|---|
rowIds[] |
|
columnIds[] |
|
coefficients[] |
NaN은 포함하지 않을 수 있습니다. |
LinearConstraintsProto
아래에 사용된 대로 '#linear constraints' = size(LinearConstraintsProto.ids).
JSON 표현 |
---|
{ "ids": [ string ], "lowerBounds": [ number ], "upperBounds": [ number ], "names": [ string ] } |
필드 | |
---|---|
ids[] |
음수가 아니고 엄격하게 증가해야 합니다. max(int64) 값을 사용할 수 없습니다. |
lowerBounds[] |
길이는 #linear 제약 조건과 같아야 하며 값은 [-inf, inf)여야 합니다. |
upperBounds[] |
길이는 #linear 제약 조건과 같아야 하며 값은 (-inf, inf]여야 합니다. |
names[] |
설정하지 않으면 모두 빈 문자열로 간주됩니다. 그렇지 않으면 길이가 #linear 제약 조건과 같아야 합니다. 비어 있지 않은 모든 이름은 고유해야 합니다. |
QuadraticConstraintProto
형식의 단일 이차 제약 조건: lb <= sum{linearTerms} + sum{quadraticTerms} <= ub.
이 제약조건과 관련된 변수가 삭제되면 0으로 설정된 것처럼 처리됩니다.
JSON 표현 |
---|
{ "linearTerms": { object ( |
필드 | |
---|---|
linearTerms |
결정 변수에서 선형인 항입니다. SparseDoubleVectorProto 메시지에 관한 요구사항 외에도 다음 요구사항을 충족해야 합니다. * linearTerms.ids는 VariablesProto.ids의 요소입니다. * linearTerms.values는 모두 유한해야 하며 NaN이 아니어야 합니다. 참고: * 생략된 변수 ID의 해당 계수는 0입니다. * linearTerms.values는 0일 수 있지만 공간을 낭비합니다. |
quadraticTerms |
결정 변수에서 이차 항입니다. SparseDoubleMatrixProto 메시지의 요구사항 외에도 다음 사항이 필요합니다. * quadraticTerms.row_ids의 각 요소와 quadraticTerms.column_ids의 각 요소는 VariablesProto.ids의 요소여야 합니다. * 행렬은 위쪽 삼각형이어야 합니다.각 i에 대해 quadraticTerms.row_ids[i] <= quadraticTerms.column_ids[i] 참고: * 명시적으로 저장되지 않은 용어는 계수가 0입니다. * quadraticTerms.coefficiencys의 요소는 0일 수 있지만 이 경우 공간을 낭비하게 됩니다. |
lowerBound |
[-inf, inf) 값이 있어야 하며 |
upperBound |
(-inf, inf]) 값이 |
name |
상위 메시지에는 이 필드에 대한 고유성 요구사항이 있을 수 있습니다. 예를 들어 ModelProto.quadratic_constraints 및 QuadraticConstraintUpdatesProto.new_constraints를 참고하세요. |
SecondOrderConeConstraintProto
형식의 단일 2차 원뿔 제약 조건은 다음과 같습니다.
||argumentsToNorm
||_2 <= upperBound
,
여기서 upperBound
과 argumentsToNorm
의 각 요소는 선형 표현식입니다.
이 제약조건과 관련된 변수가 삭제되면 0으로 설정된 것처럼 처리됩니다.
JSON 표현 |
---|
{ "upperBound": { object ( |
필드 | |
---|---|
upperBound |
|
argumentsToNorm[] |
|
name |
상위 메시지에는 이 필드에 대한 고유성 요구사항이 있을 수 있습니다. 예를 들어 |
LinearExpressionProto
선형 표현식의 희소 표현 (변수의 가중 합계와 상수 오프셋)
JSON 표현 |
---|
{ "ids": [ string ], "coefficients": [ number ], "offset": number } |
필드 | |
---|---|
ids[] |
변수의 ID입니다. 모든 요소를 구별하여 오름차순으로 정렬해야 합니다. |
coefficients[] |
ID와 길이가 같아야 합니다. 값은 유한해야 하며 NaN이 될 수 없습니다. |
offset |
유한해야 하며 NaN이 아니어야 합니다. |
SosConstraintProto
단일 SOS1 또는 SOS2 제약 조건을 나타내는 데이터입니다.
이 제약조건과 관련된 변수가 삭제되면 0으로 설정된 것처럼 처리됩니다.
JSON 표현 |
---|
{
"expressions": [
{
object ( |
필드 | |
---|---|
expressions[] |
SOS 제약 조건을 적용할 표현식: * SOS1: 최대 한 개의 요소는 0이 아닌 값을 사용합니다. * SOS2: 최대 2개의 요소가 0이 아닌 값을 가지며 반복되는 순서에서 인접해야 합니다. |
weights[] |
비어 있거나 표현식과 길이가 같습니다. 비어 있으면 기본 가중치는 1, 2, ... 이 값이 있는 경우 고유한 입력값이어야 합니다. |
name |
상위 메시지에는 이 필드에 대한 고유성 요구사항이 있을 수 있습니다. 예를 들어 ModelProto.sos1_constraints 및 SosConstraintUpdatesProto.new_constraints를 참조하세요. |
IndicatorConstraintProto
형식의 단일 지표 제약조건을 나타내는 데이터: Variable(indicatorId) = (activateOnZero ? 0 : 1) 큰 바운드 <= 표현식 <= 상한선.
이 제약조건 (표시자 또는 expression
에 표시되는 변수)과 관련된 변수가 삭제되면 0으로 설정된 것처럼 처리됩니다. 특히 표시기 변수를 삭제하면 activateOnZero
가 false인 경우 표시기 제약조건이 비어 있고 activateOnZero
가 true인 경우 선형 제약조건과 동일합니다.
JSON 표현 |
---|
{
"activateOnZero": boolean,
"expression": {
object ( |
필드 | |
---|---|
activateOnZero |
true인 경우 표시기 변수의 값이 0이면 암시적 제약 조건이 충족되어야 합니다. 그렇지 않고 표시기 변수가 값 1을 취하는 경우 암시적 제약 조건이 충족되어야 합니다. |
expression |
포함하는 모델과 관련하여 유효한 선형 표현식이어야 합니다. * |
lowerBound |
[-inf, inf);에 값이 있어야 합니다. NaN일 수 없습니다. |
upperBound |
(-inf, inf] 형식의 값이 있어야 하며 NaN이 될 수 없음) |
name |
상위 메시지에는 이 필드에 대한 고유성 요구사항이 있을 수 있습니다. 예를 들어 |
indicatorId |
바이너리 변수에 해당하거나 설정되지 않은 ID입니다. 설정하지 않으면 표시기 제약 조건이 무시됩니다. 설정하는 경우 다음 요구사항을 충족해야 합니다. * VariablesProto.integers[indicatorId] = true, * VariablesProto.lower_bounds[indicatorId] >= 0, * VariablesProto.upper_bounds[indicatorId] <= 1. 이 조건은 MathOpt에 의해 확인되지 않지만, 충족되지 않으면 해결 시 문제 해결사가 오류를 반환합니다. |
SolveParametersProto
단일 솔브를 제어하는 매개변수입니다.
모든 문제 해결사에 공통된 두 매개변수가 모두 포함됩니다. 예를 들면 timeLimit 및 특정 문제 해결사의 매개변수(예: gscip을 연결합니다. 일반 필드와 문제 해결사 전용 필드 모두에 값이 설정된 경우 문제 해결사별 설정이 사용됩니다.
선택사항이고 설정되지 않은 공통 매개변수 또는 값이 지정되지 않은 enum은 솔버 기본값이 사용된다는 것을 나타냅니다.
사용 중인 이외의 솔버에 대한 솔버 관련 매개변수는 무시됩니다.
모델에 종속되는 매개변수 (예: 각 변수에 분기 우선순위가 설정됨)는 ModelSolveParametersProto에 전달됩니다.
JSON 표현 |
---|
{ "timeLimit": string, "enableOutput": boolean, "lpAlgorithm": enum ( |
필드 | |
---|---|
timeLimit |
문제 해결사가 문제에 소비해야 하는 최대 시간입니다 (설정되지 않은 경우 무한함). 이 값은 엄격한 한도가 아니며 해결 시간이 이 값을 약간 초과할 수 있습니다. 이 매개변수는 항상 기본 솔버에 전달되며 솔버 기본값이 사용되지 않습니다. 소수점 아래가 최대 9자리까지이고 ' |
enableOutput |
솔버 구현 트레이스를 출력할 수 있습니다. 이러한 트레이스의 위치는 솔버에 따라 다릅니다. SCIP 및 Gurobi의 경우 표준 출력 스트림이 됩니다. Glop 및 CP-SAT의 경우 LOG(INFO)가 표시됩니다. 솔버가 메시지 콜백을 지원하고 사용자가 메시지 콜백을 등록하면 이 매개변수 값은 무시되고 트레이스가 출력되지 않습니다. |
lpAlgorithm |
선형 프로그램을 풀기 위한 알고리즘입니다. LP_ALGORITHM_UNSPECIFIED인 경우 솔버 기본 알고리즘을 사용합니다. 선형 프로그램은 아니지만 선형 프로그래밍이 하위 루틴인 문제의 경우 솔버가 이 값을 사용할 수 있습니다. 예: MIP 솔버는 일반적으로 루트 LP 솔트에만 이 값을 사용합니다 (그렇지 않으면 이중 심플렉스를 사용). |
presolve |
기본 알고리즘을 시작하기 전에 문제를 단순화하기 위해 노력합니다. 또는 해결사의 기본 난이도(EMPHASIS_UNSPECIFIED인 경우)를 시도합니다. |
cuts |
더 강한 LP 완화를 위해 노력(MIP만 해당) 또는 해결사의 기본 노력 수준(EMPHASIS_UNSPECIFIED인 경우)을 얻기 위한 노력. 참고: 잘라내기를 사용 중지하면 콜백이 MIP_NODE에 컷을 추가하지 못할 수 있습니다. 이 동작은 솔버에 따라 다릅니다. |
heuristics |
전체 검색 절차(MIP만 해당) 또는 해결사 기본 작업 수준(EMPHASIS_UNSPECIFIED인 경우)에서 경험한 것 이상의 실행 가능한 솔루션을 찾기 위해 노력합니다. |
scaling |
수치 안정성을 개선하기 위해 문제를 재조정하기 위한 노력 또는 EMPHASIS_UNSPECIFIED인 경우 문제 해결사의 기본 노력 수준입니다. |
iterationLimit |
기본 알고리즘의 반복을 제한합니다 (예: 단방향 피벗). 구체적인 동작은 사용된 솔버와 알고리즘에 따라 다르지만, 종종 확정적인 Solve 제한을 제공할 수 있습니다(추가 구성이 필요할 수 있음(예: 스레드 1개)). 일반적으로 LP, QP, MIP 솔버에서 지원되지만 MIP 솔버의 경우 nodeLimit도 참조하세요. |
nodeLimit |
열거 검색 (예: 브랜치 및 바운드)에서 해결된 하위 문제의 수를 제한합니다. 많은 솔버의 경우 계산을 결정론적으로 제한하는 데 사용할 수 있습니다 (하나의 스레드와 같은 추가 구성이 필요할 수 있음). 일반적으로 MIP 솔버의 경우 iterationLimit도 참고하세요. |
cutoffLimit |
솔버는 적어도 컷오프만큼 좋은 원시 해가 없음을 증명할 수 있는 경우 조기에 중지됩니다. 조기 중단 시 솔버는 종료 이유 NO_SOLUTION_FOUND를 반환하고 한도 CUTOFF를 반환하며 추가 솔루션 정보를 제공할 필요가 없습니다. 조기 중단이 없으면 반환 값에 영향을 미치지 않습니다. 목표가 컷오프와 정확히 동일한 솔루션이 반환되도록 하려면 허용 오차를 사용하는 것이 좋습니다. 자세한 내용 및 bestBoundLimit와의 비교는 사용자 가이드를 참조하세요. |
objectiveLimit |
솔버는 최소한 이 정도 이상의 해답을 찾는 즉시 중지되며, 종료 이유는 'FEASIBLE'이고 'OBJECTIVE'는 제한됩니다. |
bestBoundLimit |
솔버는 최적 범위가 최소 이 이상이라는 것이 증명되는 즉시 조기에 중지됩니다. 종료 이유는 FEASIBLE 또는 NO_SOLUTION_FOUND이고 OBJECTIVE를 제한합니다. 자세한 내용 및 cutoffLimit와의 비교는 사용자 가이드를 참조하세요. |
solutionLimit |
솔버는 이처럼 여러 가능한 솔루션을 찾은 후 조기에 중단되며, 종료 이유는 FEASIBLE(가능하고 SOLUTION)로 제한됩니다. 설정된 경우 0보다 커야 합니다. 발견된 첫 번째 가능한 솔루션에서 솔버를 가져오려고 할 때 종종 사용됩니다. 반환되는 솔루션에 대한 목표 값은 보장되지 않습니다. 일반적으로 솔루션 한도보다 많은 솔루션을 반환하지 않는 솔루션이지만, 이는 MathOpt에 의해 적용되지 않습니다. 또한 b/214041169를 참조하세요. 현재 Gurobi와 SCIP, 그리고 값이 1인 CP-SAT에만 지원됩니다. |
threads |
설정하는 경우 1 이상이어야 합니다. |
randomSeed |
기본 솔버의 의사 랜덤 숫자 생성기에 관한 시드입니다. 모든 솔버는 의사 난수를 사용하여 LP 알고리즘의 교란, 타이브레이크 규칙, 휴리스틱 고정 등을 선택합니다. 이를 변경하면 솔버 동작에 현저한 영향을 미칠 수 있습니다. 모든 솔버에는 시드라는 개념이 있지만 유효한 값은 실제 솔버에 따라 다릅니다. - Gurobi: [0:GRB_MAXINT] (Grobi 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 |
주로 MIP 솔버를 위한 절대 최적 허용치입니다. 절대적 GAP는 * 찾은 가장 실현 가능한 해법의 객관적 값과 검색을 통해 도출된 이중 경계 사이의 차이의 절대값입니다. 솔버는 절대 GAP가 절대적 GapTolerance (설정된 경우)가 되면 중지하고 TERMINATION_REASON_OPTIMAL을 반환할 수 있습니다. 설정할 경우 0 이상이어야 합니다. relativeGapTolerance도 참고하세요. |
relativeGapTolerance |
주로 MIP 솔버의 상대적 최적 허용치입니다. 상대 GAP는 절대GapTolerance에 정의된 절대 GAP의 정규화된 버전으로서, 정규화는 문제 해결사에 따라 다릅니다 (예: 절대적 GAP를 발견된 최선의 해결책의 객관값으로 나눈 값입니다. 솔버는 상대 GAP가 최대relativeGapTolerance (설정된 경우)가 되면 중지하고 TERMINATION_REASON_OPTIMAL을 반환할 수 있습니다. 설정할 경우 0 이상이어야 합니다. AbsoluteGapTolerance도 참조하세요. |
solutionPoolSize |
검색 중에 솔루션을 최대 |
LPAlgorithmProto
선형 프로그램을 풀기 위한 알고리즘을 선택합니다.
열거형 | |
---|---|
LP_ALGORITHM_UNSPECIFIED |
|
LP_ALGORITHM_PRIMAL_SIMPLEX |
(기본) 심플렉스 메서드 일반적으로 원시 및 이중 해법, 원시/이중 무한 문제에 대한 기본/이중 광선을 기초로 제공할 수 있습니다. |
LP_ALGORITHM_DUAL_SIMPLEX |
이중 심플렉스 메서드 일반적으로 원시 및 이중 해법, 원시/이중 무한 문제에 대한 기본/이중 광선을 기초로 제공할 수 있습니다. |
LP_ALGORITHM_BARRIER |
배리어 방법으로 일반적으로 내부 포인트 방법 (IPM)이라고도 합니다. 일반적으로 기본 용액과 이중 용액을 모두 제공할 수 있습니다. 또한 일부 구현은 무한하거나 실행 불가능한 문제에 대한 광선을 생성할 수도 있습니다. 기본 솔버가 '크로스오버'를 실행하지 않으면 기준이 제공되지 않습니다. 심플렉스로 끝납니다. |
LP_ALGORITHM_FIRST_ORDER |
1차 방식에 기반한 알고리즘입니다. 이러한 솔루션은 일반적으로 기본 솔루션과 이중 솔루션, 그리고 잠재적으로 원시 및/또는 이중 실행 불가 인증서를 생성합니다. 1차 방법은 일반적으로 정확도가 낮은 솔루션을 제공하므로 사용자는 솔루션 품질 매개변수 (예: 공차)를 설정하고 솔루션을 검증하는 데 주의를 기울여야 합니다. |
EmphasisProto
해결하는 동안 선택적 작업에 적용되는 노력 수준입니다 (사용 방법은 SolveParametersProto 참고).
강조는 다음과 같이 솔버 기능을 구성하는 데 사용됩니다. * 솔버가 이 기능을 지원하지 않으면 'UNSPECIFIED'만 항상 유효하며, 다른 설정에서는 일반적으로 잘못된 인수 오류가 발생합니다 (일부 솔버도 OFF를 허용할 수 있음). * 문제 해결사가 기능을 지원하는 경우: - UNSPECIFIED로 설정하면 기본 기본값이 사용됩니다. - 기능을 해제할 수 없는 경우 OFF는 오류를 반환합니다. - 이 기능이 기본적으로 사용 설정된 경우 솔버 기본값은 일반적으로 MEDIUM에 매핑됩니다. - 기능이 지원되는 경우 LOW, MEDIUM, HIGH, VERY HIGH로 인해 오류가 발생하지 않으며 가장 일치하는 값으로 매핑됩니다.
열거형 | |
---|---|
EMPHASIS_UNSPECIFIED |
|
EMPHASIS_OFF |
|
EMPHASIS_LOW |
|
EMPHASIS_MEDIUM |
|
EMPHASIS_HIGH |
|
EMPHASIS_VERY_HIGH |
ModelSolveParametersProto
JSON 표현 |
---|
{ "variableValuesFilter": { object ( |
필드 | |
---|---|
variableValuesFilter |
PrimalSolutionProto 및 PrimalRayProto의 변수로 키가 지정된 모든 반환된 희소 컨테이너에 적용되는 필터 (PrimalSolutionProto.variable_values, PrimalRayProto.variable_values). 요구사항: * filterIds는 VariablesProto.ids의 요소입니다. |
dualValuesFilter |
DualSolutionProto 및 DualRay에서 선형 제약 조건으로 키가 지정된 모든 반환된 희소 컨테이너에 적용되는 필터 (DualSolutionProto.dual_values, DualRay.dual_values). 요구사항: * filterIds는 LinearConstraints.ids의 요소입니다. |
reducedCostsFilter |
DualSolutionProto 및 DualRay의 변수로 키가 지정된 모든 반환된 희소 컨테이너에 적용되는 필터 (DualSolutionProto.reduced_costs, DualRay.reduced_costs). 요구사항: * filterIds는 VariablesProto.ids의 요소입니다. |
initialBasis |
웜 스타트 심플렉스 LP 솔버를 위한 초기 기준(선택사항) 설정된 경우 현재 |
solutionHints[] |
선택적 솔루션 힌트입니다. 기본 솔버가 단일 힌트만 허용하는 경우 첫 번째 힌트가 사용됩니다. |
branchingPriorities |
선택적 브랜치 우선순위입니다. 값이 더 높은 변수가 먼저 분기됩니다. 우선순위가 설정되지 않은 변수는 문제 해결사의 기본 우선순위를 얻습니다 (일반적으로 0). 요구사항: * branchingPriorities.values는 유한해야 합니다. * branchingPriorities.ids는 VariablesProto.ids의 요소여야 합니다. |
SparseVectorFilterProto
이 메시지를 사용하면 SparseXxxxVector의 특정 부분을 쿼리/설정할 수 있습니다. 기본적으로 아무것도 필터링하지 않습니다. 일반적인 용도는 해의 일부만 쿼리하는 것입니다 (0이 아닌 값 또는 직접 선택한 변수 값 집합만).
JSON 표현 |
---|
{ "skipZeroValues": boolean, "filterByIds": boolean, "filteredIds": [ string ] } |
필드 | |
---|---|
skipZeroValues |
SparseBoolVectorProto: 'zero' |
filterByIds |
true인 경우 filterIds에 나열된 ID에 해당하는 값만 반환합니다. |
filteredIds[] |
filterByIds가 true일 때 사용할 ID 목록입니다. filterByIds가 false인 경우 비어 있어야 합니다. 참고: 비어 있고 filterByIds가 true이면 결과에 어떠한 정보도 원하지 않음을 의미합니다. |
BasisProto
선형 프로그램에 대한 해답의 조합적 특성입니다.
선형 프로그램을 푸는 심플렉스 메서드는 항상 '기본 실현 가능한 해법'을 반환합니다. 이는 기준으로 조합적으로 설명할 수 있습니다. 기본은 모든 변수 및 선형 제약조건에 BasisStatusProto를 할당합니다.
예: 표준 형식 LP를 고려하십시오. 최소 c * x s.t. A * x = b x >= 0은 제약조건보다 변수가 많고 전체 행 순위 A를 갖습니다.
n을 변수의 수로, m을 선형 제약 조건의 수로 합니다. 이 문제의 유효한 근거는 다음과 같이 구성할 수 있습니다. * 모든 제약 조건은 기본 상태가 FIXED(수정됨)입니다. * A열이 선형적으로 독립되어 m개의 변수를 선택하고 BASIC 상태를 할당합니다. * 나머지 n - m개의 변수에 상태 AT_LOWER를 할당합니다.
이 기초에 대한 기본 솔루션은 상태 AT_LOWER가 모든 변수를 하한 (모두 0)에 고정한 A * x = b의 고유한 해법입니다. 이 해답이 x >= 0을 만족하는 경우 실현 가능한 기본 해법이라고 합니다.
JSON 표현 |
---|
{ "constraintStatus": { object ( |
필드 | |
---|---|
constraintStatus |
제약조건 기준 상태입니다. 요구사항: * constraintsStatus.ids는 LinearConstraints.ids와 같습니다. |
variableStatus |
변수 기반 상태입니다. 요구사항: * constraintsStatus.ids는 VariablesProto.ids와 동일합니다. |
basicDualFeasibility |
이는 MathOpt가 최적화되지 않은 LP 솔루션의 실행 가능성을 규정하기 위해 사용하는 고급 기능입니다 (최적의 솔루션은 항상 SOLUTION_STATUS_FEASIBLE 상태). 일방 LP의 경우 관련된 이중 솔루션의 실행 가능성 상태와 동일해야 합니다. 양측 LP의 경우 일부 예외적인 경우 (예: 원초 단면을 사용한 불완전한 해결)에서 다를 수 있습니다. ModelSolveParametersProto.initial_basis를 통해 시작 기준을 제공하는 경우 이 값은 무시됩니다. SolutionProto.basis가 반환한 기준과만 관련이 있습니다. |
SparseBasisStatusVector
기본 상태의 벡터를 희소하게 표현한 것입니다.
JSON 표현 |
---|
{
"ids": [
string
],
"values": [
enum ( |
필드 | |
---|---|
ids[] |
모든 요소를 구별하여 오름차순으로 정렬해야 합니다. |
values[] |
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 |
Solver가 실행 가능성 상태를 주장하지 않습니다. |
SOLUTION_STATUS_FEASIBLE |
문제 해결사는 솔루션이 실행 가능하다고 주장합니다. |
SOLUTION_STATUS_INFEASIBLE |
문제 해결사는 솔루션이 실행 불가능하다고 주장합니다. |
SolutionHintProto
문제 해결사를 위한 추천 시작 솔루션
MIP 솔버는 일반적으로 원시 정보 (variableValues
)만 원하는 반면 LP 솔버는 원시 정보 및 이중 정보 (dualValues
)를 모두 원합니다.
많은 MIP 솔버는 (1) 모든 변수를 지정하지 않는 부분 해법 또는 (2) 실행 불가능한 해법을 사용할 수 있습니다. 이러한 경우 솔버는 일반적으로 하위 MIP를 해결하여 힌트를 완료/수정합니다.
문제 해결사가 힌트를 사용하는 방법은 해결사, 문제 유형, 사용하는 알고리즘에 따라 크게 달라집니다. 힌트가 효과를 발휘하도록 하는 가장 신뢰할 수 있는 방법은 힌트를 포함하거나 포함하지 않고 기본 솔버 로그를 읽는 것입니다.
단순 기반 LP 솔버는 일반적으로 솔루션 힌트보다 초기 기반을 선호합니다 (그렇지 않으면 힌트를 기본적인 실행 가능한 솔루션으로 변환하기 위해 크로스오버해야 함).
JSON 표현 |
---|
{ "variableValues": { object ( |
필드 | |
---|---|
variableValues |
문제의 원시 변수에 값을 부분적으로 할당하는 것입니다. 이 하위 메시지의 해결사 독립적 요구사항은 다음과 같습니다. *variableValues.ids는 VariablesProto.ids의 요소입니다. * varValues.values는 모두 유한해야 합니다. |
dualValues |
문제의 선형 제약 조건에 대한 값 할당 (부분적일 수 있음)입니다. 요구사항: * dualValues.ids는 LinearConstraintsProto.ids의 요소입니다. * dualValues.values는 모두 유한해야 합니다. |
SparseInt32VectorProto
정수 벡터의 희소 표현입니다.
JSON 표현 |
---|
{ "ids": [ string ], "values": [ integer ] } |
필드 | |
---|---|
ids[] |
모든 요소를 구별하여 오름차순으로 정렬해야 합니다. |
values[] |
ID와 길이가 같아야 합니다. |
SolveResultProto
원색/이중 해법/광선이 복잡한 경우의 계약서에 나온 자세한 설명은 종료_reasons.md를 참고하세요.
정확한 계약이 확정될 때까지는 해지 사유에 의존하기보다는 솔루션/레이가 있는지 간단히 확인하는 것이 가장 안전합니다.
JSON 표현 |
---|
{ "termination": { object ( |
필드 | |
---|---|
termination |
문제 해결사가 중지된 이유입니다. |
solutions[] |
향후 문제 해결자가 구현해야 하는 솔루션의 순서는 일반적으로 다음과 같은 기준으로 정렬합니다. 1. 기본 실현 가능한 해가 있는 해로, 가장 먼저 가장 적합한 기본 목표 순으로 정렬됩니다. 2. 가능한 이중 목표가 있는 솔루션이 최적의 이중 목표 (알 수 없는 이중 목표가 최악임) 순으로 정렬됨 3. 나머지 모든 솔루션은 순서와 관계없이 반환될 수 있습니다. |
primalRays[] |
무한한 기본 개선 또는 이중 실행 불가 인증서에 대한 방향 일반적으로 CancellationReasonProtos UNBOUNDED 및 DUAL_INFEASIBLE용으로 제공됩니다. |
dualRays[] |
무한한 이중 개선 또는 이에 상응하는 기본적인 실행 불가 인증서에 대한 방향 일반적으로 CancellationReasonProto INFEASIBLE을 위해 제공됩니다. |
solveStats |
해결 프로세스에 대한 통계입니다. 예: 실행할 수 있습니다 |
TerminationProto
Solve() 호출이 종료된 이유에 관한 모든 정보입니다.
JSON 표현 |
---|
{ "reason": enum ( |
필드 | |
---|---|
reason |
값이 TERMINATION_REASON_FEASIBLE 또는 TERMINATION_REASON_NO_SOLUTION_FOUND인 경우 |
limit |
사유가 TERMINATION_REASON_FEASIBLE 또는 TERMINATION_REASON_NO_SOLUTION_FOUND인 경우를 제외하고 LIMIT_UNSPECIFIED입니다. 모든 솔버가 종료를 야기한 한도를 항상 확인할 수 있는 것은 아니며, 원인을 파악할 수 없는 경우 LIMIT_UNDETERMINED가 사용됩니다. |
detail |
종료에 관한 추가 일반적으로 솔버 관련 정보입니다. |
problemStatus |
원시 문제와 이중 문제의 실행 가능성 상태입니다. 2023년 7월 18일부터 이 메시지가 누락되었을 수 있습니다. 누락된 경우 SolveResultProto.solve_stats에서 problemStatus를 찾을 수 있습니다. |
objectiveBounds |
최적의 목표 값에 대한 경계입니다. 2023년 7월 18일부터 이 메시지가 누락되었을 수 있습니다. 누락된 경우 SolveResultProto.solve.stats.best_primal_bound에서 audienceBounds.primal_bound가, SolveResultProto.solve.stats.best_dual_bound에서 goalBounds.dual_bound를 찾을 수 있습니다. |
TerminationReasonProto
Solve() 호출이 종료되는 이유입니다.
열거형 | |
---|---|
TERMINATION_REASON_UNSPECIFIED |
|
TERMINATION_REASON_OPTIMAL |
입증할 수 있는 최적의 솔루션 (숫자 허용 오차까지)을 찾았습니다. |
TERMINATION_REASON_INFEASIBLE |
원시 문제에는 실현 가능한 해결책이 없습니다. |
TERMINATION_REASON_UNBOUNDED |
원시 문제는 실현 가능하며 원시 광선을 따라 임의의 양호한 해법을 찾을 수 있습니다. |
TERMINATION_REASON_INFEASIBLE_OR_UNBOUNDED |
원시 문제는 실현 불가능하거나 무한합니다. 문제 상태에 대한 자세한 내용은SolveStats.problem_status에서 확인할 수 있습니다. Gurobi의 unbounded 상태는 여기에 매핑될 수 있습니다. |
TERMINATION_REASON_IMPRECISE |
문제가 위의 기준 (Optimal, Infeasible, Unbounded, InfeasibleOrUnbounded) 중 하나로 해결되었지만 하나 이상의 허용 오차가 충족되지 않았습니다. 일부 기본/이중 해법/광선이 존재하지만 약간 실현 불가능하거나 (문제가 거의 최적화된 경우) 최상의 솔루션 목표와 최상의 목표 경계 사이의 격차가 될 수 있습니다. 사용자는 여전히 원시/이중 해/선 및 용액 통계를 쿼리할 수 있지만, 수치 부정확성을 처리해야 합니다. |
TERMINATION_REASON_FEASIBLE |
옵티마이저가 일종의 한계에 도달하여 실현 가능한 해답이 반환됩니다. 도달한 한도에 관한 자세한 설명은 SolveResultProto.limit_detail을 참고하세요. |
TERMINATION_REASON_NO_SOLUTION_FOUND |
옵티마이저가 일종의 한계에 도달했지만 현실적으로 가능한 해결책을 찾지 못했습니다. 도달한 한도에 관한 자세한 설명은 SolveResultProto.limit_detail을 참고하세요. |
TERMINATION_REASON_NUMERICAL_ERROR |
복구할 수 없는 숫자 오류가 발생하여 알고리즘이 중지되었습니다. 솔루션 정보가 없습니다. |
TERMINATION_REASON_OTHER_ERROR |
위에 정의된 상태 중 하나에 해당하지 않는 오류로 인해 알고리즘이 중지되었습니다. 솔루션 정보가 없습니다. |
LimitProto
Solve()가 CancellationReasonProto FEASIBLE 또는 NO_SOLUTION_FOUND로 조기에 중지되는 경우 도달한 구체적인 한도입니다.
열거형 | |
---|---|
LIMIT_UNSPECIFIED |
제한에서 벗어나지 않았을 때 null 값으로 사용됩니다 (예: TERMINATION_REASON_OPTIMAL). |
LIMIT_UNDETERMINED |
기본 솔버가 어떤 한도에 도달했는지 노출하지 않습니다. |
LIMIT_ITERATION |
반복 알고리즘이 최대 반복 횟수 (예: 심플렉스 또는 배리어 반복)를 실행한 후 중지되었습니다. |
LIMIT_TIME |
사용자가 지정한 계산 시간 후에 알고리즘이 중지되었습니다. |
LIMIT_NODE |
브랜치 및 바인딩된 트리에서 최대 노드 수를 탐색했기 때문에 브랜치 및 바인딩 알고리즘이 중지되었습니다. |
LIMIT_SOLUTION |
필요한 개수의 해를 찾았기 때문에 알고리즘이 중지되었습니다. 이는 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가 사용됩니다. ExpirationProto.detail에는 한도에 대한 추가 정보가 포함될 수 있습니다. |
ProblemStatusProto
솔버가 주장한 원초 문제와 그 이중 (또는 지속적인 완화의 이중)의 실행 가능성 상태입니다. 솔버가 클레임에 대한 인증서를 반환할 필요는 없습니다. 예를 들어 솔버가 원시 실행 가능한 솔루션을 반환하지 않고 원시 실행 가능성을 주장할 수 있습니다. 이 결합된 상태는 해결된 문제의 실행 가능성과 무한성에 대한 문제 해결사의 주장을 포괄적으로 설명합니다. 예를 들면 다음과 같습니다.
- 원시 및 이중 문제에 대한 가능한 상태는 원점이 실현 가능하고 제한적이며 최적의 해결 방법 (비선형 제약 조건이 없는 문제에 보장됨)을 가지고 있을 가능성이 높음을 나타냅니다.
- 원시 가능한 상태와 이중 실행 불가 상태는 원래 문제가 무한하다는 것을 나타냅니다 (즉, 임의의 양호한 해결 방법이 있음).
이중 실현 불가능한 상태 그 자체 (즉, 결정되지 않은 원시 상태가 수반됨)는 두 문제를 모두 실현할 수 없을 수 있으므로 원시 문제가 무한하다는 것을 암시하지 않습니다. 또한 원시 및 이중 실행 가능한 상태는 최적의 솔루션이 있음을 암시할 수 있지만 솔버가 실제로 이러한 최적의 솔루션을 찾았다고 보장하지는 않습니다.
JSON 표현 |
---|
{ "primalStatus": enum ( |
필드 | |
---|---|
primalStatus |
원시 문제의 상태입니다. |
dualStatus |
이중 문제 (또는 지속적인 긴장 완화의 이중) 상태입니다. |
primalOrDualInfeasible |
true인 경우 솔버는 원시 또는 이중 문제가 실행 불가능하다고 주장하지만 어떤 문제 (또는 둘 다 실행 가능하지 않은지)는 알지 못합니다. Primeal_problem_status = dual_problem_status = kUnresolved인 경우에만 true가 될 수 있습니다. 이러한 추가 정보는 전처리를 통해 문제에 대한 최적의 솔루션이 없다고 판단할 때 종종 필요합니다 (그러나 이것이 실행 불가능성인지, 무한성인지 또는 둘 다 때문인지는 판단할 수 없음). |
FeasibilityStatusProto
해결사가 요청한 문제 타당성 상태입니다 (해결자가 해당 클레임에 대한 인증서를 반환할 필요는 없음).
열거형 | |
---|---|
FEASIBILITY_STATUS_UNSPECIFIED |
상태가 없음을 나타내는 보호 값입니다. |
FEASIBILITY_STATUS_UNDETERMINED |
Solver가 상태를 요구하지 않습니다. |
FEASIBILITY_STATUS_FEASIBLE |
문제 해결사가 문제가 실행 가능하다고 주장합니다. |
FEASIBILITY_STATUS_INFEASIBLE |
문제 해결사는 문제가 실행 불가능하다고 주장합니다. |
ObjectiveBoundsProto
최적의 목표 값에 대한 경계입니다.
JSON 표현 |
---|
{ "primalBound": number, "dualBound": number } |
필드 | |
---|---|
primalBound |
Solver는 최적의 값이 솔버의 기본 실행 가능성 허용 범위 (아래 경고 참조)에 대한 PrialBound와 같거나 더 좋다고 주장합니다 (최소화의 경우 더 작지만 최대화의 경우 더 큼). * PrimealBound는 솔버가 이러한 경계를 가지고 있다고 주장하지 않는 경우 사소합니다 (최소화의 경우 +inf, 최소화의 경우 -inf 극대화). * PrimealBound는 가능한 최상의 원용 해법의 목표보다 최적 값에 더 가까울 수 있습니다. 특히 PrimealBound는 기본 가능한 해가 반환되지 않는 경우에도 그리 간단하지 않을 수 있습니다. 경고: 정확한 주장은 *이 수치적으로 실행 가능하며 (즉, 해결자 허용치까지 가능함) *에 목표 값 primalBound가 있는 기본 해법이 있다는 것입니다. 수치적으로 가능한 이 솔루션은 약간 현실적이지 않을 수 있으며, 이 경우 primaryalBound가 최적 값보다 엄격히 더 나을 수 있습니다. 특히 실행 가능성 허용 범위가 상대적으로 큰 경우 (예: PDLP로 해결할 때)에는 기본 타당성 허용치를 PrialBound에서 허용 오차로 변환하는 것이 그리 간단하지 않습니다. |
dualBound |
솔버가 최적의 값이 솔버의 이중 실행 가능성 허용 범위까지 dualBound보다 같거나 더 나쁘다고 주장합니다(최소화의 경우 더 크고, 최대화의 경우 더 작음). * dualBound는 솔버가 이러한 제한을 갖고 있다고 주장하지 않는 경우(최소화의 경우 -inf, +inf 극대화의 경우) 십대입니다. primaryalBound와 마찬가지로 최적을 반환하는 경우에도 일부 솔버에서 이 문제가 발생할 수 있습니다. MIP 솔버는 일반적으로 경계가 부정확하더라도 보고합니다. * 연속 문제의 경우 dualBound는 실현 가능한 최상의 이중 솔루션의 목표보다 최적 값에 더 가까울 수 있습니다. MIP의 경우 dualBound에서 중요한 첫 번째 값 중 하나는 MIP의 LP 완화 최적값인 경우가 많습니다. * dualBound가 솔버 허용 범위 (아래 경고 참조)에 이르기까지 PrialBound보다 더 우수해야 합니다 (최소화의 경우 더 작고, 최대화를 위해 더 큼). 경고: * 연속 문제의 경우 정확한 주장은 *이 수치적으로 실행 가능 (즉, 솔버 허용 범위까지 실행 가능) *이 목표 값 dualBound를 갖는 이중 솔루션이 존재한다는 것입니다. 수치적으로 가능한 이 솔루션은 약간 현실적이지 않을 수 있으며, 이 경우 dualBound가 최적 값 및 primalBound보다 나빠질 수 있습니다. 기본 사례와 마찬가지로 이중 실행 가능성 허용 범위를 dualBound에서 허용 오차로 변환하는 것은 그리 간단하지 않으며 특히 실행 가능성 허용 범위가 비교적 큰 경우에는 더욱 그렇습니다. 그러나 일부 솔버는 수치상으로 더 안전할 수 있는 수정된 버전의 dualBound를 제공합니다. 수정된 버전은 솔버의 특정 출력 (예: PDLP의 경우 pdlp_output.convergence_information.corrected_dual_objective)을 통해 액세스할 수 있습니다. * MIP 솔버의 경우 dualBound가 일부 지속적인 완화 (예: LP 완화)를 위한 이중 솔루션과 연결될 수도 있지만, 솔버 실행의 복잡한 결과인 경우가 많으며, 일반적으로 LP 솔버가 보고한 범위보다 더 부정확합니다. |
SolutionProto
해결 방법은 문제의 종류와 해결사에 따라 다릅니다. 현재 공통 패턴은 1입니다. MIP 솔버는 기본 해법만 반환합니다. 2. 심플 LP 솔버는 기저와 이 기저와 관련된 기본 해법과 이중 해법을 반환하는 경우가 많습니다. 3. 다른 연속 솔버는 솔버에 종속된 형식으로 연결된 기본 및 이중 솔루션을 반환하는 경우가 많습니다.
요구사항: * 하나 이상의 필드를 설정해야 합니다. 솔루션은 비워 둘 수 없습니다.
JSON 표현 |
---|
{ "primalSolution": { object ( |
필드 | |
---|---|
primalSolution |
|
dualSolution |
|
basis |
|
PrimalSolutionProto
최적화 문제에 대한 해결책입니다.
예: 간단한 선형 프로그램을 생각해 보세요. min c * x s.t. A * x >= b x >= 0과 같습니다. 기본 해법은 x에 값을 할당하는 것입니다. 위의 A * x >= b 및 x >= 0을 만족하는 경우 가능합니다. 아래의 PrimalSolutionProto 메시지에서 변수 값은 x이고 목표 값은 c * x입니다.
JSON 표현 |
---|
{ "variableValues": { object ( |
필드 | |
---|---|
variableValues |
요구사항: * variableValues.ids는 VariablesProto.ids의 요소입니다. * varValues.values는 모두 유한해야 합니다. |
objectiveValue |
기본 솔버에서 계산한 목표 값입니다. 무한 또는 NaN일 수 없습니다. |
auxiliaryObjectiveValues |
기본 솔버에서 계산된 보조 목표 값입니다. 키는 유효한 보조 목표 ID여야 합니다. 값은 무한 또는 NaN일 수 없습니다.
|
feasibilityStatus |
기본 솔버에 따른 솔루션의 실행 가능성 상태입니다. |
DualSolutionProto
두 가지 최적화 문제에 대한 해결책입니다.
예: 원초 이중 쌍 선형 프로그램 쌍인 (원시) (이중) min c * x max b * y s.t. A * x >= bs.t. y * A + r = c x >= 0 y, r >= 0과 같습니다. 이중 솔루션은 쌍 (y, r)입니다. 위의 (Dual) 제약 조건을 만족하는 경우 적합합니다.
아래 메시지에서 y는 dualValues, r은 감소된 비용, b * y는 목표 값입니다.
JSON 표현 |
---|
{ "dualValues": { object ( |
필드 | |
---|---|
dualValues |
요구사항: * dualValues.ids는 LinearConstraints.ids의 요소입니다. * dualValues.values는 모두 유한해야 합니다. |
reducedCosts |
요구사항: * reduceCosts.ids는 VariablesProto.ids의 요소입니다. * ReduceCosts.values는 모두 유한해야 합니다. |
feasibilityStatus |
기본 솔버에 따른 솔루션의 실행 가능성 상태입니다. |
objectiveValue |
|
PrimalRayProto
최적화 문제를 무한히 개선할 수 있는 방향입니다. 마찬가지로, 최적화 문제 이중에 대한 실행 불가 인증서입니다.
예: 간단한 선형 프로그램을 생각해 보세요. min c * x s.t. A * x >= b x >= 0인 원광선은 c * x <를 충족하는 x입니다. 0 A * x >= 0 x >= 0 주어진 해에 주어진 원광선의 양의 배수와 해당 용액의 배수가 여전히 실현 가능하며 더 나은 목표값을 제공합니다. 또한 원시 광선은 이중 최적화 문제를 실행할 수 없음을 증명합니다.
아래의 PrimalRay 메시지에서 변수 값은 x입니다.
JSON 표현 |
---|
{
"variableValues": {
object ( |
필드 | |
---|---|
variableValues |
요구사항: * variableValues.ids는 VariablesProto.ids의 요소입니다. * variableValues.values는 모두 유한해야 합니다. |
DualRayProto
최적화라는 두 가지 문제를 모두 포괄하는 무한한 개선 방향입니다. 원조 실황 인증서도 마찬가지입니다.
예: 원초 이중 쌍 선형 프로그램 쌍인 (원시) (이중) min c * x max b * y s.t. A * x >= bs.t. y * A + r = c x >= 0 y, r >= 0과 같습니다. 이중 광선은 (y, r)을 만족하는 쌍입니다. b * y > 0 y * A + r = 0 y, r >= 0 이중 실행 가능한 솔루션에 (y, r)의 양의 배수를 추가하면 이중 실행 가능성이 유지되고 목표가 개선됩니다 (이중이 제한되지 않음을 증명). 또한 이중 광선은 원시 문제가 현실적으로 불가능함을 증명합니다.
아래 DualRay 메시지에서 y는 dualValues이고 r은 축소비용입니다.
JSON 표현 |
---|
{ "dualValues": { object ( |
필드 | |
---|---|
dualValues |
요구사항: * dualValues.ids는 LinearConstraints.ids의 요소입니다. * dualValues.values는 모두 유한해야 합니다. |
reducedCosts |
요구사항: * reduceCosts.ids는 VariablesProto.ids의 요소입니다. * ReduceCosts.values는 모두 유한해야 합니다. |
SolveStatsProto
JSON 표현 |
---|
{
"solveTime": string,
"problemStatus": {
object ( |
필드 | |
---|---|
solveTime |
math_opt로 측정된 실제 경과 시간으로, Solver::Solve() 내의 시간과 비슷합니다. 참고: 모델을 빌드한 작업은 여기에 포함되지 않습니다. 소수점 아래가 최대 9자리까지이고 ' |
problemStatus |
원시 문제와 이중 문제의 실행 가능성 상태입니다. |
simplexIterations |
|
barrierIterations |
|
firstOrderIterations |
|
nodeCount |
|