Index: /reasoner/reasoner.tex
===================================================================
--- /reasoner/reasoner.tex	(revision 47)
+++ /reasoner/reasoner.tex	(revision 48)
@@ -131,5 +131,5 @@
 Variables can be \emph{local}, e.g., as specified in the IVML model used as parameters of a user-defined constraint function, within let-expression or as collection iterator. Such variables have the same properties as usual configuration variables and can be identified using $isLocal(v)$, which then returns $true$.
 
-Due to the specific semantics of default or frozen variables, IVML variables have an internal \emph{assignment state}. The state of individual variables is actually changed (indirectly) by the expression evaluator as side effect of constraint evaluation. The following states are defined:
+Due to the specific semantics of default or frozen variables, IVML variables have an internal \emph{assignment state} to be accessed via $state(v)$. The state of individual variables is actually changed (indirectly) by the expression evaluator as side effect of constraint evaluation. The following states are defined:
 
 \begin{itemize}
@@ -258,4 +258,5 @@
 \newcommand\variableMapping[0]{vm}
 \newcommand\relevantConstraints[0]{r_t}
+\newcommand\scopeAssignments[0]{a}
 
 The reasoner performs forward reasoning, i.e., it identifies relevant constraints (according to the reasoning mode), translates the constraints, evaluates them in a loop until all constraints are processed and adjusts/extends the constraint set upon variable value changes.  This section introduces the top-level reasoning algorithms, in particular the main reasoning loop in Section \ref{sectTopLevelMainReasoningLoop}, the top-level constraint translation in Section \ref{sectTopLevelConstraintsTranslation}, the top-level constraint evaluation in Section \ref{sectTopLevelConstraintsEvaluation} and the re-scheduling of constraints while evaluation in Section \ref{sectTopLevelConstraintsRescheduling}. The constraint translation will be discussed in detailed in Section \ref{sectTranslation}.
@@ -339,7 +340,7 @@
   \SetAlgoLined
   \KwIn{project $p$}
-  \KwData{constraint $base$, scope assignments $a$, problem records $m$, used variables $u$, constraint evaluator $e$, flags $hasTimeout$ and $stop$}
+  \KwData{constraint $base$, scope assignments $\scopeAssignments$, problem records $m$, used variables $u$, constraint evaluator $e$, flags $hasTimeout$ and $stop$}
   
-    $clearScopeAssignments(a)$\; \label{algEvalLoopClearScope}
+    $\scopeAssignments \assng \setEmpty{}$\; \label{algEvalLoopClearScope}%clearScopeAssignment
     $setDispatchScope(e, p)$\; \label{algEvalLoopDispatchScope}%evaluator.setDispatchScope
     \While {$|base| > 0 \wedge \neg hasTimeout \wedge \neg stop$} { \label{algEvalLoopLoopStart}
@@ -368,16 +369,19 @@
 \subsection{Constraint Re-scheduling}\label{sectTopLevelConstraintsRescheduling}
 
-When variable $v$ is changed as side effect of a constraint evaluation during reasoning, Algorithm \ref{algVarChange} is called. If the changed variable is not local, i.e., neither a parameter of a user-defined function, an iterator of a container operation nor a local variable defined in a let-expression, the change is registered within the actual project scope. This scope information is used by the evaluator prior to a variable assignment to check for illegal duplicate assignments within the same scope. Then all known constraints (\MISSING{dynamic value type changes}) for a variable are identified and become subject to re-scheduling. The identification includes both, parent and nested variables, which is in particular relevant to capture all relevant constraints for variables in compound and container values. These constraints are appended to the constraint $base$, not adding an individual constraint if it is already scheduled in the constraint $base$.
+When variable $v$ is changed as side effect of a constraint evaluation during reasoning, Algorithm \ref{algVarChange} is called. If the changed variable is not local, i.e., neither a parameter of a user-defined function, an iterator of a container operation nor a local variable defined in a let-expression, the variable is relevant for re-scheduling. First, Algorithm \ref{algVarChange} registers in lines \ref{algVarChangeScopeStart}-\ref{algVarChangeScopeEnd} the change of $v$ within the actual project scope (\TBD{correct? also \IVML{DEFAULT}? Test case needed!}) if the value of $v$ actually has been affected by reasoning. This scope information is used by the evaluator prior to a variable assignment to check for illegal duplicate assignments within the same scope. Then all known constraints (\MISSING{dynamic value type changes}) for a variable are identified and become subject to re-scheduling. The identification includes both, parent  (line \ref{algVarChangeRescheduleParents}) and nested (line \ref{algVarChangeRescheduleNested}) variables, which is in particular relevant to capture all relevant constraints for variables in compound and container values. These constraints are appended to the constraint $base$, not adding an individual constraint if it is already scheduled in the constraint $base$.
 
 \begin{algorithm}[H]
   \SetAlgoLined
   \KwIn{decision variable $v$, old value $val$}
-  \KwData{scope assignments $a$, relevant constraints $\relevantConstraints$}
+  \KwData{scope assignments $\scopeAssignments$, relevant constraints $\relevantConstraints$}
   
   \If{$\neg isLocal(v)$}{
-      $registerScopeAssignment(a, v)$\;
+      \If{$state(v) == \IVML{DERIVED}$}{\label{algVarChangeScopeStart} %addScopeAssignment
+          $\scopeAssignments \assng \scopeAssignments \cup \set{v}$\;
+      }\label{algVarChangeScopeEnd}
       \MISSING{change constraints if dynamic value type changes}\;
-      $base \assng base \addSeqNoDupl \bigcup_{p\in allParents(v)}t[p]$\; %constraintsForParent
-      $base \assng base \addSeqNoDupl \bigcup_{c\in alNested(v)}t[c]$\; %constraintsForChilds, nested geht für alle variablen
+      $base \assng base \addSeqNoDupl \seqWith{\relevantConstraints[p]}{p\in allParents(v)}$\; \label{algVarChangeRescheduleParents}%constraintsForParent
+      $base \assng base \addSeqNoDupl \seqWith{\relevantConstraints[n]}{n\in allNested(v)}$\; \label{algVarChangeRescheduleNested}%constraintsForParent
+%      $base \assng base \addSeqNoDupl \bigcup_{c\in alNested(v)}\relevantConstraints[c]$\; \label{algVarChangeRescheduleNested}%constraintsForChilds, nested geht für alle variablen
   }
  \caption{Adjusting the constraint base (\IVML{notifyChanged}).}\label{algVarChange}
