Method: mathopt.solveMathOptModel

Resolve o modelo de entrada e retorna o resultado de uma vez. Use quando não precisar de callbacks, incrementabilidade nem 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 for compatível com um atributo específico no modelo, o procedimento de otimização não será bem-sucedido.
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 verdadeiro 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 resultará em um erro.
modelParameters

object (ModelSolveParametersProto)

Opcional. Parâmetros para controlar uma única solução que são específicos do modelo de entrada (consulte SolveParametersProto para conhecer 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 solução do modelo na solicitação.
messages[]

string

Se SolveParametersProto.enable_output tiver sido usado, ele conterá mensagens de registro para solucionadores que oferecem suporte a callbacks de mensagens.

SolverTypeProto

Os solucionadores compatíveis com MathOpt.

Enums
SOLVER_TYPE_UNSPECIFIED
SOLVER_TYPE_GSCIP

Resolvedor de programas de números inteiros de restrições (SCIP, na sigla em inglês) (terceiros).

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

Solucionador Gurobi (terceiro).

Dá suporte a problemas quadráticos de números inteiros não convexos, de LP e de MIP. Geralmente é a opção mais rápida, mas tem uma licença especial.
SOLVER_TYPE_GLOP

o solucionador Glop do Google.

Oferece suporte ao LP com métodos primários e dual simplex.
SOLVER_TYPE_CP_SAT

o solucionador CP-SAT do Google.

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

Solucionador de PDLP do Google.

Oferece suporte a objetivos quadráticos diagonais convexos e de LP. Usa métodos de primeira ordem em vez de simplex. Pode resolver problemas muito grandes.
SOLVER_TYPE_GLPK

GNU Linear Programming Kit (GLPK) de terceiros.

Compatível com MIP e LP.

Segurança da linha de execução: o GLPK usa o armazenamento local da linha de execução para alocações de memória. Como consequência, as instâncias do Solver devem ser destruídas na mesma linha de execução em que são criadas, caso contrário o GLPK falhará. Não há problema em chamar Solver::Solve() de um thread diferente do usado para criar o Solver, mas isso não está documentado pelo GLPK e deve ser evitado.

Ao resolver um LP com o resolvedor, uma solução e os raios ilimitados só são retornados quando uma solução ideal é encontrada. Caso contrário, nada será retornado. Consulte a glpk-5.0/doc/glpk.pdf página 40, disponível em glpk-5.0.tar.gz, para saber mais detalhes.
SOLVER_TYPE_OSQP

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

Dá suporte a 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) (terceiros).

Oferece suporte a problemas de LP e SOCP. Usa métodos de ponto interior (barreira).
SOLVER_TYPE_SCS

O solucionador cônico de divisão (SCS, na sigla em inglês) (terceiro).

Oferece suporte a problemas de LP e SOCP. Usa um método de primeira ordem.
SOLVER_TYPE_HIGHS

O solucionador HiGHS (terceiro).

Oferece suporte a problemas de LP e MIP (QPs convexos não são implementados).
SOLVER_TYPE_SANTORINI

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

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

ModelProto

Um problema de otimização. O MathOpt oferece suporte a: - 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. - Uma série de 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 "ID dos dados" mapas. No entanto, representamos restrições lineares em uma "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 com vários objetivos.

Os IDs de chave do mapa precisam estar no formato [0, max(int64)). Cada prioridade e nome não vazio precisam ser exclusivos e diferentes da 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 para as restrições lineares.

Se uma variável envolvida nessa restrição for excluída, ela será tratada como se fosse 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 todos 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))

Restrições SOS1 no modelo, que restringem que no máximo um expression pode 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 produzam "equilíbrio" nós filhos.

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 precisam ser adjacentes na ordem delas. Se nenhum weights for fornecido, essa ordem será linear na lista de expressions. se weights forem apresentados, a ordem será tomada 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 indicadores no modelo, que impõem que, se uma "variável indicadora" binária for definido como 1, a "restrição implícita" precisa realizar.

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

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

string

Se não definido, presume-se que sejam todas as strings vazias. Caso contrário, o comprimento deve ser 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: * linearCoefficiencys.ids são elementos de VariablesProto.ids. * VariablesProto não especificado corresponde a zero. * linearCoefficiencys.values precisa ser finito. * linearCoefficiencys.values pode ser zero, mas isso é um desperdício de espaço.
quadraticCoefficients

object (SparseDoubleMatrixProto)

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

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

Observações: * Termos não armazenados explicitamente têm coeficiente zero. * Os elementos de quadráticosCoeficientes.coeficientes podem ser zero, mas isso é um desperdício de espaço.
name

string

As mensagens mãe podem ter requisitos de exclusividade neste campo. por exemplo, 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 (quanto mais baixo, mais importante). Esse valor não pode ser negativo. Além disso, cada prioridade objetiva no modelo precisa ser distinta no momento da resolução. Essa condição não é validada no nível do protótipo, 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)

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

number

O comprimento dos IDs precisa ser igual. Não pode conter NaN.

SparseDoubleMatrixProto

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

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

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

string (int64 format)
columnIds[]

string (int64 format)
coefficients[]

number

Não pode conter NaN.

LinearConstraintsProto

Conforme usado abaixo, definimos "#restrições lineares" = 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 definido, presume-se que sejam todas as strings vazias. Caso contrário, deverá ter comprimento igual às restrições #linear.

Todos os nomes não vazios precisam ser distintos.

QuadraticConstraintProto

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

Se uma variável envolvida nessa restrição for excluída, ela será tratada como se fosse 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 de mensagens SparseDoubleVectorProto, exigimos que: * linearTerms.ids são elementos de VariablesProto.ids. * Os linearTerms.values precisam ser todos finitos e não-NaN.

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

object (SparseDoubleMatrixProto)

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

Além dos requisitos para mensagens SparseDoubleMatrixProto, exigimos que: * Cada elemento de quadraticTerms.row_ids e cada elemento de quadraticTerms.column_ids precisa 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 não armazenados explicitamente têm coeficiente zero. * Os elementos de quadraticTerms.coeficientes podem ser zero, mas isso é um desperdício de espaço.
lowerBound

number

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

number

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

string

As mensagens mãe 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 fosse 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 mãe 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. Precisa ser classificado (em ordem crescente) com todos os elementos distintos.
coefficients[]

number

O comprimento dos IDs precisa ser igual. Os valores precisam ser finitos e não podem ser NaN.
offset

number

Precisa ser finito e não pode ser NaN.

SosConstraintProto

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

Se uma variável envolvida nessa restrição for excluída, ela será tratada como se fosse 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 podem receber valores diferentes de zero e precisam estar adjacentes na ordem repetida.
weights[]

number

Vazio ou de comprimento igual às expressões. Se estiver vazio, as ponderações padrão serão 1, 2, ... Se presente, as entradas devem ser únicas.
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 única restrição de indicador no formato: Variable(indicatorId) = (activateOnZero ? 0 : 1) ⇒ bottomBound <= expressão <= topBound.

Se uma variável envolvida nessa restrição (seja o indicador ou que aparece em expression) for excluída, ela será tratada como se estivesse definida como zero. Em particular, excluir a variável do indicador significa que a restrição dele será vazia se activateOnZero for falso 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 for verdadeiro, se a variável do indicador receber o valor 0, a restrição implícita precisa ser mantida. Caso contrário, se a variável do indicador receber o valor 1, a restrição implícita precisa 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 valor em [-inf, inf); não pode ser NaN.
upperBound

number

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

string

As mensagens mãe 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, exigimos 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 após a resolução.

SolveParametersProto

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

Contém os dois parâmetros comuns a todos os solucionadores, por exemplo, timeLimit e parâmetros de 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 solucionador padrão será 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 da 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 estiver definido).

Este valor não é um limite fixo. O tempo de resolução pode exceder um pouco esse valor. Esse parâmetro sempre é passado para o solucionador, e o padrão dele não é usado.

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. O local desses traces depende do solucionador. Para SCIP e Gurobi, esses serão os fluxos de saída padrão. Para Glop e CP-SAT, isso vai gerar LOG(INFO).

Se o solucionador for compatível com callback de mensagem e o usuário registrar um callback para ele, esse valor de parâmetro será ignorado e nenhum rastro será mostrado.
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 usam isso apenas para a resolução do LP raiz (e usam dual simplex caso contrário).
presolve

enum (EmphasisProto)

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

enum (EmphasisProto)

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

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

enum (EmphasisProto)

Esforço em encontrar soluções viáveis além daquelas encontradas em todo o procedimento de pesquisa (somente MIP) ou o nível de esforço padrão do solucionador, se ⌘_UNSPECIFIED.
scaling

enum (EmphasisProto)

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

string (int64 format)

Limite as iterações do algoritmo subjacente (por exemplo, pivots simplex). O comportamento específico depende do solucionador e do algoritmo usados, mas muitas vezes pode fornecer um limite determinístico de resolução (mais configuração pode ser necessária, por exemplo, uma linha de execução).

Normalmente tem suporte de solucionadores LP, QP e MIP, mas para solucionadores MIP, consulte também nodeLimit.
nodeLimit

string (int64 format)

Limite do número de subproblemas resolvidos na pesquisa enumerativa (por exemplo, ramificação e vinculação). Em muitos solucionadores, isso pode ser usado para limitar a computação de forma determinista (mais configurações podem ser necessárias, por exemplo, uma linha de execução).

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

number

O solucionador é interrompido antes se puder provar que não há soluções primárias tão boas quanto o corte.

Em uma parada antecipada, o solucionador retorna o motivo de encerramento NO_SOLUTION_FOUND e com o limite CUTOFF e não precisa fornecer informações extras sobre a solução. Não terá efeito sobre o valor de retorno se não houver parada antecipada.

Recomendamos 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 é interrompido assim que encontra uma solução pelo menos assim, com o motivo de encerramento viável e limitar o OBJETIVO.
bestBoundLimit

number

O solucionador é interrompido assim que prova que o melhor limite é pelo menos esse bom, com o motivo de encerramento FEASIBLE ou NO_SOLUTION_FOUND e limitar OBJECTIVE.

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

integer

O solucionador para logo após encontrar essas muitas soluções viáveis, com o motivo de encerramento viável e SOLUÇÃO limitada. Precisa ser maior do que zero se definido. Muitas vezes, ela é usada para fazer o solucionador parar na primeira solução viável encontrada. Não há garantia sobre o valor do objetivo para nenhuma das soluções retornadas.

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

Atualmente aceito para Gurobi e SCIP e para CP-SAT apenas com valor 1.
threads

integer

Se definido, ele deve ser >= 1.
randomSeed

integer

Semente para o gerador de números pseudoaleatórios no solucionador subjacente. Observe que todos os solucionadores usam números pseudoaleatórios para selecionar itens como perturbação no algoritmo de LP, regras de desempatamento e correções heurísticas. Variar isso pode ter um impacto perceptível no comportamento do solucionador.

Embora todos os solucionadores tenham um conceito de sementes, observe que os valores válidos dependem do solucionador real. - Gurobi: [0:GRB_MAXINT] (que a partir de 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 pode ser interrompido quando o GAP absoluto for no máximo offsetGapTolerance (quando definido) e retornar TERMINATION_REASON_OPTIMAL.

Precisa ser maior ou igual a 0 se definido.

Consulte também parentGapTolerance.
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 em LiveGapTolerance), em que a normalização é dependente do solucionador, por exemplo, o GAP absoluto dividido pelo valor objetivo da melhor solução viável encontrada.

O solucionador poderá ser interrompido quando o GAP relativo atingir o nível relativo do GapTolerance (quando definido) e retornar TERMINATION_REASON_OPTIMAL.

Precisa ser maior ou igual a 0 se definido.

Consulte também PersistentVolumeGapTolerance.
solutionPoolSize

integer

Mantenha até solutionPoolSize soluções enquanto pesquisa. O pool de soluções geralmente tem duas funções: (1) para solucionadores que podem retornar mais de uma solução, isso limita o número de soluções que serão retornadas. (2) Alguns solucionadores podem executar heurística usando soluções do pool de soluções. Portanto, alterar esse valor pode afetar o caminho do algoritmo. Para forçar o solucionador a preencher o pool de soluções, por exemplo, as N melhores soluções, requer uma configuração adicional específica do solucionador.

LPAlgorithmProto

Seleciona um algoritmo para resolver programas lineares.

Enums
LP_ALGORITHM_UNSPECIFIED
LP_ALGORITHM_PRIMAL_SIMPLEX O método simplex (prim). Normalmente, pode fornecer soluções primárias e duplas, raios primários/duplos em problemas ilimitados primários/duplos e uma base.
LP_ALGORITHM_DUAL_SIMPLEX O método dual simplex. Normalmente, pode fornecer soluções primárias e duplas, raios primários/duplos em problemas ilimitados primários/duplos e uma base.
LP_ALGORITHM_BARRIER Método de barreira, também comumente chamado de método de ponto interior (IPM). Normalmente, pode 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 um "crossover" e termina com simplex.
LP_ALGORITHM_FIRST_ORDER Um algoritmo baseado em um método de primeira ordem. Elas normalmente produzem 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 ter cuidado ao definir parâmetros de qualidade da solução (por exemplo, tolerâncias) e validar soluções.

EmphasisProto

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

A ênfase é usada para configurar um recurso do solucionador da seguinte maneira: * 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 DESLIGADO). * Se o solucionador for compatível com o 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 for ativado por padrão, o solucionador padrão normalmente será mapeado para MÉDIO. - Se o atributo for compatível, LOW, MEDIUM, HIGH e VERY HIGH nunca apresentarão um erro e serão mapeados para sua 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, ele será 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 vai ser usada.
branchingPriorities

object (SparseInt32VectorProto)

Prioridades opcionais de ramificação. As variáveis com valores mais altos serão ramificadas primeiro. As variáveis para as quais prioridades não sã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 das 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 vazio quando filterByIds for falso. OBSERVAÇÃO: se estiver vazio e filterByIds for verdadeiro, você está dizendo que não deseja nenhuma informação no resultado.

BasisProto

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

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

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

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

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

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

object (SparseBasisStatusVector)

Status da base da restrição.

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

object (SparseBasisStatusVector)

Status de base variável.

Requisitos: * constraintsStatus.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 (soluções ideais sempre terão o status SOLUTION_STATUS_FEASIBLE).

Para LPs unilaterais, deve ser igual ao status de viabilidade da solução dupla associada. Para LPs de dois lados, pode ser diferente em alguns casos extremos (por exemplo, soluções incompletas com primal simplex).

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

SparseBasisStatusVector

Uma representação esparsa de um vetor de status de base.

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

string (int64 format)

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

enum (BasisStatusProto)

O comprimento dos IDs precisa ser igual.

BasisStatusProto

Status de uma variável/restrição em uma base de LP.

Enums
BASIS_STATUS_UNSPECIFIED Valor protegido que representa nenhum 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 inferior e superior finitos idênticos.
BASIS_STATUS_BASIC A variável/restrição é básica.

SolutionStatusProto

Viabilidade de uma solução primária ou dupla, conforme declarado pelo solucionador.

Enums
SOLUTION_STATUS_UNSPECIFIED Valor protegido que representa nenhum status.
SOLUTION_STATUS_UNDETERMINED O Solver não alega 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 solução inicial sugerida para o solucionador.

Os solucionadores MIP geralmente querem apenas informações primárias (variableValues), enquanto os LPs 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 geralmente resolvem um sub-MIP para concluir/corrigir a dica.

A forma como a dica é usada pelo solucionador, se for o caso, depende muito do solucionador, do tipo de problema e do algoritmo usado. A maneira mais confiável de garantir que a dica tenha efeito é ler os registros do solucionador com e sem ela.

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

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

object (SparseDoubleVectorProto)

Uma atribuição possivelmente parcial de valores às variáveis primárias do problema. Os requisitos independentes de solucionador para esta submensagem são: * variablesValues.ids são elementos de VariablesProto.ids. * variablesValues.values precisam ser todas finitas.
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. * Os valores dualValues.values devem ser todos finitos.

SparseInt32VectorProto

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

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

string (int64 format)

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

integer

O comprimento dos IDs precisa ser igual.

SolveResultProto

O contrato do momento em que as soluções/raios primárias/duplas são complexas. Consulte encerramento_reasons.md para a 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 da interrupção do solucionador.
solutions[]

object (SolutionProto)

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

object (PrimalRayProto)

Instruções de melhoria primária ilimitada ou, equivalente, certificados de inviabilidade dupla. Fornecido normalmente para DeletionReasonProtos UNBOUNDED e DUAL_INFEASIBLE
dualRays[]

object (DualRayProto)

Instruções de melhoria dupla ilimitada ou, equivalente, certificados de inviabilidade primária. Fornecido normalmente para EndpointReasonProto INFEASIBLE.
solveStats

object (SolveStatsProto)

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

TerminationProto

Todas as informações sobre o motivo de uma chamada para Solve() ser encerrada.

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

enum (TerminationReasonProto)

Mais informações em limit quando o valor é 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 sempre determinar 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. Em 18 de julho de 2023, essa mensagem pode não ter sido exibida. Se ausente, problemStatus poderá ser encontrado em SolveResultProto.solve_stats.
objectiveBounds

object (ObjectiveBoundsProto)

Limites sobre o valor do objetivo ideal. Em 18 de julho de 2023, essa mensagem pode não ter sido exibida. Se ausente, "objectBounds.primal_bound" pode ser encontrado em SolveResultProto.solve.stats.best_primal_bound, e "objectBounds.dual_bound" pode ser encontrado em SolveResultProto.solve.stats.best_dual_bound,

TerminationReasonProto

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

Enums
TERMINATION_REASON_UNSPECIFIED
TERMINATION_REASON_OPTIMAL Foi encontrada uma solução provavelmente 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 solveStats.problem_status. Observe que o status ilimitado de Gurobi pode ser mapeado aqui.
TERMINATION_REASON_IMPRECISE

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

Os usuários ainda podem consultar soluções/raios primitivas/duplas 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 primária 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. Nenhuma informação sobre a solução está disponível.
TERMINATION_REASON_OTHER_ERROR O algoritmo parou devido a um erro que não foi coberto por um dos status definidos acima. Nenhuma informação sobre a solução está disponível.

LimitProto

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

Enums
LIMIT_UNSPECIFIED Usado como valor nulo quando encerramos fora de 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 conduzir o número máximo de iterações (por exemplo, iterações simplex ou de barreira).
LIMIT_TIME O algoritmo parou após um tempo de computação especificado pelo usuário.
LIMIT_NODE Um algoritmo com ramificação e vinculação parou porque explorou um número máximo de nós na árvore.
LIMIT_SOLUTION O algoritmo parou porque encontrou o número necessário de soluções. Isso é muito usado em MIPs para 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 ponto de 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 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 parou porque encontrou uma solução ou um limite melhor do que um 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 ou a uma solicitação de interrupção do usuário.
LIMIT_SLOW_PROGRESS O algoritmo parou porque não pôde continuar a progredir em direção à solução.
LIMIT_OTHER

O algoritmo parou devido a um limite não coberto por uma 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.

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

ProblemStatusProto

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

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

Observe que um status inviável dupla por si só (ou seja, acompanhado por um status primário indeterminado) não implica que o problema primário é ilimitado, já que ambos podem ser inviáveis. Além disso, embora um status de viabilidade primária e dupla 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 do problema duplo (ou do 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 somente quando primal_problem_status = dual_problem_status = kUndeterminado. Muitas vezes, essas informações extras são necessárias quando o pré-processamento determina que não há uma solução ideal para o problema, mas não é possível determinar se o motivo é inviabilidade, ilimitada ou ambos.

FeasibilityStatusProto

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

Enums
FEASIBILITY_STATUS_UNSPECIFIED Valor protegido que representa nenhum status.
FEASIBILITY_STATUS_UNDETERMINED O solucionador não solicita 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 sobre 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 dos solucionadores (confira o aviso abaixo): * primalBound é trivial (+inf para minimização e maximização -inf) quando o solucionador não alega ter esse limite. * O primalBound pode estar mais próximo do valor ideal do que do objetivo da melhor solução primária viável. Em particular, o primalBound pode não ser trivial, mesmo quando nenhuma solução primitiva viável for retornada. Aviso: a afirmação exata é que existe uma solução primária que: * é numericamente viável (ou seja, viável até a tolerância dos solucionadores) 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 primária em 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 do solucionador (veja o aviso abaixo): * dualBound é trivial (-inf para minimização e +inf maximização) quando o solucionador não alega ter esse limite. Assim como no método primalBound, isso pode acontecer com alguns solucionadores mesmo ao retornar o valor ideal. Os solucionadores de MIP normalmente relatam um limite, mesmo que ele seja impreciso. * para problemas contínuos, o dualBound pode ser mais próximo do valor ideal do que o objetivo da melhor solução dupla viável. No MIP, um dos primeiros valores não triviais do dualBound costuma ser o valor ideal do relaxamento do LP do MIP. * dualBound deve ser melhor (menor para minimização e maior para maximização) do que primalBound até as tolerâncias dos solucionadores (veja o aviso abaixo). Aviso: * para problemas contínuos, a afirmação precisa é que existe uma solução dupla que: * é numericamente viável (ou seja, viável até a tolerância do solucionador) 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, converter uma tolerância de viabilidade dupla para 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 de dualBound que pode ser numericamente mais seguro. Essa versão corrigida pode ser acessada pela saída específica do solucionador, por exemplo, para PDLP, pdlp_output.convergence_information. correçãoed_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 costuma ser uma consequência complexa da execução dos solucionadores e normalmente é mais impreciso do que os limites relatados pelos solucionadores de LP.

SolutionProto

Uma solução depende do tipo de problema e de solucionador. Os padrões comuns atuais são 1. Os solucionadores MIP retornam somente uma solução primária. 2. Os solucionadores de LP Simplex retornam uma base e as soluções primárias e duplas associadas a ela. 3. Outros solucionadores contínuos muitas vezes retornam soluções primárias e duplas que são conectadas na forma dependente do solucionador.

Requisitos: * pelo menos um campo deve 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 primária é atribuir valores a x. Ela é viável se satisfizer A * x >= b e x >= 0 do valor acima. 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: * variablesValues.ids são elementos de VariablesProto.ids. * variablesValues.values precisam ser todas finitas.
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 conforme 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). Ela é viável se satisfizer as restrições de (Dual) acima.

Na mensagem abaixo, y é dualValues, r é reduzidoCosts e b * y é o 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. * Os valores dualValues.values devem ser todos finitos.
reducedCosts

object (SparseDoubleVectorProto)

Requisitos: * reduceCosts.ids são elementos de VariablesProto.ids. * reduceCosts.values precisa ser finito.
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; de forma equivalente, um certificado de inviabilidade para o problema duplo de otimização.

Por exemplo: considere um programa linear simples: min c * x s.t. A * x >= b x >= 0 Um raio primário é um x que satisfaz: c * x < 0 A * x >= 0 x >= 0 Observe que, dada uma solução viável, qualquer múltiplo positivo do raio primário mais essa solução ainda é viável, e fornece um valor objetivo melhor. 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: * variablesValues.ids são elementos de VariablesProto.ids. * variablesValues.values precisam ser todas finitas.

DualRayProto

uma direção de melhoria ilimitada para o duplo de um problema de otimização; equivalente, um certificado de inviabilidade primária.

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 Observe que adicionar um múltiplo positivo de (y, r) à solução dupla mantém a viabilidade dupla e melhora o objetivo (provando que a dupla é ilimitada). O raio duplo também prova que o problema primário é inviável.

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

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

object (SparseDoubleVectorProto)

Requisitos: * dualValues.ids são elementos de LinearConstraints.ids. * Os valores dualValues.values devem ser todos finitos.
reducedCosts

object (SparseDoubleVectorProto)

Requisitos: * reduceCosts.ids são elementos de VariablesProto.ids. * reduceCosts.values precisa ser finito.

SolveStatsProto

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

string (Duration format)

Tempo decorrido do relógio de parede, medido por math_opt, aproximadamente o tempo dentro de Solver::Solve(). Observação: isso não inclui o trabalho concluído na criação do modelo.

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)