Method: mathopt.solveMathOptModel

Resolve o modelo de entrada e retorna o resultado de uma vez. Use quando não precisar de callbacks, incrementabilidade e não precisar acompanhar o progresso de uma solução.

Solicitação HTTP

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

O URL usa a sintaxe de transcodificação gRPC.

Corpo da solicitação

O corpo da solicitação contém dados com a seguinte estrutura:

Representação JSON 
{
  "solverType": enum (SolverTypeProto),
  "model": {
    object (ModelProto)
  },
  "parameters": {
    object (SolveParametersProto)
  },
  "modelParameters": {
    object (ModelSolveParametersProto)
  }
}
Campos
solverType

enum (SolverTypeProto)

Opcional. Tipo de solucionador para resolver numericamente o problema. Se um solucionador não oferecer suporte a um recurso específico no modelo, o procedimento de otimização não vai funcionar.
model

object (ModelProto)

Obrigatório. Uma representação matemática do problema de otimização a ser resolvido.
parameters

object (SolveParametersProto)

Opcional. Parâmetros para controlar uma única solução. O parâmetro enableOutput é tratado especificamente. Para solucionadores compatíveis com callbacks de mensagens, defini-lo como "true" fará com que o servidor registre um callback de mensagem. As mensagens resultantes serão retornadas em SolveMathOptModelResponse.messages. Para outros solucionadores, definir enableOutput como verdadeiro vai resultar em um erro.
modelParameters

object (ModelSolveParametersProto)

Opcional. Parâmetros para controlar uma solução única específica do modelo de entrada. Consulte SolveParametersProto para ver os parâmetros independentes do modelo.

Corpo da resposta

Resposta para uma solução remota unária em MathOpt.

Se bem-sucedido, o corpo da resposta incluirá dados com a estrutura a seguir:

Representação JSON 
{
  "result": {
    object (SolveResultProto)
  },
  "messages": [
    string
  ]
}
Campos
result

object (SolveResultProto)

Descrição da saída da resolução do modelo na solicitação.
messages[]

string

Se SolveParametersProto.enable_output foi usado, ele conterá mensagens de registro para solucionadores compatíveis com callbacks de mensagens.

SolverTypeProto

Os solucionadores com suporte de MathOpt.

Enums
SOLVER_TYPE_UNSPECIFIED
SOLVER_TYPE_GSCIP

Resolver o solucionador de programas de números inteiros de restrição (SCIP, na sigla em inglês) (terceiros).

Oferece suporte a problemas quadráticos de números inteiros não convexos com LP, MIP e números inteiros não convexos. No entanto, nenhum dado duplo para LPs é retornado. Prefira GLOP para LPs.
SOLVER_TYPE_GUROBI

Solucionador Gurobi (terceiros).

Oferece suporte a problemas quadráticos de números inteiros não convexos com LP, MIP e números inteiros não convexos. Geralmente a opção mais rápida, mas com licenciamento especial.
SOLVER_TYPE_GLOP

o solucionador Glop do Google.

Dá suporte ao LP com métodos primários e duplos simplex.
SOLVER_TYPE_CP_SAT

o solucionador CP-SAT do Google.

Compatível com problemas em que todas as variáveis são inteiras e limitadas (ou implícitas após a resolução). Suporte experimental para redimensionar e discretizar problemas com variáveis contínuas.
SOLVER_TYPE_PDLP

Solucionador de PDLP do Google.

Compatível com objetivos quadráticos diagonais de LP e convexos. Usa métodos de primeira ordem em vez de simplex. Pode resolver problemas muito grandes.
SOLVER_TYPE_GLPK

GNU Linear Programming Kit (GLPK) (terceiros).

Dá suporte a MIP e LP.

Segurança de encadeamento: o GLPK usa armazenamento local de encadeamento para alocações de memória. Como consequência, as instâncias do solucionador devem ser destruídas no mesmo thread em que são criadas, ou o GLPK falhará. Não há problema em chamar Solver::Solve() de outra linha de execução diferente daquela usada para criar o Solver, mas isso não é documentado pelo GLPK e deve ser evitado.

Ao resolver um LP com o presolver, uma solução (e os raios não vinculados) só são retornadas se uma solução ideal tiver sido encontrada. Caso contrário, nada será retornado. Consulte a página glpk-5.0/doc/glpk.pdf 40 disponível em glpk-5.0.tar.gz para obter detalhes.
SOLVER_TYPE_OSQP

O solucionador de operadores de divisão do programa quadrático (OSQP, na sigla em inglês) (terceiros).

Suporta problemas contínuos com restrições lineares e objetivos quadráticos lineares ou convexos. Usa um método de primeira ordem.
SOLVER_TYPE_ECOS

O solucionador cônico incorporado (ECOS, na sigla em inglês).

Suporta problemas de LP e SOCP. Usa métodos de ponto interno (barreira).
SOLVER_TYPE_SCS

O Solucionador de Cônicas de Divisão (SCS) (terceiros).

Suporta problemas de LP e SOCP. Usa um método de primeira ordem.
SOLVER_TYPE_HIGHS

O Solucionador de HiGHS (terceiros).

Suporta problemas de LP e MIP (os QPs convexos não são implementados).
SOLVER_TYPE_SANTORINI

Implementação de referência de MathOpt de um solucionador MIP.

Lento/não recomendado para produção. Não é um solucionador LP (nenhuma informação dupla é retornada).

ModelProto

Um problema de otimização. MathOpt suporta: - Variáveis de decisão contínuas e inteiras com limites finitos opcionais. - Objetivos lineares e quadráticos (objetivos únicos ou múltiplos), minimizados ou maximizados. - Vários tipos de restrições, incluindo: * Restrições lineares * Restrições quadráticas * Restrições de cone de segunda ordem * Restrições lógicas > Restrições de SOS1 e SOS2 > Restrições do indicador

Por padrão, as restrições são representadas em mapas "id-to-data". No entanto, representamos as restrições lineares em um formato de “struct-of-arrays” mais eficiente.

Representação 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)
    },
    ...
  }
}
Campos
name

string
variables

object (VariablesProto)
objective

object (ObjectiveProto)

O objetivo principal do modelo.
auxiliaryObjectives

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

Objetivos auxiliares para uso em modelos multiobjetivos.

Os IDs de chave do mapa precisam estar no intervalo [0, max(int64)). Cada prioridade e cada nome não vazio precisam ser únicos e também diferentes do objective principal.

Um objeto com uma lista de pares "key": value. Exemplo: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
linearConstraints

object (LinearConstraintsProto)
linearConstraintMatrix

object (SparseDoubleMatrixProto)

Os coeficientes variáveis das restrições lineares.

Se uma variável envolvida nessa restrição for excluída, ela será tratada como se estivesse definida como zero.

Requisitos: * linearConstraintMatrix.row_ids são elementos de linearConstraints.ids. * linearConstraintMatrix.column_ids são elementos de variables.ids. * As entradas de matriz não especificadas são zero. * linearConstraintMatrix.values precisam ser finitos.
quadraticConstraints

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

Restrições quadráticas no modelo.

Um objeto com uma lista de pares "key": value. Exemplo: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
secondOrderConeConstraints

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

Restrições de cone de segunda ordem no modelo.

Um objeto com uma lista de pares "key": value. Exemplo: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
sos1Constraints

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

As restrições SOS1 no modelo restringem o máximo de um expression ser diferente de zero. As entradas weights opcionais são um detalhe de implementação usado pelo solucionador para convergir mais rapidamente. Em mais detalhes, os solucionadores podem (ou não) usar esses pesos para selecionar decisões de ramificação que produzem nós filhos "equilibrados".

Um objeto com uma lista de pares "key": value. Exemplo: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
sos2Constraints

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

Restrições SOS2 no modelo, que restringem que no máximo duas entradas de expression podem ser diferentes de zero, e elas precisam ser adjacentes na ordem. Se nenhum weights for fornecido, essa ordem será a ordem linear na lista de expressions. Se weights forem apresentados, a ordem será considerada em relação a esses valores em ordem crescente.

Um objeto com uma lista de pares "key": value. Exemplo: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
indicatorConstraints

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

Restrições de indicador no modelo, que impõem que, se uma "variável indicadora" binária for definida como um, então uma "restrição implícita" precisa ser mantida.

Um objeto com uma lista de pares "key": value. Exemplo: { "name": "wrench", "mass": "1.3kg", "count": "3" }.

VariablesProto

Conforme usado abaixo, definimos "#variables" = size(VariablesProto.ids).

Representação JSON 
{
  "ids": [
    string
  ],
  "lowerBounds": [
    number
  ],
  "upperBounds": [
    number
  ],
  "integers": [
    boolean
  ],
  "names": [
    string
  ]
}
Campos
ids[]

string (int64 format)

Precisa ser não negativo e estritamente crescente. Não é possível usar o valor max(int64).
lowerBounds[]

number

Deve ter comprimento igual a #variables, valores em [-inf, inf).
upperBounds[]

number

Deve ter comprimento igual a #variables, valores em (-inf, inf].
integers[]

boolean

Deve ter comprimento igual a #variables. O valor é falso para variáveis contínuas e verdadeiro para variáveis de números inteiros.
names[]

string

Se não for definido, serão consideradas todas as strings vazias. Caso contrário, ele deve ter comprimento igual a #variables.

Todos os nomes não vazios precisam ser distintos.

ObjectiveProto

Representação JSON 
{
  "maximize": boolean,
  "offset": number,
  "linearCoefficients": {
    object (SparseDoubleVectorProto)
  },
  "quadraticCoefficients": {
    object (SparseDoubleMatrixProto)
  },
  "name": string,
  "priority": string
}
Campos
maximize

boolean

falso é minimizar, verdadeiro é maximizar
offset

number

Precisa ser finito e não NaN.
linearCoefficients

object (SparseDoubleVectorProto)

Termos de ObjectiveProto que são lineares nas variáveis de decisão.

Requisitos: * linearCoefficients.ids são elementos de VariablesProto.ids. * VariablesProto não especificado corresponde a zero. * linearCoeficientes.values precisam ser finitos. * linearCoeficientes.values pode ser zero, mas isso só desperdiça espaço.
quadraticCoefficients

object (SparseDoubleMatrixProto)

Termos objetivos que são quadráticos nas variáveis de decisão.

Requisitos, além daqueles nas mensagens SparseDoubleMatrixProto: * Cada elemento de quadraticCoefficients.row_ids e cada elemento de quadraticCoefficients.column_ids precisam ser um elemento de VariablesProto.ids. * A matriz deve ser triangular superior: para cada i, quadraticCoefficients.row_ids[i] <= quadraticCoefficients.column_ids[i].

Observações: * Termos que não são armazenados explicitamente têm coeficiente zero. * Os elementos de quadraticCoeficientes.coeficientes podem ser zero, mas isso só desperdiça espaço.
name

string

As mensagens principais podem ter requisitos de exclusividade neste campo. Por exemplo, consulte ModelProto.objectives e AuxiliaryObjectivesUpdatesProto.new_objectives.
priority

string (int64 format)

Para problemas com vários objetivos, a prioridade desse objetivo em relação aos outros (menor é mais importante). Esse valor não pode ser negativo. Além disso, cada prioridade objetiva do modelo precisa ser distinta no momento da resolução. Essa condição não é validada no nível proto, então os modelos podem ter objetivos temporariamente com a mesma prioridade.

SparseDoubleVectorProto

Uma representação esparsa de um vetor de duplos.

Representação JSON 
{
  "ids": [
    string
  ],
  "values": [
    number
  ]
}
Campos
ids[]

string (int64 format)

Precisam ser classificados (em ordem crescente) com todos os elementos distintos.
values[]

number

Precisa ter o mesmo comprimento que os IDs. Pode não conter NaN.

SparseDoubleMatrixProto

Uma representação esparsa de uma matriz de duplos.

A matriz é armazenada como triplos de ID de linha, ID de coluna e coeficiente. Esses três vetores devem ter o mesmo comprimento. Para todos i, a tupla (rowIds[i], columnIds[i]) deve ser distinta. As entradas precisam estar na ordem maior na linha.

Representação JSON 
{
  "rowIds": [
    string
  ],
  "columnIds": [
    string
  ],
  "coefficients": [
    number
  ]
}
Campos
rowIds[]

string (int64 format)
columnIds[]

string (int64 format)
coefficients[]

number

Pode não conter NaN.

LinearConstraintsProto

Conforme usado abaixo, definimos "#linear constraints" = size(LinearConstraintsProto.ids).

Representação JSON 
{
  "ids": [
    string
  ],
  "lowerBounds": [
    number
  ],
  "upperBounds": [
    number
  ],
  "names": [
    string
  ]
}
Campos
ids[]

string (int64 format)

Precisa ser não negativo e estritamente crescente. Não é possível usar o valor max(int64).
lowerBounds[]

number

Deve ter comprimento igual a #linear restrições, valores em [-inf, inf).
upperBounds[]

number

Deve ter comprimento igual a #linear restrições, valores em (-inf, inf].
names[]

string

Se não for definido, serão consideradas todas as strings vazias. Caso contrário, deve ter comprimento igual a #linear restrições.

Todos os nomes não vazios precisam ser distintos.

QuadraticConstraintProto

Uma única restrição quadrática da forma: lb <= sum{linearTerms} + soma{quadraticTerms} <= ub.

Se uma variável envolvida nessa restrição for excluída, ela será tratada como se estivesse definida como zero.

Representação JSON 
{
  "linearTerms": {
    object (SparseDoubleVectorProto)
  },
  "quadraticTerms": {
    object (SparseDoubleMatrixProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string
}
Campos
linearTerms

object (SparseDoubleVectorProto)

Termos que são lineares nas variáveis de decisão.

Além dos requisitos para mensagens SparseDoubleVectorProto, exigimos que: * linearTerms.ids são elementos de VariablesProto.ids. * linearTerms.values precisa ser finito e não-NaN.

Observações: * Os IDs de variáveis omitidos têm um coeficiente correspondente de zero. * linearTerms.values pode ser zero, mas isso apenas desperdiça espaço.
quadraticTerms

object (SparseDoubleMatrixProto)

Termos quadráticos nas variáveis de decisão.

Além dos requisitos para mensagens de SparseDoubleMatrixProto, solicitamos que: * Cada elemento de quadraticTerms.row_ids e cada elemento de quadraticTerms.column_ids deve ser um elemento de VariablesProto.ids. * A matriz precisa ser triangular superior: para cada i, quadraticTerms.row_ids[i] <= quadraticTerms.column_ids[i].

Observações: * Termos que não são armazenados explicitamente têm coeficiente zero. * Elementos de quadraticTerms.coeficientes podem ser zero, mas isso só desperdiça espaço.
lowerBound

number

Precisa ter um valor em [-inf, inf) e ser menor ou igual a upperBound.
upperBound

number

Precisa ter um valor em (-inf, inf] e ser maior ou igual a lowerBound.
name

string

As mensagens principais podem ter requisitos de exclusividade neste campo. Por exemplo, consulte ModelProto.quadratic_constraints e QuadraticConstraintUpdatesProto.new_constraints.

SecondOrderConeConstraintProto

Uma única restrição de cone de segunda ordem do formulário:

||argumentsToNorm||_2 <= upperBound,

em que upperBound e cada elemento de argumentsToNorm são expressões lineares.

Se uma variável envolvida nessa restrição for excluída, ela será tratada como se estivesse definida como zero.

Representação JSON 
{
  "upperBound": {
    object (LinearExpressionProto)
  },
  "argumentsToNorm": [
    {
      object (LinearExpressionProto)
    }
  ],
  "name": string
}
Campos
upperBound

object (LinearExpressionProto)
argumentsToNorm[]

object (LinearExpressionProto)
name

string

As mensagens principais podem ter requisitos de exclusividade neste campo. Por exemplo, consulte ModelProto.second_order_cone_constraints e SecondOrderConeConstraintUpdatesProto.new_constraints.

LinearExpressionProto

Uma representação esparsa de uma expressão linear (uma soma ponderada de variáveis, mais um deslocamento constante).

Representação JSON 
{
  "ids": [
    string
  ],
  "coefficients": [
    number
  ],
  "offset": number
}
Campos
ids[]

string (int64 format)

IDs de variáveis. Precisam ser classificados (em ordem crescente) com todos os elementos distintos.
coefficients[]

number

Precisa ter o mesmo comprimento que os IDs. Os valores precisam ser finitos e podem não ser NaN.
offset

number

Precisa ser finito e pode não ser NaN.

SosConstraintProto

Dados para representar uma única restrição de SOS1 ou SOS2.

Se uma variável envolvida nessa restrição for excluída, ela será tratada como se estivesse definida como zero.

Representação JSON 
{
  "expressions": [
    {
      object (LinearExpressionProto)
    }
  ],
  "weights": [
    number
  ],
  "name": string
}
Campos
expressions[]

object (LinearExpressionProto)

As expressões sobre as quais aplicar a restrição SOS: * SOS1: no máximo, um elemento assume um valor diferente de zero. * SOS2: no máximo, dois elementos recebem valores diferentes de zero e precisam ser adjacentes na ordem repetida.
weights[]

number

Vazio ou de igual comprimento às expressões. Se estiver vazio, as ponderações padrão serão 1, 2, ... Se estiver presente, as entradas devem ser exclusivas.
name

string

As mensagens mãe podem ter requisitos de exclusividade neste campo. Por exemplo, consulte ModelProto.sos1_constraints e SosConstraintUpdatesProto.new_constraints.

IndicatorConstraintProto

Dados para representar uma restrição de indicador único no formato: Variable(indicatorId) = (activateOnZero ? 0 : 1) ⇒ lowerBound <= expressão <= aboveBound.

Se uma variável envolvida nessa restrição (o indicador ou que aparece em expression) for excluída, ela será tratada como se estivesse definida como zero. Mais especificamente, a exclusão da variável de indicador significa que a restrição do indicador será vazia se activateOnZero for falsa, e que será equivalente a uma restrição linear se activateOnZero for verdadeiro.

Representação JSON 
{
  "activateOnZero": boolean,
  "expression": {
    object (SparseDoubleVectorProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string,
  "indicatorId": string
}
Campos
activateOnZero

boolean

Se verdadeira, se a variável do indicador receber o valor 0, a restrição implícita deverá ser mantida. Caso contrário, se a variável do indicador receber o valor 1, a restrição implícita deverá ser mantida.
expression

object (SparseDoubleVectorProto)

Precisa ser uma expressão linear válida em relação ao modelo que o contém: * Todas as condições declaradas em SparseDoubleVectorProto, * Todos os elementos de expression.values precisam ser finitos, * expression.ids são um subconjunto de VariablesProto.ids.
lowerBound

number

Precisa ter um valor em [-inf, inf); não pode ser NaN.
upperBound

number

Precisa ter um valor em (-inf, inf]; não pode ser NaN.
name

string

As mensagens principais podem ter requisitos de exclusividade neste campo. Por exemplo, consulte ModelProto.indicator_constraints e IndicatorConstraintUpdatesProto.new_constraints.
indicatorId

string (int64 format)

Um ID correspondente a uma variável binária ou não definido. Se não for definida, a restrição do indicador será ignorada. Se definido, será necessário que: * VariablesProto.integers[indicatorId] = true, * VariablesProto.lower_bounds[indicatorId] >= 0, * VariablesProto.upper_bounds[indicatorId] <= 1. Essas condições não são validadas pelo MathOpt, mas, se não forem satisfeitas, o solucionador retornará um erro ao resolver.

SolveParametersProto

Parâmetros para controlar uma única solução.

Contém os parâmetros comuns a todos os solucionadores (por exemplo, timeLimit) e parâmetros para um solucionador específico (por exemplo, gscip). Se um valor for definido no campo comum e específico do solucionador, a configuração específica do solucionador será usada.

Os parâmetros comuns que são opcionais e não definidos ou um tipo enumerado com valor não especificado indicam que o padrão do solucionador é usado.

Os parâmetros específicos do solucionador para solucionadores diferentes do que está em uso são ignorados.

Os parâmetros que dependem do modelo (por exemplo, a prioridade de ramificação é definida para cada variável) são transmitidos em ModelSolveParametersProto.

Representação 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
}
Campos
timeLimit

string (Duration format)

O tempo máximo que um solucionador deve gastar no problema (ou infinito, se não for definido).

Este valor não é um limite fixo. O tempo de solução pode exceder um pouco esse valor. Esse parâmetro sempre é transmitido para o solucionador. O padrão do solucionador não é usado.

Uma duração em segundos com até nove dígitos fracionários, terminando em "s". Exemplo: "3.5s".
enableOutput

boolean

Ativa a impressão dos rastros de implementação do solucionador. A localização desses traces depende do solucionador. Para SCIP e Gurobi, esses serão os fluxos de saída padrão. Para Glop e CP-SAT, LOG(INFO).

Se o solucionador oferecer suporte ao callback de mensagem e o usuário registrar um callback para ela, esse valor de parâmetro será ignorado e nenhum rastro será exibido.
lpAlgorithm

enum (LPAlgorithmProto)

O algoritmo para resolver um programa linear. Se LP_ALGORITHM_UNSPECIFIED, use o algoritmo padrão do solucionador.

Para problemas que não são programas lineares, mas em que a programação linear é uma sub-rotina, os solucionadores podem usar esse valor. Por exemplo, os solucionadores de MIP normalmente o usam apenas para a solução de LP raiz (senão, o simplex duplo será usado).
presolve

enum (EmphasisProto)

Esforça-se para simplificar o problema antes de iniciar o algoritmo principal ou o nível de esforço padrão do solucionador, se FALSE_UNSPECIFIED.
cuts

enum (EmphasisProto)

Esforço para obter um relaxamento de LP mais forte (somente MIP) ou o nível de esforço padrão do solucionador se FALSE_UNSPECIFIED.

OBSERVAÇÃO: desativar cortes pode impedir que os callbacks tenham a chance de adicionar cortes em MIP_NODE. Esse comportamento é específico do solucionador.
heuristics

enum (EmphasisProto)

Esforço para encontrar soluções viáveis além das encontradas no procedimento de pesquisa completo (somente MIP) ou no nível de esforço padrão do solucionador se FALSE_UNSPECIFIED.
scaling

enum (EmphasisProto)

Esforço para redimensionar o problema a fim de melhorar a estabilidade numérica ou o nível de esforço padrão do solucionador se FALSE_UNSPECIFIED.
iterationLimit

string (int64 format)

Limite nas iterações do algoritmo subjacente (por exemplo, tabelas dinâmicas simples). O comportamento específico depende do solucionador e do algoritmo usado, mas muitas vezes pode fornecer um limite de solução determinístico (pode ser necessária uma configuração adicional, por exemplo, uma linha de execução).

Geralmente suportado por solucionadores de LP, QP e MIP, mas para solucionadores MIP consulte também nodeLimit.
nodeLimit

string (int64 format)

Limite no número de subproblemas resolvidos na pesquisa enumerada (por exemplo, ramificação e limite). Para muitos solucionadores, isso pode ser usado para limitar de maneira determinista a computação (pode ser necessária uma configuração adicional, por exemplo, uma linha de execução).

Normalmente, para solucionadores de MIP, consulte também iterationLimit.
cutoffLimit

number

O solucionador interrompe antecipadamente se consegue provar que não há soluções primárias pelo menos tão boas quanto o corte.

Em uma parada antecipada, o solucionador retorna o motivo da rescisão NO_SOLUTION_FOUND e tem o limite de CUTOFF e não precisa fornecer informações adicionais sobre a solução. Não tem efeito sobre o valor de retorno se não houver parada antecipada.

Recomenda-se usar uma tolerância se você quiser que soluções com objetivo exatamente igual ao limite sejam retornadas.

Consulte o guia do usuário para mais detalhes e uma comparação com bestBoundLimit.
objectiveLimit

number

O solucionador interrompe o processo assim que encontra uma solução pelo menos tão boa, com motivo de encerramento FÁCIL e limite OBJETIVO.
bestBoundLimit

number

O solucionador interrompe o processo assim que consegue comprovar que o melhor limite é pelo menos tão bom, com o motivo da rescisão FEASIBLE ou NO_SOLUTION_FOUND e limite OBJETIVO.

Para mais detalhes e uma comparação com o cutoffLimit, consulte o guia do usuário.
solutionLimit

integer

O solucionador interrompe logo após encontrar essas muitas soluções viáveis, com o motivo da rescisão FÁCIL e limitar a SOLUÇÃO. Precisa ser maior do que zero se definido. Em geral, esse método é usado para que o solucionador pare na primeira solução viável encontrada. Não há garantia sobre o valor objetivo de nenhuma das soluções retornadas.

Os solucionadores não costumam retornar mais soluções do que o limite da solução, mas isso não é aplicado pelo MathOpt. Consulte também b/214041169.

No momento, compatível com Gurobi e SCIP e apenas para CP-SAT com valor 1.
threads

integer

Se definido, precisa ser >= 1.
randomSeed

integer

Semente para o gerador de números pseudoaleatórios no solucionador. Todos os solucionadores usam números pseudoaleatórios para selecionar itens como perturbação no algoritmo LP, regras de tie-break e correções heurísticas. Fazer isso pode ter um impacto perceptível no comportamento do solucionador.

Embora todos os solucionadores tenham um conceito de sementes, os valores válidos dependem do solucionador real. - Gurobi: [0:GRB_MAXINT] (na versão Gurobi 9.0 é 2x10^9). – GSCIP: [0:2147483647] (que é MAX_INT, kint32max ou 2^31-1). - GLOP: [0:2147483647] (o mesmo que acima). Em todos os casos, o solucionador receberá um valor igual a: MAX(0, MIN(MAX_VALID_VALUE_FOR_SOLVER, randomSeed)).
absoluteGapTolerance

number

Uma tolerância de otimização absoluta (principalmente) para solucionadores de MIP.

O GAP absoluto é o valor absoluto da diferença entre: * o valor objetivo da melhor solução viável encontrada, * o limite duplo produzido pela pesquisa. O solucionador poderá parar assim que a GAP absoluta atingir o valor máximo de GapTolerance (quando definido) e retornar TERMINATION_REASON_OPTIMAL.

Precisa ser >= 0, se definido.

Consulte também relativeGapTolerance.
relativeGapTolerance

number

Uma tolerância de otimização relativa (principalmente) para solucionadores de MIP.

O GAP relativo é uma versão normalizada do GAP absoluto (definido emAbsoluteGapTolerance), em que a normalização depende do solucionador, por exemplo, o GAP absoluto dividido pelo valor objetivo da solução mais viável encontrada.

O solucionador poderá parar quando o GAP relativo estiver no máximo relativo GapTolerance (quando definido) e retornar TERMINATION_REASON_OPTIMAL.

Precisa ser >= 0, se definido.

Consulte tambémAbsoluteGapTolerance.
solutionPoolSize

integer

Mantenha até solutionPoolSize soluções durante a pesquisa. O pool de soluções geralmente tem duas funções: (1) para solucionadores que podem retornar mais de uma solução, isso limita quantas soluções serão retornadas. (2) Alguns solucionadores podem executar heurísticas usando soluções do conjunto. Por isso, alterar esse valor pode afetar o caminho do algoritmo. Forçar o solucionador a preencher o conjunto de soluções, por exemplo, com as "n melhores soluções", exige mais configuração específica do solucionador.

LPAlgorithmProto

Seleciona um algoritmo para resolver programas lineares.

Enums
LP_ALGORITHM_UNSPECIFIED
LP_ALGORITHM_PRIMAL_SIMPLEX O método simplex (primal). Normalmente, pode fornecer soluções primárias e duplas, raios primais/duais em problemas ilimitados primais/duais e uma base.
LP_ALGORITHM_DUAL_SIMPLEX O método simplex duplo. Normalmente, pode fornecer soluções primárias e duplas, raios primais/duais em problemas ilimitados primais/duais e uma base.
LP_ALGORITHM_BARRIER O método de barreira, também comumente chamado de método de ponto interno (IPM, na sigla em inglês). Normalmente, podem oferecer soluções primárias e duplas. Algumas implementações também podem produzir raios em problemas ilimitados/inviáveis. Uma base não é fornecida, a menos que o solucionador subjacente faça "crossover" e termine com simplex.
LP_ALGORITHM_FIRST_ORDER Um algoritmo baseado em um método de primeira ordem. Eles normalmente produzirão soluções primárias e duplas e, potencialmente, também certificados de inviabilidade primária e/ou dupla. Os métodos de primeira ordem normalmente fornecem soluções com menor acurácia, portanto, os usuários devem tomar cuidado ao definir os parâmetros de qualidade da solução (por exemplo, tolerâncias) e validar as soluções.

EmphasisProto

Nível de esforço aplicado a uma tarefa opcional durante a resolução (consulte SolveParametersProto para uso).

A ênfase é usada para configurar um recurso do solucionador da seguinte forma: * Se um solucionador não oferecer suporte ao recurso, somente UNSPECIFIED será sempre válido, qualquer outra configuração normalmente será um erro de argumento inválido (alguns solucionadores também podem aceitar OFF). * Se o solucionador oferecer suporte ao recurso: - Quando definido como UNSPECIFIED, o padrão subjacente será usado. - Quando o recurso não puder ser desativado, OFF retornará um erro. - Se o recurso estiver ativado por padrão, o padrão do solucionador será mapeado para MEDIUM. - Se o recurso for suportado, BAIXO, MÉDIO, ALTO e MUITO ALTO nunca darão um erro e serão mapeadas na melhor correspondência.

Enums
EMPHASIS_UNSPECIFIED
EMPHASIS_OFF
EMPHASIS_LOW
EMPHASIS_MEDIUM
EMPHASIS_HIGH
EMPHASIS_VERY_HIGH

ModelSolveParametersProto

Representação JSON 
{
  "variableValuesFilter": {
    object (SparseVectorFilterProto)
  },
  "dualValuesFilter": {
    object (SparseVectorFilterProto)
  },
  "reducedCostsFilter": {
    object (SparseVectorFilterProto)
  },
  "initialBasis": {
    object (BasisProto)
  },
  "solutionHints": [
    {
      object (SolutionHintProto)
    }
  ],
  "branchingPriorities": {
    object (SparseInt32VectorProto)
  }
}
Campos
variableValuesFilter

object (SparseVectorFilterProto)

Filtro aplicado a todos os contêineres esparsos retornados codificados por variáveis em PrimalSolutionProto e PrimalRayProto (PrimalSolutionProto.variable_values, PrimalRayProto.variable_values).

Requisitos: * filterIds são elementos de VariablesProto.ids.
dualValuesFilter

object (SparseVectorFilterProto)

Filtro aplicado a todos os contêineres esparsos retornados codificados por restrições lineares em DualSolutionProto e DualRay (DualSolutionProto.dual_values, DualRay.dual_values).

Requisitos: * filterIds são elementos de LinearConstraints.ids.
reducedCostsFilter

object (SparseVectorFilterProto)

Filtro aplicado a todos os contêineres esparsos retornados codificados por variáveis em DualSolutionProto e DualRay (DualSolutionProto.reduced_costs, DualRay.reduced_costs).

Requisitos: * filterIds são elementos de VariablesProto.ids.
initialBasis

object (BasisProto)

Base inicial opcional para solucionadores de LP simplex de inicialização a quente. Se definido, espera-se que ele seja válido de acordo com ValidateBasis em validators/solution_validator.h para o ModelSummary atual.
solutionHints[]

object (SolutionHintProto)

Dicas de solução opcionais. Se o solucionador aceitar apenas uma dica, a primeira será usada.
branchingPriorities

object (SparseInt32VectorProto)

Prioridades de ramificação opcionais. As variáveis com valores mais altos serão ramificadas primeiro. As variáveis com prioridades não definidas recebem a prioridade padrão do solucionador (geralmente zero).

Requisitos: * branchingPriorities.values deve ser finito. * branchingPriorities.ids precisa ser elementos de VariablesProto.ids.

SparseVectorFilterProto

Essa mensagem permite consultar/definir partes específicas de um SparseXxxxVector. O comportamento padrão é não filtrar nada. Um uso comum é consultar apenas partes de soluções (apenas valores diferentes de zero e/ou apenas um conjunto de valores de variáveis escolhidos manualmente).

Representação JSON 
{
  "skipZeroValues": boolean,
  "filterByIds": boolean,
  "filteredIds": [
    string
  ]
}
Campos
skipZeroValues

boolean

Para SparseBoolVectorProto, "zero" é false.
filterByIds

boolean

Quando verdadeiro, retorna apenas os valores correspondentes aos IDs listados em filterIds.
filteredIds[]

string (int64 format)

A lista de IDs a serem usados quando filterByIds for verdadeiro. Precisa estar em branco quando filterByIds for definido como falso. OBSERVAÇÃO: se estiver vazio e filterByIds for verdadeiro, você estará dizendo que não quer nenhuma informação no resultado.

BasisProto

Uma caracterização combinatória para uma solução de um programa linear.

O método simplex para resolver programas lineares sempre retorna uma “solução básica viável” que pode ser descrita de forma combinatória por uma base. Uma base atribui um BasisStatusProto para cada variável e restrição linear.

Por exemplo, considere uma forma padrão LP: min c * x s.t. A * x = b x >= 0 que tenha mais variáveis do que restrições e com classificação de linha completa A.

Permita que n seja o número de variáveis e m o número de restrições lineares. Uma base válida para esse problema pode ser construída da seguinte maneira: * Todas as restrições terão o status de base FIXED. * Escolha m variáveis de modo que as colunas de A sejam linearmente independentes e atribuam o status BASIC. * Atribua o status AT_LOWER para as variáveis n - m restantes.

A solução básica para essa base é a solução exclusiva de A * x = b que tem todas as variáveis com status AT_LOWER fixo em seus limites inferiores (todas zero). A solução resultante é chamada de solução básica viável se também atende a x >= 0.

Representação JSON 
{
  "constraintStatus": {
    object (SparseBasisStatusVector)
  },
  "variableStatus": {
    object (SparseBasisStatusVector)
  },
  "basicDualFeasibility": enum (SolutionStatusProto)
}
Campos
constraintStatus

object (SparseBasisStatusVector)

Status da base de restrição.

Requisitos: * restrictedStatus.ids é igual a LinearConstraints.ids.
variableStatus

object (SparseBasisStatusVector)

Status de base variável.

Requisitos: * restrictedStatus.ids é igual a VariablesProto.ids.
basicDualFeasibility

enum (SolutionStatusProto)

Esse é um recurso avançado usado pelo MathOpt para caracterizar a viabilidade de soluções de LP abaixo do ideal (as soluções ideais sempre terão o status SOLUTION_STATUS_FEASIBLE).

Para páginas de destino unilateral, deve ser igual ao status de viabilidade da solução dupla associada. Para LPs bilateral, pode ser diferente em alguns casos extremos (por exemplo, soluções incompletas com simplex primária).

Se você estiver fornecendo uma base inicial por ModelSolveParametersProto.initial_basis, esse valor será ignorado. Ele é relevante apenas para a base retornada por SolutionProto.basis.

SparseBasisStatusVector

Uma representação esparsa de um vetor de status básicos.

Representação JSON 
{
  "ids": [
    string
  ],
  "values": [
    enum (BasisStatusProto)
  ]
}
Campos
ids[]

string (int64 format)

Precisam ser classificados (em ordem crescente) com todos os elementos distintos.
values[]

enum (BasisStatusProto)

Precisa ter o mesmo comprimento que os IDs.

BasisStatusProto

Status de uma variável/restrição na página de destino.

Enums
BASIS_STATUS_UNSPECIFIED Valor de guarda que não representa status.
BASIS_STATUS_FREE A variável/restrição é sem custo financeiro (não tem limites finitos).
BASIS_STATUS_AT_LOWER_BOUND A variável/restrição está no limite inferior (que precisa ser finito).
BASIS_STATUS_AT_UPPER_BOUND A variável/restrição está no limite superior (que precisa ser finito).
BASIS_STATUS_FIXED_VALUE A variável/restrição tem limites inferiores e superiores finitos idênticos.
BASIS_STATUS_BASIC A variável/restrição é básica.

SolutionStatusProto

Viabilidade de uma solução primal ou dupla, conforme declarado pelo solucionador.

Enums
SOLUTION_STATUS_UNSPECIFIED Valor de guarda que não representa status.
SOLUTION_STATUS_UNDETERMINED O solucionador não declara um status de viabilidade.
SOLUTION_STATUS_FEASIBLE O solucionador afirma que a solução é viável.
SOLUTION_STATUS_INFEASIBLE O solucionador afirma que a solução é inviável.

SolutionHintProto

Uma sugestão de solução inicial para o solucionador.

Os solucionadores de MIP geralmente querem apenas informações primárias (variableValues), enquanto os solucionadores de LP querem informações primárias e duplas (dualValues).

Muitos solucionadores de MIP podem trabalhar com: (1) soluções parciais que não especificam todas as variáveis ou (2) soluções inviáveis. Nesses casos, os solucionadores normalmente resolvem um sub-MIP para concluir/corrigir a dica.

A forma como a dica é usada pelo solucionador depende muito do solucionador, do tipo de problema e do algoritmo usado. A maneira mais confiável de garantir que sua dica tenha efeito é ler os registros dos solucionadores subjacentes com e sem a dica.

Os solucionadores de LP baseados em simplex normalmente preferem uma base inicial a uma dica de solução. Caso contrário, eles precisam fazer um crossover para converter a dica em uma solução básica viável.

Representação JSON 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "dualValues": {
    object (SparseDoubleVectorProto)
  }
}
Campos
variableValues

object (SparseDoubleVectorProto)

Uma atribuição possivelmente parcial de valores para as variáveis primitivas do problema. Os requisitos independentes do solucionador para essa submensagem são: * "variableValues.ids" são elementos de VariablesProto.ids. * Os atributos variables.values precisam ser finitos.
dualValues

object (SparseDoubleVectorProto)

Uma atribuição (possivelmente parcial) de valores às restrições lineares do problema.

Requisitos: * dualValues.ids são elementos de LinearConstraintsProto.ids. * dualValues.values precisam ser finitos.

SparseInt32VectorProto

Uma representação esparsa de um vetor de ints.

Representação JSON 
{
  "ids": [
    string
  ],
  "values": [
    integer
  ]
}
Campos
ids[]

string (int64 format)

Precisa ser classificado (em ordem crescente) com todos os elementos distintos.
values[]

integer

Precisa ter o mesmo comprimento que os IDs.

SolveResultProto

O contrato de quando soluções/raios primitivos/duais/raios são complexos. consulte terminais_reasons.md para uma descrição completa.

Até que um contrato exato seja finalizado, é mais seguro simplesmente verificar se uma solução/raio está presente em vez de confiar no motivo da rescisão.

Representação JSON 
{
  "termination": {
    object (TerminationProto)
  },
  "solutions": [
    {
      object (SolutionProto)
    }
  ],
  "primalRays": [
    {
      object (PrimalRayProto)
    }
  ],
  "dualRays": [
    {
      object (DualRayProto)
    }
  ],
  "solveStats": {
    object (SolveStatsProto)
  }
}
Campos
termination

object (TerminationProto)

O motivo pelo qual o solucionador parou.
solutions[]

object (SolutionProto)

O contrato geral para a ordem das soluções que futuros solucionadores de problemas implementarão é ordenar por: 1. As soluções com uma solução primária viável, ordenadas pelo melhor objetivo primário primeiro. 2. As soluções com uma solução duplamente viável, ordenada pelo melhor objetivo duplo (objetivo duplo desconhecido é pior) 3. Todas as soluções restantes podem ser retornadas em qualquer ordem.
primalRays[]

object (PrimalRayProto)

Rotas de melhoria primária ilimitada ou, equivalente, certificados de inviabilidade dupla. Normalmente fornecido para RescisãoReasonProtos UNBOUNDED e DUAL_INFEASIBLE
dualRays[]

object (DualRayProto)

Rotas de certificados de melhoria dupla ilimitada, ou, equivalente, de certificados de inviabilidade primárias. Normalmente fornecido para RescisãoReasonProto INFEASIBLE.
solveStats

object (SolveStatsProto)

Estatísticas do processo de solução, por exemplo, tempo de execução, iterações.

TerminationProto

Todas as informações sobre o motivo pelo qual uma chamada para Solve() foi encerrada.

Representação JSON 
{
  "reason": enum (TerminationReasonProto),
  "limit": enum (LimitProto),
  "detail": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "objectiveBounds": {
    object (ObjectiveBoundsProto)
  }
}
Campos
reason

enum (TerminationReasonProto)

Para mais informações no limit quando o valor for TERMINATION_REASON_FEASIBLE ou TERMINATION_REASON_NO_SOLUTION_FOUND, consulte limit para mais detalhes.
limit

enum (LimitProto)

É LIMIT_UNSPECIFIED, a menos que o motivo seja TERMINATION_REASON_FEASIBLE ou TERMINATION_REASON_NO_SOLUTION_FOUND. Nem todos os solucionadores podem determinar sempre o limite que causou o encerramento. LIMIT_UNDETERMINED é usado quando a causa não pode ser determinada.
detail

string

Outras informações, normalmente específicas do solucionador, sobre a rescisão.
problemStatus

object (ProblemStatusProto)

Status de viabilidade para problemas primários e duplos. Desde 18 de julho de 2023, essa mensagem pode não estar disponível. Se não definido, problemStatus pode ser encontrado em SolveResultProto.solve_stats.
objectiveBounds

object (ObjectiveBoundsProto)

Limites para o valor do objetivo ideal. Desde 18 de julho de 2023, essa mensagem pode não estar disponível. Se ausente, "objectBounds.primal_bound" pode ser encontrado em SolveResultProto.solve.stats.best_primal_bound e goalBounds.dual_bound pode ser encontrado em SolveResultProto.solve.stats.best_dual_bounds.

TerminationReasonProto

O motivo pelo qual uma chamada para Solve() é encerrada.

Enums
TERMINATION_REASON_UNSPECIFIED
TERMINATION_REASON_OPTIMAL Foi encontrada uma solução comprovadamente ideal (até tolerâncias numéricas).
TERMINATION_REASON_INFEASIBLE O problema primário não tem soluções viáveis.
TERMINATION_REASON_UNBOUNDED O problema primário é viável e arbitrariamente boas soluções podem ser encontradas ao longo de um raio primário.
TERMINATION_REASON_INFEASIBLE_OR_UNBOUNDED O problema primário é inviável ou ilimitado. Mais detalhes sobre o status do problema podem estar disponíveis em resolveStats.problem_status. O status ilimitado de Gurobi pode ser mapeado aqui.
TERMINATION_REASON_IMPRECISE

O problema foi resolvido para um dos critérios acima (ideal, inviável, ilimitado ou inviável ou ilimitado), mas uma ou mais tolerâncias não foram atendidas. Alguns raios/soluções primitivas/duais estão presentes, mas serão ligeiramente inviáveis ou (se o problema for quase ideal), podem ser uma lacuna entre o melhor objetivo da solução e o melhor limite do objetivo.

Os usuários ainda podem consultar soluções/raios primários/duais e estatísticas de solução, mas são responsáveis por lidar com a imprecisão numérica.
TERMINATION_REASON_FEASIBLE O otimizador atingiu algum tipo de limite e uma solução primeira viável é retornada. Consulte SolveResultProto.limit_detail para obter uma descrição detalhada do tipo de limite que foi atingido.
TERMINATION_REASON_NO_SOLUTION_FOUND O otimizador atingiu algum tipo de limite e não encontrou uma solução primária viável. Consulte SolveResultProto.limit_detail para obter uma descrição detalhada do tipo de limite que foi atingido.
TERMINATION_REASON_NUMERICAL_ERROR O algoritmo parou porque encontrou um erro numérico irrecuperável. Não há informações de solução disponíveis.
TERMINATION_REASON_OTHER_ERROR O algoritmo foi interrompido devido a um erro que não foi coberto por um dos status definidos acima. Não há informações de solução disponíveis.

LimitProto

Quando um Solve() é interrompido antes com juntosReasonProto FEASIBLE ou NO_SOLUTION_FOUND, o limite específico que foi atingido.

Enums
LIMIT_UNSPECIFIED Usado como um valor nulo quando encerramos sem um limite (por exemplo, TERMINATION_REASON_OPTIMAL).
LIMIT_UNDETERMINED O solucionador não expõe qual limite foi atingido.
LIMIT_ITERATION Um algoritmo iterativo parou depois de realizar o número máximo de iterações (por exemplo, iterações simplex ou barreira).
LIMIT_TIME O algoritmo foi interrompido após um tempo de computação especificado pelo usuário.
LIMIT_NODE Um algoritmo de ramificação e vinculação foi interrompido porque analisou um número máximo de nós na árvore correspondente.
LIMIT_SOLUTION O algoritmo parou porque encontrou o número necessário de soluções. Isso é frequentemente usado em MIPs para fazer com que o solucionador retorne a primeira solução viável que encontrar.
LIMIT_MEMORY O algoritmo parou porque ficou sem memória.
LIMIT_CUTOFF O solucionador foi executado com um corte (por exemplo, SolveParameters.cutoff_limit foi definido) no objetivo, indicando que o usuário não queria uma solução pior do que o ponto de corte, e o solucionador concluiu que não havia soluções tão boas quanto o corte. Normalmente, nenhuma outra informação sobre a solução é fornecida.
LIMIT_OBJECTIVE O algoritmo foi interrompido porque encontrou uma solução ou um limite melhor do que o limite definido pelo usuário (consulte SolveParameters.objective_limit e SolveParameters.best_bound_limit).
LIMIT_NORM O algoritmo parou porque a norma de uma iteração ficou muito grande.
LIMIT_INTERRUPTED O algoritmo parou devido a um sinal de interrupção ou a uma solicitação de interrupção do usuário.
LIMIT_SLOW_PROGRESS O algoritmo parou porque não foi possível continuar progredindo em direção à solução.
LIMIT_OTHER

O algoritmo foi interrompido devido a um limite não coberto por nenhuma das opções acima. LIMIT_UNDETERMINED é usado quando o motivo não pode ser determinado, e LIMIT_OTHER é usado quando o motivo é conhecido, mas não se encaixa em nenhuma das alternativas acima.

RescisãoProto.detail pode conter informações adicionais sobre o limite.

ProblemStatusProto

Status de viabilidade do problema primal e seu duplo (ou duplo de um relaxamento contínuo), conforme reivindicado pelo solucionador. O solucionador não precisa retornar um certificado para a declaração. Por exemplo, o solucionador pode reivindicar viabilidade primária sem retornar uma solução primeira viável. Esse status combinado fornece uma descrição abrangente das afirmações de um solucionador sobre a viabilidade e a infinidade de limites do problema resolvido. Por exemplo:

  • um status viável para problemas primários e duplos indica que a primária é viável e limitada e provavelmente tem uma solução ideal (garantida para problemas sem restrições não lineares).
  • um status primeiramente viável e um status inviável duplo indicam que o problema primário é ilimitado (ou seja, tem soluções arbitrariamente boas).

Um status duplo inviável por si só (ou seja, acompanhado por um status primal indeterminado) não implica que o problema primário é ilimitado, já que os dois problemas podem ser inviáveis. Além disso, embora um status inicial e duplo viável possa implicar a existência de uma solução ideal, isso não garante que o solucionador realmente encontrou essa solução ideal.

Representação JSON 
{
  "primalStatus": enum (FeasibilityStatusProto),
  "dualStatus": enum (FeasibilityStatusProto),
  "primalOrDualInfeasible": boolean
}
Campos
primalStatus

enum (FeasibilityStatusProto)

Status do problema primário.
dualStatus

enum (FeasibilityStatusProto)

Status para o problema duplo (ou para o duplo relaxamento contínuo).
primalOrDualInfeasible

boolean

Se verdadeiro, o solucionador afirma que o problema primário ou duplo é inviável, mas não sabe qual (ou se ambos são inviáveis). Pode ser verdadeiro apenas quando primal_problem_status = dual_problem_status = kUndeterminado. Essa informação extra muitas vezes é necessária quando o pré-processamento determina que não há uma solução ideal para o problema, mas não é possível determinar se a causa é inviabilidade, delimitação ou ambos.

FeasibilityStatusProto

Status de viabilidade do problema conforme reivindicado pelo solucionador (o solucionador não precisa retornar um certificado para a reivindicação).

Enums
FEASIBILITY_STATUS_UNSPECIFIED Valor de guarda que não representa status.
FEASIBILITY_STATUS_UNDETERMINED O solucionador não reivindica um status.
FEASIBILITY_STATUS_FEASIBLE O solucionador afirma que o problema é viável.
FEASIBILITY_STATUS_INFEASIBLE O solucionador afirma que o problema é inviável.

ObjectiveBoundsProto

Limites para o valor do objetivo ideal.

Representação JSON 
{
  "primalBound": number,
  "dualBound": number
}
Campos
primalBound

number

O solucionador afirma que o valor ideal é igual ou melhor (menor para minimização e maior para maximização) do que primalBound até a tolerância de viabilidade primária do solucionador (veja o aviso abaixo): * primalBound é trivial (+inf para minimização e -inf maximização) quando o solucionador não alega ter esse limite. * primalBound pode estar mais perto do valor ideal do que o objetivo da melhor solução primária viável. Em particular, primalBound pode não ser trivial, mesmo quando nenhuma solução primária viável é retornada. Aviso: a afirmação precisa é que existe uma solução primária que: * é numericamente viável (ou seja, viável até a tolerância do solucionador) e * tem um valor objetivo primalBound. Essa solução numericamente viável pode ser ligeiramente inviável, caso em que primalBound pode ser estritamente melhor do que o valor ideal. Converter uma tolerância de viabilidade primal para uma tolerância em primalBound não é trivial, especialmente quando a tolerância de viabilidade é relativamente grande (por exemplo, ao resolver com PDLP).
dualBound

number

O solucionador afirma que o valor ideal é igual ou pior (maior para minimização e menor para maximização) do que dualBound até a tolerância de viabilidade dupla dos solucionadores (veja o aviso abaixo): * dualBound é trivial (-inf para minimização e +inf maximização) quando o solucionador afirma não ter esse limite. Da mesma forma que na primalBound, isso pode acontecer com alguns solucionadores mesmo quando retorna o ideal. Os solucionadores de MIP normalmente informam um limite, mesmo que ele seja impreciso. * Para problemas contínuos, o dualBound pode estar mais próximo do valor ideal do que o objetivo da melhor solução dupla viável. Para o MIP, um dos primeiros valores não triviais para dualBound costuma ser o valor ideal do relaxamento do LP do MIP. * DualBound precisa ser melhor (menor para minimização e maior para maximização) do que primalBound até as tolerâncias do solucionador. Confira o aviso abaixo. Aviso: * para problemas contínuos, a declaração precisa é que existe uma solução dupla que: * é numericamente viável (ou seja, viável até a tolerância do solucionadores) e * tem um valor objetivo dualBound. Essa solução numericamente viável pode ser ligeiramente inviável, caso em que dualBound pode ser estritamente pior do que o valor ideal e primalBound. Semelhante ao caso primário, a conversão de uma tolerância de viabilidade dupla em uma tolerância em dualBound não é trivial, especialmente quando a tolerância de viabilidade é relativamente grande. No entanto, alguns solucionadores fornecem uma versão corrigida do dualBound que pode ser numericamente mais segura. Essa versão corrigida pode ser acessada pela saída específica do solucionador (por exemplo, para PDLP, pdlp_output.convergence_information. previstoed_dual_objective). * Para solucionadores de MIP, o dualBound pode ser associado a uma solução dupla para algum relaxamento contínuo (por exemplo, relaxamento de LP), mas geralmente é uma consequência complexa da execução dos solucionadores e costuma ser mais impreciso do que os limites relatados por solucionadores de LP.

SolutionProto

O que está incluído em uma solução depende do tipo de problema e do solucionador. O padrão comum atual é 1. Os solucionadores de MIP retornam apenas uma solução primária. 2. Os solucionadores de LP Simplex geralmente retornam uma base e as soluções primária e dupla associadas a ela. 3. Outros solucionadores contínuos geralmente retornam uma solução primária e uma solução dupla que estão conectadas em uma forma dependente do solucionador.

Requisitos: * pelo menos um campo precisa ser definido. Uma solução não pode ficar vazia.

Representação JSON 
{
  "primalSolution": {
    object (PrimalSolutionProto)
  },
  "dualSolution": {
    object (DualSolutionProto)
  },
  "basis": {
    object (BasisProto)
  }
}
Campos
primalSolution

object (PrimalSolutionProto)
dualSolution

object (DualSolutionProto)
basis

object (BasisProto)

PrimalSolutionProto

Uma solução para um problema de otimização.

Por exemplo, considere um programa linear simples: min c * x s.t. A * x >= b x >= 0. Uma solução primaria é atribuir valores a x. É viável se satisfizer A * x >= b e x >= 0 a partir de cima. Na mensagem PrimalSolutionProto abaixo, "variableValues" é x e "objectValue" é c * x.

Representação JSON 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "objectiveValue": number,
  "auxiliaryObjectiveValues": {
    string: number,
    ...
  },
  "feasibilityStatus": enum (SolutionStatusProto)
}
Campos
variableValues

object (SparseDoubleVectorProto)

Requisitos: * variableValues.ids são elementos de VariablesProto.ids. * Os atributos variables.values precisam ser finitos.
objectiveValue

number

Valor do objetivo calculado pelo solucionador. Não pode ser infinito ou NaN.
auxiliaryObjectiveValues

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

Valores de objetivos auxiliares calculados pelo solucionador. As chaves precisam ser IDs de objetivos auxiliares válidos. Os valores não podem ser infinitos ou NaN.

Um objeto com uma lista de pares "key": value. Exemplo: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
feasibilityStatus

enum (SolutionStatusProto)

Status de viabilidade da solução de acordo com o solucionador.

DualSolutionProto

Uma solução para o duplo problema de otimização.

Por exemplo, considere o par de programa linear de par duplo primário: (Primal) (Dual) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. A solução dupla é o par (y, r). É viável se ele satisfaz as restrições de (Dual) acima.

Na mensagem abaixo, y é dualValues, r éreduceCosts e b * y é um valor objetivo.

Representação JSON 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  },
  "feasibilityStatus": enum (SolutionStatusProto),
  "objectiveValue": number
}
Campos
dualValues

object (SparseDoubleVectorProto)

Requisitos: * dualValues.ids são elementos de LinearConstraints.ids. * dualValues.values precisam ser finitos.
reducedCosts

object (SparseDoubleVectorProto)

Requisitos: * lowerCosts.ids são elementos de VariablesProto.ids. * restrictedCosts.values devem ser todos finitos.
feasibilityStatus

enum (SolutionStatusProto)

Status de viabilidade da solução de acordo com o solucionador.
objectiveValue

number

PrimalRayProto

Uma direção de melhoria ilimitada para um problema de otimização; equivalente, um certificado de inviabilidade para o duplo do problema de otimização.

Por exemplo, considere um programa linear simples: min c * x s.t. A * x >= b x >= 0 Um raio primal é um x que satisfaz: c * x < 0 A * x >= 0 x >= 0. Considerando uma solução viável, qualquer objetivo múltiplo positivo do raio primário ainda é um valor melhor e essa solução. Um raio primário também prova que o problema de otimização dupla é inviável.

Na mensagem PrimalRay abaixo, "variableValues" é "x".

Representação JSON 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  }
}
Campos
variableValues

object (SparseDoubleVectorProto)

Requisitos: * variableValues.ids são elementos de VariablesProto.ids. * Os atributos variables.values precisam ser finitos.

DualRayProto

Uma direção de melhoria ilimitada para o duplo de uma otimização, problema; equivalente, um certificado de inviabilidade primordial.

Por exemplo, considere o par de programa linear de par duplo primário: (Primal) (Dual) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. O raio duplo é o par (y, r) que satisfaz: b * y > 0 y * A + r = 0 y, r >= 0. A adição de um múltiplo positivo de (y, r) a uma solução viável dupla mantém a viabilidade dupla e melhora o objetivo (provando que o duplo é ilimitado). O raio duplo também prova que o problema primário é inviável.

Na mensagem DualRay abaixo, y é dualValues e r é lowerCosts.

Representação JSON 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  }
}
Campos
dualValues

object (SparseDoubleVectorProto)

Requisitos: * dualValues.ids são elementos de LinearConstraints.ids. * dualValues.values precisam ser finitos.
reducedCosts

object (SparseDoubleVectorProto)

Requisitos: * lowerCosts.ids são elementos de VariablesProto.ids. * restrictedCosts.values devem ser todos finitos.

SolveStatsProto

Representação JSON 
{
  "solveTime": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "simplexIterations": string,
  "barrierIterations": string,
  "firstOrderIterations": string,
  "nodeCount": string
}
Campos
solveTime

string (Duration format)

O tempo decorrido decorrido, conforme medido por math_opt, é aproximadamente o tempo dentro de Solver::Solve(). Observação: isso não inclui o trabalho feito na criação do modelo.

Uma duração em segundos com até nove dígitos fracionários, terminando em "s". Exemplo: "3.5s".
problemStatus

object (ProblemStatusProto)

Status de viabilidade para problemas primários e duplos.
simplexIterations

string (int64 format)
barrierIterations

string (int64 format)
firstOrderIterations

string (int64 format)
nodeCount

string (int64 format)