Uses of Class
com.google.ortools.constraintsolver.BaseObject

Packages that use BaseObject

Package	Description
com.google.ortools.constraintsolver

Uses of BaseObject in com.google.ortools.constraintsolver

Subclasses of BaseObject in com.google.ortools.constraintsolver

Modifier and Type	Class	Description
class	Assignment	An Assignment is a variable -> domains mapping, used to report solutions to the user.
class	BaseIntExpr
class	BaseLns	This is the base class for building an Lns operator.
class	BaseObjectiveMonitor
class	BooleanVar
class	CastConstraint	Cast constraints are special channeling constraints designed to keep a variable in sync with an expression.
class	ChangeValue	Defines operators which change the value of variables; each neighbor corresponds to *one* modified variable. Sub-classes have to define ModifyValue which determines what the new variable value is going to be (given the current value and the variable).
class	Constraint	A constraint is the main modeling object.
class	Decision	A Decision represents a choice point in the search tree.
class	DecisionBuilder	A DecisionBuilder is responsible for creating the search tree.
class	DecisionVisitor	A DecisionVisitor is used to inspect a decision. It contains virtual methods for all type of 'declared' decisions.
class	Demon	A Demon is the base element of a propagation queue.
class	DisjunctiveConstraint
class	GlobalVehicleBreaksConstraint	GlobalVehicleBreaksConstraint ensures breaks constraints are enforced on all vehicles in the dimension passed to its constructor. It is intended to be used for dimensions representing time. A break constraint ensures break intervals fit on the route of a vehicle. For a given vehicle, it forces break intervals to be disjoint from visit intervals, where visit intervals start at CumulVar(node) and last for node_visit_transit[node].
class	ImprovementSearchLimit
class	IntervalVar	Interval variables are often used in scheduling.
class	IntExpr	The class IntExpr is the base of all integer expressions in constraint programming. It contains the basic protocol for an expression: - setting and modifying its bound - querying if it is bound - listening to events modifying its bounds - casting it into a variable (instance of IntVar)
class	IntVar	The class IntVar is a subset of IntExpr.
class	IntVarIterator	The class Iterator has two direct subclasses.
class	IntVarLocalSearchFilter
class	IntVarLocalSearchOperator	Specialization of LocalSearchOperator built from an array of IntVars which specifies the scope of the operator. This class also takes care of storing current variable values in Start(), keeps track of changes done by the operator and builds the delta. The Deactivate() method can be used to perform Large Neighborhood Search.
class	JavaDecisionBuilder	This class acts as a intermediate step between a c++ decision builder and a java one.
class	LocalSearchFilter	Local Search Filters are used for fast neighbor pruning. Filtering a move is done in several phases: - in the Relax phase, filters determine which parts of their internals will be changed by the candidate, and modify intermediary State - in the Accept phase, filters check that the candidate is feasible, - if the Accept phase succeeds, the solver may decide to trigger a Synchronize phase that makes filters change their internal representation to the last candidate, - otherwise (Accept fails or the solver does not want to synchronize), a Revert phase makes filters erase any intermediary State generated by the Relax and Accept phases. A given filter has phases called with the following pattern: (Relax.Accept.Synchronize | Relax.Accept.Revert | Relax.Revert)*. Filters's Revert() is always called in the reverse order their Accept() was called, to allow late filters to use state done/undone by early filters' Accept()/Revert().
class	LocalSearchFilterManager	Filter manager: when a move is made, filters are executed to decide whether the solution is feasible and compute parts of the new cost.
class	LocalSearchMonitor
class	LocalSearchOperator	The base class for all local search operators. A local search operator is an object that defines the neighborhood of a solution.
class	ModelVisitor	Model visitor.
class	ObjectiveMonitor
class	OptimizeVar	This class encapsulates an objective.
class	Pack
class	PropagationBaseObject	NOLINT The PropagationBaseObject is a subclass of BaseObject that is also friend to the Solver class.
class	PropagationMonitor
class	RegularLimit	Usual limit based on wall_time, number of explored branches and number of failures in the search tree
class	RoutingModelVisitor	Routing model visitor.
class	SearchLimit	Base class of all search limits.
class	SearchLog	The base class of all search logs that periodically outputs information when the search is running.
class	SearchMonitor	A search monitor is a simple set of callbacks to monitor all search events
class	SequenceVar	A sequence variable is a variable whose domain is a set of possible orderings of the interval variables.
class	SolutionCollector	This class is the root class of all solution collectors. It implements a basic query API to be used independently of the collector used.
class	SolutionPool	This class is used to manage a pool of solutions.
class	SymmetryBreaker	A symmetry breaker is an object that will visit a decision and create the 'symmetrical' decision in return. Each symmetry breaker represents one class of symmetry.
class	TypeRegulationsConstraint	The following constraint ensures that incompatibilities and requirements between types are respected. It verifies both "hard" and "temporal" incompatibilities. Two nodes with hard incompatible types cannot be served by the same vehicle at all, while with a temporal incompatibility they can't be on the same route at the same time. The VisitTypePolicy of a node determines how visiting it impacts the type count on the route. For example, for - three temporally incompatible types T1 T2 and T3 - 2 pairs of nodes a1/r1 and a2/r2 of type T1 and T2 respectively, with - a1 and a2 of VisitTypePolicy TYPE_ADDED_TO_VEHICLE - r1 and r2 of policy ADDED_TYPE_REMOVED_FROM_VEHICLE - 3 nodes A, UV and AR of type T3, respectively with type policies TYPE_ADDED_TO_VEHICLE, TYPE_ON_VEHICLE_UP_TO_VISIT and TYPE_SIMULTANEOUSLY_ADDED_AND_REMOVED the configurations UV --> a1 --> r1 --> a2 --> r2, a1 --> r1 --> a2 --> r2 --> A and a1 --> r1 --> AR --> a2 --> r2 are acceptable, whereas the configurations a1 --> a2 --> r1 --> ..., or A --> a1 --> r1 --> ..., or a1 --> r1 --> UV --> ... are not feasible. It also verifies same-vehicle and temporal type requirements. A node of type T_d with a same-vehicle requirement for type T_r needs to be served by the same vehicle as a node of type T_r. Temporal requirements, on the other hand, can take effect either when the dependent type is being added to the route or when it's removed from it, which is determined by the dependent node's VisitTypePolicy. In the above example: - If T3 is required on the same vehicle as T1, A, AR or UV must be on the same vehicle as a1. - If T2 is required when adding T1, a2 must be visited *before* a1, and if r2 is also visited on the route, it must be *after* a1, i.e.

Methods in com.google.ortools.constraintsolver with parameters of type BaseObject

Modifier and Type	Method	Description
static final String	mainJNI.BaseObject_toString(long jarg1, BaseObject jarg1_)
static long	BaseObject.getCPtr(BaseObject obj)
static long	BaseObject.swigRelease(BaseObject obj)