More changes to first arxive intro section.

This commit is contained in:
Aaron Huber 2022-01-17 12:17:17 -05:00
parent 317fe1602f
commit a2fcf0b468
2 changed files with 97 additions and 71 deletions

View file

@ -3,50 +3,110 @@
\section{Introduction}\label{sec:intro}
\secrev{
This work explores the problem of developing a theoretical framework (\textit{at fine-grained/parameterized levels}) for the problem of computing the expectation of a tuple's multiplicity in a bag \abbrPDB. We begin our analysis using a restricted form of \abbrPDB which we call a \abbrCTIDB. A \abbrCTIDB, $\pdb = \inparen{\idb, \pd}$, is a bag \abbrPDB where each tuple is an independent random event, with a multiplicity of at most $c$, where $\idb$ is the set of possible worlds and $\pd$ is the probability distribution over $\idb$. Since each tuple in $\pdb$ has a mutually exclusive probability distribution over its possible multiplicities, it is natural to reduce a \abbrCTIDB to traditional (set) block independent database (\abbrBIDB). We refer to the reduced \abbrBIDB as a $1$-\abbrBIDB, as it is the case that each tuple can appear in a possible world at most $c = 1$ time. \Cref{fig:ctidb-red} shows an example of this reduction. We can formally state this problem as:
This work explores the problem of developing a theoretical framework (\textit{at fine-grained/parameterized levels}) for the problem of computing the expectation of a tuple's multiplicity in a bag \abbrPDB. We begin our analysis using a restricted form of \abbrPDB which we call a \abbrCTIDB. A \abbrCTIDB, $\pdb = \inparen{\idb, \pd}$, is a bag \abbrPDB where each tuple is an independent random event, with a multiplicity of at most $c$, where $\idb$ is the set of possible worlds and $\pd$ is the probability distribution over $\idb$.
}
\mypar{For a later section}
%\sout{
Since each tuple in $\pdb$ has a mutually exclusive probability distribution over its possible multiplicities, it is natural to reduce a \abbrCTIDB to traditional (set) block independent database (\abbrBIDB). We refer to the reduced \abbrBIDB as a $1$-\abbrBIDB, as it is the case that each tuple can appear in a possible world at most $c = 1$ time. \Cref{fig:ctidb-red} shows an example of this reduction.
%}
\secrev{
Allowing for $\leq c$ multiplicities across all tuples gives rise to having $\leq c^\numvar$ possible worlds instead of the usual $2^\numvar$ possible worlds of a \abbrTIDB. \Cref{fig:ctidb-red} shows an example \abbrCTIDB and the possible worlds (with probabilities) which the model encodes.
We can formally state this problem as:
\begin{Problem}\label{prob:expect-mult}
Given a \abbrCTIDB $\pdb = \inparen{\idb, \pd}$, query $\query$, and result tuple $\tup$, compute the expected multiplicity of $\tup$: $\expct_{\randDB\sim\pd}\pbox{\query\inparen{\randDB}\inparen{\tup}}$.
\end{Problem}
\begin{figure}[h!]
\centering
\textcolor{red}{
\begin{tabular}{c | c | c}
\multicolumn{3}{c}{$\mathbf{\rel}$}\\
\begin{tabular}{>{\footnotesize}c | >{\footnotesize}c | >{\footnotesize}c | >{\footnotesize}c | >{\footnotesize}c}
\multicolumn{5}{c}{$\mathbf{\rel}$}\\
\toprule
A & Mult. & id\\
A & Mult. $\inparen{M}$ &$\probOf\pbox{M=1}$ &$\probOf\pbox{M=2}$ &$\probOf\pbox{M=3}$\\
\midrule
$a$ & $2$ & $\tup_1$\\
$b$ & $3$ & $\tup_2$\\
$a$ & $2$ & $0.4$ &$0.3$ &$0.0$\\
$b$ & $3$ & $0.2$ &$0.35$ &$0.15$\\
\end{tabular}
\hspace*{1cm}
{\LARGE $\equiv$}
\hspace*{1cm}
\begin{tabular}{c | c | c}
\multicolumn{3}{c}{$\textbf{\rel'}$}\\
% \hspace*{0.5cm}
% {\LARGE $\Rightarrow$}
% \hspace*{0.5cm}
\begin{tabular}{>{\footnotesize}c | >{\footnotesize}c}
\multicolumn{2}{c}{$\textbf{World Probabilities}$}\\
\toprule
A & $\poly$ & $\probOf\pbox{x_{i, j}}$\\
World & Probability \\
\midrule
a & $\pVar_{1, 1}$ & $0.4$\\
a & $\pVar_{1, 2}$ & $0.3$\\
a & $\pVar_{1, 3}$ & $0.0$\\
\midrule
b & $\pVar_{2, 1}$ & $0.2$\\
b & $\pVar_{2, 2}$ & $0.35$\\
b & $\pVar_{2, 3}$ & $0.15$\\
$\emptyset$ & $0.3\cdot0.3 = 0.09$\\
$\inset{\intup{a, 1}}$ & $0.4\cdot0.3 = 0.12$\\
$\inset{\intup{a, 2}}$ & $0.3\cdot0.3 = 0.09$\\
$\inset{\intup{b, 1}}$ & $0.3\cdot0.2 = 0.06$\\
$\inset{\intup{b, 2}}$ & $0.3\cdot0.35 = 0.105$\\
$\inset{\intup{b, 3}}$ & $0.3\cdot0.15 = 0.045$\\
$\inset{\intup{a, 1}, \intup{b, 1}}$ & $0.4\cdot0.2 = 0.08$\\
$\inset{\intup{a, 1}, \intup{b, 2}}$ & $0.4\cdot0.35 = 0.14$\\
$\inset{\intup{a, 1}, \intup{b, 3}}$ & $0.4\cdot0.15 = 0.06$\\
$\inset{\intup{a, 2}, \intup{b, 1}}$ & $0.3\cdot0.2 = 0.06$\\
$\inset{\intup{a, 2}, \intup{b, 2}}$ & $0.3\cdot0.35 = 0.105$\\
$\inset{\intup{a, 2}, \intup{b, 3}}$ & $0.3\cdot0.15 = 0.045$\\
\end{tabular}
}
\caption{\textcolor{red}{\abbrCTIDB ($\rel$) Reduction to $1$-\abbrBIDB ($\rel'$). Note the probability distribution over tuple multiplicities of $\rel$, where e.g. tuple $\tup_1$ has a probability $\prob_{1, j} > 0$ for each multiplicity $j \in [2]$. This is better expressed as a block of mutually exclusive tuples, where each tuple has a specific multiplicity in $[c]$. Multiplicities that don't exist are automatically assigned a probability of $0$. Also note that it is implicit in \abbrBIDB\xplural for a block $i$ that $1 - \sum_{j \in [c]}\prob_{i, j}$ is the probability that no tuple in that block will be selected for a possible world.
\caption{\textcolor{red}{\abbrCTIDB relation$\rel$ and its possible worlds with their probabilities.% Reduction to $1$-\abbrBIDB ($\rel'$). Note the probability distribution over tuple multiplicities of $\rel$, where e.g. tuple $\tup_1$ has a probability $\prob_{1, j} > 0$ for each multiplicity $j \in [2]$. This is better expressed as a block of mutually exclusive tuples, where each tuple has a specific multiplicity in $[c]$. Multiplicities that don't exist are automatically assigned a probability of $0$. Also note that it is implicit in \abbrBIDB\xplural for a block $i$ that $1 - \sum_{j \in [c]}\prob_{i, j}$ is the probability that no tuple in that block will be selected for a possible world.
}}
\label{fig:ctidb-red}
\end{figure}
We upperbound the multiplicity of tuples in a \abbrCTIDB because of the cancellation effect of queries over a $1$-\abbrBIDB, where, for the worst case, a self join query, we would have a factor of $\frac{1}{c^{n-1}}$ cancellations. Allowing for unbounded $c$ is an intersting open problem.\newline
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%Figure may work for an example in a later section of the Intro
%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\begin{figure}[h!]
% \centering
% \textcolor{red}{
% \begin{tabular}{c | c | c}
% \multicolumn{3}{c}{$\mathbf{\rel}$}\\
% \toprule
% A & Mult. & id\\
% \midrule
% $a$ & $2$ & $\tup_1$\\
% $b$ & $3$ & $\tup_2$\\
% \end{tabular}
% \hspace*{1cm}
% {\LARGE $\equiv$}
% \hspace*{1cm}
% \begin{tabular}{c | c | c}
% \multicolumn{3}{c}{$\textbf{\rel'}$}\\
% \toprule
% A & $\poly$ & $\probOf\pbox{x_{i, j}}$\\
% \midrule
% a & $\pVar_{1, 1}$ & $0.4$\\
% a & $\pVar_{1, 2}$ & $0.3$\\
% a & $\pVar_{1, 3}$ & $0.0$\\
% \midrule
% b & $\pVar_{2, 1}$ & $0.2$\\
% b & $\pVar_{2, 2}$ & $0.35$\\
% b & $\pVar_{2, 3}$ & $0.15$\\
% \end{tabular}
% }
% \caption{\textcolor{red}{\abbrCTIDB ($\rel$) Reduction to $1$-\abbrBIDB ($\rel'$). Note the probability distribution over tuple multiplicities of $\rel$, where e.g. tuple $\tup_1$ has a probability $\prob_{1, j} > 0$ for each multiplicity $j \in [2]$. This is better expressed as a block of mutually exclusive tuples, where each tuple has a specific multiplicity in $[c]$. Multiplicities that don't exist are automatically assigned a probability of $0$. Also note that it is implicit in \abbrBIDB\xplural for a block $i$ that $1 - \sum_{j \in [c]}\prob_{i, j}$ is the probability that no tuple in that block will be selected for a possible world.
%}}
% \label{fig:ctidb-red}
%\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
We upperbound the multiplicity of tuples in a \abbrCTIDB because of the cancellation effect of queries over a $1$-\abbrBIDB (introduced later), where, for the worst case, a self join query, we would have a factor of $\frac{1}{c^{n-1}}$ cancellations. Allowing for unbounded $c$ is an intersting open problem.
}
%\sout{
\mypar{Example that can perhaps be used later on (using commented out figure above)}
Given a \abbrCTIDB $\pdb$ with $\numvar$ tuples, we can encode a possible world by the vector $\vct{W} \in \inset{0,\ldots, c}^\numvar$, with the intuitive interpretation when bit $W_i = j$, then tuple $\tup_i$ with multiplicity $j$ is selected, with $\tup_i$ not existing for the special case of $j = 0$. For the example in ~\cref{fig:ctidb-red}, we have that for \abbrCTIDB $\textbf{R}$, $\numvar = 2$. Then, e.g., arbitrary world vector $\vct{W} = [2, 3]$ encodes the possible world $\db = \inset{\intup{a, 2}, \intup{b, 3}}$ Computing ~\cref{prob:expect-mult} for tuple $\tup_2$ in ~\cref{fig:ctidb-red} when $\query = \mathbf{\rel}$ then becomes $\expct_{\randDB\sim\pd}\pbox{\mathbf{\rel}\inparen{\tup_2}} = 1\cdot\prob_{2,1} + 2\cdot\prob_{2,2} + 3\cdot\prob_{2,3} = 1\cdot 0.2 + 2\cdot 0.35 + 3\cdot 0.15 = 1.35$.
\newline One of the main points in our theoretical work is to discern whether or not bag \abbrPDB query semantics are indeed linear in the runtime of the deterministic query. Unfortunately, we prove that this is not the case. To analyze this question we denote by $\timeOf{}^*(Q,\pdb)$ the optimal runtime complexity of computing ~\cref{prob:expect-mult} over \abbrCTIDB $\pdb$. Let $\qruntime{\query, \db}$ be the runtime of query $\query$ on deterministic database $\db$ under a cost model that is satisfied by a wide range of query processing algorithms, including those based on the recent work on worst-case optimal join algorithms. We make this runtime concrete later on.
%}
\secrev{
One of the main theoretical points in this work is to discern whether or not bag \abbrPDB query semantics are indeed linear in the runtime of the deterministic query. Unfortunately, we prove that this is not the case. To analyze this question we denote by $\timeOf{}^*(Q,\pdb)$ the optimal runtime complexity of computing ~\cref{prob:expect-mult} over \abbrCTIDB $\pdb$. Let $\qruntime{\query, \db}$ be the runtime of query $\query$ on deterministic database $\db$ under a cost model that is satisfied by a wide range of query processing algorithms, including those based on the recent work on worst-case optimal join algorithms. We make this runtime concrete later on.
We denote by $\dbbase$ the base \abbrCTIDB table containing all possible tuples, formally as,
\begin{Definition}[$\dbbase$]
Let $\dbbase$ be the relation composed of all possible tuples in $\pdb$, i.e. $\dbbase = \bigcup_{\db \in \idb}\db$.
\end{Definition}
~\Cref{tab:lbs} shows our upper and lower bounds for computing ~\cref{prob:expect-mult} on general \abbrPDB\xplural.
~\Cref{tab:lbs} shows our lower bounds for computing ~\cref{prob:expect-mult} on general \abbrPDB\xplural.
\newline
\begin{table}[h!]
\begin{tabular}{|p{0.43\textwidth}|p{0.12\textwidth}|p{0.35\textwidth}|}
@ -65,9 +125,17 @@ $\Omega\inparen{\inparen{\qruntime{\query, \dbbase}}^{c_0\cdot k}}$ for {\em som
\end{table}
\mypar{Our lower bound results} In table~\ref{tab:lbs} we show that depending on what hardness result/conjecture we assume, we get various emphatic versions of {\em no} as an answer to our question. To make some sense of the other lower bounds in Table~\ref{tab:lbs}, we note that it is not too hard to show that $\timeOf{}^*(Q,\pdb) \le O\inparen{\inparen{\qruntime{Q, \dbbase}}^k}$, where $k$ is the largest degree of the polynomial $\apolyqdt$ over all result tuples $\tup$ (and the parameter that defines our family of hard queries). What our lower bound in the third row says is that one cannot get more than a polynomial improvement over essentially the trivial algorithm for \Cref{prob:informal}.\AH{Not sure what is meant by `the trivial algorithm for (what was originally called) Problem 1.4'}
However, this result assumes a hardness conjecture that is not as well studied as those in the first two rows of the table (see \Cref{sec:hard} for more discussion on the hardness assumptions). Further, we note that existing results already imply the claimed lower bounds if we were to replace the $\qruntime{\query, \dbbase}$ by just $\abs{\dbbase}$ (indeed these results follow from known lower bound for deterministic query processing). Our contribution is to then identify a family of hard queries where deterministic query processing is `easy' but computing the expected multiplicities is hard.
% To put these hardness results in context, we will next take a short detour
%\AH{Is this detour still necessary?}
%to review the existing hardness results for \abbrPDB\xplural under set semantics.
\mypar{Our upper bound results} We introduce an $(1\pm \epsilon)$-approximation algorithm that computes ~\cref{prob:expect-mult} in $\leq \qruntime{\query, \dbbase}$. In particular, we show the following upper bound results.
(i) We show that e.g. for a circuit representation of the lineage polynomial (more on this later), when the circuit is a tree and there is a single
result tuple, we also have the same runtime (we can also handle the case of multiple result tuples\footnote{We can approximate the expected result tuple multiplicities (for all result tuples {\em simultanesouly}) with only $O(\log{Z})=O_k(\log{n})$ overhead (where $Z$ is the number of result tuples) over the runtime of a broad class of query processing algorithms (see \Cref{app:sec-cicuits}).}).
Further, we show that for {\em any} $\raPlus$ query on a \abbrTIDB $(1$-$\abbrTIDB)$, we also obtain linear runtime for approximation.
% the approximation algorithm has runtime linear in the size of the compressed lineage encoding (
In contrast, known approximation techniques (\cite{DBLP:conf/icde/OlteanuHK10,DBLP:journals/jal/KarpLM89}) in set-\abbrPDB\xplural need time $\Omega(\abs{\circuit}^{2k})$ (see \Cref{sec:karp-luby}).
(ii) We generalize the \abbrPDB data model considered by the approximation algorithm to a class of bag-Block Independent Disjoint Databases (see \Cref{subsec:tidbs-and-bidbs}) (\abbrBIDB\xplural).
}
\secrev{
\subsection{Polynomial Equivalence}
}
A probabilistic database (PDB) $\pdb$ is a pair $\inparen{\idb, \pd}$, where $\idb$ is a set of deterministic database instances called possible worlds and $\pd$ is a probability distribution over $\idb$.
@ -80,23 +148,11 @@ Following~\cite{DBLP:conf/pods/GreenKT07}, we model bag databases (resp., relati
\sout{
We refer to such a probabilistic database as a bag-probabilistic database or \abbrBPDB for short.
}
The natural generalization of the \AHchange{(set)} problem of computing marginal probabilities of query result tuples to bag semantics is to compute the expectation of a random variable over $\pd$ that is assigned value $\query(\db)(\tup) \in \semN$ in world $\db \in \idb$
\AHchange{
, formally $\expct_{\randDB\sim\pd}\pbox{\query\inparen{\randDB}\inparen{\tup}}$.
}
%OK: done
%\AH{I think I understand what is being stated in this last sentence, but I wonder if phrasing the end something like, ``for world $\db \in \idb$ would be easier to digest for the average reviewer...maybe it was just me.}
% In bag query semantics the random variable $\query\inparen{\pdb}\inparen{\tup}$ is the multiplicity of its corresponding output tuple $\tup$ (in a random database instance in $\idb$ chosen according to $\pd$).
%In addition to traditional deterministic query evaluation requirements (for a given query class), the query evaluation problem in bag-\abbrPDB semantics can be formally stated as:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\begin{Problem}[Expected Multiplicity]\label{prob:bag-pdb-query-eval}
%Given an \raPlus query\footnote{The class of positive relational algebra (\raPlus) queries consists of all queries that can be composed of the positive (monotonic) relational algebra operators: selection, projection, join, and union (SPJU).\label{footnote:ra-def}} $\query$, \abbrBPDB $\pdb$, and result tuple $\tup$, compute the expected
%multiplicity ($\expct_{\randDB\sim\pd}\pbox{\query\inparen{\randDB}\inparen{\tup}}$)
%of tuple $\tup$.
%\end{Problem}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
For \lstinline{COUNT(*)} queries, expected multiplicities can model the expected count. \sout{
The equivalent set-\abbrPDB operation, simply computes the probability that this count is non-zero.
@ -118,7 +174,7 @@ We then define a \abbrCTIDB be a bag \abbrTIDB with the further restriction that
}
\noindent\AHchange{
For notational convenience we make use of the following definitions.
For notational convenience we make use of the following definition.
\begin{Definition}[$\pdassign$]
Given a \abbrCTIDB $\pdb = \inparen{\idb, \pd}$ and the set of all $c^\numvar$ worlds $W$, denote the probability distribution induced from $\pd$ over each world $\wElem \in W$ as $\pdassign$.
\end{Definition}
@ -356,37 +412,7 @@ Given one circuit $\circuit$ that encodes $\apolyqdt$ for all result tuples $\tu
%%%%%%%%%%%%%%%%%%%%%%%%%
%Contributions, Overview, Paper Organization
%%%%%%%%%%%%%%%%%%%%%%%%%
\mypar{Our upper bound results} We show that the answer to \Cref{prob:intro-stmt} (and hence the answer to \Cref{prob:big-o-joint-steps}) is yes. In particular, we show the following upper bound results.
%In this paper we tackle~\Cref{prob:bag-pdb-query-eval} to~\Cref{prob:intro-stmt}.
%Concretely, we make the following contributions:
%(i) %Under fine grained hardness assumption,
%We show that the answer to~\Cref{prob:bag-pdb-query-eval} is \textit{no} in general for exact computation. %\cref{prob:intro-stmt} for bag-\abbrTIDB\xplural is not true in general
% \sharpwonehard in the size of the lineage circuit
%In fact, via a
%reduction from counting the number of $k$-matchings over an arbitrary graph, we show that the problem of \abbrStepTwo (\termStepTwo) is \sharpwonehard. I.e., not only is the answer to~\Cref{prob:intro-stmt} no, but \abbrStepTwo cannot be solved in fully polynomial time, i.e. there is no algorithm for \abbrStepTwo with runtime that grows as $f(k)\cdot |\circuit|^d$, where $k$ is the degree of the corresponding lineage polynomial and $d$ is any fixed constant.\footnote{We would like to note that it is a well-known result in deterministic query computation that \abbrStepOne is also \sharpwonehard. What our result says is that \abbrStepTwo is \sharpwonehard\emph{even if} we exclude the complexity of \abbrStepOne .}
%This hardness result requires the algorithm to be able to solve the hard query $Q$ for {\em multiple} PDBs. We further show that the answer to~\Cref{prob:intro-stmt} is no even if we fix the $\pd$ (in particular, we insist on $\prob_i = \prob$ for some $\prob$ in $(0, 1)$).
%Atri: The footnote above is where I talk about \sharpwonehard of det query complexity.
%We further note that in our hardness proofs, we have $|\circuit|=\Theta\inparen{\timeOf{\abbrStepOne}(Q,\pdb)}$, which shows that the answer to~\Cref{prob:bag-pdb-query-eval} is also no.\AR{Need to make sure we have the correct statement for this claim (i) in the main paper.}
%we further show superlinear hardness in the size of \circuit for a specific %cubic
%graph query for the special case of all $\prob_i = \prob$ for some $\prob$ in $(0, 1)$;
%(ii) To complement our hardness results, we consider an approximate version of~\Cref{prob:intro-stmt}, where instead of computing the expected multiplicity exactly, we allow for an $(1\pm\epsilon)$-\emph{multiplicative} approximation of the expected multiplicitly.
(i) We show that %for typical database usage patterns\BG{Not sure what we mean by that?}
e.g. when the circuit is a tree
%or is generated by recent worst-case optimal join algorithms or their Functional Aggregate Query (FAQ)/Aggregations and Joins over Annotated Relations (AJAR) followups~\cite{DBLP:conf/pods/KhamisNR16, ajar}),
and there is a single
result tuple, %\BG{This sounds like we restricting the discussion to queries that return a single tuple}\AR{Does moving the footnote help?},
the answer to \Cref{prob:intro-stmt} for \abbrTIDB is {\em yes} (we can also handle the case of multiple result tuples\footnote{We can approximate the expected result tuple multiplicities (for all result tuples {\em simultanesouly}) with only $O(\log{Z})=O_k(\log{n})$ overhead (where $Z$ is the number of result tuples) over the runtime of a broad class of query processing algorithms (see \Cref{app:sec-cicuits}).}).
Further, we show that for {\em any} $\raPlus$ query on a \abbrTIDB, the answer to \Cref{prob:big-o-joint-steps} is also yes.
% the approximation algorithm has runtime linear in the size of the compressed lineage encoding (
In contrast, known approximation techniques (\cite{DBLP:conf/icde/OlteanuHK10,DBLP:journals/jal/KarpLM89}) in set-\abbrPDB\xplural need time $\Omega(\abs{\circuit}^{2k})$ (see \Cref{sec:karp-luby}).
%\cite{DBLP:conf/icde/OlteanuHK10,DBLP:journals/jal/KarpLM89}.
%Atri: The footnote below does not add much
%\footnote{Note that this doesn't rule out queries for which approximation is linear});
(ii) We generalize the \abbrPDB data model considered by the approximation algorithm to a class of bag-Block Independent Disjoint Databases (see \Cref{subsec:tidbs-and-bidbs}) (\abbrBIDB\xplural).
%\AH{This point \emph{\Large seems} weird to me. I thought we just said that the approximation complexity is linear in step one, but now it's as if we're saying that it's $\log{\text{step one}} + $ the runtime of step one. Where am I missing it?}
%\OK{Atri's (and most theoretician's) statements about complexity always need to be suffixed with ``to within a log factor''}
%(iii) We finally observe that our results trivially extend to higher moments of the tuple multiplicity (instead of just the expectation).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

View file

@ -11,7 +11,7 @@
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%editing/highlighting sections
\newcommand{\AHchange}[1]{\textcolor{blue}{#1}}
\newcommand{\secrev}[1]{\textcolor{red}{#1}}
\newcommand{\secrev}[1]{\color{red}#1\color{black}}
\newcommand{\draft}{0} %%% Change this to non-zero to remove comments
\ifnum\draft=0
\newcommand{\currentWork}[1]{\textcolor{red}{#1}}