Method: mathopt.solveMathOptModel

इनपुट मॉडल को हल करता है और तुरंत नतीजा देता है. इसका इस्तेमाल तब करें, जब आपको कॉलबैक, बढ़ोतरी की ज़रूरत न हो, और समाधान की प्रोग्रेस को ट्रैक करने की ज़रूरत न हो.

एचटीटीपी अनुरोध

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

यह यूआरएल gRPC ट्रांसकोडिंग सिंटैक्स का इस्तेमाल करता है.

अनुरोध का मुख्य भाग

अनुरोध के मुख्य हिस्से में, यहां दिए गए स्ट्रक्चर का डेटा शामिल होता है:

JSON के काेड में दिखाना 
{
  "solverType": enum (SolverTypeProto),
  "model": {
    object (ModelProto)
  },
  "parameters": {
    object (SolveParametersProto)
  },
  "modelParameters": {
    object (ModelSolveParametersProto)
  }
}
फ़ील्ड
solverType

enum (SolverTypeProto)

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

object (ModelProto)

ज़रूरी है. इस उदाहरण में, उस ऑप्टिमाइज़ेशन सवाल को गणित के हिसाब से दिखाया गया है जिसे हल करना है.
parameters

object (SolveParametersProto)

ज़रूरी नहीं. सिंगल सॉल्वर को कंट्रोल करने के लिए पैरामीटर. सक्षम करने वाले आउटपुट पैरामीटर को खास तौर पर हैंडल किया जाता है. मैसेज कॉलबैक के साथ काम करने वाले सॉल्वर के लिए, इसे 'सही' पर सेट करने के लिए सर्वर, मैसेज कॉलबैक को रजिस्टर करेगा. नतीजे के तौर पर मिलने वाले मैसेज के लिए, SummaryMathOptModelResponse.messages दिखाए जाएंगे. अन्य सॉल्वर के लिए, चालू करने के विकल्प को 'सही' पर सेट करने से गड़बड़ी होगी.
modelParameters

object (ModelSolveParametersProto)

ज़रूरी नहीं. इनपुट मॉडल के लिए खास एक सॉल्वर को कंट्रोल करने के लिए पैरामीटर. (मॉडल इंडिपेंडेंट पैरामीटर के लिए हल पैरामीटर प्रोटो देखें).

जवाब का मुख्य भाग

MathOpt में, सिंगल रिमोट तरीके से समाधान करने का रिस्पॉन्स दिया जाता है.

अगर एपीआई सही से जुड़ जाता है, ताे जवाब के मुख्य भाग में नीचे दिए गए स्ट्रक्चर शामिल होता है.

JSON के काेड में दिखाना 
{
  "result": {
    object (SolveResultProto)
  },
  "messages": [
    string
  ]
}
फ़ील्ड
result

object (SolveResultProto)

अनुरोध में मॉडल को हल करने के नतीजे के बारे में जानकारी.
messages[]

string

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

SolverTypeProto

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

Enums
SOLVER_TYPE_UNSPECIFIED
SOLVER_TYPE_GSCIP

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

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

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

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

Google का Glop सॉल्वर.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LP और SOCP से जुड़ी समस्याओं के साथ काम करता है. पहले ऑर्डर वाले तरीके का इस्तेमाल करता है.
SOLVER_TYPE_HIGHS

HiGHS सॉल्वर (तीसरा पक्ष).

LP और MIP से जुड़ी समस्याओं के साथ काम करता है. 'कन्वर्ज़न के क्यूपी' को लागू नहीं किया गया है.
SOLVER_TYPE_SANTORINI

MIP सॉल्वर के लिए, MathOpt की रेफ़रंस के तौर पर दी गई वैल्यू लागू करना.

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

ModelProto

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

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

JSON के काेड में दिखाना 
{
  "name": string,
  "variables": {
    object (VariablesProto)
  },
  "objective": {
    object (ObjectiveProto)
  },
  "auxiliaryObjectives": {
    string: {
      object (ObjectiveProto)
    },
    ...
  },
  "linearConstraints": {
    object (LinearConstraintsProto)
  },
  "linearConstraintMatrix": {
    object (SparseDoubleMatrixProto)
  },
  "quadraticConstraints": {
    string: {
      object (QuadraticConstraintProto)
    },
    ...
  },
  "secondOrderConeConstraints": {
    string: {
      object (SecondOrderConeConstraintProto)
    },
    ...
  },
  "sos1Constraints": {
    string: {
      object (SosConstraintProto)
    },
    ...
  },
  "sos2Constraints": {
    string: {
      object (SosConstraintProto)
    },
    ...
  },
  "indicatorConstraints": {
    string: {
      object (IndicatorConstraintProto)
    },
    ...
  }
}
फ़ील्ड
name

string
variables

object (VariablesProto)
objective

object (ObjectiveProto)

मॉडल का मुख्य मकसद.
auxiliaryObjectives

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

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

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

एक ऑब्जेक्ट, जिसमें "key": value पेयर की सूची है. उदाहरण: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
linearConstraints

object (LinearConstraintsProto)
linearConstraintMatrix

object (SparseDoubleMatrixProto)

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

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

आवश्यकताएँ: * लीनियरConstraintMatrix.row_ids, LineConstraints.ids के एलिमेंट हैं. * levelConstraintMatrix.column_ids, वैरिएबल.आईडी के एलिमेंट हैं. * जिन मैट्रिक्स एंट्री की जानकारी नहीं दी गई है वे शून्य हैं. * relatedConstraintMatrix.values, सभी वैल्यू सीमित होनी चाहिए.
quadraticConstraints

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

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

एक ऑब्जेक्ट, जिसमें "key": value पेयर की सूची है. उदाहरण: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
secondOrderConeConstraints

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

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

एक ऑब्जेक्ट, जिसमें "key": value पेयर की सूची है. उदाहरण: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
sos1Constraints

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

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

एक ऑब्जेक्ट, जिसमें "key": value पेयर की सूची है. उदाहरण: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
sos2Constraints

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

मॉडल में एसओएस 2 कंस्ट्रेंट, जो यह सीमित करता है कि expression की ज़्यादा से ज़्यादा दो एंट्री शून्य हो सकती हैं और उन्हें उनके क्रम के बगल में होना चाहिए. अगर कोई weights नहीं दिया गया है, तो expressions सूची में यह क्रम लीनियर है; अगर weights दिखाया गया है, तो इन वैल्यू के हिसाब से ऑर्डर को बढ़ते क्रम में लिया जाता है.

एक ऑब्जेक्ट, जिसमें "key": value पेयर की सूची है. उदाहरण: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
indicatorConstraints

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

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

एक ऑब्जेक्ट, जिसमें "key": value पेयर की सूची है. उदाहरण: { "name": "wrench", "mass": "1.3kg", "count": "3" }.

VariablesProto

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

JSON के काेड में दिखाना 
{
  "ids": [
    string
  ],
  "lowerBounds": [
    number
  ],
  "upperBounds": [
    number
  ],
  "integers": [
    boolean
  ],
  "names": [
    string
  ]
}
फ़ील्ड
ids[]

string (int64 format)

यह नकारात्मक नहीं होना चाहिए और इसे पूरी तरह से बढ़ाना चाहिए. Max(int64) वैल्यू का इस्तेमाल नहीं किया जा सकता.
lowerBounds[]

number

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

number

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

boolean

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

string

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

जो नाम खाली नहीं हैं उनके नाम अलग-अलग होने चाहिए.

ObjectiveProto

JSON के काेड में दिखाना 
{
  "maximize": boolean,
  "offset": number,
  "linearCoefficients": {
    object (SparseDoubleVectorProto)
  },
  "quadraticCoefficients": {
    object (SparseDoubleMatrixProto)
  },
  "name": string,
  "priority": string
}
फ़ील्ड
maximize

boolean

गलत का मतलब छोटा होना है, सही का मतलब है सबसे बड़ा
offset

number

सीमित होना चाहिए, NaN नहीं.
linearCoefficients

object (SparseDoubleVectorProto)

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

शर्तें: * लीनियरकॉफ़िशिएंट.आईडी, वैरिएबलsProto.ids के एलिमेंट होते हैं. * वैरिएबल प्रोटो शून्य से संबंधित नहीं है. * LineCoefficients.values की वैल्यू सीमित होनी चाहिए. * लीनियरकॉफ़िशिएंट.वैल्यू शून्य हो सकती है. हालांकि, इससे सिर्फ़ स्टोरेज की बर्बादी होती है.
quadraticCoefficients

object (SparseDoubleMatrixProto)

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

SparseDoubleClickMatrixProto मैसेज के लिए शर्तें: * quadraticCoefficients.row_ids का हर एक एलिमेंट और quadraticCoefficients.column_ids का हर एक एलिमेंट, वैरिएबलsProto.ids का एलिमेंट होना चाहिए. * मैट्रिक्स को ऊपरी त्रिभुज के आकार में होना चाहिए: हर i के लिए, quadraticCoefficients.row_ids[i] <= quadraticCoefficients.column_ids[i].

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

string

इस फ़ील्ड में, माता-पिता के मैसेज के लिए ज़रूरी शर्तें हो सकती हैं; उदाहरण के लिए, ModelProto.objectives and AuxiliaryObjectivesUpdateProto.new_objectives देखें.
priority

string (int64 format)

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

SparseDoubleVectorProto

डबल्स के वेक्टर को कम दिखाने वाली इमेज.

JSON के काेड में दिखाना 
{
  "ids": [
    string
  ],
  "values": [
    number
  ]
}
फ़ील्ड
ids[]

string (int64 format)

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

number

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

SparseDoubleMatrixProto

दो संख्याओं के मैट्रिक्स का विरल तरीके से दिखाया गया है.

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

JSON के काेड में दिखाना 
{
  "rowIds": [
    string
  ],
  "columnIds": [
    string
  ],
  "coefficients": [
    number
  ]
}
फ़ील्ड
rowIds[]

string (int64 format)
columnIds[]

string (int64 format)
coefficients[]

number

इसमें NaN शामिल नहीं हो सकता.

LinearConstraintsProto

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

JSON के काेड में दिखाना 
{
  "ids": [
    string
  ],
  "lowerBounds": [
    number
  ],
  "upperBounds": [
    number
  ],
  "names": [
    string
  ]
}
फ़ील्ड
ids[]

string (int64 format)

यह नकारात्मक नहीं होना चाहिए और इसे पूरी तरह से बढ़ाना चाहिए. Max(int64) वैल्यू का इस्तेमाल नहीं किया जा सकता.
lowerBounds[]

number

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

number

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

string

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

जो नाम खाली नहीं हैं उनके नाम अलग-अलग होने चाहिए.

QuadraticConstraintProto

फ़ॉर्म का एक क्वाड्रेटिक कंस्ट्रेंट: lb <= sum{linearTerms} + sum{quadraticTerms} <= ub.

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

JSON के काेड में दिखाना 
{
  "linearTerms": {
    object (SparseDoubleVectorProto)
  },
  "quadraticTerms": {
    object (SparseDoubleMatrixProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string
}
फ़ील्ड
linearTerms

object (SparseDoubleVectorProto)

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

SparseDoubleClickWriteProto मैसेज की ज़रूरी शर्तों के अलावा, हमारे लिए यह भी ज़रूरी है कि: * LowलीनियरTerms.ids, वैरिएबलsProto.ids के एलिमेंट हैं. * लीनियर शर्तें.वैल्यू सभी सीमित होनी चाहिए और NaN नहीं होनी चाहिए.

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

object (SparseDoubleMatrixProto)

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

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

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

number

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

number

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

string

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

SecondOrderConeConstraintProto

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

|argumentsToNorm||_2 <= upperBound,

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

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

JSON के काेड में दिखाना 
{
  "upperBound": {
    object (LinearExpressionProto)
  },
  "argumentsToNorm": [
    {
      object (LinearExpressionProto)
    }
  ],
  "name": string
}
फ़ील्ड
upperBound

object (LinearExpressionProto)
argumentsToNorm[]

object (LinearExpressionProto)
name

string

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

LinearExpressionProto

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

JSON के काेड में दिखाना 
{
  "ids": [
    string
  ],
  "coefficients": [
    number
  ],
  "offset": number
}
फ़ील्ड
ids[]

string (int64 format)

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

number

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

number

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

SosConstraintProto

एक एसओएस1 या एसओएस 2 कंस्ट्रेंट को दिखाने के लिए डेटा.

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

JSON के काेड में दिखाना 
{
  "expressions": [
    {
      object (LinearExpressionProto)
    }
  ],
  "weights": [
    number
  ],
  "name": string
}
फ़ील्ड
expressions[]

object (LinearExpressionProto)

वे एक्सप्रेशन जिन पर एसओएस कंस्ट्रेंट लागू करना है: * एसओएस1: ज़्यादा से ज़्यादा एक एलिमेंट गैर-शून्य वैल्यू लेता है. * एसओएस2: ज़्यादा से ज़्यादा दो एलिमेंट, शून्य के अलावा किसी और वैल्यू को नहीं लेते हैं. इसलिए, वे बार-बार एक ही क्रम में होने चाहिए.
weights[]

number

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

string

इस फ़ील्ड में, माता-पिता के मैसेज के लिए ज़रूरी शर्तें हो सकती हैं; उदाहरण के लिए, ModelProto.sos1_constraints और SosConstraint UpdatesProto.new_constraints.

IndicatorConstraintProto

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

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

JSON के काेड में दिखाना 
{
  "activateOnZero": boolean,
  "expression": {
    object (SparseDoubleVectorProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string,
  "indicatorId": string
}
फ़ील्ड
activateOnZero

boolean

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

object (SparseDoubleVectorProto)

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

number

[-inf, inf] में वैल्यू होनी चाहिए; NaN नहीं हो सकता.
upperBound

number

वैल्यू (-inf, inf] में होनी चाहिए; NaN नहीं होनी चाहिए.
name

string

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

string (int64 format)

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

SolveParametersProto

सिंगल सॉल्वर को कंट्रोल करने के लिए पैरामीटर.

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

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

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

ऐसे पैरामीटर जो मॉडल पर निर्भर करते हैं (जैसे कि हर वैरिएबल के लिए ब्रांचिंग की प्राथमिकता सेट की गई है), उन्हें ModelSolveParametersProto में पास किया जाता है.

JSON के काेड में दिखाना 
{
  "timeLimit": string,
  "enableOutput": boolean,
  "lpAlgorithm": enum (LPAlgorithmProto),
  "presolve": enum (EmphasisProto),
  "cuts": enum (EmphasisProto),
  "heuristics": enum (EmphasisProto),
  "scaling": enum (EmphasisProto),
  "iterationLimit": string,
  "nodeLimit": string,
  "cutoffLimit": number,
  "objectiveLimit": number,
  "bestBoundLimit": number,
  "solutionLimit": integer,
  "threads": integer,
  "randomSeed": integer,
  "absoluteGapTolerance": number,
  "relativeGapTolerance": number,
  "solutionPoolSize": integer
}
फ़ील्ड
timeLimit

string (Duration format)

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

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

सेकंड में कुल नौ दशमलव अंक, जो 's' पर खत्म होते हैं. उदाहरण: "3.5s".
enableOutput

boolean

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

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

enum (LPAlgorithmProto)

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

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

enum (EmphasisProto)

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

enum (EmphasisProto)

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

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

enum (EmphasisProto)

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

enum (EmphasisProto)

अंकों की स्थिरता में सुधार करने के लिए समस्या को हल करने की कोशिश करें या https_UNSPECIFIED होने पर सॉल्वर के डिफ़ॉल्ट कोशिश लेवल को बेहतर बनाएं.
iterationLimit

string (int64 format)

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

आम तौर पर, LP, QP, और MIP सॉल्वर के साथ काम करते हैं, लेकिन MIP सॉल्वर के लिए, nodelimit का इस्तेमाल किया जाता है.
nodeLimit

string (int64 format)

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

आम तौर पर, MIP सॉल्वर के लिए बार-बार इस्तेमाल करने की सीमा भी देखें.
cutoffLimit

number

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

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

अगर आपको कटऑफ़ के बराबर ऐसे समाधान चाहिए जो कटऑफ़ समय के बराबर हों, तो टालने की सुविधा का इस्तेमाल करें.

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

number

सॉल्वर को जैसे ही कोई अच्छा समाधान मिलता है, वह जल्दी बंद हो जाता है. उसे खत्म करने की वजह FEASIBLE होती है और Objective को सीमित कर दिया जाता है.
bestBoundLimit

number

जैसे ही सॉल्वर यह साबित कर देता है कि उसकी सबसे अच्छी सीमा कम से कम एक अच्छी सीमा है, तो उसे खत्म करने की वजह FEASIBLE या NO_SOLUTION_FOUND और OBJECTIVE को सीमित करें.

ज़्यादा जानकारी और कटऑफ़ लिमिट के साथ तुलना करने के लिए, इस्तेमाल के लिए गाइड देखें.
solutionLimit

integer

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

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

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

integer

अगर यह वैल्यू सेट है, तो यह >= 1 होनी चाहिए.
randomSeed

integer

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

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

number

एमआईपी सॉल्वर के लिए, डिवाइस इस्तेमाल करने की पूरी क्षमता (मुख्य तौर पर).

निरपेक्ष GAP, अंतर का निरपेक्ष मान है: * खोज में पाया गया सबसे कारगर समाधान का ऑब्जेक्टिव वैल्यू, * खोज से मिलने वाला ड्यूअल बाउंड. जब निरपेक्ष GAP अधिकतम GapTolerance (सेट होने पर) हो जाता है, तब सॉल्वर रुक सकता है और TERMINATION_REASON_OPTIMAL लौटा सकता है.

अगर यह वैल्यू सेट की गई है, तो वैल्यू >= 0 होनी चाहिए.

relatedGapTolerance भी देखें.
relativeGapTolerance

number

MIP सॉल्वर के लिए एक सापेक्षिक इष्टतमता सहनशीलता (मुख्य रूप से).

रिलेटिव GAP, ऐब्सलूट GAP का नॉर्मलाइज़्ड वर्शन है. इसे असल इसके लिए, कुल GAP को, सबसे किफ़ायती समाधान के मकसद वैल्यू से भाग दिया जाता है.

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

अगर यह वैल्यू सेट की गई है, तो वैल्यू >= 0 होनी चाहिए.

TotalGapTolerance भी देखें.
solutionPoolSize

integer

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

LPAlgorithmProto

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

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

EmphasisProto

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

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

Enums
EMPHASIS_UNSPECIFIED
EMPHASIS_OFF
EMPHASIS_LOW
EMPHASIS_MEDIUM
EMPHASIS_HIGH
EMPHASIS_VERY_HIGH

ModelSolveParametersProto

JSON के काेड में दिखाना 
{
  "variableValuesFilter": {
    object (SparseVectorFilterProto)
  },
  "dualValuesFilter": {
    object (SparseVectorFilterProto)
  },
  "reducedCostsFilter": {
    object (SparseVectorFilterProto)
  },
  "initialBasis": {
    object (BasisProto)
  },
  "solutionHints": [
    {
      object (SolutionHintProto)
    }
  ],
  "branchingPriorities": {
    object (SparseInt32VectorProto)
  }
}
फ़ील्ड
variableValuesFilter

object (SparseVectorFilterProto)

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

ज़रूरी शर्तें: * फ़िल्टर किए गए आईडी, वैरिएबलsProto.ids के एलिमेंट होते हैं.
dualValuesFilter

object (SparseVectorFilterProto)

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

ज़रूरतें: * फ़िल्टर किए गए आईडी, लीनियरConstraints.ids के एलिमेंट होते हैं.
reducedCostsFilter

object (SparseVectorFilterProto)

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

ज़रूरी शर्तें: * फ़िल्टर किए गए आईडी, वैरिएबलsProto.ids के एलिमेंट होते हैं.
initialBasis

object (BasisProto)

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

object (SolutionHintProto)

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

object (SparseInt32VectorProto)

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

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

SparseVectorFilterProto

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

JSON के काेड में दिखाना 
{
  "skipZeroValues": boolean,
  "filterByIds": boolean,
  "filteredIds": [
    string
  ]
}
फ़ील्ड
skipZeroValues

boolean

SparseBoolvectorProto "zero" के लिए false है.
filterByIds

boolean

सही होने पर, फ़िल्टर की गई आईडी में मौजूद आईडी की वैल्यू ही दिखाएं.
filteredIds[]

string (int64 format)

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

BasisProto

लीनियर प्रोग्राम के किसी हल के लिए कॉम्बिनेटियल कैरेक्टराइज़ेशन.

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

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

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

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

JSON के काेड में दिखाना 
{
  "constraintStatus": {
    object (SparseBasisStatusVector)
  },
  "variableStatus": {
    object (SparseBasisStatusVector)
  },
  "basicDualFeasibility": enum (SolutionStatusProto)
}
फ़ील्ड
constraintStatus

object (SparseBasisStatusVector)

कंस्ट्रेंट के आधार की स्थिति.

शर्तें: * constraintStatus.ids, लीनियरConstraints.ids के बराबर है.
variableStatus

object (SparseBasisStatusVector)

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

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

enum (SolutionStatusProto)

यह एक बेहतर सुविधा है, जिसका इस्तेमाल MathOpt से, कम बेहतर LP समाधानों की संभावना की जानकारी देने के लिए किया जाता है. सबसे बेहतरीन समाधान का स्टेटस हमेशा SOLUTION_STATUS_FEASIBLE होगा.

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

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

SparseBasisStatusVector

आधार स्थितियों के वेक्टर को विरल तरीके से दिखाया गया.

JSON के काेड में दिखाना 
{
  "ids": [
    string
  ],
  "values": [
    enum (BasisStatusProto)
  ]
}
फ़ील्ड
ids[]

string (int64 format)

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

enum (BasisStatusProto)

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

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 वैरिएबल/कंस्ट्रेंट बुनियादी है.

SolutionStatusProto

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

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

SolutionHintProto

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

MIP सॉल्वर को आम तौर पर, सिर्फ़ बुनियादी जानकारी (variableValues) चाहिए, जबकि LP सॉल्वर को प्राइमल और ड्यूअल जानकारी, दोनों चाहिए (dualValues).

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

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

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

JSON के काेड में दिखाना 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "dualValues": {
    object (SparseDoubleVectorProto)
  }
}
फ़ील्ड
variableValues

object (SparseDoubleVectorProto)

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

object (SparseDoubleVectorProto)

सवाल के लीनियर कंस्ट्रेंट के लिए, वैल्यू का (संभावित तौर पर आंशिक) असाइनमेंट.

आवश्यकताएँ: * DualValues.ids, लीनियरConstraintsProto.ids के एलिमेंट हैं. * DualValues.values की वैल्यू सीमित होनी चाहिए.

SparseInt32VectorProto

पूर्णांकों के वेक्टर का विरल रूप.

JSON के काेड में दिखाना 
{
  "ids": [
    string
  ],
  "values": [
    integer
  ]
}
फ़ील्ड
ids[]

string (int64 format)

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

integer

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

SolveResultProto

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

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

JSON के काेड में दिखाना 
{
  "termination": {
    object (TerminationProto)
  },
  "solutions": [
    {
      object (SolutionProto)
    }
  ],
  "primalRays": [
    {
      object (PrimalRayProto)
    }
  ],
  "dualRays": [
    {
      object (DualRayProto)
    }
  ],
  "solveStats": {
    object (SolveStatsProto)
  }
}
फ़ील्ड
termination

object (TerminationProto)

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

object (SolutionProto)

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

object (PrimalRayProto)

बिना किसी सीमा के बुनियादी सुधार या इस तरह के ड्यूअल इनबिलिटी सर्टिफ़िकेट के बारे में निर्देश. आम तौर पर, EndREASONProtos UNBOUNDED और DUAL_INFEASIBLE के लिए दिया जाता है
dualRays[]

object (DualRayProto)

बिना किसी सीमा के दोहराए जाने वाले सुधार या इसी तरह के, बुनियादी तौर पर संभव न होने वाले सर्टिफ़िकेट के बारे में बताने के लिए. आम तौर पर, यह सेवा तब उपलब्ध कराई जाती है, जब खत्म होने की वजह से, नुकसान पहुंचाने वाली चीज़ें शामिल न हो पाएं.
solveStats

object (SolveStatsProto)

सवाल हल करने की प्रोसेस के आंकड़े, जैसे कि उसे चलाने का समय, उसे पूरा करने में लगने वाला समय.

TerminationProto

कॉल टू सलूशन() क्यों खत्म किया गया, इसके बारे में पूरी जानकारी.

JSON के काेड में दिखाना 
{
  "reason": enum (TerminationReasonProto),
  "limit": enum (LimitProto),
  "detail": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "objectiveBounds": {
    object (ObjectiveBoundsProto)
  }
}
फ़ील्ड
reason

enum (TerminationReasonProto)

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

enum (LimitProto)

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

string

आम तौर पर, कानूनी समझौता खत्म करने के बारे में खास जानकारी.
problemStatus

object (ProblemStatusProto)

प्राइमल और ड्यूअल प्रॉब्लम के लिए संभावना की स्थितियां. ऐसा हो सकता है कि 18 जुलाई, 2023 से यह मैसेज न दिखे. अगर यह जानकारी मौजूद नहीं है, तोकैंपेन को हल करने के नतीजे प्रोटो.solve_stats पर जाकर देखा जा सकता है.
objectiveBounds

object (ObjectiveBoundsProto)

सबसे बेहतर मकसद की वैल्यू से जुड़ा होता है. ऐसा हो सकता है कि 18 जुलाई, 2023 से यह मैसेज न दिखे. अगर यह जानकारी मौजूद नहीं है, तो criteriaBounds.primal_bound को क्वेरी नतीजेProto.solve.stats.best_primal_bound में पाया जा सकता है, और criteriaBounds.dual_bound को एनएसएलप्रोटो.सॉल्व.स्टैट्स.बेस्ट_dual_bound में पाया जा सकता है

TerminationReasonProto

इस वजह से, Solutions() वाला कॉल खत्म हो जाता है.

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

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

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

LimitProto

जब रिज़ॉल्व() बार खत्म होने के बाद खत्म हो जाता है, तो वह खास सीमा पूरी हो जाती है. इसके साथ ही, EarthReasonProto FEASIBLE या NO_SOLUTION_FOUND को शामिल किया जाता है.

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

ऊपर दी गई किसी एक सीमा में बदलाव न होने की वजह से, एल्गोरिदम रुक गया है. ध्यान दें कि LIMIT_UNDETERMINED का उपयोग तब किया जाता है जब कारण का पता नहीं चलता और LIMIT_OTHER का उपयोग तब किया जाता है जब कारण ज्ञात हो लेकिन ऊपर दिए गए किसी भी विकल्प के साथ फ़िट नहीं होता हो.

EndProto.detail में इस सीमा के बारे में ज़्यादा जानकारी मौजूद हो सकती है.

ProblemStatusProto

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

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

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

JSON के काेड में दिखाना 
{
  "primalStatus": enum (FeasibilityStatusProto),
  "dualStatus": enum (FeasibilityStatusProto),
  "primalOrDualInfeasible": boolean
}
फ़ील्ड
primalStatus

enum (FeasibilityStatusProto)

प्राइमल प्रॉब्लम की स्थिति.
dualStatus

enum (FeasibilityStatusProto)

दोहरी समस्या की स्थिति (या लगातार सुकून पाने की स्थिति) की स्थिति.
primalOrDualInfeasible

boolean

अगर सही है, तो सॉल्वर दावा करता है कि ओरिजनल या दोहराई गई समस्या मुश्किल है. हालांकि, उसे यह नहीं पता होता कि कौन-कौनसी समस्या (या दोनों मुश्किल है) हैं. primal_problem_status = Dual_problem_status = kUndetermined होने पर ही सही हो सकता है. आम तौर पर, इस अतिरिक्त जानकारी की ज़रूरत तब होती है, जब प्री-प्रोसेसिंग से पता चलता है कि समस्या का कोई बेहतर समाधान नहीं है. हालांकि, यह तय नहीं किया जा सकता कि ऐसा समस्या के अंजाम, बेहिसाब या दोनों की वजह से हुआ है.

FeasibilityStatusProto

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

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

ObjectiveBoundsProto

सबसे बेहतर मकसद की वैल्यू से जुड़ा होता है.

JSON के काेड में दिखाना 
{
  "primalBound": number,
  "dualBound": number
}
फ़ील्ड
primalBound

number

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

number

सॉल्वर का दावा है कि सॉल्वर यह दावा करता है कि सॉल्वर उससे जुड़ी कोई सीमा नहीं होने का दावा नहीं करता. सॉल्वर में यह दावा किया जाता है कि सॉल्वर की ड्यूअल बाउंड्री के मुकाबले, सबसे अच्छी वैल्यू, दोगुनी संख्या के बराबर या खराब (कम करने के लिए बड़ा और साइज़ बढ़ाने के लिए कम) है. इसके लिए, नीचे दी गई चेतावनी देखें: * ड्यूअलबाउंड वैल्यू छोटी है (-कम करने और +कम करने के लिए इनपुट की ज़्यादा वैल्यू). प्राइमलबाउंड की तरह ही, कुछ सॉल्वर के मामले में ऐसा हो सकता है, भले ही वे बेहतर नतीजे देते हों. MIP सॉल्वर आम तौर पर बाउंड की रिपोर्ट करते हैं, भले ही वह सटीक न हो. * लगातार समस्याओं के लिए DualBound, सबसे अच्छे ड्यूअल मुमकिन समाधान के मकसद से ज़्यादा बेहतर वैल्यू के करीब हो सकता है. MIP के लिए DualBound के लिए शुरुआती नॉन-ट्रिवियल वैल्यू, अक्सर MIP के LP छूट की सबसे अच्छी वैल्यू होती है. * सॉल्वर की सहनशीलता तक प्राइमलबाउंड की तुलना में DualBound, बेहतर (कम करने के लिए छोटा और बड़ा करने के लिए बड़ा) बेहतर होना चाहिए (नीचे चेतावनी देखें). चेतावनी: * लगातार समस्याओं के लिए, सटीक दावा यह है कि इसमें दोहरा समाधान मौजूद है जो: * अंकों में संभव है (यानी कि सॉल्वर की बर्दाश्त के हिसाब से संभव है) और * का मकसद DualBound है. संख्या के तौर पर मुमकिन समाधान थोड़ा मुश्किल हो सकता है. इस स्थिति में DualBound, सबसे अच्छी वैल्यू और प्राइमलबाउंड से बेहद खराब हो सकता है. प्राइमल केस की तरह, ड्यूअल फ़िशेबिलिटी सहिष्णुता की तुलना DualBound पर सहनशीलता में करना सामान्य नहीं है. ऐसा खास तौर पर तब होता है, जब मुमकिन है कि सहनशीलता ज़्यादा हो. हालांकि, कुछ सॉल्वर ड्यूअलबाउंड का सही वर्शन उपलब्ध कराते हैं, जो अंकों के हिसाब से सुरक्षित हो सकता है. ठीक किए गए इस वर्शन को, सॉल्वर के खास आउटपुट के ज़रिए ऐक्सेस किया जा सकता है. उदाहरण के लिए, PDLP, pdlp_Output.convergence_information. जिनसेएड_dual_objective के लिए. * MIP सॉल्वर के लिए, DualBound, थोड़ी-बहुत सुकून पाने के लिए, एक ड्यूअल सलूशन के साथ जुड़ा हो सकता है. जैसे, एलपी में मिलने वाली छूट. हालांकि, यह अक्सर सॉल्वर के एक्ज़ीक्यूट करने की वजह से जटिल होता है. आम तौर पर, यह एलपी सॉल्वर की रिपोर्ट से ज़्यादा सटीक होता है.

SolutionProto

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

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

JSON के काेड में दिखाना 
{
  "primalSolution": {
    object (PrimalSolutionProto)
  },
  "dualSolution": {
    object (DualSolutionProto)
  },
  "basis": {
    object (BasisProto)
  }
}
फ़ील्ड
primalSolution

object (PrimalSolutionProto)
dualSolution

object (DualSolutionProto)
basis

object (BasisProto)

PrimalSolutionProto

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

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

JSON के काेड में दिखाना 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "objectiveValue": number,
  "auxiliaryObjectiveValues": {
    string: number,
    ...
  },
  "feasibilityStatus": enum (SolutionStatusProto)
}
फ़ील्ड
variableValues

object (SparseDoubleVectorProto)

शर्तें: * variablesValues.ids, वैरिएबलsProto.ids के एलिमेंट हैं. * VariableValues.values सभी सीमित होने चाहिए.
objectiveValue

number

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

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

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

एक ऑब्जेक्ट, जिसमें "key": value पेयर की सूची है. उदाहरण: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
feasibilityStatus

enum (SolutionStatusProto)

दिए गए सॉल्वर के हिसाब से, समाधान की संभावना की स्थिति.

DualSolutionProto

ऑप्टिमाइज़ेशन की दो समस्याओं का हल.

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

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

JSON के काेड में दिखाना 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  },
  "feasibilityStatus": enum (SolutionStatusProto),
  "objectiveValue": number
}
फ़ील्ड
dualValues

object (SparseDoubleVectorProto)

आवश्यकताएँ: * DualValues.ids, लीनियरConstraints.ids के एलिमेंट हैं. * DualValues.values की वैल्यू सीमित होनी चाहिए.
reducedCosts

object (SparseDoubleVectorProto)

आवश्यकताएँ: * LowCosts.ids, वैरिएबलsProto.ids के एलिमेंट हैं. * कम की गई लागत.इन सभी की वैल्यू सीमित होनी चाहिए.
feasibilityStatus

enum (SolutionStatusProto)

दिए गए सॉल्वर के हिसाब से, समाधान की संभावना की स्थिति.
objectiveValue

number

PrimalRayProto

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

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

नीचे दिए गए PrimalRay मैसेज में वैरिएबल की वैल्यू x है.

JSON के काेड में दिखाना 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  }
}
फ़ील्ड
variableValues

object (SparseDoubleVectorProto)

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

DualRayProto

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

उदाहरण के लिए, प्राइमल ड्यूअल पेयर लीनियर प्रोग्राम पेयर का इस्तेमाल करें: (शुरुआती) (ड्यूअल) कम से कम c * x max b * y s.t. A * x >= bst. 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 को DualValues कहते हैं और r को कम किया जाता है.

JSON के काेड में दिखाना 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  }
}
फ़ील्ड
dualValues

object (SparseDoubleVectorProto)

आवश्यकताएँ: * DualValues.ids, लीनियरConstraints.ids के एलिमेंट हैं. * DualValues.values की वैल्यू सीमित होनी चाहिए.
reducedCosts

object (SparseDoubleVectorProto)

आवश्यकताएँ: * LowCosts.ids, वैरिएबलsProto.ids के एलिमेंट हैं. * कम की गई लागत.इन सभी की वैल्यू सीमित होनी चाहिए.

SolveStatsProto

JSON के काेड में दिखाना 
{
  "solveTime": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "simplexIterations": string,
  "barrierIterations": string,
  "firstOrderIterations": string,
  "nodeCount": string
}
फ़ील्ड
solveTime

string (Duration format)

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

सेकंड में कुल नौ दशमलव अंक, जो 's' पर खत्म होते हैं. उदाहरण: "3.5s".
problemStatus

object (ProblemStatusProto)

प्राइमल और ड्यूअल प्रॉब्लम के लिए संभावना की स्थितियां.
simplexIterations

string (int64 format)
barrierIterations

string (int64 format)
firstOrderIterations

string (int64 format)
nodeCount

string (int64 format)