Method: mathopt.solveMathOptModel

Wykonuje obliczenia modelu wejściowego i zwraca wynik od razu. Skorzystaj z tej opcji, gdy nie potrzebujesz wywołań zwrotnych, przyrostu wartości ani śledzenia postępu rozwiązania.

Żądanie HTTP

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

Adres URL używa składni transkodowania gRPC.

Treść żądania

Treść żądania zawiera dane o następującej strukturze:

Zapis JSON 
{
  "solverType": enum (SolverTypeProto),
  "model": {
    object (ModelProto)
  },
  "parameters": {
    object (SolveParametersProto)
  },
  "modelParameters": {
    object (ModelSolveParametersProto)
  }
}
Pola
solverType

enum (SolverTypeProto)

Opcjonalnie: Typ rozwiązania matematycznego do rozwiązania zadania liczbowego. Pamiętaj, że jeśli rozwiązanie nie obsługuje konkretnej funkcji modelu, procedura optymalizacji się nie powiedzie.
model

object (ModelProto)

Wymagane. Matematyczna reprezentacja zadania optymalizacyjnego do rozwiązania.
parameters

object (SolveParametersProto)

Opcjonalnie: Parametry do sterowania pojedynczym rozwiązaniem. Parametr allowoutput jest obsługiwany w szczególności. W przypadku rozwiązań, które obsługują wywołania zwrotne wiadomości, ustawienie wartości Prawda spowoduje, że serwer zarejestruje wywołanie zwrotne wiadomości. Otrzymane wiadomości zostaną zwrócone w formacie SolveMathOptModelResponse.messages. W przypadku innych rozwiązań ustawienie wartości allowOutput na „true” (prawda) spowoduje błąd.
modelParameters

object (ModelSolveParametersProto)

Opcjonalnie: Parametry do sterowania pojedynczym rozwiązaniem, które są specyficzne dla modelu wejściowego (w sekcji SolveParametersProto znajdziesz parametry niezależne od modelu).

Treść odpowiedzi

Odpowiedź na jednoargumentowe rozwiązanie zdalne w narzędziu MathOpt.

W przypadku powodzenia treść żądania zawiera dane o następującej strukturze:

Zapis JSON 
{
  "result": {
    object (SolveResultProto)
  },
  "messages": [
    string
  ]
}
Pola
result

object (SolveResultProto)

Opis wyników rozwiązania modelu w żądaniu.
messages[]

string

Jeśli użyto parametru SolveParametersProto.enable_output, będą one zawierać komunikaty logu dotyczące rozwiązań obsługujących wywołania zwrotne wiadomości.

SolverTypeProto

Rozwiązania obsługiwane przez funkcję MathOpt.

Wartości w polu enum
SOLVER_TYPE_UNSPECIFIED
SOLVER_TYPE_GSCIP

Rozwiązywanie programów SCIP (Constraint Integer Programs – rozwiązania innych firm).

Obsługuje zadania z zapisami LP, MIP oraz z niewypukłymi liczbami całkowitymi. Nie są jednak zwracane podwójne dane dotyczące stron docelowych. Preferuj GLOP w przypadku stron docelowych.
SOLVER_TYPE_GUROBI

Rozwiązanie Gurobi (inna firma).

Obsługuje zadania z zapisami LP, MIP oraz z niewypukłymi liczbami całkowitymi. Jest to zwykle najszybsza opcja, ale ma specjalne licencje.
SOLVER_TYPE_GLOP

Rozwiązanie Google Glop.

Obsługuje LP z użyciem metod podstawowych i podwójnych.
SOLVER_TYPE_CP_SAT

Rozwiązanie Google CP-SAT.

Obsługuje zadania, w których wszystkie zmienne są liczbami całkowitymi i ograniczonymi (lub domniemane, że występuje po presolve). Eksperymentalna obsługa przeskalowania i dyskretowania problemów ze zmiennymi ciągłymi.
SOLVER_TYPE_PDLP

Rozwiązanie Google PDLP.

Obsługuje obiektywy kwadratowe i wypukłe w kierunku LP. Używa metod pierwszego rzędu zamiast metody jednokierunkowej. mogą rozwiązać bardzo duże problemy.
SOLVER_TYPE_GLPK

GNU Linear Programming Kit (GLPK) (inna firma).

Obsługuje MIP i LP.

Bezpieczeństwo wątków: GLPK używa pamięci lokalnej wątku na potrzeby alokacji pamięci. W związku z tym instancje Solver muszą zostać zniszczone w tym samym wątku, w którym są tworzone. W przeciwnym razie GLPK ulegnie awarii. Wydaje się, że można wywołać funkcję Solver::Solve() z innego wątku niż ten użyty do utworzenia funkcji Solver, ale nie jest to udokumentowane w GLPK i należy tego unikać.

Podczas ustalania LP za pomocą presora rozwiązanie (i niepowiązane promienie) jest zwracane tylko wtedy, gdy zostało znalezione optymalne rozwiązanie. W przeciwnym razie nic nie jest zwracane. Szczegółowe informacje można znaleźć na stronie glpk-5.0/doc/glpk.pdf nr 40 dostępnej pod adresem glpk-5.0.tar.gz.
SOLVER_TYPE_OSQP

Rozwiązanie do podziału operatora w ramach programu kwadratowego (OSQP) (firma zewnętrzna).

Obsługuje ciągłe zadania z ograniczeniami liniowymi oraz liniowymi lub wypukłymi celami kwadratowymi. Używa metody pierwszego rzędu.
SOLVER_TYPE_ECOS

Embedded Conic Solver (ECOS) (inna firma).

Obsługuje problemy LP i SOCP. Stosuje metody punktowe wewnątrz (przeszkoda).
SOLVER_TYPE_SCS

The Splitting Conic Solver (SCS) (firma zewnętrzna).

Obsługuje problemy LP i SOCP. Używa metody pierwszego rzędu.
SOLVER_TYPE_HIGHS

HiGHS Solver (inna firma).

Obsługuje problemy z poziomem strony docelowej i MIP (wypukłe QP nie są zaimplementowane).
SOLVER_TYPE_SANTORINI

Referencyjna implementacja rozwiązania MIP w MathOpt.

Powolne działanie lub niezalecane w środowisku produkcyjnym. To nie jest narzędzie do rozwiązywania problemów LPD (brak zwróconych informacji).

ModelProto

Problem z optymalizacją. MathOpt obsługuje: – ciągłe i całkowite zmienne decyzji z opcjonalnymi granicami skończonymi. – Cele liniowe i kwadratowe (jeden lub wiele celów), zminimalizowane lub zmaksymalizowane. – Wiele typów ograniczeń, w tym: * Ograniczenia liniowe * Ograniczenia kwadratowe * Ograniczenia stożkowe drugiego rzędu * Ograniczenia logiczne > Ograniczenia SOS1 i SOS2 > Ograniczenia wskaźnika

Domyślnie ograniczenia są przedstawione w formacie „identyfikator do danych” map. Reprezentujemy jednak ograniczenia liniowe w bardziej efektywnym „strukturze tablic” .

Zapis 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)
    },
    ...
  }
}
Pola
name

string
variables

object (VariablesProto)
objective

object (ObjectiveProto)

Główny cel w modelu.
auxiliaryObjectives

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

Cele pomocnicze do wykorzystania w modelach wielocelowych.

Identyfikatory kluczy mapowania muszą mieć format [0, max(int64)). Każdy priorytet i każda nazwa, która nie jest pusta, muszą być niepowtarzalne i różnić się od podstawowego elementu objective.

Obiekt zawierający listę par "key": value. Przykład: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
linearConstraints

object (LinearConstraintsProto)
linearConstraintMatrix

object (SparseDoubleMatrixProto)

Współczynniki zmienne ograniczeń liniowych.

Jeśli zmienna powiązana z tym ograniczeniem zostanie usunięta, jest traktowana tak, jakby miała wartość 0.

Wymagania: * element linearConstraintMatrix.row_ids to elementy obiektu linearConstraints.ids. * Element linearConstraintMatrix.column_ids to elementy zmiennej hosts.ids. * Nieokreślone wpisy macierzy mają wartość 0. * Wszystkie wartości linearConstraintMatrix.values muszą być skończone.
quadraticConstraints

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

Ograniczenia kwadratowe w modelu.

Obiekt zawierający listę par "key": value. Przykład: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
secondOrderConeConstraints

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

Ograniczenia stożkowe drugiego rzędu w modelu.

Obiekt zawierający listę par "key": value. Przykład: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
sos1Constraints

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

Ograniczenia SOS1 w modelu, które określają, że maksymalnie 1 expression nie może mieć wartości zero. Opcjonalne wpisy weights to szczegóły implementacji używane przez rozwiązanie do szybszego uzgodnienia. Dokładniej rzecz ujmując, rozwiązania te mogą (lub nie) wykorzystać te wagi przy wyborze decyzji rozgałęzionych, które dają „zrównoważone” węzłów podrzędnych.

Obiekt zawierający listę par "key": value. Przykład: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
sos2Constraints

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

Ograniczenia SOS2 w modelu, które sprawiają, że maksymalnie 2 wpisy funkcji expression nie mogą być zerowe i muszą przylegać w kolejności. Jeśli nie podano właściwości weights, jest to ich kolejność liniowa na liście expressions; jeśli podane są wartości weights, stosowana jest kolejność rosnąca względem tych wartości.

Obiekt zawierający listę par "key": value. Przykład: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
indicatorConstraints

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

Ograniczenia wskaźników w modelu, które go wymuszają w przypadku binarnej „zmiennej wskaźnika” ma wartość jeden, a następnie „domniemane ograniczenie” musi utrzymywać.

Obiekt zawierający listę par "key": value. Przykład: { "name": "wrench", "mass": "1.3kg", "count": "3" }.

VariablesProto

W poniższym przykładzie definiujemy „#variables” = size(ZmienneProto.ids).

Zapis JSON 
{
  "ids": [
    string
  ],
  "lowerBounds": [
    number
  ],
  "upperBounds": [
    number
  ],
  "integers": [
    boolean
  ],
  "names": [
    string
  ]
}
Pola
ids[]

string (int64 format)

Musi być nieujemna i ściśle rosnąca. Nie można użyć wartości max(int64).
lowerBounds[]

number

Długość powinna być równa #zmiennym oraz wartościom w [-inf, inf).
upperBounds[]

number

Długość powinna być równa #variables, a wartości w (-inf, inf].
integers[]

boolean

Długość powinna być równa #zmiennej. Wartość to „false” w przypadku zmiennych ciągłych i „prawda” w przypadku zmiennych liczb całkowitych.
names[]

string

Jeśli zasada nie jest skonfigurowana, zakłada się, że wszystkie ciągi są puste. W przeciwnym razie długość powinna być równa #variables.

Wszystkie nazwy, które nie są puste, muszą być różne.

ObjectiveProto

Zapis JSON 
{
  "maximize": boolean,
  "offset": number,
  "linearCoefficients": {
    object (SparseDoubleVectorProto)
  },
  "quadraticCoefficients": {
    object (SparseDoubleMatrixProto)
  },
  "name": string,
  "priority": string
}
Pola
maximize

boolean

wartość fałsz oznacza minimalizację, prawda oznacza maksymalizację;
offset

number

Musi być skończony, a nie NaN.
linearCoefficients

object (SparseDoubleVectorProto)

Terminy ObjectiveProto liniowe w zmiennych decyzyjnych.

Wymagania: * linearCoEffectives.ids są elementami zmiennej variablesProto.ids. * Nieokreślony parametr ZmiennesProto ma wartość 0. * Wszystkie wartości linearne.wartości muszą być skończone. * Wartość linearCoefficiencys.values może wynosić zero, ale powoduje to tylko marnowanie miejsca.
quadraticCoefficients

object (SparseDoubleMatrixProto)

Terminy obiektywne w zmiennych decyzyjnych, które są kwadratowe.

Wymagania oprócz wymagań dotyczących komunikatów SparseDoubleMatrixProto: * Każdy element quadraticCoeffectives.row_ids i każdego elementu parametru quadraticCoeffectives.column_ids musi być elementem ZmiennesProto.ids. * Macierz musi być trójkątna: dla każdego i współczynniki kwadratowe.identyfikatory_wierszy[i] <= współczynniki kwadratowe.identyfikatory_kolumn[i].

Uwagi: * współczynniki, które nie są bezpośrednio przechowywane, mają wartość zero. * Elementy składowe quadraticCo ocenias.coefficiencys mogą wynosić 0, ale powoduje to tylko zmarnowanie miejsca.
name

string

Wiadomości nadrzędne mogą mieć w tym polu wymagania dotyczące unikatowości. np. zapoznaj się z sekcjami ModelProto.objectives i AuxiliaryObjectivesUpdatesProto.new_objectives.
priority

string (int64 format)

W przypadku problemów wielozadaniowych priorytet tego celu w porównaniu z innymi (niższy jest ważniejszy). Ta wartość nie może być ujemna. Ponadto każdy priorytet celu w modelu musi być inny w czasie rozwiązania. Ten warunek nie jest weryfikowany na poziomie protokołu, dlatego modele mogą tymczasowo mieć cele o tym samym priorytecie.

SparseDoubleVectorProto

Rzadka reprezentacja wektora liczby zmiennoprzecinkowej.

Zapis JSON 
{
  "ids": [
    string
  ],
  "values": [
    number
  ]
}
Pola
ids[]

string (int64 format)

Muszą być sortowane (w kolejności rosnącej), tak aby wszystkie elementy były inne.
values[]

number

Musi mieć taką samą długość jak identyfikatory. Nie może zawierać NaN.

SparseDoubleMatrixProto

Rzadka reprezentacja macierzy liczby podwójnej precyzji.

Macierz jest przechowywana jako potrójne wartości identyfikatora wiersza, identyfikatora kolumny i współczynnika. Te 3 wektory muszą mieć taką samą długość. W przypadku każdego parametru i krotka (rowIds[i], columnIds[i]) powinna być inna. Wpisy muszą być w kolejności głównej.

Zapis JSON 
{
  "rowIds": [
    string
  ],
  "columnIds": [
    string
  ],
  "coefficients": [
    number
  ]
}
Pola
rowIds[]

string (int64 format)
columnIds[]

string (int64 format)
coefficients[]

number

Nie może zawierać NaN.

LinearConstraintsProto

W dalszej części artykułu definiujemy „#linearne ograniczenia”. = rozmiar(LinearConstraintsProto.ids).

Zapis JSON 
{
  "ids": [
    string
  ],
  "lowerBounds": [
    number
  ],
  "upperBounds": [
    number
  ],
  "names": [
    string
  ]
}
Pola
ids[]

string (int64 format)

Musi być nieujemna i ściśle rosnąca. Nie można użyć wartości max(int64).
lowerBounds[]

number

Długość powinna być równa #linearną ograniczeniom i wartościom w [-inf, inf).
upperBounds[]

number

Długość powinna być równa #linearne ograniczenia, wartości w (-inf, inf].
names[]

string

Jeśli zasada nie jest skonfigurowana, zakłada się, że wszystkie ciągi są puste. W przeciwnym razie długość powinna być równa #linearne ograniczenia.

Wszystkie nazwy, które nie są puste, muszą być różne.

QuadraticConstraintProto

Jedno ograniczenie kwadratowe w formie: lb <= sum{linearTerms} + sum{quadraticTerms} <= ub.

Jeśli zmienna powiązana z tym ograniczeniem zostanie usunięta, jest traktowana tak, jakby miała wartość 0.

Zapis JSON 
{
  "linearTerms": {
    object (SparseDoubleVectorProto)
  },
  "quadraticTerms": {
    object (SparseDoubleMatrixProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string
}
Pola
linearTerms

object (SparseDoubleVectorProto)

Wyrazy liniowe w zmiennych decyzyjnych.

Oprócz wymagań dotyczących komunikatów SparseDoubleVectorProto wymagamy, aby: * element linearTerms.ids był elementami parametru variablesProto.ids. * Parametr linearTerms.values musi mieć format skończony i inny niż NaN.

Uwagi: * pominięte identyfikatory zmiennych mają odpowiedni współczynnik równy zero. * Parametr linearTerms.values może mieć wartość 0, ale powoduje to tylko marnowanie miejsca.
quadraticTerms

object (SparseDoubleMatrixProto)

Wyrazy o równaniu kwadratowym w zmiennych decyzyjnych.

Oprócz wymagań dotyczących komunikatów SparseDoubleMatrixProto wymagamy, aby: * Każdy element quadraticTerms.row_ids i każdego elementu quadraticTerms.column_ids musi być elementem ZmiennesProto.ids. * Macierz musi być trójkątną górną: w przypadku każdego i quadraticTerms.row_ids[i] <= quadraticTerms.column_ids[i].

Uwagi: * współczynniki, które nie są bezpośrednio przechowywane, mają wartość zero. * Elementy parametru quadraticTerms.coeffectives mogą wynosić zero, ale to tylko marnuje miejsce.
lowerBound

number

Musi mieć wartość w [-inf, inf) i być mniejsza lub równa upperBound.
upperBound

number

Wartość musi być równa (-inf, inf] oraz większa lub równa lowerBound.
name

string

Wiadomości nadrzędne mogą mieć w tym polu wymagania dotyczące unikatowości. np. w sekcjach ModelProto.quadratic_constraints i QuadraticConstraintUpdatesProto.new_constraints.

SecondOrderConeConstraintProto

Ograniczenie jednego stożka drugiego rzędu w formie:

||argumentsToNorm||_2 <= upperBound,

gdzie upperBound i każdy element argumentsToNorm są wyrażeniami liniowymi.

Jeśli zmienna powiązana z tym ograniczeniem zostanie usunięta, jest traktowana tak, jakby miała wartość 0.

Zapis JSON 
{
  "upperBound": {
    object (LinearExpressionProto)
  },
  "argumentsToNorm": [
    {
      object (LinearExpressionProto)
    }
  ],
  "name": string
}
Pola
upperBound

object (LinearExpressionProto)
argumentsToNorm[]

object (LinearExpressionProto)
name

string

Wiadomości nadrzędne mogą mieć w tym polu wymagania dotyczące unikatowości. np. patrz ModelProto.second_order_cone_constraints i SecondOrderConeConstraintUpdatesProto.new_constraints.

LinearExpressionProto

Rzadka reprezentacja wyrażenia liniowego (ważona suma zmiennych i stałe przesunięcie).

Zapis JSON 
{
  "ids": [
    string
  ],
  "coefficients": [
    number
  ],
  "offset": number
}
Pola
ids[]

string (int64 format)

Identyfikatory zmiennych. Muszą być sortowane (w kolejności rosnącej), tak aby wszystkie elementy były inne.
coefficients[]

number

Musi mieć taką samą długość jak identyfikatory. Wartości muszą być skończone, ale nie NaN.
offset

number

Musi być skończona i nie może być NaN.

SosConstraintProto

Dane do reprezentowania pojedynczego ograniczenia SOS1 lub SOS2.

Jeśli zmienna powiązana z tym ograniczeniem zostanie usunięta, jest traktowana tak, jakby miała wartość 0.

Zapis JSON 
{
  "expressions": [
    {
      object (LinearExpressionProto)
    }
  ],
  "weights": [
    number
  ],
  "name": string
}
Pola
expressions[]

object (LinearExpressionProto)

Wyrażenia, w których należy zastosować ograniczenie SOS: * SOS1: maksymalnie jeden element ma wartość inną niż zero. * SOS2: maksymalnie 2 elementy mogą mieć wartości inne niż zero i muszą przylegać do siebie w powtarzającej się kolejności.
weights[]

number

Pole może być puste lub mieć taką samą długość jak wyrażenia. Jeśli pole jest puste, wagi domyślne to 1, 2, ... Jeśli występuje, wpisy muszą być unikalne.
name

string

Wiadomości nadrzędne mogą mieć w tym polu wymagania dotyczące unikatowości. np. zobacz model Proto.sos1_constraints i SosConstraintUpdatesProto.new_constraints.

IndicatorConstraintProto

Dane do przedstawiania ograniczenia według jednego wskaźnika w postaci: zmienna(indicatorId) = (activateOnZero? 0 : 1) ⇒ dolna granica <= wyrażenie <= górna granica.

Jeśli zmienna powiązana z tym ograniczeniem (wskaźnik lub pojawiająca się w polu expression) zostanie usunięta, jest traktowana tak, jakby miała wartość 0. W szczególności usunięcie zmiennej wskaźnika oznacza, że ograniczenie wskaźnika jest bezwartościowe, jeśli activateOnZero ma wartość fałsz, i że jest to odpowiednik ograniczenia liniowego, jeśli activateOnZero ma wartość prawda.

Zapis JSON 
{
  "activateOnZero": boolean,
  "expression": {
    object (SparseDoubleVectorProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string,
  "indicatorId": string
}
Pola
activateOnZero

boolean

Jeśli zmienna wskaźnika ma wartość 0, to jeśli zmienna wskaźnika ma wartość 0, musi obowiązywać domniemane ograniczenie. W przeciwnym razie, jeśli zmienna wskaźnika przyjmuje wartość 1, musi obowiązywać domniemane ograniczenie.
expression

object (SparseDoubleVectorProto)

Musi być prawidłowym wyrażeniem liniowym w odniesieniu do modelu, który z nich korzysta: * wszystkie podane warunki dla funkcji SparseDoubleVectorProto, * wszystkie elementy funkcji expression.values muszą być skończone, * expression.ids są podzbiorem funkcji VariablesProto.ids.
lowerBound

number

Musi zawierać wartość w [-inf, inf); nie może być NaN.
upperBound

number

Musi mieć wartość w (-inf, inf]; nie może być NaN.
name

string

Wiadomości nadrzędne mogą mieć w tym polu wymagania dotyczące unikatowości. np. patrz ModelProto.indicator_constraints i IndicatorConstraintUpdatesProto.new_constraints.
indicatorId

string (int64 format)

Identyfikator odpowiadający zmiennej binarnej lub nieskonfigurowany. Jeśli zasada jest nieskonfigurowana, ograniczenie wskaźnika jest ignorowane. Jeśli jest ustawiony, wymagamy, aby: * variablesProto.integers[indicatorId] = true, * ZmiennesProto.lower_bounds[indicatorId] >= 0, * ZmiennesProto.upper_bounds[indicatorId] <= 1. Te warunki nie są weryfikowane przez MathOpt, ale jeśli nie zostaną spełnione, narzędzie do rozwiązania zwróci błąd.

SolveParametersProto

Parametry do sterowania pojedynczym rozwiązaniem.

Zawiera oba parametry wspólne dla wszystkich rozwiązań, np. limit czasu i parametry konkretnego rozwiązania, np. gscip. Jeśli wartość jest ustawiona zarówno we wspólnym polu, jak i w polu dotyczącym konkretnego rozwiązania, używane jest ustawienie dotyczące konkretnego rozwiązania.

Typowe parametry, które są opcjonalne i nieskonfigurowane, lub wyliczenie z nieokreśloną wartością wskazują, że używana jest wartość domyślna rozwiązania.

Określone parametry rozwiązywania problemów innych niż używany są ignorowane.

Parametry zależne od modelu (np. priorytet odgałęzienia jest ustawiany dla każdej zmiennej) są przekazywane w ModelSolveParametersProto.

Zapis 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
}
Pola
timeLimit

string (Duration format)

Maksymalny czas, który musi poświęcić na rozwiązanie problemu (lub nieokreślony, jeśli nie jest ustawiony).

Ta wartość nie jest sztywnym limitem; czas rozwiązania może go nieznacznie przekroczyć. Ten parametr jest zawsze przekazywany do bazowego rozwiązania do rozwiązywania problemów. Wartość domyślna rozwiązania nie jest używana.

Czas trwania w sekundach składający się z maksymalnie 9 cyfr po przecinku, kończący się cyfrą „s”. Przykład: "3.5s".
enableOutput

boolean

Umożliwia drukowanie logów czasu implementacji rozwiązania. Lokalizacja tych logów czasu zależy od rozwiązania. W przypadku SCIP i Gurobi są to standardowe strumienie wyjściowe. W przypadku Glop i CP-SAT spowoduje to LOG(INFO).

Jeśli rozwiązanie obsługuje wywołanie zwrotne wiadomości, a użytkownik zarejestruje dla niego wywołanie zwrotne, ta wartość parametru będzie ignorowana, a ślady nie będą wyświetlane.
lpAlgorithm

enum (LPAlgorithmProto)

Algorytm do rozwiązywania zadań liniowych. Jeśli wartość to LP_ALGORITHM_UNSPECIFIED, użyj domyślnego algorytmu rozwiązania.

Ta wartość może zostać użyta w przypadku problemów, które nie są programami liniowymi, ale gdzie programowanie liniowe jest podprogramem. Na przykład: Rozwiązania MIP zazwyczaj używają tego rozwiązania tylko do rozwiązywania problemów z poziomem głównej strony głównej (w przeciwnym razie korzystają z technologii Dual Simplex).
presolve

enum (EmphasisProto)

Spróbuj uprościć zadanie przed uruchomieniem głównego algorytmu lub domyślny poziom wysiłku rozwiązania, jeśli EMPHASIS_UNSPECIFIED.
cuts

enum (EmphasisProto)

Wysiłek w celu uzyskania silniejszego złagodzenia LP (tylko MIP) lub domyślnego poziomu wysiłku rozwiązania, jeśli EMPHASIS_UNSPECIFIED.

UWAGA: wyłączenie cięć może uniemożliwić wywołaniem zwrotnym dodanie cięć na poziomie MIP_NODE. To działanie jest specyficzne dla rozwiązania.
heuristics

enum (EmphasisProto)

Wysiłek w celu znalezienia realnych rozwiązań wykraczających poza te zastosowane w pełnej procedurze wyszukiwania (tylko w przypadku MOP) lub na domyślnym poziomie wysiłku rozwiązania (jeśli EMPHASIS_UNSPECIFIED).
scaling

enum (EmphasisProto)

Wysiłek związany z przeskalowaniem problemu w celu poprawy stabilności liczbowej lub domyślnego poziomu wysiłku rozwiązania, jeśli EMPHASIS_UNSPECIFIED.
iterationLimit

string (int64 format)

Ogranicz liczbę iteracji będącego podstawą algorytmu (np. przestawień prostego kodu). Konkretne zachowanie zależy od użytego rozwiązania i algorytmu, ale często może dać deterministyczny limit rozwiązań (może być potrzebna dodatkowa konfiguracja, np. 1 wątek).

Zwykle obsługiwane przez rozwiązania LP, QP i MIP, ale w przypadku rozwiązań MIP sprawdź też limit węzłów.
nodeLimit

string (int64 format)

Ograniczenie liczby podproblemów rozwiązanych w wyszukiwaniu wyliczeniowym (np. gałęzi i bound). W przypadku wielu rozwiązań może to być używane do deterministycznego ograniczenia obliczeń (mogą być potrzebne dodatkowe ustawienia, np. 1 wątek).

Wartość ta jest zwykle dostępna w przypadku rozwiązań MIP. Zapoznaj się też z zasadą iterationLimit.
cutoffLimit

number

Rozwiązanie zatrzymuje się wcześnie, jeśli może udowodnić, że nie ma rozwiązań pierwszych, które byłyby równie skuteczne jak wartość graniczna.

W przypadku wcześniejszego zatrzymania rozwiązanie zwraca przyczynę zakończenia działania NO_SOLUTION_FOUND z limitem CUTOFF i nie musi podawać żadnych dodatkowych informacji o rozwiązaniu. Nie ma wpływu na wartość zwracaną, jeśli nie ma wcześniejszego zatrzymania.

Zalecamy stosowanie tolerancji, jeśli chcesz, aby zwracane były rozwiązania o celu dokładnie równym wartości granicznej.

Więcej informacji znajdziesz w przewodniku użytkownika oraz w porównaniu z bestBoundLimit.
objectiveLimit

number

Rozwiązanie zatrzymuje się wcześnie, gdy znajdzie rozwiązanie co najmniej tak dobre, z uzasadnioną przyczyną zamknięcia i ograniczeniem OBJECTIVE.
bestBoundLimit

number

Rozwiązanie zatrzymuje się wcześnie, gdy udowodni, że najlepsza granica jest przynajmniej taka dobra. Powód zamknięcia to FEASIBLE lub NO_SOLUTION_FOUND i ograniczenie OBJECTIVE.

Więcej informacji znajdziesz w przewodniku użytkownika oraz porównanie wartości z limitem cutoffLimit.
solutionLimit

integer

Po znalezieniu tak wielu realistycznych rozwiązań rozwiązanie zatrzymuje się wcześnie, przy czym powód zamknięcia jest PRAKTYCZNY i ogranicza ROZWIĄZANIE. Jeśli jest ustawione, wartość musi być większa niż 0. Często przydaje się to do zatrzymania rozwiązania przy pierwszym znalezionym możliwym rozwiązaniu. Pamiętaj, że nie ma gwarancji co do wartości celu dla każdego zwróconego rozwiązania.

Rozwiązania matematyczne zwykle nie zwracają większej liczby rozwiązań niż limit, ale MathOpt nie jest egzekwowany (zobacz też b/214041169).

Obecnie obsługiwane w przypadku Gurobi i SCIP oraz tylko w przypadku CP-SAT z wartością 1.
threads

integer

Jeśli jest ustawiona, musi być >= 1.
randomSeed

integer

Materiał wyjściowy dla generatora pseudolosowych liczb w podstawowym rozwiązaniu. Pamiętaj, że wszystkie rozwiązania używają pseudolosowych liczb do wybierania czynników takich jak perturbacja w algorytmie LP, reguły rozdzielania i ustalanie heurystyczne. Zmiana tej wartości może mieć zauważalny wpływ na działanie rozwiązań.

Chociaż we wszystkich rozwiązaniach obowiązuje koncepcja nasion, pamiętaj, że prawidłowe wartości zależą od rzeczywistego rozwiązania. – Gurobi: [0:GRB_MAXINT] (co wg Gurobi 9.0 to 2x10^9). – GSCIP: [0:2147483647] (czyli MAX_INT lub kint32max lub 2^31-1). – GLOP: [0:2147483647] (tak samo jak powyżej) we wszystkich przypadkach rozwiązanie do rozwiązania otrzyma wartość równą: MAX(0; MIN(MAX_VALID_VALUE_FOR_SOLVER, randomSeed)).
absoluteGapTolerance

number

Bezwzględna tolerancja optymalizacji (przede wszystkim) w przypadku rozwiązań MIP.

Bezwzględna wartość GAP to bezwzględna wartość różnicy między: * obiektywną wartością najlepszego znalezionego rozwiązania i * podwójną granicą wypracowaną przez wyszukiwanie. Rozwiązanie może zostać zatrzymane, gdy bezwzględna wartość GAP osiągnie wartość najwyżej bezwzględną (po ustawieniu) i zwrócić TERMINATION_REASON_OPTIMAL.

Jeśli jest ustawiona, musi wynosić >= 0.

Zobacz też względną lukę w tolerancji.
relativeGapTolerance

number

Względna tolerancja optymalizacji (głównie) w przypadku rozwiązań MIP.

Względna wartość GAP to znormalizowana wersja bezwzględnej wartości GAP (zdefiniowana na podstawie tolerancji bezwzględnej), gdzie normalizacja zależy od rozwiązania, np. wartość bezwzględna GAP podzielona przez wartość obiektywną najlepszego znalezionego rozwiązania.

Rozwiązanie może zostać zatrzymane, gdy względna wartość GAP będzie miała wartość co najmniej względnąGapTolerance (po ustawieniu) i zwróci TERMINATION_REASON_OPTIMAL.

Jeśli jest ustawiona, musi wynosić >= 0.

Zobacz też wartość bezwzględną tolerancji bezwzględnej.
solutionPoolSize

integer

Podczas wyszukiwania zachowaj do solutionPoolSize rozwiązań. Pula rozwiązań ma zasadniczo 2 funkcje: (1) W przypadku rozwiązań, które mogą zwrócić więcej niż 1 rozwiązanie, ogranicza to liczbę zwróconych rozwiązań. (2) Niektóre rozwiązania mogą przeprowadzać heurystykę, korzystając z rozwiązań z puli rozwiązań, więc zmiana tej wartości może wpłynąć na ścieżkę algorytmu. Aby wymusić wypełnienie puli rozwiązań przez rozwiązanie, np. i n najlepszych rozwiązań wymaga dalszej, specyficznej konfiguracji.

LPAlgorithmProto

Wybiera algorytm do rozwiązywania programów liniowych.

Wartości w polu enum
LP_ALGORITHM_UNSPECIFIED
LP_ALGORITHM_PRIMAL_SIMPLEX Metoda (pierwotna) typu Simplex. Występują zwykle pierwotne i podwójne rozwiązania, pierwotne/podwójne promienie w przypadku problemów podstawowych/podwójnych, które są podstawą.
LP_ALGORITHM_DUAL_SIMPLEX Metoda podwójnej prostoty. Występują zwykle pierwotne i podwójne rozwiązania, pierwotne/podwójne promienie w przypadku problemów podstawowych/podwójnych, które są podstawą.
LP_ALGORITHM_BARRIER Metoda bariery, nazywana też metodą z punktem wewnętrznym (IPM). Zwykle można podać zarówno rozwiązanie pierwotne, jak i podwójne. Niektóre implementacje mogą też generować promienie w przypadku nieograniczonych lub niemożliwych problemów. Podstawa nie jest podana, chyba że bazowe rozwiązanie do wykonania „łączy się” i kończy kropką.
LP_ALGORITHM_FIRST_ORDER Algorytm oparty na metodzie pierwszego rzędu. Takie rozwiązania dają zwykle zarówno podstawowe, jak i podwójne rozwiązania, a także certyfikaty pierwotnych lub podwójnych niewykonalności. Metody pierwszego zamówienia zwykle zapewniają rozwiązania o niższej dokładności, dlatego użytkownicy powinni zadbać o określanie parametrów jakości (np. tolerancje) i weryfikowanie rozwiązań.

EmphasisProto

Poziom wysiłku zastosowany do zadania opcjonalnego w trakcie rozwiązywania problemu (patrz: SolveParametersProto).

Wyróżnienie jest używane do konfigurowania funkcji rozwiązania w ten sposób: * Jeśli rozwiązanie nie obsługuje tej funkcji, prawidłowa będzie tylko wartość UNSPECIFIED. Każde inne ustawienie będzie zwykle błędem nieprawidłowego argumentu (niektóre rozwiązania mogą też akceptować wartość WYŁ.). * Jeśli rozwiązanie obsługuje tę funkcję: – Jeśli zasada ma wartość UNSPECIFIED, używana jest podstawowa wartość domyślna. - Jeśli nie można wyłączyć tej funkcji, wyłączenie spowoduje zwrócenie błędu. – Jeśli funkcja jest domyślnie włączona, wartością domyślną rozwiązania jest zwykle ŚREDNI. - Jeśli funkcja jest obsługiwana, wartości LOW, ŚREDNIA, WYSOKA i BARDZO WYSOKA nigdy nie będą powodować błędu i zostaną zmapowane na najlepsze dopasowanie.

Wartości w polu enum
EMPHASIS_UNSPECIFIED
EMPHASIS_OFF
EMPHASIS_LOW
EMPHASIS_MEDIUM
EMPHASIS_HIGH
EMPHASIS_VERY_HIGH

ModelSolveParametersProto

Zapis JSON 
{
  "variableValuesFilter": {
    object (SparseVectorFilterProto)
  },
  "dualValuesFilter": {
    object (SparseVectorFilterProto)
  },
  "reducedCostsFilter": {
    object (SparseVectorFilterProto)
  },
  "initialBasis": {
    object (BasisProto)
  },
  "solutionHints": [
    {
      object (SolutionHintProto)
    }
  ],
  "branchingPriorities": {
    object (SparseInt32VectorProto)
  }
}
Pola
variableValuesFilter

object (SparseVectorFilterProto)

Filtr stosowany do wszystkich zwracanych rozproszonych kontenerów kluczowanych przez zmienne w PrimalSolutionProto i PrimalRayProto (wartości PrimalSolutionProto.variable_wartości, PrimalRayProto.variable_values).

Wymagania: * odfiltrowane identyfikatory to elementy parametru variablesProto.ids.
dualValuesFilter

object (SparseVectorFilterProto)

Filtr stosowany do wszystkich zwróconych kontenerów rozproszonych, do których klucze są oparte na ograniczeniach liniowych w DualSolutionProto i DualRay (DualSolutionProto.dual_values, DualRay.dual_values).

Wymagania: * filterIds to elementy LinearConstraints.ids.
reducedCostsFilter

object (SparseVectorFilterProto)

Filtr stosowany do wszystkich zwracanych rozproszonych kontenerów kluczowanych przez zmienne w DualSolutionProto i DualRay (DualSolutionProto.reduced_costs, DualRay.reduced_costs).

Wymagania: * odfiltrowane identyfikatory to elementy parametru variablesProto.ids.
initialBasis

object (BasisProto)

Opcjonalna wstępna podstawa do rozwiązywania problemów LP z pamięci z pamięci. Jeśli jest ustawiony, powinien być poprawny zgodnie z zasadą ValidateBasis w polu validators/solution_validator.h w bieżącym okresie: ModelSummary.
solutionHints[]

object (SolutionHintProto)

Opcjonalne wskazówki dotyczące rozwiązań. Jeśli bazowe rozwiązanie akceptuje tylko jedną wskazówkę, używana jest pierwsza wskazówka.
branchingPriorities

object (SparseInt32VectorProto)

Opcjonalne priorytety rozgałęzienia. Zmienne z wyższymi wartościami zostaną rozgałęzione na początku. Zmienne, dla których nie zostały ustawione priorytety, otrzymują domyślny priorytet rozwiązania (zwykle 0).

Wymagania: * wartość branchingPriorities.values musi być skończona. * branchingPriorities.ids muszą być elementami parametru ZmiennesProto.ids.

SparseVectorFilterProto

Ten komunikat umożliwia wykonywanie zapytań lub ustawianie określonych części wektora SparseXxxxVector. Działanie domyślne nie polega na odfiltrowywaniu czegokolwiek. Typowym zastosowaniem jest wysyłanie zapytań dotyczących tylko części rozwiązań (tylko wartości innych niż zero lub ręcznie wybranego zbioru wartości zmiennych).

Zapis JSON 
{
  "skipZeroValues": boolean,
  "filterByIds": boolean,
  "filteredIds": [
    string
  ]
}
Pola
skipZeroValues

boolean

W przypadku SparseBoolVectorProto „zero” jest false.
filterByIds

boolean

Jeśli zasada ma wartość prawda, zwracane są tylko wartości odpowiadające identyfikatorom wymienionym w identyfikatorze filtra.
filteredIds[]

string (int64 format)

Lista identyfikatorów, które mają być używane, gdy filterByIds mają wartość prawda. To pole musi być puste, jeśli parametr filterByIds ma wartość false (fałsz). UWAGA: jeśli to pole jest puste, a filterByIds ma wartość true, oznacza to, że w wyniku nie chcesz wyświetlać żadnych informacji.

BasisProto

Charakterystyka kombinacyjna rozwiązania programu liniowego.

Metoda jednorazowa do rozwiązywania programów liniowych zawsze zwraca „podstawowe możliwe rozwiązanie” które można opisać kombinatoricznie za pomocą podstawy. Podstawa przypisuje wartość BasisStatusProto każdej zmiennej i ograniczeniu liniowemu.

Na przykład: użyj standardowej postaci LP: min c * x s.t. A * x = b x >= 0, który ma więcej zmiennych niż ograniczenia i pełną pozycję wiersza A.

Niech n będzie liczbą zmiennych, a m liczbą ograniczeń liniowych. Prawidłową podstawę tego problemu można zdefiniować w ten sposób: * Wszystkie ograniczenia będą miały stan podstawy FIXED. * Wybierz m zmiennych, aby kolumny A były liniowo niezależne i przypisano im stan PODSTAWOWY. * pozostałym zmiennym (n–m) przypisz stan AT_LOWER.

Podstawowym rozwiązaniem tej zasady jest unikalne rozwiązanie funkcji A * x = b, w którym wszystkie zmienne o stanie AT_LOWER mają stałą wartość u dolnych granic (wszystkie 0). Otrzymane rozwiązanie jest nazywane podstawowym, realnym rozwiązaniem, jeśli spełnia też warunki x >= 0.

Zapis JSON 
{
  "constraintStatus": {
    object (SparseBasisStatusVector)
  },
  "variableStatus": {
    object (SparseBasisStatusVector)
  },
  "basicDualFeasibility": enum (SolutionStatusProto)
}
Pola
constraintStatus

object (SparseBasisStatusVector)

Stan podstawy ograniczenia.

Wymagania: * constraintStatus.ids równa się LinearConstraints.ids.
variableStatus

object (SparseBasisStatusVector)

Zmienna.

Wymagania: * constraintStatus.ids równa się variablesProto.ids.
basicDualFeasibility

enum (SolutionStatusProto)

To zaawansowana funkcja wykorzystywana przez MathOpt do określania wykonalności nieoptymalnych rozwiązań LPG (rozwiązania optymalne zawsze mają stan SOLUTION_STATUS_FEASIBLE).

W przypadku jednostronnych elementów strony docelowej powinna być ona równa stanowi wykonalności powiązanego rozwiązania podwójnego. W przypadku dwustronnych elementów LP może się różnić w niektórych przypadkach skrajnych (np. w nieukończonych rozwiązaniach z podstawowym elementem jednostkowym).

Jeśli podajesz podstawę jako podstawę za pomocą ModelSolveParametersProto.initial_basis, ta wartość jest ignorowana. Ma znaczenie tylko dla podstawy zwróconej przez SolutionProto.basis.

SparseBasisStatusVector

Rzadka reprezentacja wektora stanów podstaw.

Zapis JSON 
{
  "ids": [
    string
  ],
  "values": [
    enum (BasisStatusProto)
  ]
}
Pola
ids[]

string (int64 format)

Muszą być sortowane (w kolejności rosnącej), tak aby wszystkie elementy były inne.
values[]

enum (BasisStatusProto)

Musi mieć taką samą długość jak identyfikatory.

BasisStatusProto

Stan zmiennej/ograniczenia na podstawie elementu docelowego.

Wartości w polu enum
BASIS_STATUS_UNSPECIFIED Wartość zabezpieczenia reprezentująca brak stanu.
BASIS_STATUS_FREE Zmienna/ograniczenie jest swobodna (nie ma skończonych granic).
BASIS_STATUS_AT_LOWER_BOUND Zmienna/ograniczenie znajduje się w dolnej granicy (która musi być skończona).
BASIS_STATUS_AT_UPPER_BOUND Zmienna/ograniczenie znajduje się w górnej granicy (która musi być skończona).
BASIS_STATUS_FIXED_VALUE Zmienna/ograniczenie ma identyczną dolną i górną granicę.
BASIS_STATUS_BASIC Zmienna/ograniczenie jest podstawowa.

SolutionStatusProto

Wykonalność pierwotnego lub podwójnego rozwiązania zgodnie z deklaracją rozwiązania.

Wartości w polu enum
SOLUTION_STATUS_UNSPECIFIED Wartość zabezpieczenia reprezentująca brak stanu.
SOLUTION_STATUS_UNDETERMINED Narzędzie Solver nie zgłasza praw do stanu wykonalności.
SOLUTION_STATUS_FEASIBLE Według funkcji Solver rozwiązanie jest możliwe.
SOLUTION_STATUS_INFEASIBLE Twórcy rozwiązań twierdzą, że rozwiązanie jest niewykonalne.

SolutionHintProto

Sugerowane rozwiązanie początkowe.

Rozwiązania MIP wymagają zwykle informacji podstawowych (variableValues), natomiast rozwiązania LP wymagają zarówno informacji podstawowych, jak i podwójnych (dualValues).

Wiele rozwiązań MIP może działać z: (1) rozwiązaniami częściowymi, które nie określają wszystkich zmiennych, lub (2) rozwiązaniami niewykonalnymi. W takich przypadkach rozwiązania zazwyczaj rozwiązują inny plik MIP, aby uzupełnić lub poprawić podpowiedź.

Sposób, w jaki rozwiązanie wykorzysta wskazówkę, (o ile w ogóle) zależy od rozwiązania, typu problemu i zastosowanego algorytmu. Najbardziej niezawodnym sposobem na zapewnienie skuteczności podpowiedzi jest odczytywanie bazowych logów rozwiązań z użyciem podpowiedzi i bez niej.

Rozwiązania LP oparte na prostych rozwiązaniach LP zwykle wolą na początkowym etapie ścieżki (w przeciwnym razie muszą przejść na inną).

Zapis JSON 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "dualValues": {
    object (SparseDoubleVectorProto)
  }
}
Pola
variableValues

object (SparseDoubleVectorProto)

Prawdopodobnie częściowe przypisanie wartości do podstawowych zmiennych problemu. Niezależne od rozwiązania wymagania dla tego komunikatu podrzędnego są następujące: * ZmienneValues.ids to elementy parametru variablesProto.ids. * ZmienneValues.values muszą być wartościami skończonymi.
dualValues

object (SparseDoubleVectorProto)

(potencjalnie częściowe) przypisanie wartości do liniowych ograniczeń problemu.

Wymagania: * dualValues.ids to elementy obiektu LinearConstraintsProto.ids. * Wszystkie wartości dualValues.values muszą być skończone.

SparseInt32VectorProto

Rzadka reprezentacja wektora liczb całkowitych.

Zapis JSON 
{
  "ids": [
    string
  ],
  "values": [
    integer
  ]
}
Pola
ids[]

string (int64 format)

Należy go sortować (w kolejności rosnącej), tak aby wszystkie elementy były inne.
values[]

integer

Musi mieć taką samą długość jak identyfikatory.

SolveResultProto

Umowa dotycząca rozwiązania podstawowego/podwójnego/promieniowania jest złożona. Pełny opis znajdziesz tutaj: termin_wykonania_reasons.md.

Do czasu ostatecznego zawarcia umowy najbezpieczniej jest po prostu sprawdzać, czy rozwiązanie jest dostępne, zamiast polegać na przyczynie rozwiązania umowy.

Zapis JSON 
{
  "termination": {
    object (TerminationProto)
  },
  "solutions": [
    {
      object (SolutionProto)
    }
  ],
  "primalRays": [
    {
      object (PrimalRayProto)
    }
  ],
  "dualRays": [
    {
      object (DualRayProto)
    }
  ],
  "solveStats": {
    object (SolveStatsProto)
  }
}
Pola
termination

object (TerminationProto)

Przyczyna zatrzymania rozwiązania.
solutions[]

object (SolutionProto)

Ogólna umowa dotycząca kolejności rozwiązań, które powinny wdrożyć rozwiązania w przyszłości, to porządkowanie według: 1. Rozwiązania z pierwotnym, wykonalnym rozwiązaniem, uporządkowane według najlepszego głównego celu. 2. Rozwiązania obejmujące 2 wykonalne rozwiązania, uporządkowane według najlepszego 2 celów (nieznany podwójny cel jest najgorszy) 3. Wszystkie pozostałe rozwiązania można zwrócić w dowolnej kolejności.
primalRays[]

object (PrimalRayProto)

Kierunki nieograniczonego pierwotnego ulepszania lub równoważnego podwójnego certyfikatu niewykonalności. Zwykle dostarczany w przypadku TerminationReasonProtos UNBOUNDED i DUAL_INFEASIBLE
dualRays[]

object (DualRayProto)

Kierunki nieograniczonego podwójnej poprawy lub równoważnych certyfikatów niewykonalności. Zwykle dostarczana w przypadku TerminationReasonProto INFEASIBLE.
solveStats

object (SolveStatsProto)

statystyki procesu rozwiązywania, np. czas trwania czy iteracje.

TerminationProto

Wszystkie informacje na temat powodów zakończenia wywołania funkcji Solve().

Zapis JSON 
{
  "reason": enum (TerminationReasonProto),
  "limit": enum (LimitProto),
  "detail": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "objectiveBounds": {
    object (ObjectiveBoundsProto)
  }
}
Pola
reason

enum (TerminationReasonProto)

Dodatkowe informacje w polu limit, w przypadku których wartość to TERMINATION_REASON_FEASIBLE lub TERMINATION_REASON_NO_SOLUTION_FOUND; szczegóły znajdziesz tutaj: limit.
limit

enum (LimitProto)

Jest LIMIT_UNSPECIFIED, chyba że przyczyna to TERMINATION_REASON_FEASIBLE lub TERMINATION_REASON_NO_SOLUTION_FOUND. Nie wszystkie rozwiązania potrafią określić limit, który spowodował zamknięcie. Jeśli nie można ustalić przyczyny, używana jest wartość LIMIT_UNDETERMINED.
detail

string

Dodatkowe informacje dotyczące rozwiązania umowy.
problemStatus

object (ProblemStatusProto)

Stany wykonalności problemów podstawowych i podwójnych. Od 18 lipca 2023 r. tej wiadomości może brakować. Jeśli jej nie ma, status problemStatus można znaleźć w funkcji SolveResultProto.solve_stats.
objectiveBounds

object (ObjectiveBoundsProto)

Granice przy optymalnej wartości celu. Od 18 lipca 2023 r. tej wiadomości może brakować. Jeśli go nie ma, pole celBounds.primal_bound można znaleźć w parametrach SolveResultProto.solve.stats.best_primal_bound oraz celBounds.dual_bound, który można znaleźć w funkcji SolveResultProto.solve.stats.best_dual_bound.

TerminationReasonProto

Przyczyna zakończenia wywołania funkcji Solve().

Wartości w polu enum
TERMINATION_REASON_UNSPECIFIED
TERMINATION_REASON_OPTIMAL Znaleziono ewidentnie optymalne rozwiązanie (do tolerancji liczbowych).
TERMINATION_REASON_INFEASIBLE Pierwotny problem nie ma żadnych realnych rozwiązań.
TERMINATION_REASON_UNBOUNDED Pierwotny problem jest wykonalny i dowolnie dobre rozwiązania można znaleźć wzdłuż promienia pierwotnego.
TERMINATION_REASON_INFEASIBLE_OR_UNBOUNDED Pierwotny problem jest albo niewykonalny lub nieograniczony. Więcej informacji o stanie problemu można znaleźć w sekcji resolveStats.problem_status. Nieograniczony status Gurobi może zostać naniesiony tutaj.
TERMINATION_REASON_IMPRECISE

Problem został rozwiązany w przypadku jednego z powyższych kryteriów (Optimal, Infeasible, Unbounded, InfeasibleOrUnbounded), ale nie została spełniona co najmniej 1 tolerancja. Niektóre rozwiązania pierwotne/podwójne/promieniowanie są wprawdzie nieco niemożliwe do realizacji, a jeśli problem był niemal optymalny, mogą one wskazywać na różnicę między najlepszym a najbardziej optymalnym celem.

Użytkownicy mogą nadal wysyłać zapytania dotyczące rozwiązań podstawowych/podwójnych/promieni oraz statystyk rozwiązań, ale muszą sobie radzić z niedokładnością liczbową.
TERMINATION_REASON_FEASIBLE Optymalizator osiągnął jakiś limit i zwrócone zostaje pierwsze wykonalne rozwiązanie. Szczegółowy opis rodzaju limitu znajdziesz w sekcji SolveResultProto.limit_detail.
TERMINATION_REASON_NO_SOLUTION_FOUND Optymalizator osiągnął pewien limit i nie znalazł podstawowego wykonalnego rozwiązania. Szczegółowy opis rodzaju limitu znajdziesz w sekcji SolveResultProto.limit_detail.
TERMINATION_REASON_NUMERICAL_ERROR Algorytm przestał działać, ponieważ napotkał nieodwracalny błąd numeryczny. Brak dostępnych informacji o rozwiązaniach.
TERMINATION_REASON_OTHER_ERROR Algorytm przestał działać z powodu błędu, którego nie obejmuje żaden ze stanów. Brak dostępnych informacji o rozwiązaniach.

LimitProto

Konkretny limit, który osiągnięto, gdy funkcja Solve() zatrzymuje się przed czasem przy funkcji TerminationReasonProto FEASIBLE lub NO_SOLUTION_FOUND.

Wartości w polu enum
LIMIT_UNSPECIFIED Używana jako wartość null, gdy zakończenie nie występuje z powodu limitu (np. TERMINATION_REASON_OPTIMAL).
LIMIT_UNDETERMINED Bazowe rozwiązanie do rozwiązywania problemów nie ujawnia, który limit został osiągnięty.
LIMIT_ITERATION Algorytm iteracyjny zatrzymał się po wykonaniu maksymalnej liczby iteracji (np. iteracji typu jednokierunkowego lub powtórzenia bariery).
LIMIT_TIME Algorytm przestał działać po upływie czasu obliczeń określonego przez użytkownika.
LIMIT_NODE Algorytm gałęzi i powiązany został zatrzymany, ponieważ zbadał maksymalną liczbę węzłów w drzewie gałęzi i powiązanej.
LIMIT_SOLUTION Algorytm przestał działać, ponieważ znalazł wymaganą liczbę rozwiązań. Jest to często stosowane w modelach MIP, aby rozwiązanie zwracało pierwsze realne rozwiązanie.
LIMIT_MEMORY Algorytm przestał działać, ponieważ zabrakło pamięci.
LIMIT_CUTOFF Rozwiązanie problemu zostało uruchomione z wartością odcięcia celu (np. ustawiona została wartość SolveParameters.cutoff_limit), co oznacza, że użytkownik nie życzył sobie rozwiązania gorszego niż wartość graniczna, a rozwiązanie stwierdziło, że nie ma rozwiązań o takiej samej jakości jak wartość graniczna. Zwykle nie podaje się żadnych dodatkowych informacji o rozwiązaniach.
LIMIT_OBJECTIVE Algorytm przestał działać, ponieważ znalazł rozwiązanie lub wartość lepsza niż limit ustawiony przez użytkownika (patrz SolveParameters.objective_limit i SolveParameters.best_bound_limit).
LIMIT_NORM Algorytm przestał działać, ponieważ norma iteracji stała się zbyt duża.
LIMIT_INTERRUPTED Algorytm został zatrzymany z powodu sygnału przerwania działania lub żądania przerwania działania przez użytkownika.
LIMIT_SLOW_PROGRESS Algorytm przestał działać, ponieważ nie mógł kontynuować pracy nad rozwiązaniem.
LIMIT_OTHER

Algorytm przestał działać z powodu limitu, którego nie obejmuje żaden z powyższych. Pamiętaj, że wartość LIMIT_UNDETERMINED jest używana, gdy nie można określić przyczyny, a wartość LIMIT_OTHER jest używana, gdy przyczyna jest znana, ale nie pasuje do żadnej z powyższych opcji.

TerminationProto.detail może zawierać dodatkowe informacje na temat limitu.

ProblemStatusProto

Stan wykonalności pierwotnego problemu i jego podwójny (lub podwójny ciągłe złagodzenie) zgodnie z deklaracją rozwiązania. Rozwiązanie nie musi zwracać certyfikatu dla twierdzenia (np. może twierdzić, że jest prawdziwa wykonalność, nie zwracając pierwotnego, wykonalnego rozwiązania). Ten połączony stan zapewnia kompleksowy opis twierdzeń rozwiązania problemu dotyczącego wykonalności i nieograniczenia rozwiązania. Przykład:

  • Praktyczny stan dla problemów podstawowych i podwójnych wskazuje, że pierwsze jest możliwe i ograniczone, a najprawdopodobniej ma rozwiązanie optymalne (gwarantowane w przypadku problemów bez ograniczeń nieliniowych).
  • podstawowy możliwy do realizacji, a podwójnie niewykonalny stan wskazuje, że pierwotny problem jest nieograniczony (tzn. ma arbitralnie dobre rozwiązania).

Uwaga: sam podwójny niemożliwy stan (tj. któremu towarzyszy nieokreślony status pierwotny) nie oznacza, że problem podstawowy jest nieograniczony, ponieważ oba problemy mogą być niewykonalne. Co więcej, chociaż stan podstawowy i podwójnie realistyczny może sugerować istnienie rozwiązania optymalnego, nie gwarantuje, że to rozwiązanie rzeczywiście znalazło takie optymalne rozwiązanie.

Zapis JSON 
{
  "primalStatus": enum (FeasibilityStatusProto),
  "dualStatus": enum (FeasibilityStatusProto),
  "primalOrDualInfeasible": boolean
}
Pola
primalStatus

enum (FeasibilityStatusProto)

Stan pierwszego problemu.
dualStatus

enum (FeasibilityStatusProto)

Stan podwójnego problemu (lub podwójnej relaksacji).
primalOrDualInfeasible

boolean

Jeśli funkcja ma wartość prawda, funkcja rozwiązywania problemów twierdzi, że podstawowy lub podwójny problem jest niemożliwy do zrealizowania, ale nie wie, który z nich (lub czy oba te problemy są niewykonalne). Może być prawdziwa tylko wtedy, gdy primal_problem_status = dual_problem_status = kUndetermined. Te dodatkowe informacje są często potrzebne, gdy wstępne przetwarzanie wskazuje, że nie ma optymalnego rozwiązania problemu (ale nie można określić, czy wynika to z niewykonalności, braku ograniczeń, czy z obu tych powodów).

FeasibilityStatusProto

Stan wykonalności zadania określony przez rozwiązanie (nie jest wymagany zwracanie certyfikatu dla roszczenia).

Wartości w polu enum
FEASIBILITY_STATUS_UNSPECIFIED Wartość zabezpieczenia reprezentująca brak stanu.
FEASIBILITY_STATUS_UNDETERMINED Solver nie zgłasza praw do stanu.
FEASIBILITY_STATUS_FEASIBLE Rozwiązanie twierdzi, że problem jest wykonalny.
FEASIBILITY_STATUS_INFEASIBLE Rozwiązanie twierdzi, że problem jest niemożliwy do zrealizowania.

ObjectiveBoundsProto

Granice przy optymalnej wartości celu.

Zapis JSON 
{
  "primalBound": number,
  "dualBound": number
}
Pola
primalBound

number

Twierdzi, że optymalna wartość jest równa lub większa (mniejsza przy zminimalizowaniu i większa w przypadku maksymalizacji) niż primalBound do pierwotnej tolerancji wykonalności (patrz ostrzeżenie poniżej): * pierwotna granica jest trudna (+inf w przypadku minimalizacji i -inf), gdy rozwiązanie nie twierdzi, że ma takie ograniczenie. * PrimalBound może być bliższa wartości optymalnej niż cel najlepszego pierwotnego rozwiązania. W szczególności wartość primalBound może być niezrozumiała nawet wtedy, gdy nie zostały zwrócone żadne pierwotne, realne rozwiązanie. Ostrzeżenie: dokładne twierdzenie jest takie, że istnieje podstawowe rozwiązanie, które: * jest możliwe z użyciem liczb (tj. możliwe do osiągnięcia tolerancji rozwiązań), a * ma obiektywną wartość „pierimalBound”. To rozwiązanie liczbowe może być trochę niewykonalne. W takim przypadku primalBound może być znacznie lepsze od wartości optymalnej. Przekształcenie pierwotnej tolerancji wykonalności na tolerancję na wartość primalBound nie jest proste, zwłaszcza gdy tolerancja wykonalności jest stosunkowo duża (np. w przypadku zastosowania PDLP).
dualBound

number

Twierdzi, że optymalna wartość jest równa lub mniejsza (większa w przypadku minimalizacji i mniejsza w przypadku maksymalizacji) niż w przypadku rozwiązania dualBound do podwójnej tolerancji wykonalności (patrz ostrzeżenie poniżej): * Podwójna granica jest trudna (-inf w przypadku minimalizacji i + maksymalizacji inf), gdy rozwiązanie nie twierdzi, że ma takie ograniczenie. Podobnie jak w przypadku primalBound ten problem może wystąpić w przypadku niektórych rozwiązań nawet wtedy, gdy zwracany jest parametr optymalny. Rozwiązania MIP zazwyczaj zgłaszają ograniczenia, nawet jeśli są nieprecyzyjne. * W przypadku ciągłych problemów funkcja DualBound może być bliższa wartości optymalnej niż cel najlepszego, ale możliwego do zrealizowania celu rozwiązania. W przypadku MIP jedna z pierwszych nieprostych wartości dla DualBound jest często optymalną wartością zrelaksowania LP MIP. * Wartość dualBound powinna być lepsza (mniejsza w przypadku minimalizacji i większa w celu maksymalizacji) niż primalBound do tolerancji rozwiązań (zobacz ostrzeżenie poniżej). Ostrzeżenie: * w przypadku ciągłych problemów dokładne twierdzenie polega na tym, że istnieje podwójne rozwiązanie, które: * jest możliwe pod względem liczbowym (czyli możliwe do osiągnięcia tolerancji rozwiązań), a * ma celową wartość dualBound. To realistyczne rozwiązanie liczbowe może być trochę niewykonalne. W takim przypadku wartość dualBound może być znacznie gorsza od wartości optymalnej i pierwotnej granicy. Podobnie jak w przypadku pierwszej sytuacji przełożenie podwójnej tolerancji wykonalności na tolerancję dla dualBound nie jest proste, zwłaszcza gdy tolerancja wykonalności jest względnie duża. Niektóre rozwiązania udostępniają jednak poprawioną wersję funkcji DualBound, która może być bezpieczniejsza liczbowo. Do tej poprawionej wersji można uzyskać dostęp za pomocą określonych danych wyjściowych rozwiązania (np. w przypadku PDLP: pdlp_output.confergence_information. corrected_dual_objective). * W przypadku rozwiązań MIP rozwiązanie dualBound może być powiązane z rozwiązaniem podwójnym zapewniającym ciągłą relaksację (np. relaksacją LP), ale często jest to złożona konsekwencja zastosowania tych rozwiązań i zwykle jest bardziej nieprecyzyjna niż granice zgłaszane przez te rozwiązania.

SolutionProto

Zastosowanie rozwiązania zależy od rodzaju problemu i sposobu jego rozwiązania. Obecnie typowe wzorce to 1. Rozwiązania MIP zwracają tylko rozwiązanie pierwotne. 2. Rozwiązania proste LPD często zwracają podstawę oraz rozwiązania podstawowe i podwójne związane z tą podstawą. 3. Inne rozwiązania ciągłe zwracają często pierwotne i podwójne rozwiązanie połączone w postaci zależnej od rozwiązania.

Wymagania: * musisz ustawić co najmniej jedno pole; rozwiązanie nie może być puste.

Zapis JSON 
{
  "primalSolution": {
    object (PrimalSolutionProto)
  },
  "dualSolution": {
    object (DualSolutionProto)
  },
  "basis": {
    object (BasisProto)
  }
}
Pola
primalSolution

object (PrimalSolutionProto)
dualSolution

object (DualSolutionProto)
basis

object (BasisProto)

PrimalSolutionProto

Rozwiązanie problemu optymalizacyjnego.

Na przykład: należy rozważyć prosty program liniowy: min. c * x s.t. A * x >= b x >= 0. Rozwiązanie podstawowe to przypisanie wartości do x. Jest to możliwe, jeśli spełnia powyższe warunki: A * x >= b oraz x >= 0. W komunikacie PrimalSolutionProto poniżej zmienna zmiennaValues to x, a celValue to c * x.

Zapis JSON 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "objectiveValue": number,
  "auxiliaryObjectiveValues": {
    string: number,
    ...
  },
  "feasibilityStatus": enum (SolutionStatusProto)
}
Pola
variableValues

object (SparseDoubleVectorProto)

Wymagania: * zmiennaValues.ids jest elementami zmiennej variablesProto.ids. * ZmienneValues.values muszą być wartościami skończonymi.
objectiveValue

number

Wartość obiektywna obliczana przez rozwiązanie źródłowe. Nie może to być wartość nieskończona ani wartość NaN.
auxiliaryObjectiveValues

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

Wartości celów dodatkowych obliczone przez rozwiązanie źródłowe. Klucze muszą być prawidłowymi identyfikatorami celów pomocniczych. Wartości nie mogą być nieskończone ani naN.

Obiekt zawierający listę par "key": value. Przykład: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
feasibilityStatus

enum (SolutionStatusProto)

Stan wykonalności rozwiązania zgodnie z jego bazowym rozwiązaniem.

DualSolutionProto

Rozwiązanie dwóch problemów optymalizacyjnych.

Na przykład: uwzględnij podstawową parę liniową w podwójnej parze podstawowej: (Primal) (Podwójna) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. Podwójnym rozwiązaniem jest para (y i r). Jest to wykonalne, jeśli spełnia ograniczenia opisane powyżej (Dual).

W poniższym komunikacie y oznacza wartość dualValues, r oznacza obniżoną cenę, a b * y jest wartością obiektywną.

Zapis JSON 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  },
  "feasibilityStatus": enum (SolutionStatusProto),
  "objectiveValue": number
}
Pola
dualValues

object (SparseDoubleVectorProto)

Wymagania: * dualValues.ids to elementy obiektu LinearConstraints.ids. * Wszystkie wartości dualValues.values muszą być skończone.
reducedCosts

object (SparseDoubleVectorProto)

Wymagania: * RedCosts.ids to elementy zmiennej VariablesProto.ids. * Zmniejszone koszty.wartości muszą być skończone.
feasibilityStatus

enum (SolutionStatusProto)

Stan wykonalności rozwiązania zgodnie z jego bazowym rozwiązaniem.
objectiveValue

number

PrimalRayProto

kierunek nieograniczonej eliminacji problemu optymalizacyjnego; a także zaświadczenie o niemożliwości realizacji 2 problemów optymalizacyjnych.

Na przykład: należy rozważyć prosty program liniowy: min. c * x s.t. A * x >= b x >= 0 Promień podstawowy to x, która spełnia następujące warunki: c * x < 0 A * x >= 0 x >= 0 Zwróć uwagę, że w przypadku praktycznych rozwiązań dowolna dodatnia wielokrotność promienia pierwotnego i tego rozwiązania jest nadal wykonalna i daje lepszą wartość obiektywną. Promień pierścienia potwierdza również niemożliwy do wykonania problem podwójnej optymalizacji.

W wiadomości PrimalRay poniżej zmienna zmiennaValues to x.

Zapis JSON 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  }
}
Pola
variableValues

object (SparseDoubleVectorProto)

Wymagania: * zmiennaValues.ids jest elementami zmiennej variablesProto.ids. * ZmienneValues.values muszą być wartościami skończonymi.

DualRayProto

kierunek nieograniczonego ulepszania podwójnej optymalizacji – problemu; a następnie zaświadczenie o pierwotnej niewykonalności.

Na przykład: uwzględnij podstawową parę liniową w podwójnej parze podstawowej: (Primal) (Podwójna) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. Promień podwójny to para (y, r) zadowalająca: b * y > 0 y * A + r = 0 y, r >= 0 Zwróć uwagę, że dodanie dodatniej wielokrotności (y, r) do podwójnego wykonalnego rozwiązania zapewnia podwójną wykonalność i poprawia cel (udowodnienie, że podwójna jest nieograniczona). Promień podwójny pokazuje również, że pierwotny problem jest niewykonalny.

W poniższym komunikacie DualRay y oznacza dualValues, a r oznacza obniżone koszty.

Zapis JSON 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  }
}
Pola
dualValues

object (SparseDoubleVectorProto)

Wymagania: * dualValues.ids to elementy obiektu LinearConstraints.ids. * Wszystkie wartości dualValues.values muszą być skończone.
reducedCosts

object (SparseDoubleVectorProto)

Wymagania: * RedCosts.ids to elementy zmiennej VariablesProto.ids. * Zmniejszone koszty.wartości muszą być skończone.

SolveStatsProto

Zapis JSON 
{
  "solveTime": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "simplexIterations": string,
  "barrierIterations": string,
  "firstOrderIterations": string,
  "nodeCount": string
}
Pola
solveTime

string (Duration format)

Upłynęło: czas zegara ściennego mierzony za pomocą parametru math_opt, przybliżony czas w funkcji Solver::Solve(). Uwaga: nie dotyczy to pracy wykonanej przy tworzeniu modelu.

Czas trwania w sekundach składający się z maksymalnie 9 cyfr po przecinku, kończący się cyfrą „s”. Przykład: "3.5s".
problemStatus

object (ProblemStatusProto)

Stany wykonalności problemów podstawowych i podwójnych.
simplexIterations

string (int64 format)
barrierIterations

string (int64 format)
firstOrderIterations

string (int64 format)
nodeCount

string (int64 format)