Method: mathopt.solveMathOptModel

הפונקציה פותרת את מודל הקלט ומחזירה את התוצאה בבת אחת. אפשר להשתמש באפשרות הזו כשאין לך צורך בקריאות חוזרות (callbacks) או בהמרות מצטברות, ואין לך צורך לעקוב אחר ההתקדמות של פתרון.

בקשת HTTP

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

בכתובת ה-URL נעשה שימוש בתחביר המרת קידוד של gRPC.

גוף הבקשה

גוף הבקשה מכיל נתונים במבנה הבא:

ייצוג JSON 
{
  "solverType": enum (SolverTypeProto),
  "model": {
    object (ModelProto)
  },
  "parameters": {
    object (SolveParametersProto)
  },
  "modelParameters": {
    object (ModelSolveParametersProto)
  }
}
שדות
solverType

enum (SolverTypeProto)

זה שינוי אופציונלי. סוג הפותר כדי לפתור את הבעיה מבחינה מספרית. שימו לב שאם פותר לא תומך בתכונה מסוימת במודל, תהליך האופטימיזציה לא יצליח.
model

object (ModelProto)

חובה. ייצוג מתמטי של בעיית האופטימיזציה שצריך לפתור.
parameters

object (SolveParametersProto)

זה שינוי אופציונלי. פרמטרים לשליטה בפתרון יחיד. הפרמטר EnableOutput (הפעלת) מטופל באופן ספציפי. לפותרים שתומכים בקריאות חוזרות (callback) של הודעות, אם מגדירים את הערך True, השרת ירשום קריאה חוזרת (callback) של הודעה. ההודעות שייווצרו יוחזרו ב-SolveMathOptModelResponse.messages. בפתרונות אחרים, הגדרת EnableOutput ל-true תגרום לשגיאה.
modelParameters

object (ModelSolveParametersProto)

זה שינוי אופציונלי. פרמטרים לשליטה בפתרון יחיד שהם ספציפיים למודל הקלט (ב-SolveParametersProto מפורטים פרמטרים בלתי תלויים במודל).

גוף התשובה

תשובה לפתרון מרחוק של Unary ב-MathOpt.

אם הפעולה בוצעה ללא שגיאות, גוף התגובה יכיל נתונים במבנה הבא:

ייצוג JSON 
{
  "result": {
    object (SolveResultProto)
  },
  "messages": [
    string
  ]
}
שדות
result

object (SolveResultProto)

תיאור הפלט של פתרון המודל בבקשה.
messages[]

string

אם נעשה שימוש ב-SolveParametersProto.enable_output, ההודעה תכלול הודעות יומן לפותרים שתומכים בקריאות חוזרות (callbacks) של הודעות.

SolverTypeProto

הפותרים שנתמכים על ידי MathOpt.

טיפוסים בני מנייה (enum)
SOLVER_TYPE_UNSPECIFIED
SOLVER_TYPE_GSCIP

פותר בעיות שקשורות למגבלות של תוכניות מספרים שלמים (SCIP) (צד שלישי).

תומכת בבעיות ריבועיות מסוג LP, MIP ומספרים שלמים לא קמורים. עם זאת, לא מוחזרים נתונים כפולים עבור דפי הנחיתה. יש לי העדפה ל-GLOP בדפי נחיתה.
SOLVER_TYPE_GUROBI

פותר Gurobi (צד שלישי).

תומכת בבעיות ריבועיות מסוג LP, MIP ומספרים שלמים לא קמורים. האפשרות המהירה ביותר בדרך כלל, אבל יש לה רישוי מיוחד.
SOLVER_TYPE_GLOP

פותר ה-Glop של Google.

תומכת ב-LP באמצעות שיטות ראשוניות וכפולות.
SOLVER_TYPE_CP_SAT

פותר CP-SAT של Google.

תומכת בבעיות שבהן כל המשתנים הם שלמים ותחומים (או משתמעים אחרי presolve). תמיכה ניסיונית כדי להתאים לעומס (scaling) בעיות עם משתנים רציפים, ולהבדיל ביניהן.
SOLVER_TYPE_PDLP

פותר ה-PDLP של Google.

תומכת במטרות ריבועיות באלכסון וקמורות. משתמשת בשיטות מסדר ראשון במקום בשיטות חד-פעמיות. אפשר לפתור בעיות גדולות מאוד.
SOLVER_TYPE_GLPK

ערכת התכנות הלינארית GNU (GLPK) (צד שלישי).

תמיכה ב-MIP וב-LP.

בטיחות בנוגע לשרשורים: ב-GLPK נעשה שימוש באחסון מקומי בשרשור (thread) להקצאות זיכרון. כתוצאה מכך, יש להשמיד מכונות של Solver באותו שרשור שבו הן נוצרות, אחרת ה-GLPK יקרוס. נראה שאפשר לקרוא ל-Solver::Solve() משרשור אחר מזה ששימש ליצירת ה-Solver, אבל הוא לא מתועד על ידי GLPK ויש להימנע ממנו.

בעת פתרון LP באמצעות ה-Presolve, תמיסה (והקרניות הבלתי מאוגדות) מוחזרת רק אם נמצא פתרון אופטימלי. אחרת, שום דבר לא מוחזר. לפרטים נוספים, אפשר לעיין ב-glpk-5.0/doc/glpk.pdf דף #40 הזמין בכתובת glpk-5.0.tar.gz.
SOLVER_TYPE_OSQP

פותר הבעיות של תוכנית פיצול מפעיל (OSQP) (צד שלישי).

תומכת בבעיות רציפות עם מגבלות ליניאריות ויעדים ריבועיים ליניאריים או קמורים. משתמשת בשיטה של הזמנה ראשונה.
SOLVER_TYPE_ECOS

Embedded Conic Solver (ECOS) (צד שלישי).

תמיכה בבעיות דפי נחיתה ו-SOCP. נעשה שימוש בשיטות נקודה פנימית (מחסום).
SOLVER_TYPE_SCS

Splitting Conic Solver (SCS) (צד שלישי).

תמיכה בבעיות דפי נחיתה ו-SOCP. משתמשת בשיטה של הזמנה ראשונה.
SOLVER_TYPE_HIGHS

HiGHS Solver (צד שלישי).

תומכת בבעיות דפי נחיתה ו-MIP (לא בוצעה הטמעה של QP קמור).
SOLVER_TYPE_SANTORINI

הטמעת קובץ עזר של MathOpt של פותר MIP.

איטי/לא מומלץ לצורכי ייצור. לא פותר LP (לא הוחזר מידע כפול).

ModelProto

בעיית אופטימיזציה. תמיכה ב-MathOpt: משתני החלטה רציפים ומספרים שלמים עם גבולות סופיים אופציונליים. - יעדים לינאריים וריבועיים (יעדים בודדים או מרובים), מוקטנים או מוגדלים. - מספר סוגי אילוצים, כולל: * אילוצים לינאריים * אילוצים ריבועיים * אילוצים של חרוטים מסדר שני * אילוצים לוגיים > מגבלות חירום 1 ו-SOS2 > מגבלות אינדיקטור

כברירת מחדל, האילוצים מיוצגים ב-"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 הם רכיבים של LinearConstraints.ids. * LinearConstraintMatrix.column_ids הם אלמנטים של variable.ids. * הערכים במטריצה שלא צוינו הם אפס. * ערכים של LinearConstraintMatrix.value חייבים להיות סופיים.
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))

מגבלות מסוג OS2 במודל, שמגבילות את האופן שבו שתי ערכים של expression לכל היותר יכולות להיות לא אפס, והן חייבות להיות צמודות בסדר שלהן. אם לא צוין weights, הסדר הזה הוא הסדר הלינארי ברשימה של expressions. אם מוצג weights, הסדר ביחס לערכים האלה בסדר הולך וגדל.

אובייקט שמכיל רשימה של "key": value זוגות. לדוגמה: { "name": "wrench", "mass": "1.3kg", "count": "3" }.
indicatorConstraints

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

מגבלות אינדיקטור במודל, שאוכפים זאת, כאשר 'משתנה אינדיקטור' בינארי מוגדר ל-1, ואז ל'אילוץ משתמע' חייבים להחזיק.

אובייקט שמכיל רשימה של "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)

הערך חייב להיות לא שלילי והמספר במגמת עלייה. אי אפשר להשתמש בערך המקסימלי(int64).
lowerBounds[]

number

האורך צריך להיות שווה ל-#variables, הערכים צריכים להיות [-inf, inf).
upperBounds[]

number

האורך צריך להיות שווה ל- #variables, ערכים ב-( -inf, inf].
integers[]

boolean

האורך צריך להיות שווה ל- #variable. הערך הוא FALSE למשתנים רציפים ו-True למשתנים שלמים.
names[]

string

אם המאפיין לא מוגדר, ההנחה היא שכל המחרוזות ריקות. אחרת, האורך צריך להיות שווה ל- #variables.

כל שמות שאינם ריקים חייבים להיות נפרדים.

ObjectiveProto

ייצוג JSON 
{
  "maximize": boolean,
  "offset": number,
  "linearCoefficients": {
    object (SparseDoubleVectorProto)
  },
  "quadraticCoefficients": {
    object (SparseDoubleMatrixProto)
  },
  "name": string,
  "priority": string
}
שדות
maximize

boolean

FALSE הוא מזעור, true הוא למקסם
offset

number

חייב להיות סופי ולא NaN.
linearCoefficients

object (SparseDoubleVectorProto)

מונחי ObjectiveProto שהם לינאריים במשתני ההחלטה.

דרישות: * LinearCoefficients.id הם רכיבים של VariablesProto.ids. * VariablesProto (משתנים לדוגמה) לא תואמים לאפס. * הערך של LinearCoefficients.values צריך להיות סופי. * לינאריCoefficients.values יכולים להיות אפס, אבל זה פשוט בזבוז מקום.
quadraticCoefficients

object (SparseDoubleMatrixProto)

מונחי אובייקט שהם ריבועיים במשתני ההחלטה.

דרישות בנוסף לדרישות בהודעות של Sparse DoubleMatrixProto: * כל רכיב של quadraticCoefficients.row_ids וכל רכיב של quadraticCoefficients.column_ids חייבים להיות רכיב של VariablesProto.ids. * המטריצה חייבת להיות משולשת עליונה: לכל i, quadraticCoefficients.row_ids[i] <= quadraticCoefficients.column_ids[i].

הערות: * לתנאים שלא מאוחסנים במפורש יש מקדם אפס. * אלמנטים של quadraticCoefficients.coefficients יכולים להיות אפס, אבל זה פשוט בזבוז מקום.
name

string

יכול להיות שלהודעות הורה יהיו דרישות ייחודיות בשדה הזה. לדוגמה, ראו ModelProto.objectives ו-AuxiliaryObjectivesUpdatesProto.new_objectives.
priority

string (int64 format)

בבעיות עם כמה מטרות, העדיפות של המטרה הזו ביחס לאחרים (הרמה הנמוכה יותר חשובה יותר). הערך הזה חייב להיות לא שלילי. בנוסף, כל עדיפות של מטרה במודל צריכה להיות ייחודית בזמן פתרון. התנאי הזה לא מאומת ברמת הפרוטו, לכן יכול להיות שלמודלים יש באופן זמני יעדים עם אותה עדיפות.

SparseDoubleVectorProto

ייצוג דל של וקטור של כפולים.

ייצוג JSON 
{
  "ids": [
    string
  ],
  "values": [
    number
  ]
}
שדות
ids[]

string (int64 format)

חייב להיות ממוין (בסדר הולך וגדל) עם הבחנה בין כל הרכיבים.
values[]

number

האורך חייב להיות זהה למזהים. לא יכול להכיל NaN.

SparseDoubleMatrixProto

ייצוג דל של מטריצה של זוגות.

המטריצה מאוחסנת כשלשות של מזהה שורה, מזהה עמודה ומקדם. שלושת הווקטורים האלה חייבים להיות באורך שווה. לכל ה-i, ה-tuple (rowIds[i], columnIds[i]) צריך להיות ייחודי. הרשומות חייבות להיות בסדר ראשי של שורה.

ייצוג JSON 
{
  "rowIds": [
    string
  ],
  "columnIds": [
    string
  ],
  "coefficients": [
    number
  ]
}
שדות
rowIds[]

string (int64 format)
columnIds[]

string (int64 format)
coefficients[]

number

לא יכול להכיל NaN.

LinearConstraintsProto

כפי שמתואר בהמשך, אנחנו מגדירים '#מגבלות לינאריות' = size(LinearConstraintsProto.ids).

ייצוג JSON 
{
  "ids": [
    string
  ],
  "lowerBounds": [
    number
  ],
  "upperBounds": [
    number
  ],
  "names": [
    string
  ]
}
שדות
ids[]

string (int64 format)

הערך חייב להיות לא שלילי והמספר במגמת עלייה. אי אפשר להשתמש בערך המקסימלי(int64).
lowerBounds[]

number

האורך צריך להיות שווה למגבלות #ליניאריות, הערכים בעמודות [-inf, inf).
upperBounds[]

number

האורך צריך להיות שווה למגבלות #לינאריות, הערכים ב-( -inf, inf].
names[]

string

אם המאפיין לא מוגדר, ההנחה היא שכל המחרוזות ריקות. אחרת, האורך צריך להיות שווה למגבלות #לינאריות.

כל שמות שאינם ריקים חייבים להיות נפרדים.

QuadraticConstraintProto

אילוץ ריבועי יחיד מהצורה: lb <= amount{ מפרineTerms} + amount{quadraticTerms} <= ub.

אם משתנה שמעורב באילוץ הזה נמחק, המערכת מתייחסת אליו כאילו שהוא הוגדר לאפס.

ייצוג JSON 
{
  "linearTerms": {
    object (SparseDoubleVectorProto)
  },
  "quadraticTerms": {
    object (SparseDoubleMatrixProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string
}
שדות
linearTerms

object (SparseDoubleVectorProto)

מונחים לינאריים במשתני ההחלטה.

בנוסף לדרישות בהודעות של SparseDoubleClickVectorProto, אנחנו דורשים: * LinearTerms.ids הם רכיבים של VariablesProto.ids. * lineTerms.values חייבים להיות סופיים ולא מוגדרים כ-NaN.

הערות: * למזהי המשתנים שהושמטו יש מקדם תואם של אפס. * LinearTerms.value יכולים להיות אפס, אבל זה פשוט בזבוז מקום.
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 ו-QuadraticConstraintUpdatesProto.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 ו-SosConstraintUpdatesProto.new_constraints.

IndicatorConstraintProto

נתונים לייצוג אילוץ של מדד יחיד בטופס: Variable(indicatorId) = (activateOnZero ? 0 : 1) ⇒ גבול תחתון <= ביטוי <= עליון.

אם משתנה שמעורב באילוץ הזה (המדד או שמופיע ב-expression) נמחק, המערכת מתייחסת אליו כאילו הוגדר שהוא אפס. באופן ספציפי, אם מוחקים את משתנה המדד, המשמעות היא שאילוץ המדד ריק אם activateOnZero הוא False, ושהוא שוות ערך לאילוץ לינארי אם activateOnZero נכון.

ייצוג JSON 
{
  "activateOnZero": boolean,
  "expression": {
    object (SparseDoubleVectorProto)
  },
  "lowerBound": number,
  "upperBound": number,
  "name": string,
  "indicatorId": string
}
שדות
activateOnZero

boolean

אם True, אם משתנה המדד מקבל את הערך 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)

מזהה שתואם למשתנה בינארי או לא מוגדר. אם היא לא מוגדרת, המערכת תתעלם ממגבלת האינדיקטור. אם המדיניות מוגדרת, אנחנו דורשים את הפרטים הבאים: * VariablesProto.integers[indicatorId] = true, * VariablesProto.lower_bounds[indicatorId] >= 0, * VariablesProto.upper_bounds[indicatorId] <= 1. התנאים האלה לא מאומתים על ידי MathOpt, אבל אם הם לא יתקיימו, הפתרון יחזיר שגיאה בסיום הפתרון.

SolveParametersProto

פרמטרים לשליטה בפתרון יחיד.

מכיל את שני הפרמטרים המשותפים לכל הפותרים, למשל: מגבלת זמן ופרמטרים של פותר ספציפי, למשל gscip. אם ערך מוגדר גם בשדה משותף וגם בשדה ספציפי לפותר, המערכת תשתמש בהגדרה הספציפית לפותר.

הפרמטרים הנפוצים שהם אופציונליים ולא מוגדרים או enum עם ערך לא צוין מציינים שנעשה שימוש בברירת המחדל של הפותר.

המערכת מתעלמת מפרמטרים ספציפיים של פתרון עבור פתרונות אחרים, שאינם אלה שנמצאים בשימוש.

פרמטרים שתלויים במודל (למשל, עדיפות הסתעפות מוגדרת לכל משתנה) מועברים ב-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, יתבצע LOG(INFO).

הערה: אם הפותר תומך בקריאה חוזרת (callback) של הודעה והמשתמש מבצע קריאה חוזרת (callback), המערכת תתעלם מערך הפרמטר הזה ולא יודפסו עקבות.
lpAlgorithm

enum (LPAlgorithmProto)

האלגוריתם לפתרון תוכנית לינארית. אם LP_ALGORITHM_UNSPECIFIED, אתם יכולים להשתמש באלגוריתם ברירת המחדל של הפותר.

אם יש בעיות שהן לא תוכניות ליניאריות, אבל שתכנות ליניאריות הן שגרתיות, הפותרים יכולים להשתמש בערך הזה. לדוגמה הפתרון של MIP ישתמש בדרך כלל באפשרות הזו לפתרון בעיות של LP ברמה הבסיסית (root) בלבד (ואחרת הם ישתמשו בשני עקרונות פשוטים).
presolve

enum (EmphasisProto)

מאמץ לפשט את הבעיה לפני הפעלת האלגוריתם הראשי, או רמת המאמץ המוגדרת כברירת המחדל של הפתרון אם JSON_UNSPECIFIED.
cuts

enum (EmphasisProto)

מאמץ להשגת הרגיעה חזקה יותר של LP (MIP בלבד), או רמת המאמץ שמוגדרת כברירת המחדל של הפתרון אם JSON_UNSPECIFIED.

הערה: השבתת הקיצוצים עשויה למנוע מקריאות חוזרות (callback) להוסיף חיתוכים ב-MIP_NODE, התנהגות כזו היא ספציפית לפותר.
heuristics

enum (EmphasisProto)

מאמץ במציאת פתרונות מעשיים מעבר לאלה שנתקלו בתהליך החיפוש המלא (MIP בלבד), או רמת המאמץ המוגדרת כברירת מחדל של הפתרון אם JSON_UNSPECIFIED.
scaling

enum (EmphasisProto)

מאמץ להתאים את הבעיה לעומס (scaling) כדי לשפר את היציבות המספרית, או את רמת המאמץ המוגדרת כברירת המחדל של הפתרון אם JSON_UNSPECIFIED.
iterationLimit

string (int64 format)

הגבלה על איטרציות של האלגוריתם הבסיסי (למשל, צירים פשוטים). ההתנהגות הספציפית תלויה בפותר ובאלגוריתם שבהם נעשה שימוש, אבל לעיתים קרובות יכולה לתת מגבלת פתרון דטרמיניסטית (ייתכן שיהיה צורך בהגדרה נוספת, למשל שרשור אחד).

בדרך כלל נתמכת על ידי פתרונות מסוג LP, QP ו-MIP, אבל בשביל לפתורי MIP צריך לעיין גם ב-NodeLimit.
nodeLimit

string (int64 format)

הגבלה למספר בעיות המשנה שנפתרות בחיפוש מבוסס-ספירה (למשל הסתעפות ותחום). עבור פותרים רבים ניתן להשתמש בהגדרה הזו כדי להגביל את החישובים באופן דטרמיניסטי (ייתכן שיהיה צורך בהגדרה נוספת, למשל שרשור אחד).

בדרך כלל לפותרי MIP, יש לעיין גם במדיניות iterationLimit.
cutoffLimit

number

הפותר עוצר בשלב מוקדם אם הוא יכול להוכיח שאין פתרונות ראשוניים טובים לפחות כמו סף החיוב.

במקרה של עצירה מוקדמת, הפתרון מחזיר את סיבת הסיום NO_SOLUTION_FOUND עם מגבלת CUTOFF ולא נדרש לספק מידע נוסף על הפתרון. אין השפעה על הערך המוחזר אם אין עצירה מוקדמת.

מומלץ להשתמש בהגדרות סובלנות אם רוצים להחזיר פתרונות עם יעד ששווה בדיוק לחיתוך.

לפרטים נוספים והשוואה ל-bestBoundLimit, אפשר לעיין במדריך למשתמש.
objectiveLimit

number

הפותר מפסיק את הבעיה ברגע שהוא מוצא פתרון שהוא לפחות הטוב ביותר, עם סיבת הסיום - אפשרית ומוגבלת.
bestBoundLimit

number

הפותר מפסיק את פעולתו מוקדם ברגע שמוכיח שהגבול הטוב ביותר הוא לפחות הטוב ביותר, עם סיבת הסיום FEASIBLE או NO_SOLUTION_FOUND וההגבלה על היעד OBJECT.

לפרטים נוספים והשוואה ל-cutoffLimit, אפשר לעיין במדריך למשתמש.
solutionLimit

integer

הפותר מפסיק את פעולתו מוקדם אחרי שמצא את כל הפתרונות האפשריים האלה. סיבת הסיום היא FEASIBLE ומגבילה את הפתרון. אם השדה מוגדר, הערך שלו צריך להיות גדול מאפס. לרוב משתמשים בפותר הבעיות כדי לעצור את הפתרון האפשרי הראשון שנמצא. חשוב לשים לב שאין כל ערובה לערך היעד של הפתרונות שמוחזרים.

בדרך כלל הפותרים לא יחזירו יותר פתרונות מעבר למגבלה של הפתרון, אבל לא נאכפת על ידי MathOpt. אפשר לעיין גם במאמר b/214041169.

בשלב הזה נתמך עבור Gurobi ו-SCIP, ועבור CP-SAT רק עם ערך 1.
threads

integer

אם הערך מוגדר, הוא צריך להיות >= 1.
randomSeed

integer

ערך הבסיס למחולל המספרים האקראיים לכאורה בפותר הבסיסי. הערה: כל הפותרים משתמשים במספרים פסאודו אקראיים כדי לבחור דברים כמו טרנספורמציה באלגוריתם ה-LP, לכללים של פריצת קשירה ולתיקונים היוריסטיים. שינוי המיקום יכול להשפיע באופן משמעותי על התנהגות הפותר.

למרות שלכל הפתרונות יש קונספט של מקור נתונים, חשוב לזכור שערכים חוקיים תלויים בפותר בפועל. - גורובי: [0:GRB_MAXINT] (החל מ-Gurobi 9.0 הוא 2x10^9). - GSCIP: [0:2147483647] (כלומר MAX_INT או kint32max או 2^31-1). - GLOP: [0:2147483647] (כמו למעלה) בכל המקרים, הפותר יקבל ערך ששווה ל: MAX(0, MIN(MAX_סף_VALUE_FOR_SOLVER, TRUESeed)).
absoluteGapTolerance

number

סבילות מוחלטת לאופטימיזציה (בעיקר) לפותרי MIP.

ה-GAP המוחלט הוא הערך המוחלט של ההפרש בין: * הערך האובייקטי של הפתרון בר הקיימא הטוב ביותר שנמצא, * הגבול הכפול שהחיפוש מפיק. הפותר יכול להפסיק כאשר GAP המוחלט הוא מוחלט ביותר של GapTolerance (כאשר הוא מוגדר), ולהחזיר TERMINATION_REASON_OPTIMAL.

אם השדה מוגדר, הערך חייב להיות >= 0.

ראו גם יחסי סובלנות (GapTolerance).
relativeGapTolerance

number

סובלנות יחסית לאופטימליות (בעיקר) לפותרי MIP.

ה-GAP היחסי הוא גרסה מנורמלת של ה-GAP המוחלט (מוגדר ב- להישארGapTolerance), שבו הנירמול תלוי בפותר, למשל. את ה-GAP המוחלט חלקי הערך האובייקטיומי של הפתרון בר הביצוע הטוב ביותר שנמצא.

הפותר יכול להפסיק כאשר ה-GAP היחסי הוא יחסי לכל היותר GapTolerance (כאשר הוא מוגדר), והחזרת תהיה TERMINATION_REASON_OPTIMAL.

אם השדה מוגדר, הערך חייב להיות >= 0.

ראו גם מוחלט של GapTolerance.
solutionPoolSize

integer

תחזוקה של עד solutionPoolSize פתרונות במהלך החיפוש. בדרך כלל, מאגר הפתרונות כולל שתי פונקציות: (1) לפותרים שיכולים להחזיר יותר מפתרון אחד, האפשרות הזו מגבילה את מספר הפתרונות שיוחזרו. (2) חלק מהפותרים עשויים להריץ היוריסטיקה באמצעות פתרונות ממאגר הפתרונות, כך ששינוי הערך הזה עשוי להשפיע על הנתיב של האלגוריתם. כדי לאלץ את הפתרון למלא את מאגר התמיסות, לדוגמה עם n הפתרונות הטובים ביותר, דורש הגדרה ספציפית נוספת לפותר.

LPAlgorithmProto

בחירת אלגוריתם לפתרון תוכניות ליניאריות.

טיפוסים בני מנייה (enum)
LP_ALGORITHM_UNSPECIFIED
LP_ALGORITHM_PRIMAL_SIMPLEX השיטה (הראשי) בדרך כלל יכול לספק פתרונות ראשוניים וכפולים, קרניים ראשוניות/כפולות לבעיות ראשוניות/כפולות ובסיסי.
LP_ALGORITHM_DUAL_SIMPLEX שיטת Dual Simplex. בדרך כלל יכול לספק פתרונות ראשוניים וכפולים, קרניים ראשוניות/כפולות לבעיות ראשוניות/כפולות ובסיסי.
LP_ALGORITHM_BARRIER שיטת המחסום, שנקראת גם בדרך כלל שיטת נקודה פנימית (IPM). בדרך כלל יכול לתת גם פתרונות ראשוניים וגם פתרונות כפולים. יישומים מסוימים עלולים להפיק קרניים גם בבעיות בלתי מוגבלות/בלתי מעשיות. לא ניתן בסיס אלא אם הפתרון הבסיסי מבצע "קרוסאובר" והוא מסתיים בקידוד חד-פעמי.
LP_ALGORITHM_FIRST_ORDER אלגוריתם שמבוסס על שיטה מסדר ראשון. הם בדרך כלל יפיקו גם פתרונות ראשוניים וגם פתרונות כפולים, ואולי גם אישורים של חוסר היתכנות ראשוני ו/או כפול. שיטות בעדיפות ראשונה יספקו בדרך כלל פתרונות ברמת דיוק נמוכה יותר, לכן המשתמשים צריכים להגדיר פרמטרים של איכות לפתרון (למשל, סבילות) ולאמת את הפתרונות.

EmphasisProto

רמת המאמץ שהוחלה על משימה אופציונלית במהלך הפתרון (ראו שימוש ב-SolveParametersProto).

הדגשה משמשת להגדרת תכונת פותר באופן הבא: * אם פותר לא תומך בתכונה, רק UNSPECIFIED יהיה תמיד תקף, כל הגדרה אחרת לרוב תהיה שגיאת ארגומנט לא חוקי (פותרים מסוימים יכולים גם לקבל כבוי). * אם הפותר תומך בתכונה: - כאשר ההגדרה היא UNSPECIFIED, נעשה שימוש בברירת המחדל הבסיסית. - כאשר לא ניתן לכבות את התכונה, כיבוי יחזיר הודעת שגיאה. - אם התכונה מופעלת כברירת מחדל, ברירת המחדל של הפותר ממופה בדרך כלל ל-MEDIUM. - אם התכונה נתמכת, הערכים LOW, MEDIUM, high וגבוהים מאוד אף פעם לא יספקו שגיאה והם ימופו להתאמה הטובה ביותר שלהם.

טיפוסים בני מנייה (enum)
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).

דרישות: * FilterIds הם רכיבים של VariablesProto.id.
dualValuesFilter

object (SparseVectorFilterProto)

מסנן שמיושם על כל הקונטיינרים החלקיים המוחזרים, עם מפתחי מגבלות לינאריים ב-DualSolutionProto וב-DualSolutionProto.dual_values, DualRay.dual_values.

דרישות: * FilterIds הם רכיבים של LinearConstraints.id.
reducedCostsFilter

object (SparseVectorFilterProto)

מסנן שמיושם על כל הקונטיינרים החלקיים שהוחזרו, עם מפתחות של משתנים ב-DualSolutionProto וב-DualSolutionProto (DualSolutionProto.reduced_costs, DualRay.reduced_costs).

דרישות: * FilterIds הם רכיבים של VariablesProto.id.
initialBasis

object (BasisProto)

בסיס ראשוני אופציונלי לפותרי LP עם הפעלה מהירה במצב ביניים (warm start). אם הוא מוגדר, הוא צפוי להיות תקף לפי ValidateBasis ב-validators/solution_validator.h עבור ModelSummary הנוכחי.
solutionHints[]

object (SolutionHintProto)

רמזים אופציונליים לפתרונות. אם הפותר הבסיסי מקבל רק רמז אחד, נעשה שימוש ברמז הראשון.
branchingPriorities

object (SparseInt32VectorProto)

עדיפויות אופציונליות להסתעפות. משתנים עם ערכים גבוהים יותר יסתעפו קודם. משתנים שעבורם לא מוגדרות עדיפויות מקבלים את עדיפות ברירת המחדל של הפותר (בדרך כלל אפס).

דרישות: * branchesPriorities.values חייב להיות סופי. * brancingPriorities.ids חייב להיות רכיבים של VariablesProto.ids.

SparseVectorFilterProto

ההודעה הזו מאפשרת להריץ שאילתה/להגדיר חלקים ספציפיים של SparseXxxxVector. התנהגות ברירת המחדל היא לא לסנן דבר. שימוש נפוץ הוא להריץ שאילתות רק על חלקים של פתרונות (רק ערכים שאינם אפס או רק על קבוצה של ערכי משתנים שנבחרו ידנית).

ייצוג JSON 
{
  "skipZeroValues": boolean,
  "filterByIds": boolean,
  "filteredIds": [
    string
  ]
}
שדות
skipZeroValues

boolean

עבור SparseBoolVectorProto "zero" false.
filterByIds

boolean

אם הערך הוא True, מוחזר רק הערכים שתואמים למזהים שמפורטים ב-FilterIds.
filteredIds[]

string (int64 format)

רשימת המזהים שצריך להשתמש בהם אם השדה filterByIds מוגדר כ-True. אם השדה filterByIds מוגדר כ-False, יש להשאיר את השדה ריק. הערה: אם השדה הזה ריק, והפרמטר filterByIds נכון, המשמעות היא שאינך רוצה לקבל מידע בתוצאה.

BasisProto

אפיון משולב לפתרון של תוכנית לינארית.

שיטת הצד השלישי לפתרון תוכנות ליניאריות תמיד מחזירה 'פתרון ישים בסיסי' שאפשר לתאר בסך הכול בעזרת בסיס. הבסיס מקצה BaseStatusProto לכל משתנה ואילוץ לינארי.

לדוגמה חשוב להשתמש בפורמט סטנדרטי LP: min c * x s.t. A * x = b x >= 0 שיש לו יותר משתנים ממגבלות ועם דירוג שורה מלא A.

n הוא מספר המשתנים ומ-m את מספר המגבלות הלינאריות. אפשר לבנות בסיס תקף לבעיה הזו באופן הבא: * לכל האילוצים סטטוס הבסיס 'FIXED'. * בחרו משתני m כך שהעמודות של A יהיו בלתי תלויות לינאריות והקצו את הסטטוס BASIC. * מקצים את הסטטוס AT_LOWER למשתנים הנותרים של n - m.

הפתרון הבסיסי לבסיס הזה הוא הפתרון הייחודי של A * x = b שמכיל את כל המשתנים שהסטטוס AT_LOWER נקבע לגבולות התחתון שלהם (כל האפס). הפתרון שמתקבל נקרא פתרון ישים בסיסי אם הוא עומד גם בתנאי x >= 0.

ייצוג JSON 
{
  "constraintStatus": {
    object (SparseBasisStatusVector)
  },
  "variableStatus": {
    object (SparseBasisStatusVector)
  },
  "basicDualFeasibility": enum (SolutionStatusProto)
}
שדות
constraintStatus

object (SparseBasisStatusVector)

סטטוס בסיס האילוץ.

דרישות: * queryStatus.ids שווה ל-LinearConstraints.ids.
variableStatus

object (SparseBasisStatusVector)

סטטוס של בסיס משתנה.

דרישות: * queryStatus.ids שווה ל-VariablesProto.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

הסטטוס של משתנה/אילוץ על בסיס LP.

טיפוסים בני מנייה (enum)
BASIS_STATUS_UNSPECIFIED ערך Guard שמייצג אין סטטוס.
BASIS_STATUS_FREE המשתנה/אילוץ חופשי (ללא גבולות סופיים).
BASIS_STATUS_AT_LOWER_BOUND המשתנה/האילוץ נמצא בגבול התחתון שלו (שחייב להיות סופי).
BASIS_STATUS_AT_UPPER_BOUND המשתנה/האילוץ נמצא בגבול העליון שלו (שחייב להיות סופי).
BASIS_STATUS_FIXED_VALUE למשתנה/לאילוץ יש גבול תחתון סופי וגבול עליון זהים.
BASIS_STATUS_BASIC המשתנה/האילוץ הוא בסיסי.

SolutionStatusProto

היתכנות של פתרון ראשוני או כפול כפי שטוען הפותר.

טיפוסים בני מנייה (enum)
SOLUTION_STATUS_UNSPECIFIED ערך Guard שמייצג אין סטטוס.
SOLUTION_STATUS_UNDETERMINED הפותר לא טוען סטטוס היתכנות.
SOLUTION_STATUS_FEASIBLE הפתרון טוען שהפתרון ניתן לביצוע.
SOLUTION_STATUS_INFEASIBLE הפתרון טוען שהפתרון אינו ישים.

SolutionHintProto

הצעה לפתרון התחלתי.

פתרוןי MIP בדרך כלל רוצים רק מידע ראשוני (variableValues), בעוד שפותרי LP רוצים לקבל גם מידע ראשוני וגם מידע כפול (dualValues).

הרבה פתרונות של MIP יכולים לעבוד עם: (1) פתרונות חלקיים שלא מציינים את כל המשתנים, או (2) פתרונות לא אפשריים. במקרים כאלה, הפותרים בדרך כלל פותרים MIP כדי להשלים או לתקן את הרמז.

האופן שבו הרמז משתמש ברמז, אם בכלל, תלוי במידה רבה בפותר, בסוג הבעיה ובאלגוריתם שבו נעשה שימוש. הדרך הבטוחה ביותר להבטיח שלרמז יש השפעה היא לקרוא את יומני הפתרונות הבסיסיים עם הרמז או בלעדיו.

פתרוןי LP המבוססים על סימפטומים בדרך כלל מעדיפים בסיס ראשוני לרמז לפתרון (אחרת הם צריכים להמיר את הרמז לפתרון ניתן לשימוש בסיסי).

ייצוג JSON 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "dualValues": {
    object (SparseDoubleVectorProto)
  }
}
שדות
variableValues

object (SparseDoubleVectorProto)

יכול להיות שגם הקצאה חלקית של ערכים למשתנים הראשוניים של הבעיה. הדרישות שאינן תלויות בפותר עבור הודעת המשנה הזו הן: * variableValues.ids הם רכיבים של VariablesProto.ids. * הערך של variableValues.values חייב להיות סופי.
dualValues

object (SparseDoubleVectorProto)

הקצאה (שעשויה להיות חלקית) של ערכים למגבלות הלינאריות של הבעיה.

דרישות: * dualValues.ids הם רכיבים של LinearConstraintsProto.ids. * DualValues.values חייבים להיות סופיים.

SparseInt32VectorProto

ייצוג דל של וקטור של Int.

ייצוג JSON 
{
  "ids": [
    string
  ],
  "values": [
    integer
  ]
}
שדות
ids[]

string (int64 format)

צריך למיין (בסדר עולה) כאשר כל הרכיבים נפרדים.
values[]

integer

האורך חייב להיות זהה למזהים.

SolveResultProto

החוזה של מקרים שבהם תמיסות או קרניים ראשוניים/כפולים הוא מורכב. תיאור מלא זמין בכתובת activity_reasons.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)

כיוונים של שיפור ראשוני בלתי מוגבל, או אישורי היתכנות כפולים. בדרך כלל מסופק עבור DoneReasonProtos UNboundED ו-DUAL_INFEASIBLE
dualRays[]

object (DualRayProto)

כיוונים של שיפור כפול ללא הגבלה, או אישורי היתכנות ראשוניים. בדרך כלל מסופק במקרים של FinishReasonProto בלתי ראוי.
solveStats

object (SolveStatsProto)

נתונים סטטיסטיים על תהליך הפתרון, למשל: זמן ריצה, איטרציות.

TerminationProto

כל המידע לגבי הסיבה לסיום הקריאה ל-Solve() .

ייצוג JSON 
{
  "reason": enum (TerminationReasonProto),
  "limit": enum (LimitProto),
  "detail": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "objectiveBounds": {
    object (ObjectiveBoundsProto)
  }
}
שדות
reason

enum (TerminationReasonProto)

מידע נוסף ב-limit כשהערך הוא TERMINATION_REASON_FEASIBLE או TERMINATION_REASON_NO_SOLUTION_FOUND, יש לעיין ב-limit.
limit

enum (LimitProto)

LIMIT_UNSPECIFIED, אלא אם הסיבה היא TERMINATION_REASON_FEASIBLE או TERMINATION_REASON_NO_SOLUTION_FOUND. לא כל הפותרים יכולים תמיד לקבוע את המגבלה שגרמה לסיום. כאשר לא ניתן לקבוע מהי הסיבה, נעשה שימוש ב-LIMIT_UNDETERMINED.
detail

string

מידע ספציפי בדרך כלל לפותר לגבי סיום.
problemStatus

object (ProblemStatusProto)

סטטוסים של היתכנות לבעיות ראשוניות ולבעיות כפולות. החל מ-18 ביולי 2023 יכול להיות שההודעה הזו לא תופיע. אם הפרמטר חסר, אפשר למצוא את ה- issueStatus ב-Solve resultProto.solve_stats.
objectiveBounds

object (ObjectiveBoundsProto)

הגבלה על הערך היעד האופטימלי. החל מ-18 ביולי 2023 יכול להיות שההודעה הזו לא תופיע. אם חסר, הפרמטר objectBounds.primal_bound יכול למצוא ב-SolveAmountProto.solve.stats.best_primal_bound.

TerminationReasonProto

הסיבה לסיום קריאה ל-Solve() .

טיפוסים בני מנייה (enum)
TERMINATION_REASON_UNSPECIFIED
TERMINATION_REASON_OPTIMAL נמצא פתרון אופטימלי (עד סבילות מספרית).
TERMINATION_REASON_INFEASIBLE לבעיה הראשונית אין פתרונות מעשיים.
TERMINATION_REASON_UNBOUNDED הבעיה הראשונית היא אפשרית, וניתן למצוא פתרונות טובים באופן שרירותי לאורך קרן ראשונית.
TERMINATION_REASON_INFEASIBLE_OR_UNBOUNDED הבעיה הבסיסית היא לא ישרה או בלתי מוגבלת. פרטים נוספים על סטטוס הבעיה זמינים ב- השלביםStats.problem_status. לידיעתך, ניתן למפות כאן את הסטטוס הלא-קבוע של Gurobi.
TERMINATION_REASON_IMPRECISE

הבעיה נפתרה לפי אחד מהקריטריונים שמפורטים למעלה ('אופטימלי', 'לא בר-ביצוע', 'לא מוגבל' או 'לא אפשרי', אבל לא מולאה אחת או יותר). יש פתרונות או קרניים ראשוניים/כפולים, אבל ייתכן שהם לא ישיגו בכלל, או (אם הבעיה הייתה כמעט אופטימלית) הם עלולים להוות פער בין מטרת הפתרון הטוב ביותר לבין היעד הטוב ביותר.

המשתמשים עדיין יכולים להריץ שאילתות על פתרונות או קרניים ראשוניים/כפולים ועל נתונים סטטיסטיים של פתרונות, אבל הם אחראים לטפל באי הדיוק המספרי.
TERMINATION_REASON_FEASIBLE כלי האופטימיזציה הגיע למגבלה מסוימת ומחזיר פתרון מעשי. לקבלת תיאור מפורט של סוג המגבלה שהגעתם אליה, אפשר לעיין ב-SolvePRODUCTProto.limit_detail.
TERMINATION_REASON_NO_SOLUTION_FOUND כלי האופטימיזציה הגיע למגבלה כלשהי והוא לא מצא פתרון ראשוני מעשי. לקבלת תיאור מפורט של סוג המגבלה שהגעתם אליה, אפשר לעיין ב-SolvePRODUCTProto.limit_detail.
TERMINATION_REASON_NUMERICAL_ERROR האלגוריתם הפסיק לפעול כי הוא נתקל בשגיאה מספרית שבעקבותיה אי אפשר לשחזר אותו. אין מידע זמין על הפתרון.
TERMINATION_REASON_OTHER_ERROR האלגוריתם הופסק עקב שגיאה שלא נכללת באחד מהסטטוסים שהוגדרו למעלה. אין מידע זמין על הפתרון.

LimitProto

כש-Solve() מפסיק מוקדם עם DoneReasonProto FEASIBLE או NO_SOLUTION_FOUND, המגבלה הספציפית שהושגה.

טיפוסים בני מנייה (enum)
LIMIT_UNSPECIFIED משמש כערך null אם הפסקנו את השימוש בו ללא מגבלה (למשל, TERMINATION_REASON_OPTIMAL).
LIMIT_UNDETERMINED הפותר הבסיסי לא חושף את המגבלה שהגעתם אליה.
LIMIT_ITERATION אלגוריתם איטרטיבי הופסק אחרי שביצע את המספר המרבי של חזרות (למשל, איטרציות חד-פעמיות או מכשולים).
LIMIT_TIME האלגוריתם הופסק אחרי זמן חישוב שצוין על ידי המשתמש.
LIMIT_NODE אלגוריתם של הסתעפות וכריכה הופסק כי הוא בחן מספר מקסימלי של צמתים בעץ ההסתעפות והקשורים.
LIMIT_SOLUTION האלגוריתם הופסק כי הוא מצא את מספר הפתרונות הנדרש. בדרך כלל משתמשים באפשרות הזו ב-MIP כדי לגרום לפותר להחזיר את הפתרון האפשרי הראשון שהוא נתקל בו.
LIMIT_MEMORY האלגוריתם הפסיק לפעול כי אין לו זיכרון.
LIMIT_CUTOFF הפותר פעל עם נקודת חיתוך (למשל, SolveParameters.cutoff_limit הוגדר) על היעד, והעיד על כך שהמשתמש לא רצה פתרון גרוע יותר מהמועד האחרון להזמנה, והפותר הגיע למסקנה שאין פתרונות שטובים לפחות כמו הסף האחרון. בדרך כלל לא ניתן לספק מידע נוסף על פתרון.
LIMIT_OBJECTIVE האלגוריתם הופסק כי הוא מצא פתרון או הגבול טוב יותר מהמגבלה שהגדיר המשתמש (מידע נוסף זמין בקטע SolveParameters.objective_limit ו-SolveParameters.best_bound_limit).
LIMIT_NORM האלגוריתם הופסק כי הנורמה של איטרציה נעשתה גדולה מדי.
LIMIT_INTERRUPTED האלגוריתם הופסק עקב אות הפרעה או בקשת הפרעה ממשתמש.
LIMIT_SLOW_PROGRESS האלגוריתם הופסק כי הוא לא הצליח להמשיך להתקדם לעבר הפתרון.
LIMIT_OTHER

האלגוריתם הופסק עקב מגבלה שלא מכוסה על ידי אחת מהאפשרויות שלמעלה. לתשומת ליבך: נעשה שימוש ב-LIMIT_UNDETERMINED אם לא ניתן לקבוע את הסיבה, ונעשה שימוש ב-LIMIT_OTHER כשהסיבה ידועה, אבל היא לא מתאימה לאף אחת מהחלופות שלמעלה.

DoneProto.detail עשוי להכיל מידע נוסף על המגבלה.

ProblemStatusProto

סטטוס ההיתכנות של הבעיה הראשונית והכפולה שלה (או הכפולה של רגיעה מתמשכת) כפי שטוען הפותר. הפותר לא נדרש להחזיר אישור עבור התביעה (למשל, הפותר יכול לטעון להיתכנות ראשונית בלי להחזיר פתרון מעשי ראשוני). הסטטוס המשולב הזה מספק תיאור מקיף של טענות הפתרון לגבי היתכנות וחוסר עקביות של הבעיה שנפתרה. למשל:

  • סטטוס אפשרי לבעיות ראשוניות וכפולות מצביע על כך שהבעיה הראשונה היא אפשרית ומוגבלת, וסביר להניח שיש לה פתרון אופטימלי (מובטח לבעיות ללא מגבלות לא ליניאריות).
  • סטטוס ראשוני בר-ביצוע וסטטוס כפול לא-אפשרי מציין שהבעיה הבסיסית היא בלתי מוגבלת (כלומר, יש לה פתרונות טובים באופן שרירותי).

שימו לב שסטטוס שני לא אפשרי כשלעצמו (כלומר, מלווה בסטטוס ראשוני לא ידוע) לא מרמז על כך שהבעיה הבסיסית אינה קשורה, מכיוון ששתי הבעיות עלולות להיות בלתי אפשריות. בנוסף, גם אם סטטוס ראשוני וכפול יכול לרמוז על קיומו של פתרון אופטימלי, הוא לא מבטיח שהפותר מצא פתרון אופטימלי כזה.

ייצוג JSON 
{
  "primalStatus": enum (FeasibilityStatusProto),
  "dualStatus": enum (FeasibilityStatusProto),
  "primalOrDualInfeasible": boolean
}
שדות
primalStatus

enum (FeasibilityStatusProto)

הסטטוס של הבעיה הראשונית.
dualStatus

enum (FeasibilityStatusProto)

הסטטוס של הבעיה הכפולה (או של הכפולה של רגיעה מתמשכת).
primalOrDualInfeasible

boolean

אם True, הפותר טוען שהבעיה הראשונית או הכפולה לא אפשרית, אבל הוא לא יודע איזו (או אם שניהם לא אפשריים). יכול להיות true רק כאשר primal_problem_status = dual_problem_status = kUndetermined. המידע הנוסף הזה נדרש לעיתים קרובות כשעיבוד מראש קובע שאין פתרון אופטימלי לבעיה (אבל הוא לא יכול לקבוע אם הבעיה נובעת מחוסר היתכנות, מחוסר גבולות או משניהם).

FeasibilityStatusProto

סטטוס היתכנות של הבעיה כפי שהפותר טען (הפותר לא נדרש להחזיר אישור עבור התביעה).

טיפוסים בני מנייה (enum)
FEASIBILITY_STATUS_UNSPECIFIED ערך Guard שמייצג אין סטטוס.
FEASIBILITY_STATUS_UNDETERMINED הפותר לא טוען סטטוס.
FEASIBILITY_STATUS_FEASIBLE הפתרון טוען שהבעיה אפשרית.
FEASIBILITY_STATUS_INFEASIBLE ה-Solver טוען שהבעיה אינה אפשרית.

ObjectiveBoundsProto

הגבלה על הערך היעד האופטימלי.

ייצוג JSON 
{
  "primalBound": number,
  "dualBound": number
}
שדות
primalBound

number

הפותר טוען שהערך האופטימלי הוא שווה או טוב יותר (קטן יותר לצורך מזעור וגדול יותר לצורך הגדלת הרווחים) מ-primalBound עד לסבילות ההיתכנות הראשונית של הפותרים (ראו אזהרה בהמשך): * primalBound הוא טריוויאלי (+inf עבור מזעור ו-inf כדי למקסם) כאשר הפתרון אינו טוען שאין לו קשר כזה. * הפרמטר primalBound יכול להיות קרוב יותר לערך האופטימלי יותר מהמטרה של הפתרון הראשוני הטוב ביותר. בפרט, ערך primalBound עלול להיות לא טרי, גם אם לא מוחזרים פתרונות ראשוניים מעשיים. אזהרה: הטענה המדויקת היא שקיים פתרון ראשוני אשר: * הוא בר-ביצוע מבחינה מספרית (כלומר, ניתן לביצוע עד לסבולת הפותרים), ושיש לו ערך אובייקטיבי primalBound. הפתרון הזה מעשי מבחינה מספרית עשוי להיות מעט לא מעשי, ובמקרה כזה primalBound יכול להיות רק טוב יותר מהערך האופטימלי. תרגום של סובלנות היתכנות ראשונית לסבלנות ב-primalBound הוא לא פשוט, במיוחד במקרים שבהם סובלנות ההיתכנות גדולה יחסית (למשל, בפתרון באמצעות PDLP).
dualBound

number

הפותר טוען שהערך האופטימלי הוא שווה או גרוע יותר (גדול יותר למזעור וקטן יותר לצורך הגדלת האופטימיזציה) מאשר סובלנות היתכנות הכפולה עד לפותרים (ראו אזהרה בהמשך): * DualBound הוא טריוויאלי (-inf for minimization ו-+inf maximization) כאשר הפותר לא טוען שיש לו קשר כזה. בדומה ל-primalBound, זה יכול לקרות אצל חלק מהפותרים גם כשהם חוזרים למצב אופטימלי. פתרוןי MIP ידווחו בדרך כלל על מגבלה גם אם הוא לא מדויק. * במקרים של בעיות רציפות, DualBound יכולה להיות קרובה יותר לערך האופטימלי מאשר המטרה של הפתרון הכפול הטוב ביותר האפשרי. עבור MIP, אחד מהערכים הלא טריוויאליים הראשונים של dualBound הוא בדרך כלל הערך האופטימלי של הרגיעה של ה-LP של ה-MIP. * DualBound צריך להיות טוב יותר (קטן יותר למזעור וגדול יותר למקסום) מאשר primalBound עד לפתרונות של פותרים (ראו אזהרה בהמשך). אזהרה: * במקרה של בעיות מתמשכות, הטענה המדויקת היא שקיים פתרון כפול אשר: * הוא בר-ביצוע מספרי (כלומר, ניתן לביצוע עד לסבולת הפותרים), ויש לו ערך אובייקטיבי DualBound. הפתרון הזה הוא בר-ביצוע מספרי, ובמקרה כזה DualBound יכול להיות גרוע יותר מהערך האופטימלי ומ-primalBound. בדומה למקרה הראשוני, אין חשיבות רבה לתרגום של סובלנות היתכנות כפולה לסבלנות ב-DualBound, במיוחד כאשר סובלנות ההיתכנות גדולה יחסית. עם זאת, חלק מהפותרים מספקים גרסה מתוקנת של DualBound שיכולה להיות בטוחה יותר מבחינה נומרית. ניתן לגשת לגרסה המתוקנת הזו דרך הפלט הספציפי של הפותר (למשל: עבור PDLP, pdlp_output.convergence_information.Corrected_dual_objective). * עבור פתרוןי MIP, DualBound עשוי להיות משויך לפתרון כפול לרגיעה מתמשכת (למשל, הרגיעה של LP), אבל לרוב זו תוצאה מורכבת של הביצוע של הפותרים, ולרוב היא לא מדויקת יותר מהגבולות שמדווחים על ידי הפותרים של LP.

SolutionProto

מה שנכלל בפתרון תלוי בסוג הבעיה ובפותר. הדפוסים הנפוצים כרגע הם 1. פתרונות MIP מחזירים רק פתרון ראשוני. 2. בדרך כלל, הפתרונות של LPs פשוטים מחזירים בסיס ואת הפתרונות הראשוניים והכפולים שמשויכים לבסיס הזה. 3. בדרך כלל, פתרונות רציפים אחרים מחזירים פתרון ראשוני וכפול שמחובר באופן תלוי-פותר.

דרישות: * יש להגדיר שדה אחד לפחות. פתרון לא יכול להיות ריק.

ייצוג JSON 
{
  "primalSolution": {
    object (PrimalSolutionProto)
  },
  "dualSolution": {
    object (DualSolutionProto)
  },
  "basis": {
    object (BasisProto)
  }
}
שדות
primalSolution

object (PrimalSolutionProto)
dualSolution

object (DualSolutionProto)
basis

object (BasisProto)

PrimalSolutionProto

פתרון לבעיית אופטימיזציה.

לדוגמה נבחן תוכנית לינארית פשוטה: min c * x s.t. A * x >= b x >= 0. פתרון ראשוני הוא הקצאה של ערכים ל-x. הוא אפשרי אם הוא עומד בתנאי A * x >= b ו-x >= 0 מלמעלה. בהודעה PrimalSolutionProto למטה, variableValues הוא x ו-objectValue הוא c * x.

ייצוג JSON 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  },
  "objectiveValue": number,
  "auxiliaryObjectiveValues": {
    string: number,
    ...
  },
  "feasibilityStatus": enum (SolutionStatusProto)
}
שדות
variableValues

object (SparseDoubleVectorProto)

דרישות: * variableValues.ids הם רכיבים של VariablesProto.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

פתרון לכפולה של בעיית אופטימיזציה.

לדוגמה נבחן את צמד התוכניות הלינאריות הכפולות של {2/}: (ראשי) (Dual) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. הפתרון הכפול הוא הצמד (y, r). הדבר אפשרי אם הוא עומד במגבלות שמפורטות למעלה (Dual).

בהודעה הבאה, y הוא dualValues, r הוא במורד העלויות, ו-b * y הוא ערך אובייקטיבי.

ייצוג JSON 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  },
  "feasibilityStatus": enum (SolutionStatusProto),
  "objectiveValue": number
}
שדות
dualValues

object (SparseDoubleVectorProto)

דרישות: * dualValues.ids הם רכיבים של LinearConstraints.ids. * DualValues.values חייבים להיות סופיים.
reducedCosts

object (SparseDoubleVectorProto)

דרישות: * ReduceCosts.ids הם רכיבים של VariablesProto.ids. * הערך של Costs.values צריך להיות סופי.
feasibilityStatus

enum (SolutionStatusProto)

סטטוס ההיתכנות של הפתרון בהתאם לפותר הבסיסי.
objectiveValue

number

PrimalRayProto

הכוונה של שיפור בלתי מוגבל בבעיית אופטימיזציה; בדומה לכך, אישור על יכולת פעולה של בעיית האופטימיזציה כפולה.

לדוגמה נבחן תוכנית לינארית פשוטה: min c * x s.t. A * x >= b x >= 0 קרן ראשונית היא x שמספק: c * x < 0 A * x >= 0 x >= 0 שימו לב שכשנותנים פתרון בר-ביצוע, כל כפולה חיובית של הקרניים הראשוניות וגם הפתרון הזה עדיין מעשית, ונותן ערך אובייקטיבי טוב יותר. קרניים ראשוניות מוכיחות גם שבעיית האופטימיזציה הכפולה לא אפשרית.

בהודעה PrimalRay שבהמשך, הערך של variableValues הוא x.

ייצוג JSON 
{
  "variableValues": {
    object (SparseDoubleVectorProto)
  }
}
שדות
variableValues

object (SparseDoubleVectorProto)

דרישות: * variableValues.ids הם רכיבים של VariablesProto.ids. * הערך של variableValues.values חייב להיות סופי.

DualRayProto

כיוון של שיפור בלתי מוגבל מבחינת הכפולה של אופטימיזציה, בעיה; בדומה לכך, אישור על חוסר היתכנות ראשוני.

לדוגמה נבחן את צמד התוכניות הלינאריות הכפולות של {2/}: (ראשי) (Dual) 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 הוא dualValues ו-r להפחיתCosts.

ייצוג JSON 
{
  "dualValues": {
    object (SparseDoubleVectorProto)
  },
  "reducedCosts": {
    object (SparseDoubleVectorProto)
  }
}
שדות
dualValues

object (SparseDoubleVectorProto)

דרישות: * dualValues.ids הם רכיבים של LinearConstraints.ids. * DualValues.values חייבים להיות סופיים.
reducedCosts

object (SparseDoubleVectorProto)

דרישות: * ReduceCosts.ids הם רכיבים של VariablesProto.ids. * הערך של Costs.values צריך להיות סופי.

SolveStatsProto

ייצוג JSON 
{
  "solveTime": string,
  "problemStatus": {
    object (ProblemStatusProto)
  },
  "simplexIterations": string,
  "barrierIterations": string,
  "firstOrderIterations": string,
  "nodeCount": string
}
שדות
solveTime

string (Duration format)

הזמן שחלף של שעון קיר כפי שנמדד באמצעות Mat_opt, זהו הזמן המשוער בתוך Solver::Solve(). הערה: בקטגוריה הזו לא נכללים עבודה שהתבצעה במסגרת בניית המודל.

משך זמן בשניות עם עד תשע ספרות עשרוניות, שמסתיים ב-'s'. לדוגמה: "3.5s".
problemStatus

object (ProblemStatusProto)

סטטוסים של היתכנות לבעיות ראשוניות ולבעיות כפולות.
simplexIterations

string (int64 format)
barrierIterations

string (int64 format)
firstOrderIterations

string (int64 format)
nodeCount

string (int64 format)