Package google.research.optimization.v1.mathopt

इंडेक्स

BasisProto

लीनियर प्रोग्राम के समाधान के लिए, इसे अलग-अलग कैटगरी में बांटा जाता है.

लीनियर प्रोग्राम को हल करने का सिंप्लेक्स तरीका, हमेशा "बुनियादी समाधान" देता है, जिसे आधार के ज़रिए कॉम्बिनेशन में बताया जा सकता है. आधार, हर वैरिएबल और लीनियर कंस्ट्रेंट के लिए BasisStatusProto असाइन करता है.

उदाहरण के लिए, एक स्टैंडर्ड फ़ॉर्म LP: कम से कम c * x s.t. A * x = b x >= 0 रखें, जिसमें कंस्ट्रेंट से ज़्यादा वैरिएबल और पूरी लाइन रैंक A है.

मान लें कि n वैरिएबल की संख्या और m लीनियर कंस्ट्रेंट की संख्या है. इस सवाल का सही जवाब इस तरह से बनाया जा सकता है: * सभी कंस्ट्रेंट के आधार पर तय की गई स्थिति 'ठीक की गई' होगी. * m वैरिएबल चुनें, ताकि A के कॉलम लीनियर तौर पर एक-दूसरे से अलग हों और 'BASIC' स्टेटस असाइन करें. * बचे हुए n - m वैरिएबल के लिए, AT_lower स्थिति असाइन करें.

इस आधार पर, A * x = b का यूनीक समाधान होता है. इसमें ऐसे सभी वैरिएबल होते हैं जिनका स्टेटस AT_ पूर्वानुमान की निचली सीमा (सभी शून्य) पर तय होता है. नतीजे के तौर पर मिलने वाले समाधान को बुनियादी व्यावहारिक समाधान कहा जाता है, अगर वह x >= 0 की वैल्यू भी दे देता है.

फ़ील्ड
constraint_status

SparseBasisStatusVector

पाबंदी के आधार की स्थिति.

ज़रूरी शर्तें: * expandt_status.ids, लीनियरConstraints.ids के बराबर है.
variable_status

SparseBasisStatusVector

वैरिएबल के आधार पर स्टेटस.

ज़रूरी शर्तें: * comet_status.ids, वैरिएबलsProto.ids के बराबर होते हैं.
basic_dual_feasibility

SolutionStatusProto

यह एक बेहतर सुविधा है जिसका इस्तेमाल MathOpt, बेहतर तरीके से काम करने वाले एलपी सलूशन की पहचान करने के लिए करता है. सबसे बेहतर समाधान की स्थिति हमेशा SOLUTION_STATUS_FEASIBLE होगी.

एक-तरफ़ा एलपी के लिए, यह इससे जुड़े ड्यूअल सॉल्यूशन की संभावना की स्थिति के बराबर होना चाहिए. दो-तरफ़ा LPs के लिए, कुछ किनारे के मामलों में यह अलग हो सकता है. उदाहरण के लिए, प्राइमल सिंप्लेक्स के साथ अधूरे समाधान.

अगर आप ModelSolveपैरामीटरsProto.Initial_basis के ज़रिए शुरुआत करने की जानकारी देते हैं, तो इस वैल्यू को अनदेखा कर दिया जाता है. यह सिर्फ़ SolutionProto.basis से मिली जानकारी के आधार पर काम करता है.

BasisStatusProto

एलपी के हिसाब से वैरिएबल/कंस्ट्रेंट की स्थिति.

Enums
BASIS_STATUS_UNSPECIFIED गार्ड की वैल्यू, कोई स्टेटस नहीं दिखा रही है.
BASIS_STATUS_FREE वैरिएबल/कंस्ट्रेंट मुफ़्त है (इसकी कोई सीमित सीमा नहीं है).
BASIS_STATUS_AT_LOWER_BOUND वैरिएबल/सीमा अपनी निचली सीमा पर है (जो सीमित होनी चाहिए).
BASIS_STATUS_AT_UPPER_BOUND वैरिएबल/सीमा अपनी ऊपरी सीमा पर है (जो सीमित होनी चाहिए).
BASIS_STATUS_FIXED_VALUE वैरिएबल/कंस्ट्रेंट में एक जैसी निचली और ऊपरी सीमाएं होती हैं.
BASIS_STATUS_BASIC वैरिएबल/कंस्ट्रेंट बेसिक होता है.

DualRayProto

ऑप्टिमाइज़ेशन, समस्या के दोहराव में बड़े पैमाने पर सुधार की दिशा; इसके बराबर, मामूली फ़ेलियर का सर्टिफ़िकेट.

उदाहरण के लिए, प्राइमल ड्यूअल पेयर लीनियर प्रोग्राम पेयर पर विचार करें: (Primal) (ड्यूअल) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. दोहरी रे (y, r) से मिलने वाली संतोषजनक: b * y > 0 y * A + r = 0 y, r >= 0 देखें कि (y, r) के पॉज़िटिव मल्टिपल को ड्यूअल फ़ीटेबल समाधान में जोड़ने से द्वैत व्यवहार की क्षमता बनी रहती है और मकसद में सुधार होता है (यह साबित करना कि ड्यूअल बाउंड नहीं है). ड्यूअल रे यह भी साबित करती है कि शुरुआती समस्या संभव नहीं है.

नीचे दिए गए DualRay मैसेज में, y Dual_values का इस्तेमाल किया गया है और r कम खर्च किया गया है.

फ़ील्ड
dual_values

SparseDoubleVectorProto

ज़रूरी शर्तें: * Dual_values.ids, लीनियरConstraints.ids के एलिमेंट हैं. * Dual_values.values का इस्तेमाल न किया जा सकता हो.
reduced_costs

SparseDoubleVectorProto

ज़रूरी शर्तें: * कम_costs.ids, वैरिएबलsProto.ids के एलिमेंट होते हैं. * कम की गई_costs.values सभी सीमित होनी चाहिए.

DualSolutionProto

ऑप्टिमाइज़ेशन सवालों के दोहराव का समाधान.

उदाहरण के लिए, प्राइमल ड्यूअल पेयर लीनियर प्रोग्राम पेयर पर विचार करें: (Primal) (ड्यूअल) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. दो समाधान को पेयर (y, r) कहते हैं. ऐसा सिर्फ़ तब किया जा सकता है, जब यह ऊपर दी गई (ड्यूअल) शर्तों को पूरा करता हो.

नीचे दिए गए मैसेज में, y Dual_values का इस्तेमाल किया गया है, r कम की गई लागत है, और b * y ऑब्जेक्टिव वैल्यू है.

फ़ील्ड
dual_values

SparseDoubleVectorProto

ज़रूरी शर्तें: * Dual_values.ids, लीनियरConstraints.ids के एलिमेंट हैं. * Dual_values.values का इस्तेमाल न किया जा सकता हो.
reduced_costs

SparseDoubleVectorProto

ज़रूरी शर्तें: * कम_costs.ids, वैरिएबलsProto.ids के एलिमेंट होते हैं. * कम की गई_costs.values सभी सीमित होनी चाहिए.
feasibility_status

SolutionStatusProto

दिए गए सॉल्वर के हिसाब से, सलूशन की संभावना का स्टेटस.
objective_value

double

EmphasisProto

किसी वैकल्पिक टास्क को हल करते समय, उस पर लागू की गई मेहनत का लेवल (इस्तेमाल करने के लिए SolveparametersProto देखें).

सॉल्वर सुविधा को कॉन्फ़िगर करने के लिए, प्रॉविज़निंग का इस्तेमाल इस तरह से किया जाता है: * अगर कोई सॉल्वर सुविधा काम नहीं करता है, तो सिर्फ़ वह सेटिंग मान्य रहेगी जिसकी जानकारी नहीं दी गई है. कोई भी अन्य सेटिंग आम तौर पर अमान्य आर्ग्युमेंट की गड़बड़ी होगी (कुछ सॉल्वर बंद भी स्वीकार कर सकते हैं). * अगर सॉल्वर इस सुविधा के साथ काम करता है: - अगर यह विकल्प 'जानकारी नहीं है' पर सेट है, तो डिफ़ॉल्ट के तौर पर इसका इस्तेमाल किया जाएगा. - जब सुविधा को बंद नहीं किया जा सकता, तो 'बंद करें' पर एक गड़बड़ी दिखेगी. - अगर यह सुविधा डिफ़ॉल्ट रूप से चालू रहती है, तो सॉल्वर को आम तौर पर MEDIUM के लिए मैप किया जाता है. - अगर सुविधा का इस्तेमाल किया जा सकता है, तो कम, मध्यम, और बहुत ज़्यादा इस्तेमाल करने से कभी भी गड़बड़ी नहीं दिखेगी और न ही वह सबसे बेहतर नतीजे देने वाली कार्रवाई में शामिल हो पाएगा.

Enums
EMPHASIS_UNSPECIFIED
EMPHASIS_OFF
EMPHASIS_LOW
EMPHASIS_MEDIUM
EMPHASIS_HIGH
EMPHASIS_VERY_HIGH

FeasibilityStatusProto

समस्या की संभावना का स्टेटस, जिसके लिए सॉल्वर का दावा किया गया है. हल करने वाले व्यक्ति के लिए, दावे का सर्टिफ़िकेट देना ज़रूरी नहीं होता है.

Enums
FEASIBILITY_STATUS_UNSPECIFIED गार्ड की वैल्यू, कोई स्टेटस नहीं दिखा रही है.
FEASIBILITY_STATUS_UNDETERMINED सॉल्वर किसी स्टेटस का दावा नहीं करता.
FEASIBILITY_STATUS_FEASIBLE सॉल्वर का दावा है कि सवाल हल किया जा सकता है.
FEASIBILITY_STATUS_INFEASIBLE सॉल्वर का दावा है कि समस्या को हल नहीं किया जा सकता.

IndicatorConstraintProto

इस फ़ॉर्म के सिंगल इंडिकेटर कंस्ट्रेंट को दिखाने के लिए डेटा: वैरिएबल(indicator_id) = (activate_on_zero ? 0 : 1) फीटिंग री लोअर_बाउंड <= एक्सप्रेशन <= अपर_बाउंड.

अगर इस कंस्ट्रेंट में शामिल कोई वैरिएबल (इंंडिकेटर या expression में दिखने वाला) मिटा दिया जाता है, तो उसे ऐसे माना जाता है जैसे उसे शून्य पर सेट किया गया हो. खास तौर पर, इंंडिकेटर वैरिएबल को मिटाने का मतलब है कि अगर activate_on_zero गलत है, तो इंडिकेटर कंस्ट्रेंट खाली है. साथ ही, यह भी कि अगर activate_on_zero सही है, तो यह लीनियर कंस्ट्रेंट के बराबर है.

फ़ील्ड
activate_on_zero

bool

अगर सही है, तो अगर इंडिकेटर वैरिएबल की वैल्यू 0 होती है, तो इंप्लिसिट कंस्ट्रेंट को होल्ड करना होगा. ऐसा न होने पर, अगर इंडिकेटर वैरिएबल की वैल्यू 1 होती है, तो इंप्लिसिट कंस्ट्रेंट को होल्ड करना होगा.
expression

SparseDoubleVectorProto

शामिल मॉडल के संबंध में एक मान्य लीनियर एक्सप्रेशन होना चाहिए: * SparseDoubleVectorProto पर बताई गई सभी शर्तें, * expression.values के सभी एलिमेंट सीमित होने चाहिए, * expression.ids VariablesProto.ids के सबसेट हैं.
lower_bound

double

[-inf, inf; में मान होना चाहिए); NaN नहीं हो सकता.
upper_bound

double

(-inf, inf] में मान होना चाहिए; NaN नहीं हो सकता.
name

string

इस फ़ील्ड में, पैरंट मैसेज के लिए ज़रूरी शर्तें हो सकती हैं. जैसे, ModelProto.indicator_constraints और IndicatorConstraintUpdatesProto.new_constraints देखें.
indicator_id

int64

बाइनरी वैरिएबल से जुड़ा आईडी या सेट नहीं किया गया. अगर यह नीति सेट नहीं है, तो इंडिकेटर कंस्ट्रेंट को अनदेखा कर दिया जाता है. अगर यह नीति सेट है, तो यह ज़रूरी है: * वैरिएबलsProto.integers[indicator_id] = true, * variablesProto.lower_bounds[indicator_id] >= 0, * VariablesProto.upper_bounds[indicator_id] <= 1. MathOpt की मदद से इन शर्तों की पुष्टि नहीं करता है. हालांकि, अगर ये शर्तें पूरी नहीं होती हैं, तो समाधान करने पर सॉल्वर को गड़बड़ी दिखेगी.

LPAlgorithmProto

लीनियर प्रोग्राम को हल करने के लिए, कोई एल्गोरिदम चुनता है.

Enums
LP_ALGORITHM_UNSPECIFIED
LP_ALGORITHM_PRIMAL_SIMPLEX (प्राइमल) सिंप्लेक्स मेथड. आम तौर पर प्राइमल और ड्यूअल समाधान, प्राइमल/ड्यूअल अनबाउंडेड समस्याओं पर प्राइमल/ड्यूअल रेज़, और आधार दिया जा सकता है.
LP_ALGORITHM_DUAL_SIMPLEX ड्यूअल सिंप्लेक्स मेथड. आम तौर पर प्राइमल और ड्यूअल समाधान, प्राइमल/ड्यूअल अनबाउंडेड समस्याओं पर प्राइमल/ड्यूअल रेज़, और आधार दिया जा सकता है.
LP_ALGORITHM_BARRIER बैरियर मेथड को आम तौर पर, इंटरनल पॉइंट मेथड (आईपीएम) भी कहा जाता है. आम तौर पर, यह प्राइमल और ड्यूअल, दोनों समाधान दे सकता है. लागू करने के कुछ तरीके, अनबाउंड/असाधारण समस्याओं पर रे पैदा कर सकते हैं. आधार तब तक नहीं बताया जाता, जब तक ऐप्लिकेशन मौजूद सॉल्वर "क्रॉसओवर" नहीं करता और सिंप्लेक्स के साथ खत्म नहीं होता.
LP_ALGORITHM_FIRST_ORDER पहले-ऑर्डर करने के तरीके पर आधारित एल्गोरिदम. ये आम तौर पर प्रिमल और ड्यूअल सलूशन, और संभावित तौर पर प्राइमल और/या ड्यूअल असेबिलिटी सर्टिफ़िकेट भी बनाएंगे. आम तौर पर, पहले-ऑर्डर करने के तरीकों से कम सटीक नतीजे मिलते हैं. इसलिए, उपयोगकर्ताओं को सलूशन के क्वालिटी पैरामीटर (उदाहरण के लिए, टॉलरेंस) सेट करने और समाधानों की पुष्टि करने पर ध्यान देना चाहिए.

LimitProto

जब कोई Solve() जल्दी बंद हो जाता है, तो ExpirationRequestProto FEASIBLE या NO_SOLUTION_FOUND के साथ, जो हिट की गई थी, वह तय की गई सीमा होती है.

Enums
LIMIT_UNSPECIFIED इसे तब शून्य वैल्यू के तौर पर इस्तेमाल किया जाता है, जब हम किसी सीमा में नहीं खत्म करते हों (उदाहरण के लिए, TERMINATION_REASON_OPTIMAL).
LIMIT_UNDETERMINED दिए गए सॉल्वर से पता नहीं चलता कि कौनसी सीमा पूरी हो गई है.
LIMIT_ITERATION बार-बार होने वाले दोहराव (जैसे कि सिंप्लेक्स या बैरियर इटरेशन) को लागू करने के बाद, बार-बार होने वाले एल्गोरिदम ने बंद कर दिया.
LIMIT_TIME उपयोगकर्ता के बताए गए हिसाब के समय के बाद, एल्गोरिदम रुक गया.
LIMIT_NODE ब्रांच और सीमा से जुड़े एल्गोरिदम ने काम करना बंद कर दिया, क्योंकि इसने ब्रांच और बाउंड ट्री में ज़्यादा से ज़्यादा नोड एक्सप्लोर किए.
LIMIT_SOLUTION एल्गोरिदम बंद हो गया, क्योंकि इसे ज़रूरी संख्या में समाधान मिल गए. एमआईपी में अक्सर इसका इस्तेमाल किया जाता है, ताकि सॉल्वर को सबसे पहले संभव समाधान के तौर पर जवाब दिया जा सके.
LIMIT_MEMORY मेमोरी खत्म होने की वजह से एल्गोरिदम रुक गया.
LIMIT_CUTOFF मकसद पर, सॉल्वर को कटऑफ़ के साथ चलाया गया, जैसे कि Solves.cutoff_limit को सेट किया गया. इससे यह पता चलता है कि उपयोगकर्ता को कटऑफ़ से भी खराब कोई समाधान नहीं चाहिए.सॉल्वर को यह नतीजा मिला कि कट-ऑफ़ समय जितना अच्छा कोई समाधान नहीं था. आम तौर पर, समाधान के बारे में कोई और जानकारी नहीं दी जाती है.
LIMIT_OBJECTIVE एल्गोरिदम रुक गया, क्योंकि या तो इसे कोई समाधान मिला या इसका बाउंड, उपयोगकर्ता की तय की गई सीमा से बेहतर था. Solveparameters.objective_limit और Solveparameters.बेस्ट_bound_limit देखें.
LIMIT_NORM एल्गोरिदम रुक गया, क्योंकि फिर से दोहराने का स्टैंडर्ड बहुत बड़ा हो गया.
LIMIT_INTERRUPTED रुकावट सिग्नल या उपयोगकर्ता की रुकावट के अनुरोध की वजह से एल्गोरिदम रुक गया.
LIMIT_SLOW_PROGRESS एल्गोरिदम बंद हो गया, क्योंकि यह समाधान की दिशा में आगे नहीं बढ़ सका.
LIMIT_OTHER

ऊपर दिए गए किसी एक विकल्प के दायरे में न आने की वजह से, एल्गोरिदम रुक गया. ध्यान दें कि LIMIT_UNDETERMINED का इस्तेमाल तब किया जाता है, जब वजह का पता नहीं चल पाता. साथ ही, LIMIT_OTHER का इस्तेमाल तब किया जाता है, जब वजह पता चल जाती है, लेकिन वह ऊपर दिए गए किसी विकल्प के मुताबिक नहीं होती.

PrivacyProto.detail में, सीमा के बारे में ज़्यादा जानकारी शामिल हो सकती है.

LinearConstraintsProto

जैसा कि नीचे इस्तेमाल किया गया है, हम "#linear कंस्ट्रेंट" = साइज़(लीनियर कंस्ट्रेंटप्रोटो.इड्स) को परिभाषित करते हैं.

फ़ील्ड
ids[]

int64

मैसेज, नेगेटिव न हों और पूरी तरह से बढ़ते हों. max(int64) वैल्यू का इस्तेमाल नहीं किया जा सकता.
lower_bounds[]

double

इसकी लंबाई #linear प्रतिबंधों के बराबर होनी चाहिए, [-inf, inf में वैल्यू).
upper_bounds[]

double

इसकी लंबाई #linear प्रतिबंधों के बराबर होनी चाहिए, वैल्यू (-inf, inf] में होनी चाहिए.
names[]

string

अगर इस नीति को सेट नहीं किया जाता है, तो इसे सभी खाली स्ट्रिंग माना जाता है. अगर ऐसा नहीं है, तो लंबाई #linear कंस्ट्रेंट के बराबर होनी चाहिए.

सभी गैर-खाली नाम अलग-अलग होने चाहिए.

LinearExpressionProto

यह लीनियर एक्सप्रेशन को सटीक तरीके से दिखाता है. इसमें वैरिएबल का भारित योग और कॉन्स्टेंट ऑफ़सेट शामिल होते हैं.

फ़ील्ड
ids[]

int64

वैरिएबल के आईडी. सभी एलिमेंट अलग-अलग के साथ क्रम से (बढ़ते क्रम में) लगाए जाने चाहिए.
coefficients[]

double

आईडी की लंबाई बराबर होनी चाहिए. वैल्यू सीमित होनी चाहिए और वह NaN भी नहीं हो सकती.
offset

double

सीमित होना चाहिए और NaN नहीं होना चाहिए.

ModelProto

ऑप्टिमाइज़ेशन से जुड़ी कोई समस्या. MathOpt काम करता है: - वैकल्पिक सीमित सीमाओं वाले कंटिन्यूअस और इंटीजर डिसिज़न वैरिएबल. - लीनियर और क्वाड्रेटिक मकसद (एक या कई मकसद), जिन्हें या तो छोटा किया गया हो या ज़्यादा से ज़्यादा बढ़ाया गया हो. - कई तरह के कंस्ट्रेंट टाइप, जिनमें ये शामिल हैं: * लीनियर कंस्ट्रेंट * क्वाड्रेटिक कंस्ट्रेंट * सेकंड-ऑर्डर कोन कंस्ट्रेंट * लॉजिकल कंस्ट्रेंट > SOS1 और SOS2 कंस्ट्रेंट > इंडिकेटर कंस्ट्रेंट

डिफ़ॉल्ट रूप से, पाबंदियां "id-to-data" मैप में दिखाई जाती हैं. हालांकि, हम लीनियर कंस्ट्रेंट को ज़्यादा बेहतर "स्ट्रक्चर-ऑफ़-अरे" फ़ॉर्मैट में दिखाते हैं.

फ़ील्ड
name

string
variables

VariablesProto
objective

ObjectiveProto

मॉडल में मुख्य मकसद.
auxiliary_objectives

map<int64, ObjectiveProto>

कई मकसद वाले मॉडल में इस्तेमाल के लिए सहायक मकसद.

मैप की कुंजी के आईडी, [0, max(int64)) में होने चाहिए. हर प्राथमिकता और हर नाम खाली होना चाहिए. साथ ही, यह मुख्य objective से अलग होना चाहिए.
linear_constraints

LinearConstraintsProto
linear_constraint_matrix

SparseDoubleMatrixProto

लीनियर कंस्ट्रेंट के लिए वैरिएबल गुणांक.

अगर इस कंस्ट्रेंट में शामिल किसी वैरिएबल को मिटा दिया जाता है, तो इसे शून्य पर सेट माना जाता है.

ज़रूरी शर्तें: * Linear_constraint_matrix.row_ids Linear_constraints.ids के एलिमेंट होते हैं. * Linear_constraint_matrix.column_ids, वैरिएबल.id के एलिमेंट होते हैं. * मैट्रिक्स एंट्री दर्ज नहीं की गई हैं, शून्य हैं. * Linear_constraint_matrix.values सभी सीमित होने चाहिए.
quadratic_constraints

map<int64, QuadraticConstraintProto>

मॉडल में क्वाड्रेटिक कंस्ट्रेंट.
second_order_cone_constraints

map<int64, SecondOrderConeConstraintProto>

मॉडल में सेकंड-ऑर्डर कोन कंस्ट्रेंट.
sos1_constraints

map<int64, SosConstraintProto>

मॉडल में SOS1 कंस्ट्रेंट, ज़्यादा से ज़्यादा एक expression को कंस्ट्रेंट करते हैं, लेकिन यह शून्य नहीं हो सकता. weights एंट्री, लागू करने की ऐसी जानकारी होती है जिसका इस्तेमाल सॉल्वर ज़्यादा तेज़ी से एक-दूसरे से जुड़ने के लिए करता है. ज़्यादा जानकारी के साथ, सॉल्वर इन महत्व का इस्तेमाल, ब्रांचिंग से जुड़े फ़ैसले लेने में कर सकते हैं (या नहीं कर सकते). इससे बच्चों के नोड “संतुलित” हो सकते हैं.
sos2_constraints

map<int64, SosConstraintProto>

मॉडल में SOS2 कंस्ट्रेंट होने चाहिए, जो इस बात को सीमित करते हैं कि expression की ज़्यादा से ज़्यादा दो एंट्री नॉन-ज़ीरो हो सकती हैं. साथ ही, वे उनके क्रम में आस-पास होनी चाहिए. अगर weights नहीं दिए जाते हैं, तो यह expressions सूची में उनका लीनियर क्रम होता है. अगर weights प्रज़ेंट किए जाते हैं, तो इन वैल्यू के हिसाब से क्रम को बढ़ते क्रम में लिया जाता है.
indicator_constraints

map<int64, IndicatorConstraintProto>

मॉडल में इंडिकेटर कंस्ट्रेंट, इसे लागू करता है. अगर बाइनरी "इंंडिकेटर वैरिएबल" को एक पर सेट किया जाता है, तो "इंप्लिसिट कंस्ट्रेंट" को होल्ड किया जाना चाहिए.

ModelSolveParametersProto

फ़ील्ड
variable_values_filter

SparseVectorFilterProto

यह फ़िल्टर, लौटाए गए सभी Sprse कंटेनर पर लागू होता है. इन पर, PrimalSolutionProto और PrimalRayProto{/1} (PrimalSolutionProto.variable_values, PrimalRayProto.variable_values) के वैरिएबल के हिसाब से डाला जाता है.

ज़रूरी शर्तें: * Filter_ids, वैरिएबलsProto.ids के एलिमेंट होते हैं.
dual_values_filter

SparseVectorFilterProto

यह फ़िल्टर, DualSolutionProto और DualRay (DualSolutionProto.dual_values, DualRay.dual_values) में लीनियर कंस्ट्रेंट के ज़रिए लौटाए गए सभी स्पार्स कंटेनर पर लागू होता है.

ज़रूरी शर्तें: * Filter_ids, लीनियरConstraints.ids के एलिमेंट हैं.
reduced_costs_filter

SparseVectorFilterProto

यह फ़िल्टर, DualSolutionProto और DualRay (DualSolutionProto.reduced_costs, DualRay.reduced_costs) में वैरिएबल के हिसाब से लगाए गए सभी स्पार्स कंटेनर हैं.

ज़रूरी शर्तें: * Filter_ids, वैरिएबलsProto.ids के एलिमेंट होते हैं.
initial_basis

BasisProto

वार्म स्टार्टिंग एलपी सॉल्वर के लिए वैकल्पिक शुरुआती आधार. अगर यह नीति सेट है, तो इसके validators/solution_validator.h में मौजूद ValidateBasis के मुताबिक, मौजूदा ModelSummary में मान्य रहने की संभावना है.
solution_hints[]

SolutionHintProto

समाधान के लिए वैकल्पिक संकेत. अगर दिया गया सॉल्वर सिर्फ़ एक संकेत को स्वीकार करता है, तो पहले संकेत का इस्तेमाल किया जाता है.
branching_priorities

SparseInt32VectorProto

ब्रांचिंग की वैकल्पिक प्राथमिकताएं. ज़्यादा वैल्यू वाले वैरिएबल को सबसे पहले ब्रांच में शामिल किया जाएगा. जिन वैरिएबल के लिए प्राथमिकताएं सेट नहीं की जाती हैं उन्हें सॉल्वर की डिफ़ॉल्ट प्राथमिकता (आम तौर पर शून्य) मिलती है.

ज़रूरी शर्तें: * Branching_priorries.values सीमित होनी चाहिए. * Branching_priories.ids, वैरिएबलsProto.ids के एलिमेंट होने चाहिए.

ObjectiveBoundsProto

सबसे सही मकसद की वैल्यू पर सीमाएं.

फ़ील्ड
primal_bound

double

सॉल्वर का दावा है कि सॉल्वर की वास्तविक क्षमता सहिष्णुता तक, primal_bound के तौर पर छोटा और ज़्यादा से ज़्यादा करने के लिए सबसे छोटा मान बराबर या बेहतर है (नीचे चेतावनी देखें): जब सॉल्वर ऐसी सीमा का दावा नहीं करता हो, तो * प्राइमल_बाउंड (मिनिमेशन के लिए +inf और -inf maximization) को छोटा करता है. * primal_bound, सबसे अच्छे मूल समाधान के मकसद की तुलना में, सबसे बेहतर वैल्यू के करीब हो सकता है. खास तौर पर, primal_bound, छोटा नहीं हो सकता. ऐसा तब भी हो सकता है, जब कोई मूल समाधान न दिया गया हो. चेतावनी: इसका सटीक दावा यह है कि ऐसा शुरुआती समाधान मौजूद है जो: * संख्या के हिसाब से संभव है (यानी, सॉल्वर के अनुभव के हिसाब से लागू किया जा सकता है) और * की वैल्यू 'प्राइमल_बाउंड' है. संख्या के हिसाब से यह समाधान संभव नहीं है. इस मामले में, primal_bound, सबसे सही वैल्यू से पूरी तरह बेहतर हो सकता है. प्राइमल बाउंड्री के सहिष्णुता के मामले में, प्राइमल_बाउंड के मुकाबले टॉलरेंस का अनुवाद करना आसान नहीं होता है. खास तौर पर, ऐसा तब होता है, जब व्यावहारिकता के हिसाब से समस्या को हल किया जा रहा हो.
dual_bound

double

सॉल्वर का दावा है कि सॉल्वर के लिए डबल-बिड और सॉल्वर के लिए सबसे बड़ा वैल्यू, दोनों बराबर या खराब हैं. सॉल्वर के लिए यह वैल्यू 'ड्यूअल_बाउंड' के मुकाबले कम या ज़्यादा है (नीचे चेतावनी देखें): Primal_bound की तरह ही, कुछ सॉल्वर के लिए सबसे सही नतीजे देने पर भी ऐसा हो सकता है. आम तौर पर, MIP सॉल्वर सटीक ही बाउंड रिपोर्ट करते हैं. * लगातार मौजूद समस्याओं के लिए Dual_bound का इस्तेमाल, सबसे बेहतर ड्यूअल मुमकिन समाधान के मकसद के मुकाबले, सबसे बेहतर वैल्यू के करीब किया जा सकता है. MIP के लिए, Dual_bound के लिए पहली गैर-ज़रूरी वैल्यू में से एक, अक्सर MIP के LP रिलैक्सेशन का सबसे सही वैल्यू होती है. * सॉल्वर सहिष्णुता के लिए प्राइमल बाउंड के मुकाबले Dual_bound बेहतर होना चाहिए (मिनिमेशन के लिए छोटा और बड़ा करने के लिए बड़ा). (यहां चेतावनी देखें). चेतावनी: * लगातार होने वाली समस्याओं के लिए, सटीक दावा यह है कि दो तरीकों से समाधान मौजूद है: * संख्या के हिसाब से संभव है (यानी कि सॉल्वर के हिसाब से संभव है) और * का मकसद Dual_bound है. संख्या के हिसाब से यह समाधान संभव नहीं है. इस मामले में, Dual_bound, सबसे अच्छी वैल्यू और primal_bound से पूरी तरह खराब हो सकता है. प्राइमल केस की तरह, Dual_bound पर डबल प्रॉमिनेंस टॉलरेंस का अनुवाद करना बहुत ज़रूरी नहीं है. खास तौर पर तब, जब संभावना के हिसाब से सहिष्णुता ज़्यादा हो. हालांकि, कुछ सॉल्वर Dual_bound का सही वर्शन उपलब्ध कराते हैं. यह संख्या के हिसाब से सुरक्षित हो सकता है. सही किए गए इस वर्शन को सॉल्वर के खास आउटपुट की मदद से ऐक्सेस किया जा सकता है. उदाहरण के लिए, पीडीएलपी, pdlp_OUT.convergence_information. सहीed_dual_objective के लिए. * MIP सॉल्वर के लिए, Dual_bound को दो सॉल्यूशन के साथ जोड़ा जा सकता है, ताकि लगातार आराम मिल सके (जैसे, एलपी रिलैक्सेशन). हालांकि, यह अक्सर सॉल्वर के एक्ज़ीक्यूशन की वजह से होता है. आम तौर पर, यह एलपी सॉल्वर की बताई गई सीमा से ज़्यादा सटीक होता है.

ObjectiveProto

फ़ील्ड
maximize

bool

गलत अधिकतम होता है, सही अधिकतम होता है
offset

double

सीमित होना चाहिए, NaN के नहीं.
linear_coefficients

SparseDoubleVectorProto

ObjectiveProto ऐसे शब्द जो डिसिज़न वैरिएबल में लीनियर होते हैं.

ज़रूरी शर्तें: * Linear_coefficiencys.ids, वैरिएबलsProto.ids के एलिमेंट होते हैं. * वैरिएबलsProto तय नहीं किया गया है, जो शून्य के बराबर है. * Linear_coefficiencys.values सभी सीमित होने चाहिए. * Linear_coefficiencys.values शून्य हो सकता है, लेकिन इससे सिर्फ़ जगह बर्बाद होती है.
quadratic_coefficients

SparseDoubleMatrixProto

डिसिज़न वैरिएबल में क्वाड्रेटिक टर्म वाले ऑब्जेक्टिव टर्म.

SprseDoubleClickMatrixProto मैसेज के अलावा ज़रूरी शर्तें: * quadratic_coefficiencys.row_ids के हर एलिमेंट और quadratic_coefficiencys.column_ids का हर एलिमेंट, वैरिएबल का एक एलिमेंट होना चाहिए. * मैट्रिक्स को ऊपरी त्रिकोणीय होना चाहिए: हर i के लिए, quadratic_coefficiencys.row_ids[i] <= quadratic_coefficiencys.column_ids[i] की वैल्यू.

ध्यान दें: * जिन शब्दों को साफ़ तौर पर सेव नहीं किया गया है उनका गुणांक कोई नहीं होता. * quadratic_coefficiencys.coefficiencys के एलिमेंट शून्य हो सकते हैं, लेकिन इससे सिर्फ़ जगह बर्बाद होती है.
name

string

इस फ़ील्ड पर पैरंट मैसेज की यूनीक वैल्यू हो सकती है. उदाहरण के लिए, ModelProto.objectives और AuxiliaryObjectivesUpdateProto.new_objectives देखें.
priority

int64

कई मकसद वाले सवालों के लिए, दूसरे मकसद के मुकाबले इस मकसद की प्राथमिकता (कम ज़रूरी है ज़्यादा ज़रूरी है). यह वैल्यू, नेगेटिव नहीं होनी चाहिए. इसके अलावा, सॉल्व के समय मॉडल में हर मकसद की प्राथमिकता अलग-अलग होनी चाहिए. प्रोटो लेवल पर इस स्थिति की पुष्टि नहीं की जाती है. इसलिए, हो सकता है कि मॉडल की प्राथमिकता कुछ समय के लिए ही हो.

PrimalRayProto

किसी ऑप्टिमाइज़ेशन समस्या में असीमित सुधार की दिशा; इसके बराबर, ऑप्टिमाइज़ेशन समस्या के दोहराव के लिए अक्षमता का प्रमाणपत्र.

उदाहरण के लिए, एक आसान लीनियर प्रोग्राम पर विचार करें: कम से कम c * x s.t. A * x >= b x >= 0 प्राइमल रे वह x है जो संतुष्ट करती है: c * x < 0 A * x >= 0 x >= 0 वह समाधान देता है जो काम करने लायक कोई भी समाधान देता है. साथ ही, कोई भी पॉज़िटिव हल होता है. प्राइमल रे भी यह साबित करती है कि ड्यूअल ऑप्टिमाइज़ेशन की समस्या को करना मुमकिन नहीं है.

नीचे PrimalRay के मैसेज में, वैरिएबल_values x है.

फ़ील्ड
variable_values

SparseDoubleVectorProto

ज़रूरी शर्तें: * variable_values.ids, वैरिएबलsProto.ids के एलिमेंट हैं. * वैरिएबल_values.values सभी सीमित होने चाहिए.

PrimalSolutionProto

ऑप्टिमाइज़ेशन समस्या का समाधान.

उदाहरण के लिए, एक आसान लीनियर प्रोग्राम पर विचार करें: कम से कम c * x s.t. A * x >= b x >= 0. प्रिमल सलूशन, x के असाइनमेंट की वैल्यू होता है. यह संभव है अगर यह ऊपर से A * x >= b और x >= 0 के बराबर हो. नीचे दिए गए PrimalSolutionProto मैसेज में, वैरिएबल_values x है और आइडिया_वैल्यू c * x है.

फ़ील्ड
variable_values

SparseDoubleVectorProto

ज़रूरी शर्तें: * variable_values.ids, वैरिएबलsProto.ids के एलिमेंट हैं. * वैरिएबल_values.values सभी सीमित होने चाहिए.
objective_value

double

ऑब्जेक्टिव वैल्यू, जिसे दिए गए सॉल्वर ने कैलकुलेट किया है. अनंत या NaN नहीं हो सकता.
auxiliary_objective_values

map<int64, double>

सहायक मकसद की वैल्यू, जिनका पता लगाने के लिए दिए गए सॉल्वर का इस्तेमाल किया जाता है. कुंजियां, मान्य सहायक मकसद आईडी होनी चाहिए. मान अनंत या NaN नहीं हो सकते.
feasibility_status

SolutionStatusProto

दिए गए सॉल्वर के हिसाब से, सलूशन की संभावना का स्टेटस.

ProblemStatusProto

सॉल्वर के दावे के मुताबिक, मूल सवाल और इसके दोहराव (या लगातार मिलने वाले आराम की ड्यूअल) की संभावना की स्थिति. सॉल्वर को दावे के लिए सर्टिफ़िकेट देने की ज़रूरत नहीं होती. उदाहरण के लिए, सॉल्वर, असल व्यावहारिक सॉल्यूशन को वापस किए बिना, मूल संभावना का दावा कर सकता है. इस मिली-जुली स्थिति से, सॉल्वर के दावों की पूरी जानकारी मिलती है कि हल किए जाने की संभावना है या नहीं. साथ ही, यह भी पता चलता है कि कोई हल किया जा सकता है या नहीं. उदाहरण के लिए,

  • प्राइमल और दोहरी समस्याओं के लिए एक संभव स्थिति से यह पता चलता है कि प्राइमल संभव है और सीमित है. साथ ही, उसके सबसे बेहतर समाधान की संभावना है. इसमें नॉन-लीनियर कंस्ट्रेंट के बिना समस्याओं के लिए गारंटी दी हुई है.
  • बुनियादी समस्या और दोहरा अभावल स्टेटस यह बताता है कि मूल समस्या अनबाउंड है (यानी कि इसके जवाब मनमोहक हैं).

ध्यान दें कि अपने-आप ड्यूअल इनफ़िबल स्टेटस (यानी कि एक अनिर्धारित प्राइमल स्टेटस के साथ) का यह मतलब नहीं है कि मूल समस्या अनबाउंड है, क्योंकि हो सकता है कि दोनों ही समस्याओं को हल न किया जा सके. साथ ही, एक शुरुआती और दो-सही स्थिति के हिसाब से सबसे बेहतर समाधान की मौजूदगी का संकेत हो सकता है. हालांकि, यह इस बात की गारंटी नहीं देता कि सॉल्वर को इतना बेहतर समाधान मिल ही गया है.

फ़ील्ड
primal_status

FeasibilityStatusProto

मूल समस्या की स्थिति.
dual_status

FeasibilityStatusProto

दो समस्याओं की स्थिति के लिए (या लगातार आराम करने की दोहराई के लिए).
primal_or_dual_infeasible

bool

अगर सही है, तो सॉल्वर दावा करता है कि शुरुआती या दोहरा सवाल संभव नहीं हैं. हालांकि, उन्हें यह नहीं पता कि इनमें से कौनसी समस्या है या फिर दोनों संभव नहीं हैं. यह सिर्फ़ तब सही हो सकता है, जब primal_problem_status = double_problem_status = kUnतय है. इस ज़्यादा जानकारी की ज़रूरत अक्सर तब होती है, जब प्री-प्रोसेसिंग के ज़रिए यह पता चलता है कि समस्या का कोई बेहतर समाधान नहीं है. हालांकि, हम यह तय नहीं कर सकते कि इसकी वजह आसानी से समझ में नहीं आने वाली, अलग-अलग सीमा में मौजूद होने या दोनों की वजह से है या नहीं.

QuadraticConstraintProto

फ़ॉर्म का सिंगल क्वाड्रेटिक कंस्ट्रेंट: lb <= sum{linear_terms} + Sum{quadratic_terms} <= ub.

अगर इस कंस्ट्रेंट में शामिल किसी वैरिएबल को मिटा दिया जाता है, तो इसे शून्य पर सेट माना जाता है.

फ़ील्ड
linear_terms

SparseDoubleVectorProto

ऐसे शब्द जो डिसिज़न वैरिएबल में लीनियर होते हैं.

Sprse एआईवटर्कप्रोटो मैसेज की ज़रूरी शर्तों के अलावा, हमें इन चीज़ों की ज़रूरत है: * Linear_terms.ids, वैरिएबलsProto.ids के एलिमेंट होते हैं. * Linear_terms.values सभी सीमित होने चाहिए और NaN के नहीं.

ध्यान दें: * हटाए गए वैरिएबल आईडी का गुणांक शून्य होता है. * Linear_terms.values शून्य हो सकता है, लेकिन इससे सिर्फ़ जगह बर्बाद होती है.
quadratic_terms

SparseDoubleMatrixProto

डिसीज़न वैरिएबल में क्वाड्रेटिक टर्म.

Sprse DoubleMatrixProto मैसेज की ज़रूरतों के अलावा यह ज़रूरी है कि: * quadratic_terms.row_ids के हर एलिमेंट और quadratic_terms.column_ids का हर एलिमेंट, वैरिएबलsProto.ids का एक एलिमेंट होना चाहिए. * मैट्रिक्स ऊपरी त्रिकोणीय होना चाहिए: हर i के लिए, quadratic_terms.row_ids[i] <= quadratic_terms.column_ids[i].

ध्यान दें: * जिन शब्दों को साफ़ तौर पर सेव नहीं किया गया है उनका गुणांक कोई नहीं होता. * quadratic_terms.coऐफ़िशिएंट के एलिमेंट शून्य हो सकते हैं, लेकिन इससे सिर्फ़ जगह बर्बाद होती है.
lower_bound

double

वैल्यू [-inf, inf) में होनी चाहिए और यह upper_bound से कम या उसके बराबर होनी चाहिए.
upper_bound

double

वैल्यू (-inf, inf] में होनी चाहिए) और lower_bound से ज़्यादा या उसके बराबर होनी चाहिए.
name

string

इस फ़ील्ड पर पैरंट मैसेज के लिए, ईमेल के यूनीक होने की ज़रूरी शर्तें हो सकती हैं. उदाहरण के लिए, ModelProto.quadratic_constraints और QuadraticConstraintUpdateProto.new_constraints देखें.

SecondOrderConeConstraintProto

फ़ॉर्म का एक सेकंड-ऑर्डर कोन कंस्ट्रेंट:

|arguments_to_norm||_2 <= upper_bound,

जहां upper_bound और arguments_to_norm का हर एलिमेंट लीनियर एक्सप्रेशन है.

अगर इस कंस्ट्रेंट में शामिल किसी वैरिएबल को मिटा दिया जाता है, तो इसे शून्य पर सेट माना जाता है.

फ़ील्ड
upper_bound

LinearExpressionProto
arguments_to_norm[]

LinearExpressionProto
name

string

इस फ़ील्ड में, पैरंट मैसेज के लिए ज़रूरी शर्तें हो सकती हैं. जैसे, ModelProto.second_order_cone_constraints और SecondOrderConeConstraintUpdatesProto.new_constraints देखें.

SolutionHintProto

सॉल्वर के लिए सुझाया गया शुरुआती समाधान.

एमआईपी सॉल्वर आम तौर पर सिर्फ़ शुरुआती जानकारी (variable_values) चाहते हैं, जबकि एलपी सॉल्वर असली और दोहरी, दोनों तरह की जानकारी (dual_values) चाहते हैं.

कई MIP सॉल्वर इनके साथ काम कर सकते हैं: (1) ऐसे आंशिक समाधान जो सभी वैरिएबल की जानकारी नहीं देते या (2) संभव न होने वाले समाधान. इन मामलों में, सॉल्वर आम तौर पर संकेत को पूरा/सही करने के लिए सब-एमआईपी को हल करते हैं.

सॉल्वर, संकेत का इस्तेमाल कैसे करता है. हालांकि, यह पूरी तरह से सॉल्वर, सवाल, और इस्तेमाल किए गए एल्गोरिदम पर निर्भर करता है. संकेत का असर दिखने के लिए, सबसे भरोसेमंद तरीका यह है कि दिए गए सॉल्वर लॉग को संकेत के साथ और उसके बिना पढ़ा जाए.

आम तौर पर, सिंप्लेक्स-आधारित एलपी सॉल्वर, सलूशन से जुड़े संकेत के लिए शुरुआती आधार को प्राथमिकता देते हैं. अगर ऐसा नहीं है, तो संकेत को मूल समाधान में बदलने के लिए, उन्हें क्रॉसओवर करना पड़ता है.

फ़ील्ड
variable_values

SparseDoubleVectorProto

सवाल के प्राइमल वैरिएबल के लिए वैल्यू का कुछ हद तक असाइनमेंट. इस सब-मैसेज के लिए, सॉल्वर इंडिपेंडेंट ज़रूरी शर्तें ये हैं: * variable_values.ids, वैरिएबलsProto.ids के एलिमेंट हैं. * वैरिएबल_values.values सभी सीमित होने चाहिए.
dual_values

SparseDoubleVectorProto

सवाल की लीनियर कंस्ट्रेंट के लिए वैल्यू का ए (संभावित रूप से कुछ हद तक) असाइनमेंट.

ज़रूरी शर्तें: * Dual_values.ids, लीनियरConstraintsProto.ids के एलिमेंट हैं. * Dual_values.values का इस्तेमाल न किया जा सकता हो.

SolutionProto

समाधान में क्या शामिल किया जाएगा, यह समस्या और उसे सुलझाने वाले तरीके पर निर्भर करता है. मौजूदा सामान्य पैटर्न 1 हैं. एमआईपी सॉल्वर सिर्फ़ शुरुआती समाधान दिखाते हैं. 2. सिंप्लेक्स एलपी सॉल्वर अक्सर आधार और इससे जुड़े प्राइमल और ड्यूअल सलूशन के बारे में बताते हैं. 3. अन्य एक जैसे सॉल्वर अक्सर प्राइमल और ड्यूअल सलूशन देते हैं. ये समाधान, सॉल्वर पर निर्भर होते हैं.

ज़रूरी शर्तें: * कम से कम एक फ़ील्ड सेट करना ज़रूरी है; समाधान को खाली नहीं छोड़ा जा सकता.

फ़ील्ड
primal_solution

PrimalSolutionProto
dual_solution

DualSolutionProto
basis

BasisProto

SolutionStatusProto

सॉल्वर के दावे के मुताबिक, प्राइमल या डबल सलूशन की संभावना.

Enums
SOLUTION_STATUS_UNSPECIFIED गार्ड की वैल्यू, कोई स्टेटस नहीं दिखा रही है.
SOLUTION_STATUS_UNDETERMINED सॉल्वर किसी संभावना के बारे में नहीं बताता है.
SOLUTION_STATUS_FEASIBLE सॉल्वर का दावा है कि समाधान संभव है.
SOLUTION_STATUS_INFEASIBLE सॉल्वर का दावा है कि समाधान संभव नहीं है.

SolveParametersProto

एक ही सॉल्यूशन को कंट्रोल करने वाले पैरामीटर.

इसमें सभी सॉल्वर के लिए एक जैसे पैरामीटर, जैसे कि time_limit और किसी खास सॉल्वर के पैरामीटर शामिल होते हैं, जैसे कि gscip. अगर कोई वैल्यू सामान्य और सॉल्वर, दोनों के हिसाब से सेट की गई है, तो सॉल्वर के लिए खास सेटिंग का इस्तेमाल किया जाता है.

ऐसे सामान्य पैरामीटर जो ज़रूरी नहीं हैं और सेट नहीं हैं या जिनकी वैल्यू नहीं बताई गई है उनसे पता चलता है कि सॉल्वर डिफ़ॉल्ट का इस्तेमाल किया गया है.

इस्तेमाल किए जा रहे सॉल्वर के अलावा, सॉल्वर के लिए खास पैरामीटर को अनदेखा कर दिया जाता है.

मॉडल पर निर्भर करने वाले पैरामीटर (उदाहरण के लिए, हर वैरिएबल के लिए ब्रांचिंग प्राथमिकता सेट की जाती है) ModelSolve parametersProto में पास किए जाते हैं.

फ़ील्ड
time_limit

Duration

सॉल्वर को सवाल पर ज़्यादा से ज़्यादा समय देना चाहिए या सेट न होने पर अनलिमिटेड समय देना चाहिए.

इस वैल्यू को इस्तेमाल करने की कोई सीमा नहीं है. सवाल हल करने में लगने वाला समय, इस वैल्यू से कुछ ज़्यादा हो सकता है. यह पैरामीटर हमेशा मौजूद सॉल्वर को पास किया जाता है, इसमें सॉल्वर डिफ़ॉल्ट का इस्तेमाल नहीं किया जाता है.
enable_output

bool

सॉल्वर को लागू करने वाले ट्रेस प्रिंट करने की सुविधा चालू करता है. उन ट्रेस की जगह सॉल्वर पर निर्भर करती है. SCIP और Gurobi के लिए यह स्टैंडर्ड आउटपुट स्ट्रीम होंगी. Glop और CP-SAT के लिए यह LOG(INFO) होगा.

ध्यान दें कि अगर सॉल्वर, मैसेज कॉलबैक के साथ काम करता है और उपयोगकर्ता इसके लिए एक कॉलबैक रजिस्टर करता है, तो इस पैरामीटर वैल्यू को अनदेखा कर दिया जाता है और कोई ट्रेस प्रिंट नहीं किया जाता.
lp_algorithm

LPAlgorithmProto

लीनियर प्रोग्राम को हल करने के लिए एल्गोरिदम. अगर LP_ALGORITHM_UNSPECIFIED हो, तो सॉल्वर डिफ़ॉल्ट एल्गोरिदम का इस्तेमाल करें.

ऐसे सवाल जो लीनियर प्रोग्राम नहीं हैं, लेकिन लीनियर प्रोग्रामिंग एक सबरूटीन है, उनके लिए सॉल्वर इस वैल्यू का इस्तेमाल कर सकते हैं. उदाहरण के लिए, MIP सॉल्वर आम तौर पर रूट एलपी सॉल्वर के लिए इसका इस्तेमाल करेंगे. अगर ऐसा नहीं है, तो ड्यूअल सिंप्लेक्स का इस्तेमाल करें.
presolve

EmphasisProto

मुख्य एल्गोरिदम शुरू करने से पहले, समस्या को आसान बनाने की कोशिश करें या अगर समाधान देने वाला डिफ़ॉल्ट तौर पर काम करता है, तो सवाल हल करने का लेवल SSID_UNSPECIFIED.
cuts

EmphasisProto

बेहतर एलपी रिलैक्सेशन (सिर्फ़ एमआईपी) पाने की कोशिश करना. अगर सॉल्वर डिफ़ॉल्ट रूप से किसी समस्या को हल करने का लेवल {/6}_UNSPECIFIED हो, तो उसे पाने की कोशिश करें.

ध्यान दें: कट बंद करने से, कॉलबैक को MIP_NODE में कट लगाने से रोका जा सकता है. यह सॉल्वर के लिए खास होता है.
heuristics

EmphasisProto

खोज प्रक्रिया (सिर्फ़ MIP) के ज़रिए समाधान ढूंढने की कोशिश करना. अगर सॉल्वर के लिए डिफ़ॉल्ट तौर पर कोई समाधान नहीं है, तो उस समस्या के समाधान खोजने की कोशिश करना.
scaling

EmphasisProto

संख्यात्मक स्थिरता को बेहतर बनाने के लिए समस्या को फिर से बढ़ाने की कोशिश करें या सेशन को डिफ़ॉल्ट रूप से तय किए जाने का लेवल {7}_UNSPECIFIED हो.
iteration_limit

int64

दिए गए एल्गोरिदम के दोहराव की सीमा तय करें (उदाहरण के लिए, सिंप्लेक्स पिवट). यह खास तरीका, सॉल्वर और इस्तेमाल किए गए एल्गोरिदम पर निर्भर करता है.हालांकि, अक्सर यह एक डिटर्मिनिस्टिक सॉल्व लिमिट देता है. इसके लिए, एक और कॉन्फ़िगरेशन की ज़रूरत पड़ सकती है, जैसे कि एक थ्रेड.

आम तौर पर, यह एलपी, क्यूपी, और एमआईपी सॉल्वर के साथ काम करता है. हालांकि, एमआईपी सॉल्वर के लिए node_limit भी देखें.
node_limit

int64

संख्यात्मक खोज (जैसे कि ब्रांच और बाउंड) में हल किए गए सब-सवालों की संख्या की सीमा. कई सॉल्वर के लिए, इसका इस्तेमाल कंप्यूटेशन को सीमित करने के लिए किया जा सकता है. इसके लिए, कॉन्फ़िगरेशन की ज़रूरत पड़ सकती है, जैसे कि एक थ्रेड.

आम तौर पर, एमआईपी सॉल्वर के लिए iteration_limit देखें.
cutoff_limit

double

अगर सॉल्वर यह साबित कर देता है कि कोई भी प्राइमरी सलूशन कम से कम कटऑफ़ भी नहीं है, तो सॉल्वर जल्दी रुक जाता है.

शुरुआत में, सॉल्वर खाता बंद करने की वजह NO_SOLUTION_FOUND के साथ और सीमा CUTOFF के साथ दिखाता है. साथ ही, जवाब के बारे में ज़्यादा जानकारी देने की ज़रूरत नहीं होती. अगर कोई शुरुआती स्टॉप न हो, तो रिटर्न वैल्यू पर इसका कोई असर नहीं होता.

अगर आपको कट-ऑफ़ समय के बराबर ऑब्जेक्ट वाले सलूशन चाहिए, तो हमारा सुझाव है कि 'टोलरेंस' चुनें.

ज़्यादा जानकारी और Best_bound_limit के साथ तुलना करने के लिए, उपयोगकर्ता गाइड देखें.
objective_limit

double

जैसे ही हल मिलता है, वैसे ही सॉल्वर जल्दी रुक जाता है. कम से कम इतना अच्छा जवाब मिल जाता है, क्योंकि उसे बंद करने की वजह फ़ेल हो जाती है और मकसद सीमित हो जाता है.
best_bound_limit

double

जैसे ही यह साबित होता है कि सॉल्वर जल्दी रुक जाता है, कम से कम इतना अच्छा होता है, तो इसका मतलब है कि उसे खत्म करने की वजह FEASIBLE या NO_SOLUTION_FOUND है. साथ ही, इसमें ObjectIVE को सीमित किया गया.

ज़्यादा जानकारी औरcutoff_limit के साथ तुलना के लिए उपयोगकर्ता गाइड देखें.
solution_limit

int32

कई संभव समाधान ढूंढने के बाद, सॉल्वर जल्दी रुक जाता है. ऐसे में, समझौता खत्म होने की वजह फ़ेल हो जाती है और SOLUTION को सीमित कर दिया जाता है. अगर वैल्यू सेट की गई है, तो वैल्यू शून्य से ज़्यादा होनी चाहिए. इसका इस्तेमाल अक्सर सॉल्वर को सबसे पहले संभव समाधान पर रोकने के लिए किया जाता है. ध्यान दें कि दिखाए गए किसी भी समाधान के मकसद की वैल्यू की कोई गारंटी नहीं है.

आम तौर पर, सॉल्वर, सॉल्यूशन की सीमा से ज़्यादा जवाब नहीं देते हैं. हालांकि, यह MathOpt लागू नहीं करता है, इसलिए b/214041169 भी देखें.

फ़िलहाल, यह Gurobi और SCIP के लिए काम करता है. साथ ही, यह सिर्फ़ CP-SAT के लिए वैल्यू 1 के साथ काम करता है.
threads

int32

अगर यह संख्या सेट है, तो यह >= 1 होनी चाहिए.
random_seed

int32

दिए गए सॉल्वर में, स्यूडो-रैंडम नंबर जनरेटर का बीज. ध्यान दें कि सभी सॉल्वर, एलपी एल्गोरिदम में गड़बड़ी, टाई-ब्रेक-अप के नियम, और अनुमान के हिसाब से गड़बड़ी जैसी चीज़ों को चुनने के लिए, स्यूडो-रैंडम नंबर का इस्तेमाल करते हैं. इसे अलग-अलग रखने से, सॉल्वर के व्यवहार पर काफ़ी असर पड़ सकता है.

सभी सॉल्वर में बीज का सिद्धांत होता है, लेकिन ध्यान रखें कि मान्य वैल्यू, असल सॉल्वर पर निर्भर करती हैं. - गुरोबी: [0:GRB_MAXINT] (Gurobi 9.0 के हिसाब से, इसका साइज़ 2x10^9 है). - GSCIP: [0:2147483647] (यह MAX_INT या kint32max या 2^31-1 है). - GLOP: [0:2147483647] (जैसा कि ऊपर बताया गया है) सभी मामलों में, सॉल्वर को इसके बराबर मान मिलेगा: MAX(0, MIN(MAX_VALID_VALUE_FOR_SOLVER,!).
absolute_gap_tolerance

double

एमआईपी सॉल्वर के लिए, खास तौर पर सबसे सही सहिष्णुता.

निरपेक्ष GAP इनके बीच के अंतर का निरपेक्ष मान है: * सबसे बेहतर संभव समाधान की मकसद वैल्यू, * खोज से जनरेट की गई ड्यूअल बाउंड. जब GAP पूरी तरह से तय हो जाता है, तो सॉल्वर बंद हो सकता है (जब यह सेट हो जाता है) और TERMINATION_REASON_OPTIMAL वापस आ सकता है.

अगर इसे सेट किया गया है, तो इसे >= 0 होना चाहिए.

रिलेटिव_हिप_टॉलरेंस भी देखें.
relative_gap_tolerance

double

मुख्य तौर पर, MIP सॉल्वर के लिए एक रिलेटिव इष्टतमिटी सहिष्णुता.

मिलता-जुलता GAP, कुल GAP का सामान्य वर्शन है (इसे alternate_ गाने के बीच में रखकर तय किया गया है), जहां नॉर्मलाइज़ेशन, सॉल्वर पर निर्भर होता है. उदाहरण के लिए, कुल GAP को मिलने वाले सबसे सही समाधान की ऑब्जेक्ट वैल्यू से भाग दिया जाता है.

जब सापेक्ष GAP सबसे ज़्यादा सापेक्ष_ग्राप_टॉलरेंस (सेट होने पर) होता है, तो सॉल्वर बंद हो जाता है और TERMINATION_REASON_OPTIMAL लौटा सकता है.

अगर इसे सेट किया गया है, तो इसे >= 0 होना चाहिए.

साथ ही, base_ फ़िल्म के लिए ज़्यादा से ज़्यादा विकल्प अपनाना भी देखें.
solution_pool_size

int32

खोज करते समय, ज़्यादा से ज़्यादा solution_pool_size समाधान पाएं. सलूशन पूल में आम तौर पर दो फ़ंक्शन होते हैं: (1) सॉल्वर के लिए जो एक से ज़्यादा सलूशन लौटा सकते हैं, इससे यह सीमित होता है कि कितने सलूशन दिए जाएंगे. (2) कुछ सॉल्वर, सॉल्यूशन पूल के सलूशन का इस्तेमाल करके हेरिस्टिक्स चला सकते हैं. इसलिए, इस वैल्यू में बदलाव करने से एल्गोरिदम के पाथ पर असर पड़ सकता है. सॉल्वर को सॉल्वर पूल को भरने के लिए, ज़बरदस्ती लागू करने के लिए, n सबसे अच्छे सलूशन के साथ. इसके लिए, सॉल्वर के लिए खास कॉन्फ़िगरेशन की ज़रूरत होती है.

SolveResultProto

जब प्राइमल/ड्यूअल सलूशन/रे जटिल होते हैं, तब इनके कॉन्ट्रैक्ट की पूरी जानकारी देखने के लिए file_REASONs.md को देखें.

जब तक कोई सटीक समझौता नहीं हो जाता, तब तक खत्म होने की वजह पर भरोसा करने के बजाय, सिर्फ़ यह देखना सुरक्षित है कि कोई समाधान/रे मौजूद है या नहीं.

फ़ील्ड
termination

TerminationProto

सॉल्वर के रुक जाने की वजह.
solutions[]

SolutionProto

आने वाले समय में सॉल्वर को जो सलूशन लागू करने चाहिए उनके लिए सामान्य कॉन्ट्रैक्ट इस तरह तय किया जाता है: 1. असल समाधान वाले समाधान, जिन्हें सबसे पहले बुनियादी मकसद के हिसाब से क्रम में लगाया जाता है. 2. दो संभावित समाधान वाले समाधान, सबसे अच्छे ड्यूअल मकसद के हिसाब से क्रम में लगाए गए (अनजान दोहरा मकसद सबसे खराब है) 3. बाकी सभी सलूशन, किसी भी ऑर्डर में लौटाए जा सकते हैं.
primal_rays[]

PrimalRayProto

बिना सीमा के बुनियादी सुधार या इसके बराबर, ड्यूअल इनफ़ेबिलिटी सर्टिफ़िकेट के निर्देश. आम तौर पर, समय के साथ समझौता खत्म होने की वजह और DUAL_INFEASIBLE की जानकारी दी जाती है
dual_rays[]

DualRayProto

दो बार सुधार न होने के बारे में निर्देश या इसके बराबर, बुनियादी क्षमता के सर्टिफ़िकेट. आम तौर पर, यह मुकाबलों के लिए वजह से दूर नहीं किए जा सकते.
solve_stats

SolveStatsProto

सॉल्व प्रोसेस से जुड़े आंकड़े. जैसे, दौड़ने का समय, दोहराव.

SolveStatsProto

फ़ील्ड
solve_time

Duration

बीती हुई दीवार घड़ी का समय, जिसे value_opt से मापा गया है. आम तौर पर, Sover::Solve() के अंदर का समय ऐसा होता है. ध्यान दें: इसमें मॉडल बनाने में किया गया काम शामिल नहीं है.
problem_status

ProblemStatusProto

शुरुआती और दोहरी समस्याओं के लिए संभावना की स्थितियां.
simplex_iterations

int64
barrier_iterations

int64
first_order_iterations

int64
node_count

int64

SolverTypeProto

MathOpt के साथ काम करने वाले सॉल्वर.

Enums
SOLVER_TYPE_UNSPECIFIED
SOLVER_TYPE_GSCIP

सॉल्विंग कंस्ट्रेंट इंटीजर प्रोग्राम (एससीआईपी) सॉल्वर (तीसरा पक्ष).

यह एलपी, एमआईपी, और नॉनकंएक्स पूर्णांक क्वाड्रेटिक सवालों के साथ काम करता है. हालांकि, एलपी के लिए ड्यूअल डेटा नहीं दिखता है. एलपी के लिए जीएलओपी को प्राथमिकता दें.
SOLVER_TYPE_GUROBI

गुरोबी सॉल्वर (तीसरा पक्ष).

यह एलपी, एमआईपी, और नॉनकंएक्स पूर्णांक क्वाड्रेटिक सवालों के साथ काम करता है. आम तौर पर, सबसे तेज़ विकल्प मिलता है, लेकिन इसके लिए खास लाइसेंस दिए जाते हैं.
SOLVER_TYPE_GLOP

Google का ग्लोप सॉल्वर.

प्राइमल और ड्यूअल सिंप्लेक्स तरीकों के साथ, एलपी के साथ काम करता है.
SOLVER_TYPE_CP_SAT

Google का CP-SAT सॉल्वर.

उन सवालों को सपोर्ट करता है जिनमें सभी वैरिएबल पूर्णांक और बाउंड होते हैं (या अनुमान लगाए जाते हैं). कंटिन्यूअस वैरिएबल से जुड़ी समस्याओं को फिर से स्केल करने और उन्हें अलग करने के लिए एक्सपेरिमेंट के तौर पर दी गई सहायता.
SOLVER_TYPE_PDLP

Google का पीडीपी सॉल्वर.

एलपी और कॉन्वेक्स डायगनल क्वाड्रेटिक लक्ष्यों के साथ काम करता है. सिंप्लेक्स के बजाय, पहले ऑर्डर के तरीकों का इस्तेमाल करता है. इससे बहुत बड़ी समस्याओं को हल किया जा सकता है.
SOLVER_TYPE_GLPK

GNU लीनियर प्रोग्रामिंग किट (जीएलपीके) (तीसरा पक्ष).

MIP और LP के साथ काम करता है.

थ्रेड-सुरक्षा: GLPK, मेमोरी असाइन करने के लिए थ्रेड-लोकल स्टोरेज का इस्तेमाल करता है. नतीजतन, सॉल्वर इंस्टेंस को उसी थ्रेड में खत्म करना ज़रूरी है जो बनाए गए थे. ऐसा न करने पर, GLPK बंद हो जाएगा. ऐसा लगता है कि सॉल्वर को बनाने के लिए इस्तेमाल किए गए थ्रेड के बजाय, किसी दूसरे थ्रेड से Salver::Solve() को कॉल करना सही है. हालांकि, इसे GLPK में दर्ज नहीं किया गया है और ऐसा करने से बचना चाहिए.

प्रीसॉल्वर के साथ एलपी को हल करते समय, सलूशन (और अनबाउंड रेज़) सिर्फ़ तब मिलते हैं, जब सबसे बेहतर समाधान मिल जाता है. ऐसा न होने पर कुछ नहीं लौटाया जाएगा. ज़्यादा जानकारी के लिए, glpk-5.0/doc/glpk.pdf पेज #40 को glpk-5.0.tar.gz पर देखें.
SOLVER_TYPE_OSQP

ऑपरेटर स्प्लिटिंग क्वाड्रेटिक प्रोग्राम (ओएसक्यूपी) सॉल्वर (तीसरा पक्ष).

लीनियर कंस्ट्रेंट और लीनियर या उत्तल क्वाड्रेटिक लक्ष्यों की लगातार समस्याओं को हल करने में मदद करता है. पहले-ऑर्डर वाले तरीके का इस्तेमाल करता है.
SOLVER_TYPE_ECOS

एम्बेड किया गया कॉनिक सॉल्वर (ईसीओएस) (तीसरा पक्ष).

इसमें, एलपी और एसओसीपी से जुड़ी समस्याओं का इस्तेमाल किया जा सकता है. इंटीरियर पॉइंट मैथड (बैरियर) का इस्तेमाल किया जाता है.
SOLVER_TYPE_SCS

द स्प्लिटिंग कोनिक सॉल्वर (एससीएस) (तीसरा पक्ष).

इसमें, एलपी और एसओसीपी से जुड़ी समस्याओं का इस्तेमाल किया जा सकता है. पहले-ऑर्डर वाले तरीके का इस्तेमाल करता है.
SOLVER_TYPE_HIGHS

HiGHS Sover (तीसरा पक्ष).

यह एलपी और एमआईपी की समस्याओं के साथ काम करता है (कॉन्ट्रैक्ट के क्यूपी लागू नहीं किए जाते).
SOLVER_TYPE_SANTORINI

MathOpt की मदद से, एमआईपी सॉल्वर को लागू करने का तरीका.

धीमा है/इसे प्रोडक्शन के लिए इस्तेमाल करने का सुझाव नहीं दिया जाता है. एलपी सॉल्वर नहीं है (कोई दोहरा जानकारी नहीं मिली).

SosConstraintProto

एक SOS1 या SOS2 कंस्ट्रेंट को दिखाने के लिए डेटा.

अगर इस कंस्ट्रेंट में शामिल किसी वैरिएबल को मिटा दिया जाता है, तो इसे शून्य पर सेट माना जाता है.

फ़ील्ड
expressions[]

LinearExpressionProto

वे एक्सप्रेशन जिन पर SOS कंस्ट्रेंट लागू करना है: * SOS1: अधिकतम एक एलीमेंट गैर-शून्य मान लेता है. * SOS2: ज़्यादा से ज़्यादा दो एलिमेंट, शून्य के अलावा किसी और वैल्यू को लेते हैं और वे दोहराए गए क्रम में साथ-साथ होने चाहिए.
weights[]

double

खाली या एक्सप्रेशन की लंबाई के बराबर होना चाहिए. अगर खाली है, तो डिफ़ॉल्ट वेट 1, 2, ... हैं, तो एंट्री यूनीक होनी चाहिए.
name

string

इस फ़ील्ड पर पैरंट मैसेज की यूनीक वैल्यू हो सकती है. उदाहरण के लिए, ModelProto.sos1_constraints और SosConstraintUpdateProto.new_constraints देखें.

SparseBasisStatusVector

आधार स्थितियों के वेक्टर का विरल निरूपण.

फ़ील्ड
ids[]

int64

सभी एलिमेंट अलग-अलग के साथ क्रम से (बढ़ते क्रम में) लगाए जाने चाहिए.
values[]

BasisStatusProto

आईडी की लंबाई बराबर होनी चाहिए.

SparseDoubleMatrixProto

डबल्स के मैट्रिक्स का सीमित रूप.

मैट्रिक्स को पंक्ति आईडी, कॉलम आईडी, और गुणांक के ट्रिपल के तौर पर स्टोर किया जाता है. इन तीन वेक्टर की लंबाई बराबर होनी चाहिए. सभी i के लिए, टपल (row_ids[i], कॉलम_ids[i]) अलग-अलग होने चाहिए. लाइन में मौजूद एंट्री बड़े क्रम में होनी चाहिए.

फ़ील्ड
row_ids[]

int64
column_ids[]

int64
coefficients[]

double

हो सकता है कि उसमें NaN न हो.

SparseDoubleVectorProto

डबल्स वाले वेक्टर का विरल रूप.

फ़ील्ड
ids[]

int64

सभी एलिमेंट अलग-अलग के साथ क्रम से (बढ़ते क्रम में) लगाए जाने चाहिए.
values[]

double

आईडी की लंबाई बराबर होनी चाहिए. हो सकता है कि उसमें NaN न हो.

SparseInt32VectorProto

इनट्स के वेक्टर का विरल रूप.

फ़ील्ड
ids[]

int64

सभी एलिमेंट अलग-अलग के साथ क्रम में (बढ़ते क्रम में) लगाए जाने चाहिए.
values[]

int32

आईडी की लंबाई बराबर होनी चाहिए.

SparseVectorFilterProto

यह मैसेज आपको SprseXxxxवेक्टर के खास हिस्सों पर क्वेरी करने/सेट करने की अनुमति देता है. डिफ़ॉल्ट तरीका किसी भी चीज़ को फ़िल्टर करना नहीं है. सामान्य इस्तेमाल, सलूशन के सिर्फ़ उन हिस्सों के लिए क्वेरी करना होता है जो शून्य नहीं हैं और/या वैरिएबल की वैल्यू के सिर्फ़ आपके चुने हुए सेट के बारे में क्वेरी करते हैं.

फ़ील्ड
skip_zero_values

bool

SprseBoolTemplateProto के लिए "शून्य" false है.
filter_by_ids

bool

सही होने पर, सिर्फ़ फ़िल्टर किए गए आईडी में दिए गए आईडी से जुड़े मान दिखाएं.
filtered_ids[]

int64

फ़िल्टर_by_ids के सही होने पर, आईडी की सूची का इस्तेमाल किया जाना चाहिए. फ़िल्टर_by_ids के गलत होने पर, फ़ील्ड खाली होना चाहिए. ध्यान दें: अगर यह खाली है और Filter_by_ids सही है, तो इसका मतलब है कि आपको नतीजे में कोई जानकारी नहीं चाहिए.

TerminationProto

कॉल टू Solve() खत्म होने की वजह के बारे में पूरी जानकारी.

फ़ील्ड
reason

TerminationReasonProto

मान TERMINATION_REASON_FEASIBLE या TERMINATION_REASON_NO_SOLUTION_FOUND होने पर limit में अतिरिक्त जानकारी, ज़्यादा जानकारी के लिए limit देखें.
limit

LimitProto

क्या LIMIT_UNSPECIFIED की कोई वैल्यू TERMINATION_REASON_FEASIBLE या TERMINATION_REASON_NO_SOLUTION_FOUND है. सभी सॉल्वर हमेशा उस सीमा का पता नहीं लगा सकते जिससे खाता बंद किया जा सकता है. LIMIT_UNDETERMINED का इस्तेमाल तब किया जाता है, जब इसकी वजह का पता नहीं चल पाता है.
detail

string

समझौता खत्म करने के बारे में, आम तौर पर समाधान करने वाले टूल के बारे में खास जानकारी.
problem_status

ProblemStatusProto

शुरुआती और दोहरी समस्याओं के लिए संभावना की स्थितियां. ऐसा हो सकता है कि यह मैसेज 18 जुलाई, 2023 से उपलब्ध न हो. अगर यह मौजूद नहीं है, तो समस्या_status का पता SolveresultsProto.solve_stats में दिया जा सकता है.
objective_bounds

ObjectiveBoundsProto

सबसे सही मकसद की वैल्यू पर सीमाएं. ऐसा हो सकता है कि यह मैसेज 18 जुलाई, 2023 से उपलब्ध न हो. अगर मौजूद नहीं है, तो Solve_bounds.primal_bound को SolveresultsProto.solve.stats.Best_primal_bound में और purpose_bounds.dual_bound को

TerminationReasonProto

Solve() को कॉल खत्म होने की वजह.

Enums
TERMINATION_REASON_UNSPECIFIED
TERMINATION_REASON_OPTIMAL एक संभावित रूप से सबसे अच्छा समाधान (संख्या वाली सहिष्णुता तक) मिल गया है.
TERMINATION_REASON_INFEASIBLE इस शुरुआती समस्या का कोई संभव समाधान नहीं है.
TERMINATION_REASON_UNBOUNDED प्राथमिक समस्या व्यावहारिक है और प्राइमल रे के साथ मनमाने तरीके से अच्छे समाधान पाए जा सकते हैं.
TERMINATION_REASON_INFEASIBLE_OR_UNBOUNDED शुरुआती समस्या या तो पूरी तरह से खत्म नहीं है या सीमा से ज़्यादा नहीं है. सवाल की स्थिति के बारे में ज़्यादा जानकारी, just_stats.problem_status पर जाकर मिल सकती है. ध्यान दें कि गुरोबी की अनबाउंड स्थिति को यहां मैप किया जा सकता है.
TERMINATION_REASON_IMPRECISE

ऊपर दी गई शर्तों में से किसी एक के आधार पर समस्या हल की गई थी ('इशारे से कम करना', 'आसान नहीं', 'पूरा नहीं हो सकता' या 'अ करने लायक' या 'अ करने लायक' या 'अ करने लायक'), लेकिन एक या एक से ज़्यादा नियम और शर्तें पूरी नहीं की गईं. कुछ मूल/दो तरह के समाधान/रे मौजूद होते हैं, लेकिन या तो वे थोड़े मुमकिन नहीं होंगे या (अगर समस्या काफ़ी हद तक सही थी) उनकी वजह से, सबसे अच्छे समाधान के मकसद और सबसे अच्छे मकसद की सीमा के बीच का अंतर हो सकता है.

उपयोगकर्ता अब भी प्राइमल/ड्यूअल सलूशन/रे और समाधान के आंकड़ों के लिए क्वेरी कर सकते हैं, लेकिन संख्या में होने वाली कमी से निपटने की ज़िम्मेदारी उनकी ही है.
TERMINATION_REASON_FEASIBLE ऑप्टिमाइज़र एक प्रकार की सीमा तक पहुंच गया है और एक वास्तविक संभव समाधान दिया गया है. जिस तरह की सीमा पूरी हुई है उसके बारे में ज़्यादा जानकारी के लिए, SolveProto.limit_detail पर जाएं.
TERMINATION_REASON_NO_SOLUTION_FOUND अनुकूलक एक सीमा तक पहुंच गया और उसे कोई वास्तविक संभव समाधान नहीं मिला. जिस तरह की सीमा पूरी हुई है उसके बारे में ज़्यादा जानकारी के लिए, SolveProto.limit_detail पर जाएं.
TERMINATION_REASON_NUMERICAL_ERROR एल्गोरिदम रुक गया, क्योंकि इसमें संख्या वाली ऐसी गड़बड़ी मिली जिसे ठीक नहीं किया जा सकता. कोई समाधान जानकारी उपलब्ध नहीं है.
TERMINATION_REASON_OTHER_ERROR ऊपर बताई गई किसी भी स्थिति में कोई गड़बड़ी होने की वजह से एल्गोरिदम रुक गया. कोई समाधान जानकारी उपलब्ध नहीं है.

VariablesProto

जैसा कि नीचे इस्तेमाल किया गया है, हम "#variables" = size(VariablesProto.ids) को परिभाषित करते हैं.

फ़ील्ड
ids[]

int64

मैसेज, नेगेटिव न हों और पूरी तरह से बढ़ते हों. max(int64) वैल्यू का इस्तेमाल नहीं किया जा सकता.
lower_bounds[]

double

इसकी लंबाई #variables के बराबर होनी चाहिए, [-inf, inf में वैल्यू).
upper_bounds[]

double

इसकी लंबाई #variables के बराबर होनी चाहिए, वैल्यू (-inf, inf].
integers[]

bool

इसकी लंबाई #variables के बराबर होनी चाहिए. कंटिन्यूअस वैरिएबल के लिए वैल्यू गलत होती है और इंटीजर वैरिएबल के लिए सही होती है.
names[]

string

अगर इस नीति को सेट नहीं किया जाता है, तो इसे सभी खाली स्ट्रिंग माना जाता है. अगर ऐसा नहीं है, तो लंबाई #variables के बराबर होनी चाहिए.

सभी गैर-खाली नाम अलग-अलग होने चाहिए.