\chapter{Design of the Implementation}

\section{How other cT Applications are implemented}

The other cT applications that have been written are quite different from
each other.  To make maintainability of the applications as easy as
possible, a requirement was that implementation of RVadd be modelled
after one of the already existing applications. However, there were
problems caused by the way the other two applications were written.  The
queuing program had an interface completely different from the
intended look of RVadd, and the Bernoulli application had a lack of
documentation for the code, which made it extremely difficult to
understand many of the subroutines that were used.


\section{Programming Conventions used in RVadd}

Because of the similarity of Grant's Bernoulli Process Application to the
old CDS application, the programming style of RVadd was made somewhat
similar to Grant's.  As is standard with most cT applications, the
program consists of only one main file, editted and compiled in cT's
integrated environment.  All of the functions are extremely modularized,
but there are very few local or global variables, or arguments to
procedures.  Instead, the variables are separated into ``groups'', which
allow several procedures to use each batch of variables.  There is not
much convention in the naming of the previous cT applications, so the
convention is also very loose in RVadd.  Most variables have all
lower-case names, and constants are fully capitalized.  The different
words making up the procedure names are separated by an underscore, to
make it easier to read procedure names.  Comments describing the function
of units are placed before the top of the unit, and the header of each
unit is in bold.  The name of the main units for each of the screens is 
of XXX\_page, where XXX is the name of the screen.  Also, there is a
unit, ``main'', which is run as soon as the program is started, to
initialize all the variables.

\paragraph{}
Several local variable names are reused for the same purpose in
different units.

%% **********************************************************************
%% **********************************************************************

\begin{itemize}

\item ``index'':  counter for loops
\item ``which'':  denotes whether pmf a or b should be used

\end{itemize}

\section{Problems with cT}

\paragraph{Screen Refresh}

Whenever the screen is refreshed in cT, the execution of the program is
restarted at the begining of the current main unit.  However, because the
contents of variables are not lost, and there is no animation in RVadd,
this does not pose much of a problem.  One precaution that was taken was
the saving of the state of sliders into a variable.  Another problem that
was caused by the unit restarting was an inability to initialize
variables.  There is no natural way to do this, and if they are
initialized in the procedure, they will be reinitialized every time the
screen refreshes.  To fix this, there is a startup unit, ``main'', which
initializes all the variables when the program is run.

\paragraph{}
If any modifications are made to RVadd in the future, to incorporate some
sort of animation, this limitation of cT must be reviewed to make sure
that no information is lost.

\paragraph{cT crash on a screen refresh}

If a slider is being held down, and the screen has to refresh, cT will
crash.  This bug is inherent to cT, and has been reported to the
developers.  The only way to get around it currently is to avoid the use
of sliders.

\paragraph{Callback Functions}

Callback functions for buttons and sliders can only have one argument
passed to them.  To pass more variables to a function called as a
callback, more information had to be encoded into a single argument.

\paragraph{Lack of Interrupts for Mouse Events}

When input is required from the mouse, cT requires a pause in the
program, to wait for the input.  Nothing can be executed by the program
while it is waiting for the mouse to be used.

\paragraph{Color vs. Black/White}

When color commands are sent to a cT program running on a black and white
screen, there can be unpredictable results.  For this reason, RVadd is
implemented in black and white only, to ensure compatibility across
different computers.

\paragraph{Screen Sizes}

To maximize usability at various screen and window sizes, the cT feature
for normalized coordinates is used.  This allows everything to stay at
its appropriate place in proportion to the screen, no matter what size
the window is resized to.

\paragraph{Mouse}

To achieve greatest compatibility across platforms, only the primary
mouse button is used.  This ensures that machines with only one mouse
button can still do all the functions of the application.

\paragraph{Multiple Graph Handling}

In cT, there is no easy way to automatically handle having several graphs
on the screen at the same time.  In order to have graphs of the two PMFs,
and any other graphs, all of the information has to be stored and set
manually.

\section{Layout of the Program}

The application is separated into several different screens, each
describing or demonstrating the addition of random variables in a
different way.  The different screens follow each other in order, and can
be reached through ``Prev'' and ``Next'' buttons, or any particular
screen can be accessed by going through the ``Screens'' option in the
menubar.

\paragraph{}

There is a subroutine in RVadd to jump to the different screens, and a
subroutine for each screen.  When the navigation buttons (``Prev'' or
``Next'') are clicked, or a screen is chosen through the menubar, the
unit to jump is called, and it will in turn call the appropriate
procedure.  Each screen is implemented by one main procedure, with
sub-units where necessary.  If screens are added, or the order of the
screens is changed, both the menubar and the jump\_to\_page procedure must
be modified.

\subsection{The Screens}

\paragraph{Adding Independent Variables using Sample Space}

There are currently two different procedures written to show the summing
of independent variables, but only one is used.  The other can be called
instead by changing a line in the main procedure for the page.

\paragraph{Convolution at work}

Many delays were introduced because of the lack of mathematical functions
in cT.  There is no way in cT to easily have 3 different graphs
concurrently, so it is necessary to manually change from graph to graph.
A lot of time had to be spent writing preliminary functions to handle and
initialize the arrays and the graphs.

\paragraph{Editting Screen}

There are three procedures written to edit the PMFs in three different
ways.  Only one of these is in use, and the others can be called instead
with trivial changes to the main ``Edit'' unit.

\begin{enumerate}

\item Sliders to edit the PMFs, as in Johnny Piscitello's application.

\item ``Up'' and ``Down'' buttons to edit the PMFs.

\item Dragging the bars directly on the bargraph to edit.  This is the
method that is currently being used, because it is more intuitive.
Because of cT limitations mentioned earlier, a button to ``Edit'' still
has to be clicked in order to set the PMF values.

\end{enumerate}
