Bug#147204: tetex-base: Float placed on the page before the reference
Package: tetex-base
Version: 1.0.2+20011202-2
Severity: normal
Lamport writes that a float is never placed on a page *before* its
(first) reference. I attach a text where this happens (sorry, it has
a few pages):
----------------------------
\documentclass[a4paper,11pt]{book}
\begin{document}
\begin{itemize}
\item create the agent. It is shared by all the processors and its
access is protected by a mutex.
\item Global move agents: expandable vector containing agents which
are in a domain and move into another domain. It is shared by all
the processors and its access is protected by a mutex.
\item Global conflicts: vector containing the agents involved in
conflicts. Each element corresponds to a conflict, and contains all
the agents involved in the conflict. It is shared by all the
processors, but each processor accesses only the conflicts appearing
in its domain, hence no mutex is used.
\item Global new positions: static matrix at the same size of the
environment, whose elements contain mainly the id of the conflict
element (next structure), if any. Each time an agent is added in
this structure (mark new position), it checks if there is already an
agent inside and creates a conflict if affirmative. It is shared by
all the processors, but each processor accesses only its domain,
hence no mutex is used.
\end{itemize}
\subsection{Execution flow}
The following steps form a cycle and are executed by each processor:
\begin{enumerate}
\item Plan step: execute behaviour of all agents and plan agent
creation and destruction.
\item Process global created agents. [put them in local structures]
\item Process global move agents.
\item Spatial conflict step: solve all conflicts. Create winner
agents. For loser agents, refuse their creation or change their
move action in stay.
\item Create local agents.
\item Action step: kill agents and execute effectively the planned
action of the agents.
\item User step: execute sequentially the user function. This is the
normal place to specify the end of simulation and to save
information about the system. Also, the cycle number is
incremented.
\item Parallel saving step: if specified in previous step, the whole
system is saved in parallel.
\item Potential field step: update if necessary the potential fields.
\end{enumerate}
aaa
The whole procedure is presented in figure~\ref{fig:concurrency-code}
and is explained below.
\begin{figure}
\begin{verbatim}
for all global created agents
if it is in its domain
put it in local created agent structure
mark its position
for all global move agents
it its new position is in its domain
mark the new position
for all (local) conflicts
if created agents exist
choose randomly the winner among them
effectively create the winner
else // only move agents
if high priority agents exist
choose randomly the winner among them
else // normal priority only
choose randomly the winner among them
for all loser agents
if it was to be created
refuse its creation
else // it wanted to move
change its action into stay
for all local created agents not in conflict
create them
SYNC
for all agents whose new position is in its domain
if agent was to be killed
kill it
else
execute its action
SYNC
if thid==0
execute user function
if it returns STOP
mark end simulation
cycle = cycle + 1
SYNC
save system if needed (in parallel)
if not end simulation
recalculate potential fields if needed
\end{verbatim}
\caption{Execution flow of each processor.}
\label{fig:concurrency-code}
\end{figure}
During the first step, each processor execute the behaviour of the
agents found in its domain. If they create agents (through the call
to the appropriate function) in the local domain, then the created
agents are put in its local structure of created agents and their
position is stored in the global new position structure. Elsewhere,
if the position of created agents is in another domain, they are put
in a global structure to be dispatched afterwards in a local
structure. If they move and their new position is again in its
domain, their new move is stored either in the global new position
structure. If they move and change the domain, they are put in the
global move agent structure.
After a synchronisation among all the processors, each processor reads
the global created agent structure and copy the agents belonging to
its domain into its local created agent structure. All the created
agents are now in the appropriate local created agent structures.
Afterwards, the same processing is done for move agents. Now all the
move agents are also in local move agent structures.
The next step solves the spatial conflicts among agents. The
conflicts can be solved separately by each processor, since any
conflict involves agents whose new position is identical, hence
processed by a same processor. For any conflict case, in order, a
random winner is chosen among the created agents. If there are no
created agents in the conflict, a random winner is chosen among agents
with high priority, if there are any, elsewhere among all the agents.
Winner agents are effectively created, while for loser agents, their
creation is refused or their action is changed into stay (no action).
The next step effectively creates all the agents not in conflict in
the local created agent structure. Now, all the agents to be created
are effectively created (and appear in the agent structure).
After a synchronisation among all the processors, all the agents carry
out their action. Also the agent kills are effectively done in this
step.
After another synchronisation among all the processors, one thread
executes the user function. If it returns \mbox{\texttt{STOP}}, then
the
simulation is planned to end. The cycle number is incremented.
After a synchronisation among all the processors, the state of all the
system is saved if it has been specified. The saving is done in this
step because it is done in parallel by all the processors, while the
previous step is executed in sequential.
The last step updates, if needed, the potential fields. All the
vectors with cycle-life information are cleared.
These steps are executed repeatedly until the end of the simulation.
After a synchronisation among all the processors, all the agents carry
out their action. Also the agent kills are effectively done in this
step.
After another synchronisation among all the processors, one thread
executes the user function. If it returns \mbox{\texttt{STOP}}, then
the
simulation is planned to end. The cycle number is incremented.
After a synchronisation among all the processors, the state of all the
system is saved if it has been specified. The saving is done in this
step because it is done in parallel by all the processors, while the
previous step is executed in sequential.
The last step updates, if needed, the potential fields. All the
vectors with cycle-life information are cleared.
These steps are executed repeatedly until the end of the simulation.
\end{document}
-----------------------------------------------------------
Am I missing anything? Thanks,
Eugen
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux eminescu 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages tetex-base depends on:
ii dpkg 1.9.20 Package maintenance system for Deb
ii texinfo 4.1-2 Documentation system for on-line i
--
To UNSUBSCRIBE, email to debian-tetex-maint-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: