Alberto,
It's looking pretty good I think.
Heavily edited.
Please look at the points entitled Alberto:
Some parts couldn't be edited because I didn't understand them
well enough.
Thanks,
Dennis

--=====================_456135==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

\documentclass{article}
\usepackage{graphicx}
\usepackage{epsfig}
\usepackage{latexsym}

\begin{document}

%% Outline

%% Motivation, examples, show our language by example.
%% integrated with generous references to other work.
%% Framework and some of the more important transformations
%% integrated with related work on transformations.
%% Examples.
%% Performance results.


\title{AQuery: an Arrable-Based Approach to Array Query
Languages and Optimization}
\author{}
\date{{\Large Draft Note} \\  \vspace{0.6 in} \today}


\maketitle

\vspace{0.6 in}
\noindent {\bf Abstract --- }
\vspace{0.6 in}

%%===========================
\section{Introduction}
\label{sec:intro}

Querying order arises naturally in applications
ranging from finance to molecular biology to linguistics.
A financial analyst may be interested in moving averages in or correlation
among price time series.
A biologist may be interested in frequent nucleic acid motifs.
A linguist may want to study the relationships among interlinear
phrases.
SQL:99 follows a small collection of research languages to
provide this facility and is the first language to gain
commercial acceptance.

SQL:99 adds 
a new order-based construct
(OVER) to the SELECT clause, a notion of row numbering (but not
subscripting),
and a simple ARRAY data type.
That is, order has been added as an afterthought, making it
hard to express queries.
Because it's hard to express queries using order,
it is also hard to optimize them, because the problem is similar
to nested query optimization.

Optimizations of special cases of order do exist.
For example,
there are several efficient techniques 
for early or lazy sorting \cite{SSM96}, finding the
top k tuples \cite{CK97}, and order-preserving physical operations
\cite{CKK+00}, to mention a few.
But these techniques are applied in isolation, each in its own
pre- or pos-optimization step.
What is missing is a data model that treats order
as a first class algebraic concept from the ground up.
The result is a clear, expressive language offering many opportunities
for optimization, some of which are new.

Our starting point is an ordered table called
{\em arrable}, as in array table, for it is simply a
collection of named arrays where the names are column headers.
Thus, arrables have the physical appearance of a table and can support
the order-dependent queries of SQL:92 as well as queries 
like moving averages that depend
on the order within the column arrays.
Generally,
operations may change order (e.g. sort and hash), may preserve order
(e.g. a grouping expression on stocks that
associates a sequence of prices with each stock, where that sequence
is consistent with the order in the original table),
or may exploit order (e.g. correlation).

Thus, our system is based on an algebra of arrables.
The query language
{\em AQuery}.
is a dialect of SQL, in that the classic SELECT-FROM-WHERE
clauses are present, but the predicates and expression that can
be used on it include order based queries and updates.
As you'll see, the language is simple enough to foster idiom 
recognition.



In the remainder of the paper, we describe the query language,
the algebra, transformations, and experiments.


%%===========================
\section{AQuery by Example}
\label{sec:aquery}


The following arrables support our running examples.
{\sf Ticks(ID, tradeDate, timestamp, volume, price,  ...)
ORDERED BY timestamp}
holds trades done in the financial markets,
where ID is the ticker of the traded security, 
timestamp identifies the date and time of a particular
trade (tradeDate is a human-readable form of the day
portion), volume is the number
of shares that exchanged hands in the trade, and price is the price
of the trade.
{\sf Base(ID, Name, SIC, ...) ORDERED BY ID}
where Name is the name of the security, and SIC is
its standard industry code (eg., computer,
automobile, etc).
Note that arrables may have their sort order explicitly
declared.
It is most convenient if this order is maintained by inserts
for free -- time order has this property.

%A query's assumed order is declared in a construct called
%{\sf ASSUMING ORDER} which is appended at the end of the {\sf FROM}
%clause.
%All the predicates and expressions in a query assume that
%the arrable resulting from the {\sf FROM} clause is in
%a determined order.
%(It's up to the optimizer to take advantage of existing order.
%But that will be discussed later.)


In AQuery, expressions manipulate
entire vectors and always return vectors.
Built-in vector-to-vector functions include
avgs which is a running average; mins, a running minimum, just to
mention a few.
``Running'' operations could take an extra parameter
determining the size of a window, as would need, for instance,
a 3-day moving average, avgs(3,$\cdots$).


\vspace{0.1 in}
\noindent {\bf Example 1.}
For a given stock and a given date, find the
maximum profit one could obtain by buying it and
then selling it later that day.


{\sf
\begin{tabbing}
xxxxxxxxxxxx\= \kill
SELECT   \>max(price - mins(price)) \\
FROM     \>Ticks  \\
          \>ASSUMING ORDER timestamp \\
WHERE    \>ID = 'xxx' \\
          \>AND tradeDate = '99/99/99'
\end{tabbing}
}

In words, take the vector of prices ordered by timestamp
(that's what the {\em ASSUMING} clause does) and subtract
from that the running minimum of prices.
The running minimum at time t gives 
the lowest purchase price at any time up to t.
Hence the difference between the two vectors gives the maximum
one could win at each time t. The max function
gives the maximum win over any time t.
Note that taking {\sf max(price) - min(price)} wouldn't
work, because the highest price may occur before the lowest
when the market goes down.
$\Box$
\vspace{0.1 in}


In SQL:92, {\em GROUP BY} yields a scalar aggregate corresponding
to each group.
In AQuery,
GROUP BY groups columns into arrays.
These columns may or may not be further processed by
aggregating functions.
Note that this may generate non-first-normal form arrables, but 
the nesting goes only one level deep.
Further, a well-formed arrable is one in which, for each tuple $t$,
if more than one attribute of $t$ holds an array-typed field,
then all such fields  have arrays of the same cardinality.


\vspace{0.1 in}
\noindent {\bf Example 2.}
Get the latest 10 ticks for each stock in the
database.

{\sf
\begin{tabbing}
xxxxxxxxxxxx\= \kill
SELECT   \>ID, last(10, price) \\
FROM     \>Ticks  \\
          \>ASSUMING ORDER timestamp \\
GROUP BY \> ID
\end{tabbing}
}

After the sort order is enforced,
Ticks is divided into groups based on their
ID values.
The assumed order is preserved within each group
because grouping is semantically order-preserving in AQuery, 
but groups appear in no particular order.
So, the IDs may not appear in any particular order, but
within each row, the prices will appear in timestamp order.
{\sf last()} is iteratively applied to each row, trimming it
down to 10 position at best.
{\em Alberto: do we need each here?}
The result is a well formed arrable.
The query offers many opportunities for optimization, as we will
see later.
$\Box$
\vspace{0.1 in}


Arrables that have array-field types may be unnested to
first normal form by the {\sf FLATTEN} operation.
This is similar to but generalizes
the SQL:1999 UNNEST operation. 


\vspace{0.1 in}
\noindent {\bf Example 3.}
Find the dates where the 21-day and 5-month moving
average price for a given set of stocks cross, during a
6-month period.
The traded stocks IDs are in a table called traded stocks.

{\sf
\begin{tabbing}
xxx\= xxxxxxxxxxxx\= \kill
WITH \\
   \>averages (ID, tradeDate, a21, a5, pa21, pa5) AS \\
   \>(SELECT \>ID, tradeDate, \\
   \>        \>avgs(21 days, ClosePrice) as a21,  \\
   \>        \>avgs(5 months,ClosePrice) as a5,  \\
   \>        \>prev(avgs(21 days, ClosePrice)) as pa21,  \\
   \>        \>prev(avgs(5 months,ClosePrice)) as pa5 \\
   \>FROM    \>tradedstocks NATURAL JOIN Market \\
   \>        \>ASSUME ORDER ID, TradeDate \\
   \> GROUP BY \>ID) \\
xxxxxxxxxxx\= \kill
SELECT \>ID, TradeDate \\
FROM   \>FLATTEN(averages) \\
WHERE  \>a21 $>$ a5 \\
        \> AND pa21 $<=$ pa5 \\
        \>AND today() - 6 months $>$ tradeDate
\end{tabbing}
}


The {\sf WITH }

It borrows its semantics from SQL:1999.
Intuitively, it's a non-correlated sub-query that can
be referred to only in the {\sf FROM} clause of the main query.
The virtual table {\sf averages} 
contains the 5-month moving averages, the 21-days 
moving averages,
and their 'prev' vectors for the traded securities.
Given that table, the query is straightforward.
$\Box$
\vspace{0.1 in}


Subscripts may be used on any column header,
because columns are simply arrays.
This generalizes
SQL:1999's ROW\_NUMBER capability.
Sequences of indexes (positions) can be synthetically
generated.
Thus, queries that rely on patterns of positions
become straightforward.


\vspace{0.1 in}
\noindent {\bf Example 4.}
Find the standard deviation of each value, every 10th
value and every 100 th tick of a given stock

{\sf
\begin{tabbing}
xxxxxxxxxxxx\= \kill
SELECT \>stdev(closePrice), stdev(closePrice[EVERY 10]), \\
        \>stdev(closePrice[EVERY 100]) \\
FROM   \>Ticks \\
        \>ASSUMING ORDER timestamp \\
WHERE  \>ID = 'xxx'
\end{tabbing}
}


We introduce the use of subscripting, as a sampling
mechanism here.
EVERY n is syntactic sugar for the integer sequence
0, n, 2n,..., m, where m is the highest index less than or
equal to the vector cardinality such that m mod n = 0.
Note that subscripting uses all indexes at once,
closePrice[0, n, 2n,...,m], producing an entire new vector
as opposed to one scalar at a time.
The stdev function computes the standard deviation.
$\Box$
\vspace{0.1 in}


In AQuery, order is specified by the ASSUMING clause (if necessary)
and then is preserved by each operation.
If a query specifies a null ASSUMING clause, then non-order-preserving
implementations of operations can be used.


%%===========================
\section{Algebra and Transformation Rules}
\label{sec:transf}


Semantically speaking, a data stream's ({\sf ASSUMING})
order should be enforced right after the {\sf FROM} clause is
processed.
Optmization may delay or even eliminate sorting. 
Order-based predicates and expressions may constrain optimization.
We seek a set of transformations that preserve semantics
while enhancing performance.
Because order is first class,
every relational algebraic operator has at least two flavors:
an order-preserving and an order-oblivious
one.
We now discuss definitions used throughout this section.


\subsection{Preliminaries}
\label{subsec:prelim}

\noindent {\bf Notation.}
Let $A$ and $B$ be lists of attribute names (which will name arrays),
$r$ an arrable (a collection of named arrays),
predicate $P$ a function from a list of arrays to arrays
of booleans,
and function $f$ a function from a list of arrays to arrays.
Order-dependent predicates and functions will have a
superscript $od$; order-preserving functions, a superscript $op$;
and order-generating operations, a superscript $og$.


\noindent {\bf Definition (Auxiliary Functions).}
$Att(r)$ returns the collection of names of the attributes $r$ is made of.
$Order(r)$ returns a list (ordered) of attributes $X$
from $Att(r)$
such that if
$i<j$ then $r[i].X <= r[j].X$.
We call $order(r)$ ``the attributes that $r$ is ordered by''.
$Index(bv)$ is a conversion function from an array of booleans $bv$
to an array of
subscripts such that Index$(bv)= \langle i \mid bv[i]=1 \rangle$.
We need this because predicates return boolean arrays.
$Indexsort_A(r)$ returns an array of indexes for $r$
that would permute $r$ in such a way that if $r'$ were
the result of the permutation, then $order(r')$ = $A$.
$FD(r)$ returns the set of functional dependencies among
columns of r.
$Dupelim(r)$ returns all distinct tuples of $r$.


\noindent {\bf Definition (Order-equivalence).}
Two arrables $r_1$ and $r_2$ are {\em order-equivalent}
with respect to the list of attributes $A$, denoted $r_1 \equiv_A r_2$,
if $A$ is a  prefix of Order$(r_1)$ and of Order$(r_2)$, and some
permutation of $r_1$ is identical to $r_2$.
We denote by $r_1 \equiv_{\{\}} r_2$ the case where $r_1$
and $r_2$ are multiset-equivalent (i.e. they contain the same set
of tuples and for each tuple in the set, they contain the same
number of instances of that tuple).


\noindent {\bf Definition (List Operations).}
Let {\em list difference} $A-B = \langle a_1,a_2,\cdots,a_n \rangle$
be such that $a_i \in A$, $a_i \not\in B$, and if $i<j$ then
$a_i$ precedes $a_j$ in $A$.
Let {\em list concatenation} $A\bullet B = \langle a_1,\cdots,
a_n,b_1,\cdots,b_m\rangle$ be such that $a_i \in A$, $b_i \in B$,
and if $i<j$ then $a_i$ (or $b_i$) precedes $a_j$ (or $b_j$)
in $A$ (or $B$, respectively).
The set of attributes in $A$ and the set in $B$ need not be
disjoint.


\noindent {\bf Definition (Miscellaneous on vectors).}
Let the {\em cardinality} of a vector $v$ be denoted by $\vert
v\vert$  and an {\em array of indexes} into  $v$ (between
$0$ and $|v|-1$) by $idx$.
Let $f$ be any function from vector(s) to vector.
Then the {\em substitution} $f\{v \leftarrow v^\prime\}$ is
the result of replacing the vector $v$ for $v\prime$ in $f$.


\subsection{Logical Equivalences}
\label{subsec:}

We now state the main logical equivalences between the
algebra operators underlying AQuery.
We will be giving an operator's formal definition as
it appears.
We have two goals:
investigate equivalences involving sort
and identify transformations
arising from the option to implement algebraic operators as order-preserving
or order-oblivious.
In sub-section \ref{subsec:examples} we will be showing
example optimization of queries using the rules given
here.
Only some of these transformations are original.
We discuss the sources for the others in our related work section.

%% Dennis: some of the equivalences appear in other works
%% We say that in the related work, but here we are showing
%% which ones is ``ours'' and which ones are not.
%% Should we do it?


\subsubsection{Sort Elimination}
\label{subsubsec:sort}

In many situations, sorts are
unnecessary; in others, the number of attributes to be
sorted on can be reduced.
Table \ref{tab:sortrans} depicts such transformations.

\begin{table}[h]
\begin{tabular*}{4.75 in}{l@{\extracolsep{\fill}}r}

sort$_A(r) \equiv_A r$
    & if $A$ is prefix of Order$(r)$ \\

sort$_A(r) \equiv_A r$
    & if $\mid \mbox{Dupelim}(\pi_A(r))\mid = 1$ \\

sort$_{A\bullet B}(r) \equiv_{A\bullet B} \mbox{ sort}_{A}^o(r)$
    & if $B$ is a prefix of Order$(r)$\\

sort$_A(\mbox{sort}_B(r)) \equiv_{A\bullet B} \mbox{ sort}_A(r)$
    & if $A \rightarrow B \in FD(r)$ \\

sort$_A(\mbox{sort}_B(r)) \equiv_{A\bullet B} \mbox{ sort}_{A \bullet 
(B-A)}(r)$
    & \\

op-path$($sort$(r)) \equiv_{\{\}}$ op-path$(r)$
    & if op-path has no $od$ operation

\end{tabular*}
\caption{\label{tab:sortrans} Sort elimination logical equivalences}
\end{table}

In the first equivalence sort is unnecessary because
the arrable is already sorted; in the second, because there is only one
distinct value for the attributes being sorted over.
The superscript $o$ on the left-hand side of the third sort
means that
the sort is relatively
order preserving.
Formally, $sort_A^o$ is {\em relatively order preserving} if
whenever $r^\prime = \mbox{sort}_A^o(r)$, if $r[i].A=r[j].A$
and $i<j$ and $r[i]$ maps to $r^\prime[i^\prime]$ and
$r[j]$ maps to $r^\prime[j^\prime]$ then $i^\prime<j^\prime$.
That is, a relatively
order-preserving sort on $A$ does not 
the order of rows that are equal in their $A$ values.
The forth and fifth rules reduce the number of
attributes to sort on by, respectively, taking advantage of
a functional dependency among the sorting attributes, and
of duplicate sort attributes.
Finally, the last equivalence states that if no operation
above a sort is order-dependent, then that sort has no reason
to be executed.


\subsubsection{Selection and Array Indexing (subscripting)}
\label{subsubsec:sel}

A selection can be viewed as a form of array indexing in that it 
produces the values that are indexed.
Table \ref{tab:seltrans} shows the selection and array indexing
equivalences.

\begin{table}[h]
\begin{tabular*}{4.75 in}{l@{\extracolsep{\fill}}r}

sort$_A(\sigma_P(r))\equiv_A \sigma_P^{op}(\mbox{sort}_A(r))$
    &  \\

sort$_A(r[f(r)]) \equiv_A r[f^\prime(r)]$
    & $f^\prime(r) =f(r)\{v\leftarrow v[\mbox{Sortindex}_A(r)]\}$ for all 
$v \in f^{op}$, if f is tuple-local

\end{tabular*}
\caption{\label{tab:seltrans} Selection logical equivalences}
\end{table}


The first equivalence states that sort can be pushed down a
regular (non-order-dependent) selection by transforming the
latter into an order-preserving operation.
The second equivalence pushes a sort down over an indexing operation
under an assumption about that indexing operation.
Suppose that $f(r)$ is a {\em tuple-local} operation.
That is, there exists a function $g$ such that 
for all permutations $p$ of $r$ 
$f(v_1[p],v_2[p],\cdots,v_n[p])$ = {\em Alberto: I want to 
say something like $<g(v_1[p[i]], v_2[p[i]],\cdots,v_n[p[i]]>$
such that i ranges from 0 to |p|-1>; that is the same g
works for all permutations} 
%That is, it is of the form $f(v_1[p],v_2[p],\cdots,v_n[p])$
%where $v_i$ are columns of $r$ and $p$ is any permutation of
%its tuples.
The equivalence states that sorting an arrable that
is indexed by a function $f$ gives the same result as indexing
$r$ by the sorted result of $f$.

{\em Alberto: in general, we should present only the subset of
transformations that we in fact use in our examples.
We can say that we will produce a list of all of them
on a web site.}

\subsubsection{Projection}
\label{subsubsec:proj}

Projection in AQuery basically takes two forms:
one over attributes, and one over functions over attributes.
The distinction is important because in the latter case,
the functions may embody implicit selection functions as
example 4 shows.
Such implicit selection functions have transformations
of their own, detailed in section \ref{subsubsec:expr}.


\begin{table}[h]
\begin{tabular*}{4.75 in}{l@{\extracolsep{\fill}}r}

sort$_A(\pi_A(r)) \equiv_A \pi_A^{op}(\mbox{sort}_A(r))$
    &  \\

sort$_A(\pi_{f_1,\cdots,f_n}(r))\equiv_A 
\pi_{f_1^{op},\cdots,f_n^{op}}(\mbox{sort}_A(r))$
    & if $A \subseteq f_1^{op},\cdots,f_n^{op}$

\end{tabular*}
\caption{\label{tab:projtrans} Projection logical equivalences}
\end{table}

Pushing down sort over projection is possible in both cases.
In simple projection, the operation itself takes its
order-preserving variation.
Sort can also be pushed past order-preserving functions.


\subsubsection{Cartesian Product and Join}
\label{subsubsec:cartjoin}

Cartesian product in AQuery is considered order-oblivious.
Joins, on the other hand, may have several variations.
A {\em left-hand side order-preserving} join, {\em ljoin},
is one that has the following property.
if $r = r_1 \Join ^{l-op} r_2$, $i<j$,
$x = \pi_{Att(r_1)}(r)[i]$,
$y = \pi_{Att(r_1)}(r)[j]$,
then the index of $x$ in $r_1$ is less than the index
of $y$ in $r_1$.
{\em Alberto: please put the word "and" in the right place
above here. Also, it would be nice if the condition were
stated in the form that if x comes before y in r1 then
something about r. As it stands, I'm not sure it is true
since  x and y could be the same tuple.
Please rethink what follows here in the same way.}
A {\em left-right order-preserving} join, {\em lrjoin},
is one that has additionally the following property.
If $r = r_1 \Join^{lr-op} r_2$, $i<j$,
$x_1 = \pi_{Att(r_1)}(r)[i]$,
$x_2 = \pi_{Att(r_2)}(r)[i]$
$y_1 = \pi_{Att(r_1)}(r)[j]$,
$y_2 = \pi_{Att(r_2)}(r)[j]$,
$x_1 = y_1$,
then the index of $x_2$ in $r_2$ is less than the index
of $y_2$ in $r_2$.
Note that $\Join$ is commutative,  but $\Join^{lop}$ and
$\Join^{lrop}$ are not.
Associativity exists between pairs of $\Join$'s or pairs of
$\Join^{lop}$.
Table \ref{tab:jointrans} shows the join equivalences.

\begin{table}[h]
\begin{tabular*}{4.75 in}{l@{\extracolsep{\fill}}r}

sort$_A(r_1 \Join r_2) \equiv_A \mbox{sort}_A(r_1) \Join^{lop} r_2$
    & if $A \subseteq Att(r_1)$ \\

sort$_{A\bullet B}(r_1 \Join r_2)\equiv_{A\bullet B}\mbox{sort}_A(r_1) 
\Join^{lop} r_2$
    & if $A \subseteq Att(r_1)$,$B \subseteq Att(r_2)$ \\
    \multicolumn{2}{r}{$|\mbox{Dupelim}(\pi_B(r_2))| = 1$} \\

sort$_{A\bullet B}(r_1 \Join r_2)\equiv_{A\bullet B}\mbox{sort}_A(r_1) 
\Join^{lrop}\mbox{ sort}_B(r_2)$
    &if $A \subseteq Att(r_1)$,$B \subseteq Att(r_2)$ \\

\end{tabular*}

\vspace{0.2in}

\begin{tabular*}{4.75 in}{l@{\extracolsep{\fill}}r}

$\sigma_{P^{od}}(r_1 \Join^{lop} r_2) \equiv_{\mbox{Order}(r_1)} 
(\sigma_{P^{od}}(r_1) \Join^{lop} r_2)$
    & if $\mathcal{V}_P \subseteq$ Att$(r_1)$

\end{tabular*}
\caption{\label{tab:jointrans} Join logical equivalences}
\end{table}


The first rule shows that sort can be pushed down over
a join, at the expense of transforming it into a ljoin.
That can be done only if all the attributes
being sorted on belongs to the left-side arrable.
The second rule takes advantage of the fact the sorting
$r_2$ is irrelevant to make a similar transformation, and
tries to reduce the number of sorting attribute at the same
time.
The third transformations splits the join in two,
and pushes each one down one side of the join.
That requires the prefix (suffix) of the list of
attributes being sorted on belong to the left (right, respectively)
arrable.
{\em Alberto: let's discuss this last one sometime.
Again, if we don't use it, then let's not mention it.}

\noindent {\bf Dennis:} the last transformation is not always true.
We've recently found cases where by pushing a sigma
down a join, a group by would be created.


\subsubsection{Duplicate Elimination}
\label{subsubsection:dupelim}


\begin{tabular*}{4.25 in}{l@{\extracolsep{\fill}}r}

sort$_A(\mbox{Dupelim}(r)) \equiv_A \mbox{Dupelim}^{op}(\mbox{sort}_A(r))$

\end{tabular*}

{\em Alberto: dupelim one may be too simple to mention}

\subsubsection{Grouping}
\label{subsubsec:group}

Grouping and aggregation are disassociated operations
in AQuery.
Grouping partitions
the operand into groups of arrays of tuples according to a grouping
expression, preserving the order of the tuples in the original
tables.
It then transforms each group into a single tuple by projecting
each column into a single, array-typed value.
Aggregating is merely function application over each of those arrays.


\begin{figure}[h]
\center{
\begin{tabular}{ccc}

\begin{tabular}{r|cc}
$r$ & $a_1$ & $a_2$  \\ \hline
     &   a   &   3    \\
     &   b   &   2    \\
     &   b   &   1    \\
     &   a   &   1
\end{tabular}

& $\stackrel{\mbox{Gby}_{a_1}}{\Rightarrow}$ &

\begin{tabular}{r|cc}
     & $a_1$   & $a_2$   \\ \hline
     & a & $<3,1>$ \\
     & b & $<2,1>$
\end{tabular}  \\ %%end first line

$\stackrel{\mbox{sort$_{a_2}$}}{\Downarrow}$ & & 
$\stackrel{\mbox{sort-each$_{a_2}$}}{\Downarrow}$ \\ %%end second line

\begin{tabular}{r|cc}
     & $a_1$ & $a_2$ \\ \hline
     &   b   &   1   \\
     &   a   &   1   \\
     &   b   &   2   \\
     &   a   &   3
\end{tabular}

& $\stackrel{\mbox{Gby}_{a_1}}{\Rightarrow} $ &

\begin{tabular}{c}

\begin{tabular}{r|cc}
     & $a_1$   & $a_2$   \\ \hline
     & a & $<1,3>$ \\
     & b & $<1,2>$
\end{tabular}  \\

$\not\equiv$ \\

\begin{tabular}{r|cc}
     & $a_1$   & $a_2$   \\ \hline
     & b & $<1,2>$ \\
     & a & $<1,3>$
\end{tabular}

\end{tabular}

\end{tabular}
\caption{\label{fig:gbyexample} Example why sort can't always be pushed
down over group-by}
}
\end{figure}


Sorting may not commute
with  Group-by.
For instance, figure \ref{fig:gbyexample} shows one example
in which sort-each$_{a_2}(\mbox{Gby}_{a_1}(r)) \not\equiv
\mbox{Gby}_{a_1}(\mbox{sort}_{a_2}(r))$.
Some specific, but useful properties are listed in table \ref{tab:gbytrans}.


\begin{table}[h]
\begin{tabular*}{4.75 in}{l@{\extracolsep{\fill}}r}

sort-each$_B(\mbox{Gby}_A(r)) \equiv_{\{\}} \mbox{Gby}_{A}(\mbox{sort}_B(r)$
    & \\

sort-each$_B(\mbox{Gby}_A^{op}(r)) \equiv_{\mbox{Order}(r_1)} 
\mbox{Gby}_A^{op}(r)$
   & if $B$ is a prefix of Order$(r)$

\end{tabular*}
\caption{\label{tab:gbytrans} Group-by logical equivalences}
\end{table}


The first transformation says that commuting sort
and group by results in two multi-set equivalent arrables.
In practice that's useful whenever one is interested in
the order existing within array fields as opposed to the
order of the groups.
The second equivalence uses an order-preserving group-by
to take advantage of an existing sort order.


\subsubsection{Flattening}
\label{subsubsec:flat}

Flatten is inherently order-preserving.
Here again intuition can be misleading.
Figure \ref{fig:flatexample} shows why sort$_A($flatten$(r))\not\equiv_A$
flatten$($sort-each$_A(r))$.
Note, also, that if Order$(r)=B$,
then flatten$($Gby$_A(r)) \not\equiv_B r$;
flatten after a Gby becomes order-oblivious.
If Gby were order-generating, then the situation would
be different:
flatten$($Gby$_A(r)) \equiv_{A\bullet B}$ sort$_A(r)$.

{\em Alberto: instead of using lots of space for these
non-equivalences, should we make sure the reader understands 
what flatten does.}


\begin{figure}[h]
\center{
\begin{tabular}{ccc}

\begin{tabular}{r|cc}
      $r$       & $a_1$     & $a_2$     \\ \hline
                & $<7,5>$   & $<a,b>$   \\
                & $1$       & $c$
\end{tabular}

& $\stackrel{\mbox{sort-each}_{a_1}}{\Rightarrow}$ &

\begin{tabular}{r|cc}
                & $a_1$     & $a_2$     \\ \hline
                & $<5,7>$   & $<b,s>$   \\
                & $1$       & $c$
\end{tabular}  \\ %%end first line

$\stackrel{\mbox{flatten}}{\Downarrow}$ & & 
$\stackrel{\mbox{flatten}}{\Downarrow}$ \\ %%end second line

\begin{tabular}{r|cc}
                 & $a_1$ & $a_2$ \\ \hline
                 &   7   &   a   \\
                 &   5   &   b   \\
                 &   1   &   c
\end{tabular}

& $\stackrel{\mbox{sort}_{a_1}}{\Rightarrow} $ &

\begin{tabular}{c}

\begin{tabular}{r|cc}
                 & $a_1$ & $a_2$ \\ \hline
                 &   5   &   b   \\
                 &   7   &   a   \\
                 &   1   &   c   \\
\end{tabular} \\

$\not\equiv$ \\

\begin{tabular}{r|cc}
                 & $a_1$ & $a_2$ \\ \hline
                 &   1   &   c   \\
                 &   5   &   b   \\
                 &   7   &   a
\end{tabular}

\end{tabular}

\end{tabular}
\caption{\label{fig:flatexample} Example why sort can't always be pushed
down over flatten}
}
\end{figure}

Flatten yields some useful transformations however as table \ref{tab:flattrans}
shows.


\begin{table}[h]
\begin{tabular*}{4.75 in}{l@{\extracolsep{\fill}}r}

flatten$(\mbox{Gby}_A(r) \equiv_{\{\}} r$
    & \\

flatten$($Gby$_A^{op}(r)) \equiv_{A\bullet B} r$
    & if Order$(r) = A\bullet B$

\end{tabular*}
\caption{\label{tab:flattrans} Flatten logical equivalences}
\end{table}

The first equivalence states that flatten is the inverse of
group by, but the result in terms of order is unpredictable.
In the specific case where one is grouping over a
prefix of Order($r$), a flatten and
grouping still maintain the order existing before.


\subsubsection{Expression Manipulation}
\label{subsubsec:expr}

%Expression manipulation is particularly important in AQuery
%because it can carry implicit selections.
%If array indexing is used in a way that reduces the
%cardinality of the expression it is indexing (as opposed to
%just reorganizing it) then that subscripting may be
%separated from the main expression in some cases.
%(In section \ref{subsec:logtophys} we will show how to take
%advantage of such a selection to reduce cardinality as
%early as possible.)

A frequent kind of query on ordered data requires knowledge
of only the ``edges'' of the data, e.g., the earliest, the latest,
the top, or the bottom.
Transformations that push selections past these functions can
reduce cost substantially. 
For example, consider finding the running average of the 
earliest 1000 sales.
Clearly the best way to do this is to find the earliest
sales values and computing the runing average on them, as opposed
to computing the running average on all sales values and then
cutting off that average on the first 1000.
Formally,
let $i$ be a valid array of indexes into a function $f$ that
maps a list of arrays into an array,
and let $f$ be prefix-dependent.
$f(v_1,v_2,\cdots,v_n) = u$ is {\em prefix-dependent} if
$|v_1|=\cdots=|v_n|=|u|$; and for every $i$, $0 \leq i \leq |u|-1$,
$u[0..i]=f(v_1[0..i],v_2[0..i],\cdots,v_n[0..i])$.
Now, consider the transformations in table \ref{tab:exprtrans}.


\begin{table}[h]
\begin{tabular*}{4.75 in}{l@{\extracolsep{\fill}}r}

$f^{pd}[i] \equiv f^{pd}\{v_j \leftarrow v_j[0..\vert i\vert]\}$
    & $1 \leq j \leq n$ \\
    & if $f^{pd}$ is a prefix-dependent function

\end{tabular*}
\caption{\label{tab:exprtrans} Expression manipulation logical equivalences}
\end{table}


\subsubsection{WITH Query-Block Merging}
\label{subsubsec:WITH}

{\bf Dennis:} Now that I think of it, the transformation
suggested here seems particularly cryptic.
I left the text here, just a reminder.
And also because I think we should address block merging somehow, as
it would be present in a considerable percentage of queries.

{\em Alberto: fine. We should get together to discuss I think.}


The WITH clause defines a list of named query-expressions
each of which can only be used in the FROM clause, be it of
the main query's or of a subsequent named query-expression's.
Correlation is not allowed between the main and the WITH
query.
Thus, the WITH sub-query can be
treated as a sub-expression on the main query.

The join used to refer to the WITH-block
can sometimes be commuted by a flatten.
(Example 2 illustrate the use of this rule.)

\begin{tabular*}{4.25 in}{l@{\extracolsep{\fill}}r}

$\pi_{f_1,\cdots,f_n}(\mbox{Gby}_A(r))\Join^{l-op}_{A=A} r \equiv_{A\bullet 
\mbox{Order}(r)} \mbox{flatten}(\pi_{*,f_1,\cdots,f_n}(\mbox{Gby}_A(r)))$
\end{tabular*}


\subsection{Logical to Physical Operators and Algorithms}
\label{subsec:logtophys}

\noindent{\bf Dennis:} This section still needs some thinking.
What I had in mind here is that we have some non trivial
implementation rules, e.g., the subsection below.
In addition, I think we should mention alternative implementations
of joins and sorts.
In any case, here are some notes.

{\em Alberto: ok, but this should come immediately after the
expression transformation involving prefix-dependent functions.
It's too rough for me to edit at this point.}

\subsubsection{Combining stopping expressions with other operations.}
\label{subsubsec:stopalgs}
Edgeby is a smart implementation of the logical pattern
"each(select-edge-condition) + group by." Note that the selection
"select-edge-condition" may appear before other operators than group by,
inspiring new implementations.

For instance, take the query
SELECT avg(first(10,salary))
FROM Emp ASSUMING salary
and suppose
Emp(ID, salary,...) ORDER BY ID

Here's a (sideways, right-to-left) plan
$\pi_{avg(salary)} \leftarrow \sigma_{rowid = first(10)}
\leftarrow sort(salary) \leftarrow Emp$

Here there would be no need to sort all Emp, but merely
find the top 10. That is, there is a more efficient way to
carry $\sigma_{rowid = first(10)} \leftarrow sort(salary)$
in just one step.

\subsubsection{Joins}
\label{subsubsec:joinalgs}
Join PK-FK positional is extremely fast.

\subsubsection{Sorts}
\label{subsubsec:sortsalgs}
Relatively order preserving sort.


\subsection{Examples}
\label{subsec:examples}

{\bf Dennis:} There is still some work to do in this
section too.
About example 2, it has to be completed.


\noindent {\bf Example 1.}
This simple example illustrates some 
strengths of AQuery's optimization process.
Suppose one wants to retrieve the last quote of a
given company.
The query is shown below and its optimization is fully
depicted in figure \ref{fig:plan2}.


{\small
{\sf
\begin{tabbing}
xxxxxxxxx\= \kill
SELECT last(price) \\
FROM \>Ticks JOIN Base ON ticks.ID=base.ID \\
      \>ASSUMING ORDER name, timestamp \\
WHERE \>name = ``...''
\end{tabbing}
}
}


The strategy to optimize this query is to do
early sorting.
The optimizer makes that decision because the {\sf ASSUMING}
order matches one arrable's original
order.
Plan (a) shows the query the way the parser generated it.
The selection on name is then pushed down as shown in (b)
and (c) with the appropriate transformations rules.
At this point, the sort may be pushed down.
In (d) it was moved over the join, making it become
an ljoin.
As Tick's order matches the desired one, that sort can
be eliminated.
In plan (e), the optimizer separates the implicit selection
clause from the projection.
The new selection can then be pushed down the join, as
(f) suggests.
That transformation generates a whole new set of operators
on the left side of the join and entails an additional selection
after the join. 
The plan's last logical stage is shown in (g)
%\footnote{In practice,
%AQuery's optimizer does not work
%with such a logical and physical transformation separation.
%Actually, a physical plan is generated as soon and as fast
%as possible, in order to have it's costs as an upper bound for
%any future plan being considered.}.
The physical plan is shown in (h).


\begin{figure}[hbtp]
\center{\epsfig{figure=plan2.eps}}
\caption{\label{fig:plan2}
This figure shows the several steps of optimization of
a query that returns the latest stock quote of a
security given its name.
Double arcs connecting operators mean that the stream
of tuples between them is ordered.
The plan shown in (a) comes directly from the query as written.
At each step, the box indicates where the next transformation
is going to act.
}
\end{figure}


\noindent {\bf Example 2.}
Here we show how lazy sorting can be advantageous.
In this query, one wants to know which stocks
opened with a steady increase in prices and at
which date.
Assume that a steady increase is characterized by
ten consecutive price risings.
The query is shown below.

{\small
{\sf
\begin{tabbing}
xxxxxxxxx\= \kill
SELECT ID, date \\
FROM \>ticks JOIN base ON ticks.ID=base.ID \\
      \>ASSUMING ORDER timestamp \\
WHERE \>industry = ``...'' \\
GROUP \>BY ID, date \\
HAVING \>prd(deltas(price[!10])) $>$ 0
\end{tabbing}
}
}


{\bf Dennis:} I need to work on the following comments.
Suppose that the arrables in the query are not
sorted in a suitable way.
{\em Alberto: the reasonable assumption here is that ticks
is sorted based on timestamp. Maybe this example can be about
taking advantae of that assumption and the fact that 
deltas and prd are both prefix-dependent}
The transformations can be used to postpone sorting
in the following way.


\begin{figure}[hbtp]
\center{\epsfig{figure=plan3.eps}}
\caption{\label{fig:plan3}
Caption goes here
}
\end{figure}



%%===========================
\section{Experimental Results}
\label{sec:exprs}


\subsection{Implementation Aspects}
\label{subsec:implem}

Complete here: Say that we decided to work on a main-memory DB and
justify with motivations.
{\em Alberto: Do we have to limit ourselves to main memory
or is this simply more convenient for experiments.
I would prefer the latter, since time series databases may well
be big.}


{\em Alberto: I haven't edited this part.}
AQuery's vector flavor makes it particular suitable
for this kind of implementation.
As variables are bound to entire vectors, and
not to values, we can abandon the iterator model in
favor of a vector-processing one.
That carries tremendous performance advantages in
the considered scenario>
First, we drastically reduce the number of function
calls to operators, as we call them only once to process
an entire vector, and not once for each tuple.
Second, most operators traverse its vector operands
with a high locality of reference, which privileges
Level 1 and Level 2 caches hits.
Finally, during the traverse the main loop's branch
fails only once and at the end.
It is thus expected that AQuery plans have a highly
efficient degree of CPU consumption.

Description of machine type, memory amount and other
relevant parameters go here.


\subsection{Performance measurements}
\label{subsec:perfmeas}

{\bf Dennis:} I still have to update this section to
reflect the changes made in the paper.
So far, it is still in its originally proposed format.

\begin{itemize}
\setlength{\parsep}{0 in}
\setlength{\itemsep}{0 in}

\item Hypothesis 1: The cost difference between optimized and
non-optimized queries is non negligible.
Proof: Run different plans for a same query and time
the execution time.

\item Hypothesis 2: AQuery structural simplicity foster finding
better plans.
Proof: Run a SQL:1999 query using a plan generated by
product X.
Compare with AQuery's counterpart.

\item Hypothesis 3: The transformations are cost-dependent.
Proof: Pick scenarios where a same transformation help
and hinders improving costs.

\end{itemize}
{\em Alberto: I like these points.
I would call them Observations rather than Hypotheses.}


%%===========================
\section{A Search Strategy}
\label{sec:search}


Making order a logical property vastly increases
the size of the optimization search space. 
Intuitively, for every unary operator that has
non- and order-preserving variations, sorting
may be done before or after.
The situation is worse for joins, where the optimizer
must consider variations
that preserves either input stream's order or
combines them in one. {\em Alberto: I don't understand the last phrase.
Please rewrite.}
Fortunately, heuristics can
shrink the size of the search space. 

The reason is that our strategy works in steps.
First, the optimizer identifies
any "select-edge" conditions.
The parsing
phase can do this.


{\em Alberto: the following is too raw for me to edit.}
The next step is to use a different set of rules to try to move
selections  closer -- ideally adjacent to  -- operations with
which it can form efficiently implementable patterns (e.g. group
by and perhaps sort).
That is obtained by returning very high values for the
promise() function, the one that ranks and ultimately influences
the choice of transformation whenever more than one is possible,
of the desired transformations.


The final step uses a set rich in implementation rules that,
again driven by the promise() rankings and the cost model, picks
the implementations that are able to take advantage the query
shape to process the least number of tuples possible.


%%===========================
\section{Related Work}
\label{sec:relwork}

Whereas SQL:99 is the commercially most significant implementation
of ordered queries,
other systems, both commercial and research, have proposed
many excellent ideas.

\subsection{Languages}
\label{subsec:lang}


AQuery is a direct descendent of 
KX systems's KSQL.
In particular, AQuery takes its arrable
notion -- a fully vertically partitioned implementation
of tables, each of whose columns is an array -- from KSQL\cite{Kxx}.
AQuery differs from KSQL by trying to preserve SQL:92 syntax
whenever possible and using cost-based optimization. 


The sequence query languages SEQUIN \cite{SLR96} and
SRQL \cite{RDR+98} are precursors of SQL:1999.
SEQUIN treats sequences as an extended abstract data type,
although a sequence can serve as the sole source of data
for a query.
Whenever used as a column data type, a
query may have to mix SEQUIN and SQL to specify a full
predicate.
SRQL treats tables as ordered
relations.
However, it supports neither vectors nor sequences
as a column's data type.
{\em Alberto: you are going to need to say more here}


$<$Comment on RasDaMan as a variation of SQL with
subscripting$>$.


Non-SQL efforts at query languages that incorporate
underlying ordered structures are AML \cite{MS97} and
AQL \cite{LMW96}.
AML is algebraic and its main mechanisms are function application 
as well as
sub-slabbing and merging arrays.
AQL's expressive power is based on
comprehensions and treats arrays as functions.
{\em Alberto: can we say something nice, e.g. they've
offered nice optimization techniques?}


\subsection{Optimization Techniques}
\label{subsec:optech}

IBM folks use the concept of ``glue'' in Starburst
to generate additional plans that contemplate 
``interesting orders'' \cite{Loh88}.
Similarly, Volcano uses ``enforcers'' \cite{GM93}.
These mechanisms exist because order is considered
to be a physical property that does not correspond to
any logical level operator.

Early sorting and redundant sort elimination was
studied in \cite{SSM96} in the context of DB2.
That work treats order in a separate
step before plan enumeration starts.
We use a somewhat similar technique but we treat sort
as part of
the enumeration process.
Moreover, in \cite{SSM96} {\em order requirements}
arise only from the ORDER BY clause.

As mentioned early, some of the transformations
used here were described previously in \cite{SJS01}.
$<$Describe in what they differ$>$.


%%===========================
\section{Conclusion}
\label{sec:conclusion}

Conclusion goes here.


%%===========================
\begin{thebibliography}{11}


\bibitem{CK97}
Michael J. Carey and Donald Kossmann.
``On Saying `Enough Already!' in SQL''
In {\em  Proceedings 1997 ACM SIGMOD International
Conference on Management of Data}, 219-230,
Tucson, Arizona, 1997.


\bibitem{GM93}
Goetz Graefe and William J. McKenna.
``The Volcano Optimizer Generator: Extensibility and
Efficient Search.''
In {\em Proceeding of the International Conference on
Data Engineering}, 209--218, Viena, Austria, 1993.


\bibitem{CKK+00}
Jens Claussen, Alfons Kemper, Donald Kossmann,
and Christian Wiesner.
``Exploiting early sorting and early partitioning for
decision support query processing.''
VLDB Journal, 9(3): 190-213, 2000.


\bibitem{Kxx}
KX Systems.
KSQL Reference Manual, Version 2.0


\bibitem{LMW96}
Leonid Libkin,  Rona Machlin, and Limsoon Wong.
A Query Language for Multidimensional Arrays: Design,
Implementation, and Optimization Techniques.
In {\em Proceedings of the 1996 ACM SIGMOD International
Conference on Management of Data}, 228--239,
Quebec, Canada, June, 1996.


\bibitem{Loh88}
Guy M. Lohman.
``Grammar-like Functional Rules for Representing
Query Optimization Alternatives.''
In {\em Proceeding of the SIGMOD International Conference
on Management of Data}, 18-27, Chicago, Illinois, 1988.


\bibitem{MS97}
Arunprasad P. Marathe and Kenneth Salem.
A Language for Manipulating Arrays.
In {\em Proceedings of 23rd International Conference on Very
Large Data Bases}, 46--55, Athens, Greece, August, 1997.


\bibitem{RDR+98}
Raghu Ramakrishnan, Donko Donjerkovic, Arvind Ranganathan,
Kevin S. Beyer, and Muralidhar Krishnaprasad.
SRQL: Sorted Relational Query Language.
In  {\em 10th International Conference on Scientific and
Statistical Database Management}, 84--95, Capri, Italy, July, 1998.


\bibitem{SJS01}
Geidrius Slivinskas, Christian S. Jensen, and
Richard T. Snodgrass.
``A Foundation for Conventional and Temporal Query
Optimization Addressing Duplicates and Order.''
{\em IEEE Transactions on Knowledge and Data Engineering},
13(1):21--49, January/February, 2001.


\bibitem{SLR96}
Praveen Seshadri, Miron Livny, and Raghu Ramakrishnan.
The Design and Implementation of a Sequence Database System.
In {\em Proceedings of 22th International Conference on Very
Large Data Bases}, 99--110, September, 1996, Mumbai (Bombay),
India.


\bibitem{SSM96}
David E. Simmen, Eugene J. Shekita, Timothy Malkemus.
``Fundamental Techniques for Order Optimization.''
In {\em Internation Conference on Extending Database
Technology}, 625--628, Avignon, France, 1996.


\end{thebibliography}


\end{document}

--=====================_456135==_
Content-Type: application/octet-stream; name="plan2.fig"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="plan2.fig"

I0ZJRyAzLjIKTGFuZHNjYXBlCkNlbnRlcgpJbmNoZXMKTGV0dGVyICAKMTAwLjAwClNpbmdsZQot
MgoxMjAwIDIKNiA3NTAgMzAwIDkwMCA1MjUKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAg
LTEgMCAwIDIKCSA4NDUgNTAwIDg0NSAzNTAKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAg
LTEgMCAwIDIKCSA4MDUgNTAwIDgwNSAzNTAKLTYKNiA3NTAgNjc1IDkwMCA5MDAKMiAxIDAgMSAw
IDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSA4NDUgODc1IDg0NSA3MjUKMiAxIDAgMSAw
IDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSA4MDUgODc1IDgwNSA3MjUKLTYKNiAyNzAw
IDMwMCAyODUwIDUyNQoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDI3
OTUgNTAwIDI3OTUgMzUwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkg
Mjc1NSA1MDAgMjc1NSAzNTAKLTYKNiA0NzI1IDMwMCA0ODc1IDUyNQoyIDEgMCAxIDAgNyA1MCAw
IC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDQ4MjAgNTAwIDQ4MjAgMzUwCjIgMSAwIDEgMCA3IDUw
IDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgNDc4MCA1MDAgNDc4MCAzNTAKLTYKNiA3NTAgMTg3
NSA0ODc1IDIxMDAKNCAxIDAgNTAgMCAwIDggMC4wMDAwIDQgMTA1IDEzNSA4MjUgMjAyNSAoYSlc
MDAxCjQgMSAwIDUwIDAgMCA4IDAuMDAwMCA0IDEwNSAxNTAgNDgwMCAyMDI1IChjKVwwMDEKNCAx
IDAgNTAgMCAwIDggMC4wMDAwIDQgMTA1IDE1MCAyNzc1IDIwMjUgKGIpXDAwMQotNgo2IDAgMjQw
MCA1Nzc1IDQ1NzUKNiA2NzUgMjU1MCA4MjUgMjc3NQoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAw
IDAgMCAtMSAwIDAgMgoJIDc3MCAyNzUwIDc3MCAyNjAwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4w
MDAgMCAwIC0xIDAgMCAyCgkgNzMwIDI3NTAgNzMwIDI2MDAKLTYKNiAzMDAgMjkyNSA2NzUgMzA3
NQoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDM3NSAzMDc1IDY3NSAy
OTI1CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgMzEwIDMwNzUgNjEw
IDI5MjUKLTYKNiAyMTc1IDMwMDAgMjU1MCAzMTUwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAg
MCAwIC0xIDAgMCAyCgkgMjI1MCAzMTUwIDI1NTAgMzAwMAoyIDEgMCAxIDAgNyA1MCAwIC0xIDAu
MDAwIDAgMCAtMSAwIDAgMgoJIDIxODUgMzE1MCAyNDg1IDMwMDAKLTYKNiAyNTUwIDI2MjUgMjcw
MCAyODUwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgMjY0NSAyODI1
IDI2NDUgMjY3NQoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDI2MDUg
MjgyNSAyNjA1IDI2NzUKLTYKNiA0NTAwIDI2MjUgNDY1MCAyODUwCjIgMSAwIDEgMCA3IDUwIDAg
LTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgNDU5NSAyODI1IDQ1OTUgMjY3NQoyIDEgMCAxIDAgNyA1
MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDQ1NTUgMjgyNSA0NTU1IDI2NzUKLTYKNiA0NTAw
IDMwMDAgNDY1MCAzMjI1CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkg
NDU5NSAzMjAwIDQ1OTUgMzA1MAoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAg
MgoJIDQ1NTUgMzIwMCA0NTU1IDMwNTAKLTYKNiA0MTI1IDMzNzUgNDUwMCAzNTI1CjIgMSAwIDEg
MCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgNDIwMCAzNTI1IDQ1MDAgMzM3NQoyIDEg
MCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDQxMzUgMzUyNSA0NDM1IDMzNzUK
LTYKNiA4MjUgNDI3NSA0ODAwIDQ1NzUKNCAxIDAgNTAgMCAwIDggMC4wMDAwIDQgMTA1IDE1MCAy
Nzc1IDQ1MDAgKGUpXDAwMQo0IDEgMCA1MCAwIDAgOCAwLjAwMDAgNCAxMDUgMTM1IDQ3MjUgNDUw
MCAoZilcMDAxCjQgMSAwIDUwIDAgMCA4IDAuMDAwMCA0IDEwNSAxNTAgOTAwIDQ0MjUgKGQpXDAw
MQotNgoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDEyNzUgMzA3NSAx
MTI1IDMwMDAKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDUKCSA2NzUgMjc3
NSA4MjUgMjg1MCA4MjUgMjc3NSA2NzUgMjg1MCA2NzUgMjc3NQoyIDEgMCAxIDAgNyA1MCAwIC0x
IDAuMDAwIDAgMCAtMSAwIDAgMgoJIDEyNzUgMzQyNSAxMjc1IDMyNzUKMiAxIDAgMSAwIDcgNTAg
MCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSAzMDAgMzQyNSAzMDAgMzI3NQoyIDIgMCAxIDAgNyA1
MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgNQoJIDAgMzA3NSA2MDAgMzA3NSA2MDAgMzY3NSAwIDM2
NzUgMCAzMDc1CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgMzE1MCAz
MTUwIDMwMDAgMzA3NQoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgNQoJIDI1
NTAgMjg1MCAyNzAwIDI5MjUgMjcwMCAyODUwIDI1NTAgMjkyNSAyNTUwIDI4NTAKMiAxIDAgMSAw
IDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSAzMTUwIDM1MDAgMzE1MCAzMzUwCjIgMiAw
IDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCA1CgkgMjMyNSAyNDc1IDM1MjUgMjQ3NSAz
NTI1IDMwNzUgMjMyNSAzMDc1IDIzMjUgMjQ3NQoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAg
MCAtMSAwIDAgMgoJIDUxMDAgMzUyNSA0OTUwIDM0NTAKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAw
MCAwIDAgLTEgMCAwIDUKCSA0NTAwIDMyMjUgNDY1MCAzMzAwIDQ2NTAgMzIyNSA0NTAwIDMzMDAg
NDUwMCAzMjI1CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgNTEwMCAz
ODc1IDUxMDAgMzcyNQoyIDIgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgNQoJIDQy
MDAgMjg1MCA1NDc1IDI4NTAgNTQ3NSAzNDUwIDQyMDAgMzQ1MCA0MjAwIDI4NTAKNCAwIDAgNTAg
MCAwIDggMC4wMDAwIDQgMTIwIDc2NSA4MjUgMjYyNSBjb2w9bGFzdChwcmljZSlcMDAxCjQgMSAw
IDUwIDAgMCAxMCAwLjAwMDAgNCAxMDUgMjU1IDEyNzUgMzYwMCBiYXNlXDAwMQo0IDEgMCA1MCAw
IDMyIDEyIDAuMDAwMCA0IDkwIDEyMCAxMjc1IDMyMjUgc1wwMDEKNCAwIDAgNTAgMCAwIDggMC4w
MDAwIDQgNzUgMzQ1IDkwMCAyOTI1IElEPUlEXDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCAx
MDUgMjEwIDkwMCAyNzc1IGwtb3BcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDc1IDU3MCAx
MzUwIDMzMDAgbmFtZSA9ICIuLi4iXDAwMQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgMTA1IDMw
MCAzMDAgMzYwMCB0aWNrc1wwMDEKNCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDkwIDI1NSAzMDAg
MzIyNSBzb3J0XDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCA3NSA5MCAzNzUgMzMwMCB0c1ww
MDEKNCAxIDAgNTAgMCAzMiAxMiAwLjAwMDAgNCA5MCAxMDUgMjYyNSAyNjI1IHBcMDAxCjQgMCAw
IDUwIDAgMCA4IDAuMDAwMCA0IDEyMCA3NjUgMjcwMCAyNzAwIGNvbD1sYXN0KHByaWNlKVwwMDEK
NCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDEwNSAyNTUgMzE1MCAzNjc1IGJhc2VcMDAxCjQgMSAw
IDUwIDAgMCAxMCAwLjAwMDAgNCAxMDUgMzAwIDIxNzUgMzMwMCB0aWNrc1wwMDEKNCAxIDAgNTAg
MCAzMiAxMiAwLjAwMDAgNCA5MCAxMjAgMzE1MCAzMzAwIHNcMDAxCjQgMCAwIDUwIDAgMCA4IDAu
MDAwMCA0IDc1IDM0NSAyNzc1IDMwMDAgSUQ9SURcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0
IDEwNSAyMTAgMjc3NSAyODUwIGwtb3BcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDc1IDU3
MCAzMjI1IDMzNzUgbmFtZSA9ICIuLi4iXDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAuMDAwMCA0IDkw
IDEwNSA0NTc1IDI2MjUgcFwwMDEKNCAwIDAgNTAgMCAwIDggMC4wMDAwIDQgMTIwIDI1NSA0NjUw
IDI3MDAgcHJpY2VcMDAxCjQgMSAwIDUwIDAgMCAxMCAwLjAwMDAgNCAxMDUgMjU1IDUxMDAgNDA1
MCBiYXNlXDAwMQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgMTA1IDMwMCA0MTI1IDM2NzUgdGlj
a3NcMDAxCjQgMSAwIDUwIDAgMzIgMTIgMC4wMDAwIDQgOTAgMTIwIDUxMDAgMzY3NSBzXDAwMQo0
IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCA3NSAzNDUgNDcyNSAzMzc1IElEPUlEXDAwMQo0IDAgMCA1
MCAwIDAgOCAwLjAwMDAgNCAxMDUgMjEwIDQ3MjUgMzIyNSBsLW9wXDAwMQo0IDAgMCA1MCAwIDAg
OCAwLjAwMDAgNCA3NSA1NzAgNTE3NSAzNzUwIG5hbWUgPSAiLi4uIlwwMDEKNCAwIDAgNTAgMCAw
IDggMC4wMDAwIDQgNzUgNzUwIDQ2NTAgMzA3NSBST1dJRCA9IGxhc3RcMDAxCjQgMSAwIDUwIDAg
MzIgMTIgMC4wMDAwIDQgOTAgMTIwIDQ1NzUgMzAwMCBzXDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAu
MDAwMCA0IDkwIDEwNSA3NTAgMjU1MCBwXDAwMQotNgo2IDc1MCA1MzI1IDkwMCA1NTUwCjIgMSAw
IDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgODQ1IDU1MjUgODQ1IDUzNzUKMiAx
IDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSA4MDUgNTUyNSA4MDUgNTM3NQot
Ngo2IDQ1MCA1NzAwIDgyNSA1ODUwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAg
MCAyCgkgNTI1IDU4NTAgODI1IDU3MDAKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEg
MCAwIDIKCSA0NjAgNTg1MCA3NjAgNTcwMAotNgoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAg
MCAtMSAwIDAgMgoJIDgyNSAxMTc1IDgyNSAxMDI1CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAg
MCAwIC0xIDAgMCAyCgkgNDUwIDE1MDAgNzUwIDEzNTAKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAw
MCAwIDAgLTEgMCAwIDIKCSAxMzUwIDE1MDAgMTIwMCAxNDI1CjIgMSAwIDEgMCA3IDUwIDAgLTEg
MC4wMDAgMCAwIC0xIDAgMCA1CgkgNzUwIDEyMDAgOTAwIDEyNzUgOTAwIDEyMDAgNzUwIDEyNzUg
NzUwIDEyMDAKMiAyIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDUKCSA2MDAgNTI1
IDE1NzUgNTI1IDE1NzUgMTEyNSA2MDAgMTEyNSA2MDAgNTI1CjIgMSAwIDEgMCA3IDUwIDAgLTEg
MC4wMDAgMCAwIC0xIDAgMCAyCgkgNDQyNSAxMjAwIDQ3MjUgMTA1MAoyIDEgMCAxIDAgNyA1MCAw
IC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDUzMjUgMTIwMCA1MTc1IDExMjUKMiAxIDAgMSAwIDcg
NTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDUKCSA0NzI1IDkwMCA0ODc1IDk3NSA0ODc1IDkwMCA0
NzI1IDk3NSA0NzI1IDkwMAoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJ
IDQ4MDAgODc1IDQ4MDAgNzI1CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAy
CgkgNTMyNSAxNTUwIDUzMjUgMTQwMAoyIDIgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAw
IDAgNQoJIDQ1NzUgNTI1IDUzMjUgNTI1IDUzMjUgMTEyNSA0NTc1IDExMjUgNDU3NSA1MjUKMiAx
IDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSAyNDAwIDE1MDAgMjcwMCAxMzUw
CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgMzMwMCAxNTAwIDMxNTAg
MTQyNQoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgNQoJIDI3MDAgMTIwMCAy
ODUwIDEyNzUgMjg1MCAxMjAwIDI3MDAgMTI3NSAyNzAwIDEyMDAKMiAyIDAgMSAwIDcgNTAgMCAt
MSAwLjAwMCAwIDAgLTEgMCAwIDUKCSAyNTUwIDg1MCAzNDUwIDg1MCAzNDUwIDE0MjUgMjU1MCAx
NDI1IDI1NTAgODUwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgMjc3
NSA4NzUgMjc3NSA3MjUKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSAy
Nzc1IDExNzUgMjc3NSAxMDI1CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAy
CgkgMTM1MCA1ODUwIDEyMDAgNTc3NQoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAw
IDAgNQoJIDc1MCA1NTUwIDkwMCA1NjI1IDkwMCA1NTUwIDc1MCA1NjI1IDc1MCA1NTUwCjIgMSAw
IDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgMTM1MCA2MjAwIDEzNTAgNjA1MAoy
IDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDQ1MCA2MjAwIDQ1MCA2MDUw
CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgODI1IDUxNTAgODI1IDUw
MDAKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSA0NTAgNjU3NSA0NTAg
NjQyNQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgMTA1IDMwMCAzNzUgMTY1MCB0aWNrc1wwMDEK
NCAxIDAgNTAgMCAzMiAxMiAwLjAwMDAgNCA5MCAxMjAgODI1IDY3NSBzXDAwMQo0IDEgMCA1MCAw
IDAgMTAgMC4wMDAwIDQgMTA1IDI1NSAxNDI1IDE2NTAgYmFzZVwwMDEKNCAwIDAgNTAgMCAwIDgg
MC4wMDAwIDQgNzUgMzQ1IDk3NSAxMzUwIElEPUlEXDAwMQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAw
IDQgOTAgMjU1IDgyNSA5NzUgc29ydFwwMDEKNCAwIDAgNTAgMCAwIDggMC4wMDAwIDQgNzUgNTcw
IDkwMCA3NTAgbmFtZSA9ICIuLi4iXDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAuMDAwMCA0IDkwIDEw
NSA4MjUgMzAwIHBcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDEyMCA3NjUgOTAwIDM3NSBj
b2w9bGFzdChwcmljZSlcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDkwIDM3NSA5MDAgMTA1
MCBuYW1lLHRzXDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAuMDAwMCA0IDkwIDEwNSA0ODAwIDMwMCBw
XDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCAxMjAgNzY1IDQ4NzUgMzc1IGNvbD1sYXN0KHBy
aWNlKVwwMDEKNCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDEwNSAzMDAgNDM1MCAxMzUwIHRpY2tz
XDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCA3NSAzNDUgNDk1MCAxMDUwIElEPUlEXDAwMQo0
IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgOTAgMjU1IDQ4MDAgNjc1IHNvcnRcMDAxCjQgMCAwIDUw
IDAgMCA4IDAuMDAwMCA0IDkwIDM3NSA0ODc1IDc1MCBuYW1lLHRzXDAwMQo0IDEgMCA1MCAwIDAg
MTAgMC4wMDAwIDQgMTA1IDI1NSA1MzI1IDE3MjUgYmFzZVwwMDEKNCAxIDAgNTAgMCAzMiAxMiAw
LjAwMDAgNCA5MCAxMjAgNTMyNSAxMzUwIHNcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDc1
IDU3MCA1NDAwIDE0MjUgbmFtZSA9ICIuLi4iXDAwMQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQg
MTA1IDMwMCAyMzI1IDE2NTAgdGlja3NcMDAxCjQgMSAwIDUwIDAgMCAxMCAwLjAwMDAgNCAxMDUg
MjU1IDMzNzUgMTY1MCBiYXNlXDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCA3NSAzNDUgMjky
NSAxMzUwIElEPUlEXDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAuMDAwMCA0IDkwIDEwNSAyNzc1IDMw
MCBwXDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCAxMjAgNzY1IDI4NTAgMzc1IGNvbD1sYXN0
KHByaWNlKVwwMDEKNCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDkwIDI1NSAyNzc1IDY3NSBzb3J0
XDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCA5MCAzNzUgMjg1MCA3NTAgbmFtZSx0c1wwMDEK
NCAxIDAgNTAgMCAzMiAxMiAwLjAwMDAgNCA5MCAxMjAgMjc3NSA5NzUgc1wwMDEKNCAwIDAgNTAg
MCAwIDggMC4wMDAwIDQgNzUgNTcwIDI4NTAgMTA1MCBuYW1lID0gIi4uLiJcMDAxCjQgMCAwIDUw
IDAgMCA4IDAuMDAwMCA0IDkwIDEyMCA5MDAgNjAwIG9wXDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAu
MDAwMCA0IDkwIDEwNSA4MjUgNDk1MCBwXDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCAxMjAg
MjU1IDkwMCA1MDI1IHByaWNlXDAwMQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgMTA1IDI1NSAx
MzUwIDYzNzUgYmFzZVwwMDEKNCAxIDAgNTAgMCAzMiAxMiAwLjAwMDAgNCA5MCAxMjAgMTM1MCA2
MDAwIHNcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDc1IDM0NSA5NzUgNTcwMCBJRD1JRFww
MDEKNCAwIDAgNTAgMCAwIDggMC4wMDAwIDQgMTA1IDIxMCA5NzUgNTU1MCBsLW9wXDAwMQo0IDAg
MCA1MCAwIDAgOCAwLjAwMDAgNCA3NSA1NzAgMTQyNSA2MDc1IG5hbWUgPSAiLi4uIlwwMDEKNCAx
IDAgNTAgMCAzMiAxMiAwLjAwMDAgNCA5MCAxMjAgODI1IDUzMjUgc1wwMDEKNCAxIDAgNTAgMCAz
MiAxMiAwLjAwMDAgNCA5MCAxMjAgNDUwIDYwMDAgc1wwMDEKNCAwIDAgNTAgMCAwIDggMC4wMDAw
IDQgNzUgNzUwIDUyNSA2MDc1IFJPV0lEID0gbGFzdFwwMDEKNCAwIDAgNTAgMCAwIDggMC4wMDAw
IDQgOTAgNzgwIDkwMCA1NDAwIFJPV0lEID0gZmlyc3RcMDAxCjQgMSAwIDUwIDAgMCA4IDAuMDAw
MCA0IDEwNSAxNTAgOTAwIDczNTAgKGcpXDAwMQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgMTA1
IDMwMCA0NTAgNjc1MCB0aWNrc1wwMDEKNCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDEzNSAyNTUg
NDUwIDYzNzUgR2J5XDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCA3NSAxMzUgNTI1IDY0NTAg
SURcMDAxCjQgMSAwIDUwIDAgMCA4IDAuMDAwMCA0IDEwNSAxNTAgMjc3NSA3MzUwIChoKVwwMDEK
NCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDEzNSA2MDAgMjcwMCA1NjI1IHBsYW4gd2l0aFwwMDEK
NCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDEzNSA1MTAgMjcwMCA1ODIwIHBoeXNpY2FsXDAwMQo0
IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgMTIwIDU4NSAyNzAwIDYwMTUgb3BlcmF0b3JzXDAwMQo0
IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgMTM1IDU1NSAyNzAwIDYyMTAgZ29lcyBoZXJlXDAwMQo=
--=====================_456135==_
Content-Type: application/octet-stream; name="plan3.fig"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="plan3.fig"

I0ZJRyAzLjIKTGFuZHNjYXBlCkNlbnRlcgpJbmNoZXMKTGV0dGVyICAKMTAwLjAwClNpbmdsZQot
MgoxMjAwIDIKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSA4MjUgMTU1
MCA4MjUgMTQwMAoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDgyNSAx
ODUwIDgyNSAxNzAwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgNDUw
IDIxNzUgNzUwIDIwMjUKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSAx
MzUwIDIxNzUgMTIwMCAyMTAwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCA1
CgkgNzUwIDE4NzUgOTAwIDE5NTAgOTAwIDE4NzUgNzUwIDE5NTAgNzUwIDE4NzUKMiAxIDAgMSAw
IDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSA4MjUgMTE3NSA4MjUgMTAyNQoyIDEgMCAx
IDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDgyNSA4MDAgODI1IDY1MAoyIDEgMCAx
IDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDgyNSA0MjUgODI1IDI3NQoyIDIgMCAx
IDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgNQoJIDYwMCAxMjAwIDE0MjUgMTIwMCAxNDI1
IDE4MDAgNjAwIDE4MDAgNjAwIDEyMDAKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEg
MCAwIDIKCSAyMzI1IDE1NTAgMjMyNSAxNDAwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAw
IC0xIDAgMCAyCgkgMjMyNSAxODUwIDIzMjUgMTcwMAoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAw
IDAgMCAtMSAwIDAgMgoJIDE5NTAgMjE3NSAyMjUwIDIwMjUKMiAxIDAgMSAwIDcgNTAgMCAtMSAw
LjAwMCAwIDAgLTEgMCAwIDIKCSAyODUwIDIxNzUgMjcwMCAyMTAwCjIgMSAwIDEgMCA3IDUwIDAg
LTEgMC4wMDAgMCAwIC0xIDAgMCA1CgkgMjI1MCAxODc1IDI0MDAgMTk1MCAyNDAwIDE4NzUgMjI1
MCAxOTUwIDIyNTAgMTg3NQoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJ
IDIzMjUgMTE3NSAyMzI1IDEwMjUKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAw
IDIKCSAyMzI1IDgwMCAyMzI1IDY1MAoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAw
IDAgMgoJIDIzMjUgNDI1IDIzMjUgMjc1CjIgMiAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0x
IDAgMCA1CgkgMjEwMCAxNTAwIDI5MjUgMTUwMCAyOTI1IDIxMDAgMjEwMCAyMTAwIDIxMDAgMTUw
MAoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDgyNSA0MjUwIDgyNSA0
MTAwCjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgODI1IDM4NzUgODI1
IDM3MjUKMiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSA4MjUgMzUwMCA4
MjUgMzM1MAoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDgyNSAzMTI1
IDgyNSAyOTc1CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCA1CgkgNzUwIDQy
NzUgOTAwIDQzNTAgOTAwIDQyNzUgNzUwIDQzNTAgNzUwIDQyNzUKMiAxIDAgMSAwIDcgNTAgMCAt
MSAwLjAwMCAwIDAgLTEgMCAwIDIKCSAxNDI1IDQ5MjUgMTQyNSA0Nzc1CjIgMSAwIDEgMCA3IDUw
IDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgMTM1MCA0NjUwIDEyMDAgNDU3NQoyIDEgMCAxIDAg
NyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDQ1MCA0NTc1IDc1MCA0NDI1CjIgMSAwIDEg
MCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgMzgyNSAxNTUwIDM4MjUgMTQwMAoyIDEg
MCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDM4MjUgMTE3NSAzODI1IDEwMjUK
MiAxIDAgMSAwIDcgNTAgMCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSAzODI1IDgwMCAzODI1IDY1
MAoyIDEgMCAxIDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgMgoJIDM4MjUgNDI1IDM4MjUg
Mjc1CjIgMSAwIDEgMCA3IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCA1CgkgMzc1MCAxNTc1IDM5
MDAgMTY1MCAzOTAwIDE1NzUgMzc1MCAxNjUwIDM3NTAgMTU3NQoyIDEgMCAxIDAgNyA1MCAwIC0x
IDAuMDAwIDAgMCAtMSAwIDAgMgoJIDQ0MjUgMjIyNSA0NDI1IDIwNzUKMiAxIDAgMSAwIDcgNTAg
MCAtMSAwLjAwMCAwIDAgLTEgMCAwIDIKCSA0MzUwIDE5NTAgNDIwMCAxODc1CjIgMSAwIDEgMCA3
IDUwIDAgLTEgMC4wMDAgMCAwIC0xIDAgMCAyCgkgMzQ1MCAxODc1IDM3NTAgMTcyNQoyIDIgMCAx
IDAgNyA1MCAwIC0xIDAuMDAwIDAgMCAtMSAwIDAgNQoJIDM2MDAgODI1IDQzNTAgODI1IDQzNTAg
MTUwMCAzNjAwIDE1MDAgMzYwMCA4MjUKNCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDEwNSAyODUg
Mzc1IDIzMjUgdGlja3NcMDAxCjQgMSAwIDUwIDAgMzIgMTIgMC4wMDAwIDQgOTAgMTA1IDgyNSAx
MzUwIHNcMDAxCjQgMSAwIDUwIDAgMCAxMCAwLjAwMDAgNCAxMDUgMjU1IDE0MjUgMjMyNSBiYXNl
XDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCA5MCAzNDUgOTc1IDIwMjUgSUQ9SURcMDAxCjQg
MSAwIDUwIDAgMCAxMCAwLjAwMDAgNCA5MCAyMjUgODI1IDE2NTAgc29ydFwwMDEKNCAwIDAgNTAg
MCAwIDggMC4wMDAwIDQgMTA1IDQ2NSA5MDAgMTQyNSBpbmQgPSAiLi4uIlwwMDEKNCAxIDAgNTAg
MCAwIDEwIDAuMDAwMCA0IDEzNSAyNTUgODI1IDk3NSBHYnlcMDAxCjQgMCAwIDUwIDAgMCA4IDAu
MDAwMCA0IDEyMCAzNzUgOTAwIDEwNTAgSUQsZGF0ZVwwMDEKNCAxIDAgNTAgMCAwIDggMC4wMDAw
IDQgMTIwIDE1MCA4MjUgMjYyNSAoYSlcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDc1IDc1
IDkwMCAxNzI1IHRzXDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAuMDAwMCA0IDkwIDEwNSA4MjUgNjAw
IHNcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDEwNSA0NSA5MDAgNjc1IGZcMDAxCjQgMSAw
IDUwIDAgMzIgMTIgMC4wMDAwIDQgOTAgMTA1IDgyNSAyMjUgcFwwMDEKNCAwIDAgNTAgMCAwIDgg
MC4wMDAwIDQgMTIwIDM3NSA5MDAgMzAwIElELGRhdGVcMDAxCjQgMSAwIDUwIDAgMCAxMCAwLjAw
MDAgNCAxMDUgMjg1IDE4NzUgMjMyNSB0aWNrc1wwMDEKNCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0
IDEwNSAyNTUgMjkyNSAyMzI1IGJhc2VcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDkwIDM0
NSAyNDc1IDIwMjUgSUQ9SURcMDAxCjQgMSAwIDUwIDAgMCAxMCAwLjAwMDAgNCAxMzUgMjU1IDIz
MjUgOTc1IEdieVwwMDEKNCAwIDAgNTAgMCAwIDggMC4wMDAwIDQgMTIwIDM3NSAyNDAwIDEwNTAg
SUQsZGF0ZVwwMDEKNCAxIDAgNTAgMCAwIDggMC4wMDAwIDQgMTM1IDE1MCAyMzI1IDI2MjUgKGIp
XDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAuMDAwMCA0IDkwIDEwNSAyMzI1IDYwMCBzXDAwMQo0IDAg
MCA1MCAwIDAgOCAwLjAwMDAgNCAxMDUgNDUgMjQwMCA2NzUgZlwwMDEKNCAxIDAgNTAgMCAzMiAx
MiAwLjAwMDAgNCA5MCAxMDUgMjMyNSAyMjUgcFwwMDEKNCAwIDAgNTAgMCAwIDggMC4wMDAwIDQg
MTIwIDM3NSAyNDAwIDMwMCBJRCxkYXRlXDAwMQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgOTAg
MjI1IDIzMjUgMTM1MCBzb3J0XDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCA3NSA3NSAyNDAw
IDE0MjUgdHNcMDAxCjQgMSAwIDUwIDAgMzIgMTIgMC4wMDAwIDQgOTAgMTA1IDIzMjUgMTY1MCBz
XDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCAxMDUgNDY1IDI0MDAgMTcyNSBpbmQgPSAiLi4u
IlwwMDEKNCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDEwNSAyNTUgMTQyNSA1MDI1IGJhc2VcMDAx
CjQgMSAwIDUwIDAgMzIgMTIgMC4wMDAwIDQgOTAgMTA1IDgyNSAzMzAwIHNcMDAxCjQgMCAwIDUw
IDAgMCA4IDAuMDAwMCA0IDEwNSA0NSA5MDAgMzM3NSBmXDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAu
MDAwMCA0IDkwIDEwNSA4MjUgMjkyNSBwXDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCAxMjAg
Mzc1IDkwMCAzMDAwIElELGRhdGVcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDkwIDM0NSA5
MDAgNDUwMCBJRD1JRFwwMDEKNCAxIDAgNTAgMCAzMiAxMiAwLjAwMDAgNCA5MCAxMDUgMTQyNSA0
NzI1IHNcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDEwNSA0NjUgMTUwMCA0ODAwIGluZCA9
ICIuLi4iXDAwMQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAwIDQgMTA1IDI4NSA0NTAgNDcyNSB0aWNr
c1wwMDEKNCAxIDAgNTAgMCAwIDggMC4wMDAwIDQgMTIwIDE1MCA4MjUgNTMyNSAoYylcMDAxCjQg
MSAwIDUwIDAgMCAxMCAwLjAwMDAgNCAxMDUgMjU1IDQ0MjUgMjMyNSBiYXNlXDAwMQo0IDEgMCA1
MCAwIDAgMTAgMC4wMDAwIDQgMTM1IDI1NSAzODI1IDk3NSBHYnlcMDAxCjQgMCAwIDUwIDAgMCA4
IDAuMDAwMCA0IDEyMCAzNzUgMzkwMCAxMDUwIElELGRhdGVcMDAxCjQgMSAwIDUwIDAgMzIgMTIg
MC4wMDAwIDQgOTAgMTA1IDM4MjUgNjAwIHNcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDEw
NSA0NSAzOTAwIDY3NSBmXDAwMQo0IDEgMCA1MCAwIDMyIDEyIDAuMDAwMCA0IDkwIDEwNSAzODI1
IDIyNSBwXDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCAxMjAgMzc1IDM5MDAgMzAwIElELGRh
dGVcMDAxCjQgMSAwIDUwIDAgMCAxMCAwLjAwMDAgNCA5MCAyMjUgMzgyNSAxMzUwIHNvcnRcMDAx
CjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0IDc1IDc1IDM5MDAgMTQyNSB0c1wwMDEKNCAwIDAgNTAg
MCAwIDggMC4wMDAwIDQgOTAgMzQ1IDM5MDAgMTgwMCBJRD1JRFwwMDEKNCAxIDAgNTAgMCAzMiAx
MiAwLjAwMDAgNCA5MCAxMDUgNDQyNSAyMDI1IHNcMDAxCjQgMCAwIDUwIDAgMCA4IDAuMDAwMCA0
IDEwNSA0NjUgNDUwMCAyMTAwIGluZCA9ICIuLi4iXDAwMQo0IDEgMCA1MCAwIDAgMTAgMC4wMDAw
IDQgMTA1IDI4NSAzNDUwIDIwMjUgdGlja3NcMDAxCjQgMSAwIDUwIDAgMCA4IDAuMDAwMCA0IDEy
MCAxNTAgMzgyNSAyNjI1IChjKVwwMDEKNCAxIDAgNTAgMCAwIDEwIDAuMDAwMCA0IDEzNSAyNTUg
ODI1IDQwNTAgR2J5XDAwMQo0IDAgMCA1MCAwIDAgOCAwLjAwMDAgNCAxMjAgMzc1IDkwMCA0MjAw
IElELGRhdGVcMDAxCjQgMSAwIDUwIDAgMCAxMCAwLjAwMDAgNCAxMDUgNTcwIDgyNSAzNjc1IHNv
cnQtZWFjaFwwMDEKNCAwIDAgNTAgMCAwIDggMC4wMDAwIDQgNzUgNzUgMTEyNSAzNzUwIHRzXDAw
MQo=
--=====================_456135==_--