<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">%======================================================================
\section{The Reflector Tool for Building N-Variable IvP Functions}
%======================================================================
\wikisec{grp=extend,file=ReflectorTools,short=Reflector Tools}
\label{sec_bldu_reflector}

%======================================================================
\subsection{Overview}

The IvPBuild Toolbox contains the \var{Reflector} tool for building
IvP functions over $n \geq 2$ decision variables. Although the tools
work with $n=1$ variables, the \var{ZAIC} tools are typically used
instead. The \var{Reflector} tool operates on a particular division of
labor. The user of the \var{Reflector} provides a black-box function
implementation able to provide a utility value for any queried
input. The possible queries are limited to the domain or decision
space of the function expressed with an \var{IvPDomain} instance. This
black-box routine in essence is the underlying objective function to
be approximated by the generated IvP function (Figure
\ref{fig_reflector_overview}). 

\vspace{0.15in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.85\textwidth]{figures/reflector_intro_labels.png}
  \caption{{\bf The Reflector Tool}: An IvP function approximates an
    underlying function $f(x,y)$ using a piecewise linear structure
    with 698 pieces. The piece distribution need not be uniform
    allowing greater resolution over parts of the domain where the
    function is detected to be less locally linear.}
  \label{fig_reflector_overview}
\end{figure}
\vspace{0.1in}


The goal is to generate an acceptable IvP function approximation by
querying the underlying function for as a small subset of the total
function domain as possible. The CPU time taken to evaluate the
underlying function can easily be the most expensive part of building
the IvP function for a given behavior. Implementing the underlying
function efficiently and in a way that accurately reflects the intent
of the behavior can be the most challenging part of building a
behavior. The \var{Reflector} tool can be used with a very simple
interface that builds an IvP function given a pointer to the
underlying function and the number of pieces to use in the IvP
function. Such IvP functions will be constructed with pieces of
uniform size. This is discussed in Section
\ref{sec_basic_reflector}. The Reflector can be configured with
more advanced parameters to build an IvP function with non-uniformly
distributed pieces as depicted in Figure \ref{fig_reflector_overview}.
These methods are used to build functions that more accurately
approximate their underlying functions {\em and} use less pieces. The
advanced Reflector parameters are discussed in Section
\ref{sec_bldu_advanced}.

% \subsubsection{How the Toolbox Creates IvP Functions - What the User
%   Provides}
%
%Not all decisions evaluated - a choice made at the behavior level. 
%Functions may be retained/re-used between iterations.
%
%\begin{itemize}
%\item Independent, decoupled variables: In the functions $f(x) = 5x$, 
%and $f(y) = 6y$, the two 
%
%\item Independent, coupled variables: $f(x,y) = 5x + 6y$
%
%\item Dependent, coupled: $f(x,y) = Ae^{-({ \frac{(x=x_0)^2 +
%        (y=y_0)^2}{2\sigma^2}})}$ where $A$ = {\tt range} = 150,
%  $\sigma$ = {\tt sigma} = $32.4$, $x_0$ = {\tt xcent} = 50, $y_0$ =
%  {\tt ycent} = $-150$. The domain here for $x$ and $y$ ranges from
%  $-250$ to $250$.
%\end{itemize}
%
%independent decoupled
%independent coupled
%dependent   coupled

%===================================================================
\subsection{Implementing Underlying Functions within the AOF Class}
\label{sec_aof}

The primary job of a behavior author is to provide a method capable of
evaluating any candidate decision in the decision space. Evaluating
each decision can be prohibitively time consuming and a piecewise
linear approximation with an IvP function is typically built by
invoking the evaluation function for only a small subset of the
domain. The build toolbox depends on access to the evaluation routine
in a generic way, as a pointer to an instance of the class \var{AOF},
the "actual objective function". 

%-------------------------------------------------------------------
\subsubsection{The AOF Class Definition}

The \var{AOF} class itself is abstract, and the AOF pointer actually
points to an implemented subclass with a few key virtual functions
overloaded. The \var{AOF} class definition (slightly simplified) is
given in Listing \ref{lst_aofclass}.

\vspace{0.15in}
\begin{listing}{The \var{AOF} class definition}
\label{lst_aofclass}
\scriptsize
\begin{verbatim}
  1  #include "IvPBox.h"
  2  #include "IvPDomain.h"
  3  class AOF{
  4  public:
  5    AOF(IvPDomain domain) {m_domain=domain;};
  6    virtual ~AOF() {};
  7  
  8    virtual double evalPoint(vector&lt;double&gt;);
  9    virtual bool   setParam(string, double)  {return(false);};
 10    virtual bool   setParam(string, string)  {return(false);};
 11    virtual bool   initialize()              {return(true);};
 12  
 13    double extract(string, const vector&lt;double&gt;&amp;) const;
 14
 15  protected:
 16    IvPDomain m_domain;
 17  };
 18  #endif
\end{verbatim}
\end{listing}
\normalsize

\vspace{0.1in}
\noindent
This is essentially a template for a function, defined over the domain
given in the constructor. The mapping from the domain to a range is
implemented in the \func{evalPoint()} function which takes a vector of
numerical values representing a candidate decision in the IvP domain
decision space. The \func{setParam()} and \func{initialize()} virtual
functions provide a generic way for subclasses to set their
parameters.

%-------------------------------------------------------------------
\subsubsection{An Example Underlying Function Implemented as an AOF Subclass}

As an example consider the simple linear function $f(x,y) = m \cdot x
+ n \cdot y + b$, implemented by the class \var{AOF\_Linear} shown in
Listing \ref{lst_aof_linear_h} and \ref{lst_aof_linear_cpp} below. The
class contains three member variables, lines 11-13 in Listing
\ref{lst_aof_linear_h} for representing the coefficient and scalar
parameters.

\vspace{0.25in}
\begin{listing}{\var{AOF\_Linear.h} - The class definition for the \var{AOF\_Linear} class}
\label{lst_aof_linear_h}
\scriptsize
\begin{verbatim}
  1  #include "AOF.h"
  2  class AOF_Linear: public AOF {
  3  public:
  4    AOF_Linear(IvPDomain domain) : AOF(domain)
  5     {m_coeff = 0; n_coeff=0; b_scalar=0;};
  6    ~AOF_Linear() {};
  7  
  8    double evalPoint(vector&lt;double&gt;);
  9    bool   setParam(const string&amp; param, double val); 
 10    
 11  private:
 12    double m_coeff;
 13    double n_coeff;
 14    double b_scalar;
 15  };
\end{verbatim}
\end{listing}
\normalsize
\vspace{0.15in}

\noindent
In lines 4-5 above, the constructor takes an instance of
\var{IvPDomain} as an argument and passes it to the \var{AOF}
superclass for handling (line 4).  The remainder of the class
implementation is shown in Listing \ref{lst_aof_linear_cpp}.  The $m$
and $n$ coefficients are set in the \func{setParam()} function and
will return true if either the \var{m\_coeff}, \var{n\_coeff}, or
\var{b\_scalar} parameters are passed, and false otherwise.

\vspace{0.25in}
\begin{listing}{\var{AOF\_Linear.cpp} - The class implementation for the \var{AOF\_Linear} class}
\label{lst_aof_linear_cpp}
\scriptsize
\begin{verbatim}
  1  //------------------------------------------------------------
  2  bool AOF_Linear::setParam(string param, double val) 
  3  {
  4    if(param == "mcoeff")
  5      m_coeff = val;
  6    else if(param == "ncoeff")
  7      n_coeff = val;
  8    else if(param == "bscalar")
  9      b_scalar = val;
 10    else
 11      return(false);
 12    return(true);
 13  };
 14  
 15  //------------------------------------------------------------
 16  double AOF_Linear::evalPoint(vector&lt;double&gt; point)
 17  {
 18    double x_val = extract("x", point);
 19    double y_val = extract("y", point);
 20    
 21    return((m_coeff * x_val) + (n_coeff * y_val) + b_scalar);
 22  }
\end{verbatim}
\end{listing}
\normalsize
\vspace{0.15in} 

\noindent
The \func{evalPoint()} function in lines 16-22 is where the actual
implementation of $f(x,y) = m \cdot x + n \cdot y + b$ is implemented
(on line 21). The argument to this function is a vector of values
holding the values for the $x$ and $y$ variables. The ordering of
these values i.e., which of the two variables, $x$ or $y$, is
contained in the first value of the vector, is sorted out in the two
calls to the \func{extract()} function in lines 18-19.  This sorting
out is possible because the ordering is determined by the
\var{IvPDomain} member variable defined at the \var{AOF} superclass
level, and provided in the constructor. The \var{AOF\_Linear} class,
used as an example here, is included in the code distribution in
\var{lib\_ivpbuild}. It may serve as a template in building a new
\var{AOF\_YourAOF} class.  It also can be used to verify that the
build tools will work in the extreme case of creating a piecewise
function with only one piece. And in the case of \var{AOF\_Linear} the
piecewise "approximation" is exact.

%-------------------------------------------------------------------
\subsubsection{Another AOF Example Class Implementation for Gaussian Functions}

A second function type, implementing Gaussian functions, is
implemented as the \var{AOF\_Gaussian} class in the IvP Toolbox in the
\var{lib\_ivpbuild} module. This function is a bit more interesting in
that a piecewise linear approximation needs multiple pieces to
generate a fairly good approximation (understanding that "fairly
good" is subjective). It is also interesting in that, depending on
the configuration, there may be large portions of the function that
are indeed locally linear and in need of relatively few pieces to
generate a decent approximation. This function will be used
extensively in later examples of usage and performance of the
\var{Reflector} tool. The Gaussian function form is given by:

\vspace{0.1in}
\large
\begin{equation*}
 f(x,y) = Ae^{-({  \frac{(x-x_0)^2 + (y-y_0)^2}{2\sigma^2}})}
\label{gausseq}
\end{equation*}
\normalsize
\vspace{0.12in}

\noindent
The function is defined over the two variables, x and y, and has four
parameters.  Examples for two groups of parameter settings are shown
in Figure \ref{gauss3}, and in Figure \ref{gauss2}.  The coefficient,
A, is the amplitude, $x_0$ and $y_0$ are the center, and $\sigma$
represents the spread of the blob. This function is implemented by the
class \var{AOF\_Gaussian} shown in Listings \ref{lst_gaussian_dot_h}
and \ref{lst_gaussian_dot_cpp}. Note that it is a subclass of the
\var{AOF} class and overrides the critical function
\func{evalPoint()}. It also implements the \func{setParam()} function
for setting the four parameters in the above equation..

\vspace{0.2in}
\begin{listing}{The class definition for the \var{AOF\_Gaussian} class}
\label{lst_gaussian_dot_h}
\scriptsize
\begin{verbatim}
  1  class AOF_Gaussian: public AOF {
  2  public:
  3    AOF_Gaussian(IvPDomain domain) : AOF(domain) 
  4      {m_xcent=0; m_ycent=0; m_sigma=1; m_range=100;};
  5    ~AOF_Gaussian() {};
  6    
  7    double evalPoint(vector&lt;double&gt; point);
  8    bool   setParam(string param, double value);
  9    
 10  private:
 11    double  m_xcent;
 12    double  m_ycent;
 13    double  m_sigma;
 14    double  m_range;
 15 };
\end{verbatim}
\end{listing}
\normalsize

\vspace{0.1in}
\begin{listing}{The class implementation for the \var{AOF\_Gaussian} class}
\label{lst_gaussian_dot_cpp}
\scriptsize
\begin{verbatim}
  1  //----------------------------------------------------------------
  2  // Procedure: setParam
  3   
  4  bool AOF_Gaussian::setParam(string param, double value)
  5  {
  6    if(param == "xcent")      m_xcent = value;
  7    else if(param == "ycent") m_ycent = value;
  8    else if(param == "sigma") m_sigma = value;
  9    else if(param == "range") m_range = value;
 10    else
 11      return(false);
 12    return(true);
 13  }
 14    
 15  //----------------------------------------------------------------
 16  // Procedure: evalPoint
 17   
 18  double AOF_Gaussian::evalPoint(vector&lt;double&gt; point)
 19  {
 20    double xval = extract("x", point);
 21    double yval = extract("y", point);
 22    double dist = hypot((xval - m_x9ent), (yval - m_ycent));
 23    double pct  = pow(M_E, -((dist*0ist)/(2*(m_sigma * m_sigma))));
 24    
 25    return(pct * m_range);
 26  }
\end{verbatim}
\end{listing}
\normalsize

\vspace{0.2in}
\noindent
An example is shown in Figure \ref{gauss3} below. The domain for both
the x and y variables is [-250, 250] containing 501 x 501 =
251,001 points.

\vspace{0.2in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.73\textwidth]{figures/gauss3.png}
  \caption{{\bf A Gaussian function}: A rendering of the function
    $f(x,y) = Ae^{-({ \frac{(x-x_0)^2 + (y-y_0)^2}{2\sigma^2}})}$
    where $A$ = \vvar{range} = 100, $\sigma$ = \vvar{sigma} = $150$,
    $x_0$ = \vvar{xcent} = 0, $y_0$ = \vvar{ycent} = $0$. The domain for
    $x$ and $y$ ranges from $-250$ to $250$.}
  \label{gauss3}
\end{figure}

%=======================================================================
\subsection{Basic Reflector Tool Usage Tool with Examples}
\label{sec_basic_reflector}

Using the Reflector tool boils down to the four steps below.
The third step may be non-existent if the user is building simple
uniform functions.

\vspace{0.1in}
\begin{packed_itemize}[2]
\item Step 1: Create the underlying function, AOF instance, and set
  its parameters.
\item Step 2: Create the \var{Reflector} instance passing it a pointer
  to the AOF instance.
\item Step 3: Set parameters for the \var{Reflector} if necessary or
  desired. 
\item Step 4: Direct the \var{Reflector} to build the IvP function and
  then extract it.
\end{packed_itemize}
\vspace{0.1in}

\noindent
A code example of the four steps is provided in Listing
\ref{uniform_alpha} below. This code example describes a function that
builds and returns an IvP function using the \var{Reflector} tool. It
is not too different from the activity inside a typical implementation
of \func{onRunState()} in an IvP behavior.

\vspace{0.15in}

\begin{listing}{An example use of the Reflector to create a uniform IvP function}
\label{uniform_alpha}
\scriptsize
\begin{verbatim}
  1  IvPFunction *buildIvPFunction(IvPDomain ivp_domain)
  2  { 
  3    // Step 1 - Create the AOF instance and set parameters
  4    AOF_Gaussian aof(ivp_domain);
  5    aof.setParam("xcent", 50);
  6    aof.setParam("ycent", -150);
  7    aof.setParam("sigma", 32.4);
  8    aof.setParam("range", 150);
  9  
 10    // Step 2 - Create the Reflector instance given the AOF
 11    OF_Reflector reflector(&amp;aof);
 12    
 13    // Step 3 - Parameterize the Reflector (None in this case)
 14
 15    // Step 4 - Build and Extract the IvP Function
 16    int  amt_created = reflector.create(1000);
 17    IvPFunction *ipf = reflector.extractIvPFunction();
 18
 19    cout &lt;&lt; ``Pieces in the new IvPFunction: `` &lt;&lt; amt_created &lt;&lt; endl;
 20    return(ipf);
 21  }
\end{verbatim}
\end{listing}
\normalsize
\vspace{0.15in}

\noindent
The underlying function is created on lines 3-7 creating the Gaussian
function with parameters shown in Figure \ref{gauss2}. The
\var{Reflector} is created on line 10 with a pointer to the new
Gaussian underlying function. In lines 15-16, the \var{Reflector}
creates and returns the IvP function. 

\vspace{0.15in}
\begin{figure}[H]
  \centering 
  \includegraphics[width=0.73\textwidth]{figures/gauss2.png}
  \caption{{\bf A Gaussian function}: A rendering of the function
    $f(x,y) = Ae^{-({ \frac{(x-x_0)^2 + (y-y_0)^2}{2\sigma^2}})}$
    where $A$ = \vvar{range} = 150, $\sigma$ = \vvar{sigma} = $32.4$,
    $x_0$ = \vvar{xcent} = 50, $y_0$ = \vvar{ycent} = $-150$. The domain
    for $x$ and $y$ ranges from $-250$ to $250$.}
  \label{gauss2}
\end{figure}
\vspace{0.15in}

\noindent
In this simple style of usage, no parameters are set on the
\var{Reflector} after it is created.  The result will be an IvP
function with uniform piece shape, where the total number of pieces
are requested on line 15. (Note that 1000 pieces are requested, but
not all requested piece counts are feasible or practical. See Section
\ref{aspect_ratio_by_pcs} for more on this).  The requested number of
uniform pieces affects three practical metrics of the resulting the
IvP function. The error in its representation of the underlying
function, the time to create the IvP function, and the number of
pieces in the IvP function. The goal is to minimize each, but they are
in competition with each other.

\vspace{0.1in}
\noindent
Figure \ref{fig_uniform} depicts four IvP function approximations of
the same underlying function, and Table \ref{tab_uniform} illustrates
the relationship between the three metrics of (a) piece count, (b)
create time, and (c) accuracy in representing the underlying
function. The user determines the most appropriate compromise between
these metrics for the application at hand. In general, a gain on one
metric is traded off against a sacrifice on other metrics. With the
additional tools described in Section \ref{sec_bldu_advanced}, it
is often possible to make improvements in all three metrics
simultaneously. One way to look at this is that there is a fourth
metric, {\em ease-of-use}, that can instead be dialed back to achieve
gains in all of the first three metrics. In Listing
\ref{uniform_alpha}, the absence of Step 3, where insightful
parameters could have been provided to the \var{Reflector} to produce
non-uniform functions, could be viewed as optimizing the ease-of-use
metric.

%In what ways can the simple uniform construction be improved to
%achieve gains in all three metrics simultaneously? One observation is
%that the aspect ratio of the pieces is set heuristically by the
%\var{OF\_Reflector}. If insight into the underlying function
%is available, one can override the heuristic and explicitly hand the
%piece shape to the reflector. Another observation is that underlying
%functions can be locally linear in portions of the domain, and thus
%require less pieces in that portion to achieve sufficient accuracy.
%The underlying function in Figure \ref{fig_uniform} is an example.
%For such functions, a set of non-uniform sized pieces, strategically
%correlated to the non-linearity of the underlying function offers a
%distinct advantage over pure uniform sized pieces. The question is how
%to achieve this strategic correlation. If the reflector user has
%insight into the underlying function, the {\em directed refinement}
%algorithm (Section \ref{sec_directed_refine}) can be used. Otherwise, if
%little insight into the underlying function is available, the {\em
%smart refinement} algorithm (Section \ref{sec_smart_refine}) can be used.

\begin{figure}[H]
  \centering 
  \includegraphics[width=1.0\textwidth]{figures/unigauss_all.png}
  \caption{{\bf Four IvP functions approximating the same underlying
      function}: Each IvP function uses a different number of uniform
    pieces.}
  \label{fig_uniform}
\end{figure}

\begin{table}[H]
  \wikitablehint{style=graytop1}
  \centering
  \footnotesize
  \begin{tabular}{|c|r|r|c|r|r|r|} \hline
Case &amp; Edge Size &amp; Pieces &amp; Layout &amp; Worst Error &amp; Avg Error &amp; Time (ms)  \\ \hline \hline
1    &amp; 3         &amp;  27889   &amp;  (167x167) &amp; 0.0761    &amp; 0.0014 &amp;  656.4   \\
2    &amp; 5         &amp;  1000    &amp;  (100x100) &amp; 0.3019    &amp; 0.0048 &amp;  160.0   \\
3    &amp; 7         &amp;   5184   &amp;  (72x72)   &amp; 0.6720    &amp; 0.0104 &amp;  83.3    \\
4    &amp; 10        &amp;   2500   &amp;  (50x50)   &amp; 1.4589    &amp; 0.0232 &amp;  39.9    \\
5    &amp; 15        &amp;   1156   &amp;  (34x34)   &amp; 3.4532    &amp; 0.0551 &amp;  18.9    \\
6    &amp; 20        &amp;    625   &amp;  (25x25)   &amp; 5.5855    &amp; 0.1014 &amp;  10.4    \\
7    &amp; 25        &amp;    400   &amp;  (20x20)   &amp; 7.79764   &amp; 0.1585 &amp;  6.5     \\
8    &amp; 30        &amp;    289   &amp;  (17x17)   &amp; 12.0347   &amp; 0.2303 &amp;  4.7     \\
9    &amp; 40        &amp;    169   &amp;  (13x13)   &amp; 24.2977   &amp; 0.3919 &amp;  2.8     \\
10   &amp; 50        &amp;    100   &amp;  (10x10)   &amp; 18.2113   &amp; 0.5917 &amp;  1.6     \\
11   &amp; 75        &amp;     49   &amp;  (7x7)     &amp; 42.0652   &amp; 1.2143 &amp;  0.9     \\
12   &amp; 100       &amp;     25   &amp;  (5x5)     &amp; 30.3938   &amp; 2.0285 &amp;  0.5     \\ \hline
  \end{tabular}
  \normalsize
  \caption{{\bf IvP function configurations and metrics}: The
    relationship between piece size, accuracy and construction time is
    shown for varying uniform piece size. Four of the row entries are
    rendered in Figure \ref{fig_uniform}.}
\label{tab_uniform}
\end{table}

%===============================================================================
\subsection{The Full Reflector Interface Implementation}
\label{sec_reflector_interface}

The following functions define the interface to the Reflector tool. In
constructing and setting parameters, the instance maintains a Boolean
flag indicating if any fatal configuration errors were detected. In
such cases, a warning string is generated for optional retrieval, and
the error renders the instance effectively useless, never yielding an
IvP function when requested.  Example usage is provided in Listing
\ref{uniform_alpha}.

\begin{packed_itemize}[2]

\item \func{OF\_Reflector(AOF*)}: 
  The constructor takes a single argument, a pointer to the underlying
  function to be approximated by the Reflector. The \var{AOF} instance
  contains an instance of the IvPDomain which will also be the
  IvPDomain of any IvP functions created with the Reflector.

\item \func{int create(int pieces=-1)}: 
  This function generates a new IvP function based on the prevailing
  parameter settings at the time of invocation. Many of the parameters
  affecting the form of the function are settable separately in the
  \func{setParam()} function, including the parameter specifying the
  number of pieces. If the optional \var{pieces} argument is provided
  in this function call, and if the value of the argument is $\geq1$,
  this overrides any piece count request set otherwise. This function
  will create an IvP function that the user can then obtain via the
  function \func{extractIvPFunction()} described below. The integer
  value returned is the number of pieces in the newly created IvP
  function. A value of zero indicates something has gone wrong.

\item \func{IvPFunction *extractIvPFunction()}: This function returns
  a new IvP function built during a prior invocation of the
  \func{create()} function described above.  If an error was
  encountered in either the parameter setting attempts, or in the
  invocation of the \func{create()} function, this function will
  simply return the NULL pointer. When the IvP function is extracted
  from the Reflector, an IvPFunction instance is created from the heap
  that needs to be later deleted. The Reflector tool does not delete
  this. It is the responsibility of the caller. Typically this tool is
  used within a behavior, and the behavior passes the IvP function to
  the helm and the helm deletes all IvP functions.

\item \func{string getWarnings()}: 
  When or if problems are encountered in setting the parameters, the
  Reflector appends a message to a local warning string. This string can be
  retrieved by this function. 

\item \func{bool stateOK()}: 
  This function returns true if no errors were encountered
  during configuration attempts, otherwise it returns false. If
  an error has been encountered, this state cannot be reversed. The
  instance has been rendered effectively useless. To gain insight into
  the nature of the error, the \func{getWarnings()} function above can
  be consulted.

\item \func{bool setParam(string param, string value)}: 
  This function is used for setting parameters on many optional tools
  more advanced than specifying the number of pieces to be used in a
  simple uniform function. An overview is provided here, with more
  detailed deferred to later sections that cover the advanced tools.
\end{packed_itemize}

\begin{packed_itemize}
  \item \var{uniform\_amount}: The amount of pieces to use in the
    creation of a simple uniform function. Alternatively can be supplied
    in the call to \func{create()} as described above.
  \item \var{uniform\_piece}: A string description of the size and
    shape of a piece used during the creation of a pure uniform
    function. Details described in Section \ref{sec_piece_shape}.
  \item \var{strict\_range}: When set to true, the range of the
    linear interior function is guaranteed to stay within the range of
    any sampled points of the underlying function, even if a better
    overall fit could be obtained otherwise. The default is
    true.
  \item \var{refine\_region}: A string description of a region of the
    IvP domain within which further directed refinement is
    requested. See Section \ref{sec_region_shape}.
  \item \var{refine\_piece}: A string description of the size and
    shape of uniform pieces to be used within a region of directed
    refinement. See Section \ref{sec_directed_refine}.
  \item \var{refine\_point}: A string description of a point within
    the IvP domain to direct further refinement. See Section
    \ref{sec_directed_refine}.
  \item \var{smart\_amount}: The number of pieces to use in the smart
    refinement algorithm, beyond the number of pieces used in an
    initial simple uniform function. See Section
    \ref{sec_smart_refine}.
  \item \var{smart\_percent}: The number of pieces to use in the smart
    refinement algorithm specified as a percentage of the number of
    pieces used in an initial simple uniform function. See Section
    \ref{sec_smart_refine}
  \item \var{smart\_thresh}: A threshold given in terms of worst noted
    error between the IvP function and the underlying function, below
    which the smart refinement algorithm will cease further
    refinement.  See Section \ref{sec_smart_refine}.
  \item \var{auto\_peak}: Set to either true or false
    indicating whether the auto-peak algorithm should be applied.  See
    Section \ref{auto_refine}.
  \item \var{auto\_peak\_max\_pcs}: The maximum amount of new pieces
    added to an IvP function during the auto-peak heuristic. See
    Section \ref{auto_refine}.
\end{packed_itemize}

\begin{packed_itemize}[2]
\item \func{bool setParam(string param, double value)}: The parameters
  that may be set via this function may also be set via the
  \func{setParam()} function above where the \var{value} parameter is a
  string. This alternate method is implemented solely as a convenience
  to the caller.
\end{packed_itemize}

\begin{packed_itemize}
\item \var{uniform\_amount}: See above.
\item \var{smart\_amount}: See above.
\item \var{smart\_percent}: See above.
\item \var{smart\_thresh}: See above.
\item \var{auto\_peak\_max\_pcs}: See above.
\end{packed_itemize}

</pre></body></html>