Skip to content

Commit

Permalink
added objective function and put feasibility into its own section
Browse files Browse the repository at this point in the history
  • Loading branch information
thomasWeise committed Dec 16, 2023
1 parent 8ad0940 commit d62af88
Show file tree
Hide file tree
Showing 14 changed files with 308 additions and 147 deletions.
6 changes: 3 additions & 3 deletions notation/optimization.sty
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
%
\newSymbol{instance}{\ensuremath{\mathcal{I}}}{I}{%
the problem instance data, see \autoref{def:instance} in \autoref{sec:problemInstance}}%
the problem instance data, see \autoref{def:instance}}%
\newSymbol{solutionSpace}{\mathSpace{Y}}{Y}{%
the solution space, i.e., the set of possible solutions to an optimization problem, see \autoref{def:solutionSpace}}%
\newSymbol{solspel}{\ensuremath{y}}{y}{%
a candidate solution to an optimization problem, i.e., an element of the solution space~\solutionSpace, see \autoref{def:candidateSolution}}%
%
\newFunc{objf}{\ensuremath{f}}{f(y)}{y}{%
an objective function~$f:\solutionSpace\mapsto\realNumbers$ computes the cost of a candidate solution~$\solspel\in\solutionSpace$}%
an objective function~$f:\solutionSpace\mapsto\realNumbers$ computes the cost of a candidate solution~$\solspel\in\solutionSpace$, see \autoref{def:objectiveFunction}}%
%
\protected\gdef\searchSpaceSubset{\ensuremath{X}}%
%
Expand All @@ -24,7 +24,7 @@ the decoding function~$\gamma:\searchSpace\mapsto\solutionSpace$ maps the candid
A search operator $\@searchOp:\searchSpace^n\mapsto\searchSpace$ with $n\in\naturalNumbersZ$ takes zero or more points from the search space~\searchSpace\ as input and produces one new element of~\searchSpace\ as output}%
%
\newSymbol{obspel}{\ensuremath{z}}{z}{%
an objective value returned by the objective function~\objf}%
an objective value returned by the objective function~\objf, see \autoref{def:objectiveValue}}%
%
\newSymbol{nFeasible}{\ensuremath{\#\mathrm{feasible}}}{feasible}{%
the number of feasible solutions in the solution space~\solutionSpace, see \autoref{def:feasibility}}%
Expand Down
2 changes: 1 addition & 1 deletion scripts/filterPdf.sh
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ gs -dAntiAliasColorImages=true \
-dAntiAliasMonoImages=true \
-dAutoFilterColorImages=false \
-dAutoFilterGrayImages=false \
-dAutoRotatePages=/PageByPage \
-dAutoRotatePages=/None \
-dBATCH \
-dCannotEmbedFontPolicy=/Error \
-dColorConversionStrategy=/LeaveColorUnchanged \
Expand Down
169 changes: 169 additions & 0 deletions text/main/structure/feasibility/feasibility.tex
Original file line number Diff line number Diff line change
@@ -0,0 +1,169 @@
%
\hsection{The Feasibility of the Solutions}%
\label{sec:solutionSpace:feasibility}%
%
For many optimization problems, we can pick any element~\solspel\ from the solution space~\solutionSpace\ and return it as output of an optimization algorithm.
For many \emph{other} optimization problems, some elements of~\solutionSpace\ are not permissible for different reasons.
We we call these reasons \emph{constraints}.%
%
\hsection{Definitions}%
%
\begin{definition}[Constraint]%
\label{def:constraint}%
A \emph{constraint} is a rule imposed on the solution space~\solutionSpace\ which can either be fulfilled or violated by a candidate solution~$\solspel\in\solutionSpace$.%
\end{definition}%
%
\begin{definition}[Feasibility]%
\label{def:feasibility}%
A candidate solution~$\solspel\in\solutionSpace$ is \emph{feasible} if and only if it fulfills all constraints.%
\end{definition}%
%
\begin{definition}[Infeasibility]%
\label{def:infeasibility}%
A candidate solution~$\solspel\in\solutionSpace$ is \emph{infeasible} if it is \emph{not feasible}, i.e., if it violates at least one constraint.%
\end{definition}%
%
\endhsection%
%
\hsection{A Programmer's Perspective}%
%
There is not much to discuss here from a programmer's perspective because there are many different ways to deal with constraints.
In our \moptipy\ \codeil{Space} API illustrated in \autoref{lst:Space}, we provide the method \codeil{validate}.
The programmer can implement this method to check whether a solution is feasible or not.
If not, the method is supposed to throw a \codeil{ValueError} if it is not.%
%
\endhsection%
%
\hsection{Example: Job Shop Scheduling}%
%
In order to be a feasible solution for a \gls{JSSP} instance, a Gantt chart must indeed fulfill a couple of \emph{constraints}:%
%
\begin{enumerate}
%
\item All operations of all jobs must be assigned to their respective machines and properly be completed.%
%
\item Only the jobs and machines specified by the problem instance must occur in the chart.%
%
\item An operation must be assigned a time window on its corresponding machine which is exactly as long as the operation needs on that machine.%
%
\item The operations of one job cannot intersect or overlap. %
The next operation of one job can only begin after the previous operation of the job has been completed.%
%
\item Each machine can only carry out one operation at a time.%
%
\item Once a machine begins to process an operation, it cannot stop until the operation is complete, i.e., no preemption is possible%
%
\item The precedence constraints of the operations must be honored. %
In other words, if the instance says that operation~1 of job~1 should take place before operation~2 of job~1, then this must also be the case in the Gantt chart.%
%
\end{enumerate}%
%
While the first six \emph{constraints} are rather trivial, the latter one proofs problematic.
Imagine a \gls{JSSP} with $\jsspJobs=2$~jobs and $\jsspMachines=2$~machines.
There are $(2!)^2=(1*2)^2=4$~possible Gantt charts.
Assume that the first job needs to first be processed by machine~0 and then by machine~1, while the second job first needs to go to machine~1 and then to machine~0.
A Gantt chart which assigns the first job to be the first on machine~1 and the second job first to be the first on machine~$0$ cannot be executed in practice, i.e., is \emph{infeasible}, as such an assignment does not honor the precedence constraints of the jobs.
Instead, it contains a deadlock.

\begin{figure}%
\centering%
\includegraphics[width=0.85\linewidth]{\currentDir/jssp_feasible_gantt.pdf}%
\caption{Two different JSSP instances with $\jsspMachines=2$~machines and $\jsspJobs=2$~jobs.%
The left one has four feasible corresponding Gantt charts.
The right one has only three feasible solutions and one infeasible one.}%
\label{fig:jssp_feasible_gantt}%
\end{figure}%

The third schedule in the right column of \autoref{fig:jssp_feasible_gantt} illustrates exactly this case.
Machine~0 should begin by doing job~1.
Job~1 can only start on machine~0 after it has been finished on machine~1.
At machine~1, we should begin with job~0.
Before job~0 can be put on machine~1, it must go through machine~0.
So job~1 cannot go to machine~0 until it has passed through machine~1, but in order to be executed on machine~1, job~0 needs to be finished there first.
Job~0 cannot begin on machine~1 until it has been passed through machine~0, but it cannot be executed there, because job~1 needs to be finished there first.
A cyclic blockage has appeared: no job can be executed on any machine if we follow this schedule.
This is called a deadlock.

No jobs overlap in the schedule.
All operations are assigned to proper machines and receive the right processing times.
Still, the schedule is infeasible, because it cannot be executed or written down without breaking the precedence constraint.

Hence, there are only three out of four possible Gantt charts that work for this problem instance.
For a problem instance where the jobs need to pass through all machines in the same sequence, however, all possible Gantt charts will work, as also illustrated in the left column of \autoref{fig:jssp_feasible_gantt}.
The number of actually feasible Gantt charts in~\solutionSpace\ thus can be different for different problem instances.

\begin{table}%
\centering%
\caption{%
The minimal number $\min\nFeasible$ of feasible solutions over all instances with specific size \jsspJobs\ and \jsspMachines\ (compare with \autoref{tbl:jsspSolutionSpaceSizeTable}).}%
\label{tbl:jsspSolutionSpaceFeasibleTable}%
\begin{tabular}{lrrrr}%
\hline%
example&\jsspJobs&\jsspMachines&$\min\nFeasible$&$\left|\solutionSpace\right|$\\%
\hline%
\autoref{fig:jssp_feasible_gantt}&2&2&3&4\\%
&2&3&4&8\\%
&2&4&5&16\\%
&2&5&6&32\\%
&3&2&22&36\\%
&3&3&63&216\\%
&3&4&147&1\dgsep296\\%
&3&5&317&7\dgsep776\\%
&4&2&244&576\\%
&4&3&1\dgsep630&13\dgsep824\\%
&4&4&7\dgsep451&331\dgsep776\\%
&5&2&4\dgsep548&14\dgsep400\\%
&5&3&91\dgsep461&1\dgsep728\dgsep000\\%
\hline%
\end{tabular}%
\end{table}%

Different \gls{JSSP} instances can have different numbers~\nFeasible\ of possible \emph{feasible} Gantt charts, even if they have the same numbers of machines and jobs.
We just saw this in \autoref{fig:jssp_feasible_gantt}.
Naturally, for a given setting of~$\jsspMachines$ and~$\jsspJobs$, we are interested in the minimum~$\min\nFeasible$ of this number, i.e., the \emph{smallest value} that~\nFeasible\ can take on over all possible instances with \jsspJobs~jobs and \jsspMachines~machines.

Now, I don't know how to compute this number in any efficient and we only want to see out of academic curiosity.
So I just enumerated all the instances for a given combination of \jsspJobs\ and ~jsspMachines.
For each instance, I enumerated all the possible Gantt charts and counted how many were feasible, i.e., computed \nFeasible\ for that instance.
After I was done with enumerating all the instances, I know the smallest value of \nFeasible, i.e., $\min\nFeasible$, for that combination of \jsspJobs\ and~\jsspMachines.
I know that there must be a better way to get this number, probably with dynamic programming, but for now, the crude method will be sufficient.
Of course, it only works for very small values of \jsspJobs\ and~\jsspMachines.

The results in \autoref{tbl:jsspSolutionSpaceFeasibleTable} show that, at least for some instances, most of the possible Gantt charts might be infeasible, as~$\min\nFeasible$ can be much smaller than~$\left|\solutionSpace\right|$.
%
\ruleOfThumb{infeasibleSolutions}{If a problem has feasibility constraints, then we often find that most of the candidate solutions are infeasible.}%
%
This is very annoying.
The potential existence of infeasible solutions means that we cannot just pick a good element from~\solutionSpace\ (according to whatever \emph{good} means), we also must be sure that it is actually \emph{feasible}.
An optimization algorithm that may sometimes return infeasible solutions will not be acceptable.%
%
\endhsection%
%
\hsection{Summary}%
%
In this section, we discovered that not every Gantt chart that we can draw for a given \gls{JSSP} instance is also \emph{feasible}.
Some of them have deadlocks (\ref{fig:jssp_feasible_gantt}).
Obviously, whatever we will later do to find \emph{good} Gantt charts, we must never return an infeasible one, i.e., one that cannot actually be executed.
To make matters worse, we discovered that it is entirely possible that the vast majority of Gantt charts that we could come up with for a given instance could be infeasible.

So the \gls{JSSP} is not just a problem where the number of possible solutions is far too huge to test them all, most of these solutions may also be wrong.
And the \gls{JSSP} is an \inQuotes{average citizen} in optimization.

Not all optimization problems have feasibility constraints.
Often, the constraints are very straightforward such as assigning each operation once to exactly one machine in a Gantt chart.
Or to visit each city only once in a \gls{TSP}.
In such cases, we can relatively easily take care of them in our algorithm implementation and they do not cause us any specific headache.

Some constraints are structurally hard, such as not permitting deadlocks in a Gantt charts.
They may or may not be hard to deal with in when building valid candidate solutions.

Other constraints may not be structural but instead of a metric nature, e.g., \inQuotes{{\dots}with a cost not exceeding 1000~RMB.}
Such constraints may not even be hard, e.g., permit some violation as long as it is small.

Either way:
If there are constraints, then it is likely that most possible solutions are infeasible, as noted in \autoref{rule:infeasibleSolutions}.
And for our example problem, the \gls{JSSP}, this is the case.
So optimization is indeed interesting.%
\endhsection%
\endhsection%
%
11 changes: 10 additions & 1 deletion text/main/structure/instance/instance.tex
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
The \gls{JSSP}, for instance, has the goal of scheduling production jobs to machines under a set of constraints that we will discuss later.
A problem instance of the \gls{JSSP} is a concrete scenario, e.g., a concrete lists of tasks, requirements, and machines.%
%
\begin{definition}%
\begin{definition}[Problem Instance~\instance]%
\label{def:instance}%
A concrete instantiation of all information that are relevant from the perspective of solving an optimization problems is called a \emph{problem instance}~\instance.%
\end{definition}%
Expand Down Expand Up @@ -220,5 +220,14 @@
The actual code of the above, other utility methods, as well as sanity checks in the \codeil{__new__} constructor have here been omitted as they are unimportant for the understanding of the scenario.%
\endhsection%
\endhsection%
%
\hsection{Summary}%
We now have learned the first component of optimization problems.
When we say \inQuotes{optimization problem} we do not actually mean a single problem that we can solve.
We refer to a whole family of scenarios that have the same structure and can be solved by the same algorithms.
There is not just \emph{one} \gls{TSP} or \emph{one} \gls{JSSP}.
There are infinitely many of them.
They are called problem \emph{instances}~\instance.%
\endhsection%
\endhsection%
%
4 changes: 2 additions & 2 deletions text/main/structure/introduction/introduction.tex
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@

First, let us clarify what \emph{optimization problems} actually are.%
%
\begin{definition}%
\begin{definition}[Optimization Problem~\textrm{I}]%
\label{def:optimizationProblemEconomical}%
An \emph{optimization problem} is a situation~\instance\ which requires deciding for one choice from a set of possible alternatives in order to reach a predefined/required goal at minimal costs.%
\end{definition}%
Expand All @@ -32,7 +32,7 @@
Since all of them lead to reaching the goal, we want to pick the one choice with the minimal costs.
We can refine this situation into the more mathematical formulation given in \autoref{def:optimizationProblemMathematical}.%
%
\begin{definition}%
\begin{definition}[Optimization Problem~\textrm{II}]%
\label{def:optimizationProblemMathematical}%
The goal of solving an \emph{optimization problem} is finding an input value~$\globalOptimum{\solspel}\in\solutionSpace$ from a set~\solutionSpace\ of allowed values for which a function~$\objf:\solutionSpace\mapsto\realNumbers$ takes on the smallest value.%
\end{definition}%
Expand Down
Binary file not shown.
Binary file not shown.
Loading

0 comments on commit d62af88

Please sign in to comment.