Browse Source

Remark the use and the semantics of the yield statement in Dixon.

Michele Orrù 11 years ago
parent
commit
434a76cc27
1 changed files with 8 additions and 3 deletions
  1. 8 3
      book/dixon.tex

+ 8 - 3
book/dixon.tex

@@ -176,6 +176,14 @@ and storing dependencies into a \emph{history matrix} $H$.
   \end{algorithmic}
   \end{algorithmic}
 \end{algorithm}
 \end{algorithm}
 
 
+\begin{remark}
+The \texttt{yield} statement in line $12$ of algorithm \ref{alg:dixon:kernel}
+has the same semantics as in the python programming language.
+It is intended to underline the fact that each $\{\mu  \mid H_{i,\mu} = 1\}$
+can lead to a solution for \ref{eq:dixon:x_sequence}, and therefore their
+generation can be performed asynchronously.
+\end{remark}
+
 
 
 \section{An Implementation Perspective}
 \section{An Implementation Perspective}
 
 
@@ -264,9 +272,6 @@ can even act on the \texttt{ker} function - but less easily.
 This idea would boil down to the same structure we discussed with Wiener's attack:
 This idea would boil down to the same structure we discussed with Wiener's attack:
 one node - the \emph{producer} - discovers linear dependencies, while the others
 one node - the \emph{producer} - discovers linear dependencies, while the others
 - the \emph{consumers} - attempt to factorize $N$.
 - the \emph{consumers} - attempt to factorize $N$.
-For this reason that we introduced the \texttt{yield} statement in line
-$12$ of algorithm \ref{alg:dixon:kernel}: the two jobs can be performed
-asynchronously.
 
 
 Certainly, due to the probabilistic nature of this algorithm, we can even think
 Certainly, due to the probabilistic nature of this algorithm, we can even think
 about running multiple instances of the same program. This solution is fairly
 about running multiple instances of the same program. This solution is fairly