# 3.11. Hint Reference¶

GTOpt hints specify types of variables and additional properties of objectives and constraints in an optimization problem.

- You can specify hints in your problem class definition
when adding variables, objectives, and constraints —
see the hints dictionary argument to
`add_variable()`

,`add_objective()`

,`add_constraint()`

. - You can set hints in an instance of your problem class — see
`set_variable_hints()`

,`set_objective_hints()`

, and`set_constraint_hints()`

.

This section lists available hints, corresponding keys recognized in hints, and their valid values.

Variable Hints

- key:
`"@GT/VariableType"`

, value:`"Continuous"`

(default),`"Integer"`

, or`"Discrete"`

Changed in version 6.1: integer variables are now supported in gradient-based optimization (previously were supported in surrogate-based optimization only).

Changed in version 6.14: renamed the key to `"@GT/VariableType"`

since it is now also used by a similar hint in GTDoE.

Changed in version 6.15: added the discrete variable type.

Objective Hints

- key:
`"@GTOpt/EvaluationCostType"`

, value:`"Cheap"`

(default) or`"Expensive"`

- key:
`"@GTOpt/ExpensiveEvaluations"`

, value: integer in range \([0, 65535]\),`-1`

, or`"Auto"`

(default);`-1`

and`"Auto"`

are the same - key:
`"@GTOpt/LinearityType"`

, value:`"Generic"`

(default),`"Linear"`

, or`"Quadratic"`

Changed in version 1.10.2: GTOpt now allows multiple expensive objectives and/or constraints in the given problem, thus supporting the multi-objective surrogate based optimization. Prior to 1.10.2, SBO was supported only in problems with a single objective or functional constraint (single-objective box-constrained problems and constraint satisfaction problems with one constraint).

Changed in version 6.6: the *@GTOpt/LinearityType* hint is no longer ignored in robust optimization problems. However, GTOpt now assumes that objectives hinted as linear or quadratic do not depend on any stochastic variable. This can lead to unexpected behavior if your definition of some objective includes a stochastic variable and at the same time you specify it to be a linear or quadratic function. Note that this is incorrect problem formulation, but GTOpt cannot automatically detect it.

Note

It is not recommended to set non-default *@GTOpt/LinearityType* and *@GTOpt/EvaluationCostType*
for the same objective.
See the note in **Constraint Hints** below for more details.

Constraint Hints

- key:
`"@GTOpt/ConstraintAlpha"`

, value:`float`

in range \([0.0001, 0.9999]\); for example:`0.05`

; default:*no value* - key:
`"@GTOpt/ConstraintType"`

, value:`"ExpectationConstraint"`

(default) or`"ChanceConstraint"`

- key:
`"@GTOpt/EvaluationCostType"`

, value:`"Cheap"`

(default) or`"Expensive"`

- key:
`"@GTOpt/ExpensiveEvaluations"`

, value: integer in range \([0, 65535]\),`-1`

, or`"Auto"`

(default);`-1`

and`"Auto"`

are the same - key:
`"@GTOpt/LinearityType"`

, value:`"Generic"`

(default),`"Linear"`

, or`"Quadratic"`

Note

If *@GTOpt/ConstraintType* is set to `"ChanceConstraint"`

,
then *@GTOpt/ConstraintAlpha* must also be set to a valid value since it has no default.

Changed in version 6.6: the *@GTOpt/LinearityType* hint is no longer ignored in robust optimization problems.
However, GTOpt now assumes that constraints hinted as linear or quadratic
do not depend on any stochastic variable.
This can lead to unexpected behavior if
your definition of some constraint includes a stochastic variable,
and at the same time you specify it to be a linear or quadratic function.
Note that this is incorrect problem formulation, but GTOpt cannot automatically detect it.

Note

It is not recommended to set non-default *@GTOpt/LinearityType* and *@GTOpt/EvaluationCostType*
for the same response (objective or constraint).
This combination of hints is accepted, but the *@GTOpt/LinearityType* hints becomes generally ineffective.
For example, the method that restores the analytical form of linear and quadratic responses
(see GTOpt/RestoreAnalyticResponses) is not used
if the response is expensive: depending on the number of variables in the response,
analytical restoration may require more evaluations than allowed by
the GTOpt/MaximumExpensiveIterations option or the
the @GTOpt/ExpensiveEvaluations hint.

Note

Linear and quadratic constraints cannot have the chance constraint type.
If you set `"@GTOpt/ConstraintType"`

to `"ChanceConstraint"`

for a linear or quadratic constraint,
this `"@GTOpt/ConstraintType"`

setting is ignored.

@GTOpt/ExpensiveEvaluationsRestricts the number of evaluations individually for each expensive objective or constraint, including the evaluations of initial guess points.

Value: integer in range \([0, 65535]\), `-1`

, or`"Auto"`

Default: `"Auto"`

New in version 6.13.

This hint is intended for response functions (objectives and constraints) that were marked as expensive using the

@GTOpt/EvaluationCostTypehint. In addition to the common expensive evaluations limit specified by GTOpt/MaximumExpensiveIterations, you can set a specific limit for any expensive response which works as follows:

A positive

@GTOpt/ExpensiveEvaluationsvalue can be used to impose a more strict limit than the one set by GTOpt/MaximumExpensiveIterations and GTOpt/MaximumIterations. That is, the lowest of these three limits is selected and becomes the evaluation budget for this response.Note that if GTOpt/MaximumExpensiveIterations is left default, GTOpt will analyze problem’s properties (number of variables, responses, and other) to automatically determine the common expensive evaluations limit. Then it will select the most strict limit among

@GTOpt/ExpensiveEvaluations, GTOpt/MaximumIterations, and the internally determined GTOpt/MaximumExpensiveIterations. Since this behavior can be ambiguous, it is not recommended to use the@GTOpt/ExpensiveEvaluationshint with the default value of the GTOpt/MaximumExpensiveIterations option.If you set

@GTOpt/ExpensiveEvaluationsfor some expensive response to`0`

, GTOpt will never request evaluations for this response, regardless of the mentioned options’ values. Note that it also prohibits evaluating this response for the initial guess points (specified when adding variables to your problem or by passing the sample_x argument to`solve()`

).If the

@GTOpt/ExpensiveEvaluationshint is not set, or set to one of the “auto” values (`-1`

or`"Auto"`

, default), the evaluation limit is controlled only by the GTOpt/MaximumIterations and GTOpt/MaximumExpensiveIterations options.

@GTOpt/ExpensiveEvaluationsregards the evaluations required to obtain response values for the initial guess points in the same way as the GTOpt/MaximumIterations: such evaluations expend the budget specified by this hint. That is, for an expensive response with an added@GTOpt/ExpensiveEvaluationshint, the actual budget limit becomes the lowest of three values:

- the limit set by GTOpt/MaximumIterations,
- the number of initial guesses plus the limit set by
GTOpt/MaximumExpensiveIterations, and- the limit set by
@GTOpt/ExpensiveEvaluations.Once the evaluation limit for a response is reached, GTOpt stops requesting its evaluations by setting the corresponding values in the querymask that it sends to the problem’s evaluation method to

`0`

. A proper handling of such selective evaluations requires a method that correctly parses the querymask — otherwise the hint you specified will have no effect. For this reason, if you want to use the@GTOpt/ExpensiveEvaluationshint, it is recommended to inherit your problem class from`ProblemGeneric`

and implement the`evaluate()`

method accordingly (see the method’s description for details).