Fixed a few typos.

introduction.tex

@@ -77,8 +77,8 @@ computing the probability of an output tuple's multiplicity being bounded by giv
 \mypar{Our Setup} In contrast to~\cite{https://doi.org/10.48550/arxiv.2201.11524}, we consider \abbrCTIDB\xplural, i.e., the multiplicity of input tuples is bound by a constant $\bound$.
 Then, % (\abbrCTIDB\xplural, i.e., the multiplicity of input tuples is bound by a constant $\bound$), however,
 there exists a trivial \ptime algorithm for computing the expectation of a result tuple's multiplicity~(\Cref{prob:expect-mult}) for any fixed $\raPlus$ query  due to linearity of expectation (see~\Cref{sec:intro-poly-equiv}).
-Since the {\em data complexity} of~\Cref{prob:expect-mult} is in \ptime, the  %interesting 
-we explore the question of  %the hardness of 
+Since the {\em data complexity} of~\Cref{prob:expect-mult} is in \ptime, %interesting 
+we then explore the question of  %the hardness of 
  computing expectation using fine-grained and parameterized complexity, where we are interested in the exponent of polynomial runtime.\footnote{While %the authors of 
   \cite{https://doi.org/10.48550/arxiv.2201.11524} also observes that computing the expectation of an output tuple multiplicity is in \ptime, it does not investigate the fine-grained complexity of this problem.}
 
@@ -118,7 +118,7 @@ that maps each tuple in $\gentupset$ to a multiplicity in $[0,\bound]$.
 %where the maximum multiplicity of any tuple is less than or equal to $\bound$.  % This paper considers $\raPlus$ queries, for which order of operations is \emph{explicit}, as opposed to other query languages, e.g. Datalog, UCQ.  Thus, since order of operations affects runtime, we denote the optimized $\raPlus$ query picked by an arbitrary production system as $\optquery{\query} \approx \min_{\query'\in\raPlus, \query'\equiv\query}\qruntime{\query', \gentupset, \bound}$.  Then $\qruntime{\optquery{\query}, \gentupset,\bound}$ is the runtime for the optimized query.\footnote{The upper bounds on runtime that we derive apply pointwise to any $\query \in\raPlus$, allowing us to abstract away the specific heuristics for choosing an optimized query (i.e., Any deterministic query optimization heuristic is equally useful for \abbrCTIDB queries).}\BG{Rewrite: since an optimized Q is also a Q this also applies in the case where there is a query optimizer the rewrites Q}
 Our question is whether or not it is always true that for every $\query$,  $\timeOf{}^*\inparen{\query, \pdb, \bound}\leq \bigO{\qruntime{\optquery{\query}, \tupset, \bound}}$.  We remark that the issue of query optimization is orthogonal to this question (recall that an $\raPlus$ query explicitly encodes order of operations) since we want to answer the above question for {\em all} $\query$. \emph{Specifically, if there is an equivalent and more efficient query $\query'$, we allow both deterministic and probabilistic query processing access to $\query'$}.
 
-Unfortunately the the answer to the above question  is no--
+Unfortunately the answer to the above question  is no--
  \Cref{tab:lbs} shows our results.
 Specifically, depending on what hardness result/conjecture we assume, we get various weaker or stronger versions of {\em no} as an answer to our question.  To make some sense of the  lower bounds in \Cref{tab:lbs}, we note that it is not too hard to show that $\timeOf{}^*(\query,\pdb, \bound) \le  \bigO{\inparen{\qruntime{\optquery{\query}, \tupset, \bound}}^k}$, where $k$ is the join width of $\query$ (our notion of join width 
 %follows from~\Cref{def:degree-of-poly}