Package google.research.optimization.v1.mathopt

Index

• BasisProto (message)
• BasisStatusProto (enum)
• DualRayProto (message)
• DualSolutionProto (message)
• EmphasisProto (enum)
• FeasibilityStatusProto (enum)
• IndicatorConstraintProto (message)
• LPAlgorithmProto (enum)
• LimitProto (enum)
• LinearConstraintsProto (message)
• LinearExpressionProto (message)
• ModelProto (message)
• ModelSolveParametersProto (message)
• ObjectiveBoundsProto (message)
• ObjectiveProto (message)
• PrimalRayProto (message)
• PrimalSolutionProto (message)
• ProblemStatusProto (message)
• QuadraticConstraintProto (message)
• SecondOrderConeConstraintProto (message)
• SolutionHintProto (message)
• SolutionProto (message)
• SolutionStatusProto (enum)
• SolveParametersProto (message)
• SolveResultProto (message)
• SolveStatsProto (message)
• SolverTypeProto (enum)
• SosConstraintProto (message)
• SparseBasisStatusVector (message)
• SparseDoubleMatrixProto (message)
• SparseDoubleVectorProto (message)
• SparseInt32VectorProto (message)
• SparseVectorFilterProto (message)
• TerminationProto (message)
• TerminationReasonProto (enum)
• VariablesProto (message)

BasisProto

Caractérisation combinatoire d'une solution à un programme linéaire.

La méthode simplex de résolution de programmes linéaires renvoie toujours une "solution réalisable de base" qui peut être décrite de façon combinatoire par une base. Une base attribue un BasisStatusProto à chaque variable et contrainte linéaire.

Prenons l'exemple d'une page de destination au format standard: min c * x s.t. A * x = b x >= 0 qui comporte plus de variables que de contraintes et présente un rang A à ligne complet.

Soit n le nombre de variables et m le nombre de contraintes linéaires. Une base valable pour ce problème peut être construite comme suit: * Toutes les contraintes auront l'état de base FIXED. * Choisissez des variables m de sorte que les colonnes de A soient linéairement indépendantes et attribuez l'état BASIC. * Attribuez l'état AT_LOWER aux variables n - m restantes.

La solution de base pour cette base est la solution unique de A * x = b dans laquelle toutes les variables dont l'état est AT_LOWER sont fixées sur leur limite inférieure (toutes des zéros). La solution qui en résulte est appelée solution réalisable de base si elle satisfait également x >= 0.

Champs
constraint_status	SparseBasisStatusVector État de la base de contrainte. Exigences: * constrain_status.ids est égal à LinearConstraints.ids.
variable_status	SparseBasisStatusVector État de la base variable. Conditions requises: * constrain_status.ids est égal à VariablesProto.ids.
basic_dual_feasibility	SolutionStatusProto MathOpt utilise cette fonctionnalité avancée pour déterminer la faisabilité de solutions LP non optimales (les solutions optimales ont toujours l'état SOLUTION_STATUS_FEASIBLE). Pour les pages de destination unilatérales, cela doit être égal à l'état de faisabilité de la solution double associée. Pour les pages de destination recto verso, elle peut être différente dans certains cas particuliers (par exemple, résolution incomplète avec le simplex primal). Si vous fournissez une base de départ via ModelSolveParametersProto.initial_basis, cette valeur est ignorée. Elle n'est pertinente que pour la base renvoyée par SolutionProto.basis.

BasisStatusProto

État d'une variable/contrainte dans une page de destination.

Enums
BASIS_STATUS_UNSPECIFIED	Valeur de garde représentant aucun état.
BASIS_STATUS_FREE	La variable/contrainte est libre (elle n'a pas de limites finies).
BASIS_STATUS_AT_LOWER_BOUND	La variable/contrainte est à sa limite inférieure (qui doit être finie).
BASIS_STATUS_AT_UPPER_BOUND	La variable/contrainte est dans sa limite supérieure (qui doit être finie).
BASIS_STATUS_FIXED_VALUE	La variable/contrainte a des limites finies et supérieures identiques.
BASIS_STATUS_BASIC	La variable/contrainte est basique.

DualRayProto

Direction d'amélioration illimitée de la double optimisation : problème ; ce qui équivaut à un certificat d'infaisabilité primaire.

Prenons l'exemple de la paire de programmes linéaire à paires primitives: (Primal) (Dual) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. Le double rayon est la paire (y, r) qui réponde: b * y > 0 y * A + r = 0 y, r >= 0. Notez que l'ajout d'un multiple positif de (y, r) à la double solution réalisable maintient la double faisabilité et améliore l'objectif (prouver que le double est illimité). Le double rayon prouve également que le problème primaire est irréalisable.

Dans le message DualRay ci-dessous, "y" correspond à "dual_values" et "r" est "reduce_costs".

Champs
dual_values	SparseDoubleVectorProto Exigences: * dual_values.ids sont des éléments des LinearConstraints.ids. * dual_values.values doivent tous être finis.
reduced_costs	SparseDoubleVectorProto Conditions requises: * restricted_costs.ids sont des éléments de VariablesProto.ids. * Les valeurs réduit_costs.values doivent toutes être limitées.

DualSolutionProto

Solution à deux problèmes d'optimisation

Prenons l'exemple de la paire de programmes linéaire à paires primitives: (Primal) (Dual) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. La double solution est la paire (y, r). Cela est possible si les contraintes de la règle (Dual) ci-dessus sont remplies.

Dans le message ci-dessous, y est double_valeurs, r est réduit_coûts et b * y est la valeur de l'objectif.

Champs
dual_values	SparseDoubleVectorProto Exigences: * dual_values.ids sont des éléments des LinearConstraints.ids. * dual_values.values doivent tous être finis.
reduced_costs	SparseDoubleVectorProto Conditions requises: * restricted_costs.ids sont des éléments de VariablesProto.ids. * Les valeurs réduit_costs.values doivent toutes être limitées.
feasibility_status	SolutionStatusProto État de faisabilité de la solution selon le résolveur sous-jacent.
objective_value	double

EmphasisProto

Niveau d'effort appliqué à une tâche facultative lors de la résolution (voir l'utilisation de SolveParametersProto).

La mise en valeur est utilisée pour configurer une fonctionnalité de solution comme suit: * Si un résolveur n'est pas compatible avec cette fonctionnalité, seul "UNSPECIFIED" (NON SPÉCIFIÉ) est toujours valide. Tout autre paramètre génère généralement une erreur d'argument non valide (certains résolveurs peuvent également accepter la valeur "OFF"). * Si le résolveur prend en charge la fonctionnalité: - Lorsqu'il est défini sur "UNSPECIFIED" (NON SPÉCIFIÉ), la valeur par défaut sous-jacente est utilisée. - Si la fonctionnalité ne peut pas être désactivée, elle renvoie une erreur. - Si la fonctionnalité est activée par défaut, les valeurs par défaut du résolveur sont généralement mappées sur MOYENNE. - Si l'élément géographique est pris en charge, les valeurs LOW (faible), MEDIUM (moyenne), HIGH (élevée) et très élevée (très élevée) ne généreront jamais d'erreur et seront mappées sur la meilleure correspondance.

Enums
EMPHASIS_UNSPECIFIED
EMPHASIS_OFF
EMPHASIS_LOW
EMPHASIS_MEDIUM
EMPHASIS_HIGH
EMPHASIS_VERY_HIGH

FeasibilityStatusProto

État de faisabilité du problème tel que revendiqué par le résolveur (le résolveur n'est pas tenu de renvoyer un certificat pour la réclamation).

Enums
FEASIBILITY_STATUS_UNSPECIFIED	Valeur de garde représentant aucun état.
FEASIBILITY_STATUS_UNDETERMINED	Le résolveur ne revendique pas de statut.
FEASIBILITY_STATUS_FEASIBLE	Le résolveur affirme que le problème est réalisable.
FEASIBILITY_STATUS_INFEASIBLE	Le résolveur affirme que le problème est impossible à résoudre.

IndicatorConstraintProto

Données représentant une seule contrainte d'indicateur au format suivant: Variable(indicator_id) = (activate_on_zero ? 0 : 1) PRIVATE_limite_inférieure <= expression <= limite_supérieure.

Si une variable impliquée dans cette contrainte (l'indicateur ou apparaissant dans expression) est supprimée, elle est traitée comme si elle était définie sur zéro. En particulier, la suppression de la variable d'indicateur signifie que la contrainte d'indicateur est vide si activate_on_zero est défini sur "false", et qu'elle équivaut à une contrainte linéaire si activate_on_zero est défini sur "true".

Champs
activate_on_zero	bool Si la valeur est "true", alors si la variable d'indicateur prend la valeur 0, la contrainte implicite doit être respectée. Sinon, si la variable d'indicateur prend la valeur 1, la contrainte implicite doit être respectée.
expression	SparseDoubleVectorProto Doit être une expression linéaire valide par rapport au modèle parent: * Toutes les conditions indiquées sur SparseDoubleVectorProto, * Tous les éléments de expression.values doivent être finis, * expression.ids est un sous-ensemble de VariablesProto.ids.
lower_bound	double Doit avoir une valeur dans [-inf, inf) ; ne peut pas être NaN.
upper_bound	double Doit avoir une valeur dans (-inf, inf]; ne peut pas être NaN.
name	string Les messages parents peuvent présenter des exigences d'unicité dans ce champ (voir ModelProto.indicator_constraints et IndicatorConstraintUpdatesProto.new_constraints, par exemple).
indicator_id	int64 ID correspondant à une variable binaire, ou non défini. Si cette valeur n'est pas définie, la contrainte d'indicateur est ignorée. S'il est défini, nous exigeons les éléments suivants: * VariablesProto.integers[indicator_id] = true, * VariablesProto.lower_bounds[indicator_id] >= 0, * VariablesProto.upper_bounds[indicator_id] <= 1. Ces conditions ne sont pas validées par MathOpt, mais si elles ne sont pas remplies, le résolveur renvoie une erreur lors de la résolution.

LPAlgorithmProto

Sélectionne un algorithme pour résoudre des programmes linéaires.

Enums
LP_ALGORITHM_UNSPECIFIED
LP_ALGORITHM_PRIMAL_SIMPLEX	Méthode simplex (primale). En général, ces solutions peuvent fournir des solutions primales et doubles, des rayons primaires/doubles sur des problèmes illimités et doubles, ainsi qu'une base.
LP_ALGORITHM_DUAL_SIMPLEX	Méthode du double simplex. En général, ces solutions peuvent fournir des solutions primales et doubles, des rayons primaires/doubles sur des problèmes illimités et doubles, ainsi qu'une base.
LP_ALGORITHM_BARRIER	La méthode de la barrière, également communément appelée méthode du point intérieur (IPM, Indoor Point Method). Peut généralement fournir à la fois une solution primaire et une solution double. Certaines implémentations peuvent également produire des rayons sur des problèmes illimités/inréalisables. Aucune base n'est indiquée, sauf si le résolveur sous-jacent effectue un "croisement" et se termine par un simplex.
LP_ALGORITHM_FIRST_ORDER	Algorithme basé sur une méthode du premier ordre. Elles produisent généralement des solutions primaires et doubles, et potentiellement des certificats d'inexploitabilité primaire et/ou double. Les méthodes de premier ordre fournissent généralement des solutions moins précises. Les utilisateurs doivent donc veiller à définir les paramètres de qualité de la solution (par exemple, des tolérances) et à valider les solutions.

LimitProto

Lorsqu'une fonction Solve() s'arrête avant la fin avec une valeur FEASIBLE ou NO_SOLUTION_FOUND, la limite spécifique atteinte.

Enums
LIMIT_UNSPECIFIED	Utilisée en tant que valeur nulle lorsque nous n'avons pas atteint une limite (par exemple, TERMINATION_REASON_OPTIMAL).
LIMIT_UNDETERMINED	Le résolveur sous-jacent n'indique pas quelle limite a été atteinte.
LIMIT_ITERATION	Un algorithme itératif s'est arrêté après avoir effectué le nombre maximal d'itérations (par exemple, itérations simplex ou barrière).
LIMIT_TIME	L'algorithme s'est arrêté après un temps de calcul spécifié par l'utilisateur.
LIMIT_NODE	Un algorithme lié aux branches et à la branche s'est arrêté, car il a exploré un nombre maximal de nœuds dans l'arborescence liée aux branches et aux branches.
LIMIT_SOLUTION	L'algorithme s'est arrêté, car il a trouvé le nombre de solutions requis. Elle est souvent utilisée dans les MIP pour amener le résolveur à renvoyer la première solution réalisable qu'il rencontre.
LIMIT_MEMORY	L'algorithme s'est arrêté, car il était à court de mémoire.
LIMIT_CUTOFF	Le résolveur a été exécuté avec une limite (par exemple, SolveParameters.cutoff_limit a été définie) sur l'objectif, ce qui indiquait que l'utilisateur ne voulait pas de solution inférieure à la limite. Il en a conclu qu'il n'existait pas de solutions au moins aussi bonnes que la limite. En général, aucune autre information sur la solution n'est fournie.
LIMIT_OBJECTIVE	L'algorithme s'est arrêté, car il a trouvé une solution ou une limite supérieure à une limite définie par l'utilisateur (voir SolveParameters.objective_limit et SolveParameters.best_bound_limit).
LIMIT_NORM	L'algorithme s'est arrêté, car la norme d'une itération est devenue trop grande.
LIMIT_INTERRUPTED	L'algorithme s'est arrêté en raison d'un signal d'interruption ou d'une demande d'interruption utilisateur.
LIMIT_SLOW_PROGRESS	L'algorithme s'est arrêté, car il n'a pas pu continuer à progresser vers la solution.
LIMIT_OTHER	L'algorithme s'est arrêté en raison d'une limite non couverte par l'un des éléments ci-dessus. Notez que LIMIT_UNDETERMINED est utilisé lorsque le motif ne peut pas être déterminé, et LIMIT_OTHER est utilisé lorsque la raison est connue, mais qu'elle ne correspond à aucune des alternatives ci-dessus. La valeur terminationProto.detail peut contenir des informations supplémentaires sur la limite.

LinearConstraintsProto

Comme indiqué ci-dessous, nous définissons "#linear contraintes" = size(LinearConstraintsProto.ids).

Champs
ids[]	int64 La valeur ne doit pas être négative et doit augmenter considérablement. Impossible d'utiliser la valeur max(int64).
lower_bounds[]	double La longueur doit être égale à la contrainte #linear, les valeurs sont comprises dans [-inf, inf).
upper_bounds[]	double La longueur doit être égale à celle des contraintes #linear, et les valeurs doivent être comprises dans (-inf, inf].
names[]	string Si cette valeur n'est pas définie, on considère qu'il s'agit de chaînes vides. Sinon, la longueur doit être égale à celle des contraintes #linear. Tous les noms non vides doivent être distincts.

LinearExpressionProto

Représentation creuse d'une expression linéaire (somme pondérée de variables plus un décalage constant).

Champs
ids[]	int64 Identifiants des variables. Doit être trié (par ordre croissant) avec tous les éléments distincts.
coefficients[]	double La longueur doit être égale à celle des identifiants. Les valeurs doivent être finies et ne pas être définies sur "NaN".
offset	double Doit être finie et ne peut pas être NaN.

ModelProto

Problème d'optimisation. MathOpt prend en charge: - Variables de décision continues et entières avec des limites finies facultatives – Objectifs linéaires et quadratiques (un ou plusieurs), minimisés ou maximisés - Plusieurs types de contraintes, y compris: * Contraintes linéaires * Contraintes quadratiques * Contraintes cônes de deuxième ordre * Contraintes logiques > Contraintes SOS1 et SOS2 > Contraintes indicateurs

Par défaut, les contraintes sont représentées dans les cartes "id-to-data". Cependant, nous représentons les contraintes linéaires dans un format "struct de tableaux" plus efficace.

Champs
name	string
variables	VariablesProto
objective	ObjectiveProto Objectif principal du modèle.
auxiliary_objectives	map<int64, ObjectiveProto> Objectifs auxiliaires à utiliser dans les modèles multi-objectifs. Les ID de clé de mappage doivent être compris entre [0, max(int64)). Chaque priorité, et chaque nom non vide, doit être unique et distinct de l'objective principal.
linear_constraints	LinearConstraintsProto
linear_constraint_matrix	SparseDoubleMatrixProto Coefficients variables des contraintes linéaires. Si une variable impliquée dans cette contrainte est supprimée, elle est traitée comme si elle était définie sur zéro. Exigences: * linear_constraint_matrix.row_ids est un élément de linear_constraints.ids. * linear_constraint_matrix.column_ids est des éléments de variables.ids. * Les entrées de la matrice non spécifiées sont égales à zéro. * linear_constraint_matrix.values doit tous être finis.
quadratic_constraints	map<int64, QuadraticConstraintProto> Contraintes quadratiques dans le modèle.
second_order_cone_constraints	map<int64, SecondOrderConeConstraintProto> Les contraintes de cône de deuxième ordre dans le modèle.
sos1_constraints	map<int64, SosConstraintProto> Contraintes SOS1 dans le modèle, qui limitent au maximum une valeur expression pouvant être non nulle. Les entrées weights facultatives sont un détail d'implémentation utilisé par le résolveur pour (idéalement) converger plus rapidement. Plus précisément, les résolveurs peuvent (ou non) utiliser ces pondérations pour sélectionner des ramifications qui produisent des nœuds enfants "équilibrés".
sos2_constraints	map<int64, SosConstraintProto> Les contraintes SOS2 dans le modèle, qui limitent au maximum deux entrées de expression peuvent être différentes de zéro et doivent être adjacentes dans leur ordre. Si aucun weights n'est fourni, cet ordre correspond à leur ordre linéaire dans la liste expressions. Si des weights sont présentées, l'ordre est effectué par rapport à ces valeurs par ordre croissant.
indicator_constraints	map<int64, IndicatorConstraintProto> Contraintes d'indicateur dans le modèle, qui imposent que, si une "variable d'indicateur" binaire est définie sur un, une "contrainte implicite" doit être respectée.

ModelSolveParametersProto

Champs
variable_values_filter	SparseVectorFilterProto Filtre appliqué à tous les conteneurs creux renvoyés associés à des variables dans PrimalSolutionProto et PrimalRayProto (PrimalSolutionProto.variable_values, PrimalRayProto.variable_values). Conditions requises: * filter_ids sont des éléments de VariablesProto.ids.
dual_values_filter	SparseVectorFilterProto Filtre appliqué à tous les conteneurs creux renvoyés associés à des contraintes linéaires dans DualSolutionProto et DualRay (DualSolutionProto.dual_values, DualRay.dual_values). Exigences: * filter_ids sont des éléments des LinearConstraints.ids.
reduced_costs_filter	SparseVectorFilterProto Filtre appliqué à tous les conteneurs creux renvoyés associés à des variables dans DualSolutionProto et DualRay (DualSolutionProto.reduced_costs, DualRay.reduced_costs). Conditions requises: * filter_ids sont des éléments de VariablesProto.ids.
initial_basis	BasisProto Base initiale facultative pour les résolveurs de page de destination simplex à démarrage tiède. S'il est défini, il devrait être valide selon ValidateBasis dans validators/solution_validator.h pour le ModelSummary actuel.
solution_hints[]	SolutionHintProto Suggestions de solution facultatives. Si le résolveur sous-jacent n'accepte qu'un seul indice, le premier est utilisé.
branching_priorities	SparseInt32VectorProto Priorités de branchement facultatives. Les variables dont les valeurs sont supérieures seront remplacées par des branches. Les variables pour lesquelles des priorités ne sont pas définies obtiennent la priorité par défaut du résolveur (généralement zéro). Conditions requises: * branching_priorities.values doit être fini. * branching_priorities.ids doit être des éléments de VariablesProto.ids.

ObjectiveBoundsProto

Limites par rapport à la valeur d'objectif optimale.

Champs
primal_bound	double Le résolveur affirme que la valeur optimale est égale ou supérieure (plus petite pour la minimisation et plus grande pour l'optimisation) que primal_bound jusqu'à la tolérance de faisabilité primaire du résolveur (voir l'avertissement ci-dessous): * primal_bound est mineur (+inf pour la minimisation et maximisation -inf) lorsque le résolveur ne prétend pas avoir une telle limite. * primal_bound peut être plus proche de la valeur optimale que l'objectif de la meilleure solution primaire réalisable. En particulier, primal_bound peut être non trivial même si aucune solution primal réalisable n'est renvoyée. Avertissement: L'affirmation précise qu'il existe une solution primaire: * est réalisable numériquement (c'est-à-dire réalisable jusqu'à la tolérance du résolveur), et * a une valeur objective primal_bound. Cette solution réalisable sur le plan numérique peut s'avérer légèrement irréalisable. Dans ce cas, primal_bound peut être strictement supérieur à la valeur optimale. Traduire une tolérance de faisabilité primaire à une tolérance à primal_bound n'est pas simple, en particulier lorsque la tolérance de faisabilité est relativement élevée (par exemple, lors d'une résolution avec PDLP).
dual_bound	double Le résolveur affirme que la valeur optimale est égale ou inférieure (plus élevée pour la minimisation et inférieure pour l'optimisation) à la tolérance de duel_bound à la double faisabilité du résolveur (voir l'avertissement ci-dessous): * dual_bound est insignifiant (-inf pour la minimisation et +inf pour la maximisation) lorsque le résolveur ne prétend pas avoir une telle limite. Comme pour primal_bound, cela peut se produire pour certains résolveurs, même en cas de renvoi optimal. Les résolveurs MIP signalent généralement une limite, même si elle est imprécise. * Pour les problèmes continus, le paramètre "dual_bound" peut être plus proche de la valeur optimale que l'objectif de la meilleure solution du double réalisable. Pour MIP, l'une des premières valeurs non significatives de double_bound est souvent la valeur optimale de l'assouplissement LP de la MIP. * dual_bound devrait être meilleur (plus petit pour la minimisation et plus grand pour l'optimisation) que primal_bound jusqu'aux tolérances du résolveur (voir l'avertissement ci-dessous). Avertissement: * Pour les problèmes continus, l'affirmation exacte est qu'il existe une double solution qui: * est réalisable numériquement (c'est-à-dire réalisable jusqu'à la tolérance du résolveur), et * a une valeur objective double_bound. Cette solution réalisable numériquement pourrait être légèrement irréalisable, auquel cas double_bound pourrait être strictement pire que la valeur optimale et primal_bound. Tout comme dans le cas primaire, traduire une double tolérance de faisabilité en tolérance double_bound n'est pas une mince affaire, en particulier lorsque la tolérance de faisabilité est relativement élevée. Cependant, certains résolveurs fournissent une version corrigée de double_bound qui peut être numériquement plus sûre. Cette version corrigée est accessible via la sortie spécifique du résolveur (par exemple, pour PDLP, pdlp_output.convergence_information.corrected_dual_objective). * Pour les résolveurs MIP, la valeur "dual_bound" peut être associée à une double solution pour un certain relâchement continu (ex. : assouplissement de la LP). Toutefois, elle est souvent une conséquence complexe de l'exécution des résolveurs. Elle est généralement plus imprécise que les limites indiquées par les résolveurs LP.

ObjectiveProto

Champs
maximize	bool "false" pour minimiser, "true" pour "maximiser"
offset	double Doit être finie et non NaN.
linear_coefficients	SparseDoubleVectorProto Termes ObjectiveProto linéaires dans les variables de décision. Conditions requises: * Les linear_coefficients.ids sont des éléments de VariablesProto.ids. * VariablesProto non spécifiée correspond à zéro. * Les valeurs de linear_coefficients.values doivent toutes être finies. * La valeur de linear_coefficients.values peut être nulle, mais cela ne fait que gaspiller de l'espace.
quadratic_coefficients	SparseDoubleMatrixProto Termes objectifs quadratiques dans les variables de décision. Exigences en plus de celles concernant les messages SparseDoubleMatrixProto: * Chaque élément de quadratic_coefficients.row_ids et chaque élément de quadratic_coefficients.column_ids doit être un élément de VariablesProto.ids. * La matrice doit être de type triangulaire supérieur: pour chaque i, quadratic_coefficients.row_ids[i] <= quadratic_coefficients.column_ids[i]. Remarques: * Les termes qui ne sont pas stockés explicitement ont un coefficient zéro. * Les éléments de quadratic_coefficients.coefficients peuvent être nuls, mais cela ne fait que gaspiller de l'espace.
name	string Les messages parents peuvent présenter des exigences d'unicité dans ce champ ; par exemple, voir ModelProto.objectives et AuxiliaryObjectivesUpdatesProto.new_objectives.
priority	int64 Pour les problèmes à plusieurs objectifs, la priorité de cet objectif par rapport aux autres (la priorité la plus faible est la plus élevée). Cette valeur ne doit pas être négative. De plus, chaque priorité objective dans le modèle doit être distincte au moment de la résolution. Cette condition n'est pas validée au niveau du prototype. Par conséquent, des modèles peuvent temporairement avoir des objectifs avec la même priorité.

PrimalRayProto

Direction d'amélioration illimitée d'un problème d'optimisation ; équivalent : un certificat d'infaisabilité pour la double du problème d'optimisation.

Prenons l'exemple d'un programme linéaire simple: min c * x s.t. A * x >= b x >= 0 Un rayon primale est un x qui satisfait: c * x < 0 A * x >= 0 x >= 0. Observer qu'à partir d'une solution réalisable, tout multiple positif de la solution est un multiple positif de la solution. Un rayon primale prouve également que le problème de double optimisation est irréalisable.

Dans le message PrimalRay ci-dessous, variable_values est x.

Champs
variable_values	SparseDoubleVectorProto Conditions requises: * variable_values.ids sont des éléments de VariablesProto.ids. * Les valeurs de variable_values.values doivent toutes être finies.

PrimalSolutionProto

Solution à un problème d'optimisation

Prenons l'exemple d'un programme linéaire simple: min c * x s.t. A * x >= b x >= 0. Une solution primaire consiste à attribuer des valeurs à x. Elle est réalisable si elle satisfait aux critères A * x >= b et x >= 0 ci-dessus. Dans le message PrimalSolutionProto ci-dessous, variable_values est x et objectif_value est c * x.

Champs
variable_values	SparseDoubleVectorProto Conditions requises: * variable_values.ids sont des éléments de VariablesProto.ids. * Les valeurs de variable_values.values doivent toutes être finies.
objective_value	double Valeur d'objectif calculée par le résolveur sous-jacent. Ne peut pas être infini ni NaN.
auxiliary_objective_values	map<int64, double> Valeurs d'objectif auxiliaire calculées par le résolveur sous-jacent. Les clés doivent être des ID d'objectifs auxiliaires valides. Les valeurs ne peuvent pas être infinies ni NaN.
feasibility_status	SolutionStatusProto État de faisabilité de la solution selon le résolveur sous-jacent.

ProblemStatusProto

État de faisabilité du problème primaire et de son duel (ou le double d'un assouplissement continu), selon les affirmations du résolveur. Le résolveur n'est pas tenu de renvoyer un certificat pour la réclamation (par exemple, il peut revendiquer la faisabilité primaire sans renvoyer de solution primitive). Cet état combiné donne une description complète des affirmations d'un résolveur sur la faisabilité et le caractère illimité du problème résolu. Par exemple :

• Un état réalisable pour des problèmes primaires et doubles indique que le premier est réalisable et limité, et qu'il offre probablement une solution optimale (garanti pour les problèmes sans contraintes non linéaires).
• le statut "primal possible" et le statut "double infaisable" indiquent que le problème primaire est illimité (c'est-à-dire que des solutions arbitrairement bonnes sont disponibles).

Notez qu'un double statut d'impossibilité en soi (c'est-à-dire accompagné d'un statut primaire non déterminé) n'implique pas que le problème primaire est illimité, car les deux problèmes pourraient être impossibles à résoudre. En outre, bien qu'un statut primaire et double réalisable puisse impliquer l'existence d'une solution optimale, cela ne garantit pas que le résolveur a trouvé une solution aussi optimale.

Champs
primal_status	FeasibilityStatusProto État du problème principal.
dual_status	FeasibilityStatusProto État du double problème (ou du duel d'un assouplissement continu).
primal_or_dual_infeasible	bool Si la valeur est "true", le résolveur affirme que le problème primaire ou double est irréalisable, mais il ne sait pas lequel (ou si les deux sont irréalisables). Ne peut être "true" que lorsque primal_problem_status = dual_problem_status = kUndéterminé. Ces informations supplémentaires sont souvent nécessaires lorsque le prétraitement détermine qu'il n'existe pas de solution optimale au problème (mais qu'il est impossible de déterminer si le problème est dû à une impossibilité, à une infinité ou aux deux).

QuadraticConstraintProto

Une seule contrainte quadratique sous la forme: lb <= sum{linear_terms} + sum{quadratic_terms} <= ub.

Si une variable impliquée dans cette contrainte est supprimée, elle est traitée comme si elle était définie sur zéro.

Champs
linear_terms	SparseDoubleVectorProto Termes linéaires dans les variables de décision. En plus des exigences relatives aux messages SparseDoubleVectorProto: * linear_terms.ids sont des éléments de VariablesProto.ids. * Les valeurs "linear_terms.values" doivent toutes être finies et non "NaN". Remarques: * Les identifiants de variable omises sont associés à un coefficient zéro. * La valeur linear_terms.values peut être nulle, mais cela ne fait que gaspiller de l'espace.
quadratic_terms	SparseDoubleMatrixProto Termes quadratiques dans les variables de décision. En plus des exigences relatives aux messages SparseDoubleMatrixProto: * Chaque élément de quadratic_terms.row_ids et chaque élément de quadratic_terms.column_ids doit être un élément de VariablesProto.ids. * La matrice doit être de type triangulaire supérieur: pour chaque i, quadratic_terms.row_ids[i] <= quadratic_terms.column_ids[i]. Remarques: * Les termes qui ne sont pas stockés explicitement ont un coefficient zéro. * Les éléments de quadratic_terms.coefficients peuvent être nuls, mais cela ne fait que gaspiller de l'espace.
lower_bound	double Doit avoir une valeur entre [-inf, inf) et inférieure ou égale à upper_bound.
upper_bound	double Doit avoir une valeur entre (-inf, inf] et supérieure ou égale à lower_bound.
name	string Les messages parents peuvent présenter des exigences d'unicité dans ce champ ; par exemple, voir ModelProto.quadratic_constraints et QuadraticConstraintUpdatesProto.new_constraints.

SecondOrderConeConstraintProto

Une seule contrainte de cône de deuxième ordre sous la forme:

||arguments_to_norm||_2 <= upper_bound,

où upper_bound et chaque élément de arguments_to_norm sont des expressions linéaires.

Si une variable impliquée dans cette contrainte est supprimée, elle est traitée comme si elle était définie sur zéro.

Champs
upper_bound	LinearExpressionProto
arguments_to_norm[]	LinearExpressionProto
name	string Les messages parents peuvent présenter des exigences d'unicité dans ce champ (voir ModelProto.second_order_cone_constraints et SecondOrderConeConstraintUpdatesProto.new_constraints, par exemple).

SolutionHintProto

Solution de départ suggérée pour le résolveur.

Les résolveurs MIP ne veulent généralement que des informations primaires (variable_values), tandis que les résolveurs LP veulent des informations à la fois primaires et doubles (dual_values).

De nombreux résolveurs MIP peuvent fonctionner avec: (1) des solutions partielles qui ne spécifient pas toutes les variables ou (2) des solutions non réalisables. Dans ce cas, les solvants résolvent généralement un sous-MIP pour compléter/corriger l'indice.

La façon dont l'indice est utilisé par le résolveur dépend fortement du résolveur, du type de problème et de l'algorithme utilisé. Le moyen le plus fiable de vous assurer que votre indice est pris en compte consiste à lire les journaux des solutions sous-jacentes avec et sans cet indice.

Les solvants LP basés sur simplex préfèrent généralement une base initiale à un indice de solution (ils doivent effectuer un croisement pour convertir l'indice en solution réalisable de base dans le cas contraire).

Champs
variable_values	SparseDoubleVectorProto Attribution potentiellement partielle de valeurs aux variables primaires du problème. Les exigences indépendantes du résolveur pour ce sous-message sont les suivantes: * variable_values.ids sont des éléments de VariablesProto.ids. * Les valeurs de variable_values.values doivent toutes être finies.
dual_values	SparseDoubleVectorProto Attribution (potentiellement partielle) de valeurs aux contraintes linéaires du problème. Exigences: * dual_values.ids sont des éléments de LinearConstraintsProto.ids. * dual_values.values doivent tous être finis.

SolutionProto

Le contenu d'une solution dépend du type de problème et de solution. Les modèles communs actuels sont 1. Les solutions MIP ne renvoient qu'une solution primaire. 2. Les résolveurs LP simplex renvoient souvent une base ainsi que les solutions primaires et doubles associées à cette base. 3. D'autres résolveurs continus renvoient souvent une solution primale et double qui est connectée sous une forme dépendante du résolveur.

Conditions requises: * Vous devez renseigner au moins un champ. Vous devez indiquer une solution.

Champs
primal_solution	PrimalSolutionProto
dual_solution	DualSolutionProto
basis	BasisProto

SolutionStatusProto

Faisabilité d'une solution primaire ou double, selon la proposition du résolveur.

Enums
SOLUTION_STATUS_UNSPECIFIED	Valeur de garde représentant aucun état.
SOLUTION_STATUS_UNDETERMINED	Le résolveur ne revendique pas l'état de faisabilité.
SOLUTION_STATUS_FEASIBLE	Le résolveur affirme que la solution est réalisable.
SOLUTION_STATUS_INFEASIBLE	Le résolveur affirme que la solution est irréalisable.

SolveParametersProto

Paramètres permettant de contrôler une seule résolution.

Contient les deux paramètres communs à tous les résolveurs (par exemple, time_limit) et les paramètres d'un résolveur spécifique (par exemple, gscip). Si une valeur est définie à la fois dans le champ "commun et spécifique au résolveur", le paramètre propre au résolveur est utilisé.

Les paramètres courants qui sont facultatifs et non définis, ou une énumération dont la valeur n'est pas spécifiée, indiquent que la valeur par défaut du résolveur est utilisée.

Les paramètres spécifiques aux résolveurs autres que celui utilisé sont ignorés.

Les paramètres qui dépendent du modèle (par exemple, la priorité de branchement est définie pour chaque variable) sont transmis dans ModelSolveParametersProto.

Champs
time_limit	Duration Temps maximal qu'un résolveur doit consacrer au problème (ou infinie s'il n'est pas défini). Cette valeur n'est pas une limite stricte. Le temps de résolution peut être légèrement supérieur à cette valeur. Ce paramètre est toujours transmis au résolveur sous-jacent. La valeur par défaut du résolveur n'est pas utilisée.
enable_output	bool Active l'impression des traces d'implémentation du résolveur. L'emplacement de ces traces dépend du résolveur. Pour SCIP et Gurobi, il s'agit des flux de sortie standards. Pour Glop et CP-SAT, LOG(INFO). Notez que si le résolveur prend en charge le rappel de message et que l'utilisateur en enregistre un, cette valeur de paramètre est ignorée et aucune trace n'est imprimée.
lp_algorithm	LPAlgorithmProto Algorithme permettant de résoudre un programme linéaire. Si la valeur est LP_ALGORITHM_UNSPECIFIED, utilisez l'algorithme par défaut du résolveur. Pour les problèmes qui ne sont pas des programmes linéaires, mais où la programmation linéaire est une sous-routine, les résolveurs peuvent utiliser cette valeur. Par exemple, les résolveurs MIP ne l'utilisent généralement que pour la résolution LP racine (et utilisent le double simplex dans le cas contraire).
presolve	EmphasisProto Effort à fournir pour simplifier le problème avant de démarrer l'algorithme principal, ou niveau d'effort par défaut du résolveur s'il est indiqué comme étant {8/}_UNSPECIFIED (NON SPÉCIFIÉ).
cuts	EmphasisProto Effort à fournir pour renforcer l'assouplissement de la LP (MIP uniquement) ou niveau d'effort par défaut du résolveur s'il est défini sur {8/}_UNSPECIFIED. REMARQUE: La désactivation des coupures peut empêcher les rappels d'ajouter des coupures au nœud MIP_NODE. Ce comportement est spécifique au résolveur.
heuristics	EmphasisProto Effort à fournir pour trouver des solutions réalisables au-delà de celles rencontrées dans la procédure de recherche complète (MIP uniquement), ou niveau d'effort par défaut du résolveur si {8/}_UNSPECIFIED (NON SPÉCIFIÉ).
scaling	EmphasisProto Tentative de remise à l'échelle du problème afin d'améliorer la stabilité numérique, ou niveau d'effort par défaut du résolveur si =\"_UNSPECIFIED (non spécifié).
iteration_limit	int64 Limitez les itérations de l'algorithme sous-jacent (par exemple, les tableaux croisés dynamiques en simplex). Le comportement spécifique dépend du résolveur et de l'algorithme utilisés, mais il peut souvent donner une limite de résolution déterministe (une configuration supplémentaire peut être nécessaire, par exemple un thread). Généralement compatible avec les résolveurs LP, QP et MIP, mais pour les résolveurs MIP, voir aussi node_limit.
node_limit	int64 Limite le nombre de sous-problèmes résolus dans la recherche énumérative (par exemple, branche et lié). De nombreux résolveurs permettent de limiter le calcul de manière déterministe (une configuration supplémentaire peut être nécessaire, par exemple un thread). En règle générale, pour les résolveurs MIP, consultez également la section itérative_limit.
cutoff_limit	double Le résolveur s'arrête prématurément s'il peut prouver qu'il n'existe pas de solutions primaires au moins aussi efficaces que la limite. Lors d'un arrêt prématuré, le résolveur renvoie le motif d'arrêt NO_SOLUTION_FOUND avec une limite CUTOFF et n'a pas besoin de fournir d'informations supplémentaires sur la solution. N'a aucun effet sur la valeur renvoyée s'il n'y a pas d'arrêt anticipé. Il est recommandé d'utiliser une tolérance si vous souhaitez que des solutions dont l'objectif est exactement égal à la limite soient renvoyées. Consultez le guide de l'utilisateur pour en savoir plus et pour comparer la valeur "best_bound_limit".
objective_limit	double Le résolveur s'arrête tôt dès qu'il trouve une solution au moins aussi performante, avec un motif d'arrêt FAIBLE et la limite OBJECTIF.
best_bound_limit	double Le résolveur s'arrête tôt dès qu'il s'avère que la meilleure limite est au moins cette bonne, avec le motif d'arrêt FEASIBLE ou NO_SOLUTION_FOUND et la limite OBJECTIVE. Consultez le guide de l'utilisateur pour en savoir plus et pour comparer les valeurs de cutoff_limit.
solution_limit	int32 Le résolveur s'arrête tôt après avoir trouvé autant de solutions réalisables, avec un motif d'arrêt FAIBLE et une limite de SOLUTION. Doit être supérieur à zéro si défini. Il est souvent utilisé pour que le résolveur s'arrête sur la première solution réalisable trouvée. Notez que la valeur d'objectif n'est pas garantie pour les solutions renvoyées. Les résolveurs ne renvoient généralement pas plus de solutions que la limite de la solution, mais cela n'est pas appliqué par MathOpt (voir également b/214041169). Actuellement compatible avec Gurobi et SCIP, et CP-SAT uniquement avec la valeur 1.
threads	int32 S'il est défini, il doit être >= 1.
random_seed	int32 Valeur initiale du générateur de nombres pseudo-aléatoires dans le résolveur sous-jacent. Notez que tous les résolveurs utilisent des nombres pseudo-aléatoires pour sélectionner des éléments tels que la perturbation dans l'algorithme LP, pour les règles de répartition et pour les corrections heuristiques. Cela peut avoir un impact notable sur le comportement des résolveurs. Bien que tous les résolveurs aient le concept de valeurs initiales, notez que les valeurs valides dépendent du résolveur réel. - Gurobi: [0:GRB_MAXINT] (qui correspond à 2 x 10^9 à partir de Gurobi 9.0) - GSCIP: [0:2147483647] (qui correspond à MAX_INT ou kint32max ou 2^31-1) - GLOP: [0:2147483647] (identique à la table ci-dessus). Dans tous les cas, le résolveur recevra une valeur égale à: MAX(0, MIN(MAX_VALID_VALUE_FOR_SOLVER, random_seed)).
absolute_gap_tolerance	double Tolérance d'optimisation absolue (principalement) pour les résolveurs MIP. L'écart absolu correspond à la valeur absolue de la différence entre: * la valeur objectif de la meilleure solution réalisable trouvée, * la double limite produite par la recherche. Le résolveur peut s'arrêter une fois que l'écart absolu a atteint la valeur de absolute_gap_false (lorsqu'il est défini) et renvoyer TERMINATION_REASON_OPTIMAL. Doit être >= 0 si défini. Voir aussi relative_gap_quality.
relative_gap_tolerance	double Tolérance d'optimisation relative (principalement) pour les résolveurs MIP. Le GAP relatif est une version normalisée de la GAP absolue (définie sur absolute_gap_false), où la normalisation est dépendante du résolveur, c'est-à-dire la GAP absolue divisée par la valeur objectif de la meilleure solution réalisable trouvée. Le résolveur peut s'arrêter une fois que la GAP relative atteint la valeur relative la plus large (lorsque cette valeur est définie) et renvoyer la valeur TERMINATION_REASON_OPTIMAL. Doit être >= 0 si défini. Voir aussi absolute_gap_absolute.
solution_pool_size	int32 Gérez jusqu'à solution_pool_size solutions pendant vos recherches. Le pool de solutions a généralement deux fonctions: (1) Pour les résolveurs pouvant renvoyer plusieurs solutions, cela limite le nombre de solutions renvoyées. (2) Certains résolveurs peuvent exécuter des méthodes heuristiques à l'aide de solutions du pool de solutions. Par conséquent, la modification de cette valeur peut affecter le chemin de l'algorithme. Pour forcer le résolveur à remplir le pool de solutions, par exemple avec les n meilleures solutions, vous devez disposer d'une configuration plus poussée et spécifique au résolveur.

SolveResultProto

Le contrat lorsque les solutions/rayons primal/duels sont complexes, voir termination_reasons.md pour une description complète.

Jusqu'à ce qu'un contrat exact soit finalisé, il est plus sûr de simplement vérifier si une solution/rayon est présent plutôt que de s'appuyer sur le motif de résiliation.

Champs
termination	TerminationProto Motif pour lequel le résolveur s'est arrêté.
solutions[]	SolutionProto Le contrat général concernant l'ordre des solutions que les futurs résolveurs doivent mettre en œuvre est de classer par: 1. Les solutions avec une solution réalisable primaire, classées en premier par le meilleur objectif primaire. 2. Les solutions avec une double solution réalisable, classées selon le meilleur double objectif (le double objectif inconnu est le pire) 3. Toutes les solutions restantes peuvent être renvoyées dans n'importe quel ordre.
primal_rays[]	PrimalRayProto Instructions d'amélioration primaire illimitée, ou certificats de double infaisabilité. Généralement fourni pour CompletedReasonProtos UNBOUNDED et DUAL_INFEASIBLE
dual_rays[]	DualRayProto Directives de la double amélioration illimitée ou, équivalentes, de certificats d'infaisabilité primaires. Généralement fourni pour CompletedReasonProto INFEASIBLE.
solve_stats	SolveStatsProto Statistiques sur le processus de résolution, telles que la durée d'exécution et les itérations.

SolveStatsProto

Champs
solve_time	Duration Durée d'exécution écoulée, telle que mesurée par math_opt, à peu près la durée dans Solver::Solve(). Remarque: cela n'inclut pas le travail de création du modèle.
problem_status	ProblemStatusProto États de faisabilité pour les problèmes primaires et doubles.
simplex_iterations	int64
barrier_iterations	int64
first_order_iterations	int64
node_count	int64

SolverTypeProto

Les résolveurs acceptés par MathOpt.

Enums
SOLVER_TYPE_UNSPECIFIED
SOLVER_TYPE_GSCIP	Résoudre des problèmes de programmes entiers de contraintes (SCIP) (tiers). Prise en charge des problèmes quadratiques à nombres entiers (LP, MIP) et non convexes. Toutefois, aucune donnée double pour les pages de destination n'est renvoyée. Choisissez GLOP pour les pages de destination.
SOLVER_TYPE_GUROBI	Solution Gurobi (tiers). Prise en charge des problèmes quadratiques à nombres entiers (LP, MIP) et non convexes. Il s'agit généralement de l'option la plus rapide, mais elle est associée à une licence spéciale.
SOLVER_TYPE_GLOP	l'outil Glop de Google. Prise en charge de la LP avec les méthodes primal et double simplex.
SOLVER_TYPE_CP_SAT	l'outil CP-SAT de Google. Prise en charge des problèmes où toutes les variables sont des nombres entiers et limitées (ou implicitement après la presolve). Prise en charge expérimentale du redimensionnement et de la discrétisation des problèmes à l'aide de variables continues.
SOLVER_TYPE_PDLP	Outil de résolution des problèmes liés à la protection contre la perte de données (PDLP) de Google Compatible avec les objectifs quadratiques en diagonale et en LP et les objectifs quadratiques convexes en diagonale. Utilise des méthodes du premier ordre plutôt que simplex. Peut résoudre de très gros problèmes.
SOLVER_TYPE_GLPK	GNU Linear Programming Kit (GLPK) (tiers). Compatible avec MIP et LP. Sécurité des threads: GLPK utilise le stockage local au thread pour les allocations de mémoire. Par conséquent, les instances du résolveur doivent être détruites sur le même thread que lors de leur création, sans quoi GLPK plante. Il semble acceptable d'appeler Solver::Solve() à partir d'un autre thread que celui utilisé pour créer le résolveur, mais il n'est pas documenté par GLPK et doit être évité. Lors de la résolution d'une LP avec le prérésolveur, une solution (et les rayons non liés) n'est renvoyée que si une solution optimale a été trouvée. Sinon, rien n'est renvoyé. Pour plus d'informations, consultez la page glpk-5.0/doc/glpk.pdf page 40 disponible à l'adresse glpk-5.0.tar.gz.
SOLVER_TYPE_OSQP	Le résolveur de programmes quadratiques de fractionnement par l'opérateur (OSQP, Operator Splitting Quadratic Program) (tiers). Prise en charge des problèmes continus comportant des contraintes linéaires et des objectifs quadratiques linéaires ou convexes. Utilise une méthode du premier ordre.
SOLVER_TYPE_ECOS	Le solutionneur de conique intégré (ECOS) (tiers). Prise en charge des problèmes LP et SOCP. Utilise des méthodes de point intérieur (barrière).
SOLVER_TYPE_SCS	Le résolveur de conique de fractionnement (SCS) (tiers). Prise en charge des problèmes LP et SOCP. Utilise une méthode du premier ordre.
SOLVER_TYPE_HIGHS	Le résolveur HiGHS (tiers). Prise en charge des problèmes LP et MIP (les QP convexes ne sont pas implémentés).
SOLVER_TYPE_SANTORINI	Implémentation de référence d'un résolveur MIP par MathOpt. Lenteur/déconseillé pour la production. Il ne s'agit pas d'un outil de résolution de la page de destination (aucune double information renvoyée).

SosConstraintProto

Données représentant une seule contrainte SOS1 ou SOS2.

Si une variable impliquée dans cette contrainte est supprimée, elle est traitée comme si elle était définie sur zéro.

Champs
expressions[]	LinearExpressionProto Expressions sur lesquelles appliquer la contrainte SOS: * SOS1: un élément au maximum a une valeur non nulle. * SOS2: au maximum deux éléments ont des valeurs non nulles et doivent être adjacents dans l'ordre répété.
weights[]	double Soit vide, soit de longueur égale aux expressions. Si ce champ est vide, les pondérations par défaut sont 1, 2, ... Si elles sont indiquées, les entrées doivent être uniques.
name	string Les messages parents peuvent présenter des exigences d'unicité sur ce champ ; par exemple, voir ModelProto.sos1_constraints et SosConstraintUpdatesProto.new_constraints.

SparseBasisStatusVector

Représentation creuse d'un vecteur d'états de base.

Champs
ids[]	int64 Doit être trié (par ordre croissant) avec tous les éléments distincts.
values[]	BasisStatusProto La longueur doit être égale à celle des identifiants.

SparseDoubleMatrixProto

Représentation creuse d'une matrice de doubles.

La matrice est stockée sous la forme de triples de l'ID de ligne, de l'ID de colonne et du coefficient. Ces trois vecteurs doivent être de longueur égale. Pour tous les i, le tuple (row_ids[i], column_ids[i]) doit être distinct. Les entrées doivent être dans l'ordre principal des lignes.

Champs
row_ids[]	int64
column_ids[]	int64
coefficients[]	double Peut ne pas contenir de valeur NaN.

SparseDoubleVectorProto

Représentation creuse d'un vecteur de doubles.

Champs
ids[]	int64 Doit être trié (par ordre croissant) avec tous les éléments distincts.
values[]	double La longueur doit être égale à celle des identifiants. Peut ne pas contenir de valeur NaN.

SparseInt32VectorProto

Représentation creuse d'un vecteur de nombres entiers.

Champs
ids[]	int64 Doit être trié (par ordre croissant) avec tous les éléments distincts.
values[]	int32 La longueur doit être égale à celle des identifiants.

SparseVectorFilterProto

Ce message permet d'interroger/de définir des parties spécifiques d'un vecteur SparseXxxxVector. Le comportement par défaut consiste à ne filtrer aucun élément. Une utilisation courante consiste à n'interroger que des parties des solutions (uniquement des valeurs non nulles et/ou un ensemble sélectionné manuellement de valeurs de variables).

Champs
skip_zero_values	bool Pour SparseBoolVectorProto, la valeur "zéro" est false.
filter_by_ids	bool Lorsque la valeur est "true", ne renvoie que les valeurs correspondant aux ID listés dans filter_ids.
filtered_ids[]	int64 Liste des ID à utiliser lorsque filter_by_ids est défini sur "true". Ce champ doit être vide lorsque filter_by_ids a la valeur "false". REMARQUE: Si ce champ est vide et que filter_by_ids est défini sur "true", vous indiquez que vous ne voulez aucune information dans le résultat.

TerminationProto

Toutes les informations concernant la raison pour laquelle un appel à Solve() a pris fin.

Champs
reason	TerminationReasonProto Informations supplémentaires dans limit lorsque la valeur est TERMINATION_REASON_FEASIBLE ou TERMINATION_REASON_NO_SOLUTION_FOUND. Consultez limit pour en savoir plus.
limit	LimitProto La valeur est LIMIT_UNSPECIFIED, sauf si le motif est TERMINATION_REASON_FEASIBLE ou TERMINATION_REASON_NO_SOLUTION_FOUND. Tous les résolveurs ne peuvent pas toujours déterminer la limite à l'origine de l'arrêt. La valeur LIMIT_UNDETERMINED est utilisée lorsque la cause ne peut pas être déterminée.
detail	string Informations supplémentaires sur la résiliation, généralement spécifiques au résolveur.
problem_status	ProblemStatusProto États de faisabilité pour les problèmes primaires et doubles. À compter du 18 juillet 2023, ce message pourrait être manquant. S'il est absent, le statut de problème se trouve dans SolveResultProto.solve_stats.
objective_bounds	ObjectiveBoundsProto Limites par rapport à la valeur d'objectif optimale. À compter du 18 juillet 2023, ce message pourrait être manquant. S'il n'est pas spécifié, "object_bounds.primal_bound" se trouve dans SolveResultProto.solve.stats.best_primal_bound, et "object_bounds.dual_bound" se trouve dans SolveResultProto.solve.stats.best_dual_bound.

TerminationReasonProto

La raison pour laquelle un appel à Solve() prend fin.

Enums
TERMINATION_REASON_UNSPECIFIED
TERMINATION_REASON_OPTIMAL	Une solution généralement optimale (jusqu'à des tolérances numériques) a été trouvée.
TERMINATION_REASON_INFEASIBLE	Le problème primaire n'a pas de solution réalisable.
TERMINATION_REASON_UNBOUNDED	Le problème primaire est réalisable et des solutions arbitrairement bonnes peuvent être trouvées à partir d'un rayon primal.
TERMINATION_REASON_INFEASIBLE_OR_UNBOUNDED	Le problème primaire est soit infaisable, soit illimité. Pour en savoir plus sur l'état du problème, consultez resolve_stats.problem_status. Notez que le statut illimité de Gurobi peut être mappé ici.
TERMINATION_REASON_IMPRECISE	Le problème a été résolu selon l'un des critères ci-dessus (optimal, infaisable, illimité, infaisible ou illimité), mais une ou plusieurs tolérances n'ont pas été respectées. Il existe des solutions ou rayons primaires/doubles, mais soit ils seront légèrement infaisables, soit (si le problème était presque optimal), il y aura peut-être un écart entre l'objectif de la meilleure solution et le meilleur objectif de la solution. Les utilisateurs peuvent toujours interroger des solutions/rayons primaires/doubles et des statistiques sur les solutions, mais ils sont responsables de l'imprécision numérique.
TERMINATION_REASON_FEASIBLE	L'optimiseur a atteint une certaine limite et une solution primaire réalisable est renvoyée. Consultez la section SolveResultProto.limit_detail pour obtenir une description détaillée du type de limite atteint.
TERMINATION_REASON_NO_SOLUTION_FOUND	L'optimiseur a atteint une certaine limite et n'a pas trouvé de solution primaire réalisable. Consultez la section SolveResultProto.limit_detail pour obtenir une description détaillée du type de limite atteint.
TERMINATION_REASON_NUMERICAL_ERROR	L'algorithme s'est arrêté, car il a rencontré une erreur numérique irrécupérable. Aucune information sur la solution n'est disponible.
TERMINATION_REASON_OTHER_ERROR	L'algorithme s'est arrêté en raison d'une erreur non couverte par l'un des états définis ci-dessus. Aucune information sur la solution n'est disponible.

VariablesProto

Comme indiqué ci-dessous, nous définissons "#variables" = size(VariablesProto.ids).

Champs
ids[]	int64 La valeur ne doit pas être négative et doit augmenter considérablement. Impossible d'utiliser la valeur max(int64).
lower_bounds[]	double La longueur doit être égale à #variables, valeurs comprises entre [-inf, inf).
upper_bounds[]	double La longueur doit être égale à #variables, valeurs comprises entre (-inf, inf].
integers[]	bool Doit avoir une longueur égale à #variables. La valeur est "false" pour les variables continues et "true" pour les variables entières.
names[]	string Si cette valeur n'est pas définie, on considère qu'il s'agit de chaînes vides. Sinon, sa longueur doit être égale à #variables. Tous les noms non vides doivent être distincts.